Implementazione e analisi di un protocollo per la replicazione attiva

Transcript

1 Università degli Studi di Roma La Sapienza Facoltà di Ingegneria Tesi di Laurea in Ingegneria Informatica Dicembre, 2002 Implementazione e analisi di un protocollo per la replicazione attiva Stefano Cimmino

2

3 Università degli Studi di Roma La Sapienza Facoltà di Ingegneria Tesi di Laurea in Ingegneria Informatica Sessione Autunnale Dicembre, 2002 Implementazione e analisi di un protocollo per la replicazione attiva Stefano Cimmino Relatore Co-Relatore Prof. Roberto Baldoni Ing. Carlo Marchetti Revisore Ing. Andrea Vitaletti

4 Indirizzo dell Autore: Stefano Cimmino Viale Spagna, Cond. Sagittario Frosinone, ITALIA

5 Indice 1 Introduzione 1 2 Il problema della replicazione Modelli di sistema Sincronia Modelli di guasto Replicazione software Criteri di consistenza Tecniche di replicazione Comunicazioni di gruppo Servizi di group membership Servizi di multicast Servizi di state transfer Consenso e problemi di agreement Il problema del consenso Risolvere il consenso Replicazione attiva a tre livelli Motivazioni Architetture a due livelli per la replicazione software Replicazione software nei sistemi a larga scala Una architettura a tre livelli per la replicazione software Replicazione attiva a tre livelli Specifica Panoramica sull architettura Modello di sistema Il Sequencer Service Il protocollo del middle-tier Discussione i

6 ii INDICE 4 Il total order multicast nei group toolkit Il total order multicast Specifiche alternative Algoritmi di total order I group toolkit Classificazione rispetto all architettura Classificazione rispetto al total order multicast Analisi delle prestazioni Discussione Interoperable Replication Logic Una panoramica su CORBA La Common Object Request Broker Architecture Fault Tolerant CORBA Panoramica sull architettura di IRL Il prototipo di IRL Una interazione client/server in IRL Outgoing Request GateWay Object Group Handler Incoming Request GateWay Analisi delle prestazioni Piattaforma di test ed esperimenti preliminari Parametri degli esperimenti Prestazioni dell ORGW e della replicazione stateless Prestazioni della replicazione stateful Osservazioni rilevanti Discussione Conclusioni Contributi Sviluppi futuri

7 Elenco delle figure 2.1 La tecnica di replicazione attiva La tecnica di replicazione passiva Spiegazione del view synchronous multicast Una architettura a due livelli per la replicazione software Una architettura a tre livelli per la replicazione software Una architettura a tre livelli per la replicazione software attiva Una esecuzione priva di guasti del protocollo per la replicazione attiva a tre livelli Una esecuzione in presenza di guasti del protocollo per la replicazione attiva a tre livelli Scenari che violano la proprietà di Uniform Agreement Problemi dovuti ad un indebolimento della prorietà di Order nella specifica del total order multicast Gerarchia delle specifiche per il total order multicast Varianti comuni degli algoritmi basati su sequencer Varianti degli algoritmi basati sul protocollo di Skeen Architettura dei group toolkit Schema di interazione usato nei test dei group toolkit Prestazioni dei group toolkit in funzione di R e C Prestazioni dei group toolkit in funzione di C per R= Componenti principali dell architettura CORBA Operazioni one way e callback Client e Server Portable Request Interceptor L architettura di IRL Un esempio di distribuzione dei componenti di IRL Una interazione client/server priva di guasti in IRL Confronto tra un client CORBA standard e un client IRL Architettura del componente Object Group Handler iii

8 iv ELENCO DELLE FIGURE 5.9 Passi principali della computazione di una replica OGH Architettura interna di un membro di un object group Prestazioni della replicazione stateless (C=1, M=2) Prestazioni della replicazione stateful in funzione di M (C=1, H=2) Prestazioni della replicazione stateful in funzione di H (C=1, M=2) Latenza introdotta dal Sequencer in funzione di H (C=1, M=2) Prestazioni della replicazione stateful in funzione di C (M=2, H=2) Latenza dovuta al Sequencer in funzione di C (M=2, H=2)

9 Elenco delle tabelle 2.1 Classi di failure detector Specifiche per il total order multicast Classificazione dei group toolkit rispetto alla loro architettura Specifica del total order multicast supportata dai group toolkit Replicazione dei componenti di IRL Prestazioni di una interazione client/server base Parametri degli esperimenti Prestazioni di IRL in funzione di M Prestazioni di IRL in funzione di H Tempo impiegato dal Sequencer in funzione di H Prestazioni di IRL in funzione di C (approccio primary) Prestazioni di IRL in funzione di C (approccio active) Latenza del Sequencer in funzione di C v

10 vi ELENCO DELLE TABELLE

11 Capitolo 1 Introduzione L utilizzo di servizi automatizzati è aumentato sensibilmente negli ultimi anni. Basti pensare per esempio ai servizi di commercio elettronico, ai servizi per transazioni bancarie, al controllo industriale, ecc. Data questa diffusione, si ritiene ormai inaccettabile che un servizio sia reso indisponibile a causa di un guasto. In particolare, qualità come affidabilità e disponibilità sono considerate fondamentali per qualsiasi sistema. L affidabilità è definita come il tempo medio tra due guasti consecutivi, mentre la disponibilità rappresenta la probabilità che, in un qualsiasi momento, il sistema sia funzionante. Esistono diverse tecniche che consentono di raggiungere tali qualità. Una di esse è la tolleranza ai guasti, la quale, basandosi sull assunzione che i guasti possono sempre verificarsi nonostante il tentativo di prevenirli, propone soluzioni che permettono la continuità del servizio anche in presenza di tali eventi indesiderati. Tolleranza ai guasti tramite replicazione software. La replicazione software è una delle possibili soluzioni per ottenere tolleranza ai guasti. L idea è quella di replicare i componenti software di un sistema, ossia creare diverse copie dello stesso componente, allo scopo di aumentarne il grado di affidabilità e disponibilità. Il modello di interazione considerato è il modello client/server, secondo il quale un programma client, per usufruire di un determinato servizio, invia una richiesta verso una applicazione remota, il server, che implementa tale servizio. Il server si fa carico di processare la richiesta, eventualmente modificando il proprio stato interno, ed invia poi il corrispondente risultato al client. In questo contesto, per aumentare affidabilità e disponibilità, il servizio viene replicato, creando varie copie dell applicazione server, chiamate repliche, le quali vengono distribuite su diversi host. Il sistema deve assicurare che lo stato di ciascuna replica rimanga consistente con quello delle altre, in modo da consentire al client di accedere ad una replica qualsiasi per usufruire del servizio. In particolare, si parla di consis- 1

