Realizzazione di un supporto per la progettazione di applicazioni in ambiente distribuito Fiorani Enrico Matr.196232 Università degli studi di Bologna.

Presentazione sul tema: "Realizzazione di un supporto per la progettazione di applicazioni in ambiente distribuito Fiorani Enrico Matr.196232 Università degli studi di Bologna."— Transcript della presentazione:

1 Realizzazione di un supporto per la progettazione di applicazioni in ambiente distribuito Fiorani Enrico Matr.196232 Università degli studi di Bologna Facoltà di ingegneria Reti di calcolatori L-S

2 Enrico Fiorani 2 Scopo del progetto Il sistema sviluppato vuole offrirsi come supporto alla progettazione di applicazioni in ambiente distribuito, adottando una struttura fortemente centralizzata e basandosi su una architettura di riferimento nota e consolidata come quella delle Remote Method Invocation di Sun.

3 Enrico Fiorani 3 Obiettivi e criticità Garanzia ed elevata disponibilità del servizio Distribuzione del carico di lavoro Down-time minimo Tolleranza e individuazione di guasti Monitoraggio a minima intrusione e basso overhead Architettura fault-tolerant Problemi legati alla centralità dellarchitettura: – Forte ripercussione sul sistema di guasti allunità centrale – Congestione – Sovraccarico di responsabilità

4 Enrico Fiorani 4 Dualità dei requisiti Realizzare una struttura solida e ben organizzata che risponda alle esigenze di interazione, coordinamento e replicazione necessarie allo sviluppo di applicazioni distribuite; Fare in modo che essa sia allo stesso tempo anche dinamica e flessibile per adattarsi il più possibile ad esigenze e scenari differenti.

5 Enrico Fiorani 5 Architettura del sistema Caratterizzata da tre unità fondamentali: – Client – Server – CenterService (gestore e coordinatore del sistema) Riferimenti remoti via RMI; Trasparenza lato client e server: – Invocano metodi solo sul center (*); – Center unico ad avere conoscenza globale del sistema; * modalità di default

6 Enrico Fiorani 6 Diagramma di sequenza (semplificato) Selezione server per il servizio richiesto Fase iniziale comune: Init & Configure node Risposta mediata dal Center Possibile richiesta dei servizi presenti

7 Enrico Fiorani 7 Estensioni al modello C/S Possibilità di delegare lattesa, il recupero e la gestione del risultato ad una entità (ClientResponse) indipendente dal client : – Modalità poll – Modalità call-back Sincronizzazione e coordinamento tra le varie entità server (* mediate dal Center) Risposta al client ritardata e asincrona (Delegator)

8 Enrico Fiorani 8 Un sistema centralizzato: il CenterService public interface NewCenterServiceInterface extends Remote { public Object chiediServizio(String metodo,Object o) throws RemoteException; public Object chiediServizio(AddressInfo aCl,String metodo,Object o)... public Object chiediServizioMulticast(String metodo,Object o)... public AddressInfo dammiServerPerServizio(String metodo)... public String[] mostraListaMetodi() throws RemoteException; public boolean registraMetodi(AddressInfo as) throws RemoteException; public Object chiediServizioAlCenter(String metodo,AddressInfo aiServer,Object in) public boolean copiaRegistroServer(AIContainer as) throws RemoteException; public void aggiornaSlave(Object in) throws RemoteException; public Object aggiornaMasterFromSlave(Object in) throws RemoteException; } CLIENTCLIENT SERVERSERVER CENTERCENTER Modalità sincrona Modalità asincrona Broadcast (sincrona) Center consulente (no intermediario) Registrazione servizi Sincronizzazione/ Coordinamento Aggiornamento copie calde Aggiorna stato Master Aggiornamento copie calde

9 Enrico Fiorani 9 Architettura CenterService Selezione Server Distribuzione carico Monitoraggio Server & Slave Check-point di Aggiornamento Slave Deferred response Salvataggio stato su file XML Boot da file Gestione richieste Sequenziale/Concorrente

10 Enrico Fiorani 10 Distribuzione del carico Suddivisione del lavoro tra i vari server che soddisfano quel particolare servizio. Selezione: – Random (per N>1) ; – Il più scarico nella categoria (per server differenziati) ; – Il più scarico globalmente; – Quello con meno clienti al momento collegati; Classi utilizzate: DistributionService

