Sviluppo di procedure per l automatizzazione del flusso di lavoro per l analisi dati distribuita in Grid nell esperimento CMS

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Sviluppo di procedure per l automatizzazione del flusso di lavoro per l analisi dati distribuita in Grid nell esperimento CMS"

Transcript

1 Università degli Studi di Perugia Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea in Informatica Tesi di Laurea Sviluppo di procedure per l automatizzazione del flusso di lavoro per l analisi dati distribuita in Grid nell esperimento CMS Candidato Mattia Cinquilli Relatore Prof. Leonello Servoli Correlatore Dott. Daniele Spiga

2 ii

3 Indice Introduzione 1 1 Grid Introduzione a Grid Grid computing Definizione di Grid Architettura Grid Livelli architetturali Grid di produzione Sostenibilità dell infrastruttura Grid: dallo sviluppo alle operazioni Da Grid a cloud computing Architettura WLCG/EGEE Utenti e VO Sicurezza Elementi principali del middleware Job flow: sottomissione MAGIC-5: un caso d uso della Grid Flussi di lavoro complessi in ambienti distribuiti Client-server computing Definizione di client-server computing Un server per ogni client Caratterizzazione Funzioni del client Funzioni del server Modelli strutturali Integrazione con il calcolo distribuito Classificazione dei sistemi client-server in base alla topologia... 31

4 iv Modello a due livelli (two-tiers) Modello a tre livelli (three-tiers) Modello a N livelli (N-tiers) Client-server: vantaggi e svantaggi Vantaggi Svantaggi Sviluppo di un sistema client-server Strumenti di sviluppo Software Development Life Cycle Pianificazione Definizione dei requisiti Progettazione Sviluppo Integrazione e test Installazione Client-server: sicurezza Le minacce di sicurezza emergenti Server: possibili minacce LHC e CMS LHC CMS L ambiente computazionale di CMS Framework dell analisi distribuita in CMS CRAB: evoluzione verso un architettura client-server Motivazioni dell evoluzione Client-server: fattorizzazione del flusso di lavoro Strategia implementativa Architettura del server Classificazione logica delle componenti Descrizione agenti di input/output Descrizione agenti di logica e di gestione Descrizione agenti per l interazione con la Grid Interfaccia al middleware ed ai sistemi di batch: BossLite Implementazione dei componenti di gestione dei task Richieste degli utenti: task Task e job Componente per l aggregazione delle informazioni sui task... 85

5 v TaskTracking: architettura Componente per la gestione del ciclo di vita dei task TaskLifeManager: architettura Supporto per l interazione trasparente con Storage Element SEAPI: architettura SEAPI: funzionamento Risultati Dalla fase di test alle operazioni in produzione Test di scala del server Fase con un solo utente Fase multiutente Utilizzo del server di CRAB in produzione Valutazione dell e cienza dei job Conclusioni 115 Ringraziamenti 117 Bibliografia 119

6 vi

7 Elenco delle figure 1.1 I tre macro livelli architetturali di una griglia computazionale Autentificazione nella Grid Elementi della Grid WLCG/EGEE Job Flow nella Grid WLCG/EGEE Topologia client-server con un server per un unico client Topologia client-server con un solo server per client multipli Topologia client-server con più server e più client Modello client-server su due livelli Modello client-server su tre livelli Modello client-server su N livelli SDLC: fasi base Il progetto LHC Struttura del rivelatore CMS Il modello computazionale di CMS: l architettura su livelli Velocità dei trasferimenti di PhEDEx dal 2004 al CRAB workflow. WMS può essere inteso sia come glite WMS che come glidein WMS CRAB: flusso di lavoro e interazioni L aggiunta di un nuovo livello fra la Grid e l utente CRAB: flusso di lavoro e interazioni con l introduzione del server Schema SQL del supporto per la gestione del Message Service Vista schematica dell architettura del server di CRAB Job per sito sottomessi dal 20 Novembre 2009 al 28 Dicembre Grafico prelevato dall HTTPFrontend del server di analisi di Legnaro Implementazione con un pool di thread della componente JobTracking Schema UML della componente GetOutput Vista schematica dell architettura di BossLite

8 viii 5.1 Architettura e componenti del server di CRAB; in rosso sono evidenziati gli agenti dedicati alla gestione dei task e le frecce relative all interazione con lo Storage Element attraverso le SEAPI Schema delle interazioni della TaskTracking con le altre componenti del server Diagramma delle classi degli oggetti della TaskTracking costruito con la specifica UML Schema del funzionamento dei thread e della coda dei task Diagramma delle classi degli oggetti della TaskLifeManager costruito con la specifica UML Principali componenti logiche delle SEAPI Diagramma delle classi degli oggetti delle SEAPI costruito con la specifica UML Schema di un caso d uso delle SEAPI nel caso di un tasferimento da uno Storage Element ad un altro Distribuzione per stato dei job sottomessi attraverso il server di CRAB sul middleware glite durante la fase di test di sottomissioni controllate con singolo utente. Informazioni prelavate dai dati contenuti nella base di dati del server, attraverso l HTTPFrontend (cap. 4) Utilizzo percentuale della CPU (scala verticale) distribuito nel tempo (scala orizzontale) da parte del server MySQL (sorgente: HTTPFrontend) Distribuzione per stato dei job sottomessi al server durante la fase di test multiutente (sorgente: HTTPFrontend) Distribuzione giornaliera del numeri di utenti diversi che hanno utilizzato i server di CRAB a partire da Gennaio 2009 fino a metà Gennatio Grafico generato tramite le informazioni messe a disposizione dalla Dashboard (cap. 3) Distribuzione dei job sottomessi tramite i server di CRAB fra i siti della collaborazione CMS (sorgente: Dashboard) Distribuzione della frazione giornaliera di jobs terminati con successo durante tutto l anno 2009 (sorgente: Dashboard) Distribuzione giornaliera della percentuale di jobs terminati con stato Abort durante tutto l anno 2009 (sorgente: Dashboard)

9 Introduzione Una Griglia Computazionale è un ambiente sviluppato per il calcolo distribuito che consente la condivisione, selezione e aggregazione di risorse autonome geograficamente distribuite utilizzate a tempo di esecuzione, a seconda della loro disponibilità, capacità e prestazioni. La crescente domanda di risorse di calcolo nel mondo moderno ha portato dagli anni 50 ad oggi all incremento esponenziale della potenza di calcolo. Dalla costruzione dei primi Supercomputer che concentravano tutta la potenza in unico sistema, si è arrivati all unione delle risorse di piú computer collegati su di una rete locale, cioé il Cluster Computing. Successivamente, l idea che il potenziale generato da un sistema di computer in cluster connessi fra loro fosse su ciente per soddisfare le richieste delle applicazioni più onerose, portò l esigenza di andare oltre quella che era stata la comune struttura di un sistema di calcolo. Quindi vennero create le prime griglie computazionali. Attualmente esistono molteplici implementazioni di questo paradigma con casi d uso che vanno dalla ricerca di nuove terapie di cura delle malattie (come l Alzheimer e l AIDS), fino ai servizi finanziari. Fra gli utilizzatori della griglia computazionale vi sono anche gli esperimenti di fisica delle alte energie in funzione al Large Hadron Collider (LHC) del CERN a Ginevra, che hanno individuato in questa tecnologia le potenzialità in grado di soddisfare le proprie esigenze computazionali. Il Compact Muon Solenoid (CMS) è uno dei 4 esperimenti di LHC che ha progettato il modello di calcolo sul paradigma di Grid. A regime il rilevatore CMS sarà in grado di acquisire una quantità di dati annua pari a 1 PB. Il processamento e quindi l analisi di questa mole di dati richiede una quantità di risorse di calcolo e di memorizzazione senza precedenti. La griglia computazionale fornisce la risposta a queste esigenze, garantendo inoltre ad ogni utente della vasta collaborazione la possibilità di accesso ai dati distribuiti in Grid. CMS nel corso degli anni ha quindi sviluppato delle applicazioni basate su sitemi Grid che possono essere classificate in due categorie: quelle necessarie alla gestione dei dati e quelle necessarie alla gestione dei flussi di lavoro per il relativo processamento. Lo scopo di questo lavoro di tesi è la progettazione e lo sviluppo di componenti fondamentali di un sistema basato su architettura client/server, specializzato nella gestione

10 2 del flusso di lavoro dell analisi dati distribuita, tale che rappresenti una piattaforma per il supporto di flussi complessi quali quelli concatenati, tipici di alcuni casi d uso di un esperimento di fisica delle alte energie (calibrazione ed allineamento del rivelatore di particelle elementari). Il modello di calcolo di CMS prevede tre livelli computazionali (detti Tier) organizzati gerarchicamente. Dopo una prima fase di processamento cha avviene al Tier-0 del CERN, i dati sono spediti ai Tier-1. Questi ultimi devono garantirne la custodia e la potenza di calcolo per i successivi riprocessamenti. I dati vengono infine resi disponibili ai Tier-2, centri di calcolo di dimensioni inferiori ai Tier-1, responsabili per il supporto di tutte le attività di analisi dell utente. Secondo questo schema computazionale i fisici della collaborazione CMS sono obbligati ad interagire con il complesso ambiente distribuito di Grid. Tale aspetto può essere piuttosto complicato soprattutto per utenti di fisica, storicamente più interessati ai risultati dell analisi piuttosto che agli aspetti tecnici del sistema di calcolo. Il miglior modo di soddisfare tali esigenze è quello di incapsulare l utente finale in un ambiente protetto, da cui la scelta di disegnare un applicazione basata all architettura client/server. La presentazione del lavoro di tesi si articola in 6 capitoli. Nel primo viene data una descrizione della griglia computazionale come infrastruttura di calcolo distribuito, della sua architettura, delle implementazioni più importanti e delle varie fasi del flusso di lavoro. Nel secondo viene descritta la teoria del client/server computing illustrandone l architettura e le varie topologie d implementazione, descrivendo in particolar modo i vantaggi e gli svantaggi del suo utilizzo. Nel terzo viene fatto un quadro dell esperimento CMS da un punto di vista prettamente computazionale, descrivendo quindi: i servizi e le applicazioni specifiche per la gestione dei dati, del software per l analisi dei dati e le applicazioni d interfaccia alla griglia computazionale. Negli ultimi tre capitoli si illustra la parte originale del lavoro di tesi. In particolare nel capito quattro vengono descritte in dettaglio le motivazioni per la scelta di un applicazione client/server, la strategia e l architettura utilizzata. Il quinto capitolo presenta i dettagli dello sviluppo di due componenti del server (TaskTracking e TaskLifeManager) e delle librerie necessarie ad interagire con i servizi di memorizzazione della griglia. Infine nel sesto capitolo vengono presentati i risultati ottenuti durate un intero anno di attività.

11 C è tanta gente infelice che tuttavia non prende l iniziativa di cambiare la propria situazione perché è condizionata dalla sicurezza, dal conformismo, dal tradizionalismo, tutte cose che sembrano assicurare la pace dello spirito, ma in realtà per l animo avventuroso di un uomo non esiste nulla di più devastante di un futuro certo. Il vero nucleo dello spirito vitale di una persona è la passione per l avventura. La gioia di vivere deriva dall incontro con nuove esperienze, e quindi non esiste gioia più grande dell avere un orizzonte in continuo cambiamento, del trovarsi ogni giorno sotto un sole nuovo e diverso. Se vuoi avere di più dalla vita, devi liberarti dalla tua inclinazione alla sicurezza monotona e adottare uno stile più movimentato che al principio ti sembrarà folle, ma non appena ti ci sarai abituato, ne assaporerai il pieno significato e l incredibile bellezza. Chris McCandless

12 4

13 Capitolo 1 Grid The secret of a Grid s success is not so much its structure as the imagination with which it is used. Allen Hurlburt 1.1 Introduzione a Grid Dalla creazione del primo microprocessore su di un solo chip agli inizi degli anni 70 è stata fatta molta strada nell incremento delle prestazioni computazionali. Proprio in quegli anni il cofondatore della Intel Corporation, Gordon Moore, diceva: Le prestazioni dei processori, e il numero di transistor ad esso relativo, raddoppiano ogni 18 mesi. [1] Questa previsione si rivelò corretta e per tutti gli anni 70 e 80 le prestazioni delle CPU andavano migliorando ad un ritmo equivalente a quello che Moore aveva previsto. Inoltre, dagli inizi degli anni 80 si assistette ad una crescente commercializzazione di personal computer ed all avvio dell informatizzazione di massa. L ascensione vertiginosa delle prestazioni di un singolo microprocessore non era destinata a durare ancora per molto. Nonostante l introduzione di supercomputer 1 e mainframe 2, gli onerosi calcoli scientifici, ma non solo quelli, richiedevano prestazioni di calcolo sempre più bisognose di risorse. La velocità con cui aumentava la complessità dei software, e quindi la loro necessità di risorse era maggiore delle prestazioni 1 Isupercomputersonodeisistemidielaborazioneprogettatiperottenerepotenzedicalcolomolto elevate. 2 Mainframe: un computer grande e dotato di elevata capacità di elaborazione in grado di supportare l utilizzo contemporaneo da parte di numerosi utenti, anche migliaia.

14 6 1 Grid hardware che potevano essere fornite. Questo ha portato all unione delle risorse di piú computer collegati su di una rete telematica locale sviluppando tecnologie quali il Cluster Computing, che permette di e ettuare calcoli in parallelo. I calcolatori facenti parte di questo sistema possono essere eterogenei, funzionando comunque in un modo tale da poter essere considerati come un singolo computer. Questo permette di scomporre un problema che richiede molte elaborazioni in sottoproblemi separabili che possono essere distribuiti fra i vari nodi del cluster, e dove applicabile per risolverli in parallelo. Sono state sviluppate varie tecnologie per la creazione di programmi in grado di essere eseguiti in parallelo e per l interfacciamento del cluster stesso; tra cui MPI e PVM. Quest ultimo è acronimo di Parallel Virtual Machine[2], ed è un software progettato per permettere a macchine eterogenee, connesse via rete, di essere usate come un singolo processore parallelo e distribuito. L MPI (Message Passing Interface)[3] è un protocollo di comunicazione fra computer, o nodi, che eseguono un programma parallelo su di un sistema distribuito. Una naturale evoluzione di questi concetti è il Grid computing o Grid cluster che è una tecnologia strettamente collegata al cluster computing. Nel 1996 venne pubblicato su The International Journal of Supercomputer Applications and High Performance Computing [4] un articolo destinato a far tramontare la legge di Moore. La pubblicazione fu intitolata Overview of the I-WAY: Wide Area Visual Supercomputing e tra gli autori vanta Ian Foster 3. Il progetto I-WAY (Information Wide Area Year) è stato il primo riguardante: la costruzione di applicazioni in una realtà virtuale distribuita; la gestione di risorse distribuite in una WAN 4 ; il relativo scheduling della richiesta di risorse. Lo scopo dell esperimento era quello di usare risorse per consentire ai ricercatori di e ettuare calcoli computazionali su larga scala. Connettendo 17 centri tramite una comunicazione via rete di tipo ATM 5 usando i collegamenti di rete già esistenti, 5 siti di ricerca virtuale ed oltre 60 gruppi di applicazioni, il progetto I-WAY venne creato in una WAN 6 eterogenea. L obiettivo principale era quello di avere applicazioni che 3 Ian Foster è ricercatore presso il Mathematics and Computer Science Division all Argonne National Laboratory e professore di Informatica all University of Chicago; meglio conosciuto come father of the Grid (il padre della griglia) 4 WAN (Wide Area Network) è una rete di computer usata per connettere LAN (Loacal Area Network) 5 Asynchronous Transfer Mode 6 WAN: Wide Area Network (rete geografica), che collega nodi a distanza qualsiasi, anche planetaria.

15 1.1 Introduzione a Grid 7 usassero più di un supercomputer, di uno o più dispositivi virtuali e di avere una tecnologia collaborativa usando spazi virtuali comuni nei quali condurre una scienza computazionale. L obiettivo secondario da un punto di vista teorico, ma non da un punto di vista tecnico, era quello di scoprire problemi legati ad un uso esteso della tecnologia basata su sistemi distribuiti. Questo portò all analisi ed alla relativa risoluzione di problematiche molto importanti nello sviluppo di applicazioni distribuite, quali: sicurezza; ambienti computazionali uniformi; scheduling globale delle risorse distribuite; riserva (lock) di risorse; definizione e gestione di gruppi di ricerca virtuali distribuiti, ma collaborativi. I-WAY permise di sperimentare un nuovo metodo per rendere possibili calcoli che necessitavano di risorse sempre maggiori, andando a sfruttare la potenza di calcolo di tutti quei computer dedicati ad altre attività, ma momentaneamente inutilizzati. Una metodologia di calcolo computazionale distribuito, che avrebbe permesso di condividere dati e potenza di calcolo tramite una rete a pubblico accesso, creando una vastissima risorsa computazionale, venne quindi considerata la soluzione ideale per risolvere problemi. Questo nuovo sviluppo avvenne parallelamente alla progressiva involuzione della legge di Moore, causata soprattutto da limiti tecnologici, quali: l impossibilità di ridurre la scala del gate del singolo transistor a causa dell incremento della densità di corrente eladi coltà legata alla schermatura dei chip all aumentare delle frequenze di calcolo (circa 3 GHz odierni). Oramai le performance dei chip non raddoppiavano più e il loro prezzo non stava diminuendo come era accaduto in passato. Inoltre dall avvento del progetto I-WAY l obiettivo principale non era più quello di creare risorse per il calcolo computazionale sempre più potenti in una densità sempre minore: era di rendere l utilizzo di risorse geograficamente distribuite sempre più facile ed e ciente. Ma sotto un altro punto di vista, l avvento del progetto di Ian Foster aveva portato nuova linfa allo sviluppo del calcolo computazionale, costruendo una nuova struttura che si potesse interporre fra l hardware e l utente, migliorando ulteriormente le prestazioni di calcolo, senza il bisogno di aumentare ancora una volta vertiginosamente la complessità della circuiteria di un computer. Il progetto di Ian Foster era l inizio di quell infrastruttura di calcolo computazionale

16 8 1 Grid che evolvendosi ha portato a focalizzare lo sviluppo su quelle che oggi sono le griglie computazionali. 1.2 Grid computing In seguito al progetto I-WAY vi fu un moltiplicarsi di progetti che prevedevano lo sviluppo di un infrastruttura di calcolo simile ad esso. Tutti i progetti avevano in comune la stessa architettura globale e tecnologie simili venivano usate per la realizzazione. La Grid vera e propria nacque ad un gruppo di lavoro presso l Argonne National Laboratory nel Settembre del Questo fu seguito da una pubblicazione del 1998 intitolata The Grid: Blueprint for a New Computing Infrastructure [5] di Ian Foster e Carl Kesselman, ma meglio conosciuta come La bibbia di Grid Definizione di Grid La griglia computazionale è un tipo di sistema parallelo e distribuito che consente la condivisione, selezione e aggregazione di risorse autonome geograficamente distribuite utilizzate a tempo di esecuzione, a seconda della loro disponibilità, capacità, prestazione, costo e qualità del servizio richiesto dall utente. Dunque il Grid Computing è l applicazione infrastrutturale di quella logica di condivisione delle risorse che consente di utilizzare la potenza di elaborazione di una serie di computer collegati in rete via Internet, dividendo i processi di calcolo e di memoria secondo regole di distribuzione definite dai gestori della Grid. Ciò che rende possibile quest infrastruttura intermediando fra diverse entità è il middleware. Questo è un software di connessione formato da un insieme di servizi e di ambienti di sviluppo che consentono a più entità, che possono risiedere su uno o più elaboratori, di interagire attraverso una rete di connessione a dispetto di di erenze nei protocolli di comunicazione, architetture dei sistemi locali, sistemi operativi, ecc... Dunque, lo scopo del middleware è quello di o rire servizi di comunicazione, astrazione, collaborazione ed un ambiente di sviluppo delle applicazioni per permettere l interoperabilità e la connettività fra applicazioni distribuite su risorse eterogenee. [5] Passiamo ad analizzare in dettaglio le proprietà della Grid. Condivisione di risorse La possibilità di condividere risorse eterogenee, intese come potenza di calcolo e spazio disco, in scala globale è una caratteristica essenziale della Grid. Le risorse possono essere costituite da piattaforme di erenti, con diverse architetture hardware e software, con diversi linguaggi computazionali, situate in luoghi

17 1.2 Grid computing 9 di erenti, appartenenti a di erenti domini amministrativi. La condivisione deve essere ad un livello di astrazione tale da rendere una generica operazione completamente trasparente all utente. Questo ha il vantaggio di proiettare l utente stesso in un ambiente virtualizzato, nel quale accedere a dati e risorse locali o distribuiti nella Grid non faccia alcuna di erenza. Da questo punto di vista Grid è un evoluzione di Internet in quanto permette di migliorare i collegamenti, definendo opportuni protocolli di comunicazione, ma in un contesto generico. Nella definizione di questi protocolli entra in gioco il concetto di sicurezza che è un aspetto importante e critico della Grid e che deve essere ad un livello molto alto. Sicurezza Poiché non è possibile una condivisione incondizionata di risorse a livello di Internet, è fondamentale che l aspetto della sicurezza sia trattato in una Computing Grid. Per questo, vengono definiti tre livelli di sicurezza: politica di accesso: i fornitori di risorse e gli utenti devono definire con chiarezza e precisione a chi è permesso di condividere risorse e per quali condizioni le risorse possono essere accedute; autenticazione: è fondamentale un meccanismo per la verifica dell identità di una risorsa e di un utente; autorizzazione: è necessario un meccanismo per determinare se un operazione è permessa, a seconda del tipo di politica di accesso delle risorse. Quindi è importante sapere chi è autorizzato ad usare Grid e quali risorse in particolare; chi certifica che l utente autentificato sia proprio quell utente; quali sono le politiche d uso delle risorse. Uso delle risorse Con un quantitativo di risorse molto grande, è fondamentale un e ciente uso delle stesse. Questo perché non ha importanza avere un numero di risorse molto elevato se ogni volta che un utente voglia accedervi esso trovi lunghe code di utenti per la stessa risorsa. È primario l obiettivo di distribuire i lavori fra le code, allocando i lavori e cientemente in modo da distribuire gli accessi fra più risorse. Quindi, in linea di principio, un utente ha informazioni relative a diversi lavori (jobs) sottomessi su Grid ed è possibile calcolare una distribuzione ottimale per l allocazione delle risorse. Un software che esegua questa analisi di carico e distribuzione di jobs è da considerare parte integrante del middleware della Grid.

18 10 1 Grid 1.3 Architettura Grid Non è possibile definire un architettura Grid che possa essere considerata come definitiva perché le caratteristiche e l architettura dipendono fortemente dal caso concreto. Ad esempio è ben diverso avere risorse omogenee gestite amministrativamente in maniera centralizzata dall organizzare risorse eterogenee e controllabili solo localmente. In questo ultimo caso, che è quello che ci interessa, una delle richieste a cui dovrà soddisfare la Grid è quella di assemblare risorse eterogenee, di mettere a disposizione un infrastruttura scalabile che assicuri dinamicità nell uso e nell organizzazione delle risorse. È tuttavia possibile definire come è organizzata in generale una Grid da un punto di vista concettuale Livelli architetturali Come è possibile vedere in figura 1.1 sono distinguibili tre macro-livelli. Applicazioni Scientifiche, Business e Ingegneristiche Applicazioni d'ambiente per lo sviluppo APPLICAZIONI High Level Knowledge Services Security Workload Management System Low Level MIDDLEWARE Scheduling Monitoring Communica tion Risorse Computers Storage Elements Dati FABRIC Figura 1.1: I tre macro livelli architetturali di una griglia computazionale.

