Dell EMC Ready Solution for HPC PixStor Storage - 용량 확장(영문)

없음

목차

1. 소개
   1. 솔루션 아키텍처
   2. 솔루션 구성 요소
2. 성능 특성화
   1. 순차 IOzone Performance N 클라이언트에서 N 파일로
   2. 1개의 파일로의 순차 IOR 성능 N 클라이언트
   3. 임의로 작은 블록 IOzone Performance N 클라이언트에서 N 파일로
   4. 빈 파일을 사용하여 MDtest를 사용한 메타데이터 성능
   5. 4 KiB 파일을 사용하는 MDtest의 메타데이터 성능
3. 결론 및 향후 작업

 

---

소개

오늘날의 HPC 환경은 NFS, SMB 등과 같은 여러 표준 프로토콜을 통해 대용량 및 분산 액세스가 필요한 매우 빠른 스토리지에 대한 수요가 증가하고 있습니다. 이러한 수요가 높은 HPC 요구 사항은 일반적으로 단일 파일 또는 여러 노드의 파일 세트에 대한 동시 액세스를 제공하는 병렬 파일 시스템에서 지원되며, 여러 서버에 걸쳐 여러 LUN에 데이터를 매우 효율적이고 안전하게 분산합니다.

 

---

솔루션 아키텍처

이 블로그는 HPC 환경을 위한 PFS(Continuation Parallel File System) 솔루션으로, PowerVault ME484 EBOD 스토리지를 사용하여 솔루션의 용량을 늘리는 DellEMC Ready Solution for HPC PixStor Storage입니다. 그림 1 에는 기존 PowerVault ME4084 스토리지 어레이에 추가된 용량 확장 SAS를 나타내는 참조 아키텍처가 나와 있습니다.
PixStor 솔루션에는 PFS 구성 요소로도 알려진 광범위한 일반 병렬 파일 시스템뿐만 아니라 고급 분석, 관리 및 모니터링 간소화, 효율적인 파일 검색, 고급 게이트웨이 기능 등과 같은 다른 여러 Arcastream 소프트웨어 구성 요소가 포함되어 있습니다.


그림 1: 레퍼런스 아키텍처.

 

---

솔루션 구성 요소

이 솔루션은 최신 인텔 제온 2세대 확장 가능한 제온 CPU(일명 Cascade Lake CPU)와 함께 출시될 예정이며 일부 서버는 사용 가능한 가장 빠른 RAM(2933MT/s)을 사용합니다. 그러나 성능을 특성화하기 위해 솔루션의 프로토타입에서 작업할 수 있는 현재 하드웨어로 인해 인텔 제온 1세대 확장 가능한 제온 CPU가 있는 서버가 있습니다. Skylake 프로세서와 경우에 따라 더 느린 RAM이 이 시스템의 특성을 지정하는 데 사용되었습니다. 솔루션의 병목 현상은 DellEMC PowerVault ME40x4 어레이의 SAS 컨트롤러에 있기 때문에 Skylake CPU와 RAM을 구상된 Cascade Lake CPU와 더 빠른 RAM으로 교체한 후에는 큰 성능 차이가 발생하지 않습니다. 또한 이 솔루션은 RHEL 7.7 및 OFED 4.7을 지원하는 최신 버전의 PixStor(5.1.1.4)로 업데이트되었습니다.

이전에 설명한 상황으로 인해 표 1에는 솔루션의 주요 구성 요소 목록이 있지만 불일치가 도입되었을 때 첫 번째 설명 열에는 릴리스 시점에 사용된 구성 요소가 있으므로 고객이 사용할 수 있으며 마지막 열은 솔루션의 성능을 특성화하기 위해 실제로 사용되는 구성 요소입니다. 데이터(12TB NLS) 및 메타데이터(960Gb SSD)에 나열된 드라이브는 성능 특성화에 사용되는 드라이브이며, 더 빠른 드라이브는 더 나은 랜덤 IOPS를 제공하고 메타데이터 생성/제거 작업을 개선할 수 있습니다.

마지막으로, 완성도를 위해 가능한 데이터 HDD 및 메타데이터 SSD 목록이 포함되었으며, 이 목록은 온라인으로 제공되는 DellEMC PowerVault ME4 지원 매트릭스에서 열거된 드라이브를 기반으로 합니다.

