Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Introducción a los Modelos de Coordinación

No description
by

Roberto Arteaga

on 17 August 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Introducción a los Modelos de Coordinación

INTRODUCCIÓN A LOS MODELOS DE COORDINACIÓN
Es fundamental establecer una clara separación entre cómputo y coordinación. Si vemos a un sistema distribuido como un conjunto de procesos, entonces la parte de cómputo de un sistema distribuido está formada por los procesos, y cada proceso se ocupa en efectuar una actividad computacional específica la cual, en principio, es realizada independientemente de las actividades de otros procesos.
En este modelo, la parte de coordinación de un sistema distribuido maneja la comunicación y la cooperación entre procesos, forma el pegamento que aglutina las actividades realizadas por los procesos en un todo.
Cuando los procesos se acoplan temporal y referencialmente, la coordinación ocurre de una forma directa, conocida como coordinación directa. El acoplamiento referencial aparece por lo común en la forma de hacer referencia explícita en comunicación.
Un tipo diferente de comunicación ocurre cuando los procesos se desacoplan temporalmente, pero se acoplan referencialmente, lo cual se conoce como coordinación de buzón de correo. En cambio, la comunicación ocurre colocando mensajes en un buzón de correo.
La combinación de sistemas referencialmente desacoplados y temporalmente acoplados forman el grupo de modelos de coordinación orientada a la reunión. En otros términos, cuando un proceso desea coordinar sus actividades con otros procesos, no puede referirse directamente a otro proceso.
También se presenta otro mecanismo útil para implementar reuniones denominado sistemas de publicación y suscripción. En estos sistemas, los procesos pueden suscribirse a mensajes que contienen información sobre temas específicos, en tanto que otros procesos producen tales mensajes
.
La mayoría de los sistemas de publicación y suscripción requiere que los procesos que se están comunicando estén activos al mismo tiempo; por consiguiente, existe un acoplamiento temporal. Sin embargo, en caso contrario, los procesos que se están comunicando pueden permanecer anónimos.
El modelo de coordinación más ampliamente conocido es la combinación de procesos referencial y temporalmente desacoplados. La idea fundamental en comunicación generativa es que un conjunto de procesos independientes utilicen un espacio de datos persistentes compartidos de tuplas. Los procesos pueden poner cualquier tipo de registro en el espacio de datos compartidos (es decir, generan registros de comunicación). La etiqueta sólo se utiliza para distinguir entre las tuplas que representan diferentes clases de información.
ARQUITECTURAS
Un aspecto importante de los sistemas basados en coordinación es que la comunicación ocurre describiendo las características de los elementos de datos que se van a intercambiar.
Enfoque total
Supongamos en primer lugar que los elementos de datos están descritos por una serie de atributos y que un elemento de datos está publicado cuando se pone a la disposición de otros procesos para que sea leído. Con esta finalidad, se tiene que transferir una suscripción al middleware, la cual describe los elementos de datos en los que el suscriptor está interesado. Cuando se da la coincidencia, existen dos posibles escenarios.
En el primer caso, el middleware puede decidir remitir los datos publicados a su grupo actual de suscriptores, es decir, a los procesos que tengan una suscripción coincidente.
En el segundo caso, se espera que el atributo especificado adopte valores dentro de un rango especificado.
Arquitecturas tradicionales
La solución más simple para igualar elementos de datos a suscripciones es tener una arquitectura cliente-servidor centralizada. Ésta es una solución típica adoptada por muchos sistemas de publicación y suscripción, asimismo, implementaciones de los modelos de comunicación generativos más elaborados tales como Jini y JavaSpaces están basados principalmente en servidores centrales.
Ejemplo:
Jini, JavaSpaces y TIB/Rendezvous.
Jini es un sistema distribuido compuesto a partir de una mezcla de elementos diferentes pero relacionados. Está fuertemente relacionado con el lenguaje de programación Java, aunque muchos de sus principios pueden ser implementados igualmente bien en otros lenguajes. Jini proporciona un desacoplamiento temporal y referencial de procesos mediante un sistema de coordinación llamado JavaSpaces.
Un JavaSpace es un espacio de datos compartido que guarda tuplas que representan un conjunto de referencias a objetos Java.
Las tuplas se guardan en forma serializada, es decir, siempre que un proceso desea guardar una tupla, ésta primero se empaqueta, lo cual implica que todos sus campos también se empaquetan. Por consiguiente, cuando una tupla contiene dos campos diferentes que se refieren al mismo objeto, la tupla guardada en una implementación de JavaSpace mantendrá dos copias empaquetadas de dicho objeto.
Una tupla se pone en JavaSpace por medio de una operación write, la cual primero empaqueta la tupla antes de guardarla. Cada vez que la operación write es invocada en relación con una tupla, se guarda otra copia empaquetada de dicha tupla en el JavaSpace.
En los casos en que los elementos de datos son remitidos de inmediato a los suscriptores, generalmente el middleware no ofrecerá almacenamiento de datos. El almacenamiento es o explícitamente manejado por un servicio aparte, o es responsabilidad de los suscriptores. Esta situación es diferente cuando se envían notificaciones de modo que los suscriptores tengan que leer explícitamente los datos publicados. Necesariamente, el middleware tendrá que guardar elementos de datos.
Los procesos que utilizan JavaSpaces no tienen que coexistir al mismo tiempo. En realidad, si se implementa un JavaSpace mediante almacenamiento persistente, un sistema Jini completo puede venirse abajo y reiniciarse más tarde sin que se pierda ninguna tupla. Aunque Jini no lo soporta, deberá quedar claro que tener un servidor central permite que las suscripciones sean bastante elaboradas.

