Prof. Guido Russo - Scope - Università degli Studi di Napoli Federico II

Università degli Studi di Napoli Federico II
Facoltà di Scienze MM.FF.NN.
Corso di Laurea in Informatica
Tesi Sperimentale di Laurea Triennale
Sviluppo dell'interfaccia utente per la configurazione del
sistema PowerFarm
Relatori Candidato
Prof. Guido Russo Pietro Neroni
Dott.ssa Alessandra Doria (INFN) Matricola: 566/2833
Anno accademico 2008/2009

Ringraziamenti
Al termine di questo lavoro di tesi, che segna la conclusione del mio percorso di studi di
laurea triennale, mi sento in dovere di ringraziare alcune delle persone che hanno condiviso
con me tutti i momenti sia felici che difficili vissuti in questi tre anni.
Desidero ringraziare innanzitutto i miei due relatori, il prof. Guido Russo e la prof.ssa
Alessandra Doria per avermi dato la possibilità di realizzare questa tesi e per avermi offerto
tutto il supporto necessario per portare a termine questa esperienza accademica.
Vorrei ringraziare la mia famiglia, mia madre, mio padre e mia sorella, che hanno sempre
creduto nelle mie capacità, regalandomi un grande sostegno morale nonché economico che
mi ha spinto a raggiungere questo importante traguardo.
Ringrazio tutti gli amici del centro S.Co.P.E. per le piacevoli giornate passate insieme, per la
loro simpatia e per essersi dimostrate delle persone splendide, sempre pronte ad aiutarti.
Ringrazio i tanti compagni di università che vedo tuttora e che non ho più visto per diverse
strade intraprese.
Grazie a tutti!

Indice generale
1 INTRODUZIONE.............................................................................................................................1
2 INTRODUZIONE AL CALCOLO IN ATLAS ...............................................................................4
2.1 Il Sito Tier2-Napoli...................................................................................................................5
2.1.1 Servizi offerti dal Tier2......................................................................................................6
2.1.2 Collocazione apparati del Tier2 di Napoli.........................................................................9
3 POWERFARM ...............................................................................................................................14
3.1 Funzionamento Powerfarm.....................................................................................................14
3.2 Architettura Di Powerfarm.......................................................................................................15
3.3 Modulo Principale....................................................................................................................15
3.4 Modulo Per La Gestione Delle Emergenze ...........................................................................16
3.5 Modulo Di Notifica..................................................................................................................17
3.6 Modulo Di Log........................................................................................................................17
3.7 Riga Di Comando E Interfaccia Web.......................................................................................17
3.8 La Gestione Delle Dipendenze ...............................................................................................18
3.9 I Plugin.....................................................................................................................................19
3.9.1 Tecnologie e plugin utilizzati..........................................................................................20
4 I FILE DI CONFIGURAZIONE XML........................................................................................25
5 Gli STRUMENTI UTILIZZATI......................................................................................................30
5.1 JAVA........................................................................................................................................30
5.2 HTML......................................................................................................................................31
5.3 XML.........................................................................................................................................31
5.4 JSP...........................................................................................................................................31
5.5 Javascript.................................................................................................................................32
5.6 Graphviz E Webdot..................................................................................................................32
6 L'OBIETTIVO DELLA TESI: SITO WEBPOWERFARM............................................................35
6.1 Introduzione.............................................................................................................................35
6.2 Diagramma Dei Casi D'uso.....................................................................................................36
6.3 L'architettura ...........................................................................................................................37
6.4 Interfaccia Utente.....................................................................................................................39
6.5 Visualizzazione Del Grafo Delle Dipendenze.........................................................................47
6.6 Inserimento, Modifica, Eliminazione Di Un Dispositivo........................................................53
6.7 Diagrammi Di Cockburn.........................................................................................................60
6.8 Class Diagram..........................................................................................................................63
6.9 Sequence Diagram...................................................................................................................64
7 VALIDAZIONE E TESTING.........................................................................................................68
8 CONCLUSIONI E SVILUPPI FUTURI.........................................................................................72
9 BIBLIOGRAFIA.............................................................................................................................73
10 APPENDICE.................................................................................................................................74
10.1 L'esperimento ATLAS...........................................................................................................74
10.2 Il Codice ................................................................................................................................76

1 INTRODUZIONE
Questa tesi si inserisce nello sviluppo del sistema Powerfarm che permette di gestire
una o più farm, cioè insiemi di dispositivi che offrono particolari servizi alla Grid ed
hanno particolari caratteristiche hardware e software.
Il sistema Powerfarm è usato dagli amministatori delle farm per attivare e disattivare
i dispositivi, sia attraverso un'interfaccia WEB per le configurazioni e le operazioni
di manutenzione, sia automaticamene per la gestione delle emergenze
Dal punto di vista logico , ciascun dispositivo ha un proprio ruolo nella farm e svolge
compiti specifici, invece dal punto di vista fisico ogni dispositivo è collegato ad un
alimentatore e risiede all'interno del rack. Quindi ogni dispositivo ha una serie di
dipendenze logiche e fisiche da rispettare e pertanto prima di effettuare un operazione
di accensione o spegnimento bisogna creare una vera e propria catena delle
dipendenze tra tutti i dispositivi presenti nella farm. Per calcolarsi queste dipendenze
powerfarm usa un file di confgurazione xml dove ci sono sia le dipendenze fisiche e
logiche.
La prima parte del mio lavoro di tesi è stato quello di ottenere informazioni sulle
dipendenze logiche analizzando il file xml utilizzando il linguaggio Java, e
rappresentarle tramite un grafo aciclico orientato dove ogni nodo rappresenta un
dispositivo o un insieme di dispositivi, e gli archi rappresentano le dipendenze tra i
dispositivi.
Ciò consente di effettuare un immediato controllo visivo della configurazione del
sistema.
Questo grafo delle dipendenze sarà la home page dell'interfaccia web di Powerfarm e
viene creato dinamicamente ogniqualvolta si accede ed essa, tenendo conto quindi di
eventuali modifiche dei file di configurazione xml. Per visualizzare il grafo delle
dipendenze costruito è stato utilizzato uno script lato server ( Webdot) che presa una
descrizione testuale di un grafo ne fornisce la sua rappresentazione grafica. Ogni
nodo di questo grafo è di un colore diverso a seconda del tipo di dispositivo che
rappresenta, e si ha la possibilità di raggruppare dispositivi che hanno le stesse
dipendenze logiche in un unico nodo del grafo. Inoltre per avere maggiori dettagli su
un dispositivo o su un gruppo di dispositivi si può cliccare sul corrispondente nodo e
Pietro Neroni 566/2833 Pagina 4 di 117

si viene reindirizzati in una pagina che contiene delle informazioni sul dispositivo o
sull'insieme di dispositivi scelto quali tipo, indirizzo IP, dei link alle pagine di
monitoraggio, lo stato del dispositivo (online, offline), ed un link alla pagina di
configurazione del dispositivo.
Proprio la pagina di configurazione di un dispositivo rappresenta la seconda parte del
mio lavoro di tesi. Infatti mi è stato chiesto di riscriverla per offrire nuove
funzionalità che migliorino la qualità interna ed esterna , in particolare robustezza e
usabilità.
Innanzitutto si è introdotto nell'interfaccia un meccanismo che associa
automaticamente il tipo del dispositivo introdotto con i plugin necessari per la sua
gestione. In questo modo si facilita il compito dell'amministratore che deve
configurare nuovi dispositivi del sistema e si evitano gli errori dovuti all'aggiunta
manuale dei plugin .
Inoltre si può avere la possibilità di associare dei plugin ad un nuovo tipo di
dispositivo. Infatti quando viene creato un nuovo tipo di dispositivo si possono
assegnare dei plugin che grazie a questo script vengono inseriti automaticamente
ogniqualvolta si provi ad aggiungere un dispositivo dello stesso tipo.
Sempre nell'ottica di semplificare il lavoro degli amministratori di sistema ed evitare
possibile cause di errore, sono stati introdotti altri controlli relativi alla
configurazione di altri dispositivi.
Lato client sono state realizzate delle funzioni in javascript che effettuano i controlli
sui campi obbligatori durante l'inserimento di un dispositivo, e sull'indirizzo IP che
deve essere del tipo previsto dallo standard IP
Per evitare di assegnare al dispositivo dipendenze non volute, dalla pagina di
configurazione si può aprire una finestra di pop-up che visualizza il grafo delle
dipendenze considerando il nuovo dispositivo e le sue dipendenze in quel momento
assegnate.
Infine, poiché nel grafo orientato aciclico costruito sulla base delle dipendenze
logiche dei dispositivi , non ci possono essere cicli, prima che le dipendenze relative
al nuovo dispositivo vengono registrate sui file di configurazione , viene verificato
lato server che il loro inserimento non provochi dei cicli nel grafo, e in caso
contrario queste non vengono registrate e viene visualizzata una pagina con la lista
Pietro Neroni 566/2833 Pagina 5 di 117

delle dipendenze che causano cicli .
Il sistema sviluppato è stato applicato e validato nel sito Grid dell'esperimento ATLS
presente presso il Dipartimento di Fisica dell'Università Federico II di Napoli.
Pietro Neroni 566/2833 Pagina 6 di 117

2 INTRODUZIONE AL CALCOLO IN ATLAS
Il modello generale di calcolo per l'offline e l'analisi dell'esperimento ATLAS è un
modello gerarchico, i cui livelli sono detti Tier,utilizzato per tutti gli esperimenti
operanti presso l'acceleratore i particelle LHC del CERN di Ginevra .
Nel sistema online di Acquisizione Dati c'è l'Event Filter Farm, che organizza i dati
grezzi in output dall'esperimento in uno stream da passare al Tier0.
-Il Tier0 è situato al CERN, qui avviene la produzione dei dati da inviare ai Tiers di
livello inferiore. Dopo una fase di calibrazione ed allineamento dei dati di output di
LHC , il Tier0 invia ai Tier1 l'output costruito
-Il Tier1 conserva a tempo indeterminato una porzione dei dati grezzi, sui quali esegue
procedure di calibrazione, allineamento e ricostruzione dei dati e li distribuisce al
Tier2.
-Il Tier2 esegue produzione di dati simulati e job di analisi sui dati reali, passando
l'output ai Tier3 se richiesto.
-Nei Tier3 i fisici compiono localmente ulteriori analisi dei dati.
Ogni Tier mantiene una copia dei dati che ha elaborato per usarli come esempio per le
successive elaborazioni e permettere al livello successivo di recuperarli se
necessario[1].
Pietro Neroni 566/2833 Pagina 7 di 117

Figura 1: struttura a Tiers di ATLAS
2.1 Il Sito Tier2-Napoli
Nel modello di calcolo di ATLAS i Tier2 hanno un ruolo molto importante per quel
che riguarda le calibrazioni del rivelatore, la simulazione dati e l'analisi secondo gli
interessi e le attività delle comunità locali ed in base alle caratteristiche tecniche del
singolo sito, intese come risorse, connessioni di rete ed affidabilità.
Un Tier2 fornisce capacità di analisi per i gruppi e sottogruppi di fisica: quindi deve
fornire un infrastruttura di calcolo che possa sostenere una attività multi-utente, dove
ci sono utenti che eseguono operazioni computazionalmente impegnative e necessitano
di tempi di risposta ragionevoli.
Oltre a ciò un Tier2 deve farsi carico di tutte le capacità di simulazione richieste
all'esperimento ed i dati simulati prodotti sono inviati al Tier1 di riferimento dove
saranno disponibili per tutti gli altri siti che fanno capo ad esso.
E' necessario quindi, che il Tier2 sia pienamente accessibile tramite gli strumenti Grid
standard.
Le risorse del Tier2-Napoli sono disponibili 24 ore al giorno, 7 giorni alla settimana.
Il centro è assistito 8-10 ore al giorno per 5 giorni alla settimana e le operazioni di
Pietro Neroni 566/2833 Pagina 8 di 117

manutenzione sono programmate in modo da sospendere il servizio per il minor tempo
possibile.
Il Tier2-Napoli è localizzato nel Complesso Universitario di Monte Sant'Angelo,
distribuito su due locali :
• Il Capannone SCoPE, che contiene quattro Racks con apparati dedicati
esclusivamente al Tier2 Atlas.
• Una sala appositamente dedicata nei locali del Servizio di Calcolo & Reti (SCR)
della Sezione INFN, del Dipartimento di Fisica .
La topologia del Tier2-Napoli può essere schematizzata in questo modo :
Figura 2: Topologia del Tier2 Napoli
L'attività del Tier2 è garantita anche in caso di guasti alla rete elettrica grazie alla
presenza di cinque gruppi di continuità, tre sono utilizzato per alimentare la sala
macchine posta nel dipartimento di fisica, altri due invece garantiscono l'alimentazione
elettrica agli apparati posizionati nel capannone SCoPE. I collegamenti in questione
sono indicati dalla figura 2.
2.1.1 Servizi offerti dal Tier2
Pietro Neroni 566/2833 Pagina 9 di 117

Al fine di comprendere meglio le attività previste dalla Tier2, è opportuno
illustrare i servizi e gli elementi fondamentali.
Ogni Virtual Organization mette a disposizione delle Grid [2] un insieme di
risorse interconnesse tramite la rete Internet. In ogni sito sono installate delle
farm composte da macchine distinte a seconda delle funzionalità.; alcune
offrono essenzialmente capacità di calcolo, altre di storage o implementano
funzionalità diverse:
– User Interface (UI) Rappresenta il punto di accesso a Grid; è costituita da un
calcolatore dove gli utenti hanno un account personale, dove è installato il loro
certificato e che permette loro di interagire con le funzionalità del sistema grid.
Dalla UI, pertanto, un utente può essere autenticato e autorizzato all'utilizzo
delle risorse e può sottomettere le proprie applicazioni (job), gestirne
l'esecuzione e ottenerne i risultati.
Figura 3: Accesso ai servizi Grid tramite UI
– Computing Element(CE) sono l'interfaccia Grid verso una Farm costituita da
nodi di calcolo (Worker Node – WN) e gestiscono i job di calcolo tramite un
batch-queue system; tramite il batch system e possibile partizionare l'insieme di
risorse di calcolo (CPU) e definire delle policy di utilizzo da parte delle varie
VO (CPU time, numero di job concorrenti) mediante la creazione di code batch
e ciascun Computing Element e fornito di certificato digitale che attesta
l'attendibilita delle transazioni;
– Worker nodes (WN) Sono nodi di una farm, chiamati computer off-the-shelf, i
quali offrono soltanto CPU e connettività senza periferiche di I/O. L disco
locale contiene solo il sistema operativo ed un'area dati che funge da buffer
temporaneo
Pietro Neroni 566/2833 Pagina 10 di 117

Figura 4: Comunicazione attraverso i Computing Element
– HRL servizio per l'accounting per l'utilizzo delle risorse di calcolo da parte
delle diverse Virtual Organization
– Servizi di Storage:
Lo Storage Element è il servizio che permette ad utenti o applicazioni di
memorizzare dati per usi futuri.I dati su un SE sono read-only: non possono
essere modificati, ma solo cancellati o sovrascritti.
Il tipo di Storage Element utilizzato dal Tier2 di Napoli è l'SRM (storage
resource manager) che è interfaccia verso diverse risorse di storage, gestite da
più server. Lo spazio di storage può essere aggiunto dinamicamente. In
particolare si è utilizzato il DPM ( disk pool manager) il quale è un server che
fornisce un singolo punto di accesso verso un pool di server di disco.
Pietro Neroni 566/2833 Pagina 11 di 117

Figura 5: Schema tipico di un sito Grid
2.1.2 Collocazione apparati del Tier2 di Napoli
Gli apparati sono collocati all'interno delle due sale secondo questa disposizione :
Pietro Neroni 566/2833 Pagina 12 di 117

Figura 6: Localizzazione degli apparati del Tier2 napoli
I due locali sono collegati attraverso un link in fibra a 10 Gbps, la connessione verso il
Tier1 è ottenuta tramite il POP GARR localizzato nell'edificio dei Centri Comuni del
Complesso Universitario di Monte Sant'Angelo, e facente capo al CSI. Il collegamento
fra il Tier2 ed il POP GARR è ottenuto tramite un router Cisco 3750, con un Link in
fibra a 1 Gbps, ed il router ha una linea dedicata.
Per quanto riguarda i dettagli tecnici degli apparati appartenenti al Tier2-Napoli
possiamo fare riferimento alle seguenti tabelle :
Service Nodes
Pietro Neroni 566/2833 Pagina 13 di 117

Figura 7: caratteristiche tecniche dei service nodes
I Service Nodes sono gli apparati dedicati alla gestione dell'accounting degli utenti e
dello smistamento dei job da eseguire alle macchine deputate ad eseguirli.
Come si può notare sono macchine abbastanza eterogenee fra di loro dal momento che
sono state installate con tempistiche differenti.
Switch
Figura 8: network switches
Pietro Neroni 566/2833 Pagina 14 di 117

Sono gli apparati che si occupano della gestione del traffico dati fra le due sale ed
anche da e verso l'esterno. Il trasferimento dei dati è un passaggio fondamentale per un
tier-2, dal momento che il loro scopo principale è quello di elaborare i dati ricevuti dai
tier-1 e passare i risultati di queste elaborazioni ai tier-3, per cui questi apparati devono
essere tenuti sotto controllo specie per quanto riguarda il traffico generato.
Storage Elements
Figura 9: Risorse di storage
sono gli apparati destinati a conservare i dati da elaborare.
Sono collegati agli altri apparati attraverso dei canali in fibra ottica appositamente
dedicati e sono gestiti attraverso vari server che si occupano delle operazioni di lettura
e scrittura su di essi.
Osservando la tabella si può notare che non sono tutti dello stesso tipo, dal momento
che sono stati aggiunti alla rete in tempi differenti.
Pietro Neroni 566/2833 Pagina 15 di 117

Worker Nodes
Figura 10: caratteristiche tecniche dei worker node
Sono gli apparati che eseguono i job sui dati contenuti negli Storage Elements, si nota
immediatamente che non tutti hanno le stesse caratteristiche tecniche. Inoltre come si
evince dalle colonne relativo all'anno di acquisto e dismissione molti di essi sono stati
aggiunti di recente, e quindi sono diversi dagli apparati più “anziani” . Per alcuni di
questi ultimi inoltre è già stata programmata la dismissione.
Pietro Neroni 566/2833 Pagina 16 di 117

