Windows Server 2012 Hyper-V Replica in ambiente extra dominio tramite HTTPS

 

Ciao a tutti, continua il percorso di conoscenza di Windows Server 2012 e Hyper-V introducendo un altro argomento: Replica in ambiente extra dominio tramite HTTPS.

Ermanno Goletto, Roberto Massa e Mario Serra ci introducono l’argomento ma prima una loro breve descrizione.

Ermanno Goletto è certificato su tecnologie Microsoft dal 2004 (MCP, MCSA, MCTS, MCITP) e collabora con la Community Sysadmin.it dal 2006. Nel 2008 diventa Microsoft MVP per Directory Services e dal 2010 interviene come speaker a eventi e Conferenze sulle tecnologie Microsoft dedicati ai Professionisti IT.

 

 

Mario Serra ha conseguito differenti certificazioni Microsoft MCSDT, MCSE, MCTS e MCITP e attualmente lavora come sistemista tecnico senior. Dal 2009 collabora con la Community Sysadmin.it e ha partecipato come speaker a differenti eventi e Conferenze sulle tecnologie Microsoft. Da Aprile 2012 è MVP per la categoria Directory Services.

 

 

Roberto Massa, si occupa di Informatica dal 1989 impegnato da sempre nella gestione sistemi in ambito Windows Server, Linux, e Netware, ha approfondito la conoscenza di sistemi di monitoraggio Open-Source in particolare Nagios e Zenoss. Da alcuni anni si occupa di sicurezza implementando soluzioni basate su sistemi OpenBSD e OpenVPN. E’ intervenuto come speaker ad eventi Linuxday.

Attualmente è impiegato come sistemista presso l’Azienda Ospedaliera S. Croce e Carle di Cuneo.

Introduzione

Come già esaminato nel documento di overview, la funzionalità Hyper-V Replica, integrata in Windows Server 2012 consente una notevole flessibilità degli scenari di Disaster Recovery.

Questa funzionalità è nuova ed è stata introdotta da questa versione, è particolarmente utile per le realtà che non dispongono di budget molto elevati ma vogliono realizzare un servizio di questo tipo.

La possibilità di attivare Hyper-V Replica tra server in dominio verso server in workgroup, unita alla definizione di un “filtro di accesso e di replica” può essere utile per un piccolo gruppo di aziende che intendono attivare
questo servizio centralizzato anche condividendo i costi di un sito comune di Disaster Recovery realizzato, ad esempio in una sede staccata di un’azienda.

In questo articolo prenderemo in esame la soluzione di replica tra siti non appartenenti allo stesso dominio, geograficamente distanti e con una interconnessione non particolarmente performante.

Descrizione dello scenario di Test

L’ambiente realizzato in questo scenario coinvolge due server Hyper-v 2012 rispettivamente un server primario , ed un server di replica: sul  primo sono installate le VM  di produzione mentre sul secondo sono ospitate le  VM  replicate.

Entrambi i server NON sono parte di alcun dominio, mentre fanno (o possono fare)  parte di un dominio le VM replicate.

Le VM in replica sono rispettivamente una Windows 7 Professional ed un Windows Server 2012, su quest’ultimo uno script eseguito ogni 2 minuti genera un file di 200 Mb, al fine di  simulare una sorta di attività simile a quella di un server in produzione sul virtual disk della VM.

• Hyper-V server principale  nome Hyperv1srv ( ip 192.168.1.100)
• Hyper-V server 
  di replica ( DR ) nome  Hvreplica2
  ( ip 192.168.0.100)

Operazioni preliminari di configurazione

La tipologia di replica analizzata impone quindi che l’autenticazione ed il traffico tra il sito Primario ed il sito di Replica, (che per comodità chiameremo di DR), avvenga tramite certificati digitali, naturalmente i certificati, come vedremo possono essere auto-generati , senza
ricorrere quindi all’acquisto presso una CA esterna.

I certificati dovranno essere utilizzati da entrambe i server sia quello del sito primario che espone le VM per la replica, sia quello del sito di DR che ospita le VM replicate.

