Best practice per la memorizzazione di Hyper-V

La memorizzazione è uno dei componenti più importanti coinvolti nei server; questo include server virtualizzati che hanno un hypervisor installato e macchine virtuali in esecuzione. La memorizzazione può causare prestazioni elevate o basse, nonché garantire un’elevata o bassa affidabilità nel mantenimento dei dati VM e dei dischi virtuali. Tipi diversi di storage possono essere utilizzati nell’ambiente virtuale Hyper-V e l’amministratore dovrebbe fare la scelta giusta prima di configurare un server o distribuire macchine virtuali.

Questo post sul blog ha lo scopo di aiutarti a esplorare i diversi tipi di opzioni di storage al fine di effettuare una selezione di storage che sia più adatta al tuo ambiente e quindi una che soddisfi efficacemente i tuoi requisiti.

Raccomandazioni sui dati di archiviazione Hyper-V

Lo storage che può essere montato sul server Hyper-V può essere di due tipi: storage locale o remoto.

Storage locale consiste in diversi dischi collegati localmente al server. Tali dischi sono generalmente collegati tramite interfaccia SAS (Serial Attached SCSI) a un controller RAID (Redundant Array of Independent Disks) all’interno del chassis del server. L’uso di dischi SAS è preferito rispetto a dischi SATA (nonostante la compatibilità – i dischi SATA possono essere collegati a porte SAS ma non viceversa) a causa del livello di affidabilità più elevato dei dischi SAS. Lo storage locale può essere più conveniente rispetto allo storage remoto. Se non prevedi di distribuire un cluster Hyper-V, puoi utilizzare lo storage locale.

Il memorizzazione remota è situata separatamente dal server Hyper-V ed è collegata al server tramite i protocolli iSCSI, Fibre Channel o SMB 3.0. Fibre Channel e iSCSI forniscono memorizzazione a livello di blocco mentre SMB 3.0 è una memorizzazione a livello di file. Fibre Channel richiede un’interfaccia fisica speciale per collegare i server allo storage come SAN (Storage Area Network). FCoE (Fibre Channel over Ethernet) può essere utilizzato per collegare lo storage tramite reti Ethernet. Il protocollo iSCSI può essere utilizzato per collegare un server a SAN o NAS (Network Attached Storage). Il dispositivo NAS assomiglia a un mini server che ha un controller RAID con slot per dischi interni e porte diverse per collegarsi alla rete esterna. Un server autonomo può anche essere configurato per essere utilizzato come NAS. SAN e NAS possono garantire la ridondanza dei dati per una maggiore affidabilità.

Quando si implementa un cluster di failover, deve essere utilizzato uno storage remoto condiviso con tutti i nodi all’interno del cluster. In questo caso, tale storage è chiamato storage condiviso.

Utilizzare RAID 1 o RAID 10

RAID è l’array ridondante di dischi indipendenti. La ridondanza dei dati sul tuo storage può proteggere i tuoi dati nel caso di guasto del disco. Ci sono diversi tipi di RAID.

RAID 0 non è ridondante ed è chiamato striping dei dischi. Non c’è tolleranza ai guasti – il fallimento di un disco causa il fallimento dell’intero array. L’aumento delle prestazioni può essere menzionato come caso d’uso (ad esempio, memorizzazione nella cache di flussi live per l’industria televisiva). Sono necessari almeno 2 dischi per costruire questo tipo di RAID.

RAID 1 è ridondante. Tutti i blocchi su un disco sono specchiati su un altro disco, quindi si ottiene una ridondanza del 100%. Se uno dei dischi fallisce, i dati sul secondo disco possono essere accessi e utilizzati per ricostruire l’array. La probabilità di un ripristino riuscito dell’array è alta. RAID 1 può essere utilizzato per lo storage di failover. È necessario un minimo di 2 dischi per costruire questo tipo di RAID.

RAID 10 è una combinazione di RAID 0 e RAID 1. Vengono utilizzati i vantaggi di entrambi i tipi di array, quindi il risultato è un array tollerante ai guasti con prestazioni più elevate. I dischi specchiati vengono combinati in una striscia. È necessario un minimo di 4 dischi per costruire questo tipo di RAID. Se RAID 10 è composto da 4 dischi, i dati possono essere protetti in caso di guasto di un singolo disco. Inoltre, l’array a 4 dischi può sopravvivere se due dischi provenienti da specchi diversi falliscono.

