Replicazione Master-Slave per Default Place in sistemi SOMA

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, ilPNS); 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 • contactMaster() • save repConnection • setDomains (DNS) • setFather, setChildren • setPlaces (PNS) • setPermConnections() • start pollingThread 4. save repConnection 3: MeetCommand 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

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 3: PutDomainCommand (to Father and other Children) 12: SlaveDNSChild RefreshCommand • putDomain • 4. add to childrenDNS 13. putDomain 14. add to childrenDNS 5: DomainRefresh Command 1: DomainRegister Command 9: SlaveDNSFather RefreshCommand • set Domains • set fatherDNS • set Domains • set fatherDNS 8: DomainRefreshCommand (to Children)

10. DNS - Inserimento • In SOMA è anche possibile aggiungere dei domini in maniera arbitraria 4: SlaveDNSTable RefreshCommand 1: DNS.putDomainSlave() 5. putDomain 2. putDomain 3: PutDomainCommand (to Father and other Children) 4: SlaveDNSTable RefreshCommand 1: PutDomainCommand 5. putDomain 2. putDomain

11. DNS - Rimozione • In maniera analoga all’inserimento, è possibile rimuovere una entry dal DNS 6: SlaveDNSRemove Command 1: DNS.removeDomainSlave() • removeDomain • remove FatherDNS • remove from childrenDNS • removeDomain • remove FatherDNS • remove from childrenDNS 5: RemoveDomainCommand (to Father and other Children) 6: SlaveDNSRemove Command 1: RemoveDomainCommand 7. removeDomain 8. remove FatherDNS 9. remove from childrenDNS • removeDomain • remove FatherDNS • 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 8: SlavePNS RefreshCommand • putPlace • 4. save connection 9. putPlace 3: PutPlace Command * 1: PlaceRegister Command * * 5: PlaceRefresh Command putPlace 6. set Places 7. save connection putPlace

14. PNS – Inserimento • Occorre avvertire lo Slave solamente se l’inserimento avviene presso un Default Place 1: PNS.putPlaceSlave() 4: SlavePNSTable RefreshCommand 5. putPlace • putPlace 3: PutPlace Command * * * *

15. PNS – Rimozione • La logica da seguire è quella del caso precedente: lo Slave viene avvertito se è coinvolto un Default Place 1: PNS.removePlaceSlave() 4: SlavePNS RemoveCommand 5. removePlace • removePlace • remove connection 3: RemovePlace Command * * * *

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 1: NetManager.stop PermanentConnection() flag = 1 flag = 2 2. put connection 2. remove connection 4. put connection 4. 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() 1: worker.start()

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

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 • DNS.putDomain() • NetMgr.refreshPermC() • NetMgr.sendToAll • (SlavePeerConRefCmd) • PNS.putPlace() • AgMgr.restartAllAgts() SlavePeerConnection RefreshCommand * ReqAliveCommand Father ReqAliveCommand * PutDomain Command PutPlace Command * * Children

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 • setDomains (DNS) • setPlaces (PNS) • setFather, setChildren • setPermConnections • refreshPermConnections() • DNS.putDomain() • PNS.putPlace() • send SlavPeerConRefCmd • save repConnection 4: ActivateMaster Command • contactMaster2() • save repConnection • stopAllConnections() • 13. initNameServices()

31. * * * * * * * * Simulazione completa riattivazione Father SlavePeerConnection RefreshCommand stopAllConnections() * ActivateMaster Command • Impostazione STATO (DNS, PNS, conns, etc.) • DNS.putDomain() • NetMgr.refreshPermC() • NetMgr.sendToAll • (SlavePeerConRefCmd) • 5. PNS.putPlace() * * * PutDomain Command PutPlace Command Children

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