このページでは、複数のクライアント仮想マシンから単一の Google Cloud NetApp Volumes ボリュームが受けるパフォーマンスの制限値を示します。このページの情報を使用して、ワークロードのサイズを決定してください。
パフォーマンス テスト
以下のテスト結果は、性能限界を示しています。これらのテストでは、データ転送量がベンチマークテストに影響を与えないよう、十分な容量が確保されています。以下のスループット値を超えて単一ボリュームの容量を割り当てても、それ以上のパフォーマンス向上は得られません。
なお、パフォーマンステストは Fio を使用して実施されました。
性能テストの結果については、以下の点にご注意ください。
標準、プレミアム、エクストリームのサービスレベルは、上限に達するまで、処理能力に応じてスループットを拡張します。Flex のすべてのサービスレベルはストレージプールの性能に応じて拡張され、プール内のすべてのボリュームはプールのパフォーマンスを共有します。
カスタムパフォーマンスを備えた Flex Unified および Flex File サービスレベルでは、容量、IOPS、およびスループットを個別にスケーリングできます。
IOPS の結果はあくまで参考情報です。
以下の結果を得るために使用された数値は、最大の結果を示すように設定されています。以下の結果は、達成可能な最大スループット容量の推定値として捉えるべきである。
プロジェクトごとに複数の高速ボリュームを使用する場合、プロジェクトごとの制限が適用される場合があります。
以下の性能テスト結果は、NFSv3、SMB、および iSCSI プロトコルのみを対象としています。NetApp Volumes のパフォーマンステストには、NFSv4.1 などの他のプロトコルタイプは使用されませんでした。
NFSv3 アクセスにおけるボリュームスループット制限
以下のセクションでは、NFSv3 アクセスにおけるボリュームスループット制限の詳細について説明します。
カスタムパフォーマンスを備えた Flex File サービスレベル
以下のテストは、Flex カスタムパフォーマンスゾーンストレージプール内の単一ボリュームを使用して実行されました。プールは最大スループットと最大 IOPS で構成され、その結果が記録された。
64 KiB のブロックサイズ(シーケンシャル I/O)
これらの結果は、次の設定で Fio を使用して取得されました。
64 KiB のブロックサイズで、6 つの単一ボリュームに対応
n2-standard-32仮想マシンRed Hat 9 OS
各仮想マシンにつき 96 GiB のワーキングセット、合計 576 GiB
nconnect各ホストでマウントオプションが値 16 に設定されています65536 で設定された
rsizeおよびwsizeマウント オプションボリュームサイズは、カスタムパフォーマンス付きの Flex サービスレベルの 10TiB でした。テストのため、カスタムパフォーマンスは最大値である 5,120 MiBps と 160,000 IOPS に設定されました。
Fio は、各仮想マシンで 8 つのジョブを実行し、合計 48 個のジョブを実行しました。以下の表は、NFSv3 上で 64 KiB のブロックサイズを使用した場合、単一のボリュームが約 4,300 MiBps の純粋なシーケンシャル読み取りと 1,480 MiBps の純粋なシーケンシャル書き込みを処理できると推定されることを示しています。
NFS 64 KiB シーケンシャル 6 n2-standard-32 Red Hat 9 VM のベンチマーク結果
| 読み取り 100%、書き込み 0% | 75% が読み、25% が書く | 50%が読み書き | 25% が読み、75% が書く | 読み取り 0%、書き込み 100% | |
|---|---|---|---|---|---|
| MiBps を読み取る | 4,304 | 2,963 | 1,345 | 464 | 0 |
| MiBps を書き込む | 0 | 989 | 1,344 | 1,390 | 1,476 |
8 KiB ブロックサイズ(ランダム I/O)
これらの結果は、次の設定で Fio を使用して取得されました。
6 台の
n2-standard-32仮想マシンを含む単一ボリュームに対する 8 KiB ブロックサイズRed Hat 9 OS
各仮想マシンにつき 96 GiB のワーキングセット、合計 576 GiB
nconnect各ホストでマウントオプションが値 16 に設定されていますrsizeそしてwsize各ホストのマウントオプションは 65536 に設定されていますボリュームサイズは、カスタムパフォーマンス付きの Flex サービスレベルの 10TiB でした。テストのため、カスタムパフォーマンスは最大値である 5,120 MiBps と 160,000 IOPS に設定されました。
Fio は、各仮想マシンで 8 つのジョブを実行し、合計 48 個のジョブを実行しました。以下の表は、NFSv3 上で 8 KiB のブロックサイズを使用した場合、単一のボリュームで約 126,400 の純粋なランダム読み取り IOPS と 78,600 の純粋なランダム書き込み IOPS を処理できると推定されることを示しています。
NFS 8 KiB ランダム 6 n2-standard-32 Red Hat 9 VM のベンチマーク結果
| 読み取り 100%、書き込み 0% | 75% が読み、25% が書く | 50%が読み書き | 25% が読み、75% が書く | 読み取り 0%、書き込み 100% | |
|---|---|---|---|---|---|
| 読み取り IOPS | 126,397 | 101,740 | 57,223 | 23,600 | 0 |
| 書き込み IOPS | 0 | 33,916 | 57,217 | 70,751 | 78,582 |
極めて高いサービスレベル
以下のテストは、Extreme ストレージプール内の単一ボリュームを使用して実行され、結果が記録されました。
64 KiB のブロックサイズ(シーケンシャル I/O)
これらの結果は、次の設定で Fio を使用して取得されました。
64 KiB のブロックサイズで、6 つの単一ボリュームに対応
n2-standard-32仮想マシンRed Hat 9 OS
各仮想マシンにつき 1 TiB のワーキングセット、合計 6 TiB
nconnect各ホストでマウントオプションが値 16 に設定されていますボリューム サイズは Extreme サービスレベルの 75 TiB でした
Fio は、各仮想マシンで 8 つのジョブを実行し、合計 48 個のジョブを実行しました。以下の表は、NFSv3 上で 64 KiB のブロックサイズを使用した場合、単一のボリュームが約 5,240 MiBps の純粋なシーケンシャル読み取りと約 2,180 MiBps の純粋なシーケンシャル書き込みを処理できると推定されることを示しています。
NFS 64 KiB シーケンシャル 6 n2-standard-32 Red Hat 9 VM のベンチマーク結果
| 読み取り 100%、書き込み 0% | 75% が読み、25% が書く | 50%が読み書き | 25% が読み、75% が書く | 読み取り 0%、書き込み 100% | |
|---|---|---|---|---|---|
| MiBps を読み取る | 5,237 | 2,284 | 1,415 | 610 | 0 |
| MiBps を書き込む | 0 | 764 | 1,416 | 1,835 | 2,172 |
256 KiB のブロックサイズ(シーケンシャル I/O)
これらの結果は、次の設定で Fio を使用して取得されました。
256 KiB のブロックサイズで、6 つの単一ボリュームに対応
n2-standard-32仮想マシンRed Hat 9 OS
各仮想マシンにつき 1 TiB のワーキングセット、合計 6 TiB
nconnect各ホストでマウントオプションが値 16 に設定されていますボリューム サイズは Extreme サービスレベルの 75 TiB でした
Fio は、各仮想マシンで 8 つのジョブを実行し、合計 48 個のジョブを実行しました。以下の表は、NFSv3 上で 256 KiB のブロックサイズを使用した場合、単一のボリュームが約 4,930 MiBps の純粋なシーケンシャル読み取りと約 2,440 MiBps の純粋なシーケンシャル書き込みを処理できると推定されることを示しています。
NFS 256 KiB シーケンシャル 6 n2-standard-32 Red Hat 9 VM のベンチマーク結果
| 読み取り 100%、書き込み 0% | 75% が読み、25% が書く | 50%が読み書き | 25% が読み、75% が書く | 読み取り 0%、書き込み 100% | |
|---|---|---|---|---|---|
| MiBps を読み取る | 4,928 | 2,522 | 1,638 | 677 | 0 |
| MiBps を書き込む | 0 | 839 | 1,640 | 2,036 | 2,440 |
4 KiB ブロックサイズ(ランダム I/O)
これらの結果は、次の設定で Fio を使用して取得されました。
6 台の
n2-standard-32仮想マシンを含む単一ボリュームに対する 4 KiB のブロックサイズRed Hat 9 OS
各仮想マシンにつき 1 TiB のワーキングセット、合計 6 TiB
nconnect各ホストでマウントオプションが値 16 に設定されていますボリューム サイズは Extreme サービスレベルの 75 TiB でした
Fio は、各仮想マシンで 8 つのジョブを実行し、合計 48 個のジョブを実行しました。次の表は、NFSv3 経由で 4 KiB のブロックサイズを使用した場合、1 つのボリュームで約 380,000 の純粋なランダム読み取り IOPS と約 120,000 の純粋なランダム書き込み IOPS を処理できることを示しています。
NFS 4 KiB ランダム 6 n2-standard-32 Red Hat 9 VM のベンチマーク結果
| 読み取り 100%、書き込み 0% | 75% が読み、25% が書く | 50%が読み書き | 25% が読み、75% が書く | 読み取り 0%、書き込み 100% | |
|---|---|---|---|---|---|
| 読み取り IOPS | 380,000 | 172,000 | 79,800 | 32,000 | 0 |
| 書き込み IOPS | 0 | 57,300 | 79,800 | 96,200 | 118,000 |
8 KiB ブロックサイズ(ランダム I/O)
これらの結果は、次の設定で Fio を使用して取得されました。
6 台の
n2-standard-32仮想マシンを含む単一ボリュームに対する 8 KiB ブロックサイズRed Hat 9 OS
各仮想マシンにつき 1 TiB のワーキングセット、合計 6 TiB
nconnect各ホストでマウントオプションが値 16 に設定されていますボリューム サイズは Extreme サービスレベルの 75 TiB でした
Fio は、各仮想マシンで 8 つのジョブを実行し、合計 48 個のジョブを実行しました。次の表は、NFSv3 上で 8 KiB のブロックサイズを使用した場合、単一のボリュームが約 270,000 の純粋なランダム読み取り IOPS と約 110,000 の純粋なランダム書き込み IOPS を処理できると推定されることを示しています。
NFS 8 KiB ランダム 6 n2-standard-32 Red Hat 9 VM のベンチマーク結果
| 読み取り 100%、書き込み 0% | 75% が読み、25% が書く | 50%が読み書き | 25% が読み、75% が書く | 読み取り 0%、書き込み 100% | |
|---|---|---|---|---|---|
| 読み取り IOPS | 26 万 5000 人 | 132,000 | 66,900 | 30,200 | 0 |
| 書き込み IOPS | 0 | 44,100 | 66,900 | 90,500 | 104,000 |
SMB アクセスにおけるボリュームスループット制限
以下のセクションでは、SMB アクセスにおけるボリュームスループット制限の詳細について説明します。
64 KiB のブロックサイズ(シーケンシャル I/O)
これらの結果は、次の設定で Fio を使用して取得されました。
64 KiB のブロックサイズで、6 つの単一ボリュームに対応
n2-standard-32仮想マシンWindows 2022 OS
各仮想マシンにつき 1 TiB のワーキングセット、合計 6 TiB
SMB 接続数(RSS ネットワークインターフェイスごと)クライアント側オプションは、各仮想マシンで 16 に設定されています。
ボリューム サイズは Extreme サービスレベルの 75 TiB でした
Fio は、各仮想マシンで 8 つのジョブを実行し、合計 48 個のジョブを実行しました。以下の表は、SMB 上で 64 KiB のブロックサイズを使用した場合、単一のボリュームが約 5,130 MiBps の純粋なシーケンシャル読み取りと約 1,790 MiBps の純粋なシーケンシャル書き込みを処理できると推定されることを示しています。
SMB 64 KiB シーケンシャル 6 n2-standard-32 Windows 2022 VM
| 読み取り 100%、書き込み 0% | 75% が読み、25% が書く | 50%が読み書き | 25% が読み、75% が書く | 読み取り 0%、書き込み 100% | |
|---|---|---|---|---|---|
| MiBps を読み取る | 5,128 | 2,675 | 1,455 | 559 | 0 |
| MiBps を書き込む | 0 | 892 | 1,454 | 1,676 | 1,781 |
256 KiB のブロックサイズ(シーケンシャル I/O)
これらの結果は、次の設定で Fio を使用して取得されました。
6 台の n2-standard-32 仮想マシンを含む単一ボリュームに対して、256 KiB のブロックサイズを使用
Windows 2022 OS
各仮想マシンにつき 1 TiB のワーキングセット、合計 6 TiB
SMB 接続数(RSS ネットワークインターフェースごと)クライアント側オプションは、各ホストで 16 に設定されています。
ボリューム サイズは Extreme サービスレベルの 75 TiB でした
Fio は、各仮想マシンで 8 つのジョブを実行し、合計 48 個のジョブを実行しました。以下の表は、SMB 上で 256 KiB のブロックサイズを使用した場合、単一のボリュームが約 4,620 MiBps の純粋なシーケンシャル読み取りと約 1,830 MiBps の純粋なシーケンシャル書き込みを処理できると推定されることを示しています。
SMB 256 KiB シーケンシャル 6 n2-standard-32 Windows 2022 VM
| 読み取り 100%、書き込み 0% | 75% が読み、25% が書く | 50%が読み書き | 25% が読み、75% が書く | 読み取り 0%、書き込み 100% | |
|---|---|---|---|---|---|
| MiBps を読み取る | 4,617 | 2,708 | 1,533 | 584 | 0 |
| MiBps を書き込む | 0 | 900 | 1,534 | 1,744 | 1,826 |
4 KiB ブロックサイズ(ランダム I/O)
これらの結果は、次の設定で Fio を使用して取得されました。
6 台の
n2-standard-32仮想マシンを含む単一ボリュームに対する 4 KiB のブロックサイズWindows 2022 OS
各仮想マシンに 1 TiB のワーキング セット(合計 6 TiB)
各ホストで SMB 接続数 / RSS ネットワーク インターフェース クライアントサイド オプションが 16 の値で有効になっている
ボリューム サイズは Extreme サービスレベルの 75 TiB でした
Fio は、各仮想マシンで 8 つのジョブを実行し、合計 48 個のジョブを実行しました。次の表は、単一ボリュームが SMB 経由で 4 KiB のブロックサイズで約 390,000 の純粋なランダム読み取り IOPS と約 110,000 の純粋なランダム書き込み IOPS を処理できることを示しています。
SMB 4 KiB ランダム 6 n2-standard-32 Windows 2022 VM のベンチマーク結果
| 読み取り 100%、書き込み 0% | 75% が読み、25% が書く | 50%が読み書き | 25% が読み、75% が書く | 読み取り 0%、書き込み 100% | |
|---|---|---|---|---|---|
| 読み取り IOPS | 390,900 | 164,700 | 84,200 | 32,822 | 0 |
| 書き込み IOPS | 0 | 54,848 | 84,200 | 98,500 | 109,300 |
8 KiB ブロックサイズ(ランダム I/O)
これらの結果は、次の設定で Fio を使用して取得されました。
6 台の
n2-standard-32仮想マシンを含む単一ボリュームに対する 8 KiB ブロックサイズWindows 2022 OS
各仮想マシンに 1 TiB のワーキング セット(合計 6 TiB)
各ホストで 16 の値に構成された SMB 接続数(RSS ネットワーク インターフェースあたり)クライアントサイド オプション
ボリューム サイズは Extreme サービスレベルの 75 TiB でした
Fio は、各仮想マシンで 8 つのジョブを実行し、合計 48 個のジョブを実行しました。以下の表は、SMB 上で 8 KiB のブロックサイズを使用した場合、単一のボリュームが約 280,000 の純粋なランダム読み取り IOPS と約 90,000 の純粋なランダム書き込み IOPS を処理できると推定されることを示しています。
SMB 8 KiB ランダム 6 n2-standard-32 Windows 2022 VM のベンチマーク結果
| 読み取り 100%、書き込み 0% | 75% が読み、25% が書く | 50%が読み書き | 25% が読み、75% が書く | 読み取り 0%、書き込み 100% | |
|---|---|---|---|---|---|
| 読み取り IOPS | 271,800 | 135,900 | 65,700 | 28,093 | 0 |
| 書き込み IOPS | 0 | 45,293 | 65,900 | 84,400 | 85,500 |
iSCSI アクセスのボリュームスループット制限
以下のセクションでは、Flex Unified サービスレベルにおける iSCSI アクセスのボリュームスループット制限について説明します。
以下のテストは、Flex Unified のカスタムパフォーマンスリージョンストレージプール内の 6 つの 1TiB ボリュームを使用して実行されました。プールは最大スループットと最大 IOPS で構成され、その結果が記録された。
64 KiB のブロックサイズ(シーケンシャル I/O)
これらの結果は、次の設定で Fio を使用して取得されました。
6 ボリュームで 64 KiB のブロックサイズ
n2-standard-32仮想マシンRed Hat Enterprise Linux (RHEL) 9 OS
各仮想マシンのワーキングセットは 720 GiB で、合計 4,320 GiB となる。
各ホストの
nr_sessionsパラメータを 16 に設定した iSCSI各ボリュームのサイズは、10 TiB の容量を持つストレージプールから 1 TiB です。
Fio は、iodepthを 1 に設定した状態で、各仮想マシン上で 24 個のジョブを使用して実行されました。以下の表は、iSCSI 上で 64 KiB のブロックサイズを使用した場合、ストレージ プールが約 4,915 MiBps の純粋なシーケンシャル読み取りと約 2,375 MiBps の純粋なシーケンシャル書き込みを処理できると推定されることを示しています。
iSCSI 64 KiB シーケンシャル 6 n2-standard-32 RHEL 9 VM
| 読み取り 100%、書き込み 0% | 75% が読み、25% が書く | 50%が読み書き | 25% が読み、75% が書く | 読み取り 0%、書き込み 100% | |
|---|---|---|---|---|---|
| MiBps を読み取る | 4,915 | 3,642 | 1,846 | 701 | 0 |
| MiBps を書き込む | 0 | 1,214 | 1,844 | 2,104 | 2,375 |
256 KiB のブロックサイズ(シーケンシャル I/O)
これらの結果は、次の設定で Fio を使用して取得されました。
6 つのボリュームに対して 256 KiB のブロックサイズ、6
n2-standard-32仮想マシンRHEL 9 OS
各仮想マシンのワーキングセットは 720 GiB で、合計 4,320 GiB となる。
各ホストの
nr_sessionsパラメータを 16 に設定した iSCSI各ボリュームのサイズは、10 TiB の容量を持つストレージプールから 1 TiB です。
Fio は、iodepthを 1 に設定した状態で、各仮想マシン上で 24 個のジョブを使用して実行されました。以下の表は、iSCSI 上でブロックサイズ 256 KiB の場合、ストレージ プールが純粋なシーケンシャル読み取りで約 4,954 MiBps、純粋なシーケンシャル書き込みで約 2,648 MiBps の処理能力を持つと推定されることを示しています。
iSCSI 256 KiB シーケンシャル 6 n2-standard-32 RHEL 9 VM
| 読み取り 100%、書き込み 0% | 75% が読み、25% が書く | 50%が読み書き | 25% が読み、75% が書く | 読み取り 0%、書き込み 100% | |
|---|---|---|---|---|---|
| MiBps を読み取る | 4,954 | 3,774 | 2,387 | 859 | 0 |
| MiBps を書き込む | 0 | 1,259 | 2,389 | 2,574 | 2,648 |
4 KiB ブロックサイズ(ランダム I/O)
これらの結果は、次の設定で Fio を使用して取得されました。
6 つのボリュームで 4 KiB のブロックサイズ
n2-standard-32仮想マシンRHEL 9 OS
各仮想マシンのワーキングセットは 720 GiB で、合計 4,320 GiB となる。
各ホストの
nr_sessionsパラメータを 16 に設定した iSCSI各ボリュームのサイズは、10 TiB 容量のストレージ プールから 1 TiB
Fio は、各仮想マシンで 24 個のジョブを実行し、iodepth を 4 に設定して実行しました。次の表は、iSCSI 経由で 4 KiB のブロックサイズを使用した場合、ストレージ プールで約 160,000 の純粋なランダム読み取り IOPS と約 160,000 の純粋なランダム書き込み IOPS を処理できることを示しています。
iSCSI 4 KiB ランダム 6 n2-standard-32 RHEL 9 VM
| 読み取り 100%、書き込み 0% | 75% が読み、25% が書く | 50%が読み書き | 25% が読み、75% が書く | 読み取り 0%、書き込み 100% | |
|---|---|---|---|---|---|
| 読み取り IOPS | 159,861 | 120,061 | 80,047 | 40,027 | 0 |
| 書き込み IOPS | 0 | 40,031 | 80,056 | 120,060 | 160,072 |
8 KiB ブロックサイズ(ランダム I/O)
これらの結果は、次の設定で Fio を使用して取得されました。
6 つのボリュームで 8 KiB のブロックサイズ
n2-standard-32仮想マシンRHEL 9 OS
各仮想マシンのワーキングセットは 720 GiB で、合計 4,320 GiB となる。
各ホストの
nr_sessionsパラメータを 16 に設定した iSCSI各ボリュームのサイズは、10 TiB 容量のストレージ プールから 1 TiB
Fio は、iodepthを 4 に設定して、各仮想マシン上で 24 個のジョブで実行されました。以下の表は、iSCSI 上で 8 KiB のブロックサイズを使用した場合、ストレージ プールが約 158,000 の純粋なランダム読み取り IOPS と約 140,400 の純粋なランダム書き込み IOPS を処理できると推定されることを示しています。
iSCSI 8 KiB ランダム 6 n2-standard-32 RHEL 9 VM
| 読み取り 100%、書き込み 0% | 75% が読み、25% が書く | 50%が読み書き | 25% が読み、75% が書く | 読み取り 0%、書き込み 100% | |
|---|---|---|---|---|---|
| 読み取り IOPS | 157,780 | 120,028 | 80,102 | 39,866 | 0 |
| 書き込み IOPS | 0 | 40,035 | 80,070 | 119,565 | 140,366 |
データベースワークロードベンチマーク
このセクションでは、NetApp ボリューム上の iSCSI 経由で動作する Oracle および Microsoft SQL Server ワークロードに対する、アプリケーションレベルのデータベースベンチマーク結果を示します。 これらの実測値は、合成ストレージベンチマークデータを補完するものです。
考慮事項
これらのデータベースベンチマーク結果を検討する際には、以下の要素を考慮してください。
データベースのベンチマーク結果は、特定のテスト条件下での測定値を表しています。
実際のパフォーマンスは、ワークロードの特性や、ホストのサイズ、ネットワーク、データベース、iSCSI、マルチパス、デプロイメントアーキテクチャなどの構成によって異なります。
Oracle データベース
以下のテストは、iSCSI を介して Silly Little Oracle Benchmark (SLOB) ツールを使用して Oracle Database 23c 上で実行され、分析のためにパフォーマンス結果を取得しました。
| ワークロード プロファイル | ストレージ IOPS | レイテンシ |
|---|---|---|
| 100% 読了 | ~ 157,000 | 0.40 ミリ秒 |
| 90% 読み取り、10% 書き込み | ~ 145,000 | 0.38 ミリ秒 |
ストレージ IOPS 値は、テスト中に観測されたバックエンド ストレージ I/O を表します。合計ストレージ IOPS は、読み取り 90%、書き込み 10% のワークロードの読み取り IOPS と書き込み IOPS の合計として計算されます。
詳細については、iSCSI 経由の Google Cloud NetApp Volumes での Oracle のパフォーマンスをご覧ください。
Microsoft SQL Server
次のテストは、単一 LUN 構成で iSCSI 経由で SQL ストレージ ベンチマーク(SSB)ツールを使用して Microsoft SQL Server ワークロードで実行され、分析用のパフォーマンス結果をキャプチャしました。
| ワークロード プロファイル | ストレージ IOPS | レイテンシ |
|---|---|---|
| 100% 既読 | 約 140,000 | 1 ミリ秒未満 |
| 80% の読み取りと 20% の書き込み | ~ 100,000 | 1 ミリ秒未満 |
これらのパフォーマンス値は、低レイテンシのオペレーティング ポイントでの持続的なストレージ パフォーマンスを表します。ストレージ IOPS の合計は、読み取り 80% と書き込み 20% のワークロードの読み取り IOPS と書き込み IOPS の合計として計算されます。
電子設計自動化ワークロードのベンチマーク
NetApp Volumes の大容量ボリュームのサポートにより、電子設計自動化ワークロードに最適な高パフォーマンスの並列ファイル システムが提供されます。これらのファイル システムは、最大 1 PiB の容量を提供し、低レイテンシで高い I/O とスループットを実現します。
電子設計自動化ワークロードでは、フロントエンド フェーズとバックエンド フェーズでパフォーマンス要件が異なります。フロントエンド フェーズではメタデータと IOPS が優先され、バックエンド フェーズではスループットが重視されます。
業界標準の電子設計自動化ベンチマークでは、フロントエンドとバックエンドのワークロードが混在し、6 つの IP アドレスに均等に分散された複数の NFSv3 クライアントを使用した大容量データを使用することで、最大 21.5 GiBps のスループットと最大 1,350,000 IOPS を達成できます。