Journal Archive

Lustre에서 데이터의 메타 정보는 중앙화된 메타데이터 서버(MDS: MetaData Server)를 통해 관리된다. DNE는 분산 파일 시스템에서 파일 및 디렉터리의 이름 공간을 관리하는 기술로 그림 2와 같이 복수 개의 MDS를 설정할 수 있으며 Lustre 파일 시스템에서는 DNE를 통해 파일과 디렉터리의 이름 공간을 각각 관리한다. 복수 개의 MDS를 사용하는 Lustre 파일 시스템에서는 다양한 이점을 갖는다. 첫째, 분산된 메타데이터는 파일 시스템의 확장성을 향상시킨다. 여러 MDS가 동시에 작업을 처리하므로 시스템의 처리량(IOPS)이 증가하고 병목 현상이 감소한다. 둘째, 복제된 메타데이터를 통해 고가용성(HA: High Availability)을 제공한다. 하나의 MDS가 고장 나더라도 다른 MDS가 해당파일 및 디렉터리의 메타데이터를 처리할 수 있어 시스템의 가용성을 보장할 수 있다. 셋째, 복수 개의 MDS는 메타데이터의 부하를 분산시켜 시스템의 성능을 향상시킨다. 복수 개의 MDS를 사용하는 경우 메타데이터 정보를 동기화하는 메커니즘이 필요하다. 이를 위해 Lustre는 메타데이터 간 동기화를 위한 특정 프로토콜과 알고리즘을 사용하여 MDS 간에 메타데이터 변경 사항을 상호 동기화하여 일관성을 유지한다.

Fig 2. 
Lustre overview

Lustre 파일시스템은 스트라이핑(Striping)을 통해 하나의 파일을 물리적으로 분산된 여러 디스크(OST: Object Storage Target)에 분할하여 저장함으로써 병목 현상을 제거 하고 I/O 성능 향상시킬 수 있다. PFL은 기존에 파일을 고정으로 분할하여 저장하는 방식이 아니라 파일의 크기에 따라 복합 레이아웃을 설정하여 동적으로 분할 개수(Stripe count)와 크기(Stripe size)를 조정한다.

DoM은 Lustre에서 OST에 분산된 작은 파일 검색 및 무작위 I/O(Small random file I/O)의 부하를 개선하기 위한 기법이다. 작은 파일은 MDT에 직접 배치함으로써 실제 OST에 발생하는 부하를 줄여 전체 파일시스템의 성능향상을 가져온다. 위에 언급한 PFL의 복합 레이아웃 설정을 통해 MDT 블록 영역을 지정하고 파일의 크기를 설정하면 해당되는 작은 파일은 MDT에 직접 저장된다. 나머지 크기의 파일들은 PFL에서 지정한 레이아웃에 맞게 OST에 저장된다. 이로써 작은 파일에 대해 더 빠르게 액세스가 가능하다[12]. 그림 3은 Lustre DoM 설정을 보여주는 그림으로 레이아웃의 첫 번째 컴포넌트인 MDT 영역에는 1M 이하 사이즈의 작은 데이터가 저장되며 나머지 파일 크기의 데이터는 OST 영역에 저장된다.

Fig. 3. 
DoM file layout

IOR은 병렬 파일 시스템의 성능을 측정하는 벤치마크 도구로 POSIX, MPIIO, HDF5와 같은 다양한 인터페이스와 액세스 패턴을 이용하여 스토리지의 대역폭, 지연, I/O 처리량 등을 측정할 수 있다. MPI 라이브러리를 사용 병렬 파일 I/O를 수행하여 여러 노드 또는 프로세서에서 동시에 파일을 읽고 쓸 수 있다. MPI(Message Passing Interface)는 병렬 컴퓨팅에서 메시지 패싱을 지원하기 위한 표준 프로토콜 및 라이브러리이다[13]. 테스트는 각 프로세스가 단일파일을 생성(Single-Shared File)하거나 또는 각 프로세스마다 각각 파일을 생성하는 방식(File per Process)으로 수행된다[14].

