13년차의 서버실

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

[태그:] Neutron

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

  • [클라우드] 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 멀티노드 배포를 준비 중이시라면, 설치 명령보다 먼저 노드 역할을 도식화해보세요. 그 한 장의 메모가 삽질 시간을 꽤 줄여줍니다.

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