Il middleware per il grid computing risolve due problemi che i protocolli web standard lasciano aperti: come conservare lo stato di una risorsa remota tra una chiamata e l’altra a servizi che sono stateless per progetto, e come autorizzare un processo ad agire per conto di un utente che, mentre quel processo gira, non è davanti alla tastiera. Globus Toolkit 4 (GT4) affronta entrambi i problemi appoggiandosi a specifiche pubbliche — WSRF per il primo, i proxy certificate X.509 per il secondo — invece di inventare protocolli propri. Guardare come lo fa serve: le scelte di GT4 sono un caso di studio su cosa significhi costruire infrastruttura distribuita riusando gli standard che già ci sono.

Contesto

Globus Toolkit nasce dalla Globus Alliance, con Ian Foster (Argonne National Laboratory, University of Chicago) e Carl Kesselman (USC Information Sciences Institute) come figure principali. La versione 4.0 esce nel maggio 2005 sotto licenza Apache 2.0; mentre scrivo, la linea 4.0.x è quella di riferimento. Su GT4 girano infrastrutture in produzione: TeraGrid negli Stati Uniti, l’Open Science Grid e il progetto europeo EGEE (Enabling Grids for E-sciencE), il cui middleware gLite 3.0 — uscito nel maggio 2006 — include componenti Globus attraverso la Virtual Data Toolkit. La Worldwide LHC Computing Grid, costruita al CERN per distribuire l’analisi dei dati del Large Hadron Collider su una gerarchia di centri Tier-0/Tier-1/Tier-2, poggia sullo stesso strato.

La transizione architetturale che porta a GT4 è precedente, e ricostruirla spiega le scelte di oggi. La versione 3 implementava OGSI (Open Grid Services Infrastructure), pubblicata dal Global Grid Forum nel 2003. OGSI infilava i concetti di grid dentro i servizi web in un’unica specifica monolitica, e si incastrava male con gli strumenti SOAP e XML dell’epoca: chi la adottava finiva spesso per patchare o rimpiazzare i toolkit standard. Nel gennaio 2004 IBM e la Globus Alliance hanno scomposto quelle idee in WSRF (Web Services Resource Framework), una famiglia di specifiche separate, poi portata sotto OASIS. GT4 è la prima release Globus costruita interamente su WSRF.

Architettura: dare stato a un servizio stateless

Un servizio web SOAP, per progetto, non conserva nulla tra una chiamata e la successiva. Un job in esecuzione su un cluster remoto, invece, ha uno stato che cambia nel tempo — in coda, in esecuzione, terminato — e il client deve poterlo interrogare e modificare. WSRF scioglie questa tensione separando il servizio (stateless, indirizzabile) dalla risorsa (stateful, con i propri dati). La coppia servizio più identificatore di risorsa si chiama WS-Resource e si indirizza con un endpoint reference di WS-Addressing.

Le proprietà di una risorsa vengono esposte come WS-ResourceProperties: documenti XML che si interrogano e si modificano con operazioni standard, senza che ogni servizio si reinventi le proprie API per leggere lo stato. La durata di vita la governa WS-ResourceLifetime, che prevede sia la distruzione esplicita sia una scadenza programmata — la risorsa si autodistrugge se non viene rinnovata, e questo evita che su un sito remoto si accumuli stato orfano. Le notifiche di cambiamento viaggiano su WS-BaseNotification. In pratica, le quattro famiglie storiche di componenti Globus — gestione dell’esecuzione (WS-GRAM), trasferimento dati, sicurezza, monitoraggio (MDS) — vengono reimplementate come WS-Resource e diventano interoperabili con qualunque stack di servizi web conforme.

Il caso più chiaro è WS-GRAM (Grid Resource Allocation and Management). Prende la descrizione di un job, la rappresenta come WS-Resource interrogabile e la traduce in comandi per lo scheduler locale del sito — PBS, Condor, LSF, SGE. Il client interroga sempre la stessa interfaccia astratta; lo scheduler sottostante resta nascosto. Il trasferimento dei file di input e output del job lo gestisce GridFTP, un’estensione di FTP che apre più stream TCP in parallelo per saturare reti geografiche ad alta latenza e riparte dal punto di rottura quando un trasferimento si interrompe — indispensabile quando i volumi arrivano ai terabyte.

Il punto critico: delegare le credenziali

Il problema più sottile non è autenticare un utente, ma autorizzare un processo che agisce mentre l’utente è altrove. Un ricercatore sottomette un workflow che, per ore, lancia job su un sito, ne sposta i risultati su un secondo, ne avvia altri su un terzo. A ogni passaggio serve la sua identità, ma lui non è alla tastiera a digitare una passphrase. La Grid Security Infrastructure (GSI) risolve la cosa con i proxy certificate, standardizzati come RFC 3820 nel 2004.

Un proxy certificate è un certificato X.509 a vita breve, firmato dal certificato di identità dell’utente (o da un proxy precedente, in catena) e con la chiave privata non cifrata. È la chiave in chiaro a far firmare i processi automatici senza intervento umano; è la vita breve — di solito dodici ore — a contenere il danno se il proxy viene esfiltrato. La delega è il meccanismo per cui il sito A, ricevuto il proxy, ne genera un altro per agire verso il sito B per conto dello stesso utente, senza mai trasmettere la chiave dell’identità originale. La fiducia tra istituzioni poggia su una International Grid Trust Federation di autorità di certificazione che si riconoscono a vicenda.

Il punto da non perdere è che GSI non tira su un sistema di sicurezza da zero: compone X.509, TLS e un’estensione standardizzata in sede IETF. Lo stesso fa WSRF rispetto a SOAP e WS-Addressing. È la differenza tra estendere gli standard e rimpiazzarli, e GT3 con OGSI aveva imboccato la seconda strada, pagandola in interoperabilità.

Implicazioni

Per chi progetta sistemi distribuiti, il valore di GT4 come riferimento sta nelle decisioni, più che nel codice. Federare risorse eterogenee lasciando a ogni sito la sua autonomia amministrativa — non un unico supercomputer, ma istituzioni indipendenti che condividono capacità secondo politiche concordate — è lo stesso problema che ritorna in molte architetture multi-organizzazione. La separazione tra servizio stateless e risorsa stateful, l’autorizzazione per delega a credenziali a vita breve, la traduzione di un’interfaccia astratta verso backend eterogenei: sono pattern che valgono ben oltre il calcolo scientifico.

Limiti

WSRF ha creato attrito dentro la comunità dei servizi web. La sovrapposizione con WS-Transfer e WS-Management, sostenute da un altro gruppo di vendor, ha frammentato lo spazio delle specifiche per la gestione di risorse stateful, e che la convergenza su WSRF prevalga non è scontato. La complessità operativa di installare e configurare GT4 resta alta: l’adozione passa quasi sempre per distribuzioni intermedie (gLite, VDT) che lo impacchettano. Infine, GSI presuppone una PKI funzionante e mutuamente riconosciuta tra le istituzioni — un costo organizzativo, prima che tecnico, che le griglie scientifiche reggono grazie a federazioni di fiducia già esistenti e che, fuori da quel contesto, non si può dare per acquisito.

Immagine di copertina: Vista ravvicinata dall’alto di un rack di server pieno di cavi di rete colorati nel data center del CERN — foto di Marián Hubinský, CC BY-SA 4.0 — https://commons.wikimedia.org/wiki/File:Rack_of_Worldwide_LHC_Computing_Grid.jpg