19 1.3 Architettura Grid 11 Livello delle Applicazioni Ne fanno parte tutte le applicazioni dell utente che interagiscono, direttamente o non, con la Grid. Talvolta contiene l interfaccia che consente all utente di interagire con la Grid e quindi anche l ambiente di programmazione (API). Questo è caratterizzato da un assoluta portabilità attraverso vari tipi di sistemi hardwaresoftware e loro combinazioni in un contesto di eterogeneità e dinamicità. Inoltre tutto il meccanismo della gestione dei gruppi di lavoro è parte integrante di questo livello. Livello Middleware Questo livello è a sua volta scomponibile in due parti: un livello più vicino all utente (High Level) ed uno più vicino alle risorse (Low Level). L High Level è costituito da: Knowledge Discovery: servizi di Grid che forniscono un accesso consistente, pervasivo ed e cace a risorse computazionali, con un interesse rivolto allo sfruttamento della Grid come un sofisticato strumento di Web computing ; Sicurezza: la possibilità di un e cace ed e ciente controllo di accesso alla griglia per avere ambienti di Grid sicuri, ma anche per una cooperazione tra ambienti Grid appartenenti a di erenti organizzazioni; Resource Broker: servizio che fornisce un collegamento tra la richiesta di risorse e le risorse disponibili. Il Low Level è composto da: Scheduling: interagendo con i servizi del suo livello e di quello superiore si occupa di mappare costantemente le risorse della Grid, decidendo su quali siti devono essere assegnati i vari lavori, bilanciando il carico di lavoro a seconda delle informazioni disponibili; quindi garantisce un accesso altamente e ciente ad informazioni statiche e dinamiche traducendo le richieste di alto livello in richieste di basso livello; Monitoring: questo servizio si incarica di controllare l utilizzo delle risorse del sistema e di dare un supporto diagnostico in caso di guasti e sovraccarichi; Comunication: definisce i protocolli di comunicazione e autenticazione per le transazioni di rete abilitando lo scambio dei dati con il livello fabric. I protocolli di comunicazione permettono lo scambio di dati tra le risorse del livello inferiore, cioè implementano i servizi di trasporto, routing e naming; mentre i protocolli di autenticazione forniscono un meccanismo di autoriz-

20 12 1 Grid zazione e protezione delle comunicazioni in uno scenario multi-istituzionale permettendo l interoperabilità tra le varie soluzioni locali. Livello Fabric Le risorse sono oggetti che hanno proprietari, che possono essere usate per un certo periodo di tempo e che possono essere rinnovabili oppure no. Sono gestite tramite lo Scheduling, il Knowledge Discovery e il Resource Broker. Questi permettono di allocare le risorse di cui ha bisogno un utente, sottraendole a quelle disponibili. I dati possono essere replicati per l ottimizzazione delle risorse di memorizzazione, garantendo prestazioni migliori nell accesso ai dati. Alcuni esempi di risorse possono essere lo spazio disco, la banda di rete, il tempo di CPU o semplicemente i dati. 1.4 Grid di produzione Dopo il progetto I-WAY sono nati nuovi e sempre più avanzati progetti che prevedono l applicazione della Grid, per scopi principalmente scientifici e finanziari. Ecco un elenco dei principali: Condor[6]. È un progetto sviluppato a partire dal 1988 dall University of Wisconsin (Madison, USA) con l idea di sfruttare la potenza di calcolo dei desktop universitari accesi ma momentaneamente inutilizzati. L obiettivo del progetto è quello di sviluppare, implementare, di ondere e valutare i meccanismi e le linee di condotta per il supporto dell High Throughput Computing (HTC) in grandi insiemi di risorse computazionali proprietarie e distribuite. Gli utenti sottomettono i loro job, seriali o paralleli che siano, a Condor; quest ultimo mette i job in una coda, sceglie quando e dove eseguire i job, ne segue l andamento, ed alla fine informa l utente al termine dell esecuzione. UNICORE[7]. É una tecnologia di Grid Computing che fornisce l accesso trasparente, sicuro e intuitivo a risorse distribuite Grid come supercomputer o sistemi cluster e le informazioni memorizzate nelle basi di dati. UNICORE (Uniform Interface to Computing Resources) è stato sviluppato in due progetti finanziati dal ministero tedesco per l istruzione e la ricerca. L architettura è costituita da tre livelli: l utente (client), il server e il sito di destinazione. NorduGrid[8]. Nasce come infrastruttura di calcolo distribuito a disposizione delle università e dei centri di ricerca del Nord Europa. NorduGrid utilizza il middleware ARC[9] che include molteplici applicativi e librerie mediante le quali è possibile realizzare i servizi base (monitoraggio delle risorse distribuite, gestione dei dati, comunicazione, autenticazione e sicurezza, portabilità) su cui

21 1.4 Grid di produzione 13 definire il middleware di livello superiore. Le sue diverse componenti possono essere adoperate indipendentemente l una dall altra oppure in maniera congiunta al fine di sviluppare applicativi per il Grid Computing. LCG[10]. L LHC Computing Grid Project è stato creato dal CERN (Ginevra, Svizzera) nel 2001 con lo scopo di costruire e mantenere l infrastruttura computazionale necessaria per la memorizzazione e l analisi dei dati provenienti dai quattro esperimenti dell LHC (ALICE, ATLAS, CMS e LHCb). LCG costituisce un test di vitale importanza per le nuove tecnologie informatiche Grid e potrebbe rivoluzionare il modo in cui utilizziamo le risorse dei computer in aree che vanno dalla ricerca fondamentale alla diagnostica medica. EGEE[11]. Enabling Grid for E-sciencE è il progetto finanziato dalla Comunità Europea che ha come scopo la realizzazione di un infrastruttura Grid sicura, a dabile e robusta, che consenta di accedere a risorse geograficamente distribuite 24 ore al giorno. La base di partenza è stata quella del preesistente LHC Computing Grid (LCG), e uno degli scopi è di fornire a LCG nuove versioni del middleware. Questo progetto garantisce anche l interoperabilità di implementazioni diverse (glite[12], ARC, UNICORE). OSG[13]. L Open Science Grid è un infrastruttura Grid per la scienza su larga scala, sviluppata ed adoperata da un consorzio di università e laboratori degli Stati Uniti. È stata formata nel 2004 per permettere a di erenti comunità di scienziati di accedere ad una infrastruttura Grid che permettesse di sfruttare le risorse comuni. Questa include due progetti: Integration e Production Grid. L Integration Grid permette di verificare nuove tecnologie e applicazioni, mentre la Production Grid fornisce un ambiente stabile e supportato per applicazioni destinate ad un uso a lungo termine. Le capacità e la linea di sviluppo di questo progetto, sono guidate dai partecipanti degli Stati Uniti negli esperimenti presso l LHC. Inoltre, molti dei gruppi di lavoro dell OSG collaborano e lavorano sull interoperabilità con l infrastruttura EGEE. La correlazione fra LCG e le risorse degli Stati Uniti avviene attraverso gli esperimenti a LHC a cui partecipano anche i ricercatori statunitensi. WLCG[10]. La Worldwide LHC Computing Grid è stata creata per preparare le infrastrutture necessarie alla simulazione e all analisi dei dati prodotti dagli esperimenti dell acceleratore LHC. Essa dipende da una stretta collaborazione con i maggiori progetti ed organizzazioni che fruiscono di fondi pubblici, per la fornitura di servizi di rete, software di Grid specializzato e per il controllo dell infrastruttura Grid. Proprio per questo, i progetti WLCG ed EGEE condividono

22 14 1 Grid una gran parte dei loro servizi operando in congiunzione e creando un sistema WLCG/EGEE Sostenibilità dell infrastruttura Grid: dallo sviluppo alle operazioni Attualmente gli stati membri e la Commissione Europea hanno progettato e stanno mettendo in atto un piano per garantire la sostenibilità a lungo termine del middleware della infrastruttura della Grid di base con l European Grid Initiative (EGI)[14]. Questa è un associazione fra un ente di coordinazione e le National Grid Initiative (NGI). Queste ultime sono delle entità nazionali legali il cui compito è quello di prendersi carico sia delle operazioni inerenti all infrastruttura Grid nei rispettivi stati, che delle richieste delle comunità scientifiche che vengono supportate. L obiettivo principale dell evoluzione di EGEE è quello di collegare fra di loro le Grid nazionali esistenti e di supportare attivamente l avvio di nuove iniziative in quegli stati dove ancora non esistono. Le attività dei progetti correnti (EGEE) vengono progressivamente trasformate in servizi di EGI: questa fase deve ancora essere completata e per poter garantire una continuità dei servizi per gli utenti della Grid europea. Alla fine della transizione l infrastruttura dovrà essere sostenibile nel lungo periodo in termini di costi e risorse e dovrà coordinare le singole iniziative dei 42 paesi europei ed extra-europei che partecipano all iniziativa. Particolare attenzione verrà prestata allo sviluppo dei sistemi middleware necessari per i servizi o erti, nonché alla validazione e standardizzazione dei software che saranno messi a disposizione da sistemi di Grid Computing (già sviluppati a livello nazionale). Il progetto prevede anche la realizzazione di specifici standard per le interfacce Grid e la promozione di questa tecnologia presso l industria, per un corretto trasferimento tecnologico. Oltre al trasferimento delle nuove tecnologie, è necessario che l attuale middleware della Grid europea venga continuamente sviluppato. Tale sviluppo continuerà anche nell ambito del progetto UMD: Unified Middleware Distribution. Questo altri non è che l unione dei tre consorzi di EGEE (ARC, glite e UNICORE) che permetterà di coordinare a livello europeo gli sviluppi che attualmente sono paralleli, evitando una duplicazione degli sforzi Da Grid a cloud computing Il passaggio ad una struttura con maggiore sostenibilità, consente anche un passaggio da Grid a Cloud Computing[15]. Questo implica che l infrastruttura Grid potrà essere vista come un insieme di servizi da mettere a disposizione agli utenti tramite un o erta

23 1.5 Architettura WLCG/EGEE 15 (commerciale) attraverso un servizio web di risorse di calcolo e storage con un ambiente virtuale creato secondo le esigenze degli utenti in un dominio amministrativo unico, così come stanno già facendo Amazon, Google o IBM. Quest approccio rende semplice e flessibile l accesso ad hardware, software e storage grazie a una nuova interfaccia web el o erta di ambienti virtuali (Worker Node on Demand 7 ). La funzionalità nei servizi Cloud può essere descritta in molti modi e dipende dai tipi di astrazione e servizi che si intende mettere a disposizione. Le astrazioni tipiche sono: Hardware as a Service (HaaS): mettere l hardware a disposizione dei clienti. Software as a Service (SaaS): fornire dei servizi software pronti per essere usati. Data as a Service (DaaS): consentire accesso ai dati disponibili da varie fonti. Queste astrazioni possono essere viste collettivamente come l o erta di una Platform as a Service (Paas), o, piú in generale, di una Infrastructure as a Service (IaaS). L infrastruttura (come IGI 8 ) potrà potenzialmente diventare un servizio che si compra e si vende facilmente via web, cosí che la Grid integrata con Cloud e virtualizzazione possa estendere l uso dell infrastruttura dalla ricerca a potenzialemente ogni utente (Pubblica Amministrazione e aziende). 1.5 Architettura WLCG/EGEE I requisiti computazionali degli esperimenti di LHC sono enormi: circa Peta- Bytes di dati saranno prodotti ogni anno. Analizzare questa mole di dati richiederà l equivalente di 70 mila computer del tipo più veloce tra quelli oggi prodotti, che per vari motivi non possono essere tutti concentrati in un solo posto. La Worldwide LHC Computing Grid viene incontro a queste necessità attraverso il dispiegamento di un servizio di calcolo Grid a livello mondiale, integrando le risorse dei centri di calcolo scientifici disseminati in Europa, America e Asia, in un organizzazione globale di calcolo virtuale Utenti e VO Le organizzazioni virtuali (VO, Virtual Organization)[16] sono un insieme dinamico, multi-istituzionale e virtuale di entità che condividono risorse. Ognuna ha una dimensione di erente e persegue un diverso scopo con una diversa durata temporale. Nell architettura WLCG/EGEE le VO sono utilizzate per fornire agli utenti di un gruppo, senza una particolare caratterizzazione geografica, la potenzialità di accedere 7 WNOD: selezione dinamica di risorse virtuali tramite Grid 8 Italian Grid Initiative: é la NGI italiana che fa parte del progetto EGI

24 16 1 Grid alla risorse di un sistema distribuito, garantendone un accesso coordinato e controllato, o rendo all utente la visibilità di un unico sistema di calcolo logico, facilmente scalabile. Ogni entità mette a disposizione della griglia computazionale un insieme di risorse locali. Ognuna di queste entità può utilizzare le risorse della griglia computazionale combinandole nel modo più opportuno per risolvere i propri problemi. Inoltre, ogni entità agisce sia da client che da server (così come avviene nella tecnologia peer to peer) Sicurezza La Grid Security Infrastructure (GSI)[17] è una specifica d autenticazione per una comunicazione segreta e protetta fra software nell ambiente Grid. Questa si basa sul concetto di chiave pubblica criptata (certificati X ) e sul protocollo di comunicazione Secure Socket Layer (SSL) 10. Dunque una generica entità della Grid (qualsiasi essa sia: utente o risorsa) necessita di un certificato digitale rilasciato da una Certification Authority (CA) 11 riconosciuta da WLCG/EGEE. Il certificato, la cui chiave privata è protetta da una password, è usato per generare e certificare un proxy certificate, che corrisponde ad un certificato temporaneo (generalmente con una durata di 24 ore) usato per l attuale autentifica all interno della Grid e che non necessita di password. Spesso i lavori che gli utenti hanno la necessità di eseguire sulla Grid hanno durate molto più lunghe -anche di molti giorni- e potrebbe accadere che le credenziali scadano prima della fine dei lavori, così che questi vengano invalidati per mancanza di autorizzazione ed eventualmente i risultati prodotti non siano accessibili. Anche per questo motivo è stato introdotto un sistema di deposito delle credenziali dell utente, permettendo la creazione e la relativa memorizzazione di un certificato proxy a lunga durata in un server dedicato. Il nome del server è MyProxy, ed il certificato contenuto in questo server viene utilizzato per rinnovare periodicamente il proxy di un utente che sta per scadere. Lo schema di autenticazione è mostrato in figura 1.2. Questo servizio oltre che a mantenere a lungo termine le credenziali degli utenti permette di avere un autenticazione unica dal punto di vista dell utente, così che ogni servizio Grid si limiti ad interrogare il MyProxy, senza che l utente debba inserire la password della chiave privata per ogni singolo servizio. Il Virtual Organization Membership Service (VOMS) è un sistema che permette di complementare un certificato con delle estensioni contenenti informazioni relative alla VO, il gruppo VO a cui appartiene l utente, e il ruolo che l utente ha all interno della VO. Nella terminologia VO, un gruppo è un sottoinsieme dell organizzazione virtuale, 9 In crittografia, X.509 è uno standard per le infrastrutture a chiave pubblica 10 SSL è un protocollo realizzato per comunicazioni cifrate su Internet 11 Certification authority è un entità che rilascia certificati digitali verso terze parti

25 1.5 Architettura WLCG/EGEE 17 MyProxy CA Utente Proxy..1 Proxy..n FIRMA DIGITALE FIRMA DIGITALE FIRMA DIGITALE FIRMA DIGITALE Figura 1.2: Autentificazione nella Grid: dalla Certification Autority al servizio MyProxy. contenente i membri che condividono responsabilità e privilegi nel progetto. I gruppi sono organizzati in modo gerarchico Elementi principali del middleware In figura 1.3 sono mostrate le interazioni fra gli elementi principali, a cui corrispondono una o più macchine dedicate, che compongono la Grid di WLCG/EGEE. Interfaccia Utente L Interfaccia Utente (UI, User Interface) è il punto d accesso alla Grid di WLCG/EGEE. Questa può essere un qualsiasi computer nel quale l utente abbia un account e il proprio certificato installato. Dall interfaccia l utente può essere autorizzato ad utilizzare le risorse della Grid, accedendo alle funzionalità o erte dall Information, Workload e Data Management Systems. Computing Element Per la terminologia Grid, un Computing Element (CE) corrisponde ad un insieme di risorse computazionali localizzate in un sito (esempio: cluster, farm computazionale). La funzionalità principale del CE è quella della gestione dei job (sottomissione, controllo, etc.). Una delle risorse facenti parte del CE sono i Worker Nodes (WN). Questo è l insieme dei nodi che formano il cluster; i WN eseguono i job e contengono gli stessi comandi e librerie installate nelle UI. Storage Element

26 18 1 Grid Lo Storage Element (SE) è un entità logica che garantisce un accesso uniforme alle risorse di memoria. Queste ultime possono essere disk server, disk array o tape disk. Gli Storage Element possono supportare di erenti tipi di protocolli ed interfacce per l accesso ai dati memorizzati. Molti dei siti WLCG/EGEE forniscono almeno uno SE. COMPONENTE FISICA USER INTERFACE INFORMATION INDEX RESOURCE BROKER STORAGE ELEMENT COMPUTING ELEMENT WORKER NODE WORKER NODE Figura 1.3: Elementi della Grid WLCG/EGEE. Resource Broker Il Resource Broker (RB), è il modulo della Grid che riceve le richieste degli utenti e interroga l Information Service per trovare le risorse adatte. Il Workload Management System (WMS) è un software che risiede nel Resource Broker. Il suo obiettivo è quello di accettare i job degli utenti, assegnarli ai più appropriati CE, registrare il loro stato e ritirarne il relativo output al termine dell esecuzione. Dunque, questa entità regola l accesso alle risorse distribuite e ettuando il processo detto di match-making. Information System L Information System (IS) fornisce informazioni circa le risorse WLCG/EGEE ed il loro stato. I sistemi di informazione attualmente utilizzati dalla Grid WLCG/EGEE sono due: il Monitoring and Discovering Service (MDS)[18] che è usato per la scoperta di risorse e per pubblicarne lo stato; il Relational Grid Monitoring Architecture (R-GMA)[19] che invece è usato per il controllo delle risorse e la loro relativa pubbli-

27 1.5 Architettura WLCG/EGEE 19 cazione ad un livello utente. Questi servizi si appoggiano a BDII (Berkeley Database Information Index), un database che serve per memorizzare lo stato delle risorse e che contiene tutte le informazioni disponibili relative a Grid Job flow: sottomissione La figura 1.4 mostra il flusso di lavoro nella sottomissione di un Job nella griglia computazionale WLCG/EGEE. Figura 1.4: Job Flow nella Grid WLCG/EGEE. I passi principali sono i seguenti: a: l utente ottiene un certificato digitale dalla Certification Authority; si registra ad una VO ed ottiene un account ad una Interfaccia Utente; da qui crea un certificato proxy che permette all utente di e ettuare operazioni; b: viene sottomesso un job dall UI al Resource Broker, specificando i files da copiare nei Worker Nodes (Input Sandbox); lo stato del job è SUBMITTED;

28 20 1 Grid c: il Workload Management System cerca il miglior Computing Element disponibile secondo le richieste specificate dall utente, interrogando il BDII; lo stato del job è WAITING; d: il RB prepara il job per la sottomissione ed invia le informazioni necessarie al CE selezionato; lo stato del job è READY; e: il CE riceve la richiesta; lo stato del job è SCHEDULED; f: il manager di risorse locale della farm invia l esecuzione del job ai WN locali e i file dell utente vengono copiati dal RB al WN dove viene eseguito il job; lo stato del job è RUNNING; g: mentre il job è in esecuzione i file possono essere letti da uno Storage Element; h: il job può produrre dei file di output nuovi; questi possono essere memorizzati negli SE ed essere acceduti da altri utenti; i: nel caso in cui l esecuzione del job termina senza errori e l output prodotto (Output Sandbox) è di dimensioni non molto grandi quest ultimo viene copiato nel Resource Broker; lo stato del job è DONE; j: ora l utente può ritirare l output del suo job nella sua User Interface; lo stato del job è CLEARED; k: le richieste per il controllo dello stato del job e delle risorse possono essere e ettuate dalla UI; l: se un sito a cui è stato inviato il job, non è in grado di accettarlo e di eseguirlo, allora il job può essere passato ad un altro CE; dopo un certo numero di risottomissioni il job viene marcato ABORTED MAGIC-5: un caso d uso della Grid MAGIC-5[20] (Medical Application on a Grid Infrastructure Connection) è una collaborazione italiana fra vari istituti INFN e ospedali il cui fine è quello di sviluppare un sistema software per applicazioni mediche, che fornisca un individuazione assistita dal computer (CAD, Computer Aided Detection) su basi di dati distribuite d immagini mediche (mammografia, TAC,... ) e la loro scansione automatizzata tramite l ausilio della tecnologia Grid. Data l enorme mole di dati da controllare e le dimensioni delle singole immagini che sconsigliano il trasferimento (vietato d altra parte da motivi di riservatezza dei dati), l uso di un sistema automatico distribuito per l analisi di immagini mediche è di grandissima importanza per i programmi di monitoraggio;

29 1.6 Flussi di lavoro complessi in ambienti distribuiti 21 alcuni esempi di applicazione sono: immagini mammografiche ai raggi-x per la diagnosi di cancro al seno, immagini per l individuazione del cancro al polmone fornite dalla Computed Tomography (CT) e immagini fornite dalla tomografia ad emissione di positroni (PET, Positron Emission Tomography), per una diagnosi precoce dell Alzheimer. Questo permette un organizzazione dei dati ed una loro analisi remota, consentendo anche una diagnosi remota interattiva. In questo caso la Grid consente anche di operare su dati remoti rispettando i limiti previsti dalla legge; infatti, secondo la tutela della privacy del paziente, non è possibile trasferire dei dati relativi ad esso, da una struttura ospedaliera ad un altra senza una burocrazia molto pesante. MAGIC-5, prevede di trasferire ed eseguire il software sul sito contenente i dati di interesse e di ricevere il risultato dell esecuzione del software su quei dati anonimizzati o meno a seconda dell applicazione. Questo, oltre a provocare una certa riduzione dei ritardi associati al processo di monitoraggio, permette un analisi più e ciente e sicura, segnalando i casi da sottoporre ad ulteriore analisi da parte di un medico. 1.6 Flussi di lavoro complessi in ambienti distribuiti I modelli computazionali definiti dalle organizzazioni o istituzioni che hanno bisogno di una grande quantità di risorse spesso necessitano dell implementazione di flussi di lavoro complessi che devono però coesistere con la richiesta di scalabilità. La Grid dá la possibilità di risolvere i problemi relativi alla scalabilità introducendo servizi e infrastrutture che permettono a ogni collaborazione di costruire applicazioni specifiche. Quest ultime implementano di erenti flussi di lavoro permettendo di dare una soluzione alla quasi totalità dei casi d uso. Soddisfare tutti i requisiti appena descritti è di cile -o forse impossibile- se s interagisce direttamente con la Grid, e la tendenza attuale è quella di andare verso il Client/Server Computing in sostituzione alle applicazioni autonome e indipendenti. L introduzione di un tale nuovo livello di servizi per le applicazioni, che si interpone fra quest ultime e il middleware della Grid, permette di soddisfare i requisiti in termini di scalabilità dell infrastruttura e funzionalità messe a disposizione degli utenti. Inoltre l utente viene isolato dalle complessità del sistema distribuito permettendo di costruire un ambiente di lavoro dinamico e modulare. Infatti le applicazioni basate sul client/server computing permettono di mettere in atto, migliorare e ottimizzare l utilizzo del middleware della Grid. In particolare la presenza di un server (o meglio: un insieme di servizi distribuiti su molteplici server) permette di: implementare dei flussi di lavoro specifici e allo stesso tempo complessi; gestire facilmente le politiche dell applicazione decise dalle relative Virtual Organization, centralizzando eventuali cambiamenti;

30 22 1 Grid sganciarsi dall infrastruttura Grid, con la possibilità per gli amministratori di gestire le esigenze della VO senza passare dalla Grid; nascondere le complessità della Grid agli utenti.

31 Capitolo 2 Client-server computing Real men don t use backups, they post their stu on a public ftp server and let the rest of the world make copies. Linus Torvalds Negli ultimi anni la crescita esponenziale del Web ha portato allo sviluppo di servizi fortemente centralizzati in netto contrasto con la natura fortemente distribuita della rete stessa così come era stata concepita. Il sistema client-server, che rappresenta il core system di molti sistemi presenti ad oggi su Internet, ha portato infatti notevoli vantaggi in termini di fruizione del servizio. Oltre che nei sistemi Internet, il sistema client-server ha trovato applicazione in tutti quei contesti in cui è necessaria una condivisione di risorse e/o una suddivisione dei lavori. Il termine client-server venne usato per la prima volta nel 1980 in riferimento ad un personal computer (PC) su una rete, evolvendo nell attuale modello solamente verso la fine degli anni 80. Tale evoluzione ha portato a considerare questo termine un concetto logico, che non dipende né dalla diversità né dalla locazione dell hardware; infatti una singola macchina può essere sia client che server a seconda della configurazione del software. La tecnologia client-server è dunque un modello per l interazione tra i processi di un software che vengono eseguiti contemporaneamente. 2.1 Definizione di client-server computing Il client-server computing viene usato per descrivere un modello architetturale per lo sviluppo di sistemi computazionali. Questo modello è basato sulla distribuzione delle funzioni fra due tipi di processi autonomi e indipendenti: il server e il client.

