studio delle prestazioni di un batch system basato …...una natura ciclica, in cui la fase di...
TRANSCRIPT
Università degli Studi di PerugiaFacoltà di Scienze Matematiche, Fisiche e Naturali
Corso di Laurea in Informatica
Tesi di Laurea
Studio delle prestazioni di un batch system basato
su TORQUE / Maui
Candidato
Francesco Cantini
Relatore Correlatore
Prof. Leonello Servoli Mirko Mariotti
Anno Accademico
2006-2007
1
2
Indice
INTRODUZIONE....................................................................................... ...9
BATCH SYSTEM.................................................................................. ......13
1.1 Il concetto di batch production.......................................................................13
1.2 Nascita ed evoluzione dei batch system.........................................................14
1.2.1 Generazioni pre batch system................................................................14
1.2.2 Prima generazione batch system............................................................14
1.2.3 Seconda generazione batch system........................................................16
1.2.4 Terza generazione batch system............................................................17
1.2.5 Il tramonto dei batch system storici.......................................................18
1.3 Batch system oggi..........................................................................................20
1.3.1 Struttura fisica di un batch system.........................................................20
1.3.2 Struttura logica di un batch system........................................................22
1.3.3 Perché il batch computing ?...................................................................24
1.3.4 super-computers o cluster computers ?..................................................24
1.3.5 Limiti del batch computing....................................................................25
1.3.6 Superamento dei limiti: il calcolo distribuito........................................26
IL CLUSTER INFN DI PERUGIA...................................................... ........27
2.1 Dalla nascita del cluster all'ingresso in GRID................................................27
2.2 Livello hardware: la struttura del cluster........................................................29
2.2.1 Architettura della rete............................................................................29
2.2.2 I nodi......................................................................................................30
2.2.3 Il cluster fisico in dettaglio ...................................................................31
2.2.4 Le risorse hardware del cluster in sintesi...............................................34
2.3 Peculiarità della farm.....................................................................................35
2.3.1 Risorse hardware e diritti d'uso.............................................................35
2.3.2 Una farm ibrida......................................................................................35
2.3.3 WN su rete nascosta...............................................................................37
2.3.4 Macchine Virtuali..................................................................................38
2.4 Livello software: il batch system...................................................................40
2.4.1 Gruppi, utenti e quote computazionali...................................................40
2.4.2 Tipologia dei job....................................................................................41
2.4.3 Accesso e sicurezza...............................................................................41
2.4.4 Il batch system in uso............................................................................42
2.4.5 Configurazione di TORQUE.................................................................42
2.4.6 Configurazione di Maui.........................................................................43
2.5 Formulazione del problema............................................................................44
3
TORQUE + Maui.................................................................................. .......47
3.1 TORQUE........................................................................................................47
3.1.1 Architettura e “demoni”.........................................................................48
3.1.2 Ciclo di funzionamento di pbs_server...................................................49
3.1.3 Scalabilità..............................................................................................50
3.2 Maui...............................................................................................................51
3.2.1 Interazione col resource manager..........................................................51
3.2.2 Scheduling, policy & fairness................................................................52
3.2.3 Priorità di esecuzione.............................................................................52
3.2.3.1 Gerarchie di componenti...............................................................53
3.2.3.2 Calcolo della priorità di un job.....................................................55
3.2.3.3 Elenco delle componenti ..............................................................56
3.2.4 Node allocation......................................................................................57
3.2.5 Maui Fairness........................................................................................59
3.2.5.1 Restrizione delle allocazioni.........................................................59
3.2.5.2 Fairshare........................................................................................60
3.2.5.3 Resource allocation management..................................................62
3.2.6 Il controllo dell'accesso alle risorse.......................................................62
3.2.6.1 Prenotazione delle risorse.............................................................62
3.2.6.2 Partizionamento delle risorse........................................................65
3.2.6.3 QoS (Qualità del Servizio)............................................................65
3.2.7 Maui Backfill.........................................................................................66
3.2.8 Ciclo di esecuzione di Maui..................................................................68
3.2.9 File di traccia.........................................................................................69
3.2.10 Scheduling e simulazione....................................................................70
ALLESTIMENTO DELL'INFRASTRUTTURA DI VALIDAZIONE E SVILUPPO DEI TOOL DI ANALISI............................................ ..............71
4.1 L'esperimento di validazione..........................................................................71
4.2 Allestimento batch system di test...................................................................73
4.2.1 Struttura del batch system di test...........................................................73
4.2.2 Installazione e configurazione di TORQUE..........................................75
4.2.3 Installazione e configurazione di Maui..................................................78
4.2.4 Configurazione di SSH..........................................................................79
4.2.5 Creazione degli utenti............................................................................81
4.3 Tool di base.....................................................................................................82
4.3.1 Lo script “makeuser.sh”.........................................................................82
4.3.2 Lo script “sleep-launcher.sh”.................................................................83
4.3.2 Lo script “job-launcher.sh”....................................................................84
4.3.4 Lo script “workload-time-updater.pl”....................................................84
4.3.5 Lo script workload-analyzer.pl..............................................................85
4.3.5.1 Complessità temporale di workload-analyzer.pl...........................89
4
4.4 Tool di automazione evoluta..........................................................................90
4.4.1 Necessità di automazione......................................................................90
4.4.2 Script di simulazione automatica “simulate.sh”....................................92
4.4.3 Script di esecuzione automatica “launch.sh”.........................................94
4.4.4 Il livello superiore: lo script “run.sh”....................................................95
4.4.5 Funzioni avanzate di “run.sh”...............................................................98
VALIDAZIONE DEL SIMULATORE...................................................... .101
5.1 Validazione...................................................................................................101
5.1.1 Obbiettivi di validazione......................................................................102
5.1.2 Modalità di validazione ......................................................................103
5.1.3 Tipo di job usati per le esecuzioni reali...............................................104
5.1.4 Criterio di verosimiglianza..................................................................105
5.2 Presa di contatto col simulatore...................................................................106
5.2.1 Problemi riscontrati e soluzioni adottate.............................................106
5.2.1.1 La carenza di documentazione ...................................................106
5.2.1.2 Scoperta e correzione di un bug..................................................106
5.2.1.3 Una corretta procedura di simulazione.......................................107
5.2.2 Visualizzazione delle tracce.................................................................109
5.2.3 Scheduling reale, simulato e relative tracce.........................................111
5.2.3.1 Ritardo dovuto a overhead nel batch system reale......................111
5.2.3.2 Overhead e quantizzazione dei tempi.........................................112
5.2.3.3 Simulazione e soppressione dell'overhead..................................113
5.2.3.4 Allocazione delle risorse “identica” o “compatibile”..................114
5.2.3.5 Scheduling “compatibile”...........................................................116
5.2.3.6 Criteri di compatibilità per validazione “black box”..................117
5.2.3.7 Idealità, realtà e validazione “black box”...................................117
5.3 Test di validazione e relativi risultati............................................................118
5.3.1 Verifiche elementari sui tempi.............................................................118
5.3.1.1 Rispetto dei tempi e delle durate di esecuzione..........................118
5.3.1.2 Repliche dell'esperimento...........................................................120
5.3.2 Verifiche dell'ordine di allocazione dei nodi.......................................120
5.3.2.1 Identicità dell'ordine di allocazione dei nodi..............................120
5.3.2.2 Repliche degli esperimenti..........................................................122
5.3.2.3 Ordine di allocazioni dei nodi “compatibile”.............................123
5.3.2.4 Ordine di scheduling compatibile...............................................124
5.3.3 Verifiche di indipendenza dall'input....................................................125
5.3.4 Simulazione del meccanismo di priorità..............................................126
5.3.4.1 Test di priorità di utenti...............................................................127
5.3.4.2 Repliche del test di priorità.........................................................130
5.3.5 Simulazione di limiti statici di allocazione..........................................130
5.3.5.1 Test dei limiti statici attribuiti per utente ...................................130
5.3.5.2 Prima variante del test dei limiti di allocazione..........................132
5
5.3.5.3 Seconda variante del test dei limiti di allocazione......................132
5.3.5.4 Repliche dei test sui limiti statici................................................134
5.3.6 Conclusioni riguardo i test di validazione...........................................134
ANALISI DEI DATI E STRUMENTI DI MISURA............................ ......135
6.1 Tracce di Maui..............................................................................................135
6.2 Semplici esempi di analisi delle tracce.........................................................136
6.2.1 Tempo in coda dei job di certificazione...............................................136
6.2.2 Ricerca di job di certificazione “periodici”.........................................138
6.2.3 Sottomissione massiccia di job utente.................................................139
6.3 Metriche di valutazione................................................................................140
6.4 Rappresentazione.........................................................................................140
6.5 Metrica di equità...........................................................................................142
6.6 Metrica di efficienza.....................................................................................144
6.7 Intervallo di interazione Maui / TORQUE ed efficienza del sistema...........147
CONCLUSIONI............................................................ ............................151
RINGRAZIAMENTI................................................................. ................153
APPENDICI............................................................................................ ...155
Appendice A1 ....................................................................................................155
Appendice A2 ....................................................................................................158
Appendice A3.....................................................................................................160
Appendice A4 ....................................................................................................161
6
A mio zio Carlo,
le cui passioni vivono ancora.
7
8
INTRODUZIONE
I vantaggi derivanti dalla gestione unificata e centralizzata di un sistema di calcolo,
hanno portato col tempo i gruppi di ricerca, afferenti alla Sezione dell'Istituto Nazionale
di Fisica Nucleare e al Dipartimento di Fisica dell'Università e di Perugia, alla messa in
compartecipazione dei propri apparati di elaborazione in un unico cluster di computer,
adibito a funzioni di batch system. La struttura è cresciuta gradualmente fino a
raggiungere dimensioni considerevoli e dall'anno 2004 il cluster è uno dei siti INFN
GRID dislocati sul territorio nazionale.
La concentrazione di potenza di calcolo comunque, non è di per se sinonimo di
efficienza senza un'amministrazione opportuna; un sistema come il precedente può
produrre disservizi nei confronti della propria utenza e un servizio non all'altezza delle
aspettative. Politiche di allocazione delle risorse troppo permissive o restrittive possono
portare alla monopolizzazione dell'intero sistema da parte di un solo utente o lasciare
inutilizzate preziose risorse di calcolo. Nel primo caso si ha il malcontento degli altri
utenti, nel secondo una perdita di efficienza del sistema. La grande eterogeneità di job
sottomessi al sistema, unita alla variabilità nel tempo del flusso di accodamento, nonché
alla possibilità di ricevere richieste di computazione sia da locale che via GRID,
rendono inefficace l'uso di singole strategie. Spesso la garanzia minima di un servizio
equo, passa per decine di code di sottomissione dei job e file di configurazione dello
scheduler con centinaia di policy. La complessità del problema è indubbiamente
notevole.
Questo lavoro di tesi si occuperà di studiare come districare almeno in parte questa
aggrovigliata matassa, fornendo gli strumenti con cui ricercare la sottile linea di
equilibrio, tra la soddisfazione dell'utenza e l'efficienza di utilizzo del sistema.
9
Struttura della tesi
La presentazione del lavoro di tesi consiste in cinque capitoli, a cui si aggiungono le
conclusioni e le appendici.
• Il primo capitolo introduce il concetto di batch computing, considerando
anche il percorso storico che dai primi esempi di batch system, ha portato agli
attuali apparati di calcolo automatizzato.
• Il secondo capitolo presenta il batch system che costituisce il sito INFN GRID
di Perugia, descrivendone le caratteristiche strutturali, la configurazione
corrente ed il bacino di utenza che ad esso afferisce. In questo capitolo viene
inoltre formulato il problema dell'ottimizzazione per tale struttura di calcolo.
• Il terzo capitolo descrive le caratteristiche di un batch system basato su
scheduler Maui e resource manager TORQUE, lo stesso in uso nel sito INFN
GRID di Perugia. Di questi due software sono presi in considerazione i
principali meccanismi di funzionamento e le politiche di scheduling
implementate. Si introduce inoltre il simulatore di Maui e la sua importanza
come strumento di previsione, sull'impatto di politiche di scheduling
sperimentali.
• Il quarto capitolo si occupa di illustrare l'infrastruttura hardware e software
messa in esercizio per lo studio e la validazione del simulatore di Maui. In
questo capitolo vengono anche presentati i diversi programmi, sviluppati per
l'analisi dei dati del batch system in questione.
• Il quinto capitolo spiega le tecniche adottate per la verifica di validità del
simulatore, la correzione di alcuni problemi di tale software ed infine presenta
il pacchetto di prove di validazione eseguite, discutendo i risultati ottenuti.
• Il sesto capitolo tratta alcune semplici analisi dei dati del batch system INFN
GRID di Perugia, e presenta le due fondamentali metriche di valutazione,
formulate nel corso di questo lavoro, per l'analisi quantitativa di grandezze
particolarmente significative, legate al funzionamento del sistema.
10
Il futuro è radioso.
Kant
11
12
Capitolo 1
BATCH SYSTEM
1.1 Il concetto di batch production
Parlando di batch production, si intende solitamente un metodo in cui la produzione di
determinati oggetti, articoli, alimenti, ecc. avviene per gruppi detti batch
( letteralmente “infornate” ), in analogia a quanto si verifica in un forno per la cottura
del pane o in quegli impianti industriali, ove la produzione sia scandita da fasi operanti
ognuna su una molteplicità di prodotti. Questo metodo di lavorazione è caratterizzato da
una natura ciclica, in cui la fase di produzione è preceduta da una fase improduttiva,
detta down time, durante la quale avviene la preparazione del successivo batch (figura
1.1). Tale inefficienza intrinseca al procedimento, è comunque compensata dalla mole
dei prodotti, ottenuti ad ogni iterazione. Questo modello produttivo, trova applicazione
in molteplici contesti, dall'industria alimentare a quella chimica o metallurgica ed
ovviamente anche nell'informatica.
ProdottoFinito
Sistema Batch
Preparazione del batch
Down Time ProductionTime
Lavorazione del batch
MateriaPrima
Figura 1.1
Schema logico di una produzione di tipo batch
L' applicazione del concetto di batch production alla gestione di un computer prese
storicamente il nome di batch computing ed il sistema che la implementava era detto
batch system. Nel presente, la dicitura batch system mantiene buona parte dell'originale
connotazione semantica ma designa apparati di calcolo che in termini di impianto
hardware e software ben poco hanno a che vedere col passato.
13
1.2 Nascita ed evoluzione dei batch system
Il significato storico del termine batch system è indissolubilmente legato alla la storia
dei primi computer ed alla modalità di funzionamento dei loro sistemi operativi.
1.2.1 Generazioni pre batch system
I primi sistemi di elaborazione, erano caratterizzati dall'assenza di sistema operativo ed
il programmatore accedeva direttamente alla macchina, immettendo dati e programmi
attraverso interfacce rudimentali come lettori di schede o nastri perforati. Le
computazioni eseguibili erano per forza di cose relative ad un singolo programma ed
avvenivano secondo il paradigma:
• Immissione programma e dati
• Elaborazione
• Raccolta dei risultati
Il risultato finale era solitamente ottenuto al termine di una catena di esecuzioni
elementari, ognuna preceduta e seguita dalle relative operazioni di input ed di output. Le
fasi di immissione e raccolta dati, si alternavano quindi a quelle di esecuzione anche
all'interno di quelle elaborazioni che nel complesso erano da considerare logicamente
unitarie. L'interazione umana col sistema era totale e continuativa. E' chiaro che una
siffatta gestione, oltre ad essere ripetitiva e gravosa per l'operatore, si traduceva in uno
sfruttamento altamente inefficiente del calcolatore: il processore era assorto in
operazioni non produttive (idle), sia durante le fasi di input che quelle di output, ossia
per la maggior parte del tempo. I “velocissimi” tempi di macchina erano costantemente
intervallati, e quindi vanificati, dai “lentissimi” tempi umani per l' immissione dei
programmi e la raccolta dei dati delle operazioni intermedie. Lo spreco di tempo di
calcolo era ancor più intollerabile se valutato in rapporto al costo di un computer di
quegli anni. Fu con l'intento di ovviare a questo problema che, a partire dalla seconda
metà degli anni cinquanta dello scorso secolo, vennero sviluppati i primi sistemi
operativi “a lotti” o “batch”.
1.2.2 Prima generazione batch system
L'idea di base di questi sistemi era quella di raggruppare processi computazionali
elementari, detti job, assieme ai relativi dati di input ed i comandi per la loro
esecuzione, in un unico insieme detto batch. I criteri di composizione di un batch
14
potevano rispecchiare legami di consequenzialità dei job oppure di affinità di operazioni
tra questi. Il batch, che nella realtà era realizzato da un lotto di schede preventivamente
ed opportunamente perforate, veniva sottomesso al computer in un' unica volta. Il
sistema operativo si faceva carico di eseguire nel giusto ordine ogni job, di raccogliere
gli output intermedi e trasformarli negli input delle operazioni successive, fino al
completamento del pacchetto di istruzioni. Per tutta la durata dell'esecuzione, il sistema
non richiedeva più l'interazione con l'operatore (a meno di errori occorsi), e
l'avanzamento dei job avveniva alla massima velocità possibile, senza interruzioni. Il
problema dello storage temporaneo dei dati intermedi, veniva efficacemente risolto
adottando l' uso delle allora nascenti, e relativamente veloci, memorie di massa a nastro
magnetico che all'occorrenza ospitavano anche il sistema operativo. In Figura 1.2 è
riportato un tipico esempio di batch di schede perforate per la compilazione di un
programma Fortran e la successiva esecuzione. Sono evidenziate in colore giallo le
schede che codificano comandi rivolti al sistema operativo (solitamente scelti in un
repertorio chiamato Job Control Language), in celeste le schede corrispondenti al
sorgente Fortran del programma ed in verde i dati richiesti per la successiva esecuzione.
L' ordine con cui il sistema avrebbe letto le schede, è quello mostrato.
Figura 1.2
Lotto di schede perforate riguardanti compilazione ed esecuzione immediata di un programma in linguaggio Fortran.
I batch system di prima generazione portarono ad una notevole riduzione dei tempi
morti, grazie ad un abbattimento delle interazioni uomo–macchina. Malgrado ciò, il
tasso di utilizzo del processore restava modesto. La sottomissione del batch avveniva
con la lettura di un certo numero di schede perforate attraverso un dispositivo
elettromeccanico e lo stesso output finale consisteva nel perforare nuove schede o nello
15
stampare il risultato su carta, via telescrivente, un carattere alla volta. Tali operazioni,
seppure lentissime, impegnavano comunque il processore in modo totale, dedicando
una risorsa preziosa all'espletamento di funzioni di importanza non fondamentale.
1.2.3 Seconda generazione batch system
A partire dai primi anni sessanta, una seconda generazione di sistemi batch vide la luce.
Essa manteneva l'approccio originario al problema ma si avvaleva sistematicamente dei
vantaggi apportati dalle memorie a nastro magnetico. Le lente periferiche
elettromeccaniche con cui il calcolatore interagiva col mondo esterno (stampanti, lettori
e perforatori di schede) vennero rimpiazzate da due unità a nastro magnetico: una per
l'input ed una per l' output. Al sistema principale furono affiancati uno o più calcolatori
“satellite” (Figura 1.3), dal costo decisamente minore, provvisti di un' unità a nastro
magnetico e di periferiche di input ed output come quelle dismesse dal calcolatore
“centrale”. L' utente continuava a produrre lotti di schede perforate ma questi venivano
ora letti da uno dei sistemi satellite e l' immagine del batch convertita in un archivio
(file) su nastro magnetico. Completata la serie di acquisizioni, un operatore provvedeva
al trasferimento della bobina al calcolatore principale. La sottomissione dei job al
sistema avveniva quindi con una semplice e rapida lettura del nastro, abbattendo
radicalmente i tempi di acquisizione del batch da parte del processore. La fase di
computazione continuava a svolgersi autonomamente coi vantaggi di cui sopra ed in
caso di successo i risultati erano scritti su un' altra unità di memoria a nastro magnetico,
che successivamente poteva essere letta da un sistema satellite e convogliata verso una
stampante od un perforatore di schede.
figura 1.3
(a) Perforazione del lotto di schede (b) Acquisizione lotto e riversamento su nastro magnetico (c) Trasferimento nastro di input al sistema centrale (d) Lettura, elaborazione e scrittura risultati (e) Trasferimento nastro di output ad un sistema satellite (f) Stampa su carta o perforazione schede.
16
1.2.4 Terza generazione batch system
Durante il corso degli anni sessanta, i batch system conobbero un ulteriore sviluppo che
sfociò in una terza generazione. I progressi tecnologici avevano portato ad una rapida
crescita delle dimensioni della memoria principale e della velocità del processore,
inoltre la comparsa del sistema di interruzione e dei controllori di accesso diretto alla
memoria (DMA), rendevano superflua la presenza di calcolatori satellite per la gestione
ottimizzata di input ed output di sistema. Inoltre gli apparati di storage a nastro furono
abbandonati, in favore dei ben più efficienti dischi magnetici. In questo scenario i batch
system compirono un grande balzo in avanti in termini di sfruttamento del processore. Il
sistema di interruzione permetteva infatti una primitiva ma efficace forma di
ripartizione in tempo della CPU del calcolatore segnando l' abbandono di un modello di
esecuzione puramente seriale. L' elaborazione di un batch poteva cioè essere intervallata
dall'esecuzione di un qualsiasi numero di routine di servizio, invocate dai relativi
segnali di interruzione, al fine di implementare un insieme di funzionalità fino ad allora
impensabili. Degna di nota è l' astrazione dei dispositivi di ingresso ed uscita, introdotta
coi lettori e le stampanti virtuali. Apposite routine di servizio dette gestori di dispositivo
virtuale, potevano leggere in un qualsiasi momento un lotto di schede perforate presso
uno o più dispositivi fisici di input. Il batch era copiato in una porzione di memoria
principale (buffer) e quindi archiviato in un file su disco nei tempi più consoni per l'
avanzamento del sistema stesso. Questo meccanismo che astraeva l'interazione col
dispositivo di lettura e slegava l'operazione di acquisizione di un lotto di schede dalla
subitanea esecuzione, costituiva appunto il lettore virtuale (Figura 1.4).
Stampante
Lettore schede
Buffer BufferBuffer
Gestorelettorevirtuale
Gestoreesecuz.batch
Gestorestampavirtuale
CPU
Disco magneticoLettore virtuale Stampante Virtuale
Batches
RAM
Figura 1.4
Struttura logica di un batch system di terza generazione, con enfasi dei dispositivi virtuali
17
Il sistema poteva percepire a questo punto non più un singolo batch ma un insieme di
questi. La presenza simultanea di più batch pronti all'esecuzione, si traduceva nella
possibilità di comporli in una coda. All'occorrenza la coda poteva essere riordinata
secondo criteri di priorità o criteri logici del tutto indipendenti dall'ordine fisico con cui
i lotti di schede erano stati sottomessi al terminale di lettura. Si comincia con questa
generazione a parlare di scheduling di job. Quanto detto per l' astrazione dei dispositivi
di ingresso valeva analogamente per quelli di uscita. La tecnica di astrazione dei
dispositivi di input ed output prese il nome di Simultaneous Peripheral Operation On
Line (SPOOL). In Figura 1.5 viene riportata una rappresentazione logica del flusso di
esecuzione, basato sulla tecnica di spooling.
BatchesStampanteSpool dei batch in
ingressoSpool deile stampe
in uscitaEsecuzione
Figura 1.5
Spool di ingresso ed di uscita, in un sistema batch di terza generazione
1.2.5 Il tramonto dei batch system storici
Malgrado la terza generazione dei sistemi a lotti rappresentasse una mirabile evoluzione
rispetto alle precedenti, mostrava ancora un limite notevole. In essa il processore era
ripartito tra le routine che implementavano le funzioni del sistema operativo e la ben più
onerosa esecuzione del batch. Nel caso in cui l'elaborazione del batch fosse stata
accompagnata da un elevato numero di accessi al disco per operazioni di lettura e
scrittura, il processore doveva arrestarsi frequentemente in attesa della risposta del
dispositivo, i cui tempi di latenza erano enormi rispetto ai tempi di CPU. Ciò
comportava ancora una volta uno spreco di risorse e, di conseguenza, basse velocità di
esecuzione. Lo sviluppo successivo fu quello di permettere la coesistenza in esecuzione
di più batch, anziché uno solo. Grazie agli allora nascenti modelli di caricamento
18
dinamico della memoria principale ed all'affinamento delle tecniche di gestione del
processore, i job di batch diversi trovarono spazio per una coesistenza simultanea nel
sistema. Quando un job entrava in attesa di un dispositivo (o di un qualche evento),
subiva il pre-rilascio del processore, in favore del job di un diverso batch, pronto invece
all'esecuzione. Ovviamente le esecuzioni dei job sospesi potevano riprendere quando
fossero tornati di nuovo pronti. L' aggiunta di una equa politica di alternanza nell'uso del
processore, migliorò ancor più la resa del sistema, dando l'effetto di una esecuzione
parallela di tutti i lotti. Questo nuovo approccio cominciava ad essere palesemente in
contrasto con la definizione stessa di batch production: nessun fornaio sospenderebbe la
cottura dei propri pani dopo una frazione del tempo necessario, per passare ad una
cottura parziale dei biscotti, poi dei dolci e di nuovo tornare ai pani, e così via fino alla
completa cottura di ogni prodotto. Il termine job fu dunque rimpiazzato da quello di
“processo” e per designare ognuno dei batch che coesistevano in fase di esecuzione
alternata, si preferì il termine “attività”. Il risultato fu che questa nuova generazione di
calcolatori fu detta “multi-programmata” anziché “multi-batch”.
Successive evoluzioni tecnologiche condussero alla riconquista di una caratteristica
perduta dai batch system: la piena interattività tra sistema ed operatore. Grazie ai
progressi degli apparati hardware ed alla multiprogrammazione, ciò non costituì più un
limite alle prestazioni della macchina e permise una fruibilità dell'apparato di calcolo
enormemente superiore. La sintesi di questo progresso fu rappresentata dai sistemi
“time sharing”: grandi unità centrali (mainframe) collegate ad un elevato numero di
terminali interattivi da cui era possibile richiedere al sistema servizi, ricevere in tempo
reale la risposta, inserire programmi e dati. Sul finire degli anni sessanta, l' affermarsi
dell'architettura time sharing sancì definitivamente il tramonto dei computer, e relativi
sistemi operativi, di tipo batch.
19
1.3 Batch system oggi
Le generazioni storiche di sistemi batch rispecchiavano in modo esemplare il concetto
di batch production. Malgrado queste architetture scomparvero dopo poco più di un
decennio di sviluppo il loro nome continuò ad esistere, designando apparati di calcolo
che pur non avendo nulla da condividere in termine di impianto hardware e software
con i propri antenati, operavano e tuttora operano in modo da fornire un servizio di
elaborazione che poco si discosta da produzioni concettualmente batch. Due moderne
ed essenziali definizioni, potrebbero essere le seguenti:
Batch processing: esecuzione di una serie di programmi utenti detti “job” in un
computer senza interazione umana, quando possibile.
Batch system: un qualunque sistema di calcolo in grado di supportare il batch
processing.
I batch job possono essere sottomessi al sistema, solo da utenti accreditati. Ogni job è
corredato dai relativi dati o parametri di input, dalla specifica del trattamento desiderato
e delle risorse di calcolo richieste. Le problematiche relative all'esecuzione sono di
esclusiva competenza del sistema e non riguardano l' utente.
Un moderno batch system appare ai suoi utilizzatori come un insieme organico, astratto
e semplice, del quale è possibile ignorare la quasi totalità dei dettagli implementativi,
senza rinunce in termini di fruizione delle risorse di calcolo. Esso provvede tutti gli
strumenti atti a garantire una piena condivisione della sua potenza di calcolo, tra gli
utenti accreditati, consente il grande vantaggio di essere accessibile da remoto, e
dispone dei necessari meccanismi per l'esecuzione efficiente dei job e la gestione di
eventuali errori.
1.3.1 Struttura fisica di un batch system
Come appare dalle precedenti definizioni, la valenza di un batch system è quella di
poter erogare capacità di calcolo, in favore di un dato insieme di fruitori che ne facciano
richiesta. Dato lo scopo, è facilmente intuibile la presenza un'architettura hardware non
banale, caratterizzata da un consistente numero di risorse come processori, memoria
principale, memoria di massa, interfacce di comunicazione ecc. A prescindere dalle
scelte implementative, è spesso utile operare una suddivisione di queste risorse in unità
logiche dette “nodi” . Un nodo è rappresentato da almeno un processore e dall'insieme
20
di risorse di memoria e di comunicazione che ad esso afferiscono. In un generico
sistema batch, i nodi possono essere classificati in base alla propria appartenenza ad
almeno una delle seguenti quattro categorie:
➢ Central manager node
➢ execution node
➢ user interface node
➢ checkpoint server node
Il ruolo di central manager è il più importante in quanto prevede la gestione ed il
coordinamento dell'intero sistema. I programmi che girano su questo nodo raccolgono
le richieste di elaborazione (i job) degli utenti, dal nodo users interface e le ripartiscono
tra i nodi di esecuzione, mediando tra le risorse richieste e quelle al momento offerte.
Lo svolgimento di queste attività, comporta che il central manager debba essere la
macchina con le più spiccate doti di connettività nei confronti degli altri nodi e che offra
le migliori garanzie in fatto di stabilità di funzionamento, giacché una “caduta”
comprometterebbe l' operatività dell'intero sistema. I nodi di tipo execution sono come
ci si attende i più numerosi. In alcune implementazioni di batch system, essi possono
appartenere ad un insieme anche molto eterogeneo, in termini di prestazioni e risorse a
disposizione. Gli execution node comunicano col central manager, eseguendo i job che
questo invia loro e ritornando i risultati. I nodi con funzionalità user interface,
rappresentano la porta di accesso al sistema per gli utenti accreditati. A questi
pervengono le richieste di esecuzione dei job dagli utenti ed i risultati del calcolo
effettuato dal sistema (cosicché i committenti possano prelevarli). Questo tipo di nodi
dovrebbe possedere buoni requisiti in fatto di memoria sia principale che di massa. Il
nodo checkpoint è facoltativo. Se presente, confluiscono in esso i file di checkpoint per
i job in esecuzione. In caso di guasto di un nodo execution, il job ospitato può essere
ricostruito da questo file e riavviato altrove. Tale servizio comporta continui
trasferimenti di grandi quantità di dati e, quando presente, deve necessariamente
risiedere su nodi con grande capacità di comunicazione e capienti unità per lo storage
dei dati. L'appartenenza di un nodo ad una delle quattro precedenti categorie non è
necessariamente esclusiva ma sono ammesse, anche se non consigliate,
sovrapposizioni1. In Figura 1.6 si riporta il modello fisico per un batch system di tipo
“cluster”.
1 A titolo di esempio si consideri un nodo central manager adibito anche all'esecuzione di job od alle
funzioni di user interface.
21
Figura 1.6
Impianto hardware di un sistema batch basato su cluster computer. Le frecce evidenziano la centralità del nodo “manager” relativamente alla comunicazione interna.
1.3.2 Struttura logica di un batch system
L' amministrazione di un sistema batch non è un compito banale. I job sottomessi dagli
utenti, sono spesso di natura eterogenea, hanno durate molto variabili e possono
richiedere quantità di risorse che non siano al momento disponibili. Come se non
bastasse, il migliore ordine di esecuzione per i job, non coincide quasi mai con quello di
arrivo e specifiche politiche di riordino devono essere attuate per massimizzare il tasso
di utilizzo del sistema e minimizzare i tempi di attesa per i job non ancora lanciati. La
decisione di quale sia la migliore sequenza di esecuzione spetta alla componente di gran
lunga più importante di un batch system: lo scheduler.
Lo scheduler è un programma, in esecuzione permanente sul nodo designato al ruolo di
manager del sistema, che si occupa di calcolare un giusto ordine di esecuzione dei job
pervenuti. La definizione di “giusto ordine” è al momento prematura e quindi tale
dicitura sarà in questa sede, intesa semplicemente come un punto di equilibrio tra
richieste degli utenti e tempi di risposta del sistema. Oltre ad effettuare il riordino dei
job, lo scheduler provvede a che questi non interferiscano gli uni con gli altri in termine
di allocazione delle risorse e fornisce i necessari meccanismi per la loro gestione
differenziata, secondo classe di appartenenza, importanza, ecc. Lo scheduler è
programmato per prendere decisioni (si spera buone) riguardo le attività future del batch
system ma è solitamente sprovvisto degli strumenti che consentano la manipolazione
22
dei job all'interno del sistema stesso. Affinché ciò divenga possibile esso è coadiuvato
da una sorta di factotum, che implementa tutte le strutture dati per l'amministrazione dei
job ed ha piena visibilità delle risorse al momento disponibili (oltre a quelle occupate da
esecuzioni in corso). Questo programma prende il nome di resource manager e
solitamente gira anch'esso sul nodo “principale”2.
Resource Manager
Central manager node
Userinterface
CPU
CPU
CPU
CPU
CPU
CPU
CPU
Jobs
Risultati
Jobs
Code di jobsJobs
utente
Executionnodes
“Esegui!”
ComandiInformazioni
Scheduler
Figura 1.7
Interazioni scheduler ↔ resource manager ↔ sistema. In rosso è evidenziato l'effetto della decisione dello scheduler, di mandare in esecuzione i primi due job della coda in alto, in due nodi di calcolo disponibili e la conseguente attuazione da parte del resource manager.
Come visibile in Figura 1.7, il resource manager preleva i job sottomessi dagli utenti
attraverso la user interface e li ripartisce tra code (dette anche classi) in base a quanto
specificato nei dati che accompagnano il job stesso. Il numero delle code è limitato solo
inferiormente (almeno una deve esistere), sono create dall'amministratore di sistema
secondo le politiche che si vogliano attuare ed hanno la funzione di contenitori logici
per i job in attesa di esecuzione. Si noti nuovamente dall'immagine come lo scheduler
interagisca esclusivamente con il resource manager, dal quale riceve informazioni sulle
code e sullo stato sistema.
2 La soluzione con scheduler e resource manager in esecuzione sullo stesso nodo (central manager), è una
prerogativa dei sistemi di dimensione medio piccola. Sistemi di grandi possono adibire alle due funzioni
nodi separati. Sistemi particolarmente estesi richiedono addirittura più di un nodo con funzione di
resource manager, tra i quali ripartire la gestione dei numerosi execution node.
23
Confrontando queste informazioni con l'insieme delle policy3 con le quali è
programmato, lo scheduler comanda al resource manager operazioni sui job, richiede
informazione sullo stato di esecuzione ed avvia ai nodi di calcolo liberi, i job che ne
hanno maturato il diritto. Il resource manager risponde alle richieste ed esegue i
comandi, interagendo con il preposto programma in esecuzione sui nodi di calcolo.
Lo schema di Figura 1.7 si riferisce all'architettura più semplice e diffusa, dove lo
scheduler comanda un solo resource manager. Nel caso di sistemi particolarmente
estesi, i resources manager possono essere molteplici, ferma restando l' unicità dello
scheduler.
1.3.3 Perché il batch computing ?
Il batch computing ha dimostrato nel corso degli anni, di essere un modello vincente per
l'implementazione e la fruizione di apparati di calcolo ad alte ed altissime prestazioni.
Alcuni dei benefici apportati da questa impostazione sono i seguenti.
• Permette la facile condivisione delle risorse di calcolo tra più utenti.
• Consente la ripartizione degli utenti in classi di utenza, caratterizzate da privilegi o
restrizioni riguardo l'accesso alle risorse (servizi differenziati).
• La gestione automatizzata evita i momenti d'inattività dei nodi di calcolo, senza bisogno
di una costante interazione umana.
• Permette i vantaggi tipici della gestione centralizzata di un sistema.
• Consente un veloce ammortamento degli investimenti per i sistemi più costosi grazie ad
un elevato e costante utilizzo delle risorse.
1.3.4 super-computers o cluster computers ?
Un batch system è un'astrazione, un paradigma, un modello computazionale secondo cui
offrire agli utenti, accesso alle risorse di un computer dall'elevata potenza di calcolo. In
teoria, se ne potrebbero descrivere le caratteristiche ed i servizi, senza nemmeno
accennare allo hardware sottostante. Ciò non vuol dire comunque che lo hardware non
ci sia.
3 Per il momento si intenderà il termine policy come sinonimo di regola impostata nello scheduler, per la
realizzazione di una prestabilita politica di funzionamento.
24
I calcolatori che si sceglie di adibire ad attività di batch computing possono essere
realizzati secondo architetture molto diverse, a seconda delle esigenze e delle possibilità
economiche. In ogni caso, qualunque sia la scelta, essa ricadrà di certo in una delle due
categorie di sistemi votati a questo utilizzo:
➢ super-computers
➢ cluster computers
La prima categoria fa riferimento a “macchine dedicate”, sviluppate secondo tecnologie
proprietarie, mentre la seconda rappresenta una evoluzione piuttosto recente del
concetto di rete di calcolatori, resa possibile dalla grande potenza di calcolo raggiunta
dai calcolatori commerciali e dalla notevole velocità di comunicazione tra i nodi4.Un
cluster è in sostanza un aggregato di decine o centinaia (fino a decine di migliaia) di
personal computer connessi con un sistema di rete anch'esso commerciale. Ognuno dei
due approcci ha i propri vantaggi e svantaggi. I super-computer permettono di
massimizzare parametri come l'efficienza computazionale ed il rapporto flops/watt ed
inoltre, disponendo di architettura omogenea, supportano al meglio il calcolo parallelo.
L' ottimizzazione però si paga e l'inconveniente delle soluzioni dedicate è solitamente
un prezzo proibitivo. I cluster computer invece costano relativamente poco rispetto alla
potenza di calcolo fornita e rappresentano soluzioni molto valide in termini di
espandibilità futura e semplicità di gestione. I loro inconvenienti riguardano rese
inferiori sul rapporto flops/watt, ingombro della farm5, sistema di di comunicazione
meno efficiente ed un'inevitabile eterogeneità delle risorse, introdotta ad ogni
ampliamento del sistema.
1.3.5 Limiti del batch computing
Per come i batch system sono stati fin qui descritti, si darebbe per scontato che
dimensioni e potenze di calcolo da questi raggiungibili, dipendano esclusivamente dalla
quantità di risorse economiche a disposizione per la realizzazione. Non è così.
4 Attualmente velocità di trasferimento dell'ordine dei 10 GigaBit / sec. sono già ampiamente fruibili, a
costi molto ragionevoli, col più commerciale tra gli standard di rete locale: Ethernet.
5 In ambito informatico, il termine farm indicava storicamente una serie di server collocati in un ambiente
unico in modo da poterne centralizzare la gestione, la manutenzione e la sicurezza. Col tempo si evoluto
fino a significare una qualunque struttura di calcolo centralizzata, come ad esempio un cluster computer.
Nel prosieguo la dicitura cluster computer ed il termine farm saranno considerati come perfettamente
interscambiabili.
25
L'accrescimento di un sistema di calcolo centralizzato è limitato da una serie di fattori
che vanno ben oltre la semplice spesa per l'acquisto del nuovo hardware. Affinché il
sistema possa funzionare ad esempio, ha bisogno di potenza elettrica6 e la sua crescita
potrebbe coincidere col raggiungimento dei limiti di erogazione della rete elettrica di
zona. La quantità di calore prodotta nell'ambiente che ospita le macchine, richiederebbe
magari nuovi e costosi impianti di condizionamento ed un ulteriore aggravio del
consumo elettrico. Non solo. Gli oneri di amministrazione, programmazione e
manutenzione di un sistema non sono una funzione lineare della sua dimensione ma
crescono drammaticamente al superamento di certe soglie7, finendo per porre un tetto
spesso insormontabile. I costi di esercizio, possono diventare rapidamente ingenti al
crescere delle dimensioni.
Esistono dunque per ogni realtà di calcolo, dei limiti infrastrutturali e costi relativi alle
risorse umane che determinano una dimensione massima, oltre la quale i vantaggi
legati all'utilizzo del sistema non ripagherebbero le accresciute spese di mantenimento.
1.3.6 Superamento dei limiti: il calcolo distribuito
Il crescente bisogno di potenza di calcolo a livello mondiale mal si concilia coi limiti di
cui sopra ed a partire dalla metà degli anni novanta dello scorso secolo, un nuovo
approccio è stato proposto per superare l'ostacolo. La soluzione al problema si basa sul
concetto di calcolo distribuito e consiste nel collegare sistemi di calcolo su scala
geografica o addirittura planetaria, in una rete computazionale fruibile in maniera
trasparente, come si trattasse di un singolo computer. I vari sistemi collegati
costituiscono i singoli nodi della rete che, nel complesso, raggiunge potenze di calcolo
inimmaginabili per una architettura centralizzata. Questa nuovo paradigma è conosciuto
come GRID (griglia computazionale) e conta già numerose implementazioni.
Attualmente, la più importante GRID europea è quella del CERN di Ginevra, progettata
e sviluppata per far fronte alle enormi necessità di storage ed analisi dei dati prodotti
nell'ambito dell'esperimento LHC (Large Hadron Collider)8.
6 Un processore commerciale assorbe una potenza elettrica media di circa 100Watt. Si tenga conto inoltre
che tale potenza verrà dissipata sotto forma di calore e dovrà quindi essere in qualche modo smaltita.
7 Si potrebbe arrivare a situazioni paradossali in cui lo stipendio dei tecnici che amministrano la macchina
superi ampiamente le spese di gestione della stessa.
8 Si stima la produzione annuale di dati per questo esperimento sia prossima ai 10 PetaBytes per anno! La
documentazione riguardo l'esperimento LHC è visionabile presso il sito: http://lhc.web.cern.ch/lhc/ .
26
Capitolo 2
IL CLUSTER INFN DI PERUGIA
2.1 Dalla nascita del cluster all'ingresso in GRID
Fino a non molti anni fa, la sezione INFN di Perugia non disponeva di una struttura di
calcolo unificata. Ogni gruppo di ricerca provvedeva del tutto autonomamente,
all'installazione ed alla gestione di macchine proprie, secondo necessità. Questo
approccio individuale all'approvvigionamento computazionale, non tardò a mostrare i
propri limiti. Periodi in cui i computer di un singolo gruppo erano oberati di lavoro, si
alternavano a fasi di sostanziale inutilizzo, inoltre i costi complessivi di gestione e
manutenzione risultavano moltiplicati per il numero dei sistemi allestiti. La naturale
soluzione al problema, fu raggiunta con l'aggregazione dei vari apparati di calcolo, in un
unico cluster di computer, operante come un batch system. I vantaggi furono da subito
evidenti. La capacità di un sistema grande, permise di ammortizzare i picchi di attività
del singolo gruppo (assegnando le risorse di gruppi in quel momento meno attivi) e la
gestione centralizzata consentì di abbattere i costi per la manutenzione hardware e
software. Inoltre era divenuto possibile per tutti, beneficiare di un'amministrazione
centralizzata e professionale.
27
Ci fu tuttavia un prezzo da pagare: un cluster di computer adibito a funzioni di batch
system, richiede una stessa versione di sistema operativo su tutti i suoi nodi. Questo
comportò (e comporta tuttora) almeno due problemi. I gruppi persero la facoltà di
scegliere il sistema operativo per le macchine messe in compartecipazione e cosa ben
peggiore, il tipo o la versione di sistema operativo adottato, non sempre è eseguibile
sullo hardware più vecchio e non sempre supporta in modo efficiente quello più recente.
Gli svantaggi si sono comunque dimostrati accettabili se paragonati ai benefici della
nuova architettura, ed i problemi di compatibilità hardware/software possono in buona
misura essere risolti, grazie a tecnologie le cui ricadute riguardano anche la
minimizzazione gli effetti dei guasti hardware con gli ovvi benefici riguardo la
continuità dei servizi offerti dal sistema9.
A partire dal 2004, mettendo in compartecipazione parte delle proprie risorse di calcolo,
il cluster INFN si è progressivamente inserito nel contesto delle griglie computazionali
divenendo uno dei siti INFN GRID presenti sul territorio nazionale.
Con i suoi 102 processori10, il batch system INFN di Perugia11 occupa una posizione di
buon livello nel panorama italiano e si è distinto nel recente passato per l'introduzione
di innovazioni tecnologiche, rapidamente recepite in ambito GRID.
Varie sono comunque, le caratteristiche che differenziano questo sito dalle
implementazioni di settore più “ortodosse” e la loro presentazione avverrà nelle pagine
seguenti, successivamente alla descrizione dello hardware di sistema.
9 Le tecnologie in questine fanno riferimento a tecniche di virtualizzazione che presto saranno discusse
all'interno di questo capitolo.
10 Il numero di processori riportato indica un valore medio. Il cluster, come tutti gli apparati di questo tipo, è
una struttura in continua evoluzione per la quale è impossibile stilare una lista definitiva delle risorse. Ad
esempio, un guasto hardware può portare alla disattivazione di uno o più nodi (e dei relativi processori)
per periodi anche molto lunghi. Nodi di prova possono essere aggiunti per un certo lasso di tempo e
quindi rimossi. Altre risorse possono infine essere riservate a funzioni amministrative oppure a test di
sviluppo ed essere anch'esse sottratte al batch system.
11 D'ora in avanti le espressioni “cluster INFN di Perugia” o “batch system INFN di Perugia”, saranno
spesso sostituite con le più brevi diciture “la farm” o “il cluster” senza rischio di ambiguità.
28
2.2 Livello hardware: la struttura del cluster
Come già osservato nel precedente capitolo, le componenti fondamentali di una
architettura di tipo cluster, sono un insieme di computer (nodi) ed una struttura di
rete che li connetta in maniera adeguata. La descrizione della nostra farm, comincerà
dalla seconda delle suddette componenti, per poi passare alla prima ed infine ad una
visione d'insieme delle due.
2.2.1 Architettura della rete
La rete di collegamento dei nodi del cluster, è una LAN12 commutata di tipo Ethernet e
la sua struttura fisica è schematizzata nella seguente Figura 2.1 .
Figura 2.1
Topologia della rete di collegamento del cluster INFN di Perugia
La topologia di collegamento è a stella, a due livelli di ramificazioni. Il primo livello fa
capo ad un “main switch” posto al centro della stella, il secondo dai restanti switch
“interni” che afferiscono al primo. Ogni switch, compreso quello centrale, interconnette
un certo numero di nodi, assegnati secondo criteri che riguardano la ripartizione dei
12 Local Area Network. E' una rete che si estende su scala locale (all'interno di una stanza, di un edificio o al
limite tra edifici molto vicini) e può essere implementata secondo diverse topologie (a dorsale, a stella,
ecc.). Le realizzazioni attualmente diffuse sono basate sullo standard Ethernet e prevedono la
commutazione centralizzata tramite switch, dei segnagli tra le diverse postazioni collegate.
29
carichi di comunicazione, la collocazione fisica delle macchine e le caratteristiche delle
schede di rete di cui questi dispongono.
2.2.2 I nodi
I nodi della rete sono dedicati all'espletazione di compiti specifici13, necessari al
normale funzionamento del batch system ed alla parallela attività di sviluppo.
La precedente Figura 2.1 permette una prima classificazione di questi nodi in due
categorie:
➢ nodi interni
➢ nodi di frontiera
Al primo gruppo appartengono quelle macchine che fanno parte della struttura intima
del batch system e non devono essere direttamente accessibili dagli utenti.
• Worker Node (WN): sono gli “execution node”, ossia i nodi di calcolo del sistema. A
questi nodi spetta l'onere dell'effettiva esecuzione dei job.
• File Server (FS): questi nodi sono responsabili delle funzioni di storage dei dati
all'interno della farm.
La seconda tipologia rappresenta invece la porta d'accesso per gli utenti (o per GRID) ai
servizi erogabili. La caratteristica dei nodi di frontiera è infatti quella di disporre di due
distinte interfacce di rete, collegate rispettivamente sia ad uno degli switch interni sia
allo switch esterno, connesso alla rete dipartimentale. Quelli di frontiera sono gli unici
nodi del cluster visibili dall'esterno. Data la loro funzione di interfaccia, a queste
macchine compete le funzioni di controllo dell'accesso degli utenti e la restrizione
all'erogazione dei servizi della farm. In Figura 2.1 i nodi di frontiera sono idealmente
collocati a cavallo della linea di separazione logica e fisica, tra la rete interna al sistema
e quella esterna. Gli elementi di frontiera sono di seguito riportati.
• Computing Element (CE): è il nodo che nel primo capitolo abbiamo chiamato “central
manager” del batch system e come tale esegue scheduler e resource manager. In questo
contesto è arricchito dalle funzioni di interfaccia verso GRID grazie alle quali è in grado
di accoglierne i job, e schedularli nel sistema come se fossero stati sottomessi
localmente.
13 Alcune delle tipologie di nodo che a breve saranno elencate, sono già state incontrate nel primo capitolo
parlando della struttura hardware generica di un batch system. In questo contesto però, si terrà conto che
il sistema partecipa alla rete GRID ed alcuni nomi saranno rivisti in tal senso, specificando comunque le
corrispondenze con la precedente nomenclatura.
30
• User Interface (UI): sono le uniche macchine a cui gli utenti possono accedere (se
ovviamente su queste possiedono un account). Le UI sono usate in maniera interattiva
per sottomettere job (sia in ambito locale che GRID), oppure per reperire informazioni
sullo stato del sistema, dei job in esecuzione o accodati oppure accedere ai file system
del cluster per il semplice reperimento di informazioni (uso interattivo del cluster). Le
UI sono anche utilizzate come workstation di analisi dati interattiva.
• Storage Element (SE): i nodi con funzione di storage element costituiscono un sistema
di memoria di massa per applicazioni di tipo GRID. Essi possono fisicamente ospitare
supporti di memoria o, più semplicemente, implementare un'interfaccia trasparente
verso i nodi di file system presenti nel cluster. In entrambi i casi un'utenza GRID non
percepisce differenze nel compiere le proprie operazioni di storage.
• Install server (IS): affinché un sistema come quello in esame possa operare in ambito
distribuito (GRID), in piena sintonia col resto della rete, richiede l'installazione sui vari
nodi di un medesimo sistema operativo, ed un set-up standard di alcune componenti
software. Installazione e configurazione manuale sarebbero proibitive considerato il
numero di nodi. L'install server provvede ad un repository centralizzato, costantemente
aggiornato via Internet, a cui i nodi attingono al loro avvio il giusto sistema operativo e
le configurazioni necessarie al loro funzionamento.
Le tipologie fin qui elencate fanno parte del bagaglio usuale di un sito del livello
fabric14 di GRID. La farm INFN si distingue per la presenza di un ulteriore tipo di nodo,
che rappresenta una delle peculiarità della sua architettura logica.
• Dom 0. Sono i nodi adibiti ad ospitare una o più macchine virtuali (Dom U), ognuna
delle quali può implementare una macchina per test amministrativi od una qualsiasi
delle precedenti tipologie di nodo di batch system (WN, CE, ecc.), risorse hardware
permettendo.
L'uso di macchine virtuali comporta una lunga serie di vantaggi relativamente a
fruizione e gestione di un sistema come quello in esame. Tale tecnologia ed i benefici
che apporta, saranno ripresi ed approfonditi nel prosieguo di questo capitolo.
2.2.3 Il cluster fisico in dettaglio
Ora che la struttura base della rete e tutte le tipologie di nodo che essa connette sono
stati presentati, è possibile considerare in maniera complessiva e dettagliata l'impianto
fisico della farm. La seguente Figura 2.2 rappresenta i cablaggi tra switch, e tra nodi e
switch, coi nodi raggruppati per switch di appartenenza.
14 GRID è suddivisa in quattro livelli gerarchici, ad ognuno dei quali corrisponde un diverso livello di
astrazione delle risorse sottostanti e specifiche funzionalità operative ed amministrative. Il livello fabric si
colloca alla base della gerarchia ed rappresenta le risorse hardware dei siti distribuiti sul territorio.
31
Figura 2.2
Schema fisico dettagliato della farm INFN Perugia
32
In figura sono esaltati i collegamenti tra gli switch, al fine di facilitare il riconoscimento
della topologia di rete a stella, il cui centro coincide con “CMS Switch 1000”. Gli altri
switch interni costituiscono invece il secondo livello di ramificazione. “External
Switch” è ovviamente lo “Switch Esterno” già visto in Figura 2.1 ed in esso
confluiscono tutte le linee esterne dei nodi di frontiera del cluster (linee rosse).
La macchine evidenziate dal rettangolo di colore verde chiaro, costituiscono i nodi di
tipo “Dom0 Xen” e sono dedicate all'esecuzione di macchine virtuali15.
I nomi dei nodi che si prestano all'adozione di una nomenclatura significativa16, sono
espressi col seguente formalismo.
• User Interface (UI): [nome_esperimento][gridui][numero]17
• Worker Node (WN): [node][numero_di_nodo]
• File Server (FS): [nome_esperimento][fs][numero]
Per i restanti nodi i nomi sono invece i seguenti.
• Instal Server (IS): gridrep
• Computing Element (CE): [gridce][numero]
• Storage Element (SE): [gridse][numero]
Il numero “100” che accompagna il nome di uno switch indica che il suo standard di
comunicazione è Fast Ethernet (100 Mbit/s), mentre ove non specificato o compare il
valore “1000” lo standard è Gigabit Ethernet (1 Gbit/s).
Tale eterogeneità nelle risorse di comunicazione, conseguenza di ampliamenti
successivi del cluster, si riscontra in misura ancora maggiore considerando i singoli nodi
dal punto di vista dello hardware che li compone.
Le macchine presenti hanno caratteristiche enormemente differenziate in termini di
memoria, velocità, ecc. e sono distribuite lungo un percorso evolutivo che parte da nodi
bi-processore basati su CPU Intel Pentium III 1GHz, fino a nodi ad otto core (2x4) con
processori di ultima generazione.
15 La farm ricorre massicciamente a tecnologie di virtualizzazione, non solo per gli esperimenti di test e di
ricerca ma anche per la realizzazione di numerosi servizi di controllo e gestione.
16 Sono gli insiemi di quei nodi che svolgono la stessa funzione. Ad esempio tutte le interfacce utente, tutti i
nodi di calcolo, ecc.
17 Con nome_esperimento si intende il nome del gruppo degli utenti, che partecipano ad un certo
esperimento nell'ambito INFN. Ad esempio la user interface a cui possono accedere gli utenti
dell'esperimento “glast” è “glastgridui”.
33
2.2.4 Le risorse hardware del cluster in sintesi
Data l'impossibilità di fornire in questa sede in una enumerazione dettagliata delle
risorse hardware presenti nella farm, verrà riportata una semplice tabella riassuntiva
(Tabella 2.1), che comunque da un quadro significativo delle potenzialità del sistema a
livello hardware. In questa rappresentazione, le risorse sono raggruppate ed elencate
per esperimenti (o equivalentemente gruppi di ricerca), mentre l'ultima riga da il totale
delle risorse.
Esperimento Totale
Macchine
File
Server
Spazio
Disco
User
Interface
Nodi Di
Calcolo
Altri
Nodi
Totale CPU
Core
GRID 7 0 1,5 TB 0 2 + 4 5 20
BABAR 3 1 0,75 TB 1 1 0 6
CMS 22 2 6,5 TB 2 13 5 + 4 44
GLAST 11 2 3,5 TB 1 8 0 22
NA48 18 3 5,5 TB 2 13 0 36
Teorici 5 0 0 TB 1 4 0 10
Virgo 7 0 0 TB 1 6 0 14
Altri fondi 1 0 0 TB 0 0 1 2
Risorse totali 74 8 17,75 TB 8 47 + 4 11 + 4 154
Tabella 2.1
Tavola riassuntiva delle risorse hardware del cluster INFN Perugia
La tabella si intende riferita alle sole risorse in produzione e non tiene conto di quelle
impegnate per ricerca e sviluppo. Il formalismo in cui il valore numerico riportato è
seguito da “+ valore” indica che tali risorse “sommate” sono di tipo virtuale.
34
2.3 Peculiarità della farm
Conclusa la carrellata sui dettagli di livello hardware del sistema, e prima di passare alla
descrizione del suo strato software (in particolare del batch system che implementa), è
opportuno soffermarsi su almeno quattro delle peculiarità che distinguono questo sito
dalla maggior parte delle analoghe realizzazioni. Tali singolarità, molto diverse tra loro,
derivano da aspetti che vanno dal possesso dello hardware del cluster ripartito tra più
gruppi, alla ricerca di soluzioni tecniche per aggirare limiti tecnologici o amministrativi.
2.3.1 Risorse hardware e diritti d'uso
La prima delle caratteristiche insolite del nostro batch system ad essere considerata,
riguarda il fatto che il diritto d'uso dello hardware confluito nel cluster, è frazionato tra
più gruppi di ricerca. Questa frammentazione comporta l'impossibilità di una gestione
arbitraria del sistema da parte di chi lo amministra. Ogni gruppo vanta infatti il diritto di
poter decidere dell'uso che verrà fatto delle proprie risorse e lo stesso ingresso del
sistema in GRID è avvenuto “per gruppi” e diluito nel tempo. Le decisioni riguardo
sviluppi e finalità future del sistema debbono essere concertate tra le parti in causa (chi
ha conferito il suo hardware al sistema) e non necessariamente il cammino evolutivo
sarà unico. Questa “proprietà distribuita” delle risorse, si traduce in legittime pretese in
fatto di prestazioni attese dal sistema, da parte di chi apporta le risorse su cui il sistema
si fonda e come vedremo questa caratteristica condiziona la gestione del batch system
fino al livello delle politiche di scheduling.
2.3.2 Una farm ibrida
Solitamente, l'appartenenza di un sito alla GRID computazionale è totale, esclusiva. Il
sito riceve dalla rete i job sottomessi da utenti accreditati presso una virtual
organization18, li esegue e ritorna i risultati. Gli utenti afferenti ad un certo sito possono
magari richiedere l'esecuzione dei loro job sulle proprie macchine ma la sottomissione
avviene sempre via GRID previa autenticazione. Sfortunatamente non tutte le richieste
di calcolo sono immediatamente trasferibili in GRID e, nel caso specifico di INFN
Perugia, non tutti i gruppi di ricerca sono accreditati, pur avendo messo in
18 Le Virtual Organization (VO) sono delle comunità di utenti che concordano con il management della
GRID, le politiche d’uso e di condivisione delle risorse, per accedere all’infrastruttura di produzione.
35
compartecipazione le loro risorse di calcolo al cluster. La soluzione al problema è
consistita nel permettere un utilizzo duale della farm, sia come sito INFN GRID, sia
come un normale batch system con accesso locale, senza bisogno di autenticazione in
GRID. L'obbiettivo è stato raggiunto modificando la configurazione dello scheduler in
modo che questo accettasse job dalle User Interface locali oltre che dal Computing
Element (via GRID). Una rappresentazione logica di questa architettura è riportata in
Figura 2.3 .
Figura 2.3
Schema logico dell'accesso duale alla farm INFN Perugia
La figura enfatizza per quattro dei cinque gruppi riportati, l'insieme delle risorse
hardware possedute e la doppia interfaccia di accesso lato GRID e lato utente. Si noti
che il gruppo “GRID” (evidenziato in giallo), non prevede una User Interface per la
sottomissione di job da locale. Tale insieme di risorse sono infatti assegnate da INFN
per essere utilizzate da tutta la GRID nazionale e conseguentemente non necessitano
dell'accesso duale preteso dagli altri gruppi. Comunque, in accordo allo spirito di
condivisione che caratterizza il funzionamento del cluster, tale insieme di risorse è
all'abbisogna fruibile anche dagli utenti locali.
36
Ogni gruppo decide autonomamente, il rapporto tra le risorse dedicate alla griglia
computazionale e quelle mantenute per uso locale, in base alle necessità e alle proprie
tipologie di calcolo.
Uno degli effetti dell'architettura ibrida, è quello di determinare un job flow “doppio”
come quello riportato in Figura 2.4 .
WN
WN
WN
WN
WN
WorkerNodes
GRID
Computing Element
(Batch system)
User Interface
(login)
File Server File Server File Server
Storage Element
(Disk Server)
Figura 2.4
Job-flow della farm ibrida INFN Perugia. Sottomissione di un job localmente e via GRID.
L'esempio riportato in figura mostra come un utente della farm, possa disporre di un un
doppio accesso al batch system. Le frecce bianche mostrano il percorso di un job
sottomesso localmente, dalla UI al CE, mentre quelle gialle sono relative alla
sottomissione via GRID con richiesta di esecuzione sul sito INFN GRID di Perugia.
Come si vede i protagonisti della gestione dei job, all'interno della farm, sono diversi a
seconda della sua provenienza. Le frecce relative alla riconsegna del risultato della
computazione del job sono state omesse per garantire una migliore leggibilità
dell'immagine.
2.3.3 WN su rete nascosta
La terza peculiarità della farm riguarda la sua parte GRID, ha una connotazione
squisitamente tecnica ed una rilevanza storica. L'installazione di un sito INFNGrid
prevedeva fino alla versione 2.3.0, che tutte le macchine interessate, disponessero di un
indirizzo IP pubblico. La richiesta mal si conciliava con la carenza di indirizzi che
37
affligge tuttora la sezione INFN di Perugia. Una soluzione originale è stata trovata,
apportando una modifica allo strato middleware di GRID, per permettere la
collocazione di alcuni nodi su rete nascosta (privata). I candidati perfetti per il passaggio
su tale rete sono ovviamente i Worker Node, data la loro caratteristica di non dover
essere direttamente raggiungibili dall'esterno19.
L'esito favorevole dei test di funzionamento ed il notevole risparmio di indirizzi
pubblici ottenuto, hanno ben presto richiamato l'interesse della comunità di sviluppo del
middleware INFN GRID che ha provveduto a fare di questa soluzione uno standard a
partire dalla distribuzione 2.6.0 .
2.3.4 Macchine Virtuali
L'ultima delle caratteristiche distintive della farm ad essere considerate, riguarda l'uso di
una tecnologia conosciuta da tempo ma ancora non diffusa nell'ambito dei batch system,
quella legata alle macchine virtuali. In informatica per virtualizzazione si intende
l'astrazione di un dispositivo fisico per mezzo di un software detto hypervisor20. Nel
caso specifico questa astrazione è volta alla creazione in una macchina fisica (host), di
diversi ambienti di esecuzione, in grado ognuno di ospitare un proprio sistema operativo
(guest). Queste macchine virtuali, vengono percepite da un utilizzatore come macchine
fisiche vere e proprie. Il tipo di tecnologia utilizzata risponde al nome di Xen21 ed è un
esempi di para-virtualizzazione22 caratterizzato da basso costo di overhead e riduzioni di
prestazioni minime. Lo hypervisor di Xen genera all'avvio del sistema una virtual
machine “0” (o dom-0) che è l'unica ad interagire con lo hardware. Essa è il supporto a
tutte le altre macchine virtuali (dom-U23), delle quali procede alla generazione, alla
soppressione od alla migrazione verso altri dom-0.
19 La tecnica si basa sul ricorso ad un server DNS (Domain Name Server) collocato sulla rete interna del
sistema, per la traduzione dei nomi simbolici dei nodi, in indirizzi fisici. Tale DNS è lo stesso per i
worker node e le macchine con due interfacce di rete.
20 Altrimenti detto Virtual Machine Monitor.
21 Xen è un hypervisor, sviluppato come Software Libero dall'Università di Cambridge
22 Le tecniche di virtualizzazione sono molteplici ed ognuna risponde a esigenze o persegue obbiettivi
diversi. La para-virtualizzazione non simula completamente lo hardware del sistema “host” ma offre
un'interfaccia astratta di esso ai sistemi operativi “guest” che quindi necessitano di essere modificati in
accordo allo hypervisor.
23 Domain Unprivileged (dominio non privilegiato). Le macchine virtuali supportate da dom-0 infatti, non
hanno accesso diretto alla macchina fisica e sottostanno totalmente, alla gestione che dom-0 fa di esse.
38
I vantaggi legati all'uso di macchine virtuali sono innumerevoli, di seguito si riportano i
principali.
• Diversi sistemi operativi possono essere eseguiti in contemporanea su una singola
macchina.
• Possibilità di eseguire su macchina virtuale sistemi operativi per i quali la macchina
fisica non consenta l'esecuzione direttamente24.
• Le macchine possono essere clonate per eseguire operazioni di test o aggiornamenti,
preservando così l'integrità della macchina originale.
• Le macchine possono essere stoppate e riavviate tutte le volte che serve, senza perdita
di informazioni o problemi al flusso di esecuzione dei processi che sulla macchina sono
in corso. Ciò rende possibile due tipologie operative notevoli.
➢ load balancing: migrare macchine verso nodi con basso carico di lavoro per
bilanciare le prestazioni del sistema.
➢ alta disponibilità: migrare le macchine alle prime avvisaglie di
malfunzionamento della macchina fisica che le ospita, evitando possibili (e
solitamente prolungate) interruzioni dei servizi.
• Le virtual machine possono essere isolate dal resto del sistema per garantire la sicurezza
rispetto ad interferenze esterne od il confinamento delle attività interne.
24 Questa possibilità rappresenta una soluzione spesso valida, al problema di dover eseguire un dato sistema
operativo su un'architettura che non lo supporti adeguatamente. Come si ricorderà questo è ad esempio il
caso del cluster INFN di Perugia, dove la necessità di un sistema operativo unico, mal si concilia con
l'architettura di determinati nodi. Si tenga comunque conto che questa tecnica non rappresenta una
panacea ai problemi di incompatibilità: non tutti i sistemi operativi sono virtualizzabili con Xen ma
soltanto quelli che supportano un'interfaccia verso esso.
39
2.4 Livello software: il batch system
Alcune delle caratteristiche riguardanti la modalità di funzionamento al livello batch del
cluster INFN sono già emerse nel precedente paragrafo, parlando delle peculiarità di
questo sistema. I rimanenti aspetti di questo strato logico, verranno discussi nelle
pagine seguenti, considerando il tipo di utenza del sistema, le modalità di accesso allo
stesso, il batch system in uso e la sua configurazione.
2.4.1 Gruppi, utenti e quote computazionali
Attualmente nell'ambito INFN di Perugia operano i seguenti gruppi, con diritto di
accesso al batch system:
° CMS °NA48 °GLAST ° VIRGO °THEOPHISYS
Ogni gruppo vanta un credito nei confronti della potenza computazionale del cluster
pari alla potenza di calcolo riconducibile alle risorse apportate. Questo credito può
essere formalizzato nel concetto di quota computazionale, espresso dalla seguente
frazione:
quota computaz. gruppo = potenza apportata / potenza complessiva sistema
dove ovviamente la “potenza” è quella computazionale. Ad ogni gruppo spetta quindi
una quota computazionale ma il concetto può essere esteso anche agli utenti che ad esso
appartengono:
quota computaz. utente = frazione della quota computazionale del gruppo
accordata dal coordinatore del gruppo all'utente
I criteri di frammentazione delle quote computazionali di un gruppo tra i suoi utenti
rispecchiano logiche interne, e possono magari essere correlate all'importanza attribuita
all'attività di ricerca della persona o ad altri aspetti contingenti.
Il concetto di quota computazionale di gruppi ed utenti, è stato introdotto per
formalizzare la particolare situazione riguardo i diritti di fruizione del cluster INFN di
Perugia. Esso sarà incontrato nuovamente nell'ultimo paragrafo di questo capitolo
all'atto della formulazione del criterio di ottimizzazione del batch system in questione.
40
2.4.2 Tipologia dei job
Anche se il supporto a job che richiedano più processori (job paralleli MPI) è
tecnicamente disponibile, esso non è praticamente utilizzabile a causa della eterogeneità
delle risorse. Pressoché la totalità dei job sottoposti al sistema richiede quindi un solo
processore.
Pur data questa semplificazione, i job che pervengono sia dall'utenza locale che da
GRID presentano l'inconveniente di caratteristiche molto diversificate. Per quello che
riguarda la scala temporale, la durata dei job va da meno di un secondo (job di
certificazione provenienti da GRID) a giorni se non addirittura settimane di esecuzione,
mentre la tipologia di calcolo richiesta, varia con continuità tra attività I/O intensive e
CPU intensive.
2.4.3 Accesso e sicurezza
Ferma restando la possibilità di poter usufruire dei servizi della farm solo se si è utenti
accreditati (si disponga cioè di un account su una delle User Interface o di un certificato
x.509 valido per l'accesso via GRID), il logging al sistema deve avvenire in una
modalità il più possibile sicura e lo stesso vale per i trasferimenti delle informazioni
(spesso sensibili) da e verso la farm e all'interno della farm stessa. Per venire incontro a
queste due esigenze, il sistema supporta uno dei protocolli di comunicazione cifrata più
diffusi e sicuri, disponibili al momento: SSH.
• SSH (Secure SHell, shell sicura) è un protocollo che permette di stabilire una
sessione remota cifrata con un host25 della rete. Il client SSH ha una interfaccia
a linea di comando simile a quella di telnet e rlogin, ma l'intera comunicazione
(ovvero sia l'autenticazione che la sessione di lavoro) avviene in maniera
cifrata. Per questo motivo, SSH è diventato uno standard di fatto per
l'amministrazione remota di sistemi unix e di dispositivi di rete, rendendo
obsoleto il protocollo telnet, giudicato inaffidabile per la sua mancanza di
protezione contro le intercettazioni.
• SCP (Secure CoPy, copia sicura) è un'utilità per il trasferimento sicuro di file
fra host di una rete. La sicurezza deriva dal fatto che SCP si basa sul protocollo
SSH e quindi ogni sessione di trasferimento dei dati beneficia degli stessi
meccanismi di autentifica e degli stessi efficaci algoritmi di cifratura.
25 Una qualsiasi macchina collegata il rete, a cui è associato almeno un indirizzo IP.
41
2.4.4 Il batch system in uso
L'attuale panorama in fatto di programmi per l'implementazione e la gestione di un
batch system, comprende un insieme di prodotti piuttosto vasto. Alcune soluzioni
prevedono scheduler e resource manager integrati in un pacchetto unico, altre invece
consentono l'abbinamento di due programmi distinti. Certi software vengono sviluppati
secondo la filosofia Open Source / free software, altri sono invece a pagamento. Più
numerose e sostanziali le differenze di approccio al problema dello scheduling. Ogni
pacchetto ha insomma delle peculiarità che assieme a pregi e difetti, andrebbero
considerate in funzione del sistema che si intenda allestire. Le più diffuse soluzioni
commerciali (e non) per implementare un batch system sono riportate di seguito.
➢ Famiglia PBS
• OpenPBS
• TORQUE + Maui
• TORQUE + Moab
• PBS PRO
➢ LSF
➢ Condor
➢ BQS
L'appartenenza del cluster INFN alla rete INFN GRID, pone però dei vincoli alla scelta
tra candidati nella precedente lista. Il middleware di GRID è finora in grado di
interfacciarsi, con due soltanto delle soluzioni elencate: LSF e TORQUE + Maui. Il
primo programma implementa un sistema organico e ricco di funzioni ma è a
pagamento, l'accoppiata successiva appartiene invece ad un progetto open source ed è
gratuita sebbene più spartana. Il sito INFN GRID di Perugia è attualmente un sistema
basato su TORQUE + Maui26.
2.4.5 Configurazione di TORQUE
Nella configurazione attuale tutte le code permettono l'accesso a qualsiasi worker node.
Per ogni gruppo locale sono state create quattro code (short, medium, long, infinite),
riservate alla sottomissione selettiva dei job in base alla stima della loro durata di
esecuzione. Per ogni gruppo inoltre è presente una coda, chiamata con lo stesso nome,
per la sottomissione di job via GRID.
26 La descrizione delle principali caratteristiche di questo batch system sarà oggetto del capitolo 3.
42
Le restanti code riguardano sottomissione di job amministrativi o job di test o
certificazione via GRID. La lista completa di code e relativi walltime è riportata di
seguito, in Tabella 2.1.
Nome coda Walltime Nome coda Walltime Nome coda Walltime
cms-short 02:00:00 na48-short 02:00:00 babar-short 02:00:00
cms-medium 24:00:00 na48-medium 24:00:00 babar-medium 24:00:00
cms-long 52:00:00 na48-long 52:00:00 babar- long 52:00:00
cms-infinite 780:00:00 na48-infinite 780:00:00 babar-infinite 780:00:00
virgo-short 02:00:00 glast-short 02:00:00 theo-short 02:00:00
virgo-medium 24:00:00 glast-medium 24:00:00 theo-medium 24:00:00
virgo-long 52:00:00 glast-long 52:00:00 theo-long 52:00:00
virgo-infinite 780:00:00 glast-infinite 780:00:00 theo-infinite 780:00:00
test 24:00:00
na48 120:00:00 Code locali
babar 72:00:00
virgo 120:00:00 grid 72:00:00 Code GRID
cms 120:00:00 cert 72:00:00 theophys 72:00:00
Tabella 2.1
Code del batch system del sito INFN GRID di Perugia.
2.4.6 Configurazione di Maui
La configurazione dello scheduler della farm di produzione, si è evoluta nel corso degli
anni fino a raggiungere un numeroso ed articolato insieme di policy. Vista
l'inadeguatezza di questa sede ad un'analisi capillare di tale configurazione, si riportano
le sole tipologie delle politiche di scheduling impostate.
• Partizionamento delle risorse. Le risorse di calcolo sono partizionate in base ai gruppi
che afferiscono ed allocate preferenzialmente ad utenti del gruppo di appartenenza.
• Priorità per code. Le varie code hanno associato un peso di priorità tanto maggiore
quanto più breve è la durata dei job che su di esse possono essere sottomessi.
• Limiti statici. Sono applicati limiti statici di allocazione, di tipo soft e hard ad utenti,
gruppi e code.
43
2.5 Formulazione del problema
La precedente descrizione della farm, avrà già fatto riflettere il lettore, sulla
straordinaria complessità che caratterizza il problema di una “buona gestione” di tale
batch system. La varietà dello hardware, i numerosi gruppi di utenza, la gestione ibrida
di job locali e via GRID, la variegatura delle tipologie dei job, le numerose code e mille
altri aspetti, fanno dell'attuale configurazione operativa un espediente per la
sopravvivenza più che una politica di scheduling ottimizzata.
La molteplicità di fattori da considerare, trasmette un senso di vertigine all'idea di un
approccio “quantitativo”, alla soluzione del problema dell'ottimizzazione. La
definizione stessa delle metriche da ottimizzare, è un problema complesso.
Come spesso accade in questi casi, l'osservazione del fenomeno ed il buon senso,
permettono di discernere alcune caratteristiche macroscopiche, sulle quali risulterà più
facile il ragionamento, e dalla armonizzazione delle quali è lecito attendersi un
miglioramento tangibile della resa del sistema. Queste linee guida possono individuarsi
nelle esigenze di fruizione del batch system in questione, da parte delle tre figure che
attorno ad esso gravitano:
➢ l'amministratore dello scheduler
➢ i gruppi di ricerca
➢ gli utenti afferenti ai gruppi
Le esigenze di queste tre entità non sono tra loro indipendenti e risultano inquadrabili in
una gerarchia di tre livelli, corrispondente al precedente ordine di elencazione. Partendo
dal livello degli utenti e salendo, si incontreranno esigenze di qualità del servizio via via
più generali e la necessità di armonizzare le esigenze dei livelli sottostanti.
Livello degli utenti
Ogni utente percepisce solamente due cose: se stesso ed il sistema come erogatore di
servizi. Le sue necessità sono dettate da una sorta di “egoismo computazionale” e sono
le seguenti.
1. All'occorrenza tutte le risorse del batch system che corrispondono alla propria quota
computazionale devono poter essere dedicate all'esecuzione dei propri job.
2. All'occorrenza deve essere possibile usufruire di tutte le risorse del sistema che al
momento siano inutilizzate, per poter eseguire i propri job.
44
Livello dei gruppi di ricerca
La visione che il gruppo ha nei riguardi del batch system è più ampia che nel caso
precedente. Il gruppo percepisce se stesso, ogni utente che ad esso afferisce ed
ovviamente il sistema. Le sue esigenze rispecchiano ancora logiche “egoistiche” ma in
più compare una quasi “paterna” vocazione all'equità di trattamento, per tutti gli utenti
che ad esso fanno capo.
1. All'occorrenza tutte le risorse corrispondenti alla propria quota computazionale di
gruppo, devono poter essere dedicate all'esecuzione dei propri job
2. All'occorrenza deve essere possibile usufruire di tutte le risorse del sistema che al
momento siano inutilizzate, per poter eseguire i propri job.
3. Lo spazio computazionale concesso ad uno qualsiasi dei suoi utenti, non deve essere
tale da privare delle risorse (o comunque penalizzare) gli altri utenti del gruppo se al
momento necessitino della loro quota computazionale.
Livello dell'amministratore dello scheduler
L'amministratore, gode della visione più ampia possibile relativamente al batch system
ed i sui fruitori. Esso percepisce il sistema come insieme delle risorse e delle relative
politiche di allocazione, percepisce ovviamente se stesso ed il proprio ruolo di gestore
“altruista”, infine i gruppi con le loro necessità. Le sue esigenze sono le seguenti.
1. Bilanciamento dell'attività dei gruppi
2. Massimizzazione dell'utilizzo delle risorse del sistema
L'insieme di queste esigenze conflittuali e la ricerca di un bilanciamento complessivo,
rappresenta una formulazione comprensibile del problema di ottimizzazione del sistema.
La ricerca di una soluzione non può prescindere dalla conoscenza delle le caratteristiche
del batch system in uso ed in questo caso, esso è TORQUE + Maui.
45
46
Capitolo 3
TORQUE + Maui
3.1 TORQUE
TORQUE (Terascale Open-Source Resource and QUEue Manager) è un resource
manager open source, sviluppato da Cluster Resources Inc.27, sulla base della versione
2.3.12 dello scheduler OpenPBS28.
TORQUE si distingue dal suo progenitore per i miglioramenti apportati da oltre 1200
patch, messe a punto nel corso degli anni, da importanti enti governativi e comunità di
sviluppo29 che si sono avvalsi di questo programma. Come ogni resource manager,
TORQUE implementa tutte le funzioni necessarie alla manipolazione ed esecuzione di
job in un sistema batch, comprese le utilità per reperire informazioni sullo stato del
sistema e quelle relative all'esecuzione dei job stessi.
27 Cluster Resources, Inc. è un'azienda fondata nel 1996 da David Jackson, specializzata nello sviluppo di
software di gestione ed amministrazione di batch system. Le informazioni riguardo ai prodotti ed alle
attività di Cluster Resources possono essere reperite all'indirizzo: http://www.clusterresources.com/ .
28 OpenPBS (Open Portable Batch System) è un batch system basato sulla gestione di code di job,
sviluppato dalla N.A.S.A (National Aeronautic and Space Administration) nella prima metà degli anni '90
dello scorso secolo.
29 NCSA (National Center of Supercomputing Application); OSC (Ohio Supercomputer Center) ; U.S. Dept
of Energy; PNNL (Pacific Northwest National Laboratory); University of Buffalo; Sandia Labs; TeraGrid
project.
47
3.1.1 Architettura e “demoni”
Affinché il resource manager abbia pieno accesso alle risorse del sistema che
amministra, è abbastanza evidente che il suo programma debba in qualche modo essere
“distribuito” nel sistema stesso. TORQUE è costantemente in esecuzione come
demone30 su tutti i nodi nodi di calcolo e sul nodo central manager del sistema. Il
demone è però diverso a seconda della tipologia di nodo: nel caso degli execution node
esso è detto pbs_mom mentre sul nodo centrale gira il pbs_server.
Il primo dei due è specializzato nella gestione della macchina che lo ospita. Tra i suoi
compiti rientrano il monitoraggio delle risorse hardware, l'allocazione delle stesse per
l'esecuzione del (o dei) job, la raccolta di informazioni sullo stato del nodo e l'attuazione
di tutti i meccanismi necessari a sorvegliare, interrompere o alimentare l'esecuzione di
un job, fino al completamento ed alla riconsegna dei risultati del calcolo. Ogni
pbs_mom comunica esclusivamente col pbs_server ed ogni azione che intraprende al di
fuori del suo ciclo di funzionamento è conseguenza di un esplicito comando esterno. La
comunicazione è bidirezionale: quando è diretta in ingresso al “mom” riguarda ordini o
interrogazioni provenienti dal “server”, quando è in uscita riguarda risposte (rapporti di
stato) o risultati di computazioni, da consegnare al relativo committente.
Il funzionamento di pbs_server è più articolato e principalmente consiste nel
coordinamento a basso livello di tutto il batch system, tramite l'interazione coi vari
“mom”. Questa attività varia dall'esecuzione di funzioni di feedback all'attuazione dei
comandi che provengono al demone dagli utenti o dallo scheduler31. Pbs_server è inoltre
il detentore e l'amministratore di tutte le strutture dati che permettono la gestione dei job
(ad es. le code) o contengono le informazioni sullo stato del corrente del sistema.
TORQUE non prevede un vero e proprio programma client per l'interazione degli utenti
col pbs_server ma piuttosto una collezione di script realizzanti una serie di comandi, che
vanno dalla sottomissione del job al monitoraggio della sua esecuzione. Questi script
possono essere lanciati da una qualsiasi delle macchine ma solitamente ciò avviene da
quella riservata alla funzione di User Interface.
30 Un demone è un programma con funzioni di server, la cui esecuzione avviene in background.
31 La distribuzione che accompagna TORQUE prevede uno scheduler FIFO integrato ma per ovvi motivi di
prestazioni, esso è solitamente usato per i soli test di configurazione. Durante il funzionamento di
produzione TORQUE è invece abbinato a scheduler evoluti come ad esempio Maui.
48
3.1.2 Ciclo di funzionamento di pbs_server
L'essenza di pbs_server è, in accordo alla definizione di resource manager, quella di
mero esecutore di comandi esterni32 (sottomissioni di job, ordini dello scheduler, ecc.) e
la sua attività consiste nella iterazione delle tre sole fasi visibili in Figura 3.1.
pbs_server
pbs_mom
pbs_mom
pbs_mom
pbs_mom
Nodi diesecuzione
Nodointerfaccia
utentiNodo Central Manager
2. EseguiComandi
1. AcquisisciComandi
3. Rispondi
Utente X
Utente Z
Utente A
Comandi Risposte Ciclo di esecuzione
Sche
dule
r
Figura 3.1
Ciclo di funzionamento del pbs_server di TORQUE
1. Ascolto. Ad ogni avvio del proprio ciclo di esecuzione, pbs_server verifica se sono
pervenuti comandi dagli utenti o dallo scheduler.
2. Esecuzione. Se trova comandi e li riconosce come validi, provvede alla loro
esecuzione. In particolare se queste direttive riguardano un'azione da compiere sul
sistema, pbs_server traduce i comandi in istruzioni elementari per i “mom”, li trasmette
agli opportuni destinatari ed attende l'eventuale risposta. Se il comando eseguito non
prevede il ritorno di una risposta si torna alla fase 1.
3. Risposta. Se il comando eseguito produce un qualche contenuto informativo che debba
tornare indietro, pbs_server provvede a recapitarlo al giusto destinatario, quindi torna
alla fase 1.
32 E' sottinteso che il resource manager debba comunque eseguire tutte le funzioni necessarie al proprio
sostentamento.
49
Sempre riferendosi alla Figura 3.1, il flusso dei comandi è rappresentato dalle frecce
rosse mentre quello delle eventuali risposte dalle frecce bianche. Si noti che a volte lo
scheduler può fungere da interfaccia tra i comandi utente e demone, recependoli ed
inoltrandoli al suo posto. Un discorso analogo vale per le risposte.
3.1.3 Scalabilità
TORQUE si distingue per le proprie doti di scalabilità, dimostrando un'ottima
integrazione sia coi sistemi di piccole e medie dimensioni che con i grandi. I limiti di
gestione dichiarati per questo software sono i seguenti:
• supporto di sistemi fino a 2.500 processori e portate di calcolo prossime a 15 TeraFlops;
• supporto di job paralleli MPI che richiedano fino a 2.000 processori.
Nel caso di sistemi in cui il numero dei processori sia tale da eccedere la precedente
soglia, si può procedere ad una “moltiplicazione” di TORQUE. Più copie di pbs_server
possono essere tenute in esecuzione, amministrando ognuna un diverso sottoinsieme di
pbs_mom. I diversi resource manager continuerebbero comunque ad interagire con un
unico scheduler, data la natura centralizzata di questo tipo di attività.
50
3.2 Maui
Maui è uno job scheduler open source multi-piattaforma33 per cluster e super-computer.
Nato con il semplice scopo di massimizzare l'utilizzazione di un batch system, si è
rapidamente evoluto in un articolato insieme di strumenti di scheduling avanzato, basato
su esecuzione prioritaria dei job, ripartizione “equa” delle risorse di calcolo tra gli
utenti, classi di Quality of Service (QoS) e meccanismi di ottimizzazione dell'attività del
batch system. I primi sistemi ad eseguire questo scheduler erano tutti basati su
architetture di tipo supercomputer ma il progressivo affermarsi dei cluster HPC34 ha
visto Maui adattarsi ad esse perfettamente, al punto che attualmente sono centinaia in
tutto il mondo i cluster batch system che lo utilizzano. Le prestazioni dichiarate per
Maui dai suoi sviluppatori35, garantiscono la capacità di supportare 4,000 job simultanei,
2000 nodi di calcolo e fino ad un massimo di 500,000 processori. La realtà ha
dimostrato validità ben più ampie, visto che attualmente Maui è in esecuzione in sistemi
da 4000 nodi, e riesce a gestire con successo fino a 20.000 job accodati
simultaneamente.
Nel prosieguo saranno considerate le principali caratteristiche riguardanti il
funzionamento di questo scheduler e le politiche che esso è in grado di attuare36.
3.2.1 Interazione col resource manager
Come tutti gli scheduler Maui non è in grado di gestire direttamente i job o reperire
informazioni dal sistema ma deve servirsi di un programma specializzato: un resource
manager. Maui può interfacciarsi con software come: PBS , LoadLeveler, SGE, BProc,
SSS XML e naturalmente TORQUE. L'interazione col resource manager avviene
tramite scambio di messaggi secondo un protocollo stabilito, su porte stabilite ed in
maniera del tutto trasparente. Chi fruisce il sistema percepisce lo scheduler ed il suo
33 Attualmente Maui supporta i seguenti sistemi operativi: Linux, AIX, OSF/Tru-64, Solaris, HP-UX, IRIX,
FreeBSD.
34 HPC (High Performance Computing)
35 Maui è prodotto e sviluppato da Cluster Resources, Inc. (http://www.clusterresources.com).
36 Per una trattazione esaustiva delle numerose funzioni implementate da questo scheduler e la miriade di
parametri di configurazione ad esse relative, si rinvia il lettore alla consultazione della Maui
Administarator's guide, disponibile assieme ad ulteriore documentazione tecnica all'indirizzo:
http://www.clusterresources.com/pages/resources/documentation.php
51
“factotum”, come un'unica entità logica e può sottomettere job e comandare operazioni,
senza curarsi dei meccanismi di interazione tra i due.
3.2.2 Scheduling, policy & fairness
Maui espleta il proprio compito di scheduler, attuando delle policy stabilite
dall'amministratore del sistema, in funzione del tipo di scheduling desiderato. Una
policy può essere considerata come una regola, una restrizione o un criterio di
valutazione, che Maui applica nei confronti dei job o del suo stesso funzionamento. Il
numero delle tipologie di policy possibili è piuttosto ampio ed eventuali loro
combinazioni, permettono schemi di scheduling particolarmente accurati e raffinati.
L'insieme di tutte le policy decise dall'amministratore dello scheduler, è specificato
secondo un'opportuna sintassi, nel file maui.cfg, assieme agli altri parametri che
determinano la configurazione operativa dello scheduler.
3.2.3 Priorità di esecuzione
Tra i meccanismi che in Maui concorrono a determinare l' ordine di scheduling, quello
basato sulla priorità di esecuzione dei job, gioca il ruolo di maggiore importanza.
Secondo esso, ad ogni job viene associato un valore numerico che ne esprime, in
termini assoluti, la priorità di esecuzione maturata. Partendo da questo indicatore, Maui
compila ciclicamente una lista di job eleggibili37, ordinata per priorità decrescente. I job
sono mandati in esecuzione, semplicemente scandendo la lista a partire dalla prima
posizione, finché vi siano risorse di calcolo disponibili all'assegnazione. Ovviamente a
intervalli di tempo determinati, lo scheduler provvede all'aggiornamento delle priorità
accordate ai job. Il calcolo avviene secondo meccanismi, descritti in seguito, valutando
sia caratteristiche immutabili del job (come ad esempio il numero di processori richiesti)
sia caratteristiche variabili in funzione del tempo o dello stato del sistema (come il
tempo che il job ha trascorso in coda fino ad allora). L' assegnazione di un valore di
priorità, non è comunque una caratteristica dei soli job in coda ma anche di quelli in
esecuzione. Durante questa fase infatti, la priorità dei job continua ad essere aggiornata
sulla base delle statistiche relative alla loro stessa computazione e può essere
considerata da Maui, per prendere decisioni su quali job favorire (o penalizzare) a
seconda dell'andamento del sistema.
37 Un job in stato di attesa è detto “eleggibile” quando esso è pronto a ricevere dal sistema le risorse di
calcolo e passare in stato di esecuzione.
52
3.2.3.1 Gerarchie di componenti
Le caratteristiche dei job valutate da Maui per il calcolo della priorità (credenziali,
risorse richieste, vincoli di policy, ecc.), rappresentano un insieme di valori numeroso ed
eterogeneo. Una loro manipolazione diretta comporterebbe una certa complessità anche
per la realizzare delle politiche di scheduling più semplici. La soluzione al problema
consiste nell'organizzare tali caratteristiche, che d'ora in avanti chiameremo sub-
componenti (o attributi) del job, in una gerarchia a tre livelli, secondo lo schema
riportato in Figura 3.2:
Valorenumericosub-comp.
Componente 1 Componente 2
Sub-Comp1 A
Sub-Comp1 B
Sub-Comp1 X
Valorenumericosub-comp.
Sub-Comp2 A
Valorenumericosub-comp.
Valorenumericosub-comp.
Peso associato alla componente o alla sub-componente
Livello delle Sub-Componenti (attributi del job)
Livello dei valori delle
Sub-Componenti
Livello delle Componenti
Figura 3.2
I tre livelli gerarchici delle caratteristiche di un job ed i pesi delle componenti e delle sub-componenenti.
Livello delle componenti
E' il livello più in alto nella gerarchia ed è costituito da 6 categorie generali, o
famiglie di attributi, raggruppati secondo criteri di affinità. Ad ogni famiglia,
detta anche componente, sono associati due valori interi chiamati limite e peso,
che esprimono rispettivamente il massimo valore di priorità che si consente di
raggiungere alla componente e l' importanza della componente relativamente
alle altre. Il peso deciso per una famiglia di attributi, vale allo stesso modo per
tutti i job.
53
Livello delle sub-componenti
Rappresenta i singoli attributi (sub-componenti) che formano le componenti.
Ad ogni sub-componente è associato un peso che esprime la sua importanza
rispetto alle altre della famiglia di appartenenza. Come sopra, il peso deciso per
un attributo vale per tutti i job.
Livello dei “valori” delle sub-componenti
Di questo livello fanno parte i valori di priorità veri e propri che competono ad
ogni sub-componente del job. A seconda del tipo di attributo, questi valori sono
assegnati:
• Dall'amministratore dello scheduler per dare priorità specifica (ad es.
assegnare priorità 100 all'utente di nome Marco).
• Dallo scheduler stesso per tenere traccia di grandezze mutabili come
statistiche di funzionamento, valori temporali, ecc. (ad es. la permanenza in
coda del job per 4.500 secondi).
• Dallo scheduler in base alla specifica delle richieste accompagnanti il job
all'atto della sottomissione al resource manager (ad es. la richiesta di 8
processori e 2048 MByte di RAM).
I valori che l' amministratore dello scheduler può scegliere per i pesi ed i limiti, devono
per convenzione essere espressi da numeri interi non negativi, mentre i valori di priorità
possono essere interi qualsiasi, anche negativi.
54
3.2.3.2 Calcolo della priorità di un job
Data la precedente impostazione, il criterio di calcolo della priorità di un job risulta
piuttosto semplice e viene definito a partire dal basso, ossia dalle sub-componenti. Per
ogni sub-componente del job si definisce il concetto priorità pesata come il seguente
prodotto:
PrioPesata= pesoSubComp∗prioritàSubComp
I fattori che compaiono nella moltiplicazione sono, come la rappresentazione
suggerisce, il peso accordato alla sub-componente ed il valore numerico della stessa. Si
definisce inoltre priorità di una componente, la somma delle priorità pesate delle sue
sub-componenti quando questa è minore del limite di massima priorità consentita,
oppure il valore del limite stesso , secondo la formula:
PrioComp=min LIMITE ,∑j=1
n
pesoSubComp j∗prioritàSubComp j
dove n è il numero degli attributi della componente e LIMITE rappresenta la massima
priorità che si concede di assumere alla componente.
La priorità del job è quindi definita come somma delle priorità delle 6 componenti,
moltiplicate ognuna per il rispettivo peso. La seguente formula riassume e completa le
precedenti.
PrioJob=∑i=1
6
pesoCompi∗min LIMITE i ,∑j=1
ni
pesoSubComp j∗prioritàSubComp j
In Maui la massima priorità raggiungibile da un job è stabilita da un parametro, il cui
valore di default è 1,000,000,000 (un miliardo). Allo stesso modo si stabilisce che la
priorità minima non possa scendere al disotto del valore 0 (zero). Qualora la priorità
calcolata per un job oltrepassi uno di questi limiti, essa viene automaticamente assunta
uguale al valore del limite stesso.
Il criterio di calcolo sopra descritto, introduce una grande semplificazione riguardo la
definizione delle policy di scheduling in base alla priorità. Ogni policy infatti consiste
nella semplice assegnazione di un peso, un valore od un limite di priorità, alla giusta
componente o sub-componente del job.
55
Qualora fosse necessario, l' amministratore dello scheduler può operare aggiustamenti
manuali della priorità calcolata per un dato job, incrementandola o decrementandola di
un valore arbitrario od impostare per essa valore “ex novo”, del tutto indipendente da
quello calcolato. Contrariamente all'attribuzione automatica di priorità, quella manuale
non è vincolata da alcuna limitazione al valore massimo o minimo.
3.2.3.3 Elenco delle componenti
Al fine di fornire un'idea di quanto possa essere capillare il sistema di attribuzione di
priorità in Maui, si riporta in Tabella 3.1 la lista completa delle sub-componenti,
raggruppate secondo le sei componenti. Relativamente alle metriche delle sub-
componenti, sono evidenziati in rosso i valori di priorità assegnati esplicitamente
dall'amministratore dello scheduler, in verde quelli derivati dalla differenza tra valori
assegnati e statistiche di sistema ed in blu i valori che accompagnano il job fin dalla sua
sottomissione. Tutti gli altri valori provengono dalle statistiche che Maui compila
durante il proprio funzionamento.
Componente Sub-Componente Metrica
CRED USER Priorità dell'utente
GROUP Priorità del gruppo di appartenenza dell'utente
(Credenziali ACCOUNT Priorità dell'account associato
del job) QOS Priorità della QOS
CLASS Priorità della coda di provenienza
FS FSUSERDifferenza tra obbiettivo ed uso corrente risorse
per utente
FSGROUPDifferenza tra obbiettivo ed uso corrente risorse
per gruppo
(Fair Share) FSACCOUNTDifferenza tra obbiettivo ed uso corrente risorse
per account
FSQOSDifferenza tra obbiettivo ed uso corrente risorse
per QoS
FSCLASSDifferenza tra obbiettivo ed uso corrente risorse
per coda
RES NODE Numero nodi richiesti
PROC Numero processori richiesti
(Risorse MEM Totale memoria richiesta
richieste) SWAP Totale memoria virtuale richiesta
DISK Totale spazio disco richiesto
PS Proc-secondi richiesti
PE totale processori-equivalenti richiesti
WALLTIME Valore di Walltime richiesto
56
SERV QUEUETIME Durata di permanenza in coda
(Livello servizi) XFACTOR Minimo fattore di espansione del job
BYPASS Numeri sorpassi subiti dal job causa backfilling
TARGET TARGETQUEUETIMETempo di raggiungimento obiettivo di
permanenza coda
(Livello obiettivo ) TARGETXFACTOR Distanza dall'obiettivo di fattore di espansione
USAGE CONSUMED proc-secondi correntemente dedicati
REMAINING proc-seconds fermi
(Risorse usate PERCENT Percentuale Walltime consumato
dai job attivi) EXECUTIONTIME Secondi trascorsi dall'avvio del job
Tabella 3.1
Attributi e classi di attributi di un job.
I valori di default per il peso delle componenti sono tutti settati ad “1”, mentre i pesi
delle sub-componenti sono invece tutti uguali a “0”. Fa eccezione “QUEUETIME” che
invece è impostato ad uno. Ciò comporta che in assenza di specifiche policy di priorità,
lo scheduler lavori in modalità FIFO38.
3.2.4 Node allocation
Mentre il criterio di priorità e le relative policy determinano quali job mandare in
esecuzione, le policy di allocazione dei nodi permettono allo scheduler di decidere quali
tra le risorse disponibili saranno allocate ai job. L' adozione di una buona politica di
allocazione è di importanza strategica. Le risorse di calcolo di un batch system
rappresentano un insieme finito. Esse devono essere amministrate con grande
parsimonia ma allo stesso tempo essere fruite dal maggior numero possibile di job.
Questa missione è piuttosto ardua e non esiste una soluzione unica per tutti i sistemi. Ad
esempio, i batch system di tipo cluster sono spesso caratterizzati da risorse non
omogenee, velocità di comunicazioni diverse tra alcuni nodi e richiedono quindi
politiche di allocazione radicalmente diverse da quelle adatte per super-computer dove
risorse e comunicazione sono omogenee. Non solo. Anche nello stesso sistema, la
politica di allocazione deve tenere conto delle modalità di funzionamento scelte, come
ad esempio se questo preveda o meno la possibilità di riservare in anticipo39 determinate
risorse di calcolo per determinati job.
38 FIFO (First In First Out). Secondo questa politica i job sono avviati all'esecuzione nello stesso ordine in
cui essi vengono sottomessi alle code del sistema.
39 Il sistema di prenotazione delle risorse è una delle funzionalità più importanti di Maui.
57
La node allocation di Maui, tiene conto di numerosi aspetti relativi allo hardware di
sistema ed alle politiche di funzionamento. Essa permette di scegliere tra diverse
strategie di allocazione delle risorse, quella che meglio si adatta alla tipologia del
sistema sottostante. Le principali modalità previste sono le seguenti:
• FIRSTAVAILABLE (FIFO) è la politica di allocazione più semplice e veloce. I nodi
liberi vengono allocati secondo l'ordine in base al quale sono rilasciati al resource
manager dai precedenti assegnatari. A dispetto della scarsa raffinatezza, questa scelta da
buoni risultati in sistemi omogenei gestiti senza prenotazione.
• LASTAVAILABLE assegna ogni nodo a quei job la cui esecuzione riempia il più
possibile l' intervallo di tempo tra due sue prenotazioni successive. Questo algoritmo è
un esempio di best fit40 temporale ed è usato per minimizzare gli effetti negativi di
gestioni che ricorrano pesantemente alla tecnica della prenotazione delle risorse.
• MINRESOURCE si basa sull'assegnazione ai job di nodi col minimo insieme di
risorse atto a consentire l' esecuzione del job stesso. Questa tecnica minimizza lo spreco
di risorse in sistemi eterogenei.
• MACHINEPRIO associa ai nodi di calcolo valori di priorità di assegnazione, in base a
criteri statici e dinamici. Si può pensare a questo algoritmo come ad una variante
“flessibile” di MINRESOURCE.
• MAXBALANCE cerca di allocare ad un job un insieme di nodi il più possibile
“bilanciato” (omogeneo) rispetto ad una metrica di valutazione, che solitamente è la
velocità del processore.
• FASTEST assegna i nodi liberi a partire da quelli più veloci o casualmente qualora tale
informazione no fosse disponibile.
• CPULOAD è un algoritmo per sistemi i cui nodi sono gestiti in modalità timesharing41
ed assegna ai job, nodi i cui processori sono meno impegnati dall'esecuzione di job
precedenti.
Qualora nessuna delle precedenti politiche fosse considerata idonea ad allocare i nodi di
un dato sistema, Maui consente di invocare algoritmi di allocazione personalizzati,
sviluppati in base alle specifiche esigenze del sistema.
40 Letteralmente significa “miglior riempimento” e sta ad indicare la soluzione ottimale di un problema di
massimizzazione, rispetto ad una certa metrica di valutazione.
41 E' una tipica modalità operativa in cui l'assegnazione di un processore è suddivisa nel tempo, tra più
utilizzatori (processi).
58
3.2.5 Maui Fairness
La disponibilità di un buon algoritmo di scheduling e di un appropriato criterio di
allocazione delle risorse, determina indubbiamente un uso efficiente del batch system
ma non da alcuna garanzia che questo utilizzo sia anche equamente ripartito tra i vari
utenti42. La definizione del concetto di equità di utilizzo, o fairness, varia molto da
sistema a sistema, dipendendo pesantemente dalle condizioni esterne legate agli utenti.
In questa sede sarà genericamente intesa come:
la possibilità di dare equamente accesso alle risorse di calcolo ad ogni utente.
Maui provvede tre diverse funzionalità specifiche per evitare assegnazioni sbilanciate
delle risorse:
➢ restrizione delle allocazioni
➢ fairshare
➢ allocation management
Combinate tra loro ed affiancate da politiche di priorità mirate, esse permettono una
fruizione equilibrata del sistema da parte dei suoi utenti.
3.2.5.1 Restrizione delle allocazioni
Questa tecnica rappresenta la più semplice delle politiche di fairness. Essa permette di
porre dei limiti, all'allocazione delle risorse di calcolo necessarie per l'esecuzione di un
job, anche se al momento ve ne siano disponibili in abbondanza. La definizione delle
policy di restrizione è basata sulle cosiddette credenziali del job. Come si ricorderà,
ogni job di Maui è accompagnato da un certo numero di attributi che ne esprimono
caratteristiche di vario genere. Tra questi prendono il nome di credenziali i seguenti
cinque:
42 Un esempio di assegnazione iniqua di risorse potrebbe essere il seguente. Un utente sottomette un gran
numero di job molto onerosi al sistema, in un momento in cui buona parte dei nodi di calcolo sono liberi.
I job ricevono tutte le risorse di cui hanno bisogno, prendono avvio e restano in esecuzione per dieci
giorni. Durante questo lasso di tempo considerevole, buona parte dei job pervenuti da altri utenti non può
eseguire perché non ci sono processori liberi. Il sistema di priorità e di allocazione dei nodi hanno
funzionato egregiamente ma il primo utente ha ingiustamente “monopolizzato” il sistema e danneggiato
gli altri fruitori del servizio.
59
• user : nome dell'utente proprietario del job
• group : nome del gruppo a cui appartiene l' utente
• account : tipo di account del job
• QoS : classe di Quality of Service di appartenenza
• class : coda di provenienza del job
Una policy di restrizione, consiste semplicemente nello specificare, per un dato valore
di credenziale (user-name, group-name, ecc.), la massima quantità di risorse fruibili
simultaneamente (nodi, CPU, memoria, ecc.) dai job che riportano quel valore per
quella credenziale43. Maui tiene traccia delle risorse correntemente allocate e
l'assegnamento di quelle disponibili, avverrà solo per i job i cui valori di credenziale
rispettino tutti i vincoli imposti (se ve ne sono)44.
Il meccanismo di restrizione delle allocazioni, data la sua caratteristica di porre limiti è
idoneo ad una realizzazione di massima per le politiche di fairness45 e lascia le
operazioni di sintonia fine ad altri strumenti come ad esempio il fairshare.
3.2.5.2 Fairshare
Una volta stabiliti gli ordini di grandezza, relativi ai limiti di fruizione delle risorse, il
meccanismo di fairshare (condividere equamente) permette un eccellente affinamento
del fairness del sistema. Esso consiste nella possibilità di alterare la priorità dei job
ancora in coda, in accordo ad obbiettivi prefissati riguardo l'assegnazione delle risorse
ed ai dati di utilizzo recente46 del sistema.
43 Se ad esempio per un dato utente (user) si stabilisce un limite di 10 job in esecuzione contemporanea ed il
limite è al momento raggiunto, tutti gli altri job la cui credenziale “user” riporta lo stesso nome utente,
non verranno eseguiti, indipendentemente da quella che sono le priorità da essi maturate e la quantità di
risorse disponibili. Questo esempio è del tutto generale e può essere esteso a qualsiasi valore delle
credenziali per un qualsiasi insieme di risorse.
44 Una variante di questo meccanismo consente di fissare, per una data credenziale, non un singolo valore
limite riguardo l'allocazione delle risorse ma una coppia. Il primo valore (detto soft limit) esprime il
massimo numero di risorse assegnabili nel caso in cui la farm si trovi a pieno carico, il secondo (hard
limit) stabilisce il limite (meno restrittivo) per le allocazioni in caso di farm non impegnata.
45 La politica delle restrizioni di allocazione non è adatta a realizzazioni accurate della “gestione equa” del
sistema. Essa opera infatti facendo rispettare rigidamente dei limiti di utilizzo, anche quando il sistema è
in gran parte libero e tale fiscalità non ha senso. La sua utilità va quindi considerata esclusivamente
nell'ottica di una regolamentazione macroscopica, che stabilisca limiti massimali e prevenga la
monopolizzazione delle risorse da parte di singoli utenti o gruppi.
46 Il temine “recente” non è quantificabile in termini assoluti ma dipende fortemente dal tipo di sistema e
dalle politiche di scheduling che per esso sono desiderate.
60
Le policy di fairshare, fanno riferimento alle credenziali del job e consistono nello
specificare per un dato valore di credenziale (user-name, group-name, ecc.), la
percentuale ottimale di risorse (nodi, CPU, memoria, ecc.) fruibili simultaneamente dai
job, che riportano quel valore per quella credenziale. Ogni policy codifica quindi un
determinato target di fruizione di certe risorse, da parte di una determinata utenza47.
Come si è già accennato, Maui compila durante il suo ciclo di esecuzione, una serie di
statistiche, inerenti la storia recente dell'assegnazione delle risorse. L' algoritmo di
fairshare opera come segue:
1. Accede le statistiche ed estrae la percentuale d' uso delle risorse relativamente alle
utenze specificate nelle policy (obbiettivo d'uso).
2. Calcola la differenza tra percentuale d' uso reale e l'obbiettivo stabilito.
3. Inserisce la differenza suddetta come valore di priorità della giusta sub-componente48
dei job.
In base al sistema di calcolo della priorità già descritto, Maui aggiorna quindi la
posizione del job nella lista dei job eleggibili, portandolo verso l'alto se l'utenza a cui
afferisce sta consumando poche risorse rispetto all'obbiettivo preposto o retrocedendolo
se sta invece consumando una percentuale delle risorse che ecceda quella desiderata.
Oltre alla definizione delle policy, Maui provvede un ulteriore livello di configurazione
del fairshare, permettendo di definire l'ampiezza dell'intervallo temporale49 sul quale
raccogliere le statistiche d'uso e consentendo la scelta delle metriche da adottare nel
calcolo delle statistiche medesime. La validità del fairshare, risiede nel fatto che non
ponendo limiti ferrei all'assegnazione delle risorse, non ostacola l' avvio dei job di
utenze che già impegnano oltre la loro quota il sistema, quando per esso non ci sono
altre richieste pendenti. Non appena però i job di utenze che sotto-utilizzano la rispettiva
quota, pervengono al sistema, questi scavalcheranno in priorità50 gli altri accodati,
finché la distribuzione delle risorse non converga nuovamente all'equilibrio di utilizzo.
47 D'ora in avanti il termine “utenza” sarà usato per indicare i possibili valori che può assumere una
qualsiasi delle credenziali del job (nome utente, nome di una classe QoS, nome di una coda , ecc.).
48 Si veda la componente FS (FairShare) e le relative sub-componenti della Tabella 3.1 .
49 Valori tipici variano da due o tre giorni a due o tre settimane a seconda del sistema in esame e delle
politiche di scheduling che si vogliano attuare.
50 E' evidente che per un corretto funzionamento delle politiche di fairshare, i pesi accordati alla
componente ed alle sub-componenti FS del sistema di priorità di Maui, devono essere accuratamente
dimensionati.
61
3.2.5.3 Resource allocation management
Un allocation manager è un programma che permette l'assegnazione delle risorse
secondo schemi complessi e mutevoli che non possono essere realizzati col solo uso di
restrizioni e fairshare. L'utilizzo di un allocation manager è facoltativo spesso
l'amministratore dello scheduler decide di non avvalersene, se comunque viene attivato
agisce in sintonia con le regole di di restrizione e fairshare. Una descrizione degli
articolati meccanismi di “crediti” e di “debiti” di risorse di un allocation manager,
sarebbe del tutto fuori luogo in questa sede. Per il prosieguo è sufficiente sapere che il
suo funzionamento è simile al modo di operare di un istituto di credito che pianifichi
prestiti (nel nostro caso di risorse di calcolo) in base a credenziali specifiche dei
richiedenti (job), a seconda delle finanze attuali di cui dispone (stato del sistema) e
tenendo conto di investimenti già decisi per il futuro (prenotazioni delle risorse).
3.2.6 Il controllo dell'accesso alle risorse
Quanto visto finora rappresenta un insieme di meccanismi atto a garantire un ordine di
scheduling accurato, un'assegnazione razionale delle risorse e la possibilità di soddisfare
una legittima aspettativa di equità nel trattamento dei vari job. La gestione efficiente di
un batch system richiede comunque ulteriori strumenti di amministrazione,
relativamente alla gestione delle risorse, allo scopo di poter garantire anche una
fruizione arbitraria delle stesse, provvedere meccanismi per ottimizzare l'ordine di
scheduling, ed offrire qualità di servizio differenziate a seconda dell'utenza. A questo
scopo Maui implementa tre funzioni specifiche, per il controllo dell'accesso alle risorse
di calcolo:
➢ Prenotazione delle risorse
➢ Partizionamento delle risorse
➢ Livelli diversificati di qualità del servizio (QoS)
3.2.6.1 Prenotazione delle risorse
Questa caratteristica consiste nella possibilità di prenotare (o riservare) la fruizione
futura di determinati insiemi di risorse, a favore di uno o più beneficiari. Questa
impostazione può abbracciare intervalli di tempo più o meno lunghi e, può essere decisa
dall'amministratore del sistema o da Maui stesso nell'attuazione di certe modalità
operative. Una prenotazione è costituita dalle seguenti tre componenti.
62
• Insieme delle risorse riservate: indica la totalità delle risorse interessate da
una prenotazione. Queste sono suddivise in Task ossia collezioni indivisibili di
elementi hardware (processori, memoria, spazio disco, ecc.) che fanno
riferimento ad uno stesso nodo di calcolo51. Le richieste di prenotazione
pervengono a Maui come richieste di Task e le allocazioni delle risorse
prenotate, ai relativi beneficiari, avvengono anch'esse come allocazioni di
Task52. L'insieme delle risorse riservate è composto da uno o più Task.
• Time-frame: è l'intervallo temporale durante il quale è in vigore la
prenotazione. In Maui è specificato da un tempo di inizio ed uno di fine,
oppure da un tempo di inizio ed una durata.
• Access Control List (ACL): specifica una lista delle credenziali in base a cui è
possibile individuare quale job ha diritto di usufruire delle risorse di una data
prenotazione.
In Maui sono possibili tre diversi tipi di prenotazione delle risorse. Il primo tipo è detto
amministrativo e corrisponde alle prenotazioni che l'amministratore dello scheduler
effettua in maniera contingente all'esecuzione di determinati progetti o computazioni per
le quali esistano stringenti vincoli di tempo. Il secondo tipo è chiamato standing
reservation ed indica una pianificazione anche complessa delle prenotazioni per
permettere la diversificazione delle attività del sistema su base giornaliera, settimanale,
mensile o annuale. L'ultimo tipo consiste nelle cosiddette priority reservation e
rappresenta un meccanismo interno di Maui per impedire attese indefinitamente lunghe
per quei job che non trovino, malgrado la priorità maturata, un adeguato insieme di
risorse disponibili53. La possibilità di prenotare anticipatamente risorse di calcolo per
51 La strutturazione in Task delle risorse è usata da Maui per delimitare insiemi di elementi hardware in
grado di soddisfare determinati tipi di esecuzioni. Se ad esempio un Task richiede 4 processori e 2 GB di
memoria, Maui deve trovare nel sistema (e riservarli) i quattro processori e la memoria su uno stesso
nodo e non può riservare invece 3 processori ed 1GB di un nodo ed un processore ed 1GB di un altro,
giacché questa seconda soluzione andrebbe contro le necessità per le quali la prenotazione è stata
richiesta.
52 Le componenti un Task non possono essere allocate separatamente, in accordo alla definizione data di
collezione atomica di risorse.
53 In taluni casi, come ad esempio quando lo scheduler sia abilitato ad eseguire job al di fuori dell'ordine di
priorità (backfill), potrebbe accadere che job particolarmente onerosi in termini di risorse richieste,
vengano scavalcati da job molto piccoli, per un numero di volte indefinito. Per evitare questa situazione
patologica detta starvation, Maui individua nel futuro del sistema, il primo istante in cui tutte le risorse
necessarie per il job in attesa siano disponibili e le riserva, garantendo la prossima esecuzione.
63
eseguire job, aggiunge la dimensione temporale nelle decisioni di allocazione dei nodi.
Una tipica rappresentazione dell'attività di esecuzione dei job in rapporto alle
prenotazioni future è riportata in Figura 3.2 e prende il nome di spazio nodi-tempo.
Nod
i di c
alco
lo
Tempo
Prenotazione 1
Prenotazione 2
t1
t2
t3
t4
Prenotazione 3
Job X
Job Y
Job Z
1
2
3
3
ACL di appartenenza
Job K
Figura 3.2
Spazio nodi-tempo con tre prenotazioni, tre job accreditati alla fruizione delle stesse ed un job non accreditato.
Lo spazio nodi-tempo può essere letto nel seguente modo.
• Ogni sottile striscia arancione rappresenta un nodo di calcolo.
• L'estremità sinistra delle strisce corrisponde al tempo presente.
• Spostandosi verso destra si avanza nel futuro.
• Le porzioni delle strisce non coperte da rettangoli verdi o blu, indicano intervalli di
tempo in cui il nodo è libero.
In questo scenario l'esecuzione di un job appare come un rettangolo che avrà per altezza
il numero di nodi che servono alla sua computazione, ed una larghezza pari alla durata
della computazione stessa. Anche le prenotazioni hanno un aspetto rettangolare ed
interessano un certo numero di nodi per un certo intervallo di tempo. Ad esempio
“Prenotazione 2” riserva otto nodi tra i tempi t1 e t2 (time-frame), Prenotazione 3
riserva dieci nodi tra t3 e t4. “Prenotazione 1” (cinque nodi) si conclude invece oltre
l'intervallo temporale considerato nell'immagine.
64
Come detto ad ogni prenotazione corrisponde una lista d'accesso (ACL). Il job X ad
esempio rientra nelle ACL di prenotazione 1 e 2, mentre job K non ha diritto di fruire di
alcuna prenotazione.
La Figura 3.2 mostra anche una caratteristica della prenotazione di risorse in Maui,
ossia che essa è non vincolante in termini di allocazione delle stesse. Il “job X” rientra,
come evidenziato nell'immagine, nelle ACL di “Prenotazione 1” e “Prenotazione 2” ma
lo scheduler non forza la sua esecuzione negli insiemi di risorse riservate. Esso è invece
libero di cercare la miglior allocazione possibile per il job, che in questo caso consiste
anche in normali nodi liberi. Lo stesso discorso vale per “Job Y” che pur rientrando
nella ACL di “Prenotazione 3” è interamente eseguito su nodi liberi, mentre è
puramente casuale che i nodi allocati a “Job Z” risiedano tutti all'interno della
prenotazione a cui esso ha accesso. Ben diverso sarebbe il discorso se non vi fossero
nodi disponibili al di fuori di quelli prenotati e resta ovvio che job che non rientrano in
nessuna ACL, possano eseguire solo su nodi non riservati (job K).
3.2.6.2 Partizionamento delle risorse
Questa tecnica prevede la possibilità di ripartire le risorse di calcolo del sistema, in
strutture logiche che prendono il nome di partizioni. Gli elementi di ogni partizione
sono in genere accomunati da una qualche affinità di tipo logico (nodi di calcolo di un
certo gruppo di ricerca, ecc.) o più spesso di tipo fisico (omogeneità dello hardware,
stessa velocità di elaborazione o comunicazione, ecc.). L'utilità di definire partizioni del
sistema, è data dalla possibilità di sottomettere i job al gruppo di risorse più idoneo,
anziché lasciare allo scheduler la scelta in un insieme indifferenziato. Inoltre l'accesso
ad una partizione può essere ristretto con una lista di accesso (ACL) proprio come per le
prenotazioni54, consentendone la fruizione da parte dei job con dati valori delle
credenziali.
3.2.6.3 QoS (Qualità del Servizio)
Come Maui pone regole per determinare il proprio funzionamento, così provvede gli
strumenti che permettano di eludere le stesse.
Può capitare che alcuni job richiedano un trattamento particolare e così Maui consente
54 Una partizione di risorse con restrizione dell'accesso (ACL), può essere considerata come una
prenotazione definitiva, senza scadenza.
65
la definizione di alcune classi di servizio in cui siano specificati i vari privilegi di cui i
job possano beneficiare, se le loro credenziali lo consentano. Questi privilegi riguardano
aspetti come il poter disattendere vincoli e restrizioni, un calcolo della priorità al di
fuori degli schemi usuali o l'aggiramento di alcuni usuali meccanismi di esecuzione.
Ogni classe di servizio può essere definita in base a specifiche esigenze di QoS e, come
visto in precedenza, essere corredata di una lista di accesso (ACL) in base alla quale
riconoscere i job che possono usufruirne.
3.2.7 Maui Backfill
L'ordine di scheduling basato sul meccanismo della priorità di esecuzione, produce in
alcuni casi un sottoutilizzo delle risorse del sistema. Ogni volta che un job in cima alla
lista di priorità non trovi sufficiente “spazio” per eseguire, resta bloccato finché le
risorse mancanti non vengano rilasciate. Durante questa attesa nessun altro job può
passare in esecuzione e così i nodi di calcolo eventualmente liberi restano inutilizzati.
L'idea alla base del backfill è di consentire l'esecuzione fuori dall'ordine di priorità, di
quei job eleggibili per cui le risorse correntemente fruibili siano adeguatamente
dimensionate. Perché il backfill funzioni è necessario risolvere due problemi.
• Evitare che ripetute esecuzioni fuori ordine prolunghino indefinitamente
l'attesa per il job bloccato.
• Garantire che l'esecuzione fuori ordine sia conclusa prima che il job a massima
priorità riceva le risorse per le quali era in attesa.
Cominciamo dal primo. Maui conosce i walltime55 di tutti i job e da quanto tempo
ognuno è in esecuzione, quindi può calcolare con una semplice differenza il tempo
limite entro il quale, le risorse di interesse saranno tutte rilasciate dai rispettivi detentori.
A partire da quell'istante verra quindi fissata una prenotazione per tutte le risorse
necessarie al job in attesa, garantendone così la certa esecuzione.
Per risolvere il secondo problema, l'algoritmo di backfill deve conoscere esattamente le
ampiezze delle cosiddette finestre di backfill. Per chiarire questo concetto ci si servirà
della Figura 3.3.
55 Tempo limite entro il quale un job che non abbia completato la propria esecuzione viene soppresso.
66
Nod
i di c
alco
lo
Tempo
Job A
Job B
Nodi per il backfill
a) b)
Finestra 1
Finestra 2Prenota
zioneJob C
Tempo
Figura 3.3
Nodi liberi e finestre di backfill
La parte “a)” della figura rappresenta uno spazio nodi-tempo nel quale sono già in
esecuzione “job A” e “job B” (rettangoli blu). Al momento, le risorse necessarie
all'esecuzione di “job C” sono in parte occupate da questi due job e quindi esso non può
passare in esecuzione. Una prenotazione per esso delle risorse necessarie (rettangolo
grigio) è già stata effettuata da Maui, sulla stima di massima durata del job B e da quel
momento job C potrà eseguire. Le aree arancioni indicate dalle frecce, rappresentano
invece i nodi liberi fino alla terminazione di “job B” (cioè fino alla fruizione effettiva
della prenotazione).
La parte “b)” della figura mostra come Maui non consideri singolarmente gli insiemi di
nodi liberi compresi tra l'istante corrente e l'inizio prenotazione ma preferisca
raggrupparli in insiemi di uguale durata temporale: ogni insieme è una finestra di
backfill.
Una volta definite le finestre, l'algoritmo di backfill provvede a selezionare tra i job
eleggibili56, quelli per cui il numero di nodi richiesto e la massima durata di esecuzione,
siano compatibili con le ampiezze delle finestre stesse. Se ne trova, provvede ad
allocare loro le risorse57 ed avvia per tali job, l'esecuzione fuori ordine.
56 La selezione dei job compatibili con le finestre di backfill avviene in due fasi successive. Durante la
prima si compila una lista dei job che soddisfano le policy di fairness maggiormente restrittive, nella
seconda fase la lista viene estesa coi job che rispettano le policy di fairness meno restrittivi. La prima fase
ha priorità sulla seconda relativamente alla scelta dei job da eseguire fuori ordine.
57 Come nella normale allocazione dei nodi di calcolo, anche quella per “esecuzioni di riempimento”
avviene in accordo ad una specifica politica. L'impostazione di default di Maui è un'allocazione di tipo
FIRSTFIT ma con opportuna policy può essere cambiata in una qualsiasi delle altre considerate nel
paragrafo 3.2.5.2 .
67
3.2.8 Ciclo di esecuzione di Maui
Maui opera in maniera ciclica, alternando operazioni di scheduling, fasi di sleeping58 ed
esecuzioni di comandi esterni. Una nuova iterazione è avviata al verificarsi di uno
qualsiasi tra seguenti eventi.
• Cambiamento dello stato di un job o di una delle risorse di calcolo (ad esempio un job
viene terminato, un nodo di esecuzione fallisce, ecc.).
• Raggiungimento del limite di una prenotazione di risorse.
• Lo scheduler è riavviato da un comando esterno.
• Esaurimento del quanto di tempo impostato tra due successive iterazioni
Ad ogni iterazione lo scheduler esegue una serie di otto routine, che complessivamente
ne determinano il funzionamento.
1. Acquisizione di nuove informazioni. Maui interroga il resource manager per ottenere
le informazioni che questo ha raccolto sullo stato del sistema nel tempo trascorso dalla
precedente richiesta.
2. Aggiornamento delle statistiche. Vengono aggiornate le statistiche e le informazioni
relative ai job ancora in esecuzione mentre per quelli completati si aggiunge un
opportuno record nel file delle tracce di esecuzione. In questa fase vengono altresì
aggiornati i file di log del sistema.
3. Aggiornamento delle prenotazioni. In base alle informazioni raccolte al passo “1”,
Maui aggiorna gli insiemi di risorse prenotate, includendo i nodi disponibili e
rilasciando quelli divenuti indisponibili. Se previsto la prenotazione viene anticipata o
ritardata in caso di mancato reperimento delle risorse. Durante questa fase vengono
rimosse le prenotazioni scadute, aggiunte le nuove ed i job pronti, per i quali le risorse
erano riservate, ricevono l' effettiva assegnazione.
4. Elezione dei job accreditati. In questo passo viene compilata una classifica di tutti quei
job le cui caratteristiche soddisfino i vincoli e le policy stabiliti dallo scheduler per
accedere alla fase di esecuzione. Questi job sono detti “eleggibili”.
58 Fase di inattività tra due iterazioni successive.
68
5. Incremento delle priorità. Viene incrementata la priorità di avvio di ogni job
eleggibile in base al peso deciso concordato per i suoi attributi (proprietario, classe di
provenienza, tempo di accodamento, ecc).
6. Esecuzione dei job. I job che hanno maturato la priorità maggiore sono avviati
all'esecuzione finché le risorse libere non vengano esaurite. In caso il job a massima
priorità non disponga delle risorse necessarie, si esamina il successivo e così via fino al
lancio di un job compatibile con lo stato del sistema. In favore dei job “scavalcati”
vengono prenotate le risorse necessarie, in modo da evitare attese indefinite.
7. Backfill “morbido”. Maui cerca la presenza di finestre di backfill e se ne trova cerca di
riempirle con quei job eleggili che soddisfino le policy di fairness più restrittive. I criteri
di allocazione delle risorse per l'esecuzione di questi job sono quelli stabiliti
dall'amministratore dello scheduler.
8. Backfill “duro”. Se conclusa la fase precedente dovessero ancora ancora esserci
finestre di backfill, Maui cerca di riempirle con quei job che soddisfino le policy di
fairness meno restrittive. I criteri di allocazione delle risorse per l'esecuzione di questi
job sono quelli stabiliti dall'amministratore dello scheduler.
3.2.9 File di traccia
Al termine dell'esecuzione di ogni job, Maui aggiunge uno speciale record ad un file
detto traccia, situato in memoria di massa. Ogni record, il cui formato è fisso59, contiene
le informazioni relative al job, dal momento della sottomissione al sistema alla
finalizzazione60. Lo stesso avviene anche nel caso che il job abortisca spontaneamente o
venga soppresso tramite l'apposito comando. Questo prezioso file chiamato anche
workload trace, rappresenta la memoria storica dello scheduler ed è una miniera
pressoché inesauribile di informazioni. A partire da esso è possibile compilare
statistiche che aiutino a delineare il profilo dell'utenza del sistema o a valutare la bontà
della politica di scheduling impostata. Inoltre questo file può essere usato come carico
di lavoro virtuale per simulare il comportamento di Maui, con politiche diverse rispetto
a quella che ha prodotto la traccia.
59 Il record è formato da quarantaquattro campi, contenenti informazioni come: JobID, tempo di inizio
esecuzione, tempo di completamento, credenziali del job, ecc.
60 E' la fase conclusiva del ciclo vitale di un job. Le tre fasi che precedono la finalizzazione sono:
1.Creazione del job; 2.Sottomissione al sistema; 3.Esecuzione .
69
3.2.10 Scheduling e simulazione
In linea di principio la grande varietà di policy formulabili in Maui, permetterebbe di
affinare quanto si voglia la risposta del batch system (e parallelamente il grado di
soddisfazione degli utenti), al solo costo di un tempo sufficientemente lungo per operare
regolazioni ed assestamenti sempre più accurati. Sfortunatamente, anche disponendo di
un tempo virtualmente infinito, difficilmente si arriverà ad una configurazione ottimale
definitiva, perché l'insieme delle richieste computazionali che pervengono al sistema,
non gode di caratteristiche di stazionarietà: la sua contingenza alle necessità mutevoli
degli utenti, lo rende variabile nel tempo. D'ora in avanti si assume quindi che:
la bontà di una configurazione di scheduling è funzione della tipologia e del
flusso dei job, sottomessi al sistema nel tempo.
La ricerca di policy che portino ad un miglioramento dello scheduling, anche solo
temporaneo, deve essere continuativa ed avviene solitamente nell'unico modo che
garantisca sufficiente sicurezza: si operano variazione minime, procedendo per piccoli
passi, nella speranza di avvicinarsi all'obbiettivo. Se la via è quella giusta si prosegue,
altrimenti si torna indietro con una perdita minima.
I problemi cominciano qualora si voglia cambiare completamente strada, tentando
configurazioni radicalmente diverse o sperimentando politiche di scheduling mai
provate prima. Compiere simili tentativi su di un sistema in produzione, potrebbe
portare ad effetti imprevedibili come congestioni disastrose, perdita di job ed ire funeste
di utenti fino al giorno prima mansueti. Per scongiurare questi rischi Maui prevede una
modalità di simulazione che permette di valutare una qualsiasi configurazione di
scheduling, per un qualsiasi batch system, su un qualsiasi carico di lavoro reale o
ipotetico. I vantaggi della simulazione non riguardano solamente la salvaguardia del
sistema in produzione ma si manifestano con grande evidenza anche nella scala
temporale della ricerca. La velocità di simulazione è tale da ridurre la verifica della
bontà di una serie di policy a pochi minuti di computazione, mentre la stessa verifica
avrebbe richiesto settimane di osservazione del sistema reale.
La validazione e l'utilizzo del simulatore di Maui saranno oggetto dei successivi due
capitoli.
70
Capitolo 4
ALLESTIMENTO
DELL'INFRASTRUTTURA DI
VALIDAZIONE E SVILUPPO DEI
TOOL DI ANALISI
4.1 L'esperimento di validazione
Un simulatore è uno strumento prezioso. In ogni ambito di ricerca o di progettazione, la
possibilità di prevedere l'esito di un esperimento o l'evoluzione di un sistema, apporta
informazioni di enorme valore in fatto di riduzione dei costi e durata dei tempi di
lavoro. Un simulatore resta comunque uno strumento limitato. Qualsiasi sia il modello
di simulazione su cui si basi, questo sarà per forza di cose una semplificazione della
realtà ed ogni previsione fatta su un sistema complesso, produrrà necessariamente una
approssimazione anziché un'immagine esatta. Ciò non toglie comunque, che tale
approssimazione possa essere “accettabilmente” verosimile, ed adeguata allo scopo che
ci si proponga di raggiungere. L'utilizzo di un qualsiasi simulatore, che nel nostro caso è
un software riproducente l'attività di scheduling di Maui, deve quindi essere preceduto
da una fase di test in cui si verifichi la consistenza delle previsioni con la realtà, entro
limiti giudicati soddisfacenti. Tale fase di test preliminare è solitamente conosciuta col
nome di validazione del simulatore.
Il presente lavoro pone come suo obbiettivo primario, la costruzione degli strumenti
necessari all'analisi delle prestazioni di un batch system (basato su TORQUE + Maui)
e tale analisi non può prescindere dall'uso della simulazione per ottenere informazioni
sulla “bontà” di politiche di scheduling, non ancora sperimentate nel sistema reale.
71
Questo capitolo ed il successivo, trattano dunque della validazione del simulatore di
Maui. In particolare nelle pagine seguenti si darà una descrizione il più possibile
esaustiva dell'apparato hardware e software allestito a tale scopo, tenendo comunque
presente che molti dei tool sviluppati ai fini della validazione, hanno un'utilità ben più
generale e rappresentano gli strumenti di analisi coi quali si approccerà, nel capitolo
sesto, all'esame dei dati (reali e simulati) attinenti al batch system INFN di Perugia.
Le infrastrutture e gli strumenti in questione sono i seguenti.
1. Batch system di test: cluster di cinque macchine virtuali, composto da un nodo con
funzione di central manager e quattro nodi di calcolo, configurato come un batch
system TORQUE + Maui, concettualmente equivalente al sistema in uso nella farm di
produzione reale.
2. Nodo di simulazione: singola macchina virtuale per l'esecuzione del simulatore di
Maui.
3. Tool software di base: un insieme di script realizzati in linguaggio perl61 o in bash62
rispondenti a diverse necessità che vanno dall'automazione di operazioni ripetitive alla
correzione di bug del programma di simulazione di Maui
4. Tool software di automazione evoluta: un pacchetto di tre script bash, per
l'esecuzione automatica di simulazioni su un file di traccia Maui, sottomissione
automatica di job al batch system di test e funzioni di esecuzione seriali delle due
operazioni appena citate.
Ognuno dei precedenti strumenti, rappresenta il soddisfacimento di specifiche esigenze,
legate al raggiungimento di determinati obbiettivi. Nelle pagine seguenti, ogni
strumento hardware allestito o software implementato, verrà quindi presentato dopo una
breve descrizione delle necessità alle quali risponde.
61 Perl (practical extraction and report language) è un linguaggio di programmazione ad alto livello,
dinamico, procedurale e interpretato, creato nel 1987 da Larry Wall. Perl ha un singolare insieme di
funzionalità ereditate da C, scripting shell Unix (sh), awk, sed e in diversa misura da molti altri linguaggi
di programmazione, compresi alcuni linguaggi funzionali. La sua vocazione ad una facile e potente
manipolazione di stringhe e file di testo lo rende lo strumento più idoneo all'analisi dei file di traccia di
Maui.
62 Bash (bourne again shell) è una shell del progetto GNU usata nei sistemi operativi Unix e specialmente
in GNU/Linux.
72
4.2 Allestimento batch system di test
L'allestimento dell'infrastruttura di validazione è avvenuto in accordo a due specifiche
esigenze. Da un lato si necessitava di un batch system TORQUE + Maui avulso dalla
farm di produzione, e che quindi non potesse interferire con la normale attività di
quest'ultima, dall'altro occorreva che il batch system di test fosse un apparato
pienamente controllabile, caratterizzato da stati finale ed iniziale noti, in cui i job in
esecuzione fossero tutti e soli quelli inerenti la prova di validazione. Un cluster con tali
caratteristiche avrebbe inoltre offerto la possibilità di una interazione utente/sistema
notevolmente semplificata, utile alla comprensione di numerose dinamiche di
scheduling, non adeguatamente documentate in letteratura.
4.2.1 Struttura del batch system di test
La struttura per il batch system di test consiste in un piccolo cluster ricavato all'interno
della farm stessa, utilizzando le risorse disponibili63 al tempo dell'avvio di questo
progetto. Una rappresentazione del cluster di esperimento è riportata in Figura 4.1.
LocalVirtualBridge
Rete diconnessionedel clusterMacchina fisica “Devel 250”
test-simulator
test-master
test-node04
test-node01
test-node02
test-node03
Altre macchine virtuali
Xen Bridge
Figura 4.1
Realizzazione con macchine virtuali del batch system di test e del nodo di simulazione.
63 Alcuni dei nodi della farm non fanno parte del batch system di produzione ma sono riservati
dall'amministratore a funzioni di test, simulazioni, sviluppo software, ecc. Le risorse per l'esperimento di
validazione sono state attinte da tale repertorio.
73
L'assegnazione di risorse è consistita in sei macchine virtuali64, cinque delle quali
implementano il batch system TORQUE + Maui mentre la sesta, ospita il simulatore di
Maui. Queste sono in esecuzione sulla macchina fisica “Devel 250”, assieme alle virtual
machine dedicate ad altri esperimenti. I quattro nodi di calcolo virtuale comunicano col
proprio nodo central manager, attraverso le funzionalità di uno strato software detto
“Local Virtual Bridge”, mentre il nodo central manager ed il nodo che esegue il
simulatore di Maui, sono raggiungibili dall'esterno attraverso l'interfacciamento operato
dal servizio “Xen Bridge”.
I nomi scelti per le macchine fanno riferimento alla funzione a cui sono adibite:
• test-master è il nodo central manager del sistema, esegue i demoni pbs_server e maui e
svolge anche la funzione di User Interface;
• test-node01, test-node02, test-node03, test-node04: sono i nodi di calcolo, su ognuno
gira il demone pbs_mom;
• test-simulator: è il nodo per la simulazione delle tracce di esecuzione reali, su di esso
viene eseguito Maui in modalità simulation.
La scelta delle macchine virtuali (VM) per l'implementazione della struttura di test, è
motivata dai numerosi vantaggi che questa tecnologia apporta. Un cluster di test
“virtuale” può essere isolato con facilità dal cluster reale (che comunque lo ospita) e se
necessario migrato su macchine fisiche diverse da quelle su cui è in esecuzione65.
L'accesso ai vari nodi è stato reso possibile tramite shell remota, basata su protocollo
SSH (Secure Shell) ed i trasferimenti di file all'interno del sistema (oppure da e verso
esso), avvengono con l'uso di SCP (Secure Copy)66. Ai fini del test di validazione la
configurazione e l'utilizzo di un batch system basato su nodi virtuali sono del tutto
equivalenti ad uno implementato con macchine reali. D'ora in avanti ci si riferirà al
cluster di test, senza far ulteriormente menzione alla sua architettura virtual machine
based e si adotterà per esso il nome di “mini-cluster”.
64 Il concetto di macchina virtuale e la descrizione delle caratteristiche di questa tecnologia sono riportati nel
paragrafo “2.3.4 Macchine Virtuali”.
65 La migrazione delle macchine virtuali componenti il mini-cluster è realmente avvenuta durante il periodo
dell'esperimento di validazione, per rispondere a necessità contingenti l'amministrazione delle macchine
fisiche su cui quelle virtuali erano in esecuzione. L'impatto del trasferimento è stato pressoché inesistente
e non si è resa necessaria alcuna forma di re-installazione del batch system sul nuovo hardware.
66 Relativamente ad SSH e SCP si veda il paragrafo “2.4.2 Accesso e sicurezza”.
74
Per quanto riguarda la creazione degli account di utenti, gruppi e code (per la
sottomissione di job al sistema), questi si intendono aggiunti in numero adeguato al tipo
di test svolto ed in accordo alla nomenclatura sotto riportata.
Per gli utenti:Group_numero-gruppo_User_numero-utente
Per i gruppi:Group_numero-grupp
Per le code:lettera-alfabeto-greco
La descrizione dei dettagli dell'implementazione e della configurazione del mini-cluster,
è riportata nelle pagine seguenti, a partire dal successivo paragrafo.
4.2.2 Installazione e configurazione di TORQUE
L'installazione di TORQUE ha riguardato cinque delle sei macchine del test, vale a
dire quelle che implementano il batch system di test. La versione del resource manager
utilizzata è la 2.1.2, distribuita con il pacchetto torque-2.1.2.tar.gz. Come si ricorderà
dal capitolo 3, TORQUE consta complessivamente di due programmi serventi:
pbs_server e pbs_mom67 nonché di un pacchetto di script, con funzione di client per
l'invio di comandi utenti a pbs_server. L'installazione è avvenuta in modo differenziato,
a seconda che le macchine fossero i nodi di esecuzione oppure il nodo central manager.
Tale scelta è motivata dalla volontà di non installare servizi inessenziali all'attività
svolta dal nodo, prevenendo a monte i problemi dovuti ad attivazioni conflittuali dei
servizi stessi68. Per le due tipologie di nodo, lo script di configurazione dell'installer è
stato eseguito con le seguenti opzioni.
Per il nodo di calcolo:
# ./configure --disable-server --disable-clients -–with-scp
Per il nodo central manager:
# ./configure --disable-mom --with-scp
67 Vedi paragrafo “3.1.1 Architettura e demoni”.
68 La configurazione di default dell'installer di TORQUE, prevede che vengano installati in blocco i
programmi dei due server e degli script client, indipendentemente dal ruolo che poi sarà giocato dalla
macchina in questione. In se la cosa non causa problemi ma un'attivazione erronea di pbs_server su uno
dei nodi di calcolo, potrebbe ad esempio causare conflitti di comunicazione tra il pbs_server “legittimo” e
lo scheduler. Un programma non installato invece, mai potrà essere avviato per sbaglio. Allo stesso scopo
è bene che gli script di comando siano installati solo sulle User Interface e che il nodo central manager
non giri un demone “mom”. La pratica delle installazioni minimali e mirate, è la prassi nell'allestimento
dei batch system reali.
75
Come si nota dai comandi riportati, oltre a disattivare l'installazione dei servizi non
necessari, si è provveduto per ambedue le tipologie di nodo, all'attivazione del supporto
al protocollo di trasferimento cifrato dei file SCP. Il motivo è il seguente. Ogni volta
che un job completa la sua esecuzione presso un dato nodo di calcolo, il pbs_mom del
nodo scrive il risultato dell'elaborazione in un file con lo stesso nome del job. Affinché
il file possa essere trasferito attraverso il sistema fino a tornare all'utente che aveva
sottomesso il job, è necessario abilitare in TORQUE il supporto al protocollo di
trasferimento, adottato dal cluster su cui insiste il batch system. Nel caso in esame
questo è SCP. Ulteriori modifiche all'installazione standard non sono state necessarie.
La configurazione di TORQUE consiste in un insieme di operazioni, riguardanti sia la
macchina che esegue il “server” sia i nodi che girano il “mom”. Tali operazioni sono
descritte di seguito tenendo presente che i file di configurazione a cui si fa riferimento,
sono collocati nella cartella /var/spool/torque/, che rappresenta la home
directory di TORQUE, per tutte le macchine su cui è stato installato.
Configurazione lato mom (nodo di calcolo):
La configurazione di pbs_mom per i quattro nodi di calcolo avviene con la semplice
aggiunta del file di testo “server_name”, il cui contenuto è un'unica riga esprimente
l'indirizzo simbolico della macchina che gira il pbs_server. La riga da aggiungere è:
test-master
Eseguita l'operazione per tutti i nodi di esecuzione, è stato possibile avviare il demone
“mom” invocando l'apposito comando:
# pbs_mom
Configurazione lato server (nodo central manager):
Affinché pbs_server abbia visibilità dei nodi di calcolo del batch system di test, è
necessario che la lista dei loro indirizzi simbolici sia inserita nel file
“server_priv/nodes” nel seguente modo:
test-node01test-node02test-node03test-node04
Il completamento della configurazione di pbs_server avviene tramite l'uso di un
programma interattivo chiamato “qmgr” facente parte del pacchetto di TORQUE. Per
poter lanciare qmgr, il demone pbs_server deve già essere stato avviato col comando:
# pbs_server
76
Il tool qmgr consiste in una interfaccia a riga di comando, dalla quale è possibile
modificare le impostazioni di default del demone “server” di TORQUE o creare (e
configurare) le strutture dati fondamentali del resource manager: le code.
Si riportano a titolo di esempio le istruzioni di creazione ed attivazione della coda
chiamata “alpha”, tenendo presente che per l'aggiunta di altre code si è proceduto in
maniera analoga. Tali istruzioni si intendono eseguite al prompt del programma di
configurazione.
> create queue alpha > set queue alpha queue_type = Execution > set queue alpha enabled = True > set queue alpha started = True
Per tutte le altre impostazioni i parametri di default sono stati ritenuti soddisfacenti e
nessuna modifica è stata apportata. Il “server” è stato riavviato per rendere effettive le
modifiche ed il test di funzionamento effettuato invocando al prompt dei comandi:
# pbsnodes -a
ha confermato col proprio output, una piena e corretta interazione tra nodo principale e
nodi di calcolo69.
69 Il comando 'pbsnodes -a', lanciato dal nodo “server”, avvia un'interrogazione riguardo lo stato
corrente, rivolta a tutti i “mom” dei nodi elencati nel file “server_priv/nodes”. Per ogni comunicazione
andata a buon fine viene riportato lo stato del nodo (libero o occupato dalla computazione di un job) ed
una serie di informazioni aggiuntive sulle sue caratteristiche hardware. Se invece non è possibile stabilire
la comunicazione con un nodo, verrà riportato per esso lo stato “down”. Se il sistema è correttamente
configurato, il comando produrrà un output in cui nessuno dei nodi risulta “down” cioè irraggiungibile.
77
4.2.3 Installazione e configurazione di Maui
L'installazione di Maui ha riguardato due delle sei macchine del test, vale a dire il nodo
central manager della farm di test ed il nodo di simulazione. La versione dello
scheduler utilizzata è la 3.2.6p16, distribuita con il pacchetto maui-3.2.6p16.tar.gz. Le
due installazioni differiscono per piccoli dettagli, dovuti al diverso uso a cui i
programmi sono destinati.
Installazione nel nodo central manager (test-master):
L'attività di Maui su questo nodo consiste nello scheduling reale di job, quindi esso deve
interagire col resource manager (TORQUE) precedentemente installato. Affinché ciò sia
possibile, lo script di configurazione dell'installer è stato lanciato abilitando il supporto
a tale programma e specificando la directory in cui questo risiede.
# ./configure --with-pbs=/var/spool/torque/
Durante la fase d'installazione, non sono state necessarie ulteriori azioni.
La configurazione di Maui è stata altrettanto semplice e ha riguardato tre sole modifiche
al file maui.cfg. Le prime due per informare lo scheduler sul nome del nodo che lo
ospita e che il resource manager suo interlocutore è TORQUE (anch'esso in esecuzione
sul nodo test-master).
SERVERHOST test-master # macchina di residenza di Maui.
RMCFG[test-master]TYPE=PBS # Resource manager di riferimento.
La terza modifica di maui.cfg serve invece ad impostare l'intervallo di interazione dello
scheduler col resource manager, al minimo valore possibile (un secondo):
RMPOLLINTERVAL 1
Questa operazione consente di ottenere tracce di esecuzioni in cui i tempi riportati siano
precisi “al secondo”, in accordo alle esigenze di accuratezza degli esperimenti in seguito
condotti70.
Maui è già impostato di default all'attività di scheduling ed i restanti parametri del file
maui.cfg, non richiedono al momento modifica71.
70 Il default per l'intervallo tra ogni comunicazione col resource manager, è di trenta secondi. Questo valore
introduce una pari quantizzazione di tutti i tempi che Maui scriverà nella traccia. La risoluzione temporale
accurata al “mezzo minuto”, si addice bene ai sistemi in produzione (job che durano mediamente ore) ma
per i nostri esperimenti, in cui molti job possono durare anche solo qualche minuto, sarebbe inaccettabile.
71 Le configurazioni del file “maui.cfg”, relative alle policy che saranno decise per lo scheduler nelle varie
esecuzioni reali dei test di validazione, saranno descritte nel prosieguo, all'interno della presentazione dei
singoli esperimenti.
78
Il funzionamento del sistema (scheduler)-(resource manager) è stato verificato con
l'esecuzione del comando:
# schedctl -n
il cui output ha confermato, una piena e corretta interazione tra Maui ed il resource
manager72.
Installazione nel nodo di simulazione (test-simulator):
Su questo nodo Maui deve funzionare esclusivamente come simulatore e l'installazione
è avvenuta senza bisogno di abilitare alcun servizio aggiuntivo.
La configurazione invece ha riguardato ancora una volta il file maui.cfg ed è consistita
nella modifica dei tre seguenti parametri:
SERVERMODE SIMULATIONSIMWORKLOADTRACEFILE workload SIMRESOURCETRACEFILE resourcesRMPOLLINTERVAL 1
Le prime tre righe consentono di cambiare la modalità di funzionamento da scheduler
reale a simulatore e specificare da quali file leggere la traccia (workload) da simulare e
la configurazione hardware (resources) del sistema per il quale si esegue la simulazione.
La quarta invece imposta la massima frequenza temporale possibile per l'interazione
simulata col resource manager (ogni secondo contro i 30 di default).
4.2.4 Configurazione di SSH
Come già detto, usando il protocollo di trasferimento SCP, TORQUE si occupa di
trasferire i file coi risultati della computazione di ogni job, dai nodi di calcolo alla User
Interface da cui gli utenti potranno poi prelevarli. La modalità di funzionamento base di
SCP è di tipo interattivo e prevede, ad ogni trasferimento, la richiesta della password
dell'account a cui si vuole inviare il file. TORQUE non è in grado di gestire questa
funzione interattiva ed anche se lo fosse non potrebbe conoscere le password degli
utenti. Senza un'opportuna configurazione per rendere automatica l'operazione di
trasferimento, i file coi risultati non potrebbero lasciare i nodi di calcolo e
confluirebbero alle varie cartelle “undelivered”, situate nella home directory di
72 Il comando 'schedctl -n' produce da parte di Maui, una richiesta diretta al pbs_server di TORQUE,
per il reperimento di tutte le caratteristiche hardware dei vari nodi computazionali. A sua volta questo
contatta tutti i pbs_mom ed attende il ritorno delle informazioni per reindirizzarle verso Maui. Se il
sistema è correttamente configurato questa catena di comunicazione non conosce interruzioni e l'output
del comando riporta sullo schermo le caratteristiche, di tutti i nodi di calcolo del sistema.
79
TORQUE, in ogni execution node. La soluzione al problema è stata raggiunta con una
modif1ica dei due file di configurazione del protocollo SSH che, come si ricorderà, è
alla base di SCP73. La tecnica utilizzata si chiama Host Based Authentication e consiste
nell'autenticazione di un mittente in base all'accertamento dell'identità della macchina
da cui il file viene inviato. Nel caso specifico, quindi si è provveduto ad accreditare i
nodi di esecuzione presso il nodo central manager, in modo da consentire ai vari “mom”
di inviare file coi risultati del calcolo, verso la User Interface (che come detto risiede sul
nodo central manager), senza verifiche di password. Si riporta la procedura seguita.
Per ogni mittente (test-node01, test-node02, test-node03, test-node04):
1. Si è innanzitutto reso eseguibile il file binario di ssh da parte di applicazioni che girano
come ”root” (cioè il demone pbs_server)
# chown root /usr/bin/ssh
# chmod u+s /usr/bin/ssh
2. Si è generata una coppia di chiavi (pubblica-privata)74 DSA ed una coppia RSA con
l'apposito comando “ssh-keygen”.
3. 1Si è abilitato il supporto per questa tecnica nel file di configurazione del client SSH
“/etc/ssh/ssh_config” con la direttiva:
HostbasedAuthentication yes
Per il destinatario (test-master):
1. Si è abilitato il supporto per questa tecnica, inserendo nel file di configurazione
del server SSH “/etc/ssh/sshd_config” la direttiva:
HostbasedAuthentication yes
2. La parte pubblica delle chiavi generate per i nodi di esecuzione è stata copiata nel file:
“/etc/ssh/ssh_known_hosts”
73 Il protocollo SCP usa per l'autenticazione dello host da (o verso) cui trasferire un file, i meccanismi di
autenticazione di SSH. Una modifica della configurazione per SCP riguardo questi aspetti consiste quindi
in una modifica di SSH.
74 La crittografia a doppia chiave pubblica/privata (crittografia asimmetrica) è una delle più versatili e sicure
forme di cifratura oggi in uso. Essa consiste nella generazione di una coppia di chiavi, dette pubblica e
privata, tali che qualsiasi contenuto informativo criptato con chiave pubblica, possa essere decodificato
esclusivamente da chi possiede la corrispondente chiave privata. La versatilità di questa tecnica consiste
nella possibilità di poter inviare, senza particolari misure di sicurezza, la chiave pubblica al proprio
interlocutore e nel ricevere da questi contenuti criptati inaccessibili a chiunque non disponga della
rispettiva chiave privata.
80
3. I nomi dei nodi di esecuzione sono stati aggiunti al file: “/etc/ssh/shosts.equiv” col
seguente formalismo:
+test-node01+test-node02+test-node03+test-node04
A questo punto ogni comunicazione basata su SSH (compreso un trasferimento di file
via SCP) e diretta dai nodi di calcolo al nodo central manager, è considerata attendibile
e non più sottoposta a verifica di password. Il test di funzionamento è stato eseguito con
trasferimenti manuali di file e quelli automatici compiuti da TORQUE. In entrambi i
casi, non si sono riscontrati problemi di funzionamento.
4.2.5 Creazione degli utenti
Affinché TORQUE possa gestire correttamente i job di un utente, è opportuno che in
fase di configurazione del batch system, la creazione degli utenti e dei gruppi segua i tre
seguenti accorgimenti:
• l'utente deve avere un account non solo sulla User Interface da cui si connette, ma anche
su tutti i nodi di calcolo a cui i propri job possono essere inviati per la computazione;
• è bene che gli account di uno stesso utente, abbiano lo stesso User ID75 su ognuno dei
nodi in cui sono presenti;
• è bene che i gruppi di appartenenza dei vari utenti, abbiano lo stesso Group ID76 su
ognuno dei nodi in cui sono presenti.
La creazione degli utenti e dei rispettivi tre gruppi di appartenenza, è avvenuta per i
nodi del mini-cluster in modo automatizzato e nel rispetto dei vincoli precedentemente
elencati, utilizzando un tool appositamente sviluppato per tale operazione: lo script di
shell makeuser.sh.
La descrizione dello script e della sua modalità di utilizzo, è riportata nel prossimo
paragrafo, assieme a quella degli altri tool software, detti “di base”, sviluppati nel corso
di questo lavoro.
75 Nei sistemi Unix/Linux è un numero intero compreso tra 0 e 65.535 che identifica un utente del sistema.
Il default prevede che lo User ID di utenti differenti siano differenti (identificazione univoca dell'utente).
Valori tra 0 e 999 sono tipicamente riservati per account di sistema.
76 Nei sistemi Unix/Linux è un numero intero compreso tra 0 e 65.535 che identifica un gruppo del sistema.
Il default prevede che il Group ID sia univoco. Valori tra 0 e 999 sono tipicamente riservati per account
di sistema.
81
4.3 Tool di base
Questo insieme di utilità è stato sviluppato per rispondere a problematiche piuttosto
diverse tra loro. Si va dalla necessità di automatizzare le monotone operazioni di
configurazione del batch system alla sottomissione automatica di job nello stesso, dalla
correzione di anomalie di funzionamento del simulatore di Maui, alla possibilità di
estrarre in maniera semplice e flessibile, informazioni native dal file di traccia di Maui o
derivarne di nuove . Quest'ultima funzionalità ha rappresentato lo sforzo di gran lunga
maggiore ed è sfociata nello script workload-analyzer.pl. Indipendentemente dalla
rispettiva complessità ed articolazione delle funzioni offerte, questi tools fanno parte di
un pacchetto software che diremo di base per distinguerlo dal pacchetto dei tools di
automazione, descritto nel prossimo paragrafo 4.4. Di seguito si riporta la descrizione
dei tool di base.
4.3.1 Lo script “makeuser.sh”
Nell'ambito dei test condotti ai fini del presente lavoro, numerose volte si è resa
necessaria la creazione nel mini-cluster, di nuovi insiemi di utenti e dei rispettivi gruppi
di appartenenza. Come si è visto, TORQUE richiede che l'operazione di creazione di
ogni nuovo account, debba essere replicata anche su tutti i nodi di calcolo, un compito
oneroso se eseguito manualmente. Inoltre la necessità della sincronizzazione degli ID
degli utenti e degli ID dei gruppi, espone al rischio di errori insidiosi, riscontrabili solo
durante il funzionamento del batch system.
Lo script makeuser.sh, è stato sviluppato allo scopo di poter creare su un qualsiasi
nodo, un qualsivoglia numero di account di utenti (e di gruppi), assegnando in maniera
deterministica sia gli ID d'utente che quelli dei relativi gruppi. Lo script richiede in
input una lista di nomi utenti, per ognuno dei quali sia specificato il gruppo principale di
appartenenza e gli eventuali gruppi secondari. La lista di nomi deve essere un file di
testo compilato nel rispetto del seguente formalismo:
nome_utente : gruppo_di_appartenenza_principale [altri_gruppi]
Dal parsing della lista lo script ricava in primo luogo i nomi dei gruppi, li crea
assegnando un Group ID progressivo, quindi aggiunge gli utenti, inserendoli nei
rispettivi gruppi ed assegnando, anche in questo caso, User ID progressivi. La tecnica di
numerazione degli ID, dipende esclusivamente dall'ordine di compilazione della lista
degli utenti ed eseguendo lo script sui vari nodi con quella stessa lista tutti gli ID degli
account di gruppo e di utente risultano sincronizzati.
82
Lo script prevede un intervallo di ID che di default va da un valore soglia 1.000 ad un
limite superiore di 65.000. Ad ogni esecuzione gli account già presenti in questo range
vengono rimossi e rimpiazzati dai nuovi. L'intervallo degli indirizzi può essere
modificato dall'utente invocando le apposite opzioni77, in modo da aggiungere nuovi
utenti e gruppi in intervalli di ID non occupati, senza eliminare i preesistenti. Sono
inoltre disponibili le opzioni di sola cancellazione degli utenti (e gruppi) compresi in un
certo intervallo di ID e la possibilità di aggiungere utenti senza che per essi sia creata la
relativa directory nella cartella “/home” del nodo.
Il codice dello script makeusers.sh è riportato in Appendice A1.
4.3.2 Lo script “sleep-launcher.sh”
Questo script implementa un meccanismo per la sottomissione automatica di job di tipo
“sleep78”, per conto di un qualsiasi utente accreditato, in un batch system in cui il
resource manager sia TORQUE. La sequenza di lancio degli “sleep” è specificata in un
file di testo, in cui ogni riga è un record col seguente formato:
nome_utente tempo_di_sottomissione nome_coda durata_sleep
Ogni campo del record ha il significato riportato in seguito.
• nome_utente indica il nome dell'utente per conto del quale lo script sottometterà il job
“sleep”. Ovviamente questo nome deve corrispondere ad un account valido nel sistema.
• tempo_di_sottomissione esprime il tempo in cui deve avvenire la sottomissione del job
al sistema. I tempi sono indicati nell'abituale formato “hh:mm:ss” ed esprimono quanto
ritardare la sottomissione al sistema dello sleep job, rispetto all'istante in cui è stato
avviato lo script di lancio. A titolo di esempio un tempo di lancio “00:00:00” comporta
il lancio di un job in concomitanza dell'avvio dello script stesso, mentre un tempo
01:00:15 comporterà la sottomissione del job dopo un'ora e quindici secondi dall'avvio
del lanciatore.
77 Riguardo la possibilità di definire nuovi intervalli degli ID, si è convenuto che questi non possano
eccedere i valori stabiliti per il default, vale a dire che qualunque nuovo intervallo dovrà essere compreso
tra 1.000 e 65.000.
78 Sleep è un comando dei sistemi Linux/Unix che sospende il flusso di esecuzione nel sistema in cui è
eseguito, per un tempo specificato. Lo sviluppo di un lanciatore di job di tipo “sleep” è motivato da
ragioni che saranno spiegate nel capitolo 5. Per il momento, si può considerare per semplicità un job
basato sull'esecuzione di un comando sleep, come un qualsiasi job che si possa sottomettere ad un batch
system.
83
• coda rappresenta il nome della coda del batch system sulla quale si effettua la
sottomissione del job.
• durata_sleep durata dello “sleep” da inviare come job, espressa in hh:mm:ss.
Il codice di sleep-launcher.sh è riportato in Appendice A2.
4.3.2 Lo script “job-launcher.sh”
Questo “lanciatore” differisce dal precedente, esclusivamente per il fatto che i job che è
in grado di sottomettere al batch system, non sono degli “sleep” ma dei generici script
definiti dall'utente. La sequenza di lancio è specificata in un file di testo, in cui ogni riga
è un record col seguente formato:
nome_utente tempo_di_sottomissione nome_coda nome_job
Il campo più a destra (“nome_job”) specifica il nome del job da lanciare mentre gli altri
tre campi del record hanno gli stessi significati già discussi per il precedente sleep-
launcher.sh.
4.3.4 Lo script “workload-time-updater.pl”
Questo script prende in input un file di taccia di Maui (workload) e su questo effettua un
“aggiornamento” dei valori dei seguenti campi temporali.
• QueueTime: tempo di sottomissione del job
• DispatchT: tempo di via libera all'esecuzione
• StartTime: tempo di inizio esecuzione
• CompleteT: tempo di fine esecuzione
L'aggiornamento di questi valori temporali consiste nel sommare ad ognuno un
opportuno offset temporale, tale che il minore dei tempi presenti in traccia, raggiunga lo
stesso valore del tempo corrente di sistema. Il valore dell'offset è costante e quindi
produce una traslazione in avanti delle cronologie senza alterarne l'ordine temporale. Lo
sviluppo di questo script è stato necessario per compensare quella che sembra
un'anomalia di funzionamento non ancora documentata, del simulatore di Maui.
Il codice dello script workload-time-updater.pl è riportato in appendice A3.
84
4.3.5 Lo script workload-analyzer.pl
Ogni file di traccia di Maui è una preziosa miniera di informazioni, a patto che si
disponga di un buon modo per estrarle. La traccia è pressoché illeggibile ad occhio
nudo, i campi di ogni record sono ben quarantaquattro e tutti i tempi sono espressi nello
standard Unix, ossia come numero di secondi trascorsi dal 01/01/1970 (si tratta di valori
numerici a dieci cifre!). Si moltiplichi tutto questo per migliaia o decine di migliaia di
record da esaminare simultaneamente e si avrà la misura, della necessità di uno
strumento per la manipolazione e l'analisi semplice ed efficiente di tale tipo di file.
Lo script workload-analyzer.pl è un estrattore di dati versatile, in grado di compiere
selezioni di record in base al valore assunto da uno o più campi di interesse. Allo stesso
tempo esso implementa funzioni di sorting, funzioni per la visualizzazione dell'attività
dei nodi di calcolo e per il calcolo di diversi tipi di grandezze derivate e metriche per la
valutazione del sistema. Il formalismo di invocazione dello script è il seguente:
./workload-analyzer.pl lista_opzioni nome_file_di_traccia
La specifica delle operazioni da compiere avviene da riga di comando, invocando
opportunamente le opzioni in seguito elencate.
Richiesta dello help (opzione “ --help ”):
• --help : mostra a schermo lo help dello script, relativo a tutte le funzioni implementate
in esso e la sintassi delle opzioni con cui invocarle.
Elencazione dei field della traccia Maui e di quelli derivati (opzione “ --fields ”):
• --fields : mostra a schermo la lista dei nomi di campo della traccia Maui e di altri campi
derivati da operazioni sui precedenti.
Selezione di record (opzione “--in”):
• --in field79=valore_numerico : seleziona il record se il campo indicato ha quel valore;
• --in field=[val1..val2] : seleziona il record se il valore del campo è nell'intervallo;
• --in field=valore_stringa : è l'equivalente del primo punto, per i campi di tipo stringa.
Qualora più opzioni “--in” siano presenti, il record viene selezionato soltanto se le
soddisfa tutte.
79 Col termine field si indicherà genericamente il nome di uno dei campi, che compongono il record del file
di traccia di Maui o il nome di uno dei campi che lo script può derivare dai precedenti dai precedenti.
85
Selezione di campi (opzione “--out”):
• --out field : estrae il valore del campo il cui nome è “field“ da tutti quei record che
hanno soddisfatto le opzioni “--in”. L'output dei valori avviene per righe, dove ogni riga
ha tante colonne quanti sono i campi selezionati con l'uso di opzioni “--out”.
Qualora nessuna opzione “--in” sia stata specificata, il precedente comando ritorna il
valore del campo specificato, per tutti i record del file di traccia.
Ordinamento dell'output (opzione “--numsort”):
• --numsort field : effettua il sorting dell'output sulla base dei valori di un campo
numerico.
Se il campo indicato da “field” non è già richiamato da un'opzione “–out”, esso viene
aggiunto automaticamente alla lista dei campi in output. Se “field” non è un campo
numerico, lo script ritorna un messaggio di errore.
Time-line80 dell'attività dei nodi (opzione “ --nodehistory ”):
• --nodehistory [min_index_node..max_indx_node] : produce in output una sequenza
di valori tale che, se letta dal programma di visualizzazione GNUPlot (opportunamente
configurato), questo grafica la time-line dell'attività di tutti i nodi di esecuzione nel cui
nome compaia un numero (index) compreso nell'intervallo specificato.
Quando questa funzione è invocata, tutte le altre opzioni con cui si è richiamato lo script
vengono ignorate. La descrizione del formato dell'output per GNUPlot è riportata come
commento all'interno del codice dello script.
Funzione di media aritmetica per campi di aggregazione (opzione “ --avg ”):
• --avg field_di_aggregazione : realizza la media aritmetica dei valori (ovviamente
numerici) presenti nei campi dei record selezionati in precedenza, dopo averli suddivisi
in base al valore assunto da un campo detto di aggregazione. Ad esempio la sequenza di
opzioni “--out GroupName --out ExecTime --avg GroupName”, ritorna la durata di
esecuzione media per i job di ogni gruppo presente nella traccia.
Formattazione dell'output (opzione “ --formattedout ”):
• --formattedout : restituisce l'output richiesto dall'utente, formattandolo secondo lo
standard della funzione di visualizzazione “printDumper ( ) ” del linguaggio Perl.
80 Forma di rappresentazione secondo la quale, i periodi di attività di un nodo (esecuzione del job), sono
rappresentati come segmenti di lunghezza proporzionale alla durata. Tali segmenti sono intervallati da
spazi vuoti tanto più estesi quanto più lunga è l'inattività del nodo (nessuna elaborazione di job).
86
Calcolo dell'efficienza81 del Batch system (opzione “ --efficiency ”):
--efficiency numero_CPU_sistema : determina il valore di efficienza del sistema,
relativo allo scheduling dei job presenti nella traccia esaminata.
Misura dell'equità di utilizzo del sistema (opzione “ --fields ”):
--fairness [nome_gruppo | nome utente] num_CPU_spettanti : restituisce un valore
esprimente quanto un certo gruppo (o singolo utente), ha equamente usufruito dell'uso
delle “num_CPU_spettanti” che il sistema dovrebbe garantire ad esso per l'esecuzione
dei propri job82.
Lo script opera compiendo i tre passi logici mostrat1 in Figura 4.2:
2.Manipolazionedella tabella dilavoro (sorting,calcolo medie,
calcolo metriche,ecc.)
3.Funzioni di
Stampa
54.74386
Stampa dei valoriin formato tabulare
Stampa di valoresingolo
Record del filedi traccia Maui
Aggiunta di tre campiderivati da quelli originari
Tabella di lavoro
Lettura record(uno alla volta)
Selezione record(opzione --in)
Selezione campi(opzione --out)
1. Creazione tabella di lavoro
time-line dell'attivitàdei nodi di calcolo
Figura 4.2
Le tre fasi del funzionamento dello script workload-analyzer.pl
81 Il concetto di “efficienza di un batch system” e la relativa metrica di calcolo saranno discussi nel capitolo
sesto.
82 Il concetto di “fruizione equa di CPU spettanti” e la relativa metrica di calcolo saranno discussi nel
capitolo sesto.
87
1. Generazione di una tabella di lavoro con i valori selezionati dalla traccia: dal file di
traccia viene letto un record alla volta, e vi si aggiungono tre campi83 opportunamente
derivati da quelli già presenti in traccia. Il record così ampliato, viene selezionato se
soddisfa tutte le condizioni specificate dalle opzioni “--in”, altrimenti scartato. Se
accettato si selezionano da esso i soli valori specificati dalle opzioni “--out”. Questi
valori vengono quindi raccolti in una struttura dati tabellare per la successiva fase di
elaborazione.
2. Elaborazione della tabella in accordo alle richieste dell'utente: se l'utente ha
richiesto un'operazione di pura selezione di record, lo stato dei dati in tabella si dice
pre-stampa e si passa alla fase successiva. Se invece la tabella deve essere elaborata con
operazioni specificate dall'utente (ordinamento dei record in base ad un campo
numerico, calcolo di “medie aggregate”, calcolo dei valori di metrica, ecc.), ogni
operazione richiesta viene eseguita secondo un ordine determinato, portando così la
tabella di lavoro in stato pre-stampa.
3. Stampa del contenuto finale della tabella: A questo punto i dati in tabella sono
compatibili con almeno una delle tre funzioni di stampa principali:
• Stampa di valore singolo (per l'opzione –efficiency o --fairness);
• Stampa di dati in formato GNUPlot compatibile (per l'opzione --nodehistory);
• Stampa in forma tabulare della tabella di lavoro (per tutte le altre opzioni).
La stampa con output formattato (oopzione --formattedout) è una variante della
precedente.
Ovviamente le tre fasi si articolano in un insieme di funzioni e strutture impossibili da
approfondire in questa sede. Per la comprensione dei dettagli dell'implementazione si
rinvia il lettore interessato, alla consultazione dell'Appendice A4 dove è riportato il
codice (commentato) dello script workload-analyzer.pl.
83 I campi aggiunti sono: “StayInQueueT” (tempo di permanenza in coda di un job); “ExecTime” (durata
dell'esecuzione di un job), “OverallTime” (tempo trascorso dall'accodamento del job al completamento
dell'esecuzione). Su di esse sono possibili le stesse operazioni di selezione e computazione applicabili ai
field nativi della traccia.
88
4.3.5.1 Complessità temporale di workload-analyzer.pl
La mole di dati che questo script deve poter processare giustifica un breve cenno ai
propri valori di complessità temporale84 in funzione delle dimensioni dell'input.
• Fase “1”. Lo script scandisce sequenzialmente il file di traccia per selezionare i record
d'interesse. Essendo tale operazione svolta in una sola passata il costo computazionale
della costruzione della tabella intermedia è θ(n). Relativamente all'occupazione della
memoria notiamo che l'esame di un record alla volta (letto dal file di traccia) permette
un'occupazione di memoria relativa alle sole dimensioni della tabella di lavoro prodotta,
cioè O(n) nel caso pessimo (l'intera traccia di input è selezionata). Siccome le
successive due fasi non affiancano ulteriori strutture dati di rilievo alla tabella di lavoro,
ma continuano ad operare su di essa, è legittimo assumere per l'intero script
un'occupazione O(n) della memoria.
• Fase “2”. Ogni operazione eseguibile sulla tabella ha un suo costo computazionale:
➢ --numsort , --nodehistory : O(n * log n);
➢ --efficiency, --fairness : θ(n2);
➢ tutte le altre funzioni : O(n).
• Fase “3”. Ognuna delle funzioni di stampa ha complessità temporale O(n).
Componendo le complessità delle tre fasi si ha quindi che, a seconda delle operazioni
richieste, la complessità totale dello script varia da O(n) a θ(n2), passando per O(n * log n).
La complessità delle funzioni --efficiency e –fairness (quando eseguite) rappresenta un
collo di bottiglia per le prestazioni complessive dello script. Al momento in cui si
scrive è stata da poco dimostrata la possibilità di una riduzione ad O(n * log n) per
queste funzioni. Una realizzazione riguarderà già la prossima versione dello script.
84 Per complessità temporale di un algoritmo, si intende la valutazione formale di come il tempo di calcolo
cresce, in funzione delle dimensioni dei suo input. Nel caso specifico tali dimensioni saranno
riconducibili al numero “n” di record che costituiscono il file di traccia. Il simbolismo utilizzato sarà dato
dalle usuali espressioni θ(f(n)) oppure O(f(n)) dette “teta” ed “o grande” di f(n). La prima significa che il
costo computazionale di una certa operazione cresce asintoticamente ad f(n), la seconda che “al peggio” il
costo può crescere asintoticamente ad f(n) (“o grande” esprime un limite superiore che non
necessariamente viene raggiunto). f(n) è un qualsiasi polinomio in “n”. Casi di esempio possono essere
complessità temporali θ(n) od O(n2) indicanti rispettivamente che i tempi di elaborazione, crescono
linearmente con le dimensioni “n” dell'input (primo esempio) oppure crescono col quadrato delle
dimensioni dell'input, ma solo nel caso pessimo (secondo esempio). La stessa simbologia può essere
estesa anche al caso di occupazione della memoria,riguardo le strutture dati usate dall'algoritmo. In tal
caso non si parlerà più di complessità temporale ma di “occupazione della memoria, in funzione delle
dimensioni dell'input”.
89
4.4 Tool di automazione evoluta
Contrariamente a quanto avviene per i tool di base, i tre script che compongono questo
pacchetto software non sono tra loro indipendenti. Il loro sviluppo è stato, fin dall'inizio,
orientato alla creazione di una infrastruttura di automazione e standardizzazione, delle
operazioni di simulazione delle tracce di Maui e dell'esecuzione pianificata di job nel
batch system di test85. I rapporti tra i suddetti script sono di tipo gerarchico, strutturato
su due livelli:
• coordinazione (script: “run.sh”);
• esecuzione (script: “simulate.sh”, ”launch.sh”).
La descrizione delle caratteristiche degli script di automazione e delle relative
funzionalità, partirà dal livello gerarchico più basso, quello di “esecuzione”, per passare
poi al livello “coordinazione” fino alla presentazione del quadro di un più ampio ed
articolato contesto futuro, verso cui questa infrastruttura di automazione, è destinata ad
evolvere.
4.4.1 Necessità di automazione
La creazione di strumenti di automazione per le operazioni di simulazione o
sottomissione di job al batch system di test (compreso il relativo recupero dei risultati
di esecuzione), si è resa necessaria, data l'inadeguatezza di un approccio manuale ed
interattivo all'esecuzione ripetuta di queste due attività.
Simulazione
Il simulatore di Maui richiede per ogni sua esecuzione la disponibilità di tre diversi file
di testo.
• Un file di traccia (workload trace): è il file che un batch system Maui compila durante
il suo funzionamento ordinario per tenere memoria dell'attività di scheduling prodotta
dalle policy impostate, sui job sottomessi al sistema dagli utenti. Questo file, frutto di
uno scheduling realmente avvenuto, è usato come un carico di lavoro virtuale sul quale
il simulatore di Maui può ipotizzare nuove decisioni di scheduling sulla base di nuove
policy impostate.
85 Come si ricorderà dalle pagine precedenti, il mini-cluster allestito per il test di validazione consta di un
nodo su cui gira il simulatore di Maui (test-simulator) e di un batch system TORQUE + Maui di cinque
nodi. Le due componenti sono logicamente isolate. Le operazioni di “simulazione” ed “esecuzione reale”
trattate in queste pagine, si intendono ogni volta riferite alla componente pertinente. Senza rischio di
ambiguità quindi, parlando di “simulazione” sarà sempre sottinteso che si è nel contesto del nodo di
simulazione, parlando di “esecuzione reale” il contesto sarà quello del batch system di test a cinque nodi.
90
• Un file di descrizione del sistema: questo file specifica, secondo un formalismo
standard per Maui, la configurazione hardware del batch system per il quale si esegue la
simulazione.
• Il file di configurazione dello scheduler “maui.cfg”: è il file che contiene tutti i
settaggi operativi del simulatore (o del batch system reale), compreso l'insieme delle
policy decise per lo scheduler.
Questi tre file debbono tutti essere copiati nella cartella che il simulatore usa come sua
directory di lavoro e vanno manualmente aggiornati o modificati prima dell'avvio di
ogni simulazione. Il risultato della simulazione confluisce poi, in un ulteriore file di
traccia Maui (simulated workload trace) e deve essere portato fuori dalla cartella di
lavoro del simulatore, prima che sia sovrascritto dalla simulazione successiva.
La gestione diretta e ripetuta di questa fase preparatoria da parte dell'utente, comporta
non solo un lavoro monotono ma presta il fianco a molteplici occasioni di errore, nel
caso in cui il numero di simulazioni da effettuare sia elevato.
Esecuzione reale
Ai fini delle prove di validazione, un lavoro di preparazione analogo a quello che
precede una simulazione, deve essere compiuto anche prima del lancio di una sequenza
di job86 sul batch system di test. In questo caso la sottomissione dei job avviene su un
sistema TORQUE + Maui reale e quindi l'unico file da preparare (con le opportune
policy) è “maui.cfg”. Come in precedenza invece, il file di traccia prodotto dallo
scheduling dei job (real workload trace), deve essere spostato verso una destinazione
consona al suo futuro utilizzo. Gli svantaggi della gestione manuale della preparazione
del sistema all'esecuzione di sequenze di job, sono dunque analoghi a quelli visti per le
operazioni di simulazione.
Prima di procedere oltre, notiamo in riferimento al file “maui.cfg”, che sia lo si
impieghi nelle simulazioni sia nelle esecuzioni reali, le modifiche a cui è interessato
riguardano soltanto una parte molto limitata di esso, quella in cui sono specificate le
policy di scheduling. Questa constatazione suggerisce l'opportunità di dividere detto file
di configurazione in due parti.
• Head (testa): l'insieme immutabile dei settaggi e delle dichiarazioni comuni a tutte le
operazioni.
• Tail (coda): l'isieme delle policy specifiche, decise per un dato obbiettivo di scheduling.
86 Il lancio di una sequenza di job, nell'ambito dei test di validazione effettuati, è finalizzato alla produzione,
di un file di traccia reale da usare come input del programma di simulazione.
91
Data questa separazione il file “maui.cfg” sarà riottenibile come concatenazione di una
“head”, che potremmo dire standard, ed un opportuna “tail”. L'utilità di questa
separazione è evidente. La possibilità di specificare le policy di interesse in una “tail”
semplice e concisa, agevola possibili generazioni automatiche della stessa e previene
deleterie modifiche accidentali delle impostazioni “generali” del file di configurazione.
Nei prossimi due paragrafi, ci si mostrerà come lo sviluppo dei due script “simulate.sh”
e “launch.sh”, abbia permesso di velocizzare, standardizzare e rendere sicure le
sequenze di operazioni attinenti a simulazioni e lanci dei job di test.
4.4.2 Script di simulazione automatica “simulate.sh”
Questo script prende in input una qualsiasi cartella utente del nodo di simulazione
(test-simulator) nella quale devono essere presenti presenti:
• un file di traccia Maui dato da una esecuzione reale (workload-real-unscaled87);
• il file con la conformazione hardware del sistema da simulare;
• la parte “tail” di un file di configurazione “maui.cfg”.
Lo script opera in modo ciclico secondo le tre fasi riportate nella seguente Figura 4.3.
Simulatoredi Maui
Cartella Utente
Cartella di lavoro simulatore
simul.sh
1.Preparazione
2.Avvio
simulazione
3.Recupero
simulazione
Nodo test-simulator
Figura 4.3
Flusso di esecuzione dello script “simulate.sh” riportante le tre fasi che realizzano l'automazione dell'operazione di simulazione di un file di traccia Maui.
87 In base al formalismo adottato, “workload-real-unscaled” è il nome scelto per il file di traccia Maui
“originario” al cui interno i tempi riportati sono quelli risalenti all'esecuzione reale.
92
1. Preparazione: durante questa fase lo script si occupa di verificare che il contenuto della
cartella passata sia effettivamente l'insieme dei tre file sopra elencati. Se è così, tutto il
contenuto della cartella utente, viene copiato nella cartella di lavoro che Maui usa per la
simulazione88 ed il file “maui.cfg”, ricostruito aggiungendo la “head” standard alla
“tail” presente. A questo punto lo script provvede ad invocare uno dei tool di base, lo
script workload-time-updater.pl per traslare in avanti tutti i tempi presenti in traccia di
un opportuno offset temporale89: il file di traccia “workload-real-unscaled” viene
convertito in ”workload-real-scaled”.
2. Avvio simulazione: terminata la fase preparatoria lo script di automazione avvia la il
simulatore di Maui, il quale produce un ulteriore file di traccia contenete i dati simulati.
Durante la simulazione lo script resta in attesa per riattivarsi al termine di questa.
3. Recupero simulazione: il file di traccia prodotto dal simulatore è rinominato come
”workload-simul-scaled”. Di esso viene realizzata una variante in cui i tempi presenti
sono scalati, stavolta all'indietro, dello stesso offset temporale di cui al punto 1,
restituendo alla traccia simulata coerenza temporale con la traccia originaria. Conclusa
questa operazione, tutte le tracce vengono copiate nella cartella utente da cui
l'automatismo di simulazione aveva tratto avvio. La cartella di lavoro del simulatore di
Maui viene ripulita dai i file sopra menzionati e riportata al suo stato iniziale
(antecedente alla simulazione).
Con riferimento alla Figura 4.3, le frecce indicano non solo il susseguirsi delle tre fasi
appena descritte ma anche il percorso logico che la traccia reale segue prima di ritornare
alla cartella di partenza, come traccia simulata. In particolare le frecce di colore blu
indicano le manipolazioni ed i trasferimenti del file di traccia, compiute dallo script di
automazione, mentre quelle gialle le operazioni eseguite sulla traccia dal programma
simulatore di Maui.
Il valore aggiunto di questo tipo di automazione è evidente. L'utente che richieda una
simulazione non è più costretto a gestire manualmente l'allestimento della cartella di
lavoro del simulatore, ne ad apportare modifiche all'intero file di configurazione di
Maui. Questi deve semplicemente creare una cartella nel nodo di simulazione ed ivi
inserire i tre file elencati all'inizio di questo paragrafo. Lo script “simulate.sh” riceve
tale cartella e provvede al resto, rendendo il processo di simulazione semplice e
trasparente.
88 La cartella di lavoro del simulatore, è specificata nella parte “head” del file di configurazione “maui.cfg”.
89 Questa operazione, per eseguire la quale si è realizzato l'apposito tool “workload-time-updater.pl”, serve a
correggere un'anomalia del simulatore di Maui riscontrata nel corso di questo lavoro. Tale anomalia verrà
descritta in dettaglio nel prossimo capitolo. Per il momento si assuma quindi che la pratica di traslazione
dei tempi delle tracce reali, sia semplicemente necessaria alla corretta simulazione della traccia stessa.
93
4.4.3 Script di esecuzione automatica “launch.sh”
Lo script di esecuzione automatica “launch.sh” opera in maniera logicamente identica al
precedente ma stavolta l'automazione riguarda la sottomissione di una sequenza di job
ad un batch system TORQUE + Maui ed il recupero del file di traccia prodotto dal
sistema, ad esecuzione avvenuta. Lo script prende in input una qualsiasi cartella utente
del nodo central manager del batch system (nodo “test-master”), nella quale devono
essere presenti:
• un file contenente una sequenza di lancio di “sleep” o job basati su script, espressa
secondo il formalismo già descritto nei paragrafi 4.3.2 e 4.2.3;
• la parte “tail” di un file di configurazione “maui.cfg”.
Lo script opera in modo ciclico secondo le tre fasi riportate nella seguente Figura 4.4.
Cartella Utente /usr/local/maui/stats
2.Recupero traccia
Batch Systemdi test
launch.sh
1.Sottomissione
di job
Scritturafile di traccia
Nodo test-master
Figura 4.4
Flusso di esecuzione dello script “launch.sh” riportante le due fasi che realizzano l'automazione dell'operazione di sottomissione di job di test in un batch sistem TORQUE + Maui.
1. Sottomissione jobs: durante questa fase si controlla che la cartella utente contenga
i due file sopra elencati. Se presenti lo script procede alla ricostruzione del file
“maui.cfg” ed al trasferimento di questo nella home directory di Maui. Lo
scheduler viene quindi avviato e richiamando il tool di base “real-laucher.sh” tutti i
job specificati nella lista di lancio vengono sottomessi al batch system ai tempi
specificati nella lista stessa. Lo script attende quindi il completamento
dell'esecuzione di tutti i job sottomessi.
94
2. Recupero traccia: ad esecuzione avvenuta, Maui completa la scrittura del suo file
di traccia nella cartella di sistema “/usr/local/maui/stats”. Lo script riprende la
propria azione arrestando lo scheduler (sopprime il demone di Maui), rinominando
il file di traccia prodotto col nome di “workload-real-unscaled” e trasferendolo
nella cartella utente di partenza, assieme al file di descrizione delle risorse
hardware del batch system90. La cartella “/usr/local/maui/stats” viene ripulita,
ripristinando la situazione antecedente alla all'esecuzione dei job di test.
Con riferimento alla Figura 4.4, le frecce blu indicano nuovamente le operazioni
svolte dallo script di automazione “launch.sh” mentre la freccia gialla le operazioni
di scrittura del file di traccia svolte automaticamente da Maui.
L'utilità di questo tool non risiede soltanto nel fatto di rendere semplice e trasparente la
sottomissione di sequenze di job di test al sistema ma anche nel produrre per ogni
esecuzione reale un output conforme alle specifiche di input dello script “simulate.sh”.
Questo significa che relativamente ad esperimenti che lo richiedano, l'esecuzione dei
due script può essere concatenata.
4.4.4 Il livello superiore: lo script “run.sh”
Questo script costituisce il livello alto della gerarchia di automazione che si sta
descrivendo. Esso vede i due precedenti script come strumenti che possono essere
richiamati un numero arbitrario di volte, al fine di produrre non una singola simulazione
od una singola esecuzione reale ma delle serie di queste.
Lo script “run.sh” ha caratteristiche polimorfe, nel senso che è concepito come uno
strumento multi-valente ed in grado di eseguire diverse funzioni di alto livello, inerenti
la generazione, la simulazione e l'esame di tracce Maui. Relativamente al presente
lavoro di tesi, verrà considerata la sola funzione di simulazione enumerativa91.
Questa funzione trae origine dalla necessità di poter valutare, in fase di simulazione, i
cambiamenti prodotti sull'ordine di scheduling dei job, dalla variazione mirata di alcuni
parametri di configurazione. Una formulazione più rigorosa del problema è la seguente.
90 La produzione di questo file avviene a run-time invocando un apposito comando di Maui.
91 Le restanti funzioni rappresentano strumenti di automazione evoluti, appartenenti ad un contesto più
ampio di quello corrente ed ancora in fase di sviluppo. Le feature che implementano vanno oltre gli
obbiettivi che questo studio si prefigge e la loro trattazione non affiancherà quella della simulazione
enumerativa. Il loro scopo è comunque attinente alle tematiche affrontate in nel presente lavoro e pertanto
una sintetica descrizione sarà fornita nel prossimo paragrafo.
95
Dato un certo numero di parametri di policy di Maui92 (al limite uno solo), si vogliono valutare
gli effetti, che la variazione dei valori di questi parametri entro limiti prestabiliti, produce
sull'ordine di scheduling, ottenuto simulando una traccia reale. Si assume in particolare che la
variazione dei valori dei parametri, i quali saranno indicati con lettere maiuscole A, B, C, ecc.,
avverrà nei rispettivi intervalli di interi [a1..an1], [b1..n2], [c1..cn3], ecc.
La funzione di simulazione enumerativa opera sulla base di tre passaggi logici.
1. Genera tanti “tail” di file di configurazione “maui.cfg” quante sono le possibili
configurazioni ottenibili per un insieme di parametri di policy, al variare dei rispettivi
valori negli intervalli specificati. In ogni file “tail”, i parametri sono settati con una
diversa permutazione dei valori in questione.
2. Ogni “tail” viene copiata in una cartella appositamente creata (il cui nome è reso
significativo da una definita regola di nomenclatura), assieme al file di conformazione
hardware del sistema ed una traccia di esecuzione reale di interesse.
3. Le cartelle così allestite rispettano il formalismo necessario perché lo script del livello
inferiore “simulate.sh”, possa operare la simulazione come descritto nelle pagine
precedenti. Detto script è quindi invocato per ognuna delle cartelle.
La lista dei parametri di policy da variare ed i rispettivi intervalli di valori, sono
specificati in input allo script “run.sh” (così come il file contenente la descrizione delle
risorse hardware ed il file di traccia da simulare), attraverso uno speciale file di
configurazione chiamato “run.cfg”.
Il meccanismo in esame esegue dunque un'enumerazione di simulazioni (da qui il
nome), su intervalli di valori che si vogliono testare per un dato insieme di parametri di
policy. Una forma di rappresentazione di questa attività, relativa al caso elementare in
cui un solo parametro venga simulato dell'intervallo di valori [a1..a6], potrebbe essere la
seguente:
. . . . . . a1 a2 a3 a4 a5 a6
Ogni punto rappresenta una simulazione effettuata col parametro di policy settato al
valore “ai”. Nel caso invece di due parametri, ad esempio A e B, varianti rispettivamente
negli intervalli [a1..a6] e [b1..b3] la rappresentazione introdotta in precedenza
prenderebbe la forma:
92 Si ricordi che in Maui la quasi totalità delle policy è definibile semplicemente affiancando al nome di una
componente (o sub-componente) di priorità, un valore numerico esprimente il peso che questa apporterà
ai job interessati, all'atto del calcolo delle rispettive priorità di esecuzione. La formulazione di policy
basate su attribuzione di “pesi” di priorità è descritta nel paragrafo “3.2.3 Priorità di esecuzione”.
96
b3 . . . . . . b2 . . . . . . b1 . . . . . .
a1 a2 a3 a4 a5 a6
Dove stavolta ogni punto rappresenta una simulazione in cui il parametro di policy A è
settato al valore ai ed il parametro B è settato al valore “bi”. L'utilità di questo tipo di
rappresentazione93 sarà mostrata nel prossimo capitolo, relativamente ad una delle prove
di validazione del simulatore, per la quale la funzione di simulazione enumerativa è
stata impiegata.
Per quantificare il numero di simulazioni che vengono eseguite, dato un insieme di n
parametri ed i relativi intervalli di variazione, si considera ogni intervallo come
l'insieme dei valori che lo compongono, in modo da poter scrivere:
NumSimul = cardinalità ([a1..ana]) * · · · * cardinalità ([z1..znz] )
o più sinteticamente:
NumSimul=∏j=1
n
cardinalità [valore1j ,..valorenj ] j
dove n indica il numero dei parametri variabili e valoreij il generico elemento
dell'intervallo di variazione del parametro j.
Come si intuisce il numero di simulazioni cresce molto rapidamente all'aumentare dei
parametri di policy, che si sceglie di simulare contemporaneamente, e delle dimensione
dei rispettivi intervalli dai variazione. Questa crescita pone un limite superiore al
numero di parametri esaminabili in modo “incrociato”, limite che dipende dalla potenza
di calcolo della macchina fisica che ospita il simulatore di Maui94 o dal tempo che si è
disposti ad attendere.
93 Un'estensione di questa forma di rappresentazione al caso di simulazioni su tre o più parametri varianti
non è considerata necessaria, visto che nel prosieguo il meccanismo verrà applicato al più al caso di due
soli parametri di policy varianti simultaneamente.
94 Al fine di ridurre il numero di simulazioni o non scendere in livelli di dettaglio eccessivi, lo script è in
grado di operare anche solo su un sottoinsieme dei valori di un intervallo. Il sottoinsieme è determinato
in base ad un parametro detto granularità di enumerazione. Ad esempio in caso di granularità pari ad “1”,
tutti e dieci i valori dell'intervallo [1..10] saranno simulati (caso standard), in caso di granularità “3” solo i
valori 1, 4, 7, 10 saranno considerati.
97
Senza spingersi così avanti comunque, si consideri che questo meccanismo produce i
risultati migliori, in quanto leggibilità e semplicità di interpretazione, al variare di uno o
al massimo due parametri contemporaneamente. Nel prosieguo non si andrà oltre questa
soglia.
I vantaggi introdotti dalla funzione appena descritta sono ancora una volta quelli già
visti al livello inferiore di questa infrastruttura, con in più l'eliminazione dell'interazione
uomo-macchina, relativa all'attesa del termine di una simulazione e l'avvio manuale
della successiva. Al termine dell'esecuzione dello script inoltre, la serie delle
simulazioni è ripartita in un insieme ordinato di cartelle, accomunate da una specifica
nomenclatura, dalle quali l'utente può estrarre agevolmente tutte le informazioni di
interesse.
4.4.5 Funzioni avanzate di “run.sh”
Due ulteriori funzioni, ancora in fase di sviluppo, costituiscono lo script “run.sh”. Di
queste si riporterà una descrizione molto concisa allo scopo di dare una prospettiva di
sviluppo del progetto di ricerca complessivo, del quale il presente lavoro di tesi
costituisce la fase embrionale.
Validazione con metodo montecarlo del simulatore di Maui
Questa funzione mira a fornire una misura quantitativa dell'attendibilità del simulatore
di Maui, relativamente alla simulazione delle varie policy di scheduling possibili. Essa
si basa sulla possibilità di concatenare l'output di “launch.sh” con l'input di
“simulate.sh”. L'algoritmo opera iterando quattro fasi:
1. Genera casualmente ed inserisce in una cartella:
• una sequenza di lancio di job;• una “tail” di “maui.cfg”;• un file con la descrizione delle risorse del sistema.
2. Esegue sulla cartella: “launch.sh”.
3. Esegue sulla cartella: “simulate.sh”.
4. Confronta la traccia reale con quella simulata, valutando secondo opportune metriche, il
grado di fedeltà della simulazione.
La dimensione quantitativa della validazione deriva dal presupposto che, a parità di
configurazione di scheduling e sistema, i valori determinati da opportune metriche di
valutazione per traccia reale e simulata, devono essere tanto più simili quanto corretta è
l'attività del simulatore.
98
Algoritmo genetico per la ricerca di configurazioni di scheduling efficienti
Questa funzione vuole fornire un meccanismo, per la ricerca delle policy più adatte allo
scheduling di determinate sequenze e tipologie di job, che possono presentarsi ad un
batch system. Essa si basa su tecniche proprie degli algoritmi genetici e la sua linea di
funzionamento è riportata sotto.
1. Genera casualmente una “popolazione” i cui individui siano “tail” di “maui.cfg”.
2. Genera il corrispondente insieme di cartelle, ognuna delle quali contiene :
• una traccia Maui reale (di cui si cerca una configurazione di policy ottimali)• una delle “tail” precedentemente generate;• un file con la descrizione delle risorse del sistema.
3. Simula ogni cartella.
4. Applica un opportuno algoritmo di fitness la “tail” le cui policy anno prodotto i risultati
migliori.
5. Applica alle “tail” selezionate le operazioni tipiche dell'algoritmica genetica
(mutazione, incrocio, ecc.) per ottenere una nuova popolazione da testare e ricomincia
dal punto 2.
99
100
Capitolo 5
VALIDAZIONE DEL SIMULATORE
5.1 Validazione
Il simulatore di un determinato fenomeno o sistema reale, è solitamente un software che
implementa uno o più modelli matematici, atti a descrivere l'evoluzione nel tempo del
fenomeno o del sistema stesso, a partire da uno stato iniziale noto. Ogni modello
riproduce in maniera semplificata, una specifica legge o meccanismo attinente
“l'oggetto fisico” in questione ed a priori non è possibile affermare, che tutti i modelli
implementati, abbiano lo stesso grado di accuratezza nell'approssimare il rispettivo
comportamento reale. Un simulatore potrebbe dunque essere uno strumento valido in
certi casi e fornire risultati meno attendibili in altri. Da qui la necessità, che la verifica di
validazione coinvolga il maggior numero possibile di ambiti, eseguendo prove
sull'utilizzo di ognuno dei modelli di previsione implementati e sulle possibili
applicazioni congiunte di questi.
Il simulatore di Maui riconosce e riproduce tutte le possibili policy applicabili allo
scheduler reale e qualora si volesse fornire una validazione a tutto tondo dello
strumento, questo si tradurrebbe nella necessità di verificare un numero di contesti di
simulazione incredibilmente elevato.
La fase successiva al lavoro preparatorio consiste nella simulazione di tracce reali
provenienti dalla farm INFN di Perugia. Lo scopo è ottenere previsioni sugli effetti che
una specifica politica di scheduling, avrà sul batch system stesso. Il perseguimento di
questo obbiettivo, comporta una semplificazione notevolissima del lavoro di
validazione, permettendo di concentrare l'indagine di attendibilità del simulatore, su di
un contesto operativo molto localizzato.
La validazione del simulatore avverrà quindi, limitatamente al solo ambito
dell'esperimento che verrà condotto, valutando l'accuratezza della simulazione in base
ad un criterio di verosimiglianza ritenuto adeguato allo scopo. I contesti di simulazione
da vagliare, saranno detti d'ora in avanti obbiettivi di validazione. Non verranno
compiuti test sul comportamento del simulatore, riguardo strategie di scheduling diverse
da quelle d'interesse.
101
5.1.1 Obbiettivi di validazione
La conclusione del capitolo secondo, in cui si è descritto il batch system del sito INFN
di Perugia, è coincisa con la formulazione del problema di ottimizzazione ad esso
relativo. Come anticipato, una possibile soluzione, data da una certa politica di
scheduling, sarà vagliata nel prossimo futuro, ricorrendo alla simulazione dei dati
provenienti dai file di traccia della farm INFN. La politica in questione è realizzata
tramite l'uso di una specifica tipologia di policy di Maui, già introdotta parlando di
fairness95:
➢ la restrizione delle allocazioni con limiti di tipo variabile (“soft & hard limits”);
Data la premessa, risulta quindi evidente che almeno uno degli obbiettivi di validazione,
riguardi la corretta attuazione da parte del simulatore, della politica appena citata. Non
solo, affinché questa policy di fairness possa essere utilizzata, è necessario che la
rispettiva componente (e le sub-componenti) del sistema di attribuzione della priorità sia
attivata. La validazione quindi, non può prescindere dal verificare che il simulatore sia
in grado di riprodurre correttamente, il meccanismo di:
➢ priorità di esecuzione.
Per concludere si consideri che i due obbiettivi finora considerati, sono subordinati ad
una adeguata simulazione di azioni più basilari come:
➢ schedulare correttamente i job, indipendentemente dalla loro durata o provenienza
(sottomissione da parte di utenti o gruppi diversi, su code diverse, ecc.)
➢ schedulare le esecuzioni senza compiere errori logici (perdita di job, inutilizzo di nodi
fruibili, incoerenze cronologiche, produzione di paradossi nella traccia simulata, ecc).
I punti elencati rappresentano quello che potremmo definire come:
l'insieme minimo degli obbiettivi di validazione del simulatore di Maui, limitatamente
alla simulazione della sola politica di fairness citata.
Ognuno dei precedenti punti, sarà testato con specifici esperimenti per verificare se il
criterio di verosimiglianza scelto è rispettato. L'ordine di conduzione dei test sarà inoltre
invertito rispetto a quello di elencazione precedente, in modo che la verifica proceda
dagli aspetti più generali verso quelli di maggior specificità.
95 Si vedano il paragrafo “3.2.5 Maui fairness” ed i successivi.
102
5.1.2 Modalità di validazione
La modalità di validazione di un simulatore, è fortemente dipendente dalla natura del
fenomeno reale che esso riproduce. Nel caso in questione il simulatore imita il
comportamento di un batch system, una realtà che come si è visto è molto complessa
nonché fortemente dipendente dai dati in ingresso. Tale natura eterogenea e mutevole
del fenomeno “scheduling”, non consente ad esempio di eseguire la verifica del relativo
simulatore, usando le due tecniche più potenti e generali: la validazione induttiva96 e la
validazione per conformità a distribuzioni di riferimento97. Allo scopo invece ben si
adattano due procedure meno potenti ma comunque efficaci: la validazione di tipo black
box e quella basata sulla conferma di previsioni.
• Black box: il simulatore è trattato come una scatola nera ed il suo funzionamento
interno considerato inessenziale. La validazione consiste nel sottomettere al simulatore
lo stesso contenuto informativo, che nel dispositivo reale ha prodotto un certo output,
assunto come campione. Dal confronto tra l'output del simulatore ed il campione si
valuta l'accuratezza (e quindi l'accettabilità o meno) della simulazione.
• Conferma di previsioni: si tratta di dedurre, partendo da assunzioni plausibili, la
risposta che un simulatore privo di errori produrrebbe da un determinato input. Dal
confronto tra la previsione e l'output del simulatore si decide la validità dello strumento.
L'applicazione della prima tecnica al simulatore di Maui avviene come segue.
1. Job con opportune caratteristiche, vengono sottomessi al batch system di test. La loro
esecuzione, in accordo alle politiche impostate, produce la traccia dello scheduling
operato.
2. La traccia è quindi sottoposta al simulatore, configurato con le stesse politiche del
sistema reale. Questo ne ricava la sequenza dei job originale e simula per essa un suo
ordine di scheduling (che confluirà in un ulteriore file di traccia Maui).
3. La stessa configurazione delle policy in entrambi i casi, deve comportare una
“coerenza” tra la prima traccia (il campione) e la seconda. Tale coerenza è quindi
valutata, applicando il criterio di verosimiglianza scelto.
96 Secondo questa tecnica di validazione, si testa il simulatore per casi elementari e, sfruttando la presenza
di un “passo induttivo”, si estende la validazione anche ai casi di maggiore complessità. Ovviamente i
casi simulabili debbono rappresentare una successione logica ed il passo induttivo esprimere una
proprietà immutabile che lega ogni caso al successivo.
97 E' la tipica forma di validazione riservata, tra gli altri, ai generatori di numeri casuali. Essa consiste nel
verificare se la distribuzione dei valori di output del simulatore, ricalca entro margini accettabili la
distribuzione di valori (teorica o sperimentalmente determinata) propria del fenomeno simulato.
103
In riferimento alla seconda tecnica si procede in modo abbastanza simile.
1. Si produce un'opportuna traccia reale da usare come carico di lavoro.
2. Si effettua una previsione sullo scheduling che verrà operato dal simulatore, sulla base
delle policy con cui è correntemente configurato.
3. Si confronta la traccia prodotta con la previsione, valutando la bontà della simulazione
in base del criterio di verosimiglianza scelto.
Il pregio di queste due tecniche, è quello di poter essere applicate con facilità, anche in
contesti di validazione “difficili”, in cui la casistica delle simulazioni è caratterizzata
dall'assenza di legami (o dipendenze) tra i vari casi e dall'impossibilità di individuare
distribuzioni di riferimento, a cui l'output dovrebbe ricondursi. Questa versatilità si paga
però su un altro fronte: la verifica prodotta è piuttosto contingente alla specifica prova
effettuata. La solidità della validazione viene quindi a dipendere dal numero dei test
condotti e dall'ampiezza di spettro delle configurazioni vagliate. Contestualmente al
presente lavoro, il numero delle prove effettuate sarà comunque minimo, giacché si è
scelto di privilegiare, l'aspetto della messa in esercizio della struttura di validazione,
piuttosto che il suo uso sistematico. Il superamento di tale limite “quantitativo”, rientra
invece tra gli obbiettivi dei lavori che seguiranno.
5.1.3 Tipo di job usati per le esecuzioni reali
In accordo al tipo di validazione appena presentato, si ha dunque la necessità di
produrre tracce reali dall'esecuzione di job. La cosa è in se abbastanza semplice, in
quanto basta sottomettere al batch system, dei job i cui tempi di durata e di
accodamento siano consoni al tipo di esperimento che si vuole condurre. Ma quale tipo
di job utilizzare? Il migliori candidati a questo scopo sono i job di tipo sleep.
Lo sleep è un comando dei sistemi Linux/Unix che sospende per un tempo specificato,
il flusso di esecuzione nel sistema in cui viene invocato. Anche se la sua attività è
letteralmente quella di “non fare niente”, se sottomesso al batch system di test, esso è
visto dallo scheduler come un qualsiasi altro job98, col vantaggio però di occupare il
nodo di calcolo che lo esegue, per un tempo noto a priori. La forzatura che sembra
98 Questo è possibile in quanto il batch system di test vede i propri nodi di calcolo, configurati in modalità
“non time-shared” in base alla quale, ogni nodo può eseguire un solo job alla volta. Un job sleep infatti
assorbe una porzione infinitesimale della potenza di calcolo di una CPU e se i nodi di calcolo fossero
configurati in modalità “time-shared” una sola cpu potrebbe in teoria processare tutti i job sleep
sottomessi al sistema dedicando una porzione del proprio tempo ad ognuno. Ciò vanificherebbe la tecnica
che si è scelta, per produrre agevolmente file di traccia dall'esecuzione di job reali.
104
accompagnare questa tecnica è soltanto apparente. Le informazioni temporali che il
simulatore ricava dalla traccia reale, sottoposta come carico di lavoro, riguardano solo i
tempi di accodamento dei job e le durate di esecuzione. Per esso quindi non fa alcuna
differenza se un certo tempo di computazione, sia consistito nel calcolo di un numero
primo, di una costante fisica o semplicemente in “ozio” del processore99.
5.1.4 Criterio di verosimiglianza
Individuato l'insieme degli obbiettivi di validazione e le modalità di indagine
appropriate, non resta che definire il criterio per stabilire, se il prodotto di una
simulazione riproduce adeguatamente la realtà. In sostanza si tratta di fissare una soglia,
rispetto alla quale discernere se l'approssimazione introdotta (inevitabilmente) dalla
simulazione, è compatibile con le necessità per le quali l'uso del simulatore è richiesto.
Date alcune caratteristiche del simulatore di Maui che presto saranno descritte, e gli
obbiettivi legati al suo utilizzo futuro, si è scelto di posizionare tale soglia ad un livello
medio, concentrando la verifica di correttezza su aspetti più qualitativi che quantitativi.
Il criterio di verosimiglianza per la validazione di tipo black box, stabilisce quindi che la
simulazione di un file di traccia Maui è corretta se:
1. nella traccia generata non vi sono incoerenze logiche 100;
2. l'ordine di scheduling simulato è identico o compatibile a quello della traccia reale ;
3. l'ordine di allocazione dei nodi simulato è identico o compatibile con quello della
traccia reale101.
Ai fini della validazione per conferma di previsioni la simulazione è invece corretta se:
1. nella traccia generata non ci sono incoerenze logiche ;
2. l'ordine di scheduling simulato è identico a quello previsto in base alle policy con cui è
impostato il simulatore.
99 Ovviamente si stanno considerando casi di utilizzo, dove il limite è rappresentato dalla potenza di calcolo
piuttosto che il throughput di Input / Output.
100 Relativamente al concetto di incoerenza logica, si intende una qualsiasi produzione, di situazioni
impossibili nel mondo reale. Alcuni esempi possono essere: la perdita di job o la comparsa di job spuri
rispetto alla traccia di input; l'esecuzione simultanea di più job di quanti sono i nodi; la sovrapposizioni di
esecuzioni su uno stesso nodo; l'immotivata inadempienza agli obblighi di policy, ecc.
101 Una caratteristica del simulatore di Maui è quella di produrre, in determinate circostanze, un ordine di
scheduling o di allocazione dei nodi di calcolo (ai vari job da eseguire) diverso da quello della traccia
reale. Al fine di non confondere questa peculiarità di funzionamento, con una banale incoerenza logica
prodotta da una errata simulazione, nel prosieguo sarà fornita una descrizione dettagliata del fenomeno.
105
5.2 Presa di contatto col simulatore
Prima di addentrarsi nel pieno dell'esperimento di validazione, è opportuno mettere in
luce alcuni aspetti riguardanti l'uso del simulatore di Maui ed alcune caratteristiche del
modello di scheduling che esso implementa. Si forniranno inoltre al lettore i primi
esempi della rappresentazione adottata per le tracce (reali e simulate) e la relativa
interpretazione.
5.2.1 Problemi riscontrati e soluzioni adottate
L'esperimento di validazione del simulatore, ha richiesto preliminarmente la soluzione
di alcuni inconvenienti, legati al funzionamento ed alla modalità di utilizzo dello stesso.
Data la rilevanza di tali problemi, se ne riporta la descrizione e la relativa soluzione.
5.2.1.1 La carenza di documentazione
L'approccio al simulatore di Maui non è stato un compito semplice. La documentazione
messa a disposizione dal produttore di tale software, è complessivamente disorganica,
carente e soprattutto priva delle informazioni fondamentali per la comprensione dello
scheduling prodotto dalla simulazione. Non solo. Le basilari indicazioni, riguardo gli
accorgimenti da prendere affinché la simulazione avvenga correttamente, sono del tutto
mancanti. Questa carenza di informazioni ha causato a più riprese, errate procedure di
simulazione e la conseguente generazione di dati errati, spesso fuorvianti. Numerose
prove sono state compiute per arrivare alla spiegazione delle anomalie osservate,
ricorrendo all'uso degli stessi strumenti sviluppati per la validazione del simulatore. Tale
operato ha dato infine i suoi frutti, permettendo la comprensione dei comportamenti
“inattesi” del simulatore, nonché di interessanti peculiarità che caratterizzano lo
scheduling virtuale, in determinate condizioni limite. I paragrafi seguenti riportano le
più importati tra le caratteristiche del simulatore di Maui, frutto dell'esperienza acquisita
durante questo lavoro di tesi.
5.2.1.2 Scoperta e correzione di un bug
All'atto delle prime prove di utilizzo del simulatore, si è individuata un'anomalia di
funzionamento, che non sembra ancora essere stata documentata nel sito ufficiale di
Maui né segnalata nei forum di settore. Il problema è il seguente. Qualunque sia la
traccia reale, che si intenda usare come carico di lavoro per il simulatore, questa è
106
caratterizzata dal fatto che tutti i tempi contenuti, fanno riferimento ad un passato più o
meno remoto, nel quale i job sono stati accolti ed eseguiti nel batch system reale. Il
simulatore sembra incapace di relazionarsi a tali tempi passati ed al suo avvio,
percepisce la totalità dei job della traccia, come fossero già stati tutti sottomessi nelle
rispettive code e pronti per essere schedulati secondo le policy impostate. Questa
situazione vanifica in toto la veridicità della simulazione, in quanto lo scheduler virtuale
troverà sempre nelle code job da eseguire, anche quando nella realtà questi non erano
ancora pervenuti al sistema. Si perde in sostanza la dimensione relativa al naturale
flusso di sottomissione dei job, predicendo sviluppi di una realtà che non è mai esistita.
Prove effettuate hanno comunque dimostrato, che il problema non si verifica simulando
tracce in cui i tempi di accodamento dei job, sono successivi al tempo corrente del
sistema102. Acquisita questa informazione, il problema è stato quindi risolto con un
piccolo artificio. Prima di avviare la simulazione su una data traccia, questa viene
elaborata in modo da “spostare in avanti” tutti i valori temporali che vi compaiono.
Qusto shift è di tanti secondi quanti ne occorrono a far coincidere il più anziano dei
tempi, con l'istante di avvio del simulatore103. L'operazione è realizzata sommando un
opportuno offset di secondi a tutti i tempi presenti nella traccia. Essendo il valore
dell'offset costante, la traslazione temporale non altera i rapporti d'ordine che
intercorrono tra i job ed in particolare, tutti i valori di intervallo (ad esempio la durata di
un job, o la sua attesa in coda) restano gli stessi. Dal punto di vista del simulatore, la
traccia si estende ora dal presente verso il futuro ed i job i cui tempi di sottomissione
sono successivi al tempo corrente del sistema, vengono giustamente percepiti come non
accodati (e quindi non schedulati prematuramente).
A simulazione avvenuta, i tempi della traccia prodotta vengono traslati dello stesso
offset di secondi, ma stavolta all'indietro, tornando consistenti con l'ambito temporale
della traccia di partenza.
5.2.1.3 Una corretta procedura di simulazione
Un altro comportamento anomalo e particolarmente insidioso, svelato per il simulatore
di Maui, deriva dalla modalità con cui questo, data una traccia reale in input, ne estrae e
simula i job contenuti.
102 L'effetto è stato ottenuto avviando la simulazione, dopo aver impostando l'orologio di sistema della
macchina che esegue il simulatore, ad un tempo antecedente il primo dei tempi di accodamento dei job
presenti nella traccia.
103 Di questo compito si occupa in maniera automatica, un tool software appositamente sviluppato: lo script
workload-time-updater.pl. La sua descrizione è riportata nel paragrafo 4.3.4.
107
L'operazione in questione avviene nel seguente modo:
1. Il simulatore legge il file di traccia un record alla volta, a partire dal primo.
2. Ad ogni lettura, il job corrispondente a quel record è “accodato” al sistema virtuale
3. L'esecuzione del job è simulata in accordo alle sue caratteristiche, allo stato corrente del
sistema virtuale ed alle policy impostate.
In sostanza, la sequenza dei record nel file di traccia reale, determina l'ordine di
“accodamento” dei job al simulatore e quindi l'ordine di scheduling finale. Risulta
evidente quindi, che la corretta simulazione di una traccia reale non possa prescindere,
dal fatto che in questa i record siano ordinati per tempo di accodamento dei job,
cosicché che la sequenza di sottomissione al batch system virtuale, sia la stessa
pervenuta a quello reale.
Consideriamo ora il file di traccia reale. Questo è compilato dallo scheduler Maui non in
base all'ordine di accodamento dei job al batch system fisico ma secondo l'ordine di fine
esecuzione di ognuno104. In determinate circostanze, può accadere che l'ordinamento dei
job per fine esecuzione coincida con quello di sottomissione ma il più delle volte questi
sono diversi105.
La documentazione ufficiale di Maui non fa menzione a quanto appena spiegato e
lascia intendere che qualsiasi traccia reale, possa essere simulata così com'è stata redatta
dallo scheduler. Ciò comporta quindi che i job della traccia reale siano processati in un
ordine quasi sempre diverso da quello naturale ed il risultato è che la simulazione, pur
eseguita a parità policy e configurazione hardware, mostri gravi incongruenze logiche e
temporali con i dati da cui deriva. Lo stesso ordine di scheduling risulta alterato.
La deduzione dei meccanismi sopra spiegati, ha consentito la soluzione del problema.
Dato un file di traccia reale, il semplice riordino dei suoi record, per indice di job
crescente, ripristina la stessa sequenza con cui i job sono stati originariamente
sottomessi al batch system fisico106 e permette di ottenere simulazioni coerenti con il file
di traccia di partenza, come ci si attende.
104 Solo al termine dell'esecuzione la totalità dei dati riguardanti il job è disponibile per la creazione del
record da aggiungere nel file di traccia.
105 Accade frequentemente che job di breve durata accodati in un dato tempo, precedano nella traccia job
sottomessi anche molto tempo prima ma rimasti in esecuzione più a lungo.
106 Gli indici di job (JobID) sono valori numerici assegnati dal sistema ad ogni job, al momento della
sottomissione in coda. Gli indici rappresentano una chiave di ordinamento per i record della traccia, in
quanto sono univoci. Inoltre, essendo assegnati in maniera progressiva, il loro ordinamento in senso
crescente riproduce la stessa sequenza di accodamento dei job nel sistema che fisicamente li ha eseguiti.
108
5.2.2 Visualizzazione delle tracce
Indipendentemente dal tipo di test di validazione che si stia eseguendo (black box o
confronto con previsione), il criterio di verosimiglianza scelto suggerisce l'opportunità
di una qualche riproduzione grafica dell'ordine di scheduling contenuto nei file di
traccia Maui (reali e simulati). Lo scopo è il confronto visivo e semplice dei casi
simulato-reale o simulato-previsione. La forma di rappresentazione scelta, dovrebbe
essere tale da permettere anche una facile individuazione di eventuali errori logici del
simulatore, quali i paradossi già elencati nel precedente paragrafo 5.1.4. Questi
obbiettivi sono stati raggiunti visualizzando l'attività dei nodi del batch system, in
funzione del tempo. Il modello di tale rappresentazione, per l'attività reale di un
generico nodo, è riportato in Figura 5.1.
Nome-nodo
Scorrere del tempo
Job 1 Job 2 Job 3 Job 4 Job 5
Attività del nodo
Nod
i d
i calc
olo
Nome-nodo
Nome-nodo
20 Secondi
Assenza di job da eseguire
Pausa di overhead
Overhead nonmisurabile
Figura 5.1
Rappresentazione dell'attività di un nodo del batch system, ricavata da una traccia di esecuzione reale.
La figura mostra l'attività del nodo, riprodotta come una serie di intervalli temporali
(segmenti neri), indicanti gli intervalli di tempo in cui questo ha computato il job riferito
dal relativo Job ID107. Come mostrato, i segmenti di attività dei nodi sono quasi sempre
intervallati da spazi vuoti. La maggior parte di questi sono piuttosto brevi e
corrispondono al cosiddetto al tempo di overhead di sistema, ossia quella che potremmo
al momento definire come: “l'inerzia” del sistema ad avviare una nuova esecuzione al
107 Nell'esempio dell'immagine ed in quelli che seguiranno, i Job ID (ID: indice di identificazione) sono, a
scopo esemplificativo, riportati a partire dal numero “1”.
109
termine della precedente. Le pause di maggior durata indicano invece l'inattività dovuta
alla mancanza di job da eseguire. A volte l'overhead è assente e nessuno spazio vuoto
intervalla la fine di una computazione e l'inizio della successiva108. Nell'esempio
mostrato gli overhead sono ben visibili, perché la durata dei job in questione è
CREDWEIGHT 1dell'ordine dei secondi. Come si vedrà nel prosieguo, per job di durata
molto maggiore, la scala temporale adottata per le immagini, non permetterà una visione
nitida quanto quella del precedente disegno didattico ed i segmenti di attività verranno
percepiti come contigui. I margini degli intervalli di attività (astine verticali), saranno
comunque opportunamente riportati e sempre ben visibili, rendendo agevole il
riconoscimento dei singoli job.
Visualizzare l'attività dei nodi, soddisfa pienamente le esigenze di rappresentazione ai
fini della validazione proposta. Per ogni nodo infatti, un semplice colpo d'occhio
permette la costatazione di eventuali anomalie come perdite (o duplicazioni) di job,
sovrapposizioni degli intervalli di esecuzione, ecc; mentre la sequenza di allocazione ai
vari job, è ricavabile percorrendo verso destra la sequenza dei segmenti109.
Nel caso di black box validation, risulta particolarmente utile la possibilità visualizzare
simultaneamente sia l'attività reale che quella simulata dei nodi, cosi da semplificare le
operazioni di confronto. Si è quindi introdotto un secondo tipo di rappresentazione,
estendendo semplicemente quanto visto in precedenza (Figura 5.2).
Nome-nodo
Scorrere del tempo
Job 1 Job 2 Job 3 Job 4 Job 5 Job 6
Attività del nodo simulata
Attività delnodo reale
Nod
i d
i calc
olo
Nome-nodo
Nome-nodo
20 Secondi
Job 1 Job 2 Job 3 Job 4 Job 11
Figura 5.2Rappresentazione dell'attività reale e simulata per un nodo di un batch system Maui.
108 Questo effetto, dovuto alla quantizzazione dei tempi nelle tracce Maui o agli effetti della simulazione,
sarà adeguatamente spiegato nel paragrafo seguente.
109 In casi particolarmente semplici, la lettura del grafico di attività dei nodi permette anche la ricostruzione
dell'ordine di scheduling globale. Altre volte questa ricostruzione “visiva” non è così agevole e sarà
preferibile ricavare l'ordine di scheduling dei job direttamente dal file di traccia.
110
La Figura 5.2 riproduce il formato che d'ora in avanti sarà usato per l'illustrazione di
tutti i test basati su validazione black box. In essa le time-line di attività reale del nodo
sono riportate in rosso, in verde quelle simulate. Riguardo l'attività simulata, si è scelto
presentare fin d'ora due caratteristiche tipiche della simulazione effettuata da Maui:
➢ l'azzeramento dei tempi di overhead tra i segmenti;
➢ la possibile generazione di un ordine di allocazione dei nodi alternativo, ma comunque
valido, rispetto a quello del caso di esecuzione reale.
Questi due aspetti, tra loro correlati, sono di fondamentale importanza per la
comprensione del modello di simulazione di Maui. La loro trattazione sarà svolta nei
successivi paragrafi “5.2.3.3” e “5.2.3.4”.
Tornando invece al formato di visualizzazione di attività del nodo reale-simulata, si
assume che tutte le considerazioni già fatte in precedenza per la generica
rappresentazione di attività, continuino a valere.
5.2.3 Scheduling reale, simulato e relative tracce
La possibilità di rappresentare graficamente dati estratti dai file di traccia Maui, pone
l'accento sulla necessità di una comprensione non superficiale dei meccanismi che
portano alla compilazione dei file di traccia stessi. Tale comprensione permetterà infatti
il facile riconoscimento delle peculiarità di funzionamento dello scheduler e del suo
simulatore, nei grafici di attività dei nodi. Si darà inoltre spiegazione del concetto di
overhead del batch system reale e di come questo sia legato alla possibile produzione in
simulazione (a parità di configurazione), di ordini di allocazione dei nodi di esecuzione
diversi da quello della traccia di partenza.
5.2.3.1 Ritardo dovuto a overhead nel batch system reale
Nel paragrafo 5.2, si è mostrato come l'attività di esecuzione di un nodo, sia
caratterizzata da una breve pausa tra la finalizzazione di un job e l'avvio del successivo.
Ogni pausa rappresenta il tempo che occorre al batch system per allocare di nuovo il
nodo al termine di una esecuzione. Tale tempo è dovuta allo svolgimento delle
operazioni di gestione del batch system stesso, come ad esempio eseguire le otto fasi di
111
funzionamento dello scheduler Maui110, copiare un job dalla user interface al nodo di
calcolo, ritornare i risultati, ecc. Esso è detto tempo di overhead del sistema e dipende
da diversi aspetti come: la frequenza con cui lo scheduler interagisce col resource
manager, la “velocità” dello hardware sottostante, l'eventuale stato di congestione della
rete di comunicazione del cluster111, ecc.
La conseguenza di questo elemento di ritardo, è che un nodo di calcolo non torna
allocabile nello stesso istante in cui termina l'esecuzione del job ma occorre un certo
tempo prima che lo scheduler “si accorga” che la risorsa si è effettivamente liberata. Per
un batch system reale vale quindi la seguente assunzione:
la durata effettiva di ogni job si estende di un certo tempo di overhead, oltre il
proprio termine.
Questa “occupazione” prolungata delle risorse, del tutto normale in un batch system
fisico, influisce sulla possibilità di allocazione delle stesse, determinando un ordine di
assegnazione dei nodi di calcolo che non dipende dalla sola durata “netta” dei job.
5.2.3.2 Overhead e quantizzazione dei tempi
In teoria per ogni job eseguito realmente, l'esatto overhead del sistema dovrebbe essere
deducibile dal file di traccia. In pratica però non è così. Lo scheduler Maui ha una
risoluzione temporale che al massimo arriva al secondo112 e questo comporta la
conseguente quantizzazione di tutti i tempi113 inseriti nella traccia (accodamento,
avvio e termine esecuzione, ecc.). In particolare se un job inizia la sua esecuzione entro
lo scadere dello stesso secondo in cui termina il precedente, il tempo di overhead
riportato in traccia è nullo. La rappresentazione dell'attività del nodo interessato, vedrà i
segmenti dei due job contigui. In tutti gli altri casi questi saranno invece intervallati da
spazi con l'ampiezza di un numero intero di secondi.
110 Si veda il paragrafo “3.2.8 Ciclo di funzionamento di Maui”.
111 Il tempo di overhead è tipicamente variabile nel range di qualche secondo per batch system abbastanza
estesi (ad esempio la farm INFN di Perugia) ed entro un intervallo molto più limitato per il batch system
di test (il quale conta solo quattro nodi di calcolo).
112 Un secondo è il minimo intervallo di tempo selezionabile in Maui, tra due interrogazioni successive al
resource manager per aggiornare le proprie informazioni sullo stato del sistema.
113 D'ora in avanti si terrà conto della quantizzazione, ogni volta che ci si considerino o confrontino i valori
temporali presenti nelle tracce. Essa si intenderà considerata anche quando non esplicitamente nominata.
112
5.2.3.3 Simulazione e soppressione dell'overhead
Una ulteriore peculiarità del simulatore di Maui, anch'essa dedotta dall'esperienza d'uso,
è quella che esso esegue la simulazione dei job di una traccia reale, ipotizzando un batch
system totalmente ideale e pertanto privo di qualsiasi tempo di overhead. L'allocazione
virtuale di un nodo avviene sempre entro pochi istanti dal precedente rilascio e, in virtù
della quantizzazione dei tempi, questo si traduce in un tempo di overhead quasi sempre
nullo, nella traccia simulata. Visualizzando dunque l'attività simulata per ogni nodo, ci
si aspetta di osservare che la quasi totalità dei segmenti siano tra loro contigui (mentre
nella nella traccia reale erano pochissimi). Un esempio ricavato da vere tracce Maui,
tramite l'apposita funzione dello script workload-analizer.pl, è riportato in Figura 5.3.
Figura 5.3
Attività del nodo “test-node01” reale e simulata. Cinque job da venti secondi sottomessi simultaneamente.
In accordo al formalismo grafico già presentato, la figura riproduce in rosso l'attività del
nodo “test-node01”, ottenuta dall'esecuzione reale di cinque job da venti secondi,
sottomessi al sistema simultaneamente114. Le pause di overhead sono perfettamente
visibili. L'attività simulata (ovviamente a parità di policy e configurazione hardware) è
invece riportata in verde. Come ci si attende, l'ordine di scheduling è stato riprodotto
perfettamente ma gli intervalli di esecuzione non sono più inframezzati da attese di
overhead. Si noti in particolare la contrazione (ovvia) della durata complessiva di
computazione nel caso simulato.
Per questo primo esempio di visualizzazione di tracce Maui, si è scelto un esperimento
molto favorevole all'osservazione della perdita di overhead con la simulazione: pochi
job e scala temporale appropriata, dell'ordine delle decine di secondi. Nel prosieguo le
scale temporali saranno tali da non permettere l'osservazione diretta, usando la
rappresentazione grafica, delle pause di overhead nella traccia reale.
114 Per ottenere un grafico di semplice lettura si è forzata l'esecuzione dei cinque job su uno stesso nodo.
113
5.2.3.4 Allocazione delle risorse “identica” o “compatibile”
L'azzeramento dei ritardi di overhead in simulazione, non rappresenta una caratteristica
fine a se stessa ed in alcuni casi particolari la sua azione condiziona l'ordine di
allocazione dei nodi di calcolo nel sistema simulato, differenziandolo dal corrispettivo
presente nella traccia reale. La spiegazione di questo fenomeno e dei casi in cui può
manifestarsi o meno, sarà data attraverso due esempi.
Esempio 1. Si immagini un batch system, che per semplicità abbia due soli nodi di
calcolo e preveda come unica policy la gestione FIFO dei job sottomessi. Ad esso
vengono sottoposti sei job della durata di 1 minuto115, uno ogni 30 secondi. Completata
l'esecuzione la traccia viene simulata a parità di policy e risorse hardware. Le attività dei
nodi ricavate dalle tracce (reale e simulata) sono riportate in Figura 5.4.
Nodo 2
Job 1
30 sec
Job 1
Nodo 1
Job 3
Job 3
Job 5
Job 5
Job 2
Job 2
Job 4
Job 4
Job 6
Job 6
Stessosfasamento
Figura 5.4
Esempio di una identica allocazione dei nodi di calcolo per il caso reale e quello simulato.
L'interpretazione dell'immagine è la seguente. Sia lo scheduler reale che il simulatore
avviano l'esecuzione del primo job accodato (“job1”) sul nodo con indice più alto
(questa è la prassi per Maui). Dopo trenta secondi perviene al sistema il secondo job e la
sua computazione inizia su “nodo 2” che è libero. Al termine di “job 1”, “job 3” (che
intanto era stato accodato) riceve il nodo con un certo ritardo di overhead nel caso reale
e senza alcun ritardo in quello simulato. E così via nell'ordine indicato dalle frecce nere
tratteggiate. Man mano che ci si sposta verso destra nel grafico, le attività dei nodi
simulati cominciano a dimostrare un certo “sfasamento” nei confronti delle rispettive
attività reali. Tale discrepanza verrà d'ora in poi chiamata anticipazione dei tempi.
115 I valori delle durate dei job, cosi come i tempi di accodamento sono puramente indicativi. Quello che
invece conta è che le durate dei job siano uguali tra loro e che la sottomissione non sia tanto dilazionata
nel tempo, da produrre periodi di inattività dovuti a mancanza di job da eseguire.
114
Il dato da rimarcare nel caso di studio che si sta descrivendo, è che l'identica durata dei
job eseguiti (e poi simulati) comporta per entrambi i nodi, uno stesso numero di pause
tra le esecuzioni reali ed uno stesso numero di “soppressioni” di queste nella
simulazione. Nell'ipotesi esemplificativa che l'attesa di overhead sia costante, lo
sfasamento tra tempo simulato e reale è lo stesso per entrambi i nodi e la situazione
virtuale sarà costantemente un'anticipazione di quella reale. La sequenza di allocazione
delle risorse rimarrà identica nei due casi, anche continuando ad aggiungere job di
uguale durata all'infinito. L'unica differenza riguarderà l'aumento dell'anticipo che
l'attività simulata avrà su quella reale.
Esempio 2. Si consideri nuovamente il batch system di cui sopra e si assuma utile per
l'esperimento, che il tempo di overhead tra allocazioni consecutive dei nodi sia noto,
costante e pari a 2 secondi. Si sottomettono in sequenza (uno dopo l'altro) un job da 1
minuto, tre job da 19 secondi ed un altro job da 1 minuto. Come in precedenza,
completata l'esecuzione la traccia viene simulata a parità di policy e risorse hardware.
Le attività dei nodi per il caso reale e quello simulato, sono riportate in Figura 5.5.
Nodo 2
Job 1
20 sec
Job 1
Nodo 1
Job 2
Job 2
Job 3
Job 3
Job 4
Job 5
Job 5
Anticipo
Job 4
57 sec
62 sec
Cambio diallocazione
Figura 5.5
Esempio di differenti allocazioni dei nodi di calcolo per la traccia reale e la rispettiva simulazione.
In riferimento alla figura, si consideri il caso reale. Il primo job sottomesso al sistema
(job “lungo” da un minuto), attende il primo ritardo di overhead (2 secondi) e comincia
ad eseguire su “Nodo 2”. Parallelamente su “Nodo 1” si danno il cambio i tre job brevi,
attendendo ognuno i due secondi necessari a vedersi allocato il nodo. Dopo i primi 62
secondi (2+60) il job da un minuto è il primo a terminare116 e “job 5” riceverà “Nodo 2”
nei due secondi successivi, eseguendo così su di esso.
116 “Nodo1” concluderà la computazione di “job 4” a 63 secondi ( 2+19+2+19+2+19).
115
Nel caso simulato invece, tutte le attese dovute all'overhead di sistema sono annullate e
per “Nodo 1”, la somma dei tempi di esecuzione dei tre job corti, da un totale di 57
secondi (19+19+19). Stando al simulatore quindi, “Nodo 1” si libera ben tre secondi
prima di “Nodo 2” e sarà esso ad accogliere per l'esecuzione l'ultimo dei job accodati.
Data la durata reciprocamente diversa dei job considerati, il numero di pause di
overhead soppresse in simulazione è diverso per i due nodi (tre contro una) e
l'anticipazione dei tempi nella simulazione, è sbilanciata a favore di “Nodo 1”. La
durata appositamente scelta per i job “corti”, ha fatto il resto e l'ordine di allocazione
simulata dei nodi, è cambiato rispetto alla traccia originale.
Il simulatore di Maui, a causa della soppressione di tempi di overhead, può dunque
produrre sotto certe condizioni, un anticipo delle allocazioni non simmetrico per i vari
nodi e modificarne l'ordine di allocazione rispetto alla realtà.
5.2.3.5 Scheduling “compatibile”
Gli effetti della mancanza di overhead in simulazione, possono in certi casi influire non
solo sull'ordine di allocazione dei nodi di esecuzione ma anche sull'ordine di scheduling
dei job. Si consideri a titolo di esempio un batch system formato da un solo nodo di
calcolo, che esegua la sequenza di job riportata in Figura 5.6.
10 sec
Nodo 1
Job 1
Job 1
Job 2 Job 3 Job 4 Job 13
Job 2 Job 3 Job 4 Job 5 Job 13
Job 5 Job 6
Job 6 Job 7
Accodamento diun job ad altissimapriorità ( Job 13 )
Figura 5.6
Esempio di differenti ordini di scheduling per la traccia reale e la rispettiva simulazione.
La situazione riportata in figura mostra che alla sottomissione di un job con priorità
molto elevata (“Job 13”), la sequenza di esecuzione dei job già accodati viene interrotta
per far eseguire tale job. Per il sistema reale, il ritardo di esecuzione tra un job e l'altro
fa si che l'esecuzione di “Job 13” avvenga tra prima di quella di “Job 5” mentre in
simulato l'esecuzione è successiva a “Job 5”. L'ordine di scheduling è quindi diverso.
116
5.2.3.6 Criteri di compatibilità per validazione “black box”
In base al criterio di verosimiglianza adottato in caso di validazione di tipo “black box,
la variazione dell'ordine di allocazione dei nodi e quella dell'ordine di scheduling, non
comportano una incongruenza ai fini della verifica condotta, se sono compatibili coi
rispettive ordini reali. La definizione del concetto di compatibilità è ora possibile.
➢ Un'allocazione simulata dei nodi, che differisca da quella reale per le sole conseguenze
dell'anticipo di attività, sarà considerata corretta e detta compatibile con questa;
➢ Un'ordine di scheduling simulato,che differisca da quello reale per le sole conseguenze
dell'anticipo di attività, sarà considerato corretto e detto compatibile con questo;
L'utilità di queste definizioni consiste nel fornire lo strumento per distinguere, se
eventuali incongruenze tra traccia reale e relativa simulazione, siano imputabili al
caratteristico funzionamento del simulatore (compatibilità con la realtà) oppure ci si
trova di fronte ad una incongruenza logica e quindi ad un errore del simulatore.
5.2.3.7 Idealità, realtà e validazione “black box”
Il sistema virtuale a cui vengono sottoposti i job per la simulazione è ideale e quindi non
mostra ritardi, fallimenti, inconvenienti hardware, ecc. Nel caso dell'overhead le
approssimazioni introdotte dalla simulazione sono tollerabili e come si è visto
inquadrabili tramite i criteri appena formulati, nel contesto della validazione con tecnica
“black box”. Alcuni eventi del mondo reale invece si mostrano del tutto incompatibili
con tale tecnica di verifica del simulatore.
La rottura di un nodo di calcolo durante un'esecuzione reale, potrebbe ad esempio essere
assorbita dallo scheduler di Maui, semplicemente ignorando in futuro il nodo e
riaccodando il descrittore del job “fallito”, per la futura esecuzione altrove. Lo
scheduling prodotto risentirebbe quindi dell'evento. Eseguendo una simulazione sulla
relativa traccia, il simulatore non ha invece modo di sapere del guasto avvenuto, e per il
job precedentemente citato porterebbe virtualmente a termine l'esecuzione su quel nodo,
producendo uno scheduling diverso dal reale. Una eccezione del mondo fisico può
produrre una simulazione inconsistente, anche se il simulatore applica le sue regole in
maniera impeccabile. Tale situazione sancisce l'inutilizzabilità del metodo “black box”
in casi come questo. Ciò non toglie comunque, la possibilità di effettuare una
previsione riguardo lo scheduling che ci sarebbe stato senza l'evento reale, e se questa
previsione coincide con la simulazione ottenuta (“conferma di previsione”), il
simulatore sarebbe comunque validato per quel caso.
117
5.3 Test di validazione e relativi risultati
Si riportano in queste pagine, le descrizioni delle prove di validazione effettuate sul
batch system di test, descritto nel quarto capitolo. Tali prove saranno discusse a partire
dalla verifica dei meccanismi di simulazione più generali fino ai più specifici. Per ogni
test verranno specificate le seguenti informazioni:
• la finalità della verifica eseguita;
• l'insieme di job con cui si è prodotta la traccia reale;
• modalità di sottomissione dei job al sistema reale;
• le policy del batch system fisico e quelle del simulatore;
• una raffigurazione grafica (il grafico di attività dei nodi o qualsiasi altra forma di
rappresentazione utile ad una lettura semplice e veloce dei risultati);
• un sintetico commento relativo ai risultati dell'esperimento.
Qualora più esperimenti dello stesso tipo abbiano prodotto risultati formalmente
identici, si riporterà la rappresentazione grafica di uno solo di questi, lasciando ad un
commento la descrizione degli altri.
5.3.1 Verifiche elementari sui tempi
Le prove che seguono, sono state effettuate con la tecnica della “black box validation”
ed hanno lo scopo di verificare aspetti basilari della simulazione come il mantenimento
dei tempi non soggetti ad anticipo di simulazione (tempo di sottomissione dei job al
sistema e durata dei tempi di esecuzione), il rispetto dell'ordine di scheduling, ecc.
5.3.1.1 Rispetto dei tempi e delle durate di esecuzione
Finalità: con questa prova si è voluta testare la capacità del simulatore di rispettare i
tempi di sottomissione dei job ed i rispettivi intervalli di esecuzione. Job: la tracia reale
è stata prodotta utilizzando 20 job di un solo utente, con durate da 30 secondi a 2
minuti. Sottomissione: tutti i job sono stati sottomessi su una stessa coda, ad intervalli
di tempo tali che le esecuzioni sui quattro nodi siano intervallate da periodi di inattività.
Policy: lo scheduler del batch system e del simulatore sono in configurazione di default,
l'unica policy attiva è cioè “QUEUETIMEWEIGHT 1”, vale a dire la gestione FIFO dei
job sottomessi. I risultati del test sono riportati in Figura 5.7.
118
Figura 5.7
Rispetto dei tempi di accodamento e delle durate di esecuzione.
119
Come mostrato in figura, l'accordo tra attività reale e simulata per i quatto nodi del
batch system di test, è eccellente. Il rispetto dei tempi di accodamento e delle durate di
esecuzione, già evidente graficamente, è stato verificato anche quantitativamente
eseguendo il confronto dei rispettivi valori riportati nel file di traccia reale ed in quello
simulato. A meno dell'errore di quantizzazione già discusso in precedenza, la
coincidenza di tali tempi è perfetta. Gli ordini di scheduling ricavati dai due file di
traccia, sono riportati sotto e come ci si attendeva coincidono.
Reale: 30[85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99], 31[01, 02, 03, 04]
Simulato: 30[85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99], 31[01, 02, 03, 04]
In base quindi al criterio di verosimiglianza adottato, il test si considera superato.
5.3.1.2 Repliche dell'esperimento
Il precedente esperimento è stato replicato due volte, modificando la sola durata dei job
ed i tempi di accodamento. Con tali prove si è voluto verificare, che il simulatore
continuasse ad operate con la stessa correttezza dimostrata nel caso precedente, anche
con job di media e lunga durata. Si sono quindi usati ogni volta venti job, con durate di
esecuzione comprese tra dieci minuti ed un'ora, e tra una e cinque ore. La modalità di
sottomissione ha rispettato lo stesso criterio discusso in precedenza. I grafici di attività
prodotti sono formalmente identici a quello precedentemente riportato e non saranno
dunque allegati. Il loro esame, quello dei valori riportati nelle tracce, e l'ordine di
scheduling prodotto, hanno confermato la correttezza della simulazione.
5.3.2 Verifiche dell'ordine di allocazione dei nodi
Come spiegato nel paragrafo 5.2.3.4, esistono alcune situazioni in cui, a parità di
scheduling, la simulazione può produrre una diversa allocazione delle risorse rispetto al
caso reale. In altre situazioni invece questo non può (e non deve avvenire). La verifica
di questi aspetti è stata l'obbiettivo dei seguenti test. Il modello di validazione è
nuovamente il “black box” ma stavolta integrato da elementi di “previsione” che si
vuole siano confermati dalla simulazione.
5.3.2.1 Identicità dell'ordine di allocazione dei nodi
Finalità: oltre alla consistenza della simulazione con la traccia reale, si vuole verificare
che la simulazione di job di uguale durata, opportunamente accodati, non produca un
ordine di allocazione diverso da quello che si ha nella traccia reale, contraddicendo le
120
aspettative riguardo la sua modalità di funzionamento117. Job: sono 12, di un solo utente
e tutti della durata di 4 minuti. Sottomissione: i job sono sottomessi simultaneamente
(in modo consecutivo) su singola coda. Policy: è attiva la sola politica FIFO (default
dello scheduler). L'esito dell'esperimento è riportato in Figura 5.8.
Figura 5.8
Produzione di un ordine allocazione nodi simulato, identico a quello reale (primo esempio).
Come si nota dall'immagine, ai fini della validazione “black box” la simulazione è
corretta in quanto non è presente alcuna incoerenza logica rispetto all'attività reale dei
nodi, l'ordine di scheduling è lo stesso della traccia originale118 ed inoltre si ha un
identico ordine di allocazione delle risorse. Proprio quest'ultimo aspetto soddisfa la
previsione fatta riguardo l'esperimento: dati job di uguale durata, l'allocazione simulata
dei nodi deve essere identica a quella reale e non semplicemente compatibile119.
117 Questa assunzione introduce nel contesto della validazione “black box” in corso, l'elemento base della
validazione per “verifica di previsione”. Ciò dimostra come le due tecniche possano essere combinate
nell'ambito di uno stesso esperimento, rafforzando il valore del risultato ottenuto.
118 D'ora in avanti, per motivi di praticità, non verrà più riportato l'ordine di scheduling reale e simulato come
lista degli indici dei job (come fatto per il primo test) ma ci si limiterà al riferire se i due ordini
coincidono. Qualora il grafico di attività dei nodi non permettesse una ricostruzione certa degli ordini di
scheduling, questi si intenderanno ricavati direttamente dai rispettivi file di traccia.
119 Questa assunzione è sempre vera a meno di possibili (rare) eccezioni dovute alla ormai familiare
quantizzazione dei tempi. Qualora una eccezione si verificasse, un semplice esame dei valori temporali
nelle tracce ne permetterebbero il riconoscimento, evitando di invalidare la regola generale relativa alla
generazione di ordini di allocazione simulata identici a quella reale.
121
Si noti che la parte terminale delle attività dei nodi in Figura 5.8 è stata evidenziata per
mostrare come “l'anticipo dei tempi”, introdotto dalla soppressione delle pause di
overhead da parte del simulatore, sia ugualmente bilanciato sui quattro nodi.
Una variante di questo test è stata condotta modificando esclusivamente l'ordine di
sottomissione dei job al sistema reale che ha prodotto la traccia. Sottomissione: i job
sono sottomessi uno al minuto su singola coda. Il risultato è visibile in Figura 5.9.
Figura 5.9
Produzione di un ordine allocazione nodi simulato identico a quello reale (secondo esempio).
La figura si distingue per una grande leggibilità. L'attività dei nodi mostra chiaramente,
per esecuzione reale e simulata, l'identicità sia dell'ordine di scheduling che di quello di
allocazione dei nodi. Le esecuzioni dei job sono scalate di un minuto, in accordo
all'iniziale ritardo di sottomissione. Si noti infine che la Figura 5.9 ricalca fedelmente la
Figura 5.4, esprimente la previsione teorica per questo tipo di esperimento. Riguardo la
presente prova di validazione quindi, sia i vincoli di “black box” che quelli di “rispetto
della previsione” sono ampiamente soddisfatti.
5.3.2.2 Repliche degli esperimenti
I due precedenti esempi sono stati ripetuti con l'unica variante dell'uso di job della
durata di un'ora (anziché quattro minuti). Anche in questo caso la diversa componente
temporale non ha influito sulla qualità della simulazione. I risultati dei test sono stati
122
formalmente identici ai precedenti ed hanno rispettato pienamente il criterio di
verosimiglianza adottato. I relativi grafici di attività dei nodi non saranno riportati
5.3.2.3 Ordine di allocazioni dei nodi “compatibile”
Finalità: si vuole testare se la simulazione di una traccia reale, in cui la scelta dei job è
tale da originare un ordine di allocazione simulato compatibile col reale, produca
effettivamente tale fenomeno. Job: 12 job di durata variabile da 1 a 5 minuti.
Sottomissione: i job sono sottomessi ad intervalli di tempo consoni alle finalità del test.
Policy: è attiva la sola politica FIFO. I risultati del test sono visualizzati in Figura 5.10.
Figura 5.10
Generazione di un ordine allocazione simulato dei nodi compatibile con quello reale.
Si osservi la figura a partire dal riquadro blu. La situazione mostra una tipica serie di
esecuzioni per la quale è impossibile che la soppressione degli overhead da parte del
simulatore, produca variazioni dell'ordine di allocazione dei nodi. Ben diversa è invece
la situazione per i nodi del riquadro rosso. Lo scenario presente è formalmente identico
a quello previsto dal caso teorico rappresentato in figura 5.5. Data la particolare durata
dei job del terzo nodo, il numero di overhead soppressi è tale da sbilanciare l'anticipo
123
dei tempi di allocazione a suo favore. Questo apparirà quindi libero, prima di quanto sia
avvenuto realmente, e sottrarrà al quarto nodo l'esecuzione del job “3042”. La
conseguenza di questo “salto di nodo” (freccia nera lunga) si ripercuote quindi sul job
“3044” la cui esecuzione virtuale è avviata sul quarto nodo (freccia nera corta), che nel
frattempo si è liberato. L'inversione di allocazione dei nodi appena descritta, è il perfetto
esempio di un ordine di allocazione simulato compatibile col reale, dovuta allo
sbilanciamento dell'anticipo dei tempi, prodotto dal simulatore di Maui. Pertanto essa
non costituisce un errore logico di simulazione. Gli scheduling generati nel caso reale e
simulato coincidono e quindi, in base al criterio di verosimiglianza, la simulazione è
consistente con la realtà.
Il fenomeno osservato è fortemente dipendente dalle caratteristiche temporali dei job
simulati e come tale non esprime una proprietà generale, che deve valere per una
qualsiasi durata dei job. Una replica del test appena condotto per una diversa scala
temporale quindi non ha molto senso ed il passaggio dai minuti alle ore (o viceversa)
molto difficilmente produrrà i risultati “formalmente identici” ottenuti per le repliche
dei precedenti esperimenti.
5.3.2.4 Ordine di scheduling compatibile
Finalità: si vuole testare se la simulazione di una traccia reale, in cui la scelta dei job è
tale da originare un ordine di scheduling simulato compatibile col reale, produca
effettivamente tale fenomeno. Job: 200 job della durata di 10 secondi. Di questi 199
appartengono ad “Utente_01” ed il rimanente ad “Utente_02”. Sottomissione: i job
sono sottomessi consecutivamente, sulla stessa coda, ad un secondo di distanza uno
dall'altro, il job di “Utente_02” è l'ultimo ad essere accodato, dopo circa 200 secondi.
Policy: Al primo dei due utenti di questo test, è accordato un valore di priorità pari ad 1,
al secondo invece il valore di 100000. E' inoltre attiva per lo scheduling la politica FIFO
di base. Le policy di configurazione appena citate sono riportate sotto, come appaiono
nel file di configurazione “maui.cfg”.
QUEUETIMEWEIGHT 1
USERWEIGHT 1
USERCFG[User_01] PRIORITY=1
USERCFG[User_02] PRIORITY=100000
Per semplicità il batch system di test è stato ridotto ad un solo nodo di calcolo.
I risultati dell'esperimento sono visibili nella seguente Figura 5.11.
124
Figura 5.11Generazione di un ordine di scheduling simulato compatibile con quello reale.
L'immagine riproduce la sola parte della traccia dove avviene la variazione dell'ordine
di scheduling. In accordo all'ordine di sottomissione descritto, a 200 secondi dal primo
accodamento, lo scheduler Maui reale si trova a dover gestire un job ad altissima
priorità (job “6885”quello di “Utente_02”). Il flusso di esecuzione dei job sottomessi in
precedenza è quindi interrotto al termine del job “6875”, ossia alla prima occasione utile
per allocare il nodo di calcolo ed eseguire il job più “importante”. L'esecuzione
riprende con logica FIFO a partire dal job “6876” fino allo svuotamento della coda. Nel
caso simulato invece l'anticipazione dei tempi di allocazione del nodo, causa
l'esecuzione simulata di un ulteriore job, prima di “6885”, producendo un ordine di
scheduling diverso dal reale ma, come atteso, compatibile con questo.
5.3.3 Verifiche di indipendenza dall'input
I test effettuati fino ad ora, hanno dimostrato per un certo numero di casi, la validità del
simulatore nel riprodurre i meccanismi fondamentali dello scheduling. Dove sensato, si
è anche mostrata l'indipendenza dall'ordine di grandezza dei tempi. In ogni caso gli
esperimenti hanno riguardato job di un solo utente, sottomessi al sistema reale su
un'unica coda. Le nove prove seguenti servono a verificare che il simulatore si
comporti correttamente anche quando più utenti, gruppi e code siano coinvolti. Ai fini di
una snella elencazione, sarà fatta una deroga all'abituale prassi di presentazione dei test.
Il sistema si considera ancora una volta configurato con politica FIFO e le code, così
come utenti e gruppi hanno la stessa priorità.
• Prova 1: Due utenti di uno stesso gruppo, sottomettono dieci job a testa su una stessa
coda. Le durate dei job vanno da 15 a 60 minuti. Si accoda un job ogni 5 minuti
scegliendo casualmente i job dell'uno o dell'altro.
• Prova 2: Due utenti di uno stesso gruppo, sottomettono sette job a testa su una stessa
coda. Le durate dei job vanno da 15 a 60 minuti. Si accoda un job ogni 5 minuti in
modo casuale.
125
• Prova 3: Due utenti di uno stesso gruppo, sottomettono dieci job a testa, su due code
separate (una a testa). Le durate dei job vanno da 15 a 60 minuti. Si ha un accodamento
ogni cinque minuti, in ordine casuale.
• Prova 4: Tre utenti di uno stesso gruppo, sottomettono 20 job di durata compresa tra 15
e 60 minuti su due code nella seguente maniera: il primo utente 5 job sulla prima coda,
il secondo utente 5 job sulla seconda coda, il terzo utente sottomette dieci job, 5 su una
coda e 5 sull'altra. Gli accodamenti avvengono ogni cinque minuti, in ordine casuale.
• Prova 5: Come per prova 1 ma i due utenti appartengono a due diversi gruppi.
• Prova 6: Come per prova 2 ma due utenti appartengono ad un gruppo ed il terzo ad un
altro.
• Prova 7: Come per prova 3 ma i due utenti appartengono a due diversi gruppi.
• Prova 8: Come per prova 4 ma i primi due utenti appartengono ad un gruppo ed il terzo
ad un altro.
• Prova 9: Come per prova 4 ma il primo ed il terzo utente appartengono ad un gruppo ed
il secondo ad un altro.
Ognuna delle precedenti prove è stata eseguita in accordo al paradigma della
validazione “black box”, seguendo la stessa procedura adottata per i test descritti nei
precedenti paragrafi. Ogni volta la visualizzazione delle attività reali e simulate dei nodi
non ha mostrato anomalie e l'ordine di allocazione simulato per i nodi è sempre stato o
identico al reale o compatibile con esso. Infine gli ordini di scheduling ricavati dalle
nove coppie di tracce (reale e simulata) si sono sempre dimostrati identici. Ognuno dei
test quindi ha validato il simulatore nel proprio specifico ambito .
Tornando alle visualizzazioni delle attività dei nodi dei vari esperimenti, queste non
hanno mostrato caratteristiche particolarmente interessanti, ricadendo sempre in un
qualche caso intermedio rispetto quelli notevoli mostrati in precedenza. Per questo
motivo, nessuno di tali grafici verrà riportato.
5.3.4 Simulazione del meccanismo di priorità
La politica FIFO prevista come default per lo scheduler Maui ed il suo simulatore, ha
costituito la policy sulla base della quale sono stati eseguiti tutti i precedenti test. Come
qualsiasi politica implementata in Maui, anche FIFO ha una sua componente nel
meccanismo di scheduling basato sul calcolo di priorità. L'esito positivo di tutti i test fin
qui condotti, nonché il fatto che gli scheduling simulati hanno effettivamente rispettato
tale politica, costituisce già una prima, indiretta forma di validazione del simulatore,
riguardo la corretta riproduzione del sistema di scheduling prioritario.
126
I seguenti test mirano ad una verifica più diretta, vagliando di volta in volta l'operato del
simulatore, nel riprodurre policy per l'attribuzione di valori arbitrari di priorità a:
➢ utenti
➢ gruppi
➢ classi (code).
Il criterio di validazione adottato è quello della “verifica di previsione”. Per il momento
si abbandonerà lo strumento di visualizzazione dell'attività dei nodi usato finora, in
favore di una tecnica grafica altrettanto efficace, legata alla funzione di simulazione
enumerativa, inserita nello script run.sh120. Allo scopo di semplificare e rendere
significativa l'osservazione, tre dei nodi di calcolo del batch system di test sono stati
disattivati, realizzando un sistema con un singolo execution node.
5.3.4.1 Test di priorità di utenti
Finalità: si vuole verificare se il simulatore, dati due utenti qualsiasi a cui siano
associati valori (pesi) di priorità differenti, scheduli per primi i job dell'utente con
priorità maggiore, anche quando sottomessi successivamente ai job dell'altro utente.
Job: i job impiegati per il test sono tre.
• Un job di “saturazione” dell'unico nodo di calcolo, da sottomettere al sistema per primo.
• Un job per il primo utente (Utente_01).
• Un job per il secondo utente (Utente_02).
Tutti i job hanno una durata di 15 minuti. Sottomissione: il job di saturazione è
sottomesso per primo, a farm “scarica”. Dopo cinque minuti il job del primo utente
viene accodato, seguito immediatamente dal job del secondo utente. Tutte le
sottomissioni sono avvenute sulla stessa coda. Policy: le policy di configurazione
diverse dal default sono le seguenti:
QUEUETIMEWEIGHT 1
CREDWEIGHT 100
USERWEIGHT 1
USERCFG[Utente_01] PRIORITY = x
USERCFG[Utente_02] PRIORITY = y
Come si vede la componente FIFO dello scheduling è mantenuta attiva ma per evitare
120 Tale script costituisce il livello superiore dell'infrastruttura di automazione delle simulazioni, descritta nel
quarto capitolo. La descrizione della sue caratteristiche ed in particolare della funzione di simulazione
enumerativa, è riportata nel paragrafo “4.4.4 lo script run.sh”.
127
che influisca sensibilmente con le priorità accordate agli utenti, si è assegnato ad essa un
peso che è 1 / 100 rispetto quello della componente relativa alle priorità accordate agli
utenti. I simboli “x” ed “y” indicano la coppia di valori di priorità, di volta in volta
assegnati ai due utenti, nelle varie prove condotte.
La prima coppia di valori attribuita ad “x” ed “y” è stata (0, 0)121 ai fini dell'esecuzione
sul batch system fisico, per produrre la traccia reale da utilizzare come base delle
successive simulazioni.
Il test è basato sulla simulazione enumerativa “a due parametri”, che nel caso specifico
sono “x” ed “y” nei rispettivi intervalli [1, 10] e [3, 7]. Tale meccanismo genererà
automaticamente tante simulazioni quante sono le possibili coppie di valori interi dei
due intervalli (vale a dire 50) ed in ogni simulazione la coppia di valori esprimerà il
peso di priorità accordato ai due utenti.
Data la configurazione del batch system, le policy descritte e la modalità con cui sono
stati sottomessi i job, si avrà che in ogni simulazione lo scheduler virtuale esegue per
primo il job di saturazione (che impegnerà l'unico nodo di calcolo) ed al termine di
questo sceglierà tra i restanti due job, che intanto sono stati accodati, il prossimo ad
essere eseguito sulla base di tre casi possibili.
1. Il job di “Utente_1” se la sua priorità è maggiore di quella di “Utente_2” ( x > y ).
2. Il job di “Utente_2” se la sua priorità è maggiore di quella di “Utente_1” ( y > x ).
3. Il job di “Utente_1” se la sua priorità uguale a quella di “Utente_2” ( x = y ), perché
nel sistema è attiva la politica FIFO ed a pari priorità dei due utenti, “Utente_1” ha
sottomesso prima il suo job.
Quanto appena descritto, rappresenta una ragionevole previsione del comportamento,
che un simulatore privo di errori, deve tenere per l'esperimento dato.
Volendo esprimere tale previsione, in una forma più consona alla rappresentazione
introdotta a suo tempo, per descrivere la simulazione enumerativa al variare di due
diversi parametri, si avrebbe:
121 Ai fini dell'esperimento qualsiasi altra coppia di valori sarebbe andata bene. Lo scopo è semplicemente
ottenere una traccia di esecuzione reale, della quale il simulatore considererà i soli tempi di sottomissione
dei job e delle rispettive durate, ignorando lo scheduling prodotto in base a specifici valori di policy. Per
completezza si nota comunque che con la coppia (0, 0) il risultato dell'esecuzione è ovviamente uno
scheduling FIFO dei tre job.
128
“o” Esegue prima il job di Utente_01“o” Esegue prima il job di Utente_02
7 o o o o o o o o o o
6 o o o o o o o o o o
5 o o o o o o o o o o
4 o o o o o o o o o o
3 o o o o o o o o o o
1 2 3 4 5 6 7 8 9 10
Ogni punto “o” della matrice rappresenta una diversa simulazione, delle cinquanta
effettuate. I valori riportati in ascissa sono tutti i possibili valori di priorità che possono
essere associati ad “Utente_01” mentre in ordinata quelli per “Utente_02”. Il colore di
ogni “o” indica la previsione, per la relativa simulazione, riguardo quale deve essere il
job a partire per primo (rosso se del primo utente, verde se del secondo).
Eseguita la simulazione enumerativa come specificato, si è provveduto in maniera
automatica sia alla raccolta dei risultati delle simulazioni che alla compilazione del
grafico riportato in Figura 5.12.
Figura 5.12
Enumerazione dei casi in cui il job del primo utente è eseguito prima di quello del secondo e viceversa.
I segni “+” di colore rosso indicano le simulazioni in cui il job di “Utente _01” è partito
prima del job di “Utente _02”, viceversa i segni “x” verdi. L'accordo dei risultati con la
previsione è totale. Il simulatore ha correttamente gestito il meccanismo di attribuzione
di priorità ad ai job, in base all'utente proprietario.
129
5.3.4.2 Repliche del test di priorità
La precedente prova è stata ripetuta due volte, verificando il comportamento del
simulatore di Maui riguardo l'attribuzione di priorità ai job, in base al gruppo di
provenienza ed alla coda di sottomissione. La modalità di conduzione del test è stata
identica, ferma restando la formulazione di policy di priorità non più riferite ad una
coppia di utenti ma di gruppi e quindi di code. Ancora una volta l'esito degli esperimenti
è stato positivo.
5.3.5 Simulazione di limiti statici di allocazione
L'ultima serie di prove effettuate, è servita a verificare la capacità del simulatore, di
riprodurre correttamente il meccanismo di limitazione delle allocazioni dei nodi di
calcolo, stabilita con policy, dette di “restrizioni delle allocazioni” nella loro
formulazione con limiti soft e hard122. Il criterio di validazione adottato è quello “black
box” e la tecnica di rappresentazione grafica per l'interpretazione dei risultati, torna
quindi quella di visualizzazione delle attività reali e simulate dei nodi.
5.3.5.1 Test dei limiti statici attribuiti per utente
Finalità: dati due utenti qualsiasi, per i quali siano posti limiti al numero di job
eseguibili contemporaneamente (cioè ai nodi allocati ad essi simultaneamente), si vuole
verificare che il simulatore scheduli i job dei due utenti in accordo a tali limiti, come
avvenuto per l'esecuzione reale. Job: dieci job per ogni utente, della durata di 5 minuti
ognuno. Sottomissione: i job sono sottomessi consecutivamente. Prima i dieci di
“Utente_01” seguiti da quelli di “Utente_02”. La sottomissione avviene sulla stessa
coda. Policy: le policy di configurazione diverse dal default sono le seguenti:
QUEUETIMEWEIGHT 1
USERWEIGHT 100
USERCFG[Utente_01] MAXJOB = 3, 4
USERCFG[Utente_02] MAXJOB = 1, 3
Le ultime due policy vanno lette come segue. Quando la farm è a pieno carico, il primo
utente ha diritto a tre esecuzioni contemporanee ed il secondo ad una soltanto. In caso di
farm “scarica”123, il primo utente può ricevere l'allocazione di tutti e quattro i nodi di
calcolo mentre il secondo utente al massimo di tre.
122 Si veda il paragrafo “3.2.5.1 Restrizione delle allocazioni”.
123 Con la dicitura “farm scarica” si intende la presenza nelle code, dei job di un solo utente.
130
Il confronto tra la traccia reale e la propria simulazione, effettuata a parità di
configurazioni, è riportata in Figura 5.13
Figura 5.13
Esecuzione di job con limiti statici di allocazione dei nodi per utente e relativa simulazione.
Riguardo l'immagine, si noti che il formalismo di rappresentazione delle attività dei
nodi è stato ampliato con l'aggiunta alle time-line, dei riferimenti all'utente che ha
sottomesso il job ed al gruppo a cui esso appartiene. Tale aggiunta di informazione
permette al lettore che voglia ripercorrere la sequenza di allocazione dei nodi, di poter
constatare il rispetto dei limiti impostati dalle policy.
La sottomissione simultanea dei job dei due utenti, porta subito la farm di test a pieno
carico e già dalle prime quattro allocazioni (quelle incolonnate nella parte sinistra del
grafico), si vede l'assegnazione di tre nodi ad “Utente_01” e di un solo nodo ad
“Utente_02”, come atteso. Le allocazioni proseguono nel rispetto delle policy ed
all'esaurimento dei job di “Utente_01”, il nodo “test-node03” salta il proprio turno di
allocazione (spazio vuoto a destra), in accordo al limite di tre job contemporanei per
“Utente_02”, quando la farm è “scarica” (cioè coi job di un solo utente accodati).
La precedente discussione ha solamente un valore didattico in quanto ai fini della
validazione è sufficiente constatare che la simulazione della traccia reale ha prodotto
identici ordini di scheduling e di allocazione dei nodi, che uniti alla totale assenza di
incoerenze di tipo logico tra caso reale e simulato, decretano il superamento della prova.
131
5.3.5.2 Prima variante del test dei limiti di allocazione
Una variante della precedente prova è consistita nella modifica del numero dei job dei
due utenti e del criterio del loro accodamento nel sistema reale. Ogni altro aspetto
relativo al test originale (policy, utenti, criterio di validazione, ecc.) è stato mantenuto.
Si riportano le sole variazioni.
Job: cinque per ogni utente, della durata di 5 minuti ognuno. Sottomissione: sono
sottomessi per primi e simultaneamente i job di “Utente_01”; dopo un minuto di pausa,
tutti quelli quelli di “Utente_02” anch'essi simultaneamente. La traccia reale prodotta e
la relativa simulazione sono riportate in Figura 5.14.
Figura 5.14
Esecuzione di job con limiti statici di allocazione dei nodi per utente e relativa simulazione (variante 1).
Come nel caso precedente l'immagine mostra un accordo totale tra esecuzione reale e
simulazione, sia in fatto di allocazione dei nodi che di scheduling dei job.
5.3.5.3 Seconda variante del test dei limiti di allocazione
Questo terzo esperimento sulla corretta simulazione delle policy di allocazione, è in
assoluto il più interessante tra tutti i test condotti. L'impostazione di base è la stessa
delle due prove compiute in precedenza ed ancora una volta la differenza consiste nel
criterio di sottomissione dei job (di nuovo 5 ad utente) alla farm di test.
132
Sottomissione: sono sottomessi per primi e simultaneamente i job di “Utente_02”; dopo
un minuto di pausa, tutti quelli quelli di “Utente_01” anch'essi simultaneamente. La
traccia reale prodotta e la relativa simulazione sono riportate in Figura 5.15.
Figura 5.15
Esecuzione di job con limiti statici di allocazione dei nodi per utente e relativa simulazione (variante 2)
L'immagine mostra il motivo dell'interesse che l'esecuzione di questo test ha suscitato. Il
cerchio blu evidenzia, quello che a tutti gli effetti può essere considerato un
“imprevisto” del mondo fisico.
Si osservino le attività reali dei quattro nodi (riportate come da convenzione in rosso).
Mentre i nodi “01”, “02” e “04”, sono allocati pressoché subito ai job indicati, per il
nodo “03” si verifica un qualche problema, a causa del quale esso è momentaneamente
visto da Maui come irraggiungibile. La natura del problema è irrilevante, quello che
importa è che a seguito di una situazione inattesa, Maui non ha potuto contare su uno
dei nodi di calcolo ed il job che stava per essere avviato, è stato in qualche modo
bloccato e riaccodato per evitarne la perdita. Come si vede in figura, dopo un certo
tempo (circa un minuto) il nodo è tornato raggiungibile dallo scheduler, il quale avvia su
di esso il job che al momento ha maturato la maggiore priorità di esecuzione. In sintesi
quindi, durante l'esecuzione reale si è verificato un evento inatteso e lo scheduler si è
adattato ad esso, prendendo decisioni diverse rispetto a quelle che avrebbe preso se tutto
fosse andato normalmente.
133
Si consideri ora l'attività dei nodi simulata (riportata in verde). Il simulatore esegue la
sua previsione sulla base dei tempi di sottomissione dei job e non sa, ne ha modo di
sapere dell'inconveniente occorso al nodo “03”. Nel suo mondo virtuale il sistema è
perfettamente funzionante, non ci sono modificazioni della struttura fisica del batch
system ed i job vengono simulati normalmente. Per la prima volta quindi si osserva la
produzione di un ordine di scheduling simulato diverso da quello osservato.
La cosa non deve allarmare. Data la presenza di un evento eccezionale verificatosi nel
mondo reale, il mancato soddisfacimento della condizione di “identicità tra scheduling
reale e simulato”, non invalida il simulatore in questa prova. Molto semplicemente la
validazione “black box” non è applicabile a questo caso124. Si è insomma nella
circostanza descritta nel precedente paragrafo “5.2.3.7” e quindi la rinuncia all'uso del
criterio di validazione “black box”, può trovare un succedaneo nella “verifica di
previsione”. Tornando alla Figura 5.15 quindi, il lettore non farà fatica a constatare che,
date le policy stabilite, i job ed il loro accodamento, la previsione sullo scheduling che
una corretta simulazione dovrebbe fornire, è effettivamente quello riportato in figura.
Malgrado quindi la necessità del cambio “in corsa” del criterio di validazione, anche
questa verifica si considera andata a buon fine.
5.3.5.4 Repliche dei test sui limiti statici
Le tre prove precedentemente descritte sono state opportunamente replicate, con policy
di restrizione formulate per una coppia di gruppi e per una coppia di code. Ogni test è
andato a buon fine e non si sono riscontrate ulteriori anomalie.
5.3.6 Conclusioni riguardo i test di validazione
Si conclude la parte relativa alla validazione del simulatore di Maui, avendo raggiunto
l'obbiettivo minimale che ci si è preposti. Il numero esiguo delle verifiche effettuate,
non pretende certo di aver mostrato l'assoluta bontà dello strumento in questione ma
l'andata a buon fine di ognuno dei semplici esperimenti compiuti, permette già un
dignitoso grado confidenza nella correttezza logica di questo. Le prove di validazione
hanno inoltre prodotto un prezioso patrimonio di informazioni sul simulatore stesso,
permettendo di prevenire a monte, situazioni che ne comprometterebbero
irrimediabilmente l'affidabilità.
124 Ben diverso sarebbe stato il caso in cui la discrepanza dei due scheduling (reale e simulato) non fosse
stata accompagnata dal riscontro di nessuna anomalia o comportamento imprevisto nella traccia reale.
134
Capitolo 6
ANALISI DEI DATI E STRUMENTI
DI MISURA
6.1 Tracce di Maui
Più volte in precedenza si è parlato del file di traccia Maui e della ricchezza del suo
contenuto informativo ai fini di analisi e statistiche.
Dei quarantadue campi informativi, che ogni record contiene, non tutti hanno comunque
la stessa importanza. In particolare, tre soli di questi condensano una grossa parte delle
informazioni di reale interesse, ai fini dell'analisi dello scheduling effettuato.
Tali campi contengono le tre informazioni temporali fondamentali di ogni job
processato dal sistema:
➢ Tempo di sottomissione al batch system (accodamento)
➢ Tempo di inizio esecuzione
➢ Tempo di fine esecuzione
La valenza del contenuto di queste tre componenti di traccia, in fatto di informazioni
apportate, va ben oltre la semplice indicazione dei tempi assoluti a cui gli eventi si
verificano. Semplici sottrazioni tra tali valori ( relativi a job all'occorrenza selezionati
secondo un qualche criterio) producono informazioni derivate di grande importanza,
come ad esempio: durata del tempo in coda del job, durata dell'esecuzione, durata
complessiva, tempo trascorso tra fine esecuzione di un job e l'allocazione dello stesso
nodo al job successivo, ecc.
La semplice manipolazione dei valori dei campi temporali, permette già un'analisi
elementare dello scheduling dei job contenuto in una traccia Maui e la verifica di alcuni
risultati attesi. Questo approccio seppur qualitativo, combinato con opportune tecniche
di visualizzazione, consente di mettere in luce informazioni piuttosto interessanti.
135
6.2 Semplici esempi di analisi delle tracce
Le immagini che seguono sono state ricavate da file di traccia reali, creati dal batch
system del sito INFN GRID di Perugia. I record di tali tracce sono stati di volta in volta
“filtrati” in funzione dell'osservazione di interesse. I valori temporali riportati, sono
derivati dai tre campi fondamentali precedentemente descritti. Ogni immagine sarà
presentata brevemente, spiegando il tipo di rappresentazione, l'insieme dei dati e
l'interpretazione degli stessi.
6.2.1 Tempo in coda dei job di certificazione
L'appartenenza della farm INFN di Perugia al contesto della griglia computazionale
GRID, comporta per essa la ricezione periodica, di brevi job per testare lo stato e la
reattività del sistema, chiamati job di certificazione. Questi job godono di un trattamento
ad elevata priorità, affinché una loro pronta computazione, ritorni all'ente di verifica le
informazioni sulla corretta operatività del sistema. Si osservi La Figura 6.1
Figura 6.1
Distribuzione dei tempi in coda per i job di certificazione di GRID.
L'immagine mostra la distribuzione dei job relativamente al tempo trascorso in coda
prima di essere eseguiti. La durata di tale attesa è ricavata come differenza tra tempo di
avvio di esecuzione e tempo di accodamento del job.
136
In ascissa è riportato il tempo di permanenza in coda in secondi, mentre in ordinata il
numero di questi. Entrambe le scale sono logaritmiche. L'osservazione è stata condotta
sui soli job di certificazione, opportunamente estratti dalla traccia completa. Come è
facile notare, la maggior parte di questi passa in esecuzione entro un secondo
dall'accodamento ed entro i primi dieci secondi, la quasi totalità di questi sono stati
eseguiti. Si osservi ora la seguente Figura 6.2.
Figura 6.2
Rappresentazione integrale pesata della distribuzione di Figura 6.1
L'immagine rappresenta un modo alternativo di raffigurare lo stesso insieme di dati,
dell'immagine precedente. In ascissa è ancora riportata l'attesa in coda dei job di
certificazione ma in ordinata si ha ora, l'integrazione125 della distribuzione di questi,
pesata sul numero complessivo dei job. Questo significa che ad ogni secondo in ascissa
corrisponde in ordinata la percentuale di job avviati all'esecuzione entro quel tempo.
L'immagine conferma appieno quanto osservato nella precedente: entro i primi 120
secondi, circa il 97% dei job di certificazione accodati ha raggiunto un nodo di calcolo
per l'esecuzione, dimostrando da parte del sistema una reattività più che adeguata per il
rispetto del protocollo di feedback di GRID.
125 In questo caso per integrazione si intende, che il numero di job che terminano la propria attesa in coda in
dato tempo, è sommato al numero dei job che complessivamente sono passati in esecuzione fino a quel
momento.
137
6.2.2 Ricerca di job di certificazione “periodici”
Lo stesso insieme di job di certificazione che è stato oggetto della precedente analisi,
viene ora utilizzato per una nuova indagine, volta alla verifica della periodicità con cui
un certo tipo di job di certificazione perviene al batch system via GRID.
Figura 6.3
Distribuzione dei tempi che separano due accodamenti consecutivi dei job di certificazione.
Il grafico di Figura 6.3 mostra la distribuzione dei tempi che intercorrono tra due
sottomissioni consecutive di job di certificazione. Le durate degli intervalli (espresse in
secondi) sono riportate in ascissa, mentre in ordinata c'è il numero di job
corrispondente.
Come evidente dalla figura, i job di test consecutivi sottomessi ad intervalli superiori ai
2000 secondi sono in numero esiguo e la loro distribuzione non mostra concentrazioni
significative. Gli intervalli che invece vanno da 0 a 1500 secondi sono caratterizzati da
fluttuazioni di distribuzione con picchi molto stretti. Questa situazione scarsamente
leggibile è conosciuta e deriva dall'interferenza delle diverse frequenze temporali di
sottomissione, dei vari tipi di job di certificazione. L'unica parte significativa del grafico
riprodotto, è quella centrata attorno ai 1800 secondi. Il picco che si vede è ben isolato,
dotato di una certa consistenza e simmetria. Ciò non è casuale, in quanto il protocollo di
certificazione di GRID prevede tra gli altri, l'invio di un particolare job di test ad
intervalli regolari di trenta minuti, vale a dire ogni 1800 secondi. Il numero soverchiante
di questi “check job” periodici rispetto a tutti gli altri, ne consente il riconoscimento
138
anche all'interno di una distribuzione “contaminata” come la precedente. Se fosse stato
possibile filtrare la traccia dagli altri job di certificazione, il picco di periodicità a 1800
secondi sarebbe stato ancor più isolato, alto e definito.
6.2.3 Sottomissione massiccia di job utente
La stessa tipologia di grafico introdotta per l'esempio precedente, viene ora riproposta
relativamente alla distribuzione dei tempi tra job consecutivi di un solo utente.
Figura 6.4
Distribuzione dei tempi che separano due accodamenti consecutivi dei job di un particolare utente del sito INFN GRID di Perugia.
Come si evince dalla Figura 6.4, la distribuzione degli intervalli tra la sottomissione di
un job ed il successivo, mostra un accumulo verso i tempi bassi: un chiaro segno che i
job sono stati sottomessi in maniera massiccia, a pacchetti di centinaia ognuno.
Gli esempi di analisi della traccia Maui fin qui riportati, svelano aspetti interessanti del
batch system ma rappresentano un approccio non adeguato allo studio delle grandezze
fondamentali del problema dello scheduling. Tali “grandezze” saranno individuate e
valutate, a partire dal prossimo paragrafo, al fine di produrre gli strumenti finora
mancanti, per un'analisi non solo qualitativa ma anche quantitativa dei file di traccia.
139
6.3 Metriche di valutazione
La possibilità di determinare la bontà delle policy adottate per un batch system, dipende
essenzialmente dall'individuazione di grandezze particolarmente significative, la cui
misura permetta di quantificare, quanto ci si è avvicinati o allontanati da un certo
obbiettivo.
Come si ricorderà dal secondo capitolo, la formulazione del problema di ottimizzazione
della farm INFN del sito di Perugia, richiede il bilanciamento delle esigenze di utenti e
gruppi da un lato e dell'amministratore del sistema dall'altro. Per i primi due la richiesta
è in particolare che lo scheduling prodotto dal sistema, dimostri equità nei loro
confronti126, per l'amministratore l'obbiettivo è invece che il sistema operi con la
massima efficienza possibile, garantendo il migliore utilizzo dello hardware. Appare
dunque chiaro che le grandezze significative per il sito in questione, siano proprio:
• l'equità dello scheduling effettuato sulla base delle policy impostate e dei job
sottomessi;
• l'efficienza con cui il batch system ha compiuto la sua attività di raccolta, esecuzione e
restituzione dei job sottomessi dagli utenti.
La definizione di cosa si intenda esattamente per queste due quantità e la formulazione
dei rispettivi criteri (metriche) di valutazione, è oggetto dei successivi paragrafi 6.3 e
6.4, mentre nel prossimo saranno forniti al lettore gli strumenti per comprendere
agevolmente tali definizioni.
6.4 Rappresentazione
Le tre grandezze temporali fondamentali citate in precedenza, vale a dire tempo di
accodamento, di inizio esecuzione e completamento del job, sono alla base della
definizione dei concetti di equità, efficienza e delle relative metriche di valutazione. Al
fine di una loro semplice trattazione visiva, si consideri che queste individuano
virtualmente una coppia di segmenti consecutivi: il primo è la permanenza in coda127 del
job, il secondo la sua durata di esecuzione, come mostrato in Figura 6.5.
126 Lo scheduling dei job deve essere tale da garantire il più possibile che la quantità di risorse che spetta ad
ogni utente o gruppo, venga ad esso allocata quando questi ne hanno bisogno, nel minor tempo possibile.
Il significato della parola “spetta” dipende da vari fattori, tra cui: chi ha materialmente pagato le risorse,
quale priorità scientifica viene assegnata al lavoro, ecc.
127 Nel caso in cui il job sia eseguito nello stesso secondo in cui è accodato, questo intervallo è nullo.
140
Job n
Inizio esecuzione
Accodamento Fine esecuzione
Permanenza
in coda
Durata
esecuzione
Tempo
Figura 6.5
Rappresentazione di un job in base alla permanenza in coda ed alla durata di esecuzione.
Data la rappresentazione quindi, qualsiasi insieme di job proveniente da una traccia
Maui, ordinata per tempo di accodamento, apparirà come una serie di coppie di
segmenti, così come mostrato in Figura 6.6.
(Running Job)
(Queued Job) 02 1013 3
0 0 1 3 4 3 2
Job 1
Job 2
Job 3
Q
R
1
1
Intervalli di sovrapposizione dei job
......
Figura 6.6
Rappresentazione dei job estratti da un file di traccia Maui, ordinati per tempo di accodamento. La figura è completata dal conteggio dei job in coda e in esecuzione, per ogni intervallo di sovrapposizione.
La Figura 6.6 mostra inoltre quelli che sono stati definiti come “intervalli di
sovrapposizione” dei job, ossia gli intervalli temporali individuati da uno qualsiasi dei
tre valori temporali di un job (accodamento, inizio esecuzione e completamento) con
uno qualsiasi dei tre tempi di tutti gli altri job. Ogni intervallo rappresenta cioè un lasso
di tempo al cui interno non si verifica ne sottomissione, ne avvio o fine di nessun job.
La suddivisione dell'arco temporale complessivo in intervalli di sovrapposizione,
permette di poter associare ad ognuno di questi sia il numero di job in coda sia quelli in
esecuzione durante il relativo lasso di tempo. L'attribuzione di questi valori è stata
riportata nella parte superiore della precedente Figura 6.6.
141
6.5 Metrica di equità
Dal punto di vista di un utente, e parimenti di un gruppo, l'equità “Eq” che il sistema
dimostra nei suoi confronti, in un dato istante, è piena (Eq=1), se almeno tutte le risorse
di calcolo a cui questi ha diritto, sono assegnate all'esecuzione dei suoi job oppure se
non ha propri job in coda. E' invece nulla (Eq=0) quando nessuna delle risorse è
allocata, ed i job dell'utente restano in attesa in coda. Ovviamente sono possibili un
certo numero di valori intermedi (0<Eq<1) a seconda della situazione contingente. La
definizione della metrica di valutazione per l'equità, sarà introdotta avvalendosi della
Figura 6.7.
(Running Job)
(Queued Job) 02 0023 3
0 0 1 2 4 2 0
Job 1
Job 2
Job 3
Job 4
Job 5
Q
R
(Equitàelementare)
Eqɛ
10 11 ⅔0 ⅓ ⅓
1
1
(Risorse spettanti di diritto) = 3 Nodi di calcoloRis
i1
i2
i3
i4
i5
i6
i7
i8
Job 6
ΔT1
Figura 6.7
Rappresentazione dei soli job di un dato utente, in ordine di accodamento. Per ogni intervallo di sovrapposizione sono riportati il totale dei job in coda, in esecuzione e l'equità elementare.
La Figura 6.7 mostra un insieme di job appartenenti ad un solo utente128, elencati per
ordine di accodamento. Come si nota sono riportati tutti gli intervalli di sovrapposizione
(numerati da i1 ad i8) ed i conteggi del numero di job in coda “Q” ed in esecuzione “R”.
Per ogni intervallo si è aggiunto un ulteriore parametro, chiamato equità elementare
“Eqɛ” che esprime per ogni intervallo di sovrapposizione, il valore dell'equità con cui il
sistema ha trattato i job dell'utente in questione. Si è inoltre assunto che il numero nodi
di calcolo (“Ris”), spettanti di diritto all'utente in questione, siano tre.
128 Quanto detto per i job di un utente vale in maniera perfettamente analoga per i job un gruppo.
142
Il criterio di calcolo dell'equità elementare è dato dal seguente algoritmo, espresso nella
sintassi del linguaggio C:
If ( Q == 0 || R >= Ris ) {
Eq ɛ = 1} else { if ( Q > Ris - R) {
Eq ɛ = 1 - (( Ris -R ) / Ris) } else {
E ɛ = 1 - (Q / Ris) }}
Nei casi elementari di code vuote o fruizione di un numero di risorse maggiore o uguale
a quelle spettanti si assume l'equità elementare piena, ossia uguale ad “1”. Negli altri
casi, “( Ris - R ) / Ris” o “Q / Ris” rappresentano la porzione di risorse “negate”, dati i
job in coda che potrebbero utilizzarle, vale a dire l'iniquità del sistema in
quell'intervallo. Sottraendo quindi ad “1” questi valori, si avrà la complementare equità
elementare. Il precedente algoritmo di calcolo può essere espresso in maniera molto più
concisa dalla seguente formula:
Eqɛ=1−minQ ,Ris−R
Ris
Si assuma ora che i valori ΔT1, ΔT2, ecc. rappresentino le durate dei rispettivi intervalli
di sovrapposizione. Il calcolo del valore “globale” di equità, cioè l'equità del sistema
nell'arco di tempo spaziato dai job dell'utente, è definito come la seguente media pesata:
Eq=∑j=1
n
Eqɛj∗ΔT j
∑j=1
n
ΔT j
Il calcolo di questa metrica è effettuato da un'apposita funzione dello script workload-
analyzer.pl,uno dei tool già descritti nel capitolo 4.
143
6.6 Metrica di efficienza
Dal punto di vista dell'amministratore del batch system, l'efficienza “Eff” con cui opera
il sistema, in un dato istante, è piena (Eff=1) se tutti i nodi di calcolo che lo
compongono sono impegnati nell'esecuzione dei job. Ovviamente, il caso di efficienza
nulla (Eff=0) si avrà nella situazione opposta, in cui malgrado la presenza di job in
coda, nessuno dei nodi di calcolo è impegnato in una computazione. I valori intermedi
possibili sono tali che 0<Eff<1 e a breve si fornirà il criterio per la loro valutazione.
(Running Job) 0 0 1 2 4 3 0
Job 1
Job 2
Job 3
Job 4
R
(Efficienzaelementare)
Effɛ ¾0 01⅟20 ¼
0
(Risorse complessive del batch system) = 4 Nodi di calcoloRisSys
i3i
1i2
i4
i5
i6
i7
i8
Job 6
Job 5
¼
Figura 6.8
Rappresentazione dei job di una traccia Maui, in ordine di accodamento. Per ogni intervallo di sovrapposizione sono riportati il totale dei job in esecuzione e l'efficienza elementare.
La Figure 6.8 mostra, secondo l'ormai consueta rappresentazione, l'insieme di tutti i job
eseguiti in certo lasso di tempo. Per ogni intervallo di sovrapposizione, si riporta il solo
conteggio dei job in esecuzione “R”, in quanto ai fini del calcolo dell'efficienza, è
indifferente la conoscenza del numero di job in coda. La definizione della metrica di
efficienza si avvale, in analogia al caso precedente, del concetto di efficienza elementare
“Effɛ” che esprime il valore di tale grandezza, per gli intervalli di sovrapposizione dei
job. Esso è definito come il rapporto:
Eff ɛ=R
RisSys
Dove “RisSys” è il totale delle risorse del sistema, cioè il numero dei nodi di calcolo.
144
Il calcolo dell'efficienza globale del sistema (cioè su tutto l'arco di tempo spaziato dai
job), richiede inoltre l'introduzione del concetto di efficienza del sistema relativa
all'attesa di un job “EffJob”.
Siano ΔT1, ... , ΔTm, le durate dei soli intervalli di sovrapposizione, in cui è partizionata
l'attesa in coda di un certo job e siano inoltre Eff 1ɛ .. Effɛ m le efficienze elementari del
sistema per gli stessi intervalli, l'efficienza di tale job è definita come segue.
• Se il tempo di attesa in coda del job è nullo (il job inizia ad eseguire nello
stesso secondo in cui è stato sottomesso):
EffJob=1
• In tutti gli altri casi:
EffJob=∑i=1
m
Eff ɛi∗ΔT i
∑i=1
m
ΔT i
E' evidente che un job che passi in esecuzione appena accodato, debba necessariamente
percepire il servizio offerto dal batch system nei suoi confronti, come pienamente
efficiente (EffJob=1).
Quando per il job c'è invece attesa in coda, la valutazione dell'efficienza del servizio
offerto, dipende da quanto tale attesa è “motivata” da un'effettiva occupazione delle
risorse di calcolo nella computazione di altri job129.
La seconda delle due formule esprime quindi la media delle efficienze elementari, per
gli intervalli in cui il job è stato in coda, pesata sulla durata degli intervalli stessi. Essa
rappresenta la misura, di quanto l'attesa in coda sia stata accompagnata da un
funzionamento efficiente del sistema.
A questo punto risulta di una certa facilità la definizione dell'efficienza complessiva del
batch system come:
Eff=∑1=1
n
EffJobi∗ΔQi
∑i=1
n
ΔQi
129 Se infatti è efficiente (oltre che ragionevole) che un job attenda in coda, mentre il sistema è pienamente
impegnato nell'elaborazione di tutti gli altri job con priorità maggiore, non può certo considerarsi
efficiente lo stare in coda a fronte di una qualche inattività dei nodi di calcolo.
145
dove “ΔQ i ” è il tempo in coda del job i-esimo ed “n” il numero dei job considerati.
L'efficienza complessiva del sistema, relativamente alla computazione di tutti i job
compresi entro un dato intervallo di tempo, è quindi espressa come la media
dell'efficienza dei singoli job pesata sulle rispettive durate dei tempi in coda.
Il calcolo di questa metrica è effettuato da un'apposita funzione dello script workload-
analyzer.pl.
146
6.7 Intervallo di interazione Maui / TORQUE
ed efficienza del sistema
Si riporta un semplice caso di studio, per mostrare la dipendenza che intercorre tra il
tempo trascorso tra due interazioni successive130, tra lo scheduler (Maui) ed il proprio
resource manager (TORQUE), e l'efficienza del sistema calcolata con la metrica appena
definita.
La constatazione iniziale è che il lasso di tempo trascorso tra ogni interazione
(interrogazione), comporta una certa latenza nell'acquisire informazioni da parte dello
scheduler ed un pari ritardo, nel comunicare i comandi conseguenti al resource manager.
Durante tali intervalli, può quindi accadere che risorse di calcolo tornate fruibili, non
siano tempestivamente allocate al successivo assegnatario, lasciando i nodi liberi
inattivi. Alla luce di quanto visto definendo il concetto di efficienza e la relativa metrica,
ci si attende che il sistema sia soggetto ad un calo di efficienza tanto maggiore quanto
più grande è l'intervallo tra due interrogazioni successive di Maui a TORQUE.
L'intervallo in questione può essere impostato in Maui (sia per lo scheduler reale che
per il simulatore) con l'apposito parametro del file di configurazione
“RMPOLLINTERVAL”.
L'esperimento di verifica è stato condotto avvalendosi di alcuni degli strumenti già
descritti nel quarto capitolo, in particolare del tool di simulazione enumerativa.
Partendo da una traccia reale opportunamente generata dal batch system di test, si è
proceduto ad eseguire 60 diverse simulazioni della stessa, variando in ognuna il valore
RMPOLLINTERVAL del simulatore dal valore di 1 secondo a quello di 60 secondi. Per
ognuna delle 60 simulazioni si è eseguita una valutazione dell'efficienza del sistema,
analizzando la traccia relativa secondo le regole della metrica definita.
I risultati ottenuti sono quindi stati riportati nella seguente Figura 6.8 per una facile
valutazione visiva.
130 Si ricordi che uno scheduler non si occupa direttamente della gestione del batch system ma si avvale
dell'operato di un apposito resource manager. Tale lontananza dello scheduler dall'amministrazione a
basso livello del sistema, comporta la necessità di una periodica interazione col resource manager per
acquisire tutte le informazioni sullo stato del sistema e comandare le operazioni decise per i job.
147
Figura 6.9
Efficienza del sistema virtuale al variare del parametro RMPOLLINTERVAL tra 0 e 60 secondi.
Il grafico in figura mostra in ascissa l'ampiezza in secondi dell'intervallo tra
un'interazione tra scheduler e resource manager (virtuali) ed in ordinata il relativo
valore di efficienza del sistema simulato. Come si vede il calo di efficienza pronosticato
è effettivamente osservabile, anche se di modestissima entità. La massima perdita di
efficienza (tra 1 e 60 secondi) si attesta infatti, ad un valore di 0,00002.
Vale la pena osservare che i valori di efficienza per il sistema simulato sono comunque
ben al di sopra di quanto accade nella realtà (come ci si attende). La valutazione di
efficienza eseguita sulla traccia reale, usata come base per le simulazioni, ha infatti
prodotto il valore 0.960288.
Si riporta infine un grafico (Figura 6.10) attinente il presente esperimento.
Figura 6.10
Durata dei tempi di simulazione al variare del parametro RMPOLLINTERVAL tra 0 e 60 secondi.
148
La Figura 6.10 mostra la correlazione tra il valore attribuito ad RMPOLLINTERVAL ed
il tempo di calcolo della simulazione. Si nota chiaramente che più le interrogazioni dello
scheduler al resource manager sono frequenti, più l'elaborazione della traccia reale
diventa onerosa, in particolare avvicinandosi al minimo intervallo di comunicazione (1
secondo) il tempo che si deve attendere prima di conoscere l'esito della simulazione
cresce molto rapidamente.
Questa osservazione suggerisce dunque di trovare un ragionevole punto di equilibrio tra
l'accuratezza della “risoluzione temporale” della simulazione ed il tempo che si può
dedicare al calcolo di questa, tanto più che come si è mostrato, la differenza in termini
di efficienza misurata per il sistema simulato, è praticamente trascurabile nell'arco di
intervalli di interazione fino ad un minuto.
149
150
CONCLUSIONI
Durante questo lavoro di tesi, che ha conglobato anche lo stage, portato a termine presso
la sezione INFN di Perugia ed il locale Dipartimento di Fisica, ho avuto modo di
affrontare varie problematiche, a partire dagli aspetti inerenti lo scheduling di job in un
batch system concreto. A questa fase preliminare è seguita quella di comprensione del
funzionamento del batch system del sito INFN GRID di Perugia, con tutte le sue
complessità, problematiche e peculiarità, compresi i particolari vincoli di utenza che lo
caratterizzano. Una prima parte del mio lavoro è consistita nella produzione di strumenti
software per l'analisi di tale sistema, e nell'allestimento di una infrastruttura
hardware/software dedicata, tra l'altro, alla validazione del simulatore di Maui. La
produzione di tali strumenti è coincisa con lo studio del linguaggio di scripting Perl, il
cui utilizzo è stato fondamentale per il raggiungimento degli obbiettivi.
Le prime e reali difficoltà incontrate, hanno riguardato le iniziali prove di utilizzo del
simulatore di Maui. In esso si è scoperto e corretto un bug di funzionamento e per esso è
stata prodotta documentazione per il corretto utilizzo, visto che quella ufficiale è
pressoché inesistente. Una parte considerevole del lavoro è coincisa con la formulazione
di una strategia di validazione del citato simulatore e l'esecuzione dei relativi test di
verifica. L'esito di tali prove ha dimostrato che lo strumento è affidabile relativamente
alla correttezza logica dello scheduling simulato, mentre la riproduzione della scala
temporale risulta leggermente falsata.
L'ultima parte del mio lavoro è consistita nella formulazione di due metriche per la
misurazione di grandezze di primaria importanza nello scheduling di job, individuate
nell'ambito della ricerca svolta.
Complessivamente il lavoro si è articolato su vari fronti, ed ha prodotto in me
conoscenze molteplici e variegate, la cui utilità va ben oltre il semplice completamento
del presente lavoro di tesi.
Le prospettive di sviluppo futuro si diramano in almeno tre direzioni. L'applicazione
delle metriche di valutazione, può sfociare in un'analisi sistematica della grande mole di
dati fin qui prodotti, da anni di attività della farm INFN.
L'infrastruttura allestita per la validazione può essere facilmente evoluta in un apparato
automatizzato, per la validazione con metodo Montecarlo del simulatore di Maui.
Infine, molti degli strumenti software sviluppati, sono già stati concepiti nell'ottica
dell'integrazione, in un algoritmo genetico per la ricerca, tramite simulazioni, di
soluzioni a specifici problemi di scheduling, da trasferire poi nel sistema reale.
Per il prossimo futuro, quest'ultimo è l'obbiettivo più ambizioso.
151
152
RINGRAZIAMENTI
Il mio primo ringraziamento è rivolto al Prof. Leonello Servoli, per l'opportunità datami
di intraprendere questo percorso di tesi e per la grande disponibilità dimostrata nei miei
confronti. Ringrazio quindi Mirko Mariotti, senza il cui aiuto determinante e paziente,
avrei continuato a pensare a Maui come una delle isole delle Hawaii ed a Linux come
una semplice alternativa a Windzoz®.
Grazie agli amici della biblioteca di matematica, grazie a Giampaolo, Fiorella, Shirin,
Nicoletta, Monica, Fabio, Luca, Sara e Giuliano per aver condiviso negli anni questa
reciproca avventura e per il piacere della loro quotidiana presenza.
La mia riconoscenza alle fanciulle di Via Appia, Giovanna e Chiara per i mille caffè
“scroccati” nel tempo (ma soprattutto per la loro amicizia :-) ed a Valentina “Marm”
semplicemente perché è come è.
Un grazie per avermi “sopportato” tutto questo tempo ai miei compagni di casa vecchi e
nuovi: Samuele, Sara, Daniele R, Martina, Eugenio e Melania. Grazie ad Antonietta per
ognuno di quei meravigliosi pranzi cucinati, grazie di cuore.
Infinita gratitudine ai miei amici-fratelli del servizio civile, Ciccio, Miccione e Carpa
per le serate piacevoli e rilassanti trascorse insieme tra un esame e l'altro.
Grazie infine ai miei genitori, per il loro supporto e la loro pazienza in questi anni e
soprattutto, per il loro amore di sempre.
153
154
APPENDICI
Appendice A1
makeuser.sh
#!/bin/bash
# Descrizione:# Questo script esegue l'aggiunta di nuovi utenti in un sistema Linux, in base ad una lista di input # in cui gli utenti ed i gruppi di appartenenza sono specificati secondo il formalismo: ## nome_utente : gruppo_appartenenza_principale [altri_gruppi]## La creazione di utenti (e gruppi) avviene in maniera tale che questi abbiano lo stesso User # (e Group) Idetification (ID) su tuttele macchine su cui lo script è eseguito, data ovviamente la # stessa lista utenti-gruppi.
# makeusers version 1.2
# ---------------------------------------------VARIABLES------------------------------------------------------
DELETE_INTERVAL_ONLY=false # Flag per la sola cancellazione degli utenti.
EXEC_ERR=65 # Codice errore di esecuzione.PARAM_ERR=66 # “ “ parametri input.ABORTED_BY_USER=67 # “ interruzione da parte dell'utente.
LOW_ID_LIMIT=1000 # Limite inferiore spazio ID.LOW_ID=$LOW_ID_LIMIT
HIGH_ID_LIMIT=65000 # Limite superiore spazio ID.HIGH_ID=$HIGH_ID_LIMIT
# Versione dello scriptVERSION='makeusers Version 1.2 01.09.2007 By FrancescoKant'
makeuserhomedir='-m' # Flag per la crezione o meno delle home. directories.
# ------------------------------------------------Functions-------------------------------------------------------
# show_help ()# # Stampa a schermo lo help di questo script.
show_help (){ echo 'Usage: makeusers [-i ID] [-I ID] [-H] FILENAME' echo ' makeusers [-h] [-d] [-v]' echo echo 'Options:' echo ' -h, --help display this help message and exit' echo ' -i, --min_id IDVALUE specify the interval`s lower limit for users and' echo " groups deletion based on their ID value (default $LOW_ID_LIMIT)" echo ' -I, --max_id IDVALUE specify the interval`s upper limit for users and' echo " groups deletion based on their ID value (default $HIGH_ID_LIMIT)" echo ' -H, --no_homedir the user home directory will not be created (default is create)' echo ' -d, --del_only remove users and groups only and exit' echo ' -V, --version display the version and exit'
exit 0}
155
# remove_old_users_and_groups ()## Rimuove dal sistema tutti gli utenti il cui ID è compreso tra [LOW_ID, HIGH_ID]# (se nell'intervallo non ci sono utenti, nessuna azione è intrapresa).
remove_old_users_and_groups () { echo
# Chiede conferma per procedere while [[ "$ANSWER" != "yes" ]]; do echo -n "WARNING: users and groups whit ID in [ $LOW_ID - $HIGH_ID ] will be deleted /
from the local system. Do you want to proceed? (yes/no): "
read ANSWER
if [[ "$ANSWER" = "no" ]]; then exit $ABORTED_BY_USER fi done
# Seleziona gli utenti con lo ID nell'intervallo specificato e li cancella. temp=`awk -F : -v low=$LOW_ID -v high=$HIGH_ID /
'{if (($3 >= low) && ($3 <= high)) print $1}' /etc/passwd`
if [[ $temp != "" ]]; then echo $temp | xargs -n 1 userdel -rf; fi
# seleziona i gruppi con lo ID nell'intervallo specificato e li cancella. temp=`awk -F : -v low=$LOW_ID -v high=$HIGH_ID /
'{if (($3 >= low) && ($3 <= high)) print $1}' /etc/group`
if [[ $temp != "" ]]; then echo $temp | xargs -n 1 groupdel; fi
}
# make_new_users_and_groups ()## Crea nel sistema i nuovi utenti specificati nella lista in input allo script.
make_new_users_and_groups (){ # Prima crea nel sistema i gruppi a cui i nuovi utenti appartengono...
ID_VALUE=$LOW_ID groups=`sed -e 's/..* : //' $1 | xargs -n 1 | sort | uniq`
for group in $groups do eval "groupadd -g $ID_VALUE $group"
let "ID_VALUE += 1" done
# ...Poi crea gli utenti assegnandoli ai relativi gruppi. ID_VALUE=$LOW_ID { read USER_AND_GROUPS
while [[ $USER_AND_GROUPS ]] do USER_AND_GROUPS="$makeuserhomedir $ID_VALUE $USER_AND_GROUPS"
156
eval `echo $USER_AND_GROUPS | sed -e 's/ /,/g6' | awk '{ if( $6 == "" ) printf "useradd %s -u %s -g %s %s\n", $1, $2, $5, $3 else printf "useradd %s -u %s -g %s -G %s %s\n", $1, $2, $5, $6, $3}'`
let "ID_VALUE += 1" read USER_AND_GROUPS done } < $1 }
# ----------------------------------------------Main Program----------------------------------------------------
# Acquisizione e parsing di opzioni e parametri in ingresso allo script.
while getopts ":hi:I:dHV" Optiondo case $Option in h | help ) show_help;;
i | min_id ) if [[ $OPTARG -gt $LOW_ID_LIMIT ]]; then LOW_ID=$OPTARG; fi;;
I | max_id ) if [[ $OPTARG -lt $HIGH_ID_LIMIT ]]; then HIGH_ID=$OPTARG; fi;;
d | del_only ) remove_old_users_and_groups; exit 0;;
H | no_homedir) makeuserhomedir='-M';;
V | version ) echo $VERSION; exit 0;;
* ) echo; echo 'Some paramaters are unknown, see the script usage'; show_help;; esacdoneshift $(($OPTIND - 1))# Verifica se l'utente ha specificato un file con la lista di nuovi utenti...if [[ -z "$1" ]]; then show_help; exit $PARAM_ERR; fi
# Verifica se il file specificato esiste...if [[ ! -e $1 ]]then echo "Execution aborted: \"$1\" file does not exist!" exit $PARAM_ERRfi
# Verifica se l'intervallo degli ID è corretto...
users=`wc -l $1 | cut -d ' ' -f1` # Conta gli utenti nel file.let "interval=$HIGH_ID-$LOW_ID+1" # Calcola l'ampiezza dell'intervallo.
if [[ $interval -lt $users ]] # Verifica se lo spazio degli ID è abbastanza ampio# da contenere tutti gli utenti presenti nella lista.
then echo 'Execution aborted: selected ID interval is smaller than users` number' exit $PARAM_ERRfi
# Richiama la funzione che rimuove dal sistema gli utenti in certo range di ID.remove_old_users_and_groups
# Richiama la funzione che crea nuovi utenti nel sistema in accordo alla lista passata in input.make_new_users_and_groups $1
exit 0
157
Appendice A2
sleep-launcher.sh
#!/bin/bash
# Questo script esegue in maniera automatica la sottomissione di job in un Batch # System basato su resource manager PBS o TORQUE. La sequenza di sottomissione # e' specificata in un file passato come argomento in cui i job da sottomettere # sono specificati secondo il formalismo: # # Username SubmissionTime QueueOfSubmission SleepTime # # "SubmissionTime" e' espresso in 'hh:mm:ss' di ritardo rispetto all'avvio dello # script, mentre gli altri campi del record debbono avere valori coerenti con # la configurazione del Batch Sistem e con il job che si sta' lanciando.
# sleep-launcher.sh version 1.3
SLEEP_TIME=1 # Intervallo tra ogni scansione della lista di lancio.
# Verifica se e' stato specificato il nome di un file con lo schedule di lancio # di job e se tale file esiste nella directory corrente.
if [ -z "$1" ] then echo -e "\nUsage: $0 launcher JOB_LAUNCH_SCHEDULE_FILE\n" exit 1 elif [ ! -e "$1" ] then echo -e "\nfile \"$1\" does not exist\n" exit 1 fi
scheduleLaunchFile=$1 # Prende il nome del file con lo schedule di lancio.
# Esegue la conversione dei tempi presenti nella sequenza di lancio nel file dal # formato hh:mm:ss nel formato "tempo assoluto Unix" e salva lo schedule coi tempi # "riscriti" in una variabile 'scheduleWithTimesInSeconds'.
scheduleWithTimesInSeconds=`awk ' { if ( ($0) && ($0 !~ /^#/) ) {
split($2, TIME_1, ":"); LaunchT_inSec=(TIME_1[1]*3600)+(TIME_1[2]*60)+TIME_1[3];
split($4, TIME_2, ":"); SleepT_inSec=(TIME_2[1]*3600)+(TIME_2[2]*60)+TIME_2[3];
printf "%s %s %s %s\n",$1, LaunchT_inSec, $3, SleepT_inSec;}
}' $scheduleLaunchFile`
# Determina a quale tempo sara' sottomesso l'ultimo dei job elencati nella sequenza # di lancio. Tale tempo verra' considerato per terminare l'esecuzione dello script # quando non ci saranno piu' job da lanciare.
158
relativeEndLaunchTime=`echo -e "$scheduleWithTimesInSeconds" | awk ' BEGIN { latestLaunchTime = 0 }
{ if ($2 > latestLaunchTime){ latestLaunchTime = $2 } }
END { print latestLaunchTime }'`
# Acquisisce il tempo corrente assoluto (Unix Time) in base al quale ricavera' poi # per differenza il tempo (relativo) trascorso dall'avvio della sequenza di lancio.
scriptStartTime=`date +%s`
lastLaunch=-1 # Tempo (relativo) a cui e' avvenuto l'ultimo lancio.
# Ciclo di lancio dei jobs. Ad intervalli regolari si valuta quali jobs hanno # raggiunto il loro tempo di lancio e li si sottomette al Batch System.
while ((1)) do
presentAbsoluteTime=`date +%s`
let "relativeTime=$presentAbsoluteTime-$scriptStartTime"
# Viene scandita la lista di lancio alla ricerca di jobs il cui tempo di sotto- # missione sia minore del tempo presente e maggiore del tempo dell'ultimo lancio.
submissionString=`echo -e "$scheduleWithTimesInSeconds" |\ awk -v now=$relativeTime -v before=$lastLaunch '
{ if (($2 <= now) && ($2 > before)) printf "echo \"sleep %d\" | sudo -u %s qsub -d /home/%s -q %s\n",$4,$1,$1,$3
}'` if [ ! -z "$submissionString" ]; then eval "$submissionString"; fi
# Si assume il tempo corrente come l'istante dell'ultimo lancio effettuato.
lastLaunch=$relativeTime
# Verifica condizione di uscita dal ciclo di lancio e rapporto di esecuzione. if [ "$relativeEndLaunchTime" -lt "$relativeTime" ] then echo echo "Launching of the jobs in '$scheduleLaunchFile' was completed by '$0'" echo "in $relativeEndLaunchTime seconds. Last job submitted `date`" echo
exit 0 fi
sleep $SLEEP_TIME # Pausa per non saturare la Cpu.
done
exit 0
159
Appendice A3
workload-time-updater.pl
#!/usr/bin/perl
# Descrizione:# Questo script riceve in input un file di traccia di Maui ed aggiorna i valori temporali riportati nei# campi : QueueTime, DispatchT, StartTime, CompleteT in base ad un valore temporale di offset,# specificato anch'esso come parametro in input.
# workload-time-updater.pl Version 1.1
$workload=$ARGV[0]; # Acquisisce il nome del file di traccia Maui da aggirnare.
$workloadnew=$ARGV[1]; # Acquisisce il file su cui scrivere la traccia aggiornata.
$offset=$ARGV[2]; # Acquisisce il valore di offset temporale.
open(WRK, $workload);
open(WRKN, ">$workloadnew");
while (<WRK>)
{
if ((!/VERSION/)&&(!/Queue/)) # Ignora i commenti.
{
s/\s+/ /g;
# Aggiorna i tempi del file di traccia in base al valore di offset temporale.
@raw = split(/ /);
$raw[8]=$raw[8]+$offset;
$raw[9]=$raw[9]+$offset;
$raw[10]=$raw[10]+$offset;
$raw[11]=$raw[11]+$offset;
foreach $i (@raw)
{
print WRKN $i." "; # Aggiunge il record coi tempi
# aggiornati al file di output.
}
print WRKN "\n";
}
}
close (WRK);
close (WRKN);
160
Appendice A4
workload-analyzer.pl
#!/usr/bin/perl -w
# Descrizione:# Questo script opera una selezione dei record componenti un file di traccia Maui, in base a# condizioni specificate dall'utente. Le condizioni di selezione possono riguardare appartenenze # dei valori dei campi numerici ad intervalli od uguagliare singoli pattern numerici o stringhe. Per # ogni record che soddisfa la selezione, lo script restituisce i valori per quei campi che l'utente ha# specificato. Lo script può eseguire inoltre operazioni per l'ordinamento dei record selezionati (o # di loro porzioni) in base ad un campo chiave stabilito dall'utente. E' inoltre prevista una # funzione per la formattazione dell'output in modo da generare una sequenza di dati che se presa # in input dal programma di visualizzazione GNUPlot, riproduce la time-line di attività dei # nodi specificati dall'utente.
# Version 1.4
# PERL PRAGMAuse strict; # Tutte le variabili vanno dichiarate all'interno
# dei rispettivi ambiti di appartenenza.
# PERL MODULESuse Data::Dumper; # Utilità di visualizzazione di strutture (array-hash)use Getopt::Long; # Opzione per il formato delle opzioni 'long'
# ############################### PARAMETRI GLOBALI ################################
our $USAGE = "usage: $0 [--help] [--fields] [--in FieldName=numericValue] [--in FieldName=[intMin..intMax]] [--in FieldName=string] --out FieldName [--out FieldName] [--numsort NumericFieldName] [--avg FieldName] [--efficency NumCpu] [--equity NumCpu] [--noderunninghistory [intMin..intMax]] [--formattedout] TRACEFILENAME";
# Lista dei 44 campi del file di traccia (workload) di Maui.
our $FIELDSCHEMA = " JobID NRQ TRQ UserName GroupName WCLimit JobState Class QueueTime DispatchT StartTime CompleteT Network Arch Opsys MC Mem DC Disk Features SQTime Tas TPNd QOS Flags Account Command Comm Byp PSUtil Partition DProcs DMem DDisk DSwap StartDate EndDate MNode RMName HostList Reserv AppType RES1 RES2 ";
# Campi extra ricavati dal file di traccia # (tempo permanenza job in coda, durata esecuzione, tempo complessivo).
our $ADDEDFIELDS = "StayInQueueT ExecTime OverallTime ";
# ############################## SUBRUTINES ##################################
# FUNZIONI PER IL MATCHING DEI VALORI (NUMERICI O TESTUALI) RICHIAMATE # DALL'ALGORITMO DI SELEZIONE:
161
# Match di intervalli numericisub match_interval {
my ($numericValue, $min, $max) = @_;
return ($numericValue >= $min) && ($numericValue <= $max);}
# Match di stringhe.sub match_string{
my ($string, $stringPattern) = @_;
return ($string eq $stringPattern);}
# Match di valore numerico singolo.sub match_numericValue{
my ($numericValue, $numericPattern) = @_;
return ($numericValue == $numericPattern);}
# FUNCTION:___________________parseInputOptions_()_____________________________## Questa funzione effettua il parsing delle opzioni e dei parametri ricevuti in input dalla riga di # comando e seguendo tutti i controlli relativi alla correttezza delle opzioni sottomesse, al rispetto. # del formato di immissione e alla correttezza dei valori numerici. Se il parsing da buon esito, i # parametri raccolti vengono inseriti in una struttura di output (%opt) basata su un hash.
sub parseInputOptions {
# %inputOptions: Hash in cui GetOptions() inserisce le opzioni d'utenete. # %field_check: Hash per mappare i nomi di campo corretti. # %opt: Hash che raccogli tutte le opzioni in output alla funzione.
my (%inputOptions, %field_check, %opt);
# @_ è l'array coi nomi dei campi del file di traccia di Maui + i 'campi extra'. # Ciascun nome di CAMPO diventa una chiave di '%field_check'. Questo hash serve per # vedere se un valore letto da input e' davvero un campo della traccia di Maui.
foreach ( @_ ) { $field_check { $_ } = 1 }
# Acquisizione delle opzioni della riga di comando e travaso delle stessa in '%inputOptions'.
GetOptions( \%inputOptions, "help", "fields", "in=s@", "out=s@","numsort=s", "fill=s", "nodehistory=s" ) or die "$USAGE";
# Se una delle opzioni catturate prima richiede lo help, viene mostrato e l'esecuzione termina.
if ( $inputOptions { help }) { print "$USAGE\n"; exit } if ( $inputOptions { fields }) { print "fields:$FIELDSCHEMA\n$ADDEDFIELDS\n\n"; exit } # PARSING DELL'OPZIONE (--in) .............................................................................................
foreach (@{$inputOptions{in}}) {
# %inputOptionserifica sei il formato '--in FieldName=pattern' è rispettato.# Se non è rispettato scrive un messaggio nello STDERR e termina l'esecuzione.
m/^[A-Z]([a-z]|[A-Z])+=.+$/ or die "\nThe ' --in $_ 'option format is not correct\n$USAGE\n";
162
# Separa il parametro dell'opzione (--in) nel nome di un campo della traccia Maui e# ed il relativo valore da matchare.
my ($tempField, $tempPattern) = split "=";
# Verifica se il nome del campo è corretto.
$field_check{$tempField} or die "'$tempField' fieldname not exists\n\nfields:
$FIELDSCHEMA\n$ADDEDFIELDS\n\n";
# Questa struttura CASE riconosce il tipo di pattern# e lo inserisce nella struttura appropriata all'interno dello hash: '%out_option'.
PATTERN:for ($tempPattern) {
/^\[\d+\.\.\d+\]$/ && do { s/\[//; # rimuove la prima parentesi quadra: min..max]s/\]//; # rimuove la seconda parentesi quadra: min..max
# separa min..max inserendoli in $min & $maxmy ($min, $max) = split /\.\./;
# Assegna il puntatore della giusta funzione di matching# ed gli estremi dell'intervallo da passare alla funzione.
$opt{in}{$tempField}{ function } = \&match_interval;$opt{in}{$tempField}{ paramList } = [ $min, $max ];
last PATTERN };
/^\d+(\.\d+)?$/ && do {# Assegna il puntatore della giusta funzione di matching# ed il valore numerico da matchare.
$opt{in}{$tempField}{ function } = /\&match_numericValue;
$opt{in}{$tempField}{ paramList } = [ $_ ];
last PATTERN };
/^\w+(\.[a-z]+)*$/ && do { # Assegna il puntatore della giusta funzione di matching# e la stringa da matchare.
$opt{in}{$tempField}{ function } = \&match_string;$opt{in}{$tempField}{ paramList } = [ $_ ];
last PATTERN };
# Se l'esecuzione dello script raggiunge questo punto, allora qualcuno dei parametri # passati con le opzioni è sbagliato: scrive un messaggio di errore termina esecuzione. die "\nThe pattern '$_' is not correct!\n$USAGE\n"
} }
163
# PARSING DELL'OPZIONE ( --out ) .......................................................................................
# Verifica se i nomi dei campi passati, sono corretti.
foreach (@{$inputOptions{ out } } ) { $field_check{$_} or die "'$_' fieldname not exists\n\nfields:$FIELDSCHEMA\n$ADDEDFIELDS\n\n" }
$opt{ out } = $inputOptions{ out }; # restituisce uno hash con le opzioni di output.
# PARSING DELL'OPZIONE ( --numsort ) ................................................................................ if ($inputOptions{ numsort } ) {
# Verifica se la chiave di ordinamento è un nome di campo di file di traccia Maui.
$field_check{ $inputOptions{ numsort } } or die "'$inputOptions{ numsort }
' fieldname not exists\n\nfields:$FIELDSCHEMA\n$ADDEDFIELDS\n\n";
# Verrifica se la chiave scelta è un campo numerico.
( $inputOptions{ numsort } =~ /^(JobID|NRQ|TRQ|WCLimit|QueueTime|DispatchT|StartTime|CompleteT|Mem|Disk|SQTime|Tas|TPNd |PSUtil|DProcs|DMem|DDisk|DSwap|StartDate |EndDate|StayInQueueT|ExecTime|OverallTime)$/) or
die "Numeric sorting of '$inputOptions{ numsort }' is not permitted\n";
# Setta l'opzione corrispondente (sorting numerico) dello hash di output: '%opt'.
$opt{ numsort } = $inputOptions{ numsort };
# aggiunge il campo di traccia alla lista dei campi in output se questo non è già stato# selezionato con una opzione ( --out ).
if (scalar @{ $opt{ out } }) { my $flag = 1; foreach ( @{ $opt{ out } } ) { if ( $_ eq $opt{ numsort } ) { $flag = 0; last } }
push @{ $opt{ out } }, $opt{ numsort } if $flag;}else { push @{ $opt{ out } }, $opt{ numsort } }
}
# PARSE --efficency OPTION -------------------------------------------------------- if ($inputOptions{ efficency } ) {
$opt { efficency } = $inputOptions{ efficency };
$opt { out } = ["QueueTime", "StayInQueueT", "StartTime", "CompleteT"]; $opt { numsort } = "StartTime";
}
# PARSE --avg OPTION --------------------------------------------------------------- if ($inputOptions{ avg } ) {
# $field_check{ $inputOptions{ avg } } or die "\n'$inputOptions{ avg }' fieldname not
exists\n\nfields:$FIELDSCHEMA\n$ADDEDFIELDS\n\n";
164
# Assegna alla struttura delle operazioni in uscita il campo di aggregazione. $opt{ avg } = $inputOptions{ avg };
my $flag = 1; # aggiunge ai campi selezionati per l'output if (scalar @{ $opt{ out } }) { foreach ( @{ $opt{ out } } ) {
# Vede se il campo su cui agrregare per mediare, e' presente tra quelli selezionati per
l'output. if ( $_ eq $opt{ avg } ) { $flag = 0 }
# Verifica se i campi selezionati per l'output contengono valori numerici (e quindi mediabili).
else { ( $_ =~ /^(JobID|NRQ|TRQ|WCLimit|QueueTime|DispatchT
|StartTime|CompleteT|Mem|Disk|SQTime|Tas|TPNd |PSUtil|DProcs|DMem|DDisk|DSwap|StartDate |EndDate|StayInQueueT|ExecTime|OverallTime)$/) or die "\nAverage function is impossible for '$_' field. Remove
it!\n\n"; }
}
push @{ $opt{ out } }, $opt{ avg } if $flag; }
else { push @{ $opt{ out } }, $opt{ avg } } }
# PARSE --formattedout OPTION --------------------------------------------------------------- if ($inputOptions{ formattedout } ) {
$opt{ formattedoutput } = "format1";
}
# exit if no fields are selected for the output die "No output field is selected\n$USAGE\n" unless (scalar @{ $opt{ out } });
# TEST: remove the '#' coming first 'print' command to display relative data structure. #print Dumper(\%inputOptions); #print Dumper(\%opt);
return \%opt }
# FUNCTION:____________selectFieldsAccordingOptions_($, @, %)____________________## Questa funzione effettua la selezione delle righe del file di traccia in cui i valori dei campi# soddisfano le condizioni di matching stabilite con le opzioni ( --in ). Per ogni riga selezionata # vengono estrapolati i soli campi specificati dalle opzioni ( --out ). #
sub selectFieldsAccordingOptions {
my $file = shift; # Riceve il nome del file di traccia. my @field_schema_array = @{ shift @_ }; # “ hash col formato del recor di traccia. my %opt = %{ shift @_ }; # “ le opzioni di selezione.
my ( %fields_hash, @selected_fields_array, $temp );
165
open FILE, "$file" or die "Impossible to open file '$file' : $!";
# Legge una riga alla volta tutti i record del file di traccia di Maui.
RECORD: while ( <FILE> ) { next if /^#/; # Rimuove i commenti. next if /^$/; # Rimuove le linee vuote. next if /^VERSION/; # Rimuove il “numero di versione” di Maui chomp;
# Divide il record della traccia in tutti i suoi 44 campi e ne inserisce i valori in un hash # dello stesso formato in corrispondenza del rispettivo nome di campo.
@fields_hash { @field_schema_array } = split " ", $_;
# "StayInQueue" : numero di secondi che il job attende in coda. # "ExecTime" field : numero di secondi della durata di esecuzione del job. # "OverallTime" : numero di secodi dalla sottomissione del job alla sua finalizzazione.
$fields_hash { StayInQueueT } = $fields_hash { DispatchT } - $fields_hash { QueueTime };
$fields_hash { ExecTime } = $fields_hash { CompleteT } - $fields_hash { StartTime };
$fields_hash { OverallTime } = $fields_hash { CompleteT } - $fields_hash { QueueTime };
# Verifica se il record corrente verifica tutte le condizioni di selezione.# Se ciò non accade passa al record successivo.
foreach ( keys %{$opt{in}} ){
next RECORD unless ($opt{in}{$_}{"function"}->($fields_hash{$_}, @{$opt{in}{$_}{"paramList"}}));
}
# Aggiunge una hash dei campi selezionati, al vettore dei record selezionati.
foreach (@{ $opt { out } } ) { $temp -> { $_ } = $fields_hash { $_ } }push @selected_fields_array, $temp;$temp = {};
}
close $file;
return \@selected_fields_array; # Ritorna l'array dei campi del record selezionati.# D'ora in avanti lo chiameremo tabella delle selezioni.
}
# Funzione di sorting per riordinare la tabella delle selezioni in base al campo chiave specificato.
sub sorting { my @table = @{ shift @_ }; my %opt = %{ shift @_ }; my @sorted_fields = sort {
$a -> {$opt{numsort}} <=> $b -> {$opt{numsort}} } @table;
return \@sorted_fields; # Ritorna la tabella ordinata.}
166
# Funzione per il calcolo dell'efficienza dei job
sub calculateEfficency { my @table = @{ shift @_ }; my %opt = %{ shift @_ };
my ($jobEfficency, $intersection); my ($totalQueueTime, $globalEfficency) = (0, 0);
my $nuberOfJob = scalar @table;
for (my $i = 0; $i < $nuberOfJob; $i++) {
# Aggiunge la durata del tempo in coda del job corrente alla variabile che alla fine conterrra' il totale. $totalQueueTime += $table[$i]{StayInQueueT};
if ($table[$i]{StayInQueueT} == 0) { $jobEfficency = 1 }
else {
$jobEfficency = 0;
for (my $j = 0; $j < $i; $j++) {
if ($table[$i]{QueueTime} < $table[$j]{CompleteT}) {
$intersection = -abs($table[$i]{QueueTime} - $table[$j]{StartTime}); $intersection += abs($table[$i]{QueueTime} - $table[$j]{CompleteT}); $intersection += abs($table[$i]{StartTime} - $table[$j]{StartTime}); $intersection -= abs($table[$i]{StartTime} - $table[$j]{CompleteT}); $jobEfficency+=$intersection }
}
$jobEfficency /= ( $opt{efficency} * $table[$i]{StayInQueueT} * 2 ) }
#$jobEfficency = sprintf("%.6f", $jobEfficency);
#$table[$i]{JobEfficency} = $jobEfficency; $globalEfficency += $jobEfficency * $table[$i]{StayInQueueT};
}
$globalEfficency /= $totalQueueTime;
# Aggiunge alla lista dei campi in uscita, quello "JobEfficency" push( @{ $opt{ out } }, "JobEfficency" );
return \@table }
# Funzione per il calcolo della media dei valori per campo di aggregazione
sub average { my @table = @{ shift @_ }; my %opt = %{ shift @_ };
my (%aggregation_by_field, @avgTable);
# Raggruppa in base al campo di aggregazione. # Per tutti i campi che non sono # quello di aggregazione, somma (accumula) i valori del record corrente... foreach my $temp_ref ( @table ) {
167
foreach ( @{ $opt{ out } } ) {
if ( $_ ne $opt{ avg } ) {
$aggregation_by_field{${$temp_ref}{ $opt{avg}}}{$_} += ${$temp_ref}{$_}; } } # incrementa il contatore del raggruppamento corrente. ++$aggregation_by_field { ${ $temp_ref }{ $opt{ avg }}}{ total_of_job };
}
# ...Poi divide per le occorrenze contate, facendo la media e costruisce # la tabella di output con tutte le medie calcolate. foreach my $aggregated (sort keys %aggregation_by_field){
foreach ( @{ $opt{ out } } ) {
if ( $_ ne $opt{ avg } ) {
$aggregation_by_field {$aggregated}{$_} /= $aggregation_by_field {$aggregated}{total_of_job};
} } $aggregation_by_field {$aggregated}{$opt{ avg }} = $aggregated; push @avgTable, $aggregation_by_field {$aggregated};
}
push ( @{ $opt{ out } }, "total_of_job" ); # Aggiunge il numero di occorrenze ad ogni campo di aggregazione
return \@avgTable }
# Funzione per la generazione di dati per la raffigurazione dell'attività dei nodi attrverso il tool GNUPlot.
sub print_GnuPlot_Format_Run_NodeHistory { my @lines = @{ shift @_ }; my $quotaOffset = shift @_; my $array_size = scalar @lines; my $previous_end_time = 0; my (@overlaing_lines, $halfExecTime, $intervalCenter, $quotaByNodeNomber);
return unless ($array_size); # se non ci sono piu' elementi nell'array, arresta la ricorsione.
$lines[0]{ MNode } =~ /(\d+)/; $quotaByNodeNomber = $1 + $quotaOffset;
foreach ( @lines ) { if ( ${ $_ }{ StartTime } >= $previous_end_time ) {
$halfExecTime = ${ $_ }{ ExecTime }/2; $intervalCenter = ${ $_ }{ StartTime } + $halfExecTime;
$previous_end_time = ${ $_ }{ CompleteT };
printf "%s %s %.4f %s %s\n",$intervalCenter, $quotaByNodeNomber, $halfExecTime, ${ $_ }{ JobID }, ${ $_ }{ UserName };
$previous_end_time = ${ $_ }{ CompleteT }; }
else {push( @overlaing_lines, $_ )};
168
}
&print_GnuPlot_Format_Run_NodeHistory( \@overlaing_lines, ($quotaOffset - 0.05) ); }
# Funzione per la stampa semplice, su STDOUT, dei valori della tabella delle selezioni.
sub basicPrint { my @selected_fields = @{ shift @_ }; my %opt = %{ shift @_ }; my $temp_ref; foreach $temp_ref ( @selected_fields ) { foreach ( @{ $opt{ out } } ) { print ${ $temp_ref }{ $_ }, " " } print "\n"; }}
# ########################### MAIN PROGRAM #################################
# Converte la lista dei campi del file di traccia Maui (più i campi extra), in un array di nomi di# campo.
my @field_schema_array = split " ", $FIELDSCHEMA . $ADDEDFIELDS;
# Si richiama la funzione che fa il parsing delle opzioni ed i relativi parametri sottomessi da riga di# comando. '%opt' è un'unica struttura dati globale in cui sono stati raccolti tutti le opzioni ed i# parametri letti e riconosciuti dall'operazione di parsing.
my $opt_ref = &parseInputOptions(@field_schema_array);
# A questo punto tuutte le opzioni sono state catturate: se chi ha invocato lo script ha specificato il# nome di un file di traccia, esso è rimasto in ARGV[0]. Se il nome non è presente si andranno a # cercare i dati nello STDIN.
$ARGV[0] ? ( my $file = $ARGV[0] ) : die "Please, enter 'TRACEFILENAME' ! \n$USAGE\n";
# Si richiama la funzione che seleziona, in base alle condizioni stabilite dall'utente, i campi della# traccia che soddisfano le condizioni. Dalla funzione si riceve la tabella delle selezioni.
# seleziona i dati dalla traccia di Maui e mettili nella tabella puntata da "$selected_fields_ref". my $selected_fields_ref = &selectFieldsAccordingOptions( $file, \@field_schema_array, $opt_ref );
# Se la tabella dei valori selezionati dalla traccia Maui non e' vuota, vai avanti. if (scalar @$selected_fields_ref) {
# Effettua il sorting dei record della tabella dei job selezionati rispetto ad un campo numerico (se l'operazione e' richiesta) if ($$opt_ref { numsort } ) { $selected_fields_ref = &sorting( $selected_fields_ref, $opt_ref ) }
# Aggiunge alla tabella dei job selezionati una colonna con i valori di efficienza di ogni job if ($$opt_ref { efficency }) {
$selected_fields_ref = &calculateEfficency( $selected_fields_ref, $opt_ref) }
# Effettua la media dei valori selezionati in base ad un campo di aggregazione. if ($$opt_ref { avg } ) { $selected_fields_ref = &average( $selected_fields_ref, $opt_ref ) }
169
# FUNZIONI DI STAMPA DELLA TABELLA DELLE SOLUZIONI
my %GroupLinesByNodeName; if ( $$opt_ref { noderunninghistory } ) {
foreach my $line (@{$selected_fields_ref}) {
push (@{$GroupLinesByNodeName{${$line}{MNode}}}, $line); }
foreach (keys %GroupLinesByNodeName) {
#print "$_\n"; &print_GnuPlot_Format_Run_NodeHistory( $GroupLinesByNodeName{$_}, 0 ) }
}
# elsif ( $$opt_ref { formattedoutput } ) { print Dumper($selected_fields_ref) }
# else { &basicPrint ( $selected_fields_ref, $opt_ref ) } }
# ----------------------------------------------------------------------------------------------------- Kant Fecit
170