Archivi categoria: Microsoft Azure

Azure Backup: la protezione dei sistemi Linux in Azure

Azure Backup è una soluzione per la protezione del dato basata sul cloud Microsoft che, mettendo a disposizione diversi componenti, consente di effettuare il backup dei dati, indipendentemente dalla loro locazione geografica (on-premises oppure nel cloud) verso un Recovery Service vault in Azure. In questo articolo verranno esaminati gli aspetti principali riguardanti la protezione delle macchine virtuali Linux presenti in Microsoft Azure, utilizzando Azure Backup.

Nello scenario di protezione di macchine virtuali Azure Iaas (Infrastructure as a Service) non è necessario nessun server di backup, ma la soluzione è completamente integrata nella fabric di Azure e sono supportate tutte le distribuzioni Linux approvate per essere eseguite in ambiente Azure, ad eccezione di Core OS. Anche la protezione di altre distribuzioni Linux è consentita purché ci sia la possibilità di installare sulla macchina virtuale il VM agent e sia presente il supporto per Python.

Come avviene la protezione dei sistemi Linux su Azure

Sui sistemi Linux viene installata, durante l’esecuzione del primo job di backup, una extension specifica denominata VMSnapshotLinux, attraverso la quale Azure Backup, durante l’esecuzione dei job, pilota la creazione di snapshot che vengono trasferite verso il Recovery Service vault.

Figura 1 – Principi di esecuzione del backup di VM Azure IaaS con Azure Backup

Per avere una protezione del dato efficace è opportuno riuscire ad effettuare backup consistenti a livello applicativo. Azure Backup di default per le macchine virtuali Linux crea dei backup consistenti a livello di file system ma può essere configurato anche per creare dei backup application-consistent. Sui sistemi Windows questo avviene utilizzando il componente VSS, mentre per le VM Linux viene messo a disposizione uno scripting framework grazie al quale è possibile eseguire dei pre-script e dei post-script per controllare l’esecuzione dei backup.

Figura 2 – Application-consistent backup nelle VM Linux di Azure

Azure Backup prima di avviare il processo di creazione della snapshot della macchina virtuale richiama il pre-script, se questo si completa con esito positivo viene creata la snaspshot, al termine del quale viene eseguito il post-script. Si tratta di script completamente personalizzabili dall’utente e che devono essere creati in base alle caratteristiche dell’applicativo specifico presente a bordo della macchina virtuale. Per maggiori dettagli a riguardo è possibile consultare la documentazione ufficiale Microsoft.

Come abilitare il backup delle macchine virtuali Linux su Azure

Recentemente è stata introdotta la possibilità di abilitare dal portale Azure la protezione delle macchine virtuali già dal momento della creazione:

Figura 3 – Abilitazione backup durante la creazione della VM

In alternativa è possibile abilitare la protezione post creazione della macchina virtuale selezionandola direttamente dal Recovery Service vault oppure accedendo al blade della VM nella sezione Operations – Backup. Dallo stesso pannello è possibile visualizzare lo stato di esecuzione dei backup.

File Recovery nelle macchine Linux in Azure

Azure Backup, oltre alla possibilità di effettuare il restore dell’intera macchina virtuale, consente anche per i sistemi Linux di effettuare il ripristino del singolo file utilizzando la funzionalità di File Recovery. Per effettuare questa operazione è possibile effettuare la procedura riportata in seguito.

Dal portale Azure, si seleziona la macchina virtuale per la quale si ha la necessità di ripristinare il file e nella sezione Backup si avvia il task di File Recovery:

Figura 4 – Avvio del processo di File recovery

A questo punto compare il pannello dove è necessario selezionare il Recovery Point che si desidera utilizzare per l’operazione di ripristino. In seguito occorre premere il pulsante Download Script il quale genera uno script con estensione .sh, e la relativa password, che viene utilizzato per effettuare il mount del recovery point come disco locale del sistema.