표 1 릴리스 시 사용되는 구성 요소 및 테스트침대에 사용되는 구성 요소

솔루션 구성 요소		릴리스 시	테스트 베드
내부 연결		Dell Networking S3048-ON 기가비트 이더넷
데이터 스토리지 서브시스템		Dell EMC PowerVault ME4084 1~4개 1x~4개의 Dell EMC PowerVault ME484(ME4084당 1개) 80~ 12TB 3.5" NL SAS3 HDD 드라이브 옵션 900GB @15K, 1.2TB @10K, 1.8TB @10K, 2.4TB @10K, 4TB NLS, 8TB NLS, 10TB NLS, 12TB NLS.     8개의 LUN, 선형 8+2 RAID 6, 청크 크기 512KiB. 메타데이터용 1.92TB SAS3 SSD 4개 – RAID 1 2개(또는 글로벌 HDD 스페어 4개,고가용성 메타데이터 모듈 옵션 사용 시)
고가용성 메타데이터 스토리지 서브시스템(선택 사항)		1~2개의 Dell EMC PowerVault ME4024(필요한 경우 4개의 ME4024, 대형 구성만 해당) 24개의 960GB 2.5" SSD SAS3 드라이브(옵션 480GB, 960GB, 1.92TB) 12개의 LUN, 선형 RAID 1.
RAID 스토리지 컨트롤러		12Gbps SAS
구성된 용량		원시: 8064TB(7334TiB 또는 7.16 PiB) 포맷 ~ 6144GB(5588TiB 또는 5.46 PiB)
프로세서	Gateway	인텔 제온 골드 6230 2.1G, 20C/40T, 10.4GT/s, 27.5M 캐시, 터보, HT(125W) DDR4-2933 2개	N/A
	높은 수요의 메타데이터		2개의 인텔 제온 골드 6136@ 3.0GHz, 12코어
	스토리지 노드		2개의 인텔 제온 골드 6136@ 3.0GHz, 12코어
	관리 노드	인텔 제온 골드 5220 2.2G, 18C/36T, 10.4GT/s, 24.75M 캐시, 터보, HT(125W) DDR4-2666 2개	2개의 인텔 제온 골드 5118@ 2.30GHz, 12코어
메모리	Gateway	12개의 16GiB 2933MT/s RDIMM(192GiB)	N/A
	높은 수요의 메타데이터		24개의 16GiB 2666MT/s RDIMM(384GiB)
	스토리지 노드		24개의 16GiB 2666MT/s RDIMM(384GiB)
	관리 노드	16GB DIMM 12개, 2666MT/s(192GiB)	12개의 8GiB 2666MT/s RDIMM(96GiB)
운영 체제		Red Hat Enterprise Linux 7.6	Red Hat Enterprise Linux 7.7
커널 버전		3.10.0-957.12.2.el7.x86_64	3.10.0-1062.9.1.el7.x86_64
PixStor 소프트웨어		5.1.0.0	5.1.1.4
GPFS(Spectrum Scale)		5.0.3	5.0.4-2
고성능 네트워크 연결		Mellanox ConnectX-5 듀얼 포트 InfiniBand EDR/100GbE 및 10GbE	Mellanox ConnectX-5 InfiniBand EDR
고성능 스위치		Mellanox SB7800(HA – 이중화) 2개	Mellanox SB7700 1개
OFED 버전		Mellanox OFED-4.6-1.0.1.0	Mellanox OFED-4.7-3.2.9
로컬 디스크(OS 및 분석/모니터링)		관리 노드를 제외한 모든 서버 OS용 480GB SSD SAS3(RAID1 + HS) 3개 PERC H730P RAID 컨트롤러 관리 노드 OS용 480GB SSD SAS3(RAID1 + HS) 3개 PERC H740P RAID 컨트롤러	관리 노드를 제외한 모든 서버 OS용 300GB 15K SAS3(RAID 1) 2개 PERC H330 RAID 컨트롤러 관리 노드 OS 및 분석/모니터링을 위한 300GB 15K SAS3(RAID 5) 5개 PERC H740P RAID 컨트롤러
시스템 관리		iDRAC 9 Enterprise + DellEMC OpenManage	iDRAC 9 Enterprise + DellEMC OpenManage

 

