Microsoft Operations Management Suite (#MSOMS) è la risposta di Microsoft per la gestione delle operations per architetture IT ibride e distribuite tra sistemi on-premises e cloud provider pubblici.
Si tratta di un progetto estremamente ambizioso che parte da alcuni punti fermi:
- In un mondo IT sempre più eterogeno ed interconnesso uno strumento di operations deve poter gestire questa eterogeneità
- Le aziende sono interessate ai benefici portati da uno strumento di operations non alle competenze necessarie al mantenimento dello strumento stesso
- Il grado di complessità, il numero di livelli di astrazione, le differenti tecnologie coinvolte, richiedono un nuovo modo di governare le operations. Gli strumenti di operations devono adeguarsi, sfruttando tutte quelle tecnologie una volta di nicchia e ora mainstream (big data, machine learning, etc)
- La dinamicità delle release software in un’era in cui tutto è accelerato (che ci piaccia o no) impone agli strumenti per la gestione delle operations di essere pronti “Day 0” per le nuove release dei sistemi oggetto della gestione
La risposta di Microsoft a queste sfide è stata probabilmente l’unica con una possibilità di successo: progettare un sistema che possa gestire tutte le cloud (private, public, hybrid), per tutti i vendor con una presenza significativa (Amazon AWS, Microsoft Azure) e tutte le tecnologie (Hyper-V, VMWare, Windows, Linux, SQL, My SQL e Oracle, etc) erogato direttamente dalla cloud. In caso di successo si tratterà davvero della quadratura del cerchio.
#MSOMS è dunque una suite di gestione delle operations completamente erogata dalla cloud che a oggi copre i seguenti ambiti – figura 1.
Figura 1 – Pilastri OMS
Onboarding
#MSOMS è semplice da valutare, essendo completamente cloud based i prerequisiti necessari sono nulli o minimi (in base allo scenario). Il punto di accesso dell’intera soluzione è la dashboard oggi fornita da Operational Insights e il modo più semplice per iniziare è utilizzare la pagina di presentazione del servizio. Qui si verrà guidati passo passo all’apertura di un workspace Operational Insights. Per completare la valutazione di tutti i moduli sarà necessario avere un abbonamento Azure, l’offerta per la valutazione della durata di un mese è più che sufficiente per valutare #MSOMS senza spendere un euro. Per fare questo è bene scegliere la fascia di prezzo Free in fase di creazione del vault, figura 2, in questo modo si possono raccogliere 500 MB di dati ogni giorno e mantenerli in linea per 7 giorni. Ovviamente ci sono altre fasce di prezzo fino ad arrivare ad una retention massima di 1 anno. Con lo sviluppo della soluzione è probabile che questi limiti verranno ulteriormente alzati.
Figura 2 – Creazione Workspace
Considerazione importante, tutti i moduli della suite sono disponibili presso i datacenter Azure europei, i propri dati quindi risiederanno all’interno della comunità europea, rimuovendo ogni ostacolo di tipo legale all’utilizzo della soluzione. Azure ha infatti ottenuto tutte le certificazioni richieste dalla comunità europea in termini di protezione dei dati e di privacy.
Una volta attivato il workspace si hanno a disposizione tutte le funzionalità di Log Analytics e quelle ad esse connesse, come ad esempio il modulo di security. Il modo per aggiungere funzionalità al portale #MSOMS è l’aggiunta di Intelligence Pack. Gli Intelligence Pack sono una collezione di regole, dashboard, integrazioni che risolvono un problema specifico: ad esempio esiste il modulo per Automation o per Active Directory che ci permette di ricevere le best practice di configurazione.
Tutto questo è reso accessibile da un portale HTML5 e tramite App per le piattaforme mobile Windows Phone, iOS ed Android.
Operational Insights
Il componente di log analytics è al cuore della soluzione. Tutti i componenti che necessitino di un vault big data dal quale attingere i dati da analizzare e interpretare sono basati su questo. Questo ruolo è dunque trasversale a tutti gli altri e quello su cui anche la dashboard OMS è fondata.
I dati possono essere collezionati da varie fonti e molte altre, anche custom, saranno aggiunte nel futuro. Per chi ha effettutato un investimento in System Center Operations Manager (#SCOM) l’integrazione è semplice ed immediata, garantendo l’arricchimento di Operations Manager con gli elementi innovativi portati da #MSOMS. Allo stesso tempo è possibile connettere sistemi Windows e Linux senza che questi facciano parte di infrastruttura #SCOM; non solo, per sistemi ospitati su Azure la soluzione si integra con Azure Diagnostics e permette di recuperare le informazioni da questo senza installare agenti sui sistemi.
I tipi di log e di performance counters collezionabili sono configurabili all’interno del sistema in modo estremamente granulare, come mostra la figura 3.
Figura 3 – Configurazione di Log & Performance
Da notare la possibilità di includere anche log IIS e sorgenti Syslog, inoltre ogni singolo agente Linux può essere configurato per aggiungere a #MSOMS ogni tipo di log (esempio gli alert di Nagios o Zabbix).
Consolidati i log, la soluzione mette a disposizione un potente linguaggio di interrogazione che permette di estrarre e correlare i dati. Ad esempio per estrarre tutti gli eventi con ID 1234 sui sistemi dove anche l’evento 5678 è presente basta interrogare il sistema come segue:
Type:Event EventID=1234 Computer IN {Type:Event EventID=5678 | Measure Count() by Computer}
Oppure per mostrare tutti i sistemi che richiedono fix, ma per nei quali non abilitato l’automatic update:
Type=RequiredUpdate Computer IN {Type=UpdateAgent AutomaticUpdateEnabled!=Enabled | Measure count() by Computer } | Measure count() by KBID
Oppure per mostrare la media dello spazio disco disponibile nell’ultime 8 ore per i computer SQL Server:
Type=PerHourly ObjectName=“Logical Disk” CounterName=“% Free Space” InstanceName=“_Total” Computer IN {Type=SQLAssessmentRecommendation | Measure count() by Computer } TimeGenerated>NOW-8HOURS | Measure Avg(SampleValue) by Computer
Ovviamente il linguaggio di interrogazione non è per tutti, soprattutto all’inizio è necessario superare qualche ostacolo. Per ovviare a questo non solo sono presenti centinaia di interrogazioni già preparate da utilizzare così come sono o da cui imparare, ma il sistema è pensato per permettere di costruire le interrogazioni in modo interattivo, tramite un sistema di facets (o campi chiave) che consente di navigare tra i dati nelle varie dimensioni, come mostra la figura 4.
Figura 4 – Il Sistema di Facets
Estendere il Sistema
Come anticipato #MSOMS può essere esteso tramite Intelligence Pack disponibili nel catalogo della soluzione, figura 5, il quale è aggiornato ed arricchito a “cloud speed”.
Figura 5 – Intelligence Pack disponibili a Dicembre 2015
Security
Tra tutti gli Intelligence Pack mi preme sottolineare il Security and Audit, figura 6, che permette di consolidare le sorgenti relative alla sicurezza e dare risposte rispetto alle vulnerabilità o minacce in atto, oltre che permettere di eseguire analisi forensi per tracciare eventuali operazioni fraudolente. Non solo, le informazioni di questo modulo sono anche arricchite dall’esperienza maturata da Microsoft con Azure (non a caso il team che si occupa di sicurezza è il medesimo che ha realizzato l’Azure Security Center), ad esempio segnalando la presenza di attività da indirizzi IP inclusi in una blacklist mantenuta da Azure.
Per il mercato italiano questo modulo è estremamente interessante per la gestione della collezione dei logon amministrativi (196/03). Un sistema in cloud garantisce per definizione la non modificabilità dei dati una volta che questi sono stati collezionati e la collezione avviene in near realtime.
Figura 6 – Overview di Security & Audit
Monitoring
Va da sé che una naturale estensione del linguaggio di interrogazione è la possibilità di generare allarmi, potendo affidarsi su una visione complessiva basata sul Data Vault è possibile costruire un sistema di sintesi e correlazione che permetta di avere allarmi significativi e non duplicati, come mostra la figura 7.
Figura 7 – Modulo di Alerting
La funzionalità è in questo momento in preview e nel suo sviluppo è estremamente semplice. Un allarme è basato sulla valutazione dell’esito di una query, figura 8, nel momento in cui un allarme è attivato è possibile eseguire una remediation. Quest’ultima è basata sull’esecuzione di un runbook della componente Automation di #MSOMS (si veda paragrafo seguente). In questo modo la naturale evoluzione del linguaggio di interrogazione permetterà di avere allarmi sempre più precisi ed “intelligenti”.
Figura 8 – Configurazione di un Alert
Azure Automation
#MSOMS comprende un potente motore di automazione, basato su PowerShell, che permette di scrivere i propri processi di automazione (runbooks) in tre differenti modalità:
- PowerShell Scripts
- PowerShell Workflows
- Graphical
Figura 9 – Tipologia di Runbook
Il sistema è integrato con la PowerShell Gallery per rendere più semplice lo startup e l’importazione di workflow e moduli già preparati. L’estensibilità del sistema è illimitata anche grazie all’introduzione degli Hybrid Workers. In condizioni normali i runbooks vengono eseguiti su risorse in pool presenti e gestite su Azure in modo del tutto trasparente, in questa modalità raggiungere sistemi on-premises diventa impraticabile per ragioni di security e complessità di configurazione. L’hybrid worker è un pool di sistemi (minimo uno) che, installati presso i propri datacenter, permettono di eseguire runbook localmente.
L’attivazione è semplicissima: basta installare l’agente #MSOMS (Microsoft Monitoring Agent – MMA) e lanciare un comando PowerShell per la registrazione presso l’Automation account. L’hybrid worker effettua un polling verso #MSOMS e laddove siano presenti runbook da eseguire, scarica le istruzioni e le esegue localmente. In questo modo qualsiasi sistema è raggiungibile, sia esso su Azure, su Amazon Web Services (AWS), virtualizzato su Hyper-V o VMWare, presente su una cloud pubblica piuttosto che on-premises.
Attivazione
Ad oggi l’attivazione di un automation account non può avvenire dalla dashboard #MSOMS, in quanto il processo non è ancora stato completamente integrato. Occorre dunque prima attivare un nuovo account nel portale Azure scegliendo l’opportuna subscription e region Azure, figura 10, quindi nel portale #MSOMS occorre aggiungere l’intelligence pack Automation.
Figura 10 – Creazione di un Nuovo Automation Account
Disaster Recovery
Con l’aumentare della dipendenza dei processi di business dall’IT i temi legati alla business continuity si estendono anche a questi servizi. Uno dei building blocks di un piano di business continuity è il processo che permette di riattivare i servizi IT critici in una diversa location. Questo processo fa parte di una più ampia strategia di Disaster Recovery (DR). #MSOMS risponde a questa esigenza con il modulo Azure Site Recovery (ASR). ASR permette di definire il proprio workflow di ripristino orchestrando la replica dei workload e il loro avvio su locazioni alternative, definendo passaggi manuali e consentendo di inserire step di automazione (usando il modulo Automation). L’aspetto più interessante di ASR è il numero di differenti scenari attualmente disponibili, figura 11, in termini di gestione della replica:
- Da Hyper-V verso Azure
- Da System Center Virtual Machine Manager verso Azure
- Tra site locali tramite System Center Virtual Machine Manager potendo utilizzare anche sistemi di replica in hardware (se si sono effettuati investimenti in questo senso)
- Da VMware verso Azure
- Tra due site locali tramite VMware
- Da sistemi fisici verso Azure
Figura 11 – Scenari Supportati da Azure Site Recovery
Anche per ASR il meccanismo di onboarding non è ancora integrato nella dashboard #MSOMS, al momento occorre dunque creare un account nel vecchio portale Azure e quindi aggiungere l’intelligence pack Azure Site Recovery al proprio workspace #MSOMS.
Data Protection
Sebbene qualcuno a volta voglia farci credere che la cloud pubblica è gestita tramite magia nera e che quindi la protezione del dato (altrimenti chiamata backup) non sia necessaria, non c’è nulla di più falso. Se i servizi di piattaforma (PaaS) mettono a disposizione i propri meccanismi di protezione, per i sistemi in Infrastructure as a Service (IaaS) è necessario definire una strategia di protezione che, come siamo abituati, definisca il Recovery Time Objective (RTO), il Recovery Point Objective (RPO) ed il mantenimento storico delle copie di salvataggio. Questo è il ruolo di Microsoft Azure Backup (MAB).
Azure Backup permette di realizzare copie delle VM in esecuzione su Azure IaaS (si tratta del comune host based backup) e di proteggere i dati contenuti nelle VM integrandosi con i workload presenti nelle VM. Ad esempio è possibile ottenere un continuos backup di un SQL Server in esecuzione in una VM con copie continue ogni 15’, come mostra la figura 12.
Figura 12 – Protezione delle VM in Esecuzione su Azure IaaS
La funzionalità di salvataggio “workload aware” è basata sulla tecnologia System Center Data Protection Manager (#SCDPM) opportunamente modificata per adattarsi ad un ambiente cloud. Occorre attivare uno o più Microsoft Azure Backup Servers (MABS) su altrettante VM in Azure e il gioco è fatto.
Un altro scenario reso possibile da MAB è il tapeless backup per lo stoccaggio a lunga durata offsite. Per chi ha effettuato un investimento su #SCDPM è possibile integrarlo con MAB per mantenere i dati su un datacenter Azure fino a 99 anni. Con un’opportuna pianificazione è dunque possibile avere i dati caldi dai quali avviene il 99.9% dei restore on-premises su disco e i dati tenuti per fini legali e “perché non si sa mai sulla cloud”, potendo dismettere la gestione dei nastri. Come sempre la scelta non deve essere tutto o nulla, ad esempio la strategia di cui sopra è particolarmente interessante per sedi periferiche con dati di cui è necessario il backup, ma scarsamente presidiate.
Come per Automation e ASR, anche l’onboarding di MAB deve essere effettuato dal vecchio portale Azure, occorre quindi aggiungere l’intelligence pack Azure Backup al proprio workspace #MSOMS. Per il salvataggio “host based” delle VM non occorre fare altro se non “scoprire” e “proteggere” le proprie VM seguendo un semplice wizard, figura 13.
Figura 13 – MAB Policy
Per quanto riguarda la protezione “guest based” è invece necessario il deployment di un agente, questo può essere fatto singolarmente su ogni sistema, ma nel caso in cui questa funzionalità sia necessaria, è sicuramente consigliato utilizzare la soluzione server MABS che permette di gestire in modo centralizzato i singoli agenti.
Conclusioni
#MSOMS è la risposta Microsoft per la gestione delle operations di un IT che si muove sempre più rapidamente ed è sempre più eterogeneo e distribuito geograficamente. La soluzione è in grado di abbracciare sistemi tradizionali su tutto lo stack, sistemi IaaS e applicativi che sfruttano servizi PaaS. Non pretende l’esclusività, ma piuttosto si pone come una soluzione modulare in cui ognuno può scegliere cosa sfruttare e quali dati integrare, costruendo su essi per portare valore aggiunto.