Archivi categoria: Microsoft Azure

Azure Backup: la protezione di SQL Server sulle macchine virtuali in Azure

Azure Backup si arricchisce con una nuova importante funzionalità che consente di proteggere in modo nativo i workload SQL, in esecuzione sulle macchine virtuali IaaS che risiedono su Azure. In questo articolo si esploreranno i benefici introdotti e le caratteristiche di questa nuova funzionalità.

Figura 1 – Protezione con Azure Backup di SQL Server su VMs Azure

Azure Backup ci ha da sempre abituato ad un approccio cloud-first consentendo di effettuare la protezione dei sistemi in modo rapido, sicuro ed efficace. La protezione di SQL Server sulle macchine virtuali IaaS di Azure fornisce una soluzione unica nel suo genere, caratterizzata dai seguenti elementi:

  • Zero-infrastructure backup: non è necessario gestire una infrastruttura di backup classica, composta dal server di backup, dai vari agenti installati sui sistemi e dallo storage su cui risiedono i backup. Inoltre, non è nemmeno richiesto l’utilizzo di script di backup, spesso necessari in altre soluzioni di backup, per la protezione di SQL Server.
  • Monitor dei backup tramite Recovery Services Vault: utilizzando la dashboard è possibile monitorare facilmente e in modo intuitivo i vari job di backup per tutte le tipologie di workload protetti: Azure IaaS VMs, Azure Files e SQL server databases. Risulta inoltre possibile configurare notifiche via mail a fronte di operazioni di backup o restore non andate a buon fine.
  • Gestione centralizzata: si ha la possibilità di configurare delle policy di protezione comuni, utilizzabili per database che risiedono su server distinti, dove viene definita la schedulazione e la retention per i backup short-term e long-term.
  • Restore dei DB a una data e ora precisa: grazie ad una intuitiva interfaccia grafica viene consentito all’operatore di effettuare il restore selezionando il recovery point più opportuno per la data selezionata. Azure Backup si preoccuperà di gestire il ripristino del backup full, differenziale e della catena dei backup log per poter ottenere il ripristino del database all’ora selezionata.
  • Recovery Point Objective (RPO) di 15 minuti: si può effettuare il backup dei transaction log con una frequenza di 15 minuti.
  • Servizio Pay as you go (PAYG): la fatturazione avviene mensilmente sulla base dei consumi e non sono previsti costi anticipati per il servizio.
  • Integrazione nativa con le API di SQL Server: Azure Backup richiama le API native della soluzione per garantire una elevata efficienza e affidabilità delle operazioni svolte. I job di backup possono essere consultati anche utilizzando SQL Server Management Studio (SSMS).
  • Supporto per gli Always On Availability Group: la soluzione è in grado di effettuare il backup dei database che risiedono all’interno di un Availability Group (AG), garantendo la protezione in caso di eventi di failover, onorando la backup preference impostata a livello di AG.

Questa nuova funzionalità supporta al momento le seguenti versioni del sistema operativo e di SQL Server, indipendentemente che siano VMs generate da una immagine del marketplace o meno (installazione di SQL Server effettuata manualmente).

Sistemi Operativi supportati

  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Server 2016

Linux, al momento, non è supportato.

VersioniEdizioni di SQL Server supportate

  • SQL 2012 Enterprise, Standard, Web, Developer, Express
  • SQL 2014 Enterprise, Standard, Web, Developer, Express
  • SQL 2016 Enterprise, Standard, Web, Developer, Express
  • SQL 2017 Enterprise, Standard, Web, Developer, Express

Per poter usufruire di questa funzionalità devono essere rispettati i seguenti requisiti:

  • Disporre di un Recovery Services vault nella stessa region Azure dove risiede la macchina virtuale che ospita i database SQL da proteggere.
  • La macchina virtuale con SQL Server necessità di connettività verso gli IP pubblici di Azure.
  • Sulla macchina virtuale che detiene i database da proteggere devono essere presenti specifiche impostazioni. Azure Backup richiede la presenza della VM extension AzureBackupWindowsWorkload. Tale extension viene installata sulla macchina virtuale durante il processo di discovery e consente la comunicazione con il servizio di Azure Backup. L’installazione dell’extension comporta la creazione sulla VM, da parte di Azure Backup, del Windows virtual service account denominato NT Service\AzureWLBackupPluginSvc. Questo virtual service account necessita permessi di log in e di sysadmin lato SQL, per proteggere i database.

Per abilitare il backup dei workload SQL a bordo delle macchine virtuali Azure è necessario effettuare un processo di discovery e successivamente è possibile configurare le politiche di protezione.

Processo di discovery

Si riporta la procedura da seguire, accedendo al portale Azure, per abilitare il discovery dei database:

Figura 2 – Avvio del processo di discovery

Figura 3 – Discovery in progress

Figura 4 – Discovery dei DBs sui sistemi selezionati

 

Configurazione dei backup di SQL

Completata la fase di discovery dei database è possibile procedere con la configurazione dei backup di SQL Server.

Figura 5 – Avvio della configurazione dei backup, post discovery dei DBs nelle VMs

Figura 6 – Selezione dei DBs da proteggere

Figura 7 – Creazione della policy che definisce la tipologia di backup di SQL e la retention dei dati

Figura 8 – Abilitazione del backup

 

Monitor dei backup e processo di restore

Figura 9 – Dashboard del Recovery Service vault

Figura 10 – Numero di backup items di SQL a bordo delle VMs Azure

Figura 11 – Stato dei backup di SQL

Selezionando il singolo DB è possibile avviare il processo di restore.

Figura 12 – Avvio del processo di restore del DB

Figura 13 – Selezione della destinazione dove ripristinare il DB

Figura 14 – Selezione del restore point da utilizzare

Figura 15 – Configurazione delle impostazioni di restore e delle directory dove posizionare i file

Figura 16 – Avvio del job di restore

 

Costo della soluzione

Il costo per la protezione di SQL Server in Azure Backup è dato dal numero di istanze protette (singole VMs Azure oppure Availability Groups). Il costo di una singola istanza protetta dipende dal size, il quale è determinato dalla dimensione complessiva dei vari DB protetti (senza tenere in considerazione il fattore di compressione e l’encryption). A questo costo è da aggiungere il costo dello storage Azure effettivamente consumato. Si tratta di Block Blob Storage di tipologia locally redundant storage (LRS) oppure geo-redundant storage (GRS). Per maggiori dettagli sui costi è possibile consultare la pagina ufficiale Microsoft.

 

Conclusioni

Azure Backup si arricchisce con una importante funzionalità e conferma di essere un’ottima soluzione enterprise per la protezione dei sistemi, ovunque essi si trovino. Grazie a questa funzionalità Azure si distingue da qualsiasi altro cloud pubblico, mettendo a disposizione una soluzione per la protezione di SQL Server a bordo delle macchine virtuali IaaS, totalmente integrata nella platform. Per maggiori informazioni sulla soluzione Azure Backup è possibile consultare la documentazione ufficiale.

Tutto quello che bisogna sapere sui nuovi Load Balancer di Azure

Microsoft ha recentemente annunciato la disponibilità in Azure degli Standard Load Balancer. Si tratta di load balancer Layer-4, per i protocolli TCP e UDP che, rispetto ai Basic Load Balancer, introducono dei miglioramenti e consentono di avere un controllo più granulare di determinate funzionalità. In questo articolo verranno riportate le caratteristiche principali degli Standard Load Balancer di Azure, al fine di poter avere gli elementi necessari per scegliere la tipologia di bilanciatore più opportuna per le proprie esigenze.

Qualsiasi scenario dove è possibile utilizzare la SKU Basic degli Azure Load Balancer, può essere soddisfatto anche utilizzando la SKU Standard, ma le due tipologie di bilanciatori presentano importanti differenze in termini di scalabilità, funzionalità, livelli di servizio garantito e costo.

