Un Framework per la valutazione delle statistiche di esercizio della rete wireless di Ateneo "Wifi-Unina"

Università degli Studi di Napoli Federico II

Facoltà di Scienze MM.FF.NN.
Corso di Laurea in Informatica

Tesi Sperimentale di Laurea Triennale

Un Framework per la valutazione delle statistiche di esercizio
della rete wireless di Ateneo “Wifi-Unina”

Relatori Candidato
Prof. Guido Russo Paolo Vanacore
Dr. Ing Catello Di Martino Matricola: 566/1539

Anno accademico 2009/2010

Desidero ringraziare...

...il Prof Guido Russo e l'Ing. Catello Di Martino
per avermi consentito di svolgere questo lavoro di tesi
e per il costante supporto umano e professionale,

...la mia famiglia ed in particolare i miei genitori
per il sostegno e la fiducia che mi hanno consentito
di intraprendere questo percorso,

...Paola per avermi sostenuto in ogni attimo,
anche nei momenti più difficili,

...tutti gli amici del corso di studi, dello SCoPE e di vita.

Paolo Vanacore 566/1539 Pagina 2 di 279

Indice generale
1 Introduzione..........................................................................................................................5
2 La rete wireless di Ateneo: “Wifi-Unina”.............................................................................7
2.1 Topologia Di Rete..........................................................................................................7
2.2 Apparati Di Rete..........................................................................................................10
2.3 Dati Generali Sull'infrastruttura Di Rete Wireless......................................................17
2.3.1 Infrastruttura di Monte Sant'Angelo..................................................................21
2.3.2 Infrastruttura del Centro Storico........................................................................22
2.3.3 Infrastruttura del Policlinico..............................................................................24
3 Monitoraggio di rete............................................................................................................26
3.1 Il Protocollo SNMP: Simple Network Management Protocol....................................27
3.2 Cacti.............................................................................................................................32
3.3 RRDTool: Round-Robin Database Tool......................................................................36
4 L'applicazione realizzata.....................................................................................................46
4.1 Requisiti ......................................................................................................................46
4.2 Architettura Generale..................................................................................................49
4.3 Accesso Ai Dati Di Monitoraggio...............................................................................51
4.3.1 Server di monitoraggio: Il Data Server..............................................................52
4.3.2 Il Data Client.....................................................................................................54
4.3.2.1 Parsing di XML dump file.....................................................................54
4.3.2.2 Il database RRDB..................................................................................56
4.4 Logica Di Controllo Per La Gestione Dei Dati...........................................................60
4.4.1 Servizi di amministrazione dei dati...................................................................61
4.4.2 Temporizzazione delle letture degli rrd.............................................................62
4.4.3 Monitor e Report Statistici: il Design Pattern Observer....................................64
4.5 Presentazione Dei Dati................................................................................................66
4.5.1 Model 1..............................................................................................................67
4.5.2 Model 2 e Design Pattern MVC........................................................................69
4.5.3 JFreeChart..........................................................................................................73
4.6 Architettura Completa.................................................................................................76
5 Guida d'uso dell'applicazione realizzata.............................................................................77
5.1 Interfaccia Di Amministrazione..................................................................................77
5.1.1 Gestione dei Data Server...................................................................................81
5.1.2 Gestione dei Report statistici.............................................................................85
5.1.3 Le briciole di pane.............................................................................................86
5.2 Interfaccia Di Visualizzazione Dei Grafici..................................................................87
6 Considerazioni e conclusioni..............................................................................................91
7 Appendici............................................................................................................................93
7.1 Messa In Esercizio Del Framework............................................................................93
7.1.1 Data Server........................................................................................................93
7.1.2 Data Client.........................................................................................................95


7.1.3 Interfaccia di amministrazione..........................................................................96
7.1.4 Interfaccia di visualizzazione dei grafici...........................................................97
7.2 Diagrammi...................................................................................................................99
7.2.1 UML – Use Case Diagrams...............................................................................99
7.2.2 UML – Component Diagrams.........................................................................100
7.2.3 UML – Class Diagrams...................................................................................101
7.2.4 UML – Sequence Diagrams.............................................................................111
7.2.5 UML – Statechart.............................................................................................114
7.2.6 EER Diagram...................................................................................................115
7.3 Documentazione JavaDoc.........................................................................................116
7.4 Codice Sorgente.........................................................................................................116
7.4.1 it.unina.scope.wistat.dataclient........................................................................116
7.4.2 it.unina.scope.wistat.dataclient.database.........................................................136
7.4.3 it.unina.scope.wistat.dataclient.net..................................................................144
7.4.4 it.unina.scope.wistat.dataclient.rrd..................................................................162
7.4.5 Files di configurazione DataClient..................................................................170
7.4.6 it.unina.scope.wistat.dataserver.......................................................................171
7.4.7 it.unina.scope.wistat.dataserver.database.........................................................175
7.4.8 it.unina.scope.wistat.dataserver.net.................................................................176
7.4.9 Files di configurazione DataServer.................................................................183
7.4.10 Script SQL per la creazione del database rrdb...............................................184
7.4.11 WiStat – bean.................................................................................................192
7.4.12 WiStat – controller (Servlet)..........................................................................202
7.4.13 Wistat – database...........................................................................................206
7.4.14 WiStat – JSP..................................................................................................210
7.4.15 Files di configurazione dell'interfaccia WiStat..............................................214
7.4.16 WiStatAdmin – bean......................................................................................216
7.4.17 WiStatAdmin – controller (Servlet)...............................................................225
7.4.18 WiStatAdmin – JSP.......................................................................................250
7.4.19 Files di configurazione dell'interfaccia WiStatAdmin...................................274
8 Bibliografia e Sitografia....................................................................................................278


1 Introduzione

Una corretta valutazione dello stato di un sistema complesso è alla base del processo di
manutenzione, gestione ed evoluzione del sistema stesso. Ne consegue la necessità di
fornire adeguati strumenti che ne consentano valutazioni corrette.
Il monitoraggio, inteso come strumento di rappresentazione dello stato di un sistema,
svolge, quindi, un ruolo di primaria importanza per la vita ed evoluzione del sistema
stesso.
In tale contesto il sistema è rappresentato dalla rete wireless di Ateneo “WiFi-Unina” e
gli strumenti da realizzare consistono in un framework per la valutazione delle
statistiche di esercizio della stessa.
Su tali considerazioni si basa il lavoro di tesi che si colloca nell'ambito dell'iniziativa
“WiFi SUD” del progetto “ICT4University” che realizza quanto previsto dall'obiettivo
Università del Piano E-Gov 2012. In particolare l'iniziativa ha previsto il
finanziamento di progetti delle Università del Sud per realizzare, estendere o
completare reti di connettività senza fili e sviluppare servizi online di tipo
amministrativo e/o didattico, accessibili gratuitamente da parte degli studenti.
Il framework realizzato consta di due principali sottosistemi:
• il sottosistema di monitoraggio per la raccolta di informazioni sugli apparati
di rete;
• il sottosistema per la definizione e la rappresentazione di statistiche.
Per il monitoraggio è stato utilizzato il software open source Cacti. Tale applicativo
costituisce un sistema completo per il monitoraggio passivo di apparati di rete,
offrendo tutti gli strumenti necessari per interrogazioni SNMP (Simple Network
Management Protocol).
Per quanto riguarda il sottosistema per le statistiche, è stata realizzata un'applicazione
che consente, attraverso interfaccia web, di definire report statistici a partire dai dati


frutto di monitoraggio. L'applicazione ha un'architettura client/server multithread e ciò
consente di avere uno o più server di monitoraggio con una gestione centralizzata dei
dati di interesse.
Tra le problematiche affrontate le più rilevanti riguardano l'accesso ai dati di
monitoraggio e la gestione di report statistici.
L'accesso ai dati ha richiesto lo studio di uno degli strumenti software open source
maggiormente utilizzati nell'ambito del monitoraggio di sistemi in genere, del quale
Cacti è considerato una GUI user friendly: RRDTool. Buona parte del data layer del
framework realizzato riguarda proprio l'interazione con RRDTool, al fine di replicare i
dati di monitoraggio in un database realizzato su DBMS MySQL e poterli così
consolidare per mezzo di funzioni statistiche. Particolare attenzione è stata data,
quindi, all'accesso, coerenza e persistenza dei dati di monitoraggio.
L'applicazione per le statistiche è interamente scritta in linguaggio Java per consentire
un'alta portabilità.
Tra le principali tecnologie adottate vi sono:
• Parser Document Object Model, istruzioni XPath e parser Simple API for XML
per i files XML;
• Java DataBase Connectivity per le connessioni ai database MySQL;
• Java Server Pages, Servlet e JavaBeans per la presentazione dei dati;
• Libreria JFreeChart per la creazione di grafici.


