Università degli Studi di Napoli Federico II. Facoltà di Scienze MM.FF.NN. Corso di Laurea in Informatica

Transcript

1 Università degli Studi di Napoli Federico II Facoltà di Scienze MM.FF.NN. Corso di Laurea in Informatica Tesi Sperimentale di Laurea Triennale Un sistema di controllo interattivo per job batch in ambiente grid: g-shell Relatori Candidato Prof. Guido Russo Jonathan Cacace Dr. Silvio Pardi (INFN) Matricola: 566/2731 Anno accademico 2008/2009

2 Indice generale 1 Introduzione L'infrastruttura Grid della Federico II Il Progetto S.Co.P.E Le Risorse Di Calcolo Il Modello GLite I sistemi batch e la sottomissione tramite Grid I Sistemi Di Code PBS E MAUI Le E-science E Le Problematiche Di Interazione Un sistema per il controllo interattivo dei job: g-shell Il Concetto Di VO La Certificazione Standard X Gli Utenti Di Un Computing Element Un Job Batch In Ambiente Grid Analisi Del Software Modellazione Use Case Rappresentazione Del Caso D'uso G-shell Tramite Tabelle Di Cockburn La Tecnologia Web Services Architettura Di G-shell Il File Grid-jobmap GSISSH La Connessione Client - WorkerNode Log Degli Accessi La Disconnessione La Sicurezza: Protocollo Https, Certificazione Proxy E Le Native Grid Functions Il WorkerNode Proxy Sequence Diagram Statechart Diagram Deployment del servizio sull'infrastruttura Esempio di funzionamento Casi Di Errore Codice prodotto Client Server Cron Conclusioni e sviluppi futuri Ringraziamenti Appendice I: La User Interface di INFN-GRID Appendice 2: Codice Bibliografia...97 Jonathan Cacace 566/2731 Pagina 2 di 113

3 1 Introduzione L'oggetto della presente tesi è stata la creazione di un'applicazione sperimentale che mira a fornire un servizio dedicato al Grid Computing. La scopo del progetto presentato in questo documento è quella di fornire una funzionalità del tutto innovativa integrabile senza difficoltà con i siti grid già funzionanti; permette infatti di effettuare un controllo interattivo dei job sottomessi sulle griglie computazionali, cercando di superare quello che appare forse il limite più grande di questi potenti centri di calcolo. Al giorno d'oggi, infatti, le griglie computazionali trovano il loro più grande (se non unico) impiego in job di tipo batch (programmi non interattivi, che prevedono interazione con l'utente solo all'inizio e alla fine della loro esecuzione) molto lunghi, in termini di durata del job, durante la cui esecuzione, potrebbe essere molto difficile o quasi impossibile controllare che il job stia processando in maniera corretta i propri compiti e non sia incappato in alcun tipo di errore durante la sua esecuzione, o magari controllare semplicemente che il programma stia operando in maniera consona allo scopo per cui è stato progettato. Il problema viene risolto permettendo una sessione gsissh (protocollo di connessione ssh che permette la connessione tramite il file di certificato utente e non con nome utente e password) all'utente proprietario del job verso la macchina, e all'interno della directory, dove è in reale esecuzione il job. All'interno di questa directory infatti saranno salvati, nella maggior parte dei casi, tutti i file relativi al job, come il file di output che sta generando o i log della sua esecuzione. Al fine di introdurre al meglio il software, e i problemi che ne hanno reso la necessità, nella seguente figura viene mostrato e successivamente spiegato l'interazione tra l'utente e sito grid nella sottomissione e successiva gestione di un job batch in ambiente grid, semplificando il più possibile il corso di una sua esecuzione. Nella figura vengono mostrate solo due delle varie entità presenti un un sito grid, la User Interface, che rappresenta il nodo di accesso dell'utente alle risorse del sito, e il Jonathan Cacace 566/2731 Pagina 3 di 113

4 Computing Element che invece rappresenta la macchina dedicata all'esecuzione del job sottomesso. Dalla User Interface l'utente ha la possibilità di inviare in esecuzione un programma, e leggerne i valori di uscita una volta che il job è stato completato. Nel corso della tesi verrà spiegato più da vicino il ruolo delle singole entità del sito grid. Figura 1: Principali componenti di un sito grid Come si può notare nell'immagine presentata, un utente dalla propria User Interface non fa altro che scrivere il codice che riguarda il proprio programma. A questo punto, tramite apposite funzioni messe a disposizione per l'utilizzo della griglia computazionale, può sottomettere il job. Dopo la sottomissione, che include l'invio del programma all'unità chiamata Computing Element, l'utente non ha più proprietà del job e deve unicamente attendere la sua esecuzione, finché non gli verranno consegnati i valori di uscita del programma. Dal momento della sottomissione, l'utente non è più in grado di seguire in maniera efficiente il corso dell'esecuzione del proprio job, in quanto tutti i dati ad esso relativi sono presenti su una macchina sconosciuta all'utente su cui non ha alcun diritto di accesso, e l'utente può oggi solo leggere lo stato del processo, ovvero controllare se il processo è in esecuzione o meno. Il metodo di esecuzione del job rappresentato costituisce solo uno dei metodi di utilizzo delle griglie computazionali per il calcolo intensivo, rappresentando il modo d'uso scientifico maggiormente utilizzato. Esistono e vengono utilizzati invece altri metodi in Jonathan Cacace 566/2731 Pagina 4 di 113

5 cui non sempre viene gestito un file nella directory locale del Computing Elementi da cui è possibile leggere i risultati dei propri calcoli, ma non saranno discussi in questo documento. Nel caso in cui si presentano errori durante l'esecuzione del programma, non sempre l'utente riesce a capire i motivi dell'eventuale fallimento e quindi non può capire cosa non è andata a buon fine. La gestione di questi processi batch appare dunque molto difficile e poco intuitiva da parte degli utenti, da qui la necessità di fornire un'applicazione che, nonostante fosse coerente con gli attuali standard di sicurezza delle griglie computazionali, rendesse possibile la visibilità del job in esecuzione. Le directory presenti nel Computing Element, dove l'utente verrà connesso, sono create al momento della configurazione della griglia computazionale, appartengono ad utenti locali che non hanno alcun riscontro con l'utente che sta sottomettendo il proprio job dalla propria User Interface. L'utente una volta connesso via gsissh con l'utilizzo del software realizzato, verrà conosciuto proprio con l'identità dell'utente locale che sta eseguendo il job, in modo da ottenere gli stessi permessi che vengono dati al proprio job e poter eseguire le stesse operazioni che potrebbe eseguire il job. Se da un certo punto di vista potrebbe sembrare una scelta di sicurezza il non permettere ad utenti di effettuare accesso gsissh sulle macchine che processano i job, in realtà la motivazione di questo blocco è da ricercare nel vero motivo che ha spinto la nascita e il successivo sviluppo delle griglie computazionali. Infatti, condividere risorse a livello mondiale significa anche avere un altissimo numero di utilizzatori di questi strumenti dislocati nelle varie organizzazioni scientifiche del mondo, e sarebbe molto difficile non solo creare ma anche gestire un account personale per ogni utente utilizzatore della griglia. Durante la progettazione del software, oltre che alla sicurezza, si è puntato molto sulla portabilità dell'applicazione presentata, rendendo possibile l'operabilità del software senza dover accennare a modifiche sulle strutture già esistenti e funzionanti. In conclusione, la diffusione e l'ulteriore sviluppo di questo progetto, potrebbe portare ad Jonathan Cacace 566/2731 Pagina 5 di 113

6 una nuova visione di Griglia computazionale, favorendone l'usabilità, concedendo agli utenti utilizzatori la possibilità di verificare il corso del proprio job, e aprendo le porte ad una concezione interattiva di Grid Computing. Inoltre, per permettere una più semplice distribuzione del software, come fase di ulteriore sviluppo, verrà implementata una interfaccia utente che sostituisca la linea di comando che potrebbe apparire ostile e di difficile utilizzo per diversi gruppi di utenti. Jonathan Cacace 566/2731 Pagina 6 di 113

7 2 L'infrastruttura Grid della Federico II 2.1 Il progetto S.Co.P.E. La tesi qui presentata entra a far parte del progetto S.Co.P.E dell'università Federico II di Napoli. S.Co.P.E rappresenta l'acronimo Sistema Cooperativo Distribuito ad alte Prestazioni per Elaborazioni Scientifiche Muti disciplinari. L'obiettivo principale del progetto S.Co.P.E è quello di realizzare un sistema di calcolo ad alte prestazioni rivolto al calcolo intensivo, basato sulle più moderne tecnologie di calcolo distribuito ed operante con paradigma GRID. [1] L architettura finale consiste dunque nella creazione di una Grid Metropolitana capace di unire le sinergie dei dipartimenti e strutture di ricerca afferenti o in collaborazione con la Federico II, distribuite nella città di Napoli. S.Co.P.E. promuove altresì lo sviluppo scientifico per la ricerca di base e l innovazione tecnologica, finalizzata alla creazione di codici innovativi ed applicativi nei 4 settori strategici: Scienze del Microcosmo e del Macrocosmo Scienze dei Materiali e dell Ambiente Scienze della Vita Middleware In queste aree di interesse è impegnata una grande comunità scientifica forte delle esperienze e delle competenze maturate in numerosi progetti pregressi ed in stretta collaborazione con l INFN ed altre strutture di ricerca locali e nazionali. Jonathan Cacace 566/2731 Pagina 7 di 113

8 2.2 Le risorse di calcolo Le risorse di calcolo del Data Center del progetto S.c.O.p.e vantano di hardware ad altissime prestazioni, che lo rendono una struttura molto competitiva nel campo del calcolo intensivo ad alte prestazioni. L'intera struttura dispone di: Più di 300 WN biprocessore quadcore a 64bit 8GB RAM (con un totale di 2432 core), in soluzione blade; 16 lame per shelf connessioni infiniband; Risorse di storage di 200 TB in Fiber Channel; 32 TB di storage iscsi; 10 Storag Element connessioni Fiber Channel; 33 Rack Raffreddamento interno. Rete infiniband su ogni macchine. Jonathan Cacace 566/2731 Pagina 8 di 113

9 Per quanto riguarda le risorse di rete invece il data center dispone di una divisione LAN e WAN: LAN: Dorsale di rete a 10 Gbit/sec. Rete ridondata divisa Gbit/sec. Rete a bassa latenza infiniband. Rete separata per monitoraggio e management 100 Mbit/sec. WAN Collegamenti Intranet a 2.4 Gbit/sec, ridondati Collegamenti Internet a 1 Gbit/sec, ridondati Jonathan Cacace 566/2731 Pagina 9 di 113

