Windows Server 2012 Hyper-V Replica - Overview

Article
05/03/2013

Ciao a tutti, oggi introduciamo una delle numerose novità di Windows Server 2012: Hyper-V Replica.

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

Ermanno Goletto

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

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

Windows Server 2012 ha introdotto moltissime novità in tutti gli ambiti e in particolare per quanto riguarda la virtualizzazione, migliorando ed estendendo le funzionalità di Hyper-V. Una di queste nuove funzionalità è Hyper-V Replica che consente, come dice il suo nome, di replicare le macchine virtuali tra due server di virtualizzazione diversi.

Descrizione della funzionalità Hyper-V Replica

Hyper-V Replica permette la replica asincrona delle macchine virtuali (VM) tra due server di virtualizzazione (host) senza l’utilizzo di archiviazione condivisa (SAN o NAS SMB 3.0) o di hardware particolare. E’ possibile replicare qualunque VM che possa essere eseguita in Hyper-V e può essere eseguita su qualunque rete basata su IP con la possibilità di crittografare i dati replicati.

Gli host tra cui può avvenire la replica possono essere:

· server autonomi, in cluster di failover, in una combinazione di entrambi

· collocati sulla stessa rete rete LAN o collegati tramite una rete WAN

· nello stesso dominio, in domini diversi, in foreste diverse, in workgroup o in qualunque di queste combinazioni

Di fatto l’unico prerequisito è che i server tra cui avviene la replica abbiano come sistema operativo Windows Server 2012 con il ruolo Hyper-V installato o Hyper-V Server 2012.

Viene definito sito Primario la posizione in cui opera l’host di virtualizzazione su cui viene eseguita la o le VM da replicare. Il sito di Replica indica invece la posizione dell’host di virtualizzazione che riceve i dati replicati.

Funzionamento

Dopo avere configurato e abilitato la replica tra l’host nel sito Primario e quello nel sito di Replica occorre inviare una copia iniziale delle VM replicate, questa operazione è denominata Replica inziale. L’invio della copia inziale può essere eseguito tramite rete oppure riversando i dati di replica su un dispositivo di archiviazione fisico che verrà poi trasportato nel sito di Replica.

Durante l’esecuzione della replica le VM vengono trasmesse periodicamente dall’host nel sito Primario verso l’host nel sito di Replica. La frequenza di trasmissione delle VM varia in base al tempo necessario per completare un ciclo di replica, quindi dipende da vari fattori e in particolare dalla velocità effettiva della rete. In generale si può assumere che approssimativamente ogni 5-15 minuti venga eseguito un ciclo di replica.

E’ possibile eseguire in qualunque momento un failover pianificato ovvero spostare l’attività di una VM dall’host nel sito Primario sull’host nel sito di Replica. Durate un failover pianificato le modifiche non replicate della VM vengono copiate nella VM di replica e la VM primaria viene arrestata per evitare perdite di dati. Terminato il failover pianificato la VM diventa operativa e viene configurata la replica inversa per inviare le modifiche verso la VM primaria.

Nel caso in cui il server Primario risulti non più disponibile a causa di un guasto hardware o a causa di un disastro naturale sul sito Primario è possibile attivare manualmente le VM di replica eseguendo un failover non pianificato. Ovviamente in questa circostanza potrebbero verificarsi perdite di dati a causa dell’impossibilità di copiare sulla VM di replica le modifiche intercorse dopo l’ultimo ciclo di replica.

Una volta configurata e attivata la Replica di Hyper-V è possibile eseguire un Test Failover, questa attività permette agli amministratori di provare l’esecuzione della VM replicata sul server di Replica senza interrompere l’esecuzione della VM sul server Primario. Per evitare problemi di coesistenza la VM Replica viene disconnessa dalla rete. Se si intende testare anche la connessione di rete della VM di replica è possibile creare una rete di test separata a cui connettere la VM di test. La VM di test è riconoscibile dal fatto che il suo nome termina con il suffisso Test.