2 La rete wireless di Ateneo: “Wifi-Unina”

2.1 Topologia di rete

Seguendo un approccio top-down nella descrizione della topologia di rete, una prima
classificazione si basa sulle principali sedi di Ateneo che costituiscono tre sotto-domini
(fig. 2.1.1):
• Monte Sant'Angelo;
• Centro Storico;
• Policlinico.

Fig. 2.1.1 – le tre principali sedi di Ateneo (immagine ottenuta da Google Eearth ).


Queste sedi sono interconnesse per mezzo della rete metropolitana (MAN –
Metropolitan Area Network) che, attraverso un cablaggio in fibra ottica, offre
collegamenti a 2.4 Gigabit (Packet over SONET – Synchronous Optical NETwork).
Scendendo nella gerarchia e considerando unicamente i nodi di interesse, una
descrizione più dettagliata è data dalla suddivisione in strutture e facoltà (fig. 2.1.2).

Centri Comuni

Aulario A

Monte Sant'Angelo Dipartimento di Chimica

Dipartimento di Matematica

Biblioteche

Agnano Edificio

Edificio 1

Via Claudio Edificio 3
Ingegneria
Edificio 5

Piazzale Tecchio Edificio

Mezzocannone
Centro Storico
S.Antoniello

Edificio 01 Edificio 04 Edificio 05 Edificio 08

Edificio 09 Edificio 10 Edificio 11 Edificio 12

Policlinico Edificio 13 Edificio 14/15 Edificio 17 Edificio 18

Edificio 19 Edificio 20 Edificio 21 Ed. 22 (Mensa)

Fig. 2.1.2 – schema gerarchico della topologia logica di rete in basato sulle sedi


Per non appesantire lo schema precedente sono state omesse le ulteriori classificazioni
delle strutture in piani/livelli derivanti dal cablaggio strutturato.
Come si evince dalla fig. 2.1.2, la sede di Monte Sant'Angelo costituisce il nodo
principale della rete. Il POP (Point Of Presence – punto di connessione fisica tra reti
di telecomunicazione) di Monte Sant'Angelo, infatti, offre e gestisce l'accesso da e
verso diverse reti e servizi, con connessioni da 1GbE fino a 10GbE, tra cui:
• accesso alla rete GARR
Rete Italiana per la ricerca nata nel 1977 e gestita dal Consortium GARR
(Gruppo per l'Armonizzazione delle Reti della Ricerca). Diversi sono gli enti
che afferiscono a tale consorzio, tra cui i fondatori:
▪ CNR (Consiglio Nazionale delle Ricerche);
▪ ENEA (Ente per le Nuove Teconologie, l'Energia e l'Ambiente);
▪ INFN (Istituto Nazionale di Fisica Nucleare);
▪ Fondazione CRUI (Conferenza dei Rettori delle Università Italiane) in
rappresentanza delle Università Italiane.
• griglie computazionali (GRID):
▪ SCOPE (Sistema Cooperativo distribuito ad alte Prestazioni per
Elaborazioni scientifiche multidisciplinari – infrastruttura di
supercomputing general purpose basata su GRID e calcolo distribuito in
genere);
▪ GRISU' (Griglia del Sud – infrastruttura distribuita a carattere
multidisciplinare);
▪ ATLAS (griglia nata nell'ambito dell'esperimento A Toroidal LHC
Apparatus presso l'acceleratore Large Hadron Collider del CERN di
Ginevra).


Limitando il discorso alla rete wireless di Ateneo, considerata la complessità e la
vastità della stessa, un aspetto particolarmente importante, dal punto di vista
progettuale, è sicuramente la scalabilità.
Nei successivi paragrafi vengono descritte le soluzioni architetturali adottate
evidenziando come queste ultime sostengono tale caratteristica.
In particolare vengono considerati i seguenti tipi di scalabilità:
• scalabilità di carico
Capacità di scalare sul carico, inteso come mole di traffico/numero di utenti;
• scalabilità geografica
Capacità di estensione fisica della rete;
• scalabilità amministrativa
Capacità di mantenere inalterata la gestibilità all'evolversi della rete.

2.2 Apparati di rete

Ognuna delle tre principali sedi di Ateneo (Monte Sant'Angelo, Centro Storico e
Policlinico) costituisce un sotto-dominio della rete.
La totalità degli apparati sono prodotti dalla Cisco ed offrono una soluzione completa
per la realizzazione e gestione di reti WLAN (Wireless Local Area Network). In
particolare, considerando ogni sotto-dominio come una WLAN autonoma,l'architettura
adottata è gerarchica (fig. 2.2.1) e costituita da tre principali tipologie di apparati:
• WLSE (Wireless Lan Solution Engine);
• WDS (Wireless Domain Service);
• AP (Access Point).


WLSE
sottodominio i

WDS1 WDS2 WDSn
Infrastructure APs Infrastructure APs Infrastructure APs
(registered on WDS 1) (registered on WDS 2) (registered on WDS n)

AP1 AP2 APx AP1 AP2 APy AP1 AP2 APz

Fig. 2.2.1 – apparati attivi di un generico sotto-dominio di rete

Tale soluzione architetturale è conosciuta con il nome di “Cisco SWAN” (Structured
Wireless-Aware Network). Il programma SWAN della Cisco mira ad integrare vari
componenti di rete al fine di fornire WLAN di qualità.
Gli obiettivi, dichiarati dalla Cisco, di tale programma, sono principalmente i seguenti:
• Integrazione dei servizi wired e wireless per mezzo di infrastrutture sia
hardware che software (Cisco IOS Software) proprietarie;
• Semplificazione della gestione di numerosi punti d'accesso, consentendo un
accesso centralizzato e da remoto;
• Monitoraggio e scansione di radio frequenze;
• Alta disponibilità della LAN (Local Area Network) per mezzo di processi di
auto-diagnosi e “self-healing” (auto-guarigione) come la rilevazione,
individuazione ed isolamento di interferenze di rete;
• Gestione dei servizi di autenticazione ed autorizzazione secondo lo standard
IEEE 802.1X. In particolare tale aspetto è garantito da un server RADIUS


(Remote Authentication Dial-In User Service).
RADIUS è un protocollo del tipo AAA (Authentication Authorization
Accounting) con il compito, quindi, di realizzare le tre funzioni di:
▪ autenticazione (authentication);
▪ controllo degli accessi (authorization);
▪ tracciamento del consumo delle risorse da parte degli utenti
(accounting).

Come si evince dalla figura 2.2.1, ogni sotto-dominio i della rete è dotato di un WLSE
(fig. 2.2.2). Il WLSE può essere paragonato ad un vero e proprio server che offre
molteplici servizi di gestione per tutti gli apparati del sotto-dominio a suo carico. In
particolare, le caratteristiche principali del WLSE sono le seguenti:
• gestione centralizzata della WLAN;
• rilevamento ed individuazione di connessioni non autorizzate (Intrusion
Detection);
• rilevamento di interferenze radio;
• monitoraggio delle prestazioni (Reports);
• sistema di configurazione dei punti d'accesso automatizzato.

Fig. 2.2.2 – esempio di Cisco WLSE 1130

In figura 2.2.3 è riportata una schermata dell'interfaccia web del WLSE di Monte
Sant'Angelo dalla quale è possibile notare la mole di funzionalità offerte che spaziano


dai servizi di configurazione a quelli di monitoraggio ed allarmistica.
Per una gestione ancor più completa dell'intera WLAN, è degno di nota il “Location
Manager”. Tale applicazione, accessibile sempre dall'interfaccia web del WLSE, si
presenta come un' applet JAVA che consente, previa configurazione, di visualizzare le
planimetrie delle strutture che ospitano la WLAN, la precisa ubicazione e gli stati di
esercizio di ogni singolo apparato (fig. 2.2.4).

Fig. 2.2.3 – interfaccia web del WLSE di Monte Sant'Angelo


Fig. 2.2.4 – il Location Manager del WLSE di Monte Sant'Angelo. A destra la planimetria del Livello
0 dei Centri Comuni con l'esatta ubicazione degli Access Point (in verde)

Sempre in riferimento all'architettura Cisco SWAN, il secondo e terzo livello
gerarchico sono occupati dai WDS ed AP.
I WDS, fisicamente, sono AP settati in una particolare modalità che conferisce loro lo
stato di Wireless Domain Services. Il principale scopo di tale configurazione è quello
di definire un'infrastruttura di AP.
Un certo numero di AP vengono registrati ad un WDS andando così a costituire
un'infrastruttura gestita, dal punto di vista dei servizi di rete, dal WDS stesso.
Tra i principali vantaggi che tale soluzione offre vi sono:
• riduzione del tempo richiesto per le autenticazioni dei client attraverso un
processo, quando possibile, locale.
In particolare il processo di autenticazione prevede che le credenziali vengano
inviate da un AP al WDS cui è registrato. Nel caso di prima autenticazione da
parte del client nell'infrastruttura a carico del WDS, quest'ultimo ne verifica le


