Università degli Studi di Napoli Federico II

Transcript

1 Università degli Studi di Napoli Federico II Scuola Politecnica e delle Scienze di Base Area Didattica Scienze MM.FF.NN Master di I Livello in Tecnologie per il CAlcolo Scientifico ad Alte Prestazioni - CASAP Tesi di Master Un Sistema di Monitoraggio per il data center ReCaS/PRISMA di Napoli: Analisi dei requisiti e funzioni di base Relatore Candidato Prof. G.Russo Salvatore Naddeo matr. Z Anno Accademico

2 I Indice generale Introduzione...III 1.Struttura generale del Data Center da monitorare Analisi dei requisiti Requisiti Funzionali Requisiti Non Funzionali Requisiti Tecnici Servizi Da Monitorare Definizione Delle Soglie Per I Servizi L'ambiente Utilizzato: FAN (Fully Automated Nagios) L'ambiente Utilizzato: Nagios Implementazione del sistema di monitoraggio Schematizzazione Del Sistema Scelte Implementative Script Realizzati check_active_cores.sh check_core_number.sh check_cpu_load.sh check_process_number.sh check_traffic_in.sh check_traffic_out.sh check_up_hosts.sh check_used_ram.sh Test degli script e configurazione dei servizi: un esempio pratico Test Degli Script Configurazione Dei Servizi In Centreon Conclusioni Panoramica Sul Sistema Realizzato Conclusioni E Sviluppi Futuri...39 Appendice: dettagli Hardware del Data Center...41 Bibliografia...45

3 II Introduzione Obiettivo di questo lavoro è la realizzazione dell'infrastruttura di monitoraggio per il Data Center da utilizzare nell'ambito del progetto ReCaS ubicato nella sede di Napoli e nella sua integrazione con quanto presente anche negli altri siti del progetto, ovvero Bari, Catania e Cosenza, oltre che nel già esistente portale web del progetto. Quando parliamo di data center per il calcolo ad alte prestazioni dobbiamo tenere presente che si tratta di sistemi composti da centinaia, nei casi più grandi anche migliaia, di apparati destinati a vari usi e non sempre omogenei fra loro. I requisiti di affidabilità sono particolarmente stringenti e bisogna garantire il funzionamento della rete di calcolo 24 ore al giorno 7 giorni su 7. Date queste premesse è quindi evidente che si rende necessaria una infrastruttura sia software che hardware dedicata al monitoraggio della rete di calcolo sia nel suo complesso che nelle singole apparecchiature che la compongono. Le particolari caratteristiche del progetto impongono inoltre la realizzazione di un sistema di monitoraggio basato su software open source e modulare, in modo che ognuno dei quattro nodi della rete possa, partendo da un set di requisiti comuni, personalizzare la propria piattaforma in base alle sue esigenze specifiche. Il lavoro che sarà descritto nel seguito di questo documento si è svolto in due fasi distinte: 1) realizzazione della mappa fisica del Data Center, necessaria per ricostruire la topologia della rete e i collegamenti fra i vari apparati installati. 2) Realizzazione del sistema di monitoraggio, comprendente a sua volta le fasi di raccolta dei requisiti, configurazione del software, implementazione degli script necessari ad interrogare gli apparati e delle pagine web in cui i dati saranno visualizzati. Nella prima fase mi sono basato su documentazione pre-esistente, opportunamente integrata ed ampliata per ottenere una rappresentazione coerente della struttura fisica del data center.

4 III Successivamente è stato necessario scegliere fra le varie opzioni open-source e non quale piattaforma software utilizzare per realizzare il sistema di monitoraggio; una volta effettuata la scelta mi sono soffermato sulla configurazione di base del software e dei protocolli necessari. Solo dopo questa fase è stato possibile scrivere il codice necessario alla realizzazione delle funzionalità individuate in fase di raccolta dei requisiti e alla loro rappresentazione in un formato visibile tramite web-browser. E' bene far presente al lettore che in questo lavoro non è stato possibile realizzare tutte le funzionalità individuate in fase di specifica dei requisiti; mi sono soffermato in particolare sui servizi relativi alla categoria di apparati che di seguito indicheremo come worker nodes. Il lavoro seguente sarà così strutturato: nel capitolo 1 sarà descritta la struttura generale del data center da monitorare; nel capitolo 2 affronteremo l'analisi dei requisiti del sistema da realizzare; il capitolo 3 sarà invece dedicato all'implementazione del sistema. Il capitolo 4 sarà invece dedicato alla descrizione della modalità di test e di configurazione del sistema. Nel capitolo 5 saranno mostrate le considerazioni finali sul lavoro eseguito e sarà fatto il punto sulle sue possibili evoluzioni future.

5 1. Struttura generale del Data Center da monitorare Il Data Center da monitorare è composta da due sale poste in edifici diversi all'interno del Campus Universitario di Monte Sant'Angelo: la struttura della prima sala è schematizzata in questo modo: Il data center in questione è collegato tramite rete in fibra ottica a 10GB/s con il data center ubicato nell'edifico del dipartimento di fisica e schematizzato invece nella figura seguente: Pagina 5 di 45

