Skip to main content
ONTAP tools for VMware vSphere 105
Une version plus récente de ce produit est disponible.
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Comment les ONTAP tools gèrent les igroups et les politiques d'exportation

Contributeurs netapp-revathid
PDF

Les groupes d'initiateurs (igroups) sont des tables de noms de port mondiaux (WWPN) d'hôtes du protocole FC ou de noms de nœuds qualifiés iSCSI d'hôtes. Vous pouvez définir des igroups et les associer à des LUN pour contrôler quels initiateurs ont accès aux LUN.

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 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. Comprenez le flux de travail des igroups pour gérer les LUN et les datastores dans ONTAP tools for VMware vSphere. Différents flux de travail génèrent des configurations d'igroups différentes, comme illustré dans les exemples suivants :

Remarque Les noms mentionnés sont donnés à titre d'exemple uniquement et ne correspondent pas à de vrais noms d'igroups. Les igroups gérés par ONTAP tools utilisent le préfixe « otv_ ». Les igroups personnalisés peuvent porter n'importe quel nom.

Terme

Description

DS<number>

Magasin de données

iqn<number>

IQN de l'initiateur

hôte<number>

Hôte MoRef

lun<number>

ID LUN

<DSName>Igroup<number>

Groupe parent par défaut (géré par ONTAP tools) igroup

<Host-Moref>Igroup<number>

igroup enfant

CustomIgroup<number>

Groupe parent igroup personnalisé défini par l'utilisateur

ClassicIgroup<number>

Igroup utilisé dans les versions 9.x des outils ONTAP.
Exemple 1 :

Créer un datastore sur un seul hôte avec un seul initiateur

Flux de travail : [Create] DS1 (lun1) : host1 (iqn1)

Résultat:

  • DS1Igroup :

    • host1Igroup → (iqn1: lun1)

ONTAP crée le parent igroup DS1Igroup pour DS1 et associe le child igroup host1Igroup à lun1. Le système associe toujours les LUN à des child igroups.

Exemple 2 :

Monter la banque de données existante sur un hôte supplémentaire

Flux de travail : [Mount] DS1 (lun1) : host2 (iqn2)

Résultat:

  • DS1Igroup :

    • host1Igroup → (iqn1: lun1)

    • host2Igroup → (iqn2: lun1)

Les outils ONTAP pour VMware vSphere créent un igroup enfant host2Igroup et l'ajoutent à l'igroup parent existant DS1Igroup.

Exemple 3 :

Démontez un datastore d'un hôte

Workflow : [Démonter] DS1 (lun1) : host1 (iqn1)

Résultat:

  • DS1Igroup :

    • host2Igroup → (iqn2: lun1)

ONTAP tools for VMware vSphere suppriment host1Igroup de la hiérarchie. Le système ne supprime pas explicitement les igroups enfants. Il les supprime dans les deux cas suivants :

  • Si aucun LUN n'est mappé, le système ONTAP supprime l'igroup enfant.

  • Une tâche de nettoyage planifiée supprime les igroups enfants orphelins sans mappage LUN. Ces scénarios concernent uniquement les igroups gérés par les ONTAP tools, et non ceux créés sur mesure.

Exemple 4 :

Supprimer le datastore

Flux de travail : [Delete] DS1 (lun1) : host2 (iqn2)

Résultat:

  • DS1Igroup :

    • host2Igroup → (iqn2: lun1)

Les igroups parents et enfants sont supprimés, sauf si un autre datastore réutilise l'igroup parent. Les igroups enfants ne sont pas explicitement supprimés

Exemple 5 :

Créez plusieurs datastores sous un igroup parent personnalisé

Flux de travail :

  • [Créer] DS2 (lun2) : hôte1 (iqn1), hôte2 (iqn2)

  • [Créer] DS3 (lun3): hôte1 (iqn1), hôte3 (iqn3)

Résultat:

  • CustomIgroup1 :

    • host1Igroup → (iqn1 : lun2, lun3)

    • host2Igroup → (iqn2: lun2)

    • host3Igroup → (iqn3: lun3)

CustomIgroup1 est créé pour DS2 et réutilisé pour DS3. Les igroups enfants sont créés ou mis à jour sous le parent partagé, chaque igroup enfant étant associé à ses LUNs correspondants.

Exemple 6 :

Supprimez un datastore sous un igroup parent personnalisé.

Flux de travail : [Supprimer] DS2 (lun2) : hôte1 (iqn1), hôte2 (iqn2)