Figura 5 – Selezione del Recovery Point e Download dello script

Lo script dovrà essere copiato sulla macchina Linux e per farlo è possibile utilizzare WinSCP:

Figura 6 – Copia dello script sulla macchina Linux

Accedendo al sistema Linux in modalità terminal è necessario assegnare allo scritpt copiato i permessi di esecuzione, tramite il comando chmod +x e successivamente è possibile eseguire lo script:

Figura 7 – Esecuzione dello script per il File Recovery

Nel momento dell’esecuzione lo script richiede la password che viene mostrata dal portale Azure ed in seguito procede con le operazioni necessarie per effettuare la connessione del recovery point tramite canale iSCSI ed il mount come file system.

A questo punto è possibile accedere al percorso del mount point che espone il recovery point selezionato e ripristinare oppure consultare i file necessari:

Figura 8 – Accesso al percorso del mount point

Dopo aver completato le operazioni di ripristino è opportuno effettuare l’unmount dei dischi tramite l’apposito pulsante dal portale Azure (in ogni caso la connessione verso il mountpoint viene chiusa in modo forzato dopo 12 ore) ed è necessario eseguire lo script con il parametro -clean per rimuover il percorso del recovery point dalla macchina.

Figura 9 – Unmount dei dischi e rimozione mount point dalla macchina

Nel caso sulla VM per la quale si desidera ripristinare i file siano presenti partizioni LVM oppure Array RAID è necessario eseguire la stessa procedura, ma su una macchina Linux differente per evitare conflitti nei dischi.

Conclusioni

Azure Backup è una soluzione completamente integrata nella fabric Azure che consente di proteggere facilmente e con estrema efficacia anche le macchine virtuali Linux presenti su Azure. Il tutto avviene senza la necessità di implementare infrastrutture complesse per la protezione del dato. Azurer Backup consente inoltre di proteggere numerosi sistemi su larga scala e di mantenere un controllo centralizzato della propria architettura di protezione del dato.

OMS e System Center: novità di Gennaio 2018

Il nuovo anno è iniziato con diversi annunci da parte di Microsoft riguardanti novità relative a Operations Management Suite (OMS) e System Center. In questo articolo verranno riepilogate in modo sintetico con i riferimenti necessari per poter effettuare maggiori approfondimenti in merito.

Operations Management Suite (OMS)

Log Analytics

Il rilascio dell’IT Service Management Connector (ITSMC) per Azure consente di avere una integrazione bi-direzionale tra gli strumenti di monitor di Azure e le soluzioni di ITSMC come: ServiceNow, Provance, Cherwell, e System Center Service Manager. Grazie a questa integrazione è possibile:

Creare o aggiornare work-items (event, alert, incident) nelle soluzioni di ITSM sulla base degli alert presenti in Azure (Activity Log Alerts, Near Real-Time metric alerts and Log Analytics alerts).
Consolidare in Azure Log Analytics i dati relativi a Incident e Change Request.

Per configurare questa integrazione è possibile consultare la documentazione ufficiale Microsoft.

Figura 1 – ITSM Connector dashboard della solution di Log Analytics

Agente

Questo mese la nuova versione dell’agente OMS per sistemi Linux risolve importanti bug introducendo anche una versione aggiornata dei componenti SCX e OMI. Visto il numero importante di bug fix incluso in questa versione il consiglio è di valutare l’adozione di questo l’aggiornamento. Per ottenere la versione aggiornata dell’agente OMS è possibile accedere alla pagina ufficiale GitHub OMS Agent for Linux Patch v1.4.3-174.

Figura 2 – Elenco Bug Fix e novità del nuovo agente OMS per Linux

Azure Backup

Durante la procedura di creazione delle macchine virtuali dal portale Azure è stata introdotta la possibilità di abilitarne la protezione tramite Azure Backup:

Figura 3 – Abilitazione del backup durante la creazione di una VM

