--- title: "OpenStack Octavia로 Kolla Ansible을 이용한 로드밸런서 설정 가이드" description: "OpenStack에서 LBaaS를 제공하는 Octavia를 Kolla Ansible 환경에 설정하는 방법을 안내하며, VLAN 310을 이용한 관리 네트워크(o‑hm0.310) 구성, netplan을 통한 VLAN 인터페이스 설정, globals.yml의 주요 Octavia 옵션(활성화, 자동 구성, 인증서, Amphora 플래버, 보안 그룹, 포트, provider 네트워크 및 서브넷 등) 및 배포 절차와 확인 체크리스트를 설명한다." date: "2026-02-20" last_modified: "2026-08-06T00:36:00.000Z" type: "Post" tags: - "openstack" - "kolla ansible" - "load balancing" categories: - "📗 Docs" series: - "오픈스택 운영" canonical_url: "https://blog.pieroot.xyz/octavia-kolla-ansible" markdown_url: "https://blog.pieroot.xyz/octavia-kolla-ansible.md" --- # OpenStack Octavia로 Kolla Ansible을 이용한 로드밸런서 설정 가이드 OpenStack에서 LBaaS를 제공하는 Octavia를 Kolla Ansible 환경에 설정하는 방법을 안내하며, VLAN 310을 이용한 관리 네트워크(o‑hm0.310) 구성, netplan을 통한 VLAN 인터페이스 설정, globals.yml의 주요 Octavia 옵션(활성화, 자동 구성, 인증서, Amphora 플래버, 보안 그룹, 포트, provider 네트워크 및 서브넷 등) 및 배포 절차와 확인 체크리스트를 설명한다. OpenStack에서 로드밸런서를 사용하려면 **Octavia**라는 서비스가 필요하다. Octavia는 **LBaaS(Load Balancer as a Service)**를 제공하는 OpenStack 프로젝트로, Amphora라는 전용 VM을 생성하여 그 안에서 HAProxy를 돌리는 구조다. 이번 글에서는 Kolla Ansible 환경에서 Octavia를 설정하는 과정을 다룬다. 특히 **Health Manager 통신을 위한 VLAN 인터페이스 구성**과 `globals.yml` 설정을 중심으로 정리했다. > **이 글에서 다루는 내용** > > - Octavia란 무엇인가, 왜 필요한가 > > - netplan으로 VLAN 인터페이스(`o-hm0.310`) 생성 > > - Health Manager와 Management Network의 관계 > > - Kolla Ansible `globals.yml` 주요 설정 항목 해설 > > - Amphora 보안 그룹, 인증서, 네트워크 설정 --- ### 🤔 Octavia란? Octavia는 OpenStack의 **로드밸런싱 서비스**다. 사용자가 로드밸런서를 요청하면, Octavia는 **Amphora**라는 경량 VM을 Nova를 통해 생성하고, 그 안에 HAProxy를 설치하여 트래픽을 분산시킨다. > **Octavia의 핵심 구성 요소** > > - **Amphora**: 실제 로드밸런싱을 수행하는 VM. HAProxy가 돌아간다 > > - **Health Manager**: Amphora의 상태를 모니터링하는 컴포넌트 > > - **Worker**: 로드밸런서 생성/삭제 등 실제 작업을 수행 > > - **Housekeeping**: Amphora 인증서 갱신, 미사용 리소스 정리 등 유지보수 담당 > > - **Management Network**: 컨트롤 플레인과 Amphora 간의 전용 통신 네트워크 여기서 중요한 건 **Management Network**다. Octavia의 컨트롤러(Health Manager, Worker 등)가 Amphora VM과 통신하려면, **전용 네트워크**가 반드시 필요하다. 이 네트워크가 없으면 Health Manager가 Amphora의 상태를 확인할 수 없고, 설정 변경도 불가능하다. --- ### 🌐 네트워크 아키텍처 이해 Octavia의 네트워크 구조를 간단히 그려보면 이렇다: ```javascript ┌─────────────────────────────────────────────────┐ │ Controller Node │ │ │ │ ┌──────────────┐ ┌──────────────────────┐ │ │ │ Health Mgr │────▶│ o-hm0.310 (VLAN 310) │ │ │ │ Worker │ │ 172.32.0.1/16 │ │ │ │ Housekeeping │ └──────────┬───────────┘ │ │ └──────────────┘ │ │ └──────────────────────────────────┼───────────────┘ │ VLAN 310 ┌──────────────┴───────────────┐ │ lb-mgmt-net (172.32.0.0/16) │ │ Management Network │ └──────────────┬───────────────┘ │ ┌──────────────┴───────────────┐ │ Amphora VM │ │ (HAProxy inside) │ │ 172.32.x.x │ └──────────────────────────────┘ ``` ![OpenStack Octavia Architecture Diagram](https://blog.pieroot.xyz/api/image-proxy?id=94379e32-a5ec-4b29-a891-1e3f694e25f7&kind=s3&pageId=30c067c0-15d0-8095-8339-f77a1517ace2&source=block&blockId=85482731-e49b-4ed5-9833-b483edfe9e11) > **핵심 포인트** > > Octavia Health Manager와 Amphora VM이 **실제로 통신 가능한 네트워크**에 있어야 한다. 단순히 Neutron에서 네트워크를 만드는 것만으로는 부족하고, **컨트롤러 노드에 해당 VLAN에 접근할 수 있는 물리 인터페이스**가 존재해야 한다. 이게 바로 `o-hm0.310`을 만드는 이유다. Health Manager는 UDP 포트 5555를 통해 Amphora로부터 heartbeat를 수신한다. 이 통신이 되지 않으면 Amphora가 정상이어도 `ERROR` 상태로 표시되거나, failover가 트리거될 수 있다. ~~이거 때문에 삽질한 사람이 한둘이 아니다~~ --- ### 🔧 netplan으로 VLAN 인터페이스 생성 [OpenStack 네트워크 최적화: unattended-upgrades 문제 해결과 netplan으로의 전환](https://app.notion.com/p/305067c015d0807cb74afe3f4505ad58) 이전 글에서 netplan으로 bridge와 veth를 구성하는 방법을 다뤘었다. 이번에는 여기에 **VLAN 인터페이스**를 추가한다. Octavia Management Network로 VLAN 310을 사용할 것이기 때문에, 컨트롤러 노드에서 해당 VLAN에 접근할 수 있는 인터페이스가 필요하다. ![VLAN 310 Network Tagging Concept](https://blog.pieroot.xyz/api/image-proxy?id=45c07021-cf5f-43bc-a834-7edd72dbb31f&kind=s3&pageId=30c067c0-15d0-8095-8339-f77a1517ace2&source=block&blockId=14335025-af23-4adb-957e-c04d45f2a1a3) #### netplan YAML 구성 ```yaml network: version: 2 ethernets: eno1: dhcp4: false eno2: dhcp4: false enp2s0: mtu: 9000 dhcp4: false enp10s0: dhcp4: false bridges: mybr0: interfaces: - enp2s0 - veth0 mtu: 9000 addresses: - "172.30.0.11/16" nameservers: addresses: - 8.8.8.8 search: [] routes: - to: "default" via: "172.30.0.1" virtual-ethernets: veth0: peer: veth1 veth1: peer: veth0 vlans: o-hm0.310: id: 310 link: enp10s0 addresses: - 172.32.0.1/16 ``` */etc/netplan/50-cloud-init.yaml* 기존 netplan 구성에서 **vlans** 섹션만 추가한 것이다. 핵심만 뽑아보면: ```yaml vlans: o-hm0.310: id: 310 link: enp10s0 addresses: - 172.32.0.1/16 ``` > **VLAN 인터페이스 설정 해설** > > - `o-hm0.310`: 인터페이스 이름. Octavia Health Manager용임을 알 수 있게 네이밍했다 > > - `id: 310`: VLAN 태그 번호. Neutron에서 생성할 provider network의 segmentation ID와 **반드시 일치**해야 한다 > > - `link: enp10s0`: VLAN 트래픽이 흐를 물리 인터페이스. tenant 네트워크용 NIC를 지정한다 > > - `addresses: 172.32.0.1/16`: 이 인터페이스의 IP. Management Network의 서브넷 내에 있어야 한다 > **왜 ****`enp10s0`****에 연결하는가?** > > Octavia Management Network는 Neutron의 **provider network**로 생성된다. 이 provider network가 실제로 사용하는 물리 네트워크가 `enp10s0`(tenant용 NIC)이기 때문에, VLAN 인터페이스도 같은 물리 NIC에 연결해야 한다. 물리적으로 같은 네트워크에 있어야 VLAN 태그가 일치하는 트래픽끼리 통신이 가능하다. #### 적용 ```bash # 문법 확인 (원격 작업 시 필수!) sudo netplan try # 문제 없으면 적용 sudo netplan apply # VLAN 인터페이스 확인 ip addr show o-hm0.310 ``` 정상적으로 적용되면 `o-hm0.310` 인터페이스가 생성되고, `172.32.0.1/16` IP가 할당된 것을 확인할 수 있다. ![image](https://blog.pieroot.xyz/api/image-proxy?id=52e9055d-8290-4b71-a639-34ab3eee0104&kind=s3&pageId=30c067c0-15d0-8095-8339-f77a1517ace2&source=block&blockId=30c067c0-15d0-805a-a44b-d631de6d07da) --- ### ⚙️ Kolla Ansible globals.yml 설정 이제 본격적으로 Kolla Ansible의 `globals.yml`에서 Octavia 관련 설정을 진행한다. 하나씩 살펴보자. #### Octavia 활성화 ```yaml enable_octavia: "yes" ``` 당연히 이걸 켜야 Octavia가 배포된다. ~~안 켜면 아무 일도 일어나지 않는다~~ #### 자동 구성 ```yaml octavia_auto_configure: yes ``` Kolla Ansible이 Octavia에 필요한 리소스(네트워크, 보안 그룹, flavor 등)를 **자동으로 생성**해주는 옵션이다. > **Ussuri에서 업그레이드한 경우 주의!** > > Ussuri 릴리즈에서 업그레이드하는 경우, 반드시 `octavia_auto_configure: no`로 설정하고 기존 설정을 유지해야 한다. 자동 구성이 기존 리소스와 충돌할 수 있다. #### 인증서 설정 ```yaml octavia_certs_country: KR octavia_certs_state: Seoul octavia_certs_organization: DMSLAB octavia_certs_organizational_unit: Openstack ``` Octavia는 컨트롤러와 Amphora 간의 통신을 **TLS로 암호화**한다. 이를 위해 자체 CA(Certificate Authority)를 생성하는데, 여기에 들어갈 인증서 정보를 설정하는 부분이다. 내부용이므로 적당히 채워주면 된다. #### Amphora Flavor ```yaml octavia_amp_flavor: name: "amphora" is_public: no vcpus: 1 ram: 1024 disk: 5 swap: 0 ephemeral: 0 ``` Amphora VM이 생성될 때 사용할 Nova flavor를 정의한다. > **Amphora Flavor 설정 팁** > > - `is_public: no`: 일반 사용자에게 이 flavor가 노출되지 않도록 한다. Amphora 전용이므로 숨기는 게 맞다 > > - `vcpus: 1, ram: 1024, disk: 5`: 기본 로드밸런싱에는 충분한 스펙이다. 트래픽이 많다면 스펙을 올리자 > > - 대규모 환경에서는 `extra_specs`에 `hw:mem_page_size: "large"`를 추가하여 hugepage를 활용할 수 있다 #### 보안 그룹 ```yaml octavia_amp_security_groups: mgmt-sec-grp: enabled: true name: "lb-mgmt-sec-grp" rules: - protocol: icmp - protocol: tcp src_port: 22 dst_port: 22 - protocol: tcp src_port: 9443 dst_port: 9443 health-mgr-sec-grp: name: "lb-health-mgr-sec-grp" enabled: true rules: - protocol: udp src_port: 5555 dst_port: 5555 ``` Amphora VM에 적용될 보안 그룹이다. 두 개의 그룹을 정의한다: > **보안 그룹 규칙 해설** > > - **lb-mgmt-sec-grp** (Amphora 관리용) > - `ICMP`: ping으로 Amphora 상태 확인 > - `TCP 22`: SSH 접근 (디버깅용) > - `TCP 9443`: Amphora Agent 통신 포트. Worker가 이 포트로 로드밸런서 설정을 전달한다 > > - **lb-health-mgr-sec-grp** (Health Manager용) > - `UDP 5555`: Health Manager가 Amphora로부터 heartbeat를 수신하는 포트 #### 통신 포트 ```yaml octavia_amp_listen_port: "9443" octavia_health_manager_port: "5555" ``` - `9443`: Amphora Agent가 리슨하는 포트. 컨트롤러가 이 포트를 통해 Amphora에 설정을 전달한다 - `5555`: Health Manager가 heartbeat를 수신하는 UDP 포트 #### Management Network 설정 이 부분이 가장 중요하다. Octavia Management Network를 어떻게 구성할지 정의한다. ```yaml octavia_amp_network: name: lb-mgmt-net shared: false external: false provider_network_type: "vlan" provider_segmentation_id: 310 provider_physical_network: "tenant" mtu: 1450 subnet: name: lb-mgmt-subnet cidr: "172.32.0.0/16" allocation_pool_start: 172.32.10.1 allocation_pool_end: 172.32.250.254 no_gateway_ip: yes enable_dhcp: yes ``` > **네트워크 설정 상세 해설** > > - `provider_network_type: "vlan"`: VLAN 기반 provider network로 생성 > > - `provider_segmentation_id: 310`: **netplan에서 설정한 VLAN ID와 반드시 동일**해야 한다. 이게 다르면 통신 불가 > > - `provider_physical_network: "tenant"`: Neutron의 physical network 매핑 이름. `ml2_conf.ini`의 설정과 일치해야 한다 > > - `mtu: 1450`: VLAN 오버헤드를 고려한 MTU 값 > > - `shared: false`: 다른 프로젝트에 공유하지 않는다. Octavia 전용 네트워크 > > - `external: false`: 외부 네트워크가 아닌 내부 관리용 네트워크 > **서브넷 설정 포인트** > > - `cidr: "172.32.0.0/16"`: Management Network의 대역. 충분히 넓게 잡았다 > > - `allocation_pool_start/end`: DHCP로 할당될 IP 범위. `172.32.0.1`(컨트롤러)과 겹치지 않도록 `172.32.10.1`부터 시작 > > - `no_gateway_ip: yes`: 이 네트워크는 외부로 나갈 필요가 없으므로 게이트웨이 없음 > > - `enable_dhcp: yes`: Amphora VM이 부팅될 때 자동으로 IP를 할당받도록 DHCP 활성화 #### 네트워크 CIDR 및 인터페이스 ```yaml octavia_amp_network_cidr: 172.32.0.0/16 octavia_network_type: "provider" octavia_network_interface: "o-hm0.310" ``` - `octavia_network_type: "provider"`: provider network를 사용한다는 선언. 프로덕션 환경에서는 반드시 `provider`를 사용해야 한다 - `octavia_network_interface: "o-hm0.310"`: 앞서 netplan으로 만든 VLAN 인터페이스를 지정한다. **이 인터페이스를 통해 Health Manager가 Amphora와 통신**한다 > **`tenant`**** vs ****`provider`**** 네트워크 타입** > > - `tenant`: Kolla Ansible이 자동으로 VXLAN 기반 테넌트 네트워크를 생성한다. **개발/테스트 환경에서만 사용**하자. 네트워크 안정성이 프로덕션 수준이 아니다 > > - `provider`: VLAN 기반 provider network를 사용한다. 물리 네트워크와 직접 연결되므로 **안정적이고 프로덕션에 적합**하다. 대신 VLAN 인터페이스를 수동으로 구성해야 한다 #### Amphora 이미지 및 토폴로지 ```yaml octavia_amp_image_tag: "amphora" octavia_loadbalancer_topology: "SINGLE" ``` - `octavia_amp_image_tag: "amphora"`: Amphora VM 이미지의 태그. Kolla Ansible이 이 태그로 Glance에서 이미지를 찾는다 - `octavia_loadbalancer_topology: "SINGLE"`: 로드밸런서 토폴로지 설정 > **로드밸런서 토폴로지 옵션** > > - `SINGLE`: Amphora VM 하나로 로드밸런싱. 간단하고 리소스 절약. 소규모 환경에 적합 > > - `ACTIVE_STANDBY`: 두 개의 Amphora VM이 Active-Standby 구성으로 동작. 하나가 죽으면 나머지가 자동으로 인수한다. **고가용성이 필요한 프로덕션 환경**에서 권장 --- ### 🚀 배포 설정이 완료되었으면 배포를 진행한다. Octavia는 별도의 인증서 생성 과정이 필요하다. ```bash # Octavia 인증서 생성 kolla-ansible octavia-certificates # 전체 배포 (또는 Octavia만 배포) kolla-ansible reconfigure -i multinode # Octavia만 따로 배포할 경우 kolla-ansible reconfigure -i multinode --tags octavia ``` > **배포 전 체크리스트** > > - \[ \] `enable_neutron_provider_networks: yes`가 `globals.yml`에 설정되어 있는지 확인 > > - \[ \] netplan으로 `o-hm0.310` 인터페이스가 생성되어 있는지 확인 (`ip addr show o-hm0.310`) > > - \[ \] VLAN ID(310)가 netplan과 `globals.yml`에서 일치하는지 확인 > > - \[ \] Management Network CIDR과 인터페이스 IP가 같은 서브넷에 있는지 확인 > > - \[ \] Amphora 이미지가 Glance에 업로드되어 있는지 확인 배포가 완료되면 Octavia 관련 컨테이너들이 정상적으로 동작하는지 확인한다. ```bash # Octavia 컨테이너 상태 확인 docker ps | grep octavia # 예상 결과: # octavia_api # octavia_health_manager # octavia_housekeeping # octavia_worker ``` --- ### ✅ 동작 확인 로드밸런서를 생성하여 Octavia가 정상 동작하는지 테스트한다. ```bash # 로드밸런서 생성 openstack loadbalancer create --name test-lb --vip-subnet-id # 상태 확인 (ACTIVE가 되면 성공) openstack loadbalancer show test-lb # Amphora 확인 openstack loadbalancer amphora list ``` > **로드밸런서 상태 확인 포인트** > > - `provisioning_status`가 `ACTIVE`면 정상 > > - `operating_status`가 `ONLINE`이면 Health Manager 통신도 정상 > > - 만약 `ERROR`나 `PENDING_CREATE`에서 멈춘다면 로그를 확인하자: `docker logs octavia_worker` --- ### 핵심 정리 ✅ **Octavia**: OpenStack의 LBaaS 서비스. Amphora VM 위에 HAProxy를 돌려서 로드밸런싱 ✅ **Management Network**: 컨트롤러와 Amphora 간 전용 통신 네트워크. VLAN provider network로 구성 ✅ **o-hm0.310**: netplan으로 생성한 VLAN 인터페이스. Health Manager가 이 인터페이스를 통해 Amphora와 통신 ✅ **VLAN ID 일치 필수**: netplan의 VLAN ID와 `globals.yml`의 `provider_segmentation_id`가 반드시 동일해야 한다 ✅ **provider 네트워크 타입**: 프로덕션에서는 반드시 `provider`를 사용. `tenant`는 개발/테스트용 ✅ **보안 그룹**: TCP 9443(Amphora Agent)과 UDP 5555(Health Manager)가 핵심 포트 ### 주의사항 ⚠️ **VLAN ID 불일치**: netplan과 Neutron의 VLAN ID가 다르면 통신이 안 된다. 반드시 확인하자 ⚠️ **물리 인터페이스 매핑**: VLAN 인터페이스의 `link`가 tenant 네트워크용 물리 NIC와 일치해야 한다 ⚠️ **IP 충돌 주의**: `o-hm0.310`의 IP(`172.32.0.1`)가 DHCP allocation pool 범위와 겹치지 않도록 설정 ⚠️ **인증서 만료**: Octavia 인증서는 기본 1년이다. `kolla-ansible octavia-certificates --check-expiry 30`으로 주기적으로 확인하자 ⚠️ **Amphora 이미지**: Amphora 이미지가 Glance에 없으면 로드밸런서 생성이 실패한다. 이미지 빌드 및 업로드를 잊지 말자 ### 참고 자료 - [Kolla Ansible Octavia 공식 문서](https://docs.openstack.org/kolla-ansible/latest/reference/networking/octavia.html) - [Octavia 공식 문서](https://docs.openstack.org/octavia/latest/) - [Netplan YAML Configuration](https://netplan.readthedocs.io/en/stable/netplan-yaml/) - [Octavia Configuration Reference](https://docs.openstack.org/octavia/latest/configuration/configref.html)