Ceph Blog(https://ceph.io/en/news/blog/)를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://ceph.io/en/news/blog/2025/stretch-cluuuuuuuuusters-part1/
Ceph Stretch 클러스터 1부: 핵심 개념¶
소개¶
복제, 재해 복구, 백업 및 복원을 고려할 때, 데이터 및 애플리케이션 복구에 대한 다양한 SLA를 적용하는 여러 전략 중에서 선택합니다. 주요 요소로는 Recovery Time Objective (RTO)와 Recovery Point Objective (RPO)가 있습니다. 동기식 복제는 가장 낮은 RPO를 제공하여 데이터 손실이 전혀 없습니다. Ceph는 Ceph 클러스터를 여러 데이터 센터에 걸쳐 확장하여 사이트 간 동기식 복제를 구현할 수 있습니다.
비동기 복제는 본질적으로 0이 아닌 RPO를 의미합니다. Ceph를 사용하는 경우, 비동기 다중 사이트 복제는 다른 Ceph 클러스터로 데이터를 복제하는 것을 포함합니다. 각 Ceph 스토리지 액세스 방식(객체, 블록, 파일)은 서비스 수준에서 구현되는 고유한 비동기 복제 방식을 갖습니다.
비동기 복제 : 복제는 서비스 수준(RBD, CephFS 또는 RGW)에서 발생하며, 일반적으로 완전히 독립적인 Ceph 클러스터에서 발생합니다.
동기 복제(“스트레치 클러스터”) : 복제는 RADOS(클러스터) 계층에서 수행되므로 클라이언트에 확인이 전송되기 전에 모든 사이트에서 쓰기가 완료되어야 합니다.
두 방법 모두 장단점이 뚜렷하며, 성능 프로필과 복구 고려 사항도 서로 다릅니다. Ceph 스트레치 클러스터에 대해 자세히 살펴보기에 앞서, 이러한 복제 모드에 대한 개요를 살펴보겠습니다.
Ceph의 복제 옵션¶
비동기 복제¶
비동기 복제는 서비스 계층에서 구동됩니다. 각 사이트는 완전한 독립형 Ceph 클러스터를 프로비저닝하고 데이터의 독립적인 복사본을 유지합니다.
- RGW 멀티사이트 : 각 사이트는 하나 이상의 독립적인 RGW 존을 구축합니다. 변경 사항은 RGW 멀티사이트 복제 프레임워크를 사용하여 사이트 간에 비동기적으로 전파됩니다. 이 복제는 저널 기반이 아닙니다. 대신 로그 기반 복제를 사용하는데, 각 RGW는 작업 로그(동기 로그)를 통해 변경 사항을 추적하고, 이 로그는 피어 사이트에서 재생되어 데이터를 복제합니다.
- RBD 미러링 : 성능, 충돌 일관성 및 스케줄링에 대한 요구 사항에 따라 저널 기반 접근 방식(Openstack과 같은) 또는 스냅샷 기반 접근 방식(ODF/OCP와 같은)을 사용하여 블록 데이터를 미러링합니다.
- CephFS 스냅샷 미러링 (현재 개발 중): 구성 가능한 간격으로 스냅샷을 사용하여 파일 데이터를 복제합니다.
비동기 복제는 위치 간 네트워크 지연 시간이 긴 아키텍처에 적합합니다. 이 방식을 사용하면 원격 쓰기가 완료될 때까지 기다리지 않고도 애플리케이션을 계속 운영할 수 있습니다. 하지만 이 전략은 본질적으로 0이 아닌 복구 지점 목표(RPO)를 제공하므로 원격 사이트가 기본 사이트와 일관성을 유지하기까지 약간의 지연이 발생한다는 점에 유의해야 합니다. 결과적으로, 사이트 장애 발생 시 아직 전송 중인 최근 작성된 데이터가 손실될 수 있습니다.
Ceph의 비동기 복제에 대해 알아보려면 이전 블로그 게시물인 개체 스토리지 멀티사이트 복제를 확인하세요 .
동기 복제: 스트레치 클러스터¶
스트레치 클러스터는 여러 데이터 센터 또는 가용성 영역에 배포된 단일 Ceph 클러스터입니다. 쓰기 작업은 모든 사이트 또는 각 논리적 풀의 복제 스키마 요구 사항을 충족하는 충분한 사이트에 저장된 후에만 클라이언트로 반환됩니다. 이는 다음을 제공합니다.
- RPO = 0 : 모든 클라이언트 쓰기가 동기적으로 복제되고 실패한 사이트가 다시 온라인 상태가 되면 재생되므로 한 사이트에 장애가 발생해도 데이터 손실이 없습니다.
- 단일 클러스터 관리 : 특별한 클라이언트 측 복제 구성이 필요하지 않습니다. 일반 Ceph 도구와 워크플로가 적용됩니다.
스트레치 클러스터는 엄격한 네트워킹 요구 사항을 갖습니다. 사이트 간 최대 RTT는 10ms입니다. OSD에 대한 쓰기는 클라이언트에게 확인 응답이 반환되기 전에 사이트 간에 전송되어야 하므로 지연 시간이 매우 중요합니다. 네트워크 불안정성, 대역폭 부족, 지연 시간 급증은 성능을 저하시키고 데이터 무결성을 위협할 수 있습니다.
Ceph Stretch 클러스터¶
소개¶
Ceph Stretch 클러스터는 최대 가동 시간과 복원력이 필요한 중요한 애플리케이션에 적합한 옵션으로 만드는 다음과 같은 이점을 제공합니다.
- 내결함성 : 스트레치 클러스터는 클라이언트 운영에 영향을 미치지 않고 전체 사이트의 장애를 투명하게 처리합니다. 데이터 손실 없이 이중 사이트 장애를 견딜 수 있습니다.
- 강력한 일관성: 3개 사이트 설정에서 온라인에 업로드된 데이터는 모든 가용 영역(AZ)/사이트에서 즉시 확인 및 접근 가능합니다. 강력한 일관성 덕분에 각 사이트의 클라이언트는 항상 최신 데이터를 확인할 수 있습니다.
- 간편한 설정 및 2일차 운영: 스트레치 클러스터의 가장 큰 특징 중 하나는 간편한 운영입니다. 대부분의 경우 일반적인 단일 사이트 클러스터와 유사합니다. 또한 사이트 장애 복구를 위한 수동 개입이 필요하지 않아 관리 및 배포가 용이합니다.
- 스트레치 클러스터는 지역 간 데이터 복제를 위해 다중 사이트 비동기 복제로 보완될 수 있습니다 .
그러나 Ceph 스트레치 클러스터의 경고 사항을 고려하는 것이 필수적입니다.
- 네트워킹은 매우 중요합니다 . 플래핑, 지연 급증, 대역폭 부족 등 사이트 간 네트워킹의 단점은 성능과 데이터 무결성에 영향을 미칩니다.
- 성능 : 쓰기 작업 지연 시간은 가장 멀리 떨어진 두 사이트의 RTT(Return to Time)에 따라 증가합니다. 세 사이트에 걸쳐 배포하는 경우, 풀 데이터 보호 전략은 복제를 위해 size는 값 6으로 설정해야 하며 이는 클라이언트 쓰기당 6개의 OSD 작업의 쓰기 증폭을 의미합니다. 이에 따라 워크로드 기대치를 설정해야 합니다. 예를 들어, 높은 IOPS와 낮은 지연 시간을 요구하는 OLTP 데이터베이스 워크로드는 스트레치 클러스터에 데이터를 저장하는 데 어려움을 겪을 가능성이 높습니다.
- 안정성을 위해 Replica 6(또는 Replica 4 2-사이트 스트레치)을 권장합니다 . 데이터 사본을 6개(또는 4개) 보관합니다. 성능 저하, 사이트 간 네트워크 수요, 그리고 강력한 일관성과 고가용성을 동시에 보장해야 하는 미묘한 차이 때문에 현재로서는 삭제 코딩(Erasure Coding)을 사용할 수 없습니다. 따라서 주어진 원시 기반 스토리지 용량에 대한 총 가용 용량을 기존 단일 사이트 클러스터와 비교하여 신중하게 고려해야 합니다.
- 모든 사이트에 걸친 단일 클러스터 : 단일 스트레치 클러스터에서 삭제를 포함한 소프트웨어 또는 사용자 문제로 인해 데이터가 손상된 경우 모든 사이트에서 볼 수 있는 데이터가 영향을 받습니다.
네트워킹: 스트레치 클러스터의 기초¶
스트레치 클러스터는 최적의 작동을 위해 강력한 네트워킹에 의존합니다. 최적화되지 않은 네트워크 구성은 성능과 데이터 무결성에 영향을 미칩니다.
- 사이트 간 동일한 지연 시간: 사이트는 고가용성 L2 또는 L3 네트워크 인프라를 통해 연결되며, 데이터 가용성 영역/사이트 간 지연 시간은 비슷합니다. RTT는 이상적으로 10ms 미만입니다. 네트워크 지연 시간(지터)이 일정하지 않으면 클러스터 성능이 저하됩니다.
- 지연 시간 급증이 최소화된 안정적인 L2/L3 네트워크 : 중복성을 갖춘 사이트 간 경로 다양성: 전체 메시 또는 중복 전송.
- 충분한 대역폭 : 네트워크는 복제, 클라이언트 요청 및 복구 트래픽을 처리할 수 있는 충분한 대역폭을 확보해야 합니다. 네트워크 대역폭은 클러스터 성장에 따라 확장되어야 합니다. 노드를 추가함에 따라 성능 유지를 위해 사이트 간 네트워크 처리량도 증가해야 합니다.
- 네트워킹 QoS는 유익합니다 . QoS가 없으면 상당한 사이트 간 트래픽을 보내거나 받는 잡음이 많은 이웃으로 인해 클러스터 안정성이 저하될 수 있습니다.
- 글로벌 로드 밸런서 : S3 RESTful 엔드포인트를 사용하는 개체 스토리지에는 사이트 장애 발생 시 클라이언트 요청을 리디렉션하기 위한 GLB가 필요합니다.
- 성능 : 각 클라이언트 쓰기는 사이트 간 최대 RTT(Return to Time)의 지연 시간 이상을 경험합니다. 다음 다이어그램은 클라이언트와 기본 OSD가 서로 다른 사이트에 있고 사이트 간 RTT가 1.5ms인 3개 사이트 스트레치 클러스터의 운영 지연 시간을 보여줍니다.
3개 사이트 스트레치 클러스터¶
각 데이터 센터(또는 가용성 영역)는 3개 사이트로 구성된 스트레치 클러스터의 OSD를 공유합니다. 각 영역에는 두 개의 데이터 복제본이 저장되므로 CRUSH 풀의 size 매개변수는 6입니다. 이를 통해 전체 사이트가 오프라인 상태가 되어도 클러스터는 데이터 가용성이나 손실 없이 클라이언트 작업을 처리할 수 있습니다. 주요 기능은 다음과 같습니다.
- 타이브레이커 없음 : 전체 데이터 사이트가 3개(모든 사이트에 OSD) 있으므로 모니터는 서로 연결할 수 있는 두 사이트와 정족수를 형성할 수 있습니다.
- 향상된 복원력 : 전체 사이트 장애와 생존한 사이트에서 추가 OSD 또는 노드 장애가 발생해도 살아남습니다.
- 네트워크 요구 사항 : L3 라우팅이 권장되며, 3개 사이트 간에 최대 10ms RTT가 필요합니다.
Ceph 3-사이트 스트레치 구성을 자세히 알아보려면 Kamoltat Sirivadhna의 훌륭한 Cephalocon 비디오를 시청하세요.
타이브레이커가 있는 2개 사이트 스트레치 클러스터¶
두 개의 데이터 센터만 지연 시간이 짧은 연결을 사용하는 배포의 경우, 두 데이터 센터에 OSD를 배치하고 세 번째 사이트는 다른 곳에 타이브레이커 모니터를 호스팅합니다. 이는 클라우드 제공업체의 VM일 수도 있습니다. 이렇게 하면 단일 사이트에 장애가 발생하더라도 클러스터가 쿼럼을 유지할 수 있습니다.
- 두 개의 저지연 주요 사이트 : 각각 전체 OSD 용량의 절반을 호스팅합니다.
- 타이브레이커 1개 : 사이트 호스팅과 타이브레이커 모니터.
- 복제본 : “size=4“로 풀 데이터 생성 전략을
replication사용하는데, 이는 데이터 센터당 복제본이 2개라는 의미입니다. - 지연 시간 : OSD를 포함하는 주요 데이터 센터 간 최대 10ms RTT. 타이브레이커 사이트는 훨씬 더 높은 지연 시간(예: 100ms RTT)을 허용할 수 있습니다.
- 향상된 netsplit 처리: 분할 브레인 시나리오를 방지합니다.
- SSD OSD가 필요합니다 . HDD OSD는 지원되지 않습니다.
결론¶
Ceph는 비동기 및 동기 복제 전략을 모두 지원하며, 각 전략은 복구 목표, 운영 복잡성 및 네트워킹 요구 사항 간에 특정한 상충 관계를 갖습니다. 비동기 복제(RBD 미러링, RGW 멀티사이트 및 CephFS 스냅샷 미러링)는 유연성과 손쉬운 지리적 배포를 제공하지만 RPO가 0이 아닙니다. 반면, 스트레치 클러스터는 여러 데이터 센터에 동기적으로 쓰기를 수행하여 RPO가 0이므로 데이터 손실은 없지만, 견고하고 지연 시간이 짧은 사이트 간 연결과 높은 운영 지연 시간을 포함한 복제 오버헤드가 증가합니다.
3개 사이트 또는 타이브레이커 설계를 적용한 2개 사이트를 구축하든, 스트레치 클러스터는 최소한의 운영 개입으로 전체 데이터 센터의 손실을 원활하게 처리할 수 있습니다. 그러나 엄격한 네트워킹 요구 사항(지연 시간과 대역폭 모두)과 복제 시 발생하는 높은 용량 오버헤드를 고려하는 것이 중요합니다 size=4. 지속적인 가용성과 제로 RPO가 최우선 순위인 중요 애플리케이션의 경우, 스트레치 클러스터를 위한 추가 계획 및 리소스는 투자 가치가 있을 수 있습니다. 예를 들어, 한 데이터 센터를 보관용으로만 사용하거나 성능이 저하된 재해 복구 사이트로 사용하는 경우, 용량 효율적인 삭제 코딩을 두 사이트 모두에 사용할 수 있으므로 비동기 복제가 매력적일 수 있습니다.
다음 게시물(이 시리즈의 2부)에서는 타이브레이커를 적용한 두 사이트 스트레치 클러스터를 살펴보겠습니다. 여러 데이터 센터에 Ceph를 설정하는 실제적인 단계를 제공하고, 필수적인 네트워크 및 하드웨어 고려 사항에 대해 논의합니다. 또한, 사양 파일을 사용하여 클러스터 부트스트랩을 자동화하는 방법을 시연하는 실습 배포를 수행합니다. CRUSH 규칙을 구성하고 스트레치 모드를 활성화하는 방법도 다룹니다.
저자는 이 게시물을 작성하는 데 시간을 할애하여 커뮤니티를 지원해 준 IBM에 감사드리고 싶습니다.
