아키텍처 가이드

Ceph 스토리지 클러스터는 데이터 오브젝트를 'Pools'라는 논리 파티션에 저장합니다. Ceph 관리자는 블록 장치, 오브젝트 게이트웨이 등의 특정 유형의 데이터에 대한 풀을 생성하거나 한 사용자 그룹을 다른 사용자 그룹과 분리할 수 있습니다.

Ceph 클라이언트의 관점에서 보면 스토리지 클러스터는 매우 간단합니다. Ceph 클라이언트가 I/O 컨텍스트를 사용하여 데이터를 읽거나 쓰는 경우 항상 Ceph 스토리지 클러스터의 스토리지 풀에 연결됩니다. 클라이언트는 풀 이름, 사용자 및 시크릿 키를 지정하므로 풀은 해당 data 오브젝트에 대한 액세스 제어를 사용하여 논리 파티션 역할을 합니다.

실제로 Ceph 풀은 오브젝트 데이터를 저장하기 위한 논리 파티션일 뿐만 아니라 풀은 Ceph 스토리지 클러스터가 데이터를 배포하고 저장하는 방법에 중요한 역할을 합니다. 그러나 이러한 복잡한 작업은 Ceph 클라이언트에 완전히 투명합니다.

Ceph 풀은 다음을 정의합니다.

또한 CRUSH를 사용하면 클라이언트가 SSD, SSD 저널이 있는 하드 드라이브 또는 데이터와 동일한 드라이브에 저널이 있는 하드 드라이브와 같은 특정 유형의 하드웨어에 데이터를 쓸 수 있습니다. CRUSH 규칙 세트는 풀의 장애 도메인 및 성능 도메인을 결정합니다. 관리자는 풀을 생성할 때 CRUSH 규칙 세트를 설정합니다.

클라이언트 관점에서 Ceph는 간단하고 간단합니다. 클라이언트는 단순히 풀에서 읽고 쓰기만 하면 됩니다. 그러나 풀은 데이터 지속성, 성능 및 고가용성에 중요한 역할을 합니다.

사용자를 식별하고 중간자 공격으로부터 보호하기 위해 Ceph는 사용자와 데몬을 인증하는 cephx 인증 시스템을 제공합니다.

cephx는 인증에 공유 시크릿 키를 사용합니다. 즉, 클라이언트와 모니터 클러스터에 모두 클라이언트의 시크릿 키 사본이 있습니다. 인증 프로토콜을 사용하면 두 당사자가 실제로 공개하지 않고 키 복사본이 있음을 증명할 수 있습니다. 이는 클러스터가 사용자가 시크릿 키를 소유하고 있는지 확인하고 클러스터에 시크릿 키 사본이 있는지 확인하는 상호 인증을 제공합니다.

사용자/actor는 Ceph 클라이언트를 호출하여 모니터에 연결합니다. Kerberos와 달리 각 모니터는 사용자를 인증하고 키를 배포할 수 있으므로 cephx 를 사용할 때 단일 장애 지점이나 병목 현상이 발생하지 않습니다. 모니터는 Ceph 서비스를 가져오는 데 사용할 세션 키가 포함된 Kerberos 티켓과 유사한 인증 데이터 구조를 반환합니다. 이 세션 키는 사용자의 영구 시크릿 키를 사용하여 자체적으로 암호화되므로 사용자만 Ceph 모니터에서 서비스를 요청할 수 있습니다. 그런 다음 클라이언트는 세션 키를 사용하여 모니터에서 원하는 서비스를 요청하고 모니터는 고객에게 실제로 데이터를 처리하는 OSD에 클라이언트를 인증하는 티켓을 제공합니다. Ceph 모니터 및 OSD는 시크릿을 공유하므로 클라이언트는 클러스터의 OSD 또는 메타데이터 서버와 함께 모니터에서 제공하는 티켓을 사용할 수 있습니다. Kerberos와 마찬가지로 cephx 티켓은 만료되므로 공격자는 만료된 티켓 또는 세션 키를 과도하게 사용할 수 없습니다. 이러한 형태의 인증으로 인해 통신 매체에 대한 액세스 권한이 있는 공격자가 다른 사용자의 ID에 따라 bogus 메시지를 생성하거나 사용자의 비밀 키가 만료되기 전에 공개되지 않는 한 다른 사용자의 합법적인 메시지를 변경하는 것을 방지할 수 있습니다.

cephx 를 사용하려면 관리자가 먼저 사용자를 설정해야 합니다. 다음 다이어그램에서 client.admin 사용자는 명령줄에서 ceph auth get-or-create-key 를 호출하여 사용자 이름 및 시크릿 키를 생성합니다. Ceph의 auth 하위 시스템은 사용자 이름과 키를 생성하고 모니터가 있는 복사본을 저장하고 사용자의 시크릿을 client.admin 사용자로 다시 전송합니다. 즉, 클라이언트와 모니터는 시크릿 키를 공유합니다.

클러스터에 수백만 개의 오브젝트를 저장하고 개별적으로 관리하는 것은 리소스 집약적입니다. 따라서 Ceph는 배치 그룹(PG)을 사용하여 대규모 오브젝트를 보다 효율적으로 관리합니다.

PG는 개체 컬렉션을 포함하는 데 사용되는 풀의 하위 집합입니다. Ceph는 풀을 일련의 PG로 분할합니다. 그런 다음 CRUSH 알고리즘은 클러스터 맵과 클러스터의 상태를 고려하여 PG를 균등하게 및 의사 무작위로 클러스터의 OSD에 배포합니다.

이것이 작동하는 방식은 다음과 같습니다.

