OpenStack Ceph 마이그레이션 결정 기준과 절차

OpenStack Ceph 마이그레이션을 검토할 때 저는 늘 같은 질문부터 던집니다. "지금 바꾸면 뭐가 좋아지고, 대신 무엇을 새로 운영해야 하나"라는 질문이죠. 핵심은 단순한 저장소 교체가 아니라 운영 모델의 변경입니다. Cinder 볼륨만 옮길지, Glance 이미지 저장소까지 묶을지, Nova의 에페메럴 디스크까지 Ceph RBD로 정리할지에 따라 난이도와 장애 반경이 완전히 달라지거든요. 실제 운영에서는 성능 수치보다 스케줄링 일관성, Ceph 재배치 부담, 인증 권한, 롤백 가능성이 더 자주 발목을 잡습니다.

이 글은 OpenStack과 Ceph의 일반적인 운영 패턴을 기준으로 정리했습니다. 특정 벤더 확장 기능이나 과장된 수치 없이, 현장에서 일정 잡을 때 실제로 보는 판단 기준과 절차만 남겼습니다. 한 줄로 줄이면 이렇습니다. 기존 백엔드를 덮어쓰지 말고, 새 백엔드를 병행 등록한 뒤 신규 유입과 기존 자산 이동을 분리해서 진행하는 편이 안전합니다. 관련해서 볼륨 타입 설계나 Ceph 풀 설계 글도 함께 보시면 운영 그림이 훨씬 빨리 잡힙니다.

OpenStack 서비스 계층과 Ceph 풀(pool) 구조, 데이터 이동 흐름을 한눈에 보여주는 개요 이미지입니다.

1. OpenStack Ceph 마이그레이션을 고민하는 대표적인 이유

운영 현장에서는 보통 "Ceph가 좋아 보여서"가 아니라 아래 같은 이유로 움직입니다.

• 풀 구조가 성장 패턴을 못 따라갈 때: 같은 풀에 서로 다른 I/O 성격의 볼륨이 섞이면 운영 판단이 흐려집니다.
• 볼륨 타입 정책을 분리해야 할 때: 테넌트별, 워크로드별, 복제 정책별로 다른 백엔드가 필요해집니다.
• 증설과 장애 대응의 표준화가 필요할 때: 하드웨어별 절차보다 Ceph 기준으로 운영 일관성을 맞추고 싶을 때가 많습니다.
• 기존 백엔드가 OpenStack 스케줄러와 잘 안 맞을 때: 사용자는 타입을 골랐는데 실제 배치가 정책대로 안 되는 경우가 반복됩니다.

제가 실무에서 특히 중요하게 보는 건 "왜 옮기느냐"보다 어디까지 옮기느냐입니다. Cinder만 옮기면 블록 스토리지 정책 문제로 한정되지만, Glance까지 함께 들어가면 이미지 캐시와 부팅 경로가 바뀝니다. Nova 에페메럴까지 손대는 순간부터는 스토리지 변경이라기보다 컴퓨트 설계 변경에 가깝습니다.

2. OpenStack Ceph 마이그레이션 결정 기준은 성능보다 운영 책임입니다

Ceph 도입 여부를 성능 하나로만 판단하면 나중에 꼬이기 쉽습니다. 더 정확한 질문은 이겁니다. "이 팀이 Ceph의 재배치, 권한, 풀 정책, 장애 메시지를 자기 책임으로 읽고 운영할 준비가 됐는가"예요. 이 기준이 생각보다 훨씬 현실적입니다.

짧게 정리하면 이렇습니다. 볼륨 타입 분리와 점진 전환이 필요하면 Ceph 쪽이 유리하고, 운영 역량이 아직 약하면 기존 백엔드를 남겨둔 병행 운영이 맞습니다. 반대로 다운타임 제로만 바라보면서 한 번에 덮어쓰는 방식은 실무에서 꽤 위험하더라고요.

3. OpenStack 스토리지 교체 범위를 자르면 난이도가 확 줄어듭니다

OpenStack 스토리지 교체는 기술 문제라기보다 범위 관리 문제인 경우가 많습니다. 보통 아래 셋으로 끊습니다.

1. Cinder 볼륨만 전환: 가장 현실적이고, 실패해도 영향 반경을 제한하기 쉽습니다.
2. Glance 이미지까지 전환: 이미지 업로드, 캐시, 부팅 경로를 함께 봐야 합니다.
3. Nova 에페메럴 디스크까지 전환: 성능과 일관성 이득은 크지만 컴퓨트 노드 영향이 급격히 커집니다.

