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 Gestore Nomi Server Cliente Richiesta registrazione/ cancellazione Richiesta indirizzo e porta del server 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: MasterI SlaveII Slave N  Salve

Progetto: analisi guasti(2) Con questo tipo di configurazione abbiamo diverse tipologie di guasti possibili Caduta del master Caduta di uno slave intermedio MasterI SlaveII Slave N  Salve Master I SlaveII Slave N  Salve I Slave

Progetto: analisi guasti(3) Caduta dell’ultimo slave MasterI SlaveII Slave N  Salve N-1 Slave Attesa nuovo slave

Struttura del master

Struttura dello slave

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 Gestore Nomi DemonServer inserisci DemonAggiorna Aggiorna

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 Comunicazione tra cliente e DemonClient

Protocolli di Comunicazione 2 Comunicazione tra DemonAggiorna e DemonAggiornato Comunicazione per ingresso del master Gestore Nomi Entro Time out Master

Protocolli di comunicazione 3 Comunicazione tra DemonAttesa e nuova copia in arrivo Il master era in attesa Uno slave era in attesa

Protocolli di Comunicazione 4 Comunicazioni tra DemonLive e DemonLiveSlave Normale Segnale copia diventa master 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