Archivi categoria: azure resource manager

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.

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

Utilizzare Docker Machine per creare hosts in Microsoft Azure

Facebooktwittergoogle_plusredditlinkedin

In questo articolo vedremo come creare delle macchine virtuali in Microsoft Azure da utilizzare come Hosts per i container Docker.

Esistono diversi modi per poterlo fare, ma certamente avere un automatismo che mi crei la macchina virtuale e mi installi Docker semplifica di molto il lavoro.

Il comando che permette di creare automaticamente la macchina virtuale da usare come host è docker-machine. Potrete trovare un esauriente articolo alla pagina https://docs.docker.com/machine/, che vi darà un’idea dei comandi da utilizzare.

Il comando docker-machine create creerà per voi l’host per i container, in base ai driver che gli indicherete. I driver https://docs.docker.com/machine/drivers/ rappresentano le piattaforme che possono ospitare il nostro host. Attualmente sono disponibili i seguenti driver:

Creazione tramite Azure Cloud Shell

Il modo più veloce per creare un host container su Azure è l’utilizzo della Azure Cloud Shell. 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 per 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

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

Figura 3: Creazione di Azure Cloud Shell completata

Nella Azure Cloud Shell sono preinstallati i più diffusi strumenti da riga di comando. Quindi non abbiamo bisogno di installare nulla e per lanciare la creazione di una nuova macchina virtuale host ci basterà utilizzare il comando:

docker-machine create -d azure –azure-subscription-id “id_della_vostra_sottoscrizione” –azure-ssh-user ictpower –azure-open-port 80 –azure-size “Standard_D2_v2” dockervm00

Dopo aver lanciato il comando verrà creata una VM chiamata dockervm00 che utilizzerà come sistema operativo Ubuntu 16.04 LTS, in cui verrà installato Docker. Tramite il comando abbiamo anche indicato di rendere disponibile la porta 80 (che verrà aperta nel Network Security Group) e abbiamo scelto di usare per l’autenticazione tramite SSH un utente chiamato ictpower.

Al momento del lancio del comando vi verrà chiesto di autenticarvi, collegandovi al link https://aka.ms/devicelogin ed inserendo il codice monouso visualizzato nella console.

Figura 4: Inserimento del codice monouso nella pagina di autenticazione https://aka.ms/devicelogin

Figura 5: Autenticazione con il proprio account al tenant Azure

Figura 6: Dopo aver completato l’accesso viene richiesta l’autorizzazione al login da parte di Docker Machine for Azure

Figura 7: Autenticazione e Autorizzazione completata

Dopo aver completato la procedura di login ed aver autorizzato Docker Machine for Azure, la creazione della macchina virtuale (resource group, storage account, vnet, public ip, ecc.) procede in autonomia, come mostrato in figura:

Figura 8: Creazione della VM host per i container

Dopo pochi minuti la macchina sarà pronta e sarà possibile cominciare ad utilizzare i container con Docker.

Creazione tramite l’applicazione Docker for Windows

Una maniera alternativa che è possibile utilizzare per la creazione dell’host che ospiterà i nostri container è l’utilizzo dell’applicazione Docker for Windows, che possiamo installare in una macchina locale (io ho usato una macchina con Windows 10), da cui poi lanceremo i comandi per la creazione della VM host su Azure. L’applicazione Docker for Windows, scaricabile dal link https://docs.docker.com/docker-for-windows/install/, è un pacchetto che contiene tutto il necessario per eseguire Docker su un sistema operativo Windows, compresi i tool di gestione a riga di comando.

Figura 9: Installazione dell’applicazione Docker for Windows

Figura 10: Installazione di Docker for Windows completata

Io ho installato l’applicazione su una macchina Windows 10, su cui non ho installato Hyper-V. Lanciando l’applicazione ho ricevuto un messaggio di errore che mi invita ad abilitare il ruolo di Hyper-V, come mostrato in figura. Per l’obiettivo che vogliamo raggiungere non è un’operazione necessaria, in quanto al momento mi interessano solo i tool di gestione a riga di comando.

Figura 11: Messaggio di avviso dell’applicazione Docker for Windows che segnala l’assenza di Hyper-V

Da un Command Prompt con privilegi elevati lanciate lo stesso comando che vi ho mostrato prima e che provvederà a creare la VM chiamata dockervm00

