Archivi categoria: VMware

VMware vCenter High Availability: manutenzione e test failover – pt.2

Facebooktwittergoogle_plusredditlinkedin

VMware vCenter High Availability: manutenzione e test failover – pt.2

vcha-maintenance-test-failover-01

Una volta che il cluster HA è stato creato, le procedure di manutenzione e test del failover del vCenter High Availability assicurano che la VCSA 6.5 sia protetta contro tipologie multiple di malfunzionamenti hardware e software.

Quando i nodi del vCenter Server (Attivo, Passivo e Witness) sono stati implementati, la manutenzione e il test failover devono essere effettuati regolarmente per garantire un cluster funzionale e protetto.

 

Blog Serie

VMware vCenter High Availability: installazione – pt.1
VMware vCenter High Availability: manutenzione e test failover – pt.2

 

Monitorare lo stato del cluster HA

Controllando lo stato del vCenter Server HA regolarmente, si assicura la massima protezione per la funzionalità dell’infrastruttura virtuale.

Per verificare lo stato corrente del cluster HA, aprire il vSphere Web Client e posizionarsi nella sezione Configure e selezionare la voce vCenter HA. Cliccare su vCenter HA Monitoring per accedere al monitoraggio.

vcha-maintenance-test-failover-02

La finestra visualizza lo stato corrente dei nodi Attivo, Passivo e Witness. Cliccare su vCenter HA Settings per ritornare alla pagina di configurazione.

vcha-maintenance-test-failover-03

 

Manutenzione del cluster HA

Il cluster HA è abilitato per default ed effettua un failover automatico quando si verifica un malfunzionamento. Se è necessario controllare il comportamento del cluster HA, dall’area vCenter HA cliccare sul bottone Edit.

vcha-maintenance-test-failover-04

Selezionando l’opzione Maintenance mode si disabilita il failover automatico ma la replica continua a funzionare tra i nodi Attivo e Passivo. Cliccare su OK per confermare. Questa opzione si utilizza ad esempio per effettuare l’aggiornamento del vCenter Server.

vcha-maintenance-test-failover-05

Quando il cluster HA è in Maintenance Mode, lo Status corrente è visualizzato nella tabella.

vcha-maintenance-test-failover-06

Selezionando l’opzione Disable vCenter HA le funzioni di failover e replication sono disabilitate ma la configurazione HA rimane intatta. Cliccare OK per confermare.

vcha-maintenance-test-failover-07

Quando il cluster HA è disabilitato, lo Status corrente viene visualizzato nella tabella.

vcha-maintenance-test-failover-08

Selezionando l’opzione Remove vCenter HA, il cluster HA viene completamente rimosso preservando la normale funzionalità del nodo Attivo.

vcha-maintenance-test-failover-09

Se il cluster HA è in Maintenance Mode o Disabilitato, selezionare la voce Enable vCenter HA per ripristinare la funzionalità di default del cluster HA.

vcha-maintenance-test-failover-10

Quando il cluster viene abilitato, sono richiesti alcuni minuti prima che il failover automatico sia disponibile nuovamente poichè la replica iniziale potrebbe essere ancora in corso.

vcha-maintenance-test-failover-11

Il vCenter HA è disponibile e la protezione con il failover automatico è nuovamente abilitata.

vcha-maintenance-test-failover-12

 

Backup e Restore

Come strategia di backup, effettuare il backup del solo nodo Attivo tralasciando i nodi Passivo e Witness. Nel caso ci sia la necessità di effettuare il restore del nodo Attivo, è necessario rimuovere la configurazione del cluster HA, effettuare il restore e ricreare il cluster HA.

vcha-maintenance-test-failover-13

 

Testare il failover

Per testare il failover, dall’area Configure > vCenter HA cliccare sul bottone Initiate Failover.

vcha-maintenance-test-failover-14

Abilitare l’opzione Force the failover… e cliccare Yes per iniziare il failover.

vcha-maintenance-test-failover-15

E’ possibile seguire l’andamento del failover dal browser utilizzando, ovviamente, lo stesso nome DNS o indirizzo IP. VMware dichiara un RTO di 5 minuti, probabilmente un valore un po’ troppo alto ma che sicuramente verrà migliorato nelle prossime release.

vcha-maintenance-test-failover-16

Il nodo Passivo subentra come ruolo Attivo e l’indirizzo IP del cluster HA (nell’esempio 192.168.70.10) è rimasto, come previsto, lo stesso.

vcha-maintenance-test-failover-17

Quando il nodo Attivo ritorna operativo, viene ripristinato lo status normale.

vcha-maintenance-test-failover-18

Configurando il vCenter Server HA si assicura un alto livello di protezione per il proprio ambiente virtuale senza la necessità di extra licenze. Testare il failover è una buona procedura per essere sicuri che il tutto funzioni come previsto.

signature

Copyright Nolabnoparty. All Rights Reserved.

VMware NSX 6.4

