Archivi categoria: Microsoft Azure

Azure Site Recovery: il disaster recovery di macchine virtuali VMware

La soluzione Azure Site Recovery (ASR) consente di proteggere sistemi fisici oppure virtuali, ospitati sia in ambiente Hyper-V che VMware, automatizzando il processo di replica verso un datacenter secondario oppure verso Microsoft Azure. Con un’unica soluzione è possibile implementare piani di Disaster Recovery per ambienti eterogenei orchestrando in modo funzionale il processo di replica e le azioni necessarie per il corretto ripristino. Grazie a questa soluzione il proprio piano di DR sarà facilmente usufruibile in qualsiasi evenienza, anche la più remota, per garantire la business continuity. Recentemente la soluzione è stata ampliata prevedendo anche la possibilità di implementare una strategia di disaster recovery per macchine virtuali in Azure, consentendo di attivare la replica tra differenti region.

In questo articolo verrà mostrato come ASR può essere utilizzato per replicare macchine virtuali in ambiente VMware verso Azure (scenario 6 della figura seguente), esaminando le caratteristiche e la procedura tecnica da seguire. Nell’immagine seguente sono riportati tutti gli scenari attualmente contemplati dalla soluzione ASR:

Figura 1 – Scenari contemplati da Azure Site Recovery

Lo scenario di replica di macchine virtuali VMware verso Azure richiede la presenza della seguente architettura:

Figura 2 – Architettura nello scenario di replica di sistemi VMware verso Azure

Per poter attivare il processo di replica è necessaria la presenza di almeno un server on-premises su cui vengono installati i seguenti ruoli:

Configuration Server: coordina le comunicazioni tra il mondo on-premises ed Azure, e gestisce la replica dei dati.
Process Server: questo ruolo di default viene installato insieme al Configuration Server, ma possono essere previsti più sistemi Process Server in base al volume di dati da replicare. Agisce come replication gateway, quindi riceve i dati di replica, ne effettua un’ottimizzazione tramite meccanismi di cache e compressione, provvede all’encryption e li invia verso lo storage in ambiente Azure. Questo ruolo ha inoltre il compito di effettuare il discovery delle macchine virtuali sui sistemi VMware.
Master target server: anche questo ruolo viene installato di default insieme al Configuration Server, ma per deployment con un numero elevato di sistemi possono essere previsti più server con questo ruolo. Entra in azione durante il processo di failback delle risorse da Azure gestendo i dati di replica.

Su tutte le macchine virtuali sottoposte al processo di replica è necessaria la presenza del Mobility Service, che viene installato dal Process Server. Si tratta di un agente specifico che si occupa di replicare i dati presenti nella macchina virtuale.

In seguito viene descritto il processo da seguire per effettuare il deployment dei componenti on-premises e nel mondo Azure necessari per attivare la replica delle macchine virtuali VMware verso la cloud pubblica di Microsoft.

Il componente core necessario lato Azure è il Recovery Service Vault all’interno del quale, nella sezione Site Recovery, è possibile avviare il processo di configurazione pilotato per lo scenario di protezione prescelto.

Figura 3 – Scelta dello scenario di replica di macchine virtuali VMware all’interno del Recovery Service Vault

Successivamente è necessario procedere all’installazione sulla macchina on-premises del Configuration Server seguendo gli step indicati:

Figura 4 – Step da seguire per aggiungere il Configuration Server

In questa sezione del portale Azure è possibile scaricare il Microsoft Azure Site Recovery Unified Setup e la chiave necessaria per la registrazione del server al vault. Prima di avviare il setup accertarsi che la macchina su cui si intende installare il ruolo di Configuration Server sia in grado di accedere agli URL pubblici del servizio Azure e che durante il setup sia consentito il traffico web su porta 80 necessario per effettuare il download del componente MySQL utilizzato dalla soluzione.

Avviando il setup vengono richieste le seguenti informazioni:

Figura 5 – Scelta dei ruoli da installare

Selezionare la prima opzione per l’installazione del ruolo Configuration Server e Process Server. La seconda opzione è utile nel caso si debbano installare ulteriori Process Server per consentire uno scale out del deployment.

Figura 6 – Accettazione del license agreement di MySQL Community Server

Figura 7 – Selezione della chiave necessaria per la registrazione al Site Recovery Vault

Figura 8 – Scelta della metodologia per accedere ai servizi Azure (diretta o tramite proxy)

Figura 9 – Check di verifica dei prerequisiti

Figura 10 – Impostazione delle password relative a MySQL

Figura 11 – Ulteriore check sulla presenza dei componenti necessari per proteggere VMs VMware

Figura 12 – Scelta del path di installazione

L’installazione richiede indicativamente 5 GB di spazio a disposizione, ma sono consigliati almeno 600 GB per la cache.

Figura 13 – Selezione dell’interfaccia di rete e della porta da utilizzare per il traffico di replica

Figura 14 – Summary delle scelte di installazione

Figura 15 – Setup dei diversi ruoli e componenti completato con successo

Al termine del setup viene mostrata la connection passphrase che viene utilizzata dal Configuration Server, che è bene salvare con cura.

In seguito è necessario configurare le credenziali che verranno utilizzate da Azure Site Recovery per effettuare il discovery delle macchine virtuali nell’ambiente VMware e per effettuare l’installazione del Mobility Service sulle macchine virtuali.

Figura 16 – Definizioni delle credenziali utilizzate dal servizio

Completate queste operazioni sarà possibile selezionare il Configuration Server dal portale Azure e successivamente definire i dati del sistema VMware (vCenter oppure vSphere) con cui interfacciarsi.

Figura 17 – Selezione del Configuration Server e aggiunta vCenter/vSphere host

Conclusa questa configurazione è necessario attendere alcuni minuti per consentire al Process Server di effettuare il discovery delle macchine virtuali sull’ambiente VMware specificato.

In seguito occorre definire le impostazioni relative al target della replica:

Su quale sottoscrizione e con quale recovery model creare i sistemi.
Quale storage account utilizzare per ospitare i dati replicati.
vNet su cui attestare i sistemi replicati.

Figura 18 – Impostazioni relative al Target della replica

Lo step successivo prevede la definizione delle policy di replica in termini di RPO (espresso in minuti), retention dei recovery point (espresso in ore) e frequenza con cui effettuare delle snapshot consistenti a livello di applicazione.

Figura 19 – Creazione della policy di replica

Al termine di questa attività viene proposto di effettuare l’analisi del proprio ambiente tramite il tool Deployment Planner (scaricabile direttamente tramite il link riportato nel portale Azure) al fine di accertarsi di avere i requisiti, le risorse network e le risorse storage sufficienti per garantire il corretto funzionamento della soluzione.

Figura 20 – Step di preparazione dell’infrastruttura completati con successo

Terminati gli step di preparazione dell’infrastruttura è possibile attivare il processo di replica:

Figura 21 – Source e Target di replica

Figura 22 – Selezione delle macchine virtuali e dei relativi dischi da replicare

In questa sezione viene anche specificato quale account il Process Server utilizzerà per effettuare l’installazione del Mobility Service su ogni macchina virtuale VMware (account configurati in precedenza come documentato nella Figura 16).

Figura 23 – Selezione della policy di replica e abilitazione facoltativa della Multi-VM consistency

Nel caso venga selezionata l’opzione “Multi-VM consistency” verrà creato un Replication Group all’interno del quale verranno inserite le VMs che si desidera replicare insieme per utilizzare recovery point condivisi. Questa opzione è consigliata solo quando è necessaria una consistenza durante il processo di Failover su più macchine virtuali che erogano lo stesso workload. Inoltre attivando questa opzione è bene tenere in considerazione che per attivare il processo di Failover dei sistemi è necessario configurare un Recovery Plan specifico e non è possibile attivare il Failover per una singola macchina virtuale.

Al termine di queste configurazioni è possibile attivare il processo di replica

Figura 24 – Attivazione del processo di replica e relativo esito

Figura 25 – Stato della replica della macchina virtuale VMware

