SISTEMAS DISTRIBUIDOS

Fecha: Noviembre 11, 2013 Tema: JGroups Soporte para Comunicacin a Grupos

1. Objetivos Describir los principios de funcionamiento de la comunicacin en grupos basada en el uso de JGroups. Establecer la relacin existente entre este mecanismo de comunicacin grupal y los sistemas distribuidos. 2. Introduccin JGroups es un conjunto de herramientas (toolkit) para la comunicacin confiable en grupo, escrito en Java. Es parte de la serie de herramientas de comunicacin grupal que emergieron de la Universidad de Cornell, basndose en los conceptos fundamentales desarrollados en ISIS, Horus y Ensemble. Actualmente es mantenido y desarrollado por la comunidad open source JGroups, parte de la comunidad JBoss.

Motivacin de Desarrollo Se busc la creacin de una tecnologa de soporte para aplicaciones confiables orientadas a objetos que presente este mismo paradigma. Se emple el acercamiento toolkit para lograr la confiabilidad, debido a la posibilidad de proveer un nmero de clases con diferentes niveles de abstraccin, que puedan corresponder a los variantes requerimientos de las aplicaciones (sin imponer un modelo especfico). Su primera versin empleaba los protocolos de comunicacin grupal provistos por Ensemble (escrito en C), representado una interfaz Java modelada para y en base a dicha herramienta. Se eligi aprovechar las caractersticas del lenguaje Java: la portabilidad al poder ejecutarse en distintas arquitecturas y la posibilidad de generar instancias en tiempo de ejecucin (aplicado, por ejemplo, para generar todo el stack de protocolos en runtime).

3. Marco Terico 1

Comunicacin Indirecta Comunicacin indirecta se define como la comunicacin establecida entre entidades en un sistema distribuido mediante un intermediario, sin acoplamiento directo entre la entidad que realiza el envo y el receptor (o receptores). La naturaleza precisa del intermediario vara en cada estrategia especfica de implementacin. Comunicacin en Grupo La comunicacin en grupo ofrece un servicio a travs del cual un mensaje es enviado a un grupo y dicho mensaje es entregado a todos sus miembros (comunicacin punto a multipunto). En esta accin, el emisor desconoce las identidades de los receptores. Los grupos son la abstraccin clave para este tipo de comunicacin y estn formados por una coleccin de procesos u objetos que persiguen un objetivo comn y cooperan activamente para alcanzarlo. Cada grupo est asociado a un nombre lgico. Los mensajes se destinan a dicho nombre y es un servicio de comunicacin en grupo el que se encarga de entregarlo a sus integrantes. La comunicacin en grupo representa una abstraccin sobre la comunicacin multicast y puede ser implementada sobre multicast IP o mecanismos equivalentes, aadiendo funcionalidades como administracin de membresa, deteccin de fallas y provisin de garantas de ordenamiento y confiabilidad. Con la inclusin de estas caractersticas, la comunicacin grupal es para multicast IP lo que TCP es para el servicio IP punto a punto. Es as que el paradigma de comunicacin grupal es un elemento importante para los sistemas distribuidos, permitiendo la provisin de aplicaciones confiables y de alta disponibilidad. reas clave de aplicacin incluyen: Diseminacin confiable de informacin a un nmero potencialmente grande de clientes. Soporte para aplicaciones colaborativas. Soporte para un conjunto de estrategias para tolerancia a fallos, incluida la actualizacin consistente de informacin replicada o la implementacin de servidores replicados altamente disponibles. Soporte para sistemas de monitoreo y administracin, incluyendo, por ejemplo, estrategias de balanceo de carga.

Grupos de Procesos y Grupos de Objetos La mayor parte del trabajo en servicios de grupo se enfoca en el concepto de grupos de procesos, lo que quiere decir que las entidades que se comunican son procesos. Los grupos de procesos son una manera viable de solucionar problemas de confiabilidad en sistemas distribuidos. La idea principal es la creacin redundante de componentes crticos para que puedan ser reemplazados al presentarse una falla (replicacin). De manera general, dichos servicios son relativamente de bajo nivel tomando en cuenta que: Mensajes son entregados a procesos y no se provee soporte adicional de despacho. Mensajes son tpicamente arrays no estructurados de bytes sin soporte para marshalling de tipos de datos complejos.