12 2 CAPITOLO 1 tenza forte quando il sistema fornisce al client l illusione di comunicare con una singola entità logica. Tecniche di replicazione. Le tecniche di replicazione consentono di garantire consistenza tra le repliche di un servizio. Negli ultimi venti anni sono state proposte varie tecniche di replicazione che consentono di ottenere consistenza forte delle repliche, come per esempio la tecnica di replicazione attiva (chiamata anche approccio state-machine) [Lam78, Sch93], quella passiva (chiamata anche approccio primary-backup) [BSTM93], la semi-passiva [DSS98] e la semi-attiva [Pow91]. Le tecniche principali sono quella attiva e quella passiva. Replicazione attiva. Nella replicazione attiva, tutte le repliche effettuano le stesse operazioni nello stesso ordine, mantenendo perciò identico il loro stato. Il vantaggio principale di questa tecnica di replicazione consiste nel basso tempo di risposta, anche in presenza di guasti. Tuttavia le repliche devono necessariamente essere deterministiche: il risultato di una richiesta deve dipendere solo dalla richiesta stessa e dallo stato corrente della replica che la processa. In altre parole, ciò significa che la replica si comporta come una macchina a stati finiti deterministica. Questa condizione è necessaria per fare in modo che tutte le repliche producano lo stesso risultato per una data richiesta. Replicazione passiva. Nella replicazione passiva, una particolare replica (chiamata primary) riceve tutte le richieste dei client, definisce l ordine della loro esecuzione e aggiorna le altre repliche (chiamate backup), per mantenere consistente il loro stato. In caso di guasto del primary, il processamento delle richieste si arresta fino all elezione di un nuovo primary, che viene scelto tra le repliche backup. Per questa ragione, la replicazione passiva può comportare un tempo di risposta più basso in caso di guasti del primary. Tuttavia questa tecnica richiede una quantità minore di risorse di calcolo rispetto alla replicazione attiva e consente di avere repliche nondeterministiche, in quanto solo il primary processa le richieste, inviando i corrispondenti aggiornamenti dello stato alle repliche backup. I group communication toolkit. L implementazione delle tecniche di replicazione pone diverse difficoltà, legate soprattutto alla necessità di mantenere la consistenza delle repliche. I group communication toolkit rappresentano un conveniente strumento per risolvere questo tipo di problemi: utilizzando l astrazione di gruppo, ossia un insieme di processi cooperanti, detti membri, essi forniscono un insieme di servizi e primitive di comunicazione che semplificano l implementazione delle tecniche di replicazione software. Per esempio, il servizio di group

13 3 membership permette a ciascun membro del gruppo di sapere l attuale composizione della vista (view), ossia l insieme dei membri attivi e partecipanti alla computazione, mentre varie primitive di comunicazione uno-a-molti (cioè multicast) permettono ai membri di scambiarsi messaggi con varie garanzie di ordinamento e affidabilità. In particolare, la primitiva di total order multicast assicura che tutti i membri consegneranno lo stesso insieme di messaggi nello stesso ordine, e può quindi essere utilizzata per implementare la replicazione attiva. Allo stesso modo, la replicazione passiva necessita di (i) un servizio di group membership, che permetta alle repliche backup di individuare il guasto del primary ed eleggerne uno nuovo, e (ii) una primitiva di view synchronous multicast, che assicura che un messaggio inviato all interno di una vista verrà consegnato nel contesto della stessa vista da tutti o da nessun membro, evitando quindi che un vecchio primary aggiorni erroneamente una replica backup dopo che un nuovo primary è già stato eletto. Il problema del consenso. In generale, ogni tecnica di replicazione che deve assicurare consistenza forte delle repliche, richiede di risolvere un problema di agreement, cioè di accordo, come il total order multicast o il view synchronous multicast. Si può dimostrare (vedi [CT96, GS97b, GS01]) che risolvere il problema di ottenere un total order multicast o un view synchronous multicast, necessari per l implementazione della replicazione attiva e passiva, rispettivamente, equivale a risolvere il problema del consenso. Nel problema del consenso, ogni processo propone un valore e tutti i processi non guasti devono essere d accordo nel decidere uno stesso valore, che deve essere scelto tra quelli proposti. Tuttavia il risultato di impossibilità, noto come FLP, stabilisce che se si considera un sistema in cui i processi possono guastarsi e in cui non si possono fare assunzioni sui tempi di (i) trasmissione dei messaggi scambiati tra diverse entità distribuite, e di (ii) esecuzione delle richieste, il problema del consenso non può essere risolto [FLP85]. Ciò significa che per poter implementare una qualsiasi tecnica di replicazione che richieda consistenza forte, le entità coinvolte nella soluzione del problema di agreement devono necessariamente essere distribuite in un sistema che presenti un qualche livello di sincronia, come ad esempio una LAN. In particolare, se le uniche entità presenti sono i client e le repliche del servizio, come accade nelle architetture a due livelli, non è possibile distribuire entrambi su una rete WAN, come Internet, in cui i tempi di ritardo dei messaggi e di esecuzione delle richieste sono finiti ma non predicibili. Esistono diverse soluzioni per la replicazione software che assumono un sistema asincrono, ma possono però essere utilizzate solo per applicazioni che richiedono minori garanzie di consistenza. Per esempio, i group toolkit basati su un servizio di group membership partizionabile consentono il partizionamento del gruppo e il progresso della computazione in ciascun sot-