credenziali attraverso comunicazione con un server RADIUS, ed infine
memorizza le stesse in cache. Con tale strategia di caching, le successive fasi di
autenticazione del client nell'infrastruttura risultano più veloci non necessitando
di interazioni con il server RADIUS;
• assegnazione dello stato di WDS definito come processo autonomo all'interno
dell'infrastruttura.
Gli AP possono eleggere il miglior dispositivo da definire come WDS. Questo
meccanismo si basa sulla valutazione di diversi parametri come, ad esempio, il
carico di lavoro. È inoltre possibile definire un dispositivo candidato come
WDS principale ed uno o più dispositivi candidati come WDS di backup;
• Raccolta dei dati di funzionamento in maniera aggregata.
Tutti i dati di funzionamento degli apparati possono essere mantenuti e gestiti
in maniera centralizzata sul WDS dell'infrastruttura;

Il ruolo degli AP, infine, è quello di offrire, agli utenti provvisti di dispositivi mobili,
l'accesso alla rete WLAN.
I modelli di AP della rete sono due: Cisco Aironet 1210 e Cisco Aironet 1240
(fig. 2.2.5).

Fig. 2.2.5 – Cisco Aironet 1240


Gli AP della serie 1240 supportano la modalità WDS.
Le caratteristiche salienti di questi ultimi sono le seguenti:

Fino a 108 Mbps e compatibilità con client
Standard 802.11a ed 802.11g
802.11b.

Doppio connettore per antenne RP-TNC Antenne da 2,4 a 5 Ghz.

Funzionamento come Access Point o come
Modalità
Bridge.

Cisco IDS/IPS. Funzionalità software Cisco per la
sicurezza wireless.
Rilevamento Spoofing.
Autenticazione: WPA, WPA2, Cisco TKIP,WEP
Sicurezza e protezione a 40b e 128b, autenticazione EAP-FAST, PEAP-
GTC, PEAP-MS-CHAP, EAP-TLS, EAP-TTLS,
EAP-SIM, Cisco LEAP.
Crittografia: AES-CCMP (WPA2), TKIP(WPA),
Cisco TKIP, WPA TKIP, WEP a 40b e 128b.

Supporto fino a 12 canali non sovrapposti e,
potenzialmente, fino a 23 canali.
Varie
Alimentazione PoE IEEE 802.3af.

RAM da 32MB.
Memoria
16MB di memoria flash.

Consumi 12,95W massimo.

Cisco IOS.
Software
Cisco Unified Wireless Network Software.


2.3 Dati generali sull'infrastruttura di rete wireless
Nella figura a seguire viene mostrato lo stato di avanzamento dei lavori della rete
wireless di Ateneo. Questi dati sono stati prelevati dal sito www.ict4university.gov.it
che riporta lo stato di avanzamento dei progetti di ogni singola Università che
partecipa al progetto. In particolare, di seguito, vengono mostrati i dati relativi al
progetto “WiFi SUD” limitatamente all'Università Federico II.

Fig. 2.3.1 – stato attuale dei lavori in riferimento all'iniziativa “WiFi SUD”.
Dati prelevati dal sito: www.ict4university.gov.it


I seguenti grafici sono stati realizzati a partire dai dati rilevati dai WLSE in data
12/01/2010. È importante notare che tali dati risultano essere delle stime indicative
della reale ed attuale struttura della rete, in quanto la loro produzione non è totalmente
automatizzata. In particolare la categorizzazione degli AP e l'inserimento di nuovi
apparati, ad esempio, è a carico del personale tecnico-amministrativo.

Distribuzione AP per zona
Ubicazione Numero AP
Centro Storico 218
Monte Sant'Angelo 307
Policlinico 73
Totale 598

12,21%
36,45%
Centro Sto-
rico
MSA
Policlinico
51,34%

Tipologia AP
Modello AP Quantità
Cisco Aironet 1210 321
Totale 598

46,32%
53,68%
Cisco Aironet
1210
Cisco Aironet
1240


Distribuzione Subnet

Ubicazione Numero Subnet
Centro Storico 19
Policlinico 2
Totale 37

5,41%
Centro Sto-
51,35% 43,24% rico
MSA
Policlinico

Tipologie IP

IP Pubblico IP Privato Totali
Subnet 13 24 37
Apparati 378 244 622

IP Pubblici
64,86% IP Privati
39,23%
IP Privati

60,77%
100 35,14%
IP Pubblici
50

0
Subnet Apparati


Percentuale WDS attivi/di backup

Stato Numero WDS
WDS Attivi 25
WDS di Backup 24
Totale 49

51,02% 48,98%
WDS Attivi
WDS
Backup

Distribuzione WDS

Ubicazione Numero WDS
Centro Storico 26
Policlinico 4

8,16%

53,06% Centro Storico
38,78%
MSA
Policlinico

Dai dati rilevati si evince un'alta concentrazione di Access Point nella sede di Monte
Sant'Angelo, seguita dal Centro Storico e quindi dal Policlinico. È inoltre interessante
notare come il rapporto dei WDS, effettivamente di 1:1, presenta un WDS attivo in più
rispetto a quelli di backup. Ciò può essere dovuto al malfunzionamento di un WDS di
backup o alla caduta di uno attivo che ha comportato il passaggio di un WDS dallo
stato di backup allo stato attivo.


2.3.1 Infrastruttura di Monte Sant'Angelo

Tipologia AP

Totale 307

40,72%
Cisco Ai-
ronet 1210
59,28% Cisco Ai-
ronet 1240

Tipologie IP

Subnet 7 9 16

IP Pubblici
56,25% IP Privati
39,63%
IP Privati

60,37%
100 43,75%
IP Pubblici
50

0
Subnet Apparati



Stato Numero WDS
WDS Attivi 9
WDS di Backup 10
Totale 19

47,37% 52,63%

WDS Attivi
WDS Backup

2.3.2 Infrastruttura del Centro Storico

Tipologia AP

Totale 218

43,12%
Cisco Aironet
1210
56,88% Cisco Aironet
1240


Tipologie IP

Subnet 4 15 19

78,95% IP Pubblici
51,33% IP Privati
IP Privati

48,67%
100 21,05%
IP Pubblici
50

0
Subnet Apparati


Stato Numero WDS
WDS Attivi 14
WDS di Backup 12
Totale 26

46,15%
53,85%

WDS Attivi
WDS Backup


2.3.3 Infrastruttura del Policlinico

Tipologia AP

Totale 73

1,37%

Cisco Aironet
1210
Cisco Aironet
1240

98,63%

Tipologie IP

Subnet 2 0 2
Apparati 73 0 73

100
80
100,00% 100,00% IP Pubblici
60
IP Privati
40
20
0
0,00% 0,00%
IP Privati

IP Pubblici

Subnet Apparati



Stato Numero WDS
WDS Attivi 2
WDS di Backup 2
Totale 4

50,00% 50,00%

WDS Attivi
WDS Backup


3 Monitoraggio di rete

Una corretta valutazione dello stato di un sistema complesso è alla base del processo di
manutenzione, gestione ed evoluzione del sistema stesso. Da questa considerazione
nasce la necessità di fornire adeguati strumenti che consentano valutazioni corrette.
Il monitoraggio, inteso come strumento di rappresentazione dello stato di un sistema,
svolge quindi un ruolo di primaria importanza nella vita ed evoluzione del sistema
stesso. Le informazioni che un sistema di monitoraggio deve fornire devono quindi
risultare esatte e rilevanti.
Al fine di caratterizzare lo stato della rete è opportuno isolarne le principali entità:

Entità Esempi di parametri caratterizzanti
Utente Numero di utenti connessi.
Stato (attivo/non attivo);
Up Time;
Apparato (WDS/AP)
Consumi;
Velocità di connessione.
Dati di funzionamento dei principali
protocolli come:
Protocollo il numero e lo stato di connessioni
TCP/IP; numero di datagrammi UDP
inviati, errati, e così via.

Si distinguono inoltre due tipi di monitoraggio: passivo ed attivo.
In quello di tipo passivo il sistema di monitoraggio si limita ad aggregare le
informazioni fornitegli dalle entità della rete. Ciò significa che gli apparati devono
essere dotati di sistemi di memorizzazione e devono offrire i servizi necessari per
l'accesso ai dati.
I monitoraggi attivi, invece, raccolgono informazioni sullo stato della rete attraverso


processi di interazione con la rete stessa. Un monitoraggio attivo è, ad esempio, quello
basato sulla tecnica Packet-pair. Tale tecnica fa uso di code FIFO (coda del tipo First
In First Out) al fine di misurare la larghezza di banda di un collegamento.
Il sistema di monitoraggio previsto nel progetto cui afferisce il presente lavoro prevede
un monitoraggio di tipo passivo ed è quindi opportuno analizzare in maniera esaustiva
il protocollo maggiormente utilizzato in tale ambito: il protocollo SNMP.

