3.2. Ceph 스토리지 클러스터의 하위 수준 모니터링

CRUSH가 Ceph OSD에 배치 그룹을 할당하면 풀의 복제본 수를 살펴보고 배치 그룹의 각 복제본이 다른 Ceph OSD에 할당되도록 배치 그룹을 Ceph OSD에 할당합니다. 예를 들어 풀에 배치 그룹의 복제본이 세 개 필요한 경우 CRUSH가 osd.1,osd.2 및 osd.3 에 각각 할당할 수 있습니다. CRUSH는 실제로 CRUSH 맵에서 설정한 실패 도메인을 고려할 의사 임의의 배치를 사용하므로 대규모 클러스터에서 가장 가까운 인접 Ceph OSD에 할당된 배치 그룹을 거의 볼 수 없습니다. 특정 배치 그룹의 복제본을 Acting Set 로 포함해야 하는 Ceph OSD 세트를 참조하십시오. 경우에 따라 Acting Set의 OSD가 다운 되었거나 배치 그룹의 개체에 대한 요청을 서비스할 수 없는 경우가 있습니다. 이러한 상황이 발생하면 패닉에 빠질 수 없습니다. 일반적인 예는 다음과 같습니다.

Ceph는 실제로 요청을 처리하는 Ceph OSD 세트인 Up Set 를 사용하여 클라이언트 요청을 처리합니다. 대부분의 경우 up 세트와 Acting Set는 사실상 동일합니다. Ceph가 데이터를 마이그레이션하지 않거나 Ceph OSD가 복구되었거나 문제가 있음을 나타낼 수 있습니다. 즉, Ceph는 일반적으로 이러한 시나리오에서 "stuck stale" 메시지와 함께 HEALTH WARN 상태를 에코합니다.

배치 그룹에 데이터를 쓰기 전에 먼저 활성 상태여야 하며 정리 된 상태 여야 합니다. Ceph가 배치 그룹의 현재 상태, 즉 작동 세트의 첫 번째 OSD인 배치 그룹의 기본 OSD를 확인하기 위해 보조 및 세 번째 OSD를 사용한 피어로 배치 그룹의 현재 상태에 대한 합의를 설정합니다. PG의 세 개의 복제본이 있는 풀을 가정합니다.

그림 3.1. peering

ceph 상태 ,ceph -s 또는 ceph -w 와 같은 명령을 실행하는 경우 클러스터가 HEALTH OK 를 항상 표시하지 않는 것을 확인할 수 있습니다. OSD가 실행 중인지 확인한 후 배치 그룹 상태도 확인해야 합니다. 여러 배치 그룹 피어링 관련 상황에서 클러스터가 HEALTH OK 를 표시 하지 않아야 합니다.

관련 상황 중 하나가 Ceph가 HEALTH WARN 을 에코하도록 하는 경우 패닉을 발휘하지 마십시오. 대부분의 경우 클러스터가 자체적으로 복구됩니다. 경우에 따라 조치를 취해야 할 수도 있습니다. 배치 그룹을 모니터링하는 중요한 측면은 클러스터가 모든 배치 그룹이 활성 상태인지, 가장 바람직하게 실행 중인지 확인하는 것입니다.

모든 배치 그룹의 상태를 보려면 다음을 실행합니다.

[ceph: root@host01 /]# ceph pg stat

결과적으로 배치 그룹 맵 버전, vNNNNNN, 총 배치 그룹 수, x, 배치 그룹 수, y.가 active+clean 과 같은 특정 상태에 있음을 알 수 있습니다.

vNNNNNN: x pgs: y active+clean; z bytes data, aa MB used, bb GB / cc GB avail

출력 예:

244 active+clean+snaptrim_wait
 32 active+clean+snaptrim

Ceph는 배치 그룹 상태 외에도 사용된 데이터 양, aa, 스토리지 용량은 나머지 스토리지 용량, bb, 배치 그룹의 총 스토리지 용량을 반환합니다. 이러한 수치는 몇 가지 경우에 중요할 수 있습니다.

POOL_NUM.PG_ID

출력 예:

0.1f

풀을 만들면 지정한 배치 그룹 수가 생성됩니다. Ceph는 하나 이상의 배치 그룹을 만들 때 생성 을 에코합니다. 배치 그룹이 생성되면 배치 그룹의 Acting Set에 속하는 OSD가 피어링됩니다. 피어링이 완료되면 배치 그룹 상태가 active+clean 여야 합니다. 즉, Ceph 클라이언트가 배치 그룹에 쓰기를 시작할 수 있습니다.

