Dans vSphere, il existe trois façons d'utiliser les LUN de stockage bloc :

VMFS est un système de fichiers en cluster hautes performances qui fournit des datastores sous forme de pools de stockage partagés. Les datastores VMFS peuvent être configurés avec des LUN accessibles via des espaces de noms FC, iSCSI, FCoE ou NVMe accessibles via le protocole NVMe/FC. VMFS permet d'accéder simultanément aux LUN classiques par chaque serveur ESX d'un cluster. La taille de LUN maximale du ONTAP est généralement de 16 To. Par conséquent, un datastore VMFS 5 de 64 To (voir le premier tableau de cette section) est créé avec quatre LUN de 16 To (tous les systèmes SAN prennent en charge la taille de LUN VMFS de 64 To maximum). Dans la mesure où l'architecture LUN ONTAP ne dispose pas de petites profondeurs de files d'attente individuelles, les datastores VMFS en ONTAP peuvent évoluer plus largement qu'avec les architectures de baies traditionnelles de manière relativement simple.

VSphere inclut la prise en charge intégrée de plusieurs chemins d'accès aux périphériques de stockage, appelés chemins d'accès multiples natifs (NMP). NMP peut détecter le type de stockage pour les systèmes de stockage pris en charge et configure automatiquement la pile NMP afin de prendre en charge les capacités du système de stockage utilisé.

NMP et ONTAP prennent en charge le protocole ALUA (Asymmetric Logical Unit Access) pour négocier des chemins optimisés et non optimisés. Dans ONTAP, un chemin optimisé pour le protocole ALUA suit un chemin d'accès direct aux données, utilisant un port cible sur le nœud qui héberge la LUN accédée. ALUA est activé par défaut dans vSphere et ONTAP. Le NMP reconnaît le cluster ONTAP en tant que ALUA, et il utilise le plug-in ALUA de type baie de stockage (VMW_SATP_ALUA) et sélectionne le plug-in de sélection de chemin d'accès rond (VMW_PSP_RR).

ESXi 6 prend en charge jusqu'à 256 LUN et jusqu'à 1,024 chemins d'accès aux LUN au total. Les LUN et les chemins au-delà de ces limites ne sont pas visibles par ESXi. En supposant un nombre maximum de LUN, la limite de chemin autorise quatre chemins par LUN. Dans un cluster ONTAP plus grand, il est possible d'atteindre la limite de chemin avant la limite de LUN. Pour résoudre cette limitation, ONTAP prend en charge le mappage de LUN sélectif (SLM) dans la version 8.3 et les versions ultérieures.

SLM limite les nœuds qui annoncent les chemins vers une LUN donnée. Il est recommandé à NetApp d'utiliser au moins une LIF par nœud par SVM et SLM pour limiter les chemins annoncés vers le nœud hébergeant la LUN et son partenaire de haute disponibilité. Bien que d'autres chemins existent, ils ne sont pas annoncés par défaut. Il est possible de modifier les chemins annoncés avec les arguments de noeud de rapport ajouter et supprimer dans SLM. Notez que les LUN créées dans les versions antérieures à la version 8.3 annoncent tous les chemins et doivent être modifiés pour uniquement annoncer les chemins d'accès à la paire HA d'hébergement. Pour plus d'informations sur SLM, consultez la section 5.9 de "TR-4080". La méthode précédente de ensembles de ports peut également être utilisée pour réduire davantage les chemins disponibles pour une LUN. Les jeux de ports permettent de réduire le nombre de chemins visibles via lesquels les initiateurs d'un groupe initiateur peuvent voir les LUN.

Des protocoles de bloc (iSCSI, FC et FCoE) accèdent aux LUN à l'aide d'identifiants de LUN, de numéros de série et de noms uniques. Les protocoles FC et FCoE utilisent des noms mondiaux (WWN et WWPN) et iSCSI utilise les noms qualifiés iSCSI (IQN). Le chemin vers les LUN à l'intérieur du stockage n'a aucun sens avec les protocoles de bloc et n'est pas présenté au niveau du protocole. Par conséquent, un volume contenant uniquement des LUN n'a pas besoin d'être monté en interne et un chemin de jonction n'est pas nécessaire pour les volumes contenant les LUN utilisées dans les datastores. Le sous-système NVMe dans ONTAP fonctionne de la même manière.

