구성 가이드

모든 Red Hat Ceph Storage 클러스터에는 다음과 같은 구성이 있습니다.

cephadm 과 같은 배포 툴은 일반적으로 초기 Ceph 구성 파일을 생성합니다. 그러나 배포 도구를 사용하지 않고 Red Hat Ceph Storage 클러스터를 부트스트랩하려는 경우 직접 생성할 수 있습니다.

Ceph 모니터는 전체 스토리지 클러스터의 구성 옵션을 저장하여 구성 관리를 중앙 집중화하는 Ceph 옵션의 구성 데이터베이스를 관리합니다. 따라서 데이터베이스의 Ceph 구성을 중앙 집중화하면 스토리지 클러스터 관리가 간소화됩니다.

Ceph에서 옵션을 설정하는 데 사용하는 우선순위 순서는 다음과 같습니다.

여전히 로컬 Ceph 구성 파일에 정의할 수 있는 몇 가지 Ceph 옵션이 있습니다. 기본적으로 /etc/ceph/ceph.conf 입니다. 그러나 ceph.conf 는 Red Hat Ceph Storage 8에서 더 이상 사용되지 않습니다.

cephadm 은 Ceph 모니터에 연결, 인증 및 구성 정보를 가져오기 위한 최소한의 옵션 세트만 포함된 기본 ceph.conf 파일을 사용합니다. 대부분의 경우 cephadm 은 mon_host 옵션만 사용합니다. mon_host 옵션에만 ceph.conf 를 사용하지 않으려면 DNS SRV 레코드를 사용하여 모니터로 작업을 수행합니다.

Ceph를 사용하면 런타임 시 데몬 구성을 변경할 수 있습니다. 이 기능은 디버그 설정을 활성화하거나 비활성화하여 로깅 출력을 늘리거나 줄이는 데 유용할 수 있으며 런타임 최적화에도 사용할 수 있습니다.

Ceph 구성 옵션에는 마스크가 연결되어 있을 수 있습니다. 이러한 마스크는 옵션이 적용되는 데몬 또는 클라이언트를 추가로 제한할 수 있습니다.

마스크에는 두 가지 유형이 있습니다.

메타 변수는 Ceph 스토리지 클러스터 구성을 크게 단순화합니다. 구성 값에 메타 변수가 설정된 경우 Ceph는 메타 변수를 구체적인 값으로 확장합니다.

메타 변수는 Ceph 구성 파일의 [global], [osd], [mon] 또는 [client] 섹션에서 사용할 때 매우 강력합니다. 그러나 관리 소켓과 함께 사용할 수도 있습니다. Ceph 메타 변수는 Bash 쉘 확장과 유사합니다.

Ceph는 다음 메타 변수를 지원합니다.

Ceph 구성 파일은 부팅 시 및 런타임 시 볼 수 있습니다.

Red Hat Ceph Storage의 구성 설정은 런타임 시 Ceph Monitor 노드에서 볼 수 있습니다.

런타임 시 특정 Ceph 구성을 설정하려면 ceph config set 명령을 사용합니다.

ceph config set mgr mgr/cephadm/manage_etc_ceph_ceph_conf false

BlueStore는 osd_memory_target 구성 옵션을 사용하여 OSD 힙 메모리 사용량을 지정된 대상 크기 아래에 유지합니다.

osd_memory_target 옵션은 시스템에서 사용 가능한 RAM에 따라 OSD 메모리를 설정합니다. TCMalloc이 메모리 al Cryostat로 구성되어 있고 BlueStore의 bluestore_cache_autotune 옵션이 true 로 설정된 경우 이 옵션을 사용합니다.

블록 장치가 느릴 때 Ceph OSD 메모리 캐싱이 더 중요합니다. 예를 들어 캐시 적중의 이점은 솔리드 스테이트 드라이브를 사용하는 것보다 훨씬 길기 때문입니다. 그러나 OSD를 하이퍼 컨버지드 인프라(하이퍼 컨버지드 인프라) 또는 기타 애플리케이션과 같이 다른 서비스와 배치하기 위한 결정에 직면해야 합니다.

OSD 데몬은 osd_memory_target 구성 옵션을 기반으로 메모리 사용을 조정합니다. osd_memory_target 옵션은 시스템에서 사용 가능한 RAM에 따라 OSD 메모리를 설정합니다.

Red Hat Ceph Storage가 다른 서비스와 메모리를 공유하지 않는 전용 노드에 배포된 경우 cephadm 은 총 RAM 양 및 배포된 OSD 수에 따라 자동으로 OSD 소비를 조정합니다.

ceph config set osd osd_memory_target_autotune true

cephadm 은 mgr/cephadm/autotune_memory_target_ratio 로 시작합니다. 기본값은 시스템의 총 RAM으로, 비 자동 조정되지 않은 데몬에서 사용하는 메모리를 제거하고 osd_memory_target_autotune 이 false인 OSD로 나눕니다.

osd_memory_target 매개변수는 다음과 같이 계산됩니다.

osd_memory_target = TOTAL_RAM_OF_THE_OSD * (1048576) * (autotune_memory_target_ratio) / NUMBER_OF_OSDS_IN_THE_OSD_NODE - (SPACE_ALLOCATED_FOR_OTHER_DAEMONS)

SPACE_ALLOCATED_FOR_OTHER_DAEMONS 는 선택적으로 다음 데몬 공간 할당을 포함할 수 있습니다.

