HPC PixStorストレージ向けDell EMC Readyソリューション

HPCおよびAIイノベーション ラボのMario Gallegosが2019年10月に執筆した記事

目次

1. 概要
   1. ソリューション アーキテクチャ
   2. ソリューション コンポーネント
2. パフォーマンス特性
   1. シーケンシャルIOゾーン パフォーマンス - NクライアントからNファイル
   2. シーケンシャルIORパフォーマンス - Nクライアントから1ファイル
   3. 小さなブロックを使用したIOzoneランダム パフォーマンス - NクライアントからNファイル
   4. 空のファイルを使用したMDtestによるメタデータ パフォーマンス
   5. 4 KiBファイルを使用した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
  クライアント ノードあたりのプロセッサー数	2 インテル(R) Xeon(R) Gold E5-2697v4 18コア @ 2.30GHz
  クライアント ノードあたりのメモリー	12 16GiB 2400 MT/s RDIMM
  BIOS	2.8.0
  OSカーネル	3.10.0-957.10.1
  GPFSのバージョン	5.0.3

   

  ---

  シーケンシャルIOゾーン パフォーマンス - NクライアントからNファイル

  NクライアントからNファイルへのシーケンシャル パフォーマンスは、IOzoneバージョン3.487で測定されました。実行されたテストは、1 つのスレッドから最大 1024 スレッドまでさまざまです。
  キャッシュ効果は、16GiBに調整可能なGPFSページ プールを設定し、その2倍のサイズのファイルを使用した場合に、最小限に抑えられました。GPFS の場合、その tunable は、インストールされている RAM の量と空き容量に関係なく、データのキャッシングに使用されるメモリーの最大量を設定することに注意することが重要です。また、以前のDell EMC HPCソリューションでは、大規模なシーケンシャル転送のブロック サイズは1 MiBですが、GPFSは8 MiBブロックでフォーマットされていたため、その値がベンチマークで使用され、最適なパフォーマンスが得られることに注意することが重要です。容量が大きすぎて、スペースが無駄になる可能性がありますが、GPFSはサブブロック割り当てを使用して状況を回避します。現在の構成では、各ブロックはそれぞれ 32 KiB の 256 個のサブブロックに分割されていました。
  次のコマンドを使用して、書き込みと読み取りのベンチマークを実行しました。ここで、Threadsは使用されたスレッド数(2の累乗で1から1024まで増分)を含む変数であり、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スレッドで23 GB/秒であり、ボトルネックはInfiniBand EDRインターフェイスである可能性が非常に高いことに注意してください。一方、ME4アレイには追加のパフォーマンスがまだ使用可能でした。同様に、最大ライト パフォーマンス16.7は16スレッドで少し早く到達しており、ME4アレイの仕様と比較して明らかに低いことに注意してください。
  ここで重要なのは、GPFS 優先操作モードが分散していること、およびそれを使用するようにソリューションがフォーマットされていることです。このモードでは、ブロックは最初から疑似ランダム方式で割り当てられ、各HDDの表面全体にデータが分散されます。明らかなデメリットは、初期の最大パフォーマンスが小さくなることですが、ファイル システムで使用されているスペースの量に関係なく、そのパフォーマンスはかなり一定に維持されます。これは、ディスク レボリューションあたりより多くのデータ（セクター）を保持できる外部のトラックを最初に使用する他の並列ファイル システムとは対照的に、HDDが提供できる最高のパフォーマンスを備えていますが、システムがより多くのスペースを使用するため、レボリューションあたりのデータがより少ない内部トラックが使用され、パフォーマンスが低下します。 
  
   

  ---

  シーケンシャルIORパフォーマンス - Nクライアントから1ファイル

  Nクライアントから単一の共有ファイルへのシーケンシャル パフォーマンスは、IORバージョン3.3.0を使用して測定されました。また、OpenMPI v4.0.1によるアシストにより、16個のコンピューティング ノード上でベンチマークを実行しました。実行されたテストは、単一スレッドから最大1024スレッドまでさまざまです。
  キャッシュ効果は、16GiBに調整可能なGPFSページ プールを設定し、その2倍のサイズのファイルを使用した場合に、最小限に抑えられました。このベンチマーク テストでは、最適なパフォーマンスを実現するために8 MiBブロックを使用しました。これらの事項については、前のパフォーマンス テストのセクションで詳しく説明しています。
  次のコマンドを使用して、書き込みと読み取りのベンチマークを実行しました。ここで、Threadsは使用されたスレッド数(2の累乗で1から1024まで増分)を含む変数であり、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.7 GB/秒でした。ボトルネックはInfiniBand EDRインターフェイスである可能性が非常に高いですが、ME4アレイには追加のパフォーマンスがまだ使用可能でした。さらに、読み取りパフォーマンスは、約20.5 GB/秒でプラトーに達するまでその値から低下し、128スレッドで18.5 GB/秒に一時的に低下しました。同様に、最大ライト パフォーマンス16.5は16スレッドで達成されており、ME4アレイの仕様と比較すると明らかに低いことに注意してください。
   

  ---

  小さなブロックを使用したIOzoneランダム パフォーマンス - NクライアントからNファイル

  ランダムNクライアントからNファイルへのパフォーマンスは、IOzoneバージョン3.487で測定されました。実行されたテストは、単一スレッドから最大1024スレッドまでさまざまです。このベンチマーク テストでは、小さなブロック トラフィックをエミュレートするために4 KiBのブロックを使用しました。
  キャッシング効果は、GPFS ページ・プール・チューナブルを 16GiB に設定し、その 2 倍のサイズのファイルを使用することで最小限に抑えられました。最初のパフォーマンス テストのセクションでは、GPFSでこれが有効である理由について詳しく説明しています。
  次のコマンドを使用して、書き込みと読み取りの両方に対してランダムIOモードでベンチマークを実行しました。ここで、Threadsは使用されたスレッド数(2の累乗で1から1024まで増分)の変数で、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を超える非常に小さい値から始まり、使用されるクライアントの数にほぼ比例してパフォーマンスを向上させ(各データ ポイントのスレッド数が2倍になることに注意してください)、512スレッドで最大パフォーマンスの20.4K IOPSに達しますが、最大値に達する兆候はありません。ただし、それぞれ 2 つの CPU を搭載し、各 CPU に 18 コアがある現在の 16 個のコンピューティング ノードでより多くのスレッドを使用すると、コンテキスト切り替え (16 x 2 x 18 = 576 コア) を発生させずに最大数の IOzone スレッド (1024) を実行するのに十分なコアがないという制限があり、パフォーマンスが大幅に制限されます。コンピューティング ノードを増やした今後のテストでは、IOzoneを使用して1024スレッドで達成できるランダム読み取りパフォーマンスを確認したり、IORを使用して1024スレッドを超える動作を調査したりできます。
  
   

  ---

  空のファイルを使用したMDtestによるメタデータ パフォーマンス

  メタデータのパフォーマンスは、MDtestバージョン3.3.0で測定されました。また、OpenMPI v4.0.1のアシストにより、16個のコンピューティング ノード上でベンチマークを実行しました。テストは、1つのスレッドから最大512スレッドで実行されました。ベンチマークはファイルのみ(ディレクトリーのメタデータなし)に使用され、ソリューションが処理できる作成、統計、読み取り、削除の数を取得しました。
  このソリューションを他のDell EMC HPCストレージ ソリューションと比較して適切に評価するために、オプションの高需要メタデータ モジュールを使用しました。ただし、1台のME4024アレイを使用し、この作業でテストした大規模構成では2台のME4024を指定するようにしました。
  このハイ デマンド メタデータ モジュールは、最大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

  
  パフォーマンスの結果は、IOPの総数、ディレクトリーあたりのファイル数、スレッド数によって影響を受ける可能性があるため、表3に示すように、ファイルの総数を2 MiBファイル(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 の累乗に基づいてより良い数値を処理し、記憶する傾向があります。
  
  
  このシステムでは、Stat操作とRead操作がそれぞれ11.2M op/sと4.8M op/sで64スレッドのピーク値に達し、非常に良い結果が得られています。削除操作は16スレッドで最大169.4K op/sを達成し、作成操作は194.2K op/sで512スレッドでピークに達しました。統計操作と読み取り操作での変動性は高いですが、ピーク値に達すると、その後パフォーマンスは、統計の場合は300万op/s、読み取りの場合は200万op/sを下回ることはありません。作成と削除は、プラトーに達するとより安定し、削除の場合は140K op/s、作成の場合は120K op/sを超える状態が維持されます。
   

  ---

  4 KiBファイルを使用した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)
  
  このシステムでは、Stat操作とRemoval操作で非常に良好な結果が得られ、それぞれ7.7M op/sと1M op/sで128スレッドのピーク値に達しています。削除操作は最大37.3K op/秒、作成操作は55.5K op/秒でピークに達しました(いずれも512スレッド)。統計と除去操作のばらつきは大きくなりますが、ピーク値に達すると、パフォーマンスは統計で4M op/s、削除で200K op/sを下回ることはありません。作成と読み取りでは変動が少なく、スレッドの数が増えるにつれて上昇し続けます。
  これらの数値は単一のME4024を搭載したメタデータ モジュールの場合であるため、ME4024アレイを追加するごとにパフォーマンスは向上しますが、各操作で直線的に増加すると想定することはできません。このようなファイルのinode内にファイル全体が収まる場合を除き、ME4084上のデータ ターゲットは4Kファイルの格納に使用され、パフォーマンスがある程度制限されます。inodeサイズは4KiBですが、メタデータを保存する必要があるため、内部には3 KiB前後のファイルのみを格納し、それ以上のファイルはデータ ターゲットを使用します。
   

  ---

  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を達成し、作成操作は512スレッドで78K op/sでピークに達しました。統計操作と読み取り操作は、作成と削除よりも変動性が大きくなります。削除により、上位2つのスレッド ポイントのパフォーマンスがわずかに低下し、128スレッド後の持続的なパフォーマンスが400K op/sをわずかに超えることが示唆されます。Createは最大512スレッドまで増加し続けましたが、頭打ちになっているように見えるため、最大パフォーマンスはまだ100K op/s未満である可能性があります。
  このような小容量ファイルはSSDベースのメタデータ モジュールに完全に格納されるため、小容量ファイルの優れたパフォーマンスを必要とするアプリケーションでは、1つ以上のオプションの高負荷メタデータ モジュールを使用して小容量ファイルのパフォーマンスを向上させることができます。ただし、inodeに収まるファイルは、現在の基準では小さいものです。また、メタデータ ターゲットは比較的小さい(最大サイズ19.2TB)SSDを搭載したRAID1を使用するため、ストレージ ノードと比較すると容量は制限されます。そのため、メタデータ ターゲットがいっぱいにならないように注意する必要があります。メタデータ ターゲットがいっぱいになると、不要な障害やその他の問題が発生するおそれがあります。
   

  ---

  高度な分析

  PixStorの機能の中でも、高度な分析を使用してファイル システムを監視することは、管理を大幅に簡素化し、問題や潜在的な問題をプロアクティブまたはリアクティブに発見するために不可欠です。次に、これらの機能の一部について簡単に説明します。
  図8は、ファイル システムの容量に基づく有用な情報を示しています。左側には、ファイル システムの使用済み領域の合計と、使用済みファイル システムの容量に基づく上位10人のユーザーが表示されます。右側には、長年にわたる使用済み容量の履歴ビュー、使用された容量に基づく上位10個のファイル タイプと上位10個のファイルセットが、パレート図に似た形式(累積合計の線なし)で表示されます。この情報を使用して、ファイル システムの公平なシェアを超える値を得ているユーザー、容量使用率のトレンドを簡単に見つけることができ、容量の将来の増加に関する決定に役立ちます。また、容量の大部分を使用しているファイルや、容量の大部分を占めているプロジェクトもどれかを確認できます。
  
  
  図8：  PixStor Analytics - 容量ビュー
  
  図 9 は、問題を見つけるための 2 つの非常に便利な方法を備えたファイル数ビューを示しています。画面の前半には、上位 10 人のユーザーが円グラフで表示され、上位 10 個のファイル タイプと上位 10 個のファイルセット (プロジェクトなど) がパレート図に似た形式 (累積合計の線なし) で表示され、すべてファイル数に基づいています。この情報は、いくつかの重要な質問に答えるために使用できます。たとえば、作成しすぎるファイルによってファイル システムを独占しているユーザー、メタデータの悪夢を生み出しているファイルのタイプ、リソースの大部分を使用しているプロジェクトなどです。
  下半分には、ファイルサイズごとに5つのカテゴリを使用したファイルサイズごとのファイル数(頻度)のヒストグラムがあります。これは、ファイル システム全体で使用されているファイル サイズを把握するために使用でき、ファイル タイプと連携して圧縮が有益かどうかを判断するために使用できます。
  
  
  図9：  PixStor Analytics - ファイル数ビュー

  
  
   

  ---

  結論および今後の計画

  現在のソリューションは、 表4に示すように、使用スペースに関係なく安定して動作することが見込めます(システムが分散モードでフォーマットされているため)。さらに、ストレージ ノード モジュールが追加されると、ソリューションの容量とパフォーマンスが直線的に拡張され、オプションのハイ デマンド メタデータ モジュールでも同様のパフォーマンスの向上が期待できます。このソリューションは、HPCのお客様に、多くの上位500のHPCクラスターで使用される非常に信頼性の高い並列ファイル システムを提供します。さらに、卓越した検索機能、高度なモニタリングと管理を備え、オプションのゲートウェイを追加することで、NFSやSMBなどのユビキタス標準プロトコルを介して、必要な数のクライアントとファイルを共有できます。
  
  表 4  ピーク時および持続的なパフォーマンス
  
   

  	ピーク時のパフォーマンス		継続的なパフォーマンス
  	書き込み	読み取り	書き込み	読み取り
  大規模 - シーケンシャル - NクライアントからNファイル	16.7 GB/秒	23 GB/秒	16.5 GB/秒	20.5 GB/秒
  大規模 - シーケンシャル - Nクライアントから単一の共有ファイル	16.5 GB/秒	23.8 GB/s	16.2 GB/秒	20.5 GB/秒
  ランダム - 小さなブロック - NクライアントからNファイル	15.8キログラフ	20.4Kアップ	15,700キロ秒	20.4Kアップ
  メタデータ - 作成 - 空のファイル	169.4K IOps		127.2,000 IOPS
  メタデータ - 統計 - 空のファイル	1,120万IOPS		330万IOPS
  メタデータ - 読み取り - 空のファイル	480万IOPS		2.4M IOps
  メタデータ - 削除 - 空のファイル	194.2K IOPS		144.8K IOps
  メタデータ - 作成 - 4KiBファイル	55,400 IOPS		55,400 IOPS
  メタデータ - 統計 - 4KiBファイル	640万IOPS		400万IOPS
  メタデータ - 読み取り - 4KiBファイル	37.3千のIOPS		37.3千のIOPS
  メタデータ - 削除 4KiBファイル	100万IOps		219.5千IOPS

  
  
  このソリューションは、Cascade Lake CPUとより高速なRAMを搭載してリリースされる予定であるため、システムが最終的な構成になると、パフォーマンスのスポットチェックが実行されます。また、少なくとも2台のME4024と4KiBファイルを使用して、オプションのハイ デマンド メタデータ モジュールをテストし、データ ターゲットが関連する場合にメタデータのパフォーマンスがどのように拡張されるかをより的確に文書化する必要があります。さらに、ゲートウェイ ノードのパフォーマンスが測定され、スポット チェックからの関連する結果とともに、新しいブログまたはホワイト ペーパーで報告されます。最後に、さらに多くの機能を提供するために、より多くのソリューション コンポーネントをテストおよびリリースする予定です。

  ---