Ambiente operativo corrente. Sebbene i team IT siano generalmente esperti nella gestione dell'infrastruttura IP Ethernet, non tutti sono esperti nella gestione di un fabric FC SAN. Tuttavia, l'utilizzo di una rete IP generica non progettata per il traffico di storage potrebbe non funzionare bene. Prendi in considerazione l'infrastruttura di rete in uso, gli eventuali miglioramenti pianificati e le competenze e la disponibilità del personale per gestirli.

Facilità di configurazione. oltre alla configurazione iniziale del fabric FC (switch e cablaggio aggiuntivi, zoning e verifica dell'interoperabilità di HBA e firmware), i protocolli a blocchi richiedono anche la creazione e la mappatura di LUN e il rilevamento e la formattazione da parte del sistema operativo guest. Una volta creati ed esportati, i volumi NFS vengono montati dall'host ESXi e pronti all'uso. NFS non dispone di specifiche qualifiche hardware o firmware da gestire.

Facilità di gestione. Con i protocolli SAN, se è necessario più spazio, sono necessari diversi passaggi, tra cui l'espansione di una LUN, una nuova scansione per rilevare le nuove dimensioni e quindi l'espansione del file system. Sebbene sia possibile espandere una LUN, ridurne le dimensioni non lo è. NFS consente un facile aumento o riduzione delle dimensioni, e questo ridimensionamento può essere automatizzato dal sistema storage. SAN offre space reclamation tramite i comandi DEALLOCATE/TRIM/UNMAP del sistema operativo guest, consentendo di restituire all'array lo spazio dei file eliminati. Questo tipo di space reclamation non è possibile con i datastore NFS.

Trasparenza dello spazio di storage. l'utilizzo dello storage è in genere più semplice da visualizzare negli ambienti NFS perché il thin provisioning restituisce immediatamente risparmi. Allo stesso modo, i risparmi di deduplica e clonazione sono immediatamente disponibili per altre macchine virtuali nello stesso datastore o per altri volumi di sistemi storage. La densità delle macchine virtuali è in genere maggiore anche in un datastore NFS, che può migliorare i risparmi della deduplica e ridurre i costi di gestione grazie a un numero inferiore di datastore da gestire.

L'implementazione di vSphere con datastore NFS ONTAP si traduce in una soluzione ad alte prestazioni e facile da gestire, che offre rapporti VM-datastore non ottenibili con protocolli di storage a blocchi. Questa architettura può comportare un aumento di dieci volte della densità dei datastore, con una corrispondente riduzione del numero di datastore. Sebbene un datastore più grande possa migliorare l'efficienza dello storage e offrire vantaggi operativi, considera di utilizzare almeno quattro datastore (FlexVol volumi) per nodo per archiviare le VM su un singolo controller ONTAP, al fine di ottenere le massime prestazioni dalle risorse hardware. Questo approccio consente inoltre di stabilire datastore con diverse policy di ripristino. Alcuni possono essere sottoposti a backup o replicati più frequentemente di altri in base alle esigenze aziendali. Non sono necessari più datastore con volumi FlexGroup per le prestazioni, poiché sono scalabili per progettazione.

NetApp consiglia l'uso di volumi FlexVol per la maggior parte dei datastore NFS. A partire da ONTAP 9.8, i volumi FlexGroup sono supportati anche per l'utilizzo come datastore e sono generalmente consigliati per determinati casi d'uso. Altri contenitori di storage ONTAP, come i qtree, non sono generalmente consigliati perché attualmente non sono supportati né dagli ONTAP tools for VMware vSphere né dal plugin NetApp SnapCenter per VMware vSphere.

Una buona dimensione per un datastore di volumi FlexVol è di circa 4TB - 8TB. Queste dimensioni rappresentano un buon punto di equilibrio per le performance, la facilità di gestione e la protezione dei dati. Inizia in piccolo (ad esempio, 4 TB) e fai crescere il datastore in base alle necessità (fino a un massimo di 300 TB). I datastore più piccoli sono più veloci da ripristinare dal backup o dopo un disastro e possono essere spostati rapidamente nel cluster. Prendere in considerazione l'utilizzo della funzione di dimensionamento automatico di ONTAP per aumentare e ridurre automaticamente il volume in base alle modifiche dello spazio utilizzato. I tool ONTAP per la procedura guidata di provisioning del datastore di VMware vSphere utilizzano il dimensionamento automatico per impostazione predefinita per i nuovi datastore. È possibile personalizzare ulteriormente le soglie di aumento e riduzione e le dimensioni massime e minime con System Manager o la riga di comando.

In alternativa, i datastore VMFS possono essere configurati con LUN o namespace NVMe (chiamati anche unità storage nei nuovi sistemi ASA) accessibili tramite FC, iSCSI, NVMe/FC o NVMe/TCP. VMFS consente l'accesso simultaneo ai datastore da parte di ogni server ESX in un cluster. Gli archivi di dati VMFS possono avere dimensioni fino a 64 TB e sono costituiti da un massimo di 32 LUN da 2 TB (VMFS 3) o un singolo LUN da 64 TB (VMFS 5). Le dimensioni massime del LUN del ONTAP sono di 128TB GB su sistemi AFF, ASA e FAS. NetApp consiglia sempre di utilizzare una singola LUN di grandi dimensioni per ciascun datastore, invece di provare a utilizzare estensioni. Come per NFS, prendere in considerazione l'utilizzo di datastore multipli (volumi o unità storage) per massimizzare le performance su un singolo controller del ONTAP.

I sistemi operativi guest precedenti necessitavano di un allineamento con il sistema storage per ottenere le migliori performance ed efficienza dello storage. Tuttavia, i moderni sistemi operativi supportati dai vendor dei distributori Microsoft e Linux come Red Hat non richiedono più modifiche per allineare la partizione del file system con i blocchi del sistema storage sottostante in un ambiente virtuale. Se stai utilizzando un vecchio sistema operativo che potrebbe richiedere un allineamento, cerca nella Knowledge base di supporto NetApp gli articoli che utilizzano "allineamento VM" o richiedi una copia del documento TR-3747 a un contatto commerciale o di un partner NetApp.

Evitare l'uso di utilità di deframmentazione all'interno del sistema operativo guest, poiché ciò non offre vantaggi in termini di prestazioni e influisce sull'efficienza dello storage e sull'utilizzo dello spazio snapshot. È inoltre consigliabile disattivare l'indicizzazione della ricerca nel sistema operativo guest per i desktop virtuali.

ONTAP ha guidato il settore con innovative funzionalità di efficienza dello storage, che ti consentono di sfruttare al massimo lo spazio su disco utilizzabile. I sistemi AFF aumentano ulteriormente questa efficienza con la deduplica e la compressione inline predefinite. I dati vengono deduplicati in tutti i volumi in un aggregato, quindi non è più necessario raggruppare sistemi operativi simili e applicazioni simili in un singolo datastore per massimizzare i risparmi.

In alcuni casi, potrebbe non essere necessario un datastore. Considerare i file system guest-owned come NFS, SMB, NVMe/TCP o iSCSI gestiti dal guest. Per indicazioni specifiche sulle applicazioni, consulta i report tecnici NetApp relativi alla tua applicazione. Ad esempio, "Database Oracle su ONTAP" ha una sezione sulla virtualizzazione con informazioni utili.

I dischi di prima classe (o dischi virtuali migliorati) consentono dischi gestiti da vCenter indipendenti da una macchina virtuale con vSphere 6.5 e versioni successive. Anche se gestiti principalmente da API, possono essere utili con vVol, soprattutto se gestiti da OpenStack o Kubernetes tools. Sono supportati da ONTAP e dai tool ONTAP per VMware vSphere.

Utilizzare Storage vMotion per spostare la maggior parte delle macchine virtuali su ONTAP. Questo approccio non solo non è disgregativo per l'esecuzione di macchine virtuali, ma consente anche funzionalità di efficienza dello storage ONTAP come la deduplica inline e la compressione per elaborare i dati durante la migrazione. Prendere in considerazione l'utilizzo delle funzionalità di vCenter per selezionare più macchine virtuali dall'elenco di inventario e quindi pianificare la migrazione (utilizzare il tasto Ctrl mentre si fa clic su azioni) in un momento appropriato.

Sebbene sia possibile pianificare attentamente una migrazione verso i datastore di destinazione appropriati, spesso è più semplice migrare in blocco e poi organizzare successivamente secondo necessità. Potresti voler utilizzare questo approccio per guidare la migrazione verso diversi datastore se hai esigenze specifiche di protezione dei dati, come diverse pianificazioni di Snapshot. Inoltre, una volta che le VM sono sul NetApp cluster, lo storage vMotion può utilizzare gli offload VAAI per spostare le VM tra i datastore del cluster senza richiedere una copia basata sull'host. Si noti che NFS non esegue l'offload dello storage vMotion delle VM accese; tuttavia, VMFS lo fa.

Le macchine virtuali che richiedono una migrazione più accurata includono database e applicazioni che utilizzano lo storage collegato. In generale, considerare l'utilizzo degli strumenti dell'applicazione per gestire la migrazione. Per Oracle, prendere in considerazione l'utilizzo di strumenti Oracle come RMAN o ASM per migrare i file di database. Per ulteriori informazioni, vedere "Migrazione dei database Oracle sui sistemi di storage ONTAP" . Allo stesso modo, per SQL Server, prendere in considerazione l'utilizzo di SQL Server Management Studio o di strumenti NetApp come SnapManager per SQL Server o SnapCenter.

Separare il traffico di rete dello storage dalle altre reti. È possibile ottenere una rete separata utilizzando una VLAN dedicata o switch separati per lo storage. Se la rete di storage condivide percorsi fisici come gli uplink, potrebbe essere necessario QoS o porte di uplink aggiuntive per garantire una larghezza di banda sufficiente. Non connettere gli host direttamente allo storage; utilizzare gli switch per disporre di percorsi ridondanti e consentire a VMware ha di funzionare senza alcun intervento. Vedere "Connessione di rete diretta" per ulteriori informazioni.

I frame jumbo possono essere utilizzati se lo si desidera e supportati dalla rete, in particolare quando si utilizza iSCSI. Se vengono utilizzati, assicurarsi che siano configurati in modo identico su tutti i dispositivi di rete, VLAN e così via nel percorso tra lo storage e l'host ESXi. In caso contrario, potrebbero verificarsi problemi di connessione o di prestazioni. La MTU deve essere impostata in modo identico anche sullo switch virtuale ESXi, sulla porta VMkernel e anche sulle porte fisiche o sui gruppi di interfacce di ciascun nodo ONTAP.

NetApp consiglia di disattivare solo il controllo di flusso di rete sulle porte di cluster Interconnect in un cluster ONTAP. NetApp non fornisce altri consigli sulle Best practice per le restanti porte di rete utilizzate per il traffico dati. Attivare o disattivare secondo necessità. Vedere "TR-4182" per ulteriori informazioni sul controllo di flusso.

Quando gli array di storage ESXi e ONTAP sono connessi a reti di storage Ethernet, NetApp consiglia di configurare le porte Ethernet a cui questi sistemi si connettono come porte edge Rapid Spanning Tree Protocol (RSTP) o utilizzando la funzione Cisco PortFast. NetApp consiglia di abilitare la funzione di trunk PortFast Spanning-Tree in ambienti che utilizzano la funzione PortFast Cisco e che dispongono di trunking VLAN 802,1Q abilitato al server ESXi o agli array di storage ONTAP.

NetApp consiglia le seguenti procedure consigliate per l'aggregazione dei collegamenti: