Archivi categoria: Microsoft Azure

Migrazione di server fisici verso Microsoft Azure con Azure Site Recovery

Facebooktwittergoogle_plusredditlinkedin

Anche se ormai gran parte delle nostre infrastrutture sono virtualizzate, potrebbe capitare che in alcune aziende ci siano ancora delle macchine fisiche. Azure Site Recovery è una funzionalità offerta da Microsoft Azure per poter effettuare il disaster recovery dei nostri server fisici oppure per poterli definitivamente migrare verso il Cloud.

In questo articolo ci occuperemo della migrazione dei server fisici, ma se siete interessati alla migrazione di macchine virtuali vi invito a leggere l’articolo https://www.ictpower.it/sistemi-operativi/migrazione-di-macchine-virtuali-vmware-verso-microsoft-azure-con-azure-site-recovery.htm e l’articolo https://www.ictpower.it/sistemi-operativi/migrazione-delle-macchine-virtuali-vmware-verso-microsoft-azure-con-lutilizzo-di-azure-migrate.htm

Per eseguire la migrazione di un server fisico è necessario abilitare la replica del server ed eseguirne il failover in Azure.

Creazione del Recovery Service Vault

Il Recovery Service Vault è un servizio di Azure che ospita i dati e le configurazioni delle macchine virtuali. Per sapere nel dettaglio le caratteristiche del servizio 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 1: Creazione di un nuovo Azure Recovery Vault

Terminata la creazione del Vault ne potete visualizzare le caratteristiche utilizzando la scheda Overview. Cliccate sulla scheda Site Recovery e iniziate la preparazione dell’infrastruttura, indicando cosa volete proteggere (Protection Goal). Nel mio caso, visto che voglio proteggere delle macchine fisiche on-premises, ho dichiarato che le macchine non sono virtualizzate, come indicato in figura:

Figura 2: Preparazione del Protection Goal

Nel secondo passaggio vi verrà chiesto di scaricare e testare il Deployment Planner, uno strumento gratuito che vi consente di profilare i vostri server fisici senza alcun impatto sulla produzione e di determinare i requisiti di larghezza di banda e spazio di archiviazione di Azure per le operazioni di replica e failover. Vi consiglio di leggere l’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-deployment-planner per conoscere le potenzialità di questo strumento.

Figura 3: Deployment Planning

Nel passaggio successivo dovrete selezionare il Configuration Server da utilizzare per la replica dei dati della vostra macchina fisica. 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 il Microsoft Azure Site Recovery Unified Setup (sono circa 1,5 GB) e ad installarlo nella vostra infrastruttura in una macchina Windows Server 2012 R2 (va bene anche la versione Evaluation e la macchina può essere anche in workgroup). Seguite tutte le istruzioni indicate nel blade del portale Azure, come mostrato in figura:

Figura 4: Aggiunta del Configuration Server e procedura di installazione

Installazione di Microsoft Azure Site Recovery Unified Setup

L’installazione del software che provvederà a creare il nostro Configuration Server è molto semplice ed è descritta nelle immagini che seguono. Assicuratevi di rispettare i Requisiti di dimensione per un server di configurazione e, dopo aver installato un server con Windows Server 2012 R2, dategli un IP statico e lanciate il setup di configurazione.

Figura 5: Prima schermata di installazione del Configuration Server

Figura 6: Inserimento della Site Recovery Registration Key che avete precedentemente scaricato dal portale di Azure

Figura 7: Verifica dei prerequisiti per l’installazione del Configuration Server

Figura 8: Inserimento della password di root e di svsystems user per il database MySQL

Figura 9: Indicazione che vogliamo proteggere server fisici e non macchine virtuali

Figura 10: Schermata riassuntiva del Setup del Configuration Server

Figura 11: Installazione del Configuration Server completata

A questo punto vi verrà chiesto di riavviare. Terminato il riavvio del server, subito dopo il login, vi apparirà il messaggio che vi indica quale sarà la passphrase da utilizzare per collegare l’agent del Mobility Service al vostro Configuration Server. Il Mobility Service è un servizio che si occupa di trasferire i file generati dal vostro server fisico verso il Configuration Server, che si occuperà poi di inoltrarli Ad Azure Site Recovery. Salvate la passphrase in un file di testo, perché potrebbe esservi richiesta se vorrete installare manualmente l’agent di Azure Site Recovery Mobility Service. In ogni caso è sempre possibile rigenerarla seguendo le indicazioni contenute nell’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-manage-configuration-server

