Azure Site Recovery: Overview ed Implementazione

Microsoft Azure

Avere un sito di Disaster Recovery non è sempre una cosa possibile, soprattutto per le aziende piccole che sicuramente non hanno i budget dedicati per il reparto IT. Tuttavia anche le piccole aziende ormai non possono più permettersi tempi di downtime, perchè la perdita di un servizio critico, anche per poche ore, è una perdita di produttività.

 

Se alcuni servizi primari, come la posta elettronica, possono essere spostati sul Cloud non sempre questo è applicabile quando si parla di intere Virtual Machine, che magari fanno girare applicativi gestionali o che non possono essere gestite in altro modo.

 

Microsoft Azure Site Recovery è un servizio introdotto diversi mesi fa, che permette di orchestrare la replica di una macchina virtuale dal proprio datacenter verso un altro, come mostra la figura 1. Mentre la prima versione era nata per replicare le VM solo verso un sito secondario fisico, la nuova versione permette di replicare le VM all’interno di Microsoft Azure.

 

2014_11_13_ASR_01
Figura 1 – Azure Site Recovery

 

Il vantaggio di replicare su Azure è dato dall’enorme riduzione di costi, relativo alla possibilità di non dover avere un sito di disastro bensì di utilizzare un’infrastruttura consolidata come Azure.

 

ASR sì ma prima di procedere è importante farsi queste domande prima di iniziare:

 

Quali Servizi Proteggo?

Avere una soluzione di Business Continuity ha sicuramente un costo, che si bilancia con quanto verrebbe a costare il fermo del servizio che vogliamo proteggere. Decidere quali servizi mettere in DR è legato dalla criticità sulla disponibilità che deve avere rispetto agli utenti. Altro aspetto importante è valutare se questi servizi hanno delle dipendenze, cosa che ci porta a dover mettere sotto protezione altre componenti, con un relativo aumento dei costi.

 

Come Ripristino i Servizi?

La procedura di restore di un servizio è fondamentale in un processo di DR, perchè a volte è necessario sviluppare soluzione di automazione che fare in modo che ci sia il minor impatto possibile sulla produttività; inoltre questo tipo di processo deve essere studiato e testato in modo completo.

 

Come Collegare il DR alla mia Infrastruttura?

Una volta ripristinata la VM sul sito di disastro devo fare in modo che il workload sia raggiungibile dai miei utenti, esterni o interni. Mentre nel primo caso potrebbe essere sufficiente la connettività fornita dal mio Cloud Provider, nel secondo diventa necessario valutare correttamente la creazione di un tunnel, come la VPN, che mette in collegamento il sito DR con il mio Datacenter.

 

A livello architetturale, ASR attualmente si basa sui seguenti elementi:

 

  • System Center Virtual Machine Manager 2012 R2
  • Hyper-V 2012 R2 Replica
  • Azure IaaS
  • Azure Virtual Network

 

Azure Site Recovery è dunque un terzo attore che orchestra l’operazione di replica, sfruttando il servizio di Hyper-V Replica, per mezzo di Virtual Machine Manager, che passa le relative configurazioni della VM. L’Infrastructure as a Service di Azure è la piattaforma che consente di poter posizionare le nostre VM sul Cloud, mentre le Virtual Network consentono di mettere in comunicazione la VM con il mondo esterno/interno.

 

I pre-requisiti per poter utilizzare questa tecnologia sono i seguenti per quanto riguarda le VM:

 

  • OS Supportati da Azure
  • Windows Server 2008 R2 o superiore
  • Linux: CentOS, openSUSE, SUSE, Ubuntu
  • Solo 64 bit
  • Solo Generation 1
  • Disco OS 127 GB Max

 

Vista un po’ la teoria, passiamo alla pratica ovvero alla creazione basilare di una Vault.

 

La prima operazione da fare è creare un nuovo Recovery Vault, figura 2, che in pochi secondi sarà disponibile all’interno di Azure.

 

2014_11_13_ASR_02
Figura 2 – Creazione Vault

 

Il passo successivo sarà la creazione di uno storage, figura 3, che ci servirà per posizionare le VM replicate; importante che sia attiva la Geo-Replica, altrimenti non sarà possibile selezionarla nei settings della Vault.

 

2014_11_13_ASR_03
Figura 3 – Creazione Storage

 

Conclusa la creazione della Vault e dello Storage, è tempo di installare l’agent all’interno di Virtual Machine Manager e in ogni Hyper-V che intendiamo proteggere. L’agent per VMM richiederà un file relativo alla chiave Vault che autorizzerà la comunicazione tra Azure e VMM; questo file si genera direttamente dalla Recovery Vault, figura 4.

 

