Archivi categoria: Cloud

Azure File Sync: panoramica della soluzione

Il servizio Azure File Sync (AFS) permette di centralizzare le cartelle di rete della propria infrastruttura in Azure Files, consentendo di mantenere le caratteristiche tipiche di un file server on-premises, in termini di performance, compatibilità e flessibilità e allo stesso tempo di beneficiare delle potenzialità offerte dal cloud. In questo articolo verranno riportate le caratteristiche principali del servizio Azure File Sync e le procedure da seguire per effettuarne il deployment.

Figura 1 – Schema di overview di Azure File Sync

Azure File Sync è in grado di trasformare Windows Server in una “cache” per accedere rapidamente ai contenuti presenti su una determinata Azure file share. L’accesso locale ai propri dati può avvenire con qualsiasi protocollo disponibile in Windows Server, come SMB, NFS, e FTPS. Si ha la possibilità inoltre di disporre di più server “cache” dislocati in location geografiche differenti.

Queste le caratteristiche principali di Azure File Sync:

  • Multi-site sync: si ha la possibilità di effettuare la sincronizzazione tra differenti site, consentendo di accedere in scrittura agli stessi dati tra differenti Windows Servers ed Azure Files.
  • Cloud tiering: vengono mantenuti localmente solo i dati acceduti di recente.
  • Integrazione con Azure backup: viene a decadere la necessità di effettuare il backup dei dati on premises. La protezione dei contenuti è possibile farla tramite Azure Backup.
  • Disaster recovery: si ha la possibilità di effettuare in modo immediato il ripristino dei metadata dei file e di richiamare solamente i dati necessari, per velocizzare le operazioni di riattivazione del servizio in scenari di Disaster Recovery.
  • Accesso diretto all’ambiente cloud: è consentito accedere direttamente ai contenuti presenti sulla File Share da altre risorse Azure (IaaS e PaaS).

 

Requisiti

Per poter effettuare il deployment di Azure File Sync è necessario disporre dei seguenti requisiti:

Un Azure Storage Account, con una file share configurata in Azure Files, nella stessa region dove si vuole fare il deploy del servizio AFS. Per effettuare la creazione di uno storage account è possibile seguire l’articolo Create a storage account, mentre la procedura di creazione della file share è riportata in questo documento.

Un sistema Windows Server con sistema operativo Windows Server 2012 R2 o successivo, il quale dovrà avere:

  • PowerShell 5.1, che è incluso di default a partire da Windows Server 2016.
  • Moduli PowerShell AzureRM.
  • Agente Azure File Sync. Il setup di installazione dell’agente può essere scaricato a questo indirizzo. Nel caso si intenda utilizzare AFS in ambiente cluster è opportuno installare l’agente su tutti i nodi del cluster. A questo proposito è bene precisare che Windows Server Failover Clustering è supportato da Azure File Sync per deployment di tipologia “File Server for general use”. L’ambiente Failover Cluster non è invece supportato su “Scale-Out File Server for application data” (SOFS) oppure su Clustered Shared Volumes (CSVs).
  • Si consiglia di mantenere l’opzione “Internet Explorer Enhanced Security Configuration” disabilitata sia per gli Administrators che per gli Users.

 

Concetti e configurazione del servizio

Dopo aver verificato la presenza di questi requisiti l’attivazione di Azure File Sync richiede di procedere con la creazione del servizio Storage Sync:

Figura 2 – Creazione servizio Storage Sync

Si tratta della risorsa top-level per Azure File Sync, la quale funge da contenitore per le relazioni di sincronizzazione tra i differenti storage account e molteplici Sync Group. Il Sync Group definisce la topologia di sincronizzazione per un set di files. Gli endpoint che si trovano all’interno dello stesso Sync Group vengono mantenuti in sincronizzazione tra di loro.

Figura 3 – Creazione Sync Group

A questo punto è possibile procedere con la registrazione del server avviando l’agente Azure File Sync.

Figura 4 – Avvio del processo di Sign-in

Figura 5 – Selezione dei parametri di registrazione del server

Figura 6 – Conferma di registrazione dell’agente

Al termine della registrazione il server comparirà anche nella sezione “Registered servers” del portale Azure:

Figura 7 – Server registrati nel servizio Storage Sync

Conclusa la registrazione del server è opportuno inserire un Server Endpoint all’interno del Sync Group, il quale integra un volume oppure una folder specifica, con un Registered Server, creando una location per la sincronizzazione.

Figura 8 – Aggiunta di un Server Endpoint

Aggiungendo un Server Endpoint è possibile abilitare la funzionalità di Cloud tiering che consente di mantenere, localmente sulla cache della macchina Windows Server, i file acceduti più frequentemente, mentre tutti i restanti file vengono salvati in Azure sulla base di specifiche policy che è possibile configurare. Per maggiori informazioni relative alla funzionalità di Cloud Tiering è possibile consultare la documentazione ufficiale Microsoft. A questo proposito è opportuno specificare che al momento non c’è supporto tra Azure File Sync con abilitata la funzionalità di cloud tiering, e la deduplica del dato. Nel caso si desideri abilitare Windows Server Data Deduplication occorre mantenere disabilitata la funzionalità di cloud tiering.

Dopo aver aggiunto uno o più Server Endpoint è possibile consultare lo stato del Sync Group:

Figura 9 – Stato del Sync Group

 

Per ottenere dei deployment di successo di Azure File Sync è inoltre necessario verificare attentamente la compatibilità con le soluzioni antivirus e di backup che vengono utilizzate.

Azure File Sync e DFS Replication (DFS-R) sono due soluzioni per la replica del dato e possono funzionare anche in side-by-side purché siano rispettate queste condizioni:

  1. Azure File Sync cloud tiering deve essere disabilitato sui volumi con cartelle DFS-R replicate.
  2. I Server endpoints non devono essere configurati su cartelle DFS-R read-only.

Azure File Sync può essere un ottimo sostituto di DFS-R e per la migrazione è possibile seguire le indicazioni riportate in questo documento. Rimangono alcuni scenari specifici che possono richiedere l’utilizzo contemporaneo di entrambe le soluzioni di replica:

  • Non tutti i server on-premises che necessitano di una copia dei file possono essere connessi a Internet.
  • Quando i branch servers consolidano i dati in un singolo hub server, sul quale viene poi utilizzato Azure File Sync.
  • Durante la fase di migrazione di deployment di DFS-R verso Azure File Sync.

Conclusioni

Azure File Sync è una soluzione che consente di estendere il classico file server dislocato on-premises con nuove funzionalità di sincronizzazione dei contenuti, beneficando delle potenzialità del cloud pubblico di Microsoft in termini di scalabilità e flessibilità.

Microsoft Azure: guida per la scelta della Region

Microsoft Azure è dislocato in differenti luoghi sparsi per il mondo e vanta il primato di disporre di datacenter nel maggior numero di aree geografiche rispetto a qualsiasi altro cloud provider. Questo aspetto consente di disporre di un’ampia scalabilità, necessaria per erogare gli applicativi in prossimità della locazione geografica degli utenti, preservando al tempo stesso la residenza dei dati e offrendo opzioni complete di conformità e resiliency. Poter scegliere, tra differenti region Azure, dove attivare i propri servizi, ha indubbiamente numerosi vantaggi, ma è bene tenere in considerazione differenti aspetti nel momento in cui ci si trova di fronte a questa scelta. In questo articolo saranno riportati i principali elementi che è opportuno tenere in considerazione nella scelta della region di Azure.

