Archivi categoria: Microsoft Azure

Azure IaaS and Azure Stack: announcements and updates (January 2019 – Weeks: 03 and 04)

This series of blog posts includes the most important announcements and major updates regarding Azure infrastructure as a service (IaaS) and Azure Stack, officialized by Microsoft in the last two weeks.

Azure

Azure Guest OS Family 6 (Windows Server 2019)

Azure Guest OS Family 6, based on Windows Server 2019, is now generally available. Windows Server 2019 is the operating system that bridges on-premises environments with Azure, adding layers of security while helping you modernize your applications and infrastructure.

Azure Availability Zones in East US 2

Azure Availability Zones, a high-availability solution for mission-critical applications, is generally available in East US 2.

Availability Zones are physically separate locations within an Azure region. Each Availability Zone consists of one or more datacenters equipped with independent power, cooling, and networking. With the introduction of Availability Zones, Microsoft offers a service-level agreement (SLA) of 99.99% for uptime of virtual machines.

Update rollup for Azure File Sync Agent: January 2019

An update rollup for the Azure File Sync agent was released and addresses the following issues:

Files are not tiered after upgrading the Azure File Sync agent to version 4.x.
AfsUpdater.exe is now supported on Windows Server 2019.
Miscellaneous reliability improvements for sync.

More information about this update rollup:

This update is available for Windows Server 2012 R2, Windows Server 2016 and Windows Server 2019 installations that have Azure File Sync agent version 4.0.1.0 or later installed.
The agent version of this update rollup is 4.3.0.0.
A restart may be required if files are in use during the update rollup installation.
Installation instructions are documented in KB4481059.

Azure Migrate is available in Asia and Europe

Azure Migrate now supports Asia and Europe as migration project locations. This means that you can now store your discovered metadata in Asia (Southeast Asia) and Europe (North Europe/West Europe) regions.

In addition to Asia and Europe, Azure Migrate also supports storing the metadata in United States and Azure Government geographies. Support for other Azure geographies is planned for the future.

Note that the project geography does not restrict you from planning your migration for a different target location. Azure Migrate supports more than 30 regions as assessment target locations. The project geography is only used to store the discovered VM metadata.

M-series virtual machines (VMs) are available in Australia Central region

Azure M-series VMs are available in the Australia Central region. M-series VMs offer configurations with memory from 192 GB to 3.8 TiB (4 TB) RAM and are certified for SAP HANA.

Azure Governance: introduzione alle Azure Policy

L’IT governance è quel processo attraverso il quale è possibile garantire a un’organizzazione un utilizzo efficace ed efficiente delle risorse IT, al fine di poter raggiungere i propri obiettivi. Azure Policy è un servizio disponibile nel cloud pubblico di Microsoft che è possibile utilizzare per creare, assegnare e gestire dei criteri per controllare le risorse presenti in Azure. Le Azure Policy, integrate nativamente nella piattaforma, sono un elemento chiave per la governance dell’ambiente cloud. In questo articolo vengono riportati i principi di funzionamento e le caratteristiche della soluzione.

Negli ambienti Azure si possono trovare differenti subscription sulle quali sviluppano e operano diversi gruppi di operatori. L’esigenza comune è di standardizzare, e in alcuni casi imporre, come vengono configurate le risorse nel cloud. Tutto questo viene fatto per ottenere ambienti che rispettano specifiche normative di conformità, controllare la sicurezza, i costi delle risorse e uniformare il design di differenti architetture. Questi obiettivi si possono ottenere con un approccio tradizionale, che prevede un blocco degli operatori (Dev/Ops) nell’accesso diretto alle risorse cloud (tramite portale, api oppure cli). Questo approccio tradizionale risulta però poco flessibile, in quanto implica una perdita di agilità nel controllare il deployment delle risorse. Utilizzando invece il meccanismo che viene fornito in modo nativo dalla piattaforma Azure è possibile pilotare la governance per ottenere il controllo desiderato, senza impattare sulla velocità, elemento fondamentale nelle operations dell’IT moderno.

Figura 1 – Approccio tradizionale vs cloud-native governance

In ambito Azure Policy è possibile fare quanto in seguito riportato:

Attivare policy built-in o configurarle in base alle proprie esigenze.
Effettuare in tempo reale la valutazione dei criteri presenti nelle policy e forzarne l’esecuzione.
Valutare la compliance delle policy periodicamente oppure su richiesta.
Attivare dei criteri di controllo anche sull’ambiente guest delle macchine virtuali (VM In-Guest Policy).
Applicare Policy a dei Management Group al fine di ottenere un controllo sull’intera organizzazione.
Applicare contemporaneamente più criteri e aggregare i vari stati delle policy.
Configurare scope sui quali vengono applicate delle esclusioni.
Attivare operazioni per la remediation in tempo reale, anche per risorse già esistenti.

Tutto questo si traduce nella possibilità di applicare e forzare su larga scala dei criteri di compliance e le relative azioni di remediation.

Il meccanismo di funzionamento delle Azure Policy è semplice e integrato nella piattaforma. Nel momento in cui viene fatta una richiesta di configurazione di una risorsa Azure tramite ARM, questa viene intercettata dal layer contenente il motore che effettua la valutazione delle policy. Tale engine effettua una valutazione sulla base delle policy Azure attive e stabilisce la legittimità della richiesta.

Figura 2 – Principio di funzionamento delle Azure Policy nella creazione di risorse