Figura 12: Passpharse per il collegamento degli agent di Azure Site Recovery al Connection Server

Lanciate dal Desktop il collegamento al Cspsconfigtool, che vi darà la possibilità di aggiungere le credenziali per installare il Mobility Service sulle vostre macchine fisiche. Esistono diverse modalità di installazione di questo servizio e per approfondimenti vi rimando alla lettura dell’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-install-mob-svc

Figura 13: Aggiunta dell’account necessario all’installazione del Mobility Service sulle macchine fisiche

Terminata l’installazione del Configuration Server potete tornare nel portale Azure e dal blade dello Step 3 adesso sarà possibile selezionare il server appena installato, come mostrato in figura:

Figura 14: Selezione del Connection Server appena installato

Proseguite con lo Step 4, indicando la Subscription Azure da utilizzare, il Deployment model e assicurandovi di avere uno storage account ed una virtual network dove migrare i vostri server fisici on-premises.

Figura 15: Individuazione del target Azure dove replicare le macchine fisiche on-premises

L’ultimo passaggio di preparazione dell’infrastruttura consiste nella creazione di una Replication Policy da associare al vostro Configuration Server. La Replication Policy stabilisce la frequenza di replica delle vostre macchine fisiche on-premises. Maggiori informazioni sono disponibili al link https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-setup-replication-settings-vmware

Figura 16: Creazione di una Replication Policy da associare al Configuration Server

Verranno create ed associate due Replication Policy: una per il Failover ed un’altra per il Failback, come mostrato in figura:

Figura 17: Creazione ed associazione delle Replication Policy

Completate la preparazione della vostra infrastruttura facendo clic sul pulsante OK.

Figura 18: Completamento della preparazione dell’infrastruttura

Replica dei server fisici

Per dichiarare quali sono i server fisici da replicare con Azure Site Recovery fate clic sulla scheda Step 1: Replicate Application e configurate il Source con i parametri inseriti in figura:

Figura 19: Configurazione del Source per la Replica

Configurate nel secondo passaggio il Target del Recovery, in particolar modo indicando lo Storage Account dove verranno salvati i dati dei server fisici e la rete virtuale dove collegare le macchine replicate in Azure.

Figura 20: Configurazione del Target in Azure Site Recovery

Nel terzo passaggio indicate quali sono i server fisici da replicare in Azure, indicando un nome, l’indirizzo IP e il tipo di sistema operativo, come mostrato in figura:

Figura 21: Scelta dei server fisici da replicare in Azure

Figura 22: Aggiunta dei server fisici da replicare in Azure

Dichiarate quale sarà l’account (che avete precedentemente creato sul Configuration Server) da utilizzare per l’installazione dell’agent di Mobility Service sulle macchine fisiche, e quali dischi del server fisico volete escludere dalla replica, come mostrato in figura:

Figura 23: Configurazione delle proprietà della replica, scelta dell’account per l’installazione del Mobility Service

L’ultimo passaggio vi chiede di confermare quale Replication Policy utilizzare per la replica dei server fisici scelti.

Figura 24: Replication Policy da utilizzare per la replica dei server fisici scelti

Completate lo Step 1: Replicate Application cliccando sul pulsante Enable Replication.

Figura 25; Completamento dello Step 1: Replicate Application e abilitazione della replica

Lo Step 2: Manage Recovery Plans consiste nella creazione di un Recovery Plan (o piano di ripristino), che permette di stabilire quali macchine devono essere avviate ed in quale ordine. Aggiungetene un nuovo Recovery Plan e configuratelo con i parametri richiesti, come mostrato in figura:

Figura 26: Creazione di un nuovo Recovery Plan

A questo punto il Configuration Server installerà il Mobility Service sui server fisici che avete deciso di migrare e abiliterà la replica della macchina. Potete anche installare manualmente il Mobility Service usando la procedura indicata dall’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-install-mob-svc#install-mobility-service-manually-by-using-the-gui. Il file di installazione dell’agent si trova nel percorso C:\ProgramData\ASR\home\svsystems\pushinstallsvc\repository del Configuration Server.

