13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[카테고리:] openstack

  • [OpenStack] 오픈스택 플레이버 최적화로 유휴 자원 줄이기

    [OpenStack] 오픈스택 플레이버 최적화로 유휴 자원 줄이기

    목차

    [OpenStack] 오픈스택 플레이버 최적화로 유휴 자원 줄이기

    프라이빗 클라우드 운영을 하다 보면 CPU는 남는데 메모리가 먼저 바닥나거나, 반대로 스토리지는 넉넉한데 작은 워크로드가 큰 VM 사양을 계속 잡아먹는 상황을 자주 보게 됩니다. 저도 홈랩과 업무 환경에서 이런 패턴을 여러 번 겪었고, 결국 문제의 중심에는 OpenStack 플레이버 설계가 있더라고요. 처음엔 인스턴스만 잘 뜨면 된다고 생각했는데, 실제로 써보니까 플레이버가 조금만 느슨해도 유휴 자원(idle resource)이 금방 쌓이고, 그게 곧 비용 압박으로 이어졌거든요.

    특히 프라이빗 클라우드 운영에서는 퍼블릭 클라우드처럼 청구서가 바로 날아오지 않아서 체감이 늦습니다. 근데 여기서 방심하면 안 됩니다. 서버 증설, 전력, 랙 공간, 백업, 운영 시간까지 다 합치면 결국 내부 비용이 꽤 커지거든요. 그래서 오늘은 OpenStack 플레이버를 어떻게 다듬어야 자원 최적화와 비용 절감을 동시에 가져갈 수 있는지, 제가 삽질했던 포인트까지 포함해서 정리해보겠습니다.

    OpenStack 플레이버가 프라이빗 클라우드 자원 배분에 미치는 구조를 보여주는 아키텍처 이미지

    플레이버 정의가 컴퓨트 노드 자원 사용률에 어떤 영향을 주는지 한눈에 보여주는 개요 이미지입니다.

    왜 OpenStack 플레이버 최적화가 중요한가

    쉽게 말해 플레이버는 VM의 기본 체급표입니다. vCPU, RAM, root disk 같은 자원 크기를 미리 정해두고, 사용자는 그중 하나를 골라 인스턴스를 만들게 되죠. 문제는 이 체급표가 현실과 안 맞을 때 생기더라고요.

    • 너무 큰 플레이버만 있으면 작은 서비스도 과하게 큰 자원을 점유합니다.
    • 너무 많은 플레이버가 있으면 운영 기준이 흐려지고, 사용자도 뭘 골라야 할지 헷갈립니다.
    • 이름 규칙이 제각각이면 자동화 스크립트와 정책 관리가 꼬이기 쉽습니다.
    • 워크로드 특성에 맞지 않는 비율로 설계하면 CPU overcommit(오버커밋)이나 메모리 낭비가 반복됩니다.

    저도 처음엔 부서 요청이 들어올 때마다 플레이버를 하나씩 추가했었습니다. 그때는 빨리 만들어주는 게 친절이라고 생각했는데요. 시간이 지나니까 m1-medium-v2-final 같은 이름이 생기고, 용도는 겹치고, 어떤 VM은 메모리만 남고 어떤 VM은 CPU만 묶여버리는 이상한 상태가 되더라고요. 그때부터 기준을 다시 세웠고, 드디어 좀 정리가 됐습니다.

    OpenStack 플레이버 개념, 쉽게 말해 이런 겁니다

    Flavor(플레이버, 가상머신 자원 템플릿)는 Nova(노바, OpenStack의 컴퓨트 서비스)에서 인스턴스 크기를 정의하는 단위입니다. 일반적으로 아래 항목을 포함합니다.

    • vCPU: 가상 CPU 개수
    • RAM: 메모리 크기(MB 단위)
    • Disk: 루트 디스크 크기(GB 단위)
    • Ephemeral Disk: 임시 디스크가 필요한 경우 사용하는 추가 디스크
    • Swap: 스왑 영역
    • extra_specs: 스케줄링, CPU 정책, NUMA 같은 추가 속성

    여기서 중요한 포인트! 플레이버는 단순히 숫자 몇 개를 묶어놓은 게 아닙니다. 실제로는 스케줄러(scheduler, 어느 컴퓨트 노드에 올릴지 결정하는 구성요소)와 운영 정책의 기준점 역할도 해요. 예를 들어 특정 플레이버에 dedicated CPU policy(전용 CPU 정책)나 huge pages(대용량 메모리 페이지) 같은 조건을 넣으면, 같은 4 vCPU / 8GB라도 완전히 다른 자원 소비 패턴이 됩니다.

    그래서 자원 최적화를 하려면 단순히 작은 플레이버를 늘리는 게 아니라, 어떤 워크로드를 어떤 비율로 태울지를 먼저 봐야 합니다. 사실 이걸 건너뛰면 플레이버만 바꾸고 결과는 그대로인 경우가 많더라고요.

    현재 상태부터 점검해보세요: 유휴 자원은 숫자로 봐야 합니다

    제가 직접 해보니 제일 먼저 해야 할 일은 플레이버를 새로 만드는 게 아니라, 지금 어떤 플레이버가 실제로 얼마나 쓰이는지 확인하는 일이었습니다. 감으로 보면 꼭 틀립니다. 특히 오래된 환경일수록 더 그렇거든요.

    1. 현재 등록된 플레이버 목록을 확인합니다.
    2. 인스턴스별로 어떤 플레이버가 얼마나 사용 중인지 집계합니다.
    3. 컴퓨트 노드별 vCPU, 메모리 사용률과 배치 불균형을 함께 봅니다.
    4. 실사용 대비 과대 할당된 표준 플레이버를 후보로 뽑습니다.
    openstack flavor list --long

openstack server list --all-projects -f value -c ID -c Name -c Flavor

openstack hypervisor list
openstack hypervisor stats show

    CLI(Command Line Interface, 명령줄 인터페이스)로 보면 좀 투박하긴 한데, 오히려 현실이 잘 보여요. 예를 들어 플레이버는 12개인데 실제로 자주 쓰는 건 4개뿐인 경우가 꽤 많습니다. 반대로 이름은 비슷한데 메모리만 조금씩 다른 플레이버가 잔뜩 있는 환경도 있었고요.

    제가 운영하던 환경에서는 2 vCPU / 8GB 계열 플레이버가 유독 많았는데, 실제 앱은 메모리 3~4GB 수준만 쓰는 경우가 대부분이었습니다. 결국 메모리 단편화(fragmentation, 자원이 애매하게 쪼개져 남는 현상)가 심해졌고, 새 인스턴스를 띄울 때 특정 노드만 계속 부족하다는 알람이 뜨더라고요. CPU는 남는데 메모리 때문에 못 올리는 상황, 이거 꽤 자주 본답니다.

    OpenStack 플레이버 사용 편중과 자원 불균형을 보여주는 운영 대시보드 이미지

    실제 운영에서 자주 보게 되는 플레이버 사용 편중과 노드별 자원 불균형 예시를 보여주는 이미지입니다.

    표준 플레이버를 줄이고, 비율을 맞추는 게 비용 절감의 시작입니다

    여기서 중요한 건 플레이버 개수를 무조건 늘리는 게 아니라 표준화(standardization, 기준을 통일하는 작업)입니다. 저는 보통 워크로드를 세 가지로 나눠서 봅니다.

    • 범용형: 웹, API, 배치처럼 평균적인 CPU/메모리 비율
    • 메모리 집중형: 캐시, JVM, 분석 도구처럼 메모리 사용량이 큰 유형
    • 컴퓨트 집중형: 빌드, 인코딩, 일부 계산 작업처럼 CPU 사용량이 높은 유형

    이걸 바탕으로 플레이버를 단순하게 재구성하면 선택이 쉬워지고, 배치도 예측 가능해집니다. 아래는 많이 쓰는 정리 방식 예시입니다.

    구분 예시 이름 용도 설계 포인트
    범용형 gp.small / gp.medium 일반 웹, API, 업무 시스템 CPU와 메모리 비율을 균형 있게 유지
    메모리형 mem.small / mem.medium 캐시, 메모리 민감 서비스 같은 vCPU 대비 RAM 비율 확대
    컴퓨트형 cpu.small / cpu.medium 배치, 변환, CI 작업 메모리보다 CPU 효율 우선
    전용형 perf.large 성능 민감 워크로드 extra_specs로 정책 분리

    이름 규칙도 꽤 중요합니다. 저는 나중에 자동화할 걸 생각해서 접두사(prefix)를 꼭 넣어요. 예를 들면 gp, mem, cpu 같이요. 이렇게 해야 Terraform(테라폼, 인프라 코드 도구)이나 Ansible(앤서블, 자동화 도구)에서 분기하기 편하더라고요.

    참고로 플레이버를 설계할 때는 너무 세밀하게 자르는 것보다 20~30% 정도의 여유 구간을 가진 계단형 구성이 관리가 편합니다. 2GB, 3GB, 4GB, 5GB, 6GB 식으로 촘촘히 만들면 한동안은 좋아 보이는데, 운영자가 나중에 감당하기 힘들어진답니다.

    실전 구현: OpenStack 플레이버 재설계와 적용 순서

    이제 실제로 손을 대볼 차례입니다. 제가 보통 쓰는 절차는 아래 순서입니다. 한 번에 다 바꾸려고 하면 사고 나요. 저도 예전에 급하게 정리하다가 사용자한테 왜 목록이 바뀌었냐는 문의를 한꺼번에 받았거든요.

    1. 기존 플레이버 사용 현황을 수집합니다.
    2. 표준 플레이버 목록을 먼저 문서화합니다.
    3. 새 플레이버를 추가하되 기존 것은 바로 삭제하지 않습니다.
    4. 신규 배포부터 새 플레이버를 사용하게 유도합니다.
    5. 사용량이 떨어진 기존 플레이버를 단계적으로 비공개 또는 정리합니다.
    # 범용형 플레이버 생성 예시
openstack flavor create gp.small \
  --vcpus 2 \
  --ram 4096 \
  --disk 20

openstack flavor create gp.medium \
  --vcpus 4 \
  --ram 8192 \
  --disk 40

# 메모리형 플레이버 생성 예시
openstack flavor create mem.small \
  --vcpus 2 \
  --ram 8192 \
  --disk 20

# extra_specs 설정 예시
openstack flavor set perf.large \
  --property hw:cpu_policy=dedicated \
  --property hw:mem_page_size=large

    위 예시는 어디까지나 구조 예시입니다. 수치는 각 환경의 하이퍼바이저(hypervisor, 가상화 호스트) 구성과 워크로드 특성에 맞춰 잡으셔야 해요. 무작정 따라 넣는 건 추천하지 않습니다. 특히 전용 CPU 정책은 호스트 여유가 부족하면 오히려 배치 가능성이 떨어질 수 있거든요.

    실제로 써보니까 신규 플레이버를 만들고 바로 공지하는 것보다, Horizon(호라이즌, OpenStack 웹 대시보드) 또는 내부 포털에서 기본 선택지를 먼저 바꾸는 게 효과가 좋았습니다. 사용자는 기본값을 잘 따라가거든요. 이거 진짜 편하더라고요.

    표준 플레이버 생성과 정책 분리를 적용하는 과정을 시각적으로 보여주는 구성 이미지입니다.

    권장 운영 기준

    • 기존 플레이버는 즉시 삭제하지 말고 일정 기간 공존시키세요.
    • 프로젝트별 예외 요구는 별도 전용 플레이버로 격리하세요.
    • 자동 배포 템플릿에서 플레이버 이름을 하드코딩했다면 사전 점검이 필요합니다.
    • 비용 절감 효과는 VM 개수보다 호스트 증설 지연 효과에서 더 크게 나타날 수 있습니다.

    ⚠️ 제가 실제로 겪은 문제들: 트러블슈팅과 주의사항

    여기서부터가 진짜 운영 이야기예요. 문서에는 잘 안 나오는데, 실제론 이런 부분에서 많이 막힙니다.

    1. 플레이버만 줄였는데도 자원이 안 돌아오는 경우

    기존 인스턴스는 자동으로 새 플레이버를 쓰지 않아요. resize(리사이즈, 인스턴스 사양 변경)나 재배포가 필요합니다. 저도 처음엔 표준 플레이버 정리만 하면 바로 효과가 날 줄 알았는데, 기존 대형 인스턴스가 그대로 남아 있어서 체감 변화가 거의 없었습니다.

    # 인스턴스 리사이즈 예시
openstack server resize --flavor gp.small <SERVER_ID>
openstack server resize confirm <SERVER_ID>

    2. 메모리 단편화가 심해 배치가 꼬이는 경우

    플레이버 종류가 많으면 같은 총 메모리 용량이라도 애매하게 쪼개져 남아요. 이럴 때는 큰 플레이버를 무작정 유지하는 것보다, 중간 단계를 줄이고 범용형으로 수렴시키는 편이 낫더라고요.

    3. extra_specs를 너무 공격적으로 쓰는 경우

    특정 성능 요구 때문에 dedicated CPU나 huge pages를 광범위하게 쓰기 시작하면 스케줄링 제약이 커져요. 성능은 좋아질 수 있어도 전체 효율성은 오히려 떨어질 수 있습니다. 성능 민감 워크로드만 별도 클래스로 분리하는 게 안전했습니다.

    4. 이름만 바꾸고 정책은 안 바뀌는 경우

    이건 꽤 흔합니다. 이름을 optimized로 바꿔도 사용자가 여전히 가장 큰 플레이버를 고르면 의미가 없어요. 그래서 quota(쿼터, 프로젝트별 자원 한도), 기본 템플릿, 셀프서비스 포털 가이드까지 같이 손봐야 합니다.

    검증은 이렇게 보시면 됩니다: 자원 최적화가 됐는지 확인하는 법

    변경 후에는 감이 아니라 지표로 보셔야 해요. 저는 보통 아래 네 가지를 같이 봅니다.

    1. 플레이버별 인스턴스 분포가 표준 세트로 모였는지
    2. 컴퓨트 노드별 메모리/CPU 편차가 줄었는지
    3. 새 인스턴스 배치 실패가 감소했는지
    4. 호스트 증설 시점을 뒤로 미룰 수 있는지
    openstack hypervisor stats show
