Ceph 클러스터 장애가 발생했을 때,BE가 계속 retry를 하면서 오히려 응답이 더 느려지고 있었습니다. 배경현재 Ceph API를 활용해서 Ceph 데이터를 서빙하는 백엔드를 개발하고 있습니다.FE → G/W → BE → Ceph MGR API (Active-Standby 구조)서비스 흐름 자체는 단순한데, Ceph의 Active-Standby 구조 때문에303 Redirect, Fallback, Retry, Active MGR 갱신 같은 걸 전부 BE에서 직접 처리하고 있었습니다.평소에는 별 문제 없이 돌아갔는데, Ceph 장애 상황에서는 다음과 같은 문제가 발생했습니다.평균 응답 시간이 1.15초까지 증가redirect → retry → host 순회 → 재귀 호출 구조장애 원인 파악이 어려움(..

RBD 이미지 -> PG -> OSD 매핑Ceph 클러스터를 운영하다 보면 장애 분석이나 성능·용량 이슈가 생겼을 때,“지금 보고 있는 RBD 이미지가 실제로 어떤 PG에 올라가 있고, 그 PG가 어떤 OSD 들에 퍼져 있는지”를 알고 싶은 순간이 생겼습니다. 예를 들어,1. 특정 OSD 장애가 발생했을 때, 그 OSD에 어떤 이미지가 얼마나 몰려 있는지 보고 싶거나2. 리밸런싱 이후 데이터가 의도대로 고르게 분산됐는지 확인하고 싶은경우 "Ceph 내부에서는 객체 이름과 풀 ID로 해시해서 PG를 계산하고 이 PG를 다시 CRUSH로 여러 OSD에 배치를 하게 됩니다."그래서 저는 go-cpeh(librados를 go 언어로 래핑한 오픈소스)를 사용하여 RBD 이미지 -> PG -> OSD 매핑 API ..