Archivi categoria: Operations Management Suite

Tutto quello che c’è da sapere sui workspace di OMS Log Analytics

Per poter utilizzare Log Analytics è necessario disporre di un workspace OMS, che costituisce l’ambiente dedicato di Log Analytics all’interno del quale troviamo il repository dei dati e le differenti solution. In questo articolo verranno presi in considerazione i diversi aspetti che è bene valutare in merito ai workspace di Log Analytics.

Che cos’è un workspace?

Un workspace di Log Analytics non è altro che un contenitore in ambiente Azure all’interno del quale vengono collezionati, aggregati e analizzati i dati provenienti da fonti differenti e raccolti da Log Analytics.

Per poter creare un workspace è necessario disporre di una subscription Azure. A partire dal 26 settembre 2016 infatti tutti i workspace devono necessariamente essere collegati ad una subscription Azure al momento della creazione. Durante il processo di creazione del workspace sarà inoltre necessario assegnargli un nome, che al momento non è possibile cambiare post creazione, ed associarlo ad un Resource Group esiste oppure crearne uno specifico. Infine viene richiesto in quale location crearlo e quale modello di licensing adottare. A questo proposito si ricorda che Log Analytics può essere licenziato secondo differenti modalità che è possibile consultare a questo indirizzo.

Figura 1 – Creazione di un workspace Log Analytics

Figura 2 – Location attualmente disponibili per la creazione di un workspace

Quanti workspace è opportuno creare?

All’interno di ogni subscription Azure possono essere creati più workspace. Quando si ha la necessità di stabilire il numero appropriato di workspace da creare è opportuno prendere in considerazione i seguenti fattori:

  • Locazione geografica dei dati. Realtà aziendali geograficamente distribuite a livello globale possono avere la necessità di archiviare i dati in region specifiche per contemplare politiche aziendali di sovranità del dato e per ragioni di compliance. Un altro aspetto da tenere in considerazione può essere la presenza di altre risorse in ambiente Azure che devono riportare dati in Log Analytics. In questi scenari, per evitare addebiti causati dal trasferimento di dati in uscita, è bene mantenere, qualora possibile, le risorse e il workspace OMS nella medesima region.
  • Data Isolation. Nel caso si debbano gestire dati in Log Analytic provenienti da diversi clienti (ad esempio per quanto riguarda i Service Provider) oppure da unità organizzative distinte che per diversi motivi devono essere mantenuti isolati è opportuno creare workspace distinti.
  • Maggiore flessibilità per la fatturazione. La fatturazione avviene per workspace quindi può essere utile, per mantenere ben distinti i costi di fatturazione e averne maggiore visibilità, creare workspace separati per i differenti dipartimenti oppure per le diverse business unit aziendali.

Quando si valuta il numero di workspace di Log Analytics che è necessario creare è bene tenere in considerazione che se nel proprio ambiente è stata attivata l’integrazione tra System Center Operations Manager e OMS Log Analytics sarà possibile connettere ogni Operations Manager management group con un solo workspace. Il Microsoft Monitoring Agent può invece essere configurato direttamente per riportare i dati sia verso Operations Manager che verso diversi workspace di Log Analytics.

Figura 3 – Configurazione Microsoft Monitoring Agent per riportare dati a più workspace

Come fare query tra workspace differenti

Grazie al nuovo linguaggio introdotto nei mesi scorsi in Log Analycts è ora possibile creare delle query cross workspace al fine di analizzare e aggregare dati inclusi in workspace distinti. Questa tipologia di query è possibile eseguirla accedendo al nuovo portale Advanced Analytics.

Durante la creazione delle query, per referenziare un altro workspace è necessario utilizzare l’espressione workspace(). Maggiori dettagli a riguardo è possibile consultarli nella documentazione ufficiale Microsoft.

Figura 4 – Esempio di query cross workspace

Come migrare workspace

La migrazione di un workspace Log Analytics esistente verso un’altra subscription Azure può avvenire direttamente dal portale Azure oppure utilizzando il cmdlet powershell Move-AzureRmResource. Non esiste la possibilità di migrare i dati contenuti in un workspace verso un altro workspace Log Analytics oppure di cambiare la region dove risiedono i dati.