Questa possibilità migliora in modo considerevole l’experience di creazione delle macchina virtuali dal portale Azure.

Azure Site Recovery

Azure Site Recovery consente di gestire diversi scenari per implementare piani di Disaster Recovery, tra cui la replica di macchine virtuali VMware verso Azure. In questa ambito sono state introdotte le seguenti importanti novità:

Rilascio di un template nel formato Open Virtualization Format (OVF) per effettuare il deployment del ruolo Configuration Server. Questo consente di effettuare il deployment del template nella propria infrastruttura di virtualizzazione ed avere un sistema dotato di tutto il software necessario già preinstallato, ad eccezione di MySQL Server 5.7.20 e della VMware PowerCLI 6.0, per velocizzare il deployment e la registrazione al Recovery Service Vault del Configuration Server.
Introdotto nel Configuration Server un portale web per pilotare le principali azioni di configurazione necessarie come le impostazioni del server proxy, i dettagli e le credenziali per accedere al server vCenter e la gestione delle credenziali per installare oppure aggiornare il Mobility Service sulle macchine virtuali coinvolte nel processo di replica.
Migliorata l’experience per effettuare il deployment del Mobility Service sulle macchine virtuali. A partire dalla versione 9.13.xxxx.x del Configuration Server vengono infatti utilizzati i VMware tools per installare ed aggiornare il Mobility Service su tutte le macchine virtuali VMware protette. Questo comporta che non è più necessario aprire le porte del firewall per i servizi WMI e File and Printer Sharing sui sistemi Windows, in precedenza utilizzati per effettuare l’installazione push del Mobility Service.

Le funzionalità di monitoring incluse in modo nativo in Azure Site Recovery sono state notevolmente arricchite per avere una visibilità completa ed immediata. Il pannello Overview dei Recovery Service Vault è ora strutturato, per la sezione Site Recovery, nel modo seguente:

Figura 4 – Azure Site Recovery dashboard

Queste le varie sezioni presenti, le quali si aggiornano in automatico ogni 10 minuti:

Switch between Azure Backup and Azure Site Recovery dashboards
Replicated Items
Failover test success
Configuration issues
Error Summary
Infrastructure view
Recovery Plans
Jobs

Per maggiori dettagli in merito alle varie sezioni è possibile consultare la documentazione ufficiale oppure visualizzare questo breve video.

Known Issues

Si segnala la seguente possibile problematica nell’esecuzione dei backup delle macchine virtuali Linux su Azure. L’error code restituito è UserErrorGuestAgentStatusUnavailable ed è possibile seguire questo workaround per risolvere la condizione di errore.

System Center

System Center Configuration Manager

Rilasciata la versione 1801 per il branch Technical Preview di System Center Configuration Manager: Update 1801 for Configuration Manager Technical Preview Branch.

Tra le novità introdotte in questo rilascio troviamo:

Possibilità di importare ed eseguire signed scripts e di monitorare il risultato dell’esecuzione.
I distribution point possono essere spostati tra differenti primary site e da un secondary site ad un primary site.
Miglioramento nei client settings per il Software Center, con la possibilità di visualizzare una preview prima di farne il deployment.
Nuove impostazioni relative a Windows Defender Application Guard (a partire da Windows 10 versione 1709).
Possibilità di visualizzare una dashboard con le informazioni relative al co-management.
Phased Deployments.
Supporto per hardware inventory string di lunghezza superiore a 255 caratteri.
Miglioramenti relativi alle schedulazioni delle Automatic Deployment Rule.

Si ricorda che i rilasci nel Technical Preview Branch consentono di valutare in anteprima le nuove funzionalità di SCCM ed è consigliato applicare questi aggiornamenti solo in ambienti di test.

Inoltre per System Center Configuration Manager current branch, versione 1710 è stato rilasciato un update rollup che contiene un numero considerevole di bug fix.

Valutazione di OMS e System Center

