DAY 77 [ Ceph ] 기본 개념, 원리 및 아키텍처

머리말

컨테이너화 초기 단계에서는 Ceph를 컨테이너 저장소로 사용할 계획이다. 스토리지는 가상화의 어머니라고 하는데, 컨테이너에 비해 스토리지도 중요한 역할을 합니다.

컨테이너화된 스토리지로 Ceph를 선택한 이유는 다음과 같습니다.

나중에 수평적 확장을 촉진합니다.
Ceph는 패스트 스토리지, 오브젝트 스토리지, 파일 스토리지를 동시에 지원할 수 있으며, 컨테이너는 블록 스토리지를 사용하고 오브젝트 스토리지는 추후 OSS 서비스를 대체하는 용도로 사용될 예정이다.

위와 같은 이유로 Ceph 분산 스토리지를 채택하는 것이 좋은 선택이 될 것입니다. 컨테이너화의 첫 번째 단계는 스토리지에서 시작됩니다.

Ceph 공식 문서(중국어): http://docs.ceph.org.cn/start/intro/

세프 소개

클라우드 플랫폼용 Ceph 개체 스토리지 또는 블록 장치를 제공하거나 Ceph 파일 시스템을 배포하려는 경우 모든 Ceph 스토리지 클러스터의 배포는 단일 Ceph 노드, 네트워크 및 Ceph 스토리지 클러스터에서 시작됩니다.

Ceph 스토리지를 생성하려면 최소한 다음 서비스가 필요합니다.

Ceph 모니터
두 개의 OSD 데몬

Ceph 파일 시스템 클라이언트 실행 시 메타데이터 서버(Metadata Server)가 있어야 하며, Ceph를 파일 시스템으로 사용하는 시나리오는 많지 않아야 하며, 이번 컨테이너화 프로젝트는 파일 시스템 스토리지를 포함하지 않을 것이므로 깊이 파고들지 마시기 바랍니다.

Ceph OSD: Ceph OSD 데몬(Ceph OSD)의 기능은 데이터를 저장하고 데이터 복제, 복구, 백필, 재조정을 처리하고 다른 OSD 데몬의 하트비트를 확인하여 Ceph Monitors에 일부 모니터링 정보를 제공하는 것입니다. Ceph 클러스터가 2개의 복사본을 갖도록 설정된 경우 클러스터가 활성+클린 상태에 도달하려면 최소 2개의 OSD 데몬이 필요합니다(Ceph는 기본적으로 3개의 복사본을 갖지만 복사본 수를 조정할 수 있음).

Ceph는 OSD를 통해 데이터를 하나씩 저장하고 Ceph의 기본 OSD는 3이지만 수동으로 2로 설정할 수 있습니다. 데이터 저장을 실현하는 OSD 고가용성.

모니터: Ceph Monitor는 모니터 그래프, OSD 그래프, 배치 그룹(PG) 그래프 및 CRUSH 그래프를 포함하여 클러스터의 상태를 보여주는 다양한 그래프를 유지 관리합니다. Ceph는 모니터, OSD 및 PG에서 발생하는 모든 상태 변경의 기록 정보(에포크라고 함)를 유지합니다.

Monitor는 Ceph의 모니터로, Ceph가 데이터를 저장하면 각종 데이터 지표가 기록되어 표시된다. PG / CURSH가 무엇인지는 나중에 논의됩니다.

Ceph는 클라이언트 데이터를 스토리지 풀에 개체로 저장합니다. CRUSH 알고리즘을 사용하여 Ceph는 지정된 개체(Object)를 보유해야 하는 배치 그룹(PG)을 계산한 다음 배치 그룹을 보유하는 OSD 데몬 프로세스를 추가로 계산할 수 있습니다. CRUSH 알고리즘을 사용하면 Ceph 스토리지 클러스터가 동적으로 확장, 재조정 및 복구할 수 있습니다.

공식 문서는 Ceph의 원리를 한 문장으로 요약한 것이지만, Ceph를 처음 접하는 사람들에게는 단순히 육박하고 이해하기 어렵습니다. 몇 가지 키워드 요약: 개체, CRUSH 알고리즘, 배치 그룹(PG), 동적 확장