El nivel de servicio provisto por grupos de procesos es similar al de los sockets. En contraste, grupos de objetos proveen un mecanismo de computacin grupal de ms alto nivel. Un grupo de objetos es una coleccin de objetos (normalmente instancias de una misma clase) que procesan un mismo conjunto de invocaciones de manera concurrente, cada uno retornando una respuesta. Los objetos cliente no estn al tanto de la replicacin, invocando operaciones 2

en un nico objeto local que acta como un proxy para el grupo. El proxy utiliza un sistema de comunicacin en grupo para enviar las llamadas a los miembros del objeto grupo. Parmetros de objeto y resultados pasan por un proceso de marshalling (como en RMI). Pese al potencial de los grupos de objetos, los grupos de procesos todava son dominantes en trminos de uso. Por ejemplo, JGroups presenta un mecanismo de grupos de procesos (aunque no se apega estrictamente a la definicin al presentar ciertas particularidades). Mecanismos Clave Los mecanismos clave de la arquitectura subyacente de los distintos sistemas de comunicacin grupal son un servicio de membresa a grupos integrado a un servicio de multicast confiable. El objetivo del servicio de membresa es mantener a los miembros consistentemente informados acerca de cambios en la membresa actual (composicin actual) del grupo mediante la instalacin de vistas. El servicio de membresa debe mantener una lista actual de los integrantes activos y conectados. El resultado de este servicio es lo que se denomina vista. La composicin del grupo puede variar dinmicamente en base a solicitudes voluntarias de ingresar o abandonar el grupo, o a eventos accidentales como el colgamiento de un integrante. Las vistas instaladas consisten de una coleccin de miembros y representa la percepcin de la constitucin del grupo que es compartida por sus componentes. En otras palabras, debe existir un acuerdo entre los miembros sobre la composicin de la vista antes de que esta sea instalada. Tareas principales: o Proveer una interfaz para cambios en la membresa del grupo: el servicio provee operaciones para crear y destruir grupos, as como aadir o retirar a procesos de un grupo. En la mayora de sistemas, un nico proceso puede pertenecer a varios grupos al mismo tiempo. o Deteccin de fallas: el servicio monitorea a los miembros del grupo tanto para detectar fallas en el proceso en s, como para detectar elementos inalcanzables por errores de comunicacin (particin por error de red). El detector marca a los procesos como sospechosos o no sospechosos. o Notificacin a miembros de cambios en la composicin. o Ejecutar expansin de direcciones del grupo: cuando un proceso realiza un multicast de un mensaje provee el identificador del grupo, no la lista de procesos en l. El servicio de administracin de membresa expande al identificador en la composicin actual del conjunto para realizar la entrega. El servicio puede decidir consistentemente donde entregar un mensaje dado, aun cuando la membresa pueda estar cambiando durante la entrega. Adquirir estas propiedades requiere de lo que se conoce como comunicacin en grupo 3

con vista sncrona. Debe haber una sincronizacin de la informacin de vistas y una integracin con la entrega de mensajes: dos procesos que instalen el mismo par de vistas en el mismo orden, entregan el mismo conjunto de mensajes entre las instalaciones de estas vistas.

En el ejemplo del grfico, los servidores S1, S2 y S3 se unen al grupo formando la vista v1. Inmediatamente despus, S1 y S2 son particionados de S3. El servicio de administracin de membresa reacciona instalando dos vistas v2 y v3. Luego, el particionamiento desaparece y los nodos otra vez pueden formar una nica vista v4. Finalmente, el servidor S3 sufre un crash causando la instalacin de la vista v5, nicamente con los miembros sobrevivientes. La tarea del servicio de multicast confiable es permitir a los miembros del grupo comunicarse utilizando mensajes multicast. 4. JGroups

