インスタンスのパフォーマンス

このページでは、Filestore インスタンスのパフォーマンスの上限と、推奨されるパフォーマンス設定とテスト オプションについて説明します。

Filestore の各サービスティアは、パフォーマンスのレベルがそれぞれ異なります。パフォーマンスは、キャッシュの使用、クライアント VM の数、クライアント VM のマシンタイプ、テスト対象のワークロードなどの要因によって異なる場合があります。

次の表に、各サービスティアの最小容量と最大容量を設定したときに達成可能な最大パフォーマンスを示します。

表の値はすべて推定上限であり、保証されるものではありません。カスタム パフォーマンス設定と上限については、カスタム パフォーマンスの上限をご覧ください。

各サービスティアの最小容量と最大容量でのパフォーマンスの上限
サービスティア 容量 読み取り IOPS 書き込み IOPS 読み取りスループット（MiBps） 書き込みスループット（MiBps） 単一クライアントの読み取りスループット（MiBps） 単一クライアントの書き込みスループット（MiBps） カスタム パフォーマンスがサポートされている
BASIC_HDD 1 TiB～10 TiB 600 1,000 100 100 100 100 いいえ
10 TiB～63.9 TiB 1,000 5,000 180 120 180 120
BASIC_SSD 2.5 TiB～63.9 TiB 60,000 25,000 1,200 350 1,200 350
ZONAL 1 TiB 9,200 2,600 260 88 260 88 ○
9.75、TiB 89,700 25,350 2,535 858 450 260
10 TiB 92,000 26,000 2,600 880 1,600 800
100 TiB 920,000 260,000 26,000 8,800 1,600 800
REGIONAL 1 TiB 12,000 4,000 120 100 120 100
9.75、TiB 117,000 39,000 1,170 975 450 260
10 TiB 92,000 26,000 2,600 880 1,600 800
100 TiB 920,000 260,000 26,000 8,800 1,600 800
Enterprise 1 TiB 12,000 4,000 120 100 120 100 いいえ
10 TiB 120,000 40,000 1,200 1,000 450 260

パフォーマンスのスケーリング

パフォーマンスは、前の表に記載されているパフォーマンスの上限内で、容量に応じて線形的にスケーリングします。たとえば、エンタープライズ インスタンスの容量が 1 TiB から 2 TiB に倍増すると、インスタンスのパフォーマンスの上限は 12,000/4,000 読み取り / 書き込み IOPS から 24,000/8,000 読み取り / 書き込み IOPS に倍増します。

単一クライアントと数クライアントのシナリオでは、最大の NFS のパフォーマンスを実現するには、nconnect マウント オプションで TCP 接続の数を増やす必要があります。

特定のサービスティアでは、クライアントとサーバー間の接続数を次のように指定することをおすすめします。

階層 容量 接続の数
リージョン、ゾーン 1～9.75 TiB nconnect=2
リージョン、ゾーン 10～100 TiB nconnect=7
Enterprise - nconnect=2
高スケール SSD - nconnect=7

一般に、ファイル共有の容量が大きく、接続しているクライアント VM が少ないほど、nconnect で追加の接続を指定することでパフォーマンスが向上します。

カスタム パフォーマンス

カスタム パフォーマンスを設定して、指定された容量とは別に、ワークロードのニーズに応じてパフォーマンスを構成します。TiB あたりの IOPS 比率を指定するか、固定の IOPS 数を設定できます。詳細については、カスタム パフォーマンスをご覧ください。

推奨されるクライアント マシンタイプ

16 Gbps 以上の下り（外向き）帯域幅を提供する Compute Engine マシンタイプ（n2-standard-8 など）を使用することをおすすめします。この下り（外向き）の帯域幅により、クライアントは頻繁にキャッシュ保存が行われるワークロードに対しておよそ 16 Gbps の読み取り帯域幅を確保できます。詳細については、ネットワーク帯域幅をご覧ください。

Linux クライアントのマウント オプション

次の NFS マウント オプション、特に hard マウントと async を使用し、rsize オプションと wsize オプションを使用して、Linux クライアントの VM インスタンスでの最適なパフォーマンスを実現することをお勧めします。NFS マウント オプションの詳細については、nfs をご覧ください。

デフォルト オプション 説明
hard NFS クライアントは、NFS リクエストを無期限に再試行します。
timeo=600 NFS クライアントは、NFS リクエストを再試行するまで 600 デシ秒（60 秒）待ちます。
retrans=3 NFS クライアントは、NFS リクエストを 3 回試行してから、さらに復旧処理を行います。
rsize=524288 NFS クライアントは、NFS サーバーから READ リクエストごとに最大 524,288 バイトを受信できます。
注: ベーシック ティア インスタンスの場合は、rsize 値を 1048576 に設定します。
wsize=524288 NFS クライアントは、WRITE リクエストごとに最大 524,288 バイトを NFS サーバーに送信できます。
resvport NFS クライアントは、このマウント ポイントの NFS サーバーと通信するときに特権ソースポートを使用します。
async NFS クライアントは、特定の条件が満たされるまで、NFS サーバーへのアプリケーション書き込みの送信を遅らせます。
注意: sync オプションを使用すると、パフォーマンスが大幅に低下します。

