「HPC BeeGFS高性能ストレージ向けDell EMC Readyソリューション（英語）」

この記事は、2019年11月にDell EMC HPCおよびAI Innovation LabのNirmala Sundararajanによって作成されました。

「HPC BeeGFS高性能ストレージ向けDell EMC Readyソリューション（英語）」

目次

1. 概要
2. ソリューションのリファレンス アーキテクチャ
3. ハードウェアおよびソフトウェアの構成
4. ソリューション構成の詳細
   • 管理サービス
   • メタデータ サービス
   • ストレージ サービス
   • クライアント サービス
5. R740xd、24x NVMeドライブ、CPUマッピングの詳細
6. パフォーマンス特性
   • シーケンシャルな読み取りおよび書き込み(N-H)
   • ランダム読み取りおよび書き込み(N-N)
7. 結論および今後の計画
    

概要

ソリューションのリファレンス アーキテクチャ

ハードウェアおよびソフトウェアの構成

表1および2では、管理サーバーとメタデータ/ストレージ サーバーのハードウェア仕様についてそれぞれ説明しています。表3では、ソリューションに使用されるソフトウェア バージョンについて説明しています。

ソリューション構成の詳細

• 管理サービス
• メタデータ サービス
• ストレージ サービス
• クライアント サービス

管理サービス

メタデータ サービス

図3： メタデータ サーバー

図4は、メタデータ サーバーのRAID構成を示しています。ここでは、メタデータ サーバーで、どのようにNUMAゾーン0のドライブがMDTをホストし、NUMAゾーン1のドライブがストレージ データをホストし、またストレージ サーバーが両方のNUMAゾーンでSTをホストするかが分かります。

ストレージ サービス

1. ライト パフォーマンスは、ddコマンドを使用して、1MiBブロック長の10GiBファイルとデータ用のダイレクトI/Oを作成することによって測定されました。RAID 0デバイスの平均は各デバイスに対して約5.1 GB/秒でしたが、RAID 10デバイスの平均は各デバイスに対して3.4GB/秒でした。
2. StorageBenchベンチマーク テストでは、RAID 0構成では最大スループットが5.5 GB/秒、RAID 10構成では3.4 GB/秒でした。これらの結果は、ddコマンドを使用して取得されたものと似ています。
3. RAID 10では、ディスク容量の使用率が50%で、ライト パフォーマンスが約50%削減されます。RAID 10の使用は、ストレージの冗長性を得るためには高価な方法です。
4. NVMeドライブは高価なうえ、RAID 0構成で最適に使用される速度を提供します。

クライアント サービス

$ cat /etc/beegfs/beegfs-mounts.conf
/mnt/beegfs-medium /etc/beegfs/beegfs-client-medium.conf
/mnt/beegfs-small /etc/beegfs/beegfs-client-small.conf

R740xd、24x NVMeドライブ、CPUマッピングの詳細

# cat /proc/sys/kernel/numa_balancing
0

パフォーマンス特性

シーケンシャルな書き込みおよび読み取り(N-N)

シーケンシャルな読み取りおよび書き込みを評価するため、IOzoneベンチマークがシーケンシャルな読み取りおよび書き込みモードで使用されました。これらのテストは、1つのスレッドから、2の累乗（最大1024スレッド）で増加する複数のスレッド数に対して実施されました。このテストでは、スレッドあたり1つのファイル、またはNクライアント - Nファイル(N-N)の場合に作動するため、各スレッド数では同じ数のファイルが生成されました。プロセスが、ラウンド ロビンまたは循環式で32個の物理クライアント ノードに分散されるため、リクエストが均等に分散され、ロード バランシングが行われます。8TBの合計ファイル サイズが選択され、特定のテスト内のスレッド数に均等に分けられました。合計ファイル サイズは、サーバーとBeeGFSクライアントからのキャッシュの影響を最小限に抑えるのに十分な大きさが選択されました。IOzoneは、操作間の境界を調整できるように、書き込みおよび読み取り（-i 0、-i 1）の組み合わせモードで実行されました。このテストと結果では、実行ごとに1MiBのレコード サイズを使用しました。シーケンシャルなN-Nテストに使用されたコマンドは次のとおりです。

