Red Hat Summit1장. 개요
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 클라이언트는 catalog, video 및 기타 데이터와 같은 개체에 RESTful S3 호환 및 Swift 호환 개체 스토리지를 제공하는 클라우드 플랫폼의 주요 스토리지 백엔드입니다.
- 비용/성능의 이점: 속도가 더 빠릅니다. 크기, 내구성 등이 더 우수합니다. 그러나 각 슈퍼워치에 대한 가격 및 해당 비용 / 혜택의 상향식 거래가 있습니다. 성능 관점에서 다음 사용 사례를 고려하십시오. SSD는 상대적으로 적은 양의 데이터 및 저널링에 매우 빠른 스토리지를 제공할 수 있습니다. 데이터베이스 또는 개체 인덱스를 저장하면 매우 빠른 SSD 풀의 이점이 될 수 있지만 다른 데이터에서는 비용이 너무 많이 듭니다. SSD 저널링을 사용하는 SAS 드라이브는 볼륨과 이미지의 경제적인 가격으로 빠른 성능을 제공합니다. SSD 저널링이 없는 SATA 드라이브는 전체 성능이 낮은 저렴한 스토리지를 제공합니다. OSD의ECDHE 계층 구조를 생성하는 경우 사용 사례와 비용/성능이 차단될 수 있는 문제를 고려해야 합니다.
-
대규모 클러스터에서 하드웨어 장애는 예외가 아니라 예상입니다. 그러나 데이터 손실 및 서비스 중단은 허용되지 않습니다. 이러한 이유로 데이터 지속성이 매우 중요합니다. Ceph는 여러 개체 복사본 또는 삭제 코딩 및 여러 코딩 청크를 사용하여 데이터를 처리합니다. 여러 사본 또는 여러 코딩 청크는 추가 비용/잘못된 절충을 제공합니다. 즉, 더 적은 사본이나 코딩 청크를 저장할 수 있지만 성능이 저하된 상태에서는 서비스 쓰기 요청을 처리할 수 없게 될 수 있습니다. 일반적으로 두 개의 추가 사본 (즉,
size = 3) 또는 두 개의 코딩 청크가 있는 한 개체를 사용하면 클러스터가 복구되는 동안 성능이 저하된 상태의 쓰기를 서비스할 수 있습니다. FlexVolume 알고리즘은 Ceph가 클러스터 내의 다른 위치에 추가 복사 또는 코딩 청크를 저장하도록 하여 이 프로세스를 지원합니다. 이렇게 하면 단일 스토리지 장치 또는 노드가 실패해도 데이터 손실을 방지하는 데 필요한 모든 복사본 또는 코딩 청크가 손실되지 않습니다.
스토리지 전략에서 사용 사례, 비용/가행 성능 장단점 및 데이터 대결을 캡처하여 Ceph 클라이언트에 스토리지 풀로 제공할 수 있습니다.
Ceph의 오브젝트 복사 또는 코딩 청크는 RAID를 더 이상 사용하지 않습니다. Ceph는 이미 데이터 지속성을 처리하므로 RAID를 사용하지 마십시오. 성능이 저하된 RAID는 성능에 부정적인 영향을 미치며 RAID를 사용하여 데이터를 복구하는 것은 깊은 복사본 또는 코딩 청크를 사용하는 것보다 훨씬 느립니다.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}