Скачать презентацию Corso di Laurea in Ingegneria Informatica Facoltà di Скачать презентацию Corso di Laurea in Ingegneria Informatica Facoltà di

1cce3da92c280ab401bc877047563359.ppt

  • Количество слайдов: 17

Corso di Laurea in Ingegneria Informatica Facoltà di Ingegneria – A. A. 2005/2006 Università 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 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 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 Java di progettazione.

Protocollo di discovery Il protocollo di discovery permette ad una nuova entità di entare 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 lookup. Service address WSP master/ address. Bis bis. WSP discovery lookup. Service • nuova entità Server (Resource. Manager, Resource) e nuova entità Client discovery lookup. Service server discovery lookup. Service client lookup. Service address WRP

Servizio di LOOKUP: overview Un sistema a risorse condivise che vuole rispondere ai requisiti 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 Service Table ID HPInk. Jet 5000 MSP interface PRINT Servizio di LOOKUP: strutture dati Service Table ID HPInk. Jet 5000 MSP interface PRINT WSP/ MP port MUL 3032 WRP SUP Upgrade List UP discovery lookup. Service address WSP master/ address. Bis bis. WSP 127. 0. 0. 1 MULticast. Port: porta di multicast necessaria per il MULticast. Port discovery Quando nasce un Look. Up. Service manda un messaggio multicast per sapere se ci sono altri Look. Up. Services 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. • Waiting. Slave. Port: su questa porta l’ultimo slave della catena attende un nuovo slave Waiting. Slave. Port • Monitor. Port: se non si è l’ultimo slave la porta di waiting non deve essere attiva; si deve Monitor. Port però comunicare con lo slave in modo da farsi monitorare • Monitor. Slave. Port: su questa porta lo slave controlla il suo predecessore Monitor. Slave. Port • Upgrade. Port: da questa porta si mandano gli aggiornamenti al successore Upgrade. Port • Slave. Upgrade. Port: su questa porta si ricevono gli aggiornamenti dal predecessore Slave. Upgrade. Port • Waiting. Request. Port: se si è master un demone resta in ascolto di richieste Waiting. Request. Port

Servizio di LOOKUP: protocolli di comunicazione delete interface address Ilregistartion funzionamento a regime port Servizio di LOOKUP: protocolli di comunicazione delete interface address Ilregistartion funzionamento a regime port ID interface address port ID WRP looking. For ID del Lookup può essere così schematizzato: looking. For. Interface MP interface live MSP Master WSP Slave I ready UP bis. UP UP Upgrade List ready SUP UP slave Upgrade. Port

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

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

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

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

Risorsa stampante: protocolli di comunicazione Il comportamento a regime di una risorsa è attendere Risorsa stampante: protocolli di comunicazione Il comportamento a regime di una risorsa è attendere richieste dal cliente sulla porta WRP. La richiesta WRP prevede l’invio dei dati del cliente stesso. Client CP client ID address port TCP IDresource address TCPport 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 Server. Socket sulla porta TCPPort WRP e rimanendo in attesa di una richiesta di connessione Resource dal client (che deve avvenire entro un timeout). I dati Printer relativi alla porta di attesa della risorsa vengono quindi comunicati al client, in modo che possa aprire la EP TCP connessione. Sfruttando la connessione TCP il client può inviare alla stampante il file da stampare ed essa può quindi procedere nella stampa. Request queue

Risorsa stampante: ipotesi di guasto L’architettura realizzata prevede due fasi relative all’ipotesi guasto: 1. Risorsa stampante: ipotesi di guasto L’architettura realizzata prevede due fasi relative all’ipotesi guasto: 1. caduta della risorsa/client prima della connessione TCP WRP client ID Resource address Printer port CP Client EP 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. 2. caduta della risorsa/client durante connessione TCP stabilita TCP client ID Resource address port Printer TCP Client 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 Replicazione Servizio WRP ID Resource interface Manager Gestore delle risorse: overview e strutture dati Replicazione Servizio WRP ID Resource interface Manager PRINT HPInk. Jet 5000 port 3032 WTP 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 master/slave sono analoghi a quelli illustrati per il servizio di Lookup. In aggiunta sono presenti due demoni per la gestione delle risorse address in modo #request svolgere il compito di bilanciamento del da poter carico: 127. 0. 0. 1 0 carico • Waiting. Request. Port: attende registrazione da parte di Waiting. Request. Port stampanti e richieste da parte del cliente • Waiting. Termination. Port: attende messaggi di terminazione Waiting. Termination. Port da parte delle stampanti gestite, in modo da poter aggiornare il numero di richieste accodate su quella risorsa. 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 WRP Client Resource Gestore delle risorse: protocolli di comunicazione (3) client ID address port WRP Client Resource Manager WTP client ID address port (2) OK TCP CP (4) Request queue (5) TCP IDresource address TCPport WRP (1) registration interface address port IDResource (7) (6) Resource Printer EP TCP 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 L’architettura realizzata prevede due ipotesi guasto: 1. Gestore delle risorse : ipotesi di guasto L’architettura realizzata prevede due ipotesi guasto: 1. caduta del gestore: l’architettura è la stessa del servizio di Lookup; gestore identificazione guasto e recovery sono quindi analoghe 2. 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

Sviluppo prototipo e test Il prototipo del sistema è stato realizzato in Java (demoni 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. Thread • Il protocollo di discovery è stato implementato utilizzando le socket multicast, multicast basate sul protocollo UDP • Per la realizzazione dei servizi si è scelto di utilizzare sempre le Datagram. Socket (protocollo UDP) tranne per la connessione tra client e risorsa, dove si è ritenuta idonea una connessione TCP (attraverso l’uso di Socket e Server. Socket). Server. Socket

Conclusioni Nel progetto svolto vengono affrontate le tematiche/problematiche di un sistema distribuito che ha 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