Tazio: Una Memoria Software Transazionale Distribuita affidabile per Java

Transcript

1 Tazio: Una Memoria Software Transazionale Distribuita affidabile per Java Andrea Reale ABSTRACT La diffusione rapida di applicazioni distribuite rende necessario lo sviluppo di modelli e tecniche che permettano la comunicazione e l interazione affidabile di processi dislocati su nodi diversi. L astrazione di memoria condivisa distribuita offre una possibile soluzione al requisito di condivisione di informazioni tra le parti di un sistema, ma espone il programmatore all obbligo di soddisfare complessi requisiti di sincronizzazione nell accesso ai dati comuni. Una logica d accesso basato su transazioni può sollevare da questo onere, permettendo il lavoro concorrente e validandone i risultati solo in un secondo momento. Sarà illustrata una implementazione di memoria condivisa distribuita con accesso a semantica transazionale (DSTM) pensata e progettata per garantire un servizio ad alta affidabilità tramite tecniche di clustering. 1. INTRODUZIONE Tazio è un sistema di memoria software transazionale distribuita (DSTM - Distributed Shared Transactional Memory) per sistemi Java pensato per l alta disponibilità e la tolleranza ai guasti e capace di supportare un elevato numero di processi che lavorino contemporaneamente sulla memoria. Obiettivo primario è permettere allo sviluppatore di applicazioni distribuite di condividere informazioni e lavorare su di esse in maniera semplice, offrendogli una astrazione che sia il più possibile vicina a quella di un ambiente Java locale, e proteggendolo da problemi di accesso concorrente grazie all utilizzo di transazioni. L unità di memoria di base è l oggetto Java, e l accesso al suo stato - che avviene tramite gli usuali metodi getter e setter - è reso implicitamente transazionale e disponibile a tutti i clienti del sistema. Aspetto cruciale è il modo in cui tazio gestisce la replicazione della memoria coordinando le transazioni che su di essa avvengono in maniera distribuita: normalmente in una memoria transazionale, tutti i partecipanti prendono parte ad un protocollo di commit atomico per garantire che operazioni concorrenti sulla memoria siano serializzate in maniera consistente: questo porta ad un notevole degrado delle prestazioni quando i processi partecipanti sono numerosi, soprattutto nel caso in cui sia difficile garantire la correttezza e monitorare le prestazioni di tutti. Il sistema proposto affronta questo problema differenziando le garanzie che offre rispetto alla vista della memoria condivisa, in base a due diversi tipi di processi (Replica Manager e Weak Replica Manager). Tazio è inoltre pensato per garantire in maniera nativa alta disponibilià del servizio e resistenza ai guasti, facendo uso di tecniche di clustering ed esplorando un protocollo di terminazione delle transazioni alternativo ai tradzionali protocolli di commit atomico (e.g. 2PC), pensato specificamente per transazini su oggetti replicati. Il documento è organizzato come segue: nella sezione 2 verranno velocemente elencate le assunzioni alla base del failure model del sistema; nella sezione 3 verranno illustrati i concetti e i principi dell architettura del sistema; nella sezione 4 verrà illustrata la scomposizione in parti e responsabilità di tazio, mentre nelle sezioni 5 e 6 saranno dettagliate le sottoporti relative rispettivamente alle comunicazioni client-server e alla gestione delle transazioni, sviluppate da me. Infine nella sezione 7 saranno riportati i risultati dei test sul sistema e nella sezione 8 saranno illustrati possibili sviluppi ed espansioni. 2. ASSUNZIONI In questa breve sezione sono elencate le assunzioni fatte sulle modalità di fallimento delle parti del sistema. Tali assunzioni sono da ritenersi verificate in ogni altra parte del documento e sono necessarie affinché il sistema presenti il comportamento descritto in seguito. Failure dei processi. Tutti i processi del sistema falliscano solo in seguito a crash, e sono completamente immuni da fallimenti di tipo bizantino. I processi andati in crash potranno essere eventualmente ripristinati e tornare a partecipare al sistema. Failure della rete. Il canale di comunicazione tra i RM facenti parte del cluster, è un canale affidabile che garantisca che un messaggio sia consegnato a tutti i processi corretti. In questo momento non si fa nessuna assunzione sull ordinamento dei messaggi, anche e si vedrà come sarà necessario introdurle per la realizzazione del protocollo di commit distribuito. Al contrario non si fa alcun tipo di assunzione riguardo al canale di comunicazione che collega i Weak Replica Manager tra di loro e con i Replica Manager. In questo tipo di comunicazione i messaggi possono essere persi, ritardati e disordinati a piacimento. 3. CONCETTI DI BASE La memoria condivisa di Tazio è organizzata intorno al concetto di Share che definisce il contenitore concettuale in cui vengono memorizzati e resi disponibili gli oggetti condivisi. Esso rappresenta il punto d accesso al sistema per

