Fanelli Mario Montanari Marco Salbaroli Francesco

Presentazione sul tema: "Fanelli Mario Montanari Marco Salbaroli Francesco"— Transcript della presentazione:

1 Fanelli Mario Montanari Marco Salbaroli Francesco
Progetto RE.VE.N.GE. CORBA con Replicazione Sistema di Consegna Fanelli Mario Montanari Marco Salbaroli Francesco Professore: Ing. Antonio Corradi Tutor: Ing. Luca Foschini Presentazione di Mario Fanelli Matricola

2 Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
Sommario Architettura del sistema RE.VE.N.GE Il Notification Service di JacORB Aspetti implementativi curati Proxy d’accesso al sistema Monitoraggio del Master Discovery del Master e protocollo di elezione Prestazioni del sistema Conclusioni e sviluppi futuri Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

3 Architettura del sistema RE.VE.N.GE
Requisiti Sistema di distribuzione di notizie basato su tecnologia CORBA Supporto a modalità di interazione da parte dei clienti sia di tipologia pull che push Aumento dell’affidabilità da ottenere mediante replicazione del servizio di consegna Notification Service come motore del sistema di distribuzione delle notizie Utilizzo dell’implementazione dell’ORB e del Notification Service offerta da JacORB Linee guida adottate durante il progetto Trasparenza al fallimento del sistema di consegna verso l’utente finale Attenzione posta sui parametri di qualità di servizio riscontrati dai clienti Introduzione del minor overhead possibile → Principio di minima intrusione Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

4 Architettura del sistema RE.VE.N.GE: Global Access Point
È il punto di accesso al sistema RE.VE.N.GE Gestisce e monitora i Local Access Point presenti nel sistema Fornisce il riferimento della rispettiva facciata ai clienti che effettuano login Fornisce alcuni servizi fondamentali come il Naming Service e il Client Manager Global Access Point RE.VE.N.GE Server Master RE.VE.N.GE Server Slave 1 RE.VE.N.GE Server Slave 2 Fruitore Push Fornitore Pull Fruitore Pull Fornitore Push Local Access Point Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

5 Architettura del sistema RE.VE.N.GE: Local Access Point
Contiene le facciate di accesso per i clienti È una barriera introdotta per garantire trasparenza alla caduta del RE.VE.N.GE Server Master Gestisce la riconnessione implicita di tutti i clienti a seguito della caduta di quest’ultimo Global Access Point RE.VE.N.GE Server Master RE.VE.N.GE Server Slave 1 RE.VE.N.GE Server Slave 2 Fruitore Push Fornitore Pull Fruitore Pull Fornitore Push Local Access Point Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

6 Architettura del sistema RE.VE.N.GE: RE.VE.N.GE Server
Gruppo delle copie dinamico e basato su modello di replicazione Master-Slave a copie tiepide Checkpoint emesso periodicamente secondo quanto impostato da file di configurazione Monitoraggio del Master effettuato mediante heartbeat periodico A seguito del fallimento del RE.VE.N.GE Server Master, è necessario effettuare un’elezione Global Access Point RE.VE.N.GE Server Master RE.VE.N.GE Server Slave 1 RE.VE.N.GE Server Slave 2 Fruitore Push Fornitore Pull Fruitore Pull Fornitore Push Local Access Point Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

7 Ipotesi di guasto considerate
Global Access Point non soggetto ad alcun tipo di guasto Local Access Point soggetti a guasti con conseguente riconnessione del cliente → Trasparenza non garantita in questa evenienza Nessuna ipotesi di guasto singolo tra i server → 2 o più server e protocollo di elezione Nessun guasto bizantino e nessun errore derivante dal partizionamento della rete Global Access Point Fornitore Push Local Access Point RE.VE.N.GE Server Slave 2 RE.VE.N.GE Server Master Fornitore Pull RE.VE.N.GE Server Slave 1 Fruitore Pull Local Access Point Fruitore Push Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

