• Cloud, Guide
• 20 Ottobre 2018

Abbiamo visto nel precedente articolo Proteggere le macchine virtuali Hyper-V con Windows Admin Center e Azure Site Recovery come proteggere le VM ospitate on-premises e poterle avviare in Azure in caso di disastro.

In questo articolo ci occuperemo invece di riportare le VM on-premises in caso si sia verificato un disastro e abbiate avuto bisogno di accenderle in Cloud.

L’operazione viene chiamata tecnicamente Failback e quello che simuleremo noi sarà la perdita totale dell’host Hyper-V on-premises e la sua successiva sincronizzazione con le macchine virtuali che erano protette e che sono avviate in Azure.

Failover delle VM protette in Azure

Supponiamo che sia avvenuto un grave danno al nostro Datacenter o anche solo al nostro server on-premises (molte piccole aziende hanno un solo server Hyper-V in locale). Al momento le macchine virtuali non sono più disponibili in azienda ma poiché abbiamo provveduto a proteggerle con Azure Site Recovery possiamo adesso avviarle nel Cloud. Dal portale di Azure selezioniamo il Recovery Services Vault dentro il quale ci sono le nostre VM replicate e per ognuna della macchine dichiariamo il Failover. In questo modo le macchine verranno avviate in Azure, secondo le configurazioni che abbiamo precedentemente dato, come mostrato in figura:

Figura 1: Dichiarazione del Failover della VM

Dopo pochi minuti, la VM sarà avviata in Azure e sarà disponibile. Effettuate i test del caso per vedere se tutto funziona all’interno della macchina virtuale e se il Recovery Point che avete scelto è funzionante. Cliccate su Commit per confermare il Recovery Point scelto. Da questo momento in poi non sarà più possibile scegliere un altro Recovery Point e le modifiche alla macchina non potranno essere più annullate.

Figura 2: Commit della VM e conferma delle modifiche

Aggiunta di un nuovo server Hyper-V all’infrastruttura di Azure Site Recovery

Supponiamo ora che, a distanza di qualche giorno dal disastro, abbiate installato uno nuovo server Hyper-V on-premises e che lo vogliate utilizzare per riportare in casa le vostre macchine virtuali protette. Ricordatevi di creare sull’host Hyper-V gli stessi virtual switch (con lo stesso nome) che aveva il vecchio host.

Per poter aggiungere il nuovo server all’infrastruttura di Disaster Recovery in Azure è sufficiente collegarsi al Recovery Services Vault, selezionare Site Recovery Infrastructure e dal nodo Hyper-V Servers aggiungere un nuovo server, seguendo le indicazioni riportate in figura:

Figura 3: Aggiunta di un nuovo host Hyper-V all’infrastruttura di disaster recovery di Azure

Scaricate l’installer per il Microsoft Azure Site Recovery Provider e la chiave di registrazione al Vault che utilizzerete per registrare l’host all’interno dell’Hyper-V Site. Ricordatevi di selezionare l’Hyper-V Site di Azure a cui volete aggiungere il nuovo host. Installate il Provider nell’host Hyper-V seguendo le istruzioni riportate in figura:

Figura 4: Installazione dell’Azure Recovery Services Agent

Figura 5: Installazione dell’Azure Recovery Services Agent completata

Figura 6: Registrazione dell’Azure Recovery Services Agent con il Vault scelto

Figura 7: Registrazione dell’Azure Recovery Services Agent completata

Nel portale di Azure il nuovo host Hyper-V sarà visibile nell’elenco dei server collegati alla Site Recovery Infrastructure

Figura 8: L’host Hyper-V è collegato alla Site Recovery Infrastructure e all’Hyper-V Site

Failback delle VM da Azure verso On-premises

Una volta che avete ripristinato la vostra infrastruttura on-premises sarà quindi possibile effettuare il Failback delle VM e riportarle nel sito primario (on-premises). Dal portale di Azure non esiste il pulsante Failback ma dovrete usare il pulsate Planned Failover. Quando si avvia un’operazione di failover, il pannello segnala la direzione in cui le macchine virtuali devono essere spostate. Se lo spostamento avviene da Azure al sistema locale, si tratta di un failback.

Cliccate quindi su Planned Failover e scegliete in che modo volete sincronizzare i dati con l’host Hyper-V on-premises. In Data Sync è consigliabile selezionare l’opzione Minimize Downtime. Questa opzione riduce al minimo i tempi di inattività delle macchine virtuali avviate in Azure.

Vengono effettuate le seguenti operazioni:

• Fase 1: Viene creato uno snapshot della macchina virtuale in Azure e viene copiato nell’host Hyper-V in locale (on-premises). La macchina continua l’esecuzione in Azure.
• Fase 2: Viene arrestata la macchina virtuale in Azure in modo che non vengano apportate nuove modifiche. Il set finale di modifiche viene trasferito al server locale (on-premises) e viene avviata la macchina virtuale locale.

Il failback è un’attività pianificata in cui si decide di accettare un breve tempo di inattività in modo che i carichi di lavoro possano iniziare di nuovo a essere eseguiti in locale.

Scegliete l’host Hyper-V dove volete che venga ripristinata la VM e spuntate la casella se volete che venga creata automaticamente la macchina on-premises nel caso non ci sia. Probabilmente con un backup probabilmente avrete già provveduto a ripristinare la VM e in questo caso verranno replicate solo le modifiche che sono state effettuate mentre la VM è stata in esecuzione in Azure.

Figura 9: Failback della VM dal portale di Azure

Figura 10: scelta della modalità di sincronizzazione dei dati

Figura 11: Operazioni effettuate dal Planned Failover durante il job di Failback

Nota: Se si annulla il processo di failback durante la fase di sincronizzazione dei dati, la macchina virtuale locale ne risulterà corrotta. Questo avviene perché la sincronizzazione dei dati copia i dati più recenti dai dischi della macchina virtuale di Azure sui dischi di dati locali e, fino al completamento della sincronizzazione, il disco dati potrebbe non trovarsi in uno stato coerente. La macchina virtuale locale potrebbe non avviarsi dopo aver annullato la sincronizzazione dei dati. Riattivare il failover per completare la sincronizzazione dei dati.

Il tempo richiesto per completare la sincronizzazione dei dati e avviare la macchina virtuale dipende da diversi fattori. La sincronizzazione dei dati crea uno snapshot dei dischi della macchina virtuale, avvia il controllo blocco per blocco e calcola il checksum. Il checksum calcolato viene inviato in locale per confrontarlo con il checksum locale dello stesso blocco. In caso di corrispondenza tra i checksum, il blocco di dati non viene trasferito. Se non c’è corrispondenza, il blocco di dati viene trasferito in locale. Il tempo di trasferimento dipende dalla larghezza di banda disponibile.

La velocità del checksum è di pochi GB al minuto e per rendere più veloce il download dei dati è possibile configurare l’agente di Microsoft Azure Site Recovery affinché usi più thread per eseguire i download in parallelo. Consultare il documento Modalità di gestione per l’utilizzo della larghezza di banda di Azure Site Recovery su come modificare i thread di download nell’agente ed aumentare la velocità di trasferimento da Azure verso l’on-premises.

Terminata la Fase 1, cioè la replica della VM da Azure verso il sito locale (on-premises), è necessario avviare manualmente la Fase 2 utilizzando il pulsante Complete Failover. Come già detto, la Fase 2 consiste nello spegnimento della VM in Azure, nella copia degli ultimi dati della VM in locale e l’avvio della VM in locale sull’host Hyper-V.

Figura 12: Avvio della Fase 2. Completamento del Failover verso l’on-premises

Figura 13: Spegnimento della VM in Azure

Figura 14: Completamento del trasferimento dei dati verso l’on-premises

Cliccate sul pulsante Commit per confermare che da questo momento in poi le modifiche alla macchina non potranno essere più annullate. Il Commit
cancella la macchina virtuale presente in Azure e prepara la VM ad essere protetta nuovamente.

Figura 15: Commit dell’operazione di Failover

La macchina virtuale è stata avviata all’interno dell’host Hyper-V locale

Figura 16: La VM è in esecuzione nell’host Hyper-V on-premises

Riprotezione della VM verso Azure

Per riproteggere nuovamente la VM dall’on-premises verso Azure è sufficiente cliccare sul pulsante Reverse Replicate. Questa operazione replicherà solo le modifiche apportate dal momento in cui la VM è stata disattivata in Azure e quindi vengono inviate solo i dati differenziali.

Figura 17: riprotezione della VM da on-premises verso Azure

Conclusioni

L’operazione di Failback e di trasferimento delle nostre macchine virtuali da Azure verso on-premises è molto semplice e viene effettuata con pochi clic, esattamente come abbiamo effettuato la protezione delle VM con Azure Site Recovery. Questo tipo di funzionalità può essere anche utilizzato per trasferire le macchine virtuali dal Cloud verso l’on-premises.