Un Sistema di Monitoraggio per una Rete ad Alte

Transcript

Università degli Studi di Napoli Federico II
Facoltà di Scienze MM.FF.NN.
Corso di Laurea in Informatica
Tesi Sperimentale di Laurea Triennale
Un Sistema di Monitoraggio per una Rete ad Alte Prestazioni
e ad Alta Affidabilità
Relatori
Candidato
Prof. Guido Russo
Dr. Domenico Del Prete
Alfonso Palma
Matricola: 566/1880
Anno accademico 2009/2010
Desidero ringraziare...
il Prof Guido Russo per avermi consentito
di svolgere questo lavoro di tesi, e per la sua piena disponibilità,
tutti i miei colleghi che mi hanno accompagnato
nel percorso di studio,
e tutte le persone a me care,
che hanno creduto in me,
e mi hanno sostenuto.
Indice generale
1 Introduzione.......................................................................................................................................1
2 Principali Caratteristiche di una Rete................................................................................................4
2.1 Affidabilità.................................................................................................................................4
2.1.1 Come la topologia di una rete può influenzare l'affidabilità..............................................5
2.1.2 Metriche ed analisi di un Modello per la valutazione dell'affidabilità di una rete.............6
2.2 Sicurezza....................................................................................................................................7
2.3 Performance.............................................................................................................................10
2.3.1 Valutazione delle prestazioni di una rete..........................................................................11
2.3.2 Metriche in dettaglio........................................................................................................12
2.4 L'Importanza Di Un Sistema Di Monitoraggio.......................................................................13
2.5 Le Regole Della Qualità Applicate Alle Reti (Deming Cycle)................................................14
3 Analisi dell'Infrastruttura della Rete................................................................................................17
3.1 Che Cos'è Il Tier2....................................................................................................................17
3.2 La Rete Del Tier2.....................................................................................................................18
3.2.1 Configurazioni in Dettaglio.............................................................................................20
3.2.2 Tabella Apparati della Rete..............................................................................................22
3.2.3 Alcuni Dispositivi della Rete in Dettaglio.......................................................................22
3.3 Le Mappe Realizzate...............................................................................................................34
3.3.1 Mappa generale della Rete...............................................................................................35
3.3.2 Mappe degli Apparati.......................................................................................................36
4 Analisi degli Strumenti Software Utilizzati.....................................................................................42
4.1 Cacti.........................................................................................................................................42
4.1.1 Raccolta dei Dati..............................................................................................................45
4.1.2 Il Plugin Weathermap.......................................................................................................47
4.2 Ulteriori Sistemi Software Di Monitoraggio...........................................................................49
4.3 Scelta E Motivazioni Del Tool Utilizzato................................................................................51
4.4 Realizzazione Di Una Guida Per L'Installazione Di Cacti E Del Plugin Weathermap...........52
4.5 Test Preliminari........................................................................................................................61
5 Progettazione e Realizzazione di un Sistema per il Monitoraggio di una Rete..............................71
5.1 Presentazione Del Sistema Realizzato.....................................................................................71
5.1.1 Integrazione del Sistema di Monitoraggio nel Portale del Tier2.....................................73
5.1.2 Il Portale del Tier2............................................................................................................74
5.2 Casi D'Uso...............................................................................................................................75
5.3 Component Diagram................................................................................................................78
5.4 Configurazione Delle Componenti Utilizzate..........................................................................79
5.5 Il Codice Realizzato.................................................................................................................87
5.6 I Risultati Ottenuti.................................................................................................................107
6 Deployment Diagram.....................................................................................................................117
7 Caso di Studio reale: Il Monitoraggio della Rete del Tier2...........................................................120
7.1 I Servizi Monitorati................................................................................................................120
7.2 Risultati Ottenuti....................................................................................................................122
8 Considerazioni conclusive.............................................................................................................137
9 Appendice......................................................................................................................................140
9.1 Guida D'Uso Di Weathermap.................................................................................................140
9.2 Warning Ed Errori Di Weathermap........................................................................................155
9.3 Il Protocollo SNMP...............................................................................................................162
9.4 Codice Dei Grafici Implementati Con RRDTool..................................................................165
Bibliografia.......................................................................................................................................188
Sitografia..........................................................................................................................................189
1
Introduzione
Le reti sono diventate un elemento di fondamentale e vitale importanza per un
qualsiasi Ente o Azienda. Negli ultimi anni realizzare una semplice infrastruttura di
rete non è più sufficiente, da essa ci si aspetta Affidabilità, Sicurezza e Performance, al
fine di offrire pieno supporto ad applicazioni innovative quali Multimedia, e-Learning,
Telemedicina, Griglie, Osservazione della Terra e Supercalcolo.
L’Affidabilità definisce la capacità da parte di un’entità a svolgere una funzione
richiesta, sotto certe condizioni e per un intervallo di tempo.
Per sicurezza di una rete o di un sistema d'informazione s’intende la capacità di
resistere a eventi imprevisti o ad atti dolosi, che compromettono la disponibilità, e
l'integrità o la riservatezza dei dati conservati o trasmessi.
La performance è un modello di misurazione dei tempi di risposta.
Per l’Istituto Nazionale Fisica Nucleare che promuove, coordina ed effettua ricerche
scientifiche in svariati campi, caratteristiche come l'affidabilità, la sicurezza e la
performance sono aspetto di cruciale importanza.
Sono proprio queste prerogative a far nascere l'esigenza di realizzare, per l'Istituto
Nazionale Fisica Nucleare di Napoli, un sistema per il monitoraggio della rete del
centro di calcolo Tier2, al fine di valutare, garantire e migliorare l'Affidabilità e la
Performance di questo Data Center.
Come linea guida, per raggiungere questi obbiettivi, viene applicato un particolare
modello chiamato “Deming Cycle”.
Il ciclo di Deming può essere suddiviso nelle seguenti quattro fasi: Plan, Do, Check e
Act.
Nella fase Plan sono stati definiti gli obbiettivi da raggiungere, è stata effettuata
Alfonso Palma 566/1880
Pagina 1 di 190
un'attenta analisi della rete del Tier2, studiando singolarmente ogni apparato, e la sua
configurazione all'interno della rete.
Sempre in questa fase, sono state date anche le basi per la progettazione del sistema di
monitoraggio della rete.
Nella fase Do è stato fatto un censimento dell'intera rete, realizzando mappe ben
dettagliate degli apparati e della topologia della rete. Fatto ciò, sempre in relazione a
questa fase, è stato sviluppato il software per il monitoraggio della rete.
Nella fase di Check, attraverso il sistema di monitoraggio realizzato, è stato possibile
monitorare la rete del Tier2, rilevando eventuali malfunzionamenti, come: congestione
della rete, errori o perdita di informazioni.
Dopo la fase di monitoraggio della rete si è giunti alla fase Act, in cui è stato possibile
modificare la configurazione di alcuni apparati della rete, al fine di aumentare e
garantire l’affidabilità e la Performance del Data Center.
Il sistema realizzato da la possibilità all'utente di accedere a tutte le funzionalità di
monitoraggio della rete del Tier2 in modo diretto e semplificato, comunicando
informazioni indispensabili per il rendimento ottimale del Data Center del Tier2.
Con questo strumento è possibile monitorare in tempo reale oltre che alla banda
occupata su tutti i link di interconnessione dei nodi (apparati attivi), e lo stato dei
dispositivi della rete, anche gli errori e i pacchetti persi durante lo scambio dei dati.
Tutto ciò, contribuisce a tenere alta l’affidabilità e l’efficienza dell’intera rete, grazie
anche alle notifiche che il sistema inoltra in caso di anomalie e/o di guasti.
In sintesi il mio lavoro di tesi si è sviluppato nelle seguenti fasi:
•
Analisi dell'Infrastruttura della rete, studiando singolarmente ogni apparato e
in che modo esso è collegato e configurato all'interno della rete,
•
Censimento degli apparati e della rete,
•
Realizzazione della mappa Topologica della rete,
Pagina 2 di 190
•
Realizzazione di mappe dettagliate di tutti gli apparati della rete,
•
Analisi e scelta degli strumenti software da utilizzare,
•
Realizzazione di una guida dettagliata per l'installazione di Cacti e del
Plugin Weathermap, disponibile on line sul forum di cacti, versando il mio
contributo alla comunità Open Source,
•
Test Preliminari effettuati sulle apparecchiature della Control Room con
cacti ed il Plugin Weathermap.
•
Progettazione e Realizzazione del sistema di monitoraggio della rete del
Tier2 di Napoli,
•
Configurazioni delle componenti utilizzate, e implementazione di script ad
hoc,
•
Pubblicazione e configurazione del sistema di monitoraggio sul server
virtusatlas01, per l'accesso del sistema via web, raggiungibile all'indirizzo
http://tier2-cacti.na.infn.it/cacti/,
•
Integrazione dell'applicazione realizzata nel Portale del Tier2 di Napoli,
raggiungibile all'indirizzo web http://tier2.na.infn.it/,
•
Caso di studio reale: Monitoraggio della rete del Tier2 attraverso il sistema
che ho realizzato,
•
Proposta di riconfigurazione di alcuni apparati attivi della rete, in seguito al
caso di studio effettuato, al fine di aumentare l'Affidabilità e la Performance
della rete del Tier2 di Napoli.
L'obbiettivo di realizzare un sistema di monitoraggio, per la rete di un sistema di
calcolo distribuito ad alte prestazioni e ad alta affidabilità, è stato raggiunto con ottimi
risultati. Tanto che, il mio lavoro è stato anche presentato alla Conferenza GARR 2010
che si è tenuta presso il Politecnico di Torino dal 26 al 28 Ottobre 2010. Il titolo del
progetto, in cui è stato presentato il sistema di monitoraggio realizzato è: un portale di
monitoraggio centralizzato per i centri di calcolo distribuito.
Pagina 3 di 190
2
Principali Caratteristiche di una Rete
2.1
Affidabilità
L'Affidabilità di un Network è definita come la probabilità che un sistema continui a
funzionare per un certo periodo di tempo, date particolari condizioni fisiche
dell'ambiente in cui si trova, tenendo conto anche del carico a cui esso è sottoposto.
La maggior parte delle applicazioni di comunicazione, che vanno dalle conversazioni
telefoniche alle operazioni con carte di credito, assumono la disponibilità di una rete
affidabile. A questo livello ci si aspetta che i dati, attraverso la rete, arrivino integri a
destinazione [23].
Talvolta i sistemi fisici che compongono una rete, sono sottoposti ad una vasta gamma
di problemi, che vanno dalla distorsione del segnale ai guasti delle componenti [23].
Allo stesso modo, il software che supporta l'interfaccia ad alto livello spesso contiene
bug sconosciuti e altri problemi di affidabilità latenti.
A questo proposito definiamo una gerarchia di classi di malfunzionamenti, al fine di
comprendere come l'affidabilità di una rete possa fallire:
1. Nella prima classe di malfunzionamenti si considerano gli errori a livello di bit.
Mentre un pacchetto viene trasmesso lungo un canale fisico di connessione,
possono essere introdotti dei bit di errori, in modo da confrontare i bit prima e
dopo l'avvenuta trasmissione. In modo da capire se ci sono state delle
alterazioni dei dati. Se a causa della diafonia, questi bit di errore vengono
alterati, non sarà più possibile capire se c'è un'alterazione dei dati trasmessi [1].
2. Nella seconda classe di malfunzionamenti si considerano gli errori non a livello
di bit, ma a livello di pacchetto. Ovvero quando un intero pacchetto viene
perduto dalla rete. Questo accade quando uno dei nodi della rete, switch o
Pagina 4 di 190
router, che inoltra il pacchetto sia sovraccarico e quindi elimini il pacchetto
perché non ha più spazio per memorizzarlo: congestione della rete.
Oppure, meno frequentemente, è possibile perdere un pacchetto a causa del
software di gestione di un nodo, che inoltra in pacchetto su una linea di
connessione sbagliata [2].
3. La terza classe di malfunzionamenti si riferisce a problemi di collegamento:
linea fisica interrotta o di un nodo. Ciò può essere causato guasti hardware e/o
software, o da un errore di configurazione di un dispositivo di rete. Anche se
questi guasti vengono risolti, possono avere un impatto negativo sulla rete. Una
delle difficoltà legata a questa classe di malfunzionamenti è la distinzione tra un
computer lento ed uno semplicemente guasto. Oppure nel caso di una linea di
collegamento, distinzione tra un mezzo fisico che è stato interrotto e uno che
introduce un numero di errori elevato [1].
Esistono svariate tecniche per gestire i malfunzionamenti elencati, in modo da
garantire l'Affidabilità dei dati trasmessi, e di un Network.
2.1.1 Come la topologia di una rete può influenzare l'affidabilità
L'affidabilità di una rete implica a sua volta l'adozione di apparecchiature affidabili e
di una progettazione della rete che tenga conto di difetti ed errori di funzionamento.
E' necessario progettare reti in grado di “ri-convergere velocemente”, in modo da
escludere i difetti di funzionamento che vengono riscontrati.
In questo caso si fa riferimento ad una topologia di rete ridondante. Uno degli
obbiettivi principali di queste topologie, riguarda l'eliminazione dei periodi di
interruzione della rete dovuti a un singolo punto di malfunzionamento. Quindi, tutte le
reti dovrebbero definire qualche forma di ridondanza per aumentare l'affidabilità [3].
Un esempio:
Pagina 5 di 190
Una rete di strade può essere pensata in analogia a una topologia di rete con
ridondanza. Se una strada particolare risulta interrotta per manutenzione o per qualsiasi
altro motivo, è probabile che si possa sempre definire un percorso alternativo che
conduca a una stessa destinazione [1].
2.1.2 Metriche ed analisi di un Modello per la valutazione dell'affidabilità
di una rete
Una rete, sia essa logica o fisica, è rappresentabile da un grafo G(N,E) di N nodi ed E
archi. Lo studio di questi sistemi inevitabilmente porta ad una valutazione sia della
loro efficienza in termini prestazionali, sia dell'efficienza in termini di affidabilità che
questi offrono [21].
Diverse possono essere le metriche per valutare la bontà di un network:
•
Brandwith,
•
Costo,
•
Affidabilità,
•
Complessità,
•
...
Nei casi pratici, ciò che viene fatto a livello di design del network, è effettuare un
Trade-Off rispetto alle priorità che si hanno nella progettazione. Un Trade-Off è una
situazione che implica una scelta tra due o più alternative, in cui la perdita di valore di
una, costituisce un aumento di valore in un'altra [22].
Effettuando un Trade-Off tra le metriche per valutare la bontà di un network,
interessandoci dell'affidabilità di un rete, suggeriamo un modello in cui le variabili
siano riassumibili come [21]:
•
Archi
•
Nodi
Pagina 6 di 190
•
Capacità dei Nodi
•
Capacità degli Archi
•
Traffico istantaneo-medio che passa per un arco e deve essere elaborato da un
nodo
Non è semplice analizzare questo modello soprattutto senza l'ausilio di calcolatori e di
applicazioni dedicate al calcolo di ogni variabile.
Per nodi si intendono gli apparati di una rete: come switch e router (apparati attivi), ma
anche server. Mentre per archi si intendono i collegamenti fisici tra i nodi.
Per capacità dei nodi e degli archi si intendono i requisiti funzionali dei dispositivi, ad
esempio la velocità di inoltro (milioni di pacchetti al secondo) di un router o switch, o
la massima larghezza di banda di inoltro etc.
Per analizzare il traffico che passa per gli archi attraversando dei nodi occorrono
strumenti software per monitoraggio della rete. In questo caso definiremo l'Affidabilità
come la probabilità che un nodo sia in grado di comunicare con tutti gli altri nodi per
un dato periodo di tempo, e chiaramente, viceversa [2].
Dal punto di vista fisico, conoscere gli archi, i nodi e la loro capacità non basta,
occorre conoscere la disposizione geometrica dei collegamenti e dei nodi che
costituiscono la rete, ovvero la topologia.
2.2
Sicurezza
Le persone interagiscono ogni giorno con le reti, ad esempio quando eseguono
operazioni bancarie, effettuano telefonate o viaggiano con treni e aerei.
Le grandi società per tenere traccia dei proprio servizi, per effettuare pagamenti e per
emettere fatture utilizzano le reti. La vita senza le reti sarebbe meno facile e molte
attività sarebbero impossibili. Non bisogna sorprendersi dal fatto che le reti di
computer siano l'obbiettivo preferito, sia oggi che in futuro, da parte degli aggressori.
Visto il loro impatto potenziale ed effettivo, gli attacchi alle reti attraggono l'attenzione
Pagina 7 di 190
di manager, giornalisti e del grande pubblico [4]. Documentandosi su Internet,
leggendo giornali o riviste è possibile trovare notizie su “attacchi alle reti
informatiche”. La trattazione stessa evoca un senso di malvagità, perché utilizza
termini come hijacking, virus, worm e cavalli di Troia che esprimono una vera e
propria minaccia alla sicurezza delle reti informatiche [3].
Per minacce alla sicurezza si intendono tutti quegli avvenimenti che possono avere
come conseguenza la perdita dei requisiti generici e/o di sicurezza delle informazioni.
Una rete di telecomunicazione per essere considerata sicura, e quindi garantire i dati
che vi transitano, deve soddisfare almeno i seguenti requisiti: confidenzialità,
disponibilità e integrità [4].
Confidenzialità delle informazioni: solo chi ha il diritto può accedere, conoscere e
trattare i dati.
Disponibilità delle informazioni: possibilità da parte degli utenti di accedere ai dati in
qualsiasi momento. I sistemi devono soddisfare le richieste di accesso.
Integrità delle informazioni: i dati non possono essere manomessi, persi o
danneggiati.
Vengono definite minacce alla sicurezza delle reti anche catastrofi ambientali o errori
umani che causano la caduta della rete; pertanto la sicurezza di una rete o di un sistema
d'informazione va per tanto intesa come la capacità di resistere ad eventi imprevisti o
atti dolosi che compromettono la disponibilità, l'integrità o la riservatezza dei dati
conservati o trasmessi, nonché dei servizi forniti e accessibili tramite la suddetta rete o
sistema. A questo punto focalizziamo l'attenzione su ciò che può provocare la caduta di
una rete.
Caduta della Rete
Gran parte delle reti sono controllate e informatizzate da un sistema informatico, un
Pagina 8 di 190
computer, la cui disfunzione provoca una caduta della rete. In passato gli attacchi
erano rivolti soprattutto verso questi computer. Attualmente, invece, vengono sfruttate
le debolezze e le vulnerabilità dei componenti della rete (sistema operativo, router,
switch, Domain Name System, etc.) per sferrare gli attacchi e causare gravi
interruzioni.
Qualche esempio :
Attacchi rivolti ai router: il routing su Internet è estremamente decentrato ed ogni
router comunica regolarmente con gli altri router che reti deve conoscere e come
raggiungerle [4]. La vulnerabilità sta nel fatto che queste informazioni non possono
essere verificate perché, per esigenze di progettazione, ogni router ha una conoscenza
minima della topologia della rete. Quindi, ognuno di essi può spacciarsi come la strada
migliore da intercettare per una determinata destinazione, in modo da bloccare o
modificare il traffico diretto a tale destinazione.
I computer funzionano con le applicazioni software. Tali applicazioni possono essere
utilizzate anche per spegnere un computer o per cancellare o modificare i dati che vi
sono contenuti. Come indicato in precedenza, se il computer in questione fa parte del
sistema di gestione della rete, una sua anomalia di funzionamento può ripercuotersi
sugli altri componenti della rete stessa. Esistono dei software maligni (malicious
software) che sono sviluppati proprio con l'obbiettivo di modificare o distruggere dati
una volta mandati in esecuzione [4]. Questi software possono assumere molteplici
forme : alcuni danneggiano solo il computer sul quale vengono copiati mentre altri si
propagano verso altri computer della rete. Ad esempio, esistono programmi (logic
bombs) che rimangono inerti fino al momento in cui vengono innescati da un
determinato evento, come ad esempio una data [4]. Altri programmi sembrano
inizialmente benigni ma, una volta attivati, distruggono tutto (Cavalli di Troia).
Una gestione poco oculata della capacità della rete può causare una congestione del
traffico che rallenta o paralizza i canali di comunicazione aumentandone la
vulnerabilità.
Pagina 9 di 190
E' difficile valutare i danni reali e potenziali di una violazione della sicurezza delle reti
perché non esiste un sistema di segnalazioni sistematiche, anche perché molte imprese
preferiscono non ammettere di essere state vittima di attacchi informatici per timore di
pubblicità negativa.
La sicurezza delle reti e delle informazioni è un problema evolutivo. L'evoluzione
tecnologica pone continuamente nuove sfide per i responsabili della sicurezza, i
problemi di ieri sono risolti ma le soluzioni di oggi sono già superate.
2.3
Performance
Con il termine Network of Performance ci si riferisce alla qualità del servizio di un
sistema di telecomunicazioni e non a un tentativo di come “ottenere di più” attraverso
la rete.
Qualità di Servizio o dall'inglese Quality of Service indica la qualità del servizio
offerto dalla rete di telecomunicazione, o gli strumenti per ottenere una qualità
desiderata [4].
Il modello Quality of Service si riferisce ad applicazioni chiamate inelastiche, ovvero
servizi che richiedono un certo livello di banda per funzionare (se ottengono più banda
non la sfruttano e se ne ottengono di meno non funzionano affatto). Viceversa le
applicazioni elastiche possono funzionare anche su reti con prestazioni molto
degradate e se possibile, usare l'intera banda a disposizione se questa è abbondante.
Esempio di alcune applicazioni inelastiche che richiedono una qualità del servizio :
•
Telefonia VoIP
•
Multimedia Streaming
•
Link dedicati che richiedono sia un throughput garantito che un ritardo
massimo limitato.
Pagina 10 di 190
•
Servizi critici per la sicurezza che richiedono un livello garantito per la
disponibilità.
La qualità del servizio è influenzata positivamente dalle risorse utilizzate per realizzare
e gestire la rete, e negativamente con il traffico offerto alla rete.
2.3.1 Valutazione delle prestazioni di una rete
Le reti possono essere informalmente classificate in reti ad alta o a bassa velocità.
L'uso di queste locuzioni è inadeguato perché un sistema che tre o quattro anni fa era
considerato veloce, oggi grazie allo sviluppo delle tecnologie può essere considerato
relativamente lento. Non a caso vengono definiti i parametri quantitativi che
definiscono le misure di prestazione di una rete.
•
Ritardo
Il ritardo (delay) indica il tempo, espresso in secondi, necessario per trasferire un bit da
un computer all'altro nella rete. Esistono diversi tipi di ritardo:
Il ritardo di propagazione (propagation delay) è il tempo necessario ai segnali per
attraversare un conduttore o una fibra ottica, quantità proporzionale alla distanza. Per
esempio in una rete locale di un edificio si ha in genere un ritardo di propagazione di
un millisecondo. Tale valore può apparire irrilevante, ma per un calcolatore che è in
grado di eseguire più di centomila istruzioni in un millisecondo, diventa un ritardo
significativo.
Il ritardo di commutazione (switching delay) è il tempo che un dispositivo elettronico
(switch, router) attende per l'arrivo di tutti i bit di un pacchetto più il tempo che
impiega per scegliere dove instradare il pacchetto.
Ritardo di accesso (access delay) è il tempo di attesa per il permesso ad usare un
Pagina 11 di 190
mezzo di trasmissione condiviso.
Ritardo di accodamento (queueing delay), ciascun commutatore accoda i pacchetti in
arrivo durante il processo di store and forward, se la coda non è vuota, l'ultimo
pacchetto dovrà aspettare l'instradamento di quelli che lo precedono.
Il ritardo della rete, misurato in secondi, specifica il tempo di permanenza di un
singolo bit sulla rete.
•
Rendimento
Il rendimento (throughput) misura della velocità alla quale si possono trasmettere dati
tramite la rete. Solitamente tale velocità viene espressa in bit per secondo (bps), ma
nella maggior parte delle reti viene espressa in mega bit per secondo (Mbps) o Giga bit
per secondo (Gbps) [3]. Il rendimento può essere misurato in modi diversi infatti la
capacità di rendimento della rete fisica è definita larghezza di banda. Anche il termine
velocità è usato come sinonimo di rendimento ma è sbagliato. Il rendimento è una
misura della capacità della rete e non della velocità, esso è misurato in bit al secondo,
specificando la quantità di bit che possono accedere alla rete in un secondo.
Rendimento e ritardo non sono completamente indipendenti. Se il traffico su una rete è
eccessivo, si dice che la rete è congestionata. Al crescere del traffico, il ritardo cresce.
Una rete che sfrutti quasi tutta la sua capacità avrà presumibilmente ritardi molto
rilevanti.
2.3.2 Metriche in dettaglio
One-way Delay: differenza tra il tempo di spedizione e il tempo di ricezione
dell'ultimo bit del pacchetto, inviato dal mittente al destinatario. Include
principalmente i seguenti ritardi : ritardo di commutazione, di accodamento e di
propagazione.
Round Trip Time: indica il tempo complessivo che impiega un pacchetto per giungere
Pagina 12 di 190
dal mittente al destinatario più quello che lo stesso pacchetto ci mette per tornare
indietro dal destinatario al mittente. Il calcolo dell'RTT ha il vantaggio di non
richiedere che il mittente e il destinatario abbiano gli orologi sincronizzati, in quanto
viene calcolato come differenza di due tempi assoluti all'interno della stessa macchina.
Quindi utilizzando lo stesso orologio del sistema.
Delay unit: è il minimo valore dell’insieme del one-way delay all’interno dell’insieme
di campioni. E’ un numero puro che può essere compreso fra 1 ed infinito.
TX unit: è il tempo ideale che impiegherebbe un pacchetto senza considerare i ritardi
introdotti dagli accodamenti e dai tempi di elaborazione nei router. Il tempo teorico
dipende dalla dimensione del pacchetto e dalla velocità dei collegamenti che lo
trasportano.
2.4
L'Importanza di un Sistema di Monitoraggio
Qualsiasi Azienda o Ente Scientifico, che utilizza un sistema telematico, interessa
monitorare la propria rete, per garantire Affidabilità, Sicurezza e Performance. Sono
proprio queste esigenze, che permettono di comprendere l'importanza dell'utilizzo di
uno strumento software per il controllo e la gestione della rete.
Attraverso
uno
strumento
di
monitoraggio,
è
possibile
rilevare
eventuali
malfunzionamenti della rete, come: congestione, errori o perdita di informazioni, tutto
ciò che influisce negativamente sull'Affidabilità, Sicurezza e Performance.
Sono proprio queste prerogative a far nascere l'esigenza di sviluppare un sistema di
monitoraggio per una rete, ad alte prestazioni e ad alta affidabilità, come quella del
Tier2 di Napoli.
Pagina 13 di 190
2.5
Le regole della qualità applicate alle Reti (Deming Cycle)
Il ciclo di Deming, chiamato anche ciclo PDCA (Plan, Do, Check, Act), è uno
strumento che serve a promuovere il miglioramento continuo della qualità in un ottica
a lungo raggio [6]. La forza di questo strumento consiste nella sua capacità di
prescindere dal contenuto dei progetti che si intendono sviluppare per concentrarsi
prevalentemente sulla loro forma, che viene supposta come invariante. Deming in
sostanza dice che qualsiasi processo può essere visto come un ciclo che ha quattro
momenti : innanzi tutto bisogna pianificare e progettare ciò che si vuole fare (prima
fase – Plan); poi si sperimenta mettendo in pratica le attività pianificate in un'area
limitata (seconda fase – Do); controllare i benefici di tali attività e si apportano le
eventuali correzioni al progetto iniziale (terza fase – Check); a questo punto si procede
nell'applicazione estesa delle attività progettate(quarta fase – Act).
Una delle versioni più conosciute del ciclo PDCA :
plan:
•
determinare obiettivi e destinatari,
•
determinare metodi per raggiungere gli obiettivi,
•
impegnarsi nell'istruzione e nella formazione,
•
svolgere il lavoro,
do:
check:
•
controllare gli effetti,
act:
• intraprendere azioni appropriate (correggere o stabilizzare il sistema),
• riavviare il ciclo di intervento.
Pagina 14 di 190
Figura 2.1 - Ciclo di Deming
Questo modello viene applicato come linea guida per la realizzazione di un sistema di
monitoraggio per la rete del Tier2 di Napoli, al fine di valutare l'affidabilità e la
performance.
Elenchiamo le seguenti fasi:
Plan:
•
Migliorare l'affidabilità e la performance della rete, e quindi del data
center,
•
Analisi dell'intera rete studiando singolarmente gli apparati e in che
modo essi sono collegati,
•
Progettazione di uno strumento software per il monitoraggio della rete,
•
Censimento degli apparati e della rete,
•
Realizzazione della mappa Topologica della rete,
•
Realizzazione delle mappe degli apparati attivi della rete,
•
Sviluppo di uno strumento software per il monitoraggio della rete del
Do:
Pagina 15 di 190
Tier2,
•
Messa in esercizio del sistema realizzato per il monitoraggio della rete.
Check:
•
Monitoraggio della Rete del Tier2,
•
Controllo della configurazione degli apparati.
•
Proposta di riconfigurazione di alcuni apparati attivi della rete, per
Act:
aumentare l'Affidabilità e o la Performance,
•
Messa in esercizio del sistema di monitoraggio sviluppato.
Pagina 16 di 190
3
Analisi dell'Infrastruttura della Rete
3.1
Che cos'è il Tier2
Il modello gerarchico di calcolo dei vari esperimenti di Fisica Subnucleare che
utilizzano l'acceleratore LHC (Large Hadron Collider), è a Multi-Tier.
L'Event Filter Farm che si trova al CERN di Ginevra, organizza i dati grezzi
dall'esperimento in uno stream di dati da passare al Tier0:
•
Il Tier0 si trova al CERN, in esso avviene la produzione dei dati da inviare ai
Tiers di livello inferiore. Il Tier0 esegue una prima fase di calibrazione ed
allineamento dei dati di output di LHC, ed effettua una loro prima ricostruzione.
Successivamente l'output ricostruito viene inviato ai Tier1.
•
Il Tier1 di livello nazionale o internazionale, effettua un'analisi e parte della
ricostruzione, assieme all'immagazzinamento degli altri tipi di oggetti.
•
Il Tier2, centri regionali (Laboratori e Università). Esegue job di analisi e
simulazioni sui dati. I risultati di queste operazioni vengono passati al Tier3.
•
Il Tier3, raccoglie i singolo istituti o dipartimenti, ovvero è il luogo dove
avviene fisicamente l'analisi dei dati.
•
Infine il Tier4, rappresenta i singoli desktop dei Fisici.
Ogni Tier mantiene una copia dei dati che ha elaborato in modo da usarli come
esempio per le prossime elaborazioni e per fare in modo che il livello successivo possa
recuperarli se necessario.
Con il termine Tier-n si indica il centro di calcolo che si pone al livello n-esimo
all'interno della gerarchia.
Pagina 17 di 190
3.2
La Rete del Tier2
La rete del Tier2 è situata presso il Complesso Universitario di Monte Sant'Angelo di
Napoli.
Tale rete è divisa in due componenti: una componente interna che riguarda la struttura
interna della rete, ed una esterna che si riferisce al collegamento alla rete geografica.
La componente interna è predisposta in due livelli: un primo livello che si trova
fisicamente nel Data Center dell'INFN e un secondo livello che si trova nel Data
Center di S.Co.P.E..
Il punto centrale della rete, che si trova nel primo livello, è il router-atlas 1, un Cisco
Catalyst 3750 che è il Centro Stella della rete del Tier2 di Napoli. A questo Centro
Stella sono collegati altri apparati attivi, definendo tale rete, una Rete a Stella Estesa.
Quindi ai componenti attivi, collegati al Centro Stella, troveremo collegati altri
componenti.
Di seguito rappresentiamo tutti i componenti attivi collegati al Centro Stella:
1. un Cisco Catalyst 3750 denominato mercurio1. Il collegamento tra questo router
ed il router-atlas1 avviene in fibra ottica a 1 Gbps.
Mercurio1 è collegato al POP GARR e ad uno switch Cisco 6509, chiamato
cat65091.
Questi apparati costituiscono i capisaldi della Local Area Network del
dipartimento di Fisica, ma ovviamente ci sono altri componenti attivi che
costituiscono tale rete. Nel nostro caso focalizziamo l'attenzione sugli apparati
che interagiscono direttamente con la rete del Tier2.
La connessine tra mercurio1 e il POP GARR permette alla rete di Fisica di
accedere all'esterno, quindi al “mondo” di Internet e dei tanti altri servizi offerti
da esso. Il cat65091 costituisce la vera e propria LAN di Fisica, con tutti i client
e servizi di monitoraggio e gestione della rete, con la seguente classe
172.16.X.X.
1 Domain Name System
Pagina 18 di 190
Il collegamento tra suddetti apparati, avviene in fibra ottica a 1 Gbps.
1. il GigaPOP GARR, che è collegato alla rete GARR [17].
Su questo collegamento viene adottato un controllo di Taffic Shaping. Ovvero
un insieme di operazioni di controllo sul traffico dati, finalizzate a ottimizzare o
a garantire le prestazioni di trasmissione. In modo da ridurre o controllare i
tempi di latenza e sfruttare al meglio la banda disponibile [18].
Il collegamento tra questi apparati, avviene in fibra ottica a 1 Gbps.
2. uno switch della 3COM 4500G denominato sw3com-atlas021, che a sua volta è
collegato con altri due 3COM 4500G : sw3com-atlas011 e sw3com-atlas031. Il
router-atlas1 è collegato in Link Aggregation con lo switch sw3com-atlas021 a 2
Gbps in rame.
Gli switches sw3com-atlas011, sw3com-atlas021 e sw3com-atlas031 sono
collegati tra di loro in Local Connection a 10 Gbps con cavi CX42. In questa
configurazione il dispositivo definito master è lo switch sw3com-atlas021.
Questo dispositivo è collegato in fibra ottica a 1 Gbps con lo switch Dell 2748
denominato swdell-scope011, a sua volta questo e collegato in up link allo
switch linksys 2024 chiamato linksys-cs1, collegamento in rame a 1 Gbps. Lo
switch sw3com-atlas021 è collegato in fibra ottica a 1 Gbps al cat6509 1,
appartenente alla LAN di Fisica, nominato precedentemente.
A questo punto descriviamo il secondo livello della componente interna della
rete in questione.
Allo switch sw3com-atlas021 sono collegati due switch Dell 6248 in Stacking,
che grazie a questo tipo di configurazione, figurano come un unica unità
logica : swdell-atlas011.
Il collegamento tra sw3com-atlas021, che si trova nel Data Center di Fisica, e lo
swdell-atlas011, che si trova nel data Center di S.Co.P.E., avviene con un tipo di
fibra ottica mono modale 9/125, che attraversa diversi Patch Panel nei vari
2 Cavi utilizzati per ottenere connessioni a 10 Gigabit tra Local Connection Module
Pagina 19 di 190
rack.
Per garantire una certa affidabilità e ridondanza alla rete, oltre alla fibra ottica
che abbiamo citato, esiste un'altra fibra ottica mono modale 9/125, e che collega
il Data Center di Fisica con il data Center di S.Co.P.E.. Attualmente questa fibra
è scollegata, ma disponibile per ogni tipo di evenienza.
Allo switch swdell-atlas011 è collegato in up link un altro switch Dell 6248 :
swdell-atlas021, e uno switch della 3COM 4500G : sw3com-atlas041.
Il collegamento tra swdell-atlas011 e sw3com-atlas041 avviene in fibra ottica a
10 Gbps, tra swdell-atlas011 e swdell-atlas021 avviene in up link a 1 Gbps in
rame.
Dal Centro Stella partono i collegamenti per i vari rack di Worker Nodes e i Disk
Server, dove si trovano le macchine virtuali che monitorano e gestiscono la rete.
La componente esterna si riferisce al collegamento del Tier2 con la rete geografica.
Il Centro Stella del Tier2 di Napoli è collegato al Tier1 dell'INFN-CNAF di Bologna,
attraverso un link dedicato della capacità di 1 Gbps che attraversa vari POP GARR, tra
cui il POP GARR che si trova a Monte Sant'Angelo nei Centri Comuni presso il CSI.
Il collegamento a 1 Gbps dedicato è utilizzato per il centro di calcolo (Tier2) coinvolto
nel progetto LHC (www.cern.ch/lhc) .
3.2.1 Configurazioni in Dettaglio
Durante l'analisi dell'Infrastruttura della rete del Tier2 abbiamo citato delle
configurazioni di alcuni apparati : Stacking Configuration e Local Connection.
Vale la pena soffermarsi su questi tipi di configurazioni al fine di comprendere le vere
potenzialità della rete in questione.
La configurazione Local Connection avviene tra i switches della 3COM 4500G con i
Pagina 20 di 190
seguenti domani name system : sw3com-atlas01, sw3com-atlas02 e sw3com-atlas03.
Ciascuno dispone di due slot posteriori per moduli di 10 Gigabit Local Connection,
collegati per mezzo dei cavi CX4 di lunghezza massima di 300 cm.
Questo tipo di connessione permette di avere prestazioni 10 volte superiori rispetto al
Gigabit Ethernet, per applicazioni che richiedono notevole ampiezza di banda ed alte
prestazioni tra dispositivi. Local connection rappresenta una tecnologia di
aggregazione perfetta per mettere in collegamento core switch e switch di
distribuzione. Gli switch utilizzati in questo tipo di configurazione offrono scalabilità
stackable con gestione tramite un unico indirizzo IP.
Nel nostro caso, la configurazione adoperata non permette di vedere gli switch come
un unica unità logica e quindi con un unico indirizzo IP. Infatti tra i tre switch elencati,
lo switch master è quello con il seguente DNS: sw3com-atlas02.
La configurazione in Stack dei due switch Dell 6248 fa in modo che essi possano
essere visti come un unica unità logica. Di conseguenza con un unico indirizzo IP ed
un unico DNS: swdell-atlas01.
Questi switch dispongono di due slot posteriori per gli stacking module, che
permettono l'aggregazione di switch per mezzo di appositi cavi : stacking cable.
Lo Stacking supporta alte prestazioni per i sistemi (switch), ciascuno a 48 Gb/s,
consentendo di aumentare la velocità di trasmissione dati in base alle necessità senza
impatti sulle prestazioni di rete.
I principali vantaggi di questo tipo di configurazione sono:
1. Gestione amministrativa della rete semplificata : un unica interfaccia di
gestione per l'amministratore di rete.
2. Scalabilità: una rete può essere realizzata da una pila di switch sovrapponibili,
quindi può essere espansa semplicemente con l'aggiunta di ulteriori unità nel
corso del tempo.
3. Flessibilità della distribuzione: uno switch può operare indipendentemente dalla
pila di cui fa parte.
Pagina 21 di 190
3.2.2 Tabella Apparati della Rete
Di seguito è riportata una tabella che elenca il tipo di dispositivo attivo, con il relativo
DNS e locazione, in modo da facilitare l'individuazione di essi :
Domain Name System
Tipo Dispositivo
Locazione
router-atlas
Cisco Catalyst 3750
Rack 2 - Sala Macchine
INFN
mercurio
Cisco Catalyst 3750
Sala Macchine INFN
cat6509
Cisco 6509
Sala Macchine INFN
sw3com-atlas01
3COM 4500G
Rack 1 – Sala Macchine
INFN
sw3com-atlas02
3COM 4500G
INFN
sw3com-atlas03
3COM 4500 G
INFN
swdell-scope01
DELL 2748
INFN
linksys-cs
LINKSYS 2024
INFN
swdell-atlas01
DELL 6248
Rack 31 – Data Center
S.Co.P.E.
swdell-atlas02
DELL 6248
S.Co.P.E.
sw3com-atlas04
3COM 4500 G
S.Co.P.E.
Tabella 3.1 – Apparati di Rete
3.2.3 Alcuni Dispositivi della Rete in Dettaglio
Al fine di valutare la Performance e l'Affidabilità della rete del Tier2, abbiamo
effettuato un'attenta analisi dei principali dispositivi della rete, elencando
Pagina 22 di 190
caratteristiche dei prodotti e i vantaggi:
➢ Switch Cisco Catalyst 3750
Gli switch Cisco Catalyst 3750 costituiscono una linea di prodotti innovativa che
migliora l'efficienza delle LAN combinando facilità di utilizzo e il grado di resilienza
più elevato disponibile per gli switch stackable. Questi rappresentano la nuova
generazione degli switch desktop ed è basata su Cisco StackWise. Questa tecnologia si
basa su un'architettura di stacking di livello straordinario ottimizzata per Gigabit
Ethernet. Cisco StackWise è progettata per rispondere ad aggiunte, eliminazioni e
ridistribuzioni mantenendo costante il livello delle prestazioni [11].
Grazie agli speciali cavi di interconnessione degli stack e a un software specifico per
lo stacking, con Cisco StackWise è possibile collegare fino a nove switch Cisco
Catalyst 3750 in un'unica unità logica. Lo stack si comporta come un'unica unità di
commutazione gestita da uno switch principale selezionato tra uno degli switch che
compongono lo stack. Lo switch principale crea e aggiorna automaticamente tutte le
tabelle di commutazione e di routing opzionale. Uno stack operativo può accettare
nuovi componenti o eliminarne di vecchi senza alcuna interruzione del servizio [11].
Le caratteristiche principali di questo dispositivo sono:
Facilità di utilizzo - Configurazione “Plug-and-Play”
Gestione e configurazione degli stack sono automatiche. In caso di aggiunta o
rimozione di switch, lo switch principale aggiorna automaticamente tutte le tabelle in
base alle modifiche apportate. Gli aggiornamenti vengono applicati universalmente e
simultaneamente a tutti i componenti dello stack.
Scalabilità - Da Fast Ethernet a Gigabit Ethernet
Con la serie Cisco Catalyst 3750 è possibile collegare in stack fino a nove switch in
un'unica unità logica, per un totale di 468 porte Ethernet 10/100 o 252 porte Ethernet
10/100/1000. Le singole unità 10/100 e 10/100/1000 possono essere collegate in
qualsiasi combinazione, in base alle esigenze della rete.
Pagina 23 di 190
È possibile creare gli stack utilizzando qualsiasi combinazione di switch Cisco
Catalyst 3750.
Disponibilità - Prestazioni non-stop Layer 2 e Layer 3
Con la serie Cisco Catalyst 3750 la disponibilità di switch stackable è aumentata.
Ciascuno switch può funzionare sia da controller principale che da processore di
inoltro. Ciascuno switch dello stack, inoltre, può fungere da switch principale, creando
uno schema di disponibilità di tipo 1:N per il controllo della rete. Nell'improbabile
eventualità di un guasto a una singola unità, tutte le altre unità continuano a inoltrare il
traffico e a garantire il funzionamento della rete.
Smart Multicast - Un nuovo livello di efficienza per reti convergenti
Grazie alla tecnologia Cisco StackWise, la serie Cisco Catalyst 3750 offre una
maggiore efficienza per applicazioni multicast, come ad esempio le applicazioni video.
Ogni pacchetto di dati viene inserito nel backplane una volta soltanto, in questo modo
si ottiene un supporto più efficiente per ulteriori flussi di dati.
Quality of Service - Su tutto lo stack e a velocità wire-speed
Gli switch della serie Cisco Catalyst 3750 offrono velocità Gigabit Ethernet combinata
con servizi intelligenti che assicurano uniformità di flusso, anche a velocità dieci volte
più alta rispetto a quella di una rete normale. Meccanismi avanzati di marcatura,
classificazione e pianificazione forniscono prestazioni da primi della classe riguardo al
traffico di dati o di segnali audio e video, il tutto a livelli wire-speed.
Protezione - Controllo granulare sull'ambiente di accesso
La serie Cisco Catalyst 3750 supporta un set completo di funzioni di protezione per la
connettività e il controllo degli accessi che comprende: ACL, autenticazione,
protezione a livello porta e servizi di rete basati sull'identità con protocollo 802.1x e
sue estensioni.
Gestione con IP singolo - Molti switch, un solo indirizzo
Ciascuno stack Cisco Catalyst 3750 viene gestito come un unico oggetto e ha un solo
indirizzo IP. La gestione con IP singolo è supportata per attività quali rilevazione di
errori, creazione e modifica di LAN virtuali, protezione e controlli QoS (Quality of
Pagina 24 di 190
service).
Frame jumbo - Supporto per applicazioni ad alta richiesta
Gli switch della serie Cisco Catalyst 3750 supportano frame jumbo sulle
configurazioni 10/100/1000 per applicazioni avanzate dati e video che richiedono
frame molto grandi.
Supporto di IPv6 - Pronti per il futuro
Catalyst 3750 supporta il routing IPv6 nell'hardware per prestazioni di altissimo
livello. Con lo sviluppo dei dispositivi di rete cresce il bisogno di un più ampio
indirizzamento e si rende necessaria una maggiore protezione. La serie Catalyst 3750
sarà pronta a soddisfare queste esigenze.
Opzioni di gestione
La serie Cisco Catalyst 3750 offre una CLI (command-line interface, interfaccia di riga
di comando) di livello superiore per configurazioni dettagliate e fornisce il software
Cisco CMS (Cluster Management Suite), un tool su base Web per configurazioni
veloci basate su modelli preimpostati.
Inoltre, CiscoWorks supporta la serie Cisco Catalyst 3750 per la gestione di rete
completa.
Routing IP ad alte prestazioni
L'architettura hardware di routing Cisco Express Forwarding fornisce routing IP ad
altissime prestazioni:
I protocolli base per routing IP unicast (static, RIPv1 [Routing Information Protocol
Version 1] e RIPv2) sono supportati per applicazioni di routing in reti di piccole
dimensioni.
I protocolli avanzati di routing IP unicast (OSPF [Open Shortest Path First], IGRP
[Interior Gateway Routing Protocol], EIGRP [Enhanced IGRP] e BGPv4 [Border
Gateway Protocol Version 4]) sono supportati per il bilanciamento del carico e per la
realizzazione di LAN scalabili. È necessaria un'immagine software EMI (Enhanced
Multilayer Image).
Il routing policy-based (PBR) consente un controllo eccellente abilitando il
Pagina 25 di 190
reindirizzamento del flusso indipendentemente dal protocollo di routing configurato. È
necessaria un'immagine software EMI.
Routing IP Inter-VLAN IP per routing completo Layer 3 tra due o più VLAN. • È
supportato il PIM (Protocol-Independent Multicast) per routing IP multicast. Include
PIM-SM (PIM sparse mode, PIM-DM (PIM dense mode) e PIM sparse-dense mode. È
necessaria un'immagine software EMI.
Il tunneling DVMRP (Distance Vector Multicast Routing Protocol) interconnette 2 reti
abilitate per multicast attraverso reti non multicast. È necessaria un'immagine software
EMI.
Il bridging con fallback inoltra il traffico non IP tra 2 o più VLAN. È necessaria
un'immagine software EMI.
Il routing è abilitato sull'intero stack.
Sono supportate 500 interfacce virtuali di switch (SVI) e un numero illimitato di porte
con routing.
Di seguito rappresentiamo la tabella hardware, tabella 3.2:
Tabella Hardware:
Prestazioni
• Massima larghezza di banda di inoltro 32 Gbps
a switching fabric Layer 2 e Layer 3
• Velocità di inoltro: 38,7 milioni di pacchetti al
secondo (mpps) per pacchetti di
64 byte
• Velocità di inoltro: 6,5 mpps (Cisco Catalyst
3750-24-TS), 13,1 mpps (Cisco Catalyst 375048TS), 35,7 mpps (Cisco Catalyst 3750G-24T),
38,7 mpps (Cisco Catalyst 3750G-24TS)
• 128 MB di DRAM (dynamic random-access
memory) e 16 MB di memoria Flash (Cisco
Catalyst 3750G-24TS, Cisco Catalyst 3750G24T, Cisco Catalyst 3750-24TS e Cisco Catalyst
3750-48TS)
• Fino a 12.000 indirizzi MAC configurabili
(Cisco Catalyst 3750G-24TS, Cisco Catalyst
3750G-24T, Cisco Catalyst 3750-24TS e Cisco
Catalyst 3750-48TS)
Pagina 26 di 190
• Fino a 11.000 route unicast configurabili (Cisco
Catalyst 3750G-24TS, Cisco Catalyst 3750G24T, Cisco Catalyst 3750-24TS e Cisco Catalyst
3750-48TS)
• Fino a 1000 gruppi IGMP e route multicast
configurabili (Cisco Catalyst 3750G-24TS, Cisco
Catalyst 3750G-24T, Cisco Catalyst 3750-24TS e
Cisco Catalyst 3750-48TS)
• Fino a 9018 byte di unità di trasmissione
massima (MTU) configurabili (Jumbo frames)
per bridging su porte Gigabit Ethernet e fino a
1546 byte per bridging e routing su porte Fast
Ethernet
Connettori e cablaggio
• Porte 10BASE-Ts: connettori RJ-45; 2 coppie di
cavi non schermati in doppino UTP (Unshielded
Twisted-Pair), categoria 3, 4 o 5
• Porte 100BASE-TX: connettori RJ-45, 2 coppie
di cavi UTP categoria 5
• Porte 1000BASE-T: connettori RJ-45, 2 coppie
di cavi UTP categoria 5
• Porte 1000BASE-T basate su SFP: connettori
RJ-45, 2 coppie di cavi UTP categoria 5
• Porte 1000BASE-SX, -LX/LH, -ZX e CWDM
basate su SFP: connettori LC in fibra (modalità
singola o multipla)
• Porte di collegamento in stack Cisco StackWise:
cablaggio Cisco StackWise a base di rame
• Porta della console di gestione: cavo da RJ-45 a
DB9 per connessioni di PC
Tabella 3.2 – Caratteristiche Hardware Cisco 3750
➢ Switch 3COM 4500G
La famiglia 3Com Switch 4500, che comprende gli switch Managed Ethernet 10/100
Stackable, fornisce connettività LAN sicura e flessibile per le organizzazioni aziendali
di qualunque dimensione. Si compone di diverse versioni in grado di offrire lo
switching Layer 2 e il routing dinamico Layer 3, nonché una sicurezza efficace,
Quality of Service e funzioni di management per una connettività edge in grado di
gestire le applicazioni e le connessioni aziendali di base [19].
Caratteristiche generali del dispositivo:
Pagina 27 di 190
Sicurezza
La famiglia di Switch 4500 garantisce un accesso sicuro alle risorse, grazie all'utilizzo
del controllo degli accessi alla rete tramite lo standard 802.1X coadiuvato
dall'autenticazione RADIUS per i singoli utenti. Inoltre, il RADA (RADIUS
Authenticated Device Access) consente l'autenticazione dei device collegati attraverso
l'indirizzo MAC, per aumentare la sicurezza complessiva. Le ACL (Access Control
Lists) basate su porta consentono un efficace utilizzo delle policy in ogni punto di
accesso alla rete [19].
Il supporto di Secure Shell (SSHv2) ed SNMPv3 garantisce inoltre una gestione degli
accessi critici, effettuati dal network administrator attraverso l'autenticazione e la
cifratura del traffico di gestione.
VoIP (Voice over IP) dinamico
La funzione voice VLAN,
una esclusiva
dei prodotti 3Com di ultima
generazione,rileva la presenza dei telefoni IP* e assegna dinamiamente le porte switch
alla VLAN vocale, consentendo configurazione e assegnazione automatizzata della
priorità al traffico VoIP. Questa funzione unica riduce al minimo i costi e la
complessità associati all'aggiunta e alla rimozione dei telefoni IP a prescindere dal loro
marchio.
Prestazioni
Pensata per la connettività di rete ad alte prestazioni, la famiglia di Switch 4500
presenta i modelli a 26 porte e a 50 porte che forniscono una capacità di switching
wire speed no blocking fino a 8,8 Gbps e fino a 13,6 Gbps rispettivamente. Gli uplink
Gigabit duali su ogni unità switch consentono i collegamenti ad alta velocità nel
backbone della rete o ai server collegati.
Assegnazione di priorità e gestione della larghezza di banda
Otto code di priorità per porta consentono la Class of Service/Quality of Service
(CoS/QoS) standard 802.1p. La possibilità di limitare la larghezza di banda e le
funzioni di filtraggio del protocollo consentono alla famiglia di Switch 4500 di
applicare i controlli su ogni porta, per un utilizzo efficace delle risorse di rete e
Pagina 28 di 190
l’assegnazione di priorità alle applicazioni “business-critical” o “time-sensitive”,
compreso il VoIP (Voice over IP) [19].
PoE (Power over Ethernet)
Due modelli della famiglia di Switch 4500 forniscono l'alimentazione in linea alle
periferiche collegate mediante il PoE (Power over Ethernet) nello standard IEEE
802.3af. L'alimentazione interna fornisce una potenza erogata di 300 Watt che viene
dinamicamente allocato alle porte PoE. L'alimentazione supplementare può essere
fornita da un sistema DC che fornisce fino a 15,4 watt di potenza alle porte PoE in
switch o stack.
Flessibilità e scalabilità
Due porte Gigabit su ogni modello della famiglia di Switch 4500 possono essere
utilizzate per lo stacking o per la connettività uplink ad alta velocità nel backbone della
rete o nei server locali collegati. Ogni porta Gigabit offre una scelta di supporti in fibra
o rame: 1000Base- T (mediante RJ45) o 1000Base-X (mediante i moduli del
transceiver SFP opzionale).
La funzione di stacking consente di unire fino a 8 unità in uno stack singolo gestito e
di scalare così fino a un massimo di 384 porte 10/100. Un gruppo completo di funzioni
di switching, compreso il filtraggio multicast e il protocollo Rapid Spanning Tree,
consentono di migliorare ulteriormente la scalabilità e la disponibilità delle risorse di
rete.
Gestione e controllo
La famiglia di Switch 4500 è potenziata grazie al sistema operativo di 3Com, lo stesso
codice collaudato che caratterizza gli switch delle famiglie di Switch 5500, nonché dei
grandi sistemi a chassis come Switch 7750 e Switch 8800. La configurazione della rete
e le funzioni di controllo sono accessibili mediante la CLI (command line interface)
oppure utilizzando software di gestione SNMP come EMS (Enterprise Management
Suite) di 3Com e 3Com Network Director [19].
Semplicità d'uso
Il routing dinamico con RIP (Routing Information Protocol) consente l'aggiornamento
Pagina 29 di 190
automatico delle topologie di rete Layer 3. Le modalità fast Ethernet e full duplex su
tutte le porte sono negoziate automaticamente in modo da evitare la possibilità di una
configurazione non corretta. Gli switch rilevano e si adattano alle connessioni via cavo
lineari o incrociate mediante la funzione “Auto MDI/MDIX”, eliminando così la
necessità di dotarsi di cavi diversi per il collegamento delle periferiche di rete.
Prestazioni:
Massima capacità di switching
Modelli a 50 porte: 13,6 Gbps; modelli a 26
porte: 8,8 Gbps
Velocità di inoltro pacchetti massima
Modelli a 50 porte: 10,1 Mpps; modelli a 26
porte: 6,5 Mpps Prestazioni wirespeed in tutte le
porte con stack o fabric Switching store-andforward; latenza <10 µs
Larghezza di banda di uno stacking
Stacking full-duplex da 2 Gbps
Tabella 3.3 – Caratteristiche Prestazionale SW3COM 4500G
Switching layer 2:
Indirizzo MAC
8000 Indirizzi MAC
Indirizzi MAC statici: 12 oltre all'indirizzo
predefinito
VLAN
256 VLAN basate su porta per lo standard IEEE
802.1Q (VLAN x port)
Link Aggragation
LACP (Link Aggregation Control Protocol)
standard IEEE 802.3ad Possibilità di
aggregazione manuale Gruppi di trunk: 25 gruppi
(50 porte); 13 gruppi (26 porte) 8 porte 10/100 o
2 porte Gigabit per gruppo
Auto-negoziazione
Auto-negoziazione della porta Fast
Ethernet/Ethernet – Half/Full Duplex
Controllo del Traffico
Controllo del flusso full-duplex dello standard
IEEE 802.3x Controllo del flusso backpressure
per la modalità half-duplex
Spanning Tree/Rapid Spanning
STP (Spanning Tree Protocol) standard 802.1D
IEEE RSTP (Rapid Spanning Tree Protocol)
standard IEEE 802.1w Protezione BPDU (Bridge
Protocol Data Unit) inclusa in Avvio rapido
Snooping multicast
IGMP (Internet Group Management Protocol)
snooping v1 e v2 IGMP Querier Filtraggio per
Pagina 30 di 190
128 gruppi multicast
Tabella 3.4 – Caratteristiche layer 2 SW3COM 4500G
Switching layer 3:
Route
Routing basato sull'hardware Route statiche: 12
oltre all'indirizzo predefinito ARP Entry (Address
Resolution Protocol) dinamiche/statiche =
1990/10
Routing IP
Interfacce IPv4 = 2000 utilizzando RIP (Routing
Information Protocol) v1 e v2 mediante la route
predefinita più 10 route apprese localmente
Routing muticast
IGMP snooping v1 e v2
Protocollo di rete
DHCP Relay (Dynamic Host Configuration
Protocol): 2 KB max
Tabella 3.5 – Caratteristiche layer 3 SW3COM 4500G
➢ Switch DELL 6248
PowerConnect 6248 è uno degli switch più avanzati di Dell, con funzionalità
fondamentali di switching per aziende di piccole o medie dimensioni.
Questo switch Gigabit Ethernet Layer 3 a 24 porte supporta lo stacking, offre uplink
opzionali a 10 Gigabit Ethernet e supporta la versione più recente di Internet Protocol,
IPv6, per una più ampia scalabilità a livello globale. Lo stacking ad alte prestazioni è
supportato per un massimo di dodici sistemi; le funzionalità avanzate di sicurezza e di
QoS (Quality of Service) rendono questo switch ideale per applicazioni quali Voice
over IP, routing Layer 3, High Performance Cluster Computing (HPPC) e storage
iSCSI [20].
Le caratteristiche principali di questo dispositivo sono:
Alta Densità
Con un'elevata densità rack, il PowerConnect 6248 è progettato per assicurare la
flessibilità necessaria per ottimizzare la connettività di server e workstation in un
Pagina 31 di 190
fattore di forma 1U. È possibile collegare fino a 576 server o client in uno stack di
dodici switch serie 62xx, in modo tale da ottenere densità, flessibilità e gestibilità
ottimali; lo stack è realizzato su uno switch Gigabit Ethernet 10/100/1000 BASE-T
[20].
Stacking ad alte prestazioni
Il PowerConnect 6248 supporta lo stacking ad alte prestazioni di un massimo di dodici
sistemi (ciascuno a 48 Gb/s), che consente di aumentare la velocità di trasmissione dati
in base alle necessità senza impatti sulle prestazioni di rete. Con switch che supportano
fino a 184 Gb/s di capacità ciascuno, il cliente può disporre di quasi 3 Terabyte di
capacità in un unico stack di 12 switch [20].
Funzionalità Layer 3 avanzate
Il PowerConnect 6248 supporta il routing avanzato Layer 3 e i protocolli multicast per
favorire una riduzione della congestione e la gestione del traffico in rete. Sono inoltre
supportati i protocolli di routing LAN di uso frequente, quali RIPv1/v2, OSPFv2/v3,
VRRP, IGMP, DVMRP, PIM e LLDP-MED.
Quality of Service avanzato
Il PowerConnect 6248 offre flessibilità in termini di QoS (Quality of Service) poiché
consente agli amministratori di dare la priorità al traffico di rete più urgente in base a
una serie di criteri definiti dall'utente. Gli amministratori possono in tal modo
velocizzare il traffico in base alle informazioni L2 o L3, come QoS IP, e ottenere un
maggiore controllo del flusso del traffico all'interno della rete. Voice VLAN vengono
fornite in modo specifico per applicazioni VoIP [20].
Sicurezza avanzata
Gli elenchi di controllo di accesso (ACL, Access Control Lists) possono essere
supportati sullo switch, consentendo all'utente l'utilizzo della tecnologia DPI (Deep
Packet Inspection). L'autenticazione della porta 802.1x offre accesso host singolo e
multiplo. Un ulteriore livello di sicurezza è fornito mediante protezione dagli attacchi
Denial of Service (DoS), mentre lo switch protegge da attacchi comuni alla rete e alla
Pagina 32 di 190
CPU [20].
Ipv6 certificato
IPv6 è la versione 6 dell'Internet Protocol, resa disponibile dopo oltre 20 anni di
progettazione. IPv6 è stato progettato per superare le limitazioni nel numero di
indirizzi IP della versione precedente di Internet Protocol e offrire una più ampia
scalabilità a livello globale per le esigenze attuali e quelle future mediante un numero
maggiore di indirizzi IP univoci.
In particolare analizziamo alcune caratteristiche, vedi tabella 3.6:
Connessioni
48 10/100/1000BASE-T auto-sensing Gigabit
Ethernet switching ports
4 SFP combo ports for fiber media support
10 Gigabit Ethernet uplink modules (optional)
48Gbps Stacking module (optional)
Auto-negotiation for speed, duplex mode and
flow control
Auto MDI/MDIX
Port mirroring
Flow-based port mirroring
Broadcast storm control
Prestazioni
Switch Fabric Capacity up to 184 Gb/s
Forwarding Rate up to 95 Mpps
Up to 8,000 MAC Addresses
256MB of CPU SDRAM
32MB of Flash Memory
Prestazioni Routing Layer 3
Up to 128 RIP Routing Interfaces
Up to 128 OSPF Routing Interfaces; up to128
OSPF Areas; up to 128 Routing Interfaces per
OSPF Area; up to 32 routes for ECMP Routing;
up to 2 next hops per ECMP
Up to 128 VLAN Routing Interfaces
Up to 256 Multicast Forwarding Entries
Up to 896 ARP entries; Up to 512 NDP
entries
Routing Layer 3
Static routes
Routing Information Protocol (RIP) v1/v2
Open Shortest Path First (OSPF) v1/v2/v3
Classless Inter-Domain Routing (CIDR)
Internet Control Message Protocol (ICMP)
ICMP Router Discover Protocol (IRDP)
Pagina 33 di 190
Virtual Redundant Routing Protocol (VRRP)
Address Resolution Protocol (ARP)
Internet Group Management Protocol (IGMP) v2
Distance-Vector Multicast Routing Protocol
(DVMRP)
DHCP – Helper/Relay
Tabella 3.6 – Caratteristiche switch swDell 6248
3.3
Le Mappe Realizzate
In seguito ad un'attenta analisi effettuata su tutta Rete del Tier2, e ad uno studio
approfondito sull'apparecchiature e sulle configurazioni di esse, è stato possibile
realizzare mappe generali della rete e mappe dettagliate degli apparati.
Lo scopo della realizzazione delle mappe è stato quello di dare subito un idea ben
chiara di come è predisposta la rete e da quali componenti è costituita. Si parte dalla
rappresentazione generale della rete per poi finire con una rappresentazione dettagliata
degli apparati, e dei collegamenti tra di essi.
Le mappe sono state realizzate inizialmente con Dia, un programma utilizzato per la
creazione di grafici e vari tipi di diagrammi, ma visto alcuni limiti del programma
nella realizzazione di mappe, si è scelto di utilizzare Office Visio.
Office Visio è un software per la creazione di grafici e diagrammi, sviluppato da
Microsoft.
Nello sviluppo delle mappe siamo stati molto attenti nel non trascurare nulla, a partire
dal tipo di cavo utilizzato per la connessione, fino ad arrivare al DNS dei dispositivi.
Pagina 34 di 190
3.3.1 Mappa generale della Rete
Figura 3.1 – Mappa generale della rete
Pagina 35 di 190
3.3.2 Mappe degli Apparati
Figura 3.2 – Mappa degli Apparati sezione INFN
Pagina 36 di 190
Figura 3.3 - Monitoraggio Ambientale e Controllo Rack sezione INFN
Pagina 37 di 190
Figura 3.4 – Mappa degli Apparati 1 di 3 sezione Data Center S.Co.P.E.
Pagina 38 di 190
Pagina 39 di 190
Pagina 40 di 190
Figura 3.7 - Monitoraggio Ambientale e Controllo Rack sezione Data Center S.Co.P.E.
Pagina 41 di 190
4
Analisi degli Strumenti Software Utilizzati
4.1
Cacti
Cacti è la soluzione grafica completa per il monitoraggio di una rete. Progettato per
sfruttare le potenzialità di RRDTool, permette di tenere sotto controllo lo stato degli
apparati o dei sistemi raggiungibili sulla rete. Cacti si occupa di interrogare
ciclicamente (Poller) i dispositivi della rete, e richiedere, tramite opportuni script o
richieste esplicite, le informazioni necessarie per la creazione dei grafici o di statistiche
[7].
Le operazioni di Cacti possono essere divise in tre diversi compiti :
Figura 4.1 – Cacti Operation
Data Retrieval
Il recupero dei dati avviene interrogando ciclicamente i dispositivi della rete.
In particolare, per recuperare dati da sistemi distanti, come ad esempio server, o
apparati di rete, Cacti utilizza il Simple Network Management Protocol o protocollo
SNMP.
Data Storage
La memorizzazione dei Dati avviene utilizzando RRDTool.
Pagina 42 di 190
RRDTool è un programma che permette di memorizzare misurazioni effettuate nel
tempo e ricavarne diagrammi come il traffico della rete. Si basa sul concetto di Round
Robin, una tecnica che utilizza un numero finito di elementi e un puntatore
all'elemento corrente, in cui i nuovi elementi vengono aggiunti sovrascrivendo i dati
più vecchi. In pratica il database è circolare, una volta raggiunta la fine il puntatore si
sposta di nuovo sul primo elemento e inizia a sovrascrivere i dati. I vantaggi di questa
tecnica risiedono proprio nel fatto che, essendo noto e predeterminato il numero di
elementi che compongono il database, le sue dimensioni sono statiche. In questo modo
si il database non ha bisogno di manutenzione.
Un altra caratteristica di RRDTool è che i valori vengono memorizzati a intervalli di
tempo predeterminati. Nel caso di Cacti il Poller Interval può avvenire ogni 10, 15, 20,
30 secondi, ogni minuto o ogni 5 minuti, assicurando un campionamento di dati non
obsoleti.
Un RRD (Round Robin Database) po' contenere qualsiasi tipo di dato numerico, non
necessariamente intero, con l'unico limite dato dall'applicabilità della sua struttura
circolare. Il timestamp, ovvero la marcatura temporale del momento della rilevazione
del dato, è sempre espresso in numero di secondi trascorsi dal 01/01/1970 (timeepoch) ovvero dalla data convenzionale di creazione di Unix.
Utilizzato per monitorare qualsiasi tipo di dato, RRDTool viene soprattutto utilizzato
in congiunzione con il protocollo SNMP.
Data Presentation
Una della caratteristiche più apprezzate di Cacti è la Presentazione dei Dati.
Una volta che uno o più dispositivi (server, stampanti ed altri apparati di rete) sono
stati aggiunti, il software memorizza soltanto i dati necessari per creare i grafici o
statistiche.
Per esempio, Cacti potrebbe registrare un campione ogni minuto per un giorno, uno
ogni ora per una settimana, uno ogni due ore per un mese, uno ogni settimana per un
anno. Questo schema di consolidamento consente di mantenere importanti
Pagina 43 di 190
informazioni di carattere storico senza dover memorizzare dettagli inutili o sprecare
tempo nell'amministrazione del database.
I grafici possono essere a barre o composti da linee, possono rappresentare i dati
tramite diverse scale o presentare legende e possono essere visualizzati in molti modi
ad esempio: vista ad elenco, vista ad albero, modalità anteprima etc.
Cacti viene definito un sistema web-based grapher [7], mostriamo di seguito il suo
principio di funzionamento:
Figura 4.2 – Cacti Infrastructure
Un'altra caratteristica importante di Cacti è la gestione degli utenti. Infatti con esso è
possibile aggiungere o eliminare utenti, e definire permessi di visualizzazione o
modifica per ognuno di essi.
Un aspetto importante di questo applicativo è l'estensibilità attraverso l'installazione di
Plugin, che permettono l'aggiunta di nuove funzionalità, non previste dal software di
base. Ad esempio il plugin weathermap, che permette di realizzare delle mappe per
monitorare il traffico della rete e lo stato dei dispositivi.
Inoltre Cacti è uno strumento con un interfaccia grafica user friendly, quindi
facilmente gestibile e configurabile anche da utenti poco esperti.
Pagina 44 di 190
4.1.1 Raccolta dei Dati
La maggior parte dei sistemi software per il monitoraggio dei dispositivi in rete,
utilizza il protocollo SNMP (Simple Network Management Protocol). Questo
protocollo ha lo scopo di fornire agli amministratori informazioni e allarmi sui
dispositivi presenti in rete, senza l'ausilio di meccanismi esterni di cattura o sonde
software da installare.
Il grado e il numero di informazioni ottenibili dipende dal dispositivo stesso, ad
esempio una stampante fornirà informazioni differenti da quelle generate da uno
switch o da un server.
Prima di poter eseguire il monitoraggio devono verificarsi alcune condizioni: i
dispositivi, chiamati Managed Devices, devono essere dotati di un Agent SNMP ed
avere la capacità di comunicare le informazioni nella rete locale.
Solo i dispositivi di fascia medio-alta dispongono di un implementazione SNMP, gli
apparati economici di solito, sono privi di questa funzionalità.
I dispositivi dotati di agenti SNMP sono in grado di comunicare informazioni interne
di funzionamento, ma hanno bisogno di un sistema centrale, una Network
Management Station, che raccolga questi dati e che li visualizzi in un formato leggibile
dall'amministratore di rete [12]. Senza la Network Management Station l'utilità del
protocollo SNMP è del tutto vana.
Questa situazione è in realtà più comune di quanto si pensi. Infatti esistono molti
ambienti di lavoro che pur disponendo di periferiche SNMP, non hanno un sistema
centrale in grado di raccogliere i dati SNMP. Ignorando informazioni che costituiscono
un gran valore nella gestione della rete e nella diagnosi di situazioni di errore.
SNMP è un protocollo client-server, in cui gli agenti presenti sulle periferiche operano
come server mentre il sistema centrale di raccolta, la Network Management Station
agisce da client [12]. Gli agenti sulle periferiche vengono attivati all'accensione della
periferica e restano in attesa di richieste da parte sistema centrale. E' compito
dell'amministratore decidere quali dettagli delle periferiche controllare configurando il
Pagina 45 di 190
software centrale di monitoraggio [12]. Questo non farà altro che interrogare a cadenza
di tempo regolare gli agenti per leggere le informazioni richieste dall'amministratore.
Esiste anche una comunicazione SNMP che opera nel senso opposto: SNMP Trap, in
cui sono le periferiche a mandare automaticamente degli allarmi se si verificano
situazioni particolari. In questo caso è il dispositivo che inizia una comunicazione con
il software di monitoraggio la NMS.
La lista delle informazioni, o meglio variabili, che una periferica può fornire, è
organizzata all'interno di una struttura dati standardizzata chiamata MIB (Management
Information Base) che è condivisa tra gli agenti e il software di controllo. In questo
modo i software di controllo possono così funzionare subito dopo essere stati installati
senza la necessità che l'amministratore fornisca i dettagli precisi sulle periferiche.
Basterà inserire l'indirizzo IP del dispositivo, una stringa di accesso e la variabile che
si vuole monitorare.
La Management Information Base (MIB), è una base di dati contenente tutte le
informazioni gestite dall'Agent SNMP che è in funzione sulla device monitorata. Gli
oggetti all'interno di una MIB vengono definiti in base alle strutture SMI. La Structure
Management Information definisce in modo standard come devono essere strutturate le
informazioni e la loro gerarchia per essere inserite nel database MIB.
All'interno di ogni MIB gli oggetti sono suddivisi in categorie, in particolare :
•
System: contiene informazioni di carattere generale sul device di rete;
•
Interfaces: contiene le informazioni relative alle interfacce di rete;
•
Address Translation: contiene informazioni relative alla conversioni degli
indirizzi (Es. da logico a fisico), esiste per compatibilà con MIB-I;
•
Ip: contiene informazioni relative al protocollo IP;
•
Icmp: contiene informazioni relative al protocollo ICMP;
•
Tcp: contiene informazioni relative al protocollo TCP. Gli oggetti di questo
gruppo esistono solo per la durate della sessione TCP;
•
Udp: contiene informazioni relative al protocollo UDP;
Pagina 46 di 190
•
Egp: contiene informazioni relative al protocollo EGP (protocollo utilizzato da
un router per scambiare informazioni tra Autonomous System);
•
Transmission: sperimentale, contiene informazione sui mezzi trasmissione
utilizzato da ogni interfaccia di rete ;
•
Snmp: contiene informazioni relative al protocollo SNMP.
Figura 4.3 - Architettura dell'SNMP
4.1.2 Il Plugin Weathermap
Il Plugin Weathermap è una delle tante implementazioni della stessa idea di base:
prendere i dati dai dispositivi di rete e utilizzarli per fornire una descrizione dello stato
attuale della rete.
Questo Plugin non si occupa di raccogliere i dati, ma integra strumenti come MRTG,
Cricket o Cacti, che acquisiscono i dati in un database per poi realizzare grafici in
Pagina 47 di 190
dettaglio e statistiche [8].
Il Plugin Weathermap da la possibilità all'utente di realizzare delle mappe, utilizzando i
dati acquisiti da Cacti, MRTG o Cricket. Le mappe realizzate con weathermap possono
descrivere lo stato attuale dei dispositivi di una rete (ad esempio host), o anche
rappresentare il traffico di una rete in tempo reale.
La versione attuale v0.97a è scritta in PHP e può leggere sia i dati delle statistiche
prodotte da MRTG, ovvero file HTML, che file RRD prodotti da Cacti.
Weathermap permette di generare file HTML per le immagini delle mappe, che
possono includere anche link ad altri sistemi di monitoraggio e/o a grafici di statistiche
[8].
Dotato di un map editor, Weathermap, permette di creare e modificare facilmente
mappe senza ricorrere direttamente ai file di configurazione.
Al contrario se si vogliono realizzare particolari mappe, bisogna ricorrere ai file di
configurazione. Infatti vengono sfruttate al massimo le potenzialità del plugin
Weathermap, con la stesura di script ad hoc, scritti da utenti esperti.
Weathermap richiede alcuni altri prodotti public domain:
•
mysql e mysql-server: per la gestione dei dati
•
php: per la programmazione delle pagine web
•
php-gd: per la gestione dei file PNG in PHP, e per le fonti TrueColour e
FreeType
•
httpd: web server
•
rrdtool: per leggere i file RRD
•
cacti: per la raccolta dei dati e la produzione dei grafici
•
cacti plugin architecture: per installare Weathermap come plugin di cacti
Weathermap si può utilizzare in vari modi:
Pagina 48 di 190
•
come un Plugin di Cacti, con un editor web-based
•
come un Plugin di Cacti, con un editor basato su interfaccia di riga di comando
•
Come un tool standalone da riga di comando, con un editor web-based
•
Come un tool standalone da riga di comando, con un editor basato su interfaccia
di riga di comando
Per rendere l'idea di cosa sia possibile realizzare con Weathermap, riportiamo una
mappa che abbiamo realizzato:
Figura 4.4 – Mappa realizzata con Weathermap
4.2
Ulteriori Sistemi Software di Monitoraggio
Multi Router Traffic Grapher
Il Multi Router Traffic Grapher (MRTG) è un applicativo utilizzato per monitorare
l'andamento del traffico di un dispositivo di rete, tipicamente un router. MRTG genera,
a partire da informazioni rilevate attraverso il protocollo SNMP, pagine HTML
contenenti immagini ii formato PNG, che rappresentano un grafico riepilogativo
sull'andamento del traffico.
Originariamente MRTG è stato sviluppato pensando ai router, successivamente poi è
stato utilizzato per monitorare qualsiasi dispositivo di rete sul quale sia abilitato
l'SNMP.
Pagina 49 di 190
MRTG viene fornito in codice sorgente, ciò significa che prima di poterlo utilizzare è
necessario completare e compilare parti di esso. Precisamente consiste in uno script
scritto in Perl, che legge il valore di una variabile SNMP, ed in un veloce programma
scritto in C, che registra i dati e crea grafici. Questi grafici sono incorporati in pagine
Web che possono essere lette da un qualsiasi browser web.
MRTG è un applicativo Open Source e offre molte funzionalità interessanti: mantenere
un database di dimensione fissa che non richiede manutenzione e conservare solo i dati
sufficienti a creare i grafici necessari.
Le caratteristiche principali di MRTG possono essere riassunte nei seguenti punti
•
Portabilità: disponibile sia per Linux che per Windows,
•
Perl: scritto in codice liberamente accessibile ed eventualmente modificabile,
•
Performance : le parti ritenute critiche del programma sono state scritte nel
linguaggio C,
•
Personalizzazione: le pagine html prodotte da MRTG sono personalizzabili,
•
Configurazione facilitata dall'utilizzo di alcuni tools forniti insieme al
programma.
Cricket
Cricket è definito come un web-based grapher capace di generare dei grafici per
visualizzare dei dati.
Cricket si basa su RRDTool (round robin data tool). Come abbiamo descritto
precedentemente, è un applicativo che acquisisce e colleziona dati con dei database di
tipo Round Robin, in cui ogni data-file ha una prefissata e predeterminata grandezza.
Il campionamento dei dati di RRDTool è medio, quindi non si creano mai dati
fortemente obsoleti.
Ogni tabella di RRDTool ciclicamente raccoglie i dati registrandoli secondo questa
tabella oraria : ogni cinque minuti per tutto l'intervallo delle ultime 24 ore, in modo
Pagina 50 di 190
giornaliero raccogliendo i dati per l'ultima settimana. E' ovvio che quando si
estrapolano i dati attraverso il grafico, con questo tipo di implementazione, non sarà
possibile estrapolare dati che superino ad esempio le due settimane di tempo.
Con cricket si possono monitorare router, il traffico di banda di uno switch, si puo'
avere il traffico di banda di ogni singolo host etc.
Cricket usa il SNMP (Simple Network Management Protocol) che può registrare dati
da qualsiasi periferica in rete.
Inoltre con cricket è possibile realizzare script per collezionare dati su qualsiasi cosa
che utilizzi questo tipo di protocollo.
Cricket è un applicativo scritto interamente in perl ed è Open Source.
4.3
Scelta e Motivazioni del Tool Utilizzato
I dati relativi alle reti si apprezzano meglio in un contesto visuale e cronologico. E'
importante disporre di uno strumento per registrare e rappresentare graficamente
informazioni come il traffico, il carico sulla CPU, o il numero di errori di
comunicazione. Tutto ciò ricade sulla scelta del software di monitoraggio da utilizzare.
Il “mondo” software offre svariati tool per il monitoraggio delle reti, ma da un'attenta
analisi dei software disponibili, ho preferito scegliere Cacti come strumento software
per il monitoraggio della rete, per i seguenti motivi:
Cacti offre principalmente funzionalità basilari, che possono essere espanse con
l'installazione di Plugin. Attraverso questi, è possibile aggiungere strumenti specifici,
come ad esempio il plugin Weathermap, che permette di realizzare delle mappe per
monitorare il traffico della rete e lo stato dei dispositivi.
Nonostante l'utilizzo di un Plugin aggiuntivo come Weathermap, il massimo della
configurazione e delle potenzialità, per il controllo e la gestione della rete, si ha con la
stesura di script ad hoc, realizzati da utenti esperti.
Cacti, rispetto a MRTG e Cricket, è uno strumento con un interfaccia grafica user
friendly, quindi facilmente gestibile e configurabile anche da utenti poco esperti.
Pagina 51 di 190
Una altra caratteristica saliente di questo strumento, è che associandolo ad un server
web, come ad esempio Apache, è possibile accedere a Cacti da un browser web di una
qualsiasi piattaforma. In modo da poter accedere a tutte le funzionalità di Cacti da
remoto.
Cacti è un'applicazione Open Source, scritta in PHP, che quindi benefica di tutti i
vantaggi di un software Open Source.
4.4
Realizzazione di una Guida per l'Installazione di Cacti e del Plugin
Weathermap
Installare Cacti non è stato semplice, visto che esistono molte guide generali, ma
nessuna di esse, descrive passo passo il processo d'installazione.
Per la corretta installazione e configurazione dei servizi utilizzati da cacti e/o dal
Plugin Weathermap, ho deciso di realizzare una guida dettagliata nei minimi
particolari.
Realizzando tale guida, ho versato il mio contributo alla “Comunità Open Source”,
infatti la seguente guida è disponibile nella sezione forum, del sito ufficiale di cacti.
In seguito allo sviluppo delle nuove versioni di Cacti e del Plugin Weathermap, al fine
di avere una versione sempre più aggiornata e affidabile per il nostro sistema, sono
state effettuate diverse installazioni. Durante la fase di installazione, ci siamo trovati
ad affrontare diversi problemi per il corretto funzionamento di cacti e del Plugin
Weathermap.
In seguito alle diverse prove d'installazione effettuate, siamo giunti alla conclusione
che per non incombere ad ulteriori problemi, a seconda della versione di cacti che si
utilizza, bisogna associare una determinata versione dell'architettura, e del Plugin di
Weathermap, vedi tabella 4.1:
Pagina 52 di 190
Cacti
Architettura
Plugin Weathermap
Versione 0.8.7e
Versione 2.6a
Versione 0.96a
Versione 0.8.7f
Versione 2.7a
Versione 0.97a
Versione 0.8.7g
Già presente nella v 0.8.7g
Versione 0.97a
Tabella 4.1 – Versione Cacti, Architettura e Plugin
Di seguito dettagliamo tutti i passi per installare Cacti e il Plugin Weathermap su un
sistema operativo Scientific Linux 32 bit:
Passo 1:
Verificare che i repository siano abilitati : andare nella directory /etc/yum.repos.d
cd /etc/yum.repos.d
gedit ......repo (mettere enabled=1)
Passo 2:
Installare i pacchetti con il seguente comando yum:
yum install mysql-server
yum install cacti
yum install php-gd
yum install cacti-spine
yum list
Passo 3:
Verificare i seguenti file di configurazione:
gedit /etc/php.ini
extension_dir = /usr/lib/php/modules (verificare la presenza di questo rigo, se
all'architettura della macchina è 64bit, si avrà questo rigo: extension_dir =
/usr/lib64/php/modules)
gedit /etc/php.d/mysql.ini
; Enable mysql extension module
Pagina 53 di 190
extension=mysql.so (verificare che ci sia questo rigo)
gedit /etc/php.d/snmp.ini
; Enable snmp extension module
extension=snmp.so (verificare che ci sia questo rigo)
session.save_path=/tmp (eliminare questo rigo, se presente)
gedit /etc/httpd/conf/httpd.conf
# Load config files from the config directory "/etc/httpd/conf.d".
Include conf.d/*.conf (verificare che ci sia questo rigo)
gedit /etc/httpd/conf.d/php.conf
# PHP is an HTML-embedded scripting language which attempts to make it
# easy for developers to write dynamically generated webpages.
LoadModule php5_module modules/libphp5.so (verificare che ci sia questo rigo)
# Cause the PHP interpreter to handle files with a .php extension.
AddHandler php5-script .php (verificare che ci sia questo rigo)
AddType text/html .php (verificare che ci sia questo rigo)
# Add index.php to the list of files that will be served as directory
# indexes.
DirectoryIndex index.php (verificare che ci sia questo rigo)
Passo 4:
Avviare da riga di comando il servizio MySQL e dare una password:
/sbin/service mysqld start
mysqladmin --user=root password cacti123 (in questo caso attribuiamo per la prima
volta la password all'utente root)
con il comando seguente creiamo un database nominato cacti per l'utente root:
mysqladmin --user=root create cacti -p (vista l'opzione -p, viene chiesto di inserire la
Pagina 54 di 190
password dell'utente root “cacti123”)
/sbin/service mysqld restart
Passo 5:
Aggiungere un nuovo account al sistema con le seguenti credenziali : user “cactiuser”,
password “cacti1”, la password deve essere di sei caratteri, altrimenti non viene
accettata dal sistema. Da precisare che questa password non necessariamente deve
essere uguale a quella del database creato cacti.
adduser -p cacti1 cactiuser
Passo 6:
Ci disponiamo nella cartella di cacti,
cd /var/www/cacti
lanciando il seguente comando copiamo nel database cacti i dati di partenza da
cacti.sql
mysql cacti < cacti.sql -p; (chiede la password “cacti123”)
accediamo a mysql come utente root,
mysql --user=root mysql -p (chiede la password “cacti123”; i due – vanno vicini)
e con il seguente comando aggiorniamo tutti i privilegi dell'utente cactiuser per il
database cacti:
mysql> GRANT ALL ON cacti.* TO 'cactiuser'@'localhost' IDENTIFIED BY
‘cacti123’;
mysql> flush privileges;
mysql> exit;
Passo 7:
Verificare il seguente file di configurazione:
gedit /var/www/cacti/include/config.php
$database_type = "mysql"; (verificare che ci sia questo rigo)
Pagina 55 di 190
$database_default = "cacti";(verificare che ci sia questo rigo)
$database_hostname = "localhost"; (verificare che ci sia questo rigo)
$database_username = "cactiuser"; (verificare che ci sia questo rigo)
$database_password = "cacti123"; (verificare che ci sia questo rigo)
diamo i seguenti permessi:
chown -R cactiuser rra/ log/
chmod 777 rra/ log/
gedit /etc/crontab (verificare che ci sia questo rigo che segue, se no inserirlo)
*/5 * * * * cactiuser php /var/www/cacti/poller.php > /dev/null 2>&1
Questo rigo serve a specificare ogni quanto effettuare l'interrogazione, infatti si trova
nella cartella crontab del sistema.
Passo 8:
Se si installa anche spine, verificare il seguente file di configurazione:
gedit /etc/Spine.conf
DB_Host 127.0.0.1
DB_Database cacti
DB_User cactiuser
DB_Password cacti123
DB_Port 3306
Passo 9:
In base alla versione di Cacti utilizzata, è possibile che ci siano delle patches da
installare. Le patches servono a risolvere eventuali bug legati alla versione di cacti
utilizzata, e possono essere scaricate dal sito di cacti.
Riportiamo un esempio di patches per la versione f di cacti:
wget http://www.cacti.net/downloads/patches/0.8.7f/cli_add_graph.patch
wget http://www.cacti.net/downloads/patches/0.8.7f/snmp_invalid_response.patch
Pagina 56 di 190
wget http://www.cacti.net/downloads/patches/0.8.7f/template_duplication.patch
wget
http://www.cacti.net/downloads/patches/0.8.7f/fix_icmp_on_windows_iis_servers.path
esecuzione delle patch:
patch -p1 -N < cli_add_graph.patch
patch -p1 -N < snmp_invalid_response.patch
patch -p1 -N < template_duplication.patch
patch -p1 -N < fix_icmp_on_windows_iis_servers.patch
Passo 10:
Fare una ricerca aggiornamenti, per eventuali allineamenti di versione e delle
dipendenze:
yum clean all
yum update
Passo 11:
Disabilitare completamente SELINUX (si trova in “Menu->Amministrazione ->livello
di sicurezza e firewall”) e riavviare tutti i servizi e poi la macchina.
Passo 12:
Dopo il riavvio del sistema, avviare Cacti eseguendo i comandi:
/sbin/service mysqld start
/sbin/service httpd start
Passo 13:
Nel caso in cui si utilizza una versione di cacti che richiede l'installazione
dell'architettura, scaricare il plugin architecture dal seguente indirizzo web:
http://cactiusers.org/downloads/patches/architecture
Pagina 57 di 190
Predisporsi in cacti:
cd /var/www/cacti
Estrarre il contenuto del file nella cartella di cacti (attenzione a non copiare la cartella
dell'architettura in cacti), attraverso il seguente comando:
tar -zvxf cacti-plugin-arch.tar.gz
A questi punto verranno sovrascritti dei file.
Passo 14:
Nel caso in cui si utilizza una versione di cacti che richiede l'installazione
dell'architettura, fare queste operazioni:
eseguire mysql:
mysql –p (chiede la password “cacti123”)
selezionare cacti come database:
mysql> use cacti;
eseguire il file pa.sql in mysql:
mysql> source pa.sql;
mysql> exit
predisporsi in cacti:
cd /var/www/cacti
eseguire il seguente comando:
patch -p1 -N < cacti-plugin-0.8.7f-PA-v2.7.diff
Passo 15:
Editare il file global.php e modificare le seguenti righe:
gedit /var/www/cacti/include/global.php
$database_type = "mysql";
(verificare che ci sia questo rigo)
$database_default = "cacti";
$database_hostname = "localhost";
$database_username = "cactiuser";
Pagina 58 di 190
$database_password = "cacti123";
$config['url_path'] = " /cacti/”;
define(‘URL_PATH’,$config[‘url_path’]);
...
include_once($config[“library_path”] . “/plugins.php”);
include_once($config[“include_path”] . “/plugins.php”);
…
Passo 16:
Aggiunta del Plugin Weathermap:
Creare la cartella plugins all'interno della cartella cacti, se non esiste:
mkdir /var/www/cacti/plugins
assegnare i seguenti permessi:
chmod 775 /var/www/cacti/plugins
predisporsi all'interno della partella plugins:
cd /var/www/cacti/plugins
Scaricare il plugin weathermap dal seguente indirizzo web:
wget http://www.network-weathermap.com/files/php-weathermap-0.97a.zip
Estrarre il file scaricato nella cartella plugins:
tar -zvcf php-weathermap-0.96a.zip
Verrà creata la cartella weathermap
/var/www/cacti/plugins/weathermap
assegnare i seguenti permessi:
chmod –R 777 weathermap
chown –R cactuser weathermap
Passo 17:
E' possibile aggiungere dei plugin opzionali, oltre a Weathermap, come il plugin
monitor:
Pagina 59 di 190
scaricare il file dal seguente indirizzo web:
http://cactiusers.org/downloads/monitor.tar.gz
predisporsi all'interno della cartella plugins
cd /var/www/cacti/plugins
Estrarre il file all'interno della cartella plugins
tar -zvcf monitor-0.3.tar.gz
assegare i seguenti permessi alla cartella monitor creata:
chown cactiuser monitor
chmod 777 monitor
Passo 18:
Editare il file global.php e config.php, per modificare o inserire alcune righe:
cd /var/www/cacti/include
gedit global.php
$plugins = array();
$plugins[] = ‘monitor’;
$plugins[] = ‘weathermap’;
gedit config.php
$plugins = array();
$plugins[] = ‘monitor’;
$plugins[] = ‘weathermap’;
E' da sottolineare che questi file sono i principali file di configurazione di cacti e del
plugin weathermap. Infatti, viste le tante modifiche, nel capitolo successivo (paragrafo
Configurazione dei servizi utilizzati) verranno riportati interamente.
Passo 19:
Riavviare i servizi mysqld e httpd
Pagina 60 di 190
/sbin/service mysqld restart
/sbin/service httpd restart
A questo punto l'installazione di cacti e del Plugin Weathermap è terminata.
Passo 20:
Per accedere a cacti tramite browser web, utilizzare il seguente indirizzo:
http://localhost/cacti/
A questo punto troveremo di fronte a noi una schermata di login.
La prima volta che si accede a cacti bisogna utilizzare le seguenti credenziali:
User name: admin
Password: admin
successivamente al login ci viene suggerito di cambiare subito la password.
Con quest'ultimo passo, terminiamo la guida che abbiamo realizzato.
Per avviare e stoppare velocemente entrambi i servizi che permettono l'esecuzione e la
non esecuzione di cacti sul nostro sistema, ho ritenuto opportuno realizzare degli script
di shell chiamati startcacti.sh e stopcacti.sh, presenti nella cartella home.
4.5
Test Preliminari
Scelto Cacti come strumento base di monitoraggio, prima di dedicarmi alla stesura
degli script, per la realizzazione delle mappe della rete del Tier2, ho ritenuto opportuno
effettuare dei test su delle apparecchiature di rete.
Le apparecchiature presenti nella Control Room di SCoPE, sono state messe a mia
disposizione per effettuare dei test.
Lo scopo di tali prove è stato quello di:
1. riconosce eventuali malfunzionamenti del software ed eventualmente risolverli,
2. capire il dominio applicativo,
Pagina 61 di 190
3. configurare il software con tutti i servizi,
4. prendere dimestichezza con le apparecchiature di rete.
Disponendo di una macchina, ovvero di un computer messo a disposizione per il
periodo di Tirocinio, è stato possibile installare i seguenti strumenti software :
1. Scientific Linux,
2. Cacti,
3. Plugin Weathermap.
4. mysql e mysql-server per la gestione dei dati,
5. php,
6. php-gd per la gestione dei file PNG in PHP, e per le fonti TrueColour e
FreeType,
7. httpd in particolare Apache come web server,
8. rrdtool per leggere i file RRD.
Le apparecchiature interessate nelle prove sono:
1. Switch Linksys 2024,
2. Switch Linksys 2048,
3. Nas (Network Attached Storage) Synology DS 508,
4. Nas (Network Attached Storage) Synology DS 508.
Di seguito vengono riportate le principali caratteristiche del Linksys SRW 2024 [11]:
1. N° porte: 24 x Ethernet 10Base-T, Ethernet 100Base-TX, Ethernet 1000Base-T
2. Velocità di trasferimento: 1 Gbps
3. Data Link Protocol: Ethernet, Fast Ethernet, Gigabit Ethernet
4. Tecnologia di connessione: Cablato
5. Modalità di comunicazione: Half-duplex, full-duplex
6. Protocollo di commutazione: Ethernet
7. Dimensione della tabella degli indirizzi MAC: 32.000 voci
Pagina 62 di 190
8. Indicatori di stato: Stato porta, attività collegamento, sistema, Attività
collegamento, velocità trasmissione porta, sistema,Standard di conformità:
IEEE 802.3, IEEE 802.3u, IEEE 802.3ab, IEEE 802.3x
9. Protocollo di gestione remota: HTTP
Principali caratteristiche del Linksys SRW 2048 [11]:
1. Numero porte lan : 48
2. Velocità lan : 10/100/1000 Mbps
3. Conformità lan : IEEE 802.3, IEEE 802.3u, IEEE 802.3ab
4. Dimensioni tabella mac : 8.000
5. Supporto ip : ipv4/ipv6.
Riportiamo anche alcune caratteristiche salienti del gruppo NAS Synology DS 508:
Hardware:
CPU Clock: 800 MHz
RAM: 512MB
HDD Interno: 3.5” SATA(II) 5X HDD
Interfaccia esterna: 2X porte USB 2.0, 1x porta eSATA
Capacità massima (HDD Interni): 5 TB controllare compatibilità HDD
Numero massimo IPCam: 10
Condivisione file :
Numero massimo utenti: 2048
Numero massimo gruppi: 256
Numero massimo cartelle condivise: 200
Numero massimo connessioni simultanee: 128
Gestione RAID:
Tipo di Volume: Disco singolo, RAID 0, RAID 1, Raid 5
Pagina 63 di 190
Aggiornamento da disco singolo a RAID 1
Espansione RAID 1 o RAID 5 con Grossi hard-disk
Expansione RAID 5 Aggiungendo Hard Drive Al Volo
Auto ricostruzione del Volume dopo una mancanza di energia elettrica
Aggiornabile in RAID 5 aggiungendo un hard-disk a caldo.
Nonostante le difficoltà riscontrate per l'installazione e configurazione degli strumenti
software utilizzati, è stato possibile effettuare i primi test sull'apparecchiature in
questione. In questo modo abbiamo potuto valutare il funzionamento del software
scelto, simulando limitatamente situazioni reali di monitoraggio.
Per effettuare le prove è stato necessario conoscere gli indirizzi IP degli apparati da
monitorare e abilitare il loro protocollo SNMP, per poterli successivamente inserire ed
interrogare con Cacti.
Inizialmente l'interrogazione tramite protocollo SNMP è stata effettuata da riga di
comando tramite la shell con il seguente comando: snmpwalk -v 2 -c public
IP_address. Questo comando lancia un interrogazione al dispositivo specificando la
versione di SNMP da utilizzare (-v), la community (-c) e l'indirizzo IP del dispositivo.
Questo tipo di interrogazione tramite riga di comando è stata effettuata per verificare
se i dispositivi erano abilitati a ricevere tale richiesta, prima di aggiungerli in Cacti.
Abbiamo effettuato i seguenti Test:
1. Test
In questo test abbiamo monitorato il traffico di rete durante la copia di un file di grosse
dimensioni da un computer ai Synology DS508, e viceversa dai Synology DS508 al
computer.
Con questo tipo di test abbiamo voluto simulare una situazione reale di trasferimento
dati tra dispositivi, all'interno di una rete di piccole dimensioni.
Nel nostro caso la rete di piccole dimensioni è costituita da un computer collegato allo
switch Linksys 2024 alla porta 23, a dai Synology collegati in Link Aggregation al
Pagina 64 di 190
Linksys 2024 sulla porta ch1.
Nel primo caso analizziamo la seconda parte dei grafici, vedi figura 4.5 e figura 4.6 le
aree delineate in rosso, che riguardano il trasferimento di un immagine di un disco di
circa 4 GB, dal computer ai Synology DS508.
Figura 4.5 – Traffico Linksys 2024
Con il grafico mostrato in figura 4.5, monitoriamo precisamente il traffico entrante e
uscente dalla porta 23 dello switch Linksys 2024, dove è collegato il computer.
Come si può vedere c'è una quantità di dati rilevante solo in entrata, ovvero Inbound
corrente 1.44 Mbps; mentre in uscita c'è una minima quantità di dati, Outbound
corrente 62.04 kpbs.
Allo stesso istante in cui avviene il trasferimento, monitorando la porta ch1 dove sono
collegati i Synology DS508, figura 4.6, si nota una quantità di traffico rilevante solo in
uscita, Outbound corrente 1.52 Mbps e una quantità di dati irrilevanti in entrata
Inbound pari a 65.01 kbps. Questo è ovvio, visto che monitoriamo le porte di due
dispositivi tra cui avviene un trasferimento di dati, dove quindi l'Inbound di una porta
sarà circa uguale all'Outboud dell'altra e viceversa.
Pagina 65 di 190
Nel secondo caso analizziamo la prima parte dei grafici, ovvero le aree che sono
delineate in nero di entrambe le figure 4.5 e figura 4.6, e che riguardano il
trasferimento di un immagine di un disco di circa 4 GB, dai Synology al computer.
In questo caso non è stato possibile riportare precisamente i valori espressi in Mbps o
kbps dell'Inboud e dell'Outbound, visto che gli screen shoot dei grafici sono aggiornati
ai valori correnti del caso precedente; ma nonostante ciò, attraverso i grafici è possibile
analizzare il trasferimento dei dati tra i dispositivi.
Dalla prima parte del grafico figura 4.6, è possibile notare una quantità di traffico
entrante, Inbound, notevole sulla porta ch1 del Linksys dove sono collegati i Synology.
Mentre facendo riferimento al grafico figura 4.5, è possibile notare una quantità di dati
trasferiti in uscita notevole sulla porta 23 del Linksys dove è collegato il computer.
Un particolare importante da definire in questa simulazione è che il tool di
monitoraggio Cacti operava in locale. Ovvero Cacti si trovava sullo stesso computer
che è stato utilizzato per inviare il file di immagine sui Synology e viceversa dai
Synology al computer.
Pagina 66 di 190
2. Test
In questo test abbiamo monitorato il traffico di dati tra due dispositivi di una rete LAN,
dall'estero di questa rete. Vale a dire che durante la copia di un file di grosse
dimensioni, da un computer presente nella Control Room ai Synology DS508, e
viceversa dai Synology DS508 al computer, Cacti operava da un computer esterno alla
LAN della Control Room.
Con questo tipo di test abbiamo voluto simulare una situazione reale di monitoraggio
di una rete raggiungibile dall'esterno dal sistema di monitoraggio utilizzato.
Questo test è stato possibile effettuarlo perché i Synology DS508 e il computer della
Control Room sono raggiungibili dall'esterno, attraverso un indirizzo IP pubblico e
ovviamente con i rispettivi nome utente e password.
Lavorando da remoto per effettuare questa prova, abbiamo utilizzati i seguenti
comandi da shell: ftp -v IP_address, ssh root@IP_address.
Con il comando ssh root@IP_address è stato possibile stabilire una connessione
remota cifrata ad interfaccia a riga di comando con un altro host, nel nostro caso il
computer presente nella Control Room. Stabilita la sessione remota, da questa
abbiamo utilizzato il comando ftp -v IP_address per trasferire il file dal Synology al
computer e viceversa dal computer al Synology, mentre Cacti monitorava questo
trasferimento di dati esternamente alla rete della Control Room.
Vediamo in dettaglio il comando ftp:
Il comando ftp ovvero File Transfer Protocol è un protocollo, cioè un linguaggio
standard di comunicazione tra due terminali, che permette a dei terminali di tipo
diverso di trasferire dei file su una rete che funzioni su TCP/IP. Il protocollo FTP
permette di scambiare un file alla volta, nei due sensi tra terminale client e terminale
server. Questo protocollo permette anche altre azioni come la creazione e
l'eliminazione di cartelle, l'elenco dei file, l'eliminazione e la rinomina di file, etc.
In particolare con questo protocollo, abbiamo utilizzato i seguenti comandi: get
nome_file e put nome_file.
Get permette di recuperare un file presente sul server e trasferirlo sul terminale nella
Pagina 67 di 190
cartella locale in uso.
Put permette di inviare un file locale sul server e trasferirlo nella cartella remota in
uso.
L'opzione (-v) obbliga ftp a mostrare tutte le risposte dal server remoto, oltre a un
rapporto sulle statistiche di trasferimento dati.
Questi sono principalmente i comandi che abbiamo usato per trasferire un file da un
dispositivo all'altro da remoto.
Durante il trasferimento di un file di grosse dimensioni tra i Synology e il computer e
viceversa, abbiamo monitorato l'intero trasferimento con Cacti e abbiamo ottenuto i
seguenti grafici:
Figura 4.7 – Traffico Linksys 2024 gate 23 e channel 1
Pagina 68 di 190
Come si può vedere dai grafici, figura 4.7, le aree delineate in rosso, il trasferimento
ha un comportamento analogo al test precedente, nel caso in cui si trasferisce un file di
grosse dimensioni dal computer ai Synology DS508.
Il test1 ed il test2 sono analoghi: infatti nel secondo test l'Inbound corrente della porta
23 dove è collegato il computer, trasferisce una quantità di dati paria a: 4.23 Mbps,
mentre l'Outbound trasferisce una quantità di dati uguale a: 3.92 Mbps. Entrambe le
quantità sono superiori rispetto al test precedente, ma per l'unica ragione che gli screen
shoot dei grafici sono effettuati in momenti diversi. Infatti anche il file utilizzato nel
trasferimento è lo stesso utilizzato per il test precedente, ovvero un immagine di un
disco di circa 4 GB.
Nel secondo caso analizziamo la prima parte dei grafici, ovvero le aree delineate in
nero, e che riguardano il trasferimento dai Synology al computer.
Anche se non è stato possibile riportare precisamente i valori dell'Inboud e
dell'Outbound, visto che gli screen shoot dei grafici sono aggiornati ai valori analizzati
nel caso precedente, si ha modo di comprendere che in questo test il monitoraggio
avviene senza problemi.
3. Test
Con quest'ultimo test abbiamo monitorato il traffico dello switch Linksys 2048 sulla
porta 3. In particolare abbiamo deciso di monitorare questa porta perché su di essa è
collegata un macchina che offre servizi per la Wi-Fi dell'Ateneo. Questa prova è stata
effettuata all'interno della Control Room, quindi sulla stessa LAN dove è collegato lo
switch Linksys 2048.
Come si può notare dalla figura 4.8, i dati di traffico di ingresso e di uscita non sono
molto elevati: Inbound: 30.62 bps e Outbound: 1.84 kbps. Questo dimostra che al
momento la macchina che offre servizi per la Wi-Fi, non ha richieste.
Pagina 69 di 190
Con quest'ultimo test terminiamo le prove di monitoraggio effettuate con l'applicativo
Cacti.
Pagina 70 di 190
5
Progettazione e Realizzazione di un Sistema per il Monitoraggio
di una Rete
5.1
Presentazione del Sistema Realizzato
Con il sistema di monitoraggio che ho realizzato è possibile rilevare eventuali
malfunzionamenti della rete, come: congestione, errori o perdita di informazioni.
Precisamente, con questo sistema è possibile monitorare in tempo reale oltre che il
traffico della banda passante di tutti i link di interconnessione dei nodi (apparati attivi
della rete), e lo stato degli host della rete, anche gli errori e i pacchetti persi in input ed
in output durante il trasferimento dei dati.
Attraverso l'utilizzo di strumenti software, quali Cacti e il Plugin Weathermap, è stato
possibile realizzare il sistema di monitoraggio della rete del Tier2, raggiungibile al
seguente indirizzo web: http://tier2-cacti.na.infn.it/cacti/. Ma come già anticipato,
questi strumenti software, Cacti e il Plugin Weathermap, mettono a disposizione
principalmente funzionalità di base per il monitoraggio, il massimo della
configurazione e delle potenzialità, per il controllo e la gestione della rete, si ha con la
stesura di script ad hoc, implementati da utenti esperti.
Per questa ragione, per sfruttare al massimo le potenzialità dei programmi utilizzati, e
per realizzare mappe dinamiche, interattive e personalizzate, l'intero sistema dedicato
al monitoraggio della rete del Tier2 di Napoli, è stato implementato con script scritti da
me.
Effettuando l'accesso al sistema, ovviamente con i rispettivi nome utente e password, e
andando nella sezione Weathermap, è possibile accedere al sistema dedicato al
monitoraggio del traffico e dei dispositivi della rete. In questa sezione è possibile
navigare tra tutte le mappe, scorgendo ogni minimo particolare dei dispositivi attivi e
della rete.
Dalle mappe, selezionando un qualsiasi link di collegamento dei nodi, è possibile
accedere ad una serie di grafici sia del traffico, che dei pacchetti persi o danneggiati, in
modo da avere una visione completa della situazione della rete.
Pagina 71 di 190
Inoltre, questi grafici mostrano l'andamento del traffico o dei pacchetti persi o
danneggiati secondo una certa scale temporale: giorno, settimana, mese, anno. Questo
schema di consolidamento consente di mantenere importanti informazioni di carattere
storico.
I grafici possono essere a barre o composti da linee, possono rappresentare i dati
tramite diverse scale o presentare legende e possono essere visualizzati in molti modi
ad esempio: vista ad elenco, vista ad albero, modalità anteprima etc.
Per rendere l'idea di come si effettua il login al sistema di monitoraggio, riportiamo di
seguito la schermata di accesso, figura 5.1:
Figura 5.1 – Cacti Login
Come già anticipato, Cacti generalmente offre l'accesso ad un unico tipo di utente,
l'utente amministratore. Questo utente ha la possibilità di aggiungere, modificare o
eliminare dispositivi, grafici, e mappe.
Pagina 72 di 190
Questo utente ha inoltre la possibilità di aggiungere utenti con i relativi permessi,
come ad esempio, per un utente scegliere determinate mappe o grafici da fargli
visualizzare.
Proprio nel nostro caso sono stati creati diversi utenti di tipo visitatore, che hanno solo
la possibilità di visionare i grafici e navigare tra le mappe in maniera interattiva.
Per realizzare queste mappe, ho effettuato l'accesso al sistema con le credenziali di
amministratore, e ho implementato gli script dei file di configurazione, che generano le
mappe.
5.1.1 Integrazione del Sistema di Monitoraggio nel Portale del Tier2
Il portale del Tier2 è dedicato al monitoraggio centralizzato di tutti i servizi del centro
di calcolo Tier2.
Tra tutti i servizi che vengono monitorati, uno dei più importanti per assicurare
l'affidabilità e la performance del centro di calcolo distribuito, è il servizio dedicato al
monitoraggio della rete.
Questo servizio, che è integrato all'interno del portale, in una sezione dedicata al
controllo e alla gestione della rete, viene implementato attraverso il sistema che ho
realizzato.
Il portale del Tier2 è raggiungibile all'indirizzo web: http://tier2.na.infn.it, ed è
possibile accedere al servizio di Monitoraggio della rete, in modo diretto e
semplificato, semplicemente cliccando sul link: Network Monitoring. Così facendo, al
sistema di monitoraggio si accede con i privilegi di utente visitatore, che ha solo la
facoltà di navigare tra le mappe e visionare i vari grafici e le statistiche della rete.
Inoltre dalla home del portale, cliccando sul logo di Cacti, il cactus, è possibile
accedere ad una mappa semplificata della rete. Questa mappa è stata realizzata per
dare la possibilità agli utenti di avere subito un quadro generale del flusso di traffico
della rete del Tier2.
Vista la parte dedicata al monitoraggio della rete, ora analizziamo gli altri servizi del
Pagina 73 di 190
portale Tier2.
Il Portale del Tier2 è composto dai seguenti sottosistemi principali:
•
Nagios, usato per il monitoraggio di tutti i servizi
•
Nagvis, per la navigazione interattiva
•
NaReTo, impiegato per il reporting dei dati di monitoraggio collezionati
•
Centeron, utilizzato per la configurazione avanzata dei servizi
•
Weathermap, configurato per la navigazione topologica della rete e per la
consultazione interattiva dei dati di monitoraggio della rete.
•
GridICE, è un tool di monitoraggio per sistemi Grid distribuiti.
•
Ganglia, è un tool di monitoraggio per sistemi ad alte prestazioni come Clusters
e grids.
PowerFarm.
•
5.1.2 Il Portale del Tier2
Il Portale del Tier2 è realizzato con Liferay, un Portlet Container, ovvero
un'applicazione Open Source, basata sul linguaggio Java orientata alla gestione di
portali e al lavoro collaborativo.
Le Portlet sono delle componenti Java web-based, ovvero moduli web riusabili
all'interno di un portale web. Queste, integrate insieme, contribuiscono alla formazione
delle pagine di un portale.
Il successo di Liferay è dovuto alla quantità e qualità dei servizi che esso integra,
infatti con il portale Liferay del Tier2, si ha l'integrazione di diverse funzionalità.
Il portale fornisce all'utente una visione globale, che partendo da macro-componenti
hardware e attraverso una navigazione gerarchica, arriva a tutti i servizi associati al
singolo componente aggregato, finendo con la navigazione della web-management del
device.
Il portale Liferay ha una particolare architettura che permette l'integrazione di sistemi
Pagina 74 di 190
di
monitoraggio
eterogenei
e
l'implementazione
di
nuove
estensioni
per
l'autenticazione unificata, per ogni tipologia di utente, su tutte le applicazioni di
monitoraggio contenute nel portale. Ogni utente che si autenticherà al portale sarà
riconosciuto in base ai propri diritti e avrà accesso in modo trasparente e automatizzato
a tutte le funzionalità previste. Ad esempio, nel caso in cui si dovesse accedere come
amministratore al portale, si accederebbe come amministratore anche a tutti i servizi di
monitoraggio del Tier2.
Questo tipo di architettura implementata nel portale Liferay del Tier2 prende il nome
di Single Sign-On.
5.2
Casi D'Uso
Descrizione del comportamento funzionale del sistema dal punto di vista dell'utente:
Figura 5.2 – Diagramma dei casi d'uso
Pagina 75 di 190
Template di Cockbourn:
Visualizza Grafici
Visualizza i grafici di tutti i dispositivi della rete
monitorati
Scope & Level
//
Preconditions
L'utente visitatore ha effettuato il login al sistema
di monitoraggio
Success End Condition Visualizzazione dei grafici
Failed End Condition //
Primary Actor
Utente Visitatore
Trigger
L'utente clicca sul bottone “graphs”
DESCRIPTION
STEP Utente
Sistema
1
L'utente
visitatore clicca
sul bottone
“graphs”
2
Il sistema visualizza tutti
i grafici inerenti al
monitoraggio dei
dispositivi della rete.
Open Issues
//
Due Date
//
Superordinates
Nessuna
Subordinates
Nessuna
USE CASE #1
Goal in Context
Pagina 76 di 190
Visualizza Mappe
Visualizza le Mappe di tutta la rete monitorata
//
L'utente visitatore ha effettuato il login al sistema
di monitoraggio
Success End Condition Visualizzazione delle Mappe
Failed End Condition //
Primary Actor
Utente Visitatore
Trigger
L'utente clicca sul bottone “weathermap”
DESCRIPTION
STEP Utente
Sistema
1
L'utente
visitatore clicca
sul bottone
“weathermap”
2
Il sistema visualizza le
mappe della rete
monitorata
Open Issues
//
Due Date
//
Superordinates
Nessuna
Subordinates
Nessuna
USE CASE #2
Goal in Context
Scope & Level
Preconditions
Pagina 77 di 190
5.3
Component Diagram
Il diagramma delle componenti rappresenta l'architettura Software del sistema, ovvero
la suddivisione di esso in vari componenti (moduli software), e le dipendenze tra
questi.
Di seguito riportiamo il diagramma delle componenti del sistema realizzato:
Figura 5.3 – Component Diagram
Dal diagramma illustrato in figura 5.3, è possibile individuare da quanti e quali moduli
software la componente composta cacti dipende: Moduli Php, RRDTool, MySQL e
web server cacti per l'accesso da remoto. Cacti viene definita componente composta
Pagina 78 di 190
perché al suo interno esiste un'altra componente, il plugin weathermap. Proprio
attraverso quest'ultima componente è possibile implementare gli script per realizzare il
sistema di monitoraggio della rete del Tier2.
Analizzando la componente composta Cacti, è possibile notare una tipo di dipendenza
particolare: <<use>>, questa indica che il client (componente cacti) necessita del
supplier (componente RRDTool) per la sua implementazione.
Analizzando invece la componente composta Liferay Portal, è possibile notare che le
sue componenti interne: Cacti Portlet e Atlas_net.html dipendono da altre componenti:
la prima dipende necessariamente dalla componente composta cacti, mentre la seconda
dipende dalla componente web server di cacti.
Attraverso questo diagramma delle componenti è possibile capire soprattutto il tipo di
interazione tra il sistema che ho realizzato, che fa riferimento alla componente Plugin
Weathermap, e il Portale Liferay dedicato al monitoraggio di tutti i servizi della rete
del Tier2.
Infatti dalla rappresentazione grafica si evince che la componente cacti non ha nessun
tipo di relazione con la componente Liferay Portal, ma che è la componente interna al
Liferay Portal, cacti portlet, ad avere una dipendenza “necessaria” con la componente
cacti per funzionare.
Questo tipo di interazione ci permette di capire un po' quella che la logica di
funzionamento del portale Liferay con le portlet.
5.4
Configurazione delle Componenti Utilizzate
Visto i moduli software utilizzati e le loro dipendenze, con il Component Diagram, ora
elenchiamo il codice di alcune configurazioni salienti dei servizi utilizzati, per il
sistema realizzato.
Riportiamo solo le parti di codice che abbiamo modificato o aggiunto, visto che
sarebbe oneroso riportare le numerose pagine dei file di configurazione.
Pagina 79 di 190
Per il file php.conf :
# PHP is an HTML-embedded scripting language which attempts to
make it
# easy for developers to write dynamically generated webpages.
<IfModule prefork.c>
LoadModule php5_module modules/libphp5.so
</IfModule>
<IfModule worker.c>
# Use of the "ZTS" build with worker is experimental, and no
shared
# modules are supported.
LoadModule php5_module modules/libphp5-zts.so
</IfModule>
#
Cause
the
PHP
interpreter
to
handle
files
with
a
.php
extension.
AddHandler php5-script .php
AddType text/html .php
# Add index.php to the list of files that will be served as
directory
# indexes.
DirectoryIndex index.php
# Uncomment the following line to allow PHP to pretty-print
.phps
# files as PHP source code:
#AddType application/x-httpd-php-source .phps
Per il file php.ini:
Nella parte di codice seguente abbiamo modificato il limite della memoria da 128M a
Pagina 80 di 190
256M, perché realizzando alcune mappe dinamiche occorreva una quantità di memoria
superiore a quella di default.
; Resource Limits ;
max_execution_time = 30
; Maximum execution time of each
script, in seconds
max_input_time = 60 ; Maximum amount of time each script may
spend parsing request data
memory_limit = 256M
; Maximum amount of memory a script
may consume
Nella seguente parte di codice abbiamo modificato alcuni path.
; Paths and Directories ;
; UNIX: "/path1:/path2"
;include_path = ".:/php/includes"
; Windows: "\path1;\path2"
;include_path = ".;c:\php\includes"
; The root of the PHP pages, used only if nonempty.
; if PHP was not compiled with FORCE_REDIRECT, you SHOULD set
doc_root
; if you are running php as a CGI under any web server (other
than IIS)
; see documentation for security issues.
The alternate is to
use the
; cgi.force_redirect configuration below
doc_root =
;
The
directory
under
which
PHP
opens
the
script
using
/~username used only
; if nonempty.
user_dir =
; Directory in which the loadable extensions (modules) reside.
Pagina 81 di 190
extension_dir = "/usr/lib/php/modules"
;
Whether
or
not
to
enable
the
dl()
function.
The
dl()
function does NOT work
; properly in multithreaded servers, such as IIS or Zeus, and
is automatically
; disabled on them.
enable_dl = On
Per permettere la visualizzazione di alcuni servizi via web, implementati da noi,
abbiamo aggiunto e modificato le seguenti righe nel file httpd.conf:
# This should be changed to whatever you set DocumentRoot to.
<Directory "/var/www">
Options Indexes FollowSymLinks
#
AllowOverride
controls
what
directives
may
be
placed
in
.htaccess files.
# It can be "All", "None", or any combination of the keywords:
#
Options FileInfo AuthConfig Limit
AllowOverride None
# Controls who can get stuff from this server.
Order allow,deny
Allow from all
</Directory>
Seconda parte di codice modificato:
# Allow server status reports generated by mod_status,
# with the URL of http://servername/server-status
<Directory /var/www/cacti>
Options None
Pagina 82 di 190
AllowOverride None
Order allow,deny
Allow from
all
</Directory>
# Allow remote server configuration reports, with the URL of
#
http://servername/server-info (requires that mod_info.c be
loaded).
# Change the ".example.com" to match your domain to enable.
#<Location /server-info>
#
SetHandler server-info
#
Order deny,allow
#
Deny from all
#
Allow from .example.com
#</Location>
# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#<IfModule mod_proxy.c>
#ProxyRequests On
#<Proxy *>
#
Order deny,allow
#
Deny from all
#
Allow from .example.com
#</Proxy>
Per il file snmp.ini:
; Enable snmp extension module
extension=snmp.so
Per il file mysql.ini:
; Enable mysql extension module
Pagina 83 di 190
extension=mysql.so
Per far funzionare Cacti correttamente con i servizi che abbiamo integrato, abbiamo
configurato i seguenti file: global.php, config.php e cacti.conf.
Per il file global.php riportiamo solo le righe di codice che abbiamo modificato o
aggiunto:
/* Default database settings*/
$database_port = "3306";
/*
Default
session
name
-
Session
name
must
contain
alpha
characters */
$cacti_session_name = "Cacti";
/*$plugins = array();
$plugins[]='weathermap': */
/* Include configuration */
include(dirname(__FILE__) . "/config.php");
if (isset($config["cacti_version"])) {
die("Invalid include/config.php file detected.");
exit;
}
/* Files that do not need http header information - Command
line scripts */
Pagina 84 di 190
$no_http_header_files = array(
"cmd.php",
"poller.php",
"poller_commands.php",
"script_server.php",
"query_host_cpu.php",
"query_host_partitions.php",
"sql.php",
"ss_host_cpu.php",
"ss_host_disk.php",
"ss_sql.php",
"add_device.php",
"add_graphs.php",
"add_perms.php",
"add_tree.php",
"copy_user.php",
"host_update_template.php",
"poller_export.php",
"poller_graphs_reapply_names.php",
"poller_output_empty.php",
"poller_reindex_hosts.php",
"rebuild_poller_cache.php",
"repair_database.php",
"structure_rra_paths.php"
);
$config = array();
$colors = array();
/* this should be auto-detected, set it manually if needed */
$config["cacti_server_os"] = (strstr(PHP_OS, "WIN")) ? "win32"
: "unix";
/* built-in snmp support */
Pagina 85 di 190
$config["php_snmp_support"] = function_exists("snmpget");
/* set URL path */
if (! isset($url_path)) {
$url_path = "";
}
$config['url_path'] = '/cacti/';
define('URL_PATH', $url_path);
/* used for includes */
$config["base_path"] = strtr(ereg_replace("(.*)[\\\/]include",
"\\1", dirname(__FILE__)), "\\", "/");
$config["library_path"]
=
ereg_replace("(.*[\\\/])include",
"\\1lib", dirname(__FILE__));
$config["include_path"] = dirname(__FILE__);
$config["rra_path"] = $config["base_path"] . '/rra';
/* include base modules */
include($config["library_path"] . "/adodb/adodb.inc.php");
include($config["library_path"] . "/database.php");
/* connect to the database server */
db_connect_real($database_hostname,
$database_password,
$database_default,
$database_username,
$database_type,
$database_port);
/* include additional modules */
include_once($config["library_path"] . "/functions.php");
include_once($config["include_path"]
.
"/global_constants.php");
include_once($config["library_path"] . "/plugins.php");
include_once($config["include_path"] . "/plugins.php");
include_once($config["include_path"] . "/global_arrays.php");
Pagina 86 di 190
include_once($config["include_path"]
.
"/global_settings.php");
include_once($config["include_path"] . "/global_form.php");
include_once($config["library_path"] . "/html.php");
include_once($config["library_path"] . "/html_form.php");
include_once($config["library_path"] . "/html_utility.php");
include_once($config["library_path"] . "/html_validate.php");
include_once($config["library_path"] . "/variables.php");
include_once($config["library_path"] . "/auth.php");
api_plugin_hook("config_insert");
Per il file config.php riportiamo le seguenti righe di codice:
/*
make
sure
these
values
refect
your
actual
database/host/user/password */
$database_port = "3306";
$plugins = array();
$plugins[] = 'weathermap';
/* load up old style plugins here */
$plugins = array();
//$plugins[] = 'thold';
$url_path = "http://tier2-cacti.na.infn.it/cacti/";
Pagina 87 di 190
/*
Default
session
name
-
Session
name
must
contain
alpha
characters */
#$cacti_session_name = "Cacti";
Per il file cacti.conf riportiamo le seguenti righe di codice:
Alias /cacti/ /var/www/cacti/
<Directory /var/www/cacti/>
DirectoryIndex index.php
Options -Indexes
AllowOverride all
order deny,allow
Abbiamo commentato le due seguenti righe per permettere di l'accesso a cacti non solo
localmente.
# deny from all
# allow from 127.0.0.1
allow from all
AddType application/x-httpd-php .php
php_flag magic_quotes_gpc on
php_flag track_vars on
</Directory>
5.5
Il Codice Realizzato
Gli strumenti software utilizzati mettono a disposizione principalmente funzionalità di
base, ma il massimo della configurazione e della personalizzazione si ha con la stesura
di script ad hoc scritti da utenti esperti. Questi script permettono di realizzare nuove
funzionalità integrando quelle già esistenti. Infatti le mappe generate con l'editor
Weathermap, per il monitoraggio della rete del Tier2, sono state realizzate e
Pagina 88 di 190
configurate con script scritti da me.
L'implementazione di questi script, hanno permesso la realizzazione della varie mappe
dinamiche e interattive.
Di seguito riportiamo il codice dei file di configurazione di ogni singola mappa
realizzata, partendo dalla mappa generale della rete, fino ad arrivare alle mappe che
rappresentano tutti gli apparati attivi della rete.
L'output, ovvero la mappa generata da ogni file di configurazione, è demandato al
paragrafo Risultati Ottenuti.
Di seguito rappresenteremo i file di configurazione di ogni mappa.
Mappa Atlas_net:
FONTDEFINE
411
/var/www/cacti/plugins/weathermap/docs/example/VeraBd.ttf 8
FONTDEFINE
412
/var/www/cacti/plugins/weathermap/docs/example/Vera.ttf 8
BACKGROUND images/Atlas_cacti_fine2.png
WIDTH 1069
HEIGHT 735
HTMLSTYLE overlib
KEYFONT 3
TITLE Atlas Generale
TIMEPOS 118 11 Created: %b %d %Y
KEYPOS DEFAULT 947 444 Traffic Load
KEYTEXTCOLOR 0 0 0
KEYOUTLINECOLOR 0 0 0
KEYBGCOLOR 255 255 255
BGCOLOR 255 255 255
TITLECOLOR 0 0 0
TIMECOLOR 0 0 0
SCALE DEFAULT 0
0
192 192 192
SCALE DEFAULT 0
1
174 174 157
SCALE DEFAULT 1
10
140
0 255
SCALE DEFAULT 10
25
32 32 255
SCALE DEFAULT 25
40
0 192 255
SCALE DEFAULT 40
55
0 240
0
SCALE DEFAULT 55
70
240 240
0
Pagina 89 di 190
SCALE DEFAULT 70
SCALE DEFAULT 85
85
100
255 192
255
0
0
0
SET key_hidezero_DEFAULT 1
# End of global section
# TEMPLATE-only NODEs:
NODE DEFAULT
MAXVALUE 100
# TEMPLATE-only LINKs:
LINK DEFAULT
BWFONT 412
BWLABEL bits
BANDWIDTH 1000M
# regular NODEs:
NODE node08021
ICON images/tick_{node:this:state}.png
TARGET cactihost:3
POSITION 375 160
NODE node08060
TARGET cactihost:5
POSITION 468 285
NODE node08096
TARGET cactihost:26
POSITION 707 158
NODE node08112
TARGET cactihost:6
POSITION 806 285
NODE node08125
TARGET cactihost:10
POSITION 894 128
NODE node08153
Pagina 90 di 190
TARGET cactihost:17
POSITION 908 369
NODE node08166
TARGET cactihost:18
POSITION 269 573
NODE node05280
ICON images/legenda_cacti.png
POSITION 121 400
NODE node01779
TARGET cactihost:8
POSITION 687 368
NODE INFN
INFOURL
http://tier2cacti.na.infn.it/cacti/plugins/weathermap/weathermap-cactiplugin.php?action=viewmap&id=5f13d0a78f2aa1c594f1
OVERLIBGRAPH
http://tier2cacti.na.infn.it/cacti/plugins/weathermap/images/Tier2_INFN_Co
llegamenti_400pix.png
ICON images/infn.png
POSITION 351 33
NODE SCOPE
http://tier2INFOURL
cacti.na.infn.it/cacti/plugins/weathermap/weathermap-cactiplugin.php?action=viewmap&id=77eada022179f1fafb5a
OVERLIBGRAPH
http://tier2cacti.na.infn.it/cacti/plugins/weathermap/images/Nuovo_SCOPE_p
ag1_400pixel.png
ICON images/Data_center_scope.png
POSITION 591 487
NODE node00438
TARGET cactihost:15
POSITION 889 58
NODE node04057
TARGET cactihost:16
POSITION 88 636
Pagina 91 di 190
NODE node06541
TARGET cactihost:19
POSITION 68 557
NODE node02607
TARGET cactihost:20
POSITION 63 156
# regular LINKs:
LINK node08021-node08096
WIDTH 3
COMMENTFONT 411
COMMENTFONTCOLOR 0 0 0
INFOURL /cacti/graph.php?rra_id=all&local_graph_id=60
OVERLIBGRAPH
/cacti/graph_image.php?
local_graph_id=60&rra_id=0&graph_nolegend=true&graph_height=10
0&graph_width=300
COMMENTPOS 95 40
TARGET /var/www/cacti/rra/cat6509_traffic_in_77.rrd
OUTCOMMENT 1 Gbps
NODES node08021 node08096
WIDTH 3
OVERLIBGRAPH
0&graph_width=300
TARGET /var/www/cacti/rra/mercurio_traffic_in_39.rrd
WIDTH 3
COMMENTFONT 411
OVERLIBGRAPH
0&graph_width=300
COMMENTPOS 90 40
OUTCOMMENT 1 Gbps
Pagina 92 di 190
WIDTH 3
COMMENTFONT 411
OVERLIBGRAPH
0&graph_width=300
COMMENTPOS 70 50
TARGET /var/www/cacti/rra/router-atlas_traffic_in_41.rrd
INCOMMENT Link Aggregation 2 Gbps
NODES node08060:0:1 node08112
BANDWIDTH 2000M
WIDTH 3
COMMENTFONT 411
OVERLIBGRAPH
0&graph_width=300
COMMENTPOS 60 40
TARGET /var/www/cacti/rra/sw3com-atlas02_traffic_in_36.rrd
OUTCOMMENT 10 Gbps
BANDWIDTH 10000M
WIDTH 3
COMMENTFONT 411
OVERLIBGRAPH
0&graph_width=300
COMMENTPOS 60 5
INCOMMENT 10 Gbps
VIA 514 371
BANDWIDTH 10000M
WIDTH 3
COMMENTFONT 411
Pagina 93 di 190
OVERLIBGRAPH
0&graph_width=300
COMMENTPOS 70 50
INCOMMENT 10 Gbps
BANDWIDTH 10000M
WIDTH 3
COMMENTFONT 411
OVERLIBGRAPH
0&graph_width=300
COMMENTPOS 60 40
INCOMMENT 1 Gbps
WIDTH 3
COMMENTFONT 411
OVERLIBGRAPH
0&graph_width=300
COMMENTPOS 70 30
INCOMMENT 10 Gbps
BANDWIDTH 10000M
WIDTH 3
COMMENTFONT 411
OVERLIBGRAPH
0&graph_width=300
COMMENTPOS 60 50
Pagina 94 di 190
INCOMMENT 1 Gbps
WIDTH 3
COMMENTFONT 411
OVERLIBGRAPH
0&graph_width=300
COMMENTPOS 60 50
OUTCOMMENT 1 Gbps
VIA 157 269
Mappa INFN_Comp_attivi:
FONTDEFINE
411
FONTDEFINE
412
BACKGROUND images/Tier2_INFN_Collegamenti.png
WIDTH 1081
HEIGHT 774
HTMLSTYLE overlib
KEYFONT 3
TITLE INFN Collegamenti
TIMEPOS 903 330 .
KEYTEXTCOLOR 0 0 0
BGCOLOR 255 255 255
TITLECOLOR 0 0 0
TIMECOLOR 0 0 0
SCALE DEFAULT 0
0
192 192 192
SCALE DEFAULT 0
1
174 174 157
SCALE DEFAULT 1
10
140
0 255
SCALE DEFAULT 10
25
32 32 255
SCALE DEFAULT 25
40
0 192 255
SCALE DEFAULT 40
55
0 240
0
Pagina 95 di 190
SCALE DEFAULT 55
SCALE DEFAULT 70
SCALE DEFAULT 85
70
85
100
240 240
255 192
255
0
0
0
0
NODE DEFAULT
MAXVALUE 100
LINK DEFAULT
BWFONT 412
BWLABEL bits
BANDWIDTH 100M
# regular NODEs:
NODE node00398
INFOURL
http://tier2cacti.na.infn.it/cacti/plugins/weathermap/weathermap-cactiplugin.php?action=viewmap&id=c0a687d098e5f5637ee2
ICON images/indietro.png
POSITION 27 30
NODE node00473
INFOURL
http://tier2cacti.na.infn.it/cacti/plugins/weathermap/weathermap-cactiplugin.php?action=viewmap&id=f258efeb92e400941ce5
ICON images/avanti1.png
POSITION 1055 30
NODE node09935
OVERLIBGRAPH
rra_id=0&graph_nolegend=true&graph_height=100&graph_width=300&
local_graph_id=33
TARGET cactihost:5
POSITION 449 95
NODE node09967
ICON images/transparent_line.png
Pagina 96 di 190
TARGET cactihost:6
POSITION 401 131
NODE node09991
OVERLIBGRAPH
rra_id=0&graph_nolegend=true&graph_height=100&graph_width=300&
local_graph_id=26
TARGET cactihost:10
POSITION 707 494
NODE node00048
TARGET cactihost:17
POSITION 919 99
NODE node00798
TARGET cactihost:15
POSITION 708 468
NODE node06693
POSITION 549 677
NODE node05808
POSITION 101 109
NODE node06259
POSITION 906 495
NODE node06267
POSITION 437 133
NODE node06751
POSITION 387 100
NODE node06756
POSITION 385 489
NODE node07382
Pagina 97 di 190
TARGET cactihost:6
POSITION 447 489
NODE node07517
POSITION 947 495
NODE node08697
POSITION 523 593
NODE node09220
POSITION 223 76
NODE node09980
TARGET cactihost:8
POSITION 139 468
NODE node00088
TARGET cactihost:17
POSITION 954 463
# regular LINKs:
WIDTH 3
COMMENTFONT 411
OVERLIBGRAPH
0&graph_width=300
COMMENTPOS 60 50
OUTCOMMENT 10 Gbps
VIA 244 156
BANDWIDTH 10000M
WIDTH 3
COMMENTFONT 411
Pagina 98 di 190
OVERLIBGRAPH
0&graph_width=300
COMMENTPOS 95 30
OUTCOMMENT 10 Gbps
VIA 670 189
BANDWIDTH 10000M
WIDTH 3
COMMENTFONT 411
OVERLIBGRAPH
0&graph_width=300
COMMENTPOS 60 50
OUTCOMMENT LACP 2 Gbps
VIA 316 304
BANDWIDTH 2000M
WIDTH 3
COMMENTFONT 411
OVERLIBGRAPH
0&graph_width=300
COMMENTPOS 95 40
OUTCOMMENT 1 Gbps
VIA 577 514
BANDWIDTH 1000M
WIDTH 3
COMMENTFONT 411
OVERLIBGRAPH
Pagina 99 di 190
0&graph_width=300
COMMENTPOS 95 50
OUTCOMMENT 1 Gbps
BANDWIDTH 1000M
WIDTH 3
COMMENTFONT 411
OVERLIBGRAPH
0&graph_width=300
COMMENTPOS 80 5
INCOMMENT 10 Gbps
BANDWIDTH 10000M
WIDTH 3
COMMENTFONT 411
OVERLIBGRAPH
0&graph_width=300
COMMENTPOS 70 5
INCOMMENT 1 Gbps
BANDWIDTH 1000M
WIDTH 3
COMMENTFONT 411
OVERLIBGRAPH
0&graph_width=300
COMMENTPOS 60 40
OUTCOMMENT 1 Gbps
Pagina 100 di 190
VIA 298 103
BANDWIDTH 1000M
Mappa Scope_Comp_attivi1:
BACKGROUND images/Nuovo_SCOPE_pag1.png
WIDTH 1033
HEIGHT 738
TITLE Data Center SCoPE Collegamenti 1
TIMEPOS 385 130 .
KEYPOS DEFAULT -1 -1 Traffic Load
KEYTEXTCOLOR 0 0 0
BGCOLOR 255 255 255
TITLECOLOR 0 0 0
TIMECOLOR 0 0 0
SCALE DEFAULT 0
0
192 192 192
SCALE DEFAULT 0
1
255 255 255
SCALE DEFAULT 1
10
140
0 255
SCALE DEFAULT 10
25
32 32 255
SCALE DEFAULT 25
40
0 192 255
SCALE DEFAULT 40
55
0 240
0
SCALE DEFAULT 55
70
240 240
0
SCALE DEFAULT 70
85
255 192
0
SCALE DEFAULT 85
100 255
0
0
NODE DEFAULT
MAXVALUE 100
LINK DEFAULT
BANDWIDTH 100M
# regular NODEs:
Pagina 101 di 190
NODE node09341
INFOURL
POSITION 30 28
NODE node09441
INFOURL
http://tier2cacti.na.infn.it/cacti/plugins/weathermap/weathermap-cactiplugin.php?action=viewmap&id=dfe6ba4bd28c83ade6ad
POSITION 1003 28
NODE node04456
LABEL spento
LABELOUTLINECOLOR 255 255 255
POSITION 322 128
NODE node04456_copy
LABEL spento
POSITION 322 479
WIDTH 1042
HEIGHT 747
TIMEPOS 418 135 .
KEYTEXTCOLOR 0 0 0
BGCOLOR 255 255 255
TITLECOLOR 0 0 0
TIMECOLOR 0 0 0
SCALE DEFAULT 0
0
192 192 192
SCALE DEFAULT 0
1
255 255 255
SCALE DEFAULT 1
10
140
0 255
SCALE DEFAULT 10
25
32 32 255
SCALE DEFAULT 25
40
0 192 255
SCALE DEFAULT 40
55
0 240
0
Pagina 102 di 190
SCALE DEFAULT 55
SCALE DEFAULT 70
SCALE DEFAULT 85
70
85
100
240 240
255 192
255
0
0
0
0
NODE DEFAULT
MAXVALUE 100
LINK DEFAULT
BANDWIDTH 100M
# regular NODEs:
NODE node04654
INFOURL
http://tier2cacti.na.infn.it/cacti/plugins/weathermap/weathermap-cactiplugin.php?action=viewmap&id=77eada022179f1fafb5a
POSITION 30 28
NODE node04689
INFOURL
http://tier2cacti.na.infn.it/cacti/plugins/weathermap/weathermap-cactiplugin.php?action=viewmap&id=5017e12014ad04c4bb02
POSITION 1017 28
FONTDEFINE
411
FONTDEFINE
412
WIDTH 1057
HEIGHT 753
HTMLSTYLE overlib
KEYFONT 3
Pagina 103 di 190
TIMEPOS 371 245 .
KEYTEXTCOLOR 0 0 0
BGCOLOR 255 255 255
TITLECOLOR 0 0 0
TIMECOLOR 0 0 0
SCALE DEFAULT 0
0
192 192 192
SCALE DEFAULT 0
1
174 174 157
SCALE DEFAULT 1
10
140
0 255
SCALE DEFAULT 10
25
32 32 255
SCALE DEFAULT 25
40
0 192 255
SCALE DEFAULT 40
55
0 240
0
SCALE DEFAULT 55
70
240 240
0
SCALE DEFAULT 70
85
255 192
0
SCALE DEFAULT 85
100 255
0
0
NODE DEFAULT
MAXVALUE 100
LINK DEFAULT
BWFONT 412
BWLABEL bits
BANDWIDTH 100M
# regular NODEs:
NODE node06145
INFOURL
http://tier2cacti.na.infn.it/cacti/plugins/weathermap/weathermap-cactiplugin.php?action=viewmap&id=d4b62418c5d2e31ab6b8
POSITION 1023 28
NODE node09876
INFOURL
http://tier2-
Pagina 104 di 190
cacti.na.infn.it/cacti/plugins/weathermap/weathermap-cactiplugin.php?action=viewmap&id=dfe6ba4bd28c83ade6ad
POSITION 30 28
NODE node03584
TARGET cactihost:18
POSITION 678 141
NODE node03785
TARGET cactihost:16
POSITION 681 261
NODE node08659
LABEL spento
POSITION 812 533
NODE node08659_copy
LABEL spento
POSITION 820 582
NODE node08659_copy_copy
LABEL spento
POSITION 820 646
NODE node08659_copy_copy_copy
LABEL spento
POSITION 823 233
NODE node08659_copy_copy_copy_copy
LABEL spento
POSITION 813 174
NODE node08659_copy_copy_copy_copy_copy
LABEL spento
POSITION 817 287
NODE node06801
Pagina 105 di 190
POSITION 489 636
NODE node07592
POSITION 503 373
NODE node07606
POSITION 663 485
NODE node07807
POSITION 666 613
NODE node01789
TARGET cactihost:19
POSITION 678 200
NODE node01278
TARGET cactihost:14
POSITION 677 104
# regular LINKs:
WIDTH 3
COMMENTFONT 411
OVERLIBGRAPH
0&graph_width=300
COMMENTPOS 60 5
OUTCOMMENT 10 Gbps
VIA 550 447
BANDWIDTH 10000M
WIDTH 3
COMMENTFONT 411
Pagina 106 di 190
OVERLIBGRAPH
0&graph_width=300
OUTCOMMENT 10 Gbps
VIA 705 552
BANDWIDTH 10000M
Mappa CMC_SCOPE:
BACKGROUND images/CMC_SCOPE.png
WIDTH 881
HEIGHT 707
TITLE CMC Data Center SCoPE
TIMEPOS 397 471 .
KEYTEXTCOLOR 0 0 0
BGCOLOR 255 255 255
TITLECOLOR 0 0 0
TIMECOLOR 0 0 0
SCALE DEFAULT 0
0
192 192 192
SCALE DEFAULT 0
1
255 255 255
SCALE DEFAULT 1
10
140
0 255
SCALE DEFAULT 10
25
32 32 255
SCALE DEFAULT 25
40
0 192 255
SCALE DEFAULT 40
55
0 240
0
SCALE DEFAULT 55
70
240 240
0
SCALE DEFAULT 70
85
255 192
0
SCALE DEFAULT 85
100 255
0
0
NODE DEFAULT
MAXVALUE 100
Pagina 107 di 190
LINK DEFAULT
BANDWIDTH 100M
# regular NODEs:
NODE node03882
INFOURL
http://tier2cacti.na.infn.it/cacti/plugins/weathermap/weathermap-cactiplugin.php?action=viewmap&id=5017e12014ad04c4bb02
POSITION 21 30
NODE node03923
INFOURL
POSITION 856 30
NODE node07610
TARGET cactihost:14
POSITION 402 479
NODE node06773
POSITION 736 553
Mappa CMC_INFN:
BACKGROUND images/CMC_INFN.png
WIDTH 888
HEIGHT 706
TITLE CMC INFN
TIMEPOS 398 477 .
KEYTEXTCOLOR 0 0 0
BGCOLOR 255 255 255
TITLECOLOR 0 0 0
TIMECOLOR 0 0 0
SCALE DEFAULT 0
0
192 192 192
SCALE DEFAULT 0
1
255 255 255
Pagina 108 di 190
SCALE
SCALE
SCALE
SCALE
SCALE
SCALE
SCALE
DEFAULT
DEFAULT
DEFAULT
DEFAULT
DEFAULT
DEFAULT
DEFAULT
1
10
25
40
55
70
85
10
25
40
55
70
85
100
140
32
0
0
240
255
255
0 255
32 255
192 255
240
0
240
0
192
0
0
0
NODE DEFAULT
MAXVALUE 100
LINK DEFAULT
BANDWIDTH 100M
# regular NODEs:
NODE node04040
INFOURL
http://tier2cacti.na.infn.it/cacti/plugins/weathermap/weathermap-cactiplugin.php?action=viewmap&id=5f13d0a78f2aa1c594f1
POSITION 25 30
NODE node04107
INFOURL
POSITION 859 30
NODE node07026
TARGET cactihost:6
POSITION 439 458
NODE node06747
POSITION 147 513
Pagina 109 di 190
Come già anticipato, il Sistema di Monitoraggio è frutto di un'aggregazione di diversi
componenti, vedi Component Diagram, non a caso le mappe che ho creato si basano su
una serie di grafici che ho realizzato con il componente RRDTool.
Gran parte del codice dei grafici viene auto-generato da cacti, anche se in alcuni casi
esso è stato modificato da noi.
Attraverso questo codice è possibile definire la dimensione del grafico, il titolo, le
etichette degli assi e soprattutto il tipo di grafico da realizzare: traffico, errori, etc.
Nell'Appendice riportiamo il codice dei grafici realizzati, paragrafo 9.4 Codice dei
Grafici Implementati con RRDTool.
Per inserire la mappa semplificata della rete, nel portale del Tier2, è stato necessario
realizzare una semplice pagina web in formato html, attraverso la quale è possibile
avere una mappa aggiornata, ogni sessanta secondi, della situazione reale del traffico
Di seguito riportiamo il frammento di codice scritto:
<HTML>
<HEAD>
<meta http-equiv="refresh" content="60">
<TITLE>
Atlas Network
</TITLE>
</HEAD>
<BODY>
<p align=center><IMG SRC="http://172.16.7.77/link_atlas_net"
width="70%" ></p> <br/>
<br />
</BODY>
</HTML>
5.6
I Risultati Ottenuti
Per avere un idea chiara del monitoraggio della rete, e quindi delle mappe che
Pagina 110 di 190
realizzano ciò, è opportuno indicare in che modo avviene la navigazione tra le mappe.
La navigazione avviene partendo dalla mappa generale della rete del Tier2, e
attraversando tutte le mappe, si arriva di nuovo alla mappa generale.
Per passare da una mappa all'altra, si clicca su degli appositi pulsanti che permettono
di scorrere le mappe, tranne che per la mappa generale. Quest'ultima permette di
accedere alle varie sezioni, selezionando gli appositi link: INFN o Data Center SCoPE.
Oltre a scorrere le mappe, cliccando su un link che collega due nodi, è possibile
accedere ai grafici inerenti al traffico del link selezionato.
La navigazione è molto intuitiva, visto che passando con il cursore del mouse su un
link o su un bottone, viene visualizzata o l'anteprima della mappa o del grafico che si
andrà a visualizzare.
Partendo dalla mappa centrale, cliccando sul link INFN, si accede alla sezione di rete
che riguarda il data center dell'INFN, mentre cliccando sul link data center S.Co.P.E.
si accede alla sezione di rete che riguarda il data center S.Co.P.E..
Nella mappa dell'INFN sono raffigurati i rack con tutti i dispositivi e i collegamenti,
cliccando sugli appositi bottoni si può andare avanti, visualizzando in dettaglio i CMC
come sono collegati, e indietro per tornare alla mappa iniziale. Come già anticipato i
CMC servono per il controllo dei rack e il monitoraggio dell'ambiente.
Lo stesso discorso vale per la sezione che riguarda il data center di S.Co.P.E., con
l'unica differenza che per rappresentare tutti i dispositivi, e i rack presenti in questa
sezione, sono state implementate ben tre mappe, più una quarta mappa per raffigurare i
collegamenti dei CMC, per il controllo dei rack e il monitoraggio ambientale. Anche
da questa scorrendo in avanti si ricomincia di nuovo dalla mappa generale.
Tutte le mappe, tranne la mappa generale della rete, si possono scorrere andando in
avanti ed indietro, tramite opportuni bottoni che si trovano nella parte superiore di ogni
mappa.
Per rendere l'idea di come si possono scorrere le mappe, mostriamo uno schema
dettagliando anche il verso in cui può avvenire la navigazione:
Pagina 111 di 190
Pagina 112 di 190
Pagina 113 di 190
Pagina 114 di 190
Pagina 115 di 190
Pagina 116 di 190
Pagina 117 di 190
Pagina 118 di 190
Pagina 119 di 190
Figura 5.4 – Schema Navigazione Mappe
La prima mappa che viene mostrata all'utente, è quella generale della rete, che
rappresenta tutti gli apparati con i rispettivi collegamenti, in modo da dare subito un
quadro generale della situazione del traffico sulla rete e degli host.
Le mappe Data Center SCoPE uno, due e tre e la mappa INFN, rappresentano in
dettaglio i rack con tutti gli apparati e i collegamenti tra di essi. Anche in queste mappe
è possibile monitorare il traffico in dettaglio.
Infine ci sono le mappe dei CMC che rappresentano i collegamenti di ogni singolo
apparato CMC ad uno switch. Per queste mappe si è preferito monitorare solo lo stato
dell'apparato a cui sono collegati tutti i CMC e non il traffico, visto che sarebbe stato
un dato poco rilevante.
Da precisare che le didascalie delle immagini che seguiranno corrispondono al nome
degli script che generano le mappe, vedi capitolo Codice Realizzato.
Pagina 120 di 190
Figura 5.5 - Mappa Atlas_Net
Pagina 121 di 190
Figura 5.6 - Mappa INFN_Comp_attivi
Pagina 122 di 190
Figura 5.7 - Mappa Scope_Comp_attivi1
Pagina 123 di 190
Pagina 124 di 190
Pagina 125 di 190
Figura 5.10 - Mappa CMC_SCOPE
Pagina 126 di 190
Figura 5.11 - Mappa CMC_INFN
Pagina 127 di 190
6
Deployment Diagram
Il Deployment Diagram descrive un sistema in termini di risorse hardware detti nodi, e
di relazioni fra di esse. Questo diagramma mostra come le componenti software sono
distribuite rispetto alle risorse hardware, specificando anche in quale componente
hardware ciascun componente software viene eseguito.
Di seguito riportiamo il Deployment Diagram del sistema realizzato:
Figura 6.1 – Deployment Diagram
Cacti con tutti i suo componenti software è in esecuzione sul server dedicato al
monitoraggio della rete del Tier2. Da questo server è possibile raggiungere ed
interrogare i vari dispositivi della rete, per effettuare il monitoraggio. Questo, nella
rappresentazione grafica, viene raffigurato con un nodo chiamato Monitored Devices,
che è collegato al server, e che indica tutti i dispositivi attivi della rete.
Dalla rappresentazione grafica si nota una connessione tra il server Network
Pagina 128 di 190
Monitoring ed il nodo Client attraverso “Internet”. Questa illustrazione indica che è
possibile accedere al sistema di monitoraggio da qualsiasi parte del mondo in cui
l'utente si trova, utilizzando un qualunque browser web.
Dall'illustrazione, figura 6.1, è possibile notare che il server dedicato al monitoraggio
globale dei servizi del Tier2, ovvero il nodo server global monitoring, non ha nessun
collegamento con il server Network Monitoring.
Il nodo server global monitoring, mostra la componente software Liferay Portal, in
quale componente hardware viene eseguita e quali sono le dipendenze. Da quanto si
può vedere gli unici collegamenti che ci sono, sono relativi ai componenti software:
cacti e web server cacti.
Per mettere in esercizio il sistema di monitoraggio che ho realizzato, secondo lo
schema appena descritto, è stato necessario aggiungere una nuova macchina virtuale,
chiamata AtlasNetwork, al server dedicato al monitoraggio del Tier2: virtusatlas01. Ed
è proprio su AtlasNetwork che è in esecuzione il sistema di monitoraggio realizzato.
Le principali caratteristiche del server virtusatlas01 sono:
Hostaname: virtusatlas01
Manufacturer: Supermicro
Model: X8DTU
Processors: Intel(R) Xeon(R) CPU E5506 @2.13GHz
1CPU x 4 Cores
Memory: 23.56 GB
Inizialmente la macchina virtuale AtlasNetwork è stata realizzata con appositi tool, su
un computer locale, e successivamente è stata trasportata sul server virtusatlas01
tramite appositi comandi.
Le principali caratteristiche della macchina virtuale AtlasNetwork sono :
Hardware:
Memory: 2048 MB di Ram
Pagina 129 di 190
Processors: 2x4.166 GHz
Hard Disk: 20 GB
Software:
Red Hat Enterprise Linux 5 (32-bit)
Con queste informazioni che ho dato, termina la descrizione del deployment diagram.
Pagina 130 di 190
7
Caso di Studio reale: Il Monitoraggio della Rete del Tier2
7.1
I servizi Monitorati
Grazie all'attenta analisi che ho effettuato sulla rete del Tier2 (vedi capitolo 3) e grazie
alla realizzazione del sistema di monitoraggio, ho potuto effettuare un vero e proprio
studio sulla rete in questione.
L'obbiettivo di questo studio è capire eventuali malfunzionamenti della rete come
congestione, perdita di informazioni o di errori, durante il trasferimento dei dati, al fine
di valutarne l'Affidabilità e la Performance.
Si esegue il monitoraggio dei seguenti dispositivi attivi della rete del Tier2:
Per l'host mercurio si monitorano i seguenti dati:
•
Traffico di entrata e di uscita da e verso il POP GARR
•
Traffico di entrata e di uscita da e verso il router ATLAS
•
Pacchetti danneggiati o eventuali errori verso il POP GARR
•
Pacchetti danneggiati o eventuali errori verso il router ATLAS
•
Il Round Trip Time dell'host mercurio
Per l'host router-atlas si monitorano i seguenti dati:
•
Traffico di entrata e di uscita da e verso il POP GARR
•
Traffico di entrata e di uscita da e verso lo switch sw3com-atlas02
•
Pacchetti danneggiati o eventuali errori verso il POP GARR
•
Pacchetti danneggiati o eventuali errori verso lo switch sw3com-atlas02
•
Il Round Trip Time dell'host router-atlas
Per l'host sw3com-atlas02 si monitorano i seguenti dati:
•
Traffico di entrata e di uscita da e verso lo switch swdell-scope01
•
•
Pagina 131 di 190
•
Traffico di entrata e di uscita da e verso lo switch swdell-atlas01
•
Pacchetti danneggiati o eventuali errori verso lo switch swdell-scope01
•
•
•
Pacchetti danneggiati o eventuali errori verso lo switch swdell-atlas01
•
Il Round Trip Time dell'host sw3com-atlas02
•
Traffico di entrata e di uscita da e verso lo switch swdell-atlas01
•
Pacchetti danneggiati o eventuali errori verso lo switch swdell-atlas01
•
Per l'host cat6509 si monitorano i seguenti dati:
•
•
Traffico di entrata e di uscita da e verso il router mercurio
•
Pacchetti danneggiati o eventuali errori verso il router mercurio
•
•
Il Round Trip Time dell'host cat6509
•
•
Per l'host swdell-atlas01 si monitorano i seguenti dati:
•
Il Round Trip Time dell'host swdell-atlas01
Per l'host swdell-scope01 si monitorano i seguenti dati:
Pagina 132 di 190
•
Il Round Trip Time dell'host swdell-scope01
E' da precisare che è stato possibile capire la topologia della rete, le connessioni, e
come questa fosse organizzata con gli apparati, grazie al duro lavoro che abbiamo
effettuato nella fase di Analisi dell'Infrastruttura della rete.
Nel prossimo paragrafo mostreremo i risultati ottenuti dal monitoraggio dei servizi
7.2
Risultati Ottenuti
In seguito ad una attenta analisi della rete e dei dati monitorati, abbiamo deciso di
riportare solo i grafici dei principali dispositivi della rete, in quanto mostrano a pieno
la situazione del traffico della rete del Tier2.
Anche se i servizi monitorati sono i medesimi, si è ritenuto riportare i grafici del
monitoraggio per l'host mercurio, router-atlas, sw3com-atlas02 e cat6509, per dare
l'idea effettiva del traffico della rete del Tier2.
Partendo dall'host mercurio:
mostriamo il grafico dell'andamento del traffico da e verso il POP GARR figura 7.1:
Pagina 133 di 190
Pagina 134 di 190
Pagina 135 di 190
Pagina 136 di 190
Pagina 137 di 190
Pagina 138 di 190
Figura 7.1 – Traffico tra mercurio e il POP GARR
mostriamo il grafico dell'andamento del traffico da e verso il router-atlas, figura 7.1:
Figura 7.2 – Traffico tra mercurio e il router atlas
Come è evidente dalle figure 7.1 e 7.2, i grafici sono composti da due informazioni
sovrapposte, vale a dire le linee di colore blu rappresentano i dati in uscita
dall'apparato di rete, mentre quelle in verde sono i dati in ingresso. I grafici sono
strutturati su gli assi x,y, dove l'asse x rappresenta l'avanzamento temporale, mentre
Pagina 139 di 190
l'asse y rappresenta quanti bit sono trasferiti al secondo.
Dalle figure è possibile evincere che gli apparati sono sempre in attività, e che in
alcuni momenti il traffico si intensifica.
Inoltre dai grafici è possibile avere informazioni dettagliate come valori correnti,
valori medi e massimi per un massimo di dati trasferiti, oltre che alla data e l'ora.
Mostriamo il grafico dei pacchetti danneggiati o degli eventuali errori verso il POP
GARR:
Figura 7.3 – Errors/Discarded Packets tra mercurio e il POP GARR
Mostriamo il grafico dei pacchetti danneggiati o degli eventuali errori verso il routeratlas:
Pagina 140 di 190
Figura 7.4 – Errors/Discarded Packets tra mercurio e il router atlas
Con i grafici rappresentati in figura 7.3, e figura 7.4, è possibile monitorare gli errori
presenti sulla rete da mercurio al router atlas, e al POP GARR.
Questi grafici offrono la possibilità di visionare errori in ingresso, evidenziati in rosso
ed in uscita, evidenziati in verde. Per poter offrire un buon servizio, si è scelto di
inserire nello stesso grafico anche dati relativi a pacchetti persi o danneggiati. Con il
colore arancione si evidenziano i pacchetti persi o danneggiati in ingresso, mentre con
il colore verde si evidenziano i pacchetti persi o danneggiati in uscita.
Dai grafici e dai valori che indicano, è possibile evincere che non c'è nessun tipo di
errore durante la trasmissione.
Infine mostriamo il grafico relativo al monitoraggio del Round Trip Time:
Pagina 141 di 190
Figura 7.5 – Ping Latency mercurio
Questo grafico ci indica quanti millisecondi occorrono per un pacchetto di dimensione
trascurabile per viaggiare dal dispositivo mercurio e il sistema di monitoraggio e
tornare indietro. Se il valore del Round Trip Time è elevato vuol dire che ci sono
problemi nel raggiungere il dispositivo, o addirittura che il dispositivo non è
raggiungibile. Questo è assicurato da una soglia minima del valore RTT.
Facendo riferimento all'host router-atlas abbiamo i seguenti grafici:
Monitoraggio del Traffico di entrata e di uscita da e verso il POP GARR:
Pagina 142 di 190
Figura 7.6 – Traffico tra il router atlas e il POP GARR
Monitoraggio del Traffico di entrata e di uscita da e verso lo switch sw3com-atlas02:
Pagina 143 di 190
Figura 7.7 – Traffico tra il router atlas e lo switch sw3com-atlas02
Dalle figure 7.6 e 7.7, è possibile evincere che gli apparati hanno un'attività intensa, la
mole di dati trasferiti dal POP GARR al dispositivo sw3com-atlas02, attraverso il
router atlas, sia in entrata che in uscita e notevole.
Dai grafici è possibile notare picchi di traffico in entrata e uscita dovuti ad un
intensificazione del trasferimento dei dati in alcuni momenti.
Monitoraggio dei Pacchetti danneggiati o di eventuali errori verso il POP GARR:
Figura 7.8 – Errors/Discarded Packets tra il router atlas e il POP GARR
Pagina 144 di 190
Monitoraggio dei Pacchetti danneggiati o di eventuali errori verso lo switch sw3comatlas02:
Figura 7.9 – Errors/Discarded Packets tra il router atlas e lo switch sw3com-atlas02
Da quanto si può vedere dai grafici figura 7.8 e figura 7.9, c'è una discreta perdita di
pacchetti in uscita verso l'apparato sw3com-atlas02 e verso il POP GARR. Questi dati
non sono preoccupanti, visto la grande mole di dati trasferiti dal router-atlas.
Monitoraggio del Round Trip Time dell'host router-atlas:
Figura 7.10 – Ping Latency router atlas
Questo grafico, figura 7.10, ci indica quanti millisecondi occorrono per un pacchetto di
dimensione trascurabile per viaggiare dal router-atlas al sistema di monitoraggio e
tornare indietro. Se il valore del Round Trip Time è elevato, e quindi supera il valore di
Pagina 145 di 190
soglia garantita, vuol dire che ci sono problemi nel raggiungere il dispositivo, o
addirittura che il dispositivo non è raggiungibile.
Facendo riferimento all'host sw3com-atlas02 abbiamo i seguenti grafici:
Monitoraggio del Traffico di entrata e di uscita da e verso lo switch swdell-scope01:
Figura 7.11 – Traffico tra lo switch sw3com-atlas02 e lo switch swDell-scope01
Dal grafico, figura 7.11, è possibile notare che non esiste un attività intensa di traffico
sia in entrata che in uscita verso l'apparato swdell-scope01. Infatti dall'analisi della rete
risulta che sul dispositivo swdell-scope01 sono collegate delle macchine virtuali che
offrono servizio per la rete dell'INFN.
Pagina 146 di 190
Figura 7.12 – Traffico tra lo switch sw3com-atlas02 e lo switch sw3com-atlas01
Figura 7.13 – Traffico tra lo switch sw3com-atlas02 e lo switch sw3com-atlas03
Monitoraggio del Traffico di entrata e di uscita da e verso lo switch swdell-atlas01:
Pagina 147 di 190
Figura 7.14 – Traffico tra lo switch sw3com-atlas02 e lo switch swDell-atlas01
Analizzando questi grafici, figura 7.12, figura 7.13 e figura 7.14 è possibile notare che
esiste un traffico di dati considerevole. Infatti è su questi apparati che si basa l'intero
sistema di calcolo della rete del Tier2. Ovvero dove sono collegati i server che
eseguono le continue operazioni richieste.
Monitoraggio dei Pacchetti danneggiati o di eventuali errori verso lo switch swdellscope01:
Figura 7.15 – Errors/Discarded Packets tra gli switch sw3com-atlas02 e swdell-scope01
Monitoraggio dei Pacchetti danneggiati o di eventuali errori verso lo switch sw3com-
Pagina 148 di 190
atlas01:
Figura 7.16 – Errors/Discarded Packets tra gli switch sw3com-atlas02 e sw3com-atlas01
Figura 7.17 – Errors/Discarded Packets tra gli switch sw3com-atlas02 e sw3com-atlas03
Monitoraggio dei Pacchetti danneggiati o eventuali errori verso lo switch swdell-
Pagina 149 di 190
atlas01:
Figura 7.18 – Errors/Discarded Packets tra gli switch sw3com-atlas02 e swDell-atlas01
Da quanto si può vedere dai grafici che vanno dalla figura 7.15 alla figura 7.18, c'è una
discreta perdita di pacchetti in entrata verso gli apparati sw3com-atlas01, sw3comatlas03, swdell-atlas01 e swdell-scope01. Questi dati non sono preoccupanti, visto la
grande mole di dati trasferiti dallo switch sw3com-atlas02.
Monitoraggio del Round Trip Time dell'host sw3com-atlas02:
Figura 7.19 – Ping Latency sw3com-atlas02
Questo grafico, figura 7.19, ci indica quanti millisecondi occorrono per un pacchetto di
dimensione trascurabile per viaggiare dallo sw3com.atlas02 al sistema di monitoraggio
Pagina 150 di 190
e tornare indietro. Se il valore del Round Trip Time è elevato, e quindi supera il valore
di soglia garantita, vuol dire che ci sono problemi nel raggiungere il dispositivo, o
addirittura che il dispositivo non è raggiungibile.
Fecendo riferimento all'host cat6509 abbiamo i seguenti grafici:
Figura 7.20 – Traffico tra lo switch cat6509 e lo switch sw3com-atlas02
Monitoraggio del Traffico di entrata e di uscita da e verso il router mercurio:
Figura 7.21 – Traffico tra lo switch cat6509 e il router mercurio
Pagina 151 di 190
Analizzando questi grafici, figura 7.20 e figura 7.21, è possibile notare che esiste un
discreto traffico di dati. Infatti su questo dispositivo si poggia l'intera rete del
dipartimento dell'INFN.
Monitoraggio dei Pacchetti danneggiati o di eventuali errori verso il router mercurio:
Figura 7.22 – Errors/Discarded Packets tra lo switch cat6509 e il router mercurio
Figura 7.23 – Errors/Discarded Packets tra gli switch cat6509 e sw3com-atlas02
Analizzando la figura 7.23, notiamo che non ci sono ne errori ne pacchetti persi
Pagina 152 di 190
durante la trasmissione dei dati. Mentre analizzando la figura 7.22, notiamo che esiste
una discreta quantità di pacchetti persi in entrata dal router mercurio, durante la
trasmissione dei dati. Questi valori non sono preoccupanti.
Monitoraggio del Round Trip Time dell'host cat6509:
Figura 7.24 – Ping Latency cat6509
Dalla figura 7.24 è possibile notare che l'host cat6509 è raggiungibile, indicando
quanti millisecondi occorrono per un pacchetto di dimensione trascurabile per
viaggiare dall'host al sistema di monitoraggio e tornare indietro.
Attraverso questi grafici, che ho realizzato con cacti ed il componente RRDTool, è
stato possibile controllare il traffico dati, eventuali errori o perdita di pacchetti nella
rete. Ma solo attraverso le mappe che ho realizzato, si ha un idea ben chiara del
traffico in tempo reale.
Infatti con scala di colori, utilizzata per monitorare i link di collegamento tra un
dispositivo ed un altro, è possibile capire se i link sono congestionati o meno, mentre
con l'immagine della spunta è possibile conoscere lo stato attuale degli host.
Al fine di comprendere meglio il contributo versato, attraverso il sistema che ho
realizzato, riporto la mappa generale del traffico di questo caso di studio, vedi figura
7.25.
Pagina 153 di 190
Pagina 154 di 190
Figura 7.25 – Mappa generale del traffico della rete del caso di studio effettuato
Pagina 155 di 190
8
Considerazioni conclusive
Effettuando un'attenta analisi sull'infrastruttura della rete del Tier2, ed effettuando uno
studio (vedi capitolo precedente), attraverso il software di monitoraggio che ho
sviluppato, è stato possibile valutare le caratteristiche “qualitative” del Data Center,
ovvero Affidabilità e Performance, al fine di garantirle e migliorarle.
Come già anticipato, l'affidabilità di una rete implica l'adozione di apparecchiature
affidabili e di una progettazione della rete che tenga conto di difetti ed errori di
funzionamento.
A mio parere, per aumentare l'affidabilità della rete del Tier2, sarebbe necessario
duplicare principalmente questi nodi: il router-atlas1, centro stella della rete e lo switch
sw3com-atlas021. In modo tale, da garantire il funzionamento della rete anche nel caso
in cui questi nodi dovessero “cadere”, o non funzionare correttamente.
Ritengo opportuno duplicare solo questi nodi, perché in caso di malfunzionamento di
qualche altro apparato, si potrebbe pensare di ri-convergere il traffico della rete su altri
apparati.
Oltre alla ridondanza di alcuni componenti della rete per aumentare l'affidabilità, per
avere dei miglioramenti prestazionali, e quindi migliorare la performance della rete,
sarebbe opportuno effettuare i seguenti cambiamenti:
•
sostituire il centro stella attuale, che ha porte a 1 Gbps, con un altro
concentratore, con 24 porte a 10 Gbps. In modo da collegare i Service Node, i
Worker Node e gli Storage Element direttamente a queste porte a 10 Gbps.
Avendo un aumento considerevole della prestazioni della rete.
•
visto che il router mercurio1 è collegato al router-atlas1 a 1 Gbps, sarebbe
interessante utilizzare il collegamento a 1 Gbps, che collega attualmente il
Juniper GARR con il router mercurio1, per il router-atlas1.
In modo da avere un collegamento a 2 Gbps (Link Aggregations), tra il Juniper
GARR ed il router-atlas1, a fronte di 1 Gbps attuale che viene utilizzato. Con
Pagina 156 di 190
questa soluzione, il traffico dati del dipartimento dell'INFN passerebbe
attraverso mercurio per il router-atlas1. Ovviamente applicando una “politica” di
load balancing a questo collegamento, al fine di non dedicare tutti i 2 Gbps di
banda alla rete del Tier2. Quindi bilanciando il traffico tra le due reti: la rete del
Tier2 e la rete del dipartimento di Fisica.
Questa sarebbe una proposta No-Cost, visto che i collegamenti ci sono, e
l'attuale centro stella permette di creare un link aggregations a 2 Gbps,
smistando il traffico in VLAN separate: la rete Tier2 e la rete del dipartimento
Fisica, in maniera bilanciata.
Apportando le modifiche che ho appena proposto, si garantirebbe una maggiore
affidabilità, sicurezza, e performance al Data Center Tier2.
Grazie ad uno studio dettagliato sulle configurazioni degli apparati, che ho svolto
durante l'analisi della rete, si è deciso di apportare delle modifiche alla configurazione
di alcuni apparati attivi. Ovvero si è deciso di configurare, nella sezione del Data
Center S.Co.P.E, tutti e quattro gli switch DELL 6248 in stacking configuration, in
modo da avere dei miglioramenti in termini prestazionali.
L'attività di Tirocinio, svolta in questi mesi presso la Control Room di S.Co.P.E., mi ha
permesso di acquisire competenze specifiche sia nell'ambito dei sistemi di
monitoraggio per reti informatiche, sia nell'ambito dell'infrastruttura e configurazione
delle reti ad altre prestazioni e ad alta affidabilità.
L'obbiettivo di realizzare un sistema di monitoraggio per una rete di un sistema di
calcolo distribuito, ad alte prestazioni e ad alta affidabilità, è stato raggiunto con ottimi
risultati.
Infatti, il lavoro che ho realizzato è stato anche presentato alla Conferenza GARR
2010 che si è tenuta presso il Politecnico di Torino dal 26 al 28 Ottobre 2010. Il titolo
del progetto in cui è stato presentato il sistema di monitoraggio realizzato è: un
Pagina 157 di 190
portale di monitoraggio centralizzato per i centri di calcolo distribuito.
Inoltre, è da considerare che il sistema che ho realizzato risulta essere attualmente in
esercizio, ed è utilizzato dagli operatori addetti al Data Center del Tier2 di Napoli,
dell'Istituto Nazionale Fisica Nucleare.
Il sistema è raggiungibile via web o dall'indirizzo http://tier2-cacti.na.infn.it/cacti/, o
dal portale dedicato al monitoraggio di tutti i servizi del Tier2, all'indirizzo web
http://tier2.na.infn.it/, nella sezione Network Monitoring.
Pagina 158 di 190
9
Appendice
9.1
Guida d'Uso di Weathermap
L’esecuzione di Weathermap
Ci sono due modi di eseguire Weathermap: come un plugin di Cacti, oppure come un
tool standalone.
Nel primo caso, l’esecuzione è automatica: il plugin gira nell’ambito del ciclo di
polling di Cacti. Basta quindi aggiungere il file di configurazione delle mappe, come
illustrato poco più avanti.
Nel secondo caso, bisogna appunto utilizzare i comandi come elencati nella guida CLI
Reference; un esempio di comando è il seguente:
php ./weathermap --config myconfigfile.conf --output mymap.png --htmloutput
mymap.html
É possibile saltare i comandi htmloutput e output se nel file di configurazone sono
presenti delle righe che specificano HTMLOUTPUTFILE e IMAGEOUTPUTFILE.
Un comando come quello sopra riportato viene spesso (ma non è obbligatorio)
eseguito periodicamente, ad esempio ogni 5 minuti, e per far questo va creato un 'cron
job'. Poiché però weathermap utilizza dati raccolti da altri programmi, anche questi
programmi devono avere un corrispondente ‘cron job’.
Weathermap produce i propri output sulla base di file di configurazione. Se uno ha già
questi file, essi vanno copiati nella cartella /var/www/cacti/waeathermap/configs. I file
di configurazione appaiono listati come segue, se sono già noti a cacti (cliccando sul
link a sinistra della pagina di console di cacti); altrimenti con il comando “add” si
aggiungono i file voluti, e la lista viene aggiornata con i nuovi file di configurazione,
vedi figura 9.1.
Pagina 159 di 190
Figura 9.1 – Screen Shoot Weathermap
Bisogna però attendere un ciclo di polling, generalmente cinque minuti, per vedere le
mappe dal ‘tab’ Weathermap e verificare così che i file di configurazione sono corretti.
Eventuali errori sono nel file cacti.log nella directory /var/www/cacti/log. Il livello di
debug, come più avanti illustrato, può essere incrementato per avere più informazioni,
ma generalmente non ce n’è bisogno.
La gestione delle mappe - il controllo dell’accesso
La gestione del controllo degli accessi viene gestita su due livelli gerarchici: va prima
detto quale utente può vedere il “tab” corrispondente al plugin Weathermap, e va poi
detto quale particolare Weathermap ogni utente abilitato può vedere.
Il primo livello è gestito da Cacti: nella sezione User Management, bisogna dare al
singolo utente il diritto ‘View Weathermaps”.
Il secondo livello è gestito dal plugin Weathermap: agendo sul link della mappa creata
nella colonna ‘Accessible By”, viene visualizzata una finestra come quella che segue,
figura 9.2. Si può dare l’autorizzazione ad ogni singolo utente, oppure a “Anyone”.
Figura 9.2 – Gestione delle Mappe
Pagina 160 di 190
La pagina di management di Weathermap permette anche di cambiare l’ordine in cui le
mappe sono mostrate.
Come visualizzare le mappe
L'utente agendo sul ‘tab’ denominato Weathermap, visualizza in formato ridotto tutte
le Weathermap per cui è abilitato, figura 9.3, e può visualizzarne una cliccandoci
sopra, oppure fare un ciclo in cui più mappe sono visualizzate ciclicamente.
Figura 9.3 – Visualizzazione Mappe
Poiché la singola mappa può essere stata creata con dei popup di Cacti, l’utente deve
essere stato abilitato anche a vedere questi grafici di Cacti.
La gestione delle mappe – le opzioni di visualizzazione
Tutti i settaggi di Weathermap sono nel ‘tab’ denominato ‘Misc’ nella pagina dei
setting di Cacti, che a sua volta si visualizza andando su ‘Console’ e poi ‘Settings’ a
sinistra.
La pagina che viene visualizzata è la seguente:
Pagina 161 di 190
Figura 9.4 – Console
Come si vede dalla figura 9.4, la prima opzione riguarda semplicemente la periodicità
con cui verificare se sono disponibili aggiornamenti al software; le altre cinque opzioni
riguardano esplicitamente Weathermap, e sono: ‘Page style’, ‘Thumbnail maximum
size’, ‘Refresh time’, ‘Output format’, ‘Map rendering interval’.
Page style dà la possibilità di scegliere tra due modalità, corrispondenti a cosa si vedrà
quando si apre il ‘tab’ Weathermap: un insieme di mappe a dimensioni reali, cioè tutto
schermo, oppure dei ‘thumbnail’, delle miniature delle mappe stesse. Se le mappe sono
molte, conviene avere delle miniature, sulle quali poi cliccare per visualizzarle. In
entrambi i casi, si può avere sempre la modalità ciclica già descritta in precedenza, per
cui se uno deve vedere due mappe, queste si alternano sullo schermo ad intervalli
regolari.
Se l’utente ha una sola mappa, tutte queste opzioni non hanno senso, cioè possono
essere settate o meno, ma non influenzeranno la modalità di visualizzazione della
Weathermap.
Pagina 162 di 190
L’effetto della scelta ‘thumbnail’, se si ha più di una mappa, è ritardato fino al
successivo ciclo di polling, tipicamente 5 minuti.
Refresh time permette di fissare il tempo di visualizzazione di ogni mappa; se si mette
su automatico, il tempo di polling (dei default 5 minuti) viene diviso per il numero
delle mappe da visualizzare: ad esempio, se le mappe sono 10, ne viene visualizzata
una ogni mezzo minuto; se sono cinque, una ogni minuto. Questo parametro non ha
nulla a che vedere con la durata del ciclo di polling, da cui però dipende se si sceglie la
modalità automatica.
Output Format permette di scegliere il formato delle immagini create da Weathermap s
disco, e visualizzate sullo schermo: il formato può essere PNG, GIF, JPG; il default è
PNG.
Map Rendering Interval serve a fissare il tempo di refresh, in termini di multipli del
tempo di polling. Ad esempio, se il polling usato in Cacti è molto frequente (un
minuto), può essere utile avere le Weathermap ogni due cicli, cioè ogni due minuti.
During that one cycle when it does redraw, your polling cycle will still be longer than
usual, so you can also turn off the poller part of Weathermap, so that it doesn't redraw
at all. This allows you to use the user-access parts of the plugin, but manage the
redrawing of maps yourself. To redraw all the maps outside of the standard Cacti
poller process, there is a special PHP script weathermapcacti-rebuild.php that does
the same job as the Cacti poller. To use this, you need to edit it, and change the path in
the top of the file to point to your Cacti root directory. Then set up a second
/etc/crontab entry, to redraw your Weathermaps without slowing down your Cacti
polling:
*/5 * * * * cactiuser /usr/bin/php /your/cacti/path/plugins/weathermap/ weathermapcacti-rebuild.php
You will need to change the paths to php and cacti, and the user that cacti runs as. If
Pagina 163 di 190
you use 'crontab -e', instead of editing /etc/crontab directly, then you should remove
the 'cactiuser'. In normal use, you don't need to add a cron job - the Cacti poller does
this work for you.
La gestione degli errori
Weathermap è dotato di un buon sistema di logging. Se si hanno problemi nell’uso, è
spesso
sufficiente
vedere
il
file
cacti.log
(normalmente
in
/var/www/cacti/log/cacti.log): le rige che iniziano con i caratteri WEATHERMAP
sono ovviamente prodotte da Weathermap. Cacti ha due
livelli di logging, che vengono usati da Weathermap: LOW e DEBUG. Se si fissa il
livello a DEBUG, allora le informazioni che andranno nel log sono numerosissime.
Ricalcolare le mappe
La pagina di management di Weathermap è dotata anche di un comando 'Recalculate
NOW', che consente di ricalcolare tutte le mappe, cioè di eseguire il codice
corrispondente. Le problematiche che possono insorgere con questo comando sono
dovute ai permessi dei file: normalmente i file grafici, ad esempi i PNG, vanno nella
cartella /var/www/cacti/output, il cui owner è ‘cactiuser’. Se si usa il comando
‘Recalculate NOW’, il proprietario dei file sarà l’utente con cui gira il webserver
(httpd), ad esempop nobody. Pertanto, la directory /var/www/cacti/output deve avere i
permessi di scrittura sia per cactiuser sia per nobody. La soluzione facile è di dare il
comando chmod 777 /var/www/cacti/output, e chmod 777 /var/www/cacti/output/*,
ma questo vuol dire che chiunque può scrivere in questa directory. In alternativa, è
consigliabile creare un nuovo gruppo di utenti, ad esempio cactigroup, fare in modo
che sia cactiuser sia nobody facciano parte di questo gruppo, e poi dare chgrp –R
cactigroup /var/www/cacti/output e poi chmod 770 /var/www/cacti/output, e chmod
770 /var/www/cacti/output.
Comunque, normalmente non vi è nessun bisogno di ricalcolare le mappe, basta
aspettare il successivo ciclo di polling.
Pagina 164 di 190
I comandi basilari per la creazione di mappe
Una Weathermap è definita da un file di testo che normalmente è chiamato
weathermap.conf; è possibile ovviamente avere molti file di configurazione, con nomi
diversi. Di default, weathermap legge il file e lo esegue, all’interno di cacti,
producendo nella directory /var/www/cacti/output un file del tipo PNG denominato
weathermap.png. Più avanti vi è un esempio completo del fle di configurazione.
Il file di configurazione ha tre sezioni: Node definitions, Link definitions e Global
settings.
I nodi sono i punti sulla rete che sono uniti insieme: ad esempio i router. In una mappa
molto semplice, un nodo è caratterizzato da tre informazioni: un nome interno
(univoco), la sua posizione in pixel (relativa all’angolo in alto a sinistra della mappa),
ed una etichetta o label, che apparirà in un box corrispondente alla posizione del nodo.
Se un nodo non ha la label, non apparirà sulla mappa, ma potrà comunque esservi in
quella posizione la linea terminale di un link da un altro nodo. Un esempio di
definizione di nodo è il seguente:
NODE nycore1
LABEL NYC
POSITION 30 30
I link sono le connessioni o route della rete tra i vari nodi. Normalmente sono dei veri
e propri link, ad esempio il link tra due router; tuttavia, è possibile trattare come un
link qualsiasi altra cosa rappresentabile numericamente sulla mappa. Un link
elementare ha tre informazioni: un nome interno (univoco), il nome del primo nodo ed
il nome del secondo nodo. Per mostrare i dati sulla mappa, c’è bisogno di dare altre
due informazioni: il primo è la banda massima (BANDWIDTH), ad esempio
100.000.000 bit/sec; si possono però usare le lettere K, M, G e T, nell’esempio 100 M.
Il secondo è la sorgente dei dati (TARGET), che può essere: (a) un file HTML
Pagina 165 di 190
generato da MRTG; (b) un file RRD generato da Cacti; (c) un file RRD di altra
provenienza. Un esempio di definizione di link è il seguente:
LINK backbone1
NODES nycore1 paix1
BANDWIDTH 3M
TARGET ../my-mrtg-data/backbone1.html
L’ordine dei nodi nella definizione del link è importante: il primo è il nodo locale, il
secondo è il modo verso cui vano i dati. Del resto, se uno sbaglia l’ordine basta
invertirli nell’elencazione suddetta.
Parametri generali di configurazione (global settings)
Questi settaggi vengono solitamente messi all’inizio del file di testo che specifica la
configurazione, e servono a fissare alcuni parametri di base. I parametri minimi sono
WIDTH e HEIGHT, che specificano la dimensione della mappa in pixel; ad esempio:
WIDTH 800
HEIGHT 600
In questo modo lo sfondo è un rettangolo nero; se si vuole, come accade quasi sempre,
uno sfondo diverso, basta avere una immagine di sfondo in formato PNG e specificarla
come segue:
BACKGROUND western-europe.png
Altri parametri servono a fissare le fonti, il colore dei vari elementi, la legenda, i nomi
dei file etc. In generale, esistono tre categorie di opzioni – o meglio di direttive – che
possono essere inserite nel file di configurazione:
Direttive specifiche per i nodi:
NODE
TEMPLATE
POSITION
LABEL
TARGET
USESCALE
MAXVALUE
ICON
USEICONSCALE LABELOFFSET LABELANGLE LABELFONT *COLOR INFOURL
Pagina 166 di 190
OVERLIBGRAPH
OVERLIBWIDTH
OVERLIBHEIGHT
OVERLIBCAPTION
NOTES
SET ZORDER
Direttive specifiche per i link:
LINK
TEMPLATE
BWLABEL
NODES
TARGET
INBWFORMA T
BWFONT
OUTBWFORMA T
INCOMMENT
COMMENTSTYLE SPLITPOS
OUTINFOURL
OUTCOMMENT
*COLOR
WIDTH
BANDWIDTH
BWSTYLE
COMMENTFONT
INFOURL
DUPLEX
BWLABELPOS
COMMENTPOS
ININFOURL
OVERLIBGRAPH
OUTOVERLIBGRAPH
OVERLIBCAPTION
USESCALE
INOVERLIBGRAPH
OVERLIBWIDTH
INOVERLIBCAPTION
OVERLIBHEIGHT
OUTOVERLIBCAPTION
NOTES
INNOTES OUTNOTES VIA VIASTYLE LINKSTYLE ARROWSTYLE SET ZORDER
Direttive generali
BACKGROUND
WIDTH
HEIGHT
HTMLOUTPUTFILE
HTMLSTYLESHEET IMAGEOUTPUTFILE IMAGEURI FONTDEFINE *FONT
*COLOR
TIMEPOS
MINTIMEPOS
MAXTIMEPOS
TITLE
TITLEPOS
KILO
HTMLSTYLE SCALE KEYPOS KEYSTYLE SET
Una lista completa del significato delle direttive è presentata più avanti.
Un esempio di file Config
Qui di seguito è presentato un file di configurazione completo; esso produce la mappa
riportata subito dopo.
BACKGROUND background.png
HTMLOUTPUTFILE example.html
IMAGEOUTPUTFILE example.png
TITLE Network Overview
HTMLSTYLE overlib
KEYPOS 10 400
# define some new TrueType fonts - built-in ones go from 1 to
Pagina 167 di 190
5, so start high FONTDEFINE 100 VeraIt 8
FONTDEFINE 101 Vera 12
FONTDEFINE 102 Vera 9
KEYFONT 102
LINK DEFAULT
BANDWIDTH 100M
BWLABEL bits
BWFONT 100
OVERLIBWIDTH 395
OVERLIBHEIGHT 153
WIDTH 4
NODE DEFAULT
LABELFONT 101
NODE transit
POSITION 400 180
LABEL TRANSIT
# a little splash of background colour for these nodes
NODE isp1
POSITION 250 100
LABEL ISP1
INFOURL http://www.isp1.com/support/lookingglass.html
LABELBGCOLOR 255 224 224
NODE isp2
POSITION 550 100
LABEL ISP2
INFOURL http://www.isp2.net/portal/
LABELBGCOLOR 224 255 224
NODE core
Pagina 168 di 190
POSITION 400 300
LABEL core
INFOURL https://core.mynet.net/admin/
NODE customer1
LABEL xy.com
POSITION 150 370
NODE customer2
LABEL ww.co.uk
POSITION 250 450
NODE infra
LABEL INFRASTRUCTURE
POSITION 450 450
# this node has an icon, and so we push the label to the South
edge of it, so it # can still be read
NODE sync
LABEL Sync
ICON my_router.png
LABELOFFSET S
LABELFONT 2
POSITION 550 370
# the icon is taken from a Nagios icon pack:
#http://www.nagiosexchange.org/Image_Packs.75.0.html&tx_netnag
ext_pi1[p_view]=110&tx_netnagext_pi1[page]=10%3A10
NODE site1
LABEL site1
POSITION 700 220
Pagina 169 di 190
NODE site2
LABEL site2
POSITION 750 420
LINK sync-core
NODES sync-core
TARGET data/sync_traffic_in_259.rrd
OVERLIBGRAPH
http://support.mynet.net/cacti/graph_image.php?
00&graph_wid th=300
INFOURL
http://support.mynet.net/cacti/graph.php?
rra_id=all&local_graph_id=256
## Site1 has two E1s, so we use NODE-offsets to allow them to
run parallel
LINK sync-site1a
NODES sync:N site1:W
WIDTH 3
BANDWIDTH 2M
OVERLIBGRAPH
00&graph_wid th=
INFOURL rra_id=all&local_graph_id=126
LINK sync-site1b NODES sync:E site1:SE
WIDTH 3
OVERLIBGRAPH
Pagina 170 di 190
00&graph_wid th=
BANDWIDTH 2M
INFOURL
# site2 also has two links, but this time we use the VIA to
curve the links #
LINK sync-site2a
NODES sync site2
WIDTH 3
VIA 650 380
OVERLIBGRAPH
00&graph_wid th=300
BANDWIDTH 1M
INFOURL rra_id=all&local_graph_id=252
LINK sync-site2b
NODES sync site2
WIDTH 3
VIA 650 420
OVERLIBGRAPH
00&graph_wid th=300
Pagina 171 di 190
BANDWIDTH 1M
INFOURL
# ISP 1 has a several links, again, but they prefer to see one
arrow, and the aggregate #bandwidth
#so we use multiple TARGETs on one line, here, to sum the
data
LINK transit-isp1
NODES transit isp1
TARGET
data/trans1_traffic_in_352.rrd
BANDWIDTH 10M
OVERLIBGRAPH
00&graph_wid
th=INFOURL
LINK transit-isp2 NODES transit isp2
TARGET
BANDWIDTH
34M
OVERLIBGRAPH
00&graph_wid
th=300 rra_id=all&local_graph_id=265 LINK core-transit
INFOURL
NODES transit-core
Pagina 172 di 190
TARGET data/trans1_traffic_in_350.rrd
ARROWSTYLE compact
WIDTH 4
OVERLIBGRAPH
00&graph_wid th=300
INFOURL
LINK cust1-core
NODES customer1 core
TARGET data/extreme_traffic_in_299.rrd
OVERLIBGRAPH
00&graph_wid th=300
INFOURL
LINK cust2-core
NODES customer2 core
OVERLIBGRAPH
00&graph_wid th=300
INFOURL
LINK infra-core
Pagina 173 di 190
NODES infra core
OVERLIBGRAPH
00&graph_wid th=300
INFOURL
Di seguito riportiamo la mappa realizzata attraverso il file di configurazione appena
descritto, figura 9.5.
Figura 9.5 – Mappa realizzata con Weathermap
Pagina 174 di 190
9.2
Warning ed errori di Weathermap
Segue un elenco di tutti gli attuali codici di errore di Weathermap, con le
corrispondenti spiegazioni.
[WMW ARN01]
"Skipping drawing very short link (linkname). Impossible to draw! Try changing
WIDTH or ARROWSTYLE? "
Weathermap disegna le punte delle frecce per i link, in proporzione allo spessore della
linea dle link: più la linea del link è grossa, più è rande la punta della freccia. Può
capitare che due nodi siano molto vicini, nel qual caso non c’è abbastanza spazio per
disegnare la linea del link ed anche la corrispondente punta della freccia.
Se si riceve questo errore, si può tentare di ridurre lo spessore della linea del link, cosa
che fa ridurre in proporzione la dimensione della punta della feeccia. Si può anche
usare usare la direttiva ARROWSTYLE per scegliere una freccia dalla punta più
piccola - ARROWSTYLE 1 1 è il valore minimo.
Si può anche provare a spostare leggermente uno dei nodi, in moco che la freccia
possa entrare nello spazio tra i due nodi.
[WMWARN02], [WMWARN04]
"Angled text doesn't work with non-FreeType fonts "
The standard fonts used by Weathermap are the ones bundled with the GD graphics
library. These fonts (number 1-5 when you select fonts) can only be drawn 'flat', and
not at an angle.
Se state usando i commenti ai link, o il comando BWSTYLE per produrre scritte
angolate, Weathermap deve essere in grado di scrivere testi a vari angoli. Per fare
questo, c’è bisogno di font del tipo Truetype, che vengono scritte usando la libreria
FreeType.
Dovete quindi trovare una fonte Truetype, metterla nella directory di Weathermap, e
poi definire una nuova fonte nel file di configurazione, ad esempio con il comando:
FONTDEFINE 100 Vera 9.
Pagina 175 di 190
Solo allora potete usare la nuova fonte (n. 100) nei comandi COMMENTFONT o
BWFONT.
La cartella docs/example contiene degli esempi di quanto sopra detto.
La ragione per cui la fonte di default non è di tipo TrueType è nel fatto che la libreria
FreeType è una parte opzionale della libreria GD library, e potrebbe non essere stata
installata.
[WMW ARN03]
"Using a non-existent special font (fontnumber) - falling back to internal GD fonts "
14Se si usa un numero per la fonte dei caratteri che non esiste di default (cioé da 1 a
5), e non vi è una valida direttiva FONTDEFINE, allora si riceve questo errore.
Weathermap userà la fonte 5, invece di quella richiesta.
La causa più frequente di questi errori è che il file della fnte non è stato trovato, è non
è sato possibile caricarlo. È utile quindi verificare il file di log, per vedere altri errori
simili (come WMWARN30 o WMWARN31).
[WMW ARN05]
"ProcessString: key refers to unknown item "
Avete
usato
una
stringa
del
tipo
'Special
Token',
come
ad
esempio
{node:this:something}, ma il 'something' che avete usato non è definito per il nodo o
per il link specificato. Ciò è spesso dovuto ad un errore di battitura, semplicemente.
[WMW ARN06]
"Couldn't open plugin-type Plugin directory (dir). Things will probably go wrong. "
Alcune parti di Weathermap sono caricate dai plugin. Se le directory dei plugin non
esistono, o non sono accessibili per problemi di protezione, allora i plugin non possono
essere caricati. Un esempio si ha con le operazioni di lettura dei dati, che sono tutte
fatte con i plugin.
Dovete quindi verificare che le directory lib/datasources, lib/pre e lib/post esistano
tutte nella directory Weathermap, e che esse siano tutte accessibili (sia in lettura sia per
l’esecuzione) all’utente e/o al poller di Cacti.
[WMW ARN07]
Pagina 176 di 190
"ReadData: type name, target: targetstring on config line linenumber was recognised
as a
valid TARGET by a plugin that is unable to run (pluginname) "
Quando i plugin che leggono i dati sono caricati, ciascuno di essi verifica se può
accedere ai dati di propria pertinenza. Se qualcosa non va in questo senso, il plugin
può rifiutare il caricamento. Il messaggio appare se vi è un comando TARGET che
punta ad un plugin particolare, e questo rifiuta di caricarsi perchè non può accedere ai
dati.
[WMW ARN08]
"ReadData: type name, target: targetstring[4] on config line linenumber was not
recognised as a valid TARGET "
Avete specificato un TARGET che nessuno dei plugin di datasource ha riconosciuto.
Ciò è molto spesso dovuto a semplici errori di formaizone.
[WMW ARN09]
"ColourFromPercent: Attempted to use non-existent scale: scalename for itemname "
Avete aggiunto una riga USESCALE ad un NODE o ad un LINK, ma il nome della
scala non è stato definito usando prima una riga SCALE. Definite quindi prima una
riga SCALE, oppure verificate che il problema non sia dovuto ad errori di battitura.
[WMW ARN10]
"NODE nodename has a relative position to an unknown node! "
Avete usato la POSITION relativa per un NODE, ma con un riferimento ad un nodo
che non esiste. Si tratta probabilmente di un errore di battitura.
[WMWARN11]
"There are Circular dependencies in relative POSITION lines for number nodes. "
Avete usato la POSITION per i nodi, ma in modo ciclico, cioè relativo ad un nodo che
a sua volta è relativo ad un altro che è relativo al primo. Bisogna che almeno un nodo
abbia una posizione assoluta, altrimenti non potrà essere disegnato alcun nodo.
[WMW ARN12]
"Failed to write map image. No function existed for the image format you requested. "
Pagina 177 di 190
Avete specificato un particolare formato per scrivere l’immagine con il comando
IMAGEFILE, ma l’installazione di php/GD non supporta il tipo di immagine
specificato.
Dovete quindi scegliere un formato differente, o ricompilare/reinstallare le librerie
php, php- gd e GD per supportare questo tipo di immagine.
[WMW ARN13],[WMW ARN15],[WMW ARN16]
"Failed to overwrite existing image file filename - permissions of existing file are
wrong? "
I file nella cartella di output sono di un proprietario differente da quello con cui sta
girando Weathermap, che non può quindi sovrascriverli.
Questo può avvenire se usate il comando "Recalculate Now", che crea I file con
l’utente del webserver; se il poller cerca poi di riscriverli, non ci riesce. È quindi
necessario che la cartella abbia come owner il poller ('cactiuser'); è comunque bene
non usare il comando 'Recalculate Now'.
[WMW ARN14]
"Failed to create image file filename - permissions of output directory are wrong? "
Weathermap non è stato capace di creare file nella directory dove devono andare I file
di output, cioè plugins/weathermap/output/, quindi bisogna fare in modo che il poller
possa scrivere nella cartella, come per la cartella /rra di Cacti.
[WMW ARN17]
"Skipping thumbnail creation, since we don't have the necessary function. "
La vs libreria php/php-gd/GD non include la funzione imagecopyresampled(), che è
necessaria per creare i thumbnail usati nei plugin di Cacti. Per avere questa funzione,
dovete aggiornare/ricompilare/reinstallare le librerie php, php-gd e GD.
[WMW ARN20]
"No image (gd) extension is loaded. This is required by weathermap. "
Tutta la grafica di Weathermap è realizzata usando le estensioni gd PHP extension. Se
ricevete questo errore, la vostra installazione di php non ha questa estensione, oppure
essa non è abilitata. Bisogna quindi installare l’estensione, o abilitarla.
Pagina 178 di 190
[WMW ARN21]
"Your GD php module doesn't support PNG format. "
Avete specificato una immagine ICON o BACKGROUND in formato PNG, e la vostra
installazione di php-gd non supporta il formato PNG.
Dovete
quindi
o
cambiare
il
formato
dell’immagine
grafica,
oppure
ricompilare/reinstallare php, php-gd e le librerie GD in modo che supportino questo
formato.
[WMW ARN22]
"Your GD php module doesn't support truecolor. "
Weathermap richiede che sia la GD library, sia la estensione php-gd supportino colori a
24- bit (cioè "TrueColor"). Di conseguenza, dovete aggiornare, o ricompilare, o
reinstallare php, php-gd e le librerie GD. Infatti quasi sempre l’errore nasce da una
vecchia versione di GD.
[WMW ARN23]
"Your GD php module doesn't support thumbnail creation (imagecopyresampled). "
Vedere quanto scritto per WMWARN17.
[WMW ARN24]
"Duplicate node name nodename at line linenumber - only the last one defined is
used."
Avete usato lo stesso nome per due o più comandi NODE nel file di configurazione:
Ciò può essere dovuto ad errori tipografici, o ad operazioni inesatte di copia & incolla.
L’effetto è che uno dei due NODE non apparirà sulla mappa.
[WMW ARN25]
"Duplicate link name linkname at line linenumber - only the last one defined is used. "
Avete usato lo stesso nome per due o più linee LINK nel vostro file di configurazione.
Ciò è probabilmente dovuto ad errori di battitura o di taglia & copia. Solo una delle
due linee verrà rappresentata sulla mappa.
[WMW ARN26]
"LINK DEFAULT is not the first LINK. Defaults will not apply to earlier LINKs. "
Pagina 179 di 190
Dovete specificare il vostro DEFAULT LINK prima di tutti i vostri veri LINK. Questo
perché un link vero deve copiare prima le caratteristiche di default.
[WMW ARN27]
"NODE DEFAULT is not the first NODE. Defaults will not apply to earlier NODEs. "
Dovete specificare il vostro DEFAULT NODE prima di tutti i vostri veri NODE.
Questo perché un nodo vero deve copiare prima le caratteristiche di default.
[WMW ARN28]
"Dropping LINK linkname - it hasn't got 2 NODES! "
Avete definito un link laddove uno o entrambi i nodi non esistono, per esempio perché
avete dimenticato una riga NODES.
Un link deve necessariamente congiungere due nodi.
[WMW ARN30]
"Failed to load ttf font filename - at config line linenumber" Avete definito una fonte
TrueType/FreeType con il comando FONTDEFINE, ma il file
corrispondente non esiste o non può essere letto per problemi con i permessi.
[WMW ARN31]
"imagettfbbox() is not a defined function. You don't seem to have FreeType compiled
into your gd module. "
Avete provato ad usare una fonte TrueType/FreeType, ma la vostra libreria GD (e/o
l’estensione php-gd) non comprende le fonti FreeType.
Dovete o scegliere una nuova fonte, oppure ricompilare/reinstallare le librerie php,
php-gd, GD e forse freetype2 per supportare il formato specificato.
[WMW ARN32]
"Failed to load GD font: filename (errorcode) at config line linenumber "
Avete definito una fonte .gdf con il comando FONTDEFINE, ma il file non esiste o
non può essere caricatio per problemi con i permessi.
[WMW ARN99]
"something not implemented yet"
Avete provato ad usare delle funzionalità implementate solo parzialmente e qundi non
Pagina 180 di 190
utilizzabili.
[WMIMG01]
"Image file filename is GIF, but GIF is not supported by your GD library. "
[WMIMG02]
"Image file filename is JPEG, but JPEG is not supported by your GD library. "
[WMIMG03]
"Image file filename is PNG, but PNG is not supported by your GD library. "
[WMIMG04]
"Image file filename wasn't recognised (type=type). Check format is supported by your
GD library. "
[WMIMG05]
"Image file filename is unreadable. Check permissions. "
[WMRRD01]
"RRD DS: RRDTool exists but is not executable? "
Per qualche motivo avete il path giusto per rrdtool, ma lo stesso non è eseguibile dal
poller: verificate i permessi dei binari di rrdtool.
[WMRRD02]
"RRD DS: Can't find RRDTOOL. Check line 29 of the 'weathermap' script. RRDbased TARGETs will fail. "
State usando la versione command-line di weathermap, ma il path alla riga 29 (in
questo esempio) del file di script non corrisponde al path esatto dei binari di rrdtool.
Editare il file ed immettere il path giusto, altrimenti webinary. Editare il file ed
immettere il path giusto, altrimenti Weathermap non potrà leggere i file .rrd.
[WMRRD03]
"RRD DS: Can't find RRDTOOL. Check your Cacti config. "
L’installazione di Weathermap è integrata in Cacti, ma i settings di Cacti includono un
path errato a rrdtool. Probabilmente si tratta di una errata configurazione, provate a
modificare il path in Console..Settings..Paths (in Cacti) per far puntare alla posizione
giusta.
Pagina 181 di 190
[WMRRD04]
"RRD ReadData: failed to open pipe to RRDTool: phperrormsg "
Si tratta probabilmente di un bug di Weathermap, che non è stato in grado di leggere,
tramite rrdtool, un file .rrd che tuttavia esiste. Ma potrebbe anche essere che l’utente (o
il poller) non ha i privilegi di accesso al file, o non ha i privilegi per eseguire rrdtool.
[WMRRD06]
"Target rrdfile doesn't exist. Is it a file? "
É stato dato al comando TARGET un RRD che non è un file ma una directory, o
qualcosa di simile.
9.3
Il protocollo SNMP
Il Simple Network Management Protocol è un protocollo che opera a livello
applicazioni (livello sette del modello OSI), per l'amministrazione delle reti basate
sulla suite di protocolli TCP/IP.
Il Simple Network Management Protocol usa come protocollo di trasporto il
protocollo UDP, User Datagram Protocol, che a differenza del protocollo TCP,
Trasmission Control Protocol, è un protocollo connectionless, ossia un protocollo non
orientato alla connessione, e che fornisce solo i servizi basilari del livello di trasporto.
Uno dei vantaggi nell'usare il protocollo UDP rispetto al protocollo TCP, è che il
traffico di rete sviluppato da quest'ultimo è minimo.
Uno dei svantaggi nell'usare il protocollo UDP rispetto al protocollo TCP, è che non
viene gestito il riordinamento dei pacchetti ne la ritrasmissione di quelli persi, ed è per
questo motivo considerato il protocollo di minore affidabilità.
Per le sue caratteristiche, il protocollo UDP attualmente è uno dei protocolli più diffusi
per la gestione ed il monitoraggio della rete dei calcolatori, e per tale motivo gran parte
degli apparati hardware e apparecchiature di rete lo supportano.
Nel corso degli anni il protocollo SNMP ha avuto delle evoluzioni, sviluppando
diverse versioni del protocollo:
Pagina 182 di 190
•
SNMP v.1
◦ Utilizza un sistema di autenticazione Community,
◦ Indipendenza dalle piattaforme utilizzate,
◦ Facilità d'uso, Trasportabilità, Estensibilità,
◦ Bassa Affidabilità dovuta all'utilizzo del protocollo UDP.
•
SNMP v.2
◦ Crittografia tramite DES a 64 bit e integrità tramite MD5
•
SNMP v.2c
◦ Messaggi d'errore dettagliati,
◦ Connessione TCP.
•
SNMP v.3
◦ Nuova Architettura
◦ Formato dei Messaggi
◦ Poco Utilizzato
Il sistema di autenticazione del SNMPv1 non è in grado di garantire la completa
sicurezza dell’accesso agli agenti, in quanto il trasporto in chiaro dell’identificativo
della comunità consente, in modo relativamente facile, l’intercettazione della stringa di
community e quindi l’intrusione di Manager non autorizzati: a questo inconveniente si
è cercato di porre rimedio attraverso la definizione di meccanismi più severi per
l’autenticazione e con l’introduzione di meccanismi di crittografia, definiti dapprima
nel S-SNMP (Secure-SNMP) e poi nell’SNMPv2.
Limitazione SNMPv1 e v2: community name in chiaro.
SNMPv3 ha i seguenti vantaggi: controllo dell’integrità dei pacchetti, autenticazione
forte, ovvero trasmissione dei dati via un canale sicuro(crittografato), pacchetti criptati.
Tipicamente L'SNMP utilizza la porta UDP 161 per le interrogazioni e le risposte, e la
porta UDP 162 come destinazione dei messaggi trap SNMP generate dagli agent
Pagina 183 di 190
SNMP.
Architettura :
L'Internet Network Management Framework è l'architettura di cui fa parte il
protocollo SNMP.
I tre componenti fondamentali del framework SNMP sono:
1. Sistema gestito (managed object)
2. Agente di gestione (management agent)
3. Sistema di gestione (manager)
All'interno di ogni sistema gestito (ad esempio un router, una stampante o qualsiasi
altro dispositivo che fornisca un'interfaccia di gestione SNMP) è contenuto un agente
di gestione (master agent) e frequentemente un dato numero di subagent.
Il master agent ha il ruolo di mediatore fra il manager (che è l'applicazione remota che
prende le decisioni di gestione, per esempio sotto il controllo diretto dell'operatore
umano) e i subagent (che sono gli esecutori di tali decisioni).
Tutti i subagent hanno come incarico quello di effettuare le decisioni di gestione nel
contesto di un particolare sottosistema o in rapporto a un particolare aspetto del
sistema gestito.
Quei sistemi che producono meccanismi di gestione particolarmente semplici, master
agent e subagent possono convergere in un unico componente software in grado sia di
comunicare con il manager, che di mettere in atto le decisioni; in questo caso si parlerà
semplicemente di agent.
Nell'architettura SNMP, per ogni sottosistema è definita una base dati detta MIB
(Management Information Base), gestita dal corrispondente subagent, la quale
rappresenta lo stato del sottosistema gestito, o meglio, una proiezione di tale stato
limitata agli aspetti di cui si vuole consentire la gestione. Si tratta di una base dati che
si potrebbe definire, mutuando un termine dalla riflessione, "causalmente connessa": in
altre parole, ogni modifica alla MIB causa un corrispondente mutamento nello stato
Pagina 184 di 190
del sottosistema rappresentato, e viceversa. Garantire questa proprietà della MIB è la
funzione principale del subagent che la gestisce.
L'accesso alla MIB (in lettura e scrittura) rappresenta l'interfaccia fornita al manager
per gestire il sistema. Ogni MIB, pur variando nei contenuti specifici, ha la medesima
struttura generale e i medesimi meccanismi generali di accesso da parte del manager
(lettura e scrittura dei dati). Grazie alla connessione causale della MIB, è quindi
possibile al manager agire sullo stato del sottosistema in un modo che è largamente
indipendente dalle procedure concrete che devono essere messe in atto (dal subagent)
per estrarre le informazioni di stato rappresentate nella MIB, o attuare le modifiche di
stato a seguito di cambiamenti dei contenuti della MIB. Così, per esempio, si potrebbe
avere un dato di MIB che rappresenta l'indirizzo IP del sistema gestito; per modificare
tale indirizzo, al manager è sufficiente accedere alla MIB sovrascrivendo il dato
corrispondente, prescindendo dei dettagli di come una tale modifica venga poi
concretamente "attuata" sul sistema gestito.
Più in dettaglio, il manager dialoga con i sistemi gestiti essenzialmente in due modi:
invia richieste SNMP e riceve notifiche SNMP.
9.4
Codice dei Grafici Implementati con RRDTool
Statistiche degli errori e dei pacchetti persi o danneggiati, tra il router-atlas e il
GigaPOP GARR:
/usr/bin/rrdtool graph - \
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='router-atlas - Errors/Discarded Packets - Router
GARR' \
--rigid \
--base=1000 \
--height=120 \
Pagina 185 di 190
--width=600 \
--alt-autoscale-max \
--lower-limit=0 \
--vertical-label='errors/sec' \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/var/www/cacti/rra/routeratlas_errors_in_59.rrd":discards_in:AVERAGE \
DEF:b="/var/www/cacti/rra/routeratlas_errors_in_59.rrd":errors_in:AVERAGE \
DEF:c="/var/www/cacti/rra/routeratlas_errors_in_59.rrd":discards_out:AVERAGE \
DEF:d="/var/www/cacti/rra/routeratlas_errors_in_59.rrd":errors_out:AVERAGE \
LINE1:a#FFAB00FF:"Discards In" \
GPRINT:a:LAST:" Current\:%8.2lf %s" \
GPRINT:a:AVERAGE:"Average\:%8.2lf %s" \
GPRINT:a:MAX:"Maximum\:%8.2lf %s\n" \
LINE1:b#F51D30FF:"Errors In" \
GPRINT:b:LAST:"
Current\:%8.2lf %s" \
GPRINT:b:AVERAGE:"Average\:%8.2lf %s" \
GPRINT:b:MAX:"Maximum\:%8.2lf %s\n" \
LINE1:c#C4FD3DFF:"Discards Out" \
GPRINT:c:LAST:"Current\:%8.2lf %s" \
GPRINT:c:AVERAGE:"Average\:%8.2lf %s" \
GPRINT:c:MAX:"Maximum\:%8.2lf %s\n" \
LINE1:d#00694AFF:"Errors Out" \
GPRINT:d:LAST:" Current\:%8.2lf %s" \
GPRINT:d:AVERAGE:"Average\:%8.2lf %s" \
GPRINT:d:MAX:"Maximum\:%8.2lf %s\n"
Statistiche degli errori o dei pacchetti persi o danneggiati, tra il router-atlas e lo switch
sw3com-atlas02:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='router-atlas - Errors/Discarded Packets - LACP
sw3com-atlas02' \
--rigid \
Pagina 186 di 190
--base=1000 \
--height=120 \
--width=600 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/var/www/cacti/rra/routeratlas_errors_in_58.rrd":discards_in:AVERAGE \
DEF:b="/var/www/cacti/rra/routeratlas_errors_in_58.rrd":errors_in:AVERAGE \
DEF:c="/var/www/cacti/rra/routeratlas_errors_in_58.rrd":discards_out:AVERAGE \
DEF:d="/var/www/cacti/rra/routeratlas_errors_in_58.rrd":errors_out:AVERAGE \
GPRINT:b:LAST:"
Statistiche degli errori e dei pacchetti persi o danneggiati, tra il cat6509 e mercurio:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='cat6509 - Errors/Discarded Packets - Mercurio' \
--rigid \
--base=1000 \
--height=120 \
Pagina 187 di 190
--width=600 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/var/www/cacti/rra/cat6509_errors_in_79.rrd":discards_i
n:AVERAGE \
DEF:b="/var/www/cacti/rra/cat6509_errors_in_79.rrd":errors_in:
AVERAGE \
DEF:c="/var/www/cacti/rra/cat6509_errors_in_79.rrd":discards_o
ut:AVERAGE \
DEF:d="/var/www/cacti/rra/cat6509_errors_in_79.rrd":errors_out
:AVERAGE \
GPRINT:b:LAST:"
Statistiche degli errori e dei pacchetti persi o danneggiati, tra il cat6509 e lo switch
sw3com-atlas02:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='cat6509 - Errors/Discarded Packets - sw3comatlas02' \
--rigid \
--base=1000 \
Pagina 188 di 190
--height=120 \
--width=600 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/var/www/cacti/rra/cat6509_errors_in_80.rrd":discards_i
n:AVERAGE \
DEF:b="/var/www/cacti/rra/cat6509_errors_in_80.rrd":errors_in:
AVERAGE \
DEF:c="/var/www/cacti/rra/cat6509_errors_in_80.rrd":discards_o
ut:AVERAGE \
DEF:d="/var/www/cacti/rra/cat6509_errors_in_80.rrd":errors_out
:AVERAGE \
GPRINT:b:LAST:"
Statistiche degli errori e dei pacchetti persi o danneggiati, tra mercurio e il router-atlas:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='mercurio - Errors/Discarded Packets - Router ATLAS' \
--rigid \
--base=1000 \
--height=120 \
--width=550 \
Pagina 189 di 190
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/var/www/cacti/rra/mercurio_errors_in_62.rrd":discards_
in:AVERAGE \
DEF:b="/var/www/cacti/rra/mercurio_errors_in_62.rrd":errors_in
:AVERAGE \
DEF:c="/var/www/cacti/rra/mercurio_errors_in_62.rrd":discards_
out:AVERAGE \
DEF:d="/var/www/cacti/rra/mercurio_errors_in_62.rrd":errors_ou
t:AVERAGE \
GPRINT:b:LAST:"
Statistiche degli errori e dei pacchetti persi o danneggiati, tra mercurio e il POP
GARR:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='mercurio - Errors/Discarded Packets - Router GARR' \
--rigid \
--base=1000 \
--height=120 \
--width=550 \
Pagina 190 di 190
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/var/www/cacti/rra/mercurio_errors_in_61.rrd":discards_
in:AVERAGE \
DEF:b="/var/www/cacti/rra/mercurio_errors_in_61.rrd":errors_in
:AVERAGE \
DEF:c="/var/www/cacti/rra/mercurio_errors_in_61.rrd":discards_
out:AVERAGE \
DEF:d="/var/www/cacti/rra/mercurio_errors_in_61.rrd":errors_ou
t:AVERAGE \
GPRINT:b:LAST:"
Statistiche degli errori e dei pacchetti persi o danneggiati, tra lo switch sw3comatlas02 e lo switch sw3com-atlas01:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='sw3com-atlas02 - Errors/Discarded Packets - sw3comatlas01' \
--rigid \
--base=1000 \
--height=120 \
--width=600 \
Pagina 191 di 190
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/var/www/cacti/rra/sw3comatlas02_errors_in_65.rrd":discards_in:AVERAGE \
DEF:b="/var/www/cacti/rra/sw3comatlas02_errors_in_65.rrd":errors_in:AVERAGE \
DEF:c="/var/www/cacti/rra/sw3comatlas02_errors_in_65.rrd":discards_out:AVERAGE \
DEF:d="/var/www/cacti/rra/sw3comatlas02_errors_in_65.rrd":errors_out:AVERAGE \
GPRINT:b:LAST:"
Statistiche degli errori e dei pacchetti persi o danneggiati, tra lo switch sw3comatlas02 e lo switch sw3com-atlas03:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='sw3com-atlas02 - Errors/Discarded Packets - sw3comatlas03' \
--rigid \
--base=1000 \
--height=120 \
--width=600 \
Pagina 192 di 190
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
GPRINT:b:LAST:"
Statistiche degli errori e dei pacchetti persi o danneggiati, tra lo switch sw3comatlas02 e lo switch swdell-atlas01:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='sw3com-atlas02 - Errors/Discarded Packets - swdellatlas01' \
--rigid \
--base=1000 \
Pagina 193 di 190
--height=120 \
--width=600 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
GPRINT:b:LAST:"
Statistiche degli errori e dei pacchetti persi o danneggiati, tra lo switch sw3comatlas02 e lo switch swdell-scope01:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='sw3com-atlas02 - Errors/Discarded Packets - swdellscope01' \
--rigid \
Pagina 194 di 190
--base=1000 \
--height=120 \
--width=600 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
GPRINT:b:LAST:"
Statistiche degli errori e dei pacchetti persi o danneggiati, tra lo switch sw3comatlas04 e lo switch swdell-atlas01:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='sw3com-atlas04 - Errors/Discarded Packets - swdellatlas01' \
Pagina 195 di 190
--rigid \
--base=1000 \
--height=120 \
--width=550 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
GPRINT:b:LAST:"
Traffico dei dati di ingresso e di uscita tra il cat6509 e lo switch sw3com-atlas02:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='cat6509 - Traffic - Gi1/2 - sw3com-atlas02' \
Pagina 196 di 190
--rigid \
--base=1000 \
--height=120 \
--width=600 \
--lower-limit=0 \
--vertical-label='bits per second' \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/var/www/cacti/rra/cat6509_traffic_in_78.rrd":traffic_i
n:AVERAGE \
DEF:b="/var/www/cacti/rra/cat6509_traffic_in_78.rrd":traffic_o
ut:AVERAGE \
CDEF:cdefa=a,8,* \
CDEF:cdeff=b,8,* \
AREA:cdefa#00CF00FF:"Inbound" \
GPRINT:cdefa:LAST:" Current\:%8.2lf %s" \
GPRINT:cdefa:AVERAGE:"Average\:%8.2lf %s" \
GPRINT:cdefa:MAX:"Maximum\:%8.2lf %s\n" \
COMMENT:"Total In\: 1.05 GB\n" \
LINE1:cdeff#002A97FF:"Outbound" \
GPRINT:cdeff:LAST:"Current\:%8.2lf %s" \
GPRINT:cdeff:AVERAGE:"Average\:%8.2lf %s" \
GPRINT:cdeff:MAX:"Maximum\:%8.2lf %s\n" \
COMMENT:"Total Out\: 3.14 GB\n"
Traffico dei dati di ingresso e di uscita tra il cat6509 e mercurio:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='cat6509 - Traffic - Gi2/16 - mercurio' \
--rigid \
--base=1000 \
--height=120 \
--width=600 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
Pagina 197 di 190
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/var/www/cacti/rra/cat6509_traffic_in_77.rrd":traffic_i
n:AVERAGE \
DEF:b="/var/www/cacti/rra/cat6509_traffic_in_77.rrd":traffic_o
ut:AVERAGE \
CDEF:cdefa=a,8,* \
CDEF:cdeff=b,8,* \
Traffico dei dati di ingresso e di uscita tra il router-atlas e il POP GARR:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='router-atlas - Traffic - Gi1/0/3 - Router GARR' \
--rigid \
--base=1000 \
--height=120 \
--width=500 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/var/www/cacti/rra/routeratlas_traffic_in_40.rrd":traffic_in:AVERAGE \
DEF:b="/var/www/cacti/rra/routeratlas_traffic_in_40.rrd":traffic_out:AVERAGE \
CDEF:cdefa=a,8,* \
CDEF:cdeff=b,8,* \
Pagina 198 di 190
COMMENT:"Total In\: 4.42 TB\n" \
Traffico dei dati di ingresso e di uscita tra il router-atlas e lo switch sw3com-atlas02:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='router-atlas - Traffic - LACP - sw3com-atlas02' \
--rigid \
--base=1000 \
--height=120 \
--width=500 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/var/www/cacti/rra/routeratlas_traffic_in_41.rrd":traffic_in:AVERAGE \
DEF:b="/var/www/cacti/rra/routeratlas_traffic_in_41.rrd":traffic_out:AVERAGE \
CDEF:cdefa=a,8,* \
CDEF:cdeff=b,8,* \
Pagina 199 di 190
COMMENT:"Total Out\: 8.63 TB\n"
Traffico dei dati di ingresso e di uscita tra mercurio e il POP GARR:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='mercurio - Traffic - Gi1/0/2 - Router GARR' \
--rigid \
--base=1000 \
--height=120 \
--width=500 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/var/www/cacti/rra/mercurio_traffic_in_38.rrd":traffic_
in:AVERAGE \
DEF:b="/var/www/cacti/rra/mercurio_traffic_in_38.rrd":traffic_
out:AVERAGE \
CDEF:cdefa=a,8,* \
CDEF:cdeff=b,8,* \
Traffico dei dati di ingresso e di uscita tra mercurio e il router-atlas:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='mercurio - Traffic - Gi1/0/8 - Router ATLAS' \
Pagina 200 di 190
--rigid \
--base=1000 \
--height=120 \
--width=500 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/var/www/cacti/rra/mercurio_traffic_in_39.rrd":traffic_
in:AVERAGE \
DEF:b="/var/www/cacti/rra/mercurio_traffic_in_39.rrd":traffic_
out:AVERAGE \
CDEF:cdefa=a,8,* \
CDEF:cdeff=b,8,* \
COMMENT:"Total In\: 897.97 MB\n" \
Traffico dei dati di ingresso e di uscita tra lo switch sw3com-atlas02 e lo switch
swdell-scope01:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='sw3com-atlas02 - Traffic - 1 Gbps Eth - swDELLscope01' \
--rigid \
--base=1000 \
--height=120 \
--width=600 \
--lower-limit=0 \
Pagina 201 di 190
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/var/www/cacti/rra/sw3comatlas02_traffic_in_34.rrd":traffic_in:AVERAGE \
DEF:b="/var/www/cacti/rra/sw3comatlas02_traffic_in_34.rrd":traffic_out:AVERAGE \
CDEF:cdefa=a,8,* \
CDEF:cdeff=b,8,* \
COMMENT:"Total In\: 22.91 MB\n" \
COMMENT:"Total Out\: 500.23 MB\n"
sw3com-atlas01:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='sw3com-atlas02 - Traffic - 10 Gbps CX4 - sw3comatlas01' \
--rigid \
--base=1000 \
--height=120 \
--width=600 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
Pagina 202 di 190
CDEF:cdefa=a,8,* \
CDEF:cdeff=b,8,* \
sw3com-atlas03:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='sw3com-atlas02 - Traffic - 10 Gbps CX4- sw3comatlas03' \
--rigid \
--base=1000 \
--height=120 \
--width=600 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
CDEF:cdefa=a,8,* \
CDEF:cdeff=b,8,* \
Pagina 203 di 190
swdell-atlas01:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='sw3com-atlas02 - Traffic - 10 Gbps Fiber - swDELLatlas01' \
--rigid \
--base=1000 \
--height=120 \
--width=600 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
CDEF:cdefa=a,8,* \
CDEF:cdeff=b,8,* \
Pagina 204 di 190
swdell-atlas01:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='sw3com-atlas04 - Traffic - 10 Gbps Fiber - swdellatlas01' \
--rigid \
--base=1000 \
--height=120 \
--width=550 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
CDEF:cdefa=a,8,* \
CDEF:cdefe=b,8,* \
LINE1:cdefe#002A97FF:"Outbound" \
GPRINT:cdefe:LAST:"Current\:%8.2lf %s" \
GPRINT:cdefe:AVERAGE:"Average\:%8.2lf %s" \
GPRINT:cdefe:MAX:"Maximum\:%8.2lf %s\n"
Ping Latency cat6509:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='cat6509 - Ping Latency' \
--base=1000 \
Pagina 205 di 190
--height=120 \
--width=600 \
--lower-limit=0 \
--vertical-label='milliseconds' \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/var/www/cacti/rra/cat6509_ping_75.rrd":ping:AVERAGE \
AREA:a#FFF200FF:"" \
GPRINT:a:LAST:"Current\:%8.2lf %s" \
GPRINT:a:MAX:"Maximum\:%8.2lf %s\n"
Ping Latency mercurio:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='mercurio - Ping Latency' \
--base=1000 \
--height=120 \
--width=600 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/var/www/cacti/rra/mercurio_ping_72.rrd":ping:AVERAGE \
AREA:a#FFF200FF:"Round Trip Time" \
Ping Latency sw3com-atlas02:
--imgformat=PNG \
Pagina 206 di 190
--start=-86400 \
--end=-300 \
--title='sw3com-atlas02 - Ping Latency' \
--base=1000 \
--height=120 \
--width=600 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/var/www/cacti/rra/sw3comatlas02_ping_68.rrd":ping:AVERAGE \
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--base=1000 \
--height=120 \
--width=600 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
Pagina 207 di 190
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--base=1000 \
--height=120 \
--width=600 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
Ping Latency swdell-atlas01:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='swdell-atlas01 - Ping Latency' \
--base=1000 \
--height=120 \
--width=600 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
Pagina 208 di 190
DEF:a="/var/www/cacti/rra/swdellatlas01_ping_74.rrd":ping:AVERAGE \
GPRINT:a:AVERAGE:"Average\:%8.2lf %s"
\
Ping Latency router-atlas:
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title='router-atlas - Ping Latency' \
--base=1000 \
--height=120 \
--width=600 \
--lower-limit=0 \
--slope-mode \
--font TITLE:12: \
--font AXIS:8: \
--font LEGEND:10: \
--font UNIT:8: \
DEF:a="/var/www/cacti/rra/routeratlas_ping_71.rrd":ping:AVERAGE \
Pagina 209 di 190
Bibliografia
1. Le reti
di Peter Norton e David Kearns, Apogeo
2. Le reti di Calcolatori
di Larry L. Peterson e Bruce S. Davie, Apogeo
3. Reti di Calcolatori
di Andrew S. Tanenbaum,
4. Internet e reti di calcolatori
Pagina 210 di 190
di Douglas E. Comer, Addison-wesley
5. Ingegneria del software
di Ivan Sommerville, Pearson Addison Wesley
Sitografia
6. Ciclo di Deming
http://it.wikipedia.org/wiki/Ciclo_di_Deming
7. Cacti
http://www.cacti.net/
8. Weathermap
http://www.network-weathermap.com/
9. RRDTool
Pagina 211 di 190
http://oss.oetiker.ch/rrdtool/
10. MySQL
http://www.mysql.it/
11. Cisco
http://www.cisco.com/
12. SNMP
http://www.net-snmp.org/
13. PhpMyAdmin
http://www.phpmyadmin.net/
14. HTML
http://www.html.it/
15. Liferay
http://www.liferay.com/
16. Apache
http://www.apache.org/
17. La rete GARR
http://www.garr.it/
18. Il Tier2 di Napoli
http://www.infn.it/CCR/tier2/ATLAS_Napoli_v2.pdf
Pagina 212 di 190
19. 3com
http://www.3com.com/
20. Dell
http://www.dell.com/
21. Network Reliability
http://it.wikipedia.org/wiki/Network_reliability
22. Trade-Off
http://it.wikipedia.org/wiki/Trade-off
23. Network Reliability
http://www.neutraltandem.com/documents/NetworkReliability.pdf
Pagina 213 di 190

Un Sistema di Monitoraggio per una Rete ad Alte

Transcript

Documenti analoghi

Il mio giardino

STORIA DELLA MOKA L`invenzione della Moka Express risale al

Trachycarpus fortunei

east26_Pp_46-47_ItaWeb

ATLANTIS BAY Taormina ***** Sulla splendida baia di Taormina

"LA MUSICA NEL CUORE)" (August Rush)

Frescobaldi Castello di Nipozzano Riserva Chianti Rùfina

SALMO 84 - Hai favorito, Signore, la tua terra