3.1 Il protocollo SNMP: Simple Network Management Protocol

In riferimento allo stack ISO/OSI, il protocollo SNMP si colloca al livello 7 (livello
applicazione, corrispondente al livello 4 dello stack TCP/IP) e, al fine di garantire un
basso overhead sul traffico di rete, fa uso di datagrammi UDP (porte 161 e 162) del
livello di trasporto.

Come si evince dall'acronimo “Simple Network Management Protocol”, l'SNMP nasce
con lo scopo di fornire uno strumento di gestione e supervisione di apparati di rete.
L'SNMP si basa su tre principali tipi di entità:
1. management object – il sistema gestito (porta UDP 161);
2. management agent – l'agente di gestione;
3. manager – sistema di gestione (porta UDP 162).

Per sistema gestito s'intende un qualunque apparato collegato in rete (uno switch, un
router, una stampante, un server,...) in grado di fornire un'interfaccia di gestione
SNMP. Tale interfaccia viene realizzata per mezzo di almeno un agente di gestione
detto master ed eventuali altri agenti detti subagent. Gli agenti/sotto-agenti sono
moduli software con responsabilità decisionali di gestione limitatamente ad un


particolare sottosistema o relativamente ad un particolare aspetto del sistema ove
risiedono (management object).
In sistemi “semplici” è possibile definire un unico agente di gestione che, in tal caso,
svolge sia il ruolo di master che di subagent e, per tale motivo, viene denominato
semplicemente agent.

Ogni agent/subagent gestisce una struttura dati denominata MIB (Management
Information Base). Tale struttura modellizza lo stato di un sottosistema in base a suoi
parametri caratterizzanti che si desidera gestire. È importante constatare che ogni
modifica ad un parametro della MIB si ripercuote sullo stato del sistema e ciò permette
tutte le funzionalità di gestione del sottosistema. Come precedentemente accennato, la
coerenza della MIB, rispetto allo stato del relativo sistema/sottosistema che
rappresenta, e viceversa, è a carico degli agent/subagent.
L'accesso alla MIB può essere in lettura e/o in scrittura e rappresenta l'interfaccia
fornita al manager del sistema. In particolare il manager comunica con i sistemi gestiti
tramite i seguenti tipi di messaggi:
• richieste SNMP
◦ GET, per la lettura;
◦ GETNEXT, per la lettura iterativa su una sequenza di dati della MIB;
◦ GETBULK, per la lettura di un blocco di dati della MIB;
◦ SET, per la scrittura di uno o più dati della MIB.
• notifiche SNMP
◦ TRAP, sono messaggi asincroni inviati dall'agent per segnalare eventi (usati,
ad esempio, per i sistemi di allarmistica);
◦ INFORM, notifiche con ACK per informazioni di stato generiche.


La MIB ha una struttura di tipo albero n-ario dove ogni sotto-albero è detto modulo e
le foglie sono gli oggetti. I moduli vengono definiti in base ad un'aggregazione logica
di oggetti.
Ogni nodo/foglia dell'albero MIB è identificato univocamente per mezzo di una
successione di valori numerici separati da un punto. In particolare ogni elemento
(nodo/foglia) è identificabile per mezzo della successione di numeri ottenuta dal
cammino che dalla radice conduce ad esso. Il singolo valore numerico di un modulo è
assegnato dalla IANA (Internet Assigned Number Authority). La successione di tali
identificativi è detta OID (Object IDentifier). L'SNMP definisce, inoltre, una struttura
MIB standard di cui è possibile visionarne una porzione in figura 3.1.1.

ISO Root Standard ISO
1

Org Per le organizzazioni che
3 possono emanare standard

Dod Per il Dipartimento della
6 difesa americano
Per usi futuri OSI

Internet
1

Mgmt Experi-
Directory Private
2 mental
1 4
3

MIB-II
MIB definite Enterpises
1
Ufficialmente
1
Dall'Internet
Architecture
Board Per esperimenti Moduli non standard
Internet definiti dai
costruttori
Fig. 3.1.1 – porzione dell'albero MIB standard


Per quanto riguarda i tipi di dati, che il protocollo SNMP defisce, essi si distinguono
in: primitivi e non primitivi.
I tipi primitivi sono:
• Integer – per i valori interi positivi o negativi incluso lo zero;
• Octet String – per gli insiemi ordinati di byte;
• Object Identifier – per i valori unici secondo le specifiche ASN.1;
• NULL – per il tipo nullo.

I tipi non primitivi previsti dalllo standard sono:
• Indirizzi di rete – per la rappresentazione degli indirizzi IP;
• Counter – per i valori interi non negativi che possono essere unicamente
incrementati fino ad un valore massimo, raggiunto il quale vengono azzerati;
• Gauge – per gli interi non negativi che possono essere sia incrementati che
decrementati;
• Time Tick – per la rappresentazione di intervalli di tempo nella gestione degli
eventi;
• Opaque – tale tipo è in grado di mantenere qualunque valore e viene usato per
le informazioni per le quali non sono strettamente applicabili i tipi
precedentemente descritti.

A partire dalla versione 2 dell'SNMP, per offrire un minimo livello di sicurezza
totalmente assente nella versione 1, è stato introdotto il concetto di comunità.
L'SNMPv2 definisce una comunità come un insieme di sistemi facenti parte di una rete
SNMP. Ogni comunità viene identificata per mezzo di una stringa di 32Byte e ciascun
sistema può appartenere ad una o più comunità. Gli agent accettano quindi richieste
solo da manager della stessa comunità cui possono essere assegnati tre tipi di


autorizzazioni:
• read – autorizzazione in lettura. Il manager può unicamente richiedere all'agent
il valore degli oggetti della MIB (messaggi GET);
• write – autorizzazione in scrittura. Il manager può richiedere all'agent la lettura
e la scrittura di valori degli oggetti della MIB (messaggi GET e SET);
• trap – autorizzazione per le notifiche. Il manager può richiedere all'agent di
ricevere notifiche relative agli oggetti della MIB (messaggi TRAP/INFORM);

È utile ricordare che l'ultima versione dell'SNMP, definita nel documento RFC2570, è
la 3. Questa versione risolve diversi problemi che vanno dalla sicurezza alla
standardizzazione delle varie implementazioni delle versioni precedenti. Tale versione
unifica il concetto di agent e manager in un'unica entità detta SNMP entity. È inoltre
stata adottata un'architettura modulare e diversi algoritmi di autenticazione, sicurezza e
crittografia.
Per concludere questa trattazione del protocollo SNMP è opportuno menzionare alcuni
dei software Open Source maggiormente diffusi:
• Net-SNMP;
• OpenSNMP – software multi-thread per SNMPv3;
• SNMP4J – libreria per Java;
• Netsnmpj – libreria per Java.


3.2 Cacti

Il software utilizzato per la raccolta dei dati di esercizio degli apparati della rete
wireless di Ateneo è l'applicazione open source Cacti (fig. 3.2.1).
La scelta di utilizzare Cacti come strumento di raccolta dati è dettata principalmente
dalle sue caratteristiche, di seguito analizzate, che rientrano in maniera più che
adeguata nel contesto in esame.

Fig. 3.2.1 – schermata di esempio di Cacti. In particolare è possibile notare il grafico
relativo al numero di processi attivi sulla macchina che ospita il sistema di monitoraggio.

Per completezza di informazione si menziona anche un'alternativa, l'applicativo


Nagios. Sono molti gli aspetti in comune con Cacti e, proprio per questo, è importante
notare che l'applicazione realizzata, descritta nei successivi paragrafi, è facilmente
adattabile/estendibile all'uso di Nagios. Una differenza evidente tra i due software
risiede nel fatto che Nagios è utilizzato maggiormente per la realizzazione di sistemi di
allarmistica, più che per monitoraggio puro.
Tornando a Cacti, questi integra una serie di tool, sempre open source, al fine di
fornire un sistema semplice e completo per il monitoraggio passivo di reti
informatiche.
Più dettagliatamente Cacti si basa sui seguenti strumenti:
• Net-SNMP, per le interrogazioni SNMP;
• RRDTool, per la persistenza dei dati frutto di monitoraggio e la loro
presentazione per mezzo di grafici;
• piattaforma LAMP (Linux Apache Mysql Php), ed in particolare:
◦ PHP ed Apache, per la presentazione dei dati e per le interfacce utente;
◦ MySQL, per la persistenza dei dati di configurazione.

Una schematizzazione modulare, esplicativa, può essere la seguente:

NetSNMP

CACTI

Piattaforma LAMP RRDTool
MySQL
DB

