パフォーマンスの最適化

このページでは、ボリュームとクライアントサイドの構成を調整して、Google Cloud NetApp Volumes のパフォーマンスを最適化する方法について説明します。これらの調整により、アプリケーションのスループットが向上し、レイテンシが短縮され、全体的なデータ転送効率が向上します。

始める前に

パフォーマンスを最適化するためにボリュームを変更する前に、 パフォーマンスに関する考慮事項を確認してください。

ボリューム設定を調整する

次のボリューム設定を調整して、パフォーマンスを最適化できます。

• ボリューム容量を増やす: Premium、Extreme、Standard の各サービスレベルのボリュームの容量を増やして、ボリュームのスループットの最大値を向上させることができます。Flex ファイル サービスレベルのボリュームの場合は、ストレージ プールの容量を増やします。Flex Unified または Flex ファイルのカスタム パフォーマンスの場合は、ストレージ プールのスループットと IOPS を増やします。

• サービスレベルをアップグレードする: Premium サービスレベルのボリュームを Extreme サービスレベルのストレージ プールに移動して、スループットを向上させることができます。

• 手動 QoS プールを使用してスループットを増やす: スループット要件が低い大容量ボリュームの 割り当てスループットを減らし、 より高いパフォーマンスを必要とする小容量ボリュームのスループットを、 使用可能なプール スループットまで増やすことができます。

ボリューム容量の増加とサービスレベルのアップグレードは、どちらもボリュームで処理中の I/O ワークロードに影響を与えず、ボリュームへのアクセスにも影響しません。

クライアントを調整する

クライアントで次の設定を調整して、パフォーマンスを向上させることができます。

• クライアントを併置する: レイテンシの結果は、クライアントの 機能とロケーションに直接影響します。最適な結果を得るには、クライアントをボリュームと同じリージョンに配置するか、できるだけ近くに配置します。各ゾーンのクライアントからレイテンシをテストしてゾーンの影響をテストし、レイテンシが最も低いゾーンを使用します。

• Compute Engine のネットワーク帯域幅を構成する: Compute Engine 仮想マシンのネットワーク機能は、使用するインスタンス タイプによって異なります。通常、インスタンスが大きいほど、ネットワーク スループットが向上します。適切なネットワーク帯域幅機能を備えたクライアント仮想マシンを選択し、Google Virtual NIC（gVNIC）ネットワーク インターフェースを選択して、Tier_1 パフォーマンスを有効にすることをおすすめします。詳細については、ネットワーク帯域幅に関する Compute Engine のドキュメントをご覧ください。