RAID 5 fornisce uno striping con parità. I blocchi sono stripati sui dischi, ma le informazioni di parità che possono essere utilizzate per il ripristino sono anche memorizzate sui dischi. Lo spazio occupato dalle informazioni di parità è uguale alla capacità di un disco. Ad esempio, le informazioni di parità occupano circa il 25% dello spazio per un array a 4 dischi. Non è ridondante al 100% come RAID 1. In teoria, RAID 5 può sopravvivere se uno dei dischi fallisce. È necessario un minimo di 3 dischi per costruire questo tipo di RAID.

RAID 6 fornisce uno striping con doppia parità. Questo è simile al concetto di RAID 5 ma le informazioni di parità sono memorizzate su due dischi invece che su uno solo. RAID 6 può sopravvivere in caso di guasto fino a due dischi. È necessario un minimo di 4 dischi per costruire questo tipo di RAID.

A prima vista, RAID 5 e RAID 6 sembrano attraenti, ma esaminiamoli più da vicino. RAID 5 è stato sviluppato decine di anni fa, quando la capacità dei dischi era piuttosto ridotta. Nel mondo moderno, la capacità dei dischi rigidi aumenta più velocemente della velocità del disco – di conseguenza, se un disco si guasta, la ricostruzione di RAID 5 può richiedere molto tempo. Il carico di lavoro di ciascun disco in RAID 5 aumenta significativamente durante una ricostruzione, specialmente se il server utilizza intensamente il storage per svolgere compiti regolari allo stesso tempo. Potrebbero esserci dati raramente utilizzati sui dischi che appartengono a RAID 5; e non puoi essere sicuro che questi dati possano essere letti con successo. Ciò aumenta la probabilità di errore. Se si verifica un errore durante la ricostruzione dell’array, l’intero array potrebbe fallire. Quando RAID 5 ha un disco danneggiato, questo array funziona come RAID 0 e i dati sono a rischio.

RAID 6 ha il doppio dei dati di parità che possono essere utilizzati per il recupero rispetto a RAID 5. Di conseguenza, la probabilità di sopravvivere alla rottura di un disco e la probabilità di una ricostruzione di successo sono più alte. RAID 6 ha un altro problema – le sue prestazioni sono le più basse rispetto a RAID 10 e RAID 5. I problemi di prestazioni si notano soprattutto durante la ricostruzione.

Come si può vedere, RAID 1 e RAID 10 offrono la massima affidabilità, motivo per cui sono raccomandati per l’utilizzo per il storage di Hyper-V. Il RAID hardware può essere configurato su un server fisico o su un dispositivo NAS.

Sfruttare il storage ad alta velocità

Le prestazioni di input/output dello storage hanno un impatto significativo sulle prestazioni sufficienti delle VM. I dischi rigidi (HDD) più veloci dovrebbero essere utilizzati per memorizzare le VM. Esiste un’ampia gamma di dischi rigidi moderni con elevate caratteristiche di prestazioni, che offrono velocità elevate a un prezzo accessibile per gigabyte. Se la velocità di un disco rigido non è sufficiente per le tue VM, puoi utilizzare un’unità a stato solido (SSD). Non ci sono parti mobili in un SSD rispetto ai classici HDD rotanti, quindi un SSD offre una velocità maggiore, ma è più costoso. Il prezzo per gigabyte di un SSD è più alto e la sua capacità complessiva è di solito inferiore a quella di un HDD. Utilizzando i dischi con le prestazioni più elevate per il tuo storage Hyper-V, le VM sono in grado di funzionare senza ritardi.

Utilizza un volume dedicato per memorizzare le VM

Evita di memorizzare le VM sui volumi di sistema. Il volume di sistema è di solito occupato dalla lettura o dalla scrittura di file di sistema utilizzati dal sistema operativo (C:\ è sempre un volume di sistema per impostazione predefinita). Pertanto, memorizzare i file VM sul volume di sistema può ridurre le prestazioni delle VM. Un altro problema che può sorgere è quello della mancanza di spazio libero sul volume. Questa situazione può verificarsi quando i file di sistema occupano tutto lo spazio libero del disco, o quando i file VM come i file di disco virtuale occupano tutto lo spazio disco. Di conseguenza, le VM su cui sono memorizzati i file all’interno di un volume di sistema sono a rischio di fallimento. Inoltre, l’host Hyper-V potrebbe anche non funzionare correttamente senza spazio libero sufficiente per scrivere file di sistema. Utilizza volumi separati per memorizzare i sistemi operativi e le VM. Inoltre, evita di memorizzare file di sistema come file di swap su unità utilizzate per i dati delle VM.

Archiviare i file della VM in un’unica posizione