Facebooktwittergoogle_plusredditlinkedin

VMware ha rilasciato una nuova versione di NSX-v, la versione di NSX per ambienti vSphere. Benché NSX 6.4 sia solo una minor release, la lista delle novità è decisamente significativa. Tra le novità più interessanti, c’è finalmente il supporto per il client in HTML5 (un altro piccolo passo verso la sua completa adozione) e funzionalità di firewall (distribuito) anche a livello 7. Purtroppo mancano ancora le funzionalità di load balacing di tipo distribuito (sarebbe un interessante valore aggiunto) e una chiara indicazione su quale versione tra NSX-v e NSX-t potranno rappresentare il futuro di NSX. Personalmente […]

The post VMware NSX 6.4 appeared first on vInfrastructure Blog.

VMware vCenter High Availability: configurazione – pt.1

Facebooktwittergoogle_plusredditlinkedin

VMware vCenter High Availability: configurazione – pt.1

vcha-setup-01

vCenter High Availability (VCHA) è una funzionalità introdotta in VMware vSphere 6.5 che elimina il singolo punto di failure del vCenter ed è disponibile solo per la VCSA 6.5.

Per implementare un cluster VCHA è richiesto l’utilizzo di una singola licenza di vCenter (la licenza Standard è sufficiente). vCenter High Availability supporta i modelli di installazione external PSC (vCenter Server e PSC risiedono in VM differenti) ed embedded PSC (vCenter Server e PSC sono installati nella stessa VM).

 

Blog Serie

VMware vCenter High Availability: configurazione – pt.1
VMware vCenter High Availability: manutenzione e failover – pt.2

 

Architettura del vCenter High Availability (VCHA)

L’architettura del vCenter HA è composto da tre nodi:

  • Active Node – gestisce l’istanza attiva del vCenter Server fornendo i servizi richiesti dai client.
  • Passive Node – gestisce l’istanza passiva del vCenter Server e riceve continuamente gli aggiornamenti dello stato dal nodo Attivo in modo sincrono. Assume il ruolo di nodo Attivo nel caso di un malfunzionamento del nodo primario.
  • Witness Node – è una VM leggera che è utilizzata come nodo di quorum e non assume i ruoli di nodo Attivo/Passivo.

vcha-setup-02

Sebbene le architetture tradizionali utilizzano storage condivisi per risolvere il problema dello split-brain, cioè l’inconsistenza dei dati/disponibilità dovuto a malfunzionamenti della rete con sistemi distribuiti per il mantenimento dei dati replicati, il design del VCHA non prevede l’utilizzo di un’installazione basata su storage condiviso per il supporto del cluster VCHA distribuito su datacenter multipli. Devono essere utilizzati tre diversi datastore per salvare le tre VM ed ogni nodo deve risiedere in host differenti. Almeno 3 host sono richiesti per effettuare l’installazione.

E’ richiesta inoltre una buona connettività di rete tra il nodo Attivo e Passivo per garantire un RPO pari a zero e quindi deve essere configurata una rete dedicata separata dalla rete di management. I client hanno accesso alla VCSA tramite l’interfaccia di rete di management.

Nel caso il vCenter Server Attivo smettesse di funzionare, il cluster HA si comporta in questo modo:

  • Fallisce il nodo Attivo: fino a quando il nodo Passivo ed il Witness possono comunicare tra loro, il nodo Passivo assume il ruolo di nodo Attivo e comincia a soddisfare le richieste dei client.
  • Fallisce il nodo Passivo: se il nodo Attivo e Witness riescono a comunicare fra loro, il nodo Attivo continua a soddisfare le richieste dei client.
  • Fallisce il nodo Witness: fino a quando il nodo Attivo e Passivo comunicano fra loro, il nodo Attivo continua a soddisfare le richieste dei client.
  • Fallisce più di un nodo: tutti e tre i nodi non possono comunicare fra loro, il cluster è ritenuto non operativo causando l’interruzione dei servizi del vCenter Server.
  • Evento di isolamento del nodo: se un nodo rimane isolato dal cluster, viene automaticamente rimosso dal cluster fermando tutti i servizi. Ad esempio se un nodo Attivo è isolato, tutti i servizi vengono fermati per assicurare che il nodo Passivo possa subentrare fino a quando è connesso al nodo Witness.

vcha-setup-03

 

Configurare la rete HA

Prima di procedere con l’installazione del VCHA, è necessario creare una nuova rete poichè il cluster VCHA necessita di una rete isolata per la comunicazione dei nodi.

Dal vSphere Web Client, selezionare il primo host del cluster e posizionarsi nella sezione Configure. Selezionare l’opzione Virtual switches per la configurazione della rete.

vcha-setup-04

Cliccare sull’icona Add host network per configurare la rete HA.

vcha-setup-05

Selezionare Virtual Port Group for a Standard Switch come tipo di connessione e cliccare su Next.

vcha-setup-06

