3.3. 배치 그룹 상표

Ceph는 데이터의 영구 손실을 방지하기 위해 노력합니다. 그러나 OSD에 오류가 발생하면 데이터가 완전히 복구될 때까지 영구 데이터 손실 위험이 증가합니다. 영구 데이터 손실은 드문 경우지만 여전히 가능합니다. 다음 시나리오에서는 Ceph가 데이터의 복사본을 세 개 포함하는 단일 배치 그룹의 데이터를 영구적으로 잃을 수 있는 방법을 설명합니다.

하드웨어 실패는 예외가 아니라 기대입니다. 예정된 시나리오를 방지하기 위해 이상적으로 복구 프로세스는 합리적으로 가능한 한 빨리 수행되어야합니다. 클러스터 크기, 하드웨어 구성 및 배치 그룹 수는 총 복구 시간에 중요한 역할을 합니다.

Ceph가 나머지 150개 배치 그룹을 나머지 9개 OSD에 무작위로 저장했을 가능성이 높습니다. 따라서 남아 있는 각 OSD는 다른 모든 OSD에 오브젝트 복사본을 보내고, 나머지 OSD는 현재 할당된 150개 배치 그룹을 담당하므로 일부 새 오브젝트도 수신합니다.

총 복구 시간은 풀을 지원하는 하드웨어에 따라 다릅니다. 예를 들어 10개의 OSD 클러스터에서 호스트에 1TB SSD가 있는 하나의 OSD가 있고 10GB/s 스위치가 각각 10개의 호스트를 연결하는 경우 복구 시간은 M 분 정도 걸립니다. 반대로 호스트에 두 개의 SATA OSD가 포함되어 있고 1GB/s 스위치가 5개의 호스트를 연결하는 경우 복구 시간이 훨씬 더 오래 걸립니다. 흥미로운 점은 이러한 크기의 클러스터에서 배치 그룹의 수는 데이터 내구성에 거의 영향을 미치지 않습니다. 배치 그룹 수는 128 또는 8192 일 수 있으며 복구 속도가 느려지거나 빨라지지 않습니다.

그러나 10개의 OSD 대신 동일한 Ceph 클러스터를 20개의 OSD로 확장하면 복구 속도가 빨라지므로 데이터 내구성이 크게 향상될 수 있습니다. 이유가 무엇입니까? 각 OSD는 이제 150개 대신 75개의 배치 그룹에만 참여하고 있습니다. OSD 클러스터에서는 복구하기 위해 여전히 19개의 OSD가 모두 동일한 양의 복사 작업을 수행해야 합니다. 10개의 OSD 클러스터에서 각 OSD는 약 100GB를 복사해야 했습니다. 20개의 OSD 클러스터에서는 각각 OSD를 각각 50GB만 복사하면 됩니다. 네트워크가 병목 상태인 경우 복구 작업은 두 번 수행됩니다. 즉, OSD 수가 증가함에 따라 복구 시간이 단축됩니다.

위에서 설명한 10개의 OSD 클러스터에서 OSD가 실패하면 약 8개의 배치 그룹(즉, 복구되는 75개 pgs / 9 osds )은 단 하나의 복사만 갖습니다. 그리고 8개의 나머지 OSD 중 하나라도 실패하면 하나의 배치 그룹의 마지막 개체가 손실될 수 있습니다(즉, 남아 있는 사본 하나만 복구된 8 pgs / 8 osds ). 따라서 다소 큰 클러스터(예: 50개의 OSD)로 시작하는 것이 좋습니다.

클러스터 크기가 20개의 OSD로 확장되면 OSD 3개가 손실되어 배치 그룹 수가 손상됩니다. 손실된 두 번째 OSD는 8 대신 약 2(즉, 35 pgs / 19 osds 가 복구됨)가 저하되고 세 번째 OSD 손실은 분리 사본이 포함된 두 개의 OSD 중 하나인 경우에만 데이터를 잃게 됩니다. 즉, 복구 시간 프레임 중 하나의 OSD가 0.0001% 일 가능성이 있는 경우 클러스터의 8 * 0.0001% 에서 20개의 OSD가 있는 클러스터에서 2 * 0.0001% 로 이동합니다. 데이터 내구성과 관련하여 OSD가 50개 미만인 클러스터에서는 512개 또는 4096개의 배치 그룹이 거의 동일합니다.

