NVMe SSD 기반 캐시를 통한 병렬파일시스템 특징 및 성능 분석

Ⅰ. 서 론

최근 HPC 스토리지의 대역폭은 500GB/s이상 까지 달하며 조만간 TB/s 단위 규모의 대역폭을 갖는 고성능 스토리지가 주류를 이룰 것으로 본다[1]. 계산노드 또한 수천 대에서 수만 대의 규모로 증가할 것 이며 단일노드의 성능 또한 급격히 증가할 것으로 예측된다. 현재 세계 1위 슈퍼컴퓨터(2019년 06월 기준)인 오크리지 국립연구소(ORNL)에 Summit 시스템은 이론 성능 200PFlops의 계산 능력을 지닌 IBM AC922 시스템으로, Oak Ridge Leadership Computing Facility(OLCF)에 설치되어 있다. 이런 추세라면 2020년 정도에는 슈퍼컴퓨터 연산 능력이 ExaFlops에 다다를 것으로 예측한다[2]. 이런 대규모의 슈퍼컴퓨터에서 다양한 애플리케이션이 수행되고 있으며 계산노드의 연산능력 뿐만 아니라 고성능 스토리지의 I/O 성능이 동시에 지원되어야 최적의 성능을 얻을 수 있다. 통계에 의하면 HPC 애플리케이션의 데이터 90 %의 크기가 32KB 미만으로 보고되었다[3]. 대규모의 HPC 시스템에서 주로 사용하고 있는 병렬파일시스템(Parallel File System) 소프트웨어로는 대표적으로 Lustre, GPFS 등이 있으나 KByte 수준의 작은 파일에 대한 I/O 또는 랜덤 I/O에 상대적으로 취약하다.

이를 해결하기 위해 스토리지와 계산노드 사이에 SSD(Solid-State Disk) 기반의 새로운 고속 데이터 스토리지 계층을 제공함으로써 병렬파일시스템의 캐시역할을 수행하게 하는데 이 기술을 버스트 버퍼(Burst Buffer)라 불리기도 한다[4]. 아래 그림은 Argonne 연구소에 설치된 DDN 솔루션으로 계산노드(Compute nodes)와 스토리지(Enterprise storage) 사이에서 발생할 수 있는 고대역폭의 부하를 SSD 기반의 IO 노드를 구축하여 분산시키는 역할을 수행한다. (그림 1)은 Argonne의 IBM Blue Geen/P 시스템에서 계산노드와 스토리지 사이에 SSD 기반 고속의 디스크를 이용한 I/O 캐시 노드를 배치한 시스템 아키텍처이다. 이로써 기존처럼 병렬파일시스템의 최종 위치에 데이터가 이동할 때 까지 기다리지 않고 고속의 캐시의 메모리에 데이터를 배치하고 다음 계산을 수행할 수 있다[5].

Fig. 1.

Distributed Environment with I / O layer between Compute node and Storage on Argonne IBM Blue Geen/P System

일반적으로 병렬파일시스템의 경우 일정 프로세스의 수에 다다를시 성능이 포화되어 일정한 수준으로 수렴하게 되나 SSD 기반 캐시의 경우 선형으로 일정하게 증가됨을 볼 수 있다[5]. (그림 2)은 IBM Blue Geen/P 시스템에서 병렬파일시스템과 SSD 기반의 캐시를 사용할 때의 I/O 성능을 클라이언트의 수, 즉 프로세스 수를 증가시키면서 확장성 테스트를 수행한 결과이다. 실험의 결과는 버스트 버퍼의 유무에 따른 스토리지 시스템의 최대 달성 가능한 애플리케이션 I/O 대역폭을 보여준다. 실험에서 버스트 버퍼가 없는 풀 스토리지 시스템은 모든 애플리케이션 I/O 요청이 외부 스토리지 시스템과 상호 작용하기 때문에 유사한 지속적인 대역폭을 달성한다. 버스트 버퍼가 없는 하프 스토리지 시스템 구성은 유사한 I/O 패턴을 나타내지 만 전체 스토리지 시스템의 절반 해당하는 대역폭을 보인다. 반면에 버스트 버퍼를 외부 스토리지 시스템 구성으로 사용한 경우 I/O 대역폭의 노드의 규모의 스케일링에 따라 성능이 선형적으로 증가함을 확인할 수 있다. 주목할 점은 하프 스토리지 시스템 구성에서도 버스트 버퍼가 외부 스토리지로 사용된 경우 풀 스토리지 시스템과 유사한 대역폭을 갖는다. 이는 버스트 버퍼가 스토리지의 캐시 역할을 수행하며 병목이 발생하는 시점에 부하를 분산시키기 때문이다. 즉, 버스트 버퍼는 애플리케이션 I/O 요청을 캐싱하고 외부 스토리지 시스템과의 갖는 부하의 비용을 억제한다. 이 테스트에서 애플리케이션 I/O 성능은 컴퓨팅 노드를 I/O 노드와 연결하는 Blue Gene/P 네트워크의 대역폭에 의해 제한되는데 최대 700MiB/s의 대역폭을 갖는다.

