Comprendre les groupes i et les stratégies d'exportation dans les outils ONTAP pour VMware vSphere
Suggérer des modifications
PDF
Les groupes d'initiateurs (igroups) sont des tables de noms de port mondiaux (WWPN) d'hôte de protocole FC ou de noms de nœuds qualifiés d'hôte iSCSI. Vous pouvez définir des groupes initiateurs et les mapper sur des LUN pour contrôler l'accès des initiateurs aux LUN.
Dans les ONTAP tools for VMware vSphere 9.x, les igroups étaient créés et gérés dans une structure plate, où chaque banque de données dans vCenter était associée à un seul igroup. Ce modèle limitait la flexibilité et la réutilisation des igroups sur plusieurs banques de données. Les ONTAP tools for VMware vSphere introduisent des igroups imbriqués, où chaque banque de données de vCenter est associée à un igroup parent, tandis que chaque hôte est lié à un igroup enfant sous ce parent. Vous pouvez définir des groupes parents personnalisés avec des noms définis par l'utilisateur pour les réutiliser dans les banques de données afin de faciliter la gestion des groupes. Comprendre le flux de travail igroup pour gérer les LUN et les banques de données dans les ONTAP tools for VMware vSphere. Différents flux de travail génèrent des configurations igroup variables, comme illustré dans les exemples suivants :
|
Les noms mentionnés sont uniquement à des fins d'illustration et ne font pas référence aux vrais noms de groupes i. Les groupes gérés par les outils ONTAP utilisent le préfixe « otv_ ». Les groupes i personnalisés peuvent recevoir n'importe quel nom. |
Terme |
Description |
DS<numéro> |
Datastore |
iqn<nombre> |
IQN initiateur |
hôte<numéro> |
Hébergeur MoRef |
lun<numéro> |
IDENTIFIANT DE LUN |
<DSName>Igroup<numéro> |
Groupe parent par défaut (géré par les outils ONTAP) |
<Host-Moref>Igroup<numéro> |
Groupe d'enfants |
CustomIgroup<numéro> |
Groupe parent personnalisé défini par l'utilisateur |
ClassicIgroup<numéro> |
Igroup utilisé dans les versions 9.x des outils ONTAP. |
Créer une banque de données sur un seul hôte avec un seul initiateur
Workflow : [Créer] DS1 (lun1) : host1 (iqn1)
Résultat:
-
DS1Igroup :
-
hôte1Igroupe → (iqn1: lun1)
-
ONTAP crée le groupe parent DS1Igroup pour DS1 et mappe le groupe enfant host1Igroup à lun1. Le système mappe toujours les LUN aux groupes enfants.
Monter le magasin de données existant sur un hôte supplémentaire
Workflow : [Montage] DS1 (lun1) : host2 (iqn2)
Résultat:
-
DS1Igroup :
-
hôte1Igroupe → (iqn1: lun1)
-
host2Igroup → (iqn2: lun1)
-
Les ONTAP tools for VMware vSphere créent un groupe i enfant host2Igroup et l'ajoutent au groupe i parent existant DS1Igroup.
Démonter une banque de données d'un hôte
Workflow : [Démonter] DS1 (lun1) : hôte1 (iqn1)
Résultat:
-
DS1Igroup :
-
host2Igroup → (iqn2: lun1)
-
Les ONTAP tools for VMware vSphere suppriment host1Igroup de la hiérarchie. Le système ne supprime pas explicitement les groupes enfants. Il les supprime sous ces deux conditions :
-
Si aucun LUN n'est mappé, le système ONTAP supprime le groupe i enfant.
-
Une tâche de nettoyage planifiée supprime les groupes enfants suspendus sans mappages LUN. Ces scénarios s'appliquent uniquement aux groupes gérés par les outils ONTAP, et non à ceux créés sur mesure.
Supprimer le magasin de données
Workflow : [Supprimer] DS1 (lun1) : host2 (iqn2)
Résultat:
-
DS1Igroup :
-
host2Igroup → (iqn2: lun1)
-
Les groupes i parents et enfants sont supprimés, sauf si une autre banque de données réutilise le groupe i parent. Les groupes enfants ne sont pas explicitement supprimés
Créer plusieurs banques de données sous un groupe parent personnalisé
Flux de travail:
-
[Créer] DS2 (lun2) : host1 (iqn1), host2 (iqn2)
-
[Créer] DS3 (lun3) : host1 (iqn1), host3 (iqn3)
Résultat:
-
CustomIgroup1 :
-
hôte1Igroup → (iqn1 : lun2, lun3)
-
host2Igroup → (iqn2: lun2)
-
host3Igroup → (iqn3: lun3)
-
CustomIgroup1 est créé pour DS2 et réutilisé pour DS3. Les groupes d'applications enfants sont créés ou mis à jour sous le parent partagé, chaque groupe d'applications enfant étant mappé à ses LUN respectifs.
Supprimez un magasin de données sous un groupe parent personnalisé.
Workflow : [Supprimer] DS2 (lun2) : host1 (iqn1), host2 (iqn2)
Résultat:
-
CustomIgroup1 :
-
hôte1Igroupe → (iqn1 : lun3)
-
host3Igroup → (iqn3: lun3)
-
-
Même si CustomIgroup1 n'est pas réutilisé, il n'est pas supprimé.
-
Si aucun LUN n'est mappé, le système ONTAP supprime host2Igroup.
-
Le groupe hôte1 n'est pas supprimé, car il est mappé sur lun3 de DS3. Les groupes personnalisés ne sont jamais supprimés, quel que soit leur statut de réutilisation.
Développer la banque de données vVols (ajouter un volume)
Flux de travail:
Avant l'extension :
[Développer] DS4 (lun4) : host4 (iqn4)
-
DS4Igroup : host4Igroup → (iqn4 : lun4)
Après l'extension :
[Développer] DS4 (lun4, lun5) : host4 (iqn4)
-
DS4Igroup : host4Igroup → (iqn4 : lun4, lun5)
Un nouveau LUN est créé et mappé au groupe enfant existant host4Igroup.
Réduire le volume de la banque de données vVols (Supprimer le volume)
Flux de travail:
Avant rétrécissement :
[Rétrécir] DS4 (lun4, lun5) : host4 (iqn4)
-
DS4Igroup : host4Igroup → (iqn4 : lun4, lun5)
Après rétrécissement :
[Rétrécir] DS4 (lun4) : host4 (iqn4)
-
DS4Igroup : host4Igroup → (iqn4 : lun4)
Le LUN spécifié (lun5) est dissocié du groupe d'objets enfant. Ce groupe reste actif tant qu'il possède au moins un LUN mappé.
Migration des outils ONTAP 9 vers 10 (normalisation igroup)
Workflow
Les outils ONTAP pour les versions VMware vSPhere 9.x ne prennent pas en charge les groupes hiérarchiques. Lors de la migration vers les versions 10.3 ou supérieures, les igroups doivent être normalisés dans la structure hiérarchique.
Avant la migration :
[Migration] DS6 (lun6, lun7) : host6 (iqn6), host7 (iqn7) → ClassicIgroup1 (iqn6 et iqn7 : lun6, lun7)
La logique des outils ONTAP 9.x autorise plusieurs initiateurs par igroup sans imposer de mappage d'hôte un à un.
Après la migration :
[Migration] DS6 (lun6, lun7) : host6 (iqn6), host7 (iqn7) → ClassicIgroup1 : otv_ClassicIgroup1 (iqn6 et iqn7 : lun6, lun7)
Pendant la migration :
-
Un nouveau groupe parent (ClassicIgroup1) est créé.
-
L'igroup d'origine est renommé avec le préfixe otv_ et devient un igroup enfant.
Cela garantit le respect du modèle hiérarchique.
Export-policies
Les politiques d'exportation contrôlent l'accès à la banque de données NFS et les autorisations client dans les ONTAP tools for VMware vSphere. Les politiques d’exportation sont créées et gérées dans les systèmes ONTAP et peuvent être utilisées avec les banques de données NFS pour appliquer le contrôle d’accès. Chaque politique d'exportation se compose de règles qui spécifient les clients (adresses IP ou sous-réseaux) autorisés à accéder et les autorisations accordées (lecture seule ou lecture-écriture).
Lorsque vous créez une banque de données NFS dans les outils ONTAP pour VMware vSphere, vous pouvez sélectionner une politique d'exportation existante ou en créer une nouvelle. Cette politique est ensuite appliquée à la banque de données, garantissant ainsi que seuls les clients autorisés y ont accès.
Lorsque vous montez une banque de données NFS sur un nouvel hôte ESXi, les outils ONTAP pour VMware vSphere ajoutent l'adresse IP de l'hôte à la stratégie d'exportation existante associée à la banque de données. Cela permet au nouvel hôte d'accéder à la banque de données sans créer de nouvelle stratégie d'exportation.
Lorsque vous supprimez ou démontez une banque de données NFS d'un hôte ESXi, les ONTAP tools for VMware vSphere suppriment l'adresse IP de l'hôte de la stratégie d'exportation. Si aucun autre hôte n’utilise cette politique d’exportation, elle sera supprimée. Lorsque vous supprimez une banque de données NFS, les ONTAP tools for VMware vSphere suppriment la stratégie d'exportation associée à cette banque de données si elle n'est pas réutilisée par d'autres banques de données. Si la politique d’exportation est réutilisée, elle conserve l’adresse IP de l’hôte et ne change pas. Lorsque vous supprimez les banques de données, la politique d'exportation annule l'attribution de l'adresse IP de l'hôte et attribue une politique d'exportation par défaut, afin que les systèmes ONTAP puissent y accéder si nécessaire.
L'attribution de la stratégie d'exportation diffère selon la réutilisation entre différents magasins de données. Lorsque vous réutilisez la stratégie d'exportation, vous pouvez lui ajouter la nouvelle adresse IP de l'hôte. Lorsque vous supprimez ou démontez un magasin de données utilisant une stratégie d'exportation partagée, celle-ci n'est pas supprimée. Elle reste inchangée et l'adresse IP de l'hôte n'est pas supprimée, car elle est partagée avec les autres magasins de données. La réutilisation des stratégies d'exportation est déconseillée, car elle peut entraîner des problèmes d'accès et de latence.