시스템 관리자가 풀을 생성할 때 CRUSH는 사용자가 정의한 풀 PG 수를 생성합니다. 일반적으로 PG 수는 데이터의 합리적으로 세분화된 하위 집합이어야 합니다. 예를 들어 풀당 OSD당 100개의 PG는 각 PG가 풀 데이터의 약 1%를 차지함을 의미합니다.

Ceph가 하나의 OSD에서 다른 OSD로 PG를 이동해야 하는 경우 PG 수가 성능에 영향을 미칩니다. 풀에 PG가 너무 적으면 Ceph는 많은 양의 데이터를 동시에 이동하고 네트워크 로드는 클러스터 성능에 부정적인 영향을 미칩니다. 풀에 PG가 너무 많은 경우 Ceph는 데이터의 백분율을 낮게 이동할 때 CPU와 RAM을 너무 많이 사용하므로 클러스터 성능에 부정적인 영향을 미칩니다. 최적의 성능을 얻기 위해 PG 수를 계산하는 방법에 대한 자세한 내용은 배치 그룹 수 를 참조하십시오.

Ceph는 오브젝트의 복제본을 저장하거나 오브젝트의 삭제 코드 청크를 저장하여 데이터 손실을 방지합니다. Ceph는 PG 내에 오브젝트 또는 삭제 코드 청크를 저장하므로, Ceph는 각 PG를 오브젝트 복사본 또는 오브젝트의 각 삭제 코드 청크에 대해 "Acting Set"이라고 하는 OSD 세트에 복제합니다. 시스템 관리자는 풀의 PG 수와 복제본 또는 삭제 코드 청크 수를 결정할 수 있습니다. 그러나 CRUSH 알고리즘은 특정 PG에 대해 설정된 OSD를 계산합니다.

CRUSH 알고리즘과 PG는 Ceph 동적입니다. 클러스터 맵 또는 클러스터 상태를 변경하면 Ceph가 하나의 OSD에서 다른 OSD로 PG를 자동으로 이동할 수 있습니다.

다음은 몇 가지 예입니다.

Ceph 스토리지 클러스터는 수백 ~ 수천 개의 PG 환경에서 수백만 개의 오브젝트를 관리함으로써 장애를 효율적으로 확장, 축소 및 복구할 수 있습니다.

Ceph 클라이언트의 경우 librados 를 통한 CRUSH 알고리즘을 사용하면 오브젝트를 읽고 쓰는 프로세스가 매우 간단합니다. Ceph 클라이언트는 개체를 풀에 작성하거나 풀에서 오브젝트를 읽기만 하면 됩니다. 작동 중인 세트의 기본 OSD는 오브젝트의 복제본 또는 오브젝트 삭제 코드 청크를 Ceph 클라이언트를 대신하여 작업 세트의 보조 OSD에 작성할 수 있습니다.

클러스터 맵 또는 클러스터 상태가 변경되면 PG를 저장하는 OSD의 CRUSH 계산도 변경됩니다. 예를 들어 Ceph 클라이언트는 오브젝트 foo 를 풀 바에 작성할 수 있습니다. CRUSH는 PG 1.a 에 오브젝트를 할당하고 OSD 5 에 저장하므로 OSD 10 및 OSD 15 의 복제본을 각각 생성합니다. OSD 5 가 실패하면 클러스터 상태가 변경됩니다. Ceph 클라이언트가 pool bar 에서 오브젝트 foo 를 읽을 때 librados 를 통해 클라이언트는 새 기본 OSD로 OSD 10 에서 자동으로 검색합니다.

librados 를 통해 Ceph 클라이언트는 오브젝트를 작성하고 읽을 때 작동 세트 내의 기본 OSD에 직접 연결합니다. I/O 작업은 중앙 집중식 브로커를 사용하지 않기 때문에 일반적으로 네트워크 초과 서브스크립션은 Ceph의 문제가 아닙니다.

다음 다이어그램에서는 CRUSH가 PG에 오브젝트를 할당하고 PG를 OSD에 할당하는 방법을 보여줍니다. CRUSH 알고리즘은 작동 세트의 각 OSD가 별도의 장애 도메인에 있도록 OSD에 PG를 할당합니다. 이는 일반적으로 OSD가 항상 별도의 서버 호스트에 있고 경우에 따라 별도의 랙에 있어야 함을 의미합니다.

Ceph는 CRUSH 규칙 세트를 풀에 할당합니다. Ceph 클라이언트가 풀에 데이터를 저장하거나 검색하는 경우 Ceph는 규칙 세트 내의 규칙 및 데이터를 저장하고 검색하는 규칙의 CRUSH 규칙, CRUSH 규칙 집합을 식별합니다. Ceph는 CRUSH 규칙을 처리하면 오브젝트의 배치 그룹이 포함된 기본 OSD를 식별합니다. 이를 통해 클라이언트는 OSD에 직접 연결하고 배치 그룹에 액세스하여 개체 데이터를 읽거나 쓸 수 있습니다.

배치 그룹을 OSD에 매핑하기 위해 CRUSH 맵은 계층적 버킷 유형 목록을 정의합니다. 버킷 유형 목록은 생성된 CRUSH 맵의 유형에 있습니다. 버킷 계층 구조를 생성하는 목적은 드라이브 유형, 호스트, 섀시, 랙, 전원 배포 단위, Pod, 행, 행, 데이터 센터와 같은 장애 도메인 및/또는 성능 도메인으로 리프 노드를 분리하는 것입니다.