예를 들어 노드에 24개의 OSD가 있고 251GB RAM 공간이 있는 경우 osd_memory_target 은 7860684936 입니다.

최종 대상은 옵션을 사용하여 구성 데이터베이스에 반영됩니다. MEM LIMIT 열의 ceph orch ps 출력에서 각 데몬에서 사용하는 제한 및 현재 메모리를 볼 수 있습니다.

[ceph: root@host01 /]# ceph config set mgr mgr/cephadm/autotune_memory_target_ratio 0.2

스토리지 클러스터에서 OSD의 특정 메모리 대상을 수동으로 설정할 수 있습니다.

[ceph: root@host01 /]# ceph config set osd.123 osd_memory_target 7860684936

스토리지 클러스터에서 OSD 호스트의 특정 메모리 대상을 수동으로 설정할 수 있습니다.

ceph config set osd/host:HOSTNAME osd_memory_target TARGET_BYTES

[ceph: root@host01 /]# ceph config set osd/host:host01 osd_memory_target 1000000000

ceph orch host label add HOSTNAME _no_autotune_memory

autotune 옵션을 비활성화하고 특정 메모리 대상을 설정하여 OSD를 메모리 자동 튜닝에서 제외할 수 있습니다.

[ceph: root@host01 /]# ceph config set osd.123 osd_memory_target_autotune false
[ceph: root@host01 /]# ceph config set osd.123 osd_memory_target 16G

MDS 서버는 Ceph OSD의 사용자인 cephfs_metadata 라는 별도의 스토리지 풀에 메타데이터를 유지합니다. Ceph File Systems의 경우 MDS 서버는 스토리지 클러스터 내의 단일 스토리지 장치뿐만 아니라 전체 Red Hat Ceph Storage 클러스터를 지원해야 하므로 특히 워크로드가 소규모-medium-size 파일로 구성된 경우 특히 메타데이터와 데이터 비율이 훨씬 높은 경우 메모리 요구 사항이 중요할 수 있습니다.

예: mds_cache_memory_limit 을 2000000000 바이트로 설정합니다.

ceph_conf_overrides:
  mds:
    mds_cache_memory_limit=2000000000

네트워크 구성은 고성능 Red Hat Ceph Storage 클러스터를 구축하는 데 중요합니다. Ceph 스토리지 클러스터는 Ceph 클라이언트를 대신하여 요청 라우팅 또는 디스패치를 수행하지 않습니다. 대신 Ceph 클라이언트는 Ceph OSD 데몬에 직접 요청합니다. Ceph OSD는 Ceph 클라이언트를 대신하여 데이터 복제를 수행합니다. 즉, 복제 및 기타 요인은 Ceph 스토리지 클러스터 네트워크에 추가 로드를 부과합니다.

Ceph에는 모든 데몬에 적용되는 하나의 네트워크 구성 요구 사항이 있습니다. Ceph 구성 파일은 각 데몬의 호스트 를 지정해야 합니다.

cephadm 과 같은 일부 배포 유틸리티는 구성 파일을 생성합니다. 배포 유틸리티에서 해당 값을 수행하는 경우 이 값을 설정하지 마십시오.

모든 Ceph 클러스터는 공용 네트워크를 사용해야 합니다. 그러나 내부 클러스터 네트워크를 지정하지 않으면 Ceph는 단일 공용 네트워크를 가정합니다. Ceph는 공용 네트워크에서만 작동할 수 있지만 대규모 스토리지 클러스터의 경우 클러스터 관련 트래픽만 전송하기 위해 두 번째 프라이빗 네트워크에서 성능이 크게 향상되었습니다.

두 개의 네트워크를 지원하려면 각 Ceph 노드에 NIC(네트워크 인터페이스 카드)가 두 개 이상 있어야 합니다.

두 개의 별도의 네트워크 운영을 고려해야 하는 몇 가지 이유가 있습니다.

네트워크 구성 설정은 필요하지 않습니다. Ceph 데몬을 실행하는 모든 호스트에 공용 네트워크가 구성되어 있다고 가정하면 Ceph가 공용 네트워크에서만 작동할 수 있습니다. 그러나 Ceph를 사용하면 공용 네트워크에 대한 여러 IP 네트워크 및 서브넷 마스크를 포함하여 훨씬 더 구체적인 기준을 설정할 수 있습니다. OSD 하트비트, 오브젝트 복제 및 복구 트래픽을 처리하도록 별도의 클러스터 네트워크를 설정할 수도 있습니다.

구성에 설정한 IP 주소와 공용 방향 IP 주소 네트워크 클라이언트가 서비스에 액세스하는 데 사용할 수 있는 IP 주소를 혼동하지 마십시오. 일반적인 내부 IP 네트워크는 종종 192.168.0.0 또는 10.0.0.0 입니다.

네트워크를 구성하면 클러스터를 다시 시작하거나 각 데몬을 다시 시작할 수 있습니다. Ceph 데몬은 동적으로 바인딩되므로 네트워크 구성을 변경하는 경우 전체 클러스터를 한 번에 다시 시작할 필요가 없습니다.

Cryostat는 Ceph 네트워크 계층 구현입니다. Red Hat은 다음 두 가지 유형의 메시징을 지원합니다.

