Kolla Ansible로 OpenStack Trove 설치하기

Trove는 OpenStack에서 Database as a Service를 제공하는 서비스다. 사용자는 VM을 직접 만들고 DB 패키지를 설치하지 않아도, OpenStack API를 통해 MySQL 같은 데이터베이스 인스턴스를 생성할 수 있다.

다만 Trove를 실제로 배포하려면 trove-taskmanager와 Trove 인스턴스가 서로 통신할 수 있는 management network가 필요하다. 기본적으로는 RabbitMQ와 통신 가능한 management network에 Trove DB 인스턴스를 직접 연결하는 구성이 가장 단순하다. 이번 글에서는 Kolla Ansible 환경에서 Trove용 management VLAN을 구성하고, 우리 환경의 특수성 때문에 db-mgmt-net을 gateway router에 연결한 뒤 trove.conf에 반영하고 재배포하는 과정을 다룬다.

📌

이 글에서 다루는 내용

Trove management network가 필요한 이유

Netplan으로 Trove용 VLAN interface 추가

Neutron provider network와 subnet 생성

우리 환경에서만 필요한 db-mgmt-net gateway router 연결

trove.conf에 management network, keypair, security group 반영

Kolla Ansible 재배포 후 확인할 포인트

🤔 Trove management network가 왜 필요한가?

Trove는 사용자가 요청한 데이터베이스 인스턴스를 Nova VM 형태로 생성한다. 이때 trove-taskmanager는 생성된 DB 인스턴스와 통신하면서 초기화, 상태 확인, 설정 적용 같은 작업을 수행해야 한다.

즉, 컨트롤러 쪽의 Trove 서비스와 실제 DB 인스턴스가 management network를 통해 접근 가능해야 한다. 또한 DB 인스턴스 내부의 guest agent는 RabbitMQ와 통신해야 하므로, 일반적인 구성에서는 RabbitMQ와 통신 가능한 management network에 DB 인스턴스를 바로 붙이는 방식이 기본에 가깝다.

💡

왜 별도 management network를 쓰는가?

Trove 인스턴스는 일반 tenant network에만 붙어 있으면 trove-taskmanager와 RabbitMQ에 안정적으로 접근하기 어렵다. 그래서 Octavia의 health manager network처럼, 서비스 제어용 네트워크를 별도로 구성해 두는 방식이 깔끔하다.

⚠️

우리 환경에서만 달라지는 부분

기본 구성이라면 Trove management network를 RabbitMQ와 통신 가능한 management network에 직접 연결하면 된다. 하지만 이번 환경에서는 기존 management network를 provider network 용도로도 사용하고 있어서, Trove용 db-mgmt-net을 별도로 만들고 gw-router를 통해 management network 쪽으로 라우팅되도록 구성한다.

이번 구성에서는 이전에 Octavia를 설정할 때 사용했던 방식과 비슷하게 VLAN network를 직접 붙이기로 했다.

OpenStack Octavia로 Kolla Ansible을 이용한 로드밸런서 설정 가이드

OpenStack에서 LBaaS를 제공하는 Octavia를 Kolla Ansible 환경에 설정하는 방법을 안내하며, VLAN 310을 이용한 관리 네트워크(o‑hm0.310) 구성, netplan을 통한 VLAN 인터페이스 설정, globals.yml의 주요 Octavia 옵션(활성화, 자동 구성, 인증서, Amphora 플래버, 보안 그룹, 포트, provider 네트워크 및 서브넷 등) 및 배포 절차와 확인 체크리스트를 설명한다.

/octavia-kolla-ansible

🧱 전체 구성 흐름

구성 흐름은 크게 6단계다.

Netplan에 Trove용 VLAN interface t-tm0.311 추가

OpenStack Neutron에 db-mgmt-net provider network 생성

같은 대역으로 subnet 생성

우리 환경에서는 db-mgmt-subnet을 gw-router에 연결

trove.conf에 management network 관련 값 반영

Kolla Ansible로 Trove 서비스 재배포

📝

이번 예제의 네트워크 값

VLAN ID: 311

