Nella Parte 1 di questo articolo ho trattato dell’architettura generale di CSV e dei suoi principi di funzionamento. Vediamo ora gli scopi precisi di utilizzo ed i requisiti necessari per l’implementazione della tecnica.
Scopi di utilizzo e benefici della tecnica CSV
Ripartiamo dalla constatazione che NON è strettamente obbligatorio configurare CSV quando si vuole implementare l’alta disponibilità delle macchine virtuali in Hyper-V, ma grazie ai suoi benefici, è altamente raccomandato utilizzarla.
Quali sono i vantaggi?
- Ridotto numero di LUN da creare. Si può utilizzare CSV per ridurre il numero di LUN richiesti dalle macchine virtuali. Quando si attiva e configura CSV, si possono memorizzare multiple macchine virtuali su un singolo LUN, e multipli “host server” possono accedere allo stesso LUN simultaneamente.
- Cluster Validation più veloce. Utilizzando un minor numero di LUN, il wizard che controlla la validità dello storage (”Cluster Validation Wizard” nella console del “Failover Cluster) viene eseguito più speditamente
- Miglior utilizzo di spazio su disco. Invece di piazzare ogni singolo vhd su un disco separato con dello spazio libero in modo che il vhd possa espandersi, posso più facilmente occupare lo spazio libero su un LUN memorizzando su di lui multipli vhd (e se questi sono di tipo “Fixed”, posso già dall’inizio calcolare l’occupazione di spazio sul LUN).
- Nessun particolare requisito hardware necessario. Si può implementare CSV su qualunque configurazione di dischi supportata, e su SAN a fibra ottica, iSCSI o SAS.
- Miglior recuperabilità. CSV aumenta la recuperabilità in quanto il cluster può rispondere correttamente anche se la connettività tra un nodo e la SAN è interrotta, oppure una parte della rete è caduta. Il cluster re-instrada il traffico CSV attraverso una parte intatta della SAN e/o della rete. Le caratteristiche di ridondanza di CSV saranno oggetto di un futuro articolo di questa serie.
- La configurazione delle macchine virtuali in Cluster è molto più semplice di prima
Quindi l’utilizzo di CSV è altamente consigliato negli scenari in cui sono vere tutte le seguenti condizioni, o la maggior parte di esse :
- presenza di numerose macchine virtuali, alla maggior parte delle quali bisogna garantire un’alta ridondanza
- in caso di disastri, le macchine virtuali devono essere recuperate col minor downtime possibile
- il trasferimento di macchine virtuali da un host all’altro (per es. per necessità di manutenzione di uno degli host) deve essere eseguito senza downtime delle macchine virtuali
- l’ottimizzazione dei costi dello storage è importante
Requisiti per l’implementazione di CSV
I nodi del cluster devono avere i seguenti prerequisiti :
- Tutti i nodi devono eseguire Windows Server 2008 R2 Enterprise o Datacenter Edition (Full o Server Core Installation), oppure Hyper-V Server 2008 R2. E’ possibile combinare nello stesso cluster nodi che eseguono Hyper-V Server 2008 R2 con nodi che eseguono Windows Server 2008 R2 Enterprise o Datacenter Server Core Installation
- La partizione di sistema su tutti i nodi deve avere la stessa lettera di drive (per es. C:)
- I Ruoli Hyper-V e Failover Cluster devono essere installati su ogni nodo che esegue una supportata edizione di Windows Server 2008 R2
- I processori di tutti i nodi devono supportare le tecniche Intel VT o AMD-V (attivabili nel BIOS)
- Non utilizzare nei nodi processori di differente fornitori (es. Intel e AMD)
- L’Hardware dei nodi dovrebbe essere il più simile possibile
- Assicurarsi di dotare ogni nodo di adeguata RAM, in modo da supportare il failover delle macchine virtuali da altri nodi
Lo Storage deve avere i seguenti prerequisiti :
- Lo storage su SAN deve essere compatibile con il Windows Server 2008 R2 Failover Cluster
- I LUN creati sulla SAN devono essere raggiungibili da tutti i nodi, via Fibre Channel, SAS o iSCSI
- Per assoggettare un LUN a CSV, questo deve essere visibile nella console del Cluster come “Physical Disk Resource” disponibile
- Se una macchina virtuale è dotata di un “Pass-Through Disk”, questo non può essere assoggettato a CSV, ma ciò non significa che una Live Migration della macchina virtuale non possa essere eseguita. Questo scenario verrà illustrato in un successivo articolo della serie
- I dischi in CSV sono identificati con un nome di percorso. Questi percorsi appaiono nella partizione di sistema dei nodi, nella cartella \ClusterStorage. I percorsi non sono altro che dei “Junction Point” verso i LUN
- I LUN possono essere creati col software di gestione del vendor della SAN, utilizzando configurazioni RAID di qualunque tipo : RAID 0, RAID 1, RAID 1+0, RAID 5, RAID 6. Consiglio la soluzione RAID 1+0 per le migliori performance nonchè ridondanza, anche se è accettabile anche un RAID 5 su un buon numero di dischi fisici
I prerequisiti di rete devono essere i seguenti :
- Installare un numero sufficiente di Schede di Rete in ogni nodo, in modo che una rete sia disponibile per CSV e altre reti siano disponibili per altri scopi (es. operazioni di gestione, traffico pubblico, traffico privato del cluster, connessioni via iSCSI allo storage)
- Per tutte le Schede di rete che trasportano comunicazioni del cluster, assicurarsi di attivare “Client for Microsoft Networks” e “File and Print Sharing for Microsoft Networks”, allo scopo di supportare SMB 2.0 (Server Message Block), che è richiesto da CSV. Solo una scheda di rete sarà la “preferred network” per le comunicazioni CSV, ma abilitare SMB 2.0 su tutte le schede di rete, permette al cluster di rispondere meglio alle rotture
- Tutti i nodi di un cluster con CSV attiva, devono risiedere sulla stessa sottorete logica. Questo significa che, in caso di Cluster Multisito che usano CSV, bisogna utilizzare una VLAN
- Ulteriori considerazioni sull’ambiente di rete CSV saranno illustrate nella parte 4 di questo articolo
Nella terza parte di questo articolo analizzerò più nel dettaglio il dimensionamento e il posizionamento dei LUN, dei volumi e dei files vhd in un ambiente di Cluster CSV.