「HPC PixStorストレージ向けDell EMC Readyソリューション - 容量拡張（英語）」

なし

目次

1. 概要
   1. ソリューション アーキテクチャ
   2. ソリューション コンポーネント
2. パフォーマンス特性
   1. シーケンシャルIOゾーン パフォーマンスNクライアントからN個のファイルへ
   2. シーケンシャルIORパフォーマンスNクライアントから1ファイル
   3. ランダムな小さなブロック IOzone Performance NクライアントからN個のファイル
   4. 空のファイルを使用したMDtestによるメタデータのパフォーマンス
   5. 4つのKiBファイルを使用したMDtestによるメタデータパフォーマンス
3. 結論および今後の計画

 

---

概要

今日のHPC環境では、NFS、SMBなどのいくつかの標準プロトコルを介した大容量と分散アクセスも頻繁に必要とする、非常に高速なストレージに対する需要が高まっています。このような要求の厳しいHPC要件は、通常、単一のファイルまたは複数のノードからの一連のファイルへのコンカレント アクセスを提供し、複数のサーバー間で複数のLUNにデータを非常に効率的かつ安全に分散する並列ファイル システムによってカバーされます。

 

---

ソリューション アーキテクチャ

このブログは、HPC環境向けの継続的な並列ファイル システム(PFS)ソリューションであるDellEMC Ready Solution for HPC PixStor Storageです。PowerVault ME484 EBODアレイは、ソリューションの容量を増やすために使用されます。図1 は、既存のPowerVault ME4084ストレージ アレイへの容量拡張SASの追加を示すリファレンス アーキテクチャを示しています。
PixStorソリューションには、PFSコンポーネントとしてスペクトラム スケールとも呼ばれる広範な一般的な並列ファイル システムが含まれています。さらに、高度な分析、シンプルな管理とモニタリング、効率的なファイル検索、高度なゲートウェイ機能などの多くのArcastreamソフトウェア コンポーネントが含まれています。


図1: リファレンス アーキテクチャ。

 

---

ソリューション コンポーネント

このソリューションは、最新のインテルXeon第2世代スケーラブルXeon CPU(別名Cascade Lake CPU)とともにリリースされる予定です。一部のサーバーは、使用可能な最速のRAM(2933 MT/s)を使用します。ただし、現在のハードウェアはパフォーマンスを特徴づけるソリューションのプロトタイプで動作するため、インテルXeon第1世代スケーラブルXeon CPUを搭載したサーバーは別名です。Skylakeプロセッサーと、場合によっては低速のRAMを使用して、このシステムの特徴を説明しました。ソリューションのボトルネックはDellEMC PowerVault ME40x4アレイのSASコントローラーにあります。Skylake CPUとRAMを想定されたCascade Lake CPUと高速RAMに置き換えると、大きなパフォーマンスの差は予想されません。さらに、このソリューションは、システムの特徴を示すためにRHEL 7.7および OFED 4.7をサポートする PixStor(5.1.1.4)の最新バージョンにアップデートされました。

前述の状況のため、表1にはソリューションの主要コンポーネントのリストが記載されていますが、不一致が発生した場合、最初の説明列にはリリース時に使用されるコンポーネントがあるため、お客様が使用できます。最後の列は、ソリューションのパフォーマンスを特徴付けるために実際に使用されるコンポーネントです。データ(12TB NLS)およびメタデータ(960Gb SSD)にリストされているドライブは、パフォーマンス特性評価に使用されるドライブであり、より高速なドライブは、より優れたランダムIOPSを提供し、メタデータの作成/削除操作を向上させることができます。

最後に、完全性のために、可能なデータHDDとメタデータSSDのリストが含まれていました。これは、オンラインで利用可能なDellEMC PowerVault ME4サポート マトリックスで列挙されたドライブに基づいています。

表1 リリース時に使用されるコンポーネントとテスト ベッドで使用されるコンポーネント

