Università degli Studi di Napoli Federico II - Scope

Università degli Studi di Napoli Federico II
Facoltà di Scienze MM.FF.NN.
Corso di Laurea in Informatica
Tesi Sperimentale di Laurea Magistrale
Integrazione in un portale LIFERAY di un sistema di
accounting di code batch in ambito GRID.
Relatore
Candidato
Ch.mo Prof. Guido Russo Dott. Tommaso Foglia
Dott. Domenico del Prete Matricola: 961/147
Correlatore
Ch.mo Prof. Adriano Peron
Anno accademico 2010/2011

...

Indice generale
Introduzione..........................................................................................................................1
1 Sistemi distribuiti e griglie computazionali.........................................................................2
1.1I Sistemi Di Calcolo Distribuito WAN...........................................................................2
1.2 I Punti Forti Delle Griglie............................................................................................6
1.2.1 Le Organizzazioni Virtuali per gli esperimenti...........................................6
1.2.2 Stabilità e tolleranza ai guasti...................................................................7
1.2.3 Bilanciamento e condivisione delle risorse...............................................8
1.2.4 Elaborazione parallela e distribuita...........................................................8
1.2.5 Affidabilità del servizio...............................................................................9
1.3 Le Problematiche Nell'acquisizione Dei Dati Su Applicazioni Di Monitoraggio
Distribuite.......................................................................................................................11
2 L'infrastruttura dei Datacenter distribuiti dell'esperimento ATLAS..................................15
2.1 Topologia Del Centro ...............................................................................................15
2.2 Il Centro Di Calcolo Dell'INFN Di Napoli ..................................................................18
2.2.1 Le tecnologie del DataCenter .................................................................18
3 L'importanza delle informazioni a livello LRMS...............................................................22
3.1 Le Caratteristiche Del Servizio.................................................................................22
3.2 Le Informazioni Fornite Dai Batch System...............................................................30
3.3 Esempi Di Batch System: PBS E LFS......................................................................35
4 La modularità del portale di monitoraggio del Tier2 di Napoli.........................................44
4.1 Organizzazione Dei Servizi......................................................................................44
4.2 Struttura Di Un Portale.............................................................................................46
4.2.1 Java Portlet e Portlet Container..............................................................46
4.3 Un'esempio Di Enterprice Portal: Liferay..................................................................51
5 Progettazione di un sistema per il monitoraggio dello stato delle code...........................54

5.1 Raccolta Dei Requisiti E Casi D'uso. .......................................................................55
5.2 Analisi Del Prototipo E Degli Strumenti Già Esistenti...............................................64
5.3 Design Del Sistema Ed Implementazione Dei Requisiti Funzionali .........................69
5.4 Requisiti Non Funzionali...........................................................................................86
5.5 Class Diagram..........................................................................................................92
6 Conclusioni e sviluppi futuri.............................................................................................96
7 Bibliografia e Sitografia....................................................................................................97
Appendice A.......................................................................................................................99
Appendice B.....................................................................................................................127
Appendice C.....................................................................................................................144

Introduzione
Nell'ambito delle architetture distribuite multilivello, il monitoraggio ha ricoperto
negli anni un ruolo sempre più importante. Con lo scopo di voler garantire un servizio
affidabile, si diffondono sempre più sistemi capaci di poter mostrare la situazione
delle risorse monitorate in tempo reale in modo da poter rilevare anche i guasti e i
malfunzionamenti.
Partendo dalle informazioni che provengono dal monitoraggio delle componenti ai
vari livelli, si vuole automatizzare la possibilità di carpire immediatamente quante più
informazioni possibili sul reale stato delle risorse che vengono monitorate.
Il lavoro di tesi di laurea ha riguardato lo sviluppo di un'applicazione web,
integrabile in un portale LIFERAY, partendo dalla razionalizzazione e
dall'ampliamento delle funzionalità di un prototipo precedentemente sviluppato.
Nei primi capitoli vengono descritte le architetture distribuite multilivello, il
paradigma GRID e gli apparati oggetto dell'attività di monitoraggio. Successivamente
vengono valutate le informazioni che è possibile reperire a livello LRMS. Si
esaminano le informazioni che provengono dai batch system e vengono presi in
considerazione principalmente quelli di due tipi: PBS e LSF.
Viene poi descritto il portale di monitoraggio in cui verrà integrata l'applicazione.
Descritto l'ambiente di riferimento, si è passati alla progettazione dell'applicazione
web. Dalla raccolta dei requisiti, all'implementazione, passando per la scelta delle
tecnologie da utilizzare, sono illustrate tutte le fasi del processo di realizzazione.
L'applicazione ha lo scopo di voler fornire, tramite interfaccia web, le informazioni
relative allo stato di utilizzo delle code batch. In tempo reale avviene la realizzazione
di grafici che permettono, appunto, di poter monitorare l'occupazione delle code.
Inoltre tramite interazione è possibile navigare le informazioni secondo diversi criteri
di aggregazione. Una storicizzazione dei dati permette di ricostruire lo stato di
occupazione delle code, rendendo così disponibili nel tempo le informazioni.
Tommaso Foglia 961/147 Pagina 1 di 150

1 Sistemi distribuiti e griglie computazionali
1.1 I sistemi di calcolo distribuito WAN
I sistemi di Griglie Computazionali sono emersi come importante sinonimo per i
sistemi ad alte prestazioni HTC(High Throughput Computing). Contrariamente a
questi sistemi, dove l'obiettivo era raggiungere un risultato performante in termini di
operazioni floating point che il sistema poteva elaborare al minuto, l'importanza delle
griglie è definita in termini di quantità di lavoro che sono in grado di portare a
termine in un periodo di tempo.
Le griglie non possono essere considerate a tutti gli effetti una tecnologia
rivoluzionaria. La loro nascita scaturisce dall'evoluzione di tecnologie già esistenti
come il calcolo distribuito, i web service, internet e da varie tecnologie di crittografia
che provvedevano alla sicurezza e alla virtualizzazione.
Ognuna di queste aveva il suo proprio utilizzo. Le griglie prendono spunto da queste
tecnologie per sviluppare un sistema che fornisca risorse computazionali per qualche
scopo specifico.
I campi di applicazione possono essere i più disparati. Ricerche di marketing e
ricerche scientifiche sono solo alcuni esempi di utilizzo per organizzazioni che hanno
una presenza distribuita geograficamente. Le griglie sono quindi una tecnologia
evolutiva che migliorando quella esistente, provvedono a fornire alte prestazioni.
Una delle parole chiave che racchiude le motivazioni dietro l'evoluzione dei sistemi
di griglie è “virtualizzazione”. Virtualizzazione che nelle griglie si riferisce
all'integrazione dei sistemi eterogenei e geograficamente distribuiti. Questo permette
agli utenti di fare un uso dei servizi forniti dalla griglia in modo trasparente.
Tommaso Foglia 961/147 Pagina 2 di 150

Non c'è bisogno che l'utente sia a conoscenza della dislocazione delle risorse
computazionali. Così, dal punto di vista dell'utente, c'è un solo punto di accesso al
sistema. Essi dovranno solo sottoporre le loro richieste a questo nodo. Sarà compito
del sistema a griglia di trovare risorse computazionali disponibili che potranno
soddisfare le richieste degli utenti.
Si definisce VO(Virtual Organizzation) un raggruppamento dinamico di diverse
organizzazioni che provvedono al coordinamento delle risorse condivise. La
formazione di queste organizzazioni è volta all'utilizzo delle risorse computazionali
per la soluzione di problemi specifici. Basandoci sul concetto di VO è possibile
individuare tre termini per meglio comprendere il significato dei sistemi a griglie.
Il primo termine è “virtualizzazione” di cui abbiamo già parlato. Il secondo è
“eterogeneo” . Quando parliamo di VO, dovrebbe implicare che stiamo parlando di
un'entità multi-istituzionale. Le organizzazioni che prendono parte ad una VO
generalmente potrebbero avere differenti risorse in termini di hardware, di sistemi
operativi e di velocità di collegamento, per questo affermiamo che una VO è una
collezione di risorse eterogenee.
La terza parola è “dinamico”. Un'organizzazione può unirsi ad una VO o lasciarla per
sua convenienza o necessità. Per questo una VO è un'entità dinamica.
Questo spiega come mai le griglie hanno delle caratteristiche specifiche se comparate
ad altri sistemi distribuiti. Una griglia dovrebbe provvedere una coordinazione delle
risorse meno centralizzata, basata su degli standard condivisi e fornire una qualità del
servizio elevata.
Una griglia può essere utilizzata per scopi computazionali(griglie computazionali),
per la memorizzazione di dati su larga scala(griglie di dati), oppure una combinazione
di entrambe.
Tommaso Foglia 961/147 Pagina 3 di 150

Figura 1: Esempio di elementi componenti una griglia computazionale.
I sistemi distribuiti generalmente sono utilizzati da una singola organizzazione ed
hanno controllo centralizzato. Di contro, le griglie non hanno controllo centralizzato e
vengono utilizzati per scopi di un grande numero di organizzazioni. Come detto, una
griglia è definita da parole chiavi come eterogeneo, dinamico e virtualizzazione. I
sistemi distribuiti possono avere risorse eterogenee ma il concetto di eterogeneo è
limitato ad una sola organizzazione, mentre nelle griglie sono composte da risorse
eterogenee di svariate organizzazioni.
I sistemi distribuiti spesso focalizzano l'attenzione sulla condivisione delle
informazioni, basandosi sul modello client-server. Nelle griglie la condivisione non è
soltanto delle informazioni. Si può estendere alle applicazioni e all'hardware.
Tommaso Foglia 961/147 Pagina 4 di 150

Figura 2: Esempio di sottomissione di un job sulla griglia.
Tecnologie computazionali distribuite permettono la condivisione delle informazioni
con una sola organizzazione, mentre le griglie permettono la condivisione delle
risorse tra le VO(composte a loro volta da più organizzazioni).
Le griglie supportano l'aggiunta automatica delle risorse e il monitoraggio delle stesse
su larga scala. Questo non è presente nei sistemi distribuiti. Se consideriamo sistemi
decentralizzati come i sistemi peer-to-peer, osserviamo che essi offrono servizi
altamente specializzati che però non badano alla qualità del servizio QoS(Quality of
Service).
Non vi è una nozione di azioni permesse o non permesse, come nei sistemi a griglia.
Le griglie e i sistemi peer-to-peer differiscono inoltre sullo scopo per cui sono state
create, per l'ammontare del traffico di dati e per le risorse condivise tra tutte le entità
partecipanti.
Tommaso Foglia 961/147 Pagina 5 di 150

1.2 I punti forti delle Griglie
Principalmente si fa riferimento alle griglie in termini di VO e in termini di sistemi ad
alte prestazioni.
1.2.1 Le Organizzazioni Virtuali per gli esperimenti
Le griglie permettono la collaborazione tra un folto gruppo di organizzazioni per la
condivisione delle risorse. Questa collaborazione non è limitata allo scambio di file
ed implica un accesso diretto alle risorse computazionali.
Figura 3: Concetto di dislocazione geografica della griglia.
I membri delle griglie possono essere dinamicamente organizzati in più
organizzazioni virtuali. Ognuna di queste VO può avere differenti politiche e
Tommaso Foglia 961/147 Pagina 6 di 150

differenti controlli amministrativi. Tutte le Vo sono parte di una grande griglia e
possono condividere le risorse.
Le risorse condivise tra le VO possono essere dati, hardware specializzato, capacità
esecutiva ed informazioni riguardo le altre risorse disseminate sulla griglia.
Le VO nascondono la complessità della griglia all'utente permettendo una
virtualizzazione delle risorse eterogenee della griglia. I membri di una griglia
possono prendere parte a più VO contemporaneamente. Inoltre le griglie possono
essere utilizzate per definire delle politiche di utilizzo per i membri, potendo dare
priorità sulle risorse per utenti differenti.
1.2.2 Stabilità e tolleranza ai guasti
Supposto che un utente mandi in esecuzione un job da un particolare nodo della
griglia. Gli vengono allocale le risorse necessarie in base alla disponibilità e alle
politiche di scorrimento della griglia. Se per qualche motivo il nodo su cui è in
esecuzione il job dovesse subire un guasto, la griglia provvederebbe automaticamente
alla risottomissione dello stesso su di un altro nodo disponibile.
E' possibile che si verifichi anche un altro caso. Una griglia dati, può essere
considerata come una griglia per elaborare e condividere una larga quantita di dati
distribuiti. Una griglia dati può essere utilizzata per più scopi differenti.
Può essere utilizzata per incrementare la velocità di trasferimento dei dati. Diverse
copie dei dati possono essere create in aree distribuite geograficamente. Se un utente
ha bisogno dei dati per un qualsiasi scopo, può essere recuperato dalla macchina più
vicina che ne detiene una copia. Ovviamente questo contribuisce ad un aumento
dell'efficienza. Se alcune macchine dovessero scollegarsi, le altre macchine possono
provvedere le copie di backup. Inoltre se è previsto che si faccia accesso più
frequentemente a particolari dati su una macchina, le copie possono essere ospitate su
macchine più vicine ad essa.
Tommaso Foglia 961/147 Pagina 7 di 150

Entrambi possono essere considerati esempi di virtualizzazione. Nel primo l'utente
non è a conoscenza del guasto e del suo automatico aggiramento. Nel secondo
l'utente accede ai dati senza sapere quale macchina della rete serve la sua richiesta.
1.2.3 Bilanciamento e condivisione delle risorse
Il Bilanciamento e la condivisione delle risorse sono aspetti importanti delle griglie,
che forniscono le necessarie funzioni di gestione delle risorse. Questo aspetto
permette alla griglia di distribuire i tasks alle risorse disponibili. In un sistema della
griglia sovraccaricato, l'algoritmo di scheduling può ridistribuire tasks su sistemi che
sono inattivi o comunque meno carichi. In questo modo l'algoritmo di scheduling
della griglia trasferisce in modo trasparente i tasks ad una macchina meno carica,
ottimizzando l'utilizzo delle risorse meno utilizzate.
1.2.4 Elaborazione parallela e distribuita
Alcuni tasks possono essere divisi in più sottotasks, ognuno dei quali può essere
elaborato su una macchina diversa. Nell'ambito del calcolo scientifico, della
modellazione matematica, nell'elaborazione di immagini o nell'animazione 3D questo
viene molto spesso utilizzato.
Ognuna di queste applicazioni può essere scritta per essere eseguita come un singolo
sottotask indipendente, poi, i risultati provenienti da ogni sottotasks possono essere
combinati per produrre l'output desiderato. Ci sono, tuttavia, dei vincoli che limitano
l'utilizzo di questa pratica, non tutti i tasks possono essere partizionati in questo
modo. Inoltre c'è un limite nel numero di sottotasks in cui un task può essere diviso,
facendo da limite superiore al massimo incremento di performance raggiungibile.
Se due o più di questi sottotasks lavorano sullo stesso insieme di strutture di dati,
Tommaso Foglia 961/147 Pagina 8 di 150

dovrà esistere qualche sistema di controllo, come avviene per la concorrenza nei
database o tipo semafori per quanto riguarda i sistemi operativi, per fare in modo che
la struttura dati utilizzata non diventi inconsistente. Quindi esiste un vincolo sul tipo
di tasks che può essere pensato di essere mandato in esecuzione sulla griglia ed esiste
inoltre un limite sul poter rendere un'applicazione grid-enabled.
1.2.5 Affidabilità del servizio
Una griglia può essere utilizzata in uno scenario in cui gli utenti possono inviare i
loro jobs ed ottenere l'output, l'utilizzo che gli utenti fanno della grigilia può essere
misurato nel tempo in cui questi vengono completati.
In questo scenario, dove è tenuta una sorta di contabilità all'utente per i servizi di cui
ha usufruito, è auspicabile che l'utente si aspetti una determinata affidabilità del
sistema. Questo viene specificato in un accordo: Service Level Agreement(SLA).
SLA stabilisce la qualità minima del servizio, della disponibilità delle risorse. SLA
può anche specificare un minimo tempo di up-time desiderato del sistema. Le griglie,
come detto, provvedono una tolleranza ai guasti, stabilità e capacita di esecuzione in
parallelo per determinati tasks e può essere utilizzato per lo sviluppo di sistemi
distribuiti.
La qualità del servizio puo' essere basata sulle richieste dell'utente, in modo che
l'algoritmo di scheduling dei tasks possa dare precedenza all'uno o all'altro utente.
Un utente potrebbe avere bisogno dei servizi offerti dalla griglia per un'applicazione
in tempo reale ed ovviamente sarà richiesto un QoS maggiore rispetto agli altri utenti.
Così, l'algoritmo di scheduling della griglia potrà dare priorità ai job dell'utente
rispetto agli altri job in esecuzione. Questo fornirà il necessario livello di affidabilità
all'applicazione in tempo reale dell'utente.
Una qualità del servizio elevata può essere ottenuta riservando alcune risorse della
griglia per determinati job. Quando queste risorse riservate sono inutilizzate possono
Tommaso Foglia 961/147 Pagina 9 di 150

comunicare il loro stato ad un nodo per la gestione delle risorse. Queste possono
essere utilizzate dalla griglia per l'esecuzione di altri jobs Non appena arriva una
richiesta da parte dei jobs a priorità maggiore, i job che attualmente utilizzano queste
risorse vengono prelazionati e lasciano subito disponibili le risorse per i job a priorità
maggiore, che erano quelli per qui le risorse erano state riservate.
I job prelazionati vengono posti in una coda di job insieme alle informazioni sul loro
completamento. Questi job potranno essere mandati in esecuzione dal job scheduler
qualora ci saranno risorse disponibili sulla griglia.
Anche altri sistemi distribuiti possono fornire queste stesse funzionalità, ma la
differenza risiede nel fatto che le griglie possono fornire queste funzionalità su un
livello multi-istituzionale e questo permette di gestire le risorse distribuite
geograficamente.
I sistemi distribuiti che forniscono queste stesse funzionalità operano generalmente su
livelli organizzativi e hanno un punto di controllo centralizzato a differenza delle
griglie.
Tommaso Foglia 961/147 Pagina 10 di 150