Figura 27: Abilitazione della replica

Dopo circa 20 minuti dall’abilitazione, inizierà la replica dei dati verso Azure Site Recovery. Attendete che tutti i dati siano stati replicati visualizzando la scheda Replicated Items del vostro Azure Site Recovery Vault.

Figura 28: replica dei dati del server fisico completata

Failover Test

Per verificare che tutto funzioni correttamente è necessario testare il Failover della macchina virtuale presente in Azure. Cliccando su Replicated Items nel Recovery Service Vault dal portale di Azure, selezionate la macchina virtuale da testare e dal menù scegliete Test Failover, come mostrato in figura:

Figura 29: Test failover della macchina virtuale in Azure

Nel blade che vi si aprirà scegliete il Recovery Point da testare e la rete virtuale a cui collegare la VM di test. Cliccate su OK e attendete alcuni minuti fino a quando la VM di test non sarà stata creata.

Figura 30: Scelta del Recovery Point e della rete virtuale per il test del Failover

Collegatevi alla VM di test che è stata creata in Azure ed effettuate tutte le verifiche che ritenete necessarie per assicurarvi che la vostra macchina abbia tutti i dati e che funzioni correttamente. Al termine di tutte le procedure di controllo, sarà possibile effettuare il Cleanup test failover, che distruggerà la VM Azure di test che è stata creata.

Figura 31: Test failover Cleanup

Cliccando su Replicated Items nel Recovery Service Vault dal portale di Azure è possibile configurare le proprietà della macchina replicata. Potete scegliere il nome che verrà visualizzato in Azure, il Resource Group dove metterla, la dimensione della VM, la virtual network ed anche dargli un IP statico. Nel caso ne abbiate i diritti, attivate l’Hybrid Use Benefit, che vi permette un risparmio considerevole sulle licenze del sistema operativo. Maggiori informazioni sull’Hybrid Use benefit le trovate leggendo l’articolo https://docs.microsoft.com/it-it/azure/virtual-machines/windows/hybrid-use-benefit-licensing

Figura 32: Configurazione dei parametri della VM

Migrazione della macchina fisica in Azure

Per completare la migrazione della macchina fisica è necessario effettuare due passaggi: Failover e Complete Migration. Prima di eseguire un failover, eseguite sempre un failover di test per verificare che tutto funzioni come previsto. Maggiori dettagli sono disponibili leggendo l’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-failover

Figura 33: Failover della macchina fisica

Terminata la procedura di Failover ed dopo esservi accertati che tutto funzioni perfettamente, potete effettuare la procedura di Complete Migration. Il processo di migrazione viene completato, viene arrestata la replica della macchina virtuale e viene arrestata la fatturazione di Site Recovery per la macchina virtuale. D’ora in poi pagherete però l’esecuzione delle VM in Azure.

Figura 34: Completamento della migrazione

Conclusioni

Migrare i server fisici verso Azure è un’operazione molto semplice se viene effettuata con Azure Site Recovery. Per eseguire la migrazione di un server è sufficiente abilitare la replica del server ed eseguirne il failover in Azure. In questo modo l’intera macchina, con tutti i dati, viene migrata con un minimo downtime e senza impatto sull’infrastruttura e sulla produzione. Migrare i server fisici verso il Cloud non è mai stato così facile!

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.

PowerShell Core 6.0: una nuova era ha inizio

Facebooktwittergoogle_plusredditlinkedin

Da qualche giorno è disponibile una nuova versione di Windows PowerShell, giunta ormai alla sesta versione. La grande novità risiede nell’introduzione della versione Core, che ha l’obiettivo di portare l’utilizzo della shell Microsoft su tutti […]

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.

Gestire l’accesso alle macchine virtuali in Microsoft Azure con la funzionalità JIT (Just-in-Time)

Facebooktwittergoogle_plusredditlinkedin

Mai come in questo periodo il tema della sicurezza informatica sta monopolizzando gli articoli e gli avvisi che ci arrivano dai diversi vendor hardware e software e gli attacchi si stanno non solo evolvendo come complessità, ma soprattutto stanno aumentando. Difendersi dagli attacchi è sempre impegnativo e non bisogna mai sottovalutare nulla, ma io sono dell’idea che prevenire sia meglio che curare e quindi nell’approccio alla sicurezza la cosa più importante è ridurre la superficie di attacco.

