Porting di applicativi Scientici Paralleli in INFN GRID. Università degli studi di Parma. Facoltà di Scienze Matematiche, Fisiche e Naturali

Transcript

1 Università degli studi di Parma Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Triennale in Fisica Porting di applicativi Scientici Paralleli in INFN GRID Relatore: Dott. ROBERTO ALFIERI Candidato: CORNIA FABRIZIO Anno Accademico Aprile 2008

2 A Tiziano e Cristina 1

3 Ringraziamenti Un amico mi ha detto: i ringraziamenti si fanno alla ne, la tesi triennale non è la ne... Io i ringraziamenti li faccio lo stesso, anche perchè è probabile che questa sia davvero la ne della mia carriera universitaria, anche se il futuro non ci è mai noto. In primis sono obbligato a ringraziare la mia famiglia. Ha tanti limiti, si, ma quali famiglie non li hanno?? E allora ringrazio per tutte le volte che mi avete sostenuto, Tiziano e Cristina, vi ringrazio per ogni momento in cui non l'ho fatto e vi chiedo scusa per ogni momento in cui ho pensato a prendere per me, senza donare la gratitudine verso la famiglia che un glio dovrebbe esprimere sempre. Se sono arrivato a questo traguardo, una buona parte del merito è vostro, perchè io da solo forse non ce l'avrei fatta. In casa mia, poi, non si può dire famiglia senza dire nonna. Il mio 'sponsor' principale in questi anni universitari è una persona magnica e incredibile; ha uno spirito che sembra proprio inattaccabile da qualsiasi evento e tantomeno dallo scorrere del tempo. Vorrei tanto capire che ne hanno fatto oggi quei geni nel mio patrimonio, e nella speranza che prima o poi rispuntino fuori ti ringrazio per tutte le volte che mi hai ricordato l'esistenza del mestiere del benzinaio quando arrivavo a casa tua (non troppo frequentemente... ) distrutto dai miei problemi (però le volte che venivo ero sempre così... ). E ti ringrazio per tutte le volte che hai detto che sono il nipote più bello del mondo (anche alle nonne degli altri) e che assomiglio a Manuel, con la solita modestia e pacatezza che ti contraddistingue (ma mia mamma è davvero tua glia?). Chiusa la dovuta parentesi famigliare (Birillo lo ringrazio dopo... ) ringrazio... eh, tutti! Giulia, perche mi hai sempre sostenuto, e mi hai sopportato per lunghi anni di sottile inquietudine senza mai vedermi troppo contento o sucientemente sereno, sempre restio nel concederti riposo o un meritato spuntino penso che si, tu ti sia meritata la santità. Poi ci mettiamo il Dott. Roberto Aleri, che sospetto abbia scoperto che la pianicazione non è la mia dote principale; ha 'soerto' con me il parto (prematuro) di questa tesi e veramente mi ha donato molto, in termini professionali e umani; la sua gura resterà sempre nel mio cuore come uno dei lati migliori di questa università. Ringrazio i miei compagni di corso, che per lungo tempo sono stati il vero motore della mia avventura universitaria; ringrazio proprio tutti: Nicolò, Rocco, Alberto, Carlo, Mirco, Marco, Murco (ops...), Matteo, Daniele, Paolo, Nicola, Alice, Rita, Giulia, Davide. La distribuzione di importanza di questi 2

4 ce è una Gaussiana, si, altrimenti starei mentendo, ma molto molto poco piccata. E' stato bello condividere con voi questi anni preziosi; per me sono stati colmi di momenti fantastici, e non li scorderò mai. E'impossibile scrivere una riga per ciascuno, scriverei un libro. Perdonatemi, ma rendetevi conto... Come è possibile dimenticare i primi giorni, i primi laboratori, gli anni passano, il periodo dei 'Nerz', quando ridevamo in continuazione sempre e comunque; come è possibile elencare la vagonata di cose belle che abbiamo vissuto insieme, quando eravamo giovani di belle speranze e spensierati? Gli scherzi con l'acqua a Carlo, la celebre birra Amoretti fatta con Marco, i soprannomi idioti tipo Bottleneck, il feeling con Rocco, i discorsi politici con Paolo, la serietà di Nicola, l'angelo custode della Giulia, gli abbracci dell'alice, i racconti di Mel, la disponibilità del Bronz, la vicinanza di Nicolò, la bontà innita di Alberto, la forza di Daniele, la err... 'inumanità' di Carlo. Mi sono reso conto che alla ne... sto scrivendo un commiato (malinconico per giunta, come è nel mio stile). Volevo ringraziare un sacco di altra gente, i povigliesi, i reggiani, le fans di puianello, gli scienziati dei materiali, Marco Ana che, Cristo Santo, andavo a casa sua a giocare con il 286, e 18 anni dopo siamo più amici di prima. Volevo ringraziare tanta gente, ma quello che mi stringe il cuore adesso siete Voi, i miei amici universitari. Mi sto rendendo conto che il tempo della vita sta volando e di quanto siete stati importanti per me, per la mia felicità e per la mia serenità; ormai è giunta l'ora in cui la Compagnia dei Nerds si deve sciogliere, e in realtà dentro di me si è già sciolta da qualche mese, perchè non sono più riuscito a vivere l'università con la positività che mi ha sempre avvolto, forse pagando molto salato il prezzo della mia indolenza. Molte cose sono cambiate, non sorrido più svelto come prima, ma porto nel cuore ogni singola goccia del ruscello di felicità che mi avete fatto sgorgare dentro, e per questo non riuscirò a ringraziarvi mai abbastanza, è impossibile. Non voglio scrivere frasi di convenienza; le strade della vita ci portano lontano, e stare vicini sarà dura. Ma come dicono i Nani, tra un buon amico e uno cattivo ci sono trent'anni di dierenza. farò del mio meglio per esserlo un buon amico, e per portare a voi sempre il meglio di me. Si può fare. 3