Scalabilità

I Load Balancer Standard hanno una maggiore scalabilità, rispetto ai Basic Load Balancer, per quanto riguarda il numero massimo delle istanze (IP Configuration) che possono essere configurate nei pool di backend. La SKU Basic consente di avere fino a 100 istanze, mentre utilizzando la SKU Standard il numero massimo di istanze è pari a 1000.

Funzionalità

Backend pool

Per quanto riguarda i Basic Load Balancer, nei pool di backend, possono risiedere in modo esclusivo:

  • Macchine virtuali che si trovano all’interno di un availability set.
  • Una singola VM standalone.
  • Virtual Machine Scale Set.

Figura 1 – Associazioni possibili nei backend pool dei Basic Load Balancer

Negli Standard Load Balancer invece è consentito inserire nei pool di backend qualsiasi macchina virtuale attestata su una determinata virtual network. Lo scope di integrazione in questo caso non è infatti l’availability set, come per i load balancer Basic, ma è la virtual network e tutti i relativi concetti ad essa associati. Un requisito da tenere in considerazione, per poter inserire nei backend pool degli Standard Load Balancer le macchine virtuali, è che queste non devono avere IP pubblici associati oppure devono avere IP Pubblici con SKU Standard.

Figura 2 – Associazione nei backend pool degli Standard Load Balancer

Availability Zones

Gli Standard Load Balancer contemplano scenari di integrazione con le Availability Zones, nelle region che comprendono questa funzionalità. Per maggiori dettagli a riguardo è possibile consultare questo specifico documento Microsoft, che riporta i concetti principali e le linee guida di implementazione.

Alta disponibilità delle porte

I load balancer con SKU Standard, di tipologia “Internal”, consentono di bilanciare i flussi TCP e UDP su tutte le porte simultaneamente. Per farlo, nella regola di load-balancing, c’è la possibilità di abilitare l’opzione “HA Ports”:

Figura 3 – Configurazione rule di bilaciamento con opzione “HA Ports” abilitata

Il bilanciamento avviene per flusso, il quale è determinato dai seguenti elementi: source IP address, source port, destination IP address, destination port, e protocollo. Questa funzionalità risulta particolarmente utile in scenari dove vengono utilizzate delle Network Virtual Appliances (NVAs) che richiedono scalabilità. Questa nuova funzionalità consente di migliorare le attività richieste relative ad implementazioni in HA delle NVAs.

Figura 4 – Architettura di rete che prevede l’utilizzo del LB con opzione “HA Ports” abilitata

Un altro possibile utilizzo di questa funzionalità è quando si ha la necessità di bilanciare un elevato numero di porte.

Per maggiori dettagli in merito all’opzione “HA Ports” è possibile consultare la documentazione ufficiale.

Diagnostica

I Load Balancer Standard introducono le seguenti funzionalità in termini di capacità diagnostica:

  • Multi-dimensional metrics: si possono recuperare differenti metriche che consentono di consultare, in tempo reale, lo stato di utilizzo dei load balancer, sia pubblici che interni. Queste informazioni risultano particolarmente utili anche per operazioni di troubleshooting.

Figura 5 – Metriche dei Load Balancer dal portale Azure

  • Resource Health: in Azure Monitor si ha la possibilità di consultare lo stato di salute dei Load Balancer Standard (al momento disponibile solo per i Load Balancer Standard di tipologia Public).

Figura 6 – Resource health del Load Balancer in Azure Monitor

Si può inoltre consultare lo storico dello stato di health:

Figura 7 – Health history del Load Balancer

Tutti i dettagli relativi alla diagnostica, dei Load Balancer Standard, possono essere consultati nella documentazione ufficiale.

Sicurezza

I Load Balancer con SKU standard sono configurati di default in modo sicuro in quanto, per consentire il funzionamento, è necessario avere un Network Security Group (NSG) dove il flusso di traffico viene consentito in modo esplicito. Come riportato in precedenza, i Load Balancer Standard sono completamente integrati nella virtual network, la quale è caratterizzata dal fatto che è privata e di conseguenza chiusa. I Load Balancer Standard e gli IP Pubblici Standard vengono utilizzati per consentire l’accesso alle virtual network dall’esterno e ora di default è necessario configurare un Network Security Group (chiuso di default) per consentire il traffico voluto. Nel caso non sia presente un NSG, attestato sulla subnet oppure sulla NIC della macchina virtuale, non sarà consentito il relativo accesso da parte del flusso di rete proveniente dal Load Balancer Standard.

I Load Balancer Basic sono invece di default aperti e la configurazione di un Network Security Group è opzionale.

Connessioni in Outbound

I Load Balancer in Azure supportano scenari di connettività sia in inbound che in outbound. I Load Balancer Standard, rispetto ai Load Balancer Basic, si comportano in modo differente per quanto riguarda le connessioni in outbound.

Per effettuare il mapping degli indirizzamenti IP interni e privati della propria virtual network verso gli indirizzi IP pubblici dei Load Balancer viene utilizzata la tecnica Source Network Address Translation (SNAT). I Load Balancer Standard introducono un nuovo algoritmo per avere politiche di SNAT più robuste, scalabili e precise, che consentono di avere una maggiore flessibilità e di disporre di nuove funzionalità.

Utilizzando i Load Balancer Standard è opportuno considerare i seguenti aspetti per quanto riguarda gli scenari di outbound:

  • Devono essere creati in modo esplicito per consentire alle macchine virtuali la connettività in uscita e sono definiti sulla base delle regole di bilanciamento in ingresso.
  • Le regole di bilanciamento definiscono come avvengono le politiche di SNAT.
  • In presenza di più frontend, vengono utilizzati tutti i frontend e per ognuno di questi si moltiplicano le porte SNAT preallocate disponibili.
  • Si ha la possibilità di scegliere e controllare se uno specifico frontend non lo si vuole utilizzare per le connessioni in uscita.

Nei Basic Load Balancer, in presenza di più frontend IP Pubblici, viene scelto un singolo frontend per essere utilizzato nei flussi in uscita. Questa selezione non può essere configurata e avviene in modo casuale.

Per designare un indirizzo IP specifico è possibile seguire la procedura descritta in questa sezione della documentazione Microsoft.

Operazioni di Management

I Load Balancer di tipologia Standard consentono l’abilitazione delle operazioni di management in modo più rapido, tanto da portare i tempi di esecuzione di queste operazioni al di sotto dei 30 secondi (contro i 60-90 secondi necessari per i Load Balancer con SKU Basic). I tempi di modifica dei pool di backend sono dipendenti anche dalla dimensione degli stessi.

Altre differenze

Al momento per i Public Load Balancer di tipologia Standard non è possibile prevedere l’utilizzo di un indirizzo IPv6 pubblico:

Figura 8 – IPv6 pubblico per i Public Load Balancer

 

Service-Level Agreement (SLA)

Un importante aspetto da tenere in considerazione, nella scelta della SKU più opportuna per le diverse architetture, è il livello di servizio che si deve garantire (SLA). Utilizzando i Load Balancer Standard viene garantito che un Load Balancer Endpoint, che serve due o più istanze di macchine virtuali in stato di salute, sarà disponibile temporalmente con uno SLA del 99.99%.

I Load Balancer Basic non garantisco questo SLA.

Per maggiori dettagli a riguardo è possibile consultare l’articolo specifico SLA for Load Balancer.

 

Costo

Mentre per i Load Balancer Basic non sono previsti dei costi, per i Load Balancer Standard sono previsti dei costi di utilizzo in base ai seguenti elementi:

  • Numero delle regole di load balancing configurate.
  • Quantità dei dati processati in ingresso e in uscita.

Non sono invece previsti costi specifici per le regole di NAT.

Nella pagina dei costi dei Load Balancer possono essere consultati i dettagli e le cifre.

 