Alcuni dei principali file della macchina virtuale Hyper-V sono: VHDX (VHD) – file del disco virtuale, AVHDX – file del disco virtuale differenziale, VMCX – file di configurazione e VMRS – file di stato di esecuzione. I file della VM potrebbero essere archiviati in diverse posizioni predefinite che non sono convenienti per gli amministratori. Per evitarlo, specificare una singola directory per archiviare tutti i file che appartengono alla VM corrente. Nella schermata sottostante è possibile vedere che tutti i file che appartengono a una VM chiamata Server2016-01 sono archiviati in sotto directory di una singola directory che si chiama Server2016-01.

Lasciare spazio per i file BIN (VMRS)

I file BIN consumano spazio su disco per memorizzare lo stato della memoria. A questo scopo, dovrebbe essere lasciato uno spazio riservato sui volumi in cui sono archiviati i file della VM. Dal 2016, l’estensione di questo tipo di file è stata cambiata da BIN a VMRS. Questo tipo di file occupa il secondo posto nel consumo di spazio su disco dopo i file del disco virtuale VHDX. Le dimensioni di un file BIN (VMRS) sono uguali alle dimensioni della memoria virtuale della VM. Ad esempio, se la VM ha un disco virtuale da 30 GB e 8 GB di memoria virtuale, è necessario riservare almeno 38 GB sullo storage. Se la memoria virtuale dinamica è configurata per una VM, le dimensioni del file BIN (VMRS) sarebbero uguali alla quantità di memoria assegnata in quel momento specifico.

Quale sistema di file utilizzare: NTFS o ReFS?

NTFS (New Technology File System) è un sistema di file creato da Microsoft nel 1993 e ampiamente utilizzato negli ambienti Windows ai giorni nostri.

Il ReFS (Resilient File System) è il sistema di file più recente di Microsoft rilasciato con Windows Server 2012 che presenta miglioramenti come:

  • Protezione dei dati contro la corruzione tramite checksum per metadati e file
  • Integrazione con spazi di archiviazione
  • Controllo automatico dell’integrità dei dati e correzione degli errori (se si verifica un errore)
  • Tecnologia di clonazione a blocchi (utile durante il clonaggio delle VM)
  • Maggiore tolleranza agli black-out
  • Supporto per la crittografia con BitLocker
  • Aumento della dimensione massima del file e della lunghezza del nome del file
  • Aumento del volume massimo
  • Creazione più veloce di dischi virtuali fissi

Come si può vedere, il sistema di file ReFS ha un lungo elenco di vantaggi ed è progettato per soddisfare in modo più efficiente i requisiti di archiviazione del server. Tuttavia, sono presenti anche alcuni svantaggi:

  • Windows non può essere caricato da un volume ReFS
  • Compressione dei dati, deduplicazione basata su file di Windows, crittografia dei file, collegamenti fisici, attributi estesi, quote disco non sono supportati
  • Non può essere utilizzato per volumi condivisi clusterizzati
  • Non fornisce supporto per i nomi file legacy 8.3

Infine, la scelta del sistema di file spetta all’amministratore. È consigliabile utilizzare ReFS per l’archiviazione Hyper-V se i limiti di ReFS non sono importanti per il sistema.

Utilizzare una rete di archiviazione ad alta velocità

Quando si utilizza un archivio remoto, la connessione di rete è un fattore cruciale. Se si dispone di dischi ad alta velocità nel NAS o nel SAN ma una connessione di rete lenta, le prestazioni complessive del sistema di archiviazione verrebbero degradate. È per questo motivo che si consiglia di utilizzare una rete ad alta velocità dedicata con bassa latenza. Si consiglia una connessione di rete da 10 Gbit per garantire una velocità accettabile. L’uso del teaming NIC per l’aggregazione di banda è anche utile.

Evitare di memorizzare il VM con Controller di Dominio su condivisione SMB3

L’accesso a un controller di dominio è necessario per il funzionamento corretto della condivisione SMB 3.0. Se un host con condivisione SMB 3.0 o un host Hyper-V non riesce ad accedere al controller di dominio, non può essere superata l’autenticazione e non può essere stabilita una connessione. In questa situazione, un server Hyper-V non è in grado di avviare un VM con Controller di Dominio che è posizionato su condivisione SMB 3.0. Mantenere un VM con Controller di Dominio nell’archiviazione locale del vostro host Hyper-V al fine di prevenire questo problema.

Fare uso delle Volumi condivisi del cluster per l’archiviazione cluster

Durante la distribuzione di un cluster, è necessario configurare l’archiviazione condivisa. Quando si utilizza un archiviazione tradizionale senza CSV, solo un nodo (host Hyper-V) può accedere allo stesso disco/LUN alla volta. I Volumi condivisi del cluster (CSV) possono risolvere questo problema fornendo l’accesso simultaneo all’archiviazione per più nodi senza rimonta dei volumi e cambiando la proprietà con i permessi. Con CSV è possibile avere un file system cluster su NTFS o ReFS per Hyper-V.

