바쁜 프로젝트에서 Ceph를 사용하기 위한 팁과 요령

로드가 다양한 프로젝트에서 Ceph를 네트워크 스토리지로 사용하면 언뜻 보기에는 단순하거나 사소해 보이지 않는 다양한 작업에 직면할 수 있습니다. 예를 들어:

• 새 클러스터의 이전 서버를 부분적으로 사용하여 이전 Ceph에서 새 Ceph로 데이터 마이그레이션
• Ceph의 디스크 공간 할당 문제에 대한 솔루션입니다.

이러한 문제를 해결하려면 데이터 손실 없이 OSD를 올바르게 제거해야 하며 이는 대용량 데이터를 처리할 때 특히 중요합니다. 이에 대해서는 기사에서 논의할 것입니다.

아래 설명된 방법은 모든 Ceph 버전에 적용됩니다. 또한 Ceph가 많은 양의 데이터를 저장할 수 있다는 사실도 고려됩니다. 데이터 손실 및 기타 문제를 방지하기 위해 일부 작업은 여러 작업으로 "분할"됩니다.

OSD에 대한 서문

논의된 세 가지 레시피 중 두 가지가 OSD 전용이므로(객체 스토리지 데몬), 실용적인 부분을 살펴보기 전에 Ceph의 기능과 이것이 왜 그렇게 중요한지에 대해 간략하게 설명합니다.

우선 Ceph 클러스터 전체는 수많은 OSD로 구성되어 있다고 해야 할까요. 데이터가 많을수록 Ceph의 무료 데이터 볼륨도 커집니다. 여기서부터 이해하기 쉽다 주요 OSD 기능: 모든 클러스터 노드의 파일 시스템에 Ceph 객체 데이터를 저장하고 이에 대한 네트워크 액세스(읽기, 쓰기 및 기타 요청)를 제공합니다.

동일한 수준에서 복제 매개변수는 서로 다른 OSD 간에 개체를 복사하여 설정됩니다. 그리고 여기에서 다양한 문제가 발생할 수 있으며 이에 대한 해결책은 아래에서 논의됩니다.

사건 번호 1. 데이터 손실 없이 Ceph 클러스터에서 OSD를 안전하게 제거

OSD를 제거해야 하는 이유는 클러스터에서 서버를 제거하는 것(예: 다른 서버로 교체하는 경우)으로 인해 발생할 수 있습니다. 이것이 바로 우리에게 일어난 일이며 이 기사를 작성하게 된 계기가 되었습니다. 따라서 조작의 궁극적인 목적은 해당 서버의 모든 OSD와 Mon을 추출하여 서버를 중지하는 것입니다.

편의를 위해 명령을 실행하는 동안 필요한 OSD를 표시하는 데 실수를 하는 상황을 방지하기 위해 별도의 변수를 설정하며 그 값은 삭제할 OSD 번호가 됩니다. 그녀에게 전화하자 ${ID} — 여기와 아래에서 이러한 변수는 우리가 작업 중인 OSD 번호를 대체합니다.

작업을 시작하기 전 상태를 살펴보겠습니다.

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME      STATUS REWEIGHT PRI-AFF
-1       0.46857 root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
 1   ssd 0.15619      osd.1     up     1.00000  1.00000
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2     up     1.00000  1.00000

OSD 제거를 시작하려면 원활하게 수행해야 합니다. reweight 그것에 XNUMX으로. 이렇게 하면 OSD의 데이터 양을 다른 OSD와의 균형을 맞춰 줄일 수 있습니다. 이렇게 하려면 다음 명령을 실행하세요.

ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78

... XNUMX까지 계속됩니다.

원활한 밸런싱이 필요함데이터를 잃지 않도록. OSD에 많은 양의 데이터가 포함되어 있는 경우 특히 그렇습니다. 명령을 실행한 후 확인하려면 reweight 모든 일이 잘 진행됐어요. 완료해도 돼요 ceph -s 또는 별도의 터미널 창에서 실행 ceph -w 실시간으로 변화를 관찰하기 위해서다.

OSD가 "비워지면" 표준 작업을 진행하여 OSD를 제거할 수 있습니다. 이렇게 하려면 원하는 OSD를 상태로 전송하십시오. down:

ceph osd down osd.${ID}

클러스터에서 OSD를 "당겨" 보겠습니다.

ceph osd out osd.${ID}

OSD 서비스를 중지하고 FS에서 해당 파티션을 마운트 해제해 보겠습니다.

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

OSD 제거 크러쉬 맵:

ceph osd crush remove osd.${ID}

OSD 사용자를 삭제해 보겠습니다.

ceph auth del osd.${ID}

마지막으로 OSD 자체를 제거해 보겠습니다.

ceph osd rm osd.${ID}

주의: Ceph Luminous 버전 이상을 사용하는 경우 위의 OSD 제거 단계를 두 가지 명령으로 줄일 수 있습니다.

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

위에서 설명한 단계를 완료한 후 다음 명령을 실행하면 ceph osd tree, 그러면 작업이 수행된 서버에는 위 작업이 수행된 OSD가 더 이상 없다는 것이 분명해집니다.

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.46857      root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2    up     1.00000  1.00000

그 과정에서 Ceph 클러스터의 상태는 다음과 같이 변경됩니다. HEALTH_WARN, OSD 수와 사용 가능한 디스크 공간도 감소합니다.

다음은 서버를 완전히 중지하고 그에 따라 Ceph에서 제거하려는 경우 필요한 단계를 설명합니다. 이 경우 다음을 기억하는 것이 중요합니다. 서버를 종료하기 전에 모든 OSD를 제거해야 합니다. 이 서버에서.

이 서버에 OSD가 더 이상 남아 있지 않으면 OSD를 제거한 후 OSD 맵에서 서버를 제외해야 합니다. hv-2다음 명령을 실행하여:

ceph osd crush rm hv-2

삭제 mon 서버에서 hv-2다른 서버에서 아래 명령을 실행하여(예: 이 경우 hv-1):

ceph-deploy mon destroy hv-2

그런 다음 서버를 중지하고 후속 작업(재배포 등)을 시작할 수 있습니다.

사건 번호 2. 이미 생성된 Ceph 클러스터의 디스크 공간 분포

PG에 대한 서문으로 두 번째 이야기를 시작하겠습니다.배치 그룹). Ceph에서 PG의 주요 역할은 주로 Ceph 개체를 집계하고 OSD에서 추가로 복제하는 것입니다. 필요한 PG 금액을 계산할 수 있는 공식은 다음과 같습니다. 관련 섹션 세프 문서. 이 문제는 구체적인 예와 함께 논의됩니다.

따라서 Ceph를 사용할 때 흔히 발생하는 문제 중 하나는 Ceph의 풀 간 OSD 및 PG 수가 불균형하다는 것입니다.

첫째, 이로 인해 작은 풀에 너무 많은 PG가 지정되는 상황이 발생할 수 있으며, 이는 본질적으로 클러스터의 디스크 공간을 비합리적으로 사용하는 것입니다. 둘째, 실제로는 더 심각한 문제가 있습니다. OSD 중 하나에서 데이터가 오버플로되는 것입니다. 이는 클러스터가 먼저 상태로 전환하는 것을 수반합니다. HEALTH_WARN, 그런 다음 HEALTH_ERR. 그 이유는 Ceph가 사용 가능한 데이터 양을 계산할 때(다음을 통해 확인할 수 있음) MAX AVAIL 명령 출력에서 ceph df 풀마다 별도로)은 OSD에서 사용 가능한 데이터의 양을 기준으로 합니다. 하나 이상의 OSD에 공간이 충분하지 않으면 데이터가 모든 OSD에 적절하게 배포될 때까지 더 이상 데이터를 쓸 수 없습니다.

이러한 문제가 있음을 명확히 할 가치가 있습니다. Ceph 클러스터 구성 단계에서 크게 결정됩니다.. 사용할 수 있는 도구 중 하나는 세프 PGCalc. 이를 통해 필요한 PG 금액이 명확하게 계산됩니다. 그러나 Ceph 클러스터가 이미 잘못 구성되었습니다. 수정 작업의 일부로 PG 수를 줄여야 할 가능성이 높으며 이 기능은 이전 버전의 Ceph에서는 사용할 수 없다는 점을 여기서 명확히 할 필요가 있습니다(이 기능은 Ceph 버전에서만 나타남). 노틸러스).

