2.3. Red Hat Ceph Storage 워크로드 고려 사항

Ceph 스토리지 클러스터의 주요 이점 중 하나는 성능 도메인을 사용하여 동일한 스토리지 클러스터 내에서 다양한 유형의 워크로드를 지원할 수 있다는 것입니다. 각 성능 도메인과 다른 하드웨어 구성을 연결할 수 있습니다. 스토리지 관리자는 적절한 성능 도메인에 스토리지 풀을 배포할 수 있으므로 애플리케이션에 특정 성능 및 비용 프로필에 맞는 스토리지를 제공할 수 있습니다. 이러한 성능 도메인에 맞게 크기가 조정되고 최적화된 서버를 선택하는 것은 Red Hat Ceph Storage 클러스터를 설계하는 데 있어 필수적인 부분입니다.

데이터를 읽고 쓰는 Ceph 클라이언트 인터페이스의 경우 Ceph 스토리지 클러스터는 클라이언트가 데이터를 저장하는 간단한 풀로 나타납니다. 그러나 스토리지 클러스터는 클라이언트 인터페이스에 완전히 투명한 방식으로 많은 복잡한 작업을 수행합니다. Ceph OSD라고 하는 Ceph 클라이언트 및 Ceph 개체 스토리지 데몬은 모두 오브젝트 스토리지 및 검색에 대해 CRUSH(Controlled Replication Under Scalable Hashing) 알고리즘을 사용합니다. Ceph OSD는 컨테이너 또는 RPM 기반 배포를 사용하여 스토리지 클러스터 내의 베어 메탈 서버 또는 가상 시스템에서 실행할 수 있습니다.

CRUSH 맵은 클러스터 리소스의 토폴로지를 설명하고 이 맵은 클라이언트 노드와 클러스터 내의 Ceph 모니터 노드에 모두 존재합니다. Ceph 클라이언트 및 Ceph OSD는 모두 CRUSH 맵과 CRUSH 알고리즘을 사용합니다. Ceph 클라이언트는 OSD와 직접 통신하여 중앙 집중식 개체 조회 및 잠재적인 성능 병목 현상을 제거합니다. CRUSH 맵과 해당 피어의 통신을 인식하면 OSD에서 복제, 백필 및 복구 기능을 처리할 수 있으므로 동적 오류 복구를 수행할 수 있습니다.

Ceph는 CRUSH 맵을 사용하여 장애 도메인을 구현합니다. 또한 Ceph는 CRUSH 맵을 사용하여 성능 도메인을 구현합니다. 이 도메인은 단순히 기본 하드웨어의 성능 프로파일을 고려합니다. CRUSH 맵은 Ceph가 데이터를 저장하는 방법을 설명하고, 이는 단순한 계층 구조, 특히 재활용 그래프 및 규칙 세트로 구현됩니다. CRUSH 맵은 여러 계층 구조를 지원하여 한 가지 유형의 하드웨어 성능 프로필을 분리할 수 있습니다. Ceph는 장치 "클래스"로 성능 도메인을 구현합니다.

예를 들어 동일한 Red Hat Ceph Storage 클러스터에 이러한 성능 도메인을 공존할 수 있습니다.

  • 일반적으로 HDD(하드 디스크 드라이브)는 비용 및 용량 중심 워크로드에 적합합니다.
  • 처리량에 민감한 워크로드는 일반적으로 SSD(반도체 드라이브)에서 Ceph 쓰기 저널과 함께 HDD를 사용합니다.
  • MySQL 및 MariaDB와 같은 IOPS 집약적인 워크로드에서는 SSD를 사용하는 경우가 많습니다.

워크로드