ソリューション コンポーネント		リリース時	テスト ベッド
内部接続		Dell Networking S3048-ONギガビット イーサネット
データ ストレージ サブシステム		Dell EMC PowerVault ME4084 x 1~4 Dell EMC PowerVault ME484 x 1~4(ME4084あたり1) 80~12TB 3.5インチNL SAS3 HDDドライブ オプション900GB @15K、 1.2TB@10K、1.8TB@10K、2.4TB@10K、 4TB NLS、8TB NLS、10TB NLS、12TB NLS。     8 LUN、リニア8+2 RAID 6、チャンク サイズ512KiB。 メタデータ用の1.92TB SAS3 SSD x 4 – RAID 1 x 2(またはオプションの高需要メタデータ モジュールを使用する場合はグローバルHDDスペア x 4)
High Demandメタデータ ストレージ サブシステム(オプション)		Dell EMC PowerVault ME4024 x 1~2(必要に応じてME4024 x 4、大規模構成のみ) 24 x 960GB 2.5インチSSD SAS3ドライブ(オプション480GB、960GB、1.92TB) 12 LUN、リニアRAID 1。
RAID ストレージコントローラ		12 Gbps SAS
構成済みの容量		生：8064 TB(7334 TiBまたは7.16 PiB)フォーマット:最大6144 GB(5588 TiBまたは5.46 PiB)
CPU	ゲートウェイ	インテルXeon Gold 6230 2.1G、20C/40T、10.4GT/秒、27.5Mキャッシュ、ターボ、HT(125W)DDR4-2933 x 2	なし
	高需要メタデータ		2 x インテルXeon Gold 6136 @ 3.0 GHz、12コア
	ストレージ ノード		2 x インテルXeon Gold 6136 @ 3.0 GHz、12コア
	管理ノード	インテルXeon Gold 5220 2.2G、18C/36T、10.4GT/s、24.75Mキャッシュ、ターボ、HT(125W)DDR4-2666 x 2	インテルXeon Gold 5118 @ 2.30GHz x 2、12コア
メモリー	ゲートウェイ	12x 16GiB 2933 MT/s RDIMM(192 GiB)	なし
	高需要メタデータ		24x 16GiB 2666 MT/s RDIMM(384 GiB)
	ストレージ ノード		24x 16GiB 2666 MT/s RDIMM(384 GiB)
	管理ノード	16 GB DIMM x 12、2666 MT/s(192GiB)	12 x 8GiB 2666 MT/s RDIMM(96 GiB)
オペレーティングシステム		Red Hat Enterprise Linux 7.6	Red Hat Enterprise Linux 7.7
カーネル バージョン		3.10.0-957.12.2.el7.x86_64	3.10.0-1062.9.1.el7.x86_64
PixStorソフトウェア		5.1.0.0	5.1.1.4
Spectrum Scale(GPFS)		5.0.3	5.0.4-2
ハイ パフォーマンス ネットワーク接続		Mellanox ConnectX-5デュアルポートInfiniBand EDR/100 GbE、および10 GbE	Mellanox ConnectX-5 InfiniBand EDR
ハイ パフォーマンス スイッチ		Mellanox SB7800 x 2(HA – 冗長)	Mellanox SB7700 x 1
OFEDのバージョン		Mellanox OFED-4.6-1.0.1.0	Mellanox OFED-4.7-3.2.9
ローカル ディスク(OS & 分析/監視)		管理ノードを除くすべてのサーバー OS用480GB SSD SAS3(RAID1 + HS)x 3 PERC H730P RAIDコントローラー 管理ノード OS用480GB SSD SAS3(RAID1 + HS)x 3 PERC H740P RAIDコントローラー	管理ノードを除くすべてのサーバー OS用300GB 15K SAS3(RAID 1)x 2 PERC H330 RAIDコントローラー 管理ノード OS用300GB 15K SAS3(RAID 5)x 5 & 分析/監視 PERC H740P RAIDコントローラー
システム管理		iDRAC 9 Enterprise + DellEMC OpenManage	iDRAC 9 Enterprise + DellEMC OpenManage

 

