Fanelli Mario Montanari Marco Salbaroli Francesco Progetto RE.VE.N.GE. CORBA con Replicazione...

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


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


Fruitore Push

Fornitore Pull

Fruitore Pull

Fornitore Push

Local Access Point

Local Access Point


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




Fruitore Push

Fornitore Pull

Fruitore Pull

Fornitore Push

Local Access Point

Local Access Point


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




Fruitore Push

Fornitore Pull

Fruitore Pull

Fornitore Push

Local Access Point

Local Access Point


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




Fruitore Push

Fornitore Pull

Fruitore Pull

Fornitore Push

Local Access Point

Local Access Point


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


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


Proxy d’accesso al sistema


NOTIFICATION SERVICENOTIFICATION 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


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


NOTIFICATION SERVICENOTIFICATION SERVICE









Proxy Fornitore

Push

Proxy Fruitore

Push

Local Access Point


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 Slave



Discovery del Master

RE.VE.N.GE Server



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 ….



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


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_MASTER

CANDIDATE CANDIDATE

CANDIDATECOORDINATORMASTER

SLAVESLAVE


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


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 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

conse

gna i

n m

s



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

conse

gna i

n m

s



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



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

conse

gna i

n 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 812

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 Server

RE.VE.N.GE Server No Filtri RE.VE.N.GE Server Filtri

Tempo di simulazione in secondi

Cari

co C

PU

in p

erc

entu

ale

0 4 812

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 Server

Notification Service No Filtri Notification Filtri

Tempo di simulazione in secondi

Cari

co C

PU

in p

erc

entu

ale



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 Montanari Marco Salbaroli Francesco Progetto RE.VE.N.GE. CORBA con Replicazione...

Documents

Transcript of Fanelli Mario Montanari Marco Salbaroli Francesco Progetto RE.VE.N.GE. CORBA con Replicazione...