지구상에서 가장 인기있는 병렬 파일시스템, Lustre 파일시스템 알아보기

지난 블로그에서는 병렬 파일시스템이 무엇이고 왜 고성능 컴퓨팅 환경에서 필수적으로 사용되는지에 대해 알아보았습니다. 이번 블로그에서는 병렬 파일시스템 중, 가장 대표적인 파일시스템이라 할 수 있는 Lustre에 대해 좀 더 자세히 알아보도록 하겠습니다. Lustre는 AWS의 병렬 파일 스토리지 서비스인 Amazon FSx for Lustre의 기반이 되는 스토리지 기술입니다.

What is Lustre?

이 블로그 시리즈는 AWS의 고성능 매니지드 스토리지 서비스인 FSx for Lustre를 심층적으로 알아보기에 앞서, Lustre 파일시스템의 기본 개념과 특징을 이해하기 위한 기초 내용을 다루고 있습니다. 그렇다면 Lustre란 어떤 파일시스템인지에 대해 알아보도록 하겠습니다. 우선 Lustre는 리눅스(Linux)와 클러스터(Cluster)의 합성어를 의미합니다. Lustre는 1999년 Carnegie Mellon University의 Peter J. Braam에 의해 개발된 오픈소스 기반의 대표적인 병렬 파일시스템 입니다. 최초 개발 이후에 Sun Microsystems, Oracle, Intel 등 다양한 회사에 의해 관리되었습니다. 현재는 HPC 전문 스토리지 업체인 DDN(DataDirect Networks)이 Intel로부터 Lustre 사업부를 인수하여 Lustre 팀을 Whamcloud라는 독립 사업부로 운영하고 있습니다.

Lustre는 DDN에서 개발과 유지보수를 담당하고 있지만 GNU 버전 하에서 무료로 사용이 가능합니다. 이러한 개방적인 라이선스 정책 및 높은 고성능으로 인해 현재 기상학, 제조업, 생명과학, 미디어, 금융, 인공지능 등 다양한 분야에서 사용되고 있습니다. 특히 그림1과 같이 전세계에서 가장 성능이 좋은 Top 100 슈퍼컴퓨터에 있어, 80%에 가까운 대부분의 스토리지 솔루션으로 Lustre가 채택되고 있습니다. 이 블로그의 제목처럼, 지구상에서 가장 인기 있는 병렬 파일시스템이 바로 Lustre라고 이해하시면 좋을 것 같습니다.

<그림 1. Top100에서 사용되는 스토리지 옵션(2021년 11월 기준)>

그렇다면 왜 수많은 슈퍼컴퓨터 환경의 스토리지 시스템으로 Lustre가 채택되고 있을까요? Lustre는 다음과 같은 장점들을 가지고 있습니다.

• 확장성 및 성능
  • 수 만개의 클라이언트 노드와 수백 페타(Peta) 바이트의 스토리지를 지원하는 뛰어난 확장성을 제공합니다
  • 초당 테라(Tera) 바이트 이상의 높은 I/O 처리량을 제공합니다.
  • 파일시스템 크기에 따라 선형적으로 성능이 증가하는 스케일 아웃 구조를 가지고 있습니다.
• 유연성과 호환성
  • POSIX 표준을 준수하여 높은 호환성 및 신뢰성을 제공합니다.
  • 인피니밴드(Infiniband), 이더넷(Ethernet), 옴니패스(Omni-Path)와 같은 다양한 초고속 네트워크 환경을 지원합니다.
  • ldiskfs(ex4 수정 버전)나 ZFS와 같은 다양한 로컬 파일시스템을 지원합니다.

Lustre 아키텍처

Lustre는 클라이언트/서버 기반의 분산 병렬 파일시스템으로서, 그림2와 같은 전형적인 구조를 기반으로 구성됩니다.

<그림 2. Lustre 아키텍처>

Lustre를 구성하는 핵심 요소들은 다음과 같습니다.

• MGS(Management Server)
  • 파일시스템의 구성 정보를 제공하며, 파일시스템 변경 사항을 클라이언트에 사전에 알리는 것도 가능합니다. 클라이언트는 파일시스템을 마운트할 때 MGS에 접속하여 파일 시스템에 대한 세부 정보를 검색합니다.
• MGT(Management Target)
  • MGS가 Lustre의 구성 정보를 영구적으로 저장하는데 사용하는 블록 디바이스(스토리지) 역할을 수행합니다. 일반적으로 비교적 적은 양의 스토리지 공간(약 100MB)을 필요로 합니다.
• MDS(Metadata Server)
  • 파일시스템의 네임스페이스를 관리하고 클라이언트에 파일 이름 조회, 디렉토리 정보, 파일 레이아웃, 엑세스 권한과 같은 메타데이터 서비스를 제공합니다.
• MDT(Metadata Target)
  • MDS에서 메타데이터 정보를 저장하는데 사용되는 블록 디바이스입니다. 일반적인 구성에서는 MDS 하나당 하나의 MDT를 사용하지만, 여러 MDT를 사용할 수도 있습니다.
• OSS(Object Storage Sever)
  • 클라이언트가 데이터가 저장된 OST라고 불리우는 스토리지 볼륨에 접근할 수 있는 권한을 제공하는 서버입니다. Lustre에는 높은 데이터 저장 용량 및 높은 네트워크 대역폭을 제공하기 위해 많은 OSS 노드를 보유합니다.
• OST(Object Storage Target)
  • 사용자 데이터를 저장하기 위해 사용되는 블록 디바이스 입니다. 그림 2에는 상세히 표현되어 있지 않지만 하나의 OSS는 일반적으로 여러 개의 OST를 호스팅 합니다. 파일시스템의 총 용량은 개별 OST의 총 용량의 합계입니다.
• Lustre 클라이언트
  • Lustre 파일시스템을 마운트 하는 주체입니다. HPC 환경이라면 클러스터를 구성하며 연산을 담당하는 워커(worker) 노드가 그 대상이 됩니다. 단일 Lustre 파일시스템에 접근하는 클라이언트는 수 천 또는 수 만개 이상이 될 수 있습니다. 또한 각 클라이언트는 한 번에 두 개 이상의 Lustre 파일시스템에 마운트 하는 것도 가능합니다.
• LNet(Lustre Networking)
  • 클라이언트와 서버 간에 통신을 담당하는 네트워크 프로토콜을 의미합니다. 그림2에는 표시되어 있지 않지만, Lustre 파일시스템은 매니지먼트 및 데이터 트래픽 전송을 위한 별도의 네트워크 인터페이스로 구성됩니다. 그림2에서 표시된 인피니밴드 또는 기가비트 이더넷 등은 데이터 네트워크에 해당되며, 그림에서는 표기가 되어 있지 않지만 관리용 네트워크용으로는 일반적인 이더넷 기반의 네트워크가 사용됩니다.

또한 Lustre 파일시스템은 다음과 같은 특징을 가지고 있습니다.

