Archivi categoria: Microsoft Azure

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.

Microsoft Azure: panoramica delle soluzioni di monitoring per la rete

In Microsoft Azure sono disponibili diverse soluzioni che consentono di monitorare le risorse di rete, non solo per ambienti cloud, ma anche in presenza di architetture ibride. Si tratta di funzionalità cloud-based, orientate a controllare lo stato di salute della rete e la connettività verso le proprie applicazioni. Inoltre, sono in grado di fornire informazioni dettagliate sulle performance di rete. In questo articolo verrà effettuata una panoramica delle diverse soluzioni riportandone le caratteristiche principali, necessarie per orientarsi nell’utilizzo degli strumenti di monitor della rete più opportuni per le proprie esigenze.

Network Performance Monitor (NPM) è una suite che comprende le seguenti soluzioni:

  • Performance Monitor
  • ExpressRoute Monitor
  • Service Endpoint Monitor

Oltre agli strumenti inclusi in Network Performance Monitor (NPM) è possibile utilizzare Traffic Analytics e DNS Analytics.

Performance Monitor

L’approccio sempre più frequentemente utilizzato è quello di avere ambienti ibridi con un networking eterogeneo, che consente di mettere in comunicazione la propria infrastruttura on-premises con l’ambiente implementato nel cloud pubblico. In alcuni casi si potrebbe disporre anche di differenti cloud provider, che rendono ancor più complicata l’infrastruttura di rete. Questi scenari richiedono pertanto l’utilizzo di strumenti di monitor flessibili e che possano lavorare in modo trasversale on-premises, in cloud (IaaS), e in ambienti ibridi. Performance Monitor ha tutte queste caratteristiche e grazie all’utilizzo di transazioni sintetiche, fornisce la possibilità di monitorare, pressoché in tempo reale, i parametri di rete per avere le informazioni relative alle performance, come la perdita di pacchetti e la latenza. Inoltre, questa soluzione consente di localizzare facilmente la sorgente di una problematica in uno specifico segmento di rete o identificando un determinato dispositivo. La soluzione richiede la presenza dell’agente di OMS e tenendo traccia dei pacchetti di retransmission e del tempo di roundtrip, è in grado di restituire un grafico di facile e immediata interpretazione.

Figura 1 – Diagramma Hop-by-hop fornito da Performance Monitor

Dove installare gli agenti

L’installazione dell’agente di Operations Management Suite (OMS) è necessario farla su almeno un nodo connesso a ogni sottorete dalla quale si intende monitorare la connettività verso altre sottoreti. Nel caso si intenda monitorare uno specifico link di rete è necessario installare gli agenti su entrambe gli endpoint del link. Nei casi dove non si è a conoscenza della topologia esatta di rete, un possibile approccio è quello di installare gli agenti su tutti i server che detengono workload particolarmente critici e per i quali è necessario monitorare le performance di rete.

Costo della soluzione

Il costo della funzionalità Performance Monitor in NPM è calcolato sulla base della combinazione di questi due elementi:

  • Subnet link monitorati. Per ottenere i costi per il monitoring di un singolo subnet link per un mese, è possibile consultare la sezione Ping Mesh.
  • Volume di dati.

Per maggiori dettagli a riguardo è possibile consultare la pagina ufficiale Microsoft.

ExpressRoute Monitor

Utilizzando ExpressRoute Monitor è possibile effettuare il monitor della connettività end-to-end e verificare le performance tra l’ambiente on-premises ed Azure, in presenza di connettività ExpressRoute con connessioni Azure Private peering e Microsoft peering. Le funzionalità chiave di questa soluzione sono:

  • Auto-detection dei circuit ExpressRoute associati alla propria subscription Azure.
  • Detection della topologia di rete.
  • Capacity planning e analisi dell’utilizzo di banda.
  • Monitoring e alerting sia per il primary che per il secondary path dei circuit ExpressRoute.
  • Monitoring sulla connettività verso i servizi Azure come Office 365, Dynamics 365 che utilizzano ExpressRoute come connettività.
  • Rilevamento di eventuali degradi della connettività verso le varie virtual network.

Figura 2 – Topology view di una VM su Azure (sinistra) connessa a una VM on-prem (destra), tramite connessione ExpressRoute

Figura 3 – Trend sull’utilizzo della banda e sulla latenza riscontrata sul circuit ExpressRoute

Dove installare gli agenti