OSD를 나타내는 리프 노드를 제외하고 나머지 계층 구조는 임의의 것입니다. 기본 유형이 요구 사항에 맞지 않는 경우 관리자는 자체 요구에 따라 정의할 수 있습니다. CRUSH는 일반적으로 계층 구조에서 Ceph OSD 노드를 모델링하는 대상 순환 그래프를 지원합니다. 따라서 Ceph 관리자는 단일 CRUSH 맵에서 여러 루트 노드가 있는 여러 계층을 지원할 수 있습니다. 예를 들어 관리자는 고성능을 위해 높은 비용 SSD를 나타내는 계층과 중간 성능을 위해 SSD 저널을 사용하여 더 낮은 하드 드라이브 계층 구조를 생성할 수 있습니다.

Ceph 클라이언트는 Ceph 모니터에서 '클러스터 맵'을 검색하고 풀에 바인딩하고 풀에 있는 배치 그룹 내의 오브젝트에 I/O(입력/출력)를 수행합니다. 풀의 CRUSH 규칙 세트와 배치 그룹 수는 Ceph에서 데이터를 배치하는 주요 요인입니다. 최신 버전의 클러스터 맵을 통해 클라이언트는 클러스터의 모든 모니터와 OSD와 현재 상태를 알고 있습니다. 그러나 클라이언트는 개체 위치에 대해 아무것도 알 수 없습니다.

클라이언트에 필요한 유일한 입력은 오브젝트 ID와 풀 이름입니다. Ceph는 단순합니다. 즉, Ceph는 이름이 지정된 풀에 데이터를 저장합니다. 클라이언트가 풀에 이름이 지정된 개체를 저장하려는 경우 개체 이름, 해시 코드, 풀의 PG 수 및 풀 이름을 입력으로 사용하고 CRUSH(Controlled Replication Under Scalable Hashing)는 배치 그룹의 ID와 배치 그룹의 기본 OSD를 계산합니다.

Ceph 클라이언트는 다음 단계를 사용하여 PG ID를 계산합니다.

Ceph 스토리지 클러스터의 토폴로지 및 상태는 세션 중에 상대적으로 안정적입니다. librados 를 통해 개체 위치를 계산하도록 Ceph 클라이언트의 강화는 클라이언트가 각 읽기/쓰기 작업에 대한 채팅 세션을 통해 스토리지 클러스터에 쿼리해야 하는 것보다 훨씬 빠릅니다. CRUSH 알고리즘을 사용하면 클라이언트가 오브젝트를 저장해야 하는 위치를 계산하고 클라이언트가 동작 세트의 기본 OSD에 직접 연결하여 개체의 데이터를 직접 저장하거나 검색할 수 있습니다. 엑사바이트 규모의 클러스터에는 수천 개의 OSD가 있으므로 클라이언트와 Ceph OSD 간의 네트워크 초과 구독은 큰 문제가 아닙니다. 클러스터 상태가 변경되면 클라이언트는 Ceph 모니터에서 클러스터 맵 업데이트를 간단히 요청할 수 있습니다.

Ceph 클라이언트와 마찬가지로 Ceph OSD는 Ceph 모니터에 연결하여 클러스터 맵의 최신 사본을 검색할 수 있습니다. Ceph OSD는 CRUSH 알고리즘도 사용하지만 오브젝트 복제본을 저장할 위치를 계산하는 데 사용합니다. 일반적인 쓰기 시나리오에서 Ceph 클라이언트는 CRUSH 알고리즘을 사용하여 개체의 Acting Set의 배치 그룹 ID와 기본 OSD를 계산합니다. 클라이언트가 개체를 기본 OSD에 쓸 때 기본 OSD는 저장해야 하는 복제본 수를 찾습니다. 값은 osd_pool_default_size 설정에 있습니다. 그런 다음 기본 OSD는 오브젝트 ID, 풀 이름 및 클러스터 맵을 사용하고 CRUSH 알고리즘을 사용하여 작동 세트에 대한 보조 OSD의 ID를 계산합니다. 기본 OSD는 개체를 보조 OSD에 씁니다. 기본 OSD에서 보조 OSD에서 승인을 수신하고 기본 OSD 자체에서 쓰기 작업을 완료하면 Ceph 클라이언트에 대한 쓰기 작업을 성공적으로 확인합니다.

Ceph 클라이언트를 대신하여 데이터 복제를 수행할 수 있는 기능을 통해 Ceph OSD 데몬은 Ceph 클라이언트가 이러한 의무를 완화하는 동시에 높은 데이터 가용성 및 데이터 보안을 보장합니다.

삭제 코딩된 풀에서 Ceph는 성능이 저하된 상태에서 작동할 수 있도록 여러 OSD에 오브젝트 청크를 저장해야 합니다. 복제 풀과 유사하게 삭제 코딩된 풀을 사용하면 Ceph 클라이언트가 성능 저하된 상태를 읽고 쓸 수 있습니다.

Ceph는 많은 삭제 코드 알고리즘 중 하나를 로드할 수 있습니다. 가장 빠르고 일반적으로 사용되는 것은 Reed-Solomon 알고리즘입니다. 삭제 코드는 실제로 FEC(전방향 오류 수정) 코드입니다. FEC 코드는 K 청크의 메시지를 N 청크의 '코드 단어'라는 긴 메시지로 변환하여 Ceph가 N 청크의 하위 집합에서 원래 메시지를 복구할 수 있습니다.