6 Insieme, le due sale formano un unico data center, collegato alle altre sedi del progetto, ovvero Bari, Catania e Cosenza, tramite la rete Garr-X, seguendo lo schema riportato di seguito [1]: Illustrazione 3: la rete Garr-X E' bene ricordare che al momento la struttura del data center è ancora in fase di allestimento; questo lavoro è focalizzato su quanto attualmente installato e funzionante, come si può vedere nella seguente figura. Pagina 6 di 45

7 Illustrazione 4: riepilogo delle caratteristiche del data center ReCaS In appendice saranno allegate le tabelle più dettagliate con la descrizione di ogni apparato inserito nei singoli rack monitorati e le specifiche generali. Pagina 7 di 45

8 2. Analisi dei requisiti Al momento in cui si è pensato di sviluppare un nuovo sistema di monitoraggio per il data center descritto in precedenza è stata necessario eseguire una fase di analisi e specifica dei requisiti, attraverso cui tracciare le linee guida da seguire nello sviluppo della piattaforma ed individuare le funzionalità da implementare in base alle richieste degli utenti Requisiti Funzionali Requisito fondamentale è la presenza di due categorie di utenti: Guest e Admin. Gli appartenenti alla prima categoria dovranno visualizzare lo stato della rete e le informazioni riguardanti i singoli apparati che la compongono. Non effettueranno operazioni per quello che concerne la gestione dei dati visualizzati e degli apparati facenti parte della rete. Gli appartenenti alla seconda categoria potranno effettuare tutte le operazioni di un utente generico, ed in più avranno la facoltà di eseguire operazioni di configurazione sul software di monitoraggio, come la modifica, l'aggiunta e la rimozione di hosts e/o servizi da visualizzare, l'attivazione e/o la sospensione di servizi. Inoltre, dove gli apparati lo consentono, gli utenti amministratori potranno interagire direttamente con essi per la loro configurazione, dopo essersi autenticati su di essi attraverso un meccanismo dipendente dal software, proprietario o no, installato sulla macchina. Riassumendo: al software di monitoraggio potranno accedere due distinte classi di utenti, una che è la specializzazione dell'altra : una avrà soltanto i permessi necessari a visualizzare lo stato della rete, l'altra invece avrà anche i permessi necessari alla configurazione del software e degli apparati. Il sistema di monitoraggio è stato progettato allo scopo di fornire agli utenti delle due categori determinate funzionalità: la seguente tabella mostra nel dettaglio la loro Pagina 8 di 45

9 descrizione e gli utenti autorizzati ad eseguirle. Funzionalità Utente Admin Utente Guest Autenticazione con username e password si si Visualizzazione mappa generale e interattiva della rete si si Modifica impostazioni software si no Gestione e configurazione dei servizi si no Ricezione notifiche sullo stato dei servizi si no Tabella 1: funzionalità e utenti Per maggiore chiarezza descriviamo le operazioni consentite alle due diverse categorie di utenti consentite attraverso un diagramma che segue lo standard UML : Pagina 9 di 45

10 Illustrazione 5: use cases Pagina 10 di 45

11 2.2. Requisiti Non Funzionali Notiamo subito, data la prevista installazione su siti diversi e non necessariamente omogenei, la necessità di avere un software scalabile, modulare, facilmente espandibile e modificabile. La caratteristica importante di una qualsiasi rete di calcolo è infatti quella di non avere una architettura fissata a priori: possiamo modificarne la topologia in qualsiasi momento, ad esempio aggiungendo ed eliminando apparati. Un nuovo elemento inserito nella rete non avrà necessariamente le stesse caratteristiche di quello che andrà a sostituire e ogni eventuale cambiamento deve essere completamente trasparente all'utente. Per questo motivo necessitiamo di un software di monitoraggio modulare, che permetta di gestire in modo semplice i cambiamenti nella configurazione della rete. Altrettanto importanti sono i requisiti di facilità di manutenzione, affidabilità del software e sicurezza degli accessi; il software di monitoraggio deve essere attivo 24 ore su 24 per 7 giorni su 7 e questo ci impone di realizzare un software di cui sia estremamente semplice recuperare una versione funzionante nel caso si verifichi un fault grave nel server su cui sta girando. Essendo poi un'applicazione web-based è fondamentale che deve essere garantito l'accesso alle sue funzionalità solo agli utenti autorizzati. Pagina 11 di 45

12 2.3. Requisiti Tecnici Dalla raccolta dei requisiti è emersa la necessità di utilizzare un software open-source, sviluppato per ambienti Linux e con requisiti hardware contenuti. Questo è un requisito fondamentale per fare in modo da avere un sistema che possa funzionare anche su macchina virtuale, in modo da rendere più semplici le eventuali operazioni di manutenzione e ripristino in caso di fault del sistema. Infine il software deve essere raggiungibile attraverso un comune browser web; caratteristica importante in quanto parliamo di un sistema gestibile completamente da remoto e integrato con altri strumenti simili messi in produzione negli altri siti aderenti al progetto ReCaS Servizi da monitorare Come già detto un data center è composto da apparati di diverso tipo e con diverse caratteristiche. In prima analisi possiamo dividere questo insieme in varie sottoclassi, omogenee per quello che riguarda le funzionalità offerte e i parametri da tenere sotto controllo. Fatta questa suddivisione ogni tipologia di macchina avrà un certo insieme di informazioni chiave, ovvero parametri fondamentali che il sistema dovrà permettere agli utenti di visualizzare e gestire. Nel caso specifico possiamo quindi riassumere classi di apparati e servizi da monitorare nella tabella seguente. Pagina 12 di 45