openstack usage show --project <PROJECT_ID>
openstack server list --all-projects --long

    제가 직접 해보니 가장 먼저 보이는 변화는 “애매하게 남는 자원”이 줄어드는 점이었어요. 예전에는 노드마다 2GB, 4GB, 6GB씩 찌꺼기처럼 남았는데 실제 배치엔 못 쓰는 경우가 많았거든요. 플레이버를 표준화하고 나니 배치 성공률이 안정되고, 신규 호스트 추가 논의를 한 템포 늦출 수 있었습니다. 프라이빗 클라우드 운영에서는 이 지점이 곧 비용 절감 효과로 이어집니다.

    🎉 특히 showback(쇼백, 내부 비용 가시화)이나 chargeback(차지백, 부서별 비용 배분) 체계가 있는 조직이라면 플레이버 표준화가 훨씬 중요합니다. 기준이 명확해야 부서별 사용 패턴도 설명하기 쉽고, 과도한 요청에 근거 있게 대응할 수 있거든요.

    OpenStack 플레이버 표준화 전후 자원 활용도 개선 결과를 보여주는 대시보드 이미지

    최적화 전후의 자원 활용도와 인스턴스 배치 효율 차이를 보여주는 결과 시각화 이미지입니다.

    자주 묻는 질문

    Q1. OpenStack 플레이버를 많이 만들수록 사용자 만족도가 높아지지 않나요?

    짧게 답하면, 꼭 그렇진 않습니다. 선택지가 너무 많으면 오히려 잘못 고를 확률이 높아져요. 표준 플레이버는 적게, 예외는 분리해서 운영하는 쪽이 장기적으로 효율적이었습니다.

    Q2. 비용 절감 효과를 어떻게 설명하면 좋을까요?

    직접적인 청구 금액보다 호스트 증설 지연, 배치 실패 감소, 유휴 자원 감소 관점으로 설명하는 게 현실적이에요. 프라이빗 클라우드 운영에서는 이게 훨씬 설득력이 있습니다.

    Q3. 기존 인스턴스는 언제 옮기는 게 좋을까요?

    서비스 영향이 적은 점검 창을 잡아서 순차적으로 resize하거나, 재배포 주기에 맞춰 천천히 전환하는 게 안전해요. 한 번에 몰아붙이면 운영팀만 고생합니다. 저도 그렇게 삽질 좀 했습니다.

    정리: 비용 절감은 작은 플레이버가 아니라 좋은 기준에서 시작됩니다

    OpenStack 플레이버 최적화의 핵심은 단순히 VM 사양을 낮추는 게 아니에요. 워크로드를 분류하고, 표준 타입을 정하고, 운영 정책과 연결하는 것이죠. 이 흐름이 잡히면 자원 최적화, 효율성 개선, 비용 절감이 같이 따라옵니다. 반대로 기준 없이 요청마다 플레이버를 추가하면 언젠가 운영 복잡도가 비용으로 돌아와요.

    혹시 지금 환경에서 플레이버 이름이 제각각이거나, 어떤 걸 없애도 되는지 감이 안 오신다면 먼저 사용 현황부터 뽑아보세요. 거기서 답이 보여요. 다음 글에서는 quota 설계와 프로젝트별 자원 정책을 어떻게 묶어야 실제 프라이빗 클라우드 운영이 편해지는지 다뤄볼 예정입니다. 이전 글에서 다룬 하이퍼바이저 자원 모니터링 글과 함께 보셔도 흐름이 더 잘 잡히실 거예요.

    OpenStack 플레이버 설계 원칙과 비용 절감 포인트를 요약한 인포그래픽

    표준화, 운영 정책, 비용 절감 포인트를 한 장으로 정리한 요약 이미지입니다.

    ✅ 오늘 내용만 실무에 적용해도, 플레이버 목록 정리와 기본값 개선만으로 꽤 큰 차이를 느끼실 가능성이 높습니다. 저도 처음엔 이게 뭔가 싶었는데, 막상 정리하고 나니 운영이 훨씬 덜 피곤해졌거든요.

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

    [OpenStack] OpenStack 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 오류처럼 보일 때도 있습니다. 특히 테스트 환경에서는 이것 때문에 시간을 꽤 쓰게 되네요.

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

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

    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

    여기까지 정상이라면 일단 급한 불은 껐다고 봐도 됩니다. 드디어 됐다! 하는 순간이 오긴 오더라고요.

    OpenStack Cinder 오류 해결 후 볼륨 생성과 attach 검증 이미지

    문제 해결 후 볼륨 상태가 정상으로 바뀌고 인스턴스에 연결된 결과를 보여주는 검증 이미지입니다.

    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 흐름도 함께 보시면 전체 그림 이해에 도움이 됩니다.

    OpenStack Cinder 오류 점검 순서를 정리한 요약 인포그래픽

    서비스, 로그, 백엔드, 검증 순서로 이어지는 Cinder 트러블슈팅 체크리스트 요약 이미지입니다.

  • [OpenStack] OpenStack Trove vs RDS 마이그레이션, 왜 AWS RDS로 옮겼나

    [OpenStack] OpenStack Trove vs RDS 마이그레이션, 왜 AWS RDS로 옮겼나

    목차

    OpenStack Trove vs RDS 마이그레이션, 제가 AWS RDS로 옮긴 이유

    OpenStack Trove vs RDS 마이그레이션을 고민하는 분들이 생각보다 많더라고요. 저도 한동안 OpenStack 환경에서 관리형 데이터베이스를 직접 운영해봤습니다. 처음엔 '우리 클라우드 안에서 끝내면 제일 깔끔하지 않을까?' 싶었는데, 막상 들어가 보니 기능보다 운영 복잡도가 더 크게 다가왔습니다. 결국 저는 Trove를 접고 AWS RDS로 옮겼습니다.

    이 글은 'Trove가 무조건 나쁘다'는 얘기를 하려는 건 아닙니다. 다만 OpenStack 관리형 DB의 한계가 어디서 드러나는지, 그리고 어떤 조직에서는 왜 AWS RDS가 더 현실적인 선택이 되는지 제 경험 기준으로 정리해보려 합니다. 지금 관리형 데이터베이스 선택 때문에 고민 중이라면, 아마 중간중간 꽤 공감되실 겁니다.

    온프레미스 OpenStack 영역과 AWS RDS 영역을 나란히 보여주는 비교 아키텍처 예시입니다.

    1. OpenStack Trove vs RDS 마이그레이션 이야기가 자주 나오는 이유

    Trove는 OpenStack 안에서 DBaaS(Database as a Service, 서비스형 데이터베이스)를 제공하는 프로젝트입니다. 사용자는 직접 VM을 띄우고 MySQL이나 PostgreSQL을 손으로 설치하지 않아도 되고, API나 CLI로 인스턴스를 만들고 관리할 수 있습니다. 개념만 보면 꽤 매력적입니다.

    문제는 여기서부터였어요. 관리형이라는 단어에 기대하는 수준이 사람마다 다르거든요. 사용자는 보통 이렇게 기대합니다.

    • 장애가 나도 복구가 빠를 것
    • 백업과 복원이 일관되게 동작할 것
    • 버전 업그레이드가 예측 가능할 것
    • 모니터링과 알림 구성이 어렵지 않을 것
    • 운영자가 밤에 덜 깨울 것

    그런데 실제 운영에 들어가면 Trove는 '완성형 관리 서비스'라기보다 OpenStack 위에 얹은 DB 배포·운영 프레임워크에 더 가깝게 느껴질 때가 있습니다. 반면 AWS RDS는 오랫동안 다듬어진 상용 관리형 서비스라서, 운영 경험이 이미 서비스 안에 녹아 있다는 느낌이 있었어요. 결국 클라우드 DB 서비스 비교를 할 때 핵심은 기능표보다도 '누가 운영 책임을 얼마나 가져가 주느냐'였습니다.

    2. OpenStack Trove vs RDS를 쉽게 설명해보면

    2-1. Trove는 어떤 성격인가

    Trove는 OpenStack 프로젝트 중 하나이고, DBaaS를 목표로 합니다. 인스턴스 생성, 데이터베이스와 사용자 관리, 백업과 복원 같은 기본 기능은 분명 있습니다. 다만 구조를 뜯어보면 Nova, Neutron, Cinder, Keystone, Swift 같은 여러 OpenStack 컴포넌트와 꽤 강하게 얽혀 있습니다. 운영 환경에 따라서는 관리 네트워크, guest agent, datastore 이미지까지 챙겨야 해서 생각보다 손이 많이 가더라고요.

    2-2. RDS는 어떤 성격인가

    AWS RDS(Relational Database Service, AWS의 관리형 관계형 DB 서비스)는 관계형 데이터베이스 운영 작업을 크게 줄여주는 서비스입니다. 인스턴스 생성, 자동 백업, 스냅샷, 시점 복구, 파라미터 그룹, 보안 그룹 연계 같은 운영 레일이 비교적 잘 정리돼 있습니다. 물론 완전 자동은 아닙니다. 설계와 튜닝은 여전히 사람이 해야 합니다. 그래도 기본 운영 레일이 잘 깔려 있다는 점은 확실히 컸습니다.

    2-3. 제가 느낀 가장 큰 차이

    항목 OpenStack Trove AWS RDS
    도입 목적 자체 OpenStack 환경에서 DBaaS 제공 AWS에서 검증된 관리형 DB 운영
    운영 난이도 인프라 팀 숙련도와 표준화 수준에 크게 좌우 상대적으로 낮고 표준화가 잘 됨
    문제 발생 시 원인 추적 컴퓨트, 네트워크, 스토리지, 이미지까지 넓게 봐야 함 서비스 경계가 비교적 명확함
    백업/복원 체감 구성과 저장소 정책에 따라 편차가 큼 자동 백업과 스냅샷 흐름이 비교적 일관적임
    확장성과 표준 운영 경험 구현 수준에 따라 다름 문서와 사례가 풍부함

    여기서 중요한 포인트는 이겁니다. Trove의 한계는 '기능이 없다'가 아니라, 운영 품질을 일정하게 유지하기가 어렵다는 데 있었습니다.

    3. 제가 Trove를 포기하게 된 실제 이유

    3-1. 장애 경계가 너무 넓었습니다

    실제로 써보면 DB 하나 문제 생겼을 때 DB 엔진만 보면 끝나는 경우가 거의 없었습니다. 인스턴스 상태, 스토리지 연결, 네트워크 정책, guest agent 동작, 이미지 상태까지 같이 봐야 했거든요. 이게 한두 번이면 괜찮은데 반복되면 운영 피로가 확 올라갑니다. 결국 Trove 운영 비용은 라이선스보다 사람 시간에서 크게 나오더라고요.

    3-2. '관리형' 기대치와 현실의 차이

    사용자 입장에서는 RDS처럼 몇 가지 옵션만 정하면 끝나는 경험을 기대합니다. 그런데 Trove는 환경에 따라 준비해야 할 게 많습니다. 이미지 관리도 신경 써야 하고, Swift 백업 저장소 정책도 따져야 하고, 네트워크 경로도 챙겨야 합니다. 인프라 팀이 강하면 운영할 수는 있지만, 결국 특정 담당자 의존도가 높아졌습니다.

    3-3. 마이그레이션 이후 운영 피로도가 확 줄었습니다

    이건 정말 체감이 컸습니다. RDS로 옮긴 뒤에는 DB 엔진 자체보다 애플리케이션 성능, 쿼리 튜닝, 파라미터 최적화에 시간을 더 쓰게 됐어요. 예전에는 '왜 인스턴스가 이 상태지?'를 먼저 봤다면, 옮긴 뒤에는 '이 쿼리가 왜 느리지?'를 먼저 보게 되더라고요. 운영자가 봐야 하는 층이 줄어드니 훨씬 낫습니다.

    4. OpenStack Trove vs RDS 마이그레이션, 저는 이렇게 진행했습니다

    아래는 제가 보통 권장하는 흐름입니다. 엔진은 예시로 MySQL 계열을 가정하되, 핵심은 절차입니다.

    1. 현재 Trove 인스턴스 상태 점검: 버전, 파라미터, 사용자, 백업 정책, 연결 애플리케이션 목록 정리
    2. RDS 목표 사양 설계: 엔진 계열, 인스턴스 클래스, 스토리지 유형, 백업 보존, 네트워크, 보안 그룹 정리
    3. 사전 덤프 테스트: 운영 전과 동일한 방식으로 내보내기와 가져오기를 리허설
    4. 애플리케이션 연결 문자열 분리: 엔드포인트 전환이 가능하도록 설정 외부화
    5. 점검 창 확보 후 최종 데이터 이전
    6. 읽기/쓰기 검증 후 DNS 또는 설정 전환

    4-1. Trove 쪽 사전 점검

    openstack database instance list
openstack database instance show mydb
openstack database backup list

    명령어는 단순하지만, 여기서 확인할 게 많습니다. 인스턴스 이름만 보지 말고 실제 엔진 버전, 백업 상태, 연결 중인 애플리케이션 목록을 같이 정리하셔야 합니다. 저도 처음엔 대충 보고 넘어갔다가 예전 접속 정보를 계속 물고 있는 애플리케이션 하나 때문에 꽤 헤맸습니다.

    4-2. 데이터 덤프

    mysqldump -h TROVE_DB_HOST -u migration_user -p --databases appdb > appdb.sql

    여기서는 덤프가 되느냐보다 복원 시간이 어느 정도인지를 꼭 재보셔야 합니다. OpenStack Trove vs RDS 마이그레이션 관련 검색으로 들어오신 분들이 가장 많이 놓치는 부분이 이거예요. 덤프는 되는데 복원이 너무 오래 걸리면 점검 창이 바로 무너집니다.

    OpenStack Trove vs RDS 마이그레이션 데이터 이전 흐름 이미지

    Trove 소스 DB에서 덤프를 만들고 AWS RDS 대상으로 복원하는 흐름을 나타낸 구성도입니다.

    4-3. RDS 대상 준비

    aws rds create-db-instance \
  --db-instance-identifier appdb-prod \
  --db-instance-class db.t3.micro \
  --engine mysql \
  --master-username admin \
  --manage-master-user-password \
  --allocated-storage 20 \
  --backup-retention-period 7

    실무에서는 보통 콘솔과 IaC(Infrastructure as Code, 코드형 인프라)를 같이 씁니다. 위 예시는 CLI 흐름만 간단히 보여드린 겁니다. 실제로는 VPC, DB subnet group, VPC security group, DB parameter group까지 함께 설계하셔야 해요. 이 부분을 건너뛰면 서비스는 떠도 운영은 금방 불편해집니다.

    4-4. 복원 및 검증

    mysql -h RDS_ENDPOINT -u admin -p < appdb.sql
mysql -h RDS_ENDPOINT -u app_user -p -e "SHOW DATABASES;"

    저는 여기서 단순 접속 확인만 하지 않고, 애플리케이션이 실제로 사용하는 주요 쿼리도 몇 개 꼭 돌려봤습니다. 문자셋이나 권한 차이 때문에 예상 못 한 오류가 나는 경우가 있거든요. 이런 문제는 전환 직후에 터지면 꽤 곤란합니다.

    5. 설정 화면보다 중요한 설계 포인트

    관리형 데이터베이스 선택에서 자주 놓치는 게 있습니다. 서비스 이름보다 주변 설계를 먼저 봐야 한다는 점입니다.

    • 네트워크 경계: 퍼블릭 접근 여부, 배스천 호스트 사용 여부
    • 보안: 최소 권한 계정 분리, 운영 계정과 애플리케이션 계정 분리
    • 백업/복구: 자동 백업 보존 기간, 스냅샷 주기, 복구 리허설 여부
    • 관측성: CPU, 연결 수, 지연 시간, 슬로우 쿼리 관찰 체계
    • 전환 전략: DNS 전환인지 애플리케이션 설정 전환인지 미리 결정

    사실 서비스 자체보다 이런 운영 설계가 결과를 좌우합니다. RDS가 편한 건 맞지만, 설계를 대충 하면 어디서든 사고 납니다. 이전 글에서 다룬 백업 자동화 내용이 있다면 이 부분과 같이 보는 게 훨씬 도움이 됩니다.

    관리형 데이터베이스 선택 시 확인하는 AWS RDS 운영 설정 이미지

    RDS 운영에서 자주 만지는 설정 요소들을 한 화면 개념도로 묶어 보여주는 예시입니다.

    6. 실제로 겪었던 문제와 해결법

    6-1. 애플리케이션 타임아웃

    복원 후 애플리케이션 연결은 되는데 응답이 느린 경우가 있었습니다. 처음엔 DB 성능 문제인 줄 알았는데, 실제로는 보안 그룹과 네트워크 경로가 꼬여 있어서 우회 홉이 생긴 적도 있었어요. 이건 DB만 들여다보면 잘 안 잡힙니다.

    6-2. 권한 차이

    Trove에서 쓰던 계정 권한과 RDS에서 허용되는 범위가 완전히 같다고 생각하면 안 됩니다. 특히 슈퍼유저처럼 넓게 쓰던 계정이 있었다면 전환하면서 정리하는 편이 낫습니다. 저도 이참에 권한을 쪼개서 다시 만들었는데, 번거롭긴 해도 결과적으로 훨씬 안정적이었습니다.

    6-3. 백업이 있다고 복구가 쉬운 건 아니었습니다

    이 부분은 정말 중요합니다. 백업이 존재하는 것과 정해진 시간 안에 복구가 끝나는 것은 다른 얘기거든요. 저도 예전에 백업만 믿고 있다가 복원 속도 때문에 식은땀 흘린 적이 있습니다. 그 뒤로는 무조건 복구 리허설을 같이 했습니다.

    6-4. 운영 문서가 없으면 또 같은 삽질을 합니다

    OpenStack Trove vs RDS 마이그레이션을 마치면 다 끝난 것 같지만, 실제로는 그때부터 운영 기준을 굳혀야 합니다. 엔드포인트, 계정, 비밀번호 회전 정책, 알람 기준을 문서화하지 않으면 다음 장애 때 같은 문제를 반복하게 돼요. 저는 위키에 runbook을 따로 남겨뒀습니다.

    7. 검증은 이렇게 했습니다

    1. 애플리케이션 읽기 기능 확인
    2. 쓰기 기능 확인
    3. 배치 작업 및 스케줄러 실행 확인
    4. 모니터링 지표 수집 여부 확인
    5. 백업 생성 및 복원 테스트 계획 확인

    검증 단계에서는 '접속된다'만 보면 안 됩니다. 실제 업무 흐름이 정상인지를 봐야 하거든요. 저는 최소한 로그인, 조회, 저장, 배치, 알람까지 묶어서 확인했습니다. 그렇게 하니 전환 직후 불안감이 훨씬 줄더라고요.

    OpenStack Trove vs RDS 마이그레이션 검증 결과 대시보드 이미지

    전환 후 연결 수, 지연 시간, 백업 상태 등을 점검하는 결과 대시보드 예시입니다.

    8. 결국 왜 RDS였나: 비용보다 운영 예측 가능성

    많은 분이 RDS를 얘기하면 바로 비용부터 떠올리십니다. 맞아요. 퍼블릭 클라우드 비용은 늘 예민하죠. 그런데 제가 직접 운영해보니, Trove 운영 비용은 단순 인프라 비용표만으로 잘 안 보였습니다. 장애 대응 시간, 특정 인력 의존도, 야간 대응 피로도, 복구 리허설 부담까지 다 포함해야 하거든요.

    반대로 RDS는 비용이 비교적 눈에 잘 보이고, 운영 품질도 어느 정도 예측 가능합니다. 제 기준에서는 이 '예측 가능성'이 정말 컸습니다. 물론 모든 환경이 AWS로 가야 한다는 뜻은 아닙니다. 규제, 데이터 위치, 기존 OpenStack 투자 규모 때문에 Trove나 자체 구축이 더 맞는 조직도 분명히 있습니다.

    이런 경우 추천 방향
    OpenStack 전문 인력이 충분하고 내부 표준화가 잘 된 경우 Trove 유지 검토 가능
    소수 인력으로 안정적 운영이 더 중요한 경우 RDS 같은 상용 관리형 서비스 검토
    장애 대응 시간과 복구 예측 가능성이 핵심인 경우 RDS 쪽 장점이 큼
    커스터마이징보다 운영 단순화가 우선인 경우 RDS가 유리한 편

    9. 정리와 FAQ

    정리하자면, 제가 Trove를 포기하고 AWS RDS로 간 이유는 화려한 기능 차이보다 운영 복잡도와 책임 범위 때문이었습니다. 처음에는 OpenStack 안에서 다 해결하면 멋있어 보였는데, 실제로는 DB 운영보다 플랫폼 운영 이슈를 더 많이 다루게 되더라고요. 그 순간 '이건 우리가 풀어야 할 문제가 조금 다르다'는 생각이 들었습니다.

    다음 글에서는 RDS 전환 후 파라미터 그룹 정리, 백업 점검 루틴, 슬로우 쿼리 확인 흐름을 따로 다뤄보려 합니다. 이전 글에서 홈랩 백업 자동화 얘기를 보셨다면 그 연장선으로 같이 읽으셔도 좋습니다.

    자주 묻는 질문

    • Q. Trove는 쓰면 안 되나요?
      아닙니다. 조직 역량과 표준화 수준이 충분하면 의미 있습니다. 다만 기대하는 '관리형' 수준을 먼저 맞춰보셔야 합니다.
    • Q. RDS로 가면 운영이 완전히 끝나나요?
      그건 아닙니다. 스키마 설계, 쿼리 튜닝, 접근 제어, 비용 관리는 여전히 중요합니다.
    • Q. 마이그레이션에서 제일 중요한 한 가지는 뭔가요?
      복원 리허설입니다. 백업 존재 여부보다 복원 가능 시간이 더 중요합니다.
    클라우드 DB 서비스 비교와 Trove 운영 비용 요약 이미지

    Trove 유지와 RDS 전환 중 어떤 선택이 맞는지 빠르게 판단할 수 있는 요약 인포그래픽입니다.

  • [인프라] OpenStack TCO 분석: VMware 대안, 실제 비용은 얼마나 줄어드나?

    [인프라] OpenStack TCO 분석: VMware 대안, 실제 비용은 얼마나 줄어드나?

    목차

    [인프라] OpenStack TCO 분석: VMware 대안, 실제 비용은 얼마나 줄어드나?

    VMware 대안으로 OpenStack을 검토하시는 분들이 제일 먼저 묻는 건 결국 하나입니다. "그래서 돈이 얼마나 줄어드는데?" 저도 그랬습니다. 처음엔 라이선스만 빼면 무조건 싸질 줄 알았거든요. 그런데 실제로 OpenStack VMware TCO를 따져보면 그렇게 단순하지 않더라고요. 라이선스(License, 사용권) 비용은 분명 큰 축이지만, 운영 인력, 자동화 수준, 장애 대응 체계, 하드웨어 표준화 같은 요소가 함께 들어와야 진짜 총소유비용(TCO, Total Cost of Ownership)이 보입니다.

    특히 요즘은 프라이빗 클라우드 비용을 다시 계산하는 팀이 많습니다. 기존 VMware 환경을 유지할지, VMware 대안으로 OpenStack 같은 오픈소스 기반 프라이빗 클라우드로 갈지, 아니면 일부만 전환할지 고민이 커졌거든요. 제가 홈랩(Home Lab, 개인 실험실)과 실무 환경에서 직접 검토해보니, OpenStack은 라이선스 절감만 보고 들어가면 삽질하기 쉽고, 반대로 운영 모델까지 같이 설계하면 꽤 설득력 있는 선택지가 됩니다.

    여기서 중요한 포인트! 이 글은 "무조건 OpenStack이 싸다" 같은 결론을 밀어붙이는 글이 아닙니다. 실제 비용 절감 효과가 어느 구간에서 생기는지, 그리고 어떤 팀은 오히려 더 비싸질 수 있는지, 경험 기반으로 정리해보겠습니다.

    OpenStack VMware TCO 비교 아키텍처 개요 이미지

    OpenStack과 VMware 기반 프라이빗 클라우드의 비용 구조와 운영 요소를 한눈에 보여주는 개요 이미지입니다.

    1. 왜 OpenStack VMware TCO 분석이 중요한가

    쉽게 말해 TCO는 "도입 가격"이 아니라 "몇 년 동안 실제로 나가는 총비용"입니다. 서버 몇 대 샀는지로 끝나는 게 아니거든요.

    • CapEx(Capital Expenditure, 자본 지출): 서버, 스토리지, 네트워크 장비처럼 처음 들어가는 비용
    • OpEx(Operational Expenditure, 운영 지출): 유지보수, 인력, 전력, 상면, 교육, 장애 대응 비용
    • 전환 비용(Migration Cost, 마이그레이션 비용): 기존 VMware 워크로드를 옮기기 위해 드는 검증과 운영 변경 비용

    저도 처음엔 라이선스 항목만 엑셀에서 지우고 "와, 많이 줄겠네" 했는데요. 막상 계산해보니 OpenStack은 운영 자동화가 덜 되어 있으면 사람 시간이 꽤 필요하더라고요. 반대로 환경이 커질수록, 그리고 내부에 Linux/KVM 역량이 쌓일수록 프라이빗 클라우드 비용 구조가 달라집니다. 이 지점이 핵심입니다.

    2. OpenStack을 VMware 대안으로 볼 때 개념부터 정리

    OpenStack은 가상머신, 네트워크, 스토리지 자원을 API 기반으로 관리하는 프라이빗 클라우드 플랫폼입니다. VMware처럼 완성도 높은 상용 스택 하나를 산다기보다, 여러 컴포넌트를 조합해 클라우드 운영 체계를 만든다고 보시면 이해가 쉽습니다.

    OpenStack 핵심 구성요소

    • Nova(노바, 컴퓨트 관리): 가상머신 생성과 스케줄링
    • Neutron(뉴트론, 네트워크 관리): 가상 네트워크, 라우팅, 보안 그룹
    • Cinder(신더, 블록 스토리지): VM용 디스크 볼륨
    • Glance(글랜스, 이미지 서비스): VM 이미지 저장소
    • Keystone(키스톤, 인증/권한): 사용자와 프로젝트 접근 제어

    반면 VMware는 vSphere, vCenter 같은 상용 관리 체계가 이미 다듬어져 있어서 초기 진입 장벽이 낮은 편입니다. 그래서 OpenStack VMware TCO 비교는 단순히 기능 비교가 아니라 운영 모델 비교로 봐야 합니다. 저도 처음엔 이게 뭔가 싶었는데, 실제로 써보니까 기술 선택보다 운영 철학 차이가 더 크더라고요.

    3. 프라이빗 클라우드 비용, 어디서 갈리나

    비용을 나눠보면 판단이 훨씬 쉬워집니다. 아래 표처럼 보시면 됩니다.

    비용 항목 VMware OpenStack 체크 포인트
    라이선스 상용 라이선스 및 서브스크립션 부담 가능 오픈소스 자체는 라이선스 부담이 낮음 상용 지원 계약 포함 여부 확인
    초기 구축 상대적으로 표준화된 구축 절차 설계와 통합 난이도 높을 수 있음 내부 인력 숙련도 중요
    운영 자동화 관리도구 성숙도 높음 자동화 수준에 따라 편차 큼 Ansible, Terraform 연계 여부
    인력 비용 상용 운영 경험자 수급 비교적 수월 Linux/KVM/OpenStack 경험자 필요 교육 비용과 채용 난이도 반영
    확장성 기능 확장 시 비용 증가 가능 대규모 표준화 환경에 유리할 수 있음 노드 증가 시 운영 효율 점검
    벤더 종속 상대적으로 높을 수 있음 구성 자유도 높음 장기 전략과 맞는지 확인

    여기서 제가 꼭 말씀드리는 게 있습니다. OpenStack은 "라이선스 절감"보다 "운영 체계 내재화"에서 이득이 나는 경우가 많습니다. 반대로 작은 조직에서 운영 전담자 없이 도입하면, 장애 한 번에 절감한 비용이 바로 날아가기도 합니다. 삽질 좀 했습니다 ㅎㅎ

    4. 실제 TCO 분석은 이렇게 해야 덜 틀립니다

    제가 실무에서 비용 비교할 때는 감으로 안 갑니다. 최소 3년 기준으로 항목을 나눠서 봐야 합니다. 1년만 보면 전환 비용이 과하게 커 보이고, 너무 길게 보면 변수 통제가 안 되거든요.

    1. 현행 VMware 비용 기준선(Baseline)을 만든다.
    2. OpenStack 전환 시나리오를 최소 2개 만든다. 완전 전환, 일부 워크로드 전환.
    3. 공통 비용과 차등 비용을 분리한다.
    4. 운영 인건비를 반드시 넣는다.
    5. 장애 리스크와 학습 곡선을 숫자 대신 등급으로라도 반영한다.

    제가 주로 쓰는 TCO 분류 템플릿

    # 예시: 비용 분류 디렉터리 만들기