Migrazione tra SKUs

Per i Load Balancer non è previsto il passaggio dalla SKU Basic alla SKU Standard e viceversa. Ma è necessario prevedere una migrazione in side by side, tenendo in considerazione le differenze funzionali precedentemente descritte.

 

Conclusioni

L’introduzione dei Load Balancer Standard in Azure consente di disporre di nuove funzionalità e garantiscono una maggiore scalabilità. Queste caratteristiche potrebbero consentire di non dover utilizzare, in scenari specifici, soluzioni di bilanciamento offerte da vendor di terze parti. Rispetto ai Load Balancer tradizionali (SKU Basic) cambiano diversi principi di funzionamento e hanno caratteristiche distinte in termini di costi e SLA, che è bene valutare attentamente per poter scegliere la tipologia di Load Balancer più opportuna, sulla base dell’architettura che si deve realizzare.

Azure Backup: come evolve la soluzione

Microsoft ha recentemente annunciato importanti novità riguardanti la protezione delle macchine virtuali tramite Azure Backup. Grazie ad un aggiornamento dello stack di backup si possono infatti ottenere consistenti miglioramenti della soluzione che la rendono più performante e ne estendono le potenzialità. In questo articolo verranno approfonditi i benefici che si ottengono dall’aggiornamento e sarà esaminata la procedura da seguire per passare al nuovo stack di backup.

Funzionalità introdotte dal nuovo stack di backup

Recovery point istantanei e miglioramenti nelle performance

Il job di Azure Backup per la protezione delle macchine virtuali può essere suddiviso in due fasi distinte:

  1. Creazione della snapshot della VM.
  2. Trasferimento della snapshot verso il Recovery Service vault.

Figura 1 – Fasi del job di backup

Aggiornando lo stack di backup, il recovery point viene reso disponibile immediatamente al termine della creazione della snapshot della macchina virtuale (Fase 1), ed è utilizzabile per le operazioni di ripristino secondo le modalità note. A differenza di prima che era possibile utilizzarlo solo al termine della Fase 2. Dal portale Azure è possibile distinguere la tipologia di recovery point, in quanto al termine della Fase 1, il recovery point type viene definito come “snapshot”, mentre al termine del trasferimento della snapshot verso il vault di backup, il recovery point type viene marcato come “snapshot and vault”.

Le snapshot effettuate durante il processo di backup vengono mantenute per 7 giorni. Grazie a questa modifica vengono ridotti notevolmente i tempi di esecuzione dei restore, effettuati utilizzando le snapshot, le quali sono utilizzabili in modo del tutto analogo ai checkpoint creati da Hyper-V oppure da VMware.

Supporto per dischi di grosse dimensioni

Il nuovo stack di backup consente inoltre di proteggere i dischi di dimensione fino ai 4TB, sia di tipologia managed che unmanaged. Il limite in precedenza nella dimensione massima dei dischi protetti era di un 1TB.

Distribuzione dei dischi durante il ripristino delle macchine virtuali

Dopo aver effettuato l’aggiornamento dello stack di backup si ha la possibilità di scegliere dove posizionare i dischi unmanaged delle macchine virtuali durante i processi di restore. Questo riduce le configurazioni che sarebbero necessarie, post attività di restore, mettendo tutti i dischi all’interno dello stesso storage account.

Il processo di Upgrade

Per poter usufruire dei benefici introdotti dal nuovo stack di backup è necessario effettuare manualmente l’upgrade della subscription che detiene i Recovery Service Vault secondo le modalità in seguito descritte.

Considerazione pre-Upgrade

Prima di affrontare l’aggiornamento dello stack è opportuno considerare i seguenti aspetti:

  • Dal momento che l’upgrade viene attivato a livello di subscription Azure, la metodologia di esecuzione dei backup viene modificata per tutte le macchine virtuali protette, presenti nella subscription specifica. In futuro sarà possibile avere un controllo più granulare di questo processo di upgrade.
  • Le snapshot vengono salvate localmente per velocizzare il processo di creazione dei recovery point e per aumentare la velocità dei processi di restore. Questo comporta che saranno previsti dei costi per lo storage utilizzato dalle snapshot mantenute per 7 giorni.
  • Le snapshot incrementali vengono salvate come page blob. Per coloro che utilizzano managed disk non sono previsti costi aggiuntivi, mentre chi utilizza dischi unmanaged deve considerare anche il costo delle snapshot salvate (durante i 7 giorni) nello storage account locale.
  • In caso di ripristino di una VM premium, partendo da uno snapshot recovery point, sarà presente, durante la creazione della VM effettuata dal processo di restore, una location temporanea per lo storage.
  • Per gli storage account premium è necessario considerare un’allocazione di 10 TB di spazio, per le snapshot create a fini di instant recovery.

Come effettuare l’upgrade

L’upgrade può essere effettuato direttamente dal portale Azure oppure tramite comandi PowerShell.

Accedendo dal portale Azure al Recovery Service vault, comparirà la notifica che segnala la possibilità di effettuare l’aggiornamento dello stack di backup.

Figura 2 – Notifica di upgrade dello stack di backup

Selezionando la notifica comparirà la seguente segnalazione che consente di avviare il processo di upgrade.

Figura 3 – Avvio del processo di upgrade dello stack di backup

La medesima operazione può essere svolta utilizzando i seguenti comandi Powershell:

Figura 4 – Comandi Powershell per registrare la subscription al processo di upgrade

L’aggiornamento dello stack di backup richiede generalmente diversi minuti (massimo due ore), ma non ha nessun impatto sulle operazioni di backup schedulate.

Considerazioni

Questo importante aggiornamento dello stack di Azure Backup dimostra che la soluzione è in continua evoluzione per ampliare le sue potenzialità e per garantire maggiori livelli di performance. Per portare il proprio contributo con nuove idee o per votare le funzionalità che si ritengono maggiormente importanti per Azure Backup è possibile accedere a questa pagina. Per maggiori dettagli in merito ad Azure Backup è possibile consultare la documentazione ufficiale Microsoft.

OMS e System Center: novità di Aprile 2018

Microsoft annuncia in modo costante novità riguardanti Operations Management Suite (OMS) e System Center. La nostra community rilascia mensilmente questo riepilogo, che consente di avere una panoramica complessiva delle principali novità del mese, in modo da rimanere sempre aggiornati su questi argomenti ed avere i riferimenti necessari per condurre eventuali approfondimenti.

Operations Management Suite (OMS)

Log Analytics

Microsoft ha deciso di estendere gli Alerts presenti in Log Analytics dal portale OMS verso il portale Azure, facendoli confluire in Azure Monitor. Questo processo avverrà in modo automatico a partire dal 14 Maggio 2018 (la data è stata posticipata, inizialmente era prevista per il 23 Aprile), non comporterà nessun tipo di modifica alla configurazione degli Alerts e delle relative query, e non prevede nessun downtime per la sua attuazione. Per maggiori informazioni a riguardo è possibile consultare l’articolo specifico “L’estensione degli Alerts di Log Analytics in Azure Monitor“.

Figura 1 – Notifica estensione alerts nel portale OMS

Per evitare situazioni dove, le risorse gestite in Log Analytics inviino in modo inaspettato un elevato volume dei dati verso il Workspace OMS, è stata introdotta la possibilità di fissare un Daily Volume cap. Questo consente di limitare la data ingestion giornaliera per il proprio workspace. Il Data volume cap è possibile configurarlo in tutte le regions, accedendo nella sezione Usage and estimated costs:

Figura 2 – Impostazione del Daily volume cap

Il portale mostra inoltre il trend del volume dei dati negli ultimi 31 giorni e il totale del volume dei dati, suddiviso per solution:

Figura 3 – Data ingestion per solution (ultimi 31 giorni e totale)