이제 다음 그림을 상상해 보겠습니다. 클러스터에는 상태가 있습니다. HEALTH_WARN OSD 중 하나에 공간이 부족하기 때문입니다. 이는 오류로 표시됩니다. HEALTH_WARN: 1 near full osd. 아래는 이러한 상황을 벗어나기 위한 알고리즘이다.

우선, 나머지 OSD 간에 사용 가능한 데이터를 배포해야 합니다. 우리는 노드를 "드레이닝"할 때 첫 번째 경우에 이미 유사한 작업을 수행했습니다. 유일한 차이점은 이제 약간 줄여야 한다는 점입니다. reweight. 예를 들어 최대 0.95:

ceph osd reweight osd.${ID} 0.95

이렇게 하면 OSD의 디스크 공간이 확보되고 ceph 상태의 오류가 수정됩니다. 그러나 이미 언급한 바와 같이 이 문제는 주로 초기 단계에서 Ceph를 잘못 설정했기 때문에 발생하므로 앞으로는 Ceph가 나타나지 않도록 재구성하는 것이 매우 중요합니다.

우리의 특별한 경우에는 다음과 같은 결과가 나왔습니다.

• 값이 너무 높음 replication_count 수영장 중 한 곳에서,
• 한 풀에는 PG가 너무 많고 다른 풀에는 PG가 너무 적습니다.

이미 언급한 계산기를 사용해 보겠습니다. 입력해야 할 내용을 명확하게 보여 주며 원칙적으로 복잡한 것은 없습니다. 필요한 매개변수를 설정하면 다음 권장 사항을 얻을 수 있습니다.

주의: Ceph 클러스터를 처음부터 설정하는 경우 계산기의 또 다른 유용한 기능은 표에 지정된 매개변수를 사용하여 처음부터 풀을 생성하는 명령을 생성하는 것입니다.

마지막 열은 탐색하는 데 도움이 됩니다. 권장 PG 수. 우리의 경우 복제 승수를 변경하기로 결정했기 때문에 복제 매개 변수가 표시된 두 번째 항목도 유용합니다.

따라서 먼저 복제 매개변수를 변경해야 합니다. 승수를 줄이면 디스크 공간이 확보되므로 먼저 수행할 가치가 있습니다. 명령이 실행되면 사용 가능한 디스크 공간이 증가하는 것을 확인할 수 있습니다.

ceph osd pool $pool_name set $replication_size

완료 후 매개변수 값을 변경합니다. pg_num и pgp_num 다음과 같이

ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number

중요한 일이야: 각 풀에서 순차적으로 PG 수를 변경해야 하며, 경고가 사라질 때까지 다른 풀의 값을 변경하지 않아야 합니다. "데이터 중복성 저하" и "n개의 페이지가 저하되었습니다.".

명령 출력을 사용하여 모든 것이 잘 진행되었는지 확인할 수도 있습니다. ceph health detail и ceph -s.

사건 번호 3. LVM에서 Ceph RBD로 가상 머신 마이그레이션

프로젝트에서 임대 베어메탈 서버에 설치된 가상 머신을 사용하는 상황에서는 내결함성 스토리지 문제가 자주 발생합니다. 이 스토리지에 충분한 공간이 있는 것도 매우 바람직합니다... 또 다른 일반적인 상황: 서버에 로컬 스토리지가 있는 가상 머신이 있고 디스크를 확장해야 하지만 디스크가 없기 때문에 갈 곳이 없습니다. 서버에 남은 여유 디스크 공간.

문제는 다른 서버로 마이그레이션하거나(있는 경우) 서버에 새 디스크를 추가하는 등 다양한 방법으로 해결할 수 있습니다. 하지만 항상 이렇게 할 수 있는 것은 아니므로 LVM에서 Ceph로 마이그레이션하는 것이 이 문제에 대한 탁월한 솔루션이 될 수 있습니다. 이 옵션을 선택하면 한 하이퍼바이저에서 다른 하이퍼바이저로 로컬 스토리지를 이동할 필요가 없으므로 서버 간의 추가 마이그레이션 프로세스도 단순화됩니다. 유일한 문제는 작업이 수행되는 동안 VM을 중지해야 한다는 것입니다.