Quando si termina il test mediante l’operazione Stop Test Failover la VM di test viene eliminata a meno che il test non sia stato eseguito su di un Replica Cluster, in questo caso occorre eliminare manualmente la VM di test.

Per il restore di VM a seguito di un Failover Hyper-V utilizza i Recovery Points che contengono uno snapshot della VM replicata. E’ possibile mantenere solo l’ultimo recovery point o memorizzare più Recovery points, nel secondo caso occorrerà la disponibilità di una quantità di spazio superiore sul server di Replica. I Recovery points sono creati ogni ora, ma il server di Replica riceve le modifiche intercorse sulla VM eseguita sul server Primario più frequentemente in modo che i server rimangano sincronizzati

E’ anche possibile eseguire snapshot che siano consistenti a livello applicativo (Application-consistent replicas) a intervalli specifici utilizzando Volume Shadow Copy Service (VSS), ovviamente affinché vi sia consistenza applicativa le applicazioni e i servizi in esecuzione nella VM replicata devono essere VSS aware come ad esempio SQL Server, Exchange, SharePoint, AD, DHCP, BITS, WINS (a riguardo si veda The Wonder of Volume Shadow Copy and Hyper-V). Nell’impostazione della frequenza con cui vengono eseguiti gli snapshots si tenga conto che la creazione di quest’ultimi ha un impatto a livello di performance nei confronti delle applicazioni e dei servizi erogati dalla VM Replica.

Architettura dei componenti di Hyper-V Replica

L’architettura della funzionalità Hyper-V Replica può essere suddivisa nei seguenti componenti principali:

· Hyper-V Replica Management Interface

· Hyper-V Replica PowerShell Objects

· Hyper-V Replica WMI API

· Hyper-V Replica Replication Manager (RM)

· Hyper-V Replica Replication Tracker (RT)

· Hyper-V Replica Networking

· Hyper-V Replica Broker Manager

Il componente Hyper-V Replica Replication Manager (RM) interagisce con Hyper-V per implementare il meccanismo di change tracking a livello della VM. Questo componente si occupa infatti di monitorare le modifiche che avvengono sui metadati che definiscono la VM di replica:

· Metadata di configurazione (Standard-replica, Application-consistent replicas, crittografia, compressione e mapping delle storage tra sorgente e destinazione)

· Informazioni sul path dei VHD replicati

· Stato della replica (ultimo Recovery Point di tipo Application-consistent o Standard replica eseguito con successo)

L’Hyper-V Replica Replication Tracker (RT) è il componente che si occupa di catturare lo stato delle VM sul server Primario e di replicare gli aggiornamenti sui VHD relativi alle VM sul server di Replica. Per impostazione predefinita la Delta Replication viene eseguita ogni 5 minuti (questo non è configurabile) e le modifiche vengono memorizzate su un file denominato Hyper-V Replication Log con estensione .hrl che si trova nella stessa directory dei VHD. Ogni VHD della VM replicata ha un file di tracking log associato che viene inviato al server di Replica, per ridurre il traffico di replica è possibile inviare il file in formato compresso. Durante l’invio del file al Server di Replica le modifiche sulla VM nel server Primario vengono mantenute in un altro file di log sempre nella stessa directory.

Il numero di Recovery Points che si è scelto di mantenere determina il numero di log di replica mantenuti sul server di Replica. Il componente Hyper-V Replica Replication Manager fornisce lo stato della VM all’Hyper-V Replica Replication Tracker che provvede a memorizzarlo nel file di configurazione della VM di replica per garantire la consistenza degli stati delle VM primaria e di replica.

Come detto precedentemente le modifiche delle VM sono replicate ogni 5 minuti inviando i replication logs se dal Server di Replica è stato ricevuto un acknowledge relativo all’invio precedente. Scendendo nel dettaglio implementativo è possibile identificare tre casi specifici per la gestione dei tracking logs.