---

성능 특성화

이 새로운 Ready Solution을 특성화하기 위해 선택 사항인 High Demand 메타데이터 모듈을 포함하여 표 1의 마지막 열에 지정된 하드웨어를 사용했습니다. 솔루션 성능을 평가하기 위해 다음 벤치마크가 사용되었습니다.

• IOzone N -N 순차
• IOR N ~ 1 순차
• IOzone 랜덤
• MDtest

 위에 나열된 모든 벤치마크의 경우 아래 표 2에 설명된 대로 테스트 베드에 클라이언트가 있었습니다. 테스트에 사용할 수 있는 컴퓨팅 노드 수는 16개에 불과했기 때문에 더 많은 스레드가 필요할 때 이러한 스레드는 컴퓨팅 노드에 동일하게 분산되었습니다(예: 32개 스레드 = 노드당 2개 스레드, 64개 스레드 = 노드당 4개 스레드, 128개 스레드 = 노드당 8개 스레드, 256개 스레드 =노드당 16개 스레드, 512개 스레드 = 노드당 32개 스레드, 1024개 스레드 = 노드당 64개 스레드). 컴퓨팅 노드 수가 제한된 상태에서 더 많은 수의 동시 클라이언트를 시뮬레이션하기 위한 것이었습니다. 벤치마크는 많은 수의 스레드를 지원하므로 과도한 컨텍스트 스위칭 및 기타 관련 부작용이 성능 결과에 영향을 미치지 않도록 하면서 최대 1,024개의 최대 값을 사용했습니다(각 테스트에 지정됨).

표 2 클라이언트 테스트침대

클라이언트 노드 수	16
클라이언트 노드	C6320
클라이언트 노드당 프로세서	인텔(R) 제온(R) 골드 E5-2697v4 18코어 2.30GHz 2개
클라이언트 노드당 메모리	12 x 16GiB 2400MT/s RDIMM
BIOS	2.8.0
OS 커널	3.10.0-957.10.1
GPFS 버전	5.0.3

 

---

순차 IOzone Performance N 클라이언트에서 N 파일로

순차 N 클라이언트에서 N 파일로의 성능은 IOzone 버전 3.487로 측정되었습니다. 테스트는 단일 스레드에서 최대 1,024개의 스레드까지 다양했으며 용량 확장 솔루션(ME4084s 4개 + ME484 4개)의 결과는 대규모 솔루션(ME4084 4개)과 대조됩니다. GPFS 페이지 풀을 튜닝할 수 있는 16GiB로 설정하고 크기가 두 배 더 큰 파일을 사용하여 캐싱 효과를 최소화했습니다. GPFS의 경우 설치 및 사용 가능한 RAM 양에 관계없이 튜닝이 가능하면 데이터 캐싱에 사용되는 최대 메모리 용량을 설정하는 것이 중요합니다. 또한 이전 DellEMC HPC 솔루션에서는 대규모 순차 전송에 대한 블록 크기가 1 MiB이지만 GPFS는 8개의 MiB 블록으로 포맷되었기 때문에 최적의 성능을 위해 벤치마크에 값이 사용된다는 점도 주목해야 합니다. 너무 커 보일 수도 있고 공간을 너무 많이 낭비할 수도 있지만 GPFS는 이러한 상황을 방지하기 위해 스텁 할당을 사용합니다. 현재 구성에서는 각 블록이 각각 32 KiB의 256개 서브록으로 세분화되었습니다.

다음 명령을 사용하여 쓰기 및 읽기에 대한 벤치마크를 실행했습니다. 여기서 스레드는 사용된 스레드 수(1~1024 2개씩 증가)가 있는 변수였고, 스레드 목록은 라운드 로빈을 사용하여 16개의 컴퓨팅 노드에 동종으로 분산하는 다른 노드의 각 스레드를 할당한 파일이었습니다.

./iozone -i0 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./threadlist
./iozone -i1 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./threadlist

그림 2:  N에서 N까지의 순차적 성능