Su ogni server facente parte dello scenario di replica dovranno essere generati due certificati, il primo sarà il certificato  della ROOT AUTHORITY, mentre il secondo che verrà generato a partire da questo, sarà il certificato macchina  che dovrà essere utilizzato sia per la SERVER
AUTHENTICATION che per la CLIENT AUTHENTICATION                             

( OIDs 1.3.6.1.5.5.7.3.1 client authentication e 1.3.6.1.5.5.7.3.2 server authentication)

Il certificato ROOT CA generato per ogni server verrà manualmente copiato sull’altro, in questo modo ogni hypervisor  riconosce il proprio reciproco ed utilizza il certificato per l’instaurazione del tunnel Https.

L’operazione di scambio dei certificati ROOTCA non è necessaria se vengono utilizzati certificati pubblici rilasciati da CA commerciali.

Prima di configurare la Replica di Hyper-V, utilizzando la mutua autenticazione basata su certificato, è necessario eseguire le seguenti operazioni preliminari :

1)      Installare due server  Windows 2012 con il ruolo di Hyper-V attivato

2)      Configurare correttamente l’accesso ad internet

3)      Creare i certificati ROOT CA e macchina necessari per l’autenticazione reciproca

4)      Impostare il file HOSTS / DNS  per  da fare si che gli Hypervisor siano raggiungibili tramite un  nome  FQDN

5)      Scambiare i rispettivi certificati ROOT CA  ed installarli nell’archivio Trusted Root della Macchina Locale

6)      Modificare le chiavi di registro per disattivare la verifica della revoca dei certificati

Generazione dei certificati ROOTCA

Tramite l’utility Makecert.exe, scaricabile dall’URL http://msdn.microsoft.com/en-us/windowsserver/bb980924.aspx è necessario generare il certificato della ROOTCA per ciascun server

Sul server Hyperv1srv

makecert -pe -n "CN=hyperv1rootca" -ss root -sr LocalMachine -sky signature -r "hyperv1RootCA.cer"

Questo comando genera un certificato contrassegnato come esportabile con nome “Hyperv1RootCA” di tipo root lo posiziona nell’archivio localmachine, il certificato ha una chiave di tipo signature e contestualmente viene generato un file hyperv1rootca.cer
da utilizzare per la copia sul server di DR.

Gli stessi passi devono essere eseguiti sul server che ospiterà la replica si riportano di seguito i comandi da utilizzare per la creazione della ROOTCA sul server Hvreplica2

 

makecert -pe -n "CN=hvreplica2rootca" -ss root -sr LocalMachine -sky signature -r "hvreplica2RootCA.cer"

 

Generazione del certificato macchina

Sempre con l’utility Makecert.exe si deve generare il certificato macchina a partire dal ROOTCA generato in precedenza

Sul server Hyperv1srv

makecert -pe -n "CN=Hyperv1" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "hyperv1RootCA" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 hyperv1.cer

Sul server Hvreplica2

makecert -pe -n "CN=Hvreplica2" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in " hvreplica2RootCA " -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 hvreplica2.cer

Definizione dei nomi FQDN degli HyperVisor

Nel caso descritto in questo articolo non vi erano a disposizione DNS pubblici per le connessioni utilizzate, si è quindi modificato il file HOSTS di ciascun server definendo correttamente il nome macchina in relazione all’ip pubblico.

In uno scenario più strutturato è consigliabile configurare la risoluzione mediante DNS.

Nel caso che uno o entrambe gli hypervisor facciano parte di un dominio Active Directory ( anche differente tra sito primario e sito di replica) il nome FQDN del certificato dovrà essere quello del dominio AD di appartenenza

Installazione dei ROOTCA su entrambe gli HyperVisor

A questo punto, manualmente è necessario scambiare i certificati delle ROOTCA generate per ogni server e ed installarli nell’archivio TRUSTED Root CA di ogni LocalMachine, questa operazione può essere effettuata in due modi, tramite lo snap-in di gestione certificati oppure tramite il comando certutil.exe