En terminologa ms comn, un miembro es un nodo y un grupo es un clster. Un nodo es un proceso que reside en algn host. Los nodos no estn restringidos a ejecutarse en un mismo host. JGroups es un conjunto de herramientas para comunicacin en grupo confiable. Procesos pueden unirse a un grupo, enviar mensajes a todos los miembros o a un nico miembro y recibir mensajes de otros integrantes del grupo. El sistema lleva un registro de los miembros de cada grupo y notifica el ingreso de nuevos miembros, as como el abandono u ejecucin errnea (crash) de alguno de ellos. Los grupos son identificados por su nombre y no tienen que ser creados explcitamente; cuando un proceso se integra a un grupo inexistente el grupo ser creado automticamente. Procesos pertenecientes a un grupo pueden encontrarse en el mismo host, dentro de la misma LAN o en una WAN. Un miembro puede pertenecer a mltiples grupos.

Arquitectura

*El diagrama de arquitectura mostrado en la parte derecha corresponde el diseo de las primeras versiones del toolkit, mientras el de la izquierda es ms actual. El diagrama de las primeras versiones refleja la integracin existente con la herramienta Ensemble y con otro toolkit denominado iBus, enfocado en la diseminacin confiable de mensajes bajo la filosofa publish-suscribe. El canal (JChannel) representa la interfaz ms primitiva para el desarrollo de aplicaciones, ofreciendo funcionalidad bsica de unin, abandono, envo y recepcin. Un proceso interacta con un grupo mediante un objeto canal, que opera como manejador del grupo. Para unirse a un grupo y enviar mensajes, un proceso debe crear un canal y conectarse a l empleando el nombre de grupo. Todos los canales con el mismo nombre forman un grupo. Los grupos solo existen conceptualmente. Cada canal tiene una direccin nica. El canal siempre conoce quienes son los otros miembros dentro del mismo grupo, una lista de direcciones de los miembros puede ser accedida desde cualquier canal. Dicha lista es lo que se conoce como vista. Un proceso puede seleccionar una direccin de la lista y enviarle un mensaje unicast (tambin a s mismo) o un mensaje multicast a todos los miembros de la vista actual (tambin incluyndose a s mismo). Cada vez que un proceso se une o abandona el grupo, o cuando se detecta un crash en un proceso, una nueva vista es enviada a todos los miembros restantes del grupo. Cuando se sospecha que un proceso miembro est cado, un mensaje de sospecha es recibido por todos los integrantes libres de falla. De esta manera, los canales reciben mensajes regulares, notificaciones de vista y de sospecha. Las propiedades del canal tpicamente se definen en un archivo XML, pero existe la opcin de realizar configuraciones a travs de strings simples, URIs, rboles DOM o incluso programticamente. Los canales son simples y primitivos, ofreciendo la funcionalidad bsica para la comunicacin en grupo habiendo sido diseados en base al modelo sencillo de sockets. De esta forma, una aplicacin puede hacer uso de solo un pequeo subconjunto de JGroups.

De igual manera, la interfaz de cierta forma minimalista es fcil de entender, el cliente necesita saber alrededor de cinco mtodos para poder crear y usar un canal. Proveen recepcin y envo asncrono de mensajes, de cierta forma similar a UDP. Esencialmente, el mtodo send() retorna inmediatamente cuando el mensaje es colocado en la red. Solicitudes conceptuales, o respuestas a solicitudes previas, son recibidas en orden indefinido, y la aplicacin debe encargarse de coincidir las respuestas con las solicitudes. Bloques de construccin (building blocks) Proveen APIs ms sofisticados sobre un canal. Los bloques de construccin crean y usan canales internamente, o requieren la especificacin de un canal ya existente al crearse un bloque de construccin. Las aplicaciones se comunican directamente con los bloques de construccin, no con el canal. Su propsito es ofrecer un mayor de nivel de abstraccin para la comunicacin grupal, evitndoles al desarrollador la escritura de cdigo tedioso y recurrente. Tambin pueden ser descritos como patrones de comunicacin que proveen estructuras y algoritmos comnmente encontrados en comunicacin grupal, en forma de clases Java. La interfaz del canal es lo suficientemente simple y pequea para ser trasladada sobre distintos stacks de protocolos de forma que estos patrones, al solo depender de una implementacin de la interfaz (abstracta) del canal, pueden ser usados en la mayora de instancias de comunicacin grupal. Ejemplo de building block: o MessageDispatcher Los canales son patrones simples para enviar y recibir mensajes asncronamente. Sin embargo, un nmero significativo de patrones de comunicacin requieren comunicacin sncrona. Por ejemplo, un emisor podra querer enviar un mensaje a un grupo y esperar por todas las respuestas. MessageDispatcher provee funcionalidad para lograr este objetivo realizando bloqueo hasta que un nmero especfico de respuestas haya sido receptado. Stack de protocolos, que implementa las propiedades especificadas para un canal dado.