10 2.3 Il modello glite glite (pronunciato gee-lite) è definito come il middleware di nuova generazione. E' un progetto nato nel 2004 e distribuito nel 2006, con l'intento di fornire una piattaforma per lo sviluppo di applicazioni all'interno del paradigma grid sfruttando le infrastrutture di calcolo e di storage sulla rete internet. Al fine di una corretta e piena comprensione del software presentato in questa tesi, è fondamentale riuscire a capire il ruolo e il funzionamento di un middleware all'interno di un ambiente grid e sopratutto la particolarità del middleware glite. Middleware è definito come uno strato software che si frappone fra le risorse di calcolo e la memoria e gli utenti stessi utilizzatori della griglia computazionale, in modo da far apparire in maniera trasparente all'ambiente esterno la complessità di un sistema grid. Nello sviluppo dell'applicazione presentata in questo documento, e per il funzionamento della stessa, si è adottato glite, un middleware sviluppato dal EGEE (The Enabling Grids for E-sciencE), progetto finanziato dalla commissione europea per sviluppare applicazioni in ambienti grid. Infatti questo software si incorpora perfettamente nel contesto di glite, in quanto è stata adottata la sua architettura come ambiente di sviluppo, adattandosi perfettamente ai requisiti funzionali e di sicurezza di glite. Lo scopo principale della ragione di esistenza di uno strato software che interagisce con i sistemi grid al posto dell'utente, è proprio quello di semplificare l'intero processo di sottomissione di un job che potrebbe apparire una procedura piuttosto onerosa ed ostile agli utenti. In questo modo, con l'adozione del middleware, si ha la possibilità di ridurre tutte le interazioni tra utente e sito grid ad un semplice comando; questo livello di astrazione proposto dal middleware rende totalmente trasparente all'utente l'intera complessità della struttura del sito grid permettendo al software di assumersi tutti i compiti che riguardano la gestione del job, dalla sua sottomissione, alla consegna dell'output. La comunità degli utenti glite è raggruppata nelle organizzazioni virtuali (per maggiori Jonathan Cacace 566/2731 Pagina 10 di 113

11 informazioni si rimanda al paragrafo: 4.1), un utente deve essere iscritto ad una organizzazione supportata dall'infrastruttura che esegue glite per permettere l'autenticazione e l'autorizzazione che rendono possibile l'utilizzo delle risorse grid. Per potersi iscrivere a queste organizzazioni, l'utente deve possedere un file di certificato che attesti la sua identità, rilasciato dalla Certification Authority a cui è legata l'infrastruttura che esegue glite. Il punto di accesso a glite è permesso attraverso una User Interface, che può essere installata su una qualsiasi macchina dove gli utenti possiedono un account e il proprio certificato personale, da qui infatti l'utente, utilizzando i comandi messi a disposizione da glite può eseguire alcune operazioni di base come: Visualizzare una lista di tutte le risorse utilizzate da un job; Sottomettere job per l'esecuzione; Cancellare job; Ricevere output una volta terminata l'esecuzione del job; Mostrare lo stato del job sottomesso; Ricevere lo stato delle risorse dalla griglia computazionale. Per sottomettere un job basta semplicemente utilizzare il seguente comando: glite-wms-job-submit [ path del job ] Dopo aver lanciato questo comando, l'utente verrà informato della corretta sottomissione del proprio job, e gli verrà inoltre fornito un identificativo con cui può tenere traccia del proprio job anche dopo la sua esecuzione. Se invece intendiamo controllare lo stato del nostro programma: glite-wms-job-status [ id del job da controllare ] Jonathan Cacace 566/2731 Pagina 11 di 113

12 In questo caso viene riportato un responso completo dello stato del proprio job, ovvero se è in attesa di essere eseguito, se è in esecuzione, o se magari è fallito per qualche motivo. quando infine il job termina e vogliamo leggerne i valori di output: glite-wms-job-output [ id del job ] Come si può notare, la semplicità con cui è possibile eseguire queste operazioni nasconde completamente la complessità della loro esecuzione, fornendo all'utente un opzione semplice, intuitiva ed immediata per l'utilizzo di un sito grid, che non prevede particolari conoscenze di base di queste architetture. Ovviamente queste sono solo alcune delle funzionalità offerte da glite. Per dare una definizione di middleware più approfondita, si può pensare ad esso come l'insieme di servizi e protocolli che implementano tutti i servizi grid, occupandosi di funzioni come sicurezza, gestione delle risorse, regole per gli utenti e quant'altro occorre per operare in maniera sicura, robusta ed efficiente su di una struttura grid. Per questo motivo glite ha un tipo di architettura orientata ai servizi (SOA) per rendere il software più modulare e astratto, i cui servizi comunicano attraverso interfacce che permettono scambio e controllo dei dati. In particolare il modello glite si divide in due classi di servizi: servizi collective e servizi core. I servizi collective sono servizi distribuiti fuori dal contesto di macchina locale, che vanno quindi a costituire l'infrastruttura distribuita. I servizi core sono invece quei servizi locali che permettono alle macchine di condividere risorse di calcolo o di storage. I principali servizi offerti dal middleware glite, e soprattutto quelli di particolare interesse per la comprensione del software presentato, sono mostrati in figura: Jonathan Cacace 566/2731 Pagina 12 di 113

13 Figura 2: Componenti glite Autenticazione: L'autenticazione rappresenta il processo tramite il quale si può risalire all'effettiva identità dell'utente utilizzatore dei servizi grid. Le informazioni sull'autenticazione dell'utente sono necessarie per permettere l'utilizzo e l'accesso alle risorse, o, sopratutto, per proteggere il sistema da eventuali attacchi e risalire ad utenti che causano malfunzionamenti al sistema. L'utente può autenticarsi tramite un certificato personale, rilasciato da enti dedicati. Questo certificato attesta infatti che l'utente è in grado di autenticarsi e può usufruire dei servizi grid portando con se molte informazioni dell'utente, come i suoi dati personali o la comunità scientifica a cui è iscritto (VO). Jonathan Cacace 566/2731 Pagina 13 di 113

14 Autorizzazione: I servizi di tipo autorizzazione sono una gamma di funzionalità che mirano a consentire o meno l'accesso a servizi grid a determinati tipi di utenti. L'accesso ai diversi tipi di servizi viene permesso a seconda delle politiche scelte dagli amministratori e al tipo di utente. Un utente può essere infatti identificato all'interno di una VO (Virtual Organization) che rappresenta un ente, o un gruppo a cui è possibile iscrivere il proprio certificato. A seconda delle VO esistenti e supportate dalla griglia computazionale, esistono diverse politiche. Un utente può essere iscritto a più VO con lo stesso certificato. Wms: (Workload Management System) Il WMS è da considerare come un insieme di servizi che operano ad alto livello per schedulare i job eseguiti dagli utenti sulla griglia computazionale. I servizi di tipo WMS entrano in gioco quando si vuole sottomettere un job su un sito grid, ed hanno essenzialmente il compito di accettare e successivamente soddisfare le richieste dei job sottomessi mediante la ricerca, e se possibile la selezione, di un Computing Element (CE). Si può parlare di WMS come uno scheduler ad alto livello. Le componenti principali di un WMS sono tre: User Interface: rappresenta un punto di accesso per gli utenti al sito grid, tramite cui è possibile mandare in esecuzione job e leggerne sia lo stato che l'output. WM: (Workload manager) è il centro stella del wms che parla con gli altri componenti per la gestione dei job sul sito grid. RB: (Resource Broker) questo componente si fa carico di ricercare le risorse necessarie al job sottomesso, come la scelta di un particolare Computing Element in seguito ad una particolare richiesta di risorse. Jonathan Cacace 566/2731 Pagina 14 di 113

15 CE: (Computing Element) Il Computing Element rappresenta la parte più generale dell'unità di calcolo di un sito grid. Il Computing Element è l'unica macchina che comunica in maniera diretta con le singole unità di calcolo chiamate WorkerNode. Il wms comunica con il Computing Element per risalire ad informazioni quali la possibilità di eseguire determinate operazioni accedendo a diversi servizi, o la potenza di calcolo disponibile tra i vari WorkerNode. L'utente quindi arriva ad utilizzare le funzionalità della griglia computazionale attraverso glite ed i servizi wms che collaborano con il Computing Element, e rendono incredibilmente semplice la sottomissione di un job. Con la nozione di Computing Element, si capisce come il wms si riduce ad essere solo una sorta di tramite tra l'utente che sottomette il job e il Computing Element di destinazione che si troverà ad eseguirlo. La gestione dei job e quindi delle risorse va a ricadere tutta sul Computing Element. Le funzioni di base di un CE sono quindi: L'esecuzione, seppure indiretta, dei job; L'eliminazione dei dati relativi ai job eseguiti e conclusi; Il recupero di informazione dei job durante la loro esecuzione; La gestione delle risorse dei propri WorkerNode. SE: (Storage Element) Lo Storage Element identifica quella serie di servizi e protocolli dedicati a fornire uniformità di accesso alle risorse dati messe a disposizione dal sito grid. Jonathan Cacace 566/2731 Pagina 15 di 113

16 3 I sistemi batch e la sottomissione tramite Grid 3.1 I sistemi di code Un ambiente di calcolo distribuito ad alte prestazioni, al fine di un corretto funzionamento, necessita di un Manager di risorse per ottimizzare al meglio la propria potenza di calcolo. Questo manager viene definito da un particolare sistema di code associato ad un software di scheduling. Infatti, un programma, una volta pronto alla sottomissione, prenderà posto in una coda in una macchina con risorse disponibili in base ad una serie di criteri come particolari risorse richieste al job o magari a seconda del carico di lavoro delle altre macchine. Le code vengono gestite tramite un sistema a priorità che definiscono, a seconda delle politiche implementate sul sito, quale job ha una maggiore priorità di esecuzione rispetto ad altri. Lo scopo principale di questo sistema, è quindi quello di ottimizzare il più possibile la gestione delle risorse di calcolo e regolamentare l'esecuzione di un gran numero di job. Nell'ambito di questo documento verrà discusso del software PBS, adottato inoltre per lo sviluppo e necessario per il corretto funzionamento di questo software. In un ambiente grid con il termine LRMS (local resource managament system) viene indicato l'insieme del sistema di code e lo scheduler che si occupa di gestire le stesse. Il sistema di code maggiormente utilizzato nei siti grid è conosciuto come PBS, mentre lo scheduler delle code che viene nella maggior parte dei casi associato a PBS è MAUI. 3.2 PBS e MAUI. Due software che svolgono un ruolo di particolare interesse durante la sottomissione di un job batch sono il PBS e il MAUI, che come già detto vanno a formare l' LRMS del sito grid. Portable Batch System, o semplicemente PBS, è un sistema di code che si occupa di curare le risorse del sistema grid. PBS accetta job batch, preserva e protegge il job prima Jonathan Cacace 566/2731 Pagina 16 di 113