32 24 2 Client-server computing Un client è un qualsiasi processo che richiede uno specifico servizio al processo del server. Un server è un processo che fornisce i servizi che sono stati richiesti dal client. I due processi possono risiedere nello stesso computer o su computer diversi, a patto che questi siano connessi da una rete. Un client può richiedere servizi a più server all interno di una rete, senza preoccuparsi della posizione o delle caratteristiche fisiche del computer su cui si trova il processo del server. La rete che collega il client e il server diventa così il mezzo attraverso il quale i vari processi possono comunicare. La caratteristica principale del client-server computing è la distribuzione dei compiti e delle funzioni, potendo così concentrare la potenza di calcolo dove vengono svolte le funzioni computazionalmente più complesse (generalmente è il server). [21] Un server per ogni client Alcune tipologie di server sono: File Server È una macchina progettata per condividere file all interno di una rete. Questa mette a disposizione degli utilizzatori di una rete di computer (i client) dello spazio su un disco (disco singolo o composto da più dischi) nel quale sia possibile salvare, leggere, modificare, creare file e cartelle condivise da tutti, secondo regole o autorizzazioni che generalmente il gestore di rete organizza e gestisce. Il processo server è in un certo senso primitivo, perché per poter trovare i dati richiesti tende a esigere lo scambio di un alto numero di messaggi. Alcuni esempi di File Server sono: UNIX: Network File Services (NFS) creato da Sun Microsystems [22]. Microsoft Windows Map Drive e.g., Rivier College s P-drive. Samba: Samba è un progetto libero che fornisce servizi di condivisione di file e stampanti a client SMB/CIFS [23]. Print Server Questo tipo di server gestisce l accesso ai dispositivi di uscita condivisi, come le stampanti. Questi sono stati il primo tipo di server. Un servizio di stampa può trovarsi in un solo Print Server o su più macchine separate, che funzionano come un unico Print Server. Application Server Questa macchina gestisce l accesso ad applicazioni software centralizzate, come nel caso di un database condiviso. Quando l utente richiede delle informazioni l Application Server processa la richiesta e ritorna il risultato del processo all utente. Mail Server Questo servizio gestisce il flusso della posta elettronica, della messaggistica e della comunicazione nei sistemi a larga scala, come con sistemi di tipo

33 2.1 Definizione di client-server computing 25 Mainframe. Fax Server Fornisce la struttura per inviare e ricevere i fax attraverso una singola connessione di rete telematica. Il Fax Server può essere costituito da una stazione di lavoro con una scheda che permette d interfacciarsi al Fax e da un software gestionale specifico, oppure può essere semplicemente costituito da un dispositivo specializzato dedicato e progettato per servizi Fax. Questa macchina gestisce il flusso delle informazioni del Fax da e per la rete (simile al Mail Server). Directory Services Server Sistema tipico negli ambienti a larga scala in cui i dati sono distribuiti attraverso più server. I servizi di directory forniscono uno strato di astrazione tra le risorse e gli utenti, organizzando e memorizzando le informazioni su reti di computer e su risorse condivise disponibili tramite la rete. Il servizio di directory fornisce anche un controllo degli accessi sull utilizzo delle risorse condivise in modo da favorire il lavoro dell amministratore di sistema. Web Server Sistema che memorizza e recupera dati da Internet o dall intranet. Tipicamente ci sono dei client leggeri, come i browser web, che consentono di richiedere una pagina web (spesso scritta in HTML), messa a disposizione dal server. Le informazioni inviate dal server web viaggiano in rete trasportate dal protocollo HTTP (Hyper Text Transfer Protocol). L insieme di server web dà vita al World Wide Web, uno dei servizi più utilizzati di Internet. Normalmente un server web risiede su sistemi dedicati ma può essere eseguito su computer ove risiedano altri server o che vengano utilizzati anche per altri scopi. Web Application Server È un software che fornisce l infrastruttura e le funzionalità di supporto, sviluppo ed esecuzione di applicazioni e componenti server in un contesto distribuito orientato per il web. Si tratta di un complesso di servizi per la realizzazione di applicazioni multilivello ed enterprise, con alto grado di complessità. Alcuni esempi di Web Application Server sono: Internet Information Server (IIS) di Microsoft, iplanet della Netscape, WebSphere della IBM, WebLogic di BEA and Oracle Application Server. Database Server Un server di basi di dati è un servizio che fornisce l accesso ai dati organizzati all interno del database localizzato sul server. Questo si occupa di fornire i servizi di utilizzo del database ad altri programmi e ad altri computer secondo la modalità client-server. Il server memorizza i dati, riceve le richieste dei client ed elabora le risposte appropriate. I Database Server sono complessi sistemi software

34 26 2 Client-server computing concepiti, oltre che per memorizzare i dati, anche per fornire un accesso rapido ed e cace ad una pluralità di utenti contemporaneamente e garantire protezione sia dai guasti che dagli accessi indebiti. Un esempio di Database Server è: Oracle9i[24] Caratterizzazione Le caratteristiche in base alle quali possiamo classificare i sistemi client-server sono principalmente due: il tipo di distribuzione dei servizi fra le due entità che permette di definire i concetti di Fat Client e Fat Server. la capacità del server di avere transazioni indipendenti da ogni precedente interazione o meno, cioè di avere un server con o senza stati. Client-server: massiccio o snello (fat or thin). Un entità è chiamata client o server a seconda di quale sia il livello di condivisione delle operazioni fra di essi. Un client snello (thin) è un client che esegue direttamente solo un minimo dell elaborazione, mentre uno massiccio (fat) si fa carico di una proporzione dell elaborazione decisamente più amplia. Il criterio di definizione del concetto di Fat Client o Fat Server è dato dal criterio di quanto un applicazione sia sul client o sul server. Fat Client: vengono utilizzati nei tradizionali modelli di client-server computing; spesso la loro introduzione comporta problemi non indi erenti dal punto di vista della manutenzione o dell assistenza. Un esempio ne sono le applicazioni Web 2.0 come Google Mail che presenta un interfaccia ricca (scritta in Ajax) ad un sistema di posta elettronica. Fat Server: il server contiene la logica del sistema, mettendo a disposizione un livello di servizi astratto. Il vantaggio più grande nell usare un server - massiccio è dovuto al fatto che la gestione è più semplice, perché, in caso di una qualsiasi modifica al software del server è su ciente intervenire solamente sul server, invece che andare a modificare tutti i client che sono potenzialmente disponibili. Le tendenze attuali privilegiano questo tipo di sistema, dove sempre più spesso il client leggero corrisponde a un browser web. Client-server: con o senza stati stateless or stateful Un server senza stati (Stateless Server) è un server che tratta ogni richiesta come una transazione indipendente scorrelata da ogni precedente richiesta [25]. Il vantaggio più grande di questa proprietà è che semplifica di molto la progettazione del server, perché esso non ha bisogno nè di tenere in relazione transazioni diverse, nè di allocare dinamicamente

35 2.1 Definizione di client-server computing 27 un area di memoria dedicata o di preoccuparsi di liberare lo spazio allocato se il client s interrompe nel mezzo della transazione. Ovviamente ci sono anche degli svantaggi, quali: dover includere un quantitativo di informazioni maggiore per ogni richiesta; il server deve ogni volta interpretare tutte le informazioni. Un esempio di un server senza stati è un server del World Wide Web (fatta eccezione dei cookies 1 ): questi prendono come input la richiesta (URL) che specifica completamente il documento richiesto e non hanno bisogno di nessun contesto particolare o memoria allocata durante una precedente richiesta. Questo tipo di server contrasta con un tradizionale server FTP[26], che gestisce una sessione interattiva con l utente. Nel caso di una richiesta per un file che si trova sul server FTP, si assume che l utente si sia precedentemente autenticato e che la directory corrente e la modalità di trasferimento del file siano già state definite. Un server con stati (Stateful Server) ha una tabella che permette di registrare in modo incrementale le informazioni e lo stato delle interazioni in corso con i client, incluse le risposte ad ogni richiesta, in modo che il server possa tener traccia di tutte le richieste e ettuate dal client. Il vantaggio di un server con stati è che i messaggi scambiati sono di dimensioni minori e che sono trattati in modo più e ciente. Alcuni svantaggi sono invece dovuti ai possibili problemi che il client incontra: nel caso in cui questo incorra in interruzioni ripetute e frequenti, la grande quantità di informazioni che devono essere gestite dal server possono peggiorare le prestazioni di quest ultimo. L esempio migliore di un server con stati è un File Server remoto. Stateless vs Stateful Server. Confrontando da un punto di vista analitico i server con e senza stati possiamo notare che: Un server con stati tiene traccia dei dati del client (dati) fra una richiesta e la successiva. Un server senza stati non mantiene nessuna informazione sullo stato; ad esempio, usando un File Server che non mantenga gli stati, per ogni richiesta il client devrebbe indicare il nome completo del file, specificando dove leggere e scrivere, riautenticandosi ad ogni richiesta. 1 IcookieHTTP(piùcomunementedenominatiWebcookies,trackingcookiesosemplicemente cookie) sono frammenti di testo inviati da un server ad un Web client (di solito un browser) e poi rimandati indietro dal client al server - senza subire modifiche - ogni volta che il client accede allo stesso server. I cookie HTTP sono usati per eseguire autenticazioni e tracking di sessioni e memorizzare informazioni specifiche riguardanti gli utenti che accedono al server.

36 28 2 Client-server computing Usando un File Server con stati il client può inviare meno informazioni per ogni richiesta, diventando così il modello più semplice. D altro canto, un server senza stati è più robusto e ad esempio: le connessioni perse non lasciano un file in uno stato invalido; riavviando il server non viene persa nessuna informazione; un riavvio del client non causa nessuna confusione in un server senza stati Funzioni del client Le operazioni principali dei sistemi client sono: Gestione dell interfaccia utente. Controllo della sintassi degli input degli utenti. Gestione della logica dell applicazione. Generazione delle richieste per le operazioni da eseguire e loro trasmissione al server. Gestione della comunicazione con il server Funzioni del server Le operazioni principali che sono svolte dal server sono: Accettazione e trattamento delle richieste ricevute dal client. Controllo dell autorizzazione. Garanzia di preservare l integrità. Esecuzione delle operazioni necessarie e trasmissione delle risposte al client. Manutenzione di un catalogo/tabella del sistema. Capacità di uso concorrente tra più client (multiclient). Ripristino del sistema in caso di fallimento.

37 2.1 Definizione di client-server computing Modelli strutturali Quando si parla di topologia nei sistemi client-server ci si riferisce alla disposizione e alla struttura fisica della rete client-server, in cui tutti i client e tutti i server sono connessi gli uni con gli altri, includendo tutte le stazioni di lavoro. I diversi schemi di topologie e strategie usate sono i seguenti [27]: Unico client, unico server: in questa topologia un unico client è connesso al server come mostrato in figura 2.1. Più client, unico server: i client sono multipli e sono connessi ad un unico server, figura 2.2. Più client, più server: i client sono multipli e sono connessi a molteplici server, figura 2.3. Server Client Figura 2.1: Topologia client-server con un server per un unico client. Server Client Client Client Client Client Figura 2.2: Topologia client-server con un solo server per client multipli. La struttura dei due casi in figura 2.2 e 2.2 è tale da introdurre il problema legato alla presenza di un unico server, infatti nel caso di non disponibilità di quest ultimo i servizi non sono più accessibili. Questo problema è conosciuto come Single Point of Failure. L indisponibilità di tale servizio può essere legata a un attacco maligno, un problema di rete o la semplice manutenzione del server. La soluzione ridondante mostrata in figura 2.3 permette di avere un servizio più stabile dal punto di vista della disponibilità, in quanto è basata su server multipli. Questi introducono la capacità di

38 30 2 Client-server computing Server Server Server Server Server Client Client Client Client Client Figura 2.3: Topologia client-server con più server e più client. cambiare server quando quello precedentemente contattato è terminato inaspettatamente o non è stato proprio possibile contrattarlo (failover). Tale tecnica avviene in modo trasparente senza l intervento umano e senza nessun avvertimento. [28] Integrazione con il calcolo distribuito Una caratteristica tipica del calcolo distribuito è quella di avere delle tecnologie implementate attraverso ambienti eterogenei Nel caso dei sistemi eterogenei, questo implica la capacità di comunicare con altri sistemi e protocolli. Il calcolo distribuito ha un architettura complessa, che implica la progettazione delle applicazioni e lo sviluppo dei sistemi in una nuova ottica, andando ad aumentare l e cienza di manutenzione della rete nel suo insieme. Molte entità distribuite lavorano per conto di un client che e ettua una richiesta e proprio la presenza di più server fa si che il sistema sia in grado di tollerare gli errori (fault tolerant), il che è un vantaggio enorme rispetto ai sistemi centralizzati. Per far sì che il calcolo distribuito diventi e cace e di fatto rivoluzionario, gli sviluppatori delle applicazioni distribuite devono fare tutto il possibile per minimizzare la complessità delle architetture e della manutenzione, integrando i vari software con le varie piattaforme. La progettazione di applicazioni basate su di un architettura di tipo client-server necessita della modularizzazione delle applicazioni e delle relative funzioni in componenti discrete. Queste componenti devono essere legate solamente da dati incapsulati e funzioni che possono essere spostate da un sistema ad un altro. Questo modello di progettazione dà ai software basati sull architettura client-server una maggiore adattabilità e flessibilità.

39 2.2 Classificazione dei sistemi client-server in base alla topologia Classificazione dei sistemi client-server in base alla topologia Esistono tre tipi di sistemi client-server [25]: Due livelli (Two-tiers). Tre livelli (Three-tiers). N-livelli (N-tiers) Modello a due livelli (two-tiers) I due livelli di un applicazione basata su questo tipo di sistema sono generalmente collegati dalla rete, ma in alcuni casi entrambi i livelli possono essere presenti sulla stessa macchina. La tendenza è quella di centralizzare la logica dell applicazione sul server, rendendo la manutenzione del codice più semplice. L architettura client-server è per definizione composta da almeno due livelli, dove il client è il primo livello mentre il secondo livello è costituito dal server. Il client richiede i servizi al server, comunicando direttamente con esso senza nessun altra entità intermedia. Un illustrazione del modello a due livelli è mostrata in figura 2.4. CLIENT APPLICAZIONE LIBRERIE INTERFACCIA DI RETE INTERFACCIA DI RETE LIBRERIE APPLICAZIONE SERVER Figura 2.4: Modello client-server su due livelli. Un esempio tipico di applicazione che implementa questo modello è il Database

40 32 2 Client-server computing Server, in cui le richieste (query SQL) vengono fatte dall applicazione e poi processate dal database per l esecuzione. I risultati vengono quindi mandati indietro attraverso lo stesso meccanismo, ma nella direzione opposta. I sistemi a due livelli presentano vari vantaggi: Permettono di avere un applicazione con un interfaccia grafica più accattivante, rispetto a quanto fosse possibile con le precedenti tecnologie. L implementazione è più veloce e meno complicata rispetto ai sistemi con un numero maggiore di livelli. O rono la possibilità di una gestione semplice e flessibile. La disponibilità di strumenti ben integrati come quelli messi a disposizione dai produttori di DBMS. Contrariamente vi sono alcuni svantaggi con le architetture su due livelli: Lo sviluppo dell applicazione dev essere portato avanti anche lato client, la manutenzione del client è di conseguenza costosa; infatti in un architettura a due livelli il client è generalmente fat client; Maggiore carico della rete: poiché l elaborazione dei dati avviene sul client, i dati devono essere trasportati nella rete, portando uno stress maggiore alla rete. La procedura di distribuzione del software per il modello in questione è complicata. Siccome la logica dell applicazione si trova anche lato client, tutte le macchine che ne ospitano uno devono essere aggiornate in caso di una nuova release. Questa procedura oltre che essere complicata, costosa e soggetta ad errori, porta via molto tempo. Le macchine client sono considerate deboli in termini di sicurezza e sono relativamente facili da corrompere. Le librerie necessarie all esecuzione dell applicazione devono essere caricate sul client. L architettura su due livelli causa problemi quando è implementata su Internet Modello a tre livelli (three-tiers) Più la logica dell applicazione è distribuita fra i vari livelli dell architettura più diventa di cile raggiungere un buon livello di riusabilità. Per evitare di includere la logica dell applicazione sia a livello del server che lato client, un terzo livello software può

41 2.2 Classificazione dei sistemi client-server in base alla topologia 33 essere inserito nel mezzo. In questo caso si parla di un architettura a tre livelli (threetiers), dove la maggior parte della logica si trova nel livello intermedio e dove ogni livello corrisponde ad un servizio che viene messo a disposizione dal sistema. Con questo tipo di struttura quando è necessario cambiare la logica dell applicazione è su ciente modificare solo il livello intermedio. Ogni livello architetturale può essere associato ad un specifica categoria logica: Rappresentazione (GUI) dei servizi per l utente: include la manutenzione dell interfaccia grafica per l utente e la presentazione di ció che gli utenti vedono sul monitor. Servizi dell applicazione e della logica: includono l esecuzione di applicazioni e il flusso del programma di controllo, cioè la logica che si occupa della convalida dei dati e delle richieste/risposte nella comunicazione fra i processi dei vari livelli. Core server: si riferisce al server che esegue e ettivamente le richieste e che eventualmente gestisce la base di dati sottostante. In questo caso la logica del server interagisce con la gestione, l accesso e la sicurezza dei dati. Sulla base di queste tre categorie logiche, i tre livelli dell architettura del sistema client-server sono mostrati in figura 2.5. PROXY SERVER LIBRERIE APPLICAZIONE INTERFACCIA DI RETE INTERFACCIA DI RETE INTERFACCIA DI RETE LIBRERIE LIBRERIE APPLICAZIONE APPLICAZIONE CLIENT SERVER Figura 2.5: Modello client-server su tre livelli. Il server del livello intermedio funziona come un proxy per tutte le richieste che vengono dai client, inoltrandole al Core server e restituendo il risultato al client dopo che la richiesta è stata processata. Oltre a funzionare come un livello intermedio, il

42 34 2 Client-server computing proxy server coordina l esecuzione dei lavori sul Core server. Quest architettura permette di creare un ambiente di lavoro più sicuro per il server che svolge le richieste. Ma anche per questo modello ci sono un paio di inconvenienti: la necessità di avere un piccolo processo (listener) all interno del server intermedio; tutte le richieste del client devono essere trasmesse in una rete tramite un protocollo ben definito. I confini fra i vari livelli sono di tipo logico. Primo livello (client). La responsabilità principale di questo livello è quella di ricevere gli eventi degli utenti, controllare l interfaccia utente e rappresentare i dati sull interfaccia. Poiché con questa architettura la maggior parte del software è rimosso dal client, questo è sottile (thin). Secondo livello (application/proxy server). La parte complessa della logica dell applicazione è all interno di questo livello ed è disponibile per il livello client, quando questo la richiede. Tale livello costituisce l entità centrale per la soluzione dei problemi presenti nel modello a due livelli, anche proteggendo l accesso diretto di dati. Terzo livello (core server). Questo livello è responsabile della memorizzazione dei dati, spesso tramite un File Server e un gestore di basi di dati. I livelli sopra elencati possono essere eseguiti tutti in un unica e medesima macchina, in quanto è importante che il sistema sia ben strutturato e che la progettazione dei confini fra i vari software esistenti nei diversi livelli sia ben definita. Alcuni dei vantaggi derivanti dall utilizzo del modello a tre livelli includono: La manutenzione delle applicazioni è centralizzata perché la logica necessaria agli utenti finali è nel server intermedio. Ciò permette di eliminare una delle problematiche più importanti che è presente nel modello tradizionale a due livelli: la distribuzione del software. Attraverso la separazione netta fra l interfaccia utente, il controllo e la presentazione dei dati dalla parte logica dell applicazione più client possono accedere ad una vasta gamma di applicazioni messe a disposizione dal server. I vantaggi principali per le applicazioni client sono due: uno sviluppo più rapido grazie al riutilizzo delle componenti logiche già esistenti ed una fase di test più breve, in quanto le componenti del server sono già state testate a parte.

43 2.2 Classificazione dei sistemi client-server in base alla topologia 35 Molti utenti sono in grado di accedere ad una vasta gamma di applicazioni server, proprio perché tutte le applicazioni logiche sono messe a disposizione sul server del terzo livello. Di regola i server sono sistemi fidati (trusted) e l autorizzazione è più semplice rispetto a quella di numerosi client non attendibili, così che la protezione e la sicurezza dei dati sono più semplici da ottenere. Pertanto, questo sistema ha senso anche per l esecuzione di tutti quei processi critici in cui la sicurezza dei dati sensibili sul server è uno dei punti chiave. La ridefinizione delle strategie di memorizzazione non influenza i client. Nei sistemi ben progettati, il client accede ai dati attraverso un interfaccia stabile che incapsula tutti i dettagli della memorizzazione. Il bilanciamento del carico è più facile grazie alla separazione della logica dell applicazione dal Core server. Il bilanciamento dinamico del carico: nel caso in cui vi siano dei colli di bottiglia in termini di prestazioni il processo del server può essere trasferito ad altri server in fase di esecuzione. La necessità di avere un hardware meno costoso per quanto riguarda il client (thin). La gestione di un qualsiasi cambiamento nella logica è più facile e più veloce da eseguire, perché la componente logica è implementata sul server, quindi in un unico posto piuttosto che su numerosi client. La modularità dei vari livelli rende più facile modificare o sostituire un livello senza che vengano interessati gli altri livelli. I client non hanno bisogno di avere le librerie native caricate a livello locale, ma queste possono essere gestite centralmente. Il server principale può non essere direttamente visibile a Internet. Un ulteriore vantaggio dell architettura a tre livelli è che mappa in modo del tutto naturale il Web, con un browser Web che agisce come thin client eunserverwebche agisce come application server. Alcuni svantaggi di questo modello invece sono: Il client non mantiene una connessione persistente e diretta al server principale (come nel caso di un Database Server). Può essere necessario un proxy server separato.

44 36 2 Client-server computing Nel caso in cui venga utilizzato un proxy server separato puó venire generato un tra co di rete maggiore. Il protocolli di rete utilizzati possono essere protocolli proprietari. L architettura a tre livelli può essere facilmente estesa a N livelli, con dei livelli aggiuntivi necessari a fornire una maggiore flessibilità e scalabilità. Ad esempio, il livello intermedio del modello a tre livelli potrebbe essere diviso in due, con un livello per il server Web e un altro per il server delle applicazioni. Architettura a tre livelli e Internet. Con il rapido sviluppo di Internet e delle tecnologie Web, le applicazioni clientserver in esecuzione su Internet e intranet stanno diventando un nuovo tipo di calcolo distribuito. Una tipica applicazione web utilizza la seguente architettura su tre livelli. L interfaccia utente viene eseguita sul desktop come client. Il client è collegato (attraverso uno o più collegamenti immediati al server) ad un Web server, che può essere un magazzino per delle applicazioni scaricabili (le componenti software). Il server web è, a sua volta, sostenuto da un Database Server che tiene traccia delle informazioni specifiche per l interesse del client e la relativa storia. Queste applicazioni web si basano su standard di Internet (HTTP, HTML, XML, ecc) Modello a N livelli (N-tiers) Nel modello computazionale a N livelli gli sviluppatori sono obbligati a progettare le componenti secondo un ben preciso schema che rappresenti le entità, i rapporti, le attività e le regole, per una distribuzione ottimale delle funzioni tra livelli logici e fisici, consentendo un migliore utilizzo delle piattaforma hardware e delle risorse condivise. Un altro aspetto della suddivisione su N livelli è che sia gli sviluppatori di applicazioni che gli amministratori sono in grado di identificare i colli di bottiglia e quindi: aggiungere più hardware dove necessario, permettendo un bilanciamento migliore del carico; duplicare i servizi per avere una disponibiltà continua in caso di fallimento (failover). La suddivisione può essere e ettuata fra la logica delle componenti dell applicazione, la sicurezza logica e la logica di presentazione, il calcolo ad alta intensità e le componenti con un alto I/O e così via. Nella progettazione di un sistema con questa

45 2.3 Client-server: vantaggi e svantaggi 37 topologia l approccio che viene più comunemente utilizzato è quello con un architettura su tre livelli. I modelli su tre o N livelli sono simili, se non per il fatto che quello su quest ultimo permette di definire un maggior scomposizione e quindi modularitá dei servizi. Perció, per la distribuzione dei servizi di alcuni sistemi spesso si opta per una struttura con ben più di tre livelli, infatti un infrastruttura che supporta tre livelli è spesso composta da svariate macchine e servizi, le cui funzionalità non fanno parte della progettazione. In figura 2.6 è illustrata l architettura N-tier. Server 1 Server 2 CLIENT Server 3 Server X Server N-2 SERVER N Figura 2.6: Modello client-server su N livelli. Un sistema client-server su N livelli o re numerosi vantaggi rispetto ai modelli tradizionali su uno o due livelli, fra cui: migliori prestazioni complessive; logica dell applicazione centralizzata; raggiunto un livello di protezione nettamente più avanzato. 2.3 Client-server: vantaggi e svantaggi Vantaggi Ci sono diversi vantaggi associabili al modello di client-server computing: Prestazioni e carico di lavoro ridotto: l elaborazione è ripartita tra il client e il server, quindi le prestazioni dell applicazione non sono legate principalmente alle caratteristiche della postazione di lavoro (desktop); questa deve essere solamente in grado di eseguire il software del client (aumentando la durata dei vecchi PC, da un punto di vista dell utilità nel tempo). Di conseguenza c è anche l e etto di riduzione del carico sulla rete che collega la stazione di lavoro al server, che invece di inviare tutte le richieste del client avanti e indietro, si limita a inviare solo le domande e le risposte dal server dell applicazione.

