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

このページでは、複数のクライアント仮想マシンからの単一の Google Cloud NetApp Volumes ボリュームのパフォーマンスの上限について説明します。このページの情報を使用して、ワークロードのサイズを設定します。

パフォーマンス テスト

次のテスト結果は、パフォーマンスの上限を示しています。これらのテストでは、スループットがベンチマーク テストに影響しないように、ボリュームに十分な容量があります。単一ボリュームの容量を次のスループット数を超えて割り当てても、パフォーマンスは向上しません。

パフォーマンス テストは Fio を使用して完了しました。

パフォーマンス テストの結果については、次の点を考慮してください。

  • Standard、Premium、Extreme の各サービスレベルのパフォーマンスは、上限に達するまでボリューム容量に比例してスループットをスケーリングします。すべての Flex サービスレベルはストレージ プールの機能に合わせてスケーリングされ、プール内のすべてのボリュームがプールのパフォーマンスを共有します。

  • カスタム パフォーマンスを備えた Flex Unified サービスレベルと Flex File サービスレベルでは、容量、IOPS、スループットを個別にスケーリングできます。

  • IOPS の結果はあくまで情報提供を目的としたものです。

  • 次の結果を生成するために使用される数値は、最大の結果を表示するように設定されています。次の結果は、達成可能な最大スループット容量の割り当ての見積もりと見なす必要があります。

  • プロジェクトごとに複数の高速ボリュームを使用する場合は、プロジェクトごとの上限が適用されることがあります。

  • 次のパフォーマンス テストの結果は、NFSv3、SMB、iSCSI プロトコルのみを対象としています。NFSv4.1 などの他のプロトコル タイプは、NetApp Volumes のパフォーマンスのテストには使用されませんでした。

NFSv3 アクセスのボリューム スループットの上限

以降のセクションでは、NFSv3 アクセスのボリューム スループットの上限について詳しく説明します。

カスタム パフォーマンスの Flex File サービスレベル

次のテストは、Flex カスタム パフォーマンスのゾーン ストレージ プール内の単一ボリュームで実行されました。プールは最大スループットと IOPS で構成され、結果がキャプチャされました。

64 KiB ブロックサイズ（順次 I/O）

これらの結果は、次の設定で Fio を使用して取得されました。

  • 6 つの n2-standard-32 仮想マシンを含む単一ボリュームに対する 64 KiB のブロックサイズ

  • Red Hat 9 OS

  • 各仮想マシンに 96 GiB のワーキング セット（合計 576 GiB）

  • 各ホストで nconnect マウント オプションが 16 の値に構成されている

  • rsize と wsize のマウント オプションが 65536 に設定されている

  • ボリューム サイズは、カスタム パフォーマンスの Flex サービスレベルの 10 TiB でした。テストでは、カスタム パフォーマンスは最大値の 5,120 MiBps と 160,000 IOPS に設定されました。

Fio は、各仮想マシンで 8 つのジョブを実行し、合計 48 個のジョブを実行しました。次の表は、NFSv3 で 64 KiB のブロックサイズを使用した場合、1 つのボリュームで約 4,300 MiBps の純粋なシーケンシャル読み取りと 1,480 MiBps の純粋なシーケンシャル書き込みを処理できることを示しています。

NFS 64 KiB 順次 6 n2-standard-32 Red Hat 9 VM のベンチマーク結果
読み取り 100%、書き込み 0% 75% の読み取りと 25% の書き込み 読み取り 50%、書き込み 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 サービスレベルの 10 TiB でした。テストでは、カスタム パフォーマンスは最大値の 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%、書き込み 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 サービスレベル

次のテストは、Extreme ストレージ プール内の単一ボリュームで実行され、結果がキャプチャされました。

64 KiB ブロックサイズ（順次 I/O）

これらの結果は、次の設定で Fio を使用して取得されました。

  • 6 つの n2-standard-32 仮想マシンを含む単一ボリュームに対する 64 KiB のブロックサイズ

  • Red Hat 9 OS

  • 各仮想マシンのワーキング セットは 1 TiB で、合計 6 TiB

  • 各ホストで nconnect マウント オプションが 16 の値に構成されている

  • ボリューム サイズは Extreme サービスレベルの 75 TiB でした

Fio は、各仮想マシンで 8 つのジョブを実行し、合計 48 個のジョブを実行しました。次の表は、NFSv3 で 64 KiB のブロックサイズを使用した場合、1 つのボリュームで約 5,240 MiBps の純粋なシーケンシャル読み取りと約 2,180 MiBps の純粋なシーケンシャル書き込みを処理できることを示しています。

NFS 64 KiB 順次 6 n2-standard-32 Red Hat 9 VM のベンチマーク結果
読み取り 100%、書き込み 0% 75% の読み取りと 25% の書き込み 読み取り 50%、書き込み 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 を使用して取得されました。

  • 6 台の n2-standard-32 仮想マシンを含む単一ボリュームに対する 256 KiB のブロックサイズ

  • Red Hat 9 OS

  • 各仮想マシンのワーキング セットは 1 TiB で、合計 6 TiB

  • 各ホストで nconnect マウント オプションが 16 の値に構成されている

  • ボリューム サイズは Extreme サービスレベルの 75 TiB でした