read_ahead_kb パラメータを使用して NFS 読み取りスループットを最適化する

NFS read_ahead_kb パラメータは、順次読み取りオペレーション中に Linux カーネルがプリフェッチするデータ量をキロバイト単位で指定します。その結果、後続の読み取りリクエストはメモリから直接処理されるため、レイテンシが短縮され、全体的なパフォーマンスが向上します。

Linux カーネル バージョン 5.4 以降の場合、Linux NFS クライアントはデフォルトの read_ahead_kb 値として 128 KB を使用します。この値を 20 MB に増やして、シーケンシャル読み取りスループットを改善することをおすすめします。

Linux クライアント VM にファイル共有を正常にマウントしたら、次のスクリプトを使用して read_ahead_kb パラメータ値を手動で調整できます。

mount_point=MOUNT_POINT_DIRECTORY
device_number=$(stat -c '%d' $mount_point)
((major = ($device_number & 0xFFF00) >> 8))
((minor = ($device_number & 0xFF) | (($device_number >> 12) & 0xFFF00)))
sudo bash -c "echo 20480 > /sys/class/bdi/$major:$minor/read_ahead_kb"

ここで

MOUNT_POINT_DIRECTORY は、ファイル共有がマウントされているディレクトリへのパスです。

単一および複数のクライアント VM のパフォーマンス

Filestore のスケーラブルなサービスティアは、単一のクライアント VM ではなく、複数のクライアント VM 向けにパフォーマンスが最適化されています。

ゾーン インスタンス、リージョン インスタンス、エンタープライズ インスタンスの場合、完全なパフォーマンスを利用するには少なくとも 4 つのクライアント VM が必要です。これにより、基盤となる Filestore クラスタ内のすべての VM が完全に利用されます。

追加するコンテキスト用に、最小のスケーラブルな Filestore クラスタには 4 つの VM があります。各クライアント VM は、nconnect マウント オプションを使用して指定されたクライアントあたりの NFS 接続の数に関係なく、1 つの Filestore クラスタ VM とのみ通信します。単一のクライアント VM を使用する場合、読み取りと書き込みのオペレーションは 1 つの Filestore クラスタ VM からのみ実行されます。

Google Cloud リソース全体のパフォーマンスを向上させる

複数の Google Cloud リソースにわたるオペレーション（gcloud CLI を使用して Cloud Storage から Filestore インスタンスにデータをコピーすることなど）は時間がかかることがあります。パフォーマンスの問題を軽減するには、次の方法をお試しください。

  • Cloud Storage バケット、クライアント VM、Filestore インスタンスをすべて同じリージョンに配置する。

    デュアルリージョンは、Cloud Storage に保存されているデータに対して最もパフォーマンスの高いオプションを提供します。このオプションを使用する場合は、デュアルリージョンに含まれる単一リージョンのいずれかに他のリソースを配置してください。たとえば、Cloud Storage データが us-central1,us-west1 にある場合は、クライアント VM と Filestore インスタンスを us-central1 に配置します。

  • 基準となるものとして、Persistent Disk（PD）がアタッチされた VM のパフォーマンスを確認し、Filestore インスタンスのパフォーマンスと比較します。

    • PD がアタッチされた VM のパフォーマンスが Filestore インスタンスと比較して同等または遅い場合、これは Filestore とは関係のないパフォーマンスのボトルネックが存在することを示している可能性があります。Filestore 以外のリソースのベースライン パフォーマンスを改善するには、並列複合アップロードに関連付けられている gcloud CLI プロパティを調整します。詳細については、ツールと API で並列複合アップロードを使用する方法をご覧ください。

    • Filestore インスタンスのパフォーマンスが PD がアタッチされた VM よりも大幅に低い場合は、オペレーションを複数の VM に分散してみてください。

    • これにより、Cloud Storage からの読み取りオペレーションのパフォーマンスを向上できます。

    • ゾーン インスタンス、リージョン インスタンス、エンタープライズ インスタンスの場合、完全なパフォーマンスを利用するには少なくとも 4 つのクライアント VM が必要です。これにより、基盤となる Filestore クラスタ内のすべての VM が完全に利用されます。詳細については、単一および複数のクライアント VM のパフォーマンスをご覧ください。

次のステップ