Figura 5 – Seleziono il cambio della subscription

Figura 6 – Migrazione di un workspace verso un’altra subscription Azure

A seconda delle solution installate potrebbe essere necessario ripetere l’installazione delle stesse post migrazione.

Conclusioni

Quando si decide adottare Log Analytics è opportuno effettuare un assessment dettagliato per stabilire il design di implementazione più opportuno, che passa in primis dagli aspetti trattati riguardanti i workspace. Determinate scelte effettuate al momento della creazione dei workspace non possono essere facilmente cambiate in seguito e per questo motivo è opportuno effettuarle in modo mirato, seguendo le best practice di implementazione, per effettuare un deployment di successo di Log Analytics.

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 Operations – Backup. 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.

L’integrazione tra Service Map e System Center Operations Manager

Service Map è una soluzione che è possibile attivare in Operations Management Suite (OMS) in grado di effettuare in automatico il discovery dei componenti applicativi, presenti sia su sistemi Windows che Linux, e di creare una mappa che riporta pressoché in tempo reale le comunicazioni presenti tra i vari servizi. Il tutto consente di visualizzare i server come sistemi tra di loro interconnessi che erogano dei servizi.

In System Center Operations Manager (SCOM) c’è la possibilità di definire delle Distributed Application per fornire una visuale complessiva dello stato di salute di un’applicazione costituita da oggetti differenti.  Le Distributed Application non forniscono delle funzionalità di monitor aggiuntive, ma si limitano a mettere in relazione lo stato di oggetti presenti nel sistema di monitor per fornire lo stato di salute globale dell’applicativo.

Grazie all’integrazione tra Service Map e System Center Operations Manager è possibile creare in automatico in SCOM i diagrammi che rappresentano le Distributed Application sulla base delle dipendenze rilevate dalla soluzione Service Map.

In questo articolo verrà esaminata la procedura da seguire per attivare questa integrazione riportandone le caratteristiche principali.

Prerequisiti

Questo tipo di integrazione è possibile nel caso siano verificati i seguenti requisiti:

  • Ambiente System Center Operations Manager 2012 R2 o successivo.
  • Workspace OMS con la soluzione Service Map abilitata.
  • Presenza di un Service Principal con accesso alla subscription Azure che contiene il workspace OMS.
  • Presenza di sistemi server gestiti da Operations Manager e che inviano dati a Service Map.

Sono supportati sia sistemi Windows che Linux, ma con una importante distinzione.

Per i sistemi Windows è possibile valutare l’utilizzo dello scenario di integrazione tra SCOM e OMS, come descritto nell’articolo Integrazione tra System Center Operations Manager e OMS Log Analytics e aggiungere semplicemente il Dependencing Agent di Service Map sui vari server.

Per i sistemi Linux invece non è possibile collezionare in modo diretto i dati degli agenti gestiti da Operations Manager in Log Analytics. Sarà quindi sempre necessaria la presenza sia dell’agente di SCOM che dell’agente di OMS. Al momento, in ambiente Linux, i due agenti condividono alcuni binari, ma si tratta di agenti distinti che possono coesistere sulla stessa macchina purché l’agente di SCOM sia almeno della versione 2012 R2. L’installazione dell’agente di OMS su un sistema Linux gestito da Operations Manager comporta l’aggiornamento dei package OMI e SCX. Si consiglia di installare sempre prima l’agente di SCOM e successivamente quello di OMS, in caso contrario è necessario modificare il file di configurazione di OMI (/etc/opt/omi/conf/omiserver.conf) aggiungendo il parametro httpsport=1270. Dopo la modifica è necessario riavviare il componente OMI Server tramite il seguente comando: sudo /opt/omi/bin/service_control restart.

Processo per attivazione l’integrazione

Il primo step richiesto è l’importazione dalla console di System Center Operations Manager dei seguenti Management Pack (al momento in Public Preview), contenuti all’interno del bundle che è possibile scarica a questo indirizzo:

  • Microsoft Service Map Application Views.
  • Microsoft System Center Service Map Internal.
  • Microsoft System Center Service Map Overrides.
  • Microsoft System Center Service Map.

