Ceph 노트(둘)

이 글은 주로 Ceph의 저장 대상 명사 해석과 그 의미, 그리고 Ceph 집단 내 CRUSH bucket 조정, PG/PGP 파라미터 조정 등 설정을 약술하였다.동시에 일부 서적 자료를 참고하여 간단하게 Ceph 집단 하드웨어 요구 등을 개술하였다

1. Ceph 구성 요소 및 정의

1.1 개체

대상은 Ceph에서 가장 작은 저장 단원으로 대상은 하나의 데이터와 하나의 메타데이터가 연결된 전체이다.메타데이터에 구체적인 데이터의 관련 속성 설명 정보 등이 저장되어 있다.Ceph는 각 대상에 대해 집단 내의 유일한 대상 식별자를 생성하여 대상이 집단 내의 유일성을 확보한다.전통적인 파일 시스템의 저장소에서 단일 파일의 크기는 일정한 제한이 있지만, Ceph의 대상은 메타데이터 영역이 커지면서 매우 커질 수 있다

1.2、CRUSH

전통적인 파일 저장 시스템에서 데이터의 메타데이터는 매우 중요한 위치를 차지하고 매번 시스템에 데이터가 추가될 때마다 메타데이터는 먼저 업데이트되고 그 다음에 실제 데이터가 기록된다.작은 스토리지 시스템(GB/TB)에서 메타데이터를 고정된 스토리지 노드나 디스크 어레이에 저장하는 방법은 수요를 충족시킬 수 있다.데이터 양이 PB/ZB 수준으로 증가할 때 메타데이터 검색 성능은 매우 큰 병목이 될 것이다.이 동시에 원데이터의 통일된 저장은 단일한 고장을 초래할 수 있다. 즉, 원데이터가 분실되면 실제 데이터는 되찾을 수 없다.전통적인 파일 저장 시스템과 달리 Ceph는 확장 가능한 산열 아래의 제어 복제(Ctrolled Replication Under Scalable Hashing, CRUSH) 알고리즘을 사용하여 데이터가 어디에 쓰여져야 하는지/어디서 읽어야 하는지 정확하게 계산한다.CRUSH는 메타데이터 대신 주문형 메타데이터를 계산하여 기존 파일 스토리지 시스템의 병목 현상을 해결합니다.

1.3 CRUSH 검색

Ceph에서 메타데이터의 계산과 부하는 분포식이며 필요할 때만 실행된다.메타데이터의 계산 과정을 CRUSH 검색이라고 하는데 다른 분포식 파일 시스템과 다르다. Ceph의 CRUSH 검색은 클라이언트가 자신의 자원을 사용하여 완성한 것으로 중심 검색이 가져오는 성능과 단일 고장 문제를 제외한다.CRUSH를 찾을 때 클라이언트는 먼저 모니터를 통해 집단 맵 던전을 획득한 다음에 맵 던전에서 집단 설정 정보를 획득한다.그런 다음 객체 정보, 풀 ID 등을 통해 객체를 생성합니다.이어 대상과 PG 수를 산열한 후 Ceph 풀에 이 대상을 최종적으로 저장한 PG를 얻는다.최종적으로 CRUSH 알고리즘을 통해 이 PG가 저장하는 OSD의 위치를 확정한다. OSD의 위치를 확정하면 클라이언트는 OSD와 직접 통신하여 데이터 읽기와 쓰기를 완성한다. 이는 중간 부분을 직접 제거하고 성능의 큰 향상을 보장한다.

1.4 CRUSH 계층 구조

Ceph에서 CRUSH는 각종 인프라 시설과 사용자 정의를 완전히 지원한다.CRUSH 설비 목록에서 디스크, 노드, 프레임, 줄, 스위치, 전원 회로, 방, 데이터 센터 등 일련의 설비를 미리 정의했다.이러한 구성 요소를 고장 구역(CRUSH bucket)이라고 하는데 사용자는 자신의 설정을 통해 서로 다른 OSD를 서로 다른 구역에 분포할 수 있다.이후 Ceph가 데이터를 저장할 때 CRUSH bucket 구조에 따라 모든 데이터가 정의된 물리 구성 요소 사이에서 완전히 격리될 것을 보장한다.예를 들어 우리가 여러 개의 선반 위의 서로 다른 OSD를 정의했다면 Ceph가 저장할 때 스마트하게 데이터 복사본을 여러 개의 선반 위에 분산시켜 어떤 선반 위의 기계가 모두 무릎을 꿇은 후에 데이터가 모두 분실되는 상황을 방지할 수 있다

1.5, 복구 및 재균형

고장 구역 내의 모든 구성 요소에 고장이 나면 Ceph는down과out 상태로 표시합니다.그리고 기본적으로 Ceph는 300초 후에 데이터 복구와 재균형을 기다릴 것입니다. 이 값은 설정 파일에서 4mon osd down out interval매개변수로 조정

1.6、PG

PG는 Ceph의 복제 수준에 따라 각 PG의 데이터가 여러 OSD로 복제되므로 고가용성을 보장합니다.

1.7 Ceph 풀

Ceph 풀은 스토리지 객체의 논리적 파티션으로, 각 풀에는 여러 개의 PG가 포함되어 있으므로 클러스터 내의 서로 다른 OSD에 특정 객체를 매핑할 수 있습니다. 이 두 가지 방식을 동시에 사용할 수는 없습니다.

2. Ceph 구성 요소 조정 및 조작

2.1 풀 작업

#  rados mkpool test-pool#  rados lspools#  rados cppool test-pool cp-pool#  rados rmpool test-pool test-pool --yes-i-really-really-mean-it