Ceph가 배치 그룹을 피어링하는 경우 Ceph는 배치 그룹의 복제본을 저장하는 OSD를 배치 그룹 의 개체 및 메타데이터의 상태에 대해 합의합니다. Ceph가 피어링을 완료하면 배치 그룹을 저장하는 OSD가 배치 그룹의 현재 상태에 대해 동의합니다. 그러나 피어링 프로세스를 완료해도 각 복제본에 최신 콘텐츠가 포함되어 있지 않습니다.

확인된 각 쓰기 작업의 정확한 레코드로 Ceph는 배치 그룹의 새로운 권한 있는 이력을 구성하고 배포할 수 있습니다. 완료되면 배치 그룹의 OSD 복사본을 최신 상태로 가져오는 완전한 정렬 작업 세트가 수행됩니다.

Ceph가 피어링 프로세스를 완료하면 배치 그룹이 활성 상태가 될 수 있습니다. 활성 상태는 배치 그룹의 데이터를 일반적으로 기본 배치 그룹 및 읽기 및 쓰기 작업에 대한 복제본에서 사용할 수 있음을 의미합니다.

배치 그룹이 정리 상태에 있으면 기본 OSD와 복제본 OSD가 성공적으로 피어링되고 배치 그룹에 대한 stray 복제본이 없습니다. Ceph는 배치 그룹의 모든 오브젝트를 올바른 횟수로 복제했습니다.

클라이언트가 기본 OSD에 개체를 쓸 때 기본 OSD는 복제본 OSD에 복제본을 작성합니다. 기본 OSD는 오브젝트를 스토리지에 쓴 후 Ceph가 복제본 오브젝트를 성공적으로 생성한 복제본 OSD에서 승인을 받을 때까지 배치 그룹이 성능 저하 상태로 유지됩니다.

배치 그룹이 활성+degraded 일 수 있는 이유는 아직 모든 오브젝트를 보유하지 않더라도 OSD가 활성화 될 수 있기 때문입니다. OSD가 다운 된 경우 Ceph는 OSD에 할당된 각 배치 그룹을 성능 저하 로 표시합니다. Ceph OSD가 다시 온라인 상태가 되면 Ceph OSD가 다시 피어링해야 합니다. 그러나 클라이언트는 활성화 된 경우 성능이 저하된 배치 그룹에 새 개체를 작성할 수 있습니다.

OSD가 다운 되어 성능이 저하된 조건이 지속되면 Ceph에서 OSD를 클러스터 외부에서 표시하고 다운 OSD에서 다른 OSD로 데이터를 다시 매핑할 수 있습니다. 표시된 것과 표시된 사이의 시간은 기본적으로 600 초로 설정된 mon_osd_ down _ out _interval 에 의해 제어됩니다.

Ceph가 배치 그룹에 있다고 생각되는 하나 이상의 개체를 찾을 수 없기 때문에 배치 그룹 성능이 저하 될 수도 있습니다. unfound 개체를 읽거나 쓸 수는 없지만 성능이 저하된 배치 그룹의 다른 모든 개체에 계속 액세스할 수 있습니다.

예를 들어 세 가지 방법으로 복제본 풀의 OSD 9개가 있는 경우. OSD 번호 9가 다운되면 OSD 9에 할당된 PG가 저하된 상태가 됩니다. OSD 9가 복구되지 않으면 스토리지 클러스터에서 벗어나 스토리지 클러스터의 균형을 다시 조정합니다. 이 시나리오에서는 PG가 저하된 다음 활성 상태로 복구됩니다.

Ceph는 하드웨어와 소프트웨어 문제가 지속적으로 발생하는 규모에 대한 장애 발생을 위해 설계되었습니다. OSD가 다운 되면 해당 콘텐츠는 배치 그룹의 다른 복제본의 현재 상태 뒤에 떨어질 수 있습니다. OSD가 백업 되면 현재 상태를 반영하도록 배치 그룹의 콘텐츠를 업데이트해야 합니다. 이 기간 동안 OSD는 복구 상태를 반영할 수 있습니다.

