ceph (3단계) 기본 사용법

시스템은 ceph 클러스터로 시작됩니다.

이번 글에서는 ceph 클러스터를 활용하는 방법을 체계적으로 소개하겠습니다.

관련: crush, osd, pool, 캐시

ceph 버전: nautilus

ceph-deploy 버전: 2.0.1

in 기본 사용 요구 사항에 따라 스토리지 클러스터는 일반적으로 고성능 스토리지(SSD)와 일반 스토리지(HDD)를 제공해야 합니다.

ceph에서 구체적인 성능은 일부 풀은 고성능 스토리지를 사용하고 일부 풀은 일반 스토리지를 사용한다는 것입니다. 이 요구 사항은 ceph의 크러시 규칙에 의해 구현됩니다.

ceph는 캐싱 개념을 제공합니다. 일반 스토리지 풀 위에 고성능 캐시 풀이 구축되어 외부 액세스가 캐시 풀에 먼저 도달한 후 누락이 발생하면 스토리지 풀에 액세스합니다. 여기서 언급할 한 가지는 모든 상황에 캐싱이 필요한 것은 아니라는 것입니다.

다양한 시나리오에서 ceph는 다양한 방식으로 사용될 수 있습니다. 여기서 소개하는 내용은 간단하지만 최대한 포괄적입니다.

표준 시나리오: 스토리지 풀과 캐시 풀, 스토리지 풀은 일반 장치를 사용하고 캐시 풀은 고성능 장치를 사용합니다.

먼저 고성능 하드 디스크를 추가하세요(저는 여기 가상 환경에 있고 일반 하드 디스크로만 충전할 수 있습니다)

그런 다음 크러시를 사용하여 다른 풀을 허용해야 합니다 다른 저장 장치를 사용하십시오.

여기에서는 일반 가상 하드 디스크만 테스트에 사용할 수 있습니다.

ceph02 가상 머신에 30G 가상 하드 디스크를 추가합니다.

ceph03 가상 머신에 30G 가상 하드 디스크를 추가합니다.

이제 작동할 배포 노드로 이동합니다.

그림에 표시된 대로 osd.6은 ceph02에 나타나고 osd.7은 ceph03에 나타납니다.

여기에는 기사 마지막 부분의 확장에서 소개할 루트 개념이 포함됩니다. 여기에서 직접 사용할 수 있습니다.

