Prima di implementare il carico di lavoro o di eseguire la migrazione dall'hypervisor esistente, assicurarsi che il carico di lavoro sia dimensionato in modo da soddisfare le performance richieste. Ciò può essere ottenuto facilmente raccogliendo i dati sulle performance per ogni singola macchina virtuale che raccoglie statistiche per CPU (utilizzata/fornita), memoria (utilizzata/fornita), storage (fornita/utilizzata), throughput di rete e latenza, insieme all'aggregazione degli IOPS in lettura/scrittura, throughput e dimensioni dei blocchi. Questi parametri sono obbligatori per un'implementazione corretta e per il dimensionamento corretto dello storage array e degli host del carico di lavoro.

Nota: Pianificare IOPS e capacità nel dimensionamento dello storage per Hyper-V e dei carichi di lavoro associati.

Nota: Per macchine virtuali con i/o elevato o per quelle che richiedono molte risorse e capacità, separare il sistema operativo e i dischi dati. I file binari del sistema operativo e dell'applicazione cambiano raramente e la coerenza del crash del volume è accettabile.

Nota: Utilizzare lo storage Guest Connected (noto anche come in-guest) per dischi dati ad alte prestazioni rispetto all'utilizzo di VHD. Anche questo facilita il processo di clonazione.

Scegliere la giusta quantità di RAM e vCPU per prestazioni ottimali oltre a collegare più dischi a un unico controller SCSI virtuale. L'utilizzo di VHDx fisso è comunque consigliato come scelta principale per i dischi virtuali per le distribuzioni e non vi sono restrizioni per l'utilizzo di alcun tipo di dischi virtuali VHDX.

Nota: Evitare di installare ruoli non necessari su Windows Server che non verranno utilizzati.

Nota: Scegli Gen2 come generazione per le macchine virtuali in grado di caricare le VM dal controller SCSI e si basa sull'architettura VMBUS e VSP / VSC per il livello di avvio, il che aumenta significativamente le prestazioni complessive della VM.

Nota: Evitare di fare frequenti checkpoint perché ha un impatto negativo sulle prestazioni della VM.

Le condivisioni di file SMB 3,0 possono essere utilizzate come storage condiviso per Hyper-V. ONTAP supporta operazioni senza interruzioni sulle condivisioni SMB per Hyper-V. Hyper-V può utilizzare le condivisioni di file SMB per archiviare i file della macchina virtuale, come configurazioni, Snapshot e file dell'hard disk virtuale (VHD). Utilizza una SVM CIFS dedicata di ONTAP per condivisioni basate su SMB3,0 per Hyper-V. I volumi utilizzati per archiviare i file della macchina virtuale devono essere creati con volumi di tipo di protezione NTFS. La connettività tra gli host Hyper-V e l'array NetApp è consigliata su una rete 10GB, se disponibile. In caso di connettività di rete 1GB GbE, NetApp consiglia di creare un gruppo di interfacce composto da più porte 1GB GbE. Collegare ogni NIC che serve SMB multicanale alla propria subnet IP dedicata, in modo che ogni subnet offra un unico percorso tra client e server.

Punti chiave

Nota: ODX è supportato e funziona su più protocolli. Anche la copia dei dati tra una condivisione file e iSCSI o un LUN FCP-collegato utilizza ODX.

Nota: Le impostazioni dell'ora sui nodi nel cluster devono essere configurate di conseguenza. È necessario utilizzare il protocollo NTP (Network Time Protocol) se il server CIFS NetApp deve far parte del dominio Active Directory (ad) di Windows.

Nota: I valori MTU di grandi dimensioni devono essere attivati tramite il server CIFS. Le dimensioni ridotte dei pacchetti possono causare un peggioramento delle prestazioni.

Per una guida dettagliata alle Best practice, vedere "Linee guida per l'implementazione e Best practice per Hyper-V.".

Per ulteriori informazioni, fare riferimento a. "Requisiti di volume e server SMB per Hyper-V su SMB
".

Punti chiave

Nota: Utilizzare un LUN per volume, con mappatura 1:1:1 per il rapporto LUN/CSV.

Per eseguire il provisioning del volume ISCSI, verificare che siano soddisfatti i seguenti prerequisiti.

Nota: Per impostazione predefinita, ONTAP utilizza SLM (Selective LUN Map) per rendere la LUN accessibile solo attraverso percorsi sul nodo proprietario della LUN e del suo partner ad alta disponibilità (ha).

Fasi

Una volta creata la LUN, passare a failover Cluster Manager. Per aggiungere un disco a CSV, è necessario aggiungere il disco al gruppo archiviazione disponibile del cluster (se non è già stato aggiunto), quindi aggiungere il disco a CSV nel cluster.

Nota: La funzione CSV è attivata per impostazione predefinita in clustering di failover.

Aggiunta di un disco alla memoria disponibile:

Per ulteriori informazioni, fare riferimento a. "Utilizzo di volumi condivisi del cluster in un cluster di failover".

