[인프라] OpenStack Ceph 연동 실패 사례와 스토리지 성능 최적화 교훈

OpenStack Ceph 연동은 프라이빗 클라우드를 운영할 때 한 번쯤 꼭 마주치는 주제입니다. 저도 홈랩과 실무 환경에서 OpenStack 스토리지 구성을 여러 번 만졌는데요, 처음엔 단순히 연결만 되면 끝일 줄 알았습니다. 그런데 실제로 써보니까 연동 성공과 제대로 빠르게 동작하는 상태는 완전히 다른 이야기더라고요. 특히 볼륨 생성은 되는데 체감이 느리거나, 가상머신 부팅이 들쭉날쭉하거나, 특정 시간대에 I/O가 몰리면 급격히 지연이 커지는 문제를 겪으면 그때부터 삽질이 시작됩니다. 혹시 지금 OpenStack Ceph 연동 이후 성능이 이상하게 답답하다고 느끼고 계신가요?

여기서 중요한 포인트는, 원인이 Ceph 자체인지 OpenStack 설정인지, 아니면 둘 사이의 연결 방식인지 분리해서 봐야 한다는 점입니다. 이 글에서는 제가 직접 겪었던 OpenStack Ceph 연동 실패 패턴과 해결 방법을 정리했으니, 비슷한 상황이라면 참고하시길 바랍니다.

OpenStack 컴퓨트, 이미지, 블록 스토리지 서비스와 Ceph 클러스터 간 연결 구조를 한눈에 보여주는 아키텍처 이미지입니다.

왜 OpenStack Ceph 연동에서 성능 문제가 자주 생길까

쉽게 말해 OpenStack는 서비스를 제공하는 제어 평면(control plane)이고, Ceph는 실제 데이터를 저장하는 분산 스토리지(distributed storage) 역할을 합니다. 많이들 Cinder(신더, 블록 스토리지), Glance(글랜스, 이미지 서비스), Nova(노바, 컴퓨트)가 Ceph의 RBD(RADOS Block Device, 블록 디바이스 인터페이스)를 함께 쓰도록 구성하죠. 구조만 보면 깔끔합니다. 근데 여기서 병목이 생기는 지점이 꽤 많습니다.

• 인증 설정은 맞는데 풀(pool) 권한이 어긋난 경우
• 네트워크 분리가 부족해서 클라이언트 트래픽과 복제 트래픽이 섞이는 경우
• 풀 설계가 서비스 특성과 맞지 않는 경우
• 하이퍼바이저(hypervisor) 캐시 정책이 애매해서 지연이 커지는 경우
• 작은 I/O가 많이 발생하는 워크로드를 고려하지 않은 경우

저도 처음엔 Ceph 최적화라고 하면 OSD(Object Storage Daemon, 오브젝트 스토리지 데몬) 쪽만 보면 된다고 생각했었는데요, 막상 들여다보니 OpenStack 스토리지 설정에서 생기는 비효율이 꽤 컸습니다. 특히 이미지 업로드는 괜찮은데 볼륨 기반 부팅이 유독 느린 경우, 그 원인이 하나가 아니라 여러 레이어에 걸쳐 있는 경우가 많았습니다.

구성 개념 먼저 정리해보겠습니다

OpenStack Ceph 연동을 이해할 때는 각 서비스가 어느 풀을 쓰는지부터 정리하면 훨씬 덜 헷갈립니다.

핵심은 이겁니다. OpenStack 스토리지 성능은 단순히 디스크가 빠르냐 느리냐로 끝나지 않습니다. 인증, 네트워크, 풀 설계, 복제 정책(replication policy), 클라이언트 설정이 다 같이 맞물립니다. 그래서 문제를 볼 때도 한 군데만 보면 안 되죠.

제가 실제로 점검했던 사전 체크리스트

본격적으로 손대기 전에 저는 항상 아래 순서대로 확인합니다. 이 순서를 안 지키면 괜히 OSD 튜닝만 하다가 시간을 많이 쓰게 되더라고요.

1. Ceph 클러스터 상태가 HEALTH_OK 또는 경미한 경고 수준인지 확인합니다.
2. Glance, Cinder, Nova가 각각 어떤 Ceph 사용자와 풀을 쓰는지 정리합니다.
3. 스토리지 네트워크와 서비스 네트워크가 분리되어 있는지 확인합니다.
4. 볼륨 생성, 이미지 업로드, 부팅 중 어디가 가장 느린지 구분합니다.
5. 가상머신 내부 체감 속도와 백엔드 I/O 지표를 따로 봅니다.

여기서 중요한 포인트! 사용자는 보통 “Ceph가 느리다”라고 말하지만, 실제로는 이미지 복사 경로가 비효율적이거나 캐시 정책이 안 맞아서 그렇게 느끼는 경우도 많습니다. 저도 예전에 이걸 구분 못 해서 하루를 날린 적이 있습니다. OpenStack Ceph 연동에서는 정말 이런 실수가 흔하거든요.

실전 구현: OpenStack Ceph 연동 기본 점검과 설정

아래 예시는 개념을 설명하기 위한 일반적인 형태입니다. 배포판이나 자동화 도구에 따라 파일 위치와 세부 항목은 조금 다를 수 있습니다. 그래도 큰 흐름은 비슷합니다.

1. Ceph 클러스터 상태 확인

ceph -s
ceph health detail
ceph osd tree
ceph osd df
rbd pool ls

이 단계에서 저는 먼저 복제 지연이나 OSD 불균형부터 봅니다. 연동 전에 백엔드가 불안정하면 OpenStack 쪽에서 아무리 손봐도 체감이 안 좋아집니다.

2. Ceph 사용자 권한 확인

ceph auth list
ceph auth get client.glance
ceph auth get client.cinder
ceph auth get client.nova

권한이 과하게 넓은 것도 문제지만, 더 자주 보는 건 풀 권한이 어설프게 빠져 있는 경우입니다. 그러면 기능은 되는 것처럼 보여도 특정 작업에서만 실패하거나 지연이 생깁니다.

3. Cinder 백엔드 확인

[ceph]
volume_driver = cinder.volume.drivers.rbd.RBDDriver
volume_backend_name = ceph
rbd_pool = volumes
rbd_user = cinder
rbd_ceph_conf = /etc/ceph/ceph.conf
rbd_secret_uuid = YOUR_SECRET_UUID
rbd_flatten_volume_from_snapshot = false
rbd_max_clone_depth = 5
rbd_store_chunk_size = 8

rbd_max_clone_depth 같은 항목은 운영 방식에 따라 영향을 줄 수 있습니다. 저는 예전에 스냅샷 기반 복제가 누적된 상태를 방치했다가, 특정 볼륨 체인에서 응답이 들쭉날쭉해지는 걸 본 적이 있습니다.

4. Glance 백엔드 확인

[glance_store]
default_backend = rbd
stores = rbd
rbd_store_pool = images
rbd_store_user = glance
rbd_store_ceph_conf = /etc/ceph/ceph.conf

Glance(글랜스, 이미지 서비스)가 Ceph를 바로 쓰도록 해두면 이미지 관리가 단순해집니다. 다만 이미지 업로드와 변환 작업이 많은 환경이라면 여기서도 풀 설계와 I/O 패턴을 꼭 같이 봐야 합니다.

OpenStack 서비스별로 어떤 Ceph 사용자와 풀을 사용하는지 보여주는 구성 다이어그램입니다.

실패 사례: OpenStack Ceph 연동은 됐는데 성능이 안 나온 이유

이제 제가 실제로 겪었던 전형적인 실패 패턴을 말씀드려볼게요. 처음엔 볼륨 생성도 되고 인스턴스도 뜨니까 성공한 줄 알았습니다. 그런데 실제로 써보니까 VM 부팅 시간이 일정하지 않았고, 동시에 여러 작업이 걸리면 체감 지연이 확 올라가더라고요. 여기서부터가 진짜 OpenStack Ceph 연동의 시작이었습니다.

문제 1. 네트워크를 논리적으로만 나눠놓고 물리적으로는 섞어 썼던 경우

Ceph는 복제와 복구 트래픽이 발생합니다. 그런데 클라이언트 액세스와 같은 대역을 공유하면 피크 시간에 지연이 커질 수 있습니다. 저도 홈랩에서 처음엔 VLAN만 나누면 충분하겠지 했었는데, 실제로는 업링크 혼잡이 생기면서 체감 성능이 꽤 흔들렸습니다.

• 증상: 특정 시간대에 볼륨 attach와 부팅 지연 증가
• 원인: 스토리지 트래픽과 일반 서비스 트래픽 경합
• 대응: 스토리지 네트워크 경로를 분리하고 혼잡 구간을 줄임

문제 2. 풀을 나누지 않고 한 곳에 몰아넣은 경우

이미지, 볼륨, 테스트용 작업이 한 풀에 몰려 있으면 관찰도 어렵고 튜닝 포인트도 흐려집니다. Ceph 최적화는 결국 워크로드 분리가 기본이더라고요.

• 증상: 어떤 작업이 느린지 구분이 잘 안 됨
• 원인: 서비스별 I/O 특성 혼재
• 대응: images, volumes 등 역할 단위로 풀을 분리해 관찰성 확보

문제 3. 클론과 스냅샷 체인을 너무 방치한 경우

처음엔 공간 절약 측면에서 좋아 보이는데, 운영 기간이 길어지면 관리 포인트가 늘어납니다. 특히 오래된 이미지 기반으로 파생된 체인이 많아지면, 성능과 운영 복잡도가 같이 올라갈 수 있습니다. OpenStack Ceph 연동 운영에서는 정말 흔한 문제입니다.

문제 4. 성능 문제를 전부 Ceph 탓으로만 본 경우

이거 정말 많이 봅니다. 근데 실제로는 하이퍼바이저 캐시 설정, 인스턴스 유형별 디스크 패턴, 백그라운드 작업 영향도 같이 봐야 하거든요. 저도 처음엔 Ceph OSD만 의심했었는데, 나중에 보니 OpenStack 스토리지 경로에서 이미지 변환과 attach 흐름이 더 큰 영향을 준 케이스가 있었습니다.

⚠️ 트러블슈팅: 제가 효과를 봤던 점검 순서

문제가 생기면 아래 순서로 좁혀가면 좋습니다. 무작정 튜닝부터 하지 마세요. 저도 예전엔 그랬다가 더 꼬였습니다.

1. Ceph 상태 확인
   클러스터 경고, 리밸런싱(rebalancing), 복구 상태를 먼저 확인합니다.
2. 풀 단위 관찰
   어느 풀이 바쁜지, 이미지와 볼륨 중 어디서 병목이 생기는지 봅니다.
3. OpenStack 작업별 분리
   이미지 업로드, 볼륨 생성, 인스턴스 부팅을 따로 테스트합니다.
4. 동시 작업 테스트
   단건 테스트는 괜찮은데 동시성에서 무너지는 경우가 많습니다.
5. 체인 정리 여부 검토
   오래된 스냅샷/클론 구조가 쌓였는지 확인합니다.

openstack volume create --size 10 test-volume
openstack server create --flavor m1.small --image test-image --network private test-vm
rbd ls -p volumes
rbd info volumes/test-volume
ceph osd perf

여기서 ceph osd perf 같은 기본 지표와 OpenStack 작업 시간을 같이 비교해보면 감이 옵니다. 절대적인 숫자보다 언제 느려지는지, 어떤 작업에서 흔들리는지를 보는 게 더 중요합니다.

볼륨 생성과 가상머신 부팅 과정에서 지연이 발생하는 구간을 시각적으로 보여주는 대시보드 이미지입니다.

Ceph 최적화 관점에서 배운 점

이번 경험에서 가장 크게 느낀 건, Ceph 최적화는 단일 옵션 몇 개로 끝나는 작업이 아니라는 점이었습니다. 결국 아래 네 가지가 같이 맞아야 하더라고요.

• 네트워크 분리: 복제와 클라이언트 경로를 명확히 구분
• 풀 설계: 워크로드 성격에 맞춰 역할 분리
• 운영 습관: 오래된 스냅샷/클론 체인 방치 금지
• 관찰성: OpenStack 로그와 Ceph 상태를 함께 확인