2 oggetti che legge o scrive, e prima che possa effettuare il commit deve superare una fase di validazione in cui sono rilevati eventuali conflitti con transazioni concorrenti. Per un Replica Manager corretto è garantito che tutte le operazioni effettuate sugli oggetti che esso replica avvengono con semantica strettamente transazionale se una transazione viene eseguita sulla sua memoria, quella stessa transazione verrà eseguita anche da tutti gli altri Replica Manager corretti del sistema Figure 1: Tazio: schematic architecture chiunque voglia usufrirne dei servizi: permette di aggiungere alla memoria nuovi oggetti, recuperare oggetti condivisi da altri clienti, ed eventualmente eliminarli. Lo sviluppatore che voglia usare il servizio deve definire un interfaccia per gli oggetti che vuole utilizzare, e tramite l utilizzo di apposite annotazioni, indicare al sistema quali sono le proprietà per le quali desidera un accesso transazionale. A runtime, la creazione delle istanze di tali oggetti dovrà essere affidata al sistema: questo utilizzerà una implementazione fornitagli dallo sviluppatore, arricchendola con la logica transazionale richiesta tramite l utilizzo di proxy dinamici; automaticamente l oggeto creato sarà aggiunto allo Share. Lo stato dello Share così come quello degli oggetti in esso contenuti, viene mantenuto da un cluster di processi server - i Replica Managers - ciascuno dei quali replica localmente l intera memoria, e si coordina con il resto del gruppo al fine di mantenere la propria copia in uno stato sempre consistente tramite l uso di un protocollo di commit per le transazioni appositamente studiato (vedi sezione 6.2). Alla memoria possono accedere processi client, che forniscono all utilizzatore accesso agli oggetti condivisi e interfaccie per il controllo e la gestione delle transazioni. Tali processi - denominati Weak Replica Manager - non sono direttamente coinvolti nel protocollo di commit atomico sopra citato: in questo modo i server sono liberati dall onere di dover contattare e gestire un numero possibilmente alto di nodi durante la coordinazione per il commit di transazioni (vedi fig. 1. Benché la semantica delle operazioni sulla memoria dal punto di vista dei client non sia strettamente transazionale, il sistema riesce comunque a garantire che tutte le operazioni vengano effettuate su una vista dei dati aggiornata, o che in caso contrario le transazioni che le coinvolgono falliscano. In particolare due diversi insiemi di asserzioni sono garantite riguardo alla consistenza delle copie degli oggetti, sulla base della categoria di processo. Replica Manager Un RM è responsabile di mantenere una copia sempre aggiornata della memoria condivisa e di gestire e rispondere alle richieste di oggetti condivisi da parte dei clienti del sistema. Le transazioni in ogni RM sono gestite sfruttando un protocollo di controllo dei conflitti ottimistico basto sul versioning: ogni transazione agisce su uno snapshot locale degli tutte le transazioni che esso vede, arrivano e sono validate nello stesso ordine di quello visto da ogni altro Replica Manager del sistema. In base a queste assunzioni è facile dimostrare che il gruppo di Replica Managers manterrà uno stato di replicazione in ogni istante consistente (così assicurando la proprietà di one copy serializability), a patto che tutti partano dallo stesso stato iniziale della memoria. Weak Replica Manager Con Weak Replica Manager (WRM) si identifica il componente software utilizzato dalle applicazioni che vogliono accedere al servizio di DSTM. Generalmente un WRM è fisicamente collocato sullo stesso nodo in cui risiede l applicazione che ne fa uso, e può essere visto da essa come una replica locale della memoria offerta dal cluster di RM. Tutti gli accessi alla memoria da parte di un WRM devono avvenire nel contesto di una transazione: l API fornita allo sviluppatore permette di gestire manualmente i suoi confini, ed in caso questo non avvenga il sistema si preoccupa di crearne una ed associarla al thread che vuole accedere ad un oggetto condiviso. Transazioni concorrenti sullo stessa istanza di WRM sono serializzate attraverso l uso di un protocollo simile a quello usato dai Replica Managers: in questo modo i potenziali conflitti tra accessi locali sono rilevati durante una prima fase di validazione. Le transazioni che sopravvivono a questa fase dovranno poi essere validate globalmente dal cluster prima di essere applicate sulla memoria, controllando che esse non confliggano con altre originate da altri nodi. Per un istanza di Weak Replica Manager corretta sono fatte le seguenti garanzie: se un WRM riesce a completare una transazione con successo, allora quella transazione sarà stata completata con successo anche dal gruppo dei RMs una transazione avviata da un WRM non ha mai successo se essa lavora su copie di oggetti non aggiornati rispetto allo stato dei RMs un WRM riceve prima o poi notifica delle modifiche allo stato degli oggetti che avvengono sui RMs da parte del sistema di cache (vedi sezione 4). Si noti che se è vero che il commit di una transazione lato WRM implichi il commit della stessa su RMs, non è garantito che sia vero il contrario: è infatti possibile che una transazione iniziata da un WRM sia completata con successo dai RMs, ma che fallisca sul WRM che l ha iniziata (ad esempio perchè viene perso qualche messaggio scambiato tra WMR e RM - si veda la sezione 2); questa è la violazione principale

3 Figure 2: Struttura di un RM Figure 3: Struttura di un WRM alla semantica transazionale lato Weak Replica Manager, ed è conseguenza diretta della scelta di tener fuori i processi di questo tipo dal protocollo di commit atomico. 4. ORGANIZZAZIONE DEL SISTEMA Nelle figure 2 e 3 è illustrata la scomposizione in sottopoarti di Replica Manager e Weak Replica Manager. Ciascuna delle parti è pensata per assolvere una precisa responsabilità e collabora con le altre per realizzare le funzionalità richieste dal servizio; in questa sezione sarà illustrato brevemente il razionale dietro ciascun layer, e nelle due sezioni successive (5 e 6) verranno dettagliati i sottosistemi di comunicazione client-server (tazio-networking) e di gestione delle transazioni (tazio-transactions). tazio-networking. Realizza la logica di comunicazione tra WRMs e RMs, secondo un modello Client / Server. Obiettivo del sottosistema è fornire un implementazione di server TCP che sia capace di scalare in maniera soddisfacente rispetto al numero di connessioni gestite. Ulteriori dettagli saranno forniti nella sezione 5. tazio-transparency. Ha l obiettivo di realizzare un astrazione uniforme rispetto alle diverse forme di comunicazione per i sottosistemi di più alto livello. Le sue responsabilità possono essere ulteriormente scomposte in tre distinte parti. Group Service: incapsula la logica di comunicazione di gruppo tra i Replica Manager - reallizzata sfruttando JGroups [1] - e si occupa dei problemi relativi alla sua gestione (modifica dinamica della membership del gruppo, network partitions, ecc..). Transparency Layer: si preoccupa di rendere trasparenti le comunicazioni tra WRM e RM, rispetto alla repli- cazione di questi ultimi. In particolare gestisce l eventualità che uno di questi diventi irragiungibile, e - ove permesso dalla logica applicativa - dirotta i messaggi verso un altro RM disponibile. Dispatching Layer: fornisce un servizio ai sottosistemi di più alto livello, permettendo loro di registrarsi per la notifica della ricezione di messaggi in base al loro tipo, e si preoccupa di smistare i loro messaggi al destinatario (remoto o locale) più aprropriato. tazio-ril. Implementa un semplice sistema di RMI tra oggetti remoti che sia capace di sfruttare nativamente la natura replicata del sistema. Lato WRM pemette - sfruttando delle apposite annotazioni - di invocare un metodo su un oggetto remoto localizzato su un RM specificando il tipo di comportamento desiderato rispetto alla replicazione: Invocazione su al più un RM : prova ad eseguire l invocazione sull oggetto remoto desiderato, cercandolo su uno degli RM. In caso di mancata risposta l invocazione fallisce. Invocazione su almeno un RM : prova ad eseugiore l invocazione sull oggetto remoto desiderato, provando prima su un RM ed in caso di mancata risposta prova a rieseguire l invocazione su un diverso RM. Lato RM permette di invocare metodi su un oggetto remoto replicato su tutti i membri del cluster: tale invocazione avviene una volta su ogni replica, e non prevede valori di ritorno. tazio-caching. Si occupa di far sì che le copie degli oggetti condivisi possedute dai WRM siano aggiornate rispetto a quelle degli

4 RM, quando queste sono modificate da transazioni originate da nodi diversi. Realizzando un proxy dinamico intorno alle copie di oggetti condivisi, ne gestisce l invalidazione e l aggiornamento secondo due diversi possibili protocolli (write-update o write-invalidated) tazio-transactions. Realizza la logica transazionale del sistema, comprendendo la gestione della memoria condivisa, l implementazione dei protocolli di controllo di concorrenza per le transazioni, la coordinazione tra WRM e RM nell accesso agli oggetti condivisi, fino alla realizzazione del protocollo di commit atomico utilizzato dal cluster di RM per garantire la correttezza del sistema. Per ulteriori dettagli si veda la sezione TAZIO-NETWORKING Come accennato nella sezione precedente, scopo del sottosistema di C/S networking è implementare un server basato su TCP che sia in grado di gestire un largo numero di connessioni, e di scalare in maniera adeguata all aumentare di queste. Un ulteriore requisito fondante che sta alla base della realizzazione di questo componente è il desiderio di fornire un componente riutilizzabile indipendentemente dal protocollo applicativo utilizzato, e il cui comportamente fosse ampiamente configurabile a seconda dello scenario d suo. In tazio questo componente viene utilizzato principalmente sui Replica Managers per gestire le richieste provenienti dai WRM. Data la natura del sistema, pensato per essere utilizzato da una grande quantità di clienti contemporaneamente, era necessario evitare che si avesse un primo collo di bottaglia a partire dal request handling. Una versione leggera di questo componente gira anche su ogni Weak Replica Manager per permettere al sottosistema di cache di contattarli e notificare loro le eventuali invalidazioni di oggetti condivisi. La scelta di utilizzare TCP come protocollo di comunicazione tra i WRM e gli RM nasce dall analisi dello scenario di deployment tipico per cui il sistema è pensato: un cluster di RM geograficamente vicini (verosimilmente nella stessa LAN), contattati da un numero elevato di WRM sulla cui locazione non si fa nessuna assunzione. Le garanzie che TCP offre riguardo alla consegna e all ordinamento dei messaggi, sebbene non strettamente necessarie per la correttezza del sistema (vedi sezione 6), rappresentano una comoda assunzione di partenza: in questo modo, ad esempio, il sistema può rilevare quando un messaggio non è consegnabile al suo destinatario, ed in tal caso provvedere se necessario a reindirizzarlo ad un altra replica nel cluster. Per soddisfare il requisito di scalabilità rispetto al numero di connessioni, utilizzare il classico schema thread-persocket sarebbe stato largamente inefficiente: all aumentare delle connessioni, ed in modo proporzionale dei thread dedicati a gestirli, si introdurrebbe un pesante collo di bottiglia rappresentato dallo scheduling dei thread. Anziché dedicare un thread all ascolto bloccante di eventi su ogni socket, tazio utilizza uno schema basato sull idea di socket non bloccanti, introdotte dal framework Java NIO [6, 4] : un thread si blocca in attesa di connessioni su una ServerSocket e, una volta creata una Socket connessa con un client, registra il canale ad essa associata su un oggetto dedicato al dispaching delle richieste. Il dispatcher, a sua volta, possiede un thread di controllo che sfrutta il servizio di demultiplexing offerto dal sistema operativo ospite (e.g. la select() nei s.o. unix) per essere notificato di eventi sui canali che gestisce. All arrivo Figure 4: Layout del sottosistema di networking di dati su un canale, poi, metterà in esecuzione un handler utilizzando un thread proveniente da un pool di dimensioni limitate. All handler spetterà di gesitre i dati in ingresso secondo la sua logica ed eventualmente generare una risposta. (Vedi figura 4) Vista la natura a stream delle socket non bloccanti, ovviamente non è detto che all handler associato ad una socket arrivi volta per volta un messaggio intero: in linea di principio spetta a lui bufferizzare i dati ricevuti e riconoscere, a seconda del protocollo applicativo che utilizza, un messaggio completo. Questo può risultare complicato e fastidioso da fare a livello di codice applicativo: siccome il sistema presuppone che i messaggi scambiati siano incapsulati in oggetti java, è stato previsto un handler astratto che gestisce la ricezione e la deserializzazione di oggetti, e che i componenti di più alto livello possono estentedere per aggiungere la loro logica di protocollo. Dualmente sono stati previste delle classi lato cliente che gestiscono la serializzazione dei messaggi da inviare. Ultima caratteristica che vale la pena citare è il fatto che l handler astratto appena citato può essere configurato per ricevere e inviare messaggi compressi utilizzando gzip, rendendo così possibile un considerevole risparmio di traffico di rete. 6. TAZIO-TRANSACTIONS Il sottosistema di transazioni è la parte che in tazio svolge la vera e propria logica del servizio offerto, ossia la gestione degli oggetti condivisi, della loro replicazione, e di tutti gli aspetti che coinvolgono l accesso transazionale ad essi. Le sue responsabilità possono essere riassunte nei seguenti punti: Fornire un API all utente che gli permetta di creare, rimuovere o recuperare oggetti condivisi dallo Share Fornire un API all utente che gli permetta il controllo esplicito dei boundary delle transazioni

5 Figure 6: Il ciclo di vita di una transazione Figure 5: I proxy in tazio Garantire che tutti gli accessi agli oggetti avvengano nel contesto di una transazione Gestire il completo ciclo di vita delle transazioni Per garantire che ogni accesso avvenga in ambito transazionale, tazio utilizza un semplice sistema basato sul proxying dinamico delle istanze degli oggetti transazionali (fig. 5): tutte le chiamatate su metodi getter e setter degli oggetti condivisi vengono dirottate su un proxy che si assicura che esista una transazione associata al thread chiamante. In caso affermativo associa l azione richiesta a quella transazione, mentre in caso contrario si preoccupa di creare una nuova transazione e richiederne il commit subito alla fine della chiamata. (In verità le chiamate vengono prima intercettate da un ulteriore proxy gestito dal sottosistema di cache, che si preoccupa che l oggetto su cui viene effettuata la chiamata sia aggiornato all ultima versione. Questo aspetto però esula dagli scopi di questa relazione, e verrà approfondito nel lavoro del progettista di quel sottosistema). Il controllo per la rilevazione di conflitti tra transazioni concorrenti è gestito sfruttando un approccio basato sul Multiversion Concurrency Control (MVCC). Ogni thread che accede ad oggetti condivisi in maniera transazionale lo fa lavorando su una sua copia locale (d ora in poi riferita come snapshot). Così facendo ci si assicura che una transazione lavori in isolamento sui suoi snapshot, evitando a priori l interferenza di altre transazioni concorrenti. Evidentemente, però, dovrà essere previsto un meccanismo di individuazione e risoluzione dei conflitti al momento del commit delle transazioni. In tazio ciò avviene sfruttando il versioning degli oggetti e l ordinamento delle transazioni basato su un timestamp logico. Tale sistema si basa su una versione riadattata del metodo delle Versioned Box proposta da Joao Cachopo [2], e verrà illustrato descrivendo il ciclo di vita delle transazioni in tazio. 6.1 Ciclo di vita di una transazione Tutte le transazioni sono - impliciatmente o espliciamente - iniziate da un WRM. Idealmente l interfaccia di una transazione esposta all utente è la seguente interface Transacition UUID id long seqno int status void begin() void commit() void rollback() Ogni transazione deve essere globalmente identificabile in tutto il sistema: una possibile soluzione sarebbe far sì che un componente centralizzato assegni un identificativo unico al momento della creazione della transazione. L approccio che è stato scelto, invece, non lascia questa responsabilità ad un server unico, ma è il WRM che generare localmente uno UUID, di cui è garantita l univocità statistica. Inoltre ad ogni transazione è associato un numero di sequenza, che verrà utilizzato come clock logico per identificare il momento nel quale la traansazione ha iniziato la sua esecuzione. La vita di una transazione passa attraverso una serie di stati, corrispondenti ad altrettante fasi, come illustrato in figura 6. Una transazione che riesce ad effettuare un commit con successo passa attraverso tutte le fasi in maniera sequenziale, mentre ciò non è detto per una transazione che viene abortita. BEGINNING. Quando un thread chiama il metodo Transaction.begin(), viene generato un nuovo UUID per la transazione appena creata, e viene inviato un messagio al RM a cui il WRM è attualmente connnesso, informandolo della sua intenzione di iniziare una nuova transazione. Il Replica Manager risponde a questa richiesta ritornando un Initial Sequence Number da assegnare alla transazione: queto numero corrisponde al Sequence Number dell ultima transazione completata con successo che abbia effettutato operazioni di scrittura su quel Replica Manager (i.e. non vengono contate le transazioni di sola lettura per il conteggio). Questo numero rappresenta un clock logico che colloca la transazione appena iniziata in un punto preciso nel tempo, e servirà ad individuare - al momento della verifica dei conflitti - le transazioni che hanno eseguito concorrentemente. Va fatto notare che il Sequence Number assegnato ad una transazione in questa fase non è definitivo, e può cambiare durante la fase di COMMIT come sarà descritto in seguito. Se un messaggio di richiesta di inizio transazione, o la sua risposta, sono persi per qualsiasi motivo il WRM può inviare di nuovo la stessa richiesta allo stesso, oppure ad un altro, RM dato che tale richiesta non altera lo stato interno dei server. Durante questa fase, inoltre, il sistema di cache si assicura che ogni oggetto presente nella cache locale al cliente sia aggiornato alla sua ultima versione, o - in caso negativo - invalidato.

6 Una volta che il client riceve un messaggio di risposta, e la transazione un suo sequence numeber, essa passa nella fase RUNNING. RUNNING. Questa fase coincide con l esecuzione vera e propria della transazione, ed è svolta completamente dal WRM che l ha originata. Al primo accesso ad un oggetto ne viene recuperata un istanza attraverso il sistema di cache, e ne viene immediatamente creato uno snapshot ed associato alla transazione. Tutte le letture e le scritture effettutate sull oggetto condiviso verranno d ora in poi effettuate sullo snapshot, così garantendo l isolamento delle operazioni della transazione. È ovvio però che, dal momento che diverse transazioni possono essere in esecuzione concorrentemente, due (o più) di loro potrebbero voler modificare un insieme di oggetti coincidenti allo stesso tempo: se una di queste fa commit prima delle altre, gli snapshot letti dalle altre transazioni diventano invalidi, e dunque tali transazioni vanno abortite. Questo controllo avviene in due fasi separate, durante le fasi di LOCAL VERIFICATION e GLOBAL VERIFICA- TION. LOCAL VERIFICATION. La fase RUNNING termina non appena ad una transazine viene chiesto di fare commit. A questo punto questa deve essere controllata per individuare conflitti con altre transazioni ad essa sovrapposte. Tale verifica utilizza un protocollo per il controllo dei conflitti all indietro (backward validation): la transazione che si sta verificando viene confrontata contro le sole transazioni che hanno fatto commit con successo mentre essa era nello stato di RUNNING. D ora in poi questo sottoinsieme di transazioni sarà riferito come l insieme delle transazioni overlapping. Come sarà spiegato a breve il meccanismo dei sequence number permette di identificare tale sottoinsieme come quello delle transazioni committed aventi un sequence number strettamente maggiore dell initial sequence numebr della transazione in verifica. La backward validation controlla che una transazione non abbia letto proprietà da oggetti che una delle transazioni overlapping ha scritto durante il loro commit. Più precisamente, ad ogni transazione sono associati due insiemi: un read set (RS), contentente gli identificativi degli oggetti letti un write set (WS), consistente degli identificatori degli oggetti scritti Quando una transazione Tv entra nella fase di verifica essa viene abortita se esiste una transazione overlapping Ti tale che: (Tv.RS intersect Ti.WS) is not empty Durante la fase di LOCAL VERIFICATION questo algoritmo è applicato alle sole transazioni locali al WRM che ha generato la transazione. Per garantire la sua correttezza, l intera verifica va eseguita in una sezione critica. Si noti che, da solo, questo step non assicura che una transazione non sia in conflitto con altre transazioni overlapping originate su altri Weak Replica Manager, e dunque è necessario eseguire una validazione globale. Le transazioni che superano questa verifica passano dunque nello stato di GLOBAL VERIFICATION, le altre vanno direttamente nella fase di ROLLBACK. GLOBAL VERIFICATION. In questa fase il cluster di Replica Manager è informato delle modifiche che una transazione intende apportare alla memoria condivisa, e prova a validarle rispetto a tutte le altre transazioni overlapping del sistema. La fase di GLOBAL VERIFICATION inizia quando un WRM fa una richiesta di commit al Replica Manager al quale è correntemente connesso. Insieme alla richiesta viene serializzato un oggetto che descrive la transazione di cui si vuole fare il commit, comprendente le modifiche da apportare in caso di successo. Questa richiesta deve essere inviata al più ad un Replica Manager del cluster, anche in caso di mancata risposta. Infatti se accadesse che un messaggio di risposta fosse perso, e un WRM reinviasse la richiesta di commit ad un altro Replica Manager, potrebbe accadere che la transazione sia duplicata. Al momento della ricezione, il Replica Manager diventa il Transaction Manager per quella transazione: sarà responsabile di propagare la transazione agli altri RM del cluster, e di informare il suo cliente del risultato del processo di commit. Per raggiungere la proprietà di one-copy serializability (i.e. tutte i RM condividono un ordine in cui serializzare le transazioni) tutte i Replica Manager del cluster devnono validare tutte le transazioni nello stesso ordine ed il risultato della validazione deve coincidere. Questa proprietà è realizzato sfruttando un protocollo di terminazione bastato sull atomic broadcast 1, che verrà meglio illustrato nella sezione 6.2. Il processo di verifica su ciascun Replica Manager riflette del tutto quello descritto per la fase di LOCAL VERIFICA- TION, ma questa volta una transazione è validata rispetto a tutte le transazioni concorrenti presenti nel sistema; se una transazione non passa questa validazione essa va abortita, e passa nella fase di roll back. Al contrario se la verifica termina con successo la transazione è pronta per terminare il suo commit e passa nella fase COMMITTING. COMMITTING. Dopo aver passato la verifica globale una transazione è pronta per fare commit. Si noti che è necessario che le transazioni entrino nella fase di COMMIT nello stesso ordine in cui sono state validate, ed anche in questo caso, devono farlo una alla volta: per questo motivo il codice che esegue le due fasi è racchiuso in un unica sezione critica. La prima operazione durante questa fase è impostare il sequence number definitivo di una transazione: queto corrisponde al suo initial sequence number incrementato di uno se la transazione ha eseguito operazioni di scrittura. Come fatto notare precedentemente, questo passo permette - a tempo di verifica - di identificare immediatamente l insieme delle transazioni che si sovrappongono temporalmente: infatti, siccome il sequence number iniziale di una transazione corrisponde a quello dell ultima transazione conclusa con successo, una transazione già conclusa sarà temporalmente sovrapposta ad un altra se e solo se essa possiede un 1 In questo documento i termini broadcast e multicast vengono usati - impropriamente - in maniera intercambiabile, ma in entrambi i casi ci si riferisce al multicast di un messaggio ai membri del cluster

7 sequence number strettamente maggiore del initial sequence number dell altra. Successivamente, il Replica Manager procede aggiornando gli oggetti nella memoria condivisa: quelli modificati sono marcati con un numero di versione che coincide con il sequence number della transazione che sta facendo il commit, rendendo così possibile capire quale transazione ha modificato per ultimo un oggetto. A questo punto tutti i RM avranno preso una decisione finale (ed uguale) sull esito della transazione, ma il WRM ancora non ha ricevuto un acknowledgment: questo è ciò che discrimina pesantemente i Weak Replica Manager come parte non attiva nelle transazioni distribuite. Infatti se, ad esempio, il client dovesse guastarsi dopo aver inviato una richiesta di commit, la transazione potrebbe concludersi positivamente anche a sua insaputa. In ogni caso, a decisione presa, il Transacion Manager per una transazione informa il WRM che l ha originata sul suo esito con un messaggio di acknowledgment. Come appena sottolineato questo messaggio può venir perso senza compormettere o alterare l esito della transazione, e sta nella logica del Weak Replica Manager investigare sull esito di una transazione di cui non ha ricevuto acknoledgment. Alla fine di questa fase, inoltre, il sistema di cache sarà incarciato di invalidare (o aggiornare) le copie in cache dei WRM che possedevano repliche degli oggetti condivisi appena modificati. ROLLING BACK. Una transazione può entrare nella fase di ROLL BACK per tre diverse ragioni: una chiamata esplicita dell utente al metodo rollback(), un fallimento nella fase di LOCAL VERIFICATION, oppure un fallimento nella fase di GLO- BAL VERIFICATION. Nei primi due casi, siccome la transazione non ha mai abbandonato il WRM che l ha originata, è sufficiente scartare la transazione; nel terzo caso, invece, il Replica Manager che aveva preso in consegna la richiesta di commit deve notificare il WRM proprietario della transazione del fallimento dlla verifica. 6.2 Il protocollo di commit atomico Per coordinare il commit delle transazioni distribuite tra il cluster di Replica Manager, tazio esplora un protocollo di terminazione basato sull atomic broadcats [5], piuttosto che utilizzare un protocollo di coordinazione tradzionale quale 2PC o 3PC. Nel momento stesso in cui un RM riceve una richiesta di commit da un client, procede ad inoltrare tale richiesta a tutti i membri del cluster con un messaggio di broadcast atomico. L uso del broadcast atomico garantisce che: se un RM corretto riceve una richiesta di commit r, allora tutti gli altri membri del gruppo riceveranno r se un RM corretto riceve una richiesta di commit r prima di un altra richiesta r, allora tutti gli altri i membri del gruppo riceveranno r prima di r Queste due proprietà, insieme, garantiscono che tutti i Replica Manager corretti riceveranno lo stesso insieme di richieste di commit, e lo riceveranno nel medesimo ordine. È evidente che in questo modo, validando le transazioni nello stesso ordine in cui sono ricevute, ogni RM le verificherà rispetto allo stesso insieme di transazioni precedenti. Ciò garantisce che tutti i Replica Manager concorderanno sull esito della verifica, e dunque che lo stato della replica della memoria condivisa che gestiscono sarà passo dopo passo consistente con quello delle altre repliche. Il vantaggio di usare un protocollo del genere rispetto all uso di un protocollo di coordinazione tradizionale, è notevole: in primo luogo la sua adozione semplifica incredibilmente la realizzazione della replicazione in quanto, supponendo di disporre di un implementazione dell atomic broadcast, non c è bisogno di scrivere neanche una riga di logica di coordinazione. Inoltre, soprattutto nel caso di un elevato numero di membri del cluster, il numero di messaggi scambiati per raggiungere la terminazione è decisamente minore, soprattutto nel caso in cui il multicast avvenga sfruttando IP Multicast: in tale situazione i messaggi necessari sarebbero 1 messaggio punto punto al sequencer più un singolo messaggio di broadcast. Uno svantaggio evidente dell implementazione di atomic broadcast basata su sequencer è l introduzione di un importante collo di bottiglia sul nodo che riveste il ruolo di sequencer, ma evidentemente il problema è rimandato all implementazione della primitiva di broadcast ad ordinamento totale, e nulla vieta di implementarla usando algoritmi a sequencer mobile, oppure ad ordinamento distribuito, che - pur aumentando i messaggi scambiati - risolvono il problema del collo di bottiglia. 7. VALUTAZIONE Abbiamo provato il primo prototipo del sistema su 7 macchine ciascuna dotata di un processore Intel Core2 Duo E7400 (2.80 Ghz), 2Gb di memoria primaria, sistema operativo Ubuntu Linux 9.04 (kernel linux 2.6.x a 64 bit), e Java HotSpot 64-Bit Server VM nella implementazione della Sun. Tutte le macchine erano connesse via Ethernet alla stessa rete locale. Purtroppo sia il numero limitato di macchine che il fatto che esse fossere collegate ad una stessa LAN non si prestano bene all analisi di un sistema che tra ha come primo obiettivo la scalabiltà rispetto ad un elevato numero di clienti, e che vuole riuscire a fornire una qualità del servizio soddisfacente anche a clienti fisicamente localizzati lontano dai cluster. Nonostante ciò sono stati eseguiti una serie di test per valutare il comportamento del sistema sotto diversi punti di vista. Tutti i sottosistemi di tazio sono predisposti per esporre un interfaccia di management a runtime, sfruttando la tecnologia Java Management Extensions (JMX): in particolare ogni nodo pubblica una serie di MBean che espongono all esterno diversi indicatori sul funzionamento runtime del sistema, tra cui statistiche sulle prestazioni ed informazioni sulla configurazione. Alla fine di ogni prova effettuata un nodo si è preoccupato di raccogliere i dati dagli MBean Server delle macchine sotto test, e di farne il log su file in un formato convenientemente importabile 2 Il codice di tutti i test svolti si basa sull uso di un semplicissimo tipo di oggetto transazionale, che vuole mimare la semantica di un semplice contatore mettendo a disposizione nella sua intefaccia una sola semplice proprietà di tipo intero read-write: 2 Tutti i risultati dei test sono disponibili all indirizzo todj6c8ndak7zofntye6wha&output=html

8 Figure 7: Un contatore per ogni WRM, numero di commit medio al secondo Figure 8: Un contatore per ogni WRM, tempo di commit medio lato public interface Counter int void setvalue(int newvalue); } A seconda dei risultati che si intendeva validare e verificare, tale oggetto viene usato in maniera diversa e con accessi a diversi livelli di concorrenza dalle applicazioni sui Weak Replica Manager. 1RM vs 2RM - Niente concorrenza. Il primo test è volto a verificare l influenza della numerosità di membri del cluster di Replica Manger sulle prestazioni del sistema. Per questo motivo è stato predisposto uno scenario a concorrenza di transazioni nulla, evitando così che la presenza di rollback inficiasse i risultati. L applicazione sui nodi dei WRM consiste in un ciclo senza attese che - dopo aver aggiunto un istanza di Counter (ciascuna diversa per ogni nodo) nella memoria condivisa - lo incrementa ad ogni iterazione fino a fargli raggiungere il valore di 300. Il test è stato ripetuto prima con un solo RM e variando il numero di WRM contemporaneamente attivi (da 1 a 5), poi aggiungendo un secondo Replica Manager nel cluster e ripetendo le stesse prove. Il primo grafico (fig. 7) mostra il numero medio di transazioni per secondo completate dai Weak Replica Manager. Come prevedibile all aumentare del numero di WRM connessi le prestazioni degradano leggermente ma comunque si mantengono tra i 13 e i 14.5 commit al secondo. Interessante è notare come l aggiunta di un secondo nodo nel cluster, lasci praticamente inalterate le prestazioni del sistema, confermando come il protocollo di commit utilizzato effettivamente non pesi in gran misura sulle prestazioni. Di più le prestazioni con 2 RM risultano essere anche leggermente migliori, probabilmente a cuasa del fatto che il carico delle connessioni client-server con i WRM è distribuito tra i due nodi. La figura 8 invece mostra il tempo medio di verifica e commit di una transazione lato RM, sempre al variare del numero di WRM e RM. Anche in questo caso le differenze di tempistiche tra la configurazione con 1 e 2 RM sono minime (meno di 3 Figure 9: Un contatore condiviso, percentuale di transazioni con commit millisecondi), ed ancora la configurazione con due Replica Manager si dimostra migliore. 2RM - Alta Concorrenza. Un secondo interessante test è quello volto a misurare gli effetti di uno scenario ad alta concorrenza sulle prestazioni del sistema. In questo caso le applicazioni sui nodi dei WRM condivodono un singolo contatore, ed iterativamente provano ad incrementare il suo valore fino al valore massimo di 300. Per simulare un utilizzo più realistico del sistema tra una transazione e l altra ogni WRM si ferma e attende un valore casuale di tempo compreso tra 0 e 500 millisecondi. Nel primo grafico (fig. 9) è mostrata la percentuale di transazioni concluse con successo rispetto al totale di transazioni iniziate. Non sorprende che, in uno scenario ad alta contesa del contatore come questo, all aumentare del numero di clienti questa percentuale cali fin sotto il 60%. In figura 11 sono mostrati i dati rilevati circa il tempo medio di durata di una transazione su un WRM (a partire dal begin() fino alla ricezione di una risposta da un RM). Si confrontino questi dati con quelli riportati in figura 10, che mostra lo stesso tipo di rilevazione in uno scenario di test privo di conflitti tra transazioni simile al precedente: la du-

