Qumulo 하이브리드 클라우드 파일 기술 개요

현대적이고 확장성이 뛰어난 스토리지

QF2(Qumulo File Fabric)는 데이터 센터와 퍼블릭 클라우드에 걸쳐 확장성이 뛰어난 최신 파일 스토리지 시스템입니다. 수십억 개의 파일로 확장되고 비용이 적게 들며 레거시 스토리지 어플라이언스보다 TCO가 낮습니다. 또한 온프레미스 및 클라우드에서 최고 성능의 파일 스토리지 시스템입니다. 내장된 실시간 분석 기능을 통해 관리자는 공간이 얼마나 크거나 데이터가 전 세계적으로 어디에 있든 관계없이 데이터를 쉽게 관리할 수 있습니다.

QF2는 예를 들어 온프레미스 클러스터와 클라우드에서 실행되는 클러스터 간에 파일 데이터를 필요할 때 필요한 위치로 이동합니다. QF2를 사용하면 전 세계 어디에서나 여러 환경에서 방대한 데이터 세트를 저장하고 관리할 수 있습니다. QF2의 소프트웨어는 온프레미스 또는 클라우드 인스턴스 및 클라우드 스토리지 리소스에서 업계 표준 하드웨어에서 실행됩니다. QF2는 처음부터 오늘날의 확장성 및 데이터 이동성 요구 사항을 충족하도록 설계되었습니다. 세계 최초의 범용 파일 저장 시스템입니다.

Qumulo는 전적으로 고급 소프트웨어를 기반으로 하는 새로운 유형의 스토리지 회사입니다. Qumulo는 하드웨어에 비해 소프트웨어의 가치가 증가하는 더 큰 산업 추세의 일부입니다. 고급 분산 소프트웨어를 실행하는 상용 하드웨어는 최신 저비용 확장형 컴퓨팅의 확실한 기반입니다. 이는 대규모 파일 저장소에서도 마찬가지입니다.

QF2가 작동하는 것을 처음 본 사람들은 종종 "어떻게 그럴 수 있지?"라고 묻습니다. 그 질문에 답하는 것이 이 논문의 이유입니다. QF2에 고유한 기능을 제공하는 몇 가지 고급 기술에 대해 자세히 살펴보겠습니다.

데이터 이동성, 선형 확장성 및 글로벌 범위

확장성을 위해 QF2에는 많은 개별 컴퓨팅 노드가 함께 작동하여 확장 가능한 성능과 단일 통합 파일 시스템을 갖춘 클러스터를 형성하는 분산 아키텍처가 있습니다. 그러면 QF2 클러스터가 함께 작동하여 전 세계적으로 분산되지만 연속 복제 관계로 연결된 고도로 연결된 스토리지 패브릭을 형성합니다.

고객은 업계 표준 파일 프로토콜, QF2 REST API 및 스토리지 관리자를 위한 웹 기반 그래픽 사용자 인터페이스(GUI)를 사용하여 QF2 클러스터와 상호 작용합니다.

이 다이어그램은 클라이언트, Qumulo Core를 실행하는 노드로 구성된 QF2 클러스터, 여러 환경 및 지리적 위치에서 실행되는 패브릭을 구성하는 여러 QF2 클러스터 간의 연결을 보여줍니다.

QF2는 모듈식 시스템입니다. QF2 클러스터에 대한 수요가 증가하면 노드나 인스턴스를 추가하기만 하면 됩니다. 용량과 성능은 선형적으로 확장되며 이는 QF2 클러스터가 온프레미스 데이터 센터에서 작동하든 퍼블릭 클라우드에서 작동하든 마찬가지입니다.

QF2에 포함된 기능

QF2는 소프트웨어와 서비스로 구성됩니다. 간단하고 투명한 구독 기반 가격으로 제공됩니다. 다음은 QF2 구독에 포함된 항목에 대한 다이어그램입니다. Qumulo Core는 QF2 클러스터의 각 노드에서 실행되는 소프트웨어입니다. 여기에는 강력한 실시간 분석 및 용량 할당량, 연속 복제 및 스냅샷이 포함됩니다. 이러한 기능은 다른 시스템과 달리 파일 메타데이터의 통합 실시간 집계를 포함하는 확장성이 뛰어난 QF2 파일 시스템을 기반으로 합니다.

QF2 파일 시스템은 Qumulo SBS(Scalable Block Store)라는 강력한 최신 데이터 관리 시스템 위에 구축되었습니다. SBS는 대규모로 확장 가능한 분산 데이터베이스의 원칙을 사용하며 파일 기반 데이터의 특수한 요구 사항에 최적화되어 있습니다. Scalable Block Store는 QF2 파일 시스템의 블록 계층으로, 파일 시스템을 더 간단하게 구현하고 매우 강력하게 만듭니다. SBS는 또한 파일 시스템에 대규모 확장성, 최적화된 성능 및 데이터 보호를 제공합니다.

QF2는 포괄적인 고객 지원과 함께 QF2 구독의 일부로 클라우드 기반 모니터링 및 추세 분석을 제공합니다. 클라우드 모니터링에는 문제가 발생하기 전에 예방하기 위해 디스크 오류와 같은 이벤트의 사전 감지가 포함됩니다. 과거 추세에 대한 액세스는 스토리지 투자를 최대한 활용하기 위해 비용을 절감하고 작업 흐름을 최적화하는 데 도움이 됩니다.

운영 환경 선택

Qumulo Core 소프트웨어는 퍼블릭 클라우드와 데이터 센터의 업계 표준 하드웨어에서 실행됩니다. Qumulo Core는 현재 Qumulo의 자체 QC 시리즈 화이트 박스 서버와 HPE(Hewlett-Packard Enterprise) Apollo 서버에서 실행됩니다. QF2는 하드웨어 독립적이기 때문에 하나의 하드웨어 공급업체에 의존하지 않으며 실제로 Qumulo가 여러 OEM의 서버에 대한 지원을 추가할 것이라고 예상할 수 있습니다.

QF2의 소프트웨어 전용 접근 방식은 NVRAM, InfiniBand 스위치 및 독점 플래시 스토리지와 같은 값비싼 독점 구성 요소에 대한 종속성이 없음을 의미합니다. 대신 QF2는 드라이브 제조업체에서 사용할 수 있는 표준 펌웨어가 포함된 하드 디스크 드라이브(HDD) 및 솔리드 스테이트 드라이브(SSD)를 사용합니다. 핫 데이터와 콜드 데이터의 자동 계층화를 위한 표준 SSD와 HDD의 조합은 QF2가 아카이브 스토리지 가격으로 플래시 성능을 제공하는 이유 중 하나입니다.

