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

Presentazione sul tema: "Progetto di un supporto per il deployment di applicazioni distribuite di Samorani Michele."— Transcript della presentazione:

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

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

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

4 Paradigma della rete di interazione (framework uniboEnv) KERNEL Actor_1Actor_2Actor_3 KB sendSignal(actionName,args) Cliente istanzia actors istruisce 1.Cliente: kernel.reactInteraction (Actor_1, Actor_2, “inc”) 2.Actor_2: kernel.sendSignal(“inc”, args) 3.Actor_1: void doAction (String actionName, Object args) {…} ESEMPIO

5 Architettura fisica MasterSupport RMI registry RmiServer OSGiServer 2 OSGiServer 1 Macchina master Macchina 1 Macchina 2 Macchina registry ApplicazioneMaster bundle2 bundle1 Disco master KB bundle1bundle2bundle1 Factory di actor

6 Architettura di un nodo (OsgiServer) KB i-ma OSGi i-mo Actor_1 Actor_2 Actor_3 remotingSupport i-mo KERNEL i-mo FactoryManager

7 Architettura logica Cliente KB OsgiServer KB OsgiServer KB MasterSupport actor segnale nodo INVOCA API Master Application

8 declarePhisicalNode (nomeNodo, IP) declarePhisicalNode (nomeNodo, IP) Configura (rinomina) un nodo non configurato Configura (rinomina) un nodo non configurato declareFactory (tipo, bundleLocation) declareFactory (tipo, bundleLocation) Dichiarazione di una factory di actor contenuta in un bundle Dichiarazione di una factory di actor contenuta in un bundle deployActor (tipo, nomeActor, nomeNodo) deployActor (tipo, nomeActor, nomeNodo) Installa la factory corrispondente nel nodo remoto Installa la factory corrispondente nel nodo remoto Istanzia un actor Istanzia un actor remoteReactInteraction (reactor, emitter, actionName) remoteReactInteraction (reactor, emitter, actionName) Creazione di un canale comunicativo tramite riferimento remoto / supporto javaBeans Creazione di un canale comunicativo tramite riferimento remoto / supporto javaBeans removeInteraction (reactor, emitter, actionName) removeInteraction (reactor, emitter, actionName) Distruzione di un canale comunicativo Distruzione di un canale comunicativo destroyActor (nomeActor, todoMode) destroyActor (nomeActor, todoMode) Distruzione di un actor Distruzione di un actor API del master support Ogni azione scrive / cancella una tupla in tutte le KB

9 Nodo MasterSupport Nodo IOsgiServer_192.168.70.39_127.0.0.1). Master declareNode (n1, 192.168.70.39) n1 n1 IOsgiServer_192.168.70.40_127.0.0.1).n2 n2 declareNode (n2, 192.168.70.40) declareFactory (counter,d:\bundles\b1.jar) deployActor(counter, c1, n1) declareFactory (gui,d:\bundles\b2.jar) installBundle c1 deployActor(counter, c1) deployActor(gui, g1, n2) g1 remoteReactInteraction (c1, g1, inc) c1_ref Se entrambi gli actor sono sullo stesso nodo, supporto javaBeans DEMO 1: n1: g1,c1 n2: g2 g1,g2->c1 c1->g2

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

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

12 Agli occhi del cliente (≠ MasterApplication) tutto continua a funzionare Agli occhi del cliente (≠ MasterApplication) 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, 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: Il master, quando entra nel sistema: Si accorge (dal registry) se ci sono nodi configurati. 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 Cerca chi ha la KB più aggiornata, la carica e la inoltra a tutti i nodi Il caso peggiore è quando il master modifica lo stato (i.e. i riferimenti remoti) Il caso peggiore è quando il master modifica lo stato (i.e. i riferimenti remoti) Failure del Master es. remoteReactInteraction: c1 -> g2 (“updateVal”) Master Nodo di g2 aggiunto riferimento a g2 Agg. teoria Divulgazione teoria Agg. teoria Nodo di c1 DEMO 3: master exit Il sistema risponde bene anche durante il TTR del master!!!

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

14 CounterActor CounterActor Input: “inc” -> incrementa un contatore Input: “inc” -> incrementa un contatore Output: “updateVal (int newVal) “ Output: “updateVal (int newVal) “ Anche versione lazy, fail Anche versione lazy, fail GuiActor GuiActor Input: “updateVal (int n)” -> visualizza n Input: “updateVal (int n)” -> visualizza n Output: “inc” : se viene premuto il tasto inc Output: “inc” : se viene premuto il tasto inc MasterSupport MasterSupport Realizzato anche in versione fail (fallisce durante destroyActor) Realizzato anche in versione fail (fallisce durante destroyActor) Prove Prove Eseguite prove su 3 macchine in rete locale (LAB2) Lenta la reazione del supporto in caso di guasti (oltre 10 sec) Lenta la reazione del supporto in caso di guasti (oltre 10 sec) TEST DEMO 4: c1 lazy Master fails

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