replicazione master-slave per default place in sistemi soma
Post on 02-Jan-2016
36 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
2. removeDomain3. remove FatherDNS4. remove from childrenDNS
2. removeDomain3. remove FatherDNS4. remove from childrenDNS
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
**
** **
**
SlavePeerConnectionRefreshCommand
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
**
**
** **
SlavePeerConnectionRefreshCommand
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
top related