3 POWERFARM
Con il termine farm intendiamo una serie di dispositivi distinti (worker node, disk
server, computing element, storage, etc.) , che forniscono particolari servizi alla grid,
ed hanno delle particolari caratteristiche hardware e software. Essa nasce con lo sopo
di centralizzare le operazioni che si occupano di gestione, manutenzione e sicurezza di
un insieme di dispositivi. Ognuna di queste operazioni ha la necessità comune di
accedere o spegnere i dispositivi.
Si pensi ad un aumento della temperatura all'interno dei rack che contengono i
dispositivi, oppure si deve effettuare un operazione di manutenzione di un dispositivo
malfunzionante, in entrambi i casi bisognerebbe spegnere prima i dispositivi coinvolti
per poi riaccenderli. Per fare un operazione del genere si deve tener conto che ogni
dispositivo ha una serie di dipendenze software e hardware.
Quindi è necessario un sistema che consenta agli amministratori della farm di tenere
sotto controllo in maniera centralizzata tutti i dispositivi presenti.
Per questo motivo è stato creato “Powerfarm”[3] che è un sistema che consente di
gestire, controllare lo stato, attivare/disattivare qualsiasi dispositivo della farm, sia
manualmente che in modo automatico rispettando le dipendenze hardware e software
dei dispositivi.
3.1 Funzionamento Powerfarm
Powerfarm viene innescato in corrispondenza di uno dei seguenti tre eventi:
1 . Mancanza/ritorno della corrente (monitoraggio eseguito dal modulo UPSmon)
2. Sensori di temperatura, umidità e allagamento fuori norma (monitoraggio eseguito
dai moduli CMC)
3. Operazione di manutenzione eseguite manualmente dagli operatori autorizzati della
griglia.
Lo script Powerfarm, quindi, può essere richiamato:
• Nei primi due casi, automaticamente da uno dei programmi di monitoraggio della
farm,
• Nell’ultimo caso, mediante un interfaccia web (creata appositamente per consentire
agli amministratori del sito non solo di creare la struttura della farm, ma anche di
spegnere o accendere uno determinato dispositivo, un insieme di dispositivi, o tutta la
farm) o da linea di comando (se si è un utente autorizzato).
In entrambe le situazioni, Powerfarm è capace di evitare danni alle macchine e/o al
Pietro Neroni 566/2833 Pagina 17 di 117

software spegnendo/accendendo correttamente server, worker node, risorse di storage,
router e virtualmente un qualunque altro dispositivo, grazie all'utilizzo di appositi
plugin scritti specificatamente per funzionare con il particolare hardware di cui si
dispone, e rispettando le dipendenze espresse dal grafo aciclico che definisce la farm.
Si è voluto, infatti, descrivere la topologia della farm mediante una struttura a grafo
aciclico. Le informazioni riguardo la topologia della farm e, di conseguenza, le
caratteristiche dei singoli nodi e le dipendenze tra questi, sono contenute all’interno di
due file XML, devices.xml e dependencies.xml, che contengono reciprocamente le
informazioni relative al nodo, come il nome, l’indirizzo, il tipo di dispositivo ( storage
element, computing element,Ups, Pdu, dpm, host generici, switch, worker node,
ecc…), e tutti i plugin che realizzano le operazioni di accensione, spegnimento e
controllo di stato specifici di quel dispositivo:
L’impiego dei plugin consente di ottenere un livello di astrazione che permette agli
amministratori di una farm di poter controllare virtualmente qualunque tipo di
dispositivo: gli utenti possono, infatti, scriversi i propri plugin specifici per
spegnere/accendere i particolari dispositivi hardware e software di cui dispongono.
3.2 Architettura di Powerfarm
Powerfam è un sistema software per la gestione remota dello spegnimento e
dell'accensione (tenendo conto delle dipendenze hardware e software dei dispositivi)
dei dispositivi della farm organizzate secondo il paradigma Grid.
Tale software e indipendente dalla piattaforma ed e scritto in Perl (modulo principale)
e Java ,Javascript,JSP(interfaccia web), gira sotto Linux, anche se può essere
esportato su altre piattaforme, grazie alla flessibilità dei linguaggi di programmazione
utilizzati.
L'architettura del Powerfarm è formata dalle seguenti componenti:
• Il modulo principale;
• Modulo per la gestione delle emergenze;
• I plugin;
• Modulo di notifica;
• Modulo di log;
• File di configurazione XML;
• Interfaccia web e linea di comando.
3.3 Modulo principale
Il modulo principale si occupa della gestione dei dispositivi. Ogni dispositivo può
Pietro Neroni 566/2833 Pagina 18 di 117

essere acceso / spento mediante di tre funzioni: spegnimento hardware, spegnimento
software e accensione hardware. Visto che Powerfarm viene richiamato in condizioni
di emergenza o per manutenzione, e doveroso prevedere eventuali malfunzionamenti
dei dispositivi, che e il motivo per cui ci sono due tipi di procedure di spegnimento per
i dispositivi.
Lo spegnimento software spegne il dispositivo in modo canonico, che e per esempio
tramite SSH se si tratta di un server Linux, o mediante DRAC .
Invece, lo spegnimento hardware viene richiamato solo se lo spegnimento software
non va a buon fine , e quindi spegne i dispositivi fisicamente, ad esempio disattivando
la PDU che fornisce l'energia elettrica ad un rack.
Tutte le procedure utilizzate, di accensione o di spegnimento, sui vari dispositivi
considerano le dipendenze hardware/software tra essi. Quindi, per poter accendere
uno specifico dispositivo si dovrà agire in modo ricorsivo su tutti i dispositivi a cui
esso e collegato, mentre per poter spegnere un dispositivo sarà necessario spegnere
prima tutti i dispositivi che sono collegati con lui. Questo verra spiegato nei dettagli
successivamente.
3.4 Modulo per la gestione delle emergenze
Una trap SNMP è un pacchetto di informazioni inviate da un dispsitivo di rete che
comunica mediante il protocollo SNMP (Simple Network Management Protocol),
basato su TCP/IP ed è usato per monitorare e gestire le periferiche di rete.
Il modulo per la gestione delle emergenze è il modulo che ascolta e cattura trap SNMP,
che arrivano da dispositivi di controllo e notifica il Modulo principale degli eventi
accaduti con lo scopo di adottare le azioni corrispondenti. Come abbiamo detto
Powerfarm puo venir richiamato manualmente o automaticamente quando si
verificano dei principali eventi:
• modifiche della alimentazione , per esempio, quando si verifica la perdita di potenza,
l'ups monitor puo richiamare Powerfarm con l'istruzione di spegnimento di tutto cio
che e collegato al gruppo di continuita e probabilmente anche gli altri dispositivi che
dipendono da quelli direttamente coinvolti. Successivamente in caso di ritorno della
corrente, l'ups monitor puo eseguire Powerfarm con le istruzioni di accensione di tutto
cio che e collegato al gruppo di continuita e anche gli altri dispositivi che dipendono
da quelli direttamente coinvolti, sempre rispettando le dipendenze dei dispositivi;
• manualmente dagli amministratori della farm per eventuali operazioni di
manutenzione.
Infatti l'amministratore della farm puo decidere se effettuare operazioni su tutta la
farm, su tutti i dispositivi presenti in un rack o collegati ad un particolare dispositivo,
su uno specifico gruppo di dispositivi tipo i worker node, oppure procedere solo su un
singolo dispositivo.
• per agire su uno o piu dispositivi al verificarsi di un evento anomalo (ad esempio, un
Pietro Neroni 566/2833 Pagina 19 di 117

picco di temperatura, fumo o altri eventi monitorabili mediante l'uso di sensori).
Powerfarm viene richiamato quando si verifica un evento o un sensore supera il valore
limite. Ad esempio, se la temperatura in un rack raggiunge un valore critico, viene
richiamato Powerfarm per spegnere tutti i dispositivi appartenenti al rack; dopodichè ,
quando la temperatura raggiungera un valore normale di nuovo, verrà richiamato
Powerfarm per accendere di nuovo la dispositivi nel rack.
Tali eventi generati dai sensori vengono rilevati tramite un programma ,che effettua
continue interrogazioni attraverso SNMP, e solo dopo aver verificato con certezza di
trovarsi in uno stato di allarme invoca Powerfarm.
3.5 Modulo di notifica
Il modulo di notifica ha la funzione di informare gli amministratori della farm in
presenza di un evento anomalo, queste notifiche possono essere inviate tramite e-mail
o SMS se quest'ultima opzione è abilitata.
L'invio delle notifiche attraverso e-mail avviene quando viene richiamato Powerfarm
in seguito al verificarsi di un comportamento anomalo rilevato dai sensori, come un
picco della temperatura o il rilevamento di fumo.
3.6 Modulo di log
Vengono registrati in un modulo di log tutti gli eventi e le attivita che si svolgono .
In questo modulo sono presenti tutte le informazioni verificatesi (accensione e
spegnimento automatica o manuale , picchi di temperatura) e i dispositivi coinvolti che
hanno comportato l'azionamento di Powerfarm, ordinate per data in cui si sono
verificate, in modo da consentire una ricostruzione degli eventi.
3.7 Riga di Comando e Interfaccia Web
Powerfarm puo essere utilizzato in due modi, mediante linea di comando
o mediante l'interfaccia web (di solito utilizzata dall'amministratore della farm per
operazioni di manutenzione). Anche i file di configurazione XML possono essere
modificati manualmente o tramite l'interfaccia web, pero dopo l'esecuzione di un
operazione di modifica dei file di configurazione mediante interfaccia Web, affinchè il
sito si aggiorni sulla base delle modifiche effettuate, si deve ricompilare il file di
configurazione utilizzando l'apposita sezione, che in seguito verra spiegata in dettaglio
Pietro Neroni 566/2833 Pagina 20 di 117

L'interfaccia web si basa su un sito web composto da pagine JSP e le principali azioni
consentite sono:
• visualizzare il grafo delle dipendenze;
• controllare lo stato corrente di accensione e spegnimento dei dispositivi;
• controllare lo stato della farm;
• aggiungere, aggiornare o cancellare un dispositivo della farm;
• ricerca di un dispositivo;
• aggiornare le impostazioni dell'applicazione, mediante la registrazione in memoria
dei file di configurazione XML modificati dopo aver effettuato almeno un'operazione
di modifica di tali file.
Il tipico ciclo di vita d'iterazione consiste principalmente in tre operazioni:
1) ricerca di uno o piu dispositivi da gestire;
2) procedere con una delle due operazioni possibili accensione o spegnimento su uno o
un gruppo di dispositivi selezionati
3) Controllare che su tutti i dispositivi coinvolti sia effettuata l'operazione richiesta,
consultando il log generato o verificando lo stato in cui si trovano nella schermata
principale.
L'interfaccia Web verrà spiegata in dettaglio nei capitoli successivi
3.8 La gestione delle dipendenze
Uno dei principali aspetti che Powerfarm tiene conto sono le dipendenze tra i
dispositivi. Dal punto di vista logico infatti , ciascun dispositivo ha un proprio ruolo
nella farm e svolge compiti specifici, invece dal punto di vista fisico ogni dispositivo
e collegato ad un alimentatore ed e risiede all'interno del rack. Quindi ogni dispositivo
ha una serie di dipendenze logiche e fisiche da rispettare e pertanto prima di effettuare
un operazione di accensione o spegnimento bisogna creare una vera e propria catena
delle dipendenze tra tutti i dispositivi presenti nella farm.
Per esempio, per disattivare un disco di storage bisogna disattivare prima tutti i worker
node che utilizzano tale disco, altrimenti si verificherebbe che togliamo lo spazio di
storage ad un worker node che ancora e attivo. Questo vale anche per l'attivazione,
infatti per poter attivare un worker node bisogna prima attivare lo spazio di storage che
deve utilizzare.
Powerfarm per rappresentare le dipendenze sia hardware che software utilizza un grafo
delle dipendenze che vedremo nel dettaglio nei capitoli successivi.
Pietro Neroni 566/2833 Pagina 21 di 117

3.9 I Plugin
Per le funzioni di controllo dello stato e gestione di tutti i dispositivi della farm quali
server, worker node, risorse di storage, router, Powefarm utilizza dei Plugin realizzati
in un qualsiasi linguaggio di programmazione o di scripting che sono eseguibili sotto
linux e ritornano il valore 0 se il plugin è stato eseguito con successo oppure un valore
diverso da 0 in caso contrario e inoltre ritorna il codice d'errore ed eventualmente la
descrizione dell'errore.
I plugin vengono utilizzati da Powerfarm oltre per accendere o spegnere uno o piu
dispositivi o l'intera farm, ma anche per controllare se il un dispositivo è online oppure
offline. Quindi ci sonp diverse librerie di plugin per i vari dispositivi, ad esempio,
SSH, Intelligent Platform Management Interface (IPMI), Baseboard Management
Controller (BMC), Dell Remote Administration Controller (DRAC), Power
distribution Unit (PDU), Chassis Management Controller (CMC). Inoltre se si vuole
aggiungere un particolare dispositivo si può scrivere un nuovo plugin per gestire il
nuovo dispositivo.
I plugin utilizzati si occupano principalmente:
- Accensione;
- Spegnimento software;
- Spegnimento hardware;
- Controllo stato di accensione;
- Controllo stato di spegnimento.
Per ogni plugin è presente un parametro, (timeout) che rappresenta il tempo massimo
entro il quale il plugin deve completare la sua esecuzione. Nel caso dello spegnimento
software di un dispositivo, se non si spegne entro il timeout previsto, verrà richiamato
il plugin per lo spegnimento hardware che consistera nello spegnere in modo fisico il
dispositivo, come ad esempio disattivando il unita di alimentazione (ad esempio PDU)
per il dispositivo.
Se anche il plugin dello spegnimento hardware fallisce, dopo il timeout di scadenza, si
agirebbe in base al valore di ritorno del blocco, se il processo dovrebbe continuare o
no, in questa situazione il valore di default per il blocco off e 0, il che significa che il
processo deve andare avanti anche se la dispositivo non si spegne.
Come quello per lo spegnimento il plugin per l'accensione ha il timeout e se non viene
portato a temine entro il temine stabilito si agirebbe in base al valore che il blocco
ritorna, di solito il valore di default e 1 che significa che il processo deve fermarsi,
perche non può effettuare l'accensione in modo ricorsivo sugli altri dispositivi che
dipendono dal dispositivo non acceso, quindi bisogna rispettare sempre le dipendenze
tra i vari dispositivi.
I plugin per il controllo dello stato di accensione o spegnimento sono utilizzati per
verificare se un dispositivo e acceso o spento.
Pietro Neroni 566/2833 Pagina 22 di 117

Nel seguente paragrafo presentiamo i dispositivi hardware a disposizione, le
tecnologie adottate e i Plugin realizzati per controllare con Powerfarm tali dispositivi.
3.9.1 Tecnologie e plugin utilizzati
IPMI
La specifica denominata Intelligent Platform Management Interface (IPMI) definisce
un insieme di interfacce verso un dispositivo informatico che un amministratore di
sistema può usare per controllare lo stato di salute dell’hardware e per gestire alcuni
parametri di funzionamento quali ad esempio il circuito di alimentazione del
dispositivo.
L’IPMI opera indipendentemente dal sistema operativo e permette agli amministratori
di gestire il sistema monitorato direttamente da remoto persino in assenza di sistema
operativo o a dispositivo spento. L’IPMI può comunque funzionare anche quando il
sistema operativo è avviato e pienamente funzionante. La specifica dell’IPMI
stabilisce solo lo standard della struttura e del formato delle interfacce, mentre
l’implementazione può variare a seconda dei costruttori e degli sviluppatori.
L’IPMI è costituito da un controller principale denominato Baseboard Management
Controller (BMC) e da altri controller periferici connessi al BMC attraverso
l’interfaccia denominata IPMB (Intelligent Platform Management Bus/Bridge). I
controller periferici gestiscono gli attuatori ed i sensori che consentono di controllare i
vari aspetti del sistema.
Per il controllo dell’interfaccia IPMI è usato il tool IPMITOOL liberamente
disponibile all’indirizzo http://sourceforge.net/projects/ipmitool/.
Dispositivi
I dispositivi che dispongono dell’IPMI nella sala del Tier2 di Atlas sono i seguenti:
Device Indirizzzo IP device Indirizzo Ip IPMI
atlaswn16.na.infn.it 172.16.20.116 172.16.10.128
atlaswn17.nf.infn.it 172.16.20.117 172.16.20.117
atlasce01.nf.infn.it 192. 167. 203.183 172.16.10.129
atlasse02.nf.infn.it 192. 167. 203. 187 172.16.10.10.45
atlase04nf.infn.it 192. 167. 203. 188 172.16.10.10.46
Plugin
I plugin usati per gestire le macchine che dispongono di IPMI sono i seguenti:
• ipmi_hard_on.pl
Pietro Neroni 566/2833 Pagina 23 di 117

• ipmi_hard_off.pl
• ipmi_ssh_shutdown.pl
PDU
Una Power Distribution Unit (comunemente abbreviato in PDU) è un dispositivo che
distribuisce l’energia elettrica all’interno del Rack. Le PDU possono essere di tipo
“intelligente” ovvero controllabili e gestibili da remoto. In particolare, i singoli socket
(prese di corrente) delle PDU possono essere accesi o spenti tramite l’unità di
controllo CMC (Chassis Management Controller) con comandi SNMP.
Laddove si disponga di PDU intelligenti, esse possono essere sfruttate per controllare
da remoto e in maniera automatica l’energia elettrica erogata alle singole prese dei
dispositivi, controllando in tal modo l’effettiva accensione o spegnimento dei
dispositivi ad esse collegati.
I dispositivi che possono essere controllati tramite PDU sono quelli che sono collegati
interamente alle PDU intelligenti. Ovviamente, se un dispositivo dispone già di un
metodo alternativo per l’accensione /spegnimento hardware (es. IPMI) non è
necessario utilizzare la PDU ma si può usare il metodo principale senza bisogno di
andare ad interrogare la PDU corrispondente.
Plugin
I plugin usati per gestire le macchine collegate alle PDU intelligenti sono i seguenti:
• pdu_hard_on.pl
• pdu_hard_off.pl
• pdu_ssh_shutdown.pl
• check_pdu_on.pl
• check_pdu_off.pl
DRAC
Il Dell® Remote Access Controller (DRAC) permette di accedere, monitorare e gestire
sia i server blade che il cestello da remoto e indipendentemente dallo stato del sistema
operativo dei server blade stessi. Il DRAC può essere usato per accendere / spegnere
via software i server blade ed il cestello.
Il DRAC presenta però alcune limitazioni: non supporta di fatto il multiple sign-on,
ovvero – anche se è possibile collegarsi al DRAC da più istanze contemporaneamente
(ad es. tramite l’utility a linea di comando, il terminal server e l’interfaccia web) – poi
in realtà i comandi di accensione / spegnimento che vengono impartiti sono eseguiti
solo alla disconnessione di tutte le istanze oppure non sono eseguiti affatto. E’ dunque
indispensabile che i comandi vengano eseguiti uno per volta e che non vi nessuna altra
istanza che si stia interfacciando con il DRAC nel momento in cui viene eseguito il
comando di accensione / spegnimento. Il DRAC inoltre, nella versione precedente
(presente nella Farm sui worker node dal 18 al 27) è molto lento nella risposta ai
comandi che gli vengono impartiti.
Pietro Neroni 566/2833 Pagina 24 di 117