Figura 1 – Avvio importazione del Management Pack

Figura 2 – Installazione del Management Pack per l’integrazione con Service Map

Dopo aver completato l’installazione del Management Pack verrà visualizzato il nuovo nodo Service Map, nel workspace Administration, all’interno della sezione Operations Management Suite. Da questo nodo è possibile avviare il wizard di configurazione dell’integrazione:

Figura 3 – Configurazione del workspace OMS dove è presente la soluzione Service Map

Allo stato attuale è possibile configurare l’integrazione con un solo workspace OMS.

Il wizard richiede di specificare un Service Principal per accedere in lettura alla subscription Azure che contiene il workspace OMS, con la soluzione Service Map attivata. Per la creazione del Service Principal è possibile seguire la procedura riportata nella documentazione ufficiale Microsoft.

Figura 4 – Parametri di connessione al workspace OMS

Sulla base dei permessi assegnati al Service Principal vengono mostrate le subscription Azure e i relativi workspace OMS associati:

Figura 5 – Selezione subscription Azure, OMS Resource Group e OMS workspace

A questo punto viene richiesto di selezionare quali gruppi di macchine presenti in Service Map si desidera sincronizzare in Operations Manager:

Figura 6 – Selezione dei Service Map Machine Group da sincronizzare in SCOM

Nella schermata successiva viene richiesto di selezionare quali server presenti in SCOM sincronizzare con le informazioni recuperate da Service Map.

Figura 7 – Selezione degli items di SCOM

A questo proposito per poter fare in modo che questa integrazione sia in grado di creare il diagramma della Distributed Application per un server, questo deve essere gestito da SCOM, da Service Map e deve essere presente all’interno del gruppo Service Map precedentemente selezionato.

In seguito viene richiesto opzionalmente di selezionare un Management Server Resource Pool per la comunicazione con OMS e se necessario un proxy server:

Figura 8 – Configurazione opzionale di un Management Server Resource Pool e di un proxy server

La registrazione richiede alcuni secondi al termine dei quali compare la schermata seguente e Operations Manager effettua la prima sincronizzazione di Service Map, prelevando i dati dal workspace OMS.

Figura 9 – Aggiunta del workspace OMS completata con successo

La sincronizzazione dei dati di Service Map avviene di default ogni 60 minuti, ma è possibile cambiare questa frequenza andando ad agire con un override sulla rule denominata Microsoft.SystemCenter.ServiceMapImport.Rule.

Risultato dell’integrazione tra Service Map e SCOM

Il risultato di questa integrazione è visibile dalla console di Operations Manager nel pannello Monitoring. Viene infatti creata una nuova folder Service Map che contiene:

  • Active Alerts: eventuali alert attivi riguardanti la comunicazione tra SCOM e Service Map.
  • Servers: lista dei server sotto monitor per i quali vengono sincronizzate le informazioni provenienti da Service Map.

Figura 10 – Server con informazioni sincronizzate da Service Map

  • Machine Group Dependency Views: viene visualizzata una Distributed Application per ogni gruppo Service Map selezionato per la sincronizzazione.

Figura 11 – Machine Group Dependency View

  • Server Dependency Views: viene mostrata una Distributed Application per ogni server per il quale vengono sincronizzate le informazioni da Service Map.

Figura 12 – Server Dependency View

 

Conclusioni

Molte realtà che hanno intenzione di utilizzare oppure che hanno già implementato la soluzione Service Map hanno anche on-premises un ambiente System Center Operations Manager (SCOM). Grazie a questa integrazione si vanno ad arricchire le informazioni contenute in SCOM consentendo di avere una visibilità completa delle applicazioni e delle dipendenze dei vari sistemi. Questo è un esempio di come è possibile utilizzare le potenzialità fornite da OMS anche in realtà con SCOM, senza dover rinunciare agli investimenti fatti sullo strumento, come ad esempio la possibile integrazione con soluzioni di IT service management (ITSM).

Service Map in Operations Management Suite: introduzione alla soluzione

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

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