제가 추천하는 순서는 거의 같습니다. Cinder -> Glance -> Nova예요. 이유는 단순합니다. Cinder는 볼륨 타입이라는 절연층이 있지만, Nova 루트/에페메럴까지 한 번에 건드리면 인스턴스 부팅 실패가 곧바로 서비스 장애로 번지기 쉽습니다.

실무에서 자주 보는 장면도 있습니다. 기존에는 외부 SAN을 쓰다가 "이번에 Ceph도 붙였으니 볼륨도 이미지도 같이 넘기자"고 범위를 넓히는 경우죠. 이때 Cinder 신규 볼륨은 정상 생성되는데, 부팅 지연이나 이미지 캐시 미스 때문에 운영팀이 Glance 문제를 Ceph 문제로 오해하는 일이 꽤 많습니다. 그래서 저는 첫 전환 주기에는 신규 볼륨 경로와 이미지 경로를 일부러 분리합니다. 원인 분리가 정말 편해집니다.

4. OpenStack Ceph 마이그레이션 사전 점검

이 단계는 체크리스트라기보다 진입 금지선에 가깝습니다. 상태가 좋지 않으면 일정부터 미루는 편이 맞습니다. 마이그레이션 자체보다, 진행 중 나타난 문제의 원인이 Ceph인지 OpenStack인지 분리하기 어려워지기 때문입니다.

ceph -s
ceph health detail
ceph osd stat
ceph osd tree
ceph osd df tree
ceph osd pool ls detail
rados df
openstack volume service list
openstack volume type list --long
openstack volume list --status in-use --long

여기서는 보통 이렇게 읽습니다.

• ceph -s: 클러스터 전체 상태와 recovery/backfill 진행 여부를 먼저 봅니다. 단순 HEALTH_WARN보다 경고 원인이 재배치인지 용량 임계치인지가 더 중요합니다.
• ceph health detail: degraded, undersized, inactive, nearfull 계열 메시지가 보이면 이동 작업을 미룹니다.
• ceph osd df tree: 특정 OSD만 유독 가득 찼다면 마이그레이션 중 backfill이 겹치면서 체감 성능이 흔들릴 가능성이 큽니다.
• ceph osd pool ls detail: 새 풀의 복제 정책, CRUSH rule, autoscale 상태를 봅니다. 풀 이름만 맞고 규칙이 다르면 기대한 장애 도메인이 깨질 수 있습니다.
• openstack volume service list: 대상 cinder-volume 서비스가 up이고 enabled인지 확인합니다.
• openstack volume type list --long: 현재 타입과 백엔드 이름 연결이 살아 있는지 확인합니다.
• openstack volume list --status in-use --long: 붙어 있는 볼륨 비중이 높다면 온라인 정책 변경이 가능한지부터 따져야 합니다.

실제 실패 모드도 비슷합니다. 새 타입은 잘 만들었는데 Ceph 쪽에서 이미 backfill이 길게 돌고 있던 상황이죠. OpenStack API는 성공으로 보이는데 사용자는 I/O 지연을 바로 체감합니다. OpenStack의 성공 응답이 Ceph 내부 재배치 비용까지 끝났다는 뜻은 아니라는 점, 이 부분은 꼭 분리해서 봐야 합니다.

Ceph 클러스터 헬스 체크, 풀 상태, Cinder 볼륨 타입과 백엔드 이름 매핑 관계를 설명하는 이미지입니다.

5. 백엔드 설계는 pool보다 volume type을 먼저 잡아야 합니다

운영에서 더 오래 가는 설계는 "풀 이름 중심"이 아니라 볼륨 타입 중심입니다. 사용자는 타입을 고르고, Cinder 스케줄러는 타입의 extra_specs를 보고 백엔드를 고르거든요. 그래서 이름 규칙이 중요합니다.

• 백엔드 섹션 이름: 운영자가 구분하기 쉬운 내부 이름
• volume_backend_name: 타입과 연결되는 스케줄링 식별자
• Ceph 풀 이름: 실제 데이터가 놓이는 물리적 대상

많이 헷갈리는 지점이 하나 있습니다. [rbd-new] 같은 설정 섹션 이름과 volume_backend_name=rbd-new는 같은 개념이 아닙니다. 우연히 같게 맞출 수는 있지만, 스케줄러가 직접 참조하는 값은 섹션명이 아니라 백엔드 이름입니다. 여기 오타가 나면 타입은 멀쩡해 보여도 No valid host 오류가 나기 쉽습니다.