Per interfacciarsi con il DRAC è usato il tool racadm liberamente scaricabile dal sito
http://www.dell.com
La guida in linea del racadm è consultabile all’indirizzo:
http://www.cs.uwaterloo.ca/~brecht/servers/docs/PowerEdge2600/en/Racadm/racadmc
1.htm
Dispositivi
I dispositivi controllabili mediante il sistema DRAC sono i seguenti:
Device Indirizzzo IP device descrizione
atlasdrac01.na.infn.it 172.16.20.100 Cestello wn 18-27
atlasdrac02.nf.infn.it 172.16.20.87 Cestello wn 28-38
Plugin
Il plugin usato per gestire i dispositivi DRAC è il seguente:
• drac_chassis.exp
Plugin
In Powerfarm vi sono 4 tipologie di plugin:
I. Plugin di accensione
II. Plugin di spegnimento software
III. Plugin di spegnimento hardware
IV. Plugin di controllo stato ON | OFF
Ciascuna tipologia di plugin può essere composta da vari plugin che realizzano la
medesima funzionalità ma con tecnologie diverse e che vengono quindi usati su device
diversi. Tutti i plugin rispettano la seguente logica: essi ritornano il valore 0 (zero) se
sono stati eseguiti con successo, un valore diverso da 0 altrimenti.
Elenco Plugin
ELENCO PLUGIN
Plugin di accensione
ipmi_hard_on.pl
Plugin per l'accensione di un dispositivo mediante IPMI
Pietro Neroni 566/2833 Pagina 25 di 117

pdu_hard_on.pl
drac_chassis.exp
drac_blade.exp
Plugin di spegnimento software
ipmi_ssh_shutdown.pl
pdu_ssh_shutdown.pl
drac_chassis.exp
Plugin di spegnimento hardware
ipmi_hard_off.pl
pdu_hard_off.pl
Plugin di controllo stato ON|OFF
Plugin per l'accensione di un dispositivo mediante l'accensione dei
socket della PDU
Plugin per l'accensione (e spegnimento software) del cestello Dell
contenente i blade server che usano il DRAC
Plugin per l'accensione e spegnimento (sia hardware che software)
dei server blade del cestello Dell che usano il DRAC
Plugin per lo spegnimento software mediante SSH di un dispositivo
con IPMI
Plugin per lo spegnimento software mediante SSH di un dispositivo
senza IPMI ma collegato ad una PDU intelligente
Si vede drac_chassis.exp come plugin di accensione
Plugin per lo spegnimento hardware di un dispositivo mediante
IPMI
Plugin per lo spegnimento hardware di un dispositivo mediante
spegnimento dei socket della PDU
check_ping_on.pl
check_ping_off.pl
check_pdu_on.pl
check_pdu_off.pl
Plugin per il controllo dello stato ON di un dispositivo mediante
ping
Plugin per il controllo dello stato OFF di un dispositivo mediante
ping
Plugin per il controllo dello stato ON dei socket di una PDU
Plugin per il controllo dello stato OFF dei socket di una PDU
Plugin e Delay di accensione
I device necessitano tipicamente di un tempo di start-up per essere realmente operativi
che va da alcuni secondi a diversi minuti dopo l’accensione (si pensi, ad es., al
caricamento di un sistema operativo e all’avvio di tutti i servizi). Quando si accende
un dispositivo è necessario attendere che esso sia completamente operativo prima di
passare ad accendere il dispositivo al livello successivo nel grafo delle dipendenze.
Questo meccanismo è realizzato grazie all’uso dei plugin di check-on che
periodicamente controllano se un dispositivo è acceso ed operativo prima di passare
Pietro Neroni 566/2833 Pagina 26 di 117

all’accensione del successivo (ad es., nel caso di un device con sistema operativo,
controllando se il dispositivo risponde al ping). Il check-on avviene periodicamente
entro e comunque non oltre il tempo di timeout impostato per l’accensione del device.
Se, entro il tempo di timeout, il dispositivo si è acceso ed è operativo allora si passa
all’accensione del dispositivo al livello successivo. Se, al contrario, il dispositivo non
si è acceso neanche allo scadere del timeout, allora si va a controllare il valore
dell’attributo lock-on per stabilire se si può comunque proseguire con l’accensione del
livello successivo o se bisogna arrestare il processo di accensione a causa
della mancata accensione/operatività del device corrente.
Tuttavia, per alcuni device particolari, il meccanismo del check-on non è direttamente
implementabile, poiché non c’è un modo di stabilire da remoto se il dispositivo è
realmente operativo oppure no. E’ questo il caso, ad esempio, degli slot di espansione
del sistema di dischi dell’IBM DS4700 (device exp01, exp02, exp03). Questi device –
che vengono accesi tramite PDU – impiegano dall’accensione 30 secondi circa per
essere realmente operativi ma una volta operativi essi non rispondono al ping né ad
altro simile sistema di controllo remoto (è solo possibile controllare se la PDU
corrispondente è accesa o spenta, ma questo controllo non garantisce che il device sia
realmente operativo). E’ quindi necessario prevedere un meccanismo per “attendere”
che questi dispositivi siano pienamente operativi prima di procedere all’accensione del
successivo livello. Questo comportamento può essere facilmente ottenuto facendo si
che il plugin responsabile dell’accensione del dispositivo attenda con uno sleep il
tempo necessario all’accensione prima di ritornare il controllo a Powerfarm. In pratica,
si mette uno sleep come ultima istruzione del plugin di accensione in modo da
attendere i secondi necessari alla completa accensione del device. Quindi, si imposta in
Powerfarm un timeout di accensione per quel device abbastanza alto da comprendere il
tempo totale di esecuzione del plugin di accensione.
Ad esempio, per il device exp01, il plugin di accensione pdu_hard_on.pl esegue come
ultima istruzione uno sleep di 30 secondi mentre il timeout di esecuzione di questo
plugin impostato in Powerfarm è di 60 secondi, un tempo sufficiente per l’esecuzione
del plugin e per l’attesa dello sleep finale.
Questo meccanismo dovrebbe essere realizzato per tutti i device per cui non si dispone
di un metodo per controllare che essi siano – oltre che accesi – anche realmente
operativi.
Pietro Neroni 566/2833 Pagina 27 di 117

4 I FILE DI CONFIGURAZIONE XML
I file di configurazione XML vengono utilizzati sia dal programma in perl, sia
dall'interfaccia web, e rappresentano le informazioni gestite da Powerfarm.
Esse infatti contengono tutte le informazioni sui dispositivi gestiti da Powerfarm
(device.xml) e i corrispondenti link alle loro pagine di monitoraggio (links.xml), sulle
loro dipendenze (dependencies.xml), ed eventualmente se fanno parte di un insieme di
dispositivi (set.xml).
In seguito spiegheremo in dettaglio ognuno di questi file xml, fornendo una breve
descrizione per ogni campo presente nei file xml.
Device.xml
Descrive i dispositivi che Powerfarm gestisce.
Ha i seguenti campi:
name: indica il nome del device
description: una breve descrizione testuale del dispositivo
address: indica l'indirizzo IP del dispositivo
type: indica il tipo del dispositivo ( worker node, computing element....)
selected: può assumere 0 o 1. Quando è ad 1 seleziona automaticamente il campo
select della riga corrispondente al device quando questo viene visualizzato a seguito
ad una ricerca
action: per i rispettivi plugin di accensione , spegnimento e controllo stato, indica
dove essi risiedono, gli argomenti che devono essere passati, timeout che rappresenta
il tempo massimo entro il quale il plugin deve completare la sua esecuzione, e una
descrizione testuale del plugin
Pietro Neroni 566/2833 Pagina 28 di 117

La struttura XML che è utilizzata viene rappresentato nel file device.dtd
Figura 11: File di configurazione device.xml
Dependences.xml
Descrive le dipendenze tra i dispositivi
Ogni dipendenza tra i dispositivi viene descritta dall'elemento arc che ha 3 attributi:
source e target dove vanno inseriti i dispositivi che compongono la dipendenza e
description che è un attributo facoltativo nel caso si voglia inserire una breve
descrizione testuale sulla dipendenza tra source e target
Pietro Neroni 566/2833 Pagina 29 di 117

Figura 12: File di configurazione dependences.xml
Il file dependence.dtd rappresenta la struttura di base utilizzata nel file dependence.xml
Links.xml
Contiene i link dei dispositivi per l'integrazione dell'interfaccia web con Nagios e
Ganglia
Il nodo radice del file è l'elemento links che ha come figlio l'elemento link, che a sua
volta contiene altri 2 elementi , nagios e ganglia.
Nell'attributo “name” dell'elemento link viene inserito il nome del dispositivo a cui
verranno associati i link di Ganglia e Nagios. Le informazioni sui link vengono fornite
dagli attributi dei due elementi nagios e ganglia.
Pietro Neroni 566/2833 Pagina 30 di 117

Figura 13: File di configurazione links.xml
Il file links.dtd rappresenta la struttura di base utilizzata nel file links.xml
Plugins.xml
Contiene per un particolare tipo di dispositivo , il path assoluto dei plugin ad esso
associati. Questo file utilizzato nella pagina di configurazione di un dispositivo da una
funzione in Javascript che verrà spiegata in dettaglio nei capitoli successivi.
Figura 14: File di configurazione plugins.xml
Ogni elemento plugin ha 6 attributi: il tipo del dispositivo, e i plugin utilizzati da
Powerfarm per gestire un dispositivo (hard-on, off-soft, off-hard, check-on, check-off)
Il file plugins.dtd rappresenta la struttura di base utilizzata nel file plugins.xml
Pietro Neroni 566/2833 Pagina 31 di 117

Set.xml
Questo file xml indica se un dispositivo fa parte di un particolare insieme di
dispositivi. Viene utilizzato durante la costruzione del grafo delle dipendenze, infatti se
un dispositivo è presente in questo file , nel grafo delle dipendenze verrà rappresentato
il corrispondente insieme invece del singolo dispositivo.
Ha due campi:
dispositivo dove c'è il nome del dispositivo che fa parte dell'insieme e
insieme che indica il nome dell'insieme
Figura 15: File di configurazione set.xml
Il file set.dtd rappresenta la struttura di base utilizzata nel file set.xml
Pietro Neroni 566/2833 Pagina 32 di 117

5 Gli STRUMENTI UTILIZZATI
5.1 JAVA
Java è stato progettato fin dall'inizio come un linguaggio con caratteristiche di
sicurezza e buona programmazione che lo rendono particolarmente adatto alle
applicazioni Web.
Java è un linguaggio orientato agli oggetti: questo lo rende di uso relativamente
semplice, anche se non è un linguaggio di scripting.
Le principali caratteristiche di Java sono:
Fortemente tipato. Non ammette costrutti insicuri, quali un accesso a vettore senza
controllo sugli indici, perché questo tipo di costrutti possono dare origine a
comportamenti del programma non specificati e non predicibili.
Gestione auomatica della memoria (garbage collector). Inoltre, evita tutti i problemi di
sicurezza collegati con le istruzioni di deallocazione della memoria.
Indipendente dalla piattaforma, nel senso che viene compilato in un bytecode
eseguibile da una Java Virtual Machine.
Java risulta adeguato alle applicazioni Web perché ha determinate caratteristiche di
sicurezza: la maggior parte delle azioni di attacco ad un sistema non possono essere
descritte come un programma Java.
Il programma Java viene compilato in un bytecode che viene eseguito dalla macchina
virtuale (che funge da interprete). In questo modo si ottiene un buon compromesso tra
linguaggi compilati e linguaggi interpretati:
• è più portabile di un linguaggio compilato;
• è più efficiente di un linguaggio interpretato;
• ha caratteristiche che un linguaggio interpretato di solito non ha (ad esempio è
fortemente tipato).
Ne deriva un linguaggio che pur di uso meno diretto di un linguaggio di scripting,
Pietro Neroni 566/2833 Pagina 33 di 117

isulta molto più facile di altri linguaggi di programmazione, quali C e C++[4].
5.2 HTML
L'HyperText Markup Language (HTML) (traduzione letterale: linguaggio di
marcatura per ipertesti) è un linguaggio usato per descrivere la struttura dei
documenti ipertestuali disponibili nel Word Wide Web ossia su internet. L'HTML non
è un linguaggio di programmazione, ma un linguaggio di markup, ossia descrive il
contenuto, testuale e non, di una pagina web.
5.3 XML
E' l'acronimo di eXtendible Markup Linguage
XML è un insieme di specifiche dal World Wide Web Consortium (W3C):
le specifiche sono disponibili pubblicamente e in modo gratuito al sito www.3c.org
E' un linguaggio di markup che definisce un meccanismo sintattico che consente di
estendere o controllare il significato di altri linguaggi di markup come html.
XML deve descrivere i dati: si concentra dunque su cosa sono i dati
XML non ESEGUE nulla: XML non è stato pensato per eseguire qualcosa, ma solo per
strutturare, memorizzare e scambiare informazione.
La caratteristica vincente di XML sta nella sua indipendenza dalla piattaforma, dagli
strumenti hardware e software[5].
5.4 JSP
JSP è l'acronimo di JavaServer Page[6]. Questa è una tecnologia java per lo sviluppo
di applicazioni Web che forniscono contenuti dinamici.
Pietro Neroni 566/2833 Pagina 34 di 117

Mediante i suoi tag, è possibile inserire all'interno delle pagine funzioni o codice Java.
Alla tecnologia JSP è correlata quella Servlet. Infatti, all'atto della chiamata di una JSP,
quest'ultima viene tradotta in una Servlet. .A questo punto, come una qualsiasi servlet,
essa viene messa in esecuzione dal servlet engine: questo carica la classe con un class
loader, e la esegue.
Una pagina JSP ha in più alcuni elementi:
• direttive:
• dichiarazioni:
• scriptlet:
• espressioni:
• librerie di etichette
Il meccanismo delle JSP converte in stringa il risultato di ogni espressione JSP, in
modo da poterlo includere nella risposta che viene passata al client.
L'uso , di JSP offre vantaggi non indifferenti, quali:
• velocità di sviluppo;
• prestazioni;
• portabilità;
• ed altri aspetti inerenti alla qualità interna ed esterna dell'applicazione Web;
5.5 Javascript
Fu originariamente sviluppato da Brendan Eich della Netscape Comunication con il
nome di Mocha e successivamente di LiveScript, ma in seguito è stato rinominato
"JavaScript". È un linguaggio di scripting orientato agli oggetti e comunemente
utilizzato nei siti Web. Esso risulta avere una sintassi molto vicina a quella Java. La
caratteristica principale di questo linguaggio è che un linguaggio interpretato. Il codice
viene quindi eseguito a runtime senza la necessità di essere compilato. Un aspetto
molto importante è che il codice JavaScript lato client viene eseguito dal client, senza,
quindi, la necessità sollecitare il server.
5.6 Graphviz e Webdot
Graphviz è un programma software open source sviluppato dai laboratori di ricerca di
Pietro Neroni 566/2833 Pagina 35 di 117

