지난 편까지 DevStack을 홈랩에 올리며 CPU·Neutron·Glance·Placement에서 연달아 부딪히고 하나씩 해결했습니다. 이번 편은 그 여정의 솔직한 후기와 교훈입니다. 결과를 미화하지 않고, 홈랩에서 DevStack에 도전할 분께 실질적인 지도를 남기려 합니다.
1. 어디까지 됐고, 무엇이 남았나
정직하게 말하면 “완벽한 원클릭 성공”은 아니었습니다.
✅ 코어 서비스 전부 기동(Keystone·Glance·Nova·Neutron·Cinder·Placement)
✅ geneve 테넌트 네트워크 생성 성공, 하이퍼바이저 등록, 이미지 업로드, 플레이버 확인
❌ 인스턴스 최종 부팅은 placement 자원 클래스 누락으로 막힘 — 여러 번의 부분 설치가 누적돼 생긴 불일치가 근본 원인
즉 OpenStack의 뼈대는 다 세웠지만, 마지막 조립이 어긋난 상태였습니다. 그리고 그 어긋남의 원인까지 정확히 짚었다는 게 이 도전의 진짜 소득입니다.
2. 가장 큰 교훈 — “깨끗한 상태에서 한 번에”
이번 삽질의 뿌리는 하나였습니다: 중간에 실패한 설치 위에 계속 재시도한 것. DevStack은 실행 때마다 여러 서비스의 DB를 다시 만들고 마무리 단계를 수행하는데, 앞 단계에서 죽으면 뒷 단계가 통째로 생략됩니다. 그 위에 또 돌리면 서로 다른 실행의 잔재가 뒤섞여 새로운 증상이 끝없이 나옵니다.
다음엔 실패하면 미련 없이 ./clean.sh로 초기화하고, 모든 수정을 local.conf에 미리 반영한 뒤 깨끗한 상태에서 한 번에 완주시키겠습니다.
3. 홈랩 DevStack 체크리스트 (다음 도전용)
항목
이유
OS는 Ubuntu (22.04/24.04)
DevStack 공식 지원
VM CPU 타입 = host
x86-64-v2 미노출 시 NumPy 크래시
RAM 12GB+ / 디스크 40GB+
올인원 최소선
local.conf에 geneve 명시
테넌트 네트워크 할당 실패 방지
실패 시 clean.sh 후 재시작
부분 설치 누적 방지(가장 중요)
완주 후에도 서비스 재시작 점검
엔드포인트/동기화 지연 대응
4. DevStack에 대한 현실 감각
DevStack은 “개발/학습용”입니다. 운영용이 아니고, 재부팅하면 상태가 깨지기도 합니다. 공부하고 부수고 다시 까는 용도로 쓰세요.
무겁습니다. 올인원도 12~16GB를 먹고, 설치에 수십 분이 걸립니다. 홈랩에선 “쓸 때만 켜는 랩”이 현실적입니다.
그럼에도 배움은 큽니다. 이 과정에서 CPU 가상화(x86-64-v2), Neutron의 geneve, placement의 자원 모델, 서비스 간 의존성을 에러를 통해 몸으로 익혔습니다. 매끄러운 성공보다 이 삽질에서 더 많이 배웠습니다.
5. 마치며
“튜토리얼대로 했는데 왜 안 되지?”는 홈랩의 일상입니다. 이번 DevStack 도전도 7번 넘게 깨졌지만, 각 실패의 원인을 파고드는 과정 자체가 클라우드 인프라를 이해하는 가장 빠른 길이었습니다. 다음엔 clean.sh 원샷으로 완주시키고, 실제 인스턴스를 띄워 SSH로 접속하는 순간까지 이어가는 후속편으로 돌아오겠습니다. 홈랩에서 프라이빗 클라우드에 도전하는 분들, 깨져도 그게 정상입니다. 원인을 하나씩 잡으면 됩니다.
지난 편에서 CPU 함정을 넘었습니다. 하지만 그건 시작이었습니다. DevStack이 완주할 때까지 Neutron → Glance → Nova/Placement에서 연달아 막혔거든요. 이번 편은 그 실제 에러들과 원인, 그리고 관통하는 하나의 패턴을 정리합니다. 같은 벽을 만난 분께 지도가 되길 바랍니다.
벽 2. 테넌트 네트워크 생성 실패 (503)
다시 돌리자 이번엔 네트워크 생성에서 죽었습니다.
HttpException: 503: No project network is available for allocation.
서비스·네트워크·이미지가 다 됐는데 인스턴스가 ERROR. 이유는 “No valid host was found”. 하이퍼바이저는 up인데 왜? nova-compute 로그가 진짜 원인을 보여줬습니다.
400 Bad Request: Unknown resource class in inventory ...
No such resource class MEMORY_MB.
즉 placement DB에 표준 자원 클래스(MEMORY_MB·VCPU·DISK_GB)가 로드되지 않아서, nova-compute가 자원 인벤토리를 placement에 등록하지 못했습니다. 인벤토리가 없으니 스케줄러가 “쓸 수 있는 호스트 없음”으로 판단한 거죠.
관통하는 하나의 패턴
벽 3·4·5를 보면 공통점이 보입니다.
서비스 프로세스는 떠 있는데, 그 뒤에 와야 할 “초기화·동기화·등록”이 안 끝나 있다.
geneve 풀 동기화, glance 엔드포인트, placement 자원 클래스 — 전부 stack.sh가 끝까지 완주하며 해줬어야 할 마무리 단계입니다. 제 경우 stack.sh가 중간에 여러 번 죽으면서 이 마무리들이 제각각 미완성으로 남았고, 그래서 재시도할 때마다 “부분적으로만 살아있는” 상태가 겹쳐 새 증상이 계속 튀어나온 겁니다.
여기서 배운 교훈: DevStack은 “깨끗한 상태에서 한 번에 완주”가 생명입니다. 중간 실패 후 그 위에 계속 재시도하면, 서로 다른 실행의 잔재가 섞여 디버깅이 미궁에 빠집니다. 다음 편에서 이 교훈과 현실적인 후기를 정리하겠습니다.
프라이빗 클라우드를 제대로 공부하려면 OpenStack을 직접 깔아봐야 합니다. 가장 빠른 길이 DevStack — 스크립트 하나로 올인원 OpenStack을 올려주는 개발/학습용 도구죠. 저는 이걸 Proxmox 홈랩에 올려봤습니다. 결론부터 솔직히 말하면 한 방에 안 됐고, 여러 번 깨졌습니다. 이번 편은 설치 준비부터 첫 번째 벽까지의 실전 기록입니다.
1. 먼저 정한 것 — OS는 Ubuntu
제 홈랩엔 Rocky 9 설치용 VM이 있었지만, DevStack엔 안 썼습니다. DevStack은 사실상 Ubuntu 전용이거든요(공식 지원·테스트가 우분투 중심). Rocky/CentOS는 지원이 불안정합니다. 그래서 깨끗한 Ubuntu 24.04로 갔습니다.
RuntimeError: NumPy was built with baseline optimizations:
(X86_V2) but your machine doesn't support: (X86_V2).
원인은 가상 CPU 타입이었습니다. Proxmox VM의 기본 CPU 타입(kvm64)은 호환성을 위해 최신 명령어셋(SSE4.2 등, x86-64-v2)을 감춥니다. 그런데 요즘 NumPy 휠은 x86-64-v2를 전제로 빌드돼서, 그 명령어가 없으면 임포트 단계에서 크래시합니다. nova의 콘솔 프록시가 NumPy를 쓰다 죽은 거죠.
해결은 지난 KVM 글에서 다룬 바로 그 포인트 — CPU 타입을 host로 바꿔 물리 CPU 기능을 그대로 노출하는 것이었습니다.
qm stop 200
qm set 200 --cpu host # 물리 i5의 명령어셋 그대로 노출
qm start 200
# VM 안에서 확인 — 이제 노출됨
grep -o -m1 sse4_2 /proc/cpuinfo # sse4_2
grep -o -m1 avx2 /proc/cpuinfo # avx2
이건 일반 DevStack 튜토리얼엔 없는 함정입니다. 물리 서버나 워크스테이션에선 안 생기고, “기본 CPU 타입 가상머신”에서만 터지거든요. 홈랩에서 VM으로 OpenStack·AI 라이브러리를 돌린다면 --cpu host는 기본으로 챙기세요.
다음 편
CPU를 고치고 다시 ./stack.sh를 돌렸습니다. 그런데 이번엔 네트워크(Neutron)에서, 그다음엔 Glance에서, 또 placement에서 연달아 막혔습니다. 다음 편에서 이 “서비스는 뜨는데 안 되는” 연속 삽질과 각각의 원인을 낱낱이 분석합니다. DevStack이 홈랩에서 왜 만만치 않은지, 제대로 보여드리겠습니다.
RDO OpenStack 마이그레이션 이야기는 생각보다 많은 분들이 한 번쯤 부딪히는 주제입니다. 처음엔 DevStack(데브스택, OpenStack 개발·테스트용 빠른 배포 도구)으로 가볍게 올려 봤다가, 서비스가 붙고 VM이 늘고 네트워크가 꼬이기 시작하면 그때부터 고민이 깊어지거든요. 저도 홈랩에서 시작했다가 “이걸 계속 DevStack으로 끌고 가는 게 맞나?” 싶은 순간이 왔었습니다. 처음엔 이게 뭔가 싶었는데, 막상 하나씩 뜯어보니 핵심은 단순했습니다. 개발 편의 중심 환경을 운영형 구조로 바꾸는 일, 바로 그겁니다.
특히 DevStack 프로덕션 전환을 고민하시는 분들이라면, 단순히 설치만 다시 하는 문제가 아니라 Nova(노바, 컴퓨트 서비스), Neutron(뉴트론, 네트워크 서비스), Glance(글랜스, 이미지 서비스), Cinder(신더, 블록 스토리지) 같은 구성요소를 어떻게 옮기고 검증할지까지 같이 봐야 합니다. 여기서 중요한 포인트! RDO는 Red Hat 계열 생태계에서 OpenStack 패키지를 다루기 편하게 제공하는 배포판 계열로 많이 이야기되기 때문에, DevStack 다음 단계의 후보로 자주 검토되더라고요.
DevStack 단일 또는 소규모 테스트 환경에서 RDO 기반 역할 분리 구조로 옮겨 가는 흐름을 한눈에 보여주는 이미지입니다.
1. 왜 DevStack에서 RDO OpenStack으로 옮기게 되나
쉽게 말해 DevStack은 빨리 띄워서 기능을 확인하는 데 최적화되어 있어요. 반대로 운영 관점에서는 아쉬운 부분이 꽤 보입니다. 서비스 재기동 순서, 설정 누적 관리, 패키지 일관성, 장기 운영 시 변경 추적 같은 부분에서요. 저도 처음엔 “테스트 잘 되는데 굳이?”라고 생각했는데, 장애를 두 번 겪고 생각이 바뀌었습니다 ㅎㅎ
DevStack: 빠른 실험, API 테스트, 기능 검증에 강점
RDO: 패키지 기반 운영, 구성 관리, 역할 분리 설계에 유리
핵심 차이: 편의성 중심이냐, 운영 일관성 중심이냐죠
특히 클라우드 환경 이전에서는 “서비스가 떠 있느냐”보다 “문제가 났을 때 추적 가능한가”가 더 중요합니다. 제가 직접 해보니, 이 시점부터는 설치 속도보다 운영 구조가 훨씬 중요해지더라고요.
2. 개념부터 정리: DevStack과 RDO의 차이
혹시 이런 경험 있으신가요? DevStack으로는 금방 Horizon(호라이즌, 웹 대시보드)까지 열리는데, 며칠 지나고 설정을 다시 손보려 하면 어디서 바꿨는지 기억이 안 나는 경우요. 저도 그랬거든요. 그래서 먼저 개념을 분리해서 봐야 합니다.
OpenStack 배포판 선택에서 중요한 건 “무엇이 더 고급이냐”가 아니에요. 내 환경에서 변경 관리와 장애 대응이 가능한가, 이 질문이 더 중요합니다. 쉽게 말해 DevStack은 ‘빨리 시작하는 도구’이고, RDO는 ‘운영 구조를 갖춰 가는 출발점’에 가깝습니다.
3. 마이그레이션 전에 반드시 정리할 체크리스트
여기서 바로 설치로 들어가면 삽질 확률이 꽤 높아요. 저는 이 단계를 가볍게 봤다가 네트워크 이름하고 브리지 매핑을 뒤엎는 바람에 시간을 좀 썼습니다. 드디어 됐다 싶었는데 인스턴스가 외부 통신이 안 되더라고요.
현재 리소스 인벤토리 작성: 인스턴스, 이미지, 볼륨, 플로팅 IP, 보안그룹 목록 정리
네트워크 설계 고정: Management(관리망), Provider(프로바이더망), Tenant(테넌트망) 구분
서비스 우선순위 지정: 어떤 워크로드를 먼저 옮길지 결정
다운타임 기준 수립: 이미지 기반 재배포인지, 데이터 복제인지 미리 확정
백업 확보: DB, 설정 파일, 이미지, 중요한 볼륨 스냅샷 확보
아래처럼 최소한의 현황 수집 명령은 먼저 뽑아 두는 걸 권합니다.
openstack service list
openstack endpoint list
openstack hypervisor list
openstack server list --all-projects
openstack image list
openstack volume list --all-projects
openstack network list
openstack subnet list
openstack router list
openstack security group list
이 출력 결과를 저장해 두면, 나중에 클라우드 환경 이전 검증할 때 비교 기준이 생깁니다. 이거 진짜 편하더라고요.
4. 실전 구현 1: DevStack 환경 백업과 추출
제가 실제로 먼저 했던 건 “새 환경 설치”가 아니라 “기존 환경을 최대한 읽을 수 있게 만드는 것”이었어요. 그래야 옮긴 뒤에 빠진 걸 찾을 수 있거든요.
4-1. 설정 파일과 데이터 백업
sudo mkdir -p /backup/devstack
sudo cp -a /etc/nova /backup/devstack/
sudo cp -a /etc/neutron /backup/devstack/
sudo cp -a /etc/glance /backup/devstack/
sudo cp -a /etc/cinder /backup/devstack/
sudo mysqldump --all-databases > /backup/devstack/openstack-all.sql
물론 실제 경로와 데이터베이스 접속 방식은 환경마다 다릅니다. 중요한 건 서비스 설정과 메타데이터를 같이 남겨 두는 것이에요.
4-2. 이미지와 중요 리소스 추출
mkdir -p ~/migration/images
for id in $(openstack image list -f value -c ID); do
name=$(openstack image show "$id" -f value -c name | tr ' ' '_')
openstack image save --file ~/migration/images/${name}.qcow2 "$id"
done
볼륨 기반 워크로드는 더 신중해야 해요. 인스턴스 이미지로만 끝나는 게 아니라 애플리케이션 데이터 정합성까지 봐야 하니까요. 데이터베이스가 올라간 인스턴스라면 파일 복사 전에 서비스 정지나 스냅샷 정책을 꼭 정해 두셔야 합니다.
기존 DevStack에서 이미지, 설정, 데이터베이스 메타데이터를 백업하는 절차를 설명하는 이미지입니다.
5. 실전 구현 2: RDO 설치와 운영형 구조 맞추기
이제 RDO 설치 단계네요. 여기서는 “한 번에 완성”보다 “먼저 표준 구조를 세운다”가 중요합니다. 저는 처음에 all-in-one으로 빨리 띄우고 끝내려다가, 결국 역할 분리 구조를 다시 고민하게 됐어요. 그래서 테스트용과 운영형 설계를 분리해서 접근했습니다.
위 예시는 개념 설명용이에요. 실제 인터페이스 이름과 대역은 환경에 맞게 바꾸셔야 합니다. 저도 처음엔 브리지 이름을 대충 맞췄다가 Neutron L3 에이전트가 제대로 붙지 않아서 한참 봤습니다.
5-3. 기본 검증 명령
openstack compute service list
openstack network agent list
openstack catalog list
openstack hypervisor stats show
이 단계에서 서비스 등록과 에이전트 상태가 깔끔하게 보이면 다음으로 넘어가도 돼요. 반대로 여기서 빨간불이 보이면, 워크로드부터 옮기지 마시고 구조부터 다시 점검하세요. 경험상 이 순서가 시간을 아낍니다.
6. 주의사항과 트러블슈팅: 제가 실제로 막혔던 지점들
RDO OpenStack 마이그레이션에서 제일 많이 막히는 건 화려한 기능이 아니라 기본값 차이에요. 진짜 별거 아닌 설정 하나 때문에 반나절이 날아가더라고요.
6-1. ⚠️ Neutron 브리지 매핑 불일치
DevStack에서는 자동으로 맞아 들어가던 부분이 RDO에서는 더 명시적으로 보여요. physnet 이름, OVS(오픈 브이스위치) 브리지, NIC 매핑이 안 맞으면 외부 통신이 바로 안 됩니다.
증상: 플로팅 IP 연결은 되는데 외부 통신 실패
확인 포인트: bridge_mappings, external bridge, provider network 설정
해결: 물리 NIC와 브리지 연결을 다시 확인하고 에이전트 재기동
6-2. ⚠️ 보안그룹과 메타데이터 접근 차이
인스턴스는 떴는데 SSH가 안 붙는 경우, 의외로 보안그룹이 원인인 경우가 많아요. 메타데이터 서비스 경로도 같이 봐야 하고요.
openstack security group rule list default
openstack port list --server <SERVER_ID>
ping -c 3 <FLOATING_IP>
ssh -i ~/.ssh/id_rsa cloud-user@<FLOATING_IP>
6-3. ⚠️ 이미지 포맷과 드라이버 기대값 차이
Glance 이미지 자체는 옮겨졌는데 부팅이 실패하는 경우도 있었어요. 이럴 때는 이미지 속성, 디스크 포맷, 하이퍼바이저 기대값을 같이 확인해야 합니다.
qcow2인지 raw인지 확인
virtio 드라이버 지원 여부 확인
cloud-init(클라우드 이닛, 초기 설정 자동화) 동작 여부 확인
저도 처음엔 “이미지만 있으면 끝 아닌가?” 했는데, 실제로 써보니까 인스턴스 부팅 옵션이 미묘하게 달라서 예상 외로 시간이 걸렸어요.
RDO 환경에서 네트워크 브리지, 에이전트 상태, 서비스 정상 여부를 검증하는 장면을 보여주는 이미지입니다.
7. 검증과 결과 확인: 옮긴 뒤 무엇을 봐야 하나
운 좋게 인스턴스가 부팅됐다고 끝이 아니에요. 여기서부터가 진짜 검증입니다. 저는 아래 순서대로 확인했습니다.
서비스 상태 확인: API, 스케줄러, 네트워크 에이전트
테스트 인스턴스 생성: 신규 부팅이 되는지 확인
외부 통신 확인: 플로팅 IP, NAT, 보안그룹 확인
스토리지 검증: 볼륨 생성, 연결, 분리 테스트
이미지 재사용성 확인: 기존 백업 이미지로 재배포 테스트
openstack server create \
--flavor m1.small \
--image test-image \
--network private \
--security-group default \
test-vm
openstack server list
openstack console log show test-vm
openstack floating ip create public
검증이 끝나면 꼭 결과를 문서화해 두세요. 어떤 네트워크 이름을 썼는지, 어떤 보안그룹 규칙이 필요한지, 어떤 이미지가 정상 부팅되는지 남겨 두면 다음 노드 증설 때 훨씬 수월합니다. 이건 멘토링할 때도 늘 강조하는 부분이에요.
🎉 개인적으로 가장 큰 성과는 “문제가 나도 어디를 봐야 하는지 감이 생겼다”는 점이었어요. DevStack에서는 빠르게 실험할 수 있었고, RDO 쪽으로 오면서 운영 기준선이 생겼습니다.
인스턴스 생성, 네트워크 연결, 서비스 상태가 정상으로 확인된 결과 화면을 표현하는 이미지입니다.
8. 정리와 FAQ: DevStack 프로덕션 전환 전에 꼭 생각할 점
결론부터 말씀드리면, DevStack에서 RDO OpenStack으로 마이그레이션은 단순 재설치가 아니라 운영 철학을 바꾸는 작업에 가깝습니다. 빨리 띄우는 환경에서, 반복 가능하고 설명 가능한 환경으로 넘어가는 거죠. 저도 처음엔 헷갈렸는데, 기준을 딱 하나로 잡으니 훨씬 쉬웠어요. “이 구성이 다음 달에도 내가 설명할 수 있는가?” 바로 그 질문이에요.
다음 글에서는 이미지 카탈로그 정리, 네트워크 설계 분리, 그리고 베어메탈 자원과 연동할 때 체크할 포인트도 다뤄볼 예정입니다. 이전 글에서 다뤘던 홈랩 네트워크 설계 글과 연결해서 보시면 더 이해가 잘 되실 겁니다.
자주 묻는 질문
Q. DevStack을 그대로 운영에 써도 되나요? 짧게 말씀드리면 권장하긴 어려워요. 테스트와 학습에는 정말 좋지만, 장기 운영과 변경 관리까지 생각하면 운영형 구조 검토가 필요하더라고요.
Q. RDO만이 정답인가요? 아닙니다. 다만 Red Hat 계열 환경과 패키지 기반 운영을 선호한다면 좋은 후보가 됩니다. 결국 OpenStack 배포판 선택은 팀 역량과 운영 기준에 달렸어요.
Q. 다운타임 없이 이전할 수 있나요? 워크로드 성격에 따라 다릅니다. 상태 저장 서비스는 별도 복제 전략이 필요하고, 무상태 워크로드는 이미지 기반 재배포가 비교적 수월해요.
💡 마지막 팁 하나만 드리면, 처음부터 완벽하게 옮기려 하지 마세요. 제 경험상 제일 잘 되는 방법은 작은 서비스 하나를 끝까지 이전하고 검증한 뒤 패턴을 복제하는 방식이었어요.
DevStack과 RDO의 차이, 이전 체크리스트, 검증 포인트를 한 장으로 정리한 요약 이미지입니다.
DevStack OpenStack 연동 문제는 생각보다 자주 만납니다. 설치는 얼추 끝난 것 같은데 인스턴스가 안 뜨고, 네트워크가 안 붙고, 이미지 조회는 되는데 부팅은 실패하고, 로그를 보면 Keystone(키스톤, 인증 서비스) 쪽 인증 에러가 한 줄씩 튀어나오거든요. 저도 홈랩에서 개발 환경을 구성하면서 이런 삽질을 꽤 했더라고요. 처음엔 서비스가 각각 살아 있으면 되는 줄 알았는데, 실제로는 서비스 간 엔드포인트(endpoint, 접속 지점), 메시지 큐(message queue), 데이터베이스(database), 서비스 사용자(service user) 권한이 한 군데만 어긋나도 전체 흐름이 무너집니다.
이번 글은 제품 홍보나 이론 소개가 아니라, 제가 직접 DevStack 개발 환경에서 반복적으로 겪었던 OpenStack 서비스 연동 문제를 어떤 순서로 확인하고 풀었는지 정리한 실전형 트러블슈팅 가이드입니다. 혹시 DevStack 트러블슈팅 하다가 로그만 한참 보고 계셨다면, 이 순서대로 점검해 보시면 시간 꽤 아끼실 수 있을 겁니다.
Keystone, Nova, Neutron, Glance, Cinder가 DevStack 환경에서 어떻게 연결되는지 한눈에 보여주는 개요 이미지입니다.
1. 왜 DevStack 개발 환경에서 OpenStack 서비스 연동 문제가 자주 생길까
쉽게 말해 DevStack은 빠르게 OpenStack을 올려서 개발과 검증을 하기 위한 환경입니다. 그래서 편한 점도 많지만, 반대로 서비스가 많고 연결 지점도 많습니다. 예를 들어 Nova(노바, 컴퓨트 서비스)가 인스턴스를 띄우려면 Keystone에서 토큰 인증을 받고, Glance(글랜스, 이미지 서비스)에서 이미지를 읽고, Neutron(뉴트론, 네트워크 서비스)에서 포트를 만들고, 필요하면 Cinder(신더, 블록 스토리지)까지 붙어야 하거든요.
즉, 화면에서 보이는 실패 증상은 하나인데 원인은 여러 군데일 수 있습니다. 여기서 중요한 포인트! 증상 기준으로 보지 말고 요청 흐름 기준으로 봐야 빨리 잡힙니다. 저도 처음엔 Horizon(호라이즌, 대시보드)에서 에러만 보고 있었는데, 실제 원인은 RabbitMQ(래빗MQ, 메시지 브로커) 연결 문제였던 적도 있더라고요.
2. OpenStack 서비스 연동을 흐름으로 이해하기
OpenStack 서비스 연동을 너무 어렵게 볼 필요는 없습니다. 요청 하나가 아래처럼 지나간다고 생각하시면 됩니다.
사용자 또는 CLI가 Keystone에 인증 요청을 보냅니다.
인증이 끝나면 서비스 카탈로그(service catalog, 서비스 목록)와 토큰을 받습니다.
Nova가 Glance, Neutron, Placement 같은 다른 서비스와 통신합니다.
백엔드에서는 메시지 큐와 데이터베이스가 중간 연결을 받쳐줍니다.
문제가 생기면 API 응답, 서비스 로그, 백엔드 연결 상태 중 하나가 어긋납니다.
구성 요소
역할
연동 실패 시 흔한 증상
Keystone
인증/권한/엔드포인트 관리
401 Unauthorized, endpoint not found
Nova
가상머신 생성 및 제어
인스턴스 build 실패, scheduling 오류
Neutron
네트워크/포트/IP 관리
포트 생성 실패, floating IP 연결 불가
Glance
이미지 저장 및 조회
이미지 다운로드 실패, boot from image 오류
Cinder
볼륨 제공
볼륨 attach 실패, device not found
이 표만 머리에 넣어도 DevStack OpenStack 연동 문제를 볼 때 훨씬 덜 막막합니다. 사실 로그를 읽는 요령도 결국은 어느 서비스가 다음 서비스를 못 찾고 있는지를 보는 거거든요.
3. DevStack 트러블슈팅 전에 먼저 확인할 기본 체크리스트
본격적으로 로그 보기 전에, 저는 아래 항목부터 먼저 봅니다. 사소해 보여도 여기서 많이 걸립니다.
호스트명과 IP: 서비스가 등록된 주소와 실제 바인딩 주소가 같은지
/etc/hosts: 로컬 이름 해석이 꼬이지 않았는지
시스템 시간: 토큰 인증 문제를 만들 정도로 시간 차이가 없는지
포트 리스닝 상태: 각 API 서비스가 실제로 떠 있는지
환경 변수: admin-openrc 같은 OpenRC 파일을 제대로 불러왔는지
제가 직접 해보니, OpenRC를 안 읽은 상태에서 CLI 테스트를 해서 Keystone 문제로 착각한 경우가 제일 허무했습니다. 드디어 원인 찾았다 싶었는데 그냥 환경 변수 누락이더라고요.
cd ~/devstack
source openrc admin admin
openstack token issue
openstack service list
openstack endpoint list
위 명령이 정상 동작하면 최소한 Keystone 인증과 서비스 카탈로그 조회는 된다는 뜻입니다. 여기서부터 하나씩 좁혀가면 됩니다.
4. 실전 구현: DevStack 환경에서 서비스 연동 상태 점검 순서
4-1. DevStack 설정 파일부터 다시 봅니다
local.conf에 서비스 활성화가 빠져 있거나, 비밀번호 변수 구성이 엇갈리면 설치는 돼도 연동이 흔들립니다. 아래는 가장 기본적인 예시입니다.
여기서는 이미지 상태가 active 인지, 접근 권한 문제는 없는지, Nova가 해당 이미지를 실제 읽을 수 있는지 확인합니다.
5-4. RabbitMQ 또는 DB 연결 문제로 서비스가 간헐적으로 실패하는 경우
이건 더 골치 아픕니다. 같은 명령이 한 번은 되고 한 번은 안 되거든요. 저도 실제로 써보니까 간헐 장애는 오히려 더 찾기 어렵더라고요.
sudo systemctl status rabbitmq-server
sudo systemctl status mariadb
sudo journalctl -u rabbitmq-server -n 100 --no-pager
메시지 큐나 DB 연결이 흔들리면 각 서비스 로그에 timeout, reconnect, access denied 같은 메시지가 섞여 나옵니다. 이럴 때는 개별 서비스보다 공통 백엔드부터 의심하는 게 빠릅니다.
여러 OpenStack 서비스 로그를 비교해서 장애 지점을 추적하는 실제 운영 감각의 트러블슈팅 이미지입니다.
6. 검증: 어디까지 확인해야 진짜 해결된 걸까
로그 한 줄 없어졌다고 끝난 건 아닙니다. 저는 아래 순서가 모두 통과하면 그제야 해결로 봅니다.
토큰 발급이 정상 동작한다.
서비스 목록과 엔드포인트가 정상 조회된다.
이미지, 네트워크, 플래버 목록 조회가 된다.
테스트 네트워크와 서브넷 생성이 된다.
테스트 인스턴스가 ACTIVE 또는 기대 상태로 전환된다.
필요 시 floating IP 연결 또는 콘솔 접속이 된다.
openstack token issue
openstack endpoint list
openstack network list
openstack subnet list
openstack image list
openstack server create --flavor m1.tiny --image cirros --network demo-net test-vm
openstack server list
openstack console url show test-vm
이 단계까지 가면 DevStack OpenStack 연동 문제는 대부분 정리됩니다. 물론 테스트 이미지나 플래버는 환경에 따라 다를 수 있으니, 현재 설치 상태에 맞게 조정하시면 됩니다.
서비스 연동이 정상화된 뒤 CLI와 대시보드에서 인스턴스, 네트워크, 이미지가 모두 보이는 결과 이미지입니다.
7. 빠른 진단 기준
증상
먼저 볼 곳
우선 점검 포인트
401 인증 오류
Keystone
OpenRC, 토큰, 서비스 사용자 비밀번호
인스턴스 생성 실패
Nova
Glance/Neutron/Placement 연동
포트 생성 실패
Neutron
agent 상태, 브리지 구성, endpoint
이미지 부팅 실패
Glance
이미지 상태, 접근 권한, API 응답
간헐적 timeout
RabbitMQ/DB
공통 백엔드 연결 안정성
이 표는 제가 실제로 자주 참고하는 기준입니다. 독자분들도 로그를 보기 전에 먼저 증상별 1차 의심 지점을 잡아두면 훨씬 덜 헤매실 겁니다.
8. 자주 묻는 질문과 실무 팁
Q1. 서비스가 모두 떠 있는데도 왜 연동이 안 될까요?
A. 프로세스가 떠 있는 것과 API 호출이 성공하는 것은 다릅니다. endpoint 등록, 권한, 환경 변수, 에이전트 상태를 같이 보셔야 합니다.
Q2. DevStack을 다시 설치하는 게 더 빠를 때도 있나요?
A. 있습니다. 특히 실험을 여러 번 반복하면서 설정이 꼬였을 때는 부분 수정보다 재구성이 빠를 때가 있더라고요. 다만 그 전에 왜 꼬였는지를 한 번 정리해 두면 다음부터 훨씬 빨라집니다.
Q3. 로그는 어디부터 봐야 하나요?
A. 사용자 요청이 처음 닿는 지점부터 보는 게 좋습니다. 예를 들어 인스턴스 생성 실패면 Nova API부터 보고, 그 다음 Neutron/Glance 쪽 연동 로그를 따라가는 방식이 효율적입니다.
💡 팁: CLI 테스트는 Horizon보다 원인 분리가 쉽습니다.
💡 팁: 한 번에 여러 문제를 고치지 말고, 한 항목씩 검증하세요.
💡 팁: 변경 전 endpoint 목록과 서비스 상태를 저장해 두면 비교가 편합니다.
인증, 네트워크, 이미지, 인스턴스 생성 문제를 어떤 순서로 점검할지 한 장으로 정리한 요약 인포그래픽입니다.
9. 마무리: DevStack 트러블슈팅의 핵심은 흐름을 보는 눈입니다
이번 글에서는 DevStack OpenStack 연동 문제를 단순히 에러 메시지별로 보는 대신, 서비스 요청 흐름 기준으로 점검하는 방법을 정리해 봤습니다. 저도 처음엔 서비스 이름이 너무 많아서 겁부터 났었는데, 실제로는 Keystone, Nova, Neutron, Glance, Cinder가 어떻게 이어지는지만 잡아도 절반은 해결되더라고요.
정리하면 이렇습니다. 인증이 되는지 확인하고, 엔드포인트가 맞는지 보고, 서비스별 실제 생성 요청을 날려보고, 공통 백엔드까지 확인한다. 이 순서가 DevStack 트러블슈팅에서 꽤 강력합니다. 다음 글에서는 DevStack 환경에서 Neutron 네트워크를 조금 더 깊게 파서, 브리지 구성과 외부 네트워크 연결 쪽도 따로 다뤄볼 예정입니다. 이전 글에서 다뤘던 OpenStack 기본 구성 이해 편이 있으시다면 같이 보시면 흐름 잡는 데 더 도움이 될 겁니다.
혹시 지금 비슷한 OpenStack 서비스 연동 문제를 겪고 계시다면, 오늘 소개한 체크리스트만 따라가도 원인 범위를 꽤 빨리 좁히실 수 있을 겁니다. 드디어 됐다! 하는 순간이 분명 오거든요. 그 맛에 또 홈랩 만지게 됩니다 ㅎㅎ
![[OpenStack] RDO OpenStack 마이그레이션: DevStack에서 운영형 배포로 전환하기](https://blog.pswq.net/wp-content/uploads/2026/07/devstack-rdo-openstack-migration-guide-thumbnail.jpg)
![[OpenStack] DevStack 환경에서 OpenStack 서비스 간 연동 문제 해결 가이드](https://blog.pswq.net/wp-content/uploads/2026/07/devstack-openstack-inter-service-troubleshooting-thumbnail.jpg)