mkdir -p tco/{baseline,openstack,shared}

cat > tco/baseline/vmware_cost_items.csv <<'EOF'
category,item,period,notes
license,hypervisor_subscription,annual,vmware related recurring cost
support,vendor_support,annual,commercial support contract
hardware,compute_nodes,3year,existing or refresh cycle
operations,admin_labor,annual,platform operation labor
facility,power_and_rack,annual,datacenter operating expense
migration,upgrade_project,one-time,major version or redesign effort
EOF

    이런 식으로 분류를 먼저 해두면 회의할 때 덜 흔들립니다. 숫자부터 넣으면 부서마다 기준이 달라져서 금방 싸움 나거든요.

    프라이빗 클라우드 비용 분석을 위한 OpenStack VMware TCO 워크시트 이미지

    라이선스, 인력, 하드웨어, 지원 비용을 나눠서 비교하는 TCO 분석 워크시트 예시입니다.

    OpenStack 자원 현황 수집 예시

    OpenStack 쪽도 막연하게 "오픈소스니까 싸다"로 접근하면 안 됩니다. 실제 필요한 노드 수와 운영 범위를 봐야 합니다.

    # OpenStack 클라우드 자원 현황 확인 예시
openstack hypervisor list
openstack compute service list
openstack network agent list
openstack volume service list
openstack server list --all-projects
openstack flavor list

    위 명령은 특별한 마법이 있는 게 아니라, 현재 몇 대를 운영하고 있고 어떤 서비스가 붙어 있는지를 구조적으로 보는 출발점입니다. VMware 대안 검토에서 중요한 건 기능 체크리스트보다 실제 운영 대상의 크기거든요.

    간단한 비교용 계산 스크립트 예시

    from dataclasses import dataclass

@dataclass
class TCO:
    license_cost: float = 0.0
    support_cost: float = 0.0
    hardware_cost: float = 0.0
    labor_cost: float = 0.0
    facility_cost: float = 0.0
    migration_cost: float = 0.0

    def total(self) -> float:
        return (
            self.license_cost
            + self.support_cost
            + self.hardware_cost
            + self.labor_cost
            + self.facility_cost
            + self.migration_cost
        )

vmware = TCO(
    license_cost=0,
    support_cost=0,
    hardware_cost=0,
    labor_cost=0,
    facility_cost=0,
    migration_cost=0,
)

openstack = TCO(
    license_cost=0,
    support_cost=0,
    hardware_cost=0,
    labor_cost=0,
    facility_cost=0,
    migration_cost=0,
)

print({
    "vmware_tco": vmware.total(),
    "openstack_tco": openstack.total(),
    "difference": vmware.total() - openstack.total(),
})

    일부러 숫자는 비워뒀습니다. 확실하지 않은 수치를 넣어서 그럴듯하게 만드는 게 제일 위험하거든요. 각 조직의 계약 구조와 인건비 기준이 다르니, 여러분 환경 숫자를 직접 넣어야 합니다.

    5. OpenStack 도입 시 실제로 비용 절감이 나는 구간

    제가 직접 해보니, 비용 절감은 보통 아래 조건에서 더 잘 보였습니다.

    • 가상화 규모가 크고 표준화가 잘 된 환경
    • Linux/KVM 운영 경험이 이미 있는 팀
    • 자동화 도구를 적극적으로 쓰는 조직
    • 벤더 종속을 줄이고 내부 플랫폼 역량을 쌓으려는 경우

    반대로 다음 조건에서는 조심해야 합니다.

    • 소규모 환경인데 운영팀이 매우 얇은 경우
    • 장애 대응을 거의 벤더에 의존해온 경우
    • 조직 내 네트워크와 스토리지 표준이 정리되지 않은 경우

    이건 진짜 많이 놓치는데요. 프라이빗 클라우드 비용은 기술보다 조직 성숙도에 더 민감합니다. OpenStack은 자유도가 높아서 잘 쓰면 좋습니다. 근데 정리 안 된 환경에서 도입하면 복잡성이 그대로 비용이 됩니다.

    6. ⚠️ 제가 겪었던 트러블슈팅과 함정

    여기서는 현실 얘기 좀 해보겠습니다. TCO 문서에는 잘 안 적히는데, 실제론 이런 게 큽니다.

    1) 운영 인건비를 너무 낮게 잡는 실수

    처음엔 오픈소스니까 라이선스 절감폭만 크게 보입니다. 근데 초반엔 Runbook(런북, 운영 절차 문서) 정리, 모니터링, 백업, 네트워크 연동, 권한 체계 정비에 시간이 꽤 들어갑니다. 초기 6~12개월 운영 안정화 비용을 별도 항목으로 잡는 게 좋습니다.

    2) 마이그레이션 난이도를 균일하게 보는 실수

    모든 VM이 똑같이 잘 옮겨지지 않습니다. 에이전트 의존성이 있거나, 특정 네트워크 정책에 묶인 워크로드는 손이 더 갑니다. 그래서 저는 항상 워크로드를 세 그룹으로 나눕니다.

    1. 쉽게 이전 가능
    2. 테스트 후 이전 가능
    3. 유지 또는 재설계 필요

    3) 상용 지원 계약을 0원처럼 보는 실수

    OpenStack도 엔터프라이즈 환경이면 지원 체계가 필요합니다. 내부에서 다 감당 가능한 팀이 아니라면, 결국 지원 계약이나 파트너 비용이 들어갑니다. 이걸 빼면 비교가 왜곡됩니다.

    4) 네트워크 설계를 나중으로 미루는 실수

    Neutron(뉴트론, 네트워크 관리) 설계를 얕게 보면 나중에 VLAN, 라우팅, 보안 그룹, 외부망 연결에서 많이 막힙니다. 저도 홈랩에서 처음엔 컴퓨트만 올리면 끝인 줄 알았는데, 실제로는 네트워크가 시간을 제일 많이 먹더라고요.

    OpenStack 네트워크와 컴퓨트 구성으로 보는 VMware 대안 구조 이미지

    OpenStack 환경에서 네트워크, 컴퓨트, 스토리지 구성이 어떻게 연결되는지 보여주는 다이어그램입니다.

    7. 검증과 결과 해석, 숫자보다 먼저 볼 것

    비용표를 만들었으면 이제 끝이 아닙니다. 저는 아래 항목으로 검증합니다.

    1. 운영 1건당 처리 시간: VM 생성, 네트워크 추가, 증설 요청 처리 시간이 줄었는가
    2. 장애 복구 절차: 누가 어떻게 복구하는지 문서화되었는가
    3. 자동화 비율: 수작업 비율이 줄고 있는가
    4. 확장 시 단가 안정성: 노드가 늘어도 운영 복잡도가 감당 가능한가

    이 단계를 거치면 "OpenStack이 더 싸다"가 아니라 "우리 조직에서 OpenStack이 더 유리한 구조인가"로 질문이 바뀝니다. 이게 훨씬 정확합니다.

    제가 실제로 써봤을 때 느낀 건 이거였습니다. OpenStack의 진짜 비용 절감 포인트는 장기적인 표준화와 자동화입니다. 단기 전환만 보면 오히려 비용이 커 보일 수 있어요. 하지만 일정 규모 이상에서 운영 패턴이 정리되면, VMware 대안으로서 꽤 현실적인 선택지가 됩니다. 드디어 감이 잡히더라고요.

    OpenStack VMware TCO 3년 비용 비교 대시보드 이미지

    3년 기준 TCO 비교 결과를 대시보드 형태로 시각화한 예시 이미지입니다.

    8. 자주 묻는 질문 FAQ

    Q1. OpenStack이 무조건 VMware보다 저렴한가요?

    아닙니다. 조직의 운영 역량과 규모에 따라 다릅니다. 작고 단순한 환경에서는 상용 플랫폼이 더 경제적일 수도 있습니다.

    Q2. 프라이빗 클라우드 비용 비교에서 가장 많이 빠지는 항목은 뭔가요?

    대부분 인건비와 전환 안정화 비용이 빠집니다. 라이선스만 보면 판단이 틀어집니다.

    Q3. OpenStack 도입 전에 무엇부터 확인해야 하나요?

    현재 워크로드 분류, 네트워크 구조, 자동화 도구 사용 수준, 운영 인력 숙련도부터 점검하시는 게 좋습니다.

    Q4. 일부 워크로드만 OpenStack으로 옮기는 것도 괜찮나요?

    네, 오히려 현실적입니다. 개발/테스트 환경부터 시작해서 운영 모델을 검증하는 방식이 리스크를 줄여줍니다.

    9. 마무리: 비용 절감은 제품이 아니라 운영 모델에서 나옵니다

    정리해보면, OpenStack VMware TCO 분석의 핵심은 단순합니다. 라이선스 절감은 시작일 뿐이고, 진짜 승부는 운영 자동화, 표준화, 인력 구조에서 납니다. 저도 처음엔 숫자만 보고 판단하려다가 여러 번 돌아왔습니다. 근데 결국 남는 건 제품 이름이 아니라 운영 체계더라고요.

    혹시 지금 VMware 대안을 검토 중이시라면, 먼저 3년 기준 TCO 표를 직접 만들어보세요. 그리고 완전 전환보다 파일럿(Pilot, 시험 운영)부터 시작해보시는 걸 권합니다. 이거 진짜 중요합니다. 다음 글에서는 OpenStack 파일럿 환경을 최소 구성으로 설계하는 방법을 다뤄볼 예정입니다. 이전 글의 가상화 표준화 체크리스트도 같이 보시면 흐름이 더 잘 잡히실 겁니다.

    OpenStack과 VMware 선택 기준을 정리한 TCO 비교 인포그래픽

    어떤 조직에 OpenStack이 맞고 어떤 조직에 VMware가 더 적합한지 한눈에 정리한 요약 인포그래픽입니다.

    ✅ 한 줄 결론: OpenStack은 분명 강력한 VMware 대안입니다. 다만 실제 비용 절감 효과는 제품 그 자체보다, 그걸 운영하는 팀의 준비 상태에서 결정됩니다.

  • [OpenStack] MicroStack 1년 사용 후기: 홈랩에서 프로덕션까지

    [OpenStack] MicroStack 1년 사용 후기: 홈랩에서 프로덕션까지

    목차

    [인프라] MicroStack 사용 후기: 홈랩에서 프로덕션까지

    MicroStack 사용 후기를 찾는 분들은 대체로 비슷한 고민을 하시더라고요. “홈랩에서 OpenStack(오픈스택, 오픈소스 IaaS 클라우드 플랫폼) 감 잡기엔 너무 무겁지 않나?”, “경량 OpenStack이라고는 하는데 실제로 운영 가능한 수준일까?” 같은 질문 말입니다. 저도 딱 그랬어요. 처음엔 단순히 집에서 VM 몇 개 올려보려고 시작했는데, 실제로 써보니까 홈랩 클라우드 관점에서는 꽤 매력적이고, 반대로 MicroStack 프로덕션 관점에서는 선명한 한계도 있더라고요. 오늘은 제가 1년 정도 굴리면서 느낀 현실적인 장단점을 정리해보겠습니다.

    특히 이 글은 홍보성 사용기가 아니라, 설치할 때 뭐가 편했고 어디서 삽질했는지, 그리고 어떤 환경까지는 추천하고 어디부터는 말리고 싶은지에 초점을 맞췄어요. 혹시 지금 OpenStack MicroStack 도입을 고민 중이시라면, 시간을 꽤 아끼실 수 있을 겁니다.

    MicroStack 사용 후기용 홈랩 클라우드 전체 아키텍처 이미지

    MicroStack이 컨트롤 플레인과 컴퓨트 역할을 어떻게 묶어서 운영하는지 한눈에 보여주는 개요 이미지입니다.

    MicroStack이 뭔가요? 쉽게 말해 “작게 시작하는 OpenStack”입니다

    쉽게 말해 MicroStack은 OpenStack을 더 간단하게 설치하고 빠르게 실험할 수 있게 다듬은 배포 형태라고 보면 돼요. OpenStack 자체는 Nova(노바, 컴퓨트), Neutron(뉴트론, 네트워크), Cinder(신더, 블록 스토리지), Keystone(키스톤, 인증) 같은 구성요소가 많아서, 처음 접하면 머리가 좀 아픕니다. 저도 처음엔 “이걸 집에서 왜 하고 있지?” 싶었거든요.

    근데 경량 OpenStack인 MicroStack은 이 진입장벽을 확실히 낮춰줍니다. 특히 홈랩에서 OpenStack의 구조를 익히거나, API 기반 인프라 운영 감각을 익히기엔 상당히 괜찮더라고요. 한 대 또는 소규모 노드에서 빠르게 올려보고, 네트워크와 이미지, 플래버(Flavor, 가상머신 사양 템플릿), 보안 그룹(Security Group, 방화벽 정책)을 직접 만져볼 수 있다는 게 매력이에요.

    중요한 포인트는 이겁니다. MicroStack은 “OpenStack을 배운다”는 목적에는 굉장히 좋지만, 대규모 멀티노드 운영을 곧바로 대체해주는 마법 상자는 아닙니다. 여기서 기대치를 잘 맞추면 만족도가 높고, 기대치를 잘못 잡으면 금방 실망하게 돼요.

    제가 1년 써보면서 느낀 MicroStack 사용 후기 핵심 요약

    항목 좋았던 점 아쉬웠던 점
    설치 난이도 경량 OpenStack 치고는 진입이 확실히 쉬워요 환경마다 네트워크 초기 설정은 여전히 까다로워요
    학습 효과 실제 OpenStack 개념을 익히기 정말 좋습니다 단순 가상화만 원하면 오히려 과할 수 있어요
    홈랩 적합성 테스트, 자동화, API 실습에 잘 맞아요 자원이 넉넉하지 않으면 금방 답답해져요
    운영 편의성 구성 요소를 비교적 빠르게 확인할 수 있어요 장애 분석은 결국 OpenStack 지식이 필요해요
    프로덕션 적합성 소규모 검증, 사내 PoC엔 의미가 있어요 중요 서비스 운영은 설계와 검증이 훨씬 더 필요해요

    한 줄로 요약하면 이렇습니다. 경량 OpenStack 입문과 실험에는 좋고, 운영 난이도까지 가벼운 건 아니에요. 이 차이를 이해하시면 실패 확률이 많이 줄어들어요.

    홈랩 클라우드에서 MicroStack을 올릴 때 제가 잡았던 기준

    제가 처음부터 거창하게 시작한 건 아니었어요. 목표는 세 가지였습니다.

    1. VM을 API로 만들고 지우는 흐름을 익칠 것
    2. 가상 네트워크와 보안 그룹을 직접 다뤄볼 것
    3. 나중에 Ansible(앤서블, 자동화 도구)이나 Terraform(테라폼, IaC 도구)과 붙여볼 것

    이 기준으로 보니 MicroStack이 딱 중간 지점이더라고요. Proxmox(프록스목스)처럼 가볍게 VM만 다루는 맛과는 다르고, 그렇다고 풀스택 OpenStack 구축처럼 초반 비용이 너무 크지도 않았어요. 특히 “클라우드처럼 운영해보고 싶다”는 감각을 주는 건 확실했습니다.

    반면, 스토리지 고가용성(HA, High Availability), 네트워크 이중화, 장애 도메인 분리까지 바로 요구하는 환경이라면 시작부터 접근을 다르게 해야 해요. 홈랩 클라우드와 실제 서비스 인프라는 닮았지만 같지는 않거든요. 저도 이 부분을 중간에 뼈저리게 느꼈어요.

    실전 구현: MicroStack 기본 설치와 초기 확인

    여기서는 가장 단순한 실험 흐름 위주로 적어볼게요. 릴리스에 따라 초기화 방식이나 일부 명령은 달라질 수 있으니, 큰 흐름을 보시면 됩니다. 제가 썼던 초반 구성은 단일 노드 중심이었고, 이후 네트워크와 이미지 관리 쪽을 반복적으로 손봤어요.

    1. 운영체제와 가상화 지원 상태를 먼저 확인합니다
    2. MicroStack 패키지를 설치합니다
    3. 초기화 후 서비스가 정상 기동했는지 확인합니다
    4. OpenStack CLI로 네트워크, 이미지, 인스턴스를 점검합니다
    sudo snap install microstack --classic