Fig. 2.

Performance Comparison with SSD-based Cache(burst buffer) on Argonne IBM Blue Geen/P system

본 연구에서는 여러 대의 계산노드로 구성된 클러스터 환경에서 병렬파일시스템의 NVMe SSD 기반 캐시 계층을 구성하기위한 요구사항과 특징을 논하고 성능을 검증해보고자 한다.

Ⅱ. 관련 연구

병렬파일시스템은 대규모 클러스터 환경에서 대량의 데이터 관리를 목적으로 하며 파일의 I/O를 분산하여 처리한다. 일반적으로 POSIX 기반의 I/O를 지원하며 블록 기반뿐만 아니라 객체(object) 기반의 저장단위를 사용한다. 최근 HPC 환경의 계산노드 규모가 1만여 대까지 구축됨에 따라 병렬파일시스템 대역폭 증가에 대한 아키텍처 디자인 및 비용 요구사항이 커지고 있다. 또한 AI 분야의 머신러닝, 딥러닝 프로그램에서 사용하는 데이터의 특성 또한 다양해지고 있다. 이에 계산 수행시 SSD 기반의 새로운 고속 데이터 스토리지를 이용하여 대역폭을 충족시키고, 이 후 데이터를 병렬파일시스템으로 플러싱 하여 전체적인 파일시스템 성능 향상을 얻을 수 있다[6]. 이런 스토리지 기반으로 구축된 파일시스템의 I/O 성능을 분석하기 위해서는 오픈소스 기반의 I/O 벤치마크 도구가 필요하다. 이를 이용하여 구축된 각 스토리지의 워크로드를 분석함으로써 성능 특성 및 패턴을 얻을 수 있다[7].

2-1 Lustre 파일시스템

Lustre는 HPC 분야의 대표적인 분산 병렬파일시스템으로 여러 대규모 클러스터 환경에서 사용되고 있다[8]. 오픈소스 기반의 파일시스템으로 병렬 I/O를 지원하며 대형 클러스터 시스템에서 고성능의 대역폭을 얻을 수 있도록 설계되었다. 기존 네트워크 파일시스템(NFS)에 객체기반저장(Object based Storage) 기술을 적용하여 확장성과 성능에 있어 이점을 갖는다. Lustre는 대규모 클러스터 환경을 지원할 수 있는 객체 기반의 파일시스템으로 (그림 3)와 같이 메타데이터 서버, 객체 저장 서버, 클라이언트 노드로 구성되며 각각은 고속 네트워크로 연결된다.

Fig. 3.

Lustre Overview

Lustre에서는 TCP/IP, Infiniband[9], OPA[10] 등과 같은 고속의 인터커넥트를 지원한다. Lustre 클라이언트는 리눅스 기반 환경에서 설치되는 파일시스템으로 메타데이터 서버, 객체 저장 서버들과 통신하게 되며 클라이언트에서 수행되는 애플리케이션에 인터페이스를 제공한다. Lustre 서버와 클라이언트들은 동일한 이름공간(Name Space)을 제공하는 공유 파일시스템이며 객체 저장 서버는 파일 데이터를 저장하고 클라이언트로부터의 객체 입출력 요청을 처리한다. 데이터의 위치를 저장하는 객체는 실제 디스크 스토리지에 분산, 스트라이핑(striping) 되어 저장된다.