14 4 CAPITOLO 1 togruppo, aumentando la disponibilità di varie applicazioni che non richiedono consistenza forte. Architetture a tre livelli per la replicazione software. Le architetture a tre livelli per la replicazione software consentono di distribuire i client e le repliche anche su una WAN con basse garanzie di predicibilità riguardo i ritardi nella trasmissione e nel processamento dei messaggi. Ciò è reso possibile evitando che i client e le repliche partecipino ad algoritmi per la soluzione di problemi di agreement. In una architettura a tre livelli per la replicazione software, i client e le repliche sono disaccoppiati, cioè non interagiscono direttamente tra di loro, ma piuttosto comunicano attraverso uno strato software intermedio (middle-tier) altamente affidabile e tollerante ai guasti. In particolare il middle-tier riceve le richieste dei client (client-tier) e le inoltra verso le repliche (end-tier), insieme ad altre informazioni che consentono a ciascuna replica di eseguire le richieste indipendentemente dalle altre repliche, ma in modo tale da garantire consistenza forte. Le repliche inviano poi il risultato al middle-tier, che lo inoltra verso i client. In questo modo, né i client né le repliche prendono parte ad algoritmi per la soluzione di problemi di agreement. Al contrario, è il middle-tier a risolvere tali problemi, per esempio stabilendo un ordine totale sulle richieste, nell ambito di una tecnica di replicazione attiva, oppure definendo il primary tra le repliche, nell ambito di una tecnica di replicazione passiva. Ciò significa che solamente il middle-tier deve quindi essere distribuito in un sistema con qualche livello di sincronia, mentre invece i client e le repliche possono essere distribuiti anche in sistemi asincroni, come Internet, preservando comunque le garanzie di consistenza forte. Contributo. Il contributo di questa tesi consiste (i) nell aver effettuato una classificazione ed una valutazione delle prestazioni di alcuni tra i group toolkit attualmente disponibili, e (ii) nell aver utilizzato il più adatto di tali group toolkit per la realizzazione di un prototipo di una infrastruttura software per la tolleranza ai guasti denominata Interoperable Replication Logic (IRL), che adotta una architettura a tre livelli per la replicazione software. Più in dettaglio, i group toolkit sono stati classificati rispetto alle caratteristiche architetturali e al servizio di total order multicast offerto, su cui si è poi basata l analisi delle loro prestazioni. Inoltre è stato definito il design di alcuni componenti di IRL, la cui implementazione ha poi consentito di esaminare, tramite una accurata analisi prestazionale, le caratteristiche del protocollo per la replicazione attiva a tre livelli adottato dal prototipo.

15 5 Organizzazione della tesi. La tesi è strutturata come segue. Il Capitolo 2 introduce i concetti generali usati nel seguito della dissertazione. Il Capitolo 3 motiva e introduce le architetture a tre livelli per la replicazione software, illustrando in particolare un protocollo per la replicazione attiva a tre livelli. Il Capitolo 4 tratta il problema del total order multicast, e fornisce una classificazione rispetto a tale servizio di alcuni tra i group toolkit attualmente disponibili, sui quali viene eseguita una analisi delle prestazioni. Il Capitolo 5 descrive una infrastruttura per la tolleranza ai guasti, chiamata Interoperable Replication Logic, che adotta una architettura a tre livelli per la replicazione software. In particolare viene illustrato il design del prototipo attuale, del quale viene riportata una accurata analisi delle prestazioni. Infine il Capitolo 6 conclude la dissertazione, mettendo in luce i principali risultati del lavoro svolto.

16 6 CAPITOLO 1

17 Capitolo 2 Il problema della replicazione Negli ultimi anni c è stata una notevole diffusione di servizi on-line. Diversi settori, come la finanza, le telecomunicazioni, booking-reservation ecc, forniscono servizi attraverso Internet, ai quali accedono un numero sempre crescente di client. Ciò ovviamente comporta un aumento dei requisiti di alta disponibilità e affidabilità di tali servizi. Una soluzione per raggiungere questi obiettivi consiste nello sviluppare software su hardware replicato tollerante ai guasti. Sebbene questa soluzione sia adatta per alcune classi di applicazioni e sia stata perseguita con successo da alcune compagnie come Tandem e Stratus, fattori economici hanno spinto a cercare una soluzione meno costosa basata sul software. L idea è quella di creare più copie del servizio, chiamate repliche, distribuite su diversi host. Il sistema deve assicurare che lo stato delle repliche rimanga consistente, in modo da consentire al client di accedere ad una replica qualsiasi per ottenere una risposta. Questo capitolo introduce vari concetti legati al problema della replicazione software. In particolare, la Sezione 2.1 introduce i modelli di sistema per i sistemi distribuiti e i modelli di guasto. La Sezione 2.2 tratta il problema della replicazione, descrivendo i criteri di consistenza e le due tecniche principali per la replicazione software, ossia quella attiva e quella passiva. La Sezione 2.3 descrive alcuni servizi utili per la replicazione, offerti dai sistemi per la comunicazione di gruppo (i group toolkit). Infine la Sezione 2.4 tratta il problema del consenso e la sua relazione con i problemi di agreement, legati alla replicazione software. 2.1 Modelli di sistema Un sistema distribuito basato su scambio di messaggi è definito come un insieme finito di processi Π = {p 1... p n }. I processi possono comunicare inviando e ricevendo messaggi attraverso dei canali di comunicazione (o link). I processi e 7

