Fanelli Mario Montanari Marco Salbaroli Francesco
Post on 24-Feb-2016
58 Views
Preview:
DESCRIPTION
Transcript
Fanelli Mario Montanari Marco Salbaroli Francesco
Progetto RE.VE.N.GE. CORBA con Replicazione Sistema di Consegna
Professore: Ing. Antonio CorradiTutor: Ing. Luca Foschini
Presentazione di Mario FanelliMatricola 0000281427
Sommario1. Architettura del sistema RE.VE.N.GE
2. Il Notification Service di JacORB
3. Aspetti implementativi curati Proxy d’accesso 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
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
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
Local Access Point
Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
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
Local Access Point
Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
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
Local Access Point
Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
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 1
RE.VE.N.GE Server Slave 2
Fruitore Push
Fornitore Pull
Fruitore Pull
Fornitore Push
Local Access Point
Local Access Point
Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
Il Notification Service di JacORBPunto 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
1. Persistenza delle connessioni non supportata2. 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
Proxy d’accesso al sistemaI 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
Proxy d’accesso 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 L’ACCESSO
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 d’accesso ottenuto
Fruitore Push
Fornitore Push
Fruitore Push
Fornitore 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 L’ACCESSO
Proxy Fornitore
Push
Proxy Fruitore
Push
Local Access Point
RE.VE.N.GE Server Master
Monitoraggio del MasterNormale 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 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
Discovery del Master
RE.VE.N.GE Server
RE.VE.N.GE Server Master
RE.VE.N.GE Server Slave
Discovery di un’eventuale Master presente sulla rete effettuato mediante gruppo di multicast1. Invio di un messaggio FIND_MASTER
sul Multicast Group2. 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
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:
1. Ultimo ID di replica ottenuto con successo
2. Carico del server3. 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 Master
RE.VE.N.GE Server SlaveRE.VE.N.GE Server
Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
Multicast Group
Protocollo di elezione
RE.VE.N.GE ServerRE.VE.N.GE Server
RE.VE.N.GE Server
Multicast Group
1. Emissione del messaggio ELECTION_MASTER2. Tutti i server transitano in stato di ELECTION_IN_PROGRESS e emettono le candidature mediante
messaggio CANDIDATE3. 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_MASTERCANDIDATE CANDIDATE
CANDIDATECOORDINATORMASTER
SLAVESLAVE
Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
Protocollo di elezioneLimiti 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
Performance del sistema
Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
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:1. Server MASTER presente su Athlon Xp 1700+ con 1 Gbyte di RAM2. 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 5000numero totale di messaggi consegnati al singolo fruitore pari a quello dei messaggi inviati dal fornitorel’utilizzo dei filtri in modo da non ridurre il numero dei messaggi consegnati
100 200 300 400 500 600 700 800 900 10000
20
40
60
80
100
120
140
160
180
Tempi di consegna Notification Service RE.VE.N.GE Server No Filtri
NUmero di push consumer iscritti
Tem
po m
edio
di c
onse
gna
in m
s
Performance del sistema
Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
Tempi di consegna del tutto comparabili a quelli dell’implementazione standard.Ma se introduciamo i filtri…
100 200 300 400 500 600 700 800 900 10000
10000
20000
30000
40000
50000
60000
70000
Tempi di consegna Notification Service No Filtri Notification Service FiltriRE.VE.N.GE Server No Filtri RE.VE.N.GE Server Filtri
Numero di push consumer iscritti
Tem
po m
edio
di c
onse
gna
in m
s
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
un’esecuzione e l’altra 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
Performance del sistema
Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
1000 1500 2000 2500 3000 3500 4000 4500 50000
500
1000
1500
2000
2500
3000
Tempi di consegna Notification Service RE.VE.N.GE Server No Filtri
Numero di push consumer iscritti
Tem
po m
edio
di c
onse
gna
in m
s
Senza filtri, garantiamo tempi di consegna del tutto comparabili a quelli dell’implementazione standard anche all’aumento considerevole dei clientiNon è stato possibile effettuare test con i filtri dato che non terminavano in
tempi umani
0 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80 84 88 92 96 100
104
108
112
116
120
124
128
132
136
140
144
148
152
156
1600
10
20
30
40
50
60
70
80
90
100
Carico di CPU derivante dal ServerRE.VE.N.GE Server No Filtri RE.VE.N.GE Server Filtri
Tempo di simulazione in secondi
Cari
co C
PU in
per
cent
uale
0 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80 84 88 92 96 100
104
108
112
116
120
124
128
132
136
140
144
148
152
156
1600
10
20
30
40
50
60
70
80
90
100
Carico di CPU derivante dal ServerNotification Service No Filtri Notification Filtri
Tempo di simulazione in secondi
Cari
co C
PU in
per
cent
uale
Performance del sistema
Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
L’uso dei filtri comporta risultati pessimi anche per l’utilizzo 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
Conclusioni e sviluppi futuriConclusioni 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
top related