46 38 2 Client-server computing Indipendenza dalla stazione di lavoro: gli utenti non sono limitati a un solo tipo di sistema o piattaforma, in quanto è possibile avere sistemi compatibili con tutte o quasi le stazioni di lavoro (in base al tipo e alla versione del sistema operativo), in modo del tutto trasparente. Interoperabilità dei sistemi: il modello client-server, non permette solo di cambiare in modo del tutto trasparente una componente, ma dà anche la possibilità alle diverse componenti o sistemi (client, rete o server) di lavorare assieme. Scalabilità: la natura modulare del sistema client-server permette sostituzioni senza danneggiare il resto del sistema. Per esempio, è possibile aggiornare il server ad una macchina più potente, senza cambiamenti visibili all utente. Questa capacità di cambiare le componenti del sistema rende il modello client-server particolarmente aperto all introduzione di nuove tecnologie, sia hardware che software. Integrità dei dati: è preservata, in quanto il server può usufruire e fornire un numero di servizi che proteggano i dati come, l archiviazione crittografata dei file, il backup in tempo reale (mentre i dati stanno venendo elaborati), il mirroring del disco (dove i dati sono automaticamente duplicati su un altra partizione dello stesso disco fisso), la duplicazione dei dati (i dati vengono automaticamente scritti su un disco rigido diverso), l elaborazione delle transazioni che consente di tenere traccia delle modifiche apportate ai dati e di correggere eventuali problemi che possono sorgere (ad esempio in caso di crash del server). Accessibilità dei dati: poiché il server detiene la maggior parte dei dati in una posizione centralizzata, più utenti possono accedere e lavorare simultaneamente sui dati garantendone una maggiore condivisione. Amministrazione del sistema: l ambiente client-server é particolarmente maneggevole, favorendo una gestione centralizzata del sistema. Inoltre, poiché i dati sono centralizzati, la gestione di questi può anch essa essere centralizzata. Alcune delle funzioni di amministrazione del sistema sono relative alla gestione della sicurezza, dell integrità dei dati e il recupero del sistema in caso di fallimenti. Servizi integrati: tutte le informazioni che il client ha il diritto di utilizzare sono disponibili sulla propria stazione di lavoro, tramite l interfaccia, così che non vi sia la necessità di modificare le modalità di accesso diretto alle informazioni. Mascheramento dell accesso fisico ai dati: l accesso ai dati memorizzati in un punto qualsiasi della rete, dal PC locale, al server locale o anche al server su

47 2.3 Client-server: vantaggi e svantaggi 39 WAN, avviene utilizzando lo stesso tipo di richiesta dei dati. L unica di erenza può essere dovuta ad una riduzione delle prestazioni, ad esempio se la larghezza di banda della rete è insu ciente. Indipendenza dal luogo di trattamento dei dati: gli utenti accedono tramite una stazione di lavoro senza nessuna preoccupazione riguardante l ubicazione o la tecnologia dei processori coinvolti. Con un sistema utente centrico il desktop fornisce il punto di accesso al sistema (ed eventualmente al gruppo di lavoro, servizi aziendali inclusi), senza nessun legame con la piattaforma di esecuzione dell applicazione. Costi operativi ridotti: il costo dell hardware e del software è in continua discesa, il che significa che il valore di calcolo è in continuo aumento. Il modello client-server o re un modo per sfruttare questo andamento, sostituendo i sistemi di grandi dimensioni spesso molto costosi, con quelli meno costosi e più piccoli ma collegati in rete. Costo dell hardware ridotto: il costo dell hardware può essere ridotto, in quanto è solo il server che richiede lo spazio e la potenza di elaborazione su - ciente per memorizzare e gestire l applicazione. Costi di comunicazione sono ridotti: l applicazione svolge parte delle operazioni lato client, inviando solo una richiesta per l accesso ai servizi del server attraverso la rete, quindi una minore quantità di dati passa attraverso la rete Svantaggi Pure gli svantaggi connessi all uso del modello computazionale client-server sono diversi: Costi di manutenzione: il principale svantaggio di questo modello è dato dall aumento del costo del personale amministrativo e di sostegno per mantenere il server. In genere l amministratore di rete può prendersi carico anche della gestione e manutenzione del server, di controllare l accesso degli utenti ad esso e di supportare le relative applicazioni. Tuttavia, quando il numero degli utenti del server aumenta, o non appena aumenta la quantità di informazioni gestite dal server stesso, diviene necessario assumere un amministratore del server. Costo della formazione: la formazione può comportare dei costi aggiuntivi, in quanto il personale d amministrazione deve acquisire familiarità con il sistema operativo e l applicazione, specialmente lato server.

48 40 2 Client-server computing Costo dell hardware: quando si vuole avere un server con delle buone prestazioni e un integrità dei dati ottima si verifica un aumento dei costi dell hardware, dovuto all acquisto di hardware ad alta potenza (grande quantità di RAM, spazio su disco rigido,...). Costo del software: il costo complessivo del software è generalmente superiore a quello dei PC tradizionali. Complessità: le componenti che costituiscono l intero sistema client-server possono essere molte, e, più sono le componenti, più sono le cose che possono andare storte, rendendo più di cile individuare la sorgente del problema quando si verificano degli errori o, ancora peggio, quando il sistema si blocca. 2.4 Sviluppo di un sistema client-server Lo sviluppo nel caso di sistemi client-server è un processo molto diverso dai tradizionali metodi di sviluppo dei sistemi informativi. Ad esempio, l approccio nel caso dello sviluppo di sistemi orientati verso un ambiente centralizzato come quello mainframe e basato sui tradizionali linguaggi di programmazione che di cilmente può essere usato per poter ottenere uno sviluppo ottimale di un sistema client-server che si basa sulla diversità di hardware e software fra le entità coinvolte. Inoltre, gli utenti moderni sono più esigenti e hanno una conoscenza migliore della tecnologia informatica rispetto agli utenti che usavano il PC quando questo è comparso. [29] Strumenti di sviluppo In un contesto in rapida e continua evoluzione come quello attuale, una delle decisioni più critiche per lo sviluppo di un applicazione client-server è la scelta degli strumenti più adeguati al problema. Come regola generale, i manager tendono a scegliere uno strumento che abbia un potenziale di sopravvivenza a lungo termine. Tuttavia, la scelta di uno strumento per la progettazione o lo sviluppo di applicazioni deve essere guidato dalle esigenze di sviluppo del sistema. Una volta che tali requisiti siano stati definiti, è opportuno determinare le caratteristiche dello strumento che si vorrebbe avere. Gli strumenti per lo sviluppo client-server includono: Interfaccia grafica (GUI ) per lo sviluppo. Costruttore d interfacce grafiche per le applicazioni. Sviluppo orientato agli oggetti, utilizzando un repository centrale per i dati e le applicazioni.

49 2.5 Software Development Life Cycle 41 Supporto per database multipli (gerarchici, in rete, relazionali). Accesso ai dati indipendentemente dal modello di dati. Definizione di un SDLC (System Development Life Cycle) completo che serva come supporto dalla progettazione, all implementazione e alla manutenzione del progetto. Gruppo di sviluppo e di supporto. Supporto per gli strumenti di sviluppo appartenenti a terze parti (es: librerie) Supporto per piattaforme multiple (sistema operativo, hardware e GUI). Supporto del protocollo di rete (TCP / IP, IXP / SPX, NetBIOS, e così via). Non è possibile definire quale sia la scelta migliore per ogni singolo strumento necessario allo sviluppo delle applicazioni, ad esempio non tutti gli strumenti supporteranno tutte le GUI, i sistemi operativi, i middleware o i database. I manager del progetto devono scegliere uno strumento che si adatti sia alle esigenze di sviluppo delle applicazioni sia che corrisponda alle risorse umane disponibili, nonché all infrastruttura hardware. È probabile che il sistema richiederà più strumenti di quanti ne siano e ettivamente utili, assicurarandosi che tutti o la maggior parte dei requisiti siano soddisfatti. Individuare gli strumenti di sviluppo è solo il primo passo, mentre fare in modo che il sistema soddisfi i suoi obiettivi a livello di client, server, e di rete è un altro problema. 2.5 Software Development Life Cycle Nell ingegneria del software il System Development Life Cycle (SDLC) è il processo di creare o alterare i sistemi, e consiste nell insieme di modelli e metodologie usati specialmente nell ingegneria del software per il loro sviluppo. Queste metodologie costituiscono il framework per pianificare e controllare la creazione di un sistema informativo: il processo di sviluppo software. Il SDLC aderisce alle fasi importanti che sono essenziali per gli sviluppatori, come la pianificazione, l analisi, la progettazione e l implementazione e ne esistono svariati modelli. Storicamente il piú antico è quello a cascata: una sequenza di fasi nelle quali l output di ogni fase è l input della successiva. Generalmente queste fasi seguono sempre quelle di base, ma molte metodologie a cascata danno diversi nomi alle fasi e il numero di queste puó variare da 4 a 7. Comunque, non si puó parlare di un modello SDLC definitivamente corretto, in quanto ogni fase puó essere caratterizzata e suddivisa in varie fasi.

50 42 2 Client-server computing Nel modello a cascata (waterfall model) ogni fase è costruita sovrapponendone una sull altra, prendendo l output della fase precedente, aggiungendo ulteriore lavoro e producendo dei risultati che sono influenzati da quelle precedenti. Questo tipo di approccio top-down serve per soddisfare le intenzioni originarie mantenendo la qualitá del prodotto. Nei prossimi paragrafi sono descritte le fasi principali, quelle che possiamo considerare essere la base di uno sviluppo, cosí come sono mostrate in figura 2.7. PLANNING REQUISITI (definizione) DESIGN SVILUPPO TEST (integrazione) INSTALLAZIONE Figura 2.7: SDLC: fasi base Pianificazione La fase di pianificazione stabilisce una vista ad ampio spettro di quello che sará il software finale, usandola per definire la struttura base del progetto, valutare la fattibilitá e i rischi associati ad esso, descrivendo una gestione appropriata e gli approcci piú tecnici. La parte piú critica di questa fase è la definizione ad alto livello dei requisiti del prodotto, soprattutto riferito ai suoi obiettivi, mentre tutti i requisiti del software devono essere definiti nella fase relativa. L output di questa fase consiste dei piani di configurazione della gestione, un piano di assicurazione della qualitá e il piano del progetto con il relativo programma di lavoro che include le attivitá per la fase successiva Definizione dei requisiti Questo processo prende in input gli obiettivi identificati nella sezione dei requisiti ad alto livello della fase di pianificazione. Ogni obiettivo viene quindi ra nato in un insieme di uno o piú requisiti. Questi requisiti definiscono:

51 2.5 Software Development Life Cycle 43 le funzioni principali dell applicazione desiderata, le aree dati operative, entitá dati iniziali. Questa fase consiste nel ripartire il sistema in parti di erenti e disegnare un diagramma per un analisi dettagliata. Analizzare gli obiettivi del progetto, ripartire le funzionalitá che devono essere create e coinvolgere gli utenti cosí che possano essere definiti dei requisiti definitivi. L output di questa fase è costituito da un documento contenente la lista dei requisiti e da un piano di lavoro aggiornato Progettazione Questa fase ha in input i requisiti definiti nella precedente. Per ogni requisito identificato, viene prodotto un insieme di uno o piú elementi. Gli elementi di progettazione descrivono le funzionalitá desiderate nel software e generalmente includono diagrammi, tabelle con regole e anche pseudocodice. Questi elementi di progettazione hanno il fine di descrivere il software abbastanza in dettaglio da consentire ad un programmatore esperto di poterlo sviluppare con poche altre informazioni in piú. L output della fase sono i documenti di progettazione e l aggiornamento dei requisiti e del piano di lavoro Sviluppo La fase di sviluppo prende in input gli elementi prodotti dalla fase di progettazione. Per ogni elemento, un insieme di uno o piú implementazioni software vengono prodotte. Dunque, in questa fase viene e ettivamente scritto il codice di programmazione dei vari sottosistemi. Inoltre gli sviluppatori e ettuano i controlli necessari sui singoli elementi (unit testing) esuimoduliinteri. L output di questa fase include un insieme completo di software che soddisfa i requisiti e gli elementi di progettazione precedentemente documentati, un sistema di supporto che descrive le operazioni del software (online help), un piano di test che descrive i vari casi in cui validare la correttezza e la completezza del software. Inoltre vengono aggiornati i requisiti e il piano di lavoro Integrazione e test Durante questa fase, le implementazioni software, l online help e i dati per il test vengono migrati dall ambiente di sviluppo ad un altro ambiente analogo, necessario per la fase di test. Quindi, tutti i casi di test vengono eseguiti per verificare la correttezza e

52 44 2 Client-server computing la completezza del software. Successivamente l esecuzione della suite di test conferma la robustezza e la completezza delle potenzialitá di migrazione. Inoltre, i dati vengono preparati per un uso in produzione, vengono identificati gli utenti e collegati ai ruoli a loro appropriati. L output della fase di integrazione e di test include l insieme dei software opportunamente integrato, un sistema di aiuto online, un mappa d implementazione, un piano di messa in produzione che descrive i dati e gli utenti Installazione Nella fase d installazione, le implementazioni software, l online help e i dati iniziali sono caricati nel server di produzione (deployment). A questo punto tutti i casi di test per verificare la correttezza e la completezza del software sono stati eseguiti. Successivamente i test vengono nuovamente eseguiti per validare il sistema e come prerequisito per l accettazione del software da parte del destinatario. L output di questa fase include un applicazione in produzione e una test di suite completa. 2.6 Client-server: sicurezza Una minaccia per la sicurezza è definita come la circostanza, la condizione, o un evento che abbia la possibilità di causare qualche tipo di di coltà distruttiva a dati o risorse di rete. La divulgazione di dati riservati (disclosure), la modifica non autorizzata o sbagliata dei dati (data integrity), la negazione del servizio (Denial of Service) ela frode sono alcune delle possibili minacce ad un qualsiasi sistema informativo. Nel caso di un sistema distribuito la sicurezza è una questione delicata, specialmente nel caso in cui ci si trovi in una rete aperta come Internet. Tuttavia, per ogni sistema di questo tipo si presentano delle questioni da trattare con metodi diversi a seconda del contesto e delle politiche di sicurezza e protezione che sono state definite nell organizzazione, azienda o sistema specifico. I temi principali nel caso di un sistema di tipo clientserver sono l autorizzazione e l autenticazione. Per queste operazioni esistono vari meccanismi che permettono di gestirle, fra cui la protezione con password, con smart card crittografate o attraverso la biometria. I problemi di sicurezza nel client-server computing possono essere dovuti alle seguenti falle: sicurezza credenziali: si presentano quando un individuo qualsiasi riesce ad ottenere l accesso non autorizzato a un computer attraverso le credenziali di accesso di qualche utente.

53 2.6 Client-server: sicurezza 45 sicurezza del software: alcuni difetti (bug) nel software possono causare la presenza di errori nel sistema compromettendo i risultati. uso incoerente: possono accadere quando due usi diversi di un sistema contrastano su un unico punto di sicurezza; sicurezza fisica: si presentano quando un qualsiasi vi è un qualsiasi accesso fisico alla macchina che ospita il server o una delle sue componenti (ad esempio: se un malintenzionato riesce ad accedere alla sala in cui è contenuta la macchina fisica e porta via l hard disk o manomette il sistema). Gli ultimi due tipi di falle possono essere eliminate grazie ad un attenta progettazione e implementazione del sistema, mentre per risolvere le falle dovute ai problemi di sicurezza fisica possono essere utilizzati dei metodi di protezione migliori. Questi metodi di protezione e sicurezza possono essere classificati nelle seguenti categorie: sicurezza basata sulla fiducia (trust based), sicurezza attraverso segretezza, schema della password, sistema biometrico Le minacce di sicurezza emergenti Possiamo identificare le minacce di sicurezza emergenti dei sistemi client-server come: minacce all ambiente di elaborazione locale da mobile code 2 minacce ai server che possono includere l impersonificazione, le intercettazioni, i denial of service o la modifica dei pacchetti di rete. Il metodo di protezione consiste nella ricerca di dati dannosi e frammenti di programma che sono trasferiti dal server al client filtrando i dati e programmi noti per essere pericolosi Server: possibili minacce Le possibili minacce di sicurezza al server possono essere dei seguenti tipi: L intercettazione è l attività di ascoltare in modo passivo i dati inviati attraverso la rete. Questo sistema consente ad un malintenzionato di ottenere la trascrizione 2è u n s o f t w a r e t r a s f e r i b i l e f r a s i s t e m i d i v e r s i, a d e s e m p i o, t r a s f e r i b i l i a t t r a v e r s o l a r e t e o t r una penna USB, ed eseguito su un sistema locale, senza l esplicita esecuzione da parte del destinatario.

54 46 2 Client-server computing completa delle attività di rete e in tal modo di ottenere informazioni sensibili, come password, dati e procedure per svolgere delle funzioni. La crittografia può impedire gli intercettatori dall ottenere dati che viaggiano su reti non protette. Denial of service è la situazione in cui un utente rende il sistema inutilizzabile per gli utenti legittimi monopolizzando o danneggiando una risorsa in modo che non possa essere utilizzata. Le forme più comuni di questo attacco sono le seguenti: Sovraccarico di servizio (Service Overloading): un server può essere reso inutilizzabile tramite l invio di una grande quantità di richieste di servizio illegittime, atte a consumare le sue risorse (in particolare il ciclo di CPU). In una tale situazione il server può negare (per limiti fisici o anche implementativi) le richieste di servizi che invece sono legittime. Inondazione di Messaggi (Message flooding): si tratta di un processo che punta a saturare il disco del server inviando ripetutamente e concorrentemente richieste o file di grandi dimensioni. Questo può causare il blocco del disco. Attacco di risposta (Replay Attack): è una forma di attacco di rete che consiste nell impossessarsi di una credenziale di autenticazione comunicata da una macchina ad un altra e riproporla successivamente simulando l identità dell emittente. In genere l azione viene compiuta da un attaccante che s interpone tra i due lati comunicanti (man in the middle). Questo tipo di minaccia può essere risolto utilizzando dei token di sessione generati pseudocasualmente, oppure utilizzando una marca temporale e all interno nel corpo del messaggio crittografato.

55 Capitolo 3 LHC e CMS Physics is the universe s operating system. Steven R. Garman 3.1 LHC Il Large Hadron Collider (LHC)[30], è il piú grande e potente acceleratore di particelle mai costruito. L acceleratore è collocato in un tunnel circolare di 27 km di circonferenza, inizialmente scavato per ospitare il Large Electron Positron Collider (LEP)[31], situato a circa 100m sotto la campagna che circonda Ginevra a cavallo della frontiera franco-svizzera. LHC accelera due fasci di protoni circolanti in senso opposto, ognuno contenuto in un tubo a vuoto, ed è stato disegnato per far collidere i due fasci ad un energia nel centro di massa di 14 TeV (1 TeV = 1 miliardo di elettronvolt = ev 1 ). Le collisioni avvengono in quattro punti. In corrispondenza di queste zone di collisione sono stati installati quattro grandi apparati sperimentali: ATLAS (A Toroidal LHC Apparatus), CMS (Compact Muon Solenoid), LHCb ed ALICE (A Large Ion Collider Experiment). Questi si occupano di rivelare le collisioni prodotte da LHC e, a valori nominali, produrranno una quantità di dati pari a quella che oggi producono l insieme delle reti di telecomunicazione europee! Due di questi, ATLAS e CMS, sono rivelatori dedicati ad uno studio generale della fisica di LHC. I restanti due (ALICE e LHCb) sono più piccoli e più specializzati. I primi fasci di protoni sono stati fatti circolare, a bassa energia e senza farli collidere tra loro, il 10 settembre Dopodiché LHC è tornato operativo solo il 19 novembre 1 Un elettronvolt (simbolo ev) è l energia acquistata da un elettrone libero quando passa attraverso una di erenza di potenziale elettrico di 1 volt.

56 48 3 LHC e CMS Il 23 novembre 2009 i 4 esperimenti hanno registrato i primi eventi da collisioni protone-protone di LHC. Figura 3.1: Il progetto LHC. Le ricerche e ettuate con LHC serviranno per lo studio della fisica ad alte energie, per la conferma delle attuali teorie della fisica ed in particolare della verifica del Modello Standard. IlModello Standard è una teoria della fisica che spiega esattamente una vasta gamma di fenomeni subnucleari, lasciando tuttavia ancora senza risposta molte domande fondamentali. Di conseguenza i fisici ritengono che quello di cui siamo a conoscenza non sia tutto e questo è il motivo per cui si sta cercando la nuova fisica che sta oltre il Modello Standard, che permetterà loro di arrivare ad una teoria più completa. 3.2 CMS CMS (Compact Muon Solenoid)[32] è uno dei due grandi esperimenti general-purpose di fisica delle particelle installati all acceleratore protone-protone LHC del laboratorio CERN di Ginevra. Circa 3600 persone da 183 istituti scientifici di 38 stati formano la collaborazione CMS che ha costruito il rivelatore. Il rivelatore CMS è capace di studiare tutti gli aspetti fisici delle collisioni protone-protone ad un energia nel centro di

57 3.2 CMS 49 massa di 14 TeV. L apparato sperimentale contiene sotto-rivelatori capaci di misurare l energia e l impulso di fotoni, elettroni, muoni e altre particelle create nelle collisioni. È suddiviso geometricamente in una parte cilindrica centrale (barrel) chiuso alle due estremità da due tappi (endcaps). Il rivelatore piú vicino al punto di collisione è il tracciatore al silicio. Attorno ad esso vi è il calorimetro elettromagnetico, che è poi seguito dal calorimetrico adronico. Il tracciatore ed i calorimetri sono collocati all interno del magnete solenoidale superconduttore che genera un campo magnetico di 4 Tesla. All esterno del magnete vi è il sistema di rivelazione dei muoni, che è collocato nel giogo in ferro che chiude le linee di forza del campo magnetico. L intero apparato sperimentale di CMS ha un diametro di 15 m, è lungo 21m ed ha un peso totale di oltre tonnellate. Figura 3.2: Struttura del rivelatore CMS. Ognuno dei 5 sotto-rivelatori ha dei canali di lettura propri (per un totale di 15 milioni di canali di lettura) attraverso i quali CMS puó raccogliere dati per vari TB/s, di cui peró solo alcuni saranno selezionati per essere scritti su disco (100 MB/s). Il sistema di selezione on-line (trigger) è basato su due livelli: uno hardware ed uno software. Questi permetteranno di ridurre la frequenza dai 40 MHz (frequenza di collisione a LHC) a 100 Hz (frequenza di scrittura dati), cioè 100 MB/s, che corrispondono alla scrittura di circa 1 PB di dati (raw data) per ogni anno. La mole di dati scritta de-