5 Indice 1 Introduzione 6 2 L'architettura GRID WLCG/EGEE Panoramica glite Struttura di un sito User Interface Computing Element Storage Element Information Service Data Management Workload Management System il Job Description Language Request e Job Types Job Attributes Resource Attributes Utilizzo generale dell'architettura GRID Porting di applicazioni parallele Analisi delle performances di algoritmi paralleli Speedup Ecienza Isoecienza e scalabilità Dimensione massima del problema Valutazione dell'ambiente GRID Interrogazione del BDII riguardo all'hardware Interrogazione del BDII riguardo al Software Cenni di analisi delle architetture di rete Benchmarking architetture di rete Hardware delle architetture di rete Esempi di utilizzo Sintesi per l'utente

6 4 MPI su GRID Overview Funzionalità Implementazioni OpenMPI Supporto attuale di MPI su Grid Sviluppo La situazione su INFN GRID La soluzione attuale: Mpi-Start Test MPI-START Cactus Introduzione Thorns struttura di un Thorn Congurazione e produzione dell'eseguibile Creare una congurazione Componenti aggiuntivi Esecuzione di Cactus Test locale WaveToy Porting di Cactus su GRID Sviluppi futuri Conclusioni 63.1 INFN GRID Architetture hardware

7 Capitolo 1 Introduzione Negli ultimi decenni si è assistito a una sempre maggiore crescita del fabbisogno di risorse di calcolo per la risoluzione di problemi scientici, simulazioni teoriche ed elaborazione di dati sperimentali. A questa crescita la comunità scientica (da sempre nota per la capacità di ottenere grandi risultati con pochi fondi) e l'industria informatica hanno fatto fronte con la nascita e lo sviluppo del Calcolo Parallelo. Il Calcolo Parallelo si riferisce alla possibilità di velocizzare l'esecuzione di un codice per mezzo di elaboratori che sfruttano l'utilizzo simultaneo di un numero (anche) elevato di processori. Tutto ciò è ottenuto attraverso tecniche di programmazione che permettono di suddividere un codice sequenziale in sottoprogrammi o sottoprocessi, che sono in grado di essere eseguiti simultaneamente su più processori. Questa tecnica di programmazione è detta Programmazione Parallela. Seguire questo tipo di approccio ha portato negli anni alla nascita di dierenti architetture e a dierenti modi di programmare le architetture parallele, a dierenti implementazioni delle librerie di comunicazione stesse, creando un universo ricco ed eterogeneo. Questa tecnologia ha avuto come motore di sviluppo il grande interesse della scienza: al giorno d'oggi è praticamente impossibile fare ricerca scientica senza calcolatori. Gli scienziati di tutto il mondo stanno arontando problemi con un grado di complessità sempre più elevato, e questi problemi richiedono molto più di una lavagna per essere risolti. Quando un cluster o addirittura un supercalcolatore custom non sono più bastati a soddisfare le necessità che si sono incontrate approcciando problemi complessi, si è iniziato a pensare a una rete di supercalcolatori che fornisse la potenza adeguata per portare avanti progetti ambiziosi. 6

8 Grazie alla crescenti performances delle tecnologie di interconnessione, si è assistito allora alla nascita delle Griglie Computazionali. Ma cos'è una griglia computazionale? Cos'è GRID? E' possibile spiegarlo utilizzando un paragone con Internet: mentre il web è un servizio per condividere informazioni sulla rete, GRID è un servizio per condividere risorse di calcolo e di memoria sulla rete. GRID va ben oltre la semplice comunicazione e interconnessione tra computers: mira a commutare le reti globali di computers in una grande risorsa computazionale. Questo obiettivo è una speranza, un sogno; come vedremo GRID al momento è un work in progress, e la tecnolgia che ne sta alla base, la sua architettura, è studiata da centinaia di ricercatori in tutto il mondo. GRID è quindi capace di fornire all'utente un notevole pool di risorse che altrimenti non avrebbe a disposizione, ma queste, tornando al discorso precedente,sono disomogenee. Ad oggi, i siti di calcolo mettono a disposizione per l'esecuzione via GRID architetture dierenti, calcolatori e strati di comunicazione più o meno performanti, code più o meno utilizzate e, non ultimo, strato software dierente. Se questa eterogeneità rappresenta un problema marginale per quanto riguarda l'esecuzione di job sequenziali, nel caso si stia parlando di Calcolo Parallelo assume una rilevanza di primo piano. L'assenza di uniformità hardware/software ha reso di fatto molto complessa la creazione di una rete unicata di calcolo parallelo distribuito. La grande sda delle persone che stanno lavorando a questo progetto è cercare di integrare in GRID il maggior numero di risorse, nascondendo all'utente la complessità e la varietà dell'architettura sottostante, e mettendolo in grado di sfruttare velocemente e semplicemente la potenza della computazione parallela. 7

9 Questa tesi vuole essere un punto sulla situazione attuale, un'analisi sulle problematiche da arontare oggi quando si intende portare un codice o un'applicazione scientica parallela sull'architettura GRID. Il punto di vista utilizzato è quello di un'utente che inizia da zero il suo 'viaggio' e progressivamente, aronta le problematiche che gli si presentano, a causa dell'immaturità dell'architettura. Per questo motivo, in prima battuta è stato redatto un capitolo sulla struttura di GRID, per comprenderne il funzionamento, punti di forza e debolezze. Il cuore del lavoro è stato, una volta conosciuta l'architettura, cercare di capire come ottenere i massimi beneci da una esecuzione GRID di un applicativo parallelo. Arontare questa parte del lavoro ci ha portato a scontrarci con le limitazioni e la relativa giovinezza di questa architettura, che rendono al momento, in Italia, sconveniente l'utilizzo di codici paralleli su GRID. Successivamente siamo stati 'costretti' a parlare di MPI e del suo supporto in GRID, dato che ad oggi, dire 'calcolo parallelo' equivale a dire 'MPI'; ossia il protocollo standard de facto per quanto riguarda la comunicazioni tra processi. Come ultima parte, è stato testato l'utilizzo di un applicativo parallelo di comune utilizzo tra i sici, quale CACTUS, che sfrutta MPI per implementare il parallelismo, e ci ha impegnato nel tentativo di renderne possibile l'esecuzione via GRID. 8