Red Hat Ceph Storage 7 이상에서 async 는 기본 음성 유형입니다. enger 유형을 변경하려면 Ceph 구성 파일의 [global] 섹션에 ms_type 구성 설정을 지정합니다.

Ceph 네트워크를 구성하려면 cephadm 쉘 내에서 config set 명령을 사용하십시오. 네트워크 구성에 설정한 IP 주소는 네트워크 클라이언트가 서비스에 액세스하는 데 사용할 수 있는 공용 방향 IP 주소와 다릅니다.

Ceph는 공용 네트워크에서만 완벽하게 작동합니다. 그러나 Ceph를 사용하면 공용 네트워크에 대한 여러 IP 네트워크를 포함하여 훨씬 더 구체적인 기준을 설정할 수 있습니다.

OSD 하트비트, 오브젝트 복제 및 복구 트래픽을 처리하기 위해 별도의 프라이빗 클러스터 네트워크를 설정할 수도 있습니다. 사설 네트워크에 대한 자세한 내용은 사설 네트워크 구성을 참조하십시오.

공용 네트워크 구성을 사용하면 공용 네트워크의 IP 주소 및 서브넷을 구체적으로 정의할 수 있습니다.

네트워크 구성 설정은 필요하지 않습니다. Ceph는 프라이빗 네트워크라고도 하는 클러스터 네트워크를 구체적으로 구성하지 않는 한 모든 호스트가 작동하는 공용 네트워크를 가정합니다.

클러스터 네트워크를 생성하는 경우 OSD는 클러스터 네트워크를 통해 하트비트, 오브젝트 복제 및 복구 트래픽을 라우팅합니다. 이렇게 하면 단일 네트워크 사용과 비교하여 성능이 향상될 수 있습니다.

클러스터 네트워크를 할당하려면 cephadm bootstrap 명령과 함께 --cluster-network 옵션을 사용합니다. 지정한 클러스터 네트워크는 CIDR 표기법에 서브넷을 정의해야 합니다(예: 10.90.90.0/24 또는 fe80::/64).

boostrap 후 cluster_network 를 구성할 수도 있습니다.

사용자가 여러 네트워크 서브넷에 속하는 호스트에 Ceph Monitor 데몬을 배치하려면 클러스터에 여러 공용 네트워크를 구성해야 합니다. 사용 예로는 OpenShift Data Foundation용 Metro DR의 ACS(Advanced Cluster Management)에 사용되는 확장 클러스터 모드가 있습니다.

부트 스트랩 중에 여러 공용 네트워크를 클러스터에 구성하고 부트스트랩이 완료되면 구성할 수 있습니다.

기본적으로 Red Hat Ceph Storage 데몬은 TCP 포트 6800-​7100을 사용하여 클러스터의 다른 호스트와 통신합니다. 호스트의 방화벽이 이러한 포트에서 연결을 허용하는지 확인할 수 있습니다.

자세한 내용은 방화벽 설명서를 참조하십시오.

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

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

Ceph Monitor를 구성하는 방법은 안정적인 Red Hat Ceph Storage 클러스터를 구축하는 데 중요한 부분입니다. 모든 스토리지 클러스터에는 하나 이상의 모니터가 있습니다. Ceph Monitor 구성은 일반적으로 상당히 일관되게 유지되지만 스토리지 클러스터에서 Ceph Monitor를 추가, 제거 또는 교체할 수 있습니다.

Ceph 모니터는 클러스터 맵의 "마스터 복사"를 유지 관리합니다. 즉, Ceph 클라이언트는 하나의 Ceph 모니터에 연결하고 현재 클러스터 맵을 검색하는 것만으로 모든 Ceph 모니터 및 Ceph OSD의 위치를 확인할 수 있습니다.

Ceph 클라이언트가 Ceph OSD에서 읽거나 쓸 수 있으려면 먼저 Ceph Monitor에 연결해야 합니다. 현재 클러스터 맵 및 CRUSH 알고리즘의 사본으로 Ceph 클라이언트는 모든 오브젝트의 위치를 계산할 수 있습니다. Ceph 클라이언트는 개체 위치를 계산하는 기능을 통해 Ceph OSD와 직접 통신할 수 있습니다. 이는 Ceph의 확장성 및 성능에 매우 중요한 측면입니다.

Ceph Monitor의 기본 역할은 클러스터 맵의 마스터 사본을 유지 관리하는 것입니다. Ceph 모니터는 인증 및 로깅 서비스도 제공합니다. Ceph Monitor는 모니터 서비스의 모든 변경 사항을 단일 Paxos 인스턴스에 작성하고 Paxos는 강력한 일관성을 위해 키-값 저장소에 변경 사항을 씁니다. Ceph 모니터는 동기화 작업 중에 최신 버전의 클러스터 맵을 쿼리할 수 있습니다. Ceph 모니터는 rocksdb 데이터베이스를 사용하여 키-값 저장소의 스냅샷과 Cryostat를 활용하여 저장소 전체 동기화를 수행합니다.

구성 데이터베이스에서 Ceph Monitor 구성을 볼 수 있습니다.

클러스터 맵은 모니터 맵, OSD 맵, 배치 그룹 맵을 포함한 복합 맵입니다. 클러스터 맵은 여러 중요한 이벤트를 추적합니다.

