next up previous
Siguiente: 3. JavaGroups como herramienta Subir: Memoria Proyecto Fin de Anterior: 1. Introducción

Subsecciones


2. Estado del arte de los sistemas distribuidos

En el inicio de la era de la informática, las computadoras eran grandes y caras. Debido a su escasez y coste, sólo estaban en funcionamiento unas pocas en todo el mundo. A partir de los años 70, surgen los primeros miniordenadores (apareció el PC), que competirían con los grandes ordenadores tanto en prestaciones como en precio, con lo que se extendió su uso. Los grandes sistemas centralizados fueron dejando paso a sistemas mucho más descentralizados, formados por varios ordenadores. Pronto surgió la necesidad de interconenectar los equipos, y se desarrollaron las redes de área local (LAN), como Ethernet o Token Ring. En la actualidad, Internet es la red de mayor tamaño y la más usada, manteniendo un impresionante ritmo de crecimiento. Este crecimiento ha motivado durante los últimos años una mayor demanda de servicios por parte de los usuarios.

Aunque los actuales sistemas en red solucionan parte de las necesidades actuales de comunicación entre computadoras, tienen importantes limitaciones, y no permiten desarrollar gran cantidad de aplicaciones, principalemente aquellas que por sus características, requieren estar disponibles de forma ininterrumpida. Es en estos casos dónde los sistemas distribuidos incorporan, además, tolerancia a fallos.


2.1 Introducción

Existen varias definiciones de un sistema distribuido, una de ellas es [9] [19]: ``Un sistema de computación distribuido consta de múltiples procesadores autónomos que no comparten memoria principal, sino que cooperan a través de una red de comunicaciones que los interconecta'' (ver figura 2.1).

El término sistema operativo distribuido [9] [19] define una capa que hace transparente a los usuarios la localización de los elementos que forman parte del sistema.

Los sistemas centralizados tienen un punto de fallo único (hay un único computador en el que se ejecutan todas las aplicaciones). En los sistemas distribuidos, los elementos que lo componen están dispersos y, por lo tanto, tienen probabilidades de fallo independientes. Esta característica puede utilizarse para preveer la aparición de fallos parciales y posibilitar su tratamiento (otro computador puede sustituir al que ha fallado). De esta forma, el sistema distribuido permite la construcción de sistemas que operan de forma continua.

Figura 2.1: Sistema distribuido
\includegraphics[scale=0.6]{figures/sd.eps}

Los sistemas distribuidos necesitan de un soporte de comunicaciones. Este servicio de comunicaciones debe ser fiable y con un rendimiento aceptable. Además, en los sistemas distribuidos aparecen los problemas clásicos de los sistemas concurrentes: recusos compartidos, sincronización, etc.

En este capítulo se realiza una aproximación a estos sistemas, haciendo hincapié en los mecanismos de comunicación necesarios para el desarrollo de aplicaciones distribuidas y justificando el paradigma de grupo como propuesta válida para la implementación de aplicaciones distribuidas.

2.2 Propiedades

Los sistemas distribuidos deben intentar proporcionar transparencia, eficiencia, flexibilidad, escalabilidad y fiabilidad [9]. Sin embargo, estos aspectos son, en parte, contrarios y, por lo tanto, al diseñar un sistema distribuido se debe intentar cumplir de manera aceptable con cada uno de ellos:

2.3 Campos de aplicación

En relación con los campos de aplicación de este tipo de sistemas; podemos distinguir, por un lado, aquellos donde la distribución es fundamentalmente un medio para conseguir un fin y, por otro, aquellos donde es un problema en sí misma.

En los primeros, el uso de soluciones distribuidas pretende alcanzar las siguientes metas:

En los segundos, son los propios requisitos de la aplicación los que fuerzan a evolucionar hacia soluciones distribuidas:

Los sistemas distribuidos necesitan obligatoriamente un soporte de comunicaciones. Este servicio de comunicaciones debe ser fiable y presentar un rendimiento aceptable. Además, en los sistemas distribuidos aparecen los problemas clásicos de los sistemas concurrentes: recursos compartidos y sincronización, entre otros. En las siguientes secciones se van a analizar estas características así como describir mecanismos que permiten explotar la posibilidad de tolerar fallos en los sistemas distribuidos.


