Archivi categoria: Azure Site Recovery

Azure Site Recovery: la protezione di macchine Hyper-V tramite Windows Admin Center

Tra le varie funzionalità che è possibile gestire tramite Windows Admin Center, esiste la possibilità di pilotare in modo semplice la protezione di macchine virtuali, presenti in ambiente Hyper-V, con Azure Site Recovery (ASR). In questo articolo vengono riportati gli step necessari da seguire e le possibilità offerte dall’Admin Center in questo ambito.

Windows Admin Center, conosciuto in passato anche con il nome di Project Honolulu, consente tramite una console web, di gestire la propria infrastruttura in modo centralizzato. Grazie a questo strumento Microsoft ha avviato un processo di centralizzazione in un unico portale di tutte le console di amministrazione, consentendo di gestire e configurare la propria infrastruttura con una esperienza utente moderna, semplice, integrata e sicura.

Windows Admin Center non richiede nessuna dipendenza con il cloud per poter funzionare e può esserne fatto il deploy localmente per ottenere il controllo di diversi aspetti della propria infrastruttura server locale. Oltre al componente Web Server, che consente di accedere tramite browser allo strumento, il Windows Admin Center è costituito da un componente gateway, grazie al quale è possibile gestire i server tramite Remote PowerShell e WMI over WinRM.

Figura 1 – Schema di base dell’architettura di Windows Admin Center

 

Connessione del Windows Admin Center gateway ad Azure

Windows Admin Center offre anche la possibilità di integrarsi con diversi servizi di Azure, tra i quali Azure Site Recovery. Per poter consentire al Windows Admin Center gateway di comunicare con Azure è necessario procedere con il relativo processo di registrazione, seguendo gli step in seguito documentati. La procedura guidata, al momento disponibile nella versione in preview del Windows Admin Center, effettua la creazione di una Azure AD app nella propria directory, la quale consente la comunicazione del Windows Admin Center con Azure.

Figura 2 – Avvio del processo di registrazione dalle impostazioni dell’Admin Center

Figura 3 – Generazione del codice necessario per il login

Figura 4 – Inserimento del codice nella pagina di Device Login

Figura 5 – Avvio del processo di autenticazione di Azure

Figura 6 – Conferma di avvenuto Sign-in

Figura 7 – Selezione del Tenant dove registrare l’Azure AD app

Figura 8 – Indicazioni per fornire i permessi all’Azure AD app

Figura 9 – Assegnazione dei permessi, dal portale Azure, all’app registrata

Figura 10 – Configurazione dell’integrazione con Azure completata

 

Configurazione ambiente ASR per la protezione delle VMs Hyper-V

Dopo aver configurato la connessione del Windows Admin Center con Azure è possibile, selezionando il sistema Hyper-V che detiene le macchine virtuali da replicare verso Azure, procedere con l’intera configurazione del Recovery Services vault, direttamente dalla console web del Windows Admin Center. Gli step sotto riportati documentano la semplicità di attivazione.

Figura 11 – Avvio della configurazione necessaria per la protezione delle VMs

Dall’Admin Center vengono richieste le informazioni di base per la configurazione dell’ambiente di ASR e viene fornita la possibilità di creare un nuovo Recovery Service vault oppure di selezionarne uno esistente.

Figura 12 – Configurazione dell’host Hyper-V in Azure Site Recovery

Nel form proposto dal Windows Admin Center vengono proposti solamente alcuni valori, pertanto consiglio di procedere prima alla creazione del Recovery Service vault e, nella schermata precedente, di selezionarne uno esistente, creato con tutti i parametri di configurazione a piacimento e in base alle proprie esigenze.

Questo step effettua le seguenti azioni:

  • Installa l’agente di ASR sul sistema Hyper-V oppure su tutti i nodi nel caso di un ambiente cluster.
  • Se si seleziona di creare un nuovo vault procede alla relativa creazione nella region scelta e lo posiziona in un nuovo Resource Group (assegnandogli un nome di default).
  • Effettua la registrazione del sistema Hyper-V con ASR e configura una policy di replica di default.

Figura 13 – Site Recovery Jobs generati dalla configurazione

 

Configurazione della protezione delle macchine virtuali

