Progetto RE.VE.N.GE. CORBA con
Replicazione Sistema di Consegna
Fanelli Mario
Professore: Ing. Antonio Corradi
Tutor: Ing. Luca Foschini
Montanari Marco
Salbaroli Francesco
Presentazione di Mario Fanelli
Matricola 0000281427
Sommario
1. 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
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
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
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
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
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
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
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
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
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
Proxy d’accesso al sistema
3. Proxy d’accesso ottenuto
1.Fornitore/Fruitore login
2.Richiesta creazione
del proxy di pertinenza
Fornitore Push
Proxy
Fornitore
Push
Local Access
Point
Fruitore Push
Proxy
Fruitore
Push
GESTORE DELLE
ESCLUSIVE
GESTORE PER
L’ACCESSO
GESTORE DELLA
REPLICAZIONE
GESTORE QUALITY
OF SERVICE
NOTIFICATION SERVICE
RE.VE.N.GE Server Master
Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
Es. Invio e ricezione di un messaggio
Fornitore Push
Proxy
Fornitore
Push
Local Access
Point
Fruitore Push
Proxy
Fruitore
Push
GESTORE DELLE
ESCLUSIVE
GESTORE PER
L’ACCESSO
GESTORE DELLA
REPLICAZIONE
GESTORE QUALITY
OF SERVICE
NOTIFICATION SERVICE
RE.VE.N.GE Server Master
Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
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
Discovery del Master
Discovery di un’eventuale 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
RE.VE.N.GE Server
Multicast Group
Se non si ottiene una risposta ….
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
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:
1. Ultimo ID di replica ottenuto con
successo
2. Carico del server
3. IP e porta del server
Multicast Group
RE.VE.N.GE Server Master
RE.VE.N.GE Server Slave
RE.VE.N.GE Server
RE.VE.N.GE Server Slave
Possiamo ottenere un ordinamento totale
dei processi server
Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
Protocollo di elezione
RE.VE.N.GE Server
RE.VE.N.GE Server
Multicast
Group
RE.VE.N.GE Server
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
1.
Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
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
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:
1. Server MASTER presente su Athlon Xp 1700+ 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
 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
Performance del sistema
Tempi di consegna del tutto comparabili a quelli dell’implementazione standard.
Ma se introduciamo i filtri…
Tempi di consegna
Notification Service
RE.VE.N.GE Server No Filtri
180
Tempo medio di consegna in ms
160
140
120
100
80
60
40
20
0
100
200
300
400
500
600
700
800
900
NUmero di push consumer iscritti
Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
1000
Performance del sistema
RE.VE.N.GE Server:
Circa 170 ms medii senza filtri contro 63 sec
in caso contrario
Tempi di consegna
Notification Service No Filtri
Notification Service Filtri
RE.VE.N.GE Server No Filtri
RE.VE.N.GE Server Filtri
Tempo medio di consegna in ms
70000
Tempi calcolati non sensati dato che non possiamo
risultare più veloci
60000
50000
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
40000
30000
20000
10000
0
100
200
300
400
500
600
700
800
900
Numero di push consumer iscritti
Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
1000
Performance del sistema
Non
Senza
è stato
filtri,possibile
garantiamo
effettuare
tempi di
test
consegna
con i filtridel
dato
tutto
che
comparabili
non terminavano
a quelliin
dell’implementazione standard tempi
ancheumani
all’aumento considerevole dei clienti
Tempi di consegna
Notification Service
RE.VE.N.GE Server No Filtri
2000
3000
Tempo medio di consegna in ms
3000
2500
2000
1500
1000
500
0
1000
1500
2500
3500
4000
4500
Numero di push consumer iscritti
Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
5000
Performance del sistema
L’uso dei filtri comporta risultati pessimi anche per l’utilizzo di CPU
Simulazione ottenuta con solo 500 consumer iscritti
Carico di CPU derivante dal Server
RE.VE.N.GE
Notification
Server
Service
No Filtri
No Filtri
RE.VE.N.GE
Notification
Server
Filtri
Filtri
100
90
70
60
50
Uso della CPU durante il
dispatch dei messaggi
notevolmente più elevato
Simulazione completata
circa 60 sec dopo
40
30
20
10
0
0
4
8
12
16
20
24
28
32
36
40
44
48
48
52
52
56
56
60
60
64
64
68
68
72
72
76
76
80
80
84
84
88
88
92
92
96
96
100
100
104
104
108
108
112
112
116
116
120
120
124
124
128
128
132
132
136
136
140
140
144
144
148
148
152
152
156
156
160
160
Carico CPU in percentuale
80
Tempo di simulazione in secondi
Fanelli Mario - Progetto di Reti Di Calcolatori LS a.a. 2007/2008
Conclusioni e sviluppi futuri
Conclusioni
 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