Replicazione Master-Slave per Default Place in sistemi SOMA

Replicazione Master-Slave per Default Place in sistemi

SOMA

Alessandro Ghigi

Reti di Calcolatori LS

A.A. 2003-2004

Prof. Antonio Corradi

master slave

Sistemi ad agenti mobili Il paradigma ad agenti mobili rappresenta un’idea

innovativa ed un tentativo per porre soluzione ad alcuni gravi problemi, come l’ampiezza di banda

Le proprietà di un buon sistema di questo tipo sono: Scalabilità Apertura e portabilità Sicurezza

Per garantire scalabilità è buona cosa predisporre dei meccanismi atti alla replicazione delle risorse, in modo tale da affontare con efficacia casi di guasto

SOMA SOMA è una piattaforma ad agenti mobili scritta in

Java e sviluppata presso l’Università di Bologna Un Place rappresenta l’astrazione di nodo e non è

altro che l’ambiente di esecuzione degli agenti Un Dominio è costituito da un insieme di Place, che

si conoscono a vicenda (il naming è gestito da una tabella, il PNS); fra di essi ne esiste uno che funge da interfaccia con il mondo esterno, il Default Place

Ogni dominio può conoscere altri domini del sistema, memorizzando le informazioni nel suo DNS

Idea di base L’idea del progetto è nata dalla volontà di aumentare

la scalabilità del sistema introducendo meccanismi di replicazione (fino ad ora assenti)

In particolare è stata concentrata l’attenzione sui Default Place, che rivestono maggior importanza

In tutta la trattazione è stata impiegata la comoda e già implementata infrastruttura che permette la comunicazione fra Place tramite comandi

Sono state adottate ipotesi molto forti in modo da operare all’interno di un certo contesto, limitato

Ipotesi realizzative Replicazione di tipo Master/Slave, con una sola

copia passiva in grado di sostituire quella principale Replicazione limitata a quattro componenti di base

di un Environment SOMA: DNS PNS Network Manager (gestore delle comunicazioni) Agent Manager (gestore degli agenti)

Si suppone inoltre che lo Slave, quando è attivo, non subisca dei malfunzionamenti

Linee guida Il Master aggiorna lo Slave in maniera event-driven,

ovvero non appena intervengono dei cambiamenti sul suo stato che interessano una delle quattro componenti citate in precedenza

Lo Slave ha il compito di controllare, a intervalli regolari, che il Master sia in esecuzione

In caso di malfunzionamento lo Slave diventa la copia attiva, ma continua a verificare lo stato del Master, al quale cede nuovamente il controllo non appena quest’ultimo torna operativo

Definizione dello Slave Uno Slave può essere creato in ogni momento

tramite le informazioni di stato correnti del Masterslave master

3: MeetCommand

5: SendInfoCommand

4. save repConnection

1. contactMaster()2. save repConnection6. setDomains (DNS)7. setFather, setChildren8. setPlaces (PNS)9. setPermConnections()10. start pollingThread

Il protocollo di presentazione fa in modo che entrambi i pari salvino gli estremi della connessione e che lo Slave salvi le informazioni correnti di stato

pollingThread verifica le condizioni del Master

DNS Il DomainNameService non è altro che una tabella,

presente solamente presso i Default Place, che contiene gli identificativi dei domini del sistema ai quali un certo nodo può essere interessato

Rappresenta pertanto la visibilità che quel nodo ha del sistema, potrebbe essere anche solo parziale

Sono possibili diverse operazioni che coinvolgono l’aggiornamento di tale componente: registrazione, inserimento e rimozione; in seguito ad ogni modifica, lo Slave dev’essere avvisato

DNS - Registrazione Il dominio che si registra diventa un “figlio” per il

Default Place di destinazioneslave master

slave master

1: DomainRegister Command

2. putDomain4. add to childrenDNS

3: PutDomainCommand(to Father and other Children)

13. putDomain14. add to childrenDNS

6. set Domains7. set fatherDNS

5: DomainRefresh Command

12: SlaveDNSChildRefreshCommand

8: DomainRefreshCommand(to Children)

9: SlaveDNSFatherRefreshCommand10. set Domains

11. set fatherDNS

DNS - Inserimento In SOMA è anche possibile aggiungere dei domini

in maniera arbitrariamaster slave

3: PutDomainCommand(to Father and other Children)

4: SlaveDNSTableRefreshCommand1: DNS.putDomainSlave()

master slave

4: SlaveDNSTableRefreshCommand1: PutDomainCommand

5. putDomain

5. putDomain

2. putDomain

2. putDomain

DNS - Rimozione In maniera analoga all’inserimento, è possibile

rimuovere una entry dal DNSmaster slave

5: RemoveDomainCommand(to Father and other Children)

6: SlaveDNSRemoveCommand

1: DNS.removeDomainSlave()

master slave

6: SlaveDNSRemoveCommand

1: RemoveDomainCommand

7. removeDomain8. remove FatherDNS9. remove from childrenDNS




