OpenStack 수동 설치 8 — Cinder LVM + iSCSI 블록 스토리지 구성

Neutron으로 첫 인스턴스 부팅까지 확인했다면, 다음 단계는 인스턴스에 영구 디스크를 제공하는 Cinder(Block Storage) 다. 이 글은 Ubuntu 24.04 LTS + OpenStack 2026.1 (Gazpacho) 수동 설치 환경에서 Cinder controller 서비스와 LVM + iSCSI 백엔드를 구성하고, 볼륨 생성·attach·마운트까지 검증하는 흐름으로 갱신했다.

실습에서는 controller가 cinder-api와 cinder-scheduler를, 별도 storage 노드(또는 여유 디스크가 있는 controller)가 cinder-volume을 담당한다. 아래 RAID 5 구성과 기존 이미지는 LVM 백엔드 설계·운영 관점의 참고 예시로 그대로 유지한다.

노드별 역할과 설정 범위

🧭

아래 구성은 controller / Block Storage / Compute가 분리된 3-역할 배치를 기준으로 한다. 단일 노드 실습이라면 해당 노드에서 모든 역할의 설정을 합쳐 적용하되, 역할별 서비스와 설정 파일을 빠뜨리지 않는 것이 핵심이다.

노드 역할	실행 서비스	반드시 적용할 설정	주요 검증
Controller	`cinder-api`, `cinder-scheduler`, `nova-api`	Cinder DB·Keystone 서비스·`block-storage` endpoint, `/etc/cinder/cinder.conf`, Nova의 `[cinder]` 및 service token	`openstack endpoint list --service block-storage`
Block Storage	`cinder-volume`, `tgt`	RAID/LVM VG, `lvm.conf` filter, `/etc/cinder/cinder.conf` LVM backend, tgt include, TCP 3260	`vgs`, `systemctl status cinder-volume tgt`, `tgtadm --mode target --op show`
Compute (모든 노드)	`nova-compute`, `iscsid`	`open-iscsi`, `lvm.conf` filter, `/etc/nova/nova.conf`의 `[cinder]`·`[service_user]`, Cinder API 및 iSCSI 네트워크 연결	`iscsiadm -m session`, `openstack server add volume`

⚠️

역할을 나누었다면 같은 설정을 한 노드에만 넣으면 안 된다. 특히 cinder.conf의 LVM backend는 Block Storage 노드에, open-iscsi와 Nova의 Cinder 연동 설정은 모든 Compute 노드에 적용한다.

수동 설치에 추가되는 controller 구성

먼저 controller에서 Cinder DB, 서비스 사용자, API endpoint를 준비한다. 2026.1 기준으로는 block-storage 서비스 엔터티 하나와 /v3 endpoint를 사용한다. 예전 예제의 volumev3 서비스 타입이나 /v3/%(project_id)s endpoint 형식은 사용하지 않는다.

CREATE DATABASE cinder;
CREATE USER 'cinder'@'localhost' IDENTIFIED BY 'CINDER_DBPASS';
GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'localhost';
CREATE USER 'cinder'@'%' IDENTIFIED BY 'CINDER_DBPASS';
GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'%';
FLUSH PRIVILEGES;

source ~/admin-openrc

openstack user create --domain default --password-prompt cinder
openstack role add --project service --user cinder admin

# Xena 이후 Cinder는 block-storage 서비스 엔터티 하나를 사용한다.
openstack service create --name cinder \
  --description "OpenStack Block Storage" block-storage
openstack endpoint create --region RegionOne \
  block-storage public http://controller:8776/v3
openstack endpoint create --region RegionOne \
  block-storage internal http://controller:8776/v3
openstack endpoint create --region RegionOne \
  block-storage admin http://controller:8776/v3

sudo apt install -y cinder-api cinder-scheduler

/etc/cinder/cinder.conf에는 DB, RabbitMQ, Keystone 인증과 management IP를 설정한다.

[database]
connection = mysql+pymysql://cinder:CINDER_DBPASS@controller/cinder

[DEFAULT]
my_ip = 192.168.56.101
transport_url = rabbit://openstack:RABBIT_PASS@controller
auth_strategy = keystone

