1장. 개요
Ceph 클라이언트의 관점에서 Ceph 스토리지 클러스터와 상호 작용하는 것은 매우 간단합니다.
- 클러스터에 연결
- 풀 I/O 컨텍스트 생성
이 간단한 인터페이스는 Ceph 클라이언트가 사용자가 정의한 스토리지 전략 중 하나를 선택하는 방법입니다. 스토리지 전략은 스토리지 용량 및 성능을 제외한 모든 Ceph 클라이언트와 볼 수 없습니다.
아래 다이어그램은 클라이언트에서 Red Hat Ceph Storage 클러스터로 시작하는 논리 데이터 흐름을 보여줍니다.
1.1. 스토리지 전략이란 무엇입니까?
스토리지 전략은 특정 사용 사례에 서비스를 제공하는 데이터를 저장하는 방법입니다. 예를 들어, OpenStack과 같은 클라우드 플랫폼에 대한 볼륨 및 이미지를 저장해야 하는 경우 SSD 기반 저널을 사용하여 합리적으로 수행하는 SAS 드라이브에 데이터를 저장할 수 있습니다. 반대로, S3- 또는 Swift 호환 게이트웨이에 대한 오브젝트 데이터를 저장해야 하는 경우 SATA 드라이브와 같이 보다 경제적 인 것을 사용할 수 있습니다. Ceph는 동일한 Ceph 클러스터에 두 시나리오를 모두 수용할 수 있지만 클라우드 플랫폼에 SAS/SSD 스토리지 전략(예: OpenStack의 Glance 및 Cinder)을 제공하고 개체 저장소에 대한 SATA 스토리지를 제공하는 수단이 필요합니다.
스토리지 전략에는 스토리지 미디어(하드 드라이브, SSD, 나머지), 스토리지 미디어의 성능 및 장애 도메인, 배치 그룹 수, 풀 인터페이스 등이 있습니다. Ceph는 여러 스토리지 전략을 지원합니다. 사용 사례, 비용/해제 성능 장단점 및 데이터 내구성은 스토리지 전략을 구동하는 주요 고려 사항입니다.
- 사용 사례: Ceph는 대용량 스토리지 용량을 제공하며 다양한 사용 사례를 지원합니다. 예를 들어 Ceph Block Device 클라이언트는 OpenStack과 같은 클라우드 플랫폼의 주요 스토리지 백엔드입니다. copy-on-write 복제와 같은 고성능 기능을 사용하여 볼륨 및 이미지의 제한 없는 스토리지를 제공합니다. 마찬가지로 Ceph는 OpenShift 환경에 컨테이너 기반 스토리지를 제공할 수 있습니다. 반면, Ceph Object Gateway 클라이언트는 오디오, 비트맵, 비디오 및 기타 데이터와 같은 개체에 대해 RESTful S3 호환 및 Swift 호환 개체 스토리지를 제공하는 클라우드 플랫폼의 선도적인 스토리지 백엔드입니다.
- 비용/성능: 빠른 것이 좋습니다. 더 큰 것이 더 좋습니다. 높은 내구성이 더 좋습니다. 그러나 각 감독질에 대한 가격이 있으며 해당 가격 / 거래 비용이 있습니다. 성능 관점에서 다음과 같은 사용 사례를 고려해 보십시오. SSD는 상대적으로 소량의 데이터와 저널링을 위해 매우 빠른 스토리지를 제공할 수 있습니다. 데이터베이스 또는 오브젝트 인덱스를 저장하면 매우 빠른 SSD 풀의 이점을 얻을 수 있지만 다른 데이터에는 너무 비용이 많이 듭니다. SSD 저널링을 사용하는 SAS 드라이브는 볼륨과 이미지의 경제적인 가격으로 빠른 성능을 제공합니다. SSD 저널링이 없는 SATA 드라이브는 전체 성능이 낮은 저렴한 스토리지를 제공합니다. OSD의 CRUSH 계층 구조를 생성할 때 사용 사례와 허용 가능한 비용/성능 문제를 고려해야 합니다.
-
내구성: 대규모 클러스터에서 하드웨어 장애는 예외가 아니라 예상되는 것입니다. 그러나 데이터 손실 및 서비스 중단은 허용되지 않습니다. 이러한 이유로 데이터 지속성이 매우 중요합니다. Ceph는 객체의 여러 깊은 사본이나 삭제 및 여러 코딩 청크를 사용하여 데이터 내구성을 해결합니다. 여러 사본 또는 여러 개의 코딩 청크가 추가 비용/분리점의 장단점을 제공합니다. 즉, 적은 수의 사본이나 코딩 청크를 저장하는 것이 더 저렴하지만 성능이 저하된 상태로 서비스 쓰기 요청이 실패할 수 없게 될 수 있습니다. 일반적으로 두 개의 추가 사본(즉,
size = 3) 또는 두 개의 코딩 청크가 있는 하나의 오브젝트를 사용하면 클러스터가 복구되는 동안 클러스터가 성능이 저하된 상태에서 쓰기를 수행할 수 있습니다. CRUSH 알고리즘은 Ceph가 클러스터 내의 다른 위치에 청크를 저장 또는 코딩할 수 있도록 하여 이 프로세스를 지원합니다. 이렇게 하면 단일 스토리지 장치 또는 노드의 오류가 발생하면 데이터 손실을 방지하기 위해 필요한 모든 사본 또는 코딩 청크가 손실되지 않습니다.
사용 사례, 비용/고정 성능 장단점 및 스토리지 전략의 데이터 내구성을 캡처하여 스토리지 풀로 Ceph 클라이언트에 제공할 수 있습니다.
Ceph의 개체 복사 또는 코딩 청크는 RAID를 더 이상 사용하지 않습니다. Ceph는 이미 데이터 지속성을 처리하므로 RAID를 사용하지 마십시오. 성능이 저하된 RAID는 성능에 부정적인 영향을 미치며 RAID를 사용하여 데이터를 복구하는 것은 깊은 복사본 또는 코딩 청크를 사용하는 것보다 훨씬 느립니다.