Una solución alternativa al uso de servidores centrales es diseminar de inmediato los elementos de datos publicados a los suscriptores apropiados mediante multitransmisión. Este principio se utiliza en TIB/Rendezvous. En este método, un elemento de datos es un mensaje etiquetado con una palabra clave compuesta que describe su contenido, tal como news.comp.os.books. Se dice que estas palabras clave indican el tema de un mensaje.
Para efectuar la implementación de TIB/Rendezvous, es fundamental el uso de transmisión común en redes de área local, aunque también utiliza medios de comunicación más eficientes cuando es posible. En una red de este tipo, cada servidor ejecutará un demonio rendezvous, el cual se encarga de que los mensajes sean enviados y entregados de acuerdo con su tema. Siempre que se publica un mensaje, es multitransmitido a cada servidor en la red que ejecuta un demonio rendezvous.
Los procesos suscritos a un tema transfieren su suscripción a su demonio local. Éste construye una tabla de entradas (proceso, tema), y siempre que llega un mensaje sobre un tema S, el demonio simplemente revisa su tabla en busca de suscriptores locales y remite el mensaje a cada uno. Si no existen suscriptores para S, el mensaje se desecha de inmediato.
Arquitecturas punto a punto
Las arquitecturas tradicionales seguidas por la mayoría de los sistemas basados en coordinación sufren de problemas de escalabilidad. Desde luego, tener un servidor central para equiparar las suscripciones con los datos publicados no permite crecer a más de unos cientos de clientes.
Se ha investigado mucho sobre la realización de sistemas basados en coordinación usando tecnología punto a punto. Este método también ha sido utilizado para correlacionar pares (atributo, valor) con identificadores. En estos casos, la equiparación se reduce a una búsqueda simple de un identificador, la cual puede ser implementada eficientemente en un sistema basado en DHT. Este método funciona bien con los sistemas de publicación y suscripción más convencionales, pero también para comunicación generativa.
MOVILIDAD Y COORDINACIÓN
Se plantea dos interrogantes:


Una solución práctica a estas dos interrogantes es permitir que los suscriptores no pierdan de vista los mensajes que ya recibieron y que simplemente desechen los duplicados. Soluciones alternativas pero más complicadas comprenden enrutadores o direccionadores que no pierdan de vista qué mensajes fueron enviados a cuáles suscriptores.
LIME
En el caso de comunicación generativa, se han propuesto varias soluciones para operar un espacio de datos compartidos donde todos o algunos delos 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 si de tal modo que están conectados, sus espacios de datos se vuelven compartidos. Pero, ¿Qué significa que están conectados?

TEÓRICA
PRÁCTICA
LIME-REACCIONES
Para controlar mejor la distribución de tuplas,
los espacios de datos pueden realizar lo que se conoce como reacciones.
Una reacción especifica una acción que debe ser ejecutada cuando se encuentra una tupla que concuerda con una plantilla dada en el espacio de datos local.

¿Cómo combinar soluciones de publicación y suscripción con la movilidad de nodos?
¿Cómo garantizar que los mensajes publicados no sean entregados más de una vez a un suscriptor que cambia de puntos de acceso?
PROCESOS
No existe nada realmente especial en cuanto a los procesos utilizados en sistemas de publicación y suscripción. En la mayoría de los casos, se tienen que utilizar mecanismos eficientes para buscar en un conjunto de datos potencialmente grande.
El problema principal es elaborar esquemas que funcionen bien en ambientes distribuidos.
COMUNICACIÓN EN SISTEMAS DE PUBLICACIÓN/SUSCRIPCIÓN
ENRUTAMIENTO BASADO EN EL CONTENIDO
Se supone que el sistema esta 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. Este contenido puede usarse para interrumpir rutas que no conducen a receptores interesados.
Carzaniga y colaboradores proponen un esquema de enrutamiento donde los servidores se conectan en forma de árbol.



ENRUTAMIENTO BASADO EN EL CONTENIDO- SOLUCIONES EXTREMAS
SOLUCION 1:
enviar cada mensaje publicado a
cada servidor y dejar que este verifique si cualquiera de sus cliente (aplicaciones) se había suscrito al tema de dicho mensaje.

SOLUCION 2:
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.

