Questo è il primo di una serie di ben due post :-)

Descriverò la procedura per replicare macchine virtuali VMware su Azure.
Lo strumento utilizzato è Azure Site Recovery.

Già disponibile da tempo per replicare macchine virtuali da host Hyper-V o tramite VMM, recentemente è stato introdotto il supporto per le macchine virtuali su VMware e le macchine fisiche.

Vediamo quali sono i componenti:

  • Site Recovery Vault
    • È il “contenitore” della replica su Azure
    • Configuration server
    • Contiene il database e si occupa di orchestrare le operazioni tra i componenti
  • Master Target server
    • È la destinazione dei dati da replicare
    • Può essere Windows o Linux
  • Process server
    • Gestisce le repliche da inviare al Master Target, installa gli agent e fa il discovery su VMware
  • Mobility service
    • Agent installato sulle macchine protette che invia i dati al Process server
 clip_image001

La replica può avvenire in due modi:

  • Attraverso Internet
    • I trasferimenti avvengono con connessioni SSL attraverso IP pubblici
  • VPN/ExpressRoute
    • Tutte le comunicazioni avvengono attraverso reti private

In entrambi i casi non bisogna aprire nulla in ingresso sui firewall. Tutte le connessioni vengono iniziate on-premises.

La scelta, oltre a come avviene la replica, determina il tipo di macchine si potranno replicare.

 clip_image002  clip_image003

 

Prima di iniziare, alcuni requisiti sono:

  • Una subscription e un account su Azure (ovviamente :-) )
  • VMware ESXi/vCenter 5.1 o 5.5 (il vCenter non è necessario)
  • Guest x64
  • Sistemi operativi guest supportati:
    • Windows Server 2012 R2, Windows Server 2012, o Windows Server 2008 R2 con SP1
    • Centos 6.4, 6.5, 6.6; Oracle Enterprise Linux 6.4, 6.5 sia con kernel Red Hat che Unbreakable Enterprise Kernel Release 3 (UEK3), SUSE Linux Enterprise Server 11 SP3
  • Azure Storage Account:
    • Lo storage di destinazione deve essere Geo Redundant
  • Azure Network
    • Devono essere create una o più reti su cui collegare il Configuration server, Master Target server e le macchine di destinazione
    • Da creare prima di fare il deploy

Per la lista completa dei requisiti è disponibile sull’articolo ufficiale:

https://azure.microsoft.com/en-us/documentation/articles/site-recovery-vmware-to-azure

Iniziamo…

Innanzitutto creiamo il Site Recovery Vault, dal tasto New in basso a sinistra

 clip_image004

Tutto il resto delle configurazioni possono essere fatte dalla pagina “Quick Start” selezionando lo scenario “Between an on-premises site with VMware/physical servers and Azure”

 clip_image005

Prima di procedere con il deploy del Configuration Server, vi siete ricordati di creare la rete?

 clip_image006
 clip_image007
 clip_image008

Selezionando Deploy Configuration Server, si apre questa form

 clip_image009

Verrà creata una macchina virtuale di tipo A3.

Quando sarà avviata, dobbiamo registrarlo.

Scaricare la chiave di registrazione tramite il link “Download registration key”

Verrà scaricato un file XML da utilizzare sul Configuration Server, e servirà per gestire ASR da PowerShell

Import-AzureSiteRecoveryVaultSettingsFile -Path '<Registration Key>'

Connettersi in RDP con utente e password specificati in fase di creazione del Configuration Server

Partirà automaticamente il wizard “Microsoft Azure Site Recovery Configuration/Process Server”, che installerà i requisiti e configurerà il servizio

 clip_image010
 clip_image011
 clip_image012
clip_image013
 clip_image014

Inserire il file di configurazione scaricato prima

 clip_image015

e partirà il download e setup dei componenti

 clip_image016
 clip_image017

Salvare la Passphrase che servirà per configurare il Master Target server e il Process server

 clip_image018

Creare gli utenti che verranno utilizzati per la connessione a VMware e alle VM

 clip_image019
 clip_image020

Avviare la ricerca degli update Windows, nel frattempo che prepareremo gli altri componenti.

Possiamo avviare il deploy del Master Target Server, che richiederà queste informazioni:

 clip_image021
 clip_image022

 

Verrà creata una macchina virtuale della dimensione selezionata.

Collegarsi in RDP (public endpoint solo se è stata selezionata la replica tramite Public Internet)

Viene avviata una sessione PowerShell. NON CHIUDERLA

 clip_image023

Al termine verrà avviato l’Host Agent Config, in cui si dovrà inserire l’IP del Configuration Server e la passphrase generata sul Configuration Server

Si può usare l’IP privato e la porta 443 anche se la replica è attraverso Public Internet, perché le due macchine sono sulla stessa rete

 clip_image024

Aspettare 10/15 minuti prima di vedere il Master Target Server listato sul portale

Nel frattempo avviare la ricerca degli update Windows

Ora installiamo il Process Server

Scaricare l’installer del Process Server