[keystone_authtoken]
www_authenticate_uri = http://controller:5000
auth_url = http://controller:5000
memcached_servers = controller:11211
auth_type = password
project_domain_name = default
user_domain_name = default
project_name = service
username = cinder
password = CINDER_PASS

# Nova가 전달하는 service token을 반드시 검증한다.
service_token_roles = service
service_token_roles_required = true

[service_user]
# Cinder가 다른 OpenStack 서비스에 요청할 때 service token을 함께 보낸다.
send_service_user_token = true
project_domain_name = default
project_name = service
user_domain_name = default
username = cinder
password = CINDER_PASS
auth_url = http://controller:5000
auth_type = password

[oslo_concurrency]
lock_path = /var/lib/cinder/tmp

🔐

Service Token은 선택 사항이 아니다. 2023-05-10 이후 릴리스에서는 CVE-2023-2088 대응을 위해 Nova가 Cinder에 service token을 보내고, Cinder가 이를 검증하도록 구성해야 한다. 실제 운영 환경에서는 CINDER_PASS, NOVA_PASS를 별도 Secret 관리 체계로 보관한다.

관리자 권한으로 service role의 존재와 할당을 확인한다. role이 없다면 먼저 생성한다.

openstack role show service
# 위 명령이 실패할 때만 실행
openstack role create service

openstack role add --user cinder --project service service
openstack role add --user nova --project service service
openstack role assignment list --user cinder --project service --names
openstack role assignment list --user nova --project service --names

Nova도 Cinder를 사용할 region과 service token 발급 정보를 가져야 한다. /etc/nova/nova.conf에서 nova-api가 실행되는 controller와 nova-compute가 실행되는 모든 Compute 노드에 아래 항목을 적용한다. 기존 섹션이 있다면 섹션을 중복하지 말고 항목만 병합한다.

[cinder]
os_region_name = RegionOne

[service_user]
send_service_user_token = true
project_domain_name = default
project_name = service
user_domain_name = default
username = nova
password = NOVA_PASS
auth_url = http://controller:5000
auth_type = password

📌

[cinder]은 Nova가 Cinder endpoint의 region을 선택하게 하고, [service_user]는 Nova가 Cinder API 호출에 service token을 함께 보내게 한다. Compute 노드 하나라도 이 설정이 빠지면 해당 노드에서의 volume attach가 인증 오류로 실패할 수 있다.

sudo su -s /bin/sh -c "cinder-manage db sync" cinder
sudo systemctl restart nova-api cinder-scheduler apache2

source ~/admin-openrc
openstack endpoint list --service block-storage

이후 storage 노드에 cinder-volume, lvm2, thin-provisioning-tools, tgt를 설치하고, Compute 노드에는 open-iscsi initiator를 준비한다. 아래 LVM·iSCSI 백엔드 설정을 적용한 뒤, openstack volume create → 인스턴스 attach → 게스트 OS에서 파일시스템 생성·마운트까지 검증한다.

📌

이 글에서 다루는 내용

하드웨어 RAID 5 구성 및 확인

LVM Physical Volume / Volume Group 생성

/etc/lvm/lvm.conf 필터 설정 (중요!)

/etc/cinder/cinder.conf LVM 백엔드 설정

iSCSI 타겟 데몬(tgt) 구성

Kolla Ansible 환경에서의 설정 방법

동작 확인 및 트러블슈팅

🤔 왜 LVM + iSCSI인가?

Cinder의 스토리지 백엔드로는 Ceph RBD, NFS, 상용 SAN 등 다양한 옵션이 있다. 그런데 LVM + iSCSI는 Cinder의 레퍼런스 드라이버로, 추가적인 외부 스토리지 시스템 없이 로컬 디스크만으로 블록 스토리지를 제공할 수 있다는 장점이 있다.

💡

LVM + iSCSI 구조 한눈에 보기

LVM: 물리 디스크를 논리 볼륨으로 관리. Cinder가 볼륨을 생성하면 LVM에서 Logical Volume을 하나 만든다

iSCSI: 네트워크를 통해 블록 디바이스를 공유하는 프로토콜. Compute 노드의 VM이 Storage 노드의 LV에 접근할 수 있게 해준다

