Dell EMC Ready Solution for HPC PixStor Storage

2019년 10월 HPC 및 AI Innovation Lab의 Mario Gallegos가 작성한 문서

목차

1. 소개
   1. 솔루션 아키텍처
   2. 솔루션 구성 요소
2. 성능 특성화
   1. 순차적 IOzone 성능 N 클라이언트-N 파일
   2. 순차적 IOR 성능 N 클라이언트-1 파일
   3. 랜덤 작은 블록 IOzone 성능 N 클라이언트-N 파일
   4. 빈 파일을 사용한 MDtest의 메타데이터 성능
   5. 4KiB 파일을 사용한 MDtest의 메타데이터 성능
   6. 3K 파일에서 MDtest를 사용한 메타데이터 성능
3. 고급 분석
4. 결론 및 향후 작업

소개

솔루션 아키텍처

솔루션 구성 요소

성능 특성화

•     IOzone N-N 순차
•     IOR N-1 순차
•     IOzone 랜덤
•     MDtest
  
  위에 나열된 모든 벤치마크의 테스트 베드에는 아래 표 2 에 설명된 클라이언트가 있습니다. 테스트에 사용할 수 있는 컴퓨팅 노드 수가 16개이므로 더 많은 수의 스레드가 필요한 경우 해당 스레드는 컴퓨팅 노드에 균등하게 분산되었습니다(즉, 32개 스레드 = 노드당 2개 스레드, 64개 스레드 = 노드당 4개 스레드, 128개 스레드 = 노드당 8개 스레드, 256개 스레드 = 노드당 16개 스레드, 512개 스레드 = 노드당 32개 스레드, 1024개 스레드 = 노드당 64개 스레드) 목적은 제한된 수의 컴퓨팅 노드로 더 많은 수의 동시 클라이언트를 시뮬레이션하는 것이었습니다. 벤치마크는 많은 수의 스레드를 지원하므로 과도한 컨텍스트 전환 및 기타 관련 부작용이 성능 결과에 영향을 주지 않도록 하면서 최대 1024개(각 테스트에 대해 지정됨)가 사용되었습니다.
  
  표 2 클라이언트 테스트 베드

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

   

  ---

  순차적 IOzone 성능 N 클라이언트-N 파일

  IOzone 버전 3.487을 사용하여 순차적 N 클라이언트-N 파일 성능을 측정했습니다. 실행된 테스트는 단일 스레드에서 최대 1024개 스레드까지 다양했습니다. 
  조정 가능한 GPFS 페이지 풀을 16GiB로 설정하고 2배 더 큰 크기의 파일을 사용하여 캐싱 효과를 최소화했습니다. 조정 가능한 GPFS의 경우 설치된 RAM 및 사용 가능한 RAM의 양에 관계없이 데이터 캐싱에 사용되는 최대 메모리 양을 설정한다는 점에 유의하는 것이 중요합니다. 또한 주목해야 할 중요한 점은 이전 Dell EMC HPC 솔루션에서 대규모 순차 전송의 블록 크기가 1MiB인 반면 GPFS는 8MiB 블록으로 형식화되었기 때문에 최적의 성능을 위해 벤치마크에서 해당 값이 사용된다는 것입니다. 너무 커서 너무 많은 공간을 낭비하는 것처럼 보일 수 있지만 GPFS는 하위 블록 할당을 사용하여 이러한 상황을 방지합니다. 현재 구성에서 각 블록은 각각 32KiB의 256개 서브블록으로 세분화되었습니다. 
  다음 명령은 쓰기 및 읽기에 대한 벤치마크를 실행하는 데 사용되었으며, 여기서 Threads는 사용된 스레드 수(1에서 1024까지 2의 거듭제곱으로 증가)가 있는 변수이고 threadlist는 라운드 로빈을 사용하여 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개의 동시 클라이언트에서도 안정적임을 확인할 수 있습니다. 최대 읽기 성능은 32개 스레드에서 23GB/s였고 InfiniBand EDR 인터페이스에서 병목 현상이 발생했을 가능성이 매우 높습니다. 반면 ME4 어레이에는 여전히 추가 성능이 있습니다. 마찬가지로 최대 쓰기 성능 16.7은 16스레드에서 조금 일찍 도달했으며 ME4 어레이 사양에 비해 낮습니다.
  여기서 GPFS 선호 조작 모드는 분산되어 있으며 솔루션은 이를 사용하도록 형식화되었음을 기억하는 것이 중요합니다. 이 모드에서는 블록이 처음부터 의사 랜덤 방식으로 할당되어 각 HDD의 전체 표면에 데이터가 분산됩니다. 초기 최대 성능이 낮다는 것이 확실한 단점이지만, 파일 시스템에서 사용되는 공간의 양에 관계없이 해당 성능이 상당히 일정하게 유지됩니다. 초기에 디스크 회전당 더 많은 데이터(섹터)를 보유할 수 있는 외부 트랙을 사용하는 다른 병렬 파일 시스템과 달리 HDD가 제공할 수 있는 최고의 성능을 사용할 수 있습니다. 그러나 시스템이 더 많은 공간을 사용함에 따라 회전당 데이터가 적은 내부 트랙이 사용되어 결과적으로 성능이 저하됩니다. 
  
   

  ---

  순차적 IOR 성능 N 클라이언트-1 파일

  단일 공유 파일에 대한 순차적 N 클라이언트의 성능은 16개의 컴퓨팅 노드에서 벤치마크를 실행하기 위해 OpenMPI v4.0.1의 지원을 받아 IOR 버전 3.3.0으로 측정되었습니다. 실행된 테스트는 단일 스레드에서 최대 1024개 스레드까지 다양했습니다.
  조정 가능한 GPFS 페이지 풀을 16GiB로 설정하고 2배 더 큰 크기의 파일을 사용하여 캐싱 효과를 최소화했습니다. 이 벤치마크 테스트에서는 최적의 성능을 위해 8MiB 블록을 사용했습니다. 이전 성능 테스트 섹션에는 이러한 문제에 대한 보다 자세한 설명이 있습니다. 
  다음 명령은 쓰기 및 읽기에 대한 벤치마크를 실행하는 데 사용되었으며, 여기서 Threads는 사용된 스레드 수(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 순차적 성능
  
  : 결과에서 성능이 사용된 클라이언트 수에 따라 매우 빠르게 다시 증가한 다음 이 테스트에 사용된 최대 스레드 수까지 읽기에 대해 반안정적이고 쓰기에 대해 매우 안정적인 안정기에 도달한다는 것을 알 수 있습니다. 따라서 대용량 단일 공유 파일 순차 성능은 1024개의 동시 클라이언트에서도 안정적입니다. 최대 읽기 성능은 16개 스레드에서 23.7GB/s였고 InfiniBand EDR 인터페이스에서 병목 현상이 발생했을 가능성이 매우 높습니다. 반면 ME4 어레이에는 여전히 추가 성능이 있습니다. 또한 읽기 성능은 이 값에서 감소하여 약 20.5GB/s에서 정체기에 도달할 때까지 감소했으며 128개 스레드에서 18.5GB/s로 일시적으로 감소했습니다. 마찬가지로 16개 스레드에서 최대 쓰기 성능인 16.5에 도달했는데 ME4 어레이 사양에 비해 낮은 편입니다.
   

  ---

  랜덤 작은 블록 IOzone 성능 N 클라이언트-N 파일

  랜덤 N개 클라이언트에서 N개 파일에 대한 성능은 IOzone 버전 3.487을 사용하여 측정되었습니다. 실행된 테스트는 단일 스레드에서 최대 1024개 스레드까지 다양했습니다. 이 벤치마크 테스트에서는 작은 블록 트래픽을 에뮬레이션하는 데 4KiB 블록을 사용했습니다.
  캐싱 효과는 GPFS 페이지 풀 조정 가능 매개변수를 16GiB로 설정하고 해당 크기의 두 배에 달하는 파일을 사용하여 최소화되었습니다. 첫 번째 성능 테스트 섹션에서는 이것이 GPFS에서 효과적인 이유에 대해 보다 자세히 설명합니다. 
  다음 명령은 쓰기와 읽기 모두에 대해 임의 IO 모드에서 벤치마크를 실행하는 데 사용되었으며, 여기서 Threads는 사용된 스레드 수(1에서 1024까지 2의 거듭제곱으로 증가)가 있는 변수이고 threadlist는 라운드 로빈을 사용하여 16개의 컴퓨팅 노드에 균질하게 분산하여 다른 노드에 각 스레드를 할당한 파일입니다.

  ./iozone -i2 -c -O -w -r 4K -s 32G -t $Threads -+n -+m ./threadlist

  
  그림 4:  N - N 랜덤 성능
  
  : 결과를 보면 쓰기 성능은 거의 8.2K IOPS라는 높은 값에서 시작하여 최대 128개 스레드까지 꾸준히 증가하여 정체기에 도달하고 최대 값인 16.2K IOPS에 가깝게 유지됩니다. 반면에 읽기 성능은 200 IOPS 이상에서 매우 작게 시작하여 사용된 클라이언트 수에 따라 거의 선형적으로 성능을 증가시키며(각 데이터 요소에 대해 스레드 수가 두 배가 됨) 최대값에 도달할 기미 없이 512개 스레드에서 20.4K IOPS의 최대 성능에 도달합니다. 그러나 각각 2개의 CPU가 있고 각 CPU에 18개의 코어가 있는 현재 16개의 컴퓨팅 노드에서 더 많은 스레드를 사용하면 컨텍스트 전환(16 x 2 x 18 = 576개 코어)을 발생시키지 않고 최대 IOzone 스레드 수(1024개)를 실행할 수 있는 코어가 충분하지 않아 성능이 상당히 제한됩니다. 더 많은 컴퓨팅 노드를 사용한 향후 테스트에서는 IOzone이 있는 1,024개 스레드에서 달성할 수 있는 랜덤 읽기 성능을 확인할 수 있으며, IOR을 사용하여 1,024개 이상의 스레드에서 동작을 조사할 수 있습니다.
  
   

  ---

  빈 파일을 사용한 MDtest의 메타데이터 성능

  메타데이터 성능은 16개의 컴퓨팅 노드에서 벤치마크를 실행하기 위해 OpenMPI v4.0.1의 지원을 받아 Mdtest 버전 3.3.0으로 측정되었습니다. 단일 스레드부터 최대 512개 스레드까지 다양한 테스트가 실행되었습니다. 벤치마크는 파일(디렉토리, 메타데이터 제외)에만 사용되었으며 솔루션에서 처리할 수 있는 생성, 통계, 읽기 및 제거 수를 가져옵니다.
  다른 Dell EMC HPC 스토리지 솔루션과 비교하여 솔루션을 제대로 평가하기 위해 선택 사항인 High Demand Metadata Module을 사용했지만 단일 ME4024 어레이를 사용했습니다. 대규모 구성으로 이 작업에서 테스트한 것은 ME4024를 두 개로 구성하도록 지정되었습니다. 
  이 High Demand Metadata Module은 최대 4개의 ME4024 어레이를 지원할 수 있으며, 다른 메타데이터 모듈을 추가하기 전에 ME4024 어레이의 수를 4개로 늘리는 것이 좋습니다. 추가 ME4024 어레이는 통계 작업(및 빈 파일에 대한 읽기)을 제외하고 각 추가 어레이에서 메타데이터 성능을 선형적으로 높일 것으로 예상됩니다. 수치가 매우 높기 때문에 어느 시점에서 CPU에 병목 현상이 발생하고 성능이 계속해서 선형적으로 향상되지 않기 때문입니다.
  벤치마크를 실행하는 데 다음 명령이 사용되었습니다. 여기서 Threads는 사용된 스레드 수가 포함된 변수입니다(1부터 512까지 2의 거듭제곱으로 증가). my_hosts.$Threads는 라운드 로빈을 사용하여 16개의 컴퓨팅 노드에 균일하게 분산시키는 방식으로 각 스레드를 다른 노드에 할당한 해당 파일입니다. 랜덤 IO 벤치마크와 마찬가지로 최대 스레드 수는 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 수, 디렉토리당 파일 수, 스레드 수에 의해 영향을 받을 수 있으므로, 표 3과 같이 총 파일 수를 2MiB 파일(2^21 = 2097152)로 고정하고, 디렉토리당 파일 수를 1024로 고정하고, 스레드 수가 변경됨에 따라 디렉토리 수를 변화시키기로 결정했습니다.
  
  표 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: 메타데이터 성능 - 빈 파일
  
  먼저, 선택한 스케일은 밑이 10인 로그로, 몇 자릿수의 차이가 있는 연산을 비교할 수 있습니다. 그렇지 않으면 일부 연산은 일반 그래프에서 0에 가까운 평평한 선처럼 보일 수 있습니다. 스레드 수가 2의 거듭제곱으로 증가하기 때문에 밑이 2인 로그 그래프가 더 적절할 수 있지만 그래프는 매우 비슷해 보이며 사람들은 10의 거듭제곱을 기준으로 더 나은 숫자를 처리하고 기억하는 경향이 있습니다.
  
  
  시스템은 스탯 및 읽기 작업이 각각 11.2M op/s 및 4.8M op/s로 64스레드에서 피크값에 도달하여 매우 좋은 결과를 얻습니다. 제거 작업은 16개 스레드에서 최대 169.4K op/s에 도달했고 Create 작업은 194.2K op/s로 512개 스레드에서 최대에 도달했습니다. 통계 및 읽기 작업은 가변성이 더 높지만, 최고 값에 도달하면 통계의 경우 3M op/s, 읽기의 경우 2M op/s 아래로 성능이 떨어지지 않습니다. 생성 및 제거는 안정기에 도달하면 더 안정적이며 제거의 경우 140K op/s, 생성의 경우 120K op/s 이상을 유지합니다.
   

  ---

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

  이 테스트는 빈 파일 대신 4KiB의 작은 파일이 사용되었다는 점을 제외하면 이전 테스트와 거의 동일합니다. 
  벤치마크를 실행하는 데 다음 명령이 사용되었습니다. 여기서 Threads는 사용된 스레드 수가 포함된 변수입니다(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/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)
  
  이 시스템은 통계 및 제거 작업에 대해 각각 7.7M op/s 및 1M op/s로 128스레드에서 피크 값에 도달하는 매우 좋은 결과를 얻습니다. 제거 작업은 최대 37.3K op/s에 도달했고 Create 작업은 모두 512개 스레드에서 55.5K op/s로 최고조에 도달했습니다. 스탯 및 제거 작업에는 더 많은 변동성이 있지만, 일단 피크 값에 도달하면 성능이 스탯의 경우 4M op/s, 제거의 경우 200K op/s 미만으로 떨어지지 않습니다. 생성 및 읽기는 가변성이 적고 스레드 수가 증가함에 따라 계속 늘어납니다.
  이 수치는 단일 ME4024가 있는 메타데이터 모듈에 대한 것이므로 ME4024 어레이가 추가될 때마다 성능이 향상되지만 각 작업에 대한 선형 증가를 가정할 수는 없습니다. 전체 파일이 그러한 파일의 inode 안에 맞지 않는 한, ME4084의 데이터 타겟은 4K 파일을 저장하는 데 사용되며 성능이 어느 정도 제한됩니다. Inode 크기는 4KiB이고 메타데이터를 저장해야 하기 때문에 내부에 약 3KiB의 파일만 들어갈 수 있으며 이보다 큰 파일은 데이터 타겟을 사용합니다.
   

  ---

  3K 파일에서 MDtest를 사용한 메타데이터 성능

  이 테스트는 3KiB의 작은 파일이 사용되었다는 점을 제외하고는 이전 테스트와 거의 동일합니다. 주요 차이점은 이러한 파일이 inode 내부에 완전히 맞는다는 것입니다. 따라서 스토리지 노드와 해당 ME4084가 사용되지 않습니다. 스토리지에 SSD 미디어만 사용하고 네트워크 액세스를 줄여 전반적인 속도를 향상시킵니다. 
  벤치마크를 실행하는 데 다음 명령이 사용되었습니다. 여기서 Threads는 사용된 스레드 수가 포함된 변수입니다(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/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 3K -e 3K

   

  
  그림 7: 메타데이터 성능 - 소규모 파일(3K)
  
  이 시스템은 통계 및 읽기 작업에서 매우 우수한 결과를 얻어 각각 8.29M op/s 및 5.06M op/s로 256개 스레드에서 피크 값에 도달합니다. 제거 작업은 128개 스레드에서 최대 609K op/s에 도달했으며 Create 작업은 512개 스레드에서 최대 78K op/s에 도달했습니다. 통계 및 읽기 작업은 생성 및 제거보다 변동성이 더 큽니다. 제거 시 두 개의 더 높은 스레드 포인트에서 성능이 약간 저하됩니다. 이는 128개 스레드 후 지속적인 성능이 400K op/s를 약간 넘을 것임을 시사합니다. 생성은 최대 512 스레드까지 계속 증가하지만 정체기에 도달 한 것처럼 보이므로 최대 성능은 여전히 100K op/s 미만일 수 있습니다.
  이와 같은 작은 파일은 SSD 기반 메타데이터 모듈에 완전히 저장되므로 뛰어난 소형 파일 성능이 필요한 애플리케이션에서는 하나 이상의 선택적 고수요 메타데이터 모듈을 사용하여 소형 파일의 성능을 높일 수 있습니다. 그러나 inode에 맞는 파일은 현재 표준에 따라 작습니다. 또한 메타데이터 타겟은 상대적으로 작은 SSD(최대 크기 19.2TB)와 함께 RAID1을 사용하므로 스토리지 노드에 비해 용량이 제한됩니다. 따라서 불필요한 오류 및 기타 문제를 일으킬 수 있는 메타데이터 타겟이 채워지지 않도록 주의해야 합니다.
   

  ---

  고급 분석

  PixStor 기능 중 고급 분석을 통한 파일 시스템 모니터링은 관리를 크게 간소화하여 문제 또는 잠재적 이슈를 사전 예방적 또는 사후 대응적으로 찾는 데 필수적일 수 있습니다. 다음으로, 이러한 기능 중 일부를 간략하게 살펴보겠습니다.
  그림 8은 파일 시스템 용량에 따른 유용한 정보를 보여 줍니다. 왼쪽에는 사용된 파일 시스템 총 공간과 사용된 파일 시스템 용량 기준 상위 10명의 사용자가 표시됩니다. 오른쪽에는 여러 해 동안 사용된 용량이 포함된 기간별 보기와 사용된 용량 기준 상위 10개 파일 형식 및 상위 10개 파일 세트가 Pareto 차트와 유사한 형식으로 표시됩니다(누적 합계에 대한 선 제외). 이 정보를 통해 파일 시스템에서 공정한 몫 이상을 차지하는 사용자, 향후 용량 증가에 대한 결정을 지원하는 용량 사용 추세, 대부분의 공간을 사용하는 파일 또는 대부분의 용량을 차지하는 프로젝트를 쉽게 찾을 수 있습니다.
  
  
  그림 8:  PixStor 분석 - 용량 보기
  
  그림 9에서는 문제를 찾는 데 매우 유용한 두 가지 방법을 보여 주는 파일 개수 보기를 보여 줍니다. 화면의 전반부에는 원형 차트의 상위 10명의 사용자와 상위 10개의 파일 형식 및 상위 10개의 파일 세트(예: 프로젝트)가 파레토 차트와 유사한 형식(누적 합계에 대한 선 제외)으로 표시되며, 모두 파일 수를 기준으로 합니다. 이 정보는 몇 가지 중요한 질문에 답하는 데 사용할 수 있습니다. 예를 들어, 너무 많은 파일을 생성하여 파일 시스템을 독점하는 사용자, 메타데이터 악몽을 일으키는 파일 유형 또는 대부분의 리소스를 사용하는 프로젝트.
  아래쪽 절반에는 다양한 파일 크기에 대해 5개의 범주를 사용하는 파일 크기에 대한 파일 수(빈도)가 포함된 히스토그램이 있습니다. 이는 파일 시스템 전체에서 사용되는 파일 크기에 대한 아이디어를 얻는 데 사용할 수 있으며, 파일 형식과 조정하여 압축이 유용한지 여부를 결정하는 데 사용할 수 있습니다.
  
  
  그림 9:  PixStor Analytics - 파일 개수 보기

  
  
   

  ---

  결론 및 향후 작업

  현재 솔루션은 상당히 우수한 성능을 제공할 수 있었으며, 표 4에서 볼 수 있듯이 사용된 공간(시스템이 분산 모드로 포맷되었기 때문에)에 관계없이 안정적일 것으로 예상됩니다. 또한 솔루션은 스토리지 노드 모듈이 더 추가됨에 따라 용량과 성능이 선형적으로 확장되며, High Demand Metadata Module 옵션에서도 비슷한 성능 향상을 기대할 수 있습니다. 이 솔루션은 HPC 고객에게 다수의 상위 500개 HPC 클러스터에서 사용되는 매우 안정적인 병렬 파일 시스템을 제공합니다. 또한 탁월한 검색 기능, 고급 모니터링 및 관리를 제공하며 선택적 게이트웨이를 추가하면 NFS, SMB 등과 같은 유비쿼터스 표준 프로토콜을 통해 필요한 만큼 많은 클라이언트에 파일을 공유할 수 있습니다.
  
  표 4  최고의 성능 및 지속적인 성능
  
   

  	최고 성능		지속적인 성능
  	쓰기	읽기	쓰기	읽기
  대규모 순차적 N 클라이언트-N 파일	16.7 기가바이트/s	23GB/s	16.5 기가바이트/s	20.5 기가바이트/s
  대규모 순차적 N 클라이언트-단일 공유 파일	16.5 기가바이트/s	23.8GB/s	16.2 기가바이트/s	20.5 기가바이트/s
  랜덤 작은 블록 N 클라이언트-N 파일	15.8KIOps	20.4KIOps	15.7KiOps	20.4KIOps
  메타데이터 생성 빈 파일	169.4K IOPS		127.2K IOps
  메타데이터 통계 빈 파일	1,120만 IOPS		330만 IOPS
  메타데이터 읽기 빈 파일	480만 IOPS		2.4M IOPS
  메타데이터 제거 빈 파일	194.2K IOps		144.8K IOPS
  메타데이터 생성 4KiB 파일	55.4K IOps		55.4K IOps
  메타데이터 통계 4KiB 파일	6.4M IOPS		4M IOPS
  메타데이터 읽기 4KiB 파일	37.3K IOps		37.3K IOps
  메타데이터 제거 4KiB 파일	1M IOPS		219.5K IOPS

  
  
  이 솔루션은 Cascade Lake CPU 및 더 빠른 RAM과 함께 릴리스될 예정이며 시스템의 최종 구성이 완료되면 일부 성능 부분 검사가 수행될 것입니다. 또한 데이터 타겟이 포함될 때 메타데이터 성능이 어떻게 확장되는지 자세히 문서화하기 위해 최소 2개의 ME4024 및 4KiB 파일과 함께 High Demand Metadata Module 옵션을 테스트해야 합니다. 그뿐 아니라 게이트웨이 노드의 성능은 부분 검사 결과와 함께 측정되어 새 블로그나 백서를 통해 보고됩니다. 마지막으로, 더 많은 기능을 제공하기 위해 추가 솔루션 구성 요소를 테스트하고 릴리스할 계획입니다.

  ---