이 시점에서 Ceph의 전반적인 작동 원리가 무엇인지 이해해야 합니까? 그렇지 않으면 이 질문은 항상 우리를 둘러싸고 있을 것입니다.

Ceph Storage 원칙 소개

정보를 검색한 결과 Fat Brother가 작성한 기사가 매우 훌륭하고 반복해서 이해할 가치가 있음을 알았습니다. Ceph에 대한 Big talk - CRUSH

[다음 이론적 지식은 Fat Brother의 기사와 내 자신의 이해에서 나온 것입니다.]

먼저 질문이 제기됩니다. Ceph 클러스터에 데이터를 저장하려면 몇 단계를 거쳐야 합니까?

Ceph의 대답은 두 단계입니다.

공식 문서의 배치 그룹인 PG를 계산합니다.
OSD 계산

연산이 언급되니까 알고리즘이 있어야 하는데 그 알고리즘이 소위 CRUSH 인가요?

PG 계산

우선 Ceph의 규정을 명확히 할 필요가 있습니다. Ceph에서는 모든 것이 객체입니다. (공식 문서와 일치하는 객체가 여기에 언급되어 있습니다. 모든 것이 객체라는 것을 이해하는 것은 어렵지 않습니다. 파이썬처럼 모든 것이 객체입니다)

다음은 비디오, 사진, 텍스트 또는 기타 형식 파일 등 모든 것이 개체라는 예입니다.

비디오, 텍스트, 사진 등 어떤 형식의 데이터든 관계없이 Ceph는 일률적으로 객체로 간주하는데, 모든 데이터는 디스크에 저장된 바이너리 데이터이기 때문에 바이너리 데이터의 각 조각을 객체로 간주하고, 형식으로 구별하지 않습니다.

객체이기 때문에 객체에는 객체 이름이 있어야 합니다. 두 개체의 차이점은 개체 이름을 통해서입니다. 두 개체의 파일 이름이 같으면 어떻게 됩니까?

이제 첫 번째 질문은 Ceph 클러스터에 개체를 저장하는 데 몇 단계가 필요한가입니다.

알려진: Ceph 클러스터는 여러 서버로 구성되어 있습니다. 정확히 말하면 여러 개의 디스크로 구성되어 있으며 Ceph의 각 디스크는 OSD로 간주됩니다.

파일은 다음과 같이 단순화할 수 있습니다. OSD에 개체를 저장하는 데 얼마나 많은 단계가 필요합니까?

Ceph의 논리적 계층

객체를 저장하기 위해 Ceph는 논리적 계층, 즉 풀(Pool)을 구축하는데 이는 객체를 저장하기 위해 사용하는 가상화에서의 스토리지 풀과 마찬가지로 이해하기 어렵지 않다. 중국 장기 판 , 물체를 저장하는 과정은 체스 판에 참깨를 놓는 것과 유사합니다

그림과 같이 간단합니다.

즉, Pool은 체스판의 사각형과 유사한 여러 개의 PG(배치 그룹)로 나뉩니다. 모든 사각형은 전체 체스판을 형성합니다. 즉, 모든 PG는 Pool을 형성합니다.

이 두 다이어그램을 통해 요약할 수 있습니다. 파일은 객체이고 객체는 각 PG에 저장되며 여러 PG가 Pool을 구성합니다.

이제 문제가 다시 발생합니다. 개체가 저장할 PG를 어떻게 알 수 있습니까? 풀이 rbd라고 가정하고 총 256개의 PG가 있으며 각 PG의 번호는 0, 1, 2, 3, 4라고 합니다.

이 문제를 해결하려면 먼저 현재 무엇이 있는지 살펴보십시오.

다른 개체 이름
다른 PG 번호

Ceph의 첫 번째 알고리즘인 HASH를 소개합니다.

개체 이름이 bar 및 foo인 두 개체의 경우 해당 개체 이름을 계산하십시오.

해시('바') = 0x3E0A4162
해시('푸') = 0x7FE391A0
해시('바') = 0x3E0A4162

