회복탄력성과 데이터 무결성을 유지하면서 데이터를 빠르고 일관되게 쓰는 것은 쉬운 일이 아닙니다. vSAN과 같은 엔터프라이즈 스토리지 솔루션은 까다로운 워크로드 및 다양한 운영 조건에서도 이러한 요구 사항을 충족하도록 설계되었습니다. 하지만 데이터를 쓰는 것은 스토리지 시스템의 한 가지 책임일 뿐입니다. 데이터를 읽을 위치를 파악하고 요청된 데이터를 일관되고 정확하게 검색해야 합니다. 데이터 용량이 엄청난 수준으로 증가함에 따라 이는 생각보다 어려운 과제입니다.
vSAN의 ESA(Express Storage Architecture)는 최고 수준의 성능과 효율성을 갖춘 새로운 데이터 처리 및 저장 방식을 도입했습니다. 새로운 데이터 경로와 기본 데이터 구조는 I/O 증폭 및 계산 노력을 최소화하는 고도로 최적화된 방식으로 데이터를 기록함으로써 이를 달성합니다. 또한 가장 효율적인 방식으로 최신 NVMe 플래시 장치에 데이터를 쓰도록 설계되어 가비지 수집 작업을 최소화하고 내구성을 연장합니다. 그러나 대량의 데이터를 효율적으로 저장할 수 있다는 것은 데이터를 빠르고 효율적으로 읽을 수 있어야 한다는 의미이기도 합니다. vSAN의 ESA가 데이터를 읽는 방법을 자세히 살펴보겠습니다.
ESA의 데이터 스토리지
vSAN의 Original Storage Architecture(OSA)와 마찬가지로 ESA는 VMFS와 같은 클러스터된 파일 시스템을 사용하는 데이터스토어와 같은 전체 볼륨이 아닌 VMDK와 같은 객체가 데이터의 논리적 경계인 오브젝트 스토어와 유사한 방식으로 데이터를 저장합니다. 다시 살펴보려면 “vSAN Objects and Components Revisited” 게시물을 참조하십시오. 또한 두 아키텍처는 오브젝트 및 구성 요소 배치, 오브젝트 데이터에 대한 데이터 경로, 호스트 멤버십 등을 결정하는 데 도움이 되는 vSAN 스토리지 스택에서 동일한 계층을 많이 공유합니다.
그러나 데이터 경로와 vSAN ESA의 메타데이터 처리 방식은 OSA와 상당히 다르며, 이는 ESA가 데이터를 빠르고 효율적으로 쓸 수 있을 뿐만 아니라 데이터를 효율적으로 읽을 수 있는 기능을 제공합니다. vSAN ESA의 특허받은 log-structured filesystem(vSAN LFS)과 ESA의 대폭 수정된 log-structured object manager(LSOM)는 ESA의 인상적인 성능, 데이터 효율성 및 스냅샷 기능의 배경이 되는 요소입니다. 두 vSAN 계층 모두 자체 메타데이터를 생성하고 관리하여 검색해야 하는 항목과 위치를 결정하는 데 도움을 줍니다. 이 게시물의 초점은 vSAN LFS의 메타데이터가 게스트 VM 읽기 작업에 어떻게 도움이 되는지입니다.
ESA의 메타데이터 스토리지
메타데이터 또는 “데이터에 대한 데이터”는 스토리지 시스템이 요청된 데이터를 어디에서 가져올지 알 수 있도록 하는 것입니다. 스토리지 시스템 용량이 엄청난 수준으로 증가함에 따라 확장성을 고려하여 설계되지 않은 경우 메타데이터가 스토리지 시스템에 부담을 줄 수 있습니다. 이로 인해 CPU, 메모리, 스토리지 리소스가 과도하게 소모될 뿐만 아니라 성능 저하로 이어질 수 있습니다.
ESA는 메타데이터 관리에 매우 효율적이고 확장 가능한 접근 방식을 사용합니다. vSAN이 데이터를 효율적으로 참조할 수 있도록 매핑을 제공하는 B+ 트리라고 하는 여러 데이터 트리 구조를 사용합니다. 이 트리는 각 메타데이터를 보관하는 인덱스 페이지와 리프 페이지로 구성됩니다. 그러나 현재와 앞으로의 디바이스 용량을 고려할 때 이 메타데이터는 상당히 커질 수 있습니다. 그림 1에서 볼 수 있듯이 ESA는 일부 페이지는 메모리에 보관하고 다른 페이지는 오브젝트의 성능 레그 구성 요소 또는 오브젝트의 용량 레그 구성 요소에 압축된 형태로 저장하는 확장성이 뛰어난 접근 방식을 사용합니다. vSAN은 LFS 오버헤드 계산에서 이러한 메타데이터 스토리지를 설명합니다. ESA의 용량 오버헤드에 대한 자세한 내용은 “Capacity Overheads for the ESA in vSAN 8” 게시물을 참조하십시오.
ESA는 활발하게 액세스되는 데이터 블록(“working set”라고 함)을 가리키는 객체의 메타데이터를 가능한 한 많이 메모리에 유지하려고 노력합니다. 이렇게 메모리에 메타데이터를 캐싱하면 디스크에서 이러한 페이지를 검색하는 데 추가적인 노력을 들이지 않고도 자주 액세스하는 B-Tree 인덱스 및 리프 페이지를 메모리에서 빠르게 참조할 수 있습니다. 이렇게 하면 B+ 트리 페이지를 메모리에서 쉽게 사용할 수 있으므로 작업 세트에 액세스하는 성능이 향상됩니다.
ESA의 읽기 작업
ESA에서 데이터를 검색하는 방법을 살펴보겠습니다. 아래 예제에서는 가상 머신이 RAID-6 삭제 코딩을 사용하여 장애 허용 범위가 2(FTT=2)인 vSAN 스토리지 정책을 사용한다고 가정합니다. 즉, 패리티가 있는 데이터가 최소 6개의 호스트에 분산되어 있습니다. 또한 I/O가 정렬되어 있고 체크섬 검증 및 데이터 압축이 ESA에서 기본적으로 활성화되어 있으므로 활성화되어 있다고 가정합니다.
다음은 vSAN ESA에서 읽기 작업의 흐름에 대해 설명합니다.
- VM의 게스트 OS가 읽기 요청을 발행하고 ESXi의 vSCSI 스택을 통해 해당 요청을 VM의 DOM(Distributed Object Manager) 클라이언트로 전달합니다.
- DOM 클라이언트는 DOM 클라이언트 캐시에서 최근에 사용된 블록이 있는지 확인하고 사용 가능한 블록이 캐시에 있는 경우 읽기 작업을 수행합니다. 그렇지 않으면 다음 단계로 진행합니다.
- 오브젝트의 DOM 소유자(클라이언트가 소유자에 대한 연결을 열 때 결정됨)가 추가 단계를 수행합니다:
- 뱅크라고도 하는 객체의 LFS 인메모리 스트라이프 버퍼가 요청된 데이터 페이로드를 보유하고 있는지 확인합니다. 그렇지 않은 경우 다음 단계로 진행합니다.
- 메타데이터 조회를 수행하여 요청된 데이터 페이로드의 물리적 주소 컬렉션(‘배열’이라고 함)을 구축합니다. 이 메타데이터는 B+ 트리라고 하는 메타데이터 트리 구조의 메모리 또는 디스크에 존재합니다.
- 조회에서 참조된 요청된 데이터 페이로드의 일부에 대해 다중 읽기 작업이 실행됩니다.
- 다중 읽기 작업은 데이터 페이로드를 DOM 클라이언트로 반환하며, 여기서 체크섬이 확인되고 데이터가 압축 해제됩니다.
- 데이터는 DOM 클라이언트에서 vSCSI 스택을 통해 VM의 게스트 OS로 수신됩니다.
위 그림에 표시된 내구성 로그와 메타데이터 로그는 읽기 작업에서 어떤 역할을 하나요? 위 단계에 설명된 대로, 그렇지 않습니다. 이러한 로그는 호스트 장애 발생 시 메타데이터를 재구성할 수 있도록 메타데이터가 처음 생성될 때 디스크에 보존하는 데만 사용됩니다. 메타데이터는 처음에 이러한 로그에서 디스크에 보존되지만, 메모리에서 디스크의 B+ 트리로 기록되기 전에 가능한 한 오랫동안 메모리에 보관됩니다. 따라서 B+ 트리 업데이트 작업이 매우 효율적입니다.
요약
업계가 초대용량 스토리지 디바이스로 전환함에 따라 스토리지 시스템의 과제는 데이터 저장량이 아니라 빠르고 효율적인 데이터 검색을 지원하는 메타데이터 구조의 설계입니다. vSAN의 Express 스토리지 아키텍처는 이러한 점을 염두에 두고 설계되었으며 유연성, 확장성, 특별함을 제공하는 데 도움이 됩니다.