퍼블릭 클라우드(현재 AWS)에서 QF2 클러스터를 생성할 수도 있습니다. 클라우드 기반 QF2 클러스터의 노드는 온프레미스 QF2 클러스터와 동일한 Qumulo Core 소프트웨어를 실행합니다. 다른 클라우드 기반 파일 스토리지 시스템과 달리 퍼블릭 클라우드에서 실행되는 QF2 클러스터에는 성능 및 용량에 대한 엄격한 제한이 없습니다. 둘 다 노드(컴퓨팅 인스턴스 및 블록 스토리지)를 추가하여 늘릴 수 있습니다. QF2는 용량과 성능을 모두 유연하게 확장할 수 있는 유일한 클라우드용 솔루션입니다.

클라우드에서 실행할 때 QF2는 온프레미스에서 SSD/HDD 조합과 유사한 방식으로 클라우드 블록 스토리지를 사용합니다. QF2는 대기 시간이 짧은 블록 스토리지를 경제적인 대기 시간이 더 긴 블록 스토리지 앞에 있는 캐시로 사용합니다. 백서의 나머지 부분에서는 SSD와 HDD에 대해 설명하겠지만 논의된 개념은 QF2의 퍼블릭 클라우드에서 대기 시간이 짧거나 긴 블록 스토리지 리소스 사용자에게 동일하게 적용됩니다.

QF2 클러스터의 각 노드에서 Qumulo Core는 커널 공간이 아닌 Linux 사용자 공간에서 실행됩니다. 커널 모드는 주로 특정 하드웨어와 함께 작동하는 장치 드라이버용입니다. 사용자 공간에서 작동함으로써 QF2는 다양한 구성 및 환경에서 실행될 수 있으며 훨씬 더 빠른 속도로 기능을 제공할 수도 있습니다.

사용자 공간에서 실행된다는 것은 QF2가 SMB, NFS, LDAP 및 Active Directory와 같은 중요한 프로토콜을 자체적으로 구현할 수 있음을 의미합니다. 예를 들어, QF2의 NFS 구현은 시스템 서비스로 실행되며 실행되는 기본 운영 체제와 별개인 자체 사용자 및 그룹 개념을 가지고 있습니다.

사용자 공간에서 실행하면 QF2 안정성도 향상됩니다. 독립적인 사용자 공간 프로세스로서 QF2는 메모리 손상을 일으킬 수 있는 다른 시스템 구성 요소와 격리되며 QF2 개발 프로세스는 소프트웨어 릴리스 전에 메모리 관련 코딩 오류를 감지할 수 있는 고급 메모리 검증 도구를 사용할 수 있습니다. 소프트웨어 업그레이드에 이중 파티션 전략을 사용함으로써 Qumulo는 빠르고 안정적인 업그레이드를 위해 운영 체제와 Qumulo Core 소프트웨어를 모두 자동으로 업데이트할 수 있습니다. OS, 노드 또는 클러스터를 재부팅하지 않고도 QF2를 쉽게 다시 시작할 수 있습니다.

대규모 확장 가능한 파일 및 디렉토리

파일 수가 많으면 디렉터리 구조와 파일 속성 자체가 빅데이터가 됩니다. 결과적으로 레거시 스토리지의 기본인 트리 워크와 같은 순차적 프로세스는 더 이상 계산적으로 실현 가능하지 않습니다. 대신 대규모 파일 시스템을 쿼리하고 관리하려면 병렬 및 분산 알고리즘을 사용하는 새로운 접근 방식이 필요합니다.

QF2가 바로 그 역할을 합니다. 확장성 문제에 접근하는 방식이 독특합니다. 그 디자인은 현대의 대규모 분산 데이터베이스에서 사용하는 것과 유사한 원칙을 구현합니다. 결과는 일치하지 않는 확장 특성을 가진 파일 시스템입니다. 이와는 대조적으로 레거시 스토리지 어플라이언스는 오늘날의 대규모 데이터 공간을 처리하도록 설계되지 않았습니다.

QF2 파일 시스템은 SBS라는 가상화된 블록 계층 위에 위치합니다. QF2에서는 파일 시스템 아래 SBS 계층에서 발생하는 보호, 재구축 및 데이터를 저장할 디스크 결정과 같은 시간 소모적인 작업이 발생합니다. (보호된 가상 블록 및 트랜잭션에 대해서는 이 백서의 뒷부분에서 자세히 설명합니다.)

SBS의 가상화된 보호 블록 기능은 QF2 파일 시스템의 큰 장점입니다. SBS가 없는 레거시 스토리지 시스템에서는 파일 기반으로 또는 고정 RAID 그룹을 사용하여 보호가 이루어지므로 긴 재구축 시간, 작은 파일의 비효율적인 스토리지, 비용이 많이 드는 디스크 레이아웃 관리와 같은 많은 어려운 문제가 발생합니다. 가상화된 블록 레이어가 없으면 레거시 스토리지 시스템도 메타데이터 레이어 자체 내에서 데이터 보호를 구현해야 하며 이러한 추가 복잡성으로 인해 이러한 시스템이 디렉터리 데이터 구조 및 메타데이터에 대한 분산 트랜잭션을 최적화하는 기능이 제한됩니다.

파일 및 디렉토리의 확장성을 위해 QF2 파일 시스템은 다음과 같은 인덱스 데이터 구조를 광범위하게 사용합니다. B- 트리. B-트리는 데이터 양이 증가함에 따라 각 작업에 필요한 I/O 양을 최소화하는 "얕은" 데이터 구조이기 때문에 많은 수의 데이터 블록을 읽고 쓰는 시스템에 특히 적합합니다. B-트리를 기반으로 데이터 블록을 읽거나 삽입하는 계산 비용은 데이터 양이 증가함에 따라 매우 느리게 증가합니다. 예를 들어 B-트리는 파일 시스템과 매우 큰 데이터베이스 인덱스에 이상적입니다.

QF2에서 B-트리는 블록 기반입니다. 각 블록은 4096바이트입니다. 다음은 B-트리의 구조를 보여주는 예입니다.

각 4K 블록에는 다른 4K 블록에 대한 포인터가 있을 수 있습니다. 이 특정 B-트리에는 분기 계수가 3이며 분기 계수는 트리의 각 노드에 있는 자식(하위 노드)의 수입니다.

수백만 개의 블록이 있더라도 루트에서 데이터가 있는 위치까지 SBS의 B-트리 높이는 1~XNUMX단계에 불과할 수 있습니다. 예를 들어 다이어그램에서 인덱스 값이 XNUMX인 레이블 q를 조회하기 위해 시스템은 트리의 두 수준만 통과합니다.