HASH 알고리즘은 가장 일반적으로 사용되는 알고리즘이어야 합니다.객체 이름을 HASH한 후 16진수 출력 값 문자열을 얻습니다. 즉, HASH를 통해 객체 이름을 숫자 문자열로 변환한 다음 첫 번째 줄을 위의 세 번째 줄이 같은 점은 무엇입니까? 의미는 동일한 개체 이름에 대해 계산된 결과는 항상 동일 하지만 HASH 알고리즘은 개체 이름에서 난수를 계산한다는 것입니다. 이 난수를 사용하여 이 난수를 총 PG 수(예: 256)로 나누고 나머지는 256개의 PG 중 하나인 1-256 사이여야 합니다.

공식：HASH('bar') % PG수

0x3E0A4162 % 0xFF ===> 0x62
0x7FE391A0 % 0xFF ===> 0xA0

위의 계산을 통해 object bar는 0x62번 PG에 저장되고 foo 객체는 0xA0번 PG에 저장된다. 개체 표시줄은 항상 PG 0x62에 저장됩니다! 개체 foo는 항상 PG 0xA0에 저장됩니다!

현재 개체가 PG에 저장되는 방식을 요약할 수 있습니다.

객체 이름에 대해 HASH를 수행하여 난수를 얻은 다음 이 난수를 사용하여 총 PG 수의 나머지를 가져옵니다.획득한 값은 1과 총 PG 수 사이에 있어야 하며 객체를 변경하는 데이터입니다. 이름은 이 PG에 영원히 저장됩니다.

따라서 오브젝트 이름이 정해져 있기 때문에 오브젝트가 데이터를 저장하는 PG도 정해져 있습니다.

여기서 의문점은 개체 데이터의 크기와 상관없이 개체 이름이 고유성을 결정하는가?

대답은 '예'입니다. 즉, Ceph는 개체의 실제 크기와 콘텐츠, 형식 형식을 구분하지 않고 개체 이름만 구분합니다.

여기 Ceph에 대한 설명이 더 있습니다. 사실 Ceph에는 여러 풀이 있고 각 풀에는 여러 개의 PG가 있습니다. 두 풀의 PG 번호가 같으면 Ceph에서는 어떻게 구분합니까? 그래서 Ceph 각 풀은 예를 들어 방금 rbd 풀에 숫자 0이 지정되고 다른 풀에 숫자 1이 지정되면 Ceph에서 실제 PG 번호가 구성됩니다 pool_id+.+PG_id. 이 PG에서 이 개체는 이 PG에 저장됩니다 . 다른 풀의 PG 이름은 다음과 같을 수 있습니다.bar0.62foo0.A01.12f, 2.aa1,10.aa1

Ceph의 물리적 계층

로직 레이어에서 Ceph의 PG에 파일이 어떻게 저장되는지는 이미 알려져 있는데, 간단히 말해서 오브젝트 이름을 해싱한 다음 전체 PG 개수 중 나머지를 취하여 나머지를 해당 PG에 저장한 후 저장하면 된다. 이 PG 배치 그룹의 데이터.

다음으로 Ceph의 물리적 계층을 살펴봅니다. 여러 대의 서버가 있고, 그 서버에는 여러 개의 디스크가 존재하는데 보통 Ceph는 디스크를 OSD(사실 OSD는 디스크를 관리하는 프로그램)로 간주하기 때문에 물리계층은 여러 개의 OSD로 구성된다. 개체를 디스크에 저장하려면 논리 계층에서 개체는 PG에 저장되므로 이제 작업은 PG와 OSD 사이의 터널을 여는 것입니다. PG는 개체 묶음과 나머지가 같은 조합과 동일합니다. PG는 개체의 이 부분을 패킹합니다. 이제 각 OSD에 많은 패키지를 균등하게 배치해야 합니다. 이것이 CRUSH 알고리즘이 수행하는 작업입니다. CRUSH는 PG -> OSD 매핑을 계산합니다 . 관계

이 시점에서 논리 계층의 개체에서 바로 지금 PG에 알고리즘을 추가하면 두 가지 공식을 요약할 수 있습니다.

풀 ID+HASH('객체 이름') % PG_num --> PG_ID
크러쉬(PG_ID) --> OSD

여기서는 HASH와 CRUSH 두 가지 알고리즘을 사용하는데 이 두 알고리즘의 차이점은 무엇인가요? 해당 OSD에 HASH(PG_ID)를 직접 사용할 수 없는 이유는 무엇입니까?

CURSH(PG_ID) ==> HASH(PG_ID) % OSD_num으로 변경 ==> OSD