5-1. OpenStack Ceph 마이그레이션용 cinder.conf 예시

[DEFAULT]
enabled_backends = rbd-old,rbd-new

[backend_defaults]
rbd_ceph_conf = /etc/ceph/ceph.conf
rbd_user = cinder
rbd_secret_uuid = 11111111-2222-3333-4444-555555555555
volume_driver = cinder.volume.drivers.rbd.RBDDriver

[rbd-old]
volume_backend_name = rbd-old
rbd_pool = volumes_old

[rbd-new]
volume_backend_name = rbd-new
rbd_pool = volumes_new

현재 Cinder 샘플 설정에서도 공통 백엔드 옵션은 [backend_defaults] 섹션을 사용합니다. 여기서 중요한 건 세 가지예요. enabled_backends에 백엔드 섹션이 모두 들어가 있는지, 각 섹션의 volume_backend_name이 타입의 extra_specs와 정확히 일치하는지, 공통 설정을 쓴다면 [backend_defaults]와 개별 섹션의 덮어쓰기 관계를 이해하고 있는지입니다.

기존 단일 백엔드 서비스에 다중 백엔드를 붙이는 경우, Cinder 서비스 호스트명이 host에서 host@backend 형태로 바뀌는 환경도 있습니다. 이런 경우 기존 볼륨의 host 메타데이터를 갱신하지 않으면 운영이 꼬일 수 있어서, 사전에 cinder-manage volume update_host 대상 여부를 꼭 확인하는 편이 좋습니다.

5-2. Ceph 풀과 인증 준비

새 풀만 만들고 끝내면 안 됩니다. RBD로 쓸 풀은 초기화와 권한까지 맞아야 합니다. 저는 신규 백엔드를 붙이기 전에 아래 항목을 먼저 확인합니다.

ceph osd pool ls detail
rbd pool init volumes_new
ceph auth get-or-create client.cinder \
  mon 'profile rbd' \
  osd 'profile rbd pool=volumes_new, profile rbd pool=vms, profile rbd-read-only pool=images' \
  mgr 'profile rbd pool=volumes_new, profile rbd pool=vms'
ceph auth get-or-create client.glance \
  mon 'profile rbd' \
  osd 'profile rbd pool=images' \
  mgr 'profile rbd pool=images'

근본 원인은 늘 비슷합니다. 풀은 만들었는데 rbd pool init이 빠졌거나, client.cinder가 새 풀에 대한 cap을 갖고 있지 않거나, Glance와 Cinder 권한을 뭉뚱그려 잡아두는 식이죠. 이런 상태에선 볼륨 생성은 되는데 attach에서 실패하거나, 이미지 기반 볼륨 생성만 유독 실패하는 식으로 증상이 갈라집니다.

5-3. 새 볼륨 타입 생성

openstack volume type create ceph-rbd-new
openstack volume type set --property volume_backend_name=rbd-new ceph-rbd-new
openstack volume type show ceph-rbd-new
openstack volume type list --long

운영상 의미는 명확합니다. 신규 생성 경로를 먼저 새 백엔드로 돌리고, 기존 자산 이동은 그다음에 따로 한다는 거예요. 이 분리가 되면 실패했을 때 되돌리기도 쉬워집니다.

6. OpenStack Ceph 마이그레이션 절차: 신규 유입과 기존 자산을 분리하세요

실무 절차는 의외로 단순합니다. 대신 순서를 어기면 비용이 바로 커집니다.

1. 새 백엔드를 등록하고 타입을 만든다: 아직 기존 타입은 그대로 둡니다.
2. 신규 볼륨만 새 타입으로 생성하게 유도한다: 새 데이터 유입을 먼저 분리합니다.
3. 테스트 프로젝트에서 생성, attach, detach, 삭제까지 한 사이클을 검증한다: 생성만 확인하면 부족합니다.
4. 저위험 볼륨부터 정책 변경 또는 마이그레이션을 시작한다: 백업성 볼륨, 비핵심 업무부터 갑니다.
5. Ceph 재배치 상태를 보며 배치를 늘린다: API 성공률이 아니라 클러스터 안정성을 기준으로 속도를 조절합니다.
6. 기존 타입의 신규 생성을 막는다: 잔여 볼륨만 남기고 정리 단계로 들어갑니다.

CLI는 환경에 따라 조금씩 다르게 씁니다. 현재 openstackclient에서는 볼륨 타입 변경을 openstack volume set --type로 수행할 수 있고, 일부 운영 환경은 여전히 cinder retype를 사용합니다. 핵심은 명령 이름보다 정책 변경이 실제 데이터 이동을 유발하는지를 테스트 볼륨으로 먼저 확인하는 겁니다.

