In ambiente Grid è importante avere un set di strumenti in grado di gestire e trasferire grosse quantità di dati e al contempo degli strumenti in grado di semplificare lo sviluppo di nuove applicazioni reso altrimenti molto complesso dalla grande eterogeneità dei protocolli e componenti della griglia.
Strumenti molto utilizzati sono GridFtp per il trasferimento dei dati e Globus Toolkit [12] per lo sviluppo di applicazioni Grid.
GridFtp [6], [7], [10] è utilizzato per trasferire file di grandi dimensioni in rete e il suo largo utilizzo è dovuto alle buone performance unite ad una grande flessibilità di utilizzo.
XIO [13] è una libreria di I/O per Globus Toolkit che ha gli obiettivi di fornire attraverso una singola API [14] la gestione di tutti i protocolli di I/O di Griglia e di riuscire a minimizzare il tempo di sviluppo di nuovi protocolli.
Nell’articolo “GridFTP Protocol RFC“ [6], “GridFTP Update January 2002” [7] sono presentate le caratteristiche peculiari di GridFtp. In “Progetto INFN-GRID: GridFTP: stato dell’arte” [8] è presentato GridFtp come evoluzione e integrazione di altri protocolli esistenti come la Grid Security Infrastructure (GSI) e Kerberos, l’FTP e le estensioni dell’FTP. Queste estensioni prevedono: trasferimenti in parallelo e in striping, il resume di trasferimenti parziali, la negoziazione automatica del buffer TCP e della window size, il riuso dei canali di comunicazione e il pipelining dei comandi sugli stessi, il controllo esterno del canale di comunicazione (third-party control of data transfer) e il supporto per l’affidabilità e la fault tolerance.
Nel documento “DataGrid - monitoring of globus file transfer with grid-ftp and globus-rcp - wp10 Grid-aware Biology Applications” [9] viene presentato un confronto molto interessante sull’utilizzo della
rete con i due strumenti “globus-rcp” e “grid-ftp”. I risultati dimostrano come GridFtp utilizzi meno cpu e sfrutti maggiormente i link di comunicazione grazie al modello multi-thread. Globus-rcp utilizza di base il comando di copia rcp che richiede molta cpu e disk I/O, dato che deve effettuare preventivamente una copia del file da trasferire su disco locale; inoltre non essendo multi-thread utilizza la rete molto meno efficientemente, in media al 50%.
Nello studio “GridFTP Universal Data Transfer for the Grid” [10] si discute dell’importanza di una strategia di trasferimento file universale che dia la possibilità di collegare sistemi con diversi protocolli e che offra quindi una grande interoperabilità unita alla possibilità di raggiungere elevate prestazioni. Si discute poi dei numerosi vantaggi di questo approccio che richiede il disaccoppiamento tra le funzioni di storage e i metodi che invocano tali funzioni. Nel nostro progetto abbiamo utilizzato lo stesso principio disaccoppiando totalmente le funzioni di alto livello da quelle di comunicazione a basso livello attraverso l’utilizzo di una primitiva di comunicazione intermedia che astrae dal supporto e dai meccanismi di comunicazione utilizzati (RPC, RMI, Socket, http, ftp…).
La gestione di dati per applicazioni ad alte performance e data- intensive su ambienti geografici che siano sicuri, efficienti ed affidabili viene trattata in “Secure, Efficient Data Transport and Replica Management for High-Performance Data-Intensive Computing“ [11]. Nello stesso articolo viene discussa anche la possibilità di registrare e individuare copie multiple di insiemi di dati per effettuare trasferimenti selezionando la copia in base a stime di performance (latenza, banda, capacità…). Lo studio verte sull’analisi di due applicazioni: la fisica di particelle ad alta energia (es. Large Hadron Collider del CERN) e le previsioni climatiche. Prima dell’analisi del
dati su griglia come High Performance Storage System (HPSS), Distributed Parallel Storage System (DPSS), Distributed File System (DFS) e Storage Resource Broker (SRB) che però hanno lo svantaggio di essere incompatibili tra loro.
Durante la discussione sulle performance di questi protocolli viene messo in evidenza come aumenti l’utilizzo di banda all’aumentare degli stream in parallelo (nei test che sfruttano intensamente la rete il numero ottimale di stream risulta essere 8). Vengono poi mostrati alcuni test di performance durante la Network Challenge competition alla conferenza di Supercomputing del 2000. Nel contest è stato raggiunto il transfer rate di picco di 1.55 Gbps su un intervallo di 0.1 secondi. Su un intervallo di 5 secondi è stato raggiunto un transfer rate di 1.03 Gbps e su un intervallo di 60 minuti il transfer rate medio è stato di 512.9 Mbps, con il trasferimento di 230.8 gigabyte usando 8 server in striping alla sorgente e 8 alla destinazione con 4 stream TCP per server.
Successivamente all’analisi di GridFTP si passa ad una breve descrizione di un altro applicativo importante per la griglia: il Replica Management.
Il sistema di Replica Management offre le seguenti funzionalità: - creazione di nuove copie, complete o parziali, di un data set - registrazione delle suddette copie in un Replica Catalog
- possibilità di interrogare il Replica Catalog per cercare copie esistenti di un file o di insiemi di file
- selezione della copia migliore per l’accesso; la selezione è fatta da un servizio informativo di griglia in base ad una predizione delle performance delle rete e dello spazio disponibile.
Il Replica Catalog è implementato come un servizio LDAP (Lightweight Directory Access Protocol) e ha fondamentalmente lo scopo di mappare i nomi logici di file e collezioni di file agli archivi fisici presenti su uno o più host.
Le principali caratteristiche di XIO (una libreria di I/O per Globus Toolkit [12]) sono presentate sul sito web ufficiale di XIO [13]. XIO ha gli obiettivi di fornire attraverso una singola API [14] la gestione di tutti i protocolli di I/O di Griglia e di riuscire a minimizzare il tempo di sviluppo di nuovi protocolli.
Il primo obiettivo viene raggiunto facendo in modo che nuovi protocolli vengano sviluppati sotto forma di driver (caricati eventualmente a runtime) che vengono inseriti nella libreria Globus XIO, rendendo l’interfaccia dell’API verso lo sviluppatore completamente trasparente al supporto e protocollo utilizzato. In tal modo senza cambiare alcuna riga di codice è possibile passare ad esempio da protocolli di comunicazione su socket a pipe o message passing. Alcune caratteristiche particolari di XIO sono un’alta efficienza, estendibilità attraverso driver, timeout gestiti dalla libreria che evitano di usare timeout personalizzati, interrupt, alarm e gestione di data descriptor che consentono di associare dei metadati ai buffer di dati da inviare che poi vengono ritornati come descrittori alla conclusione di operazioni asincrone.
L’architettura di Globus XIO è formata da due componenti principali: il framework e i driver. Il Framework gestisce le richieste inoltrate tramite l’API [14] e le mappa alla componente driver che effettua la gestione vera e propria dei dati. Questa componente comprende driver di trasformazione e driver di trasporto. I driver di trasformazione sono organizzati a stack e si preoccupano di incapsulare e trasformare i dati per supportare caratteristiche peculiari dei protocolli (es. autenticazione con Kerberos piuttosto che con SSL, compressione dei dati…); i driver di trasporto invece non sono organizzati a stack ma sono a livello unico e si preoccupano di effettuare la consegna dei dati sulla linea di comunicazione usando un unico e specifico algoritmo di trasporto (es. udp, tcp, blast udp, fast