Présentation des datastores NFS

À mesure que vos données augmentent, vous devrez peut-être faire évoluer le stockage de vos charges de travail VMware indépendamment des ressources de calcul. Bien que le stockage vSAN par défaut dans VMware Engine offre des performances élevées pour vos applications les plus exigeantes, l'ajout de capacité nécessite l'ajout d'un nœud complet, y compris des ressources de calcul et de mise en réseau dont vous n'avez peut-être pas besoin.

Pour vous offrir plus de flexibilité, VMware Engine est compatible avec les datastores NFS (Network File System) externes provenant de services tels que Filestore et Google Cloud NetApp Volumes. L'utilisation d'un datastore NFS externe est un moyen économique de faire évoluer le stockage pour les applications de niveau 2 et 3, les sauvegardes et les charges de travail d'archivage qui ne nécessitent pas les hautes performances de vSAN.

Services de stockage NFS compatibles

Vous pouvez utiliser des datastores NFS externes avec les services suivants Google Cloud :

Prérequis généraux pour utiliser des datastores NFS avec VMware Engine

Avant de monter un volume NFS externe en tant que datastore, vous devez respecter les prérequis suivants :

Exigences concernant les volumes NFS

Les volumes NFS doivent répondre aux exigences suivantes :

  • Emplacement : le volume NFS (instance Filestore ou volume Google Cloud NetApp Volumes) et le cluster VMware Engine doivent se trouver dans la même Google Cloud région. VMware Engine n'est pas compatible avec le montage de datastores dans différentes régions. Pour les clouds privés étendus, seuls les datastores régionaux sont compatibles.
  • Protocole : VMware Engine n'est compatible qu'avec la version 3 de NFS (NFSv3) pour une utilisation en tant que datastore VMware Engine. NFSv4.1 n'est pas compatible.
  • Protection contre la suppression : si vous utilisez Filestore ou Google Cloud NetApp Volumes, vous devez activer la protection contre la suppression sur le volume pour éviter toute suppression accidentelle et perte de données.

Autorisations du compte de service VMware Engine

Pour créer et monter un datastore sauvegardé par Filestore ou Google Cloud NetApp Volumes, VMware Engine utilise un compte de service géré par Google pour accéder aux ressources NFS. Accordez les rôles IAM suivants au compte de service (service-PROJECT_NUMBER@gcp-sa-vmwareengine.iam.gserviceaccount.com) :

  • roles/compute.networkViewer : requis pour tous les types de Datastore afin d'afficher les appairages de réseaux. Accordez ce rôle sur le projet dans lequel réside le volume NFS. Si vous utilisez un VPC partagé, accordez plutôt ce rôle sur le projet hôte.
  • roles/file.viewer : requis pour les datastores sauvegardés par Filestore afin d'accéder aux instances Filestore. Accordez ce rôle sur le projet dans lequel réside Filestore.
  • roles/netapp.viewer : requis pour les datastores sauvegardés par Google Cloud NetApp Volumes afin d'accéder aux volumes Google Cloud NetApp Volumes. Accordez ce rôle sur le projet dans lequel réside Google Cloud NetApp Volumes.

Utilisez les commandes suivantes pour accorder ces rôles :

Lorsque vous accordez le rôle roles/compute.networkViewer pour une configuration de VPC partagé, veillez à remplacer l'ID de projet dans l'exemple par l'ID de votre projet hôte.

Pour 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

Pour 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

Remplacez les éléments suivants :

  • FILESTORE_PROJECT_ID : ID du projet dans lequel réside votre instance Filestore.
  • NETAPP_PROJECT_ID : ID du projet dans lequel réside votre volume Google Cloud NetApp Volumes.
  • PROJECT_NUMBER : numéro du projet dans lequel VMware Engine est activé.

Exigences concernant les sous-réseaux de service

Vous devez disposer d'un sous-réseau de service dédié avec une plage CIDR unique allouée au trafic NFS entre les hôtes ESXi et le volume NFS. Configurez le sous-réseau de service comme suit :

  • Vous devez configurer une plage CIDR pour le sous-réseau de service qui comporte suffisamment d'adresses IP pour en attribuer une à chaque nœud du cloud privé.
  • Vous ne pouvez utiliser le sous-réseau de service que pour le trafic des datastores NFS, mais vous pouvez connecter le même sous-réseau à plusieurs datastores NFS différents.
  • Vous devez ajouter l'allocation CIDR réservée pour le sous-réseau de service à la liste des clients autorisés ou à la stratégie d'exportation de votre volume NFS. Pour Filestore, ajoutez une règle de contrôle des accès pour la plage CIDR du sous-réseau de service. Pour Google Cloud NetApp Volumes, ajoutez le CIDR à la section Clients autorisés des règles d'exportation du volume.

Les règles de pare-feu distribuées et de passerelle NSX-T ne s'appliquent pas aux sous-réseaux de service.

Exigences concernant la connexion réseau

Une connexion active doit exister entre le réseau VPC du volume NFS et le réseau VMware Engine (VEN) du cloud privé dans lequel vous allez monter le datastore. Les frais de réseau résultant de l'accès au stockage dans une région ne s'appliquent pas lorsque vous utilisez Filestore avec l'accès aux services privés (PSA).

Lorsque vous vous connectez à des services de fichiers réseau, utilisez l'une des méthodes de connexion suivantes, en fonction du type de VEN de votre cloud privé :

  • VEN standard : les clouds privés créés dans un VEN standard utilisent l'appairage de réseaux VPC pour se connecter à des services de fichiers réseau tels que Filestore (à l'aide du PSA) ou Google Cloud NetApp Volumes.
  • VEN hérité : les clouds privés qui fonctionnent sur un VEN hérité nécessitent une connexion privée pour se connecter à des services de fichiers réseau. Si vous supprimez une connexion privée alors qu'un datastore NFS est en cours d'utilisation, l'accès au datastore sera interrompu. Par conséquent, veillez à ne pas supprimer de connexion privée lorsqu'un datastore NFS est monté et en cours d'utilisation.

Interopérabilité avec le cycle de vie du cloud privé

Les datastores NFS gérés par l'API VMware Engine restent persistants lors des événements du cycle de vie du cloud privé de la manière suivante :

  • Expansion et contraction du cluster : si vous ajoutez des nœuds à un cluster avec des datastores NFS montés, VMware Engine monte automatiquement ces datastores sur les nouveaux nœuds. Si vous supprimez des nœuds lors de la contraction d'un cluster, leurs adresses IP vmknic sont libérées.
  • Redémarrage du nœud : la configuration du datastore NFS sur un nœud est persistante et reste intacte après le redémarrage du nœud.
  • Mises à niveau logicielles : les datastores NFS montés sur des hôtes ne sont pas affectés par les mises à niveau des composants ESXi, vCenter et NSX-T.

Migration depuis les montages de datastores NFS hérités

Si vous avez créé des datastores NFS dans VMware Engine avant le 1er janvier 2026, vous utilisez le modèle hérité. Pour passer au modèle compatible et recommandé, contactez Cloud Customer Care pour lancer le processus de migration.

Problèmes connus

Voici les problèmes connus liés aux datastores NFS externes :

  • Lors de la suppression réversible d'un cloud privé, le chemin réseau vers le datastore est interrompu.
  • Une fois l'appairage de réseaux VPC établi, la propagation des routes vers les nœuds vSphere peut prendre jusqu'à 20 minutes.

Étape suivante