Nella prima parte tratteremo come configurare configurare la replica di macchine virtuali in sistemi Hyper-V utilizzando 2 server separati di cui uno sarà il sito primario e un secondo il secondario dove le macchine virtuali del sito primario verranno replicate costantemente nel secondario.
Nella seconda parte, parleremo di come configurare un cluster di failover nel il sito primario, dove più server parteciperanno all’esecuzione delle macchine virtuali che attingono a uno storage condiviso, per poi replicare le macchine in su un sito secondario tramite il ruoli replica broker del cluster.
Finiremo nel illustrare il software Hyper-V Monitor, progetto creato a me nel 2017, che ha come finalità il monitoraggio remoto di questi sistemi e la corretta replicazione tramite dashboard visive e alert via mail in caso di avventurali anomalie sulla replicazione.
Per approfondire è possibile accedere a questo link www.hyper-monitor.com.
Cos’è la replicazione in Hyper-V
La funzione di replica in Hyper V permette di replicare una macchina virtuale da un sito primario a un secondario entro un breve intervallo di tempo (anche ogni 5 secondi). Questa operazione permette una business continuity nel caso il sito primario non fosse più raggiungibile, oppure come in questo periodo il sito primario sia attaccato da una minaccia informatica, permettendo in pochissimo tempo di riavviare le macchine nel sito secondario, senza dover attingere e ripristinare i backup, molto spesso lunghi da ripristinare.
La funzione e di replica è completamente integrata in Hyper-V e non richiede licenze native o software di terze parti e quindi costi aggiuntivi oltre alla licenza di Windows Server, quindi molto conveniente rispetto ad alte soluzioni di virtualizzazione.
La replicazione è possibile essere effettuata sia tra 2 server indipendenti, uno che sarà il primario e il secondario, ma anche tra un cluster primario a un server indipendente, tramite il servizio di replica broker, sia da cluster primario a cluster secondario.
Il cluster si intende un insieme di server che tramite il servizio cluster di failover, i server che ne fanno parte partecipano a livello computazionale all’esecuzione di macchine virtuali sullo stesso storage condiviso, come una san, vsan o un volume iScsi. Le macchine che girano nel cluster possono velocemente essere spostate da un nodo all’altro.
Anche la funzionalità di cluster di failover è inclusa inclusa nel sistema operativo server e non richiede licenze aggiuntive.
Replicazione delle VM da un sito primario a uno replica
In questa parte tratteremo come configurare un sistema in cui in un server primario dove gireranno le nostre macchine virtuali, in un intervallo che può essere di 30 secondi, 5 minuti o 15 minuti, le macchine del sito primario verranno replicate in un sito secondario per ottenere una business continuity.
Il funzionamento è molto semplice. Se il nostro sito primario non fosse più raggiungibile o una macchina virtuale contenute in esso, potremmo avviare in brevissimo tempo le macchine replicare nel sito di replica.
Quello che ci servirà sono 2 server con Windows Server 2019.
Server primario: NODE-HV-02.hyper-monitor.local
Server replica: NODE-HV-REPLICA.hyper-monitor.local
La versione dei sistemi operativi non è vincolate, però tenete presente che se avete 2 server di versioni differenti (es. 2019 e 2016) le macchine virtuali andranno create con la versione meno aggiornata per poter eseguire la replica tra macchine.
Installazione
Dopo aver messo in dominio le 2 macchine che chiameremo primaria e replica, installiamo il ruolo hyper-v su entrambe le macchine come dagli step sottostanti.
Indichiamo quale interfaccia usare per le macchine virtuali che verranno avviate, in questo caso io ne ho solo una, ma in infrastrutture più strutturate può essere usata un altra interfaccia di rete.
Configuriamo dove i file di configurazioni e i dischi virtuali saranno salvati nella macchina locale.
Possiamo far riavviare il sistema automaticamente alla conclusione del installazione, quindi avviamo l’installazione del ruolo Hyper-V.
A questo punto dopo il riavvio in entrambi i server è apparsa la console di gestione di hyper-V
Interfaccia di gestione
La console gestione di Hyper-V, la possiamo cercare da pannello di controllo negli Strumenti amministrativi oppure cercandola nello start, contiene tutti gli strumenti per gestire le nostre macchine virtuali e operazioni varie. In questo caso ci siamo collegati al server che fungerà da primario.
Ora la console non contiene nessuna VM, quindi creiamo una macchina virtuale. Gli step sono molto semplici, è necessario eseguire il wizard di configurazione che comparirà.
A questo punto avviamola e tramite la voce connect possiamo collegarci alla console e verificare il corretto funzionamento.
Abilitazione replica
In tutti due i nodi ora andiamo a configurare la possibilità di accettare la replica da altri sistemi.
Abilitiamo le configurazioni segnate e le autorizzazioni dello storage.
Controllo di più server da una console
Per agevolare le operazioni di configurazione e gestione, possiamo aggiungere nella console del nodo primario anche quello di replica.
Per fare ciò selezioniamo “Hyper-V Manager” e aggiungiamo l’altro server.
Ora possiamo vedere che possiamo gestire entrambi i server Hyper-V da un unica console.
Creazione e attivazione replica
Ora configuriamo la replica di una VM del sever primario versoquello di replica. Per fare ciò dal menu della macchina virtuale da replicare eseguiamo la funzione di abilitazione replica.
Nei menu seguenti indichiamo la destinazione, dove la macchina virtuale nel server primario andrà a replicarsi
Proseguiamo configurando i parametri di connessione, che dovranno essere gli stessi impostati durante l’attivazione delle configurazioni di replica viste precedentemente.
Impostiamo l’intervallo di tempo che le modifiche vengano replicate nel server di replica.
In questo successivo menu possiamo indicare quanti punti di ripristino il nostro server replica conserverà. Mantenere piu punti di ripristino è utile nel caso si dovesse intervenire per disaster recovery oppure per ripristinare la macchina a una data antecedente per esempio da un attacco di un rasomware
Infine possiamo indicare come verrà eseguita la prima sincronizzazione. Di solito in rete interna si utilizza la replica via rete, però in alcuni casi quando è necessario replicare molti dati per esempio in un altra sede, dove la banda è limitata, è possibile esportare la macchina per poi importarla fisicamente nella sede secondaria e quindi avviare la replica. Questa metodologia viene eseguita da alcuni provider o software per il backup in cloud.
Ora non ci resta che confermare il tutto e avviare la configurazione.
A questo punto noterete che il server primario inizierà a inviare la replica iniziale, mentre quello di replica a ricevere.
Selezionando la macchina virtuale nella parte sottostante, è possibile vedere anche lo stato della replicazione. Questo dato è molto importante per assicurarci che la replica si stia svolgendo correttamente.
Planned Failover
Il planned failover è quella situazione, per esempio, per cui dobbiamo eseguire una manutenzione al server primario e quindi spostiamo l’operatività nel secondario, che è la nostra replica.
Hyper-V da uno strumento apposta per questa funzione, dal menu della macchina virtuale avviamo il Planned Failover.
A questo punto ci chiederà delle scelte, in particolare se avviare, dopo l’ultima sincronizzazione, l’avvio della macchina virtuale in automatico.
E’ possibile anche già da qui impostare che il nostro sito primario, già come replica, cosi che nel caso volessimo riportare tutto alla condizione iniziale, è già tutto sincronizzato (a quel punto è chiaro che dovremmo a sua volta eseguire un planned failover sul nodo primario).
E’ necessario che per eseguire questa operazione la macchina sia spenta, altrimenti ci sarà impossibile continuare.
Una volta confermato partirà il processo di failover.
Un altra nota importante, nel caso durante il processo di migrazione, venisse restituito che il sito non riesce a comunicare con il server, dovete aprire la porta la posta 80 del firewall nel server replica.
A questo punto possiamo vedere che la macchina è stata accesa e perfettamente operativa.
Nel caso non avessimo attivato la spunta che attiva la replicazione inversa, possiamo eseguirla manualmente come mostrato più avanti…
Cancel planned failover
Questa funzione ci è utile se per caso abbiamo avviato “per sbaglio” il planned failover per qualche ragione e si voglia tornare alla situazione iniziale.
Dal sito primario possiamo sempre dalla tendina accessibile tramite tasto destro, eseguire il “cancell planed failover”, la vm replica viene spenta e ripristinata la situazione iniziale.
In questo caso è chiaro che avremmo perso tutte le modifiche nella macchina replica accesa successivamente. Per eseguire questa funzionalità è anche necessario non aver impostato la replica inversa spiegata precedentemente.
Verrà chiesta conferma dell’operazione.
E possibile cancellare il planned failover anche dal server replica, in questo caso selezioniamo “Cancel Failover”
Reverse Replication
Il reverse replicazione, come accennato prima, permette di eseguire una replica inversa dopo un failover.
Questo porterà tutte le modifiche avvenute successivamente nel altro sito, in questo caso quello primario.
Per eseguire questo dalmenu della macchina virtuale attiviamo il reverse replication, si aprirà un wizard.
Dopo vari step che sono quelli che abbiamo già visto e avviamo la replica inversa.
A questo punto inizierà l’allineamento inverso, e renderà il server che prima era primario, un server di replica.
A fine operazione possiamo vedere che i ruoli primary/replica si sono invertiti.
Ora possiamo riportare l’esecuzione della macchina sul sito originale primario, avviando di nuovo un Planned failover sul sito di replica.
In questo caso, come spiegato prima, evitiamo di dover di nuove impostare la replica inversa, attivando già la spunta prima del failover
A questo punto abbiamo riportato la situazione alla condizione originale.
Unplanned failover
A questo punto vediamo la condizione peggiore per cui è utile e fondamentale il sistema replica, il disaster recovery del sito primario dovuto da qualsiasi motivo, es. guasto hardware, rasomware ecc, per cui il nostro sito primario non è più operativo.
E’ necessario collegarci al sito replica e avviare il failover.
Se abbiamo impostato più punti possiamo utilizzare quello piu utile per la nostra condizione.
A questo punto in un baleno ritorniamo di nuovo operativi, Failover complete!
Test Failover
Test failover è un utilità di verifica della replicazione, il sistema creerà una copia della macchina utilizzando il punti di replica desiderata, per poterla avviare e verificare la consistenza.
E’ presente una macchina perfettamente funzionate identica a quella replicata.
Checkpoint
Il checkpoint, per chi conosce gli ambienti VMware, non è altro che la snapshot.
Questa funzionalità permette di eseguire un punti di ripristino immediato. Questa funzionalità è molto utile nelle manutenzioni per tornare indietro senza dover ripristinare la macchina da backup e eseguire dei ripristini applicativi interni.
E possibile eseguire e mantenere uno o più punti di ripristino
Ci sono anche funzionalità anche più avanzate, oltre al roolback del checkpoint, quella di esportare il punto di ripristino oppure cancellare uno o più punti.
View Replication Health
Un ultima funzione molto importante legata alla replicazione, è verificare lo stato.
Da questa funzione è possibile verificare
Da questa schermata è possibile verificare lo stato della replicazione, se nel corso delle ore di attività ci sono state degli errori, il traffico scambiato e altre informazioni importanti.
Situazioni per cui ci è necessaria la replica
La situazione più grave per cui è necessaria è la rottura del server primario, quindi recandoci nel sito replica possiamo avviare il failover all’ultimo ripristino e potremmo in breve tempo continuare a lavorare.
Potrebbe succedere che una macchina prenda un rasomware o un aggiornamento non la faccia piu partire. E’ vero che potremmo accedere ai backup per ripristinare la macchina, ma questo impiegherà molto tempo per spostare i dati dal backup a server primario. Se abbiamo impostato sufficienti punti di ripristino sul server replica potremmo ripristinare la macchina a una data antecedente al fatto.
Potrebbe essere anche necessario eseguire una manutenzione sul sito principale, per cui possiamo pianificare un failover pianificato e mantener la macchina accesa e funzionate sul sito replica, per poi invertire la replicazione una volta che il sito primario sia operativo per continuare ad eseguire la macchina aggiornata sul sito principale.
Riassumendo
Questa soluzione appena descritta permette di ottenere una business continuity e tramite una soluzione di disaster recovery integrata di Hyper-V.
A differenza di altre soluzioni, come Vmware o soluzioni HCI è molto competitiva a livello di costi di implementazione e non richiede altro software di terze parti.
Nel prossimo articolo vedremmo come integrare un cluster con più server, per aggiungere una scalabilità della parte computazionale e configurando sempre un sito replica per le emergenze.