Completate le attività di configurazione precedentemente riportate è possibile attivare la protezione delle macchine virtuali.

Figura 14 – Attivazione del processo di protezione della VM

Figura 15 – Selezione dello storage account e avvio della protezione

Al termine del processo di replica è possibile validare il processo di replica azionando la procedura di test failover dal portale Azure.

 

Conclusioni

Poter interagire con determinati servizi di Azure direttamente da Windows Admin Center può facilitare e velocizzare l’amministrazione del proprio datacenter ibrido. Al momento le possibilità offerte di integrazione con Azure Site Recovery sono minimali e idonee per scenari non complessi. Tuttavia, Windows Admin Center è in costante evoluzione e sarà sempre di più arricchito di nuove funzionalità per poter interagire al meglio anche con i servizi Azure.

OMS e System Center: novità di Agosto 2018

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

Operations Management Suite (OMS)

Azure Log Analytics

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

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

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

 

Azure Automation

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

Figura 2 – Reboot option disponibile nell’update deployment

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

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

Agente

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

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

 

Azure Site Recovery

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

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

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

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

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

 

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

Figura 4 – Configurazione replica VM verso una subscription target differente

 

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

Azure Backup

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

System Center

System Center Configuration Manager

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

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

Figura 5 – Caratteristiche e benefici della funzionalità CMPivot

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

 

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

Figura 6 – Pulsante di creazione del Phased Deployment

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

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

 

System Center Operations Manager

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

Si segnalano inoltre le seguenti novità:

 

Valutazione di OMS e System Center

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

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

OMS e System Center: novità di Luglio 2018

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

Operations Management Suite (OMS)

Azure Log Analytics

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

Figura 1 – Overview della nuova solution Azure Data Factory Analytics

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

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

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

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

Figura 3 – Raggruppamento dei custom logs nella categoria specifica

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

Azure Backup

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

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

 

Azure Site Recovery

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

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

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

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

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

Azure Automation

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

System Center

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

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

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

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

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

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

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

System Center Configuration Manager

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

Tra le novità introdotte in questo rilascio troviamo inoltre:

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

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

System Center Operations Manager

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

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

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

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

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

Apache HTTP Server

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

MySQL Server

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

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

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

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

Valutazione di OMS e System Center

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

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

OMS e System Center: novità di Giugno 2018

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

Operations Management Suite (OMS)

Log Analytics

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

Figura 1 – Notifiche presenti nel portale OMS

Azure Backup

Azure Backup si arricchisce con una nuova importante funzionalità che consente di proteggere in modo nativo i workload SQL, in esecuzione sulle macchine virtuali IaaS che risiedono su Azure. In questo articolo vengono riportati i benefici introdotti e le caratteristiche di questa nuova funzionalità.

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

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

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

Figura 3 – La condivisione di report PowerBI di Azure Backup

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

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

Azure Site Recovery

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

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

Si segnalano questi utili riferimenti riguardanti questa soluzione:

Security e Audit

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

System Center

System Center Data Protectrion Manager

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

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

System Center Configuration Manager

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

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

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

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

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

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

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

Inoltre questa preview contiene aggiornamenti riguardanti:

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

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

System Center Operations Manager

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

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

Valutazione di OMS e System Center

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

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

OMS e System Center: novità di Maggio 2018

Rispetto a quanto siamo stati abituati a vedere nei mesi scorsi, nel mese di maggio, sono state annunciate da Microsoft un numero ridotto di novità riguardanti Operations Management Suite (OMS) e System Center. In questo articolo verranno riepilogate riportando i riferimenti necessari per effettuare ulteriori approfondimenti.

Operations Management Suite (OMS)

Log Analytics

Microsoft ha annunciato il ritiro, a partire dall’8 Giugno 2018, delle seguenti solution:

Questo significa che, a partire da questa data, non sarà più possibile aggiungerle nei workspaces di Log Analytics. Per coloro che le stanno attualmente utilizzando è opportuno tenere in considerazione che le solution continueranno a funzionare, ma verrà a mancare il relativo supporto e non saranno rilasciati nuovi aggiornamenti.

