Analisi di uno strumento per il monitoraggio di sistemi distribuiti

! Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Sistemi Operativi Analisi di uno strumento per il monitoraggio di sistemi distribuiti Anno Accademico 2010/2011 Candidato: Alessio Silvestro Matr. N46/247

INDICE Introduzione 1 Nagios 3 Capitolo1 Nagios core 4 1.1 Host 5 1.2 Servizi 5 1.3 Time period 6 1.4 Contatti 6 1.5 Tipi di stato 6 1.6 External command file 7 1.7 Event Handler 8 1.8 Topologia della rete 9 1.9 Check attivi e passivi 9 1.10 Elementi utili all installazione 11 1.11 Interfaccia web 11 Capitolo2 Plugin 14 2.1 Creazione di un plugin 15 Capitolo 3 Estensioni modulari 16 3.1 NRPE 16 3.2 NSCA 17 3.2.1 Sicurezza e comunicazioni cifrate 18 3.2.2 I passi della cifratura 19 3.2.3 Replay attack 19 3.3 DNX 20 3.3.1 Neb 23 Capitolo 4 Cloud Computing 25 4.1 Modelli di servizio 26 4.1.1 SaaS 26 4.1.2 PaaS 27 4.1.3 IaaS 27 4.2 OpenStack 27 4.2.1 Compute 28 4.2.2 Object Store 28 4.2.3 Image Service 28 Installazione di Nagios su OpenStack 30 Riferimenti 32

!!! Analisi di uno strumento per il monitoraggio di sistemi distribuiti INTRODUZIONE Lo sviluppo delle attuali infrastrutture informatiche e delle telecomunicazioni da un lato e le esigenze aziendali di flessibilità,decentralizzazione e cooperazione dall'altro hanno incentivato l'uso di sistemi distribuiti su rete. Sono state fornite diverse definizioni di sistemi distribuiti nessuna delle quali soddisfacente. "Un sistema distribuito è una collezione di computer indipendenti che appare ai propri utenti come un singolo sistema coerente." [ 1 ] Del tutto generale, questa definizione mette tuttavia in risalto le due caratteristiche fondamentali dei sistemi distribuiti: l'autonomia dei dispositivi e la particolare posizione dell'utente che crede di utilizzare un sistema unico.non è stata fatta alcuna considerazione sulla tipologia dei computer né sui modi in cui sono interconnessi, al fine di non intaccare la generalità della definizione. I sistemi distribuiti sono spesso logicamente organizzati come un unico strato software, middleware,interposto tra le applicazioni utente e i sistemi operativi e le funzionalità di rete sottostanti. [ 1 ] Distributed Systems: Principles and Paradigms Andrew S. Tanenbaum and Maarten van Steen Prentice Hall, 2007 Alessio Silvestro N46/247 1

Figura 1 : Sistemi distribuiti come middleware [1] Il sistema distribuito si incarica della gestione dell'intera infrastruttura come le tecniche di virtualizzazione, le modalità di comunicazione e la gestione dell'affidabilità. Si intuisce che, in riferimento a sistemi così complessi, aumenta la difficoltà nella gestione di eventi eccezionali e situazioni critiche. Nasce allora l'esigenza di disporre di strumenti dedicati per la gestione dell'affidabilità e della tolleranza ai guasti al fine di rendere il servizio efficiente e affidabile. In questo elaborato sarà analizzato uno strumento open source per il monitoraggio di sistemi distribuiti su rete.si procederà ad una breve panoramica su un sistema che ricopre oggi un ruolo fondamentale nello scenario dell informatica moderna e si presta più degli altri alla definizione di sistema distribuito : il Cloud Computing. Alessio Silvestro N46/247! 2

