Supporto per la replicazione attiva di servizi Progetto per il corso di Reti di Calcolatori LS Montanari Mirko Matr: 0000171360 Scopo del progetto Creare una estensione di Jeri, meccanismo di invocazione remota di Java, in modo da consentire una (quasi) trasparente replicazione attiva di un servizio remoto. Attualmente Java non fornisce meccanismi per replicare servizi offerti attraverso invocazione remota. Utilizzando l’infrastruttura sviluppata è molto semplice convertire un servizio qualunque in un servizio replicato. In questa presentazione … Funzionamento ed architettura del sistema Come è stato realizzato estendendo un meccanismo di invocazione remota di Java Piccolo servizio di esempio Replicazione Attiva Normalmente una invocazione remota in Java è strutturata come segue: Invocazione remota di un servizio Nel caso della replicazione attiva si vuole che la richiesta di servizio non sia eseguita soltanto da un calcolatore, ma da un gruppo di repliche. Replicazione attiva: Tutti eseguono l’operazione richiesta e si accordano per il risultato da restituire al cliente Requisiti del supporto Replicazione attiva Maggiore resistenza ai guasti: Se il gruppo è formato da 3t repliche, può tollerare guasti bizantini su t di esse Ognuna delle repliche del servizio può anche implementare algoritmo diversi Supporto trasparente Scrivere un cliente che utilizza un servizio replicato deve essere equivalente a scrivere un normale cliente che usa un servizio remoto nomale. Adattare un servizio alla replica deve essere una operazione semplice e legata alla logica del servizio stesso. Ciò che non dipende dalla logica del servizio deve essere svolto dal supporto. Funzionamento del sistema Il cliente deve interagire come se stesse dialogando con un servizio non replicato Cliente Interazione con un coordinatore Fasi dell’interazione: 1. Arrivo richiesta 2. Coordinazione copie 3. Esecuzione 4. Accordo finale 5. Risposta al cliente Richiesta con id univoco Servizio dei nomi Coordinatore Ingresso ed uscita di repliche dal gruppo è gestito da ogni replica comunicando con il master E in caso di guasto? Guasti al sistema Durante il funzionamento del sistema possono verificarsi guasti. Condizione di funzionamento del sistema: Almeno una replica ed un servizio dei nomi raggiungibile dai client. Tipologie di guasto tollerate: Sistema di 3t risorse tollera t guasti bizantini Il guasto non deve però presentarsi nella fase di raccolta e distribuzione delle richieste da parte del coordinatore. E’ tollerato un guasto fail-safe. Network partitioning: ogni partizione che rispetta la condizione di funzionamento può continuare ad erogare il servizio Guasti possibili: Guasto ad uno dei membri del gruppo Fallimento del coordinatore Network partitioning Nuova view Coordinatore Nuova view Fallimento del coordinatore (Server) Coordinatore (fallito) ID: 12 Coordinatore eletto fra i membri del gruppo 4: election Group Member ID: 9 Ogni partecipante al gruppo ha un numero univoco che lo coordinator identifica 3: election Elezione attuata attraverso l’algoritmo bully per funzionare con invocazione remota sincrona e bloccante. Group Member ID: 4 coordinator Group Member ID: 1 2: election 1: ping L’errore in un ping fa iniziare il processo di elezione Si accorge di essere il membro con il più alto id della view e si dichiara nuovo coordinatore Fallimento del coordinatore (Client) Al fallimento del coordinatore anche il cliente perde il suo interlocutore. Deve essere fatta una nuova interrogazione al servizio dei nomi per ottenere il riferimento al nuovo coordinatore Procedura effettuata in automatico dallo stub del cliente. La presenza di un identificativo univoco di ogni richiesta impedisce che la richiesta sia eseguita più volta Semantica at-most-once id: 342 id: 342 Vecchio coordinatore Nuovo coordinatore Partizionamento della rete Il partizionamento è un fallimento che dividono le rete in due partizioni. I calcolatori che sono all’interno della stessa partizione possono comunicare fra di loro, ma non con altri contenuti in altre partizioni. Ogni partizione deve contenere un servizio dei nomi e una delle repliche New view elezione Coordinatore ping Coordinatore Merge di due partizioni Quando un guasto di partizionamento viene risolto, il sistema si trova contemporaneamente ad avere due coordinatori. Inoltre ognuno dei due gruppi di repliche è evoluto indipendentemente l’uno dall’altro. Necessario un coordinamento per riportare il sistema ad avere un solo coordinatore ed un solo stato. Il calcolo dello stato finale viene demandato alla implementazione del servizio. unregister Coordinatore ID: 32 Richiede stato e Coordinatore view corrente ID: 56 Invio della nuova view e stato a tutti Calcolo del nuovo stato Realizzazione: integrazione con Jeri Jeri è una implementazione di RMI alternativa alla standard di Java. Basato su Jini Consente l’estendibilità del modo in cui l’invocazione viene effettuata. Il progetto modifica il funzionamento di: Skeleton: per implementare la distribuzione della richiesta ricevuta dal cliente alle repliche Stub: per consentire la ricerca del nuovo coordinatore al fallimento del vecchio Stub e Skeleton di Jeri A differenza di RMI standard stub e skeleton vengono generati dinamicamente. Lo stub è scaricato dal client alla richiesta del riferimento al coordinatore Stub e skeleton di Jeri divisi in livelli: Trasport Layer: codica della richiesta e della risposta in maniera che possa essere inviata attraverso la rete Object Identification Layer: Più oggetti possono essere attivati sullo stesso trasporto. Questo layer si occupa di indirizzare la richiesta all’oggetto giusto. Invocation Layer: A lato client rende trasparente l’invocazione di un servizio remoto e, a lato server, invoca l’effettivo metodo di business. Livelli di Jeri Invocazioni remote con Jeri Cliente Programma Cliente Coordinatore Group Member Servizio Servizio Group Invocation handler Invocation handler Object identification layer Group invocation dispatcher Invocation dispatcher Trasport level Trasport level Servizio Object identification layer Group Member Livelli standard di Jeri Livelli standard di Jeri Applicazione di esempio Implementato un semplice servizio di Rubrica per dimostrare il funzionamento del supporto Oltre ai metodi di business ogni servizio deve implementare: setState(Serializable state): utilizzato per impostare lo stato iniziale della replica. getState(Serializable state): utilizzato dal coordinatore per avere lo stato attuale della propria replica del servizio. joinState(Serializable state): in caso di merge di due partizioni al servizio viene passato lo stato dell’altra partizione. L’applicazione deve provvedere a creare uno stato che tenga conto di entrambi (se possibile ..) Conclusioni Il supporto sviluppato permette la replicazione attiva di un servizio java, attraverso una estensione di Jeri. Resistente ai guasti: Può tollerare vari tipi di guasto alle repliche ed è in grado di funzionare anche in caso di partizionamento Trasparente: Non richiede nessuna modifica ad un client jeri e poche modifiche nella implementazione del servizio. Sviluppi futuri Supporto nella concorrenza delle invocazioni. Attualmente un solo client alla volta può invocare il servizio Scaricare il coordinatore dall’onere di dover rispondere alle richieste di sola lettura. Potrebbero essere gestite dalla replica più vicina Utilizzo di meccanismi per la comunicazione di gruppo (multicast) per le comunicazioni fra il coordinatore e il resto del gruppo.