8 Il Notification Service di JacORB
Punto di partenza Sistema di consegna Publish/Subscribe con modalità di interazione pull/push Possibilità di effettuare filtraggio degli eventi Qualità di servizio Limiti dell’implementazione utilizzata Implementazione parziale delle specifiche dell’OMG Qualità di servizio offerta parziale Persistenza delle connessioni non supportata Persistenza degli eventi non supportata Limite superiore sul numero di messaggi pendenti sul canale Implementazione dei filtri non adatta in ambito di produzione Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

9 Proxy d’accesso al sistema
I proxy definiti dallo standard OMG non sono facilmente adattabili al sistema RE.VE.N.GE Limite sul numero massimo di messaggi consegnati / ricevuti non esprimibile Interazione con il sistema di replicazione e di monitoraggio della qualità di servizio non permessa Si vogliono assolutamente evitare coordinamenti distribuiti tra facciata e il sistema di consegna per la gestione delle esclusive e/o della replicazione Necessità di aggiungere metodi di interfaccia strettamente legati al problema considerato Soluzione Definizione di una gerarchia di proxy proprietaria Introduzione di un punto d’accesso per la creazione ( Pattern Factory ) Tutte le chiamate CORBA, tranne quelle tra la facciata e il sistema di consegna, effettuate mediante comunicazione locale al server Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

10 Proxy d’accesso al sistema
3. Proxy d’accesso ottenuto 1.Fornitore/Fruitore login Fornitore Push 2.Richiesta creazione del proxy di pertinenza Proxy Fornitore Push NOTIFICATION SERVICE GESTORE DELLA REPLICAZIONE GESTORE QUALITY OF SERVICE GESTORE DELLE ESCLUSIVE GESTORE PER L’ACCESSO Fruitore Push Local Access Point Proxy Fruitore Push RE.VE.N.GE Server Master Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

11 Es. Invio e ricezione di un messaggio
Fornitore Push Proxy Fornitore Push NOTIFICATION SERVICE GESTORE DELLA REPLICAZIONE GESTORE QUALITY OF SERVICE GESTORE DELLE ESCLUSIVE GESTORE PER L’ACCESSO Fruitore Push Local Access Point Proxy Fruitore Push RE.VE.N.GE Server Master Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

12 Monitoraggio del Master
Normale operatività implica il monitoraggio del Master Il Master invia periodicamente degli heartbeat UDP verso gli Slave registrati Ogni Slave aspetta il pacchetto per un timeout dipendente dal periodo di invio Periodo configurabile da file di configurazione in funzione dell’uso di banda finale e della prontezza che si vuole ottenere nel rilevare un fallimento del Master Eventuali elezioni scatenate a Master ancora attivo, ad esempio al seguito di un’omissione di un heartbeat, sono immediatamente interrotte senza provocare variazioni nello stato del gruppo RE.VE.N.GE Server Slave RE.VE.N.GE Server Master RE.VE.N.GE Server Slave Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

13 Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
Discovery del Master Discovery di un’eventuale Master presente sulla rete effettuato mediante gruppo di multicast Invio di un messaggio FIND_MASTER sul Multicast Group Se Master presente, risponde con MASTER_IS e inserisce la nuova copia tra gli slave Se non si ottiene una risposta …. RE.VE.N.GE Server Multicast Group RE.VE.N.GE Server Master RE.VE.N.GE Server Slave RE.VE.N.GE Server Slave Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

14 Protocollo di elezione
Protocollo di elezione necessario in assenza del Master Gruppo delle copie dinamico → un RE.VE.N.GE Server può essere aggiunto durante un’elezione Priorità dei singoli server non decisa staticamente → difficile adottare protocolli di elezione tradizionali Priorità dei processi server decisa dinamicamente in base a: Ultimo ID di replica ottenuto con successo Carico del server IP e porta del server Possiamo ottenere un ordinamento totale dei processi server Multicast Group RE.VE.N.GE Server Slave RE.VE.N.GE Server Master RE.VE.N.GE Server RE.VE.N.GE Server Slave Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