1.3 Le problematiche nell'acquisizione dei dati su applicazioni di monitoraggio
distribuite
Le risorse messe a disposizione negli ambienti distribuiti, potrebbero non essere
sempre disponibili, o non garantire un corretto funzionamento, e ciò costituisce un
problema per l'utente che ignora la complessità dell'ambiente che usa.
Anche se il modello del paradigma Grid non sia fondamentalmente diverso dai
tradizionali modelli paralleli e distribuiti, esso è ovviamente complicato da questioni
legate all'eterogeneità dell'ambiente, la multi-istituzionalità, la dinamicità della
disponibilità e delle configurazioni delle risorse dell'infrastruttura. Risulta difficoltoso
riuscire a garantire stabilità, buone prestazioni e gestione dei problemi in ambienti
talmente dinamici.
Le problematiche che possono verificarsi sono tra le più disparate: sovraccarichi o
guasti delle risorse, della rete, problemi di carattere fisico, che includono problemi di
alimentazione e raffreddamento, incendi, perdite, ed altro. Alcune di queste minacce,
comprese quelle relative al raffreddamento, all'alimentazione o agli incendi, sono
monitorate generalmente da funzioni integrate nei dispositivi di alimentazione,
raffreddamento e antincendio (è relativamente semplice avere a disposizioni
rilevazioni sulla temperature dell'hardware o sullo stato di carica di una batteria).
Molto spesso, tali malfunzionamenti sono alla base di numerosi problemi di gestione
delle infrastrutture che sono a carico degli amministratori locali dei sistemi che,
sempre maggiormente, fanno richiesta di strumenti di monitoraggio, che diventano,
cosi, parte attiva per la gestione: tali strumenti, infatti, da un lato forniscono
informazioni read-only all'utente, dall'altro consentono a chi gestisce l'infrastruttura
di ottenere informazioni, che più o meno automaticamente, permettono, in caso di
problemi, di intervenire sulle configurazioni per ripristinare uno stato coerente
dell'infrastruttura.
Il problema del monitoraggio è comune a tutte le infrastrutture distribuite
multilivello. E' necessario individuare il livello dell'infrastruttura più idoneo a
Tommaso Foglia 961/147 Pagina 11 di 150

contenere un sistema di monitoraggio che fornisca il “giusto” livello di dettaglio in
merito alle informazioni di funzionamento delle risorse. L'attenzione si sofferma
principalmente sulle risorse di calcolo.
Considerando sistemi di calcolo multilivello, è sempre presente un sistema di
gestione delle risorse che ha il compito di offrire, ai livelli superiori, i nodi di calcolo:
tale sistema è un livello comune, il Local Resource Management System (LRMS),
che è in grado di reperirne tutte le informazioni di funzionamento, occupandosi della
gestione dei nodi di calcolo.
Il WnoDes (Worker Nodes on Demands Service), un software in via di sviluppo da
parte dell'INFN (Istituto Nazionale di Fisica Nucleare), può essere portato come
esempio di condivisione di risorse di calcolo.
Tommaso Foglia 961/147 Pagina 12 di 150

Le sue principali caratteristiche sono:
Virtualizzazione e personalizzazione delle risorse di calcolo, con una stretta
integrazione con il servizio LRMS (Local Resource Management System), che
si occupa della gestione delle risorse;
Integrazione completa con le politiche di allocazione delle risorse, di
monitoraggio, di accounting e di sicurezza già presenti all’interno di un Centro
di Calcolo, assicurando al contempo la scalabilità e le performance tipiche dei
moderni LRMS;
Aiutare l'utente nella selezione ed accesso alle risorse attraverso interfacce
Grid redirigendo automaticamente i job mandati in esecuzione;
Si viene a creare un pool di risorse virtuali, che l'utente richiede a momento della
richiesta di esecuzione della sua applicazione (job).
Tommaso Foglia 961/147 Pagina 13 di 150

Il sistema software WnoDes si integra perfettamente con il servizio LRMS e si viene
così a creare un livello di Virtual Machines (VM), opportunamente configurate per
soddisfare le richieste dell’utenza, tale livello, gestito dal servizio LRMS.
Ogni richiesta di risorse, proveniente da qualsiasi tipo di utente, viene trasformata in
maniera trasparente per l’utente in un job sottoposto al LRMS. Ancora una volta, non
si può far a meno di sottolineare che il LRMS è la componente chiave per la gestione
efficiente delle migliaia di Virtual Machine. In definitiva il LRMS risulta, quindi, la
componente comune di tutti i paradigmi basati su architetture multilivello, pertanto,
per fornire informazioni sullo stato delle risorse di calcolo occorre lavorare su tale
livello.
Nel terzo capitolo, si analizzeranno nel dettaglio la struttura e le funzionalità del
Local Resource Management System, ponendo attenzione alle informazioni che è
possibile recuperare a tale livello dell'infrastruttura e quali di esse sono indispensabili
per utilizzare il sistema progettato, il tutto per garantire una qualità del servizio che
sia il più adeguata possibile.
Tommaso Foglia 961/147 Pagina 14 di 150

2 L'infrastruttura dei Datacenter distribuiti dell'esperimento ATLAS
2.1 Topologia del Centro
L’analisi dei dati provenienti dal LHC (Large Handron Collider), il più grande e
potente acceleratore di particelle, situato presso il CERN di Ginevra, è basato sul
paradigma di GRID Computing, secondo un modello gerarchico organizzato in livelli
detti Tier che permette oltre ad una forte decentralizzazione, una condivisione a
livello internazionale delle risorse computazionali.
Dopo una prima fase di raccolta e di selezione,i dati interessanti, o dati grezzi,
vengono inviati con apposite linee dedicate al Computer Center del CERN, noto
come Tier-0. Qui avviene la prima tornata di ricostruzione: i dati grezzi (RawData) in
uscita dall'esperimento subiscono una prima fase di calibrazione e allineamento.
Finita l'elaborazione i dati grezzi e le sintesi vengono inviate ai centri Tier-1 che
partecipano all'esperimento.
I centri Tier-1, sono decentralizzati. Sono dislocati nei paesi che partecipano al
progetto e contribuiscono a creare una rete di ricerca essendo collegati direttamente al
CERN. Ogni centro Tier-1 ha il compito di rielaborare i dati grezzi e di fornire un
back-up distribuito, immagazzinando a tempo indeterminato una parte di questi dati.
Ogni Tier-1 ha diversi Tier-2 associati, spesso accomunati da una vicinanza
geografica, infatti sono generalmente disposti a livello nazionale. I dati elaborati dal
Tier-1, avvalendosi di algoritmi per la ricostruzione delle informazioni, vengono poi
distrubuiti ai Tier-2, dove potranno essere eseguiti job di analisi e simulazione dei
dati da parte degli utenti.
I Tier-1 insieme ai rispettivi Tier-2 formano una Cloud. La Cloud italiana ha nel
CNAF (Centro Nazionale per la Ricerca e Sviluppo nelle Tecnologie Informatiche e
Telematiche) di Bologna il suo Tier-1 e nelle sedi dell'Istituto Nazionale di Fisica
Nucleare di Milano, Roma, Napoli e Frascati i suoi Tier-2. Circa 10 Cloud , sparse in
Tommaso Foglia 961/147 Pagina 15 di 150

tutto il mondo, fanno parte del progetto ATLAS. Ognuna è in grado di memorizzare
grandi quantità di dati dell’ordine di centinaia di Tera byte e di fornire un'adeguata
potenza di calcolo per i diversi compiti da svolgere.
I Tier-2 hanno il compito di sopperire a tutta la capacità di simulazione necessaria
all'esperimento, anche se la condivisione effettiva dei dati risultanti avverrà
attraverso i Tier-1 di riferimento. Oltre alla potenza di calcolo un centro Tier-2 dovrà
fornire anche risorse per lo storage in grado di ospitare i dati assegnati, che si
presentano in file di formati diversi, in base al tipo e alla quantità di informazioni
contenute.
Tommaso Foglia 961/147 Pagina 16 di 150

L'utilizzo del paradigma Grid è di fondamentale importanza per il Tier-2.
L'accessibilità tramite gli strumenti Grid standard e la continua operatività del
sistema, minimizzando guasti e manutenzione, fanno si che il centro possa assolvere
a tutti questi compiti. L'ambiente deve poter soddisfare un'attività multiutente, dove
vengono eseguite contemporaneamente operazioni computazionalmente onerose.
Si può parlare di un Tier-3 a carattere locale, composto da singoli istituti o
dipartimenti, fornisce capacità di analisi per i gruppi ed i sottogruppi dell'istituto o
dipartimento. E' il livello gerarchico più basso ed è dove effettivamente avviene
l'analisi dei dati.
I dati seguono il cosiddetto Event Data Model: si parte dai dati grezzi forniti in output
dall'LHC, per arrivare ai dati da elaborare nei singoli siti. Abbiamo diversi tipi di
dati:
➢ Raw Data: sono le misure grezze in uscita dal Trigger, sono trasferite dal Tier0
al Tier1.
➢ EDS (Event Summary Data): misure in uscita dalla ricostruzione. Vanno a
rappresentare quello che riguarda l'interazione tra le particelle
nell'acceleratore, i percorsi delle particelle e le collisioni.
➢ AOD (Analisys Object Data): sono un tipo ridotto degli ESD, è il formato
pubblico dei dati da elaborare. Descrivono le singole particelle.
➢ DPD (Derived Physicl Data): rappresentano il tipo di dato privato utilizzato
esplicitamente nei centri di calcolo. Risultano essere un formato ridotto degli
AOD.
Tramite l'utilizzo di specifici insiemi di software e middleware viene gestita la
comunicazione dei dati, indipendentemente dal luogo geografico in cui essi si trovano
le informazioni sono sempre disponibili all'uso.
Tommaso Foglia 961/147 Pagina 17 di 150

2.2 Il centro di calcolo dell'INFN di Napoli
Il Tier2-Napoli è disposto in due sale appositamente allestite, che sono :
➢ Il Capannone realizzato per il progetto S.Co.P.E, che contiene 33 Racks dei
quali quattro contengono dispositivi dedicati al Tier2 ATLAS.
➢ Una sala nei locali del Servizio di Calcolo & Reti (SCR) della Sezione INFN,
del Dipartimento di Fisica che contiene tre Racks.
2.2.1 Le tecnologie del DataCenter
Gli apparati del DataCenter sono distribuiti in due sale e disposti in sette Racks dei
quali tre presso INFN, e quattro preso il Capannone di S.Co.P.E. Il collegamento fra
le due sale avviene attraverso un link in fibra ottica a 10Gbps.
Il Tier-2 e' connesso alla rete geografica tramite un router Cisco con una linea
dedicata di fibra a 1Gbps verso il Pop Garr, che e' collocato nell'edificio dei Centri
Comuni del Complesso Universitario di Monte Sant'Angelo.
Tommaso Foglia 961/147 Pagina 18 di 150

Andiamo ad esaminare i servizi e gli apparati fondamentali. Ogni Organizzazione
Virturale (V.O.) mette a disposizione un'insieme di risorse interconnesse attraverso la
rete internet. In ogni sito appartenente al Tier-2 sono collocate delle macchine che
hanno diverse funzionalità.
I Service Nodes sono i dispositivi dedicati alla gestione dell'accounting degli utenti e
allo smistamento dei job da effettuare sulle macchine deputate ad eseguirli. I Service
Nodes si suddividono in :
✔ User Interface(UI): Rappresenta il punto di accesso a Grid. E' costituita da un
calcolatore dove gli utenti hanno un account personale, in cui è installato il
proprio certificato che permette di interagire con le funzionalità del sistema
Grid. Dalla UI, 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.
Tommaso Foglia 961/147 Pagina 19 di 150

✔ Computing Element(CE): Unità logica di calcolo che include il gateway verso
una farm. Il CE ha infatti il controllo su uno o più Worker Node (WN) che
sono le unità fisiche di calcolo.
✔ 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 né memoria
di massa (usano direttamente lo Storage Element). Non tutti hanno le stesse
caratteristiche tecniche, difatto molti di essi sono stati aggiunti di recente, e
quindi sono diversi dagli apparati più vecchi. Per alcuni di questi ultimi inoltre
è già stata programmata la rimozione.
✔ Storage Element(SE): Le Risorse di Storage hanno il compito di conservare i
dati da elaborare. Essi sono collegati agli altri dispositivi attraverso dei canali
in fibra dedicata e sono gestiti attraverso vari server, detti Storage Element,
che si occupano delle operazioni di lettura e scrittura di dati. In particolare
sono installati 2 server in ridondanza per ogni apparato di storage. A ciascuno
e' dedicata una parte di storage e può effettuare operazioni di lettura o scrittura,
se funzionano contemporaneamente. Invece nel caso di malfunzionamento di
uno tra i due, quello funzionante e' responsabile di impegnarsi anche per il
lavoro dell'altro. Forniscono un accesso uniforme alle risorse di storage
(servers di dischi, array di dischi, Mass Storage Systems) supportando diversi
protocolli di accesso a dati ed interfacce. Si può notare che non sono tutti gli
apparati sono dello stesso tipo, in quanto sono stati aggiunti alla rete in tempi
differenti.
✔ Disk Pool Manager(Dpm): Per utilizzare diversi tipi di SE nella Grid, è
necessario definire un’interfaccia che permetta la gestione dei possibili
supporti, indipendentemente dal loro tipo: a questa funzione è dedicato il
protocollo Storage
✔ Resource Manager (SRM). DPM implementa l'interfaccia di SRM che consiste
Tommaso Foglia 961/147 Pagina 20 di 150

in un server che fornisce un singolo punto di accesso verso un pool di server di
dischi.
✔ HLR: Effettua l'accounting dell'utilizzo delle risorse del calcolo(CPU Time),
da parte delle diverse VO.
Tommaso Foglia 961/147 Pagina 21 di 150

3 L'importanza delle informazioni a livello LRMS
3.1 Le caratteristiche del servizio
Il servizio LRMS, Local Resoure Management System avrà il compito di reclutare e
di gestire le risorse del sistema, in modo che l'andamento delle esecuzioni non sarà
più mansione dell'utente ma sarà gestito dal sistema.
Come spesso capita in un ambiente multilivello, bisogna coordinare una notevole
quantità di risorse dislocate fisicamente. Nella circostanza in cui gli utenti richiedono
l’esecuzione di un job, il sistema dovrà garantire loro,la possibilità di avere
informazioni sullo stato di esecuzione dell’applicazione oltre al corretto
funzionamento del servizio di allocazione delle risorse di calcolo.
La totalità dei nodi di calcolo risulta essere un insieme logico, visti come componenti
di una coda, dove utenti o gruppi di utenti o intere VO hanno determinati permessi di
esecuzione.
Un sistema in grado di supportare l'esecuzione di una serie di job (batch job) senza la
necessità di avere una continua interazione con l'utente (batch processing) è definito
come batch system. Nei sistemi Grid, ad esempio, la gestione dei batch job è,
generalmente, ad opera del sistema, o di utenti privilegiati, ogni job viene mandato in
esecuzione indicando i parametri di input o dove reperire i dati necessari
all'esecuzione potendo indicare quali specifiche risorse di calcolo si preferisce
utilizzare.
Ogni richiesta di risorse viene trasformata, in maniera trasparente per l’utente, in un
job da sottoporre al LRMS. Quando l'utente decide di mandare in esecuzione un job,
quest’ultimo viene presentato al LRMS che avrà il compito di assegnarlo ad un WN
disponibile, controllando sia le risorse disponibili che i requisiti del job.
Il servizio LRMS ha una logica di tipo master/slave: il master occupa una macchina
di front-end, mentre gli slave si trovano sulle macchine, virtuali o fisiche, che
Tommaso Foglia 961/147 Pagina 22 di 150

vengono impiegate per il calcolo effettivo, i cosiddetti “worker node” (WN).
Di fondamentale importanza risulta essere l'attività di gestione delle risorse e i servizi
di gestione sono composti solitamente da varie componenti con diversi ruoli.
Elenchiamo i ruoli fondamentali:
Aggiornare e controllare lo stato delle risorse;
Ricevere i job mandati in esecuzione dagli utenti;
Approvarli e controllarne i permessi;
Eseguire materialmente i job;
Controllarne l'esecuzione;
Rilasciare aggiornamenti sullo stato delle risorse alla componente che si
occupa effettivamente della scelta della risorsa di calcolo.
Per come è stato descritto, il compito di un batch system è quello di poter offrire
capacità di calcolo, per un dato insieme di fruitori che ne facciano richiesta.
E' spesso utile suddividere le risorse in unita logiche, dette nodi,a prescindere dalle
reali risorse. Elementi fondamentali di un nodo sono almeno un processore unito a
risorse di memoria e di comunicazione.
I nodi, in un tipico sistema batch semplice,hanno una classificazione in tre
categorie:
➢ Central Manager Node
➢ Execution Node
➢ User Interface Node
Tommaso Foglia 961/147 Pagina 23 di 150

Figura 9 Schema generale di funzionamento.
Un ruolo fondamentale è ricoperto dal Central Manager, infatti si occupa della
gestione e coordinamento dell'intero sistema.
I processi in esecuzione su questo nodo, raccolgono le richieste di sottomissione dei
job da parte degli utenti, che accedono tramite User Interface e le suddividono tra i
nodi di esecuzione, facendo da mediatore tra le risorse richieste e quelle al momento
disponibili.
Il Central Manager deve garantire stabilità di funzionamento, infatti un
malfunzionamento o un crash del sistema potrebbero precluderne il suo intero
funzionamento. Esso è quindi, una macchina con elevati livelli di connettività
rispetto agli altri nodi.
I nodi Execution possono essere molto eterogenei, in termini di risorse a
disposizione e di prestazioni, eseguono i job, comunicano col Central Manager e
ritornano i risultati. I nodi User Interface,sono utilizzati per l'invio delle richieste e
costituiscono l'interfaccia verso l'utente.
Tommaso Foglia 961/147 Pagina 24 di 150

Tali nodi devono fornire buoni requisiti, in termini di memoria. Ne segue che la
gestione di un sistema batch non è un compito semplice, poiché ad esempio i job,
mandati in esecuzione dagli utenti, possono avere durata variabile o essere di vario
tipo o possono aver bisogno di quantità di risorse non al momento disponibili.
Una volta allocate le risorse più “adatte” per il job, una componente detta scheduler si
occupa di:
• Ottimizzare le risorse di mandare in esecuzione i job;
• Assegnare una specifica priorità e ordinare i job;
• Smistare i job.
Lo scheduler ha il compito di calcolare un giusto ordine di esecuzione dei job
pervenuti ed è un processo in continua esecuzione su un nodo manager. Lo scheduler
fa in modo che i job non influiscano sull'esecuzione degli altri per quanto riguarda
l'allocazione di risorse, inoltre li riordina.
Per far sì che anche gli utenti possano contribuire alle scelte dello scheduler, viene
messo a disposizione un servizio, detto resource manager, che consente
l'amministrazione dei job ed ha piena visibilità delle risorse al momento disponibili.
Il livello del servizio LRMS possiede gli strumenti per ottenere un elevato numero di
informazioni statiche e dinamiche sull'organizzazione topologica e sullo stato
effettivo delle risorse di calcolo, essendo, nelle infrastrutture di calcolo distribuito il
livello più vicino ai nodi di calcolo. E' necessario quindi predisporre meccanismi di
monitoraggio delle risorse proprio a tale livello.
E' buona norma di progettazione individuare subito quelli che saranno i requisiti
funzionali e quelli non funzionali. Un generico sistema di monitoraggio deve poter
offrire:
• Una visualizzazione dei risultati relativi all'attività di monitoraggio in formato
grafico o tabellare.
Tommaso Foglia 961/147 Pagina 25 di 150

• Per evitare che anomalie ed errori compromettano l'affidabilità del sistema,
sarebbe auspicabile che dei controlli automatici, al raggiungimento di una
soglia critica, provvedessero allo spegnimento automatico della risorse non
funzionanti, alla riconfigurazione delle code di calcolo, o ancora allo
spegnimento del servizio che ha provocato il raggiungimento della soglia
critica.
Inoltre è auspicabile che il sistema abbia:
• Un basso overhead: per non incidere sulle performance del sistema nel suo
complesso le risorse occupate per il recupero delle informazioni, devono
essere minime;
• bassa latenza: ridurre il ritardo nella trasmissione delle informazioni;
• fault tolerance: cioè la sopravvivenza ai guasti, a seguito dei quali il sistema
deve essere in grado di riconnettersi e sincronizzarsi automaticamente;
• sicurezza e scalabilità: si deve prevedere di mantenere lo stesso standard di
qualità, anche al crescere delle risorse da monitorare, oltre a controllare gli
accessi al sistema.
• Formattazione dei risultati: il modo in cui presentare i risultati ottenuti deve
essere semplice ed esauriente, possibilmente rispettando uno standard
specifico.
Affinché l'attività di monitoraggio soddisfi tutti i requisiti, sia quelli funzionali che
quelli non funzionali, di cui si è parlato, c'è bisogno di un folto numero di parametri
che riescano a rappresentare fedelmente e completamente lo stato delle risorse.
Possiamo dividere questi parametri in due gruppi : del primo gruppo fanno parte le
informazioni statiche sul sito da monitorare: nomi delle code,nomi dei gruppi, numeri
Tommaso Foglia 961/147 Pagina 26 di 150

delle code, ed altro ancora. del secondo, invece, le informazioni specifiche sui job
presenti sulle code: numero di esecuzione, stato, tempi.
Poiché gli utenti sono aggregati logicamente in gruppi è importante sottolineare la
necessità di avere una mappatura tra le code di esecuzione del batch system e sui
gruppi di utenti che hanno l'autorizzazione di lavorare su queste code.
Le mappature possono essere dalle più semplici, nel caso di facili associazioni tra
gruppi e code, o molto complesse, dove più gruppi accedono a più code.
E' necessario estrarre informazioni su:
• Gruppi (o più comunemente nel caso grid VO): i gruppi o le VO hanno
obiettivi comuni e politiche di accesso ai dati distrubuiti e alle risorse
prestabilite. Ogni membro facente parte del gruppo ha accesso alle risorse del
sito oggetto di monitoraggio.
• Utenti singoli,cioè utenti non appartenenti a VO o a gruppi che hanno però
permessi di accesso alle risorse del sito;
• Code, cioè gli insiemi di nodi, messi a disposizione dalla rete di calcolo, per
poter elaborare le richieste. Sarà importante sapere per ogni coda, quali
vo,gruppi e code sono autorizzati all'utilizzo di tali risorse.
Necessari per una mappatura sono i nomi di questi elementi e le loro relazioni.
Le informazioni estraibili, relativamente alle code, al livello LRMS possono
essere elevate:
• Nome della coda
• Priorità
• Nome dello scheduler
• Limite di CPU
Tommaso Foglia 961/147 Pagina 27 di 150

• Limite di Walltime
• Limite di nodi accessibile dalla coda.
• Massimo numero di job che possono essere sottomessi da un singolo utente.
• Massimo numero di job che un processore può ottenere per ciascuna coda.
• Massimo numero di job che un host può sottomettere sulla coda.
• Numero degli slot (core) riservati ai job.
• Numero massimo di job che possono essere inseriti su tale coda.
• Massimo numero di job che possono essere messi in esecuzione in
contemporanea sulla coda.
• Tipologia di coda. Una coda può essere di tipo routine, execution o entrambe
routine/execution.
Molte di queste informazioni, anche se non aiutano direttamente a comprendere lo
stato di una coda, possono fare da contorno alle informazioni principali, ed essere
utilizzate per fornire un livello di dettaglio più elevato. Le informazioni che servono
a mostrare il reale stato di occupazione delle code sono quelle relative ai job
mentre,quelle che servono a controllare lo stato del sistema, facendo in modo che
questo resti all'interno delle soglie critiche, sono quelle relative al sistema. Tramite
queste informazioni si può capire realmente lo stato di una coda.
Informazioni relative ai job:
• Nome del Job;
• Nome della coda su è presente;
• Identificativo del job;
• Stato del job;
• Nome dell'utente, o del gruppo che ha sottoposto il job.
Tommaso Foglia 961/147 Pagina 28 di 150

Le informazioni per individuare eventuali livelli critici sono:
• Tempo in cui il job è eleggibile per essere mandato in esecuzione;
• Tempo in cui il job è stato mandato in esecuzione.
• Totale di walltime;
• Totale di memoria utilizzata;
• Totale di memoria virtuale utilizzata;
• Tempo di occupazione della CPU;
• Tempo in cui il job è stato creato;
• Tempo da cui il job è in coda;
Sapere l'host su cui un job è in esecuzione può ritornare utile per un amministratore di
sistema.
La considerazione importante da fare è che tutte le informazioni elencate sono
sempre reperibili a livello LRMS, tramite diretta interrogazione del batch system,
l'unico requisito richiesto ai batch system, per poter essere monitorato dal sistema
progettato, pertanto è di disporre di comandi adeguati (strumenti client del LRMS)
per poter recuperare tutte le informazioni elencate, che formattate in maniera
opportuna verranno utilizzate dal sistema di monitoraggio per presentarle ad utenti ed
amministratori.
Tommaso Foglia 961/147 Pagina 29 di 150

3.2 Le informazioni fornite dai batch system
Le informazioni recuperate dai batch system, per poter essere effettivamente
utilizzate dal sistema progettato, devono essere formattate in modo opportuno. Tra le
varie tecnologie a disposizione si è pensato di adottare quella che è diventata uno
standard de facto per la rappresentazione delle informazioni: XML, un metaliguaggio
di markup, che garantisce una facile integrazione. La struttura del documento XML, è
stata pensata per contenere tutte le informazioni sulla configurazione statica del sito
monitorato, informazioni necessarie per un corretto funzionamento del sistema.
Il nodo root del documento è Siteconfig, i suoi figli sono i nodi Queue, ognuno di
essi indica una coda, per ogni coda sono presenti le Vo aventi accesso ad essa, ogni
Vo contiene nodi Group che indicano tutti i gruppi in cui è suddivisa la Vo.
Figura 10: Schema della configurazione della mappatura.
I nodi Queue possono contenere anche nodi Other che indicheranno gli utenti locali,
cioè quelli aventi accesso alla coda, ma non appartenenti a nessuna Vo. Le specifiche
Tommaso Foglia 961/147 Pagina 30 di 150

descritte nel documento “Configuration of Virtual Organizations in gLite 3.0” sono
state tenute di conto nella scelta della struttura dell'albero XML, un documento che
fornisce dettagli sulla gestione delle caratteristiche delle virtual organization nei
sistemi Grid.
Il sistema offre la possibilità di utilizzare un file di testo contenente l'elenco delle
code, vo, gruppi e utenti, nel caso in cui non si disponga di un file di configurazione
in XML ed in tal caso, il file XML di configurazione viene creato dal sistema.
Le informazioni minime che devono essere presenti, nell'ordine, sono le parole
chiavi: Queue, Vo, Group e Other.
• Queue : è il nome della coda;
• Vo succesive alla queue: sono le virtual organization aventi permesso di
esecuzione sulla coda;
• Group successivi alla Vo: sono i gruppi facenti parte della virtual organization;
• Other: sono gli utenti semplici che non appartengono a nessna VO ma hanno
lo stesso permessi di esecuzione sulla coda.
Elemento root del documento è il nodo Data e per ogni job presente sulle code sarà
presente un nodo Job. Ogni nodo job contiene i seguenti figli:
• Job_Owener, nome dell'utente che ha mandato in esecuzione il job;
• Job_Name, nome del job;
• resource_used, risorse usate, che contiene 4 nodi:
• cput, che indica il tempo di cpu utilizzato;
• mem e vmem, quantità di memoria e memoria virtuale usata;
• walltime, tempo reale di esecuzione del programma ;
• job_state, lo stato del job;
• queue, nome della coda su cui il job è presente;
Tommaso Foglia 961/147 Pagina 31 di 150

• exec_host, nome dell'host su cui il job è in esecuzione;
• ctime, tempo in cui il job è stato creato;
• qtime, tempo in cui il job è diventato eleggibile per essere eseguito;
• etime, tempo da cui il job è in coda;
• start_time, tempo in cui il job è stato sottomesso.
Figura 11: Albero Xml del file contenente le informazioni sui job.
Queste rappresentano le informazioni realmente necessarie ad un corretto
funzionamento del sistema di monitoraggio, in questo modo si potranno avere
informazioni sullo stato di utilizzo delle code e si potranno tenere sotto controllo i
livelli critici, in termini di spazio e tempo occupati sulle code.
E' possibile fornire in input al sistema un ulteriore documento XML per quanto
riguarda le informazioni aggiuntive sulle code.
Tommaso Foglia 961/147 Pagina 32 di 150

L'elemento root del documento è il nodo Data, i cui figli sono i nodi Queue, uno per
ogni coda presente nel sito, per ogni coda sono presenti i nodi:
• Name, il nome della coda;
• Prio, che indica la priorità della coda;
• TypeQueue, che indica la tipologia di coda. Una coda può essere di tipo
routine, execution o entrambe routine/execution;
• TypeScheduler, che contiene il nome dello scheduler che gestisce la coda;
• cput, il limite di tempo di occupazione della CPU;
• walltime, il limite di Walltime;
Tommaso Foglia 961/147 Pagina 33 di 150

• numSlot, il numero degli slot (core) riservati ai job;
• maxJob, che contiene: Num, il numero massimo di job che può essere inserito
sulla coda; FromUsers, il massimo numero di job che può essere sottomesso
da un singolo utente.
• FromHost, il massimo numero di job che un host può sottomettere sulla coda.
• Proc, il massimo numero di job che un processore può ottenere per ciascuna
coda.
• Run, il massimo numero di job che possono essere messi in esecuzione in
contemporanea sulla coda.
Figura 13: Struttura del file xml contenente le informazioni aggiuntive sulle code.
Queste informazioni, non utilizzate immediatamente, per la creazione dei grafici,
vengono comunque storicizzate per favorire e facilitare un futuro ampliamento del
sistema.
Tommaso Foglia 961/147 Pagina 34 di 150

3.3 Esempi di batch system: PBS e LFS
Tra i software in circolazione che realizzano batch system indichiamo:
• PBS( Portable Batch System)/MAUI
• LSF (Load Sharing Facility)
Uno dei software open source maggiormente utilizzati per la gestione delle code in
ambienti di calcolo scientifico è PBS (Portable Batch System). Disponibile per varie
piattaforme, supporta job di tipo batch,paralleli ed interattivi, dispone di API per
l'aggiunta di nuovi comandi per integrarsi in altre applicazioni e per utilizzare dei
particolari algoritmi di scheduling, inoltre dispone di un'interfaccia grafica.
Le componenti di PBS sono:
• PBS supporta comandi sia da interfaccia grafica sia da linea di comando. E'
possibile sottomettere, modificare, cancellare e monitorare i job.
• job Server: rappresenta il punto centrale del sistema PBS, manda in esecuzione
il pbs_server, un demone, tutti gli altri comandi sono altri demoni che
comunicano con il server tramite IP. Il principale ruolo del server è fornire i
servizi per la ricezione, creazione, modifica, cancellazione di job, e deve
proteggere da eventuali crash del sistema. Ogni coda consiste in un insieme di
job, ed ogni server gestisce una o più code (queue), anche se non seguono uno
scorrimento ordinato. Esistono 2 tipi di code: routing e execution; i job
presenti sulle code di routing sono destinati a cambiare coda, mentre quelli
sulle code di executionsono pronti per essere eseguiti.
• job Executor, è il demone pbs_mom, che manda i job in esecuzione, e si
occupa anche di ritornare l'output all'utente.
• job Scheduler, è il demone che contiene le politiche di esecuzione dei job,
controllando dove e quando un job viene eseguito.
Tommaso Foglia 961/147 Pagina 35 di 150

Figura 14: Struttura di uno batch system di tipo PBS.
Il batch system PBS generalmente utilizza lo scheduler MAUI/MOAB, open source e
multi-piattaforma. MAUI permette agli amministratori del sito di ampliare i controlli,
inserendo nuove policy per lo scheduling dei job, e fornisce ad utenti ed
amministratori informazioni relative ai job, e all'allocazione delle risorse. Per
ottimizzare l'utilizzo delle risorse di calcolo si assegnano ai job delle priorità di
esecuzione La logica su cui si basa il sistema fa in modo di effettuare un'occupazione
“intelligente” delle risorse utilizzando una combinazione di parametri di
configurazione (preemption, node reservation, backfill, fairshare, ecc.). Sono
numerose le caratteristiche considerate dallo scheduler per la gestione delle priorità
Tommaso Foglia 961/147 Pagina 36 di 150

associate ai job: numero di processori richiesti, caratteristiche dei processori, tempo
d'esecuzione del job, tempo di esecuzione già trascorso, ecc.
La logica adottata per l'assegnazione delle priorità è complessa e prevede una
suddivisione delle caratteristiche su 3 livelli.
• Diverse famiglie di attributi costituiscono il primo livello, dette componenti, a
cui è associato un limite, che indica il valore massimo possibile, e un peso,che
indica l'importanza di quell'attributo.
• I singoli attributi che formano le componenti costituiscono il secondo livello,
ad ognuno di essi è associato un peso.
• Nel terzo livello invece sono presenti gli effettivi valori dei singoli attributi
presenti al secondo livello.
Sia lo scheduler che l'amministratore possono scegliere valori diversi e decidere di
assegnare priorità elevata a determinati gruppi o utenti. Lo scheduler inoltre analizza
le informazioni dinamiche che danno lo stato effettivo delle code.
Dunque il lavoro fatto effettivamente dallo scheduler, per il calcolo della priorità
pesata e della priorità di una componente, consiste in rigidi calcoli che determinano la
policy per l'esecuzione dei job.
LSF (Load Sharing Facility) , sviluppato dalla Platform Computing, una società
canadese, è un sistema per la gestione del carico di lavoro e monitoraggio delle
risorse di calcolo e dei job utente. Ideato per lavorare su sistemi distribuiti, permette
di unificare logicamente tutti i nodi da gestire, in modo da visualizzarli come un
unico sistema. Dispone di un set di comandi per conoscere lo stato delle risorse,
sottomettere job di tipo batch, interattivi e paralleli, e controllarne lo stato.
L'architettura si presenta scalabile e adatta ad ottenere alte prestazioni gestendo
milioni di utenti e di job concorrenti. E' formato da:
• usufruendo di meccanismi automatici implementa un insieme di politiche per
la gestione dello scheduling che rendono sempre meno necessario l'intervento
Tommaso Foglia 961/147 Pagina 37 di 150

degli amministratori;
• strumenti per la gestione di situazioni di errore, che consentono di operare
anche nel caso di crash dei cluster.
Tramite tecniche di controllo di accesso alle risorse riesce a garantire la sicurezza del
sistema.
Gli host sono suddivisi da LSF in tre categorie:
• server, che possono sottomettere ed eseguire i job;
• client, da cui vengono sottoposti i job;
• il master che è un particolare server con funzioni di gestioni riguardo lo
scheduling e l'esecuzione dei job.
Sul master host sono in esecuzione due importanti demoni:
• il Master Batch Deamon (mbatchd): riceve le richieste di sottomissione e
gestisce i job nelle code;
• il Master Batch Scheduler Deamon (mbschd): esegue lo scheduling,
Tommaso Foglia 961/147 Pagina 38 di 150

considerando le risorse disponibili e le richieste dei job.
Lo Slave Batch Deamon (sbatchd) è in esecuzione su ogni host. E' un demone che
riceve le richieste di esecuzione provenienti dal Master Batch Deamon, ed avvia
un'istanza di Remote Execution Server (res) che è l'ambiente reale su cui viene
eseguito il job. Inoltre ha il compito di controllarne lo stato.
Il Load Information Manager, (lim), è un'altro componente fondamentale del sistema
LSF. Raccoglie informazioni statiche e dinamiche relative all'host: numero e modello
di processori, di dischi, memoria disponibile, stato dell'host, ecc. Queste informazioni
vengono inviate al Master Load Information Manager (master lim), che le fornisce al
mbatchd; quest'ultimo le invia al mbschd che le utilizza per le policy di scheduling.
Se il master lim non è disponibile, vengono fornite al Process Information Manager
(pim), un demone in esecuzione su ogni server host, che invia informazioni sui job
allo sbatchd. Lo scheduling LSF è del tipo First Come Fist Served(FCFS), e il calcolo
effettuato dallo scheduler, a causa delle numerose informazioni che occorre tenere in
considerazione risulta molto complesso.
Figura 16: Esempio di scheduling.
Tommaso Foglia 961/147 Pagina 39 di 150

Per ogni coda l'amministratore associa un tempo massimo di esecuzione dei job (T) e
una priorità (P), tali misure sono inversamente proporzionali, infatti al crescere di T
diminuisce la priorità; infatti una coda short, cioè a breve tempo d'esecuzione, ha
priorità maggiore rispetto ad una coda long. Questo dà precedenza ai job più brevi.
La priorità, inoltre, può essere associata ad un singolo utente, o ad un gruppo, la
priorità maggiore è indicata dalla variabile MAX_USER_PRIORITY.
La priorità per gli utenti può essere assegnata direttamente dall'amministratore, in
modo manuale, oppure dallo scheduler in modo automatico, considerando il numero
totale di job sottoposti, la quantità di risorse richieste, tempi di esecuzione, ecc.
In caso di parità di priorità viene applicato il FIFO, first in first out. Generalmente lo
scheduler considera prima la priorità della coda e in seguito considera quella dei job.
Ecco alcuni esempi di comandi messi a disposizione dai batch system descritti, per
poter recuperare le informazioni necessarie per l'attività di monitoraggio.
Per il sistema PBS, esaminiamo questi due comandi:
1. qstat -q
2. qstat
Il primo comando interroga lo stato del sistema con attenzione alle code. Molte sono
le informazioni che vengono recuperate:
• Queue indica il nome della coda;
• Memory indica la massima quantità di memoria disponibile per un job;
• Cpu Time è il massimo tempo di cpu che un job può richiedere;
• Walltime massimo wall time disponibile per un job;
• Node massimo numero di nodi che un job può richiedere;
• Run massimo numero di job in running sulla coda;
• Que massimo numero di job in coda;
Tommaso Foglia 961/147 Pagina 40 di 150

• Lm massimo numero di job eseguibili contemporaneamente;
• State indica lo stato della coda.
Il secondo comando, invece, interroga lo stato dei job con attenzione anche
all’utente/gruppo di provenienza:
• Job id è l’identificativo del job;
• il campo Name indica il nome del job;
• User, rappresenta l'utente o il gruppo di provenienza del job;
• Time Use indica il tempo di occupazione della CPU;
• il campo S indica lo stato del job;
• Queue rappresenta il nome della coda su cui il job è presente.
Per quanto riguarda LSF , i comandi utilizzabili sono:
1) bqueue -w
2) bjobs -W -u all
Il primo comando permette di interrogare lo stato delle code:
• QUEUE_NAME rappresenta il nome della coda
• PRIO rappresenta la priorità della coda
• STATUS indica lo stato della coda
• MAX rappresenta il massimo numero di slot messi a disposizione sulla coda
JL/U rappresenta massimo numero di job che può essere sottoposto da un
singolo utente
• JL_P indica massimo il numero di job che un processore può ottenere per
ciascuna coda
• JL_H indica il massimo numero di job che un host può sottomettere sulla coda
Tommaso Foglia 961/147 Pagina 41 di 150