Red Hat Ceph Storage는 세 가지 주요 워크로드에 최적화되어 있습니다:

  • IOPS 최적화: IOPS(초당 입력, 출력당) 최적화 배포는 OpenStack에서 가상 시스템으로 RuntimeClass 또는 MariaDB 인스턴스를 실행하는 것과 같은 클라우드 컴퓨팅 작업에 적합합니다. IOPS 최적화된 배포에는 15k RPM SAS 드라이브와 같은 고성능 스토리지 및 자주 쓰기 작업을 처리하기 위해 별도의 SSD 저널이 필요합니다. 일부 IOPS 시나리오에서는 모든 Flash 스토리지를 사용하여 IOPS 및 총 처리량을 개선합니다.

    IOPS가 최적화된 스토리지 클러스터에는 다음과 같은 속성이 있습니다.

    • IOPS당 최소 비용.
    • GB당 최대 IOPS.
    • 99번째 백분위 대기 시간 일관성.

    IOPS에 최적화된 스토리지 클러스터의 용도는 다음과 같습니다.

    • 일반적인 블록 스토리지.
    • 하드 드라이브(HDD)의 3x 복제 또는 솔리드 스테이트 드라이브(SSD)의 2x 복제.
    • OpenStack 클라우드의 MySQL.
  • 최적화된 처리량: 처리량 최적화 배포는 그래픽, 오디오 및 비디오 콘텐츠와 같은 상당한 양의 데이터를 제공하는 데 적합합니다. 처리량에 최적화된 배포에는 높은 대역폭 네트워킹 하드웨어, 컨트롤러 및 하드 디스크 드라이브, 순차적 읽기 및 쓰기 기능이 필요합니다. 빠른 데이터 액세스가 요구 사항인 경우 처리량 최적화 스토리지 전략을 사용합니다. 또한 빠른 쓰기 성능이 필요한 경우 저널에 Solid State Disks (SSD)를 사용하면 쓰기 성능이 크게 향상됩니다.

    처리량 최적화 스토리지 클러스터에는 다음과 같은 속성이 있습니다.

    • MBps당 가장 낮은 비용(처리량)
    • TB당 최대 MBps
    • BTU당 최대 MBps
    • Watt당 가장 높은 MBps
    • 97%의 대기 시간 일관성

    처리량 최적화 스토리지 클러스터에 대한 사용은 다음과 같습니다.

    • 블록 또는 오브젝트 스토리지
    • 3x 복제
    • 비디오, 오디오 및 이미지를 위한 활성 성능 스토리지
    • 4K 영상 등의 스트리밍 미디어
  • 용량 최적화: 용량 최적화 배포는 많은 양의 데이터를 최대한 저렴하게 저장하는 데 적합합니다. 용량 최적화 배포는 일반적으로 더 큰 가격대에 대한 성능을 거래합니다. 예를 들어 용량 최적화 배포에서는 저널링에 SSD를 사용하지 않고 속도가 느리고 비용이 적게 드는 SATA 드라이브를 사용하는 경우가 많습니다.

    비용 및 용량 최적화 스토리지 클러스터에는 다음과 같은 속성이 있습니다.

    • TB당 최소 비용
    • TB당 최소 BTU 수
    • TB당 필요한 최소 Watt

    비용 및 용량 최적화 스토리지 클러스터에 대한 사용은 다음과 같습니다.

    • 일반적으로 오브젝트 스토리지
    • 사용 가능한 용량을 극대화하기 위한 지우기 코딩
    • 오브젝트 아카이브
    • 비디오, 오디오 및 이미지 오브젝트 리포지토리
중요

스토리지 클러스터의 가격 및 성능에 큰 영향을 미칠 수 있으므로 어떤 하드웨어를 구입할지 고려하기 전에 Red Hat Ceph Storage 클러스터에서 실행되는 워크로드를 신중하게 고려합니다. 예를 들어 워크로드가 용량에 최적화되고 처리량이 최적화된 워크로드에 하드웨어가 더 적합한 경우 하드웨어는 필요한 것보다 비용이 많이 듭니다. 반대로 워크로드가 처리량에 최적화되고 하드웨어가 용량이 최적화된 워크로드에 더 적합한 경우 스토리지 클러스터가 성능이 저하될 수 있습니다.