Realizzazione di un supporto per la
progettazione di applicazioni
in ambiente distribuito
Università degli studi di Bologna
Facoltà di ingegneria
Reti di calcolatori L-S
Fiorani Enrico
Matr.196232
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.
2
Enrico Fiorani
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à
3
Enrico Fiorani
Dualità dei requisiti
4

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 Fiorani
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
5
Enrico Fiorani
Diagramma di sequenza (semplificato)
Fase iniziale
comune:
Init & Configure node
Possibile
richiesta dei
servizi
presenti
Risposta
mediata dal
Center
6
Selezione
server per il
servizio
richiesto
Enrico Fiorani
Estensioni al modello C/S

Possibilità di delegare l’attesa, il recupero e la gestione
del risultato ad una entità (ClientResponse) indipendente
dal client :
–
–


7
Modalità poll
Modalità call-back
Sincronizzazione e coordinamento tra le varie entità
server (* mediate dal Center)
Risposta al client ritardata e asincrona (Delegator)
Enrico Fiorani
Center consulente
(no intermediario)
Un sistema centralizzato:
il CenterService
Modalità
sincrona
Modalità
asincrona
public interface NewCenterServiceInterface extends Remote {
C
L
I
E
N
T
S
E
R
V
E
R
C
E
N
T
E
R
public Object chiediServizio(String metodo,Object o) throws RemoteException;
public Object chiediServizio(AddressInfo aCl,String metodo,Object o)...
Broadcast
public Object chiediServizioMulticast(String metodo,Object o) ...
(sincrona)
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;
}
8
Aggiornamento
copie calde
Aggiorna
stato Master
Sincronizzazione/
Coordinamento
Registrazione
servizi
Enrico Fiorani
Architettura CenterService
Deferred response
Selezione Server
Distribuzione carico
Salvataggio stato
su file XML
Monitoraggio
Server & Slave
Boot da file
Check-point di
Aggiornamento
Slave
9
Gestione richieste
Sequenziale/Concorrente
Enrico Fiorani
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;

10
Classi utilizzate: DistributionService
Enrico Fiorani
Monitor
Controllo periodico dello stato dei server registrati:




11

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 Fiorani
Tolleranza ai guasti
Garantire un comportamento del sistema prevedibile e
corretto anche in caso di:

Caduta o failure del nodo server :



Comuni fault applicativi:



12

Politica preventivaMonitor;
Politica di recoverySelezione nuovo server.
Gestione tramite timeout per socket;
Successiva ritrasmissione richiesta fallita;
Operazione abortita e ripresa dell’esecuzione.
Crash del CenterService.
Enrico Fiorani
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.


13
(+frequenzacopia calda ma +overhead)
(-frequenzacopia tiepida ma -overhead)
Enrico Fiorani
Master & Slave: il CenterService2

Aggiornamento periodico lista e stato server:
 Con salvataggio su file xml da parte di CS2;


Aggiornamento periodico di dati e informazioni del center
o dei clienti:


14
Public void aggiornaSlave(Object in)
Re-boot del Master riprendendo dallo stato globale
mantenuto aggiornato dallo slave


Public boolean copiaRegistroServer(AIContainer as)
public Object aggiornaMasterFromSlave(Object in)
Classi utilizzate:CenterComunicator,XmlCreator, Parser
Enrico Fiorani
Test
In ambiente distribuito composto da tre e quattro PC con
caratteristiche tecniche e prestazioni differenti:

Simulazione di diversi possibili malfunzionamenti e guasti





15
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 Fiorani
Un’applicazione reale:
“Bacheca elettronica sicura distribuita”

Consentire ad un gruppo chiuso di utenti di potersi
trasmettere informazioni riservate.
Accesso mediante autenticazione sul Center



Chiave comune unica


Messaggi firmati ma leggibili da tutti gli utenti
Operazioni possibili:


16
Numero chiuso di utenti (dati salvati sul Center)
Chiave e dati personali riservati (TripleDEIS)

Creazione nuove bacheche elettroniche;
Inserimento messaggi;
Lettura messaggi e identificazione dell’autoreEnrico Fiorani
Autenticazione e Identificazione
Rand
Y
CenterBacheca
Client / Server
UserID
X = R_ID
+
RandY
Bacheca
Key
Bacheca
Key
RandY
Ok!
Servizi disponibili
17
Database:
UserID
R_ID
In chiaro
Cifrato
Enrico Fiorani
UserKey
Un’applicazione reale:
“Search Engine Distribuito e Replicato”
Fornire operazioni tipiche di un motore di ricerca:



CenterService in modalità consulente per il cliente


18
public AddressInfo dammiServerPerServizio(String metodo)
Sincronizzazione server e aggiornamento copie mediate
dal center


Effettuare ricerca di un dataset esistente di dati che presentano
le caratteristiche desiderate;
Aggiunta di nuovi record al dataset.
..Object chiediServizioAlCenter(String m,AddressInfo ai,Object in)
Replicazione e monitoraggio offerta dal supporto
Enrico Fiorani
Conclusioni e sviluppi futuri





19
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.
Enrico Fiorani