パフォーマンスのベンチマーク

このページでは、複数のクライアント仮想マシンから単一の 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 のブロックサイズ、6n2-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 を達成できます。

次のステップ

パフォーマンスを監視する