docker-machine create -d azure –azure-subscription-id “id_della_vostra_sottoscrizione” –azure-ssh-user ictpower –azure-open-port 80 –azure-size “Standard_D2_v2” –azure-location westeurope dockervm00

Figura 12: Lancio del comando Docker-machine create

Al momento del lancio del comando vi verrà chiesto di autenticarvi, collegandovi al link https://aka.ms/devicelogin ed inserendo il codice monouso visualizzato nella console.

Figura 13: Login dell’applicazione Docker Machine for Windows con un codice monouso

Figura 14: Autenticazione al tenant di Azure

Figura 15: Autenticazione dell’applicazione Docker for Windows completata

Dopo l’autenticazione viene creata la macchina virtuale con Ubuntu 16.04 LTS e viene installato automaticamente il Docker Engine, che utilizzeremo per far girare i nostri container, come mostrato in figura:

Figura 16: Creazione della VM host completata

Lanciando il comando docker-machine ls ci verrà mostrata la VM che è stata creata, l’indirizzo IP che è stato assegnato alla VM e lo stato della VM, come mostrato in figura:

Figura 17: Informazioni sullo stato della VM host creata su Azure

Durante il processo di provisioning della macchina virtuale, Docker Machine crea un certificato self-signed che verrà utilizzatoper creare una sessione SSH sicura verso il Docker host. La chiave privata del certificato verrà conservata nel profilo dell’utente. Questo permette di creare e gestire i Docker container dallo stesso computer da cui avete effettuato il Docker Host deployment. Per semplificare la gestione dell’Host e per creare i container è sufficiente configurare le variabili d’ambiente aprendo una console di PowerShell con privilegi elevati e lanciando il comando

docker-machine env dockervm00 Invoke-Expression

Adesso che abbiamo configurato l’host, possiamo provare ad eseguire un webserver (nel nostro caso nginx) per testare il suo corretto funzionamento. Eseguiamo quindi un container che usa un’immagine con il webserver nginx, che sia in ascolto sulla porta 80 e che se l’host si riavvia riparta in automatico (–restart=always), lanciando il comando:

docker run -d -p 80:80 –restart=always nginx

Figura 18: Esecuzione del container di test con il webserver nginx

Per collegarci al container appena creato possiamo procurarci il suo indirizzo IP anche con il comando
docker-machine ip dockervm00
e da un browser verificare se il webserver è funzionante e raggiungibile.

Figura 19: Verifica dell’esecuzione del container

Conclusioni

Indipendentemente dal metodo utilizzato, sia con la Azure Cloud Shell che con i tool dell’applicazione Docker for Windows, la creazione di un host su Azure per ospitare i nostri container è un’operazione molto semplice che ci dà un’idea dell’enorme flessibilità offerta sia dal Cloud che dalla tecnologia alla base dei container stessi.

Configurare Microsoft Azure File Sync (preview)

Facebooktwittergoogle_plusredditlinkedin

Con Azure File Sync (preview) è possibile sincronizzare una cartella di rete condivisa su un file server locale con una File Share creata in uno Storage Account di Microsoft Azure. Questo tipo di soluzione permette quindi di poter avere i file nel Cloud e di poterli sincronizzare in modalità multi-master con differenti file server, anche nei nostri uffici remoti.

Figura 1: Servizi offerti da Azure File Sync

Figura 2: Scenari di utilizzo di Azure File Sync

Grazie alla possibilità di creare dei Sync Groups, è possibile decidere quali cartelle sincronizzare tra il Cloud e i nostri server on-premises e questo tipo di sincronizzazione avviene in tempo reale! Azure File Sync potrebbe anche essere utilizzato come soluzione di Disaster Recovery, in quanto i file sono presenti sul Cloud e sono disponibili da tutti i nostri file server.

Figura 3: Principio di funzionamento di Azure File Sync

Creazione dello Strorage Sync

Per cominciare potete loggarvi al portale di Azure e dal pulsante Nuovo (quello col simbolo +) cliccate su Storage e successivamente su Azure File Sync (preview), come mostrato in figura:

Figura 4: Scelta di Azure File Sync dal Microsoft Azure Marketplece