Caso 1: mantenimento del solo dell’ultimo Recovery Point

In questo caso i file di logs correnti sono inviati ogni 5 minuti e vengono generati dei nuovi logs, il Server di Replica esegue il merge dei logs ricevuti nei VHD delle VM.

Caso 2: mantenimento di multipli Recovery Points in modalità Standard replica

Anche in questo caso i file di logs correnti sono inviati ogni 5 minuti e vengono generati dei nuovi logs, ma il server di Replica crea un Recovery snapshot ogni ora utilizzando i file di logs ricevuti. Il numero dei Recovery snapshots mantenuti dipende dalle impostazioni configurate, una volta raggiunto il limite impostato viene eseguito il merge del Recovery snapshot più vecchio nei VHD delle VM.

Caso 3: mantenimento di multipli Recovery Points in modalità Standard replica con uso di Recoveri Points Application-Consistent mediante l’uso di Volume Shadow Copy Service

Questo caso è simile al caso 2 ovvero i file di logs correnti sono inviati ogni 5 minuti e vengono generati dei nuovi logs e il server di Replica crea un Recovery snapshot ogni ora utilizzando i file di logs ricevuti. Oltre a questo vengono create e inviate VSS snapshot in base all’intervallo configurato. Quanto sul server di Replica arriva una copia Application consistent l’intero Replication snapshot diventa Application consistent.

Hyper-V Replica Broker

E’ possibile abilitare la funzionalità di Replica Hyper-V anche quando il server Primario e/o di Replica fanno parte di un Hyper-V Failover Cluster. Per supportare questa configurazione è stato introdotto un nuovo ruolo nel Failover Clustering denominato Hyper-V Replica Broker.

Nel caso in cui il server di Replica sia in cluster l’Hyper-V Replica Broker si occupa di fornire un Replica server name, ovvero un connection point anche detto Client Access Point (CAP) per stabilire la posizione iniziale della VM quando il Replica Cluster viene contattato dal server Primario.

Dopo la replica iniziale della VM sul Replica Cluster l’Hyper-V Replica Broker si occupa di fornire la mappatura VM - Replica Server (cluster node) al server Primario in modo che la replica possa continuare sul nodo in cluster corretto supportando le funzionalità di mobilità tipiche del cluster (Live\Quick Migration o Storage Migration).

Dal momento che l’Hyper-V Replica Broker si frappone tra i server Primario e il Replica cluster viene utilizzato per configurare configurare le impostazioni di replica su tutti i nodi del Replica cluster.

Per ulteriori informazioni si vedano anche:

· Prepare to Deploy Hyper-V Replica - 1.4. Configure Hyper-V Replica Broker

Why adding Hyper-V Replica Connection Broker Fails (in Failover Cluster Manager)

Architettura delle comunicazioni di Hyper-V Replica

E’ possibile scegliere tra due tipi di autenticazione tramite cui verrà autorizzato il traffico in ingresso relativo alla replica: la Windows Integrated Authentication (Kerberos) e la mutua autenticazione mediante certificato digitale.

Per impostazione predefinita viene proposto l’utilizzo della Windows Integrated Authentication (Kerberos) tramite cui le comunicazioni avvengono su porta HTTP (per default viene utilizzata la porta TCP 80). La funzionalità di crittografia di Kerberos non viene utilizzata, quindi la comunicazione tra l’host nel sito Primario e l’host nel sito di Replica non viene crittografata. Questo metodo utilizza la Windows Security Support Provider Interface (SSPI) per generare il messaggio scambiato tra i due server, mentre l’autenticazione Kerberos per i servizi vengono utilizzati i Service Principal Names (SPNs), infatti il servizio Hyper-V Replica Network Services crea e registra un SPN (Service Principal Name) con classe 'Hyper-V Replica Service' . Ovviamente l’autenticazione basata su Kerberos è utilizzabile solo se il server Primario e il server di Replica sono membri dello stesso dominio o di domini in trust.