sudo microstack init --auto

    처음엔 이게 뭔가 싶었는데, 설치 자체는 정말 빠르게 진행됐어요. 예전처럼 컴포넌트 하나씩 맞물리는 걸 손으로 다 잡는 느낌은 아니었어요. 그래서 “오, 이거 진짜 편하더라고요”라는 생각이 바로 들었습니다.

    sudo microstack.openstack service list
sudo microstack.openstack network list
sudo microstack.openstack image list
sudo microstack.openstack flavor list

    여기서 중요한 건 설치 성공 메시지보다 실제 서비스 목록과 네트워크 상태를 보는 거에요. 설치가 끝났다고 다 끝난 게 아니거든요. 특히 Neutron(뉴트론, 네트워크 서비스) 관련 구성이 꼬이면 인스턴스는 떠도 외부 통신이 안 되는 경우가 생깁니다.

    OpenStack MicroStack 설치 후 서비스와 네트워크를 점검하는 화면 이미지

    초기 설치 후 서비스 상태, 네트워크 목록, 이미지 목록을 확인하는 장면을 표현한 이미지입니다.

    테스트용 인스턴스를 만들 때는 이미지와 키페어(Key Pair, SSH 접속용 키)를 준비한 뒤, 작은 플래버로 먼저 올려보는 걸 추천드립니다.

    openstack keypair create --public-key ~/.ssh/id_rsa.pub homelab-key
openstack server create \
  --image ubuntu \
  --flavor m1.small \
  --network private \
  --key-name homelab-key \
  test-vm

    이 단계에서 제가 제일 많이 확인한 건 두 가지였어요. 하나는 DHCP(동적 IP 할당)가 정상 동작하는지, 다른 하나는 Security Group 규칙이 너무 빡빡하지 않은지였거든요. VM은 떠 있는데 접속이 안 되면 대개 여기 둘 중 하나였습니다.

    네트워크 구성에서 삽질했던 부분과 현실적인 팁

    솔직히 MicroStack 사용 후기에서 제일 중요한 건 설치가 아니라 네트워크에요. 설치는 금방 되는데, 네트워크가 예상과 다르게 흘러가면 시간이 순식간에 녹습니다. 저도 처음엔 브리지(Bridge, 가상 스위치 연결)와 외부 네트워크 매핑 개념이 머리에 잘 안 들어오더라고요.

    • 관리 네트워크와 외부 네트워크를 머릿속에서 분리해야 해요
    • 보안 그룹 규칙은 초반에 SSH와 ICMP부터 열어두는 게 디버깅이 쉬워요
    • 고정 IP(Floating IP, 외부 노출용 IP) 흐름을 미리 이해하면 덜 헤맵니다
    • DNS와 라우팅 문제는 VM 내부와 호스트 양쪽에서 같이 봐야 해요
    openstack security group rule create --proto tcp --dst-port 22 default
openstack security group rule create --proto icmp default
openstack floating ip create public
openstack server add floating ip test-vm 203.0.113.10

    위 예시는 흐름 설명용이에요. 실제 IP 풀과 외부 네트워크 이름은 환경마다 달라요. 제가 실제로 써보니까, 핑이 안 간다고 바로 인스턴스를 의심하면 안 되더라고요. 호스트 NIC 설정, 브리지 연결, 업스트림 라우터 정책이 더 근본 원인인 경우가 많았습니다.

    ⚠️ 트러블슈팅: 1년 동안 자주 만난 문제들

    첫 번째, 리소스가 생각보다 빨리 부족해져요. 경량 OpenStack이라고 해도 OpenStack은 OpenStack이거든요. 메모리와 스토리지가 넉넉하지 않으면 서비스는 떠 있어도 체감이 무거워져요. 특히 이미지 캐시와 볼륨을 이것저것 만지다 보면 디스크 사용량이 꽤 빨리 올라갑니다.

    두 번째, 로그를 보기 전까지는 원인을 짐작만 하게 돼요. 이건 OpenStack 계열 공통이죠. 대시보드에서 안 보이는 문제가 CLI나 로그에서는 바로 드러날 때가 많았어요. 그래서 저는 장애가 나면 무조건 서비스 상태, 네트워크, 인스턴스 콘솔 로그 순서로 봤습니다.

    openstack server list
openstack server show test-vm
openstack console log show test-vm
journalctl -u snap.microstack.* --no-pager

    세 번째, 업데이트 전 확인이 중요해요. 홈랩이라 가볍게 업데이트했다가 네트워크 동작이 바뀌거나 의존성이 어색해지는 경험, 한 번쯤 하시죠? 저도 했었어요. 드디어 됐다 싶어서 스냅 업데이트를 올렸는데, 다음날 테스트 VM 연결이 달라져서 한참 봤거든요. 그래서 이후엔 스냅샷이나 설정 백업 없이 먼저 올리지 않게 됐습니다.

    여기서 중요한 포인트! MicroStack 프로덕션을 고민하신다면, 장애 대응 문서화와 복구 절차 테스트를 먼저 해보셔야 해요. 설치가 간단한 것과 운영 리스크가 낮은 것은 전혀 다른 얘기거든요.

    MicroStack 사용 후기에서 다루는 네트워크 장애 분석 이미지

    접속 불가 문제를 추적하면서 로그와 네트워크 경로를 함께 보는 실제 운영 느낌의 이미지입니다.

    검증과 결과: 홈랩 클라우드로는 만족, 프로덕션은 조건부

    1년 정도 돌려보면서 얻은 결론은 꽤 명확해요. OpenStack MicroStack은 학습, 검증, 자동화 실험에는 아주 좋았습니다. Terraform으로 인스턴스를 반복 생성해보거나, 내부 개발용 테스트 환경을 API 중심으로 굴려보는 데 특히 좋았어요. “가상머신 몇 개를 띄운다”를 넘어서, “클라우드 운영 방식으로 자원을 다룬다”는 감각을 익히는 데 정말 도움이 많이 됐습니다.

    반대로, 여러 팀이 동시에 쓰는 핵심 서비스 운영 플랫폼으로 보자면 질문이 많아져요. 장애 격리, 스토리지 안정성, 네트워크 설계, 백업 전략, 모니터링 체계까지 하나씩 검증해야 하거든요. 여기서는 MicroStack 자체의 편의성보다 OpenStack 운영 역량이 더 중요해져요.

    • ✅ 홈랩 학습용: 추천
    • ✅ 사내 PoC 및 개념 검증: 조건부 추천
    • ✅ API 자동화 연습: 추천
    • ⚠️ 핵심 업무 시스템 운영: 충분한 설계와 검증 전제
    • ⚠️ 단순 VM 호스팅만 필요: 다른 선택지가 더 단순할 수 있어요
    openstack hypervisor list
openstack compute service list
openstack network agent list
openstack volume service list

    이런 식으로 각 서비스 상태를 점검하면서 운영 감각을 익히는 데는 꽤 좋았어요. 특히 제가 얻은 가장 큰 수확은 “클라우드는 결국 API와 네트워크, 그리고 운영 절차의 합”이라는 걸 몸으로 배운 점이었습니다.

    테스트 인스턴스가 정상 동작하고 서비스가 모두 올라온 상태를 시각적으로 보여주는 이미지입니다.

    MicroStack과 다른 선택지, 누구에게 맞을까요?

    선택지 잘 맞는 경우 덜 맞는 경우
    MicroStack 경량 OpenStack 학습, 홈랩 클라우드, API 실습 아주 단순한 개인 VM 호스팅만 필요한 경우
    Proxmox VE 가볍고 빠른 가상화 운영, 홈서버 편의성 OpenStack 구조 자체를 배우고 싶은 경우
    풀 OpenStack 배포 본격적인 멀티노드 운영과 세밀한 제어 처음 입문하거나 빠른 실험이 필요한 경우

    저도 처음엔 “그냥 익숙한 가상화 플랫폼 쓰면 되지 않나?” 싶었는데, 목적이 다르더라고요. MicroStack은 결과만 놓고 보면 더 복잡할 수 있어요. 대신 과정에서 배우는 게 많습니다. 이 차이가 꽤 커요.

    정리: MicroStack 사용 후기, 이런 분께는 추천합니다

    정리해보면, 제가 느낀 MicroStack 사용 후기는 꽤 현실적이에요. 배우기엔 좋고, 가볍게 시작하기도 좋지만, 운영이 쉬운 건 아니에요. 그래도 홈랩에서 OpenStack을 만져보고 싶은 분께는 분명히 가치가 있습니다. 특히 네트워크와 클라우드 자원 모델을 손으로 익히고 싶은 분께요.

    • 홈랩에서 경량 OpenStack 구조를 직접 배우고 싶은 분
    • Ansible, Terraform 같은 자동화 도구와 연결해보고 싶은 분
    • 향후 정식 OpenStack 환경을 다루기 전에 감을 잡고 싶은 분
    • 단순 VM 생성이 아니라 IaaS 운영 모델을 이해하고 싶은 분

    반대로, 빠르고 단순한 가상화만 원하시면 다른 플랫폼이 더 행복할 수 있어요. 이건 진짜입니다. 기술 선택은 멋보다 목적이거든요.

    다음 글에서는 보안 그룹(Security Group)과 플로팅 IP(Floating IP) 설정을 중심으로, 외부 접속이 왜 자꾸 막히는지 조금 더 깊게 다뤄볼 예정입니다. 이전 글에서 다뤘던 홈랩 스토리지 구성 글과 같이 보시면 흐름이 더 잘 이어질 겁니다.

    MicroStack 사용 후기 장단점과 추천 대상을 정리한 요약 이미지

    홈랩, 학습, PoC, 프로덕션 관점에서 장단점을 빠르게 비교할 수 있는 요약 이미지입니다.

    자주 묻는 질문

    Q. MicroStack은 초보자가 바로 시작해도 될까요?

    A. 가능해요. 다만 리눅스 기본기와 네트워크 개념이 조금 있으면 훨씬 덜 힘들어요. 저도 처음엔 CLI가 낯설었는데, 하나씩 확인하다 보니 금방 익숙해졌거든요.

    Q. MicroStack 프로덕션 운영도 가능한가요?

    A. 가능 여부보다 중요한 건 운영 요구사항이에요. 고가용성, 백업, 장애 복구, 네트워크 설계를 충분히 검토하지 않으면 운영 부담이 커져요.

    Q. 경량 OpenStack이라고 해서 자원 요구사항도 아주 낮나요?

    A. 체감상 그렇지는 않았어요. 작은 실험은 가능하지만, 인스턴스 수와 서비스가 늘어나면 자원 압박이 금방 생겨요. 그래서 초기 목표를 좁게 잡는 게 좋아요.

    결론적으로, OpenStack MicroStack은 “집에서도 클라우드를 진짜처럼 굴려보고 싶다”는 분께 꽤 괜찮은 출발점이에요. 저처럼 삽질 좀 하더라도 구조를 몸으로 배우고 싶은 분이라면 한 번쯤 해볼 만합니다. 다만 기대치는 현실적으로 잡으세요. 그게 제일 중요해요.

  • [OpenStack] Kolla-Ansible vs Native Install: 배포 방식 비교 분석

    [OpenStack] Kolla-Ansible vs Native Install: 배포 방식 비교 분석

    목차

    [OpenStack] Kolla-Ansible vs Native Install 배포 비교

    Kolla-Ansible OpenStack 배포를 처음 고민하시는 분들은 거의 비슷한 지점에서 막히시더라고요. 저도 처음엔 ‘그냥 패키지 설치해서 올리면 되는 거 아닌가?’ 싶었는데, 실제로 해보니 배포 방식에 따라 운영 난이도와 장애 대응 속도가 꽤 많이 달랐습니다. 특히 홈랩과 사내 테스트베드에서 OpenStack 설치 비교를 여러 번 해보니까, 처음 설계할 때의 선택이 나중에 진짜 크게 돌아오더라고요. 이번 글에서는 Kolla-Ansible과 Native Install(네이티브 설치, 직접 패키지와 서비스 단위로 구성) 방식을 경험 기준으로 차분히 비교해보겠습니다.

    혹시 지금 이런 상황이신가요? 빠르게 PoC(개념 검증, Proof of Concept)를 띄워야 하는데 운영 표준도 챙겨야 하고, 나중에 업데이트나 재배포도 염두에 두고 계신 분들 말입니다. 여기서 중요한 포인트는 단순히 ‘설치가 되느냐’가 아니라, 어떤 방식이 내 팀의 운영 역량과 더 잘 맞느냐입니다.

    컨테이너 기반 Kolla-Ansible과 패키지 기반 Native Install의 구조 차이를 한눈에 보여주는 비교 다이어그램입니다.

    Kolla-Ansible OpenStack 배포가 왜 주목받는지

    쉽게 말해 Kolla-Ansible은 OpenStack 서비스를 컨테이너(Container, 애플리케이션 실행 단위)로 배포하고, Ansible(앤서블, 에이전트 없이 원격 설정을 자동화하는 도구)로 전체 구성을 밀어 넣는 방식입니다. 반면 Native Install은 각 노드에 필요한 패키지를 직접 설치하고, 서비스 설정 파일을 손으로 맞추거나 배포 자동화 스크립트를 따로 관리하는 흐름에 가깝습니다.

    제가 직접 해보니 두 방식은 철학 자체가 다르더라고요. Kolla-Ansible은 표준화와 재현성에 강합니다. 반대로 Native Install은 세밀한 제어와 내부 이해에 강하죠. 처음엔 이게 뭔가 싶었는데, 몇 번 재설치를 반복하다 보니 왜 운영팀마다 선호 방식이 갈리는지 바로 이해됐습니다.

    • Kolla-Ansible: 컨테이너 기반, 역할 분리 명확, 재배포와 확장이 상대적으로 편함
    • Native Install: 서비스별 설정을 세밀하게 만질 수 있음, 학습에는 좋지만 운영 표준화가 어렵기 쉬움
    • 공통점: 결국 Neutron(뉴트론, 네트워크 서비스), Nova(노바, 컴퓨트 서비스), Keystone(키스톤, 인증 서비스) 같은 핵심 컴포넌트를 이해해야 안정적으로 굴러감

    OpenStack 설치 비교: 어떤 환경에 무엇이 맞을까

    이제 본론으로 들어가 보겠습니다. OpenStack 설치 비교를 할 때는 설치 편의성만 보면 안 됩니다. 운영 중 변경 작업, 장애 복구, 로그 추적, 업그레이드 전략까지 같이 봐야 하거든요. 저도 예전엔 설치만 되면 끝이라고 생각했었는데, 그 뒤에 남는 유지보수 비용이 더 크더라고요. 삽질 좀 했습니다 ㅎㅎ

    비교 항목 Kolla-Ansible Native Install
    배포 방식 컨테이너 이미지와 Ansible 플레이북 기반 패키지 설치와 서비스별 수동 설정 중심
    초기 진입 장벽 변수 구조와 네트워크 이해가 필요 설치 흐름은 단순해 보이지만 전체 의존성 파악이 어려움
    재현성 높음 운영자 숙련도에 따라 차이 큼
    문제 분석 컨테이너 로그와 Ansible 결과를 함께 봐야 함 서비스 단위 로그 확인은 직관적이나 변경 이력 관리가 어려움
    업데이트/재배포 자동화에 유리 절차 문서화가 부족하면 리스크 큼
    추천 환경 반복 배포, 표준화, 다노드 테스트베드 학습용, 디버깅 중심, 서비스 구조 파악 목적

    제 경험상 팀 단위 운영이라면 Kolla-Ansible 쪽이 훨씬 덜 힘들었습니다. 반면 OpenStack 내부 구조를 깊게 공부하려면 Native Install도 한 번은 꼭 해볼 만합니다. 왜냐하면 서비스가 어떤 순서로 붙고, 어디서 설정 충돌이 나는지 몸으로 익히게 되거든요.

    Ansible OpenStack 구성 관점에서 보는 핵심 차이

    1. 구성 관리 방식

    Kolla-Ansible은 보통 전역 설정과 서비스별 오버라이드(override, 기본 설정 덮어쓰기)를 분리해서 관리합니다. 이게 처음엔 조금 낯설어요. 하지만 실제로 써보니까 역할(Role)과 변수(Variable)가 정리돼 있어서, 나중에 다시 볼 때 덜 헷갈리더라고요.

    2. 네트워크 설계 난이도

    OpenStack은 네트워크에서 많이 넘어집니다. 관리망, 터널망, 외부망을 어떻게 나눌지에 따라 Neutron 구성이 완전히 달라지니까요. Native Install은 서비스 설정 파일을 직접 만지는 만큼 자유도는 높지만, 실수 한 번 하면 어디서부터 틀어졌는지 찾는 데 시간이 오래 걸렸습니다.

    3. 운영 표준화

    운영 문서가 중요한 조직이라면 OpenStack 배포 자동화 측면에서 Kolla-Ansible이 확실히 유리합니다. 인벤토리(inventory, 관리 대상 호스트 목록)와 변수 파일만 정리되면 재현성이 좋거든요. 이건 새 장비 들어왔을 때 정말 체감됩니다.

    Ansible OpenStack 구성과 노드 연결 구조를 보여주는 이미지

    컨트롤 노드, 컴퓨트 노드, 네트워크 노드 사이에서 Ansible과 컨테이너 서비스가 어떻게 연결되는지 보여주는 구성도입니다.

    실전 구현: Kolla-Ansible로 OpenStack 배포 기본 흐름

    이제 실전 쪽 이야기를 해보겠습니다. 여기서는 Kolla-Ansible OpenStack 배포의 전형적인 흐름을 예시로 보겠습니다. 배포판이나 릴리스에 따라 세부 패키지 이름은 조금 달라질 수 있으니, 실제 적용 전에는 운영 중인 환경 기준으로 문서를 꼭 맞춰보셔야 합니다. 저는 이런 식으로 접근하면 시행착오가 많이 줄더라고요.

    1. 배포용 제어 노드(Control Node)를 준비합니다.
    2. Ansible과 Kolla-Ansible을 설치합니다.
    3. 인벤토리와 전역 설정 파일을 작성합니다.
    4. 네트워크 인터페이스와 VIP(Virtual IP, 가상 IP)를 정의합니다.
    5. 사전 점검(prechecks)을 실행합니다.
    6. 배포 후 초기화와 검증을 진행합니다.

    1. 기본 패키지 준비

    python3 -m venv /opt/kolla-venv