하드웨어 장애로 인해 여러 Ceph OSD가 계단식으로 실패할 수 있으므로 복구가 항상 간단한 것은 아닙니다. 예를 들어 랙 또는 캐비닛의 네트워크 스위치가 실패할 수 있으므로 여러 호스트 시스템의 OSD가 스토리지 클러스터의 현재 상태에 떨어질 수 있습니다. 각 OSD는 오류가 해결되면 복구해야 합니다.

Ceph는 새 서비스 요청 간 리소스 경합과 데이터 개체를 복구하고 배치 그룹을 현재 상태로 복원하는 필요성 간의 균형을 유지하는 다양한 설정을 제공합니다. osd 복구 지연 시작 설정을 사용하면 OSD가 복구 프로세스를 시작하기 전에 일부 재생 요청을 다시 시작하고 다시 실행할 수 있습니다. osd 복구 스레드 설정은 기본적으로 하나의 스레드로 복구 프로세스의 스레드 수를 제한합니다. 여러 Ceph OSD가 실패, 재시작 및 staggered rate에서 피어를 다시 시작할 수 있으므로 osd 복구 스레드 시간 초과는 스레드 시간 초과를 설정합니다. osd 복구 max 활성 설정은 Ceph OSD가 동시에 작동하는 복구 요청 수를 제한하여 Ceph OSD를 서비스하지 않도록 합니다. osd 복구 max chunk 설정은 네트워크 혼잡을 방지하기 위해 복구된 데이터 청크의 크기를 제한합니다.

새 Ceph OSD가 스토리지 클러스터에 참여하면 CRUSH가 클러스터의 OSD에서 새로 추가된 Ceph OSD에 배치 그룹을 다시 할당합니다. 새 OSD가 재 할당 배치 그룹을 즉시 수락하도록 강제 적용하면 새 Ceph OSD에 과도한 부하를 줄 수 있습니다. 배치 그룹으로 OSD를 다시 채우면 이 프로세스가 백그라운드에서 시작됩니다. 백필이 완료되면 새 OSD가 준비되면 요청 제공을 시작합니다.

백필 작업 중에 다음과 같은 몇 가지 상태 중 하나가 표시될 수 있습니다.

배치 그룹을 다시 채울 수 없는 경우 불완전 한 것으로 간주될 수 있습니다.

Ceph는 특히 새 Ceph OSD에 배치 그룹을 재할당하는 것과 관련된 부하 급증을 관리할 수 있는 여러 가지 설정을 제공합니다. 기본적으로 osd_max_backfills 는 Ceph OSD에서 Ceph OSD로 또는 10으로 동시 백필의 최대 수를 설정합니다. osd 백필 비율을 사용하면 OSD가 전체 비율 (기본적으로 85%)에 접근하면 Ceph OSD에서 백필 요청을 거부할 수 있습니다. OSD에서 백필 요청을 거부하면 osd backfill 재시도 간격 을 사용하면 OSD에서 기본적으로 10초 후에 요청을 재시도할 수 있습니다. OSD는 osd backfill scan min 및 osd backfill scan max 를 설정하여 기본적으로 64 및 512의 검사 간격을 관리할 수 있습니다.

일부 워크로드의 경우 일반 복구를 완전히 방지하고 대신 백필을 사용하는 것이 좋습니다. 백필이 백그라운드에서 이루어지므로 OSD의 개체를 I/O로 진행할 수 있습니다. osd_min_pg_log_entries 옵션을 1 로 설정하고 osd_max_pg_log_entries 옵션을 2 로 설정하여 복구 대신 백필을 강제 적용할 수 있습니다. 이 상황이 워크로드에 적합한 시기에 대한 자세한 내용은 Red Hat 지원 계정 팀에 문의하십시오.

Acting Set that services a placement group이 변경되면 데이터는 이전 동작 세트에서 새로운 동작 세트로 마이그레이션됩니다. 새로운 기본 OSD가 서비스 요청을 처리하는 데 다소 시간이 걸릴 수 있습니다. 따라서 배치 그룹 마이그레이션이 완료될 때까지 이전 주에서 서비스 요청을 계속 실행하도록 요청할 수 있습니다. 데이터 마이그레이션이 완료되면 매핑은 새로운 동작 세트의 기본 OSD를 사용합니다.

