Prestazioni di I/O dell'archiviazione di Hyper-V
Questo articolo illustra diverse opzioni e considerazioni per l'ottimizzazione delle prestazioni di input/output (I/O) di archiviazione in una macchina virtuale (VM). Il percorso di I/O di archiviazione si estende in quattro fasi successive:
- Stack di archiviazione guest
- Livello di virtualizzazione host
- Stack di archiviazione host
- Disco fisico
Le sezioni seguenti descrivono le ottimizzazioni possibili per ogni fase.
Controller virtuali
Hyper-V offre tre tipi di controller virtuali:
Integrated Drive Electronics (IDE)
SCSI (Small Computer System Interface)
Adattatori bus host (HBA) Fibre Channel virtuali
IDE
È consigliabile usare solo dischi IDE per il sistema operativo. I dischi del sistema operativo presentano limitazioni delle prestazioni in base alle dimensioni massime di I/O per i dispositivi.
I controller IDE sono controller emulati che espongono dischi IDE alla macchina virtuale. Questo tipo di controller è l'unica opzione per le macchine virtuali guest che eseguono versioni precedenti di Windows senza servizi di integrazione delle macchine virtuali Hyper-V. Il driver di filtro dell'IDE fornito dai servizi di integrazione può offrire prestazioni di I/O del disco migliori rispetto al controller IDE emulato.
SCSI (controller SAS)
I controller SCSI virtuali espongono dischi SCSI alla macchina virtuale. Ogni controller supporta fino a 64 dispositivi. Il percorso SCSI non è emulato, cosa che lo rende il controller preferito per qualsiasi disco diverso dal disco del sistema operativo. Windows Server 2012 R2 e versioni successive supportano i controller SCSI, ma solo nei casi in cui il controller viene segnalato come Serial Attached SCSI (SAS) per il supporto di un disco rigido virtuale condiviso (VHDX).
Per ottenere prestazioni ottimali, si consiglia di collegare più dischi a un singolo controller SCSI virtuale. È consigliabile creare più controller solo se non sono disponibili altre opzioni per ridimensionare il numero di dischi connessi alla macchina virtuale.
HBA Fibre Channel virtuali
Configurare gli HBA Fibre Channel virtuali per consentire alle macchine virtuali di accedere direttamente ai numeri di unità logica (LUN) Fibre Channel e Fibre Channel over Ethernet (FCoE). I dischi Fibre Channel virtuali ignorano il file system NTFS nella partizione radice, riducendo l'utilizzo dell'unità di elaborazione centrale (CPU) di I/O di archiviazione. I dischi Fibre Channel virtuali sono ideali per unità dati di grandi dimensioni e unità condivise tra più macchine virtuali in scenari di clustering guest.
Per utilizzare i dischi Fibre Channel virtuali, è necessario installare uno o più HBA Fibre Channel nel computer host. Ogni HBA host deve usare driver HBA che supportano Windows Server 2016 Virtual Fibre Channel o funzionalità di virtualizzazione N_Port ID (NPIV). Anche l'infrastruttura SAN (Area Network) di Archiviazione deve supportare NPIV ed è necessario configurare le porte HBA per Fibre Channel in una topologia Fiber Channel che supporta NPIV.
Per ottimizzare la velocità effettiva negli host con più di un HBA, è consigliabile configurare molti HBA virtuali all'interno della macchina virtuale Hyper-V. È possibile configurare fino a quattro HBA per ogni macchina virtuale. Hyper-V bilancia automaticamente gli HBA virtuali per ospitare gli HBA che accedono alla stessa rete SAN virtuale.
Dischi virtuali
I dischi virtuali vengono esposti alle macchine virtuali attraverso i controller virtuali e possono essere dischi rigidi virtuali o dischi pass-through nell'host.
I dischi virtuali sono disponibili in formati VHD o VHDX. Ogni formato supporta tre tipi di file di disco rigido virtuale.
Se si aggiorna la distribuzione a Windows Server 2016 o versione successiva, è consigliabile convertire tutti i file VHD in formato VHDX. Per altre informazioni, vedere Formato VHDX.
Formato VHD
Le versioni successive di Hyper-V includono miglioramenti al formato VHD che consentono un migliore allineamento. Hyper-V in Windows Server 2012 e le versioni successive supportano sia i formati VHDX che VHD, anziché versioni precedenti che supportano solo il formato VHD. Di conseguenza, le versioni successive di Hyper-V offrono prestazioni migliori su dischi di settore di grandi dimensioni.
Tutti i dischi rigidi virtuali creati in Windows Server 2012 o versioni successive hanno l'allineamento ottimale di 4 KB. Questo formato allineato è completamente compatibile con le versioni precedenti di Windows Server. Tuttavia, la proprietà di allineamento non supporta le nuove allocazioni dai parser che non supportano l'allineamento di 4 KB, ad esempio un parser di una versione precedente di Windows Server o un parser non Microsoft.
Convertire il disco in formato VHD
Quando si esegue la migrazione di un disco rigido virtuale da una versione precedente di Hyper-V o Windows Server a una versione successiva, il sistema non converte automaticamente il disco in formato disco rigido.
È possibile convertire un disco virtuale esistente in disco rigido virtuale aprendo una finestra di PowerShell ed eseguendo il comando seguente:
Convert-VHD –Path <SourceDiskFilePath> –DestinationPath <ConvertedDiskFilePath>
Ad esempio, se si prevede di convertire un disco di origine denominato test.vhd nell'unità E in un disco convertito, rinominato e denominato test-converted.vhd nella stessa cartella, si esegue questo comando:
Convert-VHD –Path E:\vms\testvhd\test.vhd –DestinationPath E:\vms\testvhd\test-converted.vhd
Nota
Quando si converte un disco rigido virtuale, PowerShell usa i dati del disco rigido virtuale di origine in base all'opzione Copia dal disco di origine . Per altre informazioni, vedere Converti VHD.
Controllare l'allineamento del disco
Dopo aver convertito un disco, è possibile controllare la variabile Allineamento per assicurarsi che usi l'allineamento ottimale di 4 KB eseguendo il Get-VHD comando in PowerShell. Assicurarsi di eseguire il comando per il disco di origine e il disco convertito, quindi confrontare i valori per assicurarsi che il disco convertito sia compatibile con l'allineamento di 4 KB.
Per visualizzare l'allineamento dei dischi:
Aprire una finestra di PowerShell.
Eseguire il comando
Get-VHDper visualizzare l'impostazione di allineamento per il disco di origine.Get-VHD –Path <SourceVHDFilePath>Nell'output notare il valore per la proprietà
Alignment. In questo esempio il valore è0, il che significa che il disco non è compatibile con l'allineamento di 4 kB.Path : <SourceVHDFilePath> VhdFormat : VHD VhdType : Dynamic FileSize : 69245440 Size : 10737418240 MinimumSize : 10735321088 LogicalSectorSize : 512 PhysicalSectorSize : 512 BlockSize : 2097152 ParentPath : FragmentationPercentage : 10 Alignment : 0 Attached : False DiskNumber : IsDeleted : False Number :Eseguire di nuovo il
Get-VHDcomando, ma questa volta usare il percorso del file per il disco convertito.Get-VHD –Path <ConvertedDiskFilePath>Nell'output controllare il valore della proprietà
Alignment. Il valore deve essere1, il che significa che il disco viene convertito correttamente nel formato VHD più recente ed è compatibile con l'allineamento di 4 kB.Path : <ConvertedDiskFilePath> VhdFormat : VHD VhdType : Dynamic FileSize : 69369856 Size : 10737418240 MinimumSize : 10735321088 LogicalSectorSize : 512 PhysicalSectorSize : 512 BlockSize : 2097152 ParentPath : FragmentationPercentage : 0 Alignment : 1 Attached : False DiskNumber : IsDeleted : False Number :
Formato VHDX
VHDX è un formato di disco rigido aggiornato introdotto in Windows Server 2012. Questo formato consente di creare dischi virtuali resilienti e ad alte prestazioni con una capacità fino a 64 terabyte.
Se si esegue l'aggiornamento a Windows Server 2016 o versione successiva, è consigliabile convertire tutti i file VHD in formato VHDX. Mantenere i file in formato VHD solo se è necessario spostare la macchina virtuale in una versione precedente di Hyper-V che non supporta il formato VHDX.
Ecco alcuni vantaggi del formato VHDX:
Supporto per la capacità di archiviazione dei dischi rigidi virtuali fino a 64 TB
Protezione contro il danneggiamento dei dati in caso di interruzioni dell'alimentazione grazie alla registrazione degli aggiornamenti nelle strutture dei metadati VHDX
Archivia i metadati personalizzati per un file in base a ciò che l'utente configura, ad esempio la versione del sistema operativo o le patch applicate
Il formato VHDX offre anche diverse funzionalità di prestazioni:
È stato migliorato l'allineamento del formato del disco rigido virtuale, migliorando le prestazioni sui dischi a settori grandi.
Dimensioni dei blocchi più grandi per i dischi dinamici e differenziali, che consentono ai dischi di adattarsi ai requisiti del carico di lavoro
Un disco virtuale con settore logico di 4 KB contribuisce al miglioramento delle prestazioni quando viene usato da applicazioni e carichi di lavoro progettati per settori di 4 KB.
Efficienza nella rappresentazione dei dati per ottenere file di dimensioni inferiori e consentire al dispositivo di archiviazione fisica sottostante di recuperare lo spazio inutilizzato
Nota
Il trimming richiede dischi pass-through o SCSI e hardware compatibile con trim.
File virtuali
Sono disponibili tre tipi di file VHD:
I file corretti sono destinati a migliorare la resilienza e le prestazioni ed è consigliabile usarli quando l'archiviazione sul valore di hosting non viene monitorata attivamente. Assicurarsi che lo spazio su disco sia sufficiente quando si espande il file VHD in fase di esecuzione. È possibile usarli in qualsiasi formato di disco.
I file dinamici sono per garantire la resilienza e allocare spazio su disco in base alle esigenze della distribuzione. È possibile usarli solo in VHDX.
I file differenziali mantengono brevi le catene di snapshot delle macchine virtuali per mantenere buone prestazioni di I/O del disco. È possibile usarli in qualsiasi formato di disco.
Tipo di file fisso
Quando si crea un file VHD fisso, il sistema alloca spazio. È meno probabile che i file fissi si frammentino, riducendo la velocità effettiva di I/O quando un singolo I/O viene suddiviso in più file. Ha anche il sovraccarico della CPU più basso delle tre opzioni di file poiché le operazioni di lettura e scrittura non richiedono di cercare la mappatura del blocco.
È consigliabile usare il tipo di file fisso quando è necessaria una resilienza e prestazioni ottimali.
Tipo di file dinamico
Quando si crea un file VHD dinamico, il sistema alloca spazio su richiesta. I blocchi nel file iniziano come blocchi allocati e nessun spazio nel file esegue il backup dei blocchi non allocati. Quando un blocco riceve la prima scrittura, lo stack di virtualizzazione deve allocare spazio per il blocco nel file VHD, quindi aggiornare i metadati. Questa allocazione aumenta il numero di operazioni di I/O su disco necessarie per la scrittura, aumentando l'utilizzo della CPU. Le operazioni di lettura e scrittura nei blocchi esistenti comportano l'accesso al disco e il sovraccarico della CPU durante la ricerca della mappatura dei blocchi nei metadati.
Se si usa un file VHDX, è consigliabile usare il tipo di file dinamico quando non si monitora attivamente l'archiviazione nel volume di hosting. Assicurarsi che lo spazio su disco sia sufficiente quando si espande il file VHD in fase di esecuzione.
Tipo di file differenze
I file differenziali sono snapshot di una macchina virtuale che archivia le scritture nei dischi. Se si scrive in un blocco senza scritture esistenti, il sistema alloca spazio nel file VHD esattamente come un disco rigido virtuale a espansione dinamica. Il sistema esegue operazioni di lettura dal file VHD se il blocco contiene già delle scritture. In caso contrario, gestisce i blocchi dal file VHD padre. In entrambi i casi, il sistema legge i metadati per determinare la mappatura dei blocchi. Le letture e le scritture in questo disco rigido virtuale possono utilizzare più CPU e generare più operazioni di I/O rispetto a un file VHD fisso.
Quando sono presenti solo pochi snapshot, gli I/O di archiviazione possono potenzialmente utilizzare più CPU del normale, ma ciò non influisce in modo significativo sulle prestazioni, tranne che nei carichi di lavoro dei server ad alta intensità di I/O. La creazione e l'uso di una grande catena di snapshot di macchine virtuali causa problemi di prestazioni. Nei file differenziali, il sistema deve verificare la presenza dei blocchi richiesti in molti dischi rigidi virtuali diversi per la sola lettura dal disco rigido virtuale. Se si usano file diversi, è consigliabile mantenere le catene di snapshot brevi per mantenere buone prestazioni di I/O del disco.
Considerazioni sulle dimensioni
Quando si pianifica l'ottimizzazione del disco, è consigliabile considerare sia le dimensioni del blocco che le dimensioni del settore. In questa sezione vengono descritte le raccomandazioni per i blocchi di ridimensionamento e i settori.
Dimensioni blocco
Poiché le dimensioni dei blocchi possono influire in modo significativo sulle prestazioni, è consigliabile associare le dimensioni dei blocchi ai modelli di allocazione dei carichi di lavoro usando il disco. Se un'applicazione alloca blocchi in chunk di 16 MB, è consigliabile usare idealmente una dimensione del blocco VHD di 16 MB. Le dimensioni dei blocchi maggiori di 2 MB sono possibili solo nei dischi rigidi virtuali usando il formato di file VHDX. Quando le dimensioni del blocco sono maggiori del modello di allocazione per un carico di lavoro di I/O casuale, aumenta la quantità di spazio usata dal disco rigido virtuale nell'host.
Dimensioni del settore
Le organizzazioni software dipendono spesso da settori del disco di 512 byte, ma lo standard del settore si sta spostando verso settori del disco di 4 KB. Per ridurre i problemi di compatibilità che possono derivare dalle variazioni delle dimensioni dei settori, i produttori di dischi rigidi stanno introducendo una dimensione transitoria denominata 512 emulation drive (512e).
Le unità di emulazione offrono alcuni dei vantaggi offerti dalle unità native del settore dei dischi da 4 KB, ad esempio una migliore efficienza del formato e uno schema migliorato per i codici di correzione degli errori (ECC). Le unità di emulazione presentano meno problemi di compatibilità quando si espongono una dimensione del settore di 4 KB all'interfaccia del disco.
Per utilizzare appieno i settori da 4 KB, è consigliabile utilizzare il formato VHDX anziché i settori del disco di 512 byte. Per ridurre i problemi di compatibilità tra le dimensioni dei dischi, implementare unità da 512e per il dimensionamento transitorio.
Supportare le dimensioni transitorie con dischi da 512e
Un disco 512e può eseguire un'operazione di scrittura solo in termini di un settore fisico. Questo tipo di disco non è in grado di scrivere direttamente un settore da 512 byte in cui il sistema lo emette. Il disco dispone di un processo interno che rende possibili le operazioni di scrittura, che comporta operazioni read-modify-write (RMW) nell'ordine seguente:
Innanzitutto, il disco legge il settore fisico da 4 KB nella cache interna. La cache contiene il settore logico da 512 byte a cui si fa riferimento nell'operazione di scrittura.
Successivamente, il disco modifica i dati nel buffer da 4 kB in modo da includere il settore da 512 byte aggiornato.
Il disco esegue un'operazione di scrittura del buffer a 4 KB aggiornato nel proprio settore fisico sul disco.
L'effetto complessivo del processo RMW sulle prestazioni dipende dal carico di lavoro. Il processo RMW può causare una riduzione del livello delle prestazioni dei dischi rigidi virtuali per i motivi seguenti:
I dischi rigidi virtuali dinamici e differenze presentano una bitmap settore a 512 byte prima del payload dati. Piè di pagina, intestazione e localizzatori padre sono allineati a un settore a 512 byte. È comune che il driver del disco rigido virtuale esegua operazioni di scrittura a 512 byte per aggiornare queste strutture, che causano l'esecuzione del processo RMW sul disco.
Le applicazioni eseguono in genere operazioni di lettura e scrittura in multipli di dimensioni di 4 KB, poiché 4 KB è la dimensione predefinita del cluster di NTFS. I dischi rigidi virtuali dinamici e differenze hanno una bitmap del settore a 512 byte davanti al blocco di payload dei dati. Questa bitmap fa sì che i blocchi da 4 KB non vengano allineati al limite fisico di 4 KB. Il diagramma seguente mostra un blocco VHD da 4 KB messo in evidenza, che non è allineato con il limite fisico da 4 KB.
Ogni operazione di scrittura di 4 KB da parte del parser corrente per aggiornare i dati del payload comporta due letture per due blocchi sul disco. Il sistema aggiorna quindi i blocchi e li riscrive nei due blocchi del disco. Hyper-V in Windows Server 2016 riduce alcuni effetti sulle prestazioni dei dischi 512e nello stack del disco rigido virtuale. Hyper-V prepara le strutture per l'allineamento ai limiti di 4 KB nel formato del disco rigido virtuale. La mitigazione evita l'effetto RMW sull'accesso ai dati all'interno del file del disco rigido virtuale e gli aggiornamenti alle strutture dei metadati del disco rigido virtuale.
Come accennato in precedenza, i dischi rigidi virtuali copiati dalle versioni precedenti di Windows Server non vengono allineati automaticamente a 4 kB. È possibile convertire manualmente il disco in modo che si allinei in modo ottimale utilizzando l'opzione Copia dall'opzione disco di origine con il Convert-VHD comando.
Per impostazione predefinita, i dischi rigidi virtuali vengono esposti con dimensioni del settore fisico di 512 byte. Questo metodo garantisce che le applicazioni dipendenti dalle dimensioni del settore fisico non siano interessate quando si esegue la migrazione dell'applicazione e dei dischi rigidi virtuali da una versione precedente di Windows Server.
Per impostazione predefinita, il sistema crea dischi VHDX con una dimensione del settore fisico di 4 KB per ottimizzare il profilo delle prestazioni nei dischi normali e nei dischi con settori più grandi.
Per ridurre i problemi di compatibilità tra le dimensioni del disco, è consigliabile implementare le unità 512e per il dimensionamento transizionale. Per sfruttare appieno i settori da 4 KB, usare il formato VHDX.
Dischi nativi da 4 KB
Hyper-V in Windows Server 2012 R2 e versioni successive supporta dischi nativi da 4 KB. È anche possibile archiviare i dati del disco VHD in un disco nativo da 4 KB implementando un algoritmo RMW software nel livello dello stack di archiviazione virtuale. L'algoritmo converte le richieste di accesso e aggiornamento a 512 byte ad accessi e aggiornamenti corrispondenti a 4 KB.
Poiché i file VHD possono esporre solo dischi con dimensione del settore logico di 512 byte, è probabile che vi siano applicazioni che emettono richieste di I/O a 512 byte. In questi casi, l'algoritmo RMW nel livello dello stack di archiviazione soddisfa le richieste e causa una riduzione delle prestazioni. Lo stesso risultato si verifica per i dischi VHDX con dimensioni del settore logico di 512 byte.
È possibile configurare i file VHDX per l'esposizione come disco di dimensioni del settore logico di 4 KB. Questa implementazione è una configurazione ottimale per le prestazioni dei dischi ospitati in un dispositivo fisico nativo di 4 KB. Tuttavia, assicurarsi che le dimensioni del settore logico di 4 KB supportino sia il guest che l'applicazione che usano il disco virtuale. Il formato VHDX funziona correttamente in un dispositivo con dimensioni del settore logico di 4 KB.
È consigliabile evitare di usare dischi nativi da 4 KB con file VHD e VHDX, in quanto può causare una riduzione delle prestazioni. Quando lo scenario richiede dischi nativi da 4 KB, è consigliabile usare il formato VHDX in un dispositivo con dimensioni del settore logico di 4 KB.
Dischi pass-through
È consigliabile evitare di usare dischi pass-through a causa delle limitazioni che introducono negli scenari di migrazione delle macchine virtuali.
Il mapping di un disco rigido virtuale in una macchina virtuale direttamente su un disco fisico o su un numero di unità logica (LUN) anziché a un file VHD viene denominato disco pass-through I dischi pass-through consentono di ignorare il file system NTFS nella partizione radice, riducendo così l'utilizzo della CPU delle operazioni di I/O di archiviazione. Tuttavia, l'uso di dischi pass-through comporta anche un rischio di dischi fisici o LUN che diventano più difficili da migrare tra computer rispetto ai file VHD.
Funzionalità di archiviazione avanzate
Questa sezione illustra altre ottimizzazioni delle prestazioni da prendere in considerazione per le funzionalità di archiviazione avanzate.
Qualità del servizio (QoS) di archiviazione
In Windows Server 2012 R2 e versioni successive Hyper-V include la possibilità di impostare determinati parametri di qualità del servizio (QoS) per l'archiviazione nelle macchine virtuali. È consigliabile implementare QoS di archiviazione per accedere a parametri di archiviazione aggiuntivi, impostare soglie di IOPS massime e minime per i dischi rigidi virtuali e monitorare le prestazioni del disco. È possibile implementare questi parametri per ottenere i seguenti vantaggi:
Configurare l'isolamento delle prestazioni di archiviazione in un ambiente multi-tenant
Specificare le operazioni di input/output massime e minime al secondo (IOPS) per i dischi rigidi virtuali
- Gli amministratori possono limitare l'I/O di archiviazione per impedire a un tenant di usare risorse di archiviazione eccessive che possono influire su altri tenant. Impostare il valore minimo di operazioni di I/O al secondo e ricevere notifiche quando il sistema non raggiunge la soglia per prestazioni ottimali. Si specificano i valori di IOPS massimo o minimo in termini di IOPS normalizzati in cui ogni 8 KB di dati vengono utilizzati come I/O.
Ricevere notifiche quando le prestazioni di I/O di archiviazione scendono al di sotto delle soglie definite per eseguire in modo efficiente i carichi di lavoro delle macchine virtuali
Accedere ai parametri di archiviazione per l'infrastruttura delle metriche delle macchine virtuali e consentire agli amministratori di monitorare i parametri correlati alle prestazioni e al chargeback
Tenere tuttavia presente anche che Archiviazione QoS presenta le limitazioni seguenti:
Disponibile solo per i dischi virtuali
Il disco differenze non può avere un disco virtuale padre in un volume diverso
La QoS per un sito di replica viene configurata separatamente dal sito primario
Archiviazione QoS non supporta VHDX condiviso
Per ulteriori informazioni, vedere l'argomento relativo a Qualità del servizio di archiviazione per Hyper-V.
Impostazioni del Registro di sistema di I/O NUMA per macchine virtuali di grandi dimensioni
Windows Server 2012 e versioni successive supporta la proiezione di una topologia virtuale ad accesso non uniforme alla memoria (NUMA) in macchine virtuali Hyper-V. Il supporto NUMA migliora le prestazioni dei carichi di lavoro in esecuzione nelle macchine virtuali configurate con grandi quantità di memoria o nelle macchine virtuali di grandi dimensioni. Per abilitare questo supporto, le configurazioni di macchine virtuali di grandi dimensioni richiedono scalabilità in termini di velocità effettiva di I/O. Un esempio di macchina virtuale di grandi dimensioni è Microsoft SQL Server in esecuzione con 64 processori virtuali.
I miglioramenti seguenti di Windows Server soddisfano i requisiti di scalabilità di I/O delle macchine virtuali di grandi dimensioni:
Creazione di più canali di comunicazione tra i dispositivi guest e lo stack di archiviazione host.
Un meccanismo di completamento di I/O più efficiente che implica la distribuzione degli interrupt tra i processori virtuali per evitare costose interruzioni dell'interprocessore.
Chiavi del Registro di sistema
È consigliabile usare le impostazioni della chiave del Registro di sistema NUMA di Windows Server per migliorare le prestazioni dei carichi di lavoro in esecuzione nelle macchine virtuali di grandi dimensioni.
Sono state aggiunte e aggiornate alcune voci del Registro di sistema per supportare i miglioramenti nella sezione precedente e consentire di modificare il numero di canali. È possibile trovare le voci in HKLM\System\CurrentControlSet\Enum\VMBUS\<device id>\<instance id>\StorChannel.
La <device id>\<instance id>\ parte del percorso corrisponde ai valori rilevanti nella configurazione. Queste voci del Registro di sistema allineano i processori virtuali che gestiscono i completamenti di I/O alle CPU virtuali che l'applicazione ha assegnato come processori di I/O. Il sistema configura le impostazioni del Registro di sistema in base alla scheda sulla chiave hardware del dispositivo.
Ecco due impostazioni chiave da considerare:
ChannelCount (DWORD) è il numero totale di canali di comunicazione che la distribuzione può usare. Il valore massimo è 16. Per impostazione predefinita, il numero di canali è un valore uguale al numero di processori virtuali diviso per 16.
ChannelMask (QWORD) è l'affinità del processore per i canali. Se non si specifica questa impostazione chiave o si imposta il valore su 0, la maschera del canale utilizza per impostazione predefinita l'algoritmo di distribuzione dei canali esistente per i normali canali di archiviazione o di rete. L'azione predefinita garantisce che i canali di archiviazione non siano in conflitto con i canali di rete.
Integrazione del trasferimento dei dati offloaded
È consigliabile usare operazioni ODX (Offloaded Data Transfer) per assicurarsi che il carico di lavoro della macchina virtuale possa usare l'archiviazione abilitata per ODX nel modo in cui può essere usato in un ambiente fisico.
Le attività di manutenzione cruciali per i dischi rigidi virtuali, ad esempio l'unione, lo spostamento e la compattazione, comportano la copia di grandi quantità di dati. Il metodo corrente di copia dei dati richiede che il sistema legga e scriva i dati in posizioni diverse, che richiede molto tempo e usa risorse di CPU e memoria che potrebbero essere andate verso la manutenzione delle macchine virtuali.
I fornitori di reti SAN (Storage Area Network) possono fornire una funzionalità hardware denominata ODX. Questa funzionalità fornisce operazioni di copia quasi istantanee per grandi quantità di dati. ODX consente al sistema, non ai dischi, di specificare come spostare set di dati specifici da una posizione a un'altra.
Hyper-V in Windows Server 2012 e versioni successive supporta le operazioni ODX per passare i dati copiati dal sistema operativo guest all'hardware host. Il carico di lavoro può usare l'archiviazione abilitata per ODX esattamente come in un ambiente non virtualizzato. Lo stack di archiviazione Hyper-V può anche eseguire operazioni ODX durante le operazioni di manutenzione per i dischi rigidi virtuali, ad esempio l'unione di dischi e l'archiviazione delle meta-operazioni di migrazione durante migrazioni di dati enormi.
Integrazione delle notifiche di unmap
È consigliabile usare le notifiche di annullamento del mapping per rendere più efficienti i file VHDX e consentire al dispositivo di archiviazione fisico sottostante di recuperare lo spazio inutilizzato.
I file VHD si trovano in un volume di archiviazione in cui condividono lo spazio disponibile con altri file. Poiché le dimensioni del file tendono a essere grandi, i file VHD possono occupare molto spazio. Una maggiore richiesta di spazio di archiviazione influisce sui budget hardware IT, il che significa che è consigliabile ottimizzare l'utilizzo dello spazio fisico laddove possibile.
Nelle versioni di Windows Server precedenti a Windows Server 2012, lo stack di archiviazione di Windows nel sistema operativo guest e l'host Hyper-V presentavano limitazioni che impedivano loro di ottimizzare lo spazio di archiviazione. Quando le applicazioni hanno eliminato il contenuto in un disco rigido virtuale, lo spazio di archiviazione è rimasto abbandonato. Il sistema non invia notifiche al disco rigido virtuale o al dispositivo di archiviazione fisico sulle informazioni eliminate, impedendo allo stack di archiviazione Hyper-V di ottimizzare lo spazio per i file del disco virtuale basato su disco rigido virtuale. Di conseguenza, il dispositivo di archiviazione sottostante non è riuscito a recuperare lo spazio ora inutilizzato usato per occupare i dati eliminati.
A partire da Windows Server 2012, Hyper-V supporta le notifiche di annullamento del mapping. Questa funzionalità consente ai file VHDX di segnalare i dati eliminati allo stack di archiviazione, che ottimizza l'efficienza mantenendo le dimensioni dei file e consentendo allo stack di recuperare lo spazio di archiviazione inutilizzato per altri usi.
Solo i controller SCSI specifici di Hyper-V, IDE con riconoscimento dei dati aziendali e Fibre Channel virtuali consentono al comando unmap del sistema operativo guest di raggiungere lo stack di archiviazione virtuale host. Nei dischi rigidi virtuali, solo i dischi virtuali formattati come VHDX supportano unmap i comandi del sistema operativo guest.