클러스터 상태가 크게 변경되면 예를 들어 Ceph OSD가 중단되면 배치 그룹이 성능이 저하된 상태가 됩니다. 클러스터 맵이 업데이트되어 클러스터의 현재 상태가 반영됩니다. 또한 Ceph 모니터는 클러스터의 이전 상태 기록도 유지 관리합니다. 모니터 맵, OSD 맵, 배치 그룹 맵은 각각 맵 버전의 기록을 유지합니다. 각 버전을 epoch 라고 합니다.

Red Hat Ceph Storage 클러스터를 작동할 때 이러한 상태를 추적하는 것이 클러스터 관리의 중요한 부분입니다.

클러스터는 단일 모니터로 충분히 실행됩니다. 그러나 단일 모니터는 단일 장애 지점입니다. 프로덕션 Ceph 스토리지 클러스터에서 고가용성을 보장하기 위해 여러 모니터가 있는 Ceph를 실행하여 단일 모니터가 실패하면 전체 스토리지 클러스터가 실패하지 않습니다.

Ceph 스토리지 클러스터에서 고가용성을 위해 여러 Ceph Monitor를 실행하는 경우 Ceph 모니터는 Paxos 알고리즘을 사용하여 마스터 클러스터 맵에 대한 합의를 설정합니다. 합의를 위해서는 클러스터 맵에 대한 합의에 대한 쿼럼을 구축하기 위해 실행 중인 대부분의 모니터가 필요합니다. 예를 들어 1; 3 중 2개; 5개 중 3개, 6개 중 4개, 6개 중 4개 등

Red Hat은 고가용성을 보장하기 위해 3개 이상의 Ceph 모니터를 사용하여 프로덕션 Red Hat Ceph Storage 클러스터를 실행하는 것이 좋습니다. 여러 모니터를 실행하는 경우 쿼럼을 설정하기 위해 스토리지 클러스터의 멤버여야 하는 초기 모니터를 지정할 수 있습니다. 이로 인해 스토리지 클러스터가 온라인 상태가 되는 데 걸리는 시간이 단축될 수 있습니다.

[mon]
mon_initial_members = a,b,c

Ceph 구성 파일에 모니터 설정을 추가할 때 Ceph 모니터의 아키텍처 측면을 알고 있어야 합니다. Ceph는 클러스터 내에서 다른 Ceph Monitor를 검색할 때 Ceph Monitor에 대한 엄격한 일관성 요구 사항을 적용합니다. Ceph 클라이언트 및 기타 Ceph 데몬은 Ceph 구성 파일을 사용하여 모니터를 검색하지만 모니터는 Ceph 구성 파일이 아닌 모니터 맵(monmap)을 사용하여 서로 검색합니다.

Red Hat Ceph Storage 클러스터에서 다른 Ceph 모니터를 검색할 때 Ceph Monitor는 항상 모니터 맵의 로컬 사본을 나타냅니다. Ceph 구성 파일 대신 모니터 맵을 사용하면 클러스터가 손상될 수 있는 오류가 발생하지 않습니다. 예를 들어 모니터 주소 또는 포트를 지정할 때 Ceph 구성 파일에 오타가 있습니다. 모니터는 검색에 모니터 맵을 사용하고 클라이언트 및 기타 Ceph 데몬과 모니터 맵을 공유하므로 모니터 맵은 모니터에서 합의가 유효함을 엄격하게 보장합니다.

Ceph 모니터가 모니터 맵 대신 Ceph 구성 파일을 통해 서로 발견되면 Ceph 구성 파일이 자동으로 업데이트 및 배포되지 않기 때문에 추가 위험이 발생합니다. Ceph 모니터는 이전 Ceph 구성 파일을 실수로 사용하거나 Ceph 모니터를 인식하지 못하거나 쿼럼을 대체하거나 Paxos가 시스템의 현재 상태를 정확하게 확인할 수 없는 상황을 개발할 수 있습니다.

대부분의 구성 및 배포 사례에서 cephadm 과 같은 Ceph를 배포하는 툴은 모니터 맵을 생성하여 Ceph 모니터를 부트스트랩하는 데 도움이 될 수 있습니다.

Ceph 모니터에는 몇 가지 명시적 설정이 필요합니다.

Ceph 구성 파일에서 Ceph Monitor의 베어 최소 모니터 설정에는 DNS 및 모니터 주소에 대해 구성되지 않은 경우 각 모니터의 호스트 이름이 포함되어 있습니다. Ceph 모니터는 기본적으로 포트 6789 및 3300 에서 실행됩니다.

다음 명령을 사용하여 스토리지 클러스터 구성 옵션을 설정하거나 읽을 수 있습니다.

여기에서 Cryo stat 매개 변수는 섹션의 이름 또는 Ceph 데몬일 수 있으며 OPTION 은 구성 파일이며 VALUE 는 true 또는 false 일 수 있습니다.

ceph cephadm set-extra-ceph-conf

각 Red Hat Ceph Storage 클러스터에는 고유 식별자(fsid)가 있습니다. 지정하면 일반적으로 구성 파일의 [global] 섹션 아래에 표시됩니다. 배포 툴은 일반적으로 fsid 를 생성하고 이를 모니터 맵에 저장하므로 이 값은 구성 파일에 표시되지 않을 수 있습니다. fsid 를 사용하면 동일한 하드웨어에서 여러 클러스터에 대해 데몬을 실행할 수 있습니다.