Una delle difficoltà maggiori quando si implementa uno scenario di Disaster Recovery è avere la possibilità di testarne il funzionamento senza impattare i sistemi di produzione ed il relativo processo di replica. Altrettanto vero è che non testare in modo appropriato il processo di DR equivale quasi a non averlo. Azure Site Recovery consente di testare in modo molto semplice la procedura di Disaster Recovery per valutarne la reale efficacia:

Figura 26 – Test della procedura di Failover

Figura 27 – Esito del processo di Test Failover

Conclusioni

Poter contare su un’unica soluzione come Azure Site Recovery che consente di attivare e testare procedure per la business continuity in infrastrutture eterogenee, contemplando anche macchine virtuali in ambiente VMware, ha sicuramente numerosi vantaggi in termini di flessibilità ed efficacia. ASR consente infatti di affrontare gli ostacoli tipici che si incontrano durante la realizzazione di piani di Disaster Recovery riducendo i costi e la complessità ed aumentando i livelli di compliance. La stessa soluzione può essere inoltre utilizzata per affrontare la migrazione vera e propria dei sistemi verso Azure con un impatto minimo sull’utenza finale grazie a downtime degli applicativi vicini allo zero.

Azure Backup: la protezione del System State nel cloud

Recentemente è stata inclusa la possibilità di proteggere il System State delle macchine Windows Server direttamente in Azure utilizzando l’Azure Backup Agent. Questa funzionalità è stata in preview per alcuni mesi ed ora è disponibile per essere utilizzata in ambienti di produzione. In questo articolo verrà mostrato come è possibile proteggere con Azure Backup il System State delle macchine, analizzando le caratteristiche e riportando i vantaggi introdotti da questa nuova funzionalità.

L’Azure Backup Agent consente di salvare file, cartelle e grazie all’inclusione del System State vengono contemplati nella protezione delle macchine Windows Server anche i seguenti componenti:

File di Boot, inclusi file di sistema, e tutti i file protetti da Windows File Protection (WFP).
Active Directory e Sysvol (sui sistemi domain controller).
Il registry.
Metabase di IIS (sulle macchine Web Server IIS): include le configurazioni di IIS e i web site ospitati dal web server.
Cluster database (sui nodi del cluster).
Certificate Services (sulle certification authority).
Informazioni relative ai Performance counter.
Component Services Class registration database.

Grazie all’inclusione del System State l’utilizzo di Azure Backup diventa ideale anche per adottare strategie di protezione di Active Directory, File Server e Web Server IIS.

Figura 1 – Protezione del System State in Azure

Questa soluzione è supportata a partire da Windows Server 2008 R2 fino a Windows Server 2016.

Per attivare questo tipo di protezione è necessario creare all’interno della subscription Azure un Recovery Service Vault, installare l’Azure Backup Agent sulla macchina Windows Server ed effettuare la relativa registrazione seguendo gli step riportati nello schema seguente:

Figura 2 – Step di attivazione della protezione con Azure Backup

Accedendo al portale Azure e selezionando il Recovery Service Vault, all’interno del quale si vuole includere la protezione, nella sezione Backup compare la possibilità di proteggere il System State per workload in esecuzione On-Premises:

Figura 3 – Selezione del System State come componente da proteggere

Selezionando il pulsante “Prepare Infrastructure” vengono elencati gli step necessari per proteggere il System State delle macchine:

Figura 4 – Step di preparazione dell’infrastruttura

Dal pannello sopra riportato è necessario scaricare il setup di installazione del Recovery Service Agent e le credenziali del vault.

L’installazione dell’agente (MARSAgentInstaller.exe) è molto rapida e prevede i seguenti passaggi:

Figura 5 – Selezione della folder di installazione e della location della cache

Nella location della cache è bene prevedere come spazio libero almeno il 5% dei dati protetti.

Figura 6 – Configurazione di un eventuale sistema proxy per accedere a Internet

Figura 7 – Check dei requisiti e installazione

Figura 8 – Avvio del processo di registrazione al Recovery Service Vault

Figura 9 – Selezione delle credenziali di accesso al vault

Figura 10 – Generazione e salvataggio della Passphrase

La Passphrase viene utilizzata per criptare e decriptare i backup, non viene mai inviata verso Azure, non è recuperabile in alcun modo dal personale di supporto Microsoft ed è indispensabile per poter eseguire operazioni di restore, quindi è necessario mantenerla con estrema attenzione.

Figura 11 – Registrazione completata con successo

Dalla console di Microsoft Azure Backup è possibile schedulare un backup e per i sistemi server è disponibile nella selezione degli items da proteggere il System State:

Figura 12 – Selezione della protezione del System State

Figura 13 – Impostazioni sulla frequenza del backup

Figura 14 – Definizione delle regole di retention

Figura 15 – Step finale di attivazione del backup del System State

La protezione del System State può essere anche automatizzata grazie al supporto per PowerShell. Si ha inoltre la possibilità di consultare facilmente l’esecuzione dei job di backup in modo centralizzato direttamente dal portale Azure ed è possibile configurare delle notifiche per essere avvisati in caso di fallimento dei job di protezione.

L’offsite dei backup è garantito utilizzando questa soluzione senza dover investire in costi di infrastruttura e risparmiando tempo nelle attività operative. Inoltre è bene tenere in considerazione che i costi per questa soluzione sono davvero vantaggiosi, infatti tipicamente il System State delle machine come dimensione è nettamente inferiore ai 50 GB quindi la protezione del System State a livello di pricing ricade nella fascia di costo più bassa prevista per le istanze protette con Azure Backup. Per maggiori dettagli in merito al costo della soluzione è possibile consultare la pagina sui costi di Azure Backup. Non è inoltre previsto nessun costo per eventuali operazioni di restore.

Conclusioni

Il System State per le macchine Windows Server è un componente critico che è opportuno salvare per avere una adeguata ed efficace strategia di protezione della propria infrastruttura. Azure Backup grazie al suo approccio definito cloud-first estende le proprie potenzialità consentendo di proteggere anche il System State delle macchine in modo semplice, sicuro e con costi irrisori. Per provare Azure Backup ed altri servizi di Azure è possibile creare un Azure free Account.

Azure Site Recovery: il disaster recovery di macchine virtuali in Azure

In Azure c’è la possibilità di utilizzare Azure Site Recovery (ASR) per implementare in modo semplice una efficace strategia di disaster recovery abilitando la replica delle macchine virtuali tra differenti region di Azure. Nonostante in Azure siano presenti meccanismi integrati per far fronte a guasti hardware localizzati può essere opportuno implementare una soluzione in grado di garantire la compliance delle applicazioni, eseguite sulle macchine virtuali presenti in Azure, a fronte sia di eventi catastrofici, come terremoti oppure uragani, che di problematiche software che possono impattare sul funzionamento di una intera region di Azure. In questo articolo verrà mostrato come configurare la replica di una macchina virtuale e come attivare lo scenario di disaster recovery.

Questa funzionalità è stata definita one-click replication per la sua semplicità, al momento è in public preview ed è utilizzabile in tutte le region Azure dove è disponibile ASR.

Prima di attivare questa funzionalità è fondamentale verificare che siano rispettati tutti i requisiti necessari e per farlo è possibile consultare la matrice di compatibilità per lo scenario di replica di macchine virtuali tra differenti region.

Accedendo al portale Azure è possibile selezionare la macchina virtuale che si intende replicare ed effettuare la configurazione nella relativa sezione Disaster recovery:

Figura 1 – Sezione Disaster Recovery della VM

Selezionando Disaster Recovery viene mostrato il pannello di configurazione seguente:

Figura 2 – Pannello di configurazione della replica della VM

Il primo parametro richiesto è la region target dove si desidera replicare la macchina virtuale. La procedura di attivazione della replica effettua anche la creazione degli artifacts Azure necessari (Resource Group, Availability Set se utilizzato dalla VM selezionata, Virtual Network e Storage Account) oppure è possibile selezionarli a proprio piacimento se sono stati creati in precedenza.

Figura 3 – Risorse necessarie nella region target