Per poter utilizzare ExpressRoute Monitor è necessario installare almeno un agente di Operations Management Suite su un sistema che risiede sulla virtual network di Azure e almeno un agente su una macchina attestata sulla sottorete nell’ambiente on-premises, connessa tramite private peering di ExpressRoute.

Costo della soluzione

Il costo della soluzione ExpressRoute Monitor è calcolato in base al volume dei dati generato durante le operazioni di monitoring. Per maggiori dettagli è possibile consultare la sezione dedicata nella pagina dei costi di NPM.

Service Endpoint Monitor

Utilizzando questa soluzione si ha la possibilità di monitorare e testare la raggiungibilità dei propri servizi e delle proprie applicazioni, pressoché in tempo reale, simulando gli accessi degli utenti. Si ha inoltre la possibilità di rilevare problemi nelle prestazioni lato network e di individuare il segmento di rete problematico.

Si riportano le funzionalità principali della soluzione:

  • Effettua il monitor end-to-end delle connessioni di rete verso le proprie applicazioni. Il monitor può essere fatto di qualsiasi endpoint “TCP-capable” (HTTP, HTTPS, TCP, e ICMP), come websites, applicazioni SaaS, applicazioni PaaS, e database SQL.
  • Correla la disponibilità delle applicazioni con le performance della network, per localizzare con precisione il punto di degrado sulla rete, partendo dalla richiesta dell’utente fino al raggiungimento dell’applicativo.
  • Testa la raggiungibilità delle applicazioni da differenti location geografiche.
  • Determina le latenze di rete e i pacchetti persi per raggiungere le proprie applicazioni.
  • Rileva hot spots sulla rete che possono causare problemi di performance.
  • Effettua il monitor della raggiungibilità di applicazioni Office 365, tramite test built-in specifici per Microsoft Office 365, Dynamics 365, Skype for Business e altri servizi Microsoft.

Figura 4 – Creazione di un Service Connectivity Monitor test

Figura 5 – Diagramma che mostra la topology di rete, generata da diversi nodi, per raggiungere un Service Endpoint

Dove installare gli agenti

Per utilizzare Service Endpoint Monitor è necessario installare l’agente di Operations Management Suite su ogni nodo da cui si vuole monitorare la connettività di rete verso uno specifico service endpoint.

Costo della soluzione

Il costo per l’utilizzo di Service Endpoint Monitor è basato su questi due elementi:

  • Numero delle connessioni, dove la connessione è intesa come test di raggiungibilità di un singolo endpoint, da un singolo agente, per l’intero mese. A questo proposito è possibile consultare la sezione Connection Monitoring nella pagina dei costi.
  • Volume di dati generato dall’attività di monitor. Il costo lo si ricava dalla pagina dei costi di Log Analytics, nella sezione Data Ingestion.

Traffic Analytics

Traffic Analytics è una soluzione totalmente cloud-based, che consente di avere una visibilità complessiva sulle attività di rete che vengono intraprese nell’ambiente cloud. 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.

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.
  • Analisi delle capacità dei gateway VPN o di altri servizi, per rilevare problemi generati da over-provisioning o sottoutilizzo.

Figura 6 – Traffic Analytics overview

Figura 7 – Map delle Region Azure attive sulla subscription

DNS Analytics

La soluzione DNS Analytics è in grado di collezionare, analizzare e correlare i log del servizio DNS e mette a disposizione degli amministratori le seguenti funzionalità:

  • Indentifica i client che tentano di risolvere domini ritenuti malevoli.
  • Rileva i record appartenenti a risorse obsolete.
  • Mette in evidenza nomi di dominio frequentemente interrogati.
  • Mostra il carico delle richieste ricevute dai server DNS.
  • Effettua il monitor delle registrazioni dinamiche sul DNS fallite.

Figura 8 – Overview della solution DNS Analytics

Dove installare gli agenti

La soluzione richiede la presenza dell’agente di OMS oppure di Operations Manager installato su ogni server DNS che si intende monitorare.

Conclusioni

All’aumentare della complessità delle architetture network in ambienti ibridi, aumenta di conseguenza la necessità di potersi avvalere di strumenti in grado di contemplare differenti topologie di rete. Azure mette a disposizione diversi strumenti cloud based e integrati nella fabric, come quelli descritti in questo articolo, che consentono di monitorare in modo completo ed efficace il networking di questi ambienti. Ricordo 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.

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.

La gestione di Log Analytics dal portale Azure