source /opt/kolla-venv/bin/activate
pip install -U pip
pip install 'ansible>=6,<9' kolla-ansible
mkdir -p /etc/kolla

    여기서 중요한 포인트! Python 가상환경(virtual environment, 격리된 파이썬 실행 환경)을 써두면 나중에 의존성 꼬임이 줄어듭니다. 별거 아닌 것 같아도 이거 진짜 편하더라고요.

    2. 인벤토리 작성 예시

    all:
  hosts:
    controller01:
      ansible_host: 192.168.10.11
    compute01:
      ansible_host: 192.168.10.21
  children:
    control:
      hosts:
        controller01:
    network:
      hosts:
        controller01:
    compute:
      hosts:
        compute01:
    monitoring:
      hosts:
        controller01:
    storage:
      hosts:
        controller01:

    홈랩에서는 올인원 또는 2노드 구성으로 시작하는 경우가 많습니다. 저도 처음엔 욕심내서 역할을 너무 쪼갔다가 오히려 디버깅 포인트만 늘어났었네요. 처음에는 단순하게 가는 게 좋습니다.

    3. globals.yml 예시

    kolla_base_distro: "ubuntu"
kolla_install_type: "source"
openstack_release: "2023.2"
kolla_internal_vip_address: "192.168.10.100"
network_interface: "eth0"
neutron_external_interface: "eth1"
enable_haproxy: "yes"
enable_cinder: "yes"
enable_horizon: "yes"

    버전이나 배포판 조합은 실제 지원 매트릭스를 확인해서 맞추셔야 합니다. 제가 예전에 여기 대충 맞췄다가 컨테이너는 떠 있는데 서비스 등록이 꼬여서 한참 봤습니다. 드디어 됐다 싶으면 다른 데서 막히고, 그런 순간이 꼭 옵니다.

    4. 배포 실행

    kolla-ansible -i ./multinode bootstrap-servers
kolla-ansible -i ./multinode prechecks
kolla-ansible -i ./multinode deploy
kolla-ansible -i ./multinode post-deploy

    이 순서대로 가면 됩니다. 특히 prechecks는 꼭 보셔야 해요. DNS, 시간 동기화, 인터페이스 정의 같은 기본 조건이 여기서 많이 걸립니다.

    5. OpenStack 클라이언트 환경 적용

    source /etc/kolla/admin-openrc.sh
openstack service list
openstack network agent list
openstack hypervisor list

    여기까지 오면 1차 확인은 끝입니다. 서비스 카탈로그(Service Catalog, API 엔드포인트 목록)와 하이퍼바이저(Hypervisor, 가상화 호스트) 인식 상태를 먼저 보는 습관을 들이면 좋습니다.

    Kolla-Ansible OpenStack 배포 자동화 작업 중인 홈랩 환경 이미지

    Kolla-Ansible 배포 과정에서 사전 점검과 실제 배포가 진행되는 흐름을 홈랩 분위기로 표현한 이미지입니다.

    반대로 Native Install은 언제 유리할까

    그렇다고 Native Install이 무조건 불리한 건 아닙니다. 저도 실제로 써보니까 서비스 구조를 이해하는 데는 정말 도움이 컸습니다. 예를 들어 Keystone 설정이 어디서 인증 토큰 흐름에 영향을 주는지, Neutron ML2 플러그인(ML2 Plugin, 네트워크 드라이버 프레임워크)과 브리지 설정이 어떻게 맞물리는지 직접 보게 되거든요.

    특히 이런 경우엔 Native Install도 충분히 가치 있습니다.

    • 단일 노드 학습 환경을 빠르게 만들고 싶을 때
    • 컨테이너 추상화보다 서비스 파일과 로그를 직접 보고 싶을 때
    • 특정 컴포넌트의 동작을 깊게 디버깅해야 할 때
    • 자동화보다 구조 이해가 우선일 때

    다만 운영 관점에서는 사람이 바뀌거나 시간이 지나면 설정이 점점 꼬이기 시작합니다. 정말 많이 봤거든요. 문서가 조금만 부실해도 ‘이 설정 누가 왜 넣었지?’가 반복되더라고요.

    ⚠️ 주의사항과 트러블슈팅: 제가 실제로 막혔던 포인트

    1. 시간 동기화(NTP, Network Time Protocol) 문제

    OpenStack은 인증 토큰과 서비스 통신에서 시간 차이에 민감합니다. Kolla-Ansible이든 Native Install이든 노드 간 시간이 어긋나면 묘한 인증 실패가 납니다. 겉으로는 네트워크 문제처럼 보이는데, 알고 보면 시계 문제인 경우가 있더라고요.

    2. 네트워크 인터페이스 이름 불일치

    이건 홈랩에서 특히 자주 나옵니다. 예전 문서 보고 eth0, eth1으로 적어놨는데 실제 장비는 ens18, ens19인 경우요. 별거 아닌 오타 같은데 외부 네트워크 바인딩이 안 되고 Floating IP(플로팅 IP, 외부 접근용 가상 IP)도 꼬입니다.

    3. 컨테이너는 떠 있는데 서비스가 비정상

    Kolla-Ansible에서 흔히 겪는 착시입니다. docker ps나 podman ps 기준으로는 떠 있어도, 내부 서비스가 정상 등록되지 않았을 수 있습니다. 그래서 저는 항상 컨테이너 상태만 보지 않고 OpenStack API 응답까지 같이 확인합니다.

    4. Native Install의 설정 드리프트(Configuration Drift, 설정 불일치)

    처음엔 한 대에서 잘 되는데, 두 번째 노드부터 미묘하게 설정이 다르기 시작합니다. 결국 장애가 나면 원인 추적이 어려워져요. 여기서 중요한 포인트는 자동화되지 않은 반복 작업은 결국 누락을 만든다는 점입니다.

    • ⚠️ 사전 점검 체크리스트를 문서화하세요
    • ⚠️ 네트워크 맵과 인터페이스명을 먼저 확정하세요
    • ⚠️ 배포 직후 서비스 목록, 에이전트 목록, 하이퍼바이저 목록을 반드시 확인하세요
    • 💡 장애 분석 시에는 인프라 로그와 OpenStack API 결과를 같이 보세요

    검증과 결과 확인: 배포 후 무엇을 보면 되나

    Kolla-Ansible OpenStack 배포가 끝났다고 바로 안심하면 안 됩니다. 실제 검증은 이제부터거든요. 저는 보통 아래 순서로 확인합니다.

    1. Keystone 인증 정상 여부 확인
    2. Nova 컴퓨트 서비스 등록 확인
    3. Neutron 에이전트 상태 확인
    4. Horizon 대시보드 접속 확인
    5. 테스트 네트워크와 인스턴스 생성 확인
    source /etc/kolla/admin-openrc.sh
openstack token issue
openstack compute service list
openstack network agent list
openstack image list
openstack server list

    실제로 써보니까 이 단계에서 가장 중요한 건 ‘서비스가 보이느냐’보다 ‘실제 워크로드가 도는가’였습니다. 테스트 인스턴스 하나 띄워보고, 네트워크 붙이고, 콘솔 접속까지 해보면 훨씬 확실합니다. 🎉

    OpenStack 배포 검증 결과와 Horizon 대시보드를 보여주는 이미지

    Horizon 대시보드와 CLI 결과를 통해 배포 성공 여부를 교차 검증하는 장면입니다.

    정리: 어떤 선택이 더 현실적인가

    결론부터 말씀드리면, 반복 가능한 운영 환경이 목표라면 Kolla-Ansible 쪽이 더 현실적입니다. 특히 팀 단위로 관리하거나 테스트베드를 여러 번 재현해야 한다면 OpenStack 배포 자동화의 장점이 확실히 드러납니다. 반면 Native Install은 구조 학습과 세밀한 디버깅에 강합니다. 저도 처음엔 Native Install로 내부를 익히고, 나중엔 Kolla-Ansible 쪽으로 운영 방식을 옮겨가는 흐름이 가장 자연스러웠습니다.

    혹시 지금 둘 중 하나를 선택해야 하는 상황이라면 이렇게 보시면 됩니다.

    • 빠른 표준화와 재배포가 필요하다면 Kolla-Ansible
    • OpenStack 내부 구조 학습이 우선이라면 Native Install
    • 장기 운영까지 본다면 자동화와 문서화가 쉬운 쪽을 선택

    다음 글에서는 Kolla-Ansible 환경에서 네트워크 분리와 외부망 연결, 특히 Neutron 브리지 구성을 조금 더 깊게 다뤄볼 예정입니다. 이전 글에서 다뤘던 리눅스 브리지와 VLAN 설계 내용을 같이 보시면 훨씬 이해가 빠르실 거예요.

    Kolla-Ansible OpenStack 배포와 Native Install 장단점 요약 인포그래픽

    두 배포 방식의 선택 기준과 운영 포인트를 빠르게 복습할 수 있도록 정리한 요약 인포그래픽입니다.

    자주 묻는 질문

    Q1. 처음 배우는 입장에서는 어떤 방식이 더 나을까요?

    OpenStack 구조를 제대로 익히고 싶다면 Native Install을 한 번 경험해보는 게 도움이 됩니다. 다만 실제 운영까지 바로 생각하신다면 Kolla-Ansible이 더 덜 고생스럽습니다.

    Q2. 홈랩에서는 어떤 쪽이 더 적합한가요?

    반복 실험이 많고 초기화 후 다시 띄우는 일이 잦다면 Kolla-Ansible이 편합니다. 반대로 서비스별 설정을 직접 뜯어보고 싶은 학습형 홈랩이라면 Native Install도 괜찮습니다.

    Q3. Ansible OpenStack 구성은 운영팀에도 유리한가요?

    네, 인벤토리와 변수 파일 기준으로 변경 이력을 관리하기 쉬워서 협업에 유리합니다. 특히 사람 손을 덜 타게 만드는 점이 큽니다.

    Q4. OpenStack 설치 비교에서 가장 먼저 봐야 할 기준은 뭔가요?

    설치 성공 여부보다 재현성, 운영 문서화, 장애 대응 흐름을 먼저 보시는 게 좋습니다. 결국 오래 남는 건 운영 부담이거든요.

  • [인프라] OpenStack 멀티노드 클러스터 1년 운영 회고

    [인프라] OpenStack 멀티노드 클러스터 1년 운영 회고

    목차

    [인프라] OpenStack 멀티노드 클러스터 1년 운영 회고

    OpenStack 멀티노드 운영을 1년 정도 굴려보면, 설치가 끝이라고 생각했던 시점부터 진짜 일이 시작되더라고요. 저도 처음엔 “컨트롤 플레인(control plane, 제어 영역)만 안정적이면 되겠지”라고 가볍게 봤었는데, 실제로 써보니까 네트워크, 스토리지, 메시지 큐(message queue, 비동기 작업 전달), 그리고 운영 절차가 전부 엮여 있어서 한 군데만 흔들려도 전체가 불안해졌습니다. 혹시 랩 환경(home lab, 개인 실험실)에서 잘 되던 구성이 운영 구간에서 갑자기 말을 안 들어서 당황하신 적 있으신가요? 오늘은 제가 직접 겪은 OpenStack 클러스터 후기, 그리고 OpenStack 배포 실패 사례까지 솔직하게 묶어서 정리해보겠습니다.

    이 글은 특정 배포판 홍보가 아니라, OpenStack 멀티노드 운영에서 실제로 부딪히는 포인트를 중심으로 썼습니다. 다음 글에서는 Ceph(세프, 분산 스토리지) 연동 쪽도 따로 다룰 예정이고, 이전 글에서 다뤘던 가상화 호스트 설계 내용이 있다면 함께 보시면 흐름이 더 잘 잡히실 겁니다.

    컨트롤 노드, 컴퓨트 노드, 네트워크 경로가 한눈에 보이는 OpenStack 멀티노드 운영 아키텍처 예시입니다.

    왜 OpenStack 멀티노드 운영은 설치보다 운영이 더 어렵나

    쉽게 말해 OpenStack은 하나의 프로그램이 아니라 여러 서비스의 연합체더라고요. Keystone(키스톤, 인증), Nova(노바, 컴퓨트), Neutron(뉴트론, 네트워크), Glance(글랜스, 이미지), Cinder(신더, 블록 스토리지) 같은 서비스가 각자 잘 떠 있어야 하고, 서로 API 호출도 정상이어야 합니다. 설치 문서는 대부분 “어떻게 올릴까”에 집중하는데, 운영은 “문제가 났을 때 어디부터 볼까”가 핵심이거든요.

    제가 1년 운영하면서 느낀 건 딱 세 가지였습니다.

    • 장애는 단일 원인처럼 보이지만 실제론 연쇄 장애인 경우가 많습니다.
    • 성능 문제보다 상태 일관성(state consistency, 서비스 간 상태 맞춤) 문제가 더 까다롭습니다.
    • 사람이 반복하는 운영 작업은 결국 사고로 이어집니다.

    예를 들어 인스턴스(instance, 가상 머신) 생성 실패가 떴다고 해서 꼭 Nova 문제는 아니었습니다. 메시지 브로커(broker, 중간 전달자) 지연, Neutron 포트 생성 실패, 데이터베이스 연결 수 부족 같은 식으로 옆 서비스 이슈가 튀어나오는 경우가 꽤 많았거든요. 처음엔 이게 뭔가 싶었는데, 로그를 몇 번 따라가다 보면 OpenStack은 결국 관계도 싸움이라는 걸 알게 됩니다.

    운영 전에 잡아야 했던 기본 원칙

    여기서 중요한 포인트! OpenStack 멀티노드 운영은 기술 스택보다 운영 원칙을 먼저 정하는 게 훨씬 중요합니다. 저는 초반에 이걸 대충 잡았다가 삽질 좀 했습니다 ㅎㅎ

    영역 초기 생각 1년 뒤 결론
    네트워크 가능하면 단순하게 관리망, 스토리지망, 테넌트망 분리가 운영 피로를 줄임
    스토리지 일단 붙으면 된다 장애 복구 절차와 성능 특성까지 같이 봐야 함
    로그 문제 생기면 그때 확인 중앙 수집 없으면 원인 추적 시간이 급격히 늘어남
    배포 처음 한 번만 성공하면 됨 재현 가능한 자동화가 없으면 다음 장애 때 무너짐
    모니터링 CPU, 메모리만 보면 됨 API 지연, 큐 적체, DB 연결 상태까지 봐야 함

    특히 네트워크는 정말 중요했습니다. Neutron이 들어가는 순간 브리지(bridge, 가상 스위치), VLAN(가상 랜), 오버레이 네트워크(overlay network, 가상 터널 네트워크) 이해도가 부족하면 “핑은 되는데 VM 통신은 안 됨” 같은 상황이 자주 생깁니다. 이거 진짜 사람 멘탈 흔듭니다.

    제가 실제로 사용한 운영 구조와 체크 포인트

    구성 자체는 전형적인 멀티노드 방식이었습니다. 컨트롤 노드에 API와 스케줄러 계열을 두고, 컴퓨트 노드에서 하이퍼바이저(hypervisor, 가상화 실행 계층)를 돌리고, 네트워크는 별도 역할을 분리하거나 최소한 경로를 명확히 나눴습니다. 여기에 MariaDB(마리아디비, 관계형 데이터베이스), RabbitMQ(래빗엠큐, 메시지 큐), HAProxy(에이치에이프록시, 로드밸런서)를 조합하면 기본 뼈대는 갖춰집니다.

    배포 자동화는 도구마다 방식이 다르지만, 원칙은 비슷합니다.

    1. 호스트 이름과 DNS를 먼저 고정합니다.
    2. NTP 또는 Chrony로 시간 동기화를 맞춥니다.
    3. 관리망 IP와 서비스 엔드포인트(endpoint, 서비스 접속 주소)를 문서화합니다.
    4. 메시지 큐와 데이터베이스 상태를 먼저 확인합니다.
    5. 그다음 OpenStack 서비스 등록과 에이전트(agent, 백그라운드 작업 프로세스) 상태를 검증합니다.

    제가 자주 쓰던 점검 명령은 이런 식이었습니다.

    openstack service list
openstack endpoint list
openstack compute service list
openstack network agent list
openstack hypervisor list
openstack server list --all-projects

    처음엔 서비스 목록만 보고 안심했었는데, 실제로는 에이전트가 살아 있어도 기능이 망가진 경우가 있더라고요. 그래서 저는 아래처럼 시스템 레벨도 꼭 같이 확인했습니다.

    systemctl --type=service | grep -E 'nova|neutron|cinder|glance|keystone'
ss -lntp
journalctl -u nova-compute -n 100
journalctl -u neutron-server -n 100
rabbitmqctl list_queues
mysql -e 'show processlist;'

    여기서 핵심은 “OpenStack 명령 결과”와 “OS 레벨 상태”를 분리해서 보는 겁니다. 둘 중 하나만 보면 꼭 놓치는 구간이 생깁니다.

    OpenStack 멀티노드 운영 서비스 흐름 구성 이미지

    Keystone, Nova, Neutron, RabbitMQ, MariaDB가 어떤 흐름으로 연결되는지 설명하는 구성 다이어그램 위치입니다.

    실전 구현에서 효과 있었던 운영 습관

    프로덕션 OpenStack 회고 관점에서 보면, 기술보다 습관이 더 오래 남습니다. 제가 1년 동안 남긴 것 중 실제로 가장 도움이 됐던 건 아래 네 가지였습니다.

    1. 변경 작업 전 체크리스트 작성
      패키지 업데이트, 네트워크 설정 변경, 서비스 재시작 전후 확인 항목을 고정했습니다.
    2. 설정 파일 차이(diff, 변경점) 기록
      나중에 왜 바꿨는지 기억이 안 나는 순간이 오거든요.
    3. 장애 재현 메모
      증상, 원인 후보, 실제 원인, 해결 순서를 남겨두면 다음 장애 때 시간이 확 줄어듭니다.
    4. 작은 자동화라도 바로 적용
      반복 명령은 셸 스크립트(shell script, 명령 자동화)로 묶었습니다.

    예를 들면 컴퓨트 노드 상태 점검은 간단한 스크립트로 묶어두면 꽤 편합니다.

    #!/usr/bin/env bash
set -eu

echo '[1] hypervisor list'
openstack hypervisor list

echo '[2] compute services'
openstack compute service list

echo '[3] failed services'
systemctl --failed