QF2 파일 시스템은 다양한 목적으로 B-트리를 사용합니다.

거기에 아이 노드 모든 파일의 색인 역할을 하는 B-트리. inode 목록은 파일 시스템의 일관성을 디렉토리 계층 구조와 독립적으로 검사하는 표준 파일 시스템 구현 기술입니다. 또한 Inode는 디렉토리 이동과 같은 업데이트 작업을 효율적으로 만드는 데 도움이 됩니다.

파일과 디렉터리는 파일 이름, 파일 크기, 액세스 제어 목록(ACL) 또는 POSIX 권한과 같은 고유한 키/값 쌍이 있는 B-트리로 표시됩니다.

구성 데이터도 B-트리이며 IP 주소 및 클러스터와 같은 정보를 포함합니다.

실제로 QF2 파일 시스템은 트리의 트리로 생각할 수 있습니다. 다음은 예입니다.

최상위 트리를 슈퍼 B-트리라고 합니다. 시스템이 시작되면 그곳에서 처리가 시작됩니다. 루트는 항상 가상 보호 블록 배열의 첫 번째 주소(“paddr 1.1”)에 저장됩니다. 루트 트리는 다른 B-트리를 참조합니다. 예를 들어 QF2 파일 시스템이 구성 데이터에 액세스해야 하는 경우 구성 B-트리로 이동합니다. 특정 파일을 찾기 위해 시스템은 inode 번호를 인덱스로 사용하여 inode B-tree를 쿼리합니다. 시스템은 파일 B-트리에 대한 포인터를 찾을 때까지 inode 트리를 순회합니다. 거기에서 파일 시스템은 파일에 대한 모든 것을 조회할 수 있습니다. 디렉토리는 파일처럼 취급됩니다.

SBS에서 가상화된 보호 블록 스토리지를 가리키는 B-트리에 의존하는 것은 QF2에서 XNUMX조 개의 파일이 있는 파일 시스템이 가능한 이유 중 하나입니다.

QumuloDB를 통한 실시간 가시성 및 제어

QF2는 파일 데이터를 저장하는 것 이상의 기능을 수행하도록 설계되었습니다. 또한 데이터와 사용자를 실시간으로 관리할 수 있습니다. 레거시 스토리지 어플라이언스의 관리자는 "데이터 무지"로 인해 어려움을 겪고 있습니다. 그들은 파일 시스템에서 무슨 일이 일어나고 있는지에 대한 정확한 그림을 얻을 수 없습니다. QF2는 얼마나 많은 파일과 디렉토리가 있든 관계없이 정확히 그러한 종류의 가시성을 제공하도록 설계되었습니다. 예를 들어 처리량 추세 및 핫스팟에 대한 즉각적인 통찰력을 얻을 수 있습니다. 실시간 용량 할당량을 설정하여 레거시 스토리지의 시간 소모적인 할당량 프로비저닝 오버헤드를 방지할 수도 있습니다. 그래픽 사용자 인터페이스를 통해 정보에 액세스할 수 있으며 프로그래밍 방식으로 정보에 액세스할 수 있는 REST API도 있습니다.

QF2 파일 시스템의 통합 분석 기능은 QumuloDB라는 구성 요소에서 제공됩니다.

사람들이 QF2의 실시간 분석을 소개받고 대규모로 수행되는 것을 볼 때 일반적으로 첫 번째 질문은 "어떻게 그렇게 빠를 수 있습니까?"입니다. QF2의 실시간 분석의 획기적인 성능은 세 가지 이유로 가능합니다.

첫째, QF2 파일 시스템에는 QumuloDB 분석 기능이 내장되어 있으며 파일 시스템 자체와 완전히 통합되어 있습니다. 레거시 시스템에서 메타데이터 쿼리는 관련 없는 소프트웨어 구성 요소에 의해 코어 파일 시스템 외부에서 응답됩니다.

둘째, QF2 파일 시스템은 B-트리에 의존하기 때문에 QumuloDB 분석은 다음 섹션에서 설명하는 혁신적인 실시간 집계 시스템을 사용할 수 있습니다.

마지막으로 QF2 파일 시스템은 B-트리 인덱스와 Qumulo SBS(Scalable Block Store)의 가상화된 보호 블록 및 트랜잭션을 사용하여 간소화된 설계를 갖추고 있기 때문에 QumuloDB 분석이 가능합니다.

메타데이터의 실시간 집계

QF2 파일 시스템에서 사용된 바이트 및 파일 수와 같은 메타데이터는 파일 및 디렉터리가 생성되거나 수정될 때 집계됩니다. 이는 비용이 많이 드는 파일 시스템 트리 워크 없이 정보를 적시에 처리할 수 있음을 의미합니다.

QumuloDB는 최신 메타데이터 요약을 유지합니다. 파일 시스템의 B-트리를 사용합니다.
변경 사항이 발생할 때 파일 시스템에 대한 정보를 수집합니다. 다양한 메타데이터 필드가 파일 시스템 내부에 요약되어 가상 인덱스를 생성합니다. GUI에서 볼 수 있고 REST API로 가져올 수 있는 성능 분석은 QF2 파일 시스템에 내장된 샘플링 메커니즘을 기반으로 합니다. 샘플링 알고리즘이 더 큰 디렉토리와 파일에 더 많은 가중치를 부여할 수 있도록 하는 최신 메타데이터 요약이 있기 때문에 통계적으로 유효한 샘플링 기술이 가능합니다.

QF2에서 메타데이터 집계는 상향식 및 하향식 접근 방식을 사용합니다.

각 파일(또는 디렉토리)이 새로 집계된 메타데이터로 업데이트되면 상위 디렉토리가 "더티"로 표시되고 다른 업데이트 이벤트가 상위 디렉토리에 대해 대기합니다. 이러한 방식으로 파일 시스템 정보는 트리 위로 전달되는 동안 수집 및 집계됩니다. 데이터가 실시간으로 액세스될 때 메타데이터는 가장 낮은 수준의 개별 inode에서 파일 시스템의 루트로 전파됩니다. 각 파일 및 디렉토리 작업이 고려되며 이 정보는 결국 파일 시스템의 핵심까지 전파됩니다. 다음은 예입니다.

왼쪽 트리는 파일 및 디렉토리 정보를 집계하고 이를 메타데이터에 통합합니다. 그런 다음 상위 디렉토리에 대한 업데이트가 대기됩니다. 정보는 잎에서 뿌리로 이동합니다.