Consistencia y Replicación
La implementación distribuida de un sistema que soporta comunicación generativa con frecuencia requiere de atención especial. Ponemos énfasis en las posibles implementaciones de un servidor JavaSpace, es decir, una implementación mediante la cual el conjunto de instancias de tupla pueden ser distribuidas y replicadas en varias máquinas.
Métodos Estáticos
Una implementación distribuida eficiente debe resolver dos problemas:
1.
Cómo simular el direccionamiento asociativo sin la necesidad de realizar una búsqueda
masiva.
2.
Cómo distribuir instancias de tupla entre máquinas y localizarlas después.

La clave para ambos problemas es observar que cada tupla es una estructura de datos tecleados.
Ladivisión del espacio de tupla en subespacios, cada una de cuyas tuplas es del mismo tipo, simplifica la programación y hace posibles ciertas optimizaciones. Por ejemplo, como las tuplas se teclean, se vuelve posible determinar en tiempo de compilación en qué subespacio opera una invocación a write, read o take.

En una red de computadoras, la mejor alternativa depende de la arquitectura de comunicación.
Si se dispone de una transmisión confiable, un candidato serio es replicar por completo todos los subespacios en todas las máquinas.
Un JavaSpace puede ser replicado en todas las máquinas.
Las líneas de puntos muestran la división del JavaSpace en subespacios.
(a) Las tuplas se transmiten con la operación write. (b) Las lecturas son locales, pero la eliminación de una instancia cuando se invoca una operación take debe ser transmitida.

Este diseño es simple, pero puede no crecer bien a medida que el sistema crece en el número de instancias de tupla y tamaño de la red. Por ejemplo, implementar este esquema a través de una red de área amplia es prohibitivamente caro.
El diseño inverso es realizar varios write localmente, guardando la instancia de tupla sólo en la máquina que la generó
Para realizar una operación read o take, un proceso debe transmitir la tupla plantilla. Cada receptor revisa entonces para ver si tiene uno igual y contesta si lo tiene.
Si la instancia de tupla no está presente, o si no se recibe la transmisión en la máquina que tiene la tupla, la máquina solicitante retransmite la solicitud ad infinitum

JavaSpace no replicado.
(a) Se realiza una operación writelocalmente.
(b) Una operación read o take requiere que se transmita la tupla plantilla para localizar una instancia de tupla.

Replicación dinámica
En los sistemas basados en coordinación, en general, la replicación ha estado restringida a políticas estáticas para aplicaciones paralelas como las estudiadas aquí previamente. En aplicaciones comerciales, también se ven esquemas relativamente simples donde espacios de datos completos o, al contrario, partes estáticamente predefinidas de un conjunto de datos se someten a una sola política (GigaSpaces, 2005).
GigaSpace
GigaSpace (GSpace) es un sistema distribuido basado en coordinación y construido encima de JavaSpaces. En este sistema, la distribución y la replicación de tuplas se realizan por dos razones diferentes: mejorar el desempeño y la disponibilidad. Un elemento clave B A transmite la tupla a estas máquinaB transmite la plantilla a estas máquinas A C.

Transmisión parcial de tuplas y tuplas plantilla. en este método es la separación de intereses: las tuplas que deben ser replicadas por disponibilidad puede ser que requieran seguir una estrategia diferente a la de aquellos para los cuales el desempeño está en riesgo. Por esta razón, la arquitectura de GigaSpace soporta varias políticas de replicación de tal forma que diferentes tuplas puedan seguir políticas distintas.

El funcionamiento principal es relativamente simple. A cada aplicación se le ofrece una interfaz con una interfaz read, write y take, similar a lo que ofrece JavaSpaces. Sin embargo, cada invocación 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 plantilla que se transfiere como parte de la invocación.


El resultado de esta selección es una referencia a un gestor de distribución, el cual implementa la misma interfaz, pero ahora de acuerdo con una política de replicación específica.

Tolerancia a fallas
En sistemas basados en coordinación, donde los elementos de datos publicados se equiparan sólo con suscriptores vivos, la comunicación confiable desempeña un rol crucial. En este caso, la tolerancia a fallas se implementa con más frecuencia habilitando sistemas de multitransmisión confiablesque constituyen el fundamento del software de publicación y suscripción. Existen varios temas que se abordan de una forma general. En primer lugar, independientemente del modo en que ocurra el enrutamiento basado en el contenido, se establece un canal de multitransmisión confiable.
Tolerancia a fallas en espacios de datos compartidos
Como también señalan Tolksdorf y Rowstron (2000), en cuanto se tiene que incorporar tolerancia a fallas a espacios de datos compartidos, las soluciones a menudo se vuelven tan ineficientes que sólo son factibles las implementaciones centralizadas.
Una alternativa es utilizar una replicación más agresiva colocando copias de elementos de datos en diversas máquinas. Este método ha sido adoptado en GigaSpace, esencialmente desplegando los mismos mecanismos que utiliza para mejorar el desempeño mediante replicación. Con este objeto, cada nodo calcula su disponibilidad, la cual emplea luego para calcular la disponibilidad de un solo elemento de datos (replicado).
Full transcript