NAGIOS Nagios è un sistema open source per il monitoraggio di risorse e servizi su reti locali. Un sistema di monitoraggio si occupa di controllare le risorse degli host (carico della cpu, memoria utilizzata, numero di processi attivi, etc.), di verificare la disponibilità dei servizi offerti e inviare notifiche nel caso di malfunzionamenti. Talvolta può effettuare azioni preventive per limitare i danni. Nagios è l'acronimo di Notice Any Glitches In Our System (notifica qualsiasi malfunzionamento nel nostro sistema). Sono presenti sul mercato diverse soluzioni software per il monitoraggio, quali System management della suite IT Performance di HP e Tivoli-netview della IBM che sono entrambi programmi modulari che permettono di caricare solo il modulo relativo a quello che si vuole controllare, senza rischiare di appesantire il sistema. Tuttavia hanno entrambi un costo elevato e presentano diversi lati negativi. System management, in particolare prevede la centralizzazione dell attività di monitoraggio appesantendo notevolmente il server centrale. Nonostante quindi l ottima validità di tali soluzioni, si preferisce l altrettanto valida alternativa open-source rappresentata da Nagios. Alessio Silvestro N46/247! 3

Nagios presenta una struttura modulare composta da 3 componenti: 1. Nagios core 2. Plugin 3. Estensioni modulari o Addon Poiché Nagios tratta in egual modo servizi e host, per esporre più scorrevolmente l argomento si tenderà a non specificare ogni volta l oggetto del monitoraggio,tranne nei casi in cui il comportamento di Nagios risulta differenziato oppure sia rivolto esclusivamente all uno o all altro oggetto. Capitolo 1 NAGIOS CORE Nagios core è un demone, un programma sempre attivo eseguito in background e residente in memoria. E' il fulcro dell'infrastruttura di monitoraggio e consente di effettuare diverse operazioni: monitorare qualsiasi servizio senza essere a conoscenza dell'effettiva entità che sta monitorando grazie all'uso dei plugin; gerarchizzare la rete; definire event handler da eseguirsi all occorrenza di determinati problemi, al fine di risolverli tempestivamente; visualizzare rapidamente lo stato corrente della rete tramite una semplice interfaccia web, che contiene le notifiche inviate, file di log e lista problemi accaduti. Alessio Silvestro N46/247! 4

Di seguito saranno analizzati i componenti e le caratteristiche fondamentali di Nagios core. 1.1 Host Gli host sono apparecchi fisici collegati alla rete, quali server, router o stampanti, identificati su di essa da un indirizzo IP o MAC. Hanno generalmente uno o più servizi associati ad essi e hanno relazioni di "parentela" con altri host appartenenti alla medesima rete. Nagios utilizza le relazioni di parentela nelle definizioni degli host per definire la topologia della rete. 1.2 Servizi Figura 2: Servizi relativi agli host [3] I servizi sono un punto centrale nell'infrastruttura di monitoraggio. Ogni servizio è associato almeno ad un host e può essere un attributo di un host (carico di processore, memoria usata, uptime, etc.) o un servizio fornito dall host (come http, pop3, ftp, ssh, etc.). Alessio Silvestro N46/247! 5

1.3 Time period I time period sono lo strumento di configurazione messo a disposizione da Nagios per definire la finestra temporale all interno della quale host e servizi devono essere monitorati. In particolare, i time period indicano quali contatti devono essere notificati tra quelli definiti per lo stesso servizio e attivi nelle diverse finestre temporali(ad esempio festivi,feriali).la definizione dei time period avviene attraverso l utilizzo di due variabili presenti nella definizione dei servizi, check_period e notification_period : la prima è utile per definire la finestra temporale dei controlli mentre la seconda è utile a definire la finestra temporale entro la quale a Nagios è permesso inviare notifiche. Entrambe hanno come valore di default 24x7. 1.4 Contatti I contatti giocano un ruolo fondamentale all'interno dell'infrastruttura di monitoraggio. Si tratta di persone o gruppi di persone che, nel caso di funzionamento anomalo, ricevono tramite e-mail, chiamate o altro, notifiche su servizi e host di loro competenza, permettendo così un intervento tempestivo. Inoltre Nagios offre la possibilità di definire gruppi di persone responsabili per particolari servizi o semplicemente responsabili in determinati time period. 1.5 Tipi di stato Lo stato corrente dei servizi monitorati è determinato dallo stato del servizio (ok, warning, critical, etc.) e dal tipo dello stato del servizio. Lo stato del servizio serve ad indicare una condizione "statica" in cui si trova il servizio in quel preciso istante. Il tipo di stato invece serve ad indicare una condizione "dinamica" Alessio Silvestro N46/247! 6

