Replicazione delle risorse: UN CASO DI STUDIO Corso di Laurea in Ingegneria Informatica Facoltà di Ingegneria – A.A. 2005/2006 Università degli studi di Bologna Corso di Reti di Calcolatori LS Prof. Antonio Corradi Replicazione delle risorse: UN CASO DI STUDIO Progetto di Roberta Calegari

SCENARIO e OBIETTIVI Lo scopo del progetto è realizzare una semplice applicazione distribuita che preveda l’utilizzo di stampanti comuni. Nello svolgimento si vogliono trattare le tematiche che tipicamente emergono nella realizzazione nel distribuito: apertura e scalabilità trasparenza replicazione e fault tolerance Al fine di affrontare le tematiche proposte il progetto si occupa della realizzazione di: protocollo di discovery (apertura e scalabilità) servizio di lookup (replicazione calda e trasparenza) servizio di stampa (replicazione fredda) gestore di un pool di risorse (replicazione tiepida e bilanciamento del carico) Tecnologia implementativa scelta: Java; risponde infatti a tutte le esigenze nate in fase di progettazione.

Protocollo di discovery Il protocollo di discovery permette ad una nuova entità di entare nel sistema, scoprendo le risorse e i servizi attivi in quel momento. Il servizio base, per cui ogni entità chiederà al momento di ingresso nel sistema, è il servizio di Lookup. Il protocollo realizzato prevede che la nuova entità invii in multicast un messaggio discovery che contenga il nome di ciò che si sta cercando (Lookup) e che tipo di entità lo sta cercando (Lookup, Server, Client). nuova entità Lookup nuova entità Server (ResourceManager, Resource) e nuova entità Client discovery lookupService address WSP master/ addressBis bisWSP discovery lookupService server address WRP discovery lookupService client address WRP

Servizio di LOOKUP: overview Un sistema a risorse condivise che vuole rispondere ai requisiti di apertura e dinamicità vede come necessaria la presenza di un servizio di Lookup che permetta ad una nuova entità (client/server) di agganciarsi al sistema stesso scoprendo le risorse a disposizione. Questo servizio, che possiamo vedere come risorsa del sistema, risulta quindi essenziale per il funzionamento e permette di esaminare la replicazione calda di risorse software. L’architettura scelta per la replicazione del servizio è quella di un sistema a catena in cui e’ presente un solo master che esegue le richieste ricevute dai nodi del sistema e si occupa poi di aggiornare le risorse (replicazione PASSIVA). Per la tolleranza ai guasti si è fatta un’ipotesi di guasto singolo: caduta del master caduta dell’utlimo slave caduta di un nodo intermedio

Servizio di LOOKUP: strutture dati discovery lookupService lookupService address WSP master/ addressBis bisWSP Service Table MSP WSP/ MP ID port address interface HPInkJet5000 3032 127.0.0.1 PRINT MUL MULticastPort: porta di multicast necessaria per il discovery Quando nasce un LookUpService manda un messaggio multicast per sapere se ci sono altri LookUpServices nel sistema. Allo scadere di un timeout, se nessuna risposta è stata ricevuta l’entità si configura come slave, altrimenti si aggancia alla catena diventando l’ultimo slave. WRP SUP UP Upgrade List WaitingSlavePort: su questa porta l’ultimo slave della catena attende un nuovo slave MonitorPort: se non si è l’ultimo slave la porta di waiting non deve essere attiva; si deve però comunicare con lo slave in modo da farsi monitorare MonitorSlavePort: su questa porta lo slave controlla il suo predecessore UpgradePort: da questa porta si mandano gli aggiornamenti al successore SlaveUpgradePort: su questa porta si ricevono gli aggiornamenti dal predecessore WaitingRequestPort: se si è master un demone resta in ascolto di richieste

Servizio di LOOKUP: protocolli di comunicazione delete interface address port ID lookingFor ID Il funzionamento a regime del Lookup può essere così schematizzato: registartion interface address port ID lookingForInterface interface live WRP WRP MP MSP WSP slave UpgradePort live Master Slave I ready UP bisUP UP SUP UP ready Upgrade List

Servizio di LOOKUP: ipotesi di guasto (1/3) live L’architettura realizzata prevede tre ipotesi di guasto: caduta del master live live Master MP UP MP UP SUP MSP MSP WSP WRP changeLookupService address port Slave II Master Slave I Master SUP Invio di un messaggio multicast per avvisare eventuali client del cambiamento del master.

Servizio di LOOKUP: ipotesi di guasto (2/3) live L’architettura realizzata prevede tre ipotesi di guasto: caduta di uno slave intermedio Problems MSP SUP live live MP live MP UP SUP MSP live MSP WSP Master Slave myMasterAddr myMasterWSP myMasterUP master Slave I Slave II UP SUP

Servizio di LOOKUP: ipotesi di guasto (3/3) live L’architettura realizzata prevede tre ipotesi di guasto: caduta dell’ultimo slave live live MP UP MP UP live MSP MP WSP WSP SUP MSP Terminate master Slave I Slave II SUP UP