Lo stesso meccanismo viene poi ripetuto periodicamente oppure su specifica richiesta per valutare lo strato di compliance delle risorse esistenti.

Figura 3 – Principio di funzionamento delle Azure Policy nel controllo delle risorse

In Azure sono già presenti molte policy built-in pronte per essere applicate. Inoltre, in questo repository GitHub è possibile trovare diverse definizioni di Azure Policy, che possono essere utilizzate direttamente oppure modificate in base alle proprie esigenze. La definizione delle Azure Policy è fatta in JSON e segue una struttura ben precisa, descritta in questo documento Microsoft. Si ha inoltre la possibilità di creare delle Initiatives, che sono un insieme di più policy.

Figura 4 – Esempio di definizione di una Azure Policy

Nel momento in cui si possiede la definizione della policy desiderata, è possibile assegnarla a una subscription ed eventualmente in modo più circoscritto ad un Resource Group specifico. Si ha inoltre la possibilità di escludere determinate risorse dall’applicazione della policy.

Figura 5 – Processo di assegnazione di una Azure Policy

In seguito all’assegnazione è possibile valutare lo stato di compliance nel dettaglio e se lo si ritiene necessario applicare delle azioni di remediation.

Figura 6 – Stato di compliance

Figura 7 – Esempio di azione di remediation

Conclusioni

Grazie all’utilizzo delle Azure Policy si ha la possibilità di controllare totalmente il proprio ambiente Azure, in modo semplice ed efficace. Statistiche fornite da Microsoft citano che considerando i 100 top Azure Customers, 92 di questi utilizzano le Azure Policy per controllare il proprio ambiente. Questo perché aumentando la complessità e la quantità di servizi su Azure è indispensabile adottare degli strumenti, come Azure Policy, per avere delle politiche efficaci di governance.

Azure IaaS and Azure Stack: announcements and updates (January 2019 – Weeks: 01 and 02)

Azure

Azure Migrate is available in Azure Government and Azure Asia

Azure Migrate now supports Azure Government and Azure Asia as a migration project location. This means that you can store your discovered metadata in an Azure Government region (US Gov Virginia) and in Asia region (Southeast Asia).

General availability of Azure Data Box Disk

Azure Data Box Disk, an SSD-based solution for offline data transfer to Azure is now available in the US, EU, Canada, and Australia, with more country/regions to be added over time. Microsoft also is launching the public preview of Azure Data Box Blob Storage. When enabled, this feature will allow you to copy data to Blob Storage on Data Box using blob service REST APIs.

Azure Networking: panoramica dei servizi di protezione

Nell’era moderna del cloud computing, la tendenza è di spostare sempre più frequentemente i propri workload nel cloud pubblico e di utilizzare cloud ibridi. La sicurezza è spesso percepita come un elemento inibitore per l’utilizzo di ambienti cloud. Si può estendere il proprio datacenter nel cloud mantenendo un elevato livello di sicurezza della rete? Come garantire un accesso sicuro ai servizi presenti nel cloud e con quali strumenti? Una delle principali ragioni per utilizzare Azure, per le proprie applicazioni e i propri servizi, è proprio la possibilità di poter usufruire di un ampio set di funzionalità e di strumenti di sicurezza integrati nella platform. In questo articolo verrà fatta una panoramica dei servizi di protezione in ambito network nel mondo Azure, riportando le linee guida e gli accorgimenti utili per utilizzare al meglio le potenzialità presenti nella piattaforma, al fine di strutturare il network in Azure rispettando tutti i principi di sicurezza.

In ambito Azure Networking sono disponibili diversi servizi che consentono di abilitare la connettività verso ambienti distinti, secondo modalità differenti, di attivare la protezione della rete e di configurare il delivery delle applicazioni. Tutti questi servizi si integrano con i sistemi di monitor offerti dalla piattaforma Azure, andando a creare un ecosistema completo per l’erogazione dei servizi di rete.

Figura 1 – Azure Networking Services

Per poter configurare la protezione della rete in Azure troviamo i seguenti servizi, disponibili in modo nativo nella platform.

Network Security Group (NSG)

I Network Security Groups (NSGs) sono lo strumento principale per controllare il traffico di rete in Azure. Tramite delle regole di deny e permit è possibile filtrare le comunicazioni tra differenti workload attestati su una virtual network di Azure. Inoltre, è possibile applicare filtri sulle comunicazioni con sistemi che risiedono nell’ambiente on-premises, connesso alla VNet Azure, oppure per le comunicazioni da e verso Internet. I Network Security Groups (NSGs) possono essere applicati su una determinata subnet di una VNet Azure oppure direttamente sulle singole schede di rete delle macchine virtuali Azure. Il consiglio è di applicarli se possibile direttamente sulle subnet, per avere un controllo globale e più flessibile delle ACLs. I NSGs possono contenere regole con dei Service Tags, che consentono di raggruppare con dei nomi predefiniti delle categorie di indirizzi IP, incluse quelle assegnate a determinati servizi Azure (es. AzureMonitor, AppService, Storage, etc.).

Nelle regole dei Network Security Groups possono essere referenziati anche gli Application Security Groups (ASGs). Si tratta di gruppi che contengono schede di rete di macchine virtuali presenti su Azure. Gli ASGs consentono di raggruppare con nomi mnemonici più server, utili in particolare per workload dinamici. Gli Application Security Groups consentono inoltre di non dover più gestire nelle regole degli NSGs gli indirizzi IP delle macchine virtuali Azure, purché questi IP siano relativi a VMs attestate sulla stessa VNet.

