analisi di uno strumento per il monitoraggio di … introduzione 1 nagios 3 capitolo1 nagios core 4...

!

Facoltà di IngegneriaCorso 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 1Nagios 3Capitolo1 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 11Capitolo2 Plugin 14 2.1 Creazione di un plugin 15Capitolo 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 23Capitolo 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 28Installazione di Nagios su OpenStack 30Riferimenti 32

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.

! ! ! Analisi di uno strumento per il monitoraggio di sistemi distribuiti

[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.

! Analisi di uno strumento per il monitoraggio di sistemi distribuiti

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.



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.



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.).



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"



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



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”.



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 .



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.



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



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



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



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.



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.



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



ssl). Il demone esegue il plugin appropriato al servizio richiesto (sull'host remoto), e ritorna

i risultati al plugin check_nrpe.

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]



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



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



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



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.



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.



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]



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.



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/09Michael 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 GranceVersion 15, 10-7-09



(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



impostazioni di rete,sistema operativo, etc.) ad eccezione di alcune configurazioni utili

all’applicazione fornita dal provider.

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



11.04 è supportato nativamente da Ubuntu.Open Stack è composto da 3 progetti principali.

4.2.1 Compute

Nome in codice Nova è il progetto che si occupa della creazione e della gestione dell’intera

piattaforma di cloud, creando reti di macchine virtuali scalabili e interconnesse in modo

sicuro. Offre inoltre le API necessarie all’amministrazione dell’infrastruttura, e le

interfacce per la gestione delle istanze in esecuzione e della rete.

4.2.2 Object Store

Nome in codice Swift, è un sistema per l’archiviazione a lungo termine di grandi quantità

di dati statici (definiti oggetti), che possono essere recuperati, controllati e aggiornati. Si

appoggia su cluster di server standard e ha un’architettura completamente distribuita, senza

la presenza di nodi centrali o super nodi, in modo da garantire la scalabilità, la ridondanza

e la permanenza dei dati.

4.2.3 Image Service

Nome in codice Glance, offre le funzionalità per la gestione completa, registrazione e

recupero delle immagini delle istanze gestite dai vari nodi compute, permettendo la loro

memorizzazione in un normale file system oppure utilizzando i servizi offerti da Object

Store.



Figura 18: Struttura di OpenStack

Figura 18: Struttura OpenStack [17]

Il modello Cloud, quindi sfrutta a più livelli le potenzialità offerte dalla distribuzione dei

sistemi in quanto l’intera infrastruttura può poggiarsi su configurazioni hardware

completamente distribuite e dislocate in locazioni differenti e, ad un livello più alto, i

servizi in esecuzione su di un’infrastruttura Cloud, a loro volta, possono essere progettati

in modo distribuito. Un esempio di questa “gerarchia di sistemi distribuiti” potrebbe essere

un’applicazione client-server o peer-to-peer (quindi applicazioni distribuite) eseguite in un

ambiente totalmente distribuito e virtualizzato. In questo contesto risultano particolarmente

utili strumenti di monitoraggio per infrastrutture distribuite, in quanto in questo modo è

possibile fornire servizi su larga scala in modo dinamico ed efficiente.



Installazione di Nagios su OpenStack

Openstack offre un servizio di tipo IaaS, fornendo quindi all’utente server virtuali

dedicati e collegati all’interno di un Virtual Private Network. Openstack crea istanze di

macchine virtuali personalizzate a seconda delle richieste, ognuna con una

configurazione differente e personalizzabile, al fine di soddisfare le esigenze degli

utenti.

Uno scenario semplificato dell'infrastruttura di Cloud è composto da un host, sul quale

risiedono il nodo compute e le varie istanze delle macchine virtuali installate.

Data la centralità del nodo compute, è buona norma installare il demone di Nagios su

un secondo nodo, diverso dal primo, per evitare che problemi sul nodo compute

compromettano l'attività di monitoraggio.

Sul nodo monitorante saranno installati l'interfaccia web e Nagios Core con i relativi

plugin, in particolare il plugin check_nrpe, che permette l'esecuzione dei controlli sui

vari host remoti sulla rete.

Sul nodo compute e sulle diverse istanze saranno invece installati solo i plugin e il

demone Nrpe, per permettere di comunicare i risultati dei controlli al nodo

monitorante.Nagios è ora in grado di monitorare l'infrastruttura di Cloud, potendo

scegliere tra una vasta gamma di plugin che consentono di stabilire se il nodo compute

è UP, quante istanze sono attive e quali risorse stanno sfruttando.



Si riporta di seguito la mappa della rete, mostrata nell’interfaccia web, dove si

evidenzia la presenza di 4 nodi: il nodo monitorante (nagios-server), il nodo compute e

due istanze attive sull’infrastruttura di Cloud (presenti sul nodo compute).

Con questa semplice schermata Nagios offre la possibilità di conoscere la topologia

della rete, e sapere lo stato dei vari host (Up, Down, etc.) come mostrato in figura.

Figura 19 Mappa della rete installazione Nagios



Riferimenti

[1] “Distributed Systems: Principles and Paradigms “

Andrew S. Tanenbaum and Maarten van Steen

Prentice Hall,2007

[2] http://nagios.sourceforge.net/docs/3_0/quickstart.html

[3] http://nagios.sourceforge.net/docs/nagioscore-3-en.pdf

[4] http://nagios.sourceforge.net/docs/nrpe/NRPE.pdf

[5] http://dnx.sourceforge.net

[6] http://dnx.sourceforge.net/DNX_Workflow.pdf

[7] http://en.wikipedia.org/wiki/HP_OpenView

[8] h t t p : / / h18002 .www1.hp .com/p roduc t s / s e rve r s /managemen t / agen t s /

documentation.html

[9] http://www-01.ibm.com/software/tivoli/products/netview/

[10] http://openstack.org/projects/image-service

[11] http://openstack.org/projects/storage

[12] http://openstack.org/projects/compute

[13] http://it.wikipedia.org/wiki/Cloud_computing

[14] http://it.wikipedia.org/wiki/File:Cloud_computing.svg

[15] http://www.openstack.org/community/companies/

[16] http://www.ubuntu-linux.it/canonical-openstack-ubuntu-11-04-natt/

[17] http://docs.openstack.org/diablo/openstack-compute/admin/os-compute-adminguide-

trunk.pdf

[19] http://nagiosplug.sourceforge.net/developer-guidelines.html

[18] http://radlab.cs.berkeley.edu/

32