• 複数の TCP セッションを開く: アプリケーションで高スループットが必要な場合、 通常の NFS セッションと SMB セッションの基盤となる単一の Transmission Control Protocol（TCP） セッションが最終的に飽和する可能性があります。このような場合は、NFS 接続と SMB 接続で使用する TCP セッションの数を増やします。

  クライアントの種類に応じて、次のいずれかのタブを使用してクライアントを調整します。

  Linux

  従来、NFS クライアントは、ストレージ エンドポイントを共有するすべての NFS マウント ファイル システムに単一の TCP セッションを使用します。 nconnect マウント オプション を使用すると、サポートされる TCP セッションの数を最大 16 まで増やすことができます。

  nconnect を最大限に活用するために Linux クライアント タイプを調整する場合は、次のベスト プラクティスをおすすめします。

  • **`nconnect` で TCP セッションの数を増やす**nconnect: TCP セッションを追加するたびに、128 個の未処理リクエストのキューが追加され、同時実行性が向上します。

  • sunrpc.max_tcp_slot_table_entries パラメータを設定する: sunrpc.max_tcp_slot_table_entries は接続レベルの調整 パラメータで、変更してパフォーマンスを制御できます。sunrpc.max_tpc_slot_table_enteries を 128 リクエストまたは接続ごとに設定し、NetApp Volumes に接続する単一プロジェクト内のすべての NFS クライアントで 10,000 スロットを超えないようにすることをおすすめします。sunrpc.max_tcp_slot_table_entries パラメータを設定するには、パラメータを /etc/sysctl.conf ファイルに追加し、sysctl -p コマンドを使用してパラメータ ファイルを再読み込みします。

  • セッションあたりの最大サポート値を 180 に調整する: NFSv3 とは異なり、 NFSv4.1 クライアントはセッションでクライアントとサーバーの関係を定義します 。NetApp Volumes は NFSv3 を使用して接続ごとに最大 128 個の未処理リクエストをサポートしますが、NFSv4.1 はセッションごとに 180 個の未処理リクエストに制限されます。Linux NFSv4.1 クライアントのデフォルトはセッションごとに 64 max_session_slots ですが、必要に応じてこの値を調整できます。セッションあたりの最大サポート値を 180 に変更することをおすすめします。

    max_session_slots を調整するには、/etc/modprobe.d の下に構成ファイルを作成します。インラインに引用符（""）が表示されないようにしてください。そうしないと、オプションは有効になりません。

    $ echo "options nfs max_session_slots=180" > /etc/modprobe/d/nfsclient/conf
    $ reboot
    
    Use the systool -v -m nfs command to see the current maximum in use
    by the client. For the command to work, at least one NFSv4.1 mount
    must be in place.
    
    $ systool -v -v nfs
    {
    Module = "nfs"
    …
    Parameters:
    …
    Max_session_slots = "63" <-
    …
    }
    

  次の NFS nconnect 比較グラフは、nconnect 構成の使用が NFS ワークロードに与える影響を示しています。この情報は、次の設定で Fio を使用してキャプチャされました。

  • 100% の読み取りワークロード

  • 単一ボリュームに対する 8 KiB ブロックサイズ

  • Red Hat 9 OS を使用する n2-standard-32 仮想マシン

  • 6 TiB のワーキング セット

  nconnect 値を 16 にすると、有効になっていない場合よりもパフォーマンスが 5 倍向上しました。

  

  Windows

  Windows ベースのクライアントの場合、クライアントは SMB マルチチャネル と受信側スケーリング（RSS）を使用して複数の TCP 接続を開くことができます。この構成を実現するには、仮想マシンに RSS をサポートするネットワーク アダプタが割り当てられている必要があります。RSS は 4 または 8 の値に設定することをおすすめしますが、1 より大きい値であればスループットが向上します。

  次のグラフは、RSS 構成の使用が SMB ワークロードに与える影響を示しています。この情報は、次の設定で Fio を使用してキャプチャされました。

  • 100% の読み取りワークロード

  • 単一ボリュームに対する 8 KiB ブロックサイズ

  • Windows 2022 OS を実行する単一の n2-standard-32 仮想マシン

  • 6 TiB のワーキング セット

  8 つのジョブが実行され、テストの実行間で SMB クライアントの RSS オプションのみが変更されました。RSS 値を 4、8、16 にすると、値が 1 の場合と比較してパフォーマンスが 2 倍になりました。各 RSS インスタンスは、numjobs パラメータが 8 で 9 回実行されました。iodepth パラメータは、最大スループットに達するまで実行ごとに 5 ずつ増加しました。

  

ハイ パフォーマンス コンピューティングと高並行ワークロード

ハイ パフォーマンス コンピューティング（HPC）環境や EDA 環境など、大規模な高並行 NFS ワークロードの場合は、次のクライアントサイドの最適化を適用して、パフォーマンスと安定性を向上させ、メタデータ ストームやクライアント ハングなどの問題を回避することを検討してください。

• NFS マウント オプション: NetApp Volumes NFS 共有をマウントする場合は、 /etc/fstab またはマウント コマンドに次のオプションを含めます。

  • actimeo=600: クライアントで属性がキャッシュされる時間を増やし、GETATTR 呼び出しを減らします。
  • nconnect=8: マウントごとに複数の TCP 接続を使用し、帯域幅を向上させます。

  マウント コマンドの例:

  sudo mount -t nfs -o rw,hard,intr,rsize=1048576,wsize=1048576,vers=3,tcp,actimeo=600,nconnect=8 SERVER:/SHARE /mnt/netapp
  

• TCP keepalive 設定: システムの TCP keepalive 時間を調整して、応答のない接続をより迅速に検出します。これは sysctl を使用して設定できます。

  sudo sysctl -w net.ipv4.tcp_keepalive_time=60
  

  この変更を再起動後も維持するには、/etc/sysctl.conf に net.ipv4.tcp_keepalive_time = 60 を追加し、sudo sysctl -p で再読み込みします。

手動 QoS

NetApp Volumes の手動 QoS（Quality of Service）を使用すると、ワークロード要件を満たすようにボリューム パフォーマンスを調整し、ストレージ費用を管理できます。

手動 QoS には次のようなメリットがあります。

• 費用の最適化: ストレージ プールの容量内でボリューム パフォーマンスをスケーリングして、クラウド費用を最適化します。

• スループットの即時調整: ダウンタイムなしでボリューム スループットを調整します。

• 障害復旧費用の削減: レプリケートされたボリュームの QoS を下げて、 宛先プールの障害復旧費用を削減します。

• クローンまたはキャッシュのパフォーマンスの向上: 割り当てサイズが小さいクローン またはキャッシュ ボリュームのパフォーマンスを向上させます。

• 柔軟なワークロード管理: 大規模なストレージ プールを 複数のワークロードのコンテナとして使用し、必要に応じて各ボリュームのスループットを調整します。

考慮事項

