+=FEJ ! +5J== K 4AFE?= +IEIJA?O 5AHLE?A FAH /HE@

Capitolo 3

CONStanza: un Replica

Consistency Service per Grid

Questo capitolo illustra il problema della consistenza delle repliche dei dati in un sistema Grid. Inoltre descrive il replica consistency service CONStanza, illustrando la sua architettura, inne si soerma brevemente sull'interfaccia di tipo Web Service con cui è stato strutturato CONStanza, mostrando i metodi remoti ed il loro utilizzo da parte del cliente.

3.1 La consistenza dei dati nei sistemi Grid

Un sistema Grid, come descritto nel capitolo precedente, permette a diversi nodi geogracamente distribuiti di lavorare in maniera collaborativa. Pren-dendo maggiormente in considerazione l'aspetto della condivisione dei dati, le Data Grid permettono la gestione di enormi quantità di dati, del livello di Petabytes. Per garantire migliori prestazioni vengono utilizzati dei meccani-smi di replica, grazie ai quali si riesce ad aumentare la velocità di accesso ai dati, infatti avendo più repliche a disposizione, un nodo sceglierà il cammino più veloce. Inoltre il sistema è maggiormente robusto, in caso di guasti che compromettono l'accesso ad un insieme di dati, sarà possibile accedere ad una delle varie repliche.

Una replica non è solamente un semplice copia dell'originale, le repliche sono più istanze siche dello stesso le logico. Per essere consistente, un cambiamento eettuato su una replica deve propagarsi a tutte le altre. Nel caso in cui i dati nella Grid siano di tipo read-only, non si pone il problema, in quanto non subendo nessun aggiornamento, i dati si trovano sempre in uno stato consistente.

Nel caso in cui le repliche possono essere modicate si pone il

ma della consistenza. Questo non caratterizza in maniera esclusiva le Data Grid, bensì è un problema già presente nei Data Base Management System (DBMS), le soluzioni adottate in questo campo non possono però essere uti-lizzate nell'ambito Grid, infatti i DBMS hanno un controllo completo dei dati che elaborano, inoltre i dati hanno tutti il solito formato, in questo caso si può parlare di una consistenza locale [14].

Nelle Data Grid invece, la manipolazione dei dati avviene attraverso il le system sottostante, presente in ogni nodo. Questo non ha meccanismi per mantenere la consistenza, paragonabili a quelli presenti su database. Inoltre nelle Data Grid sono presenti dati di dierenti tipi, quindi richiedono diverse tipologie di consistenza. Inne si deve tener presente che il servizio di con-sistenza deve permettere di utilizzare qualsiasi metodo di memorizzazione. Per tutte queste caratteristiche si può parlare di una consistenza globale.

In un Data Grid deve quindi essere presente un Replica Manager che serve agli utenti per creare, spostare, aggiornare e cancellare le repliche. Questo signica che i le sono copiati da un nodo ad un altro e registrati in un catalogo. Informazioni ausiliarie, quali indice e catalogo, utilizzate per gestire i dati, devono essere anch'esse replicate e quindi mantenute consistenti.

3.1.1 Replica Sincrona

Il maggiore grado di consistenza si raggiunge attraverso delle repliche comple-tamente sincronizzate, ciò si ottiene quando tutte le repliche vengono aggior-nate all'interno di un'unica transazione, in altre parole ogni transazione di database locale deve essere propagata e quindi fatta conoscere a tutte le altre repliche (o almeno alla maggioranza delle repliche), in questo modo quando un dato viene modicato, la modica viene propagata a tutte le repliche del dato, prima che la modica stessa sia resa disponibile ai clienti dal sistema.

In un DBMS il modello sincrono può essere raggiunto estendendo le re-gole applicate alle transazioni locali, come applicare il meccanismo di lock anche alle repliche. Questa soluzione non può essere adottata nell'ambito delle Data Grid, in quanto c'è bisogno di un approccio più essibile, infatti non è detto che sia sempre necessario fornire il più alto grado di consistenza, addirittura potrebbe esserci un nodo che vuole rimanere indipendente dagli altri, una volta che i dati sono disponibili. Quindi è necessario un approccio che permetta ad alcuni dati di rimanere momentaneamente fuori dalla sin-cronizzazione (dati a bassa consistenza), mentre ad alti di essere sincronizzati immediatamente (dati ad alta consistenza).

3.1.2 Replica Asincrona

In un ambiente di replica sincrono, l'alto grado di consistenza va a scapito delle prestazioni, che risultano basse, soprattutto in operazioni di scrittura. Per questo si cerca di adottare un protocollo basato su un modello asincrono, in modo da avere maggiore ecienza, a scapito di una più bassa consistenza. Attualmente non c'è uno standard disponibile, le soluzioni comuni adottate sono:

• Approccio a Copia Primaria. Anche conosciuto come approccio master-slave; per ciascun insieme di dati o le, esiste una copia primaria, tutte le altre repliche sono considerate copie secondarie. Gli aggiornamenti possono essere eseguiti solamente agendo sulla copia primaria, quin-di se una richiesta quin-di scrittura è fatta su una copia secondaria, verrà in realtà eseguita sulla copia primaria, dopo di che gli aggiornamenti saranno propagati a tutte le copie secondarie. Con questo approccio si ottengono alti livelli di consistenza ed una maggiore ecienza nelle operazioni di scrittura, infatti il lock sul le non deve essere propagato contemporaneamente a tutte le repliche, ma applicato inizialmente alla sola copia primaria.

• Approccio Epidemico. I cambiamenti possono essere eettuati su cia-scuna replica e parallelamente un processo separato confronta le in-formazioni sulla versione delle varie repliche (ad esempio, attraverso il time-stamp), in modo da propagare gli aggiornamenti verso le repli-che più vecchie in maniera asincrona. Gli aggiornamenti sono sempre eseguiti prima a livello locale e poi i vari nodi comunicano tra loro per scambiarsi informazioni. Il livello di consistenza che si ottiene può esse-re molto basso, inoltesse-re questa soluzione non esclude possibili anomalie nei dati. Quindi questo approccio non può essere applicato a sistemi critici che non tollerano conitti di aggiornamento dei dati.

• Sottoscrizione e Nodi ad indipendenza relativa. Simile all'Epidemico, segue un approccio in base al quale un nodo possiede i dati senza pre-occuparsi della loro consistenza. Quando ciascun altro nodo esegue un aggiornamento su un particolare le, solo certi nodi riceveranno la notica dell'avvenuto cambiamento. Ovvero quelli che hanno eseguito una sottoscrizione esplicita per i dati prodotti da un determinato nodo. Quindi un nodo che non eettua sottoscrizioni deve occuparsi da solo di ottenere i dati aggiornati dagli altri.

3.2 Il Servizio di Consistenza CONStanza

In un generico ambiente Grid abbiamo due tipi di nodi: Computing Elemen-ts (CE) che forniscono la potenza computazionale e Storage ElemenElemen-ts (SE) che forniscono capacità di memorizzazione. Diversi servizi compongono il Grid middleware, che fornisce funzionalità come la schedulazione dei lavori, l'allocazione delle risorse, e la gestione dei dati. Include inoltre il Replica Management Service (RMS) e il Replica Consistency Service (RCS).

Il RMS si occupa di replicare i le in modo da ottimizzare i tempi di accesso e migliorare la disponibilità, quindi tiene traccia delle diverse repliche ed è in grado di determinare a quale replica è più conveniente accedere, per ogni job in esecuzione su un determinato CE. Per eettuare questa decisione il RMS usa il Replica Catalogue (RC), un database contenente le informazioni sulle varie repliche di ciascun le.

Ogni le in una Grid è caratterizzato da un Logical File Name (LFN), al quale vengono associate le relative repliche. Quest'ultime sono mappate negli Storage Elements. Si denisce Physical File Name (PFN) una serie di informazioni necessarie per accedere ad una determinata replica: queste informazioni includono l'indirizzo del SE, il pathname del suo le system e possibilmente un relativo protocollo di accesso (ad esempio, GridFTP).