Avevo già parlato in un precedente articolo di una funzionalità di sicurezza introdotta in Windows Server 2016 e chiamata Just Enough Administration (JEA), che ha come scopo quello di aumentare la sicurezza nella gestione e nella delega dei privilegi in Windows Server. In questo articolo invece vi parlo di una funzionalità di Microsoft Azure, attualmente in PREVIEW e che si chiama Just in time VM Access, che può essere usata per bloccare il traffico in ingresso verso le porte dei protocolli di amministrazione (RDP per Windows oppure SSH per Linux) delle macchine virtuali di Azure, riducendo l’esposizione agli attacchi.

Figura 1: Attivazione della funzionalità di Just in time VM Access in Azure Security Center

Questo tipo di funzionalità non è pero disponibile gratuitamente e fa parte del piano Standard del Centro Sicurezza di Azure (Security Center), che offre la gestione unificata della sicurezza e la protezione avanzata dalle minacce per tutti i workload in esecuzione in Azure, in locale nella propria rete aziendale e in altri cloud. È possibile aggiornare tutta la sottoscrizione di Azure al piano Standard, che viene ereditato da tutte le risorse all’interno della sottoscrizione oppure è possibile aggiornare a un solo gruppo specifico di risorse (Resource Group). Per poterlo fare è sufficiente modificare la Security Policy del Security Center come mostrato in figura:

Figura 2: Modifica delle Security Policy e del Pricing Tier in Azure Security Center

Nel momento in cui attivate la funzionalità di Just in time VM Access, Il Security Center protegge il traffico in ingresso verso le macchine virtuali creando una regola nel Network Security Group (NSG) utilizzato dalle schede di rete della VM, che blocca le porte di gestione. Quando avrete necessità di accedere in modalità amministrativa alla VM, vi basterà richiedere l’accesso e indicare per quanto tempo necessitate di amministrare la macchina. Il Security Center provvederà a modificare le regole sul Netowrk Security Group consentendo il traffico in entrata verso le porte di gestione per il periodo di tempo specificato. Al termine di questo periodo, il Security Center ripristinerà le regole preesistenti.

Attivazione del Just in time VM Access

La prima volta che vorrete usare la funzionalità di Just in time VM Access vi verrà chiesto di attivare (in prova gratuita per i primi 60 giorni) il piano Standard, come mostrato in figura:

Figura 3: Attivazione del Piano Standard per Azure Security Center

Una volta che avrete attivato il piano Standard potrete tornare nella console del Just in time VM access e visualizzare le informazioni per ogni macchina virtuale, divise in 3 categorie:

  • Configured – Macchine virtuali che sono state configurate per supportare l’accesso Just-In-Time. I dati visualizzati sono relativi all’ultima settimana e includono, per ogni macchina virtuale, il numero di richieste approvate, la data dell’ultimo accesso e l’ultimo utente che ha effettuato l’accesso.
  • Recommended – Macchine virtuali che possono supportare l’accesso Just-In-Time, ma che non sono state ancora configurate.
  • No Recommandation – I motivi per cui una macchina virtuale può risultare non raccomandata sono:
    • Network Security Group mancante – La soluzione Just-In-Time richiede la presenza di un gruppo di sicurezza di rete.
    • Macchina virtuale classica – L’accesso Just-in-Time alle macchine virtuali attualmente supporta solo VM distribuite tramite Azure Resource Manager.
    • Endpoint Protection non installato – Il Centro sicurezza di Azure monitora lo stato della protezione antimalware e verifica che nella VM sia installato Endpoint Protection

Figura 4: Macchine virtuali su cui non può essere abilitata il Just in time VM access

Per abilitare la funzionalità è sufficiente selezionare la VM, cliccare sul pulsante Enable JIT on VM e nel blade che si apre cliccare su Save, come mostrato in figura:

Figura 5: Abilitazione della funzionalità di Just in time VM access

Richiedere l’accesso a una macchina virtuale

Per richiedere l’accesso ad una macchina virtuale è sufficiente selezionare la VM nella scheda Configured e cliccare sul pulsante Request Access. Nel blade che verrà aperto definite quale porta aprire, a quali indirizzi IP permettere la connessione, per quanto tempo permettere la connessione. Al termine della scelta dei criteri cliccate sul pulsante Open Ports, come mostrato in figura:

Figura 6: richiesta di apertura delle porte di amministrazione

In qualsiasi momento potete modificare la configurazione dell’accesso JIT alla VM, visualizzarne le proprietà e i log delle attività, come mostrato in figura:

Figura 7: Modifica della configurazione dell’accesso JIT alla VM

È sempre possibile aggiungere altre porte alla configurazione dell’accesso JIT alla VM e per ognuna di loro stabilirne anche la durata, che in ogni caso non potrà superare le 24 ore.

Figura 8: Aggiunta di una nuova regola alla configurazione dell’accesso JIT alla VM

Visualizzando la scheda Networking della macchina virtuale potrete visualizzare quali regole sono state applicate al Network Security Group della VM. Sono state inserire le regole di SecurityCenter-JIT che hanno una priorità più bassa e quindi hanno precedenza rispetto alle altre regole create.

Figura 9: Regole di SecurityCenter-JIT applicate al Network Security Group della VM

Conclusioni

La semplicità con cui è possibile configurare l’accesso Just in Time alle VM di Azure permette di poter ridurre drasticamente la superfice d’attacco verso le VM esposte, come ad esempio le Jump Box con IP pubblico, ed impedisce di fatto tutti gli attacchi verso il Desktop Remoto o verso Secure Shell che cercano di indovinare le credenziali amministrative. Un modo semplice ed efficace per proteggerci e per mitigare gli attacchi di forza bruta aprendo le porte solo durante la connessione per eseguire attività di gestione o manutenzione sulle VM.

Creare un Azure Container Service (ACS) con un Kubernetes cluster

Facebooktwittergoogle_plusredditlinkedin

Abbiamo già visto in diversi articoli apparsi su questo sito che l’utilizzo dei container ci permette di migliorare l’utilizzo delle macchine virtuali sia on-premises che nel Cloud. Tuttavia, per migliorare l’affidabilità e la scalabilità, è necessario far girare decine se non migliaia di container utilizzando diversi Host. Azure Container Service, servendosi di diversi tipi di container orchestrator open source come Docker Swarm, Kubernetes e Marathon di Mesosphere’s DC/OS, permette di semplificare tantissimo la gestione dei container cluster.

In questo articolo analizzeremo l’uso di Kubernetes e della sua implementazione in Azure.

Introduzione

Azure Container Service (ACS) permette di gestire cluster di diversi Docker Hosts, dandoci la possibilità di scalare le nostre applicazioni gestendo decine di migliaia di container grazie anche ad orchestrator come Kubernetes.

Google ha rilasciato Kubernetes nel Febbraio 2015 proprio con lo scopo di orchestrare i container Docker. A Marzo 2016 ha reso il codice open source, donandolo alla Cloud Native Computing Foundation (CNCF) e impegnandosi al suo continuo sviluppo. Fin dall’inizio il software ha riscosso parecchio successo tra gli sviluppatori grazie alle numerose funzionalità che supporta.

Creazione di un cluster Kubernetes utilizzando Azure Container Service

Per creare un cluster Kubernetes in Azure è possibile utilizzare il portale web, un template di Azure Resource Manager oppure Azure CLI 2.0. In alternativa è anche possibile utilizzare un progetto open source presente su Github chiamato acs-engine per definire il cluster e per poterlo creare utilizzando Azure CLI 2.0.

Il modo più veloce per creare un cluster container su Azure è l’utilizzo della Azure Cloud Shell, una shell interattiva accessibile dal browser che permette di gestire le risorse di Azure. Gli utenti Linux possono scegliere di utilizzare Bash, mentre gli utenti Windows possono scegliere di utilizzare PowerShell. È possibile lanciare la Azure Cloud Shell direttamente dal portale di Azure, come mostrato in figura:

Figura 1: Lancio della Azure Cloud Shell dal portale

Quando lanciate la Azure Cloud Shell dal portale di Microsoft Azure la prima volta vi verrà chiesto di creare un gruppo di risorse, un account di archiviazione e una condivisione file (Azure file share). Scegliete di utilizzare Bash (Linux).

Figura 2: Primo lancio della Azure Cloud Shell con la richiesta di creazione dello storage account

