Sistemas Distribuidos Basados en Coordinación

Sistemas Distribuidos
Basados en
Coordinación
Prof. M. Curiel
Basada en láminas y libro de
Tanenbaum y Van Steem
Contenido
z
z
z
z
z
z
z
Introducción a los modelos de Coordinación
Arquitecturas
Procesos
Comunicación
Asignación de Nombres
Sincronización
Consistencia y Replicación
Introducción a los Modelos de
Coordinación
z
Cómputo y Coordinacion:
z
z
Cómputo: la parte de cómputo de un SD está
formada por procesos, y cada proceso se ocupa
de efectuar una actividad computacional
específica la cual en principio es realizada
independientemente de otros procesos.
Coordinación: maneja la comunicación y
cooperación entre procesos.
1
Introducción a los Modelos de
Coordinación
z
En SD basados en Coordinación, el
enfoque recae en cómo ocurre la
Coordinación entre procesos.
Taxonomía de Modelos de
Coordinación
Temporal
Coupled
Decoupled
Coupled
Referential
Decoupled
Direct
Mailbox
Meeting
oriented
Generative
communication
Cabri y Colaboradores (2000), para agentes móviles
Taxonomía
z
z
Acoplamiento referencial: tiene que ver con
la forma de hacer referencia explícita en la
comunicación. Por ejemplo, un proceso
puede comunicarse con otro sólo si conoce
su nombre o identificador.
Acoplamiento temporal: se refiere a que los
procesos que se comunican deben estar
funcionando.
2
Taxonomía
Coupled
Coupled
Referential
Decoupled
Temporal
Decoupled
Direct
Mailbox
Meeting
oriented
Generative
communication
z
Taxonomía
Coupled
Coupled
Referential
Decoupled
Temporal
Decoupled
Direct
Mailbox
Meeting
oriented
Generative
communication
Taxonomía
z
Coordinación directa:
los procesos deben
estar funcionando y se
conocen.
Coordinación de Buzon de
Correo: no se requiere que
los procesos que se están
comunicando funcionen al
mismo tiempo para que
funcione la comunicación.
Ésta ocurre colocando los
mensajes en un buzón de
correo (posiblemente
compartido).
En la comunicación es
necesario referirse al buzón
de correo que mantendrá
los mensajes a ser
intercambiados.
Coordinación orientada a
reunión: los procesos no se
conocen entre sí. Existe un
concepto de reunión en la
cual los procesos se
agrupan temporalmente
para coordinar sus
actividades. Según este
modelo los procesos sí
deben estarse ejecutando
al mismo tiempo.
Un tipo de sistemas de
publicación/suscripción
caen dentro de esta
categoría.
z
Temporal
Coupled
Decoupled
Coupled
Referential
Decoupled
z
Direct
Mailbox
Meeting
oriented
Generative
communication
3
Taxonomía
z
z
En los sistemas de publicación y suscripción
los procesos pueden suscribirse a mensajes
que contienen información sobre temas
específicos, en tanto que otros procesos
producen o publican tales mensajes.
La mayoría de tales sistemas requiere que
los procesos que se están comunicando
estén activos al mismo tiempo.
z
Taxonomía
Coupled
Temporal
Decoupled
z
Coupled
Referential
Decoupled
Direct
Mailbox
Meeting
oriented
Generative
communication
z
Comunicación Generativa:
(Linda) un conjunto de
procesos independientes
utilizan un espacio de datos
persistente, compartido,
conformado por tuplas.
Las tuplas son registros de
datos etiquetados
compuestos por varios
campos de entrada.
Las etiquetas sirven para
distinguir entre tuplas que
representan diferentes
clases de información.
Taxonomía
z
z
Estos espacios de datos compartidos
implementan un mecanismo de búsqueda
asociativa de tuplas: cuando un proceso
desea extraer una tupla del espacio de
datos, especifíca los valores de aquellos
campos en los que está interesado.
Cualquier tupla que coincida con la
especificación se retira del espacio de
datos y se transfiere al proceso.
4
Taxonomía
z
z
Si no se encuentra ninguna
coincidencia el proceso puede elegir
bloquearse hasta que se encuentra
alguna coincidencia.
Estos espacios de comunicación
generativa se consideran también con
frecuencia como sistemas de
publicación/suscripción.
Arquitecturas
z
z
Una característica importante de estos
sistemas (P/S) es que la comunicación
ocurre describiendo las características de los
elementos de datos que se van a
intercambiar. Los elementos de datos no son
identificados explícitamente por remitentes y
destinatarios.
Los elementos de datos se describen por
medio de una serie de atributos.
Arquitectura General
z
z
z
Un elemento de datos está publicado cuando
se coloca a disposición de otros procesos para
su lectura.
Mediante una subscripción, el subscriptor
informa al sistema las características de
aquellos elementos de datos que son de su
interés.
Tal descripción se compone de los pares
(atributo, valor) posiblemente combinados con
pares (atributo, rango). Las descripciones a
veces pueden darse utilizando varias clases de
predicados formulados sobre los atributos.
5
Arquitectura General
Qué pasa cuando las suscripciones tienen
que compararse con elementos de datos y
se da la coincidencia?
z
1. El middleware puede remitir los datos a su
grupo de suscriptores (cuando el middleware no
ofrece almacenamiento de datos, se trata de un
sistema referencialmente desacoplado pero
temporalmente acoplado)
Arquitectura General
2. Se remite una notificación, después de lo
cual los suscriptores pueden realizar la
operación read para leer el elemento de
datos. El middleware necesariamente tiene
que guardar el elemento de datos. También
es posible anexar un contrato a un elemento
de datos, de forma que cuando expire dicho
elemento se elimine automáticamente.
Publisher
Data item
Subscriber
Subscriber
Read/Delivery
Subscription
Notification
Publish/subscribe middleware
Match
6
Arquitectura General
z
z
z
z
Se supone que cada elemento de datos tiene un
vector asociado <(a1,v1),(a2,v2),(a3,v3)....> de
pares (atributo, valor).
En muchos sistemas basados en coordinación lo
que se publica son eventos.
En este tipo de sistemas es importante cómo se
implemente la coincidencia de suscripciones.
Los métodos de coordinación proporcionan un gran
potencial para construir SD a muy gran escala
debido al fuerte desacoplamiento de los procesos.
Arquitecturas Tradicionales
Solución más simple: arquitectura
Cliente/Servidor centralizada: WebSphere de
IBM, implementaciones de JMS (Sun),
implementaciones de Jini y JavaSpaces.
z
Jini y JavaSpaces
z
z
z
Jini es un sistema distribuido que implementa
un modelo de coordinación de comunicación
generativa.
Está fuertemente relacionado con Java,
aunque muchos de sus principios se pueden
implementar en otros lenguajes.
Ofrece desacoplamiento temporal y
referencial de procesos mediante un sistema
de Coordinación llamado JavaSpaces
(derivado de Linda).
7
Jini y JavaSpaces
z
z
z
Un JavaSpace es un espacio de datos
compartido que guarda tuplas que representan
un conjunto de referencias a objetos Java. En
un sistema Jini pueden coexistir múltiples
JavaSpaces.
Las tuplas se guardan en forma serializada (se
empaqueta la tupla y sus campos)
Una tupla se coloca en un JavaSpace por medio
de una operación write, que empaqueta primero
la tupla antes de guardarla.
Jini y JavaSpaces
z
z
z
Cada vez que se invoca la operación write
en relación a una tupla, se guarda otra copia
de dicha tupla (instancia) en el JavaSpace.
Para leer una instancia de tupla, un proceso
proporciona otra tupla que utiliza como
plantilla (también es un conjunto de
referencias a objetos).
Sólo pueden leerse desde el JavaSpace
instancias de tupla del mismo tipo que la
plantilla.
A
Write A
B
Write B
T
Read T
C
Insert a
copy of A
B
A
Tuple instance
Look for
tuple that
matches T
Insert a
copy of B
B
Return C
(and optionally
remove it)
A
B
C
A JavaSpace
8
class public Tupla implements Entry {
public integer id, value;
public Tupla(Integer id, Integer value){this.id=id; this.value=value}
}
La siguiente plantilla:
Tupla template = new Tupla(null, new Integer(42))
equiparará la tupla:
Tupla item = new Tupla(newInteger(64)), new Integer(42))
Dos campos coinciden si ambos tienen una copia de la misma referencia o
si el campo en la tupla plantilla es NULL. Una instancia de tupla es igual a una
tupla plantilla si sus campos concuerdan.
Jini y JavaSpaces
z
z
z
Cuando se está haciendo una operación
read y se encuentra una coincidencia, se
devuelve una copia de la instancia de la
tupla al proceso que la está solicitando.
La operación take retira la tupla del
JavaSpace.
Ambas operaciones bloquean al invocador
hasta que se encuentra una tupla
coincidente. También existen variantes para:
especificar un tiempo máximo de bloqueo o
regresar de inmediato si no se encuentra
coincidencia.
Jini y JavaSpaces
z
z
Los procesos que usan JavaSpaces no
tienen que coexistir al mismo tiempo. Si el
JavaSpace se implementa mediante
almacenamiento persistente, un sistema
Jini completo puede “bajarse” y reiniciarse
más tarde sin que se pierda ninguna tupla.
Un servidor centralizado permite
suscripciones bastante elaboradas y facilita
la sincronización.
9
TIB/Rendezvous
z
z
Una solución al uso de servidores centrales
es diseminar de inmediato los elementos de
datos publicados a los suscriptores
apropiados mediante multitransmisión
(TIB/Rendezvous)
En este sistema un elemento de datos es un
mensaje etiquetado con una palabra clave
compuesta que describe su contenido, tal
como news.comp.os.books
TIB/Rendezvous
z
z
Un suscriptor proporciona (partes de) una
palabra clave o indica los mensajes que
desea recibir, tal como news.comp.*.books.
Se dice que estas palabras clave indican el
tema de un mensaje.
Para la implementación se utiliza con
frecuencia la multitransmisión en redes de
área local, aunque también puede utilizarse
comunicación punto-punto (si se sabe donde
reside un suscriptor)
TIB/Rendezvous
z
z
z
Cada servidor ejecutará un demonio rendezvous,
que se encarga de que los mensajes sean
enviados y entregados de acuerdo con el tema.
Siempre que se publica un mensaje, se
multitransmite a cada servidor de la red que
ejecuta un demonio rendezvous.
Los procesos suscritos a un tema transfieren su
suscripción a un demonio local. Éste construye
una tabla de entradas (proceso, tema)
10
TIB/Rendezvous
z
Siempre que llega un mensaje sobre un
tema S, el demonio revisa en su tabla en
busca de suscriptores locales y remite el
mensaje a cada uno. Si no existen
suscriptores para S, el mensaje se
desecha.
Publ. on A
Subs. to A
Subj: A
Subs. to A
Publ. on B
Subs. to A
Subs. to B
Subs. to B
Subj: B
RV lib
RV lib
RV lib
RV lib
RV lib
RV
daemon
RV
daemon
RV
daemon
RV
daemon
RV
daemon
Network
Multicast message
on A to subscribers
Multicast message on B to subscribers
Arquitecturas Punto-a-Punto
z
z
Servidor central Æ no es escalable
Model TIB/R Æ la multitransmisión requiere
de medidas especiales para ir mas allá de
una red de área local.
11
Arquitecturas Punto a Punto
z
z
Son sistemas de publicación/suscripción en
los cuales los eventos que se publican son
re-dirigidos sólo a los nodos que se han
suscrito previamente a dicho evento.
Las suscripciones pueden variar desde la
especificación de un simple atributo o evento
hasta la especificación de un rango de
valores
Ejemplo: Sub-2-Sub2 (Sistema de
P/S basado en Conversación)
z
z
z
Voulgaris et all (2004)
Los elementos de datos pueden describirse por
medio de N atributos a1, ...aN cuyo valor puede se
un entero, flotante, enumeraciones, booleanos y
cadenas.
Una suscripción s adopta la forma de una tupla de
pares (atributo, valor/rango) tales como:
s =< a1 → 3.0, a4 → [0.0,0.5) >
Ejemplo: Sub-2-Sub
z
z
Cada suscripción si en realidad especifica un
subconjunto Si en el espacio de N-dimensiones de
números punto flotante. A tal subconjunto se le
llama también hiperespacio.
Los nodos regularmente intercambian
suscripciones por medio de un protocolo
epidémico. Si dos nodos i, j advierten que sus
respectivas suscripciones se entrecruzan, es decir:
S
ij
≡
S
i
∩
S
j
≠ O
registrarán este hecho y mantendrán referencias entre ellos.
12
Ejemplo Sub-2-Sub
z
≡ S ij ∩ S k ≠ 0
Si descubren un tercer
nodo k con:
ijk
S
los tres se conectarán entre sí, de modo que un elemento de datos
de interés para los tres pueda diseminarse con eficiencia.
En esencia lo que se busca es agrupar los nodos en M grupos diferentes, de
modo que los nodos i y j pertenezcan a un mismo grupo si sus suscripciones
se
entrecruzan. Los nodos ubicados en el mismo grupo deberán organizarse
en una red sobre-puesta que permitirá la diseminación eficiente de un
elemento de datos en el hiperespacio asociado con dicho grupo.
Bidirectional ring
12
10
Node IDs
8
6
4
2
5
10
15
20
25
Group of four nodes for interval [16.5, 21.0]
30
35
Attribute value
Los nodos 3,4, 7 y 10 se agrupan para representar el intervalo [16.5, 21.0].
Cualquier elemento de datos con un valor presente en ese intervalo deberá
diseminarse sólo a esos 4 nodos.
13
Ejemplo Sub-2-Sub
z
z
Los nodos no sólo mantienen la información a los
otros nodos en su anillo.
Para descubrir nuevos nodos (que pudieran estar
interesados en los mismos datos) los autores del
sistema desarrollaron cyclon, un protocolo
epidémico mediante el cual un nodo mantiene una
lista de vecinos seleccionados aleatoriamente
(vista), y regularmente intercambia vistas con otros
pares (conversación). Tal intercambio permitirá
que un nodo aprenda sobre otros nodos del
sistema.
Ejemplo Sub-2-Sub
z
Se manejan tres tipos diferentes de enlaces:
z
z
z
Enlaces aleatorios: enlaces a pares seleccionados
aleatoriamente, se necesitan para descubrir nuevos nodos y
para mantener la red conectada.
Enlaces de intereses solapados: reflejan similitudes entre
suscripciones y se usan para enviar eventos publicados a
otros pares interesados. Se usa un protocolo epidémico
basado en proximidad (vicinity)
Enlaces de anillos: Hay un orden entre los nodos que tienen
intereses comunes. Después de un intercambio de
información (nodo i, nodo j) el nodo i ordena todos los
nodos en el conjunto por sus identificadores y selecciona el
que tenga el identificador más bajo
14
Movilidad y Coordinación
z
Cómo combinar soluciones de publicación
y suscripción con la movilidad de los
nodos?
z
z
Cómo garantizar que los mensajes
publicados no sean entregados más de una
vez a un suscriptor que cambia de puntos de
acceso.
Sol: que los suscriptores no pierdan de vista
los mensajes que ya recibieron y desechen
los duplicados. Soluciones más complicadas
se basan en enrutadores o direccionadores
que no pierden de vista qué mensajes fueron
enviados a cuáles suscriptores.
Lime
z
z
z
En el caso de comunicación generativa, se han
propuesto varias soluciones para operar un espacio
de datos compartido donde todos/algunos de los
nodos son móviles. Un ejemplo de estos sistemas
es Lime.
Cada proceso tiene su propio espacio de datos
asociado, pero cuando los procesos están
próximos entre sí (conectados), sus espacios de
datos se vuelven compartidos.
Conectados:
z
z
Teoría: existe una ruta en una red subyacente conjunta
que permite que dos procesos intercambien datos.
Práctica: procesos en el mismo servidor o que sus
servidores pueden comunicarse mediante un enlace
inalambrico.
Lime
Transient, shared dataspace
Process
Process
Process
Local
dataspace
Local
dataspace
Local
dataspace
Wireless link
15
Lime
z
z
z
Si hay un espacio de datos compartidos de forma
transitoria los procesos pueden intercambiar tuplas
El espacio de datos compartidos, está distribuido,
pero esto es transparente para los procesos
participantes.
Lime también permite romper con esta
transparencia y especificar para qué proceso va el
mensaje. Las operaciones read y take pueden tener
un parámetro adicional que especifique de qué
proceso se espera una tupla.
Comunicación en Sistemas de
Publicación/Suscripción
z
z
En la mayoría de estos sistemas la
comunicación es relativamente simple, por
ejemplo en casi todos los sistemas basados
en Java, toda la comunicación se realiza
mediante invocaciones a métodos remotos.
Un problema: los datos publicados deben
llegar sólo a los suscriptores. Una solución
puede ser la organización de los nodos
presentes en un sistema punto-punto,
después de lo cual la diseminación ocurre por
grupo.
Enrutamiento basado en
contenido
z
z
Se supone que el sistema está construido
encima de una red punto-punto en la cual
los mensajes son explícitamente
direccionados entre los nodos.
Es crucial que los enrutadores sean
capaces de tomar decisiones, utilizando el
contenido del mensaje. En otras
palabras...cada mensaje porta una
descripción de su contenido. Esta
descripción puede utilizarse para
interrumpir rutas que no conducen a
receptores interesados.
16
Enrutamiento basado en
contenido
z
z
Carzaniga y colaboradores proponen un
esquema de enrutamiento donde los
servidores se conectan en forma de árbol.
En el dibujo, los servidores están en los
extremos del árbol y los nodos
intermedios son los enrutadores.
1
1
3 1
2
R1
5
R2
3
3
3
4
Enrutamiento basado en
contenido
z
z
Sol 1 (extrema) enviar cada mensaje publicado a
cada servidor y dejar que éste verifique si cualquiera
de sus clientes se había suscrito al tema de dicho
mensaje (TIB/Rendevouz)
Sol 2 (extrema) cada servidor transmita sus
suscripciones a todos los demás servidores (y
enrutadores). Cada servidor o enrutador tiene una
lista de pares (tema, destino). Cuando el mensaje
llega a un enrutador, éste puede utilizar la lista para
decidir las rutas que el mensaje deberá seguir.
17
Enrutamiento basado en
contenido
z
Podemos afinar las capacidades de los
enrutadores para decidir a donde van los
mensajes. Cada servidor transmite su
suscripción a través de la red de modo que
los enrutadores puedan componer filtros de
almacenamiento.
1
Tabla o filtro de Enrutamiento del enrutador
R2
1
Interfaz
Filtro
Hacia el
a ∈ [0,3]
Nodo 3
Hacia el
a ∈ [2 ,5 ]
nodo 4
Hacia el
No
a ∈ [2,5]
enrutador especifica
r1
-do
3 1
2
a ∈ [0,3]
R1
5 a∈ [0,3]∪ [2,5] = [0,5]
R2
3
3
3
4
a ∈[0,3]
a ∈[2,5]
z
z
Cuando un nodo abandone el sistema , o
ya no esté interesado en mensajes
específicos deberá cancelar su
suscripción y transmitir esa información
a todos los enrutadores.
Como producto de esta cancelación se
pueden ajustar varios filtros de
enrutamiento.
18
Asignación de Nombres
z
z
Hasta ahora hemos trabajado bajo la
suposición que todo dato publicado tiene un
vector asociado de N pares (atributo, valor)
y que los procesos pueden suscribirse a
elementos de datos especificando
predicados sobre estos valores de atributos.
Existen sistemas en los cuales los
elementos de datos no están etiquetados
con valores para todos los atributos.
Asignación de Nombres
z
z
En particular veremos que un elemento de
datos tiene sólo un par asociado (atributo,
valor), en cuyo caso también se conoce como
evento.
El soporte a suscripción de eventos y,
especialmente, a eventos compuestos inspira
en gran medida el análisis sobre temas de
asignación de nombres en los sistemas de
publicación/suscripción.
Asignación de Nombres
z
Cuando se trabaja con eventos tenemos que
tomar en cuenta:
z
z
Cómo componer los eventos (describir las
composiciones) (Pietzuch y colaboradores 2003
propusieron una estructura general para la
composición de eventos en SD)
Cómo recopilar eventos (primitivos) y
posteriormente equiparalos con suscripciones.
19
Descripción de Eventos Compuestos
Evento
Descripción
S1
Notifica cuando el cuarto R4.2 está desocupado
(simple)
S2
Notifica cuando el cuarto R4.2 está desocupado y la
puerta está abierta (compuesto)
S3
Notifica cuando el cuarto R4.2 está desocupado
durante 10 segundos y la puerta está abierta
(compuesto + requiere de tiempo)
S4
Notifica cuando la temperatura del cuarto sube más de
un grado por cada 30 minutos (medir temperatura)
S5
Notifica cada vez que la temperatura promedio del
cuarto se mantuvo por mas de 20 grados en la última
½ hora (calcular promedio)
Descripción de Eventos
Compuestos
z
z
La idea básica es habilitar la formulación de
suscripciones en función de eventos
primitivos.
Pietzuch y colaboradores, proponen un
lenguaje basado en una máquina de estado
finito ampliada. Las extensiones permiten
especificar tiempos de permanencia en
estados, así como la generación de eventos
nuevos (compuestos)
Room unoccupied
Door is locked
t=10s
(start)
Room is occupied
Door is unlocked
(generate event)
Máquina de Estado Finito para la suscripción S3.
Se hace una transición al estado final si la puerta no se cierra
y el salón permanecen vacíos por 10 segs.
20
Descripción de Eventos
Compuestos
z
z
Las FSM (Finite State Machines) se pueden
descomponer en otras máquinas más
pequeñas que se comunican pasándose
eventos entre sí.
Ejem: se desea apagar las luces de la
habitación R4.2 después de 2 segundos de
estar seguros que no hay nadie en ella (y la
puerta está cerrada)
(generate event)
Room unoccupied
Door is locked
(start)
t=10s
Room is occupied
(start)
Door is unlocked
t=2s
Switch lights off
Dos máquinas de Estado Finito Acopladas
Descripción de Eventos
compuestos
z
z
Las FSM pueden implementarse como
procesos aparte en el sistema distribuido. La
segunda FSM se suscribirá al evento
compuesto que se deriva de la primera.
Los eventos son mensajes enviados a través
dela red a procesos suscritos a ellos.
21
Sincronización
z
z
Es simple cuando se utiliza un solo servidor.
Los procesos pueden simplemente
bloquearse hasta que las tuplas estén
disponibles
Todo se complica cuando el espacio de
datos compartido se replica y distribuye a
través de múltiples servidores.
Consistencia y Replicación:
Métodos Estáticos
z
z
Ejem: JavaSpace. Se desea replicar y
distribuir el conjunto de tuplas en varias
máquinas.
Consideraciones generales:
z
z
Cómo realizar la asociación
(publicación/suscripciones) sin necesidad de
realizar una búsqueda masiva?
Como distribuir instancias de tuplas entre
máquinas y localizarlas después?
Consistencia y Replicación:
Métodos Estáticos
Dividir el espacio de tuplas en sub-espacios, cada
una de cuyas tuplas es del mismo tipo. Como las
tuplas entran por teclado es posible determinar a
tiempo de compilación en qué subespacio opera
una invocación a read, take o write.
z Cada sub-espacio puede organizarse mediante una
tabla de hash, utilizando uno de los campos de las
tuplas.
z Las tuplas de un mismo sub-espacio pueden
replicarse
enwrite
diferentes
máquinas.
Una invocación
a read,
o take se ejecuta
calculando la función de
z
hash del i-ésimo campo para determinar la posición de la tabla donde pertenece
la instancia de la tupla. Si el campo i-ésimo es NULL, no puede aplicar una función de
hash y es necesario hacer una búsqueda completa.
22
Consistencia y Replicación:
Métodos Estáticos
z
z
z
Si se dispone de una transmisión confiable
se pueden replicar todos los sub-espacios en
todas las máquinas.
Cuando se realiza una operación write la
nueva instancia de tupla se transmite e
ingresa en el sub-espacio adecuado para
cada máquina
Read o take realiza la búsqueda en el
subespacio local. Para la consumación
exitosa de un take, es necesario eliminar la
tupla de todas las máquinas.
Tuple broadcast
Network
Process doing
a write broadcasts
(a)
Process doing a take
examines local JavaSpace
Tuple delete
Subspaces
Network
(b)
Consistencia y Replicación:
Métodos Estáticos
z
z
Este diseño es simple pero no escala bien a medida
que aumenta el número de instancias de tupla o el
tamaño de la red.
El diseño inverso es realizar los write localmente,
guardando la instancia de la tupla sólo en la
máquina que la generó. Para realizar un read o take
el proceso debe transmitir la tupla-plantilla. Cada
receptor revisa para ver si tiene una tupla igual y
contesta afirmativamente si la tiene. Si la instancia
de la tupla no está presente o si no se recibe el
mensaje en la máquina que tiene la tupla, la
máquina solicitante retransmite (ad infinitum) hasta
que obtiene una respuesta satisfactoria.
23
Process doing a write
inserts tuple into local JavaSpace
Network
(a)
Process doing a read
broadcasts template
Template broadcast
Network
(b)
Consistencia y Replicación:
Métodos Estáticos
z
Los dos métodos anteriores pueden combinarse
para producir un sistema con replicación parcial:
z
z
z
Suponga que todas las máquinas forman una cuadrícula
rectangular.
Cuando el proceso A desea realizar una una operación
write transmite (o envía un mensaje punto-punto) la tupla
a todas las máquinas ubicadas en su fila de la cuadrícula.
Cuando el proceso B desea leer o tomar una instancia de
la tupla, transmite la tupla plantilla a todas las máquinas de
su columna. Debido a la geometría siempre habrá
exactamente una máquina que ve tanto la instancia de
tupla como la tupla plantilla (C)
A
C
A broadcasts
tuple to these
machines
B
B broadcasts template
to these machines
24
Consistencia y Replicación:
Métodos Estáticos
z
z
Todas las implementaciones presentadas tienen
problemas de escalabilidad (la mayoría se basa en
multitransmisión)
Las implementaciones de espacios de tuplas en
redes de área amplia no existen. En el mejor de los
casos pueden existir varios espacios de tuplas
diferentes, y cada espacio se implementa en un
servidor o en una red de área local.
Replicación Dinámica
z
z
z
Ejem: GigaSpaces
Se construyó encima de JavaSpaces.
En este sistema la distribución y replicación
de tuplas se realizan por dos razones:
desempeño y disponibilidad. Se utilizan
estrategias diferentes en ambos casos. Por
esta razón se soportan varias políticas de
replicación.
Replicación Dinámica
z
z
z
Se ofrecen las llamadas read, write, take, al
igual que con JavaSpaces.
Cada una de estas llamadas es captada por
un manejador de invocaciones local que
busca la política a seguirse para la
invocación específica.
Se selecciona una política basada en el tipo
y contenido de la tupla que se transfiere
como parte de la invcación.
25
Replicación Dinámica
z
z
z
El manejador de invocación usa plantillas para
identificar los diferentes tipos de tuplas.
Posteriormente se invoca al gestor de
distribución, el cual implemnta la misma interfaz
pero ahora de acuerdo con una política de
replicación específica.
Ejem. Maestro-Esclavo. Todos tienen la tupla,
un read puede ser local. Un write puede requerir
que el gestor de distribución remita el nodo al
maestro y espere un acuse de recibo antes de
realizar la operación localmente.
Application
Dataspace
slice
Distribution
Distribution
Distribution
manager
manager
manager
Invocation
handler
Policy
table
Local OS
To network
Replicación Dinámica
z
z
En GigaSpace la gestión de replicación es
automática, i.e. en lugar de permitir que el
desarrollador de aplicaciones decida qué política
es la mejor, el sistema monitorea los patrones de
acceso y comportamiento para posteriormente
adoptar las políticas que se requieran.
Con este objetivo GigaSpace continuamente
mide el ancho de banda consumido, la latencia
de la red y el uso de la memoria , coloca las
tuplas en diferentes nodos y elige la manera más
apropiada de mantener las réplicas consistentes.
26
Resumen
z
Los sistemas distribuidos basados en
coordinación están enfocados en el
desacoplamiento referencial de los
procesos, i.e. éstos no tienen que referirse
explícitamente entre sí para habilitar la
comunicación. También es posible tener
desacoplamiento temporal, de modo que los
procesos no tienen que estar activos para
comunicarse.
Resumen
z
z
Un grupo importante de estos sistemas está
formado por aquellos que siguen el paradigma de
publicación/suscripción (TIB/Rendevouz) En este
modelo los mensajes no portan la dirección de sus
receptores sino que en cambio son direccionados
por tema.
Un poco más complejos son aquellos sistemas
donde los suscriptores pueden formar predicados
sobre los atributos de los elementos de datos
publicados. El enrutamiento en estos sistemas se
hace basado en contenido.
Resumen
z
z
Otro grupo importante utiliza comunicación
generativa, la cual ocurre por un espacio
compartido de tuplas.
Los principios de los SD se aplican a
sistemas basados en coordinación. El
almacenamiento en cache y la replicación
desempeñan un rol menos prominente en
las replicaciones actuales
27