다음은 Fat Brother의 추론입니다.

OSD가 끊긴 경우 OSD_num=1이면 모든 PG % OSD_num의 나머지 부분이 변경됩니다. 즉, 이 PG가 저장한 디스크가 변경되었습니다. 가장 간단한 설명은 이 PG의 데이터를 디스크에서 다른 디스크로의 우수한 스토리지 아키텍처는 디스크가 손상되었을 때 데이터 마이그레이션의 양을 최소화해야 합니다. CRUSH가 할 수 있습니다.
여러 복사본이 저장된 경우 여러 OSD 결과 출력을 원하고 HASH는 하나만 얻을 수 있지만 CRUSH는 원하는 수를 얻을 수 있습니다.
OSD의 수가 증가하면 OSD_num이 증가하여 OSD 간에 임의의 PG 이동이 발생하지만 CRUSH는 데이터가 새로 추가된 기계에 고르게 분산되도록 할 수 있습니다.

정리하자면 HASH 알고리즘은 1:1 매핑 관계에만 적합하고, 계산된 두 값은 변경할 수 없으므로 PG -> OSD 매핑 계산에는 적합하지 않습니다. 따라서 여기에서는 CRUSH 알고리즘을 소개합니다.

크러쉬 알고리즘

여기서는 CRUSH 소스 코드를 자세히 소개하기 위한 것이 아니라 예제를 통해 CRUSH 알고리즘을 이해하기 위한 것입니다.

먼저 해야 할 일을 봅시다:

기존 PG_ID를 OSD에 매핑하고 매핑 관계를 통해 PG를 디스크에 저장할 수 있습니다.
3개의 복사본을 저장하려는 경우 하나의 PG를 3개의 다른 OSD에 매핑할 수 있으며 3개의 OSD는 정확히 동일한 PG 콘텐츠를 저장합니다.

무엇이 있는지 봅시다:

서로 다른 PG_ID;
OSD에도 번호가 지정되어 있으면 다른 OSD_ID가 있습니다.
각 OSD의 가장 큰 차이점은 용량 즉, 4T 또는 800GB의 용량입니다. 각 OSD의 용량을 OSD의 무게라고 합니다. 4T의 무게는 4, 800G의 무게는 0.8, 즉 비트 단위의 T 값입니다.

이제 문제는 자체 가중치를 사용하여 PG_ID를 OSD에 매핑하는 방법으로 변환됩니다. 여기서는 CRUSH 알고리즘의 빨대 알고리즘을 직접 사용하는데, 복권으로 번역하면 직설적으로 말하면 가장 긴 복권을 뽑는다는 뜻입니다.여기서 복권은 OSD의 가중치를 말합니다.

그러면 매번 가장 큰 용량의 OSD를 선택할 수 없고 매분 가장 큰 OSD에 데이터를 저장할 수 있습니까? 따라서 선택하기 전에 이러한 OSD를 문지릅니다. 다음은 CRUSH 알고리즘에 대한 직접적인 소개입니다.

CRUSH_HASH( PG_ID, OSD_ID, r ) ===> 추첨
( 그리기 &0xffff ) * osd_weight ===> osd_straw
high_osd_straw를 집어들다

첫 번째 줄에서 r을 상수로 취급하고 첫 번째 줄은 실제로 러빙 작업을 수행합니다. PG_ID, OSD_ID 및 r을 함께 CRUSH_HASH의 입력으로 취하고 HASH(개체 이름 ) 두 개의 추가 입력을 제외하고는 정확히 동일합니다. 따라서 동일한 3개의 입력에 대해 계산된 draw값이 동일해야 한다는 점을 강조할 필요가 있습니다.

이것 의 용도는 무엇입니까 draw? 사실 CRUSH는 여기 있는 임의의 숫자를 얻은 draw다음 이 임의의 숫자에 OSD의 가중치를 곱하여 임의의 숫자와 OSD의 가중치를 함께 비벼서 실제 서명 길이를 얻기를 희망합니다. 각각의 OSD, 그리고 각각의 기호는 길이(확률이 높음)가 다르기 때문에 가장 긴 것을 고르기가 쉽습니다.