---

パフォーマンス特性

この新しいReady Solutionの特徴を説明するために、オプションのHigh Demandメタデータ モジュールを含む、表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
クライアント ノードあたりのプロセッサー数	2 x インテル(R) Xeon(R) Gold E5-2697v4 18コア @ 2.30GHz
クライアント ノードあたりのメモリー	16GiB 2400 MT/s RDIMM x 12
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スレッドまで実行されたテストは異なり、容量拡張ソリューション(4x ME4084s + 4x ME484s)の結果は、大規模なソリューション(4x ME4084s)とは対照的です。キャッシュ効果は、調整可能なGPFSページ プールを16GiBに設定し、その2倍のサイズのファイルを使用することで最小限に抑えられました。GPFSで調整可能な場合は、取り付けられているRAMの量や空き容量に関係なく、データのキャッシュに使用されるメモリーの最大量が設定されていることに注意してください。また、以前のDell EMC HPCソリューションでは、大規模なシーケンシャル転送のブロック 長は1 MiBでしたが、GPFSは8 MiBブロックでフォーマットされているため、最適なパフォーマンスを得るためにベンチマークでその値が使用されていることに注意してください。見た目が大きすぎて、スペースが無駄になる可能性がありますが、GPFSはサブブロック割り当てを使用して状況を回避します。現在の構成では、各ブロックはそれぞれ32 KiBの256サブブロックに分割されました。

次のコマンドを使用して、書き込みと読み取りのベンチマークを実行しました。ここで、Threadsは使用されるスレッド数(2乗で1~1024増分)の変数であり、スレッドリストは、ラウンド ロビンを使用して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のコンカレント クライアントでも大規模なファイルシーケンシャル パフォーマンスが安定しています。読み取りと書き込みの両方のパフォーマンスは、ドライブ数が2倍に増えるというメリットがあることに注意してください。最大読み取りパフォーマンスは、8スレッドから始まるストレージ ノードで使用される2つのIB EDRリンクの帯域幅によって制限され、ME4アレイには追加のパフォーマンスが使用可能な場合があります。同様に、最大書き込みパフォーマンスが64スレッドと128スレッドで最大16.7 GB/秒から20.4 GB/秒に増加し、ME4アレイの最大仕様(22 GB/秒)

に近づいていることに注意してください。ここでは、GPFSの優先動作モードが散在し、ソリューションがそのようなモードを使用するようにフォーマットされていることを覚えておくことが重要です。このモードでは、動作開始時から仮想ランダムにブロックが割り当てられ、各HDDの全表面にデータが分散されます。明らかなデメリットは、初期の最大パフォーマンスが小さいことですが、ファイル システムで使用されているスペースの量に関係なく、そのパフォーマンスはかなり一定に維持されます。これは、ディスク革命あたりより多くのデータ(セクター)を保持できる外側のトラックを最初に使用する他の並列ファイル システムとは対照的に、HDDが提供できる最高のパフォーマンスを備えていますが、システムがより多くのスペースを使用すると、革命あたりのデータが少ない内部トラックが使用され、パフォーマンスが低下します。

 

---

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

単一の共有ファイル パフォーマンスに対するシーケンシャルNクライアントは、IORバージョン3.3.0で測定され、OpenMPI v4.0.1によって16個のコンピューティング ノード上でベンチマークを実行しました。テストの実行は、1スレッドから最大512スレッドまでさまざまでした(1024スレッドに十分なコアがないため)。結果は容量拡張なしでソリューションと対照的です。
キャッシュ効果は、調整可能なGPFSページ プールを16GiBに設定し、その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 to 1 シーケンシャル パフォーマンス