tgt(iSCSI Target): Storage 노드에서 LV를 iSCSI 타겟으로 노출시키는 데몬

┌─────────────────────┐         iSCSI          ┌──────────────────────────┐
│    Compute Node     │◀══════════════════════▶│     Storage Node         │
│                     │    (TCP/IP Network)    │                          │
│  ┌───────────────┐  │                        │  ┌────────────────────┐  │
│  │  VM Instance  │  │                        │  │  tgt (iSCSI target)│  │
│  │   /dev/vdb    │  │                        │  │         │          │  │
│  └───────────────┘  │                        │  │         ▼          │  │
│                     │                        │  │  ┌──────────────┐  │  │
│  iSCSI Initiator    │                        │  │  │  LVM (LV)    │  │  │
│  (open-iscsi)       │                        │  │  │  cinder-vol  │  │  │
│                     │                        │  │  └──────┬───────┘  │  │
└─────────────────────┘                        │  │         │          │  │
                                               │  │         ▼          │  │
                                               │  │  ┌──────────────┐  │  │
                                               │  │  │  /dev/md126  │  │  │
                                               │  │  │  (RAID 5)    │  │  │
                                               │  │  └──────────────┘  │  │
                                               │  └────────────────────┘  │
                                               └──────────────────────────┘

⚠️

LVM 백엔드의 한계

LVM 백엔드는 단일 스토리지 노드에 의존하기 때문에 Single Point of Failure가 된다. 고가용성이 필요한 프로덕션 환경에서는 Ceph RBD 같은 분산 스토리지를 권장한다. 하지만 소규모 환경이나 테스트, 연구용으로는 충분히 괜찮은 선택이다.

🔧 1단계: 하드웨어 RAID 구성

cinder에서 사용할 디스크를 우선 구성해야 한다. 연구실에 남는 디스크 2TB × 4개를 구했으므로, RAID 5로 구성하여 약 6TB의 볼륨을 사용할 생각이다.

📝

RAID 레벨 선택 기준

RAID 0: 속도 최우선, 안정성 없음. ~~디스크 하나 죽으면 전부 날아간다~~

RAID 1: 미러링. 안정성 좋지만 용량 50%만 사용 가능

RAID 5: 패리티 1개. 디스크 1개 장애까지 허용. 용량 대비 안정성 밸런스가 좋다

RAID 6: 패리티 2개. 디스크 2개 장애까지 허용. 쓰기 성능이 좀 떨어짐

4개의 디스크에 RAID 5를 적용하면 (4-1) × 2TB = 약 6TB 사용 가능

메인보드에서 하드웨어 RAID 5를 구성하고 서버를 부팅한 뒤, lsblk로 디스크 상태를 확인한다.

lsblk

디스크 4개(sda, sdb, sdc, sdd)가 RAID 5로 잘 구성되었으며, md126이라는 이름으로 묶여있다.

RAID 상태 확인

RAID 어레이의 상태를 좀 더 자세히 확인하려면 mdadm을 사용한다.

sudo mdadm --detail /dev/md126

💡

mdadm 출력에서 확인해야 할 포인트

State: active 또는 clean이면 정상

Active Devices / Working Devices: 구성한 디스크 수와 일치하는지 확인

Failed Devices: 0이어야 한다. 1 이상이면 디스크 교체가 필요

Rebuild Status: 리빌드 중이라면 완료될 때까지 기다린 후 다음 작업을 진행하자

🔧 2단계: LVM 구성

디스크가 정상적으로 RAID 구성된 것을 확인했으니, 이제 LVM으로 Cinder에서 사용할 볼륨 그룹을 만들어야 한다.

필수 패키지 설치

LVM 도구가 설치되어 있지 않다면 먼저 설치한다.

sudo apt install lvm2 thin-provisioning-tools

📝

thin-provisioning-tools란?

Cinder의 LVM 드라이버는 Thin Provisioning을 지원한다. Thin Provisioning은 실제로 데이터를 쓸 때만 디스크 공간을 할당하는 방식이다. 예를 들어 100GB 볼륨을 만들어도 실제로 10GB만 사용 중이면 10GB만 차지한다. 이 도구가 있어야 thin provisioning 기능을 활용할 수 있다.