결과에서 사용된 클라이언트 수에 따라 성능이 매우 빠르게 상승하고 IOzone이 허용하는 최대 스레드 수에 도달할 때까지 안정적인 고원에 도달하므로 1024개의 동시 클라이언트에서도 대용량 파일 순차적 성능이 안정적인지 확인할 수 있습니다. 읽기 및 쓰기 성능 모두 드라이브 수가 두 배로 늘어나면 도움이 됩니다. 최대 읽기 성능은 8스레드부터 스토리지 노드에 사용되는 두 IB EDR 링크의 대역폭에 의해 제한되었으며 ME4 어레이는 몇 가지 추가 성능을 사용할 수 있습니다. 마찬가지로 최대 쓰기 성능은 64개 및 128개 스레드에서 최대 16.7GB/s에서 20.4GB/s로 증가했으며 ME4 어레이의 최대 사양(22GB/s)에 더 가깝습니다.

여기서는 GPFS 기본 작동 모드가 분산되어 있고 이러한 모드를 사용하도록 솔루션이 포맷되었다는 점을 기억해야 합니다. 이 모드에서는 블록이 작동 초기부터 유사 랜덤 방식으로 할당되어 각 HDD의 전체 표면에 데이터를 분산합니다. 명백한 단점은 초기 최대 성능이 작지만 파일 시스템에 사용된 공간의 양에 관계없이 성능이 상당히 일정하게 유지됩니다. 이는 디스크 회전당 더 많은 데이터(섹터)를 수용할 수 있는 외부 트랙을 처음 사용하는 다른 병렬 파일 시스템과 달리 HDD가 제공할 수 있는 성능이 가장 높지만 시스템이 더 많은 공간을 사용하므로 회전당 데이터가 적은 내부 트랙이 사용되므로 결과적으로 성능이 저하됩니다.

 

---

1개의 파일로의 순차 IOR 성능 N 클라이언트

단일 공유 파일 성능에 대한 순차적 N 클라이언트는 16개의 컴퓨팅 노드에서 벤치마크를 실행하기 위해 OpenMPI v4.0.1의 지원을 받아 IOR 버전 3.3.0으로 측정되었습니다. 실행된 테스트는 1개의 스레드에서 최대 512개의 스레드(1024개 스레드에 대한 코어가 충분하지 않았기 때문에)까지 다양했으며, 결과는 용량 확장이 없는 솔루션과 대조됩니다.
GPFS 페이지 풀을 튜닝할 수 있는 16GiB로 설정하고 크기가 두 배 더 큰 파일을 사용하여 캐싱 효과를 최소화했습니다. 이 벤치마크 테스트에서는 최적의 성능을 위해 8개의 MiB 블록을 사용했습니다. 이전 성능 테스트 섹션에는 이러한 문제에 대한 보다 완전한 설명이 있습니다.

다음 명령은 쓰기 및 읽기에 대한 벤치마크를 실행하는 데 사용되었으며, 여기서 스레드는 사용된 스레드 수(1~1024 2개 단위로 증가)가 있는 변수였고, my_hosts.$Threads 라운드 로빈을 사용하여 16개의 컴퓨팅 노드에 동종으로 분산하는 다른 노드에 각 스레드를 할당한 해당 파일입니다.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -w -s 1 -t 8m -b 128G 

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -r -s 1 -t 8m -b 128G

그림 3: N -1 순차적 성능

결과에서 추가 드라이브가 읽기 및 쓰기 성능에 도움이 된다는 것을 다시 확인할 수 있습니다. 사용된 클라이언트의 수에 따라 성능이 다시 매우 빠르게 상승하고 읽기 및 쓰기에 상당히 안정적인 고원에 도달하여 이 테스트에 사용된 최대 스레드 수에 도달합니다. 최대 읽기 성능은 16개 스레드에서 24.8GB/s였고 병목 현상은 InfiniBand EDR 인터페이스였으며 ME4 어레이는 여전히 몇 가지 추가 성능을 사용할 수 있었습니다. 이 시점부터 읽기 성능은 약 23.8GB/s의 고원에 도달할 때까지 해당 값에서 감소했습니다. 마찬가지로 최대 쓰기 성능인 19.3은 8스레드에서 도달하여 고원에 도달했습니다.
 

---