L’utilizzo della Log Search API, utilizzata dal vecchio linguaggio di query di Log Analytics, è stato deprecato a partire dal 30 Aprile 2018. La Log Search API è stata sostituita con l’Azure Log Analytics REST API, la quale supporta il nuovo linguaggio di query e introduce una maggiore scalabilità rispetto ai risultati che è in grado di restituire. Per maggiori dettagli a riguardo è possibile consultare l’annuncio ufficiale.

Agente

Questo mese la nuova versione dell’agente OMS per sistemi Linux risolve un importante numero di bug e introduce nuove versioni dei vari componenti. Viene inoltre introdotto il supporto per Debian 9, AWS 2017 e Open SSL 1.1. Per ottenere la versione aggiornata dell’agente OMS è possibile accedere alla pagina ufficiale GitHub OMS Agent for Linux Patch v1.6.0-42.

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

Azure Backup

Per quanto riguarda Azure Backup sono stati annunciati i seguenti miglioramenti nella scalabilità del servizio:

  • Possibilità di creare fino a 500 recovery services vaults in ogni subscription per region (in precedenza il limite era di 25).
  • Il numero di macchine virtuali che può essere registrato in ogni vault è aumentato a 1000 (precedentemente era 200).

Azure Backup, per la protezione delle Azure Iaas VM, ora supporta gli storage account messi in sicurezza utilizzando storage firewalls and Virtual Networks. Per maggiori dettali a riguardo è possibile consultare il blog ufficiale Microsoft.

Figura 5 – Protezione Azure Iaas VM in scenari di storage protetti

Cambiano le modalità previste per abilitare il backup long-term per gli Azure SQL Database. La procedura, per consentire di mantenere il backup degli Azure SQL DB fino a 10 anni, prevedeva il salvataggio all’interno di un Azure Recovery Service Vault. Grazie all’introduzione di questa nuova funzionalità, si ha la possibilità di mantenere il backup long-term direttamente all’interno di un Azure Blob Storage e viene a decadere l’esigenza di un Recovery Service Vault. Tutto ciò consente di avere più flessibilità e un maggiore controllo dei costi. Per maggiori dettagli a riguardo è possibile consultare l’articolo SQL Database: Long-term backup retention preview includes major updates.

System Center

System Center Configuration Manager

Per System Center Configuration Manager è stata rilasciata la versione 1804 per il branch Technical Preview. Oltre che improvements generici nella soluzione vengono introdotte novità riguardanti l’OSD, il Software Center e l’infrastruttura di Configuration Manager. Tutte le nuove funzionalità incluse in questo update possono essere consultate nell’articolo Update 1804 for Configuration Manager Technical Preview Branch. 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.

System Center Operations Manager

Microsoft ha rilasciato l’Update Rollup 5 (UR5) per System Center 2016 Long-Term Servicing Channel (LTSC). Questo aggiornamento non introduce nuove funzionalità, ma risolve diversi bug.

In seguito, si riportano i riferimenti, riguardanti questo aggiornamento, per ogni prodotto System Center:

Non sono presenti invece aggiornamenti riguardanti Service Provider Foundation.

System Center Operations Manager 1801 introduce il supporto per la Kerberos authentication quando il protocollo WS-Management viene utilizzato dal management server per la comunicazione con i sistemi UNIX e Linux. Questo consente di avere un maggiore Livello di sicurezza, eliminando la necessità di abilitare la basic authentication per Windows Remote Management (WinRM).

Inoltre in System Center Operations Manager 1801 sono stati introdotti i seguenti miglioramenti riguardanti la gestione del monitor dei file di log di Linux:

  • Supporto per caratteri Wild Card nel nome e nel percorso del file di log.
  • Supporto per nuovi match patterns che consentono ricerche personalizzate dei log.
  • Supporto per pluging Fluentd pubblicati dalla community fluentd.

In seguito si riportano le novità riguardanti i Management Pack di SCOM:

  • MP per Windows Server Operating System 2016 e 1709 Plus 10.0.19.0
  • MP per SQL Server 2008-2012 7.0.4.0
  • MP per SQL Server 2014 7.0.4.0
  • MP per SQL Server 2016 7.0.4.0
  • MP per Microsoft Azure SQL Database 7.0.4.0
  • MP per SQL Server Dashboards 7.0.4.0
  • MP per UNIX e Linux 7.6.1085.0

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.

Azure Monitor: come controllare lo stato di salute dei servizi Azure

Azure Monitor, tramite il servizio Azure Service Health, è in grado di fornire indicazioni dettagliate nel caso dovessero verificarsi condizioni che influenzano il funzionamento dei propri servizi presenti nel cloud Microsoft. In questo articolo si approfondirà come Azure Service Health può essere di aiuto per identificare l’impatto dei problemi, inviare notifiche e mantenere gli amministratori dell’ambiente aggiornati man mano che il problema si risolve. Verrà inoltre approfondito come questo servizio può essere di aiuto per prepararsi a manutenzioni programmate e per capire come queste potrebbero influire sulla disponibilità delle proprie risorse.

Per avere una visuale sullo stato globale di salute di Azure, Microsoft mette a disposizione la relativa pagina di stato, che riporta in tempo reale la situazione dei vari prodotti e servizi, suddivisi per area geografica. In questa pagina vengono riportati tutti i problemi, anche quelli che non influiscono direttamente sullo stato dei propri servizi.

Per ottenere una vista personalizzata, che contempla solamente le proprie risorse, si può utilizzare Azure Service Health. In questo modo viene favorita l’individuazione tempestiva delle informazioni riguardanti i seguenti aspetti:

  • Problemi sui servizi: vengono riportati i problemi relativi ai servizi Azure che impattano sulle proprie risorse.
  • Manutenzioni programmate: sono elencate le future manutenzioni che interessano la disponibilità dei propri servizi.
  • Health advisories: si tratta dei cambiamenti nei servizi Azure che richiedono attenzione. Possibili esempi a riguardo possono essere segnalazioni in merito al superamento di determinate quote di utilizzo oppure quando determinate funzionalità di Azure vengono deprecate.

Figura 1 – Sezioni di Azure Service Health presenti nel portale Azure

Accedendo alla sezione Azure Service Health – Service issues, presente in Azure Monitor, è possibile effettuare la creazione di dashboard personalizzate. Al fine di ricevere le notifiche solamente per le risorse di proprio interesse, viene richiesto di selezionare le subsbription, le region e i servizi opportuni. Al termine di questa selezione è possibile salvare i filtri impostati assegnandogli un nome.

Figura 2 – Selezione delle regions

Figura 3 – Selezione dei servizi Azure

Figura 4 – Salvataggio del filtro e assegnazione del nome

Selezionando il pulsante “Pin filtered world map to dashboard” è possibile visualizzare la mappa personalizzata nella dashboard del portale Azure, in modo da avere istantaneamente un impatto visivo sullo stato di salute delle subscription, dei servizi e delle regions prescelte.

Figura 5 – Mappa, con i filtri applicati, riportata nella dashboard

Nel caso dovessero emergere problematiche che impattano le proprie risorse su Azure, accedendo al portale, si riceverà una notifica analoga alla seguente:

Figura 6 – Segnalazione di una problematica in atto che impatta i propri servizi

Selezionando la mappa personalizzata si viene rimandati nella sezione Azure Service Health di Azure Monitor. In questa dashboard vengono riportati i relativi dettagli e l’elenco delle proprie risorse, che potenzialmente potranno essere impattate dalla problematica, oltre che i relativi aggiornamenti di stato.

Figura 7 – Summary della problematica

Da questa pagina sarà possibile anche scaricare la documentazione in formato PDF (in alcuni casi anche in formato CSV) che descrive la problematica, per poter essere inviata a chi non ha accesso diretto al portale Azure. Sono presenti inoltre i link utili per poter contattare il supporto Microsoft nel caso persistano delle condizioni di errore dopo che il problema viene segnalato come risolto.