Figura 2 – Esempio di regola di un NSG che contiene un Service Tag e un ASG

Figura 3 – Visualizzazione grafica della segregazione del traffico di rete tramite NSG

Service Endpoints

Tramite i Virtual Network (VNet) service endpoints è possibile aumentare il livello di sicurezza degli Azure Services, prevenendo accessi non autorizzati. I vNet Service Endpoints consentono di isolare maggiormente i servizi Azure, permettendo l’accesso ad essi solamente da una o più subnet definite nelle proprie Virtual Network. Questa funzionalità garantisce inoltre che tutto il traffico generato dalle proprie vNet verso i servizi Azure rimanga sempre all’interno della rete di backbone di Azure. Per ottenere i servizi supportati ed avere maggiori dettagli a riguardo è possibile consultare la documentazione Microsoft.

Figura 4 – Schema di sintesi dei Sevice Endpoints

Azure Firewall

L’Azure Firewall è un firewall, totalmente integrato nel cloud pubblico di Microsoft, 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. Azure Firewall consente anche di filtrare il traffico tra le virtual network di Azure e le reti on-premises, interagendo sia con connettività che avvengono tramite Azure VPN Gateway che con Express Route Gateway. Per maggiori dettagli a riguardo è possibile consultare l’articolo Introduzione ad Azure Firewall.

Figura 5 – Posizionamento di Azure Firewall

Web Application Firewall

La pubblicazione applicativa può essere fatta utilizzando l’Azure Application Gateway, un servizio gestito dalla piattaforma Azure, con funzionalità intrinseche di alta disponibilità e scalabilità. L’Application Gateway è un load balancer applicativo (OSI layer 7) per il traffico web, che consente di governare il traffico HTTP e HTTPS delle applicazioni (URL path, host based, round robin, session affinity, redirection). L’Application Gateway è in grado di gestire in modo centralizzato i certificati per la pubblicazione applicativa, tramite policy SSL ed effettuando SSL offload quando necessario. L’Application Gateway può avere assegnato un indirizzo IP Privato oppure un indirizzo IP Pubblico, se la ripubblicazione applicativa deve avvenire verso Internet. In particolare, in quest’ultimo caso, è consigliato attivare la funzionalità di Web Application Firewall (WAF), che consente di ottenere una protezione applicativa, basandosi su regole OWASP core rule sets. Il WAF protegge l’applicativo da vulnerabilità e da attacchi comuni, come ad esempio attacchi X-Site Scripting e SQL Injection.

Figura 6 – Schema di overview dell’Application Gateway con WAF

DDoS protection

In Azure la protezione da attacchi DDoS è disponibile in due differenti tiers: Basic oppure Standard.

La protezione Basic è abilitata di default nella piattaforma Azure, la quale effettua costantemente il monitor del traffico e applica in tempo reale delle mitigazioni agli attacchi di rete più comuni. Questo tier fornisce lo stesso livello di protezione adottato e collaudato dai servizi online di Microsoft ed è attiva per gli indirizzi IP Pubblici di Azure (Pv4 e IPv6). Non è richiesta alcun tipo di configurazione per il tier Basic.

L’Azure DDoS Protection di tipologia Standard fornisce delle funzionalità di mitigation aggiuntive rispetto al tier Basic, che sono ottimizzate in modo specifico per le risorse dislocate nelle virtual network di Azure. Le policy di protezione sono auto-configurate e vengono ottimizzate effettuando un monitoraggio specifico del traffico di rete e applicando degli algoritmi di machine learning, che consentono di profilare nel modo più opportuno e flessibile il proprio applicativo studiando il traffico generato. Nel momento in cui vengono superate le soglie impostate nella policy di DDoS, viene in automatico avviato il processo di DDoS mitigation, il quale viene sospeso nel momento in cui si scende al di sotto delle soglie di traffico stabilite. Queste policy vengono applicate a tutti gli IP pubblici Azure (IPv4) associati alle risorse presenti nelle virtual network, come: macchine virtuali, Azure Load Balancer, Azure Application Gateway, Azure Firewall, VPN Gateway e istanze Azure Service Fabric.

Per maggiori dettagli a riguardo è possibile consultare l’articolo La protezione da attacchi DDoS in Azure.

Sinergie e raccomandazioni per l’utilizzo dei vari servizi di protezione

Al fine di ottenere una protezione di rete efficace ed indirizzarvi nell’utilizzo dei vari componenti si riportano le principali raccomandazioni che è consigliato tenere in considerazione:

I Network Security Groups (NSGs) e l’Azure Firewall sono tra di loro complementari e utilizzandoli in modo congiunto si ottiene un grado di difesa elevato. I NSGs è consigliato utilizzarli per filtrare il traffico tra le risorse che risiedono all’interno di una VNet, mentre l’Azure Firewall è utile per fornire una protezione di rete e applicativa tra differenti Virtual Network.
Per aumentare la sicurezza dei servizi Azure PaaS è consigliato utilizzare i Service endpoints, i quali possono essere utilizzati in concomitanza ad Azure Firewall per consolidare e centralizzare i log degli accessi. Per farlo è possibile abilitare i service endpoint dalla subnet dell’Azure Firewall, disabilitandoli dalle subnet presenti nelle VNet di Spoke.
Azure Firewall fornisce un livello di protezione di rete Layer 3 per tutte le porte ed i protocolli, inoltre garantisce un livello di protezione applicativa (Layer 7) per il traffico HTTP/S in uscita. Per questa ragione nel caso si voglia effettuare una pubblicazione applicativa protetta (HTTP/S in inbound) è opportuno utilizzare il Web Application Firewall presente nell’Application Gateway, affiancandolo quindi ad Azure Firewall.
Azure Firewall può essere affiancato anche da soluzioni WAF/DDoS di terze parti.