2.2 개체 조작

#  rados put testfile anaconda-ks.cfg -p test#  rados ls -p test#  ceph osd map test testfile#  rados rm testfile -p test

2.3 PG 및 PGP 수정

계산 PG 수는 Ceph 엔터프라이즈 스토리지의 없어서는 안 될 부분인데 그 중에서 집단 내 PG 계산 공식은 다음과 같다.

PG   = (OSD   * 100) /  

단일 연못에 대해 말하자면 우리는 연못의 PG 수를 설정해야 한다. 그 중에서 연못의 PG 수 계산 공식은 다음과 같다.

PG   = (OSD   * 100) /   /  

PGP는 포지셔닝을 실현하기 위해 설계된 PG로 PGP의 값은 PG 수량과 일치해야 한다.연못의 pgnum이 증가할 때 연못 안의 모든 PG는 둘로 나뉘지만 그들은 여전히 이전 OSD의 시사 관계를 유지하고 있다.pgp 증가Ceph 클러스터에서 PG를 OSD로 마이그레이션한 다음 재조정 프로세스를 시작합니다.
기존 PG 및 PGP 값을 가져오려면 다음 명령을 사용하십시오.

ceph osd pool get test pg_num
ceph osd pool get test pgp_num

PG와 PGP를 계산한 후 아래 명령을 통해 설정할 수 있다

ceph osd pool set test pgp_num 32
ceph osd pool set test pgp_num 32

마찬가지로 pool을 만들 때도 동기화해서 지정할 수 있습니다

ceph osd pool create POOLNAME PG PGP

2.4 pool 던전 수 조정

기본적으로 새 Pool을 만들 때 Pool에 저장된 데이터는 2개의 복사본만 있습니다. Pool 복사본 수를 보면 다음과 같은 명령을 사용할 수 있습니다

ceph osd dump | grep pool

기본 복사본 수를 고신뢰 수요를 충족시키기 위해 수정해야 할 때 다음과 같은 명령을 통해 완성할 수 있습니다

ceph osd pool set POOLNAME size NUM

2.5. 맞춤형 프로그램 배치

위에서 설명한 바와 같이 CRUSH bucket의 개념은 다음과 같은 관련 명령을 통해 우리는 자신의 집단 구조를 맞춤형으로 설정하여 Ceph가 데이터의 재해 수용 처리를 완성할 수 있다.

#  ceph osd tree#  ceph osd crush add-bucket rack01 rack
ceph osd crush add-bucket rack02 rack
ceph osd crush add-bucket rack03 rack#  (dockerX  )ceph osd crush move docker1 rack=rack01
ceph osd crush move docker2 rack=rack02
ceph osd crush move docker3 rack=rack03#  ceph osd crush move rack01 root=default
ceph osd crush move rack02 root=default
ceph osd crush move rack03 root=default

최종 집단의 전체 구조는 다음과 같다.

  ~ ceph osd tree
ID WEIGHT  TYPE NAME            UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 0.01469 root default
-5 0.00490     rack rack01
-2 0.00490         host docker1
 0 0.00490             osd.0         up  1.00000          1.00000
-6 0.00490     rack rack02
-3 0.00490         host docker2
 1 0.00490             osd.1         up  1.00000          1.00000
-7 0.00490     rack rack03
-4 0.00490         host docker3
 2 0.00490             osd.2         up  1.00000          1.00000

3. Ceph 하드웨어 구성

하드웨어 계획은 일반적으로 엔터프라이즈 스토리지에 필요한 작업이며, 다음은 Ceph의 일반적인 하드웨어 요구 사항을 간략하게 설명합니다.

3.1 수요 모니터링

Ceph 모니터는 클러스터 전체의 맵을 유지함으로써 클러스터의 건강 처리를 완료합니다.그러나 모니터는 실제 데이터 저장에 참여하지 않기 때문에 실제로 모니터 노드의 CPU가 차지하고 메모리가 비교적 적다.일반적으로 싱글 코어 CPU에 몇 G의 메모리를 추가하면 수요를 충족시킬 수 있다.모니터 노드는 실제 저장 작업에 참여하지 않지만 모니터의 네트워크 카드는 적어도 불필요해야 한다. 네트워크가 고장나면 집단 건강을 보장하기 어렵기 때문이다.

3.2 OSD 요구 사항

OSD는 Ceph 집단의 주요 저장 시설로서 일정한 CPU와 메모리 자원을 차지한다.일반적으로 추천하는 방법은 각 노드의 각 하드디스크를 하나의 OSD로 하는 것이다.또한 OSD는 로그를 작성해야 하기 때문에 OSD 통합 로그에 충분한 공간을 남겨야 한다.고장이 났을 때 OSD가 필요로 하는 자원이 더 많을 수 있기 때문에 OSD 노드는 실제 상황(각 OSD는 하나의 라인이 있을 수 있음)에 따라 더 많은 CPU와 메모리를 분배해야 한다.SSD는 OSD 액세스 속도 및 복구 속도 증가

3.3 MDS 요구 사항

MDS 서비스는 전문적으로 CephFS에 메타데이터를 저장하기 때문에 모니터와 OSD 노드에 비해 이 MDS 노드의 CPU 수요가 훨씬 많을 뿐만 아니라 메모리의 점용도 대량의 것이기 때문에 MDS는 일반적으로 강력한 물리기를 사용하여 단독으로 구축한다
전재는 출처를 밝혀 주십시오. 본문은 CC4를 채택합니다.0 프로토콜 인증
본문은 다음과 같습니다.https://mritd.me/2017/05/30/ceph-note-2/