BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei

Transcript

1 Corso di Laurea Specialistica in Ingegneria Informatica Reti di Calcolatori LS prof. Antonio Corradi BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei di Emanuele Crescentini ( ) Abstract L obiettivo di questo articolo è descrivere la progettazione e l implementazione di un middleware che permetta di risolvere un problema di sincronizzazione di dati all interno di un sistema eterogeneo cercando una soluzione il più possibile completa, efficiente ed indipendente dal problema originale, ossia riutilizzabile. Il problema di partenza è la necessità di sincronizzare un sistema gestionale realizzato come applicazione web con software di comune distribuzione nelle macchine locali. Il sistema è stato poi esteso per aumentare la QoS introducendo un cluster di server. 1 Introduzione Questo progetto nasce da una esigenza sempre più comune nello sviluppo di sistemi software: la collaborazione tra elementi eterogenei, ovvero scritti in linguaggi diversi ed operanti in diversi sistemi operativi. Lo scopo del progetto è fornire un middleware che permetta di risolvere un problema di sincronizzazione di dati all interno di un sistema eterogeneo cercando una soluzione il più possibile completa, efficiente ed indipendente dal problema originale, ossia riutilizzabile. Il problema di partenza è la necessità di sincronizzare un sistema gestionale realizzato come applicazione web (installata su un server) con software di comune distribuzione nelle macchine locali (es: Microsoft Outlook e Microsoft Pocket Outlook). Poiché i dati possono essere modificati sia sui dispositivi locali che sul server, la sincronizzazione deve essere intelligente, cioè deve poter capire a quale dei due sistemi prestar fede, e prevedere diverse politiche di sincronizzazione e variarla nel tempo, eventualmente prevedendo la possibilità di interpellare l utente stesso in caso di dubbio. Si consideri inoltre che, mentre il server web è sempre on-line, gli altri sistemi possono effettuare modifiche anche off-line e solo in seguito eseguire la sincronizzazione. Nella prossima parte sarà analizzato il problema nei suoi aspetti critici, sondando possibili alternative di soluzione. La terza sezione tratterà delle scelte effettuate nella soluzione, e la quarta mostrerà i dettagli principali dell implementazione. La quinta parte esaminerà un estensione del sistema, introducendo la replicazione del server. 2 Analisi del problema Il problema evidenzia tre importanti aspetti che devono essere affrontati con riguardo: l eterogeneità, il coordinamento tra le entità e le politiche di sincronizzazione. 2.1 Eterogeneità Le entità sono in generale software diversi che girano su piattaforme diverse, e soprattutto che organizzano le informazioni in modo diverso. Perciò è necessario in qualche modo tradurre le informazioni in una struttura logica unica per poterle confrontare. Questa potrebbe essere una struttura astratta creata dal sistema o un vero e proprio file esportato dalle diverse entità in uno standard comune. Questo secondo caso appare più interessante in