2.4 Comunicación y sincronización

El proceso es el concepto básico para expresar concurrencia, tanto en un sistema centralizado como en uno distribuido. Con la introducción de los procesos se permite dividir el software en módulos, cada uno de los cuales expresa una actividad lógicamente concurrente con el resto. Este modelo permite mayor simplicidad y más fácil comprensión del software utilizado, frente al comportamiento, muchas veces confuso, de un programa secuencial que trata de expresar un comportamiento concurrente.

El modelo de proceso resulta incompleto si no se proporcionan mecanismos para la comunicación entre procesos. Esto es debido a que, normalmente, en todo sistema concurrente, existen interacciones entre sus diferentes actividades concurrentes.

La diferencia más importante entre un sistema distribuido y uno centralizado es precisamente cómo se realiza la comunicación entre procesos. En un sistema centralizado, las interacciones entre procesos se hacen sobre memoria compartida, [9] mientras que en un sistema distribuido se necesita intercambio de mensajes. Los mecanismos a estudiar son entonces: el paso de mensajes punto a punto [2] [9] y la llamada remota a procedimiento [2] [9]. Una variante de los mensajes punto a punto son los buzones. Estos se usan para enviar o recibir mensajes, permitiendo no sólo desacoplar emisor y receptor sino, también, tener múltiples emisores y receptores.

En un sistema distribuido, un emisor también debería poder referenciar, al mismo tiempo, a un conjunto de receptores ya que la información contenida en un mensaje puede ser necesaria en más de un punto del sistema distribuido. Por tanto, la comunicación con grupos de procesos es otro tipo de interacción que conviene analizar y solucionar. Un grupo [5] [9] [15] es un conjunto de objetos que comparten una semántica de aplicación común, así como el mismo identificador de grupo y/o dirección de comunicación. Cada grupo es visto como un ente lógico individual, que no deja ver a los usuarios su estructura interna ni las interacciones entre sus miembros. Si se pretende una definición más cercana a la implementación, podría ser esta: un grupo de procesos es un conjunto de puntos extremos de comunicación (por ejemplo sockets de UNIX) que se pueden referenciar como un único ente. Los grupos de procesos son una herramienta natural para programar un sistema distribuido, y su importancia ha ido incrementándose en entornos de programación distribuida a lo largo del tiempo. Sin embargo, aún no hay un modelo que unifique las semánticas más apropiadas que deben cumplir las interacciones de los miembros de estos grupos (tipos de primitivas de comunicación, notificación de la entrada y salida de los procesos que forman un grupo, entre otras).

2.4.1 Mecanismo de paso de mensajes

El mecanismo de paso de mensajes punto a punto [2] [9] se define como una forma de comunicación en la que el usuario es explícitamente consciente del uso de mensajes en la comunicación mediante envíos y recepciones. Este tipo de interacción empezó a tener gran auge con la llegada de las arquitecturas multiprocesadores y distribuidas. Dicho mecanismo de comunicación entre procesos se ha desarrollado en el campo de los sistemas distribuidos de forma casi independiente al desarrollo de las redes de ordenadores.

La Organización Internacional de Normalización (ISO) propone un conjunto de protocolos de comunicación para la interconexión de sistemas abiertos (OSI) y define un modelo de referencia compuesto por siete niveles: nivel físico, nivel de enlace de datos, nivel de red, nivel de transporte, nivel de sesión, nivel de presentación y nivel de aplicación. El objetivo de los cuatro primeros niveles es ofrecer comunicación fiable entre dos puntos extremos. Los tres últimos niveles se refieren a los modos de interacción, representación de datos y servicios adicionales que se ofrecen a los usuarios. Sin embargo, estos protocolos no consideran el ámbito y las necesidades de los sistemas distribuidos puesto que:

Un diseño eficiente de los mecanismos de interacción entre procesos sólo se puede conseguir analizando cómo y para qué se utilizan.

2.4.2 Llamada remota a procedimiento