13 Classe di Apparati Utilizzo Servizi da monitorare Disk Box Controllers Gestione degli Storage Elements Descrizione, Ping Storage Elements Conservazione dei dati da Ping, SSH, CPU Load, elaborare Percentuale di Memoria Utilizzata, Spazio disco utilizzato, Processi attivi, Traffico IP v4, traffico IP v6, traffico totale Worker Nodes Esecuzione dei jobs sui dati Service Nodes Gestione accounting degli Ping, SSH, CPU Load, utenti e distribuzione dei Percentuale di Memoria jobs ai worker nodes Utilizzata, Spazio disco utilizzato, Processi attivi, Traffico IP v4, traffico IP v6, traffico totale CMC Gestione degli apparati nei Rack Ping, Descrizione, Velocità della Ventola di Raffreddamento, Temperatura Ambientale, Temperatura dell'acqua nel sistema di Raffreddamento, Uptime. UPS Gestione del Power Supply Descrizione, Carica Residua, Ping, Stato della Batteria, Temperatura, Autonomia Residua, Uptime, Voltaggio. Switches Gestione del traffico dati da e verso l'esterno Descrizione, Ping, Uptime, Utilizzo di Banda in Percentuale Ping, SSH, CPU Load, Percentuale di Memoria Utilizzata, Spazio disco utilizzato, Processi attivi, Traffico IP v4, traffico IP v6, traffico totale Numero di Processi Totale, numero di cores totale, numero di cores attivi, CPU info Tabella 2: Classi di apparati e parametri caratteristici Pagina 13 di 45

14 2.5. Definizione delle soglie per i servizi Una volta definiti i servizi da monitorare in base alle classi di apparati individuate bisogna scegliere le soglie warning e critical. Per soglia di warning indichiamo un valore del parametro la cui misura è più alta, o più bassa, rispetto ai valori di utilizzo normale, ma non ancora tale da essere una potenziale causa di problemi sull'apparato, condizione che si verifica invece una volta superato il valore critical. L'impostazione di soglie massime o minime dipende dalle caratteristiche del singolo apparato, dall'analisi del suo ruolo all'interno del data-center e dalle necessità emerse in fase di analisi dei requisti. Solo dopo aver discusso con gli utenti interessati si è potuto stabilire quali fossero le condizioni di pericolo e/o critiche che è necessario vengano notificate all'utenza. Nella loro definizione i valori assegnati alle soglie assumono un valore deciso in base all'osservazione dei dati di performance ottenuti dagli apparati in condizioni di utilizzo normali, a medio carico e a pieno carico. Per alcuni parametri non è stato ritenuto necessario impostare delle soglie in quanto essi non assumono valori variabili nel tempo. Le soglie individuate in fase di analisi del problema sono riepilogate nella seguente tabella: Pagina 14 di 45

15 Servizio Soglia di Warning Soglia Critica Note - - Informazioni sulla CPU (modello ecc.) 200 ms 600 ms - Uptime Ssh Carico della CPU 30,00% 90,00% Core Attivi 50,00% 10,00% Critico se i core non sono attivi Memoria utilizzata 80,00% 10,00% Critico se la memoria utilizzata è bassa, indice di nessuna attività della macchina Spazio disco libero 15,00% 5,00% - N processi in esecuzione N processi totale RPM 10 RPM - Temperatura Ambientale 35 C 60 C - Temperatura dell'acqua nel sistema di raffreddamento 40 C 60 C - Carica residua 25,00% 5,00% - Autonomia residua 59 min 9 min - Voltaggio 6.0 KV 7.0 KV - Banda utilizzata 50,00% 90,00% - N di job in coda - - Nessuna soglia, serve solo come dato statistico CPU Info Ping Velocità della Ventola di Raffreddamento Tabella 3: servizi e soglie Pagina 15 di 45

16 2.6. L'ambiente utilizzato: FAN (Fully Automated Nagios) In base a quanto ottenuto in fase di raccolta dei requisiti la scelta del software da utilizzare per il sistema di monitoraggio è caduta sull'ambiente FAN, ovvero Full Automated Nagios [2]. Questo particolare ambiente software integra al suo interno il sistema operativo CentOS e i tools Centreon, Nagios e Nagvis necessari ad implementare il sistema di monitoraggio. La scelta di questa soluzione è stata dettata da diversi fattori, primo fra tutti la necessità di avere un ambiente open-source che riuscisse a soddisfare i requisiti raccolti nella fase iniziale del lavoro. In particolare Nagios fornendo la possibilità di configurare gli account utente e di definire le operazioni che possono effettuare ci permette di soddisfare uno dei requisiti fondamentali, ovvero la profilatura degli utenti. La struttura basata sui plug-in ci permette poi di soddisfare il requisito della modularità: infatti aggiungere o eliminare funzionalità in questo caso si riduce ad aggiungere o rimuovere plug-in all'interno del sistema. I requisiti hardware e software non particolarmente esigenti ci permettono poi di realizzare l'obiettivo della facilità di manutenzione; come già detto, grazie alle poche risorse utilizzate, il sistema potrà essere messo in esercizio anche su una macchina virtuale e questo rende notevolmente più semplice la migrazione e il ripristino del sistema in caso di fault anche gravi. Terminata la fase di installazione avremo attivi tre software: Nagios: fulcro del sistema di monitoraggio Centreon: interfaccia web per la configurazione di Nagios Nagvis: Add-on per Nagios che ci permette di creare mappe e interfacce di navigazione per rappresentare la struttura del data-center Pagina 16 di 45