Résultat:

  • CustomIgroup1 :

    • host1Igroup → (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.

  • host1Igroup n'est pas supprimé car il est associé à lun3 de DS3. Les igroups personnalisés ne sont jamais supprimés, quel que soit leur statut de réutilisation.

Exemple 7 :

Agrandir le datastore vVols (Ajouter un volume)

Flux de travail :

Avant l'expansion :

[Développer] DS4 (lun4): hôte4 (iqn4)

  • DS4Igroup : host4Igroup → (iqn4 : lun4)

Après l'expansion :

[Développer] DS4 (lun4, lun5) : hôte4 (iqn4)

  • DS4Igroup : host4Igroup → (iqn4 : lun4, lun5)

Un nouveau LUN est créé et mappé au groupe d'initiateurs enfant existant host4Igroup.

Exemple 8 :

Réduire le datastore vVols (Supprimer le volume)

Flux de travail :

Avant le rétrécissement :

[Réduction] DS4 (lun4, lun5) : hôte4 (iqn4)

  • DS4Igroup : host4Igroup → (iqn4 : lun4, lun5)

Après rétrécissement :

[Réduction] DS4 (lun4): hôte4 (iqn4)

  • DS4Igroup : host4Igroup → (iqn4 : lun4)

Le LUN spécifié (lun5) est dé-mappé de l'igroup enfant. L'igroup reste actif tant qu'il possède au moins un LUN mappé.

Exemple 9 :

Migration des outils ONTAP 9 vers 10 (normalisation des igroups)

Flux de travail

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) : hôte6 (iqn6), hôte7 (iqn7) → ClassicIgroup1 (iqn6 & iqn7 : lun6, lun7)

La logique des ONTAP tools 9.x permet plusieurs initiateurs par igroup sans imposer de correspondance un-à-un entre hôte et igroup.

Après la migration :

[Migration] DS6 (lun6, lun7) : hôte6 (iqn6), hôte7 (iqn7) → ClassicIgroup1 : otv_ClassicIgroup1 (iqn6 & iqn7 : lun6, lun7)

Pendant la migration :

  • Un nouveau groupe initiateur parent (ClassicIgroup1) est créé.

  • L'igroup d'origine est renommé avec le préfixe otv_ et devient un igroup enfant.

Cela garantit la conformité avec le 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.

Sujets connexes

"À propos des igroups"

Politiques d'export

Les règles d'export contrôlent l'accès aux datastores NFS et les permissions client dans ONTAP tools for VMware vSphere. Les règles d'export sont créées et gérées dans les systèmes ONTAP et peuvent être utilisées avec les datastores NFS pour appliquer le contrôle d'accès. Chaque règle d'export se compose de règles qui spécifient les clients (adresses IP ou sous-réseaux) autorisés à accéder et les permissions accordées (lecture seule ou lecture-écriture).

Lorsque vous créez une banque de données NFS dans ONTAP tools for VMware vSphere, vous pouvez sélectionner une règle d'export existante ou en créer une nouvelle. La règle d'export est ensuite appliquée à la banque de données, garantissant que seuls les clients autorisés peuvent y accéder.

Lors du montage d'une banque de données NFS sur un nouvel hôte ESXi, ONTAP tools for VMware vSphere ajoute l'adresse IP de l'hôte à la règle d'export associée à la banque de données. Cela permet au nouvel hôte d'accéder à la banque de données sans avoir à créer une nouvelle règle d'export.

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ègle d'export. Si aucun autre hôte n'utilise cette règle d'export, elle sera supprimée. Lorsque vous supprimez une banque de données NFS, ONTAP tools for VMware vSphere supprime la règle 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ègle d'export 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 règle d'export désassocie l'adresse IP de l'hôte et attribue une règle d'export par défaut, afin que les systèmes ONTAP puissent y accéder si nécessaire.

L'attribution des règles d'export diffère lorsqu'elles sont réutilisées sur différents datastores. Lorsque vous réutilisez la règle d'export, vous pouvez y ajouter la nouvelle adresse IP de l'hôte. Lorsque vous supprimez ou démontez un datastore qui utilise une règle d'export partagée, la règle ne sera pas supprimée. Elle reste inchangée et l'adresse IP de l'hôte n'est pas retirée, car elle est partagée avec les autres datastores. La réutilisation des règles d'export n'est pas recommandée, car cela peut entraîner des problèmes d'accès et de latence.

Sujets connexes

"Créer une règles d'export"