# 현재 openstackclient 계열에서 많이 쓰는 방식
openstack volume set \
  --type ceph-rbd-new \
  --migration-policy on-demand \
  8f1f2f0d-1111-2222-3333-444444444444
openstack volume show 8f1f2f0d-1111-2222-3333-444444444444

# 환경에 따라 여전히 사용하는 cinder client 방식
cinder retype \
  --migration-policy on-demand \
  8f1f2f0d-1111-2222-3333-444444444444 \
  ceph-rbd-new

관리자가 목적지를 더 강하게 통제해야 한다면 백엔드 호스트를 직접 지정하는 방식도 씁니다.

openstack volume migrate \
  --host host01@rbd-new#volumes_new \
  8f1f2f0d-1111-2222-3333-444444444444
openstack volume show 8f1f2f0d-1111-2222-3333-444444444444 -f yaml

저는 보통 이렇게 고릅니다. 볼륨 타입 정책까지 함께 정리하려면 retype 계열이 낫고, 특정 백엔드 호스트나 풀을 명시적으로 통제해야 하면 migrate가 더 직접적입니다. 다만 in-use 볼륨의 재타입은 마이그레이션이 동반되면 보통 관리자 권한이 필요하고, 암호화된 in-use 볼륨은 재타입 마이그레이션이 지원되지 않는 경우가 있습니다. 이런 케이스는 무리해서 실시간 전환하지 말고 점검창을 잡는 편이 더 안전합니다.

신규 생성 분리, 테스트 볼륨 이동, 운영 볼륨 확장 전환 순서를 보여주는 절차형 이미지입니다.

7. OpenStack Ceph 마이그레이션에서 자주 부딪히는 실패 모드

증상은 비슷해 보여도 원인은 다릅니다. 저는 아래 네 가지부터 먼저 자릅니다.

7-1. 타입은 맞는데 스케줄링이 안 됩니다

대부분은 volume_backend_name 불일치, 백엔드 서비스 비활성화, 드라이버 초기화 실패 셋 중 하나입니다.

grep -E 'enabled_backends|volume_backend_name|rbd_pool|rbd_user' /etc/cinder/cinder.conf
openstack volume service list
journalctl -u openstack-cinder-scheduler -n 200 --no-pager
journalctl -u openstack-cinder-volume -n 200 --no-pager

배포판에 따라 systemd 유닛명은 다를 수 있으니 서비스 이름은 현 환경 기준으로 바꿔서 보시면 됩니다. 근본 원인은 흔히 두 가지예요. 첫째, 타입은 rbd-new를 보는데 실제 백엔드는 rbd_new처럼 다른 이름으로 등록된 경우. 둘째, 드라이버가 Ceph 인증 실패로 초기화되지 않았는데 운영자가 프로세스만 살아 있다고 착각하는 경우입니다.

7-2. Ceph 인증 문제로 생성 또는 attach가 막힙니다

이 경우는 생성 단계와 attach 단계의 증상이 달라서 더 헷갈립니다. 새 풀에 대한 cap이 없거나, Nova와 Cinder, Glance가 참조하는 사용자명과 시크릿, 키링 경로가 어긋나 있는 경우가 많습니다. 특히 Cinder가 볼륨을 만들 수 있는 권한과 Nova/libvirt가 그 볼륨을 실제로 매핑할 수 있는 권한은 완전히 같은 문제가 아닐 수 있습니다.

7-3. 이동은 됐는데 체감 성능이 흔들립니다

이건 마이그레이션 명령의 성공 여부보다 Ceph 내부 상태를 먼저 봐야 합니다. recovery, backfill, nearfull 경고가 길게 이어지면 배치를 줄이거나 윈도우를 다시 잡는 편이 맞습니다. 현장에서 자주 보는 패턴은 이렇습니다. 낮 시간대에 작은 볼륨 몇 개는 멀쩡해서 속도를 올렸는데, 저녁 배치에서 대용량 볼륨과 Ceph 재배치가 겹치며 지연이 튀는 거죠. 이거 진짜 자주 나옵니다.

7-4. 소스 풀에 고아 이미지가 남습니다