18 8 CAPITOLO 2 i canali possono essere modellati rispetto (i) alle garanzie di sincronia che essi forniscono e (ii) ai tipi di guasto che possono essere osservati nel sistema Sincronia La sincronia di un modello di sistema distribuito è espressa in termini di assunzioni temporali (o assunzioni di sincronia) che caratterizzano il comportamento dei processi e dei canali rispetto al tempo da essi impiegato per completare i loro compiti. In un sistema sincrono le assunzioni temporali definiscono un limite massimo noto sia sul tempo impiegato da un processo per completare un proprio compito, sia sul ritardo di trasmissione dei messaggi. Si assume che il sistema soddisfi sempre questi vincoli. Al contrario, in un sistema asincrono non esiste alcun limite noto (e di conseguenza nessuna assunzione temporale) sul tempo impiegato dai processi e dai canali per effettuare le proprie azioni. Si assume solo che il sistema alla fine completerà i compiti che sono stati richiesti. I modelli di sistema sincrono e asincrono rappresentano i due estremi di una collezione di modelli, che possono essere ottenuti indebolendo le assunzioni temporali di un modello di sistema sincrono. Questi sistemi vengono chiamati parzialmente sincroni. Per esempio, è possibile assumere che esistano dei limiti massimi non noti sulle velocità relative dei processori e sul tempo di trasmissione dei messaggi, che valgono in ogni istante, oppure che questi limiti alla fine saranno per sempre validi. I sistemi parzialmente sincroni sono particolarmente adatti per la soluzione di problemi che non possono essere risolti nei sistemi asincroni. Notiamo inoltre che molti approcci pratici di solito assumono un sistema parzialmente sincrono nel quale la maggior parte dei messaggi verosimilmente viene trasmessa entro una durata δ nota, e la maggior parte dei processi verosimilmente completa il proprio compito entro un tempo τ noto [CMA97, FC99a, FC99b]. In questi sistemi, i processi e i canali alternano periodi di stabilità, cioè periodi durante i quali i processi e i canali si comportano in accordo ai vincoli temporali, e periodi di instabilità, cioè periodi in cui i vincoli temporali non sono rispettati da qualche processo o canale Modelli di guasto In generale, sia i processi che i canali di un sistema distribuito possono esibire guasti, cioè possono iniziare ad avere un comportamento non conforme alla loro specifica.

19 2.1. MODELLI DI SISTEMA 9 Un processo si dice guasto se il suo comportamento si discosta da quello prescritto dall algoritmo che sta eseguendo; altrimenti si dice corretto. Un modello di guasto specifica il modo in cui un processo guasto si può discostare dal proprio algoritmo. I modelli di guasto sono i seguenti [HT93]: Crash: un processo guasto smette per sempre di funzionare, cioè termina l esecuzione di ogni attività e in particolare smette di inviare e ricevere messaggi; Send omission: un processo guasto termina prematuramente, oppure omette occasionalmente di inviare messaggi che era supposto inviare; Receive omission: un processo guasto termina prematuramente, oppure omette occasionalmente di ricevere messaggi che gli sono stati inviati; General omission: un processo guasto termina prematuramente, oppure omette occasionalmente di inviare e ricevere messaggi; Arbitrary (detto anche Byzantine o malicious): un processo guasto può esibire un comportamento arbitrario, per esempio può inviare messaggi caotici agli altri processi; Arbitrary con message authentication: un processo guasto può esibire un comportamento arbitrario, ma è disponibile un meccanismo di autenticazione dei messaggi (per esempio la firma digitale). Questo consente ai processi corretti di validare le asserzioni di altri processi riguardo alla attuale ricezione di messaggi inviati da processi corretti. I modelli di guasto che vanno dal modello crash al modello general omission vengono comunemente chiamati modelli di guasto benigni. Inoltre i processi di un sistema sincrono possono essere soggetti anche al seguente modello di guasto: Timing failure: un processo guasto si discosta dalla propria specifica temporale, per esempio eccedendo il tempo massimo predefinito per eseguire uno step (nel qual caso si ha una performance failure). Allo stesso modo, i canali di comunicazione possono esibire guasti, per esempio scartando ogni messaggio (guasti di tipo crash), oppure omettendo il trasporto di qualche messaggio (guasti di tipo omission), o comportandosi maliziosamente alterando il contenuto di qualche messaggio (guasti di tipo arbitrary).

20 10 CAPITOLO Replicazione software L idea alla base della replicazione software è quella di mettere in esecuzione diverse repliche di un dato servizio in processi differenti di un sistema distribuito, consentendo a un processo client di accedere ad ognuna di esse, aumentando così la probabilità di ottenere una risposta. Un servizio può mantenere uno stato interno (servizio stateful) o meno (servizio stateless). Nell ultimo caso il risultato di una richiesta dipende solo dal contenuto della richiesta stessa, per cui per incrementare la disponibilità del servizio è sufficiente consentire al client di accedere al più elevato numero possibile di repliche. Nel caso più generale, cioè quando si ha un servizio stateful, nasce il problema di mantenere la consistenza delle repliche Criteri di consistenza Mantenere la consistenza tra un insieme di repliche di un dato servizio richiede di definire un criterio di consistenza. Un criterio di consistenza definisce il comportamento di un insieme di processi interagenti attraverso oggetti concorrenti condivisi [HW90], per esempio definisce i risultati restituiti dalle repliche di un servizio a fronte di una richiesta di un client. Sono stati proposti diversi criteri di consistenza nella letteratura, come ad esempio la consistenza causale [AHN + 94], la consistenza sequenziale [Lam79], la serializzabilità [BHG87], e la linearizzabilità [HW90]. Questi criteri possono essere suddivisi in forti e deboli. I criteri di consistenza forte consentono di fornire al client l illusione di interagire con un servizio non replicato. Al contrario, i criteri di consistenza debole richiedono ai client di conoscere l esatta semantica del servizio replicato, riducendo quindi la trasparenza della replicazione del servizio. La consistenza sequenziale, la serializzabilità e la linearizzabilità sono criteri di consistenza forte 1. Nel seguito considereremo la linearizzabilità come nostro criterio di consistenza forte, essenzialmente per motivi pratici. La linearizzabilità è infatti più facile da implementare rispetto agli altri criteri di consistenza. Per essere in grado di progettare tecniche generiche di replicazione che assicurino consistenza forte, è quindi necessario definire delle condizioni sufficienti che assicurino la linearizzabilità per un generico servizio stateful replicato. È possibile mostrare che per assicurare linearizzabilità di un servizio replicato è sufficiente che le repliche siano d accordo sul loro stato interno quando viene restituito un 1 Si può dimostrare che assicurare linearizzabilità implica anche assicurare consistenza sequenziale e causale, per cui la linearizzabilità è un criterio più forte degli altri due. Al contrario, la linearizzabilità e la serializzabilità sono difficili da confrontare a causa del loro diverso campo di applicazione [HW90, AW94].