Si ricorda che per testare e valutare in modo gratuito Operations Management Suite (OMS) è possibile accedere a questa pagina e selezionare la modalità che si ritiene più idonea per le proprie esigenze.

Per provare i vari componenti di System Center 2016 è possibile accedere a l’Evaluation Center e dopo essersi registrati è possibile avviare il periodo di trial.

Service Map in Operations Management Suite: introduzione alla soluzione

In un mondo IT sempre più eterogeno e in continua evoluzione, con architetture ibride e distribuite tra sistemi on-premises e cloud provider pubblici, è di fondamentale importanza poter adottare soluzioni in grado di gestire le operations, monitorare in modo efficace l’intero ambiente e facilitare eventuali attività di troubleshooting. Operations Management Suite (OMS) è lo strumento di IT management di casa Microsoft, ideato nell’era del cloud, che include differenti soluzioni pensate proprio per questi scopi.

In questo articolo verranno descritte le caratteristiche principali della soluzione Service Map presente in Operations Management Suite (OMS) e sarà riportata la procedura da seguire per configurare Service Map ed effettuare l’onboarding degli agenti.

Che cos’è Service Map ?

Service Map è una soluzione che è possibile attivare in OMS in grado di effettuare in automatico il discovery dei componenti applicativi, presenti sia su sistemi Windows che Linux, e di creare una mappa che riporta pressoché in tempo reale le comunicazioni presenti tra i vari servizi. Il tutto consente di visualizzare i server come sistemi tra di loro interconnessi che erogano dei servizi. Service Map mostra nel dettaglio le connessioni TCP presenti tra i vari sistemi, con i riferimenti dei processi coinvolti nelle comunicazioni e le relative porte utilizzate. Questa consente di determinare e isolare facilmente eventuali problemi e di verificare i tentativi di comunicazione che vengono tentati dai vari sistemi per individuare eventuali connessioni non desiderate oppure problemi nell’istaurare comunicazioni necessarie. Questa soluzione risulta utile anche quando si devono approcciare scenari di migrazione dei sistemi verso il cloud per considerare tutte le connessioni necessarie per il corretto funzionamento dell’applicativo, senza tralasciare nessun aspetto.

Figura 1 – Esempio di schema generato da Service Map

Attivazione della soluzione

Accedendo al portale OMS è possibile aggiungere facilmente la solution Service Map, presente nella gallery, seguendo gli step documentati nel seguente articolo: Aggiungere soluzioni di gestione di Operations Management Suite (OMS).

Figura 2 – Aggiunta della solution Service Map

L’attivazione di Service Map non richiede configurazioni specifiche ma è necessario installare su ogni sistema un agente specifico chiamato Microsoft Dependency Agent, grazie al quale vengono recuperate le informazioni necessarie dalla soluzione. Il Microsoft Dependency Agent può essere installato solo su piattaforme a 64 bit e richiede come requisito la presenza dell’agente OMS. L’agente di Service Map non trasmette in modo diretto nessuna informazione verso il workspace OMS e di conseguenza non è richiesta l’apertura di porte specifiche verso l’esterno. I dati verso Service Map vengono infatti sempre e comunque inviati dall’agente OMS, in modo diretto oppure tramite un OMS gateway:

Figura 3 – Comunicazione dei dati verso Service Map

Al momento dell’attivazione di Service Map in un workspace OMS, il management pack Microsoft.IntelligencePacks.ApplicationDependencyMonitor viene inviato a tutti i sistemi Windows presenti nel workspace.

Installazione del Microsoft Dependency Agent sui sistemi Windows

L’installazione del Microsoft Dependency Agent sui sistemi Windows avviene richiamando, con privilegi amministrativi, l’eseguibile InstallDependencyAgent-Windows.exe che può essere scaricato a questo indirizzo. Questo eseguibile prevede l’installazione interattiva tramite un Wizard oppure è possibile utilizzare il parametro /S per installare l’agente di Service Map in modo completamente silent, utile nel caso si voglia effettuare l’attivazione su più sistemi tramite script.