Figura 8 – Risorse potenzialmente impattate dalla problematica

Nella sezione Health history vengono riportati i problemi passati riscontrati sui servizi Azure e che hanno avuto un impatto sullo stato di salute delle proprie risorse.

Figura 9 – Elenco dei problemi riportati nella Health history

Azure Service Health, nella sezione Resource health, consente inoltre di visualizzare lo stato di salute delle proprie risorse suddividendole per tipologia.

Figura 10 – Stato di salute delle risorse per tipologia

Selezionando il singolo servizio Azure è possibile consultare sia lo stato di salute attuale che eventuali problemi accaduti in passato su una determinata risorsa.

Figura 11 – Stato di salute attuale ed eventi passati di una specifica risorsa Virtual Machine

Grazie alla completa integrazione di Service Health in Azure Monitor, il quale detiene il motore di alerting di Azure, è possibile configurare degli Alerts specifici qualora ci siano problemi lato Azure, che impattano sul funzionamento delle risorse presenti sulle proprie subscription. La notifica avviene tramite Action Groups, che comprende ad oggi queste possibili azioni:

  • Chiamata vocale (al momento solo USA) oppure invio di SMS (per i paesi abilitati).
  • Invio di una mail.
  • Chiamata a un webhook.
  • Invio di dati verso ITSM.
  • Richiamo di una Logic App.
  • Invio di una notifica push sulla mobile app di Azure.
  • Esecuzione di un runbook di Azure Automation.

Figura 12 – Aggiunta di un Service Health Alert

Figura 13 – Configurazione di un Service Health Alert

Conclusioni

La recente disponibilità di Azure Service Health, ha introdotto la possibilità di ricevere informazioni personalizzate e mirate sullo stato di salute delle proprie risorse Azure, senza dover ricercare i potenziali problemi di Azure a livello globale accedendo alla relativa pagina di stato. Questo consente di risparmiare tempo e di capire facilmente, a fronte di problematiche oppure di manutenzioni programmate, qual è l’impatto sui propri servizi.

L’estensione degli Alerts di Log Analytics in Azure Monitor

Poter usufruire di un servizio centralizzato ed efficace per la gestione degli Alerts della propria infrastruttura è sicuramente un aspetto importante e fondamentale nella strategia di monitor. A questo scopo Microsoft ha introdotto una nuova experience nella gestione degli Alerts tramite la soluzione Azure Monitor. In questo articolo verrà presentato come evolverà la gestione degli Alerts in Log Analytics e quali sono i benefici introdotti da questo cambiamento.

In Log Analytics c’è la possibilità di generare degli Alerts quando, a fronte di una ricerca che avviene con frequenza schedulata nel repository di OMS, si ottengono dei risultati che fanno match con i criteri stabiliti. Nel momento in cui viene generato un Alert in Log Analytics si possono configurare le seguenti azioni:

  • Notifica via email.
  • Invocazione di un webhook.
  • Esecuzione di un runbook di Azure Automation.
  • Attività di IT Service Management (richiede la presenza del connettore per la solution ITSM).

Figura 1 – Alerts in Log Analytics

Fino ad oggi questo tipo di configurazione è stata gestita dal portale OMS.

Azure Monitor è un servizio che oltre a consente di monitorare tutte le risorse Azure borne, detiene l’engine di “alerting” per l’intera piattaforma cloud. Accedendo al servizio dal portale Azure si avranno infatti a disposizione, in una unica location, tutti gli Alerts della propria infrastruttura, provenienti da Azure Monitor, Log Analytics, e Application Insights. Si potrà quindi usufruire di una experience unificata sia per quanto riguarda la consultazione degli Alerts che per il relativo authoring.

Allo stato attuale gli Alerts creati in Log Analytics vengono già riportati nella dashboard di Azure Monitor, ma l’eventuale modifica comporta l’accesso al portale OMS. Per agevolare questa gestione Microsoft ha quindi deciso di estendere gli Alerts presenti in Log Analytics dal portale OMS verso il portale Azure. Questo processo avverrà in modo automatico a partire dal 23 Aprile 2018, non comporterà nessun tipo di modifica alla configurazione degli Alerts e delle relative query, e non prevede nessun downtime per la sua attuazione.

Ne consegue che, dopo questa operazione, le eventuali azioni associate agli Alerts saranno effettuate tramite Action Groups, i quali saranno creati automaticamente dal processo di estensione.

L’estensione degli Alerts di Log Analytics nel portale Azure, oltre al vantaggio di poter consentire la gestione degli stessi da un unico portale, consente di usufruire dei seguenti benefici:

  • Non esiste più il limite dei 250 Alerts.
  • Si ha la possibilità di gestire, enumerare e visualizzare non solo gli Alerts di Log Analytics, ma anche quelli provenienti da altre fonti.
  • Si ha una maggiore flessibilità nelle azioni che si possono intraprendere a fronte di un Alerts, grazie all’utilizzo degli Action Groups, come ad esempio la possibilità di inviare SMS oppure di effettuare delle chiamate vocali.

Nel caso non si voglia attendere il processo automatico è possibile forzare la migrazione via API oppure dal portale OMS, secondo gli step in seguito documentati:

Figura 2 – Avvio del processo di “Extend into Azure” dal portale OMS

Figura 3 – Step 1: mostra i dettagli del processo di estensione.

Figura 4 – Step 2: summary delle modifiche proposte

Figura 5 – Step 3: conferma del processo di estensione

Specificando un indirizzo email è possibile ricevere una notifica al termine del processo di migrazione, contenente il summary report.

Figura 6 – Notifica dell’estensione degli Alerts pianificata

Durante il processo di estensione degli Alerts di Log Analytics in Azure non sarà possibile apportare delle modifiche agli Alerts esistenti e la creazione di nuovi Alerts dovrà avvenire da Azure Monitor.

Al termine del processo di estensione gli Alerts saranno comunque visibili anche dal portale OMS e si riceverà la notifica via mail, all’indirizzo specificato durante il wizard di migrazione:

Figura 7 – Mail di notifica al termine del processo di estensione

Dal portale Azure, nella sezione “Monitor – Alerts”, si avrà una gestione completa degli Alerts di Log Analytics:

Figura 8 – Esempio di modifica di una Alert Rule da Azure Monitor

L’estensione degli Alerts di Log Analytics in Azure Monitor non comporta dei costi, ma è opportuno tenere in considerazione che, l’utilizzo degli Azure Alerts generati da query di Log Analytics, non è soggetta a fatturazione solamente se rientra nei limiti e nelle condizioni riportati nella pagina dei costi di Azure Monitor.

Conclusioni

Grazie a questa attività di estensione degli Alerts di Log Analytics, Azure Monitor si conferma il nuovo engine di gestione di tutti gli Alerts, mettendo a disposizione degli amministratori una semplice e intuitiva interfaccia centralizzata ed arricchendo le possibili azioni di notifica a fronte di un alert.

OMS e System Center: novità di Marzo 2018

Nel mese di marzo ci sono state diverse novità annunciate da parte di Microsoft riguardanti Operations Management Suite (OMS) e System Center. In questa serie di articoli, che realizziamo con cadenza mensile, vengono elencate tutte le principali novità del mese corrente, accompagnate dai riferimenti necessari per poter effettuare ulteriori approfondimenti in merito.

Operations Management Suite (OMS)

Azure Automation

In Azure Automation sono state ufficialmente rilasciate le nuove funzionalità che consentono di:

  • Gestire la distribuzione degli aggiornamenti (Update management).
  • Raccogliere informazioni di inventario relative alle applicazioni installate sui sistemi (Inventory).
  • Tenere traccia delle modifiche apportare sulle macchine (Change tracking).

Il nostro articolo, pubblicato nei mesi scorsi, mostra come configurare l’Azure Automation Account per poter usufruire di queste nuove funzionalità e ne riporta le principali caratteristiche.