직설적으로 말하면, CRUSH는 随机OSD를 고르기를 희망하지만, 또한 OSD가 뽑힐 확률이 높을수록 더 큰 가중치로 OSD를 만족시켜야 한다. 여기에 난수를 곱한 다음 곱이 가장 큰 것을 취합니다. 그래서 여기서 우리는 작은 목표를 세웠습니다. 하나를 1억 번 고르세요! 거시적 관점에서 볼 때 난수를 곱하기도 합니다.샘플 크기가 충분히 커지면 난수는 더 이상 선택 결과에 영향을 미치지 않습니다.결정적인 영향은 OSD의 가중치 즉, OSD의 가중치가 클수록 매크로 관점에서 선택될 확률이 높아집니다.

위의 내용을 이해하지 못해도 상관 없습니다. 다음은 OSD를 선택할 때 PG가 수행하는 작업에 대한 간략한 요약입니다.

CRUSH_HASH의 입력으로 PG_ID를 제공합니다.
난수를 얻기 위한 CRUSH_HASH(PG_ID, OSD_ID, r)(HASH가 아니라 난수에 중점을 둡니다).
모든 OSD에 대해 가중치를 각 OSD_ID에 해당하는 난수로 곱하여 제품을 얻습니다.
제품이 가장 큰 OSD를 선택합니다.
PG가 OSD에 저장됩니다.

위의 설명을 통해 하나의 PG를 여러 OSD에 매핑하는 문제는 이미 풀 수 있으며, 상수 r은 r+1일 때 다시 난수를 계산한 후 각 OSD의 가중치를 곱한 다음 가장 큰 곱을 선택하면 OSD 번호가 이전 OSD 번호와 다른 경우 이를 선택합니다. 이전 OSD 번호와 같으면 r+2를 추가하고 필요한 3개의 다른 번호가 선택될 때까지 다시 임의의 번호를 선택합니다. OSD 지금까지 !

물론 실제 선택 과정은 조금 더 복잡하기 때문에 OSD 선택 시 CRUSH가 무엇을 하는지 가장 간단한 방법으로 설명하겠습니다.

CRUSH 알고리즘 적용

위의 CRUSH가 OSD를 선택하는 과정을 이해한 후 CRUSH 알고리즘을 실제 구조와 더 결합하는 것은 쉽습니다.다음은 Sage가 박사 학위 논문에서 그린 트리 구조 다이어그램입니다.

하단의 파란색 스트립은 호스트로, 내부의 회색 실린더는 OSD로, 보라색 캐비닛은 캐비닛으로, 녹색 행은 캐비닛 행으로, 상단의 루트는 우리 루트 노드는 실질적인 의미가 없으며 데이터 센터 또는 전산실로 생각할 수 있지만 트리 구조의 루트 노드 역할만 합니다.

이러한 OSD 선택 구조를 기반으로 다음과 같은 새로운 요구 사항을 제시합니다.

총 3개의 OSD가 선택되었습니다.
이 세 개의 OSD는 한 행 아래에 있어야 합니다.
각 캐비닛에는 최대 하나의 OSD가 있습니다.

이러한 요구 사항에 대해 이전 섹션에서 OSD를 선택하기 위해 CRUSH 방법을 사용하면 OSD의 분포가 무작위이기 때문에 두 번째 및 세 번째 요구 사항을 충족할 수 없습니다.

따라서 이러한 요구 사항을 완료하려면 먼저 무엇이 있는지 살펴보십시오.

각 OSD의 가중치
각 호스트는 또한 호스트의 모든 OSD의 가중치를 누적하여 얻은 가중치를 가질 수 있습니다.
각 캐비닛의 무게는 모든 호스트의 무게를 합산하여 얻습니다. 이는 실제로 이 캐비닛 아래에 있는 모든 OSD의 무게 합계입니다.
같은 방식으로 각 행의 무게는 캐비닛에 누적됩니다.
루트의 가중치는 실제로 모든 OSD 가중치의 합입니다.

따라서 이 트리 구조에서 각 노드는 고유한 가중치를 가지며, 각 노드의 가중치는 下一层노드들의 가중치를 합산하여 구하므로 루트 노드 루트의 가중치는 해당 노드 내의 모든 OSD 가중치의 합이 된다. 그렇다면 가중치가 너무 많은 경우 어떻게 이 세 가지 OSD를 선택해야 할까요?