In questo articolo vengono riportate alcune importanti raccomandazioni che è opportuno seguire quando si utilizzano gli operatori “Summarize” e “Join” nelle query di Log Analytics e Application Insights. Si consiglia di adeguare la sintassi di eventuali query esistenti, che utilizzano questi operatori, per rispettare le specifiche riportate nell’articolo.

Security e Audit

Si segnala questo interessante articolo dove viene riportato come è possibile rilevare ed investigare attività anomale e potenzialmente malevole utilizzando Log Analytics ed Azure Security Center.

Azure Site Recovery

Microsoft ha annunciato che le seguenti versioni delle REST API di Azure Site Recovery saranno deprecate a partire dal 31 Luglio 2018:

  • 2014-10-27
  • 2015-02-10
  • 2015-04-10
  • 2015-06-10
  • 2015-08-10

Sarà quindi necessario utilizzare le API almeno della versione 2016-08-10 per interfacciarsi con Azure Site Recovery. Questo tipo di modifica non ha nessun impatto sul portale di Azure Site Recovery e sull’accesso alla soluzione tramite PowerShell.

System Center

System Center Orchestrator

Gli Integration Pack di Orchestrator, versione 7.3 per System Center 2016, sono stati rilasciati.
Il download può essere effettuato a questo indirizzo e include i seguenti componenti:

  • System Center 2016 Integration Pack per System Center 2016 Configuration Manager.
  • System Center 2016 Integration Pack per System Center 2016 Data Protection Manager.
  • System Center 2016 Integration Pack per System Center 2016 Operations Manager.
  • System Center 2016 Integration Pack per System Center 2016 Service Manager.
  • System Center 2016 Integration Pack per System Center 2016 Virtual Machine Manager.

Questi Integration Pack consentono di sviluppare delle automazioni, interfacciandosi direttamente anche con gli altri componenti di System Center. L’Integration Pack di System Center 2016 Operations Manager è stato rivisto per non richiedere più la presenza della console di Operations Manager per funzionare in modo corretto.

System Center Operations Manager

In seguito, si riportano gli aggiornamenti rilasciati per i Management Pack di Operations Manager:

  • Active Directory Federation Services versione 10.0.1.0
  • Active Directory Federation Services 2012 R2 versione 7.1.10100.1

System Center Service Management Automation

Service Management Automation vede il rilascio dell’Update Rollup 5. Tra le problematiche risolte troviamo:

  • Runbooks che, utilizzando cmdlets di System Center 2016 Service Manager, falliscono con l’errore “MissingMethodException”.
  • Runbooks che falliscono con l’exception “unauthorized access”.

Sono stati inoltre apportati miglioramenti nella parte di debug logging.

Per consultare l’elenco completo dei problemi risolti e i dettagli da seguire per effettuare l’aggiornamento è possibile accedere alla relativa knowledge base.

 

Valutazione di OMS e System Center

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

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

OMS e System Center: novità di Febbraio 2018

Il mese di Febbraio è stato ricco di novità e diversi sono gli aggiornamenti che hanno interessato Operations Management Suite (OMS) e System Center. In questo articolo verranno riepilogati in modo sintetico per avere una visione globale e saranno presenti i riferimenti necessari per effettuare maggiori approfondimenti a riguardo.

Operations Management Suite (OMS)

Log Analytics

Tutti coloro che utilizzano Azure ExpressRoute saranno lieti di sapere che ora è possibile effettuarne il monitor utilizzando Network Performance Monitor (NPM). Tale funzionalità è stata in preview per alcuni mesi e ora è passata nello stato di general availability. Tra le caratteristiche di questa soluzione di monitor troviamo:

  • Possibilità di visualizzare in modo interattivo, tramite la topology view di NPM, i vari componenti (network on-premises, circuit provider edge, circuit ExpressRoute, edge Microsoft, e le Azure VMs) e la latenza misurata in ogni hop. Questo consente di indentificare facilmente eventuali problemi di performance nella connettività e di individuare rapidamente il segmento problematico della comunicazione.
  • Capacità di visualizzare l’utilizzo di banda del primary e del secondary circuit ExpressRoute. Grazie al drill-down è inoltre possibile intercettare l’utilizzo di banda per ogni singola vNet connessa ai circuit ExpressRoute.
  • Possibilità di creare query e visualizzazioni personalizzate grazie al fatto che tutti i dati della soluzione sono disponibili nel repository di Log Analytics e di conseguenza è possibile utilizzare le funzionalità native di ricerca e correlazione in base alle proprie esigenze.
  • Capacità di diagnosticare problemi vari di connettività presenti nei circuit ExpressRoute.