Spuntare l’opzione Select an existing standard switch e cliccare Browse per selezionare lo vSwicth da utilizzare. Cliccare Next.

vcha-setup-07

Inserire una Network label ed opzionalmente una VLAN ID. Cliccare Next per continuare.

vcha-setup-08

Cliccare Finish per creare il nuovo Port Group.

vcha-setup-09

Il Port Group HA è stato creato.

vcha-setup-10

Ora ripetere le stesse operazioni per tutti gli altri host membri del cluster.

 

Installare il vCenter HA con la PSC embedded

Una volta che la rete HA è operativa, è possibile procedere con la configurazione del vCenter High Availability.

Il cluster VCHA può essere installato in due modi:

  • Basic – adatto per ambienti medio piccoli, il wizard si occupa della creazione dei nodi attivo/passivo/witness e delle interfacce vNIC. Sono richieste informazioni minime dal sistema, come l’indirizzo IP. Se la rete prevede un cluster DRS, il piazzamento delle VM viene fatto automaticamente. Da tenere presente che questa tipologia di installazione richiede che la rete HA sia già presente ed operativa.
  • Advanced – è necessario un setup più complesso ma fornisce una maggiore flessibilità al design (ad esempio una VM può essere piazzata in un datacenter o in un dominio SSO diverso). I tre nodi attivo/passivo/witness devono essere creati manualmente fornendo tutte le informazioni di rete richieste.

Dal vSphere Web Client, effettuare un click con il tasto destro del mouse sul vCenter Server e selezionare l’opzione vCenter HA Settings.

vcha-setup-11

Nella sezione vCenter HA cliccare il bottone Configure per avviare l’installazione del VCHA.

vcha-setup-12

Selezionare il metodo di installazione Basic e cliccare su Next.

vcha-setup-13

Specificare l’IP address e la subnet mask per il nodo Attivo, cliccare su Browse e selezionare la rete vCenter HA configurata precedentemente. Cliccare Next.

vcha-setup-14

Specificare l’IP address per i nodi Passivo e Witness e cliccare poi su Next.

vcha-setup-15

Se nella finestra di configurazione i requisiti del VCHA non vengono soddisfatti, i nodi Passivo e Witness potrebbero visualizzare degli errori. Cliccare sul link Compatibility errors per verificare la problematica riscontrata.

vcha-setup-16

L’errore in questo caso si verifica perchè i nodi Passivo e Witness devono essere posizionati in host e storage differenti. Cliccare su Close per chiudere la finestra.

vcha-setup-17

Per risolvere il problema, cliccare sulla voce Edit vicino al messaggio di errore del nodo Passivo .

vcha-setup-18

Inserire un nome per la virtual machine o lasciare il default, selezionare la locazione e cliccare Next.

vcha-setup-19

Selezionare l’host ESXi da usare e cliccare su Next una volta che la verifica della compatibilità è stata passata.

vcha-setup-20

Poichè i Datastore cluster non sono supportati dall’installazione del vCenter HA, selezionare uno storage standalone che non sia membro di cluster e quindi cliccare su Next.

vcha-setup-21

Specificare le reti da utilizzare per il management ed HA quindi cliccare su Next per continuare.

vcha-setup-22

Nel riepilogo della configurazione, cliccare su Finish per completare la configurazione del nodo Passivo. Da notare che l’operazione per la creazione del nodo Passivo consiste nell’effettuare un clone della VM corrente.

vcha-setup-23

Il nodo Passivo è ora indicato come compatibile. Procedere con il nodo Witness cliccando sul corrispondente link Edit.

vcha-setup-24

Ripetere la stessa procedura come fatto per il nodo Passivo. Da notare che è necessario specificare solamente la rete HA per il nodo Witness.

vcha-setup-25

Quando la configurazione è stata completata, anche il nodo Witness è indicato come compatibile. Cliccare su Next per completare l’installazione.

vcha-setup-26

Quando le impostazioni della configurazione sono stati verificate, cliccare su Finish per procedere con l’effettiva installazione.

vcha-setup-27

Se l’installazione dei nodi VCHA avviene in un numero di host inferiore a tre, viene visualizzato un errore. Come pre-requisito è necessario avere almeno tre host per installare il VCHA.

vcha-setup-28

Come workaround, questo post pubblicato sul blog virtuallyGhetto.com spiega come sia possibile disabilitare la regola DRS Anti affinity che blocca l’installazione editando un parametro nel vCenter Server.

Dal vCenter Server posizionarsi nella sezione Configure e selezionare la voce Advanced Settings. Cliccare sul bottone Edit per modificare il parametro richiesto. Nel box di ricerca, digitare la parola vcha per identificare velocemente il parametro da modificare.

Selezionare il parametro config.vpxd.vcha.drsAntiAffinity e sostituire il valore true con false quindi cliccare su OK per confermare. Sebbene questo setup permette l’implementazione dei nodi VCHA in soli due host, questa configurazione dovrebbe essere utilizzata solo in un ambiente LAB e non in produzione.