Tutti questi servizi di protezione, opportunamente configurati in una architettura di rete di tipologia Hub-Spoke consentono di effettuare una segregazione del traffico di rete, ottenendo un elevato livello di controllo e sicurezza.

Figura 7 – Servizi di sicurezza in una architettura Hub-Spoke

Conclusioni

Azure mette a disposizione una vasta gamma di servizi che consentono di ottenere elevati livelli di sicurezza, agendo su differenti fronti. Il modello di sicurezza che si decide adottare è possibile ridimensionarlo e adattarlo in modo flessibile, in base alla tipologia dei workload applicativi da proteggere. Una strategia vincente la si può ottenere applicando un mix-and-match dei differenti servizi di sicurezza di rete, per ottenere una protezione su più livelli.

La protezione da attacchi DDoS in Azure

Un attacco informatico di tipologia denial-of-service distribuito (attacco DDoS – Distributed Denial of Service) è rivolto a far esaurire deliberatamente le risorse di un determinato sistema che eroga un servizio ai client, come ad esempio un sito web ospitato su dei web server, al punto da renderlo non più in grado di erogare il servizio a coloro che lo richiedono in modo legittimo. In questo articolo saranno riportate le caratteristiche della protezione che è possibile avere in Azure per questa tipologia di attacchi, in modo da proteggere al meglio le applicazioni presenti sul cloud e garantire la loro disponibilità a fronte di attacchi DDoS.

Gli attacchi DDoS sono sempre più diffusi e sofisticati, al punto da poter raggiungere dimensioni, in termini di larghezza di banda, sempre più importanti, che ne rendono difficoltosa la protezione e aumentano le possibilità di apportare un downtime ai servizi pubblicati, con un impatto diretto sul business aziendale.

Figura 1 – DDoS Attack Trends

Spesso questa tipologia di attacchi viene inoltre utilizzata dagli hackers per distrarre le aziende e mascherare altre tipologie di attacchi informatici (cyber Smokescreen).

Caratteristiche della soluzione

In Azure la protezione da attacchi DDoS è disponibile in due differenti tiers: Basic oppure Standard.

Figura 2 – Comparativa delle funzionalità dei tiers disponibili per la protezione DDoS

Figura 3 – Panoramica dell’Azure DDoS Protection Standard

L’Azure DDoS Protection di tipologia Standard è in grado di far fronte ai seguenti attacchi:

Volumetric attacks: l’obiettivo di questi attacchi è di inondare la rete con una quantità considerevole di traffico apparentemente legittimo (UDP floods, amplification floods, e altri spoofed-packet floods).
Protocol attacks: questi attacchi puntano a rendere inaccessibile una specifica destinazione, sfruttando un punto debole che viene individuato nel layer 3 e nel layer 4 dello stack (ad esempio SYN flood attacks e reflection attacks).
Resource (application) layer attacks: questi attacchi hanno come obiettivo i pacchetti delle Web application, al fine di interrompere la trasmissione di dati tra i sistemi. Gli attacchi di questo tipo includono: violazioni del protocollo HTTP, SQL injection, cross-site scripting e altri attacchi di livello 7. Per proteggersi da attacchi di questa tipologia non è sufficiente la protezione DDoS standard, ma è necessario utilizzarla in concomitanza con il modulo Web Application Firewall (WAF) disponibile nell’Azure Application Gateway, oppure con soluzione web application firewall di terze parti, disponibili nel marketplace di Azure.

Abilitazione della protezione DDoS Standard

La protezione DDoS Standard viene attivata a livello di virtual network ed è contemplata per tutte le risorse che risiedono al suo interno. L’attivazione dell’Azure DDoS Protection Standard richiede di creare un DDoS Protection Plan che raccoglie le virtual network con la protezione DDoS Standard attiva, cross subscription.

Figura 4 – Creazione di un DDoS Protection Plan

Il protection Plan viene creato in una determinata subscription, alla quale saranno associati i costi della soluzione.

Figura 5 – Abilitazione della protezione DDoS Standard su una Virtual Network esistente

Il tier Standard fornisce una telemetria in tempo reale che è consultabile tramite viste in Azure Monitor.

Figura 6 – Metriche DDoS disponibili in Azure Monitor

Qualsiasi metrica relativa alla protezione DDoS può essere utilizzata per generare degli alert. Utilizzando la metrica “Under DDoS attack” si può essere avvisati nel momento in cui viene rilevato un attacco DDoS e viene applicata una azione di mitigation.

La protezione DDoS Standard applica tre auto-tuned mitigation policies (TCP SYN, TCP & UDP) per ogni IP Pubblico associato a una risorsa protetta, che risiede quindi su una virtual network con il servizio DDoS standard attivo.

Figura 7 – Metriche di mitigation disponibili in Azure Monitor

Per effettuare la generazione di report, riguardanti le azioni svolte per mitigare gli attacchi DDoS, è necessario configurare le impostazioni di diagnostica.