Figura 1 – Azure ExpressRoute Monitoring

Per maggiori informazioni su come configurare il monitor di ExpressRoute con NPM è possibile consultare la documentazione ufficiale Microsoft.

Inoltre in Network Performance Monitor (NPM) è stata introdotta la funzionalità di Service Endpoint Monitor che integra nel monitor e nella visualizzazione delle performance della propria applicazione anche le performance end-to-end della network. Questa funzionalità consente di creare differenti tipologie di test (HTTP, HTTPS, TCP e ICMP), che dovranno essere effettuati da punti chiave della propria infrastruttura di rete, in modo da poter identificare in modo rapido se il problema riscontrato è legato alla network oppure è relativo all’applicativo. Grazie all’utilizzo della network topology map il problema e la sua natura è inoltre facilmente localizzabile. Si tratta di una funzionalità in public preview le cui caratteristiche sono riportate nel dettaglio in questo articolo.

Agente

Questo mese la nuova versione dell’agente OMS per sistemi Linux risolve alcuni bug e introduce anche una versione aggiornata dei componenti SCX e OMI. Per ottenere la versione aggiornata dell’agente OMS è possibile accedere alla pagina ufficiale GitHub OMS Agent for Linux Patch v1.4.4-210.

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

Azure Backup

In questo articolo viene descritto come costruire la propria soluzione di monitor in Log Analytics per Azure Backup. Tramite questa soluzione di monitor è possibile controllare i principali aspetti di Azure Backup come i job di backup e restore, backup alert e l’utilizzo dello storage in cloud. Il tutto è possibile farlo cross Recovery Service vault e cross subscription potendo trarre beneficio delle funzionalità integrate in Log Analytics, quali ad esempio l’apertura automatizzata di ticket tramite webhooks oppure grazie all’integrazione con ITSM. Si tratta di una soluzione community e ogni contribuito è ovviamente ben accetto.

Per quanto riguarda Azure Backup è stata annunciata (in general availability) la possibilità di realizzare backup consistenti a livello applicativo per le macchine virtuali Linux in esecuzione su Azure. 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 3 – Meccanismo per la realizzazione di backup application consistent in VMs Linux su Azure

Per maggiori dettagli a riguardo è possibile consultare l’annuncio ufficiale, mentre per ulteriori informazioni sulla protezione delle macchine virtuali Linux presenti in Microsoft Azure, utilizzando Azure Backup, è possibile prendere visione dell’articolo: Azure Backup: la protezione dei sistemi Linux in Azure.

In Azure Backup è stata introdotta la possibilità di proteggere in modo nativo Azure File Shares. Tale funzionalità al momento è in Public Preview e tra le caratteristiche principali troviamo:

  • Possibilità, accedendo ai Recovery Service vault, di effettuare il discovery degli storage acccount e di rilevare le file shares presenti e non protette.
  • Protezione su larga scala: c’è la possibilità di effettuare il backup di più file shares contenute in uno storage account e di applicare un policy di protezione comune.
  • Restore istantanei e granulari. La protezione è basata su file share snapshots e questo consente di effettuare in modo rapido il ripristino di file in modo selettivo.
  • Dal portale Azure è possibile esplorare i vari restore point presenti per individuare facilmente quali file ripristinare.

Figura 4 – Backup di Azure File Shares

Per maggiori informazioni a riguardo è possibile consultare l’annuncio ufficiale.

Questo mese è stato rilasciato un Mandatory Update per l’agente Microsoft Azure Recovery Services (MARS). Per tutti coloro che utilizzano Azure Backup è necessario installare quanto prima questo aggiornamento per evitare fallimenti nelle attività di backup e di recovery.

Azure Site Recovery

In Azure Site Recovery è stata resa disponibile un’attesa funzionalità, che consente di proteggere macchine virtuali aventi managed disk, nello scenario di replica tra differenti region di Azure, consentendo di avere una maggiore flessibilità per l’attivazione di scenari di Disaster Recovery con sistemi presenti in Azure.