15 Protocollo di elezione
SLAVE RE.VE.N.GE Server SLAVE RE.VE.N.GE Server ELECTION_MASTER CANDIDATE CANDIDATE Multicast Group Master RE.VE.N.GE Server COORDINATOR CANDIDATE Emissione del messaggio ELECTION_MASTER Tutti i server transitano in stato di ELECTION_IN_PROGRESS e emettono le candidature mediante messaggio CANDIDATE Il server che a metà del tempo totale di elezione si accorge di avere priorità massima emette un messaggio COORDINATOR e transita in stato di WAIT_FOR_COMMIT; tutti gli altri server, ricevendo tale messaggio transitano nello stesso stato Allo scadere del tempo totale di elezione e se non ci sono state ABORT_ELECTION, lo stato viene reso definitivo Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

16 Protocollo di elezione
Limiti del protocollo di elezione Difficile determinare chi deve partecipare ad un’elezione → Attendo le candidature solo per un certo timeout Possibile omissione di un messaggio dovuto all’uso di multicast non affidabile → Se non si trova accordo, si blocca l’elezione e la si fa ripartire Ordinamento dei messaggi di elezione non garantito tra le copie afferenti al gruppo → Non risulta un problema grave dato che i messaggi sono emessi con temporizzazioni e con vincoli di precedenza laschi Partizionamento della rete non contemplato come da ipotesi di guasto Sviluppo futuri Possibile estendere il protocollo per ottenere maggiori garanzie anche se il protocollo attuale ha garantito sempre i risultati attesi durante la fase di testing → Il candidato potrebbe aspettare una risposta di conferma da tutte i server che hanno partecipato all’elezione Possibile gestire la riconciliazione di più Master effettuando un’elezione vincolata ad un sotto gruppo dei server Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

17 Performance del sistema
Test effettati con lo scopo fondamentale di evidenziare l’overhead introdotto dai proxy d’accesso al sistema di consegna e dai manager eseguiti sul server Configurazione di test composta da: Server MASTER presente su Athlon Xp con 1 Gbyte di RAM Codice di test e GAP su portatile Pentium M 750 con 512 Mbyte di RAM Per tutti i test successivi, si è ipotizzato: la presenza di un unico fornitore push che invia 60 messaggi in un minuto ( 1 msg/s ) un numero di fruitori push variabile da 100 a 5000 numero totale di messaggi consegnati al singolo fruitore pari a quello dei messaggi inviati dal fornitore l’utilizzo dei filtri in modo da non ridurre il numero dei messaggi consegnati Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

18 Performance del sistema
Tempi di consegna del tutto comparabili a quelli dell’implementazione standard. Ma se introduciamo i filtri… Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

19 Performance del sistema
RE.VE.N.GE Server: Circa 170 ms medii senza filtri contro 63 sec in caso contrario Tempi calcolati non sensati dato che non possiamo risultare più veloci Aumento del tempo medio di consegna considerevole. Risultati non ripetibili: usando i filtri si ottengono tempi medii molto differenti tra un’esecuzione e l’altra dello stesso test di carico Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

20 Performance del sistema
Senza filtri, garantiamo tempi di consegna del tutto comparabili a quelli dell’implementazione standard anche all’aumento considerevole dei clienti Non è stato possibile effettuare test con i filtri dato che non terminavano in tempi umani Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

21 Performance del sistema
L’uso dei filtri comporta risultati pessimi anche per l’utilizzo di CPU Simulazione ottenuta con solo 500 consumer iscritti Uso della CPU durante il dispatch dei messaggi notevolmente più elevato Simulazione completata circa 60 sec dopo Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

22 Conclusioni e sviluppi futuri
Aumento dell’affidabilità del sistema di consegna raggiunto Buoni risultati in termini di overhead di gestione introdotto Verifica positiva del funzionamento del sistema con deployment su architettura distribuita ipotizzata Sviluppi futuri Adozione di modelli di load-sharing più accurati per le facciate → Politica molto più costosa in termini di coordinamento e con miglioramenti effettivi da verificare Fornitura del servizio ai clienti mobili → È necessario introdurre la possibilità di avere associazioni statiche con le facciate Risolvere i problemi derivanti dall’uso dei filtri → Difficile realizzazione dato che sembra sia un comportamento legato strettamente all’implementazione dell’ORB usata Estendere il gestore dell’elezione e il protocollo secondo quanto discusso precedentemente Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008