Progetto di un supporto per il
deployment
di applicazioni distribuite
di
Samorani Michele
Obiettivi



Realizzare supporto per deployment di
componenti interagenti

Allocazione risorse dinamica

Approccio esplicito
Deployment effettuabile da console di comando
(Master)
I nodi destinazione devono caricare
dinamicamente le classi che vengono distribuite
Caratteristiche

Ipotesi




Guasto singolo (ma non del registry)
In alcuni casi guasto multiplo
Messaggi non persi
Tecnologie usate




OSGi
RMI
Paradigma della rete di interazione
TuProlog
Paradigma della rete di interazione
(framework uniboEnv)
Actor_1
istanzia actors
Actor_2
Actor_3
sendSignal(actionName,args)
Cliente
istruisce
KERNEL
ESEMPIO
1.
Cliente:
2.
Actor_2:
3.
Actor_1:
kernel.reactInteraction (Actor_1, Actor_2, “inc”)
kernel.sendSignal(“inc”, args)
void doAction (String actionName, Object args) {…}
KB
Architettura fisica
Macchina master
RMI
registry
ApplicazioneMaster
MasterSupport
RmiServer
KB
Disco master
bundle1
Macchina registry
Factory di
actor
bundle1 bundle2
KB OSGiServer 1
bundle1
KB
OSGiServer 2
bundle2
Macchina 1
Macchina 2
Architettura di un nodo
(OsgiServer)
remotingSupport i-mo
FactoryManager
KERNEL i-mo
OSGi i-mo
Actor_3
Actor_2
Actor_1
KB i-ma
Architettura logica
actor
segnale
Cliente
Cliente
nodo
OsgiServer
KB
OsgiServer
MasterSupport
INVOCA API
Master Application
KB
KB
API del master support

declarePhisicalNode (nomeNodo, IP)


declareFactory (tipo, bundleLocation)




Installa la factory corrispondente nel nodo remoto

Istanzia un actor
remoteReactInteraction (reactor, emitter, actionName)
Creazione di un canale comunicativo tramite riferimento remoto /
supporto javaBeans
removeInteraction (reactor, emitter, actionName)


Dichiarazione di una factory di actor contenuta in un bundle
deployActor (tipo, nomeActor, nomeNodo)


Configura (rinomina) un nodo non configurato
Distruzione di un canale comunicativo
destroyActor (nomeActor, todoMode)

Distruzione di un actor
Ogni azione
scrive / cancella
una tupla in tutte le KB
declareNode (n1, 192.168.70.39)
declareNode (n2, 192.168.70.40)
declareFactory (counter,d:\bundles\b1.jar)
MasterSupport
declareFactory (gui,d:\bundles\b2.jar)
deployActor(counter, c1, n1)
deployActor(gui, g1, n2)
Se entrambi gli actor
installBundle
sono sullo stesso
deployActor(counter,
c1)
nodo, supporto
javaBeans
remoteReactInteraction (c1, g1, inc)
c1
c1_ref g1
Nodo
n1
Nodo
n2
n1
IOsgiServer_192.168.70.39_127.0.0.1).
n2
IOsgiServer_192.168.70.40_127.0.0.1).
Master
DEMO 1:
n1: g1,c1
n2: g2
g1,g2->c1
c1->g2
Tolleranza ai guasti: OBIETTIVI

Failure di un nodo non master:




Occorre rimuovere l’entry dal registry
Occorre rimuovere eventuali riferimenti remoti
inconsistenti
Occorre aggiornare la teoria
Failure del nodo 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
Fallimento di un nodo


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:
c1 fails
Failure del Master



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, quando entra nel sistema:


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
 Il
Il sistema
caso peggiore
è quando il master modifica lo stato (i.e.
risponde
bene
i riferimenti
remoti)
anche durante
remoteReactInteraction:
c1 -> g2 (“updateVal”)
DEMO 3:
iles.
TTR
del
master!!! Master
Nodo di c1 master exit
Nodo di g2
Agg. teoria
Agg. teoria
Divulgazione teoria
aggiunto riferimento a g2
destroyActor (actorName, todo)



Il master elimina tutti i riferimenti remoti
Il master distrugge actorName aspettando
che finisca di lavorare
Se todo==true

All’inizio il master scrive

caso
Il nodo “todo” comincia a monitorare il
master.
todo:destroyActor(actorName) in un nodo a

Se si accorge che il master è fallito senza
cancellare la clausola todo, si incarica di ripetere
destroyActor

Al termine, cancella la clausola todo
TEST

CounterActor




GuiActor



Input: “updateVal (int n)” -> visualizza n
Output: “inc” : se viene premuto il tasto inc
DEMO 4:
c1 lazy
Master fails
MasterSupport


Input: “inc” -> incrementa un contatore
Output: “updateVal (int newVal) “
Anche versione lazy, fail
Realizzato anche in versione fail (fallisce durante destroyActor)
Prove

Eseguite prove su 3 macchine in rete locale (LAB2)
Lenta la reazione del supporto in caso di guasti (oltre 10 sec)
Sviluppi futuri



Progetto di un registry RMI ad alta
disponibilità e affidabilità…
Messaggi master – nodo non bloccanti…
Segnali tra gli actor con diverse
semantiche (asincroni,…)