실패한 이동, 중단된 작업, 관리자의 수동 정리 이력 때문에 원본 풀에 RBD 이미지가 남을 수 있습니다. 그렇다고 바로 지우면 안 됩니다. 먼저 OpenStack DB가 가리키는 위치와 실제 풀 위치가 일치하는지 확인해야 합니다. 저는 최소 하루 이상 운영 검증을 둔 뒤 정리합니다.

8. 검증은 보이는지보다 원하는 위치에서 실제로 쓰는지 봐야 합니다

마이그레이션 후 검증은 세 겹으로 합니다. OpenStack 상태, Ceph 실체, 워크로드 체감입니다.

1. 볼륨 메타데이터 확인: 타입, 상태, migration 관련 필드 확인
2. 대상 풀의 실제 RBD 이미지 확인: 새 풀에 이미지가 생겼는지 확인
3. attach 후 읽기/쓰기 확인: 실제 인스턴스에서 I/O 검증
4. 소스 풀 잔존물 확인: 즉시 삭제하지 말고 정리 후보만 분리

openstack volume show 8f1f2f0d-1111-2222-3333-444444444444
rbd ls volumes_new
rbd info volumes_new/volume-8f1f2f0d-1111-2222-3333-444444444444
rbd ls volumes_old

저는 운영 확인을 여기서 끝내지 않습니다. 인스턴스에 붙여 파일 생성, 재마운트, 재부팅 후 재연결까지 확인합니다. 볼륨이 새 풀에 존재하는 것과, 서비스가 그 볼륨을 문제없이 소비하는 것은 다른 검증이거든요. 여기까지 봐야 마음이 놓입니다.

볼륨 상태 확인, 대상 풀의 RBD 이미지 존재 여부, 운영 검증 체크리스트를 보여주는 결과 이미지입니다.

9. 언제 Ceph 스토리지 전환을 고르고, 언제 병행 운영을 고를까

현장 추천은 꽤 분명합니다.

• 다운타임이 거의 없고 운영 안정성이 최우선이다: 기존 백엔드를 유지한 병행 운영 후, 새 타입으로 신규를 먼저 분리하고 기존은 점진적으로 옮기세요.
• 목표가 스토리지 통합 운영과 볼륨 정책 세분화다: Ceph 백엔드를 붙이되, 처음 범위는 Cinder로 제한하세요.
• 팀이 Ceph 장애 메시지와 재배치를 아직 익숙하게 다루지 못한다: 바로 전면 전환하지 말고 신규 볼륨만 새 백엔드로 보내며 운영 감각부터 쌓는 편이 낫습니다.
• 이미 Ceph를 쓰고 있고 풀 구조만 재정비하고 싶다: 풀 직접 교체보다 새 백엔드와 새 타입을 따로 만들고 정책 전환으로 정리하는 편이 안전합니다.
• Nova 에페메럴까지 한 번에 바꾸고 싶다: 말리고 싶습니다. Cinder 경로가 안정화된 뒤 별도 프로젝트로 다루는 편이 훨씬 덜 아픕니다.

여러 번 겪어보면 결국 덜 아픈 방법은 비슷합니다. 새 백엔드를 먼저 붙이고, 신규 생성 경로를 갈라놓고, 기존 볼륨은 업무 중요도와 Ceph 상태를 보면서 천천히 옮기는 방식이죠. 빠른 전환보다 되돌릴 수 있는 전환이 훨씬 값집니다.

FAQ

Q. retype와 migrate 중 무엇을 먼저 고려하면 될까요?

볼륨 타입 정책 자체를 바꾸는 게 목적이면 retype 계열이 더 자연스럽습니다. 특정 목적지 호스트와 풀을 명시적으로 통제해야 하면 migrate가 더 직접적입니다. 다만 둘 다 실제 데이터 복사 여부는 현재 배치와 드라이버 동작에 좌우되니, 테스트 볼륨 검증부터 해보는 게 맞습니다.

Q. 기존 백엔드는 언제 제거하는 게 좋을까요?

신규 생성이 완전히 차단되고, 잔여 볼륨과 소스 풀의 정리 후보가 분리되고, 운영 검증 기간을 지난 뒤가 적절합니다. 저는 최소 한 템포 두고 소스 풀을 정리합니다.

Q. Ceph가 항상 정답인가요?

아닙니다. Ceph의 장점은 기능 자체보다 운영 일관성에 있습니다. 팀이 그 일관성을 감당할 준비가 안 돼 있다면, Ceph 도입은 기술 선택이 아니라 운영 부채가 될 수도 있습니다.

어떤 상황에서 병행 운영, 점진 전환, 즉시 전환 중 무엇을 고를지 요약한 마무리 인포그래픽입니다.