Infrastruttura di supporto per database distribuiti

1. Infrastruttura di supporto per database distribuiti Presentazione del progetto di: Reti di calcolatori L-S Federica Magnani

2. Sommario • Obiettivi • Descrizione del sistema • Architettura • Gestione dei guasti e dei malfunzionamenti • Implementazione • Conclusioni Federica Magnani

3. Obiettivi • Il seguente lavoro sviluppa un’infrastruttura di supporto per database distribuiti • Il progetto nasce dall’idea di possedere, all’interno di un istituto scolastico, un’enciclopedia letteraria consultabile e modificabile in rete da varie postazioni • Necessità di supporto ai guasti e malfunzionamenti nel sistema: replicazione dati e servizi Federica Magnani

4. Server Server Server Rete Client Client Client Richiesta Risposta Architettura del sistema • Il sistema si basa sul modello client/server in cui un utente effettua una richiesta ad un servitore attendendo da esso una risposta: modello sincrono bloccante • Lo scambio di informazioni tra client e server è asimmetrico Federica Magnani

5. Client Server Stub Skeleton Architettura (2) • Il client ottiene un riferimento all’oggetto remoto: uso di proxy • Lo stub e lo skeleton permetto a client e server di effettuare la serializzazione e la deserializzazione dei dati • Ciascun client è legato allo stesso server per tutta la sua esecuzione Federica Magnani

6. Il gestore dei nomi • Il gestore permette ai server di: • ottenere un nome univoco attraverso un contatore • aggiornare un vettore contenente i nomi dei server non più attivi • recuperare l’indirizzo di un server attivo • Il gestore permette ai client di ottenere gli indirizzi dei server attualmente attivi • Il gestore dei nomi è un oggetto attivo remoto registrato • Esso è sempre in esecuzione su un’unica macchina: • il suo indirizzo deve essere conosciuto da tutte le entità del sistema • non è replicato Federica Magnani

7. Descrizione del sistema • Il database contiene due tabelle: Autori e Opere • Le richieste di visualizzazione di un autore o di un’opera vengono eseguite immediatamente • Le operazioni di modifica o cancellazione necessitano di un meccanismo di sincronizzazione: SAFETY • uso di lock per istanze dello stesso oggetto • uso di un token in un sistema ad anello per server diversi • Ciascun server è legato ad un database • modello ad esecuzione statica: l’allocazione delle risorse viene decisa prima dell’esecuzione • Il modello di replicazione scelto è un modello attivo in cui tutte le copie eseguono in modo sincrono e coordinato Federica Magnani

8. Server 1 Server 2 Server 3 Server N DB DB DB DB Descrizione del sistema (2):sistema ad anello • Il server che effettua le modifiche deve possedere il Token • Al termine dell’operazione il server inoltra la stessa richiesta al nodo successivo passandogli il token • I server non conoscono i successori ma recuperano il loro indirizzo interrogando il gestore dei nomi: DINAMICITA’ Federica Magnani

9. Tolleranza ai guasti • Replicazione dei dati e dei server su macchine separate • Ciascun istituto possiede una copia locale dei dati e uno o più server per il servizio • Guasto sul database • Quando i dati di un istituto non sono disponibili, l’utente può contattare un server remoto e fruire degli stessi dati in modo trasparente • Guasto sul server • Quando un server non è più attivo, all’utente viene assegnato dal Manager un server remoto in modo trasparente • Se il server cade durante il servizio l’utente viene allertato e inviatato a riconnettersi nuovamente Federica Magnani

10. Implementazione: il client • Utilizzo di Java RMI • L’utente può aprire una interfaccia grafica con cui interagire con il sistema • Il client chiama il metodo Connect del Manager: • se esistono server sulla macchina locale ( list del registry) restituisce il riferimento ad uno di essi (lookup) in modo random • altrimenti interroga il gestore dei nomi e recupera l’indirizzo di uno dei server remoti attualmente attivi • In caso di guasti sul server o sui dati l’utente • E’ invitato a riconnettersi se legato al server non più attivo • Gli viene restituito un oggetto remoto attivo in modo trasparente • IlManagerrestituisce un nuovo riferimento ed aggiorna i server attivi sul gestore dei nomi: updateServer(int server) Federica Magnani

11. Esempio: fault del server • L’utente decide di visualizzare i dati di un autore • Il client invoca il metodo listAutori e il sistema gli restituisce un messaggio di errore • Se il server era locale il Manager può effettuare l’unbind altrimenti aggiorna l’array dei server attivi sul Gestore dei Nomi: updateServer( int name) e restituisce un nuovo riferimento Federica Magnani

12. Il server • Il server possiede due interfacce • IServer • Permette di interrogare il database: list • Aggiornare i dati: create, modify o deleteautori o opere • IServer_Remote • Permette di interagire con gli altri server dell’anello: update, getNext • Manipolare il token: set, get, research Token Federica Magnani

13. Esempio: modifyAutore • L’utente desidera modificare i dati di un autore: • se l’utente non è presente il sistema restituisce al mittente un messaggio di errore • Altrimenti il server ricerca il token nell’anello: reseach_Token(String name) • Effettua la modifica sul database locale e inoltra la stessa modifca agli altri server dell’anello: update_Server(String query, String server) • Entrambi i metodi richiamano il metodo getNextServer(String name) che restituisce il prossimo server attivo nell’anello: • In caso di guasti sul server il metodo aggiorna l’array dei server attivi sul gestore dei nomi e restituisce un nuovo riferimento • Al termine di tutti gli aggiornamenti il primo server restituisce una risposta al client: • In caso di errori l’applicazione lato client informa l’utente sull’esito dell’operazione Federica Magnani

14. Dati Server Conclusioni • Il progetto sviluppa un primo prototipo in grado di lavorare anche in caso di mal funzionamenti e guasti: • indisponibilità dei dati • indisponibilità dei server Replicazione • Sistema ad anello con passaggio del Token • Sviluppi futuri: • sicurezza nell’accesso ai dati distribuiti • replicazione del gestore dei nomi: anche in questo caso sarebbe necessario introdurre una politica di sincronizzazione e coordinamento Federica Magnani