58 50 3 LHC e CMS ve poi essere resa accessibile ad ogni membro della collaborazione indipendentemente dalla sua locazione geografica. Inoltre le risorse di calcolo sono messe a disposizione sia dal centro di calcolo del CERN sia per la maggior parte dei membri della collaborazione, per questo diventa fondamentale mettere a punto un sistema computazionale che permetta di sfruttare questa potenza di calcolo distribuita. Nell ottica di soddisfare le suddette problematiche, CMS ha deciso di fare uso della Grid. L ammontare dei dati crescerá nel tempo e il paradigma Grid sembra essere l unico sistema per rendere trattabile questa mole di dati (che dovrebbe corrispondere al 10% della massa di dati prodotti annualmente sulla Terra) L ambiente computazionale di CMS L utilizzo degli strumenti Grid messi a disposizione dai progetti LCG ed OSG consente di risolvere il problema piú complicato ed importante, ossia rendere accessibili dati e risorse distribuiti. Il modello computazionale distribuito di CMS[33] è stato progettato proprio per servire, elaborare e archiviare il gran numero di eventi che verranno registrati durante la presa dei dati. Le risorse computazionali sono geograficamente distribuite, interconesse tramite reti ad alta capacità e accedute attraverso la Grid. La scelta di un sistema distribuito permette la delega delle responsabilità della gestione alle comunità locali di CMS, accedendo ad ulteriori canali di finanziamento e assicurando un maggiore equilibrio del carico delle risorse disponibile, replicando i dati d interesse su siti di erenti. Architettura gerarchica Il modello di calcolo di CMS ha definito una struttura gerarchica dei vari centri della collaborazione che sono detti Tier. Come mostrato in figura 3.3 sono presenti quattro livelli: Tier-0 : del Tier-0 fa parte un solo centro computazionale, localizzato al CERN che riceve dati dal CMS Data Acquisition System, li archivia e fornisce una prima ricostruzione degli stessi. I dati ricostruiti, assieme ai dati grezzi (raw data), sono distribuiti sui Tier-1 attraverso una rete privata in fibra ottica che è lo scheletro della rete appositamente costruita per LHC, in modo da interconnettere il CERN e i Tier-1. In aggiunta al Tier-0, il CERN ospita la CMS Analysis Facilities (CAF)[33] disegnata per supportare attività che necessitano di un periodo di latenza più breve possibile. Tier-1 : è il livello sottostante al Tier-0; i centri che ne fanno parte sono distribuiti in vari paesi; questi siti o rono servizi in grado di archiviare, ricostruire e calibrare dati. Piú in generale questo livello fornisce dei servizi su larga scala, fondamentali per la gestione dei dati ed e ettuati con un lavoro centralizzato. Questo livello assicura la custodia di una parte dei row data prodotti dal rilevatore CMS e dei dati simulati

59 3.2 CMS 51 prodotti ai centri Tier-2 connessi. Tier-2 : sono centri piú piccoli ma piú numerosi di quelli al livello precedente (attualmente più di 50); questi siti forniscono principalmente notevoli risorse computazionali (CPU) e capacitá di analisi; i Tier-2 sono associati gerarchicamente ad uno specifico Tier-1 e fanno riferimento a questi ultimi per accedere a degli insiemi di dati (dataset) molto grandi. Tier-3 : il livello piú vicino all utente è il livello Tier-3 (risorsa dipartimentale); i siti appartenenti a questo livello forniscono le risorse locali per i gruppi e non hanno obblighi formali verso la collaborazione, ma solo responsabilità verso gli utenti. Tier-0, Tier-1 e Tier-2 sono risorse globali dell esperimento, mentre i Tier-3 sono risorse a disposizione essenzialmente degli utenti locali. Figura 3.3: Il modello computazionale di CMS: l architettura su livelli Framework dell analisi distribuita in CMS Il modello d analisi di CMS prevede che le attività siano guidate dalla locazione dei dati (data driven). Questi ultimi vengono distribuiti attraverso i vari centri computazionali (Tier-2). Al momento della richiesta di processamento di una specifica porzione di dati, saranno i siti che ospitano i dati richiesti ad o rire la potenza di calcolo neces-

60 52 3 LHC e CMS saria all analisi e quindi non saranno i dati ad essere spostati a tempo di esecuzione. Ovviamente, per permettere tali operazioni in un ambiente distribuito ed eterogeneo, sono necessarie delle applicazioni adeguate atte ad interfacciarsi con il complesso sistema di calcolo ed a nascondere agli utenti gli aspetti tecnici, garantendo cosí un accesso trasparente alle risorse. Per tali motivazioni è stato sviluppato un insieme di strumenti, andando così a costituire dei servizi specifici di CMS sopra i servizi Grid già esistenti. Questi strumenti costituiscono il Data e Workload Management (DMWM) della collaborazione. Data Management Il CMS Data Management ha il ruolo di mettere a disposizione l infrastruttura e gli strumenti necessari per gestire la gran quantità di dati prodotti, processati e analizzati in un ambiente computazionale distribuito. Per poter semplificare la gestione dei dati, i singoli file vengono raggruppati in blocchi (file-block) aventi una dimensione conveniente per il loro trasferimento. I file-block sono le unità del dato che vengono utilizzati per il posizionamento e la replica e sono a loro volta raccolti in dataset, la cui dimensione e definizione dipendono dal significato fisico dei dati. Dunque il Data Management mette a disposizione gli strumenti (basi di dati e relative interfacce) che tengono traccia dei dati distribuiti e delle loro locazioni. Oltre a quest ultima, vengono tracciate anche le informazioni logiche che sono poi risolte attraverso dei cataloghi locali ai centri di elaborazione. Le dimensioni dei file sono adeguatamente grandi (almeno 1GB), in modo da evitare problemi di scalabilitá con i sistemi di memorizzazione (Storage Element o nastro magnetico che siano) nonché per ottimizzare il trasferimento dei dati. Questo è reso possibile dalla possibilità di unire piccoli file di output, prodotti da singoli job, in pochi file grandi (grazie all operazione di merge). Il CMS Data Management System è costituito da un insieme di componenti interoperanti descritte nelle seguenti sezioni. DBS. Il Dataset Bookkeeping System (DBS)[34] è il mezzo per descrivere, scoprire e usare i dati-eventi di CMS. Questo cataloga le definizioni specifiche dei dati di CMS quali il numero di run, gli algoritmi e le configurazioni usate per elaborare i dati assieme alle informazioni relative alla parentela del processamento dei dati. DBS memorizza le informazioni inerenti ai dati in un formato che ne rende possibile la consultazione tramite interrogazioni: queste permettono di scoprire quali dati siano disponibili e come questi siano organizzati logicamente, in termini di file, file-block e dataset. DBS viene usato per l operazione di scoperta dei dati (data discovery) e la configurazione dei job da parte dei sistemi di produzione ed analisi attraverso un apposita

61 3.2 CMS 53 interfaccia costituita dalle DBS API. Gli utenti possono scoprire quali dati sono disponibili attraverso il Web o interfaccia a linea di comando (CLI ). DBS o re varie opportunità di utilizzo: un DBS globale come singola istanza che cataloga tutti i dati di CMS; molti DBS locali utilizzati per descrivere i dati prodotti dalle produzioni MonteCarlo di gruppi di fisica e singoli individui; se necessario i dati catalogati nei DBS locali possono essere migrati nel DBS globale, secondo opportune procedure dipendenti dalle caratterstiche dei dati. DBS è un applicazione Web costituita da più livelli e con una struttura modulare. Questo rende possibile e facile adattare il sistema a svariati tipi di database, consentendo una distribuzione (o meglio deployment) che va dalle generiche esigenze di CMS fino alle installazione individuali. Attualmente i tipi di database supportati sono ORACLE, MySQL e SQLite. Il DBS globale è installato al CERN, ed ospita anche alcuni cataloghi di tipo locale, appartenenti a specifici gruppi di fisica interni a CMS. Ovviamente esistono istanze locali installate presso altri siti e per usi prettamente privati. Local Data Catalog. Come detto in precedenza, un applicazione di CMS conosce informazioni realtive solamente ai file logici e per aver accesso ai file fisici si basa su un servizio locale al sito che funge da catalogo dei file. Ogni sito della collaborazione mantiene un Trivial File Catalog costituito da un semplice insieme di regole necessarie a costruire il percorso specifico dei file nel sito, a partire dal nome logico dei file e dal protocollo d accesso. PhEDEx. Il posizionamento e il sistema di trasferimento dei dati in CMS è implementato da PhEDEx[35]. Questo sistema fornisce un interfaccia web per definire, eseguire e controllare le decisioni amministrative sul movimento dei dati: dove i dati sperimentali devono trovarsi, quali copie devono essere custodite dal sito e quali dati devono essere replicati su altri siti a seconda delle politiche definite all interno della collaborazione, anche per facilitare l accesso a dati. Inoltre i dati vengono distribuiti su svariati siti a seconda delle risorse disponibili, degli interessi dei vari gruppi di fisica e in ultimo anche dalle scelte dei membri delle comunità locali di CMS a cui un sito fornisce servizi. Ogni sito ha la libertà di scelta dei sistemi di memorizzazione (Storage Element) da utilizzare. Per PhEDEx ogni area di memorizzazione distinta è rappresentata da un nodo. I collegamenti logici fra i nodi definisco la topologia di trasferimento. Il flusso di lavoro dei trasferimenti inizia quando un utente e ettua una richiesta di trasferimento

62 54 3 LHC e CMS di dati verso un qualche nodo attraverso un servizio Web dedicato; di conseguenza la richiesta deve essere approvata dal Data Manager del nodo in questione. Nella richiesta l utente specifica quali dati vuole trasferire e dove li vuole trasferire: il nodo sorgente viene selezionato in modo ottimale e automatico (attraverso una specifica implementazione dell algoritmo di Dijkstra[36]) fra tutti i nodi che ospitano una replica dei dati in questione. Questo consente a PhEDEx di bilanciare il trasferimento dei dati fra sorgenti multiple quando gli stessi dati sono presenti in più nodi. Il sistema in questione è in grado di tollerare trasferimenti non stabili: quando un trasferimento fallisce in uno specifico collegamento è possibile utilizzare un altra replica disponibile. Da un punto di vista tecnico PhEDEx è basato su agenti software distinti a seconda delle operazioni che svolgono. Ognuno di essi memorizza il proprio stato e comunica attraverso un database centrale installato al CERN, basato su ORACLE, utilizzato dunque come una black board. Alcuni agenti sono centrali al CERN, mentre ogni sito ha degli agenti che interagiscono con lo Storage Element locale. Gli agenti dedicati al trasferimento dei dati utilizzano varie metodologie di trasferimento (anche a seconda dei protocolli di trasferimento disponibili nel sito a cui fa riferimento il nodo), rendendo PhEDEx indipendente dalle tecnologie supportate. Un sito Web mette a disposizione gli strumenti di gestione necessari ad eseguire le operazioni richieste, quali la possibilità di creare richieste (ad esempio: di trasferimento o cancellazione dei dati) ed approvarle o meno, permettendo inoltre agli utenti e agli amministratori di controllare lo stato attuale e storico dei trasferimenti. Oltre a tutto questo PhEDEx tiene traccia del posizionamento dei dati all interno del sistema computazionale distribuito, fornendo un supporto indispensabile agli strumenti di analisi che necessitano di conoscere dove sono localizzati i dati al momento della sottomissione dei job. CMS ha trasferito oltre 87 PB di dati da quando il progetto PhEDEx è iniziato nel 2004 (figura 3.4). Workload Management Il ruolo del sistema di CMS Workload Management[37] è la gestione del flusso di lavoro necessario al processamento dei dati inteso come: creazione e sottomissione, monitoraggio dei job e recupero dei risultati. Il Production Agent (ProdAgent)[38] è ottimizzato per eseguire queste operazioni in un ambiente controllato, come il Tier-0 e i centri computazionali appartenenti al livello Tier-1. Il CMS Remote Analysis Builder (CRAB) è ottimizzato per sostenere l analisi dei dati eseguita dagli utenti. Software di CMS. Il software per la simulazione, la ricostruzione e l analisi dei dati provenienti dal rivelatore è scritto usando la programmazione orientata agli oggetti. Le applicazioni sviluppate possono essere divise in due categorie a seconda degli scopi.

63 3.2 CMS 55 Figura 3.4: Velocità dei trasferimenti di PhEDEx dal 2004 al La prima categoria consiste del software che si occupa della simulazione delle particelle elementari e della risposta del rivelatore (ossia dell output atteso). La seconda categoria si occupa di collezionare e ricostruire i dati, per poi fornire gli strumenti per l analisi degli stessi. L insieme degli strumenti sviluppati in questo ambiente per la simulazione del rilevatore e la ricostruzione dei dati è chiamato CMSSW (CMS SoftWare framework). Il software è strutturato nei seguenti elementi principali: un framework configurabile per ogni ambiente computazionale, in grado di consentire l analisi e la ricostruzione degli eventi; moduli software per calcoli fisici che possono integrarsi con il framework al momento dell esecuzione, operando attraverso i costrutti che sono già disponibili per l accesso ai dati; strumenti di servizio ed utilità che consistono di due categorie principali di servizi: fisici (es: routine di calcolo e stampa di istogrammi) e computazionali (accesso ai dati, comunicazione fra i moduli, etc). Tipicamente l utente utilizza questo software sia in maniera interattiva che in modalità batch. Dato il modello computazionale di CMS l utente, per procedere nell analisi dei dati, dovrà interagire con la Grid.

64 56 3 LHC e CMS CRAB. L analisi dei dati in un ambiente distribuito è molto complessa dal punto di vista computazionale; infatti, nonostante la presenza degli strumenti messi a disposizione dal framework CMSSW, è necessario e ettuare molti passi per preparare e gestire i propri job. I principali sono: configurazione dell ambiente remoto riproducendo le stesse identiche condizioni dell ambiente locale sottomissione dei job su Grid controllo dell esecuzione dei job ritiro dell output contenente i risultati. Tutto questo rappresenta un lavoro complesso per un fisico, che tipicamente è interessato principalmente al solo risultato dei suoi job. Per l utente è quindi necessaria un interfaccia che esegua degli automatismi che permettano di semplificare il flusso di lavoro per l analisi dei dati di CMS. Il CMS Remote Analysis Builder (CRAB)[39] è stato sviluppato come un interfaccia orientata all utente in grado di permettere all utente finale l analisi dei dati in un ambiente locale o distribuito, nascondendo le complessità dellle interazioni con la Grid e i servizi di CMS. Questo software permette all utente di lavorare su grandi insiemi di dati distribuiti usando lo stesso algoritmo di analisi che egli ha sviluppato in locale lavorando su piccoli sottoinsiemi di dati. Le funzionalità messe a disposizione da CRAB mostrate in figura 3.5 sono: Data-discovery e locazione: facilita l interrogazione con i cataloghi dei dati di CMS (DBS e PhEDEx) per trovare quali dati sono disponibili e dove possono essere acceduti. Creazione job: raccoglie e comprime localmente il codice dell utente, con le relative librerie, e tutto l ambiente di lavoro che deve essere inviato ai siti remoti dove i dati sono localizzati. Job splitting: decide come configurare ogni singolo job, per quanto riguarda l accesso ad un sottoinsieme di file del dataset in modo da distribuire l uso delle risorse del Tier-2. Sottomissione job: sottomissione ai siti Grid dove sono localizzati i dati richiesti dall utente. Monitoraggio job: controlla lo stato dei job interagendo con i servizi Grid. Ritiro output: i risultati prodotti dai job o vengono copiati nello Storage Element di un Tier-2 associato all utente in questione o nel caso di file di dimensioni

65 3.2 CMS 57 ragionevolmente piccole (pochi MB) possono tornare direttamente all utente. è poi possibile pubblicare i dati prodotti, con la loro descrizione e provenienza all interno di un DBS locale, in modo che i dati prodotti possano essere utilizzati per ulteriori analisi o semplicemente condivisi con altri utenti all interno della collaborazione. Figura 3.5: CRAB workflow. WMS può essere inteso sia come glite WMS che come glidein WMS. Strumenti di monitoraggio. In uno scenario altamente distribuito gli strumenti di monitoraggio sono dei servizi critici per il successo dell analisi, come per CMS. Questi permettono di controllare l evoluzione degli altri strumenti sviluppati da CMS (CRAB, ProdAgent,...), dando una visione completa della struttura operativa. Gli obiettivi principali che hanno guidato lo sviluppo degli strumenti di monitoraggio sono: nessuna fiducia sugli strumenti di monitoraggio locali ai siti; avere un visione unica dell utilizzo degli strumenti di CMS, che sia di alto livello e da cui sia possibile selezionare e visualizzare i dettagli delle operazioni fino al livello di un singolo processo; mantenere il sistema snello e flessibile: anche a costo di avere qualche informazione non segnalata in modo del tutto adeguato; registrare su cienti informazioni sugli errori in modo che i piani e le azioni successive possano essere basate sui dati quantitativi e che sia possibile misurare l e cacia delle soluzioni;

66 58 3 LHC e CMS individuare le informazioni necessarie alle scelte dei responsabili, così che sia possibile capire come indirizzare le attività degli utenti e su come pianificare i lavori futuri; cercare di non definire a priori tutti i parametri rilevanti. Il lavoro di monitoraggio è costruito attorno all idea di un applicazione che aggrega informazioni: i vari processi e strumenti inviano messaggi ad un collettore centrale. Ovviamente ciò implica che in questo modo possono essere raccolte solo le informazioni inviate secondo precise specifiche. In CMS gli strumenti di monitoraggio sono costituita dalla Dashboard. Quest applicazione si basa su una base di dati gestita tramite un server Oracle, una serie di strumenti che collezionano le informazioni provenienti da varie fonti di alimentazione, e da un paio di interfacce Web che attraverso diverse viste danno l accesso a livelli di dettaglio di erenti, aggregando questi in modo flessibile e personalizzato. Le viste principali che sono messe a disposizione sono quella contenente le informazioni da un punto di vista storico, quella che contiene le informazioni a tempo di esecuzione relative ai processi di analisi degli utenti e un interfaccia interattiva che permette di navigare da una vista ad un altra fornendo sia estrema flessibilità che dettaglio nello informazioni.

67 Capitolo 4 CRAB: evoluzione verso un architettura client-server Version 1 of any software is full of bugs. Version 2 fixes all the bugs and is great. Version 3 adds all the things users ask for, but hides all the great stu in Version 2. Fred Blechman La necessitá di ottimizzare l utilizzo delle risorse di calcolo distribuito in ambiente Grid ha portato la collaborazione CMS allo sviluppo di applicazioni basate sull architettura client-server. In questo capitolo vengono illustrate le motivazioni, le problematiche e i dettagli implementativi della strategia adottata nel caso dell analisi distribuita. 4.1 Motivazioni dell evoluzione CRAB nasce nel 2004 con l obiettivo di soddisfare le esigenze del modello di analisi di CMS. In particolare CRAB si propone di consentire agli utenti un accesso e ciente ai dati distribuiti nascondendo le complessità della Grid. Come è stato precedentemente illustrato (vedi sezione 3.2.2), la prima implementazione di CRAB è basata su di un architettura autoconsistente in un unica entitá, totalmente in mano all utente (standalone model) e capace di soddisfare le esigenze basilari del caso d uso in questione. In figura 4.1 è mostrato lo schema con le interazioni e il flusso di lavoro di CRAB. Dunque i principali livelli d interazione sono:

68 60 4 CRAB: evoluzione verso un architettura client-server il middleware della Grid; iservizididata Management di CMS (ad esempio quelli necessari per la ricerca dei dati); l ambiente di sviluppo locale (come il software di CMS); l area di lavoro dell utente sulla User Interface. Le fasi principali del flusso di lavoro sono: preparare l ambiente di lavoro, che consiste nelle seguenti fasi: l area di lavoro del software CMSSW, opportunamente installata e configurata; l eseguibile e le relative librerie che si vogliono sottomettere alla Grid; le variabili d ambiente necessarie all interazione con CRAB e la Grid; utilizzare CRAB per eseguire i job sulla Grid in modo facile e trasparente: creare e sottomettere alla Grid il proprio lavoro; controllarne l avanzamento; ritirare l output del proprio lavoro una volta che questo è terminato; e ettuare altre operazioni a seconda dell esito e dei risultati ottenuti. CRAB standalone è stato usato con successo dagli utenti di CMS a partire dal 2004 fino ad oggi per eseguire l analisi dei dati simulati (Monte Carlo). Il primo utilizzo intenso di questo strumento c è stato a partire dalla primavera del 2006 per la preparazione del Physics Technical Design Report (Physics TDR)[40]. Successivamente CRAB è stato utilizzato durante le fasi dei test di scala di CMS (data challenges). L ultima è stata CSA07[41] durante la quale sono stati sottomessi jobs con CRAB ad una frequenza di jobs al giorno distribuiti su circa 40 siti diversi. I primi test con dati non simulati sono stati e ettuati durante il Cosmic Challenge del 2006[42]. Se da un lato le prestazioni e la semplicitá dell interfaccia di CRAB standalone erano soddisfacenti per le esigenze della collaborazione in quella fase, dall altro è stato possibile mettere in evidenza i limiti di scala e soprattutto è stato possibile individuare i margini di miglioramento, soprattutto dal punto di vista dell automazione. Per quanto riguarda i limiti osservati, i principali sono: utilizzo del sistema computazionale: l integrazione con la Grid non è completamente adeguata per le funzionalità e potenzialità che questa mette a disposizione non permettendo al sistema di scalare. Le maggiori conseguenze sono la lentezza nell interazione diretta con la Grid specialmente quando si gestiscono un gran numero di job;

69 4.1 Motivazioni dell evoluzione 61 UI C R A B CRAB DatasetPath LFNs, #events, fileblocks DBS Dataset Discovery jdl, job, Fileblocks RB/WMS SEs PhEDEx DLS Output jdl, job (DLI interface) Dataset Location CE LFN!> PFN trivial file catalog WN... Data SE File Location Output (also to remote SE) Figura 4.1: CRAB: flusso di lavoro e interazioni. implementazione del modello computazionale: per definizione è possibile supportare un unico semplice flusso di lavoro. L assenza di persistenza non consente il supporto di flussi complessi e concatenati; gestione dello strumento software stesso: la distribuzione agli utenti di nuove versioni o di aggiornamenti che spesso includono dei cambiamenti cruciali è complessa, macchinosa e lenta, in quanto non centralizzata; interazione con gli utenti e implementazione delle politiche della collaborazione: il supporto degli utenti è di cile in quanto tutte le informazioni risiedono su macchine remote dei servizi o dei vari siti della Grid; inoltre la gestione dei vincoli della collaborazione è complessa perché non esiste una gestione centralizzata. Queste costituiscono le principali motivazioni dell evoluzione da uno strumento ad un architettura basata sul modello client-server. L introduzione di un server di analisi nell architettura costituisce l inserimento di un livello aggiuntivo fra l utente e il middleware della Grid, così come mostrato in figura 4.2.

70 62 4 CRAB: evoluzione verso un architettura client-server Oltre a far fronte alle limitazioni sopra elencate i vantaggi che si vogliono ottenere UTENTI CRAB SERVER CRAB SERVER MYSQL SERVER STORAGE SERVER GRID MIDDLEWARE SITO GRID SITO GRID SITO GRID RISORSE Figura 4.2: L aggiunta di un nuovo livello fra la Grid e l utente. con l introduzione del modello client-server sono: rendere il più possibile automatico il flusso di lavoro dell analisi in CMS; ridurre il lavoro umano non necessario spostando tutte le azioni automatizzabili sul server, rendendo il client un interfaccia semplice e leggera (thin client, vedi 2.1) che funziona come punto d accesso a tutto il sistema; automatizzare il più possibile l interazione con la Grid, e cioè la sottomissione, la risottomissione intelligente, la gestione dei possibili errori, il ritiro dei risultati e tutte le operazioni post-mortem dei job; raccogliere in un unico sistema centrale l insieme delle informazioni dei job degli utenti per poter rivelare eventuali errori e poterli risolvere. Tale aspetto risulta cruciale nell ottica di poter controllare i siti e la Grid in tempo reale, soprattutto in previsione del massiccio incremento legato alla partenza di LHC; gestire centralmente gli aggiornamenti dell applicazione ed eventuali problemi, cioè avere la possiblità di un amministrazione centralizzata.

71 4.2 Client-server: fattorizzazione del flusso di lavoro 63 Il server dell analisi distribuita si propone di migliorare la scalabilità dell intero sistema di calcolo mettendo a disposizione dell esperimento CMS le funzionalità specifiche che non possono essere incluse nel middleware della Grid, per definizione generico e multiuso. Questo nuovo strumento consente di introdurre un insieme di funzionalità e automazioni mantenendo l accesso trasparente alle risorse sottostanti, senza nessun impatto reale sugli utenti finali. L interfaccia proposta, la sua installazione e la procedura di configurazione rimangono le stesse dello standalone. 4.2 Client-server: fattorizzazione del flusso di lavoro L introduzione del paradigma client-server comporta di conseguenza una fattorizzazione delle funzionalitá fra le due entitá in gioco con la conseguente aggiunta di un nuovo livello nel flusso d interazione come mostrato in figura 4.3. Ilclientsemplifica lo strumento standalone senza modificarne l architettura[43]. É scritto in Python ed utilizza una base di dati SQLite per memorizzare in modo persistente le informazioni della singola analisi. Il client viene eseguito dall utente attraverso la linea di comando occupandosi di: creare i job interazione con i servizi di Data Management per la ricerca dei dati e della loro locazione; interazione con l area di lavoro dell utente, preparando l input sandbox che contiene l eseguibile dell utente più le librerie necessarie; preparazione dei job: suddivisione del task di analisi in piú job (job splitting), creazione degli script necessari alla gestione dell esecuzione del job; inviare la richiesta di sottomissione al server passandogli la richiesta XML, la serializzazione su file XML dei job e l input sandbox associata; una volta che la richiesta è stata presa in carico dal server è possibile: controllare lo stato di avanzamento dei job tramite il server; ritirari i risultati una volta che questi sono stati processati dal server; ri-sottomettere al server i job che sono falliti; eseguire altre operazioni sui job, quali: cancellarli o richiedere informazioni post-mortem.