La llamada remota a procedimiento (Remote Call Procedure, RPC) [2] [9] proporciona un nivel de abstracción más alto que el mecanismo de paso de mensajes, facilitando así la programación de aplicaciones distribuidas. Estas llamadas permiten al flujo de control de un proceso, que se ejecuta en un nodo del sistema, ejecutar de forma transparente una operación (procedimiento) que se encuentra en otro nodo (remoto).

El diseño inicial de la aplicación es semejante al de una aplicación centralizada. Entonces se decide qué procedimientos se ejecutarán en la máquina remota y, utilizando herramientas automáticas, se construyen dos procedimientos suplentes: uno en el lado del cliente (stub) y otro en el lado del servidor (skeleton). Son estos procedimientos suplentes los que se encargan de que, al realizar una llamada localmente, la misma sea transmitida a través de la red para su ejecución remota (ver figura 2.2). De esta forma, el proceso cliente ejecuta un procedimiento remoto sin reparar en cómo se lleva a cabo la comunicación a través de la red. La única limitación en la RPC es que todos los parámetros que se utilicen en las llamadas han de ser pasados por valor, y no por referencia, ya que ambos procedimientos se ejecutan en espacios de memoria disjuntos. Sin embargo, para que estos parámetros puedan ser enviados a través de la red es necesario que los mismos sean serializables, es decir, han de poder ser convertidos en una corriente de bytes.

Figura 2.2: Llamada remota a procedimiento
\includegraphics[scale=0.6]{figures/rpc.eps}

2.4.3 Protocolos de radiado

El simple intercambio de mensajes entre un emisor y un receptor, no es siempre un buen modelo de comunicación para un sistema distribuido. En muchas situaciones es más útil disponer de primitivas que permitan enviar datos desde un emisor a un grupo de procesos, dado que este tipo de comunicación es muy habitual en estos sistemas (por ejemplo, para conseguir tolerancia a fallos, reparto de carga o mejora de la velocidad de respuesta). En estos casos es más apropiado pensar en términos de radiado [9] [15] (de mensajes) y no, del tradicional unienvío.

El radiado de mensajes [9] [15] es una herramienta que permite simplificar el diseño de varios aspectos de un sistema distribuido:

La programación de sistemas distribuidos resulta más sencilla si se dispone de un soporte de comunicación que entienda de grupos de procesos y que asegure una serie de propiedades en la entrega de los mensajes: [9]

2.4.4 Comunicación en grupo

La mayor parte de aplicaciones distribuidas está basada en el paradigma cliente/servidor. Para resolver esta interacción utilizando grupos de procesos, se necesitan sistemas de comunicación en los que un proceso pueda enviar mensajes a varios procesos
(comunicación $1-a-N$), recibir sus respuestas (comunicación $N-a-1$) e, incluso, que un conjunto de procesos pueda enviar mensajes a otro grupo (comunicación $N-a-M$). El desarrollo de estos tipos de comunicación, conocidos como radiados, [9] [15] está íntimamente relacionado con los grupos de procesos. [9] [15]

Podemos considerar a un grupo como un conjunto de procesos con una semántica común. La propiedad fundamental que deben cumplir es que cuando se envía un mensaje, todos los miembros lo reciben. De esta forma se puede conseguir la coordinación de los distintos miembros que forman un grupo.

Figura 2.3: Grupos abiertos y grupos cerrados
\includegraphics[scale=0.6]{figures/grps_abiertos.eps}

Los sistemas que soportan comunicación con grupos pueden dividirse en dos categorías: grupos cerrados y grupos abiertos (ver figura 2.3). En los primeros sólo se permite la comunicación entre los miembros del grupo, mientras que en los segundos, los procesos que no pertenecen al grupo pueden interactuar con él. Los grupos cerrados suelen utilizarse, en general, para el procesamiento en paralelo, donde cada uno de los miembros tiene su propio objetivo y no interactúa con el ``mundo exterior''. En cambio, los grupos abiertos están pensados para el desarrollo de aplicaciones tipo cliente/servidor, donde los procesos interactúan con el grupo para solicitar servicios.

