DCloud Infra 구축하기 -1-

인프라 설계를 마치고 아키텍처까지 완성했으니 이제는 실제로 서버에 OpenStack을 설치해야 하는 단계입니다.

하지만 OpenStack은 Proxmox처럼 그냥 클릭 몇 번으로 설치되는 종류의 프로그램이 아니에요.
OpenStack은 여러 서비스가 유기적으로 연결되어 있고, 네트워크 설정도 꽤 복잡합니다.
컨트롤러, 컴퓨트, 스토리지, 네트워크 서비스… 각 노드와 서비스가 서로를 바라보고 제대로 동작해야 하죠.

그래서 보통은 혼자보다는 팀에서 같이 머리를 맞대고 설치합니다.
여러 명이 역할을 나눠서 설정을 확인하고, 네트워크와 서비스 연동 문제를 해결하며 설치를 진행하는 것이 일반적입니다.

하지만 학교 환경은 조금 달랐습니다

학교에는 인프라에 관심 있는 사람이 거의 없어서 함께할 팀이 부족했어요.
혼자 빠르게 설치하고 테스트하려면 기존 방식대로 하나하나 서비스 설치하고 네트워크 구성하는 건 거의 불가능합니다.

그래서 선택한 것이 바로 Kolla-Ansible입니다.

Kolla-Ansible이란?

OpenStack 설치해 본 사람은 알겠지만, 직접 설치하고 설정하는 건 생각보다 엄청 복잡합니다.
그래서 나온 게 Kolla-Ansible이에요. 한마디로:

“OpenStack을 도커 컨테이너로 띄워서, 관리와 배포를 훨씬 편하게 해주는 도구”

컨테이너로 서비스가 나뉘어 있어서 충돌 걱정도 적고, Ansible 스크립트로 여러 노드를 한 번에 쭉 배포할 수 있어요.
업데이트나 롤백 같은 것도 컨테이너 단위로 하니까 훨씬 수월합니다.

AI가 생성한 이미지입니다.

Kolla-Ansible로 설치를 하고 네트워크와 어떤 서비스가 들어가있는지 이미지로 만들어 보았습니다.

노드별 서비스

1️Controller Node – skyline_controller (192.10.1.39)

컨트롤러 노드는 OpenStack의 두뇌 역할을 담당합니다.
여기서 전체 서버를 지휘하고, 서비스가 제대로 돌아가도록 관리합니다.

  • Control Services
    MariaDB, RabbitMQ, Keystone, Glance, Nova API/Cond/Sched, Neutron Server, Cinder API/Sched, Horizon, Heat, Placement
    • 커스텀 프로그램: openstack-Dashboard, Skyline-apiserver-Extension
  • Interface 연결
    • ens4f0.100 → MGMT
    • ens4f0.200 → TUNNEL

컨트롤러 노드가 서버 전체를 조율하기 때문에, 나머지 노드들은 컨트롤러의 지휘 아래 안정적으로 작동합니다.


2️Network + Compute + Storage Node – nova_compute6 (192.10.1.36)

이 노드는 특수하게 네트워크, 컴퓨트, 스토리지 서비스를 동시에 담당합니다.
말 그대로 “멀티 플레이어” 역할이죠.

  • Network Services
    Neutron L3 / DHCP / Metadata Agent
  • Compute & Storage Services
    Nova Compute, OVS Agent, Cinder Volume
  • Interface 연결
    • eno1.100 → MGMT
    • eno1.200 → TUNNEL
    • eno2 → EXTERNAL

참고로, nova_compute6 노드는 랜 포트가 4개 있고 IPMI를 지원해서, 외부 연결은 EXTERNAL 포트를 통해 설정했습니다.
이렇게 특수 노드 하나가 네트워크와 컴퓨트, 스토리지를 담당하면, 전체 인프라를 관리하기가 훨씬 쉽습니다.


3️ Standard Compute + Storage Nodes – COMP1, COMP2, COMP3

나머지 일반 노드들은 Compute와 Storage 전용입니다.

  • Compute & Storage Services
    Nova Compute, OVS Agent, Cinder Volume
  • Interface 연결
    각 노드마다 MGMT & TUNNEL
  • 스토리지 설계 포인트
    Standard Compute에는 HDD에 VM 데이터를 저장하지만, 여러 사용자가 동시에 접근하면 랙이 걸릴 수 있습니다.
    그래서 각 HDD에 NVMe 캐시 드라이브를 넣어 읽기/쓰기 속도를 올렸습니다.

왜 이렇게 구성했을까?

저는 서버 성능에 따라 역할을 나눠서 밸런스를 유지하려고 했습니다.

  • 강력한 CPU와 RAM → Compute 노드
  • 성능이 낮은 서버 → 다른 기능

하지만 이렇게만 하면 서비스가 여기저기 흩어지기 때문에, 추후 유지보수나 장애 대응이 어렵습니다.
그래서 결국 이렇게 구성했습니다.

  1. 컨트롤러 노드가 서버 전체를 지휘
  2. 특수 노드 하나가 네트워크 + 컴퓨트 + 스토리지 담당
  3. 일반 노드는 Compute + Storage 전용

이 구조 덕분에 관리, 확장, 장애 대응 모두 수월해졌습니다.

다음 글에서는 제가 만든 Skyline하고 Opentack-Dashboard에 대해서 알아보겟습니다.