CRUSH 방법에 따라 OSD를 선택합니다.

CRUSH는 루트 아래의 모든 행에서 행을 선택합니다.
크러쉬는 방금 전 행 아래의 모든 캐비닛 중에서 3개의 캐비닛을 선택했습니다.
지금 크러쉬는 3개의 캐비닛 아래에 있는 모든 OSD 중에서 각각 하나의 OSD를 선택합니다.

각 행마다 가중치가 있으므로 CRUSH로 행을 선택하는 방법은 OSD를 선택하는 방법과 완전히 동일하며 행의 가중치에 임의의 숫자를 곱하여 최대값을 얻습니다. 그런 다음 이 행 아래에서 세 개의 캐비닛을 계속 선택한 다음 각 캐비닛 아래에서 OSD를 선택합니다.

이것의 근본적인 의미는 데이터가 클러스터의 모든 OSD에 고르게 분산되어 있다는 것입니다.두 시스템의 가중치가 16:32이면 두 시스템에 분산된 데이터의 양도 1:2입니다. 동시에 이 선택은 세 개의 다른 캐비닛에 분산된 세 개의 OSD를 만들었습니다.

그런 다음 범례와 결합하여 CRUSH 알고리즘의 흐름은 다음과 같습니다.

take(루트) ============> [루트]
선택(1, 행) ========> [행2]
choose(3, 캐비닛) =====> [row2] 아래의 [ cab21, cab23, cab24]
choose(1, osd) ========> [osd2107, osd2313, osd2437] 3개의 택시 아래
방출 ================> [osd2107, osd2313, osd2437]

다음은 CRUSH 알고리즘의 두 가지 중요한 개념입니다.

BUCKET/OSD: OSD는 우리의 디스크에 하나씩 대응하고 버킷은 캐비닛, 행, 루트 등과 같이 OSD를 제외한 모든 비자식 노드입니다.
RULE: CRUSH 선택은 선택 경로를 따르며 선택 경로는 규칙입니다.

RULE은 일반적으로 테이크 -> N 선택 -> 방출의 세 단계로 나뉩니다.

Take 단계는 루트 노드를 선택하는 역할을 하며, 이 루트 노드는 루트일 필요는 없지만 모든 Bucket이 될 수 있습니다.

choose N이 하는 일은 각 Bucket과 각 choose 문의 가중치에 따라 자격을 갖춘 Bucket을 선택하는 것이며, 다음 choose의 선택 대상은 이전 단계에서 얻은 결과입니다.

emit은 최종 결과를 출력하는 것으로 스택을 팝하는 것과 같습니다.

세프 아키텍처

위의 원리에 대한 이해를 통해 아래 그림의 Ceph 아키텍처를 쉽게 이해할 수 있습니다.

위에서 아래로:

1. Ceph는 4개의 외부 인터페이스를 제공합니다.

응용 프로그램은 자체 개발에 적합한 자체 개발 호출 인터페이스가 필요한 RADOS에 직접 액세스합니다.
개체 스토리지 인터페이스, (Amazon) S3 및 Swift 호출 방법 지원, 사진, 비디오 등과 같은 개체 스토리지 저장에 적합
블록 스토리지 인터페이스(RBD)는 주로 가상 머신용 블록 디바이스 스토리지와 같은 외부 블록 스토리지를 제공합니다.
파일 스토리지(CephFS)는 NFS 마운트 디렉토리 스토리지와 유사합니다.

2. 애플리케이션 직접 액세스, 객체 스토리지 및 블록 스토리지는 모두 LibRados 라이브러리 파일에 의존합니다.

3. Ceph의 최하층은 RADOS 오브젝트 스토리지 시스템으로 RADOS 오브젝트 스토리지 시스템을 통해 외부 서비스를 제공한다.

4. MDS 메타데이터 노드, MON 관리 제어 노드, 많은 풀 스토리지 풀

5. Pool 스토리지 풀에는 많은 PG 배치 그룹이 포함되어 있으며, PG의 데이터는 CRUSH 알고리즘을 통해 각 OSD 그룹에 저장됩니다.