PNS Il PlaceNameService è la tabella, posseduta da ogni

Place di un dominio, contenente gli identificativi di tutti i nodi che compongono quel dominio

Poiché, per ipotesi, la replicazione coinvolge solamente i Default Place, la gestione di tutte le operazioni, analoghe al caso precedente del DNS, risulta leggermente più semplice

Un Default Place deve inviare al suo Slave un comando di aggiornamento non appena all’interno del dominio avvengono cambiamenti nella topologia

PNS - Registrazione Avviene quando un Place manifesta la propria

intenzione di entrare a far parte di un dominiomaster slave

1: PlaceRegisterCommand

5: PlaceRefreshCommand

2. putPlace4. save connection

*

*

3: PutPlaceCommand

*

putPlace

putPlace 6. set Places7. save connection

8: SlavePNSRefreshCommand

9. putPlace

PNS – Inserimento Occorre avvertire lo Slave solamente se

l’inserimento avviene presso un Default Place

master slave

** *

* 3: PutPlaceCommand

1: PNS.putPlaceSlave()

2. putPlace

4: SlavePNSTableRefreshCommand 5. putPlace

PNS – Rimozione La logica da seguire è quella del caso precedente: lo

Slave viene avvertito se è coinvolto un Default Place

master slave

** *

* 3: RemovePlaceCommand

1: PNS.removePlaceSlave()

2. removePlace3. remove connection

4: SlavePNSRemoveCommand 5. removePlace

Network Manager È il componente di un Environment SOMA che si

preoccupa di gestire le connessioni di un Place In SOMA ogni Place di un dominio è connesso in

maniera permanente con tutti gli altri nodi del dominio

Se invece un Default Place desidera comunicare con un altro dominio, la connessione viene stabilita by need, e poi subito eliminata

Un dominio può tuttavia stabilire, su richiesta, connessioni permanenti anche con altri domini

master slave

Connessioni permanenti Le uniche operazioni, presso il Default Place, che

richiedono un aggiornamento dello Slave, sono la creazione e la distruzione di connessioni permanenti

Tali connessioni, come appena detto, vengono stabilite solo su richiesta

1: NetManager.startPermanentConnection()

3: SlavePermConnectionRefreshCommand

2. put connection 4. put connection

flag = 1

1: NetManager.stopPermanentConnection()

flag = 2

2. remove connection 4. remove connection

Agent Manager È l’oggetto, contenuto presso un Environment, che si

occupa della gestione degli agenti mobili; in SOMA un agente è un’entità passiva, non un thread

Non appena un agente approda in un Place, gli viene assegnato un worker, componente responsabile della sua gestione, specialmente in merito alla mobilità

Quando un agente lascia un Place, il corrispondente worker viene distrutto

Un agente comunica con il mondo esterno tramite un oggetto di classe AgentSystem

Replicazione worker Quando un agente approda presso un Default Place,

viene creato e messo in esecuzione un nuovo worker Se è presente uno Slave, l’agente viene inviato anche

presso tale nodo, dove viene creato (e non messo in esecuzione) un nuovo worker

master slave

3: SlaveTransportCommand

1. create worker2. worker.start()

4. create worker

Esecuzione normale Nel caso in cui l’agente termini correttamente la

propria esecuzione sul Master, occorre semplicemente rimuovere il worker dallo Slave

master slave

dest

1: worker.start()

2: worker.stop()

3: RemoveAgentCommand

Malfunzionamento In caso di malfunzionamento, l’esecuzione del

worker dell’agente riprende dall’inizio sullo Slave, presso il quale, in ogni caso, termina

master slave

dest

1: worker.start() 1: worker.start()

2: worker.stop()

Altre considerazioni Se un nodo previsto sul cammino di un agente cade

prima che esso effettivamente giunga su di esso, non c’è alcun problema: il comando di trasporto si basa sul DNS, che viene aggiornato subito con la entry corrispondente allo Slave, ed è pertanto in grado di determinare la destinazione in maniera corretta

Se il Master torna attivo mentre un agente è in esecuzione sullo Slave, il worker corrispondente termina comunque la propria esecuzione sul quel nodo, essendone pienamente in grado

Verifica stato del Master Il nodo Slave, tramite il pollingThread nominato in

precedenza, controlla, a intervalli regolari, che il Master sia effettivamente attivo

L’intervallo è ora prefissato a 30 secondi, si potrebbe pensare di dare la possibilità all’utente di specificarlo al momento della creazione dello Slave

slave master

ReqAliveCommand

Guasto: caduta del Master Se ReqAliveCommand non riesce ad essere spedito,

significa che il Master non è più attivo Viene lanciata in tal caso un’eccezione, la quale

dev’essere opportunamente gestita in modo tale da effettuare tutte le operazioni necessarie

slave master

ReqAliveCommandReqAliveCommand

Exception

Guasto: come agire Sono diverse le operazioni che, in caso di guasto, lo

Slave deve compiere per sostituirsi con piena efficienza al corrispondente Master: Inserimento del proprio PlaceInfo nel DNS ed invio di un