임의로 작은 블록 IOzone Performance N 클라이언트에서 N 파일로

N 파일에 대한 랜덤 N 클라이언트의 성능은 기존 Iozone 대신 FIO 버전 3.7로 측정되었습니다. 이전 블로그에 나열된 의도는 ME4084 스토리지가 제공할 수 있는 최대 성능을 조사하기 위해 더 큰 대기열 심도를 활용하는 것이었습니다(ME4084 스토리지에 대한 이전 테스트에서는 ME4084 스토리지가 임의 입출력 제한에 도달하기 위해 더 많은 입출력 압력이 필요하다는 것을 보여주었습니다).

1024개 스레드에 대한 클라이언트 코어가 충분하지 않았기 때문에 실행된 테스트는 단일 스레드에서 최대 512개의 스레드까지 다양했습니다. 각 스레드는 다른 파일을 사용하고 있었고 스레드에는 클라이언트 노드에 라운드 로빈이 할당되었습니다. 이 벤치마크 테스트에서는 4개의 KiB 블록을 사용하여 작은 블록 트래픽을 에뮬레이트하고 대기열 깊이 16을 사용했습니다. 대규모 솔루션과 용량 확장의 결과를 비교합니다.

GPFS 페이지 풀 튜닝을 16GiB로 설정하고 크기가 두 배인 파일을 사용하여 캐싱 효과가 다시 최소화되었습니다. 첫 번째 성능 테스트 섹션에는 GPFS에 효과적인 이유에 대한 보다 완전한 설명이 있습니다.

 
그림 4:  N - N 랜덤 성능

결과에서 쓰기 성능은 29.1K IOps의 높은 값으로 시작하여 약 40K IOps에서 고원에 도달하는 것으로 보이는 최대 64개의 스레드까지 꾸준히 상승하는 것을 확인할 수 있습니다. 반면 읽기 성능은 1.4K IOps에서 시작하여 사용된 클라이언트 수에 따라 거의 선형적으로 성능을 향상시키고(각 데이터 포인트에 대해 스레드 수가 두 배로 증가한다는 점을 명심) 고원에 근접한 64개 스레드에서 최대 25.6K IOPS의 성능에 도달합니다. 더 많은 스레드를 사용하려면 리소스 부족과 확연한 성능 저하를 방지하기 위해 16개 이상의 컴퓨팅 노드가 필요합니다. 이 경우 어레이가 실제로 성능을 유지할 수 있습니다.

 

---

빈 파일을 사용하여 MDtest를 사용한 메타데이터 성능

메타데이터 성능은 16개 컴퓨팅 노드에서 벤치마크를 실행하기 위해 OpenMPI v4.0.1의 지원을 받아 MDtest 버전 3.3.0으로 측정되었습니다. 실행된 테스트는 단일 스레드에서 최대 512개의 스레드까지 다양했습니다. 이 벤치마크는 파일 전용(디렉토리 메타데이터 없음)에 사용되었으며, 솔루션이 처리할 수 있는 생성, 통계, 읽기 및 제거 횟수를 확보했으며 결과는 대규모 솔루션과 대조되었습니다.

다른 DellEMC HPC 스토리지 솔루션 및 이전 블로그 결과와 비교하여 솔루션을 적절하게 평가하기 위해 선택 사항인 High Demand 메타데이터 모듈이 사용되었지만 단일 ME4024 어레이에서는 이 작업에서 테스트된 대규모 구성이 2개의 ME4024로 지정되었다. 이 High Demand 메타데이터 모듈은 최대 4개의 ME4024 스토리지를 지원할 수 있으며, 다른 메타데이터 모듈을 추가하기 전에 ME4024 어레이 수를 4로 늘리는 것이 좋습니다. 추가 ME4024 어레이는 통계 작업(빈 파일의 경우 읽기)을 제외하고 각 추가 스토리지에서 메타데이터 성능을 선형적으로 향상시킬 것으로 예상됩니다. 숫자가 매우 높기 때문에 어떤 시점에서는 CPU가 병목 현상이 발생하고 성능이 선형적으로 증가하지 않습니다.

