Monografía:
Replicación
Cátedra: Sistemas Operativos
Tema: Replicación
Grupo Nº: 9
Integrantes:
Basconcel,Gabriela.
Benitez, Antonio.
Fernández Diana E.
I.
Jensen, Natalia E.
Maidana, Mariela A.
Pace, Guido
J.
Podestá, Silvina I.
Rivero, Alina.
Rodríguez
Gómez, Gisela L.
Sanchez de Bustamante, Santiago B.
Año: 2002
INDICE
1.0.0. Introducción ......................................................................1
1.1.0. Replicación(concepto) .......................................................2
1.2.0. Modelo de sistema .............................................................. 3
1.2.1. Comunicación en grupo ..................................................... 4
1.3.0. Servicio tolerante a fallos .................................................. 5
1.3.2. Replicación pasiva (primaria-respaldo) .......................... 6
1.3.1. Replicación activa ...............................................................7
1.4.0. Servicios con alta disponibilidad ...................................... 8
1.4.1. Arquitectura Cotilla .......................................................... 8
1.4.2. Arquitectura de Bayou ...................................................... 9
1.4.3. Sistema de archivos Coda ................................................. 9
1.5.0. Transacciones con datos replicados ................................10
1.5.1. Arquitecturas para transacciones replicadas ................10
1.5.3. Particiones en la red ........................................................13
1.5.4. Copias disponibles con validación .................................13
1.5.5. Métodos de consenso con quórum .................................13
1.5.6 El algoritmo de la partición virtual ................................14
1.6.0. Conclusión .......................................................................16
1.0.0. Introducción
Con este trabajo nos proponemos realizar una breve reseña bibliográfica acerca de la técnica denominada replicación, sus causas, sus métodos y su finalidad.
Consideraremos los sistemas que solicitan operaciones individuales sobre grupos de objetos replicados. Describiremos los componentes de la arquitectura y un modelo de sistema para los servicios que utilicen replicación. Nos referiremos a la integración y pertenencia a grupos de procesos como parte de la comunicación en grupos que es indispensable para los servicios tolerantes a fallos. Explicaremos las aproximaciones para lograr la tolerancia a fallos las cuales son la replicación activa en la cual los clientes se comunican por multidifusión con todas las réplicas, y la replicación pasiva en la cual los usuarios se comunican con una réplica distinguida. Trataremos las arquitecturas de sistemas que proporcionan elevada disponibilidad, las cuales son de Cotilleo, Bayou y Coda.
Finalizaremos con la secuencia de operaciones sobre objetos replicados y las arquitecturas de sistemas transaccionales que gestionan los errores en los servidores y las particiones en la red.
1.1.0. Replicación (concepto)
Los datos en nuestro sistema consisten en una colección de elementos llamados objetos. Un objeto podría ser un archivo o un objeto en Java.
La replicación de datos es utilizada para el mantenimiento automático de copias de datos en múltiples computadoras, por ejemplo el almacenamiento de datos provenientes de servidores Web en la memoria caché.
Es una técnica para la mejora de los servicios que ofrecen los sistemas distribuidos porque proporciona una mejora del rendimiento de los servicios e incrementa su disponibilidad y lo hace tolerante a fallos.
Su objetivo es que las operaciones de los clientes sobre las réplicas se realicen de forma consistente y con un tiempo de respuesta y un caudal satisfactorio. La consistencia no se logra algunas veces debido a que las réplicas de un cierto objeto no son necesariamente idénticas, al menos no en cada instante de tiempo particular. Algunas réplicas pueden haber recibido actualizaciones que otras no hayan recibido.
Mejora del Rendimiento
Los datos o recursos compartidos por una gran comunidad de usuarios no deben ser almacenados en un solo ordenador ya que esto provocaría un retraso en la captura de dichos recursos o datos. Es mejor distribuir copias entre varios servidores para que cada uno proporcione datos a una comunidad mas pequeña de clientes.
Incremento en la Disponibilidad
Disponibilidad es la proporción de tiempo en la que un servicio es accesible con tiempo de respuesta razonable. Este puede incrementarse mediante servidores replicados. Sea: n el número de servidores y p la probabilidad de que un servidor falle, entonces el porcentaje de tiempo que un servidor esté activo será 1- pn . La diferencia entre caché y la replicación de servidores es que la caché no necesariamente incrementa la disponibilidad por no almacenar la totalidad de archivos.
Algunos factores principales que impiden la alta disponibilidad son las fallas en el servidor, las particiones de la red y las operaciones sin conexión.
Tolerancia a Fallos
Si las solicitudes de los clientes se procesan en paralelo, se puede garantizar que se dará respuesta correcta aunque algunos servidores fallen, esto ofrece garantías para el caso de sistemas con restricciones en tiempo real y también contra fallos arbitrarios que causan que un componente devuelva resultados erróneos en vez de detenerse.
El sistema debe gestionar la coordinación de sus componentes de un
modo preciso para garantizar la corrección de fallos que pueden ocurrir en cualquier momento.
La transparencia es un requisito común cuando los datos están replicados, para que los usuarios no adviertan la existencia de múltiples copias físicas de los datos.
Consistencia
En general no es aceptable que distintos clientes obtengan diferentes resultados al acceder a los mismos datos.
Como mínimo no es aceptable si el resultado lleva a una inconsistencia detectable y significativa entre diferentes aplicaciones o incluso dentro de una misma aplicación.
1.2.0. Modelo de Sistema
En un sistema asíncrono en el cual los procesos pueden fallar solo por caída, el modelo implica réplicas mantenidas por distintos gestores de réplicas, que son los procesos que mantienen las réplicas y realizan operaciones directamente sobre ellas. Típicamente cada gestor de réplicas mantiene una copia física de todos los conjuntos de datos, pero nada impide que a cada conjunto de datos lo mantengan distintos gestores de réplicas.
Siempre se exigirá que un gestor de réplicas solicite operaciones a sus réplicas con capacidad de recuperación. Esto permite suponer que una operación en un gestor de réplicas no deja resultados inconsistentes si falla durante el proceso.
El sistema únicamente puede determinar que operaciones aplicar en todos los gestores de réplicas y en que orden.
El conjunto de gestores de réplicas puede ser Estático o Dinámico. En un Sistema Dinámico pueden aparecer nuevos gestores de réplicas; esto no esta permitido en un sistema Estático. En un Sistema Dinámico los gestores de réplicas podrán caerse y entonces se considerará que abandonaron el sistema. En un Sistema Estático los gestores de réplicas no se caen, sino que cesan su ejecución durante un tiempo indefinido.
Los clientes perciben un servicio que les da acceso a los objetos que están replicados en los gestores. Las peticiones de cada cliente son atendidas por un componente llamado Frontal. Este se encarga de comunicarse mediante paso de mensajes con uno o mas gestores de réplicas, evitando que el cliente lo haga explícitamente. Es el móvil para hacer transparente la replicación.
El frontal se puede implementar como un paquete de usuario lo que le da mayor eficiencia, o como un proceso separado lo que da la posibilidad de compartir información entre varios clientes de la misma máquina.
Existen cinco fases para la realización de una petición sobre los objetos replicados. Las acciones en cada fase difieren de acuerdo al tipo de sistema.
Petición: El frontal realiza la petición a uno o mas de los gestores de réplicas. Una de las posibilidades es que el frontal se comunique con un gestor de réplica individual que, se comunica a su vez
con otros gestores de réplicas. La otra posibilidad es que el frontal difunda la petición a varios gestores de réplicas.
Coordinación: Se ponen de acuerdo los gestores de réplicas en si ejecutaran, o no la petición y deciden sobre la ordenación de estas peticiones con respecto a otras.
Ejecución: Los gestores de réplicas ejecutan la petición, de tal forma que puedan deshacer sus efectos en la siguiente fase, esta forma es denominada Tentativa.
Acuerdo: Los gestores de réplica se ponen de acuerdo en que si concluirán o no una petición.
Respuesta: Uno o mas gestores de réplicas envían la respuesta al frontal, si la respuesta proviene de un grupo de gestores de réplicas, el frontal selecciona una respuesta individual y la devuelve al cliente.
1.2.1. Comunicación en Grupo
La comunicación por multidifusión se entiende como comunicación en grupo ya que los grupos de procesos son los destinatarios de los mensajes de multidifusión. Los grupos sirven para manejar datos replicados y sistemas donde los procesos operan en conjunto para recibir y procesar el mismo conjunto de mensajes de multidifusión.
La pertenencia a los grupos estaba definida de manera estática a pesar de que los miembros del grupo fallen. No obstante, en la práctica los sistemas requieren pertenencia dinámica, esto significa que los procesos se unen y dejan el grupo según el sistema trabaja. Este servicio de pertenencia al grupo y la comunicación por multidifusión se incluyen en una implementación completa de la comunicación en grupo.
La gestión de la comunicación por multidifusión y la de pertenencia a grupos están fuertemente relacionadas.
El papel del servicio de pertenencia a grupos tiene cuatro tareas principales:
Proporcionar una interfaz para los cambios en la pertenencia a grupos: esta interfaz puede crear, destruir, añadir o retirar procesos de un grupo. Un proceso individual puede pertenecer a distintos grupos al mismo tiempo.
Implementar un detector de fallos: el detector marca a los procesos como sospechosos o no sospechosos. El servicio utiliza al detector de fallos para tomar una decisión acerca de la pertenencia al grupo, o sea excluye un proceso si sospecha que ha fallado o se ha vuelto inaccesible.
Notificar a los miembros del grupo los cambios en la pertenencia: el servicio notifica a los miembros del grupo cuando se añade o cuando se quita un proceso.
Expandir las direcciones del grupo: cuando un proceso multidifunde un mensaje, proporciona el identificador del grupo en vez de una lista de los procesos del grupo. El servicio de gestión de pertenencia expande el identificador para obtener los miembros actuales del grupo y proceder al
reparto, el cual puede coordinar con cambios en los miembros del grupo mediante el control de la expansión de la dirección.
Entrega de Vistas: Las vistas de grupo son listas de los miembros actuales del grupo, identificados por su identificador único de proceso. La lista está
ordenada de acuerdo a la secuencia en la cual los miembros se unieron al grupo. Cuando se añaden o excluyen procesos se genera una nueva vista de grupo.
Se referirá a un miembro entregando una vista cuando ocurra un cambio en la pertenencia y se notifique a la aplicación la nueva pertenencia, en la misma forma en que un proceso entrega un mensaje multidifundido. Al igual que en la entrega de multidifusión, la entrega de una vista es distinta a la recepción de una vista. Los protocolos de pertenencia a grupos mantienen las vistas propuestas en una cola de retención hasta que todos los miembros existentes se pongan de acuerdo en la entrega.
Los requisitos básicos para la entrega de vistas son el orden, la integridad y la no trivialidad.
Orden: este requisito brinda al programador una garantía de consistencia asegurando que los cambios en las vistas ocurren en el mismo orden en diferentes procesos.
Integridad: es una verificación de consistencia.
No trivial: la condición de no trivialidad establece que dos procesos que se hayan unido al mismo grupo podrán, al final, comunicarse indefinidamente; ambos serán, considerados del mismo grupo.
Comunicación en grupos con vistas Síncronas: esta comunicación genera garantías adicionales en lo que respecta al orden en las entregas de notificaciones a vistas con respecto al reparto de mensajes de multidifusión. Las garantías que brindan son las siguientes:
Acuerdo: los procesos correctos reparten el mismo conjunto de mensajes en cualquier vista.
Integridad: si un proceso entrega un mensaje no volverá a entregar dicho mensaje.
Validez: los procesos correctos siempre entregan los mensajes que mandan.
Grupos de Objetos
Estos conceden una aproximación orientada a objetos a la computación en grupo. Un grupo de objetos es una colección de objetos que procesan el mismo conjunto de llamadas de forma concurrente y devuelven su respuesta.
1.3.0. Servicio Tolerante a Fallos
Los servicios tolerantes a fallos son aquellos que proporcionan un servicio correcto a pesar de que hallan procesos que fallen. Logra un correcto
servicio mediante la replicación de datos y otras funcionalidades en los gestores de réplicas. Consideramos que la comunicación es fiable durante todo el proceso y no ocurren particiones.
Un servicio de réplica se considerará correcto si es capaz de funcionar a pesar de fallos y si los clientes no notan la diferencia entre un servicio con datos replicados y otro proporcionado por un único gestor de réplicas correcto.
Linealizabilidad y consistencia secuencial
Un servicio de objetos compartidos replicados se dice Linealizables si para cualquier ejecución existe algún entrelazamiento de las series de operaciones emprendidas por cada cliente que satisface los siguientes criterios:
La secuencia entrelazada de operaciones cumple la especificación de una única copia correcta de los objetos.
El orden de las operaciones del entrelazamiento es consistente con los tiempos reales en los cuales ocurrieron las operaciones en la ejecución real.
La Linealizabilidad se refiere únicamente con el entrelazamiento de operaciones individuales que no está pensada que sea transaccional. Una ejecución Linealizable podría romper las nociones de consistencia especificas de una aplicación si no se aplica un control de concurrencia.
Un servicio de objetos replicados compartidos es secuencialmente consistente si para cualquier ejecución existe algún entrelazamiento de las series de operaciones realizadas por los clientes que satisfacen los dos siguientes criterios:
La secuencia de operaciones intercaladas cumple la especificación de una única copia correcta de los objetos.
El orden de las operaciones en el entrelazamiento es consistente con el orden en el programa con el cual cada cliente individual ejecutó dichas operaciones.
1.3.0. Replicación Pasiva (Primaria - Respaldo)
En este modelo para la tolerancia a fallos en cada instante existe un único gestor de réplicas primario y uno varios gestores de réplicas secundarios (respaldo o esclavos). En el modelo puramente formal los frontales se comunican con el gestor de réplicas primario para obtener el servicio, este ejecuta las operaciones y envía copias de los datos actualizados a los gestores de respaldo. Si uno de los gestores de réplicas primario falla, uno de los secundarios toma su lugar.
La secuencia de eventos cuando un cliente solicita que se realice una operación son:
Petición: el frontal efectúa la petición, que contiene un identificador único al gestor de réplicas primario.
Coordinación: el primario acepta cada petición en el orden en que las recibe. Comprueba el identificador único y si ya hubiera ejecutado la petición reenvía la respuesta.
Ejecución: el gestor de réplicas primario ejecuta la petición y guarda la respuesta.
Acuerdo: si la petición es una actualización, el primario envía a todas las copias de seguridad el estado actualizado, la respuesta y el identificador. Los respaldos envían a su vez, una confirmación de recepción.
Respuesta: el gestor de réplica primario responde al frontal y este se encarga de devolver la respuesta al cliente.
Este sistema implementa la linealizabilidad ya que si el gestor primario falla, un gestor secundario toma el control y esto hace que el sistema conserve la capacidad de secuenciación. Los gestores de réplicas que sobreviven, se ponen de acuerdo en que operaciones se habían realizado en el momento en el que el reemplazo del primario tomó el control.
La replicación pasiva tiene la desventaja de producir sobrecargas relativamente grandes.
Algunos sistemas emplean la replicación pasiva para lograr una alta disponibilidad y un buen rendimiento, aunque, con garantías mas débiles que la consistencia secuencial.
1.3.1. Replicación Activa
En este modelo para tolerancia a fallos los gestores de réplicas son máquinas de estado que se comportan igual y se organizan como un grupo. Los frontales multidifunden sus peticiones a los grupos de gestores de réplicas, y estos procesan la petición de forma individual pero idéntica y responden. No afecta la prestación del servicio la caída de uno de los gestores de réplicas ya que los restantes continúan respondiendo de la forma habitual. La replicación activa puede tolerar fallos bizantinos (extraños), ya que el frontal puede recopilar y comparar las respuestas que recibe.
La secuencia de eventos cuando un cliente solicita que se efectúe una operación bajo replicación activa son:
- Petición: el frontal adhiere un identificador único a la petición y la multidifunde al grupo de gestores de réplicas de manera fiable y ordenada. Además no se emitirá una nueva petición hasta haber obtenido la respuesta de la primera.
- Coordinación: el sistema de comunicación en grupo reparte la petición a cada gestor de réplicas correcto en el mismo orden.
- Ejecución: cada gestor de réplicas que recibió la petición la ejecuta, debido a que son máquinas de estado y la peticiones se entregan en el mismo orden total, todos los gestores de réplicas correctos procesan de la misma forma las peticiones. La respuesta contiene el identificador único de la petición del cliente.
- Acuerdo: no es necesario la etapa de acuerdo debido a la semántica de la multidifusión.
- Respuesta: cada gestor de réplicas envía su respuesta al frontal.
Este sistema consigue la consistencia secuencial. Todos los gestores de réplicas correctos procesan la misma secuencia de peticiones. La multidifusión asegura que se procese el mismo conjunto de instrucciones, y el orden total garantiza que las peticiones se procesan en el mismo orden. Como son máquinas estado todos finalizan en el mismo estado después de cada petición. Esto asegura la consistencia secuencial.
El sistema de replicación activa no consigue linealizabilidad debido a que el orden total en el que los gestores procesan las peticiones no es el mismo que el orden impuesto por el tiempo real en que los clientes realizaron sus peticiones.
1.4.0. Servicios con Alta Disponibilidad
En este tipo de sistemas se busca un nivel de servicio aceptable utilizando un conjunto mínimo de gestores de réplicas conectados al cliente. Y debería minimizar el tiempo que el cliente espera hasta que los gestores de réplicas procesen una respuesta.
A continuación se detallan tres sistemas (Cotilleo, Bayou y Coda) que proporcionan servicios con alta disponibilidad.
1.4.1. Arquitectura Cotilla
En ésta arquitectura los clientes hacen las solicitudes a su frontal, cada uno de estos se comunica con un gestor de réplicas (no fijo), y estos, a su vez, se comunican entre si mediante mensajes "cotillas''.
La arquitectura de cotillas soporta tres esquemas de ordenación:
Causal: esta se implementa para proporcionar la consistencia relajada, esto significa que todos los gestores de réplicas en un momento reciben todas las actualizaciones y las aplican de forma ordenada para hacer a las réplicas lo suficientemente parecidas, para cumplir con las necesidades de la aplicación.
Forzado: aporta garantías de ordenación mas fuertes.
Inmediato: la actualizaciones inmediatamente ordenadas se aplican en un orden consistente en relación a otras actualizaciones en todos los gestores de réplicas.
Proporciona dos tipo de operaciones:
Consulta: son operaciones de solo lectura.
Actualización: solo modifica y no lee el estado.
Explicaremos como se procesa las operaciones de pregunta y ordenación en un sistema de cotillas en términos de un modelo básico de replicación:
Petición: el frontal envía sus peticiones a un solo gestor de réplicas normalmente, si este falla o se vuelve inaccesible el frontal se comunicara con otro gestor de réplicas.
Respuesta a una actualización: si la petición es una actualización el gestor responde tan pronto como la recibe.
Coordinación: el gestor que recibe la petición no la procesa hasta que no coordine con las restricciones de ordenación que se requieran.
Ejecución: el gestor de réplicas ejecuta la petición.
Respuesta: si la petición es una pregunta, el gestor de réplicas responde en el momento.
Acuerdo: los gestores de réplicas se actualizan entre ellos mediante mensajes de cotilleo que contiene las mas recientes actualizaciones.
1.4.2. Arquitectura de Bayou
Este sistema proporciona replicación de datos con alta disponibilidad, con garantías mas débiles que la arquitectura de cotilla. Al final cada gestor de réplicas recibe el mismo conjunto de actualizaciones y aplica estas de modo que las bases de datos de los gestores de réplicas sean iguales.
El sistema Bayou se diferencia de los otros en que la replicación no es transparente para la aplicación. Una de las desventajas es el aumento de la complejidad para el programador, otra es el aumento de la complejidad para el usuario.
1.4.3. Sistema de Archivos Coda
Este sistema de archivos proporciona alta disponibilidad a pesar de que se realizan operaciones sin conexión. El sistema Coda intenta cumplir algunos requisitos para gestionar los datos con disponibilidad constante para que los usuarios se beneficien de un repositor de archivos compartidos y a la vez que puedan depender totalmente de los recursos locales cuando este repositor este inaccesible.
El diseño de Coda se basa en la replicación de volúmenes de archivos para conseguir una mayor capacidad de procesamiento de las operaciones de acceso a archivos y un mayor grado de tolerancia a fallos. Además este sistema se basa en la ampliación de un mecanismo para el mantenimiento en caché de copias de los archivos dentro de las computadoras de los clientes, para permitirles operar cuando no están conectados a la red.
Arquitectura Coda.
Un principio del diseño del sistema Coda es que la copia de los archivos que residan en los servidores sean mas fiables que aquellas que residan en las memorias caché de las computadoras de los clientes. La arquitectura Coda ejecuta dos procesos, uno denominado Venus en los computadores de los clientes y procesos Vice en los computadores del servidor de archivos. Los procesos vice son los que aquí llamamos gestores de réplicas, los procesos Venus son un híbrido entre los frontales y los gestores de replicas. Estos realizan la tarea del frontal ocultando la implementación del servicio a los procesos locales del cliente.
Estrategia de Replicación
El comportamiento del sistema Coda en el modo de operación normal impone un peor rendimiento por pérdida de una memoria caché. Las ventajas que se derivan de la replicación de conjuntos de archivos en múltiples servidores son:
Los archivos en un volumen replicado se mantienen accesibles para los clientes que accedan al menos a una de las réplicas.
El rendimiento del sistema puede mejorarse compartiendo las cargas de las peticiones de servicio sobre un volumen réplicas entre los servidores que mantengan réplicas.
En la operación sin conexión (el cliente no puede acceder a los servidores de un volumen), la perdida de una memoria caché impide que se pueda continuar y se suspende la computación hasta que se recupere la conexión o el usuario aborte el proceso. Entonces es importante la carga de la memoria caché antes de que comience la operación sin conexión de tal forma que se evita la pérdida de dicha memoria caché.
Coda aumenta la disponibilidad gracias a la replicación de archivos entre todos los servidores y a la posibilidad de que todos los clientes operen a partir de sus cachés.
La arquitectura Coda es similar al sistema Bayou, sus objetivos son
obtener una alta disponibilidad, pero difieren en que uno gestiona archivos y el otro, bases de datos.
1.5.0. Transacciones con Datos Replicados
Las transacciones son secuencias de una o mas operaciones. Los objetos en los sistemas transaccionales pueden replicarse para incrementar tanto su disponibilidad como su rendimiento. Desde el punto de vista de un cliente una transacción sobre objetos replicados debe parecer idéntica a una con objetos no replicados. En un sistema sin replicación las transacciones se realizan según un orden.
Cuando un gestor de réplicas se recupera de un fallo, utiliza la información que obtiene de los otros gestores de réplicas para restaurar sus propios objetos a sus valores actuales, teniendo en cuenta todos los cambios que han ocurrido durante el tiempo que no estuvo disponible.
Existen tres esquemas de replicación que funcionan correctamente cuando la colección de gestores de réplicas se divide en subgrupos a causa de una partición en la red:
Copias disponibles con validación.
Consenso con quórum.
Partición virtual.
1.5.1. Arquitecturas para Transacciones Replicadas
Un frontal podría tanto multidifundir las peticiones de un cliente a grupos de gestores de réplicas o bien podría enviar cada petición a un gestor de réplicas individual, el cual se encarga de realizar la petición y enviar la respuesta al usuario.
Se asume que un frontal envía la petición a un gestor de réplicas del grupo. Según el método de copia primaria, el frontal se comunica con un gestor de réplicas distinguido para realizar las operaciones del cliente, este a su vez, mantiene actualizados los datos en las copias de respaldo. Como otra posibilidad, los frontales, podrían comunicarse con cualquier gestor de
réplicas para llevar a cabo las operaciones, esto haría mas compleja la coordinación entre los gestores.
Un gestor de réplicas que recibe una petición para realizar una operación sobre un determinado objeto, debe encargarse de conseguir la cooperación de los demás gestores de réplicas que tengan copias de ese objeto.
Dependiendo del esquema de replicación existen distintas reglas concernientes a cuantos gestores de réplicas se necesitan para completar con éxito determinada operación. Por ejemplo en un esquema "uno lee, todos escriben'' una petición de lectura solo necesitará un gestor de réplicas en tanto una operación de escritura debe ser llevada a cabo por todos los gestores de réplicas en el grupo.
El gestor de réplicas contactado por un frontal, decide postergar el caudal de peticiones de actualización a los otros gestores de réplicas del grupo hasta que la transacción sea finalizada (aproximación perezosa), o si el gestor de réplicas debe enviar cada petición de actualización a todos los gestores de
réplicas del grupo involucrados en la transacción entes de que esta de por concluido (aproximación ansiosa o acuciante). La aproximación perezosa es utilizada para reducir la cantidad de comunicación entre los gestores de replicas antes de otorgarle la respuesta al cliente. Cuando se necesita que cada gestor de réplicas conozca las peticiones atendidas por los otros, para lograr transacciones correctamente secuenciadas en todos los gestores de réplicas del grupo, (por ejemplo, si varias transacciones distintas intentan acceder a los mismos objetos en distintos gestores), la única alternativa es la aproximación ansiosa o acuciante.
Protocolo de Consumación en dos Fases
Este protocolo se convierte en un protocolo de consumación en dos fases anidados en dos niveles. En la primera fase el coordinador envía el mensaje "¿puedo consumar?'' a los trabajadores que lo pasan a los otros gestores de replicas y recogen sus respuestas antes de responder al coordinador. En la segunda fase, el coordinador envía la solicitud "consuma o aborta'', que se pasa a los miembros de los grupos de los gestores de réplicas.
Replicación de Copia Primaria
La replicación de copia primaria puede utilizarse en el contexto de transacciones. Para la replicación de copia primaria se aplica el control de concurrencia sobre el primario. Este método de replicación, permite a un gestor de réplicas de respaldo reemplazar al primario de forma consistente si este falla.
Uno lee/Todos escriben
Toda operación de escribe debe realizarse en todos los gestores de réplicas, los cuales establecen un bloqueo de escritura sobre el objeto al que afecta la operación. La operación de lee se realiza por único gestor de
réplicas, que establece un bloqueo de lectura sobre el objeto al que afecta la operación.
Replicación de Copias Disponibles
Este esquema de copia disponibles se diseña para permitir que algunos de los gestores de réplicas no estén disponibles durante un tiempo. La estrategia consiste en que una petición lee por parte de un cliente sobre un objeto lógico puede ser realizada por cualquier gestor de réplicas disponible, pero la petición de actualización por parte de un cliente debe ser realizada por todos los gestores de réplicas disponibles en el grupo que tengan copias del objeto.
Normalmente, las peticiones de los clientes son recibidas y realizadas por un gestor de réplicas en funcionamiento. Las peticiones lee pueden ser realizadas por parte del gestor de réplicas que las recibe. Las peticiones escribe son realizadas por el gestor de réplicas que las recibe y por todos los gestores de réplicas disponibles en el grupo.
Fallo de un Gestor de Réplicas
Un gestor de réplicas caído es reemplazado por un nuevo proceso, que recupera el estado consumado de los objetos desde un archivo de recuperación. Cuando un usuario realiza una petición a un gestor de réplicas caído, el realiza un timeouts reintentando la petición en otro gestor de réplicas del grupo, si éste recibe la petición donde el objeto está fuera de su fase, significa que no se ha recuperado totalmente de un fallo rechazando la petición, luego el frontal reintenta la petición en otro gestor de réplicas del grupo.
La secuenciabilidad de una copia necesita que las caídas y recuperaciones sean secuenciadas de acuerdo a las transacciones. Esta no se consigue cuando transacciones diferentes realizan observaciones sobre fallos que entran en conflicto.
Las operaciones escribe están orientadas a todas las copias disponibles, el control de concurrencia local asegura que las escrituras que entren en conflicto sobre un conjunto están secuenciadas. Una operación lee por parte de una transacción y una escribe por parte de otra requieren control de concurrencia adicional (validación local) para evitar las dependencias que formen un ciclo, entre una y otra operación.
Validación local
Diseñado para asegurar que no ocurra ningún evento asociado a un fallo o a una recuperación durante el desarrollo de una transacción (secuencias incompatibles).
Cuando una transacción observa un fallo, este procedimiento trata de comunicarse con los gestores de réplicas fallidos para confirmar de que no se han recuperado.
Los algoritmos para copias disponibles no pueden utilizarse en entorno en los cuales los gestores de replicas que están operando son incapaces de comunicarse entre ellos.
1.5.3. Particiones en la Red
Una partición en la red divide al grupo de gestores de réplicas en dos o mas subgrupos de manera que los miembros de cada subgrupo se comuniquen entre ellos siendo imposible la comunicación entre los miembros de distintos subgrupos.
Los gestores de réplicas dentro de una partición deben asegurar que las peticiones que ejecuten no harán inconsistentes al conjunto de réplicas cuando se repare la partición.
En lo que respecta a la probabilidad de que ocurran inconsistencias existen dos esquemas: el optimista y el pesimista.
Los esquemas optimistas permiten las actualizaciones en todas las particiones, lo que a su vez llevaría a inconsistencia entre éstas, las que han de resolverse cuando se repare la partición.
La aproximación pesimista reduce la disponibilidad incluso cuando no
hay particiones pero evitando las inconsistencias que ocurren mientras existen particiones. Al repararse la partición lo único que se realiza es la actualización de copias de los objetos.
1.5.4. Copias Disponibles con Validación
Es una aproximación optimista que mantiene el nivel normal de disponibilidad para las operaciones lee, validando las transacciones que pudiesen estar en conflicto y que tuvieron lugar dentro de las particiones separadas. Si fallase, se debe dar lugar a ciertos pasos para salvar las inconsistencias, y si no hubiese partición alguna, se retrasa o aborta una de las transacciones de un par que entró en conflicto. Como no hubo partición, al par de transacciones en conflicto se les permiten consumarse en particiones diferentes, siendo la única solución el aborto de una de ellas. Esto implica cambios en los objetos o la compensación de sus efectos en el mundo real.
La aproximación optimista es factible solo en aplicaciones donde se realizan acciones compensatorias.
1.5.5. Métodos de Consenso con Quórum
Para evitar resultados inconsistentes en las transacciones se establece una norma, de tal forma que las operaciones se lleven a cabo dentro de una de las particiones.
Un quórum es un subgrupo de gestores de réplicas autorizado a efectuar operaciones.
En este esquema una operación de actualización de un objeto lógico se completa con éxito por un subgrupo de su grupo de gestores de réplicas, los otros miembros del grupo tendrán copias desfasadas del objeto.
Cada copia de un objeto tiene un número de versión, pero solo las copias actualizadas tienen el número de versión actual, mientras que las desfasadas
tienen números de versión anteriores. Las operaciones se aplican a las que tienen el número de versión actual.
Para realizar una operación lee se recoge un quórum de lectura indagando los números de versión. La operación de lectura puede aplicarse a cualquier copia actualizada.
En el caso de una operación escribe se procede de la misma manera que en una operación lee.
Las actualizaciones especificadas en la operación escribe son aplicadas por cada gestor de réplicas en el quórum de escritura.
Configurabilidad de los grupos de gestores de réplicas
Los grupos de gestores de réplicas se configuran para proporcionar características distintas de rendimiento y fiabilidad. Una vez establecidos, la fiabilidad y el rendimiento de las operaciones escribe pueden aumentarse disminuyendo las operaciones de lee.
El algoritmo permite la copia de archivos en servidores o en discos locales en los computadores de los clientes considerados como representantes débiles, los cuales pueden ser utilizados para acelerar las operaciones lee.
1.5.6. El Algoritmo de la Partición Virtual
Este algoritmo combina la aproximación del consenso con quórum con el algoritmo de copias disponibles. La primera funciona perfectamente en presencia de particiones, mientras que la otra técnica es menos costosa para las operaciones lee.
Una partición virtual es una abstracción de una partición real que contiene un conjunto de gestores de réplicas. Una partición virtual se refiere a las partes en sí mismas, pero no conectadas mediante multidifusión.
Una transacción opera en una partición virtual si contiene gestores de réplicas para tener un quórum de lectura y uno de escritura para los objetos a los que accede (se utiliza el algoritmo de copias disponibles). Si un gestor de réplicas falla y la partición virtual cambia a lo largo de una transacción, dicha transacción aborta asegurando la secuenciabilidad de una copia. Al crearse una nueva partición virtual durante una transacción que realizó una operación en uno de los gestores de réplicas la transacción debe ser abortada. Las réplicas dentro de una nueva partición virtual se actualizan copiándolas desde otras réplicas. Todas las réplicas deben estar actualizadas porque las operaciones de lee se realizan en cualquier réplica individual.
Implementación de las particiones virtuales
Una partición virtual tiene un tiempo de creación, un conjunto de miembros potenciales y miembros reales. Los tiempos de creación son marcas temporales lógicas, los miembros reales comparten la idea en lo que respecta a su tiempo de creación y a su pertenencia.
La creación de una nueva partición virtual se consigue mediante un protocolo cooperativo efectuado por los miembros potenciales accesibles por los gestores de réplicas que lo inicien.
Lo que propone el protocolo es la creación de nuevas particiones virtuales de modo consistente, este protocolo tiene dos fases:
Fase 1:
* El iniciador manda una petición Unirse a cada miembro potencial.
* Cuando un gestor de réplicas recibe una petición de Unirse compara la marca temporal lógica con la de su partición virtual actual.
- Si la marca temporal lógica es mayor accede a la unión y contesta Sí.
- Si es menor, la rechaza y contesta No.
Fase2:
* Si el iniciador recibió un número de respuestas Sí como para tener quórum para escritura y de lectura, se puede completar la creación de la nueva partición virtual mediante el envío de mensajes de Confirmación a los sitios
que acceden a unirse. La marca temporal de creación y la lista de los miembros actuales se los envía como argumentos.
* Los gestores de réplicas que reciben el mensaje de Confirmación se unen a la nueva partición virtual y graban su marca temporal de creación y la lista de los miembros actuales.
1.6.0. Conclusión
Desde el punto de vista de los sistemas distribuidos y la computación móvil la replicación de objetos es un medio para conseguir servicios con un buen rendimiento, alta disponibilidad y tolerancia a fallos. Se describieron arquitecturas para servicios en los cuales los gestores de réplicas almacenan las copias de los objetos, y en los cuales los frontales hacen trasparente la replicación.
Mediante el estudio de servicios de alta disponibilidad (sistema Cotilla, Coda, Bayou), los gestores de réplicas pueden realizar actualizaciones sobre réplicas locales, intercambiar dichas actualizaciones para conseguir una alta disponibilidad en los servicios.
REFERENCIAS
SISTEMAS DISTRIBUIDOS 3º EDICION COULOURIS DOLLINES Y KOOPERS.
INTERNET: PAGINAS DE E.T.S.E. TELECOMUNICACION. CURSO 02/03 SOBRE SISTEMAS OPERATIVOS DISTRIBUIDOS Y DE TIEMPO REAL.
Número de visitantes actuales disponible desde el 14/07/2002:
Autor: lrmdavid@exa.unne.edu.ar
Ó FACENA - http://exa.unne.edu.ar
Servicios WEB: webmaster@exa.unne.edu.ar