OSD를 클러스터에 추가할 때 배치 그룹 및 오브젝트로 새 OSD를 채우는 데 시간이 오래 걸릴 수 있습니다. 그러나 오브젝트의 성능 저하는 없으며 OSD를 추가하면 데이터 내구성에 영향을 미치지 않습니다.

Ceph는 핫 스팟을 방지하기 위해 노력합니다. 즉, 일부 OSD는 다른 OSD보다 훨씬 많은 트래픽을 수신합니다. CRUSH는 배치 그룹에 오브젝트를 배치 그룹에 균등하게 할당하여 배치 그룹에 균등하게 할당되면 기본 OSD는 클러스터 전체에 균등하게 분산되고 네트워크 초과 서브스크립션 문제와 데이터 배포로 인해 개발할 수 없도록 오브젝트를 저장하는 것이 좋습니다.

NetNamespace는 각 오브젝트에 대한 배치 그룹을 계산하기 때문에 이 배치 그룹 내의 각 OSD에 저장되는 데이터 양을 알 수 없으므로 배치 그룹 수와 OSD 수 간의 비율이 데이터 배포에 상당한 영향을 미칠 수 있습니다.

예를 들어 3개의 복제본 풀에 10개의 OSD가 있는 배치 그룹이 한 개뿐인 경우 Ceph는 3개의 OSD를 사용하여 데이터를 저장하고 다른 방법으로는 데이터를 저장할 수 없습니다. 더 많은 배치 그룹을 사용할 수 있는 경우 CRUSH는 OSD에 개체를 균등하게 분산할 수 있습니다. CRUSH는 배치 그룹도 OSD에 균등하게 할당합니다.

OSD보다 배치 그룹이 2개 이상 있는 순서가 1개 이상인 경우 배포도 완료되어야 합니다. 예를 들어 OSD 3개, 10개의 OSD용 512개 또는 1024개의 배치 그룹에 대한 256개의 배치 그룹 등이 있습니다.

OSD와 배치 그룹 간의 비율은 일반적으로 오브젝트 스트라이핑과 같은 고급 기능을 구현하는 Ceph 클라이언트의 데이터 배포 문제를 해결합니다. 예를 들어 4TB 블록 장치는 4MB 개체로 분할될 수 있습니다.

CRUSH는 개체 크기를 고려하지 않기 때문에 OSD와 배치 그룹 간의 비율은 다른 경우에 균등한 데이터 배포를 처리하지 않습니다. librados 인터페이스를 사용하여 비교적 작은 오브젝트를 저장하고 일부 매우 큰 오브젝트로 인해 데이터 배포가 저하될 수 있습니다. 예를 들어, 10개의 OSD에서 1000개의 배치 그룹에 총 100만 개의 4K 개체가 균등하게 분배됩니다. 각 OSD에서 4GB / 10 = 400MB 를 사용합니다. 400MB 개체가 풀에 추가되면 개체가 배치된 배치 그룹을 지원하는 3개의 OSD는 400MB + 400MB = 800MB 로 채워지고 나머지 7개의 OSD는 400MB로만 사용됩니다.

각 배치 그룹의 경우 OSD 및 Ceph 모니터에는 항상 메모리, 네트워크 및 CPU, 복구 중에 더 많은 메모리가 필요합니다. 배치 그룹 내에서 개체를 클러스터링하여 이 오버헤드를 공유하는 것이 배치 그룹이 존재하는 주요 이유 중 하나입니다.

배치 그룹 수를 최소화하면 상당한 양의 리소스를 절약할 수 있습니다.