El stack de protocolos contiene un nmero de capas en una lista bidireccional. Todos los mensajes enviados o recibidos a travs del canal deben pasar por todos los protocolos. Cada capa puede modificar, reordenar, pasar o descartar el mensaje, o aadirle un encabezado. Un mensaje consiste en un campo remitente y destinatario, los cuales son objetos que denotan las direcciones tanto de origen como de destino. Si la direccin de destino es nula, el mensaje es enviado a todos los miembros del grupo. Los campos adicionales son el payload (byte buffer), el cual es usado para llevar informacin en el mensaje, puede contener, por ejemplo, un objeto serializado; y un header list que es usado por las capas del protocolo para aadir informacin perteneciente a su funcionalidad en el mensaje. Los header permiten adjuntar informacin a un mensaje sin alterarlo. Un canal tiene una referencia hacia un objeto de stack de protocolos, el cual es usado para enviar y recibir mensajes. Los datos son enviados a travs del stack en forma de eventos, un evento tiene un flag de tipo y un argumento. Cuando un mensaje es enviado al stack por el canal, este es envuelto en un evento, etiquetado como mensaje y enviado como argumento. La capa del fondo desenvuelve el mensaje y lo pone en la red, cuando se recibe se envuelve nuevamente y se pasa al stack. Hay que tener claro que los mensajes se intercambian entre diferentes stacks, mientras que los eventos viajan a travs de las capas de un protocolo. La composicin del stack de protocolos es determinada por el creador del canal. Un archivo XML define los protocolos a usarse y los parmetros correspondientes. La caracterstica principal de JGroups es justamente el stack de protocolos y la flexibilidad de la configuracin resultante. Las aplicaciones pueden elegir las caractersticas que les gustara en un clster simplemente editando el archivo XML mencionado. Por ejemplo, una aplicacin puede aadir compresin, simplemente aadiendo el protocolo COMPRESS a la configuracin. O puede eliminar la fragmentacin debido a que sus mensajes sern siempre ms pequeos que 65K (sobre UDP), o debido a que utiliza TCP para el transporte. Otra aplicacin podra aadir encriptacin y autenticacin, por lo que los mensajes estn cifrados y slo los nodos que presenten un certificado X.509 vlido pueden unirse al clster. Las aplicaciones son libres de escribir sus propios protocolos (o ampliar uno ya existente), y aadirlos a la configuracin. Puede ser til, por ejemplo, para aadir un protocolo que realiza un seguimiento de todos los mensajes enviados y recibidos a travs de un clster, para auditora o con fines estadsticos. Los protocolos usados por JGroups se pueden dividir en las siguientes categoras: Transporte: envo y recepcin de mensajes. UDP utiliza IP multicasting y/o datagramas UDP. TCP utiliza conexiones TCP. Descubrimiento (Discovery): descubrimiento inicial de nodos. Fusin (Merging): despus que una particin de red se recupera, esto une los subclusters de nuevo en uno. Deteccin de fallos: seguimiento de los nodos del clster y notificaciones de accidentes potenciales o errores. Entrega fiable: se asegura de que un mensaje no se pierde, se reciba slo una vez, y en el orden en el que un remitente lo envi. Esto se hace a travs de la asignacin de nmeros de secuencia a cada mensaje y a travs de la retransmisin en caso de un mensaje perdido. Estabilidad: los nodos tienen que guardar en su buffer todos los mensajes (para su posible retransmisin). El protocolo de estabilidad se asegura de que peridicamente (o basado en el tamao acumulado) los mensajes que se han recibido por todos los nodos del clster se purguen para que puedan ser recopilados y desechados. 7

