Progetto di un supporto per il deployment di

Progetto di un supporto per il deployment di applicazioni distribuite di Samorani Michele

Obiettivi n n n Realizzare supporto per deployment di componenti interagenti n Allocazione risorse dinamica n Approccio esplicito Deployment effettuabile da console di comando (Master) I nodi destinazione devono caricare dinamicamente le classi che vengono distribuite

Caratteristiche n Ipotesi Guasto singolo (ma non del registry) n In alcuni casi guasto multiplo n Messaggi non persi n n Tecnologie usate OSGi n RMI n Paradigma della rete di interazione n Tu. Prolog n

Paradigma della rete di interazione (framework unibo. Env) Actor_1 istanzia actors Actor_2 Actor_3 send. Signal(action. Name, args) Cliente istruisce KERNEL ESEMPIO 1. Cliente: 2. Actor_2: 3. Actor_1: kernel. react. Interaction (Actor_1, Actor_2, “inc”) kernel. send. Signal(“inc”, args) void do. Action (String action. Name, Object args) {…} KB

Architettura fisica Macchina master RMI registry Applicazione. Master. Support Rmi. Server KB Disco master bundle 1 Macchina registry Factory di actor bundle 1 bundle 2 KB OSGi. Server 1 bundle 1 KB OSGi. Server 2 bundle 2 Macchina 1 Macchina 2

Architettura di un nodo (Osgi. Server) remoting. Support i-mo Factory. Manager KERNEL i-mo OSGi i-mo Actor_3 Actor_2 Actor_1 KB i-ma

Architettura logica actor segnale Cliente nodo Osgi. Server KB Osgi. Server Master. Support INVOCA API Master Application KB KB

API del master support n declare. Phisical. Node (nome. Nodo, IP) n n declare. Factory (tipo, bundle. Location) n n Installa la factory corrispondente nel nodo remoto n Istanzia un actor remote. React. Interaction (reactor, emitter, action. Name) Creazione di un canale comunicativo tramite riferimento remoto / supporto java. Beans remove. Interaction (reactor, emitter, action. Name) n n Dichiarazione di una factory di actor contenuta in un bundle deploy. Actor (tipo, nome. Actor, nome. Nodo) n n Configura (rinomina) un nodo non configurato Distruzione di un canale comunicativo destroy. Actor (nome. Actor, todo. Mode) n Distruzione di un actor Ogni azione scrive / cancella una tupla in tutte le KB

declare. Node (n 1, 192. 168. 70. 39) declare. Node (n 2, 192. 168. 70. 40) declare. Factory (counter, d: bundlesb 1. jar) Master. Support declare. Factory (gui, d: bundlesb 2. jar) deploy. Actor(counter, c 1, n 1) deploy. Actor(gui, g 1, n 2) Se entrambi gli actor install. Bundle sono sullo stesso deploy. Actor(counter, c 1) nodo, supporto java. Beans remote. React. Interaction (c 1, g 1, inc) c 1_ref g 1 Nodo n 2 n 1 IOsgi. Server_192. 168. 70. 39_127. 0. 0. 1). IOsgi. Server_192. 168. 70. 40_127. 0. 0. 1). n 2 Master DEMO 1: n 1: g 1, c 1 n 2: g 2 g 1, g 2 ->c 1 c 1 ->g 2

Tolleranza ai guasti: OBIETTIVI n Failure di un nodo non master: Occorre rimuovere l’entry dal registry n Occorre rimuovere eventuali riferimenti remoti inconsistenti n Occorre aggiornare la teoria n n Failure del nodo Master: Il sistema deve continuare a rispondere correttamente ai solleciti del cliente durante tutto il TTR del master n Il master, al rientro, deve poter reperire lo stato aggiornato del sistema n

Fallimento di un nodo n n Chi se ne accorge avvisa il Master Il Master aggiorna e diffonde la nuova teoria priva delle clausole riguardanti il nodo X Avviso il master DEMO 2: c 1 fails

Failure del Master n n n Agli occhi del cliente (≠ Master. Application) tutto continua a funzionare Il master, ogni volta che cambia lo stato del sistema, propaga una tupla a tutti i nodi (con Logical Clock), che la registrano nella propria KB Il master, quando entra nel sistema: n n Si accorge (dal registry) se ci sono nodi configurati. Cerca chi ha la KB più aggiornata, la carica e la inoltra a tutti i nodi n Il Il sistema caso peggiore è quando il master modifica lo stato (i. e. risponde bene i riferimenti remoti) anche durante remote. React. Interaction: c 1 -> g 2 (“update. Val”) DEMO 3: iles. TTR del master!!! Master Nodo di c 1 master exit Nodo di g 2 Agg. teoria Divulgazione teoria aggiunto riferimento a g 2

destroy. Actor (actor. Name, todo) n n n Il master elimina tutti i riferimenti remoti Il master distrugge actor. Name aspettando che finisca di lavorare Se todo==true n All’inizio il master scrive todo: destroy. Actor(actor. Name) in un nodo a caso n Il nodo “todo” comincia a monitorare il master. n Se si accorge che il master è fallito senza cancellare la clausola todo, si incarica di ripetere destroy. Actor n Al termine, cancella la clausola todo

TEST n Counter. Actor n n Gui. Actor n n n Input: “update. Val (int n)” -> visualizza n Output: “inc” : se viene premuto il tasto inc DEMO 4: c 1 lazy Master fails Master. Support n n Input: “inc” -> incrementa un contatore Output: “update. Val (int new. Val) “ Anche versione lazy, fail Realizzato anche in versione fail (fallisce durante destroy. Actor) Prove n Eseguite prove su 3 macchine in rete locale (LAB 2) Lenta la reazione del supporto in caso di guasti (oltre 10 sec)

Sviluppi futuri n n n Progetto di un registry RMI ad alta disponibilità e affidabilità… Messaggi master – nodo non bloccanti… Segnali tra gli actor con diverse semantiche (asincroni, …)