17 della sua esecuzione, lo manda in esecuzione, e, al suo termine consegna l'output al mittente del job. Questo software consta principalmente di quattro componenti: Comandi; Server Job; Esecutore Job; Scheduler dei job; Comandi: PBS accetta sia comandi da linea di comando che da interfaccia grafica. Questi comandi vengono suddivisi in tre gruppi: comandi utente, comandi operazionali e comandi amministratore. Ogni tipo di comando necessita di diversi privilegi. I comandi utente sono quel tipo di comandi che aiutano l'utente a conoscere lo stato del job e della sua esecuzione, o che sono necessari per sottomettere un job batch. (Per approfondire si rimanda a Comandi pbs alla fine del paragrafo ). Server Job: Questo è il core principale dello scheduler PBS. La funzione principale del server è quella di gestire in maniera più vicina possibile il job batch, occupandosi della sua creazione, della sua esecuzione o modifica e la protezione degli stessi dalle possibili conseguenze di crash di altri job o dello stesso sistema. Il server inoltre si occupa della gestione delle code batch. Esistono fondamentalmente due tipi di code: routing queues e execution queues. Quando un job risiede in una routing queue vuol dire che il job è un candidato per essere dirottato ad una nuova destinazione (ad un altro server). Se il job invece risiede in una execution queue, vuole dire che il job è candidato per essere eseguito. Esecutore job: L'esecutore dei job è un demone, chiamato psb_mom, che si occupa ti portare un job in esecuzione e, una volta concluso ha la responsabilità di riportare l'output del job al mittente. Ogni WorkerNode capace di eseguire un job deve possedere un demone pbs_mom attivo. Jonathan Cacace 566/2731 Pagina 17 di 113

18 Scheduler dei job: Lo scheduler dei job è un ulteriore demone che si occupa di comunicare con i vari demoni pbs_mom prima di eseguire un nuovo job, per risalire allo stato del sistema e capire la disponibilità dei nodi ad eseguire un nuovo job. Comandi PBS: I principali comandi PBS sia d'utente che operazionali sono: * qstat: necessario per reperire informazioni sui job in coda; pbsnodes: fornisce informazioni sullo stato dei nodi che ospitano un server pbs, rappresentano quindi i WorkerNode del sito grid; qdel: cancella in job; qsub: inserisce in coda un job batch. qstat: Il comando qstat può essere eseguito su un qualsiasi Computing Element, o su uno dei WorkerNode ad esso collegati: In questo caso è stato invocato il comando qstat senza definire alcun parametro, e l'output contiene informazioni come: il Job id, che è un identificativo valido solo nell'ambito del Computing Element, questo id viene assegnato dal pbs dopo che il job inizia la sua esecuzione, l'utente locale (del Computing Element) che sta curando l'esecuzione del job, lo stato del job, in questo caso R rappresenta lo stato running, e la coda in cui risiede il job. Maggiori informazioni sul job e sulla sua destinazione possono essere ricavati invece invocando il comando con l'opzione -f : *Per ulteriori informazioni consultare la pagina di manuale del relativo comando. Jonathan Cacace 566/2731 Pagina 18 di 113

19 ]# qstat -f pbsnodes: Come nel caso precedente anche questo comando deve essere lanciato da un Computing Element o da un WorkerNode: Questo strumento offre molte informazioni sui nodi connessi alla rete. In questo esempio infatti possiamo vedere che uno dei nodi connessi è la macchina scopewn03.dsf.unina.it con np (numero processori) 4, e con stato libero (può quindi curarsi dell'esecuzione di un job). qdel: il comando qdel è necessario nel caso in cui si decidesse di eliminare un job che risiede in una coda nel proprio Computing Element. Accetta come parametro l'id del job assegnato dal computing element: [root@scopece01 ]# qstat 563 qsub: qsub rappresenta il comando che pbs utilizza per la sottomissione di programmi. Come parametri necessita il programma da sottomettere e la coda su cui inviarlo: [root@scopece01 ]# qsub qsub.sh -q resto Se PBS implementa e gestisce l'architettura delle code, lo scheduler che si occupa di gestire i processi, permettendone l'inserimento all'interno delle code pbs ed implementando politiche dinamiche, reservations e priorità è il software MAUI. Jonathan Cacace 566/2731 Pagina 19 di 113

20 PBS e MAUI lavorano a stretto contatto per ottimizzare lo sfruttamento delle risorse dei siti grid e sono installati entrambi sul Computing Element. Infatti, il software MAUI si occupa di controllare e di definire la destinazione di un job secondo le politiche del sito grid e a seconda del carico di lavoro delle code. Le interazioni tra utente, il server maui ed il server pbs sono mostrati nella seguente figura. Figura 3: Rappresentazione del ruolo di PBS e MAUI all'interno del sito grid Jonathan Cacace 566/2731 Pagina 20 di 113

21 3.3 L' e-science e le problematiche di interazione Il termine e-science è usato per descrivere la scienza del calcolo intensivo, ovvero, quelle discipline scientifiche che utilizzano ingenti quantità di dati e necessitano di una vasta potenza di calcolo per analizzarli, fornite dai sistemi grid. Diverse discipline scientifiche vengono raggruppate sotto questa classificazione, ed alcune di queste sono le scienze bio-informatiche, della vita, della terra e particolari branche della fisica. Si può infatti affermare che le e-science sono rese possibili proprio dalle griglie computazionali. La potenza di calcolo offerta da questi grossi centri di calcolo è infatti in grado di fornire risultati di esperimenti nel giro di ore invece che di giorni, rendendo più veloce e semplice il processo di analisi dei dati. La necessità di un cosi vasto potere di calcolo è giustificata dal fatto che queste scienze hanno bisogno di analizzare dati provenienti da simulazioni molto dispendiose a livello computazionale, un esempio di questo tipo esperimento è sicuramente il caso di studio portato avanti dalla comunità e-science della fisica dell'alta energia al CERN di Ginevra: l'lhc, Large Hadron Collider, che rappresenta forse il sistema grid più potente al mondo. Questo sistema prende il nome di WLCG (Worldwide LHC Computing Grid) e rappresenta una collaborazione di circa 170 siti grid disposti in 34 paesi. Lo scopo di questo centro di calcolo appunto quello di creare e mantenere un centro di archiviazione dati e di analisi degli stessi per l'intera comunità della fisica delle alte energie, che, attraverso questa rete riescono a ricevere dati direttamente dalla sede dell'esperimento e possono studiarne gli effetti senza alcuna difficoltà. Altri importanti esempi di e-science provengono da studi che riguardano la scienza dei materiali, la chimica computazionale, l astrofisica o le scienze sociali, nonché le scienze informatiche. Le comunità scientifiche che operano su questi potenti centri di calcolo però non sempre si trovano a loro agio nell'interagire con questi sistemi, sicuramente a causa di una scarsa visibilità del ciclo esecutivo del proprio programma. Infatti, quando Jonathan Cacace 566/2731 Pagina 21 di 113

22 un utente manda in esecuzione un programma, potrebbe ritenere necessario controllare in maniera dinamica ed interattiva il suo svolgimento, visualizzando magari risultati parziali che riescono a dimostrare all'utente che la sua esecuzione sta procedendo in maniera desiderata. Ricordando infatti che i job proposti ai siti grid sono per lo più di lunga durata, nell'ordine delle ore, o dei giorni, magari un utente dal semplice controllo degli stati intermedi del proprio job potrebbe riuscire a interpretare il suo corretto svolgimento o magari, notando comportamenti anomali, potrebbe decidere di elaborare un nuovo job che gli fornisca un risultato più affidabile. Al giorno d'oggi non esistono mezzi o strumenti che permettono all'utente di controllare questo corso del job e quindi, magari, l'utente può accorgersi del funzionamento scorretto solo dopo la sua lunga esecuzione. Come esempio è possibile pensare ad un programma il cui scopo sia quello di controllare vari parametri di un materiale sottoposto a determinate condizioni nel corso del tempo. Magari un job di questo tipo potrebbe terminare la sua esecuzione nel giro di 48 ore. L'utente ha la possibilità di controllare già dopo il suo avvio risultati parziali prodotti, in modo da assicurarsi che non siano stati fatti errori di calcolo e non dover attendere la fine del programma quando poi dovrà essere rielaborato il job, rinviato in esecuzione ed attendere nuovamente la sua elaborazione per ottenere risultati corretti. In conclusione, la necessità di creare un mezzo efficace che può permettere un controllo sempre presente dell'esecuzione poterebbe ad annullare tutte le problematiche di interazione che esistono al giorno d'oggi tra le discipline incluse nel contesto dell'escienze e gli ambienti grid. Jonathan Cacace 566/2731 Pagina 22 di 113

23 4 Un sistema per il controllo interattivo dei job: g-shell 4.1 Il concetto di VO VO è l'acronimo di Virtual Organization. Una Virtual Organization non è altro che un insieme dinamico di persone o istituzioni legate da un gruppo di regole che definiscono la possibilità di condivisione di determinate risorse nell'ambiente grid. Un utente iscritto ad una VO è in grado di sfruttare le risorse definite dall'ente proprietario di questa su di un sito grid che la accetta. L'appartenenza ad una organizzazione è un passaggio essenziale per permettere ad un utente di utilizzare qualsiasi tipo di servizio grid, infatti la prima operazione da effettuare per utilizzare una griglia computazionale è identificarsi (attraverso apposite funzioni) come appartenente di una specifica VO. Si noti che un utente non è strettamente legato ad un unica VO, ma è possibile iscriversi contemporaneamente a diverse organizzazioni. 4.2 La certificazione standard x509 Lo scopo di una certificazione è quello di tenere traccia dell'identità dell'utente possessore di un determinato certificato, questo è necessario per fornire un maggior livello di sicurezza, al fine di garantire un alto grado di fiducia sulla reale identità dell'utente. Esistono diversi standard di certificati per la crittografia dei dati, e, in ambito grid ci si riferisce allo standard x.509. Un certificato è rilasciato e firmato da un ente che garantisce l'effettiva e genuina identità del richiedente, questo ente è detto CA (Certification authority). Lo standard x.509 prevede una coppia asimmetrica di chiavi, una chiave privata che è nota unicamente al possessore del certificato ed una chiave pubblica. Un certificato di questo tipo contiene diverse informazioni sul possessore, come per esempio, i dati anagrafici dell'utente (subject), la CA che ha rilasciato il certificato, oppure il tempo di scadenza del certificato. Il middleware glite, presentato nel capitolo precedente, mette a disposizione un set di funzioni dedicate alla certificazione dell'utente Jonathan Cacace 566/2731 Pagina 23 di 113

24 e al controllo della qualità di un file di certificato. La struttura del certificato x.509 è mostrato nella seguente figura: Figura 4: Struttura del certificato standard x.509 Come già detto un certificato utente x.509 è necessario all'utente per poter accedere alle risorse di calcolo di un qualsiasi sito grid. Come però si può facilmente notare, questo modello di certificazione non ha con se alcuna informazione che riguarda la Virtual Organization di cui si è discusso nel paragrafo precedente. Infatti per identificare l'utente come membro di una VO si utilizza un servizio chiamato VOMS: Virtual Organization Membership Service. VOMS è un sistema per gestire utenti e VO, fornendo un database di utenti, associando a questi ruoli e capacità, ed un insieme di funzioni necessarie per la manipolazione del database e sopratutto per usare il contenuto del database al fine di generare credenziali per gli utenti che sono necessarie per utilizzare i servizi grid. VOMS mette a disposizione un'insieme di strumenti che permettono agli amministratori di definire ruoli e capacità ai singoli utenti, oppure di aggiungere utenti ad una specifica VO. Una funzione invocabile da linea di comando invece permette all'utente di generare un certificato proxy locale basato sui dati del database voms: [root@scopece01 ]# voms-proxy-init Jonathan Cacace 566/2731 Pagina 24 di 113