Figura 5 – Attivazione replica di una VM con Managed Disks

System Center

Come annunciato nei mesi scorsi e come già avviene per il sistema operativo e per Configuration Manager, anche gli altri prodotti System Center, in particolare Operations Manager, Virtual Machine Manager e Data Protection Manager seguiranno un rilascio di versioni aggiornate ogni 6 mesi (semi-annual channel). Questo mese c’è stato il primo rilascio con la versione 1801 di System Center.

Figura 6 – Sintesi delle novità introdotte nella versione 1801 di System Center

Per conoscere i dettagli delle novità introdotte in questo rilascio è possibile consultare l’annuncio ufficiale. Si ricorda infine che per le release appartenenti al semi-annual channel è garantito un supporto di 18 mesi.

System Center Configuration Manager

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

Questa release introduce un numero considerevole di novità su diversi ambiti, tra i quali: OSD, Cloud Management Gateway, funzionalità di Windows 10 e Office 365, Software Center e Site Server High Availability.

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

La funzionalità definita “Updates and Recommendations”, introdotta in SCOM 2016 per i Management Pack di casa Microsoft, è utile per facilitare il processo di discovery dei MPs appropriati per effettuare il monitor dei differenti workload presenti nella propria infrastruttura e per mantenerli aggiornati. Questa funzionalità è abilitata per ben oltre 110 workload Microsoft. Microsoft ha annunciato che sta estendendo questa funzionalità anche per i MPs realizzati e offerti da terze parti. Nella release 1801 di Operations Manager sono al momento contemplati i MPs dei seguenti partner esterni:

Figura 7 – Funzionalità Updates and Recommendations con MPs dei partners

Come conseguenza del rilascio della versione 1801 di System Center sono stati resi disponibili anche i seguenti nuovi Management Pack di SCOM:

System Center Service Manager

Rilasciata una nuova versione del Service Manager Authoring Tool.

Valutazione di OMS e System Center

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

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

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.

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.

OMS e System Center: novità di Dicembre 2017

Rispetto a quanto siamo stati abituati a vedere nei mesi scorsi, durante il mese di dicembre, complice anche il periodo di festività, sono state annunciate da Microsoft un numero ridotto di novità riguardanti Operations Management Suite (OMS) e System Center. In questo articolo ne verrà fatto un riepilogo accompagnato dai riferimenti necessari per effettuare ulteriori approfondimenti.

Operations Management Suite (OMS)

Log Analytics

In Azure Monitor è stata inclusa la possibilità di visualizzare e definire alert di Log Analytics. Si tratta di una funzionalità in preview che consente di utilizzare Azure Monitor come punto centralizzato di gestione e visualizzazione degli alert.

Figura 1- Definizione di un alert di Log Analytics in Azure Monitor (preview)

Questo mese la nuova versione dell’agente OMS per sistemi Linux risolve in particolare un importante bug riguardante il package DSC (omsconfig) che a causa di un possibile hang impedisce l’invio dei dati verso il workspace OMS. In questa versione non sono state introdotte novità. Per ottenere la versione aggiornata è possibile accedere alla pagina ufficiale GitHub OMS Agent for Linux Patch v1.4.2-125.

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

Azure Automation

In Azure Monitor, all’interno degli Action Groups è stata introdotta la possibilità di definire un Azure Automation Runbook come action type. Si tratta di una ulteriore integrazione che consente di avere una efficace piattaforma di alerting in grado di intraprendere azioni non solo per workload in esecuzione su Azure, ma in modo indipendente dalla loro location.

Figura 3 – Definizione di una action basata su un Automation Runbook

Protezione e Disaster Recovery

Azure Backup ha introdotto il supporto per la protezione delle macchine virtuali Azure con dischi, managed o unmanaged, criptati utilizzando Bitlocker Encryption Key (BEK). Questa funzionalità estende le possibilità di protezione delle macchine virtuali criptate, già supportate in precedenza nello scenario Bitlocker Encryption Key (BEK) e Key Encryption Key (KEK), consentendo di avere con estrema facilità un elevato livello di sicurezza in questi scenari di protezione. Per maggiori informazioni a riguardo è possibile consultare l’annuncio ufficiale.

