Replicazione Master-Slave per Default Place in sistemi SOMA Alessandro Ghigi Reti di Calcolatori LS A.A 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  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

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 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

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

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

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 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

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

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

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 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

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 3: SlaveTransport Command 1.create worker 2.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 1: worker.start() 2: worker.stop() 3: RemoveAgent Command

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()

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 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 ReqAliveCommand Exceptio n

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 SlavePeerConnection RefreshCommand

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()

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

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 !

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()

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()

Test - Gerarchia  Questa è la gerarchia SOMA che è stata impiegata nello svolgimento dei diversi test:

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