Una region in Azure è composta da più datacenter che risiedono in una specifica area geografica e che sono connessi tra di loro tramite una network a bassa latenza. Per consultare la lista completa delle region Azure è possibile accedere alla pagina Azure locations. All’interno di una region sono presenti delle location fisicamente distinte denominate Availability Zones. Ogni Availability Zone è composta da uno più datacenter equipaggiati in modo indipendente dagli altri per quanto riguarda l’alimentazione, i sistemi di raffrescamento e la network. Ogni region è accoppiata con un’altra region all’interno della medesima area geografica, al fine di preservare la data resiliency ed aumentare i livelli di compliance.

Figura 1 – Pair region e Availability Zones all’interno dello stesso confine di data residency

Figure 2 – Azure regional pairs

La scelta della region Azure deve essere fatta prendendo attentamente in considerazione alcuni aspetti principali, ciascuno dei quali può influire in modo decisivo.

 

Performance

Sicuramente uno dei fattori predominanti nella scelta della region è data dalle performance, che sono vincolate dalle latenze di rete nel raggiungere i datacenter di Azure. Tipicamente si sceglie la region più vicina geograficamente, ma non sempre si riesce ad individuare facilmente. A supporto di questa scelta è possibile utilizzare alcuni utili strumenti di terze parti che forniscono dei valori oggettivi:

  • Azure Speed Test 2.0: accedendo a questo sito è possibile misurare la latenza dal proprio web browser ai vari Blob Storage Service che risiedono nelle varie region Azure.

Figure 3 – Risultato mostrato da Azure Speed Test

  • Azure Latency Test: viene riportata la latenza di rete dalla propria location verso le differenti region di Azure, con la possibilità di applicare facilmente dei filtri.

Figure 4 – Risultato mostrato da Azure Latency Test

 

Disponibilità dei servizi

Non tutti i servizi Azure sono disponibili in tutte le region, ne consegue che è opportuno verificare con attenzione se il servizio Azure che si intende utilizzare viene offerto nella region prescelta. Per consultare i servizi Azure disponibili in ciascuna region è possibile accedere a questa pagina, che consente di applicare rapidamente dei filtri per verificare la disponibilità dei servizi offerti per region.

 

Compliance legislative e residenza del dato

Molte organizzazioni sono caute nell’approccio al cloud computing in quanto hanno la necessità che i propri dati risiedano geograficamente su un determinato territorio. Mantenere la confidenzialità dei dati è per tutti fondamentale, ma per i clienti che hanno esigenze specifiche in termini di compliance e data-residency, Microsoft mette a disposizione tutte le informazioni necessarie:

  • Data residency: accedendo a questo sito web è possibile ottenere tutte le informazioni su dove risiedono i dati, facendo distinzione tra i servizi per i quali si scegli la region di appartenenza e quelli che non prevedono questa selezione durante il deployment.
  • Compliance: in questo portale vengono riportate informazioni di supporto utili per i clienti che devono adempiere a normative specifiche riguardanti l’utilizzo, la trasmissione e l’archiviazione dei dati.

 

Costi

I costi dei vari servizi Azure possono variare a seconda della region. Nel caso quindi gli altri fattori non siano determinanti nella scelta, può essere utile valutare di effettuare il deploy dei servizi nella region dove sono più vantaggiosi economicamente. Per poter verificare i costi dei vari servizi si può accedere alla pagina del pricing di Azure.

 

Conclusioni

La scelta della region Azure più opportuna per le proprie esigenze di business, deve essere fatta necessariamente tenendo in considerazione i diversi fattori riportati. Trattandosi di una scelta strategica e non facilmente modificabile, il consiglio è di esaminare con attenzione gli elementi citati, al fine di progettare al meglio la propria architettura in ambiente Microsoft Azure.

Azure Virtual WAN: introduzione alla soluzione

Azure Virtual WAN è un nuovo servizio di rete che consente di ottimizzare ed automatizzare la connettività branch-to-branch attraverso Azure. Grazie a questo servizio è possibile connettere e configurare i dispositivi di rete presenti nei branch per consentire la comunicazione con Azure (branch-to-Azure). In questo articolo vengono esaminati i componenti coinvolti in Azure Virtual WAN e viene riportata la procedura da seguire per la relativa configurazione.

 

Figura 1 – Azure Virtual WAN overview

La configurazione di Azure Virtual WAN prevede la creazione delle seguenti risorse.

 

Virtual WAN

La risorsa Virtual WAN rappresenta uno strato virtuale della rete Azure e colleziona differenti componenti. Si tratta di una stratificazione che contiene i link a tutti i virtual hub che si desidera avere all’interno della Virtual WAN. Le risorse Virtual WAN sono tra loro isolate e non possono contenere hub comuni.

Figura 2 – Avvio del processo di creazione di Azure Virtual WAN

Figura 3 – Creazione Azure Virtual WAN

Durante la creazione della risorsa Virtual WAN viene richiesto di specificare una location. In realtà si tratta di una risorsa globale che non risiede in una region particolare, ma viene richiesto di specificarla solo per poterla gestire e localizzare più facilmente.

Abilitando l’opzione Network traffic allowed between branches associated with the same hub viene consentito il traffico tra i vari sites (VPN o ExpressRoute) associati allo stesso hub (branch-to-branch).

Figura 4 – Branch-to-branch connectivity option

 

Site

Il site rappresenta l’ambiente on-prem. Sarà necessario creare tanti site quante sono le location fisiche. Se ad esempio è presente un branch office a Milano, uno a New York e uno a Londra, sarà necessario ceare tre site separati, i quali contengono i rispettivi endpoint degli apparati di rete utilizzati per instaurare la comunicazione. Nel caso si utilizzino apparati di rete di partner Virtual WAN, vengono fornite delle soluzioni che in modo nativo esportano queste informazioni nell’ambiente Azure.

Figura 5 – Creazione di un site

Nelle impostazioni avanzate è possibile abilitare l’opzione BGP, che se attivata diventa valida per tutte le connessioni create per il site specifico. Tra i campi facoltativi è possibile specificare le informazioni sui device, che possono essere di aiuto al Team Azure per future eventuali ottimizzazioni o in caso di supporto.

 

Virtual Hub

Un Virtual Hub è una Microsoft-managed virtual network. L’hub è il componente core di rete in una determinata region e può esistere un solo hub per Azure region. L’hub contiene diversi service endpoint per consentire di instaurare la connettività con l’ambiente on-prem. La creazione di un Virtual Hub comporta la generazione di una nuova VNet e opzionalmente di un nuovo VPN Gateway. L’Hub Gateway non è un classico virtual network gateway che si utilizza per la connettività ExpressRoute e VPN ed è utilizzato per creare una connessione Site-to-Site tra l’ambiente on-prem e l’hub.

Figura 6 – Creazione di un Hub

Figura 7 – Associazione del site con un Hub

Gli Hub è opportuno che siano associati ai site che risiedono nella stessa region dove si trovano le VNet.

 

Hub virtual network connection

La risorsa Hub virtual network connection è utilizzata per connettere l’hub con la rete virtuale. Attualmente è possibile creare connessioni (peering) con virtual network che risiedono nella stessa region dell’hub.

Figura 8 – Connessione della VNet a un hub

 

Configurazione del dispositivo VPN on-prem

Per configurare il dispositivo VPN on-prem è possibile procedere manualmente, oppure nel caso si utilizzino soluzioni di partner Virtual WAN, la configurazione dei dispositivi VPN può avvenire automaticamente. In quest’ultimo caso il device controller ottiene il file di configurazione da Azure e applica la configurazione ai dispositivi, evitando di dover procedere con configurazioni manuali. Il tutto risulta molto comodo ed efficace, consentendo di risparmiare tempo. Tra i vari partner virtual WAN troviamo: Citrix, Riverbed, 128 Technology, Barracuda, Check Point, NetFoundry e Paloalto. Questa lista è destinata ad ampliarsi a breve con ulteriori partner.