PutDomainCommand a tutta la gerarchia di domini Inserimento del proprio PlaceInfo nel PNS ed invio di un

PutPlaceCommand a tutti i Places registrati Aggiornamento delle connessioni permanenti (da e verso

il Master, ora saranno analizzate) Riesecuzione (dall’inizio, come visto) di tutti i worker

degli agenti eventualmente interrotti dal guasto

Guasto: connessioni permanenti Occorre riattivare due tipi

di connessioni: Quelle stabilite dal Master

verso altri domini Quelle che altri domini

avevano stabilito con il Master

Per il secondo punto la gestione è leggermente più complicata

master slave

SlavePeerConnectionRefreshCommand

Simulazione completa di guasto

slave master

ReqAliveCommandReqAliveCommand

*PutDomainCommand

Father

Children

* *

*

PutPlaceCommand

**

** **

**


1. DNS.putDomain()2. NetMgr.refreshPermC()3. NetMgr.sendToAll

(SlavePeerConRefCmd)4. PNS.putPlace()5. AgMgr.restartAllAgts()

Verifica stato del Master Per ipotesi, appena il Master torna attivo in seguito

ad un malfunzionamento, riprende il controllo Pertanto lo Slave deve comunque continuare a

controllare lo stato della copia primaria Il controllo avviene sempre tramite pollingThread ad

un intervallo prefissato di 30 secondi

slave master

Riattivazione del Master Non appena si riesce a stabilire una connessione,

significa che il Master è nuovamente attivo In tal caso vengono eseguite le operazioni necessarie

per fare in modo che il controllo passi nuovamente dallo Slave alla copia primaria

slave masterOK !

Riattivazione: come agire Dopo aver fermato tutte le proprie connessioni

permanenti, lo Slave invia al Master un comando, con lo scopo di trasferire lo stato e di eseguire le operazioni viste in caso di guasto, a ruoli invertiti

Provvede poi ad inserire la entry del nodo attivo nelle proprie tabelle DNS e PNS

slave master

4: ActivateMasterCommand

5. setDomains (DNS)6. setPlaces (PNS)7. setFather, setChildren8. setPermConnections9. refreshPermConnections()10. DNS.putDomain()11. PNS.putPlace()12. send SlavPeerConRefCmd13. save repConnection

1. contactMaster2()2. save repConnection3. stopAllConnections()13. initNameServices()

Simulazione completa riattivazione

slave master

*PutDomainCommand

Father

Children

* *

*

PutPlaceCommand

**

**

** **


1. Impostazione STATO (DNS, PNS, conns, etc.)

2. DNS.putDomain()3. NetMgr.refreshPermC()4. NetMgr.sendToAll

(SlavePeerConRefCmd)5. PNS.putPlace()

ActivateMasterCommand

stopAllConnections()

Test - Gerarchia Questa è la gerarchia SOMA che è stata impiegata

nello svolgimento dei diversi test:

World

Europe America

Italy USASpain Canada

Rome

Bologna Barcelona

NewYork CalgaryVenice SevillaMadrid

SanFrancisco

Orlando

Montreal

Toronto

Test – Simulazioni senza agenti Sono stati creati gli Slave per i Default Place del

terzo livello, quelli corrispondenti ai paesi Sono state effettuate tutte le prove possibili in merito

a registrazione, inserimento e rimozione di entry sia per quanto riguarda il DNS che il PNS

Sono state simulate sia cadute di uno o più nodi, sia riattivazioni da parte dei Master: è stato verificato il corretto aggiornamento delle tabelle e delle connessioni permanenti, da e verso il Place

Tutte queste prove hanno dato i risultati previsti

Test – Simulazioni con agenti Non è stato implementato un servizio vero e proprio,

ma è stato creato un semplice agente (HelloAgent) con la funzione di stampare a video un messaggio

Sono state simulate le condizioni più delicate: Esecuzione normale sul nodo Master Caduta di un nodo mentre l’agente è in esecuzione Caduta di un nodo previsto sul cammino dell’agente ma

non ancora visitato Riattivazione del Master mentre l’agente è in esecuzione

sullo Slave Anche in tal caso sono stati ottenuti i risultati sperati

Conclusioni Lo svolgimento della trattazione ha permesso di

entrare in contatto con due aspetti molto importanti nell’ambito delle Reti di Calcolatori: L’analisi ed il funzionamento di un sistema ad agenti

mobili come SOMA, che ha messo in luce gli aspetti e le problematiche di un’infrastruttura di questo tipo

La necessità di una reale esigenza di replicazione, affiancata da tutta una serie di operazioni a contorno molto importanti: scelta dei componenti, protocolli per la rilevazione e l’aggiornamento dello stato e, più in generale, il coordinamento delle entità coinvolte

Quanto trattato può essere ulteriormente sviluppato

Replicazione Master-Slave per Default Place in sistemi SOMA

Documents

Transcript of Replicazione Master-Slave per Default Place in sistemi SOMA