17 2.7. L'ambiente utilizzato: Nagios Nagios, come abbiamo già detto, rappresenta il fulcro del sistema di monitoraggio. Prima di iniziare ad utilizzarlo bisogna opportunamente configurare sia il server che le macchine da monitorare affinché il primo possa ricevere i dati richiesti dalle seconde. La soluzione ideale prevede l'installazione del demone NRPE (Nagios Remote Plugin Executor) e dei plugin da eseguire su ogni macchina da monitorare; in questo modo ogni host invia i suoi dati di performance al server, che li elabora e li mostra agli utenti. Questa scelta però potrebbe rappresentare un problema per la sicurezza dal momento che un malintenzionato potrebbe, una volta ottenuti i diritti di amministratore su una delle macchine, sostituire i plugin con un qualsiasi software malevolo e fargli eseguire operazioni non autorizzate. Un'alternativa più sicura, e per certi versi più efficiente, è quella di utilizzare i protocolli SNMP (Simple Net Management Protocol) ed LDAP (Lightweight Directory Access Protocol) allo scopo di collezionare le informazioni che ci interessano: in questo modo non bisogna eseguire alcun genere di codice sulla macchina host, ma il server effettua una semplice query (snmp o ldap) su di essa, che risponderà inviando a questo le informazioni richieste. Quest'ultima è la soluzione proposta di seguito; prima di descriverla nel dettaglio bisogna però fare una premessa: nei sistemi operativi Linux i protocolli SNMP ed LDAP non sono abilitati di default, prima di interrogare una macchina tramite query snmp quindi va verificato che i pacchetti relativi siano installati e configurati correttamente. In caso contrario non potremo ricevere i dati richiesti e il sistema di monitoraggio risulterà in uno stato indeterminato. Pagina 17 di 45

18 3. Implementazione del sistema di monitoraggio L'architettura del sistema di monitoraggio realizzato è basata su quanto esposto nel capitolo precedente; sulla macchina destinata a fare da server, dove è installato è CentOS 5.9, è stato poi installato (come già detto) Fully Automated Nagios. Sulla macchina server si è quindi realizzato un ambiente software integrato composto da: Nagios + plugins Centreon NagVis 3.1. Schematizzazione del sistema Volendo rappresentare il sistema sotto forma di schema a blocchi possiamo assumere come riferimento la figura seguente: Illustrazione 6: schema a blocchi del sistema di monitoraggio realizzato Pagina 18 di 45

19 Si nota subito che, seguendo le direttive specificate in fase di raccolta dei requisiti, l'accesso degli utenti al sistema è filtrato dall'utilizzo di Liferay Portal, che è utilizzato per integrare la web interface classica di FAN con il sito ufficiale del progetto ReCaS e sarà l'unico punto di accesso al sistema da parte degli utenti. Sappiamo già dalle specifiche di Nagios che la comunicazione fra il core e gli host monitorati avviene tramite plug-in; nel nostro caso oltre che dagli host necessitiamo di ricevere dati anche dai siti esterni legati al progetto. Per questi, che rappresentano in realtà siti di monitoraggio completamente indipendenti da quello di Napoli, le specifiche del progetto non prevedono l'accesso in maniera diretta alle macchine per gli utenti che non siano admin. Nel portale dovranno comunque essere mostrati i dati di performance provenienti da questi siti e per i quali insieme ai responsabili locali si sono definiti i criteri per la loro condivisione. Degli appositi script cattureranno l'output di entry point opportunamente configurati e che metteranno a disposizione tramite protocollo http i dati richiesti in formato XML Scelte implementative Per quello che riguarda lo sviluppo degli script di Nagios bisogna tenere presenti alcune regole fondamentali: 1. l'output deve essere una sola riga, nel formato: <testo> <performance data>. 2. Deve restituire in output un intero compreso fra 0 e 4 e rispettare la seguete convenzione [3]: 0 OK Il plug-in è riuscito a ottenere i dati richiesti e il servizio monitorato funziona correttamente 1 Warning Il plug-in è riuscito a ottenere i dati richiesti e il servizio monitorato presenta un problema non critico 2 Critical Il plug-in è riuscito a ottenere i dati richiesti e il servizio monitorato presenta un problema critico 3 Unknown Il plug-in non è riuscito a ottenere i dati richiesti Tabella 4: output di uno script Nagios e loro significato Pagina 19 di 45

