Replicazione Master-Slave per
Default Place in sistemi
SOMA
master
slave
Alessandro Ghigi
Reti di Calcolatori LS
A.A. 2003-2004
Prof. Antonio Corradi
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

1.
2.
6.
7.
8.
9.
10.
Uno Slave può essere creato in ogni momento
tramite le informazioni di stato correnti del Master
contactMaster()
save repConnection
setDomains (DNS)
setFather, setChildren
setPlaces (PNS)
setPermConnections()
start pollingThread


slave
master
3: MeetCommand
4.
save repConnection
5: SendInfo
Command
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 destinazione
12: SlaveDNSChild
RefreshCommand
13. putDomain
14. add to childrenDNS
5: DomainRefresh
Command
slave
(to Father and other Children)
2.
4.
putDomain
add to childrenDNS
1: DomainRegister
Command
9: SlaveDNSFather
RefreshCommand
10. set Domains
11. set fatherDNS
3: PutDomainCommand
master
slave
6.
7.
master
set Domains
set fatherDNS
8: DomainRefreshCommand
(to Children)
DNS - Inserimento

In SOMA è anche possibile aggiungere dei domini in
maniera arbitraria
master
4: SlaveDNSTable
RefreshCommand
1: DNS.putDomainSlave()
2.
slave
5.
putDomain
5.
putDomain
putDomain
3: PutDomainCommand
(to Father and other Children)
master
1: PutDomainCommand
2.
putDomain
slave
4: SlaveDNSTable
RefreshCommand
DNS - Rimozione

In maniera analoga all’inserimento, è possibile
rimuovere una entry dal DNS
master
6: SlaveDNSRemove
Command
1: DNS.removeDomainSlave()
2.
3.
4.
slave
removeDomain
remove FatherDNS
remove from childrenDNS
7.
8.
9.
removeDomain
remove FatherDNS
remove from childrenDNS
7.
8.
9.
removeDomain
remove FatherDNS
remove from childrenDNS
5: RemoveDomainCommand
(to Father and other Children)
master
1: RemoveDomainCommand
2.
3.
4.
removeDomain
remove FatherDNS
remove from childrenDNS
slave
6: SlaveDNSRemove
Command
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 dominio
master
2.
4.
8: SlavePNS
RefreshCommand
putPlace
save connection
* 3: PutPlace
Command
slave
9.
1: PlaceRegister
Command
*
*
5: PlaceRefresh
Command
putPlace
putPlace
6.
7.
set Places
save connection
putPlace
PNS – Inserimento

Occorre avvertire lo Slave solamente se
l’inserimento avviene presso un Default Place
master
1: PNS.putPlaceSlave()
2.
4: SlavePNSTable
RefreshCommand
putPlace
* 3: PutPlace
Command
slave
*
*
*
5.
putPlace
PNS – Rimozione

La logica da seguire è quella del caso precedente: lo
Slave viene avvertito se è coinvolto un Default Place
master
1: PNS.removePlaceSlave()
2.
3.
4: SlavePNS
RemoveCommand
removePlace
remove connection
* 3: RemovePlace
Command
slave
*
*
*
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
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
master
1: NetManager.start
PermanentConnection()
3: SlavePermConnection
RefreshCommand
1: NetManager.stop
PermanentConnection()
2.
slave
flag = 2
1
put connection
remove
connection
4.
put connection
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: SlaveTransport
Command
1.
2.
create worker
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
1: worker.start()
slave
3: RemoveAgent
Command
2: worker.stop()
dest
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
1: worker.start()
1: worker.start()
2: worker.stop()
dest
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
Exceptio
n
ReqAliveCommand
ReqAliveCommand
master
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
master
Quelle che altri domini
avevano stabilito con il
Master
Per il secondo punto la
gestione è leggermente
più complicata
SlavePeerConnection
RefreshCommand
slave
Simulazione completa di guasto
1.
2.
3.
4.
5.
DNS.putDomain()
NetMgr.refreshPermC()
NetMgr.sendToAll
(SlavePeerConRefCmd)
PNS.putPlace()
AgMgr.restartAllAgts()
SlavePeerConnection
RefreshCommand
*
slave
master
ReqAliveCommand
*
**
Father
PutDomain
Command
PutPlace
Command
*
**
*
**
Children
**
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
master
OK !
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
1.
2.
3.
13.
contactMaster2()
save repConnection
stopAllConnections()
initNameServices()
master
4: ActivateMaster
Command
5.
6.
7.
8.
9.
10.
11.
12.
13.
setDomains (DNS)
setPlaces (PNS)
setFather, setChildren
setPermConnections
refreshPermConnections()
DNS.putDomain()
PNS.putPlace()
send SlavPeerConRefCmd
save repConnection
Simulazione completa riattivazione
Father
SlavePeerConnection
RefreshCommand
stopAllConnections()
slave
master
*
ActivateMaster
Command
1.
2.
3.
4.
*
**
*
**
5.
Impostazione STATO
(DNS, PNS, conns, etc.)
DNS.putDomain()
NetMgr.refreshPermC()
NetMgr.sendToAll
(SlavePeerConRefCmd)
PNS.putPlace()
**
*
**
Children
PutDomain
Command
PutPlace
Command
Test - Gerarchia

Questa è la gerarchia SOMA che è stata impiegata
nello svolgimento dei diversi test:
World
America
Europe
Italy
Rome
Venice
Bologna
USA
Spain
Madrid
Sevilla Orlando
Barcelona
Canada
NewYork Calgary
SanFrancisco
Toronto
Montreal
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