vcha-setup-29

Dopo aver disabilitato la regola DRS Anti-Affinity, l’installazione dei nodi VCHA procede correttamente.

vcha-setup-30

Dopo alcuni minuti, l’installazione dei nodi Passivo e Witness viene completata. Nella sezione Summary è possibile trovare il widget vCenter HA widget che riporta lo stato di funzionalità del cluster.

vcha-setup-31

Nella sezione Configure, selezionare la voce vCenter HA per vedere lo stato dei tre nodi.

vcha-setup-32

 

Installare il vCenter HA con un PSC esterno

L’implementazione del cluster HA con un PSC esterno prevede almeno due istanze PSC dietro ad un load balancer.

vcha-setup-33

La configurazione della rete HA e l’implementazione dei nodi VCHA sono stati completati correttamente. Nella parte 2 sarà illustrata la procedura per come gestire i nodi VCHA e testare il failover.

signature

Copyright Nolabnoparty. All Rights Reserved.

Migrazione di macchine virtuali VMware verso Microsoft Azure con Azure Site Recovery

Facebooktwittergoogle_plusredditlinkedin

Azure Site Recovery è un servizio che permette di proteggere le nostre macchine virtuali automatizzandone la replica verso il Cloud. Le macchine che possono essere protette da Azure Site Recovery (ASR) possono essere fisiche, macchine virtuali VMware oppure macchine virtuali Hyper-V. Il compito di ASR è quello di coordinare e gestire la replica continua dei dati e automatizzare il ripristino dei servizi nel caso di un’interruzione nel data center primario.

Abbiamo visto nel precedente articolo Migrazione delle macchine virtuali VMware verso Microsoft Azure con l’utilizzo di Azure Migrate come il servizio Azure Migrate semplifica la migrazione delle macchine virtuali VMware vSphere verso il cloud Microsoft Azure e può fornirvi assistenza attraverso tutti passaggi necessari per poterla effettuare, dall’assessment alla migrazione vera e propria. Compito di questo articolo sarà quello di mostrarvi il passaggio successivo al discovery e all’assessment, cioè la migrazione vera e propria delle VM.

Utilizzeremo quindi Azure Site Recovery per migrare le nostre macchine virtuali VMware verso Azure.

Figura 1: Architettura della migrazione da VMware ad Azure

Figura 2: Processo di replica di macchine VMware verso Azure

Creazione del Recovery Service Vault

Il Recovery Service Vault è un’entità di archiviazione di Azure che ospita i dati e le configurazioni delle macchine virtuali. Per maggiori informazioni potete leggere l’articolo https://docs.microsoft.com/it-it/azure/backup/backup-azure-recovery-services-vault-overview

Per creare un nuovo Recovery Service Vault è sufficiente aprire il portale di Azure e, facendo clic su New, cercare Backup and Site Recovery (OMS). Inserite quindi il nome del vostro Vault, il Resource group da utilizzare e la location dove volete che venga creato, come mostrato in figura:

Figura 3: Creazione di n nuovo Azure Recovery Service Vault

Al termine della creazione del Vault vi apparirà la schermata mostrata in figura:

Figura 4: Creazione del Vault completata

Cliccate su Site
Recovery e successivamente su Prepare Infrastructure, indicando come primo passaggio qual è il vostro Protection Goal. Nel mio caso, voglio proteggere alcune macchine virtuali VMware in Azure.

Figura 5: Creazione del Protection Goal

Nel secondo passaggio vi verrà chiesto di scaricare e testare il Deployment Planner, che verificherà che abbiate banda a sufficienza e quanto storage servirà per soddisfare le vostre necessità. Questo strumento consente di profilare le virtual machine VMware senza alcun impatto sulla produzione e di determinare i requisiti di larghezza di banda e archiviazione di Azure per operazioni di replica e failover. Vi consiglio di approfondire questo argomento leggendo l’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-deployment-planner

Figura 6: Deployment Planning

Installazione del Configuration Server

Il terzo passaggio consiste nel dichiarare quale Configuration Server volete utilizzare in Site Recovery. Il Configuration Server funge da coordinatore tra i servizi di Site Recovery e l’infrastruttura locale (on-premises). Per i requisiti hardware e software del Configuration Server vi rimando all’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-manage-configuration-server. Provvedete a scaricare la virtual appliance del server di configurazione (sono circa 16,5 GB) e ad importarla nella vostra infrastruttura VMware. Seguite tutte le istruzioni indicate nel blade del portale Azure:

Figura 7: Download della virtual appliance del Configuration Server

Figura 8: importazione della virtual appliance del Configuration Server

Dopo aver avviato il Configuration Server e configurato un account amministrativo, la virtual appliance verificherà la presenza della connessione Internet e vi chiederà di loggarvi con le credenziali per amministrare il Tenant Azure.

Figura 9: Connessione al Tenant di Azure

