• Guide, Sistemi Operativi
• 28 Marzo 2020

Hyper-V Replica è una funzionalità che permette di replicare automaticamente le modifiche di una macchina virtuale principale su una macchina virtuale “clone” posta su un altro server fisico, anche a chilometri di distanza.

Un sistema di replica a regime può essere utilizzato in diversi frangenti:

Failover pianificato: quando abbiamo bisogno di fare manutenzione hardware al sito primario. Possiamo trasferire il carico di lavoro sul sito di replica, effettuare il lavoro e utilizzare la replica inversa per ripristinare l’originaria direzione della replica.

Failover non pianificato: quando si verificano guasti hardware. In questo caso si possono perdere i dati non ancora replicati.

Test Failover: quando vogliamo fare dei test sulla macchina di replica evitando conflitti con la primaria. Hyper-V in questo caso disabilita la scheda di rete della macchina virtuale su cui eseguiamo il test.

Hyper-V Replica “ad incrocio”

Su sistemi che virtualizzano più di una macchina virtuale, ho utilizzato un sistema di replica ad incrocio che permette di ottimizzare l’hardware acquistato, distribuendo, anche nei periodi di normale funzionamento, il carico delle macchine virtuali su tutte le macchine fisiche. Per semplificare l’esempio userò due server fisici e due macchine virtuali.

Didatticamente si individua un sito primario e un sito di replica. Il sito in cui viene custodita la macchina virtuale principale prende il nome di sito primario, l’altro di sito di replica.

Con una replica ad incrocio, un sito è sia principale che di replica; le macchine fisiche sono tutte utilizzate (non solo per la replica) e si dividono il carico.

Autenticazione tramite certificati

Hyper-V Replica può essere configurato in modo indipendente dalla configurazione delle macchine fisiche, che possono essere nello stesso dominio, su due domini differenti o senza alcun dominio.
I server fisici che appartengono al meccanismo di replica devono autenticarsi tra loro; questa autenticazione può avvenire tramite dominio o tramite certificati.

In questo articolo vediamo come configurare Hyper-V Replica con i server che si autenticano tramite certificati.
Tale configurazione è utile, ad esempio, quando il controller di dominio è virtualizzato sulla macchina fisica oggetto di replica.
La direzione della replica avviene solitamente dal sito primario al sito di replica, ma per i “ripristini” dopo Failover (ad esempio Failover pianificato) si invertirà la direzione della replica, l’autenticazione quindi deve avvenire nelle due direzioni.

Configurazione di Hyper-V replica con autenticazione tramite certificati

1. I server fisici devono essere raggiungibili tra loro con il proprio nome; se non si dispone di un server DNS, occorre modificare il file HOSTS dei server fisici.
2. Abilitare la regola “Hyper-V Replica HTTPS” (in italiano la regola si chiama “Listener HTTPS di Replica Hyper-V (TCP-In)” )
3. Se non si usano CA pubbliche per i certificati, occorre generare un certificato root e per ogni server fisico un certificato per l’autenticazione tra client e server.Sul Server Fisico 1 (il mio SERVER107) digitare

Si può utilizzare qualsiasi valore per il CN del certificato, (io ho usato SERVER107 perché è il nome del mio server fisico 1).
Prendi nota del “Thumbprint” del nuovo certificato.
(Nel mio caso il Thumbrint è F97954B924E24576E5D1A5373FD411A2E2630DC0)

È il momento di generare il certificato di autenticazione client/server per ogni host. Questi certificati dovranno avere come CN il nome del server fisico ed utilizzare il thunbprint del certificato root.
Digitare quindi il comando:

Nel mio caso ho generato il certificato per SERVER106 (il server di destinazione) e il certificato per SERVER107 (il server destinazione della replica inversa) usando il Thumbprint del certificato root precedente.

4. Esportiamo i certificati dalla CA ed importiamo i certificati sui server replica.

Esporta i nuovi certificati che saranno in “Personal” nello snap-in “Certificati”

Esporta i certificati Host includendo la chiave privata, utilizza il formato PFX.

Fai lo stesso con il certificato del secondo server.
Esporta il certificato di root senza includere la chiave privata e utilizza il formato CER
Il certificato root verrà esportato singolarmente, disabilita l’opzione di esportazione di tutti i certificati del percorso.

Copia in tutti i server fisici il certificato root e il certificato di autenticazione client/server corrispondente.
In ogni server fisico importa il certificato root in “Autorità di certificazione radice attendibili” e il certificato host in “Personale”

5. Disabilitare la verifica della revoca dei certificati digitando su tutti i server fisici

6. Configurare Hyper-V per la replica del primo server virtuale
   In Hyper-V manager apri le impostazioni (nel server che riceverà le macchine virtuali in replica) e vai in “Replication Configuration”

Hyper-V dovrebbe suggerire il certificato corretto.

Scegli da chi consentire le repliche

Replica delle macchine virtuali

Nella macchina host sorgente, clicca con il destro sulla macchina virtuale da replicare e scegli “Abilitazione replica…”

Digita il nome del server destinazione della replica

Scegli il certificato corretto

Scegli i dischi da replicare

Scegli la frequenza della replica

Scegli il numero di repliche da tenere

Scegli quando iniziare la replica iniziale

Controlla il riepilogo e conferma

Ora il server virtuale1 sta replicando sul Server Fisico2

Al termine della configurazione viene generata la Replica iniziale che consiste nella copia completa della macchina virtuale principale; al termine di questa prima copia il sistema comincerà a copiare le modifiche apportate al disco della macchina virtuale del sito primario sul sito di replica ad intervalli regolari di 5,10,15 minuti a seconda dell’impostazione scelta.

Fai la stessa cosa all’inverso per l’altro server virtuale.

Quando avrai finito avremo ottenuto due server fisici che possono abilitare repliche e repliche inverse senza problemi.
Potremo, a questo punto, suddividere il carico distribuendo le macchine virtuali su più server e attivando le repliche per garantire una maggiore flessibilità e business continuity.