Sequential Writes and Reads: iozone -i 0 -i 1 -c -e -w -r 1m -I -s $Size -t $Thread -+n -+m /path/to/threadlist

また、OSキャッシュは、次のコマンドを実行して、反復の間、および書き込みテストと読み取りテストの間にクライアント ノードでドロップまたはクリーニングされました。

# sync&echo 3 > /proc/sys/vm/drop_caches

Beegfsのデフォルトのストライプ数は4です。ただし、ファイルあたりのチャンク サイズとターゲット数は、ディレクトリー単位で構成できます。これらすべてのテストでは、BeeGFSストライプ サイズは2MBで、ストライプ数は3で選択されました。これは、次に示すようにNUMAゾーンごとに3つのターゲットがあるためです。

$ beegfs-ctl --getentryinfo --mount=/mnt/beegfs /mnt/beegfs/benchmark --verbose
EntryID: 0-5D9BA1BC-1
ParentID: root
Metadata node: node001-numa0-4 [ID: 4]
Stripe pattern details:
+ Type: RAID0
+ Chunksize: 2M
+ Number of storage targets: desired: 3
+ Storage Pool: 1 (Default)
Inode hash path: 7/5E/0-5D9BA1BC-1

透過的な大きなページが無効になり、次のチューニング オプションがメタデータ サーバーとストレージ サーバーに配置されました。

• vm.dirty_background_ratio = 5 
• vm.dirty_ratio = 20 
• vm.min_free_kbytes = 262144 
• vm.vfs_cache_pressure = 50
• vm.zone_reclaim_mode = 2 
• kernel.numa_balancing = 0

上記に加えて、次のBeeGFSチューニング オプションが使用されました。 

• tuneTargetChooserパラメーターがメタデータ構成ファイルで「roundrobin」に設定されました。 
• tuneNumWorkersパラメーターがメタデータの場合は24、ストレージの場合は32に設定されました。 
• connMaxInternodeNumパラメーターがメタデータの場合は32、ストレージの場合は12、クライアントの場合は24に設定されました。

図9では、ピーク リード パフォーマンスが1024スレッドで132 GB/秒、ピーク ライト パフォーマンスが256スレッドで121 GB/秒であることが分かります。各ドライブは、3.2 GB/秒のピーク リード パフォーマンスと1.3 GB/秒のピーク ライト パフォーマンスを実現できます。これにより、理論上のピークは読み取りで422 GB/秒、書き込みで172 GB/秒となります。ただし、ここではネットワークが制限要因です。セットアップには、ストレージ サーバー用にInfiniBand EDRリンクが合計11個あります。各リンクは、理論上12.4 GB/秒のピーク パフォーマンスを提供できるため、これにより理論上136.4 GB/秒のピーク パフォーマンスが可能です。達成したピーク リード パフォーマンスおよびライト パフォーマンスは、理論上のピーク パフォーマンスのそれぞれ97%と89%です。

1つのスレッドのライト パフォーマンスは最大3 GB/秒で、読み取りは最大3 GB/秒であることが確認されています。ライト パフォーマンスは直線的に向上し、ピークは256スレッドで、その後減少し始めます。スレッド数が少ない場合、リード パフォーマンスとライト パフォーマンスは同じです。8スレッドになるまで、8つのクライアントが24のターゲットに対して8つのファイルを書き込むため、すべてのストレージ ターゲットが完全に使用されているわけではありません。システムには33のストレージ ターゲットがあるため、すべてのサーバーを完全に活用するには、少なくとも11個のスレッドが必要です。リード パフォーマンスは、同時スレッド数の増加に伴って直線的に向上し、512スレッドと1024スレッドでほぼ同様のパフォーマンスとなることが確認されています。

また、リード パフォーマンスは16～128のスレッド数でのライト パフォーマンスよりも低くなりますが、その後リード パフォーマンスは上がり始めることも確認されています。これは、PCIe読み取り操作はRequestとCompletionの両方を必要とするNon-Postedタイプの操作となりますが、PCIe書き込み操作は「ファイア アンド フォーゲット」タイプの操作となるためです。トランザクション レイヤー パケットがデータ リンク レイヤーに渡されると、操作は完了します。書き込み処理は、リクエストのみで構成される「Posted」操作です。