2 quanto permette la progettazione di un unico software di sincronizzazione, di cui qualunque programma di terze parti può usufruire previa la realizzazione di un plugin di esportazione ad hoc. 2.2 Coordinamento tra entità La presenza del server web sempre on-line richiama subito l idea di un sistema client/server, che facilita molto la sincronizzazione in quanto è possibile permettere ad una sola entità di monitorare l intera operazione. Questo modello però comporta un alto carico di lavoro sul server, che è prevedibile lavori con diversi utenti contemporaneamente. Non è perciò da escludere una implementazione secondo il modello P2P, considerando che ogni entità ha, a prescindere, la stessa veridicità per quanto riguarda le informazioni che contiene. 2.3 Politiche di sincronizzazione Occorre considerare innanzitutto che in generale le entità, escluso il server web, potrebbero effettuare modifiche sulle informazioni in modalità off-line. Inoltre lo stesso utente potrebbe voler attualizzare le informazioni da due dispositivi diversi contemporaneamente. La sincronizzazione deve essere quindi un operazione atomica, perché sia garantita la consistenza dei dati. Il sistema deve poi prevedere diverse politiche di sincronizzazione, dipendenti dal tempo (ad esempio: è la prima sincronizzazione, e quindi in generale le informazioni locali non sono aggiornate, o il contrario) e dal luogo (ossia dal dispositivo); occorre quindi che queste politiche siano facilmente modificabili e che il sistema ne sia indipendente. 3 Scelte progettuali 3.1 Eterogeneità e politiche di sincronizzazione Il problema dell eterogeneità ha portato alla scelta del Java come linguaggio di implementazione, in quanto è indipendente dalla piattaforma su cui gira, ed è largamente diffuso anche nelle tecnologie mobili. Per permettere il confronto dei dati si è pensato ad un formato standard in cui rappresentarli, ed è stato scelto come linguaggio l Xml, standard sempre più in uso che presenta forti vantaggi in quanto a usabilità e leggerezza, nonché diffusione. Sarà necessario perciò realizzare un exporter (in un linguaggio di programmazione qualunque!) per ogni diverso sistema che vuole interagire attraverso la nostra applicazione. Ma, grazie a questo standard, è anche possibile immaginare che vengano implementati sistemi a partire dal formato Xml da noi utilizzato come standard. Sarà utilizzato l Xml anche per la definizione delle politiche da seguire, rendendone così facile la configurazione. 3.2 Coordinamento Il nostro sistema presenta una forte asimmetria: da una parte abbiamo un server web, sempre on-line ma che deve gestire l accesso di più utenti allo stesso tempo (e anche dello stesso utente da più postazioni); dall altra delle entità che lavorano sia on-line che off-line, e lavorano con un singolo utente. Perciò, nonostante le riflessioni sulla parità di ruolo di tutte le entità, la scelta più efficace appare essere quella di un sistema client/server. È però necessario che il carico di lavoro sul server sia minimo. Ogni operazione di sincronizzazione è quindi effettuata rispetto al server, visto che è l unica entità sempre on-line, il quale ha quindi il solo compito di fornire la sua versione dei dati, nonché di impedire l accesso ai dati dello stesso utente da più postazioni, e garantire l atomicità e la consistenza delle operazioni di sincronizzazione. Compito del client è quindi fare richiesta di sincronizzazione al server ed effettuare il confronto dei dati. In questo modo sarebbe anche facilmente implementabile una politica che preveda l interrogazione diretta del client: l esecuzione avverrebbe sempre in locale, e non comporterebbe un carico di lavoro maggiore da parte del server e della rete. 4 Implementazione Il middleware è stato implementato tralasciando, oltre agli exporter (che come si è già detto sono componenti di fatto esterne al sistema), l interfaccia grafica. È perciò contemplata ma non implementata la possibilità di interrogare direttamente l utente in caso di dubbio. 2

3 Il sistema comprende due sottosistemi in comunicazione tra loro: il client e il server. Entrambi sono stati realizzati secondo una logica di layer, così da facilitare la modifica ed il riutilizzo dei componenti. Local Software WebServer-DB GUI Importer Policy Importer Application Layer Application Layer Network Layer Network Layer Disegno 1: Layers L atomicità dell operazione è realizzata tramite le operazioni di Lock e UnLock che operano sul server a livello Application. In figura 1 e 2 sono riportate le strutture logiche del Client e del Server, ad un livello di astrazione tale da riportare solo i metodi essenziali. Figura 1 Il client ruota attorno alla classe AppLayer, che si serve delle altre classi del sistema. Il dialogo col server è reso trasparente grazie alla classe NetLayer, che implementa il layer di rete, la quale, una volta istanziata, maschera tutto il dialogo di rete con due chiamate di invio e ricezione di file. Figura 2 Il server è stato implementato a partire dal basic remoting pattern Singleton. Questo ci permette di avere una classe istanziata una sola volta, la classe Framework, che, oltre a prendersi carico dell inizializzazione dello Stub e quindi dell infrastruttura di rete, gestisce il delicato accesso alla LockList, nonché la classe LockManager, responsabile di monitorare la lista. Essendo un singleton ha tra l altro il vantaggio di poter essere chiamata da chiunque ne abbia la visibilità (come il NetLayer). Si noti inoltre la classe NetUtility: questa classe composta esclusivamente di metodi statici si può considerare come un semplice middleware per standardizzare la comunicazione tra i componenti del sistema. Fornisce il passaggio di due tipi di dato: messaggio e file. La classe XmlUtility provvede invece tutti i metodi per manipolare i file xml. L interazione tra client e server è riportata in fig. 3. Come si vede il server ha un comportamento passivo, in quanto aspetta le interrogazioni del client e non è preoccupato dell esito dell operazione. Al contrario il client conosce perfettamente l esito delle operazioni e, in caso di errore, può agire di conseguenza. 3