특히, 변수 K 가 데이터 청크의 원래 양인 N = K+M 입니다. 변수 M 은 삭제 코드 알고리즘이 실패로부터 보호하기 위해 추가하는 추가 또는 중복 청크를 나타냅니다. 변수 N 은 삭제 코딩 프로세스 후에 생성된 총 청크 수입니다. M 값은 간단히 N- K 이므로 알고리즘이 K 원래 데이터 청크에서 N-K 중복 청크를 계산합니다. 이 접근 방식을 통해 Ceph는 모든 원본 데이터에 액세스할 수 있습니다. 시스템은 임의의 N-K 오류에 탄력적입니다. 예를 들어, 10 K 의 16 N 구성 또는 삭제 코딩 10/16 에서 삭제 코드 알고리즘은 10 기본 청크 K 에 6 개의 추가 청크를 추가합니다. 예를 들어 M = K-N 또는 16-10 = 6 구성에서 Ceph는 16 OSD에 16 청크 N 을 분배합니다. Red Hat Ceph Storage 클러스터가 데이터를 손실하지 않도록 하는 6개의 OSD가 실패하는 경우에도 10개의 확인된 N 청크에서 원본 파일을 재구성할 수 있으므로 내결함성이 매우 높습니다.

복제 풀과 마찬가지로 삭제 코드 풀의 기본 OSD는 모든 쓰기 작업을 수신합니다. 복제 풀에서 Ceph는 세트의 보조 OSD의 배치 그룹에 있는 각 오브젝트의 깊은 복사본을 만듭니다. 삭제 코딩의 경우 프로세스는 약간 다릅니다. 삭제 코딩 풀은 각 오브젝트를 K+M 청크로 저장합니다. K 데이터 청크와 M 코딩 청크로 나뉩니다. Ceph가 작동 중인 세트의 OSD에 각 청크를 저장할 수 있도록 풀은 크기가 K+M 으로 구성됩니다. Ceph는 청크의 순위를 오브젝트의 속성으로 저장합니다. 기본 OSD는 페이로드를 K+M 청크로 인코딩하여 다른 OSD로 전송합니다. 기본 OSD는 배치 그룹 로그의 권한 있는 버전을 유지 관리해야 합니다.

예를 들어 일반적인 구성에서 시스템 관리자는 6개의 OSD를 사용하고 두 개의 OSD를 유지하기 위해 삭제 코딩 풀을 생성합니다. 즉 (K+M =6) 이러한 (M = 2)입니다.

Ceph가 Cryostat DEFHIJKL 을 포함하는 개체를 풀에 쓸 때, 삭제 인코딩 알고리즘은 단순히 content를 네 부분으로 나누어서 4개의 데이터 청크로 분할합니다. 즉,DEF, DEF , JKL. 블록 길이가 K 의 배수가 아닌 경우 알고리즘은 콘텐츠를 패딩합니다. 이 함수는 또한 두 개의 코딩 청크를 생성합니다: YXY 를 사용한 다섯 번째와 QGC 의 여섯 번째. Ceph는 작동 세트의 OSD에 각 청크를 저장합니다. 여기서 이름이 같은 오브젝트인 object에 청크를 저장하지만 다른 OSD에 있습니다. 알고리즘은 청크를 생성한 순서와 shard_t의 이름 외에도 오브젝트 shard_t 의 특성으로 유지해야 합니다. 예를 들어 Chunk 1에는 Cryostat 및 Ceph가 OSD5 에 저장되어 있고 청크 5에는 YXY 가 포함되어 있고 Ceph가 OSD4 에 저장되어 있습니다.

복구 시나리오에서 클라이언트는 삭제 코딩된 풀에서 청크 1 에서 6까지의 오브젝트를 읽으려고 합니다. OSD는 청크 2 및 6이 누락되었음을 알고리즘에 알립니다. 이러한 누락된 청크를 'erasures'라고 합니다. 예를 들어 OSD6 이 사용 중이므로 기본 OSD에서 청크 6을 읽을 수 없으며 OSD2 가 가장 느리고 청크를 고려하지 않았기 때문에 청크 2를 읽을 수 없었습니다. 그러나 알고리즘에 4개의 청크가 있는 즉시 4개의 청크를 읽습니다. 즉, Cryostat를 포함하는 청크 1, Cryostat I 를 포함하는 청크 3, JKL 을 포함하는 청크 4, YXY 가 포함된 청크 5. 그런 다음 object Cryostat DEFGHIJKL 의 원본 내용과 QGC 가 포함된 청크 6의 원본 콘텐츠를 다시 빌드합니다.

데이터를 청크로 분할하는 것은 오브젝트 배치와 독립적입니다. CRUSH 규칙 세트는 erasure-coded pool 프로파일과 함께 OSD에서 청크 배치를 결정합니다. 예를 들어 삭제 코드 프로파일에서 로컬 복구 가능한 코드(lrc) 플러그인을 사용하면 추가 청크가 생성되고 복구하기 위해 OSD 수가 줄어듭니다. 예를 들어 lrc 프로파일 구성 K=4 M=2 L=3 에서 알고리즘은 jerasure 플러그인과 마찬가지로 6개의 청크(K+M)를 생성하지만, 지역성 값(L=3)은 알고리즘이 2개의 청크를 로컬에서 생성해야 합니다. 알고리즘은 (K+M)/L 과 같은 추가 청크를 생성합니다. 청크 0이 포함된 OSD가 실패하면 청크 1, 2 및 첫 번째 로컬 청크를 사용하여 이 청크를 복구할 수 있습니다. 이 경우 알고리즘은 5 대신 복구용 청크 3개만 필요합니다.

MSR은 "Multi-Step Retry (MSR)"의 약어입니다. Ceph 클러스터의 CRUSH 규칙으로, 스토리지 장치에 데이터가 분산된 방법을 정의하여 효율적인 데이터 검색, 분산 및 내결함성을 보장합니다.