読み取りスループットは通常、同じ量のデータに対して1回の書き込みではなく2つのトランザクションを必要とするため、書き込みスループットよりも低くなります。PCI Expressは、読み取りに分割トランザクション モデルを使用します。読み取りトランザクションには、次の手順が含まれます。

• Requesterは、メモリー読み取り要求(MRR)を送信します。
• Completerは、確認応答をMRRに送信します。
• Completerは、データを含むCompletionを返します。

読み取りスループットは、読み取り要求が発行されるまでの時間と、Completerがデータを返すのにかかる時間の間の遅延によって異なります。ただし、アプリケーションがこの遅延をカバーするのに十分な数の読み取り要求を発行すると、スループットが最大化されます。そのため、リード パフォーマンスは16～128スレッドのライト パフォーマンスよりも低くなりますが、要求の数が増加するとスループットが向上します。  後続のリクエストを発行する前にRequesterがCompletionを待機すると、スループットが低下します。最初のデータが返された後の遅延をカバーするために複数のリクエストが発行されると、より高いスループットが登録されます。

ランダム書き込みおよび読み取り(N-N)

ランダムIOパフォーマンスを評価するため、IOzoneがランダム モードで使用されました。テストは、4スレッドから最大1024スレッドまでのスレッド数に対して実施されました。IOzoneの実行には、すべての操作がバッファ キャッシュをバイパスしてディスクに直接移動できるように、ダイレクトIOオプション(-I)が使用されました。BeeGFSストライプ数は3で、チャンク サイズは2MBが使用されました。IOzoneでは、4KiBのリクエスト サイズが使用されます。パフォーマンスは、1秒あたりのI/O操作数(IOPS)で測定されます。OSキャッシュは、BeeGFSサーバーとBeeGFSクライアント上での実行の間にドロップされました。ランダム書き込みと読み取りを実行するために使用されたコマンドは、次のとおりです。

Random reads and writes: iozone -i 2 -w -c -O -I -r 4K -s $Size -t $Thread -+n -+m /path/to/threadlist

図10：  IOzoneを使用したランダム読み取り/書き込みパフォーマンス（8TB合計ファイル サイズ使用）

図10に示すように、ランダム書き込みのピークは512スレッドで最大360万IOPS、ランダム読み取りピークは1024スレッドで最大350万IOPSです。ライト パフォーマンスとリード パフォーマンスの両方で、IO要求の数が多い場合に、より高いパフォーマンスを示しています。これは、NVMe標準では、キューあたり最大64KのI/Oキューと最大64Kのコマンドをサポートするためです。このNVMeキューの大規模なプールは、より高いレベルのI/O並列化を提供するため、IOPSが300万を超えています。

結論および今後の計画

このブログでは、Dell EMCハイ パフォーマンスBeeGFSストレージ ソリューションのリリースについてお知らせし、そのパフォーマンス特性について説明します。このソリューションでは、最大132 GB/秒と最大121 GB/秒のシーケンシャルな読み取り/書き込みパフォーマンスを実現し、ランダム書き込みのピークは最大360万IOPS、ランダム読み取りは最大350万IOPSです。

このブログは、『BeeGFS Storage Solution』の第一部であり、ハイ パフォーマンスのスクラッチ領域に重点を置いて設計されています。このブログ シリーズの第二部では、パフォーマンスと容量を向上させるためにサーバーの数を増やすことでソリューションを拡張する方法について説明します。このブログ シリーズの第三部では、BeeGFSの追加機能について説明し、BeeGFSの組み込み型ストレージ ターゲット ベンチマークである「StorageBench」の使用方法について詳しく説明します。

次のステップの一環として、メタデータ パフォーマンス、Nスレッド - 1ファイルのIORパフォーマンス、および設計に関する考慮事項、チューニング、構成についての詳細を含むホワイト ペーパーを公開する予定です。

リファレンス