4 Figura 3 L interazione è divisa in due fasi: lock e sync. Questa divisione non è solo logica: la connessione viene chiusa alla fine di ogni fase. Questo per ottimizzare l utilizzo della banda e minimizzare l occupazione delle porte del server. Inoltre, pensando alla possibilità che il processo di sincronizzazione interagisca con l utente, evita di mantenere aperta una connessione inoperosa. In questo modo però il server resterebbe all oscuro di un eventuale fallimento del processo di sincronizzazione, e non potrebbe eliminare la lock effettuata dal client. Per questo è stato pensato un monitor che, dato un tempo massimo di validità della lock, controlla periodicamente il registro di lock per scartare le entry scadute. L eterogeneità è stata risolta, come detto, dall utilizzo di un formato standard basato sull Xml. Il layer Application del client quindi effettuerà una comparazione tra il documento locale, riportato dall Importer, e quello remoto, ricevuto dal Network Layer. Le scelte saranno guidate dalla politica impostata nel file di policy, anch esso in xml. Un esempio di file di policy è il seguente: <?xml version="1.0" encoding="iso "?>  <policy> <new>  <local> keep </local> <remote> skip </remote> </new> <different>  <localnewer> keeplocal </localnewer> <remotenewer> keeplocal </remotenewer> <samedate> keepremote </samedate> </different> </policy> Il sistema è stato sviluppato con il framework Eclipse usando Java JRE 1.5. E stato testato in ambiente Windows. 5 Estensione: Server replicati Vogliamo ora incrementare la Qualità del Servizio del nostro sistema. In particolare vogliamo far sì che, in caso di caduta del server, sia ancora possibile fruire del servizio in modo trasparente all utente che lavora da un dispositivo client: vogliamo quindi garantire un servizio sempre attivo 24/7. Visto che abbiamo considerato l exporter server-db come un componente esterno, non ci occuperemo della fault-tolerance del database, in quanto supporremo già fornito da terze parti. Nel nostro sistema fornire un servizio attivo 24/7 vuol dire far si che, in caso di caduta di un server, ce ne sia un altro che possa fornire lo stesso servizio, e questo conservando l atomicità dell azione rispetto all utente. Quindi è necessario avere un sistema replicato in cui tutti i server vedano la tabella dei lock aggiornata. La soluzione proposta prevede di avere un cluster di server secondo il modello del bilanciamento di carico. Ogni copia può realizzare il protocollo di scambio con il client, e il sistema provvede alla sincronizzazione e al bilanciamento. 4

5 Per la gestione dei server si introduce un nuovo componente, chiamato Broker, che dovrà occuparsi della ricezione della richiesta da parte del client, l assegnazione di un server, nonché del monitoraggio e della sincronizzazione del cluster. In questo modo, però, il collo di bottiglia creato dalla possibile caduta del server è solo spostato ad un altra entità. Per questo anche il Broker dovrà essere a sua volta replicato. Figura 4 Il client ora non interrogherà più direttamente il server, ma dovrà contattare il broker. Questi gli dovrà passare il riferimento ad un server. Perciò cambierà leggermente il protocollo di comunicazione, che sarà realizzato come in figura 5. Come si può vedere, dal lato client c è un solo significativo cambiamento: la contrattazione del server come fase iniziale. Contrattazione determinata dalla presenza del messaggio change server. Anche dal lato server i cambiamenti sono minimi: la possibilità di ricevere un ping e il messaggio di lock indiretto lock <username> ##Broker, il cui significato sarà spiegato in seguito. La limitatezza di queste modifiche fa si che sia il client che il server siano ancora compatibili con il precedente protocollo: è ancora possibile la comunicazione diretta client-server senza alcuna mediazione. L introduzione del broker ci permette di delegare a questi il monitoraggio ed il bilanciamento dei server. Il broker sarà in possesso di una lista dei server attivi e di una lista dei server offline, e istanzierà dei processi di monitoraggio per poter aggiornare il contenuto delle liste. In particolare saranno presenti due oggetti attivi, ServerManager e ServerRestore. Il primo monitorerà i server attivi, e, in caso di caduta di uno di questi, li sposterà nella lista dei server offline. Il secondo controllerà i server offline tentando di ripristinare quelli che sono tornati raggiungibili. La struttura logica del broker è riportata in figura 6. Figura 6 Figura 5 La ServerList è stata implementata come un singleton doppio, estendendo la 5