다음 명령을 사용하여 벤치마크를 실행했습니다. 여기서 스레드는 사용된 스레드 수(1~512 2개씩 증가)가 있는 변수이고, my_hosts.$Threads 라운드 로빈을 사용하여 16개의 컴퓨팅 노드에 동종으로 분산하는 다른 노드에 각 스레드를 할당한 해당 파일입니다. 랜덤 입출력 벤치마크와 마찬가지로 최대 스레드 수는 512개로 제한되었습니다. 1024개 스레드에 대한 코어가 충분하지 않기 때문에 컨텍스트 스위칭은 결과에 영향을 미치며 솔루션의 실제 성능보다 낮은 수치를 보고합니다.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1// perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F

성능 결과는 총 IOPS 수, 디렉토리당 파일 수 및 스레드 수에 따라 영향을 받을 수 있으므로 총 파일 수를 2개의 MiB 파일(2^21 = 2097152), 1024에서 수정된 디렉토리당 파일 수, 그리고 표 3에 표시된 대로 변경된 스레드 수에 따라 디렉토리 수가 달라지도록 결정되었습니다.

표 3:  디렉토리에 있는 파일의 MDtest 배포

스레드 수	스레드당 디렉토리 수	총 파일 수
1	2048	2,097,152
2	1024	2,097,152
4	512	2,097,152
8	256	2,097,152
16	128	2,097,152
32	64	2,097,152
64	32	2,097,152
128	16	2,097,152
256	8	2,097,152
512	4	2,097,152
1024	2	2,097,152

그림 5: 메타데이터 성능 - 빈 파일

첫째, 선택한 스케일이 Base 10의 로그로 표시되어 몇 가지 크기의 차이가 있는 작업을 비교할 수 있습니다. 그렇지 않으면 일부 작업은 일반 그래프에서 0에 가까운 평평한 선처럼 보입니다. 기본 2의 로그 그래프는 스레드 수가 2의 전력으로 증가하지만 그래프는 매우 유사해 보일 수 있으며 사람들은 10의 힘을 기준으로 더 나은 숫자를 처리하고 기억하는 경향이 있기 때문에 더 적합할 수 있습니다.
Stat 및 Read 작업이 각각 11M op/s 및 4.7M op/s에 달하는 64개 스레드에서 최대값에 도달하면 매우 좋은 결과를 얻을 수 있습니다. 제거 작업은 16개 스레드에서 최대 170.6K op/s를 달성했으며, 생성 작업은 222.1K op/s로 32스레드에서 최대 32개의 스레드를 달성했습니다. 통계 및 읽기 작업은 변동성이 더 높지만, 최대값에 도달하면 성능이 통계의 경우 3M op/s 미만으로, 읽기의 경우 2M op/s 미만으로 떨어지지 않습니다. 생성 및 제거는 고원에 도달하면 더 안정적이며 제거의 경우 140K op/s 이상, Create의 경우 120K op/s 이상으로 유지됩니다. 추가 드라이브는 예상대로 빈 파일에서 대부분의 메타데이터 작업에 영향을 미치지 않습니다.
 

---

4 KiB 파일을 사용하는 MDtest의 메타데이터 성능

이 테스트는 빈 파일 대신 4KiB의 작은 파일을 사용했다는 점을 제외하고 이전 테스트와 거의 동일합니다. 
다음 명령을 사용하여 벤치마크를 실행했습니다. 여기서 스레드는 사용된 스레드 수(1~512 2개씩 증가)가 있는 변수이고, my_hosts.$Threads 라운드 로빈을 사용하여 16개의 컴퓨팅 노드에 동종으로 분산하는 다른 노드에 각 스레드를 할당한 해당 파일입니다.

mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior btl_openib_allow_ib/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 4K -e 4K

그림 6:  메타데이터 성능 - 소규모 파일(4K)

