Archivi categoria: Microsoft Azure

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

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

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

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

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

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

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

Figura 2 – Selezione delle regions

Figura 3 – Selezione dei servizi Azure

Figura 4 – Salvataggio del filtro e assegnazione del nome

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

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

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

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

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

Figura 7 – Summary della problematica

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

Figura 8 – Risorse potenzialmente impattate dalla problematica

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

Figura 9 – Elenco dei problemi riportati nella Health history

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

Figura 10 – Stato di salute delle risorse per tipologia

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

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

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

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

Figura 12 – Aggiunta di un Service Health Alert

Figura 13 – Configurazione di un Service Health Alert

Conclusioni

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

L’estensione degli Alerts di Log Analytics in Azure Monitor

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

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

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

Figura 1 – Alerts in Log Analytics

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

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

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

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

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

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

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

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

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

Figura 4 – Step 2: summary delle modifiche proposte

Figura 5 – Step 3: conferma del processo di estensione

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

Figura 6 – Notifica dell’estensione degli Alerts pianificata

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

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

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

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

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

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

Conclusioni

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

OMS e System Center: novità di Marzo 2018

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

Operations Management Suite (OMS)

Azure Automation

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

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

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

Figura 1 – Relative solution presenti in Log Analytics


Azure Backup

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

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

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

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

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

 

System Center

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

System Center Configuration Manager

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

Queste in sintesi gli ambiti impattati da questo aggiornamento:

Modern Management

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

Figura 3 –  Co-management reporting

Microsoft 365 Adoption

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

Streamlined Infrastructure

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

Improvements in Cloud Management Gateway

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

Improvements in Software Center

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

Improvements in OSD

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

Miscellaneous Improvements

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

Figura 4 –  Run Script status

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

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

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

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

System Center Updates Publisher

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

System Center Operations Manager

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

Valutazione di OMS e System Center

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

Per provare i prodotti System Center è possibile accedere all’Evaluation Center e in seguito alla registrazione è possibile avviare il periodo di trial.

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

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

Caratteristiche e principi di funzionamento

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

Figura 1 – Schema di sintesi dell’architettura

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

Figura 2 – Impostazioni firewall di Azure SQL Server

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

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

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

Come effettuare la configurazione

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

Figura 3 – Abilitazione del SQL Server Service Endpoint sulla subnet

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

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

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

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

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

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

Conclusioni

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

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

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

Principi di funzionamento della soluzione

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

Figura 1 – Data flow di Traffic Analytics

Funzionalità della soluzione

Utilizzando Traffic Analytics si possono effettuare le seguenti operazioni:

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

Come abilitare la soluzione

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

Figura 2 – Abilitazione del Network Watcher dal portale

Figura 3 – Abilitazione del Network Watcher tramite PowerShell

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

Figura 4 – Registrazione dei provider tramite PowerShell

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

Primo step di configurazione delle impostazioni dei NSG flow logs:

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

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

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

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

Figura 7 – Lista dei NSGs con le impostazioni abilitate

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

Figura 8 – Dashboard di Traffic Analytics

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

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

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

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

Conclusioni

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

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

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

A cosa serve questo strumento?

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

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

Come utilizzare lo strumento?

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

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

Profilazione e misurazione del throughput

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

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

Inoltre sono necessarie le seguenti condizioni:

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

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

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

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

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

Figura 1 – Estrapolazione lista VMs dal vCenter

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

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

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

Figura 3 – Esempio di esecuzione della profilazione

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

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

Figura 4 – Esempio di sola misurazione del throughput

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

Generazione del report

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

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

Figura 5 – Esempio del comando per la generazione del report

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

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

Figura 6 – Pagina iniziale del report generato

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

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

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

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

Conclusioni

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

Azure Backup: la protezione dei sistemi Linux in Azure

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

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

Come avviene la protezione dei sistemi Linux su Azure

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

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

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

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

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

Come abilitare il backup delle macchine virtuali Linux su Azure

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

Figura 3 – Abilitazione backup durante la creazione della VM

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

File Recovery nelle macchine Linux in Azure

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

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

Figura 4 – Avvio del processo di File recovery

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

Figura 5 – Selezione del Recovery Point e Download dello script

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

Figura 6 – Copia dello script sulla macchina Linux

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

Figura 7 – Esecuzione dello script per il File Recovery

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

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

Figura 8 – Accesso al percorso del mount point

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

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

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

Conclusioni

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

OMS e System Center: novità di Gennaio 2018

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

Operations Management Suite (OMS)

Log Analytics

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

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

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

Figura 1 – ITSM Connector dashboard della solution di Log Analytics

Agente

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

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

Azure Backup

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

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

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

Azure Site Recovery

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

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

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

Figura 4 – Azure Site Recovery dashboard

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

  1. Switch between Azure Backup and Azure Site Recovery dashboards
  2. Replicated Items
  3. Failover test success
  4. Configuration issues
  5. Error Summary
  6. Infrastructure view
  7. Recovery Plans
  8. Jobs

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

Known Issues

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

System Center

System Center Configuration Manager

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

Tra le novità introdotte in questo rilascio troviamo:

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

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

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

Valutazione di OMS e System Center

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

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

Service Map in Operations Management Suite: introduzione alla soluzione

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

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

Che cos’è Service Map ?

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

Figura 1 – Esempio di schema generato da Service Map

Attivazione della soluzione

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

Figura 2 – Aggiunta della solution Service Map

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

Figura 3 – Comunicazione dei dati verso Service Map

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

Installazione del Microsoft Dependency Agent sui sistemi Windows

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

Installazione del Microsoft Dependency Agent sui sistemi Linux

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

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

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

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

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

Note e risorse relative alla soluzione Service Map

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

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

Costi della soluzione

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

Conclusioni

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

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

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

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

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

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

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

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

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

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

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

Figura 2 – Aggiunta di una nuova Azure Active Directory Application

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

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

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

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

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

Figura 5 – Aggiunta della subscription Azure dalla console SCVMM

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

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

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

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

Conclusioni

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