다음 레시피는 다음에서 가져왔습니다. 이 블로그의 기사, 그 지침은 실제로 테스트되었습니다. 그런데, 번거롭지 않은 마이그레이션 방법도 거기에 설명되어 있습니다., 그러나 우리의 경우에는 단순히 필요하지 않았기 때문에 확인하지 않았습니다. 이것이 귀하의 프로젝트에 매우 중요한 경우 댓글을 통해 결과를 기쁜 마음으로 알려드리겠습니다.

실용적인 부분으로 넘어 갑시다. 이 예에서는 virsh를 사용하고 이에 따라 libvirt도 사용합니다. 먼저, 데이터가 마이그레이션될 Ceph 풀이 libvirt에 연결되어 있는지 확인하십시오.

virsh pool-dumpxml $ceph_pool

풀 설명에는 인증 데이터와 함께 Ceph에 대한 연결 데이터가 포함되어야 합니다.

다음 단계는 LVM 이미지를 Ceph RBD로 변환하는 것입니다. 실행 시간은 주로 이미지 크기에 따라 달라집니다.

qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name

변환 후에도 LVM 이미지는 유지됩니다. 이는 VM을 RBD로 마이그레이션하는 데 실패하고 변경 사항을 롤백해야 하는 경우 유용합니다. 또한 변경 사항을 빠르게 롤백할 수 있도록 가상 머신 구성 파일을 백업해 보겠습니다.

virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml

... 그리고 원본을 편집합니다(vm_name.xml). 디스크에 대한 설명이 포함된 블록을 찾아보겠습니다(다음 줄로 시작함). <disk type='file' device='disk'> 그리고 다음으로 끝납니다 </disk>) 이를 다음 형식으로 줄입니다.

<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
  <secret type='ceph' uuid='sec-ret-uu-id'/>
 </auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
  <host name='10.0.0.1' port='6789'/>
  <host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/> 
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>

몇 가지 세부 사항을 살펴보겠습니다.

1. 프로토콜에 source Ceph RBD의 저장소 주소가 표시됩니다(Ceph 풀의 이름과 첫 번째 단계에서 결정된 RBD 이미지를 나타내는 주소입니다).
2. 블록에서 secret 종류가 표시되어 있어요 ceph, 연결하기 위한 비밀의 UUID입니다. uuid는 다음 명령을 사용하여 찾을 수 있습니다. virsh secret-list.
3. 블록에서 host Ceph 모니터에 대한 주소가 표시됩니다.

구성 파일을 편집하고 LVM에서 RBD로의 변환을 완료한 후 수정된 구성 파일을 적용하고 가상 머신을 시작할 수 있습니다.

virsh define $vm_name.xml
virsh start $vm_name

이제 가상 머신이 올바르게 시작되었는지 확인할 시간입니다. 예를 들어 SSH 또는 다음을 통해 연결하여 확인할 수 있습니다. virsh.

가상 머신이 올바르게 작동하고 다른 문제를 발견하지 못한 경우 더 이상 사용되지 않는 LVM 이미지를 삭제할 수 있습니다.

lvremove main/$vm_image_name

결론

우리는 실제로 설명된 모든 사례를 접했습니다. 지침이 다른 관리자가 유사한 문제를 해결하는 데 도움이 되기를 바랍니다. Ceph 사용 경험에 대한 의견이나 기타 유사한 이야기가 있으면 의견을 통해 기꺼이 알려드리겠습니다!

PS

블로그에서도 읽어보세요.

• «우리 손은 지루하지 않습니다: K8s에서 Rook 클러스터 복원";
• «Rook이냐 아니냐-그것이 문제로다";
• «Rook - Kubernetes용 "셀프 서비스" 데이터 웨어하우스";
• «Ceph 기반 Kubernetes에서 프로비저닝을 통해 영구 스토리지 생성".

출처 : habr.com