NJOBS rappresenta il numero totale di job presenti sulla coda
• PEND rappresenta il numero totale di job in attesa presenti sulla coda
• RUN rappresenta il numero totale di job in running
• SUSP indica il numero totale di job sospesi presenti sulla coda
• RSV il numero degli slot riservati agli job in stato pending
Il secondo comando pone particolare attenzione all’utente che ha sottoposto il job, ai
tempi di occupazione della coda e alla memoria usata:
• JOBID rappresenta l’identificativo del job presente sulla coda
• USER indica il nome dell’utente che ha sottoposto il job
• STAT lo stato del job
• QUEUE indica il nome della coda
• FROM_HOST rappresenta il nome dell’host da cui il job è stato sottoposto
• EXEC_HOST indica il nome dell’host su cui il job è in esecuzione
• JOB_NAME è il nome del job
• SUBMIT_TIME indica il tempo di sottomissione del job
• PROJ_NAME il nome del progetto di cui il job fa parte
• CPU_USED tempo di utilizzo della cpu
• MEM quantità di memoria utilizzata;
• SWAP quantità di memoria virtuale usata
• PIDS identificativo/i dei processi legati al job;
• START_TIME tempo di inizio dell'esecuzione del job
Tommaso Foglia 961/147 Pagina 42 di 150

• FINISHED_TIME tempo di fine esecuzione
Altre informazioni da recuperare dai batch system, sono quelle relative alla
mappatura del sito.
Per LSF i comandi utilizzabili sono:
• bqueues –l,
• bugroup –l nome_gruppo
Il primo comando serve per catturare l’elenco delle code presenti, e l’elenco di
gruppi e utenti semplici autorizzati all’utilizzo e per estrarre i nomi delle Vo;
Il secondo comando serve , per estrarre tutti i gruppi facenti parte delle Vo, e gli
utenti semplici.
Per PBS:
• qmgr -c 'p s'
• qmgr -c ‘p q nome_coda’
Il primo comando serve per controllare la configurazione completa del server, ed
estrarre le code presenti;
Il secondo comando serve per estrarre i nomi delle Vo e dei gruppi presenti, e gli
utenti semplici.
I sistemi di gestione delle risorse di calcolo descritti: PBS e LSF, dispongono di
strumenti per ottenere un elevato numero di informazioni statiche e dinamiche
sull'organizzazione topologica e sullo stato effettivo delle risorse di calcolo. Hanno
come punto in comune il dover conoscere i requisiti dei job e lo stato effettivo delle
risorse, per poter decidere in maniera automatica, su quale worker node smistare
effettivamente un job.
Tommaso Foglia 961/147 Pagina 43 di 150

4 La modularità del portale di monitoraggio del Tier2 di Napoli
4.1 Organizzazione dei servizi
Il portale è un servizio che opera da mediatore di informazioni a favore degli utenti
della rete, consentendo agli utilizzatori di raggiungere una grande quantità di
informazioni attraverso un prestabilito punto d'ingresso nella rete. Non è facile
determinare un'unica definizione per questo termine, che pur essendo recente, è uno
dei più diffusi ed utilizzati.
Il portale è un punto di accesso unico ad un insieme di servizi, dati e applicazioni.
Facilita il lavoro di ricerca essendo un aggregatore di informazioni e mettendo a
disposizione un servizio di navigazione sulla rete. Principalmente ha il compito di
favorire la collaborazione, la gestione dei contenuti e l'aggregazione di applicazioni.
La capacità di integrazione fa del portale uno strumento con enormi potenzialità. Dal
punto di vista dell'interfaccia utente, indipendentemente dalla soluzione
d'integrazione scelta, un portale può svolgere il ruolo importante dell'integrazione
delle applicazioni o dei servizi costituenti un sistema informativo. In questo modo
l'utente potrà accedere alla medesima interfaccia in modo facile e personalizzato a
diverse sorgenti d'informazione. Inoltre un portale è un ottimo gestore di contenuti.
L'informazione, disponibile sotto varie forme multimediali, testo, foto o video, viene
organizzata ed integrata per permettere all'utente di accedere in modo efficace ed
omogeneo ad un argomento di suo interesse. Per gestire l'eterogenericità dei contenuti
da pubblicare viene utilizzato un CSM(Content Management System), capace di
garantire un simile risultato grazie alle sue funzionalità gestionali. Grazie al CSM
ogni utente è capace di gestire interattivamente i propri spazi e i propri contenuti. Dal
punto di vista della collaborazione è importante sottolineare che un portale è in grado
di fornire i tipici strumenti utilizzati da un team di lavoro. Instant messaging, mail,
message board, shared calendar e wiki sono strumenti utilizzabili all'interno di un
Tommaso Foglia 961/147 Pagina 44 di 150

portare per favorire la collaborazione di un team di lavoro in una rete aziendale.
Come vedremo in seguito una piattaforma per la realizzazione di portali di alto livello
abilita con un unico strumento la aggregazione di applicazioni, la possibilità di
pubblicate contenuti e le funzionalità per la collaborazione tra gli utenti. È evidente
che tutte queste possibilità insieme aprono scenari infiniti al progettista web, molto
più vasti di quelli tipici di una applicazione web verticale e quindi anche più
complessi da affrontare e da indirizzare correttamente per ottenere risultati efficaci e
di reale utilità per gli utenti.
Tommaso Foglia 961/147 Pagina 45 di 150