También podemos clasificar los grupos de procesos atendiendo al papel que desempeñan los miembros que los componen: grupos de iguales y grupos jerárquicos (ver figura 2.4). Si en un grupo no existe una distinción entre los procesos que lo forman, y las decisiones se toman de forma colectiva, se dice que se trata de un grupo de iguales. En cambio, si se establecen relaciones de jerarquía en un grupo, donde unos procesos tienen una mayor capacidad de decisión que otros, se habla de grupos jerárquicos. Cada una de estas organizaciones grupales tiene sus ventajas y desventajas. En los grupos jerárquicos, si fallan los procesos que toman decisiones, se puede producir una descoordinación del resto de los miembros durante el tiempo que esta situación permanezca. En el grupo de iguales no se produce este efecto; si falla uno de sus miembros se podrá seguir trabajando (con un grupo más reducido).

Figura 2.4: Grupos de iguales y grupos jerárquicos
\includegraphics[scale=0.6]{figures/grps_jerarquicos.eps}

Cada grupo de procesos tiene asociada una membresía que define su composición. Si esta membresía puede variar durante la ejecución de la aplicación, estamos hablando de grupos dinámicos, mientras que si su composición (o membresía) no varía, o sólo lo hace si falla alguno de sus miembros, se denominan como grupos estáticos.

2.5 Tolerancia a fallos

Un sistema distribuido es una colección de nodos autónomos de computación que se pueden comunicar unos con otros y que colaboran en un objetivo o tarea común.

Cuando un nodo falla o cuando el subsistema de comunicaciones que permite que los nodos se comuniquen falla, los nodos se han de adaptar a las nuevas condiciones, para que puedan seguir cooperando.

En los sistemas tolerantes a fallo, [8] [9] [12] [14] [16] los fallos que se pueden tolerar son aquéllos que está previsto que pueden ocurrir. El primer paso necesario para que un sistema pueda recuperarse de un fallo, es detectarlo. El siguiente paso es llevar al sistema a un estado consistente, para ello, es necesario que las acciones realizadas antes del fallo mantengan la consistencia. La clave para tolerar fallos es la replicación, [8] [9] [12] [14] [16] es decir, que varios elementos del sistema puedan dar el mismo servicio.

A continuación se definen los modelos de fallo más frecuentes en la literatura, y las soluciones para conseguir la tolerancia a fallos.

2.5.1 Semánticas de fallo

Los sistemas de computación constan de multitud de componentes hardware y software que pueden fallar (debido a un error de diseño, al envejecimiento de los materiales o a un evento externo). En muchos sistemas, estos fallos pueden llegar a producir inconsistencias y, por lo tanto, la no disponibilidad del servicio que estaban ofreciendo. Existen sistemas que se diseñan para tolerar fallos. Estos sistemas (sistemas tolerantes a fallos) hacen transparente al usuario los modos de fallos previstos en el sistema. A continuación se hace una taxonomía de los modos de fallo: [9]

Cuando se quiere construir un sistema tolerante a fallos, habitualmente se consideran dos alternativas. La primera consiste en ejecutar sistemas software sobre hardware especializado tolerante a fallos (CPU y memoria principal replicadas, discos espejo, varios buses y rutas de datos, entre otros.) pero; debido a razones económicas, fundamentalmente, la segunda aproximación está ganando impulso y es la de usar hardware estándar para soportar tolerancia a fallos, replicando ese hardware y manteniendo esa replicación a nivel software. De esta forma se consigue un sistema distribuido tolerante a fallos.

Los protocolos que gestionan las réplicas pueden dividirse en dos clases: los que usan replicación activa y los que siguen el modelo de primario y respaldo.

2.5.2 Replicación activa

La replicación activa (conocida también como replicación mediante máquina de estados) [9] [14] es un método general para construir un sistema tolerante a fallos mediante la replicación de sus elementos y la coordinación de las comunicaciones entre ellos.

Una máquina de estados está compuesta por un conjunto de variables (estado) y un conjunto de operaciones que modifican o consultan el valor de esas variables. Cada operación se realiza mediante un programa determinista, [9] y su funcionamiento es atómico repecto al de otras. Las operaciones también producir resultados de salida. Cuando un cliente quiere ejecutar un servicio de la máquina de estados, le hace una petición, indicando qué operación debe ejecutar. El resultado puede ser la activación de un actuador o la respuesta a algún cliente que la estaba esperando. Es necesario también que las peticiones que recibe una máquina de estados sean atendidas de una en una, en un orden que ha de ser consistente con la causalidad potencial entre ellas.

