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

목차

• 왜 OpenStack 멀티노드 배포에서 역할 분리가 중요한가
• OpenStack 아키텍처를 쉽게 풀어보면
• 노드별 역할 분석: 어디까지 맡기는 게 현실적인가
• 컨트롤러 노드
• 컴퓨트 노드
• 네트워크 노드
• 실전 구현: OpenStack 멀티노드 배포 기본 순서
• 1. 기본 통신과 이름 해석 준비
• 2. 컨트롤러 노드에 공통 서비스 준비
• 3. Keystone, Glance, Nova API, Neutron Server 등록
• 4. 컴퓨트 노드 연결
• 5. 네트워크 노드 구성
• ⚠️ 실제로 자주 겪는 문제와 해결법
• 검증: 배포가 제대로 되었는지 확인하는 방법
• 노드 분리 전략, 어디까지 해야 할까
• 자주 묻는 질문 FAQ
• Q1. 네트워크 노드를 꼭 분리해야 하나요?
• Q2. 컴퓨트 노드는 여러 대로 늘릴 수 있나요?
• Q3. 제일 먼저 확인할 로그는 뭔가요?
• 마무리

[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 서비스들이 서로 대화하는 중심축이 됩니다.

컨트롤러 노드에 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

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

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

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

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

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

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

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

자주 묻는 질문 FAQ

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

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

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

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

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

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

마무리

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

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

📚 함께 읽으면 좋은 글

• OpenStack Trove 도입 전 필수 체크리스트: 데이터베이스 서비스 최적화
• OpenStack Octavia 성능 벤치마크: 실제 환경 부하 테스트 분석
• OpenStack Horizon 커스터마이징 완벽 가이드: 기업 환경 UI/UX 최적화 사례