4.2 Struttura di un portale
La struttura di navigazione risulta essere un aspetto molto importante nella creazione
di un portale. Esso deve incoraggiare la ricerca e l'esplorazione allo stesso modo. La
struttura, quindi, deve fornire continui stimoli all'utente oltre a guidarlo in modo
chiaro alla navigazione, facendo si che possa giungere facilmente alle informazioni
ricercate. I criteri di strutturazione devono essere pensati in modo che risultino chiari
al pubblico che dovrà essere aiutato e incoraggiato nell'esplorazione.
Normalmente la suddivisione di un portale dovrà tenere conto di sottocategorie e
sottoargomenti dell'argomento principale da presentare all'utente. La homepage
generale che andrà a rappresentare il punto cardine di accesso al sito, raccogliendo
informazioni e titoli provenienti da tutte le sezioni; contenendo una selezione delle
notizie più importanti. Alla homepage possono essere associate ulteriori pagine di
navigazione che risultano indipendenti dalle varie sezioni. Quando andiamo a
definire le diverse sezioni ci ritroviamo in una struttura già vista se pur in una forma
più piccola; costituita a sua volta da una homepage e in merito alla complessità della
sezione, zero o più pagine di navigazione.
Queste pagine danno accesso alle informazioni vere e proprie , che possono essere
anche condivise tra più sezioni. Inoltre insieme a questa struttura che può definirsi
gerarchica esiste un'organizzazione di collegamenti ipertestuali, che connettono in
maniera libera homepage, homepage sezioni, pagine di navigazione, documenti e
ogni altro tipo di informazione che si ritenga essere utile presentare.
4.2.1 Java Portlet e Portlet Container
Iniziamo ad entrare nel mondo Java ed a esaminare ciò che la piattaforma offre per la
realizzazione di portali. In questo ambito vi è stata una grande evoluzione negli ultimi
anni e da una situazione di immaturità e incompletezza di specifiche e strumenti si è
arrivati oggi a una situazione in cui si può realmente dire di avere a disposizione
Tommaso Foglia 961/147 Pagina 46 di 150

standard e tecnologie che consentono di realizzare portali web in modo efficiente e
completo.
Il tutto ha le sue fondamenta nelle Java Portlet che è l’argomento che ci accingiamo a
discutere. La Java Portlet Specification 1.0 definita nell’ambito della JSR 168 fu
rilasciata nell’ottobre 2003.
Questa è stata la prima specifica che definiva molti aspetti sulle portlet ed ebbe una
notevole importanza perché diede una prima standardizzazione a un ambito che fino
ad allora era andato sviluppandosi senza seguire una linea comune. La specifica,
sebbene costituisse un primo passo verso la standardizzazione, non copriva molti
importanti aspetti.
A febbraio 2006 fu costituito il JSR 286 Expert Group al fine di arrivare alla Java
Portlet Specification 2.0 rilasciata nel giugno 2008 che costituisce lo standard attuale
per le portlet, le cosiddette Portlet 2.0. Vediamo meglio come possiamo definire una
Portlet.
Esistono definizioni diverse più o meno rigorose da un punto di vista tecnico ma
quella forse più semplice e di immediata comprensione è la seguente: una portlet è
una applicazione web che viene eseguita in una porzione di una pagina web.
Il paradigma di funzionamento di una portlet è analogo a quello di una servlet visto
che parliamo sempre di un modello richiesta/risposta.
Chi ha familiarità con le servlet, e con le JSP, sa però che questi componenti sono
responsabili del rendering di una intera pagina web.
Con le portlet il discorso cambia poiche’ una singola portlet con le sue funzionalità è
responsabile solo di una porzione dell’intera pagina web.
Tommaso Foglia 961/147 Pagina 47 di 150

Possiamo quindi pensare alle portlet come a tanti mattoncini che messi insieme vanno
a costituire la nostra pagina web. Ecco le principali differenze tra portlet e servlet:
✗
sono componenti più semplici e quindi più leggeri, ciò consente una maggior
facilità di gestione.
✗
non possono essere raggiunte da un url specifico, in quanto è il portale interno
ad avere associato l'indirizzo.
✗
non posseggono la comunicazione con il browser, quindi non permettono di
inviare redirect o errori
✗
non possono rappresentare pagine web complete, ma solo singoli componenti.
Figura 17: Esempio di Portlet di una pagina web
Tommaso Foglia 961/147 Pagina 48 di 150

Affinchè le portlet possano essere eseguite, è necessario un ambiente dedicato,
un container, il portlet container, che è il corrispondente di ciò che è il servlet
container per le servlet. È il portlet container che assolve ai compiti infrastrutturali
necessari al corretto funzionamento di questi elementi di interfaccia detti portlet.
Da un punto di vista del deployment, una portlet non è altro che una web application,
un .WAR per intenderci, molto simile a una normale web application ma ovviamente
con alcune specificità.
Con le portlet è possibile comporre in un’unica pagina funzionalità distinte che
operano su sorgenti dati diverse.
Ciò consente di aggregare, in una interfaccia omogenea, dati e applicazioni
eterogenee senza costringere l’utente a viaggiare tra applicativi diversi per eseguire le
funzionalità di cui ha bisogno.
Il Portlet Container fornisce alle portlet il necessario ambiente di esecuzione, inoltre
fornisce loro il contesto, gestendo il loro ciclo di vita e infine il comporntamento. E' il
container ad istanziare le portlet prima che vengano richieste e lanciare eccezioni se
qualcosa va male.
Il portal server esegue il lavoro finale di aggregazione delle portlet applications e
delle singole portlet. In particolare il portal server esegue la spedizione delle request e
tute le portlet contenute in una singola pagina svolgendo quindi il lavoro di
orchestrazione e coordinamento.
La generazione di una pagina di un portale avviene attraverso questi fondamentali
passi:
1. Il contenuto per gli utenti, statico o dinamico, dipendente dalla logica
dell'applicazione della portlet, viene generato da ogni portlet.
2. Il portlet container riceve i dati generati dal server portlet.
3. Il container manipola le informazioni per il server portal.
4. Il server portal ha il compito della creazione della pagina del portale, costituita
essenzialmente da codice HTML generato automaticamente utilizzato dal
Tommaso Foglia 961/147 Pagina 49 di 150

owser. In base alle scelte di layout che ciascun portlet si porta dietro, il
server portal le applica per una corretta visualizzazione.
5. La pagina creata viene inviata dal server al browser.
6. L'utente può visualizzare il contenuto nel browser.
La pagina è pronta per effettuare interazioni con l'utente.
Tommaso Foglia 961/147 Pagina 50 di 150

4.3 Un'esempio di Enterprice Portal: Liferay
Un portale d'informazione aziendale noto è l'Enterprise Information Portal. E' una
struttura che consente di integrare informazioni, persone e processi attraverso spazi
organizzativi. Esso offre un punto di accesso unificato e sicuro, spesso nella forma di
un'interfaccia utente basata sul web, disegnato per aggregare e personalizzare
informazioni attraverso portlet.
Nel 2001 è nato Liferay, un'Enterprise Portal candidato ad aiutare le organizzazioni a
collaborare in un modo più efficiente mettendo a disposizione una serie consolidata di
applicazioni pronte all'uso. Utilizzato da piccole, medie e grandi aziende in tutto il
mondo presenta inoltre un elenco di funzionalità tali da metterlo a confronto con altri
portali commerciali, con il privilegio di essere open source. Svolge la funzione di
Web Container, permettendo di considerare una pagina come un'aggregazione di
moduli web, destinati a contenere applicazioni. Totalmente basato su tecnologia
JAVA, J2EE , consente di impiegarlo insieme a differenti application server, database
e sistemi operativi. Tra le proprietà basilari ci sono:
• Java Server Face con l'utilizzo di JSR 252
• Portlet specification e JSR 168
• Full J2EE se associato a Jboss Application Server
• WSRP 2.0
Il portale inoltre concede agli utenti di:
• Personalizzare temi e layout.
• Gestire le portlet mediante un'organizzazione gerarchica detta Interportlet
Comunication (IPC).
Tommaso Foglia 961/147 Pagina 51 di 150

• Elevata dinamicità, permettendo di creare, modificare ed eliminare portlet, di
personalizzarle, impostare livelli di sicurezza.
Liferay si basa su un'architettura orientata ai servizi denominata (SOA). Con SOA
(Service Oriented Architecture) si va ad indicare un'architettura software usata
persupportare l'utilizzo di Web Service e per assicurare l'interoperabilità tra diversi
sistemi, in modo tale da consentire l'uso delle singole applicazioni come parte
dell'intero processo gestionale. Le applicazioni, in questo modo, sono frutto
dell'unione di più servizi, che tra di loro risultano essere indipendenti garantendo il
massimo della riusabilità. La scelta ricade su Liferay in quanto offre una grande
quantità di servizi integrati di qualità ed un'ottima flessibilità. Tutto questo si va ad
includere con una grande capacità di organizzare e il supporto alla collaborazione.
Figura 18: Homepage di Liferay.
Dalla figura sovrastante si denota che il portale presenta un'interfaccia utente molto
semplice e chiara organizzata in modo tale da aiutare lo sviluppatore alla
finalizzazione del compito da effettuare. Dopo la fase di autenticazione con
l'immissione delle proprie credenziali il sistema passa ad uno stato che consente la
creazione delle pagine, in cui verranno inserite le portlet che s'intendono adoperare.
In particolare compare un bottone “AddPage” che provvederà alla creazione e
Tommaso Foglia 961/147 Pagina 52 di 150

all'inserimento della pagina nel portale.
In alto a destra, sotto il login sarà disponibile un menù per le opzioni. Tale menù è
composto da una collezione di sezioni dove è possibile fare operazione del tipo:
• Gestione della pagina
• Scelta del layout del template
• Aggiunta di un'applicazione
• Gestione Account
• Gestione Pannello di Controllo
Allo sviluppatore è concesso l'inserimento di una portlet all'interno della pagina,
tramite la pressione del pulsante “Aggiunga di un'applicazione”. Comparirà un menù
costituito da una lista di tutte le tipologie di portlet presenti nel portale. Inoltre c'è la
possibilità di aggiungere nuove portlet all'interno del portale attraverso o una ricerca
della nuova portlet da integrare o l'inserimento del file.war. La semplicità con cui si
effettuano i passaggi di inserimento, fa di Liferay uno strumento valido per la
pubblicazioni di nuove applicazioni.
Tommaso Foglia 961/147 Pagina 53 di 150

5 Progettazione di un sistema per il monitoraggio dello stato delle code
Mi è stato chiesto di ottimizzare, razionalizzare, progettare ed eseguire modifiche su
un prototipo per la realizzazione di grafici riguardanti le informazioni proveniente da
un sistema di monitoraggio.
Il modello di sviluppo utilizzato, è quello basato sul riuso, in modo da ottenere nuovi
sistemi integrando componenti esistenti. Questa tipologia di sviluppo è stata scelta
poiché si adatta particolarmente allo sviluppo di software object-oriented.
Ho sviluppato le nuove funzionalità secondo un'ottica incrementale, dove i requisiti
funzionali sono stati pensati nel complesso, ma ideati e sviluppati di volta in volta,
producendo così una prototipazione di tipo usa e getta.
Ho prodotto diversi Mock-ups del sistema, che andavano a contemplare le nuove
funzionalità offerte nell'interfaccia utente. In una prima fase ho fatto una raccolta dei
requisiti, sono poi passato ad una analisi dei componenti già esistenti. Ho considerato
la comparsa di alcuni requisiti non funzionali da parte del sistema. Ho progettato il
design del sistema integrato ai componenti esistenti, ho implementato in modo
incrementale le funzionalità arrivando così al rilascio finale dell'applicazione.
Tommaso Foglia 961/147 Pagina 54 di 150

5.1 Raccolta dei requisiti e casi d'uso.
Nelle primissime fasi di progettazione mi sono dedicato all'individuazione dei
requisiti ponendo attenzione a quelle che potessero essere le richieste dell'utente e a
quelle che invece potessero essere le richieste del sistema.
I requisiti funzionali, atti a descrivere i servizi e le funzioni offerte dal sistema,
osservato dal punto di vista dell'utente, sono :
✔ Il primo requisito funzionale riguarda la possibilità di poter visualizzare in
tempo reale i grafici tramite interfaccia web.
✔ Il secondo requisito funzionale riguarda la possibilità di storicizzare i dati,
utilizzando un'ampia finestra temporale, in modo da poter ricreare grafici di
eventi passati.
✔ Il terzo requisito funzionale riguarda la possibilità di poter visualizzare dei
grafici creati ad hoc su intervalli temporali a scelta dell'utente.
I seguenti sei casi d'uso potrebbero descrivere il funzionamento del sistema:
Tommaso Foglia 961/147 Pagina 55 di 150

Attraverso il formalismo di Cockburn esaminiamo i vari use case.
USE CASE #1
SCELTA CRITERIO TEMPORALE
GOAL IN CONTEXT Modificare il criterio di visualizzazione temporale
PRECONDITIONS
SUCCESS END
CONDITIONS
FAILED END
CONDITIONS
PRIMARY ACTOR
TRIGGER
Il server Tomcat ha distribuito l'applicazione e caricato la
pagina JSP. Il sistema ha già creato i grafici.
L'applicazione visualizza i grafici relativi al criterio temporale
scelto dall'utente.
Nessuna.
Utente
Selezione di un radio button(daily,weekly,monthly,annual)
DESCRIPTION STEP n° USER SYSTEM
1 Seleziona un radio
button raffigurante
una scelta
temporale
2 Il sistema ricarica la
pagina.
3 Viene aggiornata la
variabile di
sessione “iltempo”
4 Vengono
visualizzati i grafici
relativi al criterio
temporale scelto.
USE CASE #2
SCELTA CRITERIO VISUALIZZAZIONE
GOAL IN CONTEXT Modificare il criterio di visualizzazione
PRECONDITIONS
SUCCESS END
CONDITIONS
FAILED END
CONDITIONS
PRIMARY ACTOR
Il server Tomcat ha distribuito l'applicazione e caricato la
pagina JSP. Il sistema ha già crato i grafici.
L'applicazione visualizza i grafici relativi al criterio di
visualizzazione scelto dall'utente.
Nessuna.
Utente
Tommaso Foglia 961/147 Pagina 56 di 150

TRIGGER
Selezione di un radio button(queue,queue-details,VO,other)
DESCRIPTION STEP n° USER SYSTEM
1 Seleziona un radio
button raffigurante
un criterio di
visualizzazione
2 Il sistema ricarica la
pagina.
3 Viene aggiornata la
variabile di
sessione “ilcriterio”
4 Vengono
visualizzati i grafici
relativi al criterio di
visualizzazione
scelto.
USE CASE #3
SCELTA DELLA DATA DA VISUALIZZARE
GOAL IN CONTEXT Modificare la data relativa ai grafici visualizzati
PRECONDITIONS
SUCCESS END
CONDITIONS
FAILED END
CONDITIONS
PRIMARY ACTOR
TRIGGER
Il server Tomcat ha distribuito l'applicazione e caricato la
pagina JSP.
L'applicazione visualizza i grafici relativi alla data scelta
dall'utente.
Data inserita non corretta.Visualizzazione messaggio di
errore.
Utente
Seleziona tramite calendario Javascript una data e pressione
del tasto submit
DESCRIPTION STEP n° USER SYSTEM
1 Seleziona tramite
calendario
Javascript una data
e preme il tasto
submit
2 Il sistema ricarica la
pagina.
Tommaso Foglia 961/147 Pagina 57 di 150

EXTENSIONS A
EXTENSIONS B
3 Il sistema controlla
che la data rispetti i
vincoli.(posteriore
alla creazione del
database, non
successiva alla
data corrente)
4 Viene aggiornata la
variabile di
sessione “ladata”
5 Il sistema controlla
se i grafici relativi
alla data scelta
sono già stati creati
6 L'applicazione
visualizza i grafici
relativi alla data
scelta dall'utente.
Data non corretta
4a
5a
I grafici relativi alla
data selezionata
non sono stati
creati
6b
7b
Il sistema visualizza
un messaggio di
errore.
Il sistema ricarica la
pagina
visualizzando i
grafici relativi alla
data odierna
Il sistema fa una
chiamata alla
funzione per creare
i grafici relativi alla
data scelta
dall'utente
L'applicazione
visualizza i grafici
relativi alla data
scelta dall'utente.
Tommaso Foglia 961/147 Pagina 58 di 150

USE CASE #4
SELEZIONE PERIODO CUSTOM
GOAL IN CONTEXT Selezionare un periodo a scelta dell'utente
PRECONDITIONS
SUCCESS END
CONDITIONS
FAILED END
CONDITIONS
PRIMARY ACTOR
TRIGGER
Il server Tomcat ha distribuito l'applicazione e caricato la
pagina JSP.
L'applicazione visualizza i grafici relativi al periodo scelto
dall'utente.
Data inserita non corretta. Visualizzazione messaggio di
errore.
Utente
L'utente seleziona come criterio temporale “custom”
DESCRIPTION STEP n° USER SYSTEM
1 L'utente seleziona il
radio button relativo
al criterio temporale
“custom”
2 Il sistema ricarica la
pagina.
3 Viene aggiornata la
variabile di
sessione “iltempo”
4 L'applicazione
visualizza una
schermata per la
selezione di due
data.
5 L'utente seleziona
le due date tramite
calendario
Javascript e preme
il pulsante submit
6 Il sistema ricarica la
pagina.
7 Il sistema controlla
che la data rispetti i
vincoli.(posteriore
alla creazione del
database, non
successiva alla
data corrente,
inversione tra inizio
e fine periodo)
8 Viene aggiornata la
Tommaso Foglia 961/147 Pagina 59 di 150

EXTENSIONS A
EXTENSIONS B
variabile di
sessione “ladata1”
e “ladata2”.
9 Il sistema controlla
se i grafici relativi al
periodo scelto
siano già stati
creati.
10 L'applicazione
visualizza i grafici
relativi al periodo
scelto dall'utente.
Data non corretta
8a
9a
I grafici relativi al
periodo
selezionato non
sono stati creati
10b
11b
12b
13b
Il sistema visualizza
un messaggio di
errore.
Il sistema ricarica la
pagina per la scelta
delle due date.
Il sistema fa una
chiamata alla
funzione per creare
i grafici relativi alla
periodo scelto
dall'utente
L'applicazione
tramite funzione
Javascript
visualizza una
finestra scura per
segnalare
l'elaborazione
all'utente.
L'applicazione
visualizza i primi
grafici relativi al
periodo
selezionato.
Il sistema effettua
un refresh della
Tommaso Foglia 961/147 Pagina 60 di 150

pagina ogni 20
secondi.
Riposizionando lo
scroll bar nella
posizione in cui era
precedentemente.
USE CASE #5
SELEZIONE CODA
GOAL IN CONTEXT Selezionare una coda in particolare
PRECONDITIONS
SUCCESS END
CONDITIONS
FAILED END
CONDITIONS
PRIMARY ACTOR
TRIGGER
Il server Tomcat ha distribuito l'applicazione e caricato la
pagina JSP. Il sistema ha già crato i grafici.
L'applicazione visualizza i grafici relativi alla coda scelta
dall'utente.
Non ci sono grafici per la coda selezionata. Visualizzazione
del messaggio: “No results for this combination”.
Utente
Selezione di una coda dal menù di scelta.
DESCRIPTION STEP n° USER SYSTEM
EXTENSIONS A
1 Seleziona una coda
dal menù di scelta
2 Il sistema ricarica la
pagina.
3 Viene aggiornata la
variabile di
sessione “lacoda”
4 Il sistema ricrea la
lista effettuando
una query sulla
tabella code del
database e
visualizza la coda
selezionata
5 Vengono
visualizzati i grafici
relativi alla coda
selezionata
Nessun grafico per
Tommaso Foglia 961/147 Pagina 61 di 150

la coda selezionata
5a
Il sistema informa
l'utente con un
messaggio d'errore.
USE CASE #6
SELEZIONE VO
GOAL IN CONTEXT Selezionare una VO in particolare
PRECONDITIONS
SUCCESS END
CONDITIONS
FAILED END
CONDITIONS
PRIMARY ACTOR
TRIGGER
Il server Tomcat ha distribuito l'applicazione e caricato la
pagina JSP. Il sistema ha già crato i grafici.
L'applicazione visualizza i grafici relativi alla VO scelta
dall'utente.
Non ci sono grafici per la VO selezionata. Visualizzazione del
messaggio: “No results for this combination”.
Utente
Selezione di una VO dal menù di scelta.
DESCRIPTION STEP n° USER SYSTEM
EXTENSIONS A
1 Seleziona una VO
dal menù di scelta
2 Il sistema ricarica la
pagina.
3 Viene aggiornata la
variabile di
sessione “lavo”
4 Il sistema ricrea la
lista effettuando
una query sulla
tabella vo del
database e
visualizza la vo
selezionata
5 Vengono
visualizzati i grafici
relativi alla vo
selezionata
Nessun grafico per
la vo selezionata
5a
Il sistema informa
l'utente con un
Tommaso Foglia 961/147 Pagina 62 di 150

messaggio d'errore.
Dopo questa prima individuazione di quelli che sono i requisiti funzionali, riguardanti
cioè le funzionalità che un utente comune, può aspettarsi dal sistema, sono passato
all'analisi degli strumenti già esistenti, in modo da poter poi così delineare quale sarà
il design dell'applicazione e in modo da poter capire quali sono i requisiti non
funzionali.
Cioè quei requisiti che non espressi direttamente dall'utente, ma che sono richiesti dal
sistema, per un suo corretto funzionamento o per garantire usabilità e affidabilità.
Altri requisiti, dettati dal sistema possono scaturire dal suo dominio applicativo.
Tommaso Foglia 961/147 Pagina 63 di 150