Il processo di replica richiede anche la presenza di un Cache Storage Account nella region sorgente che viene utilizzato come repository temporaneo per memorizzare le modifiche prima che queste vengano riportate nello storage account definito nella region di destinazione. Questo viene fatto per minimizzare l’impatto sulle applicazioni di produzione che risiedono sulla VM replicata.

Figura 4 – Utilizzo del Cache Storage Account nel processo di replica

Sempre nel pannello di configurazione viene richiesto quale Recovery Services Vault utilizzare e viene proposta la creazione di una policy di replica che definisce la retention dei recovery point e la frequenza con la quale vengono effettuate delle snapshot consistenti a livello di applicazione.

Selezionando Enable Replication viene avviato il processo di creazione delle risorse Azure necessarie, la VM viene registrata nel Recovery Services Vault selezionato e viene attivato il processo di replica.

Nella sezione Disaster Recovery vengono riportati i dettagli relativi alla replica ed è possibile effettuare un Failover oppure testarne il suo corretto funzionamento:

Figura 5 – Dettagli relativi al processo di replica della VM e attivazione del processo di failover

La procedura di Test Failover consente di specificare quale recovery point utilizzare tra: latest, latest processed, latest app-consistent oppure custom. Inoltre è possibile selezionare su quale virtual network attestare la macchina virtuale durante il test di failover in modo da poter effettuare i test senza generare alcun impatto sui sistemi di produzione.

Figura 6 – Test Failover di una VM

Analogo il pannello di Failover che consente di specificare solo quale recovery point utilizzare in quanto la network su cui attestare la macchina è stata già definita in fase di configurazione.

Figura 7 – Failover di una VM

Solo nel momento in cui viene avviato il processo di Failover le macchine virtuali coinvolte vengono create nel resource group target, attestate alla vNet target e configurate nell’availability set opportuno se utilizzato.

Figura 8 – Processo di Failover

Conclusioni

Grazie a questa nuova funzionalità introdotta in Azure Site Recovery è possibile attivare con estrema facilità la replica di macchine virtuali in differenti region Azure, senza la necessità di dover disporre di costose infrastrutture secondarie per attivare un piano di disaster recovery.

What’s New in Azure Automation: Inventory, Change Tracking e Update Management

In Azure Autiomation sono state recentemente introdotte nuove funzionalità, attualmente in preview, che consentono di gestire la distribuzione degli aggiornamenti, di raccogliere informazioni di inventario relative alle applicazioni installate sui sistemi e di tenere traccia delle modifiche apportare sulle macchine. In questo articolo verrà mostrato come configurare l’Azure Automation Account per poter usufruire di queste nuove funzionalità e verranno approfondite le loro principali caratteristiche.

Per poter utilizzare ciascuna di queste funzionalità è necessario che l’Automation Account sia associato ad un Wokspace di Log Analytics.

Nel caso l’Automation Account dove si intende attivare queste nuove funzionalità non sia collegato a nessun Workspace di Log Analytics viene richiesta, in fase di abilitazione, l’associazione ad un Workspace esistente oppure viene proposta la creazione di un nuovo Workspace:

Figura 1 – Associazione dell’Automation Account al Workspace di Log Analytics

Le funzionalità di Change Tracking e di Inventory vengono abilitate contemporaneamente dal portale Azure e al termine dell’attivazione comparirà la notifica seguente:

Figura 2 – Notifica al termine dell’abilitazione delle funzionalità di Change Tracking e di Inventory

Per l’abilitazione della funzionalità di Update management sarà necessario svolgere la medesima operazione.

Figura 3 – Abilitazione delle funzionalità di Update Management

Al termine di queste attività nel Workspace di Log Analytics saranno presenti le seguenti solution:

Figura 4 – Solution aggiunte in Log Analytics

Dopo aver completato l’attivazione le solution inizieranno ad elaborare e a mostrare i dati delle macchine eventualmente già connesse al workspace OMS associato allo specifico Automation Account. Inoltre è possibile fare l’onboarding di ulteriori macchine direttamente dalle relative sezioni del portale Azure:

Figura 5 – Aggiunta di ulteriori sistemi

Questo processo richiede l’installazione dell’agente OMS sui sistemi e può avvenire sia su macchine Windows che Linux. Nel caso le macchine siano sulla fabric di Azure il processo di installazione dell’agente OMS è integrato e può avviene in modo rapido con un semplice click dal portale Azure. In caso contrario è comunque possibile associare i sistemi installando manualmente l’agente OMS, in modo indipendente dalla loro location (on-premises oppure altri cloud).

Per le funzionalità di Inventory e Change Tracking è possibile accedere alle impostazioni (comuni tra le due solution) per personalizzare le informazioni relative alle chiavi di registry, ai file in ambiente Windows e ai file in ambiente Linux che si intende inventariare e controllare:

Figura 6 – Edit delle impostazioni

Figura 7 – Personalizzazione delle configurazioni

Inventory

Questa funzionalità consente di recuperare informazioni di inventario relative a: software installati, files, chiavi Windows Registry, Servizi Windows e Daemons Linux. Il tutto può essere consultato facilmente direttamente dal portale Azure applicando eventualmente dei filtri di ricerca:

Figura 8 – Ricerca dei dati di inventario raccolti

Change Tracking

La funzionalità di Change Tracking consente di monitorare le modifiche apportate ai sistemi relativamente a Daemons, File, Registry, Software e Servizi Windows. Tale funzionalità può risultare molto utile per diagnosticare problemi specifici e per abilitare segnalazioni a fronte di cambiamenti non attesi.

Figura 9 – Consultazione delle modifiche apportate

Accedendo alla console di Log Analytics è inoltre possibile effettuare delle ricerche più mirate:

Figura 10 – Ricerche in Log Analytics

Inoltre nel Change Tracking c’è la possibilità di collegare l’Azure Activity Log di una subscription Azure per collezionare anche le modifiche che vengono apportate lato Azure.

Figura 11 – Azure Activity Log connection

Update Management

La soluzione di Update Management consente di avere una visibilità complessiva sulla compliance degli update sia per sistemi Windows che Linux:

Figura 12 – Stato globale di compliance degli update sui sistemi gestiti

Tramite il pannello di ricerca è possibile identificare velocemente gli update mancati:

Figura 13 – Identificazione degli update mancanti

La solution non è solo molto utile a fini di consultazione, ma consente anche di schedulare dei deployment per l’installazione degli update all’interno di una specifica finestra di manutenzione.

Figura 14 – Schedulazione del deplyment

A breve sarà disponibile anche la possibilità di effettuare il deployment sui sistemi Linux. Tra le funzionalità offerte c’è la possibilità di escludere dal deployment aggiornamenti specifici.

Figura 15 – Impostazione del deployment

I deployment schedulati e il loro stato di esecuzione possono essere monitorati in tempo reale direttamente dal portale Azure:

Figura 16 – Elenco dei deployment schedulati

Figura 17 – Update Deployment in corso

Figura 18 – Update Deployment Completato con successo

Selezionando il deployment completato si viene rimandati a una dashboard ben strutturata e di facile consultazione che consente di verificare i dettagli del deployment:

Figura 19 – Dashboard del deployment

Utile anche la possibilità di recuperare log relativi ai deployment per fini di troubleshooting.

Conclusioni

Si tratta di funzionalità che offrono la possibilità di controllare e gestire in modo semplice, intuitivo ed efficace ambienti composti da poche unità nel cloud fino a contemplare scenari ibiridi con un numero elevato di sistemi. Queste funzionalità al momento sono in preview quindi destinate ad ampliare ulteriormente le loro potenzialità. In particolare la funzionalità di Update Management per poter gestire e orchestrare la distribuzione degli aggiornamenti in ambienti complessi in modo efficace e flessibile dovrà evolversi molto, ma è sicuramente a un buon punto di sviluppo. Per ulteriori dettagli relativi ad Azure Automation vi invito a consultare la documentazione ufficiale.

Creazione di un ambiente Docker in Azure tramite VM Extension

