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

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

予想パフォーマンス

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

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

上の表は、各サービスティアの最小容量と最大容量で予想されるパフォーマンスを示しています。この上限と下限の間で、パフォーマンスは容量のスケーリングに応じて直線的に増減します。たとえば、エンタープライズ インスタンスの容量が 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 をご覧ください。

単一および複数のクライアント 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 に配置します。

• 基準となるものとして、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

次のステップ

• パフォーマンスに関する問題のトラブルシューティング
• 容量をスケーリングする