Membresa de grupo: seguimiento de los nodos de un clster, y notifica a la aplicacin cuando un nodo se une y o deja el clster (incluidos los accidentes). Control de flujo: se asegura de que el remitente no puede enviar mensajes ms rpido que los receptores pueden procesarlos, durante un tiempo. Esto es necesario para evitar situaciones out-of-memory. El control de flujo es una parte fundamental de la estabilidad. Fragmentacin: fragmentar mensajes de gran tamao en otros ms pequeos y la reconstruccin en los receptores. Transferencia de estado: se asegura de que el estado compartido de un grupo (por ejemplo, todas las sesiones HTTP) es transferido correctamente a un nuevo nodo. Compresin: comprime los mensajes y los descomprime en los receptores. Encriptacin: encripta mensajes. Autenticacin: evita que un nodo no autorizado se una a un grupo.

5. Ejemplo de Aplicacin Sistema de distribucin de tareas en un clster En este sistema las tareas se pueden colocar en el clster y son ejecutados por nodos de trabajo. Los nodos trabajadores (workers) pueden ser aadidos para agregar ms potencia de procesamiento, o ser retirados cuando no se tiene mucha carga. Adems, las tareas asignadas a los trabajadores que posteriormente dejan de funcionar o tienen errores son reasignadas automticamente a nodos activos. En este sistema descentralizado, cada nodo del clster puede ser a la vez un maestro (que enva tareas) y un esclavo (que ejecuta las tareas y devuelve los resultados). La idea es muy simple: se tiene un conjunto de nodos, y cada nodo puede enviar a ejecutar tareas en otro nodo del clster. As que cada nodo es un peer, en el sentido de que puede tanto enviar y manejar las tareas. En una aplicacin de la vida real, los clientes podran conectarse a cualquiera de los nodos, por ejemplo, a travs de TCP o RMI, y presentar tareas a ese nodo, que luego la distribuira a algn otro nodo (o la manejara por s mismo). Al enviar una tarea, se elige un nmero entero aleatorio que se asigna al rango de un nodo del clster. El rango (rank) es la posicin de un nodo en la vista, y como la vista es la misma en todos los nodos, el rango identifica al nodo de forma nica. La tarea es entonces enviada por multicast (EXECUTE) hacia el clster. Cada nodo aade una tarea a un hash map que contiene las tareas y las respectivas direcciones (JGroups) del nodo que las envi. Cada nodo compara el rango enviado con la tarea con su propio rango. Si no coincide, no se hace nada. Si coincide, el nodo necesita procesar la tarea. Lo hace y devuelve el resultado al remitente. Cuando el remitente recibe la respuesta (RESULT), enva un mensaje (multicast) REMOVE en el clster. Cuando REMOVE (T) es recibido, cada nodo elimina T dentro de su hash map. Si un nodo X se bloquea (crashes), o solo sale, es posible saber qu tareas fueron encomendadas a este nodo buscando dentro de su hash map, los que tengan la clave X. Todas las tareas que an estn presentes en el hash map an no han sido procesadas y necesitan ser re-ejecutadas, esta vez por un nodo diferente. Esto se realiza mediante la comparacin del rango (rank) que incluye la tarea con el rank del nodo, ejecutndola si estos coinciden. 8

Si un master M sufre un crash despus de haber enviado una serie de tareas, pero que todava no ha recibido los resultados, los esclavos eliminan todas las tareas enviadas por M, ya que M ya no necesita los resultados.