Ceph는 Ceph 모니터 데이터를 저장하는 기본 경로를 제공합니다.

Ceph 모니터는 fsync() 함수를 자주 호출하여 Ceph OSD 워크로드를 방해할 수 있습니다.

Ceph 모니터는 데이터를 키-값 쌍으로 저장합니다. 데이터 저장소를 사용하면 Paxos를 통해 손상된 버전에서 Ceph 모니터를 복구할 수 없으며, 다른 이점 중 하나의 단일 원자 배치로 여러 수정 작업을 수행할 수 있습니다.

Red Hat Ceph Storage 클러스터가 최대 용량( mon_osd_full_ratio 매개변수로 지정)에 근접하면 Ceph를 사용하면 데이터 손실을 방지하기 위해 Ceph OSD에 기록하거나 읽을 수 없습니다. 따라서 프로덕션 환경에서 Red Hat Ceph Storage 클러스터가 전체 비율에 접근하도록 하는 것은 고가용성을 저해하기 때문에 좋지 않습니다. 기본 전체 비율은 .95 또는 용량의 95%입니다. OSD 수가 적은 테스트 클러스터에 대해 매우 공격적인 설정입니다.

테스트 클러스터의 일반적인 시나리오에는 클러스터 재조정을 확인하기 위해 Red Hat Ceph Storage 클러스터에서 Ceph OSD를 제거하는 시스템 관리자가 포함됩니다. 그런 다음 Red Hat Ceph Storage 클러스터가 전체 비율 및 잠금에 도달할 때까지 다른 Ceph OSD를 제거합니다.

Ceph OSD를 즉시 교체하지 않고 클러스터가 활성 + 정리 상태로 복구할 수 있는 일련의 Ceph OSD 오류를 계획하는 것이 좋습니다. 활성 + 성능이 저하된 상태에서 클러스터를 실행할 수 있지만 정상적인 작동 상태에는 적합하지 않습니다.

다음 다이어그램에서는 호스트당 하나의 Ceph OSD가 있는 33 개의 Ceph 노드가 포함된 단순한 Red Hat Ceph Storage 클러스터를 보여줍니다. 각 Ceph OSD 데몬은 3TB 드라이브에서 읽고 씁니다. 따라서 이 예시적인 Red Hat Ceph Storage 클러스터는 최대 실제 용량이 99TB입니다. mon osd full ratio of 0.95 에서는 Red Hat Ceph Storage 클러스터가 5TB의 나머지 용량에 속하는 경우 Ceph 클라이언트가 데이터를 읽고 쓸 수 없습니다. 따라서 Red Hat Ceph Storage 클러스터의 운영 용량은 99TB가 아닌 95%TB입니다.

하나 또는 두 개의 OSD가 실패하는 경우 클러스터에서 정상입니다. 랙의 라우터 또는 전원 공급이 덜 자주 발생하지만, 이로 인해 여러 OSD가 동시에 중단됩니다(예: OSD 7-12). 이러한 시나리오에서는 작동 상태를 유지하고 짧은 순서로 추가 OSD가 있는 몇 개의 호스트를 추가하는 것을 의미하더라도 활성 + 정리 상태를 달성할 수 있는 클러스터를 계속 사용해야 합니다. 용량 사용률이 너무 높으면 데이터를 손실할 수 없지만 클러스터의 용량 사용률이 전체 비율을 초과하면 장애 도메인 내에서 중단을 해결하면서 데이터 가용성을 저하시킬 수 있습니다. 이러한 이유로 Red Hat은 최소 일부의 대략적인 용량 계획을 권장합니다.

클러스터의 두 번호를 확인합니다.

클러스터 내에서 OSD의 평균 용량을 확인하려면 클러스터의 총 용량을 클러스터의 OSD 수로 나눕니다. 정상적인 작업 중에 동시에 실패할 것으로 예상되는 OSD 수와 그 수를 곱하는 것이 좋습니다(상대적으로 적은 수). 마지막으로 최대 작동 용량에 도달하기 위해 클러스터의 용량을 전체 비율로 곱합니다. 그런 다음 적절한 전체 비율로 도달하지 못할 OSD에서 데이터 양을 제거합니다. OSD 오류가 많은 예상 프로세스(예: OSD 랙)를 반복하여 거의 전체 비율로 적절한 수에 도달합니다.

Ceph 모니터는 각 OSD에서 보고해야 하고 인접 OSD의 상태에 대한 OSD에서 보고서를 수신하여 클러스터에 대해 알고 있습니다. Ceph는 모니터와 OSD 간의 상호 작용을 위해 적절한 기본 설정을 제공하지만 필요에 따라 수정할 수 있습니다.

여러 모니터가 있는 프로덕션 클러스터를 실행할 때 각 모니터에서 주변 모니터에 더 최신 버전의 클러스터 맵이 있는지 확인합니다. 예를 들어, 인스턴트 모니터의 맵에서 가장 최신의 epoch보다 하나 이상의 epoch 번호를 갖는 인접 모니터의 맵. 주기적으로 클러스터의 한 모니터는 쿼럼을 떠나야 하는 시점으로 다른 모니터를 대체하고, 동기화를 통해 클러스터에 대한 최신 정보를 검색한 다음 쿼럼에 다시 참여할 수 있습니다.

