Archivi categoria: Linux

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:

Switch between Azure Backup and Azure Site Recovery dashboards
Replicated Items
Failover test success
Configuration issues
Error Summary
Infrastructure view
Recovery Plans
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).

Creazione di un ambiente Docker in Azure tramite VM Extension

Docker è una piattaforma software che consente di creare, gestire ed eseguire applicazioni isolate in containers. Un container non è altro che una metodologia di creazione dei pacchetti software in un formato che permette di essere eseguito in modo indipendente ed isolato su un sistema operativo condiviso. I containers a differenza delle machine virtuali non comprendono un sistema operativo completo, ma solamente le librerie e le impostazioni necessarie per consentire l’esecuzione del software. Ne derivano quindi una serie di vantaggi in termini di dimensione, velocità, portabilità e gestione delle risorse.


Figura 1 – Diagramma dei Container

Nel mondo Microsoft Azure ci sono svariate possibilità di configurare ed utilizzare container Docker che vi elenco sinteticamente:

VM Extension: tramite una Extension specifica è possibile implementare Docker all’interno di una macchina virtuale.
Azure Container Service: consente di distribuire rapidamente nell’ambiente Azure un cluster Docker Swarm, DC/OS o Kubernetes pronto per la produzione. Si tratta della soluzione più completa per l’orchestrazione dei container.
Docker EE for Azure: è un template disponibile sull’Azure Marketplace, frutto della collaborazione tra Microsoft e Docker, grazie al quale è possibile fare il provisioning di un cluster Docker Enterprise Edition sfruttando l’integrazione con gli Azure VM Scale Sets, gli Azure Load Balancer e l’Azure Storage.
RancherOS: è una distribuzione Linux appositamente creata per l’esecuzione di containers Docker disponibile come template all’interno del Marketplace Azure.
Web App for Containers: viene offerta la possibilità di utilizzare containers facendone il deployment nella piattaforma gestita degli Azure App Service come Web App in esecuzione in un ambiente Linux.
Azure Container Instances (attualmente in preview): è sicuramente il metodo più semplice e rapido per eseguire un container Docker nella piattaforma Azure, senza la necessità di creare macchine virtuali, ideale in scenari che prevedono containers isolati.
Azure Service Fabric: supporta i containers sia nell’ambiente Windows che Linux. La piattaforma contiene in modo nativo il supporto per Docker Compose (attualmente in preview), consentendo di orchestrare applicazioni basate su containers nell’Azure Service Fabric.
DC/OS su Azure: si tratta di un servizio cloud gestito che mette a disposizione un ambiente per il deployment di workload in cluster utilizzando la piattaforma DC/OS (Datacenter Operating System).

Tutte queste possibilità offerte consentono, in base alle esigenze e allo scenario che si deve implementare, di scegliere la metodologia di deployment più opportuna nell’ambiente Azure per l’esecuzione dei container Docker.

In questo articolo approfondiremo la creazione di un ambiente Docker utilizzando l’apposita Virtual Machine Extension. Partendo da una macchina virtuale presente in Azure è possibile aggiungere la Docker Extension che installa e configura il daemon Docker, il client Docker e il Docker Compose.

Questa extension è supportata per le seguenti distribuzioni Linux:

Ubuntu 13 o superiore.
CentOS 7.1 o superiore.
Red Hat Enterprise Linux (RHEL) 7.1 o superiore.
CoreOS 899 o superiore.

L’aggiunta dell’extension dal portale Azure può essere fatta tramite i seguenti step. Nella sezione Extensions della macchina virtuale seleziono il pulsante Add:


Figura 2 – Aggiunta Extension alla VM dal portale Azure

Successivamente viene mostrato l’elenco delle Extension disponibili, ci si posiziona sull’Extension Docker e si preme il pulsante Create.


Figura 3 – Selezione dell’Extension Docker

Per consentire una comunicazione sicura con il sistema Docker implementato nell’ambiente Azure è necessario utilizzare dei certificati e delle chiavi rilasciati da una CA trusted. Se non si dispone di una CA per generare questi certificati è possibile seguire le indicazioni riportate nella sezione Create a CA, server and client keys with OpenSSL presente nella documentazione ufficiale di Docker.