Figura 4 – Protezione di VM criptata utilizzando Bitlocker Encryption Key (BEK)

Microsoft ha rilasciato Azure Site Recovery Deployment Planner un utilissimo strumento che può essere utilizzato quando si ha intenzione di implementare un piano di Disaster Recovery verso Azure tramite Azure Site Recovery (ASR). ASR Deployment Planner è in grado di effettuare un assessment dettagliato dell’ambiente on-premises, mirato all’utilizzo di ASR, e fornisce gli elementi necessari da prendere in considerazione per poter contemplare in modo efficace le varie operazioni richieste dal piano di DR (replica, failover e DR-Drill delle macchine virtuali). Lo strumento funziona sia in presenza di Hyper-V che di VMware e comprende anche una stima dei costi per l’utilizzo di ASR e delle risorse Azure necessarie per la protezione delle macchine virtuali presenti on-premises. Questo strumento al momento può risultare utile anche per fare le dovute valutazioni quando si ha la necessità di affrontare veri e propri scenari di migrazione da Hyper-V verso Azure. Questo perché lo strumento Azure Migrate, pensato appositamente per valutare scenari di migrazione, consente ad oggi di effettuare l’assessment solo di ambienti VMware. Il supporto per Hyper-V in Azure Migrate verrà introdotto nei prossimi mesi. ASR Deployment Planner può essere scaricato a questo indirizzo e comprende le seguenti funzionalità:

  • Effettua una stima della banda di rete richiesta per il processo di replica iniziale (initial replication) e per la delta replication.
  • Riporta la tipologia di Storage (standard oppure premium) richiesta per ogni VM.
  • Indica il numero totale di storage account (standard e premium) necessari.
  • Per ambienti VMware, indica il numero di Configuration Server e Process Server che è necessario implementare on-premises.
  • Per ambienti Hyper-V, fornisce indicazioni sullo storage aggiuntivo necessario on-premises.
  • Per ambienti Hyper-V, indica il numero di VMs che possono essere protette in parallelo (tramite batch) e il relativo ordine da seguire al fine di attivare con successo la replica iniziale.
  • Per ambienti VMware, specifica il numero di VMs che possono essere protette in parallelo per completare la replica iniziale in un dato momento.
  • Stima il throughput raggiungibile da ASR (on-premises verso Azure).
  • Esegue un assessment, delle macchine virtuali supportate, fornendo dettagli in merito ai dischi (numero, relativa dimensione e IOPS) e alla tipologia del SO.
  • Stima i costi di DR, specifici per l’utilizzo di una determinata region Azure.

Per informazioni dettagliate sull’utilizzo del tool è possibile consultare la documentazione ufficiale relativa allo specifico scenario:

Figura 5 – Report di esempio generato da ASR Deployment Planner

System Center

System Center Configuration Manager

Rilasciata la versione 1712 per il branch Technical Preview di System Center Configuration Manager. Tra le novità introdotte in questo aggiornamento troviamo:

  • Miglioramenti nella dashboard Surface Device, che consente di visualizzare anche la versione del firmware dei dispositivi Surface, oltre che la versione del sistema operativo.
  • Miglioramenti nella dashboard Office 365 client management.
  • Installazione multipla di application accedendo al Software Center.
  • Possibilità di configurare i client per rispondere a richieste PXE senza aggiungere un ruolo distribution point (Client-based PXE).

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.

Microsoft consente di 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.

Azure Site Recovery: il disaster recovery di macchine virtuali VMware

La soluzione Azure Site Recovery (ASR) consente di proteggere sistemi fisici oppure virtuali, ospitati sia in ambiente Hyper-V che VMware, automatizzando il processo di replica verso un datacenter secondario oppure verso Microsoft Azure. Con un’unica soluzione è possibile implementare piani di Disaster Recovery per ambienti eterogenei orchestrando in modo funzionale il processo di replica e le azioni necessarie per il corretto ripristino. Grazie a questa soluzione il proprio piano di DR sarà facilmente usufruibile in qualsiasi evenienza, anche la più remota, per garantire la business continuity. Recentemente la soluzione è stata ampliata prevedendo anche la possibilità di implementare una strategia di disaster recovery per macchine virtuali in Azure, consentendo di attivare la replica tra differenti region.