Dopo pochi minuti, il server si configurerà in Azure Active Directory e sarà necessario il riavvio della VM.

Figura 10: Configurazione del Server in Azure Active Directory

Dopo il riavvio potete loggarvi alla macchina ed in automatico vi si aprirà una pagina web per la gestione del Configuration Server. Nel caso non dovesse aprirsi, potete utilizzare il collegamento presente sul Desktop. Seguite le istruzioni riportate nella pagina web e configurate la scheda di rete che volete utilizzare per collegarvi ad Azure. Subito dopo vi verrà chiesto di selezionare il Recovery Services Vault da utilizzare.

Figura 11: Selezione del Recovery Services Vault

Il passaggio successivo consiste nell’installazione del software MySQL Community Server e VMware PowerCLI. Procedete all’installazione dei due software e confermate cliccando sul pulsante Continue.

Figura 12: Installazione del software aggiuntivo MySQL e PowerCLI

A questo punto l’appliance verifica che le proprie configurazioni siano corrette (spazio libero sul disco, IP statico, memoria del sistema, ecc.), come mostrato in figura:

Figura 13: Verifica della configurazione della virtual appliance

Per poter effettuare la connessione al vCenter è necessario fornire le credenziali di accesso, che dovrete aggiungere a questo punto della configurazione, come mostrato in figura:

Figura 14: Aggiunta delle credenziali di accesso al vCenter

Per installare Azure Site Recovery mobility service all’interno delle VM è necessario fornire delle credenziali amministrative. Il servizio mobility di Azure Site Recovery acquisisce i dati da una macchina virtuale VMware o da un server fisico e le inoltra al Process Server (che è installato nella stessa macchina del Configuration Server). Per maggior informazioni su questo servizio vi rimando alla lettura dell’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-install-mob-svc

Figura 15: Inserimento delle credenziali amministrative delle VM da proteggere

A questo punto non resta altro da fare che cliccare sul pulsante Finalize configuration. La configurazione dura alcuni minuti.

Figura 16: Configurazione del server completata

Completamento della preparazione dell’infrastruttura

Tornate nel pannello di Microsoft Azure Site Recovery e continuate la configurazione del Source. Vi appariranno sia il Configuration Server che avete appena installato e configurato, sia il vCenter che avete indicato nel wizard di configurazione, come mostrato in figura:

Figura 17: Selezione del Configuration Server e del vCenter

Il passaggio 4 consiste nel configurare il Target, cioè lo Storage Account dove volete replicare le VM e la Network a cui volete collegarle. È possibile anche creare di nuovi, se quelli già esistenti non soddisfano le vostre esigenze.

Figura 18: Preparazione del Target

Completate la parte di preparazione dell’infrastruttura creando una nuova Replication
policy e associandola al vostro Configuration Server. La Replication Policy stabilisce la frequenza di replica delle vostre VM on-premises. Maggiori informazioni sono disponibili al link https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-setup-replication-settings-vmware

Figura 19: Creazione ed associazione delle Replication Policy

Dopo pochi minuti, vedrete apparire nel portale di Azure le diverse policy che vengono create. Terminate la configurazione cliccando su OK.

Figura 20: Preparazione dell’infrastruttura completata

Abilitare la replica delle VM

Per abilitare la replica delle VM è sufficiente fare clic su Step1:
Replicate Application e seguire le indicazioni contenute nel blade che si aprirà. Configurate come prima cosa il Source Environment, completando le informazioni come mostrato in figura:

Figura 21: Definizione del Source Environment

Nel Target Setting for Recovery inserite la sottoscrizione da utilizzare, lo storage account in cui inserire le VM replicate, la virtual network da utilizzare e gli altri parametri richiesti.

Figura 22: Configurazione dei Target Settings per la replica delle VM

Selezionate nel passaggio 3 le macchine virtuali on-premises da replicare, come mostrato in figura:

Figura 23: Selezione delle VM da replicare

Indicate quali credenziali utilizzare per l’installazione degli agent di Azure e, se la VM ha più dischi, decidete quali dischi escludere dalla replica.

Figura 24: Configurazione delle proprietà delle VM

Terminate a questo punto l’abilitazione della replica configurando nell’ultimo passaggio la Replication Policy da utilizzare e scegliendo se volete raggruppare le macchine, in modo tale che vengano replicate tutte insieme, per assicurare la consistenza delle applicazioni nel caso in cui queste utilizzino macchine diverse. Nel mio caso ho una webapp che usa due webserver di frontend ed un database server di backend e quindi voglio che siano replicati insieme verso Azure.

Figura 25: Configurazione del Replication Settings e dei Replication Groups

Non vi resta a questo punto che monitorare la prima replica delle vostre VM on-premises. Selezionate il nodo Replicated Items dal portale di Azure e controllate lo stato di sincronizzazione delle macchine virtuali.

Figura 26: Monitoraggio delle repliche delle VM