Ceph는 하트비트를 사용하여 호스트 및 데몬이 실행 중인지 확인하지만 ceph-osd 데몬은 통계를 적시에 보고하지 않는 상태가 끊긴 상태가 될 수도 있습니다. 예를 들어, 일시적인 네트워크 오류가 발생합니다. 기본적으로 OSD 데몬은 배치 그룹, 최대 thru, 부팅 및 실패 통계를 매 반초(즉, 0.5 )로 보고합니다. 이는 하트비트 임계값보다 더 자주 사용됩니다. 배치 그룹 설정의 기본 OSD 가 모니터에 보고되지 않거나 다른 OSD가 기본 OSD를 아래 로 보고하면 모니터에서 배치 그룹이 오래된 것으로 표시됩니다.

스토리지 클러스터를 시작하면 피어 프로세스가 완료될 때까지 오래된 상태를 확인하는 것이 일반적입니다. 잠시 동안 스토리지 클러스터가 실행된 후 오래 된 상태의 배치 그룹을 보면 해당 배치 그룹의 기본 OSD가 다운 되었거나 모니터에 배치 그룹 통계를 보고하지 않음을 나타냅니다.

PG가 OSD에 일시적으로 매핑되는 몇 가지 임시 백필 시나리오가 있습니다. 일시적 인 상황 이 더 이상 그렇지 않아야 할 때 PG는 여전히 임시 위치에 상주하고 적절한 위치에 있지 않을 수 있습니다. 이 경우, 그들은 잘못 배치 되었다고합니다. 그 이유는 올바른 수의 추가 사본이 실제로 존재하지만 하나 이상의 복사본이 잘못된 위치에 있기 때문입니다.

예를 들어 OSD 3개는 0,1,2이며, 모든 PG는 이러한 3개의 OSD에 매핑됩니다. 다른 OSD(OSD 3)를 추가하면 일부 PG가 이제 다른 OSD 대신 OSD 3에 매핑됩니다. 그러나 OSD 3이 다시 입력될 때까지 PG는 이전 매핑에서 I/O를 계속 제공할 수 있도록 임시 매핑을 갖습니다. 그 시간 동안 PG는 임시 매핑이 있지만 3 개의 사본이 있기 때문에 성능이 저하 되지 않기 때문에 잘못 배치 됩니다.

pg 1.5: up=acting: [0,1,2]
ADD_OSD_3
pg 1.5: up: [0,3,1] acting: [0,1,2]

[0,1,2]는 임시 매핑이므로 up set는 동작 세트와 같지 않으며, [0,1,2]이 아직 3개이므로 PG는 잘못 배치 되지 않습니다.

pg 1.5: up=acting: [0,3,1]

OSD 3이 다시 입력되어 임시 매핑이 제거되고 성능이 저하되지 않고 잘못 배치되지 않습니다.

불완전 한 콘텐츠와 피어링이 실패할 때 PG가 불완전한 상태가 됩니다. 즉, 복구 수행에 충분한 전체 OSD가 없는 경우 해당 상태가 없습니다.

OSD 1, 2, 3은 작동하는 OSD 세트이고 OSD 1, 4, 3으로 전환된 다음 osd.1 은 OSD 1, 2, 3의 임시 행동 세트를 요청하면서 다시 채우도록 합니다. 이 시간 동안 OSD 1, 2, 3이 모두 다운되면 osd.4 는 모든 데이터를 완전히 백업하지 않은 유일한 왼쪽이 됩니다. 현재 PG는 복구 수행에 충분한 완전한 OSD가 없음을 나타냅니다.

또는 osd.4 가 관련이 없고 동작 세트가 단순히 OSD 1, 2, 3인 경우 OSD 1, 2 및 3이 다운되는 경우, PG는 활동 세트가 변경 되기 때문에 해당 PG에 아무 것도 들어보지 않았음을 나타낼 수 있습니다. 새 OSD에 알리려면 OSD가 남아 있지 않습니다.

배치 그룹은 active+clean 상태가 아니므로 반드시 문제가 되지는 않습니다. 일반적으로 배치 그룹이 중단될 때 자체 복구를 수행하는 Ceph 기능이 작동하지 않을 수 있습니다. 안정된 상태는 다음과 같습니다.

Ceph 클라이언트는 최신 클러스터 맵을 검색하고 CRUSH 알고리즘은 개체를 배치 그룹에 매핑하는 방법을 계산한 다음 배치 그룹을 OSD에 동적으로 할당하는 방법을 계산합니다.