Docker è una piattaforma software che consente di creare, gestire ed eseguire applicazioni isolate in containers. Un container non è altro che una metodologia di creazione dei pacchetti software in un formato che permette di essere eseguito in modo indipendente ed isolato su un sistema operativo condiviso. I containers a differenza delle machine virtuali non comprendono un sistema operativo completo, ma solamente le librerie e le impostazioni necessarie per consentire l’esecuzione del software. Ne derivano quindi una serie di vantaggi in termini di dimensione, velocità, portabilità e gestione delle risorse.


Figura 1 – Diagramma dei Container

Nel mondo Microsoft Azure ci sono svariate possibilità di configurare ed utilizzare container Docker che vi elenco sinteticamente:

VM Extension: tramite una Extension specifica è possibile implementare Docker all’interno di una macchina virtuale.
Azure Container Service: consente di distribuire rapidamente nell’ambiente Azure un cluster Docker Swarm, DC/OS o Kubernetes pronto per la produzione. Si tratta della soluzione più completa per l’orchestrazione dei container.
Docker EE for Azure: è un template disponibile sull’Azure Marketplace, frutto della collaborazione tra Microsoft e Docker, grazie al quale è possibile fare il provisioning di un cluster Docker Enterprise Edition sfruttando l’integrazione con gli Azure VM Scale Sets, gli Azure Load Balancer e l’Azure Storage.
RancherOS: è una distribuzione Linux appositamente creata per l’esecuzione di containers Docker disponibile come template all’interno del Marketplace Azure.
Web App for Containers: viene offerta la possibilità di utilizzare containers facendone il deployment nella piattaforma gestita degli Azure App Service come Web App in esecuzione in un ambiente Linux.
Azure Container Instances (attualmente in preview): è sicuramente il metodo più semplice e rapido per eseguire un container Docker nella piattaforma Azure, senza la necessità di creare macchine virtuali, ideale in scenari che prevedono containers isolati.
Azure Service Fabric: supporta i containers sia nell’ambiente Windows che Linux. La piattaforma contiene in modo nativo il supporto per Docker Compose (attualmente in preview), consentendo di orchestrare applicazioni basate su containers nell’Azure Service Fabric.
DC/OS su Azure: si tratta di un servizio cloud gestito che mette a disposizione un ambiente per il deployment di workload in cluster utilizzando la piattaforma DC/OS (Datacenter Operating System).

Tutte queste possibilità offerte consentono, in base alle esigenze e allo scenario che si deve implementare, di scegliere la metodologia di deployment più opportuna nell’ambiente Azure per l’esecuzione dei container Docker.

In questo articolo approfondiremo la creazione di un ambiente Docker utilizzando l’apposita Virtual Machine Extension. Partendo da una macchina virtuale presente in Azure è possibile aggiungere la Docker Extension che installa e configura il daemon Docker, il client Docker e il Docker Compose.

Questa extension è supportata per le seguenti distribuzioni Linux:

Ubuntu 13 o superiore.
CentOS 7.1 o superiore.
Red Hat Enterprise Linux (RHEL) 7.1 o superiore.
CoreOS 899 o superiore.

L’aggiunta dell’extension dal portale Azure può essere fatta tramite i seguenti step. Nella sezione Extensions della macchina virtuale seleziono il pulsante Add:


Figura 2 – Aggiunta Extension alla VM dal portale Azure

Successivamente viene mostrato l’elenco delle Extension disponibili, ci si posiziona sull’Extension Docker e si preme il pulsante Create.


Figura 3 – Selezione dell’Extension Docker

Per consentire una comunicazione sicura con il sistema Docker implementato nell’ambiente Azure è necessario utilizzare dei certificati e delle chiavi rilasciati da una CA trusted. Se non si dispone di una CA per generare questi certificati è possibile seguire le indicazioni riportate nella sezione Create a CA, server and client keys with OpenSSL presente nella documentazione ufficiale di Docker.


Figura 4 – Schema di comunicazione docker tramite protocollo crittografato TLS

Il wizard di aggiunta dell’Extension richiede come prima cosa di inserire la porta di comunicazione utilizzata dell’Engine Docker (2376 è la porta di default). Inoltre è richiesto l’inserimento del certificato della CA, del certificato Server e della Server Key, tutti nel formato base64-encoded:


Figura 5 – Parametri richiesti dal wizard di aggiunta della Docker VM Extension

L’aggiunta dell’Extension Docker richiede alcuni minuti al termine dei quali sulla macchina virtuale sarà presente l’installazione dell’ultima versione stabile del Docker Engine e il daemon Docker sarà in ascolto sulla porta specificata utilizzando i certificati inseriti nel wizard.


Figura 6 – Dettagli dell’Extension Docker

Nel caso sia necessario consentire la comunicazione Docker dall’esterno della vNet su cui è attestata la macchina virtuale con Docker è necessario configurare in modo opportuno le regole nel Network Security Group utilizzato:


Figura 7 – Esempio di configurazione NSG per consentire comunicazione Docker (porta 2376)

Giunti a questo punto l’ambiente è pronto per essere utilizzato e da un client remoto posso iniziare a comunicare verso l’ambiente Docker appena configurato:


Figura 8 – Comando Docker eseguito da un client remoto per recuperare informazioni

Conclusioni

L’Azure Docker VM extension è ideale per implementare facilmente e in modo affidabile e sicuro un ambiente Docker di sviluppo oppure di produzione su una singola macchina virtuale. Microsoft Azure offre un’ampia gamma di possibilità nelle scelte di implementazione relative alla piattaforma Docker, consentendo di scegliere con molta flessibilità la soluzione più idonea per le proprie esigenze.

Log Analytics: un importante aggiornamento evolve la soluzione

Dalla scorsa settimana Microsoft ha iniziato il rilascio di quello che può essere definito il più importante aggiornamento di Log Analytics dalla data del suo rilascio. Tra le principali novità introdotte nella nuova versione di Log Analytics troviamo un nuovo e potente linguaggio per la creazione delle query, l’introduzione del nuovo portale Advanced Analytics e una maggiore integrazione con Power BI. In questo articolo vedremo come effettuare l’aggiornamento e le caratteristiche principali delle nuove funzionalità introdotte.

Come aggiornare Log Analytics

Il processo di aggiornamento è molto semplice e sta gradualmente interessando i workspace OMS presenti in tutte le region di Azure. Nel momento in cui l’aggiornamento è disponibile per il proprio workspace comparirà un banner di notifica nel portale OMS oppure direttamente nella sezione Log Analytics del portale Azure:

Figura 1 – Banner che notifica la disponibilità dell’aggiornamento di Log Analytics

Con un semplice click sul banner si accede alla seguente schermata di riepilogo che riassume le novità introdotte dall’aggiornamento e che consente di avviare il processo di upgrade selezionando l’apposito pulsante:

Figura 2 – Upgrade di Log Analytics

L’aggiornamento deve essere effettuato da un amministratore del workspace OMS e il processo di upgrade dura alcuni minuti, al termine dei quali tutti gli artifacts come le ricerche salvate, le alert rule, i gruppi di computer e le viste create tramite il View Designer vengono in automatico convertite nel nuovo linguaggio di Log Analytics. Le ricerche incluse nelle solution non vengono convertite in automatico durante l’upgrade, ma saranno convertite al volo e in modo trasparente per l’utente al momento dell’apertura delle stesse.

Durante il processo di upgrade viene creato un backup completo del workspace, utile nel caso ci sia la necessità di ripristinare la versione precedente. Il ripristino è possibile effettuarlo direttamente dal portale OMS:

Figura 3 – Ripristino del workspace legacy di Log Analytics

Al momento questo aggiornamento è opzionale, ma in futuro verrà forzato da Microsoft comunicando con il dovuto anticipo la data prevista per la conversione del workspace.

Nuovo linguaggio di creazione delle query

In seguito all’aggiornamento è possibile trarre vantaggio delle potenzialità del nuovo linguaggio per la creazione delle query. Vi riporto le principali caratteristiche:

Si tratta di un linguaggio semplice e di facile comprensione dove è possibile utilizzare costrutti più vicini al linguaggio naturale.
L’output di una query può essere messo in correlazione (tramite pipe) con altri comandi per poter creare query più complesse di quanto fosse possibile con il precedente linguaggio.
Supporta l’utilizzo di extended field calcolati in tempo reale e utilizzabili per comporre query complesse.
Sono state migliorate le funzionalità che consentono di effettuare join avanzate di tabelle basandosi su più campi, inner join, outer join e join utilizzando gli extended field.
Vengono messe a disposizione maggiori funzionalità per le operazioni che coinvolgono funzioni basate sulla data e sul time.
Consente di utilizzare algoritmi avanzati per l’evaluation dei pattern nei dataset e confrontare differenti set di dati.
Supporta l’inserimento di commenti nelle query, sempre utili in fase di troubleshooting e per facilitare la comprensione delle query scritte da altri.

Quelle sopra riportate sono solo alcune delle numerose novità che vengono introdotte, ma per maggiori approfondimenti relativi al nuovo linguaggio di generazione delle query di Log Analytics vi invito a consultare il sito ufficiale appositamente creato che contiene una guida completa, tutorial ed esempi.

Figura 4 – Esempio di query scritta nel nuovo linguaggio che crea un grafico con gli alert giornalieri suddivisi per severity

Per coloro che hanno già una buona familiarità con il precedente linguaggio di generazione delle query è possibile utilizzare lo strumento converter che viene aggiunto durante l’upgrade del workspace e che consente di convertire query scritte con il linguaggio legacy nel nuovo linguaggio:

Figura 5 – Esempio di conversione di una query

Utile anche il documento Legacy to new Azure Log Analytics Query Language cheat sheet che consente di effettuare un rapido confronto tra i due linguaggi riportando alcuni statement tra i più utilizzati.

Portale Advanced Analytics

Con l’introduzione del nuovo portale Advanced Analytics è possibile eseguire attività utili durante la scrittura del codice che non è possibile fare direttamente dal portale di Log Analytics. L’accesso al portale Advanced Analytics può avvenire selezionando una delle icone seguenti dal portale di Log Analytics:

Figura 6 – Accesso al portale Advanced Analytics

Grazie a questo portale si ottiene una migliore experience nella scrittura interattiva delle query avendo a disposizione un editing multi-line, sottolineatura della sintassi context-aware e un potente visualizzatore integrato. Il tutto è molto utile in fase di troubleshooting, diagnostica, analisi dei trend e per generare report in modo rapido.

Figura 7 – Query che calcola e mostra graficamente il risultato dell’utilizzo di CPU di una specifica macchina

Con estrema facilità è anche possibile creare una quick visualization dal portale Advanced Analytics ed effettuare il pin della stessa su una shared Azure Dashboard.

Integrazione con Power BI

In seguito a questo aggiornamento si ottiene anche una maggiore integrazione con Power BI, al pari di Application Insights:

Figura 8 – Schema di integrazione di Log Analytics con Power BI

Grazie a questa integrazione è possibile usufruire dei report di Power BI, pubblicarli e condividerli su PowerBI.com e abilitarne la generazione automatica. Per maggiori dettagli a riguardo vi invito a consultare il documento Export Log Analytics data to Power BI.

Conclusioni

Questo importante aggiornamento di Log Analytics aumenta le potenzialità dello strumento consentendo di effettuare ricerche complesse in modo mirato e semplice grazie al nuovo linguaggio introdotto e arricchisce le potenzialità della soluzione grazie alla migliore integrazione con Power BI. Questo nuovo linguaggio e il portale di Advanced Analytics sono già in uso anche in Application Insights e questo consente di avere un experience di monitoring omogenea e consistente per i differenti servizi Azure.

Azure Multi-Factor Authentication: Introduzione alla Soluzione

Per rendere più sicuro l’accesso ai dati e alle applicazioni critiche può essere necessario prevedere l’autenticazione a più fattori che generalmente richiede l’utilizzo di almeno due dei seguenti metodi di verifica:

Qualcosa che si conosce (tipicamente una password).
Qualcosa che si possiede (un dispositivo unico e non facilmente duplicabile, come ad esempio un telefono).
Un sistema di riconoscimento biometrico che ha lo scopo di identificare una persona sulla base di una o più caratteristiche biologiche o comportamentali (biometria).

Microsoft consente di adottare una soluzione di autenticazione a due fattori utilizzando l’Azure Multi-Factor Authentication (MFA) che prevede l’adozione di un secondo metodo di verifica dell’identità durante il processo di autenticazione. Utilizzando questa soluzione sono configurabili i seguenti fattori di autenticazione aggiuntivi:

Chiamata telefonica: viene effettuata una chiamata verso il telefono registrato per l’utenza. In questo caso verrà richiesto all’utente di rispondere alla chiamata e di verificare l’accesso premendo il pulsante # oppure inserendo un codice PIN.
Messaggio di testo (SMS): viene inviato al cellulare dell’utente un SMS che contiene un codice pin di 6 cifre il quale dovrà essere inserito durante il processo di autenticazione.
Notifica tramite Mobile App: sullo smartphone dell’utente viene inviata tramite Mobile App una richiesta di verifica che deve essere approvata dall’utente per completare il processo di autenticazione.
Codice di verifica tramite Mobile App: nella Mobile App presente sullo smartphone dell’utente viene generato un codice di 6 cifre ogni 30 secondi. L’utente dovrà quindi inserire il codice più recente nel momento in cui effettua l’autenticazione.
Token OATH di terze parti: c’è la possibilità di configurare Azure Multi-Factor Authentication per accettare metodi di verifica messi a disposizione da soluzione di terze parti.

L’Azure Multi-Factor Authentication (MFA) prevede due possibili modelli di deployment:

MFA come soluzione interamente nel Cloud.
Sistema MFA installato e configurato su sistemi on-premises.

Per individuare il modello di deployment più opportuno è necessario prendere in considerazione diversi aspetti: cosa sto mettendo in sicurezza, dove si trovano gli utenti che devono accedere alla soluzione e di quali funzionalità ho realmente bisogno.

Cosa si sta Tentando di Proteggere?

Questa è sicuramente la prima domanda che occorre porsi la cui risposta ci può già indirizzare a un modello di deployment specifico. Nel caso infatti ci sia la necessità di abilitare il doppio fattore di autenticazione per applicazioni IIS non pubblicate tramite Azure AD App Proxy oppure soluzioni di accesso remoto (VPN oppure Remote Desktop Gateway) è necessario utilizzare il server Azure MFA implementato sui sistemi on-premises.

Figura 1 – Cosa si intende proteggere tramite MFA

Dove si Trovano gli Utenti?

Un altro aspetto importante da tenere in considerazione è dove si trovano gli utenti sulla base del modello di Identity adottato, come mostra la figura 2.

Figura 2 – Ubicazione degli utenti

Quali funzionalità sono necessarie?

A seconda del modello di deployment scelto (MFA nel cloud oppure MFA locale) sono disponibili funzionalità differenti che ci potrebbero far optare per una scelta piuttosto che per un’altra, come mostra la figura 3.

Figura 3 – Funzionalità MFA disponibili nei due modelli

Requisiti necessari per l’utilizzo della MFA

Per poter utilizzare l’Azure Multi-Factor Authentication (MFA) è necessario avere accesso a una subscription Azure. Nel caso si volesse testare il servizio è possibile eventualmente utilizzare una subscription di trial di Azure.

I requisiti hardware per quanto riguarda l’Azure Multi-Factor Authentication Server sono minimi (200 MB di spazio disco e 1 GB di RAM), mentre sono richieste le seguenti caratteristiche software:

Sistema Operativo: Windows Server 2008 R2 o superiore
Microsoft .NET 4.0 Framework
IIS 7.0 o superiore se si vuole installare lo User Portal oppure il Web Service SDK

Ogni server MFA deve essere in grado di comunicare sulla porta 443 in uscita verso i seguenti indirizzi web:

https://pfd.phonefactor.net
https://pfd2.phonefactor.net
https://css.phonefactor.net

Inoltre nel caso ci siano policy firewall di blocco in uscita verso la porta 443 è necessario aprire i range di indirizzi IP documentati nel paragrafo “Azure Multi-Factor Authentication Server firewall requirements” della documentazione ufficiale Microsoft.

