NFS データストアの概要

データが増加すると、VMware ワークロードのストレージをコンピューティング リソースとは別にスケーリングする必要が生じる場合があります。VMware Engine のデフォルトの vSAN ストレージは、最も要求の厳しいアプリケーションに高いパフォーマンスを提供しますが、容量を追加するには、必要のないコンピューティング リソースやネットワーク リソースを含む完全なノードを追加する必要があります。

柔軟性を高めるため、VMware Engine は、Filestore や Google Cloud NetApp Volumes などのサービスからの外部 Network File System（NFS）データストアをサポートしています。外部 NFS データストアを使用すると、vSAN の高いパフォーマンスを必要としない Tier-2 アプリケーション、Tier-3 アプリケーション、バックアップ、アーカイブ ワークロードのストレージを費用対効果の高い方法でスケーリングできます。

サポートされている NFS ストレージ サービス

次のサービスで外部 NFS データストアを使用できます。 Google Cloud

VMware Engine で NFS データストアを使用するための一般的な前提条件

外部 NFS ボリュームをデータストアとしてマウントする前に、次の前提条件を満たす必要があります。

NFS ボリュームの要件

NFS ボリュームは次の要件を満たす必要があります。

  • ロケーション: NFS ボリューム（Filestore インスタンスまたは Google Cloud NetApp Volumes ボリューム）と VMware Engine クラスタは、同じ Google Cloud リージョンに存在する必要があります。VMware Engine では、異なるリージョン間でデータストアをマウントすることはできません。拡張プライベート クラウドでは、リージョン データストアのみがサポートされます。
  • プロトコル: VMware Engine は、VMware Engine データストアとして使用する場合、NFS バージョン 3（NFSv3）のみをサポートしています。NFSv4.1 はサポートされていません。
  • 削除保護: Filestore または Google Cloud NetApp Volumes を使用する場合は、誤って削除してデータ損失を防ぐため、ボリュームで削除保護を有効にする必要があります。

VMware Engine サービス アカウントの権限

Filestore または Google Cloud NetApp Volumes を基盤とするデータストアを作成してマウントするために、VMware Engine は Google マネージド サービス アカウントを使用して NFS リソースにアクセスします。サービス アカウント（service-PROJECT_NUMBER@gcp-sa-vmwareengine.iam.gserviceaccount.com）に次の IAM ロールを付与します。

  • roles/compute.networkViewer: ネットワーク ピアリングを表示するために、すべてのデータストア タイプで必要です。このロールは、NFS ボリュームが存在するプロジェクトに付与します。共有 VPC を使用する場合は、代わりにホスト プロジェクトにこのロールを付与します。
  • roles/file.viewer: Filestore を基盤とするデータストアが Filestore インスタンスにアクセスするために必要です。このロールは、Filestore が存在するプロジェクトに付与します。
  • roles/netapp.viewer: Google Cloud NetApp Volumes を基盤とするデータストアが Google Cloud NetApp Volumes ボリュームにアクセスするために必要です。このロールは、Google Cloud NetApp Volumes が存在するプロジェクトに付与します。

これらのロールを付与するには、次のコマンドを使用します。

共有 VPC 構成に roles/compute.networkViewer ロールを付与する場合は、例のプロジェクト ID をホスト プロジェクト ID に置き換えてください。

Filestore の場合:

gcloud projects add-iam-policy-binding FILESTORE_PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-vmwareengine.iam.gserviceaccount.com \
    --role=roles/file.viewer

gcloud projects add-iam-policy-binding FILESTORE_PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-vmwareengine.iam.gserviceaccount.com \
    --role=roles/compute.networkViewer

Google Cloud NetApp Volumes の場合:

gcloud projects add-iam-policy-binding NETAPP_PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-vmwareengine.iam.gserviceaccount.com \
    --role=roles/netapp.viewer

gcloud projects add-iam-policy-binding NETAPP_PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-vmwareengine.iam.gserviceaccount.com \
    --role=roles/compute.networkViewer