Che cos’è Service Map ?

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

Figura 1 – Esempio di schema generato da Service Map

Attivazione della soluzione

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

Figura 2 – Aggiunta della solution Service Map

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

Figura 3 – Comunicazione dei dati verso Service Map

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

Installazione del Microsoft Dependency Agent sui sistemi Windows

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

Installazione del Microsoft Dependency Agent sui sistemi Linux

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

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

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

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

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

Note e risorse relative alla soluzione Service Map

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

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

Costi della soluzione

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

Conclusioni

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

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

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.

Integrazione tra System Center Operations Manager e OMS Log Analytics

Per coloro che utilizzano System Center Operations Manager (SCOM) c’è la possibilità di estendere le funzionalità del prodotto abilitando l’integrazione con Log Analytics. Questo consente di beneficiare delle potenzialità di OMS per ottenere una strategia di monitor della propria infrastruttura sempre più efficiente e completa. In questo articolo si analizzerà la procedura da seguire per abilitare questa integrazione e verrà analizzato il funzionamento dell’architettura.

Prima di abilitare questo tipo di integrazione è necessario verificare di disporre di una tra le seguenti versioni di SCOM supportate:

  • Operations Manager 2016.
  • Operations Manager 2012 R2 UR2 o superiore.
  • Operations Manager 2012 SP1 UR6 o superiore.

Inoltre è opportuno consentire il traffico in uscita, verso i servizi cloud di OMS, proveniente dagli agenti di monitor, dai Management Server e dalla console di SCOM in modo diretto oppure tramite un OMS Gateway.

Il processo di integrazione viene fatto utilizzando la console di Operations Manager secondo pochi e semplici passaggi in seguito riportati:

Figura 1 – Avvio del processo di registrazione

Figura 2 – Selezione dell’environment OMS

Figura 3 – Avvio del processo di autenticazione

Figura 4 – Selezione del workspace OMS che si intende integrare in SCOM

Figura 5 – Schermata di conferma delle impostazioni

Figura 6 – Conferma conclusiva

Al termine di questa configurazione viene stabilita la connessione verso il workspace OMS, ma nessun dato degli agenti SCOM connessi al management group di SCOM viene inviato a Log Analytics. Per fare in modo di collezionare i dati degli agenti gestiti da Operations Manager in Log Analytics è necessario procedere in modo selettivo andando a specificare i singoli computer objects oppure un gruppo che contiene i Windows computer objects. Il tutto può essere svolto direttamente dal ramo Connection nella sezione Operations Management Suite:

Figura 7 – Selezione dei computer objects da abilitare

Al termine di questa operazione nel portale OMS è possibile verificare lo stato di connessione del proprio Management Group e il numero di sistemi server connessi:

Figura 8 – Informazioni riportate nel portale OMS in seguito all’integrazione

Dalla console di SCOM è possibile verificare lo stato della connessione a OMS navigando nella sezione Operations Management Suite – Health State del workspace Monitoring:

Figura 9 – Proprietà Authentication service URI valorizzata nell’Health state del Management Server

Dopo aver stabilito la connessione tra la propria infrastruttura SCOM e il workspace OMS, il Management Server inizia a ricevere aggiornamenti della configurazione dai web service di OMS sotto forma di Management Pack, che comprendono sia i MPs base che quelli relativi alle solution che sono state abilitate. Operations Manager effettua dei controlli a intervalli regolari per verificare la presenza di aggiornamenti per questi Management Pack. Tale comportamento è governato da queste rule di SCOM:

  • SystemCenter.Advisor.MPUpdate: gestisce l’aggiornamento dei MPs base di OMS e di default viene eseguita ogni 12 ore.
  • SystemCenter.Advisor.Core.GetIntelligencePacksRule: effettua l’aggiornamento dei MPs relativi alle solution OMS abilitate nel workspace connesso e di default viene eseguita ogni cinque minuti.

Tale comportamento è possibile gestirlo andando a modificare la frequenza oppure disabilitando completamente gli aggiornamenti (parametro Enabled) configurando degli override delle rule sopra riportate.