21 2.2. REPLICAZIONE SOFTWARE 11 risultato per una richiesta di un client. Informalmente, ciò si può ottenere facendo in modo che le repliche aggiornino il loro stato in una maniera (i) ordinata e (ii) atomica. Atomicità significa che tutte o nessuna delle repliche corrette esegue un aggiornamento dello stato, mentre ordinamento significa che ciascuna replica esegue gli aggiornamenti del proprio stato nello stesso ordine prima di guastarsi. Queste condizioni saranno formalizzate nel contesto della replicazione attiva nella Sezione Tecniche di replicazione Negli ultimi venti anni sono state proposte diverse tecniche di replicazione in grado di assicurare consistenza forte delle repliche. Esempi sono la replicazione attiva (o approccio state-machine) [Lam78, Sch93], passiva (o primary-backup) [BSTM93], coordinator-cohort [BJRA85], semi-passiva [DSS98], e semi-attiva [Pow91]. Nel seguito descriveremo le tecniche di replicazione attiva e passiva, che sono quelle più utilizzate. Replicazione attiva. Nella replicazione attiva tutte le repliche eseguono lo stesso insieme di richieste nello stesso ordine prima di guastarsi. In particolare, ogni richiesta è eseguita da ogni replica, la quale restituisce un risultato per essa (Figura 2.1). Per assicurare consistenza forte è necessario che (i) ogni replica processi ciascuna richiesta dei client nello stesso ordine delle altre repliche prima di guastarsi, e che (ii) le repliche siano deterministiche. Il determinismo delle repliche assicura che le repliche abbiano uno stato identico dopo aver completato il processamento di una richiesta, senza richiedere ulteriori comunicazioni tra di esse. client replica replica servizio replicato replica processamento deterministico Figura 2.1: La tecnica di replicazione attiva Il vantaggio principale di questa tecnica di replicazione consiste nel basso tempo di risposta in caso di guasti. Inoltre la replicazione attiva permette di

22 12 CAPITOLO 2 tollerare guasti arbitrari. Infatti, se il servizio è replicato da n repliche, e si assume che esistano almeno n+1 repliche corrette, è sufficiente che il client 2 aspetti n+1 risposte identiche per tollerare guasti arbitrari. Lo svantaggio di 2 questa tecnica riguarda invece la necessità di un numero elevato di risorse di calcolo, dal momento che tutte le repliche processano ogni richiesta. Inoltre può essere utilizzata solo se le repliche sono deterministiche. Replicazione passiva. Nella replicazione passiva (Figura 2.2) una particolare replica (chiamata primary) riceve tutte le richieste dei client e definisce l ordine della loro esecuzione. In particolare, nel momento in cui riceve una richiesta di un client, il primary processa la richiesta, raggiungendo un nuovo stato interno, e successivamente invia dei messaggi di aggiornamento alle altre repliche (chiamate backup), per imporre la consistenza. È facile vedere che se il primary è corretto la replicazione passiva garantisce consistenza forte. Per preservare la consistenza anche in presenza di guasti del primary, il primary stesso deve eseguire gli aggiornamenti assicurando atomicità, cioè che nessuna o tutte le repliche backup ricevano l aggiornamento dello stato corrispondente al processamento di una richiesta di un client. Il primary deve inoltre restituire un risultato al client solo se tutte le repliche backup sono state aggiornate. In questo modo, nel caso in cui il primary si guasti, il nuovo primary può evitare di eseguire una seconda volta la computazione relativa ad una richiesta, cosa che avrebbe condotto ad una violazione della consistenza. Nel momento in cui il primary si guasta, le repliche backup devono eleggere un nuovo primary tra di esse. A questo scopo, le repliche backup devono monitorare il primary per individuarne i guasti. Inoltre, quando viene individuato un guasto del primary, si deve assicurare che una sola replica venga eletta nuovo primary. In altre parole, in ogni istante di tempo deve esistere al più un primary. client replica primary replica backup replica backup aggiornamento atomico servizio replicato Figura 2.2: La tecnica di replicazione passiva La necessità di eleggere un nuovo primary può comportare un tempo di risposta lento in caso di guasti del primary. Tuttavia, siccome solo il primary processa

23 2.3. COMUNICAZIONI DI GRUPPO 13 le richieste dei client e invia aggiornamenti alle repliche backup, la replicazione passiva richiede una quantità inferiore di risorse di calcolo rispetto alla replicazione attiva, e inoltre tollera repliche non-deterministiche. Infine, a differenza della replicazione attiva, la replicazione passiva non è in grado di tollerare guasti arbitrari. 2.3 Comunicazioni di gruppo Varie esperienze [KT91, Bir93, Pow96, GS97a, CKV01] hanno dimostrato che il paradigma delle comunicazioni di gruppo rappresenta un potente strumento per la implementazione di servizi replicati. La nozione alla base di questo paradigma è quella di gruppo, cioè una collezione di processi di un sistema distribuito (chiamati membri) che in qualche modo cooperano tra di loro. Grazie all astrazione di gruppo, un processo può inviare un messaggio ad un gruppo, senza dover nominare esplicitamente tutti i membri che lo compongono. Esistono due diversi tipi di gruppi: gruppi statici e gruppi dinamici. Un gruppo è statico se l insieme dei suoi membri (cioè la membership) non cambia nel tempo. Ciò implica che anche se un membro si guasta, da un punto di vista logico esso rimane sempre un membro del gruppo. In un gruppo dinamico invece, la membership evolve nel tempo, per esempio modificandosi a causa di guasti. Inoltre tipicamente i gruppi dinamici offrono la possibilità di aggregarsi al gruppo o di abbandonarlo, permettendo quindi di gestire dinamicamente l insieme dei processi che prendono parte al gruppo stesso. Un altra distinzione riguarda i gruppi aperti e i gruppi chiusi. In un gruppo chiuso, solo i membri del gruppo possono inviare messaggi ad altri membri del gruppo, mentre invece in un gruppo aperto qualsiasi processo del sistema può inviare messaggi ai membri del gruppo. Nel seguito di questa sezione verranno brevemente descritti alcuni dei servizi più importanti messi a disposizione dai sistemi per la comunicazione di gruppo (group communication toolkit). Per una descrizione più formale di questi ed altri aspetti riguardanti i group toolkit si rimanda a [CKV01] Servizi di group membership Il servizio di group membership è alla base dei sistemi di comunicazione di gruppo che supportano gruppi dinamici (detti anche view-oriented). Esso consente infatti di tenere traccia dei membri del gruppo, che sono rappresentati tramite una vista (view), cioè una collezione univocamente identificata degli identificatori dei membri del gruppo. Una vista può cambiare perché un processo si aggrega