Fio は、各仮想マシンで 8 つのジョブを実行し、合計 48 個のジョブを実行しました。次の表は、NFSv3 で 256 KiB のブロックサイズを使用した場合、1 つのボリュームで約 4,930 MiBps の純粋なシーケンシャル読み取りと約 2,440 MiBps の純粋なシーケンシャル書き込みを処理できることを示しています。

NFS 256 KiB 順次 6 n2-standard-32 Red Hat 9 VM のベンチマーク結果
100% 既読、0% 書き込み 75% の読み取りと 25% の書き込み 読み取り 50%、書き込み 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%、書き込み 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%、書き込み 50% 25% の読み取りと 75% の書き込み 0% 読み取り、100% 書き込み
読み取り IOPS 265,000 132,000 66,900 30,200 0
書き込み IOPS 0 44,100 66,900 90,500 104,000

SMB アクセスのボリューム スループットの上限

以降のセクションでは、SMB アクセスのボリューム スループットの上限について詳しく説明します。

64 KiB ブロックサイズ（順次 I/O）

これらの結果は、次の設定で Fio を使用して取得されました。

  • 6 つの n2-standard-32 仮想マシンを含む単一ボリュームに対する 64 KiB のブロックサイズ

  • Windows 2022 OS

  • 各仮想マシンのワーキング セットは 1 TiB で、合計 6 TiB

  • 各仮想マシンで構成された SMB Connect Count Per RSS Network Interface クライアントサイド オプションの値が 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%、書き込み 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 Connection Count Per RSS Network Interface クライアントサイド オプションが 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%、書き込み 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 Connection Count Per RSS Network Interface クライアントサイド オプションが 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%、書き込み 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%、書き込み 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 個の 1 TiB ボリュームで実行されました。プールは最大スループットと IOPS で構成され、結果がキャプチャされました。

64 KiB ブロックサイズ（順次 I/O）

これらの結果は、次の設定で Fio を使用して取得されました。

  • 6 台の n2-standard-32 仮想マシンで 6 個のボリュームのブロックサイズを 64 KiB に設定

  • Red Hat Enterprise Linux（RHEL）9 OS

  • 各仮想マシンのワーキング セットは 720 GiB で、合計 4,320 GiB

  • 各ホストの nr_sessions パラメータが 16 に設定されている iSCSI

  • 各ボリュームのサイズは、10 TiB 容量のストレージ プールから 1 TiB

Fio は、各仮想マシンで 24 個のジョブを実行し、iodepth を 1 に設定して実行しました。次の表は、ストレージ プールが iSCSI 経由で 64 KiB のブロックサイズで約 4,915 MiBps の純粋なシーケンシャル読み取りと約 2,375 MiBps の純粋なシーケンシャル書き込みを処理できると推定されることを示しています。

iSCSI 64 KiB 順次 6 n2-standard-32 RHEL 9 VM

読み取り 100%、書き込み 0% 75% の読み取りと 25% の書き込み 読み取り 50%、書き込み 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 台の n2-standard-32 仮想マシンで 6 個のボリュームのブロックサイズを 256 KiB に設定

  • RHEL 9 OS

  • 各仮想マシンのワーキング セットは 720 GiB で、合計 4,320 GiB

  • 各ホストの nr_sessions パラメータが 16 に設定されている iSCSI

  • 各ボリュームのサイズは、10 TiB 容量のストレージ プールから 1 TiB

Fio は、各仮想マシンで 24 個のジョブを実行し、iodepth を 1 に設定して実行しました。次の表は、iSCSI 経由で 256 KiB のブロックサイズを使用した場合、ストレージ プールが純粋なシーケンシャル読み取りで約 4,954 MiBps、純粋なシーケンシャル書き込みで約 2,648 MiBps を処理できると推定されることを示しています。

iSCSI 256 KiB シーケンシャル 6 n2-standard-32 RHEL 9 VM

読み取り 100%、書き込み 0% 75% の読み取りと 25% の書き込み 読み取り 50%、書き込み 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 つの n2-standard-32 仮想マシンで 6 つのボリュームのブロックサイズが 4 KiB

  • 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%、書き込み 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 個の n2-standard-32 仮想マシンで 6 個のボリュームのブロックサイズが 8 KiB

  • RHEL 9 OS

  • 各仮想マシンのワーキング セットは 720 GiB で、合計 4,320 GiB

  • 各ホストの nr_sessions パラメータが 16 に設定されている iSCSI

  • 各ボリュームのサイズは、10 TiB 容量のストレージ プールから 1 TiB

Fio は、各仮想マシンで 24 個のジョブを実行し、iodepth を 4 に設定して実行しました。次の表は、iSCSI 経由で 8 KiB のブロックサイズを使用した場合、ストレージ プールが約 158,000 の純粋なランダム読み取り IOPS と約 140,400 の純粋なランダム書き込み IOPS を処理できると推定されることを示しています。

iSCSI 8 KiB ランダム 6 n2-standard-32 RHEL 9 VM

100% 既読、0% 書き込み 75% の読み取りと 25% の書き込み 読み取り 50%、書き込み 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 Volumes の 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 を実現できます。

次のステップ

パフォーマンスをモニタリングする。