Utilisez les outils ONTAP pour VMware vSphere (meilleure pratique la plus importante) :

Utiliser une interface logique (LIF) unique pour chaque SVM sur chaque nœud du cluster ONTAP. Les recommandations précédentes d'une LIF par datastore ne sont plus nécessaires. L'accès direct (LIF et datastore sur le même nœud) est préférable, mais ne vous inquiétez pas pour l'accès indirect, car l'effet de performance est généralement minimal (microsecondes).

Toutes les versions de VMware vSphere actuellement prises en charge peuvent utiliser NFS v3 et v4.1. Le support officiel de nconnect a été ajouté à vSphere 8.0 mise à jour 2 pour NFS v3 et mise à jour 3 pour NFS v4.1. Pour NFS v4.1, vSphere continue à prendre en charge l'agrégation de sessions, l'authentification Kerberos et l'authentification Kerberos avec intégrité. Il est important de noter que l'agrégation de session nécessite ONTAP 9.14.1 ou une version ultérieure. Vous pouvez en savoir plus sur la fonction nconnect et sur la manière dont elle améliore les performances à "Fonctionnalité NFSv3 nconnect avec NetApp et VMware".

Notez que NFS v3 et NFS v4.1 utilisent différents mécanismes de verrouillage. NFS v3 utilise un verrouillage côté client, tandis que NFS v4.1 utilise un verrouillage côté serveur. Bien qu'un volume ONTAP puisse être exporté via les deux protocoles, ESXi ne peut monter qu'un datastore via un protocole. Cependant, cela ne signifie pas que d'autres hôtes ESXi ne peuvent pas monter le même datastore via une version différente. Pour éviter tout problème, il est essentiel de spécifier la version du protocole à utiliser lors du montage, en veillant à ce que tous les hôtes utilisent la même version et, par conséquent, le même style de verrouillage. Il est essentiel d'éviter de mélanger les versions NFS entre les hôtes. Si possible, utilisez les profils hôtes pour vérifier la conformité.

Les règles d'export NFS permettent de contrôler l'accès des hôtes vSphere. Vous pouvez utiliser une seule règle avec plusieurs volumes (datastores). Avec NFS, ESXi utilise le style de sécurité sys (UNIX) et requiert l'option de montage racine pour exécuter les VM. Dans ONTAP, cette option est appelée superutilisateur et, lorsque l'option superutilisateur est utilisée, il n'est pas nécessaire de spécifier l'ID utilisateur anonyme. Notez que les règles d'export-policy avec des valeurs différentes pour -anon et -allow-suid peuvent causer des problèmes de découverte de SVM avec les outils ONTAP. Les adresses IP doivent être séparées par des virgules, sans espaces dans les adresses de port vmkernel qui montés dans les datastores. Voici un exemple de règle de stratégie :

Si le plug-in NetApp NFS pour VMware VAAI est utilisé, le protocole doit être défini comme nfs lors de la création ou de la modification de la règle d'export policy. Le protocole NFSv4 est requis pour que le déchargement des copies VAAI fonctionne, et la spécification du protocole comme nfs inclut automatiquement les versions NFSv3 et NFSv4. Cette opération est requise même si le type de datastore est créé en tant que NFS v3.

Les volumes des datastores NFS sont rassemblés dans le volume racine du SVM. Par conséquent, ESXi doit également avoir accès au volume racine pour naviguer et monter des volumes de datastores. La export policy pour le volume root, et pour tout autre volume dans lequel la jonction du volume de datastore est imbriquée, doit inclure une règle ou des règles pour les serveurs ESXi leur accordant un accès en lecture seule. Voici un exemple de règle pour le volume racine, également à l'aide du plug-in VAAI :

Bien que ONTAP offre une structure d'espace de noms de volume flexible permettant d'organiser les volumes dans une arborescence à l'aide de jonctions, cette approche n'a aucune valeur pour vSphere. Il crée un répertoire pour chaque machine virtuelle à la racine du datastore, quelle que soit la hiérarchie de l'espace de noms du stockage. Il est donc recommandé de simplement monter le Junction path pour les volumes pour vSphere au volume root du SVM, c'est-à-dire comment les outils ONTAP pour VMware vSphere provisionne les datastores. Sans chemins de jonction imbriqués, aucun volume ne dépend d'aucun volume autre que le volume root et que mettre un volume hors ligne ou le détruire, même intentionnellement, n'affecte pas le chemin d'accès aux autres volumes.

Une taille de bloc de 4 Ko convient parfaitement aux partitions NTFS sur les datastores NFS. La figure suivante décrit la connectivité d'un hôte vSphere vers un datastore NFS ONTAP.