9 Figure 10: Un contatore per ogni WRM, durata delle transazioni medio lato WRM Figure 12: Un contatore condiviso, divisione dei commit tra i WRM connessi al sequencer e gli altri Figure 11: Un contatore condiviso, durate delle transazioni medio lato WRM rata media di una transazione in presenza di conflitti risulta in generale peggiore. Ciò è facilmente attribuibile all intervento del sistema di cache, che deve invalidare e aggiornare il valore del contatore quando è modificato da altri nodi. Questo test si è inoltre rivelato essere particolarmente degno di nota, in quanto ha messo in luce una interessante conseguenza dell implementazione del multicast ad ordinamento totale utilizzata. Come accennato precedentemente il prototipo sviluppato utilizza un multicast atomico basato sull uso di un sequencer fisso: questo ruolo è rivestito da uno dei Replica Manager che il framework JGroups elegget a coordinatore del cluster. Il grafico in figura 12 mostra a confronto la percentuale di transazioni totali completate con successo dai WRM connessi al sequencer, contro quelle completate con successo dagli altri. Si vede come il 64% degli incrementi al contatore sono effettuati dai primi. Investigando i motivi di questa disparità, si è scoperto che effettivamente i nodi del sequencer effettuavano un numero di richieste di commit decisamente maggiore rispetto a quelle degli altri nodi (figura 13), all incirca nella stessa percentuale del numero di commit completati. Questo rappresenta evidentemente un pesante squilibrio rispetto alla qualità del servizio offerta ai clienti del sistema, che risulta pesantemen- Figure 13: Un contatore condiviso, richiest di commit tra i WRM connessi al sequencer vs gli altir te dipendente dal RM a cui si è connessi. Sebbene ciò non vada comunque ad inficiare la funzionalità del sistema, si tratta comunque di una proprietà poco desiderabile: possibili soluzioni sono l uso di un nodo dedicato al solo ruolo di sequencer (i.e. che non accetta transazioni), usare un implementazione con sequencer mobile, oppure un multicast atomico con responsabilità di ordinamento distribuito [3]. 1RM - 2WRM - Alta Concorrenza Locale. L ultimo test vuole verificare la bontà e l effettiva utilità della fase di LOCAL VERIFICATION, in cui transazioni di cui si rilevano conflitti locali sono abortite prima di essere inviate ai RM remoti. Sono state sviluppate due varianti della verifica locale: la prima esegue l algoritmo di validazione e la richiesta di commit remoto in un unica sezione critica; ciò significa che una transazione alla volta (per ogni WRM) può essere in commit su un RM. La seconda variante, invece, separa la fase di verifica locale dalla richiesta remota che in questo modo può essere effettuata in parallelo per più di una transazione. La seconda viarante, rispetto alla prima, ha lo svantaggio di non riuscire