Nel caso in cui sia necessaria la crittografia dei dati di replica o quando il server Primario e il server di Replica non sono membri dello stesso dominio o di domini in trust occorre utilizzare la Certificate-based Authentication. Tramite questo metodo le comunicazioni avvengono su porta HTTPS (per default viene utilizzata la porta TCP 443), viene infatti utilizzato il layer SSL per la cifratura dei pacchetti utilizzando un certificato digitale X509v3 che verrà anche utilizzato per la mutua autenticazione tra i due server. Per la generazione di un certificato digitale autofirmato è possibile utilizzare Makecert.exe.

Di seguito le inbound firewall rule di Windows Server 2012 che devono essere abilitate sul server di Replica per consentire la comunicazione:

Windows Integrated Authentication (Kerberos)	Certificate-based Authentication
Hyper-V Replica HTTP Listener (TCP-In)	Hyper-V Replica HTTPS Listener (TCP-In)

Se si prevede la possibilità di eseguire un Failover abilitare le inbound firewall rule anche sul server Primario. Nel caso in cui il server di Replica sia in cluster occorre eseguire su ciascun nodo del cluster i seguenti comandi:

#Kerberos authentication
get-clusternode | ForEach-Object {Invoke-command -computername $_.name -scriptblock {Enable-Netfirewallrule -displayname "Hyper-V Replica HTTP Listener (TCP-In)"}}

#Certificate-based authentication
get-clusternode | ForEach-Object {Invoke-command -computername $_.name -scriptblock {Enable-Netfirewallrule -displayname "Hyper-V Replica HTTPS Listener (TCP-In)"}}

Gli Hyper-V Replica Network Services supportano le seguenti funzionalità:

• Autorizzazione del server Primario sul server di Replica

• Mutua autenticazione usando certificati (HTTPS) o tramite Kerberos (HTTP)

• Cifratura degli stream di dati nel caso in cui venga usata l’autenticazione basata sui certificati

• Compressione degli stream di dati

• Network throttling parziale mediante l’utilizzo di policy Quality of Service (QOS)

• Configurazione delle porte TCP utilizzate per I traffico di Replica

Il componente Hyper-V Replica Network Services sul server di Replica invia il pacchetto di controllo all’Hyper-V Replica Replication Engine (RE) sul server Primario che deve rispondere entro un timeout di 120 secondi. I pacchetti di controllo non vengono compressi, inoltre il canale dei messaggi di controllo è sincrono e quindi non è implementata alcuna logica di controllo nel caso la connessione fallisca.

Stabilita la comunicazione col server di Replica mediante lo scambio dei pacchetti controllo il componente Hyper-V Replica Replication Engine inizia il trasferimento dei dati dal server Primario verso il server di Replica delle VM configurate basandosi sul virtual machine ID (GUID).

L’Hyper-V Replica Network Services layer determina quali file devono essere inviati inviando un pacchetto di controllo al server di Replica che contiene la lista dei file inviati dal server Primario a cui il server di Replica risponde inviando la lista dei file ricevuti.

I file di dati scambiati possono essere di due tipi Initial Replication (IR) o Delta Replication (DR) , questi vendono suddivisi in chunk da 2 MB, compressi se richiesto nella configurazione della Replica e cifrati se viene utilizzata la mutua autenticazione basata su certificati digitali. Quando il chunk di dati è ricevuto dal server di Replica viene scompattato, decriptato e memorizzato nel path assegnato alle VM di replica quindi viene notificato al server Primario che il trasferimento è avvenuto con successo.