스토리지 성능은 숫자 하나로 판단하기 어렵습니다. 어떤 환경에서는 작은 랜덤 I/O가 문제고, 또 어떤 환경에서는 이미지 배포 흐름이 더 큰 병목이 됩니다. 그래서 저는 요즘은 성능 문제가 나오면 먼저 “이게 Ceph 문제인가, OpenStack 스토리지 경로 문제인가, 아니면 둘 다인가?”부터 구분합니다.

검증 방법: 무엇을 확인해야 실제로 좋아졌다고 볼 수 있을까

개선 후에는 꼭 검증이 필요합니다. 그냥 느낌상 빨라진 것 같다고 넘어가면 다음 장애 때 다시 원점으로 돌아갑니다.

1. 동일한 이미지로 인스턴스 부팅 시간을 여러 번 비교합니다.
2. 동시에 여러 볼륨을 생성해 지연 패턴이 안정적인지 봅니다.
3. 이미지 업로드와 볼륨 생성이 겹칠 때도 성능 저하가 과도하지 않은지 확인합니다.
4. Ceph 클러스터 상태가 테스트 중에도 안정적인지 체크합니다.

제가 직접 해보니, 단건 테스트보다 동시성 테스트가 훨씬 유의미했습니다. 평소엔 괜찮다가도 작업이 몰리면 바로 티가 나거든요. 드디어 됐다! 싶은 순간도 보통 이 구간을 통과했을 때였습니다.

openstack server list
openstack volume list
ceph -s
ceph df
rbd du -p volumes

검증할 때는 결과만 보지 말고, 테스트 중간에 경고가 발생하지 않는지도 꼭 보세요. 여기서 안정적이면 그제야 실제 운영에 올릴 만한 상태라고 판단합니다.

최적화 이전과 이후의 지연 안정성 차이를 비교하고, 운영자가 점검해야 할 항목을 요약한 이미지입니다.

실무적으로 정리하는 OpenStack 스토리지 운영 팁

이 표는 제가 나중에 운영 문서로도 정리해둔 기준입니다. 사실 OpenStack Ceph 연동은 한 번 붙이고 끝나는 프로젝트가 아니라, 붙인 뒤부터 운영 품질이 갈리는 영역입니다. 이전 글에서 다뤘던 기본 네트워크 설계와도 연결되는 부분이고, 다음 글에서는 Ceph 모니터링 포인트를 조금 더 깊게 다뤄볼 예정입니다.

마무리: 연동 성공보다 중요한 건 안정적인 성능입니다

오늘 정리한 실패 사례의 핵심은 단순합니다. OpenStack Ceph 연동이 되었더라도, 그 상태가 곧 최적 상태는 아니라는 점입니다. 저도 처음엔 연결만 되면 다 끝난 줄 알았는데, 실제 운영에서는 네트워크, 풀 설계, 스냅샷 체인, 작업 동시성까지 다 영향을 주더라고요. 삽질 좀 했습니다. 그래도 이런 과정을 겪고 나니 이제는 문제를 훨씬 빨리 좁힐 수 있게 됐습니다.

혹시 지금 OpenStack 스토리지 성능 때문에 답답하셨다면, 오늘 내용처럼 어디서 느려지는지 분리해서 보는 것부터 시작해보세요. 그게 가장 현실적인 첫걸음입니다. 그리고 Ceph 최적화는 무조건 큰 튜닝보다, 구조를 바르게 잡는 쪽이 효과가 더 컸습니다. 이 부분은 정말 경험상 그렇습니다.

연동 성공, 병목 원인 분리, 검증 절차, 운영 팁을 한 장으로 요약한 마무리 인포그래픽입니다.

정리 FAQ

Q. OpenStack Ceph 연동 후 가장 먼저 볼 것은 무엇인가요?

A. Ceph 클러스터 상태와 OpenStack 서비스별 풀/사용자 매핑입니다. 이 두 가지가 기본입니다.

Q. 스토리지 성능이 느리면 무조건 Ceph 튜닝부터 해야 하나요?

A. 아닙니다. 네트워크 경합, 풀 분리 부족, 스냅샷 체인 누적, OpenStack 작업 흐름까지 같이 봐야 합니다.

Q. OpenStack 스토리지 운영에서 가장 실수하기 쉬운 부분은 뭔가요?

A. 연동 성공을 성능 검증 완료로 착각하는 부분입니다. 꼭 동시성 테스트까지 해보셔야 합니다.