Nel caso di errori cliccate sulla VM e cercate di individuarne i motivi. Nella schermata sotto è indicato uno dei probabili avvisi o errori che vi possono apparire:

Figura 27: Warning sulla Replica di una VM

Creazione del Recovery Plan

Il Recovery Plan (o piano di ripristino) permette di stabilire quali macchine devono essere avviate ed in quale ordine. Cliccate su Step 2: Recovery Plans e aggiungetene uno nuovo, configurandolo con i parametri richiesti:

Figura 28: Creazione di un Recovery Plan

Una volta che il Recovery Plan è stato creato potete personalizzarlo a vostro piacimento, raggruppando le macchine virtuali da avviare insieme, come mostrato in figura:

Figura 29: Personalizzazione del Recovery Plan

Test del Failover

Una volta che avete terminato la replica di tutte le macchine virtuali potrete provare a testare il Failover delle VM in Azure. Cliccando su Overview nel Recovery Service Vault dal portale di Azure, potrete avere un’idea di come sia configurata la vostra infrastruttura e informazioni sullo stato di replica delle vostre VM.

Figura 30: Overview della vostra infrastruttura di replica in Azure

Cliccate sul vostro Recovery Plan e successivamente sul pulsante Test failover. Dal blade che vi si aprirà scegliete il Recovery Point da testare e scegliete la virtual network Azure a cui collegare le VM di test che verranno create. Vi consiglio di utilizzare una VNET di test, in modo tale da non avere problemi.

Figura 31: Failover Test del Recovery Plan

A questo punto verranno create delle macchine di test nel vostro Tenant Azure. Collegatevi alle macchine in Desktop remoto e verificate che tutto funzioni correttamente.

Figura 32: Failover test avviato per il Recovery Plan scelto

Figura 33: Site recovery job e dettagli delle operazioni

Al termine di tutte le procedure di controllo, sarà possibile effettuare il Cleanup test failover, che distruggerà tutte le VM Azure di test che sono state create.

Figura 34: Lancio del Cleanup test failover

Figura 35: Dettaglio delle operazioni del Cleanup test failover

A questo punto avete completato tutte le operazioni per la protezione delle VM on-premises in Azure. Con questo tipo di configurazione Azure è diventato il vostro sito di Disaster Recovery e lo potrete utilizzare nel caso non sia possibile utilizzare il Datacenter principale.

Migrazione

Se il vostro obiettivo è invece migrare le macchine VMware on-premises, allora basterà dichiarare il Failover e lasciare che le macchine vengano avviate in Azure. Prima di effettuare questa operazione assicuratevi che ogni macchina sia configurata con le dimensioni corrette, con la VNET corretta e, nel caso ne abbiate i diritti, attivate l’Hybrid Use Benefit, che vi permette un risparmio considerevole sulle licenze del sistema operativo.

Figura 36: Configurazione di ogni singola macchina virtuale

Cliccate sul vostro Recovery
Plan e dichiarate il Failover, come mostrato in figura:

Figura 37: Failover dei Recovery Plan

Scegliete il Recovery Point da utilizzare per il Failover e, nel caso, selezionate la casella per spegnere le macchine virtuali on-premise prima del Failover, in modo tale da avere una situazione consistente. Se scegliete Latest (lowest RPO) verrà scelto il Recovery Point più recente e verranno sincronizzate le ultime modifiche apportate alla VM on-premises.

Figura 38: Scelta del Recovery Point del Failover

Il processo di Failover creerà le nuove macchine virtuali nel vostro tenant Azure, secondo le caratteristiche che avete definito precedentemente.

Figura 39: Esecuzione del Failover e dettaglio delle operazioni

Terminate tutte le operazioni, le macchine virtuali saranno create nel vostro Tenant Azure e saranno visibili nel Resource Group di destinazione che avete scelto.

Figura 40: Macchine virtuali accese nel Resource Group di Azure di destinazione

Effettuate l’ultima operazione, che consiste nell’eseguire, per ogni singola VM, il Complete
Migration. Nella finestra che vi si aprirà confermate con OK. Dopo alcuni minuti la migrazione sarà terminata!

Figura 41: Esecuzione del comando Complete migration su ogni VM

Figura 42: Conferma della migrazione per ogni singola VM da migrare ad Azure

NOTA: la macchina virtuale in Azure avrà un indirizzo IP dinamico nella VNET che avete scelto. Assicuratevi, nel caso ne abbiate bisogno, di mettere un indirizzo IP statico. Per maggiori informazioni sulla procedura corretta vi rimando all’articolo https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-network-interface-addresses

Per completare la migrazione potete cancellare il Recovery Service Vault. Seguire tutte le indicazioni contenute nell’articolo https://docs.microsoft.com/en-us/azure/site-recovery/delete-vault

Figura 43: Cancellazione dell’Azure Recovery Vault

Conclusioni