72 64 4 CRAB: evoluzione verso un architettura client-server UserBox CRAB Client Proxy CRAB server datasetpath DBS Jdl, Job LFN, #events, fileblocks BOSS DB gsiftp server direct submission available Dataset Discovery jdl, fileblocks SEs PhEDEx DLS (DLI enabled, LFC based) Job RB fileblocks SEs Dataset Location jdl Output CE trivial file catalog WN... Output Data SE File Location Figura 4.3: CRAB: flusso di lavoro e interazioni con l introduzione del server. Il server si occupa del resto del flusso di lavoro, e cioé di tutte quelle operazioni che non richiedono strettamente l intervento umano. Dunque esegue in modo automatico le seguenti operazioni: ricevere le richieste dal client in formato XML, verificare i dati in input per poi deserializzare la descrizione dei job memorizzandola in modo persistente sulla base di dati; soddisfare le richieste di sottomissione del client, inviando i job verso la Grid a nome dell utente richiedente; controllare lo stato dei job e memorizzarlo nella base di dati locale; ritirare i risultati quando i job sono terminati e aggiornare la base di dati con i relativi codici di uscita; ri-sottomettere i job che sono falliti secondo particolari condizioni predefinite;

73 4.3 Strategia implementativa 65 eseguire altre operazioni su richiesta del client: fornire informazioni sull avanzamento dei job, cancellare i job, etc. 4.3 Strategia implementativa I vantaggi o erti da un architettura client-server non sono certamente senza conseguenze; ad esempio l introduzione di un nuovo servizio puó rappresentare un singolo punto di fallimento e l impossibilità di bilanciare il carico di lavoro. Per far fronte a tali problematiche è stato deciso di mettere in produzione più istanze del server di analisi distribuiti fra i vari siti della collaborazione, in modo che in caso di mancata disponibilitá di un server sia sempre possibile per l utente accedere trasparentemente ad un altro. Un altro aspetto è quello relativo alla progettazione e implementazione, che ovviamente nel caso di un architettura complessa richiedono uno sforzo maggiore rispetto ad una semplice applicazione non distribuita. Per riuscire ad ottimizzare la forza lavoro disponibile e avere un ambiente di lavoro comune la collaborazione CMS ha deciso di mettere a disposizione dei vari strumenti del Workload Management una struttura comune detta WMCore[44]. Quest ultima è un framework software costituito da una serie di librerie di codice utilizzabili attraverso un insieme ben definito di API 1, spesso corredate da strumenti di supporto allo sviluppo delle estensioni o altri strumenti ideati per aumentare la velocità di sviluppo del prodotto finito.[45] A seconda delle esigenze dettate dagli obiettivi di sviluppo, ogni singolo progetto del Workolad Management estende il framework per poter aggiungere le funzionalità specifiche sfruttando il concetto di modularitá, che consente una facile separazione delle attivitá rispetto ad una vasta gamma di funzionalitá. La possibilità di avere un framework comune fra i vari progetti consente la sinergia degli sviluppatori aumentando la produttività e riducendo i costi. Inoltre la struttura per componenti modulari o re il vantaggio della sostituibilità e della riusabilitá del codice, caratteristiche importanti di un software ad alta qualitá. La sostituibilitá del codice è una proprietá importante che permette ad una componente di essere sostituita da un altra (sia durante la fase di progettazione che a tempo di esecuzione), se i requisiti delle componenti sono gli stessi. Di conseguenza, le componenti possono essere 1 Le Application Programming Interface sono ogni insieme di procedure disponibili al programmatore, di solito raggruppate a formare un set di strumenti specifici per un determinato compito.è un metodo per ottenere un astrazione, di solito tra l hardware e il programmatore, o tra software a basso ed alto livello. Le API permettono di evitare ai programmatori di scrivere tutte le funzioni dal nulla. Le API stesse sono un astrazione: il software che fornisce una certa API è detto implementazione dell API.

74 66 4 CRAB: evoluzione verso un architettura client-server sostituite anche con una loro versione aggiornata o ad esempio con una componente alternativa, senza interrompere il sistema nel quale la componente lavora, garantendo una gestione centralizzata che semplifica le operazioni sopra descritte. 4.4 Architettura del server Il server ha un architettura modulare costituita da componenti indipendenti implementate come demoni, dette agenti. Le componenti sfruttano le funzionalità del framework software messo a disposizione dal Workload Management di CMS. Oltre a queste sono state sviluppate delle componenti esterne tra cui le principali sono: Storage Element API: librerie che forniscono un interfaccia generica a diversi tipi di Storage Element attraverso di erenti protocolli; BossLite: framework per l interazione con la Grid che fornisce un interfaccia generica a diversi tipi di middleware consentendo di mantenere in modo persistente le informazioni sui job sottomessi; Message Service: servizio necessario a far comunicare in modo asincrono e persistente le varie componenti secondo il modello publish/subscribe. Questoprevede una comunicazione asincrona fra vari processi detti agenti in cui sia i mittenti che destinatari di messaggi dialogano attraverso un tramite, detto dispatcher basato su una base di dati. Il mittente di un messaggio (publisher) non è consapevole dell identitá dei destinatari (detti subscriber), ma esso si limita a pubblicare (publish) il proprio messaggio al dispatcher. I destinatari si rivolgono a loro volta al dispatcher sottoscrivendosi (subscribe) alla ricezione di messaggi. Il dispatcher quindi inoltra ogni messaggio inviato da un publisher a tutti i subscriber interessati a quel messaggio. Questo implica che ai publisher non sia noto quanti e quali sono i subscriber e viceversa. In figura 4.4 è mostrato lo schema SQL su cui il dispatcher gestisce il sistema di messaggistica. Credential API: librerie necessarie a gestire le credenziali delegate dagli utenti. Quasi tutto il software all interno del server è sviluppato utilizzando il linguaggio di programmazione Python. Rispetto ad altri linguaggi orientati agli oggetti esso permette di ridurre le linee di codifica, grazie alla sua duttilità e all esteso insieme di librerie disponibili che facilitano la programmazione ad alto livello. Il fatto che non necessita di essere compilato permette una manutenzione facile e veloce. L esigenza di memorizzare le informazioni in modo persistente implica l utilizzo di una base di dati relazionale (RDMS: Relational database management system). Attualmente quello in uso è MySql 5.0 [46], i cui vantaggi sono che:

75 4.4 Architettura del server 67 MS_MESSAGE MSG_ID TYPE SOURCE DEST MSG TIME DELAY MS_TYPE MS_SUBSCRIPTION MS_PROCESS TYPE_ID NAME SUB_ID TYPE_ID PROC_ID PROC_ID NAME HOST PID MS_HISTORY MSG_ID TYPE SOURCE DEST MSG TIME DELAY Figura 4.4: Schema SQL del supporto per la gestione del Message Service. supporta la maggior parte delle sintassi SQL e rispetta quasi del tutto lo standard ANSI, possiede delle interfacce per diversi linguaggi, fra cui Python, viene distribuito con lincenza GNU GPL 2, ha un stabilità elevata data dall esperienza accumulata e dall ampio utilizzo in tutti i settori. La struttura modulare del server è tale da consentire il supporto a di erenti tipi di basi di dati relazionali con la semplice implementazione di poche classi specifiche per la definizione dei dettagli dei comandi di interazione con il nuovo sistema (il framework comune mette già a disposizione le librerie necessarie per l utilizzo di Oracle). I parametri sopra specificati, le opzioni specifiche di ogni singola componente e tutte le informazioni di cui il server necessita sono specificate in un file in formato XML generato automaticamente durante la fase d installazione. I parametri possono essere specificati e modificati dall amministratore del server a seconda della configurazione specifica: 2 La GNU General Public License è una licenza per software libero. Ècomunementeindicatacon l acronimo GNU GPL o semplicemente GPL.

76 68 4 CRAB: evoluzione verso un architettura client-server nome, porta, percorso e tipo di protocollo dell host di Storage; variabili di accesso al server MySql fra cui le credenziali per l accesso, il tipo di accesso (locale via socket 3 o remoto) e altri parametri specifici; file di configurazione dei servizi del middleware, locazione delle credenziali delegate dagli utenti al server e URL da cui ritirare eventuali file di configurazione controllati centralmente. Qua sotto è riportato come esempio il contenuto del file di configurazione di uno dei server di CRAB attualmente in produzione: <?xml version="1.0"?> <CrabServerConfig> <CrabServerConfiguration> <Component Name="TaskTracking"/> <Component Name="JobTracking"/> <Component Name="GetOutput"/> <Component Name="ErrorHandler"/> <Component Name="JobKiller"/> <Component Name="HTTPFrontend"/> <Component Name="CrabServerWorker"/> <Component Name="AdminControl"/> <Component Name="Notification"/> <Component Name="TaskRegister"/> <Component Name="TaskLifeManager"/> <Component Name="CommandManager"/> <ConfigBlock Name="HTTPFrontend"> <Parameter Name="InstallerModule" Value="Plugins.HTTPFrontend.CrabServerTools"/> <Parameter Name="HWmonitorLogFile" Value="$WORKAREA/HTTPFrontend/HW.log"/> <Parameter Name="FirstRun" Value="None"/> <Parameter Name="ComponentDir" Value="$WORKAREA/HTTPFrontend"/> </ConfigBlock> <ConfigBlock Name="JobTracking"> <Parameter Name="PoolThreadsSize" Value="4"/> <Parameter Name="ComponentDir" Value="$WORKAREA/JobTracking"/> <Parameter Name="jobsToPoll" Value="3000"/> <Parameter Name="RssFeed" Value="no"/> <Parameter Name="QueryInterval" Value="3"/> <Parameter Name="PollInterval" Value="10"/> </ConfigBlock> <ConfigBlock Name="CrabServerConfigurations"> <Parameter Name="Protocol" Value="uberftp"/> <Parameter Name="storagePath" Value="/data/CSstoragePath"/> <Parameter Name="credentialType" Value="Proxy"/> <Parameter Name="storagePort" Value="XYZ"/> <Parameter Name="CacheDir" Value="/data1/CSstoragePath/logs"/> <Parameter Name="ProxiesDir" Value="/tmp/del_proxies/"/> <Parameter Name="storageName" Value="crabas.lnl.infn.it"/> <Parameter Name="WMSserviceList" Value=""/> <Parameter Name="baseConfUrl" Value="http://cmsdoc.cern.ch/cms/LCG/crab/config/"/> <Parameter Name="configFileName" Value="glite_wms_CERN.conf"/> <Parameter Name="crabServerschemaLocation" Value="$CRAB_SERVER_ROOT/share/CrabServerDB.sql"/> 3 Gli Unix domain socket (detti anche socket locali o socket in dominio Unix), usati nei sistemi operativi POSIX per le comunicazioni tra processi residenti sullo stesso computer.

77 4.4 Architettura del server 69 <Parameter Name="resourceBroker" Value="CNAFStress"/> </ConfigBlock> <ConfigBlock Name="CrabServerWorker"> <Parameter Name="maxThreads" Value="5"/> <Parameter Name="ComponentDir" Value="$WORKAREA/CrabServerWorker"/> </ConfigBlock> <ConfigBlock Name="JobKiller"> <Parameter Name="KillerName" Value="BossLiteKiller"/> <Parameter Name="ComponentDir" Value="$WORKAREA/JobKiller"/> <Parameter Name="RssFeed" Value="no"/> </ConfigBlock> <ConfigBlock Name="Notification"> <Parameter Name="Notification_SMTPServer" Value="smtp.lnl.infn.it"/> <Parameter Name="ComponentDir" Value="$WORKAREA/Notification"/> <Parameter Name="Notification_SMTPServerDBGLVL" Value="3"/> <Parameter Name="Notification_per_task" Value="true"/> <Parameter Name="NotificationDelay" Value="10"/> <Parameter Name="Notification_SenderName" <Parameter Name="Notification_SenderPwd" Value="XXXXX"/> <Parameter Name="debugLevel" Value="9"/> <Parameter Name="Notification_per_job" Value="false"/> </ConfigBlock> <ConfigBlock Name="TaskLifeManager"> <Parameter Name="levelAvailable" Value="15"/> <Parameter Name="checkProxy" Value="on"/> <Parameter Name="ComponentDir" Value="$WORKAREA/TaskLifeManager"/> <Parameter Name="taskLife" Value="168:00:00"/> <Parameter Name=" Admin" Value="None"/> <Parameter Name="pollingTimeCheck" Value="600"/> </ConfigBlock> <ConfigBlock Name="ErrorHandler"> <Parameter Name="ReportAction" Value="noMove"/> <Parameter Name="ComponentDir" Value="$WORKAREA/ErrorHandler"/> <Parameter Name="DelayFactor" Value="100"/> <Parameter Name="RssFeed" Value="no"/> <Parameter Name="QueueFailures" Value="False"/> <Parameter Name="MaxCacheDirSizeMB" Value="80"/> <Parameter Name="ErrorMatrixFile" Value=""/> <Parameter Name="RunHandlerName" Value="crabRunFailureHandler"/> <Parameter Name="SubmitHandlerName" Value="submitFailureHandler"/> </ConfigBlock> <ConfigBlock Name="BOSS"> <Parameter Name="BossLiteschemaLocation" Value="$PRODCOMMON_ROOT/share/setupDatabase.sql"/> <Parameter Name="configDir" Value="$WORKAREA/BOSS/config"/> <Parameter Name="tmpDir" Value="$WORKAREA/BOSS/tmp"/> </ConfigBlock> <ConfigBlock Name="MessageService"> <Parameter Name="pollInterval" Value="5"/> </ConfigBlock> <ConfigBlock Name="GetOutput"> <Parameter Name="OutputLocation" Value="SE"/> <Parameter Name="ComponentDir" Value="$WORKAREA/GetOutput"/> <Parameter Name="GetOutputPoolThreadsSize" Value="7"/> <Parameter Name="RssFeed" Value="no"/> <Parameter Name="skipWMSAuth" Value="1"/> <Parameter Name="maxGetOutputAttempts" Value="3"/> <Parameter Name="jobsToPoll" Value="3000"/>

78 70 4 CRAB: evoluzione verso un architettura client-server <Parameter Name="PollInterval" Value="10"/> </ConfigBlock> <ConfigBlock Name="CrabServer"> <Parameter Name="CrabServerName" <Parameter Name="CrabServerRunOffset" Value="10"/> <Parameter Name="CrabServerWorkDir" Value="/home/crab/work"/> </ConfigBlock> <ConfigBlock Name="AdminControl"> <Parameter Name="Bots" Value="RestartBot,MessageBot"/> <Parameter Name="BotPeriod" Value="01:00:00"/> <Parameter Name="ComponentDir" Value="$WORKAREA/AdminControl"/> </ConfigBlock> <ConfigBlock Name="CrabServerDB"> <Parameter Name="maxConnectionAttempts" Value="5"/> <Parameter Name="dbType" Value="mysql"/> <Parameter Name="refreshPeriod" Value="14400"/> <Parameter Name="dbWaitingTime" Value="10"/> <Parameter Name="passwd" Value="XXXXX"/> <Parameter Name="host" Value="localhost"/> <Parameter Name="user" Value="DatabaseUserName"/> <Parameter Name="socketFileLocation" Value="$WORKAREA/mysqldata/mysql.sock"/> <Parameter Name="portNr" Value=""/> <Parameter Name="dbName" Value="CrabServerDB"/> <Parameter Name="schemaLocation" Value="$PRODAGENT_ROOT/share/ProdAgentDB.sql"/> </ConfigBlock> <ConfigBlock Name="TaskTracking"> <Parameter Name="PollInterval" Value="13"/> <Parameter Name="ComponentDir" Value="$WORKAREA/TaskTracking"/> <Parameter Name="Thread" Value="5"/> <Parameter Name="debugLevel" Value="9"/> </ConfigBlock> <ConfigBlock Name="TaskRegister"> <Parameter Name="maxThreads" Value="6"/> <Parameter Name="ComponentDir" Value="$WORKAREA/TaskRegister"/> </ConfigBlock> <ConfigBlock Name="CommandManager"> <Parameter Name="acceptableClient" Value="2.7.0,2.7.1"/> <Parameter Name="ComponentDir" Value="$WORKAREA/CommandManager"/> <Parameter Name="acceptableThroughput" Value="-1"/> <Parameter Name="uiConfigWMS" Value=""/> <Parameter Name="uiConfigRB" Value=""/> <Parameter Name="uiConfigRBVO" Value=""/> <Parameter Name="Port" Value="20081"/> </ConfigBlock> <ConfigBlock Name="JobStates"> <Parameter Name="maxRetries" Value="3"/> <Parameter Name="mergeMaxRetries" Value="10"/> </ConfigBlock> </CrabServerConfiguration> </CrabServerConfig> Classificazione logica delle componenti L architettura del server prevede l utilizzo di uno Storage Element locale o remoto per lo scambio dei files dei job degli utenti. In figura 4.5 è mostrata la struttura del server

79 4.4 Architettura del server 71 in termini di agenti e le componenti esterne necessarie al funzionamento del server e con cui il server interagisce. Tutte le componenti (in viola) estendono il framework (detto anche common core) e utilizzano quest ultimo per interagire con la base di dati, per comunicare, per accedere alle credenziali e per interagire con lo Storage esterno. Ogni componente svolge una determinata funzione all interno del server vero e proprio; nelle componenti è implementata la logica dell applicazione che permette di ricevere le richieste degli utenti, processarle e ritornare ai risultati secondo diversi casi d uso supportati che possono essere facilmente aggiunti. Le componenti, a seconda delle entità con cui interagiscono e delle funzioni svolte possono essere classificate nei seguenti gruppi: Input/Output (in arancione nella figura 4.5): CommandManager, HTTPFrontend, Notification; Implementazione logica e gestione (viola): TaskTracking, AdminControl, ErrorHandler, TaskRegister; Interazione con la Grid (azzurre): CrabServerWorker, JobTracking, GetOutput, JobKiller. Molte di esse, specialmente quelle che interagiscono con la Grid, che ricevono gli input dagli utenti e in generale tutte quelle che devono e ettuare operazioni su molti job o task in un breve intervallo di tempo hanno la necessitá di avere delle prestazioni ottime in modo da evitare colli di bottiglia, accorciando e spesso rimuovendo il ritardo per quelle singole operazioni che devono essere svolte in molti task contemporaneamente. Tale ragione spiega perché sia stata introdotta la tecnica del multithreading[47] che consente di ottenere un sistema multi utente scalabile, soprattutto per le operazioni piú frequenti e lente come la sottomissione, il tracciamento dello stato e il ritiro dei risultati dei job. Quando si interagisce con il middleware della Grid infatti è molto importante eseguire piú istanze in parallelo in quanto alcune operazioni richiedono una quantitá di tempo considerevole. I thread permettono di suddividere un programma in piú filoni che vengono eseguiti concorrentemente. Nel caso specifico sono stati adottati due tipi d implementazioni: la prima in cui i thread sono parte di uno stesso processo e condividono risorse come la memoria in modo d accedere alle stesse variabili e comunicare facilmente; la seconda in cui i thread appartengono a processi diversi che non condividono risorse, così che vengano eseguiti in un ambiente isolato e quasi totalmente indipendente.

80 72 4 CRAB: evoluzione verso un architettura client-server RICHIESTE CRAB CLIENT RICHIESTE WEB MAILBOXES Command Manager HTTP Frontend Notification Task Tracking MESSAGE SERVICE CrabJob Creator Admin Control COMMON CORE BOSSLITE TASK/JOB TASK INSTANCE TaskLife Manager MYPROXY Error Handler MYSQL Task Register Job Killer CACHE CREDENZIALI CrabServer Worker STORAGE Job Tracking Get Output MIDDLEWARE Figura 4.5: Vista schematica dell architettura del server di CRAB. Nel caso di una macchina con un architettura a processore singolo la CPU esegue istruzioni di thread di erenti e si parla di multithreading a divisione di tempo, in cui la commutazione fra i thread avviene di solito tanto frequentemente da dare l impressione che tutte le operazioni siano eseguiti contemporaneamente. Ma il vantaggio maggiore si presenta nel caso delle architetture multi-processore (o multi-core) che negli ultimi mesi stanno prendendo sempre più piede tanto da diventare quelle più comuni, in cui i thread vengono realmente eseguiti contemporaneamente, ciascuno su un distinto processore. Nel caso di un servizio come quello in questione avere delle componenti multithread aumenta la velocitá di esecuzione sui sistemi con piú CPU o CPU con piú core. Ovviamente ci sono anche degli svantaggi in quanto tutte le componenti che utilizzano piú thread concorrenti per una stessa porzione di codice devono essere implementate mantenendo la sicurezza dei thread (thread safety) nel caso di esecuzioni multiple

81 4.4 Architettura del server 73 contemporanee. In particolare è importante che i vari threads possano avere accesso alle stesse informazioni condivise, ma che queste siano modificabili solo da un thread alla volta. Nel caso di un processo multithreaded con piú thread che accedono virtualmente agli stessi dati, la struttura di controllo e l ordine di accesso ai dati stessi non rispettano completamente la sequenzialitá del testo del programma, rendendo possibili comportamenti inattesi dovuti alla manipolazione non corretta delle informazioni. Infatti, l utilizzo di tale tecnica ha portato all introduzione di alcune e etti collaterali. In primo luogo questi ultimi sono legati alla gestione della concorrenza fra i vari thread, sia perché Python per quanto riguarda l interazione con MySql non è thread safe sia perché alcuni strumenti messi a disposizione dalla Grid necessitano di un ambiente dedicato per l esecuzione delle chiamate al middleware (ad esempio creando dei thread come fossero dei nuovi sottoprocessi che non condividono l area di memoria fra loro). Questo caso ha dilatato notevolmente il tempo necessario allo sviluppo. In secondo luogo avere molte componenti che a loro volta eseguono molti thread concorrentemente incrementa notevolmente il carico di lavoro per la macchina su cui è installato il server. Il raggiungimento di un carico di lavoro elevato influisce in modo negativo sulle prestazioni del server, rallentando l esecuzione delle operazioni eseguite dalle singole componenti. Per questo motivo non è possibile aumentare senza criterio il numero di thread necessari (generalmente un numero maggiore di thread permette un esecuzione più veloce delle richieste e delle operazioni), in quanto questo dipende strettamente dalle prestazioni della macchina fisica, specialmente in termini di processori (o core) disponibili. Infatti i sistemi multiprocessore sono dotati di più unità di calcolo indipendenti ognuna in grado di prendersi carico di un singolo thread. Infatti un fattore di cui tenere conto consiste proprio nel fatto che un alto numero di esecuzioni concorrenti, aumenta il carico di lavoro di tutto il server e dei servizi da esso usati: lo Storage e la base di dati. Per quest ultima è stata creata una libreria ad hoc, lasafe Session. Tale libreria è in grado di gestire le connessioni al database in modo e ciente, incapsulandole nel concetto più generico di sessione e ha le seguenti proprietá: supporta piú tipi di DBMS, contiene un insieme di connessioni (pool ), preserva la sicurezza nella concorrenza dei thread, gestisce piú insiemi di connessioni contemporaneamente anche da parte dello stesso programma (o componente); può essere modificata dall utilizzatore tramite la tecnica dell ereditarietà per aggiungere o modificare il comportamento di base.