Trove management subnet: 172.33.0.0/16

Host VLAN interface: t-tm0.311

Neutron network: db-mgmt-net

Neutron subnet: db-mgmt-subnet

Gateway router: gw-router (우리 환경에서 필요)

Subnet gateway 예시: 172.33.0.1 (우리 환경 기준)

🔧 Netplan에 Trove용 VLAN 추가

먼저 host network에 Trove management VLAN을 추가한다.

기존에는 Octavia용으로 o-hm0.310을 사용하고 있었고, 이번에는 Trove taskmanager용으로 t-tm0.311을 추가했다. 여기서는 내부적으로 trove-taskmanager0 역할을 하는 interface라고 보면 된다.

# /etc/netplan/00-config.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:
    # Octavia health manager network
    o-hm0.310:
      id: 310
      link: enp10s0
      addresses:
        - 172.32.0.1/16

    # Trove taskmanager management network
    t-tm0.311:
      id: 311
      link: enp10s0
      addresses:
        - 172.33.0.2/16

적용 전에는 반드시 netplan try로 먼저 확인하는 편이 좋다.

# 설정 검증 및 임시 적용
sudo netplan try

# 문제가 없으면 실제 적용
sudo netplan apply

⚠️

네트워크 설정은 항상 조심하자

Netplan 설정을 잘못 적용하면 서버 접속이 끊길 수 있다. 특히 원격 서버에서 작업 중이라면 netplan apply보다 netplan try를 먼저 사용하는 습관을 들이자. ~~서버실에 직접 가서 복구하면 눈물이 난다 😭~~

🌐 Neutron provider network 생성

Host 쪽에 VLAN interface를 준비했다면, 이제 OpenStack 내부에도 같은 VLAN ID를 사용하는 provider network를 생성해야 한다.

여기서는 VLAN ID 311을 사용하고, physical network는 br-tenant로 지정했다.

# Trove management network 생성
openstack network create db-mgmt-net \
  --provider-network-type vlan \
  --provider-physical-network br-tenant \
  --provider-segment 311 \
  --project service

이 네트워크는 Trove service project에서 사용할 management network다.

🤔

왜 provider segment를 311로 맞추는가?

Host의 t-tm0.311도 VLAN ID 311을 사용하고, Neutron provider network도 segment 311을 사용해야 같은 L2 network로 이어진다. 둘 중 하나라도 다르면 trove-taskmanager와 DB 인스턴스가 서로 다른 네트워크에 있는 셈이 된다.

🧩 Management subnet 생성

다음으로 같은 IP 대역을 사용하는 subnet을 생성한다.

# Trove management subnet 생성
openstack subnet create db-mgmt-subnet \
  --network db-mgmt-net \
  --subnet-range 172.33.0.0/16 \
  --dhcp \
  --project service \
  --gateway 172.33.0.1

여기서 중요한 부분은 gateway를 제거하지 않는 것이다. Trove DB 인스턴스의 guest agent가 RabbitMQ와 통신하려면 RabbitMQ가 있는 management network 방향으로 나갈 수 있는 기본 gateway가 필요하다.

기본 구성이라면 이 subnet을 RabbitMQ와 통신 가능한 management network에 직접 붙이는 식으로 구성할 수 있다. 하지만 우리 환경에서는 management network를 provider network 용도로도 사용하고 있어서, Trove 전용 subnet에서 RabbitMQ가 있는 management network로 나가는 경로를 router로 만들어야 한다.

💡

gateway를 두는 이유

이 설정은 Trove의 일반 기본값이라기보다 우리 환경의 네트워크 구조 때문에 필요한 조치다. db-mgmt-net을 isolated network처럼 두면 guest agent가 RabbitMQ에 접근하지 못할 수 있으므로, gw-router를 통해 management network 쪽으로 라우팅되도록 구성한다.

gateway IP는 router interface가 사용할 주소와 충돌하지 않게 잡아야 한다. 위 예시에서는 172.33.0.1을 gateway로 사용하므로, host의 t-tm0.311 주소는 172.33.0.2/16처럼 다른 주소를 사용한다.

