2.2. Red Hat Ceph Storage의 기본 고려 사항

Red Hat Ceph Storage를 사용하는 첫 번째 고려 사항은 데이터를 위한 스토리지 전략을 개발하는 것입니다. 스토리지 전략은 특정 사용 사례에 서비스를 제공하는 데이터를 저장하는 방법입니다. OpenStack과 같은 클라우드 플랫폼에 대한 볼륨과 이미지를 저장해야 하는 경우 저널용 SSD(Solid State Drives)로 더 빠른 SAS( Serial Attached SCSI) 드라이브에 데이터를 저장하도록 선택할 수 있습니다. 반대로 S3 또는 Swift 호환 게이트웨이에 대한 오브젝트 데이터를 저장해야 하는 경우 기존 SATA(Serial Advanced Technology Attachment) 드라이브와 같이 더 경제적인 것을 사용할 수 있습니다. Red Hat Ceph Storage는 동일한 스토리지 클러스터에 있는 두 시나리오를 모두 수용할 수 있지만, 클라우드 플랫폼에 빠른 스토리지 전략을 제공하는 수단과 개체 저장소에 더 많은 기존 스토리지를 제공하는 수단이 필요합니다.

Ceph 배포의 가장 중요한 단계 중 하나는 스토리지 클러스터의 사용 사례와 워크로드에 적합한 가격대 성능 프로필을 식별하는 것입니다. 사용 사례에 적합한 하드웨어를 선택하는 것이 중요합니다. 예를 들어, 콜드 스토리지 애플리케이션에 최적화된 IOPS 하드웨어를 선택하면 하드웨어 비용이 불필요하게 증가합니다. 반면, IOPS 집약적인 워크로드에서 용량에 최적화된 하드웨어를 선택하는 경우 성능 저하에 대해 불만을 제기하는 사용자가 불만을 줄 수 있습니다.

Red Hat Ceph Storage는 여러 스토리지 전략을 지원할 수 있습니다. 사운드 스토리지 전략을 개발하는 데 도움이 되는 사용 사례, 비용 대비 성능 장단점 및 데이터 지속성이 가장 중요한 고려 사항입니다.

복제는 하드웨어 장애 발생 시 장애 도메인에서 데이터의 중복 복사본을 하나 이상 저장합니다. 그러나 데이터의 중복 복사본은 규모에 따라 비용이 많이 들 수 있습니다. 예를 들어, 3개 복제를 사용하여 1페타바이트의 데이터를 저장하려면 최소 3페타바이트 이상의 스토리지 용량이 있는 클러스터가 필요합니다.

코딩 삭제는 데이터를 데이터 청크 및 코딩 청크로 저장합니다. 데이터 청크가 손실되는 경우 삭제 코딩은 나머지 데이터 청크 및 코딩 청크를 사용하여 손실된 데이터 청크를 복구할 수 있습니다. 삭제 코딩은 복제보다 상당히 경제적입니다. 예를 들어 데이터 청크 8개와 코딩 청크 3개가 있는 삭제 코딩을 사용하면 데이터 복사본 3개와 동일한 중복성이 제공됩니다. 그러나 이러한 인코딩 체계는 복제와 3x와 비교하여 약 1.5x의 초기 데이터를 사용합니다.

CRUSH 알고리즘은 Ceph가 스토리지 클러스터 내의 다른 위치에 추가 사본 또는 코딩 청크를 저장할 수 있도록 하여 이 프로세스를 지원합니다. 이렇게 하면 단일 스토리지 장치 또는 호스트에 장애가 발생해도 데이터 손실을 방지하는 데 필요한 모든 복사 또는 코딩 청크가 손실되지 않습니다. 비용 대비 이점의 장단점이 있는 스토리지 전략을 계획하고 데이터 지속성을 염두에 두고 Ceph 클라이언트에 스토리지 풀로 제공할 수 있습니다.

2.2.1. Ceph 데몬과 이점 비교

링크 복사

컨테이너화된 Ceph 데몬을 동일한 호스트에서 배치할 수 있습니다. 다음은 일부 Ceph 데몬을 배치하면 다음과 같은 이점이 있습니다.

• 소규모로 총소유비용(total cost of ownership)을 크게 개선합니다.
• 전체 성능을 향상시킬 수 있습니다.
• 최소 구성의 물리적 호스트 양을 줄입니다.
• 리소스 활용 개선.
• Red Hat Ceph Storage를 보다 쉽게 업그레이드할 수 있습니다.

컨테이너를 사용하면 다음 목록에서 하나의 데몬을 Ceph OSD 데몬(ceph-osd)과 함께 배치할 수 있습니다. 또한 Ceph Object Gateway(radosgw), Ceph 메타데이터 서버(ceph-mds) 및 Grafana의 경우 Ceph OSD 데몬과 아래 목록의 데몬과 함께 배치할 수 있습니다.

• Ceph 메타 데이터 서버 (ceph-mds)
• Ceph Monitor (ceph-mon)
• Ceph Manager (ceph-mgr)
• NFS Ganesha(nfs-ganesha)
• Ceph Manager(ceph-grafana)

Expand

표 2.1. 데몬 배치 예

호스트 이름	데몬	데몬	데몬
host1	OSD	모니터링 및 관리자	Prometheus
host2	OSD	모니터링 및 관리자	RGW
host3	OSD	모니터링 및 관리자	RGW
host4	OSD	메타 데이터 서버
host5	OSD	메타 데이터 서버

Show more

참고

ceph-mon 및 ceph-mgr 은 공동 배치를 위해 두 개의 별도의 데몬으로 간주되지 않습니다.

Ceph 데몬을 ceph orch 명령에 --placement 옵션을 사용하여 명령행 인터페이스에서 배치하거나 서비스 사양 YAML 파일을 사용할 수 있습니다.

명령줄 예

[ceph: root@host01 /]# ceph orch apply mon --placement="host1 host2 host3"

Copy to Clipboard Toggle word wrap

서비스 사양 YAML 파일 예

service_type: mon
placement:
  hosts:
   - host01
   - host02
   - host03

Copy to Clipboard Toggle word wrap

[ceph: root@host01 /]# ceph orch apply -i mon.yml

Copy to Clipboard Toggle word wrap

Red Hat은 Ceph Object Gateway를 Ceph OSD 컨테이너와 연결하여 성능을 향상시키는 것이 좋습니다. 추가 하드웨어 비용을 발생시키지 않고 최고 성능을 달성하려면 호스트당 두 개의 Ceph Object Gateway 데몬을 사용합니다.

Ceph Object Gateway 명령줄 예

[ceph: root@host01 /]# ceph orch apply rgw example --placement="6 host1 host2 host3"

Copy to Clipboard Toggle word wrap

Ceph Object Gateway 서비스 사양 YAML 파일 예

service_type: rgw
service_id: example
placement:
  count: 6
  hosts:
   - host01
   - host02
   - host03

Copy to Clipboard Toggle word wrap

[ceph: root@host01 /]# ceph orch apply -i rgw.yml

Copy to Clipboard Toggle word wrap

아래 다이어그램은 공동 배치 및 비할당 데몬이 있는 스토리지 클러스터의 차이점을 보여줍니다.

그림 2.1. 공동 배치된 데몬

View larger image

그림 2.2. 공동배치되지 않은 데몬

View larger image