ObjectStore 는 OSD의 원시 블록 장치에 하위 수준 인터페이스를 제공합니다. 클라이언트가 데이터를 읽거나 쓸 때 ObjectStore 인터페이스와 상호 작용합니다. Ceph 쓰기 작업은 기본적으로 ACID 트랜잭션입니다. 즉, Atomicity,Consistency,Isolation 및 Durability 를 제공합니다. ObjectStore 는 Atomicity 를 제공하기 위해 트랜잭션이 all-or-nothing임을 보장합니다. ObjectStore 는 오브젝트 의미 체계도 처리합니다. 스토리지 클러스터에 저장된 오브젝트에는 고유 식별자, 오브젝트 데이터 및 메타데이터가 있습니다. 따라서 ObjectStore 는 Ceph 오브젝트 의미 체계가 올바른지 확인하여 일관성 을 제공합니다. ObjectStore 는 또한 쓰기 작업에서 Sequencer 를 호출하여 Ceph 쓰기 작업이 순차적으로 발생하도록 ACID 트랜잭션의 격리 부분을 제공합니다. 반대로 OSD 복제 또는 삭제 코딩 기능은 ACID 트랜잭션의 Durability 구성 요소를 제공합니다. ObjectStore 는 스토리지 미디어에 대한 하위 수준 인터페이스이므로 성능 통계도 제공합니다.

Ceph는 데이터를 저장하기 위한 몇 가지 구체적인 방법을 구현합니다.

관리자는 일반적으로 BlueStore 만 주소이므로 다음 섹션에서는 이러한 구현을 보다 자세히 설명합니다.

BlueStore 는 Ceph의 현재 스토리지 구현입니다. k/v 데이터베이스에 대해 작은 파티션에서 매우 간단한 BlueFS 파일 시스템을 사용하고, 배치 그룹을 나타내는 디렉터리, 메타데이터를 나타내는 오브젝트 및 파일 XATTR을 나타내는 파일의 패러다임을 제거합니다.

BlueStore 는 다음과 같이 데이터를 저장합니다.

Ceph 클러스터는 많은 자체 모니터링 및 관리 작업을 자동으로 수행합니다. 예를 들어 Ceph OSD는 클러스터 상태를 확인하고 Ceph 모니터에 다시 보고할 수 있습니다. CRUSH를 사용하여 OSD 세트에 개체를 배치 그룹 및 배치 그룹에 할당함으로써 Ceph OSD는 CRUSH 알고리즘을 사용하여 클러스터를 재조정하거나 OSD 오류를 동적으로 복구할 수 있습니다.

Ceph OSD는 클러스터에 가입하고 해당 상태의 Ceph 모니터에 보고합니다. 가장 낮은 수준에서 Ceph OSD 상태는 실행 중인지와 Ceph 클라이언트 요청을 서비스할 수 있는지를 나타내는 up 또는 down 입니다. Ceph OSD가 다운 되어 Ceph 스토리지 클러스터에 있는 경우 이 상태에 Ceph OSD 오류가 표시될 수 있습니다. 예를 들어 Ceph OSD가 실행되지 않는 경우 Ceph OSD에서 Ceph Monitor에 다운 되었음을 알릴 수 없습니다. Ceph Monitor는 Ceph OSD 데몬을 주기적으로 ping하여 실행 중인지 확인할 수 있습니다. 그러나 하트베딩을 통해 Ceph OSD는 인접한 OSD가 중단 되었는지 여부를 확인하고 클러스터 맵을 업데이트하고 이를 Ceph 모니터에 보고할 수 있습니다. 즉, Ceph 모니터는 경량 프로세스로 유지될 수 있습니다.

Ceph는 여러 OSD에 배치 그룹의 사본을 저장합니다. 배치 그룹의 각 사본에는 상태가 있습니다. 이러한 OSD "피어"는 PG의 각 사본 상태에 동의하도록 서로 확인합니다. 피어링 문제는 일반적으로 자체적으로 해결됩니다.

Ceph에서 실행 중인 OSD 세트에 배치 그룹을 저장하는 경우 이를 Primary,Secondary 로 참조합니다. 관례적으로 Acting Set 의 첫 번째 OSD는 기본 OSD입니다. 배치 그룹의 첫 번째 복사본을 저장하는 Primary 는 해당 배치 그룹에 대한 피어 프로세스를 조정합니다. Primary 는 개체가 Primary 로서 작동하는 지정된 배치 그룹에 대한 클라이언트 시작 쓰기를 허용하는 유일한 OSD입니다.

Acting Set 은 배치 그룹을 저장하는 일련의 OSD입니다. Acting Set 은 현재 배치 그룹을 담당하는 Ceph OSD 데몬 또는 일부 epoch의 특정 배치 그룹을 담당하는 Ceph OSD 데몬을 참조할 수 있습니다.

Acting Set 의 일부인 Ceph OSD 데몬은 항상 가동 되지 않을 수 있습니다. Acting Set 의 OSD가 가동 되면 Up Set 의 일부입니다. OSD가 실패하면 Ceph에서 다른 Ceph OSD에 PG를 다시 매핑할 수 있으므로 Up Set 은 중요한 차이점입니다.

관리자가 Ceph OSD를 Ceph 스토리지 클러스터에 추가하면 Ceph가 클러스터 맵을 업데이트합니다. 수정된 클러스터 맵은 CRUSH 계산에 대한 입력이 변경되므로 클러스터 맵으로의 변경도 오브젝트 배치를 변경합니다. CRUSH는 데이터를 균등하게 배치하지만 무작위로 의사를 배치합니다. 따라서 관리자가 새 OSD를 추가할 때 적은 양의 데이터만 이동합니다. 데이터 양은 일반적으로 클러스터의 총 데이터 양으로 나눈 새 OSD의 수입니다. 예를 들어 OSD가 50개인 클러스터에서 OSD를 추가할 때 데이터의 1/50 또는 2%가 이동할 수 있습니다.