메타데이터 이벤트의 상향식 전파와 병행하여 주기적 순회가 파일 시스템의 상단에서 시작되어 메타데이터에 있는 집계 정보를 읽습니다. 순회가 최근에 업데이트된 집계 정보를 찾으면 검색을 정리하고 다음 분기로 이동합니다. 집계된 정보가 파일 시스템 트리에서 이 시점부터 리프(포함된 모든 파일 및 디렉터리 포함)까지 최신 상태이며 추가 분석을 위해 더 깊이 들어갈 필요가 없다고 가정합니다. 대부분의 메타데이터 요약은 이미 계산되었으며 이상적으로 순회는 전체 파일 시스템에 대한 메타데이터의 작은 하위 집합만 요약하면 됩니다. 실제로 전체 파일 시스템 트리를 위에서 아래로 탐색할 필요 없이 집계 프로세스의 두 부분이 중간에서 만납니다.

샘플링 및 메타데이터 쿼리

QF2의 실시간 분석의 한 예는 성능 핫스팟 보고서입니다. 다음은 GUI의 예입니다.

GUI 내에서 모든 처리량 작업 및 IOPS를 나타내는 것은 대규모 파일 시스템에서 실행 불가능합니다. 대신 QumuloDB 쿼리는 확률적 샘플링을 사용하여 이 정보의 통계적으로 유효한 근사치를 제공합니다. IOPS 읽기 및 쓰기 작업의 총계와 I/O 처리량 읽기 및 쓰기 작업은 몇 초마다 업데이트되는 4,096개 항목의 메모리 내 버퍼에서 수집된 샘플에서 생성됩니다.

여기에 표시된 보고서는 클러스터에 가장 큰 영향을 미치는 작업을 표시합니다. 이들은 GUI에서 핫스팟으로 표시됩니다.

통계적으로 유효한 확률적 샘플링을 사용하는 QF2의 기능은 QumuloDB에서 지속적으로 최신 상태로 유지되는 각 디렉터리(사용된 바이트, 파일 수)에 대한 요약된 메타데이터 때문에만 가능합니다. 이는 다른 파일 스토리지 시스템에서는 볼 수 없는 QF2의 고급 소프트웨어 기술의 고유한 이점입니다.

실시간 할당량

메타데이터의 실시간 집계가 QF2의 실시간 분석을 가능하게 하는 것처럼 실시간 용량 할당량도 가능합니다. 할당량을 통해 관리자는 주어진 디렉토리가 파일에 사용할 수 있는 용량을 지정할 수 있습니다. 예를 들어 관리자는 불량 사용자가 하위 디렉터리를 너무 빨리 확장시키는 것을 발견하면 해당 사용자 디렉터리의 용량을 즉시 제한할 수 있습니다.

QF2에서 할당량은 즉시 배포되며 프로비저닝할 필요가 없습니다. 실시간으로 적용되며 용량 변경 사항이 즉시 구현됩니다. 부수적인 이점은 디렉터리에 할당된 할당량이 디렉터리와 함께 이동하고 디렉터리 자체를 할당량 도메인 안팎으로 이동할 수 있다는 것입니다.

일부 다른 시스템과 달리 Qumulo 할당량은 파일 시스템을 볼륨으로 나눌 필요가 없습니다. 또한 QF2를 사용하면 할당량을 이동하거나 할당량 도메인 간에 디렉터리를 이동할 때 긴 트리 워크, 작업 일정 또는 번거로운 다단계 프로세스가 필요하지 않습니다. QF2의 할당량은 중첩 디렉터리를 포함한 모든 디렉터리에 적용할 수 있습니다. 중첩된 디렉터리로 인해 할당에 둘 이상의 할당량이 있는 경우 요청된 공간을 할당하려면 모든 할당량을 충족해야 합니다.

QF2의 할당량 제한은 디렉터리 수준에서 메타데이터로 기록되기 때문에 디렉터리 트리의 모든 수준에서 할당량을 지정할 수 있습니다. 쓰기 작업이 발생하면 모든 관련 할당량이 충족되어야 합니다. 이것은 엄격한 한계입니다. QF2의 실시간 할당량의 정확성과 민첩성은 기본 제공 수집기가 지속적으로 디렉터리당 사용된 총 스토리지 양의 요약을 최신 상태로 유지하기 때문에 가능합니다.

스냅 샷

스냅샷을 사용하면 시스템 관리자는 지정된 시점에서 파일 시스템 또는 디렉토리의 상태를 보존할 수 있습니다. 파일이나 디렉토리가 실수로 수정되거나 삭제된 경우 사용자 또는 관리자는 이를 저장된 상태로 되돌릴 수 있습니다.

QF2의 스냅샷에는 매우 효율적이고 확장 가능한 구현이 있습니다. 단일 QF2 클러스터는 성능이나 용량 저하 없이 거의 무제한의 동시 스냅샷을 가질 수 있습니다.

스냅샷은 잘못된 블록 쓰기로 구현됩니다. 스냅샷이 생성되고 블록이 수정되면 B-트리 블록의 새 스파인에 기록됩니다. 수정되지 않은 기존 블록은 새 척추에 연결되어 이제 공유됩니다. 새로 수정된 스파인은 "제자리에서 벗어나" 작성되었지만 여전히 기존 데이터를 참조하여 변경되지 않은 블록을 공유합니다. 데이터가 수정되거나 삭제될 때까지 스냅샷은 공간을 사용하지 않습니다.

예를 들어 QF4 파일 시스템에 2MB 파일을 추가한 다음 스냅샷을 생성한다고 가정합니다. 스냅샷이 생성된 후에도 사용되는 용량은 여전히 ​​4MB에 불과합니다. 그런 다음 파일의 1MB 영역을 수정합니다. 새 데이터(1MB)가 제 위치에 기록되지 않고 파일의 "라이브" 버전과 연결됩니다. 원본 3MB 데이터 중 4MB는 라이브 버전과 스냅샷에 캡처된 버전 간에 공유됩니다. 이 파일의 총 스토리지 사용량은 이제 5MB입니다.

스냅샷은 사용자가 실수로 파일 데이터를 삭제하거나 수정하는 경우 파일 시스템을 탄력적으로 만드는 데 도움이 되는 안전 기능입니다. 예를 들어 일부 데이터가 실수로 삭제된 경우 사용자는 이전에 찍은 스냅샷에서 파일을 복구할 수 있습니다. 단일 파일 또는 전체 디렉토리는 라이브 파일 시스템으로 다시 복사하여 복원할 수 있습니다.

공간이 부족해지면 관리자는 스토리지를 확보하기 위해 종종 스냅샷을 삭제하기로 결정합니다. 스냅샷은 데이터를 공유하기 때문에 일반적으로 스냅샷을 삭제해도 스냅샷에 포함된 모든 파일의 합계와 동일한 공간이 회수되지 않습니다. 레거시 시스템에서는 실제로 얼마나 많은 공간이 회수되는지 알기 어렵습니다.

