모든 Red Hat Ceph Storage 클러스터에는 다음을 정의하는 구성이 있습니다.

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

Ceph Monitor는 전체 스토리지 클러스터에 대한 구성 옵션을 저장하여 구성 관리를 중앙 집중화하는 Ceph 옵션의 구성 데이터베이스를 관리합니다. 데이터베이스에서 Ceph 구성을 중앙 집중화하면 스토리지 클러스터 관리가 도움이 됩니다. 로컬 Ceph 구성 파일인 /etc/ceph/ceph.conf 에는 여전히 몇 가지 Ceph 옵션을 정의할 수 있습니다. 이러한 Ceph 구성 옵션은 다른 Ceph 구성 요소가 인증할 Ceph 모니터에 연결하는 방법을 제어하고 데이터베이스에서 구성 정보를 가져오는 방법을 제어합니다.

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

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

Ceph 구성 파일은 시작 시 Ceph 데몬을 구성하여 기본값을 재정의합니다.

Ceph의 기본 구성 파일의 위치는 /etc/ceph/ceph.conf 입니다. 다음과 같이 다른 경로를 설정하여 해당 위치를 변경할 수 있습니다.

Ceph 구성 파일은 ini 스타일 구문을 사용합니다. 파운드 기호(#) 또는 세미콜론(;)을 사용하여 앞의 주석을 추가할 수 있습니다.

# <--A pound sign (#) sign precedes a comment.
# Comments always follow a semi-colon (;) or a pound (#) on each line.
# The end of the line terminates a comment.
# We recommend that you provide comments in your configuration file(s).
; A comment may be anything.

구성 파일은 Ceph 스토리지 클러스터의 모든 Ceph 데몬 또는 시작 시 특정 유형의 모든 Ceph 데몬을 구성할 수 있습니다. 일련의 데몬을 구성하려면 다음과 같이 구성을 수신할 프로세스에 설정을 포함해야 합니다.

    [mon.host01]
     `host = host01`
     `mon_addr = 10.0.0.101`
    [mon.host02]
     `host = host02`
     `mon_addr = 10.0.0.102`

글로벌 설정은 Ceph 스토리지 클러스터의 모든 데몬 인스턴스에 영향을 줍니다. [global] 제목을 Ceph 스토리지 클러스터의 모든 데몬에 공통인 값으로 사용합니다. 다음을 통해 각 [global] 옵션을 재정의할 수 있습니다.

OR

글로벌 설정을 재정의하면 특정 데몬에서 구체적으로 재정의하는 프로세스를 제외하고 모든 하위 프로세스에 영향을 미칩니다.

일반적인 글로벌 설정에는 인증 활성화가 포함됩니다.

[global]
#Enable authentication between hosts within the cluster.
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx

특정 유형의 데몬에 적용되는 설정을 지정할 수 있습니다. 특정 인스턴스를 지정하지 않고 [osd] 또는 [mon] 아래의 설정을 지정하는 경우 설정이 모든 OSD 또는 모니터 데몬에 각각 적용됩니다. 데몬 전체 설정의 한 가지 예는 osd 메모리 타겟입니다.

[osd]
osd_memory_target = 5368709120

데몬의 특정 인스턴스에 대한 설정을 지정할 수 있습니다. 유형을 입력하고 마침표(.)로 구분된 인스턴스 ID로 구분하여 인스턴스를 지정할 수 있습니다. Ceph OSD 데몬의 인스턴스 ID는 항상 숫자이지만 Ceph 모니터의 영숫자일 수 있습니다.

[osd.1]
# settings affect osd.1 only.

[mon.a]
# settings affect mon.a only.

일반적인 Ceph 구성 파일에는 최소한 다음 설정이 있습니다.

[global]
fsid = UNIQUE_CLUSTER_ID
mon_initial_members = NODE_NAME[, NODE_NAME]
mon_host = IP_ADDRESS[, IP_ADDRESS]

#All clusters have a front-side public network.
#If you have two NICs, you can configure a back side cluster
#network for OSD object replication, heart beats, backfilling,
#recovery, and so on
public_network = PUBLIC_NET[, PUBLIC_NET]
#cluster_network = PRIVATE_NET[, PRIVATE_NET]

#Clusters require authentication by default.
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx

#Choose reasonable numbers for your number of replicas
#and placement groups.
osd_pool_default_size = NUM  # Write an object n times.
osd_pool_default_min_size = NUM # Allow writing n copy in a degraded state.
osd_pool_default_pg_num = NUM
osd_pool_default_pgp_num = NUM

#Choose a reasonable crush leaf type.
#0 for a 1-node cluster.
#1 for a multi node cluster in a single rack
#2 for a multi node, multi chassis cluster with multiple hosts in a chassis
#3 for a multi node cluster with hosts across racks, and so on
osd_crush_chooseleaf_type = NUM

[global]
cluster network = 10.74.250.101/21
fsid = 3e07d43f-688e-4284-bfb7-3e6ed5d3b77b
mon host = [v2:10.0.0.101:3300/0,v1:10.0.0.101:6789/0] [v2:10.0.0.102:3300/0,v1:10.0.0.102:6789/0] [v2:10.0.0.103:3300/0,v1:10.0.0.103:6789/0]
mon initial members = host01, host02, host03
osd pool default crush rule = -1
public network = 10.74.250.101/21

[osd]
osd memory target = 4294967296

[mon]
    [mon.host01]
     host = host01
     mon_addr = 10.0.0.101
    [mon.host02]
     host = host02
     mon_addr = 10.0.0.102

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

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

Ceph에서는 다음과 같은 메타 변수를 지원합니다.

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

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

런타임 구성을 설정하는 일반적인 방법은 두 가지가 있습니다.

tell 및 injectargs 명령을 사용하여 모니터에 연결하여 Ceph 런타임 구성 옵션을 설정할 수 있습니다.

bluestore는 osd_memory_target 구성 옵션을 사용하여 OSD 힙 메모리 사용량을 지정된 대상 크기 미만으로 유지합니다.

osd_memory_target 옵션은 시스템에서 사용 가능한 RAM에 따라 OSD 메모리를 설정합니다. 기본적으로 Ansible은 값을 4GB로 설정합니다. 데몬을 배포할 때 /usr/share/ceph-ansible/group_vars/all.yml 파일에서 바이트로 표현된 값을 변경할 수 있습니다. ceph.conf 파일에서 Ceph 재정의를 사용하여 osd 메모리 대상 (예: 6GB)을 수동으로 설정할 수도 있습니다.

ceph_conf_overrides:
  osd:
    osd memory target: 6442450944

캐시 적중의 이점이 솔리드 스테이트 드라이브보다 훨씬 높기 때문에 블록 장치가 블록 장치(예: 기존 하드 드라이브)가 느리면 Ceph OSD 메모리 캐싱이 훨씬 더 중요합니다. 그러나 HCI(하이퍼 컨버지드 인프라) 또는 기타 애플리케이션과 같은 다른 서비스와 함께 OSD를 공동 배치하려면 이 작업을 측정해야 합니다.

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

예제: mds_cache_memory_limit 를 2GiB로 설정합니다.

ceph_conf_overrides:
  osd:
    mds_cache_memory_limit: 2147483648

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

모든 Ceph 클러스터에서 공용 네트워크를 사용해야 합니다. 그러나 내부 클러스터 네트워크를 지정하지 않는 한 Ceph는 단일 공용 네트워크를 가정합니다. Ceph는 공용 네트워크에서만 작동할 수 있지만 대규모 스토리지 클러스터의 경우 클러스터 관련 트래픽만 전달하는 두 번째 사설 네트워크에서 성능이 향상됩니다.

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

두 개의 개별 네트워크를 운영하는 데에는 몇 가지 이유가 있습니다.

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

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

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

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

호스트 이름을 지정하여 데몬이 있는 위치의 호스트 이름과 IP 주소를 설정할 수 있습니다 .

[mon.a]
    host = host01
    mon_addr = 10.0.0.101:6789, 10.0.0.101:3300

[osd.0]
    host = host02

데몬의 노드 IP 주소를 설정할 필요는 없으며 선택 사항입니다. 정적 IP 구성과 공용 및 사설 네트워크가 모두 실행 중인 경우 Ceph 구성 파일에서 각 데몬에 대해 노드의 IP 주소를 지정할 수 있습니다. 데몬의 고정 IP 주소를 설정하면 Ceph 구성 파일의 데몬 인스턴스 섹션에 표시되어야 합니다.

[osd.0]
    public_addr = 10.74.250.101/21
    cluster_addr = 10.74.250.101/21

OSD 호스트를 강제 적용하여 두 개의 네트워크를 사용하여 클러스터에 단일 NIC를 사용하여 OSD 호스트를 배포할 수 있습니다. Ceph 구성 파일의 [osd.n] 섹션에 공용 주소 항목을 추가하여 OSD 호스트가 공용 네트워크에서 강제로 작동하도록 할 수 있습니다. 여기서 n 은 하나의 NIC가 있는 OSD 수를 나타냅니다. 또한 공용 네트워크와 클러스터 네트워크는 트래픽을 서로 라우팅할 수 있어야 합니다. Red Hat은 보안상의 이유로 권장하지 않습니다.

collectd은 Ceph 네트워크 계층 구현입니다. Red Hat은 다음과 같은 두 가지 유형을 지원합니다.

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

공용 네트워크 구성을 사용하면 공용 네트워크의 IP 주소와 서브넷을 구체적으로 정의할 수 있습니다. 특정 데몬에 공용 주소 설정을 사용하여 정적 IP 주소를 구체적으로 할당하거나 공용 네트워크 설정을 재정의할 수 있습니다.

[global]
    ...
    public_network = PUBLIC-NET/NETMASK

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

클러스터 네트워크 구성을 사용하면 클러스터 네트워크를 선언하고 클러스터 네트워크의 IP 주소 및 서브넷을 구체적으로 정의할 수 있습니다. 특정 OSD 데몬에 대해 클러스터 주소 설정을 사용하여 정적 IP 주소를 구체적으로 할당하거나 클러스터 네트워크 설정을 덮어쓸 수 있습니다.

[global]
    ...
    cluster_network = CLUSTER-NET/NETMASK

기본적으로 데몬은 6800:7100 범위 내의 포트에 바인딩됩니다. 재량에 따라 이 범위를 구성할 수 있습니다. 방화벽을 구성하기 전에 기본 방화벽 구성을 확인합니다.

Ceph 모니터는 기본적으로 포트 3300 및 6789 에서 수신 대기합니다. 또한 Ceph 모니터는 항상 공용 네트워크에서 작동합니다.

기본적으로 Ceph OSD는 포트 6800부터 Ceph 노드의 첫 번째 사용 가능한 포트에 바인딩됩니다. 노드에서 실행되는 각 OSD의 포트 6800에서 최소 4개의 포트를 열어야 합니다.

포트는 노드별로 다릅니다. 그러나 프로세스가 다시 시작되고 바인딩된 포트가 릴리스되지 않는 경우 해당 Ceph 노드에서 실행 중인 Ceph 데몬에 필요한 포트 수보다 많은 포트를 열어야 할 수 있습니다. 다시 시작한 데몬이 새 포트에 바인드되도록 데몬이 실패하고 포트를 해제하지 않고 다시 시작하는 경우 몇 가지 추가 포트를 여는 것이 좋습니다. 또한 각 OSD 노드에서 포트 범위를 6800:7300 으로 여는 것이 좋습니다.

별도의 공용 네트워크와 클러스터 네트워크를 설정하는 경우 클라이언트가 공용 네트워크를 사용하여 연결되고 다른 Ceph OSD 데몬이 클러스터 네트워크를 사용하여 연결되므로 공용 네트워크와 클러스터 네트워크 모두에 대한 규칙을 추가해야 합니다.

클러스터 네트워크를 다른 영역에 배치하는 경우 해당 영역의 포트를 적절하게 엽니다.

MTU(최대 전송 단위) 값은 링크 계층에서 전송된 가장 큰 패킷의 크기(바이트)입니다. 기본 MTU 값은 1500바이트입니다. Red Hat Ceph Storage 클러스터에 대해 점보 프레임인 MTU 값 9000바이트를 사용하는 것이 좋습니다.

신뢰할 수 있는 Red Hat Ceph Storage 클러스터를 구축하는 데 있어 Ceph Monitor를 구성하는 방법을 이해하는 것이 중요합니다. 모든 스토리지 클러스터에는 모니터가 하나 이상 있습니다. Ceph 모니터 구성은 일반적으로 상당히 일관되게 유지되지만 스토리지 클러스터에서 Ceph 모니터를 추가, 제거 또는 교체할 수 있습니다.

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

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

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

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

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

Red Hat Ceph Storage 클러스터를 작동하는 경우 이러한 상태를 유지하는 것은 클러스터 관리에서 중요한 부분입니다.

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

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

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

[mon]
mon_initial_members = a,b,c

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

Red Hat Ceph Storage 클러스터에서 다른 Ceph 모니터를 검색할 때 Ceph 모니터는 항상 모니터 맵의 로컬 사본을 참조합니다. Ceph 구성 파일 대신 모니터 맵을 사용하면 클러스터가 중단될 수 있는 오류가 방지됩니다. 예를 들어 모니터 주소 또는 포트를 지정할 때 Ceph 구성 파일의 오타입니다. 모니터 맵은 검색을 위해 모니터 맵을 사용하고 클라이언트 및 기타 Ceph 데몬과 모니터 맵을 공유하므로 모니터 맵은 모니터에 합의가 유효하다는 엄격한 보장을 제공합니다.

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

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

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

전체 클러스터에 구성 설정을 적용하려면 [global] 섹션 아래의 구성 설정을 입력합니다. 클러스터의 모든 모니터에 구성 설정을 적용하려면 [mon] 섹션 아래의 구성 설정을 입력합니다. 특정 모니터에 구성 설정을 적용하려면 monitor 인스턴스를 지정합니다.

관례적으로, 모니터링 인스턴스 이름은 영숫자 표기법을 사용합니다.

[global]

[mon]

[mon.a]

[mon.b]

[mon.c]

Ceph 구성 파일의 Ceph 모니터에 대한 베어 최소 모니터 설정에는 DNS 및 모니터 주소에 대해 구성되지 않은 경우 각 모니터의 호스트 이름이 포함됩니다. [mon] 또는 특정 모니터의 항목 아래에 이러한 항목을 구성할 수 있습니다.

[mon]
mon_host = hostname1,hostname2,hostname3
mon_addr = 10.0.0.10:6789,10.0.0.11:6789,10.0.0.12:6789,10.0.0.10:3300,10.0.0.11:3300,10.0.0.12:3300

또는

[mon.a]
host = hostname1
mon_addr = 10.0.0.10:6789, 10.0.0.10:3300

DNS 조회를 위해 Ceph 클러스터를 구성하려면 Ceph 구성 파일에서 mon_dns_srv_name 설정을 설정합니다.

설정되고 나면 DNS를 구성합니다. DNS 영역의 모니터에 대한 IPv4(A) 또는 IPv6(AAAA) 레코드를 만듭니다.

#IPv4
mon1.example.com. A 192.168.0.1
mon2.example.com. A 192.168.0.2
mon3.example.com. A 192.168.0.3

#IPv6
mon1.example.com. AAAA 2001:db8::100
mon2.example.com. AAAA 2001:db8::200
mon3.example.com. AAAA 2001:db8::300

여기서: example.com 은 DNS 검색 도메인입니다.

그런 다음 세 개의 모니터를 가리키는 mon_dns_srv_name 구성 설정을 사용하여 SRV TCP 레코드를 만듭니다. 다음 예제에서는 기본 ceph-mon 값을 사용합니다.

_ceph-mon._tcp.example.com. 60 IN SRV 10 60 6789 mon1.example.com.
_ceph-mon._tcp.example.com. 60 IN SRV 10 60 6789 mon2.example.com.
_ceph-mon._tcp.example.com. 60 IN SRV 10 60 6789 mon3.example.com.
_ceph-mon._tcp.example.com. 60 IN SRV 10 60 3300 mon1.example.com.
_ceph-mon._tcp.example.com. 60 IN SRV 10 60 3300 mon2.example.com.
_ceph-mon._tcp.example.com. 60 IN SRV 10 60 3300 mon3.example.com.

모니터는 기본적으로 포트 6789 및 3300 에서 실행되며 우선 순위 및 가중치는 모두 각각 10 및 60 으로 설정되어 있습니다.

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

Ceph는 Ceph에서 데이터를 모니터링하는 기본 경로를 제공합니다.

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

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

Red Hat Ceph Storage 클러스터가 최대 용량( mon_osd_full_ratio 매개변수에서 지정)에 가까운 위치에 도달하면 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 노드가 포함되어 있으며 각 Ceph OSD 데몬이 3TB 드라이브에서 읽고 쓰는 각 Ceph OSD 데몬이 포함된 간단한 Red Hat Ceph Storage 클러스터를 보여줍니다. 따라서 이 예제의 Red Hat Ceph Storage 클러스터는 최대 99TB의 실제 용량을 갖습니다. mond 의 전체 비율이 4.85인 경우 Red Hat Ceph Storage 클러스터가 5TB의 나머지 용량으로 떨어지면 클러스터에서 Ceph 클라이언트가 데이터를 읽고 쓸 수 없습니다. 따라서 Red Hat Ceph Storage 클러스터의 운영 용량은 99TB가 아닌 95TB입니다.

이러한 클러스터의 경우 하나 또는 두 개의 OSD가 실패하는 것이 일반적입니다. 덜 빈번하지만 합리적인 시나리오에는 랙의 라우터 또는 전원 공급 장치 장애가 발생하기 때문에 OSD 7-12와 같이 동시에 여러 개의 OSD가 중단됩니다. 이러한 시나리오에서는 작동 상태를 유지하고 활성 + 클린 상태가 될 수 있는 클러스터를 위해 계속 노력해야 합니다. 즉, 추가 OSD가 있는 몇 개의 호스트를 짧은 순서로 추가하는 경우에도 마찬가지입니다. 용량 사용률이 너무 높으면 데이터가 손실되지 않을 수 있지만 클러스터의 용량 사용률이 전체 비율을 초과하면 장애 도메인 내에서 중단을 해결하는 동안 데이터 가용성을 희생할 수 있습니다. 이러한 이유로 최소한 대략적인 용량 계획을 수립하는 것이 좋습니다.

클러스터의 두 숫자를 확인합니다.

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

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

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

이러한 역할을 사용하면 리더가 동기화 작업을 프로바이더에 위임하여 동기화 요청이 리더에 과부하되고 성능이 향상되지 않도록 할 수 있습니다. 다음 다이어그램에서 요청자는 다른 모니터 뒤에서 떨어지는 것을 배웠습니다. 요청자는 리더에게 동기화하도록 요청하고 리더는 요청자에게 공급자와 동기화하도록 지시합니다.

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

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 을 해당 호스트 이름으로 바꿉니다.

권장되지 않는 키 설정을 사용하여 Ceph 구성 파일에서 키 자체를 지정하거나 key file 설정을 사용하여 키 파일에 대한 경로를 지정할 수 있습니다.

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

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

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

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

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

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

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

pool 명령을 실행할 때 이러한 값을 설정할 수 있습니다. Ceph 구성 파일의 [global] 섹션에 새 기본값을 추가하여 기본값을 재정의할 수도 있습니다.

[global]

# By default, Ceph makes 3 replicas of objects. If you want to set 4
# copies of an object as the default value--a primary copy and three replica
# copies--reset the default values as shown in 'osd pool default size'.
# If you want to allow Ceph to write a lesser number of copies in a degraded
# state, set 'osd pool default min size' to a number less than the
# 'osd pool default size' value.

osd_pool_default_size = 4  # Write an object 4 times.
osd_pool_default_min_size = 1 # Allow writing one copy in a degraded state.

# Ensure you have a realistic number of placement groups. We recommend
# approximately 100 per OSD. E.g., total number of OSDs multiplied by 100
# divided by the number of replicas (i.e., osd pool default size). So for
# 10 OSDs and osd pool default size = 4, we'd recommend approximately
# (100 * 10) / 4 = 250.

osd_pool_default_pg_num = 250
osd_pool_default_pgp_num = 250

모든 Ceph 클러스터에는 다음을 정의하는 구성이 있습니다.

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

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

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

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

가벼운 스크럽(daily)은 개체 크기 및 특성을 확인합니다. 심층 스크럽(주별)은 데이터를 읽고 체크섬을 사용하여 데이터 무결성을 보장합니다.

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

클러스터에 Ceph OSD를 추가하거나 클러스터에서 제거하면 CRUSH 알고리즘에서 배치 그룹을 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 Monitor에서 Ceph 클러스터 맵의 상태를 업데이트합니다.

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

각 Ceph OSD 데몬은 6초마다 다른 Ceph OSD 데몬의 하트비트를 확인합니다. heartbeat 간격을 변경하려면 Ceph 구성 파일의 [osd] 섹션에 osd heartbeat 간격 설정을 추가하거나 런타임 시 값을 변경합니다.

인접 Ceph OSD 데몬이 20초의 유예 기간 내에 하트비트 패킷을 전송하지 않으면 Ceph OSD 데몬에서 인접 Ceph OSD 데몬을 중단할 수 있습니다. Ceph 클러스터 맵을 업데이트할 Ceph 모니터로 다시 보고할 수 있습니다. 이 유예 기간을 변경하려면 Ceph 구성 파일의 [osd] 섹션에 osd heartbeat grace 설정을 추가하거나 런타임에 해당 값을 설정합니다.

기본적으로 다른 호스트의 Ceph OSD 데몬 2개가 Ceph OSD 데몬이 다운되었음을 확인하기 전에 Ceph OSD 데몬이 다운 되었음을 보고해야 합니다 .

그러나 오류를 보고하는 모든 OSD가 잘못된 스위치가 있는 랙의 다른 호스트에 있어 OSD 간 연결 문제가 발생할 가능성이 있습니다.

Ceph는 "false 알람"을 방지하기 위해 피어가 실패를 "하위 클러스터"의 프록시로 보고하는 것으로 간주합니다. 이러한 경우가 항상인 것은 아니지만 관리자가 제대로 수행하지 못하는 시스템의 하위 집합에 유예 수정 사항을 로컬라이제이션하는 데 도움이 될 수 있습니다.

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

기본적으로 다른 Ceph OSD Daemon을 보고 하려면 다른 하위 트리 의 보고서 2개만 필요합니다 . 관리자는 Ceph 구성 파일의 [mon] 섹션에서 또는 런타임에 값을 설정하여 Ceph OSD Daemon 을 Ceph Monitor에 보고하는 데 필요한 고유한 하위 트리의 보고자 수 및 mon_osd_reporter_subtree_level 설정을 변경할 수 있습니다.

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

Ceph OSD 데몬이 Ceph 모니터에 보고하지 않으면 Ceph Monitor에서 mon osd 보고서 시간 초과 경과 후 Ceph OSD 데몬이 다운 된 것으로 간주합니다. Ceph OSD 데몬은 실패와 같은 보고 가능한 이벤트, 배치 그룹 통계 변경, up_thru 가 변경되거나 5초 이내에 부팅되는 경우 Ceph 모니터로 보고서를 보냅니다. Ceph 구성 파일의 [osd] 섹션에 osd mon 보고서 간격을 추가하거나 런타임에 값을 설정하여 Ceph OSD 데몬 최소 보고서 간격을 변경할 수 있습니다.

Ceph OSD 데몬은 주요 변경 사항이 발생하는 여부와 관계없이 120초마다 Ceph 모니터에 보고서를 보냅니다. Ceph 구성 파일의 [osd] 섹션에 osd mon 보고서 간격 max 설정을 추가하거나 런타임 시 값을 설정하여 Ceph Monitor 보고서 간격을 변경할 수 있습니다.

디버그 설정은 Ceph 구성 파일에 필요하지 않지만 로깅을 최적화하기 위해 추가할 수 있습니다. Ceph 로깅 구성에 대한 변경 사항은 일반적으로 문제가 발생할 때 런타임에 발생하지만 Ceph 구성 파일에서 수정할 수도 있습니다. 예를 들어 클러스터를 시작할 때 문제가 있는 경우 Ceph 구성 파일에서 로그 설정을 늘리는 것이 좋습니다. 문제가 해결되면 설정을 제거하거나 런타임 작업에 대한 최적의 설정으로 복원합니다.

기본적으로 /var/log/ceph 아래에 있는 Ceph 로그 파일을 봅니다.

로깅은 리소스를 많이 사용합니다. 클러스터의 특정 영역에 문제가 있는 경우 클러스터의 해당 영역에 대한 로깅을 활성화합니다. 예를 들어 OSD가 제대로 실행되고 있지만 Ceph 개체 게이트웨이는 실행되지 않는 경우 문제가 발생하는 특정 게이트웨이 인스턴스에 대해 디버그 로깅을 활성화하여 시작합니다. 필요에 따라 각 하위 시스템에 대한 로깅을 늘리거나 줄입니다.

Ceph 로깅이 활성화되거나 로깅 속도가 증가된 경우 OS 디스크의 용량이 충분한지 확인합니다.

클러스터가 잘 실행되면 불필요한 디버깅 설정을 제거하여 클러스터가 최적으로 실행되도록 합니다. 디버그 출력 메시지를 로깅하는 것은 비교적 느리며 클러스터를 작동할 때 리소스가 낭비됩니다.