목차
- 왜 OpenStack 업그레이드가 까다로운가
- OpenStack 업그레이드 전 꼭 봐야 할 10가지 체크리스트
- 업그레이드 방식 비교: 인플레이스 vs 블루그린 관점
- 실전 구현: OpenStack 업그레이드 작업 순서
- 1. 현재 상태 수집
- 2. 데이터베이스와 설정 백업
- 3. 유지보수 창 공지와 워크로드 정리
- 4. 컨트롤 플레인부터 순차 업그레이드
- 5. Neutron과 Cinder는 연결 관계를 같이 본다
- 6. 컴퓨트 노드는 소수부터 검증
- 설정 파일에서 자주 놓치는 포인트
- ⚠️ 실제 많이 겪는 문제와 트러블슈팅
- DB migration은 끝났는데 서비스가 안 붙는 경우
- 네트워크 에이전트가 살아 있는데 포트 생성이 실패하는 경우
- 인스턴스는 생성되는데 콘솔 접속이 안 되는 경우
- 롤백이 필요한데 되돌릴 순서가 없는 경우
- 검증: 업그레이드 후 무엇을 확인해야 하나
- 제가 정리해보는 OpenStack 베스트 프랙티스
- 정리: 체크리스트 기반으로 움직이면 성공 확률이 올라갑니다
- 자주 묻는 질문
- Q. OpenStack 업그레이드는 무중단으로 가능한가요?
- Q. 테스트 환경이 작아도 도움이 되나요?
- Q. 가장 먼저 자동화해야 할 부분은 뭔가요?
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로 비교해보세요.
diff -u /root/backup/etc-nova/nova.conf /etc/nova/nova.conf
diff -u /root/backup/etc-neutron/neutron.conf /etc/neutron/neutron.conf
⚠️ 실제 많이 겪는 문제와 트러블슈팅
DB migration은 끝났는데 서비스가 안 붙는 경우
이건 생각보다 흔합니다. 서비스 계정 권한, 커넥션 문자열, 캐시, 메시지 큐 인증 정보가 미묘하게 어긋난 경우가 많더라고요. 로그에서 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. 가장 먼저 자동화해야 할 부분은 뭔가요?
상태 수집, 백업, 검증 명령 실행 결과 저장입니다. 이 세 가지가 자동화되면 반복 작업이 훨씬 안정적이 됩니다.
'IT > openstack' 카테고리의 다른 글
| [OpenStack] OpenStack에서 Ollama로 프라이빗 LLM 추론 환경 구축하기 (0) | 2026.08.07 |
|---|---|
| [OpenStack] OpenStack 프라이빗 클라우드 보안 강화: 최신 감사 보고서 분석 및 대응 전략 (0) | 2026.08.04 |
| [OpenStack] 테넌트 쿼터로 클라우드 비용 효율화하기 (0) | 2026.08.04 |
| [OpenStack] OpenStack VXLAN 오버레이 네트워크 성능 벤치마크 가이드 (0) | 2026.08.01 |
| [OpenStack] OpenStack Manila 도입 1년 회고 (0) | 2026.08.01 |
| [OpenStack] OpenStack Floating IP 연결 문제 해결: 보안 그룹 디버깅 (1) | 2026.07.28 |
