Qumulo의 분산 파일 시스템

이레이저 코딩 기반 데이터 보호

디스크 오류 발생 시 데이터 손실을 방지하려면 항상 어떤 형태의 중복성 또는 저장 장치 간의 정보 복제가 포함됩니다.

가장 단순한 형태의 데이터 보호는 미러링입니다. 미러링은 보호되는 데이터의 전체 복사본이 두 개 이상 있음을 의미합니다. 각 복사본은 다른 디스크에 상주하므로 디스크 중 하나가 실패할 경우 복구할 수 있습니다. 미러링은 구현이 간단하지만 최신 데이터 보호 기술에 비해 단점이 있습니다. 미러링은 데이터 보호에 필요한 공간 측면에서 낭비입니다. 또한 단일 디스크 오류만 처리하며 일반적으로 노드 밀도 및 클러스터 크기가 증가함에 따라 안전 수준이 충분히 높지 않습니다.

데이터 보호를 위한 다른 전략에는 RAID 스트라이핑이 포함됩니다. RAID는 매우 복잡한 관리를 필요로 하고 느린 재구축 시간으로 인해 관리자는 허용할 수 없을 정도로 긴 재구축 또는 허용할 수 없는 스토리지 효율성 중에서 선택해야 합니다.

SBS는 다음과 같은 효율적인 기술로 블록 기반 데이터 보호를 구현합니다. 삭제 코딩 (EC).

EC는 미러링 및 RAID 스트라이핑과 같은 대안보다 더 빠르고 구성 가능하며 공간 효율적입니다. EC는 서로 다른 물리적 미디어에 저장된 중복 세그먼트를 사용하여 블록 데이터를 인코딩합니다. EC의 효율성으로 인해 RAID 및 미러링 방식에 비해 데이터에 더 많은 디스크를 사용할 수 있으므로 사용 가능한 테라바이트당 비용이 절감됩니다.

EC는 성능, 물리적 미디어에 장애가 발생한 경우 복구 시간, 허용되는 동시 장애 수에 대한 절충안으로 구성할 수 있습니다. 특정 EC 구성을 나타내기 위해 "m" 및 "n" 표기법을 사용할 것입니다. 여기서 "m"은 "n" 사용자 블록을 안전하게 인코딩하는 데 사용되는 물리적 미디어 블록의 총 수를 나타냅니다. 인코딩은 "최대 m – n" 블록이 사용자 데이터 손실 없이 파괴될 수 있는 속성이 있습니다. 즉, "n"개의 디스크 모음이 남아 있으면 오류가 발생한 디스크 중 일부에 사용자 데이터가 포함된 경우에도 모든 사용자 데이터를 복구하기에 충분합니다. 인코딩의 효율성은 "n/m"의 숫자 또는 사용자 블록을 전체 블록으로 나눈 비율로 계산할 수 있습니다.

EC는 예를 들어 이해하는 것이 가장 쉽습니다. 다음은 (3,2) 인코딩이라는 간단한 예입니다.

(3,2) 인코딩에는 두 개의 블록(n = 3)을 안전하게 인코딩하기 위해 세 개의 고유한 물리적 장치에 저장된 세 개의 블록(m = 2)이 필요합니다. 블록 중 두 개는 보호하려는 사용자 데이터를 포함하고 세 번째 블록은 패리티 블록이라고 합니다. 패리티 블록의 내용은 이레이저 코딩 알고리즘에 의해 계산됩니다. 이 간단한 구성표도 미러링보다 효율적입니다. 즉, 두 데이터 블록마다 하나의 패리티 블록만 쓰는 것입니다. (3, 2) 인코딩에서 세 블록 중 하나를 포함하는 디스크에 장애가 발생하면 블록 1과 2의 사용자 데이터는 안전합니다.

작동 방식은 다음과 같습니다. 데이터 블록 1을 사용할 수 있으면 읽기만 하면 됩니다. 데이터 블록 2에 대해서도 마찬가지입니다. 그러나 데이터 블록 1이 다운되면 EC 시스템은 데이터 블록 2와 패리티 블록을 읽고 리드 솔로몬 공식(이 특정 예에서 비트 단위 XOR).

마찬가지로 데이터 블록 2가 장애가 발생한 디스크에 있는 경우 시스템은 데이터 블록 1과 패리티 블록을 읽습니다. SBS는 시스템이 블록에서 동시에 읽을 수 있도록 블록이 다른 스핀들에 있는지 확인합니다. (3,2) 인코딩의 효율성은 2/3(n/m) 또는 67%입니다. 데이터 저장 측면에서 미러링의 50% 효율성보다 낫지만 (3,2) 인코딩은 여전히 ​​단일 디스크 오류에 대해서만 보호할 수 있습니다.