echo '[4] recent nova-compute logs'
journalctl -u nova-compute -n 50 --no-pager

    이런 건 거창하지 않아도 됩니다. 중요한 건 사람 손을 덜 타게 만드는 것입니다. 제가 직접 해보니 OpenStack 배포 실패 사례 중 꽤 많은 비율이 설치 자체보다, 설치 후 운영 절차 부재에서 시작됐습니다.

    ⚠️ 실제로 크게 데였던 장애와 해결 과정

    1. 메시지 큐 지연으로 인한 인스턴스 생성 실패

    증상은 단순했습니다. VM 생성 요청은 들어가는데 완료가 안 되는 겁니다. 처음엔 Nova 스케줄러를 의심했는데, 로그를 따라가 보니 RabbitMQ 큐 적체가 원인이었습니다. 관리망 지연이 누적되면서 RPC(Remote Procedure Call, 원격 호출) 응답이 늦어졌고, 결국 타임아웃이 연쇄적으로 터졌습니다.

    • 배운 점: API 장애처럼 보여도 메시지 경로를 꼭 봐야 합니다.
    • 해결 방법: 큐 상태 확인, 관리망 상태 점검, 재시작 순서 표준화

    2. Neutron 포트 생성은 되는데 통신이 안 되는 문제

    이건 정말 오래 잡았습니다. 보안 그룹(security group, 가상 방화벽) 문제처럼 보였는데, 실제로는 브리지 매핑(bridge mapping, 네트워크 연결 규칙)과 물리 NIC 연결 정의가 어긋나 있었습니다. 로그상 큰 에러가 안 보여서 더 헷갈렸고요. 저도 처음엔 헷갈렸는데, 결국 에이전트 설정과 호스트 네트워크 구성이 서로 맞아야 한다는 너무 당연한 사실을 다시 배웠습니다.

    • 배운 점: Neutron 문제는 논리 설정과 물리 연결을 같이 봐야 합니다.
    • 해결 방법: 브리지 이름, 인터페이스 매핑, 에이전트 상태를 한 번에 점검

    3. 스토리지 연결은 되는데 성능이 들쭉날쭉한 상황

    이건 더 무서운 유형입니다. 완전히 죽는 게 아니라 “어제는 괜찮았는데 오늘은 왜 느리지?”가 반복되거든요. 결국 원인은 백엔드 스토리지 경로 경쟁, 작업 몰림, 그리고 이미지 캐시 처리 타이밍이 겹친 문제였습니다. 숫자를 괜히 지어내고 싶진 않아서 구체 수치는 빼겠지만, 체감 성능 차이는 꽤 컸습니다.

    • 배운 점: 스토리지는 붙어 있는지만 보지 말고 패턴을 봐야 합니다.
    • 해결 방법: 작업 시간대 분산, 캐시 정책 점검, 백엔드 모니터링 강화

    4. 데이터베이스는 살아 있는데 API가 간헐적으로 느린 문제

    이건 딱 “다 살아 있는데 왜 느리지?” 케이스였네요. DB 연결 수, 느린 쿼리(slow query, 지연 질의), 서비스 재시도 패턴이 겹치면서 간헐 지연이 생겼습니다. 이런 문제는 재시작으로 잠깐 가려질 수 있어서 더 위험합니다. 드디어 됐다! 싶었는데 다음날 다시 터지더라고요.

    정리하면, OpenStack 멀티노드 운영에서 가장 위험한 장애는 완전 다운보다 반쯤 되는 장애입니다. 운영자가 방심하기 쉽거든요.

    OpenStack 멀티노드 운영 장애 분석 관제 화면

    로그 추적, 큐 적체 확인, 네트워크 흐름 분석을 한 번에 보여주는 운영 관제 이미지 위치입니다.

    문제 줄이기 위해 정착시킨 검증 절차

    문제가 생긴 뒤 고치는 것도 중요하지만, 더 중요한 건 변경 후 검증입니다. 저는 아래 순서로 체크했습니다.

    1. 인증 확인: 토큰 발급과 서비스 카탈로그(service catalog, 서비스 목록) 확인
    2. 컴퓨트 확인: 하이퍼바이저 목록과 서비스 up/down 상태 확인
    3. 네트워크 확인: 네트워크 생성, 서브넷 연결, 포트 생성 테스트
    4. 부팅 확인: 테스트 인스턴스 생성 후 콘솔 접속 확인
    5. 삭제 확인: 인스턴스 삭제, 볼륨 정리, 포트 잔존 여부 확인

    간단한 검증 흐름 예시는 이렇습니다.

    openstack token issue
openstack network create lab-net
openstack subnet create --network lab-net --subnet-range 192.168.50.0/24 lab-subnet
openstack server create --flavor m1.small --image test-image --network lab-net test-vm
openstack server list
openstack console url show test-vm

    여기서 중요한 건 생성만 보는 게 아니라 삭제와 정리까지 확인하는 겁니다. 리소스 찌꺼기(resource orphan, 고아 리소스)가 쌓이기 시작하면 나중에 장애 분석이 훨씬 더 어려워집니다.

    1년 운영 후 남은 성과와 아쉬움

    🎉 성과부터 말하면, 운영 초반보다 장애 대응 시간이 눈에 띄게 줄었습니다. 원인은 대단한 튜닝이 아니라, 로그 보는 순서와 점검 절차가 정리됐기 때문이었습니다. OpenStack 클러스터 후기를 한 줄로 줄이면 이겁니다. 복잡성은 줄이지 못해도, 복잡성을 다루는 방법은 개선할 수 있다.

    반대로 아쉬움도 분명했습니다.

    • 초기 아키텍처 문서를 너무 늦게 정리했습니다.
    • 네트워크 변경 이력을 더 일찍 표준화했어야 했습니다.
    • 테스트 환경과 운영 환경 차이를 가볍게 보면 안 됐습니다.
    • “지금 되니까 괜찮다”는 판단이 가장 위험했습니다.

    특히 프로덕션 OpenStack 회고를 하면서 느낀 건, 운영자는 문제를 해결하는 사람인 동시에 문제가 다시 생기지 않게 만드는 사람이어야 한다는 점이었습니다. 근데 이게 말처럼 쉽진 않죠. 문서화는 귀찮고, 자동화는 미루기 쉽고, 장애는 꼭 바쁠 때 옵니다.

    OpenStack 멀티노드 운영 안정화 결과 요약 인포그래픽

    운영 절차 정리 전후의 안정화 흐름과 핵심 교훈을 비교하는 요약 시각화 이미지 위치입니다.

    OpenStack 멀티노드 운영 정리: 지금 다시 시작한다면

    💡 제가 지금 다시 처음부터 OpenStack 멀티노드 운영을 구성한다면 아래 순서로 갑니다.

    1. 네트워크 분리 설계부터 문서화합니다.
    2. 배포 자동화를 처음부터 전제로 둡니다.
    3. 공통 로그와 모니터링을 설치 초기에 붙입니다.
    4. 테스트 VM 생성/삭제 검증을 표준 절차로 만듭니다.
    5. 장애 기록 템플릿을 운영 첫날부터 사용합니다.

    이 다섯 개만 지켜도 OpenStack 배포 실패 사례의 상당수를 예방할 수 있습니다. 물론 환경마다 디테일은 다를 겁니다. 그래도 뼈대는 비슷하더라고요. 특히 OpenStack 멀티노드 운영은 “한 번 설치 성공”보다 “열 번 재현 가능”이 훨씬 값집니다.

    자주 묻는 질문

    Q1. 홈랩에서도 멀티노드가 의미가 있나요?

    있습니다. 오히려 작은 환경에서 역할 분리와 장애 흐름을 이해하기 좋습니다. 다만 과한 고가용성(HA, 고장 대비 이중화)보다는 기본 동작과 복구 절차부터 익히는 게 낫습니다.

    Q2. 가장 먼저 모니터링해야 할 것은 뭔가요?

    CPU나 메모리보다 먼저 API 응답 지연, 메시지 큐 적체, 데이터베이스 연결 상태, 네트워크 에이전트 상태를 보시는 걸 권합니다.

    Q3. 설치 도구보다 중요한 건 뭔가요?

    운영 문서, 변경 이력, 검증 절차입니다. 도구는 바꿀 수 있지만 운영 습관은 쉽게 안 바뀌거든요.

    마무리

    1년 동안 OpenStack 멀티노드 클러스터를 운영하면서 느낀 건, OpenStack은 화려한 기능보다 기본기가 훨씬 중요하다는 점이었습니다. 서비스 간 관계를 이해하고, 장애를 추적하는 순서를 만들고, 변경을 기록하는 것. 이 세 가지가 결국 운영 품질을 갈랐습니다. 저도 처음엔 “왜 이렇게 복잡하지?” 싶었는데, 하나씩 뜯어보니 결국 시스템은 거짓말을 안 하더라고요.

    혹시 지금 OpenStack 멀티노드 운영을 준비 중이시라면, 설치 성공 화면에서 끝났다고 생각하지 마시고 검증 절차부터 붙여보세요. 그게 나중에 가장 큰 차이를 만듭니다. 다음 글에서는 스토리지 연동과 백업 전략 쪽을 더 현실적으로 풀어보겠습니다. ✅

  • [OpenStack] OpenStack Neutron 네트워크 장애 진단 및 해결 5단계

    [OpenStack] OpenStack Neutron 네트워크 장애 진단 및 해결 5단계

    목차

    [OpenStack] OpenStack Neutron 네트워크 장애 진단 및 해결 5단계

    OpenStack Neutron 네트워크 장애는 경험해보신 분들은 알겠지만, VM은 떠 있는데 통신이 안 되고, Floating IP는 붙었는데 외부 접속이 안 되고, DHCP는 살아 있는 것 같은데 IP를 못 받아오는 식으로 정말 답답합니다. 저도 홈랩이랑 테스트 클러스터에서 OpenStack Neutron 네트워크 장애를 몇 번 크게 겪었는데요. 처음엔 인스턴스 문제인가 싶다가, 알고 보니 L2 브리지, L3 Agent, Security Group, MTU가 각각 따로 발목을 잡고 있더라고요. 그래서 이번 글에서는 제가 실제로 쓰는 흐름대로 OpenStack 네트워크 문제를 5단계로 줄여서 확인하는 방법을 정리해보겠습니다.

    컨트롤 플레인과 데이터 플레인이 어디서 갈리는지 한눈에 보는 구조입니다.

    1. OpenStack Neutron을 쉽게 말해보면

    쉽게 말해, Neutron은 클라우드 안에서 가상 스위치, 라우터, DHCP, 보안 정책을 한군데 관리해주는 네트워크 제어 계층이라고 보면 돼요. 여기서 중요한 건 Control Plane(컨트롤 플레인, 설정과 상태를 관리하는 영역)과 Data Plane(데이터 플레인, 실제 패킷이 흐르는 영역)을 분리해서 봐야 한다는 점입니다.

    예를 들어 CLI에서 네트워크와 포트가 멀쩡하게 보여도, 실제 노드의 Open vSwitch(오픈 브이 스위치, 가상 스위치) 브리지나 Linux namespace(리눅스 네임스페이스, 격리된 네트워크 공간)가 꼬이면 통신은 바로 끊깁니다. 저도 처음엔 API 결과만 보고 안심했다가 한참 삽질했었는데, 결국 패킷이 어디까지 갔는지를 봐야 답이 나오더라고요.

    2. OpenStack 네트워크 문제를 해결하는 Neutron 트러블슈팅 5단계

    1. 장애 범위 확인: 특정 VM만 문제인지, 특정 네트워크인지, 전체 노드 공통인지 먼저 자릅니다.
    2. Agent 상태 확인: DHCP Agent, L3 Agent, Open vSwitch Agent 또는 Linux Bridge Agent 상태를 봅니다.
    3. Namespace와 Port 확인: qdhcp, qrouter namespace 내부 인터페이스와 라우팅을 봅니다.
    4. Data Plane 확인: 브리지 매핑, 터널, 보안 정책, 포트 바인딩을 추적합니다.
    5. MTU, 라우팅, 외부망 확인: 마지막으로 잘 안 보이는 설정 불일치를 잡습니다.

    여기서 중요한 포인트! 위에서 아래로 내려가야 합니다. 반대로 보면 같은 명령만 반복하게 되거든요.

    3. 1단계: OpenStack 네트워크 장애 범위를 먼저 자르기

    장애가 났을 때 가장 먼저 할 일은 “어디까지 되느냐”를 확인하는 겁니다. 인스턴스 내부에서 게이트웨이 Ping이 되는지, 같은 서브넷끼리 통신이 되는지, Floating IP로 외부에서 들어오는지 순서대로 보면 생각보다 빨리 좁혀집니다.

    openstack server list
openstack network list
openstack subnet list
openstack port list --server <INSTANCE_ID>
openstack router list
openstack floating ip list

    이 단계에서는 아래처럼 메모를 남기면 좋습니다.

    • 특정 인스턴스만 안 되는가
    • 특정 Compute 노드에 올라간 인스턴스만 안 되는가
    • 내부 통신은 되고 외부만 안 되는가
    • DHCP 할당부터 실패하는가

    실제로 써보니까 이 메모 한 줄이 뒤에서 시간을 많이 줄여줍니다. 특히 특정 호스트에만 문제가 몰리면 Neutron 전체보다 하이퍼바이저 측 OVS나 브리지 설정을 먼저 의심해볼 수 있거든요.

    4. 2단계: Neutron Agent 상태부터 확인하기

    Neutron 트러블슈팅에서 가장 먼저 손에 잡히는 건 Agent 상태입니다. API는 살아 있는데 Agent가 죽어 있거나 heartbeat(하트비트, 상태 보고)가 끊긴 경우가 꽤 많습니다.

    openstack network agent list
systemctl status neutron-server
systemctl status neutron-dhcp-agent
systemctl status neutron-l3-agent
systemctl status neutron-openvswitch-agent

    환경에 따라 Linux Bridge를 쓰면 마지막 서비스명은 다를 수 있습니다. 핵심은 내가 쓰는 ML2 드라이버와 에이전트 조합을 정확히 알고 보는 겁니다.

    증상 우선 확인할 컴포넌트 자주 보는 포인트
    IP를 못 받음 DHCP Agent qdhcp namespace, dnsmasq 동작 여부
    외부 통신 안 됨 L3 Agent qrouter namespace, SNAT, 외부 게이트웨이
    동일 네트워크 간 통신 실패 OVS/Linux Bridge Agent 브리지 매핑, 포트 바인딩, 터널 상태
    간헐적 패킷 손실 MTU 및 Overlay 네트워크 VXLAN/GRE 오버헤드 반영 여부

    저는 여기서 꼭 로그도 같이 봅니다. 상태가 alive여도 내부적으로 재시도만 반복하는 경우가 있더라고요.

    journalctl -u neutron-openvswitch-agent -n 100
journalctl -u neutron-l3-agent -n 100
journalctl -u neutron-dhcp-agent -n 100
    OpenStack Neutron 네트워크 장애 점검용 Agent 상태 흐름 이미지

    장애 분석 시 어떤 Agent부터 확인하는지 흐름을 시각적으로 정리한 이미지입니다.

    5. 3단계: Namespace와 Port를 보면 길이 보입니다

    이제부터가 진짜입니다. CLI 결과는 정상인데 통신이 안 되는 경우, 저는 거의 습관처럼 namespace부터 봅니다. DHCP와 L3는 namespace 안에서 움직이기 때문에, 인터페이스가 실제로 붙어 있는지 보면 감이 옵니다.

    ip netns
ip netns exec qdhcp-<NETWORK_ID> ip addr
ip netns exec qdhcp-<NETWORK_ID> ip route
ip netns exec qrouter-<ROUTER_ID> ip addr
ip netns exec qrouter-<ROUTER_ID> ip route
ip netns exec qrouter-<ROUTER_ID> ping -c 3 <GATEWAY_IP>

    여기서 자주 보는 체크 포인트는 이렇습니다.

    • qdhcp namespace가 아예 없으면 DHCP 스케줄링이나 Agent 문제일 가능성이 큽니다.
    • qrouter namespace는 있는데 외부 인터페이스가 없으면 라우터 게이트웨이 연결을 다시 봐야 합니다.
    • 포트 상태가 DOWN이면 바인딩 실패나 하이퍼바이저 측 문제를 의심합니다.
    openstack port show <PORT_ID>
openstack router show <ROUTER_ID>
openstack network show <NETWORK_ID>

    제가 직접 해보니 port binding:vif_type, binding:host_id 정보도 꽤 중요했습니다. 인스턴스는 떠 있는데 바인딩이 엉킨 상태면 네트워크만 죽어 있는 애매한 상황이 나오거든요.

    6. 4단계: Data Plane 확인, 특히 OVS 브리지와 보안 정책

    이제 패킷이 실제로 흐르는 길을 봐야 합니다. Open vSwitch를 쓴다면 브리지와 포트 구성이 의도대로 들어갔는지부터 체크합니다. 여기서 클라우드 네트워크 오류가 많이 납니다. 설정 파일은 맞는데 실제 브리지 매핑이 빠진 경우, 터널 인터페이스가 안 살아난 경우가 생각보다 흔합니다.

    ovs-vsctl show
ovs-vsctl list-br
ovs-vsctl list-ports br-int
ovs-vsctl list-ports br-tun
ip link show
bridge fdb show

    대표적으로 보는 설정 파일 예시는 이런 형태입니다.

    [ovs]
bridge_mappings = physnet1:br-ex
local_ip = 10.0.0.10

[agent]
tunnel_types = vxlan
l2_population = true

[securitygroup]
enable_security_group = true

    여기서 제가 몇 번 당했던 게 Security Group(시큐리티 그룹, 가상 방화벽)입니다. 운영 중에는 OpenStack 장애 해결을 위해 네트워크가 죽은 것처럼 보여도 사실은 ICMP나 SSH만 막혀 있는 경우가 있습니다.

    openstack security group rule list
iptables -S
ip netns exec qrouter-<ROUTER_ID> iptables -t nat -S

    혹시 이런 경험 있으신가요? Floating IP는 붙었는데 외부에서만 접속이 안 되는 경우요. 저는 처음엔 라우터가 문제인 줄 알았는데, 실제론 보안 그룹 규칙과 외부 브리지 uplink 설정이 같이 꼬여 있었습니다. 삽질 좀 했습니다 ㅎㅎ

    OpenStack Neutron 네트워크 장애 원인 파악을 위한 OVS 브리지 구성 이미지

    br-int, br-tun, br-ex가 어떻게 이어지는지 이해하면 장애 지점이 훨씬 빨리 보입니다.

    7. 5단계: MTU, DHCP, 외부망 라우팅까지 마무리 확인

    여기까지 다 맞는데도 이상하면 MTU를 꼭 보셔야 합니다. VXLAN 같은 Overlay network(오버레이 네트워크, 기존 네트워크 위에 캡슐화해 올리는 가상 네트워크)는 헤더 오버헤드가 있어서, 물리망 MTU와 가상망 MTU가 어긋나면 큰 패킷에서만 조용히 깨집니다. 이게 진짜 사람 괴롭힙니다.

    openstack subnet show <SUBNET_ID>
ip link show dev <INTERFACE>
ping -M do -s 1400 <TARGET_IP>

    DHCP가 의심될 때는 dnsmasq 로그나 lease 파일도 같이 봅니다.

    ps -ef | grep dnsmasq
ip netns exec qdhcp-<NETWORK_ID> cat /var/lib/neutron/dhcp/<NETWORK_ID>/hosts

    외부망 연결에서는 아래 항목을 같이 체크하면 좋습니다.

    1. 외부 네트워크가 올바른 물리 브리지에 매핑되었는가
    2. L3 Agent가 해당 라우터를 실제로 호스팅하고 있는가
    3. SNAT 규칙이 생성되었는가
    4. 업스트림 스위치 또는 라우터에서 VLAN/Untagged 설정이 맞는가

    사실 마지막 4번이 종종 핵심입니다. OpenStack 장애 해결이라고 들어왔는데, 알고 보면 물리 스위치 설정 하나 때문에 고생하는 경우가 꽤 있습니다.

    8. 자주 겪는 장애 패턴과 해결 메모

    • ⚠️ DHCP namespace 없음: DHCP Agent down 또는 스케줄링 문제를 먼저 확인합니다.
    • ⚠️ Router namespace는 있는데 외부 IP Ping 실패: br-ex uplink, gateway, upstream 라우팅을 봅니다.
    • ⚠️ 특정 Compute에 올라간 VM만 통신 실패: 해당 노드의 OVS Agent, 터널, 포트 바인딩을 우선 점검합니다.
    • ⚠️ 작은 Ping은 되는데 애플리케이션 통신 실패: MTU mismatch 가능성이 큽니다.
    • ⚠️ 재부팅 후 간헐적으로 실패: 서비스 기동 순서나 브리지 자동 생성 누락을 의심합니다.

    제가 예전에 제일 오래 잡았던 건 “상태는 다 정상이지만 큰 패킷만 죽는” 케이스였는데요. 결국 MTU 문제였습니다. 드디어 됐다! 싶었던 순간이 아직도 기억나네요. 그래서 요즘은 Neutron 쪽에서 원인 못 찾으면 MTU 테스트를 꽤 빨리 해보는 편입니다. 이게 진짜 편하더라고요.

    OpenStack Neutron 네트워크 장애 해결 전후 검증 결과 이미지

    진단 전후로 어떤 항목이 정상화됐는지 비교하는 검증용 시각 자료입니다.

    9. 검증, 결과 확인, 그리고 다음 단계

    수정 후에는 반드시 검증(Validation, 적용 결과 확인)을 남겨야 합니다. 눈으로 한 번 되고 끝내면 다음 장애 때 같은 길을 또 돌게 됩니다.

    openstack network agent list