Nel blade che si apre inserite le informazioni richieste per poter effettuare il deploy della nuova Storage Sync (Nome, Sottoscrizione, Resource Group e Location), come mostrato in figura:

Figura 5: Deploy della nuova Storage Sync

Una volta che avete effettuato il deploy della nuova Storage Sync, che dura pochi secondi, dovrete registrare il file server che volete sincronizzare. Spostandovi nelle configurazioni e scegliendo Registrered Server dovete scaricare l’Azure Storage Sync client, come mostrato in figura:

Figura 6: Registrazione dei server da sincronizzare

Installazione dell’agent di Azure File Sync

Verrete a questo punto reindirizzati alla pagina di download dell’agent, che è disponibile sia per Windows Server 2012 R2 che per Windows Server 2016. Scegliete quindi la versione corrispondente alla versione del sistema operativo del vostro file server e scaricate l’agent.

Figura 7: Scelta dell’agent di sincronizzazione

Terminato il download procedete con l’installazione dell’agent, seguendo il wizard, come mostrato nelle figure sotto:

Figura 8: Schermata iniziale del setup dell’agent

Figura 9: Accettazione dei termini di licenza

Figura 10: Scelta della cartella di installazione dell’agent

Figura 11: Conferma dell’installazione

Figura 12: Installazione dei prerequisiti di Windows per il funzionamento dell’agent

Figura 13: Configurazione dei prerequisiti richiesti dall’agent

Al termine dell’installazione vi apparirà una finestra che vi chiederà di effettuare la registrazione del server. Nel caso riceveste un errore come quello mostrato in figura vorrà dire che sul vostro file server non è disponibile il modelo PowerShell di Azure RM, necessario al corretto funzionamento e alla configurazione dell’agent.

Figura 14: Mancanza del modulo PowerShell AzureRM

Procedete a questo punto all’installazione del modulo PowerShell mancante. Aprite una finestra di PowerShell con privilegi elevati e digitate il comando Install-AzureRM, come mostrato in figura:

Figura 15: Installazione del modulo PowerShell AzureRM

Dopo l’installazione del modulo sarà possibile cliccare su Retry nella finestra di Azure File Sync e potrete procedere al login al vostro Tenant Azure, come mostrato in figura:

Figura 16: Login al tenant Azure necessario alla Server registration

Dopo aver effettuato il login potrete inserire le informazioni relative alla Sottoscrizione, al Resource Group e allo Storage Sync Service che avete precedentemente creato e che avete scelto di utilizzare per la sincronizzazione dei vostri dati.

Figura 17: Scelta dello Storage Sync Service, precedentemente creato nel portale Azure

Figura 18: Registrazione allo Storage Sync Service completata

Dal portale di Azure sarà possibile verificare che il vostro server sia registrato e che l’agent funzioni correttamente, come mostrato in figura:

Figura 19: Verifica della corretta installazione dell’agent dal portale di Azure

Creazione di uno Storage Account

Per poter sincronizzare i file utilizzando Azure File Sync sarà necessario avere uno Storage Account ed una cartella condivisa (Azure File Share). Potete utilizzare qualsiasi storage account presente nella stessa Region dove avete attivato il servizio, ma nel caso voleste utilizzare uno storage account dedicato potete crearlo anche adesso.

Figura 20: Creazione di un nuovo Storage Account

Figura 21: Creazione di una file Share nello Storage Account creato

Creazione del Sync Group

Un Sync Group è formato da due Endpoint: un Cloud Endpoint (una File Share contenuta in uno Storage Account) ed un Server Endpoint (un file server on-premises che vogliamo sincronizzare). Nel blade del vostro Azure File Sync selezionate Sync Groups e scegliete quale Storage Account e quale Azure File Share utilizzare per il Cloud Endpoint, come mostrato in figura:

Figura 22: Creazione del nuovo Sync Group e scelta della Azure File Share

A questo punto non vi resta che aggiungere il Server Endpoint. Cliccando sul pulsante Add server Endpoint potrete aggiungere la cartella del vostro Registered Server che volete sincronizzare e scegliere se abilitare il Cloud Tiering, scegliendo la percentuale di spazio libero che deve rimanere sul server. Il Cloud Tiering sposta i file più vecchi e meno acceduti sul Cloud e permette quindi di gestire al meglio lo spazio disco dei vostri server on-premises.