다음 다이어그램에서는 일부 PG가 다이어그램의 기존 OSD 1 및 2에서 다이어그램의 새 OSD OSD 3으로 마이그레이션되는 리밸런싱 프로세스를 보여줍니다. 재조정 시에도 CRUSH가 안정적입니다. 많은 배치 그룹은 원래 구성에 남아 있으며 각 OSD에는 추가 용량이 추가되므로 클러스터 재조정 후 새 OSD에 부하 급증이 발생하지 않습니다.

Ceph에는 두 가지 유형의 밸런서가 있습니다.

Ceph는 데이터 무결성 유지의 일환으로 잘못된 디스크 섹터 및 비트를 방지할 수 있는 다양한 메커니즘을 제공합니다.

CRUSH 알고리즘에서 활성화한 고가용성 외에도 Ceph는 고가용성을 유지해야 합니다. 즉, 클러스터가 성능이 저하되거나 모니터가 실패하는 경우에도 Ceph 클라이언트가 데이터를 읽고 쓸 수 있어야 합니다.

Ceph 클라이언트가 데이터를 읽거나 작성하려면 먼저 Ceph Monitor에 연결하여 클러스터 맵의 최신 사본을 가져와야 합니다. Red Hat Ceph Storage 클러스터는 단일 모니터로 작동할 수 있지만 이로 인해 단일 장애 지점이 발생합니다. 즉, 모니터가 다운되면 Ceph 클라이언트는 데이터를 읽거나 쓸 수 없습니다.

Ceph는 안정성 및 내결함성을 강화하기 위해 모니터 클러스터를 지원합니다. Ceph Monitor 클러스터의 대기 시간 및 기타 결함으로 인해 하나 이상의 모니터가 클러스터의 현재 상태가 될 수 있습니다. 이러한 이유로 Ceph는 스토리지 클러스터 상태와 관련된 다양한 모니터링 인스턴스에 동의해야 합니다. Ceph는 항상 대부분의 모니터와 Paxos 알고리즘을 사용하여 현재 스토리지 클러스터 상태에 대한 모니터 간의 합의를 설정합니다. Ceph 모니터 노드에는 클럭 드리프트를 방지하기 위해 NTP가 필요합니다.

스토리지 관리자는 일반적으로 홀수의 모니터로 Ceph를 배포하므로 대다수를 결정하는 것이 효율적입니다. 예를 들어, 대다수는 1, 2:3, 3:5, 4:6 등과 같을 수 있습니다.

최신 애플리케이션에는 비동기 통신 기능이 있는 간단한 오브젝트 스토리지 인터페이스가 필요합니다. Ceph Storage 클러스터는 비동기 통신 기능이 있는 간단한 오브젝트 스토리지 인터페이스를 제공합니다. 인터페이스는 클러스터 전체에서 개체에 직접 병렬 액세스를 제공합니다.

Ceph 클라이언트는 오브젝트에 지속적인 관심을 등록하고 기본 OSD에 세션을 유지할 수 있습니다. 클라이언트는 알림 메시지와 페이로드를 모든 감시자에게 보내고 감시자가 알림을 수신할 때 알림을 받을 수 있습니다. 이를 통해 클라이언트는 모든 오브젝트를 동기화/커뮤니케이션 채널로 사용할 수 있습니다.

필수 Exclusive Locks는 여러 마운트가 있는 경우 RBD를 단일 클라이언트에 잠그는 기능입니다. 이렇게 하면 여러 개의 마운트된 클라이언트가 동일한 오브젝트에 쓰기를 시도할 때 쓰기 충돌 상황을 해결할 수 있습니다. 이 기능은 이전 섹션에서 설명한 object-watch-notify 를 기반으로 합니다. 따라서 한 클라이언트가 먼저 개체에 배타적 잠금을 설정하는 경우 다른 마운트된 클라이언트는 먼저 피어가 쓰기 전에 개체에 잠금을 배치했는지 확인합니다.

이 기능이 활성화되면 특히 스냅샷 생성/삭제 와 같은 작업 중에 내부 RBD 구조를 변경할 때 한 번에 하나의 클라이언트만 RBD 장치를 수정할 수 있습니다. 또한 실패한 고객을 위한 몇 가지 보호 기능을 제공합니다. 예를 들어 가상 시스템이 응답하지 않고 다른 위치에서 동일한 디스크로 복사본을 시작하는 경우 첫 번째 머신은 Ceph에서 블랙리스트로 표시되어 새 시스템을 손상시킬 수 없습니다.

필수 예외 잠금은 기본적으로 활성화되어 있지 않습니다. 이미지를 생성할 때 --image-feature 매개변수를 사용하여 명시적으로 활성화해야 합니다.

[root@mon ~]# rbd create --size 102400 mypool/myimage --image-feature 5

여기서 숫자 5 는 1 과 4 의 요약으로, 1 은 계층 지정 지원을 활성화하고 4 는 배타적 잠금 지원을 가능하게 합니다. 따라서 위의 명령은 100GB rbd 이미지를 생성하여 계층화 및 독점 잠금을 활성화합니다.

필수 Exclusive Locks는 오브젝트 맵 의 전제 조건이기도 합니다. 독점 잠금 지원을 활성화하지 않으면 오브젝트 맵 지원을 활성화할 수 없습니다.

또한 필수 Exclusive Locks는 미러링을 위해 몇 가지 근거가 작동합니다.