10 Capitolo 2 L'architettura GRID WLCG/EGEE 2.1 Panoramica glite Il middleware glite è sviluppato dal progetto EGEE che ha il principale obiettivo di fornire ai ricercatori l'accesso 24 ore su 24 a risorse di calcolo geogracamente distribuite su una rete GRID. Il principale fruitore dei servizi di glite è al momento LHC ossia il large hadron collider sviluppato al laboratorio europeo per la sica delle particelle, comunemente conosciuto come CERN. Il progetto per fornire l'infrastruttura di calcolo necessaria a sostenere LHC è chiamato Worldwide LHC Computing Grid Project o più brevemente (WLCG) ed opera in stretta congiunzione con l'egee. Attualmente l'infrastruttura production grid di WLCG/EGEE conta 200 siti distribuiti in tutto il mondo, ma primariamente in Europa, con più di CPU e 20 PB di data storage. L'LHC e gli esperimenti ad esso collegati sono il tipico esempio delle motivazioni che spingono a sviluppare la tecnologia GRID: generando un'enorme mole di dati, l'analisi di questi ultimi richiederebbe colossali risorse di calcolo e di storage, con il conseguente fabbisogno di risorse umane che questo comporta. 9

11 L'approccio scelto prevede, invece di una localizzazione massiva, che il servizio di calcolo dell'lhc sia implementato su una Griglia computazionale geogra- camente distribuita; questo prevede che il servizio utilizzerà risorse di calcolo e storage installate su un grande numero di siti, in molti stati dierenti, connessi da reti veloci. Il middleware glite nasconde agli utenti la gran parte della complessità di questa struttura, dando l'impressione che le risorse di calcolo siano disponibili in un unico centro di calcolo. Gli utenti di un'infrastruttura GRID sono divisi in Organizzazioni Virtuali: entità separate che raggruppano utenti, istituzioni e risorse, nello stesso dominio amministrativo; questa infrastruttura consente una più agile gestione delle risorse e del personale collegato, con una complessità allo stesso livello delle realtà locali, e non limita contemporaneamente l'accesso alle sole risorse locali relative a una VO o un sito. security Prima di poter utilizzare i servizi della griglia computazionale WLCG/EGEE l'utente dev'essere iscritto a una VO, e per fare questo deve aderire, oltre che alla policy della relativa VO, alle regole di utilizzo di WLCG/EGEE. Per autenticarsi alle risorse di GRID, è necessario utilizzare la Grid Security Infrastructure (GSI) che è basata sulla crittograa a chiave pubblica, sui certicati X.509, e sul protocollo di comunicazione Secure Socket Layer (SSL). L'utente deve disporre di un certicato X.509 rilasciato da una Certication Authority (CA) riconosciuta da WLCG/EGEE; le risorse di GRID stesse sono generalmente dotate di un certicato che permette loro di autenticarsi a loro volta all'utente. Il certicato dell'utente, con chiave privata protetta da password è usato per generare e rmare un certicato temporaneo (ordinariamente ha un lifetime di 12 ore) chiamato Proxy, che è a sua volta utilizzato per eettuare l'autenticazione alle risorse di GRID senza l'utilizzo di una password; il possesso del Proxy è 10

12 automaticamente considerato una prova d'identità dell'utente. Un utente per sottomettere un job necessita quindi di un Proxy valido; il job trasporterà una propria copia del Proxy per potersi autenticare sui servizi di GRID sui quali andrà in esecuzione. 2.2 Struttura di un sito User Interface Il punto di accesso di un utente alle risorse di GRID è chiamato User Interface (UI). Può essere un qualsiasi sistema dove è stato installato il middleware glite nella versione UI, dove l'utente possiede un account personale, e ha installato il suo certicato utente. Nella UI è presente una CLI (command line interface) che consente di accedere ai seguenti servizi. elencare le risorse disponibili per eseguire un determinato job conoscere lo stato delle risorse sottomettere un job per l'esecuzione cancellare un job recuperare l'output di un job completato conoscere lo stato di un job in esecuzione copiare e cancellare les da GRID Computing Element Un Computing Element nella terminologia di GRID è un insieme di risorse di calcolo localizzate in un sito, ed è composto da vari componenti: Grid Gate (GG) o interfaccia al cluster Local Resource Management System (LRMS) o semplicemente gestore delle code Worker Nodes (WN) ossia le risorse computazionali vere e proprie Nell'attuale WLCG/EGEE GRID è possibile implementare due dierenti Grid Gate, ai quali corrispondono CLI dierenti: l'lcg CE e il glite CE. Il GG ha il compito di accettare i job e di smistarli per l'esecuzione tramite il gestore di code, che a sua volta presenta varie implementazioni disponibili; glite supporta OpenPBS / PBSPro, LSF, Maui/Torque, BQS e Condor. Generalmente i WN di un sito sono installati con il medesimo sofware e le medesime librerie; spesso software dedicati per applicazioni speciche di una 11

13 VO possono essere installati in un'area dedicata come un le system condiviso da tutti i nodi. Code diverse su uno stesso cluster sono considerati dierenti CE Storage Element Lo Storage Element fornisce un accesso uniforme alle risorse di data storage, e può controllare qualsiasi tipo di risorsa; supporta dierenti protocolli di accesso ai dati, il cui principale, per il trasferimento di les è GSIFTP. Le risorse di storage spesso sono gestite da un servizio Middleware detto Storage Resource Manager (SRM) che, a seconda delle implementazioni è in grado di gestire la totalità delle problematiche di storage che si possono incontrare, come la migrazione dei dati da disco a nastro, l' accesso trasparente ai dati, il le pinning, l' allocazione preventiva dello spazio, la notica dello stato dei le, ecc... Il Middleware di GRID consente l'integrazione con i principali SRM utilizzati, per permettere di coprire la maggior parte delle necessità Information Service l' information Service (IS) fornisce informazioni sulle risorse della rete GRID WLCG/EGEE e sul loro stato. I dati Pubblicati dall'is sono conformi al GLUE Schema che denisce un modello concettuale comune, utilizzato per monitorare e scoprire le risorse di GRID; in glite sono utilizzati due sistemi IS: il globus Monitoring and Discovery Service (MDS) oppure il Relational Grid Monitoring Architecture (R-GMA) Il Monitoring and Discovery System implementa il GLUE Schema utilizzando OpenLDAP, un implementazione Open Source del LightWeight Directory Access Protocol (LDAP) ; un database specializzato nella lettura, ricerca, e indicizzazione delle informazioni. Il modello informativo di LDAP è basato su voci (persone, computer...), ognuna con uno o più attributi. Ogni voce ha un nome distinto (DN) che la identica, e ciascun attributo ha un tipo e uno o più valori. Un DN è formato da una sequenza di coppie attributo-valore e può essere organizzato secondo una struttura gerarchica ad albero, chaiamata Directory Infornation Tree (DIT) Lo Schema LDAP descrive le informazioni che possono essere immagazzinate in ciascuna voce del DIT, e denisce classi di oggetti, che sono raccolte di nomi di attributo e tipi di valore. Mentre una voce descrive qualche caratteristica, una classe di oggetti può essere vista come una descrizione generale di un oggetto. 12