Selezionando Download VPN configuration viene creato uno storage account nel resource group ‘microsoft-network-[location]’ dal quale è possibile scaricare la configurazione dell’apparato VPN on-prem. Tale storage account può essere rimosso dopo aver recuperato il file di configurazione.

Figura 9 – Download della configurazione VPN

Figura 10 – Download del file di configurazione presente sullo storage account

Al termine della configurazione dell’apparato on-prem il site sarà connesso, come mostrato nella figura seguente:

Figura 11 – Stato del site connesso

Viene inoltre fornita la possibilità di instaurare delle connessioni ExpressRoute con Virtual WAN, associando il circuit ExpressRoue all’hub. Si prevede inoltre la possibilità di avere connessioni Point-to-Site (P2S) verso il virtual Hub. Al momento queste funzionalità sono in preview.

Nella sezione Health vengono riportate delle informazioni utili per verificare lo stato di salute della connettività per ciascun Hub.

Figura 12 – Check Hub health

 

Conclusioni

Virtual WAN è il nuovo servizio Azure che consente di realizzare in modo centralizzato, semplice e veloce il collegamento di vari branch, tra di loro e con il cloud pubblico di Microsoft. Tale servizio consente di ottenere un’ottima esperienza di connettività, traendo vantaggio dalla rete globale di Microsoft, la quale può vantare di raggiungere diverse region in tutto il mondo, più di qualsiasi altro cloud provider pubblico.

Azure Security Center: introduzione alla soluzione

Azure Security Center è una soluzione nel cloud che consente di prevenire, rilevare e rispondere alle minacce di sicurezza che interessano le risorse Azure e workloads in ambienti ibridi. In questo articolo vengono riportate le caratteristiche principali e le diverse funzionalità, per indirizzare casi di utilizzo e per comprendere le potenzialità dello strumento.

Funzionalità e caratteristiche principali di Azure Security Center

  • Gestisce delle policy di sicurezza in modo centralizzato. Garantisce la conformità rispetto ai requisiti di sicurezza che si intende imporre a livello aziendale e normativo. Il tutto viene gestito in modo centralizzato tramite delle policy di sicurezza che si potranno applicare ai differenti workloads.

Figura 1 – Policy & compliance Overview

Figura 2 – Policy management

  • Effettua un Security Assessment. In modo continuativo viene monitorata la situazione in termini di sicurezza di macchine, reti, storage e applicazioni, al fine di individuare potenziali problemi security.
  • Fornisce delle raccomandazioni che è possibile attuare. Vengono riportate delle indicazioni che è consigliato attuare per risolvere delle vulnerabilità di sicurezza che interessano il proprio ambiente, prima che queste possano essere sfruttate in potenziali attacchi informatici.

Figura 3 – Elenco raccomandazioni

  • Assegna delle priorità agli avvisi e ad eventuali incidenti di sicurezza. Grazie a questa prioritarizzazione è possibile focalizzarsi prima sulle minacce di sicurezza che possono impattare maggiormente sulla propria infrastruttura.

Figura 4 – Assegnazione severity per ogni segnalazione

Figura 5 – Assegnazione severity per ogni potenziale incident di security rilevato

  • Consente di configurare l’ambiente cloud per proteggerlo efficacemente. Viene messo a disposizione un metodo semplice, rapido e sicuro per consentire l’accesso just in time alle porte di gestione dei sistemi e alle applicazioni in esecuzione sulle VM, applicando controlli adattivi.

Figura 6 – Abilitazione Just in time VM access

  • Fornisce una soluzione di sicurezza completamente integrata. Consente di collezionare, ricercare e analizzare i dati di security provenienti da sorgenti differenti, comprendendo la possibilità di integrazione con soluzione di terze parti.

Figura 7 – Integrazioni con altre soluzioni di security

 

Costo della soluzione

Security Center viene offerto in due possibili tiers:

  • Free tier. In questo tier Azure Security Center è totalmente gratuito e fornisce visibilità sullo stato di sicurezza delle sole risorse che risiedono in Azure. Tra le funzionalità offerte troviamo: basic security policy, raccomandazioni di sicurezza e integrazione con i prodotti e i servizi di sicurezza di terze parti.
  • Standard tier. Rispetto al tier free aggiunge funzionalità avanzate di rilevamento delle minacce (tra cui threat intelligence), analisi comportamentale, rilevamento delle anomalie e di incidenti di sicurezza e report di attribuzione delle minacce. Lo standard tier estende la visibilità sulla security delle risorse che risiedono on-premises e a workloads ibridi. Attraverso tecniche di machine learning e avendo la possibilità di creare delle whitelist consente di bloccare malware e applicazioni non desiderate.

Figura 8 – Confronto di funzionalità tra i pricing tiers disponibili

 

Il tier Standard è possibile provarlo gratuitamente per 60 giorni dopodiché, se si desidera continuare ad utilizzare la soluzione, si ha un costo mensile per singolo nodo. Per maggiori informazioni sui costi della soluzione è possibile accedere alla pagina ufficiale dei costi.

Figura 9 – Schermata di upgrade al tier Standard

Per poter usufruire di tutte le funzionalità di Security Center è necessario applicare il tier Standard alla sottoscrizione o al gruppo di risorse contenente le macchine virtuali. La configurazione del tier Standard non abilita automaticamente tutte le funzionalità, ma alcune di queste richiedono configurazioni specifiche, come ad esempio VM just in time, i controlli adattivi delle applicazioni e la network detection per le risorse Azure.

 

Principi fondamentali di funzionamento

La raccolta dei dati di security dai sistemi, indipendentemente dalla loro locazione, avviene tramite il Microsoft Monitoring Agent, che ne provvede al relativo invio verso un workspace di Log Analytics. Security Center necessita quindi sempre di un workspace sul quale sarà abilitata la seguente solution in base al tier scelto:

  • Free tier: il Security Center abilita la solution SecurityCenterFree.
  • Standard tier: il Security Center abilita la solution Security. Se nel workspace è già installata la solution Security & Auditviene utilizzata quella e non viene installato nulla di aggiuntivo.

Per salvare i dati collezionati dal Security Center è possibile utilizzarne un workspace di Log Analytics creato di default oppure selezionarne uno specifico associato alla relativa subscription Azure.

Figura 10 – Configurazione del workspace di Log Analytics dove collezionare i dati raccolti

Conclusioni

Azure Security Center risulta una soluzione idonea, matura e strutturata per far fronte alle esigenze di sicurezza per ambienti cloud, on-premises oppure ibridi. Grazie alle diverse funzionalità contemplate mette a disposizione la conoscenza che Microsoft ha maturato nella gestione dei propri servizi, coniugandola con nuove e potenti tecnologie, come machine learning e big data, per trattare e gestire in modo consapevole ed efficace il tema della sicurezza.

OMS e System Center: novità di Agosto 2018

Nel mese di agosto sono state annunciate, da parte di Microsoft, un numero considerevole di 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)

Azure Log Analytics

Come già annunciato nell’articolo La gestione di Log Analytics dal portale Azure Microsoft ha scelto di abbandonare il portale OMS, a favore del portale Azure. La data annunciata per il ritiro definitivo del portale OMS è il 15 gennaio 2019. Come conseguenza di questa scelta anche la creazione di nuovi workspace di Azure Log Analytics potrà essere effettuata solamente dal portale Azure. Tentando di creare un nuovo workspace dal vecchio portale OMS si verrà ridiretti al portale Azure per completare l’operazione. Non sono invece state apportate modifiche alle REST API e a PowerShell per la creazione dei workspace.

Anche il portale Advanced Analytics viene inglobato nel portale Azure. Al momento risulta possibile accedere a questo portale accedendo alla sezione Logs (preview) disponibile nel workspace di Log Analytics.