Creare macchine virtuali ad alta disponibilità:

Per creare una macchina virtuale altamente disponibile, attenersi alla seguente procedura:

La funzione ODX di ONTAP consente di creare copie dei VHD master semplicemente copiando un file VHDX master ospitato dal sistema storage ONTAP. Poiché una copia abilitata per ODX non trasferisce dati sulla rete, il processo di copia avviene sul lato storage di NetApp e pertanto può essere fino a sei-otto volte più veloce. Le considerazioni generali per un provisioning rapido includono le immagini sysprepped master archiviate nelle condivisioni file e i normali processi di copia avviati dalle macchine host Hyper-V.

Nota: ONTAP supporta ODX per entrambi i protocolli SMB e SAN.

Nota: Per sfruttare i casi di utilizzo del pass-through per l'offload delle copie ODX con Hyper-V, il sistema operativo guest deve supportare ODX e i dischi del sistema operativo guest devono essere dischi SCSI di cui è stato eseguito il backup tramite storage (SMB o SAN) che supporta ODX. I dischi IDE sul sistema operativo guest non supportano il pass-through ODX.

Sebbene il numero consigliato di VM per CSV sia soggettivo, numerosi fattori determinano il numero ottimale di VM che è possibile posizionare su ciascun volume CSV o SMB. Sebbene la maggior parte degli amministratori consideri solo la capacità, la quantità di i/o simultaneo inviata al VHDx è uno dei fattori principali per le performance complessive. Il modo più semplice per controllare le prestazioni è regolare il numero di macchine virtuali che vengono collocate in ogni CSV o condivisione. Se gli schemi i/o simultanei della macchina virtuale inviano troppo traffico al CSV o alla condivisione, le code del disco si riempiono e viene generata una latenza maggiore.

Assicurati che la soluzione sia dimensionata in modo adeguato end-to-end per evitare i colli di bottiglia e, quando viene creato un volume per lo storage di macchine virtuali Hyper-V, la Best practice consiste nella creazione di un volume non superiore al necessario. Il dimensionamento corretto dei volumi impedisce di inserire accidentalmente troppe macchine virtuali nel CSV e riduce la probabilità di contesa di risorse. Ciascun volume condiviso del cluster (CSV, Cluster Shared Volume) supporta una VM o più VM. Il numero di VM da collocare in un CSV è determinato dal carico di lavoro e dalle preferenze aziendali e dal modo in cui verranno utilizzate funzionalità di storage ONTAP quali snapshot e replica. Collocare più VM in un CSV è un buon punto di partenza nella maggior parte degli scenari di distribuzione. Regola questo approccio per casi di utilizzo specifici per soddisfare i requisiti di performance e protezione dei dati.

Poiché i volumi e le dimensioni di VHDx possono essere facilmente aumentati, se una macchina virtuale ha bisogno di capacità aggiuntiva, non è necessario ridimensionare i volumi CSV più grandi di quanto richiesto. Diskpart può essere utilizzato per estendere le dimensioni CSV o un approccio più semplice è creare un nuovo CSV e migrare le VM richieste al nuovo CSV. Per ottenere prestazioni ottimali, la Best practice consiste nell'aumentare il numero di CSV anziché aumentarne le dimensioni come misura provvisoria.

Uno dei casi di utilizzo più comuni nelle attuali condizioni di mercato è la migrazione. I clienti possono utilizzare il fabric VMM o altri strumenti di migrazione di terze parti per migrare le VM. Questi strumenti utilizzano la copia a livello di host per spostare i dati dalla piattaforma di origine alla piattaforma di destinazione, operazione che può richiedere tempo a seconda del numero di macchine virtuali che si trovano nell'ambito della migrazione.

L'utilizzo di ONTAP in tali scenari consente una migrazione più rapida rispetto all'utilizzo di processi di migrazione basati su host. ONTAP consente anche una rapida migrazione delle macchine virtuali da un hypervisor all'altro (ESXi in questo caso in Hyper-V). È possibile convertire un VMDK di qualsiasi dimensione in VHDx in pochi secondi sullo storage NetApp. Questo è il nostro metodo PowerShell: Sfrutta la tecnologia NetApp FlexClone® per la conversione rapida dei dischi rigidi delle VM. Gestisce inoltre la creazione e la configurazione di macchine virtuali di destinazione e di destinazione.

Questo processo consente di ridurre al minimo i tempi di inattività e di migliorare la produttività aziendale. Offre inoltre possibilità di scelta e flessibilità riducendo i costi di licenza, i vincoli e gli impegni nei confronti di un singolo fornitore. Ciò è utile anche per le organizzazioni che desiderano ottimizzare i costi di licenza delle VM ed estendere i budget IT.

Il seguente video demonstates the process to migration virtual machine from VMware ESX to Hyper-V. (il processo di migrazione delle macchine virtuali da VMware ESX a Hyper-V.)

Per ulteriori informazioni sulla migrazione con FlexClone e PowerShell, consultare la "Script PowerShell per la migrazione".