MDTEST는 MPI를 활용하여 메타데이터의 성능을 측정하는 도구로 파일시스템 Open/Stat/Close 동작을 측정하게 된다[8]. HPC 환경에서는 대량의 계산노드들이 공용의 파일시스템을 마운트 하여 사용하게 된다. 여러 사용자들이 동시에 공유 파일시스템에 접속해서 파일들을 생성하고 삭제하는 오퍼레이션을 수행하게 되는데, 이에 대해 파일시스템의 성능부하를 사전에 테스트할 수 있다. 빌드를 위해서 C 컴파일러와 MPI 라이브러리가 필요하며, 실행 시에는 프로세스에서 실행될 파일의 개수, 공용 또는 개별 디렉터리 선택, 테스트 수행 옵션(Creat, Stat, Remove)을 설정해서 각각의 메타데이터 성능을 검증한다.

위와 같은 벤치마크 수행을 통해 사용자 애플리케이션 특성에 따라 요구되는 I/O 워크로드를 측정할 수 있으며 최적의 작업수행 환경을 설계할 수 있다[15].

DNE를 테스트를 위해 복수 개의 MDS가 필요하다. 이를 위해 기존 MDS에 메타데이터 정보가 저장되는 단일 Metadata Target (MDT)를 벡업 후 두 개의 볼륨으로 나누어 복수 개의 MDT로 그림 5와 같이 구성하였다. Lustre 2.x 버전에서는 최대 256개의 분산 메타데이터를 구성할 수 있다. 하지만 분산 메타데이터의 개수가 많아질수록 항상 성능이 향상되지 않는다. 메타 정보가 여러 곳에 분산될 경우 파일의 정보를 찾아야 하므로 메타데이터 부하가 증가할 수 있기 때문이다. 따라서 스토리지 용량과 파일의 크기에 따라 분산 메타데이터의 설정을 결정해야 한다.

Fig. 5. 
Data striping by DNE and DoM configuration

HW 구성 후 Lustre 파일시스템은 DNE를 표 1과 같이 각 디렉터리에 대해 분산 메타데이터 개수를 설정할 수 있다. 두 개의 디렉터리를 생성한 후 하나의 디렉터리는 단일 메타데이터를 또 하나의 디렉터리는 복수 개로 구성하여 대역폭과 메타데이터 성능을 비교하였다.

표 2와 같이 MPI를 이용하여 각 프로세스마다 2GB 파일을 생성하는 IOR과 표 3의 명령어를 통해 1,000개의 파일을 생성하여 메타데이터 성능을 측정하는 MDTEST 벤치마크를 수행하였다. 그림 6과 7에서 보듯이 단일 MDT에 비하여 대역폭(MiB/s)과 메타데이터(IOPS) 성능이 향상됨을 확인할 수 있다.

Fig. 6. 
Bandwidth scaling performance according to DNE

Fig. 7. 
IOPS scaling performance according to DNE

그림 8과 9는 1∼4노드(16~64ppn)로 확장하면서 단일 파일을 생성(Single-Shared File)하는 성능 시험을 PFL이 미적용(no_PFL)된 디렉터리와 설정 된 디렉터리에서 각각 수행하였다. 표 4는 PFL에 적용된 분할(striping) 설정이며 여기에서 보듯이 4M부터 파일 사이즈에 따라 2배씩 분할 수를 증가시켰다. PFL 설정으로 분할 개수(Stripe count)가 많아져 데이터가 여러 저장소에 있는 경우 Read 성능에서 각 파일의 인덱스 정보를 수집하는 부하가 더 발생할 수 있다. 따라서 스토리지의 규모와 클라이언트의 수에 따라 적절한 분할 개수를 설정해야 한다.

Fig. 8. 
Read performance benchmark according to PFL

Fig. 9. 
Write performance benchmark according to PFL

Lustre는 상대적으로 작은 파일의 I/O 처리 성능에 취약하다. DoM은 메타데이터에 작은 파일을 직접 저장하여 I/O 성능을 향상시킬 수 있는 기법이다. 표 5와 같이 메타데이터 타깃(MDT)과 파일사이즈를 지정하여 DoM을 설정한다.

표 6은 DoM 성능 측정을 위한 IOR 벤치마크 명령어로 표 5의 설정에서와 같이 data_dom 디렉터리에 사이즈가 64KB이하의 파일들은 메타데이터에 저장되어 I/O가 발생한다. 그림 10의 실험은 블록사이즈 1KB와 1,000KB 사이즈의 파일들을 64개의 프로세서에서 생성하여 수행한다. 상대적으로 작은 블록사이즈(1KB)의 파일들이 많은 경우 메타데이터에서 처리되어 더 높은 성능을 얻게 된다.