Figura 4 – Schema di comunicazione docker tramite protocollo crittografato TLS

Il wizard di aggiunta dell’Extension richiede come prima cosa di inserire la porta di comunicazione utilizzata dell’Engine Docker (2376 è la porta di default). Inoltre è richiesto l’inserimento del certificato della CA, del certificato Server e della Server Key, tutti nel formato base64-encoded:


Figura 5 – Parametri richiesti dal wizard di aggiunta della Docker VM Extension

L’aggiunta dell’Extension Docker richiede alcuni minuti al termine dei quali sulla macchina virtuale sarà presente l’installazione dell’ultima versione stabile del Docker Engine e il daemon Docker sarà in ascolto sulla porta specificata utilizzando i certificati inseriti nel wizard.


Figura 6 – Dettagli dell’Extension Docker

Nel caso sia necessario consentire la comunicazione Docker dall’esterno della vNet su cui è attestata la macchina virtuale con Docker è necessario configurare in modo opportuno le regole nel Network Security Group utilizzato:


Figura 7 – Esempio di configurazione NSG per consentire comunicazione Docker (porta 2376)

Giunti a questo punto l’ambiente è pronto per essere utilizzato e da un client remoto posso iniziare a comunicare verso l’ambiente Docker appena configurato:


Figura 8 – Comando Docker eseguito da un client remoto per recuperare informazioni

Conclusioni

L’Azure Docker VM extension è ideale per implementare facilmente e in modo affidabile e sicuro un ambiente Docker di sviluppo oppure di produzione su una singola macchina virtuale. Microsoft Azure offre un’ampia gamma di possibilità nelle scelte di implementazione relative alla piattaforma Docker, consentendo di scegliere con molta flessibilità la soluzione più idonea per le proprie esigenze.

OMS Log Analytics: la soluzione di Update Management per sistemi Linux

Utilizzando la soluzione di Update Management di Operations Manager Suite (OMS) si ha la possibilità di gestire e controllare in modo centralizzato lo stato di aggiornamento dei sistemi in ambienti eterogenei composti sia da macchine Windows che Linux e in modo indipendente dal loro posizionamento, on-premises piuttosto che nel cloud. In questo articolo verranno approfonditi gli aspetti della solution per quanto riguarda i sistemi Linux.

La soluzione di Update Management consente di valutare rapidamente lo stato degli aggiornamenti disponibili su tutti i server con l’agente di OMS installato ed è in grado di avviare il processo di installazione degli aggiornamenti mancanti. I sistemi Linux configurati per utilizzare questa solution richiedono oltre all’agente OMS la presenza di PowerShell Desired State Configuration (DSC) per Linux e dell’Automation Hybrid Runbook Worker (installati in modo automatico).

La solution al momento supporta le seguenti distribuzioni Linux:

CentOS 6 (x86/x64) e CentOS 7 (x64).
Red Hat Enterprise 6 (x86/x64) e Red Hat Enterprise 7 (x64).
SUSE Linux Enterprise Server 11 (x86/x64) e SUSE Linux Enterprise Server 12 (x64).
Ubuntu 12.04 LTS e successive (x86/x64).

Inoltre per poter funzionare in modo corretto è necessario che il sistema Linux abbia accesso ad un update repository. A tal proposito è bene precisare che al momento non c’è la possibilità da OMS di selezionare quali aggiornamenti applicare, ma vengono proposti tutti gli aggiornamenti disponibili dall’update repository configurato sulla macchina. Per aver un maggior controllo sugli aggiornamenti da applicare si potrebbe valutare l’utilizzo di un update repository appositamente creato e personalizzato che contiene solamente gli aggiornamenti che si desidera approvare.

Nel diagramma seguente viene mostrato il flusso delle operazioni che viene svolto dalla solution per riportare verso il workspace OMS lo stato di compliance e per applicare gli aggiornamenti mancanti:

Figura 1 – Flusso delle operazioni svolte sui sistemi Linux