QF2의 스냅샷은 파일 시스템에 내장된 인텔리전스를 활용합니다. 관리자는 일련의 스냅샷을 삭제할 경우 실제로 회수되는 스토리지 양을 계산할 수 있습니다.

지속적인 복제

QF2는 온프레미스 또는 퍼블릭 클라우드에 상관없이 스토리지 클러스터 전체에서 연속 복제를 제공합니다. 원본 클러스터와 대상 클러스터 간의 복제 관계가 설정되고 동기화되면 QF2는 자동으로 데이터 일관성을 유지합니다.

QF2의 연속 복제는 QF2의 고급 스냅샷 기능을 활용하여 일관된 데이터 복제를 보장합니다. QF2 스냅샷을 사용하면 대상 클러스터의 복제본이 정확한 시간에 소스 디렉토리의 상태를 재현합니다. QF2 복제 관계는 최대의 유연성을 위해 디렉토리별로 설정할 수 있습니다.

Qumulo는 스마트 알고리즘을 적용하여 복제를 관리하므로 사용자가 그럴 필요가 없습니다. QF2는 전체 클러스터 성능에 부정적인 영향을 미치지 않으면서 가능한 한 자주 복제합니다. 현재 QF2의 연속 복제는 단방향 비동기식입니다. 즉, 소스와 읽기 전용 대상이 있습니다. 소스 디렉토리에 대한 변경 사항은 대상에 비동기식으로 전파됩니다.

Qumulo 확장 가능 블록 스토어(SBS)

QF2 파일 시스템의 내부를 살펴보았으므로 이제 Qumulo Scalable Block Store에서 발견되는 분산 블록 관리를 위한 QF2의 고급 전략으로 넘어가겠습니다. 다음은 SBS 내부 내용에 대한 개요입니다.

SBS는 보호된 스토리지 블록의 트랜잭션 가상 계층을 제공합니다. 모든 파일이 자체적으로 보호를 파악해야 하는 시스템 대신 파일 시스템 아래 블록 수준에서 데이터 보호가 존재합니다.

SBS에서 구현한 QF2의 블록 기반 보호는 파일 크기가 혼합된 워크로드와 페타바이트 규모의 데이터가 있는 환경에서 뛰어난 성능을 제공합니다.

SBS에는 다음과 같은 많은 이점이 있습니다.

• 디스크 드라이브 고장 시 빠른 재구축 시간
• 재구축 작업 중에 정상적인 파일 작업을 계속하는 기능
• 일반 파일 쓰기와 재구축 쓰기 간의 경합으로 인한 성능 저하 없음
• 작은 파일을 큰 파일과 동일한 스토리지 효율성
• 사용 가능한 공간의 정확한 보고
• QF2 클러스터를 수백 개의 노드로 확장할 수 있는 효율적인 트랜잭션
• 아카이브 가격으로 플래시 성능을 제공하는 기본 제공 핫/콜드 데이터 계층화.

SBS가 이러한 이점을 달성하는 방법을 이해하려면 작동 방식을 살펴봐야 합니다.

보호된 가상 블록

QF2 클러스터의 전체 스토리지 용량은 개념적으로 여기에 표시된 단일 보호 가상 주소 공간으로 구성됩니다.

해당 공간 내의 각 보호 주소는 4K 바이트 블록을 저장합니다. "보호"란 여러 디스크에 장애가 발생하더라도 모든 블록을 복구할 수 있음을 의미합니다. 보호에 대해서는 이 백서의 뒷부분에서 자세히 설명합니다.

전체 파일 시스템은 사용자 데이터, 파일 메타데이터, 디렉터리 구조, 분석 및 구성 정보를 포함하여 SBS에서 제공하는 보호된 가상 주소 공간 내에 저장됩니다. 즉, 보호된 저장소는 파일 시스템과 연결된 블록 장치에 기록된 블록 기반 데이터 간의 인터페이스 역할을 합니다. 이러한 장치는 SSD와 HDD를 결합하여 형성된 가상 디스크이거나 클라우드의 블록 스토리지 리소스일 수 있습니다.

보호된 주소 공간의 블록은 QF2 클러스터의 모든 노드 또는 인스턴스에 분산되어 있습니다. 그러나 QF2 파일 시스템에는 완전히 보호된 블록의 선형 배열만 표시됩니다.

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

디스크 오류 발생 시 데이터 손실을 방지하려면 항상 어떤 형태의 중복성 또는 저장 장치 간 정보 복제가 포함됩니다. 가장 간단한 형태의 데이터 보호는 미러링입니다. 미러링은 보호되는 데이터의 전체 복사본이 두 개 이상 있음을 의미합니다. 각 복사본은 서로 다른 디스크에 상주하므로 디스크 중 하나에 장애가 발생해도 복구할 수 있습니다.

미러링은 구현이 간단하지만 최신 보호 기술에 비해 단점이 있습니다. 미러링은 데이터를 보호하는 데 필요한 공간 측면에서 낭비적이며 단일 디스크 오류만 처리하므로 일반적으로 노드 밀도와 클러스터 크기가 증가함에 따라 충분히 높은 수준의 안전성이 아닙니다.

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

SBS는 다음과 같은 효율적인 기술로 블록 기반 데이터 보호를 구현합니다. 삭제 코딩 (EC). SBS는 리드 솔로몬 코드를 사용합니다. EC는 미러링 및 RAID 스트라이핑과 같은 대안보다 빠르고 구성 가능하며 공간 효율적입니다.

EC는 서로 다른 물리적 매체 세트에 저장된 중복 세그먼트를 사용하여 블록 데이터를 인코딩합니다. EC의 효율성으로 인해 RAID 및 미러링 방식과 비교할 때 더 많은 디스크를 데이터에 사용할 수 있으므로 사용 가능한 TB당 비용이 절감됩니다.

이레이저 코딩은 성능, 물리적 미디어 장애 시 복구 시간, 허용 가능한 동시 장애 수에 대한 트레이드오프로 구성할 수 있습니다. 이 백서에서는 표기법 (m, n)을 사용하여 특정 EC 구성을 나타냅니다. 여기서 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와 패리티 블록을 읽고 리드-솔로몬 공식을 사용하여 데이터 블록 1의 값을 재구성합니다(이 특정 예에서는 단지 비트별 XOR). 마찬가지로 데이터 블록 2가 장애가 발생한 디스크에 있는 경우 시스템은 데이터 블록 1과 패리티 블록을 읽습니다. SBS는 시스템이 블록에서 동시에 읽을 수 있도록 블록이 서로 다른 스핀들에 있는지 확인합니다.