Fig. 3.2.2 – struttura modulare di Cacti


Un'importante caratteristica di Cacti, che gli conferisce ampi margini di espansibilità, è
l'architettura a plug-in.
Tra i plug-in più rilevanti vi sono:
• Discovery – auto rilevamento di dispositivi di una subnet non monitorati da
Cacti;
• Host Info – consente di visualizzare informazioni sugli host;
• Monitor – mostra gli stati degli host monitorati generando segnali acustici in
caso di “cadute”;
• Uptime – consente di conoscere gli uptime dei dispositivi monitorati;
• Weathermap – consente di definire mappe delle reti arricchite con i dati di
monitoraggio;
• NPC – plugin per integrare il sistema di monitoraggio Nagios all'interno di
Cacti.

Per quanto riguarda la definizione dei monitoraggi, le chiamate a Net-SNMP possono
essere definite per mezzo di:
• script di shell bash;
• script Perl;
• definizione di template in XML (eXtensible Markup Language).

Una volta definite le interrogazioni SNMP desiderate, attraverso processo di polling,
Cacti prevede ad eseguirle ad intervalli di tempo regolari, passandone i risultati ad
RRDTool. In prima istanza, RRDTool può essere considerato come un vero e proprio
database ottimizzato per gli ambienti di monitoraggio in genere. Nel successivo
paragrafo sarà descritto in maniera esaustiva tale software, del quale Cacti viene
considerato un'interfaccia user friendly, in quanto l'applicazione realizzata prevede, a


livello del data layer, una ricca interazione con quest'ultimo.
Al fine di descrivere in maniera più chiara i processi legati alla raccolta dati di Cacti,
se ne riporta uno schema esplicativo contestualizzato alla rete wireless di ateneo:

MSA
Centro Storico
AP1 APa AP1 APb AP1 APc AP1
APd
Policlinico
WDSx WDS1
WDS1
WDSy AP1
SN WDS1
SN M

SNMP

SN MP
M APe
P MP
SN
P

AP1
WDSz
SN MP
NetSNMP APf

CACTI

RRD Files
Piattaforma LAMP RRDTool
MySQL
DB

Fig. 3.2.2 – processo di raccolta e persistenza dati di Cacti nell'ambito della rete wireless di ateneo

Dallo schema sopra riportato è possibile osservare come Cacti, attraverso l'uso di Net-
SNMP, è in grado di raccogliere dati dalle tre sedi principali della rete wireless di
ateneo. È importante notare che le interrogazioni SNMP vengono effettuate
unicamente sui WDS in quanto, questi ultimi, come descritto nel paragrafo 2.2,
mantengono le informazioni di tutti gli apparati dell'infrastruttura a loro carico.
Ad ogni interrogazione i dati vengono quindi passati ad RRDTool che procede alla
storicizzazione degli stessi.


3.3 RRDTool: Round-Robin Database Tool

RRDTool (acronimo di Round Robin Database Tool) è un software open source
realizzato interamente in C da Tobias Oetiker ed è uno degli strumenti maggiormente
utilizzati nell'ambito dei sistemi di monitoraggio in genere. Il compito principale di
RRDTool, in un sistema di monitoraggio, è l'archiviazione di serie temporali.
Le principali caratteristiche (fig. 3.3.1) sono:
• dimensioni degli archivi (file RRD – Round Robin Database), a regime,
costanti;
• dump degli archivi in file XML;
• fetch di serie temporali parziali dagli archivi;
• rappresentazione dei dati per mezzo di grafici (fig. 3.3.2).

RRD Files
RRDTool

STDOUT
ASCII XML files
dump file
dump file
Stream
Stream

Fig. 3.3.1 – caratteristiche principali di RRDTool


Fig. 3.3.2 – esempio di grafico generato da RRDTool

Al fine di analizzare, in maniera dettagliata, gli RRD si riporta un diagramma di classe UML
che ne sintetizza la struttura logica:

Fig. 3.3.3 – rappresentazione della struttura logica degli RRD per mezzo di diagramma di classe UML


Passando in rassegna ogni singola classe del diagramma precedente, è possibile notare
che ogni RRD è caratterizzato da:
• version – una stringa indicante il numero di versione dell'RRD (attualmente la
003);
• step – un valore numerico intero che indica la frequenza, in secondi, con cui
l'RRD viene aggiornato;
• lastupdate – intero che rappresenta la data di ultimo aggiornamento dell'RRD,
in numero di secondi trascorsi dal 01/01/1970 00:00:00 (Unix Epoch – d'ora in
avanti a tale formato ci si riferirà anche con il nome di TimeStamp).
Ad ogni RRD sono associati uno o più RRA (Round Robin Archive) ed uno o più DS
(Data Source).
Un DataSource rappresenta una fonte di dati (ad esempio “il carico del processore di
un server”, “il numero di pacchetti inviati da uno switch”,...) all'interno di un RRD.
Ogni DS ha i seguenti attributi:
• name – stringa contenente il nome del DataSource. Tale valore identifica il DS
in maniera univoca all'interno dell'RRD;
• heartbeat – letteralmente “battito del cuore/cardiaco”. Tale intero indica il
numero massimo di secondi che possono trascorrere tra l'inserimento di due dati
consecutivi relativi al DS stesso. Se allo scadere dell'heartbeat non viene
inserito un nuovo dato relativo al DataSource, RRDTool provvede a
memorizzare un valore “speciale” di tipo UNKNOWN (sconosciuto).
• min, max – interi rappresentanti gli estremi dell'intervallo [min, max] cui
devono appartenere i dati relativi al DataSource. Attraverso tali valori è quindi
possibile definire il dominio di validità per i dati del DataSource.
È utile tener presente che nella letteratura di RRDTool viene utilizzato il nome “PDP”
(Primary Data Point) per indicare i dati che vengono inseriti negli RRD prima che sia


avviato il processo di memorizzazione.
Ogni DS può essere definito di uno dei seguenti quattro tipi:
• COUNTER – tipo di contatore che può essere unicamente incrementato fin
quando non va in overflow (32 o 64bit in base all'architettura). Un esempio che
può prevedere un DS di questo tipo può essere il numero totale di autenticazioni
su un server RADIUS;
• DERIVE – tipo di dato senza controllo sull'overflow dove il nuovo dato viene
memorizzato come la differenza con il precedente diviso l'intervallo di tempo
trascorso tra le due misurazioni. Inoltre al fine della persistenza del nuovo dato,
tale differenza dev'essere positiva.
RRDTool, quindi, all'inserimento di un valore per un DS del tipo DERIVE,
effettua la differenza tra il nuovo valore e quello precedentemente memorizzato
dividendo tale risultato per il tempo trascorso.
Indicato con xi il valore di una misurazione al tempo ti e con yi il valore del
nuovo dato da memorizzare, la formula, applicata da RRDTool, può essere così
indicata:

{
x n− x n−1
y i= t n−t n−1 ⇔ x n x n−1
y i −1 ⇔ x n≤x n−1

Un esempio può essere il tasso di utenti che si connettono ad una rete.
• GAUGE – i DS di questo tipo sono impiegati per usi generici, per misurazioni,
quindi, di natura variabile. Un DS GAUGE, può riferirsi, ad esempio, alla
temperatura di una CPU;
• ABSOLUTE – tipo utilizzato per tutti i contatori che tendono velocemente
verso l'overflow. L'uso tipico si basa su letture ed azzeramenti successivi del
contatore.
Un altro tipo di DS, non trattato approfonditamente in questo contesto in quanto di


raro utilizzo e comunque non usato nel sistema di monitoraggio, è il COMPUTE. Tale
tipo consente di definire un DS in funzione di altri dello stesso RRD.
Come precedentemente accennato, ogni RRD contiene uno o più RRA (Round Robin
Archive). Tali oggetti sono gli archivi che si occupano di conservare tutte le serie
storiche dei DS dell'RRD. Ad ogni archivio è associata una o più funzioni di
consolidamento CF (Consilidation Function) il cui scopo è consolidare i dati (PDP)
dei DS prima di memorizzarli. In particolare tale funzione viene applicata per ogni DS
dell'RRD su un certo numero di PDP.
Le possibili funzioni di consolidamento sono le seguenti:
• AVERAGE – media tra un certo numero di PDP;
• MIN – valore minimo tra una serie di PDP;
• MAX – valore massimo tra una serie di PDP;
• LAST – ultimo valore di una serie di PDP.

Ogni CF ha i seguenti attributi:
• xff – XFileFactor. Tale valore, reale appartenente all'intervallo [0,1] e di default
pari a 0, indica la massima frequenza dei dati che possono essere di tipo
UNKNOWN al fine di poter applicare la CF. Questo valore è tipicamente pari a
0.5 ed indica, quindi, che al più il 50% dei dati possono essere di tipo
UNKNOWN. L'uso di tale attributo è significativo nei monitoraggi in ambienti
particolarmente “rumorosi”, dove, cioè, le misurazioni possono risultare
disturbate;
• pdp_per_row – indica ogni quanti PDP dev'essere applicata la funzione di
consolidamento;
• rows – massimo numero di dati che l'RRA può archiviare.
Per quanto concerne il Database, presente in ogni RRA, esso è costituito dai risultati


delle CF. A regime, il numero di righe, è costante e pari al parametro rows della CF.
Nello schema a seguire viene mostrato il flusso dei dati (in rosso) durante il processo
di memorizzazione all'interno di un RRD. È da notare che sono presenti più DS e più
RRA.

RRD

1 DS
2
RRA
CF

3

Database

Fig.3.3.4 – Flusso dei dati durante il processo di memorizzazione all'interno di un RRD.
Tale processo è formato dalle seguenti fasi:
1) inserimento dati (PDP); 2) Consolidamento dati (CF); 3) Archiviazione dati (Database).

