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

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

目次

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

概要

Dell HPCチームは、HPCストレージ ポートフォリオに最新追加された「HPC BeeGFSストレージ向けDell EMC Ready Solutions」のリリースを発表します。このソリューションでは、R740xdサーバーを使用し、それぞれに24台のインテルP4600 1.6TB NVMe混在使用Express Flashドライブ、および2個のMellanox ConnectX-5 InfiniBand EDRアダプターが搭載されています。この24台のNVMeドライブ構成では、12台のNVMe SSDがPCIeスイッチに接続され、各スイッチはx16 PCIeエクステンダー カードを使用して1台のCPUに接続されます。さらに、各IBインターフェイスは1台のCPUに接続されます。各CPUを1つのInfiniBandアダプターに接続し、12台のNVMe SSDを処理するこのようなバランスの取れた構成では、NVMeドライブとの間のI/O要求の処理でプロセッサーが均等に占有されるようにすることで、最大限のパフォーマンスを提供します

このソリューションの焦点は高性能I/Oであり、高速スクラッチ ソリューションとして設計されています。このソリューションの中核となるのは、ブロック レイヤーから スケジューラーとキューイングのボトルネック を取り除くことで、高帯域幅と低レイテンシーを実現する高速NVMe SSDの使用です。BeeGFSファイル システムは、高い集約I/Oスループットもサポートします。

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

図1は、ソリューションのリファレンス アーキテクチャを示しています。管理サーバーは、Ethernetを使用してメタデータ サーバーとストレージ サーバーにのみ接続されます。各メタデータ サーバーとストレージ サーバーには2つのInfiniBandリンクがあり、Ethernet経由でプライベート ネットワークに接続されています。クライアントには1つのInfiniBandリンクがあり、Ethernet経由でプライベート インターフェイスに接続されています。

図1:  Dell Ready Solutions for HPC BeeGFS Storage - リファレンス アーキテクチャ

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

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

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

BeeGFSアーキテクチャは、次の4つの主要なサービスで構成されています。

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

カーネル モジュールであるクライアント サービスを除き、管理、メタデータ、ストレージ サービスはユーザー空間プロセスです。図2では、HPC BeeGFSストレージ向けDell EMC Ready Solutionsのリファレンス アーキテクチャが、BeeGFSファイル システムの一般的なアーキテクチャとどのようにマッピングされるかを示しています。

図2：  NVMe SSDを搭載したPowerEdge R740xd上のBeeGFSファイル システム

管理サービス

各BeeGFSファイル システムまたはネームスペースには、管理サービスが1つだけ含まれています。管理サービスは、最初にセットアップする必要があるサービスです。他のすべてのサービスを構成するときは、管理サービスに登録する必要があるためです。PowerEdge R640が、管理サーバーとして使用されます。管理サービス(beegfs-mgmtd.service)をホストするだけでなく、システムから統計情報を収集し、時系列データベースInfluxDBを使用してそれらをユーザーに提供するモニタリング サービス(beegfs-mon.service)もホストします。データを可視化するために、beegfs-monは、すぐに使用できる事前定義済みのGrafanaペインを提供します。管理サーバーには、オペレーティング システムおよびInfiluxDB用にRAID 10に300GB HDDが6台搭載されています。

メタデータ サービス

メタデータ サービスは、スケールアウト サービスです。つまり、BeeGFSファイル システムには多くのメタデータ サービスが存在する可能性があります。ただし、各メタデータ サービスがメタデータを格納するメタデータ ターゲットは、1つのみです。メタデータ ターゲットで、BeeGFSはユーザーが作成したファイルごとに1つのメタデータ ファイルを作成します。BeeGFSメタデータは、ディレクトリーごとに分散されます。メタデータ サービスは、クライアントにデータ ストライピング情報を提供し、ファイルのオープン/クローズ間のデータ アクセスには関与しません。