14 Architettura dell' MDS Le risorse di calcolo e storage di un sito eseguono un software chiamato Information Provider, che genera le informazioni rilevanti riguardo una risorsa, statiche e dinamiche ( come le Risorse Hardware esistenti e quelle disponibili in quel particolare momento ). Queste informazioni sono pubblicate da un Server LDAP chiamato Grid Resource Information Server (GRIS) che generalmente è in esecuzione sulla risorsa stessa. In ogni sito esiste un'altro server LDAP chiamato site Grid Index Information Server (GIIS), che raccoglie le informazioni pubblicate dai GRIS di ogni elemento del sito, e le ripubblica. Per Immagazzinare e indicizzare i dati si utilizza il Berkeley Database Information Index (BDII). Un BDII è utilizzato anche al livello più alto della gerarchia, in modo da raccogliere e pubblicare le informazioni relative a tutti i siti WLCG/EGEE GRID di sua competenza. Questo servizio interrogherà i GIIS di ogni sito, e farà le veci di una cache, immagazzinando le informazioni sullo stato di Grid nel suo database, e conterrà tutte le informazioni disponibili riguardo ai siti di sua competenza Data Management L'unità primaria per la gestione dei dati, in Grid come nei normali calcolatori è il le. Chiaramente Grid è un architettura distribuita, quindi i les possono essere replicati su diversi siti. Un le può essere identicato senza ambiguità grazie al suo Grid Unique IDentier (GUID); questo gli viene assegnato la prima volta che viene registrato sulla rete Grid e la sua unicità è garantita dall'utilizzo di una combinazione nella generazione di MAC adress e orologio di sistema. Per localizzare un le, l'utente non utilizza però il GUID, bensì il Logical File Name (LFN) che è impostato dall'utente stesso. La posizione sica del le è invece identicata dallo Storage URL (SURL), mentre il Transport URL (TURL) fornisce le informazioni necessarie per scrivere o cercare una replica sica, includendo l'hostname, il percorso, il protocollo e la porta come un URL convenzionale. L'associazione tra LFN, SURL e TURL avviene tramite un servizio chiamato File Catalogue, mentre i le stessi sono immagazinati negli Storage Elements. Il servizio utilizzato per compiere i servizi di File Catalogue è il LCG File Catalogue (LFC) Workload Management System Il Workload Management System (WMS) è un sistema importantissimo ed è una parte centrale nell'architettura di grid; lo scopo del WMS è la distribuzione dei job (scheduling) tra le risorse di calcolo disponibili. 13

15 Le funzionalità che ore comprendono il raccogliere i job sottomessi dagli utenti, assegnarli al Computing Element più appropriato, monitorare e registrare il loro stato e inne recuperare il loro Output. Il sistema sul quale sono in esecuzione i servizi WMS è detto Resource Broker (RB). I Job che vengono sottomessi sono descritti utilizzando il Job Description Language (JDL) che specica tra i tanti parametri, quale eseguibile eseguire e i suoi parametri, i les che devono essere trasferiti e copiati da e verso i Worker Nodes sui quali è in esecuzione il Job e le condizioni imposte dall'utente che devono essere soddisfatte dai CE (risorse hardware, ambiente software, tempo di esecuzione del job). La scelta del CE sul quale viene inviato il Job è un processo chiamato matchmaking che seleziona, tra tutti i CE disponibili, quelli che soddisfano i requisiti espressi dall'utente, e tra questi, quelli più vicin a dove risiedono i dati e i les dell'utente. Quando questa prima parte del processo di selezione è completata, il WMS seleziona il CE con il più alto rank o grado; una quantità derivata dalle informazioni di status che trasmette il CE, che esprime la bontà di questo CE. Il modo con cui il WMS valuta il rank è anch'esso impostabile dall'utente (può essere il rapporto tra job in esecuzione e job accodati, oppure una discriminante sulle prestazioni, ecc... ). Il Logging and Bookkeeping service (LB) inne segue i jobs gestiti dal WMS; raccoglie i messaggi da tutti i componenti del WMS e registra lo status e la cronologia del job. 2.3 il Job Description Language Il Job Description Language è un linguaggio di alto livello user-oriented e nasce con la necessità di fornire un linguaggio descrittivo per esprimere le richieste di un utente che ha la necessità di compiere un lavoro su un'architettura GRID di calcolo distribuito. Il JDL è utilizzato in glite per specicare le caratteristiche del job e i relativi vincoli che sono utilizzati durante il processo di match-making per selezionare le risorse che il job può utilizzare. Gli attributi JDL rappresentano informazioni di richieste speciche e identicano le azioni che devono essere eseguite dal Workload Management System per compiere lo scheduling del Job. Le informazioni da specicare per l'esecuzione di un job Grid sono: requisiti sici del job (spazio disco, memoria...) requisiti logici del job (Sistema operativo, librerie, software...) Dati di Imput e Output (LFN) La sintassi dei le jdl è basata sul Condor ClassAD (CLASSied ADvertisement language) e consiste di coppie attributo / valore 14