20 Nagios non ci impone alcuna limitazione sul linguaggio di programmazione da utilizzare per lo sviluppo dei nostri plug-in se non quella di rispettare le linee guida appena descritte. La struttura del sistema da realizzare però ci costringe a una scelta: quella fra linguaggi compilati e linguaggi interpretati. Sebbene i primi siano in generale da preferire per questioni di efficienza del software, nel caso specifico si è scelto di utilizzare un linguaggio interpretato (in questo caso il Bash per realizzare script di shell Linux) in modo da garantire il corretto funzionamento del sistema anche in caso di una sua migrazione/replica su una architettura hardware/software diversa. Ad esempio, prendiamo il caso in cui si ha la necessità di utilizzare un nuovo server basato su una release Linux diversa da FAN; utilizzare dei file binari generati da un compilatore diverso da quello originario non garantirebbe il funzionamento del nostro software. Gli script realizzati hanno una struttura comune che ha origine da quanto detto a inizio paragrafo e si completa con ulteriori specifiche aggiunte per favorire la manutenzione del software e la lettura del codice da parte di sviluppatori esterni. Riassumendo, gli script realizzati si basano su quattro punti fondamentali: 1) Gli script utilizzano query SNMP per dialogare con gli hosts. 2) Uno script è composto da una parte di prelievo delle informazioni, una parte di elaborazione delle informazioni e una parte di presentazione dell'output. 3) La presentazione dell'output deve rispettare le regole descritte a inizio paragrafo. 4) Per rispettare lo standard imposto da Nagios, e per ridurre al minimo indispensabile il numero di parametri di ingresso, gli script realizzati hanno tutti il seguente prototipo: <nome dello script> <indirizzo IP della macchina interrogata> <soglia di warning> <soglia critica>. Pagina 20 di 45

21 3.3. Script Realizzati Una volta individuati servizi da monitorare, le soglie di warning e critical e definiti i criteri da seguire nello sviluppo degli script si è potuto passare alla scrittura del codice. In particolare sono stati realizzati i seguenti script, da utilizzare per il monitoraggio dei worker nodes: check_active_cores.sh Servizio: percentuale di cores attivi #!/bin/bash #Author: Salvatore Naddeo #usage:./check_active_cores.sh <ip address> <warning threshold> <critical threshold> #retrieving the number of inactive cores (if necessary, the snmp community must be set by #changing the following snmp call) inactive=`snmpwalk -Os -c n0npublic -v 2c $1 hrprocessorload grep ": 0" wc -l` #retrieving the total number of cores total_number=`snmpwalk -Os -c n0npublic -v 2c $1 hrprocessorload wc -l` #calculating the number of active cores number=$(($total_number - $inactive)) #calculating the percentage of active cores perc=`echo "($number / $total_number) * 100" bc -l` perc=${perc/.*} #preparing the output if [ $perc -ge $2 -a $perc -le $3 ]; then echo "CHECK WARNING - $perc of Active Cores active_cores=$perc" exit 1 fi if [ $perc -gt $3 ]; then echo "CHECK OK - $perc of Active Cores active_cores=$perc" exit 0 fi if [ $perc -lt $2 ]; then echo "CHECK CRITICAL - $perc of Active Cores active_cores=$perc" Pagina 21 di 45

22 exit 2 else echo "CHECK FAILURE - no active Cores detected" exit 3 fi check_core_number.sh Servizio: numero di cores sull'host #!/bin/bash #Author: Salvatore Naddeo #usage:./check_core_number.sh <ip address> #retrieving the total number of cores (if necessary, the snmp community must be set by changing the following snmp call) number=`snmpwalk -Os -c n0npublic -v 2c $1 hrprocessorload wc -l` #preparing the output if [ $number -gt 0 ]; then echo "CHECK OK - $number Cores Cores=$number" exit 0 else echo "CHECK FAILURE - no Cores detected" exit 3 fi Pagina 22 di 45

23 check_cpu_load.sh Servizio: carico della CPU #!/bin/bash #Author: Salvatore Naddeo #usage:./check_cpu_load.sh <ip address> <warning threshold> <critical threshold> #retrieving the information (if necessary, the snmp community must be set by changing the following snmp call) number=`snmpwalk -Os -c n0npublic -v 2c $ ` load=`echo ${number:18}` load1=(${load//./ }) #preparing the output if [ $load1 -ge $2 -a $load1 -le $3 ]; then echo "CHECK WARNING - 1min Load= $load% load=$load" exit 1 fi if [ $load1 -lt $2 ]; then echo "CHECK OK - 1min Load= $load% load=$load" exit 0 fi if [ $load1 -gt $3 ]; then echo "CHECK CRITICAL - 1min Load= $load% load=$load" exit 2 else echo "CHECK FAILURE - error in checkin cpu load" exit 3 fi Pagina 23 di 45

