OpenStack 스토리지는 Glance(이미지)로 시작 → Cinder(블록)로 디스크 확장 → Swift(오브젝트)로 파일 보관, 이 세 축이 전부입니다. “블록은 디스크처럼, 오브젝트는 드라이브처럼”만 기억하면 헷갈릴 일이 없습니다. 홈랩 랩에선 Glance + Cinder(LVM)부터 붙여보는 걸 권합니다.
OpenStack 플레이버 설계는 단순히 vCPU 몇 개, RAM 몇 GB를 고르는 일이 아닙니다. 실제 운영 환경에서는 이 선택 하나 때문에 웹 서버는 멀쩡한데 DB만 느려지거나, 작은 배치 작업 하나가 Compute Node(컴퓨트 노드, 가상 머신을 실제로 실행하는 호스트)의 리소스를 오래 붙잡는 상황이 생기거든요.
저도 처음 홈랩에서 OpenStack을 만졌을 때는 “그냥 small, medium, large 만들면 되겠지”라고 생각했습니다. 그런데 실제로 써보니 꽤 다르더라고요. 같은 4 vCPU VM(Virtual Machine, 가상 머신)이라도 웹 워크로드와 데이터베이스 워크로드가 원하는 리소스 성격은 완전히 달랐습니다. CPU가 순간적으로 치솟는 서비스도 있고, 메모리를 꾸준히 쓰는 서비스도 있고, 디스크 I/O(Input/Output, 입출력) 때문에 전체가 버벅이는 경우도 있었습니다.
VM 사양은 넉넉해 보이는데 애플리케이션은 느리고, 반대로 어떤 VM은 리소스를 거의 안 쓰는데 너무 큰 플레이버를 물고 있는 상황을 본 적 있으신가요? 이 글에서는 Nova 플레이버를 워크로드 기준으로 어떻게 나누고, 어떤 명령어로 만들고, 운영 중 어떤 지표를 보고 조정할지 실무 관점으로 정리해보겠습니다.
OpenStack에서 플레이버가 VM 크기뿐 아니라 워크로드 배치 전략의 출발점이 된다는 흐름을 보여주는 개요 이미지입니다.
Nova 플레이버 개념: VM의 표준 사이즈표
OpenStack에서 Flavor(플레이버)는 VM을 만들 때 선택하는 리소스 묶음입니다. vCPU, Memory(메모리), Disk(디스크) 같은 기본값을 정의하고, 필요하면 Extra Specs(추가 속성)를 붙여 스케줄링, CPU 정책, 메모리 페이지 정책까지 조정합니다.
쉽게 말해 옷 사이즈표와 비슷합니다. small, medium, large라는 이름만 있다고 좋은 게 아니라, 우리 서비스에 맞는 치수표를 만들어야 합니다. 운영자가 미리 합리적인 사이즈를 만들어두면 사용자는 매번 VM 사양을 고민하지 않아도 되고, 인프라 입장에서는 리소스 낭비를 줄일 수 있습니다.
vCPU: 가상 CPU 개수입니다. CPU 연산이 많은 워크로드에서 중요합니다.
RAM: VM에 할당되는 메모리입니다. 캐시, DB, JVM 기반 서비스에서 특히 민감합니다.
Root Disk: 기본 부팅 디스크 크기입니다. 이미지 기반 배포에서는 너무 크게 잡지 않는 편이 관리가 쉽습니다.
Ephemeral Disk: VM 삭제 시 함께 사라지는 임시 디스크입니다.
Extra Specs: CPU 고정, Huge Pages(휴즈 페이지, 큰 메모리 페이지), NUMA(Non-Uniform Memory Access, 비균일 메모리 접근) 같은 고급 옵션을 지정할 때 씁니다.
중요한 포인트는 하나입니다. 플레이버는 “많이 주면 좋다”가 아닙니다. 워크로드 분석을 먼저 하고, 그 다음에 VM 모양을 맞춰야 합니다. 이 순서가 바뀌면 나중에 튜닝이 꽤 피곤해집니다.
워크로드 분석 기준: CPU, 메모리, 디스크, 네트워크
실제 운영에서는 워크로드를 크게 네 부류로 나눠 보는 게 편했습니다. 웹/API 서버, 데이터베이스, 배치/분석 작업, 네트워크 장비형 VM입니다. 이름은 단순하지만 확인해야 할 지표는 서로 다릅니다.
워크로드 유형
주요 병목
플레이버 설계 방향
확인할 지표
웹/API 서버
순간 CPU, 네트워크
중간 vCPU, 적당한 RAM, 수평 확장 고려
CPU 사용률, Load Average, 요청 지연
DB 서버
메모리, 디스크 I/O
RAM 여유, 빠른 볼륨, 필요 시 전용 CPU
iowait, 디스크 await, 캐시 히트율
배치/분석
CPU 지속 사용, 메모리 피크
작업 시간대와 동시 실행 수 기준으로 분리
pidstat, sar, 메모리 스왑 여부
네트워크 장비형 VM
패킷 처리, 인터럽트
CPU 정책과 네트워크 드라이버 확인
pps, 인터페이스 오류, softirq
실무에서는 평균값보다 피크 패턴을 더 자주 봅니다. CPU 평균이 낮아도 특정 시간대에 요청이 몰리면 체감 성능은 나빠집니다. 반대로 하루에 한 번만 도는 배치 작업에 항상 큰 플레이버를 붙여두면 리소스가 아깝습니다. VM 수가 늘어나면 이 차이가 진짜 크게 느껴지더라고요.
OpenStack 플레이버 설계 실전: CLI로 생성하기
이제 실제 명령어로 가보겠습니다. 아래 예시는 OpenStackClient 기준입니다. 환경마다 인증 방식은 다르지만, 보통은 OpenRC 파일을 source 한 뒤 실행합니다.
여기서 RAM 단위는 MB입니다. 4096은 4GB, 8192는 8GB로 보면 됩니다. 처음엔 저도 이 단위를 대충 보고 넘겼다가 “왜 생각보다 작게 잡혔지?” 하고 한참 봤던 기억이 있습니다. 은근히 자주 하는 실수입니다.
DB나 지연 시간에 민감한 워크로드는 Extra Specs(추가 속성)를 고민할 수 있습니다. 예를 들어 CPU를 공유 정책으로 둘지, dedicated(전용 할당) 정책을 쓸지 판단해야 합니다. 다만 hw:cpu_policy=dedicated 같은 설정은 Compute Node의 전용 CPU 집합, Placement 리소스, Nova 설정이 맞아야 의미가 있습니다. 명령어만 넣는다고 마법처럼 빨라지지는 않더라고요.
OpenStack CLI로 기본 플레이버를 만들고 Extra Specs를 붙여 워크로드별로 구분하는 과정을 나타낸 구성 이미지입니다.
hw:cpu_policy=dedicated는 전용 pCPU(Physical CPU, 물리 CPU)에 vCPU를 고정하는 정책이고, hw:mem_page_size=large는 큰 메모리 페이지 사용을 요청합니다. 단, Huge Pages는 호스트 커널과 libvirt/KVM 쪽 준비가 필요합니다. 지원되지 않는 환경에서 무작정 넣으면 VM 생성이 실패할 수 있습니다.
가상 머신 최적화: 작은 VM 여러 대 vs 큰 VM 한 대
가상 머신 최적화에서 자주 나오는 고민이 있습니다. “2 vCPU VM 여러 대가 나을까, 8 vCPU VM 한 대가 나을까?” 정답은 워크로드에 따라 다릅니다. 웹/API 서버처럼 stateless(상태를 서버에 많이 저장하지 않는 구조)에 가까우면 작은 VM을 여러 대 두고 로드밸런서로 나누는 편이 운영상 편했습니다. 장애 격리도 좋고, 배포 롤백도 덜 무섭습니다.
반대로 DB처럼 상태가 크고 디스크 I/O가 중요한 서비스는 무작정 쪼개기 어렵습니다. 이 경우에는 메모리와 디스크 경로를 먼저 보고, 필요하면 전용 CPU 정책이나 빠른 Cinder Volume(신더 볼륨, OpenStack 블록 스토리지)을 붙이는 식으로 접근합니다.
먼저 애플리케이션의 병목 후보를 정합니다. CPU인지, 메모리인지, 디스크인지 구분합니다.
작은 기본 플레이버로 시작하되, 모니터링 지표를 붙입니다.
피크 시간대에 CPU iowait, 메모리 swap, 디스크 await 같은 값을 확인합니다.
증설이 필요하면 같은 계열의 다음 플레이버로 올립니다.
계속 같은 병목이 반복되면 플레이버 문제가 아니라 애플리케이션 구조나 스토리지 설계를 다시 봅니다.
추천하는 방식은 “처음부터 대형 플레이버”가 아니라 계열을 나눠 점진적으로 올리는 방식입니다. 예를 들어 web.small → web.medium → web.large처럼 같은 성격 안에서만 키우면 운영자가 판단하기 쉽습니다. 이거 진짜 편하더라고요.
점검 명령어: VM 내부와 OpenStack 외부를 같이 보기
플레이버가 적절한지 보려면 VM 내부 지표와 OpenStack 외부 상태를 같이 봐야 합니다. VM 안에서는 리눅스 성능 도구를 씁니다. 아래 명령어는 대부분의 리눅스 서버에서 sysstat 패키지를 설치하면 사용할 수 있습니다.
# CPU 사용률과 iowait 확인
sar -u 1 5
# 디스크 서비스 시간, 대기열, 사용률 확인
iostat -x 1 5
# 프로세스별 CPU/메모리/디스크 사용 확인
pidstat -urd 1 5
# 메모리와 swap 확인
free -h
해석은 이렇게 합니다. sar에서 %iowait가 계속 눈에 띄게 높다면 CPU가 부족하다기보다 디스크 응답을 기다리는 쪽을 의심합니다. iostat -x에서는 await, %util, r/s, w/s를 함께 봅니다. %util이 계속 높은데 await도 같이 늘면 스토리지 병목 가능성이 커집니다. free -h에서 swap 사용량이 증가하고 줄지 않는다면 메모리 플레이버를 올리거나 애플리케이션 메모리 설정을 줄여야 합니다.
OpenStack 쪽에서는 현재 하이퍼바이저 자원 상태와 VM 배치를 확인합니다. 일부 명령은 관리자 권한이 필요할 수 있습니다.
openstack hypervisor list
openstack hypervisor stats show
openstack server list --all-projects --long
openstack server show <SERVER_ID>
여기서 보는 핵심은 “한 Compute Node에 특정 유형 VM이 몰렸는가”입니다. CPU 집약형 VM이 한 노드에 너무 몰리면 개별 VM 스펙은 정상이어도 전체 성능이 흔들릴 수 있습니다. 이때는 Availability Zone(가용 영역), Host Aggregate(호스트 집합), Flavor Extra Specs를 조합해서 배치 정책을 나누는 쪽을 검토합니다.
주의사항과 트러블슈팅: 자주 헷갈리는 부분
OpenStack 플레이버 설계에서 가장 많이 하는 실수는 “플레이버 이름만 그럴듯하게 만든 것”입니다. m1.large라는 이름은 익숙하지만, 정작 어떤 워크로드용인지 아무도 모르면 시간이 지나면서 엉망이 됩니다. 그래서 이름에 목적을 넣는 편이 좋습니다. 예를 들면 m1.web.small, m1.db.memory, m1.batch.cpu처럼요.
VM 생성 실패: Extra Specs가 호스트 기능과 맞지 않을 때 발생합니다. flavor show와 nova-compute 로그를 같이 봅니다.
메모리가 부족함: swap이 늘면 체감 성능이 급격히 나빠집니다. RAM 증설 또는 애플리케이션 heap 설정을 조정합니다.
CPU를 많이 줬는데도 느림: CPU steal, iowait, 스레드 병렬성, 애플리케이션 락을 같이 봐야 합니다.
재현 가능한 시나리오 하나를 들어보겠습니다. 웹 서버 VM에 2 vCPU, 4GB RAM을 주고 운영했는데 피크 시간에 응답이 느려졌습니다. 처음에는 CPU가 부족한 줄 알고 4 vCPU로 올렸습니다. 그런데 개선이 애매했습니다. 다시 보니 sar에서 iowait가 계속 보였고, iostat에서는 디스크 대기가 늘어났습니다. 원인은 로그가 같은 루트 디스크에 과하게 쌓이는 구조였고, 별도 볼륨으로 로그 경로를 분리하니 훨씬 안정됐습니다.
검증과 결과: 플레이버 변경 후 확인할 것
플레이버를 바꿨다면 “VM이 켜졌다”에서 끝내면 안 됩니다. 저는 최소한 아래 순서로 확인합니다. 특히 resize 이후에는 환경에 따라 confirm 단계가 필요할 수 있으니 운영 정책도 같이 확인하세요.
VM 생성 또는 resize(크기 변경)가 정상 완료됐는지 확인합니다.
게스트 OS에서 CPU, 메모리, 디스크가 기대한 값으로 보이는지 확인합니다.
애플리케이션 로그에 오류나 타임아웃이 늘지 않았는지 봅니다.
피크 시간대 지표를 이전과 비교합니다.
동일 계열 VM 여러 대의 편차가 크지 않은지 확인합니다.
openstack server resize --flavor m1.api.medium <SERVER_ID>
openstack server resize --confirm <SERVER_ID>
# VM 내부에서 확인
nproc
free -h
lsblk
결과 해석 기준은 간단하게 잡아두면 좋습니다. CPU 사용률이 피크 시간에만 높고 요청 지연이 없다면 굳이 올리지 않아도 됩니다. 메모리는 swap이 생기는지, 디스크는 iowait와 await가 함께 나빠지는지 봅니다. 네트워크는 대역폭뿐 아니라 인터페이스 오류, retransmission(재전송)도 같이 봐야 합니다.
CPU, 메모리, 디스크 I/O 지표를 기준으로 플레이버 변경 전후를 비교하는 검증용 대시보드 예시입니다.
자주 묻는 질문: OpenStack 플레이버 설계 FAQ
Q1. 플레이버는 몇 종류로 시작하는 게 좋나요?
처음부터 너무 많이 만들지 않는 걸 추천합니다. 웹/API용 2~3개, 메모리 중심 1~2개, CPU 중심 1~2개 정도로 시작하고 실제 사용 패턴을 보면서 늘리는 편이 관리하기 쉽습니다.
Q2. dedicated CPU는 무조건 좋은 선택인가요?
아닙니다. 지연 시간에 민감하거나 성능 격리가 중요한 VM에는 도움이 될 수 있지만, 전체 클러스터 효율은 떨어질 수 있습니다. 호스트의 전용 CPU 구성과 운영 정책이 준비된 경우에만 쓰는 게 좋습니다.
Q3. 디스크 크기를 크게 잡으면 성능도 좋아지나요?
대부분의 경우 단순 디스크 용량과 성능은 별개로 봐야 합니다. 성능은 스토리지 백엔드, 볼륨 타입, 캐시 정책, I/O 패턴 영향을 더 많이 받습니다.
마무리: 워크로드별 추천 기준
OpenStack에서 VM 구성을 잘 잡고 싶다면 플레이버를 “사이즈”가 아니라 “운영 정책”으로 봐야 합니다. 이 관점이 잡히면 OpenStack 플레이버 설계가 훨씬 쉬워집니다.
웹/API 서버라면 작은 VM 여러 대와 수평 확장을 우선 추천합니다.
DB 서버라면 메모리, 디스크 I/O, 볼륨 타입을 먼저 보고 필요할 때 전용 CPU를 검토하세요.
배치 작업이라면 실행 시간대와 동시성 기준으로 CPU형 플레이버를 따로 두는 게 좋습니다.
네트워크 장비형 VM이라면 CPU 정책, 인터럽트, 드라이버, 패킷 처리량을 함께 봐야 합니다.
제 기준에서는 기본 플레이버를 작고 명확하게 시작한 뒤, 관측 지표를 보고 계열을 늘리는 방식이 가장 덜 아팠습니다. 한 번에 완벽한 표준안을 만들려고 하면 오히려 오래 걸리더라고요. 다음 글에서는 Host Aggregate와 Availability Zone을 이용해서 특정 플레이버를 특정 Compute Node 그룹에 배치하는 방법을 다룰 예정입니다. 이전 글에서 다룬 OpenStack 네트워크 기본 구조도 함께 참고하면 흐름이 더 잘 이어질 겁니다.
웹, DB, 배치, 네트워크형 VM을 어떤 기준으로 나눌지 한눈에 정리한 요약 이미지입니다.
OpenStack Ceph 성능 장애는 보통 아주 평범한 증상으로 시작합니다. 인스턴스 부팅이 길어지고, 볼륨 attach가 가끔 멈칫하고, Glance 이미지 업로드가 어느 날부터 오래 걸리죠. 사용자 입장에서는 전부 VM 디스크가 느리다고 느끼지만, 운영자 입장에서는 Ceph OSD가 느린지, OpenStack 서비스가 RBD를 제대로 쓰는지, compute node 네트워크가 막히는지, recovery/backfill이 정상적으로 자원을 쓰는지까지 같이 봐야 합니다.
저는 OpenStack과 Ceph를 같이 볼 때 튜닝값을 먼저 만지지 않는다는 원칙을 꽤 강하게 지킵니다. 특히 운영 환경에서는 osd_max_backfills, osd_recovery_max_active, rbd_cache 같은 값을 감으로 바꾸면 일시적으로 숫자는 좋아져도 장애 반경이 넓어질 수 있거든요. 먼저 병목 위치를 좁히고, 그다음에 설정을 조정해야 합니다.
이 글은 공식 문서식 옵션 나열이 아니라, 실제 장애 대응 순서에 가깝게 구성했습니다. 느리다는 말을 들었을 때 어떤 명령어를 먼저 치고, 어떤 로그를 같이 열고, 어떤 경우에는 Ceph가 아니라 Nova/Cinder/Glance를 의심해야 하는지에 초점을 맞춥니다.
OpenStack Nova, Cinder, Glance가 Ceph RBD 풀과 연결되는 구조를 한눈에 보는 개요 이미지입니다.
OpenStack에서 Ceph 병목이 헷갈리는 이유
OpenStack은 Ceph를 단순한 외장 스토리지처럼 쓰지 않습니다. Nova는 VM ephemeral disk를 RBD에 둘 수 있고, Cinder는 volume을 RBD image로 만들고, Glance는 base image를 Ceph pool에 저장할 수 있습니다. 이 셋이 같은 Ceph 클러스터를 쓰더라도 병목 지점은 서로 다릅니다.
Nova 병목: VM 생성, 부팅, live migration, libvirt secret, compute node의 RBD 접속 경로에서 드러납니다.
Ceph 병목: OSD latency, PG 상태, recovery/backfill, full/nearfull, 네트워크 손실, CRUSH 배치 문제로 드러납니다.
현장에서 자주 본 실패 패턴은 HEALTH_OK니까 Ceph는 아니라고 너무 빨리 결론 내리는 경우였습니다. HEALTH_OK는 클러스터의 일관성과 위험 상태를 보는 신호에 가깝지, 모든 OSD가 빠르고 모든 클라이언트 경로가 정상이라는 보장은 아닙니다. 반대로 HEALTH_WARN이 있어도 실제 사용자 지연의 직접 원인은 libvirt secret 불일치일 수 있습니다. 그래서 Ceph와 OpenStack을 항상 나란히 봐야 합니다.
Ceph 병목을 잡는 첫 10분: 범위를 먼저 자르세요
처음부터 fio를 돌리거나 설정값을 바꾸지 마세요. 저는 먼저 영향을 받는 범위를 세 가지 질문으로 자릅니다.
모든 VM이 느린가, 특정 compute node의 VM만 느린가?
볼륨 작업만 느린가, 이미지 부팅과 업로드도 같이 느린가?
Ceph에서 recovery/backfill/scrub 같은 내부 작업이 돌고 있는가?
이 질문에 답하면 조사 방향이 빨라집니다. 전체 VM이 느리면 Ceph cluster, OSD, 네트워크를 봅니다. 특정 compute node만 느리면 해당 노드의 ceph.conf, keyring, libvirt secret, NIC 오류를 먼저 봅니다. 볼륨 생성만 느리면 Cinder backend와 volumes pool을 봐야지 Nova 설정부터 만지는 건 순서가 아닙니다.
# 컨트롤러 또는 Ceph admin 노드에서 1차 확인
ceph -s
ceph health detail
ceph osd tree
ceph osd df tree
ceph pg stat
ceph osd perf
ceph osd pool stats
# OpenStack 관점에서 영향 범위 확인
openstack server list --all-projects --long
openstack volume list --all-projects --long
openstack image list --long
openstack hypervisor list
openstack compute service list
openstack volume service list
ceph -s에서 recovery, backfill, degraded, undersized, peering 같은 단어가 보이면 성능 저하가 자연스럽게 따라올 수 있습니다. 이때 중요한 건 왜 그런 상태가 됐는지입니다. OSD 하나가 내려갔는지, 디스크 교체 후 재분산 중인지, full ratio에 가까운 OSD가 있는지, 네트워크가 흔들렸는지까지 연결해서 봐야 합니다.
Ceph OSD 지연은 단독 숫자가 아니라 편차로 봅니다
ceph osd perf는 OSD별 commit/apply latency를 보여줍니다. 여기서 가장 위험한 해석은 몇 ms 이상이면 무조건 장애처럼 외부 숫자를 그대로 가져오는 겁니다. HDD, SSD, NVMe, replication size, network, BlueStore DB/WAL 구성에 따라 정상 범위가 달라집니다. 대신 같은 장비군에서 특정 OSD만 지속적으로 튀는지, latency 상승과 iostat의 대기열 증가가 같이 움직이는지를 봐야 합니다.
# Ceph 쪽 편차 확인
ceph osd perf
ceph osd df tree
ceph osd pool stats
# 특정 OSD 호스트에서만 확인합니다. admin socket이 있는 노드에서 실행해야 합니다.
ceph daemon osd.0 perf dump | less
# 운영 중 bench 명령은 부하를 만들 수 있으니 점검 창에서만 사용하세요.
ceph tell osd.0 bench
# OSD 호스트에서 디스크와 CPU 확인
iostat -x 1
sar -n DEV 1
sar -u 1
vmstat 1
journalctl -k --since '1 hour ago'
iostat -x에서는 await, aqu-sz, %util, r_await, w_await를 같이 봅니다. %util이 높고 aqu-sz가 커지면서 await도 같이 오르면 디스크 대기열이 밀리는 그림입니다. 반대로 디스크는 한가한데 Ceph latency만 높다면 네트워크, CPU, OSD 프로세스, RocksDB/WAL 장치, 또는 클라이언트 경로를 더 봐야 합니다.
특정 OSD만 튄다면 바로 out 처리하기보다 먼저 원인을 확인하세요. 커널 로그에 I/O error가 있으면 디스크/컨트롤러 쪽 가능성이 커지고, NIC drop이 같이 보이면 네트워크 쪽입니다. OSD가 있는 호스트의 CPU steal이나 softirq가 높으면 스토리지 문제가 아니라 호스트 자원 경합일 수 있습니다.
OSD latency, iostat, 네트워크 지표를 나란히 비교하며 병목 지점을 좁히는 장면입니다.
Nova, Cinder, Glance 설정은 같은 Ceph를 보는가부터 확인합니다
OpenStack Ceph 연동에서 의외로 많은 문제는 Ceph 성능이 아니라 설정 일관성에서 생깁니다. Glance는 Ceph RBD에 이미지를 저장하는데 Nova는 로컬 파일 기반으로 부팅한다든지, Cinder와 Nova가 서로 다른 user/keyring을 본다든지, compute node마다 /etc/ceph/ceph.conf 내용이 다른 식입니다. 이거 진짜 자주 나옵니다.
rbd_flatten_volume_from_snapshot = false는 clone 기반 흐름을 살려 생성 속도를 빠르게 가져갈 수 있지만, clone depth가 깊어지면 나중에 읽기 경로가 복잡해질 수 있습니다. rbd_max_clone_depth는 그 균형점입니다. 볼륨 생성 속도가 중요하고 snapshot 계층이 잘 관리된다면 clone을 적극적으로 쓰는 편이 유리합니다. 반대로 오래된 snapshot에서 파생된 볼륨이 많이 쌓이고 삭제 정책이 느슨한 환경이라면 flatten 전략을 더 보수적으로 잡아야 합니다.
rbd_secret_uuid는 libvirt secret과 정확히 맞아야 합니다. 예시 UUID를 그대로 쓰면 안 됩니다. 실제 compute node에서 virsh secret-list와 virsh secret-dumpxml로 확인해야 합니다. rbd_volume_local_attach는 RBD Cinder volume을 QEMU의 native RBD 경로가 아니라 compute host의 block device로 붙이는 Nova workaround 옵션입니다. 기본값처럼 false로 두는 구성이 일반적이지만, 배포판과 암호화 볼륨 요구사항에 따라 판단해야 합니다.
Glance를 RBD에 두면 Nova가 base image를 clone하는 흐름을 만들기 쉬워집니다. 다만 이미지 변환이 필요한 포맷을 무분별하게 올리면 업로드나 부팅 경로에서 예기치 않은 지연이 생길 수 있습니다. 운영 기준으로는 Glance 이미지 포맷, Nova images_type, Cinder backend가 한 방향으로 맞아야 합니다. 이미지 저장소는 file, VM은 rbd, volume은 rbd처럼 섞인 구성이 꼭 틀린 건 아니지만, 장애 때 확인해야 할 경로가 늘어납니다.
서비스 계정으로 직접 Ceph에 붙어보면 빠르게 걸러집니다
운영자가 admin keyring으로 ceph -s를 쳐서 성공하는 것과 Nova/Cinder/Glance가 자기 계정으로 RBD pool에 접근하는 것은 완전히 다른 이야기입니다. 장애 대응 때는 반드시 서비스 계정으로 직접 확인해보는 편이 좋습니다.
# compute node에서 Nova 계정 확인
ceph -n client.nova --keyring /etc/ceph/ceph.client.nova.keyring -s
rbd -n client.nova --keyring /etc/ceph/ceph.client.nova.keyring -p vms ls
# cinder-volume 노드에서 Cinder 계정 확인
ceph -n client.cinder --keyring /etc/ceph/ceph.client.cinder.keyring -s
rbd -n client.cinder --keyring /etc/ceph/ceph.client.cinder.keyring -p volumes ls
# glance-api 노드에서 Glance 계정 확인
ceph -n client.glance --keyring /etc/ceph/ceph.client.glance.keyring -s
rbd -n client.glance --keyring /etc/ceph/ceph.client.glance.keyring -p images ls
# libvirt secret 확인
virsh secret-list
virsh secret-dumpxml 00000000-0000-0000-0000-000000000000
여기서 실패하면 Ceph 튜닝은 잠시 내려놓고 인증과 권한을 봐야 합니다. 흔한 원인은 keyring 파일 경로 불일치, 파일 권한, CephX caps 부족, secret UUID 오타, 배포 자동화가 일부 노드에만 반영된 경우입니다. 특히 compute node가 여러 대일 때는 문제 없는 노드와 느린 노드의 /etc/ceph 디렉터리, Nova 설정, libvirt secret을 비교하면 빠릅니다.
스토리지 트러블슈팅을 위한 병목 유형별 판단 기준
아래 표는 실제 점검할 때 쓰는 분류에 가깝습니다. 한 줄짜리 정답표는 아니지만, 어디부터 볼지 정하는 데는 꽤 도움이 됩니다.
증상
같이 볼 지표
가능성이 큰 원인
먼저 할 조치
피해야 할 대응
전체 VM 디스크 I/O가 느림
ceph -s, ceph osd perf, iostat -x
OSD 지연, recovery/backfill, 네트워크 혼잡
느린 OSD와 내부 작업 여부를 먼저 분리
Nova 설정부터 무작정 변경
특정 compute node의 VM만 느림
sar -n DEV, journalctl -u nova-compute, virsh secret-list
compute node 네트워크, keyring, libvirt secret
정상 노드와 ceph.conf/keyring/secret 비교
Ceph 클러스터 전체 재시작
볼륨 생성·삭제가 오래 걸림
Cinder 로그, ceph osd pool stats, RBD clone depth
Cinder backend 부하, snapshot/clone 누적, pool 병목
Cinder service 상태와 volumes pool I/O 확인
사용자 VM fio 테스트로만 판단
이미지 업로드나 첫 부팅이 느림
Glance 로그, image format, Nova images_type
Glance 저장소 경로, 이미지 변환, RBD clone 미사용
Glance default store와 Nova RBD 설정 일관성 확인
OSD 교체부터 검토
평소에는 괜찮다가 특정 시간대만 느림
scrub/deep-scrub, backup, snapshot 작업 로그
예약 작업과 클라이언트 I/O 경합
작업 시간대와 Ceph 내부 작업 스케줄 조정
일시 현상으로 방치
Ceph 최적화 튜닝값은 목적별로 다르게 접근해야 합니다
Ceph 성능 글에서 자주 보이는 실수는 이 값을 올리면 빨라진다는 식의 단정입니다. 실제 운영에서는 값 하나가 성능, 복구 속도, 사용자 I/O 안정성을 동시에 흔듭니다. 특히 OpenStack은 사용자 VM이 계속 I/O를 내고 있으므로, 복구를 빠르게 끝내는 것과 사용자 지연을 줄이는 것 사이에서 선택해야 합니다.
결정 지점
A를 선택할 때
B를 선택할 때
운영 판단
recovery/backfill 속도
장애 복구를 빨리 끝내야 할 때
업무 시간 사용자 I/O를 보호해야 할 때
업무 시간에는 보수적으로, 점검 창에서는 적극적으로 조정
Glance RBD 사용
Nova/Cinder도 Ceph를 쓰고 이미지 clone 경로를 단순화하고 싶을 때
이미지 저장소를 별도로 운영하고 Ceph 부하를 분리하고 싶을 때
Ceph 기반 OpenStack은 Glance도 RBD로 맞추면 운영이 단순해지는 경우가 많습니다
pool 분리
images, vms, volumes의 성격과 장애 분석을 나누고 싶을 때
작은 테스트 환경이라 관리 단순성이 더 중요할 때
운영 환경에서는 최소한 images/vms/volumes는 분리하는 쪽을 권합니다
SSD/NVMe 혼합
워크로드별 CRUSH rule과 pool을 나눌 수 있을 때
장비 수가 적고 장애 도메인이 충분하지 않을 때
빠른 디스크를 섞기만 하면 평균이 좋아지는 게 아니라 예측성이 나빠질 수 있습니다
제가 겪은 대표 삽질: Ceph는 멀쩡한데 VM만 느린 경우
한 번은 ceph -s가 멀쩡하고 OSD latency도 크게 튀지 않는데, 특정 compute node의 VM만 디스크가 굼뜨게 느껴진 적이 있습니다. 처음에는 Ceph 최적화 문제라고 생각했습니다. 그런데 정상 노드와 문제 노드를 비교해보니 /etc/ceph/ceph.conf 배포 시점이 달랐고, libvirt secret도 서로 맞지 않았습니다.
이런 경우에는 Ceph dashboard만 보면 놓칩니다. Ceph는 정상인데, OpenStack 서비스 계층에서 RBD를 제대로 잡지 못하는 상태이기 때문입니다. 저는 이런 케이스 이후로 compute node 단위 문제가 나오면 아래 명령을 거의 습관처럼 칩니다.
정상 노드와 문제 노드의 sha256sum이 다르면 배포 일관성부터 의심합니다. 물론 Ceph 설정 파일이 일부러 다를 수도 있지만, OpenStack compute node에서 의도치 않게 다른 MON 주소나 keyring을 보고 있다면 성능 문제가 아니라 구성 문제입니다. 이때는 튜닝보다 재배포와 서비스 재시작 순서를 차분히 잡는 게 낫습니다.
네트워크 병목은 대역폭보다 손실과 재전송을 먼저 봅니다
Ceph는 네트워크에 민감합니다. 그런데 운영자가 10GbE니까 괜찮겠지라고 생각하는 순간이 위험합니다. 대역폭이 충분해도 packet drop, MTU 불일치, bonding 설정 문제, 스위치 buffer 이슈가 있으면 RBD 클라이언트 입장에서는 지연으로 보입니다.
# OSD/compute node에서 NIC 오류와 처리량 확인
ip -s link
netstat -s | grep -Ei 'retrans|timeout|listen|segments retransmitted'
sar -n DEV 1
sar -n TCP,ETCP 1
# 경로와 MTU 확인
ip route
ip addr show
ping -M do -s 8972 CEPH_OSD_IP
MTU 9000을 쓰는 환경이라면 end-to-end로 맞아야 합니다. compute node, storage node, 스위치, bond, VLAN 어디 하나라도 다르면 큰 패킷이 깨지거나 경로에 따라 묘한 지연이 생깁니다. Jumbo frame은 제대로 맞추면 도움이 될 수 있지만, 반쯤 적용된 jumbo frame은 차라리 기본 MTU보다 나쁩니다. 저는 운영 안정성이 먼저인 환경에서는 모든 구간을 검증할 수 있을 때만 jumbo frame을 쓰는 쪽을 선호합니다.
검증은 고쳤다가 아니라 재현 조건에서 나아졌다로 해야 합니다
수정 후에는 단순히 HEALTH_OK만 보고 끝내지 않습니다. 같은 증상이 났던 경로를 다시 밟아야 합니다. 이미지 업로드가 문제였으면 Glance 경로를, 볼륨 attach가 문제였으면 Cinder와 Nova attach 경로를, 특정 compute node가 문제였으면 그 노드에서 새 VM을 띄워 봐야 합니다.
# Ceph 상태 재확인
ceph -s
ceph health detail
ceph osd perf
ceph osd pool stats
# RBD pool 확인
rbd -p images ls
rbd -p volumes ls
rbd -p vms ls
# OpenStack 리소스 흐름 확인
openstack image list --long
openstack volume list --all-projects --long
openstack server list --all-projects --long
# 최근 로그에서 timeout/auth/error 확인
journalctl -u nova-compute --since '30 minutes ago' | grep -Ei 'rbd|ceph|timeout|error|auth|secret'
journalctl -u cinder-volume --since '30 minutes ago' | grep -Ei 'rbd|ceph|timeout|error|auth'
journalctl -u glance-api --since '30 minutes ago' | grep -Ei 'rbd|ceph|timeout|error|auth'
운영 환경에서 무리한 쓰기 부하 테스트를 바로 돌리는 건 권하지 않습니다. 먼저 작은 테스트 VM과 테스트 볼륨으로 재현 경로를 확인하고, 업무 영향이 낮은 시간대에 점진적으로 부하를 올리는 편이 안전합니다. 스토리지는 한 번 흔들리면 넓게 흔들리는 영역이라서, 확인도 단계적으로 해야 합니다.
Nova, Cinder, Glance 서비스가 각각 vms, volumes, images 풀을 사용하는 구성을 보여주는 이미지입니다.
운영 체크리스트: 성능보다 먼저 무너지는 것들
pool 분리: 운영 환경에서는 images, vms, volumes pool을 분리해 원인 분석과 정책 적용을 쉽게 만듭니다.
CRUSH rule 확인: HDD, SSD, NVMe가 섞인 환경에서는 장치 class와 rule이 의도대로 적용되는지 확인합니다.
시간 동기화: 모든 컨트롤러, compute, storage node에서 chrony 또는 NTP 상태를 확인합니다.
복구 작업 정책: 업무 시간과 점검 시간의 recovery/backfill 정책을 다르게 가져갈지 결정합니다.
로그 보존: nova-compute, cinder-volume, glance-api, libvirt 또는 virtqemud, kernel 로그가 충분히 남도록 설정합니다.
배포 일관성: ceph.conf, keyring, libvirt secret이 모든 관련 노드에 동일하게 배포되는지 검증합니다.
여기서 제일 많이 과소평가되는 항목은 배포 일관성입니다. Ceph 자체가 아무리 튼튼해도 compute node 한 대가 오래된 ceph.conf를 보고 있으면 사용자에게는 OpenStack Ceph 성능 문제로 접수됩니다. 자동화 도구를 쓰더라도 실제 파일 checksum을 비교하는 습관이 도움이 됩니다.
Ceph health, OSD latency, OpenStack 리소스 상태가 안정화된 모습을 보여주는 검증 이미지입니다.
증상별 추천 경로: 이럴 땐 이렇게 보세요
모든 VM이 동시에 느려졌다면 Ceph cluster 상태, OSD latency, recovery/backfill, 네트워크 손실을 먼저 봅니다. 이 경우에는 개별 VM 안에서 fio를 오래 돌리는 것보다 클러스터 전체 지표를 보는 편이 빠릅니다.
특정 compute node의 VM만 느리다면 Ceph 전체 튜닝보다 해당 노드의 네트워크, /etc/ceph 파일, Nova 설정, libvirt secret을 먼저 비교하세요. 정상 노드와 문제 노드의 차이를 찾는 방식이 가장 빠릅니다.
볼륨 생성·삭제·attach만 느리다면 Cinder volume 서비스와 volumes pool을 봅니다. snapshot/clone이 많이 쌓인 환경이라면 clone depth와 flatten 정책도 같이 봐야 합니다.
이미지 업로드나 첫 부팅만 느리다면 Glance 저장소, 이미지 포맷, Nova의 RBD 사용 여부를 확인합니다. Glance와 Nova가 같은 Ceph 기반 흐름을 쓰지 않으면 불필요한 복사나 변환 경로가 끼어들 수 있습니다.
특정 시간대만 느리다면 백업, snapshot, scrub/deep-scrub, recovery 작업 시간표를 확인하세요. 이 경우에는 하드웨어 증설보다 작업 스케줄과 우선순위 조정이 먼저일 수 있습니다.
자주 묻는 질문
Q. OpenStack Ceph 성능 문제는 Ceph 튜닝으로 해결되나요?
항상 그렇지는 않습니다. 실제 현장에서는 Nova/Cinder/Glance 설정 불일치, compute node 네트워크, libvirt secret, keyring 권한 문제가 꽤 많습니다. Ceph 튜닝은 병목이 Ceph 내부에 있다는 근거를 잡은 뒤에 하는 게 안전합니다.
Q. OSD latency가 높으면 바로 디스크 교체인가요?
바로 교체로 가기보다는 특정 OSD만 반복적으로 튀는지, 해당 호스트의 iostat, 커널 로그, NIC 오류, recovery 상태가 같이 움직이는지 봐야 합니다. 디스크 고장일 수도 있지만 네트워크 손실이나 복구 작업 영향일 수도 있습니다.
Q. Glance도 꼭 Ceph RBD를 써야 하나요?
필수는 아닙니다. 다만 Nova와 Cinder가 Ceph를 쓰는 구조라면 Glance도 RBD에 두는 구성이 운영과 장애 분석 측면에서 단순해지는 경우가 많습니다. 특히 이미지 clone 경로를 활용하고 싶다면 세 서비스의 저장 경로를 함께 설계하는 편이 좋습니다.
Q. pool을 꼭 images, vms, volumes로 나눠야 하나요?
작은 테스트 환경에서는 하나로도 돌아갑니다. 운영 환경에서는 분리하는 쪽을 권합니다. 워크로드 성격이 다르고, 장애 분석과 용량 정책, 권한 설정, 향후 CRUSH rule 적용이 쉬워지기 때문입니다.
관련 글로는 OpenStack Nova 트러블슈팅, Cinder 백엔드 설계, Ceph CRUSH rule 운영 가이드를 함께 연결해두면 독자가 다음 점검 단계로 이동하기 좋습니다.
증상별로 Ceph, OpenStack 서비스, 네트워크, 디스크 중 어디를 먼저 확인할지 정리한 요약 이미지입니다.
마지막 판단: 먼저 좁히고, 그다음에 바꾸세요
OpenStack Ceph 성능 문제를 다룰 때 제 추천은 분명합니다. 전체가 느리면 Ceph cluster와 OSD부터, 특정 compute node만 느리면 해당 노드의 RBD 접속 경로부터, 볼륨만 느리면 Cinder와 volumes pool부터, 이미지 부팅만 느리면 Glance와 Nova RBD 연결부터 보세요.
설정값 변경은 마지막 카드에 가깝습니다. ceph -s, ceph osd perf, iostat -x, 서비스 계정 RBD 접근 테스트, Nova/Cinder/Glance 로그를 통해 병목 위치를 먼저 좁히면 불필요한 튜닝을 줄일 수 있습니다. 운영에서 좋은 트러블슈팅은 멋진 한 방이 아니라, 잘못된 가능성을 빠르게 제거하는 과정에 더 가깝습니다.
OpenStack Ceph 마이그레이션을 검토할 때 저는 늘 같은 질문부터 던집니다. "지금 바꾸면 뭐가 좋아지고, 대신 무엇을 새로 운영해야 하나"라는 질문이죠. 핵심은 단순한 저장소 교체가 아니라 운영 모델의 변경입니다. Cinder 볼륨만 옮길지, Glance 이미지 저장소까지 묶을지, Nova의 에페메럴 디스크까지 Ceph RBD로 정리할지에 따라 난이도와 장애 반경이 완전히 달라지거든요. 실제 운영에서는 성능 수치보다 스케줄링 일관성, Ceph 재배치 부담, 인증 권한, 롤백 가능성이 더 자주 발목을 잡습니다.
이 글은 OpenStack과 Ceph의 일반적인 운영 패턴을 기준으로 정리했습니다. 특정 벤더 확장 기능이나 과장된 수치 없이, 현장에서 일정 잡을 때 실제로 보는 판단 기준과 절차만 남겼습니다. 한 줄로 줄이면 이렇습니다. 기존 백엔드를 덮어쓰지 말고, 새 백엔드를 병행 등록한 뒤 신규 유입과 기존 자산 이동을 분리해서 진행하는 편이 안전합니다. 관련해서 볼륨 타입 설계나 Ceph 풀 설계 글도 함께 보시면 운영 그림이 훨씬 빨리 잡힙니다.
OpenStack 서비스 계층과 Ceph 풀(pool) 구조, 데이터 이동 흐름을 한눈에 보여주는 개요 이미지입니다.
1. OpenStack Ceph 마이그레이션을 고민하는 대표적인 이유
운영 현장에서는 보통 "Ceph가 좋아 보여서"가 아니라 아래 같은 이유로 움직입니다.
풀 구조가 성장 패턴을 못 따라갈 때: 같은 풀에 서로 다른 I/O 성격의 볼륨이 섞이면 운영 판단이 흐려집니다.
볼륨 타입 정책을 분리해야 할 때: 테넌트별, 워크로드별, 복제 정책별로 다른 백엔드가 필요해집니다.
증설과 장애 대응의 표준화가 필요할 때: 하드웨어별 절차보다 Ceph 기준으로 운영 일관성을 맞추고 싶을 때가 많습니다.
기존 백엔드가 OpenStack 스케줄러와 잘 안 맞을 때: 사용자는 타입을 골랐는데 실제 배치가 정책대로 안 되는 경우가 반복됩니다.
제가 실무에서 특히 중요하게 보는 건 "왜 옮기느냐"보다 어디까지 옮기느냐입니다. Cinder만 옮기면 블록 스토리지 정책 문제로 한정되지만, Glance까지 함께 들어가면 이미지 캐시와 부팅 경로가 바뀝니다. Nova 에페메럴까지 손대는 순간부터는 스토리지 변경이라기보다 컴퓨트 설계 변경에 가깝습니다.
2. OpenStack Ceph 마이그레이션 결정 기준은 성능보다 운영 책임입니다
Ceph 도입 여부를 성능 하나로만 판단하면 나중에 꼬이기 쉽습니다. 더 정확한 질문은 이겁니다. "이 팀이 Ceph의 재배치, 권한, 풀 정책, 장애 메시지를 자기 책임으로 읽고 운영할 준비가 됐는가"예요. 이 기준이 생각보다 훨씬 현실적입니다.
판단 항목
기존 유지가 더 나은 경우
Ceph 전환이 더 나은 경우
실무 체크 포인트
운영 복잡도
현재 절차가 단순하고 장애 대응 경로가 고정돼 있음
확장, 복제, 장애 도메인 관리를 한 체계로 묶고 싶음
클라우드 팀이 Ceph 경고 메시지와 재배치 상태를 직접 해석할 수 있는지
볼륨 타입 정책
사실상 단일 티어로도 충분함
테넌트/업무군별로 다른 풀과 정책이 필요함
volume_backend_name, extra_specs, 타입 명명 규칙을 먼저 설계했는지
장애 허용 구조
외부 스토리지가 이미 안정적으로 이중화됨
CRUSH 규칙과 failure domain을 직접 설계할 가치가 있음
복제 단위가 host인지 rack인지, 기존 가용영역 설계와 충돌하지 않는지
마이그레이션 방식
짧은 점검창도 확보하기 어려움
신규/기존을 분리하고 몇 주에 걸쳐 점진 전환 가능
붙어 있는(in-use) 볼륨의 정책 변경 허용 여부와 드라이버 지원 범위
운영 비용
전담 인력이 없고 스토리지 운영을 단순화해야 함
학습 비용을 들여도 장기적으로 통합 운영 이득이 큼
모니터링, 알림, 장애 복구 문서가 Ceph 기준으로 이미 준비됐는지
짧게 정리하면 이렇습니다. 볼륨 타입 분리와 점진 전환이 필요하면 Ceph 쪽이 유리하고, 운영 역량이 아직 약하면 기존 백엔드를 남겨둔 병행 운영이 맞습니다. 반대로 다운타임 제로만 바라보면서 한 번에 덮어쓰는 방식은 실무에서 꽤 위험하더라고요.
3. OpenStack 스토리지 교체 범위를 자르면 난이도가 확 줄어듭니다
OpenStack 스토리지 교체는 기술 문제라기보다 범위 관리 문제인 경우가 많습니다. 보통 아래 셋으로 끊습니다.
Cinder 볼륨만 전환: 가장 현실적이고, 실패해도 영향 반경을 제한하기 쉽습니다.
Glance 이미지까지 전환: 이미지 업로드, 캐시, 부팅 경로를 함께 봐야 합니다.
Nova 에페메럴 디스크까지 전환: 성능과 일관성 이득은 크지만 컴퓨트 노드 영향이 급격히 커집니다.
제가 추천하는 순서는 거의 같습니다. Cinder -> Glance -> Nova예요. 이유는 단순합니다. Cinder는 볼륨 타입이라는 절연층이 있지만, Nova 루트/에페메럴까지 한 번에 건드리면 인스턴스 부팅 실패가 곧바로 서비스 장애로 번지기 쉽습니다.
실무에서 자주 보는 장면도 있습니다. 기존에는 외부 SAN을 쓰다가 "이번에 Ceph도 붙였으니 볼륨도 이미지도 같이 넘기자"고 범위를 넓히는 경우죠. 이때 Cinder 신규 볼륨은 정상 생성되는데, 부팅 지연이나 이미지 캐시 미스 때문에 운영팀이 Glance 문제를 Ceph 문제로 오해하는 일이 꽤 많습니다. 그래서 저는 첫 전환 주기에는 신규 볼륨 경로와 이미지 경로를 일부러 분리합니다. 원인 분리가 정말 편해집니다.
4. OpenStack Ceph 마이그레이션 사전 점검
이 단계는 체크리스트라기보다 진입 금지선에 가깝습니다. 상태가 좋지 않으면 일정부터 미루는 편이 맞습니다. 마이그레이션 자체보다, 진행 중 나타난 문제의 원인이 Ceph인지 OpenStack인지 분리하기 어려워지기 때문입니다.
ceph -s
ceph health detail
ceph osd stat
ceph osd tree
ceph osd df tree
ceph osd pool ls detail
rados df
openstack volume service list
openstack volume type list --long
openstack volume list --status in-use --long
여기서는 보통 이렇게 읽습니다.
ceph -s: 클러스터 전체 상태와 recovery/backfill 진행 여부를 먼저 봅니다. 단순 HEALTH_WARN보다 경고 원인이 재배치인지 용량 임계치인지가 더 중요합니다.
ceph health detail: degraded, undersized, inactive, nearfull 계열 메시지가 보이면 이동 작업을 미룹니다.
ceph osd df tree: 특정 OSD만 유독 가득 찼다면 마이그레이션 중 backfill이 겹치면서 체감 성능이 흔들릴 가능성이 큽니다.
ceph osd pool ls detail: 새 풀의 복제 정책, CRUSH rule, autoscale 상태를 봅니다. 풀 이름만 맞고 규칙이 다르면 기대한 장애 도메인이 깨질 수 있습니다.
openstack volume service list: 대상 cinder-volume 서비스가 up이고 enabled인지 확인합니다.
openstack volume type list --long: 현재 타입과 백엔드 이름 연결이 살아 있는지 확인합니다.
openstack volume list --status in-use --long: 붙어 있는 볼륨 비중이 높다면 온라인 정책 변경이 가능한지부터 따져야 합니다.
실제 실패 모드도 비슷합니다. 새 타입은 잘 만들었는데 Ceph 쪽에서 이미 backfill이 길게 돌고 있던 상황이죠. OpenStack API는 성공으로 보이는데 사용자는 I/O 지연을 바로 체감합니다. OpenStack의 성공 응답이 Ceph 내부 재배치 비용까지 끝났다는 뜻은 아니라는 점, 이 부분은 꼭 분리해서 봐야 합니다.
Ceph 클러스터 헬스 체크, 풀 상태, Cinder 볼륨 타입과 백엔드 이름 매핑 관계를 설명하는 이미지입니다.
5. 백엔드 설계는 pool보다 volume type을 먼저 잡아야 합니다
운영에서 더 오래 가는 설계는 "풀 이름 중심"이 아니라 볼륨 타입 중심입니다. 사용자는 타입을 고르고, Cinder 스케줄러는 타입의 extra_specs를 보고 백엔드를 고르거든요. 그래서 이름 규칙이 중요합니다.
백엔드 섹션 이름: 운영자가 구분하기 쉬운 내부 이름
volume_backend_name: 타입과 연결되는 스케줄링 식별자
Ceph 풀 이름: 실제 데이터가 놓이는 물리적 대상
많이 헷갈리는 지점이 하나 있습니다. [rbd-new] 같은 설정 섹션 이름과 volume_backend_name=rbd-new는 같은 개념이 아닙니다. 우연히 같게 맞출 수는 있지만, 스케줄러가 직접 참조하는 값은 섹션명이 아니라 백엔드 이름입니다. 여기 오타가 나면 타입은 멀쩡해 보여도 No valid host 오류가 나기 쉽습니다.
현재 Cinder 샘플 설정에서도 공통 백엔드 옵션은 [backend_defaults] 섹션을 사용합니다. 여기서 중요한 건 세 가지예요. enabled_backends에 백엔드 섹션이 모두 들어가 있는지, 각 섹션의 volume_backend_name이 타입의 extra_specs와 정확히 일치하는지, 공통 설정을 쓴다면 [backend_defaults]와 개별 섹션의 덮어쓰기 관계를 이해하고 있는지입니다.
기존 단일 백엔드 서비스에 다중 백엔드를 붙이는 경우, Cinder 서비스 호스트명이 host에서 host@backend 형태로 바뀌는 환경도 있습니다. 이런 경우 기존 볼륨의 host 메타데이터를 갱신하지 않으면 운영이 꼬일 수 있어서, 사전에 cinder-manage volume update_host 대상 여부를 꼭 확인하는 편이 좋습니다.
5-2. Ceph 풀과 인증 준비
새 풀만 만들고 끝내면 안 됩니다. RBD로 쓸 풀은 초기화와 권한까지 맞아야 합니다. 저는 신규 백엔드를 붙이기 전에 아래 항목을 먼저 확인합니다.
근본 원인은 늘 비슷합니다. 풀은 만들었는데 rbd pool init이 빠졌거나, client.cinder가 새 풀에 대한 cap을 갖고 있지 않거나, Glance와 Cinder 권한을 뭉뚱그려 잡아두는 식이죠. 이런 상태에선 볼륨 생성은 되는데 attach에서 실패하거나, 이미지 기반 볼륨 생성만 유독 실패하는 식으로 증상이 갈라집니다.
5-3. 새 볼륨 타입 생성
openstack volume type create ceph-rbd-new
openstack volume type set --property volume_backend_name=rbd-new ceph-rbd-new
openstack volume type show ceph-rbd-new
openstack volume type list --long
운영상 의미는 명확합니다. 신규 생성 경로를 먼저 새 백엔드로 돌리고, 기존 자산 이동은 그다음에 따로 한다는 거예요. 이 분리가 되면 실패했을 때 되돌리기도 쉬워집니다.
6. OpenStack Ceph 마이그레이션 절차: 신규 유입과 기존 자산을 분리하세요
실무 절차는 의외로 단순합니다. 대신 순서를 어기면 비용이 바로 커집니다.
새 백엔드를 등록하고 타입을 만든다: 아직 기존 타입은 그대로 둡니다.
신규 볼륨만 새 타입으로 생성하게 유도한다: 새 데이터 유입을 먼저 분리합니다.
테스트 프로젝트에서 생성, attach, detach, 삭제까지 한 사이클을 검증한다: 생성만 확인하면 부족합니다.
저위험 볼륨부터 정책 변경 또는 마이그레이션을 시작한다: 백업성 볼륨, 비핵심 업무부터 갑니다.
Ceph 재배치 상태를 보며 배치를 늘린다: API 성공률이 아니라 클러스터 안정성을 기준으로 속도를 조절합니다.
기존 타입의 신규 생성을 막는다: 잔여 볼륨만 남기고 정리 단계로 들어갑니다.
CLI는 환경에 따라 조금씩 다르게 씁니다. 현재 openstackclient에서는 볼륨 타입 변경을 openstack volume set --type로 수행할 수 있고, 일부 운영 환경은 여전히 cinder retype를 사용합니다. 핵심은 명령 이름보다 정책 변경이 실제 데이터 이동을 유발하는지를 테스트 볼륨으로 먼저 확인하는 겁니다.
# 현재 openstackclient 계열에서 많이 쓰는 방식
openstack volume set \
--type ceph-rbd-new \
--migration-policy on-demand \
8f1f2f0d-1111-2222-3333-444444444444
openstack volume show 8f1f2f0d-1111-2222-3333-444444444444
# 환경에 따라 여전히 사용하는 cinder client 방식
cinder retype \
--migration-policy on-demand \
8f1f2f0d-1111-2222-3333-444444444444 \
ceph-rbd-new
관리자가 목적지를 더 강하게 통제해야 한다면 백엔드 호스트를 직접 지정하는 방식도 씁니다.
저는 보통 이렇게 고릅니다. 볼륨 타입 정책까지 함께 정리하려면 retype 계열이 낫고, 특정 백엔드 호스트나 풀을 명시적으로 통제해야 하면 migrate가 더 직접적입니다. 다만 in-use 볼륨의 재타입은 마이그레이션이 동반되면 보통 관리자 권한이 필요하고, 암호화된 in-use 볼륨은 재타입 마이그레이션이 지원되지 않는 경우가 있습니다. 이런 케이스는 무리해서 실시간 전환하지 말고 점검창을 잡는 편이 더 안전합니다.
신규 생성 분리, 테스트 볼륨 이동, 운영 볼륨 확장 전환 순서를 보여주는 절차형 이미지입니다.
7. OpenStack Ceph 마이그레이션에서 자주 부딪히는 실패 모드
증상은 비슷해 보여도 원인은 다릅니다. 저는 아래 네 가지부터 먼저 자릅니다.
7-1. 타입은 맞는데 스케줄링이 안 됩니다
대부분은 volume_backend_name 불일치, 백엔드 서비스 비활성화, 드라이버 초기화 실패 셋 중 하나입니다.
grep -E 'enabled_backends|volume_backend_name|rbd_pool|rbd_user' /etc/cinder/cinder.conf
openstack volume service list
journalctl -u openstack-cinder-scheduler -n 200 --no-pager
journalctl -u openstack-cinder-volume -n 200 --no-pager
배포판에 따라 systemd 유닛명은 다를 수 있으니 서비스 이름은 현 환경 기준으로 바꿔서 보시면 됩니다. 근본 원인은 흔히 두 가지예요. 첫째, 타입은 rbd-new를 보는데 실제 백엔드는 rbd_new처럼 다른 이름으로 등록된 경우. 둘째, 드라이버가 Ceph 인증 실패로 초기화되지 않았는데 운영자가 프로세스만 살아 있다고 착각하는 경우입니다.
7-2. Ceph 인증 문제로 생성 또는 attach가 막힙니다
이 경우는 생성 단계와 attach 단계의 증상이 달라서 더 헷갈립니다. 새 풀에 대한 cap이 없거나, Nova와 Cinder, Glance가 참조하는 사용자명과 시크릿, 키링 경로가 어긋나 있는 경우가 많습니다. 특히 Cinder가 볼륨을 만들 수 있는 권한과 Nova/libvirt가 그 볼륨을 실제로 매핑할 수 있는 권한은 완전히 같은 문제가 아닐 수 있습니다.
7-3. 이동은 됐는데 체감 성능이 흔들립니다
이건 마이그레이션 명령의 성공 여부보다 Ceph 내부 상태를 먼저 봐야 합니다. recovery, backfill, nearfull 경고가 길게 이어지면 배치를 줄이거나 윈도우를 다시 잡는 편이 맞습니다. 현장에서 자주 보는 패턴은 이렇습니다. 낮 시간대에 작은 볼륨 몇 개는 멀쩡해서 속도를 올렸는데, 저녁 배치에서 대용량 볼륨과 Ceph 재배치가 겹치며 지연이 튀는 거죠. 이거 진짜 자주 나옵니다.
7-4. 소스 풀에 고아 이미지가 남습니다
실패한 이동, 중단된 작업, 관리자의 수동 정리 이력 때문에 원본 풀에 RBD 이미지가 남을 수 있습니다. 그렇다고 바로 지우면 안 됩니다. 먼저 OpenStack DB가 가리키는 위치와 실제 풀 위치가 일치하는지 확인해야 합니다. 저는 최소 하루 이상 운영 검증을 둔 뒤 정리합니다.
8. 검증은 보이는지보다 원하는 위치에서 실제로 쓰는지 봐야 합니다
마이그레이션 후 검증은 세 겹으로 합니다. OpenStack 상태, Ceph 실체, 워크로드 체감입니다.
볼륨 메타데이터 확인: 타입, 상태, migration 관련 필드 확인
대상 풀의 실제 RBD 이미지 확인: 새 풀에 이미지가 생겼는지 확인
attach 후 읽기/쓰기 확인: 실제 인스턴스에서 I/O 검증
소스 풀 잔존물 확인: 즉시 삭제하지 말고 정리 후보만 분리
openstack volume show 8f1f2f0d-1111-2222-3333-444444444444
rbd ls volumes_new
rbd info volumes_new/volume-8f1f2f0d-1111-2222-3333-444444444444
rbd ls volumes_old
저는 운영 확인을 여기서 끝내지 않습니다. 인스턴스에 붙여 파일 생성, 재마운트, 재부팅 후 재연결까지 확인합니다. 볼륨이 새 풀에 존재하는 것과, 서비스가 그 볼륨을 문제없이 소비하는 것은 다른 검증이거든요. 여기까지 봐야 마음이 놓입니다.
볼륨 상태 확인, 대상 풀의 RBD 이미지 존재 여부, 운영 검증 체크리스트를 보여주는 결과 이미지입니다.
9. 언제 Ceph 스토리지 전환을 고르고, 언제 병행 운영을 고를까
현장 추천은 꽤 분명합니다.
다운타임이 거의 없고 운영 안정성이 최우선이다: 기존 백엔드를 유지한 병행 운영 후, 새 타입으로 신규를 먼저 분리하고 기존은 점진적으로 옮기세요.
목표가 스토리지 통합 운영과 볼륨 정책 세분화다: Ceph 백엔드를 붙이되, 처음 범위는 Cinder로 제한하세요.
팀이 Ceph 장애 메시지와 재배치를 아직 익숙하게 다루지 못한다: 바로 전면 전환하지 말고 신규 볼륨만 새 백엔드로 보내며 운영 감각부터 쌓는 편이 낫습니다.
이미 Ceph를 쓰고 있고 풀 구조만 재정비하고 싶다: 풀 직접 교체보다 새 백엔드와 새 타입을 따로 만들고 정책 전환으로 정리하는 편이 안전합니다.
Nova 에페메럴까지 한 번에 바꾸고 싶다: 말리고 싶습니다. Cinder 경로가 안정화된 뒤 별도 프로젝트로 다루는 편이 훨씬 덜 아픕니다.
여러 번 겪어보면 결국 덜 아픈 방법은 비슷합니다. 새 백엔드를 먼저 붙이고, 신규 생성 경로를 갈라놓고, 기존 볼륨은 업무 중요도와 Ceph 상태를 보면서 천천히 옮기는 방식이죠. 빠른 전환보다 되돌릴 수 있는 전환이 훨씬 값집니다.
FAQ
Q. retype와 migrate 중 무엇을 먼저 고려하면 될까요?
볼륨 타입 정책 자체를 바꾸는 게 목적이면 retype 계열이 더 자연스럽습니다. 특정 목적지 호스트와 풀을 명시적으로 통제해야 하면 migrate가 더 직접적입니다. 다만 둘 다 실제 데이터 복사 여부는 현재 배치와 드라이버 동작에 좌우되니, 테스트 볼륨 검증부터 해보는 게 맞습니다.
Q. 기존 백엔드는 언제 제거하는 게 좋을까요?
신규 생성이 완전히 차단되고, 잔여 볼륨과 소스 풀의 정리 후보가 분리되고, 운영 검증 기간을 지난 뒤가 적절합니다. 저는 최소 한 템포 두고 소스 풀을 정리합니다.
Q. Ceph가 항상 정답인가요?
아닙니다. Ceph의 장점은 기능 자체보다 운영 일관성에 있습니다. 팀이 그 일관성을 감당할 준비가 안 돼 있다면, Ceph 도입은 기술 선택이 아니라 운영 부채가 될 수도 있습니다.
어떤 상황에서 병행 운영, 점진 전환, 즉시 전환 중 무엇을 고를지 요약한 마무리 인포그래픽입니다.
OpenStack 업그레이드 10가지 체크리스트: 실전 베스트 프랙티스로 성공 확률 높이기
OpenStack 업그레이드는 생각보다 자주, 그리고 생각보다 크게 운영팀을 흔듭니다. 평소엔 잘 돌던 Nova(노바, 컴퓨트 서비스), Neutron(뉴트론, 네트워크 서비스), Cinder(신더, 블록 스토리지 서비스)가 업그레이드 직후 서로 미묘하게 어긋나기 시작하면 진짜 진땀 나거든요. 저도 처음엔 “패키지 버전만 맞추면 되겠지” 했다가 메시지 큐(Message Queue, 서비스 간 비동기 통신), DB schema(데이터베이스 스키마), API microversion(API 세부 버전 정책) 때문에 삽질 좀 했습니다 ㅎㅎ 이번 글은 그런 시행착오를 줄이기 위한 OpenStack 업그레이드 체크리스트를 정리한 내용입니다.
특히 운영 중인 프라이빗 클라우드(private cloud)를 관리하시는 분들이라면, 단순히 패키지를 올리는 작업이 아니라 클라우드 업그레이드 전체 흐름으로 봐야 합니다. 오늘은 제가 홈랩과 실서비스 환경에서 반복해서 확인했던 항목들을 기준으로, 실패 확률을 줄이는 순서와 OpenStack 베스트 프랙티스를 풀어보겠습니다.
컨트롤 플레인과 컴퓨트 노드, 스토리지, 네트워크 컴포넌트가 단계적으로 업그레이드되는 전체 흐름을 보여주는 이미지입니다.
왜 OpenStack 업그레이드가 까다로운가
쉽게 말해 OpenStack은 하나의 프로그램이 아니라 여러 서비스 묶음입니다. Keystone(키스톤, 인증 서비스), Glance(글랜스, 이미지 서비스), Nova, Neutron, Cinder 같은 핵심 서비스가 각각 DB, API, 에이전트, 백엔드 드라이버를 갖고 있고요. 그래서 한 군데만 올리면 끝나는 구조가 아닙니다.
여기서 중요한 포인트! 업그레이드의 핵심은 버전 상승 자체가 아니라 호환성 유지입니다. 실제로 써보니까 장애는 대개 패키지 설치보다 서비스 간 정합성이 깨질 때 발생하더라고요. 예를 들어 API는 올라갔는데 agent(에이전트, 각 노드에서 동작하는 구성요소)가 예전 상태면 네트워크 포트 생성이 꼬이거나, DB migration(데이터베이스 마이그레이션)이 덜 끝난 상태에서 서비스가 붙으면서 애매한 오류를 만들기도 합니다.
OpenStack 업그레이드 전 꼭 봐야 할 10가지 체크리스트
공식 릴리스 노트와 업그레이드 경로 확인 지원되는 업그레이드 경로인지 먼저 확인해야 합니다. 중간 릴리스를 건너뛰면 안 되는 경우가 있거든요.
현재 인벤토리와 의존성 파악 컨트롤러, 컴퓨트, 네트워크 노드, 스토리지 백엔드, 하이퍼바이저, OS 패키지 상태를 정리합니다.
백업과 복구 시나리오 검증 DB dump만 뜨고 끝내면 부족합니다. 실제 복원 테스트까지 해봐야 합니다.
테스트 환경 또는 스테이징 검증 프로덕션과 최대한 비슷한 구조에서 한 번 굴려봐야 예상치 못한 이슈를 줄일 수 있습니다.
API, DB, Message Queue 호환성 점검 RabbitMQ 같은 메시지 큐와 MariaDB/MySQL, PostgreSQL 설정 차이도 같이 봐야 합니다.
드레인(Drain)과 유지보수 창 확보 라이브 마이그레이션 가능 여부, 예약 작업, 사용자 공지까지 포함해서 계획을 세워야 합니다.
롤링 업그레이드 가능 범위 확인 서비스별로 순차 적용 가능한지, 전체 중단이 필요한지 구분해야 합니다.
설정 파일 diff 비교 기존 설정과 새 기본값이 어떻게 달라졌는지 비교해야 합니다.
모니터링과 로그 수집 체계 준비 업그레이드 직후엔 로그가 거의 유일한 힌트일 때가 많습니다.
검증 시나리오 문서화 인스턴스 생성, 삭제, 볼륨 연결, 플로팅 IP, 보안 그룹, 이미지 업로드 같은 기본 기능을 체크리스트로 만들어야 합니다.
업그레이드 방식 비교: 인플레이스 vs 블루그린 관점
현실적으로는 대부분 인플레이스(in-place, 기존 환경에서 직접 업그레이드)를 선택합니다. 비용과 장비 여유 때문이죠. 저도 홈랩에서는 거의 인플레이스로 갔었는데, 대신 검증 시나리오를 더 빡세게 잡았습니다. 반대로 규모가 크고 서비스 중단 허용 범위가 작다면 블루그린(blue-green, 신규 환경을 따로 구성 후 전환) 접근이 더 안전할 수 있습니다.
방식
장점
주의점
인플레이스 업그레이드
추가 자원 부담이 적고 기존 운영 체계를 유지하기 쉽습니다
롤백이 까다롭고 서비스 간 버전 혼합 구간 관리가 중요합니다
블루그린 전환
검증 후 전환이 가능해 리스크를 줄이기 좋습니다
추가 인프라와 데이터 동기화 전략이 필요합니다
하이브리드 단계 전환
핵심 서비스만 분리해 현실적으로 적용하기 좋습니다
운영 절차가 복잡해지고 문서화가 필수입니다
실전 구현: OpenStack 업그레이드 작업 순서
여기서는 배포 도구에 종속되지 않는 공통 흐름으로 설명하겠습니다. Ansible(앤서블, 자동화 도구), Kolla-Ansible, OpenStack-Ansible, 수동 패키지 기반 환경 모두 참고 가능한 순서입니다.
1. 현재 상태 수집
처음엔 이게 뭔가 싶었는데, 이 단계가 제일 중요합니다. 업그레이드 전 상태를 남겨놓지 않으면 장애가 나도 비교 기준이 없거든요.
openstack compute service list
openstack network agent list
openstack volume service list
openstack hypervisor list
openstack server list --all-projects
openstack volume list --all-projects
이 명령으로 서비스 상태를 저장해두면 업그레이드 후 비교가 훨씬 쉬워집니다. 가능하면 결과를 파일로 보관하세요.
2. 데이터베이스와 설정 백업
mysqldump --single-transaction --routines --databases keystone glance nova nova_api neutron cinder > openstack-backup.sql
cp -a /etc/keystone /root/backup/etc-keystone
cp -a /etc/nova /root/backup/etc-nova
cp -a /etc/neutron /root/backup/etc-neutron
cp -a /etc/cinder /root/backup/etc-cinder
제가 직접 해보니 DB dump만 믿고 갔다가 설정 파일 옵션 차이 때문에 더 오래 헤맨 적이 있습니다. 그래서 DB + 설정 파일 + 서비스 목록을 같이 백업하는 습관이 중요합니다.
3. 유지보수 창 공지와 워크로드 정리
운영 환경이라면 프로젝트 사용자에게 공지하고, 가능하면 대규모 배포 작업이나 자동 스케일링 작업은 멈춰두는 게 좋습니다. 라이브 마이그레이션이 가능한 구조라면 컴퓨트 노드 분산도 미리 해두세요.
사전 점검, 백업, 서비스 중지, DB 마이그레이션, 단계별 기동 검증까지 이어지는 작업 순서를 시각화한 이미지입니다.
4. 컨트롤 플레인부터 순차 업그레이드
일반적으로는 인증, 이미지, API, 스케줄러, 컨덕터 같은 컨트롤 플레인(control plane, 중앙 제어 계층)을 먼저 올리고 이후 컴퓨트와 에이전트를 따라갑니다. 근데 여기서 중요한 건 무조건 한 번에 다 올리는 게 아니라 서비스별 검증 후 다음 단계로 이동하는 겁니다.
systemctl stop openstack-nova-api
systemctl stop openstack-nova-scheduler
systemctl stop openstack-nova-conductor
# 패키지 업데이트 또는 배포 도구 실행
# 예: dnf update, apt upgrade, ansible-playbook 실행 등
nova-manage api_db sync
nova-manage db sync
systemctl start openstack-nova-api
systemctl start openstack-nova-scheduler
systemctl start openstack-nova-conductor
서비스 이름은 배포판마다 조금 다를 수 있습니다. 그래서 실환경에 맞는 서비스 유닛 이름을 먼저 확인해야 합니다.
5. Neutron과 Cinder는 연결 관계를 같이 본다
네트워크와 스토리지는 겉보기보다 외부 의존성이 많습니다. Neutron은 L2/L3 agent, ML2 plugin, DHCP, Metadata 구성이 엮여 있고요. Cinder는 백엔드 스토리지 드라이버와의 호환성이 중요합니다. 저도 예전에 API는 멀쩡한데 agent 상태가 down으로 찍혀서 한참 로그를 봤던 적이 있네요.
openstack network agent list
openstack volume service list
journalctl -u neutron-server -n 100
journalctl -u openstack-cinder-volume -n 100
6. 컴퓨트 노드는 소수부터 검증
모든 컴퓨트 노드를 한 번에 건드리지 말고, 먼저 일부 노드만 올려서 인스턴스 생성과 마이그레이션을 확인하는 게 좋습니다. 이건 정말 실전에서 체감이 큽니다. 작은 범위에서 틀어지면 복구가 빠르거든요.
설정 파일에서 자주 놓치는 포인트
deprecated option: 더 이상 권장되지 않는 옵션이 남아 있으면 경고만 보이다가 실제 동작에 영향을 줄 수 있습니다.
endpoint URL: 내부 엔드포인트와 퍼블릭 엔드포인트 주소 체계가 섞이면 인증이나 이미지 호출이 실패할 수 있습니다.
policy: 정책 파일 구조가 바뀌는 경우가 있어 권한 문제가 생기기도 합니다.
backend driver 설정: Cinder, Neutron 플러그인 쪽은 예전 옵션명이 유지되지 않는 경우가 있습니다.
설정 비교는 단순히 파일 존재 여부가 아니라 기본값 변화를 보는 작업입니다. 여기서 중요한 포인트! 새 버전 기본 설정 샘플과 현재 운영 설정을 diff로 비교해보세요.
이건 생각보다 흔합니다. 서비스 계정 권한, 커넥션 문자열, 캐시, 메시지 큐 인증 정보가 미묘하게 어긋난 경우가 많더라고요. 로그에서 connection refused, access denied, transport error 같은 키워드를 먼저 찾으세요.
네트워크 에이전트가 살아 있는데 포트 생성이 실패하는 경우
Neutron server와 agent 버전 조합, ML2 설정, OVS(Open vSwitch, 가상 스위치) 또는 Linux bridge 구성이 어긋난 경우가 많습니다. 이럴 땐 API 응답만 보지 말고 agent heartbeat(에이전트 하트비트)와 브리지 상태를 같이 봐야 합니다.
openstack network agent list
ovs-vsctl show
ip link show
인스턴스는 생성되는데 콘솔 접속이 안 되는 경우
novncproxy, metadata, 보안 그룹, 프록시 설정이 엮여 있는 경우가 많습니다. 처음엔 컴퓨트 문제라고 생각하기 쉬운데, 실제로는 프론트 API나 프록시 계층 이슈인 경우도 있었습니다.
롤백이 필요한데 되돌릴 순서가 없는 경우
사실 제일 무서운 상황입니다. 그래서 업그레이드 시작 전에 “어디까지 실패하면 중단할지” 기준을 잡아야 합니다. 저는 보통 컨트롤 플레인 검증 실패, 인스턴스 신규 생성 실패, 기존 VM 네트워크 연결 실패 이 세 가지를 즉시 중단 기준으로 둡니다.
검증: 업그레이드 후 무엇을 확인해야 하나
업그레이드가 끝났다고 바로 종료하면 안 됩니다. OpenStack 유지보수 관점에서는 사후 검증이 절반입니다. 아래 항목은 꼭 순서대로 확인해보세요.
인증 토큰 발급과 대시보드 로그인 확인
이미지 목록 조회와 신규 이미지 업로드 확인
네트워크 생성, 서브넷 생성, 라우터 연결 확인
테스트 인스턴스 생성과 삭제 확인
플로팅 IP 연결 및 외부 통신 확인
볼륨 생성, 연결, 분리 확인
보안 그룹 규칙 반영 확인
라이브 또는 콜드 마이그레이션 시나리오 확인
모니터링 알림과 로그 수집 확인
에러 로그 증가 여부 추적
서비스 상태가 모두 정상이며 컴퓨트, 네트워크, 스토리지 검증 항목이 체크 완료된 운영 대시보드 이미지입니다.
openstack token issue
openstack image list
openstack network list
openstack server create --flavor m1.small --image test-image --network private test-vm
openstack server list
openstack volume create --size 1 test-volume
openstack volume list
이 검증 절차를 문서화해두면 다음 업그레이드 때 시간이 정말 많이 줄어듭니다. 실제로 써보니까 사람 기억보다 체크리스트가 훨씬 믿을 만하더라고요.
제가 정리해보는 OpenStack 베스트 프랙티스
작게 시작해서 넓힌다: 일부 노드, 일부 서비스부터 검증합니다.
업그레이드 전 상태를 숫자와 결과로 남긴다: 서비스 목록, 워크로드 수, 에이전트 상태를 저장합니다.
백업은 복원 테스트까지 포함한다: 백업 파일 존재만으로 안심하면 안 됩니다.
문서화한다: 명령어, 순서, 실패 지점, 복구 시간을 기록합니다.
배포 도구의 자동화를 맹신하지 않는다: 자동화는 빠르지만, 원인 분석은 사람이 해야 하거든요.
혹시 이런 경험 있으신가요? 업그레이드는 끝났는데 사용자 쪽에서 “왜 VM 생성이 예전보다 느려졌죠?”라는 질문이 나오는 경우요. 이런 건 단순 성공/실패가 아니라 성능과 안정성까지 같이 봐야 한다는 뜻입니다. 그래서 클라우드 업그레이드는 배포 이벤트가 아니라 운영 이벤트로 봐야 합니다.
정리: 체크리스트 기반으로 움직이면 성공 확률이 올라갑니다
OpenStack 업그레이드는 한 번의 명령으로 끝나는 작업이 아닙니다. 서비스 의존성, DB migration, 에이전트 상태, 검증 시나리오가 다 맞물려 있습니다. 저도 처음엔 버전만 맞추면 되겠지 싶었는데, 실제로는 사전 점검과 사후 검증이 훨씬 중요했습니다. 드디어 됐다! 싶은 순간은 마지막 패키지 설치가 아니라, 테스트 VM이 정상적으로 뜨고 네트워크와 볼륨이 다 붙는 걸 확인했을 때 오더라고요.
이번 글에서는 운영 기준으로 바로 써먹을 수 있는 체크리스트 중심으로 정리해봤습니다. 다음 글에서는 Kolla-Ansible 기반 환경에서 업그레이드 점검 포인트를 더 구체적으로 다뤄볼 예정입니다. 이전 글에서 백업 전략을 정리해두셨다면 이번 체크리스트와 같이 묶어서 보시면 흐름이 훨씬 잘 잡히실 겁니다.
업그레이드 전 점검 항목과 업그레이드 후 검증 항목을 한눈에 비교할 수 있는 요약 인포그래픽입니다.
자주 묻는 질문
Q. OpenStack 업그레이드는 무중단으로 가능한가요?
일부 구성에서는 롤링 업그레이드가 가능하지만, 실제 운영에서는 서비스 영향도를 0으로 만들기 쉽지 않습니다. 특히 네트워크와 스토리지 쪽은 사전 검증이 더 중요합니다.
Q. 테스트 환경이 작아도 도움이 되나요?
네, 도움이 됩니다. 완벽히 같지 않아도 서비스 기동 순서, DB migration, 기본 API 검증만 해봐도 큰 차이가 납니다.
Q. 가장 먼저 자동화해야 할 부분은 뭔가요?
상태 수집, 백업, 검증 명령 실행 결과 저장입니다. 이 세 가지가 자동화되면 반복 작업이 훨씬 안정적이 됩니다.
OpenStack Ceph 연동은 프라이빗 클라우드를 운영할 때 한 번쯤 꼭 마주치는 주제입니다. 저도 홈랩과 실무 환경에서 OpenStack 스토리지 구성을 여러 번 만졌는데요, 처음엔 단순히 연결만 되면 끝일 줄 알았습니다. 그런데 실제로 써보니까 연동 성공과 제대로 빠르게 동작하는 상태는 완전히 다른 이야기더라고요. 특히 볼륨 생성은 되는데 체감이 느리거나, 가상머신 부팅이 들쭉날쭉하거나, 특정 시간대에 I/O가 몰리면 급격히 지연이 커지는 문제를 겪으면 그때부터 삽질이 시작됩니다. 혹시 지금 OpenStack Ceph 연동 이후 성능이 이상하게 답답하다고 느끼고 계신가요?
여기서 중요한 포인트는, 원인이 Ceph 자체인지 OpenStack 설정인지, 아니면 둘 사이의 연결 방식인지 분리해서 봐야 한다는 점입니다. 이 글에서는 제가 직접 겪었던 OpenStack Ceph 연동 실패 패턴과 해결 방법을 정리했으니, 비슷한 상황이라면 참고하시길 바랍니다.
OpenStack 컴퓨트, 이미지, 블록 스토리지 서비스와 Ceph 클러스터 간 연결 구조를 한눈에 보여주는 아키텍처 이미지입니다.
왜 OpenStack Ceph 연동에서 성능 문제가 자주 생길까
쉽게 말해 OpenStack는 서비스를 제공하는 제어 평면(control plane)이고, Ceph는 실제 데이터를 저장하는 분산 스토리지(distributed storage) 역할을 합니다. 많이들 Cinder(신더, 블록 스토리지), Glance(글랜스, 이미지 서비스), Nova(노바, 컴퓨트)가 Ceph의 RBD(RADOS Block Device, 블록 디바이스 인터페이스)를 함께 쓰도록 구성하죠. 구조만 보면 깔끔합니다. 근데 여기서 병목이 생기는 지점이 꽤 많습니다.
인증 설정은 맞는데 풀(pool) 권한이 어긋난 경우
네트워크 분리가 부족해서 클라이언트 트래픽과 복제 트래픽이 섞이는 경우
풀 설계가 서비스 특성과 맞지 않는 경우
하이퍼바이저(hypervisor) 캐시 정책이 애매해서 지연이 커지는 경우
작은 I/O가 많이 발생하는 워크로드를 고려하지 않은 경우
저도 처음엔 Ceph 최적화라고 하면 OSD(Object Storage Daemon, 오브젝트 스토리지 데몬) 쪽만 보면 된다고 생각했었는데요, 막상 들여다보니 OpenStack 스토리지 설정에서 생기는 비효율이 꽤 컸습니다. 특히 이미지 업로드는 괜찮은데 볼륨 기반 부팅이 유독 느린 경우, 그 원인이 하나가 아니라 여러 레이어에 걸쳐 있는 경우가 많았습니다.
구성 개념 먼저 정리해보겠습니다
OpenStack Ceph 연동을 이해할 때는 각 서비스가 어느 풀을 쓰는지부터 정리하면 훨씬 덜 헷갈립니다.
구성 요소
역할
Ceph 연동 포인트
체크 포인트
Glance
이미지 저장
RBD 이미지 풀
이미지 업로드/변환 지연
Cinder
볼륨 제공
RBD 볼륨 풀
볼륨 생성 속도, attach 지연
Nova
가상머신 부팅
Ceph 백엔드 부트
부팅 시간, I/O 패턴
Ceph MON/OSD
클러스터 관리/데이터 저장
스토리지 코어
복제 상태, 지연, 균형
핵심은 이겁니다. OpenStack 스토리지 성능은 단순히 디스크가 빠르냐 느리냐로 끝나지 않습니다. 인증, 네트워크, 풀 설계, 복제 정책(replication policy), 클라이언트 설정이 다 같이 맞물립니다. 그래서 문제를 볼 때도 한 군데만 보면 안 되죠.
제가 실제로 점검했던 사전 체크리스트
본격적으로 손대기 전에 저는 항상 아래 순서대로 확인합니다. 이 순서를 안 지키면 괜히 OSD 튜닝만 하다가 시간을 많이 쓰게 되더라고요.
Ceph 클러스터 상태가 HEALTH_OK 또는 경미한 경고 수준인지 확인합니다.
Glance, Cinder, Nova가 각각 어떤 Ceph 사용자와 풀을 쓰는지 정리합니다.
스토리지 네트워크와 서비스 네트워크가 분리되어 있는지 확인합니다.
볼륨 생성, 이미지 업로드, 부팅 중 어디가 가장 느린지 구분합니다.
가상머신 내부 체감 속도와 백엔드 I/O 지표를 따로 봅니다.
여기서 중요한 포인트! 사용자는 보통 “Ceph가 느리다”라고 말하지만, 실제로는 이미지 복사 경로가 비효율적이거나 캐시 정책이 안 맞아서 그렇게 느끼는 경우도 많습니다. 저도 예전에 이걸 구분 못 해서 하루를 날린 적이 있습니다. OpenStack Ceph 연동에서는 정말 이런 실수가 흔하거든요.
실전 구현: OpenStack Ceph 연동 기본 점검과 설정
아래 예시는 개념을 설명하기 위한 일반적인 형태입니다. 배포판이나 자동화 도구에 따라 파일 위치와 세부 항목은 조금 다를 수 있습니다. 그래도 큰 흐름은 비슷합니다.
1. Ceph 클러스터 상태 확인
ceph -s
ceph health detail
ceph osd tree
ceph osd df
rbd pool ls
이 단계에서 저는 먼저 복제 지연이나 OSD 불균형부터 봅니다. 연동 전에 백엔드가 불안정하면 OpenStack 쪽에서 아무리 손봐도 체감이 안 좋아집니다.
2. Ceph 사용자 권한 확인
ceph auth list
ceph auth get client.glance
ceph auth get client.cinder
ceph auth get client.nova
권한이 과하게 넓은 것도 문제지만, 더 자주 보는 건 풀 권한이 어설프게 빠져 있는 경우입니다. 그러면 기능은 되는 것처럼 보여도 특정 작업에서만 실패하거나 지연이 생깁니다.
Glance(글랜스, 이미지 서비스)가 Ceph를 바로 쓰도록 해두면 이미지 관리가 단순해집니다. 다만 이미지 업로드와 변환 작업이 많은 환경이라면 여기서도 풀 설계와 I/O 패턴을 꼭 같이 봐야 합니다.
OpenStack 서비스별로 어떤 Ceph 사용자와 풀을 사용하는지 보여주는 구성 다이어그램입니다.
실패 사례: OpenStack Ceph 연동은 됐는데 성능이 안 나온 이유
이제 제가 실제로 겪었던 전형적인 실패 패턴을 말씀드려볼게요. 처음엔 볼륨 생성도 되고 인스턴스도 뜨니까 성공한 줄 알았습니다. 그런데 실제로 써보니까 VM 부팅 시간이 일정하지 않았고, 동시에 여러 작업이 걸리면 체감 지연이 확 올라가더라고요. 여기서부터가 진짜 OpenStack Ceph 연동의 시작이었습니다.
문제 1. 네트워크를 논리적으로만 나눠놓고 물리적으로는 섞어 썼던 경우
Ceph는 복제와 복구 트래픽이 발생합니다. 그런데 클라이언트 액세스와 같은 대역을 공유하면 피크 시간에 지연이 커질 수 있습니다. 저도 홈랩에서 처음엔 VLAN만 나누면 충분하겠지 했었는데, 실제로는 업링크 혼잡이 생기면서 체감 성능이 꽤 흔들렸습니다.
증상: 특정 시간대에 볼륨 attach와 부팅 지연 증가
원인: 스토리지 트래픽과 일반 서비스 트래픽 경합
대응: 스토리지 네트워크 경로를 분리하고 혼잡 구간을 줄임
문제 2. 풀을 나누지 않고 한 곳에 몰아넣은 경우
이미지, 볼륨, 테스트용 작업이 한 풀에 몰려 있으면 관찰도 어렵고 튜닝 포인트도 흐려집니다. Ceph 최적화는 결국 워크로드 분리가 기본이더라고요.
증상: 어떤 작업이 느린지 구분이 잘 안 됨
원인: 서비스별 I/O 특성 혼재
대응: images, volumes 등 역할 단위로 풀을 분리해 관찰성 확보
문제 3. 클론과 스냅샷 체인을 너무 방치한 경우
처음엔 공간 절약 측면에서 좋아 보이는데, 운영 기간이 길어지면 관리 포인트가 늘어납니다. 특히 오래된 이미지 기반으로 파생된 체인이 많아지면, 성능과 운영 복잡도가 같이 올라갈 수 있습니다. OpenStack Ceph 연동 운영에서는 정말 흔한 문제입니다.
문제 4. 성능 문제를 전부 Ceph 탓으로만 본 경우
이거 정말 많이 봅니다. 근데 실제로는 하이퍼바이저 캐시 설정, 인스턴스 유형별 디스크 패턴, 백그라운드 작업 영향도 같이 봐야 하거든요. 저도 처음엔 Ceph OSD만 의심했었는데, 나중에 보니 OpenStack 스토리지 경로에서 이미지 변환과 attach 흐름이 더 큰 영향을 준 케이스가 있었습니다.
⚠️ 트러블슈팅: 제가 효과를 봤던 점검 순서
문제가 생기면 아래 순서로 좁혀가면 좋습니다. 무작정 튜닝부터 하지 마세요. 저도 예전엔 그랬다가 더 꼬였습니다.
Ceph 상태 확인 클러스터 경고, 리밸런싱(rebalancing), 복구 상태를 먼저 확인합니다.
풀 단위 관찰 어느 풀이 바쁜지, 이미지와 볼륨 중 어디서 병목이 생기는지 봅니다.
OpenStack 작업별 분리 이미지 업로드, 볼륨 생성, 인스턴스 부팅을 따로 테스트합니다.
동시 작업 테스트 단건 테스트는 괜찮은데 동시성에서 무너지는 경우가 많습니다.
체인 정리 여부 검토 오래된 스냅샷/클론 구조가 쌓였는지 확인합니다.
openstack volume create --size 10 test-volume
openstack server create --flavor m1.small --image test-image --network private test-vm
rbd ls -p volumes
rbd info volumes/test-volume
ceph osd perf
여기서 ceph osd perf 같은 기본 지표와 OpenStack 작업 시간을 같이 비교해보면 감이 옵니다. 절대적인 숫자보다 언제 느려지는지, 어떤 작업에서 흔들리는지를 보는 게 더 중요합니다.
볼륨 생성과 가상머신 부팅 과정에서 지연이 발생하는 구간을 시각적으로 보여주는 대시보드 이미지입니다.
Ceph 최적화 관점에서 배운 점
이번 경험에서 가장 크게 느낀 건, Ceph 최적화는 단일 옵션 몇 개로 끝나는 작업이 아니라는 점이었습니다. 결국 아래 네 가지가 같이 맞아야 하더라고요.
네트워크 분리: 복제와 클라이언트 경로를 명확히 구분
풀 설계: 워크로드 성격에 맞춰 역할 분리
운영 습관: 오래된 스냅샷/클론 체인 방치 금지
관찰성: OpenStack 로그와 Ceph 상태를 함께 확인
스토리지 성능은 숫자 하나로 판단하기 어렵습니다. 어떤 환경에서는 작은 랜덤 I/O가 문제고, 또 어떤 환경에서는 이미지 배포 흐름이 더 큰 병목이 됩니다. 그래서 저는 요즘은 성능 문제가 나오면 먼저 “이게 Ceph 문제인가, OpenStack 스토리지 경로 문제인가, 아니면 둘 다인가?”부터 구분합니다.
검증 방법: 무엇을 확인해야 실제로 좋아졌다고 볼 수 있을까
개선 후에는 꼭 검증이 필요합니다. 그냥 느낌상 빨라진 것 같다고 넘어가면 다음 장애 때 다시 원점으로 돌아갑니다.
동일한 이미지로 인스턴스 부팅 시간을 여러 번 비교합니다.
동시에 여러 볼륨을 생성해 지연 패턴이 안정적인지 봅니다.
이미지 업로드와 볼륨 생성이 겹칠 때도 성능 저하가 과도하지 않은지 확인합니다.
Ceph 클러스터 상태가 테스트 중에도 안정적인지 체크합니다.
제가 직접 해보니, 단건 테스트보다 동시성 테스트가 훨씬 유의미했습니다. 평소엔 괜찮다가도 작업이 몰리면 바로 티가 나거든요. 드디어 됐다! 싶은 순간도 보통 이 구간을 통과했을 때였습니다.
openstack server list
openstack volume list
ceph -s
ceph df
rbd du -p volumes
검증할 때는 결과만 보지 말고, 테스트 중간에 경고가 발생하지 않는지도 꼭 보세요. 여기서 안정적이면 그제야 실제 운영에 올릴 만한 상태라고 판단합니다.
최적화 이전과 이후의 지연 안정성 차이를 비교하고, 운영자가 점검해야 할 항목을 요약한 이미지입니다.
실무적으로 정리하는 OpenStack 스토리지 운영 팁
항목
권장 접근
피해야 할 패턴
네트워크
스토리지 경로 분리
복제/서비스 트래픽 혼재
풀 설계
서비스별 역할 분리
모든 워크로드를 단일 풀에 집중
운영 관리
스냅샷/클론 주기적 점검
장기간 체인 방치
검증 방식
동시성 포함 반복 테스트
단건 테스트만으로 판단
이 표는 제가 나중에 운영 문서로도 정리해둔 기준입니다. 사실 OpenStack Ceph 연동은 한 번 붙이고 끝나는 프로젝트가 아니라, 붙인 뒤부터 운영 품질이 갈리는 영역입니다. 이전 글에서 다뤘던 기본 네트워크 설계와도 연결되는 부분이고, 다음 글에서는 Ceph 모니터링 포인트를 조금 더 깊게 다뤄볼 예정입니다.
마무리: 연동 성공보다 중요한 건 안정적인 성능입니다
오늘 정리한 실패 사례의 핵심은 단순합니다. OpenStack Ceph 연동이 되었더라도, 그 상태가 곧 최적 상태는 아니라는 점입니다. 저도 처음엔 연결만 되면 다 끝난 줄 알았는데, 실제 운영에서는 네트워크, 풀 설계, 스냅샷 체인, 작업 동시성까지 다 영향을 주더라고요. 삽질 좀 했습니다. 그래도 이런 과정을 겪고 나니 이제는 문제를 훨씬 빨리 좁힐 수 있게 됐습니다.
혹시 지금 OpenStack 스토리지 성능 때문에 답답하셨다면, 오늘 내용처럼 어디서 느려지는지 분리해서 보는 것부터 시작해보세요. 그게 가장 현실적인 첫걸음입니다. 그리고 Ceph 최적화는 무조건 큰 튜닝보다, 구조를 바르게 잡는 쪽이 효과가 더 컸습니다. 이 부분은 정말 경험상 그렇습니다.
연동 성공, 병목 원인 분리, 검증 절차, 운영 팁을 한 장으로 요약한 마무리 인포그래픽입니다.
정리 FAQ
Q. OpenStack Ceph 연동 후 가장 먼저 볼 것은 무엇인가요?
A. Ceph 클러스터 상태와 OpenStack 서비스별 풀/사용자 매핑입니다. 이 두 가지가 기본입니다.
Q. 스토리지 성능이 느리면 무조건 Ceph 튜닝부터 해야 하나요?
A. 아닙니다. 네트워크 경합, 풀 분리 부족, 스냅샷 체인 누적, OpenStack 작업 흐름까지 같이 봐야 합니다.
Q. OpenStack 스토리지 운영에서 가장 실수하기 쉬운 부분은 뭔가요?
A. 연동 성공을 성능 검증 완료로 착각하는 부분입니다. 꼭 동시성 테스트까지 해보셔야 합니다.
OpenStack Cinder 오류 때문에 볼륨이 안 만들어지는 상황, 운영하다 보면 한 번쯤은 꼭 겪게 됩니다. 인스턴스는 잘 뜨는데 스토리지 쪽에서 갑자기 발목을 잡으면 진짜 답답하거든요. 저도 홈랩과 실서비스 비슷한 테스트 환경에서 Cinder 볼륨 생성이 계속 실패해서 한참 삽질했었습니다. 처음엔 Nova(컴퓨트 서비스) 문제인가 싶었는데, 실제로 파고 들어가 보니 메시지는 비슷해도 원인은 꽤 다양하더라고요.
이번 글에서는 OpenStack Cinder 오류가 났을 때 어디부터 봐야 하는지, 어떤 로그를 먼저 열어야 하는지, 그리고 OpenStack 스토리지 문제를 어떻게 단계적으로 좁혀 가는지 제 경험 기준으로 정리해보겠습니다. 특히 막연하게 재시도만 하는 대신, Cinder 디버깅 관점에서 원인을 빠르게 찾는 흐름에 집중해볼게요.
OpenStack 환경에서 Cinder, Nova, 백엔드 스토리지가 어떻게 연결되는지 보여주는 개요 이미지입니다.
1. OpenStack Cinder 오류는 왜 그렇게 자주 터질까요?
쉽게 말해 Cinder(블록 스토리지 서비스)는 단순히 디스크 파일 하나 만드는 역할이 아닙니다. API 요청을 받고, 스케줄러가 적절한 백엔드로 보내고, 실제 스토리지 드라이버가 LVM(Logical Volume Manager)이나 Ceph(분산 스토리지) 같은 백엔드에 볼륨을 생성하는 구조거든요. 중간 단계가 많다 보니 어디 한 군데만 어긋나도 사용자 입장에서는 그냥 볼륨 생성 실패로 보입니다.
제가 직접 해보니 특히 아래 네 군데에서 많이 막혔습니다.
서비스 상태 이상: cinder-api, cinder-scheduler, cinder-volume 중 하나가 비정상
백엔드 설정 오류: volume_backend_name, target_helper, 드라이버 옵션 불일치
권한/연결 문제: iSCSI, RBD, LVM 명령 실행 실패
용량 부족: 실제 디스크 또는 풀(pool) 여유 공간 부족
여기서 중요한 포인트! 에러 메시지 한 줄만 보고 판단하면 거의 항상 돌아갑니다. 요청 경로를 따라가면서 Cinder 디버깅을 체계적으로 진행해야 합니다.
2. Cinder 볼륨 생성 흐름을 먼저 이해해보겠습니다
저도 처음엔 헷갈렸는데, 구조를 이해하면 로그 보는 순서가 훨씬 쉬워집니다.
사용자가 Horizon(대시보드) 또는 CLI로 볼륨 생성 요청
cinder-api가 요청을 받음
cinder-scheduler가 어떤 백엔드에 생성할지 결정
cinder-volume이 실제 스토리지 드라이버 호출
LVM, Ceph RBD, NFS 같은 백엔드에서 실제 볼륨 생성
즉, 볼륨이 안 만들어지면 API, 스케줄링, 백엔드 실행까지 모두 후보입니다. 그래서 저는 늘 서비스 상태 확인 → 볼륨 상태 확인 → 로그 확인 → 백엔드 직접 점검 순서로 갑니다. 이 흐름이 제일 덜 꼬였습니다.
3. 기본 점검: 가장 먼저 확인할 사항
솔직히 여기서 끝나는 경우도 꽤 많습니다. 너무 복잡하게 보기 전에 기본 체크부터 해보세요.
3-1. Cinder 서비스 상태 확인
openstack volume service list
systemctl status openstack-cinder-api
systemctl status openstack-cinder-scheduler
systemctl status openstack-cinder-volume
서비스 목록에서 enabled/up 상태인지 먼저 봅니다. 특히 cinder-volume이 down이면 백엔드까지 요청이 안 내려갑니다. 실제로 써보니까 API는 살아 있는데 volume 서비스만 죽어 있는 케이스가 은근 많더라고요.
3-2. 실패한 볼륨 상태 확인
openstack volume list
openstack volume show <VOLUME_ID>
error, error_deleting, creating에서 멈췄는지 봐야 합니다. creating 상태가 오래 유지되면 백엔드 작업이 걸렸거나 스케줄링 이후 후속 처리가 멈췄을 가능성이 있습니다.
3-3. quota(쿼터, 자원 할당량) 확인
openstack quota show <PROJECT_ID>
의외로 단순한 프로젝트 quota 초과 때문에 OpenStack Cinder 오류처럼 보일 때도 있습니다. 특히 테스트 환경에서는 이것 때문에 시간을 꽤 쓰게 되네요.
초기 점검 단계에서 서비스 상태와 볼륨 상태를 어떻게 확인하는지 보여주는 이미지입니다.
4. Cinder 디버깅의 핵심: 로그를 요청 흐름대로 읽기
이제부터는 본격적인 문제 해결입니다. 여기서는 로그를 한 군데만 보는 게 아니라 요청 흐름대로 나눠서 보는 게 Cinder 디버깅의 핵심입니다.
enabled_backends, 섹션 이름, volume_backend_name 관계를 이해하기 쉽게 보여주는 구성 이미지입니다.
6. ⚠️ OpenStack 스토리지 운영에서 자주 놓치는 부분
여기부터는 경험상 체감 비중이 높았던 항목입니다.
6-1. 디스크 용량은 남았는데도 실패하는 경우
겉으로는 스토리지 여유가 있어 보여도, thin provisioning(씬 프로비저닝) 설정이나 reserved space(예약 공간) 때문에 실제 할당 가능 용량이 부족할 수 있습니다. 특히 LVM thin pool을 쓰면 숫자만 보고 안심했다가 나중에 뒤통수 맞기 쉽습니다.
6-2. 메시지 큐와 데이터베이스 지연
Cinder만 보는 게 아니라 RabbitMQ(메시지 브로커)나 MariaDB/MySQL 같은 공통 인프라 레이어도 함께 봐야 합니다. 요청은 들어갔는데 상태 갱신이 늦거나 작업 분배가 밀리면 사용자 눈에는 그냥 실패처럼 보이거든요.
6-3. 멀티백엔드 환경의 우선순위 문제
백엔드가 여러 개면 특정 volume type(볼륨 타입)이 어느 백엔드로 가는지 꼭 확인해야 합니다. volume type과 extra specs(추가 속성)가 맞지 않으면 엉뚱한 백엔드로 가거나 스케줄링에 실패할 수 있습니다.
openstack volume type list
openstack volume type show <VOLUME_TYPE>
혹시 이런 경험 있으신가요? 분명 Ceph로 보내야 하는데 기본 타입 때문에 LVM으로 가고 있던 상황이요. 이거 생각보다 자주 나옵니다.
7. 해결책 검증하기: 실제로 동작하는지 확인
원인을 수정했다면 반드시 재현 테스트를 해봐야 합니다. 저는 아래 순서대로 확인합니다.
테스트용 소형 볼륨 생성
상태가 available로 바뀌는지 확인
인스턴스에 attach(연결) 테스트
OS 내부에서 블록 디바이스 인식 확인
openstack volume create --size 1 test-volume
openstack volume list
openstack server add volume <SERVER_ID> <VOLUME_ID>
인스턴스 내부에서는 보통 아래처럼 확인합니다.
lsblk
sudo fdisk -l
여기까지 정상이라면 일단 급한 불은 껐다고 봐도 됩니다. 드디어 됐다! 하는 순간이 오긴 오더라고요.
문제 해결 후 볼륨 상태가 정상으로 바뀌고 인스턴스에 연결된 결과를 보여주는 검증 이미지입니다.
8. 자주 묻는 질문 정리
Q1. Cinder 디버깅은 로그를 어디부터 봐야 하나요?
openstack volume show로 상태를 보고, 그다음 cinder-scheduler, cinder-volume 순으로 보시면 됩니다. 백엔드 생성 실패는 보통 cinder-volume에 단서가 많습니다.
Q2. Horizon에서는 실패라고만 나오는데요?
그럴 때는 CLI가 훨씬 낫습니다. Horizon은 요약 메시지만 보여주는 경우가 많아서요. 실제 현장에서는 CLI와 journalctl 조합이 훨씬 빠릅니다.
Q3. OpenStack Cinder 오류가 간헐적으로만 발생합니다
이 경우는 설정 오류보다 인프라 지연, 네트워크 흔들림, 메시지 큐 병목 같은 문제일 가능성이 높습니다. 그래서 애플리케이션 로그만 보지 말고 아래도 함께 봐야 합니다.
관리 네트워크 지연
메시지 큐 적체
DB 응답 시간
백엔드 스토리지 클러스터 상태
9. 마무리: Cinder 볼륨 생성 실패는 체계적으로 접근하세요
Cinder 볼륨 생성 실패는 겉보기엔 단순하지만, 실제로는 API, 스케줄러, 볼륨 서비스, 백엔드 스토리지까지 다 연결된 문제입니다. 그래서 OpenStack Cinder 오류를 빨리 잡으려면 감으로 접근하면 안 되고, 요청 흐름 기준으로 차근차근 좁혀 가야 합니다. Cinder 디버깅의 원칙만 지켜도 복구 시간이 꽤 줄었습니다.
정리하면 이렇습니다.
서비스 상태부터 확인합니다
볼륨 상태와 로그를 함께 봅니다
백엔드 스토리지를 직접 검증합니다
quota, volume type, 멀티백엔드 매핑도 놓치지 않습니다
다음 글에서는 Cinder와 Ceph RBD 조합에서 자주 만나는 장애 포인트를 따로 정리해볼 예정입니다. OpenStack Cinder 오류 해결에 필요한 Nova attach 흐름도 함께 보시면 전체 그림 이해에 도움이 됩니다.
서비스, 로그, 백엔드, 검증 순서로 이어지는 Cinder 트러블슈팅 체크리스트 요약 이미지입니다.
![[OpenStack] OpenStack 플레이버 설계: 워크로드별 VM 구성 기준](https://blog.pswq.net/wp-content/uploads/2026/09/openstack-flavor-design-workload-analysis-thumbnail.jpg)
![[OpenStack] OpenStack Ceph 성능 병목과 실전 해결 방안](https://blog.pswq.net/wp-content/uploads/2026/09/openstack-ceph-performance-troubleshooting-thumbnail.jpg)
![[OpenStack] OpenStack Ceph 마이그레이션 결정 기준과 절차](https://blog.pswq.net/wp-content/uploads/2026/09/openstack-ceph-storage-backend-migration-criteria-procedure-thumbnail.jpg)
![[OpenStack] OpenStack 업그레이드 10가지 체크리스트: 실전 베스트 프랙티스로 성공 확률 높이기](https://blog.pswq.net/wp-content/uploads/2026/08/openstack-upgrade-checklist-best-practices-thumbnail.jpg)
![[인프라] OpenStack Ceph 연동 실패 사례와 스토리지 성능 최적화 교훈](https://blog.pswq.net/wp-content/uploads/2026/07/openstack-ceph-integration-failure-case-study-thumbnail.jpg)
![[OpenStack] OpenStack Cinder 볼륨 생성 실패? 흔한 원인과 해결책](https://blog.pswq.net/wp-content/uploads/2026/07/openstack-cinder-volume-creation-failure-troubleshooting-thumbnail.jpg)