16 E' necessario sottolineare, che essendo il JDL un linguaggio estensibile, all' utente è permesso utilizzare qualsiasi attributo per la descrizione del job, senza incorrere in errori; tuttavia quelli realmente presi in considerazione dal WMS sono solamente un certo set. le categorie di attributi disponibili si suddividono in Job Attribute (deniscono le caratteristiche del job) e Resource attribute, che deniscono le principali richieste per l'esecuzione del job. Alcuni dei parametri da inserire sono necessari, per altri invece il sistema può trovare un valore di default nel caso in cui non sia inserito dell' utente Request e Job Types La sintassi del tipo di richiesta selezionabile è: Type = Job; Il linguaggio JDL permette la descrizione dei seguenti tipi di richiesta: Job un semplice job DAG Direct Acyclic Graph: set di Job dipendenti Collection set di job indipendenti come si può notare il linguaggio Jdl permette l'esecuzione di gruppi di job in un sol colpo; il WMS fornirà all'utente un identicativo collettivo che permetterà all'utente di controllare il gruppo di Job con una singola richiesta. La sintassi per identicare il tipo di Job in esecuzione è: JobType = Normal; I tipi di Job correntemente supportati sono: Normal un semplice job interactive un job i cui streams standard sono indirizzati al client che l'ha lanciato. MPICH un job parallelo che usa l'implementazione MPICH-P4 di MPI, ma non solo, come vedremo in seguito. Il futuro è l'utilizzo di OpenMPI, ma, ad oggi, il tag utilizzato per identicare il tipo di Job MPI resta MPICH. Partitionable un Job che può essere composto da un set di iterazioni/passi indipendenti, come un set di sotto-job indipendenti. 15

17 Checkpointable un job capace si salvare il suo stato, così che l'esecuzione del job possa essere sospesa e ripresa più tardi, partendo dallo stesso punto in cui è stato fermato. Parametric un Job i cui attributi JDL contengono dei parametri come attributi, i quali valori possono essere variati, per permettere la sottomissione di varie istanze di Job simili, dierenti solo per il valore degli attributi parametrizzati. I Job partizionabili e parametrici sono logicamente simili ai DAG e alle Collection di Jobs; per questo motivo allo stesso modo, il WMS utilizzerà un identicativo collettivo per il monitoring e, al momento, i Job che compongono DAG o Collection non possono essere di tipo partizionabile e parametrico per le limitazioni del WMS Job Attributes Il JobType fa parte dei Job attributes; oltre a questo è possibile specicare: Executable nome del le che contiene il codice eseguibile Arguments argomenti da fornire all' eseguibile Stdimput, Stdoutput, Stderr nome dei le che conterranno standard input/output/error del job Environment lista di attributi relativi all'environment. ImputSandbox lista di le locali (rispetto alla UI) necessari all'esecuzione del Job (come l'eseguibile, le di dati, ecc... ). I les presenti nelle caselle ImputSandbox verranno trasferiti dalla UI utilizzata per l'accesso a grid al nodo WMS, e successivamente saranno trasferiti sui WN del CE dove il Job sarà eseguito tramite il WMS Job Wrapper Script. OutputSandbox lista di le generati dal Job da recuperare dopo l'esecuzione del Job: prima verranno salvati dal WMS per poi essere recuperati dall'utente. 16

18 VirtualOrganisation l'organizzazione virtuale che ha rilasciato il certicato proxy grazie al quale l'utente sta lavorando. RetryCount l'attributo è un numero intero che rappresenta il numero di volte che il Job sarà risottomesso in caso di un fallimento dello stesso. La risottomissione del Job si può denire Deep (fallimento mentre il job è in esecuzione sui WN) o Shallow (fallimento del WMS Job Wrapper prima dell'esecuzione). RetryCount imposta il massimo numero di Deep Resubmission. Generalmente il massimo numero di RetryCount permesso dal WMS è 10. ShallowRetryCount Come il campo precedente ma considerando una risottomissione Shallow MyProxyServer Identica l'hostname del Proxy Server nel caso l'utente stia utilizzando questo servizio per permettere l'esecuzione di Job di lunga durata. NodeNumber Parametro importante per l'esecuzione di Job paralleli, specica il numero di processori richiesto per un job di tipo MPICH, in esecuzione quindi con MPI. Il Resource Broker durante la selezione, sceglierà un CE con un numero di processori pari o superiore al valore del parametro Resource Attributes Il campo Requirements contiene argomenti che descrivono le richieste del Job riguardo alle risorse appartenenti al CE. E' composto da una serie di stringhe che inizia con la solita sintassi attributo-valore: Requirements = <...> In queste stringhe vengono valutate delle espressioni Booleane con operatori uguali agli operatori logici utilizzati nel linguaggio C; i parametri valutati vengono specicati tramite i nomi degli attributi deniti nel GlueSchema dell'information Service. Ad esempio, se volessimo richiedere un determinato software: Requirements = Member("DaVinci-v17r6",other.GlueHostApplicationSoftwareRunTimeEnvironment); La notazione prevede che al momento del match-making l'espressione venga valutata dal Resource Broker; per permettere l'esecuzione del Job sul CE considerato, tutti i campi inseriti nell'attributo requirements devono essere valutati veri. 17

19 Il campo Rank invece specica qual'è il parametro prescelto per esprimere (durante il Match Making) la preferenza sul CE da selezionare tra quelli che soddisfano i requisiti richiesti (ossia quelli che soddisfano le condizioni del campo Requirements). Anch'esso viene specicato utilizzando i nomi degli attributi utilizzati dall'is. Per esempio Rank = other.gluecepolicymaxrunningjobs - other.gluecestaterunningjobs classicherà i CE secondo il numero di slot a disposizione per eseguire il Job. Questo è un esempio di un semplice.jdl che esegue lo script di shell test.sh: # campo dei Job attributes Executable = "/bin/sh"; Arguments = "test.sh"; StdOutput = "hnam.out"; StdError = "hnam.err"; InputSandbox = {"test.sh"}; OutputSandbox = {"hnam.out","hnam.err"}; # campo dei requirements requirements = Member("MPICH",other.GlueHostApplicationSoftwareRunTimeEnvironment) && (other.gluecestatefreecpus>=4) && (other.gluehostoperatingsystemrelease == "LINUX") && (other.gluehostmainmemoryramsize >= 128) && (other.gluehostnetworkadapteroutboundip) && (other.glueceinfolrmstype == "torque" other.glueceinfolrmstype == "LSF") $$ Member("PARMA",other.GlueHostApplicationSoftwareRunTimeEnvironment) && TRUE ; 2.4 Utilizzo generale dell'architettura GRID 1. Dopo aver ottenuto un certicato digitale da una Cerication Authority riconosciuta, essersi registrato a una VO e aver ottenuto un account su una UI, l'utente è in grado di ottenere un certicato Proxy per autenticarsi sulla rete di calcolo distribuito. Se il certicato è correttamente installato, il comando grid-cert-info ci restituirà informazioni sul certicato stesso. 18