結果から、追加のドライブが読み取り/書き込みパフォーマンスにメリットをもたらすことが再度確認できます。パフォーマンスは、使用されているクライアントの数によって再び非常に高速に向上し、このテストで使用されるスレッドの最大数まで、読み取りと書き込みに対してかなり安定している台地に達します。最大読み取りパフォーマンスは16スレッドで24.8 GB/秒で、ボトルネックはInfiniBand EDRインターフェイスでした。ME4アレイでは引き続き追加のパフォーマンスが利用できます。その時点から、読み取りパフォーマンスは、その値から約23.8 GB/秒で高所に到達するまで低下しました。同様に、19.3の最大書き込みパフォーマンスは8スレッドに達し、高いレベルに達していることに注意してください。
 

---

ランダムな小さなブロック IOzone Performance NクライアントからN個のファイル

ランダムNクライアントからNファイルへのパフォーマンスは、従来のIozoneではなくFIOバージョン3.7で測定されました。前のブログに記載されているように、ME4084アレイが提供できる最大限のパフォーマンスを調査するために、より大きなキューの深さを活用することを目的としています(ME4084アレイの以前のテストでは、ME4084アレイでは、ランダムIO制限に達するためにIozoneが提供できるより多くのIO負荷が必要でした)。

1024スレッドに対して十分なクライアント コアがないため、テストは1つのスレッドから最大512スレッドまでさまざまでした。各スレッドは異なるファイルを使用しており、スレッドはクライアント ノードでラウンド ロビンに割り当てられています。このベンチマーク テストでは、4つのKiBブロックを使用して、小さなブロック トラフィックをエミュレートし、キューの深さ16を使用しました。大規模なソリューションと容量拡張の結果を比較します。

GPFSページ プールを調整可能な16GiBに設定し、そのサイズの2倍のファイルを使用することで、キャッシュ効果が再び最小化されました。最初のパフォーマンス テストのセクションでは、GPFSでこれが有効である理由について詳しく説明します。


図4：  NからNランダム パフォーマンス

書き込みパフォーマンスは29.1K IOpsの高い値から始まり、最大64スレッドまで着実に上昇し、約40,000 IOpsで上昇しているように見えます。一方、読み取りパフォーマンスは1.4K IOpsから始まり、使用されるクライアントの数によってほぼ直線的にパフォーマンスが向上します(各データ ポイントでスレッド数が2倍になることに注意してください)。また、64スレッドで25.6K IOPSの最大パフォーマンスに達します。この場合は、高台に近いと思われます。より多くのスレッドを使用するには、リソースの枯渇を回避するために、16個を超えるコンピューティング ノードと、アレイが実際にパフォーマンスを維持できる明らかなパフォーマンスの低下を回避する必要があります。

 

---

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

メタデータのパフォーマンスは、MDtestバージョン3.3.0で測定されました。OpenMPI v4.0.1によってサポートされ、16個のコンピューティング ノードでベンチマークを実行しました。実行されたテストは、1つのスレッドから最大512スレッドまでさまざまです。ベンチマークはファイル(ディレクトリ メタデータなし)にのみ使用され、ソリューションで処理できる作成数、統計数、読み取り/削除数を取得し、結果は大きなサイズのソリューションと比較しました。

他のDellEMC HPCストレージ ソリューションと以前のブログの結果と比較してソリューションを適切に評価するために、オプションのHigh Demandメタデータ モジュールが使用されましたが、この作業で大規模な構成とテストが2つのME4024sに指定されている場合でも、単一の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

パフォーマンスの結果は、IOPSの合計数、ディレクトリーあたりのファイル数、スレッド数によって影響を受ける可能性があるため、ファイルの合計数を2 MiBファイル(2^21 = 2097152)、1024で修正されたディレクトリーあたりのファイル数、スレッド数の変更に応じて変更したディレクトリーの数を、表3に示すように修正しておくことが決定されました。