위의 단계에서 5번 항목에 집중해야 합니다. 위에서 언급했듯이 Ceph에서는 모든 것이 객체입니다. 먼저 HASH 알고리즘을 통해 개체 이름을 전달하여 16진수를 얻은 다음 Pool의 총 PG 수에서 나머지를 가져옵니다. 나머지는 총 PG 수 중 노드에 있어야 하며 Ceph는 이 PG에서 객체 이름의 데이터는 CRUSH_HASH(PG_ID, OSD_ID, r)로 값을 계산하여 데이터를 OSD에 드롭할 수 있으며 Ceph에서 OSD는 디스크와 동의어입니다. 이 프로세스는 그래픽으로 표시됩니다.

Ceph 기능 및 핵심 구성 요소

세프 기능:

고성능

CRUSH 알고리즘을 사용하여 기존의 중앙 집중식 스토리지 메타 데이터 주소 지정 방식을 버리고 데이터 분포가 균형을 이루며 병렬도가 높습니다.
재해 복구 도메인의 격리를 고려하여 다양한 로드에 대한 복제본 배치 규칙을 구현할 수 있습니다.
수천 개의 스토리지 노드 규모를 지원하고 TB에서 PB 수준의 데이터를 지원할 수 있습니다.

고가용성

사본 수는 유연하게 제어할 수 있습니다.
장애 도메인 분리 및 강력한 데이터 일관성을 지원합니다.
다양한 오류 시나리오에서 자동 수리 및 자가 치유
단일 장애 지점이 없으며 자동으로 관리됩니다.

높은 확장

기본 분산 분산화;
유연한 확장;
노드 수에 따라 선형적으로 증가합니다.

풍부한 기능

세 가지 스토리지 인터페이스 지원: 블록 스토리지, 오브젝트 스토리지 및 파일 스토리지
사용자 정의 인터페이스를 지원하고 여러 언어를 지원합니다.

핵심 구성 요소:

감시 장치

Ceph 클러스터에는 OSD 메타데이터를 저장하기 위해 여러 모니터의 작은 클러스터가 필요합니다.

OSD

OSD의 전체 이름은 클라이언트 요청에 대한 응답으로 특정 데이터를 반환하는 프로세스인 개체 저장 장치입니다. 일반적으로 Ceph 클러스터에는 많은 OSD가 있으며 최종 Ceph 데이터도 OSD에 의해 디스크에 저장됩니다.

MDS

MDS의 전체 이름은 CephFS 서비스가 의존하는 메타데이터 서비스인 Ceph Metadata Server입니다. 파일 저장소를 사용하지 않는 경우 설치가 필요하지 않습니다.

물체

Ceph 하단의 저장 단위는 Object 객체이며 각 Object에는 메타 데이터와 원본 데이터가 포함됩니다.

PG의 전체 이름은 배치 그룹(Placement Groups)이며 논리적 개념입니다.PG에는 여러 OSD가 포함됩니다. PG 계층을 도입하는 목적은 데이터를 더 잘 할당하고 찾는 것입니다.

만들어진

RADOS의 전체 이름은 Ceph 클러스터의 핵심인 Reliable Autonomic Distributed Object Store이며 사용자는 데이터 분산, 장애 조치 및 기타 클러스터 작업을 구현할 수 있습니다.

리브라듐

Librados는 Rados에서 제공하는 라이브러리입니다.RADOS는 직접 접근하기 어려운 프로토콜이기 때문에 상위 계층인 RBD, RGW, CephFS는 모두 librados를 통해 접근합니다.현재 PHP, Ruby, Java, Python, C, C++ 지원됩니다.

으깨다

CRUSH는 일관된 해싱과 유사한 Ceph에서 사용하는 데이터 분산 알고리즘으로 데이터가 예상되는 위치에 분산되도록 합니다.

RBD

RBD의 전체 이름은 RADOS 블록 장치로 Ceph에서 제공하는 블록 장치 서비스입니다.

RGW

RGW의 정식 명칭은 RADOS 게이트웨이로 Ceph에서 제공하는 오브젝트 스토리지 서비스로 S3, Swift와 호환되는 인터페이스로 오브젝트 스토리지를 사용하지 않는 경우 설치할 필요가 없습니다.

CephFS

CephFS의 전체 이름은 Ceph에서 제공하는 파일 시스템 서비스인 Ceph File System입니다.