D'autres meilleures pratiques à prendre en compte :

VSphere permet aux clients d'utiliser des baies NFS de classe entreprise pour fournir un accès simultané aux datastores à tous les nœuds d'un cluster ESXi. Comme mentionné dans la section datastore, la facilité d'utilisation et la visibilité sur l'efficacité du stockage présentent des avantages avec NFS avec vSphere.

Nous vous recommandons les meilleures pratiques suivantes lorsque vous utilisez ONTAP NFS avec vSphere :

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é.
Comme il n'y a pas de conversion automatique des datastores entre NFSv3 et NFSv4.1, créez un nouveau datastore NFSv4.1 et utilisez Storage vMotion pour migrer les machines virtuelles vers le nouveau datastore.
Reportez-vous aux notes du tableau interopérabilité NFS v4.1 dans le "Matrice d'interopérabilité NetApp" Pour les niveaux de correctifs VMware ESXi spécifiques requis pour la prise en charge.
* Les règles d'exportation NFS sont utilisées pour contrôler l'accès par les hôtes vSphere. Vous pouvez utiliser une seule règle avec plusieurs volumes (datastores). Avec NFSv3, ESXi utilise le style de sécurité sys (UNIX) et requiert l'option de montage root 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 l'export-policy rules avec des valeurs différentes de -anon et -allow-suid Peut entraîner des problèmes de découverte des SVM à l'aide des outils ONTAP. Voici un exemple de politique :
Protocole d'accès : nfs3
Client Match Spec : 192.168.42.21
Règle d'accès RO : sys
RW règle d'accès : sys
UID anonyme
Superutilisateur : sys
* Si le plug-in NetApp NFS pour VMware VAAI est utilisé, le protocole doit être défini comme nfs lorsque la règle export-policy est créée ou modifiée. Le protocole NFSv4 est requis pour que le déchargement des copies VAAI fonctionne et que vous spécifiez le protocole comme nfs Inclut automatiquement les versions NFSv3 et NFSv4.
* Les volumes de datastore NFS sont reliés par jonction au volume root du SVM ; par conséquent, ESXi doit également avoir accès au volume root pour naviguer et monter les volumes de datastore. 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 :
Protocole d'accès : nfs (qui inclut nfs3 et nfs4)
Client Match Spec : 192.168.42.21
Règle d'accès RO : sys
RW Access Rule: Never (meilleure sécurité pour le volume root)
UID anonyme
Superuser : sys (également requis pour le volume root avec VAAI)
* Utilisez les outils ONTAP pour VMware vSphere (meilleure pratique la plus importante) :
Utiliser les outils ONTAP pour VMware vSphere pour provisionner les datastores car cela simplifie automatiquement la gestion des règles d'exportation.
Lors de la création de datastores pour clusters VMware avec le plug-in, sélectionnez le cluster plutôt qu'un seul serveur ESX. Ce choix permet de monter automatiquement le datastore sur tous les hôtes du cluster.
Utilisez la fonction de montage du plug-in pour appliquer les datastores existants aux nouveaux serveurs.
Lorsque vous n'utilisez pas les outils ONTAP pour VMware vSphere, utilisez une règle d'exportation unique pour tous les serveurs ou pour chaque cluster de serveurs pour lesquels un contrôle d'accès supplémentaire est nécessaire.
* Bien que ONTAP offre une structure d'espace de noms de volume flexible pour organiser les volumes dans une arborescence à l'aide de jonctions, cette approche n'a pas de 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 pour les partitions NTFS sur les datastores NFS. La figure suivante décrit la connectivité d'un hôte vSphere vers un datastore NFS ONTAP.

Le tableau suivant répertorie les versions NFS et les fonctionnalités prises en charge.

Les administrateurs du stockage préfèrent parfois simplifier leurs infrastructures en supprimant les commutateurs réseau de la configuration. Cela peut être pris en charge dans certains scénarios.