In questo articolo verrà mostrato come ASR può essere utilizzato per replicare macchine virtuali in ambiente VMware verso Azure (scenario 6 della figura seguente), esaminando le caratteristiche e la procedura tecnica da seguire. Nell’immagine seguente sono riportati tutti gli scenari attualmente contemplati dalla soluzione ASR:

Figura 1 – Scenari contemplati da Azure Site Recovery

Lo scenario di replica di macchine virtuali VMware verso Azure richiede la presenza della seguente architettura:

Figura 2 – Architettura nello scenario di replica di sistemi VMware verso Azure

Per poter attivare il processo di replica è necessaria la presenza di almeno un server on-premises su cui vengono installati i seguenti ruoli:

  • Configuration Server: coordina le comunicazioni tra il mondo on-premises ed Azure, e gestisce la replica dei dati.
  • Process Server: questo ruolo di default viene installato insieme al Configuration Server, ma possono essere previsti più sistemi Process Server in base al volume di dati da replicare. Agisce come replication gateway, quindi riceve i dati di replica, ne effettua un’ottimizzazione tramite meccanismi di cache e compressione, provvede all’encryption e li invia verso lo storage in ambiente Azure. Questo ruolo ha inoltre il compito di effettuare il discovery delle macchine virtuali sui sistemi VMware.
  • Master target server: anche questo ruolo viene installato di default insieme al Configuration Server, ma per deployment con un numero elevato di sistemi possono essere previsti più server con questo ruolo. Entra in azione durante il processo di failback delle risorse da Azure gestendo i dati di replica.

Su tutte le macchine virtuali sottoposte al processo di replica è necessaria la presenza del Mobility Service, che viene installato dal Process Server. Si tratta di un agente specifico che si occupa di replicare i dati presenti nella macchina virtuale.

In seguito viene descritto il processo da seguire per effettuare il deployment dei componenti on-premises e nel mondo Azure necessari per attivare la replica delle macchine virtuali VMware verso la cloud pubblica di Microsoft.

Il componente core necessario lato Azure è il Recovery Service Vault all’interno del quale, nella sezione Site Recovery, è possibile avviare il processo di configurazione pilotato per lo scenario di protezione prescelto.

Figura 3 – Scelta dello scenario di replica di macchine virtuali VMware all’interno del Recovery Service Vault

Successivamente è necessario procedere all’installazione sulla macchina on-premises del Configuration Server seguendo gli step indicati:

Figura 4 – Step da seguire per aggiungere il Configuration Server

In questa sezione del portale Azure è possibile scaricare il Microsoft Azure Site Recovery Unified Setup e la chiave necessaria per la registrazione del server al vault. Prima di avviare il setup accertarsi che la macchina su cui si intende installare il ruolo di Configuration Server sia in grado di accedere agli URL pubblici del servizio Azure e che durante il setup sia consentito il traffico web su porta 80 necessario per effettuare il download del componente MySQL utilizzato dalla soluzione.

Avviando il setup vengono richieste le seguenti informazioni:

Figura 5 – Scelta dei ruoli da installare

Selezionare la prima opzione per l’installazione del ruolo Configuration Server e Process Server. La seconda opzione è utile nel caso si debbano installare ulteriori Process Server per consentire uno scale out del deployment.

Figura 6 – Accettazione del license agreement di MySQL Community Server

Figura 7 – Selezione della chiave necessaria per la registrazione al Site Recovery Vault

Figura 8 – Scelta della metodologia per accedere ai servizi Azure (diretta o tramite proxy)

Figura 9 – Check di verifica dei prerequisiti

Figura 10 – Impostazione delle password relative a MySQL

Figura 11 – Ulteriore check sulla presenza dei componenti necessari per proteggere VMs VMware

Figura 12 – Scelta del path di installazione

L’installazione richiede indicativamente 5 GB di spazio a disposizione, ma sono consigliati almeno 600 GB per la cache.

Figura 13 – Selezione dell’interfaccia di rete e della porta da utilizzare per il traffico di replica

Figura 14 – Summary delle scelte di installazione

Figura 15 – Setup dei diversi ruoli e componenti completato con successo

Al termine del setup viene mostrata la connection passphrase che viene utilizzata dal Configuration Server, che è bene salvare con cura.

