La gestione di grosse quantità di dati [60], [61] è un problema tipico delle Grid vista la necessità di trasferire i dati da elaborare verso le risorse di calcolo e quindi raccogliere gli output elaborati o semplicemente consentire il rapido accesso a gigabyte o terabyte di informazioni.
Le Grid vengono utilizzate per le applicazioni di tipo high- performance e/o "data intensive", cioè quelle applicazioni che lavorano su un insieme molto grande di dati (dell'ordine dei terabyte o petabyte) che devono essere reperiti e trasferiti in ambiente distribuito molto esteso (reti geografiche). Esempi di queste applicazioni includono analisi di esperimenti effettuati in laboratorio e simulazioni come ad esempio esperimenti di fisica effettuati con simulatori ed acceleratori, modellizzazione del clima, studio dei fenomeni della Terra, esperimenti nel campo dell'astronomia. A questi esperimenti partecipano numerosi centri di ricerca che, con migliaia di ricercatori sparsi in tutto il mondo, devono condividere enormi quantità di dati per effettuare i loro esperimenti e confrontarne i risultati. Le datagrid forniscono quindi un'infrastruttura per queste applicazioni e servizi fondamentali per la gestione delle stesse. Tra questi servizi uno molto importante è quello di gestione della replicazione dei dati. Vista l'enorme quantità di dati che si devono gestire con applicazioni di tipo data-intensive, uno dei modi per agevolarne la gestione e l'accesso è quello di effettuare delle replicazioni e di distribuirle su alcuni nodi della rete. Questo permette sia di evitare di stressare un unico punto della rete a cui tutti gli host dovrebbero connettersi per l'accesso ai dati, che di diminuire le eventuali latenze dovute al trasferimento. Tale strategia necessita però di operazioni di controllo e di autenticazione per garantire che i dati siano sempre aggiornati e che l'accesso sia consentito agli utenti
su diversi host della rete, gli utenti devono saper localizzare le copie per capire se accedere alle copie esistenti oppure effettuare la creazione di un'altra copia dei dati necessari alle loro applicazioni. E' altresì necessario un meccanismo per sincronizzare tutte le copie in modo che i dati su cui lavorano diversi centri siano sempre aggiornati e coerenti.
In "Data Management and Transfer in High-Performance Computational Grid Environments" viene trattato il problema della gestione delle replicazioni dei dati con Globus Toolkit; sono inoltre presentati esempi di applicazioni come il progetto di fisica LHC (Large Hadron Collider) del CERN e l'applicazione per la creazione di un modello del clima terrestre. L'esperimento LHC produrrà molti petabyte di dati all’anno e questi dati saranno di due tipi: i dati risultanti dagli esperimenti ed i metadati ovvero informazioni riguardo agli esperimenti (numero di ripetizioni, risultati delle analisi). La grandezza dei file varia dai 2 ai 10 gigabyte ed i metadati sono circa 2 gigabyte. Gli utenti sono localizzati in vari centri del mondo: è quindi necessario per loro effettuare delle copie (totali o parziali in base alle loro esigenze) per minimizzare il tempo di accesso ed il carico della rete.
Il servizio di gestione delle copie dei dati deve quindi comprendere l'operazione di creazione di un insieme completo o parziale di file e quella di registrazione all'interno di un Replica Catalog: questo permette agli utenti di effettuare delle query e di eventualmente reperire tutte le copie esistenti di un certo gruppo di file. La gestione dei dati replicati è solo uno dei componenti dell'ambiente computazionale della Grid: l'architettura generale della Grid è stata classificata in quattro livelli [31], [60]:
Fabric: sistemi di memorizzazione, networking e cataloghi Connectivity: protocolli di autenticazione e comunicazione Resource: meccanismi di accesso alle risorse
Nella figura in basso (tratta da [60]) sono rappresentati alcune componenti di ciascun livello con attenzione particolare per quelli inerenti al replica management.
Fig. 2.1
La figura mostra una lista parziale di elementi della Data Grid Reference Architecture che sono rilevanti per il Replica Management
I dati sono organizzati in file o gruppi di file a cui viene dato un nome logico (identificatore unico) che viene mappato su uno o più nomi fisici su un particolare spazio di memorizzazione. I cataloghi hanno la funzione di mappare gli identificatori unici con le locazioni fisiche in cui si trovano i dati.
Il Grid Data Farm (Gfarm) è un esempio di progetto di tipo data- intensive computing iniziato in Giappone che prevede la gestione di un insieme di dati che va dall'ordine dei Terabyte fino ai petabyte forniti dall'acceleratore di particelle del Cern nell'ambito del progetto LHC [62].
Per gestire una quantità così grande di dati nel progetto è stato adottato un modello di computazione multilivello (Regional Center) studiato all'interno del progetto MONARC [63]. Questo modello prevede un livello 0 che corrisponde al CERN, più centri di livello 1 nei continenti che partecipano al progetto, decine di centri di livello 2 di nazioni che partecipano, e molti centri di livello 3 corrispondenti a centri di ricerca e università.
L'architettura software del Gfarm ha come obiettivo l'ottimizzazione dell'accesso ai dati: per fare questo i programmi vengono schedulati sui nodi dove sono presenti i dati necessari per la computazione in modo da sfruttare al massimo la località e di ridurre le latenze dovute al trasferimento di grosse quantità di dati verso gli host. Gfarm è composto da Gfarm filesystem, Gfarm process scheduler e dalle Gfarm parallel I/O API. Il Gfarm filesystem è di tipo parallelo ed i nodi che appartengono al Gfarm filesystem hanno grosse capacità di spazio di memorizzazione (i nodi sono di tipo filesystem nodes e metadata servers). Un file Gfarm è un file di grosse dimensioni che viene diviso in frammenti e distribuito sui dischi del Gfarm filesystem e che saranno poi acceduti in parallelo. Ognuna di queste porzioni di file avrà dimensione arbitraria e potrà essere memorizzata in uno qualunque dei nodi (cluster di migliaia di host). I file di tipo Gfarm sono di tipo write-once: si assume che ogni applicazione crei sempre un nuovo file invece di effettuare continui update su file esistenti. Questo avviene perché in genere i file di grosse dimensioni sono aggiornati raramente e poi perché i dati possono essere recuperati grazie alla replicazione. I metadati sono memorizzati nel Gfarm database che consiste di associazioni tra nomi logici di file e nomi di locazioni fisiche dei nodi, lista delle copie dei file, informazioni sulla piattaforma (come ad esempio sistema operativo e CPU), informazioni sul file (dimensione, accessi e status di modifica). I metadati vengono di volta in volta aggiornati in base alle operazioni effettuate sul filesystem.