Progetto di un
Gestore di Nomi
Corso di Reti di Calcolatori L-S
prof. Antonio Corradi
A.A 2003/2004
Autore:
Molesini Ambra
Introduzione
Da quando è “esploso” Internet si è sentita sempre forte
l’esigenza di una entità capace di trasformare il “nome
logico“ di un servizio nelle sue “coordinate”, cioè
nell’indirizzo di rete e numero di porta su cui è in attesa il
servitore: questa entità è chiamata Gestore dei Nomi
il tipo di servizio che offre è prezioso, occorre che anche
in caso di un guasto il sevizio non venga negato, oppure
che i tempi in cui il servizio non sia disponibile siano
brevissimi.
occorre pensare al gestore dei nomi come ad un
servizio replicato
Obbiettivi
• Il gestore deve essere replicato per garantire comunque
il servizio
•I servitori si possono registrare/cancellare al servizio di
nomi
•I clienti devono fornirne il nome logico e otterranno
indirizzo di rete e numero di porta o indicazione di errore.
•Le copie devono essere calde
• Le copie devono monitorare il sistema per identificare
guasti
• Ipotesi di guasto singolo ai nodi
Idea Generale
Server
Richiesta
registrazione/
cancellazione
Cliente
Richiesta
indirizzo e porta
del server
Gestore
Nomi
Gestore
Nomi
Gestore
Nomi
Progetto: idea generale
Il gestore dei nomi è “un’entità complicata” che deve
svolgere innumerevoli attività durante il suo ciclo di vita:
• fornire un servizio a server e clienti esterni
• monitorare le copie che compongono il servizio
• attendere nuove copie
• risolvere problemi dovuti a crash
si è pensato per cui di strutturare l’entità come un
insieme di Demoni che collaborano tra loro al fine di
fornire il servizio richiesto
Progetto: replicazione
Come abbiamo già detto occorre che il gestore sia
replicato per poter tollerare guasti di diversa natura e
garantire comunque il servizio.
•Il tipo di replicazione scelto per questa applicazione
segue il modello delle copie passive di tipo Master-Slave
• Si è inoltre deciso che le copie si devono
autoconfigurare in una catena dopo che è partita la copia
Master
• Si è deciso di utilizzare un checkpointing event driven
(ad ogni interazione con una entità server) seguendo la
catena: Il master aggiorna il primo slave che aggiornerà il
secondo….e così via
Progetto: analisi guasti(1)
Prima di vedere come è stata strutturata l’applicazione è
bene porre l’attenzione sulla tipologia di guasti che si
devono riconoscere e risolvere.
Come scelta progettuale è stato sottolineato che le copie
si devono configurare in una catena e che si vuole un
modello a copie calde:
Master
I Slave
II Slave
N
Salve
Progetto: analisi guasti(2)
Con questo tipo di configurazione abbiamo diverse
tipologie di guasti possibili
• Caduta del master
Master
IMaster
Slave
III Slave
Slave
N
Salve
• Caduta di uno slave intermedio
Master
I Slave
III Slave
Slave
N
Salve
Progetto: analisi guasti(3)
Attesa nuovo
slave
• Caduta dell’ultimo slave
Master
I Slave
II Slave
NN-1
Salve
Slave
Struttura del master
Server
DemonServer
DemonLive
Pari
Gestore Nomi
Struttura
memorizza i
server
DemonClient
Client
DemonAggiorna
Pari
Struttura dello slave
DemonLive
DemonLiveSlave
Gestore Nomi
Struttura
memorizza i
server
DemonAttesa
DemonAggiornato
DemonAggiorna
Comunicazione tra Demoni(1)
La comunicazione tra demoni facenti parte della stessa
applicazione avviene attraverso il Gestore dei Nomi che
mette a disposizione un ambiente comune per il
“dialogo”.
Durante il normale funzionamento solo due Demoni
hanno bisogno di scambiarsi le informazioni:
• nel caso master: DemonServer e DemonAggiorna
• nel caso slave: DemonAggiornato e DemonAggiorna
inserisci
DemonServer
Gestore
Nomi
Aggiorna
DemonAggiorna
Comunicazione tra Demoni(2)
Quando si verificano guasti, si rende necessaria la
comunicazione di più Demoni perché in base alla
tipologia di guasto si devono prendere le opportune
decisioni di terminazione o di attesa
Passiamo ora a vedere i protocolli di comunicazione
Protocolli Comunicazione 1
• Comunicazione tra server esterno e DemonServer
registra
http://www.echo.it
123.155.96.14 2563
Server
DemonServer
Ok
• Comunicazione tra cliente e DemonClient
http://www.echo.it
DemonClient
Cliente
123.155.96.14
2563
Protocolli di Comunicazione 2
• Comunicazione tra DemonAggiorna e DemonAggiornato
DemonAggiorna
Cancella
http://www.echo.it
123.155.96.14 2563
DemonAggiornato
Cancellazione
avvenuta
corretamente
• Comunicazione per ingresso del master
Gestore
Master
Nomi
Entro
Time out
Protocolli di comunicazione 3
• Comunicazione tra DemonAttesa e nuova copia in arrivo
Entro
DemonAttesa
Gestore Nomi
Il master era in
attesa
Master 136
Entro
DemonAttesa
Gestore Nomi
Slave 123
123.125.145.11 125
139
Uno slave era in
attesa
Protocolli di Comunicazione 4
• Comunicazioni tra DemonLive e DemonLiveSlave
Llive
DemonLive
DemonLiveSlave
Normale
Live
master
Segnale copia diventa
master
DemonLive
DemonLiveSlave
live
Problemi
3652
2658
DemonLiveSlave
DemonLive
( nonno )
Master 2365
Slave 123
123.125.145.11 125
139
O uno o
l’altro
La copia deve
sostituire lo slave
intermedio caduto
Prototipo
E’ stato realizzato un prototipo dell’applicazione
nell’ambiente di sviluppo Java che realizza tutti gli
obbiettivi che ci siamo posti all’inizio. Scelte fatte:
• I demoni sono stati realizzati attraverso Thread
• I demoni accedono alla struttura dove sono memorizzati
i dati relativi ai server in modo mutuamente esclusivo
• Uso delle DatagramSocket e del protocollo UDP per lo
scambio dei messaggi
• ulteriore struttura in cui vengono inseriti i messaggi di
registrazione/ cancellazione dei server utilizzata per
facilitare la fase stessa di aggiornamento.
Sviluppi futuri
• Estendere il prototipo affinchè possa funzionare con il
multicast
• raffinare ulteriormente i protocolli per ridurre i tempi
necessari alle varie copie per accorgersi di un problema
• gestire il caso dell’arrivo contemporaneo di due slave
USI CONCRETI
questa applicazione è utilizzata nel progetto di un
collega di corso che ha realizzato un servizio di chat
Conclusioni
•La strutturazione del sistema in molti demoni è nata
dalla necessità di avere un sistema estremamente
“reattivo” nel senso che si voleva che il sistema fosse
sempre pronto a fornire il servizio richiesto da entrambe
le tipologie di utenti, delegando ad altri il compito di
fornire un aggiornamento alle copie e di attenderne di
nuove
•La scelta di fare l’aggiornamento ad ogni nuova
richiesta dei server e di strutturare le copie in una
“catena” è stata dettata dal fatto di avere le copie
“quanto più calde possibili” per riuscire a garantire
comunque un buon servizio aggiornato anche in caso di
caduta del Master
Conclusioni
L’applicazione realizzata si basa su protocolli e regole di
interazione semplici, non bisogna farsi trarre in inganno
dal numero di thread che la costituiscono, ogni thread
realizza una sola funzionalità, così oltre che al requisito
della semplicità guadagniamo anche in efficienza nei
tempi di risposta.
Inoltre questo ha permesso di sviluppare le varie parti del
sistema in modo quasi indipendente e di capire molto
velocemente la causa di malfunzionamenti riscontrati
durante la stesura del codice