최소한 Qumulo는 (6, 4) 인코딩을 사용합니다. 이 인코딩은 미러링과 동일한 공간에 세 번째 사용자 데이터를 추가로 저장하고 미러링처럼 하나의 디스크 오류가 아닌 두 개의 디스크 오류를 허용하는 기능입니다. 사용자 데이터를 포함하는 두 개의 블록을 사용할 수 없는 경우에도 시스템은 누락된 데이터를 복구하기 위해 나머지 두 개의 데이터 블록과 두 개의 패리티 블록만 읽으면 됩니다.

노드 전체에 보호된 가상 블록 배포

다음과 같은 경우 고려해야 할 실제적인 고려 사항이 많이 있습니다. 삭제 코딩 구현 대규모 확장성을 갖춘 시스템에서 필요한 패리티 블록을 더 쉽게 작성하고 디스크에 오류가 발생할 때 데이터를 복원하기 위해 SBS는 4K 블록의 가상 주소 공간을 보호 저장소 또는 pstore라고 하는 논리적 세그먼트로 나눕니다.

SBS는 각 pstore를 개별적으로 관리하므로 보호된 주소 공간을 디스크에 연결하는 매핑 체계를 보다 유연하게 만듭니다. 모든 pstore는 동일한 크기입니다. 데이터 보호는 시스템의 pstore 수준에서 완전히 구현됩니다. pstore는 보호된 가상 블록 주소 범위를 Qumulo 클러스터 노드의 가상 디스크에 있는 스토리지의 연속 영역에 매핑하는 테이블로 생각할 수 있습니다.

인접한 영역을 bstore라고 합니다. bstore에 대한 pstore의 맵은 클러스터의 각 노드에 저장됩니다.

신뢰성을 위해 클러스터의 노드는 이라는 분산 알고리즘을 사용합니다. Paxos pstore-to-bstore 맵과 같이 전 세계적으로 공유되는 지식에 대한 합의를 유지합니다. 클러스터는 클러스터의 중요한 데이터 구조의 안전을 보장하기 위해 노드의 쿼럼을 형성합니다. 각 bstore는 특정 가상 디스크의 세그먼트를 사용합니다(즉, bstore는 특정 SSD 및 HDD 쌍과 연결됨).

각 bstore에는 연결된 HDD의 연속 공간이 할당되고 bstore의 연결된 SDD 공간은 동적으로 할당됩니다. bstore에 대한 메타데이터는 연결된 SSD에도 존재합니다. Bstore 메타데이터에는 사용 중인 주소와 같은 정보와 bstore가 SSD 저장소를 참조하고 HDD에 있는 블록 주소를 나타내는 맵이 포함됩니다.

읽기 또는 쓰기 중에 pstore는 액세스해야 하는 bstore를 결정합니다. 파일 시스템의 클라이언트가 쓰기 작업을 시작하면 원시 데이터 스트림으로 SBS에 들어갑니다. 시스템은 데이터를 쓸 bstore를 파악하고 패리티 데이터를 계산하며 SSD가 여러 노드에 있더라도 원시 데이터와 패리티 데이터를 동시에 SSD에 씁니다. 데이터가 기록되면 사용자는 쓰기가 발생했다는 확인을 받습니다.

사용자 데이터와 패리티 블록을 포함하는 데이터 블록은 모두 bstore에 기록됩니다. 특정 bstore는 평생 동안 패리티 블록이나 데이터 블록을 포함하지만 둘 다 포함하지는 않습니다. EC는 SBS의 pstore 계층에서 구현되기 때문에 패리티 블록이 포함된 bstore와 데이터 블록이 포함된 bstore가 동일하게 동작합니다. bstore에 할당된 스토리지의 양은 EC 선택에 따라 다릅니다. pstore 크기를 일관되게 유지하기 위해 시스템의 bstore 크기는 코딩 체계에 따라 변경됩니다. 예를 들어, pstore가 70GB인 경우 (6,4) 인코딩을 사용하면 각 bstore는 약 17.5GB이며, 이는 pstore를 4개의 bstore로 나눕니다. (10, 8) 인코딩의 경우 bstores는 그 크기의 약 절반이 됩니다.