Figura 8 – Diagnostics Settings in Azure Monitor

Figura 9 – Abilitazione diagnostica su IP Pubblico per collezionare i log DDoSMitigationReports

Nelle impostazioni di diagnostica c’è la possibilità di collezionare anche altri log relativi alle attività di mitigation e alle notifiche. Per maggiori informazioni a riguardo è possibile consultare la sezione Configure DDoS attack analytics della documentazione Microsoft. Le metriche per la protezione DDoS Standard vengono mantenute in Azure Moniotr per 30 giorni.

Figura 10 – Attack flow logs in Azure Log Analytics

Come testare l’efficacia della soluzione

Microsoft ha instaurato una partnership con BreakingPoint Cloud che, grazie a una interfaccia molto intuitiva, consente di generare del traffico, verso gli IP Pubblici di Azure, per simulare un attacco DDoS. In questo modo è possibile:

Validare l’effettiva efficacia della soluzione.
Simulare ed ottimizzare le risposte a fronte di incident relativi ad attacchi DDoS.
Documentare il livello di compliance per attacchi di questa tipologia.
Formare il network security team.

Costi della soluzione

Il tier Basic non prevede nessun costo, mentre l’abilitazione della protezione DDoS Standard prevede un prezzo mensile fisso (non trascurabile) e un addebito per i dati che vengono elaborati. Il prezzo mensile fisso include la protezione per 100 risorse, superate le quali è previsto un costo unitario aggiuntivo per ogni risorsa protetta. Per maggiori dettagli sui costi di Azure DDoS Protection Standard è possibile consultare la pagina ufficiale Microsoft.

Conclusioni

La protezione da attacchi DDoS in Azure ci consente di avere sempre attiva una protezione di base per far fronte ad attacchi di questo tipo. A seconda della criticità applicative si può valutare l’abilitazione della protezione Standard, che in concomitanza con una soluzione di web application firewall, consente di avere funzionalità complete per mitigare attacchi distribuiti di denial-of-service.

Azure IaaS and Azure Stack: announcements and updates (December 2018 – Weeks: 50 and 51)

Azure

Update rollup for Azure File Sync Agent: December 2018

An update rollup for the Azure File Sync agent was released this month which addresses the following issues:

A Stop error 0x3B or Stop error 0x1E may occur when a VSS snapshot is created.
A memory leak may occur when cloud tiering is enabled

More information about this update rollup:

This update is available for Windows Server 2012 R2, Windows Server 2016, and Windows Server 2019 installations that have Azure File Sync agent version 3.1.0.0 or a later version installed.
The agent version of this update rollup is 4.2.0.0.
A restart may be required if files are in use during the update rollup installation.
Installation instructions are documented in KB4459990.

Automate Always On availability group deployments with SQL Virtual Machine resource provider

A new automated way to configure high availability solutions for SQL Server on Azure Virtual Machines (VMs) is now available using SQL VM resource provider.

Virtual Network Service Endpoints for serverless messaging and big data

Azure Event Hubs, a highly reliable and easily scalable data streaming service, and Azure Service Bus, which provides enterprise messaging, are the new set of serverless offerings joining the growing list of Azure services that have enabled Virtual Network Service Endpoints.

Azure Stack

Azure Stack 1811 update

The 1811 update package includes fixes, improvements, and new features for Azure Stack. This update package is only for Azure Stack integrated systems. Do not apply this update package to the Azure Stack Development Kit.

Azure Monitor: introduzione al servizio di monitor delle macchine virtuali

In Azure Monitor è stato introdotto un nuovo servizio che consente di effettuare il monitor delle macchine virtuali, chiamato Azure Monitor for VMs. Questo servizio analizza i dati di performance e lo stato delle macchine virtuali, effettua il monitor dei processi installati e ne esamina le relative dipendenze. In questo articolo sono riportate le caratteristiche della soluzione ed descritta la procedura da seguire per effettuarne l’attivazione.

Caratteristiche della soluzione

Il servizio Azure Monitor for VMs è suddiviso secondo tre differenti prospettive:

Health: i componenti logici presenti a bordo delle macchine virtuali vengono valutati secondo specifici criteri pre-configurati, generando alert quando si verificano determinate condizioni. Tale funzionalità, al momento, è presente solo per sistemi che risiedono in Azure.
Performance: vengono riportati i dati principali di performance, provenienti dal sistema operativo guest.
Map: viene generata una mappa con le interconnessioni presenti tra vari componenti che risiedono su sistemi differenti.

Tale soluzione può essere utilizzata su macchine virtuali Windows e Linux, indipendentemente dall’ambiente in cui esse risiedono (Azure, on-premises oppure presso altri cloud provider).

Azure Monitor for VMs richiede la presenza di un workspace di Log Analytics. Trattandosi di una funzionalità al momento in preview, sono supportati i workspace presenti in queste regions: West Central US, East US, West Europe e Southeast Asia. L’abilitazione di un workspace di Log Analytics può avvenire secondo queste modalità:

Per individuare i sistemi operativi supportati da questa soluzione è possibile consultare la relativa documentazione ufficiale Microsoft.

Come abilitare Azure Monitor for VMs

Per abilitare la soluzione per una singola macchina virtuale, dal portale Azure, è possibile procedere accedendo alla sezione Insights della macchina virtuale:

Figura 1 – Abilitazione di Azure Monitor for VMs su una singola VM

Abilitando la soluzione su una singola macchina virtuale è possibile scegliere quale workspace Log Analytics utilizzare ed eventualmente crearne uno nuovo. Il consiglio è di precedere a priori con la creazione del workspace, in modo da potergli assegnare un nome significativo in fase di creazione. Il workspace di Log Analytics deve essere configurato come segue:

Deve aver installato le solution ServiceMap e InfrastructureInsights. L’installazione di queste solution può essere fatta tramite dei template JSON, secondo le modalità riportate in questo documento.

Figura 2 – Presenza delle solution ServiceMap e InfrastructureInsights

Deve essere configurato per collezionare i performance counters. Questa configurazione può essere fatta manualmente come descritto in questo documento, oppure tramite questo script Powershell.

Figura 3 – Raccolta dei performance counters abilitata sul workspace di Log Analytics

Azure Monitor for VMs richiede la presenza dell’agent di Log Analytics sulle macchine virtuali, inoltre la funzionalità di Map richiede l’installazione del Microsoft Dependency agent. Si tratta di un agente aggiuntivo il quale si affida all’agente di Log Analytics per la connessione al workspace.

Nel caso si voglia abilitare la soluzione per sistemi presenti in Azure è possibile attivare il Dependency agent utilizzando l’apposita extension, che ne effettua l’installazione. Per le macchine virtuali che non risiedono su Azure è necessario effettuarne l’installazione manualmente oppure tramite una soluzione che consente di automatizzare il deployment (ad esempio System Center Configuration Manager).

Per abilitare questa funzionalità in modo automatico sulle nuove macchine virtuali create in ambiente Azure ed ottenere un livello elevato di compliance si possono anche utilizzare le Azure Policy. Tramite le Azure Policy è possibile:

Effettuare il deployment dell’agente di Log Analytics e del Dependency agent.
Avere un report sullo stato di compliance
Avviare delle azioni di remediation per le VMs non compliant.

Figura 4 – Aggiunta di un Assignment

Figura 5 – Initiative definition di esempio per abilitare Azure Monitor for VMs

Figura 6 – Consultazione dello stato di compliance della Policy

Consultazione dei dati raccolti dalla soluzione

Per analizzare e identificare eventi critici del sistema operativo, rilevare prestazioni non ottimali e problematiche di rete, è possibile consultare i dati forniti dalla solution direttamente dalla singola VM oppure utilizzando Azure Monitor, nel caso si voglia avere una vista aggregata delle varie macchine virtuali. Il tutto consente di rilevare e identificare se determinati problemi sono relativi a specifiche dipendenze con altri servizi.

Figura 7 – Stato di Health di una singola macchina virtuale

Figura 8 – Performance raccolte da più VMs, consultabili da Azure Monitor

Figura 9 – Mappa delle dipendenze dei vari servizi presenti sulle VMs, consultabili da Azure Monitor

Per maggiori informazioni sull’utilizzo della funzionalità di Health è possibile consultare questa documentazione Microsoft, mentre l’articolo View Azure Monitor for VMs Map mostra come individuare e analizzare le dipendenze rilevate dalla soluzione.

Costi della soluzione

Attivando la solution Azure Monitor for VMs, i dati collezionati dalle macchine virtuali vengono inviati e mantenuti in Azure Monitor e possono dipendere da diversi fattori, come ad esempio il numero dei logical disks e delle schede di rete. I costi sono quelli relativi ad Azure Monitor, il quale prevede delle spese sulla base dei seguenti elementi:

Dati inseriti e collezionati.
Numero di criteri di health monitorati.
Alert rule create.
Notifiche inviate.

Conclusioni

Il servizio Azure Monitor for VMs consente di avere uno strumento totalmente integrato in Azure per monitorare le macchine virtuali ed ottenere un controllo completo dei sistemi, indipendentemente da dove risiedono. Questa soluzione risulta anche particolarmente utile per condurre operazioni di troubleshooting in modo semplice ed immediato. Tale servizio, nonostante sia attualmente in preview, è comunque già sufficientemente completa ed è sicuramente destinata ad arricchirsi presto con nuove funzionalità.

Azure IaaS and Azure Stack: announcements and updates (December 2018 – Weeks: 48 and 49)

Azure

Azure Dedicated Hardware Security Module (HSM)

The Microsoft Azure Dedicated Hardware Security Module (HSM) service provides cryptographic key storage in Azure and meets the most stringent customer security and compliance requirements. This service is the ideal solution for customers requiring FIPS 140-2 Level 3 validated devices with complete and exclusive control of the HSM appliance. Azure Dedicated HSM addresses a unique set of customer needs for secure key storage scenarios in Azure.

The Dedicated HSM service is available in eight Azure regions, namely East US, West US, South Central US, East US 2, Southeast Asia, East Asia, West Europe, and North Europe

Improving Azure Virtual Machine resiliency with predictive ML and live migration

Since early 2018, Azure has been using live migration in response to a variety of failure scenarios such as hardware faults, as well as regular fleet operations like rack maintenance and software/BIOS updates. The use of live migration to handle failures gracefully allowed us to reduce the impact of failures on availability by 50 percent. Using the deep fleet telemetry, Microsoft enabled machine learning (ML)-based failure predictions and tied them to automatic live migration for several hardware failure cases, including disk failures, IO latency, and CPU frequency anomalies. Azure team partnered with Microsoft Research (MSR) on building the ML models that predict failures with a high degree of accuracy before they occur. As a result, Microsoft is able to live migrate workloads off “at-risk” machines before they ever show any signs of failing. This means VMs running on Azure can be more reliable than the underlying hardware.