L’agente OMS per Linux effettua una scansione ogni 3 ore per rilevare eventuali aggiornamenti mancanti e riporta l’esito della scansione verso il workspace OMS.

Figura 2 – Dashboard OMS della soluzione di Update Management

L’operatore utilizzando la dashboard di OMS può consultare l’update assessment e definire la schedulazione per il deployment degli aggiornamenti:

Figura 3 – Gestione degli Update Deployment

Figura 4 – Dashboard OMS della soluzione di Update Management

Nella creazione dell’Update Deployment viene definito un nome, l’elenco dei sistemi da coinvolgere, che può essere fornito in modo esplicito oppure utilizzando una query di Log Analytics, e una schedulazione.

Il componente Hybrid Runbook Worker in esecuzione sui sistemi Linux controlla la presenza di finestre manutentive e la disponibilità di eventuali deployment da applicare. A tal proposito è bene specificare che abilitando la solution di Update Management ogni sistema Linux connesso al workspace OMS viene automaticamente configurato come Hybrid Runbook Worker per poter eseguire runbook creati per la distribuzione degli aggiornamenti. Inoltre ogni sistema gestito dalla solution costituisce un Hybrid Runbook Worker Group all’interno dell’Automation Account di OMS seguendo la naming convention Hostname_GUID:

Figura 5 – Hybrid Worker Groups

Nel caso ad una macchina sia associato un Update Deployment (come membro diretto oppure perché appartiene ad uno specifico gruppo di computer) su di essa viene avviato il package manager (Yum, Apt, Zypper) per l’installazione degli aggiornamenti. L’installazione degli aggiornamenti viene pilotato da OMS tramite specifici runbook all’interno di Azure Automation. Questi runbook non sono visibili in Azure Automation e non richiedono nessuna configurazione da parte dell’amministratore.

Figura 6 – Azure Automation Account utilizzato dalla solution di Update Management

Al termine dell’installazione l’agente di OMS per Linux riporta lo stato dell’Update Deployment e di compliance verso il workspace OMS.

Conclusioni

Microsoft Operations Management Suite è uno strumento consolidato che consente di gestire e monitorare ambienti eterogenei. Ancora oggi purtroppo ci si trova di fronte al dibattito sulla reale necessità di mantenere aggiornati periodicamente i sistemi Linux, ma considerando anche alcuni recenti incident di security causati da sistemi non aggiornati, è evidente che è bene disporre di una soluzione che consenta di gestire gli aggiornamenti anche per le macchine Linux. La solution di Update Management di OMS è in continua evoluzione, ma già oggi ci consente di controllare e gestire la distribuzione degli aggiornamenti anche sui sistemi Linux in modo semplice ed efficace.

Per maggiori dettagli vi invito a consultare la documentazione ufficiale Microsoft della Solution di Update Management di OMS.

Per approfondire ulteriormente questa e altre funzionalità è possibile attivare gratuitamente OMS.

OMS Log Analytics: Raccogliere i Log Custom

In alcuni scenari può sorgere l’esigenza di collezionare log provenienti da applicazioni che non utilizzano i tradizionali metodi come l’Event Log in ambiente Windows oppure Syslog per i sistemi Linux per scrivere le informazioni ed eventuali errori. Log Analytics ci consente di collezionare anche gli eventi presenti in file di testo sia su sistemi Windows che sulle diverse distribuzione Linux supportate.

Figura 1 – Il processo di raccolta dei log custom

Le nuove entry scritte nel custom log vengono collezionate da Log Analytics ogni 5 minuti. L’agente è inoltre in grado di memorizzare qual è l’ultima entry collezionata in modo tale che anche se l’agente dovesse fermarsi per un certo periodo di tempo nessun dato viene perso, ma quando torna in esecuzione riprende l’elaborazione dal punto dove si era fermato.

Per poter collezionare i file di log utilizzando Log Analytics devono essere rispettati i seguenti requisiti:

Il log deve avere una singola entry per ogni riga del file oppure ogni entry deve iniziare con un timestamp che rispetti uno dei seguenti formati:

YYYY-MM-DD HH:MM:SS
M/D/YYYY HH:MM:SS AM/PM
Mon DD,YYYY HH:MM:SS
yyMMdd HH:mm:ss
ddMMyy HH:mm:ss
MMM d hh:mm:ss
Dd/MMM/yyyy:HH:mm:ss zzz

Il file di log non deve essere configurato per essere sovrascritto con circular updates.

Definizione di un custom log

Per poter collezionare le informazioni dei custom log è necessario seguire questa semplice procedura.

Aprire il wizard dei custom Log:
1. Accedere al portale OMS
2. Settings – Data
3. Custom Logs
4. Add+

Figura 2 – Custom Log Wizard

Di default tutti i cambiamenti apportati nella sezione Custom Logs vengono inviati in automatico a tutti gli agenti OMS. Per gli agenti Linux viene inviato un file di configurazione al data collector Fluentd. Se si vuole modificare manualmente questo file sugli agenti Linux è necessario rimuovere il flag “Apply below configuration to my Linux machines”.

Effettuare l’upload e il parsing di un log di esempio:

Figura 3 – Upload di un file di log di esempio

Selezionare il metodo che deve essere utilizzato per delimitare ogni record del file. Di defalut viene proposto di delimitare il file in base alle righe. Questo metodo può essere utilizzato quando il file di log contiene una singola entry per ogni riga del file. In alternativa è possibile selezionare il Timestamp per delimitare ogni record del file di log se inizia con un timestamp in un un formato supportato. Se viene utilizzato il Timestamp per delimitare i vari record la proprietà “TimeGenerated” di ogni record memorizzato in OMS verrà popolata con la data e l’ora specificata nel file di log. Se invece viene utilizzato il metodo alternativo (New Line) la proprietà “TimeGenerated” è valorizzata con la data e l’ora di raccolta del valore da parte di Log Analytics.

Figura 4 – Parsing del log con metodo New Line

Figura 4bis – Parsing del log con metodo Timestamp

Aggiungere i path dei log da collezionare:
1. Selezionare Windows oppure Linux per specificare il formato del path opportuno
2. Specificare il path e aggiungerlo con il pulsante +
3. Ripetere il processo per ogni path da aggiungere

Figura 5 – Percorsi da dove collezionare i log

Quando si inserisce un path è possibile specificare anche un valore contente un wildcard nel nome, utile per supportare applicazioni che creano nuovi file di log ogni giorno oppure al raggiungimento di una determinata dimensione.

Assegnare un nome e una descrizione al log configurato.

Figura 6 – Nome e descrizione del custom log

Il suffisso _CL viene aggiunto di default.

Validare la configurazione effettuata.

Quando Log Analytics inizia a collezionare i custom log (può essere necessario attendere fino a 1 ora dal momento dell’attivazione per visualizzare i primi dati) è possibile consultarli dal portale OMS accedendo a Log Search. Come Type è necessario specificare il nome assegnato al custom Log (esempio Type=nginx_error_CL).

Figura 7 – Ricerca dei log

Dopo avere configurato la raccolta dei custom log (ogni entry viene salvata come RawData) è possibile effettuare il parsing di ogni record presente all’interno del log in singoli campi utilizzando la funzionalità di Custom Fields presente in Log Analytics. Questo ci consente di analizzarli e di fare ricerche in modo più efficace.

Conclusioni

Ancora una volta Log Analytics si dimostra una soluzione potente e flessibile che ci consente di collezionare dati direttamente da log custom, sia per sistemi Windows che per macchine Linux, il tutto seguendo dei semplici e intuitivi passaggi guidati. Per chi vuole approfondire questa e altre funzionalità di OMS vi ricordo che è possibile provare la soluzione OMS gratuitamente.

OMS Log Analytics: la gestione dei sistemi Linux

In un mondo IT sempre più eterogeno e in continua evoluzione è di fondamentale importanza avere uno strumento in grado di gestire architetture IT ibride e distribuite tra sistemi on-premises e cloud provider pubblici. Operations Management Suite è la soluzione Microsoft, erogata direttamente dalla cloud, in grado di gestire non solo i sistemi Windows, ma anche le principali distribuzioni Linux. Continua a leggere→