dello stato del servizio, ovvero sul come sia arrivato il servizio a quella particolare condizione. L'uso dei tipi di stato serve ad evitare che problemi transitori, dovuti in alcuni casi a fattori esterni ai servizi stessi, possano attivare azioni correttive. Di seguito specifichiamo i tipi di stato e come vengono gestiti. Soft state Un servizio si trova in un Soft State quando in quell'istante è non-ok, ma non sono stati ancora effettuati un numero di controlli pari a max_check_attempts (variabile definita nella definizione del servizio, che serve appunto da indicatore del passaggio da uno stato all'altro), oppure quando un servizio viene recuperato da un Soft State, situazione definita come Soft Recovery, e serve per continuare l'azione di monitoraggio e non abbassare la guardia, verificando quindi l'effettivo ripristino del servizio. Hard state Gli hard state occorrono per i servizi nelle seguenti situazioni: un servizio risulta non-ok ed è stato ricontrollato per max_check_attempts volte; un servizio ha un transitorio da un Hard State ad un altro (ad esempio passa da warning a critical); un servizio è non-ok e il corrispondente host è unreachable; un servizio viene recuperato da un Hard State. Questo stato è chiamato Hard Recovery e viene utilizzato per prevenire falsi transitori che potrebbero invalidare le azioni preventive e di notifica di Nagios. 1.6 External command file Le azioni di monitoraggio processate da Nagios possono partire dal demone stesso oppure, come nella maggior parte dei casi, da applicazioni esterne. L'external command file è l'intermediario tra il demone e le applicazioni esterne: queste possono dare comandi Alessio Silvestro N46/247! 7

a Nagios scrivendo sull'external command file, periodicamente processato dal demone di Nagios. L external command file è implementato come una coda a gestione FIFO con una dimensione pari a circa 64 Kb. Figura 3: External command file [3] 1.7 Event handler Gli event handler sono comandi di sistema opzionali, script o eseguibili, che vengono eseguiti quando la transizione di stato di un servizio lo richiede. In particolare viene eseguito nella transizione da uno stato OK ad uno Soft/Hard, oppure quando si trova in un Soft/Hard recovery. L uso degli event handler rappresenta l'abilità di Nagios di risolvere preventivamente i problemi prima che essi siano notificati, o in ogni caso prima di un possibile intervento umano. Un uso comune degli event handler potrebbe essere il riavvio di un servizio fallito o il salvataggio dei file di log in un database. Esistono fondamentalmente due tipi di event handler all'interno di Nagios, definiti entrambi sia per gli host che per i servizi: global event handlers e specific event handlers. Alessio Silvestro N46/247! 8

Il primo tipo, definito direttamente da Nagios, ha capacità di ripristino da guasti limitate. Il secondo, eseguito in caso di fallimento del primo, è definito dall'amministratore della risorsa stessa e permette un azione correttiva definita ad hoc. 1.8 Topologia della rete Nagios è in grado di definire la topologia della rete. Invia pacchetti a tutti gli host connessi e tiene traccia di quelli che intercorrono lungo il cammino, definendo così i rapporti di "parentela", specificati poi nei file di definizione dei vari host. La conoscenza della topologia della rete permette a Nagios di riuscire a distinguere gli host unreachable: nel caso in cui un host diventi down, Nagios assegnerà lo stato di unreachable a tutti gli host appartenenti alla sottorete raggiungibile solamente attraverso quel particolare host. 1.9 Check attivi e passivi Nagios è capace di monitorare servizi in due modi: Check attivi Sono i controlli più comuni inizializzati dal demone stesso. I check attivi sono eseguiti ad intervalli di tempo regolari, o quando un servizio si trova in un Soft/Hard state oppure a richiesta quando Nagios necessita dell'ultima informazione sullo stato di un particolare servizio. Alessio Silvestro N46/247! 9

Figura 4:Check attivi [3] Check passivi I check passivi sono, al contrario, inizializzati da applicazioni esterne. Questa peculiarità permette a Nagios di monitorare servizi che presentano una natura asincrona (non adatti, quindi, allo scheduling ad intervalli di tempo regolare proprio di Nagios) e servizi che risiedono dietro un firewall, che sarebbero altrimenti non raggiungibili. Come un check passivo lavora nel dettaglio: Un'applicazione esterna esegue il check di un servizio e scrive il risultato sull'external command file. Nagios legge i dati presenti nell'external command file per la loro successiva elaborazione. Nell external command file sono presenti sia i check attivi che quelli passivi. Questa scelta di uguaglianza nel trattamento dei vari check rende ottimale l'integrazione di informazioni prese da applicazioni esterne. Uno dei motivi per cui si preferisce l uso dei check passivi è legato alla presenza di firewall su host remoti. Poiché Nagios non permette la scrittura libera sull'external command file, la comunicazione tra host remoti e il demone sul server centrale è resa possibile grazie ad un addon di Nagios, NSCA. Alessio Silvestro N46/247! 10

1.10 Elementi utili all'installazione Nagios non richiede particolari elementi per una corretta installazione. Richiede solo un server web installato sulla macchina, preferibilmente Apache, e la libreria gd di Thomas Boutell utilizzata per la grafica dell'interfaccia web 1.11 Interfaccia web Nagios offre una semplice interfaccia web, accessibile esclusivamente dal nodo centrale, che rappresenta un valido strumento di gestione dell infrastruttura di monitoraggio anche per utenti poco esperti del settore, rendendo immediate informazioni sulle performance e sui servizi dell intera rete. Di seguito verranno mostrati degli screenshot di particolari funzioni al fine di esplicarne le caratteristiche fondamentali. Viene riportata la semplice grafica che l interfaccia propone all utente; sono evidenziati (attraverso frecce rosse) alcuni punti trattati nel dettaglio successivamente. Figura 5:Home page interfaccia web Alessio Silvestro N46/247! 11

La schermata seguente mostra lo stato dei servizi monitorati sui diversi host connessi alla rete, specificando tra le varie informazioni l host sul quale viene effettuato il controllo e lo stato del servizio. Figura 6:Servizi monitorati interfaccia web L interfaccia web permette inoltre di creare report, come quelli mostrati nella seguente figura, per gli stati dei vari host. Sulla tabella vengono riportate le percentuali, relative all intera finestra di monitoraggio, dei vari stati susseguitisi. Figura 7: Report reperibilità degli host Alessio Silvestro N46/247! 12

Con pochi click è possibile avere un sommario dei problemi riscontrati mostrando, in particolare, per ogni servizio, lo stato e il tipo di stato che hanno messo in allerta il sistema. Se il problema è stato risolto, in cima alla lista presenta lo stato corretto. Figura 8: Sommario report Alessio Silvestro N46/247! 13

Capitolo 2 Plugin A differenza di tanti altri tool, Nagios non include alcun meccanismo concreto per il monitoraggio dei servizi. I veri artefici del monitoraggio sono i Nagios Plugin, ovvero script o eseguibili scritti da terzi in grado di monitorare host e servizi sulla rete. Figura 9:Plugin come livello astratto [3] I plugin agiscono come un livello astratto intermedio tra le richieste "logiche" presenti sul demone, gli host e i servizi monitorati. Alessio Silvestro N46/247! 14

Il vantaggio di questo tipo di architettura a plugin è la possibilità di monitorare qualsiasi cosa senza essere limitati alle funzioni presenti nel tool. Gli sviluppatori possono così concentrarsi solo sul fulcro dell infrastruttura di monitoraggio, lasciando a terzi la creazione di plugin. Nagios, inoltre, è totalmente all oscuro dell oggetto del monitoraggio e di conseguenza della sua struttura interna, garantendo così una certa riservatezza. Per creare un infrastruttura di monitoraggio completa bisogna installare Nagios-core congiuntamente ai suoi plugin, senza i quali il suo utilizzo risulterebbe vano.i plugin di Nagios offrono una svariata lista di controlli su servizi di base quali memoria usata, carico della cpu, etc. Nel caso piuttosto frequente in cui i plugin di base non dovessero soddisfare le esigenze del cliente, è possibile crearne di nuovi ad hoc. 2.1 Creazione di un plugin Nagios non vincola in alcun modo gli sviluppatori nella creazione dei plugin (script shell,c,perl,etc.) e dà solamente delle linee guida che gli sviluppatori devono seguire per la corretta integrazione nella piattaforma. Riportiamo di seguito due dei punti fondamentali per la corretta scrittura di un plugin: il plugin deve terminare con uno dei possibili valori di ritorno: Figura 10: Possbili valori di ritorno dei plugin [19] l'output del plugin deve essere al più 80 caratteri, rediretto verso lo STDOUT. A partire da Nagios 3, è possibile scrivere plugin che ritornano più linee di output (separate da una pipe), funzione utile nell uso dei plugin da linea di comando. Alessio Silvestro N46/247! 15

Capitolo 3 ESTENSIONI MODULARI Nagios presenta una struttura flessibile e facilmente ampliabile attraverso estensioni modulari o Addon. Questo permette di caricare solo le funzionalità necessarie, senza appesantire inutilmente il sistema, consentendo possibili estensioni future. Di seguito saranno trattate 3 tra le varie estensioni offerte da Nagios. 3.1 NRPE Nrpe (Nagios Remote Plugins Executor) permette l'esecuzione di plugin su macchine remote linux/unix. Nrpe, in particolare, sostituisce il metodo per l esecuzione di plugin remoti attraverso il plugin check_by_ssh, il quale crea connessioni sicure ssh per ogni check, introducendo un overhead che al crescere delle dimensioni delle sistema potrebbe risultare troppo oneroso. Nrpe è formato da due componenti: 1. Il plugin check_nrpe che risiede sulla macchina monitorante. 2. Il demone NRPE presente sulla macchina monitorata, dove saranno presenti, inoltre, i plugin. Quando Nagios ha bisogno di monitorare un servizio sulla macchina remota esegue il plugin check_nrpe, indicando il servizio richiesto check diretto. Il plugin check_nrpe contatta il demone nrpe sull'host remoto (opzionalmente tramite una connessione protetta Alessio Silvestro N46/247! 16

ssl). Il demone esegue il plugin appropriato al servizio richiesto (sull'host remoto), e ritorna i risultati al plugin check_nrpe.! Analisi di uno strumento per il monitoraggio di sistemi distribuiti Figura 11:Check diretti [3] E' inoltre possibile monitorare servizi pubblici e risorse su server remoti che non sono raggiungibili direttamente dalla macchina monitorante. Nel caso in cui una macchina host (dove risiede il demone nrpe) può comunicare con un server remoto inaccessibile dalla macchina monitorata, è possibile configurare il demone nrpe per permettere di monitorare il server indirettamente. In questo caso, quindi, il demone nrpe si comporta essenzialmente come un proxy e il check è definito indiretto. Figura 12: Check indiretti [3] Alessio Silvestro N46/247! 17

3.2 NSCA NSCA (Nagios Service Check Acceptor) è un addon di Nagios che permette di distribuire controlli su vari server e consente una comunicazione sicura tra loro. E composto da due parti: -il demone NSCA, presente sul server centrale, che ha il compito di ricevere e gestire i controlli ricevuti dagli host remoti; -SEND_NSCA, programma lato client utilizzato per inviare i controlli eseguiti in locale al server centrale. Figura 13:Check remoti NSCA [3] Nella pratica l uso di NSCA permette di distribuire i controlli su diversi server, in modo tale da alleggerire il carico di lavoro effettuato dal server di Nagios. L amministratore dovrà preventivamente dividere il carico di lavoro sui vari server, configurando adeguatamente sia il server centrale che i vari host. 3.2.1 Sicurezza e comunicazioni cifrate Un problema di fondamentale importanza nelle applicazioni distribuite è quello della sicurezza. Utenti maliziosi potrebbero modificare le informazioni inviate dai client NSCA per mascherare problemi presenti su client remoti, invalidando così lo scopo fondamentale nell uso di Nagios: fornire un azione tempestiva nel riparare i guasti. Oppure potrebbero costringere Nagios ad eseguire event handler (ad esempio il riavvio di Alessio Silvestro N46/247! 18

processi), in seguito a falsi allarmi, invalidando direttamente il servizio monitorato.le comunicazioni tra client e server devono quindi essere cifrate per garantire l integrità dei dati e l autenticità dei dati e degli host. 3.2.2 I passi della cifratura Quando un client vuole inviare risultati di check al server, invoca la funzione send_nsca, la quale usa un algoritmo di cifratura, deciso in fase di progettazione congiuntamente ad una password (presente nel file di configurazione send_nsca.cfg). Per garantire un ulteriore sicurezza sull integrità dei dati, la funzione send_nsca, prima della cifratura, esegue il CRC-32 dei pacchetti in modo tale da permettere al demone di scoprire eventuali modifiche dei dati da parti di terzi. Il demone, ricevuto il pacchetto, lo decifra utilizzando l algoritmo prestabilito utilizzando la password presente nel file nsca.cfg, ne calcola il CRC-32 del pacchetto decifrato e, se coincide con il CRC-32 ricevuto, salva il pacchetto come correttamente ricevuto. Nagios inoltre scarta tutti i pacchetti relativi a controlli non associati a nessuna definizione. In questo modo, anche nel caso in cui un utente malizioso venisse a conoscenza dei metodi di cifratura, dovrebbe indovinare i servizi associati per quel particolare host. 3.2.3 Replay Attack Un ulteriore tipologia di attacchi è rappresentata dai Replay Attack. Utenti maliziosi potrebbero intercettare e copiare i pacchetti inviati dal client nsca al server in un momento di quiete, per poi utilizzarli in futuro, in modo da mascherare situazioni di malfunzionamento, essendo però completamente all oscuro dei metodi di cifratura. Per evitare ciò il demone nsca genera una stringa e la invia al client. Questa stinga verrà utilizzata insieme alla password e all algoritmo di cifratura per cifrare i dati.viene generata una stringa diversa per ogni sessione temporale e viene inviata in chiaro essendo Alessio Silvestro N46/247! 19

singolarmente priva di informazioni utili. Quindi il pacchetto cifrato dipenderà dalla password, dall algoritmo e dalla stringa ricevuta. Un pacchetto cifrato con una stringa di una diversa sessione temporale sarà scartato dal server. L uso di NSCA è utile nell utilizzo dei check passivi su host remoti, ma presenta numerosi svantaggi: L amministratore deve configurare ogni controllo sia sul server che sull host, e deve tenere traccia della particolare distribuzione dei controlli sui diversi host. Nel caso in cui un server fallisca, tutti i controlli su quel determinato host andrebbero persi, costringendo l amministratore ad effettuare una redistribuzione manuale dei controlli sui rimanenti host. Gli host remoti comunicano con il server centrale tramite l external command file, generalmente di dimensioni limitate (all incirca 64 kb), il che limita il numero di richieste che contemporaneamente possono pervenire al server, ponendo un freno, così, alla reale scalabilità dell intera infrastruttura di monitoraggio. 3.3 DNX Dnx è un estensione modulare di Nagios che permette una redistribuzione dinamica dei carichi attraverso una rete di host remoti. Assicura che il lavoro sia distribuito in modo equo e uniforme tra i dnx host, chiamati worker. Diversi sono i vantaggi tratti dall utilizzo di questa soluzione. I cambiamenti nella configurazione del nodo centrale di Nagios sono minimi, per cui bisogna solo inserire una o due linee di codice nel file di configurazione, che permette di caricare il modulo NEB (Nagios Event Broker). Si ha la possibilità di aggiungere o rimuovere nodi a run time Alessio Silvestro N46/247! 20

senza la necessità di alcun cambiamento. La distribuzione dei carichi è dinamica, utile nel caso di guasti di nodi worker. Dnx bypassa l external command file per interfacciarsi con il demone, non limitando così la reale scalabilità dell intera infrastruttura. Figura 14 :Architettura DNX [6] Dnx è composto da 3 componenti fondamentali: il plugin Nagios Event Broker e il Dnx Server (presenti entrambi sui server) e il Dnx Client presente sui vari nodi worker. Si osserva di seguito il lavoro nel dettaglio di questi componenti attraverso lo studio di qualche grafico. Alessio Silvestro N46/247! 21

Figura 15: Schema di funzionamento server DNX [6] Nel grafico possiamo notare due zone, che evidenziano i compiti svolti dal demone di Nagios e quelli svolti dal plugin NEB. La coda a gestione fifo rappresenta l external command file, che riceve i risultati dei controlli dai plugin. Il demone di Nagios preleva i risultati dalla coda e li inserisce in un buffer circolare, (successivamente gestito) e, eventualmente, vengono effettuati ulteriori controlli su tali risultati. Alessio Silvestro N46/247! 22

3.3.1 NEB(Nagios Event Broker) Il plugin NEB crea 4 thread: Dispatcher: ha il compito di assegnare ad ogni richiesta dei nodi worker un job e inviare loro i relativi comandi; Collector: riceve i risultati dei comandi eseguiti dai nodi worker, bypassando la coda fifo, e verifica se è presente un job relativo ai dati ricevuti e solo allora inserisce i risultati nel buffer circolare; Timer. verifica se ogni job ha un corrispettivo nel buffer circolare e, in caso affermativo, controlla se i risultati sono arrivati in tempo; Register: ha il compito di ricevere le richieste di job inviati dai nodi worker e inserirli nella coda delle richieste. Figura 16: Schema di funzionamento client DNX [6] Alessio Silvestro N46/247! 23

Il dnx client crea almeno 3 thread: -Client Agent -Work Load Manager -Almeno un Service thread Il Work Load Manager è l elemento che conferisce dinamicità e flessibilità a DNX. Presente su ogni nodo worker, a seconda del carico di lavoro crea e distrugge service thread che invieranno richieste di job al server, ovvero richiedono lavoro. Questo metodo permette una distribuzione dei carichi -equa, in quanto ogni nodo worker richiede solo la quantità di lavoro che riesce a gestire; -flessibile, perché un nodo worker può diminuire la richiesta di lavoro in caso di carico eccessivo, distruggendo Service thread, senza intaccare l attività di monitoraggio; -dinamica,perché il carico verrebbe redistribuito equamente sui nodi worker rimanenti nel caso in cui un nodo worker dovesse essere non utilizzabile, rischedulando i check non eseguiti sul nodo in questione, rintracciati dal timer thread; Nel caso limite in cui dovessero essere inutilizzabili tutti i nodi worker, il demone di Nagios si comporterebbe come se il modulo Neb non fosse mai stato caricato, quindi incaricandosi di tutti i controlli. Alessio Silvestro N46/247! 24

Capitolo 4 Cloud computing In informatica il termine Cloud Computing indica un insieme di tecnologie, offerte tipicamente da un service provider, che consente agli utenti finali di archiviare informazioni, reperibili da un qualsiasi punto di accesso alla rete (ad esempio Google Documents) e/o sfruttare risorse computazionali distribuite e virtualizzate in rete. Risulta altamente diffuso oggi per la sua flessibilità e la capacità di adattarsi a scenari in continua evoluzione e trasformazione, quali quelli dell attuale industria ICT. Rappresenta, secondo la visione del Reliabel Adaptive Distributed Systems Laboratory dell università di Berkeley[ 2 ], una grande opportunità per le aziende, in quanto riduce i rischi nell investimento di capitali in infrastrutture informatiche e permette ad esse di sfruttare le migliori tecnologie presenti sul mercato. Secondo la definizione del NIST [ 3 ](National Institute of Standard and Tecnology) degli Stati Uniti, il cloud computing è un modello atto a garantire l accesso su rete in modo universale, comodo e on-demand a un insieme condiviso di risorse di calcolo configurabili [ 2 ] Above the Cloud: A berkeley View of Cloud Computing UC Berkeley Reliable Adaptive Distributed Systems Laboratory 10/2/09 Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz,Andy Konwinski, Gunho Lee, David Patterson,Ariel Rabkin, Ion Stoica, and Matei Zaharia [ 3 ] The NIST Definition of Cloud Computing Peter Mell and Tim Grance Version 15, 10-7-09 Alessio Silvestro N46/247! 25

(ad esempio reti,server storage e applicazioni), che possono essere rapidamente assegnate e rilasciate, con minimi sforzi di gestione o interazione da parte del provider dei servizi. Il termine Cloud vuole sottolineare la condizione dell utente finale, il quale sfrutta tali risorse rimanendo completamente all oscuro dell effettiva dislocazione delle risorse su rete. Figura 17:Cloud Computing come nuvola [14] 4.1 MODELLI DI SERVIZIO Un architettura di Cloud Computing può offrire fondamentalmente tre tipologie di servizi: 4.1.1 SaaS(Software as a Service) Al cliente viene offerta la possibilità di utilizzare applicazioni del provider, residenti su di un infrastruttura di Cloud. Le applicazioni in questione sono accessibili tramite un web browser, però l utente non gestisce l infrastruttura sottostante in alcun modo (ad esempio Alessio Silvestro N46/247! 26

impostazioni di rete,sistema operativo, etc.) ad eccezione di alcune configurazioni utili all applicazione fornita dal provider.! Analisi di uno strumento per il monitoraggio di sistemi distribuiti 4.1.2 PaaS(Platform as a Service) Questo tipo di servizio permette al cliente l installazione di applicazioni proprietarie (anche a fini commerciali), create con tecnologie supportate dall infrastruttura in questione (ad esempio linguaggi di programmazione). In questo scenario l utente ha pieno controllo delle applicazioni da lui installate e possibilmente anche delle impostazioni di sistema utili al corretto funzionamento delle applicazioni stesse. 4.1.3 IaaS (Infrastructure as a Service) Il servizio offerto al cliente consiste nel riservargli l utilizzo di risorse di calcolo, di rete e di archiviazione. Il cliente è all oscuro di tutta l infrastruttura reale sottostante, grazie al massiccio impiego delle moderne tecniche di virtualizzazione, utilizzate in tutte le infrastrutture che seguono il modello Cloud. Il cliente ha pieno controllo delle applicazioni e del sistema operativo presente sui server, e un limitato controllo sui dispositivi di rete (ad esempio firewall), mentre non gestisce affatto l infrastruttura sottostante (a lui totalmente o parzialmente sconosciuta). 4.2 OpenStack OpenStack è un progetto open source per il Cloud Computing IaaS nato nel 2010 da una collaborazione tra RackSpace e la Nasa, successivamente affiancate da più di 100 aziende tra cui Citrix Systems, Dell, AMD, Intel, Nec, Linux, Hp e Cisco. A partire dalla versione Alessio Silvestro N46/247! 27