25 Questo comando non fa altro che prendere il certificato x.509 dell'utente posto sulla propria User Interface, copiarne i dati in un nuovo certificato con lo stesso standard e aggiungere le estensioni che riguardano la VO a cui l'utente è iscritto. Attraverso la funzione voms, l'utente può scegliere di associare una Virtual Organization al proprio file di certificato, in modo da identificarsi come utente di quella organizzazione: [root@scopece01 ]# voms-proxy-init voms [VO] ovviamente per poter fare questo, l'amministratore della VO, il VO admin, in cui l'utente cerca di identificarsi deve aver iscritto l'utente alla VO associando a questa il file di certificato x.509 dell'utente. I punti forti dell'utilizzo del sistema voms sono essenzialmente: Login singolo: l'utente utilizza l'inizializzazione del certificato proxy locale solo all'inizio della propria sessione, dopodiché potrà eseguire tutte le operazioni di cui ha autorizzazione, senza reinizializzare il certificato. Tempo di scadenza: il proxy locale generato dall'utente tramite la funzione voms è valido per un breve periodo di tempo per motivi di sicurezza e, dopo lo scadere di questo tempo per eseguire altre operazioni è necessario reinizializzare il certificato proxy locale. Questo certificato proxy dura in genere 12 ore. VO multiple: l'utente, nel caso in cui sia membro di più VO, può creare il proprio proxy di certificato locale associato a più di una singola VO, questo gli da i privilegi di utilizzare le risorse associate a tutte le VO contemporaneamente. 4.3 Gli utenti di un Computing Element In un ambiente Grid di tipo glite, gli utenti non possiedono una propria home directory su tutte le risorse disponibili, ma piuttosto la complessa gestione dell'ambiente multidominio e del single-sign-on viene risolta mediante l'ausilio di account locali temporanei. Jonathan Cacace 566/2731 Pagina 25 di 113

26 Come detto, le risorse di calcolo all'interno dell'architettura glite svolgono il ruolo di WorkerNode mentre il loro accesso è mediato tramite dei server di front-end chiamati Computing Element. In fase di configurazione di questi ruoli avviene la creazione di un certo numero di utenti locali e delle loro directory con differenti politiche a seconda delle VO presenti sul Computing Element. Ogni utente che sottomette un job tramite User Interface, viene mappato su un uno dei suddetti utenti locali in base alla VO di appartenenza ed utilizzando come chiave di associazione il subject del certificato. Ad esempio l'utente Jonathan Cacace, appartenente alla VO matisse, e con subject di certificato /C=IT/O=INFN OU=Personal Certificate/L=Federico II/CN=Jonathan Cacace, verrà mappato localmente su un utente del tipo matisse001 durante il corso dell'esecuzione del job. In questo modo i suoi job saranno eseguiti in uno spazio utente con i permessi necessari. Quindi, quando un utente da una User Interface sottomette un job e questi arriva sul Computing Element, viene riconosciuto come un utente locale del Computing Element e successivamente sul WorkerNode con lo stesso utente. 4.4 Un job batch in ambiente Grid Un job dopo essere sottomesso al WMS, viene seguito con un identificativo, il job id, che risulta essere necessario per eseguire operazioni come conoscere lo stato del job o riceverne l'output. Il job id ha la forma di un indirizzo https: Stati del job: Un job una volta sottomesso può attraversare diversi stati prima di essere eseguito: - Submitted: Il job è stato sottomesso dall'utente ma non è ancora in nessuna coda; Jonathan Cacace 566/2731 Pagina 26 di 113

27 - Waiting: Il job è stato accettato ma non è stato ancora processato dal WM; - Ready: Il job è stato accettato da un Computing Element, ma non vi è stato ancora trasferito; - Scheduled: Il job è in attesa nella coda del Computing Element; - Running: Il job è in esecuzione; - Done: Il job è terminato; - Aborted: Il job è stato abortito dopo aver presentato un problema; - Cancelled: Il job è stato cancellato; - Cleared: L'output è stato trasferito all'utente. Quando infine il job viene inviato ai WorkerNode, tutti i dati che ne riguardano la sua esecuzione vengono salvati in un'apposita cartella nella home dell'utente designato per l'esecuzione. Ovviamente un utente può avere più di un job in running, a questo proposito, vengono create due tipi di directory per ogni job, una per lo standard output e l'esecuzione e un'altra per lo standard error. Si possono distinguere due classi di job, quelli seriali e quelli paralleli. Un job parallelo è un tipo di programma che viene eseguito parallelamente su più macchine diverse in modo da ridurre il tempo totale di calcolo. Le griglie computazionali trattano sostanzialmente in maniera analoga job seriali e paralleli, con l'unica differenza che, se stiamo considerando un job seriale, avremo un unico WorkerNode, in cui vi saranno nella home directory dell'utente incaricato di eseguire il job i file che riguardano la sua esecuzione, se invece consideriamo i job paralleli, i file vengono suddivisi in diversi WorkerNode, sempre nella stessa home directory dell'utente. 4.5 Analisi del software g-shell è un'applicazione dedicata per i sistemi grid la cui attività principale è quella di permettere agli utenti di controllare senza difficoltà lo stato del proprio job sottomesso sulla griglia (Variabili di ambiente, eventuali errori, frazioni di output del job). Ogni utente per utilizzare l'applicazione deve disporre di una User Interface su cui è Jonathan Cacace 566/2731 Pagina 27 di 113

28 installato il software glite, e in cui risiede un certificato personale (standard x.509). Inoltre il job che si desidera controllare deve essere in esecuzione. Il software è composto da due unità essenziali: un client ed un server. L'utente, per avviare l'applicazione deve interagire con la parte client, posta sulla User Interface, mentre il server viene installato su un apposita macchina, il WorkerNode proxy (Per maggiori si rimanda al paragrafo: 4.14). Il client è un applicazione invocabile da una unix shell da linea di comando, chiamato con l'id del job (job id) che si desidera controllare. Ricordando la struttura di base di una griglia computazionale, l'unità che si fa carico di mandare in esecuzione i job è il Computing Element (CE). Questo calcolatore lavora da front-end verso un numero indefinito di macchine, chiamate WorkerNode; quando al Computing Element viene inviato un job da eseguire, questo controlla i WorkerNode liberi, se ne esistono allora manda immediatamente in esecuzione il codice, altrimenti lo mette in coda. Una volta in esecuzione il controllo del job passa al WorkerNode di destinazione. Lo scopo principale di g-shell e quindi quello di permettere ad un utente che abbia un job in esecuzione, la possibilità di aprire una sessione remota ad interfaccia a linea di comando con autenticazione tramite certificato (sessione gsissh), direttamente sul WorkerNode che sta curando l'esecuzione del job. Inoltre l'utente dopo aver avviato l'applicazione si deve trovare come ultima destinazione all'interno della directory che si occupa dell'output del proprio job. La ragione della creazione di questo software deriva principalmente da due proprietà dei sistemi grid: un' infrastruttura grid è in grado di accettare solo job di tipo batch e questi eseguibili non prevedono alcuna interazione; questo fatto porta alla conseguenza che non esistono piattaforme di sviluppo per processi interattivi, e annullano completamente lo stato di visibilità dell'esecuzione del job. Inoltre un altro fatto determinante per la mancanza di interazione dipende dalla mancanza di un account locale sulle macchine dove è destinato il job, con possibilità di accesso da parte degli utenti. In questa maniera tutti i file che riguardano l'andamento del job sono conservati nei WorkerNode dove risiede il job, mentre all'utente verranno semplicemente consegnati i file di output, al termine dell'esecuzione. Jonathan Cacace 566/2731 Pagina 28 di 113

29 La seguente figura mostra come saranno disposti e come sono connesse le singole entità del sito grid predisposto ad eseguire il software g-shell. In questa figura vengono considerati principalmente tre unità: la User Interface, Il Sito Grid e il WorkerNode Proxy. Dalla User Interface l'utente è in grado di sottomettere un job, contattando il Resource Broker che si occuperà di consegnarlo al Computing Element. Il sito Grid, composto dal Computing Element e dall'insieme dei WorkerNode, e il Proxy, che rappresenta il server dell'applicazione. Il Proxy è in grado di contattare direttamente sia il Computing Element che i singoli WorkerNode e la User Interface. Allo stesso modo l'utente dalla propria User interface può contattare il Proxy avviando il client dell'applicazione. Figura 5: Interazioni tra il sito grid ed il WorkerNode proxy Jonathan Cacace 566/2731 Pagina 29 di 113

30 4.6 Modellazione Use Case In questo paragrafo viene presentato un diagramma dei casi d'uso di massa che include le generiche operazioni che un utente può effettuare su una griglia computazionale, includendo le nuove funzionalità offerte dall'adozione di g-shell. Figura 6: Diagramma dei casi d'uso Un utente può Identificarsi ovvero convalidare la sua identità, assicurandosi la possibilità di sottomettere job. Può Sottomettere job, Controllarne l'output nel caso questo sia terminato senza errori, Controllare lo stato del job, ovvero controllare se è in Running o se presenta altri stati (Per maggiore si rimanda a stati del job nel paragrafo: 3.3). Nel diagramma, in rosso, è presentato un altro caso d'uso non disponibile sulle generiche griglie computazionali. g-shell, infatti, rappresenta le azioni effettuabili adottando questo software; questo caso d'uso può essere diviso in diverse operazioni: g-shell controlla la certificazione dell'utente, controlla che il job sia in running e se Jonathan Cacace 566/2731 Pagina 30 di 113

31 questo appartiene all'utente che sta utilizzando l'applicazione, se è cosi apre una sessione gsissh verso il WorkerNode di destinazione del job. Da qui l'utente può eseguire una moltitudine di operazioni a basso livello che possono aiutarlo nell'utilizzo della griglia. Queste operazioni possono riguardare debug, come il riconoscimento di stati di errore presentati dal job, troubleshooting, capire eventuali comportamenti anomali del job, o magari la semplice visualizzazione di output parziali elaborati durante l'esecuzione del job, cosa del tutto impossibile senza l'utilizzo di g-shell. 4.7 Rappresentazione del caso d'uso g-shell tramite tabelle di Cockburn Obiettivo Precondiz ioni Condizion i di successo Condizion i di fallimento Attore Primario Trigger g-shell L'utente deve ottenere una sessione gsissh sul WorkerNode del proprio job L'utente è loggato su di una user interface L'utente ottiene una sessione gsissh sul WorkerNode del proprio job L'utente non viene riconosciuto come utente certificato Utente Invocazione di g-shell Descrizio ne dei passi N Passo Azione Utente 1 Invocazione di g-shell Azione Sistema 2 Controllo esistenza del job id di input 3 Controllo Jonathan Cacace 566/2731 Pagina 31 di 113