Physical Volume 및 Volume Group 생성

# Physical Volume 생성
sudo pvcreate /dev/md126

# Volume Group 생성 (cinder-volumes라는 이름으로)
sudo vgcreate cinder-volumes /dev/md126

⚠️

Volume Group 이름이 중요하다!

여기서 설정한 Volume Group 이름(cinder-volumes)은 나중에 cinder.conf의 [lvm] 섹션에서 정확히 동일하게 지정해야 한다. 이름이 다르면 Cinder가 볼륨을 생성할 수 없다.

생성 확인

# Physical Volume 확인
sudo pvs

# Volume Group 확인
sudo vgs

# 상세 정보 확인
sudo vgdisplay cinder-volumes

vgs 출력에서 cinder-volumes VG가 보이고, VSize가 약 6TB로 표시되면 성공이다.

🔒 3단계: lvm.conf 필터 설정

이 단계가 은근히 중요한데 자주 빠뜨리는 부분이다. LVM은 기본적으로 /dev 디렉토리의 모든 블록 디바이스를 스캔한다. 문제는 Cinder가 생성한 LV를 Compute 노드에서 iSCSI로 연결했을 때, Compute 노드의 LVM도 해당 볼륨을 감지해서 캐싱하려고 시도한다는 것이다. 이렇게 되면 OS와 VM 볼륨 사이에 충돌이 발생할 수 있다.

⚠️

필터 미설정 시 발생할 수 있는 문제

Compute 노드의 LVM이 VM 볼륨을 스캔하여 메타데이터 충돌 발생

볼륨 생성/삭제 시 예상치 못한 오류

최악의 경우 OS 디스크의 LVM 메타데이터가 손상될 수 있다 😭

Storage 노드 필터 설정

/etc/lvm/lvm.conf 파일을 편집한다.

sudo vi /etc/lvm/lvm.conf

devices 섹션에서 filter 항목을 찾아 다음과 같이 설정한다.

devices {
    ...
    filter = [ "a/md126/", "r/.*/" ]
}

📝

필터 문법 해설

a: Accept - 해당 디바이스를 LVM 스캔에 포함

r: Reject - 해당 디바이스를 LVM 스캔에서 제외

a/md126/: RAID 어레이 디바이스를 허용

r/.*/: 나머지 모든 디바이스를 거부

배열의 마지막은 반드시 r/.*/로 끝나야 한다

만약 OS 디스크도 LVM을 사용하고 있다면(예: /dev/sda), OS 디스크도 필터에 추가해야 한다.

# OS 디스크가 /dev/sda인 경우
filter = [ "a/sda/", "a/md126/", "r/.*/" ]

Compute 노드 필터 설정

Compute 노드에서도 /etc/lvm/lvm.conf의 필터를 설정해야 한다. Compute 노드에서는 OS 디스크만 허용하고 나머지는 전부 거부한다.

# Compute 노드의 /etc/lvm/lvm.conf
filter = [ "a/sda/", "r/.*/" ]

필터 테스트

설정 후 vgs 명령으로 필터가 제대로 동작하는지 확인한다.

# -vvvv 옵션으로 상세 로그 확인
sudo vgs -vvvv 2>&1 | grep "filter"

⚙️ 4단계: cinder.conf 설정

이제 Cinder의 설정 파일에서 LVM 백엔드를 구성한다.

수동 설치 환경

/etc/cinder/cinder.conf를 편집한다. storage 노드도 DB, RabbitMQ, Keystone 인증을 모두 설정해야 하며, backend 이름·volume type·extra spec의 값은 하나로 맞춰야 한다.

[database]
connection = mysql+pymysql://cinder:CINDER_DBPASS@controller/cinder

[DEFAULT]
# Storage 노드의 Management IP
my_ip = 172.30.0.11

# 활성화할 백엔드 이름 (아래 섹션명과 일치해야 함)
enabled_backends = lvm

# type 미지정 볼륨이 사용할 기본 type
# 사전에 `openstack volume type create lvm`을 실행해야 한다.
default_volume_type = lvm

# Glance API 주소
glance_api_servers = http://controller:9292