24台のインテルP4600 1.6TB NVMeを搭載したPowerEdge R740xdは、メタデータ ストレージ用にドライブが使用されます。BeeGFSメタデータのストレージ容量要件は非常に小さいため、専用のメタデータ サーバーを使用する代わりに、NUMAゾーン0の12台のドライブのみがメタデータT引数(MDT)のホストに使用され、残りの12台のドライブはNUMAゾーン ホストSストレージT引数(ST)のホストに使用されました。

図3は、メタデータ サーバーを示しています。黄色の長方形で囲まれた12台のドライブはNUMAゾーン0のMDTです。一方、緑色の長方形で囲まれた12台のドライブはNUMAゾーン1のSTです。この構成により、NUMAの問題が回避できるだけでなく、必要に応じて容量とパフォーマンスを拡張するのに十分なメタデータ ストレージも提供されます。

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

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

図4：  メタデータ サーバーでのドライブの構成

メタデータに使用される12台のドライブは、それぞれがMDTとして機能する2台のドライブからなる6x RAID 1ディスク グループとして構成されます。それぞれが1つのMDTを処理する6つのメタデータ サービスが実行されています。残りの12台のストレージ ドライブは、それぞれ4台のドライブからなる3つのRAID 0ディスク グループで構成されます。NUMA 1ゾーンでは3つのストレージ サービスが実行されており、各STに対して1つのサービスが実行されています。したがって、メタデータとストレージ ターゲットを共同ホストするサーバーには、6つのMDTと3つのSTがあります。また、6つのメタデータ サービスと3つのストレージ サービスも実行します。各MDTは、RAID 1構成に基づくext4ファイル システムです。STは、RAID 0で構成されたXFSファイル システムに基づいています。
 

ストレージ サービス

メタデータ サービスと同様に、ストレージ サービスもスケールアウト サービスです。BeeGFSファイル システムには、ストレージ サービスのインスタンスが多数存在する可能性があります。ただし、メタデータ サービスとは異なり、ストレージ サービスごとに複数のストレージ ターゲットが存在する可能性があります。ストレージ サービスは、ストライピングされたユーザー ファイルのコンテンツ(データ チャンク ファイルとも呼ばれます)を格納します

図5は、ストレージ サーバーとして使用される5台のPowerEdge R740xdサーバーを示しています。

図5:  専用ストレージ サーバー

各ストレージ サーバーは、それぞれ4台のドライブに搭載された6つのRAID 0グループで構成され、次の図6に示すように、サーバーあたり6つのST(NUMAゾーンごとに3つ)をホストします。

図6:  ストレージ サーバー内のドライブの構成

合計で、基本リファレンス アーキテクチャ構成は6つのMDTと33のSTをホストします。5台の専用ストレージ サーバーを使用すると、raw容量は211 TB、有効容量は190TiBになります。推定有効容量(TiB) = ドライブ数 x ドライブあたりの容量(TB) x 0.99（ファイル システムのオーバーヘッド） x (10^12/2^40)。これは、容量要件の増加に応じてストレージ サーバーを追加するのに十分なメタデータ ストレージを備えたミッドレンジ スクラッチ ソリューションとして理想的です。

次の要因を考慮して、RAID 10構成よりも、ストレージ ターゲットとしてRAID 0構成が選択されました。

1. ライト パフォーマンスは、ddコマンドを使用して、1MBブロック サイズの10GBファイルを作成し、データ用のダイレクト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構成での使用に最適な速度を提供します

クライアント サービス

BeeGFSクライアント モジュールは、BeeGFSsファイル システムにアクセスする必要があるすべてのホストにロードする必要があります。beegfs-clientがロードされると、/etc/fstabに基づく通常のアプローチではなく、/etc/beegfs/beegfs-mounts.confファイルで定義されているファイルシステムがマウントされます。このアプローチを採用すると、他のLinuxサービスと同様に、サービス起動スクリプトを介してbeegfs-clientが開始されます。また、システムのアップデート後に、BeeGFSクライアント モジュールを自動的に再コンパイルすることもできます。