Azure Multi-Factor Authentication nel cloud

L’abilitazione della MFA nello scenario cloud è molto semplice ed avviene per utente. Per farlo è necessario accedere al servizio Azure Active Directory, figura 4, dal portale Azure:

Figura 4 – Step 1: abilitazione MFA nel cloud

Dopo aver selezionato la Directory, nella sezione “Users and groups” selezionare “Multi-Factor Authentication”:

Figura 5 – Step 2: abilitazione MFA nel cloud

Si verrà rediretti su un altro portale dove selezionando l’utente specifico, figura 6, è possibile abilitare la MFA:

Figura 6 – Step 3: abilitazione MFA nel cloud

Giunti a questo punto l’utente sarà abilitato all’utilizzo della MFA. La stessa operazione può essere fatta anche selezionando più utenti contemporaneamente e dallo stesso portale è possibile configurare le varie impostazioni dell’Azure Multi-Factor Authentication. Per maggiori dettagli a riguardo vi invito a consultare la documentazione ufficiale Microsoft.

La stessa operazione può essere portata a termine anche utilizzando i cmdlet Powershell per Azure AD i quali ci consentono facilmente di effettuare l’abilitazione della MFA per più utenti con poche righe di codice, come riportato nell’esempio seguente:

$users = “user1@ugisystemcenter.org”,”user2@ugisystemcenter.org”,”user3@ugisystemcenter.org”

foreach ($user in $users)

{

$st = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement

$st.RelyingParty = “*”

$st.State = “Enabled”

$sta = @($st)

Set-MsolUser -UserPrincipalName $user -StrongAuthenticationRequirements $sta

}

Azure Multi-Factor Authentication on-premises

Il deployment on-premises dell’Azure Multi-Factor Authentication Server richiede di effettuare il download del setup di installazione direttamente dal portale Azure. Nel caso si voglia licenziare Azure Multi-Factor Authentication come servizio autonomo con opzioni di fatturazione per utente e per autenticazione è necessario creare dal portale Classic di Azure un nuovo Multi-Factor Auth Provider (tale funzionalità presto sarà disponibile anche sul nuovo portale Azure).

Figura 7 – Creazione nuovo Multi-Factor Auth Providers

Selezionando il pulsante Manage si viene rediretti verso il portale dell’Azure Multi-Factor Authentication, figura 8, dal quale è possibile effettuare il donwload del setup e generare le credenziali di attivazione del servizio.

Figura 8 – Download del Multi-Factor Authentication Server e generazione credenziali

Nel caso si voglia utilizzare la licenza in bundle a Enterprise Mobility Suite, Azure AD Premium oppure Enterprise Cloud Suite non è necessario creare un Multi-Factor Auth Provider ma è sufficiente accedere al portale dell’Azure Multi-Factor Authentication per effettuare direttamente il download del setup.

Dopo essere entrati in possesso del setup è possibile effettuare l’installazione dell’Azure MFA Server. Durante il setup verrà richiesto solamente il percorso di installazione, figura 9.

Figura 9 – Setup Azure MFA Server

Figura 10 – Setup Azure MFA Server

Giunti a questo punto è necessario eseguire il Multi-Factor Authentication Server appena installato che ci guiderà nella procedura di attivazione.

Figura 11 – Applicazione Multi-Factor Authentication Server

Figura 12 – Step 1: Procedura attivazione Multi-Factor Authentication Server

Nella schermata seguente è necessario inserire le credenziali di accesso che vengono generate dal Portale dell’Azure Multi-Factor Authentication (vedi Figura 8).

Figura 13 – Step 2: Procedura attivazione Multi-Factor Authentication Server

Dopo aver completato l’attivazione del primo server Azure MFA è possibile avviare il Wizard di configurazione, figura 14, per attivare la replica tra più server Azure MFA e configurare il servizio in alta disponibilità.

Figura 14 – Wizard di configurazione Multi-Server MFA

Nello scenario dove il Multi-Factor Authentication Server è abilitato su più sistemi, i server Azure MFA comunicano tra di loro attraverso chiamate RPC e per fare in modo che il tutto avvenga in modo sicuro devono autenticarsi in modo reciproco. Tale processo di autenticazione può avvenire sia tramite l’appartenenza a un gruppo di security specifico in Active Directory (denominato Phone Factor Admins) sia tramite l’utilizzo di certificati SSL.

Ora che il server Azure MFA è stato configurato c’è la possibilità di importare facilmente gli utenti da Active Directory, figura 15, e su questi abilitare il doppio fattore di autenticazione desiderato.

Figura 15 – Import degli utenti da Active Directory

Nello scenario di utilizzo dell’Azure Multi-Factor Authentication (MFA) Server è bene specificare che i dati relativi agli utenti vengono salvati sui sistemi on-premises e nessun dato viene memorizzato in modo persistente sul cloud. Infatti nel momento in cui un utente effettua il processo di autenticazione a più fattori il server Azure MFA invia i seguenti dati verso il servizio Cloud Azure MFA per effettuare la verifica e a fini di reportistica:

ID univoco dell’utente (username oppure ID del server MFA interno)
Nome e Cognome (opzionali)
Indirizzo Email (opzionale)
Numero di telefono (in caso di chiamata Telefonica oppure di invio SMS)
Device token (quando viene utilizzata l’autenticazione tramite mobile app)
Metodo di autenticazione
Esito autenticazione
Nome e inidirizzo IP del server Azure MFA
Client IP (se disponibile)
Esito verifica (successo o negata) e motivazione in caso di deny

Oltre all’import mirato dei diversi utenti da Active Directory sui quali si vuole abilitare il doppio fattore di autenticazione è possibile integrare il server Azure MFA con il servizio Active Directory e impostare una importazione mirata e schedulata degli utenti secondo determinati criteri. Per maggiori dettagli in merito è possibile consultare la documentazione ufficiale Integrazione di directory tra il server Azure MFA e Active Directory.

Modelli di Licensing della soluzione

Azure Multi-Factor Authentication è disponibile come servizio autonomo, con opzioni di fatturazione per utente e per autenticazione, oppure in bundle con Azure Active Directory Premium, Enterprise Mobility Suite e Enterprise Cloud Suite. Azure Multi-Factor Authentication è disponibile attraverso un contratto Enterprise Microsoft, il programma di licenza Open Volume, il programma Cloud Solution Provider e un contratto Direct, come modello annuale per utente. Il servizio è anche disponibile con un modello in base al consumo per utente e per autenticazione, fatturato ogni mese secondo l’Azure monetary commitmen.

Per maggiori informazioni sui costi della soluzione è possibile consultare il seguente documento: Prezzi di Multi-Factor Authentication.

Conclusioni

Azure Multi-Factor Authentication è una soluzione semplice da usare, scalabile e affidabile che offre la possibilità di introdurre un secondo metodo di validazione in modo che gli utenti siano in grado di accedere in modo più sicuro ai propri dati e alle applicazioni, sia esse presenti on-premises che in ambienti cloud. Per chi è interessato a provare il servizio può facilmente attivare una subscription Azure gratuitamente accedendo alla Free Trial di Azure.

OMS Log Analytics: come effettuare il monitor del networking di Azure

All’interno di Log Analytics c’è la possibilità di abilitare delle solution specifiche che consentono di effettuare il monitor di alcuni componenti dell’infrastruttura di rete presente in Microsoft Azure.

Tra queste solution troviamo Network Performance Monitor (NPM) la quale è stata approfondita nell’articolo Monitorare le performance di rete con la nuova solution di OMS e che si presta molto bene anche per monitorare lo stato di salute, la disponibilità e la raggiungibilità del networking di Azure. Sono inoltre attualmente disponibili nella gallery di Operations Management Suite le seguenti solution che arricchiscono le potenzialità di monitoring lato OMS:

Azure Application Gateway Analytics
Azure Network Security Group Analytics

Abilitazione delle Solution