2014_11_13_ASR_04
Figura 4 – Generazione File Vault

 

Per poter gestire le varie Virtual Machine è necessario che all’interno di VMM siano configurati uno o più Cloud, che racchiudono un set di risorse come host, storage, network ed altre configurazioni; senza un Cloud non sarà possibile procedere. Questi Cloud devono essere abilitati per comunicare con ASR, altrimenti non sarà possibile visualizzarli su Azure. Una volta fatto, il risultato sarà come mostra la figura 5.

 

2014_11_13_ASR_05
Figura 5 – Cloud Under Protection

 

Durante la creazione di una VM, all’interno di Virtual Machine Manager, è possibile assegnare da subito un Cloud di appartenenza, tuttavia quest’operazione è configurabile anche in un secondo momento, come mostra la figura 6.

 

2014_11_13_ASR_06
Figura 6 – Assegnazione Cloud

 

Una volta assegnata la VM al Cloud sarà possibile attivare la protezione in Azure, come mostra la figura 7.

 

2014_11_13_ASR_07
Figura 7 – Protezione VM

 

Selezionata la macchina virtuale, comincierà la replica vera e propria che richiederà diverso tempo, variabile comunque in base alla vostra connettività ed alla dimensione della VM stessa.

 

A questo punto potrete eseguire un failover-test per verificare che realmente il contenuto del vostro server sia consistente e funzionante. Per evitare conflitti è possibile non collegare nessuna scheda di rete alla VM, cosa che vi permetterà quanto meno di capire se la macchina si avvia correttamente e che i servizi al suo interno funzionino correttamente. ASR supporta le seguenti modalità:

 

  • Planned Failover – attività di DR prevista che non va ad impattare sui servizi
  • Unplanned Failover – attività di DR non prevista che causa un fermo dei servizi
  • Test Failover – attività prevista per testare il funzionamento del DR

 

La modalità di Planned Failover è un modo perfetto per migrare i propri workload verso Azure con un bassissimo impatto a livello di interruzione servizio, dato che lo spostamento viene fatto a caldo e che il failover prevede lo shutdown dal datacenter locale e la rapida riaccensione su Azure stesso.

 

Interessante anche la possibilità di creare dei Recovery Task, figura 8, che vanno ad automatizzare alcuni passaggi durante la fase di Failover o che impongono una serie di azioni preventive, come l’approvazione dell’attività da parte di un amministratore.

 

2014_11_13_ASR_08
Figura 8 – Recovery Task

 

Planned Failover

Simuliamo la necessità di dover fare una manutenzione straordinaria sul nostro host e che vogliamo utilizzare Azure Site Recovery per continuare ad offrire il servizio. Quello che bisognerà fare è selezionare la VM e cliccare su Failover -> Planned, figura 9.

 

2014_11_13_ASR_09
Figura 9 – Planned Failover

 

Verrà richiesto il verso di Failover, che sarà da VMM verso Azure, e che tipo di modalità adottare: ridurre il downtime oppure il traffico. Confermata l’opeazione inizierà il task che prevede la creazione di una macchina virtuale, in Azure, che verrà agganciata ad una Virtual Network, se precedentemente creata e collegata alle risorse del Recovery Vault.

 

A questo punto non rimane che fare un test di funzionamento: nel caso la Network preveda anche una VPN S2S, si dovrebbe notare un cambiamento di IP all’interno del proprio DNS Server.

 

Una volta concluso il test si potrà effettuare nuovamente il Failover Planned, da Azure verso VMM. I tempi di esecuzione variano a seconda della banda a disposizione, che deve essere sicuramente buona per poter replicare un’intera VM, soprattutto se vengono fatta tante modifiche, come può succedere per un gestionale con relativo DB a bordo.

 

Azure Site Recovery è sicuramente un ottimo prodotto che permette di avere un sito di recovery, senza dover fare investimenti iniziali. Benchè sia richiesta una pianificazione meticolosa, le potenzialità sono veramente imporanti. Ancora in Preview la possibilità di fare Site Recovery di una VM gestita da un sistema VMware, grazie all’acquisizione di Microsoft di InMage System, ma certamente questo dettaglio è notevole perchè fa sì che Azure sia un punto comune per piattaforme Microsoft e non.

 

Per chi volesse provare Azure Site Recovery, può farlo grazie alla Trial di 30 giorni con un bonus di 200$.

 

S