Installazione del Microsoft Dependency Agent sui sistemi Linux

Sui sistemi Linux l’installazione del Microsoft Dependency Agent avviene attraverso l’esecuzione, con permessi di root, di uno shell script contenuto nel binario InstallDependencyAgent-Linux64.bin, che si può ottenere accedendo a questo indirizzo. Anche in questo caso è prevista l’installazione silent senza interazione dell’utente, tramite il parametro -s.

Per i sistemi presenti su Azure è possibile effettuare il deploy del Microsoft Dependency Agent anche tramite una specifica Azure VM Extension. L’extension è disponibile sia per sistemi Windows che Linux e può esserne fatto il deploy sia tramite script PowerShell che tramite un template JSON nella modalità Azure Resource Manager (ARM).

Per verificare che l’installazione dell’agent di Service Map sia andata a buon fine è possibile controllare che siano presenti ed in esecuzione i seguenti componenti:

Servizio “Microsoft Dependency Agent” sui sistemi Windows.
Daemon “microsoft-dependency-agent” su macchine Linux.

Il Microsoft Dependency Agent invia dati tramite l’agente OMS ogni 15 secondi e in base alla complessità dell’ambiente ogni agente può trasmettere approssimativamente 25 MB al giorno di informazioni relative alla solution Service Map. Per l’agente Service Map si può stimare un utilizzo di risorse pari allo 0,1 percento della memoria di sistema e allo 0,1 percento della CPU del sistema.

Note e risorse relative alla soluzione Service Map

Come utilizzare dal punto di vista operativo Service Map è illustrato molto bene e nel dettaglio in questo documento ufficiale Microsoft. Inoltre per entrare nello specifico del funzionamento di Service Map è possibile consultare questo articolo che mostra le principali caratteristiche tramite una demo pratica.

Service Map al momento è disponibile solo nelle seguenti region di Azure: East US, West Europe, West Central US e Southeast Asia.

Costi della soluzione

Service Map è incluso nel pacchetto Insight & Analytics e il licenziamento può rientrare nel piano free (fino ad un massimo di 5 sistemi Service Map) oppure avviene per nodo. Per maggiori informazioni è possibile consultare la pagina relativa al pricing di OMS.

Conclusioni

Service Map è un’utile soluzione che può essere utilizzata per migliorare la visibilità sui flussi applicativi, valutare l’impatto di manutenzioni sui singoli sistemi e migliorare i tempi di troubleshooting a fronte di fault. L’attivazione di Service Map è tecnicamente molto semplice e il valore aggiunto fornito da questa soluzione è considerevole potendo consultare in qualsiasi momento una mappa di interconnessione dei propri sistemi completa ed aggiornata, indipendentemente dalla loro locazione geografica.

Si ricorda che è possibile testare e valutare in modo gratuito Operations Management Suite (OMS) accedendo a questa pagina e selezionando la modalità che si ritiene più idonea per le proprie esigenze.

System Center Virtual Machine Manager 1711: la gestione delle macchine virtuali in Azure

Come già avviene per il sistema operativo a partire dal prossimo anno anche per i prodotti System Center Microsoft rilascerà delle versioni aggiornate ogni 6 mesi (semi-annual channel). L’obiettivo principale di rilasciare nuove versioni di prodotto con una maggiore frequenza è di migliorare il supporto per ambienti sempre più eterogenei, aumentando la user experience, le performance e la stabilità, e garantire una pronta integrazione con il mondo cloud.

Figura 1 – Cadenza di rilascio delle release dei prodotti System Center

L’unica eccezione è data da Configuration Manager che continuerà a rispettare il rilascio di 3 versioni ogni anno per meglio supportare l’integrazione con Intune.

System Center 1801 introdurrà nuove funzionalità per quanto riguarda Operations Manager, Virtual Machine Manager e Data Protection Manager, mentre per Orchestrator \ SMA e Service Manager comprenderà solo degli aggiornamenti relativi alla security ed alla risoluzione di problematiche.

