In vSphere, esistono tre modi per utilizzare le LUN dello storage a blocchi:

VMFS è un file system in cluster dalle performance elevate che fornisce datastore che sono pool di storage condivisi. Gli archivi dati VMFS possono essere configurati con LUN a cui si accede utilizzando spazi dei nomi FC, iSCSI, FCoE o NVMe a cui si accede dal protocollo NVMe/FC. VMFS consente l'accesso simultaneo alle LUN tradizionali da parte di ogni server ESX in un cluster. La dimensione massima del LUN ONTAP è generalmente di 16 TB; pertanto, un datastore VMFS 5 di 64 TB (vedere la prima tabella di questa sezione) viene creato utilizzando quattro LUN da 16 TB (tutti i sistemi array SAN supportano la dimensione massima del LUN VMFS di 64 TB). Poiché l'architettura LUN di ONTAP non ha una profondità di coda singola ridotta, gli archivi dati VMFS in ONTAP possono scalare in maniera relativamente semplice rispetto alle architetture di array tradizionali.

VSphere include il supporto integrato per più percorsi verso i dispositivi storage, definito NMP (Native Multipathing). NMP è in grado di rilevare il tipo di storage per i sistemi storage supportati e di configurare automaticamente lo stack NMP per supportare le funzionalità del sistema storage in uso.

Sia NMP che ONTAP supportano l'ALUA (Asymmetric Logical Unit Access) per negoziare percorsi ottimizzati e non ottimizzati. In ONTAP, un percorso ottimizzato per ALUA segue un percorso di dati diretto, utilizzando una porta di destinazione sul nodo che ospita il LUN a cui si accede. ALUA è attivato per impostazione predefinita sia in vSphere che in ONTAP. NMP riconosce il cluster ONTAP come ALUA e utilizza il plug-in del tipo di array di storage ALUA (VMW_SATP_ALUA) e seleziona il plug-in di selezione del percorso round-robin (VMW_PSP_RR).

ESXi 6 supporta fino a 256 LUN e fino a 1,024 percorsi totali verso LUN. I LUN o i percorsi che superano questi limiti non sono visti da ESXi. Supponendo il numero massimo di LUN, il limite di percorso consente quattro percorsi per LUN. In un cluster ONTAP più grande, è possibile raggiungere il limite di percorso prima del limite di LUN. Per risolvere questo limite, ONTAP supporta la mappa LUN selettiva (SLM) nella versione 8.3 e successive.

SLM limita i nodi che pubblicizzano i percorsi a una determinata LUN. È una Best practice di NetApp avere almeno una LIF per nodo per SVM e utilizzare SLM per limitare i percorsi pubblicizzati al nodo che ospita la LUN e il suo partner ha. Sebbene esistano altri percorsi, essi non vengono pubblicizzati per impostazione predefinita. È possibile modificare i percorsi pubblicizzati con gli argomenti del nodo di reporting add e remove all'interno di SLM. Si noti che i LUN creati nelle release precedenti alla 8,3 pubblicizzano tutti i percorsi e devono essere modificati solo per pubblicizzare i percorsi alla coppia ha di hosting. Per ulteriori informazioni su SLM, vedere la sezione 5.9 di "TR-4080". Il precedente metodo di portset può essere utilizzato anche per ridurre ulteriormente i percorsi disponibili per un LUN. I portset aiutano a ridurre il numero di percorsi visibili attraverso i quali gli iniziatori in un igroup possono vedere le LUN.

I protocolli a blocchi (iSCSI, FC e FCoE) accedono alle LUN utilizzando ID LUN e numeri di serie, insieme a nomi univoci. FC e FCoE utilizzano nomi in tutto il mondo (WWNN e WWPN), mentre iSCSI utilizza nomi iSCSI qualificati (IQN). Il percorso delle LUN all'interno dello storage è privo di significato per i protocolli a blocchi e non viene presentato in alcun punto del protocollo. Pertanto, un volume che contiene solo LUN non deve essere montato internamente e non è necessario un percorso di giunzione per i volumi che contengono LUN utilizzati negli archivi dati. Il sottosistema NVMe in ONTAP funziona in modo simile.

Altre Best practice da prendere in considerazione:

VSphere consente ai clienti di utilizzare array NFS di livello Enterprise per fornire l'accesso simultaneo agli archivi dati a tutti i nodi di un cluster ESXi. Come indicato nella sezione datastore, l'utilizzo di NFS con vSphere offre alcuni vantaggi in termini di facilità d'uso e visibilità dell'efficienza dello storage.

Quando si utilizza ONTAP NFS con vSphere, si consiglia di seguire le seguenti Best practice:

Vale la pena notare che NFSv3 e NFSv4,1 utilizzano meccanismi di bloccaggio diversi. NFSv3 utilizza il blocco lato client, mentre NFSv4,1 utilizza il blocco lato server. Anche se un volume ONTAP può essere esportato tramite entrambi i protocolli, ESXi può montare un datastore solo attraverso un protocollo. Tuttavia, ciò non significa che altri host ESXi non possano montare lo stesso datastore attraverso una versione diversa. Per evitare qualsiasi problema, è essenziale specificare la versione del protocollo da utilizzare durante il montaggio, assicurandosi che tutti gli host utilizzino la stessa versione e, quindi, lo stesso stile di blocco. È fondamentale evitare di mischiare versioni NFS tra gli host. Se possibile, utilizzare i profili host per verificare la conformità.
Poiché non esiste alcuna conversione automatica del datastore tra NFSv3 e NFSv4,1, creare un nuovo datastore NFSv4,1 e utilizzare Storage vMotion per migrare le macchine virtuali nel nuovo datastore.
Fare riferimento alle note della tabella di interoperabilità NFS v4,1 nella "Tool NetApp Interoperability Matrix" Per i livelli di patch ESXi specifici richiesti per il supporto.
* Le policy di esportazione NFS vengono utilizzate per controllare l'accesso da parte degli host vSphere. È possibile utilizzare un criterio con più volumi (datastore). Con NFSv3, ESXi utilizza lo stile di sicurezza sys (UNIX) e richiede l'opzione di montaggio root per eseguire le macchine virtuali. In ONTAP, questa opzione viene definita superutente e, quando viene utilizzata l'opzione superutente, non è necessario specificare l'ID utente anonimo. Tenere presente che le regole dei criteri di esportazione con valori diversi per -anon e. -allow-suid Può causare problemi di rilevamento SVM con gli strumenti ONTAP. Ecco un esempio di politica:
Protocollo di accesso: nfs3
Specifiche di corrispondenza client: 192.168.42.21
RO regola di accesso: SYS
RW regola di accesso: SYS
UID anonimo
Superutente: SYS
* Se si utilizza il plug-in NFS NetApp per VMware VAAI, il protocollo deve essere impostato su nfs quando viene creata o modificata la regola dei criteri di esportazione. Il protocollo NFSv4 è necessario per l'offload delle copie VAAI e per specificare il protocollo come nfs Include automaticamente le versioni NFSv3 e NFSv4.
* I volumi del datastore NFS sono collegati dal volume root della SVM; pertanto, ESXi deve avere accesso al volume root per navigare e montare i volumi del datastore. La policy di esportazione per il volume root e per qualsiasi altro volume in cui la giunzione del volume del datastore è nidificata deve includere una regola o regole per i server ESXi che concedono loro l'accesso in sola lettura. Ecco un esempio di policy per il volume root, utilizzando anche il plug-in VAAI:
Protocollo di accesso: nfs (che include sia nfs3 che nfs4)
Specifiche di corrispondenza client: 192.168.42.21
RO regola di accesso: SYS
RW regola di accesso: Mai (massima sicurezza per il volume root)
UID anonimo
Superuser: SYS (richiesto anche per il volume root con VAAI)
* Utilizza i tool ONTAP per VMware vSphere (la Best practice più importante):
Utilizza i tool ONTAP per VMware vSphere per il provisioning dei datastore in quanto semplifica la gestione automatica delle policy di esportazione.
Quando si creano datastore per cluster VMware con il plug-in, selezionare il cluster piuttosto che un singolo server ESX. Questa opzione attiva il montaggio automatico del datastore su tutti gli host del cluster.
Utilizzare la funzione di montaggio dei plug-in per applicare i datastore esistenti ai nuovi server.
Quando non si utilizzano gli strumenti ONTAP per VMware vSphere, utilizzare un unico criterio di esportazione per tutti i server o per ogni cluster di server in cui è necessario un ulteriore controllo dell'accesso.
* Sebbene ONTAP offra una struttura flessibile dello spazio dei nomi dei volumi per disporre i volumi in una struttura ad albero utilizzando le giunzioni, questo approccio non ha alcun valore per vSphere. Crea una directory per ogni VM nella directory principale dell'archivio dati, indipendentemente dalla gerarchia dello spazio dei nomi dello storage. Pertanto, la Best practice consiste nel montare semplicemente il percorso di giunzione per i volumi per vSphere nel volume root della SVM, che è il modo in cui i tool ONTAP per VMware vSphere prevedono il provisioning dei datastore. La mancanza di percorsi di giunzione nidificati significa anche che nessun volume dipende da un volume diverso dal volume root e che la sua eliminazione o la sua eliminazione, anche intenzionalmente, non influisce sul percorso verso altri volumi.
* Per le partizioni NTFS sui datastore NFS è consigliabile Un blocco di 4K KB. La figura seguente mostra la connettività da un host vSphere a un datastore NFS ONTAP.

La seguente tabella elenca le versioni di NFS e le funzionalità supportate.

Gli amministratori dello storage a volte preferiscono semplificare le loro infrastrutture rimuovendo gli switch di rete dalla configurazione. Questo può essere supportato in alcuni scenari.