osd.6 osd.7을 캐시라는 루트에 추가합니다(루트 이름은 자동으로 생성됩니다. osd는 기본적으로 시작 시 호스트 이름을 읽기 때문에 이 방법은 일시적으로만 적용됩니다. , 영구 메서드는 기사 마지막 부분의 확장에서 소개됩니다.

이제 "고성능" 저장 디스크를 사용할 수 있으며 캐시 루트 아래에 배치됩니다. 다음 단계.

이제 다음 단계로 진행할 수 있습니다.

현재 환경에는 이미 기본 크러시 규칙이 있습니다.

특정 속성 설명에 대한 참조:

/docs/mimic/rados/Operations/crush-map-edits/#crush-map-rules

표시된 대로 위 줄에서 현재 규칙은 기본 루트 osd만 사용합니다.

앞서 고성능 기기를 만들 때는 루트를 캐시로 설정하세요. 이제 캐시 루트의 osd만 사용하는 규칙을 생성하여 캐시 풀과 스토리지 풀이 서로 다른 장치를 사용할 수 있도록 할 수 있습니다.

캐시 풀에서 사용하는 규칙을 만듭니다.

그 중:

복제된_cache는 규칙의 이름을 나타냅니다.

캐시는 이 규칙에서 사용되는 루트를 나타냅니다.

호스트는 장애 도메인 수준을 나타냅니다.

모든 규칙 다시 보기:

이제 고성능 저장 장치만 사용하는 규칙이 있습니다. 이제 다양한 규칙을 사용하여 풀 생성을 시작할 수 있습니다.

스토리지 풀 생성:

풀 보기:

풀 규칙 보기:

이제 스토리지 풀이 준비되었습니다. .

캐시 풀은 ceph에서 hot으로 식별되는 경우가 많습니다.

일반 스토리지 풀은 ceph에서 cold로 식별되는 경우가 많습니다.

캐싱에는 다양한 형태가 있습니다(공식 문서에는 다음이 나열되어 있지만 실제로는 더 많은 것이 있습니다).

캐싱 참조:

/docs/master/ rados/ Operations/cache-tiering/

캐시 풀 생성

캐시 풀이 생성된 후 캐시 풀을 해당 스토리지 풀과 연결해야 합니다. 이러한 관계의 개념을 캐시 계층화라고 하며, 이를 캐시 계층 또는 캐시 프록시라고 부를 수 있습니다.

참조:

/docs/master/rados/Operations/cache-tiering/

test_storage 풀의 경우 읽기 전용 캐시 풀이 있습니다. test_storage에서 객체를 읽는 한, 이 객체는 일정 기간 동안 자동으로 캐시 풀에 배치됩니다.

Write-back 모드로 객체가 캐시 풀에 업로드되면 해당 데이터가 스토리지 풀에도 나타나는 것을 확인할 수 있습니다.

osd의 크기가 동일하지 않을 수 있으므로 그에 대한 데이터의 양이 동일해서는 안 되므로 데이터 분포에 영향을 주기 위해 가중치가 도입됩니다.

예를 들어 100G osd 가중치가 1이면 200G osd 가중치는 2로 설정되어야 합니다.

ceph osd tree 명령은 저장 구조를 볼 수 있습니다. 자신의 머신 실행 결과를 바탕으로 아래 내용을 읽을 수 있습니다.

공식 사진 :

ceph 저장 구조를 설명하는 사진입니다.

우선 트리 구조입니다.

최상위 루트 기본값: root는 루트를 의미하고 기본값은 이 루트의 이름입니다.

중간에 있는 Host foo: Host는 호스트를 의미하고, foo는 이 호스트의 이름입니다. 여기서 호스트 이름은 단지 별명일 뿐이며 실제 호스트를 나타내지 않으며 마음대로 변경할 수 있습니다.

아래쪽은 특히 osd를 가리키는 리프 노드입니다.

이 세 계층의 구조를 나누는 의미(불완전):

이 글에서 ceph-deploy를 사용하여 osd를 추가할 때 최종 루트로 직접 설정되지 않고, 나중에 구성을 수동으로 추가해야 합니다. 이 작업은 무리한 작업이며 ceph-deploy의 루트를 지정하기 위한 매개 변수를 아직 찾지 못했습니다.

현재 기사에 구성된 캐시 풀에는 복사본이 2개 있습니다.

읽기 전용 캐시와 같이 캐시 데이터가 손실되는 경우가 있습니다. 이런 종류의 캐시 풀은 단일 복사본을 가질 수 있지만 테스트 결과 ceph에서는 단일 복사본 풀이 어려운 것으로 보입니다.

시스템의 호스트 이름을 한 번에 변경할 수 있습니다.

이때 시스템을 다시 시작하면 시스템의 모든 osd의 호스트 이름이 동일합니다. , OSD 트리 혼란을 야기합니다. 이때 ceph.conf에서 특정 디스크의 정보를 구체적으로 구성할 수 있습니다.

현재 환경 구성 참조:

다음 내용을 추가합니다.

다시 시작한 후에는 모든 것이 정상입니다.

OSD 시작에 대해 소란을 피운다.

예를 들어 osd의 시작 방법을 구성하고 osd를 컨테이너화하면 컨테이너가 특정 정보를 기억하므로 호스트 이름이 영구적으로 유효할 수 있습니다.

OSD의 PGS 수는 전체 클러스터 성능에 영향을 미칩니다.

풀에는 레플리카 개념이 있으므로 다음과 같은 계산 방법이 생성됩니다.

공식적인 권장 사항은 각 osd의 pg 수는 100입니다. 실제 테스트에서는 각 osd의 pg 수가 250에 도달하면 알람이 시작되므로 클러스터의 총 pg 수가 다음을 초과해서는 안됩니다.

따라서 이 문제가 발생하는 이유는 다음과 같습니다.

모든 풀 PG 개수의 합이 설정된 총 PG 개수를 초과합니다. 하지만 클러스터는 여전히 작동하므로 단지 경고일 뿐입니다.

이 문제를 해결하는 방법:

현재 개인적인 경험에 따르면 단일 사본을 사용하지 마십시오.

크러시 규칙 참조:

/docs/master/rados/Operations/crush-map/