Lustre는 병렬로 처리하여 여러 노드에서 동시에 하나의 파일을 읽고 쓰는 작업을 수행할 수 있으며, 응용 프로그램이 I/O 성능을 최대한 사용할 수 있도록 만든다. 또한, 여러 대의 스토리지를 하나의 파일시스템으로 구성하며, 하나의 파일을 여러 스토리지에 분산 및 병렬로 저장이 가능하다. Lustre는 또한 이중화를 통해 고가용성(High Availability) 및 복원력을 제공하여 장애 발생에 대한 대응력을 지원한다[11].

Ⅲ. 제 3 장 시스템 환경

본 연구를 위한 시스템 환경은 클러스터 노드에 공유 스토리지인 병렬파일시스템이 존재하며, 그 사이에 I/O 가속을 위한 NVMe SSD 기반의 캐시 스토리지 계층이 구축되어 있다. 병렬파일시스템 소프트웨어는 오픈소스 기반의 Lustre 파일시스템이 설치되어 있다. NVMe SSD 기반 캐시로는 DDN IME 파일시스템을 사용하고 있으며 계산노드와 스토리지(/scratch) 사이의 I/O 가속화를 위한 캐시 레이어 역할을 수행한다. 이는 병렬파일시스템이 갖는 small I/O 또는 random I/O에 대한 낮은 성능 보완할 수 있으며, 병렬 IO의 성능 극대화와 I/O 의존성이 높은 사용자 애플리케이션의 성능 향상을 기대할 수 있다[13].

병렬파일시스템은 SFA7700X 스토리지 기반의 메타데이터 서버(MDS)와, ES14KX 스토리지 기반의 오브젝트 스토리지 서버(OSS)로 구성된다. 계산 노드와 병렬파일시스템 사이에서 동작하는 NVMe 기반의 IO 캐시는 약 800TB의 용량을 제공한다. Lustre와 IME 파일시스템 모두 계산노드에 마운트 되어 파일에 대한 I/O 서비스를 제공한다.

3-1 파일시스템 구성

IME는 사용자 레벨 파일시스템인 FUSE(File System In USErspace)를 사용하여 클라이언트 노드(burst_buffer 큐에 할당된 계산노드)에 마운트 되어 있다. 이때 유의할 것은 IME는 /scratch의 캐시 역할을 수행하기 때문에 해당 파일시스템이 사전에 반드시 마운트 되어 있어야 한다. IME 디렉터리 위치는 /scratch_ime이며 최초로 사용자가 해당 디렉터리(/scratch_ime/$USER)에 접속하면 스크래치(/scratch/$USER) 파일시스템의 모든 디렉터리와 파일의 구조를 동일하게 확인할 수 있다. 이는 실제 IME 디바이스에 존재 않은 데이터이기 때문에 작업 수행 시 /scratch에서 IME로 캐싱하여 수행하게 된다. 따라서 애플리케이션이 수행하는 파일의 사이즈가 큰 경우 NVMe SSD에 캐싱하고 다시 병렬파일시스템으로 플러싱 해야 하는 추가 부하가 발생한다. 따라서 애플리케이션 특성에 따른 I/O 패턴을 사전에 파악할 필요가 있다.