24 check_process_number.sh Servizio: numero di processi in esecuzione sull'host #!/bin/bash #Author: Salvatore Naddeo #usage:./check_process_number.sh <ip address> <warning threshold> <critical threshold> #retrieving the information (if necessary, the snmp community must be set by changing the following snmp call) n=`snmpwalk -Os -c n0npublic -v 2c $ ` n=${n:31} #preparing the output if [ $n -ge $2 -a $n -le $3 ]; then echo "CHECK WARNING - $n Active processes active_processes=$n" exit 1 fi if [ $n -lt $2 ]; then echo "CHECK OK - $n Active processes active_processes=$n" exit 0 fi if [ $n -gt $3 ]; then echo "CHECK CRITICAL - $n Active processes active_processes=$n" exit 2 else echo "CHECK FAILURE - error in checking active processes" exit 3 fi Pagina 24 di 45

25 check_traffic_in.sh Servizio: traffico IP in ingresso #!/bin/bash # Author: Salvatore Naddeo #usage:./check_traffic_in.sh <ip address> <version of ip protocol> #to retrieve the information if necessary, the snmp community must be set by changing the corresponding snmp call #check the ip protocol if [ "$2" == "v4" ]; then #retrieving the number of ipv4 packets received number=`snmpwalk -Os -c n0npublic -v 2c $1 ipsystemstatshcinreceives.ipv4 awk '{print $4}'` #wait a minute sleep 60 #retrieving the number of ipv4 packets received after one minute number1=`snmpwalk -Os -c n0npublic -v 2c $1 ipsystemstatshcinreceives.ipv4 awk '{print $4}'` elif [ "$2" == "v6" ]; then number=`snmpwalk -Os -c n0npublic -v 2c $1 ipsystemstatshcinreceives.ipv6 awk '{print $4}'` sleep 60 number1=`snmpwalk -Os -c n0npublic -v 2c $1 ipsystemstatshcinreceives.ipv6 awk '{print $4}'` fi #calculating the number of packets received in the last 60 seconds and the value in packets/s number3=`echo "$number1 - $number" bc` Pagina 25 di 45

26 number3=`echo "$number3/60" bc` #preparing the output if [ $number -gt 0 ]; then echo "CHECK OK - $number3 Packets/s Received packets/s=$number3" exit 0 else echo "CHECK FAILURE - no data received" exit 3 fi check_traffic_out.sh Servizio: traffico IP in uscita #!/bin/bash # Author: Salvatore Naddeo #usage:./check_traffic_out.sh <ip address> <version of ip protocol> #to retrieve the information if necessary, the snmp community must be set by changing the corresponding snmp call #check the ip protocol if [ "$2" == "v4" ]; then #retrieving the number of ipv4 packets transmitted number=`snmpwalk -Os -c n0npublic -v 2c $1 ipsystemstatshcouttransmits.ipv4 awk '{print $4}'` #wait for a minute sleep 60 #retrieving the number of ipv4 packets transmitted after one minute number1=`snmpwalk -Os -c n0npublic -v 2c $1 ipsystemstatshcouttransmits.ipv4 awk Pagina 26 di 45