AT&T per la rappresentazione di grafi (sia orientati che non orientati) in diversi
formati a partire da una loro descrizione in un semplice linguaggio testuale, sviluppato
appositamente. La rappresentazione testuale dei grafi si basa su un linguaggio molto
semplice, il DOT[7], che utilizza una sintassi simile a quella del linguaggio C.
Per comprendere meglio , in figura 17, riportiamo la descrizione testuale del grafo di
figura 16
La rappresentazione testuale inizia con l’asserzione che il grafo descritto `e un grafo
orientato (il prefisso “di” corrisponde a “direct”) denominato “G”. Le istruzioni
successive impostano alcuni parametri globali per il grafo quali la dimensione,
l’orientamento, ecc.
Le istruzioni che seguono alternano descrizioni di nodi a descrizioni di archi . Le
descrizioni di nodi riportano il nome del nodo (utilizzato sia per referenziare il nodo
nelle descrizioni degli archi sia come etichetta nella rappresentazione del grafo) e sue
proprietà quali il tipo di nodo, il colore, ecc.
Figura 16: grafo generato
con Graphviz
Pietro Neroni 566/2833 Pagina 36 di 117

Figura 17: codice sorgente del grafo di firura 12
Webdot è un programma CGI che converte una descrizione testuale di un grafo scritto
in linguaggio DOT, in un immagine di formato selezionabile(come ad esempio
bmp,gif, png, jpg, ps, ecc...)che può essere inclusa in una pagina web.
Per poter utilizzare Webdot è necessario avere:
• le librerie di graphviz installate
• un web server come Apache[8]
Pietro Neroni 566/2833 Pagina 37 di 117

6 L'OBIETTIVO DELLA TESI: SITO WEBPOWERFARM
6.1 Introduzione
Il sito WebPowerfarm rappresenta l'interfaccia web del sistema Powerfarm. Esso è
stato sviluppato appositamente per consentire agli amministratori non solo di creare
la struttura della farm, ma anche di spegnere o accendere uno determinato
dispositivo, un insieme di dispositivi, o tutta la farm.
Il sito è composto da pagine JSP, nelle quali sono inclusi anche script lato client
scritti in Javascript. Inoltre la pagine JSP utilizzano delle classi sviluppate in JAVA
per compiere operazioni come leggere o modificare i file di configurazione xml.
Come si può osservare dal diagramma dei casi d'uso di figura 18, le funzionalità
consentite da WebPowerfarm sono:
• aggiungere, aggiornare o cancellare un dispositivo della farm
• accendere o spegnere un dispositivo o un insieme di dispositivi
• ricerca di un dispositivo
• visualizzare il grafo delle dipendenze logiche dei dispositivi
• aggiornare i file di configurazione xml, nel caso siano stati modificati
manualmente senza utilizzare l'interfaccia web
Nel seguito del capitolo verranno descritte le funzionalità sopra elencate, e in maniera
più dettagliata quelle che riguardano il mio lavoro di tesi che sono:
• la visualizzazione nella home page del sito del grafo orientato aciclico che
rappresenta le dipendenze tra i dispositivi( vedere paragrafo 6.5)
• inserimento di nuove funzionalità e nuovi controlli per la pagina di
configurazione del sistema (vedere paragrafo 6.6)
Pietro Neroni 566/2833 Pagina 38 di 117

6.2 Diagramma dei casi d'uso
Figura 18: Diagramma dei casi d'uso del sito WebPowerfarm
Pietro Neroni 566/2833 Pagina 39 di 117

6.3 L'architettura
L'architettura su cui si basa la Web Application realizzata è Client/Server a tre
livelli(three-tier):
• Il primo livello è dedicato alla presentazione dei dati.
• Il secondo livello dedicato alla logica applicativa
• Il terzo livello dedicato alla gestione dei dati
Figura 19: Architettura Client/Server a tre livelli
Si ha quindi bisogno di un Web Server, un' Application Server ed un DataBase (Fig.
19).
L'ambiente, in cui il sistema opera, poggia su un unico server fisico con Sistema
Operativo Red Hat AS 5.0, sul quale sono installati sia Tomcat, come Application
Server, che MySQL come RDBMS.
Il Web Server accetta richiesta da parte dei Client e invia a questi ultimi ciò che gli è
stato richiesto Il Client sottomette le richieste mediante il Web Browser così come,
mediante quest'ultimo, ha la possibilità di ottenere risposte dal Web Server.
L'Application Server si occupa della logica applicativa. In particolare esso offre un
Pietro Neroni 566/2833 Pagina 40 di 117

ambiente per poter sviluppare ed eseguire applicazioni web che solitamente, come
pure nel nostro caso, sono three-tier e dove ciascun livello, come già detto
precedentemente, ha un compito ben preciso.
L'Application Server utilizzato è Tomcat[8]. Sia per la sua robustezza sia per il fatto
che risulta essere disponibile per Sistemi Operativi Windows e Linux, e sia perchè esso
è attualmente l'Application Server più diffuso.
A dire il vero, Tomcat è un Servlet Container ed un JSP Engine. E' quindi capace di
eseguire, lato server, applicazoni web basate su tecnologia J2EE e costituite da
componenti Servlet e da pagine JSP.
L'applicazione Web è stata sviluppata secondo il paradigma MVC(Model-View-
Control), traendo così i vantaggi insiti in esso. Questo Design Pattern è una linea guida
per la suddivisione delle responsabilità fra le diverse classi che compongono
l'applicazione web. Seguendo tale Design Pattern, infatti, l'applicazione viene
suddivisa in tre componenti principali:
• model: rappresenta le classi che si interessano dei dati nudi e crudi;
• view : è la porzione dell'applicazione dedicata alla rappresentazione dei dati.
Qui sono presenti le classi che, a partire dai dati contenuti nel “model”, offrono una
presentazione della pagina all'utente;
• controller: questa categoria di classi si interessa dell'interazione con l'utente.
Tenendo presente il pattern Observer, il paradigma MVC prevede che le classi
controller siano degli “Observer” che ricevono comandi(eventi) dall'utente e allo
stesso modo, le view siano degli “Observer” delle classi model.
Pietro Neroni 566/2833 Pagina 41 di 117

Figura 20: Architettura dell'applicazione utilizzando il paradigma MVC
Sviluppando in tal modo l'applicazione, le richieste poste dall'utente saranno gestite
dalla servlet(controller), la quale provvederà a istanziare una classe che si occupa
della gestione dei dati(Model) che serviranno poi alle pagine html (View) per la
presentazione dei dati.
6.4 Interfaccia Utente
La pagina principale dell’applicazione, è composta da tre aree contestuali ognuna
contenente:
1) Un menu di scelta, dove è possibile navigare verso la pagina:
a) Principale
b) Di configurazione, vedi sezione Configurazione
c) Di impostazioni, vedi sezione Impostazioni
d) Di ricerca, vedi sezione Ricerca di un device
e) Di stato, vedi sezione Accensione e spegnimento
2) Una barra di ricerca dei nodi
3) Un’area contenuto dove viene visualizzato l’output della ricerca o della pagina
Pietro Neroni 566/2833 Pagina 42 di 117

cercata
La barra di ricerca veloce permette una rapida selezione dei nodi su cui operare. Sia
query la stringa scritta nella barra di ricerca rapida, la selezione da parte
dell’interfaccia avviene tramite il seguente filtraggio a priorità:
1. Se query corrisponde al nome di una farm, allora in risposta l’interfaccia visualizza
tutti i device della farm query.
2. Se query è il nome di un particolare device viene visualizzato esattamente il device
query.
3. Altrimenti vengono restituiti tutti i device del tipo query oppure con indirizzo query.
E’ possibile usare espressioni regolari per raffinare una selezione veloce (ad esempio
per selezionare tutti i device di tipo WN oppure SE è sufficiente scrivere “WN|SE” ).
Pietro Neroni 566/2833 Pagina 43 di 117

Figura 21: pagina di ricerca di un dispositivo SE
Una volta operata la ricerca veloce i risultati vengono riportati nell’area contenuto.
Le possibili operazioni su un particolare device riguardano:
1. Verifica dello stato (online, offline, grafico di utilizzo)
Ogni riga riporta un riepilogo delle informazioni salienti dei device selezionati. In
particolare viene visualizzato lo stato con l’orario in cui è avvenuto l’ultimo
controllo(ONLINE, OFFLINE, UNKNOWN), il tipo del device e l’indirizzo.
Pietro Neroni 566/2833 Pagina 44 di 117

Cliccando inoltre sulla freccia a sinistra del nome di ogni device è possibile
visualizzare dei grafici di utilizzo di memoria e cpu .
2. Spegnimento
Cliccando sul link power-off (attivo solo se il device risulta acceso o in uno stato
sconosciuto) si procede allo spegnimento del device. Si rimanda alla sezione
spegnimento e accensione.
3. Accensione
Cliccando sul link power-on (attivo solo se il device risulta spento o in uno stato
sconosciuto) si procede all’accensione del device. Si rimanda per approfondimenti alla
sezione spegnimento e accensione.
4. Modifica dei parametri
Cliccando sul link edit si procede alla modifica dei parametri del particolare device. Si
rimanda alla sezione configurazione per approfondimenti
5. Ganglia e Nagios
Il sistema prevede l’integrazione con altre utility di monitoraggio ad esempio Ganglia
e Nagios, cliccando sui link si è direzionati verso le rispettive pagine di configurazione
di quel particolare nodo.
Figura 22: Grafici di utilizzo del dispositivo atlasse01.na.infn.it
Pietro Neroni 566/2833 Pagina 45 di 117

Impostazioni
Da questa pagina è possibile aggiornare il database in memoria dei nodi. La base
di dati dell’interfaccia è implementata mediante file di dati scritti in linguaggio XML.
Cliccando sul bottone validate disponibile nella pagina Settings è possibile registrare
in memoria gli eventuali cambiamenti apportati ai file tramite editing manuale.
Figura 23: Pagina impostazioni
Ricerca di un device
Oltre alla ricerca rapida l’interfaccia dispone di una ricerca avanzata richiamabile
mediante il tasto search del menu principale. La ricerca è strutturata nel modo riportato
in figura 24.
Pietro Neroni 566/2833 Pagina 46 di 117

Figura 24: pagina di ricerca avanzata
Ricerca Avanzata
E’ possibile fissare i seguenti criteri nel filtro di ricerca:
• Farm di appartenenza
• Tipo del device
• Intervallo di indirizzi
• Nome del device
• Stato del device (online, offline), utile per visualizzare tutti e soli i device spenti o
accesi.
La selezione avviene tramite congiunzione dei succitati parametri.
Spegnimento e accensione
Scopo principale dell’applicazione è spegnere o accendere un particolare device (o
insieme di device) rispettando le dipendenze di spegnimento o accensione.
Per effettuare un operazione di spegnimento (accensione) è necessario:
1. Individuare i nodi su cui operare, utilizzando la ricerca rapida o avanzata descritte
in precedenza.
2. Confermare la selezione tramite l’abilitazione dei checkbox di ciascuna riga dei
Pietro Neroni 566/2833 Pagina 47 di 117

device.
3. Selezionare l’opzione power off (power on) selected.
4. Cliccare sul tasto proceed che appare dopo il riepilogo dei nodi da spegnere
(accendere), vedi figura 25.
5.Verificare i risultati nella pagina di stato Power, vedi figura 26.
Figura 25: pagina di riepilogo
Pietro Neroni 566/2833 Pagina 48 di 117

Figura 26: pagina di stato
La pagina di stato, vedi figura 26, mostra un riepilogo delle azioni che lo script di
sistema
effettua per portare a termine l’operazione prevista.
Esistono due aree:
• Power.
Nell’area power è possibile avere un resoconto di tutte le operazioni richieste tramite
Pietro Neroni 566/2833 Pagina 49 di 117

l’interfaccia. Il sistema prevede una coda con politica di scheduling di tipo FIFO. E’
possibile interrompere o invertire qualunque processo in esecuzione mediante il link
alla colonna kill e revert rispettivamente.
• Log history
Nella sezione log history è riportato il log delle azioni svolte dallo script di sistema.
L’area si auto aggiorna ogni 5 secondi.
6.5 Visualizzazione del grafo delle dipendenze
Per comprendere meglio le dipendenze fra i dispositivi, è stato realizzato per
Powerfarm un directed acyclic graf (DAG), dei dispositivi dove ogni nodo
rappresenta un dispositivo o un insieme di dispositivi gestiti da Powerfarm, e gli archi
rappresentano le dipendenze tra i dispositivi.
Ogni dispositivo puo avere qualsiasi dipendenza con altri dispositivi, l'unica regola da
tener conto e di evitare di formare cicli nel grafico.
Un esempio di grafo delle dipendenze, applicato alla farm del Tier2-ATLAS è il
seguente, formato da due parti indipenenti, una relativa allo storage e la seconda alle
risorse di calcolo
Pietro Neroni 566/2833 Pagina 50 di 117

Figura 27: Grafo delle dipendenze
Questo grafo viene creato dinamicamente, ogni volta si accede alla home page del sito
web, esaminando i file di configurazione che contengono le informazioni sui
dispositivi e sulle loro dipendenze.
Ogni nodo del grafo ha un colore a seconda del tipo di dispositivo che
rappresenta.Inoltre i dispositivi che sono dello stesso tipo ed hanno le stesse
dipendenze logiche, vengono raggruppati, in un unico nodo del grafo.
Come precedentemente accennato, il grafico rappresenta le dipendenze di accensione e
spegnimento e la priorita tra i vari dispositivi gestiti, che provengono dai vincoli logici
dei dispositivi, come il ruolo che ciascun dispositivo svolge nella farm.
Powerfarm non fa nessuna distinzione tra le varie dipendenze ma li tratta tutti allo
stesso modo perche non sono altro che dipendenze che devono essere eseguite per
identificare i dispositivi che devono essere accesi o spenti e il loro ordine.
L'operazione di accensione o spegnimento puo essere eseguita su un unico dispositivo,
su un tipo di di dispositivo (ad esempio tutti i worker node o tutti gli storage element,
etc.), un elenco specifico di dispositivi (esempio: uno o piu specifici worker node e/o
uno o piu specifici storage element, etc.), l'intera farm, tutto cio che e collegato ad un
dispositivo (ad esempio tutti i dispositivi appartenenti ad un rack).
In tale struttura stratificata ad albero, ad ogni livello ci possono essere dispositivi che
hanno dipendenze tra di loro e quindi possono essere risolte contemporaneamente,
Pietro Neroni 566/2833 Pagina 51 di 117

identificando cosi uno strato comune di esecuzione chiamato dipendenza di strato,
oppure dispositivi che non hanno dipendenze tra di loro.
Da notare che nella dipendenza di strato si possono avere anche diversi tipi di
dispositivi e questo e tutto normale e serve a ottimizzare il processo di
parallelizzazione delle operazioni sui dispositivi.
Per poter effettuare un'operazione di accensione dei vari dispositivi tenendo conto
delle dipendenze si agisce all'alto verso il basso secondo il modello top-down, mentre
per poter effettuare un'operazione di spegnimento si agisce dal basso verso l'alto
secondo il modello bottom-up.
Le modalita di funzionamento rispettando le dipendenze sono tre e sono l'accensione,
l'accensione in modo ricorsivo, e lo spegnimento.
• Accensione
Vediamo come si effettua l'accensione, ad esempio, del dispositivo SE08, che
corrisponde ad uno Storage Element: tenendo conto del grafo, si agisce dall'alto verso
il basso accendendo prima il controller e4_03a e la sua espansione , e dopo aver
constatato che questi si sono accesi correttamente si passa all'accensione dello storage
element SE08
Figura 28: Accensione del storage element SE08
• Accensione ricorsiva
Per poter effettuare Accensione ricorsiva (figura 29) si attivano non solo i nodi come
nella procedura normale di accensione ma anche tutti i dispositivi che stanno sotto e
che hanno un percorso di dipendenze con il dispositivo che deve essere acceso. Nel
nostro caso quindi, oltre ad affettuare l'accensione delle espansioni del controller, del
Pietro Neroni 566/2833 Pagina 52 di 117

controller e dello storage element, verrà acceso pure il Dpm che sta al di sotto di esso.
Figura 29: accensione ricorsiva dello storage element SE08
• Spegnimento
Per poter effettuare lo Spegnimento (figura 30) si agisce dal basso verso l'alto
partendo dalle foglie che hanno dipendenze con il dispositivo da spegnere. Infatti per
spegnere CE01 si da parte tutti i WN e dopo che tutti sono spenti si effettua lo
spegnimento del CE1 Il grafo rappresenta le dipendenze di accensione , se lo si guarda
da basso verso l'alto, e di spegnimento , se lo si guarda dall'alto verso il basso.
Pietro Neroni 566/2833 Pagina 53 di 117

Figura 30: Spegnimento del computing element CE01
Per avere maggiori informazioni su un dispositivo o su un gruppo di dispositivi si può
cliccare su un corrispondente nodo e si verrà indirizzati ad una pagina che per il
dispositivo scelto conterrà:
il suo indirizzo IP
la sua descrizione
un link alla sua pagina di configurazione dove si possono cambiare gli attributi del
dispositivo i link alle pagine di monitoraggio Ganglia e Nagios del dispositivo
Pietro Neroni 566/2833 Pagina 54 di 117

Figura 31: Click di un nodo dal grafo delle dipendenze
DETTAGLI IMPLEMENTATIVI
Per visualizzare il grafo delle dipendenze logiche, si è utilizzato Webdot, uno script
lato server che utilizza un file DOT contenente la descrizione testuale di un grafo e la
trasforma in un immagine di formato selezionabile(come ad esempio bmp,gif, png,
jpg, ps, ecc...). Nel nostro caso, poiché viene richiesto che ogni nodo del grafo sia
cliccabile l'immagine sarà una mappa cliccabile lato server dove ad ogni nodo del
grafo gli sarà associato un url che corrisponde alla sua pagina di configurazione.
Pietro Neroni 566/2833 Pagina 55 di 117

La descrizione testuale del grafo viene creata da una classe Java ,nei seguenti passi:
• viene estratto l'elemento che contiene la dipendenza tra i dispositivi nel file
dependencies.xml, che ha i due attributi source e target. Se rappresenta una
dipendenza fisica, la ignora e passa al prossimo elemento.
• Si va a leggere il tipo dei due dispositivi che compongono la dipendenza dal file
di configurazione device.xml, a seconda del tipo il dispositivo viene
rappresentato nel grafo con un colore diverso
• Si controlla nel file di configurazione set.xml se uno dei due dispositivi o
entrambi fanno parte di un insieme di dispositivi. In questo caso il dispositivo
verrà sostituito dal suo insieme
• Infine viene scritta la dipendenza nel file DOT e i due dispositivi ( o insiemi di
dispositivi) con i loro attributi (colore e URL)
Per ottenere informazioni sui file di configurazione viene fatto il parsing dei
documenti xml. Il parsing di documenti xml in Java, passa principalmente attraverso
due famiglie di API: DOM e SAX[9]. Si è utilizzato l'approccio DOM che consiste nel
caricare in memoria tutto l'albero del documento xml e su di esso potrà essere scelto
un algoritmo di esplorazione. In questa struttura ogni elemento del documento xml
diventa un nodo dell'albero rappresentato da una classe che implementa l'interfaccia
org.w3c.dom.Node. Questa interfaccia fornisce metodi per esplorare o modificare
l'albero e per conoscere le proprietà di ogni nodo.
6.6 Inserimento, modifica, eliminazione di un dispositivo
La pagina di Configurazione, che permette impostare l'intero sistema, è stata per molti
aspetti modificata e migliorata.
Si è introdotto un meccanismo che associa automaticamente il tipo del dispositivo
introdotto con i plugin necessari per la sua gestione.
Dopodiche sono stati inseriti dei controlli sui campi obbligatori e sull'indirizzo IP che
deve essere del tipo x.x.x.x con 0≤x≤255 .
Infine si è curata la parte che riguarda la gestione delle dipendenze, permettendo di
visualizzare il grafo delle dipendenze considerando anche il nuovo dispositivo, e
inserendo il controllo per non assegnare al dispositivo delle dipendenze che causano
cicli all'interno del grafo. Nel seguito del paragrafo descriveremo in maniera più
dettagliata queste funzionalità.
Pietro Neroni 566/2833 Pagina 56 di 117

Tramite la pagina Configurazione è possibile:
1. Aggiungere una nuova risorsa da monitorare e/o gestire
2. Modificare i parametri di un device presente nel sistema, selezionando la voce e
3. Eliminare un device dal sistema
Aggiunta di un nuovo device
Per aggiungere una nuova risorsa da monitorare è sufficiente cliccare sul tasto
Configure dal menu di scelta in alto sulla pagina principale.
Descriviamo in dettaglio la pagina relativa all'inserimento di un dispositivo:
Figura 32: Pagina di inserimento di un nuovo dispositivo
Pietro Neroni 566/2833 Pagina 57 di 117

La pagina relativa all'aggiunta di un dispositivo , è una pagina JSP ed ha i seguenti
campi:
1) Il nome univoco del device, nel campo name (obbligatorio)
2) La farm a cui il device appartiene, nel campo farm (facoltativo)
3) Indirizzo IP del device, nel campo IP (obbligatorio)
4) Il tipo del device (es. WN, SE, UPS, ecc.), nel campo type (facoltativo)
5)L'insieme a cui appartiene, se fa parte di un insieme di dispositivi
6) I valori dei parametri lock on e lock off, nei rispettivi campi (obbligatorio).
7) La conferma di abilitazione del device quando selezionato, nel campo select on
search. Quando è attiva questa opzione seleziona automaticamente il campo select
della riga corrispondente al device quando questo viene visualizzato in seguito ad una
ricerca.
8) Il percorso assoluto del plugin di accensione del device, con i relativi argomenti,
descrizione e timeout nel campo power on (facoltativo).
9) Il percorso assoluto del plugin di spegnimento software del device, con i relativi
argomenti , descrizione e timeout nel campo power off-soft (facoltativo).
10) Il percorso assoluto del plugin di spegnimento hardware del device, con i relativi
argomenti , descrizione e timeout nel campo power off-hard (facoltativo).
11) Il percorso assoluto del plugin di controllo stato online del device, con i relativi
argomenti , descrizione e timeout nel campo check-on (facoltativo).
12) Il percorso assoluto del plugin di controllo stato offline del device, con i relativi
argomenti , descrizione e timeout nel campo check-off (facoltativo).
13) Il percorso del link alla pagina di Nagios del particolare device visualizzato nella
finestra di riepilogo, nel campo link nagios (facoltativo).
14) Il percorso del link alla pagina di Ganglia del particolare device visualizzato
nella finestra di riepilogo, nel campo link ganglia (facoltativo).
15) Il percorso del primo dei due grafici visualizzati nella riga di riepilogo del device
nell’area di selezione, nel campo image report left (facoltativo).
16) Il percorso del secondo dei due grafici visualizzati nella riga di riepilogo del
device nell’area di selezione, nel campo image report right (facoltativo).
17) Le dipendenze di spegnimento, ovvero tutti i nodi che è necessario spegnere
prima del device in considerazione, nel campo dependencies (facoltativo).
Una volta che si è provveduto a riempire tutti i campi obbligatori è sufficiente cliccare
sulbottone add per inserire il nodo appena configurato.
Il controllo sui campi obbligatori viene fatto da uno script lato client che controlla se è
stato inserito un nome al dispositivo e se è stato inserito un indirizzo IP corretto
Quando viene selezionato il tipo del dispositivo, uno script lato client cercherà in un
Pietro Neroni 566/2833 Pagina 58 di 117

file xml (plugin.xml) gli ultimi plugin che erano stati associati a quel tipo, e se li trova
li mette automaticamente nei campi plugin.
Figura 33: Inserimento automatico dei plugin in base al tipo
L'utente ha anche la possibilità di associare dei plugin ad un nuovo tipo di dispositivo.
Infatti creando un nuovo tipo l'utente può assegnare dei plugin che verranno ricordati
ogniqualvolta si tenti di aggiungere un dispositivo dello stesso tipo.
Affianco ai plugin on, off-soft, off-hard c'è il pulsante exec che quando viene cliccato
apre una finestra di popup dove viene eseguito il plugin presente nel campo plugin e
con gli argomenti presenti nel campo args.
Figura 34: Esecuzione di un plugin tramite il tasto exec
Pietro Neroni 566/2833 Pagina 59 di 117

Affianco al campo che contiene le dipendenze del dispositivo, c'è il pulsante grafo.
Se i clicchiamo si apre una pagina di popoup dove viene creato il grafo delle
dipendenze relativo al nuovo dispositivo e alle sue dipendenze attualmente assegnate.
Questo è molto utile perché si può notare come l'inserimento del dispositivo con le
dipendenze assegnate possa influenzare altri dispositivi della farm.
Figura 35: Finestra pop-up per la visualizzazione del grafo delle dipendenze con
l'inserimento del worker node nuovo_wn
DETTAGLI IMPLEMENTATIVI
Per inserire i plugin in modo automatico a seconda del tipo selezionato si deve leggere
il file plugins.xml. Si è utilizzata quindi una funzione javascript che fa uso
dell'oggetto XMLHttpRequest, oggetto che varia a seconda del browser che stiamo
utilizzando per visualizzare la pagina. Questo oggetto è parte di un ActiveX e quindi
esposto maggiormente a restrizioni sulla configurazione del browser dell’utente, ed è
supportato, seppur manualmente, da versioni obsolete dei più comuni browser in
circolazione. Grazie a quest'oggetto possiamo caricare il documento xml in una
variabile javascript ed ottenere informazioni su di esso tramite il metodo
getElementByTagName.
Pietro Neroni 566/2833 Pagina 60 di 117

Per quel che riguarda l'esecuzione di uno specifico plugin tramite il tasto “exec”
oppure la visualizzazione del grafo delle dipendenze per quel dispositivo, è stata
utilizzata la funzione window.open di Javascript che ci permette di aprire finestre
personalizzabili. Essa accetta tre parametri: un percorso (relativo o assoluto) di un
pagina html, il nome della finestra (opzionale), lo stile che specifica la forma, la
dimensione e la posizione della finestra, se la finestra non sia ridimensionale, o che
non ci siano le barre degli strumenti e le barre di scorrimento.
Modifica di un device esistente
Per modificare la configurazione di un device esistente è necessario selezionare il
device tramite la barra di ricerca veloce o avanzata e cliccare sul link edit nella riga
corrispondente. Il sistema fornirà una pagina dove è possibile modificare i parametri
del device (eccetto il nome) secondo quanto scritto nella seziona aggiunta di un nuovo
device.
Pietro Neroni 566/2833 Pagina 61 di 117

Eliminazione di un device esistente
Per eliminare un device è sufficiente accedere alla sua pagina di configurazione, come
visto in precedenza, cliccare sul pulsante delete e confermare.
Figura 36: Eliminazione del computing element atlasce01.na.infn.it
Pietro Neroni 566/2833 Pagina 62 di 117

6.7 Diagrammi di Cockburn
a) Aggiunta di un dispositivo
Use case #1
Obiettivo nel
contesto
Precondizioni
Condizione finale
di successo
Condizione finale
di fallimento
Attore primario
Condizione di
inizio
Aggiungi dispositivo
Aggiungere un dispositivo che verrà gestito con Powerfarm
L'utente ha effettuato il login
Il dispositivo è stato aggiunto
Il dispositivo non è stato aggiunto
Utente
L'utente seleziona il pulsante “Configure”
Descrizione Step Utente Sistema
Extension 1:
L'utente non ha
inserito nulla nei
campi obbligatori
Extension 2:
E' stato inserito un
indirizzo IP del
dispositivo non
valido
1 Azione Trigger
2 Richiede all'utente di
inserire le informazioni
riguardanti il dispositivo
3 Inserisce i dati del dispositivo e clicca sul
pulsante “add”
4 Conferma i dati inseriti
dall'utente. Registra il
nuovo dispositivo e
mostra i suoi dati
Step Utente non identificato
Sistema
4.a Mostra un messaggio
d'errore “Inserire Campi
Obbligatori”
Step Utente non identificato
Sistema
4.b Mostra un messaggio
d'errore “Indirizzo IP non
valido”
Pietro Neroni 566/2833 Pagina 63 di 117

Extension 3:
E' stata aggiunta
una dipendenza
che provoca cicli
all'interno del
grafo delle
dipendenze
4.c Mostra un messaggio
d'errore “Impossibile
aggiungere le seguenti
dipendenze” con la lista
delle dipendenze non
valide
b) Eliminazione di un dispositivo
Use case #1
Obiettivo nel
contesto
Precondizioni
Condizione finale
di successo
Condizione finale
di fallimento
Attore primario
Condizione di
inizio
Elimina Dispositivo
Elimina il dispositivo scelto
L'utente ha effettuato il login
Il dispositivo è stato eliminato
Il dispositivo non è stato eliminato
Utente
L'utente seleziona il pulsante “edit” accanto al dispositivo
Descrizione Step Utente Sistema
1 Azione Trigger
2 Mostra le informazioni
relativi al dispositivo
3 Seleziona il pulsante “delete”
4 Chiede all'utente di
confermare l'eliminazione
del dispositivo
5 Conferma l'eliminazione del dispositivo
6 Elimina il dispositivo e
ritorna alla pagina di
configurazione
Extension 1: Step Utente non identificato Sistema
Pietro Neroni 566/2833 Pagina 64 di 117

6.a Mostra un messaggio
d'errore “Impossibile
eliminare il dispositivo”
Pietro Neroni 566/2833 Pagina 65 di 117

6.8 Class Diagram
Figura 37: class diagram relativo alla pagina di configurazione
Pietro Neroni 566/2833 Pagina 66 di 117

6.9 Sequence Diagram
Sequence Aggiungi dispositivi
Figura 38: Sequence diagram per l'inserimento del dispositivo
Pietro Neroni 566/2833 Pagina 67 di 117

Figura 39: continuo del sequence diagram per l'inserimento del dispositivo
Pietro Neroni 566/2833 Pagina 68 di 117

Sequence Elimina Dispositivo
Figura 40: Sequence diagram relativo all'eliminazione di un dispositivo
Pietro Neroni 566/2833 Pagina 69 di 117

Sequence Visualizza grafo delle dipendenze
Figura 41: Sequence diagram relativo alla visualizzazione del grafo delle
dipendenze
Pietro Neroni 566/2833 Pagina 70 di 117

7 VALIDAZIONE E TESTING
Al termine della fase di progettazione sono stati effettuati dei test sull'applicazione.La
prima funzionalità che è stata testata è quella relativa all'inserimento di un dispositivo
omettendo i campi obbligatori (nome e indirizzo IP). Ciò che è stato ottenuto è un
messaggio d'errore che ci avvisa che i campi obbligatori non sono stati inseriti.
Figura 42: Messaggi d'errore per il mancato
inserimento dei campi obbligatori
Pietro Neroni 566/2833 Pagina 71 di 117

Si è cercato poi di inserire un indirizzo IP non valido ed è stato ottenuto il seguente
messaggio
Figura 43: Messaggio d'errore per l'inserimento di un
indirizzo IP non valido
Si è poi testato il caso in cui durante l'inserimento del dispositivo, si sia provato a
visualizzare il grafo con le dipendenze assegnate a quel dispositivo,senza che sia stata
inserita una dipendenza. Sono stati ottenuti i seguenti messaggi d'errore
Pietro Neroni 566/2833 Pagina 72 di 117

Infine è stato inserito un dispositivo con delle dipendenze che provocassero dei cicli
nel grafo delle dipendenze.Nel nostro caso si è provato ad assegnare allo storage
element SE08 la dipendenza con il controller e4_03a e una delle sue espansioni, questo
come possiamo vedere dalla figura 44 genera dei cicli all'interno del grafo delle
dipendenze.
Figura 44: Assegnazione di dipendenze che causano cicli
Figura 45: Visualizzazione del grado con delle dipendenze cicliche
Pietro Neroni 566/2833 Pagina 73 di 117

Perciò le dipendenze non saranno assegnate e verrà mostrata la seguente pagina:
Figura 46: Pagina di confugurazione del dispositivo atlasse08.na.infn.it dopo l'assegnazione
di dipendenze cicliche
Pietro Neroni 566/2833 Pagina 74 di 117

8 CONCLUSIONI E SVILUPPI FUTURI
In conclusione, l'interfaccia web di Powerfarm consente agli amministratori del sito
non solo di creare la struttura della farm, ma anche di spegnere o accendere un
determinato dispositivo, un insieme di dispositivi, o tutta la farm.
Attualmente, Powerfarm gestisce i dispositivi che fanno parte del Data Center Tier2
del progetto ATLAS.
La configurazione di un dispositivo tramite l'interfaccia web di Powefarm permette di
evitare errori che invece potrebbero capitare tramite l'inserimento manuale di un
dispositivo, quali:
• avere un dispositivo senza nome o senza indirizzo IP oppure con uno non valido
• un dispositivo con dei plugin non adeguati al suo tipo oppure con un percorso
all'interno del file system errato.
• grazie al controllo delle dipendenze hardware e software al momento della
configurazione del dispositivo, saranno create delle farm che non conterranno
delle dipendenze cicliche.
Inoltre grazie al grafo delle dipendenze logiche sviluppato, si riesce di avere una
visione complessiva del sistema che prima mancava completamente e allo stesso
tempo permette di accedere facilmente ai dettagli dei dispositivi, facilitando ogni
operazione che si vuole compiere.
In futuro si prevede l'inserimento di una nuova farm da gestire tramite Powefarm,
magari facendo condividere uno o più dispositivi tra le varie farm.
Un ulteriore possibile estensione potrebbe riguardare l'inserimento del modulo per la
gestione delle emergenze nell'interfaccia web.
Pietro Neroni 566/2833 Pagina 75 di 117

9 BIBLIOGRAFIA
[1] Alessandra Doria Atlas Calcolo 2003
[2] Grid computing - URL: http://it.wikipedia.org/wiki/Grid_computing
[3] Powerfarm: Power and Emergency Management Thread-based Software System
for Grid and Data Center Infrastructures - S. Ricciardi, S. Iengo, M.Staffa, A.Doria, G.
Carlino, L.Merola
[4] Java: http://www.java.sun.com.
[5] Xml.com: http://www.xml.com.
[6] JavaServer Pages (JSP) Prof.ssa Anna Corazza
http://people.na.infn.it/~corazza/didattica
[7] Drawing graphs with dot ,Emden R. Gansner and Eleftherios Koutsofios and
Stephen North December 22, 2009 http://www.graphviz.org/pdf/dotguide.pdf
[8] Apache Software Foundation:http://www.apache.org.
[9] Tomcat:http://jakarta.apache.org/tomcat/index.html.
[10]The Java Api for XML Parsing (JAXP) Tutorial:
http://www.java.sun.com/xml/tutorial_intro.html.
[11]Sara Eusebio, Sylvain Féjoz., Atlas Collaboration Records,
http://library.web.cern.ch/library/Archives/isad/isaatlas.html
Pietro Neroni 566/2833 Pagina 76 di 117

10 APPENDICE
10.1 L'esperimento ATLAS
Atlas ,acronimo di A Toroidal LHCApparatuS , è un rilevatore di particelle .
Insieme ad altri 4 rilevatori ( ALICE, TOTEM, CMS, LHCb) fa parte della catena di
accellerazione collegata all'accelleratore di particelle LHC (Large Hadron Collider)
del CERN di Ginevra.All'esperimento prendono parte 165 istituti distribuiti su 35
nazioni, composti da scienziati e ingegneri.
Lo scopo del progetto ATLAS è quello di osservare fenomeni che riguardano particelle
pesanti che non sono mai state studiate utilizzando gli accelleratori a bassa energia,
con l'obiettivo di far luce su nuove teorie della fisica delle particelle oltre il modello
standard[11].
Infatti uno dei principali obiettivi di ATLAS è quello di investigare sull'ultimo pezzo
del Modello Standard, il Bosone di Higgs.
Il Bosone di Higgs è la particella ipotizzata dal fisico scozzese Peter Higgs per
spiegare la differenza di massa tra fotoni e bosoni vettori W e Z, il bosone di Higgs
interagirebbe insieme alle altre particelle determinandone la massa.
L'obiettivo di un rilevatore di particelle è osservare il comportamento delle particelle
prodotte da un acceleratore di particelle. Non basta quindi produrre particelle come i
Pietro Neroni 566/2833 Pagina 77 di 117

protoni per rivelare tutti i fenomeni legati ad essi, ed alle loro interazioni, ma sono
necessari i rilevatori per analizzare le particelle, la loro massa, quantità di moto,
energie, cariche e spin nucleari.
Per individuare tutte le particelle prodotte nel punto di interazione quando i raggi di
particelle collidono, i rivelatori solitamente sono progettati con una struttura “a
cipolla” .
Gli strati sono composti da rivelatori di vari tipi, e ciascuno studia uno specifico tipo di
particelle. Le diverse reazioni che le particelle causano in ogni strato, consentono la
loro identificazione e la misura della quantità di moto delle energie.
Più l'energia delle particelle prodotte aumenta, più il corrispondente rivelatore deve
crescere in dimensioni per fermare effettivamente e misurare particelle più
energetiche.
Attualmente ATLAS è il più grande rivelatore di particelle mai costruito presso un
collider.
Il rivelatore ATLAS è composto da una serie di cilindri concentrati intorno al punto di
interazione, dove si svolge lo scontro fra i fasci di protoni uscenti da LHC, che si può
dividere in quattro parti principali:
– rivelatore interno
Pietro Neroni 566/2833 Pagina 78 di 117

– calorimetri
– spettrometri muonici
– sistema di magneti
Ciascuna di queste parti a sua volta si può dividere in diversi strati.
I rivelatori sono complementari: quello interno traccia precisamente le particelle, i
calorimetri misurano l'energia delle particelle più facili da fermare e lo spettrometro
muonico produce misure ulteriori sui muoni più penetranti.
Il sistema di magneti dirotta le particelle cariche nel rivelatore interno e nello
spettrometro muonico per permettere la misurazione della quantità di moto.
L'esperimento ATLAS sull'acceleratore di particelle LHC, farà scontrare protoni e
protoni ad altissima energia producendo particelle tra cui forse il Bosone di Higgs.
Questo non verrà svelato direttamente ma mediante i suoi prodotti di decadimento,
come quattro muoni energetici o attraverso lo studio delle violazioni della
conservazione della quantità di moto durante una collisione.
L'analisi dei dati raccolti ad LHC è oggi possibile solo tramite modelli di calcolo che
operano secondo il modello delle griglie computazionali.
10.2 Il codice
XMLDatabase.java
package powerfarm;
import java.io.*;
import java.util.*;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.OutputStream;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Hashtable;
import java.util.Iterator;
import java.util.List;
import java.util.Map;
import java.util.Map.Entry;
import java.util.Set;
import java.util.concurrent.locks.ReentrantLock;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
Pietro Neroni 566/2833 Pagina 79 di 117

import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathExpression;
import javax.xml.xpath.XPathFactory;
import org.apache.xml.serialize.OutputFormat;
import org.apache.xml.serialize.XMLSerializer;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.NamedNodeMap;
import org.w3c.dom.Node;
import org.w3c.dom.NodeList;
import org.xml.sax.ErrorHandler;
import org.xml.sax.SAXParseException;
/*
* Classe utilizzata dalla classe webpowerfam per la gestione dei file di configurazione
*/
public class XMLDatabase implements IDatabase, ErrorHandler
{
protected String basePath;
protected Document device;
protected Document dependency;
protected Document link;
protected Document set;
protected Document plugins;
protected File deviceFile;
protected File dependencyFile;
protected File linkFile;
protected File setFile;
protected File pluginsFile;
protected String deviceDtdFileName;
protected String dependencyDtdFileName;
protected String linkDtdFileName;
protected String setDtdFileName;
protected String pluginsDtdFileName;
protected TransformerFactory tranFact;
protected Transformer transfor;
protected DocumentBuilder builder;
protected String powerOffDependencyName;
protected String powerOnDependencyName;
protected boolean validated;
protected ReentrantLock mutex;
protected String error;
protected String deviceFileName;
protected String dependencyFileName;
protected String linkFileName;
protected String setFileName;
protected String pluginsFileName;
long deviceFileLastModify;
long dependencyFileLastModify;
long linkFileLastModify;
long setFileLastModify;
long pluginsFileLastModify;
/**
* Ritorna true se non sono state effettuate ultieriori modifiche dei file di configurazione
dall'ultimo reload
* @return boolean
*/
public boolean isUpdated()
{
try
{
return ((this.deviceFileLastModify >= new File(this.basePath +
this.deviceFileName).lastModified()) &&
Pietro Neroni 566/2833 Pagina 80 di 117

(this.dependencyFileLastModify >= new File(this.basePath +
this.dependencyFileName).lastModified()) &&
(this.linkFileLastModify >= new File(this.basePath +
this.linkFileName).lastModified())&&
(this.setFileLastModify >= new File(this.basePath +
this.setFileName).lastModified())&&
(this.pluginsFileLastModify >= new
File("/usr"+"/local"+"/tomcat"+"/webapps"+"/Webpowerfarm"+"/" +
this.pluginsFileName).lastModified()));
}
catch (Exception e) {
}
return false;
}
/**
* Aggiorna tutti i file di configurazione xml utilizzati da Powerfarm
* @throws Exception
* @return boolean
*/
public boolean reload() throws Exception
{
try {
this.deviceDtdFileName = this.deviceFileName.replaceFirst(".xml", ".dtd");
this.dependencyDtdFileName = this.dependencyFileName.replaceFirst(".xml", ".dtd");
this.linkDtdFileName = this.linkFileName.replaceFirst(".xml", ".dtd");
this.setDtdFileName = this.setFileName.replaceFirst(".xml", ".dtd");
this.pluginsDtdFileName = this.pluginsFileName.replaceFirst(".xml", ".dtd");
this.deviceFile = new File(this.basePath + this.deviceFileName);
this.dependencyFile = new File(this.basePath + this.dependencyFileName);
this.linkFile = new File(this.basePath + this.linkFileName);
this.setFile = new File(this.basePath + this.setFileName);
this.pluginsFile = new File("/usr"+"/local"+"/tomcat"+"/webapps"+ "/WebPowerfarm"
+"/"+ this.pluginsFileName);
this.deviceFileLastModify = this.deviceFile.lastModified();
this.dependencyFileLastModify = this.dependencyFile.lastModified();
this.linkFileLastModify = this.linkFile.lastModified();
this.setFileLastModify = this.setFile.lastModified();
this.pluginsFileLastModify = this.pluginsFile.lastModified();
this.device = this.builder.parse(this.deviceFile);
this.dependency = this.builder.parse(this.dependencyFile);
this.link = this.builder.parse(this.linkFile);
this.set = this.builder.parse(this.setFile);
this.plugins = this.builder.parse(this.pluginsFile);
return true;
}
catch (Exception e) {
throw e;
}
}
public XMLDatabase() throws Exception {
this("xml/");
}
public XMLDatabase (String xmlDirPath)
throws Exception
{
this.deviceFileName = "devices.xml";
this.dependencyFileName = "dependencies.xml";
this.linkFileName = "links.xml";
this.setFileName="set.xml";
Pietro Neroni 566/2833 Pagina 81 di 117

this.pluginsFileName="plugins.xml";
this.deviceFileLastModify = 0L; this.dependencyFileLastModify = 0L;
this.linkFileLastModify = 0L;
this.setFileLastModify=0L; this.pluginsFileLastModify=0L;
try
{
this.mutex = new ReentrantLock();
this.error = "";
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setValidating(true);
factory.setNamespaceAware(true);
this.builder = factory.newDocumentBuilder();
this.basePath = xmlDirPath + "/";
reload();
this.tranFact = TransformerFactory.newInstance();
this.transfor = this.tranFact.newTransformer();
this.transfor.setOutputProperty("omit-xml-declaration", "no");
this.transfor.setOutputProperty("encoding", "ISO-8859-1");
this.powerOnDependencyName = "power-on";
this.powerOffDependencyName = "power-off";
this.builder.setErrorHandler(this);
}
catch (Exception e) {
throw e;
}
}
/**
* Effettua tramite XPath la query contenuta nel parametro xq, sul DOM doc
* @param xq
* @param doc
* @return NodeList
*/
protected NodeList XPath(String xq, Document doc) {
try {
XPathFactory factory = XPathFactory.newInstance();
XPath xpath = factory.newXPath();
XPathExpression expr = xpath.compile(xq);
Object result = expr.evaluate(doc, XPathConstants.NODESET);
return ((NodeList)result);
}
catch (Exception e) {
}
return null;
}
/**
* Ritorna la lista di tutti i dispositivi presenti nel file device.xml
* @return NodeList
*/
protected NodeList selectNodes() {
return XPath("devices/device/@name", this.device); }
/**
* Ritorna la lista delle farm presenti nel file device.xml
* @return NodeList
*/
protected NodeList selectFarms() {
return XPath("devices/device/[@type=\"farm\"]", this.device); }
/**
* Ritorna l'elemento nel file device.xml che rappresenta il dispositivo name
* @param name
* @return NodeList
*/
protected NodeList selectNode(String name) {
return XPath("devices/device[@name=\"" + name + "\"]", this.device);
}
Pietro Neroni 566/2833 Pagina 82 di 117

**
* Ritorna la lista dei dispositivi presenti nel file di configurazione device.xml
* @return String[]
*/
public String[] getDevices()
{
ArrayList names = new ArrayList();
try {
NodeList nodes = this.device.getElementsByTagName("device");
for (int i = 0; i < nodes.getLength(); ++i) {
Element node = (Element)nodes.item(i);
if (!(node.getAttribute("type").toLowerCase().equals("farm")))
names.add(node.getAttribute("name"));
}
}
catch (Exception e) {
this.error = e.toString(); names.clear(); }
return ((String[])names.toArray(new String[0])); }
/**
* Ritorna la lista delle farm presenti nel file di configurazione device.xml
* @return String[]
*/
public String[] getFarms() {
ArrayList names = new ArrayList();
try {
NodeList nodes = this.device.getElementsByTagName("device");
for (int i = 0; i < nodes.getLength(); ++i) {
Element node = (Element)nodes.item(i);
if (node.getAttribute("type").toLowerCase().equals("farm"))
names.add(node.getAttribute("name"));
}
}
catch (Exception e) {
this.error = e.toString(); names.clear(); }
return ((String[])names.toArray(new String[0])); }
/**
* Ritorna la lista di dispositivi che appartengono alla farm farmName
* @param String farmName
* @return String[]
*/
public String[] getDevicesOfFarm(String farmName) {
ArrayList names = new ArrayList();
try {
NodeList nodes = XPath("dependencies/arc[@source=\"" + farmName +
"\"]/@target", this.dependency);
for (int i = 0; i < nodes.getLength(); ++i)
names.add(nodes.item(i).getNodeValue());
}
catch (Exception e) {
this.error = e.toString(); names.clear(); }
return ((String[])names.toArray(new String[0])); }
/**
* Ritorna il nome della farm a cui appartiene il dispositivo deviceName
* @param String deviceName
* @return String
*/
public String getFarmOfDevice(String deviceName) {
try {
NodeList nodes = XPath("dependencies/arc[@target=\"" + deviceName +
"\"]/@source", this.dependency);
for (int i = 0; i < nodes.getLength(); ++i) {
Node node = nodes.item(i);
if (Arrays.asList(getFarms()).contains(node.getNodeValue()))
Pietro Neroni 566/2833 Pagina 83 di 117

eturn node.getNodeValue();
}
}
catch (Exception e) {
this.error = e.toString(); }
return null;
}
/**
* Ritorna gli attributi presenti nel file di configurazione device.xml del dispositivo name
* @param String name
* @return Hashtable
*/
public Hashtable getAttributesOfDevice(String name) {
Hashtable attributes = new Hashtable();
try
{
NodeList nodes = selectNode(name);
if (nodes == null) {
return attributes;
}
Node node = nodes.item(0);
NamedNodeMap nodeMap = node.getAttributes();
for (int i = 0; i < nodeMap.getLength(); ++i)
attributes.put(nodeMap.item(i).getNodeName(),
nodeMap.item(i).getNodeValue());
}
catch (Exception e)
{
this.error = e.toString(); }
return attributes;
}
protected Hashtable getTagOf(String name, String query,
Document doc) {
Hashtable plugins = new Hashtable();
NodeList nodes = XPath(query, doc);
if (nodes == null) {
return plugins;
}
Node node = nodes.item(0);
for (int i = 0; i < node.getChildNodes().getLength(); ++i) {
Node child = node.getChildNodes().item(i);
if (child == null) {
continue;
}
NamedNodeMap nodeMap = child.getAttributes();
if (nodeMap == null) {
continue;
}
Hashtable attributes = new Hashtable();
for (int j = 0; j < nodeMap.getLength(); ++j) {
attributes.put(nodeMap.item(j).getNodeName(),
nodeMap.item(j).getNodeValue());
}
plugins.put(child.getNodeName(), attributes);
}
return plugins;
}
/**
* Effettua la serializzazione del DOM doc sul canale di uscita out
* @param doc
* @param out
* @throws Exception
*/
protected void serialize(Document doc, OutputStream out) throws Exception {
OutputFormat format = new OutputFormat(doc);
format.setLineWidth(100);
Pietro Neroni 566/2833 Pagina 84 di 117

format.setIndenting(true);
format.setIndent(2);
format.setPreserveEmptyAttributes(true);
XMLSerializer serializer = new XMLSerializer(out, format);
serializer.serialize(doc);
}
/**
* Effettua le modifiche sulla base DOM doc al file xmlFile
* @param doc
* @param xmlFile
* @param dtdFileName
* @return Document
*/
protected Document saveDocument(Document doc, File xmlFile, String dtdFileName) {
try {
this.mutex.lock();
File tmpFile = new File(xmlFile.getParentFile() + "/tmp.xml");
doc.normalize();
FileOutputStream tFos = new FileOutputStream(tmpFile);
serialize(doc, tFos);
tFos.close();
this.validated = true;
doc = this.builder.parse(tmpFile);
if (!(this.validated)) {
throw new Exception();
}
FileInputStream fis = new FileInputStream(tmpFile);
FileOutputStream fos = new FileOutputStream(xmlFile);
try {
byte[] buf = new byte[1024];
int i = 0;
while ((i = fis.read(buf)) != -1)
fos.write(buf, 0, i);
}
catch (Exception e)
{
throw e;
}
fis.close();
fos.close();
tmpFile.delete();
this.mutex.unlock();
}
catch (Exception e) {
this.mutex.unlock();
return null;
}
return doc;
}
/**
* Inserisce nel file di configurazione device.xml il dispositivo name
* @param String name
* @return boolean
*/
public boolean addDevice(String name) {
try {
if (this.device.getElementById(name) == null)
{Element node = this.device.createElement("device");
node.setAttribute("name", name);
node.setAttribute("type", "");
node.setAttribute("description", "");
node.setAttribute("address", "");
node.setAttribute("lock-on", "");
node.setAttribute("lock-off", "");
node.setAttribute("selected", "");
node.setIdAttribute("name", true);
Element actionElement = this.device.createElement("action");
Pietro Neroni 566/2833 Pagina 85 di 117

Element onElement = this.device.createElement("on");
onElement.setAttribute("plugin", "");
onElement.setAttribute("args", "");
onElement.setAttribute("description", "");
onElement.setAttribute("timeout", "");
Element offSoftElement = this.device.createElement("off-soft");
offSoftElement.setAttribute("plugin", "");
offSoftElement.setAttribute("args", "");
offSoftElement.setAttribute("description", "");
offSoftElement.setAttribute("timeout", "");
Element offHardElement = this.device.createElement("off-hard");
offHardElement.setAttribute("plugin", "");
offHardElement.setAttribute("args", "");
offHardElement.setAttribute("description", "");
Element checkOnElement = this.device.createElement("check-on");
checkOnElement.setAttribute("plugin", "");
checkOnElement.setAttribute("args", "");
checkOnElement.setAttribute("description", "");
Element checkOffElement = this.device.createElement("check-off");
checkOffElement.setAttribute("plugin", "");
checkOffElement.setAttribute("args", "");
checkOffElement.setAttribute("description", "");
actionElement.appendChild(onElement);
actionElement.appendChild(offSoftElement);
actionElement.appendChild(offHardElement);
actionElement.appendChild(checkOnElement);
actionElement.appendChild(checkOffElement);
node.appendChild(actionElement);
this.device.getLastChild().appendChild(node);
this.device.normalize();
Document tmp = saveDocument(this.device, this.deviceFile,
this.deviceDtdFileName);
if (tmp != null)
this.device = tmp;
else
return false;
}
}
catch (Exception e)
{return false;
}
return true;
}
/**
* Aggiorna nel file di configurazione device.xml l'elemento node con gli attributi attributes
* @param Element node
* @param Hashtable attributes
* @return boolean
*/
protected boolean updateAttributes(Element node, Hashtable attributes) {
while (node.getAttributes().getLength() > 0) {
node.removeAttribute(node.getAttributes().item(0).getNodeName());
}
for (Iterator it = attributes.entrySet().iterator(); it.hasNext(); ) {
Map.Entry entry = (Map.Entry)it.next();
node.setAttribute((String)entry.getKey(), (String)entry.getValue());
}
return true;
}
/**
* Inserisce nel file di configurazione device.xml gli attributi attributes del dispositivo
name
* @param String name
* @param Hashtable attributes
* @return boolean
*/
Pietro Neroni 566/2833 Pagina 86 di 117

public boolean setAttributesOfDevice(String name, Hashtable attributes)
{
try {
if (attributes == null) {
return false;
}
Element node = this.device.getElementById(name);
if (node == null) {
return false;
}
attributes.put("name", name);
updateAttributes(node, attributes);
Document tmp = saveDocument(this.device, this.deviceFile,
this.deviceDtdFileName);
if (tmp != null) {
this.device = tmp; return true;
}
return false;
}
catch (Exception e) {
return false;
}
}
protected boolean setNodeTag(String nodeName, String tagName, String tagSubName,
Hashtable attributes) {
boolean ret = true;
try {
Node root = this.device.getElementById(nodeName);
if (root != null) {
Node plugin = null;
NodeList select = XPath("devices/device[@name=\"" + nodeName + "\"]/" +
tagName, this.device);
if (select.getLength() == 0) {
plugin = this.device.createElement(tagName);
root.appendChild(plugin);
}
else {
plugin = select.item(0);
}
Node pluginSub = null;
select = XPath("devices/device[@name=\"" + nodeName + "\"]/" + tagName +
"/" + tagSubName, this.device);
if (select.getLength() == 0) {
pluginSub = this.device.createElement(tagSubName);
plugin.appendChild(pluginSub);
}
else
{pluginSub = select.item(0);
}
updateAttributes((Element)pluginSub, attributes);
}
else {
ret = false;
}
Document tmp = saveDocument(this.device, this.deviceFile,
this.deviceDtdFileName);
if (tmp != null) {
this.device = tmp; return ret;
}
return false;
}
catch (Exception e) {
return false;
}
}
/**
Pietro Neroni 566/2833 Pagina 87 di 117

* Inserisce nel file di configurazione dependences.xml la dipendenza che rappresenta
l'appartenenza del dispositivo deviceName alla farm farmName
* @param String farmName
* @param String deviceName
* @return boolean
*/
public boolean setFarmOfDevice(String farmName, String deviceName)
{
if (!(Arrays.asList(getDevices()).contains(deviceName))) {
return false;
}
if (!(Arrays.asList(getFarms()).contains(farmName))) {
addFarm(farmName);
}
String oldFarmName = getFarmOfDevice(deviceName);
if (farmName.equals(oldFarmName)) {
return true;
}
if ((oldFarmName != null) && (!(removeDeviceOfFarm(deviceName, oldFarmName)))) {
return false;
}
Element arcElement = this.dependency.createElement("arc");
if (arcElement == null) {
return false;
}
arcElement.setAttribute("source", farmName);
arcElement.setAttribute("target", deviceName);
this.dependency.getLastChild().appendChild(arcElement);
Document tmp = saveDocument(this.dependency, this.dependencyFile,
this.dependencyDtdFileName);
if (tmp != null)
this.dependency = tmp;
else {
return false;
}
return true;
}
/**
* Rimuove dal file di configurazione dependences.xml la dipendenza che rappresenta
l'appartenenza del dispositivo deviceName alla farm farmName
* @param String farmName
* @param String deviceName
* @return boolean
*/
public boolean removeDeviceOfFarm(String deviceName, String farmName)
{
String oldFarmName;
if ((!(Arrays.asList(getFarms()).contains(farmName))) ||
(!(Arrays.asList(getDevices()).contains(deviceName))) ||
((oldFarmName = getFarmOfDevice(deviceName)) == null))
{
return false;
}
NodeList nodes = XPath("dependencies/arc[@source=\"" + farmName + "\"][@target=\"" +
deviceName + "\"]", this.dependency);
if (nodes == null) {
return false;
}
Node arcElement = nodes.item(0);
arcElement.getParentNode().removeChild(arcElement);
Document tmp = saveDocument(this.dependency, this.dependencyFile,
this.dependencyDtdFileName);
if (tmp != null)
this.dependency = tmp;
else {
return false;
}
Pietro Neroni 566/2833 Pagina 88 di 117

nodes = XPath("dependencies/arc[@source=\"" + farmName + "\"]", this.dependency);
if (nodes.getLength() == 0) {
return removeFarm(farmName);
}
return true;
}
/**
* Rimuove dal file di configurazione device.xml il dispositivo deviceName
* @param String deviceName
* @return boolean
*/
public boolean removeDevice(String deviceName)
{
if (!(Arrays.asList(getDevices()).contains(deviceName))) {
return false;
}
boolean success = true;
String farm = getFarmOfDevice(deviceName);
if ((farm != null) && (!(farm.equals("")))) {
success = removeDeviceOfFarm(deviceName, farm);
}
success = removeDependenciesOfDevice(deviceName, true);
success = removeDependenciesOfDevice(deviceName, false);
Element deviceElement = this.device.getElementById(deviceName);
if (deviceElement == null) {
return false;
}
deviceElement.getParentNode().removeChild(deviceElement);
Document tmp = saveDocument(this.device, this.deviceFile, this.deviceDtdFileName);
if (tmp != null)
this.device = tmp;
else {
return false;
}
return true;
}
/**
* Rimuove dal file di configurazione device.xml il dispositivo farmName che rappresenta la
farm da eliminare
* @param String farmName
* @return boolean
*/
protected boolean removeFarm(String farmName)
{
if (!(Arrays.asList(getFarms()).contains(farmName))) {
return false;
}
Element deviceElement = this.device.getElementById(farmName);
if (deviceElement == null) {
return false;
}
deviceElement.getParentNode().removeChild(deviceElement);
Document tmp = saveDocument(this.device, this.deviceFile, this.deviceDtdFileName);
if (tmp != null)
this.device = tmp;
else {
return false;
}
return true;
}
/**
* Inserisce nel file di configurazione device.xml un dispositivo farmName che rappresenta la
nuova farm creata
* @param String farmName
* @return boolean
Pietro Neroni 566/2833 Pagina 89 di 117

*/
protected boolean addFarm(String farmName) {
try {
if (this.device.getElementById(farmName) == null)
{Element node = this.device.createElement("device");
node.setAttribute("name", farmName);
node.setAttribute("type", "farm");
node.setIdAttribute("name", true);
Element actionElement = this.device.createElement("action");
Element onElement = this.device.createElement("on");
onElement.setAttribute("plugin", "");
Element offSoftElement = this.device.createElement("off-soft");
offSoftElement.setAttribute("plugin", "");
Element offHardElement = this.device.createElement("off-hard");
offHardElement.setAttribute("plugin", "");
Element checkOnElement = this.device.createElement("check-on");
checkOnElement.setAttribute("plugin", "");
Element checkOffElement = this.device.createElement("check-off");
checkOffElement.setAttribute("plugin", "");
actionElement.appendChild(onElement);
actionElement.appendChild(offSoftElement);
actionElement.appendChild(offHardElement);
actionElement.appendChild(checkOnElement);
actionElement.appendChild(checkOffElement);
node.appendChild(actionElement);
this.device.getLastChild().appendChild(node);
this.device.normalize();
Document tmp = saveDocument(this.device, this.deviceFile,
this.deviceDtdFileName);
if (tmp != null)
this.device = tmp;
else
return false;
}
}
catch (Exception e) {
return false;
}
return true;
}
/**
* Restituisce tutte le dipendenze del dispositivo deviceName
* @param String deviceName
* @param boolean incoming
* @return String[]
*/
public String[] getDependenciesOfDevice(String deviceName, boolean incoming) {
ArrayList names = new ArrayList();
NodeList nodes = (incoming)
XPath("dependencies/arc[@target=\"" + deviceName + "\"]/@source",
this.dependency) :
XPath("dependencies/arc[@source=\"" + deviceName +
"\"]/@target", this.dependency);
for (int i = 0; i < nodes.getLength(); ++i) {
String dep = nodes.item(i).getNodeValue();
if (!(Arrays.asList(getFarms()).contains(dep)))
names.add(dep);
}
return ((String[])names.toArray(new String[0]));
}
protected String[] getAllDepthDependenciesOfDevice(String name, ArrayList reached,
boolean incoming) {
for (String child : getDependenciesOfDevice(name, incoming)) {
getAllDepthDependenciesOfDevice(child, reached, incoming);
}
reached.add(name);
Pietro Neroni 566/2833 Pagina 90 di 117

eturn ((String[])reached.toArray(new String[0])); }
public String[] getAllDepthDependenciesOfDevice(String name, boolean incoming) {
return getAllDepthDependenciesOfDevice(name, new ArrayList(), incoming); }
public String[] getAllDepthDependenciesOfDevice(String[] list, boolean incoming) {
ArrayList depList = new ArrayList();
for (String parent : list) {
for (String child : getAllDepthDependenciesOfDevice(parent, incoming)) {
if (!(depList.contains(child))) {
depList.add(child);
}
}
}
return ((String[])depList.toArray(new String[0])); }
public String[] getAllDepthDependenciesOfDevice(ArrayList list, boolean incoming) {
return getAllDepthDependenciesOfDevice((String[])list.toArray(new String[0]),
incoming);
}
/**
* Inserisce nel file di configurazione dependencies.xml tutte le dipendenze dependences del
dispositivo deviceName
* @param String deviceName
* @param String[] dependences
* @param boolean incoming
* @return boolean
*/
public boolean setDependenciesOfDevice(String deviceName, String[] dependencies, boolean
incoming) {
removeDependenciesOfDevice(deviceName, incoming);
for (String dep : dependencies) {
if (!(Arrays.asList(getDevices()).contains(dep))) {
this.error = "device '" + dep + "' not exists.";
return false;
}
}
Hashtable attributes = new Hashtable();
for (String dep : dependencies) {
Element newDep = this.dependency.createElement("arc");
if (!(incoming)) {
newDep.setAttribute("source", deviceName);
newDep.setAttribute("target", dep);
}
else {
newDep.setAttribute("source", deviceName);
newDep.setAttribute("target", dep);
}
this.dependency.getLastChild().appendChild(newDep);
}
Document tmp = saveDocument(this.dependency, this.dependencyFile,
this.dependencyDtdFileName);
if (tmp != null)
this.dependency = tmp;
else {
return false;
}
return true;
}
public boolean removeDependenciesOfDevice(String deviceName, boolean incoming)
{
if (!(Arrays.asList(getDevices()).contains(deviceName))) {
return false;
}
NodeList nodes = (incoming)
Pietro Neroni 566/2833 Pagina 91 di 117

XPath("dependencies/arc[@target=\"" + deviceName + "\"]",
this.dependency) :
XPath("dependencies/arc[@source=\"" + deviceName + "\"]",
this.dependency);
for (int i = 0; i < nodes.getLength(); ++i) {
Node node = nodes.item(i);
Node parent = node.getParentNode();
parent.removeChild(node);
}
Document tmp = saveDocument(this.dependency, this.dependencyFile,
this.dependencyDtdFileName);
if (tmp != null)
this.dependency = tmp;
else {
return false;
}
return true;
}
/**
* Restituisce una lista di plugin del dispositivo deviceName
* @param String deviceName
* @return String[]
*/
public String[] getActionsOfDevice(String deviceName) {
try {
Hashtable plugin = getTagOf(deviceName, "devices/device[@name=\"" + deviceName
+ "\"]/action", this.device);
return ((String[])plugin.keySet().toArray(new String[0]));
}
catch (Exception e) {
}
return new String[0];
}
/**
* Restituisce i link delle pagine di monitoraggio del dispositivo deviceName
* @param String deviceName
* @return String[]
*/
public String[] getLinksOfDevice(String deviceName)
{
try {
Hashtable plugin = getTagOf(deviceName, "links/link[@name=\"" + deviceName +
"\"]", this.link);
return ((String[])plugin.keySet().toArray(new String[0]));
}
catch (Exception e) {
}
return new String[0];
}
/**
* Restituisce gli attributi del plugin passato come argomento del dispositivo deviceName
* @param String deviceName
* @param String action
* @return Hashtable
*/
public Hashtable getActionAttributesOfDevice(String deviceName, String action)
{
try {
Hashtable plugin = getTagOf(deviceName, "devices/device[@name=\"" + deviceName
+ "\"]/action", this.device);
return ((Hashtable)plugin.get(action));
}
catch (Exception e) {
this.error = e.toString(); }
Pietro Neroni 566/2833 Pagina 92 di 117

eturn null;
}
/**
* Restituisce gli attributi del link passato come argomento del dispositivo deviceName
* @param String deviceName
* @param String link
* @return Hashtable
*/
public Hashtable getLinkAttributesOfDevice(String deviceName, String link)
{
try {
Hashtable plugin = getTagOf(deviceName, "links/link[@name=\"" + deviceName +
"\"]", this.link);
return ((Hashtable)plugin.get(link));
}
catch (Exception e) {
this.error = e.toString(); }
return null;
}
/**
* Imposta gli attributi del plugin passato come argomento del dispositivo deviceName
* @param String deviceName
* @param String action
* @param Hashtable attributes
* @return boolean
*/
public boolean setActionAttributesOfDevice(String deviceName, String action, Hashtable attributes)
{
try {
Node node = XPath("devices/device[@name=\"" + deviceName + "\"]/action/" +
action, this.device).item(0);
if (!(updateAttributes((Element)node, attributes))) {
return false;
}
Document tmp = saveDocument(this.device, this.deviceFile,
this.deviceDtdFileName);
if (tmp != null)
this.device = tmp;
else {
return false;
}
return true;
}
catch (Exception e) {
}
return false;
}
/**
* Imposta gli attributi del link passato come argomento del dispositivo deviceName
* @param String deviceName
* @param String link
* @param Hashtable attributes
* @return boolean
*/
public boolean setLinkAttributesOfDevice(String deviceName, String link, Hashtable attributes)
{
try {
if (XPath("links/link[@name=\"" + deviceName + "\"]", this.link).getLength() ==
0) {
Element linkElement = this.link.createElement("link");
linkElement.setAttribute("name", deviceName);
this.link.getLastChild().appendChild(linkElement);
Pietro Neroni 566/2833 Pagina 93 di 117

}
if (XPath("links/link[@name=\"" + deviceName + "\"]/" + link,
this.link).getLength() == 0) {
Element subLinkElement = this.link.createElement(link);
XPath("links/link[@name=\"" + deviceName + "\"]",
this.link).item(0).appendChild(subLinkElement);
}
Node node = XPath("links/link[@name=\"" + deviceName + "\"]/" + link,
this.link).item(0);
if (!(updateAttributes((Element)node, attributes))) {
return false;
}
Document tmp = saveDocument(this.link, this.linkFile, this.linkDtdFileName);
if (tmp != null)
this.link = tmp;
else {
return false;
}
return true;
}
catch (Exception e) {
}
return false;
}
public void fatalError(SAXParseException e) {
error(e); }
public void warning(SAXParseException e) { }
public void error(SAXParseException e) { this.error = e.toString(); this.validated = false; }
public String getLastErrorMessage() { return this.error;
}
/**
* Ritorna l'insieme del dispositivo passato come argomento
* @param String device
* @return String
*/
public String getSet(String device)
{
String tmp=null;
try {
NodeList nodes = this.set.getElementsByTagName("componente");
for (int i = 0; i < nodes.getLength(); ++i) {
Element node = (Element)nodes.item(i);
if(node.getAttribute("dispositivo").equals(device))
tmp=node.getAttribute("insieme");
}
}
catch (Exception e) {
this.error = e.toString(); }
return tmp;
}
/**
* Ritorna una lista di dispositivi dell'insieme passato come argomento
* @param String set
* @return ArrayList
*/
public ArrayList getDeviceofSet(String set) {
ArrayList risultato=new ArrayList();
try {
NodeList nodes = this.set.getElementsByTagName("componente");
for (int i = 0; i < nodes.getLength(); ++i) {
Element node = (Element)nodes.item(i);
if(node.getAttribute("insieme").equals(set))
Pietro Neroni 566/2833 Pagina 94 di 117

isultato.add(node.getAttribute("dispositivo"));
}
}
catch (Exception e) {
this.error = e.toString(); }
return risultato;
}
/**
* Inserisce nel file set.xml un nuovo elemento contenente il nome del dispositivo e l'insieme
a cui appartiene
* @param String dispositivo
* @param String insieme
* @return boolean
*/
public boolean setComponenteInsieme(String dispositivo, String insieme)
{
boolean trovato=false;
try {
NodeList nodes = this.set.getElementsByTagName("componente");
for (int i = 0; i < nodes.getLength(); ++i) {
Element node = (Element)nodes.item(i);
if(node.getAttribute("dispositivo").equals(dispositivo)) {
node.setAttribute("insieme", insieme);
trovato=true;
}
}
}
catch (Exception e) {
this.error = e.toString(); }
if(!trovato){
Element newComp = this.set.createElement("componente");
newComp.setAttribute("insieme", insieme);
newComp.setAttribute("dispositivo", dispositivo);
this.set.getLastChild().appendChild(newComp);
}
Document tmp = saveDocument(this.set, this.setFile, this.setDtdFileName);
if (tmp != null)
this.set = tmp;
else {
return false;
}
return true;
}
/**
* Crea un file in linguaggio DOT contenente la descrizione testuale del grafo delle dipendenze
logiche considerando anche il dispositivo passato come argomento e le sue dipendenze.
*/
public String creaGrafo(){
Map nodi=new HashMap();
Set archi=new HashSet();
String tmp=null;
String tmp1,tmp2,tmp5,tmp6,set , source_name,target_name, name_url;
String[]tmp3, tmp4, temp_set, tmp_url;
String target,target2,source, source2 = null;
FileOutputStream file2;
PrintStream Output = null;
//crea il file DOT
try {
file2 = new FileOutputStream("/usr/local/apache2/htdocs/webdot/grafo5.dot");
Output = new PrintStream(file2);
}
catch (IOException e) {
System.out.println("Errore: " + e);
System.exit(1);
}
Output.println("digraph mainmap {");
Pietro Neroni 566/2833 Pagina 95 di 117

NodeList nodes = this.dependency.getElementsByTagName("arc");
//legge le dipendenze tra i dispositivi nel file di configurazione dependences.xml
for (int i = 0; i < nodes.getLength(); ++i) {
Element node = (Element)nodes.item(i);
source=node.getAttribute("source");
target=node.getAttribute("target");
//se la dipendenza rappresenta una dipendenza fisica la ignora
if(target.equals("atlas")) continue;
else if(source.equals("atlas")) continue;
else if (target.contains("rack")) continue;
else if(source.contains("rack")) continue;
//modifica il nome dei dispositivi che rappresentano la dipendenza per rendere
il grafo più leggibile
source_name=getNameDevice(source);
target_name=getNameDevice(target);
tmp1= source.split(".na")[0];
tmp2=target.split(".na")[0];
tmp3=tmp1.split("atlas");
tmp4=tmp2.split("atlas");
if(tmp3.length>1) tmp5=tmp3[1] ;
else tmp5=tmp1 ;
if(tmp4.length>1) tmp6=tmp4[1];
else tmp6=tmp2 ;
//se uno dei due dispositivi fa parte di un insieme viene sostituito da
quest'ultimo
if (getSet(source)!=null) {
set=getSet(source);
set=set.split(".na")[0];
temp_set=set.split("atlas");
if(temp_set.length>1) set=temp_set[1];
source2="espansioni_"+set;
}
else source2=source_name;
if (getSet(target)!=null) {
set=getSet(target);
set=set.split(".na")[0];
temp_set=set.split("atlas");
if(temp_set.length>1) set=temp_set[1];
target2="espansioni_"+set;
}
else target2=target_name;
nodi.put(source2,getAttributesOfDevice(source).get("type"));
nodi.put(target2,getAttributesOfDevice(target).get("type"));
archi.add(source2.replace("-", "_")+"->"+target2.replace("-", "_"));
source=node.getAttribute("source");
target=node.getAttribute("target");
if (getSet(source)!=null) source2="espansioni_"+getSet(source);
else source2=source;
if (getSet(target)!=null) target2="espansioni_"+getSet(target);
else target2=target;
nodi.put(source2,getAttributesOfDevice(source).get("type"));
nodi.put(target2,getAttributesOfDevice(target).get("type"));
archi.add(source2.replace("-", "_")+"->"+target2.replace("-", "_"));
}
for(String n:nodi.keySet()){
String colore=null, nodo=null;
String tipo=nodi.get(n);
if(tipo!=null){
//assegna un colore al nodo a seconda del tipo di dispositivo che
rappresenta
if(tipo.equals("wn")) colore="red";
else if (tipo.equals("se")) colore="blue";
else if (tipo.equals("exp")) colore="yellow";
else if (tipo.equals("ce")) colore="green";
else colore="gray";
}
tmp_url=n.split("espansioni_");
if(tmp_url.length>1)name_url=tmp_url[1];
Pietro Neroni 566/2833 Pagina 96 di 117

else name_url=tmp_url[0];
//scrive il nodo e i suoi attributi nel file DOT
Output.println(n.replace("-", "_")+"
[URL=\"http://localhost:8080/WebPowerfarm/index.jspvalue="+name_url+"&action=search\"]");
Output.println(n.replace("-", "_")+" [color="+colore+"]");
}
for(String a:archi){
//scrive la dipendenza nel file DOT
Output.println(a);
}
Output.println("}");
return tmp;
}
/**
* Modifica il nome del dispositivo
* @param String dispositivo
* @return String
*/
public String getNameDevice(String dispositivo){
String tmp1, result;
String []tmp3;
tmp1= dispositivo.split(".na")[0];
tmp3=tmp1.split("atlas");
if(tmp3.length>1) result=tmp3[1] ;
else result=tmp1 ;
return result;
}
/**
* Inserisce nel file plugins.xml un nuovo elemento contenente il tipo ed i plugin ad esso
associati: se i plugin per quel tipo sono già presenti li sostituisce con i nuovi
* @param String type
* @param Hashtable plugin
* @return boolean
*/
public boolean setPlugin(String type, Hashtable plugin)
{
boolean trovato=false;
try {
NodeList nodes = this.plugins.getElementsByTagName("plugin");
for (int i = 0; i < nodes.getLength(); ++i) {
Element node = (Element)nodes.item(i);
if(node.getAttribute("type").equals(type)) {
node.setAttribute("on", plugin.get("on"));
node.setAttribute("off-soft", plugin.get("off-soft"));
node.setAttribute("off-hard", plugin.get("off-hard"));
node.setAttribute("check-on", plugin.get("check-on"));
node.setAttribute("check-off",plugin.get("check-off"));
trovato=true;
}
}
}
catch (Exception e) {
this.error = e.toString(); }
if(!trovato){
Element newComp = this.plugins.createElement("plugin");
newComp.setAttribute("type", type);
newComp.setAttribute("on", plugin.get("on"));
newComp.setAttribute("off-soft", plugin.get("off-soft"));
newComp.setAttribute("off-hard", plugin.get("off-hard"));
newComp.setAttribute("check-on", plugin.get("check-on"));
newComp.setAttribute("check-off",plugin.get("check-off"));
this.plugins.getLastChild().appendChild(newComp);
}
Document tmp = saveDocument(this.plugins, this.pluginsFile, this.pluginsDtdFileName);
if (tmp != null)
this.plugins = tmp;
Pietro Neroni 566/2833 Pagina 97 di 117

else {
return false;
}
return true;
}
/**
* Crea un file in linguaggio DOT contenente la descrizione testuale del grafo delle dipendenze
logiche considerando anche il dispositivo passato come argomento e le sue dipendenze.
* @param String deviceName
* @param Set dependences
*/
public String graph(String deviceName, Set dependences){
Map nodi=new HashMap();
Set archi=new HashSet();
String tmp=null;
String tmp1,tmp2,tmp5,tmp6,set , source_name,target_name, name_url;
String[]tmp3, tmp4, temp_set, tmp_url;
String target,target2,source, source2 = null;
FileOutputStream file2;
PrintStream Output = null;
// creazione del file DOT
try {
file2 = new FileOutputStream("/usr/local/apache2/htdocs/webdot/grafo_add.dot");
Output = new PrintStream(file2);
}
catch (IOException e) {
System.out.println("Errore: " + e);
System.exit(1);
}
Output.println("digraph mainmap {");
NodeList nodes = this.dependency.getElementsByTagName("arc");
//legge le dipendenze tra i dispositivi nel file di configurazione dependences.xml
for (int i = 0; i < nodes.getLength(); ++i) {
Element node = (Element)nodes.item(i);
source=node.getAttribute("source");
target=node.getAttribute("target");
//se la dipendenza rappresenta una dipendenza fisica la ignora
if(target.equals("atlas")) continue;
else if(source.equals("atlas")) continue;
else if (target.contains("rack")) continue;
else if(source.contains("rack")) continue;
//modifica il nome dei dispositivi che rappresentano la dipendenza per rendere
il grafo più leggibile
source_name=getNameDevice(source);
target_name=getNameDevice(target);
tmp1= source.split(".na")[0];
tmp2=target.split(".na")[0];
tmp3=tmp1.split("atlas");
tmp4=tmp2.split("atlas");
if(tmp3.length>1) tmp5=tmp3[1] ;
else tmp5=tmp1 ;
if(tmp4.length>1) tmp6=tmp4[1];
else tmp6=tmp2 ;
//se uno dei due dispositivi fa parte di un insieme viene sostituito da
quest'ultimo
if (getSet(source)!=null) {
set=getSet(source);
set=set.split(".na")[0];
temp_set=set.split("atlas");
if(temp_set.length>1) set=temp_set[1];
source2="espansioni_"+set;
}
else source2=source_name;
if (getSet(target)!=null) {
set=getSet(target);
set=set.split(".na")[0];
temp_set=set.split("atlas");
Pietro Neroni 566/2833 Pagina 98 di 117

if(temp_set.length>1) set=temp_set[1];
target2="espansioni_"+set;
}
else target2=target_name;
nodi.put(source2,getAttributesOfDevice(source).get("type"));
nodi.put(target2,getAttributesOfDevice(target).get("type"));
archi.add(source2.replace("-", "_")+"->"+target2.replace("-", "_"));
source=node.getAttribute("source");
target=node.getAttribute("target");
if (getSet(source)!=null) source2="espansioni_"+getSet(source);
else source2=source;
if (getSet(target)!=null) target2="espansioni_"+getSet(target);
else target2=target;
nodi.put(source2,getAttributesOfDevice(source).get("type"));
nodi.put(target2,getAttributesOfDevice(target).get("type"));
archi.add(source2.replace("-", "_")+"->"+target2.replace("-", "_"));
}
for(String n:nodi.keySet()){
String colore=null, nodo=null;
String tipo=nodi.get(n);
if(tipo!=null){
//assegna un colore al nodo a seconda del tipo di dispositivo che
rappresenta
if(tipo.equals("wn")) colore="red";
else if (tipo.equals("se")) colore="blue";
else if (tipo.equals("exp")) colore="yellow";
else if (tipo.equals("ce")) colore="green";
else colore="gray";
}
//scrive il nodo e i suoi attributi nel file DOT
Output.println(n.replace("-", "_")+" [color="+colore+"]");
}
for(String dep: dependences){
String dep_device=getNameDevice(dep);
if(getSet(dep)!=null){
set=getSet(dep);
set=set.split(".na")[0];
temp_set=set.split("atlas");
if(temp_set.length>1) set=temp_set[1];
dep_device="espansioni_"+set;
}
//scrive la dipendenza nel file DOT
archi.add(dep_device+"->"+deviceName.replace("-", "_"));
}
for(String a:archi){
Output.println(a);
}
Output.println("}");
return tmp;
}
}
WebPowerfarm.java
package webpowerfarm;
import powerfarm.*;
import java.util.*;
public class Webpowerfarm{
protected IDatabase database;
protected Ping ping;
protected ICommand command;
Pietro Neroni 566/2833 Pagina 99 di 117

public List commandQueue;
public void updateCommandQueue(CommandInstance comm){
if(comm!=null) this.commandQueue.add(comm);
for(int i = 0; i < this.commandQueue.size(); ){
try{
commandQueue.get(i).getProcess().exitValue();
commandQueue.remove(i);
}catch(IllegalThreadStateException e){
i++;
continue;
}
}
}
public Webpowerfarm(String XMLpathDir, String COMpathDir) throws Exception{
try{
this.database = new XMLDatabase(XMLpathDir);
this.ping = new Ping(10, 10, 60);
this.command = new PerlCommand(COMpathDir, "powerfarm.pl");
this.commandQueue = new ArrayList();
this.synch();
}
catch(Exception e){
throw e;}
finally
{}
}
public IDatabase getDatabase(){ return this.database; }
public Ping getPing(){ return this.ping; }
public ICommand getCommand(){ return this.command; }
public boolean synch(){
try{
List oldSet = new ArrayList();
List newSet = Arrays.asList(this.database.getDevices());
for(Enumeration en = this.ping.getStatus().keys(); en.hasMoreElements();)
oldSet.add(en.nextElement());
//delete old
for(String d : oldSet){
if(!newSet.contains(d))
this.ping.delete(d);
}
//add new
for(String d : newSet){
if(!this.ping.contains(d)){
String address, command;
String[] commandArgs;
try{
Hashtable attr = database.getAttributesOfDevice(d);
Hashtable pingAttr =
database.getActionAttributesOfDevice(d, "check-on");
address = attr.get("address");
command = pingAttr.get("plugin");
commandArgs = pingAttr.get("args").split(" ");
}
catch(Exception e){
address = command = "";
commandArgs = new String[]{};
}
if(command!=null && !command.equals("")){
int lastIndexOfDot = command.lastIndexOf(".");
Pietro Neroni 566/2833 Pagina 100 di 117

String extension = (lastIndexOfDot>=0)
command.substring(lastIndexOfDot) : "";
if(extension.equals(".pl"))
command = "perl " + command;
this.ping.add(d, command, commandArgs);
}
else {
//this.ping.add(d, "ping", new String[]{"-c","3",(address!=null && !
address.equals(""))address:d});
this.ping.add(d, "", new String[]{});
//System.out.println("adding: " + d + " - " + address);
}
}
}
return true;
}
catch(Exception e){
return false;
}
}
}
edit.jsp
var stile = "top=10, left=10, width=800, height=200, status=no, menubar=no, toolbar=no
scrollbar=yes";
/*
Apre una finestra di pop-up dove viene eseguito il plugin e viene mostrato l'output
ottenuto
*/
function Popup(apri, command, args) {
window.open(apri + 'command=' + command.value + '&args=' + args.value, "", stile);
}
/*
Apre una finestra di pop-up dove viene eseguito il plugin e viene mostrato l'output
ottenuto
*/
function showGraph(){
if (document.form1.attr_name.value=="") {
alert('Per visualizzare il grafo è necessario inserire il nome del
dispositivo');
return false;
}
device=document.form1.attr_name.value;
dep=document.form1.listtextSelection;
if(dep.options.length==0){
alert('Per visualizzare il grafo è necessario assegnare almeno una
dipendenza');
return false;
}
dependences=dep.options[0].value + '_';
for(i = 1; i < dep.options.length; i++)
dependences+=dep.options[i].value + '_';
window.open("graph.jsp" + 'dependences=' + dependences + '&device=' + device, "",
stile);
}
Pietro Neroni 566/2833 Pagina 101 di 117

Hashtable plugin=new Hashtable();
String[] actionNames = new String[]{"on","off-soft","off-hard","check-on","check-off"};
for(String act : actionNames){
Hashtable tmp;
actions.put(act,tmp=new Hashtable());
plugin.put(act,((field = request.getParameter("action_"+act+"_plugin"))!=null
&& !field.equals(""))field:"");
tmp.put("plugin",((field = request.getParameter("action_"+act+"_plugin"))!=null && !
field.equals(""))field:"");
tmp.put("args",((field = request.getParameter("action_"+act+"_args"))!=null && !
field.equals(""))field:"");
tmp.put("description",((field = request.getParameter("action_"+act+"_description"))!
=null && !field.equals(""))field:"");
if(!act.equals("check-on") && !act.equals("check-off"))
tmp.put("timeout",((field = request.getParameter("action_"+act+"_timeout"))!
=null && !field.equals(""))field:"");
}
/*
Link alle pagine di monitoraggio
*/
String link_nagios = ((field = request.getParameter("link_nagios"))!=null)field:"";
String link_ganglia = ((field = request.getParameter("link_ganglia"))!=null)field:"";
String link_imgReport1 = ((field = request.getParameter("link_imgReport1"))!=null)
field:"";
String link_imgReport2 = ((field = request.getParameter("link_imgReport2"))!=null)
field:"";
String[] dependencies = (request.getParameterValues("dependencies")!=null)
request.getParameterValues("dependencies"):new String[]{};
//Aggiornamento o inserimento di un dispositivo
if(!webpowerfarm.getDatabase().setPlugin(type,plugin)){
throw new Exception("error in plugin");
}
if(!webpowerfarm.getDatabase().setAttributesOfDevice(value,attributes)){
throw new Exception("error in attributes");
}
if(farm.equals("")){
String oldFarm = webpowerfarm.getDatabase().getFarmOfDevice(value);
if(oldFarm!=null)
if(!webpowerfarm.getDatabase().removeDeviceOfFarm(value, oldFarm))
throw new Exception("error while removing farm");
}
else
if(!webpowerfarm.getDatabase().setFarmOfDevice(farm, value))
throw new Exception("error while setting farm");
for(String act : actionNames){
if(!webpowerfarm.getDatabase().setActionAttributesOfDevice(value, act,
actions.get(act)))
throw new Exception("error in actions text");
}
Hashtable nagiosAttr = new Hashtable();
nagiosAttr.put("href",link_nagios);
Hashtable gangliaAttr = new Hashtable();
gangliaAttr.put("href",link_ganglia);
gangliaAttr.put("imgReport1",link_imgReport1);
gangliaAttr.put("imgReport2",link_imgReport2);
if(!webpowerfarm.getDatabase().setLinkAttributesOfDevice(value,"ganglia",gangliaAttr))
Pietro Neroni 566/2833 Pagina 103 di 117

throw new Exception("error in links ganglia text");
if(!webpowerfarm.getDatabase().setLinkAttributesOfDevice(value,"nagios",nagiosAttr))
throw new Exception("error in links nagios text");
if(dependencies==null || dependencies.length==0){
if(!webpowerfarm.getDatabase().removeDependenciesOfDevice(value, false))
throw new Exception("error removing dependnecies");
}
else{
/*
viene controllato se le dipendenze assegnate al dispositivo causano cicli
*/
boolean cyclic = false;
List badArcs = new ArrayList();
for(String target : dependencies){
String[] all =
webpowerfarm.getDatabase().getAllDepthDependenciesOfDevice(target, false);
if(Arrays.asList(all).contains(value) || target.equals(value)){
cyclic = true;
badArcs.add(target);
}
}
/*
Nel caso causano cicli queste non vengono assegnate e viene stampata la lista delle
dipendenze che causano cicli
*/
if(cyclic){
String message = "Non si possono assegnare le dipendenze al dispositivo
i seguenti archi causano cicli: ";
for(String arc : badArcs){
message += "("+value+"->"+arc+")";
}
%>
error occurred while updating
Pietro Neroni 566/2833 Pagina 104 di 117

/*
Controlla se i campi obbligatori sono stati inseriti
*/
function check_obbligatori(){
if(document.form1.attr_address.value=="" || document.form1.attr_name.value=="") {
var msg="I seguenti campi obbligatori non sono stati inseriti:\n";
if(document.form1.attr_address.value=="" ) msg+="Indirizzo IP\n";
if( document.form1.attr_name.value=="") msg+="Nome dispositivo";
alert(msg);
return false;
}
var ip=document.form1.attr_address.value.split(".");
if(ip.length!=4){
alert('Indirizzo IP non valido');
return false;
}
for(i=0;i3){
alert('IP errato');
return false;
}
}
return true;
}
/*
Crea una lista di dispositivi che verra utilizzata per rappresentare le dipendenze
*/
arrDevice = new Array();
arrSelected = new Array();
/*arrDevice[0] = ['altlaswn01.na.infn.it','wn','atlas'];
...
arrDevice[14] = ['pamelace01.na.infn.it','ce','pamela'];*/
/*arrSelected[0] = 'altlaswn01.na.infn.it';
...
arrSelected[2] = 'altlaswn03.na.infn.it';*/
Pietro Neroni 566/2833 Pagina 105 di 117

*
Inserisce nella tabella usata per assegnare le dipendenze il tipo o il dispositivo , a
seconda del parametro wichBox
*/
function populate(whichBox){
var farmSelected =
document.form1.listtextFarm.options[document.form1.listtextFarm.selectedIndex].value;
if(whichBox == 'type'){
document.form1.listtextType.options.length = 0;
document.form1.listtextDevice.options.length = 0;
document.form1.listtextType.options[0] = new Option("ALL", "ALL");
for(i=0,j=1;i

document.form1.listtextDevice.options[i].value){
insert = false;
break;
}
if(insert)
document.form1.listtextSelection.options[document.form1.listtextSelection.optio
ns.length]=new Option(document.form1.listtextDevice.options[i].value,
document.form1.listtextDevice.options[i].value);
else
alert("The device '" + document.form1.listtextSelection.options[k].value + "'
is already selected");
}
}
//alert(document.form1.listtextDevice.options[0].selected);
}
/*
Rimuove il dispositivo selezionato dalla lista delle dipendenze assegnate
*/
function removeSelected(){
var myArr = new Array();
for(i = 0, j = 0; i < document.form1.listtextSelection.options.length; i++){
if(!document.form1.listtextSelection.options[i].selected){
myArr.push(document.form1.listtextSelection.options[i]);
}
}
document.form1.listtextSelection.options.length = 0;
}
for(i = 0, j = 0; i < myArr.length; i++){
document.form1.listtextSelection.options[i]=myArr[i];
}
function selectAll(obj){
for(i = 0; i < obj.options.length; i++)
obj.options[i].selected = true;
}
function onLoad(){
document.form1.listtextSelection.options.length=0;
for( i = 0; i < arrSelected.length; i++)
document.form1.listtextSelection.options[i] = new Option(arrSelected[i],
arrSelected[i]);
}
/*
Viene attivata ogni qualvolta si cambia il tipo della farm, se il tipo selezionato è new si
abilita un campo di testo per inserire il nome della nuova farm
*/
function farmSelection_onChange(){
var val =
document.form1.farmSelection.options[document.form1.farmSelection.selectedIndex].value;
if(val=="NEW"){
document.form1.farmText.setAttribute("value","");
document.form1.farmText.removeAttribute("disabled");
}
else if(val=="NONE"){
document.form1.farmText.setAttribute("value","");
document.form1.farmText.setAttribute("disabled","disabled");
}
else{
document.form1.farmText.setAttribute("value",document.form1.farmSelection.options[doc
ument.form1.farmSelection.selectedIndex].value);
Pietro Neroni 566/2833 Pagina 107 di 117

document.form1.farmText.setAttribute("disabled","disabled");
}
}
/*
Viene attivata ogni qualvolta si cambia il tipo del dispositivo, se il tipo selezionato è
new si abilita un campo di testo per inserire il nome della nuova farm. Inoltre richiama la
funzione setPlugin per assegnare in automatico i plugin per quel tipo
*/
function typeSelection_onChange(){
var val =
document.form1.typeSelection.options[document.form1.typeSelection.selectedIndex].value;
if(val=="NEW"){
document.form1.typeText.setAttribute("value","");
document.form1.typeText.removeAttribute("disabled");
}
else if(val=="NONE"){
document.form1.typeText.setAttribute("value","");
document.form1.typeText.setAttribute("disabled","disabled");
}
else{
document.form1.typeText.setAttribute("value",document.form1.typeSelection.options[doc
ument.form1.typeSelection.selectedIndex].value);
document.form1.typeText.setAttribute("disabled","disabled");
setPlugin(val);
}
}
/*
Legge nel file plugins.xml i plugin relativi al tipo passato come parametro e li assegna
automaticamente al nuovo dispositivo
*/
function setPlugin(tipo)
{var errore = 0;
try{
var ff = new XMLHttpRequest();
ff.open('GET', "plugins.xml", false);
ff.send(null);
var connect = ff.responseXML;
var plugin=connect.getElementsByTagName("plugin")
var trovato=false;
for (i=0; i

}
name:
The device name can be made of any char except space char. e.g.
myhost.mydomain.com
farm:
NONE
NEW
Insert the belonging farm, eventually blank.
IP address:
Insert the ip address of the device.
type:
Pietro Neroni 566/2833 Pagina 109 di 117

NONE
NEW
Insert the device type, e.g. WN for worker node, SE for storage element
etc.
component of:
description:
lock on/off:
/
lock-on/off pair value control the ability to wait for power on/off completion
when running power on/off operations respectively. In case of doubt leave the default
value.
select on search:
Enable the checkbox if you want the device automatically selected on search
results.
Pietro Neroni 566/2833 Pagina 110 di 117

power on:
plugin
args
description
timeout
test
Insert the absolute path of the
power-on plugin. Plugins are available in the plugin directory of powerfarm
package.
power off-soft:
Insert the absolute path of the
power-off simple plugin. Plugins are available in the plugin directory of powerfarm
package.

webpowerfarm.getDatabase().getActionAttributesOfDevice(value,"off-hard") : null; %>
power off-hard:
Insert the absolute path of the power-off hard
plugin. Plugins are available in the plugin directory of powerfarm package.
check on:
Insert the absolute path of the check-on plugin.
Plugins are available in the plugin directory of powerfarm package.
check off:
Insert the absolute path of the power-off
plugin. Plugins are available in the plugin directory of powerfarm package.
Pietro Neroni 566/2833 Pagina 112 di 117

link nagios:
hypertext reference
Place here the URL of the nagios page of the
device. This information will appear in the nagios link of the device when
searched.
link ganglia:
Place here the URL of the ganglia page of the
device. This information will appear in the ganglia link of the device when
searched.
image report left/right:
hypertext reference
/
Place in the left (right) field the graph to show on
the left (right) side of the device tag.
Set all the power-off dependencies. e.g. if you select
host "x","y" and "z" means that when shutting down this device "x","y" and "z" must be turned
off first.
Dependencies, all the device that mustbe shut before this:
Pietro Neroni 566/2833 Pagina 113 di 117

farm(s)type(s)device(s)dependencies
ALL

onclick="selectAll(document.form1.listtextSelection)">
graph.jsp
Grafo delle dipendenze per:
}catch(Exception e){ %>
Impossibile visualizzare il grafo
index.jsp
WebPowerfarm

order="0">
Pietro Neroni 566/2833 Pagina 116 di 117

}
Pietro Neroni 566/2833 Pagina 117 di 117