이러한 역할을 통해 리더는 동기화 작업을 공급자에 위임할 수 있으므로 동기화 요청이 리더를 과부하하고 성능을 개선하는 것을 방지할 수 있습니다. 다음 다이어그램에서 요청자는 다른 모니터 뒤에 있다는 것을 알게 되었습니다. 요청자는 리더에게 동기화하도록 요청하고, 리더는 요청자에게 공급자와 동기화하도록 지시합니다.

동기화가 완료되면 Ceph가 클러스터 전체에서 트리밍해야 합니다. 트리밍에서는 배치 그룹이 활성 + clean이어야 합니다.

Ceph 데몬은 중요한 메시지를 서로 전달하며 데몬이 시간 초과 임계값에 도달하기 전에 처리해야 합니다. Ceph 모니터의 시계가 동기화되지 않으면 여러 가지 문제가 발생할 수 있습니다.

예를 들면 다음과 같습니다.

불일치가 아직 유해하지는 않더라도 클럭 드리프트는 NTP에서 계속 사용할 수 있습니다. NTP가 적절한 수준의 동기화를 유지하더라도 Ceph 클럭 드리프트 및 클럭 스큐 경고가 트리거될 수 있습니다. 이러한 상황에서 클럭 드리프트를 늘리는 것은 허용될 수 있습니다. 그러나 워크로드, 네트워크 대기 시간, 기본 시간 초과에 대한 덮어쓰기 구성, 기타 동기화 옵션은 Paxos 보장을 손상시키지 않고 허용 가능한 클럭 드리프트 수준에 영향을 미칠 수 있습니다.

cephx 프로토콜은 기본적으로 활성화되어 있습니다. 암호화 인증에는 약간의 컴퓨팅 비용이 있지만 일반적으로 매우 낮습니다. 클라이언트 및 호스트를 연결하는 네트워크 환경이 안전한 것으로 간주되고 인증 컴퓨팅 비용을 허용할 수 없는 경우 비활성화할 수 있습니다. Ceph 스토리지 클러스터를 배포할 때 배포 툴에서 client.admin 사용자 및 인증 키를 생성합니다.

cephx 가 활성화되면 Ceph는 기본 검색 경로에서 인증 키를 찾습니다. 여기에는 /etc/ceph/$cluster.$name.keyring. Ceph 구성 파일의 [global] 섹션에 인증 키 옵션을 추가하여 이 위치를 재정의할 수는 있지만 권장되지는 않습니다.

인증이 비활성화된 클러스터에서 cephx 를 활성화하려면 다음 절차를 실행합니다. 사용자 또는 배포 유틸리티에서 이미 키를 생성한 경우 키 생성과 관련된 단계를 건너뛸 수 있습니다.

다음 절차에서는 Cephx를 비활성화하는 방법을 설명합니다. 클러스터 환경이 비교적 안전한 경우 인증 실행 비용을 상쇄할 수 있습니다.

그러나 인증을 일시적으로 비활성화하도록 설정 또는 문제 해결 중에 더 쉬워질 수 있습니다.

인증이 활성화된 Ceph를 실행하는 경우 Ceph 관리 명령 및 Ceph 클라이언트에 Ceph 스토리지 클러스터에 액세스하려면 인증 키가 필요합니다.

이러한 키를 ceph 관리 명령 및 클라이언트에 제공하는 가장 일반적인 방법은 /etc/ceph/ 디렉터리에 Ceph 인증 키를 포함하는 것입니다. 파일 이름은 일반적으로 ceph.client.admin.keyring 또는 $cluster.client.admin.keyring 입니다. 인증 키를 /etc/ceph/ 디렉터리에 포함하는 경우 Ceph 구성 파일에 인증 키 항목을 지정할 필요가 없습니다.

이렇게 하려면 다음 명령을 실행합니다.

# scp USER@HOSTNAME:/etc/ceph/ceph.client.admin.keyring /etc/ceph/ceph.client.admin.keyring

USER 를 호스트에서 사용하는 사용자 이름으로 client.admin 키로, HOSTNAME 을 해당 호스트의 호스트 이름으로 바꿉니다.

권장되지 않는 키 설정 또는 key file 설정을 사용하여 키 파일의 경로를 Ceph 구성 파일에 지정할 수 있습니다.

관리 사용자 또는 배포 툴은 사용자 인증 키를 생성하는 것과 동일한 방식으로 데몬 인증 키를 생성할 수 있습니다. 기본적으로 Ceph는 데이터 디렉터리에 데몬 인증 키를 저장합니다. 기본 키 링 위치와 데몬이 작동하는 데 필요한 기능입니다.

데몬 데이터 디렉터리 위치는 기본적으로 양식의 디렉터리로 설정됩니다.

/var/lib/ceph/$type/CLUSTER-ID

/var/lib/ceph/osd/ceph-12

이러한 위치를 재정의할 수는 있지만 권장되지는 않습니다.

Ceph는 세분화된 제어를 제공하므로 클라이언트와 Ceph 간의 서비스 메시지의 서명을 활성화하거나 비활성화할 수 있습니다. Ceph 데몬 간 메시지의 서명을 활성화하거나 비활성화할 수 있습니다.

풀을 생성하고 풀에 대한 배치 그룹 수를 설정할 때 기본값을 구체적으로 재정의하지 않는 경우 Ceph는 기본값을 재정의하지 않는 경우 기본값을 사용합니다.