클라우드에서 Qumulo는 한 가지 예외를 제외하고 온프레미스와 동일한 데이터 보호 체계를 사용합니다. 온프레미스에서 데이터 보호 체계를 사용하려면 클러스터에 노드가 5개 이상 있어야 합니다. 클라우드에서는 Qumulo의 파일 시스템이 모든 탄력적 저장소 블록에 있는 내장 미러링을 사용할 수 있기 때문에 단일 노드 클러스터를 가질 수 있습니다. 클라우드의 단일 노드 Qumulo 클러스터는 (4, XNUMX) 삭제 코딩을 사용합니다.

빠른 재구축 시간

Qumulo 재구축 시간은 시간 단위로 측정됩니다. 대조적으로 데이터가 훨씬 적은 워크로드용으로 설계된 레거시 스토리지 시스템의 재구축 시간은 며칠 단위로 측정됩니다.

많은 수의 파일, 혼합 워크로드, 증가하는 디스크 밀도가 모두 레거시 스토리지 어플라이언스의 재구축 시간 위기에 기여했습니다. Qumulo의 극적인 이점은 SBS의 고급 블록 기반 보호의 직접적인 결과입니다. 블록 기반 보호는 페타바이트 규모의 데이터와 수백만 개의 파일(대부분이 작음)이 있는 오늘날의 최신 워크로드에 이상적입니다.

SBS 보호 시스템은 시간이 많이 소요되는 트리 워크나 파일별 재구축 작업을 수행할 필요가 없습니다. 대신, 재구축 작업은 pstore에서 작동합니다. 결과적으로 재구축 시간은 파일 크기의 영향을 받지 않습니다. 작은 파일은 큰 파일만큼 효율적으로 처리되며 수백만 개의 파일을 완벽하게 보호할 수 있습니다. 또한 Qumulo의 파일 시스템은 재구축 시간이 클러스터 크기에 부정적인 영향을 받지 않도록 설계되었습니다. 사실, 그 반대가 사실입니다. Qumulo를 사용하면 더 큰 클러스터가 더 작은 클러스터보다 재구축 시간이 더 빠릅니다.

그 이유는 SBS가 클러스터의 노드 전체에 재구축 계산 노력을 분산하기 때문입니다. 노드가 많을수록 재구축 중에 각 노드가 수행해야 하는 작업이 줄어듭니다. 재구축 시간이 느린 레거시 스토리지 어플라이언스는 장기간 재구축 과정에서 발생할 수 있는 추가 오류에 취약합니다.

즉, 느린 재구축 시간은 안정성에 부정적인 영향을 미칩니다. 일반적으로 관리자는 과잉 프로비저닝(즉, 데이터 중복성을 추가하여 효율성 감소)을 통해 이를 보완합니다. Qumulo의 빠른 재구축 시간으로 관리자는 많은 중복 없이 MTTDL(Mean Time To Data Loss) 목표를 유지하여 비용과 시간을 절약할 수 있습니다.

pstore 재건

디스크에 오류가 발생하면 보호된 저장소가 계속 존재합니다. 항상 읽고 쓸 수 있습니다. 그러나 일부 pstore에는 bstore가 없거나 손상된 경우가 있습니다. 이를 저하된 pstore라고 합니다. EC로 인해 저하된 pstore를 계속 읽을 수 있지만 데이터는 더 이상 완전히 보호되지 않습니다. 즉, 첫 번째 오류에서 여전히 데이터 무결성이 있지만 데이터 손실에 더 가까운 하나의 디스크입니다. 데이터를 다시 보호하기 위해 시스템은 오류가 발생한 디스크 드라이브에 있는 bstore를 재구성하기 위해 (레거시 시스템에서와 같이 RAID 그룹이 있는 파일 단위가 아니라) pstore 단위로 작동합니다.

SBS는 소량의 추가 디스크 공간을 할당하므로 이를 수행할 공간이 있습니다. 이것을 절약이라고 합니다. 전역 pstore-to-bstore 맵에는 bstore와 연결된 가상 디스크의 ID가 포함되어 있으므로 이 정보를 통해 특정 디스크에 장애가 발생했을 때 처리해야 하는 pstore를 쉽게 알 수 있습니다. pstore와 bstore를 연결하는 맵은 모든 노드의 메모리에 상주할 만큼 충분히 작기 때문에 노드는 가상 블록 주소를 pstore에서 bstore로 빠르게 변환할 수 있습니다.