Figura 1 – Relative solution presenti in Log Analytics


Azure Backup

In Azure Backup sono state introdotte diverse novità che riguardano i seguenti aspetti:

  • Large disk support: possibilità di proteggere dischi di dimensione fino ai 4TB, sia di tipologia managed che unmanaged. Il limite in precedenza era di un 1TB.
  • Backup and Restore performance improvements: per ridurre i tempi di esecuzione dei backup e dei restore verranno mantenute le snapshot, effettuate durante il processo di backup, per 7 giorni.
  • Instant recovery point: i recovery point vengono resi disponibili istantaneamente nel momento della creazione della snapshot effettuata dal job di backup, in modo del tutto analogo ai checkpoint creati da Hyper-V oppure da VMware.
  • Distribute the disks of restored VM: durante i processi di restore viene fornita la possibilità di scegliere dove posizionare i dischi unmanaged delle macchine virtuali. Questo riduce le configurazioni, post attività di restore, che sarebbero necessarie mettendo tutti i dischi all’interno dello stesso storage account.

Per poter usufruire di questi improvements è necessario effettuare l’upgrade della subscription che detiene i Recovery Service Vault. L’upgrade può essere effettuato direttamente dal portale Azure (sarà presente una apposita notifica nella dashboard dei Recovery Service vault) oppure tramite comandi PowerShell. Per maggiori informazioni a riguardo è possibile consultare l’annuncio ufficiale Microsoft.

Figura 2 – Avvio del processo di upgrade della subscription al nuovo stack

Microsoft ha inoltre annunciato che il servizio Azure Backup è ora disponibile anche nelle region Azure della Francia (France Central e France South).

 

System Center

Microsoft ha ufficializzato il rilascio di Windows Server 2019 che sarà disponibile al pubblico nella seconda parte del 2018. Contestualmente verrà reso disponibile anche System Center 2019 che avrà il pieno supporto per Windows Server 2019 fin dal primo giorno del rilascio.

System Center Configuration Manager

Nel corso del mese è stata rilasciata la versione 1802 per il Current Branch (CB) di System Center Configuration Manager che introduce nuove funzionalità e importanti miglioramenti nel prodotto.

Queste in sintesi gli ambiti impattati da questo aggiornamento:

Modern Management

  • Endpoint Protection workload transition in co-management
  • Management insights
  • Co-management reporting

Figura 3 –  Co-management reporting

Microsoft 365 Adoption

  • Phased deployments
  • Windows AutoPilot Device Information report
  • Support for Windows 10 ARM64 devices
  • Surface Device Dashboard
  • Microsoft Edge browser policies
  • Report to show default browser for client machines
  • Windows 10 Servicing for a specific collection report
  • Improvements to Office 365 client management dashboard
  • Improvements for Windows Defender Exploit Guard
  • New settings for Windows Defender Application Guard

Streamlined Infrastructure

  • Configure Windows 10 Delivery Optimization to use Configuration Manager boundary groups
  • Add management points to your boundary group fallback relationships
  • Moving Distribution Points between sites

Improvements in Cloud Management Gateway

  • Cloud management gateway support for Azure Resource Manager
  • Install user-available applications on Azure AD-joined devices
  • Windows 10 in-place upgrade task sequence over the Internet

Improvements in Software Center

  • Approve application requests for users per device
  • Improvements to client settings for Software Center

Improvements in OSD

  • Improvements to Windows 10 in-place upgrade task sequence
  • Deployment Template for Task Sequences

Miscellaneous Improvements

  • Support for hardware inventory strings greater than 255 characters in length
  • Run scripts

Figura 4 –  Run Script status

Per consultare la lista completa delle nuove funzionalità e per avere maggiori dettagli a riguardo è possibile accedere alla documentazione ufficiale Microsoft.

L’aggiornamento verrà reso disponibile in queste settimane a livello globale e sarà riportato nel nodo “Updates and Servicing” della console di SCCM. Per forzare la disponibilità di questo aggiornamento è possibile utilizzare questo script PowerShell.

Per System Center Configuration Manager è stata rilasciata la versione 1803 per il branch Technical Preview. Oltre che improvements generici nella soluzione vengono introdotte utili modifiche che possono migliorare l’infrastruttura di Configuration Manager. Inoltre, sono stati apportati interessanti miglioramenti riguardanti il Software Center. Tutte le nuove funzionalità incluse in questo update possono essere consultate nell’articolo Update 1803 for Configuration Manager Technical Preview Branch.

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.

System Center Updates Publisher

System Center Updates Publisher (SCUP)  è la soluzione Microsoft che consente di gestire custom update di terze parti. Questo mese una nuova versione di SCUP è stata rilasciata ufficialmente e può essere scaricata a questo indirizzo. La nuova release introduce il supporto per Windows 10 e Windows Server 2016. Tutti i dettagli in merito a questo rilascio possono essere consultati nell’annuncio ufficiale.

System Center Operations Manager

In seguito, si riportano le novità riguardanti i Management Pack di SCOM:

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 prodotti System Center è possibile accedere all’Evaluation Center e in seguito alla registrazione è possibile avviare il periodo di trial.

Azure SQL Database: come gestire la connettività con i vNet Service Endpoints

Per avere un maggiore controllo sugli accessi che vengono effettuati sugli Azure SQL Database, lo scorso mese, Microsoft ha rilasciato pubblicamente la possibilità di abilitare i Virtual Network (vNet) Service Endpoints per i SQL Database. In questo articolo verrà spiegato il principio di funzionamento, con i benefici che ne derivano, e verrà mostrata la relativa configurazione.

Caratteristiche e principi di funzionamento

I vNet Service Endpoints per gli Azure SQL Database consentono di isolare maggiormente i SQL Server logici presenti nel cloud Microsoft, garantendo l’accesso solamente da una o più subnet definite nelle proprie Virtual Network di Azure. Questa funzionalità garantisce che tutto il traffico generato dalle proprie vNet verso l’Azure SQL Database rimarrà sempre all’interno della rete di backbone di Azure. Si tratta di una funzionalità disponibile in tutte le region di Azure e non sono previsti costi aggiuntivi per il relativo utilizzo.

Figura 1 – Schema di sintesi dell’architettura

Sul firewall degli Azure SQL Database rimane la possibilità di abilitare la comunicazione da parte dei servizi Azure e di filtrare gli accessi sulla base di un range di IP Pubblici.

Figura 2 – Impostazioni firewall di Azure SQL Server

Abilitando l’impostazione “Allow access to Azure services” viene consentito l’accesso al SQL Server da tutti gli indirizzamenti IP pubblici di Azure e da tutte le subnet di Azure, comprese quelle non di propria appartenenza. Andando ad applicare ulteriori filtri sulla base dell’IP pubblico che si deve connettere può diventare di difficile gestione e richiedere la configurazione di indirizzi IP pubblici statici sulle risorse di Azure.

Grazie all’introduzione dei Virtual Network (vNet) Service Endpoints per SQL Server è possibile avere un maggiore controllo sulle potenziali comunicazioni e un minor effort di gestione delle risorse. Il principio di funzionamento dei vNet Service Endpoints non si estende al mondo on-premises anche in presenza di connettività con Azure (VPN oppure ExpressRoute), ma per consentire l’accesso da sistemi presenti on-premises è necessario continuare ad utilizzare le regole firewall per limitare la connettività solamente agli IP pubblici di propria appartenenza.

I Virtual Network (vNet) Service Endpoints sono disponibili, con lo stesso principio di funzionamento, anche per Azure Storage e per Azure SQL Datawarehouse (al momento in preview).

Come effettuare la configurazione

L’abilitazione dei vNet Service Endpoints richiede l’attivazione sulla subnet della virtual network di Azure, dalla quale ci si intende connettere al SQL Server, dell’Enpoint di SQL Server (Microsoft.SQL).