Update rollup for Azure File Sync Agent: December 2018

An update rollup for the Azure File Sync agent was released which addresses the following issues:

A Stop error 0x3B or Stop error 0x1E may occur when a VSS snapshot is created.
The server may become unresponsive because of a cloud-tiering memory leak.
Agent installation fails with the following error: Error 1921. Service ‘Storage Sync Agent’ (FileSyncSvc) could not be stopped. Verify that you have sufficient privileges to stop system services.
The Storage Sync Agent (FileSyncSvc) service may crash when memory usage is high.
Miscellaneous reliability improvements for cloud tiering and sync.

More information about this update rollup:

This update is available for Windows Server 2012 R2, Windows Server 2016, and Windows Server 2019 installations that have Azure File Sync agent version 3.1.0.0 or a later version installed.
The agent version of this update rollup is 4.1.0.0.
A restart may be required if files are in use during the update rollup installation.

Installation instructions are documented in KB4459988.

Virtual network service endpoints for Azure Database for MariaDB (preview)

Virtual network service endpoints for Azure Database for MariaDB are accessible in preview in all available regions. Virtual network service endpoints allow you to isolate connectivity to your logical server from only a given subnet or set of subnets within your virtual network. Traffic to Azure Database for MariaDB from the virtual network service endpoints stays within the Azure network, preferring this direct route over any specific routes that take internet traffic through virtual appliances or on-premises.

Come ridurre i costi del cloud con Microsoft Azure

L’evoluzione del data center ci porta ad avere soluzioni completamente nel cloud pubblico oppure scenari ibridi dove, la scelta di utilizzare risorse nel cloud, oltre che da fattori funzionali, deve necessariamente essere fatta tenendo in considerazione l’aspetto fondamentale dei costi. In questo articolo vengono riportate delle indicazioni che è possibile seguire per ottenere un risparmio sui costi, dati dal mantenere i propri workload applicativi in Azure.

Azure Reservations

Il costo dei vari servizi Azure è calcolato sulla base dell’utilizzo delle risorse ed è possibile effettuare una stima dei costi utilizzando lo strumento Azure pricing calculator.

Se, delle risorse in ambiente Azure, ne viene fatto un uso continuativo è possibile valutare l’attivazione delle Azure Reservations.

Le Azure Reservation consentono di ottenere una riduzione dei costi fino al 72% rispetto al prezzo pay-as-you-go, semplicemente prepagando anticipatamente per uno oppure tre anni l’utilizzo delle risorse Azure. Al momento le risorse Azure che consentono di ottenere questi sconti sono: macchine virtuali, Azure SQL Database, Azure Cosmos DB e SUSE Linux. L’acquisto di queste reservation può essere fatto direttamente dal portale Azure ed è fattibile per i clienti che dispongono delle seguenti tipologie di subscription:

Enterprise agreement: in questo ambito non sono contemplate le risorse che risiedono in subscription Dev/Test. Risulta possibile attingere all’Azure Monetary Commitment per l’acquisto delle Azure Reservation.
Pay-As-You-Go.
Cloud Solution Provider (CSP): in questo caso l’acquisto è fattibile anche dal Partner Center.

Tra le Azure reservation troviamo:

Reserved Virtual Machine Instance: la reservation contempla solamente i costi computazionali della macchina virtuale, e non copre i costi aggiuntivi dati dal software installato a bordo della VM, dal networking, oppure dall’utilizzo dello storage.
SQL Database reserved vCore: anche in questo caso sono compresi solamente i costi computazionali, mentre le licenze vengono fatturate in modo separato.
Azure Cosmos DB reserved capacity: la reservation copre il throughput effettivo della risorsa, ma non contempla i costi previsti per lo storage e per il networking.
SUSE Linux: consente di risparmiare sui costi di licenza di SUSE Linux Enterprise.

Procedura per acquistare le Azure Reservations dal portale Azure

Per acquistare delle Reservations dal portale Azure è possibile seguire la procedura in seguito riportata.

Figura 1 – Aggiunta Azure Reservation dal portale e selezione della tipologia

Figura 2 – Configurazione dei parametri richiesti per le Reserved Virtual Machine Instances

Figura 3 – Riepilogo delle Azure Reservations acquistate

Per maggiori approfondimenti in merito a come le Reservation influiscono sul calcolo dei costi Azure, è possibile consultare i seguenti documenti Microsoft:

Hybrid Benefit

Un’altra possibilità da tenere in considerazione per la riduzione dei costi Azure è l’utilizzo dell’Azure Hybrid Benefit, che consente di risparmiare fino al 40% sul costo delle macchine virtuali Windows Server che vengono implementate su Azure. Il risparmio è dato dal fatto che Microsoft consente di pagare solamente i costi di infrastruttura Azure, mentre il licensing per Windows Server viene coperto dal contratto di Software Assurance. Questo benefit è applicabile sia alla versione Standard che Datacenter ed è usufruibile per Windows Server 200 R2 o successivi.

Figura 4 – Struttura dei costi per una VM Windows

L’Azure Hybrid Benefit può essere utilizzato in concomitanza con le Azure Reserved VM Instance, consentendo di avere risparmi complessivi che possono raggiungere l’80% (nel caso di acquisto di Azure Reserved Instance per 3 anni).