Accedendo al workspace Administration e filtrando i Management Pack per Advisor oppure Intelligence verranno elencati i MPs scaricati e installati in base alle solution abilitate nel proprio workspace OMS:

Figura 10 – Elenco Management Pack con nome che contiene “Advisor”

Figura 11 – Elenco Management Pack con nome che contiene “Intelligence”

Figura 12 – Elenco delle Solution installate nel Workspace OMS

Come si può notare per ogni Solution OMS installata esiste il corrispondete Management Pack importato nell’infrastruttura Operations Manager.

Al termine di questa configurazione gli agenti di monitor abilitati anche alla comunicazione con il workspace OMS possono inviare i dati richiesti dalla solution direttamente al web service di OMS oppure i dati delle solution possono essere inviati direttamente dal Management Server di SCOM verso il workspace OMS connesso. Il tutto dipende dalla solution abilitata e in nessun caso queste informazioni vengono salvate all’interno dei database di Operations Manager (OperationsManager e OperationsManagerDW). In caso di perdita di connettività del Management Server con il web service di OMS i dati vengono mantenuti localmente in cache finché non viene ristabilita la comunicazione. Nel caso in cui il Management Server rimanga offline per un periodo prolungato la comunicazione verso OMS può essere ripresa da altri Management Server presenti all’interno dello stesso Managemen Group.

Figura 13 – Diagramma con le comunicazioni tra i componenti dell’infrastruttura SCOM e OMS

Al fine di controllare e regolare al meglio le connessioni internet dei sistemi monitorati e dei Management Server verso gli URL pubblici di OMS è possibile implementare un OMS Gateway:

Figura 14 – Comunicazioni tra i componenti dell’infrastruttura SCOM e OMS in presenza di un OMS Gateway

In questo modo l’unico sistema che deve essere abilitato ad accedere agli URL pubblici di Operations Management Suite è l’OMS Gateway e tutti gli altri sistemi punteranno a questa macchina. Per rendere effettiva questo tipo di configurazione è necessario, dopo aver implementato il sistema con questo ruolo, specificare nell’utilizzo del proxy server l’indirizzo IP dell’OMS Gateway con prefisso http://.

Figura 15 – Configurazione del Proxy Server utilizzato per accedere ai servizi cloud di OMS

Figura 16 – Inserimento dell’Indirizzo IP dell’OMS Gateway con prefisso http://

Nel caso si desideri abilitare solamente alcuni sistemi all’utilizzo dell’OMS Gateway è necessario andare ad agire sulla rule Advisor Proxy Setting Rule e creare un Override per l’health service object andando a popolare il parametro WebProxyAddress con l’URL dell’OMS Gateway.

Conclusioni

Microsoft Operations Management Suite (OMS) è una soluzione interamente basata sul cloud, in constante evoluzione e con nuove funzionalità che vengono aggiunte ed estese in rapida frequenza. Grazie a questa integrazione è quindi possibile affiancare la velocità e l’efficienza intrinseca in OMS nel collezionare, detenere e analizzare i dati, alle potenzialità di Operations Manager. Questo consente di continuare ad utilizzare l’infrastruttura SCOM esistente per monitorare il proprio ambiente, mantenendo eventuali integrazioni con soluzioni di IT Service Management (ITSM) e di beneficiare contemporaneamente anche delle potenzialità offerte da Microsoft Operations Management Suite (OMS).

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.

OMS e System Center: novità di Novembre 2017

Nel mese di novembre ci sono state diverse novità annunciate da Microsoft riguardanti Operations Management Suite (OMS) e System Center. In questo articolo verranno riepilogate in modo sintetico con i riferimenti necessari per poter effettuare ulteriori approfondimenti in merito.

Operations Management Suite (OMS)

Log Analytics

Come già annunciato a partire dal 30 ottobre 2017 Microsoft ha avviato il processo di upgrade dei workspace OMS non ancora aggiornati manualmente. A questo proposito è stata rilasciato questo utile documento che riporta le differenze tra un workspace OMS legacy e un workspace OMS aggiornato, con i riferimenti per ottenere maggiori dettagli.

Solutions

