Realizzazione di un supporto per la progettazione di applicazioni

in ambiente distribuito

Fiorani EnricoMatr.196232

Università degli studi di Bologna

Facoltà di ingegneria

Reti di calcolatori L-S

Enrico Fiorani2

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.

Enrico Fiorani3

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à dell’architettura:– Forte ripercussione sul sistema di guasti all’unità centrale– Congestione– Sovraccarico di responsabilità

Enrico Fiorani4

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.

Enrico Fiorani5

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

Enrico Fiorani6

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

Enrico Fiorani7

Estensioni al modello C/S

Possibilità di delegare l’attesa, 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)

Enrico Fiorani8

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;}

CLIENT

SERVER

CENTER

Modalità sincrona

Modalità asincrona

Broadcast (sincrona)

Center consulente

(no intermediario)

Registrazione servizi

Sincronizzazione/

CoordinamentoAggiornamento

copie calde

Aggiorna stato Master

Aggiornamento copie calde

Enrico Fiorani9

Architettura CenterService

Selezione ServerDistribuzione carico

Monitoraggio Server & Slave

Check-point di Aggiornamento

Slave

Deferred response

Salvataggio statosu file XML

Boot da file

Gestione richiesteSequenziale/Concorrente

Enrico Fiorani10

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

Enrico Fiorani11

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.

Enrico Fiorani12

Tolleranza ai guasti

Garantire un comportamento del sistema prevedibile e corretto anche in caso di:

Caduta o failure del nodo server : Politica preventivaMonitor; Politica di recoverySelezione nuovo server.

Comuni fault applicativi: Gestione tramite timeout per socket; Successiva ritrasmissione richiesta fallita; Operazione abortita e ripresa dell’esecuzione.

Crash del CenterService.

Enrico Fiorani13

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.

(+frequenzacopia calda ma +overhead) (-frequenzacopia tiepida ma -overhead)

Enrico Fiorani14

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

Enrico Fiorani15

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.

Enrico Fiorani16

Un’applicazione 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 dell’autore

Enrico Fiorani17

Autenticazione e Identificazione

Client / Server

CenterBacheca

Database:

UserID

UserID R_ID UserKey

RandY

X = R_ID +

RandY

In chiaro

Cifrato

BachecaKey

RandY

Servizi disponibili

BachecaKey

Ok!

Enrico Fiorani18

Un’applicazione 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

Enrico Fiorani19

Conclusioni e sviluppi futuri

Il supporto realizzato ha superato le diverse fasi di test proposte;

Offre funzionalità e metodi utili nell’ambito del distribuito e con una architettura robusta e flessibile;

Facilità nell’estenderlo 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.