• Lustre에서는 MGS, MDS 및 OSS 노드와 같은 서버들을 프런트엔드(frontend)라고 부르며, OST 및 MDT 들이 파일을 저장하기 위해 사용하는 ldiskfs나 ZFS와 같은 로컬 파일시스템을 백엔드 파일시스템이라 부르기도 합니다.
• 참고로 Lustre는 오브젝트(object) 기반의 파일시스템입니다. 여기서 오브젝트란 파일 데이터를 저장하는 기본 단위로서 별도의 OST에 저장됩니다. OSS에서 데이터를 관리하는 기본 단위이기도 합니다.
• Lustre는 그림2와 같이 기본적으로 메타데이터(inode) 스토리지와 실제 사용자 데이터를 저장하는 블록 데이터 스토리지를 분리한 구성을 보유하고 있습니다. 따라서 메타데이터 작업과 데이터 I/O가 서로 영향을 미치지 않게 되어 전체적인 시스템 성능 향상이 가능합니다.
• 소규모의 파일시스템에서는 그림 2와는 달리, MGS와 MDS를 단일 서버로 구현하는 경우도 있으며 스토리지 관점에서 MGT는 MDT와 동일한 블록 디바이스에 구현할 수도 있습니다.
• 블록 디바이스는 MDS 또는 OSS 노드에 연결된 스토리지 장치를 의미하며, 이는 SAS, FC(Fibre Channel), iSCSI와 같은 기술을 통해 직접 연결되거나 SAN(Storage Area Network) 기술을 이용해 구성됩니다. 이러한 연결 방식은 Lustre의 클라이언트/서버 구조와는 독립적으로 동작합니다.

Lustre의 파일 레이아웃(layout)

Lustre는 단일 파일을 청크(chunk)라는 작은 단위로 분할한 다음 여러 개의 OST에 저장하게 됩니다. 이렇게 하나의 대용량 파일을 여러 개의 OST에 분산 저장 함으로써 RAID0와 동일한 효과를 얻게 됩니다. 따라서 스토리지 I/O에 있어서 높은 성능을 보장할 수 있습니다.

Lustre의 일반적인 스트라이프 레이아웃(layout)은 스트라이프 카운트와 사이즈에 의해 결정되며, 이를 통해 오브젝트를 여러 OST(Object Storage Target)에 분산하는 방법을 설정합니다. 스트라이프 카운트는 저장에 사용되는 OST의 개수를 결정하며, 스트라이프의 사이즈는 각 OST에 기록되는 데이터의 양을 결정합니다. 여기서 오브젝트와 스트라이프라는 용어에 대해 혼란을 겪을 수 있습니다. 오브젝트는 파일의 데이터를 실제로 저장하는 기본 단위로, OST에 물리적으로 저장됩니다. 반면, 스트라이프는 대용량 파일을 여러 개의 오브젝트로 나누어 저장하는 방식을 의미합니다. 이러한 스트라이핑을 통해 파일의 I/O 성능을 향상시킬 수 있습니다. 스트라이프 카운트와 스트라이프 사이즈를 조절함으로써 I/O 특성을 최적화할 수 있으며, 이 두 가지 요소가 함께 사용되어 고성능 분산 저장 시스템을 구현하는 데 중요한 역할을 합니다. Lustre 파일시스템에서는 이러한 설정을 통해 대량의 데이터를 효율적으로 처리하고, 성능 병목 현상을 줄일 수 있습니다.

그림3은 3개의 OST로 구성된 간단한 Lustre 파일시스템을 나타냅니다. 여기서 스트라이프 사이즈는 1MB로 가정하겠습니다. 이 때 파일A는 그림에서 볼 수 있듯이 3개의 OST에 분산 저장되어 있기 때문에