Da diverso tempo Microsoft ha iniziato un processo che ha portato a far confluire nel portale Azure diverse funzionalità e impostazioni di OMS Log Analytics. Recentemente è stato ufficialmente annunciato che il portale OMS sarà deprecato, a favore del portale Azure. In questo articolo saranno esaminati gli aspetti legati a questo cambiamento e cosa è bene sapere per non farsi cogliere impreparati.

La scelta di abbandonare il portale OMS, a favore del portale Azure, è stata fatta per mettere a disposizione una user experience unica per il monitor e la gestione dei propri sistemi, indipendentemente dalla loro locazione (on-premises oppure su Azure). Grazie al portale Azure è infatti possibile esplorare e gestire tutti i servizi Azure e presto si avrà anche il controllo completo di OMS Log Analytics. L’aspettativa è che il gap attualmente presente tra i due portali venga definitivamente colmato entro la fine dell’estate e a breve Microsoft annuncerà la data per la dismissione definitiva del portale OMS.

Figura 1 – Notifiche presenti nel portale OMS

Figura 2 – Overview di Log Analytics nel portale Azure

Cosa comporta questo cambiamento?

La dismissione del portale OMS, oltre a un evidente cambio nella user experience, comporta anche un cambio nell’utilizzo di Log Analytics per gli aspetti in seguito riportati.

Gestione degli alert

Anziché utilizzare la solution di Alert management di Log Analytics è necessario utilizzare Azure Monitor che, oltre a consentire di monitorare tutte le risorse Azure borne, detiene anche l’engine di “alerting” per l’intera piattaforma cloud. Nell’articolo “L’estensione degli Alerts di Log Analytics in Azure Monitor” viene presentata la nuova gestione degli Alerts in Log Analytics e i relativi benefici introdotti da questa evoluzione.

Autorizzazioni per accedere al portale

La gestione degli accessi nel portale Azure, basata su role-based access control (RBAC), è sicuramente più flessibile e potente rispetto a quella presente nel portale OMS. Azure di default prevede questi due built-in user roles per Log Analytics:

  • Log Analytics Reader
  • Log Analytics Contributor

Per i dettagli riguardanti la gestione degli accessi di Log Analytics dal portale Azure è possibile consultare questa documentazione. A partire dal 25 giugno avrà inizio il processo di conversione automatico, durante il quale ogni utente o gruppo di security presente nel portale OMS verrà riportato nel portale Azure con il ruolo opportuno, secondo la seguente associazione:

Figura 3 – Associazione permessi portale OMS e ruoli in Azure

Mobile App

Così come per il portale OMS, anche la mobile app di OMS sarà deprecata. Al suo posto è possibile accedere al portale Azure direttamente dal browser del dispositivo mobile, in attesa di future estensioni dell’App Mobile di Azure. Per ricevere le notifiche sui dispositivi mobile, quando si generano degli alert, è possibile utilizzare gli Azure Action Groups.

Application Insights Connector

L’Application Insights Connector viene utilizzato per riportare i dati di Application Insights all’interno del workspace di Log Analytics. Questo connector non è più necessario e sarà deprecato, dal mese di Novembre di quest’anno, visto che la stessa funzionalità la si può ottenere utilizzando queries cross-resource.

Azure Network Security Group Analytics

La solution  Azure Network Security Group Analytics sarà sostituita da Traffic Analytics, accessibile solamente dal portale Azure. Per maggiori dettagli su questo nuovo strumento è possibile consultare l’articolo “Come monitora le attività di rete nel cloud Azure con Traffic Analytics”

 

Attuali mancanze nel portale Azure

Ad oggi viene imposto l’utilizzo del portale OMS, a chi utilizza le seguenti solution, in quanto non sono totalmente utilizzabili nel portale Azure:

Microsoft sta lavorando per aggiornare queste solution e renderle disponibili utilizzando il portale Azure. Per rimanere aggiornati su cambiamenti in merito è possibile fare riferimento alla pagina degli Azure Updates.

 

Considerazioni

Per la gestione di Log Analytics è consigliabile utilizzare fin da oggi il portale Azure, il quale consente di adottare nuovi strumenti, di beneficiare della migliore experience offerta, e di usufruire delle funzionalità note del portale, come le dashboards, le ricerche, e il tagging per la gestione delle risorse. Il portale OMS è destinato a breve alla dismissione definitiva, ma può essere ancora necessario utilizzarlo nel caso si debbano utilizzare le solution non ancora compatibili (sopra riportate), in attesa di un loro imminente aggiornamento che le renderà totalmente funzionanti con il portale 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.