# RabbitMQ 설정
transport_url = rabbit://openstack:RABBIT_PASS@controller

# 인증 방식
auth_strategy = keystone

[lvm]
# LVM 볼륨 드라이버
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver

# 볼륨 그룹 이름 (위에서 만든 VG 이름과 동일해야 함!)
volume_group = cinder-volumes

# volume type의 volume_backend_name과 동일해야 한다.
volume_backend_name = lvm

# iSCSI 프로토콜 사용
target_protocol = iscsi

# iSCSI 타겟 헬퍼 (tgt 사용)
target_helper = tgtadm

# iSCSI 타겟이 리슨할 IP (Storage 네트워크 IP)
target_ip_address = 172.30.0.11

[keystone_authtoken]
www_authenticate_uri = http://controller:5000
auth_url = http://controller:5000
memcached_servers = controller:11211
auth_type = password
project_domain_name = default
user_domain_name = default
project_name = service
username = cinder
password = CINDER_PASS
service_token_roles = service
service_token_roles_required = true

[service_user]
send_service_user_token = true
project_domain_name = default
project_name = service
user_domain_name = default
username = cinder
password = CINDER_PASS
auth_url = http://controller:5000
auth_type = password

[oslo_concurrency]
lock_path = /var/lib/cinder/tmp

📝

설정 항목 상세 해설

volume_driver: LVM 볼륨 드라이버 클래스 경로. 이건 고정값이다

volume_group: vgcreate로 만든 볼륨 그룹 이름. 대소문자 구분하니 주의

target_protocol: iscsi 또는 iser(RDMA 기반). 일반적으로 iscsi를 사용한다

target_helper: iSCSI 타겟 관리 도구. Ubuntu에서는 tgtadm, RHEL/CentOS에서는 lioadm을 사용

target_ip_address: Compute 노드가 iSCSI로 접근할 IP. 별도 스토리지 네트워크가 있다면 해당 네트워크 IP를 사용하는 것이 좋다

⚠️

enabled_backends 네이밍 주의

enabled_backends에 지정한 이름이 곧 설정 섹션의 이름이 된다. 예를 들어 enabled_backends = lvm이면 [lvm] 섹션을 읽는다. enabled_backends = my-storage로 했다면 [my-storage] 섹션을 만들어야 한다. 이름은 자유지만 일관성이 중요하다.

Kolla Ansible 환경

Kolla Ansible을 사용하고 있다면 설정 방법이 조금 다르다. /etc/kolla/config/cinder/cinder-volume.conf 파일을 생성하여 커스텀 설정을 추가한다.

# /etc/kolla/config/cinder/cinder-volume.conf

[DEFAULT]
enabled_backends = lvm

[lvm]
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
volume_group = cinder-volumes
target_protocol = iscsi
target_helper = tgtadm
target_ip_address = 172.30.0.11
volume_backend_name = lvm

⚠️

Kolla Ansible + LVM 주의사항

Kolla Ansible은 기본적으로 서비스를 컨테이너로 배포한다. 하지만 iSCSI 기반 LVM 드라이버는 컨테이너 환경과 호환성 문제가 있을 수 있다. LXC/Docker의 제한으로 인해 iSCSI 타겟 관리가 정상 동작하지 않는 경우, cinder-volume 서비스를 호스트에 직접 배포하는 방식을 고려해야 한다.

🌐 5단계: iSCSI 타겟 데몬 설정

Cinder가 생성한 LV를 네트워크를 통해 Compute 노드에 노출하려면 iSCSI 타겟 데몬이 필요하다. Ubuntu에서는 tgt를 사용한다.

패키지 설치

공식 설치 절차 기준으로 Storage 노드에는 Cinder volume service와 target daemon을 함께 설치한다.

# Storage 노드에서
sudo apt install -y cinder-volume tgt

# Compute 노드에서 (iSCSI Initiator)
sudo apt install -y open-iscsi

tgt include 설정 및 서비스 시작

tgtadm helper를 사용할 때는 Cinder가 생성하는 target 정의를 tgt가 읽도록 include 파일을 만든다. 이 파일이 빠지면 volume 생성은 되어도 attach 단계에서 iSCSI target을 찾지 못할 수 있다.

