그 사람은 너한테 안 좋아

Rook의 인기가 높아지면서 그 과정에서 여러분을 기다리고 있는 함정과 문제점에 대해 이야기하고 싶습니다.

내 소개: 해머 버전에서 Ceph 관리 경험, 커뮤니티 창립자 t.me/ceph_ru 텔레그램에서.

근거가 없는 일이 없도록 하기 위해 Ceph 문제에 대해 Habr이 승인한 게시물(등급으로 판단)을 참조하겠습니다. 나는 또한 이 게시물에서 대부분의 문제에 직면했습니다. 사용된 자료의 링크는 포스팅 마지막에 있습니다.

Rook에 대한 게시물에서 우리는 이유 때문에 ceph를 언급합니다. Rook은 기본적으로 kubernetes로 포장된 ceph이므로 모든 문제를 상속받습니다. 세프 문제부터 시작해 보겠습니다.

클러스터 관리 단순화

Rook의 장점 중 하나는 kuberentes를 통해 ceph를 관리하기 쉽다는 것입니다.

그러나 ceph에는 구성을 위한 1000개 이상의 매개변수가 포함되어 있는 반면, 동시에 rook를 통해 우리는 그 중 소수만 편집할 수 있습니다.

빛나는 예
> ceph 데몬 mon.a 구성 표시 | 화장실 -l
1401

Rook은 ceph를 설치하고 업데이트하는 편리한 방법으로 자리잡고 있습니다.
Rook 없이도 ceph를 설치하는데는 문제가 없습니다 - ansible 플레이북은 30분만에 작성되는데 업데이트에 문제가 많습니다.

Krok의 게시물에서 인용

예: Hummer에서 Jewel로 업데이트한 후 크러시 튜너블이 올바르게 작동하지 않습니다.

> ceph osd crush 쇼 튜너블
{
...
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
"프로필": "알 수 없음",
"optimal_tunables": 0,
...
}

그러나 마이너 버전 내에서도 문제가 있습니다.

예: 업데이트 12.2.6으로 인해 클러스터가 상태 오류 상태가 되고 조건부로 PG가 중단됨
ceph.com/releases/v12-2-8-released

업데이트하지 말고 기다려서 테스트하시겠습니까? 하지만 우리는 무엇보다도 업데이트의 편의를 위해 Rook을 사용하는 것 같습니다.

Rook의 재해 복구 클러스터의 복잡성

예: OSD는 오류가 발생하면서 떨어집니다. 문제가 구성의 매개변수 중 하나에 있다고 의심되어 특정 데몬에 대한 구성을 변경하고 싶지만 kubernetes 및 DaemonSet이 있기 때문에 변경할 수 없습니다.

대안이 없습니다. ceph Tell osd.Num injectargs가 작동하지 않습니다. OSD가 거짓말을 하고 있습니다.

디버그 난이도

일부 설정 및 성능 테스트에서는 데몬의 osd 소켓에 직접 연결해야 합니다. Rook의 경우 먼저 원하는 컨테이너를 찾은 다음 해당 컨테이너로 들어가서 디버그에 누락된 도구를 찾아 매우 당황해야 합니다.

OSD를 순차적으로 올리기 어려움

예: OSD가 OOM에 빠지고 재조정이 시작된 후 다음 항목이 떨어집니다.

해결 방법: OSD를 한 번에 하나씩 올리고 클러스터에 완전히 포함될 때까지 기다렸다가 다음 OSD를 올립니다. (자세한 내용은 Ceph 보고서에서 확인하세요. 재해 분석)

베어메탈 설치의 경우 이는 간단히 손으로 수행됩니다. Rook의 경우 노드당 하나의 OSD는 특별한 문제가 없습니다. 노드당 OSD > 1인 경우 대체 리프팅 문제가 발생합니다.

물론 해결할 수 있지만 Rook을 사용하여 작업을 단순화하지만 더 복잡해집니다.

세프 데몬에 대한 한계 선택의 어려움

ceph의 베어메탈 설치의 경우 클러스터에 필요한 리소스를 계산하는 것은 매우 쉽습니다. 공식이 있고 연구가 가능합니다. 약한 CPU를 사용하는 경우에도 Numa가 무엇인지 알아내기 위해 몇 가지 성능 테스트를 실행해야 하지만 여전히 Rook보다 쉽습니다.

