Proxy based infrastructure for LBS availability Reti di Calcolatori LS Serena Agresti

Obiettivi Sviluppo di un’infrastruttura in grado di fornire un LBS con elevata availability LBS → Location Based Service Mobilità Profilo utente + dati posizionali = servizio dinamico e personalizzato Virtual Museum Tour Proxy replicati (n>=3 copie) Availability Persistenza Bilanciamento del carico QoS

Come funziona? REPLICATO!!!

Astrazione di risorsa unica Il client cosa vede? Controllo esplicito vs. implicito Un livello di indirezione: il Broker Il client deposita la richiesta di registrazione Il broker la smista ad una delle repliche Il Broker: PROs Trasparenza Client liberato dall’onere di scegliere la replica (bilanciamento del carico?) Il Broker: CONs Gestore centralizzato: fault? Collo di bottiglia del sistema

Il Broker come base di dati Il Broker deve decidere a chi affidare il client Valutazione carico computazionale complessivo Broadcast, dati storici,... Scelte random o cicliche Soluzione → “NON SCEGLIE” È poco più che una base di dati Il client deposita la richiesta di registrazione Il proxy controlla periodicamente se ci sono nuovi client da registrare → successive comunicazioni senza intermediazione

Il Broker

Bilanciamento del carico Obiettivo: equilibrare il numero di client registrati (e gestiti) da ogni replica Struttura a ring logico Risolve problemi di coordinamento tra repliche Coordinatore centralizzato ma a ruolo variabile Token a tempo Modello proattivo Registrazione vincolata al possesso del token Load sharing Azione statica fatta prima dell’erogazione del servizio Il processo relativo al client non si muoverà dal nodo in cui nasce

Availability Obiettivi: Gestire la caduta di un nodo Gestire la continuità del servizio verso i suoi client Ripristinare velocemente la normalità Struttura ring logico Poco robusta Rapida individuazione del guasto → valida procedura di recovery Immediato ripristino dell’anello Ma anche persistenza e replicazione...

Registrazione Nodo1 Nodo2 Nodo3 Nodo4 Nodo5 Benvenuto ServiziScelti Messaggio InfoRegistrazione

Registrazione & Fornitura Un database per ogni replica Basi di dati quasi sincronizzate Scambio di messaggi Stato parziale vs. stato totale  InfoRegistrazione contiene lo stato parziale  Inviato una volta sola (all’inizio)  All’uscita del client: messaggio EliminazioneClient Fornitura del servizio Priorità Evento

Conclusioni Modello Master/Slave Master variabile Checkpoint a catena Event driven → registrazione Politica eager  Prima aggiorno le repliche poi fornisco il servizio Principio di minima intrusione Testing difficile ma apparentemente positivo