우리 환경: gw-router에 subnet 연결

db-mgmt-subnet을 생성한 뒤에는 gateway router에 연결한다. 이 단계는 management network를 별도로 라우팅해야 하는 우리 환경 기준이다.

# db-mgmt-net subnet을 gateway router에 연결
openstack router add subnet gw-router db-mgmt-subnet

# RabbitMQ가 있는 management/provider subnet도 같은 router에 연결
# 환경에 맞는 subnet 이름 또는 ID로 변경
openstack router add subnet gw-router <MGMT_SUBNET_NAME_OR_ID>

이미 gw-router가 존재하고 management/provider subnet이 연결되어 있다면, db-mgmt-subnet만 추가하면 된다.

생성 후에는 network와 subnet이 제대로 만들어졌는지 확인한다.

# 네트워크 확인
openstack network show db-mgmt-net

# 서브넷 확인
openstack subnet show db-mgmt-subnet

# router 연결 확인
openstack router show gw-router
openstack port list --router gw-router

⚙️ Trove 설정 파일 반영

이제 생성한 management network를 Trove 설정에 반영한다.

trove.conf의 [DEFAULT] 섹션에 다음 값을 추가한다.

[DEFAULT]
# Trove DB 인스턴스가 붙을 management network ID
management_networks = 7b6cd969-e559-4ca0-ab85-e5d46f3d0857

# Trove 인스턴스 접속에 사용할 Nova keypair
nova_keypair = trove-mgmt-key

# Trove management network에서 사용할 security group
management_security_groups = 58975f61-cf89-4152-a6fa-f627e15f5097

# 기본 볼륨 제한 확장
max_accepted_volume_size = 1000
max_volumes_per_tenant = 2000
max_instances_per_tenant = 50
max_backups_per_tenant = 50

📚

설정값 의미

management_networks: Trove가 DB 인스턴스를 붙일 management network ID

nova_keypair: Trove 인스턴스에 주입할 keypair

management_security_groups: management 통신에 사용할 security group

max_accepted_volume_size: 인스턴스 생성 시 허용할 최대 volume size

max_volumes_per_tenant: tenant별 최대 volume 수

기본 DB volume size 제한은 테스트용으로는 괜찮지만, 실제로 사용하기에는 너무 작았다. 기본 5GB 수준으로는 간단한 확인 말고는 할 수 있는 게 거의 없다. 그래서 테스트 환경에서는 1TB 이상, 프로젝트당 2TB까지 사용할 수 있도록 제한을 조정했다. ~~DB는 항상 생각보다 빨리 커진다~~

설정 옵션은 아래 공식 문서를 참고하면 된다.

Trove Configuration Options — trove 25.0.1.dev 5 documentation

🚀 Kolla Ansible 재배포

설정을 반영했다면 Kolla Ansible로 Trove 서비스를 다시 배포한다.

환경에 따라 전체 deploy를 다시 돌릴 수도 있고, Trove 관련 서비스만 reconfigure할 수도 있다.

# 전체 재배포 예시
kolla-ansible deploy -i ./multinode

# 또는 설정 반영 중심의 재구성
kolla-ansible reconfigure -i ./multinode --tags trove

배포가 완료되면 Trove 관련 container 상태를 확인한다.

# Trove container 상태 확인
docker ps | grep trove

# Trove taskmanager 로그 확인
docker logs -f trove_taskmanager

⚠️

배포 전 체크리스트

t-tm0.311 interface가 host에 정상 생성되었는가?

172.33.0.2/16 주소가 host에 올라왔는가?

Neutron provider network의 segment ID가 311인가?

우리 환경처럼 별도 라우팅이 필요하다면 db-mgmt-subnet이 gw-router에 연결되었는가?

DB 인스턴스 subnet에서 RabbitMQ가 있는 management network로 통신 가능한가?

Trove 설정의 management_networks 값이 실제 network ID와 일치하는가?

security group에서 필요한 management traffic이 허용되어 있는가?

✅ 동작 확인