Figura 5 – Percentuali di possibili risparmi adottando RIs ed Azure Hybrid Benefit

Nel caso non ci si trovi nelle condizioni per usufruire dell’Azure Hybrid Benefit, il costo della licenza di Windows Server viene calcolato in base all’utilizzo orario della macchina virtuale e secondo il numero di core configurati.

L’Azure Hybrid Benefit può essere utilizzato anche per Azure SQL Database e per i SQL Server installati su macchine virtuali Azure. Questi vantaggi facilitano la migrazione verso soluzioni nel cloud e aiutano a massimizzare gli investimenti già effettuati in termini di licenze SQL Server. Per maggiori informazioni su come è possibile utilizzare l’Azure Hybrid Benefit per SQL Server è possibile consultare le FAQ di questo documento.

I risparmi sui costi, garantiti dall’utilizzo dell’Azure Hybrid Benefits, sono stimabili utilizzando lo strumento Azure Hybrid Benefit Savings Calculator.

Recentemente Microsoft ha effettuato degli studi sui costi da sostenere per attivare Windows Server e SQL Server in ambiente cloud che evidenziano come, grazie all’utilizzo delle Azure Reservations e di Azure Hybrid Benefit, AWS risulti fino a 5 volte più costoso rispetto ad Azure. La comparativa tra i costi Azure e quelli di AWS è possibile valutarla facilmente adottando lo strumento Azure vs. AWS Cost Comparison.

Conclusioni

Azure risulta sicuramente la scelta più economicamente vantaggiosa per ospitare in particolare i workload Microsoft, potendo avere dei costi ridotti dati dai vantaggi forniti dalle Azure Reservation e dall’Azure Hybrid Benefit. Inoltre, grazie allo strumento Azure cost management, messo a disposizione in modo gratuito a tutti i clienti Azure, si ha la possibilità di monitorare ed ottimizzare le spese dei vari servizi Azure.

Azure IaaS and Azure Stack: announcements and updates (November 2018 – Weeks: 46 and 47)

Azure

Azure Network Watcher enabled by default for subscriptions that contain virtual networks

Azure Network Watcher provides tools to monitor, diagnose, view metrics, and enable or disable logs for resources in an Azure virtual network.

Network Watcher is now enabled by default for subscriptions that contain a virtual network. There is no impact to your resources or associated charge for automatically enabling Network Watcher. This will simplify and improve your network troubleshooting experience.

To learn more about Network Watcher features, or for information about how to opt out, see the product documentation. You can also get information about pricing.

Azure Availability Zones in Southeast Asia

Azure Availability Zones, a high-availability solution for mission-critical applications, is now generally available in Southeast Asia.

Availability Zones are physically separate locations within an Azure region. Each Availability Zone consists of one or more datacenters equipped with independent power, cooling, and networking. With the introduction of Availability Zones, we now offer a service-level agreement (SLA) of 99.99% for uptime of virtual machines.

Availability Zones are generally available in select regions.

Microsoft Azure is now certified to host sensitive health data in France

Microsoft Azure, Microsoft Office 365, and Microsoft Dynamics have been granted a Health Data Hosting (HDS) certification. This makes Microsoft the first major cloud provider capable of meeting the strict standards of storing and processing health data for data centers located in France, and under the new certification process that began in June 2018. This validates the very high level of safety and protection that Microsoft can offer to French healthcare entities, who will be able to rely on the Microsoft cloud to deploy the applications and health services of tomorrow. These applications and health services will also be in compliance with the current regulations on data protection and privacy.

Announced the Azure File Sync v4 release

Improvements and issues that are fixed:

Adds support for Windows Server 2019.
Adds a new date-based cloud tiering policy setting. This policy setting is used to specify files that should be cached if accessed in a specified number of days. To learn more, see Cloud Tiering Overview.
Fixes an issue in which cloud tiering can take up to 24 hours to tier files.
Improvement when adding a new server to an existing sync group. Files are now downloaded based on the recently Created\Modified date from other servers in the sync group.
Improves interop with antivirus and other solutions so that tiered files can now use the FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS attribute.
Fixes an issue in which servers are unable to communicate with the Storage Sync Service when app-specific proxy settings are used.
Fixes an issue in which deleting a server endpoint will no longer cause tiered files to become unusable as long as the cloud endpoint was not deleted and the server endpoint is recreated within 30 days.
Improves unattended agent installations by enabling including an answer file.
Adds support for a volume-level restore option on servers which have cloud tiering disabled.
Improves sync so that it now supports bidirectional control characters.
Adds miscellaneous performance and reliability improvements for sync and cloud tiering.

New H-series Azure VMs for HPC workloads

Two new H-series (HB and HC) Azure Virtual Machines for high-performance computing (HPC) workloads are now available in preview. These are optimized for HPC applications driven by intensive computation, such as implicit finite element analysis, reservoir simulation, and computational chemistry. More information in this blog.

Azure Stack

Azure App Service on Azure Stack 1.4 (Update 4)

Released the fourth update to Azure App Service on Azure Stack. These release notes describe the improvements and fixes in Azure App Service on Azure Stack Update 4 and any known issues.

Extension Host is coming with the next update 1811

Extension Host will be enabled by the next Azure Stack update, 1811. This capability further enhances security and simplifies network integration for Azure Stack.