Eseguire Microsoft-ASR_CX_TP_8.4.0.0_Windows* che installa e configura le dipendenze

Installare VMware vSphere CLI 5.5.0 (VMware-vSphere-CLI-5.5.0-1384587, non sono supportati update successivi)

Eseguire Microsoft-ASR_CX_8.4.0.0_Windows*

Selezionare Process Server

 clip_image025

Selezionare Yes per proteggere VM VMware, se non è installato VMware vSpere CLI, o se è installata una versione non supportata, il setup si interromperà

 clip_image026

Selezionare l’interfaccia di rete da utilizzare, se ce n’è più di una

 clip_image027

Inserire l’IP e la porta del configuration server: se ci si connette tramite VPN, inserire l’IP privato e la porta 443, altrimenti inserire l’IP e la porta dell’endpoint HTTPS

Si può ricavare con questo comando PowerShell, dopo aver importato la chiave, e se non ci sono altri Cloud Service o server ASR

Get-AzureEndpoint -Name HTTPS -VM (Get-AzureVM -ServiceName $(Get-AzureService).ServiceName -Name $(Get-AzureSiteRecoveryServer).Name)

Inserire la passphrase generata prima

 clip_image028

Selezionare il disco su cui fare cache

 clip_image029

Al termine del setup, verrà richiesto il riavvio, e se è stato selezionato un disco diverso da C, verrà presentato questo avviso

clip_image030

Verificare che siano registrati il process server e il master target server

 clip_image031

Verificare gli update Windows e dei componenti di ASR sul Configuration Server, Process Server e Master Target Server.

Se sono disponibili aggiornamenti per i componenti ASR, viene notificato nella Dashboard, dove ci sono anche i link per i download

Aggiungiamo il vCenter o gli ESXi host, dal Configuration server, click su ADD VCENTER SERVER

 clip_image032

Specificare l’IP/porta del vCenter/ESXi, selezionare il Process Server (deve essere sulla stessa rete) e l’account creato in precedenza sul Configuration Server

 clip_image033

Il vCenter/ESXi dovrebbe apparire insieme al Configuration Server nella sezione Servers

Creiamo un protection Group

 clip_image034

Definire le impostazioni di replica

clip_image035
  • Multi VM Consistency: ripristina tutte le macchine allo stesso recovery point. Utile se il protection group contiene macchine dello stesso workload
  • RPO threshold: soglia per generare alert se viene superato dall’RPO
  • Recovery point retention: tempo di conservazione dei recovery point
  • Application-consistent snapshot frequency: frequenza di creazione degli snapshot

Aggiungiamo le macchine da proteggere, se non è già installato il servizio, viene installato in push dal Process serve

clip_image036

Selezioniamo il Process Server, il Master Target server e lo storage account di destinazione.

Se non sono selezionabili Storage Account è perché devono essere Geo Redundant. Quello che viene creato con il Configuration server è Locally Redundant (può essere modificato)

 clip_image037

L’account da utilizzare per l’installazione del Mobility Service deve avere privilegi amministrativi sui guest e per Linux deve essere root

 clip_image038

Se l’installazione dell’agent e la configurazione è andata a buon fine, verrà avviata la sincronizzazione

 clip_image039

Quando una macchina ha finito la sincronizzazione (status Protected), è possibile configurare il nome, le risorse CPU/RAM e la rete

Di default le macchine non vengono associate ad una rete

 clip_image040

Se viene modificata la dimensione dello storage della VM sorgente, la macchina replicata fallirà. Bisognerà rimuovere la VM su Azure, disabilitando la protezione ma mantenendo i dati

 clip_image041

Purtroppo al momento è possibile fare failover solo manualmente e non è possibile eseguire il test.

Per iniziare il failover, il Configuration Server e il Master Target Server devono essere funzionanti

Le macchine sorgente non vengono spente. Se durante il failover le macchine sono accese, la replica viene interrota e bisognerà rimuovere le macchine dal protection group per riprendere la replica

Per non perdere dati, spegnere le macchine sorgente prima di iniziare il failover

Creare un recovery plan

 clip_image042
 clip_image043

 

È possibile configurare il recovery plan:

  • Specificare l’ordine di accensione
  • Richiedere azioni manuali tramite avvisi (ad esempio modificare un record DNS)
  • Eseguire script (tramite Azure Automation Runbooks)

Arvedze




Andrea Mennuni
Systems Engineer
Andrea Mennuni

La carriera informatica di Andrea inizia nel 2000 come sistemista Unix, conseguendo le certificazioni su HP-UX e SUN Solaris. Dal 2004 il suo interesse si sposta verso il mondo Microsoft e quello VMware. Nel 2010 inizia il suo percorso di certificazione Microsoft (MCTS, MCITP Exchange, MCSE Messaging) e parallelamente quello VMware. Le sue aree di competenza sono Windows Server, Active Directory, System Center, Hyper-V, Microsoft Exchange e Office 365. Andrea è Systems Engineer in Pulsar IT



Iscriviti al feed