Rook의 경우 계산할 수 있는 메모리 제한 외에도 CPU 제한 설정에 대한 질문이 있습니다.

그리고 여기서 성능 테스트를 열심히 해야 합니다. 제한을 낮추면 클러스터 속도가 느려지고, unlim을 설정하면 재조정 중에 CPU 사용량이 활성화되어 Kubernetes의 애플리케이션에 나쁜 영향을 미칩니다.

네트워킹 문제 v1

ceph의 경우 2x10GB 네트워크를 사용하는 것이 좋습니다. 하나는 클라이언트 트래픽용이고 다른 하나는 ceph 서비스 요구 사항(재조정)용입니다. 베어메탈에서 ceph를 사용하는 경우 이 분할은 쉽게 구성됩니다. Rook을 사용하는 경우 모든 클러스터 구성이 두 개의 서로 다른 네트워크를 포드에 공급할 수 있는 것은 아니기 때문에 네트워크별로 분할하면 문제가 발생할 수 있습니다. .

네트워킹 문제 v2

네트워크 분리를 거부하면 재조정 시 ceph 트래픽으로 인해 전체 채널이 막히고 kubernetes의 애플리케이션이 느려지거나 충돌하게 됩니다. Ceph 재조정 속도를 줄일 수 있지만 재조정 기간이 길어지면 두 번째 노드가 디스크나 OOM을 통해 클러스터에서 떨어질 위험이 높아지고 이미 클러스터에 대해 읽기 전용이 보장됩니다.

긴 재조정 - 긴 애플리케이션 지연

Ceph의 게시물에서 인용합니다. 재해의 해부학.

클러스터 성능 테스트:

4KB 크기의 쓰기 작업에는 1ms가 걸리고 성능은 1000스레드에서 초당 1 작업입니다.

4MB(객체 크기) 작업에는 22ms가 걸리고 성능은 45작업/초입니다.

결과적으로 도메인 XNUMX개 중 하나가 실패하면 클러스터는 한동안 성능 저하 상태에 있고 핫 개체의 절반이 여러 버전에 분산된 다음 쓰기 작업의 절반이 강제 복구로 시작됩니다.

강제 복구 시간을 대략적으로 계산합니다(성능이 저하된 개체에 대한 쓰기 작업).

먼저 4ms에 22MB를 읽고, 22ms에 쓴 다음, 1ms에 4KB의 실제 데이터를 씁니다. 표준 성능이 45ms일 때 SSD의 저하된 개체에 대한 쓰기 작업당 총 1ms - 성능이 45배 감소했습니다.

성능이 저하된 개체의 비율이 높을수록 모든 것이 더 나빠집니다.

클러스터가 올바르게 작동하려면 재조정 속도가 매우 중요합니다.

ceph에 대한 특정 서버 설정

ceph에는 특정 호스트 조정이 필요할 수 있습니다.

예: sysctl 설정 및 동일한 JumboFrame, 이러한 설정 중 일부는 페이로드에 부정적인 영향을 미칠 수 있습니다.

Rook의 실제 필요성은 여전히 ​​의문의 여지가 있습니다.

클라우드에 있는 경우 클라우드 공급자로부터 스토리지를 얻을 수 있어 훨씬 더 편리합니다.

자체 서버를 사용하는 경우 kubernetes 없이 ceph를 관리하는 것이 더 편리할 것입니다.

저렴한 호스팅 업체에서 서버를 임대하시나요? 그러면 네트워크, 지연 및 대역폭에 대해 많은 즐거움을 누릴 수 있으며 이는 분명히 ceph에 부정적인 영향을 미칩니다.

총계 : 쿠버렌테를 구현하는 것과 스토리지를 구현하는 것은 입력과 솔루션 옵션이 서로 다른 서로 다른 작업입니다. 둘을 혼합하는 것은 둘 중 하나를 위해 위험할 수 있는 절충안을 만드는 것을 의미합니다. 설계 단계에서도 이러한 솔루션을 결합하는 것은 매우 어려울 것이며 아직 작동 기간이 있습니다.

참고 문헌 :

게시물 #1 그런데 세프라고 하더군요... 그 사람 정말 그렇게 좋은 사람인가요?
게시물 #2 세프. 재해 분석

출처 : habr.com