(3,2) 인코딩의 효율은 2/3(n/m) 또는 67%입니다. 데이터 저장 측면에서 미러링의 50% 효율성보다 낫지만 (3,2) 인코딩은 여전히 ​​단일 디스크 장애에 대해서만 보호할 수 있습니다.

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

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

대규모 확장성을 가진 시스템에서 EC를 구현할 때 고려해야 할 많은 실질적인 고려 사항이 있습니다. 필요한 패리티 블록을 쓰는 프로세스를 더 쉽게 만들고 디스크 오류 시 데이터를 복원하기 위해 SBS는 4K 블록의 가상 주소 공간을 보호 저장소 또는 pstore라는 논리적 세그먼트로 나눕니다.

SBS는 각 pstore를 개별적으로 관리하여 보호된 주소 공간을 디스크에 연결하는 매핑 체계를 보다 유연하게 만듭니다. 모든 pstore는 동일한 크기입니다. 데이터 보호는 시스템의 pstore 수준에서 완전히 구현됩니다.

pstore는 보호된 가상 블록 주소 범위를 QF2 클러스터 노드의 가상 디스크에 상주하는 스토리지의 연속 영역에 매핑하는 테이블로 생각할 수 있습니다. 인접한 영역을 bstore라고 합니다.

pstores에서 bstores로의 맵은 클러스터의 각 노드에 의해 저장됩니다. 안정성을 위해 클러스터의 노드는 다음과 같은 분산 알고리즘을 사용합니다. 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) 인코딩의 경우 bstore는 그 크기의 약 절반이 됩니다.

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

빠른 재구축 시간

QF2 재구축 시간은 시간 단위로 측정됩니다. 반대로 데이터가 훨씬 적은 워크로드용으로 설계된 레거시 스토리지 시스템은 재구축 시간이 수 일 단위로 측정됩니다. 많은 수의 파일, 혼합 워크로드 및 증가하는 디스크 밀도는 모두 레거시 스토리지 어플라이언스의 재구축 시간 위기에 기여했습니다. 재구축 시간에서 QF2의 극적인 이점은 SBS의 고급 블록 기반 보호의 직접적인 결과입니다.

블록 기반 보호는 페타바이트의 데이터와 수백만 개의 파일이 있고 대부분이 작은 오늘날의 현대적인 워크로드에 이상적입니다. SBS 보호 시스템은 시간 소모적인 트리 워크 또는 파일별 재구축 작업을 수행할 필요가 없습니다. 대신 재구축 작업은 pstore에서 작동합니다. 결과적으로 재구축 시간은 파일 크기의 영향을 받지 않습니다. 작은 파일은 큰 파일만큼 효율적으로 처리되며 수백만 개의 파일을 완벽하게 보호할 수 있습니다.

또한 QF2는 재구축 시간이 클러스터 크기에 의해 부정적인 영향을 받지 않도록 설계되었습니다. 사실 그 반대입니다. QF2에서 큰 클러스터는 작은 클러스터보다 재구축 시간이 더 빠릅니다. 그 이유는 SBS가 클러스터의 노드 전체에 재구축 계산 노력을 분산시키기 때문입니다. 노드가 많을수록 재구축 중에 각 노드가 수행해야 하는 작업이 줄어듭니다.

재구축 시간이 느린 레거시 스토리지 어플라이언스는 장기 재구축 프로세스 중에 발생할 수 있는 추가 오류에 취약합니다. 즉, 느린 재구축 시간은 안정성에 부정적인 영향을 미칩니다. 일반적으로 관리자는 오버프로비저닝(즉, 데이터 중복성을 추가하여 효율성 감소)을 통해 이를 보상합니다. QF2의 빠른 재구축 시간을 통해 관리자는 많은 중복 없이 MTTDL(Mean Time To Data Loss) 목표를 유지할 수 있으므로 비용과 시간이 모두 절약됩니다.

pstore 재건

디스크에 장애가 발생해도 보호된 저장소는 여전히 존재합니다. 항상 읽고 쓸 수 있습니다. 그러나 일부 pstore에는 누락되거나 손상된 bstore가 있습니다. 이를 저하된 pstore라고 합니다. EC로 인해 저하된 pstore를 계속 읽을 수 있지만 데이터는 더 이상 완전히 보호되지 않습니다. 즉, 첫 번째 장애 시 데이터 무결성은 여전히 ​​유지되지만 데이터 손실에 한 디스크 더 가까워집니다.

데이터를 다시 보호하기 위해 시스템은 (레거시 시스템에서와 같이 RAID 그룹이 있는 파일 단위가 아니라) pstore 단위로 작업하여 고장난 디스크 드라이브에 있던 bstore를 재구성합니다. SBS는 소량의 추가 디스크 공간을 할당하므로 이 작업을 수행할 공간이 있습니다. 이를 스페어링이라고 합니다.

전역 pstore-to-bstore 맵에는 bstore와 연결된 가상 디스크의 ID가 포함되어 있으므로 이 정보를 사용하면 특정 디스크가 실패할 때 처리가 필요한 pstore를 쉽게 알 수 있습니다. pstore와 bstore를 연결하는 맵은 모든 노드의 메모리에 상주할 만큼 충분히 작기 때문에 노드는 가상 블록 주소를 pstore에서 bstore로 빠르게 변환할 수 있습니다.

재구축 프로세스 동안 SBS는 bstore를 순차적으로 읽고 씁니다. bstore는 디스크에 연속적으로 배치되므로 성능이 저하된 pstore는 매우 빠르게 재구축할 수 있습니다. 순차 작업은 느리고 디스크 경합을 일으킬 수 있는 많은 작은 I/O 작업보다 훨씬 빠릅니다. SBS의 재구축 프로세스는 효율적입니다. 디스크는 재구축 프로세스 동안 한 번에 정확히 하나의 읽기 또는 쓰기 스트림에 관여합니다. 임의 I/O가 필요하지 않습니다. 또한 bstore는 다시 보호 작업이 전체 클러스터에 효율적으로 분산되도록 충분히 작습니다.

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

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

장애가 발생하면 성능이 저하된 pstore의 불완전한 bstore 세트에 쓰는 것은 의미가 없습니다. 새 쓰기는 완전히 보호되지 않으며 bstore 재구성 작업을 복잡하게 만듭니다. 그러나 클러스터는 재구축 작업 중에 다운타임이 발생하지 않아야 하며, 그 결과 사용자가 시작한 쓰기 작업은 pstore가 다시 보호될 때까지 기다릴 수 없습니다.

이러한 쓰기를 수행하기 위해 시스템은 성능이 저하된 pstore에 새로운 가상 bstore 계층을 추가합니다. 이것을 "레이어 밀기"라고 합니다. 쓰기는 bstores의 새 계층으로 이동하고 읽기는 각 계층의 값을 결합합니다. 다음은 예입니다.

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

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

