3.4
MONARC, il modello a centri regionali
La memorizzazione dei dati e tutte le elaborazioni che devono essere fatte su di essi, portano alla discussione di come devono essere distribuite, anche geograficamente, le risorse. Bisogna creare una struttura che offra la disponibilit`a (on site) di dati e risorse di calcolo a numerosi centri di ricerca, universit`a ed aziende sparse per il mondo che lavorano su un determinato progetto.
Nel progetto EU DataGrid e negli esperimenti legati al LHC viene utilizzato un model- lo di distribuzione delle risorse basato sui Centri Regionali, che sfrutta il lavoro fatto nell’ambito del progetto MONARC (Model Of Networked Analysis At Regional Cen- tres, [32]). Il modello proposto `e un modello gerarchico, composto da vari tiers6 in cui
il CERN si colloca al primo livello, o tier0. Qui risiede quella parte della struttura di calcolo e acquisizione dei dati che non pu`o essere replicata altrove, come l’archivio dei raw data e i database ESD e AOD. Queste risorse devono essere rese disponibili ai livelli sottostanti tramite reti ad alta velocit`a. Seguono i tier 1,2,3 e 4 che hanno una decrescente complessit`a e capacit`a operativa
I tier 1, nell’ordine di qualche unit`a, situati ad esempio in Francia, Gran Bretagna, Italia, USA, Giappone rappresentano centri regionali che devono fornire mezzi di calcolo e dati, in maniera complementare a quelli offerti dal CERN, in modo da consentire a numerose persone di lavorare al progetto pur essendo al di fuori della struttura del CERN. I centri tier 2 sono costituiti da Universit`a ed Istituti di ricerca che ospitano l’utenza finale. I tier 3 e 4 sono costituiti da piccole risorse di calcolo o di storage temporaneo, ad esempio una piccola rete di Istituto per quanto riguarda il tier 3, o quello dei desktop per il tier 4, ove ogni ricercatore esegue le proprie elaborazioni dovendo accedere alle innumerevoli risorse di calcolo e di dati messe a disposizione dai nodi superiori della struttura. L’accesso deve essere semplice, veloce, sicuro e coordinato.
Questa struttura gerarchica pu`o essere estesa e contenere pi`u strati. Per semplicit`a, in seguito faremo riferimento ad una struttura con 4 livelli (0,1,2,3).
Capitolo 4
Consistenza dei dati replicati
In questo capitolo introdurremo il meccanismo della replicazione, un metodo molto uti- lizzato nelle applicazioni distribuite per aumentare le prestazioni e la tolleranza ai guasti. Questa tecnica, allorch´e usata per replicare dati aggiornabili, introduce il problema della consistenza delle repliche. Esistono vari approcci per risolvere questo problema; non esi- ste un metodo migliore degli altri in generale, poich´e ognuno ha le sue caratteristiche ed il suo campo di applicazione. Risulta quindi fondamentale uno studio dettagliato sui requi- siti imposti dall’ambiente di utilizzo, attraverso il quale `e possibile individuare il modo migliore per risolvere il proprio caso. Vedremo inoltre le tecniche utilizzate in alcuni dei pi`u famosi DBMS (commerciali e non) per risolvere il problema della consistenza in un sistema replicato.
4.1
Introduzione
Il problema delle repliche `e un argomento che `e stato gi`a analizzato sia nel campo dei sistemi distribuiti che in quello dei database1, per aumentare le prestazioni e la tolleranza
ai guasti. I meccanismi ed i protocolli usati in queste due discipline sono simili ma non identici. Un sistema distribuito pu`o essere modellato come un insieme di servizi forniti dai server ed usati dai client, quindi ci`o che viene replicato `e un fornitore di servizio (server) con il suo stato. Nei database invece vengono replicati dati (record, tabelle o interi database), ovvero le informazioni immagazzinate o parte di esse. Si capisce che il nostro problema `e del secondo tipo, o meglio la teoria dei database `e quella che ci pu`o fornire pi`u suggerimenti.
1Si parler`a di database e non di database distribuiti per non creare confusione, ´e ovvio per´o che la teoria dei database comprende quella dei database distribuiti, ed ´e questa quella che pi´u ci interessa.
28 CAPITOLO 4. CONSISTENZA DEI DATI REPLICATI
Nei database, cos`ı come nelle griglie, l’obiettivo `e quello di accedere ai dati localmente per diminuire il tempo di risposta ed eliminare l’overhead2 dovuto alla comunicazione con siti remoti. Infatti, se un utente deve accedere a un’informazione presente nel si- stema, si capisce bene che pi`u questa informazione `e distribuita nel sistema (pi`u copie identiche, repliche, presenti nei vari nodi del sistema), maggiori sono le prestazioni del- l’intero sistema, dal momento che ogni utente pu`o accedere direttamente al dato che pi`u gli conviene (generalmente quello pi`u vicino). In un sistema centralizzato invece, dove le informazioni sono disponibili solo in una sede centrale, le prestazioni sono minori dal momento che tutti gli utenti devono far riferimento alla sede centrale per ottenere l’infor- mazione desiderata, e la sede stessa, dovendo soddisfare tutte le richieste degli utenti, non pu`o garantire un basso tempo di risposta. Questo problema aumenta all’aumentare delle dimensioni del sistema (numero di nodi).
Un sistema centralizzato inoltre costituisce il cosiddetto “single point of failure”, ovvero il sistema `e meno tollerante ai guasti dal momento che, se la disponibilit`a della sede centrale che ospita i dati viene a mancare anche temporaneamente, gli utenti non hanno modo di accedere alle informazioni di cui necessitano.
I meccanismi di replica ben si adattano a questi scopi specialmente se le operazioni ese- guite sui dati sono in gran parte di lettura. Operazioni di scrittura sui dati introducono il problema della consistenza tra repliche. Infatti, se un utente pu`o modificare una replica, le altre si vengono a trovare in uno stato inconsistente poich´e non contengono le ultime modifiche. `E quindi possibile che un secondo utente, volendo accedere lo stesso dato ma attraverso un’altra replica, possa leggere delle informazioni che non sono aggiornate in quanto non contengono le modifiche fatte dal primo utente. Sono necessari quindi dei protocolli e dei meccanismi per fare in modo che l’aggiornamento effettuato su una re- plica, dopo un tempo variabile a seconda dei metodi utilizzati, sia disponibile su tutte le altre repliche del sistema.
Vedremo quali sono i diversi approcci al problema e le caratteristiche di ognuno. La prima grande distinzione da fare per definire i diversi approcci al problema della consistenza delle repliche `e quella tra metodi Eager e metodi Lazy.