재배포 후에는 실제 Trove database instance를 생성해서 확인한다.

# Trove datastore 목록 확인
openstack datastore version list

# Trove database instance 생성 예시
openstack database instance create test-mysql \
  --flavor <FLAVOR_ID> \
  --size 10 \
  --datastore mysql \
  --datastore-version <VERSION_NAME> \
  --nic net-id=<TENANT_NET_ID>

생성 후에는 인스턴스 상태를 확인한다.

# DB 인스턴스 목록 확인
openstack database instance list

# 특정 인스턴스 상세 확인
openstack database instance show test-mysql

정상이라면 인스턴스 상태가 BUILD에서 ACTIVE로 변경된다.

만약 ERROR 상태로 떨어진다면 가장 먼저 trove-taskmanager 로그를 확인하자.

# Trove taskmanager 로그 확인
docker logs -f trove_taskmanager

# Conductor 로그 확인
docker logs -f trove_conductor

# API 로그 확인
docker logs -f trove_api

🔍

문제가 생겼을 때 우선 확인할 후보

management network ID 오타: trove.conf의 management_networks 값이 실제 Neutron network ID와 다른 경우

VLAN segment 불일치: host는 311, Neutron은 다른 segment를 사용하는 경우

gateway/router 누락: 우리 환경처럼 별도 subnet에서 RabbitMQ가 있는 management network로 라우팅해야 하는데 db-mgmt-subnet이 gw-router에 연결되지 않은 경우

security group 누락: taskmanager, RabbitMQ, DB 인스턴스 간 통신이 막힌 경우

keypair 누락: nova_keypair에 지정한 keypair가 존재하지 않는 경우

datastore image 설정 문제: Trove guest image 또는 datastore version 설정이 잘못된 경우

핵심 정리

✅ Trove: OpenStack에서 Database as a Service를 제공하는 서비스다. DB 인스턴스 생성과 관리를 자동화할 수 있다.

✅ Management network: trove-taskmanager와 Trove DB 인스턴스가 통신하기 위한 제어용 네트워크다.

✅ VLAN ID 일치: Host의 t-tm0.311과 Neutron provider network의 segment 311이 일치해야 한다.

✅ Gateway router 연결: 일반 기본 구성이라기보다, 우리 환경처럼 management network를 provider network 용도로 함께 쓰는 경우 db-mgmt-net subnet을 gw-router에 연결해야 한다.

✅ Kolla Ansible 재배포: trove.conf를 수정한 뒤에는 deploy 또는 reconfigure로 설정을 실제 container에 반영해야 한다.

주의사항

⚠️ Netplan 적용 순서: 원격 서버에서는 netplan apply 전에 netplan try를 먼저 사용하자. 잘못된 설정은 서버 접속 불가로 이어질 수 있다.

⚠️ Network ID 확인: management_networks에는 network 이름이 아니라 실제 network ID를 넣어야 한다.

⚠️ Security group 확인: security group이 막혀 있으면 DB 인스턴스는 생성되어도 taskmanager가 접근하지 못할 수 있다.

⚠️ Gateway IP 충돌 주의: subnet gateway로 172.33.0.1을 사용한다면 host VLAN interface에는 같은 IP를 쓰지 말고 172.33.0.2처럼 다른 주소를 사용하자.

⚠️ RabbitMQ 통신 확인: DB 인스턴스 guest agent가 RabbitMQ endpoint에 접근하지 못하면 인스턴스가 ACTIVE로 올라오지 못하거나 상태 갱신이 멈출 수 있다.

⚠️ VLAN trunk 확인: 물리 switch 또는 host NIC 쪽에서 VLAN 311이 통과하지 않으면 OpenStack 설정이 맞아도 통신이 되지 않는다.

⚠️ Resource limit 조정: 기본 volume 제한은 운영 목적에 부족할 수 있다. 다만 너무 크게 열어두면 tenant별 quota 관리가 어려워질 수 있다.

참고 자료

OpenStack Trove Configuration Options

OpenStack Trove Documentation

Kolla Ansible Documentation

OpenStack Neutron Provider Networks