Figura 1 – Advanced Analytics disponibile nella sezione Logs (preview) dal portale Azure

 

Azure Automation

La gestione degli aggiornamenti tramite Azure Automation Update Management vede l’aggiunta di una nuova opzione per il deployment degli update. In fase di creazione o di modifica di un update deployment è ora presente l’opzione Reboot, che consente di controllare se e quando effettuare il riavvio dei sistemi. Per maggiori informazioni in merito è possibile consultare la documentazione tecnica ufficiale.

Figura 2 – Reboot option disponibile nell’update deployment

Nella funzionalità di Change Traking sono stati apportati i seguenti cambiamenti:

  • Per rilevare le modifiche ed effettuare l’inventory dei file in ambiente Windows è ora possibile utilizzare: ricorsione, wildcards, e variabili d’ambiente. In Linux è già presente da tempo il supporto per la ricorsione e i wildcards.
  • Per quanto riguarda le modifiche che avvengo nei file, sia in ambiente Windows che in ambiente Linux, è stata introdotta la possibilità di visualizzare il contenuto delle modifiche apportate.
  • Introdotta la possibilità di ridurre la frequenza con la quale vengono collezionati i servizi di Windows (la frequenza è espressa in secondi e va da un minimo di 10 secondi a un massimo di 30 minuti).

Agente

Questo mese la nuova versione dell’agente OMS per sistemi Linux risolve alcuni bug e introduce una versione aggiornata per diversi componenti core, che ne aumentano la stabilità, la sicurezza e migliorano il processo di installazione. Tra le varie novità viene introdotto il supporto per Ubuntu 18.04. Per ottenere la versione aggiornata dell’agente OMS è possibile accedere alla pagina ufficiale GitHub OMS Agent for Linux Patch v1.6.0-163. Nel caso l’agente OMS per sistemi Linux sia stato installato utilizzando l’Azure Extension e se è attivo il relativo update automatico, questo aggiornamento sarà installato in autonomia.

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

 

Azure Site Recovery

Per Azure Site Recovery è stato rilasciato l’Update Rollup 27 che introduce nuove versioni per i seguenti componenti:

  • Microsoft Azure Site Recovery Unified Setup/Mobility agent (versione 9.18.4946.1): utilizzato per scenari di replica da VMware verso Azure.
  • Microsoft Azure Site Recovery Provider (versione 5.1.3550.0): utilizzato per scenari di replica da Hyper-V verso Azure oppure verso un secondary site.
  • Microsoft Azure Recovery Services agent (versione 2.0.9125.0): utilizzato per scenari di replica da Hyper-V verso Azure.

L’installazione di questo update rollup è consigliata in deployments dove sono presenti i componenti e le rispettive versioni in seguito riportate:

  • Unified Setup/Mobility agent versione 9.14.0000.0 o successiva.
  • Site Recovery Provider (with System Center VMM): version 3.3.x.x o successiva.
  • Site Recovery Provider (for replication without VMM): version 5.1.3100.0 o successiva.
  • Site Recovery Hyper-V Provider: version 4.6.x.x o successiva.

Per ottenere maggiori informazioni sulle problematiche risolte, sugli improvements dati da questo Update Rollup e per ottenere la procedura da seguire per la relativa installazione è possibile consultare la KB specifica 4055712.

 

In Azure Site Recovery è stato introdotto il supporto per abilitare scenari di disaster recovery Cross-subscription, per macchine virtuali IaaS, purché appartenenti allo stesso tenant Azure Active Directory. Questa funzionalità è molto utile perché spesso si hanno ambienti che utilizzano subscription Azure differenti, create principalmente per avere avere un maggior controllo dei costi. Grazie a questo nuovo supporto si possono raggiungere più facilmente i requisiti di business continuity creando piani di disaster recovery senza alterare la topologia delle subscription del proprio ambiente Azure.

Figura 4 – Configurazione replica VM verso una subscription target differente

 

Azure Site Recovery ora può integrarsi con Veritas Backup Exec Instant Cloud Recovery (ICR) con la versione di Backup Exec 20.2. Utilizzando ICR, gli utenti di Backup Exec sono in grado di configurare la replica delle VMs on-premises verso Azure e di azionare facilmente il proprio paino di DR in caso di necessità, riducendo il Recovery Point Objective (RPO) e il Recovery Time Objective (RTO). Instant Cloud Recovery richiede la presenza di una subscription Azure e supporta macchine virtuali VMware ed Hyper-V. Per ulteriori dettagli e riferimenti è possibile consultare l’annuncio specifico.

Azure Backup

In questo interessante articolo viene riportata la procedura per monitorare tutti i workloads protetti da Azure Backup utilizzando Log Analytics.

System Center

System Center Configuration Manager

Rilasciata la versione 1806 per il Current Branch (CB) di System Center Configuration Manager che introduce nuove funzionalità e importanti miglioramenti nel prodotto.

Tra le principali novità di questo aggiornamento emerge la nuova funzionalità chiamata CMPivot. Si tratta di una nuova utility disponibile nella console di Configuration Manager in grado di fornire informazioni in tempo reale riguardanti i dispositivi connessi nel proprio ambiente. Su queste informazioni è possibile applicare dei filtri e dei raggruppamenti, per poi svolgere determinate azioni.

Figura 5 – Caratteristiche e benefici della funzionalità CMPivot

Per l’elenco completo delle nuove funzionalità introdotte in questa versione di Configuration Manager è possibile consultare l’annuncio ufficiale.

 

Rilasciata la versione 1808 per il branch Technical Preview di System Center Configuration Manager. Questo aggiornamento introduce la possibilità di effettuare un rilascio graduale dei software update in modo automatico. Il pulsante che consente di configurare questa operazione è riportato nella figura seguente e si trova nei nodi della console All Software Updates, All Windows 10 Updates, e Office 365 Updates.

Figura 6 – Pulsante di creazione del Phased Deployment

Per maggiori informazioni sulla configurazione dei Phased Deployments in Configuration Manager è possibile consultare la relativa documentazione tecnica Microsoft.

Vi ricordo 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

Rilasciata la versione aggiornata del Microsoft System Center 2016 Management Pack per Microsoft Azure (versione 1.5.20.18).

Si segnalano inoltre le seguenti novità:

 

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 è necessario accedere all’Evaluation Center e dopo essersi registrati è possibile avviare il periodo di trial.

Azure Networking: introduzione al modello Hub-Spoke

Una topologia di rete sempre più adottata dai clienti che autilizzano Microsoft Azure è la topologia di rete definita Hub-Spoke. In questo articolo sono riportate le caratteristiche principali di questa architettura di rete, vengono esaminati i più comuni casi di utilizzo, e si evidenziano i principali vantaggi che si ottengono grazie a questa architettura.

La topologia Hub-Spoke

Nell’architettura di rete di tipologia Hub-Spoke, l’Hub è una rete virtuale in Azure che funge da punto di connettività verso la rete on-premises. Tale connettività può avvenire tramite VPN Site to site oppure tramite ExpressRoute. Gli Spoke sono le reti virtuali che eseguono il peering con l’Hub e possono essere usate per isolare i carichi di lavoro.

Questo uno schema di base dell’architettura:

Figura 1 – Architettura network Hub-Spoke di base

Questa architettura è pensata anche per posizionare nella rete di Hub una network virtual appliance (NVA) per controllare i flussi del traffico di rete in modo centralizzato.

Figura 2 – Possibile architettura della vNet di Hub in presenza di NVA