QF2 파일 시스템은 블록 기반 보호를 사용하기 때문에 작은 파일도 큰 파일만큼 효율적입니다. 그들은 다른 파일과 스트라이프를 공유할 수 있고 보호를 공유할 수 있습니다. 각 파일은 데이터 블록, 하나 이상의 inode 블록 및 필요한 기타 블록으로 구성됩니다. 매우 작은 파일은 inode 블록에 인라인됩니다. 시스템은 4K 블록을 사용하며 모든 블록은 시스템 보호 비율로 보호됩니다.

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

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

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

또한 QF2 파일 시스템은 사용자 파일에 사용할 수 있는 용량을 정확하게 보고합니다. 다시 말하지만, 이 예측 가능성은 블록 기반 보호의 결과입니다. 레거시 시스템에서 스토리지 사용은 파일 크기에 따라 달라지므로 이러한 시스템은 원시 공간에 대해서만 보고할 수 있습니다. 관리자는 실제로 얼마나 많은 공간이 있는지 추측해야 합니다.

QF2를 레거시 시스템과 비교할 때 각 유형의 시스템에서 실제로 사용할 수 있는 사용자 프로비저닝 용량을 고려해야 합니다.

거래 내역

SBS에서 보호된 가상 주소 공간에 대한 읽기 및 쓰기는 트랜잭션입니다. 즉, 예를 들어 QF2 파일 시스템 작업에 둘 이상의 블록이 포함된 쓰기 작업이 필요한 경우 해당 작업은 모든 관련 블록을 쓰거나 전혀 쓰지 않습니다. 원자적 읽기 및 쓰기 작업은 데이터 일관성과 SMB 및 NFS와 같은 파일 프로토콜의 올바른 구현에 필수적입니다.

최적의 성능을 위해 SBS는 I/O 작업의 트랜잭션 일관성을 유지하면서 병렬성과 분산 컴퓨팅을 최대화하는 기술을 사용합니다. 예를 들어 SBS는 작업이 병렬이 아닌 순서대로 진행되는 직렬 병목 현상을 방지하도록 설계되었습니다.

SBS의 트랜잭션 시스템은 미리 쓰기 로깅, 실행 취소 작업 중 기록 반복 및 실행 취소 작업 로깅을 포함하여 비차단 트랜잭션에 ARIES 알고리즘의 원칙을 사용합니다. 그러나 SBS의 트랜잭션 구현에는 ARIES와 몇 가지 중요한 차이점이 있습니다.

SBS는 트랜잭션이 오래 지속될 수 있는 범용 데이터베이스와 달리 QF2 파일 시스템에 의해 시작된 트랜잭션이 예상대로 짧다는 사실을 이용합니다. 수명이 짧은 트랜잭션이 있는 사용 패턴을 통해 SBS는 효율성을 위해 트랜잭션 로그를 자주 트리밍할 수 있습니다. 수명이 짧은 거래는 더 빠른 약정 주문을 허용합니다.

또한 SBS의 트랜잭션은 고도로 분산되어 있으며 전역적으로 정의된 각 트랜잭션 로그 항목에 대한 ARIES 스타일 시퀀스 번호의 전체 순서가 필요하지 않습니다. 대신 트랜잭션 로그는 각 bstore에서 로컬로 순차적이며 커밋 순서 제약 조건을 고려하는 부분 순서 체계를 사용하여 전역 수준에서 조정됩니다.

Qumulo DB는 2PL(2단계 잠금) 프로토콜을 사용하여 일관된 커밋 순서 지정을 위한 직렬화 가능성을 구현합니다. 직렬화 가능 작업은 분산 처리 장치(bstore)에 의해 수행되며 의도한 작업 순서가 사후에 재구성될 수 있다는 속성이 있습니다. SBS 접근 방식의 장점은 트랜잭션 I/O 작업에 최소 잠금이 사용되므로 QFXNUMX 클러스터를 수백 개의 노드로 확장할 수 있다는 것입니다.

읽기/쓰기 최적화를 위한 핫/콜드 계층화

SBS는 읽기/쓰기 성능을 최적화하기 위해 핫 데이터와 콜드 데이터의 기본 제공 계층화를 포함합니다.

온프레미스에서 실행할 때 QF2는 솔리드 스테이트 드라이브(SSD)의 속도와 하드 디스크 드라이브(HDD)의 비용 효율성을 활용합니다. SSD는 각 노드에서 상용 HDD와 쌍을 이룹니다. 이 쌍을 가상 디스크라고 합니다. 시스템의 모든 HDD에는 가상 디스크가 있습니다.

데이터는 항상 SSD에 먼저 기록됩니다. 읽기는 일반적으로 최근에 쓴 데이터에 액세스하기 때문에 SSD는 캐시 역할도 합니다. SSD가 약 80% 차면 자주 액세스하지 않는 데이터가 HDD로 푸시됩니다. HDD는 대용량 데이터의 용량과 순차적 읽기/쓰기를 제공합니다.

클라우드에서 실행할 때 QF2는 고성능 블록 스토리지와 비용 효율적인 저성능 블록 스토리지를 일치시켜 블록 스토리지 리소스 사용을 최적화합니다.

SBS의 핫/콜드 계층화의 다음 측면을 살펴보겠습니다.

• 데이터가 기록되는 방법 및 위치
• 메타데이터가 기록되는 위치
• 데이터 만료 방법
• 데이터를 캐시하고 읽는 방법

초기 쓰기

클러스터에 쓰기 위해 클라이언트는 일부 데이터를 노드로 보냅니다. 해당 노드는 데이터가 이동할 pstore 또는 여러 pstore를 선택하고 하드웨어 측면에서 클라우드 리소스를 사용하는 경우 항상 SSD 또는 대기 시간이 짧은 블록 스토리지에 기록합니다. (SSD는 온프레미스 SSD와 퍼블릭 클라우드의 대기 시간이 짧은 블록 스토리지를 모두 의미하며 동작은 유사합니다.) 이러한 SSD는 여러 노드에 있습니다.

모든 쓰기는 SSD에서 발생합니다. SBS는 HDD에 직접 쓰지 않습니다. SSD가 가득 차더라도 시스템은 이전에 캐시된 데이터를 제거하여 새 데이터를 위한 공간을 만듭니다.

메타데이터 처리

