Workflows de groupe initiateur (Igroup) et de règles d'export dans les outils ONTAP
Suggérer des modifications
PDF
Utilisez ces informations pour comprendre comment ONTAP tools for VMware vSphere crée et gère les igroups et les règles d'export pour l'accès aux datastores.
Dans ONTAP tools for VMware vSphere 9.x, les igroups étaient créés et gérés selon une structure plate, où chaque datastore dans vCenter était associé à un seul igroup. Ce modèle limitait la flexibilité et la réutilisation des igroups entre plusieurs datastores. ONTAP tools for VMware vSphere 10.4 introduit les igroups imbriqués, où chaque datastore dans vCenter est associé à un igroup parent, tandis que chaque hôte est lié à un igroup enfant sous ce parent. Vous pouvez définir des igroups parents personnalisés avec des noms définis par l'utilisateur pour une réutilisation entre les datastores afin de faciliter la gestion des igroups. Utilisez ces informations pour comprendre comment ONTAP tools for VMware vSphere gère les LUN et les datastores via les workflows d'igroup. Différents workflows génèrent des configurations d'igroup différentes, 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)
-
ONTAP tools for VMware vSphere crée un igroup enfant host2Igroup et l’ajoute à l’igroup 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
ONTAP tools for VMware vSphere versions 9.x ne prennent pas en charge les igroups hiérarchiques. Lors de la migration vers les versions 10.3 ou supérieures, les igroups doivent être normalisés selon une 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.
À partir d'ONTAP tools 10.5P2, les igroups migrés sont supprimés lorsqu'ils ne sont plus utilisés. Dans les versions précédentes, les igroups migrés n'étaient jamais supprimés. Remarque :
-
Les igroups migrés ne peuvent pas être réutilisés entre les banques de données.
-
Les igroups personnalisés (définis par l'utilisateur) ne sont jamais supprimés et peuvent toujours être réutilisés.
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, ONTAP tools for VMware vSphere supprime l'adresse IP de l'hôte de la règles d'export. Si aucun autre hôte n'utilise cette règles d'export, elle sera supprimée. Lorsque vous supprimez une banque de données NFS, ONTAP tools for VMware vSphere supprime la règles d'export associée à cette banque de données si elle n'est pas réutilisée par d'autres banques de données. Si la règles d'export est réutilisée, elle conserve l'adresse IP de l'hôte et ne change pas. Lorsque vous supprimez des banques de données, ONTAP tools supprime l'adresse IP de l'hôte de la règles d'export et attribue la règles d'export par défaut si ONTAP requiert un accès.
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.