Progettazione ed Implementazione di un Protocollo di Replicazione Semi-Attiva

1. Progettazione ed Implementazione di un Protocollo di Replicazione Semi-Attiva Anno Accademico 2005/2006 tesi di laurea relatore Ch.mo prof. Domenico Cotroneo correlatore Ing. Armando Migliaccio candidato Paolo Maresca Matr. 534/939

2. Contesto e Problematica • La ricerca di affidabilità e disponibilità per i servizi automatizzati in rete • la rete introduce la problematica dei guasti di nodi e canali • tolleranza ai guasti • replicazione software vs. replicazione hardware • La replicazione software è una delle soluzioni più utilizzate per tollerare i guasti • le principali tecniche di replicazione • le garanzie di consistenza • la comunicazione di gruppo La tolleranza ai guasti nei moderni sistemi distribuiti grazie alla replicazione software

3. La replicazione Semi-Attiva Una tecnica di replicazione che non prevede entità totalmente passive • La tecnica di replicazione prevede una distinzione di ruoli delle n repliche del servizio • processamento deterministico e non deterministico • Replica Leader • Repliche Follower • L’elezione del leader del gruppo non segue uno schema fisso o predetermintato dalla specifica • un guasto del leader provoca l’elezione di uno nuovo • membership e aggiornamento sono tenuti con le primitiva del GCT • I vantaggi: • si supera la difficoltà legata all’elabora- zione non deterministica • bassa ridondanza di elaborazione • tolleranza ai guasti • Gli svantaggi: • difficoltà implementativa

4. SARP(SemiActive Replication Protocol) Le caratteristiche salienti del protocollo di replicazione progettato, implementato e verificato sperimentalmente • È un protocollo interoperabile per la replicazione software semi attiva • Garantisce la replicazione del servizio su macchine distribuite eterogenee per hardware e/o software • Garantisce la tolleranza ai guasti di tipo crash per il servizio replicato • Garantisce la totale trasparenza al client rispetto alla replicazione del servizio • Si raggiunge la capacità di replicare il servizio su nodi eterogenei grazie alle scelte implementative, in particolare: • Si è scelto il linguaggio Java per l’implementazione che garantisce la portabilità del codice • Si è scelto utilizzare un middleware CORBA tra clienti e serventi che garantisce trasparenza all’eterogeneità dei nodi • Si è scelto di utilizzare il GCT Appia per garantire la consistenza forte delle rep- liche • Appia assicura flessibilità

5. Il protocollo SARP è basato su una architettura two-tier Prevede un ulteriore livello di gestione dello scenario di replicazione, che: Sovraintenda il livello di replicazione del servizio Gestisca a seguito di guasti del leader, l’elezione di uno nuovo Il livello di gestione possiede entità anch’esse replicate per evitare single point of failure Il livello di gestione non è interposto tra clienti e serventi L’architettura di SARP Una descrizione di alto livello dell’architettura e delle funzionalità implementate dai componenti architetturali • Le principali componenti architetturali sono: • CMC (Connection Manager Control): gestisce la replicazione dei gestori • CRC (Connection Replica Control):prevede un duplice comportamento, si comporta da se- rver quando appartiene al manager-tier e da client quando appartiene al replication-tier • CCS (Connection Client Service):gestisce la comunicazione basata su CORBA e quella basata su Appia

6. L’esecuzione del Protocollo Uno scenario che cattura una esecuzione del protocollo in presenza di guasti misti • Si sottolinea che: • I processi g1,g2,g3 sono le repliche di gestione del sistema • I processi p1,p2,p3 sono le repliche del servizio • Il processo c1 è il client che verifica sperimentalmente il protocollo • Con <reqx,opx> e <reqx,resx> si indicano le coppie per richiesta e risposta

7. I Risultati Sperimentali 1/2 Una vista dell’analisi sui risultati sintetici ottenuti dalle misure sperimentali di latenza • Si confrontano i risultati ottenuti dalle tre tipologie di esperimento: • Assenza di guasti • Guasti solo dei leader • Guasti misti di leader e follower

8. I Risultati Sperimentali 2/2 Una vista dell’analisi statistica operata sui risultati sintetici ottenuti dalle misure sperimentali • Si confrontano le frequenze relative delle classi di campioni di latenza • l’analisi non presenta gli outliers • confronta su 200 classi le tre dis- tribuzioni di frequenza

9. Appia e la Comunicazione di Gruppo Una panoramica sulla offerta per la comunicazione di gruppo del GCT Appia • Appia è un protocol Kernel estremamente flessibile: • Ha core ed API scritti in Java • Il core implementa i protocolli mediante stack com- ponibili da micro protocolli: la QoS • Consente di implementare nuovi micro protocolli • La comunicazione avviene mediante lo scambio di eventi • Appia offre servizi standard per la comunicazione di gruppo, poi personalizzabili • Primitive per la comunicazione di gruppo: • Reliable Multicast / Broadcast • View Synchronous Multicast • La reliability offerta dalle primitive standard può essere variata sostituendo opportunamente i micro protocolli

10. Le Conclusioni Gli obiettivi che si sono raggiunti e i possibili sviluppi che si ipotizzano • Contributi della Tesi • Studio e Analisi del GCT Appia • Realizzazione di una architettura interoperabile per la replicazione software • Valutazione Sperimentale dell’implementazione prodotta • Sviluppi Futuri • utilizzo del protocollo come architettura-testbed • al variare dei GCT • al variare delle proprietà di ordinamento delle primitive di comunicazione di gruppo