Fig. 10. 
Bandwidth performance comparison according to DoM configuration

계층형 스토리지는 저장 매체에 따라 저장소를 분류하고 각 계층에 대한 액세스 패턴과 요구 사항에 따라 데이터를 배치하여 비용 효율적인 방식으로 파일을 관리한다. Hot/Cool 영역은 각 저장소 계층을 이르며 Hot 영역에는 빠른 응답 시간과 고성능의 대역폭을 제공하는 NVMe SSD와 같은 매체를 사용하여 빈번하게 액세스되거나 작은 용량의 데이터를 저장한다. 하지만 높은 매체 비용으로 잦은 I/O가 발생하는 데이터를 대상으로 저장하며 일정 기간 동안 액세스가 발생하지 않으면 비용이 낮은 Cool 영역에 데이터를 복사 후 공간을 다시 확보하게 된다. Cool 영역은 상대적으로 액세스 빈도가 낮은 데이터를 저장하게 되며 보관 기간이 더 길고 데이터 액세스가 더 느릴 수 있지만, 비용이 상대적으로 낮다. 일반적으로 저장소 비용을 절감하면서 데이터를 안전하게 보관하는 데 사용된다.

본 실험을 위해 슈퍼컴퓨터 5호기 누리온 Burst Buffer의 NVMe SSD를 장착 노드를 Hot 영역으로 기존 NSAS 기반의 디스크는 Cool 영역으로 그림 11과 같이 계층형 스토리지를 재구성하였다.

Fig. 11. 
Tiered storage configuration using Nurion burst buffer

Hot/Cool 영역의 자동화된 데이터 관리(Automated Storage Tiering)를 위해 DDN의 Lustre 어플라이언스로 제공되는 EXAScaler 소프트웨어를 설치하였다. 계층형 스토리지 간의 자동 적재를 위해 EXAScaler에서는 Hot에서 Cool 영역으로 데이터를 미러링하는 과정과 조건에 따라 Hot 영역에 용량 조건에 따라 퍼지하는 기능을 가지고 있다. 표 7과 같이 파일의 사이즈 범위에 따라 지정된 영역에 저장되며 플래그 옵션을 통해 Hot 영역에 저장된 데이터는 동일하게 Cool 영역으로 미러링 되고 일정시간이 지나면 Hot 영역에서 제거된다. 읽기시에는 Hot 영역에 데이터가 있는 경우 바로 가져오지만 제거된 파일의 경우 Cool 영역에서 데이터를 가져오고 Hot 영역으로 다시 적재시킨다. 그림 12는 Hot/Cool 영역의 데이터 관리 흐름을 보여주며 Hot 영역에 저장된 데이터는 Cool 영역에 동일하게 미러링 및 동기화가 발생하며 일정 시간동안 사용되지 않으면 Hot 영역에서 제거된다. 이 후 해당 파일이 다시 사용되면 Hot 영역에 자동으로 적재(staging) 되어 해당 영역에서 I/O가 발생한다.

Fig. 12. 
Tiered storage configuration using Nurion burst buffer

그림 13은 Hot/Cool 영역에서 모든 프로세서가 단일파일을 생성(SSF, Single-Shared File)하거나 또는 각 프로세서가 각각 파일을 생성(FPP, File per Process)하는 방식에서 읽기 성능을 네 가지 방식으로 측정하였다. 첫 번째와 두 번째는 Hot/Cool 각 영역에서의 읽기 대역폭의 차이를 보여준다. 세 번째는 플래시기반의 NVMe SSD로 구성된 Hot 영역과 N-SAS 기반의 Cool 영역으로 구성된 자동 적재 환경에서 발생하는 I/O 패턴에 따라 일정 시간 후 Hot 영역에 데이터가 제거되었을 때의 성능을 보여준다. 이 경우(Clear Hot-Pool)는 Cool 영역과 동일 성능을 보이며, 이후 다시 데이터를 읽을 때는 Hot 영역으로 데이터가 자동 적재되어 되어 네 번째 Hot Pool (Auto Staging)과 같이 Hot 영역에서 읽기를 성능을 보이게 된다. 즉, Hot 영역에서 제거된 데이터를 다시 읽을 때는 처음 Cool 영역에서 가져온 후 Hot 영역으로 적재된다.

Fig. 13. 
SSF, FFP read performance with Hot/Cool and staging In/Out