24 14 CAPITOLO 2 al gruppo, o perché un membro abbandona il gruppo, o infine perché un membro è escluso dal gruppo. Nei primi due casi c è una richiesta esplicita del processo, mentre il terzo caso è determinato dal servizio stesso, che si fa carico di monitorare i membri per individuarne i guasti, e in tal caso escluderli dal gruppo. I membri ricevono notifica del cambiamento della membership tramite un evento di cambiamento di vista. Alla ricezione di tale evento, i membri installano una nuova vista. Un servizio di membership può essere partitionable oppure primary component: Primary component membership service. In questo tipo di servizi, per esempio [BvR93, MFSW95], gli identificatori delle viste installate da tutti i membri di un gruppo sono totalmente ordinate. In altre parole, tutti i membri di un gruppo installano la stessa sequenza di viste. Questo implica che tutti i membri devono essere d accordo sulla composizione del gruppo per ciascun cambiamento di vista. Partitionable membership service. In questo tipo di servizi, per esempio [ADKM92a, BDMS98, DMS95, MAMSA94, BDM01], gli identificatori delle viste installate dai processi di un gruppo sono parzialmente ordinati. In altre parole, i membri possono partizionarsi in sottogruppi (un sottogruppo per ogni partizione). Solo i membri dello stesso sottogruppo devono essere d accordo sulla composizione del sottogruppo stesso. Notiamo che anche in un servizio di group membership di tipo primary partition i membri possono partizionarsi, per esempio a causa di un partizionamento fisico della rete. Tuttavia, in questo tipo di servizi, solo un sottogruppo, cioè la partizione primaria, può continuare la propria esecuzione, mentre i membri degli altri sottogruppi o si suicidano (come accade in Isis [BvR93]) oppure rimangono bloccati in attesa di una fusione delle partizioni (come accade in Phoenix [MFSW95]). Notiamo inoltre che la necessità di imporre consistenza forte delle repliche richiede un servizio di group membership di tipo primary component, poiché consentire il progresso in due o più sottogruppi può causare la violazione delle proprietà di ordinamento e atomicità. Di conseguenza, le applicazioni che richiedono consistenza forte delle repliche (per esempio [ADMSM94, GS95, GS97a, Kem02]) comunemente assumono un servizio di tipo primary component. In particolare, un servizio di membership primary component può essere utilizzato per implementare la replicazione passiva: per esempio se si assume che i membri siano ordinati all interno di una vista in accordo ad una regola deterministica, le repliche possono eleggere un primary semplicemente scegliendo il primo membro che compare nella vista.

25 2.3. COMUNICAZIONI DI GRUPPO Servizi di multicast I group toolkit forniscono diversi servizi di multicast con differenti garanzie di affidabilità e ordinamento. Si va infatti dal semplice multicast non affidabile al multicast affidabile con ordinamento causale e totale [HT93, BvR93, CKV01]. Nel seguito ci concentreremo sulle primitive di total order multicast e view synchronous multicast. View Synchronous multicast. Le comunicazioni di tipo view synchronous sono state introdotte in Isis [BJ87, BvR93]. Considerando group toolkit vieworiented, un messaggio viene consegnato a un membro nel contesto di una vista. L idea alla base delle comunicazioni view synchronous è quella di ordinare la consegna dei messaggi rispetto alla installazione di una vista. Rispetto a questa idea, sono state proposte diverse specifiche per il view synchronous multicast (o VScast). Tra di esse, la più restrittiva richiede che un messaggio inviato usando un VScast sia ricevuto da tutti o nessuno dei membri nel contesto della vista in cui è stato inviato [CKV01]. Questa proprietà è stata indicata in diversi modi, per esempio sending view delivery in [CKV01], view synchrony in [BDGS95, MS95] e strong virtual synchrony in [FvR95]. La Figura 2.3 illustra alcuni scenari per spiegare questa definizione. Questi scenari mostrano un gruppo di tre processi p 1, p 2, p 3, ciascuno dei quali ha ricevuto dal servizio di membership la vista v i = {p 1, p 2, p 3 }. p 1 invia poi un messaggio m al gruppo, tramite un VScast nel contesto della vista v i. Successivamente il servizio di membership informa p 2 e p 3 che p 1 ha lasciato il gruppo 2, cosicché p 2 e p 3 installano una nuova vista v i+1 = {p 2, p 3 }. Lo Scenario 1 soddisfa la definizione data di VScast, poiché tutti i membri di v i consegnano m nel contesto di v i. Al contrario, p 2 consegna m nel contesto di v i+1 nello Scenario 2, mentre omette di ricevere m nello Scenario 3, per cui entrambi questi scenari non soddisfano la definizione. Infine, anche lo Scenario 4 non soddisfa la definizione, poiché p 2 e p 3 consegnano m nel contesto di una vista diversa rispetto a quella in cui m era stato inviato. Notiamo che anche uno scenario in cui m non è consegnato da nessun processo soddisfa la definizione. Il view synchronous multicast garantisce atomicità per quanto riguarda la consegna dei messaggi nel contesto di una vista. Questa proprietà è necessaria nella replicazione passiva per garantire atomicità nella consegna degli aggiornamenti inviati dal primary alle repliche backup, ossia per imporre consistenza forte. Siccome il soddisfacimento della proprietà di view synchrony richiede di bloccare l invio e la ricezione dei messaggi durante i cambiamenti di vista, diversi group toolkit implementano proprietà più deboli, come per esempio la same view delivery 3 [CKV01], evitando di dover bloccare l invio e la ricezione di messaggi e 2 La ragione per cui p 1 non fa più parte del gruppo non è influente in questi esempi.