6 peculiarità del singleton alle due liste di cui necessitiamo. Si noti che, nonostante l analogia col server, la classe Broker non è un singleton come la classe server.application.framework. Questo perché nel broker tutta la parte a livello di applicazione riguarda la ServerList, e perciò è a questa classe che è stato applicato il pattern. Le informazioni dei server sono incapsulati nella classe serializable ServerInfo. E perciò possibile inviarli ad oggetti remoti (quali i client) grazie ai nuovi metodi getobj e sendobj aggiunti alla classe NetUtility, a cui è stata anche aggiunta la funzione connect(serverinfo). La ServerList incapsula i server nella classe ServerListInfo, che estende la ServerInfo aggiungendo l attributo use che permette di utilizzare un algoritmo di bilanciamento di carico: ad ogni chiamata getworkingserver viene scelto il server con il parametro use maggiore, e allo stesso tempo viene incrementato di uno il valore di tutti i server. I parametro del server scelto viene poi decrementato del numero dei server presenti. Viene qui assunta nuovamente una politica positivista: il server ritornato è sicuramente on-line. Questa scelta, basata sull esistenza di un doppio monitoraggio (si veda il prossimo capoverso), permette di risparmiare il tempo altrimenti perso da una verifica dello stato del server. La sincronizzazione viene effettuata con una strategia positivista al momento stesso delle chiamata da parte dell utente: mentre il server scelto viene messo in comunicazione con l utente, agli altri server viene inviata la stessa richiesta con il suffisso ##Broker. Questo viene codificato dal server come una richiesta differente, in quanto eseguirà solo le operazioni che riguardano la lock. In questo modo si suppone che l esecuzione sul server scelto vada a buon fine. Questa scelta è stata dettata dalla volontà di minimizzare i cambiamenti, e supportata dalla relativa semplicità dell operazione. Si è deciso quindi di seguire una politica simile all aggiornamento eager di tutte le copie, ma le copie secondarie eseguono l operazione solo parzialmente, e non c è una fase di accordo finale. La chiamata agli altri server viene eseguita attraverso il ServerManager: questo permette di aggiornare la lista dei server attivi. Il ServerManager può essere eseguito anche come processo indipendente che si ripete ad intervalli regolari, in modo da migliorare il throughput al momento della richiesta da parte del cliente nel caso di un lungo intervallo di inattività del sistema. Il ServerRestore viene istanziato come un processo indipendente che, ad intervalli regolari, effettua una ping su tutti i server offline. Nel caso di risposta affermativa avvia la procedura di restore schematizzata in figura 7. Figura 7 Viene richiesto alla ServerList un WorkingServer, e a questi viene richiesto di comunicare al server in fase di restoring la lista delle lock. In seguito viene reinserito tra i server attivi. L operazione usa nuovamente i metodi sendobj e receiveobj di NetUtility, perciò anche la classe Lock ora implementa l interfaccia Serializable. La replicazione del broker è realizzata attraverso un cluster statico (nel nostro caso 2 istanze) a copie attive, una primaria ed una secondaria: entrambi i broker possono operare in maniera indipendente, e non è necessaria nessuna fase di aggiornamento tra i due, in quanto ognuno monitora comunque i server attivi. Il client avrà l indirizzo di entrambi, e potrà 6

7 accedere alla copia secondaria in caso non sia disponibile quella primaria. Sarebbe interessante, come attività futura, sviluppare in modo più completo questa replicazione, ad esempio condividendo tra i broker le informazioni di bilanciamento del carico dei server, o sfruttando il broker secondario per il controllo dello stato dei server. Le modifiche al client per adattarlo a questa estensione sono minime: è stato modificato unicamente il layer di rete, introducendo la possibilità della contrattazione del server con il broker, ad eccezione dell aggiunta di un ulteriore parametro nella configurazione per conoscere anche l indirizzo del broker secondario. Si è approfittato del cambiamento per eseguire anche una refactory del codice sfruttando la nuova classe ServerInfo dove possibile. E possibile eliminare il broker e creare un sistema di coordinamento per cui un server si prende dinamicamente l incarico di coordinatore. E possibile implementare un layer di rete alternativo che utilizzi un altra tecnologia (es: bluetooth) per la comunicazione tra un dispositivo comunque connesso alla rete (che può comportarsi quindi come un server, essendo sincronizzato con il server principale) ed uno che non può connettersi. Il server ha subito anch esso i cambiamenti principalmente nel Network Layer, per adattarlo alle nuove funzionalità come la comunicazione con il broker ed il restoring, ed ha subito qualche modifica anche nel layer applicativo: oltre alla modifica già citata della classe Lock, si sono aggiunti nuovi metodi nel Framework e nella LockList per l invio e la ricezione dell intera lista. 6 Conclusioni È stato realizzato un middleware di sincronizzazione per sistemi eterogenei, che prevede l utilizzo di un formato standard basato sull xml per il confronto dei dati, la possibilità di definire politiche di sincronizzazione anch esse in xml, che si basa su di un modello client/server. Il middleware è stato progettato ed implementato, rispondendo a tutti i requisiti. Lo si è poi esteso aumentandone la Qualità di Servizio, introducendo un cluster di server gestito da un broker a sua volta replicato. Grazie ad una politica positivista, il servizio non ha perso significativamente velocità, guadagnando in disponibilità. 6.1 Sviluppi futuri E possibile modificare il cluster di server utilizzando una politica non positivista, e quindi con un protocollo di coordinazione tra broker e server più complesso ma più affidabile. 7