20 Certificate: Data: Version: 3 (0x2) Serial Number: 7685 (0x1e05) Signature Algorithm: sha1withrsaencryption Issuer: C=IT, O=INFN, CN=INFN CA Validity Not Before: Jul 25 13:02: GMT Not After : Jul 24 13:02: GMT Subject: C=IT, O=INFN, OU=Personal Certificate, L=Parma, CN=Fabrizio Cornia Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (2048 bit) Modulus (2048 bit): ecc... Mentre il comando voms-proxy-init -voms theophys Genererà il proxy per l'esecuzione. Your identity: /C=IT/O=INFN/OU=Personal Certificate/L=Parma/CN=Fabrizio Cornia Creating temporary proxy... Done Contacting voms-01.pd.infn.it:15006 [/C=IT/O=INFN/OU=Host/L=Padova/CN=voms-01.pd.infn.it] "theophys" Done Creating proxy... Done Your proxy is valid until Sat Apr 12 05:03: E' possibile vericare quali sono i CE che soddisfano alle Request del le.jdl sottomesso.: edg-job-list-match test.jdl 2. Per sottomettere un Job dalla UI e scrivere il jobid su un le: edg-job-submit -o jobid test.jdl 19

21 Selected Virtual Organisation name from proxy certificate extension): theophys Connecting to host egee-rb-01.cnaf.infn.it, port 7772 Logging to host egee-rb-01.cnaf.infn.it, port 9002 ========================== edg-job-submit Success ============== The job has been successfully submitted to the Network Server. Use edg-job-status command to check job current status. Your job identifier (edg_jobid) is: - The edg_jobid has been saved in the following file: /home/local/fabrizio.cornia/jobid ================================================================= l'imput Sandbox indica quali les devono essere copiati dalla UI; Questi les vengono inizialmente copiati sul Resource Broker. Lo stato del Job è registrato dal LB come inviato (SUBMITTED) In qualsiasi momento, per conoscere lo stato del job, è possibile interrogare il Logging & Bookkeeping Service: edg-job-status -i jobid ************************************************************* BOOKKEEPING INFORMATION: Status info for the Job : Current Status: Status Reason: Destination: Scheduled Job successfully submitted to Globus grid-ce.pr.infn.it:2119/jobmanager-lcgpbs-theophys reached on: Fri Apr 18 11:27: ************************************************************* 3. il WMS cerca il miglior CE per eseguire il Job, secondo i parametri scelti dall'utente, interrogando una cache del BDII tenuta nell'rb. Il sistema determina lo stato delle risorse computazionali e di storage; lo stato del Job è registrato dal LB come in attesa (WAITING) 4. A questo punto l'rb prepara il Job per la sottomissione al CE, creando uno script wrapper che sarà passato assieme agli altri le e parametri al CE di destinazione. Lo stato del Job è registrato dal LB come pronto (READY) 20

22 5. Il CE riceve la richiesta, e passa il job al gestore di code locale per gestire l'esecuzione. Lo stato del job è accodato (SCHEDULED) 6. A seconda del carico di lavoro e dei parametri del gestore di code, il job viene eseguito in un certo lasso di tempo (RUNNING). Se il job termina senza errori, l'output ed eventuali le prodotti dal programma vengono inseriti nell'output Sandbox e inviati all'rb; lo stato del job è descritto come eseguito (DONE). L'utente potrà recuperarli con: edg-job-get-output -i fileid *************************************************************** JOB GET OUTPUT OUTCOME Output sandbox files for the job: - have been successfully retrieved and stored in the directory: /tmp/joboutput/fabrizio.cornia_mlhzqiifktyhezupohmeha *************************************************************** Una volta che l'output è stato recuperato, il job diventa CLEARED. Come buon accorgimento è necessario ricordarsi di scaricare l'output del job entro una settimana dal completamento dello stesso, in quanto i risultati vengono rimossi dal WMS in un breve periodo di tempo. 21

23 Capitolo 3 Porting di applicazioni parallele Il nostro obiettivo è eseguire un codice parallelo su GRID nel modo più eciente possibile. Purtroppo GRID non ha un meccanismo di selezione che permette di instradare i Job paralleli sulle architetture più adeguate, ossia quelle ad alta prestazione di Networking. In linea di massima quindi, i problemi incontrati da un utente nell'eseguire in ambito GRID un codice parallelo si possono dividere in due grandi aree aree: Valutare a monte la scalabilità, la performance del codice, la dimensione massima del problema arontabile sull'architettura, per comprendere i beneci di una possibile esecuzione GRID. Permettere all'utente di valutare con esaustività le risorse hardware GRID a disposizione; in particolare le capacità di networking che sono centrali per ottenere il massimo benecio dalla computazione parallela. Verrà eettuata un'analisi delle problematiche con esempi di utilizzo dell'architettura. 3.1 Analisi delle performances di algoritmi paralleli L'analisi delle prestazioni di un algoritmo è il problema che trattiamo in questa sezione, ma non è nelle intenzioni di questo lavoro eettuare un'analisi approfondita di questo campo della problematica. In questa sezione, pertanto, si richiamano brevemente i concetti comunemente utilizzati per analizzare le performances di algoritmi paralleli, che verranno sfruttati nella fase di testing, utilizzando Cactus come caso d'esempio. 22

