POLITECNICO DI BARI Facoltà di Ingegneria Corso di Laurea in Ingegneria Elettronica Tesi di Laurea in Sistemi Operativi Strategie di Super-Scheduling e Replicazione dei dati in Griglie per Applicazioni Data-intensive : Risultati per il progetto EU-DataGrid. Relatori: Chiar.mo Prof. Giacomo Piscitelli Chiar.mo Prof. Marcello Castellano Laureando: Francesco Carlucci A.A. 2001/2002
Ringrazio i Membri della INFN-Sezione di Bari e del Progetto Europeo DataGrid per la preziosa collaborazione offerta.
INDICE INDICE GENERALE Indice generale... 3 Introduzione... 6 Capitolo 1 Caratteristiche generali delle Griglie... 10 1.1. Definizione di Griglia... 10 1.2 Architettura di Griglia... 15 2.1 Livello Fabric: Risorse delle Griglie Computazionali... 16 2.2 Livello Connectivity: Comunicazione fra le Risorse... 17 2.3 Livello Resource: Accesso alle Risorse... 17 2.4 Livello Collective: Coordinazione delle Risorse... 17 2.5 Livello Application: Applicazioni delle Griglie Computazionali... 18 1.3 Tassonomia di una Griglia... 19 1.4 Definizione e requisiti del Workload Management System... 21 1.5 Tassonomia di un Resource Management System... 23 1.5.1 Organizzazione delle macchine... 23 1.5.2 Modello delle Risorse... 24 1.5.3 Organizzazione del Namespace delle risorse... 24 1.5.4 Qualità del Servizio (QoS)... 25 1.5.5 Resource Discovery... 26 1.5.6 Resource Dissemination... 26 1.5.7 Organizzazione degli schedulatori... 27 1.5.8 Stima dello stato del sistema... 28 1.5.9 La rischedulazione... 29 1.5.10 Le politiche di schedulazione... 29 Capitolo 2 Il Progetto EU-DataGrid.... 31 2.1. Caratteristiche del progetto EU-DataGrid... 31 2.1.1 Motivazioni e finalità del progetto EU-DataGrid... 31 2.1.2 Architettura di DataGrid... 35 2.2 WP2 Grid Data Management... 40 2.2.1 La griglia e il modello di storage... 40 2.2.2 Un caso d uso: l analisi HEP... 41 2.2.3 Architettura... 42 3
INDICE 2.2.4 Data Management... 42 2.2.5 Replica Catalog Service... 43 2.2.6 Data Mover Service e Storage Manager Service.... 47 2.2.7 Replica Manager... 48 2.3 WP3: Grid Information and Monitoring services... 51 2.3.1 Globus MDS... 51 2.3.2 R-GMA... 53 2.4 WP4: Fabric Management... 55 2.4.1 Gridification... 57 2.4.2 Resource Management... 59 2.5 WP5: Mass Storage Management... 60 2.5.1 Storage Element Service... 61 2.5.2 Interazioni con il Replica Manager (WP2)... 62 2.5.3 Interazioni con l Information Service (WP3)... 62 2.6 WP7: Network Monitoring... 63 2.6.1 QoS e incremento delle attuali prestazioni.... 64 2.6.2 Monitoring della rete... 64 2.6.2 Il Network Optimization Service... 65 2.7 WP1: Workload Management System... 67 2.7.1 ClassAd e il Job Description Language... 69 2.7.2 Architettura del WMS... 71 2.7.3 Logging & Bookkeeping Service... 74 2.7.4 Caratteristiche avanzate del WMS... 76 2.7.5 Schedulazione dei job nella attuale release del WMS... 78 Capitolo 3 Il simulatore DataGridSim... 84 3.1 La simulazione... 84 3.1.1 La simulazione multi-threaded tempo-discreta ad eventi... 84 3.1.2 Il linguaggio di programmazione e i tools utilizzati... 87 3.1.3 Meccanismo di simulazione... 88 3.2 Progetto del simulatore... 99 3.2.1 Concetti generali... 99 3.2.2 Il modello della rete... 101 3.2.3 Il modello dei Computing Element... 108 3.2.4 Il modello degli Storage Element... 122 4
INDICE 3.2.5 Il modello della gestione dei file... 129 3.3 Confronto con altri simulatori di griglie computazionali.... 131 3.3.1 Introduzione... 131 3.3.1 Bricks.... 132 3.3.2 MicroGrid.... 133 3.3.3 MONARC Simulator.... 133 3.3.4 GridSim... 134 3.3.5 Simgrid... 135 3.3.6 OptorSim... 136 3.3.7 ChicSim... 137 3.3.8 GriSim... 138 3.5 L interfaccia grafica... 139 Capitolo 4 Super-scheduling e replicazione dei dati in DataGrid... 144 4.1 Il livello della schedulazione nel simulatore... 144 4.2 Organizzazione delle risorse... 145 4.2.1 Il concetto di Virtual Organization e l organizzazione multi-tier dei siti 145 4.2.2 I servizi di DataGrid e la loro implementazione in simulazione... 149 4.3 La schedulazione su DataGrid... 159 4.3.1 Caratteristiche e obiettivi della schedulazione su griglie di dati... 159 4.3.2 Il Resource Broker e le politiche di scheduling... 161 4.3.3 Lo Storage Broker e le politiche di replicazione... 170 4.4 Simulazione e risultati... 172 4.4.1 Topologia e parametri di configurazione della DataGrid simulata.... 172 4.4.2 Misure e risultati delle simulazioni... 178 4.4.3 Effetti di variazioni parametriche... 190 Conclusioni... 193 Bibliografia... 194 Appendice A Codice Sorgente del Simulatore... 201 Indice delle figure... 202 Indice delle tabelle... 205 5
INTRODUZIONE INTRODUZIONE Il termine Griglia è stato coniato attorno alla metà degli anni Novanta, a denotare una infrastruttura di calcolo distribuito su scala geografica, essenzialmente orientata alle sperimentazioni scientifiche e ingegneristiche. Da allora questa definizione è stata estesa ad altri campi quali l intelligenza artificiale e il networking avanzato, sebbene con un certo abuso. In realtà, il vero e specifico problema alla base del concetto di Griglia è la condivisione coordinata di risorse all interno di una dinamica e multi-istituzionale organizzazione virtuale (Virtual Organization, brevemente indicata con VO) [1]. La condivisione non è limitata solo allo scambio dei file, ma si estende all accesso diretto a computer, al software, in generale a tutto l hardware necessario alla risoluzione di un problema scientifico, ingegneristico o industriale. Gli individui e le istituzioni che mettono a disposizione della griglia le loro risorse per la medesima finalità fanno parte della stessa VO. Un esempio molto esplicativo della necessità di raggruppare individui e risorse da loro offerte in organizzazioni virtuali è dato dal progetto EU-DataGrid [2], finanziato dalla Comunità Europea e finalizzato all allestimento di una infrastruttura di griglia di dati geograficamente estesa su tutta l Europa Unita. Vari esperimenti scientifici sono stati programmati [3] negli anni a venire su DataGrid, tra cui: 1. Fisica delle alte energie (HEP) come CMS, ATLAS, ALICE, e LHCb: rilevatori associati a vari esperimenti di collisioni tra particelle inizieranno a produrre a partire dal 2006 una enorme mole di dati (dell ordine di PetaBytes) per così dire grezzi che necessitano di essere analizzati e selezionati. 2. Osservazioni terrestri e spaziali: ogni giorno satelliti orbitanti inviano sulla Terra una quantità di dati attorno a 100 GB sotto forma di immagini, e questo numero è destinato sicuramente a salire in futuro, nasce dunque la necessità di immagazzinare e di conseguenza rendere accessibile ai fisici tutta l informazione raccolta. 3. Bio-Informatica, che comprende vari ambiti di ricerca, tra i quali il più interessante è l analisi del genoma umano. Ciascun progetto comunque presenta caratteristiche e necessità che lo differenziano dagli altri, ecco dunque che nasce la necessità di assegnare ciascun attività ad una VO distinta. Questo non preclude il fatto che se un istituzione o un individuo è coinvolto in più di una attività, esso possa appartenere a più VO. 6
INTRODUZIONE Caratteristica comune di questi progetti è la necessità di disporre un ambiente di calcolo data-intensive, nel quale le applicazioni hanno il bisogno di accedere a grandi quantità di dati geograficamente distribuiti in maniera veloce e affidabile, ed proprio è compito della DataGrid far operare queste applicazioni al meglio possibile. E facile osservare che nessun computer attuale sarebbe in grado da solo di elaborare simili moli di dati in tempi ragionevoli, tuttavia la condivisione di risorse quali CPU e dischi opportunamente coordinati può dare l impressione all utente di accedere ad un supercomputer virtuale, con una incredibile potenza computazionale e capacità di memorizzazione, in grado di sopportare grandi carichi di lavoro [4]. Non solo: attraverso la DataGrid, l utente può accedere a software non installato sulla sua workstation, e analizzare dati dall altro capo del mondo in modo molto più rapido. Basti pensare all efficienza e velocità derivanti dall eseguire la propria applicazione su una macchina sufficientemente potente (sicuramente più potente del proprio PC) scelta opportunamente vicina ai dati da utilizzare (vicinanza in termini di banda di trasmissione sufficiente a garantire buone prestazioni) in contrasto con l attuale procedura che consiste nello scaricare i dati da un sito remoto sulla propria macchina (lentamente, data la distanza notevole) e lanciare l applicazione sulla propria workstation, con l inconveniente aggiuntivo di doverla tenere sotto carico. Inoltre, spesso le applicazioni scientifiche abbisognano di particolari architetture di calcolo (multiprocessori paralleli, calcolatori vettoriali, ecc.) o strumenti di cui l utente non dispone fisicamente, ma ne può disporre virtualmente perché sono risorse condivise all interno della VO a cui appartiene. Dall idea di far apparire tutta l architettura di una DataGrid come un unico supercomputer virtuale, nascondendo all utilizzatore tutta la complessità interna ma mostrandogli solo i benefici, nasce l esigenza di progettare e realizzare uno schedulatore di risorse (Resource Broker, RB d ora in poi) [5][6]. Esso è uno dei componenti critici del sistema di gestione delle risorse, ha il compito di assegnare le risorse ai job in modo da soddisfare le esigenze delle applicazioni e del sistema. Le risorse di cui esso deve tenere traccia e gestire includono sistemi di calcolo, sistemi di immagazzinamento di dati (mediante lo Storage Broker [7]), la rete che li interconnette (mediante il Network Monitor). Lo scheduling è un campo tradizionale dell informatica ma, nonostante siano state studiate molte tecniche per numerosi tipi di sistemi, da uniprocessore a multiprocessore ai sistemi distribuiti, le caratteristiche tipiche delle griglie di dati 7
INTRODUZIONE rendono molti di questi approcci inadeguati. Infatti, mentre nei sistemi tradizionali le risorse e i job sono sotto il diretto controllo dello schedulatore, le risorse delle griglie sono geograficamente distribuite, sono di natura eterogenea e appartengono a diversi individui o organizzazioni, ciascuna con le proprie politiche di scheduling, modelli di costo di accesso differenti, carichi di lavoro e disponibilità di risorse che varia dinamicamente nel tempo. La mancanza di un controllo centralizzato, assieme alla presenza di utenti che generano job molto diversi l uno dall altro, rendono la schedulazione più complicata rispetto a quella dei sistemi di calcolo tradizionali. Queste considerazioni valgono per le griglie in generale, ma se consideriamo invece le griglie di dati, bisogna aggiungere che, pur essendo presenti in letteratura numerose politiche di scheduling per sistemi di macchine eterogenee, nessuna di queste può essere applicata al workload management system di una DataGrid: infatti, come su detto, è fondamentale in questo tipo di griglia garantire alle applicazioni un accesso veloce e affidabile ai dati, mentre nessuna di queste politiche tiene conto della disponibilità di rete, focalizzando la loro attenzione sulla risorsa CPU. L obiettivo di questa tesi è quello di studiare il comportamento e l efficienza (secondo metriche prestabilite, quali il makespan, il flowtime e il response time) di politiche di scheduling già esistenti in letteratura, tuttavia inadatte nella loro forma attuale all ambiente DataGrid: è necessario modificarle e integrarle con tecniche che tengano conto delle caratteristiche proprie di una griglia di dati, quali il network monitoring e il data replication. Infatti, da una parte, il monitoraggio della rete aiuta nel processo di scheduling del job sulle risorse computazionali, ottimizzando l accesso dell applicazione di griglia ai dati di input di cui ha bisogno. Una volta individuate le repliche migliori a cui il job schedulato su quella risorsa può accedere, la scelta della risorsa su cui schedulare il job avviene in base a tre politiche: i) assegnazione il job alla risorsa che meglio soddisfa i requisiti espressi dal job, mediante il Job Description Language; ii) assegnazione del job alla risorsa da cui esso può meglio accedere ai dati di input; iii) assegnazione del job alla risorsa in base ad una combinazione delle due precedenti politiche, che tenga conto sia dei requisiti del job sia della vicinanza dei dati. Questo tipo di ottimizzazione può essere ragionevolmente denominata di breve termine, dal momento che è essenzialmente orientata alle applicazioni anziché all intero sistema di griglia. Dall altra parte, l utilizzo di politiche di replicazione dinamica dei dati porta all ottimizzazione del sistema globale, quindi ad una ottimizzazione denominabile, a ragion veduta, di lungo termine. Una qualsiasi strategia di replicazione dei dati è, in 8
INTRODUZIONE generale, orientata all aumento delle prestazioni globali del sistema anziché delle singole applicazioni: come si vedrà nel corso della tesi, la schedulazione di un job prescinde dalla politica di replicazione utilizzata. La tendenza nelle griglie di dati, e quindi anche in DataGrid, è quella di tenere separati (disaccoppiati) il sistema di schedulazione dei job da quello di gestione dei dati: questa scelta, in DataGrid, è marcata dalla divisione dei due compiti tra due Work Package differenti (rispettivamente WP1 e WP2). Lo studio dell azione singola o combinata delle politiche di schedulazione e di replicazione è stato condotto mediante l uso di un simulatore di griglia realizzato ad hoc battezzato DataGridSim. Lo scopo di tale simulatore non è quello di riprodurre fedelmente il comportamento dei servizi e dei componenti di griglia: in passato si sono fatti tentativi di questo genere [58][60], però i risultati non sono stati mai soddisfacenti, in primo luogo perché il sistema simulato soffre di problemi di scalabilità (i simulatori realizzati, non riuscendo a riprodurre una vasta griglia, perdono di vista l obiettivo della simulazione, cioè riprodurre una griglia molto più vasta dei testbed disponibili), poi perché tali simulatori, sebbene riproducano fedelmente il funzionamento della griglia, si rivelano ardui da usare per lo studio di politiche di scheduling e replicazione di dati, dato l alto numero di parametri e la scarsa duttilità. Queste e altre motivazioni hanno portato alla decisione di realizzare un simulatore ex-novo anziché utilizzarne uno già esistente. DataGridSim ha come scopo principale la simulazione della condivisione delle risorse in un ambiente DataGrid. Questa caratteristica lo rende adatto allo studio di politiche di scheduling e di replicazione dei dati, giacché sono facilmente effettuabili misure di tempi di esecuzione e di carico sui nodi della griglia. La tesi è organizzata in questo modo: nei capitoli 1 e 2 è fornita una analisi approfondita delle problematiche, e delle soluzioni ad esse, rispettivamente nei sistemi a griglia in generale e nel progetto EU-DataGrid, verso cui la tesi stessa è orientata; il capitolo 3 è interamente dedicato al simulatore DataGridSim, di cui se ne illustrano le caratteristiche, l uso e anche un confronto con altri analoghi simulatori; nel capitolo conclusivo, il quarto, è illustrata, nella prima parte, l architettura proposta dell architettura di schedulazione e dei servizi di DataGrid, nella seconda invece sono discusse le politiche sia di schedulazione che di replicazione dei dati, fornendo anche i risultati delle simulazioni effettuate. 9
CAP. 1: CARATTERISTICHE GENERALI DELLE GRIGLIE CAPITOLO 1 CARATTERISTICHE GENERALI DELLE GRIGLIE In questo capitolo si cerca di fornire una panoramica abbastanza completa del lavoro di standardizzazione e uniformazione del concetto di griglia che si svolge in questi anni da parte di vari gruppi di ricercatori, coordinati dal Global Grid Forum (GGF) [29]. Infatti, l idea della griglia è un concetto sufficientemente nuovo, dunque è mancato materialmente il tempo per una razionalizzazione che invece è stata fornita ad altri argomenti del ramo del computing. A giustificazione di questa mancanza c è il fatto che finora nessun progetto di griglia è passato alla fase di produzione, al più si è arrivati alla realizzazione di piccoli e medi testbed, ben lontani però dalle dimensioni finali che si ipotizzano per un sistema Grid, quindi tutti i risultati ad oggi ottenuti sono sperimentali o addirittura solamente simulati. All interno di questa panoramica, particolare attenzione viene data al cuore della Griglia, il Resource Management System, componente o servizio che si occupa della gestione delle risorse partecipanti alla Griglia. 1.1. Definizione di Griglia Una Griglia è un sistema distribuito di network computing su larghissima scala [8], che può essere scalato alle dimensioni dell ambiente Internet con macchine distribuite tra molte organizzazioni e domini amministrativi [6]. Il concetto di Griglia nacque come progetto di collegamento di siti con supercomputer, ma ora è di gran lunga cresciuto oltre l intento originale. Infatti, sono tante le applicazioni che possono trarre beneficio da una infrastruttura a griglia, tra queste ricordiamo collaborative engineering, data exploration, high throughput computing, e naturalmente distributed supercomputing. Costruire una Griglia richiede lo sviluppo e l installazione di un certo numero di servizi, quali il resource discovery (servizio di individuazione e selezione delle risorse partecipanti all allestimento della Griglia), il resource management (servizio di gestione dei job, cioè le applicazioni utente, e delle risorse) e la sicurezza (questo servizio deve garantire un accesso autorizzato ed autenticato dell utente alle risorse). Dunque la Griglia non è solo un modello di architettura per fornire risorse computazionali per applicazioni con grandi esigenze di calcolo, ma è una infrastruttura che può collegare e unificare tra loro risorse estremamente eterogenee distribuite su 10
CAP. 1: CARATTERISTICHE GENERALI DELLE GRIGLIE tutto il globo terrestre. Ci sono cinque obiettivi che una Griglia deve perseguire per poter meritarsi questo nome [4][11]: L eterogeneità: una griglia coinvolge risorse eterogenee per natura sparse su vari domini amministrativi distribuiti su distanze geografiche. La scalabilità: una griglia può includere da poche a milioni di risorse, e ciò comporta il problema della potenziale degradazione delle prestazioni; per questo le applicazioni grid-enabled devono essere progettate per essere tolleranti alla latenza dovuta ai collegamenti su distanza geografica. La dinamicità o adattabilità: in una griglia il guasto di una risorsa è una regola, non un eccezione! Infatti, il gran numero di risorse rende la probabilità di guasto conseguentemente alta. Dunque sia i servizi offerti dalla griglia, sia le applicazioni orientate alla griglia devono avere un comportamento dinamico per ottenere la massima prestazione dalle risorse attualmente disponibili, senza far riferimento a risorse statiche potenzialmente soggette a guasti. La politica di riparazione di un guasto va dalla notifica al resto della griglia che la risorsa non è più disponibile al trasferimento del checkpoint di una attività in un altro nodo della griglia. L estensibilità: questa proprietà viene garantita nel momento in cui si adotta una progettazione modulare; le varie parti o moduli sono progettati in maniera indipendente l uno dall altro e comunicano mediante precisi e ben documentati protocolli o API. Questo modus operandi crea due vantaggi: 1) diventa facile sostituire un modulo con uno completamente nuovo, oppure semplicemente aggiornarlo, senza dover reinstallare l intera architettura (l aggiornamento o sostituzione va fatto solo sui nodi interessati e con estrema rapidità); 2) si rende la griglia altamente adattabile alle esigenze degli utenti e al loro carico di lavoro, per esempio, è sufficiente commutare su un altro modulo all interno dell RB per cambiare politica di schedulazione. L autonomia del sito: tenendo a mente eterogeneità delle risorse, la condivisione di proprie risorse all interno di una VO non deve andare a intaccare la loro normale amministrazione e quindi autonomia; in altre parole la partecipazione di un sito alla Griglia non deve intaccare gli esistenti sistemi di sicurezza, autenticazione, gestione delle risorse e degli utenti; ancora, la griglia non impone nessuno stravolgimento alla configurazione del sito, ma solamente propone norme da seguire anche in maniera lasca per utilizzare la griglia e condividere le proprie risorse al meglio [1]. 11
CAP. 1: CARATTERISTICHE GENERALI DELLE GRIGLIE Le cinque caratteristiche di una griglia su elencate possono essere implementate seguendo i seguenti passi: 1. L integrazione dei componenti individuali hardware e software in una risorsa di rete: questo comporta in primo luogo la definizione di un linguaggio di descrizione della risorsa, che possa astrarla dal livello fisico con un certo livello di dettaglio e renderla catalogabile e pubblicabile all interno dell information service (esempi sono il Condor ClassAd [14] e il LDAP [24], spiegati più avanti); in secondo luogo l implementazione di gestori della risorsa, che fanno da tramite tra i protocolli standard di griglia e l architettura della risorsa. Ad esempio, nel caso di sistemi di calcolo, il gestore della risorsa da un lato si interfaccia al protocollo di griglia, dall altro traduce i messaggi in comandi per i gestori locali (LRMS, acronimo di Local Resource Management Systems) quali LSF, PBS e Condor per cluster di workstation oppure la semplice chiamata fork() di Unix nel caso di singola workstation o PC; nel caso di altri tipi di risorse, possono essere interfacce verso il software di gestione di sensori o radiotelescopi, o interfacce verso database o file server quali NFS, AFS per i dischi e HPSS per i nastri. 2. L implementazione di un middleware (software basato su infrastrutture già esistenti) che provvede ad una visione trasparente delle risorse disponibili, assieme allo sviluppo di strumenti che permettono la gestione e il controllo delle applicazioni e delle infrastrutture di griglia e lo sviluppo e l ottimizzazione delle applicazioni distribuite, al fine di ottenere vantaggi dalle risorse. APPLICAZIONI Scientifiche Web Applications Ingegneristiche... AMBIENTI DI SVILUPPO E STRUMENTI Linguaggi Web Tools Librerie Monitoring Scheduler... SERVIZI DI ACCOPPIAMENTO DELLE RISORSE DISTRIBUITE Comunicazioni Sicurezza Informazioni Accesso ai dati QoS Applications Tools Middleware LOCAL RESOURCE MANAGERS Operating System Queuing Librerie e Kernel delle System applicazioni RISORSE DISTRIBUITE INTERNE ALLE ORGANIZZAZIONI Computer Cluster Storage Data Sources Systems TCP/IP & UDP Strumenti Scientifici Figura 1.1: Componenti di una Griglia Fabric 12
CAP. 1: CARATTERISTICHE GENERALI DELLE GRIGLIE Nella figura 1.1 si possono osservare i componenti principali della griglia, secondo una architettura a strati, di cui si dà ora la descrizione: Livello Fabric: esso raggruppa tutte le risorse hardware e software messe a disposizione della infrastruttura di griglia. Si osservi che non tutte le risorse fisiche di un sito possono apparire in questo livello: l amministratore può scegliere di non mettere a disposizione della VO di appartenenza alcune risorse per motivi di costo, sicurezza, ecc., e tali risorse risultano essere inesistenti e inaccessibili per la griglia. Livello Middleware: è il cuore della griglia, raggruppa l insieme dei protocolli, dei servizi di base (quali il controllo remoto dei processi, accesso alle risorse di memorizzazione, la sicurezza, l autenticazione, la fornitura di QoS mediante prenotazione delle risorse, la co-allocazione, la gestione delle informazioni ) e delle interfacce tra griglia e risorse del livello fabric (di cui si è parlato prima). Come suggerisce il nome, il livello Middleware mostra come l intera infrastruttura di griglia si poggia su architetture già esistenti: non tenta di sostituirsi ai gestori locali delle risorse, come sistemi operativi, scheduler di cluster, driver e protocolli di dischi, nastri e apparecchiature scientifiche, ma si integra con essi, creando così un utente virtuale che si affianca agli utenti fisici sul campo. D altra parte, il tentativo di creare un sistema di calcolo e condivisione di file su larghissima scala come Internet, non può che portare a questa scelta, piuttosto che a quella di progettare un sistema operativo distribuito tradizionale, che abbisogna di proprie risorse quali computer e linee di trasmissione dedicati. Questa direzione non è indolore: infatti lo sviluppatore di software per griglia si trova a dover interagire con hardware e software spesso mancante di documentazione accettabile, oppure non conforme a standard, oppure, ancora, non pienamente soddisfacente le proprie esigenze. Livello Tools: a questo strato la Griglia offre servizi di alto livello, quali il servizio di informazione (tiene traccia di tutti gli utenti e le risorse attualmente presenti e operanti sulla griglia, fornendo dati anche sul loro stato e carico di lavoro); il servizio di logging, indispensabile sia a livello utente (per mantenere traccia della propria attività sulla griglia), che a livello amministrativo (per effettuare analisi statistiche di workload e utilizzo delle risorse, ma soprattutto per rendere il sistema di griglia fault tolerant: infatti, un robusto servizio di logging garantisce la ripresa delle attività in modo trasparente all utente in caso di guasto di una risorsa; tale ripresa può essere effettuata sulla stessa risorsa, se è in grado di ripartire, oppure su un altra risorsa, dopo aver richiamato in automatico il servizio di brokering); il 13
CAP. 1: CARATTERISTICHE GENERALI DELLE GRIGLIE servizio di catalogo e management delle repliche di file e oggetti, che assume un ruolo fondamentale nelle DataGrid; i vari servizi di brokering delle risorse, che vanno dallo schedulatore dei job, agli storage broker (che si occupa delle risorse di immagazzinamento dati) e bandwidth broker (che si occupa della gestione della rete, principalmente di soddisfare richieste di QoS). Oltre a ciò, a questo livello si collocano tutte le librerie grid-enabled, cioè librerie di programmazione che aiutano l utente a interfacciare la propria applicazione con la griglia: l esempio più calzante è quello della sostituzione della chiamata a sistema operativo open() per l apertura di un file locale, con una ipotetica grid_open() che permette di accedere ad un file remoto presente su una risorsa di griglia, nascondendo così tutti i dettagli di basso livello, come i protocolli di comunicazione, all utente della griglia, che spesso è un ricercatore scientifico ed è poco interessato al funzionamento del sistema di griglia. Tutto quello che deve fare è ricompilare il proprio programma utilizzando le librerie grid-enabled al posto delle tradizionali librerie: questo rientra nella finalità di far apparire la griglia come un supercomputer virtuale. Tuttavia, una applicazione non orientata alla griglia (ossia che non è stata linkata con librerie grid-enabled) è comunque utilizzabile: infatti, meccanismi di data caching permettono l uso delle applicazioni tradizionali anche in remoto. Livello Applications: a questo livello si pongono tutte le applicazioni ingegneristiche e scientifiche che hanno bisogno della griglia per ottenere risultati, come le applicazioni high-throughput (simulazioni su vasta scala e studi parametrici); tali applicazioni possono avere un forte grado di parallelismo, oppure agiscono su un incredibile mole di dati (data-intensive), superiori a quelle di qualsiasi singola unità di memorizzazione, oppure interagiscono in modo remoto con strumenti scientifici costosi o non facilmente trasportabili (come radiotelescopi). Un notevole contributo allo sviluppo dei livelli middleware e tools è venuto dal progetto Globus [9][10]: il Globus Toolkit è un insieme di servizi di alto e basso livello, con la notevole caratteristica di essere costruiti in modo modulare con i moduli indipendenti e che espongono una interfaccia API ben documentata. Ciascun modulo offre un servizio differente e autonomo: si va dai servizi di basso livello come la sicurezza, l autenticazione e il trasporto di dati sulla rete, a servizi di più alto livello, come servizi di directory, di gestione delle repliche fino allo scheduling dei jobs. Il successo di questo toolkit è dovuto proprio a questa proprietà: i progettisti grid possono 14
CAP. 1: CARATTERISTICHE GENERALI DELLE GRIGLIE scegliere quali moduli utilizzare e quali scartare perché non a loro congeniali senza troppe complicazioni (solitamente la scelta ricade sui moduli di basso livello, in modo da risparmiare tempo e soldi nella progettazione di qualcosa di già esistente e già funzionante, impegnando le loro risorse sui servizi di griglia di livello tools, che sono ancora un problema aperto). Analizzeremo più avanti la struttura di Globus, nella trattazione dell EU-DataGrid, di cui il Globus Toolkit è un importante componente. Nella progettazione di una griglia è necessario seguire una serie di principi di base, al fine di facilitare la coesione di risorse eterogenee ed autonome [4]: L ambiente griglia non deve interferire con l amministrazione e l autonomia del sito; Non deve compromettere la sicurezza degli utenti e dei siti; Non deve sostituirsi ai sistemi operativi e ai protocolli di rete già presenti; Deve permettere sempre ad un sito di connettersi o sconnettersi dalla rete quando vuole; Deve provvedere ad una infrastruttura affidabile e fault tolerant con nessun punto debole; Deve utilizzare gli standard già presenti; Deve fornire agli sviluppatori di software librerie grid-enabled. 1.2 Architettura di Griglia Nella definizione di un architettura di griglia occorre porre attenzione al problema centrale dell interoperabilità intesa come capacità di stabilire relazioni condivise tra tutti i potenziali partecipanti alla Griglia, anche se questa definizione può essere ristretta senza perdere significato ai partecipanti ad una stessa VO (l interoperabilità tra VO non è strettamente necessaria). In un ambiente di rete, l interoperabilità vuol dire adozione di protocolli comuni. Dunque, l architettura di Griglia è prima e principalmente un architettura di protocolli, dove per protocolli si intendono i meccanismi di base con cui gli utenti e le risorse di una VO negoziano, gestiscono e sfruttano le condivisioni. Il messaggio contenuto in [1] e recepito dal Global Grid Forum [29] è l invito a spostare l attenzione del progettista Grid dal livello interno (software, caratteristiche delle risorse) al livello esterno (interazioni): il motivo sta nel fatto che le VO sono estremamente mutevoli, donde la necessità che la condivisione sia supportata da protocolli leggeri e flessibili, che facciano forti astrazioni sulle caratteristica della risorsa piuttosto che dettagliarla pesantemente. Protocolli con 15
CAP. 1: CARATTERISTICHE GENERALI DELLE GRIGLIE queste proprietà si prestano ad un efficiente resource discovery. Inoltre, dal momento che i protocolli gestiscono le interazioni tra componenti e non la loro implementazione, l autonomia (proprietà richiesta ad una griglia, come suddetto) è garantita: ciascun sito può scegliere una diversa implementazione del protocollo. L architettura proposta in [1] e riportata graficamente della figura 2.1 può essere definita a strati: ciascuno strato raggruppa protocolli specifici di quel livello, i quali possono interagire con protocolli di livello inferiore, il viceversa non può accadere. Gli strati hanno dimensioni differenti per sottolineare un preciso obiettivo da conseguire: man mano che si sale dal livello inferiore a quello superiore è auspicabile che il numero di protocolli vada diminuendo. Infatti, lo scopo ultimo è quello di arrivare a pochi protocolli che possano astrarre in maniera soddisfacente tutte le risorse attive sulla Griglia. Applications Collective Resource Connectivity Fabric Figura 2.1: Architettura di Protocolli per una Griglia Computazionale 2.1 Livello Fabric: Risorse delle Griglie Computazionali Il livello Fabric è composto dalle risorse della Griglia, caratterizzate da tre aspetti: i) estrema eterogeneità anche nella tipologia; ii) appartenenza ad amministrazioni differenti; iii) distribuzione su larga scala. Accanto a computer, supercomputer e database quindi, possiamo trovare altri strumenti scientifici come microscopi, radiotelescopi e sensori. L appartenenza delle risorse a domini amministrativi differenti è una 16
CAP. 1: CARATTERISTICHE GENERALI DELLE GRIGLIE caratteristica derivante dalla collaboratività dell ambiente: infatti ogni Virtual Organization mette a disposizione degli altri le proprie risorse ma ne mantiene sia la proprietà che l amministrazione, ognuna di esse quindi, ha piena libertà nella gestione. 2.2 Livello Connectivity: Comunicazione fra le Risorse Nel livello Connectivity si trovano i protocolli di comunicazione che permettono alle diverse componenti del livello Fabric di scambiarsi dati ed informazioni. Questi protocolli devono permettere il trasporto, l instradamento e l assegnazione di nomi ai diversi nodi. Naturalmente, dal momento che le griglie si basano su infrastrutture già esistenti e diffuse (è il concetto di middleware) sono adoperati gli standard de facto affermatisi con Internet, cioè i protocolli IP, TCP, UDP e DNS. 2.3 Livello Resource: Accesso alle Risorse Il livello Resource si preoccupa di rendere uniforme l accesso a risorse eterogenee, ossia crea risorse logiche uniformi adoperando quelle del livello Fabric. I componenti di questo livello possono essere suddivisi in due categorie: Sistemi informativi: forniscono informazioni sulla struttura e lo stato di una risorsa, come ad esempio la sua configurazione, il carico e le politiche d utilizzo. Sistemi di gestione: permettono l accesso e l utilizzo condiviso delle risorse, nel rispetto delle politiche d accesso stabilite dall amministrazione locale. 2.4 Livello Collective: Coordinazione delle Risorse Se il livello Resource permette l accesso ad una risorsa, il livello Collective contiene i servizi che permettono l utilizzo e la coordinazione di più risorse. I servizi di questo livello si distinguono in: Servizi di indicizzazione: permettono di scoprire l esistenza di risorse, dando la possibilità di effettuare ricerche per nome, per attributi come la tipologia, la disponibilità, il carico. Servizi di co-allocazione, scheduling e brokering: permettono l allocazione di una o più risorse pianificando l esecuzione di job. Servizi di replicazione dati: permettono la gestione dei dati realizzando meccanismi come la replicazione, che incrementano le prestazioni nell accesso ai dati, in base a metriche come il tempo di risposta, il costo e l affidabilità. 17
CAP. 1: CARATTERISTICHE GENERALI DELLE GRIGLIE Servizi di individuazione del software: permettono la scelta della miglior implementazione software e della miglior piattaforma d esecuzione. 2.5 Livello Application: Applicazioni delle Griglie Computazionali Il livello Application è costituito dagli strumenti (linguaggi, librerie, compilatori) che permettono la realizzazione di applicazioni Grid e dalle stesse applicazioni. Le applicazioni che più si avvantaggiano dell ambiente di griglia sono quelle che sfruttano: Supercalcolo distribuito: è necessario tutte le volte che la complessità dell applicazione rende improponibile la sua esecuzione su un unico elaboratore. Elaborazione high-throughput: con l elaborazione high-throghput si cerca di pianificare l esecuzione di un gran numero di job debolmente correlati, in modo da adoperare la potenza computazionale degli elaboratori temporaneamente inutilizzati. Elaborazione on-demand: l elaborazione on-demand viene adoperata ogniqualvolta c è la necessità di una gran potenza computazionale per un breve periodo di tempo, senza dover acquistare gli elaboratori necessari. Elaborazione data-intensive: le applicazioni data-intensive sintetizzano nuove informazioni partendo dai dati conservati in database distribuiti geograficamente. Ad esempio, durante un esperimento di fisica delle alte energie vengono raccolti un terabyte (1 TB 1.100 10 12 byte) di dati al giorno, che corrispondono a circa mezzo petabyte (1 PB 1.126 10 15 byte) l anno e le applicazioni d analisi accedono ad una considerevole frazione di questi dati, alla ricerca di eventi interessanti. Nella figura 3.1 si osserva un riassunto grafico dell architettura appena esaminata. 18
CAP. 1: CARATTERISTICHE GENERALI DELLE GRIGLIE APPLICATION COLLECTIVE RESOURCE CONNECTIVITY FABRIC Supercalcolo Distribuito, Highthroughput, On-demand, Data-intensive Linguaggi, Librerie, Compilatori Resource Discovery, Co-allocazione, Scheduling, Brokering, Replicazione dei Dati, Individuazione del Software Monitoraggio e Gestione delle Risorse Protocolli di Comunicazione, Meccanismi di Autenticazione Sistemi Operativi, Sistemi Operativi di Rete, Protocolli di Comunicazione, Database, Supercomputer, Workstation, PC, Reti, Microscopi, Radiotelescopi, Satelliti, Sensori Figura 3.1: Architettura di Griglia 1.3 Tassonomia di una Griglia Nella Figura 4.1 possiamo osservare la tassonomia di un sistema a griglia secondo [6]. L architettura di una griglia è motivata dagli obiettivi di progetto e dalle applicazioni di riferimento che devono utilizzare il sistema. Si possono trovare tre principali obiettivi di progetto: i) aumentare le prestazioni delle applicazioni, ii) favorire l accesso ai dati, iii) potenziare servizi nuovi o già esistenti. Alla luce di questi scopi, la tassonomia proposta divide le griglie rispettivamente in tre grandi categorie: le griglie computazionali, le griglie di dati e le griglie di servizi. 19
CAP. 1: CARATTERISTICHE GENERALI DELLE GRIGLIE Sistemi a Griglia Griglie Computazionali Griglie di Dati Griglie di Servizi Supercomputing High Throughput On-demand Multimediale Collaborativa Figura 4.1: Tassonomia dei sistemi a Griglia La categoria delle Griglie Computazionali (Computational Grids) individua sistemi che hanno una potenza di calcolo disponibile per una singola applicazione maggiore della potenza di ogni singola macchina che costituisce la griglia. In funzione di come questa potenza è utilizzata, questi sistemi si possono distinguere in sistemi distribuiti di supercomputing e high throughput. Un sistema distribuito di supercomputing esegue l applicazione in parallelo (previa opportuna parallelizzazione del codice) per ridurre il tempo di completamento di un job: esempi di questo tipo di necessità sono il modellamento dei fenomeni meteorologici e le simulazioni nucleari. Un ambiente high throughput, invece, tende a massimizzare un altra metrica di prestazioni, il tasso di completamento di un flusso di jobs (makespan e flowtime). Esempi tipici sono le applicazioni parameter-sweep, in cui è necessario eseguire sempre gli stessi calcoli sullo stesso set di dati, cambiando volta per volta alcuni parametri: in genere le simulazioni hanno questa prerogativa (come le simulazioni montecarlo). Le Griglie di Dati (Data Grids) sono sistemi che forniscono un infrastruttura per sintetizzare nuove informazioni dai data repositories, librerie digitali o banche dati largamente distribuite. Anche le griglie computazionali forniscono dei servizi per la gestione dei dati, ma la differenza maggiore tra le griglie di dati e quelle computazionali sta nella infrastruttura specializzata, fornita alle applicazioni per gestire l archiviazione e l accesso ai dati. In una Griglia Computazionale ogni applicazione implementa il proprio data management system piuttosto che usare dei servizi forniti dalla griglia. Infine, le Griglie di servizi (Service Grids) sono sistemi che forniscono servizi che non vengono forniti da singole macchine. Questa categoria si può suddividere 20
CAP. 1: CARATTERISTICHE GENERALI DELLE GRIGLIE ancora in: on-demand, collaborative e multimediali. Una griglia collaborativa connette utenti e applicazioni in gruppi di lavoro collaborativi, permettendo l interazione realtime fra gli utenti e le applicazioni tramite uno spazio di lavoro virtuale. Una griglia ondemand aggrega dinamicamente risorse differenti per fornire nuovi servizi. Infine una griglia multimediale fornisce una infrastruttura per applicazioni multimediali real-time: è quindi indispensabile che tale tipo di griglia supporti servizi di QoS tra le molteplici macchine geograficamente distribuite. Le tre categorie di griglia appena descritte rappresentano al meglio gli obiettivi dei progetti attualmente in lavorazione da parte di gruppi di ricerca in tutto il mondo. Ovviamente il sogno è quello di sviluppare un sistema a griglia veramente generalpurpose, ma tanti sono i problemi, a partire da quello dell ottimizzazione delle applicazioni a seconda delle richieste dell utente: è stato dimostrato [12] che è impossibile ottimizzare contemporaneamente il tempo di risposta di ciascuna applicazione e il throughput di tutte le applicazioni, anzi le due metriche sono antitetiche, l ottimizzazione di una va a scapito dell altra. Bisogna allora rinunciare all attuazione di una griglia general o multi-purpose? La risposta è negativa. Infatti, la necessità di mantenere l architettura di griglia modulare [11] si sposa bene con il concetto di Virtual Organization [1]: è possibile quindi che ciascuna VO adotti un proprio sistema di resource management o, meglio, che lo stesso servizio di gestione delle risorse si adatti alle esigenze degli utenti appartenenti alla stessa VO senza reinventare la ruota, semplicemente cambiando un modulo dell architettura. In questa soluzione al problema rientra l idea del community scheduler proposto in [5], quindi alla base del WMS (workload management system) di EU-DataGrid. 1.4 Definizione e requisiti del Workload Management System È chiaramente fondamentale la gestione di risorse quali i processori, la memoria, la rete, i dispositivi di memorizzazione, e le altre risorse in una griglia computazionale. Il Workload Management System (WMS) [13] è la parte del middleware di Griglia che ha il compito di amministrare le risorse al fine di eseguire le applicazioni in maniera conveniente, efficiente ed effettiva. Per svolgere questo compito, il WMS (spesso definito anche Resource Management System, RMS in breve) interagisce con gli altri componenti del Grid-middleware, come il security module che esegue l autenticazione degli utenti e gestisce le loro autorizzazioni, e il resource access 21
CAP. 1: CARATTERISTICHE GENERALI DELLE GRIGLIE module che fornisce l interfaccia al gestore locale delle risorse (come sistemi a coda di job e sistemi operativi [31]). Dal punto di vista dell utente, la gestione delle risorse è completamente trasparente, nel senso che la sua interazione con il WMS è limitata alla sola descrizione, attraverso un linguaggio di alto livello (come ClassAd di Condor [14]), dei requisiti sulle risorse sui cui devono essere eseguiti i propri job. È compito del WMS tradurre questi requisiti astratti sulle risorse in un insieme di risorse conformi, estratte dall intero set di risorse di griglie, alle quali l utente ha il permesso di accesso. Tipicamente un WMS è composto da tre moduli principali: lo user access module, il resource information module, e il resource handling module. Quest ultimo assolve al compito di allocare, reclamare e identificare la risorsa. L allocazione è la funzione di identificare una o più risorse che meglio rispondono ai requisiti del job, senza violare possibili limiti della risorsa, e di monitorare l esecuzione del job su queste risorse. La reclamazione è la funzione di richiamare la risorsa quando il job che la stava usando termina la sua esecuzione. Infine, identificare la risorsa vuol dire ad assegnare nomi simbolici alle risorse in modo tale che jobs e schedulatori possono identificare le risorse necessarie a eseguire il calcolo. A tal fine il resource handling module accede individualmente alle risorse di griglia interagendo con i gestori locali tramite interfacce predefinite. Esso interagisce strettamente col resource information module, il cui scopo è quello di collezionare e pubblicare informazioni riguardo l identità, le caratteristiche e lo stato delle risorse, cosicché possono essere prese efficaci decisioni di schedulazione. Il resource information module fornisce agevolazioni sia in fase di resource dissemination sia in fase di resource discovery. Il servizio di resource dissemination fornisce informazioni sulla disponibilità delle risorse, ed è usato dalla risorsa stessa per notificare la sua presenza sulla griglia, in modo che possa essere utilizzata dalle applicazioni. Il resource discovery è, invece, il meccanismo per cui le informazioni sulle risorse di griglia disponibili vengono esaminate dallo scheduler alla ricerca di un insieme di risorse conforme ai requisiti dell applicazione utente. Infine, lo user access module fornisce agli utenti il servizio di accesso al cuore del WMS, cioè il resource handling module. I requisiti dell applicazione sono formulati attraverso un job description language che viene sottoposto da questo modulo ad un procedimento di parsing, che traduce questo linguaggio in uno di più basso livello, interno al WMS. Solitamente questo modulo fornisce un interfaccia utente, che include comandi per iniziare, terminare e monitorare l esecuzione di un job. 22
CAP. 1: CARATTERISTICHE GENERALI DELLE GRIGLIE 1.5 Tassonomia di un Resource Management System Possiamo caratterizzare un sistema di gestione delle risorse focalizzando la nostra attenzione su: organizzazione delle macchine, modello delle risorse, protocollo di disseminazione, organizzazione del namespace, organizzazione dei data storage, resource discovery, supporto QoS, organizzazione dello scheduler, politiche di scheduling, stima dello stato e rescheduling [6]. 1.5.1 Organizzazione delle macchine Piatta Organizzazione A celle Gerarchica A celle piatte A celle gerarchiche Figura 5.1: Organizzazione delle macchine L organizzazione delle macchine nelle griglie influenza il modello delle comunicazioni del RMS e quindi la scalabilità della architettura che ne deriva. La tassonomia presentata in figura 5.1 è peculiare dei sistemi a griglia. In una organizzazione flat tutte le macchine possono comunicare l una con l altra senza intermediari. In una organizzazione gerarchica le macchine dello stesso livello possono comunicare direttamente con le macchine dello stesso livello, un livello sopra o un livello sotto nella scala gerarchica. In una struttura a celle le macchine appartenenti alla stessa cella comunicano fra loro in modo flat. Alcune macchine nella cella si occupano della comunicazione verso l esterno. La struttura interna di una cella non è visibile dall esterno. Una griglia che ha le una struttura a celle flat ha un solo livello, mentre quelle con struttura a celle gerarchica possono avere celle che contengono altre celle. La maggiore differenza fra una struttura a celle e una struttura gerarchica è che una struttura a celle ha dei confini limitati, con una struttura interna non visibile, mentre in una struttura gerarchica la struttura della gerarchia è pienamente visibile a tutti i 23
CAP. 1: CARATTERISTICHE GENERALI DELLE GRIGLIE componenti della griglia. 1.5.2 Modello delle Risorse Estensibile Oggetti Modello delle Risorse Fisso Estensibile Schema Fisso Figura 6.1: Modello delle Risorse Il modello delle risorse indica come le applicazioni e il RMS descrivono le risorse della griglia (Figura 6.1). La tassonomia presentata focalizza l attenzione su come vengono descritte le risorse e le operazioni su di esse. In un approccio a schema, la risorsa viene descritta con un linguaggio opportuno. In alcuni sistemi, viene aggiunto un linguaggio di query nel linguaggio dello schema. In uno schema estensibile nuovi tipi possono essere aggiunti per descrivere la risorsa. In un modello ad oggetti le operazioni sulla risorsa sono parte del modello delle risorse stesse. Anche questo modello può essere estensibile o fisso. Nel caso l approccio sia ad oggetti ed estensibile, viene fornito anche un meccanismo per estendere la definizione dell oggetto gestito dal RMS. 1.5.3 Organizzazione del Namespace delle risorse Il RMS di una Griglia lavora su un pool di risorse che hanno dei nomi globali. L organizzazione del namespace (Figura 7.1), che può essere creato e gestito da un entità esterna al RMS, influenza notevolmente il progetto dei protocolli di gestione delle risorse e condiziona i metodi di scoperta delle risorse. 24
CAP. 1: CARATTERISTICHE GENERALI DELLE GRIGLIE Relazionale Namespace delle Risorse Gerarchico Ibrido A grafo Figura 7.1: Organizzazione del Namespace delle Risorse Un namespace relazionale divide le risorse in relazioni e usa le metodologie dei database relazionali. Un namespace gerarchico divide le risorse della griglia in gerarchie. Le gerarchie sono tipicamente organizzate sulla base della struttura fisica o logica delle reti. Il namespace ibrido consiste in relazioni ma il contenuto delle relazioni sono spezzate in un ordine gerarchico al fine di distribuirle sulle macchine della griglia. Un namespace basato sui grafi usa nodi e puntatori dove i nodi possono o meno essere entità complesse. 1.5.4 Qualità del Servizio (QoS) Nei sistemi a griglia il QoS non è limitato alla larghezza di banda della rete ma si estende alla capacità di calcolo e di archiviazione dei nodi. Se le applicazioni hanno esigenze particolari in termini di tempo è necessario calcolare il QoS totale piuttosto che fornire solo quello relativo alla rete, inoltre la scelta delle risorse da utilizzate risulterà fortemente vincolata da questo. Nessuno Supporto QoS Hard Soft Figura 8.1: Supporto QoS Il QoS è di tipo soft se il RMS fornisce i dati circa il QoS di una risorsa ma non garantisce che sia rispettato, di tipo Hard se garantisce che il QoS dichiarato venga 25
CAP. 1: CARATTERISTICHE GENERALI DELLE GRIGLIE rispettato. 1.5.5 Resource Discovery La scelta delle risorse da utilizzare parte dalla ricerca delle risorse disponibili e adatte allo scopo, tale ricerca va sotto il nome di resource discovery (figura 9.1). I sistemi basati su query si differenziano per il fatto che le richieste possono essere inviate ad un unico database centralizzato o ad uno distribuito. Query Centralizzata Resource Discovery Agenti Distribuita Figura 9.1: Resource Discovery La maggior differenza tra un approccio basato su query e uno basato su agenti sta nel fatto che quello basato su agenti può utilizzare una sua logica, piuttosto che usare una funzione fissa del meccanismo di query, al limite un agente può comportarsi anche come una query. 1.5.6 Resource Dissemination Per dissemination ci riferiamo all operazione che compiono le risorse comunicando la loro disponibilità ad essere utilizzate (figura 10.1). L aggiornamento dei database, gli stessi usati per il resource discovery, può avvenire su base periodica o su richiesta. Quelli su base periodica si differenziano in push e pull a seconda che le informazioni vengano inviate dalla risorsa al sistema o vengano richieste dal sistema. Nei sistemi on-line/on-demand le informazioni vengono inviate (push) immediatamente dalla macchina che le origina al sistema. 26