Azure Site Recovery è sicuramente uno strumento potente per effettuare il Disaster Recovery delle nostre macchine virtuali VMware o dei nostri server fisici e può essere facilmente utilizzato per poter effettuare una migrazione verso il cloud Azure. Microsoft si è impegnata molto per fornire alle aziende strumenti utili a valutare la migrazione delle VM on-premises con lo strumento Azure Migrate https://www.ictpower.it/sistemi-operativi/migrazione-delle-macchine-virtuali-vmware-verso-microsoft-azure-con-lutilizzo-di-azure-migrate.htm e offrire la possibilità di migrarle facilmente con Azure Site Recovery.

Migrazione delle macchine virtuali VMware verso Microsoft Azure con l’utilizzo di Azure Migrate

Facebooktwittergoogle_plusredditlinkedin

Pochi mesi fa è stato annunciato un nuovo servizio chiamato Azure Migrate https://azure.microsoft.com/it-it/blog/announcing-azure-migrate/

Obiettivo di questo servizio è semplificare la migrazione delle macchine virtuali VMware vSphere verso il cloud di Microsoft Azure e di fornirvi assistenza attraverso tutti passaggi necessari per poterla effettuare, dall’assessment alla migrazione vera e propria. Dopo aver individuato le informazioni sulle macchine virtuali VMware ospitate nel Datacenter locale (utilizzo di CPU e memoria, dimensioni del disco e connessione alle diverse reti), sarà possibile ottenere consigli sul corretto dimensionamento delle risorse cloud (come ad esempio la dimensione della VM ospitata in Azure), in modo tale da avere un maggior controllo sui costi di migrazione in base ad un utilizzo efficiente della VM in Azure.

Dopo aver eseguito una valutazione della propria infrastruttura on-premises con Azure Migrate, sarà possibile quindi iniziare la migrazione delle macchine virtuali locali verso Azure, utilizzando i servizi messi a disposizione da Microsoft, come ad esempio Azure Site Recovery e Azure Database Migration Service.

Azure Migrate consente quindi di:

  • Valutare l’idoneità per Azure: valutare se le VM on-premises possono essere eseguite in Azure.
  • Ottenere informazioni sulle dimensioni consigliate: ottenere informazioni per dimensionare correttamente le VM in Azure in base alla cronologia delle prestazioni delle macchine virtuali on-premises.
  • Stimare i costi mensili: ottenere una stima dei costi per l’esecuzione delle VM in Azure.
  • Facilitare la migrazione: visualizzare le dipendenze delle VM on-premises per creare gruppi di VM di cui eseguire la migrazione insieme.

Figura 1: Principio di funzionamento di Azure Migrate

Per cominciare a familiarizzare con questo nuovo strumento potete collegarvi al portale di Azure e cercare Azure Migrate. Attualmente la funzionalità è in Preview.

Figura 2: Ricerca della funzionalità di Azure Migrate (Preview) nel portale di Azure

Cliccate sul pulsante Create e iniziate un nuovo progetto di migrazione, inserendo tutti i parametri richiesti, come mostrato in figura. Attualmente è possibile creare un progetto Azure Migrate solo nell’area Stati Uniti centro-occidentali (West Central US). Ciò non impedisce, tuttavia, di pianificare una migrazione per una diversa regione di Azure di destinazione e quindi ad esempio eseguire le macchine virtuali in West Europe. La località del progetto di migrazione viene usata solo per l’archiviazione dei metadati individuati nell’ambiente on-premises e che serviranno successivamente a definire il progetto.

Figura 3: Creazione del nuovo progetto di migrazione

La prima operazione da effettuare consiste nel “Discover & Assess“, che si compone essenzialmente di due fasi: Il primo step consiste nell’individuare quali sono le macchine virtuali VMware presenti nella propria infrastruttura, mentre il secondo step consiste nel creare un assessment. È possibile individuare fino a 1000 VM in una singola individuazione (discover) e fino a 1500 VM in un singolo progetto. È inoltre possibile valutare fino a 400 VM in una singola valutazione (assess).

Figura 4: Discover e Assess – Schermata iniziale per l’avvio delle due fasi

Figura 5: Prima fase – Individuazione dell’ambiente on-premises e delle VM VMware

Dopo aver cliccato sul pulsante “Discover machines” vi verrà presentata una pagina con 4 passaggi da effettuare. Azure Migrate usa una VM da far girare on-premises (una appliance) con a bordo un agente che si occuperà di raccogliere ed individuare i computer on-premises. Per utilizzare l’appliance, scaricate il file di installazione in formato Open Virtualization Appliance (con estensione OVA) e importatelo come macchina virtuale nel server vCenter locale.

Figura 6: Download della virtual appliance di Azure Migrate

Figura 7: importazione della virtual appliance di Azure Migrate nel vCenter locale