Dallo schema si evince come, quando viene inserito un numero di dati (PDP) pari
all'attributo pdp_per_row di una CF, viene eseguito il consolidamento degli stessi ed il
risultato inserito nel Database. In particolare vengono eseguite tutte le CF per le quali
si è raggiunto il valore pdp_per_row.

Per quanto riguarda l'algoritmo Round Robin, dal quale il tool prende il nome, è alla
base della logica di funzionamento dei Database contenuti negli RRD. Tali Database,
infatti, possono essere definiti come strutture dati del tipo “code circolari” a
dimensioni fisse. In particolare, raggiunta la lunghezza massima della coda, ogni
successivo elemento viene accodato dopo aver eliminato la testa della coda.
Nel successivo schema è possibile notare, con maggior precisione, qual è la struttura
interna dei Database:


#DS values

values

Database

Rows elementi

Fig. 3.3.5 – struttura dei Database (code circolari a lunghezza fissa) degli RRA

Il Database ha quindi una dimensione massima pari al parametro rows della CF.
Ogni suo elemento, inoltre, è un vettore di lunghezza pari al numero dei DS presenti
nell'RRD tale che, l'i-esimo elemento si riferisce all'i-esimo DS. L'associazione tra i
DS ed i dati è quindi basata sull'ordine in cui i DS sono stati definiti nell'RRD.
L'informazione che ogni dato conserva è il valore del risultato di una CF applicata ad
una serie di PDP (reale in forma normalizzata), associato al relativo TimeStamp.
Ricordando il significato dei seguenti parametri
• RRD.step : frequenza di aggiornamento RRD in secondi
• CF.pdp_per_rows : frequenza di aggiornamento Database in funzione dello step
• CF.rows : massimo numero di record del Database
si ricava che ogni Database
• ha una risoluzione pari alla frequenza d'aggiornamento del Database stesso:
 T x =  T D = pdp_per_row ⋅ step sec
i
i=0,... , rows−1

• conserva uno storico di:
 T S = rows ⋅ pdp_per_row ⋅ step sec = rows ⋅ T D

Per completare la trattazione di RRDTool si riporta un esempio di utilizzo che


consente di ottenere un semplice monitoraggio della temperatura di una CPU dual core
su un sistema Linux.
• Creazione del file RRD con le seguenti caratteristiche:
◦ coretemp.rrd – nome del file;
◦ step 15 – frequenza aggiornamento dell'rrd pari a 15 secondi;
◦ un DS per core:
1. core_01 di tipo GAUGE con heartbeat pari a 30 secondi e dominio pari
all'intervallo [0, 150];
2. core_02 di tipo GAUGE con heartbeat pari a 30 secondi e dominio pari
all'intervallo [0, 150];
▪ Considerazioni sui DS:
tali datasources consentono di memorizzare valori numerici/temperature
che vanno da 0 a 150 (in questo esempio °C). Ogni datasource dev'essere
aggiornato con frequenza pari a 30 secondi.
◦ tre RRA tutti con funzioni di consolidamento di tipo AVERAGE
(consolidamento per mezzo della media dei PDP) ed XFileFactor pari a 0.5
(massimo il 50% dei PDP possono essere UNKNOWN). Per quanto
riguarda i valori di pdp_per_row (numero di PDP a cui viene applicata la
funzione di consolidamento) e massimo numero di righe dei Database
vengono usati, nell'ordine, i seguenti valori:
1. pdp_per_row pari a 1 e 9600 rows (valori memorizzabili);
2. pdp_per_row pari a 4 e 9600 rows;
3. pdp_per_row pari a 24 e 9600 rows;
▪ Considerazioni sugli RRA:
i Database degli RRA hanno, nell'ordine, risoluzioni e mantengono
storici pari a:


1. risoluzione:  T D =pdp_per_row⋅step=1⋅15 sec=15 sec
1

dimensione storico:
 T S =rows⋅T D =9600⋅15sec=144000sec=40h

2. risoluzione:  T D =pdp_per_row⋅step=4⋅15 sec=60 sec=1min
1

dimensione storico:
 T S =rows⋅T D =9600⋅60sec=576000sec=160h

3. risoluzione:  T D =pdp_per_row⋅step=24⋅15 sec=360 sec=6min
1

dimensione storico:
 T S =rows⋅T D =9600⋅360sec=3456000sec=960h=40gg

◦ Comando di shell bash per la creazione del file rrd:
rrdtool create coretemp.rrd --step 15
DS:core_0:GAUGE:30:0:150
DS:core_1:GAUGE:30:0:150
RRA:AVERAGE:0.5:1:9600

• Creazione di uno script bash per popolare il file rrd:
#!/bin/bash
while [ 1 ] ; do

#lettura temperatura dei core
CORE0_TEMP=`sensors | grep "Core 0:" | cut -f 8 -d
| sed "s/°C$//"`
CORE1_TEMP=`sensors | grep "Core 1:" | cut -f 8 -d
| sed "s/°C$//"`

#memorizzazione dei valori nel file rrd
rrdtool update coretemp.rrd N:$CORE0_TEMP:$CORE1_TEMP

#attesa 15 secondi prima del successivo rilievo
sleep 15s
done


• Risultati:
una volta creato l'rrd ed avviato lo script bash, che necessita del pacchetto
sensors installato sulla macchina, dopo un'attesa necessaria a popolare l'rrd, è
possibile eseguire il seguente comando al fine di ottenere un grafico
rappresentativo dei due DS:
rrdtool graph coretemp.png
DEF:core_0=coretemp.rrd:core_0:AVERAGE
DEF:core_1=coretemp.rrd:core_1:AVERAGE
LINE1:core_0#0000ff:Core0_Temp LINE1:core_1#ff0000:Core1_Temp
--start -30m

Tale comando consente di ottenenre il seguente grafico relativo all'ultima
mezz'ora di rilevamenti:

Fig. 3.3.6 – esempio di grafico generato con RRDTool relativo alle
temperature di due core di una CPU nell'ultima mezz'ora

Essendo numerose le opzioni di personalizzazione per i grafici di RRDTool, si
rimanda alla relativa documentazione ufficiale per ulteriori approfondimenti.


4 L'applicazione realizzata

4.1 Requisiti

L'applicazione realizzata risponde ai seguenti, principali requisiti:
1. integrazione con il sistema di monitoraggio;
2. strumenti per la valutazione di statistiche di esercizio della rete wireless di
ateneo;

L'attuale sistema di monitoraggio consta di un server sul quale è installato il software
Cacti opportunamente configurato per la raccolta passiva dei dati dalla rete.
I dati di rete attualmente monitorati sono:
• Numero di AP attivi;
• Numero di utenti connessi;
• Dati sui protocolli:
◦ SNMP;
◦ IP;
◦ TCP;
◦ UDP.

Le interrogazioni SNMP vengono effettuate sui WDS della rete per ogni principale
sede di ateneo:
• Monte Sant'Angelo ed Ingegneria;
• Centro Storico;
• Policlinico.


Al fine di ottenere un'alta portabilità ed evolvibilità, si è deciso di realizzare
un'applicazione interamente in Java.
Lo schema a seguire mostra l'interazione tra il sistema di monitoraggio e l'applicazione
realizzata:

WiFi Unina

Applicazione
Cacti Java

Fig. 4.2.1 – contestualizzazione dell'applicazione JAVA
realizzata rispetto al sistema di monitoraggio

Il primo, principale requisito, inerente l'integrazione, implica la necessità di accesso ai
dati di Cacti. In tal senso questi risulta particolarmente “chiuso”, non prevedendo
interfacce per l'interazione verso l'esterno.
Come precedentemente descritto, il datalayer di Cacti si basa sull'uso di:
• MySQL per i dati di configurazione;
• RRDTool per la memorizzazione dei dati frutto di monitoraggio.

