La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

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

Presentazioni simili


Presentazione sul tema: "Fanelli Mario Montanari Marco Salbaroli Francesco Progetto RE.VE.N.GE. CORBA con Replicazione Sistema di Consegna Professore: Ing. Antonio Corradi Tutor:"— Transcript della presentazione:

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

2 Sommario 1. Architettura del sistema RE.VE.N.GE 2. Il Notification Service di JacORB 3. Aspetti implementativi curati Proxy daccesso al sistema Monitoraggio del Master Discovery del Master e protocollo di elezione 4. Prestazioni del sistema 5. 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 dellaffidabilità da ottenere mediante replicazione del servizio di consegna Notification Service come motore del sistema di distribuzione delle notizie Utilizzo dellimplementazione dellORB e del Notification Service offerta da JacORB Linee guida adottate durante il progetto Trasparenza al fallimento del sistema di consegna verso lutente 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 questultimo 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 unelezione 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 RE.VE.N.GE Server Master RE.VE.N.GE Server Slave 1RE.VE.N.GE Server Slave 2 Fruitore PushFornitore PullFruitore PullFornitore Push Local Access Point 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 dellimplementazione utilizzata Implementazione parziale delle specifiche dellOMG Qualità di servizio offerta parziale 1. Persistenza delle connessioni non supportata 2. 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 daccesso 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 daccesso 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 daccesso al sistema Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008 NOTIFICATION SERVICE GESTORE DELLA REPLICAZIONE GESTORE QUALITY OF SERVICE GESTORE DELLE ESCLUSIVE GESTORE PER LACCESSO 1.Fornitore/Fruitore login Proxy Fornitore Push Proxy Fruitore Push Local Access Point RE.VE.N.GE Server Master 2.Richiesta creazione del proxy di pertinenza 3. Proxy daccesso ottenuto Fruitore PushFornitore Push

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

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 delluso 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 unomissione di un heartbeat, sono immediatamente interrotte senza provocare variazioni nello stato del gruppo 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 Discovery del Master RE.VE.N.GE ServerRE.VE.N.GE Server Master RE.VE.N.GE Server Slave Discovery di uneventuale Master presente sulla rete effettuato mediante gruppo di multicast 1. Invio di un messaggio FIND_MASTER sul Multicast Group 2. Se Master presente, risponde con MASTER_IS e inserisce la nuova copia tra gli slave Se non si ottiene una risposta …. Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008 RE.VE.N.GE Server Slave Multicast Group

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

15 Protocollo di elezione RE.VE.N.GE Server Multicast Group 1. Emissione del messaggio ELECTION_MASTER 2. Tutti i server transitano in stato di ELECTION_IN_PROGRESS e emettono le candidature mediante messaggio CANDIDATE 3. 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 4. Allo scadere del tempo totale di elezione e se non ci sono state ABORT_ELECTION, lo stato viene reso definitivo ELECTION_MASTER CANDIDATE COORDINATOR 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 unelezione Attendo le candidature solo per un certo timeout Possibile omissione di un messaggio dovuto alluso di multicast non affidabile Se non si trova accordo, si blocca lelezione 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 allelezione Possibile gestire la riconciliazione di più Master effettuando unelezione vincolata ad un sotto gruppo dei server Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008

17 Performance del sistema Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008 Test effettati con lo scopo fondamentale di evidenziare loverhead introdotto dai proxy daccesso al sistema di consegna e dai manager eseguiti sul server Configurazione di test composta da: 1. Server MASTER presente su Athlon Xp con 1 Gbyte di RAM 2. 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 lutilizzo dei filtri in modo da non ridurre il numero dei messaggi consegnati

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

19 Performance del sistema Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008 Aumento del tempo medio di consegna considerevole. Risultati non ripetibili: usando i filtri si ottengono tempi medii molto differenti tra unesecuzione e laltra dello stesso test di carico 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

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

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

22 Conclusioni e sviluppi futuri Conclusioni Aumento dellaffidabilità 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 dalluso dei filtri Difficile realizzazione dato che sembra sia un comportamento legato strettamente allimplementazione dellORB usata Estendere il gestore dellelezione e il protocollo secondo quanto discusso precedentemente Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008


Scaricare ppt "Fanelli Mario Montanari Marco Salbaroli Francesco Progetto RE.VE.N.GE. CORBA con Replicazione Sistema di Consegna Professore: Ing. Antonio Corradi Tutor:"

Presentazioni simili


Annunci Google