Figura 8: Schermata finale prima dell’importazione dell’appliance di Azure Migrate

  1. Terminata l’importazione dell’appliance, procedete al suo avvio e configuratela. L’appliance è una macchina virtuale con Windows Server 2012 R2 e sul desktop troverete un link chiamato “Run Collector” che farà partire l’agente di raccolta che si occuperà dell’individuazione delle VM on-premises. L’agente di raccolta raccoglie i metadati delle VM usando cmdlet di VMware PowerCLI. L’individuazione non comporta installazioni nelle VM o negli host VMware e i metadati raccolti includono informazioni sulle VM come numero di core, quantità di memoria, numero di dischi, dimensioni dei dischi e schede di rete. Vengono anche raccolti dati sulle prestazioni delle VM, tra cui utilizzo di CPU e memoria, operazioni di I/O al secondo e velocità effettiva (in MBps) dei dischi e output di rete (in MBps).

Figura 9: Installazione dei prerequisiti del Collector di Azure Migrate

Figura 10: Connessione al vCenter da parte del Collector di Azure Migrate

Dopo aver terminato l’installazione dei prerequisiti ed esservi connessi al VMware vCenter on-premises, inserite il Project ID e la Project Key che sono stati generati durante la creazione del progetto di Azure Migrate e che sono disponibili sul portale di Azure, come mostrato in figura:

Figura 11: Inserimento dei dati del progetto di migrazione

A questo punto comincerà l’individuazione delle vostre macchine virtuali, che potrebbe durare qualche minuto (dipende dal numero delle VM che avete on-premises).

Figura 12: Raccolta delle informazioni da parte del Collector di Azure Migrate

Dopo alcuni minuti, potrete tornare nel portale Azure e visualizzare un messaggio che vi avvisa che l’individuazione delle VM è terminata e che è possibile passare alla seconda fase, quella dell’assessment.

Figura 13: Discover delle VM on-premises completato

Il processo di individuazione può essere ripetuto anche diverse volte, cliccando su Discover
machines e seguendo le istruzioni riportate nel blade, come mostrato in figura:

Figura 14: Ripetizione del processo di individuazione delle VM on-premises

Creazione dell’assessment

Un assessment è un gruppo di macchine virtuali che devono essere migrate insieme. Nel mio caso ho bisogno di migrare una WebApp composta da un database di backend e da due web server di frontend. Dal portale di Azure cliccate quindi sul vostro progetto di migrazione e sul pulsante “Create assessment“. Nella schermata che vi si aprirà date un nome al gruppo di macchine da migrate (nel mio caso l’ho chiamato WebApp) e selezionate le VM da migrare, come mostrato in figura:

Figura 15: Creazione del gruppo di macchine da migrare (assessment)

Cliccando sull’assessment appena creato potrete avere una Overview delle informazioni che sono state raccolte dall’appliance di Azure Migrate. In particolar modo potrete vedere tutte le macchine virtuali che possono essere migrate ad Azure senza problemi ed il loro costo mensile stimato, sia per il computing che per lo storage. Facendo clic su Edit properties avrete anche la possibilità di modificare alcuni parametri, come ad esempio la Region di destinazione ed il tipo di valuta.

Figura 16: Overview dell’assessment

Nella Azure readiness potrete anche avere un dettaglio delle diverse VM da migrare con la dimensione che dovranno avere le rispettive macchine Azure.

Figura 17: Azure readiness delle VM on-premises

Per sapere qual è il modo migliore di migrare le vostre macchine virtuali (che apparirebbe nella colonna SUGGESTED TOOL) è necessario installare un agente nelle VM on-premises. L’agente vi aiuterà anche a valutare le diverse dipendenze tra le VM. Per maggiori informazioni fate riferimento alla pagina https://docs.microsoft.com/it-it/azure/migrate/how-to-create-group-machine-dependencies#prepare-machines-for-dependency-mapping

Figura 18: dettaglio dei costi per ogni singola VM

È anche possibile esportare l’assessment in formato Excel, per avere una reportistica dettagliata, come mostrato in figura:

Figura 19: Esportazione dell’assessment in formato Excel

Migrazione delle macchine virtuali VMware verso Azure

Adesso che avete completato l’individuazione delle VM on-premises e avete valutato il vostro ambiente, siete pronti per migrare verso il Cloud. Per poterlo fare potete utilizzare lo strumento Azure Site Recovery e seguire i passaggi descritti nell’articolo https://www.ictpower.it/guide/protezione-delle-macchine-virtuali-vmware-e-dei-server-fisici-con-azure-site-recovery.htm

Conclusioni

Il servizio Azure Migrate vi permette di individuare le macchine virtuali VMware idonee per la migrazione verso il cloud Azure e vi fornisce degli strumenti di analisi che vi daranno anche la possibilità di stimare i costi di mantenimento della vostra infrastruttura. Se volete esercitarvi con questo nuovo strumento, che per il momento è ancora in Preview, potete utilizzare questo Laboratorio pratico su Azure Migrate. Interessante è anche il video Migrating to Azure using Azure Migrate and Azure Site Recovery – BRK3243 , registrato durante la conferenza Ignite 2017.