pool 명령을 실행할 때 이러한 값을 설정할 수 있습니다.

기본적으로 Ceph는 3개의 오브젝트 복제본을 만듭니다. 오브젝트의 복사본 4개를 기본값, 기본 복사 및 3개의 복제본 복사본으로 설정하려면 osd_pool_default_size 에 표시된 대로 기본값을 재설정합니다. Ceph에서 성능이 저하된 상태의 복사본 수를 더 적게 작성하도록 허용하려면 osd_pool_default_min_size 값을 osd_pool_default_size 값보다 작은 숫자로 설정합니다.

[ceph: root@host01 /]# ceph config set global osd_pool_default_size 4  # Write an object 4 times.
[ceph: root@host01 /]# ceph config set global osd_pool_default_min_size 1  # Allow writing one copy in a degraded state.

비현실적인 수의 배치 그룹이 있는지 확인하십시오. OSD당 약 100개를 권장합니다. 예를 들어 총 OSD 수를 복제본 수를 100으로 나눕니다(즉, osd_pool_default_size ). 10개의 OSD 및 osd_pool_default_size = 4의 경우 약 (100 * 10) / 4 = 250를 권장합니다.

[ceph: root@host01 /]# ceph config set global osd_pool_default_pg_num 250
[ceph: root@host01 /]# ceph config set global osd_pool_default_pgp_num 250

모든 Ceph 클러스터에는 다음과 같은 구성이 있습니다.

cephadm 과 같은 배포 툴은 일반적으로 초기 Ceph 구성 파일을 생성합니다. 그러나 배포 도구를 사용하지 않고 클러스터를 부트스트랩하려는 경우 클러스터를 직접 생성할 수 있습니다.

편의를 위해 각 데몬에는 일련의 기본값이 있습니다. 많은 사용자가 ceph/src/common/config_opts.h 스크립트에서 설정합니다. monitor tell 명령을 사용하거나 Ceph 노드의 데몬 소켓에 직접 연결하여 Ceph 구성 파일 또는 런타임에 이러한 설정을 재정의할 수 있습니다.

Ceph는 여러 오브젝트 복사본을 만드는 것 외에도 배치 그룹을 스크럽하여 데이터 무결성을 보장합니다. Ceph 스크럽은 오브젝트 스토리지 계층의 fsck 명령과 유사합니다.

Ceph는 각 배치 그룹에 대해 모든 오브젝트의 카탈로그를 생성하고 각 기본 오브젝트와 해당 복제본을 비교하여 오브젝트가 누락되거나 일치하지 않도록 합니다.

Light scrubbing (daily)은 오브젝트 크기와 특성을 확인합니다. Deep scrubbing (weekly)은 데이터를 읽고 체크섬을 사용하여 데이터 무결성을 보장합니다.

스크럽은 데이터 무결성을 유지하는 데 중요하지만 성능을 줄일 수 있습니다. 스크럽 작업을 늘리거나 줄이기 위해 다음 설정을 조정합니다.

Ceph OSD를 클러스터에 추가하거나 클러스터에서 제거하는 경우 CRUSH 알고리즘은 배치 그룹을 Ceph OSD로 이동하거나 Ceph OSD에서 복원하여 클러스터를 재조정합니다. 배치 그룹 및 포함된 오브젝트를 마이그레이션하는 프로세스는 클러스터 운영 성능을 크게 줄일 수 있습니다. Ceph는 운영 성능을 유지하기 위해 'backfill' 프로세스를 사용하여 이 마이그레이션을 수행하므로 Ceph에서 데이터를 읽거나 쓸 요청보다 우선 순위가 낮은 우선 순위로 설정할 수 있습니다.

클러스터가 시작되거나 Ceph OSD가 예기치 않게 종료되면 쓰기 작업이 발생하기 전에 OSD가 다른 Ceph OSD와 피어링되기 시작합니다.

Ceph OSD가 충돌하여 다시 온라인 상태가 되면 일반적으로 배치 그룹에 최신 버전의 오브젝트가 포함된 다른 Ceph OSD와 동기화되지 않습니다. 이 경우 Ceph OSD가 복구 모드로 전환되고 최신 데이터 사본을 가져오고 해당 맵을 최신 상태로 되돌립니다. Ceph OSD가 중단된 기간에 따라 OSD의 오브젝트 및 배치 그룹이 최신 상태가 될 수 있습니다. 또한 장애 도메인이 다운된 경우(예: 랙) 두 개 이상의 Ceph OSD가 동시에 온라인 상태가 될 수 있습니다. 이로 인해 복구 프로세스에 시간이 많이 소비되고 리소스가 많이 소요될 수 있습니다.

Ceph는 운영 성능을 유지하기 위해 복구 요청, 스레드 및 오브젝트 청크 크기 제한으로 복구를 수행합니다. 그러면 Ceph가 성능이 저하된 상태에서 제대로 수행할 수 있습니다.

초기 Ceph 구성을 완료한 후에는 Ceph를 배포하고 실행할 수 있습니다. ceph 상태 또는 ceph -s 와 같은 명령을 실행하면 Ceph Monitor가 Ceph 스토리지 클러스터의 현재 상태에 대해 보고합니다. Ceph Monitor는 각 Ceph OSD 데몬에서 보고해야 하고, Ceph OSD 데몬에서 Ceph OSD 데몬의 상태에 대한 보고서를 수신하여 Ceph 스토리지 클러스터에 대해 알고 있습니다. Ceph Monitor가 보고서를 수신하지 않거나 Ceph 스토리지 클러스터의 변경 사항 보고가 수신되는 경우 Ceph 모니터는 Ceph 클러스터 맵의 상태를 업데이트합니다.

