[OpenStack] RDO OpenStack 마이그레이션: DevStack에서 운영형 배포로 전환하기

목차

• 1. 왜 DevStack에서 RDO OpenStack으로 옮기게 되나
• 2. 개념부터 정리: DevStack과 RDO의 차이
• 3. 마이그레이션 전에 반드시 정리할 체크리스트
• 4. 실전 구현 1: DevStack 환경 백업과 추출
• 4-1. 설정 파일과 데이터 백업
• 4-2. 이미지와 중요 리소스 추출
• 5. 실전 구현 2: RDO 설치와 운영형 구조 맞추기
• 5-1. 랩 검증용 배포 예시
• 5-2. 네트워크 설계 예시
• 5-3. 기본 검증 명령
• 6. 주의사항과 트러블슈팅: 제가 실제로 막혔던 지점들
• 6-1. ⚠️ Neutron 브리지 매핑 불일치
• 6-2. ⚠️ 보안그룹과 메타데이터 접근 차이
• 6-3. ⚠️ 이미지 포맷과 드라이버 기대값 차이
• 7. 검증과 결과 확인: 옮긴 뒤 무엇을 봐야 하나
• 8. 정리와 FAQ: DevStack 프로덕션 전환 전에 꼭 생각할 점
• 자주 묻는 질문

RDO OpenStack 마이그레이션: 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(호라이즌, 웹 대시보드)까지 열리는데, 며칠 지나고 설정을 다시 손보려 하면 어디서 바꿨는지 기억이 안 나는 경우요. 저도 그랬거든요. 그래서 먼저 개념을 분리해서 봐야 합니다.

항목	DevStack	RDO OpenStack
주된 목적	개발, 테스트, API 검증	운영형 배포와 패키지 기반 관리
배포 방식	스크립트 중심	패키지 및 배포 도구 중심
구성 관리	실험에 유리	역할 분리와 반복 배포에 유리
추천 용도	랩, 학습, 기능 확인	장기 운영 검토, 표준화된 환경

OpenStack 배포판 선택에서 중요한 건 "무엇이 더 고급이냐"가 아니에요. 내 환경에서 변경 관리와 장애 대응이 가능한가, 이 질문이 더 중요합니다. 쉽게 말해 DevStack은 '빨리 시작하는 도구'이고, RDO는 '운영 구조를 갖춰 가는 출발점'에 가깝습니다.

3. 마이그레이션 전에 반드시 정리할 체크리스트

여기서 바로 설치로 들어가면 삽질 확률이 꽤 높아요. 저는 이 단계를 가볍게 봤다가 네트워크 이름하고 브리지 매핑을 뒤엎는 바람에 시간을 좀 썼습니다. 드디어 됐다 싶었는데 인스턴스가 외부 통신이 안 되더라고요.

1. 현재 리소스 인벤토리 작성: 인스턴스, 이미지, 볼륨, 플로팅 IP, 보안그룹 목록 정리
2. 네트워크 설계 고정: Management(관리망), Provider(프로바이더망), Tenant(테넌트망) 구분
3. 서비스 우선순위 지정: 어떤 워크로드를 먼저 옮길지 결정
4. 다운타임 기준 수립: 이미지 기반 재배포인지, 데이터 복제인지 미리 확정
5. 백업 확보: 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으로 빨리 띄우고 끝내려다가, 결국 역할 분리 구조를 다시 고민하게 됐어요. 그래서 테스트용과 운영형 설계를 분리해서 접근했습니다.

5-1. 랩 검증용 배포 예시

sudo dnf install -y openstack-packstack
sudo packstack --allinone

이 방식은 랩이나 기능 검증에는 편해요. 다만 운영형으로 가려면 Controller(컨트롤러), Compute(컴퓨트), Network(네트워크) 역할을 분리해서 보는 쪽이 낫습니다.

5-2. 네트워크 설계 예시

[network]
management_interface=ens192
provider_interface=ens224
bridge_mappings=physnet1:br-ex
external_network=public
floating_ip_cidr=203.0.113.0/24

위 예시는 개념 설명용이에요. 실제 인터페이스 이름과 대역은 환경에 맞게 바꾸셔야 합니다. 저도 처음엔 브리지 이름을 대충 맞췄다가 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. 검증과 결과 확인: 옮긴 뒤 무엇을 봐야 하나

운 좋게 인스턴스가 부팅됐다고 끝이 아니에요. 여기서부터가 진짜 검증입니다. 저는 아래 순서대로 확인했습니다.

1. 서비스 상태 확인: API, 스케줄러, 네트워크 에이전트
2. 테스트 인스턴스 생성: 신규 부팅이 되는지 확인
3. 외부 통신 확인: 플로팅 IP, NAT, 보안그룹 확인
4. 스토리지 검증: 볼륨 생성, 연결, 분리 테스트
5. 이미지 재사용성 확인: 기존 백업 이미지로 재배포 테스트

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의 차이, 이전 체크리스트, 검증 포인트를 한 장으로 정리한 요약 이미지입니다.

📚 함께 읽으면 좋은 글

• OpenStack Magnum Kubernetes 운영: 6개월 회고와 교훈
• DevStack 환경에서 OpenStack 서비스 간 연동 문제 해결 가이드
• OpenStack Glance 이미지 관리, 효율적인 스토리지 활용 전략
• LVM 볼륨 확장 및 축소: 실전 마이그레이션 시나리오 분석
• 벡터 DB Qdrant vs Chroma: 1년 사용 후기 및 마이그레이션 고려사항