11 Enrico Fiorani 11 Monitor Controllo periodico dello stato dei server registrati: Ping periodici Center to Server a tutti quelli attivi; Stato di allerta per il server al primo ping mancato; Eliminazione dalla lista degli attivi a seguito di due ping consecutivi falliti; Ping di ritorno utilizzato anche per eventuali informazioni sui clienti connessi e sulle invocazioni ricevute; Classi utilizzate: Monitor e PingResponse.

12 Enrico Fiorani 12 Tolleranza ai guasti Garantire un comportamento del sistema prevedibile e corretto anche in caso di: Caduta o failure del nodo server : Politica preventiva Monitor; Politica di recovery Selezione nuovo server. Comuni fault applicativi: Gestione tramite timeout per socket; Successiva ritrasmissione richiesta fallita; Operazione abortita e ripresa dellesecuzione. Crash del CenterService.

13 Enrico Fiorani 13 Replicazione Affiancare al CenterService una seconda entità copia in grado di sostituirsi a questo in ogni momento Replicazione in spazio (CS+copia) ; Copie calde(*); Modello passivo (Master/Slave); Check-point di aggiornamento time-driven; (*)Rispettare il principio di minima intrusione. (+frequenza copia calda ma +overhead) (-frequenza copia tiepida ma -overhead)

14 Enrico Fiorani 14 Master & Slave: il CenterService2 Aggiornamento periodico lista e stato server: Con salvataggio su file xml da parte di CS2; Public boolean copiaRegistroServer(AIContainer as) Aggiornamento periodico di dati e informazioni del center o dei clienti: Public void aggiornaSlave(Object in) Re-boot del Master riprendendo dallo stato globale mantenuto aggiornato dallo slave public Object aggiornaMasterFromSlave(Object in) Classi utilizzate:CenterComunicator,XmlCreator, Parser

15 Enrico Fiorani 15 Test In ambiente distribuito composto da tre e quattro PC con caratteristiche tecniche e prestazioni differenti: Simulazione di diversi possibili malfunzionamenti e guasti Caduta nodo server Caduta nodo client Caduta nodo center Realizzazione di un prototipo per la verifica di tutti i metodi presentati Sfruttamento ed utilizzo del supporto per la realizzazione di applicazioni reali distribuite.

16 Enrico Fiorani 16 Unapplicazione reale: Bacheca elettronica sicura distribuita Consentire ad un gruppo chiuso di utenti di potersi trasmettere informazioni riservate. Accesso mediante autenticazione sul Center Numero chiuso di utenti (dati salvati sul Center) Chiave e dati personali riservati (TripleDEIS) Chiave comune unica Messaggi firmati ma leggibili da tutti gli utenti Operazioni possibili: Creazione nuove bacheche elettroniche; Inserimento messaggi; Lettura messaggi e identificazione dellautore

17 Enrico Fiorani 17 Autenticazione e Identificazione Client / Server CenterBacheca Database: UserID R_IDUserKey Rand Y X = R_ID + RandY In chiaro Cifrato Bacheca Key RandY Servizi disponibili Bacheca Key Ok!

18 Enrico Fiorani 18 Unapplicazione reale: Search Engine Distribuito e Replicato Fornire operazioni tipiche di un motore di ricerca: Effettuare ricerca di un dataset esistente di dati che presentano le caratteristiche desiderate; Aggiunta di nuovi record al dataset. CenterService in modalità consulente per il cliente public AddressInfo dammiServerPerServizio(String metodo) Sincronizzazione server e aggiornamento copie mediate dal center..Object chiediServizioAlCenter(String m,AddressInfo ai,Object in) Replicazione e monitoraggio offerta dal supporto

19 Enrico Fiorani 19 Conclusioni e sviluppi futuri Il supporto realizzato ha superato le diverse fasi di test proposte; Offre funzionalità e metodi utili nellambito del distribuito e con una architettura robusta e flessibile; Facilità nellestenderlo ed applicarlo ad applicazioni reali, tra le quali quelle proposte. Aggiunta di nuove funzionalità a problematiche comuni e importanti, non completamente affrontate; Interventi di ottimizzazione della soluzione proposta.