오브젝트 맵은 클라이언트가 rbd 이미지에 쓸 때 RADOS 오브젝트를 백업하는 기능을 제공합니다. 쓰기가 발생하면 해당 쓰기가 백업 RADOS 오브젝트 내의 오프셋으로 변환됩니다. 오브젝트 맵 기능이 활성화되면 이러한 RADOS 오브젝트가 추적됩니다. 따라서 객체가 실제로 존재하는지 알 수 있습니다. 개체 맵은 librbd 클라이언트에 메모리 내 상태로 유지되므로 모르는 오브젝트에 대한 OSD를 쿼리하지 않을 수 있습니다. 즉, 오브젝트 맵은 실제로 존재하는 오브젝트의 인덱스입니다.

오브젝트 맵은 특정 작업인 viz에 유용합니다.

축소 크기 조정 작업은 후행 개체가 삭제되는 부분 삭제와 유사합니다.

내보내기 작업은 RADOS에서 요청할 오브젝트를 확인합니다.

복사 작업은 어떤 오브젝트가 존재하고 복사해야 하는지 알고 있습니다. 잠재적으로 수십만 개의 가능한 오브젝트를 반복할 필요가 없습니다.

flatten 작업은 모든 상위 개체에 대해 복제에 대한 복사를 수행하여 복제에서 상위 복제본으로의 참조를 제거합니다. 즉, 하위 복제본에서 상위 스냅샷으로의 참조를 제거할 수 있습니다. 따라서 모든 잠재적인 오브젝트 대신 복사는 존재하는 오브젝트에 대해서만 수행됩니다.

삭제 작업은 이미지에 존재하는 오브젝트만 삭제합니다.

읽기 작업은 알고 있는 개체에 대한 읽기가 존재하지 않는 경우 건너뜁니다.A read operation skips the read for objects it knows doesn't exist.

따라서 크기 조정, 축소, 내보내기, 복사, 병합 및 삭제와 같은 작업의 경우 이러한 작업은 잠재적으로 영향을 받는 모든 RADOS 오브젝트에 대한 작업을 실행해야 합니다. 개체 맵이 활성화된 경우 개체가 없으면 작업을 실행할 필요가 없습니다.

예를 들어 1TB 스파스 RBD 이미지가 있는 경우 수백 및 수천 개의 지원 RADOS 오브젝트가 있을 수 있습니다. 오브젝트 맵이 활성화되지 않은 삭제 작업은 이미지의 각 잠재적인 오브젝트에 대해 제거 오브젝트를 발행해야 합니다. 그러나 오브젝트 맵이 활성화된 경우 존재하는 오브젝트에 대한 오브젝트 작업 제거 만 있으면 됩니다.

오브젝트 맵은 실제 오브젝트가 없지만 부모로부터 오브젝트를 가져오는 복제본에 중요합니다. 복제된 이미지가 있으면 처음에 복제본에 오브젝트가 없고 모든 읽기가 상위로 리디렉션됩니다. 따라서 오브젝트 맵은 오브젝트 맵 없이 읽기를 개선할 수 있으므로 먼저 복제본에 대한 OSD에 읽기 작업을 실행해야 합니다. 이 경우 개체 맵이 활성화된 상태에서 상위에 다른 읽기 작업을 발행합니다. 알고 있는 오브젝트에 대한 읽기가 존재하지 않습니다.

오브젝트 맵은 기본적으로 활성화되어 있지 않습니다. 이미지를 생성할 때 --image-features 매개변수를 사용하여 명시적으로 활성화해야 합니다. 또한 Mandatory Exclusive Locks 는 오브젝트 맵 의 전제 조건입니다. 독점 잠금 지원을 활성화하지 않으면 오브젝트 맵 지원을 활성화할 수 없습니다. 이미지를 생성할 때 오브젝트 맵 지원을 활성화하려면 다음을 실행합니다.

[root@mon ~]# rbd -p mypool create myimage --size 102400 --image-features 13

여기서 숫자 13 은 1,4 및 8 의 요약으로, 여기서 1 은 계층 지정 지원을 가능하게 하고, 4 는 배타적 잠금 지원을 가능하게 하고, 8 은 오브젝트 맵을 지원할 수 있도록 합니다. 따라서 위의 명령은 100GB rbd 이미지를 생성하여 계층화, 독점 잠금 및 개체 맵을 활성화합니다.

스토리지 장치에는 처리량 제한이 있어 성능 및 확장성에 영향을 미칩니다. 따라서 스토리지 시스템은 처리량과 성능을 높이기 위해 여러 스토리지 장치에서 순차적 정보를 제거하는 경우가 많습니다. 가장 일반적인 형태의 데이터 스트라이핑은 RAID에서 가져온 것입니다. Ceph의 스트라이핑과 가장 유사한 RAID 유형은 RAID 0 또는 'striped volume'입니다. Ceph의 스트라이핑은 RAID 0 스트라이핑의 처리량, n-way RAID 미러링의 안정성 및 더 빠른 복구 기능을 제공합니다.

Ceph는 Ceph Block Device, Ceph Filesystem 및 Ceph Object Storage의 세 가지 유형의 클라이언트를 제공합니다. Ceph Client는 블록 장치 이미지, RESTful 오브젝트, CephFS 파일 시스템 디렉터리와 같이 사용자에게 제공하는 표시 형식에서 Ceph Storage 클러스터의 스토리지 오브젝트로 데이터를 변환합니다.

