Archivi categoria: Microsoft Azure

Azure Backup: come evolve la soluzione

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

Funzionalità introdotte dal nuovo stack di backup

Recovery point istantanei e miglioramenti nelle performance

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

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

Figura 1 – Fasi del job di backup

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

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

Supporto per dischi di grosse dimensioni

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

Distribuzione dei dischi durante il ripristino delle macchine virtuali

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

Il processo di Upgrade

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

Considerazione pre-Upgrade

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

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

Come effettuare l’upgrade

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

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

Figura 2 – Notifica di upgrade dello stack di backup

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

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

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

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

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

Considerazioni

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

OMS e System Center: novità di Aprile 2018

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

Operations Management Suite (OMS)

Log Analytics

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

Figura 1 – Notifica estensione alerts nel portale OMS

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

Figura 2 – Impostazione del Daily volume cap

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

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

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

Agente

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

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

Azure Backup

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

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

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

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

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

System Center

System Center Configuration Manager

Per System Center Configuration Manager è stata rilasciata la versione 1804 per il branch Technical Preview. Oltre che improvements generici nella soluzione vengono introdotte novità riguardanti l’OSD, il Software Center e l’infrastruttura di Configuration Manager. Tutte le nuove funzionalità incluse in questo update possono essere consultate nell’articolo Update 1804 for Configuration Manager Technical Preview Branch. Si ricorda che i rilasci nel Technical Preview Branch consentono di valutare in anteprima le nuove funzionalità di SCCM ed è consigliato applicare questi aggiornamenti solo in ambienti di test.

System Center Operations Manager

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

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

Non sono presenti invece aggiornamenti riguardanti Service Provider Foundation.

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

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

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

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

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

Valutazione di OMS e System Center

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

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

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

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

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

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

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

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

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

Figura 2 – Selezione delle regions

Figura 3 – Selezione dei servizi Azure

Figura 4 – Salvataggio del filtro e assegnazione del nome

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

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

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

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

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

Figura 7 – Summary della problematica

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

Figura 8 – Risorse potenzialmente impattate dalla problematica

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

Figura 9 – Elenco dei problemi riportati nella Health history

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

Figura 10 – Stato di salute delle risorse per tipologia

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

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

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

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

Figura 12 – Aggiunta di un Service Health Alert

Figura 13 – Configurazione di un Service Health Alert

Conclusioni

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

L’estensione degli Alerts di Log Analytics in Azure Monitor

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

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

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

Figura 1 – Alerts in Log Analytics

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

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

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

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

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

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

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

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

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

Figura 4 – Step 2: summary delle modifiche proposte

Figura 5 – Step 3: conferma del processo di estensione

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

Figura 6 – Notifica dell’estensione degli Alerts pianificata

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

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

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

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

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

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

Conclusioni

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

OMS e System Center: novità di Marzo 2018

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

Operations Management Suite (OMS)

Azure Automation

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

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

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

Figura 1 – Relative solution presenti in Log Analytics


Azure Backup

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

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

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

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

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

 

System Center

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

System Center Configuration Manager

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

Queste in sintesi gli ambiti impattati da questo aggiornamento:

Modern Management

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

Figura 3 –  Co-management reporting

Microsoft 365 Adoption

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

Streamlined Infrastructure

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

Improvements in Cloud Management Gateway

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

Improvements in Software Center

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

Improvements in OSD

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

Miscellaneous Improvements

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

Figura 4 –  Run Script status

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

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

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

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

System Center Updates Publisher

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

System Center Operations Manager

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

Valutazione di OMS e System Center

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

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

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

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

Caratteristiche e principi di funzionamento

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

Figura 1 – Schema di sintesi dell’architettura

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

Figura 2 – Impostazioni firewall di Azure SQL Server

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

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

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

Come effettuare la configurazione

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

Figura 3 – Abilitazione del SQL Server Service Endpoint sulla subnet

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

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

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

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

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

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

Conclusioni

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

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

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

Principi di funzionamento della soluzione

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

Figura 1 – Data flow di Traffic Analytics

Funzionalità della soluzione

Utilizzando Traffic Analytics si possono effettuare le seguenti operazioni:

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

Come abilitare la soluzione

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

Figura 2 – Abilitazione del Network Watcher dal portale

Figura 3 – Abilitazione del Network Watcher tramite PowerShell

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

Figura 4 – Registrazione dei provider tramite PowerShell

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

Primo step di configurazione delle impostazioni dei NSG flow logs:

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

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

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

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

Figura 7 – Lista dei NSGs con le impostazioni abilitate

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

Figura 8 – Dashboard di Traffic Analytics

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

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

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

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

Conclusioni

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

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

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

A cosa serve questo strumento?

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

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

Come utilizzare lo strumento?

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

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

Profilazione e misurazione del throughput

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

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

Inoltre sono necessarie le seguenti condizioni:

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

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

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

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

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

Figura 1 – Estrapolazione lista VMs dal vCenter

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

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

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

Figura 3 – Esempio di esecuzione della profilazione

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

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

Figura 4 – Esempio di sola misurazione del throughput

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

Generazione del report

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

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

Figura 5 – Esempio del comando per la generazione del report

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

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

Figura 6 – Pagina iniziale del report generato

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

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

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

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

Conclusioni

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

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.