openstack port list --server <INSTANCE_ID>
ip netns exec qrouter-<ROUTER_ID> ping -c 3 8.8.8.8
ip netns exec qdhcp-<NETWORK_ID> ping -c 3 <INSTANCE_IP>
    • ✅ 인스턴스가 DHCP로 IP를 정상 할당받는지
    • ✅ 같은 네트워크 내 동서 트래픽이 되는지
    • ✅ 라우터를 통해 남북 트래픽이 되는지
    • ✅ Floating IP를 통한 외부 접근이 되는지
    • ✅ 재시작 후에도 동일하게 유지되는지

    정리하면, OpenStack Neutron 네트워크 장애는 복잡해 보여도 “범위 자르기 → Agent 확인 → Namespace 확인 → Data Plane 추적 → MTU/외부망 점검” 순서로 가면 훨씬 덜 헤맵니다. 저도 처음엔 이게 뭔가 싶었는데, 결국 패킷이 어디서 멈추는지만 찾으면 답은 나오더라고요.

    다음 글에서는 Security Group과 Distributed Virtual Routing(DVR, 분산 가상 라우팅) 관점에서 장애를 더 세분화해서 다뤄볼 예정입니다. 이전 글에서 다뤘던 Linux bridge와 OVS 기본 구조를 같이 보시면 이해가 더 빨라집니다. 🎉

    FAQ

    • Q. Neutron API는 정상인데 통신만 안 됩니다.
      A. API 정상과 데이터 플레인 정상은 다릅니다. namespace, OVS 브리지, 보안 정책을 같이 봐야 합니다.
    • Q. Floating IP만 안 됩니다.
      A. L3 Agent, SNAT, br-ex 연결, 업스트림 라우팅을 우선 확인해보세요.
    • Q. 장애 재현이 어렵습니다.
      A. 호스트별, 네트워크별, 패킷 크기별로 조건을 나눠 기록하면 원인 파악이 훨씬 쉬워집니다.
    OpenStack Neutron 네트워크 장애 진단 5단계 요약 인포그래픽

    운영자가 바로 따라 할 수 있도록 5단계 흐름을 한 장으로 요약한 이미지입니다.

  • [클라우드] VMware ESXi에서 OpenStack으로 전환한 실제 사례

    [클라우드] VMware ESXi에서 OpenStack으로 전환한 실제 사례

    목차

    [클라우드] VMware ESXi에서 OpenStack으로 전환한 실제 사례

    VMware OpenStack 마이그레이션을 고민하는 분들이 요즘 정말 많으시죠. 라이선스 정책 변화나 비용 구조, 그리고 운영 자동화 수준을 다시 점검해야 하는 시점이 오면 결국 한 번은 ESXi OpenStack 전환을 검토하게 되더라고요. 저도 처음엔 “하이퍼바이저(Hypervisor, 가상화 실행 계층)만 바꾸면 끝나는 거 아닌가?” 싶었는데, 실제로 해보니 전혀 아니었습니다. 컴퓨트(Compute), 네트워크(Network), 스토리지(Storage), 이미지(Image) 관리 방식이 다 바뀌거든요. 그래서 오늘은 제가 홈랩과 내부 테스트 환경에서 진행했던 흐름을 바탕으로, VMware 대안 OpenStack을 검토할 때 어디서 막히고 어떻게 풀어야 하는지 경험 위주로 정리해보겠습니다.

    특히 이 글은 “OpenStack이 좋아 보이는데 실제 전환은 어떻게 하지?”, “클라우드 마이그레이션 사례를 봐도 다 추상적이던데 실무 감각이 있는 글이 없네” 하셨던 분들께 맞춰 썼습니다. 숫자 뻥튀기나 과장 없이, 제가 직접 부딪히며 정리한 포인트만 담아볼게요.

    VMware OpenStack 마이그레이션 전체 아키텍처 다이어그램

    기존 ESXi 가상머신이 이미지 변환과 네트워크 재설계를 거쳐 OpenStack으로 이동하는 전체 흐름을 보여주는 개요 이미지입니다.

    왜 VMware ESXi에서 OpenStack으로 옮기게 될까요

    쉽게 말해서 ESXi는 가상화 플랫폼 중심의 운영 경험을 주고, OpenStack은 클라우드 운영체계에 가깝습니다. 둘 다 가상머신(VM, Virtual Machine)을 띄운다는 점은 같지만, 운영 철학이 꽤 다릅니다. VMware 환경은 관리 콘솔이 잘 정리되어 있고 초기 안정화가 쉬운 편이죠. 반면 OpenStack은 구성 요소가 많아서 처음엔 복잡해 보이지만, 자동화와 API(Application Programming Interface, 프로그램 제어 인터페이스) 중심 운영으로 넘어가면 확실히 강점이 있습니다.

    제가 전환을 결심했던 이유도 단순했습니다.

    • 비용 구조를 장기적으로 통제하고 싶었습니다.
    • API 기반 자동화를 더 강하게 가져가고 싶었습니다.
    • 네트워크를 더 세밀하게 분리하고 싶었습니다.
    • 벤더 종속성(Vendor lock-in, 특정 벤더 의존)을 줄이고 싶었습니다.

    다만 여기서 중요한 게 하나 있어요. VMware OpenStack 마이그레이션은 제품 교체가 아니라 운영 모델 전환이라는 점입니다. 이거 무시하면 중간에 꼭 한 번 크게 흔들려요. 저도 처음엔 VM만 잘 옮기면 될 줄 알았는데, 보안그룹(Security Group, 가상 방화벽), 네트워크 세그먼트, 스토리지 타입 설계에서 삽질 좀 했습니다 ㅎㅎ

    핵심 개념 정리: ESXi와 OpenStack은 무엇이 다를까

    이 부분은 꼭 짚고 넘어가야 해요. 독자분들이 제일 많이 헷갈려 하시는 부분이거든요.

    영역 VMware ESXi 중심 OpenStack 중심
    가상화 실행 ESXi 보통 KVM(Kernel-based Virtual Machine)
    관리 계층 vCenter OpenStack API와 Horizon
    이미지 관리 템플릿, OVA/OVF Glance(글랜스, 이미지 서비스)
    컴퓨트 제어 클러스터/호스트 중심 Nova(노바, 컴퓨트 서비스)
    네트워크 vSwitch, 포트 그룹 Neutron(뉴트론, 네트워크 서비스)
    블록 스토리지 데이터스토어 중심 Cinder(신더, 블록 스토리지)
    인증 vCenter 계정/연동 Keystone(키스톤, 인증 서비스)

    쉽게 말해서 VMware에서는 사람이 콘솔에서 정리해주는 느낌이 강했다면 OpenStack은 “정책과 API로 자원을 선언적으로 다룬다”는 느낌이 더 강합니다. 그래서 클라우드 마이그레이션 사례를 볼 때도 VM 파일 이동만 보면 안 되고, 네트워크와 접근제어를 같이 봐야 합니다.

    전환 전에 꼭 분류해야 할 워크로드

    1. 상태 저장형(Stateful)인지 확인합니다. 데이터베이스처럼 디스크 의존도가 높으면 더 신중해야 합니다.
    2. 정적 IP, MAC 의존성이 있는지 봅니다. 방화벽이나 라이선스 서버가 여기서 많이 걸립니다.
    3. 운영체제 부팅 방식이 BIOS인지 UEFI인지 점검합니다.
    4. 게스트 OS 안에 VMware Tools 의존 설정이 있는지 확인합니다.
    5. 백업/복구 체계가 OpenStack 쪽에서도 유지되는지 따져봅니다.

    제가 직접 해보니 이 분류 작업이 귀찮아 보여도 가장 중요했습니다. 이걸 대충 하면 나중에 전환 일정이 아니라 장애 대응 일정이 되어버립니다.

    사전 준비: VMware OpenStack 마이그레이션 체크리스트

    실전 들어가기 전에 제가 잡았던 기준은 아래와 같았습니다. 여기서 절반이 결정된다고 봐도 됩니다.

    • 대상 VM 목록: 운영, 스테이징, 개발을 분리합니다.
    • 종속성 매핑: DB, 외부 API, DNS, NTP, 라이선스 서버 연결을 정리합니다.
    • 네트워크 설계: OpenStack 테넌트 네트워크와 외부 네트워크를 미리 정의합니다.
    • 이미지 변환 절차: VMDK에서 QCOW2 또는 RAW로 갈지 정합니다.
    • 전환 방식: 빅뱅(Big Bang)보다 단계적 전환을 권장합니다.
    • 롤백 계획: 문제 생기면 다시 ESXi에서 기동할 수 있게 둡니다.

    저는 처음에 네트워크를 나중에 맞추면 되겠지 하고 넘어갔다가, OpenStack의 포트(Port)와 보안그룹 정책 때문에 통신 확인에 시간을 꽤 썼습니다. VM 부팅보다 통신 성공이 더 어렵더라고요.

    실전 구현 1: ESXi VM 추출과 디스크 변환

    이제 본론입니다. 제가 많이 썼던 흐름은 VM 종료 – 디스크 추출 – 이미지 변환 – OpenStack 업로드 – 테스트 부팅 순서였습니다. 무중단 전환이 절대적으로 필요한 서비스가 아니라면, 이 방식이 가장 단순하고 예측 가능했습니다.

    1. VMware 쪽 VM 상태 확인

    govc vm.info -vm /Datacenter/vm/app-server-01

    govc는 VMware vSphere 환경을 CLI(Command Line Interface, 명령행 인터페이스)로 다룰 때 꽤 유용합니다. 환경에 따라 vCenter를 쓰지 않고 직접 ESXi에서 파일을 꺼낼 수도 있습니다.

    2. OVF 또는 VMDK 형태로 추출

    ovftool vi://[email protected]@vcenter.example.local/Datacenter/vm/app-server-01 ./app-server-01

    환경에 따라 OVA/OVF 패키지로 받거나 VMDK만 직접 확보해도 됩니다. 저는 처음엔 OVA가 편해 보여서 그렇게 했는데, 실제로는 디스크 변환만 필요할 때 VMDK 직취득이 더 단순한 경우도 있었습니다.

    3. VMDK를 QCOW2로 변환

    qemu-img convert -p -f vmdk -O qcow2 app-server-01-disk1.vmdk app-server-01.qcow2
qemu-img info app-server-01.qcow2

    여기서 qemu-img는 거의 필수 도구라고 보시면 됩니다. 변환 후 qemu-img info로 포맷과 가상 크기를 꼭 확인하세요. 저는 한 번은 스냅샷 체인이 남은 VMDK를 잘못 잡아서 이미지가 이상하게 올라간 적이 있었습니다.

    VMware OpenStack 마이그레이션에서 VMDK를 QCOW2로 변환하는 작업 흐름 이미지

    VMDK 추출, qemu-img 변환, Glance 업로드로 이어지는 실제 작업 흐름을 설명하는 이미지입니다.

    실전 구현 2: OpenStack 이미지 업로드와 네트워크 구성

    OpenStack으로 넘어오면 이제부터는 이미지와 네트워크가 핵심입니다. 이 구간에서 “드디어 됐다!” 싶다가도 보안그룹 하나 빠뜨리면 SSH도 안 붙고, 웹도 안 열리고, 괜히 이미지 탓하게 됩니다.

    1. 이미지 등록

    openstack image create "app-server-01" \
  --file app-server-01.qcow2 \
  --disk-format qcow2 \
  --container-format bare \
  --private

    OpenStack의 Glance는 이미지 저장소 역할을 합니다. 템플릿 개념과 비슷하지만, API 중심 운영에 더 잘 녹아 있습니다.

    2. 네트워크와 서브넷 준비

    openstack network create prod-net
openstack subnet create prod-subnet \
  --network prod-net \
  --subnet-range 192.168.100.0/24 \
  --dns-nameserver 8.8.8.8

    물론 실무에서는 외부 DNS를 그대로 넣기보다 내부 DNS 체계를 맞추는 경우가 많습니다. 여기서는 예시만 단순하게 보여드리는 거예요.

    3. 보안그룹 생성

    openstack security group create web-sec
openstack security group rule create --protocol tcp --dst-port 22 web-sec
openstack security group rule create --protocol tcp --dst-port 80 web-sec
openstack security group rule create --protocol tcp --dst-port 443 web-sec

    여기서 중요한 포인트! VMware 쪽에서는 포트 그룹과 상위 방화벽 정책으로 어느 정도 익숙하게 처리되던 것이, OpenStack에서는 인스턴스 단위 정책으로 체감될 때가 있습니다. 처음엔 이게 뭔가 싶었는데, 익숙해지면 오히려 훨씬 명확합니다.

    4. 인스턴스 기동

    openstack server create app-server-01 \
  --flavor m1.medium \
  --image app-server-01 \
  --network prod-net \
  --security-group web-sec

    이후 Floating IP(Floating IP, 외부 접근용 유동 IP)가 필요한 구조라면 외부 네트워크에 붙여줘야 합니다.

    openstack floating ip create public-net
openstack server add floating ip app-server-01 203.0.113.10

    ⚠️ 실제로 많이 막히는 문제들: ESXi OpenStack 전환 트러블슈팅

    여기가 제일 중요합니다. 성공 사례는 대부분 결과만 보여주는데, 실무에서는 이 구간이 진짜 본게임입니다.

    1. 부팅은 되는데 네트워크가 안 붙는 경우

    원인은 보통 세 가지였습니다.

    • 게스트 OS 안에 VMware 네트워크 인터페이스 설정이 남아 있는 경우
    • udev 규칙 때문에 NIC 이름이 바뀌는 경우
    • OpenStack 보안그룹에서 필요한 포트가 안 열린 경우

    리눅스는 부팅 후 인터페이스 이름을 먼저 확인했습니다.

    ip addr
ip route
journalctl -b | grep -i network

    특히 CentOS나 Ubuntu 구버전 계열은 예전 NIC 정보 때문에 인터페이스가 달라지는 일이 종종 있었습니다. 저는 이 문제를 몇 번 겪고 나서는 이미지 올리기 전에 네트워크 설정 파일을 먼저 정리하는 습관이 생겼습니다.

    2. 디스크는 붙었는데 부팅이 불안정한 경우

    이건 VirtIO(Virtual I/O, 가상 장치 고속 드라이버) 드라이버나 부팅 로더 문제일 때가 많았습니다. 윈도우 게스트는 VirtIO 드라이버 준비 여부를 꼭 점검하셔야 하고, 리눅스는 initramfs 안에 필요한 드라이버가 포함됐는지 보는 게 좋습니다.

    3. 시간이 틀어지거나 애플리케이션이 이상 동작하는 경우

    NTP(Network Time Protocol, 시간 동기화)와 DNS는 가볍게 보면 안 됩니다. OpenStack 쪽 인스턴스가 올라오고 서비스는 떠 있는데, 인증이나 토큰 검증이 계속 실패하면 시간 동기화부터 보셔야 합니다. 이거 진짜 자주 놓칩니다.

    4. 스냅샷 의존 운영 습관

    VMware에서 스냅샷을 임시 안전장치처럼 쓰던 습관이 있으면 OpenStack으로 넘어와서 운영 방식 자체를 다시 잡아야 합니다. 인스턴스 스냅샷, 볼륨 스냅샷, 이미지 버전 관리, 백업 정책을 분리해서 생각해야 하거든요. 저도 처음엔 “스냅샷 느낌이 왜 다르지?” 싶었는데, 클라우드식 운영으로 사고방식을 바꾸니까 정리가 되더라고요.

    ESXi OpenStack 전환 시 OpenStack 네트워크와 보안그룹 구성 다이어그램

    테넌트 네트워크, 라우터, 보안그룹, 플로팅 IP 관계와 함께 통신 장애 포인트를 표시하는 설명 이미지입니다.

    검증 방법: 클라우드 마이그레이션 사례에서 놓치면 안 되는 체크

    전환이 끝났다고 바로 운영으로 넘기면 안 됩니다. 저는 아래 순서로 검증했습니다.

    1. 인스턴스 상태 확인: ACTIVE 상태인지, 콘솔 로그에 에러가 없는지 봅니다.
    2. 네트워크 점검: 내부 통신, 외부 통신, DNS 해석을 확인합니다.
    3. 애플리케이션 점검: 웹, API, 배치 작업, 데이터 연결을 확인합니다.
    4. 성능 비교: 최소한 부팅 시간, 응답성, 디스크 지연 체감은 체크합니다.
    5. 운영 도구 점검: 백업, 모니터링, 로그 수집이 붙는지 확인합니다.
    openstack server list