Figura 3 – Abilitazione del SQL Server Service Endpoint sulla subnet

Figura 4 – Service Endpoint di SQL Server abilitato con successo sulla subnet

Successivamente è necessario aggiungere lato SQL Database la virtual network, con il Service Endpoint abilitato, nella sezione Firewall and virtual networks.

Figura 5 – Aggiunta Virtual Network con Service Endpoint di SQL Server abilitato

Ogni Virtual Network Rule viene applicata a livello di Azure SQL Database server e non a livello di singolo database.

Questo tipo di configurazione comporta che collegandosi ai DB ospitati dall’Azure SQL Server da una macchina attestata su una vNet con i Service Endpoint abilitati, verrà utilizzato come source IP un indirizzo appartenente all’address space della vNet. Questo aspetto è da tenere in considerazione, in configurazioni esistenti, per evitare che quando si attiva il SQL Server Service Endpoint sulla subnet, venga bloccato l’accesso al SQL Server. A questo scopo è possibile evitare il blocco consentendo temporaneamente l’accesso tramite l’impostazione “Allow access to Azure services”, oppure definendo la vNet nelle firewall rule del SQL Server prima di abilitare il Service Endpoint sulla subnet. Per farlo è necessario utilizzando il flag IgnoreMissingServiceEndpoint oppure selezionare il flag seguente presente nel portale Azure:

Figura 6 – Aggiunta Virtual Network senza Service Endpoint di SQL Server abilitato

Conclusioni

I Virtual Network (vNet) Service Endpoints sono in grado di estendere le proprie virtual network di Azure e la relativa identità verso determinati servizi di Azure, come Azure SQL Server, tramite una connessione diretta. Questo consente di aumentare il livello di sicurezza dei propri servizi presenti nel cloud Microsoft, di ottimizzare il routing per accedere alle risorse Azure dalle proprie vNet e di diminuire l’effort di gestione, il tutto con pochi semplici passaggi.

Come monitora le attività di rete nel cloud Azure con Traffic Analytics

Le reti nel mondo cloud presentano differenze sostanziali rispetto a quelle presenti in ambiente on-premises, ma sono accomunate dalla necessità di essere costantemente monitorate, gestite e analizzate. Tutto ciò è importante per poterle conoscere al meglio, al fine di proteggerle ed ottimizzarle. Microsoft ha introdotto in Azure la soluzione Traffic Analytics, totalmente cloud-based, che consente di avere una visibilità complessiva sulle attività di rete che vengono intraprese nell’ambiente cloud. Questo articolo analizza le caratteristiche della soluzione e spiega come è possibile attivarla.

Principi di funzionamento della soluzione

In Azure per poter consentire o negare la comunicazione di rete verso le risorse connesse alle Azure Virtual Networks (vNet) vengono utilizzati i Network Security Group (NSG), che contengono una lista di regole di accesso. I NSG vengono applicati alle interfacce di rete connesse alle macchine virtuali oppure direttamente alle subnet. La platform utilizza i NSG flow logs per mantenere la visibilità del traffico di rete in ingresso e in uscita dai Network Security Group. Traffic Analytics si basa sull’analisi dei NSG flow logs e dopo una opportuna aggregazione dei dati, inserendo l’intelligence necessaria relativamente a security, topologia e mappa geografica, è in grado di fornire informazioni dettagliate sul traffico di rete del proprio ambiente cloud Azure.

Figura 1 – Data flow di Traffic Analytics

Funzionalità della soluzione

Utilizzando Traffic Analytics si possono effettuare le seguenti operazioni:

  • Visualizzare le attività di rete cross Azure subscriptions e identificare hotspots.
  • Intercettare potenziali minacce di security lato network, per poi poter adottare le giuste operazioni correttive. Questo viene reso possibile grazie alle informazioni riportate dalla soluzione: quali porte sono aperte, quali applicazioni tentano di accedere verso Internet e quali macchine virtuali si connettono a reti non autorizzate.
  • Comprendere i flussi di rete presenti tra le varie region Azure e Internet, al fine di ottimizzare il proprio deployment di rete in termini di performance e capacità.
  • Individuare configurazioni di rete non corrette che portano ad avere tentativi di comunicazione errati.

Come abilitare la soluzione

Per poter analizzare il traffico di rete è necessario disporre di un Network Watcher in ogni region dove sono presenti i NSG per i quali si intente analizzare il traffico. Il Network Watcher è un servizio regionale grazie al quale è possibile monitorare e diagnosticare il networking di Azure. L’abilitazione del Network Watcher può essere fatta dal portale Azure, tramite Powershell oppure via REST API. Creandolo dal portale non è possibile stabilire il nome del Network Watcher e il relativo Resource Group, ma viene assegnato un nome di default a entrambe le entità.

Figura 2 – Abilitazione del Network Watcher dal portale

Figura 3 – Abilitazione del Network Watcher tramite PowerShell

Trattandosi di un servizio in preview per poterlo utilizzare è necessario effettuare nuovamente la registrazione del network resource provider sulla subscription Azure interessata. Inoltre è necessario registrare il provider Azure Insights.

Figura 4 – Registrazione dei provider tramite PowerShell

Per poter abilitare la raccolta degli NSG Flow Logs è necessario dotarsi di uno storage account sul quale memorizzarli. Inoltre è necessario disporre di un workspace OMS Log Analytics sul quale Traffic Analytics consoliderà i dati aggregati e indicizzati. Le informazioni presenti in Log Analytics verranno poi utilizzate per generare la relativa analisi.

Primo step di configurazione delle impostazioni dei NSG flow logs:

Figura 5 – Selezione dei NSG sui quali abilitare la raccolta dei flow logs

Scelta dello storage account e del workspace OMS Log Analytics per ogni NSG:

Figura 6 – Abilitazione della raccolta dei NSG flow logs e del consolidamento in OMS Log Analytics

Gli step precedentemente riportati dovranno essere ripetuti per ogni NSG per il quale si desidera abilitare Traffic Analytics.

Figura 7 – Lista dei NSGs con le impostazioni abilitate

Entro alcuni minuti dall’abilitazione, tempo necessario per avere un quantitativo di dati aggregati sufficientemente indicativo, viene popolata la relativa dashboard con le informazioni di Traffic Analytics.

Figura 8 – Dashboard di Traffic Analytics

Dalla dashboard di Traffic Analytics sono facilmente reperibili le informazioni quali: gli host con un livello elevato di comunicazione, i protocolli applicativi maggiormente utilizzati, le comunicazioni che avvengono in modo più frequente e i flussi relativi al traffico di rete nel cloud.

Selezionando la sezione di interesse viene mostrata la query di Log Analytics che estrapola i dati:

Figura 9 – Esempio di query Log Analytics che mostra il traffico malicious consentito

Per avere una panoramica completa dei possibili scenari di utilizzo di Traffic Analytics è possibile consultare questo documento Microsoft.

Conclusioni

Traffic Analytics è una nuova funzionalità, al momento in preview, introdotta in Azure. Si tratta di uno strumento efficace e di facile utilizzo che consente di tenere sotto controllo lo stato della rete in Azure riportando dati molto utili, come chi si sta collegando e dove, quali porte sono esposte verso internet, quale traffico di rete viene generato e molto altro. Si tratta di informazioni fondamentali per individuare eventuali anomalie e apportare le dovute azioni correttive. Tutte operazioni di difficile raggiungimento senza questo strumento totalmente integrato nella platform.

L’utilizzo di Azure Site Recovery Deployment Planner in ambienti VMware