# Storage 노드에서
sudo install -d -m 0755 /etc/tgt/conf.d
printf 'include /var/lib/cinder/volumes/*\n' | \
  sudo tee /etc/tgt/conf.d/cinder.conf

sudo systemctl enable --now tgt

# 상태와 include 파일 확인
sudo systemctl status tgt --no-pager
sudo cat /etc/tgt/conf.d/cinder.conf

💡

iSCSI 구성 요소 정리

Target (타겟): 스토리지를 제공하는 쪽. Storage 노드에서 tgt 데몬이 담당

Initiator (이니시에이터): 스토리지를 사용하는 쪽. Compute 노드에서 open-iscsi가 담당

IQN (iSCSI Qualified Name): 각 타겟/이니시에이터의 고유 식별자. 예: iqn.2010-10.org.openstack:volume-xxxxx

LUN (Logical Unit Number): 타겟이 노출하는 논리 디스크 번호

Cinder가 볼륨을 생성하면, 자동으로 tgt에 타겟을 등록하고 LV를 LUN으로 매핑한다. 수동으로 tgt 설정을 건드릴 필요는 없다. ~~이건 참 편하다~~

Compute 노드의 Initiator 및 Nova 연동 설정

이 절차는 모든 Compute 노드에서 각각 수행한다. iSCSI initiator IQN은 노드별로 고유해야 하며, VM이 실행되는 Compute 노드가 Block Storage 노드의 target에 접속한다.

# Initiator 이름 확인: 각 Compute 노드에서 서로 다른 IQN인지 확인
cat /etc/iscsi/initiatorname.iscsi

# iSCSI initiator daemon 시작 및 부팅 시 자동 시작
sudo systemctl enable --now iscsid
sudo systemctl status iscsid --no-pager

Compute 노드의 /etc/nova/nova.conf에도 controller에서 설명한 [cinder], [service_user] 섹션이 있어야 한다. 누락 여부는 다음처럼 확인한다.

sudo grep -A 12 '^\[cinder\]\|^\[service_user\]' /etc/nova/nova.conf

# nova-compute가 변경된 Cinder 연동 설정을 읽도록 재시작
sudo systemctl restart nova-compute
sudo systemctl status nova-compute --no-pager

마지막으로 각 Compute 노드에서 controller의 Cinder API(TCP 8776)와 Block Storage의 iSCSI target(TCP 3260)에 도달할 수 있어야 한다. 방화벽을 사용하는 경우 두 통신 경로를 허용한다.

# 이름 해석·API 도달성 확인
getent hosts controller
curl -sS http://controller:8776/ | head

# attach 후 iSCSI session 확인
sudo iscsiadm -m session

🚀 6단계: 서비스 시작 및 동작 확인

모든 설정이 완료되었으면 서비스를 재시작한다.

서비스 재시작

# Storage 노드에서
sudo service tgt restart
sudo service cinder-volume restart

서비스 상태 확인

# Cinder 볼륨 서비스 목록 확인
openstack volume service list

출력에서 Storage 노드의 cinder-volume 서비스가 enabled / up 상태인지 확인한다.

+------------------+-------------------------------+------+---------+-------+---
| Binary           | Host                          | Zone | Status  | State | ...
+------------------+-------------------------------+------+---------+-------+---
| cinder-scheduler | controller                    | nova | enabled | up    | ...
| cinder-volume    | storage-node@lvm              | nova | enabled | up    | ...
+------------------+-------------------------------+------+---------+-------+---

볼륨 타입 생성 및 기본 타입 지정

Train 이후에는 모든 볼륨이 volume type을 가져야 한다. 따라서 LVM backend에 연결할 type을 만들고, default_volume_type = lvm과 같은 이름으로 맞춘다. type을 지정하지 않은 생성 요청도 안전하게 LVM backend로 가도록 하는 설정이다.

# 볼륨 타입 생성
openstack volume type create lvm

# backend 매핑: [lvm]의 volume_backend_name과 정확히 일치해야 한다.
openstack volume type set lvm --property volume_backend_name=lvm

# Cinder가 인식하는 기본 type 확인
openstack volume type list --default

