Una delle principali novità introdotte con Hyper-V 3.0 è la funzionalità di replica. Questa funzionalità viene spesso assimilita con ciò che prende il nome di failover clustering, ma le due funzionalità sono ben distinte e non vanno confuse. Anche lo scopo di utilizzo delle due feature è completamente diverso. Ad un rapido sguardo sembrerebero due tecnologie ridondanti, in grado di tutelarci da un guasto hardware sul nodo fisico dove sono hostate le nostre VM, ma osserviamo più nel dettaglio la cosa.
Il failover cluster ci viene in aiuto principalmente in due casi:
- Guasto di un nodo ospitante un certo numero di macchine virtuali: in autonomia, il nostro cluster gestisce lo spostamento delle VM che erano ospitate sul nodo defunto verso uno o più nodi, così che i servizi erogati dalle nostre istanze virtuali riprendano a funzionare nel giro di pochi minuti;
- Manutenzione dell’host fisico: supponendo di dover fare manutenzione hardware o software sul nodo fisico è possibile spostare le VM ospitate verso gli altri nodi del cluster in modalità live. Questo significa che i servizi erogati dalle macchine virtuali non subiranno nessun tipo di interruzione e lo spostamento sarà totalmente trasparente agli utenti.
Dalla versione 3.0 di Hyper-V è stata introdotta la possibilità di realizzare un cluster di failover senza necessariamente dover ricorrere necessariamente a storage condivisi. Questa novità è molto importante poiché abbatte notevolmente il costo di una soluzione cluster-based rendendola, rispetto al passato, più appetibile anche per aziende di dimensioni ridotte e con inferiori capacità di investimento economico.
Grazie all’assenza dello storage condiviso tra i requisiti del cluster oggi è possibile pensare a dei cluster geografici, con i nodi dislocati in differenti datacenter.
La funzionalità di replica invece consente, come il nome stesso suggerisce, di replicare una VM su un secondo host fisico. Anche questa tecnologia non necessita di storage condiviso e l’host di replica potrebbe trovarsi in un’altra posizione geografica rispetto alla macchina principale. La differenza sostanziale rispetto ad un cluster è che il sistema non è in grado di intervenire autonomamente in caso di guasto ed è quindi necessario intervenire manualmente per avviare il failover.
La funzionalità di replica consente di operare replicando le VM in 4 differenti modalità che sono:
- Nodo – Nodo
- Nodo – Cluster
- Cluster – Nodo
- Cluster – Cluster
Nulla vieta quindi di replicare, ad esempio, delle VM in esecuzione su un cluster nel datacenter A verso un singolo nodo localizzato nel datacenter B a patto che, ovviamente, il nodo abbia i requisiti per poter ospitare e mantenere in esecuzione tutte le VM in caso di necessità.
A differenza di quanto avviene in un cluster geografico, la replica funziona in modo asincrono. Ciò consente di operare anche attraverso connessioni internet senza una elevata banda disponibile. Un sistema cluster, al contrario, richiede una connettività stabile e performante, poiché la comunicazione heartbeat tra i nodi è indispensabile per poter capire quali siano quelli in funzione e stabilire se avviare le eventuali procedure di failover.
La replica geografica ha quindi un minore impatto economico rispetto all’implementazione di un cluster geografico.
Scegliendo di adottare la soluzione basata su replica geografica va tenuto conto che, per poter mandare correttamente in produzione la macchina virtuale remota, in caso di failover sarà necessario agire a livello di routing. Questa incombenza non si presenta, invece, in caso di replica tra due nodi nella stessa subnet.
Per meglio analizzare questa interessante funzionalità ho in programma di realizzare uno scenario dimostrativo sul funzionamento della replica geografica in ambiente Hyper-V 3.0, non appena avrò un briciolo di tempo a disposizione. Stay tuned!
Intanto, per concludere, dico solo un’ultima cosa: la replica non sostituisce il backup! Prendiamolo intanto come un dato di fatto. A breve, con un sistema funzionante alla mano, vedremo anche il perché.
Leave a Reply