26 16 CAPITOLO 2 p 1 m p 1 m p 2 gruppo p 2 gruppo p 3 p 3 v i ={p 1,p 2,p 3 } v i+1 ={p 2,p 3 } v i ={p 1,p 2,p 3 } v i+1 ={p 2,p 3 } (a) Scenario 1 (b) Scenario 2 p 1 m p 1 m p 2 gruppo p 2 gruppo p 3 p 3 v i ={p 1,p 2,p 3 } v i+1 ={p 2,p 3 } v i ={p 1,p 2,p 3 } v i+1 ={p 2,p 3 } (c) Scenario 3 (d) Scenario 4 Figura 2.3: Spiegazione del view synchronous multicast ottenendo così prestazioni migliori. Tuttavia queste proprietà non sono sufficienti a garantire consistenza forte delle repliche. Total Order multicast. La proprietà di view synchrony riguarda l ordinamento dei messaggi rispetto agli eventi relativi alla installazione delle viste. Tuttavia essa non dice niente riguardo all ordinamento dei messaggi consegnati ai processi nel contesto di una singola vista, o tra i membri di un gruppo statico. In questo contesto, diverse garanzie di ordinamento e affidabilità sono state proposte nella letteratura, per esempio il causal multicast e il total order (o atomic) multicast [BSS91, HT93]. Nel nostro caso ci concentriamo sul total order multicast. Questa primitiva assicura che i messaggi saranno consegnati nello stesso ordine totale ai processi. Nel seguito indicheremo come Dest(m) l insieme dei destinatari del messaggio m. La specifica del total order multicast viene data rispetto a quattro proprietà: Validity, Integrity, Agreement e Order. Ciascuna di queste proprietà, eccetto la Validity, può essere considerata uniforme o meno, dove per uniforme si intende il fatto che la specifica considera tutti i processi, siano essi corretti o 3 La proprietà di same view delivery richiede che se due processi consegnano entrambi un messaggio m, lo fanno nella stessa vista v, che può essere diversa dalla vista in cui il messaggio è stato inviato. Lo Scenario 4 in Figura 2.3 soddisfa questa proprietà.

27 2.3. COMUNICAZIONI DI GRUPPO 17 meno. Questo implica varie alternative per la specifica del total order multicast. Siccome considerare una proprietà uniforme significa eliminare la possibilità che si possano verificare alcuni scenari che possono portare ad inconsistenze, una specifica che considera proprietà uniformi è più forte rispetto ad una che considera proprietà non uniformi. La specifica più forte, che chiamiamo quindi strongest total order, è la seguente: Validity. Se un processo corretto esegue il multicast di un messaggio m, allora qualche processo corretto in Dest(m) alla fine consegnerà m; Uniform Integrity. Per qualsiasi messaggio m, ogni processo p consegna m al massimo una volta, e solo se (i) m è stato precedentemente inviato da qualche processo e (ii) p è un processo in Dest(m); Uniform Agreement. Se un processo consegna un messaggio m, allora tutti i processi corretti in Dest(m) alla fine consegneranno m; Prefix Order. Sia h(p) la storia dei messaggi consegnati dal processo p, ossia la sequenza ordinata dei messaggi consegnati da p. Allora, per qualsiasi coppia di processi p e q, o h(p) è un prefisso di h(q) o viceversa. Notiamo che queste proprietà, dovendo valere anche per processi non corretti, possono essere soddisfatte solo se si assumono modelli di guasto benigni per i processi, per esempio guasti di tipo crash. Nel Capitolo 4 discuteremo alcune alternative più deboli e vedremo come la specifica viene implementata nei group toolkit Servizi di state transfer Un altro importante servizio offerto dai group toolkit è lo state transfer. Questo servizio permette di trasferire lo stato di un membro ad un altro, ed è particolarmente utile quando un nuovo processo si aggrega al gruppo, e il suo stato deve essere allineato con quello dei membri già esistenti. Lo state transfer può essere bloccante o meno 4. Durante uno state transfer bloccante, nessun messaggio è inviato o ricevuto dai membri del gruppo, mentre durante uno state transfer non bloccante i membri possono inviare e consegnare messaggi. Questo può comportare una violazione della consistenza. Tuttavia in alcune applicazioni il fatto di sapere come evolve lo stato interno di una replica a fronte della consegna dei messaggi consente di utilizzare uno state transfer non bloccante, ottenendo un 4 Lo state transfer bloccante e non-bloccante sono anche denotati sincrono e asincrono, rispettivamente [VB98].