테스트 볼륨 생성

# 1GB 테스트 볼륨 생성
openstack volume create --size 1 --type lvm test-volume

# 상태 확인
openstack volume show test-volume

status가 available이면 성공이다! 🎉

Storage 노드에서 LV 확인

# LV 목록 확인
sudo lvs

# 예상 출력
#   LV                                   VG              Attr       LSize
#   volume-xxxxxxxx-xxxx-xxxx-xxxx-xxxx  cinder-volumes  -wi-a-----  1.00g

볼륨 ID에 해당하는 LV가 생성된 것을 확인할 수 있다. Cinder가 cinder-volumes VG에서 Logical Volume을 잘 만들어낸 것이다.

OpenStack Cinder Volume Creation and Attach Flow

iSCSI 타겟 확인

# tgt에 등록된 타겟 확인
sudo tgtadm --mode target --op show

Cinder가 볼륨을 인스턴스에 attach하면, tgt에 해당 볼륨의 iSCSI 타겟이 자동으로 등록된다.

🔍 트러블슈팅

볼륨 생성이 `error` 상태로 떨어질 때

# cinder-volume 로그 확인
sudo tail -f /var/log/cinder/cinder-volume.log

# Kolla Ansible 환경에서는
docker logs cinder_volume

📝

자주 만나는 에러와 해결법

VG cinder-volumes not found: Volume Group 이름이 cinder.conf와 불일치. vgs로 실제 이름 확인 후 수정

Failed to create iscsi target: tgt 서비스가 동작하지 않거나 권한 문제. systemctl status tgt 확인

No valid host was found: 스케줄러가 적절한 백엔드를 찾지 못함. volume_backend_name이 볼륨 타입의 extra-spec과 일치하는지 확인

tgtadm: command not found: tgt 패키지가 설치되지 않음. apt install tgt

Compute 노드에서 볼륨 attach가 안 될 때

# Compute 노드에서 iSCSI 연결 확인
sudo iscsiadm -m session

# Storage 노드 검색
sudo iscsiadm -m discovery -t sendtargets -p 172.30.0.11

네트워크 연결 문제인 경우가 많다. Storage 노드와 Compute 노드 간 3260 포트(iSCSI 기본 포트)가 열려 있는지 방화벽을 확인하자.

핵심 정리

✅ RAID 구성: 물리 디스크를 RAID로 묶어 안정성과 용량 확보. mdadm --detail로 상태 확인

✅ LVM 구성: pvcreate → vgcreate cinder-volumes로 Cinder 전용 볼륨 그룹 생성

✅ lvm.conf 필터: Storage/Compute 노드 모두 설정 필수. 미설정 시 볼륨 충돌 위험

✅ cinder.conf: [lvm] 섹션에서 드라이버, VG 이름, iSCSI 프로토콜 지정

✅ iSCSI 타겟: Storage 노드에 tgt, Compute 노드에 open-iscsi 설치

✅ 동작 확인: openstack volume create로 테스트 볼륨 생성 후 lvs로 LV 확인

주의사항

⚠️ Single Point of Failure: LVM 백엔드는 단일 노드 의존. 프로덕션에서는 Ceph RBD 등 분산 스토리지를 고려하자

⚠️ lvm.conf 필터 필수: Compute 노드에서도 반드시 설정해야 한다. 안 하면 나중에 고생한다

⚠️ VG 이름 일관성: vgcreate와 cinder.conf의 volume_group 값이 정확히 일치해야 한다

⚠️ iSCSI 포트: 방화벽에서 TCP 3260 포트가 열려 있어야 Compute ↔ Storage 간 통신이 가능하다

⚠️ 디스크 모니터링: RAID 상태를 주기적으로 확인하자. mdadm --detail /dev/md126으로 Failed Devices가 0인지 체크

⚠️ Thin Provisioning 주의: 활성화 시 실제 디스크 사용량을 모니터링해야 한다. 오버커밋하면 디스크 풀 나서 전체 장애로 이어질 수 있다

참고 자료

OpenStack Cinder Installation Guide — 2026.1

Cinder LVM Driver 공식 문서

Rackspace Cinder LVM iSCSI Operator Guide

LVM 공식 문서