10 Figure 14: Efficacia della verifica di conflitti locali: percentuale di conflitti rilevati localmente Figure 15: Efficacia della verifica di conflitti locali: tempo totale di test a rilevare tutti i conflitti che sorgono localmente siccome una transazione che è in GLOBAL VERIFICATION non viene inclusa nel set di transazioni overlapping nella fase di validazione. Al contrario della prima variante però permette di parallelizzare le richieste di rete, comunque garantendo la correttezza del sistema dal momento che i conflitti non rilevati globalmente vengono comunque individuati nella fase di GLOBAL VERIFICATION remota. Questo test vuole mettere a confronto le due alternative, e per fare ciò utilizza un deployment costituito da un singolo Replica Manager, e due Weak Replica Manager che tentano di incrementare concorrentamente un singolo contatore condiviso. In più su ciascun WRM l incrementare del contatore è portato avanti da una serie di thread che lavorano a loro voltaconcorrentemente, generando conflitti locali. Il grafico in figura 14 mostra il rapporto tra il numero di rollback locali, ed il numero totale di rollback; la linea rossa si riferisce alla variante con una singola sezione critica, mentra quella azzura a quella con due parti separate. Come previdibile la variante ad una singola sezione critica riesce sempre a rilevare un maggior numero di conflitti localmente, anche se all esplodere del numero di thread la differenza diventa non troppo marcata. In realtà però la differenza di prestazioni in termini di tempo totale di test non si è rivelata così evidente, in quanto la possibilità di parallelizzare le richieste riesce a sopperire al numero di conflitti non rilevati localmente. La figura 15 illustra chiaramente questo fenomeno, ed in più fa notare come all aumentare dei thread per WRM, aumentando il numero dei conflitti, il tempo totale di test inizia a crescere rapidamente, dopo essere stato inizialmente avvantaggiato dalla parallelizzazione delle operazioni. 8. CONLUSIONI Lo sviluppo di applicazioni fortemente distribuite impone forti requisiti di coordinazioni tra i nodi partecipanti alle applicazioni. L astrazione di una memoria distribuita con semantica transazionale, abilita la comunicazione e la coordinazione tra processi remoti in maniera semplice e priva delle difficoltà inerenti alla programmazione concorrente. Il sistema proposto si pone come una valida soluzione al probleme di condividere informazioni ed accedervi in maniera concorrente in questo tipo di scenari, in più implementanto meccanismi ad hoc che permettono di offrire un servizio ad alta affidabilità ai propri clienti. Inoltre la distinzione che introduce tra i partecipanti alla memoria condivisa gli permette di rendere il sistema adottabile anche da un numero considerevole di partecipanti senza per questo imporre forti limitazioni sulle garanzie offerte. Nonostante gli ottimi risultati dimostrati nei test effettuati sul sistema, rimangono tuttavia ampi margini di miglioramento per il sistema, e numerose varianti da esplorare. Tra queste l uso di diverse implementazioni di multicast atomico, la valutazione di diversi protocolli per la comunicazione tra WRM e RM, e la valuatazione di diversi tipi di deployment. Inoltre il sistema rimane immaturo per quanto riguarda la gestione di situazioni problematiche come la rilevazione di failure di Replica Manager, il ripristino di Replica Manager dopo un crash, e la gestione di network partitions. Si spera di riuscire presto a colmare questi vuoti. 9. REFERENCES [1] T. Abdellatif, E. Cecchet, and R. Lachaize. Evaluation of a group communication middleware for clustered J2EE application servers. Lecture Notes in Computer Science, pages , [2] J. Cachopo and A. Rito-Silva. Versioned boxes as the basis for memory transactions. Science of Computer Programming, 63(2): , [3] X. Défago, A. Schiper, and P. Urbán. Total order broadcast and multicast algorithms: Taxonomy and survey. ACM Computing Surveys (CSUR), 36(4): , [4] R. Hitchens. Java Nio. O Reilly & Associates, Inc. Sebastopol, CA, USA, [5] F. Pedone, R. Guerraoui, and A. Schiper. Exploiting atomic broadcast in replicated databases. Lecture Notes in Computer Science, pages , [6] D. Schmidt. Reactor: an object behavioral pattern for concurrent event demultiplexing and event handler dispatching