クライアント モジュールがロードされると、 beegfs-mounts.confで定義されているファイル システムがマウントされます。以下に示すように、同じクライアントに複数のbeegfsインスタンスをマウントできます。

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

上の例では、同じクライアントに2つの異なるファイル システムがマウントされています。このテストでは、32個のC6420ノードがクライアントとして使用されました。

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

24 NVMe構成のPowerEdge R740xdサーバーでは、次の図7に示すように、バックプレーン上にPCIeスイッチを供給する2枚のx16 NVMeブリッジ カードがあります。これはファンアウトし、前面のドライブ（4台のドライブ）にフィードします。


図7：  R740xd、24x NVMe、CPUマッピングの詳細

Non-Uniform Memory Access (NUMA)では、システム メモリーはノードと呼ばれるゾーンに分割され、CPUまたはソケットに割り当てられます。CPUにローカルなメモリーへのアクセスは、システム上のリモートCPUに接続されているメモリーへのアクセスよりも高速です。スレッド アプリケーションは通常、スレッドが同じNUMAノード上のメモリーにアクセスする場合に最適なパフォーマンスを発揮します。NUMAのミスによるパフォーマンス インパクトは大きく、通常は10%以上のパフォーマンス ヒットが発生します。パフォーマンスを向上させるために、サービスは特定のNUMAゾーンを使用するように構成され、不要なUPIクロス ソケット リンクの使用を回避してレイテンシーを削減します。各NUMAゾーンは12台のドライブを処理し、サーバー上の2つのInfiniBand EDRインターフェイスのいずれかを使用します。このNUMAの分離は、カスタムsystemdユニット ファイルを作成し、マルチホーミングを構成して、手動でNUMAバランシングを構成することによって実現されます。したがって、次に示すように、自動NUMAバランシングは無効になります。

# cat /proc/sys/kernel/numa_balancing
0

図8はテストベッドを示しており、NUMAゾーンへのInfiniBand接続がハイライトされています。各サーバーには 2 つの IP リンクがあり、NUMA 0 ゾーンを通過するトラフィックはインターフェイス IB0 によって渡され、NUMA 1 ゾーンを通過するトラフィックはインターフェイス IB1 によって処理されます

図8:  テストベッドの構成
 

パフォーマンス特性

このセクションでは、HPC BeeGFSハイパフォーマンス ストレージ ソリューション向けDell EMC Ready Solutionの特性評価に役立つパフォーマンス評価について説明します。詳細とアップデートについては、後で公開されるホワイト ペーパーを参照してください。システム パフォーマンスは、IOzoneベンチマークを使用して評価されました。このソリューションは、シーケンシャルな読み取り/書き込みスループット、ランダム読み取り/書き込みIOPSについてテストされています。表4は、このブログのパフォーマンス調査でBeeGFSクライアントとして使用されたC6420サーバーの構成について説明しています。
 

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

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

シーケンシャルな書き込みと読み取り: 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です。ただし、ファイルあたりのチャンク サイズとターゲット数は、ディレクトリー単位で構成できます。これらすべてのテストでは、次に示すように、NUMAゾーンごとに3つのターゲットがあるため、BeeGFSストライプ サイズは2MB、ストライプ数は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：  シーケンシャルIOzone 8TBの総ファイル サイズ。

図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クライアントでの実行の間にドロップされました。ランダム書き込みと読み取りの実行に使用されるコマンドを次に示します。

ランダム読み取りおよび書き込み: 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』の第一部であり、ハイ パフォーマンスのスクラッチ領域に重点を置いて設計されています。このブログ シリーズの第二部では、パフォーマンスと容量を向上させるためにサーバーの数を増やすことでソリューションを拡張する方法について説明します。このブログ シリーズの第3部では、BeeGFSの追加機能について説明し、BeeGFSの組み込みストレージ ターゲット ベンチマークである「StorageBench」の使用に焦点を当てます

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

リファレンス

[1] BeeGFSドキュメント:  https://www.beegfs.io/wiki/
[2] 『How to connect two interfaces on the same subnet』：  https://access.redhat.com/solutions/30564