82 74 4 CRAB: evoluzione verso un architettura client-server Un pool mantiene un insieme di connessioni aperte al database, evitando di aprire e chiudere una connessione troppe volte. Dunque un qualsiasi utilizzatore della base di dati del server si connette utilizzando una sessione, senza occuparsi dei dettagli della transazione o della connessione. Vedremo il caso specifico dello Storage nel capitolo successivo tramite l implementazione da me svolta delle Storage Element API Descrizione agenti di input/output Le componenti di questo insieme consentono agli utenti di inviare richieste di ogni tipo al server, agli amministratori di poter controllare il funzionamento del server e a quest ultimo di inviare eventuali segnalazioni agli utenti e agli amministratori. CommandManager. La CommandManager è la componente che si prende carico delle richieste del client, le inoltra alle componenti interne del server attraverso il sistema di messaggistica asincrono e preleva le informazioni necessarie per rispondere alla richiesta. La comunicazione fra il client e il server avviene attraverso SOAP 4. Questo è stato scelto sia perché è uno standard de facto nello sviluppo di servizi nella comunità Grid, sia perché è ideale nei servizi web che utilizzano la programmazione orientata agli oggetti. Inoltre permette di lavorare con il protocollo HTTP (Hyper- Text Transfer Protocol), fornendo l interoperabilitá necessaria attraverso istituzioni e linguaggi di programmazione diversi. L implementazione della parte di comunicazione è stata e ettuata grazie a gsoap[48], uno strumento open source per creare servizi web o rendo la possibilitá di sviluppare facilmente in linguaggio C e C/C++ i Web services SOAP/XML (extensible Markup Language). Quindi l agente interagisce con il modulo della comunicazione attraverso delle API che permettono d integrare codice scritto in C/C++ con Python, grazie a SWIG(Simplified Wrapper and Interface Generator)[49]. Il client non assume nulla sui dettagli dell implementazione del server e vice versa e il corpo dei messaggi è definito con XML, che incapsula i comandi e i dettagli delle richieste degli utenti. Di seguito c è un esempio di comando inviato dal client al server che richiede la cancellazione del job numero 1 del task cinquilli crab uyv0 : <?xml version="1.0"?> <TaskCommand ClientVersion="2.7.0" 4 Simple Object Access Protocol è un protocollo leggero per lo scambio di messaggi tra componenti software, tipicamente nella forma di componentistica software. La parola object manifesta che l uso del protocollo dovrebbe e ettuarsi secondo il paradigma della programmazione orientata agli oggetti.

83 4.4 Architettura del server 75 /> Command="kill" Flavour="analysis" Range="[1]" Scheduler="glite" Subject="/C=IT/O=INFN/OU=Personal Certificate/L=Perugia/CN=Mattia Cinquilli" Task="cinquilli\_crab\_0\_091228\_101315\_41uyv0" TotJob="-1" Type="fullySpecified" HTTPFrontend. L HTTPFrontend fornisce gli strumenti necessari per mostrare sia agli utenti che agli amministratori informazioni sul server tramite HTTP: stato dell hardware del server, stato del software del server relativo a MySql, server Python, Storage, etc., vista dei job sul server, raggruppandoli per utente, dati analizzati, tempo, etc.. Questa componente include CherryPy[50], un framework per lo sviluppo web con Python che fornisce le fondamenta sopra le quali costruire applicazioni web in modo molto simile a come si scriverebbe un altro programma Python a oggetti, risultando in meno linee di codice sviluppate in meno tempo. Quindi ogni pagina Web che viene visualizzata da questa componente corrisponde ad un modulo. L insieme dei moduli costituisce un plug-in di questo agente. In figura 4.6 è mostrata una vista della distribuzione per sito Grid dei job sottomessi tramite il server di Legnaro dal 20 Novembre 2009 al 28 Dicembre Notification. La Notification invia messaggi di posta elettronica sia tramite un server di posta locale alla macchina del server, sia autenticandosi ad un server di posta remoto. Generalmente i messaggi di posta inviati notificano gli utenti dell esito dei loro job una volta che sono tutti terminati e gli amministratori per particolari situazioni di allarme che possono verificarsi Descrizione agenti di logica e di gestione Queste componenti gestiscono il flusso di lavoro all interno del server, implementando la logica necessaria a fornire le funzionalitá specifiche e per gestire il server stesso. TaskTracking. La TaskTracking è la componente informativa del server. Gli obiettivi di questa componente sono:

84 76 4 CRAB: evoluzione verso un architettura client-server Figura 4.6: Job per sito sottomessi dal 20 Novembre 2009 al 28 Dicembre Grafico prelevato dall HTTPFrontend del server di analisi di Legnaro. mantenere informazioni generali dei task attivi e non sul server, notificare le altre componenti quando un task passa di stato, generare e mantenere i file xml sullo stato e i log di ogni task. Questa componente è implementata con la tecnica del multithreading e sarà descritta nel dettaglio nel cap. 5. AdminControl. L AdminControl è un semplice framework a plug-in per eseguire periodicamente delle operazioni che possono essere di manutenzione per poter rendere il server il piú possibile auto gestito, riducendo al minimo il carico di lavoro sull amministratore. Ogni plug-in corrisponde ad un operazione o serie di operazioni e due esempi ne sono: RestartBot: puó capitare che per qualche motivo una componente non sia piú in esecuzione e questo si occupa di controllare che tutte le componenti del server siano in esecuzione facendo ripartire quelle che non lo sono.

85 4.4 Architettura del server 77 MessageBot: pulisce la tabella del database che contiene lo storico dei messaggi inviati dalle componenti attraverso il MessageService. ErrorHandler. L ErrorHandler si occupa della gestione degli errori sottoscrivendosi agli eventi (sotto forma di messaggi) generati dalle altre componenti. A seconda del tipo di errore e del tipo di job questa componente esegue l operazione associata, aggiornando le informazioni del job. Ha una struttura a plug-in 5 in modo che possano essere definiti una vasta gamma di errori e che per ogni caso d uso generico venga definito un plug-in appropriato. I plug-in da utilizzare vengono specificati nella configurazione del server. Quando la componente riceve l evento a cui è registrata essa attiva il plug-in associato all evento passandogli le informazioni necessarie. Il plug-in principalmente utilizzato è quello che si occupa di gestire i fallimenti dei job, prendendo delle decisioni a seconda del codice di uscita del job e innescando le azioni necessarie (generando un nuovo evento per un altra componente). Attualmente le azioni disponibili sono: NoResubmission: non viene eseguita nessuna azione per il job, che viene archiviato; è l azione eseguita di default; DelayedResubmission: viene richiesta la risottomissione del job, con un ritardo configurabile; ResubmitElsewhere: viene richiesta la risottomissione, ma il sito in cui il job è fallito viene rimosso da quelli disponibili. TaskRegister. La TaskRegister prende in carico le richieste di nuovi task dalla CommandManager, verifica la consistenza e la correttezza dei dati in ingresso (proxy, input sandbox, definizione task, etc.) e, se questa va a buon fine, prepara le strutture dati necessarie al server, deserializzando nel database del server le informazioni inviate dal client in formato XML; infine invia un messaggio di corretta registrazione di un nuovo task. Questa componente è multithreaded e permette di gestire ogni singolo task per thread Descrizione agenti per l interazione con la Grid Le componenti di questo gruppo sono basate soprattutto su BossLite per interagire con i vari middleware in modo trasparente. Come detto in precedenza sono implemen- 5 plug-in: programma non autonomo che serve ad aumentare le funzioni di una applicazione. Ad esempio, i plug-in dei browser web permettono di visualizzare oltre alle pagine html altri tipi di file, come le animazioni in formato flash, etc. La capacitá di un software di supportare i plugin è generalmente un ottima caratteristica, perché rende possibile l ampliamento e la personalizzazione delle sue funzioni in maniera semplice e veloce.

86 78 4 CRAB: evoluzione verso un architettura client-server tate secondo il modello di multithread per velocizzare l interazione con il middleware che spesso è fra le operazioni meno veloci di tutto il flusso di lavoro, evitando di creare dei rallentamenti e congestionamenti del servizio nel caso di richieste simultanee. CrabServerWorker. É strutturata da un modulo principale che si occupa di ricevere le richieste di sottomissione di insiemi di job verso la Grid ritornandone l esito e da un insieme di thread che vengono attivati dal modulo principale solo quando vi sono delle richieste da soddisfare. Un compito della componente è anche quello di e ettuare un vero e proprio scheduling delle sottomissioni su delle code appropriate distribuendo il carico di lavoro fra i vari thread. Per ogni singola richiesta di sottomissione, che spesso comprende piú job, questo agente implementa i controlli sulle dimensioni delle collezioni di job e se necessario le ridefinisce al fine di ottimizzare l interazione con la Grid. L esito dell operazione di sottomissione non è sempre positivo e per questo sono state implementate delle soluzioni di fall back. Questo agente si occupa anche di e ettuare eventuali ri-sottomissioni. JobTracking. La JobTracking controlla regolarmente lo stato dei job sottomessi sulla Grid e richiede il ritiro dell output per quei job che sono finiti. La componente è strutturata in due moduli: il primo modulo principale (main module) esegue l inizializzazione e gestisce i messaggi ricevuti; il secondo (status monitor) aggiorna lo stato dei job nella base di dati interna interrogando la Grid e segnala i job terminati alla GetOutput. Quest ultimo è stato implementato utilizzando un pool scheduler, unpool di thread e due code per la comunicazione. Il pool scheduler assegna il carico di lavoro per le interrogazioni, che in parallelo eseguono il controllo dello stato. Un modello basato sulla comunicazione di token che identificano i sottoinsiemi di job garantisce la sincronizzazione tra i thread e il pool scheduler, consentendo l assegnazione dinamica dei job. Il modello di funzionamento è mostrato in figura 4.7. Il pool scheduler partiziona l insieme dei job in una serie di sottoinsiemi, assegnando un identificatore (token) a ciascuno di essi. Dopo di che, il pool scheduler inserisce gli identificatori nella coda di input, che è persistente (sulla base di dati del server). La prima azione che viene e ettuata dal thread è quella di mettersi in attesa di un token da leggere dalla coda di input. Dopo avere ottenuto il token, il thread esegue l operazione per il controllo dello stato di tutti i job connessi a tale token, inserendo quest ultimo nella coda di output e andando nuovamente a leggere dalla coda di input per ottenere un nuovo incarico. Il token inserito nella coda di output viene prelevato dal pool scheduler, che dunque può e ettuare nuovamente l assegnazione dei job connessi a tale token, insieme ai nuovi

87 4.4 Architettura del server 79 job che nel frattempo possono essere stati sottomessi su Grid. Figura 4.7: Implementazione con un pool di thread della componente JobTracking. GetOutput. La GetOutput esegue l operazione di ritiro dei risultati dei job degli utenti quando viene richiesto dalla JobTracking. La componente interroga regolarmente la base di dati interna per verificare se ci sono o meno job per cui è stato richiesto il ritiro degli output, mettendo in coda tali richieste. Un gruppo di thread (pool thread ) prende le richieste dalla coda, e ettua l operazione e mette in coda l output. Regolarmente la componente interroga la coda per verificare se ci sono job per cui sono stati ritirati i risultati, generando il corrispondente messaggio di job terminato con successo oppure fallito. La struttura per classi è mostrata in figura 4.8. La classe GetOutputComponent è la classe principale e il metodo checkjobs() esegue l interrogazione per job di cui è stato richiesto l output, mettendo la richiesta nella coda dei thread. Successivamente esegue un interrogazione dei job di cui è stato ritirato l output, per ognuno di essi chiama il metodo processoutput() processando l output ritirato dai thread. La classe JobHandling implementa i metodi necessari a dialogare con il MessageService, la gestione delle operazioni con il file system e con le operazioni necessarie ad archiviare i job processati. La classe JobOutput implementa tutte le operazioni specifiche per il ritiro dell output, includendo i metodi come requestoutput() usato anche dalla componente JobTracking per richiedere l operazione, dowork() che implementa il corpo del thread che esegue realmente l operazione interagendo con BossLite e la Grid, e setdonestatus() usato per indicare la fine di un operazione. JobKiller. La JobKiller mette a disposizione i servizi necessari a cancellare i job sottomessi verso la Grid. Anche questa componente funziona a plug-in, è costituita da un unica classe che gestisce sequenzialmente tutte le richieste smistandole al plug-in desiderato. I diversi plug-in eseguono l operazione di cancellazione in modo diverso a

88 80 4 CRAB: evoluzione verso un architettura client-server Figura 4.8: Schema UML della componente GetOutput. seconda del tipo di richiesta ricevuta. 4.5 Interfaccia al middleware ed ai sistemi di batch: BossLite BossLite è la libreria sviluppata con Python per interfacciarsi con i vari middleware della Grid e con i sistemi batch locali. Questo strumento mette a disposizione un interfaccia generica e astratta, rendendo possibili operazioni standard come la sottomissione, il tracciamento, la cancellazione e il ritiro dei risultati dei job. Le interfacce ai sistemi specifici vengono istanziate al momento dell esecuzione grazie ad una struttura a plug-in, dove ogni plug-in contiene le definizioni per interagire con il sistema specifico. Attualmente è supportata l interazione con i seguenti middleware: glite di EGEE

89 4.5 Interfaccia al middleware ed ai sistemi di batch: BossLite 81 CondorG di OSG ARC di NorduGrid e con i seguenti sistemi locali: LSF Condor SGE PBS BossLite usa una base di dati per tracciare e registrare in uno schema entitá-relazioni le informazioni dei task e job da esso gestiti. Le informazioni presenti nella base di dati vengono rimappate logicamente e velocemente attraverso oggetti di Python che permettono agli strumenti di livelli logici più alti di utilizzare tali informazioni in modo trasparente. Un sessione per la connessione alla base di dati permette di eseguire operazioni (aprire e chiudere connessioni, e ettuare interrogazioni, inserimenti o aggiornamenti di tuple, etc.) attraverso un interfaccia astratta e supportando diversi tipi di DBMS. Attualmente quelli supportati sono MySql e SQLite[51]. L architettura di BossLite è mostrata in figura 4.9.

90 82 4 CRAB: evoluzione verso un architettura client-server Figura 4.9: Vista schematica dell architettura di BossLite.

Cos'é una (Computing) GRID?

Cos'é una (Computing) GRID? Incontro Borsisti Progetto Lauree Scientifiche Perugia, 26 agosto 1 settembre 2007 Cos'é una (Computing) GRID? Istituto Nazionale Fisica Nucleare Sezione di Perugia Università Studi di Perugia Perché il

Dettagli

Griglie computazionali

Griglie computazionali Griglie computazionali Università degli Studi di Napoli Federico II Corso di Laurea Magistrale in Informatica I Anno IL MIDDLEWARE Richiami sulla caratterizzazione dei sistemi GRID Il Concetto di Virtual

Dettagli

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale 1. Livello infrastrutturale Il Cloud, inteso come un ampio insieme di risorse e servizi fruibili da Internet che possono essere dinamicamente

Dettagli

Organizzazioni nel Grid Computing

Organizzazioni nel Grid Computing Il ruolo delle Organizzazioni nel Grid Computing Un primo sguardo a Globus - Parte 5 Organizzazioni di Grid Computing Panoramica sui prodotti software Primo sguardo a Globus Dott. Marcello CASTELLANO La

Dettagli

Presentazione NIS Network Integration & Solutions s.r.l. Autore: nome Cognome Data: Evento

Presentazione NIS Network Integration & Solutions s.r.l. Autore: nome Cognome Data: Evento Presentazione NIS Network Integration & Solutions s.r.l. Autore: nome Cognome Data: Evento Chi siamo NIS nasce nel 1993 come spin-off dalla Università di Genova (DIST) Nel 1996 viene aperta una unità operativa

Dettagli

Reti di Calcolatori GRIGLIE COMPUTAZIONALI

Reti di Calcolatori GRIGLIE COMPUTAZIONALI D. Talia RETI DI CALCOLATORI - UNICAL 10-1 Reti di Calcolatori GRIGLIE COMPUTAZIONALI D. Talia RETI DI CALCOLATORI - UNICAL 10-2 Griglie Computazionali Cosa è il Grid Computing? Architettura Ambienti Globus

Dettagli

GRIGLIE COMPUTAZIONALI

GRIGLIE COMPUTAZIONALI Reti di Calcolatori GRIGLIE COMPUTAZIONALI D. Talia RETI DI CALCOLATORI - UNICAL 10-1 Griglie Computazionali Cosa è il Grid Computing? Architettura Ambienti Globus D. Talia RETI DI CALCOLATORI - UNICAL

Dettagli

Sicurezza su Grid. Corso: Sicurezza Informatica Studente: Mattia Cinquilli Professore: Stefano Bistarelli AA: 2008/2009

Sicurezza su Grid. Corso: Sicurezza Informatica Studente: Mattia Cinquilli Professore: Stefano Bistarelli AA: 2008/2009 Sicurezza su Grid Corso: Sicurezza Informatica Studente: Mattia Cinquilli Professore: Stefano Bistarelli AA: 2008/2009 Introduzione e Definizione di Computing Grid La griglia computazionale eʼ un tipo

Dettagli

Titolo progetto: ConsoliData. Ambito di intervento: ICT e dispositivi sensoriali. Struttura di riferimento : Coordinatore di progetto: INFN

Titolo progetto: ConsoliData. Ambito di intervento: ICT e dispositivi sensoriali. Struttura di riferimento : Coordinatore di progetto: INFN Titolo progetto: ConsoliData Ambito di intervento: ICT e dispositivi sensoriali Struttura di riferimento : Coordinatore di progetto: INFN Altri EPR coinvolti: - Altri organismi e soggetti coinvolti: Descrizione

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

Corso di Informatica per la Gestione Aziendale

Corso di Informatica per la Gestione Aziendale Corso di Informatica per la Gestione Aziendale Anno Accademico: 2008/2009 DOCENTI: Prof.ssa Cecilia Rossignoli Dott. Gianluca Geremia Università degli Studi di Verona Dipartimento di Economia Aziendale

Dettagli

Sistemi Distribuiti. Libri di Testo

