このページでは、Filestore インスタンスで使用可能なパフォーマンス オプションについて説明し、パフォーマンスを最適化するための一般的な推奨事項を示します。 Google Cloud コンソールを使用してゾーン インスタンスとリージョン インスタンスを作成すると、カスタム パフォーマンスがデフォルトで有効になり、容量とは無関係に IOPS をスケーリングして、特定のワークロードのニーズを満たすことができます。
次の表に、カスタム パフォーマンス設定の下限と上限の容量範囲のパフォーマンスの上限の概要を示します。
| 容量の範囲 | サービスティア | 容量 | 1 TiB あたりのプロビジョニングされた IOPS |
|---|---|---|---|
| 低容量範囲 | リージョン(リージョンで使用可能な小規模インスタンス) | 100 GiB ~ 10,239 GiB | 4,000 ~ 17,000 |
| リージョン(このリージョンでは小規模インスタンスは使用できません) | 1 TiB~9.75 TiB | 4,000 ~ 17,000 | |
| ゾーン | 1 TiB~9.75 TiB | 4,000 ~ 17,000 | |
| 高容量範囲 | リージョン | 10 TiB~100 TiB | 3,000 ~ 7,500 |
| ゾーン | 10 TiB~100 TiB | 3,000 ~ 7,500 |
パフォーマンスの計算について
次の表に、TiB あたりのプロビジョニングされた IOPS と割り当てられた容量に基づくパフォーマンスの計算を示します。計算はさまざまな容量範囲に基づいて行われ、TiB あたりの最小 IOPS 値と最大 IOPS 値に対して、読み取り IOPS、書き込み IOPS、読み取りスループット、書き込みスループットの値がどのように変化するかを示します。
詳細については、読み取り / 書き込み IOPS をご覧ください。
| 容量の範囲 | TiB あたりの最小および最大 プロビジョニング済み IOPS |
容量 | 読み取り IOPS | 書き込み IOPS | 読み取りスループット(MiBps) | 書き込みスループット(MiBps) | 単一クライアントの読み取りスループット(MiBps) | 単一クライアントの書き込みスループット(MiBps) |
|---|---|---|---|---|---|---|---|---|
| 容量範囲の下限 (100 GiB ~ 10,239 GiB) |
4,000 | 100 GiB | 2,000* | 600 | 47 | 16 | 47 | 16 |
| 600 GiB | 2,344 | 703 | 55 | 19 | 55 | 19 | ||
| 1,024 GiB | 4,000 | 1,200 | 94 | 32 | 94 | 32 | ||
| 10,239 GiB | 39,996 | 11,999 | 940 | 320 | 450 | 260 | ||
| 17,000 | 100 GiB | 2,000 | 600 | 47 | 16 | 47 | 16 | |
| 600 GiB | 9,961 | 2,988 | 234 | 80 | 234 | 80 | ||
| 1,024 GiB | 17,000 | 5,100 | 400 | 136 | 400 | 136 | ||
| 10,239 GiB | 169,983 | 50,995 | 3,995 | 1,360 | 450 | 260 | ||
| 容量範囲が大きい (10 TiB ~ 100 TiB) |
3,000 | 10 TiB | 30,000 | 9,000 | 705 | 240 | 705 | 240 |
| 7,500 | 100 TiB | 750,000 | 225,000 | 17,625 | 6,000 | 1,600 | 800 |
* 小容量インスタンス機能へのアクセス権に応じて、Filestore リージョン インスタンスの容量範囲の下限は 100 GiB ~ 10,239 GiB または 1 TiB ~ 9.75 TiB のいずれかになります。詳細については、 小容量の Filestore インスタンスをご覧ください。
パフォーマンスのスケーリング
単一クライアントと数クライアントのシナリオでは、最大の NFS のパフォーマンスを実現するには、nconnect マウント オプションで TCP 接続の数を増やす必要があります。
特定のサービスティアでは、クライアントとサーバー間の接続数を次のように指定することをおすすめします。
| 階層 | 容量 | 接続の数 |
|---|---|---|
| リージョン、ゾーン | 1~9.75 TiB | nconnect=2 |
| リージョン、ゾーン | 10~100 TiB | nconnect=7 |
| Enterprise | - | nconnect=2 |
| 高スケール SSD | - | nconnect=7 |
一般に、ファイル共有の容量が大きく、接続しているクライアント 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=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 からのみ実行されます。
容量ベースのパフォーマンスの上限
容量ベースの上限は、カスタム パフォーマンスをサポートしていないサービスティア(基本ティアなど)や、カスタム パフォーマンスを手動で無効にしたインスタンスに適用されます。
Filestore の各サービスティアは、パフォーマンスのレベルがそれぞれ異なります。パフォーマンスは、キャッシュの使用、クライアント VM の数、クライアント VM のマシンタイプ、テスト対象のワークロードなどの要因によって異なる場合があります。
次の表に、各サービスティアの最小容量と最大容量を設定したときに達成可能な最大パフォーマンスを示します。表の値はすべて推定上限です。
| サービスティア | 容量 | 読み取り IOPS | 書き込み IOPS | 読み取りスループット(MiBps) | 書き込みスループット(MiBps) | 単一クライアントの読み取りスループット(MiBps) | 単一クライアントの書き込みスループット(MiBps) |
|---|---|---|---|---|---|---|---|
| ゾーン | 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 | |
| リージョン | 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 | |
| 基本 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 | |
| 基本 SSD | 2.5 TiB ~ 63.9 TiB | 60,000 | 25,000 | 1,200 | 350 | 1,200 | 350 |
Google Cloud リソース全体のパフォーマンスを向上させる
複数の Google Cloud リソースにわたるオペレーション(Google Cloud 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 からの読み取りオペレーションのパフォーマンスを向上させてみてください。