Per quanto riguarda il database MySQL, per mezzo di un processo di reverse
engineering, tramite l'uso dello strumento software open source SQLFairy, è stato
ricavato il seguente diagramma ER:


Fig. 4.2.2 – diagramma ER del database di Cacti ottenuto con SQLFairy


Essendo, ovviamente, il diagramma ER normalizzato, è stato necessario comprendere
il significato delle tabelle osservandone il contenuto durante il funzionamento.
A seguito di tale processo sono state individuate le seguenti tabelle d'interesse:
• host – per conoscere gli host monitorati da Cacti e le relative informazioni;
• poller_item – per conoscere, per ogni host, i dettagli delle interrogazioni
effettuate. Tra le informazioni presenti vi sono:
◦ informazioni sul protocollo SNMP usato (versione, community name,
eventuale password per la versione 3, porta, timeout per le richieste,...);
◦ informazioni circa RRDTool ed, in particolare, il pathname dell'rrd dove
vengono salvati i risultati dell'interrogazioni.

Le due tabelle sono in relazione uno a molti e quindi, per ogni host possono esserci più
poller_item.

L'accesso ai dati degli rrd è basato, invece, sull'uso dei file XML di dump.
Tutti i dettagli circa l'accesso ai dati vengono trattati nei successivi paragrafi.

4.2 Architettura generale

L'architettura dell'applicazione realizzata può essere classificata come: Client/Server
multi-tier.
L'accesso ai dati di monitoraggio è realizzato attraverso due componenti:
• Data Server;
• Data Client.
Il Data Server, residente sul server di monitoraggio (dove è installato Cacti), offre due
tipologie di servizi:


• accesso ai dati del database di Cacti;
• accesso agli rrd.
Il Data Client è costituito da alcuni componenti per gestire la persistenza dei dati
dell'applicazione realizzata, attraverso interazione con uno o più Data Server.
Al fine di offrire servizi di amministrazione del Data Client, quest'ultimo è stato dotato
di un componente detto Admin Server.

Per la presentazione dei dati e interfacce utente si è fatto uso di Servlet Java, pagine
JSP e Java Beans, come spiegato nei successivi paragrafi.

Uno schema che sintetizza l'architettura dell'applicazione è il seguente:

GUI Servlet/JSP/Beans
socket

Amministrazione Admin Server
Thread-safe
Collections

Data Client
Accesso ai dati di
monitoraggio socket

Data Server

Ad inizio paragrafo, l'architettura è stata definita come Client/Server multi-tier in
quanto i componenti comunicano per mezzo di una logica Client/Server. L'unica
eccezione è l'interazione tra l'Admin Server ed il Data Client che, attraverso Collezioni
Java thread-safe, condividono le principali entità dell'applicazione.


4.3 Accesso ai dati di monitoraggio

Come precedentemente accennato il Data Server risiede sulla stessa macchina dov'è
installato Cacti. Questo vincolo deriva dal fatto che il dump degli rrd in files XML è
possibile unicamente sulla stessa architettura dove sono stati creati.
Il seguente schema riporta i processi di interazione tra i principali componenti
designati per l'accesso ai dati di monitoraggio:

WiFi Unina


   SNMP

RRD Files

Cacti
Cacti
DB

XML XML
Dump Dump
Files Files
JDBC Dumper Parser SAX
        Socket
       Socket

XML files,


DATA SERVER MySQL DB info DATA CLIENT
Parser
JDBC
Dom/XPath
XML
Config RRDB
Files

Fig. 4.3.1 – architettura modulare per l'accesso ai dati di monitoraggio

Tale soluzione consente di avere:
• uno o più server di monitoraggio;
• gestione centralizzata dei dati d'interesse.


4.3.1 Server di monitoraggio: Il Data Server

Il Data Server è un server multithread, che risiedere su una macchina in cui è installato
Cacti, che offre i seguenti servizi:
• accesso ai dati del database di Cacti ed, in particolare, consente di conoscere:
◦ lista host (con specifica di hostname e descrizione) monitorati da Cacti;
◦ lista dei file rrd (pathname) associati ad un determinato host monitorato.
Il servizio richiede la specifica di: hostname/ip dell'host.

• accesso ai dati di uno specifico rrd ed, in particolare:
◦ invio di file XML ottenuti da dump di uno specifico rrd.
Il servizio richiede la specifica di: pathname del file rrd.
◦ lettura di serie temporali parziali (sotto forma di (valore, data)) relative ad
uno specifico DS, di un determinato RRA, contenuti in un file rrd.
Tale servizio richiede la specifica di:
▪ pathname rrd;
▪ identificativo rra (nome della funzione di consolidamento);
▪ nome, univoco, del datasource;
▪ risoluzione dei dati ;
▪ tempo (Unix Epoch) a partire dal quale vengono estratti i dati.

Per quanto riguarda l'accesso al database MySQL di Cacti, viene utilizzato il
connettore JDBC (Java Database Connectivity), mentre il dump dei file rrd viene
eseguito per mezzo di processi RRDTool.
Il Data Server è inoltre configurabile tramite file XML per il quale viene utilizzato il
parser DOM (Document Object Model) ed istruzioni XPath (Xml Path language).


Si riporta di seguito un contenuto d'esempio di un file di configurazione XML:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE configuration SYSTEM "server_config.dtd">

<configuration>

<serverPort>61000</serverPort>

<rrdtoolPath>/usr/bin/rrdtool</rrdtoolPath>

<cactiDb>

<dbName>cacti</dbName>

<userName>user_name</userName>

<userPwd>user_password</userPwd>
</cactiDb>
</configuration>

Come si evince dal codice sopra riportato, è possibile impostare i seguenti parametri di
configurazione:
• numero porta della socket;
• pathname al binario di RRDTool;
• nome del database di Cacti;
• nome utente per l'accesso al database di Cacti;
• password dell'utente per l'accesso al database di Cacti.

Tutti i files XML utilizzati nell'applicazione vengono validati per mezzo di file DTD
(Document Type Definition). Nel caso dei file XML ottenuti dal dump degli rrd, viene
utilizzato il DTD standard di RRDTool reperibile al seguente indirizzo:
http://oss.oetiker.ch/rrdtool/rrdtool.dtd.
Il processo di validazione viene eseguito sia per verificare che l'XML rispetti una
struttura nota, sia, nel caso dei file di configurazione, per poter eseguire istruzioni
XPath.

Tutte le richieste e gran parte delle risposte vengono effettuate per mezzo di oggetti
serializzati Java su Socket. Nel caso delle risposte vengono utilizzati anche stream di
byte per il trasferimento degli XML.

4.3.2 Il Data Client

Per quanto concerne il Data Client, gli aspetti di maggior rilevanza sono:
• il parsing degli XML tramite SAX (Simple Api for Xml);
• il database MySQL, denominato RRDB (Round Robin DataBase), per la
persistenza dei dati;

4.3.2.1 Parsing di XML dump file