Nel caso in cui la VM venisse migrata mentre è in coro un trasferimento dati l’Hyper-V Replica Network Service interromperà la connessione che verrà nuovamente inizializzata in modo automatico quando la migrazione sarà completata. Una volta che la connessione sarà di nuovo disponibile la replica riprenderà confrontando nuovamente i file disponibili sul server di Replica con quelli inviati dal server Primario. Lo stesso comportamento verrà adottato anche nel caso si verifichi una storage migration.

Il canale di trasmissione dati è persistente al contrario del canale di trasmissione di controllo in cui le comunicazioni sono brevi. Per consentire la persistenza del canale dati in ambienti in cui esistono proxies viene utilizzata un processo di echo. Infatti molti proxies abbattono le connessioni inattive per più di 120 secondi, quindi per rendere persistente la connessione vengono inviati dei pacchetti di echo ogni 90 secondi. Il canale di trasmissione dati viene abbattuto nel caso in cui la Replica sia messa in pausa, rimossa o se la VM viene eliminata.

Oltre al timeout di 120 secondi l’ Hyper-V Replica Network Service adotta la seguente logica di ritrasmissione per quanto riguarda la trasmissione dei file Delta Replication (DR) in base al tipo di errore verificato.

Nel caso in cui la Replica sia cancellata o messa in pausa sul server Primario non vengono applicate logiche di ritrasmissione.

Considerazioni sulla gestione delle connessioni di rete delle macchine virtuali in scenari di replica

E’ possibile che il server di Replica o il Replica cluster si trovi in un sito di Disaster Recovery connesso tramite WAN e utilizzi uno schema d’indirizzamento di rete completamente differente dal sito principale, si pensi ad esempio agli scenari in cui la replica avviene verso server di provider di servizi di backup in cloud.

In queste situazioni se la VM in seguito ad un Failover diventa attiva sul sito di Disaster Recovery occorre che le venga fornita una nuova configurazione IP perché possa comunicare col sito Primario.

Per risolvere questo tipo di problematiche Hyper-V Replica fornisce la possibilità di modificare le impostazioni di rete IPv4 e IPv6 delle VM sul server di Replica tramite le Failover TCP/IP setting.

L’indirizzamento configurato diventerà attivo quando verrà eseguito un Failover o un Failover pianificato, le impostazioni IP vengono applicate solo alle schede di rete sintetiche e non alle schede di rete Legacy dal momento che occorre interagire con il sistema operativo della VM. Dal momento che per impostare le configurazioni IP occorre Hyper-V dialoghi con il sistema operativo è necessario che la VM abbia i seguenti prerequisiti:

· Il sistema operative deve essere uno dei seguenti:

o Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 o Windows Server 2003 SP2

o Windows 8, Windows 7, Vista SP2 o Windows XP SP2

· Devono essere installati gli Integration Services di Windows Server 2012 (versione 6.2.9200.16384 per Windows Server 2012 RTM e 6.2.9200.16433 per Windows Server 2012 con Cumulative update November 2012 KB 2770917)

Le impostazioni IP vengono salvate nel file xml di configurazione della VM nella sezione ‘failover replication’ .

Compressione dei dati di replica e risincronizzazione

Come detto precedente è possibile sceglie di comprimere i dati di replica inoltre è disponibile anche la funzionalità di risincronizzazione che può essere eseguita sulla VM nel server Primario.

La risincronizzazione è utilizzabile quando la Delta Replication (DR) fallisce, ma la Full Initial Replication (IR) è troppo costosa in termini di banda e\o di tempo. In questo caso la risincronizzazione minimizza la quantità di dati inviati eseguendo dei checksums sui VHD della VM Primaria e della VM di Replica con l’obbiettivo di determinare solo i delta necessari. In ogni caso la risincronizzazione non costituisce una sostituzione della DR, infatti al termine della risincronizzazione la DR riprende il suo normale funzionamento.

I tipici scenari in cui la DR può fallire sono i seguenti:

1. Un problema su Change tracking sul server Primario che può essersi generato per I seguenti motivi:

a. Mancanza di alimentazione, problemi hardware o a livello di sistema operativo

b. Arresto anomalo del servizio cluster e spostamento della VM su un nodo diverso, nel caso in cui il server Primario sia in cluster

2. Un problema legato alla replica che può essersi generato per I seguenti motivi:

a. Impossibilità di convertire il tracking log file di replica nel VHD sul Replica Server

b. Impossibilità di collegare un VHD sul Replica Server con un Parent VHD

c. Tracking log file mancante sul server di Replica o sul server Primario

3. La VM su server Primario o di Replica è stata ripristinata da un backup e la catena dei VHD si è interrotta, in questo caso è necessaria una risincronizzazione per consentire alla Delta Replication di potere tornare in funzione

4. Esecuzione di un Reverse Replication dopo l’esecuzione di un Failover, in questo se la VM esiste ancora sul server Primario verrà eseguita una risincronizzazione.

La risincronizzazione è ottimizzata per VHD con dimensione fino 500 GB, inoltre il workflow di risincronizzazione è progettato per operare con il servizio Hyper-V Replica Networking per poter usufruire delle funzionalità di Autorizzazione, Compressione, meccanismi di Chunking\ Retry e gestione degli errori. Inoltre la risincronizzazione è progettata anche per operare in situazioni di migrazione, modifica dello stato delle VM e notifica eventi di modifiche all’albero dei VHD, alla VM o allo storage della VM. La risincronizzazione può essere ripresa nel caso interruzione dovuta ad esempio a problemi di rete, blocco del servizio Virtual Machine Manager (VMMS) etc...

La risincronizzazione utilizza una algoritmo di Fixed Block Chunking dove i file di Source (server Primario ) e di Seed (server di Replica) vengono suddivisi in chunks da 2 MB, per ogni chunk viene generata firma CRC64 che verrà utilizzata per confronto al fine di derminare quali chunk della Source devono essere applicati al Seed. Si noti che lo stesso procedimento è utilizzato Microsoft Data Protection Manager (DPM) durante i backup.

Nel caso in cui il processo di risincronizzazione duri più di 6 ore utilizzando al 50% un collegamento a 1.5 Mbs verrà richiesto di eseguire una Full Initial Replication.

Per determinare se risulta conveniente attivare la compressione è possibile utilizzare il Best Practice Analyzer (BPA) , la funzionalità di Replica Hyper-V è stata integrata Best Practice Analyzer (BPA) e una delle verifiche è appunto quella di controllare su quali VM la Replica utilizza più banda del necessario.

Per aumentare le performance della funzionalità Hyper-V Replica è anche possibile utilizzare degli ottimizzatori di WAN. In questo documento Hyper-V Replica and Riverbed sono disponibili i risultati di un esperimento dal Microsoft Engineering Excellence Center (EEC) lab sull’utilizzo di appliance ottimizzatori di WAN della Riverbed Steelhead in combinazione con Hyper-V Replica. In sintesi i risultati riportano una riduzione del tempo impiegato per la replica iniziale e successive sincronizzazione che può variare dal 98% al 35% a seconda dello specifico scenario, ma in linea generale si può ipotizzare una riduzione del 70%.

Conclusioni

Hyper-V Replica può essere impiegata in scenari come il disaster recovery locale o geografico o l’implementazione di ambienti di laboratorio per test. Inoltre i vantaggi offerti dalla Hyper-V Replica non richiedono licenze aggiuntive dal momento che come host di virtualizzazione è possibile utilizzare anche Hyper-V Server 2012.

Un altro scenario in cui tale funzionalità può trovare impiego è quella degli ambiente X-premise in cui un’hoster offre servizi di Disaster Recovery a terzi, in questo tipo di scenario viene reso disponibile un Replication Authorization Tag che evita che le VM replicate siano accedute da altri clienti dell’hoster dal momento che il Replica Cluster potrebbe essere utilizzato da più clienti.