La propiedad fundamental que caracteriza una máquina de estados es que los resultados de salida que produce están completamente determinados por la secuencia de peticiones que recibe, con independencia del momento en que las recibe y de cualquier otra actividad del sistema. Una gran ventaja de este enfoque consiste en que casi cualquier sistema puede descomponerse en clientes y máquinas de estados, por lo que puede ser utilizado en gran parte de los casos.

Para conseguir una versión tolerante a t fallos de una máquina de estados podemos replicarla, colocando cada réplica en un nodo diferente de la red. Si todas las réplicas comienzan en el mismo estado, y reciben la misma secuencia de peticiones, todas harán lo mismo, y producirán los mismos resultados. El número de réplicas que son necesarias para tolerar t fallos depende del modelo de fallo que se considere. Si son fallos bizantinos, hacen falta como mínimo 2t + 1, y para obtener resultados correctos basta con tomar los que producen la mayoría de las réplicas. Si se considera que sólo puede haber fallo-parada, basta con t + 1 réplicas.

En otras palabras, la clave para conseguir máquinas de estados replicadas tolerantes a fallos está en garantizar la coordinación entre las réplicas (todas reciben y procesan la misma secuencia de peticiones). Este requisito puede a su vez descomponerse en dos: concenso [9] [14] (todas las réplicas correctas reciben el mismo conjunto de peticiones) y orden [9] [14] (todas las réplicas correctas procesan las peticiones que reciben en el mismo orden).

Los algoritmos de comunicación que satisfacen el requisito de acuerdo (concenso) deben conseguir que un emisor pueda enviar un mensaje a los receptores cumpliendo dos condiciones: todos los receptores correctos están de acuerdo en el mensaje que reciben y, si el emisor es correcto, lo que cada receptor correcto recibe es lo que envió el emisor. Los que garantizan estas dos condiciones se llaman protocolos de radiado fiables, protocolos de acuerdo bizantino o, simplemente, protocolos de concenso [5] [9] [13].

El requisito de orden suele satisfacerse añadiendo información de orden a los mensajes. Esta información puede ser añadida por uno de los receptores (que luego la distribuye a los demás), o por los emisores, mediante el uso de algún tipo de reloj lógico (generalmente, combinado con cierto acuerdo entre los receptores).

Consideremos un objeto x, y la invocación de la operación [x op(arg) $p_{i}$] por parte del cliente $p_{i}$ (Figura 2.5):

  1. La petición se envía a todas las réplicas de x.
  2. Cada réplica procesa la petición, actualiza su estado, y envía la respuesta [x ok(res) $p_{i}$] al cliente $p_{i}$.
  3. El cliente espera hasta que recibe la primera respuesta, o hasta que recibe todas las respuestas. Si las réplicas no se comportan de manera maliciosa (es decir, no se producen fallos bizantinos), entonces el proceso cliente espera sólo por la primera respuesta. En caso contrario, será necesario disponer al menos de 2f + 1 réplicas para tolerar hasta f posibles fallos. En esta situación, el cliente espera a recibir sólo f + 1 respuestas idénticas.

Figura 2.5: Replicación activa
\includegraphics[scale=0.9]{figures/figura1.3.eps}

2.5.3 Replicación mediante primario y respaldos

En los sistemas que usan este enfoque para lograr tolerancia a fallos, los emisores envían mensajes sólo al proceso marcado como primario. Si éste falla, uno de los respaldos toma su lugar. Los clientes deben darse cuenta de estas caídas y actualizar el primario para poder enviar sus mensajes al proceso adecuado.

Más formalmente, para que un protocolo pueda ser considerado del tipo primario-respaldos, deben cumplir las siguientes condiciones: [8] [9] [14] [16]

Las tres primeras propiedades definen cómo debe ser el protocolo entre los clientes y el servicio y la cuarta indica en qué condiciones el servicio debe satisfacer las peticiones.

