---
title: "Kolla Ansible로 OpenStack Trove 설치하기"
description: "Kolla Ansible 환경에서 Trove를 배포하기 위해 관리용 VLAN 311과 전용 네트워크·서브넷을 설정하고, 해당 정보를 trove.conf에 반영한 뒤 재배포하여 DB 인스턴스가 정상적으로 동작하도록 하는 과정이다."
date: "2026-05-07"
last_modified: "2026-08-15T19:40:00.000Z"
type: "Post"
tags:
  - "openstack"
  - "kolla ansible"
  - "network"
categories:
  - "📗 Docs"
series:
  - "오픈스택 운영"
canonical_url: "https://blog.pieroot.xyz/kolla-ansible-trove"
markdown_url: "https://blog.pieroot.xyz/kolla-ansible-trove.md"
---

# Kolla Ansible로 OpenStack Trove 설치하기

Kolla Ansible 환경에서 Trove를 배포하기 위해 관리용 VLAN 311과 전용 네트워크·서브넷을 설정하고, 해당 정보를 trove.conf에 반영한 뒤 재배포하여 DB 인스턴스가 정상적으로 동작하도록 하는 과정이다.

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을 이용한 로드밸런서 설정 가이드](https://app.notion.com/p/30c067c015d080958339f77a1517ace2) 

![Trove management network 구성도](https://blog.pieroot.xyz/api/image-proxy?id=54cc7e23-97fb-4c49-9829-56232eaa5099&kind=s3&pageId=359067c0-15d0-80e8-8fe4-ef6fd66ca7c4&source=block&blockId=b02a5266-bbf0-4233-a1d0-5fc0ff98d2c8)

---

### 🧱 전체 구성 흐름

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

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

1. OpenStack Neutron에 `db-mgmt-net` provider network 생성

1. 같은 대역으로 subnet 생성

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

1. `trove.conf`에 management network 관련 값 반영

1. Kolla Ansible로 Trove 서비스 재배포

![Kolla Ansible 기반 Trove 배포 흐름](https://blog.pieroot.xyz/api/image-proxy?id=b0f94170-affe-4560-b742-de5ed961a4ee&kind=s3&pageId=359067c0-15d0-80e8-8fe4-ef6fd66ca7c4&source=block&blockId=c070a61b-2336-472b-9b75-d56b3adfb5ee)

> **이번 예제의 네트워크 값**
> 
> - 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라고 보면 된다.

```yaml
# /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`로 먼저 확인하는 편이 좋다.

```bash
# 설정 검증 및 임시 적용
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`로 지정했다.

```bash
# 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을 생성한다.

```bash
# 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를 별도로 라우팅해야 하는 우리 환경 기준이다.

```bash
# 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이 제대로 만들어졌는지 확인한다.

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

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

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

![image](https://blog.pieroot.xyz/api/image-proxy?id=d6b8ecd2-7393-4446-bc58-d706815ce8b1&kind=s3&pageId=359067c0-15d0-80e8-8fe4-ef6fd66ca7c4&source=block&blockId=359067c0-15d0-8038-a266-f209e2790481)

![image](https://blog.pieroot.xyz/api/image-proxy?id=2d8609dd-d62d-4b26-8d9f-dc4f1b83d39f&kind=s3&pageId=359067c0-15d0-80e8-8fe4-ef6fd66ca7c4&source=block&blockId=359067c0-15d0-80f9-b9ce-f5048400a306)

---

### ⚙️ Trove 설정 파일 반영

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

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

```toml
[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 ](https://docs.openstack.org/trove/2026.1/reference/conf.html)[25.0.1.dev](http://25.0.1.dev/)[5 documentation](https://docs.openstack.org/trove/2026.1/reference/conf.html)

---

### 🚀 Kolla Ansible 재배포

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

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

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

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

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

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

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

![image](https://blog.pieroot.xyz/api/image-proxy?id=ee8e2e45-eae5-4e86-90b1-6efb76c1e100&kind=s3&pageId=359067c0-15d0-80e8-8fe4-ef6fd66ca7c4&source=block&blockId=359067c0-15d0-801b-a7d5-c0fbb902b794)

> **배포 전 체크리스트**
> 
> - `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를 생성해서 확인한다.

```bash
# 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>
```

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

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

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

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

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

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

# Conductor 로그 확인
docker logs -f trove_conductor

# API 로그 확인
docker logs -f trove_api
```

> **문제가 생겼을 때 우선 확인할 후보**
> 
> 1. **management network ID 오타**: `trove.conf`의 `management_networks` 값이 실제 Neutron network ID와 다른 경우
> 
> 1. **VLAN segment 불일치**: host는 `311`, Neutron은 다른 segment를 사용하는 경우
> 
> 1. **gateway/router 누락**: 우리 환경처럼 별도 subnet에서 RabbitMQ가 있는 management network로 라우팅해야 하는데 `db-mgmt-subnet`이 `gw-router`에 연결되지 않은 경우
> 
> 1. **security group 누락**: taskmanager, RabbitMQ, DB 인스턴스 간 통신이 막힌 경우
> 
> 1. **keypair 누락**: `nova_keypair`에 지정한 keypair가 존재하지 않는 경우
> 
> 1. **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](https://docs.openstack.org/trove/2026.1/reference/conf.html)

- [OpenStack Trove Documentation](https://docs.openstack.org/trove/latest/)

- [Kolla Ansible Documentation](https://docs.openstack.org/kolla-ansible/latest/)

- [OpenStack Neutron Provider Networks](https://docs.openstack.org/neutron/latest/admin/config-provider-networks.html)