[OpenStack] OpenStack Cinder 볼륨 생성 실패? 흔한 원인과 해결책

목차

• 1. OpenStack Cinder 오류는 왜 그렇게 자주 터질까요?
• 2. Cinder 볼륨 생성 흐름을 먼저 이해해보겠습니다
• 3. 기본 점검: 가장 먼저 확인할 사항
• 3-1. Cinder 서비스 상태 확인
• 3-2. 실패한 볼륨 상태 확인
• 3-3. quota(쿼터, 자원 할당량) 확인
• 4. Cinder 디버깅의 핵심: 로그를 요청 흐름대로 읽기
• 4-1. API와 스케줄러 로그 확인
• 4-2. cinder-volume 로그로 근본 원인 찾기
• 4-3. 백엔드 직접 확인하기
• 5. 흔한 원인과 해결책: 빠르게 참고할 표
• 5-1. 설정 파일에서 자주 실수하는 부분
• 6. ⚠️ OpenStack 스토리지 운영에서 자주 놓치는 부분
• 6-1. 디스크 용량은 남았는데도 실패하는 경우
• 6-2. 메시지 큐와 데이터베이스 지연
• 6-3. 멀티백엔드 환경의 우선순위 문제
• 7. 해결책 검증하기: 실제로 동작하는지 확인
• 8. 자주 묻는 질문 정리
• Q1. Cinder 디버깅은 로그를 어디부터 봐야 하나요?
• Q2. Horizon에서는 실패라고만 나오는데요?
• Q3. OpenStack Cinder 오류가 간헐적으로만 발생합니다
• 9. 마무리: Cinder 볼륨 생성 실패는 체계적으로 접근하세요

OpenStack Cinder 볼륨 생성 실패? 흔한 원인과 해결책

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 볼륨 생성 흐름을 먼저 이해해보겠습니다

저도 처음엔 헷갈렸는데, 구조를 이해하면 로그 보는 순서가 훨씬 쉬워집니다.

1. 사용자가 Horizon(대시보드) 또는 CLI로 볼륨 생성 요청
2. cinder-api가 요청을 받음
3. cinder-scheduler가 어떤 백엔드에 생성할지 결정
4. cinder-volume이 실제 스토리지 드라이버 호출
5. 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 디버깅의 핵심입니다.

4-1. API와 스케줄러 로그 확인

journalctl -u openstack-cinder-api -n 200 --no-pager
journalctl -u openstack-cinder-scheduler -n 200 --no-pager

여기서 보는 포인트는 두 가지입니다. 첫째, 요청이 정상적으로 들어왔는지. 둘째, 스케줄러가 백엔드를 찾지 못했는지입니다. 만약 No valid backend 같은 메시지가 보이면 백엔드 이름 불일치나 capacity 정보 수집 실패를 의심해볼 수 있습니다.

4-2. cinder-volume 로그로 근본 원인 찾기

journalctl -u openstack-cinder-volume -n 300 --no-pager

볼륨 생성 실패 원인은 대부분 여기서 실마리가 나옵니다. 드라이버 예외, 인증 실패, 디바이스 생성 실패, 명령 실행 오류가 다 이쪽에 남습니다. 처음엔 이게 뭔가 싶었는데, 에러 한 줄보다 바로 위아래 문맥이 더 중요하더라고요.

4-3. 백엔드 직접 확인하기

LVM 백엔드라면 볼륨 그룹이 실제로 보이는지 확인합니다.

vgs
lvs
pvs

Ceph RBD 백엔드라면 풀 접근이 되는지, 인증이 맞는지 확인합니다.

ceph -s
rbd ls <POOL_NAME>

여기서 막히면 Cinder 문제가 아니라 사실상 백엔드 스토리지 문제인 경우가 많습니다. 이럴 때는 접근 방향을 바꿔야 합니다.

5. 흔한 원인과 해결책: 빠르게 참고할 표

제가 자주 봤던 패턴을 표로 정리해보겠습니다. 운영 중이면 이 표만 보고도 대략 감이 올 때가 있습니다.

증상	가능한 원인	확인 포인트	해결 방향
볼륨이 계속 creating 상태	백엔드 응답 지연 또는 작업 멈춤	cinder-volume 로그, 백엔드 상태	백엔드 연결 확인, stuck 작업 정리
즉시 error 상태로 전환	드라이버 설정 오류	cinder.conf, volume_backend_name	설정값 정합성 수정 후 서비스 재시작
No valid backend	스케줄러가 사용 가능한 백엔드 없음	scheduler 로그, capacity 보고값	backend 등록 상태와 용량 정보 점검
권한 관련 오류	스토리지 인증 또는 OS 권한 부족	Ceph keyring, LVM 실행 권한	자격 증명과 실행 계정 권한 수정
간헐적 실패	네트워크 또는 메시지 큐 지연	MQ, DB, 관리 네트워크 지연	인프라 레이어 상태 함께 점검

5-1. 설정 파일에서 자주 실수하는 부분

[DEFAULT]
enabled_backends = lvm

[lvm]
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
volume_group = cinder-volumes
volume_backend_name = LVM
target_helper = tgtadm

여기서 enabled_backends와 섹션 이름, volume_backend_name이 꼬이면 스케줄러가 백엔드를 인식하지 못합니다. 저는 예전에 섹션 이름은 lvm인데 다른 쪽 설정에서 백엔드 이름을 다르게 참조해둬서 몇 시간을 날렸습니다. 정말 삽질했네요.

수정 후에는 보통 관련 서비스를 다시 올려줘야 합니다.

systemctl restart openstack-cinder-volume
systemctl restart openstack-cinder-scheduler

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. 해결책 검증하기: 실제로 동작하는지 확인

원인을 수정했다면 반드시 재현 테스트를 해봐야 합니다. 저는 아래 순서대로 확인합니다.

1. 테스트용 소형 볼륨 생성
2. 상태가 available로 바뀌는지 확인
3. 인스턴스에 attach(연결) 테스트
4. 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 Trove vs RDS 마이그레이션, 왜 AWS RDS로 옮겼나
• OpenStack TCO 분석: VMware 대안, 실제 비용은 얼마나 줄어드나?
• MicroStack 1년 사용 후기: 홈랩에서 프로덕션까지