Flussi di lavoro di igroup e policy di esportazione negli ONTAP tools
Suggerisci modifiche
PDF
Utilizza queste informazioni per capire come ONTAP tools for VMware vSphere crea e gestisce gli igroup e le policy di esportazione per l'accesso al datastore.
In ONTAP tools for VMware vSphere 9.x, gli igroup venivano creati e gestiti in una struttura piatta, dove ogni datastore in vCenter era associato a un singolo igroup. Questo modello limitava la flessibilità e il riutilizzo degli igroup tra più datastore. ONTAP tools for VMware vSphere 10.4 introduce gli igroup nidificati, dove ogni datastore in vCenter è associato a un igroup padre, mentre ogni host è collegato a un igroup figlio sotto quel padre. Puoi definire igroup padre personalizzati con nomi scelti dall'utente per riutilizzarli tra i datastore e rendere più semplice la gestione degli igroup. Usa queste informazioni per capire come ONTAP tools for VMware vSphere gestisce LUN e datastore tramite i workflow degli igroup. Workflow diversi generano configurazioni di igroup differenti, come mostrato nei seguenti esempi:
|
I nomi menzionati sono solo a scopo illustrativo e non si riferiscono ai nomi reali dei gruppi igroup. Gli igroup gestiti dagli strumenti ONTAP utilizzano il prefisso “otv_”. È possibile assegnare qualsiasi nome agli igroup personalizzati. |
Termine |
Descrizione |
DS<numero> |
Datastore |
iqn<numero> |
IQN iniziatore |
host<numero> |
Ospita MoRef |
lun<numero> |
ID LUN |
<DSName>Igroup<numero> |
Gruppo padre predefinito (gestito dagli strumenti ONTAP) |
<Host-Moref>Igroup<numero> |
Gruppo infantile |
CustomIgroup<numero> |
Gruppo padre personalizzato definito dall'utente |
ClassicIgroup<numero> |
Igroup utilizzato nelle versioni 9.x degli strumenti ONTAP. |
Crea un datastore su un singolo host con un iniziatore
Flusso di lavoro: [Crea] DS1 (lun1): host1 (iqn1)
Risultato:
-
DS1Igroup:
-
host1Igroup → (iqn1: lun1)
-
ONTAP crea l'igroup padre DS1Igroup per DS1 e mappa l'igroup figlio host1Igroup su lun1. Il sistema mappa sempre i LUN sugli igroup figlio.
Montare il datastore esistente su un host aggiuntivo
Flusso di lavoro: [Montaggio] DS1 (lun1): host2 (iqn2)
Risultato:
-
DS1Igroup:
-
host1Igroup → (iqn1: lun1)
-
host2Igroup → (iqn2: lun1)
-
ONTAP tools per VMware vSphere crea un igroup figlio host2Igroup e lo aggiunge all'igroup padre esistente DS1Igroup.
Smontare un datastore da un host
Flusso di lavoro: [Smonta] DS1 (lun1): host1 (iqn1)
Risultato:
-
DS1Igroup:
-
host2Igroup → (iqn2: lun1)
-
Gli ONTAP tools for VMware vSphere rimuovono host1Igroup dalla gerarchia. Il sistema non elimina esplicitamente gli igroup figlio. Li elimina in queste due condizioni:
-
Se non viene mappato alcun LUN, il sistema ONTAP elimina l'igroup figlio.
-
Un processo di pulizia pianificato rimuove gli igroup figlio sospesi senza mapping LUN. Questi scenari si applicano solo agli igroup gestiti dagli strumenti ONTAP, non a quelli creati dall'utente.
Elimina archivio dati
Flusso di lavoro: [Elimina] DS1 (lun1): host2 (iqn2)
Risultato:
-
DS1Igroup:
-
host2Igroup → (iqn2: lun1)
-
Gli igroup padre e figlio vengono rimossi a meno che un altro datastore non riutilizzi l'igroup padre. Gli igroup figlio non vengono eliminati esplicitamente
Crea più datastore sotto un igroup padre personalizzato
Flusso di lavoro:
-
[Crea] DS2 (lun2): host1 (iqn1), host2 (iqn2)
-
[Crea] DS3 (lun3): host1 (iqn1), host3 (iqn3)
Risultato:
-
CustomIgroup1:
-
host1Igruppo → (iqn1: lun2, lun3)
-
host2Igroup → (iqn2: lun2)
-
host3Igroup → (iqn3: lun3)
-
CustomIgroup1 viene creato per DS2 e riutilizzato per DS3. Gli igroup figlio vengono creati o aggiornati sotto il padre condiviso, con ogni igroup figlio mappato alle relative LUN.
Elimina un datastore sotto un igroup padre personalizzato.
Flusso di lavoro: [Elimina] DS2 (lun2): host1 (iqn1), host2 (iqn2)
Risultato:
-
CustomIgroup1:
-
host1Igroup → (iqn1: lun3)
-
host3Igroup → (iqn3: lun3)
-
-
Anche se CustomIgroup1 non viene riutilizzato, non viene eliminato.
-
Se non viene mappato alcun LUN, il sistema ONTAP elimina host2Igroup.
-
host1Igroup non viene eliminato perché è mappato a lun3 di DS3. Gli igroup personalizzati non vengono mai eliminati, indipendentemente dallo stato di riutilizzo.
Espandi datastore vVols (Aggiungi volume)
Flusso di lavoro:
Prima dell'espansione:
[Espandi] DS4 (lun4): host4 (iqn4)
-
DS4Igroup: host4Igroup → (iqn4: lun4)
Dopo l'espansione:
[Espandi] DS4 (lun4, lun5): host4 (iqn4)
-
DS4Igroup: host4Igroup → (iqn4: lun4, lun5)
Viene creato un nuovo LUN e mappato all'igroup figlio esistente host4Igroup.
Riduci datastore vVols (rimuovi volume)
Flusso di lavoro:
Prima del restringimento:
[Riduci] DS4 (lun4, lun5): host4 (iqn4)
-
DS4Igroup: host4Igroup → (iqn4: lun4, lun5)
Dopo il restringimento:
[Riduci] DS4 (lun4): host4 (iqn4)
-
DS4Igroup: host4Igroup → (iqn4: lun4)
La LUN specificata (lun5) non è mappata dall'igroup figlio. L'igroup rimane attivo finché ha almeno una LUN mappata.
Migrazione dagli strumenti ONTAP 9 a 10 (normalizzazione igroup)
Flusso di lavoro
Gli ONTAP tools for VMware vSphere versione 9.x non supportano gli igroup gerarchici. Durante la migrazione alle versioni 10.3 o successive, gli igroup devono essere normalizzati nella struttura gerarchica.
Prima della migrazione:
[Migrazione] DS6 (lun6, lun7): host6 (iqn6), host7 (iqn7) → ClassicIgroup1 (iqn6 e iqn7: lun6, lun7)
La logica degli strumenti ONTAP 9.x consente più iniziatori per igroup senza imporre la mappatura host uno a uno.
Dopo la migrazione:
[Migrazione] DS6 (lun6, lun7): host6 (iqn6), host7 (iqn7) → ClassicIgroup1: otv_ClassicIgroup1 (iqn6 e iqn7: lun6, lun7)
Durante la migrazione:
-
Viene creato un nuovo igroup padre (ClassicIgroup1).
-
L'igroup originale viene rinominato con il prefisso otv_ e diventa un igroup figlio.
Ciò garantisce il rispetto del modello gerarchico.
A partire da ONTAP tools 10.5P2, gli igroup migrati vengono eliminati quando non sono più in uso. Nelle versioni precedenti, gli igroup migrati non venivano mai rimossi. Nota quanto segue:
-
Gli igroup migrati non possono essere riutilizzati tra datastore diversi.
-
Gli igroup personalizzati (definiti dall'utente) non vengono mai eliminati e possono essere riutilizzati.
Policy di esportazione
I criteri di esportazione controllano l'accesso al datastore NFS e le autorizzazioni client negli ONTAP tools for VMware vSphere. Le policy di esportazione vengono create e gestite nei sistemi ONTAP e possono essere utilizzate con gli archivi dati NFS per applicare il controllo degli accessi. Ogni policy di esportazione è composta da regole che specificano i client (indirizzi IP o subnet) a cui è consentito l'accesso e le autorizzazioni concesse (sola lettura o lettura-scrittura).
Quando si crea un datastore NFS negli strumenti ONTAP per VMware vSphere, è possibile selezionare una policy di esportazione esistente o crearne una nuova. La policy di esportazione viene quindi applicata al datastore, garantendo che solo i client autorizzati possano accedervi.
Quando si monta un datastore NFS su un nuovo host ESXi, gli strumenti ONTAP per VMware vSphere aggiungono l'indirizzo IP dell'host alla policy di esportazione esistente associata al datastore. Ciò consente al nuovo host di accedere al datastore senza dover creare una nuova policy di esportazione.
Quando elimini o smonti un datastore NFS da un host ESXi, ONTAP tools for VMware vSphere rimuove l'indirizzo IP dell'host dalla policy di esportazione. Se nessun altro host utilizza quella policy di esportazione, verrà eliminata. Quando elimini un datastore NFS, ONTAP tools for VMware vSphere rimuove la policy di esportazione associata a quel datastore se non viene riutilizzata da altri datastore. Se la policy di esportazione viene riutilizzata, mantiene l'indirizzo IP dell'host e non cambia. Quando elimini i datastore, ONTAP tools rimuove l'indirizzo IP dell'host dalla policy di esportazione e assegna la policy di esportazione predefinita se ONTAP richiede l'accesso.
L'assegnazione della policy di esportazione varia a seconda che venga riutilizzata su datastore diversi. Quando si riutilizza la policy di esportazione, è possibile aggiungerla con il nuovo indirizzo IP host. Quando si elimina o si smonta un datastore che utilizza una policy di esportazione condivisa, la policy non verrà eliminata. Rimane invariata e l'indirizzo IP host non viene rimosso, poiché è condivisa con gli altri datastore. Il riutilizzo delle policy di esportazione è sconsigliato, poiché può causare problemi di accesso e latenza.