In seguito è necessario configurare le credenziali che verranno utilizzate da Azure Site Recovery per effettuare il discovery delle macchine virtuali nell’ambiente VMware e per effettuare l’installazione del Mobility Service sulle macchine virtuali.

Figura 16 – Definizioni delle credenziali utilizzate dal servizio

Completate queste operazioni sarà possibile selezionare il Configuration Server dal portale Azure e successivamente definire i dati del sistema VMware (vCenter oppure vSphere) con cui interfacciarsi.

Figura 17 – Selezione del Configuration Server e aggiunta vCenter/vSphere host

Conclusa questa configurazione è necessario attendere alcuni minuti per consentire al Process Server di effettuare il discovery delle macchine virtuali sull’ambiente VMware specificato.

In seguito occorre definire le impostazioni relative al target della replica:

  • Su quale sottoscrizione e con quale recovery model creare i sistemi.
  • Quale storage account utilizzare per ospitare i dati replicati.
  • vNet su cui attestare i sistemi replicati.

Figura 18 – Impostazioni relative al Target della replica

Lo step successivo prevede la definizione delle policy di replica in termini di RPO (espresso in minuti), retention dei recovery point (espresso in ore) e frequenza con cui effettuare delle snapshot consistenti a livello di applicazione.

Figura 19 – Creazione della policy di replica

Al termine di questa attività viene proposto di effettuare l’analisi del proprio ambiente tramite il tool Deployment Planner (scaricabile direttamente tramite il link riportato nel portale Azure) al fine di accertarsi di avere i requisiti, le risorse network e le risorse storage sufficienti per garantire il corretto funzionamento della soluzione.

Figura 20 – Step di preparazione dell’infrastruttura completati con successo

Terminati gli step di preparazione dell’infrastruttura è possibile attivare il processo di replica:

Figura 21 – Source e Target di replica

Figura 22 – Selezione delle macchine virtuali e dei relativi dischi da replicare

In questa sezione viene anche specificato quale account il Process Server utilizzerà per effettuare l’installazione del Mobility Service su ogni macchina virtuale VMware (account configurati in precedenza come documentato nella Figura 16).

Figura 23 – Selezione della policy di replica e abilitazione facoltativa della Multi-VM consistency

Nel caso venga selezionata l’opzione “Multi-VM consistency” verrà creato un Replication Group all’interno del quale verranno inserite le VMs che si desidera replicare insieme per utilizzare recovery point condivisi. Questa opzione è consigliata solo quando è necessaria una consistenza durante il processo di Failover su più macchine virtuali che erogano lo stesso workload. Inoltre attivando questa opzione è bene tenere in considerazione che per attivare il processo di Failover dei sistemi è necessario configurare un Recovery Plan specifico e non è possibile attivare il Failover per una singola macchina virtuale.

Al termine di queste configurazioni è possibile attivare il processo di replica

Figura 24 – Attivazione del processo di replica e relativo esito

Figura 25 – Stato della replica della macchina virtuale VMware

Una delle difficoltà maggiori quando si implementa uno scenario di Disaster Recovery è avere la possibilità di testarne il funzionamento senza impattare i sistemi di produzione ed il relativo processo di replica. Altrettanto vero è che non testare in modo appropriato il processo di DR equivale quasi a non averlo. Azure Site Recovery consente di testare in modo molto semplice la procedura di Disaster Recovery per valutarne la reale efficacia:

Figura 26 – Test della procedura di Failover

Figura 27 – Esito del processo di Test Failover

Conclusioni

Poter contare su un’unica soluzione come Azure Site Recovery che consente di attivare e testare procedure per la business continuity in infrastrutture eterogenee, contemplando anche macchine virtuali in ambiente VMware, ha sicuramente numerosi vantaggi in termini di flessibilità ed efficacia. ASR consente infatti di affrontare gli ostacoli tipici che si incontrano durante la realizzazione di piani di Disaster Recovery riducendo i costi e la complessità ed aumentando i livelli di compliance. La stessa soluzione può essere inoltre utilizzata per affrontare la migrazione vera e propria dei sistemi verso Azure con un impatto minimo sull’utenza finale grazie a downtime degli applicativi vicini allo zero.