Risorsa “stampante”: overview e strutture dati Request queue La realizzazione della risorsa stampante prende in esame la replicazione fredda delle risorse. Solo in caso di guasto della risorsa si effettua la sua sostituzione, in modo trasparente all’utente. WRP TCP EP Resource Printer Le funzionalità della risorsa stampante sono espletate da due demoni attivi (per tutto il tempo di vita dell’applicazione) su due porte diverse. WaitingRequestPort: porta di attesa richieste di stampa da parte del client ExecutePort: porta su cui è attivo il demone che si occupa della vera gestione della richiesta. Prevede l’attivazione di una connessione sulla porta TCP, dove attende lo stream di dati da stampare da parte del client. Anche in questo caso l’ipotesi di guasto fatta prevede il caso di guasto singolo: caduta della risorsa stampante caduta del client (tempo di lease)

Risorsa stampante: protocolli di comunicazione Il comportamento a regime di una risorsa è attendere richieste dal cliente sulla porta WRP. La richiesta prevede l’invio dei dati del cliente stesso. Una volta ricevuta la richiesta viene accodata nella lista delle richieste della stampante e, quando prima in coda, viene gestita (politica FIFO possibilità di estendere con nuove politiche). Il demone incaricato di eseguire la prima richiesta in coda provvederà ad aprire una connessione TCP con il cliente, aprendo una ServerSocket sulla porta TCPPort e rimanendo in attesa di una richiesta di connessione dal client (che deve avvenire entro un timeout). I dati relativi alla porta di attesa della risorsa vengono quindi comunicati al client, in modo che possa aprire la connessione. Client CP TCP client ID address port TCP IDresource address TCPport Request queue WRP Resource Printer EP TCP Sfruttando la connessione TCP il client può inviare alla stampante il file da stampare ed essa può quindi procedere nella stampa.

Risorsa stampante: ipotesi di guasto live L’architettura realizzata prevede due fasi relative all’ipotesi guasto: caduta della risorsa/client prima della connessione TCP Le porte per lo scambio di messaggi sono se non ricevono messaggi si accorgono del guasto, lo comunicano in multicast e tronano al funzionamento a regime. Resource Printer WRP EP WRP CP CP client ID address port Client caduta della risorsa/client durante connessione TCP stabilita Client client ID address port Resource Printer TCP Introduzione tempo di lease entro il quale il client deve mandare un messaggio per mantenere impegnate le risorse. Lato client l’errore di non poter scrivere sulla socket produce il messaggio “risorsa non raggiungibile”.

Gestore delle risorse: overview e strutture dati La realizzazione del gestore delle risorse prevede una replicazione tiepida con architettura a catena PASSIVA di tipo master/slave. I demoni relativi alla gestione della replicazione sono analoghi a quelli illustrati per il servizio di Lookup. In aggiunta sono presenti due demoni per la gestione delle risorse in modo da poter svolgere il compito di bilanciamento del carico: WaitingRequestPort: attende registrazione da parte di stampanti e richieste da parte del cliente WaitingTerminationPort: attende messaggi di terminazione da parte delle stampanti gestite, in modo da poter aggiornare il numero di richieste accodate su quella risorsa. Replicazione Servizio WRP Resource Manager 127.0.0.1 ID port address interface HPInkJet5000 3032 PRINT #request WTP Resource Table La struttura dati principale è una tabella che mantiene un elenco centralizzato delle risorse attive a cui è possibile smistare richieste. Per svolgere il compito di bilanciamento carico è necessario un attributo aggiuntivo che memorizza il numero di richieste in coda su ciascuna risorsa. L’ipotesi di guasto fatta è quella di guasto singolo.

Gestore delle risorse: protocolli di comunicazione (3) client ID address port Client WRP CP TCP (4) client ID address port (5) Resource Manager TCP IDresource address TCPport (2) OK Request queue (6) WRP WTP (1) registration interface address port IDResource Resource Printer EP TCP (7) IDresource terminate Le richieste alle risorse arrivano in questo caso in modo mediato, passando attraverso il gestore che ha appunto il ruolo di mediatore.

Gestore delle risorse : ipotesi di guasto live L’architettura realizzata prevede due ipotesi guasto: caduta del gestore: l’architettura è la stessa del servizio di Lookup; identificazione guasto e recovery sono quindi analoghe caduta di una risorsa Il gestore prova ad inoltare la richiesta ad una risorsa, ma non riesce a comunicare. Elimina la risorsa dal suo elenco centralizzato rilevando il guasto e provvede a smistare la richiesta su una risorsa diversa. Il tutto avviene in modo trasparente all’utente. Resource Manager Resource Printer Resource Printer Resource Printer

Sviluppo prototipo e test Il prototipo del sistema è stato realizzato in Java (demoni realizzati come Thread). Il sistema è stato testato su una rete di 5 computer. Il protocollo di discovery è stato implementato utilizzando le socket multicast, basate sul protocollo UDP. Per la realizzazione dei servizi si è scelto di utilizzare sempre le DatagramSocket (protocollo UDP) tranne per la connessione tra client e risorsa, dove si è ritenuta idonea una connessione TCP (attraverso l’uso di Socket e ServerSocket).

Conclusioni Nel progetto svolto vengono affrontate le tematiche/problematiche di un sistema distribuito che ha come fine la condivisione di risorse. In particolare si affrontano le tematiche di replicazione (calda, tiepida, fredda), dinamicità ed apertura, e tolleranza ai guasti. Concetto rilevante nella realizzazione: struttura semplice che usa protocolli semplici. Possibili estensioni: ampliamento dei servizi forniti (come gestione di file comuni o accesso ad un database) estendere le politiche di gestione delle risorse e delle richieste cliente raffinamento dei protocolli per velocizzare lo scambio di informazioni potrebbe aumentare le performance del sistema