• 手動 QoS は、Google Cloud CLI、NetApp Volumes API、または Terraform を使用して管理できます。 Google Cloud コンソールは サポートされていません。

• 手動 QoS は、Flex Unified、Standard、Premium、Extreme の各サービスレベルでサポートされており、Flex ファイル サービスレベルでは使用できません。

手動 QoS の上限を設定する

手動 QoS ストレージ プール内のボリュームでは、スループットと容量を個別に設定できます。手動 QoS プール内のすべてのボリュームの全体的なスループットは、プールの合計スループットによって制限されます。プール スループットは、割り当てられた容量とサービスレベルによって決まります。たとえば、40 TiB Premium プールは、TiB あたり 64 MiBps で最大 2,560 MiBps のスループットを実現できますが、200 TiB Extreme プールは、合計スループットが 25,600 MiBps のボリュームをサポートできます。

重要: 新しい手動 QoS プールを作成することも、既存の自動 QoS プールを手動に変更することもできます。この変更は永続的であり、手動 QoS プールを自動 QoS プールに戻すことはできません。ただし、手動プールから自動プールにボリュームを移動することはできます。

手動 QoS プールを設定したら、プール内の各ボリュームに必要なスループット上限を設定できます。単一ボリュームの最大スループット上限は 4.5 GiBps です。大容量ボリュームの場合は 30 GiBps です。

プールとボリュームのコマンドまたは API は、プールの使用可能なスループット値と割り当てられたスループット値を表示して、合計スループットの管理に役立ちます。手動 QoS プールを作成してボリューム スループットを定義するには、ストレージ プールを作成する とボリュームを作成するをご覧ください。

ストレージ プールを作成する

gcloud

手動 QoS を使用してストレージ プールを作成します。

    gcloud netapp storage-pools create POOL_NAME \
       --project=PROJECT_ID \
       --location=LOCATION \
       --capacity=CAPACITY \
       --service-level=SERVICE_LEVEL \
       --qos-type=QOS_TYPE \
       --network=name=NETWORK_NAME

次の情報を置き換えます。

• POOL_NAME: 作成するプールの名前。プール名はロケーションごとに一意である必要があります。

• PROJECT_ID: ストレージ プールを作成するプロジェクトの名前。

• LOCATION: 作成するプールのロケーション。

• CAPACITY: プールの容量（GiB）。

• SERVICE_LEVEL: ストレージ プールのサービスレベル（Standard、Premium、Extreme）。

• QOS_TYPE: ストレージ プールの QoS タイプ（自動または手動）。

• NETWORK_NAME: VPC の名前。

ストレージ プールを編集する

gcloud

既存の自動 QoS ストレージ プールを編集して手動 QoS を使用します。

    gcloud netapp storage-pools update POOL_NAME \
       --project=PROJECT_ID \
       --location=LOCATION \
       --qos-type=QOS_TYPE

次の情報を置き換えます。

• POOL_NAME: 更新するプールの名前。

• PROJECT_ID: プロジェクトの名前。

• LOCATION: プールのロケーション。

• QOS_TYPE: ストレージ プールの更新された QoS タイプ。手動構成のみがサポートされています。

ボリュームを作成

gcloud

次のコマンドを使用して、指定した手動 QoS スループット上限でボリュームを作成します。

gcloud netapp volumes create VOLUME_NAME \
  --project=PROJECT_ID \
  --location=LOCATION \
  --storage-pool=STORAGE_POOL \
  --capacity=CAPACITY \
  --protocols=PROTOCOLS \
  --share-name=SHARE_NAME \
  --throughput-mibps=THROUGHPUT_MIBPS

次の情報を置き換えます。

• VOLUME_NAME: ボリュームの名前。この名前はロケーションごとに一意である必要があります。

• PROJECT_ID: ボリュームを作成するプロジェクトの名前。

• LOCATION: ボリュームのロケーション。

• STORAGE_POOL: ボリュームを作成するストレージ プール。

• CAPACITY: ボリュームの容量。NAS クライアントに表示される容量を定義します。

• PROTOCOLS: ボリュームのエクスポートに使用する NAS プロトコルを選択します。有効な選択肢は、NFSv3、NFSv4、SMB、および次の組み合わせです。

  • nfsv3,nfsv4
  • nfsv3,smb
  • nfsv4,smb

  選択するプロトコル タイプに応じて、export-policy や smb-settings などのプロトコル固有のパラメータを追加することをおすすめします。

• SHARE_NAME: ボリュームの NFS エクスポート パスまたは SMB 共有名。

• THROUGHPUT_MIBPS: ボリュームのスループット上限（MiBps）。

その他の省略可能なフラグの詳細については、 ボリュームの作成に関する Google Cloud SDK のドキュメントをご覧ください。

次のステップ

ボリュームの移行について確認する。