A questo proposito è opportuno evidenziare che Microsoft ha recentemente annunciato la disponibilità dell’Azure Firewall, un nuovo servizio gestito e totalmente integrato nel cloud pubblico di Microsoft, che consente di mettere in sicurezza le risorse presenti sulle Virtual Network di Azure. Al momento il servizio è in preview, ma presto sarà possibile valutare l’adozione dell’Azure Firewall per controllare in modo centralizzato, attraverso delle policy, i flussi di comunicazione di rete, il tutto in modo cross subscription e per differenti virtual network. Questo servizio, in presenza di architetture di rete di tipologia Hub-Spoke, si presta per essere posizionato nella rete di Hub, in modo da ottenere un controllo completo del traffico di rete.

Figura 3 – Posizionamento dell’Azure Firewall nella rete di Hub

Per maggiori dettagli sull’Azure Firewall è possibile consultare l’articolo Introduzione ad Azure Firewall.

Quando utilizzare la topolgia Hub-Spoke

L’architettura di rete Hub-Spoke è tipicamente utilizzata in scenari dove sono richieste queste caratteristiche in termini di connettività:

  • In presenza di workload deployati in ambienti differenti (sviluppo, test e produzione) i quali devono accedere ai servizi condivisi come ad esempio DNS, IDS, Active Directory Domain Services (AD DS). I servizi condivisi saranno posizionati nella virtual network di Hub, mentre i vari ambienti (sviluppo, test e produzione) saranno deployati nelle reti di Spoke per mantenere un elevato livello di isolamento.
  • Quando determinati workloads non devono comunicare con tutti gli altri workloads, ma solamente con i servizi condivisi.
  • In presenza di realtà che richiedono un elevato livello di controllo sugli aspetti legati alla sicurezza di rete e che necessitano di effettuare una segregazione del traffico di rete.

Figura 4 – Disegno dell’architettura Hub-Spoke con i relativi componenti

I vantaggi della topologia Hub-Spoke

I vantaggi di questa topologia di rete Azure possono essere così sintetizzati:

  • Risparmio sui costi, dati dal fatto che si possono centralizzare in un’unica posizione i servizi condivisi da più carichi di lavoro, come ad esempio i server DNS ed eventuali appliance virtuali. Si riducono inoltre i VPN Gateway necessari per fornire connettività verso l’ambiente on-premises, con un risparmi sui costi Azure.
  • Possibilità di separazione granulare dei compiti tra IT (SecOps, InfraOps) e workloads (DevOps).
  • Maggiore flessibilità in termine di gestione e sicurezza dell’ambiente Azure.

Riferimenti utili per approfondimenti

Si riportano i riferimenti alla documentazione tecnica Microsoft utili per indirizzare ulteriori approfondimenti su questa tematica:

Conclusioni

Uno dei primi aspetti da tenere in considerazione quando si decide di implementare soluzioni nel cloud è l’architettura di rete da adottare. Stabilire fin dall’inizio la topologia di rete più opportuna consente di avere una strategia vincente ed evita di trovarsi nella condizione di dover migrare in seguito dei workloads, per adottare architetture di rete differenti, con tutte le complicazioni che ne conseguono.

Ogni implementazione richiede una attenta analisi al fine di tenere in considerazione tutti gli aspetti e di effettuare le opportune valutazioni. Non è quindi possibile affermare che l’architettura di rete Hub-Spoke sia idonea per tutti gli scenari, ma introduce certamente diversi benefici che la rendono efficace per ottenere determinate caratteristiche ed avere un elevato livello di flessibilità.

OMS e System Center: novità di Luglio 2018

Microsoft annuncia in modo costante novità riguardanti Operations Management Suite (OMS) e System Center. Come di consueto la nostra community rilascia questo riepilogo mensile 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 ulteriori approfondimenti.

Operations Management Suite (OMS)

Azure Log Analytics

La possibile integrazione di Azure Data Factory (ADF) con Azure Monitor consente di inviare le metriche di utilizzo verso Operations Management Suite (OMS). La nuova solution Azure Data Factory Analytics, disponibile nell’Azure marketplace, può fornire una panoramica sullo stato di salute del proprio Data Factory, consentendo di andare nel dettaglio delle informazioni raccolte. Questo può risultare molto utile in particolare per operazioni di troubleshooting. Risulta inoltre possibile collezionare le metriche provenienti da diverse data factories verso lo stesso workspace di OMS Log Analytics. Per i dettagli sulla configurazione necessaria per utilizzare questa solution, è possibile consultare la documentazione ufficiale.

Figura 1 – Overview della nuova solution Azure Data Factory Analytics

Nell’esecuzione delle query di Log Analytics è stata introdotta la possibilità di selezionare facilmente il workspace sul quale eseguire le interrogazioni:

Figura 2 – Selezione del workspace su cui effettuare le query di Log Analytics

La stessa possibilità è stata introdotta anche in Azure Application Insights Analytics. Tale funzionalità risulta utile in quanto in ogni query tab è possibile selezionare il workspace specifico, evitando di dover aprire Log Analytics in tab differenti del browser.

Nel caso vengano collezionati custom logs in Azure Log Analytics, è stata creata una categoria separata denominata “Custom Logs”, dove vengono raggruppati.

Figura 3 – Raggruppamento dei custom logs nella categoria specifica

Per i workspace di Log Analytics presenti nelle region di West Europe, East US, e West Central è stata annunciata la disponibilità in public preview dei Metric Alerts per i logs. I Metric alerts per i logs consentono di utilizzare i dati provenienti da Log Analytics come metriche di Azure Monitor. La tipologia dei log supportati è stata estesa e la lista completa è disponibile a questo indirizzo. Per ulteriori informazioni in merito è possibile consultare la documentazione ufficiale.

Azure Backup

In Azure Pricing Calculator, lo strumento ufficiale Microsoft per stimare i costi dei servizi Azure, è stata introdotta la possibilità di ottenere una stima più accurata dei costi di Azure Backup, consentendo di specificare il range di retention dei vari Recovery Point.

Figura 4 – Nuovi parametri per effettuare una stima più accurata dei costi di Azure Backup

 

Azure Site Recovery

Per Azure Site Recovery è stato rilasciato l’Update Rollup 26 che introduce nuove versioni per i seguenti componenti:

  • Microsoft Azure Site Recovery Unified Setup/Mobility agent (versione 9.17.4897.1): utilizzato per scenari di replica da VMware verso Azure.
  • Microsoft Azure Site Recovery Provider (versione 5.1.3400.0): utilizzato per scenari di replica da Hyper-V verso Azure oppure verso un secondary site.
  • Microsoft Azure Recovery Services agent (versione 2.0.9122.0): utilizzato per scenari di replica da Hyper-V verso Azure.

L’installazione di questo update rollup è consigliata in deployments dove sono presenti i componenti e le rispettive versioni in seguito riportate:

  • Unified Setup/Mobility agent versione 9.13.000.1 o successiva.
  • Site Recovery Provider versione 5.1.3000 o successiva.
  • Hyper-V Recovery Manager 3.4.486 o successiva.
  • Site Recovery Hyper-V Provider 4.6.660 o successiva.

Per ottenere maggiori informazioni sulle problematiche risolte, sugli improvements dati da questo Update Rollup e per ottenere la procedura da seguire per la relativa installazione è possibile consultare la KB specifica 4344054.

Azure Automation

Per quanto riguarda Azure Automation è stata introdotta la possibilità di configurare gli Hybrid Runbook Workers in modo che possano eseguire solamente runbook digitalmente firmati (l’esecuzione di runbook unsigned non andrà a buon fine). La procedura da seguire è riportata in questa sezione dell’articolo Microsoft.

System Center

In seguito al primo annuncio della Semi-Annual Channel release di System Center, avvenuto nel mese di febbraio con la versione 1801, questo mese è stata rilasciata la nuova update release, System Center 1807.