Sul server Hyperv1srv

Certutil –f addstore root “Hvreplica2Rootca.cer”

Sul server Hvreplica2

Certutil –f addstore root “Hvreplica2Rootca.cer”

Modifica della verifica di revoca dei certificati

Essendo i certificati utilizzati di tipo Self-Signed non è possibile verificarne la revoca presso una CA
pubblica, per questo motivo è richiesta la modifica ulteriore di due chiavi di
registro, le modifiche al registro descritte di seguito devono essere
effettuate su entrambe i server.

reg add
"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\FailoverReplication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

 

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

se non vengono modificate le due chiavi di registro, Hyper-V,  nel momento in cui si utilizza il certificato, genera un errore impedendo di portare a termine le configurazioni.

Configurazione della Replica

Terminate le operazioni preliminari di configurazione è possibile attivare la Replica di Hyper-V iniziando dal server  di DR (Hvreplica2),  dalle proprietà dell’Hyper-V dovremo scegliere Replication Configuration ed attivare la funzione di Replica Server e quindi la replica
tramite HTTPS selezionando il certificato creato in precedenza

Sul server di produzione (Hyperv1), nelle proprietà della VM che intendiamo ridondare  dovremo attivare la replica specificando il nome del server di destinazione, è disponibile (attivata di default) la compressione dei dati scambiati tra i due Hypervisor.

Verifica della funzionalità della Replica

A questo punto la configurazione di tutto l’ambiente  è terminata e il sistema si occupa in modo autonomo di effettuare la replica ad intervalli cadenzati di 15 minuti.

Per verificarne lo stato è sufficiente dalla console di Hyper-V manager identificare la VM da controllare e selezionare View Replication Health, se il funzionamento regolare verrà proposto un report simile.

Una ulteriore possibilità offerta da Hyper-V server 2012 è quella di definire quanti recovery point di una VM  mantenere sul sito di replica, questa opzione se abilitata fa sì che ad ogni ora (intervallo non modificabile) venga creato, sul server di DR uno snapshot della VM replicata.

L ’adozione di questa funzionalità irrobustisce ulteriormente la possibilità di recupero dei dati a fronte di una corruzione della VM principale i cui dati corrotti vengano essi stessi replicati.

L’unico svantaggio nell’utilizzo di questa funzione è l’aumento dell’occupazione disco sul server di destinazione.

La possibilità di controllo dello stato di funzionamento vista in precedenza, da sola non è sufficiente per essere certi che il sistema  funzioni, per poter verificare che effettivamente la VM replicata sia operativa è previsto un Test Failover che previo spegnimento della VM principale attiva la VM replicata sul sito secondario, al termine del  tempo dedicato al test di Failover, i dati eventualmente modificati sulla VM del sito secondario vengono replicati sulla VM principale. Naturalmente per poter utilizzare la macchina replicata è necessario che le configurazioni di rete siano coerenti  e rendano raggiungibili entrambe i siti.

Conclusioni

La configurazione descritta in questo documento, pur essendo nata come “laboratorio” è stata realizzata su connessioni internet non particolarmente veloci, in particolare quello che è stato definito come sito principale era connesso tramite una rete a WiFi con banda a 3Mb, la replica è rimasta attiva per circa 35 giorni senza mai subire interruzioni o necessità di interventi manuali.

Riferimenti

http://technet.microsoft.com/en-us/library/jj134153.aspx

Per testare questa e molte altre funzionalità, scarica la versione gratuita di Windows Server 2012 seguendo le istruzioni che trovi al link!

Comments

• Anonymous
  November 05, 2015
  questo e' errato :Certutil –f addstore root “Hvreplica2Rootca.cer”
  questo e' corretto: Certutil –f -addstore root “Hvreplica2Rootca.cer”
• Anonymous
  December 08, 2015
  Tutto cio postato funziona anche in caso di reverse replication dopo un fileover o è necessario fare altre operazioni?
  grazie in anticipo.