Sistemi Distribuiti. Libri di Testo Sistemi Distribuiti Rocco Aversa Tel. 0815010268 rocco.aversa@unina2.it it Ricevimento: Martedì 14:16 Giovedì 14:16 1 Libri di Testo Testo Principale A.S. Tanenbaum, M. van Steen, Distributed Systems (2

Dettagli

Sistemi Operativi. Modulo 2. C. Marrocco. Università degli Studi di Cassino

Sistemi Operativi. Modulo 2. C. Marrocco. Università degli Studi di Cassino Sistemi Operativi Modulo 2 Schema di un Sistema di Calcolo Programmi Dati di Input Calcolatore Dati di output Modello di von Neumann Bus di sistema CPU Memoria Centrale Memoria di Massa Interfaccia Periferica

Dettagli

D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS

D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS Il modello SaaS Architettura 3D Cloud Il protocollo DCV Benefici Il portale Web EnginFrame EnginFrame

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2010/2011 Questi lucidi sono stati prodotti sulla

Dettagli

CLOUD COMPUTING REFERENCE ARCHITECTURE: LE INDICAZIONI DEL NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Prima parte: Panoramica sugli attori

CLOUD COMPUTING REFERENCE ARCHITECTURE: LE INDICAZIONI DEL NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Prima parte: Panoramica sugli attori ANALISI 11 marzo 2012 CLOUD COMPUTING REFERENCE ARCHITECTURE: LE INDICAZIONI DEL NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY Nella newsletter N 4 abbiamo già parlato di Cloud Computing, introducendone

Dettagli

I SISTEMI OPERATIVI CONCETTI INTRODUTTIVI

I SISTEMI OPERATIVI CONCETTI INTRODUTTIVI I SISTEMI OPERATIVI CONCETTI INTRODUTTIVI Il Software Software di Base Sistema Operativo (Software di base essenziale) Software di base non essenziale Utility Driver Software applicativi (Applicazioni)

Dettagli

CLOUD COMPUTING. Che cos è il Cloud

CLOUD COMPUTING. Che cos è il Cloud CLOUD COMPUTING Che cos è il Cloud Durante la rivoluzione industriale, le imprese che si affacciavano per la prima volta alla produzione dovevano costruirsi in casa l energia che, generata da grandi macchine

Dettagli

Studio e implementazione di metodi di previsione dei guasti per politiche di scheduling in ambito Desktop Grid

Studio e implementazione di metodi di previsione dei guasti per politiche di scheduling in ambito Desktop Grid Studio e implementazione di metodi di previsione dei guasti per politiche di scheduling in ambito Desktop Grid Relatore Dott. Massimo Canonico Candidato Guido Vicino Laurea in Informatica dei Sistemi Avanzati

Dettagli

Università degli Studi di Napoli Federico II Corso di Laurea Magistrale in Informatica I Anno

Università degli Studi di Napoli Federico II Corso di Laurea Magistrale in Informatica I Anno Griglie computazionali Università degli Studi di Napoli Federico II Corso di Laurea Magistrale in Informatica I Anno LEZIONE N. 16 Resource Management Systems: PBS, MAUI Il Computing Element Griglie computazionali

Dettagli

Corso di Sistemi di Elaborazione delle informazioni

Corso di Sistemi di Elaborazione delle informazioni Corso di Sistemi di Elaborazione delle informazioni Sistemi Operativi Francesco Fontanella La Complessità del Hardware Il modello di Von Neumann è uno schema di principio. Attualmente in commercio esistono:

Dettagli

Il Cloud Computing: uno strumento per migliorare il business

Il Cloud Computing: uno strumento per migliorare il business Il Cloud Computing: uno strumento per migliorare il business Luca Zanetta Uniontrasporti I venti dell'innovazione - Imprese a banda larga Varese, 9 luglio 2014 1 / 22 Sommario Cos è il cloud computing

Dettagli

EGRID MIDDLEWARE OVERVIEW. Angelo Leto Abdus Salam I.C.T.P. aleto@ictp.trieste.it 08/10/2004

EGRID MIDDLEWARE OVERVIEW. Angelo Leto Abdus Salam I.C.T.P. aleto@ictp.trieste.it 08/10/2004 EGRID MIDDLEWARE OVERVIEW Angelo Leto Abdus Salam I.C.T.P. aleto@ictp.trieste.it 08/10/2004 Introduzione al concetto di GRID Sulla base dell implementazione GLOBUS-EDG-EGRID What is the GRID? What is the

Dettagli

C Cloud computing Cloud storage. Prof. Maurizio Naldi

C Cloud computing Cloud storage. Prof. Maurizio Naldi C Cloud computing Cloud storage Prof. Maurizio Naldi Cos è il Cloud Computing? Con cloud computing si indica un insieme di tecnologie che permettono, tipicamente sotto forma di un servizio, di memorizzare/

Dettagli

Grid Middleware: L interazione con IPv6. Valentino R. Carcione valentino.carcione@garr.it GARR. [GARR WS7-Roma-16-11-2006]

Grid Middleware: L interazione con IPv6. Valentino R. Carcione valentino.carcione@garr.it GARR. [GARR WS7-Roma-16-11-2006] Grid Middleware: L interazione con IPv6 Valentino R. Carcione valentino.carcione@garr.it GARR [GARR WS7-Roma-16-11-2006] Grid e IPv6, quali vantaggi? IPv6 offre uno spazio di indirizzamento molto ampio

Dettagli

Studio e implementazione di metodi di previsione dei guasti per politiche di scheduling in ambito Desktop Grid

Studio e implementazione di metodi di previsione dei guasti per politiche di scheduling in ambito Desktop Grid Studio e implementazione di metodi di previsione dei guasti per politiche di scheduling in ambito Desktop Grid Relatore Dott. Massimo Canonico Candidato Guido Vicino Laurea in Informatica dei Sistemi Avanzati

Dettagli

L iniziativa Cloud DT

L iniziativa Cloud DT L iniziativa Cloud DT Francesco Castanò Dipartimento del Tesoro Ufficio per il Coordinamento Informatico Dipartimentale (UCID) Roma, Luglio 2011 Il Cloud Computing Alcune definizioni Il Cloud Computing

Dettagli

Abstract. Reply e il Cloud Computing: la potenza di internet e un modello di costi a consumo. Il Cloud Computing per Reply

Abstract. Reply e il Cloud Computing: la potenza di internet e un modello di costi a consumo. Il Cloud Computing per Reply Abstract Nei nuovi scenari aperti dal Cloud Computing, Reply si pone come provider di servizi e tecnologie, nonché come abilitatore di soluzioni e servizi di integrazione, volti a supportare le aziende

Dettagli

Ottimizzazione dell infrastruttura per la trasformazione dei data center verso il Cloud Computing

Ottimizzazione dell infrastruttura per la trasformazione dei data center verso il Cloud Computing Ottimizzazione dell infrastruttura per la trasformazione dei data center verso il Cloud Computing Dopo anni di innovazioni nel settore dell Information Technology, è in atto una profonda trasformazione.

Dettagli

VIRTUALIZE IT. www.digibyte.it - digibyte@digibyte.it

VIRTUALIZE IT. www.digibyte.it - digibyte@digibyte.it il server? virtualizzalo!! Se ti stai domandando: ma cosa stanno dicendo? ancora non sai che la virtualizzazione è una tecnologia software, oggi ormai consolidata, che sta progressivamente modificando

Dettagli

Il middleware INFNGRID Certification Authority Virtual Organization Servizi core Servizi collective Servizi di supporto al deployment e per la

Il middleware INFNGRID Certification Authority Virtual Organization Servizi core Servizi collective Servizi di supporto al deployment e per la Architettura del middleware INFNGRID e piano di deployment sull'infrastruttura SCoPE Gennaro Tortone INFN Napoli 21 febbraio 2007 Indice Il middleware INFNGRID Certification Authority Virtual Organization

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

Corso di Alfabetizzazione Informatica

Corso di Alfabetizzazione Informatica Corso di Alfabetizzazione Informatica Lezione 6 a.a. 2010/2011 Francesco Fontanella La Complessità del Hardware Il modello di Von Neumann è uno schema di principio. Attualmente in commercio esistono: diversi

Dettagli

Service Level Agreement Management Framework

Service Level Agreement Management Framework Facoltà di Ingegneria Università degli studi di Catania Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Workshop su QoS e SLA Service Level Agreement Management Framework Giovanni Morana

Dettagli

Informatica di Base - 6 c.f.u.

Informatica di Base - 6 c.f.u. Università degli Studi di Palermo Dipartimento di Ingegneria Informatica Informatica di Base - 6 c.f.u. Anno Accademico 2007/2008 Docente: ing. Salvatore Sorce Il Sistema Operativo Gerarchia del software

Dettagli

Estratto dell'agenda dell'innovazione e del Trade Bologna 2011. Speciale: I casi. Introduzione dell'area tematica IL CASO PRIMA INDUSTRIES

Estratto dell'agenda dell'innovazione e del Trade Bologna 2011. Speciale: I casi. Introduzione dell'area tematica IL CASO PRIMA INDUSTRIES Estratto dell'agenda dell'innovazione e del Trade Bologna 2011 Speciale: I casi Introduzione dell'area tematica IL CASO PRIMA INDUSTRIES Innovare e competere con le ICT: casi di successo - PARTE I Cap.8

Dettagli

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche Il Cloud Computing La visualizzazione nella Cloud Problematiche Virtualizzazione della GPU Front end Virtualization

Dettagli

IBM i5/os: un sistema progettato per essere sicuro e flessibile

IBM i5/os: un sistema progettato per essere sicuro e flessibile IBM i5/os garantisce la continua operatività della vostra azienda IBM i5/os: un sistema progettato per essere sicuro e flessibile Caratteristiche principali Introduzione del software HASM (High Availability

Dettagli

Sistema Operativo Compilatore

Sistema Operativo Compilatore MASTER Information Technology Excellence Road (I.T.E.R.) Sistema Operativo Compilatore Maurizio Palesi Salvatore Serrano Master ITER Informatica di Base Maurizio Palesi, Salvatore Serrano 1 Il Sistema

Dettagli

Accesso integrato a risorse computazionali: stato e prospettive

Accesso integrato a risorse computazionali: stato e prospettive Accesso integrato a risorse computazionali: stato e prospettive D. Salomoni Davide.Salomoni@cnaf.infn.it INFN-CNAF CdC CNAF, 15/12/2009 D. Salomoni (INFN-CNAF) Accesso integrato a risorse di calcolo CdC

Dettagli

Una rassegna dei sistemi operativi per il Cloud Computing

Una rassegna dei sistemi operativi per il Cloud Computing Alma Mater Studiorum Università di Bologna SCUOLA DI SCIENZE Corso di Laurea in Informatica Una rassegna dei sistemi operativi per il Cloud Computing Tesi di Laurea in Reti di Calcolatori Relatore: Chiar.mo

Dettagli

Gartner Group definisce il Cloud

Gartner Group definisce il Cloud Cloud Computing Gartner Group definisce il Cloud o Cloud Computing is a style of computing in which elastic and scalable information technology - enabled capabilities are delivered as a Service. Gartner

Dettagli

IT ARCHITECTURE: COME PREPARARSI AL CLOUD

IT ARCHITECTURE: COME PREPARARSI AL CLOUD IT ARCHITECTURE: COME PREPARARSI AL CLOUD Stefano Mainetti stefano.mainetti@polimi.it L ICT come Commodity L emergere del Cloud Computing e i nuovi modelli di delivery Trend n. 1 - ICT Commoditization

Dettagli

i5/os per processi di business efficienti e flessibili

i5/os per processi di business efficienti e flessibili L ambiente operativo integrato leader nel settore i5/os per processi di business efficienti e flessibili Caratteristiche principali Middleware integrato per processi di business efficienti. Funzioni integrate

Dettagli

Sistemi Operativi. Conclusioni e nuove frontiere

Sistemi Operativi. Conclusioni e nuove frontiere Sistemi Operativi (modulo di Informatica II) Conclusioni e nuove frontiere Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Definizione di sistema operativo Evoluzione futura

Dettagli

Il File System. È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati

Il File System. È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati Il File System È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati Le operazioni supportate da un file system sono: eliminazione di dati modifica

Dettagli

Classificazione del software

Classificazione del software Classificazione del software Classificazione dei software Sulla base del loro utilizzo, i programmi si distinguono in: SOFTWARE Sistema operativo Software applicativo Sistema operativo: una definizione

Dettagli

WNoD: Virtualizzazione, Grid e Cloud nel Calcolo Scientifico per l INFN

WNoD: Virtualizzazione, Grid e Cloud nel Calcolo Scientifico per l INFN WNoD: Virtualizzazione, Grid e Cloud nel Calcolo Scientifico per l INFN D. Salomoni Davide.Salomoni@cnaf.infn.it INFN-CNAF CdC CNAF, 16/11/2009 D. Salomoni (INFN-CNAF) WNoD: Virtualizzazione, Grid e Cloud

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

Dettagli

Griglie computazionali LEZIONE N. 14. Università degli Studi di Napoli Federico II Corso di Laurea Magistrale in Informatica I Anno

Griglie computazionali LEZIONE N. 14. Università degli Studi di Napoli Federico II Corso di Laurea Magistrale in Informatica I Anno Griglie computazionali Università degli Studi di Napoli Federico II Corso di Laurea Magistrale in Informatica I Anno LEZIONE N. 14 OGSA, OGSI e WSRF Gli Standard OGF Griglie computazionali - a.a. 2009-10

Dettagli

IL PRIVATE CLOUD DELLA FRIENDS' POWER

IL PRIVATE CLOUD DELLA FRIENDS' POWER IL PRIVATE CLOUD DELLA FRIENDS' POWER Evoluzione al Cloud Computing Condivisione dei lavori Integrazione con Android & iphone Cos è il Cloud: le forme e i vantaggi Durante la rivoluzione industriale, le

Dettagli

soluzioni e servizi per fare grande una media impresa Soluzioni di Cloud Computing per imprese con i piedi per terra.

soluzioni e servizi per fare grande una media impresa Soluzioni di Cloud Computing per imprese con i piedi per terra. soluzioni e servizi per fare grande una media impresa Soluzioni di Cloud Computing per imprese con i piedi per terra. FASTCLOUD È un dato di fatto che le soluzioni IT tradizionali richiedono investimenti

Dettagli

IBM iseries Soluzioni integrate per xseries

IBM iseries Soluzioni integrate per xseries Soluzioni innovative per l integrazione dei server Intel IBM iseries Soluzioni integrate per xseries La famiglia iseries, il cui modello più recente è l _` i5, offre due soluzioni che forniscono alternative

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

Dettagli

Sistemi Operativi di Rete. Sistemi Operativi di rete. Sistemi Operativi di rete

Sistemi Operativi di Rete. Sistemi Operativi di rete. Sistemi Operativi di rete Sistemi Operativi di Rete Estensione dei Sistemi Operativi standard con servizi per la gestione di risorse in rete locale Risorse gestite: uno o più server di rete più stampanti di rete una o più reti

Dettagli

Il sistema operativo

Il sistema operativo Il sistema operativo Percorso di Preparazione agli Studi di Ingegneria Università degli Studi di Brescia Docente: Massimiliano Giacomin Cos è un Sistema Operativo? Per capirlo, immaginiamo inizialmente

Dettagli

Come Funziona. Virtualizzare con VMware

Come Funziona. Virtualizzare con VMware Virtualize IT Il Server? Virtualizzalo!! Se ti stai domandando: ma cosa stanno dicendo? ancora non sai che la virtualizzazione è una tecnologia software, oggi ormai consolidata, che sta progressivamente

Dettagli

Soluzioni innovative per la semplificazione dell infrastruttura IT. Virtualizzazione con il sistema operativo IBM i, PowerVM e Power Systems

Soluzioni innovative per la semplificazione dell infrastruttura IT. Virtualizzazione con il sistema operativo IBM i, PowerVM e Power Systems Soluzioni innovative per la semplificazione dell infrastruttura IT Virtualizzazione con il sistema operativo IBM i, PowerVM e Power Systems Caratteristiche principali La flessibilità e la scalabilità della

Dettagli

Infrastrutture Software

Infrastrutture Software Infrastrutture Software I componenti fisici di un sistema informatico sono resi accessibili agli utenti attraverso un complesso di strumenti software finalizzati all utilizzo dell architettura. Si tratta

Dettagli

Interstudio L INGEGNERE NELLE NUVOLE. App, WEB App e Cloud. ing. Sauro Agostini. Architectural & Engineering Software. venerdì 11 ottobre 13

Interstudio L INGEGNERE NELLE NUVOLE. App, WEB App e Cloud. ing. Sauro Agostini. Architectural & Engineering Software. venerdì 11 ottobre 13 Architectural & Engineering Software L INGEGNERE NELLE NUVOLE App, WEB App e Cloud ing. Sauro Agostini Mitterand 1981 Reagan Battaglin Alice IBM PC 5150 Alonso C ERA UNA VOLTA IL DOS Non è una rivoluzione,

Dettagli

Novell ZENworks Configuration Management in ambiente Microsoft * Windows *

Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Guida GESTIONE SISTEMI www.novell.com Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Novell ZENworks Configuration Management in ambiente Microsoft Windows Indice: 2..... Benvenuti

Dettagli

Come funziona un sistema di elaborazione

Come funziona un sistema di elaborazione Introduzione Cosa è un Sistema Sste aoperativo? Come funziona un sistema di elaborazione Proprietà dei Sistemi Operativi Storia dei Sistemi di Elaborazione Sistemi Mainframe Sistemi Desktop Sistemi i Multiprocessori

Dettagli

w w w. n e w s o f t s r l. i t Soluzione Proposta

w w w. n e w s o f t s r l. i t Soluzione Proposta w w w. n e w s o f t s r l. i t Soluzione Proposta Sommario 1. PREMESSA...3 2. NSPAY...4 2.1 FUNZIONI NSPAY... 5 2.1.1 Gestione degli addebiti... 5 2.1.2 Inibizione di un uso fraudolento... 5 2.1.3 Gestione

Dettagli

Sistemi Operativi II Corso di Laurea in Ingegneria Informatica

Sistemi Operativi II Corso di Laurea in Ingegneria Informatica www.dis.uniroma1.it/~midlab Sistemi Operativi II Corso di Laurea in Ingegneria Informatica Prof. Roberto Baldoni Introduzione OS=Astrazione Dare l illusione all applicazione di memoria infinita, CPU infinita,unico

Dettagli

Architetture dei WIS. Definizione di WIS. Benefici dei WIS. Prof.ssa E. Gentile a.a. 2011-2012

Architetture dei WIS. Definizione di WIS. Benefici dei WIS. Prof.ssa E. Gentile a.a. 2011-2012 Architetture dei WIS Prof.ssa E. Gentile a.a. 2011-2012 Definizione di WIS Un WIS può essere definito come un insieme di applicazioni in grado di reperire, cooperare e fornire informazioni utilizzando

Dettagli

CAPITOLO 5 - Sistemi Operativi Moderni

CAPITOLO 5 - Sistemi Operativi Moderni CAPITOLO 5 - Sistemi Operativi Moderni PRESENTAZIONE DI INSIEME Vedremo ora come si è evoluta nel tempo la struttura di un sistema operativo, per passare dalle vecchie strutture di tipo normalmente modulari,

Dettagli

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni)

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni) Progettazione di Sistemi Interattivi Struttura e supporti all implementazione di applicazioni in rete (cenni) Docente: Daniela Fogli Gli strati e la rete Stratificazione da un altro punto di vista: i calcolatori

Dettagli

SCHEDA DI PROGRAMMAZIONE DISCIPLINARE DA RIPORTARE SUL P.O.F. A.S. 2014-2015. Ripasso programmazione ad oggetti. Basi di dati: premesse introduttive

SCHEDA DI PROGRAMMAZIONE DISCIPLINARE DA RIPORTARE SUL P.O.F. A.S. 2014-2015. Ripasso programmazione ad oggetti. Basi di dati: premesse introduttive SCHEDA DI PROGRAMMAZIONE DISCIPLINARE DA RIPORTARE SUL P.O.F. A.S. 2014-2015 ASSE DISCIPLINA DOCENTE MATEMATICO INFORMATICA Cattani Barbara monoennio CLASSE: quinta CORSO D SEZIONE LICEO SCIENZE APPLICATE

Dettagli

ARCHITETTURE DEI SISTEMI DI ELABORAZIONE

ARCHITETTURE DEI SISTEMI DI ELABORAZIONE ARCHITETTURE DEI SISTEMI DI ELABORAZIONE 1 SISTEMI ACCENTRATI CARATTERISTICHE Sistemi proprietari Monocultura Scarsa diffusione informatica Backlog 2 Soluzione centralizzata TERMINALE TERMINALE ELABORATORE

Dettagli

Soluzioni di firma remota. con PkBox

Soluzioni di firma remota. con PkBox Soluzioni di firma remota con PkBox 18 aprile 2013 Le informazioni contenute in questo documento sono da considerarsi CONFIDENZIALI e non possono essere utilizzate o riprodotte - sia in parte che interamente

Dettagli

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione BANCA VIRTUALE/1 Il termine indica un entità finanziaria che vende servizi finanziari alla clientela tramite le tecnologie dell informazione e della comunicazione, senza ricorrere al personale di filiale

Dettagli

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi Evoluzione dei sistemi operativi (4) Sistemi multiprogrammati! più programmi sono caricati in contemporaneamente, e l elaborazione passa periodicamente dall uno all altro Evoluzione dei sistemi operativi

Dettagli

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4 Obiettivi Principali di un S.D. - 7 Tipi di Sistemi

Dettagli

Supercalcolo e Grid: le infrastrutture per la ricerca del nuovo millennio. P. Govoni Universita ed INFN Milano-Bicocca

Supercalcolo e Grid: le infrastrutture per la ricerca del nuovo millennio. P. Govoni Universita ed INFN Milano-Bicocca Supercalcolo e Grid: le infrastrutture per la ricerca del nuovo millennio P. Govoni Universita ed INFN Milano-Bicocca gli ingredienti fondamentali i computer: gli strumenti che svolgono le operazioni di

Dettagli

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL STRUTTURA DEI SISTEMI OPERATIVI 3.1 Struttura dei Componenti Servizi di un sistema operativo System Call Programmi di sistema Struttura del sistema operativo Macchine virtuali Progettazione e Realizzazione

Dettagli

ERP Commercio e Servizi

ERP Commercio e Servizi ERP Commercio e Servizi Sistema informativo: una scelta strategica In questi ultimi anni hanno avuto grande affermazione nel mercato mondiale i cosiddetti sistemi software ERP. Tali sistemi sono in grado

Dettagli

LAN MAN WAN. Una internet è l'insieme di più reti reti distinte collegate tramite gateway/router

LAN MAN WAN. Una internet è l'insieme di più reti reti distinte collegate tramite gateway/router Rete di reti (interrete, internet) 2 Prof. Roberto De Prisco TEORIA - Lezione 8 Rete di reti e Internet Università degli studi di Salerno Laurea e Diploma in Informatica Una rete di comunicazione è un

Dettagli

Table of Contents. Definizione di Sistema Distribuito 15/03/2013

Table of Contents. Definizione di Sistema Distribuito 15/03/2013 Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4-7 - 13 Definizioni e Principali Caratteristiche

Dettagli

Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro.

Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro. Esercizio di GRUPPO: PROTOCOLLO INFORMATICO Mappa concettuale TECNOLOGIE DISPONIBILI Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro.

Dettagli

I nuovi modelli di delivery dell IT: un quadro di riferimento

I nuovi modelli di delivery dell IT: un quadro di riferimento I nuovi modelli di delivery dell IT: un quadro di riferimento Stefano Mainetti Fondazione Politecnico di Milano stefano.mainetti@polimi.it Milano, 25 Ottobre 2010 Cloud Computing: il punto d arrivo Trend

Dettagli

Progetto per la realizzazione di una Cloud per l'area Padovana

Progetto per la realizzazione di una Cloud per l'area Padovana Progetto per la realizzazione di una Cloud per l'area Padovana Versione 0.3.2 14 Ottobre 2013 Introduzione Il modello di calcolo basato su paradigma GRID si e' rivelato di grande successo perche' ha permesso

Dettagli

Grid Tutorial Day Palermo, 13 Aprile 2011 Job Description Language Gestione job utente

Grid Tutorial Day Palermo, 13 Aprile 2011 Job Description Language Gestione job utente Grid Tutorial Day Palermo, 13 Aprile 2011 Marco Cipolla Job Description Language Gestione job utente Jobs e Applicazioni Utente I job permettono l esecuzione di programmi utente sulla GRID Per sottomettere

Dettagli

Estratto dell'agenda dell'innovazione Smau Milano 2011. Speciale: I casi. Introduzione dell'area tematica. Il caso INCA CGIL

Estratto dell'agenda dell'innovazione Smau Milano 2011. Speciale: I casi. Introduzione dell'area tematica. Il caso INCA CGIL Estratto dell'agenda dell'innovazione Smau Milano 2011 Speciale: I casi Introduzione dell'area tematica Il caso INCA CGIL Innovare e competere con le ICT - PARTE I Cap.1 L innovazione nella gestione dei

Dettagli

IL SOFTWARE TIPI DI SOFTWARE. MACCHINE VIRTUALI Vengono definite così perché sono SIMULATE DAL SOFTWARE, UNIFORMANO L ACCESSO SISTEMA OPERATIVO

IL SOFTWARE TIPI DI SOFTWARE. MACCHINE VIRTUALI Vengono definite così perché sono SIMULATE DAL SOFTWARE, UNIFORMANO L ACCESSO SISTEMA OPERATIVO IL SOFTWARE L HARDWARE da solo non è sufficiente a far funzionare un computer Servono dei PROGRAMMI (SOFTWARE) per: o Far interagire, mettere in comunicazione, le varie componenti hardware tra loro o Sfruttare

Dettagli

UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTÀ DI INGEGNERIA

UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTÀ DI INGEGNERIA UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTÀ DI INGEGNERIA Corso di Sistemi Operativi Prof. Stefano Berretti SEMINARIO: VIRTUALIZZAZIONE DI INFRASTRUTTURE INFORMATICHE a cura di: Nicola Fusari A.A. 2012/2013

Dettagli

Servizi Avanzati in Ambiente Distribuito NESSI - Grid

Servizi Avanzati in Ambiente Distribuito NESSI - Grid Università degli Studi di Messina Facoltà di Ingegneria Servizi Avanzati in Ambiente Distribuito NESSI - Grid Autore: ing. Giulio De Meo Indice degli argomenti Piattaforme Tecnologiche Europee NESSI Grid

Dettagli

Hitachi Systems CBT S.p.A.

Hitachi Systems CBT S.p.A. Hitachi Systems CBT S.p.A. EasyCloud : Cloud Business Transformation LA TECNOLOGIA AL SERVIZIO DEL RINNOVAMENTO AZIENDALE Accompagniamo aziende di ogni dimensione e settore nella trasformazione strategica

Dettagli

Condor-G: Un Agente per la Gestione dell Elaborazione in Multi-Institutional Grids

Condor-G: Un Agente per la Gestione dell Elaborazione in Multi-Institutional Grids Condor-G: Un Agente per la Gestione dell Elaborazione in Multi-Institutional Grids James Frey, Todd Tannenbaum, Miron Livny, Ian Foster, Steven Tuecke Condor-G Sfrutta: Security, comunicazioni, resource

Dettagli

Architetture Informatiche. Dal Mainframe al Personal Computer

Architetture Informatiche. Dal Mainframe al Personal Computer Architetture Informatiche Dal Mainframe al Personal Computer Architetture Le architetture informatiche definiscono le modalità secondo le quali sono collegati tra di loro i diversi sistemi ( livello fisico

Dettagli

Sistemi Operativi I Corso di Laurea in Ingegneria Informatica Facolta di Ingegneria, Universita La Sapienza Docente: Francesco Quaglia

Sistemi Operativi I Corso di Laurea in Ingegneria Informatica Facolta di Ingegneria, Universita La Sapienza Docente: Francesco Quaglia Sistemi Operativi I Corso di Laurea in Ingegneria Informatica Facolta di Ingegneria, Universita La Sapienza Docente: Francesco Quaglia Introduzione: 1. Principi di base dei sistemi operativi 2. Sistemi

Dettagli

Sistemi Operativi. Introduzione UNICAL. Facoltà di Ingegneria. Domenico Talia A.A. 2002-2003

Sistemi Operativi. Introduzione UNICAL. Facoltà di Ingegneria. Domenico Talia A.A. 2002-2003 Domenico Talia Facoltà di Ingegneria UNICAL A.A. 2002-2003 1.1 Introduzione Presentazione del corso Cosa è un Sistema Operativo? Sistemi Mainframe Sistemi Desktop Sistemi Multiprocessori Sistemi Distribuiti

Dettagli

Grid Scheduling e WS-Agreement

Grid Scheduling e WS-Agreement Grid Scheduling e WS-Agreement D. Talia - UNICAL Griglie e Sistemi di Elaborazione Ubiqui Sommario Il Problema del esource Management Applicazioni in più domini Obiettivi del proprietario vs. obiettivi

Dettagli

icaro x PMI ICT Paolo Nesi (UNIFI, DISIT Lab) Feb 2015

icaro x PMI ICT Paolo Nesi (UNIFI, DISIT Lab) Feb 2015 icaro x PMI ICT Paolo Nesi (UNIFI, DISIT Lab) Feb 2015 IaaS, Infrastructure as a Service: Business: vendita di host a consumo Contesto IaaS/PaaS Gestione: limitata al parco degli Host vari Gestori Monitoraggio

Dettagli

Problemi di schedulazione distribuita su Grid

Problemi di schedulazione distribuita su Grid Problemi di schedulazione distribuita su Grid Ivan Porro Università degli Studi di Genova, DIST, Laboratorio BioLab pivan@unige.it 010-3532789 Si ringrazia per il materiale il Dr. Andrea Clematis dell

Dettagli

Architetture Informatiche. Dal Mainframe al Personal Computer

Architetture Informatiche. Dal Mainframe al Personal Computer Architetture Informatiche Dal Mainframe al Personal Computer Architetture Le architetture informatiche definiscono le modalità secondo le quali sono collegati tra di loro i diversi sistemi ( livello fisico

Dettagli

@CCEDO: Accessibilità, Sicurezza, Architettura

@CCEDO: Accessibilità, Sicurezza, Architettura Rev. 8, agg. Settembre 2014 @CCEDO: Accessibilità, Sicurezza, Architettura 1.1 Il Sistema di Gestione della Sicurezza Per quanto riguarda la gestione della Sicurezza, @ccedo è dotato di un sistema di autenticazione

Dettagli

Corso di Sistemi di elaborazione delle informazioni

Corso di Sistemi di elaborazione delle informazioni Corso di Sistemi di elaborazione delle informazioni Biacco Sabrina ENTERPRISE RESOURCE PLANNING Gli ERP sono delle soluzioni applicative in grado di coordinare l'insieme delle attività aziendali automatizzando

Dettagli

Il clustering. Sistemi Distribuiti 2002/2003

Il clustering. Sistemi Distribuiti 2002/2003 Il clustering Sistemi Distribuiti 2002/2003 Introduzione In termini generali, un cluster è un gruppo di sistemi indipendenti che funzionano come un sistema unico Un client interagisce con un cluster come

Dettagli

Sistemi Operativi UNICAL. Facoltà di Ingegneria. Domenico Talia A.A. 2002-2003 1.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi UNICAL. Facoltà di Ingegneria. Domenico Talia A.A. 2002-2003 1.1. Sistemi Operativi. D. Talia - UNICAL Domenico Talia Facoltà di Ingegneria UNICAL A.A. 2002-2003 1.1 Introduzione Presentazione del corso Cosa è un Sistema Operativo? Sistemi Mainframe Sistemi Desktop Sistemi Multiprocessori Sistemi Distribuiti

Dettagli

SISTEMA COMPLETO PER LA GESTIONE DELLA SICUREZZA INTEGRATA IN UN BOX

SISTEMA COMPLETO PER LA GESTIONE DELLA SICUREZZA INTEGRATA IN UN BOX S2 NETBOX SISTEMA COMPLETO PER LA GESTIONE DELLA SICUREZZA INTEGRATA IN UN BOX L inizio di una rivoluzione Nasce una rivoluzione nella mondo della sicurezza fisica: il controllo remoto e integrato delle

Dettagli