Scaricare la presentazione
La presentazione è in caricamento. Aspetta per favore
PubblicatoGisella Danieli Modificato 9 anni fa
1
Replicazione Master-Slave per Default Place in sistemi SOMA Alessandro Ghigi Reti di Calcolatori LS A.A. 2003-2004 Prof. Antonio Corradi
2
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
3
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
4
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
5
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
6
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
7
Definizione dello Slave Uno Slave può essere creato in ogni momento tramite le informazioni di stato correnti del Master 3: MeetCommand 5: SendInfo Command 4.save repConnection 1.contactMaster() 2.save repConnection 6.setDomains (DNS) 7.setFather, setChildren 8.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
8
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
9
DNS - Registrazione Il dominio che si registra diventa un “figlio” per il Default Place di destinazione 1: DomainRegister Command 2.putDomain 4.add to childrenDNS 3: PutDomainCommand (to Father and other Children) 13.putDomain 14.add to childrenDNS 6.set Domains 7.set fatherDNS 5: DomainRefresh Command 12: SlaveDNSChild RefreshCommand 8: DomainRefreshCommand (to Children) 9: SlaveDNSFather RefreshCommand 10.set Domains 11.set fatherDNS
10
DNS - Inserimento In SOMA è anche possibile aggiungere dei domini in maniera arbitraria 3: PutDomainCommand (to Father and other Children) 4: SlaveDNSTable RefreshCommand 1: DNS.putDomainSlave() 4: SlaveDNSTable RefreshCommand 1: PutDomainCommand 5.putDomain 2.putDomain
11
DNS - Rimozione In maniera analoga all’inserimento, è possibile rimuovere una entry dal DNS 5: RemoveDomainCommand (to Father and other Children) 6: SlaveDNSRemove Command 1: DNS.removeDomainSlave() 6: SlaveDNSRemove Command 1: RemoveDomainCommand 7.removeDomain 8.remove FatherDNS 9.remove from childrenDNS 2.removeDomain 3.remove FatherDNS 4.remove from childrenDNS 2.removeDomain 3.remove FatherDNS 4.remove from childrenDNS 7.removeDomain 8.remove FatherDNS 9.remove from childrenDNS
12
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
13
PNS - Registrazione Avviene quando un Place manifesta la propria intenzione di entrare a far parte di un dominio 1: PlaceRegister Command 5: PlaceRefresh Command 2.putPlace 4.save connection * * 3: PutPlace Command * putPlace 6.set Places 7.save connection 8: SlavePNS RefreshCommand 9.putPlace
14
PNS – Inserimento Occorre avvertire lo Slave solamente se l’inserimento avviene presso un Default Place * * * * 3: PutPlace Command 1: PNS.putPlaceSlave() 2.putPlace 4: SlavePNSTable RefreshCommand 5.putPlace
15
PNS – Rimozione La logica da seguire è quella del caso precedente: lo Slave viene avvertito se è coinvolto un Default Place * * * * 3: RemovePlace Command 1: PNS.removePlaceSlave() 2.removePlace 3.remove connection 4: SlavePNS RemoveCommand 5.removePlace
16
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
17
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.start PermanentConnection() 3: SlavePermConnection RefreshCommand 2.put connection4.put connection flag = 1 1: NetManager.stop PermanentConnection() flag = 2 2.remove connection4.remove connection
18
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
19
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 3: SlaveTransport Command 1.create worker 2.worker.start() 4.create worker
20
Esecuzione normale Nel caso in cui l’agente termini correttamente la propria esecuzione sul Master, occorre semplicemente rimuovere il worker dallo Slave 1: worker.start() 2: worker.stop() 3: RemoveAgent Command
21
Malfunzionamento In caso di malfunzionamento, l’esecuzione del worker dell’agente riprende dall’inizio sullo Slave, presso il quale, in ogni caso, termina 1: worker.start() 2: worker.stop()
22
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
23
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 ReqAliveCommand
24
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 ReqAliveCommand Exceptio n
25
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
26
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 SlavePeerConnection RefreshCommand
27
Simulazione completa di guasto ReqAliveCommand * PutDomain Command Father Children * * * PutPlace Command * * * * * * * * SlavePeerConnection RefreshCommand 1.DNS.putDomain() 2.NetMgr.refreshPermC() 3.NetMgr.sendToAll (SlavePeerConRefCmd) 4.PNS.putPlace() 5.AgMgr.restartAllAgts()
28
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
29
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 OK !
30
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 4: ActivateMaster Command 5.setDomains (DNS) 6.setPlaces (PNS) 7.setFather, setChildren 8.setPermConnections 9.refreshPermConnections() 10.DNS.putDomain() 11.PNS.putPlace() 12.send SlavPeerConRefCmd 13.save repConnection 1.contactMaster2() 2.save repConnection 3.stopAllConnections() 13.initNameServices()
31
Simulazione completa riattivazione * PutDomain Command Father Children * * * PutPlace Command * * * * * * * * SlavePeerConnection RefreshCommand 1.Impostazione STATO (DNS, PNS, conns, etc.) 2.DNS.putDomain() 3.NetMgr.refreshPermC() 4.NetMgr.sendToAll (SlavePeerConRefCmd) 5.PNS.putPlace() ActivateMaster Command stopAllConnections()
32
Test - Gerarchia Questa è la gerarchia SOMA che è stata impiegata nello svolgimento dei diversi test:
33
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
34
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
35
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
Presentazioni simili
© 2024 SlidePlayer.it Inc.
All rights reserved.