5.2 Analisi del prototipo e degli strumenti già esistenti
Il lavoro di potenziamento delle funzionalità inizia dal prendere atto degli strumenti
già presenti, frutto del lavori di tesi di laurea di colleghi della stessa facoltà. In primis
bisogna ricordare lo schema per la memorizzazione delle informazioni provenienti
dal sistema di monitoraggio. Il lavoro di tesi di laurea del dott. Marazita, è incentrato
sulla creazione di un database di tipo Mysql ed è pensato per accogliere le
misurazioni necessarie ad una storicizzazione, suddivisa per intervalli temporali.
La mappatura del sistema fa uso delle seguenti tabelle:
• Job (#JobId , idQueue , StatusPBS, User, Queue_name, Job_name,
Submit_time, CPU_time, MEM, Exec_Host, Exec_time, WCT, Ctime,
P_Etime, SWAP, From_Host, MemLimit, P_Elapsed_time);
• Utenti (#IdUtente , User, IdGruppo );
• Gruppi (#IdGruppo, IdVo, Nome, Tipo);
• VO (#IdVo, Nome);
• Code (#IdQueue, Queue_name, Max, Description, lm_CPU_time,
lm_WallTime, L_RSV, L_JL_U, L_JL_P, L_JL_H, P_LmNode, P_LmQueue,
P_lm, P_type, P_Run);
• Vo-Coda (#IdVo , #IdCoda);
• Admin (#IdScheduler, Nome, TimeD, TimeW, TimeY ).
Per la mappatura, l'associazione gruppo-coda è stato delineato per risolvere il
problema di individuazione. Le tabelle Job e Code, sono quelle che porteranno il
maggior numero di informazioni per descrivere il sistema.
Per memorizzare le informazioni sullo stato delle code sono utilizzate le seguenti
tabelle:
• HD_coda(#IdQueue, #date, Tot, Run, Pend ,Held)
Tommaso Foglia 961/147 Pagina 64 di 150

• HD_vo(IdQueue, date, IdVo, Tot, Run, Pend, Held)
• HD_gruppo(#IdGruppo, #data, Tot, Run, Pend, Held)
• HW_coda(#IdQueue, #data, VTot, VRun, VPend, Vheld, MTot, MRun,
MPend, MHeld, DTot, DRun, DPend, DHeld)
• HW_vo(IdQueue, data, IdVo, VTot, VRun, VPend, Vheld, MTot, MRun,
MPend, MHeld, DTot, DRun, DPend, DHeld)
• HW_gruppo(#IdGruppo, #data, VTot, VRun, VPend, Vheld, MTot, MRun,
MPend, MHeld, DTot, DRun, DPend, DHeld)
• HM_coda(#IdQueue , #data, VTot, VRun, VPend, Vheld, MTot, MRun,
MPend, MHeld, DTot, DRun, DPend, DHeld)
• HM_vo(IdQueue, data, IdVo, VTot, VRun, VPend, Vheld, MTot, MRun,
MPend, MHeld , DTot, DRun, DPend, DHeld)
• HM_gruppo(#IdGruppo, #data, VTot, VRun, VPend, Vheld, MTot, MRun,
MPend , MHeld, DTot, DRun , DPend, DHeld)
• HY_coda(#IdQueue, #data, VTot, VRun , VPend , Vheld, MTot, MRun,
MPend, MHeld, DTot, DRun, DPend , DHeld)
• HY_vo(IdQueue, data, IdVo, VTot, VRun , VPend , Vheld, MTot, MRun,
MPend, MHeld, DTot, DRun, DPend, DHeld )
• HY_gruppo(#IdGruppo, #data, VTot, VRun, VPend, Vheld, MTot, MRun,
MPend, MHeld, DTot, Drun, DPend, Dheld)
Le tabelle HD_coda/vo/gruppo, HW_coda/vo/gruppo e HM_coda/vo/gruppo si
riferiscono agli stati del sistema delle ultime 24 ore (Day), degli ultimi sette giorni
(Week), degli ultimi 30 giorni(Month) e degli ultimi 365 giorni(Year). Nelle tabelle
relative al giorno si conserveranno le informazioni riguardanti i job (totali, running,
pending e sospesi) che risiedono sulla griglia al momento dell'osservazione.
Tommaso Foglia 961/147 Pagina 65 di 150

Per quanto riguarda le informazioni non giornaliere, si calcolerà la media, la varianza
e la deviazione standard relative alle ultime osservazioni effettuate sul sistema.
Oltre a conservare le informazioni relative alla mappatura tra gruppi,code,utenti e
VO, è realizzato per storicizzare le informazioni relative alle misurazioni giornaliere,
settimanali, mensili ed annue. In ogni tabella sono presenti sia le informazioni per
descrivere il reale stato dell'occupazione delle code, sia quelle relative al controllo dei
livelli critici, cercando di andare a formare uno storico che sia il più completo
possibile. Molto utile si è rilevato lo script per la creazione automatica del Database.
Figura 20: Struttura del Database Mysql Monitor utilizzato.
Il lavoro di tesi della dott.ssa Luisa Cesarano è rivolto alla creazione di un sistema
automatico per la parserizzazione automatica dei dati proveniente dal batch system.
Tommaso Foglia 961/147 Pagina 66 di 150

Capace di interfacciarsi sia con sistemi PBS che con sistemi LSF, il prototipo creato
interroga ad intervalli regolari i sistemi di gestione delle code, riuscendone a carpire
in tempo reale i cambiamenti.
La parserizzazione automatica delle informazioni avviene tramite applicazione JAVA,
denominata Parser, e permette l'inserimento automatico dei dati nella struttura dati
ideata dal dott. Marazita.
La storicizzazione dei dati avviene in un'ottica Round Robin( si parla di RRD, Round
Robin Database) dove, con finestra temporale fissa, i dati che non appartengono più
alla finestra temporale prestabilita vengono automaticamente sovrascritti da quelli
nuovi.
Questa metodologia permette di mantenere fissa la grandezza del Database,
sovrascrivendo i dati obsoleti non viene permesso un aumento dei record. Il Database
con l'applicazione deputata al suo popolamento è pensata per essere dislocata
geograficamente. Necessario è il collegamento con il batch system per cogliere i
cambiamenti sullo stato delle code.
E' compito di un altro modulo JAVA, StackedArea, quello di collegarsi al database
per effetuare le query. Estratti i dati l'applicazione ha il compito, di organizzarli, di
prepararli e tramite librerie JfreeChart di creare grafici che riescano a mostrare le
informazioni che sono state raccolte. I grafici creati mostrano le informazioni salienti
sullo stato di occupazione delle code, da parte di utenti, gruppi e/o VO.
Sono suddivisi principalmente secondo un criterio temporale, lo stesso che abbiamo
visto essere utilizzato nella formazione delle tabelle: giorno, settimana, mese, anno.
Il prototipo per la creazione di grafici è in grado di funzionare in due modalità: XML
e Database.
La prima modalità è quella che realmente è stata portata a termine. Sfruttando la
capacità di alcuni batch system di offrire informazioni sullo stato delle code già in
formato XML, i dati vengono recuperati tramite strumenti DOM e resi disponibili per
la creazione dei grafici tramite le librerie JfreeChart.
Tommaso Foglia 961/147 Pagina 67 di 150

In questa modalità il sistema è capace di fotografare la situazione dell'occupazione
delle code, ma non in grado di storicizzare la produzione, poiché i file XML vengono
di volta in volta sovrascritti, ad ogni aggiornamento del sistema.
La modalità Database, di cui abbiamo inquadrato il funzionamento generale, è stata
ideata e sviluppata, ma mai testata realmente.
Tommaso Foglia 961/147 Pagina 68 di 150

5.3 Design del sistema ed implementazione dei requisiti funzionali
Considerando l'integrazione con un Enterprise Portal, come Liferay, di cui ho già
parlato e considerando l'analisi degli strumenti già esistenti, per la realizzazione del
primo requisito, ho ritenuto opportuno ricollegarmi alla tecnologia JAVA utilizzando
una JSP(Java Server Page), in modo che l'integrazione con le tecnologie JAVA
esistenti, fosse il più semplice possibile.
Per la visualizzazione dei grafici salvati su disco fisso, ho esaminato il criterio di
memorizzazione. I grafici creati sono già suddivisi in cartelle secondo un primo
criterio, temporale, che li porta ad essere contenuti nella cartella di riferimento al
periodo che mostrano: i grafici mostranti le informazioni giornaliere saranno nella
cartella Giornalieri, quelli settimanali saranno contenuti nella cartella Settimanali,
quelli mensili saranno così contenuti nella cartella Mensile e così via.
Figura 21: Criterio di memorizzazione su disco.
Tommaso Foglia 961/147 Pagina 69 di 150

L'applicazione web, riesce a controllare l'intero contenuto di una cartella,
recuperando il numero dei file e il loro nome. Alla prima visita ho scelto di far
mostrare le informazioni più richieste dagli utenti del sistema, cioè quelle riguardanti
lo stato attuale delle code.
Verranno quindi visualizzati i grafici contenuti nella cartella Giornalieri. E' possibile
visualizzare i grafici relativi ad un altro periodo temporale. Ho inserito un form di
tipo HTML con dei RADIO BUTTON, il pregio di questa tecnologia, oltre a quella di
appesantire il carico della pagina, è quella di poter far visualizzare il criterio
correntemente utilizzato, evidenziandone subito l'eventuale cambiamento. I bottoni
riportano un'immagine che ne indica il tipo di criterio:
• Daily
• Weekly
• Montly
• Annual
• Custom
Nell'utilizzare i bottoni viene creata una variabile di sessione che ha il compito di
ricordare la scelta effettuata. Di default il valore è impostato a Giornalieri, ma
cambiandola viene memorizzata ed utilizzata per far apparire il tag checked
all'interno del bottone utilizzato.
Di seguito è visualizzato l'effetto sulla pagina JSP e parte del codice riguardante la
creazione del form per la scelta del criterio temporale e della creazione delle variabili
di sessione.
Figura 22: Dettaglio della barra di navigazione per la scelta del tempo.
Tommaso Foglia 961/147 Pagina 70 di 150

Figura 23: Codice della pagina JSP relativo alla formazione del menù per la scelta
del tempo e creazione della relativa variabile di sessione.
Stesso meccanismo viene utilizzato per la scelta del criterio di visualizzazione. Nelle
cartelle che abbiamo visto su disco fisso, sono contenuti diversi tipi di grafici, divisi
in quattro categorie.
I grafici contenuti nella cartella utilizzeranno la seguente nomenclatura:
• coda.
• codaDettagli...
• vo.
• other.
Per permettere una visualizzazione più ristretta, che permettesse la focalizzazione su
un solo tipo di grafici a cui si è interessati ho aggiunto una seconda serie di bottoni, il
cui funzionamento riprende il funzionamento visto precedentemente.
Tommaso Foglia 961/147 Pagina 71 di 150

I bottoni sono affiancati da una serie di immagini indicanti:
• queue
• queue details
• vo
• other
Figura 24: Dettaglio della barra di navigazione per la scelta del criterio di
visualizzazione.
Viene memorizzata una seconda variabile di sessione, che ha il compito di
memorizzare e quindi di ricordare quali tipi di grafico sti stanno visualizzando. Anche
qui è stato creato un criterio di default, infatti l'applicazione mostrerà al primo avvio
in grafici relativi alle code. Nell'immagine sottostante viene mostrato quello che
costituisce la barra di navigazione.
Figura 25: In figura è mostrata la scritta e la barra di navigazione con i bottoni per
applicare un diverso criterio di visualizzazione.
Per offrire una migliore interazione con l'utente, per fare in modo che si possano
visualizzare in modo immediato le informazione ricercate, ho pensato di fornire un
filtro sulle code attualmente monitorate dal sistema. In maniera dinamica, tramite
Tommaso Foglia 961/147 Pagina 72 di 150

l'integrazione di codice HTML e codice JAVA e stato possibile creare un form di
scelta con menù a tendina dove sono rappresentate le code attualmente sotto
osservazione da parte del sistema.
La pagina JSP si collega al database ed effettuando una query sulla tabella delle
code permette di creare un menù aggiornato su quelle che sono le code realmente
operanti.
Anche per questo filtro ho ritenuto opportuno creare una variabile di sessione, il cui
scopo è permettere di visualizzare i grafici desiderati, oltre al permettere di ricordare
la scelta effettuata.
Di seguito è visualizzato il codice di riferimento alla query sul database Mysql per la
creazione del menù di scelta.
Figura 26: Dettaglio del codice per la creazione del menù di scelta delle code, con
query sul database in tempo reale.
Tommaso Foglia 961/147 Pagina 73 di 150

Figura 27: Menù per la scelta della coda.
Lo stesso discorso avviene per le VO, dove l'applicazione, collegandosi al database
ed effettuando una query sulla tabella delle vo, permette la creazione del menù di
scelta con le VO che attualmente lavorano sulle code monitorate dal batch system.
Il tutto sarà visualizzato in un altro form. Anche qui è stata creata una variabile di
sessione per ricordare il filtro sulle VO.Nel caso in cui si stiano visualizzando i
grafici relativi alle codeDettagli, il sistema presenterà entrambi i menù di scelta, in
modo da poter filtrare i grafici in base ai due criteri: in base alle code , in base alle
VO o entrambi. In questo, la creazione di variabili di sessione, permette all'utente di
non dover riselezionare il filtro desiderato, ogni qual volta decida si sfogliare grafici
diversi. Ad esempio un utente di una determinata VO o operante su una determinata
coda, troverà utile poter visualizzare in maniera semplice solo le informazioni a cui è
interessato.
Tommaso Foglia 961/147 Pagina 74 di 150

Figura 29: Menù per la sceltà della VO.
Tommaso Foglia 961/147 Pagina 75 di 150

Figura 30: Visualizzazione in tempo reale delle code monitorare e delle VO operanti
sul sistema monitorato. Menù visibili quando si richiede di visualizzare i grafici
relativi ai dettagli delle code.
Per quanto concerne la realizzazione del secondo requisito, che richiedeva una
cospicua storicizzazione dei dati, c'è stato bisogno di intervenire sull'applicazione
Parser, per adeguarlo alle nuove esigenze.
Come già sottolineato, il prototipo non è mai stato testato, se non in locale, nella
modalità Database. La creazione dei grafici avveniva tramite la modalità XML.
Dovendo pensare ad una storicizzazione dei dati che permetta di conservare le
informazioni e di ricreare i grafici fino ai 2 anni precedenti, si è dovuti passare a
prendere in considerazione la modalità Database.
L'applicazione JAVA, Parser, che ha il compito di parserizzare le informazioni
provenienti dal batch system, per poi renderle disponibili all'inserimento nel database,
è stata creata come un processo in continua esecuzione che ad intervalli regolari di
tempo si attiva per carpire i nuovi cambiamenti e per effettuare gli inserimenti
all'interno del database.
Il meccanismo presenta un problema nella parserizzazione del file XML, che viene
creato automaticamente quando si interroga il batch system. Nel testare le
funzionalità della modalità Database ci si è resi conto che con il mutare dei dati,
l'applicazione effettua solo una prima parserizzazione del file XML(viene creato
l'albero DOM del documento XML solo una volta).
Tommaso Foglia 961/147 Pagina 76 di 150

Nelle successive attivazioni, tramite timer, del Parser, la parserizzazione del nuovo
file contenente le informazioni aggiornate non avveniva in modo corretto,
producendo un'immissione di record fotocopia all'interno del database.
E' stato necessario uno smembramento e la creazione, come mostrerò in Appendice,
di nuovi classi e metodi, per fare in modo che l'applicazione, tramite l'orologio di
sistema (crontab) riesca ad essere mandata in esecuzione nei momenti giusti per
effettuare degli inserimenti che rispecchino fedelmente la situazione reale.
E' stata modificata la signature del metodo principale che manda in esecuzione
l'applicazione, in modo che possa accogliere un flag temporale, inoltre è stata creata
una classe che permette di richiamare il giusto metodo per effettuare l'inserimento nel
database in base al corretto criterio temporale.
Per una riproduzione fedele dello stato di occupazione delle code è opportuno
interrogare costantemente ad intervalli regolari di 5 minuti, il batch system. Per
questo è stato utilizzato l'orologio di sistema per fare in modo che in automatico
venga lanciato uno script per l'aggiornamento.
Considerando che il batch system viene interrogato ad intervalli regolari di 5 minuti
si è pensato di lanciare in esecuzione l'applicazione, con lo stesso intervallo di tempo.
Utilizzando un flag 'giornaliero', in modo da produrre un inserimento nelle tabelle
giornaliere, si fa in modo che la tabella giornaliera sia popolata con i dati quanto più
sensibili al minimo cambiamento sullo stato monitorato.
La stessa scelta è stata effettuata per gli altri inserimenti. Cambiando il flag e
assegnando intervalli differenti, è possibile popolare anche le altre tabelle. Per avere
inserimenti settimanali si è pensato di fare un inserimento ogni 3 ore. Per quelle
mensili un inserimento ogni 12 ore e infine per quelle annuali ogni 5 giorni.
Di seguito sono visualizzate le chiamate che l'orologio di sistema (crontab) per fare in
modo che le giuste chiamate avvengano in modo automatico nei tempi giusti.
Tommaso Foglia 961/147 Pagina 77 di 150

Figura 31: Output del comando crontab -l per l'utente che ha installato
l'applicazione.
Sempre nell'ambito della mutabilità dei dati, sempre nel concetto che con dati statici
non ci si è trovati ad avere problemi, si è dovuto inserire qualche controllo sui dati,
per evitare che l'applicazione sollevi eccezioni.
Appurato il corretto funzionamento del Parser, per l'inserimento delle informazioni
all'interno del Database, ho dovuto modificare la finestra temporale, che con una
tecnica Round Robin, provvedeva alla sovrascrizione dei record passati.
Il Database, ha una finestra temporale di Round Robin, molto breve. Ha la capacità di
accogliere i dati che servono alla creazione dei grafici.
La tabella hd_coda, ad esempio, conterrà le informazioni relative alle misurazioni
giornaliere, ovvero avrà tutte le misurazioni dal momento preso in esame fino alle 24
ore precedenti.
Tommaso Foglia 961/147 Pagina 78 di 150

La tabella hw_coda, ad esempio, conterrà tutte le misurazioni settimanali, riguardanti
le informazioni dal momento preso in esame fino ai 7 giorni precedenti. Stesso
ragionamento avviene per le tabelle mensili ed annuali.
Il taglio automatico delle tabelle avviene in modo che nelle tabelle ci siano tutte e
sole le informazioni necessarie alla corretta creazione dei grafici.
Il prototipo è modellato su questo sistema e nel raccogliere queste informazioni non
prevede nessun filtro temporale, poiché necessita di tutte le informazioni presenti in
ogni tabella.
Nell'effettuare un ampliamento nella finestra di Round Robin, portando la
storicizzazione dei dati a 2 anni, tutte le tabelle saranno in grado di contenere i dati
relativi agli ultimi 2 anni di monitoraggio, rendendo consistente la crescita delle
tabelle giornaliere,settimanali e mensili, ma limitandone comunque superiormente la
crescita.
Perseguita una storicizzazione dei dati più cospicua, bisogna fare in modo che
l'applicazione per la creazione dei grafici, riesca a ricreare i grafici utilizzando
informazioni su un periodo passato, conservate all'interno del database.
L'applicazione per la creazione dei grafici utilizza delle query che prelevano l'intero
contenuto delle tabelle.
L'allargamento della finestra di Round Robin ha reso necessario una modifica al
modo di elaborare le query. Le query dovranno ospitare un filtro temporale, in modo
da poter recuperare solo i dati che sono realmente necessari alla determinazione dei
grafici per il periodo richiesto.
E' auspicabile che l'utente richieda di visualizzare i grafici di un periodo passato. Il
sistema deve fornire la stessa “fotografia” che avrebbe scattato il giorno in cui i dati
sono stati generati.
Nel filtraggio dei dati recuperati dal database, ho provato un approccio meno
invasivo. Ho pensato di lasciare l'operazione di filtraggio a carico dell'applicazione
JAVA per la creazione dei grafici. L'applicazione per la creazione dei grafici resta
Tommaso Foglia 961/147 Pagina 79 di 150

immutata nelle sue query, ma presenta un filtro sul numero degli inserimenti, in modo
da risalire ai reali valori inseriti in quel periodo temporale.
Se questo permette di non sconvolgere il codice dell'applicazione, utilizzandone solo
le sue funzionalità, tuttavia rendeva estremamente farraginoso il lavoro della
creazione dei grafici, producendo ritardi eccessivi nella visualizzazione, soprattutto
nel caso di grafici su richiesta.
Ho pensato ad un'ottimizzazione del Database. Le tabelle del database, utilizzando un
termine geometrico, sono ad intersezione non vuota.
Quando il Parser effettua un inserimento settimanale ogni 3 ore, non fa altro che
inserire nella tabella settimanale un'informazione che è stata comunque inserita nella
tabella settimanale. Se l'ottimizzazione sembra vantaggiosa, i vantaggi derivanti da
quest'ultima non sono elevati.
Il Database ospita all'interno delle tabelle, salvo che per quelle giornaliere, dati
statici, come media e varianza, che, con un taglio delle tabelle, in modo da lasciare
solo quelle giornaliere, andrebbero persi. Inoltre la tabella giornaliera è quella, che
con l'ampliamento della finestra di Round Robin, ha subito l'incremento maggiore , in
termini di spazio occupato sul disco fisso, è l'unica che non può essere eliminata. In
definitiva ho ritenuto inopportuno seguire questa strategia .
Si è palesata la necessità di una ristrutturazione delle query, dove l'inserimento nella
clausola WHERE di un criterio temporale, è stato opportuno al fine di ottenere
esclusivamente i valori necessari a creare i grafici.
Le clausole WHERE sono state introdotte in tutte le query, in ogni tipo di grafico, la
clausola è stata adattata al tipo di grafico che si sta creando: le query per i grafici
giornalieri, raccoglieranno solo i dati della data richiesta, quelli settimanali,
partiranno dalla data richiesta per giungere fino ai 7 giorni precedenti e così via.
Il codice riportato di seguito evidenzia la presenza della clausola temporale nel
campo WHERE, inoltre viene riportata anche la query originale.
Tommaso Foglia 961/147 Pagina 80 di 150

E' riportata una sola query come esempio, in appendice verranno poi evidenziate le
differenze in tutte le query restanti.
Figura 32: Dettaglio del codice di una query presa ad esempio. Notare come la
clausola WHERE viene modificata di volta in volta per adattarsi al tipo di grafico da
realizzare.
Figura 33: Dettaglio query originale. Assente la clausola WHERE.
Nell'applicazione web è stato necessario introdurre un metodo per permettere
all'utente di selezionare una data per la quale si vogliono visualizzare i grafici.Per il
riempimenti di un form con un campo Date, ho introdotto un calendario in Javascript
che ha il compito di permettere all'utente di selezionare la data. Anche per la data ho
provveduto a creare una variabile di sessione, con il compito di informare l'utente
Tommaso Foglia 961/147 Pagina 81 di 150

sulla data relativa ai grafici che sta visualizzando.
Figura 34: Calendario Javascript utilizzato per la scelta della data.
Anche la chiamata all'applicazione StackedArea, che ha il compito di creare i grafici,
dovrà subire una modifica. E' necessario che l'utente, e quindi la pagina JSP,
comunichi all'applicazione la data desiderata. E' stato necessario utilizzare una nuova
signature, in modo che ci sia posto anche per la data. Il parametro così scelto
dall'utente sarà salvato per la visualizzazione ed inviato all'applicazione per essere
cosi' utilizzato da filtro nel campo WHERE.
Figura 35: Dettaglio del codice raffigurante la chiamata all'applicazione per la
generazione di grafici dove viene aggiungo il parametro data.
Tommaso Foglia 961/147 Pagina 82 di 150

Per quanto riguarda il terzo requisito, ho dovuto costruire una nuova funzionalità.
L'applicazione per la creazione dei grafici, non contempla la creazione di grafici con
un periodo a scelta dell'utente. Produce i grafici relativi ai criteri temporali che già
sono stati illustrati. Per inserire questa funzionalità è stato necessario aggiungere
anche qui alcuni metodi, come verrà evidenziato esaustivamente in appendice.
L'applicazione che produceva la stessa serie di grafici, per ogni criterio temporale,
dovrà lavorare su un nuovo criterio che prevede la scelta da parte dell'utente. Nel
momento in cui si sceglie il periodo custom, l'applicazione web ci permette di
selezionare due date: una di inizio periodo e l'altra di fine periodo. Per l'acquisizione
di queste date è stato utilizzato un form con due campi di tipo Date. In tutti e due i
campi è stato utilizzato un calendario Javascript per l'acquisizione.
Figura 36: Selezionato il criterio temporale "custom", l'applicazione visualizza un
form con due calendari per la scelta del periodo.
Nel momento in cui vengono indicate 2 date, il sistema controlla che il periodo di
riferimento corrisponda ad un periodo sul quale sia possibile costruire dei grafici.
Non saranno accettati periodi precedenti alla data della creazione del database,
periodi sconfinanti in date future, periodi dove la data di partenza risulta posteriore
alla data di fine periodo o viceversa.
Create altre due variabili di sessione, si presenta la necessità di comunicare
all'applicazione StackedArea, i valori acquisiti, in modo da poter effettuare un
filtraggio sull'intervallo temporale.
Tommaso Foglia 961/147 Pagina 83 di 150

All'interno dell'applicazione ho inserito un controllo per riconoscere il tipo di grafici
che viene chiesto di essere creato. Ho ideato una nuova signature, contenente
entrambe le date, di inizio e fine periodo. L'applicazione dovrà creare esclusivamente
i grafici relativi al periodo selezionato, quindi non dovrà produrre i grafici relativi
agli altri criteri temporali. Di seguito sono riportate le modifiche alla chiamata per la
generazioni di grafici di tipo Custom. Saranno passati come parametri le due date
scelte dall'utente.
Figura 37: Dettaglio del codice raffigurante la chiamata all'applicazione per generari
i grafici dove vengono aggiunti i parametri relativi alle due date.
Inoltre è presente un esempio di query con filtro temporale con due date.
La clausola WHERE sarà utilizzata per filtrare tutti i dati appartenenti al periodo
scelto dall'utente.
Figura 38: Dettaglio del codice di una query. Notare nel campo WHERE la presenza
di un filtro utilizzando le due date scelte dall'utente.
Tommaso Foglia 961/147 Pagina 84 di 150

Le date scelte per il periodo saranno passate all'applicazione JAVA e saranno
utilizzate per filtrare i dati recuperati dal database. I grafici creati saranno collocati
nella cartella della data di inizio periodo, nella sua sottocartella della data di fine
periodo, sottocartella che sarà allo stesso livello delle cartelle che contengono i
grafici giornalieri,settimanali,mensili ed annui.
Tommaso Foglia 961/147 Pagina 85 di 150

5.4 Requisiti non funzionali
Nell'implementazione dei requisiti funzionali si è tenuto conto di alcuni requisiti non
funzionali che hanno posto determinati problemi e per i quali è stata pensata una
soluzione.
E' stato modificato il file di avvio del sistema ospitante l'applicazione, in modo che
all'avvio del sistema, ed in seguito a qualsiasi crash o riavvio, il server Tomcat sia
avviato in automatico. In questo modo il sistema non avrà problemi ad interagire con
la pagina jsp, che potrà quindi, permettere all'utente di visualizzare in modo
dinamico, i grafici relativi ad un periodo predefinito o quelli relativi ad un periodo a
scelta dell'utente.
Figura 39: Servizio Tomcat attivo all'avvio della macchina.
Il prototipo del sistema era formato in diversi sue parti, da un processo che si attivava
ad intervalli di tempo. Liberarsi da questo modo di lavorare, e l'aver aggiunto delle
chiamate all'orologio di sistema(crontab) ha fatto in modo che il sistema sia attivo ad
ogni crash o riavvio non essendo più necessaria una chiamata manuale. Una
soluzione pensata inserendo solo una chiamata con l'orologio di sistema in
associazione al processo in continua esecuzione avrebbe attivato più istanze
dell'applicazione che effettuavano le stesse operazioni.
Per quanto riguarda la memorizzazione dei grafici, creati in formato jpg, ho scelto di
mantenere la struttura a cartelle con la suddivisione in giornalieri, settimanali, mensili
Tommaso Foglia 961/147 Pagina 86 di 150

e annui. I grafici che venivano creati dal prototipo andavano a sovrascrivere i grafici
creati precedentemente, senza avere la possibilità di conservarli.
La tecnica messa a punto, mira a diminuire le richieste di creazione di grafici. Le
cartelle della divisione temporale sono create all'interno di una cartella il cui nome
rappresenta la data di riferimento per quei grafici.
Un primo approccio prevedeva la creazione dei grafici solo quando ce ne fosse stato
realmente bisogno. Ogni qualvolta si sottometteva alla pagina JSP la data
corrispondente alla data odierna, i dati venivano ricreati, in modo da far visualizzare
tutti gli ultimi aggiornamenti.
Questa tipologia di utilizzo non favoriva una visualizzazione multiutente, infatti c'e' il
rischio che i grafici siano ricreati innumerevoli volte, durante l'intero arco della
giornata.
Inoltre i grafici di riferimento ad una data passata, venivano conservati nel sistema,
ma rappresentavano la situazione aggiornata all'orario dell'ultimo accesso di un
utente. Questo faceva si che si trovassero grafici che, non appartenendo alla giornata
corrente, non venivano rigenerati, ma che riproducevano informazioni non complete.
Un checkbox “replot” permetteva di ricreare i grafici per quella data, in modo che
mostrassero esaurientemente i dati di quella giornata.
Se da una parte può tornare utile fornire all'utente strumenti che gli consentano una
corretta visualizzazione di tutte le informazioni di cui ha bisogno, dall'altra lasciare la
creazione di grafici in questo modo, permetteva una distribuzione del lavoro non
uniforme, con lunghi periodi di inattività e con periodi invece di intenso lavoro, senza
poter porre un limite superiore alla quantità di chiamate all'applicazione per generare
i grafici.
Un'ottimizzazione nella creazione dei grafici è stata sviluppata tenendo conto di
queste problematiche. Tramite l'orologio di sistema, partendo dalle 00:20, ogni 30
minuti vengono creati dei grafici aggiornati per la data corrente. L'ultima chiamata
avviene alle 23:50, in modo che i grafici riportati nella cartella di una giornata,
Tommaso Foglia 961/147 Pagina 87 di 150

ispecchino fino all'ultimo il reale stato di occupazione della coda.
Di seguito sono mostrate le chiamate che l'orologio di sistema effettua
automaticamente per la creazione dei grafici.
Figura 40: Chiamate all'applicazione per la generazione dei grafici che sono inserite
nel crontab dell'utente root.
Questa tecnica, permette di limitare superiormente il numero massimo di grafici che
vengono creati per ogni data. Il sistema produrrà per ogni data 48 volte la stessa
tipologia di grafici e di volta in volta i grafici copriranno l'intero arco temporale della
giornata.
Inoltre per evitare la creazione continua di grafici recenti, è stata creata una
subroutine JAVA ,eliminagrafici, che ogni notte viene lanciata tramite crontab
dall'utente root.
L'applicazione controlla i nomi delle cartelle(sono date), fa un cast del tipo, per farlo
diventare di tipo DATE e tramite le funzioni messe a disposizione da questa classe
confronta la data memorizzata con la data corrente, cancellando tutta la produzione di
grafici più vecchia di 150 giorni.
Proprio per questo motivo, nella creazione dei grafici “custom” ho scelto di
memorizzare i grafici nella cartella “data inizio periodo” creando una sottocartella
“data fine periodo”. Anche questi grafici creati su richiesta saranno cancellati se la
data di inizio periodo sarà antecedente i 150 giorni.
Di seguito è mostrata la chiamata all'orologio di sistema che ogni notte effettua la
pulizia dei grafici creati dall'applicazione.
Tommaso Foglia 961/147 Pagina 88 di 150

Figura 41: Chiamata inserita nel crontab dell'utente root per la cancellazione
automatica della produzione di grafici obsoleta.
Di seguito è riproposto un esempio di esecuzione dell'applicazione eliminagrafici.
Figura 42: Output dell'applicazione eliminagrafici.
Questo tipo di memorizzazione permette un'immediata visualizzazione, tramite
l'applicazione web, dei grafici creati negli ultimi 150 giorni, mantenendo quasi del
tutto costante lo spazio occupato dai grafici sul disco, lasciando alla sola creazione
dei grafici su richiesta la libertà di far accrescere lo spazio occupato.
Si è ridotto drasticamente il numero di chiamate alla funzione per creare grafici,
offrendo un notevole guadagno in termini di performance per l'applicazione web.
Non solo gli utenti troveranno già pronti i grafici relativi agli ultimi 150 giorni ma,
due utenti, interessati ad esaminare lo stesso periodo custom, potranno
tranquillamente visualizzare gli stessi grafici, senza ricorrere ad una nuova
generazione e quindi ad un appesantimento del sistema.
Nel casono si voglia visualizzare di una data antecedente i 150 giorni, il sistema
provvederà alla creazione dei grafici, li renderà disponibili all'utente fino alle ore 4:10
Tommaso Foglia 961/147 Pagina 89 di 150

del giorno successivo. Orario in cui l'applicazione eliminagrafici viene mandata in
esecuzione e i grafici saranno così cancellati.
Nel caso di un accesso al sistema tra la mezzanotte e la prima creazione dei grafici,
l'applicazione considera il giorno corrente non ancora creato, alla stregua di una
giornata antecedente i 150 giorni, provvedendo alla creazione su disco della cartella
con la data e delle cartelle con i grafici.
Nel creare grafici di tipo custom è stata inserita oltre ad una pausa di circa 8 secondi,
all'interno della pagina JSP, un'pplicazione Javascript che informi l'utente del
procedimento di creazione dei grafici, in modo che la pagina nel crearsi non incorra
in problemi di visualizzazione, dovuti all'eventuale lentezza dell'applicazione
StackedArea nel rilasciare i primi grafici creati.
Figura 43: Immagine dell'applicazione Javascript che informa l'utente riguardo
all'elaborazione dei grafici per il periodo richiesto.
Tommaso Foglia 961/147 Pagina 90 di 150

Per ovviare ai tempi di attesa nel caso in cui ci sia un appesantimento del sistema ho
inserito un refresh automatico della pagina. Ho utilizzato un'applicazione Javascript
per ricordare la posizione della scroll bar verticale, in modo che l'utente possa
continuare a visualizzare i grafici che stava già visualizzando precedentemente, senza
essere annoiato dal refresh di pagina.
Tommaso Foglia 961/147 Pagina 91 di 150

5.5 Class diagram
Per quanto riguarda il Class diagram delle applicazioni utilizzate nel complesso del
sistema, Parser e StackedArea, vi è l'aggiunta di una nuova classe nel package Parser
dell'applicazione Parser.jar e di una classe nel package StackedArea.
Per quanto riguarda il Parser, come ho già spiegato, la necessità della creazione di
una nuova classe è scaturita dall'operazione di smembramento. Non lavorando più
come processo che si riattiva tramite Timer, l'applicazione ha bisogno di comprendere
le varie chiamate che riceve, di interpretare i nuovi argomenti che gli vengono passati
e di produrre poi i giusti inserimenti. La creazione di una nuova classe
AggiornaBatch.java ci assicura che il file XML aggiornato, contenente le nuove
informazioni sullo stato effettivo di occupazione delle code, venga nuovamente
processato. In questo modo l'applicazione effettua una nuova creazione dell'albero
DOM del documento XML. Questo ha reso possibile che il popolamento del
Database avvenga in maniera corretta.
Per il modulo Parser, le classi sono:
• AggiornaBatch: questa classe ha il compito di risolvere il problema della
creazione dell'albero DOM del documento XML.
• Configuratore: classe che controlla l'esistenza dei in input provenienti da
interrogazioni del batch system, e crea un oggetto di tipo ManagerParser.
• ManagerParser: classe che gestisce il sistema, interfacciandosi con il
database, o con i file XML, effettuando operazioni come creazione e lettura
del file di configurazione del sito, e creando l'oggetto di tipo ParserScheduler.
• ParserScheduler: classe che si occupa dell'effettiva lettura dello stato delle
code, effettuando il parser dei file xml provenienti dall'output dei comandi che
interrogano lo stato dei batch system.
• XMLValidator: classe che si occupa della gestione dei documenti xml.
Tommaso Foglia 961/147 Pagina 92 di 150

• GridComponent: classe che contiene le informazioni generali sulle
componenti della grid, reca, infatti, i metodi ed attributi comuni a
VirtualOrganization, Coda, Gruppo.
• VirtualOrganization: sottoclasse di GridComponent, mantiene informazioni
sulla Vo, come il numero totali di job provenienti dai membri della vo, nei
diversi stati.
• Gruppo: sottoclasse di GridComponent, mantiene le informazioni relative ai
gruppi facenti parte delle vo.
• Coda: sottoclasse di GridComponent, mantiene informazioni sulle code
associate alle Vo.
Tommaso Foglia 961/147 Pagina 93 di 150

Possiamo dividere il modulo StackedArea in due parti, per la parte relativa alla
produzione di grafici ci sono le seguenti classi:
• Configuratore: classe che controlla l'esistenza dei file XML prodotti dal
parser o la presenza dei dati nel database e permette l'avvio del generatore di
grafici.
• GeneratoreGrafici: classe che si occupa della creazione periodica dei grafici
• Grafico: classe, legge le informazioni recuperate dal parser, estraendole dai
file xml o dal database, e produce i grafici in diversi formati.
Le classi per la generazione dei grafici, interagiscono con le restanti classi che
recuperano i dati dal Database.
Tommaso Foglia 961/147 Pagina 94 di 150

Per la parte relativa alla GestioneDatabase, che nel suo class diagram non ha subito
cambiamenti rilevanti, riportiamo le seguenti classi:
• MyConnection: classe che effettua e gestisce la connessione al database.
• DBCoda: classe che si occupa di gestire le informazioni relative alle code,
all'interno del database.
• DBGruppo: classe che si occupa di gestire le informazioni relative ai gruppi,
all'interno del database.
• DBVo: classe che si occupa di gestire le informazioni relative alle Virtual
Organization, all'interno del database.
• DBJob: classe che gestisce le informazioni relative ai job.
• DBOsservazioni: classe che inserisce le misurazioni sullo stato delle code, vo e
gruppi nel database
• DBScheduler: classe che gestisce le informazioni sui batch system e sui siti che si
stanno monitorando, gestisce anche i dati relativi agli intervalli temporali tra una
misurazione e la successiva, per osservazioni giornaliere, settimanali, mensili ed
annuali.
• ControllerTimerTaskGiorno: classe che permette di gestire il timer per effettuare
le misurazioni giornaliere, effettuando statistiche.
• ControllerTimerTaskSettimana: classe che permette di gestire il timer per
effettuare le misurazioni settimanali, effettuando statistiche.
• ControllerTimerTaskMese: classe che permette di gestire il timer per effettuare le
misurazioni mensili, effettuando statistiche.
• ControllerTimerTaskAnno: classe che permette di gestire il timer per effettuare le
misurazioni annuali, effettuando statistiche.
• ControllerTimerTaskJob: classe che permette di gestire il timer per effettuare le
misurazioni relative ai job presenti sulle code.
Tommaso Foglia 961/147 Pagina 95 di 150

6 Conclusioni e sviluppi futuri
Il sistema, come richiesto, permette la visualizzazioni di un'insieme di informazioni
provenienti dal batch system. Tutti i requisiti sono stati implementati, cercando di
offrire all'utente, un sistema che sia facile da utilizzare ma che allo stesso tempo
permetta di recuperare in maniera celere tutte le informazioni di cui ha bisogno.
L'applicazione è già predisposta ad accogliere le informazioni provenienti da altri siti
di monitoraggio, in modo da ottimizzare la natura distribuita delle risorse che
vengono monitorate.
E' possibile lavorare con i due batch system presi in esame, ed uno sviluppo futuro
potrà prevedere la possibilità di lavorare anche con altri batch system. Qualora gli
utilizzatori lo ritengano necessario è anche possibile un ampliamento delle
funzionalità, con l'introduzione di grafici o altri strumenti, allo scopo di poter
visualizzare informazioni statistiche sull'attività di monitoraggio.
Tommaso Foglia 961/147 Pagina 96 di 150

7 Bibliografia e Sitografia
1. Introduction to grid computing, Frédéric Magoulès, Jie Pan, Kiat An Tan,
Abhinit Kurnar. - Boca Raton : CRC press.
2. Grid computing : making the global infrastructure a reality, Edited by Fran
Berman, Geoffrey Fox, Tony Hey. - Chichester [UK] : Wiley.
3. WNoDeS: un servizio per la gestione di infrastrutture condivise Cloud e Grid
di D. Salomoni, A. Chierici, A. Italiano, E. Ronchieri, P. Solagna
4. Reti di Calcolatori, A. S. Tanenbaum , Apogeo
5. Sito PBS: http://hpc.sissa.it/pbs/pbs.html
6. Sito Maui:
http://www.adaptivecomputing.com/resources/docs/maui/mauiadmin.php
7. Scalability Analysis of Job Scheduling using Virtual Nodes di Norman Bobro,
Richard Coppinger, Liana Fong, Seetharami Seelam, Jing Xu
8. Sito manuale LSF:
http://users.cis.fiu.edu/~tho01/psg/3rdParty/lsf4_userGuide/admincontents.html
Tommaso Foglia 961/147 Pagina 97 di 150

9. Sito Liferay :
http://www.liferay.com/
10. Sito Java:
http://www.java.sun.com/
11. Sito MySql
http://mysql.it/
12. Fondamenti di UML, J. T. Roff, McGraw-Hill, 2003
13. Fabric Monitoring at the INFN Tier1 ,Joint OSG & EGEE Operations WS,
Culham (UK) , Felice Rosso , 2005
14. Sito centro testi Scope, dott. Fabrizio Marazita:
http://www.scope.unina.it/tesidilaurea/Lists/Archivio%20Tesi%20di
%20Laurea/DispForm.aspxID=21
15. Sito centro testi Scope, dott. Luisa Cesarano:
http://www.scope.unina.it/tesidilaurea/Lists/Archivio%20Tesi%20di
%20Laurea/DispForm.aspxID=45
Tommaso Foglia 961/147 Pagina 98 di 150

Appendice A
Di seguito andiamo a mostrare il codice prodotto ex novo, relativo allo sviluppo del
progetto WebApplication1.war, nello specifico verrà esaminata la pagina JSP. A
seguire il codice relativo all'applicazione eliminagrafici.jar.
Index.jsp :
html,body{margin:0;padding:0}
p{margin:0 10px 10px}
a{display:block;color: #981793;padding:10px}
Tommaso Foglia 961/147 Pagina 99 di 150

div#header h1{height:40px;line-height:40px;margin:0;
padding-left:10px;background: #EEE;color: #79B30B}
div#content1 {}
div#content2 {}
div#footer{background: #333;color: #FFF}
div#footer p{margin:0;padding:5px 10px}
div#wrapper1{float:left;width:100%;margin-left:-50%}
div#wrapper2{float:right;width:50%;margin-left:-50%}
div#content1{margin-left:50%}
div#content2{margin-right:50%}
div#footer{clear:both;width:100%}
#overlayfrm {background-color:#333; -moz-opacity:0.8; opacity:.80;
filter:alpha(opacity=80);}
RecoverScroll.start();
Atlas Job monitoring
Tommaso Foglia 961/147 Pagina 100 di 150

Tommaso Foglia 961/147 Pagina 101 di 150

height="25" />

data = oggi;
}
if (data5.after(unDate))
{out.println("The required date is later than now");
data = oggi;
}
}
else {
if(session.getAttribute("ladata")==null)
data = oggi;
else
data = session.getAttribute("ladata").toString();
}
session.setAttribute("ladata",data);
if (!tempo.startsWith("Cust"))
{
%>

}
//DATE PER I GRAFICI AD INTERVALLO
String data1 = new String ();
String data2 = new String ();
Date data6,data7 = null;
int d=1;
if (request.getParameter("data1")!=null && request.getParameter("data2")!=null)
{ data1 = request.getParameter("data1");
data2 = request.getParameter("data2");
if (!data1.isEmpty() && !data2.isEmpty())
{ d=0; //porre d=0 per stampare i custom
data6 = (Date)formato.parse(data1);
data7 = (Date)formato.parse(data2);
if (data7.before(data6))
{
out.println("Not a valid period: "+ data2 + " < " + data1);
%>

if (data7.before(creazionedatabase) || data7.after(unDate))
{ %>
Start date
Tommaso Foglia 961/147 Pagina 106 di 150

End date

coda = session.getAttribute("lacoda").toString();
}
session.setAttribute("lacoda",coda);
try{
ResultSet rs = null;
String query = null;
if(criterio.startsWith("coda"))
{query = "select Queue_name from coda order by Queue_name;";
rs = stackedarea.ConnectionPool.inviaQuery(query);
rs.beforeFirst();
%>
Queue selection
all
Tommaso Foglia 961/147 Pagina 108 di 150

Vo selection
all

out.print(Vo);%>

}
//SE I GRAFICI PER IL PERIDO CUSTOM SONO GIA' STATI CREATI PONGO D=1 per non
farli ricalcolare
if (fileObjects2[i].isDirectory() && fileNames2[i].matches(data1))
{ String file3 =file2 + fileNames2[i] + "/";
//out.println(file3);
File f3 = new File(file3);
String [] fileNames3 = f3.list();
File [] fileObjects3= f3.listFiles();
for (int z = 0; z < fileObjects3.length; z++)
{if (fileObjects3[z].isDirectory() && fileNames3[z].matches(data2))
{d=1;//out.println("Grafici gia' creati");
}
}
}
}
VOLTA
//PER IL GIORNO CORRENTE E' NECESSARIO GENERARE I GRAFICI OGNI
(APPROCCI ABBANDONATI)
// if(data.matches(oggi) && request.getParameter("data")!=null)
// t=0;
// CHECKBOX REPLOT ATTIVATO
//if (request.getParameter("rielabora")!=null)
// t=0;
//CHIAMATA PER I GRAFICI A PERIODO PRESTABILITO
String[] arg = new String[9];
if (t==0)
Tommaso Foglia 961/147 Pagina 111 di 150

System.out.println(" PLEASE WAIT - GENERATION IN
PROGRESS");
if (t==0)
{
arg[0] =("PBS");
arg[1] =("-D") ;
arg[2] = ("/home/qjmon/sito1/");
arg[3] =("sito1");
arg[4] = (data);
arg[5] = ("Monitor");
arg[6] = ("qjmon");
arg[7] = ("admin");
arg[8] = ("qjmon.scope.unina.it:3306");
t=0");
stackedarea.Configuratore.main(arg); //out.println("ho chimato con arg perchè
//PAUSA PER FAR INIZIARE A PRODURRE QUALCHE GRAFICO ALTRIMENTI
NULLPOINTER EXCEPTION
Thread.sleep(8000);
}
//CHIAMATA PER GRAFICI CON PERIODO CUSTOM
if (d==0)
String[] arg1 = new String[11];
System.out.println("
PROGRESS");
PLEASE WAIT - GENERATION IN
if (d==0)
{
arg1[0] =("PBS");
Tommaso Foglia 961/147 Pagina 112 di 150

arg1[1] =("-D") ;
arg1[2] = ("/home/qjmon/sito1/");
arg1[3] =("sito1");
arg1[4] = (data);
arg1[5] = ("Monitor");
arg1[6] = ("qjmon");
arg1[7] = ("admin");
arg1[8] = ("qjmon.scope.unina.it:3306");
arg1[9] = (data1);
arg1[10] = (data2);
stackedarea.Configuratore.main(arg1);//out.println("ho chimato con arg1
perchè d=0");
//PAUSA PER FAR INIZIARE A PRODURRE QUALCHE GRAFICO ALTRIMENTI
NULLPOINTER EXCEPTION
Thread.sleep(8000);
}
//CAMBIO VALORI PER POTER VISUALIZZARE I GRAFICI DEL PERIODO CUSTOM
if (tempo.startsWith("Cust") )
{if (!data1.isEmpty() && !data2.isEmpty())
{data = data1;
tempo = data2;
//out.println("Now Plotting the custom period from " + data1 + " to " + data2);
}
else
{tempo="test";
//out.println("Please select a custom period");
}
} %>
Tommaso Foglia 961/147 Pagina 113 di 150

Tommaso Foglia 961/147 Pagina 114 di 150

Tommaso Foglia 961/147 Pagina 115 di 150

fileNames[i].contains(vo))
{// out.print("codaD codaD Vo");
k=1;
%>
Tommaso Foglia 961/147 Pagina 117 di 150

Tommaso Foglia 961/147 Pagina 118 di 150

k=1;
%>

k=1;
%>

tempo + "/" + fileNames[i] %>" id="img-background" width="600" height="500" />
Tommaso Foglia 961/147 Pagina 122 di 150

}
Tommaso Foglia 961/147 Pagina 123 di 150

Eliminagrafici.java:
package eliminagrafici;
import java.text.*;
import java.util.Date;
import java.io.File;
import java.util.Calendar;
/**
* @author DopatO
* L'applicazione cancella ricorsivamente tutte le cartelle, relative ai grafici, più vecchie
di 5 mesi.
*/
public class Eliminagrafici
{ public static void main(String[] args)
{ Calendar cal = Calendar.getInstance();
System.out.println("Oggi : " + cal.getTime());
cal.add(Calendar.DATE, -150);
System.out.println("150 giori fa: " + cal.getTime());
SimpleDateFormat formato = new SimpleDateFormat("yyyy-MM-dd");
//PATH DELLA CARTELLA GRAFICIDB
String file2 = "/home/qjmon/sito1/" + "MONITOR/" + "GraficiDB/";
File f2 = new File(file2);
String [] fileNames2 = f2.list();
File [] fileObjects2= f2.listFiles();
Date date = null;
int t=0;
vengono cancellate
//conta quante directory conteneti grafici di una deteminata data
for (int i = 0; i < fileObjects2.length; i++)
{ //out.println(fileObjects2[i]);
Tommaso Foglia 961/147 Pagina 124 di 150

if (fileObjects2[i].isDirectory())
{
try{
date = (Date)formato.parse(fileNames2[i]);
if (date.before(cal.getTime()))
{ String file3= (file2 + fileNames2[i] + "/");
System.out.println(file3);
File f3 = new File(file3);
File [] fileObjects3= f3.listFiles();
String [] fileNames3 = f3.list();
for (int z = 0; z < fileObjects3.length; z++)
{if (fileObjects3[z].isDirectory())
{
File f4 = new File(file3 + fileNames3[z]);
File [] fileObjects4= f4.listFiles();
String [] fileNames4 = f4.list();
for (int q = 0; q < fileObjects4.length; q++)
{fileObjects4[q].delete();
}
}
fileObjects3[z].delete();
}
fileObjects2[i].delete();t++;
System.out.println("directory cancellate:" + t);
}
}
catch (ParseException e)
{System.out.println("Exception :"+e);
Tommaso Foglia 961/147 Pagina 125 di 150

}
}
}
}
}
Tommaso Foglia 961/147 Pagina 126 di 150

Appendice B
Di seguito verranno esaminati gli elementi costituenti l'applicazione Parser.jar.
L'applicazione si suddivide in due pacchetti Parser e GestioneDatabase. Il package
Parser è composto dalle seguenti classi: AggiornaBatch.java, Configuratore.java,
ControllerTimerFileG.java, ControllerTimerTaskGiorno.java, GridComponent.java,
ManagerParser.java, ParserScheduler.java, TaskGiorno.java, XmlValidator.java.
Il package GestioneDatabase è composto dalle seguenti classi: ConnectionPool.java,
ConnectionPoolException.java, DBCoda.java, DBGruppo.java, DBJob.java,
DBOsservazioni.java, DBScheduler.java, DBVo.java.
Tuttavia l'ampliamento ha prodotto modifiche solo in alcuni di queste classi. Di
seguito mostreremo solo le classe che hanno subito cambiamenti, evidenziando in
modo particolare le nuove classi e le aggiunte di codice.
AggiornaBatch.java:
package Parser;
import GestioneDatabase.*;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.Set;
import java.util.TimerTask;
import java.sql.Timestamp;
import java.util.logging.Level;
import java.util.logging.Logger;
public class AggiornaBatch extends TimerTask {
ManagerParser bacth;
Tommaso Foglia 961/147 Pagina 127 di 150

String Sito;
String Batch;
public AggiornaBatch(String nomeSito,String nomeBatch){
Sito=nomeSito;
Batch=nomeBatch;
}
@Override
public void run(){
ManagerParser batch;
batch = new ManagerParser("Job.xml",Sito, Batch, "Coda.xml");
}
}
Configuratore.java:
package Parser;
import GestioneDatabase.*;
import GestioneDatabase.ConnectionPool;
import java.io.File;
import java.util.Timer;
import java.util.Set;
public class Configuratore {
static long secondi;
public static String inputDatiScheduler,
pathParserMONITOR, pathFileLog,
pathOutputParserXML, pathOutputParserASCII,
database, user, password, indirizzo;
Tommaso Foglia 961/147 Pagina 128 di 150

public static void main(String[] args) {
ManagerParser batch;
String Xsi = args[0]; // -X -NX
String nomeBatch = args[1]; // LSF PBS
String ModalitaDatabase = args[2]; // -D -ND
String MappaSi = args[3]; // -M -N
String PathMonitor = args[4]; // path della cartella monitor
/* Inizializza il path della cartella MONITOR, che conterra tutti i file e cartelle
* per un corretto funzionamento */
pathParserMONITOR = PathMonitor + "/MONITOR/";
inputDatiScheduler = pathParserMONITOR + "/mon/";
pathFileLog = pathParserMONITOR + "file.log.txt";
if (new File(pathParserMONITOR).isDirectory() == false) {
new File(pathParserMONITOR).mkdirs();
}
if (ModalitaDatabase.compareToIgnoreCase("-ND") == 0) {
String tempoMisurazione = args[5];
/** Creazione dell'oggetto ManagerParser che prenderà i dati di intput dai file
XML generati tramite i comandi per PBS : "PBS.txt" generato dal comando "qstat -x"
per LSF : "LSF.txt" generato tramite il metodo statico "creaFileXML_LSF" dal file bj.txt */
if (tempoMisurazione.compareToIgnoreCase("-g") == 0) {
pathOutputParserXML = pathParserMONITOR + "XML/Giornalieri";
pathOutputParserASCII = pathParserMONITOR + "ASCII/Giornalieri/";
secondi = 86400;
} else if (tempoMisurazione.compareToIgnoreCase("-s") == 0) {
pathOutputParserXML = pathParserMONITOR + "XML/Settimanali";
pathOutputParserASCII = pathParserMONITOR + "ASCII/Settimanali/";
Tommaso Foglia 961/147 Pagina 129 di 150

secondi = 604800;
} else if (tempoMisurazione.compareToIgnoreCase("-m") == 0) {
pathOutputParserXML = pathParserMONITOR + "XML/Mensili";
pathOutputParserASCII = pathParserMONITOR + "ASCII/Mensili/";
secondi = 2592000;
} else if (tempoMisurazione.compareToIgnoreCase("-a") == 0) {
pathOutputParserXML = pathParserMONITOR + "XML/Annuali";
pathOutputParserASCII = pathParserMONITOR + "ASCII/Annuali/";
secondi = 31556926;
}
if (new File(pathOutputParserXML).isDirectory() == false) {
new File(pathOutputParserXML).mkdirs();
new File(pathOutputParserASCII).mkdirs();
}
if (Xsi.compareToIgnoreCase("-JX") == 0) {
ManagerParser.creaFileJobXML_LSF("Job.xml", "bj.txt");
}
batch = new ManagerParser("Job.xml", null, nomeBatch, null);//
inputDatiScheduler, pathOutputParserXML, pathOutputParserASCII);
if (MappaSi.compareToIgnoreCase("-M") == 0) {
/* Creazione del file XML che conterrà la mappatura tra Code - Vo - Gruppi
* tramite i file "origineMappa.txt",generati tramite script shell basati su
comandi PBS e LSF */
batch.creaFileXML_Mappatura("origineMappa.txt");
}
/* Lettura della mappa del sito dal file xml */
batch.leggiMappaGrid("mappa.conf.xml");
Tommaso Foglia 961/147 Pagina 130 di 150

* Recupero delle informazioni sullo stato delle code/job */
long epoch = System.currentTimeMillis() / 1000;
System.out.println("info job GRUPPI - VO : da XML giorno");
batch.recuperaInfoJobGruppi(secondi, epoch);
System.out.println("info job CODE : da XML giorno");
batch.recuperaInfoJobCode(secondi, epoch);
System.out.println("Recupera Dettagli Code giorno");
batch.recuperaDettagliUsoCoda(secondi, epoch);
}
if (ModalitaDatabase.compareToIgnoreCase("-D") == 0) {
/* Database */
int TD = Integer.parseInt(args[5]); // 5 min
int TS = Integer.parseInt(args[6]); // 360 min = 6 ore
int TM = Integer.parseInt(args[7]); // 720 min = 12 ore
int TY = Integer.parseInt(args[8]); // 7200 min = 120 ore = 5 giorni
String nomeSito = args[9];
if (args.length > 10) {
database = args[10];
user = args[11];
password = args[12];
indirizzo = args[13];
}
if (Xsi.compareToIgnoreCase("-JX") == 0) {
ManagerParser.creaFileJobXML_LSF("Job.xml", "bj.txt");
}
if (Xsi.compareToIgnoreCase("-CX") == 0) {
if (nomeBatch.compareToIgnoreCase("LSF") == 0) {
ManagerParser.creaFileCodaXML_LSF("Coda.xml", "bq.txt");
Tommaso Foglia 961/147 Pagina 131 di 150

}
if (nomeBatch.compareToIgnoreCase("PBS") == 0) {
ManagerParser.creaFileCodaXML_PBS("Coda.xml", "bq.txt");
}
}
if (Xsi.compareToIgnoreCase("-JCX") == 0) {
if (nomeBatch.compareToIgnoreCase("LSF") == 0) {
ManagerParser.creaFileCodaXML_LSF("Coda.xml", "bq.txt");
ManagerParser.creaFileJobXML_LSF("Job.xml", "bj.txt");
}
if (nomeBatch.compareToIgnoreCase("PBS") == 0) {
ManagerParser.creaFileCodaXML_PBS("Coda.xml", "bq.txt");
}
}
batch = new ManagerParser("Job.xml", nomeSito, nomeBatch, "Coda.xml");//,
inputDatiScheduler, null, null);
if (args.length == 16) {
if (args[15].compareToIgnoreCase("-C") == 0) {
System.out.println("Rinnovo Database");
batch.eliminaDatabase();
}
}
if (MappaSi.compareToIgnoreCase("-M") == 0) {
batch.creaFileXML_Mappatura("origineMappa.txt");
}
batch.leggiMappaGrid("mappa.conf.xml");
if (MappaSi.compareToIgnoreCase("-M") == 0) {
System.out.println("Aggiornamento Database");
Tommaso Foglia 961/147 Pagina 132 di 150

atch.aggiornaDatabase_Scheduler(TD, TS, TM, TY);
System.out.println("Inserisce CODE - GRUPPI - VO ");
batch.aggiornaDatabase_CodeVoGruppi("bq.txt");
}
//Timer timer = new Timer();
DBJob.truncate();
System.out.println("Inserisce JOB ");
batch.aggiornaDatabase_Job();
System.out.println(args[14]);
if (args[14].compareToIgnoreCase("-g") == 0)
{
batch.Giorno(batch);
}
if (args[14].compareToIgnoreCase("-s") == 0)
{
batch.Settimana(batch);
}
if (args[14].compareToIgnoreCase("-m") == 0)
{
batch.Mese(batch);
}
if (args[14].compareToIgnoreCase("-a") == 0)
{
batch.Anno(batch);
}
Tommaso Foglia 961/147 Pagina 133 di 150

VECCHIA GESTIONE CON I TIMER
// timer.schedule(new AggiornaBatch(nomeSito,nomeBatch), 0 , TD*60000);
//timer.schedule(new TimerTaskJob(batch, Xsi), 100, TD * 60000); //1000 = 1
secondo 60000= un minuto
//timer.schedule(new ControllerTimerTaskGiorno(batch), 300, TD *
60000); //1000 = 1 secondo 60000= un minuto
// timer.schedule(new ControllerTimerTaskSettimana(batch), 400, TS * 60000);
// timer.schedule(new ControllerTimerTaskMese(batch), 600, TM * 60000);
// timer.schedule(new ControllerTimerTaskAnno(batch), 1200, TY * 60000);
}
}
ManagerParser.java:
Per la risoluzione della mancata rigenerazione dell'albero Dom del documento XML
aggiornato è stato aggiunta qualche inclusione in testa al file
import GestioneDatabase.*;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.Set;
import java.util.logging.Level;
import java.util.logging.Logger;
e il codice di seguito in coda:
public void Giorno (ManagerParser batch)
{
int minInGio = 1440;
Set fuoriGruppo;
System.out.println("Aggiornamento Misurazioni Giorno");
int timeIntervalGio = DBScheduler.GetDay(batch.nomeScheduler,
Tommaso Foglia 961/147 Pagina 134 di 150

atch.Nome_Sito);
int numRow = minInGio / timeIntervalGio;
int righeHd_vo = DBOsservazioni.CountTotOsservazioni("hd_vo");
int righeHd_gruppo = DBOsservazioni.CountTotOsservazioni("hd_gruppo");
int righeHd_coda = DBOsservazioni.CountTotOsservazioni("hd_coda");
/*if (righeHd_coda > numRow) {
DBOsservazioni.ElminaMin("hd_coda");
}
if (righeHd_gruppo > numRow) {
DBOsservazioni.ElminaMin("hd_gruppo");
}
if (righeHd_vo > numRow) {
DBOsservazioni.ElminaMin("hd_vo");
}*/
inserisciMisurazioniCoda_DB(batch);
inserisciMisurazioniGruppo_DB(batch);
inserisciMisurazioniFuoriGruppo_DB(batch);
}
public void Settimana(ManagerParser batch)
{
System.out.println("Aggiornamento Misurazioni Settimana");
int minInSet = 10080;
int timeIntervalSet = DBScheduler.GetWeek(batch.nomeScheduler,
batch.Nome_Sito);
int numRow = minInSet / timeIntervalSet;
int righeHw_vo = DBOsservazioni.CountTotOsservazioni("hw_vo");
int righeHw_gruppo = DBOsservazioni.CountTotOsservazioni("hw_gruppo");
Tommaso Foglia 961/147 Pagina 135 di 150

int righeHw_coda = DBOsservazioni.CountTotOsservazioni("hw_coda");
/*if (righeHw_coda >= numRow) {
DBOsservazioni.ElminaMin("hw_coda");
}
if (righeHw_gruppo >= numRow) {
DBOsservazioni.ElminaMin("hw_gruppo");
}
if (righeHw_vo >= numRow) {
DBOsservazioni.ElminaMin("hw_vo");
}*/
DBOsservazioni.codaSettimana_inserisciOsservazioni(batch.nomeScheduler,
batch.Nome_Sito);
DBOsservazioni.gruppoSettimana_inserisciOsservazioni();
DBOsservazioni.voSettimana_inserisciOsservazioni(batch.nomeScheduler,
batch.Nome_Sito);
}
public void Mese(ManagerParser batch){
System.out.println("Aggiornamento Misurazioni Mese");
int minInMes = 525600;
int timeIntervalMes = DBScheduler.GetMonth(batch.nomeScheduler,
batch.Nome_Sito);
int numRow = minInMes / timeIntervalMes;
int righeHm_vo = DBOsservazioni.CountTotOsservazioni("hm_vo");
int righeHm_gruppo = DBOsservazioni.CountTotOsservazioni("hm_gruppo");
int righeHm_coda = DBOsservazioni.CountTotOsservazioni("hm_coda");
/*if (righeHm_coda >= numRow) {
DBOsservazioni.ElminaMin("hm_coda");
}
if (righeHm_gruppo >= numRow) {
Tommaso Foglia 961/147 Pagina 136 di 150

DBOsservazioni.ElminaMin("hm_gruppo");
}
if (righeHm_vo >= numRow) {
DBOsservazioni.ElminaMin("hm_vo");
}*/
DBOsservazioni.codaMese_inserisciOsservazioni(batch.nomeScheduler,
batch.Nome_Sito);
DBOsservazioni.gruppoMese_inserisciOsservazioni();
DBOsservazioni.voMese_inserisciOsservazioni(batch.nomeScheduler,
batch.Nome_Sito);
}
public void Anno(ManagerParser batch) {
System.out.println("Aggiornamento Misurazioni Anno");
int minInAnn = 525600;
int timeIntervalAn = DBScheduler.GetYear(batch.nomeScheduler,
batch.Nome_Sito);
int numRow = minInAnn / timeIntervalAn;
int righeHy_vo = DBOsservazioni.CountTotOsservazioni("hy_vo");
int righeHy_gruppo = DBOsservazioni.CountTotOsservazioni("hy_gruppo");
int righeHy_coda = DBOsservazioni.CountTotOsservazioni("hy_coda");
/*if (righeHy_coda >= numRow) {
DBOsservazioni.ElminaMin("hy_coda");
}
if (righeHy_gruppo >= numRow) {
DBOsservazioni.ElminaMin("hy_gruppo");
}
if (righeHy_vo >= numRow) {
DBOsservazioni.ElminaMin("hy_vo");
}*/
Tommaso Foglia 961/147 Pagina 137 di 150

DBOsservazioni.codaAnno_inserisci_Osservazioni(batch.nomeScheduler,
batch.Nome_Sito);
DBOsservazioni.GruppoAnno_inserisci_Osservazioni();
DBOsservazioni.voAnno_inserisciOsservazioni(batch.nomeScheduler,
batch.Nome_Sito);
}
private void inserisciMisurazioniCoda_DB(ManagerParser batch) {
long epoch = System.currentTimeMillis() / 1000;
Timestamp timestamp = new Timestamp(epoch * 1000);
Set insiemeCode = batch.raggruppaCode();
for (Coda c : insiemeCode) {
try {
int[] infoJobCoda = new int[]{0, 0, 0, 0, 0, 0, 0};
infoJobCoda = batch.parser.recuperaInfoCodaDaXml(c.getNome());
int Tot = infoJobCoda[4] + infoJobCoda[2] + infoJobCoda[1];
DBOsservazioni.codaGiorno_inserisciOsservazioni(batch.nomeScheduler,
timestamp, c.getNome(), String.valueOf(Tot), String.valueOf(infoJobCoda[2]),
String.valueOf(infoJobCoda[1]), String.valueOf(infoJobCoda[4]), batch.Nome_Sito);
} catch (Exception ex) {
ManagerParser.printWriterFileLog.println("Eccezione da
inserisciMisurazioniCoda_DB: " + ex.getMessage());
}
}
}
private void inserisciMisurazioniGruppo_DB(ManagerParser batch) {
Set insiemeCode = batch.raggruppaCode();
long epoch = System.currentTimeMillis() / 1000;
Timestamp timestamp = new Timestamp(epoch * 1000);
Tommaso Foglia 961/147 Pagina 138 di 150

for (Coda c : insiemeCode) {
Set insiemeVOC = c.getVo();
for (VirtualOrganization v : insiemeVOC) {
int[] infoJobVO = new int[]{0, 0, 0};
// Recupero per ogni Vo tutti i gruppi appartenenti
Set gruppi = v.getGruppi();
// Per ogni gruppo vengono estratte le informazioni relative ai JOB tramite il
metodo del ParserScheduler
for (Gruppo g : gruppi) {
try {
int[] infoJobGruppo = new int[]{0, 0, 0};
infoJobGruppo = batch.parser.recuperaDettagliDaXml(g.getNome(),
v.getNome(), c.getNome());
int Tot = infoJobGruppo[0] + infoJobGruppo[1] + infoJobGruppo[2];
for (int i = 0; i < 3; i++) {
infoJobVO[i] += infoJobGruppo[i];
}
DBOsservazioni.gruppoGiorno_inserisciOsservazioni(batch.nomeSchedu
ler, timestamp, g.getNome(), v.getNome(), c.getNome(), String.valueOf(Tot),
String.valueOf(infoJobGruppo[0]), String.valueOf(infoJobGruppo[1]),
String.valueOf(infoJobGruppo[2]), batch.Nome_Sito);
} catch (Exception ex) {
ManagerParser.printWriterFileLog.println("Eccezione da
inserisciMisurazioniGruppi_DB: " + ex.getLocalizedMessage());
}
} // fine FOR gruppi
int Tot = infoJobVO[ 0] + infoJobVO[ 1] + infoJobVO[ 2];
DBOsservazioni.voGiorno_inserisciOsservazioni(batch.nomeScheduler,
timestamp, v.getNome(), c.getNome(), String.valueOf(Tot),
String.valueOf(infoJobVO[0]), String.valueOf(infoJobVO[1]),
Tommaso Foglia 961/147 Pagina 139 di 150

String.valueOf(infoJobVO[2]), batch.Nome_Sito);
} // fine FOR VO sulle VO
}
}
private void inserisciMisurazioniFuoriGruppo_DB(ManagerParser batch) {
long epoch = System.currentTimeMillis() / 1000;
Timestamp timestamp = new Timestamp(epoch * 1000);
int idSched = DBScheduler.getAdmin(batch.nomeScheduler, batch.Nome_Sito);
// Recupera le info dalla struttura "fuoriGruppo" costruita dalla classe
ParserScheduler
ResultSet utenti = ConnectionPool.inviaQuery("select IdUtente, nome, IdCoda,
idScheduler " +
" from utente where idscheduler=" + idSched);
try {
if (utenti != null) {
if (batch.nomeScheduler.compareTo("LSF") == 0) {
while (utenti.next()) {
int idUt = utenti.getInt("IdUtente");
int idCod = utenti.getInt("IdCoda");
ResultSet rs = ConnectionPool.inviaQuery("select p.statusPBS,
p.numPBS, p.statusLSF, p.numLSF, " +
" p.idutente, p.idqueue, p.job_name, " +
" p.jobid_scheduler, p.nomeusers, c.queue_name from " +
" (select j.statusPBS, count(j.statusPBS) as numPBS, j.statusLSF,
count(j.statusLSF) as numLSF," +
" j.idutente, j.idqueue, j.job_name, " +
+ idUt + "'" +
" jobid_scheduler, nomeusers FROM job as j where j.idutente='"
Tommaso Foglia 961/147 Pagina 140 di 150

" and j.idqueue='" + idCod + "' group by statusPBS, statusLSF,
j.idutente, j.idqueue) " +
" as p join coda as c on p.idqueue=c.idqueue where
c.idscheduler='" + idSched + "'");
if (rs != null) {
int r = 0;
int w = 0;
int q = 0;
String nomeUt = null, coda = null;
while (rs.next()) {
nomeUt = rs.getString("nomeusers");
coda = rs.getString("queue_name");
String stat = rs.getString("statusLSF");
if (stat.compareToIgnoreCase("R") == 0) {
r = rs.getInt("numLSF");
} else if (stat.compareToIgnoreCase("Q") == 0) {
q = rs.getInt("numLSF");
} else if (stat.compareToIgnoreCase("W") == 0) {
w = rs.getInt("numLSF");
}
}
int sumTot = r + w + q;
DBOsservazioni.gruppoGiorno_inserisciOsservazioni(batch.nomeSche
duler, timestamp, nomeUt, "", coda, String.valueOf(sumTot), String.valueOf(q),
String.valueOf(r), String.valueOf(w), batch.Nome_Sito);
}
}
} // IF batch system
else {
Tommaso Foglia 961/147 Pagina 141 di 150

while (utenti.next()) {
int idUt = utenti.getInt("IdUtente");
int idCod = utenti.getInt("IdCoda");
System.out.println(idUt +"ciao"+ idCod);
ResultSet rs = ConnectionPool.inviaQuery("select p.statusPBS,
p.numPBS, " + " p.idutente, p.idqueue, p.job_name, " +
" p.jobid_scheduler, p.nomeusers, c.queue_name from " +
" (select j.statusPBS, count(j.statusPBS) as numPBS, j.statusLSF,
count(j.statusLSF) as numLSF," + " j.idutente, j.idqueue, j.job_name, " +
+ idUt + "'" +
" jobid_scheduler, nomeusers FROM job as j where j.idutente='"
" and j.idqueue='" + idCod + "' group by statusPBS, statusLSF,
j.idutente, j.idqueue) " +
" as p join coda as c on p.idqueue=c.idqueue where
c.idscheduler='" + idSched + "'");
if (rs != null) {
int r = 0;
int w = 0;
int q = 0;
String nomeUt = null, coda = null;
while (rs.next()) {
nomeUt = rs.getString("nomeusers");
coda = rs.getString("queue_name");
System.out.println(coda + "bprima");
String stat = rs.getString("statusPBS");
if (stat.compareToIgnoreCase("R") == 0) {
r = rs.getInt("numPBS");
} else if (stat.compareToIgnoreCase("Q") == 0) {
q = rs.getInt("numPBS");
Tommaso Foglia 961/147 Pagina 142 di 150

} else if (stat.compareToIgnoreCase("W") == 0) {
}
w = rs.getInt("numPBS");
}
int sumTot = r + w + q;
System.out.println(nomeUt + coda);
if (nomeUt != null || coda != null)
DBOsservazioni.gruppoGiorno_inserisciOsservazioni(batch.nomeSche
duler, timestamp, nomeUt, "", coda, String.valueOf(sumTot), String.valueOf(q),
String.valueOf(r), String.valueOf(w), batch.Nome_Sito);
}
} // WHILE NEXT
} // ELSE su batch system
}// IF UTENTI == NULL
} catch (SQLException ex) {
Logger.getLogger(ControllerTimerTaskGiorno.class.getName()).log(Level.SEVER
E, null, ex);
}
}
}
Tommaso Foglia 961/147 Pagina 143 di 150

Appendice C
Di seguito saranno riproposte esclusivamente le integrazioni di codice
sull'applicazione StackedArea per la creazione di grafici. L'applicazione
StackedArea.jar è composta dalle seguenti classi: AvvioGrafici.java,
Configuratore.java, ConnectionPool.java, ConnectionPoolException.java,
DBScheduler.java, GeneratoreGrafici.java, Grafico.java, XMLValidator.java.
AvvioGrafici.java è di nuova creazione:
package stackedarea;
import java.text.*;
import java.util.Date;
import java.io.File;
import java.util.Calendar;
/**
* @author DopatO
*/
public class AvvioGrafici {
public static void main(String[] args){
Date unDate = new Date();
SimpleDateFormat formato = new SimpleDateFormat("yyyy-MM-dd");
String data = formato.format(unDate);
System.out.println(data);
String[] arg = new String[9];
//out.println("GENERANDO");
arg[0] =("PBS");
arg[1] =("-D") ;
arg[2] = ("/home/qjmon/sito1/");
Tommaso Foglia 961/147 Pagina 144 di 150

arg[3] =("sito1");
arg[4] = (data);
arg[5] = ("Monitor");
arg[6] = ("qjmon");
arg[7] = ("admin");
arg[8] = ("qjmon.scope.unina.it:3306");
stackedarea.Configuratore.main(arg);
}
}
Configuratore.java è stato adeguato con le seguenti linee, per creare anche i grafici
Custom:
//Creazione cartella Output anche per il nuovo caso C
File CartellaOutputDB,CartellaOutputC;
//CASO CODA
else if (!datad1.isEmpty()) {
CartellaOutputC = new File(folderOutput_C);
CartellaOutputDB = CartellaOutputC;
for (i = 0; i < numCode; i++) {
Grafico graficoC = new Grafico(vetCode[i], -1,
CartellaOutputDB.getAbsolutePath(), "coda." + nomeCode[i],
"hc_coda",datad1,datad2);
graficoC.idScheduler = idScheduler;
listaGraficiDB_C.add(graficoC);
}
//CASO VO
Tommaso Foglia 961/147 Pagina 145 di 150

else if (!datad1.isEmpty()) {
CartellaOutputC = new File(folderOutput_C);
CartellaOutputDB = CartellaOutputC;
for (i = 0; i < numVo; i++) {
Grafico graficoC = new Grafico(vetVo[i], -1,
CartellaOutputDB.getAbsolutePath(), "vo." + nomeVo[i], "hc_gruppo",datad1,datad2);
graficoC.idScheduler = idScheduler;
listaGraficiDB_VG.add(graficoC);
}
//CASO CODA DETTAGLI
else if (!datad1.isEmpty()) {
CartellaOutputC = new File(folderOutput_C);
CartellaOutputDB = CartellaOutputC;
for (i = 0; i < numGrup; i++) {
Grafico graficoC = new Grafico(idCoda[i], idVoG[i],
CartellaOutputDB.getAbsolutePath(), "codaDettagli." + nomeCoda[i] + "." + nomeVo[i],
"hc_gruppo",datad1,datad2);
graficoC.idScheduler = idScheduler;
listaGraficiDB_VG.add(graficoC);
}
//CASO OTHER
else if (!datad1.isEmpty()) {
CartellaOutputC = new File(folderOutput_C);
CartellaOutputDB = CartellaOutputC;
for (f = 0; f < numfuori; f++) {
Grafico graficoC = new Grafico(idUserfuori[f], idCodafuori[f],
CartellaOutputDB.getAbsolutePath(), "other." + nomeUserfuori[f],
"hc_gruppo",datad1,datad2);
graficoC.idScheduler = idScheduler;
Tommaso Foglia 961/147 Pagina 146 di 150

listaGraficiDB_VG.add(graficoC);
}
}
//INTEGRAZIONE NEL METODO MAIN
if (arg.length > 5) {
database = arg[5];
user = arg[6];
password = arg[7];
indirizzo = arg[8];
}
datad1= null;datad2=null;
if (arg.length > 9) {
datad1 = arg[9];
datad2 = arg[10];
data = datad1;
folderOutput_C = pathMonitor + "GraficiDB/" + datad1 + "/" + datad2;
(new File(folderOutput_C)).mkdirs();
} folderOutput_G = pathMonitor + "GraficiDB/" + data + "/Giornalieri";
folderOutput_S = pathMonitor + "GraficiDB/" + data + "/Settimanali";
folderOutput_M = pathMonitor + "GraficiDB/" + data + "/Mensili";
folderOutput_A = pathMonitor + "GraficiDB/" + data + "/Annuali";
test = pathMonitor + "GraficiDB/" + data + "/test";
if (datad1==null && (new File(folderOutput_G)).isDirectory() == false) {
(new File(folderOutput_G)).mkdirs();
(new File(folderOutput_S)).mkdirs();
(new File(folderOutput_M)).mkdirs();
(new File(folderOutput_A)).mkdirs();
(new File(test)).mkdirs();
Tommaso Foglia 961/147 Pagina 147 di 150

Grafico.java: I metodi per la creazione di grafici dovranno contenere i campi per le
date. Tutte le query sono state riscritte e diversificate in base ai vari criteri temporali.
Grafico(int idQuery, int idDettagli, String cartellaOutput, String nomeFile, String
nomeTABELLA,String data) {
this.idQuery = idQuery;
this.idDettagli = idDettagli;
this.cartellaDATI_OUTPUT = cartellaOutput;
this.nomeTABELLA = nomeTABELLA;
this.nomeFILE_GRAFICO = nomeFile;
this.data= data;
}
Grafico(int idQuery, int idDettagli, String cartellaOutput, String nomeFile, String
nomeTABELLA,String data1, String data2) {
this.idQuery = idQuery;
this.idDettagli = idDettagli;
this.cartellaDATI_OUTPUT = cartellaOutput;
this.nomeTABELLA = nomeTABELLA;
this.nomeFILE_GRAFICO = nomeFile;
this.data1= data1;
this.data2= data2;
}
Mostriamo a titolo di esempio un'unica ristrutturazione di query evitando una tediosa
ripetizione.
try {
if (nomeTABELLA.startsWith("hd"))
query2 = "select date,a.idVo,g.idgruppo,g.nome as nomeGruppo, " +
Tommaso Foglia 961/147 Pagina 148 di 150

" sum(Pend) as Pend ,sum(Run) as Run,sum(Susp) as Susp" +
" from " + nomeTABELLA + " as a left outer join gruppo as g on
a.idgruppo=g.idgruppo" +
" where a.idvo='" + idQuery + "' and idscheduler='" + idScheduler +"'
and DATE_FORMAT(date,'%Y-%m-%d')='" + data + "'" +
" group by date, a.idvo, g.idgruppo order by nomeGruppo, date";
else if (nomeTABELLA.startsWith("hw"))
query2 = "select date,a.idVo,g.idgruppo,g.nome as nomeGruppo, " +
" sum(Pend) as Pend ,sum(Run) as Run,sum(Susp) as Susp" +
" from " + nomeTABELLA + " as a left outer join gruppo as g on
a.idgruppo=g.idgruppo" +
" where a.idvo='" + idQuery + "' and idscheduler='" + idScheduler +"'
and DATE_FORMAT(date,'%Y-%m-%d') between DATE_SUB('" + data + "',INTERVAL 1
WEEK) and '" + data + "'" +
" group by date, a.idvo, g.idgruppo order by nomeGruppo, date";
else if (nomeTABELLA.startsWith("hm"))
query2 = "select date,a.idVo,g.idgruppo,g.nome as nomeGruppo, " +
" sum(Pend) as Pend ,sum(Run) as Run,sum(Susp) as Susp" +
" from " + nomeTABELLA + " as a left outer join gruppo as g on
a.idgruppo=g.idgruppo" +
" where a.idvo='" + idQuery + "' and idscheduler='" + idScheduler +"'
and DATE_FORMAT(date,'%Y-%m-%d') between DATE_SUB('" + data + "',INTERVAL 1
MONTH) and '" + data + "'" +
" group by date, a.idvo, g.idgruppo order by nomeGruppo, date";
else if (nomeTABELLA.startsWith("hy"))
query2 = "select date,a.idVo,g.idgruppo,g.nome as nomeGruppo, " +
" sum(Pend) as Pend ,sum(Run) as Run,sum(Susp) as Susp" +
Tommaso Foglia 961/147 Pagina 149 di 150

" from " + nomeTABELLA + " as a left outer join gruppo as g on
a.idgruppo=g.idgruppo" +
" where a.idvo='" + idQuery + "' and idscheduler='" + idScheduler +"'
and DATE_FORMAT(date,'%Y-%m-%d') between DATE_SUB('" + data + "',INTERVAL 1
YEAR) and '" + data + "'" +
" group by date, a.idvo, g.idgruppo order by nomeGruppo, date";
else if (nomeTABELLA.startsWith("hc"))
query2 = "select date,a.idVo,g.idgruppo,g.nome as nomeGruppo, " +
" sum(Pend) as Pend ,sum(Run) as Run,sum(Susp) as Susp" +
a.idgruppo=g.idgruppo" +
" from hd_gruppo as a left outer join gruppo as g on
" where a.idvo='" + idQuery + "' and idscheduler='" + idScheduler +"'
and DATE_FORMAT(date,'%Y-%m-%d') between '"+ data1+ "' and '" + data2 + "' "+
" group by date, a.idvo, g.idgruppo order by nomeGruppo, date";
/* QUERY originale query2 = "select date,a.idVo,a.idgruppo,g.nome as
nomeGruppo, " +
" sum(Pend) as Pend ,sum(Run) as Run,sum(Susp) as Susp" +
" from " + nomeTABELLA + " as a left outer join gruppo as g on
a.idgruppo=g.idgruppo" +
" where a.idvo=" + idQuery + " and idscheduler=" + idScheduler + " " +
" group by date, a.idvo, a.idgruppo order by nomeGruppo, date";
*/
Tommaso Foglia 961/147 Pagina 150 di 150