28 18 CAPITOLO 2 miglioramento delle prestazioni. Come detto in precedenza, l uso dei group toolkit semplifica enormemente la realizzazione di applicazioni distribuite, come per esempio un servizio reso altamente affidabile tramite la replicazione software. Per questo motivo, il campo delle comunicazioni di gruppo è stato oggetto di una intensa ricerca negli ultimi dieci anni. Questi sforzi hanno prodotto numerosi group toolkit, tra cui Isis [BvR93], Horus [vrbh94, vrbm96], Phoenix [MFSW95], Totem [AMMS + 95, MMSA + 95, MMSA + 96], Transis [ADKM92b, DM96], Ensemble [Hay98], Spread [AS98], Jgroup [BDM01], solo per nominarne alcuni. 2.4 Consenso e problemi di agreement Nella sezione precedente sono state introdotte varie primitive e servizi legati all implementazione delle tecniche di replicazione che impongono consistenza forte. Ognuno di questi strumenti rappresenta un problema di agreement. In generale, imporre la consistenza forte delle repliche implica la soluzione di un problema di agreement. Si può dimostrare che problemi di agreement come il servizio di group membership, il total order e il view synchronous multicast sono equivalenti al problema del consenso [CT96, GS97b, GS01]. L equivalenza di due problemi A e B è definita tramite il concetto di riduzione: un problema B si riduce ad un problema A se esiste un algoritmo R AB che trasforma ogni algoritmo che risolve A in un algoritmo che risolve B. Due problemi A e B sono equivalenti se A si riduce a B e viceversa. Quindi se due problemi sono equivalenti, uno può essere risolto se e solo se anche l altro può essere risolto. Ciò implica che per risolvere il problema di ottenere un total order multicast, o un view synchronous multicast, o un servizio di group membership, è necessario poter risolvere il problema del consenso Il problema del consenso Il problema del consenso [PSL80, Sch85, CT96] è definito su un insieme Π di processi. Ciascun processo p i Π propone un valore v i e tutti i processi corretti devono essere d accordo su una singola decisione, scelta tra i valori proposti. Più formalmente, i processi hanno accesso a due primitive, cioè propose(v) e decide(v), invocate da un processo per proporre un valore v e per decidere un valore v, rispettivamente. Quando un processo esegue propose(v), diciamo che esso propone il valore v. Allo stesso modo, quando un processo esegue decide(v), diciamo che esso decide il valore v. Il consenso è definito dalle proprietà seguenti.

29 2.4. CONSENSO E PROBLEMI DI AGREEMENT 19 Termination. Ogni processo corretto alla fine decide qualche valore. Agreement. Non esistono due processi corretti che decidono diversamente. Validity. Se un processo decide v, allora v era stato proposto da qualche processo. La proprietà di Agreement consente ai processi non corretti di decidere in modo diverso dai processi corretti. Ciò potrebbe essere inaccettabile per alcune applicazioni, perché consente a un processo di propagare una decisione non corretta nel sistema prima di guastarsi. Questa situazione è evitata da una specifica più restrittiva, chiamata consenso uniforme, che si ottiene sostituendo alla proprietà di Agreement la seguente proprietà di Uniform Agreement. Uniform Agreement. Non esistono due processi (corretti o meno) che decidono differentemente Risolvere il consenso La soluzione ad un problema in un sistema distribuito dipende dal modello di sistema assunto, ossia dalle assunzioni di sincronia e dai modelli di guasto ammessi per processi e canali. Esistono diversi algoritmi che permettono di risolvere il problema del consenso in sistemi sincroni, assumendo vari modelli di guasto per processi e canali. Tuttavia nel nostro caso ci concentriamo sui sistemi asincroni. Nel 1985 Fischer, Lynch e Paterson hanno dimostrato che non esiste un algoritmo deterministico in grado di risolvere il consenso in un sistema asincrono se anche un solo processo può guastarsi. Questo risultato (noto come risultato di impossibilità FLP ) può essere giustificato intuitivamente notando che in un sistema asincrono non esiste alcuna nozione di tempo, per cui i processi non sono in grado di stabilire se un altro processo si è guastato, o è diventato lento, oppure i canali sono diventati lenti. Il risultato FLP implica che non è possibile implementare tecniche di replicazione con garanzie di consistenza forte in sistemi asincroni. Negli ultimi venti anni sono state proposte varie soluzioni che cercano di aggirare questa impossibilità, essenzialmente restringendo il modello di sistema asincrono tramite assunzioni addizionali. Queste assunzioni estendono i processi o i canali mediante o (i) randomizzazione, o (ii) failure detector, o (iii) ulteriori assunzioni temporali. Tecniche di randomizzazione. Le tecniche di randomizzazione permettono di risolvere il consenso, sebbene vi sia una probabilità trascurabile di violare la

30 20 CAPITOLO 2 proprietà di terminazione. Ciò si ottiene dotando i processi di particolari operazioni che restituiscono un valore a caso in accordo ad una certa distribuzione di probabilità [Asp02, CD89]. Siccome siamo interessati ad algoritmi deterministici, non considereremo queste tecniche nel seguito. I failure detector. Un failure detector è un oracolo distribuito che fornisce suggerimenti (anche non corretti) a proposito dei processi che hanno subito dei guasti [CT96, CHT96]. Ogni processo p i del sistema ha accesso ad un modulo locale F D i, che monitora gli altri processi nel sistema e mantiene l insieme di quelli che sospetta essersi guastati. Questa informazione può essere non corretta (ad esempio viene sospettato un processo non guasto) e può essere inconsistente (ad esempio F D i sospetta al tempo t un processo p k mentre nello stesso istante di tempo t un altro modulo F D j non sospetta p k ). I failure detector sono caratterizzati in termini di due proprietà, chiamate completeness e accuracy. Completeness. La completezza di un failure detector è relativa alla sua abilità di individuare i processi guasti. La completezza è caratterizzata da una delle seguenti proprietà. Strong Completeness. Ogni processo guasto alla fine è sospettato da tutti i processi corretti. Weak Completeness. Ogni processo guasto alla fine è sospettato da qualche processo corretto. Accuracy. L accuratezza di un failure detector restringe i sospetti non corretti che esso può fare. L accuratezza è caratterizzata da una delle seguenti proprietà. Strong Accuracy. Nessun processo è sospettato prima che si guasti. Weak Accuracy. Qualche processo corretto non è mai sospettato. Eventual Strong Accuracy. C è un tempo dopo il quale nessun processo corretto è mai sospettato da alcun processo corretto. Eventual Weak Accuracy. C è un tempo dopo il quale qualche processo corretto non è mai sospettato da alcun processo corretto. Le otto combinazioni delle proprietà di completezza e accuratezza descritte sopra definiscono le otto classi di failure detector descritte nella Tabella 2.1. Si può dimostrare che, assumendo canali affidabili e un modello di tipo crash per i guasti dei processi, la classe S è la più debole classe che rende possibile la soluzione del consenso in un sistema asincrono con una maggioranza di processi