일반적으로 메타데이터는 SSD에 유지됩니다. 데이터는 일반적으로 사용 가능한 가장 낮은 주소의 bstore에 기록되므로 데이터는 bstore의 시작 부분에서 끝까지 증가합니다. 메타데이터는 bstore의 끝에서 시작하여 시작으로 갈수록 커집니다. 이는 모든 메타데이터가 데이터의 오른쪽에 있음을 의미합니다. 다음은 bstore에서 메타데이터가 있는 위치를 보여줍니다.

QF2는 SSD에 있는 bstore의 최대 1%를 메타데이터에 할당하고 절대 만료하지 않습니다. 그 1% 중 아무것도 HDD로 가지 않습니다. 메타데이터가 1% 이상 증가하면 만료될 수 있지만 일반적인 워크로드의 경우 약 0.1%의 메타데이터가 있습니다. 공간을 채울 메타데이터가 충분하지 않으면 공간이 낭비되지 않습니다. 데이터도 그 공간을 사용할 수 있습니다.

만료되는 데이터

어느 시점에서 시스템은 SSD에 더 많은 공간이 필요하므로 일부 데이터가 만료되거나 SSD에서 HDD로 이동됩니다. 데이터가 SSD에서 HDD로 복사된 다음 HDD에 저장되면 SSD에서 삭제됩니다.

만료는 SSD가 80% 이상 차면 시작되고 다시 80% 미만으로 차면 중지됩니다. 80% 임계값은 성능을 최적화하는 휴리스틱입니다. SSD가 0%에서 80% 사이이고 만료가 동시에 발생하지 않을 때 쓰기가 더 빨라집니다.

SSD의 데이터가 HDD로 이동되면 SBS는 디스크 성능을 최적화하는 방식으로 HDD에 순차적으로 쓰기를 최적화합니다. 크고 연속적인 바이트의 버스트는 HDD에 쓸 수 있는 가장 효율적인 방법입니다.t

데이터 캐싱

다음 그림은 모든 QF2 캐시를 보여줍니다. 녹색의 모든 것은 데이터를 저장할 수 있는 장소이며 SSD 또는 HDD에 있을 수 있습니다.

QF2 I/O 작업은 세 가지 유형의 캐시를 사용합니다. 클라이언트 측에는 항상 약간의 캐시가 있으며 노드에는 두 가지 유형의 캐시가 있습니다. 하나는 클라이언트가 직접 요청하는 파일 시스템 데이터로 생각할 수 있는 트랜잭션 캐시입니다. 다른 유형은 메모리에 보관되는 해당 디스크의 블록인 디스크 캐시입니다.

예를 들어, 노드 1에 연결된 클라이언트가 파일 X 읽기를 시작한다고 가정합니다. 노드 1은 해당 블록이 노드 2에 할당되어 있음을 발견하고 노드 2에 데이터를 원한다고 알립니다. 노드 2의 SSD. 노드 2는 데이터를 읽고 이 SSD와 연결된 디스크 캐시에 넣습니다. 노드 2는 노드 1에 응답하고 데이터를 보냅니다. 이 시점에서 데이터는 파일 X에 대한 데이터가 있음을 클라이언트에 알리는 노드 1 트랜잭션 캐시로 이동합니다.

디스크가 연결된 노드는 디스크 캐시가 채워지는 위치입니다. 클라이언트가 연결된 노드는 트랜잭션 캐시가 채워지는 위치입니다. 디스크 캐시는 항상 블록을 보유하고 트랜잭션 캐시는 실제 파일의 데이터를 보유합니다. 트랜잭션 캐시와 디스크 캐시는 메모리를 공유하지만 어느 하나에 할당된 특정 양이 없습니다.

산업 표준 프로토콜

QF2는 표준 NFSv3 및 SMBv2.1 프로토콜을 사용합니다.

REST API

QF2에는 포괄적인 REST API가 포함되어 있습니다. 실제로 QF2 GUI에 표시되는 모든 정보는 QF2 REST API에 대한 호출에서 생성됩니다. GUI 내의 탭은 사용 가능한 REST API 호출의 자체 문서화 리소스를 제공합니다. 라이브 클러스터에 대한 호출을 실행하고 실시간으로 요청 및 결과를 검사하여 API를 실험할 수 있습니다. 다음은 예시 스크린샷입니다.

GUI의 분석 탭에 표시되는 모든 정보는 API에 대한 REST 호출을 사용하여 프로그래밍 방식으로 검색하고 데이터베이스에 외부적으로 저장하거나 Splunk 또는 Tableau와 같은 다른 응용 프로그램으로 보낼 수 있습니다. 대부분의 파일 시스템 작업은 REST API를 사용하여 호출할 수도 있습니다.

결론

이 백서가 QF2의 내부 작동 방식을 이해하고 QF2의 성능 및 확장성 혁신이 가능한 이유에 대한 통찰력을 제공했기를 바랍니다. 추가 정보를 원하시면 여기를 클릭해주세요..

키 포인트

다음은 이 백서에서 작성한 핵심 사항입니다.

• 데이터는 폭발적인 속도로 증가하고 있으며 최신 워크로드는 크기가 페타바이트이고 수십억 개의 파일이 있을 수 있으며 이러한 파일의 크기는 혼합되어 있습니다.
• 대부분의 스토리지 시스템은 최신 워크로드를 처리하기 위한 것이 아닌 수십 년 된 기술을 사용합니다.
• QF2는 최신 워크로드를 처리하도록 특별히 설계된 최신 스토리지 시스템입니다.
• QF2는 온프레미스 및 클라우드의 표준 하드웨어에서 실행됩니다.
• QF2에는 SSD와 HDD를 사용하는 하이브리드 아키텍처가 있습니다.
• QF2는 실제 파일 시스템 아래에서 작동하는 블록 보호 체계를 사용합니다.
• QF2는 몇 시간 단위로 재구축 시간이 빠릅니다. 그들은 업계에서 가장 빠릅니다.
• 사용자 파일은 프로비저닝된 용량의 최대 100%를 차지할 수 있습니다.
• 작은 파일은 큰 파일만큼 효율적입니다.
• 전체 파일 시스템은 단일 볼륨으로 존재합니다.
• QF2는 대규모 분산 데이터베이스에서 사용하는 것과 동일한 기술을 파일 시스템에 적용합니다.
• 실시간 분석을 통해 현재 파일 시스템에서 일어나는 일에 대한 가시성을 제공합니다.
• 사용 가능한 공간의 정확한 보고가 있습니다.
• 관리자는 실시간으로 할당량을 적용할 수 있습니다.
• 관리자는 스냅샷을 삭제하여 얼마나 많은 실제 공간을 절약하는지 알고 있습니다.
• QF2에는 대규모 비동기 데이터 복제가 포함됩니다.
• QF2는 NFS 및 SMB와 같은 표준 프로토콜을 사용하며 REST API를 포함합니다.