가장 간단한 Ceph 스트라이핑 형식은 1개의 오브젝트로 구성된 스트라이프 수를 포함합니다. Ceph Clients는 개체가 최대 용량이 될 때까지 Ceph Storage Cluster 개체에 스트라이프 단위를 작성한 다음 추가 데이터 스트라이프를 위해 다른 오브젝트를 만듭니다. 가장 간단한 형태의 스트라이핑은 작은 블록 장치 이미지, S3 또는 Swift 오브젝트에 충분합니다. 그러나 이 간단한 형식은 Ceph가 배치 그룹에 데이터를 배포하는 기능을 최대한 활용하지 않으므로 성능을 크게 개선하지 않습니다. 다음 다이어그램은 가장 간단한 형태의 스트라이핑을 보여줍니다.

예를 들어 대규모 이미지 크기, 대규모 S3 또는 Swift 오브젝트를 예상하는 경우 오브젝트 세트 내에서 여러 오브젝트에 대한 클라이언트 데이터를 제거하여 읽기/쓰기 성능이 크게 향상될 수 있습니다. 클라이언트가 해당 오브젝트에 스트라이프 단위를 병렬로 쓸 때 상당한 쓰기 성능이 발생합니다. 오브젝트가 다른 배치 그룹에 매핑되고 다른 OSD에 추가 매핑되므로 각 쓰기는 최대 쓰기 속도에서 병렬로 수행됩니다. 단일 디스크에 대한 쓰기는 헤드 이동, 예를 들어 한 장치의 검색당 6ms 및 대역폭(예: 100MB/s)에 의해 제한됩니다. Ceph는 여러 배치 그룹 및 OSD에 매핑되는 여러 오브젝트에 걸쳐 해당 쓰기를 분산함으로써 드라이브당 검색 횟수를 줄이고 여러 드라이브의 처리량을 결합하여 훨씬 빠른 쓰기 또는 읽기 속도를 얻을 수 있습니다.

다음 다이어그램에서 클라이언트 데이터는 4개의 개체로 구성된 개체 세트(다음 다이어그램의오브젝트 세트 1)에서 제거되며 첫 번째 스트라이프 단위는 개체 0에서 스트라이프 단위 가 0 이고 네 번째 스트라이프 단위는 개체 3 에서 스트라이프 단위입니다. 네 번째 스트라이프를 작성한 후 클라이언트는 오브젝트 세트가 가득 졌는지 확인합니다. 오브젝트 세트가 가득 차지 않으면 클라이언트는 첫 번째 오브젝트에 스트라이프를 다시 쓰기 시작합니다. 다음 다이어그램에서 오브젝트 0 을 참조하십시오. 개체 세트가 가득 차면 클라이언트는 새 개체 세트를 만들고 다음 다이어그램에서 오브젝트 세트 2 를 확인하고 첫 번째 스트라이프 단위가 16인 스트라이프 단위로 새 개체 세트의 첫 번째 개체 집합에서 오브젝트 4 를 참조하십시오.

다음 세 가지 중요한 변수는 Ceph가 데이터를 스트라이핑하는 방법을 결정합니다.

Ceph Client가 데이터를 스트라이프하고 스트라이프 단위를 개체에 매핑하면 Ceph의 CRUSH 알고리즘은 개체를 배치 그룹에 매핑하고 개체가 스토리지 디스크에 파일로 저장되기 전에 배치 그룹에 배치 그룹을 매핑합니다.

enger 버전 2 프로토콜을 사용하여 네트워크를 통한 모든 Ceph 트래픽에 대해 암호화를 활성화할 수 있습니다. v2의 보안 모드 설정은 Ceph 데몬과 Ceph 클라이언트 간의 통신을 암호화하여 엔드 투 엔드 암호화를 제공합니다.

Ceph의 on-wire 프로토콜의 두 번째 버전인 msgr2 에는 몇 가지 새로운 기능이 포함되어 있습니다.

Ceph 데몬은 여러 포트에 바인딩되므로 레거시 v1-호환 및 새로운 v2 호환 Ceph 클라이언트가 동일한 스토리지 클러스터에 연결할 수 있습니다. Ceph Monitor 데몬에 연결하는 Ceph 클라이언트 또는 기타 Ceph 데몬은 가능한 경우 v2 프로토콜을 먼저 사용하려고 하지만 그렇지 않은 경우 레거시 v1 프로토콜이 사용됩니다. 기본적으로 두 프로토콜 모두 v1 및 v2 가 활성화되어 있습니다. 새로운 v2 포트는 3300이며 레거시 v1 포트는 기본적으로 6789입니다.

v2 프로토콜에는 v1 또는 v2 프로토콜 사용 여부를 제어하는 두 가지 구성 옵션이 있습니다.

마찬가지로 사용되는 IPv4 및 IPv6 주소를 기반으로 하는 두 가지 옵션 제어

msgr2 프로토콜은 다음 두 가지 연결 모드를 지원합니다.

기본 모드는 crc 입니다.

암호화 오버헤드를 포함하도록 Red Hat Ceph Storage 클러스터를 계획할 때 클러스터 CPU 요구 사항을 고려해야 합니다.

이제 Ceph 데몬이 여러 포트에 바인딩되므로 데몬은 단일 주소 대신 여러 주소를 표시합니다. 다음은 모니터 맵 덤프의 예입니다.

epoch 1
fsid 50fcf227-be32-4bcb-8b41-34ca8370bd17
last_changed 2021-12-12 11:10:46.700821
created 2021-12-12 11:10:46.700821
min_mon_release 14 (nautilus)
0: [v2:10.0.0.10:3300/0,v1:10.0.0.10:6789/0] mon.a
1: [v2:10.0.0.11:3300/0,v1:10.0.0.11:6789/0] mon.b
2: [v2:10.0.0.12:3300/0,v1:10.0.0.12:6789/0] mon.c

또한 mon_host 구성 옵션을 사용하고 -m 을 사용하여 명령줄에서 주소를 지정하면 새 주소 형식을 지원합니다.