openstack console log show app-server-01
ping -c 4 192.168.100.10
curl -I http://192.168.100.10

    여기서 제가 제일 강조하고 싶은 건, VM이 떠 있는 것과 서비스가 정상인 것은 다르다는 점입니다. 실제로는 애플리케이션 레벨 체크가 마지막 문턱이었습니다.

    클라우드 마이그레이션 사례 검증을 위한 OpenStack 인스턴스 상태 대시보드

    마이그레이션 이후 인스턴스 상태, 네트워크 연결, 서비스 응답을 한눈에 확인하는 검증 대시보드 이미지입니다.

    전환 결과: 제가 얻은 것과 예상 밖의 변화

    결론부터 말씀드리면, 제 경우엔 VMware OpenStack 마이그레이션 자체는 성공이었습니다. 특히 개발/스테이징 계열 워크로드에서는 OpenStack의 장점이 빨리 보였습니다. API로 인스턴스를 만들고, 네트워크를 분리하고, 이미지 기반으로 재현 가능한 환경을 만드는 흐름이 아주 좋았거든요.

    반대로 예상보다 시간이 더 걸린 부분도 있었습니다.

    • 운영팀의 사고방식 전환: 가상머신 관리에서 클라우드 자원 관리로 바뀝니다.
    • 네트워크 설계: OpenStack Neutron 이해도가 없으면 초반에 막힙니다.
    • 표준 이미지 전략: 아무 VM이나 옮기는 방식은 오래 못 갑니다.

    즉, VMware 대안 OpenStack은 충분히 현실적인 선택지이지만, “기존 VM을 그냥 다른 데 올린다”는 접근으로는 만족도가 떨어질 수 있습니다. 반대로 이미지 표준화, 자동화, 셀프서비스 포털, IaC(Infrastructure as Code, 코드형 인프라)까지 연결하면 진가가 나옵니다.

    정리와 다음 단계: 이런 순서로 접근하면 덜 흔들립니다

    혹시 지금 전환을 검토 중이시라면, 제가 추천하는 순서는 이렇습니다.

    1. 가장 덜 중요한 개발 VM부터 파일럿으로 옮깁니다.
    2. 이미지 변환 절차를 문서화합니다.
    3. 네트워크와 보안그룹 템플릿을 먼저 만듭니다.
    4. 백업, 모니터링, 로그 수집을 붙인 뒤 운영계로 확장합니다.
    5. 마지막에 표준 이미지와 자동 배포 흐름까지 정리합니다.

    사실 저도 처음엔 OpenStack이 너무 많은 조각으로 보였는데, 하나씩 이해하고 나니 왜 다들 클라우드 운영체계라고 부르는지 알겠더라고요. 반대로 VMware에서 익숙했던 편의 기능이 사라진 듯 느껴지는 순간도 있었는데, 그건 “없다”기보다 “다른 방식으로 설계해야 한다”에 가까웠습니다.

    이전 글에서 다뤘던 가상화 스토리지 설계 내용과도 연결되는 부분이 있고, 다음 글에서는 OpenStack에서 표준 이미지와 cloud-init(cloud-init, 초기 부팅 자동 설정)를 묶어 운영하는 방법도 다뤄볼 예정입니다. 여기까지 정리해보니, 결국 성공 포인트는 기술 하나가 아니라 운영 모델의 재설계였습니다.

    VMware 대안 OpenStack 전환 포인트 비교 인포그래픽

    운영 모델, 네트워크, 스토리지, 자동화 관점에서 VMware와 OpenStack의 차이를 요약한 마무리 인포그래픽입니다.

    자주 묻는 질문

    Q1. ESXi에서 OpenStack으로 무중단 전환이 가능한가요?

    가능 여부는 애플리케이션 구조에 달려 있습니다. 일반적인 단일 VM 서비스는 점검 시간을 잡고 이미지 기반으로 옮기는 편이 더 현실적이었습니다.

    Q2. 모든 VMware VM이 그대로 OpenStack에서 잘 동작하나요?

    아닙니다. 네트워크 설정, 드라이버, 부팅 방식, 에이전트 의존성에 따라 손봐야 할 부분이 꽤 있습니다. 특히 오래된 VM일수록 사전 점검이 중요합니다.

    Q3. OpenStack이 무조건 비용 절감으로 이어지나요?

    단순히 플랫폼만 바꾼다고 바로 그렇진 않습니다. 운영 역량, 자동화 수준, 표준화 정도가 함께 따라와야 의미 있는 효과가 납니다.

    Q4. 가장 먼저 테스트할 워크로드는 무엇이 좋을까요?

    개발 또는 스테이징 환경의 웹 애플리케이션부터 권장합니다. 네트워크와 이미지 변환 절차를 검증하기에 적당하고, 실패했을 때 영향도 상대적으로 적습니다.

  • [OpenStack] OpenStack 멀티노드 배포, 컨트롤러/컴퓨트/네트워크 노드 역할 분석

    [OpenStack] OpenStack 멀티노드 배포, 컨트롤러/컴퓨트/네트워크 노드 역할 분석

    목차

    [OpenStack] OpenStack 멀티노드 배포, 컨트롤러/컴퓨트/네트워크 노드 역할 분석

    OpenStack 멀티노드 배포를 처음 붙잡으면 제일 먼저 막히는 지점이 있습니다. “컨트롤러 노드, 컴퓨트 노드, 네트워크 노드가 정확히 뭐가 다른 거지?” 이 부분이 정리되지 않으면 설치 문서를 몇 번을 읽어도 머릿속이 안 이어지더라고요. 저도 홈랩에서 처음 구성했을 때는 서비스 이름은 외웠는데, 트래픽이 어디로 흐르고 장애가 나면 어느 노드부터 봐야 하는지가 감이 안 왔거든요. 결국 삽질 좀 했고요 ㅎㅎ 이번 글에서는 제가 실제로 OpenStack 아키텍처를 잡을 때 기준으로, 각 노드 역할을 현실적으로 어떻게 나누는지, 왜 그렇게 나누는지, 그리고 OpenStack 멀티노드 배포를 할 때 꼭 체크해야 할 포인트를 정리해보겠습니다.

    OpenStack 멀티노드 배포 전체 아키텍처를 보여주는 다이어그램

    컨트롤러 노드, 컴퓨트 노드, 네트워크 노드의 관계를 한눈에 보여주는 전체 구성도입니다.

    왜 OpenStack 멀티노드 배포에서 역할 분리가 중요한가

    단일 노드(All-in-One) 설치는 학습용으로는 좋습니다. 그런데 실제 운영 감각을 익히려면 멀티노드가 훨씬 중요합니다. 쉽게 말해 컨트롤러 노드(Controller Node)는 두뇌, 컴퓨트 노드(Compute Node)는 일꾼, 네트워크 노드(Network Node)는 교통정리 담당이라고 보면 됩니다. 이 셋이 섞여 있으면 처음엔 간단해 보여도, 장애 원인 추적이나 성능 병목 분석이 어려워집니다.

    제가 한 번 해봤는데 OpenStack 멀티노드 배포의 핵심은 “서비스를 설치하는 것”보다 “역할을 분리해서 운영 포인트를 명확히 만드는 것”이었거든요. 특히 CPU를 많이 쓰는 가상머신 생성 작업과 API 요청, 이미지 배포, 가상 네트워크 처리를 한 장비에 몰아넣으면 어디서 병목이 나는지 판단이 흐려집니다.

    OpenStack 아키텍처를 쉽게 풀어보면

    OpenStack 아키텍처는 여러 서비스가 협업하는 구조입니다. 대표적으로 Keystone(키스톤, 인증 서비스), Nova(노바, 컴퓨트 서비스), Neutron(뉴트론, 네트워크 서비스), Glance(글랜스, 이미지 서비스)가 중심입니다. 여기에 메시지 브로커(Message Broker)인 RabbitMQ, 데이터베이스(Database)인 MariaDB, 캐시(Cache) 역할의 Memcached 같은 기반 서비스가 붙습니다.

    노드 주요 역할 대표 서비스 운영 포인트
    컨트롤러 노드 API, 인증, 스케줄링, 이미지 관리 Keystone, Nova API, Glance, Neutron Server DB, MQ, API 가용성 확인
    컴퓨트 노드 가상머신 생성 및 실행 nova-compute, 하이퍼바이저(Hypervisor) KVM 지원, 리소스 사용량, 에이전트 상태
    네트워크 노드 가상 라우터, DHCP, NAT, Floating IP Neutron L3/DHCP/Metadata Agent 또는 OVN 구성요소 브리지, 인터페이스 매핑, 외부망 연결

    여기서 중요한 포인트! 컨트롤러 노드는 “명령을 내리는 곳”이고, 컴퓨트 노드는 “실제로 VM을 띄우는 곳”입니다. 네트워크 노드는 “VM이 외부와 통신하게 만드는 곳”이고요. 이 흐름만 이해해도 OpenStack 아키텍처가 훨씬 덜 복잡하게 보입니다.

    노드별 역할 분석: 어디까지 맡기는 게 현실적인가

    컨트롤러 노드

    컨트롤러 노드는 생각보다 바쁩니다. 사용자 로그인, 프로젝트(Project) 조회, 이미지 등록, 인스턴스(Instance) 생성 요청, 스케줄링까지 다 이쪽으로 들어옵니다. 그래서 CPU보다도 서비스 간 연결 상태와 데이터베이스 안정성이 더 중요하더라고요. 실제로 써보니까 인스턴스가 안 떠서 컴퓨트 노드를 의심했는데, 알고 보니 컨트롤러의 RabbitMQ 인증 설정이 꼬인 경우도 있었습니다.

    컴퓨트 노드

    컴퓨트 노드는 비교적 단순합니다. 하지만 가장 많이 일합니다. 하이퍼바이저로 보통 KVM(QEMU/KVM)을 쓰고, nova-compute가 컨트롤러와 통신하면서 VM을 생성합니다. 저도 처음엔 “API가 안 되면 컴퓨트 문제겠지” 했었는데, 대부분은 반대더라고요. 컴퓨트 노드는 대개 증상만 보여주고, 원인은 컨트롤러 쪽 설정 누락인 경우가 많았어요.

    네트워크 노드

    이 노드는 OpenStack 멀티노드 배포에서 제일 헷갈리거든요. 외부 네트워크(External Network), 테넌트 네트워크(Tenant Network), 라우터(Router), NAT(Network Address Translation), Floating IP까지 한꺼번에 얽혀 있거든요. 근데 쉽게 말해 내부 VM들이 서로 통신하고, 필요하면 외부 인터넷까지 나가도록 길을 만들어주는 역할입니다. 여기서 브리지(Bridge) 이름 하나만 잘못 잡아도 통신이 끊기더라고요. 제가 실제로 가장 오래 삽질한 부분도 여기였어요.

    실전 구현: OpenStack 멀티노드 배포 기본 순서

    아래 예시는 학습용으로 가장 이해하기 쉬운 3노드 분리 구조입니다. 배포 도구는 환경마다 다르지만, 역할 자체는 크게 다르지 않습니다.

    1. 관리 네트워크(Management Network)와 외부 네트워크(External Network)를 분리합니다.
    2. 컨트롤러 노드에 공통 서비스와 API 계층을 올립니다.
    3. 컴퓨트 노드에 하이퍼바이저와 nova-compute를 붙입니다.
    4. 네트워크 노드에 Neutron 관련 에이전트와 브리지를 구성합니다.
    5. 서비스 등록 후 테스트 인스턴스를 생성해 데이터패스(Data Path)를 검증합니다.
    호스트명 역할 예시 관리 IP 비고
    controller 컨트롤러 노드 10.0.0.10 DB, MQ, API 집중
    compute1 컴퓨트 노드 10.0.0.21 KVM 사용
    network 네트워크 노드 10.0.0.31 외부 NIC 별도 권장

    1. 기본 통신과 이름 해석 준비

    sudo hostnamectl set-hostname controller
sudo bash -c 'cat >> /etc/hosts <<EOF
10.0.0.10 controller
10.0.0.21 compute1
10.0.0.31 network
EOF'

    모든 노드에서 호스트명 해석이 맞아야 거든요. 별거 아닌 것 같아도, 이 단계가 틀리면 서비스 등록이 줄줄이 어긋납니다.

    2. 컨트롤러 노드에 공통 서비스 준비

    sudo apt update
sudo apt install -y mariadb-server rabbitmq-server memcached
    sudo rabbitmqctl add_user openstack strongpassword
sudo rabbitmqctl set_permissions openstack ".*" ".*" ".*"

    여기서 컨트롤러 노드는 단순히 API만 올리는 서버가 아닙니다. OpenStack 서비스들이 서로 대화하는 중심축이 됩니다.

    OpenStack 멀티노드 배포의 컨트롤러 노드 서비스 흐름 이미지

    컨트롤러 노드에 Keystone, Nova API, Glance, Neutron Server, RabbitMQ, MariaDB가 어떻게 연결되는지 보여주는 구성도입니다.

    3. Keystone, Glance, Nova API, Neutron Server 등록

    openstack service create --name keystone identity
openstack service create --name glance image
openstack service create --name nova compute
openstack service create --name neutron network
    openstack endpoint create --region RegionOne identity public http://controller:5000/v3
openstack endpoint create --region RegionOne image public http://controller:9292
openstack endpoint create --region RegionOne compute public http://controller:8774/v2.1
openstack endpoint create --region RegionOne network public http://controller:9696

    명령 자체는 단순해 보이는데, 실제로는 인증 토큰, 서비스 사용자, 데이터베이스 권한 설정이 같이 맞아야 합니다. 저는 여기서 엔드포인트(Endpoint) URL 오타 하나 때문에 Horizon 대시보드에서 서비스가 살아 있어도 호출이 실패했던 적이 있습니다.

    4. 컴퓨트 노드 연결

    sudo apt update
sudo apt install -y qemu-kvm libvirt-daemon-system nova-compute
    [DEFAULT]
transport_url = rabbit://openstack:strongpassword@controller
my_ip = 10.0.0.21

[api]
auth_strategy = keystone

[keystone_authtoken]
auth_url = http://controller:5000
memcached_servers = controller:11211
project_name = service
username = nova
password = novapass

[vnc]
enabled = true
server_proxyclient_address = 10.0.0.21
novncproxy_base_url = http://controller:6080/vnc_auto.html

[glance]
api_servers = http://controller:9292

[oslo_concurrency]
lock_path = /var/lib/nova/tmp
    sudo systemctl restart libvirtd
sudo systemctl restart nova-compute

    컴퓨트 노드에서 중요한 건 my_ip와 메시지 브로커 연결입니다. 하이퍼바이저 지원도 꼭 확인하세요.

    egrep -c '(vmx|svm)' /proc/cpuinfo

    결과가 0이면 KVM 가속이 안 되는 환경일 수 있습니다. 홈랩 미니 PC나 중고 서버로 꾸밀 때 이 부분 꽤 자주 놓쳐요.

    5. 네트워크 노드 구성

    sudo apt update
sudo apt install -y neutron-linuxbridge-agent neutron-l3-agent neutron-dhcp-agent neutron-metadata-agent
    [DEFAULT]
transport_url = rabbit://openstack:strongpassword@controller
auth_strategy = keystone

[linux_bridge]
physical_interface_mappings = provider:ens224

[vxlan]
enable_vxlan = true
local_ip = 10.0.0.31
l2_population = true

[securitygroup]
enable_ipset = true
    sudo systemctl restart neutron-linuxbridge-agent
sudo systemctl restart neutron-l3-agent
sudo systemctl restart neutron-dhcp-agent
sudo systemctl restart neutron-metadata-agent

    네트워크 노드는 외부 NIC 이름을 정확히 넣어야 거든요. 예전엔 eth0, eth1이 익숙했는데 요즘은 ens160, ens224 같은 이름이 많아서 더 헷갈리죠. 근데 여기서 한 글자만 틀려도 Floating IP가 안 붙습니다.

    ⚠️ 실제로 자주 겪는 문제와 해결법

    • 문제 1: 컴퓨트 노드가 서비스 목록에 안 보임
      대부분 RabbitMQ 연결, Keystone 인증 정보, 혹은 nova-compute 설정 파일 오타입니다. 로그에서 인증 실패와 네임 리졸브를 먼저 보세요.
    • 문제 2: 인스턴스는 생성되는데 Ping이 안 됨
      네트워크 노드의 브리지 매핑, 보안 그룹(Security Group), 라우터 게이트웨이 설정을 점검해야 합니다. 저는 외부망 브리지 연결이 빠져서 한참 헤맸습니다.
    • 문제 3: Horizon은 열리는데 VM 생성이 실패함
      Horizon은 프런트엔드일 뿐이라서, 실제 문제는 Nova 스케줄러나 Glance 이미지 접근 실패인 경우가 많습니다.
    • 문제 4: Metadata 접근 실패
      cloud-init이 동작하지 않거나 SSH 키가 주입되지 않으면 metadata-agent와 관련 설정을 봐야 합니다.
    openstack compute service list
openstack network agent list
openstack hypervisor list
sudo journalctl -u nova-compute -n 100
sudo journalctl -u neutron-l3-agent -n 100

    OpenStack 멀티노드 배포에서는 “대시보드가 열리는지”보다 “서비스 간 상태가 일관적인지”를 봐야 합니다. 저는 이제 장애가 나면 무조건 API부터 보지 않고, 서비스 목록과 에이전트 상태를 같이 확인합니다.

    검증: 배포가 제대로 되었는지 확인하는 방법

    설치가 끝났다고 바로 성공은 아닙니다. 실제 검증은 테스트 인스턴스를 띄워서 네트워크까지 확인해야 끝납니다.

    1. Glance에 테스트 이미지를 등록합니다.
    2. 내부 네트워크와 서브넷을 만듭니다.
    3. 라우터를 생성하고 외부 네트워크와 연결합니다.
    4. 보안 그룹에서 ICMP와 SSH를 허용합니다.
    5. 소형 Flavor로 테스트 VM을 띄웁니다.
    openstack image list
openstack network list
openstack router list
openstack server create --flavor m1.small --image test-image --network private test-vm
openstack server list
    OpenStack 멀티노드 배포 결과와 인스턴스 생성 검증 이미지

    서비스 목록과 테스트 인스턴스 생성이 정상 완료된 상태를 보여주는 검증 이미지입니다.

    정상이라면 인스턴스가 ACTIVE 상태로 올라오고, Floating IP 연결 후 외부에서 SSH 접속까지 확인할 수 있어야 합니다. 드디어 됐다! 싶은 순간이 여기서 옵니다. 근데 솔직히 여기까지 한 번에 가는 경우는 드뭅니다. 로그 보면서 하나씩 푸는 게 결국 제일 빠르더라고요.

    노드 분리 전략, 어디까지 해야 할까

    실무나 홈랩이나 결국 자원과 목적의 타협입니다. 아래처럼 생각하면 편합니다.

    구성 방식 장점 단점 추천 상황
    All-in-One 빠른 학습, 최소 장비 역할 구분 어려움 기초 학습
    3노드 분리 구조 이해, 장애 분석 용이 네트워크 설정 복잡 OpenStack 아키텍처 학습
    확장형 멀티노드 수평 확장, 역할 세분화 운영 부담 증가 실전형 테스트베드
    OpenStack 멀티노드 배포와 단일 노드 구성을 비교한 인포그래픽

    단일 노드 구성과 3노드 멀티노드 구성을 한눈에 비교한 요약 이미지입니다.

    개인적으로는 처음부터 3노드로 가보는 걸 추천하는데요. 이유가 단순한데 OpenStack 멀티노드 배포를 한 번 해봐야 컨트롤러 노드, 컴퓨트 노드, 네트워크 노드가 왜 분리되는지 몸으로 이해되거든요. 다음 글에서는 스토리지 노드와 Cinder(신더, 블록 스토리지)까지 붙이는 흐름도 다뤄볼 생각이에요. 이전 글에서 가상화 기초를 다뤘다면 같이 보면 더 잘 이어질 겁니다.

    자주 묻는 질문 FAQ

    Q1. 네트워크 노드를 꼭 분리해야 하나요?

    학습 초반에는 꼭 그렇진 않습니다. 다만 Floating IP, 라우팅, NAT 흐름을 제대로 이해하려면 분리했을 때 훨씬 명확합니다.

    Q2. 컴퓨트 노드는 여러 대로 늘릴 수 있나요?

    네, 이게 OpenStack의 장점 중 하나입니다. 컨트롤러에 등록만 정상적으로 되면 컴퓨트 노드를 점진적으로 추가할 수 있습니다.

    Q3. 제일 먼저 확인할 로그는 뭔가요?

    저는 보통 Nova와 Neutron 에이전트 상태, 그리고 RabbitMQ 연결부터 봅니다. 서비스 간 연결이 안 되면 증상이 아주 다양하게 나타나거든요.

    마무리

    정리해보면, 컨트롤러 노드는 제어와 관리, 컴퓨트 노드는 실행, 네트워크 노드는 연결을 담당합니다. 이 세 역할만 머릿속에 깔끔하게 들어오면 OpenStack 아키텍처는 생각보다 훨씬 읽기 쉬워집니다. 저도 처음엔 서비스 이름만 많아서 겁부터 났는데, 결국 트래픽과 역할로 나눠서 보니 길이 보이더라고요. 혹시 지금 OpenStack 멀티노드 배포를 준비 중이시라면, 설치 명령보다 먼저 노드 역할을 도식화해보세요. 그 한 장의 메모가 삽질 시간을 꽤 줄여줍니다.

    컨트롤러, 컴퓨트, 네트워크 노드의 역할과 점검 포인트를 정리한 마무리 요약 이미지입니다.