이 이야기는 다음을 다루는 짧은 시리즈의 2/2부로 제공됩니다. 이레이저 코딩 및 RAID, 스토리지 시스템의 데이터 보호를 위한 가장 잘 알려진 두 가지 방법. 아래에서 Qumulo의 분산 파일 시스템이 블록 기반 보호를 사용하여 삭제 코딩 저장 방법을 현대화하는 방법을 설명하고 파일 저장 시스템에서 삭제 코딩을 구현하는 방법을 탐색합니다.
쿠물로 코어, Qumulo의 분산 파일 시스템 기반, 매우 안정적인 데이터 저장소를 제공합니다(수만 년의 신뢰성으로 측정됨). 우리는 데이터를 안전하게 유지하도록 설계된 Qumulo Core와 함께 표준으로 제공되는 많은 데이터 서비스 중 하나인 효율적인 삭제 코딩을 통해 부분적으로 이를 달성합니다.
파일 스토리지 시스템에서 이레이저 코딩 구현
구현 시 고려해야 할 실질적인 고려 사항이 많이 있습니다. 삭제 코딩 파일 스토리지 시스템에서. 필요한 패리티 블록을 쓰는 과정을 더 쉽게 하기 위해(그리고 디스크가 고장났을 때 데이터를 복원하기 위해), 확장 가능한 블록 스토어(SBS) 4K 패리티 블록의 가상 주소 공간을 보호 저장소 또는 pstore라고 하는 논리적 세그먼트로 나눕니다.
SBS는 각 pstore를 개별적으로 관리하므로 보호된 주소 공간을 디스크에 연결하는 매핑 체계를 보다 유연하게 만듭니다. 모든 pstore는 동일한 크기입니다. 데이터 보호는 시스템의 pstore 수준에서 완전히 구현됩니다. pstore는 보호된 가상 블록 주소 범위를 Qumulo 클러스터 노드의 가상 디스크에 있는 스토리지의 연속 영역에 매핑하는 테이블로 생각할 수 있습니다.
인접한 영역을 bstore라고 합니다. bstore에 대한 pstore의 맵은 클러스터의 각 노드에 저장됩니다.
피스토어 대 비스토어, 차이점이 뭐야?
- 피스토어: 4K 블록으로 분할된 가상 주소 공간.
- 비스토어: 가상 블록의 연속 영역. (pstores는 bstores에 매핑됩니다.)[/box]
신뢰성을 위해 클러스터의 노드는 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는 평생 동안 패리티 블록이나 데이터 블록을 포함하지만 둘 다 포함하지는 않습니다. 삭제 코딩은 SBS의 pstore 계층에서 구현되기 때문에 패리티 블록이 포함된 bstore와 데이터 블록이 포함된 bstore가 동일하게 동작합니다. bstore에 할당된 스토리지의 양은 적절한 삭제 코딩 체계에 따라 다릅니다. pstore 크기를 일관되게 유지하기 위해 시스템의 bstore 크기는 코딩 체계에 따라 변경됩니다. 예를 들어, pstore가 70GB인 경우 6,4 인코딩으로 각 bstore는 약 17.5GB가 되며, 이는 pstore를 4개의 bstore로 나눕니다. 10,8 인코딩의 경우 bstores는 해당 크기의 약 절반입니다.
클라우드에서 Qumulo는 한 가지 예외를 제외하고 온프레미스와 동일한 데이터 보호 체계를 사용합니다. 온-프레미스에서 데이터 보호 체계를 사용하려면 클러스터에 5,4개 이상의 노드가 있어야 합니다. 클라우드에서는 Qumulo의 파일 시스템이 모든 탄력적 저장소 블록에 있는 내장 미러링을 사용할 수 있기 때문에 단일 노드 클러스터를 가질 수 있습니다. 클라우드의 단일 노드 Qumulo 클러스터는 XNUMX 삭제 코딩을 사용합니다.
계산을 위해 절대 다운되지 않습니다
Qumulo 재구축 시간은 시간 단위로 측정됩니다. 대조적으로 데이터가 훨씬 적은 워크로드용으로 설계된 레거시 스토리지 시스템의 재구축 시간은 며칠로 측정되며 일부는 그보다 더 오래 걸립니다.
많은 수의 파일, 혼합 워크로드, 증가하는 디스크 밀도가 모두 레거시 스토리지 어플라이언스의 재구축 시간 위기에 기여했습니다. Qumulo의 극적인 이점은 SBS의 고급 블록 기반 보호의 직접적인 결과입니다. 블록 기반 보호는 페타바이트의 데이터와 수백만 개의 데이터가 있는 오늘날의 최신 워크로드에 이상적입니다. 수십억 개의 파일, 그 중 많은 수가 작습니다.
SBS 보호 시스템은 시간이 많이 소요되는 트리 워크나 파일별 재구축 작업을 수행할 필요가 없습니다. 대신, 재구축 작업은 pstore에서 작동합니다. 결과적으로 재구축 시간은 파일 크기의 영향을 받지 않습니다. 작은 파일은 큰 파일만큼 효율적으로 처리되며 수십억 개의 파일을 완벽하게 보호할 수 있습니다. 또한 Qumulo의 파일 시스템은 재구축 시간이 클러스터 크기에 부정적인 영향을 받지 않도록 설계되었습니다. 사실, 그 반대가 사실입니다. Qumulo를 사용하면 실제로 더 큰 클러스터가 더 작은 클러스터보다 재구축 시간이 더 빠릅니다.
[상자 유형 = "그림자"]알림: 레거시 스토리지와 달리 Qumulo는 재구축 노력을 클러스터의 노드 전체에 분산시켜 레거시 스토리지보다 재구축 시간을 단축합니다. 그리고 클러스터가 클수록 재구축 속도가 빨라집니다.[/box]
그 이유는 SBS가 클러스터의 노드 전체에 재구축 계산 노력을 분산하기 때문입니다. 노드가 많을수록 재구축 중에 각 노드가 수행해야 하는 작업이 줄어듭니다. 재구축 시간이 느린 레거시 스토리지 어플라이언스는 장기간 재구축 프로세스 동안 시스템이 이미 취약한 시간 동안 추가 오류가 발생하면 데이터 손실 위험이 있습니다.
즉, 느린 재구축 시간은 안정성에 부정적인 영향을 미칩니다. 일반적으로 관리자는 과잉 프로비저닝(즉, 데이터 중복성을 추가하여 효율성 감소)을 통해 이를 보완합니다. Qumulo의 빠른 재구축 시간을 통해 관리자는 평균 데이터 손실 시간(MTTDL) 많은 데이터 중복 없이 대상을 지정하여 비용과 시간을 절약합니다.
드라이브 오류 발생 시 pstore 재구축
디스크에 오류가 발생하면 보호된 저장소가 계속 존재합니다. 항상 읽고 쓸 수 있습니다. 그러나 일부 pstore에는 bstore가 없거나 손상된 경우가 있습니다. 이를 저하된 pstore라고 합니다. 이레이저 코딩으로 인해 저하된 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의 최상위 레이어로 이동합니다. 읽기는 삭제 코딩을 사용하여 맨 위 레이어와 맨 아래 레이어의 값을 결합합니다. bstore가 재구성되면 푸시 레이어가 사라집니다. 계층은 비차단 방식으로 SBS 트랜잭션 시스템의 구성 요소를 사용하여 구성됩니다.
작은 파일 저장 효율성
Qumulo 파일 시스템은 블록 기반 보호를 사용하기 때문에 작은 파일도 큰 파일만큼 효율적입니다.
다른 파일과 스트라이프를 공유할 수 있으며 보호 기능을 공유할 수 있습니다. 각 파일은 데이터 블록, 최소한 하나의 inode 블록 및 필요한 기타 블록으로 구성됩니다. 매우 작은 파일은 inode 블록에 인라인됩니다. 시스템은 4K 블록을 사용하며 모든 블록은 시스템 보호 비율로 보호됩니다.
쿠물로스 저장 효율성 작은 파일과 시스템 메타데이터에 대해 비효율적인 미러링을 사용하는 레거시 스토리지 어플라이언스에 비해 큰 이점입니다. 레거시 스토리지 시스템은 또한 8K 블록 크기를 사용하므로 작은 파일로 인해 큰 비효율을 초래할 수 있습니다.
귀하의 스토리지입니다. 100% 사용하십시오.
Qumulo 사용자 파일이 차지할 수 있음 프로비저닝된 용량의 100%, 레거시 수평 확장은 80~85%만 사용할 것을 권장합니다. Qumulo의 블록 기반 보호는 사용자가 프로비저닝한 용량에서 제외되는 소량의 예비 공간 외에 재보호를 위해 사용자가 프로비저닝한 용량이 필요하지 않습니다.
대조적으로, 레거시 스토리지 어플라이언스는 고정 RAID 그룹을 사용하거나 파일별로 삭제 코딩을 사용하여 보호를 구현합니다. 즉, 재보호도 파일 수준에서 발생하고 복구하려면 사용자가 프로비저닝한 용량이 필요합니다. (보다 삭제 코딩 대 RAID 설명 자세한 내용은 참조하십시오.) 또한 Qumulo 파일 시스템은 사용자 파일에 사용할 수 있는 용량을 정확하게 보고합니다.
다시 말하지만, 이러한 예측 가능성은 블록 기반 보호의 결과입니다. 레거시 시스템에서 스토리지 사용은 파일 크기에 따라 달라지므로 이러한 시스템은 원시 공간에 대해서만 보고할 수 있습니다. 관리자는 실제로 얼마나 많은 공간이 있는지 추측할 수 있습니다. Qumulo를 레거시 시스템과 비교할 때 각 유형의 시스템에서 실제로 사용할 수 있는 사용자 프로비저닝 용량을 고려하고 싶을 것입니다.
편집자 주: 원래 11년 2021월 XNUMX일에 게시된 이 기사는 정확성과 포괄성을 위해 업데이트되었습니다.