Nel mese di novembre è stata annunciata la preview della nuova versione di System Center (versione 1711) che è possibile scaricare a questo indirizzo per valutare in anteprima le nuove funzionalità che saranno introdotte con il prossimo anno.

In questo articolo verranno approfondite le novità apportate alla funzionalità presente in Virtual Machine Manager che consente di gestire dalla console di SCVMM le macchine virtuali Azure. Con la versione attuale di Virtual Machine Manager questa funzionalità risulta essere ormai limitata in quanto supporta solamente la gestione delle macchine virtuali create con il modello di deployment definito Azure Service Management (ASM) e solamente per le region di Azure pubbliche. Anche il processo di autenticazione deve avvenire necessariamente tramite management certificate. In SCVMM 1711 (Technical Preview) l’integrazione per gestire le macchine virtuali in Azure si estende introducendo le seguenti novità:

Supporto per le macchine virtuali create utilizzando il modello di deployment Azure Resource Manager (ARM).
Autenticazione in Azure Active Directory e non solo basata su certificati.
Gestione di subscription presenti non solo nelle region pubbliche di Azure, ma anche in specifiche region come Germania, Cina e US Government.

In seguito viene riportata la procedura da seguire per configurare questa integrazione utilizzando come processo di autenticazione e di autorizzazione Azure Active Directory. Questo metodo di autenticazione risulta necessario per poter gestire sia macchine virtuali Azure create nella modalità classic (ASM) che in modalità ARM. Per effettuare questa configurazione è necessario creare a priori una Azure AD Application e assegnare i permessi necessari di accesso alla subscription Azure. Per creare l’application è possibile seguire gli step riportati nel dettaglio nella documentazione ufficiale Microsoft.

Figura 2 – Aggiunta di una nuova Azure Active Directory Application

Dopo aver creato l’Azure AD Application è opportuno prendere nota del relativo Application ID ed è necessario generare una nuova Application Key. Questi valori verranno richiesti dal wizard di configurazione di SCVMM:

Figura 3 – Application ID e generazione di una chiave di autenticazione

L’Azure AD Application dovrà appartenere a un ruolo che gli consenta di gestire le macchine virtuali della subscription Azure. Per questo motivo è necessario associare l’App appena creata al ruolo Virtual Machine Contributor sull’Azure subscription desiderata.

Figura 4 – Assegnazione del ruolo “Virtual Machine Contributor” all’Azure AD App

Accedendo alla console di Virtual Machine Manager, dal workspace VMs and Services è possibile aggiungere una o più subscription Azure:

Figura 5 – Aggiunta della subscription Azure dalla console SCVMM

La schermata di configurazione richiede l’inserimento dei dati relativi alla subscription e le informazioni per effettuare il processo di autenticazione tramite Azure AD App:

Figura 6 – Dati subscription e informazioni per l’autenticazione tramite Azure AD

Al termine di questa configurazione verranno mostrate nella console di Virtual Machine Manager le macchine virtuali presenti nella subscription Azure configurata. Su queste macchine virtuali al momento è possibile effettuare solamente i seguenti task basilari: Start, Stop, Stop e Deallocate, Restart e avvio della connessione RDP. Inoltre per ogni macchina virtuale vengono riportate alcune informazioni relative alla configurazione nell’ambiente Azure.

Figura 7 – Gestione delle macchine virtuali Azure dalla console di SCVMM

Conclusioni

Avere in un’unica console tutte le macchine virtuali, comprese quelle presenti in Azure, consente agli amministratori di gestire, anche solo con semplici task, in modo facile e con una maggiore rapidità ambienti ibridi. Al momento si tratta di una integrazione basilare ma grazie a un ciclo di rilascio sempre più rapido previsto anche per Virtual Machine Manager è molto probabile che questa integrazione possa essere ampliata sempre di più.

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.