Dopo aver creato uno storage account con ridondanza locale (LRS), a cui vengono applicati i normali costi di esercizio, verrà creata una Azure file share, che utilizzeremo sia per gli ambienti Bash che PowerShell.

Figura 3: Avvio della Azure Cloud Shell con Bash

Nella Azure Cloud Shell sono preinstallati i più diffusi strumenti da riga di comando, compreso Azure CLI 2.0, che utilizzeremo per creare l’Azure Container Service. Per prima cosa creiamo un Resource Group con il comando

az group create --name ACS-LabRG --location westeurope

e successivamente creiamo un nuovo servizio di Azure Container Service con orchestrator Kubernetes lanciando il comando

az acs create --orchestrator-type kubernetes --resource-group ACS-LabRG --name ACS-k8scluster --generate-ssh-keys

Figura 4: Creazione del nuovo Azure Container Service

Figura 5: Oggetti creati per l’Azure Container Service

Dopo aver atteso la creazione del nuovo Azure Container Service (che durerà alcuni minuti) possiamo scaricare e configurare le credenziali per accedere all’ACS Kubernetes cluster lanciando il comando

az acs kubernetes get-credentials --resource-group ACS-LabRG --name ACS-k8scluster

Le credenziali verranno salvate nello storage account utilizzato da Azure Cloud Shell.

Figura 6: Download delle credenziali per accedere al cluster ACS

Per verificare la connettività all’ACS Kubernetes Cluster vi basterà eseguire il comando:

kubectl get nodes

e verificare che tutti gli agent nodes siano Ready, come mostrato in figura:

Figura 7: Verifica della creazione e dello stato dei nodi del cluster

Distribuzione di un’applicazione nel cluster ACS Kubernetes

Per testare il nostro cluster distribuiremo un container con nginx, prendendolo dal Docker Hub. Lanciamo il comando

kubectl run nginx-lab --image=nginx --replicas=1 --port=80

e verifichiamo che il pod Kubernetes sia stato creato utilizzando il comando

kubectl get pods

Per identificare lo stato del deployment utilizziamo invece il comando

kubectl get deployment

Figura 8: Verifica dello stato del deployment

Per rendere il pod disponibile dall’esterno dovremo però prima esporlo con il comando

kubectl expose deployment nginx-lab --port=80 --type=LoadBalancer

Dopo qualche minuto, il servizio verrà esposto e potremo connetterci. Per individuare l’indirizzo IP pubblico utilizzato possiamo lanciare il comando

kubectl get services

Se la colonna relativa all’EXTERNAL-IP vi indica Pending, aspettate qualche minuto (nel mio caso ci sono voluti circa 5 minuti) e ripetete il comando.

Figura 9: Indirizzo IP pubblico del cluster

Collegatevi all’indirizzo IP ottenuto ed il vostro container NGINX vi farà apparire la pagina di benvenuto.

Figura 10: Pagina di benvenuto del container

Gestione di un’applicazione nel cluster ACS Kubernetes

Dopo aver creato la prima istanza del nostro deployment, possiamo scalarla facilmente utilizzando il comando

kubectl scale --replicas=2 deployment/nginx-lab

ed esattamente come prima, per verificare la buona riuscita, lanciamo il comando

kubectl get pods

Figura 11: Creazione dello scaling completato

Come potete vedere adesso ci sono due istanze che fanno girare il container nginx.

Con la stessa rapidità con cui è stato scalato è anche possibile cancellare il deployment con il comando

kubectl delete deployment nginx-lab

e verificare con il comando

kubectl get deployment

Figura 12: Cancellazione del Deployment

Conclusioni

I Docker Container di fatto ottimizzano il deployment delle nostre applicazioni e le rendono trasportabili. È necessario però fare in modo che gli Host che ospitano i container siano affidabili e scalabili. Una soluzione di orchestation è quindi necessaria per il corretto funzionamento ma soprattutto per la facilità e rapidità di utilizzo. Kubernetes insieme a Azure Container Service è senza dubbio una soluzione semplice da implementare ed altamente scalabile.

Microsoft ha anche annunciato da un paio di giorni la preview di AKS (Azure Container Service). Per maggiori info visualizzate l’articolo Introducing AKS (managed Kubernetes) and Azure Container Registry improvements