È stato scelto di utilizzare il parser SAX per i file di dump in quanto, questi ultimi,
rispecchiano l'intero contenuto dei file rrd contenendo, quindi, una grossa mole di dati
(tutti gli rra per tutti i ds dell'rrd).
A differenza del parser DOM, che costruisce in memoria l'intero albero del file XML,
il parser SAX si basa sul paradigma ad eventi e design pattern OBSERVER. Per
una descrizione del pattern Observer si rimanda al paragrafo 4.5.2. In particolare, i
principali eventi che, durante il parsing, vengono generati da SAX, sono i seguenti:
• start element – evento generato all'occorrenza di un tag aperto;
• characters – evento generato all'occorrenza di un valore compreso tra un tag di
apertura ed uno di chiusura;
• end element – evento generato all'occorrenza di un tag di chiusura.
È stata quindi realizzata una classe, denominata “RRDAutomata” (fig. 4.3.2.1), che
viene registrata come listener del parser SAX.


Fig. 4.3.2.1.1 – classe RRDAutomata per la rappresentazione in memoria degli rrd

Tale classe modellizza, nella logica, un automa a pila. Al fine di comprenderne il
funzionamento si riporta un diagramma degli stati UML:

Fig. 4.3.2.1.2 – statechart dell'automa a pila per il parsing degli XML ottenuti dal dump degli rrd


Grazie all'uso di uno stack di Object, la classe RRDAutomata, guidata dagli eventi
generati dal parser SAX, è in grado di ricostruire in memoria l'esatta struttura dell'rrd
nel rispetto del seguente diagramma di classe:

Fig. 4.3.2.1.3 – diagramma di classe UML per la rappresentazione in memoria degli rrd

4.3.2.2 Il database RRDB

In riferimento alla struttura dei files rrd, è opportuno, in tale contesto, tener presente i
seguenti punti:
• ogni rrd contiene uno o più archivi rra atti a tener traccia, per mezzo di un
database round robin, dei dati monitorati riferiti ad un device;
• per ogni rrd è definito un valore, in secondi, chiamato “step”. Tale valore
definisce la frequenza di aggiornamento dell'rrd;
• per ogni rrd è definita una variabile, “lastupdate”, che indica la data dell'ultimo
aggiornamento (nel formato Unix-epoch);


• per ogni rra è definito un valore intero, chiamato “pdp_per_row”, che indica
quanti aggiornamenti (letture del dato monitorato) concorrono all'inserimento di
un dato all'interno di un rra (per mezzo di una funzione di consolidamento);
• altro dato importante in questo contesto è la costante “rows” definita per ogni
rra. Tale valore indica il numero di righe del database mantenuto dall'rra in
esame.

Ogni database round robin è quindi identificabile per mezzo della coppia:
(nome_rrd, id_rra)
Per questioni logiche e di miglior comprensione, essendo definita un'unica funzione di
consolidamento (CF) per rra, ogni database viene identificato dalla coppia:
(nome_rrd, id_cf).

Per quanto riguarda il database realizzato per l'applicazione, denominato rrdb, la scelta
del DBMS è stata dettata sia dal tipo di licenza (GNU GPL), sotto la quale è distribuito
MySQL, sia perché esso è già in uso per il software di monitoraggio Cacti.
Una problematica di rilievo che è stata affrontata riguarda la replicabilità della logica
di memorizzazione dei database Round Robin in un database di tipo relazionale.
Di seguito vengono riportati i dettagli ritenuti di maggior rilievo.

Nell'immagine a seguire si riporta una porzione del diagramma EER interessato da tale
aspetto:


Fig. 4.3.2.2.1 – porzione del diagramma EER relativo al database “rrdb” realizzato per l'applicazione

Come è stato descritto nei precedenti documenti, la logica di memorizzazione dei dati
all'interno dei files di RRDTool, e più in generale di database Round Robin, è basata
su una struttura dati del tipo “vettore circolare”.
E' possibile adottare diverse tecniche per replicare il comportamento di un vettore
circolare in una base di dati relazionale. Una possibile soluzione, forse la più intuitiva
e performante, è quella di utilizzare un trigger con le seguenti caratteristiche:
• Evento: inserimento di un nuovo record (nella tabella DATA del diagramma
EER);
• Condizione: la tabella (DATA) ha raggiunto il massimo numero di record
memorizzabili (attributo “Rows” della tabella RRA);
• Azione: cancellazione del record con data (attributo “Data_Time” della tabella


DATA) più vecchia.
Purtroppo tale soluzione non è direttamente adottabile in MySQL (con l'attuale vers.
5.1.44 viene segnalato l'errore “1442”) in quanto non è possibile definire trigger in cui
evento ed azione sono definiti su una stessa tabella (la tabella target deve differire dalla
tabella sorgente). Ovviamente per “azioni” s'intende qualunque transizione che operi
su record diversi da “NEW” ed “OLD”. Questa scelta progettuale ha il fine di
prevenire possibili “cicli infiniti” che potrebbero scaturire da eventuali errori nella
definizione di trigger di questo tipo. Evidentemente tale limitazione non è aggirabile
attraverso l'uso di trigger annidati e/o viste modificabili.
È da notare anche il mancato supporto di trigger con eventi del tipo “INSTEAD OF”,
classici Oracle, che, con l'uso combinato di una tabella d'appoggio, avrebbe risolto il
problema.
Una strategia alternativa potrebbe essere quella di spostare la responsabilità di
eliminare il record “più vecchio”, sul client. In tal caso è opportuno rifiutare
inserimenti di nuovi record qualora sia stato raggiunto il numero massimo. Rifiutare
queries di inserimento si traduce nella creazione di un trigger con le stesse
caratteristiche di quello precedentemente definito, tranne che per l'azione. In tal caso,
infatti, l'azione deve prevedere il lancio di un'eccezione in caso di saturazione del
numero di record.
Anche in questo caso la soluzione è stata scartata in quanto non vi è possibilità di
generare eccezioni in MySQL (è solo possibile catturarne).
Tralasciando facili critiche si evidenzia la presenza, sul sito di MySQL (sez. bug), di
diverse segnalazioni a tal proposito e, in riferimento alle azioni del tipo “INSTEAD
OF” ed alle eccezioni, è stato appurato che saranno features probabilmente
implementate nelle prossime versioni.
In attesa di nuovi rilasci è stata adottata una soluzione che, anche se funzionante, si
auspica sia temporanea.


La soluzione adottata prevede la definizione di una Stored Procedure (“insertData”)
per l'inserimento di record nella tabella DATA. Tale procedura ha la responsabilità di
inserire record nella tabella DATA e di verificare e mantenerne costante il numero di
record. Il client della base di dati, quindi, invece di utilizzare l'operazione “INSERT”,
per tale tabella, deve far uso di tale procedura.
In caso di uso di “INSERT”, ed in condizione di tabella “piena”, si è ricorso ad un
“trucco” di uso comune. In particolare, non potendo definire e lanciare eccezioni,
viene richiamata una procedura inesistente. A seguito di tale chiamata, MySQL genera
un'eccezione che informa dell'inesistenza della procedura. Nonostante tale soluzione
sia poco elegante e definibile “programmazione sporca”, essa consente di esulare il
client da responsabilità che riguardano la logica interna della base di dati. Inoltre,
tenuto conto della procedura realizzata che il client deve utilizzare, si ritiene che il
risultato complessivo sia soddisfacente.
Per completezza si segnala che, al fine di generare eccezioni in MySQL, un altro
“trucco” di uso comune è quello di violare qualche vincolo di integrità.

4.4 Logica di controllo per la gestione dei dati

Gli aspetti riguardanti la logica di controllo ritenuti di maggior rilievo sono:
• amministrazione dei dati;
• temporizzazione delle letture degli rrd;
• i Monitor ed i Report Statistici.

Il componente designato all'amministrazione è l'Admin Server. Tale componente
interagisce in maniera stretta con il Data Client. In particolare persiste una relazione di
uno a uno.


Accesso ai Dati di Monitoraggio

Cacti Cacti Cacti Cacti Cacti
Cacti DB DB
DB
RRD Files RRD Files RRD Files

Data Server Data Server Data Server

RRDB Data Client

Admin
Server

Fig. 4.4.1 – Data Client ed Admin Server per la gestione della logica di controllo nella gestione dei dati

4.4.1 Servizi di amministrazione dei dati

I servizi di amministrazione, che l'Admin Server offre per mezzo di socket, sono i
seguenti:
• gestione della lista di Data Server
poiché ogni Data Client può accedere a più server di monitoraggio, l'Admin
Server consente di conoscere e gestire la lista di tali server. La gestione della
lista comprende le seguenti, possibili, azioni:
◦ lettura;
◦ aggiunta;


◦ cancellazione.
• gestione lista dei device monitorati da un Data Server
per ogni Data Server gestibile è possibile conoscere quali sono i device
monitorati;
• gestione lista degli rrd associati ad un device
per ogni device monitorato è possibile conoscere la lista dei file rrd associati;
• gestione dei Monitor
l'Admin Server consente la gestione di Monitor, che vengono trattati nel
successivo paragrafo, in termini di:
◦ lettura;
◦ aggiunta;
◦ cancellazione.
• gestione dei Report Statistici
per ogni monitor definito sul Data Client, è possibile, come spiegato
successivamente, creare dei Report Statistici. L'Admin Server offre tutti i
servizi necessari a gestire tali report.

4.4.2 Temporizzazione delle letture degli rrd

Un aspetto importante dell'applicazione riguarda la temporizzazione delle letture dei
files rrd. Tralasciando, per il momento, l'applicazione in sé, è possibile inquadrare il
problema in termini di “lettore/scrittore” (senza riferimento alcuno al classico
problema di sincronizzazione).
Da un lato vi è l'applicazione di monitoraggio che inserisce/scrive dati all'interno degli
rrd, dall'altro abbiamo uno o più client che leggono le informazioni dagli rrd.
Per quanto riguarda lo “scrittore” la frequenza di inserimento dei dati è definita, nota e


Un Framework per la valutazione delle statistiche di esercizio della rete wireless di Ateneo "Wifi-Unina"

Un Framework per la valutazione delle statistiche di esercizio della rete wireless di Ateneo "Wifi-Unina"

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (18)

En vedette

En vedette (19)

Similaire à Un Framework per la valutazione delle statistiche di esercizio della rete wireless di Ateneo "Wifi-Unina"

Similaire à Un Framework per la valutazione delle statistiche di esercizio della rete wireless di Ateneo "Wifi-Unina" (20)

Dernier

Dernier (9)

Un Framework per la valutazione delle statistiche di esercizio della rete wireless di Ateneo "Wifi-Unina"