Consideremos una vez más la invocación de la operación [x op(arg) $p_{i}$] por parte del cliente $p_{i}$. En ausencia de fallo del servidor primario, la petición se maneja de la siguiente forma (Figura 2.6):

  1. El proceso $p_{i}$ envía la petición x op(arg) a la réplica primaria $x_{1}$.
  2. $x_{1}$ recibe y ejecuta la petición. Una vez ejecutada la operación solicitada, $x_{1}$ envía a las réplicas de respaldo la petición que se recibió del cliente para que éstas actualicen su estado.
  3. Cuando $x_{1}$ recibe un reconocimiento desde todos los servidores de reserva, la respuesta es enviada al cliente $p_{i}$.

Figura 2.6: Replicación pasiva
\includegraphics[scale=0.9]{figures/figura1.2.eps}

2.6 Herramientas para comunicación en grupo

La comunicación en grupo asume un papel importantísimo a la hora de crear sistemas distribuidos tolerantes a fallos. Ello es así puesto que para poder ofrecer tolerancia a fallos a una aplicación determinada, no es suficiente con replicar dicha aplicación, sino que además es necesario disponer de un sistema que facilite la comunicación entre tales réplicas. [3] [5] [6] [7] [9] [15]

En un modelo de comunicación con grupos dinámicos, los procesos podrán unirse o abandonar el grupo cuando lo deseen, haciendo que la membresía pueda cambiar a lo largo del tiempo. Al conjunto de procesos que forman parte de un grupo se le conoce con el nombre de vista. Existirá por tanto un servicio de membresía que se ocupará de mantener actualizada la vista en cada uno de los miembros del grupo.

Las herramientas software para comunicación con grupos utilizan una arquitectura conocida con el nombre de 3T (three-tier). En este modelo los clientes (client-tier) interactuan con una capa intermedia (middle-tier) que se encarga de enviar las peticiones a los servidores replicados (end-tier), manteniendo en todo momento la consistencia.

Para lograrlo, la capa intermedia anida dos componentes básicos, el secuenciador y el manejador de replicación activa, que se encargan de garantizar que todas las réplicas reciben y ejecutan las peticiones de los clientes en el mismo orden en que fueron enviadas.

Las herramientas para comunicación con grupos [3] [5] [6] [7] [9] [15] proporcionan un conjunto de servicios y primitivas que ayudan a los desarrolladores a construir sistemas de alta disponibilidad utilizando replicación software. En un sistema de este tipo se distinguen dos bloques fundamentales, (i) la API y (ii) el núcleo del sistema (figura  2.7).

Figura 2.7: Arquitectura de las herramientas para comunicación de grupo
\includegraphics[scale=1]{figures/figura4.1a.eps}

El primer bloque lo constituye un conjunto de interfaces que permiten a la aplicación utilizar los servicios ofrecidos por la herramienta para comunicación de grupo; el segundo bloque implementa tales servicios. Ambos bloques pueden ser implementados usando diferentes lenguajes de programación.

En caso de considerar herramientas de comunicación con grupos escritas en Java, es importante tener en cuenta como puede afectar al rendimiento la localización de la Máquina Virtual (JVM). Si sólo la API está escrita en Java, entonces la JVM estará ubicada bajo este bloque, permitiendo al núcleo intercambiar mensajes a través de la red utilizando llamadas nativas al sistema. Por el contrario, si el núcleo también está escrito en Java, la comunicación con la red habrá de realizarse a través de la JVM, lo cuál puede afectar negativamente al rendimiento.

Otro factor importante a la hora de elegir una herramienta de comunicación con grupos es su capacidad para adaptarse a las necesidades del usuario, pudiendo tener sistemas monolíticos y sistemas modulares. En un sistema monolítico no se permite al usuario adaptar el sistema, sin embargo, en un sistema modular el usuario es libre para adapar el sistema a sus necesidades configurando la pila de protocolos de la forma que considere más oportuna.

2.6.1 Sistemas Monolíticos

De entre los sistemas monolíticos más conocidos se han elegido para su presentación Isis, Phoenix, RMP, Totem y Spread.

2.6.1.1 Isis

Isis [15] fué el primer sistema propuesto para comunicación en grupo (figura  2.8). Las capas principales que constituyen este sistema son:

2.6.1.2 Phoenix

Phoenix [15] es una variación de la arquitectura de Isis (figura  2.8). Los servicios de membresía (Membership) y sincronía de vistas (View Synchrony) se agrupan en una sola capa, al tiempo que se introduce una nueva capa base para resolver el problema del concenso (Concensus).