재구축 과정에서 SBS는 bstore를 순차적으로 읽고 씁니다. bstore는 디스크에 연속적으로 배치되기 때문에 성능이 저하된 pstore는 매우 빠르게 재구축될 수 있습니다. 순차 작업은 느리고 디스크 경합을 유발할 수 있는 많은 소규모 I/O 작업보다 훨씬 빠릅니다. SBS의 재구축 프로세스는 효율적입니다. 디스크는 재구축 프로세스 동안 한 번에 정확히 하나의 읽기 또는 쓰기 스트림에 관여합니다. 임의 I/O가 필요하지 않습니다.

또한 bstores는 재보호 작업이 전체 클러스터에 효율적으로 분산될 만큼 충분히 작습니다.

재구축의 영향을 받지 않는 일반 파일 작업

레거시 파일 시스템에서 잠금 경합은 재구축 시간에 영향을 미치고 재구축 중 표준 파일 시스템 작업을 느리게 합니다. 이는 이러한 파일 작업이 재구축/재보호 스레드와 경쟁하기 때문입니다. Qumulo는 재구축 작업이 파일 시스템의 일반적인 사용과 경합하지 않도록 독립적인 잠금 체계와 함께 쓰기 계층을 사용합니다.

장애가 발생하면 성능이 저하된 pstore의 불완전한 bstore 집합에 쓰는 것이 의미가 없습니다. 새 쓰기는 완전히 보호되지 않으며 bstore 재구성 작업이 복잡해집니다. 그러나 클러스터는 재구축 작업 중에 다운타임이 발생해서는 안 되며 결과적으로 사용자가 시작한 쓰기 작업은 pstore가 다시 보호될 때까지 기다릴 수 없습니다. 이러한 쓰기를 수행하기 위해 시스템은 성능이 저하된 pstore에 가상 bstore의 새 계층을 추가합니다. 이것을 "층 밀기"라고 합니다. 쓰기는 bstore의 새 계층으로 이동하고 읽기는 각 계층의 값을 결합합니다. 다음은 예입니다.

새로운 쓰기는 bstore의 최상위 레이어로 이동합니다. 읽기는 EC를 사용하여 맨 위 레이어와 맨 아래 레이어의 값을 결합합니다. bstore가 재구성되면 푸시 레이어가 사라집니다. 계층은 비차단 방식으로 SBS 트랜잭션 시스템의 구성 요소를 사용하여 구성됩니다.

작은 파일은 큰 파일만큼 효율적입니다.

Qumulo 파일 시스템은 블록 기반 보호를 사용하기 때문에 작은 파일도 큰 파일만큼 효율적입니다.

다른 파일과 스트라이프를 공유할 수 있으며 보호 기능을 공유할 수 있습니다. 각 파일은 데이터 블록, 최소한 하나의 inode 블록 및 필요한 기타 블록으로 구성됩니다. 매우 작은 파일은 inode 블록에 인라인됩니다. 시스템은 4K 블록을 사용하며 모든 블록은 시스템 보호 비율로 보호됩니다.

작은 파일에 대한 Qumulo의 효율성은 작은 파일 및 시스템 메타데이터에 비효율적인 미러링을 사용하는 레거시 스토리지 어플라이언스에 비해 큰 이점입니다.

프로비저닝된 모든 용량은 사용자 파일에 사용할 수 있습니다.

Qumulo 사용자 파일은 프로비저닝된 용량의 100%를 차지할 수 있지만 레거시 확장은 80~85%만 사용할 것을 권장합니다. Qumulo의 블록 기반 보호는 사용자가 프로비저닝한 용량에서 제외되는 소량의 예비 공간 외에 재보호를 위해 사용자가 프로비저닝한 용량이 필요하지 않습니다. 대조적으로, 레거시 스토리지 어플라이언스는 고정 RAID 그룹을 사용하거나 파일별로 삭제 코딩을 사용하여 보호를 구현합니다. 즉, 재보호도 파일 수준에서 발생하고 복구하려면 사용자가 프로비저닝한 용량이 필요합니다. 또한 Qumulo 파일 시스템은 사용자 파일에 사용 가능한 용량을 정확하게 보고합니다.

다시 말하지만, 이러한 예측 가능성은 블록 기반 보호의 결과입니다. 레거시 시스템에서 스토리지 사용은 파일 크기에 따라 달라지므로 이러한 시스템은 원시 공간에 대해서만 보고할 수 있습니다. 관리자는 실제로 얼마나 많은 공간이 있는지 추측할 수 있습니다. Qumulo를 레거시 시스템과 비교할 때 각 유형의 시스템에서 실제로 사용할 수 있는 사용자 프로비저닝 용량을 고려하고 싶을 것입니다.