表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のべき乗に基づいてより優れた数値を処理して記憶する傾向があります。
システムは、統計と読み取り操作がそれぞれ約1100万ops/秒と470万opsの64スレッドでピーク値に達すると、非常に優れた結果を得ることができます。削除操作は、16スレッドで最大170.6K op/sを達成し、作成操作は222.1K op/sで32スレッドでピークを達成しました。統計と読み取り操作の変動性は高くなりますが、ピーク値に達すると、パフォーマンスは統計の場合は300万ops、読み取りでは2M op/sを下回りません。作成と削除は、落ち着いてから安定し、削除の場合は140,000 OP/秒を超え、作成では120,000 OP/秒を超えます。余分なドライブは、空のファイルに対するほとんどのメタデータ操作に予想どおりに影響しないことに注意してください。
 

---

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/btl_openib_allow_ib 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)

システムは、統計操作と削除操作がそれぞれ8.2M op/sと400K op/sで256スレッドでピーク値に達した場合に非常に優れた結果を得ます。読み取り操作は最大44.8K op/sを達成し、Create操作は、両方とも512スレッドで68.1K op/sでピークを達成しました。統計と取り外しの操作は変動性が高くなりますが、ピーク値に達すると、パフォーマンスは統計の場合は300万ops、削除では28万ops未満に低下しません。作成と読み取りの変動が少なく、スレッドの数が増えるにつれて増え続けます。ご確認のように、容量拡張の追加ドライブは、メタデータのパフォーマンスにわずかな変化しか与えません。
これらの数値は単一のME4024を持つメタデータ モジュール向けであるため、追加のME4024アレイごとにパフォーマンスが向上しますが、各操作の直線的な増加を想定することはできません。このようなファイルのinode内にファイル全体が収まる場合を除き、ME4084s上のデータ ターゲットは4Kファイルの格納に使用され、パフォーマンスがある程度制限されます。inodeサイズは4KiBで、メタデータを保存する必要があるため、内部には3 KiB前後のファイルのみが収まり、それ以上のファイルはデータ ターゲットを使用します。
 

---

結論および今後の計画

容量が拡張されたソリューションは、ランダム アクセスだけでなく、シーケンシャル パフォーマンスでもパフォーマンスを向上させることができました。分散モードはランダムアクセスとして動作し、より多くのディスクを使用することで改善が可能になるため、これは予想されていました。表4で概要を説明できるこのパフォーマンスは、空のファイル システムからほぼ満杯になるまで安定していることが期待されています。さらに、ストレージ ノード モジュールが追加されると、ソリューションの容量とパフォーマンスが直線的に拡張され、オプションの高需要メタデータ モジュールでも同様のパフォーマンスの向上が期待できます。このソリューションは、HPCのお客様に、多くの上位500のHPCクラスターで使用される非常に信頼性の高い並列ファイル システムを提供します。さらに、卓越した検索機能、高度なモニタリングと管理を提供し、オプションのゲートウェイを追加することで、NFS、SMBなどのユビキタス標準プロトコルを介して必要な数のクライアントにファイルを共有できます。

表4  ピーク時と持続的なパフォーマンス

	ピーク時のパフォーマンス		継続的なパフォーマンス
	書き込み	読み取り	書き込み	読み取り
Nファイルへの大規模なシーケンシャルNクライアント	20.4 GB/秒	24.2 GB/秒	20.3 GB/秒	24 GB/秒
単一の共有ファイルへの大規模なシーケンシャルNクライアント	19.3 GB/秒	24.8 GB/秒	19.3 GB/秒	23.8 GB/秒
ランダムな小さなブロック N個のクライアントからN個のファイルへ	40KIOps	25.6KIOps	40.0KIOps	19.3KIOps
メタデータ 空のファイルの作成	169.4K IOps		123.5K IOps
メタデータ統計の空のファイル	1,100万IOps		320万IOps
メタデータ 空のファイルの読み取り	470万IOps		240万IOps
メタデータ 空のファイルの削除	170.6K IOps		156.5K IOps
メタデータ 4KiBファイルの作成	68.1K IOps		68.1K IOps
メタデータ統計4KiBファイル	820万IOps		300万IOps
メタデータ 4KiBファイルの読み取り	44.8K IOps		44.8K IOps
メタデータ 4KiBファイルの削除	40万IOps		28万IOps

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