Quando si ha la necessità di implementare scenari di Disaster Recovery verso Azure in ambienti particolarmente complessi, tramite la soluzione Azure Site Recovery (ASR), è possibile utilizzare lo strumento Azure Site Recovery Deployment Planner, recentemente rilasciato da Microsoft, per effettuare un assessment dettagliato dell’ambiente on-premises. Lo strumento è stato ideato per contemplare sia ambienti Hyper-V che VMware. In questo articolo verrà approfondito l’utilizzo dello strumento quando si intende attivare un piano di Disaster Recovery con replica di macchine virtuali VMware verso Azure.

A cosa serve questo strumento?

ASR Deployment Planner effettua un assessment dettagliato dell’ambiente on-premises, mirato all’utilizzo della soluzione Azure Site Recovery (ASR), e fornisce gli elementi da prendere in considerazione per poter contemplare in modo efficace le varie operazioni necessarie per implementare il piano di DR: replica, failover e DR-Drill delle macchine virtuali. Lo strumento effettua inoltre una stima delle risorse Azure necessarie per la protezione delle macchine virtuali presenti on-premises, riportando delle indicazioni sui costi per l’utilizzo di ASR.

In presenza di ambienti VMware se si ha la necessità di affrontare veri e propri scenari di migrazione verso Azure, lo strumento più opportuno da utilizzare per effettuare l’assessment dell’ambiente è Azure Migrate.

Come utilizzare lo strumento?

L’utilizzo di ASR Deployment Planner prevede due fasi principali. La prima di profilazione, durante la quale vengono raccolte le informazioni necessarie dall’ambiente VMware, e la seconda di generazione del report per effettuare l’analisi.

ASR Deployment Planner può essere scaricato a questo indirizzo. Si tratta di una folder compressa il cui contenuto dovrà essere copiato sul sistema su cui si intende eseguire lo strumento. ASRDeploymentPlanner.exe è il tool a riga di comando che dovrà essere eseguito con i parametri opportuni, non è richiesta nessuna installazione.

Profilazione e misurazione del throughput

La macchina su cui si intende effettuare la profilazione oppure il calcolo del throughput deve rispettare i seguenti requisiti:

  • Sistema Operativo: Windows Server 2016 oppure Windows Server 2012 R2.
  • Requisiti hardware: 8 vCPUs, 16 GB RAM e 300 GB HDD.
  • Requisiti Software: .NET Framework 4.5, VMware vSphere PowerCLI 6.0 R3, Visual C++ Redistributable for Visual Studio 2012.
  • Accesso Internet verso Azure.

Inoltre sono necessarie le seguenti condizioni:

  • Presenza di un Azure storage account (solo se si vuole calcolare anche il throughput).
  • VMware vCenter statistics level impostato al livello 2 oppure superiore.
  • Possibilità di connettersi al vCenter server/ESXi host sulla porta 443.
  • Utente con almeno permessi di Read-only per accedere al VMware vCenter server/VMware vSphere ESXi.

In generale è buona norma eseguire la profilazione e il calcolo del troughput sulla macchina Configuration Server che si intende utilizzare oppure su un sistema con caratteristiche del tutto analoghe.

Il tool è in grado di effettuare il profiling solo per macchine virtuali con dischi VMDK e RDM. Non è prevista la raccolta di informazioni di VMs con dischi iSCSI oppure NFS; a questo proposito è opportuno precisare che Azure Site Recovery non supporta macchine virtuali con queste tipologie di dischi in ambiente VMware.

Durante l’attività di profiling il tool si collega al server vCenter oppure all’host vSphere ESXi per collezionare i dati di performance delle macchine virtuali. Questo implica che l’attività di raccolta dei dati non ha nessun impatto sulle performance delle macchine virtuali perché non c’è nessuna connessione diretta. L’attività di profilazione viene fatta una volta ogni 15 minuti per non impattare sui sistemi VMware, ma la query che viene eseguita raccoglie comunque i dati di performance per tutto l’intervallo temporale.

L’attività di profiling richiede la presenza di un file di testo contenente l’elenco delle macchine virtuali (un nome oppure un indirizzo IP per ogni riga) che si intende esaminare. Questo file è possibile crearlo manualmente oppure, con i seguenti comandi, eseguiti dalla console VMware vSphere PowerCLI, è possibile estrapolare l’elenco di tutte le macchine virtuali presenti sul vCenter o sull’host vSphere ESXi.

Figura 1 – Estrapolazione lista VMs dal vCenter

Figura 2 – Esempio del file contenente l’elenco delle VMs

A questo punto è possibile avviare il processo di profiling. Per ambienti di produzione è raccomandato eseguirlo per almeno una settimana, in modo da avere un periodo di osservazione sufficientemente lungo per ottenere una profilazione accurata. Per ottenere la lista completa dei parametri necessari e opzionali è possibile eseguire il seguente comando: ASRDeploymentPlanner.exe -Operation StartProfiling /?.

Tra i parametri opzionali è possibile specificare anche un Azure Storage Account con la relativa chiave per calcolare il throughput che Site Recovery può raggiungere durante il processo di replica verso Azure.

Figura 3 – Esempio di esecuzione della profilazione

Nel caso il server, sul quale viene avviata la procedura di profiling, venisse riavviato oppure andasse in crash, i dati raccolti verrebbero comunque mantenuti e sarebbe sufficiente riavviare l’esecuzione del tool.

Lo strumento può essere inoltre utilizzato per il calcolo del throughput.

Figura 4 – Esempio di sola misurazione del throughput

Il processo di misurazione del throughput effettua l’upload di file con estensione .vhd sullo storage account specificato. Al completamento dell’upload questi file vengono rimossi in automatico dallo storage account.

Generazione del report

La macchina su cui si intende generare il report deve aver installato Excel 2013 oppure una versione superiore.

Terminato il processo di profilazione è possibile generare il report contenente l’output dell’assessment. Per procedere con la creazione del report è necessario eseguire lo strumento nella modalità report-generation. In questo caso per consultare tutti i possibili parametri è opportuno eseguire il comando ASRDeploymentPlanner.exe -Operation GenerateReport /?.

Figura 5 – Esempio del comando per la generazione del report

Il report generato viene chiamato DeploymentPlannerReport_xxx.xlsm all’interno del quale è possibile consultare diverse informazioni, tra le quali:

  • Una stima della banda di rete richiesta per il processo di replica iniziale (initial replication) e per la delta replication.
  • La tipologia di Storage (standard oppure premium) richiesta per ogni VM.
  • Il numero totale di storage account (standard e premium) necessari.
  • Il numero di Configuration Server e Process Server che è necessario implementare on-premises.
  • Il numero di VMs che possono essere protette in parallelo per completare la replica iniziale in un dato momento.
  • Stima del throughput raggiungibile da ASR (on-premises verso Azure).
  • Un assessment delle macchine virtuali supportate, fornendo dettagli in merito ai dischi (numero, relativa dimensione e IOPS) e alla tipologia del SO.
  • Stima dei costi di DR, specifici per l’utilizzo di una determinata region Azure.

Figura 6 – Pagina iniziale del report generato

Per ottenere informazioni dettagliate in merito all’analisi del report è possibile consultare la relativa documentazione ufficiale di Microsoft.

Oltre ad essere presente nella pagina iniziale del report un summary dei costi stimati, esiste anche un tab specifico contenente i dettagli relativi all’analisi dei costi.

Figura 7 – Sezione relativa alla stima dei costi presente nel report generato

Per maggiori dettagli sulle informazioni contenute e sulla relativa interpretazione è possibile consultare la documentazione ufficiale.

Conclusioni

Azure Site Recovery Deployment Planner è uno strumento molto utile che, effettuando un assessment dettagliato dell’ambiente on-premises, consente di non tralasciare nessun aspetto per realizzare nel migliore dei modi un piano di Disaster Recovery verso Azure, utilizzando Azure Site Recovery (ASR). Questo strumento permette inoltre di avere a priori e con un’ottima precisione una stima dei costi che sarà necessario sostenere per il proprio piano di Disaster Recovery, in modo da poter fare le dovute valutazioni.