스트라이프 카운트는 3이 됩니다. 따라서 이 파일시스템에 존재하는 모든 OST를 사용하게 됩니다. 데이터 청크는 라운드 로빈(round-robin) 알고리즘을 이용하여 저장되며, 따라서 네번째 데이터 청크는 OST0에 저장되게 됩니다. 이러한 방식을 통해 OST0에는 3개의 데이터 청크 (#1,4,7)가 저장되어 있으며 이러한 데이터 청크는 모두 단일 오브젝트에 존재하게 됩니다. Lustre 파일 시스템의 관점에서 본다면 파일 A는 3개의 오브젝트로 구성됩니다.

<그림 3. Lustre의 파일 레이아웃>

그림3 에서 파일 B와 C는 Lustre의 기본 스트라이프 카운트인 1을 보유하고 있습니다. 즉, 여러 OST에 걸쳐 파일을 분산 저장하지 않겠다는 의미입니다. 단 파일 B만 기본 스트라이프 사이즈인 1MB를 유지하고 있으며, 파일 C의 경우 2MB의 스트라이프 사이즈를 가지도록 설정되었습니다. 사용자는 ‘lfs setstripe’ 명령을 사용하여 파일 레이아웃의 여러 측면을 제어할 수 있으며 ‘lfs getstripe’ 명령을 사용하여 기존 파일의 레이아웃을 쿼리할 수 있습니다.

Lustre에서의 파일 쓰기 및 읽기 작업(동작 방식)

Lustre에서의 파일 쓰기 및 읽기 메커니즘은 다음과 같습니다.

• 쓰기 동작
  • 클라이언트가 MDS에 파일 쓰기 권한을 요청합니다.
  • MDS는 접근 권한, 파일 속성 등을 확인하고 사용할 OST 목록을 반환합니다.
    • 그림4에서 표기되어 있는 EA는 (Extended Attribute)를 의미하며, Lustre에서 메타 데이터 관리를 위한 중요한 요소입니다.
    • 이것은 클라이언트가 파일 데이터의 실제 저장 위치를 찾을 수 있도록 OST 목록과 실제 파일 데이터를 보유하는 OST 객체의 FID(File Identifier)를 포함하는 일종의 맵(map) 역할을 수행합니다.
  • 클라이언트는 각 OST와 직접 통신하며 데이터를 병렬로 쓰기 작업을 수행합니다.
  • 파일 크기와 관계없이(KB에서 TB까지) MDS의 추가 개입 없이 전체 파일이 쓰여질 때까지 작업이 계속됩니다.
• 읽기 동작
  • 기본적으로 쓰기 동작과 매우 유사합니다.
  • 클라이언트가 MDS에 파일 읽기 권한을 요청합니다.
  • MDS는 접근 권한을 확인하고 파일의 각 스트라이프가 위치한 OST 목록을 반환합니다.
  • 클라이언트는 해당 OST들과 직접 통신하여 데이터를 읽습니다.

이 때 여러 클라이언트가 동시에 같은 파일 영역에 접근할 경우, Lustre 분산 잠금(lock) 관리자가 일관성을 보장합니다. 이러한 동시성 제어를 통해 모든 I/O 요청은 충돌 방지를 위해 순차적으로 실행됩니다.

<그림 4. Lustre의 동작 원리>

Lustre의 한계점

지금까지 대표적인 병렬 파일시스템인 Lustre 파일시스템의 장점에 대해 설명하였습니다. Lustre시스템을 고성능 컴퓨팅 환경에서 적용한다면, 스토리지 관련된 모든 문제들이 손쉽게 해결될 것 같다는 착각을 갖게 합니다. 그러나 모든 제품에는 장점과 단점이 동시에 존재하듯이, Luste 파일시스템 역시 아래와 같은 몇 가지 한계점들을 내포하고 있습니다.

Lustre는 대용량 데이터의 고속 처리를 위한 고성능 분산 파일시스템이지만, 몇 가지 중요한 제약사항이 있습니다. 우선 파일 데이터의 복제 기능은 기본적으로 제공하지 않으며, 이는 File Level Redundancy(FLR) 기능을 통해 별도로 구현해야 합니다. 또한 고가용성 구성을 위해서는 별도의 HA 소프트웨어 설치가 필요하며, 대규모 시스템에서 메타데이터 관리의 복잡성이 증가하는 특징이 있습니다. 따라서 스토리지 구성에 있어서는 특별한 주의가 필요합니다. 만약 디스크 레벨의 OST/MDT 등에 문제가 발생할 경우에는 RAID 기술을 적용하여 가용성을 확보합니다. MDT의 경우 메타데이터의 중요성을 고려하여 RAID-1 또는 RAID-10 구성이 필수적이며, OST의 경우 대용량 디스크 사용시 데이터 보호를 위해 RAID-6 구성이 권장됩니다.

Lustre 시스템을 운영 및 유지보수 하는 것은 매우 어렵습니다. 이미 앞서 언급한 것처럼 Lustre 시스템은 데이터를 처리하는 OSS/OST 이외에 메타데이터 서버를 위한 MDS/MDT 등의 여러 컴포넌트들로 구성되어 있습니다. 또한 각 컴포넌트간 상호 의존성 및 복잡한 동작 메커니즘, 네트워크를 포함한 높은 하드웨어에 대한 요구 사항 등으로 인하여 운영에 대한 전문 인력 확보는 필수입니다. 그러나 주로 HPC 용도로 사용되는 기술적 제약성 및 높은 진입 장벽으로 인해, 현재 국내에서 Lustre 관련 전문 인력을 기업에서 확보하는 것은 현실적으로 매우 어려운 일입니다.

Lustre는 대용량 파일을 스트라이핑 시켜 병렬 I/O를 발생시키는데 특화되어 있지만, 다수의 작은 파일(4KB 이하) 을 처리하는데 적합하지 않습니다. MDS가 이러한 파일들을 처리하면서 성능 병목이 발생할 수 있습니다. 따라서 EDA와 같이 다수의 저용량 파일이 발생되는 환경에서는 NetApp ONTAP과 같은 스토리지가 더 나은 선택이 될 수 있습니다. NetApp ONTAP은 파일 크기에 관계없이 일관된 성능을 제공합니다. 참고로 AWS에서는 2021년 9월에 완전관리형 ONTAP 파일시스템인 Amazon FSx for NetApp ONTAP을 출시하였습니다.

이외에 시스템 관점에서는 다음과 같은 제약사항이 존재합니다.

• 플랫폼 제약 : 기본적으로 클라이언트 및 서버의 운영체제가 리눅스 기반 운영체제만을 지원합니다. Windows, macOS 등의 타 플랫폼은 지원하지 않습니다.
• 시스템 제약 : 파일 시스템 크기는, 이론상으로는 16EB까지 확장가능 하나, 실제 운영 환경에서 700PB까지 검증되었습니다. 파일 크기는 ldiskfs(ext4) 기준 최대 32PB, ZFS 기준 최대 16EB입니다.
• 메타데이터 제약 : 하나의 MDT가 저장할 수 있는 최대 파일(inode) 개수는 ldiskfs 백엔드 기준으로 최대 40억개 까지 이며, ZFS 백엔드 기준으로는 최대 256조개 까지 입니다.

맺음말

이 블로그에서는 AWS의 완전 관리형 병렬 스토리지 서비스인 Amazon FSx for Lustre의 원형인 Lustre 파일 시스템에 대해 알아보았습니다. Lustre는 Top 100의 대부분 시스템에 스토리지 솔루션으로 채택될 정도로 뛰어난 성능을 제공하지만, 기술의 복잡성으로 인해 온프레미스 환경에서의 구축과 운영에는 상당한 전문성과 리소스가 요구됩니다. 또한, 성능에 모든 초점이 맞춰져 있기 때문에 기본적으로 제공해야 하는 여러 기능들을 충분히 지원하지 못하는 한계가 존재합니다.

이러한 여러 한계점을 극복하기 위해 AWS는 2018년 12월에 CSP(Cloud Service Provider) 업계 최초로 완전 관리형 병렬 파일시스템인 Amazon FSx for Lustre를 시장에 출시하였습니다. Amazon FSx for Lustre는 사용자가 복잡한 설정 없이도 고성능 스토리지를 손쉽게 사용할 수 있도록 설계되었으며, 다양한 워크로드에서 효율적으로 데이터를 처리할 수 있는 기능을 제공합니다.

다음 블로그 시리즈 부터는 Amazon FSx for Lustre에 대해 본격적으로 알아보도록 하겠습니다.