32 proprietario del job 4 Controllo vo supportata da ce dove risiede il job 5 Controllo se il job è in running 6 Calcolo destinazione del job 7 Apertura sessione gsissh sulla destinazione del job Estensione 1 L'utente non ha specificato il job id N Passo 3(b) Azione Utente Azione Sistema Visualizzazio ne dell'errore riscontrato Estensione 2 Il job non appartiene all utente N Passo 4(b) Azione Utente Azione Sistema Visualizzazion e dell'errore riscontrato Estensione 3 La vo dell utente non è supportata dal CE dove riesede il job Jonathan Cacace 566/2731 Pagina 32 di 113

33 N Passo 5(b) Azione Utente Azione Sistema Visualizzazione dell'errore riscontrato Estensione 4 Il job non è in running N Passo 6(b) Azione Utente Azione Sistema Visualizzazio ne dell'errore riscontrato Come mostrato nella tabella precedente, le interazioni tra utente e client sono davvero minimali e permettono senza problemi l apertura della sessione gsissh. Come si nota però dallo stesso diagramma, l utente può trovarsi di fronte ad alcuni errori. Questi errori sono mostrati dalle Estensioni del caso d uso. Questi errori non dipendono dal sistema, ma solo dall utente, infatti questi, per poter sfruttare l applicazione deve certificarsi, attendere che il job sia in running e non cercare di controllare lo svolgimento di un job che non gli appartiene. La fine delle interazioni tra utente e sistema possono terminare in due modi. Nel caso in cui l utente voglia chiudere la sessione gsissh, allora verrà disconnesso dal sistema, altrimenti la disconnessione può avvenire se l utente ha aperto la sessione e il job che sta controllando termina, allora verrà chiusa la sessione stesso dal sistema. Jonathan Cacace 566/2731 Pagina 33 di 113

34 4.8 La tecnologia Web Services I web services non sono altro che API (Applications Programming Interfaces) che forniscono accesso sulla rete, come internet, e possono essere eseguite sulla macchina remota che fornisce il servizio. Un web services è un servizio che riesce a fornire la giusta interoperabilità tra più sistemi operativi e più strutture hardware grazie all'utilizzo di un sistema standard di messagging basato sul metalinguaggio XML. Figura 7: Pila protocollare Web Service In figura 7 è mostrata la pila protocollare di un web services, su cui possiamo notare 4 livelli che includono l'insieme dei protocolli di rete utilizzati per definire e far interagire tra loro i web services. Il primo livello della pila offre servizi di Discovery ed è costituito dal protocollo UDDI (Universal Description, Discovery and Integration). Questo primo livello consiste in una specifica per le definizione della pubblicazione e della ricerca dei web services. UDDI è una specifica del W3C (World Wide Web Consortium). Consiste in tre sezioni: UDDI data model: modello delle informazioni contenute nel registro UDDI; UDDI API: funzioni per l'interrogazione del registro UDDI e per la pubblicazione di un web services; UDDI cloud services: insieme di funzioni per la sincronizzazione dei registri UDDI. Jonathan Cacace 566/2731 Pagina 34 di 113

35 Il secondo livello riguarda la descrizione di un web services. Questo livello è implementato dal protocollo WSDL (Web Service Description Lenguage). Questo protocollo definisce una specifica di come descrivere un web services attraverso il metalinguaggio XML. Anche WSDL è una specifica W3C. Attraverso questo documento scritto in linguaggio formale XML è possibile infatti definire informazioni base del web services, come per esempio, cosa può essere utilizzato, ovvero le funzionalità offerte dal servizio; come utilizzarlo, ovvero il formato dei messaggi di input e i possibili output rilasciati dal servizio; dove utilizzare il servizio, ovvero il cosiddetto endpoint che solitamente corrisponde all'indirizzo del web service in formato Url. La grammatica WSDL è definibile attraverso sei elementi: definitions: rappresenta la radice del documento WSDL, al cui interno è possibile specificare il nome del web services ed i namespace che verranno utilizzati all'interno della pagina; types: tag per la descrizione dei tipi di dati utilizzati attraverso la specifica XML; messages: tag per la descrizione di ciascun messaggio scambiato con il web services; porttype: descrive le funzioni offerte dal web services; binding: tag per la descrizione della modalità di trasmissione dei messaggi; service: tag che descrive l'endpoint del web services, ovvero l'indirizzo al quale può essere raggiunto. Il documento che va a definire il web service utilizzato per l'applicazione presentata è il seguente: <definitions targetnamespace=" <types> <xsd:schema targetnamespace=" <xsd:import namespace= " Jonathan Cacace 566/2731 Pagina 35 di 113

36

37

38 binding="tns:convalidautentibinding"> <soap:address location=" </port> </service> </definitions> Jonathan Cacace 566/2731 Pagina 38 di 113

39 I vari tag che vanno a definire il documento wsdl devono quindi seguire il seguente schema di inclusione: Figura 8: Incapsulamento tag nel prtocollo WSDL Per quanto riguarda il terzo livello della pila protocollare, si riferisce al tipo di messaggio XML. Lo standard proposto dal W3C è il protocollo SOAP (Simple Object Access Protocol). SOAP è un protocollo XML-Based che definisce l'accesso ai metodi del web services. L'interoperabilità dei sistemi web services è dimostrata con questo protocollo, in quanto lo standard SOAP non dipende dal sistema operativo o dal livello di trasporto. Un framework SOAP è definito da tre elementi: SOAP envelope specification: definisce le regole per l'incapsulamento del messaggio da trasferire, del metodo da richiamare o dei valori di ritorno. Data encoding rules: definisce la regola per la codifica delle strutture dati in un Jonathan Cacace 566/2731 Pagina 39 di 113

40 messaggio XML. RPC Convention: definisce la convenzione per implementare una chiamata RPC (Remote Procedure Call), ovvero le chiamate alle procedure remote. La struttura di un pacchetto SOAP è mostrato in figura 9: Figura 9: Framework del pacchetto SOAP Le varie sezioni del pacchetto sono divisibili in: Envelope: specifica la versione SOAP utilizzata. Header: riguarda le informazioni a livello applicazione. Body: contiene le informazioni sul metodo del web services da richiamare. Infine il quarto ed ultimo livello della pila protocollare riguarda il protocollo che si occupa del trasporto del pacchetto. Il protocollo adottato può essere http, https, ftp o altri indipendentemente dal tipo di protocollo utilizzato come pacchetto da trasferire. 4.9 Architettura di g-shell Jonathan Cacace 566/2731 Pagina 40 di 113

41 Nel paragrafo 4.7 sono state discusse le interazioni basilari tra l utente e la parte client dell applicazione. In questo paragrafo invece si parlerà più in dettaglio del funzionamento del sistema, da un punto di vista prettamente tecnico. L intero sistema è strutturato su un architettura client-server. Il client è rappresentato da uno script in linguaggio perl, e, per l intera sua esecuzione scambia messaggi con il server. Se il client è posto sulla User Interface, il server deve essere installato su una macchina che deve essere configurata come un qualsiasi WorkerNode, collegato al Computing Element di appartenenza, in modo da possedere la stessa lista di utenti dei normali WorkerNode e le stesse regole di sicurezza. Si noti che questo WorkerNode è un apparato hardware estraneo alle normali configurazioni delle griglie computazionali. Lo schema delle componenti è riportato sotto forma di diagramma delle classi in figura 2: Jonathan Cacace 566/2731 Pagina 41 di 113

42 Jonathan Cacace 566/2731 Pagina 42 di 113

43 Figura 10: Diagramma delle classi In questo diagramma è riportato uno schema di massa delle componenti che interessano al software presentato in questa tesi. La linea rossa serve ad identificare i collegamenti richiesti dalla modifica hardware necessaria per il funzionamento del software. Il componente Proxy è il WorkerNode che deve essere integrato su cui viene installato il server, ed esso deve poter comunicare con la User Interface, con il Computing Element e con tutti i WorkerNode della griglia. Il server è composto da un set di funzioni che rappresentano il core principale dell applicazione e da un interfaccia web services. Web services: Questa interfaccia ha lo scopo principale di ricevere messaggi dal client, curandone la comunicazione ad ogni passo, gestendo gli accessi multipli all applicazione, ed invocando al momento giusto le funzioni per reperire informazioni sul job che l utente Jonathan Cacace 566/2731 Pagina 43 di 113