Figura 23: scelta del Registered Serve e della cartella da sincronizzare

Da questo momento comincerà automaticamente l’upload di tutti i file contenuti nella cartella che avete scelto.

Figura 24: Provisioning del Server Endpoint

Terminata la sincronizzazione potete verificare all’interno dello Storage Account che tutti i file contenuti nella cartella del vostro file server sono stati sincronizzati.

Figura 25: Verifica che tutti i file sono stati caricati nello Storage Account

Conclusioni

Diversi sono gli scenari di utilizzo di Azure File Sync. Sicuramente quello che è più evidente è la possibilità di tenere sincronizzati i file tra diversi file server e con il cloud. Il Cloud Tiering permette anche di liberare i file server on-premises dei file meno acceduti (cold data) e di tenerli solo nello Storage Account in Azure. Nel momento in cui devono essere acceduti vengono poi scaricati automaticamente. Nell’ottica di uno scenario di Disaster Recovery Azure File Sync offre una soluzione pratica e veloce per poter tornare ad utilizzare i propri file senza downtime.

Configurare i filtri in Azure AD Connect

Facebooktwittergoogle_plusredditlinkedin

Azure AD Connect è lo strumento che permette di integrare Active Directory con Azure Active Directory e connettere gli utenti a Office 365, in modo tale che possano utilizzare i servizi cloud con la stessa identità che usano oggi per accedere alle proprie postazioni di lavoro ed ai software aziendali.

Figura 1: Principio di funzionamento di Azure AD Connect

Per l’installazione di Azure AD Connect potete leggere l’articolo https://azure.microsoft.com/it-it/documentation/articles/active-directory-aadconnect/

Azure AD Connect include numerose funzionalità che è possibile abilitare:

  • Filtri
  • Sincronizzazione delle password
  • Writeback delle password
  • Writeback dei dispositivi
  • Aggiornamento automatico del software

In questo articolo voglio mostrarvi come poter applicare uno o più filtri per limitare gli oggetti da sincronizzare tra la vostra directory on-premise ed Azure AD. Tutti gli utenti, i contatti, i gruppi e i computer Windows 10 sono sincronizzati per default, ma è possibile limitare gli oggetti sincronizzati in base ai domini, alle unità organizzative o agli attributi di Active Directory.

I motivi per cui potrebbe essere necessario impostare un filtro sono diversi:

  • Creazione di un POC (proof of concept) con solo alcuni utenti del dominio
  • Non tutti gli account del dominio devono avere accesso ad Office 365
  • Ci sono utenti disabilitati che non volete siano presenti online in Azure AD.

Ci sono diversi modi per applicare un filtro con Azure AD Connect ed il filtro può essere applicato in qualsiasi momento.

È importante ricordare che tutti gli oggetti che poi rimuoverete con il filtro verranno anche rimossi da Azure AD (e spostati nel cestino)! Nel cestino poi rimarranno per 60 giorni e potranno essere ripristinati.

Nel caso rimuoviate un utente per sbaglio sarà possibile modificare il filtro di Azure AD Connect e risincronizzare la vostra directory on-premise con Azure AD. Questo permetterà di ripristinare l’utente dal cestino di Azure AD. Non sarà possibile però ripristinare gli altri oggetti, come ad esempio i gruppi.

Creazione dei filtri utilizzando il Synchronization Rule Editor

In questo articolo considererò già installato Azure AD Connect e vi mostrerò come modificare i filtri dopo aver effettuato l’installazione.

Attualmente io sto utilizzando la versione 1.1.614.0 di Azure AD Connect rilasciata il 5 Settembre 2017. Per una lista di tutte le versioni di Azure AD potete consultare la pagina Azure AD Connect: Cronologia delle versioni

Lanciate Azure AD Connect e scegliete di modificare le impostazioni di sincronizzazione. Una volta lanciato il wizard vi verrà richiesto di autenticarvi ad Office 365 (usate un Global Administrator del vostro Tenant) e di autenticarvi alla vostra foresta (usate un Enterprise Admin).

É possibile scegliere di filtrare solo alcune unità organizzative (OU). Nel mio caso ho deciso di sincronizzare solo gli oggetti contenuti nella OU che si chiama Office 365, come mostrato in figura:

Figura 2: Filtro applicato ad una organization unit

Se voleste filtrare solo alcuni gruppi, l’operazione può essere fatta solo durante il wizard iniziale, come mostrato in figura. Vedremo poi come modificare la scelta successivamente.

Figura 3: I Filtri ai gruppi effettuati durante il wizard iniziale

Filtri basati sugli attributi di AD

È possibile filtrare gli utenti in base ad alcuni attributi di Active Directory. Supponiamo infatti che non possiate modificare le Organizational Unit e spostarvi all’interno gli utenti; possiamo popolare alcuni attributi in Active Directory on-premise e poi decidere di sincronizzare solo gli utenti che possiedono l’attributo scelto.

Supponiamo di voler sincronizzare tutti gli utenti di dominio il cui attributo extensionAttribute1 sia “Office365”. Dalla console Active Directory Users and Computer popoliamo l’attributo usando l’attribute editor, come mostrato in figura:

Figura 4: Modifica dell’attributo ExtensionAttribute1 nelle proprietà dell’utente in AD

Per permettere la sincronizzazione dei soli utenti che possiedono quell’attributo è possibile usare il Synchronization Rule Editor di Azure AD Connect che potete lanciare dal menù di avvio.

Figura 5: Synchronization Rule Editor

Cliccando sul pulsante Add New Rule parte il wizard di configurazione. I filtri possono essere applicati sia in INBOUND da Active Directory verso il metaverse che in OUTBOUND dal metaverse verso Azure AD. È consigliabile applicare il filtro in INBOUND perché è il più semplice da gestire.

Creiamo quindi un filtro INBOUND popolando le informazioni richieste, come mostrato in figura:

Figura 6:Inbound synchronization rule

Nella schermata successiva applichiamo il filtro vero e proprio, cliccando su Add Group e aggiungendo una Clause, come mostrato in figura. Un gruppo può contenere una o più clausole ed è possibile utilizzare gli operatori logici AND e OR.

Figura 7: Creazione della clausola con la scelta dell’attributo da filtrare

Proseguiamo nel wizard di configurazione lasciando vuote le Join Rules e nella schermata relativa alle Transformation fate clic su Add Transformation, impostate FlowType su Constant, selezionare l’attributo di destinazione cloudFiltered e nella casella di testo Source digitate False. Fate clic su Add per salvare la regola.

Figura 8: Applicazione delle Transformations

Per completare il filtro però è necessario creare una ulteriore regola di Inboud di sincronizzazione catch-all. Lanciate nuovamente il wizard e compilate i campi come mostrato in figura:

Figura 9: Creazione della regola di Catch-All

Lasciate vuoto Scoping filter e fate clic su Next. Un filtro vuoto indica che la regola deve essere applicata a tutti gli oggetti. Lasciate vuote le Join Rules e quindi fare clic su Next. Fate clic su Add Transformation, impostare FlowType su Constant, selezionare l’attributo di destinazione cloudFiltered e nella casella di testo Source digitare True. Fare clic su Add per salvare la regola, come mostrato in figura:

Applicare e verificare le modifiche

Dopo avere apportato le modifiche alla configurazione è necessario applicarle agli oggetti già presenti in Azure AD. Se la configurazione è stata modificata usando il filtro basato su attributo, è necessario eseguire la sincronizzazione completa.

Per effettuare la sincronizzazione avete due possibilità:

  1. Aprite un prompt dei comandi, spostatevi nella directory C:\Program Files\Microsoft Azure AD Sync\bin e lanciate DirectorySyncClientCmd.exe
  2. Aprite Powershell e usate la cmdlet Start-ADSyncSyncCycle -Policytype Initial

Per maggiori approfondimenti sull’utilità di pianificazione di Azure AD Connect vi rimando all’articolo https://azure.microsoft.com/it-it/documentation/articles/active-directory-aadconnectsync-feature-scheduler/

Conclusioni

Con i filtri è possibile controllare quali oggetti della directory locale volete sincronizzare in Azure AD, in modo tale da modificare la configurazione predefinita, che replica tutti gli oggetti. Basta modificare un attributo degli utenti da replicare su Azure AD (e quindi anche su Office 365) per avere un controllo più granulare di ciò che volete sia presente nel database di Azure AD.