24 3.1.1 Speedup Si denisce lo speedup come il rapporto tra il tempo di esecuzione sequenziale e quello parallelo; ovviamente è dipendente dal numero di processori utilizzato, quindi, eseguendo il codice con un dierente numero di processori, si otterrà una curva di speedup T empo di esecuzione sequenziale Speedup = T empo di esecuzione parallelo Si può produrre un modello semplicato per valutare l'andamento dello speedup considerando il codice composto da: σ(n) - tempo di esecuzione della parte interamente sequenziale ϕ(n) - tempo di esecuzione della parte interamente parallela k(n, p) - tempo di comunicazione tra i processi dove con n e p intendiamo una dipendenza rispettivamente dalle dimensioni del prolema e dal numero di processi. L'espressione per lo speedup in funzione delle dimensioni del problema e del numero di processi potrà quindi essere scritta come: σ(n) + ϕ(n) ψ(n, p) σ(n) + ϕ(n) p + k(n, p) La Legge di Amdahl, chiamato f il rapporto tra il tempo di calcolo parallelizzabile rispetto a quello totale pone un limite superiore allo speedup raggiungibile impiegando p processori ossia: (1 f) ε(n, p) frac1f + p In generale lo speedup è una funzione crescente con le dimensioni del problema; invece aggiungere processori diminuisce il tempo di esecuzione della parte sequenziale ma aumenta il tempo di comunicazione riducendo l'ecienza del codice. Ma cos'è l'ecienza? Ecienza L'ecienza di un programma parallelo è la misura dell'utilizzo di un processore, ed è funzione del numero di processori e della dimensione del problema: Efficienza = T empo di esecuzione sequenziale Numero di processori usati T empo di esecuzione parallelo L'espressione per l'ecienza di un codice in funzione della dimensione del problema e del numero dei processi potrà essere scritta come: 23

25 σ(n) + ϕ(n) ε(n, p) pσ(n) + ϕ(n) + pk(n, p) con 0 ε(n, p) 1; ε(n, p) = 1 rappresenta il caso limite dell'ecienza massima, ossia il perfetto utilizzo di tutti i processori a disposizione, realizzabile nel caso limite di parallelizzabilità perfetta del codice. Si può notare che al denominatore dell'espressione dell'ecienza è presente il termine di overhead k(n, p): ciò signica che l'ecienza del codice parallelo è inuenzata da fattori hardware, ossia dalla rete utilizzata per eettuare le comunicazioni. Per ottenere un'alta ecienza del codice è necessario che una consistente parte dell'algoritmo sia parallelizzabile e che l'overhead di comunicazione venga ridotto al minimo. In generale, algoritmi che scambiano un elevato numero di pacchetti necessiteranno di un architettura di rete a bassa latenza, mentre algoritmi che scambiano pochi pacchetti molto grandi beneceranno di reti ad elevata bandwidth anche se, in generale, le soluzioni di interconnessioni dedicate ad alte prestazioni abbracciano le due caratteristiche come vedremo Isoecienza e scalabilità La scalabilità di un codice parallelo è la misura della sua abilità ad aumentare la performance al crescere del numero di processori. In generale, a causa del sempre maggiore overhead di comunicazione, per mantenere lo stesso livello di ecienza al crescere del numero di processori si è costretti ad aumentare le dimensioni del problema. La relazione di isoecienza informa del fatto che se un algoritmo presenta ecienza ε(n, p), per mantenere la stessa ecienza aumentando il numero di processori deve essere aumentata la dimensione del problema n no a soddisfare la relazione T (n, 1) CT 0 (n, p) dove C è una costante, T (n, 1) è il tempo speso per l'esecuzione sequenziale e T 0 (n, p) = (p 1)σ(n) + pk(n, p) è il tempo totale speso da tutti i processi per operazioni non legate al calcolo. Aumentando il numero dei processi il termine T 0 (p, n) aumenta in quanto aumenta l'overhead (secondo termine), e il tempo di cpu speso attendendo l'esecuzione di parti di codice sequenziale (primo termine); quindi si deve aumentare la dimensione del problema per aumentare anche il tempo di esecuzione sequenziale T (n, 1). 24

26 Figura 3.1: Scalabilità di un algoritmo Purtroppo non è possibile innalzare la dimensione del problema a piacimento in quanto ci si trova di fronte a limiti sici di memoria. La funzione scalabilità relativa a un codice rappresenta come la memoria deve crescere in funzione di p per mantenere lo stesso livello di ecienza; più la crescita è marcata, meno l'algoritmo è scalabile. Se la funzione scalabilità è una costante, l'algoritmo è perfettamente scalabile, perchè aumentando il numero di processori l'ecienza resta costante. Il problema della scalabilità mostra qual è la variabile a cui è necessario prestare attenzione nel portare un applicativo su di un'architettura parallela: la dicoltà consiste nel capire n quando è ragionevole, ssata la dimensione del problema, richiedere un maggior numero di risorse per incrementare le prestazioni e ridurre il tempo di comunicazione Dimensione massima del problema Problema inverso a quello arontato nel paragrafo precedente è determinare la dimensione del problema arontabile con determinate risorse a disposizione. L'utilità di accedere via GRID ad ulteriori risorse di calcolo per arontare dimensioni del problema che non potrebbero essere arontate altimenti è evidente: basti pensare a una griglia che viene scomposta; incrementare il numero di nodi utilizzati in computazione signica avere accesso a più RAM, e consente di ottenere risoluzioni di griglia superiori.tuttavia è necessario prestare attenzione alle limitazioni siche. Non è purtroppo ancora possibile modicare dinamicamente la dimensione del problema arontato da un job in base alle risorse 25

27 disponibili,anche se per certi scopi sarebbe molto utile; questo richiederebbe un'interazione dell'applicativo in esecuzione con il gestore di code e una diversa denizione del le.jdl che al momento governa l'esecuzione dei job paralleli (per i job sequenziali chiaramente il problema non si pone). Allo stato attuale, l'utente deve impostare manualmente la dimensione del problema prestando attenzione ai limiti sici posti dall'architettura sul quale esegue il Job. Memoria Un applicativo parallelo necessita di un ammontare di memoria per CPU utilizzata e di questo è forzatamente necessario tener conto al momento dell'impostazione delle dimensioni del problema arontato e della scelta del sito che eseguirà il job. Come regola generale a tale scopo, si raccomanda di non utilizzare più del 60% della memoria sica a disposizione di ogni processore, per non rischiare di utilizzare lo spazio di Swap; tale eventualità causerebbe il fallimento dei Job. CPU Anche il numero di CPU richieste è un parametro da valutare, in quanto richiedere molti processori su un sito carico di lavoro comporterà tempi di attesa molto lunghi. Spesso i gestori di code prediligono l'esecuzione di job brevi che utilizzino poche CPU per non lasciare processori inattivi nell' attesa che si liberino le ulteriori risorse necessarie per avviare un job di dimensione superiore. E'altresì vero che job di grandi dimensioni consentono di arontare problemi che altrimenti non si riuscirebbero a valutare; in questo caso la scelta spetta all'utente. 3.2 Valutazione dell'ambiente GRID All'interno di una VO saranno presenti numerosi CE dotati di: dierenti software e librerie installati dierente numero di processori dierente prestazioni dei processori, quantità di memoria e spazio di storage dierenti interconnessioni e prestazioni di Networking. dierente Policy di gestione code 26