시스템은 각각 8.2M op/s 및 400K op/s를 사용하여 256개 스레드에서 최대값에 도달한 통계 및 제거 작업에 매우 좋은 결과를 제공합니다. 읽기 작업은 최대 44.8K op/s를 달성하고 512개 스레드에서 모두 68.1K op/s로 최대 성능을 달성했습니다. 통계 및 제거 작업은 변동성이 더 높지만 최대값에 도달하면 통계의 경우 성능이 3M op/s 미만으로, 제거 시 280K op/s 미만으로 떨어지지 않습니다. 생성 및 읽기는 가변성이 낮으며 스레드 수가 증가함에 따라 계속 증가합니다. 관찰할 수 있듯이 용량 확장의 추가 드라이브는 메타데이터 성능에 미미한 변경 사항만 제공합니다.
이 수치는 단일 ME4024가 있는 메타데이터 모듈용이므로 추가 ME4024 어레이마다 성능이 향상되지만 각 작업에 대해 선형적 증가를 가정할 수는 없습니다. 전체 파일이 이러한 파일의 inode 내부에 맞지 않는 한 ME4084s의 데이터 타겟은 4K 파일을 저장하는 데 사용되므로 성능이 어느 정도 제한됩니다. inode 크기는 4KiB이고 메타데이터를 저장해야 하므로 3 KiB 정도의 파일만 내부에 적합하며 데이터 타겟을 사용하는 파일보다 큰 파일만 사용할 수 있습니다.
 

---

결론 및 향후 작업

용량이 확장된 솔루션은 랜덤 액세스뿐만 아니라 순차적 성능에도 성능을 향상시킬 수 있었습니다. 산점 모드는 랜덤 액세스로 작동하며 디스크가 더 많을수록 개선이 가능하기 때문에 예상된 것입니다. 표 4에서 개요할 수 있는 이 성능은 거의 가득 찼을 때까지 빈 파일 시스템에서 안정적으로 작동해야 합니다. 또한 더 많은 스토리지 노드 모듈이 추가됨에 따라 용량과 성능이 선형적으로 확장되며, 수요가 많은 메타데이터 모듈(선택 사항)에서도 비슷한 성능 향상을 기대할 수 있습니다. 이 솔루션은 HPC 고객에게 많은 상위 500개 HPC 클러스터에서 사용되는 매우 신뢰할 수 있는 병렬 파일 시스템을 제공합니다. 또한 탁월한 검색 기능, 고급 모니터링 및 관리 기능을 제공하며, 선택적 게이트웨이를 추가하면 NFS, SMB 및 기타 클라이언트와 같은 유비쿼터스 표준 프로토콜을 통해 필요에 따라 파일을 공유할 수 있습니다.

표 4  최고 및 지속적인 성능

	최고 성능		지속적인 성능
	쓰기	읽기	쓰기	읽기
N 파일에 대한 대규모 순차 N 클라이언트	20.4GB/s	24.2GB/s	20.3GB/s	24GB/s
단일 공유 파일에 대한 대규모 순차적 N 클라이언트	19.3GB/s	24.8GB/s	19.3GB/s	23.8GB/s
랜덤 소형 블록 N 클라이언트에서 N 파일로	40KIOps	25.6KIOps	40.0KIOps	19.3KIOps
메타데이터 빈 파일 생성	169.4K IOps		123.5K IOps
메타데이터 통계 빈 파일	1,100만 IOps		3.2M IOps
메타데이터 빈 파일 읽기	4.7M IOps		2.4M IOps
메타데이터 비어 있는 파일 제거	170.6K IOps		156.5K IOps
메타데이터 생성 4KiB 파일	68.1K IOps		68.1K IOps
메타데이터 Stat 4KiB 파일	8.2M IOps		3M IOps
메타데이터 읽기 4KiB 파일	44.8K IOps		44.8K IOps
메타데이터 제거 4KiB 파일	400K IOps		280K IOps

이 솔루션은 Cascade Lake CPU와 더 빠른 RAM을 사용하여 출시될 예정이므로 시스템에 최종 구성이 완료되면 일부 성능 스폿 검사가 수행됩니다. 또한 ME4024s 및 4KiB 파일이 2개 이상인 고가용성 메타데이터 모듈(선택 사항)을 테스트하여 데이터 타겟이 관련될 때 메타데이터 성능이 어떻게 확장되는지 더 잘 문서화해야 합니다. 또한 게이트웨이 노드의 성능을 측정하고 새로운 블로그 또는 백서에서 해당 지점 검사의 관련 결과와 함께 보고합니다. 마지막으로, 더 많은 기능을 제공하기 위해 더 많은 솔루션 구성 요소를 테스트하고 출시할 계획입니다.