L’idea che sta alla base della replicazione software `e quella di replicare server su host differenti connessi tra loro tramite una rete di comunicazione, in modo da permettere ad un client di usufruire di un servizio connettendosi a diverse repliche server. Queste tecniche di replicazione software sono realizzate tipicamente in un approccio two-tiers (2T): un client (client-tier) interagisce direttamente con un insieme di repliche server che offrono lo stesso servizio (end-tier).
Se il servizio fornito `e stateless1, migliorare la disponibilit`a del servizio si riduce nel lasciare che il client reinvochi trasparentemente la richiesta su tutte le repliche server, prima di ricevere un’eccezione. Se invece il servizio `e stateful, c’`e il prob-lema di garantire la consistenza tra gli stati delle repliche a fronte di guasti.
La replicazione attiva ([49]), passiva ([10]), semi-passive ([15]) e “a quorum” ([27, 38]) sono le tecniche 2T pi`u comuni per aumentare la disponibilit`a di server stateful. Il risultato di impossibilit`a di Fischer, Lynch e Patterson (FLP
impos-sibility result [25]) rende impossibile realizzare server stateful replicati su sistemi
asincroni, come ad esempio Internet. Al contrario, si pu`o notare che le repliche di un servizio stateless possono essere collocate in un sistema asincrono, visto che non necessitano di un protocollo di agreement.
1Il risultato di una richiesta dipende solo dalla richiesta da processare.
Il capitolo `e strutturato come segue: nella sezione 3.1 verrano illustrate due pro-priet`a architetturali che definiscono l’ambito in cui i processi di un sistema dis-tribuito possono essere posizionati; nella sezione 3.2 viene proposto l’approccio a tre livelli per la replicazione, con lo scopo di superare alcuni limiti delle classiche tecniche di replicazione.
3.1 Propriet`a architetturali per la replicazione
software
Il mantenimento della consistenza dello stato di repliche di oggetti stateful `e un requisito fondamentale per la replicazione, ma si possono definire altre propriet`a architetturali per la replicazione che riguardano sia i client che le repliche e che si calano nella natura del modello di sistema in cui queste entit`a vivono:
P1 (Client/Server-Asynchrony): un client (e rispettivamente un server)
gira-no in un sistema distribuito senza alcuna assunzione temporale (per esempio un sistema distribuito asincrono);
P2 (Client-Autonomy): un client non deve intervenire in nessun protocollo
distribuito di coordinazione che coinvolga altri client e/o repliche server con lo scopo di mantenere la consistenza delle repliche del servizio.
La propriet`a P1 implica che i client e le repliche server di servizi stateful replicati possono essere distribuite su sistemi asincroni (come ad esempio Internet), nello stesso modo fatto per servizi stateless replicati. Invece la propriet`a P2 perme-tte di implementare client molto leggeri (thin client), in modo da aumentare lo spettro di dispositivi su cui questi client possono girare (ad esempio cellulari, PDA, etc.).
Si pu`o facilmente notare che le tecniche di replicazione precedentemente citate, non rispettano la propriet`a P1, in quanto impongono ai server (ed alcune volte ai client) di girare in un sistema parzialmente sincrono. D’altra parte, in schemi di replicazione attiva implementati attraverso la primitiva di total order multicast,
3.2. REPLICAZIONE SOFTWARE A TRE LIVELLI 27
in cui `e il client che stabilisce l’ordine in cui verranno consegnati i messaggi (per esempio [19]), anche la propriet`a P2 non `e soddisfatta.
3.2 Replicazione software a tre livelli
La replicazione software a tre livelli (three-tier replication - 3T) include la logica di replicazione in un “livello software intermedio” (mid-tier ) posto tra client e server replicato, che ha il compito di assicurare la linearizzabilit`a all’esecuzioni delle repliche del servizio replicato (end-tier, Figura 3.1).
mid-tier end-tier client tier C1 C2 Cm Replication Logic R1 R2 Rn Sistema Distribuito Asincrono Sistema Distribuito Parzialemente Sincrono Sistema Distribuito Aincrono
Figura 3.1: Architettura base a 3 livelli.
In questa architettura, un client manda la richiesta al mid-tier, il quale la in-oltra alle repliche server rispettando la logica di replicazione implementata. Le repliche dell’end-tier processano la richiesta, mandando il risultato dell’operazione invocata al mid-tier, che alla fine la restituisce al client. In Figura 3.2 `e mostrata una semplice interazione client/server nel caso di end-tier replicato attivamente.
Per assicurare la terminazione dell’interazione client/server anche in presenza di guasti, i processi del mid-tier dovranno essere tolleranti ai guasti: in parti-colare, se la replica del mid-tier che sta gestendo l’interazione client/server si guasta, un’altra replica dovr`a terminare l’interazione, allo scopo di assicurare la consistenza delle repliche dell’end-tier, anche a fronte di guasti. In generale
C1 C2 M1 M2 M3 R1 R2 R3 Client-tier Mid-tier End-tier richiesta risultato risultato richiesta
Figura 3.2: Scambio di messaggi per end-tier replicato attivamente.
questo implica che il mid-tier dovr`a mantenere uno stato (replicato): questo sta-to potrebbe includere informazioni sull’ordinamensta-to delle richieste del client, il processo del mid-tier responsabile dell’interazione tra client e server, etc.
Inoltre, c’`e la necessiat`a in generale di un protocollo distribuito di agreement per le repliche del mid-tier: questo implica l’assunzione di sistema parzialmente
sincrono solo ed esclusivamente per il mid-tier.
Questo approccio soddisfa entrambe le propriet`a definite nella sezione precedente (sezione 3.1):
• un client interagisce direttamente solo col mid-tier, l’unico responsabile
del mantenimento della consistenza dell’end-tier; quindi la propriet`a P2 (Client-Autonomy) `e soddisfatta;
• le repliche server e i client non necessitano di nessun protocollo di agreement;
i client hanno solo bisogno di un semplice meccanismo di ritrasmissione per far fronte a guasti del mid-tier o a ritardi nella consegna dei messag-gi. Analogalmente, le repliche server implementano semplici funzionalit`a aggiuntive (ad esempio filtraggio dei duplicati), oltre a quelle offerte dal servizio messo a disposizione; la propriet`a P1 (Client/Server-Asynchrony) `
3.2. REPLICAZIONE SOFTWARE A TRE LIVELLI 29
C’`e da sottolineare il fatto che l’approccio a tre livelli produce una netta sepa-razione tra la gestione della replicazione e il reale servizio implementato. Rispetto all’approccio classico a due livelli si possono individuare i seguenti vantaggi:
• un client (ma anche un server) potrebbe comunicare con le entit`a del
mid-tier con interazioni point-to-point, seguendo cos`ı il semplice paradigma di interazione asincrona richiesta/risposta;
• disaccoppiando la gestione dell replicazione dal servizio, c`e la possibilit`a di
modificare lo stile di replicazione senza impattare sul client. Per esempio si potrebbe modificare “al volo” lo stile di replicazione dell’end-tier, passando da replicazione attiva a replicazione passiva ([1]);
• le repliche dell’end-tier sono poco accoppiate (loosely coupled): le repliche
non scambiano messaggi fra loro; inoltre, le repliche server potrebbe non aver bisogno di sapere quale schema di replicazione `e implementato dal mid-tier;
• l’approccio a tre livelli limita l’uso di “group communications toolkit” solo