Accedendo al portale OMS è possibile aggiungere facilmente queste solution presenti nella gallery seguendo gli step che trovate documentati nel seguente articolo: Aggiungere soluzioni di gestione di Operations Management Suite (OMS).

Figura 1 – Solution Azure Application Gateway Analytics

Figura 2 – Solution Azure Network Security Group Analytics

Azure Application Gateway Analytics

L’Azure Application Gateway è un servizio che è possibile configurare in ambiente Azure in grado di fornire funzionalità di Application Delivery garantendo un bilanciamento applicativo layer 7. Per ottenere maggiori informazioni relative all’Azure Application Gateway è possibile consultare la documentazione ufficiale.

Per poter collezionare i log di diagnostica in Log Analytics è necessario posizionarsi nel portale Azure sulla risorsa Application Gateway che si intende monitorare e nella sezione Diagnostics logs selezionare l’invio dei log verso il workspace Log Analytics opportuno:

Figura 3 – Application Gateway Diagnostics settings

Per l’Application Gateway è possibile selezionare la raccolta dei seguenti log:

Log relativi agli accessi effettuati
Dati di performance
Firewall log (nel caso l’Application Gateway abbia il Web Application Firewall abilitato)

Dopo aver completato questi semplici passaggi la solution OMS installata consente di consultare facilmente i dati inviati dalla platform:

Figura 4 – Azure Application Gateway Analytics Overview nel portale OMS

All’interno della solution è possibile visualizzare un sommario delle informazioni raccolte e selezionando i singoli grafici si accede ai dettagli relativi alle categorie seguenti:

Application Gateway Access log
- Errori client e server riscontrati nei log di accesso dell’Application Gateway
- Richieste ricevute dall’Application Gateway per ora
- Richieste fallite per ora
- Errori rilevati per user agent

Figura 5 – Application Gateway Access log

Application Gateway performance
- Stato di salute degli host che rispondono alle richieste dell’Application Gateway
- Richieste fallite dell’Application Gateway espresso come numero massimo e con il 95° percentile

Figura 6 – Application Gateway performance

Application Gateway Firewall log

Azure Network Security Group Analytics

In Azure è possibile controllare le comunicazioni di rete tramite i Network Security Group (NSG) i quali aggregano una serie di regole (ACL) per consentire oppure negare il traffico di rete basandosi sulla direzione (in ingresso o in uscita), il protocollo, l’indirizzo e la porta sorgente oppure l’indirizzo e la porta di destinazione. I NSG vengono utilizzati per controllare e proteggere le virtual network oppure direttamente le interfacce di rete. Per tutti i dettagli relativi ai NSG è possibile consultare la documentazione ufficiale Microsoft.

Per poter collezionare i log di diagnostica dei Network Security Group in Log Analytics è necessario posizionarsi nel portale Azure sulla risorsa Network Security Group che si intende monitorare e nella sezione Diagnostics logs selezionare l’invio dei log verso il workspace Log Analytics opportuno:

Figura 7 – Abilitazione diagnostica NSG

Figura 8 – Configurazione diagnostica NSG

Sui Network Security Group è possibile raccogliere le seguenti tipologie di log:

Eventi
Contatori relativi alle rule

Giunti a questo punto nell’home page del portale OMS è possibile selezionare il tile di Overview della solution Azure Network Security Group Analytics per accedere ai dati dei NSG raccolti dalla platform:

Figura 9 – Azure Network Security Group Analytics Overview nel portale OMS

La solution mette a disposizione un summary dei log raccolti suddividendoli nelle seguenti categorie:

Network security group blocked flows
- Regole del Network Security Group con traffico bloccato
- Indirizzamenti di rete con regole di traffico bloccato

Figura 10 – Network security group blocked flows

Network security group allowed flows
- Regole del Network security group con traffico consentito
- Indirizzamenti di rete con regole di traffico consentito

Figura 11 – Network security group allowed flows

La metodologia di invio dei log di diagnostica degli Application Gateway e dei Network Security Group di Azure verso Log Analytics è cambiata recentemente introducendo i seguenti vantaggi:

La scrittura dei log in Log Analytics avviene direttamente senza la necessità di utilizzare degli storage account come repository. Si può comunque scegliere di salvare i log di diagnostica sugli storage account, ma non è necessario per l’invio dei dati verso OMS.
La latenza tra il tempo di generazione dei log e la loro consultabilità in Log Analytics è stata ridotta.
Sono stati semplificati gli step necessari per la configurazione.
Tutti le informazioni di diagnostica di Azure sono state uniformate come formato.

Conclusioni

Grazie a una sempre più completa integrazione tra Azure e Operations Management Suite (OMS) è possibile monitorare e controllare lo stato dei componenti dell’infrastruttura di rete realizzata su Azure in modo completo ed efficace, il tutto con passaggi semplici e intuitivi. Questa integrazione della platform Azure con OMS è sicuramente destinata ad arricchirsi con nuove soluzioni specifiche anche per altri componenti. Per chi è interessato ad approfondire ulteriormente questa e altre funzionalità di OMS ricordo che è possibile provare la soluzione OMS gratuitamente.

Windows Server 2016: Configurazione del Cloud Witness in ambito Failover Cluster

Nell’articolo Windows Server 2016: What’s New in Failover Clustering sono state approfondite tutte le principali novità introdotte con Windows Server 2016 in ambito failover clustering. In questo articolo entreremo del dettaglio della configurazione del witness del cluster nel cloud Microsoft Azure, analizzando i possibili scenari supportati e i benefici di questa nuova funzionalità.

Possibili scenari supportati dal Cloud Witness

Tra gli scenari supportati che si prestano maggiormente per questo tipo di configurazione troviamo:

Multi-site stretched cluster.
Failover Cluster che non necessitano di storage condiviso (SQL Always On, Exchange DAGs, etc).
Failover Cluster composti da nodi ospitati su Microsoft Azure, altri cloud pubblici oppure in private cloud.
Cluster di tipologia Scale-out File Server.
Cluster realizzati in realtà small branch-office.

Configurazione del Cloud Witness

Iniziamo con il specificare che un requisito necessario per poter configurare il cluster per l’utilizzo del Cloud Witness è che tutti i nodi che compongono il cluster abbiano un accesso internet verso Azure. Il Cloud Witness infatti utilizza il protocollo HTTPS (porta 443) per stabilire una connessione con il servizio blob dell’Azure Storage Account.

La configurazione del Cloud Witness richiede la presenza di una subscription Azure all’interno della quale configurare uno Storage Account che sarà utilizzato come Cloud Witness e sul quale saranno scritti i blob file utilizzati per l’arbitration del cluster.

Dal portale Azure è necessario creare uno storage account di tipologia Genaral Purpose. Per questo scopo è corretto crearlo con un livello di performance standard in quanto non sono necessarie elevate prestazioni che vengono fornite con l’utilizzo di dischi SSD. Dopo aver selezionato la policy di replica e la location più opportuna si può procedere con il processo di creazione.

Figura 1 – Creazione dello Storage Account

Dopo aver creato lo storage account è necessario recuperare la relativa chiave di accesso necessaria per l’autenticazione, che verrà richiesta negli step successivi di configurazione.

Figura 2 – Chiavi di accesso dello Storage Account

Giunti a questo punto è possibile modificare le impostazioni del Quorum del cluster da Failover Cluster Manager seguendo i passaggi sotto riportati:

Figura 3 – Configurazione delle impostazioni Quorum da Failover Cluster Manager

Figura 4 – Selezione del Quorum Witness

Figura 5 – Selezione del Cloud Witness

Figura 6 – Nome e chiave di accesso dello Storage Account

Al termine della configurazione sarà presente tra le varie risorse del cluster anche il Cloud Witness:

Figura 7 – Risorsa Cloud Witness

Sullo Storage Account di Azure viene creato un container denominato msft-cloud-witness, all’interno del quale sarà presente un unico blob file che ha come nome l’ID univo del cluster. Questo comporta che è possibile utilizzare lo stesso Microsoft Azure Storage Account per configurare il Cloud Witness su cluster differenti, dove sarà presente un blob file per ogni cluster.

