La soluzione Azure Site Recovery (ASR) consente di proteggere sistemi fisici oppure virtuali, ospitati sia in ambiente Hyper-V che VMware, automatizzando il processo di replica verso un datacenter secondario oppure verso Microsoft Azure. Con un’unica soluzione è possibile implementare piani di Disaster Recovery per ambienti eterogenei orchestrando in modo funzionale il processo di replica e le azioni necessarie per il corretto ripristino. Grazie a questa soluzione il proprio piano di DR sarà facilmente usufruibile in qualsiasi evenienza, anche la più remota, per garantire la business continuity. Recentemente la soluzione è stata ampliata prevedendo anche la possibilità di implementare una strategia di disaster recovery per macchine virtuali in Azure, consentendo di attivare la replica tra differenti region.
In questo articolo verrà mostrato come ASR può essere utilizzato per replicare macchine virtuali in ambiente VMware verso Azure (scenario 6 della figura seguente), esaminando le caratteristiche e la procedura tecnica da seguire. Nell’immagine seguente sono riportati tutti gli scenari attualmente contemplati dalla soluzione ASR:
Figura 1 – Scenari contemplati da Azure Site Recovery
Lo scenario di replica di macchine virtuali VMware verso Azure richiede la presenza della seguente architettura:
Figura 2 – Architettura nello scenario di replica di sistemi VMware verso Azure
Per poter attivare il processo di replica è necessaria la presenza di almeno un server on-premises su cui vengono installati i seguenti ruoli:
- Configuration Server: coordina le comunicazioni tra il mondo on-premises ed Azure, e gestisce la replica dei dati.
- Process Server: questo ruolo di default viene installato insieme al Configuration Server, ma possono essere previsti più sistemi Process Server in base al volume di dati da replicare. Agisce come replication gateway, quindi riceve i dati di replica, ne effettua un’ottimizzazione tramite meccanismi di cache e compressione, provvede all’encryption e li invia verso lo storage in ambiente Azure. Questo ruolo ha inoltre il compito di effettuare il discovery delle macchine virtuali sui sistemi VMware.
- Master target server: anche questo ruolo viene installato di default insieme al Configuration Server, ma per deployment con un numero elevato di sistemi possono essere previsti più server con questo ruolo. Entra in azione durante il processo di failback delle risorse da Azure gestendo i dati di replica.
Su tutte le macchine virtuali sottoposte al processo di replica è necessaria la presenza del Mobility Service, che viene installato dal Process Server. Si tratta di un agente specifico che si occupa di replicare i dati presenti nella macchina virtuale.
In seguito viene descritto il processo da seguire per effettuare il deployment dei componenti on-premises e nel mondo Azure necessari per attivare la replica delle macchine virtuali VMware verso la cloud pubblica di Microsoft.
Il componente core necessario lato Azure è il Recovery Service Vault all’interno del quale, nella sezione Site Recovery, è possibile avviare il processo di configurazione pilotato per lo scenario di protezione prescelto.
Figura 3 – Scelta dello scenario di replica di macchine virtuali VMware all’interno del Recovery Service Vault
Successivamente è necessario procedere all’installazione sulla macchina on-premises del Configuration Server seguendo gli step indicati:
Figura 4 – Step da seguire per aggiungere il Configuration Server
In questa sezione del portale Azure è possibile scaricare il Microsoft Azure Site Recovery Unified Setup e la chiave necessaria per la registrazione del server al vault. Prima di avviare il setup accertarsi che la macchina su cui si intende installare il ruolo di Configuration Server sia in grado di accedere agli URL pubblici del servizio Azure e che durante il setup sia consentito il traffico web su porta 80 necessario per effettuare il download del componente MySQL utilizzato dalla soluzione.
Avviando il setup vengono richieste le seguenti informazioni:
Figura 5 – Scelta dei ruoli da installare
Selezionare la prima opzione per l’installazione del ruolo Configuration Server e Process Server. La seconda opzione è utile nel caso si debbano installare ulteriori Process Server per consentire uno scale out del deployment.
Figura 6 – Accettazione del license agreement di MySQL Community Server
Figura 7 – Selezione della chiave necessaria per la registrazione al Site Recovery Vault
Figura 8 – Scelta della metodologia per accedere ai servizi Azure (diretta o tramite proxy)
Figura 9 – Check di verifica dei prerequisiti
Figura 10 – Impostazione delle password relative a MySQL
Figura 11 – Ulteriore check sulla presenza dei componenti necessari per proteggere VMs VMware
Figura 12 – Scelta del path di installazione
L’installazione richiede indicativamente 5 GB di spazio a disposizione, ma sono consigliati almeno 600 GB per la cache.
Figura 13 – Selezione dell’interfaccia di rete e della porta da utilizzare per il traffico di replica
Figura 14 – Summary delle scelte di installazione
Figura 15 – Setup dei diversi ruoli e componenti completato con successo
Al termine del setup viene mostrata la connection passphrase che viene utilizzata dal Configuration Server, che è bene salvare con cura.
In seguito è necessario configurare le credenziali che verranno utilizzate da Azure Site Recovery per effettuare il discovery delle macchine virtuali nell’ambiente VMware e per effettuare l’installazione del Mobility Service sulle macchine virtuali.
Figura 16 – Definizioni delle credenziali utilizzate dal servizio
Completate queste operazioni sarà possibile selezionare il Configuration Server dal portale Azure e successivamente definire i dati del sistema VMware (vCenter oppure vSphere) con cui interfacciarsi.
Figura 17 – Selezione del Configuration Server e aggiunta vCenter/vSphere host
Conclusa questa configurazione è necessario attendere alcuni minuti per consentire al Process Server di effettuare il discovery delle macchine virtuali sull’ambiente VMware specificato.
In seguito occorre definire le impostazioni relative al target della replica:
- Su quale sottoscrizione e con quale recovery model creare i sistemi.
- Quale storage account utilizzare per ospitare i dati replicati.
- vNet su cui attestare i sistemi replicati.
Figura 18 – Impostazioni relative al Target della replica
Lo step successivo prevede la definizione delle policy di replica in termini di RPO (espresso in minuti), retention dei recovery point (espresso in ore) e frequenza con cui effettuare delle snapshot consistenti a livello di applicazione.
Figura 19 – Creazione della policy di replica
Al termine di questa attività viene proposto di effettuare l’analisi del proprio ambiente tramite il tool Deployment Planner (scaricabile direttamente tramite il link riportato nel portale Azure) al fine di accertarsi di avere i requisiti, le risorse network e le risorse storage sufficienti per garantire il corretto funzionamento della soluzione.
Figura 20 – Step di preparazione dell’infrastruttura completati con successo
Terminati gli step di preparazione dell’infrastruttura è possibile attivare il processo di replica:
Figura 21 – Source e Target di replica
Figura 22 – Selezione delle macchine virtuali e dei relativi dischi da replicare
In questa sezione viene anche specificato quale account il Process Server utilizzerà per effettuare l’installazione del Mobility Service su ogni macchina virtuale VMware (account configurati in precedenza come documentato nella Figura 16).
Figura 23 – Selezione della policy di replica e abilitazione facoltativa della Multi-VM consistency
Nel caso venga selezionata l’opzione “Multi-VM consistency” verrà creato un Replication Group all’interno del quale verranno inserite le VMs che si desidera replicare insieme per utilizzare recovery point condivisi. Questa opzione è consigliata solo quando è necessaria una consistenza durante il processo di Failover su più macchine virtuali che erogano lo stesso workload. Inoltre attivando questa opzione è bene tenere in considerazione che per attivare il processo di Failover dei sistemi è necessario configurare un Recovery Plan specifico e non è possibile attivare il Failover per una singola macchina virtuale.
Al termine di queste configurazioni è possibile attivare il processo di replica
Figura 24 – Attivazione del processo di replica e relativo esito
Figura 25 – Stato della replica della macchina virtuale VMware
Una delle difficoltà maggiori quando si implementa uno scenario di Disaster Recovery è avere la possibilità di testarne il funzionamento senza impattare i sistemi di produzione ed il relativo processo di replica. Altrettanto vero è che non testare in modo appropriato il processo di DR equivale quasi a non averlo. Azure Site Recovery consente di testare in modo molto semplice la procedura di Disaster Recovery per valutarne la reale efficacia:
Figura 26 – Test della procedura di Failover
Figura 27 – Esito del processo di Test Failover
Conclusioni
Poter contare su un’unica soluzione come Azure Site Recovery che consente di attivare e testare procedure per la business continuity in infrastrutture eterogenee, contemplando anche macchine virtuali in ambiente VMware, ha sicuramente numerosi vantaggi in termini di flessibilità ed efficacia. ASR consente infatti di affrontare gli ostacoli tipici che si incontrano durante la realizzazione di piani di Disaster Recovery riducendo i costi e la complessità ed aumentando i livelli di compliance. La stessa soluzione può essere inoltre utilizzata per affrontare la migrazione vera e propria dei sistemi verso Azure con un impatto minimo sull’utenza finale grazie a downtime degli applicativi vicini allo zero.