Il modello appena illustrato può essere esteso al concetto più generale di dataset. Un dataset può essere un le non strutturato (at le) o uno structured dataset. Nel primo caso si ha una struttura interna che ai ni della replica e della consistenza può essere trascurata. Mentre nel secondo caso la struttura interna è fondamentale, in quanto è gestita attraverso operazioni di alto livello (come l'esecuzione di comandi SQL).

Un Replica Consistency Service (RCS) è un servizio Grid che deve garan-tire la consistenza dei dati replicati. Questo servizio comprende vari schemi di replicazione e garantisce dierenti livelli di consistenza per le applicazioni utenti. Le componenti base per un RCS sono un'interfaccia client per il ser-vizio, un meccanismo di aggiornamento per le repliche ed inne un protocollo di propagazione degli aggiornamenti.

CONStanza[15] è un RCS accessibile come Web Service che può essere congurato in base a varie politiche di update. Le repliche possono essere database relazionali o semplici le. È importante distinguere tra due tipi di replica che vengono utilizzati da questo sistema, in quanto si dierenziano nel signicato e nei permessi di accesso per gli utenti nali

• _{Master replica. E' l'unica replica che per denizione è sempre}

ag-giornata, inoltre è una replica che può essere modicata da un utente del sistema.

• Secondary replica. E' una replica che viene aggiornata da CONStanza eventualmente con un certo ritardo, ma in modo da avere alla ne lo stesso contenuto della master replica. Più lungo è il ritardo nella pro-pagazione dell'update, meno la master e la secondary replica saran-no sincronizzate. Dato che gli aggiornamenti sosaran-no eseguiti solamente da CONStanza, per evitare conitti nei processi di aggiornamento, gli utenti nali hanno accesso alle secondary replica in sola lettura.

3.2.1 L'architettura di CONStanza

Le componenti principali di CONStanza sono:

Global Replica Consistency Service (GRCS) Rappresenta il principale

punto di ingresso per le richieste di aggiornamento.

Local Replica Consistency Service (LRCS) È responsabile della

regi-strazione delle nuove repliche a livello locale, che gestisce direttamente, così come gli aggiornamenti per queste repliche.

Replica Consistency Catalogue (RCC) Memorizza tutte le informazioni

su tutte le repliche, come lo stato in cui si trovano o la loro localizza-zione.

L'utente interagisce con RCS attraverso un'interfaccia testuale, tramite la quale può inviare richieste di aggiornamento. L'utente può modicare solo la master replica, mentre può accedere alle secondary replica in sola lettura. Questo è il classico approccio master-secondary, che permette veloci accessi in lettura e accessi in scrittura limitati e centralizzati. Infatti nello scenario più tipico, l'utente per prima cosa aggiorna la master replica, poi manda il comando di update, in modo che RCS replichi l'aggiornamento. Il sistema suppone che i dati siano già replicati su alcuni nodi della Grid, la cui posizione è memorizzata nel catalogo di consistenza delle repliche (RCC).

Nel caso di replica di database, è previsto un ulteriore componente, il Log Watcher, che controlla periodicamente se è stato eettuato un aggiornamento sulla master replica. Quando ciò avviene estrae gli ultimi cambiamenti dal le di log del database e li inserisce in un le di update che viene inviato a tutte le repliche, attraverso il comando di update. I cambiamenti sulle secondary replica vengono eettuati da un ulteriore componente, il DBUpdater.

Il processo di sincronizzazione nel caso di database può essere schematiz-zato nelle seguenti fasi:

RCC LRCS2 Log Watcher DB master http://pcgridtest2.pi.infn.it:8081 Site A http://pcgridtest2.pi.infn.it:8080 GRCS LRCS1 DBUpdater Site B DB slave http://pcgridtest3.pi.infn.it:8081 LRCC

Figura 3.1: Architettura CONStanza in uno scenario con replica di database [16]

• Estrazione del Log e Notica. Il master LRCS attraverso il Log Watcher, osserva il le di log del database, in base agli aggiornamenti rilevati crea un le di update che gli slave LRCS utilizzano per aggior-nare le proprie repliche. Appena il le di update è pronto, viene inviata una notica al GRCS.

• _{Update Propagation. Il GRCS, una volta ricevuta da parte del}

master LRCS la notica di update, contatta tutti gli slave LRCS che hanno almeno una replica interessata all'aggiornamento, fornendo la posizione dell'update le nella Grid.

• Log Transfer & Application. Quando uno slave LRCS riceve la no-tica di un update, recupera il le di update ed attraverso il DBUpdater applica le modiche.

3.2.2 Progetto e Implementazione

Un prototipo avanzato per il RCS è stato sviluppato in C++ (gcc 3.2 su GNU/Linux) con l'uso degli strumenti gSOAP per rendere accessibile CONStanza come Web Service e per l'implementazione dell'interfaccia web (vedi capitolo 7)

In gura 3.2 sono presentati i sottosistemi principali che compongono CONStanza, come si nota LRCS e GRCS sono distinti ma hanno la solita struttura (infatti la descrizione di alcuni subpackage presentata di seguito è valida per entrambi i sottosistemi). Ogni sottosistema ha un subpackage Core, che contiene le funzionalità principali del servizio.

Figura 3.2: Packages di CONStanza [17]

3.3 Metodi Remoti

CONStanza è accessibile come Web Service, in quanto tale, presenta un'in-terfaccia costituita da una serie di metodi remoti.

3.3.1 Il subpackage Comm

Supporta la comunicazione sia tra i sottosistemi che tra RCS ed i clienti. Contiene l'interfaccia Web Service, questa interfaccia è la lista dei metodi remoti, deniti nel le header gSOAP WRCS.gh

3.3.2 Il subpackage Client

Consiste nelle applicazioni cliente sia per il GRCS che per il LRCS, queste permettono l'esecuzione dei metodi remoti (deniti in WRCS.gh), facenti parte dell'interfaccia tra RCS e cliente. Possono essere invocati da eseguibili a linea di comando, quindi attraverso una Client Line Interface, CLI. Di seguito elenchiamo brevemente gli eseguibili che compongono la CLI [16], in quanto successivamente verrà mostrato come, partendo dalla denizione dei metodi remoti, sia possibile creare una Interfaccia Web.

Per quanto riguarda il GRCS, alcuni comandi presenti nella client CLI sono: rcs-create-repl rcs-subscribe-file rcs-subscribe-repl rcs-update-db rcs-update-file

(per la lista completa si veda l'appendice A)

Gli eseguibili CLI per quanto riguarda il LRCS sono: lrcs-set-dbupdater

lrcs-set-grcs lrcs-subscribe

lrcs-subscribe-DBreplica lrcs-unsubscribe