44 desidera controllare. La scelta di utilizzare un web services per accettare messaggi è stata guidata da due aspetti principali: in primo luogo, la facilità e la leggerezza dei messaggi scambiati tramite protocollo SOAP (Simple Access Object Protocol) permette una più veloce e leggera elaborazione dei messaggi inviati, inoltre, lo scambio dei messaggi è stata basata sul protocollo https (Hypertext Transfer Protocol over Secure Socket Layer) per garantire una maggiore sicurezza impedendo intercettazioni passive di messaggi all'esterno della rete. L'interfaccia è stata curata in linguaggio php. Un altro punto di forza di questa interfaccia è la gestione degli accessi multipli all'applicazione. Vengono infatti usati i Session Id (Identificativi di sessione) per discriminare i singoli utenti che anche utilizzando contemporaneamente l'applicazione, non creano problemi di race condition. Infatti ogni funzione del web services come prima operazione inizia una sessione in modo da discriminare i vari utenti, concedendogli l'utilizzo di una chiave univoca con cui nominare file temporanei utilizzati nel corso dell'esecuzione del software: function Convalida($uid, $Cert) { #Inizio della sessione session_start(); $phpsid=sid; #OPERAZIONI #Distruzione della sessione session_destroy(); Return(); } Questo pezzo di codice deriva dal web services e mostra la tipica architettura di una funzione. Dopo la sua inizializzazione session_start() è la funzione che si occupa di istanziare una sessione, SID invece rappresenta il Session Id che è una chiave univoca ad ogni accesso alla sessione, successivamente si svolgono le operazioni della funzione ed Jonathan Cacace 566/2731 Pagina 44 di 113

45 infine la sessione viene distrutta. Client: Come mostrato nella tabella di cockburn nel paragrafo 4.7, le prime operazioni del client riguardano il controllo della certificazione utente, della VO e dello stato del job. Questi controlli vengono fatti attraverso funzioni messe a disposizione da glite: glite-wms-job-status $Job_id La funzione glite-wms-job-status ha come valore di ritorno 0, nel caso in cui non ci siano stati problemi, se invece ritorna un valore diverso, o il job non è stato sottomesso, o non è di proprietà dell'utente che effettua la chiamata alla funzione. La stessa funzione ha come output a video alcune informazioni importanti sul job, questa caratteristica viene utilizzata per controllarne lo stato: glite-wms-job-status $ARGV[0] grep "Current Status" awk '{print \$3}' Se l'output di questa funzione non è running viene stampato un errore, altrimenti il client continua la sua esecuzione. La prima interazione tra client e web services si ha quando, una volta che il client ha controllato che non ci sono problemi di certificazione o problemi con il job che si desidera controllare, il client contatta e si connette al web services. Per stabilire la connessione vengono usate particolari librerie perl, le librerie SOAP: #Importazioni delle librerie SOAP::Lite use SOAP::Lite; #Specifica del web service che si vuole contattare my $service = SOAP::Lite -> service(' wsdl'); Con questa riga di codice viene stabilita la connessione tra il client e il web services. In questo caso l'argomento della funzione services è l'indirizzo della pagina php presente sul server. Jonathan Cacace 566/2731 Pagina 45 di 113

46 Viene successivamente chiamata una funzione del web service con cui l'utente invia il proprio file di certificato x509. #Chiamata della funzione di Convalida presente sul web service $convalida=$service->convalida($uid, $Certificato); La funzione si occupa di autenticare l'utente controllando la bontà del certificato inviato dall'utente. A questo punto si è sicuri che l'utilizzatore ha le autorizzazioni necessarie per poter continuare l'esecuzione del programma. Nel caso in cui invece il file di certificato inviato non è accettato, il programma viene chiuso stampando l'errore in output. A questo punto il client può richiedere la connessione al WorkerNode di destinazione. Verrà quindi chiamata una funzione sempre sul web services inviandogli il job id del job che si desidera controllare. #Chiamata alla funzione di connessione: #ARGV[0]: JobId $connessione=$service->connessione($argv[0],$sid,@ce[0]); Ora, se il job non è in running, eventualità che può accadere se il job è terminato dopo l'avvio del client, viene terminato il programma stampando l'errore in output, altrimenti, l'utente si troverà in una sessione gsissh sul WorkerNode dove il job è in esecuzione. A questo punto terminano le interazioni tra il client ed il web services. Server: La chiamata alla funzione di connessione porta alla fase più complessa del funzionamento di g-shell. A questo punto il sistema è sicuro che l'utente non sia ostile, quindi si deve passare alla fase di ricerca della destinazione. Si devono quindi Jonathan Cacace 566/2731 Pagina 46 di 113

47 considerare le informazioni di cui ha bisogno il server per concludere la propria esecuzione. Innanzitutto deve reperire informazioni sul job dal Computing Element, in modo da poter risalire ad informazioni come il proprietario e la destinazione. Infatti, l'utente quando riceverà la connessione gsissh verso il WorkerNode, avrà accesso con l'utente che effettivamente sta eseguendo il job (uno degli utenti locali messi a disposizione dal Computing Element). Per ottenere queste informazioni il server deve scaricare un insieme di file direttamente dal Computing Element, si deve considerare però che, in tutte queste azioni, il Computing Element deve svolgere un ruolo prettamente passivo, infatti, le interazioni devono essere totalmente guidate dal server, senza aspettarsi delle feedback da parte del CE che non deve variare il suo normale funzionamento Il file grid-jobmap Questo è un tipo di file di testo in cui sono riportate tutte le informazioni sui job sia in corso che terminati. E' presente sul Computing Element nella directory: /opt/edg/var/gatekeeper/ Ogni qual volta viene sottomesso un job sul CE che è il primo della giornata, viene creato questo tipo di file. Se invece il job non è il primo della giornata, il file sarà semplicemente aggiornato, inserendo una nuova riga, con le informazioni del job. Viene qui riportata una generica riga di questo file: "localuser=14020""userdn=/c=it/o=infn/ou=personal Certificate/L=Federico II/CN=Jonathan Cacace" "userfqan=/matisse/role=null/capability=null" "jobid= "ceid=scopece01.dsf.unina.it:2119/jobmanager-lcgpbs-resto" "lrmsid=555.scopece01.dsf.unina.it" "timestamp= :25:42" Jonathan Cacace 566/2731 Pagina 47 di 113

48 questo file contiene informazioni su tutti i dati del job, le principali nozioni di interesse sono: localuser che rappresenta l'utente locale che è stato designato per l'esecuzione del job. jobid rappresenta l'id del job. IrmslD rappresenta invece l'id assegnato a Computing Element al job, per esempio in questo caso il Computing Element riconosce il job, con job id appartenente all'utente locale a cui ha assegnato l'id 555. Il file viene semplicemente scaricato e successivamente analizzato sul server. Il download del file avviene tramite il protocollo gsiftp. Si noti che, pur essendo creato un file ogni volta che un job viene sottomesso sul Computing Element, non necessariamente è il file del giorno attuale a possedere informazioni sul job che si desidera controllare. Infatti, è possibili che un job possa continuare per più di un giorno ed oltre, quindi si è stata formulata una tecnica per assicurarsi di avere sempre file di grid-jobmap sempre completi e mai obsoleti: la strategia del Token. Questa strategia permettere di avere sul server tutti i file che possono contenere #$1: Sid di connessione - #$2: Sid attuale #$3: Data - informazioni su job ancora in esecuzione. In questo modo, anche se un job si prolunga Formato AnnoMese per più if di [ un -e giorno "/tmp/gridmap/token" e nessuno ha utilizzato l'applicazione ]; then dopo aver sottomesso il job, #In questo caso devo scaricare tutti i file del mese e di quello attraverso questa strategia ci si assicura la reperibilità del file di interesse per il nostro precedente job. rm "/tmp/gridmap/token" data=$3 ym=${data:0:6} download=$ym"*" ym1=$(( $ym-1 )) download1=$ym1"*" /opt/globus/bin/globus-url-copy gsiftp://scopece01.dsf.unina.it//opt/edg/var/gatekeeper/gridjobmap_$download file:/tmp/gridmap/ /opt/globus/bin/globus-url-copy gsiftp://scopece01.dsf.unina.it//opt/edg/var/gatekeeper/gridjobmap_$download1 file:/tmp/gridmap/ Else #In questo caso scarico solo l'attuale Jonathan Cacace 566/2731 Pagina 48 di 113 /opt/globus/bin/globus-url-copy gsiftp://scopece01.dsf.unina.it//opt/edg/var/gatekeeper/gridjobmap_$3 file:/tmp/gridmap/$2

49 Il funzionamento è molto semplice: ogni giorno alle ore 00:01 un processo sul server crea un file regolare senza contenuto nominato token, quando il server vuole scaricare il file grid-jobmap, controlla dell'esistenza di questo file token, se esiste, lo cancella e scarica i file presenti sul CE che riguardano quelli del mese della data in corso e quelli del mese precedente, sovrascrivendo quelli che sono presenti già sul server, altrimenti se non esiste il file token si occupa semplicemente di scaricare quello della data attuale. In questo modo inoltre ci si assicura che tutti i file presenti sul server non siano in alcun modo obsoleti GSISSH Il protocollo gsissh è il vero responsabile della connessione tra l'utente e la sua destinazione finale. Gsissh è un protocollo derivato da OpenSSH a cui viene aggiunto il supporto per l'autenticazione GSI (Grid Security Infrastructure), provvedendo quindi alla connessione ssh senza bisogno di utilizzare nome utente e password, bensì tramite l'autenticazione tramite il certificato proxy locale cerato in base al certificato personale standard x.509. La connessione tramite certificato permette quindi agli utenti che sono in grado di usufruire dei servizi grid, di connettersi senza bisogno che qualcuno fornisca i Jonathan Cacace 566/2731 Pagina 49 di 113

50 dati di un account locale sul sito grid a cui l'utente decide di connettersi. Per effettuare una connessione tramite questo protocollo, sul server di destinazione deve essere presente un file, il grid-mapfile, che mappa tutti gli utenti che possiedono diritto di effettuare connessioni gsissh, includendo l'utente locale su cui l'utente che richiama la funzione ha diritto di connessione. La possibilità di autenticare l'utente tramite il proprio certificato fa parte proprio della filosofia di utilizzo delle griglia computazionale, quindi la soluzione adottata per la connessione utente in g-shell è coerente con gli standard grid. Infatti in questi immensi sistemi di calcolo appare impossibile fornire dati personali agli utenti in tutti siti a cui è associata la propria Virtual Organization La connessione client - WorkerNode Il processo di connessione è riassumibile in figura 11. Jonathan Cacace 566/2731 Pagina 50 di 113

51 Figura 11: Schema di connessione Utente WorkerNode Il processo di connessione dal client al WorkerNode rappresenta la parte più complessa del sistema. Come già detto nelle pagine precedenti, non è possibile semplicemente avviare una connessione gsissh dal cliente al WorkerNode una volta che questo è stato trovato, in quanto gli utenti, pur utilizzando le griglie computazionali, non hanno alcun diritto di accesso sugli account locali dei WorkerNode. L'utente dal client si connette con protocollo gsissh al server sulla macchina proxy con lo stesso nome utente dell'utente locale che sta eseguendo il proprio job. Qui andrà ad eseguire uno script che ne permette la ridirezione, e quindi la connessione ssh, al WorkerNode di destinazione. Con l'analisi del file grid-jobmap infatti, è possibile conoscere l'host di destinazione e l'utente proprietario del job. Il download e la successiva analisi del file è iniziata dalla funzione di connessione del server chiamata dal client che, se trova il job che si desidera controllare in esecuzione, invia al client l'utente che è stato designato per l'esecuzione del job, un codice di errore altrimenti. Prima di consegnare il valore di ritorno, il server si occupa di scrivere un apposito script Jonathan Cacace 566/2731 Pagina 51 di 113

52 la cui esecuzione è demandata dopo la connessione dell'utente, salvandolo in file il cui nome è il nome utente che sta eseguendo il job. #Creo in tmp lo script di redirezione (es. /tmp/.fw/matisse020.sh) open RD, ">/tmp/.fw/$prop.sh"; #Scrivo all'interno del file appena creato il comando da eseguire: print RD "/opt/g-shell/bin/sshw.sh $host"; close(rd); #Imposto i permessi eseguibili sullo script appena creato system("chmod +x /tmp/.fw/$prop.sh"); Come si può notare dalla porzione di codice sopra riportata, il contenuto di questo script è l'esecuzione di un secondo script con un valore di input, che rappresenta il nodo di destinazione finale dell'utente, questo è un wrapper ssh, che dopo aver compiuto una serie di operazioni si occupa di chiamare la funzione ssh sulla destinazione. Quando il client riceve il nome con cui stabilire la connessione allora è in grado di invocare la sessione gsissh specificando l'indirizzo del server. Dopo la chiamata alla funzione gsissh, l'utente si trova connesso al server proxy, da cui dovrà essere automaticamente rediretto al WorkerNode che sta eseguendo il proprio job. Questa ridirezione deve avvenire in modo automatico senza alcune interazione da parte dell'utente. Per fare questo, è stato modificato il file (*) /etc/profile in modo che, ogni utente diverso da root che si collega al server, si troverà ad eseguire lo script scritto dal server e chiamato secondo il proprio nome utente all'interno del server. Lo script è oltretutto necessario per permettere all'utente di giungere non solo nella home directory dell'utente che si occupa di eseguire il job, bensì nella directory dove sono salvati i file sia temporanei che di esecuzione del proprio job, tutto attraverso due semplici passaggi. Viene qui riportata la sezione interessata del file /etc/profile: user=`whoami` if [ $user!= "root" ]; then /tmp/.fw/`whoami`.sh Jonathan Cacace 566/2731 Pagina 52 di 113

53 Come già detto in precedenza, lo script che l'utente esegue dopo la connessione gsissh con il proxy, non fa altro che chiamare un secondo script passandogli la destinazione del job. Questo script viene qui riportato: #$1: host di destinazione user=`whoami` #backup del file bashrc sul WorkerNode di destinazione ssh $1 cp /home/$user/.bashrc /home/$user/.old.bashrc #copia del nuovo bashrc sul WorkerNode di destinazione scp /tmp/.fw/$user $1:/home/$user/.bashrc #Connessione verso l'host di destinazione ssh $1 Quindi, quando l'utente si trova sul server, anche se in maniera indiretta si occupa di, inviare alla home directory del WorkerNode di destinazione una nuova copia del file di (**) bashrc sostituendolo a quello già presente, e stabilire una connessione ssh con esso. In questo modo l'utente si trova rediretto al WorkerNode che sta eseguendo il proprio job ed tramite l'esecuzione del bashrc si trova nella directory proprietaria del job; l'ultima operazione del bashrc è quella di sostituire nuovamente la nuova versione del file bashrc con quello precedente che ne rappresenta la versione originale. Questa strategia che contiene script eseguiti dall'utente e wrapper ssh è stata creata * /etc/profile: questo file contiene le variabili di ambiente per l'intero sistema e i programmi da eseguire all'avvio. ** /home/user/.bashrc: contiene gli alias e le funzioni che l'utente esegue al login nella sessione. essenzialmente per un motivo: nel contesto delle griglie computazionali vengono usate unicamente comunicazioni criptate con certificati, quindi non è possibile utilizzare il semplice protocollo ssh per effettuare una connessione utente WorkeNode. Jonathan Cacace 566/2731 Pagina 53 di 113

54 Questo aspetto è determinante per comprendere i problemi affrontanti nel corso di questo progetto. Infatti l'unica via per permettere la connessione sul server proxy è quello di utilizzare il protocollo ssh associato al file di certificato dell'utente, attraverso il protocollo gsissh. In ogni caso, su di un WorkerNode l'accesso ssh non trova cittadinanza se non verso gli altri WorkeNode della stessa rete. Questo è uno dei motivi per cui il proxy deve essere necessariamente configurato alla stessa maniera degli altri WorkerNode a cui è collegato. Riepilogando quindi, l'utente dalla propria User Interface si connette tramite gsissh con il certificato al server proxy, da cui è possibile effettuare accesso ssh sul WorkerNode di destinazione senza alcuna richiesta da parte dell'utente Log di sistema Il sistema si occupa inoltre di scrivere file di log che rappresentano il comportamento del sistema nei suoi stati essenziali. Questi file sono necessari all'amministratore del sistema per riuscire a capire in maniera semplice alcuni aspetti del software. I file di log vengono suddivisi in tre classi: il log degli accessi, il log di messaggi e il log degli errori. Il log degli accessi è un file su cui registra gli utenti che utilizzano l'applicazione e arrivano fino al processo di connessione. Su questo file viene registrata l'orario di accesso, il soggetto del certificato dell'utente che ha avviato l'applicazione, l'utente con cui viene connesso al WorkerNode di destinazione ed infine la destinazione a cui è stato dirottato. Una tipica riga di questo file di log ha questa forma: Mon Jan 11 09:20:59 CET 2010: /C=IT/O=INFN/OU=PersonalCertificate/L=Federico II/CN=Jonathan Cacace connesso verso:scopewn02.dsf.unina.it come: matisse020 Jonathan Cacace 566/2731 Pagina 54 di 113

55 Inoltre lo stesso file di log contiene informazioni riguardo la disconnessione degli utenti. Il log dei messaggi rappresenta un file in cui vengono scritti fasi rilevanti dell'esecuzione dell'applicazione, come il download dei file di gridmap o la convalida degli utenti. Anche in questo caso viene ricordata la data in cui viene eseguita l'operazione associata al soggetto del certificato dell'utente che compie l'operazione. Una tipica riga di questo file di log ha questa forma: Mon Jan 11 09:20:59 CET 2010: /C=IT/O=INFN/OU=Personal Certificate/L=Federico II/CN=Jonathan Cacace - Certificto Il terzo ed ultimo tipo di file di log è quello degli errori. Questo file tiene traccia di tutti gli errori che possono avvenire all'interno del sistema. Viene aggiunta una riga a questo file ogni qual volta il sistema ha un comportamento imprevisto o quando un utente non riesce a certificarsi in maniera corretta. Una tipica riga di questo file di log ha questa forma: Fri Jan 22 20:03:01 CET Utente: /C=IT/O=INFN/OU=Personal Certificate/L=Federico II/CN=Jonathan Cacace Download del file di gridmap non riuscito 4.14 La disconnessione La disconnessione dal server può avvenire in due modi diversi. Nel caso in cui Jonathan Cacace 566/2731 Pagina 55 di 113

56 l'utente decida di chiudere la connessione, può terminare la propria sessione dalla shell invocando il comando exit. Deve però essere gestita la disconnessione in modo che l'utente non possa trovarsi sulla shell del proxy da cui è stato rediretto sul WorkerNode. A tal fine, ricordando la modifica apportata al file /etc/profile: /tmp/.fw/`whoami`.sh kill -9 $$ Al termine dell'esecuzione dello script utente.sh, ovvero quando viene chiusa la connessione ssh verso il WorkerNode del job, eseguendo il logout dal WorkerNode, va ad eseguire la seconda riga riportata: kill -9 $$ questo permette la chiusura della sessione sul proxy, in modo che l'utente non potrà mai trovarsi con una shell attiva sul proxy. Un altro modo in cui l'utente può giungere alla disconnessione, è il caso in cui esso abbia una sessione attiva sul WorkerNode ed i job di sua proprietà sono terminati. In questo caso, sul proxy è attivo un processo che controlla ad intervalli regolari se esistono sessioni ssh attive e per ogni utente proprietario delle sessioni se ha job attivi, se non ne ha ne chiude la sessione. Il controllo periodico è effettuato da uno script inserito nella lista dei cron sul server: #Utenti con connessioni ssh attive (user id) a=$( #Nome ps degli aux utenti grep bash$ proprietari grep degli -v ^root user id awk '{print $1}' uniq b=$( cat ); /etc/passwd grep $userid awk '{print for $1}' userid sed in 's/:.*//g' $a ) do #Job ancora attivi nella coda dei processi con i rispettivi proprietari c=$( qstat grep $b ) if [! "$c" ]; then #process id della sessione ssh prid=$( ps aux grep $userid grep bash$ awk '{print $2}' ) for process in $prid do #uccidi la connessione ssh kill -9 $prid Jonathan Cacace 566/2731 Pagina 56 di 113 done fi done

57 4.15La sicurezza: protocollo https, certificazione proxy e le native grid functions La sicurezza appare un aspetto fondamentale di tutte le applicazioni il cui scopo è interfacciarsi con le griglie computazioni. Rispettare gli standard di sicurezza è un aspetto fondamentale g-shell. La sicurezza dell'intero software viene assicurata essenzialmente attraverso tre strumenti: l'utilizzo del protocollo https, la certificazione proxy, e l'uso delle funzioni native grid. Il protocollo https è utilizzato come protocollo di comunicazione tra il client e il server, più precisamente, è il protocollo utilizzato per lo scambio di messaggi tra il client e l'interfaccia web services. Https deriva dal protocollo di trasferimento di ipertesti http, con l'integrazione di un protocollo di crittografia asimmetrica, da qui il maggior grado di sicurezza offerto nello scambio di messaggi tramite questo protocollo. L'utilizzo di una chiave crittografica infatti cerca di impedire intercettazione di dati tramite tecniche di sniffing. Questo Jonathan Cacace 566/2731 Pagina 57 di 113

58 protocollo funziona in maniera analoga al protocollo http, con l'unica differenza che il canale che viene creato è criptato, infatti, una volta stabilito questo canale tra client e server, la comunicazione avviene in maniera analoga al protocollo http. Per quanto riguarda la certificazione proxy, come è stato già discusso in precedenza, questa assicura che gli utilizzatori dell'applicazione siano utenti che abbiano già possibilità di utilizzo della griglia di cui si conosce l'identità. L'utilizzo del file di certificato come discriminante per l'accesso del software da anche possibilità di stabilire particolari politiche di utilizzo, in modo da consentire l'utilizzo del software a soli particolari gruppi di utenti. L'ultimo aspetto conforme alla sicurezza da analizzare, riguarda l'utilizzo di protocolli e funzione native grid. Infatti sia per scaricare il file job-gridmap e per la connessione vengono utilizzate due particolari funzioni: globus-url-copy: questa funzione fa uso del protocollo gsiftp (Grid Security Infrastructure File Transfer). La funzione esegue le normali funzioni del protocollo ftp, utilizzando l'autorizzazione tramite la certificazione proxy. gsissh: (Grid Security Infrastructure Secure shell). Questa funzione invece è necessaria per effettuare ssh con il certificato proxy. gsissh permette la connessione agli utenti con certificato. Quando un utente chiede di ottenere una sessione, viene controllato il file /etc/grid-security/grid-mapfile, In questo file vi sono registrati gli utenti che hanno possibilità di effettuare accesso e sopratutto con che nome utente; una riga generica di questo file è riportata qui: "/C=IT/O=INFN/OU=PersonalCertificate/L=Federico II/CN=Jonathan Cacace" matisse020 Secondo questa riga, l'utente il cui soggetto del certiticato "/C=IT/O=INFN/OU=Personal Certificate/L=Federico II/CN=Jonathan Cacace" può effettuare accessi con nome utente matisse020. Jonathan Cacace 566/2731 Pagina 58 di 113

59 Il file deve essere scritto in modo che, il soggetto del certificato deve combaciare con l'utente che sta eseguendo il job che si vuole controllare. Questo file viene continuamente aggiornato dal server, in maniera dinamica. Quando il server deve permettere ad un utente accesso controlla il file del certificato utente, se il soggetto del certificato è già presente all'interno del grid-mapfile allora controlla l'utente a cui è associato, e, se l'utente associato è quello che sta eseguendo il job allora non modifica il file, se l'utente è diverso lo sostituisce, altrimenti se il soggetto non esiste, crea una nuova riga. Ovviamente questo file può apparire molto pericoloso in quanto, è colui che fornisce i permessi di accesso o meno al server, quindi, deve essere costantemente controllato affinché un utente che non abbia un job attivo, non sia mappato nel file. Per controllare questo, lo stesso processo che controlla la disconnessione degli utenti una volta terminato il job, si cura anche di controllare che non esistano utenti iscritti nel grid-mapfile e non abbiano job attivi: #Utenti mappati nel grid mapfile utenti=$( cat /etc/grid-security/grid-mapfile awk '{print $5}' ) #Utenti con job attivi sulla griglia attivi=$( qstat awk '{if (NR>2) {print $3 }}' ) for users in $utenti do x=$( echo $attivi grep $users ) #Se un utente è nel grid mapfile ma non è in qstat fi if [! "$x" ]; then #Elimina la riga nel grid-mapfile che mappa done l'utente sed -e '/'$users'/d' '/etc/grid-security/gridmapfile' -i 4.16 Il WorkerNode Proxy Il server Proxy è il cuore principale dell'applicazione. Su di essa viene installato il server e deve essere sempre raggiungibile per l'utilizzo del software. Richiamando lo Jonathan Cacace 566/2731 Pagina 59 di 113

60 schema presentato nel paragrafo 4.9, identifichiamo questo server come un componente hardware che deve essere logicamente collegato sia al Computing Element a cui fa riferimento, sia all'intero gruppo di WorkerNode che il Computing Element controlla. Inoltre questo server deve essere raggiungibile dall'esterno del sito grid, quindi deve avere un accesso alla rete internet, in modo che l'interfaccia web services possa essere eseguita senza problemi, la connessione tra il client, sulla User Interface, ed il proxy avviene infatti sulla rete internet. Proxy può essere visto come un particolare tipo di WorkerNode, infatti è fondamentale che questi sia configurato come tale, in modo da avere la lista completa degli utenti che appartengono sia agli altri WorkerNode dove vengono eseguiti i job, e gli stessi utenti del Computing Element ed inoltre il server del software fa spesso utilizzo di funzioni native grid per il controllo dei certificati o altre operazioni, funzioni che non avrebbe senza un'adatta configurazione. Oltre ospitare il server, sulla macchina proxy devono essere attivati alcuni cron che rappresentano processi automatizzati che vengono eseguiti in maniera autonoma e ad intervalli regolari. Questi cron lavorano assieme alle funzioni del server per regolare il funzionamento del software: uno infatti si occupa di disconnettere gli utenti, nel caso in cui il loro job è terminato e non sono ancora disconnessi dal WorkerNode chiudendo la sessione e cancellando il loro soggetto del certificato dal gridmap file ; un'altro si occupa di creare il file token per la strategia del token (paragrafo 4.10) ed infine il terzo ed ultimo cron si occupa di rimuovere i file grid-jobmap una volta che sono diventati troppo obsoleti. 5 Sequence Diagram Il seguente diagramma rappresenta l'intera esecuzione del software, nel caso in cui non si presentino errori. Jonathan Cacace 566/2731 Pagina 60 di 113

61 Jonathan Cacace 566/2731 Pagina 61 di 113

62 Jonathan Cacace 566/2731 Pagina 62 di 113

63 Jonathan Cacace 566/2731 Pagina 63 di 113

64 Jonathan Cacace 566/2731 Pagina 64 di 113

65 Jonathan Cacace 566/2731 Pagina 65 di 113

66 Figura 12: Sequence Diagram dell'intera esecuzione di g-shell I successivi diagrammi rappresentano casi d'errore del software. Il primo errore mostrato, riguarda il caso in cui fallisce uno dei tre controlli avviati dal client, come il controllo della VO, della certificazione, o il controllo sullo stato del job. Jonathan Cacace 566/2731 Pagina 66 di 113

67 In questo caso viene mostrato il fallimento del controllo sul job. Figura 13: Sequence Diagram caso di errore di g-shell sul controllo dello stato del job Qui invece viene riportato il diagramma di sequenza nel caso in cui il job che si desidera controllare non viene trovato sul Computing Element. Jonathan Cacace 566/2731 Pagina 67 di 113

68 Jonathan Cacace 566/2731 Pagina 68 di 113

69 Figura 14: Sequence Diagram caso di errore di g-shell sul controllo della presenda del job sul Computing Element 6 Statechart Diagram Jonathan Cacace 566/2731 Pagina 69 di 113

70 principali: Il seguente diagramma rappresenta il comportamento del sistema nei suoi stati Jonathan Cacace 566/2731 Pagina 70 di 113

71 Figura 15: Statechart Diagram del funzionamento di g-shell 7 Deployment del servizio sull'infrastruttura Come già detto, il servizio offerto da g-shell, è utilizzabile applicando una semplice modifica hardware al sito grid già attivo. Deve essere infatti collegato al sito un Jonathan Cacace 566/2731 Pagina 71 di 113

72 ulteriore macchina, il WorkerNode Proxy. Per la corretta diffusione del servizio sull'infrastruttura, i collegamenti fisici e logici devono essere effettuati in questa maniera: Il Proxy, deve essere in grado di comunicare con il Computing Element a cui è associato, e con tutti i WorkerNode collegati al Computing Element, all'interno della stessa rete lan. Inoltre il Proxy deve essere raggiungibile dalla rete internet, in modo da poter essere contattato dal client dell'applicazione. Il proxy deve essere configurato, utilizzando lo stesso file di configurazione degli altri WorkerNode già presenti, e su di esso deve essere installato il software glite con le estensioni per le funzioni voms. Infine, sempre sul server Proxy bisogna istallare un server http, in modo che l'interfaccia web services possa funzionare in maniera corretta. Appare quindi evidente che integrare questo servizio all'interno di una struttura già funzionante garantisce un impatto minimo. Non modificando in alcun modo la configurazione preesistente della griglia computazionale favorisce in maniera evidente il deployment su di una infrastruttura già funzionante. Jonathan Cacace 566/2731 Pagina 72 di 113

73 8 Esempio di funzionamento In questo capitolo viene presentato un esempio di uso del software, dividendolo nei suoi passi principali. L'azione di base da compiere è quella di accedere alla propria User Interface. Figura 16: Esempio di funzionamento: login sulla user interaface Figura 16(b): Esempio di funzionamento: login sulla user interaface Jonathan Cacace 566/2731 Pagina 73 di 113

74 In questo modo è possibile accedere alle funzioni voms per la certificazione, alle funzioni per la sottomissione di job e all'applicazione g-shell. Il passo successivo è quello di identificarci sulla user interface attraverso il nostro file di certificato, specificando la virtual organization a cui si appartiene: Figura 17: Esempio di funzionamento: identificazione dell'utente come appartenente alla Vo matisse Figura 17(b): Esempio di funzionamento: identificazione dell'utente come appartenente alla Vo matisse Jonathan Cacace 566/2731 Pagina 74 di 113

75 In questo modo possiamo essere in grado di sottomettere job sul computing element ed utilizzare g-shell. Si consideri ora il codice bash riportato: #!/bin/bash echo "Bazinga" x=0 echo $x while [ $x -lt 100 ]; do sleep 110 x=$(( x+1 )) echo $x done Questo script non fa altro che stampare la stringa Bazinga appena avviato, e poi incrementa una variabile x ogni 110 secondi, finché questa non giunge al termine. Supponiamo di voler controllare lo stato di questo job una volta inviato in esecuzione. Creiamo il file jdl (job.jdl) che manderemo in esecuzione: Executable = "job.sh"; StdOutput = "job.out"; StdError = "job.err"; InputSandbox="/home/jcacace/dir/job.sh"; OutputSandbox = {"job.out","job.err"}; Requirements=other.GlueCEUniqueID== "scopece01.dsf.unina.it:2119/ jobmanager-lcgpbs-resto"; Ora è possibile sottomettere il job jdl, verrà poi atteso l'inizio dell'esecuzione del job, ed infine si andrà a controllare lo stato del job, visualizzando l'output parziale già dopo alcuni minuti dall'inizio della sua esecuzione. Per sottomettere il job bisogno utilizzare un comando messo a disposizione da glite, indicando come oggetto di sottomissione il file jdl creato come riportato nel codice qui sopra: Jonathan Cacace 566/2731 Pagina 75 di 113

76 Figura 18: Esempio di funzionamento: sottomissione del job job.jdl Come appare dalla figura abbiamo sottomesso correttamente un job. Dalla stessa è possibile recuperare il job id che in questo caso è: Ora è possibile utilizzare l'applicazione g-shell su questo job, ovviamente dobbiamo attendere che esso sia in stato running. Quando infine il job inizia la sua esecuzione invece: Figura 19: Esempio di funzionamento: avvio di g-shell L'utente viene convalidato dal server, ed ha quindi diritto di accesso alla sessione sul WorkerNode. Jonathan Cacace 566/2731 Pagina 76 di 113

77 Figura 19(b): Esempio di funzionamento: avvio di g-shell In questo momento l'utente si trova rediretto sul WorkerNode dove è in esecuzione il proprio job. Più precisamente è nella directory dove vengono salvati file temporanei e di output. Per esempio vogliamo vedere se lo script ha iniziato legalmente la sua esecuzione, o magari siamo interessati al valore della variabile x, che è considerato una parte dell'output finale del job, basta accedere nella directory nominata come il job id che si sta controllando: Figura 19(c): Esempio di funzionamento: avvio di g-shell Jonathan Cacace 566/2731 Pagina 77 di 113

78 possiamo notare che il processo è stato avviato senza problemi e che il valore della x è arrivato a 3. Quando poi l'utente vole disconnettersi dal sistema: Viene riportato sulla user interface da cui ha avviato il software. Figura 20: Esempio di funzionamento: termine dell'applicazione g-shell 8.1 Casi di errore I tipici errori che un utente può incontrare durante l'utillizzo del software sono: Impossibilità di trovare un certificato proxy valido: Figura 21: Esempio di funzionamento: errore sulla certificazione utente Jonathan Cacace 566/2731 Pagina 78 di 113

79 Il job non è ancora in stato running: Figura 22: Esempio di funzionamento: errore controllo dello stato del job La virtual organization a cui si è iscritti non è supportata dal server: Figura 23: Esempio di funzionamento: errore vo di appartenenza Il job che sto cercando di controllare non è di mia appartenenza: Jonathan Cacace 566/2731 Pagina 79 di 113

80 Figura 24: Esempio di funzionamento: errore sul proprietario del job 9 Codice prodotto 9.1 Client g-shell Signature: g-shell.pl (Jobid) Parametri di input: jobid. Id del job sottomesso che si vuole controllare Parametri di output: eventuale verbose di errori Funzioni esterne: funzioni native grid (gsissh voms-proxy-info glite-wms-job-status) Descrizione: Rappresenta il client dell'applicazione. Attraverso questo eseguibile, specificando il job id che si desidera controllare è possibile ottenere, dopo una serie di controlli e di verifiche sulla bontà dell'utente e sullo stato del job, una sessione sul WorkerNode che si sta curando dell'esecuzione del job. Nel caso di errori durante l'utilizzo viene mostrato un verbose in output, altrimenti l'utente, senza ulteriori interazioni con il software, si trova rediretto in una sessione sul WorkerNode. 9.2 Server Jonathan Cacace 566/2731 Pagina 80 di 113