27 '{print $4}'` elif [ "$2" == "v6" ]; then number=`snmpwalk -Os -c n0npublic -v 2c $1 ipsystemstatshcouttransmits.ipv6 awk '{print $4}'` sleep 60 number1=`snmpwalk -Os -c n0npublic -v 2c $1 ipsystemstatshcouttransmits.ipv6 awk '{print $4}'` fi #calculating the number of packets received in the last 60 seconds and the value in packets/s number3=`echo "$number1 - $number" bc` number3=`echo "$number3/60" bc` #preparing the output if [ $number -gt 0 ]; then echo "CHECK OK - $number3 Packets/s Transimtted packets/s=$number3 " exit 0 else echo "CHECK FAILURE - no data received" exit 3 fi Pagina 27 di 45

28 check_up_hosts.sh Servizio: numero di hosts attivi #!/bin/bash # Author: Salvatore Naddeo #usage:./check_up_hosts.sh on the nagios server #analyzing the nagios configuration file get the total number of hosts and the list of hosts number_of_hosts=`cat /etc/nagios/hosts.cfg grep "address" wc -l` hosts=`cat /etc/nagios/hosts.cfg grep "address"` array=(`echo $hosts tr " " "\n"`) tot=0 for i in "${array[@]}" #hosts that respond to the ping count as active do if [ $i!= "address" ]; then array1=(`echo $i tr "," "\n"`) number=0; for j in "${array1[@]}" do temp_number=`ping -c 1 $j grep "1 received" wc -l` if [ $temp_number -eq "1" ]; then number=1 fi done if [ $number -eq "1" ]; then tot=$(($tot+1)) fi fi done #preparing the ouput echo "CHECK OK - $tot HOSTS UP UP=$tot" exit Pagina 28 di 45

29 check_used_ram.sh Servizio: ram occupata #!/bin/bash #Author: Salvatore Naddeo #usage:./check_used_ram.sh <ip address> <critical threshold> <warning threshold> #retrieving the amount of total memory (if necessary, the snmp community must be set by changing the following snmp call) total_ram=`snmpwalk -Os -c n0npublic -v 2c $ sed 's/[^0-9]//g' ` #retrieving the amount of free memory (if necessary, the snmp community must be set by changing the following snmp call) free_ram=`snmpwalk -Os -c n0npublic -v 2c $ sed 's/[^0-9]//g'` total_ram=${total_ram:1} free_ram=${free_ram:1} #compute the percentage of used memory perc=`awk 'BEGIN{printf("%0.2f", ('$total_ram' - '$free_ram') / '$total_ram' * 100)}'` percint=`echo $perc awk -F. '{print $1}'` #preparing the output if [ $percint -ge $2 -a $percint -le $3 ]; then echo "CHECK WARNING - used memory: $perc% perc=$perc" exit 1 fi if [ $percint -gt $3 ]; then echo "CHECK OK - used memory: $perc% perc=$perc" exit 0 fi if [ $percint -lt $2 ]; then echo "CHECK CRITICAL - used memory: $perc% perc=$perc" exit 2 Pagina 29 di 45

30 else echo "CHECK FAILURE - no data received" exit 3 fi Pagina 30 di 45

31 4. Test degli script e configurazione dei servizi: un esempio pratico 4.1 Test degli Script Una volta realizzati gli script descritti nel capitolo precedente è stata necessario eseguire alcuni test in modo da verificarne il corretto funzionamento. Solo dopo l'esito positivo di questa fase si è potuto procedere con la configurazione dei relativi servizi in Centreon. Come caso di studio valido per tutti i servizi monitorati prendiamo lo script check_used_ram.sh, che mostra la percentuale di memoria utilizzata dall'host, ed effettuiamo qualche test di funzionamento su di esso tenendo però presente quanto descritto nella tabella 3, che al momento dei test il worker node in questione non era impegnato in alcun esperimento e che i dati ottenuti non rispecchiano risultati che ci si attenderebbero da una macchina a pieno carico. Dopo aver reso eseguibile lo scritp, tramite il comando chmod +x check_used_ram.sh da riga di comando eseguiamo le seguenti istruzioni: in output abbiamo critical in quanto la memoria occupata è minore della soglia critical, cosa che nel caso specifico indica scarso utilizzo della risorsa ed un potenziale problema da gestire. Proviamo adesso a cambiare le soglie: Avendo abbassato leggermente la soglia minima e con il dato ottenuto compreso fra le due soglie l'ouput è warning. Modifichiamo ulteriormente le soglie in modo che l'output ottenuto superi la soglia massima prevista:in questo caso l'output dello script è ok, in quanto la memoria occupata è maggiore della soglia warning. Pagina 31 di 45

32 4.2 Configurazione dei servizi in Centreon Verificato il corretto funzionamento dello script passiamo alla fase di configurazione del servizio corrispondente in Centreon. Il primo passo da effettuare è l'assegnazione dei permessi di esecuzione all'utente Nagios; la sequenza di comandi da eseguire è: chmod +x <nome dello script> chown nagios:nagios <nomedello scritp>. In questo modo abbiamo reso lo script eseguibile e ne abbiamo impostato come proprietario l'utente nagios del gruppo nagios. A questo punto possiamo creare il comando con la sicurezza che solo il core di Nagios potrà lanciarne l'esecuzione: in essa vanno inseriti il percorso del file eseguibile corrispondente e i parametri da passargli. E' da sottolineare l'utilizzo dello script check_multiaddr.pl, [4] script in Perl che ci permette di superare uno dei limiti di Nagios/Centreon, ovvero quello di poter interrogare solo uno degli indirizzi IP associati ad un host; se gli host hanno più Pagina 32 di 45

33 interfacce di rete, come nel nostro caso, non è possibile sapere quale risponderà alle richieste che arrivano. Dal momento che nulla ci da la sicurezza circa quale di esse sia attiva bisogna trovare il modo di aggirare il problema ed interrogare tutti gli IP associati a un determinato host. Aggiungendo alla riga di comando lo script in questione riusciamo ad ottenere questa funzionalità aggiuntiva e a tenere traccia di tutte le interfacce di rete configurate sugli hosts. Una volta creato il comando passiamo alla configurazione del servizio; i passi da seguire sono la sua creazione: e l'associazione di esso agli hosts su cui vogliamo monitorare il servizio: Pagina 33 di 45

34 Questa fase di configurazione è estremamente importante perchè ci permette di associare i servizi agli hosts in maniera tale da rispettare quanto descritto nella tabella 2 e realizzare la suddivisione in classi di apparati non solo dal punto di vista logico ma anche dal punto di vista implementativo [5]. Per rendere effettiva la configurazione bisogna riavviare il core di Nagios. Una volta che la configurazione sarà validata e funzionante potremo vedere comparire i primi dati all'interno delle interfacce web di Centreon e Nagios. Illustrazione 10: stato dei servizi in Nagios (1) A seguito del riavvio del core di Centreon la schermata principale di Nagios si presenterà con questo aspetto: notiamo come lo stato del servizio Used Memory per l'host in osservazione è Critical perchè la macchina utilizza solo il 6.37% della memoria, un valore che indica scarso utilizzo della risorsa e che per quanto esposto in precedenza rappresenta una situazione di potenziale pericolo. La schermata sarà diversa se l'host invece sta lavorando su un qualsiasi task abbastanza impegnativo; in quel caso infatti avremo la seguente schermata dei servizi Pagina 34 di 45

35 Illustrazione 11: stato dei servizi in Nagios (2) in cui il servizio Used Memory è OK. Pagina 35 di 45

36 5. Conclusioni 5.1 Panoramica sul sistema realizzato La home page del sistema integrato nel portale ufficiale del Progetto ReCaS si presenta all'utente in questo modo: Illustrazione 12: home page del portale monitoraggio ReCaS Questa la vista del sistema al più alto livello di astrazione possibile; da questa saranno visibili tutte le informazioni generali sull'infrastruttura di calcolo ReCaS. Illustrazione 13: panoramica del sito ReCaS Napoli Pagina 36 di 45

37 Cliccando sull'icona del singolo sito si può accedere invece alla pagina specifica, come mostrato nella figura precedente. Da questa schermata si potrà scendere ancora più nel dettaglio se necessario, sempre tenendo presente quanto deciso in fase di progettazione circa i permessi utente e le operazioni ad esso associate. Dal punto di vista dell'utente admin sono inoltre disponibili le funzionalità di amministrazione di Centreon, attualmente accessibili tramite la web interface di FAN e che permettono di operare sui servizi in maniera diretta nel caso fosse necessario. In questo caso i punti di accesso a disposizione dell'admin sono due: la homepage di Nagios e quella di Centreon. La prima permette di vedere nel dettaglio lo stato dei singoli hosts e dei singoli servizi monitorati, la seconda include oltre a queste funzionalità anche la visualizzazione di grafici basati sui dati di performance ottenuti e la creazione/configurazione di hosts, comandi e servizi. Ad esempio, mantenendo come riferimento il servizio Used Memory i grafici visualizzati saranno di questo tipo: Illustrazione 14: grafici di performance giornalieri e settimanali per il servizio Used Memory Pagina 37 di 45

38 Illustrazione 15: schermata admin di Centreon L'admin potrà anche accedere alla web-interface di Centreon, che mosterà le informazioni in maniera aggregata come mostrato di seguito: In definitiva quindi gli utenti admin potranno accedere al sistema tramite due diverse interfacce web, sostanzialmente equivalenti dal punto di vista delle informazioni visualizzate ma con diversi utilizzi se si considera l'aspetto di configurazione del sistema. C'è poi una terza via, esclusivamente grafica, cioè Nagvis: anche se incapsulata all'interno del portale Liferay anche quest'ultima interfaccia è accessibile direttamente tramite browser web per gli utenti che non hanno interesse ad utilizzare il portale ufficiale del progetto ReCaS. Pagina 38 di 45

39 5.2 Conclusioni e sviluppi futuri Da quanto descritto in precedenza si può affermare che il sistema realizzato ci permette di soddisfare i requisiti individuati in fase di progettazione e che la soluzione proposta è quella che più si avvicina a quanto richiesto dagli utenti. In particolare abbiamo ottenuto modularità e facilità di manutenzione: come si può vedere aggiungere e modificare servizi si riduce a una semplice importazione di script da testare indipendentemente rispetto al core del sistema vero e proprio. Questo aspetto ci facilita molto il compito in quanto uno script viene inserito nel sistema solo dopo aver passato i test ad esso relativi, che vengono eseguiti senza interessare minimamente il sistema. Procedere secondo questo criterio ci permette di ridurre al minimo il rischio di far eseguire al sistema script potenzialmente dannosi e/o con bug noti e riduce sensibilmente i rischi legati a malfunzionamenti legati a software instabile. Il problema della profilatura degli utenti viene risolto invece grazie sia agli strumenti di Centreon che grazie all'ulteriore strato di sicurezza introdotto da Liferay al momento in cui i portali vengono integrati fra loro. Questa combinazione ci permette di raggiungere un grado di sicurezza degli accessi ragionevolmente alto, anche se non ancora perfetto. Nel prossimo futuro il sistema andrà però completato e raffinato: innanzitutto dovranno essere implementati tutti i servizi previsti dall'analisi dei requisiti e che allo stato attuale del lavoro ancora mancano. Si dovrà poi lavorare ulteriormente sulla gestione degli accessi al portale in modo da rendere le operazioni di login/logout meno macchinose e più trasparenti agli utenti; la possibilità di accedere al sistema da più indirizzi web rappresenta infatti un problema sia per la sicurezza che per la navigabilità del sistema ed è auspicabile che il tutto venga reso accessibile in maniera univoca per evitare potenziali pericoli e fornire una migliore esperienza di navigazione agli utenti. Pagina 39 di 45

40 Anche per quanto riguarda la veste grafica il lavoro dovrà essere raffinato e completato in modo da rappresentare correttamente la struttura del datacenter e permettere agli utenti una navigazione all'interno della mappa che sia esaustiva e consenta di esplorare il sistema distribuito ReCaS nella sua interezza. Pagina 40 di 45

41 Appendice: dettagli Hardware del Data Center Pagina 41 di 45

42 Pagina 42 di 45

43 Pagina 43 di 45

44 Pagina 44 di 45

45 Bibliografia 1: L.Merola, riunione di gruppo I Napoli, : fullyautomatednagios.org, Fan User Guide, 3: Nagios Plugins Development Team, Nagios Plugin Developement Guide, 4: Nagios Exchange, Metaplugin used to check a service avalaible trough different IP addresses, 5: Centreon Official Site, Centreon User Guide, Pagina 45 di 45