IME를 사용하여 애플리케이션을 수행하는 방법으로는 FUSE((Filesystem in Userspace)를 통해 구현된 POSIX-IO 방식과 IME ROMIO[14]로 구현된 MPI-IO 방식이 존재한다. 한편, NVMe SSD에 저장된 캐시 데이터를 제어하기위해 별도로 IME API 명령어를 제공한다. 이 명령어를 통해 캐시 데이터의 상태를 확인할 수 있다. 캐시 데이터 관리는 3-2절에서 논한다.

Fig. 4.

IME I/O Interface

POSIX-IO 방식은 FUSE를 통해 마운트 된 IME의 디렉터리 경로(/scratch_ime)를 입출력 디렉터리로 지정하여 사용하는 방식으로 별도의 컴파일 없이 기존 애플리케이션을 수행할 수 있다. 또 다른 방식은 IME 파일시스템에 내부에 MPI-IO를 지원하기 위해 구현된 MPI 라이브러리를 사용하는 방법이다. mvapich2 v.2.3.1에는 IME를 지원하는 MPI 라이브러리가 구현되어 있다. 각 애플리케이션은 이 MPI 라이브러리를 이용하여 다시 컴파일한 후 수행해야 한다.

3-2 캐시 데이터 관리

NVMe SSD 기반의 캐시를 관리하기 위해서는 데이터 처리 상태를 파악해야 하며 IME 파일시스템에서 제공하는 API 명령어를 통해 확인할 수 있다. IME 데이터 상태는 (그림 5)와 같이 Prestage, Prefetch, Sync, Release 4 단계가 있으며 각각에 대해 IME-API a명령어인 #ime-ctl)를 제공하고 있다.

▪ Prestage: 병렬파일시스템에서 IME 서버로 데이터를 캐싱 (#ime-ctl -i file-name)
▪ Prefetch: 애플리케이션 수행을 위해 IME 클라이언트인 계산노드의 RAM으로 데이터를 프리패치
▪ Sync: 캐시의 누적된 데이터를 병렬시스템으로 이동 (#ime-ctl -r fil-name)
▪ Release: 캐시에 누적되어 있는 데이터를 삭제 (#ime-ctl -p file-name)

Fig. 5.

IME Data Status

Ⅳ. 성능 분석

본 논문에서는 병렬파일시스템과 NVMe SSD 기반의 캐시에서의 I/O 성능을 측정하기 위해 IOR 벤치마크 도구를 사용하였다. 실험에서는 클러스터 시스템의 I/O 성능을 클러스터 내의 계산노드 수를 증가하면서 수행하기 되는데, IOR을 수행하는 계산노드의 프로세스(thread)는 각각 병렬파일시스템 또는 캐시에 파일을 생성하게 된다. 일반적으로 계산노드의 캐시성능, 인터커넥트의 대역폭, 스토리지 서브시스템의 성능 한계로 읽기와 쓰기 성능은 선형적으로 증가하다 최대 대역폭에 이르면 일정한 수준으로 수렴하거나 떨어지게 된다. 따라서 파일사이즈, 전송사이즈, 병렬수행을 위한 프로세스 개수 등 다양한 값을 이용하여 테스트를 수행하고 최적 성능환경을 확인할 수 있다. IOR 벤치마크 수행방식은 (그림 6)처럼 각 계산노드의 분산 메모리(Distributed Memory)에서 파일시스템에 데이터를 전송하게 된다. 파일사이즈(FileSize)는 다음과 같이 나타낼 수 있다.

Fig. 6.

Design of Shared File Type - Segment, Block, TransferSize (Source: Using IOR to analyze the I/O performance for HPC platforms, LLNL)

블록(Block)은 디스크 또는 파일 시스템에서 쓸 수 있는 가장 작은 단위이며 파일 시스템이 수행하는 모든 작업은 블록 단위로 수행된다. 파일 시스템 블록은 항상 디스크 블록 크기와 같거나 더 크게(정수 배수) 된다. 전송사이즈(Transfer Size)는 IOR 벤치마크에서 프로세스가 한 번에 전송하는 데이터 사이즈이며 지정된 블록사이즈 만큼 전송하게 된다. 따라서 블록사이즈는 전송사이즈의 배수가 된다[12].

클러스터 내의 단일 계산노드는 68개 코어, 96GB DDR4 메모리로 구성되어 있다. 본 실험에서는 노드 당 16개의 프로세스를 사용하여 그 수를 증가시키며 읽기와 쓰기의 성능을 측정하였다. 블록사이즈는 10G, 세그먼트의 수는 1로 고정한다.

▪ BlockSize: 10G
▪ NumTasks: 계산노드 수 × 16
▪ SegmentCount: 1

따라서 한 계산노드에서 생성되는 파일 사이즈는 160GB(10GBx16processes)로 노드당 장착된 메모리 사이즈(96GB)를 초과하므로 캐시효과를 배제하고 성능을 측정할 수 있다[15].

병렬파일시스템에서 <표 1>과 같이 벤치마크 수행시 (그림 7)과 같은 성능을 얻을 수 있다. 병렬파일시스템에서는 32노드(512 processes) 수행시 가장 높은 성능을 나타내다가 이 후 성능이 줄어드는 것을 볼 수 있다.

Table 1.

IOR Benchmarks for Computing Node Growth in Parallel File Systems

Fig. 7.

Performance Scalability with Client Growth in Parallel File Systems

NVMe SSD 기반의 캐시의 성능 테스트는 POSIX-IO와 MPI-IO 두 가지 방식으로 수행하였다. 파일의 출력을 POSIX-IO의 경우 FUSE를 통해 마운트 된 경로(/PFS_ime)로 MPI-IO의 경우는 별도의 ime 프로토콜(ime:///PFS)을 지정하여 수행하게 된다. <표 2>와 같이 벤치마크 수행시 (그림 8)과 같이 병렬파일시스템과 달리 지속적으로 성능이 증가함을 볼 수 있다. 또한, MPI-IO의 경우 노드(프로세스)의 수가 증가함에 따라 POSIX-IO에 비해 성능의 더 높게 증가함을 볼 수 있다. (그림 9는) 병렬파일시스템 대비 NVMe SSD 기반의 캐시의 성능 비율을 나타낸 것으로 노드의 증가에 따른 읽기 성능이 향상된 것을 볼 수 있다. 특히, MPI-IO의 write 성능은 병렬파일시스템 대비 급격히 증가됨을 볼 수 있다.

Table 3.

IOR Benchmarks for Computing Node Growth in NVMe SSD-based Cache

Fig. 8.

POSIX-IO vs MPI-IO Performance Scalability Differences Using Cache Based on NVMe SSDs

Fig. 9.

Performance increase rate when using POSIX-IO and MPI-IO of NVMe SSD based cache compared to parallel file system

Ⅴ. 결 론

데이터의 생산 속도와 처리량에 대한 요구사항이 증가함에 따라 데이터 이동을 가속화하기 위한 솔루션들이 제시되고 있다. NVMe SSD는 고 대역폭을 갖는 디스크 기술로 대규모의 클러스터 환경에 도입되고 있다. 그러나 NVMe SSD는 고비용의 기술로 일반 SATA 기반의 병렬파일시스템 용량을 채우기에는 한계가 있다. 따라서 스토리지와 계산노드 사이에 배치하여 I/O를 가속시키는 캐시로써의 역할을 수행한다면 비용과 용량의 이점을 모두 가질 수 있다.

본 논문은 NVMe SSD 기반의 캐시 역할을 수행하는 IME 파일시스템의 구조와 데이터 처리 방식을 논하였다. 이 후 I/O 벤치마크 도구를 사용하여 기존 병렬파일시스템과 캐시 간의 성능을 비교하였다. 연구자가 HPC 환경에서 애플리케이션 수행시 가장 큰 성능 결과를 좌우하는 것이 파일시스템의 성능이다. 파일시스템의 성능은 스토리지의 용량 및 서브시스템 구성, 계산노드 규모, 인터커넥트 대역폭에 따라 좌우된다. 본 연구의 실험 결과는 애플리케이션 수행하는 연구자에게 파일과 계산노드의 규모 그리고 캐시 기반의 파일 I/O를 통해 얻을 수 있는 성능 개선점을 예측할 수 있게 한다.

향후, 실제 현업 애플리케이션을 선정하여 데이터의 입출력 패턴을 분석하고 특성별로 구분하여 캐시 기반의 파일시스템 성능 결과를 제시한다면 실제 클러스터 시스템 사용자에게 성능에 대한 지침이 될 수 있다.

Acknowledgments

본 연구는 2019년도 부산교육대학교 학술연구과제로 지원을 받아 수행되었음.

참고문헌

• Kunkel, J., Lofstead, G. F., Bent, J., "The Virtual Institute for I/O and the IO-500", No. SAND2017-4839C. Sandia National Lab.(SNL-NM), Albuquerque, NM (United States), 2017.
• Ross, R., Ward, L., Carns, P., Grider, G., Klasky, S., Koziol, Q., Wolf, M., "Storage Systems and I/O: Organizing, Storing, and Accessing Data for Scientific Discovery", USDOE Office of Science (SC)(United States), 2019. [https://doi.org/10.2172/1544750]
• Welch, B., Noer, G., "Optimizing a hybrid SSD/HDD HPC storage system based on file size distributions." in IEEE 29th Symposium on Mass Storage Systems and Technologies (MSST). IEEE, 2013. [https://doi.org/10.1109/MSST.2013.6558449]
• Herbein, Stephen, et al. "Scalable I/O-aware job scheduling for burst buffer enabled HPC clusters.", Proceedings of the 25th ACM International Symposium on High-Performance Parallel and Distributed Computing. ACM, 2016. [https://doi.org/10.1145/2907294.2907316]
• Liu, N., Cope, J., Carns, P., Carothers, C., Ross, R., Grider, G., Maltzahn, C., “On the role of burst buffers in leadership-class storage systems,” in IEEE 28th symposium on mass storage systems and technologies (MSST), pp. 1-11, IEEE, April 2012. [https://doi.org/10.1109/MSST.2012.6232369]
• Bhimani, J., Yang, J., Yang, Z., Mi, N., Xu, Q., Awasthi, M., Balakrishnan, V., "Understanding performance of I/O intensive containerized applications for NVMe SSDs.", in IEEE 35th International Performance Computing and Communications Conference (IPCCC), pp. 1-8, Dec, 2016. [https://doi.org/10.1109/PCCC.2016.7820650]
• Y. JunWeon, S. Ui-Sung, “Study of Optimization through Performance Analysis of Parallel Distributed Filesystem”, The Journal of Digital Contents Society, Vol. 17, No. 5, pp. 409-416, 2016. [https://doi.org/10.9728/dcs.2016.17.5.409]
• Wang, F., Oral, S., Shipman, G., Drokin, O., Wang, T., Huang, I., "Understanding lustre filesystem internals", Oak Ridge National Laboratory, ational Center for Computational Sciences, Tech. Rep,. 2019.
• Liu, J., Wu, J., Kini, S., Buntinas, D., Yu, W., Chandrasekaran, B., Center, O. S., "MPI over InfiniBand: Early experiences." Ohio State University Technical Report , 2003.
• Birrittella, M. S., Debbage, M., Huggahalli, R., Kunz, J., Lovett, T., Rimmer, T., & Zak, R. C., "Intel Omni-path architecture: Enabling scalable, high performance fabrics.", in IEEE 23rd Annual Symposium on High-Performance Interconnects, IEEE, pp. 1-9, Aug, 2015. [https://doi.org/10.1109/HOTI.2015.22]
• Lofstead, J., Zheng, F., Klasky, S., Schwan, K.,"Adaptable, metadata rich IO methods for portable high performance IO." in IEEE International Symposium on Parallel & Distributed Processing, IEEE, pp. 1-10, May, 2009. [https://doi.org/10.1109/IPDPS.2009.5161052]
• Shan, H., Shalf, J., "Using IOR to analyze the I/O performance for HPC platforms.", 2007.
• Schenck, W., El Sayed, S., Foszczynski, M., Homberg, W., Pleiter, D., "Evaluation and performance modeling of a burst buffer solution.", ACM SIGOPS Operating Systems Review, 50(2), pp. 12-26, 2017. [https://doi.org/10.1145/3041710.3041714]
• Rajesh Bordawekar, Juan Miguel del Rosario, and Alok Choudhary. Design and evaluation of primitives for parallel I/O. In Proceedings of Supercomputing, Portland, OR, pp 452-461, 1993. [https://doi.org/10.1145/169627.169782]
• Shan, H., Antypas, K., Shalf, J., "Characterizing and predicting the I/O performance of HPC applications using a parameterized synthetic benchmark.", Proceedings of the 2008 ACM/IEEE conference on Supercomputing, IEEE Press, p. 42, Nov, 2008. [https://doi.org/10.1109/SC.2008.5222721]