Coloro che utilizzano circuit ExpressRoute saranno lieti di sapere che Microsoft ha annunciato la possibilità di effettuarne il monitor tramite Network Performance Monitor (NPM). Si tratta di una funzionalità al momento in preview che consente di monitorare la connettività e le performance tra l’ambiente on-premises e le vNet in Azure in presenza di circuit ExpressRoute. Per maggiori dettagli sulle funzionalità annunciate è possibile consultare l’articolo ufficiale.

Figura 1 – Network map che mostra i dettagli della connettività ExpressRoute

Agente

Come di consueto è stata rilasciata una nuova versione dell’agente OMS per sistemi Linux che ormai da tempo avviene con cadenza mensile. In questo rilascio sono stati risolti bug riguardanti la diagnostica durante la fase di onboarding degli agenti. Non sono stare introdotte ulteriori novità. Per ottenere la versione aggiornata è possibile consultare la pagina ufficiale GitHub OMS Agent for Linux Patch v1.4.2-124.

Protezione e Disaster Recovery

Azure Backup ha sempre protetto i backup effettuati dal mondo on-premises verso Azure tramite encryption che avviene utilizzando la passphrase definita in fase di configurazione della soluzione. Per la protezione delle macchine virtuali in Azure la raccomandazione per avere maggiore sicurezza nei backup era di utilizzare VM con disk-encrypted. Ora Azure Backup utilizza Storage Service Encryption (SSE) per fare l’encryption dei backup delle macchine virtuali su Azure, consentendo di avere in modo integrato nella soluzione un meccanismo per la messa in sicurezza dei backup. Questo avverrà anche per i backup esistenti in modo automatico e tramite attività in background.

Microsoft, al fine di far maggiore chiarezza in merito al pricing ed al licensing di Azure Site Recovery, ha aggiornato le FAQ che è possibile consultare nella pagina ufficiale del pricing della soluzione.

System Center

Come già avviene per il sistema operativo e per System Center 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). L’obiettivo è di fornire rapidamente nuove funzionalità e di garantire una pronta integrazione con il mondo cloud, il che diventa fondamentale vista la velocità con cui si evolve. Nel mese di novembre è stata annunciata la preview di System Center versione 1711 che è possibile scaricare a questo indirizzo.

Figura 2 – Sintesi delle novità introdotte nella preview di System Center versione 1711

Per conoscere i dettagli delle le novità introdotte in questo rilascio è possibile consultare l’annuncio ufficiale.

System Center Configuration Manager

Per System Center Configuration Manager current branch versione 1706 è stato rilasciato un importante update rollup che è consigliabile applicare in quanto risolve un numero considerevole di problematiche.

Rilasciata la versione 1710 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 emergono sicuramente le possibilità offerte dal Co-management che ampliano le possibilità di gestione dei device utilizzando sia System Center Configuration Manager che Microsoft Intune.

Figura 3 – Caratteristiche e benefici del Co-management

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

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

  • Miglioramenti nel nuovo Run Task Sequence step.
  • User interaction in fase di installazione di applicazioni nel contesto System anche durante l’esecuzione di una task sequence.
  • Nuove opzioni, nello scenario di utilizzo di Configuration Manager connesso con Microsoft Intune, per gestire policy di compliance per device Windows 10 in relazione a Firewall, User Account Control, Windows Defender Antivirus, e OS build versioning.

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.

Rilasciata una versione aggiornata del Configuration Manager Client Messaging SDK.

System Center Operations Manager

Rilasciata la nuova wave dei Management Pack di SQL Server (versione 7.0.0.0):

I Management Pack relativi a SQL Server 2017 possono essere utilizzati per il monitor di SQL Server 2017 e di release successive (version agnostic), questo consente di evitare di dover gestire differenti MP per ogni versione di SQL Server. I controlli per le versioni di SQL Server precedenti alla 2014 sono inclusi nel MP generico “Microsoft System Center Management Pack for SQL Server”.

System Center Service Manager

Microsoft ha pubblicato una serie di accorgimenti e di best practices da seguire in fase di Authoring di Management Pack di System Center Service Manager (SCSM).

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.