インスタンスのパフォーマンスの最適化とテスト

このページでは、Filestore の予想される平均パフォーマンスと推奨パフォーマンスの設定について説明します。また、Filestore インスタンスのパフォーマンスをテストする方法についても説明します。

予想パフォーマンス

Filestore の各サービスティアは、さまざまなレベルのパフォーマンスを実現します。キャッシュの使用、クライアント VM の数、クライアント VM のマシンタイプ、テストされたワークロードなど、さまざまな要因により、特定のインスタンスのパフォーマンスは予想される数とは異なる可能性があります。

次の表は、サービスティアと構成された容量に基づく Filestore インスタンスの予想されるパフォーマンスを示しています。

パフォーマンス 容量 読み取り / 書き込み IOPS 読み取り / 書き込みスループット（MiB/s）
BASIC_HDD 1 TiB～10 TiB 600/1,000 100/100
BASIC_HDD 10 TiB～63.9 TiB 1,000/5,000 180/120
BASIC_SSD 2.5 TiB～63.9 TiB 60,000/25,000 1,200/350
ZONAL 1 TiB 9,200/2,600 260/88
ZONAL 9.75、TiB 89,700/25,350 2,535/858
ZONAL 10 TiB 92,000/26,000 2,600/880
ZONAL 100 TiB 920,000/260,000 26,000/8,800
REGIONAL 1 TiB 12,000/4,000 120/100
REGIONAL 9.75、TiB 117,000/39,000 1,170/975
REGIONAL 10 TiB 92,000/26,000 2,600/880
REGIONAL 100 TiB 920,000/260,000 26,000/8,800
ENTERPRISE 1 TiB 12,000/4,000 120/100
ENTERPRISE 10 TiB 120,000/40,000 1,200/1,000

上の表は、各サービスティアの最小容量と最大容量で予想されるパフォーマンスを示しています。この上限と下限の間で、パフォーマンスは容量のスケーリングに応じて直線的に増減します。たとえば、エンタープライズ インスタンスの容量が 1 TiB から 2 TiB に倍増すると、インスタンスの予想されるパフォーマンスは 12,000/4,000 読み取り / 書き込み IOPS から 24,000/8,000 読み取り / 書き込み IOPS に倍増します。

単一クライアントと数クライアントのシナリオでは、最大の NFS のパフォーマンスを実現するには、nconnect マウント オプションで TCP 接続の数を増やす必要があります。ゾーンのサービスティアの場合は最大 7 個の接続を指定し、リージョン ティアとエンタープライズ ティアの場合は最大 2 個の接続を指定することをおすすめします。一般に、ファイル共有の容量が大きく、接続しているクライアント VM が少ないほど、nconnect で追加の接続を指定することでパフォーマンスが向上します。

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

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=262144 NFS クライアントは、NFS サーバーから READ リクエストごとに最大 262,144 バイトを受信できます。
注: ベーシック ティア インスタンスの場合は、rsize 値を 1048576 に設定します。
wsize=1048576 NFS クライアントは、WRITE リクエストごとに最大 1,048,576 バイト（1 MiB）を NFS サーバーに送信することができます。
resvport NFS クライアントは、このマウント ポイントの NFS サーバーと通信するときに特権ソースポートを使用します。
async NFS クライアントは、特定の条件が満たされるまで、NFS サーバーへのアプリケーション書き込みの送信を遅らせます。
注意: sync オプションを使用すると、パフォーマンスが大幅に低下します。

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

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

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

追加するコンテキスト用に、最小のスケーラブルな Filestore クラスタには 4 つの VM があります。nconnect マウント オプションで指定されたクライアントごとの NFS 接続の数に関係なく、各クライアント VM は 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 に配置します。

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

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

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

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

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

パフォーマンスのテスト

Linux を使用している場合は、fio ツールを使用して、ベーシック ティア インスタンスの読み取り / 書き込みスループットと IOPS のベンチマークを実施できます。このパフォーマンスのベンチマークを実施する方法は、ゾーン、リージョン、エンタープライズ インスタンスでは推奨されません。

このセクションの例では、実行する必要が生じる可能性のある一般的なベンチマークを示しています。最大のパフォーマンスを実現するには、複数のクライアント VM インスタンスから fio を実行することが必要な場合があります。

次の例は、最大書き込みスループットのベンチマークを実施します。

fio --ioengine=libaio --filesize=32G --ramp_time=2s \
--runtime=5m --numjobs=16 --direct=1 --verify=0 --randrepeat=0 \
--group_reporting --directory=/mnt/nfs  \
--name=write --blocksize=1m --iodepth=64 --readwrite=write

次の例は、最大書き込み IOPS のベンチマークを実施します。

fio --ioengine=libaio --filesize=32G --ramp_time=2s \
--runtime=5m --numjobs=16 --direct=1 --verify=0 --randrepeat=0 \
--group_reporting --directory=/mnt/nfs  \
--name=randwrite --blocksize=4k --iodepth=256 --readwrite=randwrite

次の例は、最大読み取りスループットのベンチマークを実施します。

fio --ioengine=libaio --filesize=32G --ramp_time=2s \
--runtime=5m --numjobs=16 --direct=1 --verify=0 --randrepeat=0 \
--group_reporting --directory=/mnt/nfs  \
--name=read --blocksize=1m --iodepth=64 --readwrite=read

次の例は、最大読み取り IOPS のベンチマークを実施します。

fio --ioengine=libaio --filesize=32G --ramp_time=2s \
--runtime=5m --numjobs=16 --direct=1 --verify=0 --randrepeat=0 \
--group_reporting --directory=/mnt/nfs  \
--name=randread --blocksize=4k --iodepth=256 --readwrite=randread

次のステップ