28 E' stato visto nella sezione precedente che la prestazione della rete è fondamentale per ottenere il massimo benecio nel calcolo parallelo. Le interconnessioni dedicate ad alte prestazioni sono le architetture che permettono di ottenere i massimi beneci dall'approccio parallelo; hanno però costi superiori ai processori di fascia alta, e sono utilizzate solo ove ce ne sia la necessità. Questo fatto fa si che l'esecuzione di un particolare algoritmo su un CE qualsiasi non rappresenti la scelta migliore. In poche parole richiedere a GRID n processori per un job parallelo non rappresenta una richiesta eciente: il problema centrale è richiedere determinate prestazioni di Networking Interrogazione del BDII riguardo all'hardware Sicuramente un primo modo di eettuare una scelta delle risorse è eettuare una richiesta al BDII riguardo alle risorse dei sistemi; è possibile capire come possiamo interrogare il database attraverso il comando: lcg-info --list-attrs Che ci mostra la lista dei parametri contenuti nel GLUE Schema disponibili per la ricerca. Attribute name Glue object class Glue attribute name WorstRespTime GlueCE GlueCEStateWorstResponseTime CEAppDir GlueCE GlueCEInfoApplicationDir TotalCPUs GlueCE GlueCEInfoTotalCPUs MaxRunningJobs GlueCE GlueCEPolicyMaxRunningJobs CE GlueCE GlueCEUniqueID WaitingJobs GlueCE GlueCEStateWaitingJobs MaxCPUTime GlueCE GlueCEPolicyMaxCPUTime LRMSVersion GlueCE GlueCEInfoLRMSVersion MaxTotalJobs GlueCE GlueCEPolicyMaxTotalJobs... La ricerca è personalizzabile, in modo tale da essere informati soltanto dei parametri di nostro interesse, all'interno di una determinata VO. Per capire grossolanamente quali sono le risorse a nostra disposizione: lcg-infosites --vo theophys ce In questo caso si stanno osservando le risorse appartenenti alla VO theophys di INFN GRID valor del bdii: egee-bdii.cnaf.infn.it:2170 #CPU Free Total Jobs Running Waiting ComputingElement 27

29 gridce.ilc.cnr.it gridba2.ba.infn.it gridba2.ba.infn.it gridba2.ba.infn.it grid002.ca.infn.it grid012.ct.infn.it grid012.ct.infn.it grid012.ct.infn.it grid0.fe.infn.it grid-ce.lns.infn.it grid-ce.lns.infn.it grid-ce.lns.infn.it pamelace01.na.infn.it griditce01.na.infn.it prod-ce-01.pd.infn.it grid-ce.pr.infn.it gridce.pg.infn.it gridce.pi.infn.it gridce2.pi.infn.it grid003.roma2.infn.it grid001.ts.infn.it gridce.sns.it Come si può notare, in questo modo è possibile capire quanto sia carico un particolare sito, a livello di numero di CPU disponibili e di job accodati. Per ricercare CE che soddisfano determinate condizioni è possibile utilizzare una query che interroga il BDII della relativa VO, e ci elenca soltanto i siti che soddisfanno tale richiesta con gli argomenti desiderati; per esempio se volessimo conoscere il tipo di nodi utilizzati da un determinato CE: lcg-info --list-ce --query "Tag=PARMA" --attrs=processor,clockspeed,memory,totalcpus -vo=theophys - CE: grid-ce.pr.infn.it:2119/jobmanager-lcgpbs-theophys - Processor XEON - ClockSpeed Memory TotalCPUs 70 Nella lista degli attributi del GLUE schema non è tuttavia possibile trovare alcunchè riguardo la topologia dell'architettura e sulle performance di rete. 28

30 Quindi interrogando il BDII non è possibile classicare adeguatamente le architetture di calcolo. Questa è una delle più grandi limitazioni di GRID nella sua declinazione attuale, e rivela la natura prettamente sequenziale dei job con i quali la rete viene al momento sfruttata. Tra un paio di paragra vedremo come è possibile risolvere il problema Interrogazione del BDII riguardo al Software Per l'esecuzione su grid di un particolare job, è inoltre necessario che sul sito sul quale il lavoro verrà instradato, sia installata una congurazione in grado di permettere l'esecuzione del job considerato. In GRID il software è ordinato e catalogato per VO (in quanto VO dierenti necessitano di software dierente); le informazioni sul software sono raccolte dal BDII tramite un elenco di Tag, che presentano una sintassi propria: VO-<VO name>-<software name> L'installazione di software è permessa solamente agli amministratori del sito; di conseguenza, un utente o meglio un gruppo di utenti dovrà rivolgersi alla VO per ottenere una particolare congurazione. Dal lato utente possiamo esprimere nel campo request del.jdl la richiesta di un particolare software, conoscendo il Tag con il quale tale software viene indicato nel GLUE Schema. Per vedere i Tag dei CE di una particolare VO possiamo utilizzare lcg-info --list-ce -vo theophys --attrs "Tag" less che mostrerà una lista di questo tipo: - CE: grid0.fe.infn.it:2119/jobmanager-lcgpbs-grid... - Tag... GLITE-3_0_0 R-GMA AFS FERRARA SI00MeanPerCPU_1136 SF00MeanPerCPU_1257 VO-atlas-cloud-IT VO-atlas-production VO-atlas-production VO-atlas-production VO-atlas-tier-T4 VO-babar-services VO-babar-Moose e 29