Fanelli Mario Montanari Marco Salbaroli Francesco

1. 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 0000281427

2. 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 DiCalcolatori 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 DiCalcolatori LS a.a. 2007/2008

4. Global Access Point RE.VE.N.GE Server Master Fruitore Push Fornitore Pull Fruitore Pull Fornitore Push Local Access Point Local Access Point RE.VE.N.GE Server Slave 1 RE.VE.N.GE Server Slave 2 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 Fanelli Mario - Progetto di Reti DiCalcolatori LS a.a. 2007/2008

5. Global Access Point RE.VE.N.GE Server Master Fruitore Push Fornitore Pull Fruitore Pull Fornitore Push Local Access Point Local Access Point RE.VE.N.GE Server Slave 1 RE.VE.N.GE Server Slave 2 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 Fanelli Mario - Progetto di Reti DiCalcolatori LS a.a. 2007/2008

6. Global Access Point RE.VE.N.GE Server Master Fruitore Push Fornitore Pull Fruitore Pull Fornitore Push Local Access Point Local Access Point RE.VE.N.GE Server Slave 1 RE.VE.N.GE Server Slave 2 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 Fanelli Mario - Progetto di Reti DiCalcolatori LS a.a. 2007/2008

7. Global Access Point RE.VE.N.GE Server Master Fruitore Push Fornitore Pull Fruitore Pull Fornitore Push Local Access Point Local Access Point RE.VE.N.GE Server Slave 1 RE.VE.N.GE Server Slave 2 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 Fanelli Mario - Progetto di Reti DiCalcolatori 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 DiCalcolatori 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 DiCalcolatori LS a.a. 2007/2008

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

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

13. 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 …. Multicast Group RE.VE.N.GE Server RE.VE.N.GE Server Slave RE.VE.N.GE Server Master RE.VE.N.GE Server Slave Fanelli Mario - Progetto di Reti DiCalcolatori 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 RE.VE.N.GE Server Master RE.VE.N.GE Server Slave Fanelli Mario - Progetto di Reti DiCalcolatori LS a.a. 2007/2008

15. Protocollo di elezione SLAVE SLAVE • 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 CANDIDATE CANDIDATE ELECTION_MASTER Multicast Group Master RE.VE.N.GE Server RE.VE.N.GE Server RE.VE.N.GE Server CANDIDATE COORDINATOR Fanelli Mario - Progetto di Reti DiCalcolatori 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 DiCalcolatori 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 AthlonXp 1700+ 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 DiCalcolatori 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 DiCalcolatori 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 DiCalcolatori 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 DiCalcolatori 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 DiCalcolatori LS a.a. 2007/2008

22. 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 • Fornituradel 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 DiCalcolatori LS a.a. 2007/2008