Figura 8 – Container presente all’interno dello Storage Account e relativo contenuto

Vantaggi nell’utilizzo del Cloud Witness

L’utilizzo del Cloud Witness consente di ottenere i seguenti vantaggi:

Viene eliminata la necessità di disporre di un ulteriore data center separato per determinate configurazioni cluster utilizzando invece Microsoft Azure.
Viene annullato l’effort amministrativo necessario per mantenere una macchina virtuale aggiuntiva con il ruolo di witness del cluster.
Considerata la quantità ridotta di dati scritti sullo Storage Account il costo del servizio è irrisorio.
Lo stesso Microsoft Azure Storage Account può essere utilizzato come witness per cluster differenti.

Conclusioni

Anche in ambito failover cluster Windows Server 2016 si dimostra pronto per l’integrazione con il cloud. Grazie all’introduzione del cloud Witness è possibile realizzare più facilmente sistemi cluster riducendo sensibilmente i costi complessivi per l’implementazione, l’effort di gestione e aumentando la flessibilità dell’architettura cluster.

Come migrare sistemi verso Microsoft Azure utilizzando OMS Azure Site Recovery

Nell’articolo OMS Azure Site Recovery: panoramica della soluzione sono state presentate le caratteristiche di Azure Site Recovery e sono stati esaminati gli aspetti che la rendono una efficace e flessibile soluzione per la creazione di strategie di business continuity e di disaster recovery per il proprio data center. In questo articolo vedremo come utilizzare Azure Site Recovery per migrare ambienti anche potenzialmente eterogenei verso Microsoft Azure. Sempre più spesso ci si trova infatti di fronte all’esigenza non solo di creare nuove macchine virtuali nella cloud pubblica di Microsoft, ma anche di migrare sistemi già esistenti. Per svolgere queste migrazioni è possibile adottare diverse strategie, tra le quali compare anche Azure Site Recovery (ASR) che ci consente di migrare agilmente macchine virtuali presenti su Hyper-V, VMware, sistemi fisici e workload di Amazon Web Services (AWS) verso Microsoft Azure.

Nella seguente tabella vengono riportati quali scenari di migrazione è possibile affrontare con ASR:

Sorgente	Destinazione	Tipologia di SO Guest supportati
Hyper-V 2012 R2	Microsoft Azure	Tutti i SO guest supportati in Azure
Hyper-V 2008 R2 SP1 and 2012	Microsoft Azure	Windows e Linux *
VMware e Server Fisici	Microsoft Azure	Windows e Linux*
Amazon Web Services (Windows AMIs)	Microsoft Azure	Windows Server 2008 R2 SP1+

* Supporto limitato a Windows Server 2008 R2 SP1+, CentOS 6.4, 6.5, 6.6, Oracle Enterprise Linux 6.4, 6.5, SUSE Linux Enterprise Server 11 SP3

Quando si ha la necessità di effettuare attività di migrazione solitamente è di fondamentale importanza rispettare i seguenti punti:

Ridurre al minimo il tempo di downtime dei workload di produzione durante il processo di migrazione.
Avere la possibilità di testare e validare il funzionamento della soluzione nell’ambiente di destinazione (Azure nel caso specifico) prima di convalidare la migrazione.
Effettuare un’unica migrazione dei dati utile sia per il processo di convalida che per la migrazione vera e propria.

Con ASR tutto ciò è possibile seguendo questo semplice flusso di operazioni:

Figura 1 – Flusso di migrazione con ASR

Vediamo ora nel dettaglio quali sono le operazioni da svolgere in uno scenario di migrazione di macchine virtuali presenti su un host Hyper-V 2012 R2 verso Microsoft Azure.

Come prima cosa dal portale Azure è necessario creare un Recovery Service Vault nella subscription sulla quale si desidera migrare le macchine virtuali:

Figura 2 – Creazione Recovery Service Vault

In seguito è necessario preparare l’infrastruttura per poter utilizzare Azure Site Recovery. Il tutto è possibile farlo seguendo la procedura guidata proposta dal portale Azure:

Figura 3 – Preparazione infrastruttura

Dopo aver dichiarato lo scenario di migrazione (macchine virtuali su host Hyper-V non gestito da SCVMM verso Azure), assegno un nome al site Hyper-V e associo ad esso l’host Hyper-V che detiene le macchine virtuali:

Figura 4 – Preparazione Source: step 1.1

Figura 5 – Preparazione Source: step 1.2

Giunti a questo punto è necessario installare sull’host Hyper-V il provider Microsoft Azure Site Recovery. Durante l’installazione è possibile specificare un server proxy e la chiave di registrazione al vault, la quale è necessario scaricarla direttamente dal portale Azure:

Figura 6 – Installazione provider ASR

Figura 7 – Configurazione accesso al vault

Figura 8 – Impostazioni proxy

Figura 9 – Registrazione al vault ASR

Dopo aver atteso qualche istante il server Hyper-V appena registrato al vault di Azure Site Recovery comparirà sul portale Azure:

Figura 10 – Preparazione Source: step 2

Lo step successivo richiede di specificare su quale subscription Azure verranno create le macchine virtuali e il modello di deployment (Azure Resource Manager – ARM nel caso riportato). A questo punto è importante verificare che sia presente uno storage account e una virtual network su cui attestare le macchine virtuali:

Figura 11 – Preparazione Target

Lo step seguente consente di specificare quale policy di replica associare al site. Nel caso non siano presenti policy in precedenza create è opportuno configurare una nuova policy stabilendo i parametri riportati in seguito, più idonei al proprio ambiente:

Figura 12 – Impostazione policy di replica

Figura 13 – Associazione alla policy di replica

L’ultimo step di preparazione dell’infrastruttura richiede l’esecuzione del Capacity Planner, strumento molto utile per stimare l’utilizzo di banda e di storage. Inoltre permette di valutare una serie di altri aspetti che è necessario prendere bene in considerazione in scenari di replica per evitare problematiche. Lo strumento può essere scaricato direttamente dal portale Azure:

Figura 14 – Capacity planning

Giunti a questo punto sono state completate tutte le operazioni di configurazione e preparazione dell’infrastruttura ed è possibile proseguire selezionando quali macchine si desidera replicare dal site precedentemente configurato:

Figura 15 – Abilitazione replica

Nello step successivo è possibile selezionare le configurazioni delle macchine replicate in termini di Resource Group, Storage Account e Virtual Network – Subnet:

Figura 16 – Impostazioni di recovery del target

Tra tutte le macchine ospitate sull’host Hyper-V è opportuno selezionare per quali si desidera attivare la replica verso Azure:

Figura 17 – Selezione VMs da replicare

Per ogni macchina virtuale selezionata è necessario specificare il sistema operativo guest (Windows oppure Linux), qual’è il disco che detiene il sistema operativo e quali dischi dati si vuole replicare:

Figura 18 – Proprietà delle VMs in replica

Dopo aver concluso la configurazione di tutti gli step inizierà il processo di replica secondo le impostazioni configurate nella policy specifica:

Figura 19 – Step di replica

Terminata la replica iniziale è consigliato verificare che la macchina virtuale funzioni regolarmente in ambiente Microsoft Azure effettuando un “Test Failover” (punto 1 dell’immagine seguente) e dopo aver svolto i controlli opportuni è necessario effettuare un “Planned Failover” (punto 2) per avere la macchina virtuale disponibile e pronta per essere utilizzata in ambiente di produzione. Al termine di questa operazione può ritenersi completata la migrazione verso Azure del vostro sistema e sarà possibile rimuovere la configurazione della replica all’interno del Recovery Service Vault (punto 3).

Figura 20 – Finalizzazione del processo di migrazione

Conclusioni

Azure Site Recovery con semplici passaggi guidati ci consente di migrare facilmente, in modo sicuro e con un downtime minimo sistemi che si trovano presso i propri datacenter oppure workload presenti in Amazon Web Services (AWS) verso Microsoft Azure. Vi ricordo che le funzionalità di Azure Site Recovery possono essere testate attivando un ambiente trial di Operations Management Suite oppure di Microsoft Azure.