L’update release 1807 introduce nuove funzionalità per Virtual Machine Manager e Operations Manager, mentre per Data Protection Manager, Orchestrator e Service Manager contiene fix per problemi noti (includendo i bug fixes presenti nell’UR5 di System Center 2016, rilasciata in aprile).

Novità introdotte in Virtual Machine Manager 1807
  • Supports selection of CSV for placing a new VHD
  • Display of LLDP information for networking devices
  • Convert SET switch to logical switch
  • VMware host management: VMM 1807 supports VMware ESXi v6.5 servers in VMM fabric
  • Support for S2D cluster update
  • Support for SQL 2017
Novità introdotte in Operations Manager 1807
  • Configure APM component during agent install or repair
  • Linux log rotation
  • HTML5 Web console enhancements
  • Support for SQL Server 2017
  • Operations Manager and Service Manager console coexistence

Per maggiori informazioni a riguardo è possibile consultare la documentazione ufficiale Microsoft:

System Center 1807 è possibile scaricarlo dal System Center Evaluation Center.

Per tutti i prodotti System Center (DPM, SCORCH, SM, VMM e SCOM) è ora possibile aggiornare i deployment esistenti passando da SQL server 2016 a SQL server 2017.

Si ricorda infine che le release appartenenti al Semi-Annual Channel hanno un periodo di supporto di 18 mesi.

System Center Configuration Manager

Rilasciata la versione 1807 per il branch Technical Preview di System Center Configuration Manager. La novità principale presente in questo rilascio è l’introduzione del nuovo community hub, attraverso il quale è possibile condividere scripts, reports, configuration items ed altro, relativamente a Configuration Manager. Attraverso il community hub, accessibile dalla console di SCCM, è possibile introdurre nel proprio ambiente soluzioni messe a disposizione dalla community.

Tra le novità introdotte in questo rilascio troviamo inoltre:

  • Improvements to third-party software updates
  • Co-managed device activity sync from Intune
  • Approve application requests via email
  • Repair applications
  • Admin defined offline operating system image servicing drive
  • Improvements to run scripts

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

Per poter configurare la connessione tra Operations Management Suite (OMS) e System center Operations Manager è necessario importare i seguenti nuovi management packs, specifici per versione:

Questa modifica ai MPs è stata resa necessaria per consentire la corretta comunicazione con le nuove APIs di OMS Log Analytics, introdotte in seguito allo spostamento verso il portale Azure di Log Analytics.

Figura 5 – Wizard di SCOM per l’onboarding di OMS

Si riporta la nuova wave dei management packs di System Center Operations Manager rilasciati per SQL Server, ora allineati alla versione 7.0.7.0:

Nel mese di Luglio sono inoltre stati rilasciati i seguenti Management Packs per software Open Source, versione 7.7.1129.0, che comprendono le seguenti novità:

Apache HTTP Server

  • Supports Apache HTTP Server version 2.2 and 2.4
  • Provides monitoring of busy and idle workers
  • Provides monitoring of resource usage – memory and CPU
  • Provides statistics for virtual hosts such as “Requests per Minute” and “Errors per Minute”
  • Provides alerting for SSL Certificate expiration

MySQL Server

  • Supports MySQL Server version 5.0, 5.1, 5.5, 5.6, and 5.7
  • Supports MariaDB Server version 5.5, and 10.0
  • Provides monitoring of databases
  • Provides monitoring of disk space usage for server and databases
  • Provides statistics for Key Cache, Query Cache, and Table Cache
  • Provides alerting for slow queries, failed connections, and full table scans

Sono stati inoltre rilasciati da parte di Microsoft i seguenti nuovi MPs:

  • MP per Active Directory Federation Services versione 0.2.0
  • MP per Active Directory Federation Services 2012 R2 versione 1.10172.1
  • MP per Microsoft Azure versione 5.20.18

Si segnala inoltre la nuova versione community (1807) del Management Pack di Azure, rilasciata da Daniele Grandini.

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 è possibile accedere all’Evaluation Center e dopo essersi registrati è possibile avviare il periodo di trial.

Introduzione ad Azure Firewall

Microsoft ha recentemente annunciato la disponibilità di un servizio da tempo atteso e richiesto da coloro che utilizzano sistemi in ambiente Azure, si tratta dell’Azure Firewall. L’Azure Firewall è un nuovo servizio gestito e totalmente integrato nel cloud pubblico di Microsoft, che consente di mettere in sicurezza le risorse presenti sulle Virtual Network di Azure. In questo articolo verranno esaminate le caratteristiche principali di questo nuovo servizio, attualmente in preview, e sarà riportata la procedura da seguire per la relativa attivazione e configurazione.

Figura 1 – Posizionamento dell’Azure Firewall nell’architettura di rete

L’Azure Firewall è un firewall di tipologia stateful, grazie al quale è possibile controllare in modo centralizzato, attraverso delle policy, i flussi di comunicazione di rete, il tutto in modo cross subscription e per differenti virtual network. Questo servizio, in presenza di architetture di rete di tipologia hub-spoke, si presta per essere posizionato nella rete di Hub, in modo da ottenere un controllo completo del traffico.

Le funzionalità dell’Azure Firewall, attualmente disponibili in questa fase di public preview, sono le seguenti:

  • High availability (HA) Built-in: l’alta disponibilità è integrata nel servizio e non sono richieste configurazioni specifiche o componenti aggiuntivi per renderla effettiva. Questo è sicuramente un elemento che lo distingue rispetto a soluzioni di terze parti che, per la configurazione delle Network Virtual Appliance (NVA) in HA, richiedono tipicamente la configurazione di load balancer aggiuntivi.
  • Unrestricted cloud scalability: Azure Firewall consente di scalare facilmente per adeguarsi ad eventuali cambi dei flussi di rete.
  • FQDN filtering: si ha la possibilità di limitare il traffico in uscita HTTP/S verso una specifica lista di fully qualified domain names (FQDN), con la possibilità di utilizzare caratteri wild card nella creazione delle regole.
  • Network traffic filtering rules: si possono creare regole di allow oppure di deny per filtrare il traffico di rete sulla base dei seguenti elementi: indirizzo IP sorgente, indirizzo IP di destinazione, porte e protocolli.
  • Outbound SNAT support: all’Azure Firewall viene assegnato un indirizzo IP Pubblico statico, il quale sarà utilizzato dal traffico in uscita (Source Network Address Translation), generato dalle risorse della virtual nertwork di Azure, consentendone una facile identificazione dalle destinazioni internet remote.
  • Azure Monitor logging: tutti gli eventi dell’Azure Firewall possono essere integrati in Azure Monitor. Nelle impostazioni della diagnostica è consentito abilitare l’archiviazione dei log in uno storage account, effettuare lo stream verso un Event Hub, oppure impostare l’invio verso un workspace di OMS Log Analytics.

Azure Firewall si trova al momento in una preview pubblica gestita, il che significa che per implementarlo è necessario effettuare in modo esplicito l’abilitazione tramite il comando PowerShell Register-AzureRmProviderFeature.

Figura 02 – Comandi PowerShell per l’abilitazione della public preview dell’Azure Firewall

La registrazione della feature può richiedere fino a 30 minuti ed è possibile monitorare lo stato di registrazione con i seguenti comandi PowerShell:

Figura 03 – Comandi PowerShell per verificare lo stato di abilitazione dell’Azure Firewall

Al termine della registrazione è necessario eseguire il seguente comando PowerShell:

Figura 04 – Comando di registrazione del Network Provider

Per effettuare il deployment dell’Azure Firewall su una determinata Virtual Network è necessaria la presenza di una subnet denominata AzureFirewallSubnet, che deve essere configurata con una sunbnet mask almeno /25.

Figura 05 – Creazione della subnet AzureFirewallSubnet

Per effettuare il deployment dell’Azure Firewall dal portale Azure è necessario selezionare Create a resource, Networking e successivamente See all:

Figura 06 – Ricerca dell’Azure Firewall nelle risorse Azure

Filtrando per Firewall comparirà anche la nuova risorsa Azure Firewall:

Figura 07 – Selezione della risorsa Microsoft Firewall

Avviando il processo di creazione comparirà la seguente schermata che richiede l’inserimento dei parametri necessari per effettuare il deployment:

Figura 08 – Inserimento dei parametri necessari per il deployment del Firewall

Figura 09 – Review dei parametri selezionati e conferma di creazione

Per fare in modo di far confluire il traffico in uscita di una determinata subnet verso il firewall è necessario creare una route table contenente una rotta con le seguenti caratteristiche:

Figura 10 – Creazione della regola di inoltro del traffico verso il servizio Firewall

Nonostante Azure Firewall sia un managed service è necessario specificare Virtual appliance come next hop. L’indirizzo del next hop sarà l’IP privato dell’Azure Firewall.

La route table sarà da associare alla virtual network che si desidera controllare tramite Azure Firewall.

Figura 11 – Associazione della route table alla subnet

A questo punto, per i sistemi attestati sulla subnet che inoltra il traffico verso il Firewall, non sarà consentito il traffico in uscita, fintanto che non verrà esplicitamente abilitato:

Figura 12 – Tentativo di accesso al sito web bloccato dall’Azure Firewall

Azure Firewall mette a disposizione le seguenti tipologie di regole per controllare il traffico in uscita.

Figura 13 – Tipologie di regole disponibili

  • Application rules: consentono di configurare l’accesso a determinati fully qualified domain names (FQDNs) da una determinata subnet.

 

Figura 14 – Creazione Application rule per consentire l’accesso ad un sito web specifico

  • Network rules: permettono la configurazione di regole che contengono l’indirizzo sorgente, il protocollo, l’indirizzo e la porta di destinazione.

Figura 15 – Creazione Network rule per consentire il traffico sulla porta 53 (DNS) verso uno specifico DNS Server

Conclusioni

Poter disporre di un firewall completamente integrato nella fabric di Azure è sicuramente un vantaggio importante che consente di arricchire le funzionalità offerte in modo nativo da Azure. Al momento sono configurabili operazioni di base, ma il set di funzionalità è sicuramente destinato ad arricchirsi in tempi brevi. Si ricorda che al momento si tratta di un servizio in preview, e come tale non viene garantito nessun service level agreement e non è consigliato utilizzarlo in ambienti di produzione.

Azure Application Gateway: come monitorarlo con Log Analytics

L’Azure Application Gateway è un load balancer applicativo (OSI layer 7) per il traffico web, disponibile in ambiente Azure, che consente di gestire il traffico HTTP e HTTPS delle applicazioni. In questo articolo verrà approfondito come effettuare il monitor degli Azure Application Gateway utilizzando Log Anaytics.

Figura 1 – Schema di base dell’Azure Application Gateway

Utilizzando l’Azure Application Gateway è possibile usufruire delle seguenti funzionalità:

  • Routing basato su URL
  • Redirection
  • Multiple-site hosting
  • Session affinity
  • Secure Sockets Layer (SSL) termination
  • Web application firewall (WAF)
  • Supporto nativo per i protocolli WebSocket e HTTP/2

Per maggiori dettagli sugli Azure Application Gateway è possibile consultare la documentazione ufficiale Microsoft.

Configurazione Diagnostics logs dell’Application Gateway

L’Azure Application Gateway prevede l’invio dei log di diagnostica verso un workspace di Log Analytics. Questa funzionalità è molto utile per controllare le performance, per rilevare eventuali errori ed è   fondamentale per operazioni di troubleshooting, in particolare in presenza del modulo WAF.  Per abilitare la diagnostica dal portale Azure è possibile selezionare la risorsa Application Gateway specifica ed accedere alla sezione “Diagnostics logs”:

Figura 2 –  Avvio della configurazione dei Diagnostics logs

Figura 3 – Configurazione dei Diagnostics logs

Dopo aver scelto il workspace di Log Analytics dove inviare i dati di diagnostica, nella sezione Log, è possibile selezionare quale tipologia di Log collezionare tra i seguenti:

  • Access log (ApplicationGatewayAccessLog)
  • Performance log (ApplicationGatewayPerformanceLog)
  • Firewall log (ApplicationGatewayFirewallLog): questi log vengono generati solo se il Web Application Firewall è configurato sull’Application Gateway.

Oltre a questi log sono inoltre collezionati di default gli Activity Log generati da Azure. Questi log vengono mantenuti per 90 giorni nello store dell’Azure event logs. Per maggiori dettagli è possibile consultare questo documento specifico.

Solution Azure Application Gateway analytics di Log Analytics

Microsoft mette a disposizione la solution Azure Application Gateway analytics che può essere aggiunta al workspace di Log Analytics seguendo questi semplici step:

Figura 4 – Avvio della procedura di aggiunta della solution al workspace OMS

Figura 5 – Selezione della solution Azure Application Gateway analytics

Figura 6 – Aggiunta della solution nel workspace selezionato

Dopo aver abilitato l’invio dei log di diagnostica verso il workspace di Log Analytics ed aver aggiunto sullo stesso la solution, selezionando il tile Azure Application Gateway analytics presente nella pagina di Overview, si potrà visualizzare una overview dei dati di log raccolti dall’Application Gateway:

Figura 7 – Schermata di overview della solution Azure Application Gateway analytics

Sarà inoltre possibile consultare i dettagli per le seguenti categorie.

  • Application Gateway Access logs:
    • Client and server errors for Application Gateway access logs
    • Requests per hour for each Application Gateway
    • Failed requests per hour for each Application Gateway
    • Errors by user agent for Application Gateways

Figura 8 – Schermata degli Application Gateway Access logs

  • Application Gateway performance:
    • Host health for Application Gateway
    • Maximum and 95th percentile for Application Gateway failed requests

Figura 9 – Schermata delle performance degli Application Gateway

Dashboard personalizzata di Log Analytics per il monitor dell’Application Gateway

Oltre a questa solution può essere conveniente utilizzare anche una apposita dashboard di Log Analytics, specifica per il monitoring dell’Application Gateway, reperibile a questo indirizzo. Il deploy della dashboard avviene tramite template ARM e richiede anche in questo caso l’abilitazione dei Diagnostics logs dell’Application Gateway, come descritto precedentemente. Le varie query di Log Analytics, utilizzate dalla dashboard, sono documentate in questo blog. Grazie a queste query la dashboard riporta diverse informazioni aggiuntive esposte dalla diagnostica dell’Application Gateway.

Figura 10 – Dashboard custom di Log Analytics per il monitor dell’Application Gateway

Query di Log Analytics per monitorare i Firewall Log

Utilizzando la solution Azure Application Gateway analytics di Log Analytics oppure la dashboard custom (riportata nel paragrafo precedente) non sono al momento contemplati i Firewall log, generati quando risulta attivo il Web Application Firewall (WAF) sull’Application Gateway. Il WAF si basa sulle regole di OWASP Core Rule Set 3.0 o 2.2.9 per intercettare gli attacchi, alle applicazioni Web, che sfruttano le più note vulnerabilità. Per citarne alcune, troviamo ad esempio gli attacchi SQL injection e gli attacchi cross site scripting.

In questo caso, qualora si decida di verificare i Firewall log, è necessario eseguire direttamente delle query di Log Analytics, come ad esempio:

Figura 11 – Query di LA per recuperare le richieste bloccate dal modulo WAF, negli ultimi 7 giorni, per uno specifico URI, suddivise per RuleId

Per consultare la lista delle regole del WAF, associando il RuleId alla relativa description, è possibile consultare questo documento.