Evitare l’uso dei dischi pass-through

A pass-through disk is a physical disk (LUN) that is connected to a virtual machine. This type of disk is used as a storage device and is connected directly to the disk controller of a VM. For the first versions of Hyper-V, using pass-through disks helped increase performance. Nowadays, formats of virtual disks are progressive enough – thus, including performance and using pass-through disks does not make sense because of the issues that may occur when using them. You cannot easily move a pass-through disk with a virtual machine, and backup software cannot make a backup of a VM with this disk type on a host level.

Quale tipo di disco virtuale preferire – VHD o VHDX?

VHD è un formato legacy dei dischi virtuali per le macchine virtuali introdotto nel 2003. VHDX è un formato più avanzato (rilasciato con Windows Server 2012) che ha un limite di capacità maggiore per un disco virtuale (fino a 64TB), supporta blocchi da 4KB, ha un ridimensionamento live del disco virtuale e ha un aggiornamento continuo della struttura dei metadati che riduce la probabilità di corruzione dei dati causata dalla perdita di alimentazione. Per questo motivo, è preferibile utilizzare dischi virtuali VHDX nel proprio ambiente Hyper-V.

L’uso di dischi virtuali fissi e in espansione dinamica

A fixed virtual disk is a VHDX (VHD) file that consumes all pre-allocated space on storage, despite the amount of space used inside the virtual disk. The advantages of using a fixed virtual disk are that they work faster, no issues may be caused by over-provisioning, and the fragmentation of the VHDX file is the same after creation. The disadvantages of using a fixed virtual disk are that their creation may take a longer time on NTFS volumes, and more space on storage is needed for disk creation.

Il disco virtuale in espansione dinamica inizia con una piccola dimensione di alcuni kilobyte dopo la preallocazione, cresce dopo la scrittura di file all’interno del disco virtuale fino a raggiungere la dimensione massima preallocata durante la creazione del disco. Un disco dinamico non può essere ridotto automaticamente quando i dati su questo tipo di disco vengono eliminati. I vantaggi dell’utilizzo di dischi dinamici sono che risparmiano spazio, sono veloci da creare e includono la sovrallocazione. Gli svantaggi sono che i dischi dinamici sono più lenti dei dischi fissi, comportano una maggiore frammentazione e la sovrallocazione potrebbe causare spazio libero insufficiente sullo storage dopo l’espansione dei dischi dinamici.

È possibile utilizzare sia dischi virtuali fissi che dinamici a seconda delle proprie esigenze.

Dischi virtuali a differenza

A differencing virtual hard disk is a virtual disk file (AVHDX or AVHD) that is created in the VM directory with virtual disks after checkpoint creation. The purpose of differencing the virtual disk is storing changes that are written to a parent virtual disk of a VM after creating a checkpoint. A parent virtual disk can be a fixed, dynamic, or differencing disk. When a checkpoint is deleted, the differencing virtual disk that has been created with this checkpoint is merged with a parent virtual disk. Differencing virtual disk can also be created with Hyper-V’s new virtual hard disk wizard. It is important to note that creating a high number of checkpoints causes the creation of growing differencing virtual disks, which results in performance decreases.

Monitoraggio della salute e delle prestazioni del disco

Monitorare regolarmente la salute del disco può prevenire eventuali danni al disco che potrebbero causare la corruzione dei dati. Utilizza strumenti che possono monitorare i dati S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) dei dischi, compresi i dischi che appartengono a RAID. Più presto identifichi un disco con problemi, maggiore è la probabilità che i tuoi dati siano al sicuro. La performance del disco dovrebbe essere monitorata anche per identificare quali dischi possono essere sovraccaricati. Questo può aiutarti a prendere una decisione per ridistribuire le VM con operazioni intensive sul disco tra altri storage al fine di ottimizzare le prestazioni complessive.

Conclusione

Lo storage è un componente cruciale per i server perché i dati che contiene sono particolarmente importanti per la maggior parte delle aziende IT. Il post di blog di oggi ha coperto le migliori pratiche di storage per Hyper-V, che possono aiutare a ottimizzare le prestazioni delle VM e garantire un’alta affidabilità dello storage. Tra tutte le raccomandazioni elencate sopra, scegli quelle che si adattano al tuo ambiente.

Anche se hai uno storage di alta classe, è importante eseguire il backup dei dati delle tue VM Hyper-V in modo appropriato. NAKIVO Backup & Replication può aiutarti a eseguire il backup delle tue VM Hyper-V nel modo più efficiente.

Source:
https://www.nakivo.com/blog/hyper-v-storage-best-practices/