Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products

Dell EMC Ready Solution for HPC PixStor Storage

Summary: 솔루션을 위한 레퍼런스 아키텍처와 초기 성능 평가를 제공합니다.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

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

Cause

.

Resolution

목차

  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. 결론 및 향후 작업


 


소개

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

 

솔루션 아키텍처

이 블로그에서는 HPC 환경을 위한 PFS(Parallel File System) 솔루션에 Dell EMC의 최신 제품인 Dell EMC Ready Solution for HPC PixStor Storage를 소개합니다. 그림 1은 Dell EMC PowerEdge R740 서버와 PowerVault ME4084 및 ME4024 스토리지 어레이를 활용하는 레퍼런스 아키텍처와 파트너 회사인 ArcastreamPixStor 소프트웨어를 보여줍니다.
PixStor에는 고급 분석, 간소화된 관리 및 모니터링, 효율적인 파일 검색, 고급 게이트웨이 기능 등과 같은 Arcastream 소프트웨어 구성 요소 외에도 PFS 구성 요소로 Spectrum Scale이라고도 하는 광범위한 일반 병렬 파일 시스템이 포함되어 있습니다.

SLN318841_en_US__1image(11979년)
그림 1 : 레퍼런스 아키텍처

 

솔루션 구성 요소

이 솔루션은 Cascade Lake CPU라고도 하는 최신 인텔 제온 2세대 스케일러블 제온 CPU와 함께 릴리스될 예정이며 일부 서버는 현재 사용 가능한 가장 빠른 RAM(2933MT/s)을 사용합니다. 그러나 솔루션의 프로토타입을 만들고 성능을 특성화하는 데 사용할 수 있는 하드웨어로 인해 인텔 제온 1세대 스케일러블 제온 CPU가 탑재된 서버는 Skylake 프로세서와 더 느린 RAM이 사용되었습니다. Dell EMC PowerVault ME40x4 어레이의 SAS 컨트롤러에서 솔루션의 병목 현상이 발생하기 때문에 Skylake CPU 및 RAM을 원래 Cascade Lake CPU와 더 빠른 RAM으로 교체하더라도 성능 차이는 크지 않을 것으로 예상됩니다. 또한 시스템 구성 당시 RHEL 7.6을 지원하는 최신 버전의 PixStor를 사용할 수 있었음에도 불구하고 QA 프로세스를 계속하고 시스템 특성을 특성화하기 위해 Red Hat® Enterprise Linux® 7.5 및 이전 마이너 버전의 PixStor를 사용하기로 결정했습니다. 시스템이 Cascade Lake CPU로 업데이트되면 PixStor 소프트웨어도 최신 버전으로 업데이트되고 성능이 이 문서에 보고된 수치에 가깝게 유지되는지 확인하기 위해 일부 성능 스폿 점검이 수행됩니다.

앞서 설명한 상황으로 인해 표 1 에는 솔루션의 기본 구성 요소 목록이 있습니다. 중간 열에는 릴리스 시점에 사용되어 고객이 사용할 수 있도록 계획된 구성 요소가 있고, 마지막 열에는 솔루션의 성능을 특성화하는 데 실제로 사용되는 구성 요소 목록이 있습니다. 나열된 드라이브 또는 데이터(12TB NLS) 및 메타데이터(960Gb SSD)는 성능 특성화에 사용되며, 드라이브가 빠를수록 더 나은 임의 IOPS를 제공하고 메타데이터 생성/제거 작업을 개선할 수 있습니다.

마지막으로, 완전성을 기하기 위해 온라인에서 사용 가능한 Dell EMC PowerVault ME4 Support Matrix에 명시된 대로 지원되는 드라이브를 기반으로 가능한 데이터 HDD 및 메타데이터 SSD 목록이 포함되었습니다.

표 1 릴리스 시 사용할 구성 요소와 테스트 베드에서 사용되는 구성 요소

SLN318841_en_US__2image(12041)
 

성능 특성화

이 새로운 Ready Solution의 특징을 나타내기 위해 선택 사항인 High Demand Metadata Module을 포함하여 표 1의 마지막 열에 명시된 하드웨어를 사용했습니다. 솔루션 성능을 평가하기 위해 사용된 벤치마크는 다음과 같습니다.

 
  •     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

    SLN318841_en_US__3image(11984년)
    그림 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

    SLN318841_en_US__4image(11985년)

    그림 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

    SLN318841_en_US__5image(11987년)
    그림 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




    SLN318841_en_US__6image(11988년)
    그림 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

    SLN318841_en_US__7image(11989년)
    그림 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

     

    SLN318841_en_US__8image(11990년)
    그림 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 차트와 유사한 형식으로 표시됩니다(누적 합계에 대한 선 제외). 이 정보를 통해 파일 시스템에서 공정한 몫 이상을 차지하는 사용자, 향후 용량 증가에 대한 결정을 지원하는 용량 사용 추세, 대부분의 공간을 사용하는 파일 또는 대부분의 용량을 차지하는 프로젝트를 쉽게 찾을 수 있습니다.

    SLN318841_en_US__9image(11993년)
    그림 8:  PixStor 분석 - 용량 보기

    그림 9에서는 문제를 찾는 데 매우 유용한 두 가지 방법을 보여 주는 파일 개수 보기를 보여 줍니다. 화면의 전반부에는 원형 차트의 상위 10명의 사용자와 상위 10개의 파일 형식 및 상위 10개의 파일 세트(예: 프로젝트)가 파레토 차트와 유사한 형식(누적 합계에 대한 선 제외)으로 표시되며, 모두 파일 수를 기준으로 합니다. 이 정보는 몇 가지 중요한 질문에 답하는 데 사용할 수 있습니다. 예를 들어, 너무 많은 파일을 생성하여 파일 시스템을 독점하는 사용자, 메타데이터 악몽을 일으키는 파일 유형 또는 대부분의 리소스를 사용하는 프로젝트.
    아래쪽 절반에는 다양한 파일 크기에 대해 5개의 범주를 사용하는 파일 크기에 대한 파일 수(빈도)가 포함된 히스토그램이 있습니다. 이는 파일 시스템 전체에서 사용되는 파일 크기에 대한 아이디어를 얻는 데 사용할 수 있으며, 파일 형식과 조정하여 압축이 유용한지 여부를 결정하는 데 사용할 수 있습니다.

    SLN318841_en_US__10image(11994년)
    그림 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 옵션을 테스트해야 합니다. 그뿐 아니라 게이트웨이 노드의 성능은 부분 검사 결과와 함께 측정되어 새 블로그나 백서를 통해 보고됩니다. 마지막으로, 더 많은 기능을 제공하기 위해 추가 솔루션 구성 요소를 테스트하고 릴리스할 계획입니다.


     

Affected Products

High Performance Computing Solution Resources, Dell EMC PowerVault ME4012, Dell EMC PowerVault ME4024, Dell EMC PowerVault ME4084
Article Properties
Article Number: 000130962
Article Type: Solution
Last Modified: 23 Sep 2024
Version:  6
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.