次のように置き換えます。

  • FILESTORE_PROJECT_ID: Filestore インスタンスが存在するプロジェクト ID。
  • NETAPP_PROJECT_ID: Google Cloud NetApp Volumes ボリュームが存在するプロジェクト ID。
  • PROJECT_NUMBER: VMware Engine が有効になっているプロジェクト番号。

サービス サブネットの要件

ESXi ホストと NFS ボリューム間の NFS トラフィック用に一意の CIDR の範囲が割り当てられた専用のサービス サブネットが必要です。サービス サブネットは次のように構成します。

  • プライベート クラウド内の各ノードに 1 つずつ割り当てるのに十分な IP アドレスを持つサービス サブネットの CIDR の範囲を構成する必要があります。
  • サービス サブネットは NFS データストア トラフィックにのみ使用できますが、同じサブネットを複数の異なる NFS データストアに接続できます。
  • サービス サブネット用に予約された CIDR 割り当てを、NFS ボリュームの許可されたクライアント リストまたはエクスポート ポリシーに追加する必要があります。Filestore の場合は、サービス サブネット CIDR 範囲のアクセス制御ルールを追加します。Google Cloud NetApp Volumes の場合は、ボリュームのエクスポート ルールの [許可されたクライアント] セクションに CIDR を追加します。

NSX-T ゲートウェイと分散ファイアウォール ルールはサービス サブネットに適用されません。

ネットワーク接続の要件

データストアをマウントするプライベート クラウドの NFS ボリュームの VPC ネットワークと VMware Engine ネットワーク（VEN）の間にアクティブな接続が存在する必要があります。Private Service Access（PSA）で Filestore を使用する場合、リージョン内のストレージ アクセスに起因するネットワーク料金は適用されません。

ネットワーク ファイル サービスに接続する場合は、プライベート クラウドの VEN タイプに応じて、次のいずれかの接続方法を使用します。

  • 標準 VEN: 標準 VEN で作成されたプライベート クラウドは、VPC ネットワーク ピアリングを使用して、Filestore（PSA を使用）や Google Cloud NetApp Volumes などのネットワーク ファイル サービスに接続します。
  • レガシー VEN: レガシー VEN で動作するプライベート クラウドでは、ネットワーク ファイル サービスに接続するためにプライベート接続が必要です。NFS データストアの使用中にプライベート接続を削除すると、データストアへのアクセスが中断されます。したがって、NFS データストアがマウントされて使用されている間は、プライベート接続を削除しないでください。

プライベート クラウドのライフサイクルとの相互運用性

VMware Engine API で管理される NFS データストアは、次の方法でプライベート クラウドのライフサイクル イベント全体で永続化されます。

  • クラスタの拡張と縮小: マウントされた NFS データストアを含むクラスタにノードを追加すると、VMware Engine は新しいノードにこれらのデータストアを自動的にマウントします。クラスタを縮小するときにノードを削除すると、その vmknic IP アドレスが解放されます。
  • ノードの再起動: ノードの NFS データストア構成は永続的であり、ノードの再起動後もそのまま残ります。
  • ソフトウェアのアップグレード: ホストにマウントされた NFS データストアは、ESXi、vCenter、NSX-T コンポーネントのアップグレードの影響を受けません。

従来の NFS データストア マウントからの移行

2026 年 1 月 1 日より前に VMware Engine で NFS データストアを作成した場合、従来のモデルを使用しています。サポートされている推奨モデルに移行するには、Cloud カスタマーケアに連絡して移行プロセスを開始してください。

既知の問題

外部 NFS データストアに関する既知の問題は次のとおりです。

  • プライベート クラウドの論理削除中に、データストアへのネットワーク パスが切断されます。
  • VPC ネットワーク ピアリングが確立された後、vSphere ノードへのルート伝播に最大 20 分かかることがあります。

次のステップ