El grupo consta de los nodos A, B, C y D. Los clientes pueden acceder a cualquiera de ellos. Una tarea presentada, por ejemplo, a B por un cliente que podra asignar a la tarea el numero 23. B a continuacin enva un mensaje (multicast) de EXECUTE (23, TASK) para todos los nodos del clster, y cada nodo aade la tarea nmero 23 a su cach. Sin embargo, el nico nodo procesando la tarea 23 es A (donde resulta estar mapeada la tarea 23), que luego enva el resultado como un RESULT (23, OBJ) hacia B. B devuelve el OBJ resultado al cliente y realiza un multicast de REMOVE (23) a todo el clster, lo que hace que todos los nodos eliminen la tarea 23 de sus caches. Si A tiene un problema o se cae durante el procesamiento de la tarea 23, algn otro nodo se habra hecho cargo, procesado el resultado y envindolo de vuelta a B. 6. Conclusiones Se puede concluir que un sistema implementado con JGroups cumple con los requerimientos de diseo de un sistema distribuido: o Es tolerante a fallos, tal como se present en el ejemplo de aplicacin, ya que no existe un servidor central, sino varios nodos que cumplen las mismas funciones. Cada nodo puede actuar como maestro y esclavo, y las tareas son acogidas por un nodo basado en un ID asignado por el remitente (master). Los accidentes (crashes) o el abandono voluntario de nodos no conduce a tareas perdidas ya que el sistema se re-balancea solo y asigna las tareas hurfanas a otro nodo en el clster. o Es escalable debido a que se pueden agregar ms nodos para aumentar el poder de procesamiento o a su vez eliminar nodos si no existe mucha carga. La formacin de clsteres es un claro mecanismo de escalabilidad horizontal. o Es un sistema abierto pues usa estndares reconocidos y adems se puede modificar su estructura de acuerdo a las necesidades del propio sistema. El hecho de que su componente central, el canal (Channel y su implementacin default JChannel), presente una interfaz sencilla y bien definida permite extender/modificar la funcionalidad de los elementos circundantes de forma independiente de la implementacin especfica del canal (en la mayora de casos). 9

Heterogeneidad debido a que los nodos pueden estar en distintos hosts, con distintas caractersticas. Y permite la ejecucin multiplataforma al ser una tecnologa Java.

Adicionalmente existe la presencia de transparencia, debido a que el emisor de solicitudes desconoce la identidad de los integrantes de un grupo, as como su localizacin y la manera en que el grupo afronta la presencia de errores en el conjunto.

7. Bibliografa Coulouris, George. Dollimore, Jean. Kindberg, Tim. Blair, Gordon. (2011). Distributed Systems: Concepts and Design (Fifth Edition). Estados Unidos: Pearson Education, Inc. Ban, Bela. Blagojevic, Vladimir. Reliable Group Comunication with JGroups 3.x. Recuperado el 10 de Noviembre de 2013 de http://www.jgroups.org/manual/pdf/master.pdf. Ban, Bela. Design and implementation of a Design and Implementation of a Reliable Group Communication Toolkit for Java. Recuperado el 10 de Noviembre de 2013 de http://www.cs.cornell.edu/info/projects/JavaGroupsNew/papers/Coots.ps.gz. Ban, Bela. Implementing Group Protocols Using Dynamic Remote Method Calls. Recuperado el 10 de Noviembre de 2013 de http://www.cs.cornell.edu/info/projects/JavaGroupsNew/papers/rmc.ps.gz. Montresor, Alberto. (2000). System Support for Programming Object-Oriented Dependable Applications in Partitionable Systems. Recuperado el 10 de Noviembre de 2013 de http://www.informatica.unibo.it/it/ricerca/technical-report/2000/pdfs/2000-10.ps.gz. Montresor, Alberto. Meline, Hein. (2002). Jgroup Tutorial and Programmers Manual . Recuperado el 10 de Noviembre de 2013 de http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.124.7522&rep=rep1&type=pdf Ban, Bela. (2008). A simple clustered task distribution system. Recuperado el 10 de Noviembre de 2013 de http://www.jgroups.org/taskdistribution/TaskDistribution.html.

10