Il messaggio descrittivo della rule viene riportato anche all’interno dei risultati restituiti dalla query:

Figura 12 – Query di LA per recuperare le richieste bloccate dal modulo WAF, negli ultimi 7 giorni, per uno specifico URI e per specifica RuleId

Conclusioni

Secondo la mia esperienza, nelle architetture Azure che richiedono la pubblicazione sicura di servizi Web verso internet, è spesso utilizzato il servizio Azure Application Gateway con il modulo WAF attivo. Grazie alla possibilità di inviare i log di diagnostica di questo componente verso Log Analytics si ha la possibilità di avere un monitor completo, che risulta fondamentale per analizzare eventuali condizioni di errore e per valutare lo stato del componete in tutte le sue sfaccettature.

OMS e System Center: novità di Giugno 2018

Nel mese di giugno sono state annunciate, da parte di Microsoft, un numero considerevole di novità riguardanti Operations Management Suite (OMS) e System Center. La nostra community, tramite questi articoli rilasciati mensilmente, vuole fornire una panoramica complessiva delle principali novità del mese, in modo da rimanere sempre aggiornati su questi argomenti ed avere i riferimenti necessari per effettuare maggiori approfondimenti.

Operations Management Suite (OMS)

Log Analytics

Recentemente è stato ufficialmente annunciato che il portale OMS sarà deprecato, a favore del portale Azure. In questo articolo vengono esaminati gli aspetti legati a questo cambiamento e cosa è bene sapere per non farsi cogliere impreparati.

Figura 1 – Notifiche presenti nel portale OMS

Azure Backup

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 vengono riportati i benefici introdotti e le caratteristiche di questa nuova funzionalità.

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

Rilasciata una versione aggiornata dell’Azure Backup agent (MARS), la quale la si può ottenere accedendo a questo indirizzo.

Utilizzando Azure Backup c’è la possibilità di generare la reportistica necessaria per poter facilmente controllare lo stato di protezione delle risorse, i dettagli sui vari job di backup configurati, l’effettivo utilizzo dello storage e lo stato dei relativi alert. Il tutto è reso possibile grazie all’utilizzo di Power BI, che consente di avere un elevato grado di flessibilità nella generazione e nella personalizzazione della reportistica. In questo video, recentemente pubblicato, viene riportato come configurare un workspace Power BI per la condivisione dei reports di Azure Backup all’interno della propria organizzazione. Per analizzati gli step necessari per configurare la reportistica di Azure Backup è possibile consultare questo articolo.

Figura 3 – La condivisione di report PowerBI di Azure Backup

In Azure Backup è stata introdotta la possibilità di proteggere workloads in esecuzione in ambiente Azure Stack. I tenant che usufruiscono della soluzione Azure Stack possono quindi disporre di una protezione short term direttamente sull’ambiente Azure Stack e possono usufruire dei Recovery Service vault in Azure per la long term retention e per effettuare l’offsite. Per maggiori dettagli a riguardo è possibile consultare l’annuncio del rilascio.

Figura 4 – Azure Stack Tenant backup con Microsoft Azure Backup Server

Azure Site Recovery

In Azure Site Recovery (ASR) è stata annunciata in “general availability (GA)” la funzionalità che consente di configurare il Disaster Recovery (DR) di Azure Virtual Machines. Configurando la replica delle macchine virtuali in region differenti di Azure, si ha la possibilità di rendere le applicazioni resilienti ad eventuali guasti che interessano una specifica region di Azure. Questa funzionalità è disponibile in tutte le region Azure dove è possibile utilizzare ASR. Azure è il primo cloud pubblico a offrire una soluzione nativa di Disaster Recovery per le applicazioni in esecuzione in ambiente IaaS.

Durante il periodo di preview, Microsoft ha preso in considerazione i diversi feedback ricevuti dai client ed ha aggiunto alla soluzione le seguenti importati funzionalità:

Si segnalano questi utili riferimenti riguardanti questa soluzione:

Security e Audit

La solution Azure Network Security Group Analytics sarà sostituita da Traffic Analytics che è stato rilasciato in General availability (GA). Questa soluzione, totalmente cloud-based, consente di avere una visibilità complessiva sulle attività di rete che vengono intraprese nell’ambiente cloud. Per maggiori dettagli a riguardo è possibile consultare l’articolo “Come monitora le attività di rete nel cloud Azure con Traffic Analytics

System Center

System Center Data Protectrion Manager

In ambienti dove System Center Data Protection Manager (SCDPM) è connesso al servizio Azure Backup è stata introdotta la possibilità di visualizzare tutti gli items protetti, i dettagli sull’utilizzo dello storage e le informazioni sui recovery point, direttamente dal portale Azure, all’interno dei Recovery Service vault. Questa funzionalità è supportata per SCDPM 2012 R2, 2016 e per Azure Backup Server v1 e v2, purché sia installata l’ultima versione dell’Azure Backup Agent (MARS).

Figura 5 – Informazioni provenienti da DPM riportate nel Recovery Service vault

System Center Configuration Manager

Solitamente viene rilasciata una technical preview al mese di Configuration Manager, ma questo mese, visto il numero considerevole di novità, ne sono state rilasciate due.

La prima è la versione 1806 per il branch Technical Preview di System Center Configuration Manager. La principale novità introdotta da questo aggiornamento è l’aggiunta del supporto per il software update catalogs di terze parti. Dalla console di Configuration Manager si potrà facilmente effettuare la sottoscrizione al catalog degli update di partner software di terze parti, per poi pubblicare gli updates tramite il Software Update Point. Tali aggiornamenti potranno essere rilasciati ai client utilizzando il metodo classico di Configuration Manager per la distribuzione dei software update.

Figura 6 – Accesso al software update catalogs di terze parti dalla console di SCCM

Oltre a questa nuova funzionalità sono stati rilasciati aggiornamenti riguardanti:

  • Sync MDM policy from Microsoft Intune for a co-managed device
  • Office 365 workload transition in co-management
  • Configure Windows Defender SmartScreen settings for Microsoft Edge
  • Improvements to the Surface dashboard
  • Office Customization Tool integration with the Office 365 Installer
  • Content from cloud management gateway
  • Simplified client bootstrap command line
  • Software Center infrastructure improvements
  • Removed Network Access Account (NAA) requirement for OSD Boot Media
  • Removed Network Access Account (NAA) requirement for Task Sequences
  • Package Conversion Manager
  • Deploy updates without content
  • Currently logged on user information is shown in the console
  • Provision Windows app packages for all users on a device

La seconda è la versione 1806.2 per il branch Technical Preview di System Center Configuration Manager, che include principalmente le seguenti novità relative al Phased deployment:

  • Possibilità di monitorare lo stato in modo nativo, dal Deployments node.
  • Possibilità di creare Phased deployment di applications e non solo per le task sequences.
  • Possibilità di effettuare un rollout graduale durante la fase di deployment.

Inoltre questa preview contiene aggiornamenti riguardanti:

  • Management Insights for proactive maintenance
  • Mobile apps for co-managed devices
  • Support for new Windows app package formats
  • New boundary group options for optimized P2P behaviors
  • Third-party software updates support for custom catalogs
  • Compliance 9 – Overall health and compliance (Report)

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

Rilasciata una versione aggiornata del Management Pack per OS Windows Server 2016 e 1709 Plus che include diversi aggiornamenti e risoluzioni di problematiche. Per maggiori informazioni a riguardo è possibile consultare questo articolo.

Rilasciata la versione 8.2 del MP Author che include diversi miglioramenti. Per la lista delle novità incluse in questa nuova versione è possibile consultare l’annuncio ufficiale del rilascio.

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 all’Evaluation Center e dopo essersi registrati è possibile avviare il periodo di trial.