Ceph는 Ceph Monitor 및 OSD 상호 작용에 적절한 기본 설정을 제공합니다. 그러나 기본값을 재정의할 수 있습니다. 다음 섹션에서는 Ceph 스토리지 클러스터를 모니터링하기 위해 Ceph Monitor 및 Ceph OSD 데몬이 상호 작용하는 방법을 설명합니다.

각 Ceph OSD 데몬은 6초마다 다른 Ceph OSD 데몬의 하트비트를 확인합니다. 하트비트 간격을 변경하려면 런타임 시 값을 변경합니다.

ceph config set osd osd_heartbeat_interval TIME_IN_SECONDS

[ceph: root@host01 /]# ceph config set osd osd_heartbeat_interval 60

주변 Ceph OSD 데몬이 20초 유예 기간 내에 하트비트 패킷을 보내지 않는 경우 Ceph OSD 데몬에서 Ceph OSD 데몬을 아래로 간주할 수 있습니다. Ceph 클러스터 맵을 업데이트하는 Ceph Monitor로 다시 보고할 수 있습니다. 유예 기간을 변경하려면 런타임 시 값을 설정합니다.

ceph config set osd osd_heartbeat_grace TIME_IN_SECONDS

[ceph: root@host01 /]# ceph config set osd osd_heartbeat_grace 30

기본적으로 다른 호스트의 두 Ceph OSD 데몬은 Ceph 모니터에서 보고된 Ceph OSD 데몬이 다운된 것을 확인하기 전에 다른 Ceph OSD 데몬이 다운 되었음을 Ceph 모니터에 보고해야 합니다.

그러나 오류를 보고하는 모든 OSD가 랙의 다른 호스트에 있어 OSD 간의 연결 문제가 발생할 수 있습니다.

"false 알람"을 방지하기 위해 Ceph는 오류를 지연과 유사한 "subcluster"의 프록시로 보고하는 피어를 고려합니다. 이는 항상 그런 것은 아니지만 관리자가 제대로 작동하지 않는 시스템의 하위 집합에 대한 유예 수정 사항을 현지화하는 데 도움이 될 수 있습니다.

Ceph는 mon_osd_reporter_subtree_level 설정을 사용하여 CRUSH 맵의 공통 ancestor 유형으로 피어를 "subcluster"로 그룹화합니다.

기본적으로 다른 하위 트리의 두 보고서 만 다른 Ceph OSD 데몬 을 보고해야 합니다. 관리자는 런타임 시 mon_osd_min_ down _reporters 및 mon_osd_reporter_subtree_level 값을 설정하여 Ceph OSD 데몬을 Ceph Monitor로 보고하는 데 필요한 고유한 하위 트리 및 일반적인 ancestor 유형에서 보고자 수를 변경할 수 있습니다.

ceph config set mon mon_osd_min_down_reporters NUMBER

[ceph: root@host01 /]# ceph config set mon mon_osd_min_down_reporters 4

ceph config set mon mon_osd_reporter_subtree_level CRUSH_ITEM

[ceph: root@host01 /]# ceph config set mon mon_osd_reporter_subtree_level host
[ceph: root@host01 /]# ceph config set mon mon_osd_reporter_subtree_level rack
[ceph: root@host01 /]# ceph config set mon mon_osd_reporter_subtree_level osd

Ceph OSD 데몬이 Ceph 구성 파일 또는 클러스터 맵에 정의된 Ceph OSD 데몬을 피어링할 수 없는 경우 30초마다 클러스터 맵의 최신 사본에 대해 Ceph Monitor를 ping합니다. 런타임 시 값을 설정하여 Ceph Monitor 하트비트 간격을 변경할 수 있습니다.

ceph config set osd osd_mon_heartbeat_interval TIME_IN_SECONDS

[ceph: root@host01 /]# ceph config set osd osd_mon_heartbeat_interval 60

Ceph OSD 데몬에서 Ceph Monitor에 보고하지 않으면 mon_osd_report_timeout 다음에 Ceph OSD 데몬을 아래로 표시합니다. 이는 900초입니다. Ceph OSD 데몬은 장애, 배치 그룹 통계 변경, up_thru 의 변경 또는 5초 내에 부팅되는 경우 보고 가능한 이벤트가 있는 경우 Ceph OSD 데몬으로 보고서를 Ceph Monitor로 보냅니다.

런타임 시 osd_mon_report_interval 값을 설정하여 Ceph OSD Daemon 최소 보고서 간격을 변경할 수 있습니다.

ceph config set osd osd_mon_report_interval TIME_IN_SECONDS

다음 예제를 사용하여 구성을 설정하고 확인합니다.

[ceph: root@host01 /]# ceph config get osd osd_mon_report_interval
5
[ceph: root@host01 /]# ceph config set osd osd_mon_report_interval 20
[ceph: root@host01 /]# ceph config dump | grep osd

global                  advanced  osd_pool_default_crush_rule                  -1
  osd                   basic     osd_memory_target                            4294967296
  osd                   advanced  osd_mon_report_interval                      20