La principal limitación de Isis era proporcionar el servicio de membresía al nivel de procesador. En caso de particionado de la red, conducía al servicio a eliminar todos los procesos sobre los procesadores que no estaban en la partición primaria. Phoenix solventa este inconveniente al proporcionar el servicio de membresía a nivel de procesos, permitiendo la computación en todas las particiones.

Figura 2.8: Arquitecturas ISIS y PHOENIX
\includegraphics[scale=1]{figures/figura4.3.eps}

2.6.1.3 RMP

En RMP, [15] la capa de membresía está dividida en dos partes: membresía libre de fallos (Fault-free Membership) y membresía tolerante a fallos (Fault-tolerant Membership). (Figura 2.9)

La membresía libre de fallos maneja los joins/leaves en ausencia de fallos usando la capa inferior (Atomic Broadcast). De esta forma se consigue asegurar la sincronía de las vistas, sin embargo, el protocolo de radiado atómico se bloquea en caso de que un proceso falle. Cuando esto ocurra, el papel de la capa de membresía tolerante a fallos es evitar este bloqueo excluyendo los procesos sospechosos de haber fallado.

2.6.1.4 Totem

Totem [15] utiliza un algoritmo de radiado atómico basado en la rotación de un testigo. La ordenación total es proporcionada por la capa intermedia de la arquitectura que se muestra en la figura 2.9. El protocolo de membresía de la capa más baja, aparte de detectar fallos y gestionar vistas, recupera el testigo y los mensajes que no hayan podido ser entregados cuando ocurren fallos.

La capa superior (Recovery) completa el servicio de membresía, asegurando la sincronía de las vistas.

Figura 2.9: Arquitecturas RMP y Totem
\includegraphics[scale=1]{figures/figura4.4.eps}

2.6.1.5 Spread

Spread [3] se basa en una arquitectura cliente-demonio (el demonio representa el núcleo del sistema). El cliente se conecta al demonio por medio de una API predefinida, y envia mensajes a otros miembros del grupo. La API y el núcleo residen en distintos procesos, que pueden estar ubicados en la misma o en distintas máquinas.

El demonio está escrito en C, mientras que la API está disponible en C++, Java y otros lenguajes.

2.6.2 Sistemas Modulares

Respecto a los sistemas modulares, se describen las características de Maestro/Ensamble, Appia y JavaGroups.

2.6.2.1 Maestro/Ensamble

Ensemble [3] esta basado en el concepto de pila de protocolos adaptable con objeto de solventar la degradación en el rendimiento que ofrecen los sistemas monolíticos.

A su vez, Maestro [3] es una interfaz para Ensemble escrito en C++. Ejecuta Ensemble en un hilo separado, haciendo que tanto la API como el núcleo residan en el mismo proceso, compartiendo el mismo espacio de direcciones.

2.6.2.2 Appia

Al igual que Ensemble, Appia [3] se basa en el concepto de pila de protocolos adaptable, pero a diferencia de Ensemble, permite no sólo utilizar los protocolos que mejor se adapten a las necesidades del usuario sino también añadir protocolos adicionales y eventos para comunicación entre los mismos.

No hay una separación clara entre la API y el núcleo del sistema, estando ambos escritos completamente en Java.

2.6.2.3 JavaGroups

JavaGroups es una herramienta escrita completamete en Java (con objeto de explotar al máximo los beneficios de este lenguaje). Se puede considerar como API, puesto que es facilmente integrable con cualquier otra herramienta para comunicación en grupo.

Tanto la aplicación como el núcleo se ejecutan en el mismo proceso.

2.6.3 Comparativa

En la figura 2.10 se muestra una comparativa de las distintas herramientas en base al lenguaje de programación que se utiliza, colocación de la JVM y diseño del núcleo.

Figura 2.10: Clasificación de algunas herramientas de comunicación de grupo
\includegraphics[scale=1]{figures/figura4.2.eps}

next up previous
Siguiente: 3. JavaGroups como herramienta Subir: Memoria Proyecto Fin de Anterior: 1. Introducción
Luis Hernandez 2004-09-28