Usuario:Alvaro517/Taller

La replicación ​ es una técnica utilizada en informática que consiste en mantener copias de datos en varias máquinas. La replicación juega un papel fundamental en los sistemas distribuidos, ya que proporciona mejor rendimiento, aumento de la disponibilidad y tolerancia a fallos. La replicación es muy utilizada, por ejemplo, en servidores web o en el sistema de nombres de dominio (DNS).

Motivaciones

La replicación es una técnica para mejorar los servicios. Las motivaciones para usarla son:

Mejora de rendimiento

Se basa en la utilización de memoria cache. Almacenan en cachés los recursos obtenidos de peticiones previas recientes, evitando el tiempo de latencia de recuperar los datos de nuevo del servidor origen. La replicación de datos inmutables es trivial, aumentando el rendimiento con un coste bajo para el sistema. Mientras que la replicación de datos cambiantes, como pueden ser los de la Web, se topa con la dificultad de lidiar con protocolos que buscan que los usuarios obtengan datos actualizados, lo que limita la efectividad de la mejora del rendimiento.

Aumento de disponibilidad

Los usuarios quieren que los servicios tengan una alta disponibilidad, esto es, que la proporción de tiempo que un servicio está accesible con un tiempo de respuesta razonable sea próxima al 100%. Los factores que afectan a la disponibilidad son: Fallos en los servidores: la replicación es una técnica que mantiene automáticamente la disponibilidad de datos a pesar de los fallos del servidor. Si los datos son replicados en dos o más servidores, entonces el software del cliente puede tener acceso a los datos de un servidor alternativo en caso de que el servidor predeterminado falle o esté inaccesible. Particiones de red o desconexiones: este es el segundo factor que afecta negativamente a la disponibilidad. Los usuarios móviles pueden desconectarse deliberada o involuntariamente de una red inalámbrica a medida que se mueven, incluso permanecer un tiempo desconectados. A veces, para poder trabajar en estas circunstancias el usuario se prepara copiando datos que sean utilizados frecuentemente. Pero durante la desconexión esos datos pueden haber sido actualizados por un tercero. Por tanto, esto solo es posible si el usuario o la aplicación son capaces de resolver posteriormente cualquier conflicto que surja.

Tolerancia a fallos

Los datos de alta disponibilidad no tienen por qué ser correctos. Pueden estar desactualizados, o puede haber un conflicto en la actualización por parte de dos usuarios y debe resolverse (concurrencia). Un servicio tolerante a fallos siempre garantiza un comportamiento correcto a pesar de que se produzcan cierto número y tipo de fallos. Para aumentar la tolerancia a fallos se utiliza la misma técnica que para la alta disponibilidad, replicar datos entre máquinas. Si fallan n de n + 1 servidores, queda al menos uno para suministrar el servicio. En caso de que sean fallos bizantinos, serán necesarios 2n + 1 servidores, donde n es el número de servidores con fallos de este tipo.

Requisitos

Transparencia

Los clientes no deben tener en cuenta que existen varias copias físicas de los datos. En lo que respecta a los clientes, los datos se organizan como objetos lógicos individuales e identifican solo un elemento en cada caso cuando solicitan que se realice una determinada operación.

Consistencia

Las operaciones realizadas en una colección de objetos replicados deben producir resultados que cumplan con los criterios de corrección especificados para esos objetos.

Modelo de sistema

Los datos de un sistema distribuido se almacenan en forma de colecciones de elementos que reciben el nombre de objetos. Un objeto podría ser por ejemplo un archivo o un objeto Java. Por otro lado, un objeto lógico constituye una entidad de información accesible para el cliente, se implementa mediante una colección de copias físicas llamadas réplicas. Las réplicas son objetos físicos, cada una almacenada en una sola máquina. Las réplicas de un objeto no tienen por qué ser idénticas, al menos no en un determinado momento del tiempo, algunas pueden actualizarse antes que otras.

Componentes

Suponiendo un sistema asíncrono, en el que los procesos solo fallan por caídas y en el que no existen particiones de red. Podemos tener un modelo de arquitectura básico en el que encontraremos los siguientes elementos:

• Gestor de réplicas: contienen las réplicas en una máquina determinada y realizan operaciones sobre ellas directamente. Este modelo puede aplicarse en una arquitectura cliente-servidor, en cuyo caso el gestor de réplicas sería un servidor. Siempre exigiremos que un gestor de réplicas aplique operaciones a sus réplicas de manera recuperable, lo que permite solucionar situaciones de datos inconsistentes.
• Frontal (front end): manejan las peticiones de los clientes. La función del frontal es la comunicación mediante paso de mensajes con uno o más gestores de réplicas, evitando hacer esta tarea al cliente. Es la forma de hacer que la replicación sea transparente.

Fases de petición sobre objetos replicados

Las operaciones que se realizan en cada fase varían dependiendo del tipo de sistema. De un modo general distinguiremos cinco fases en el proceso de petición de un objeto replicado:

1. Petición: el frontal emite la solicitud a uno o más gestores de réplicas. O bien el frontal se comunica con un gestor de réplicas y éste se comunica con otros gestores, o el frontal multidifunde la petición a varios gestores de réplicas.
2. Coordinación: los gestores de réplicas se coordinan para preparar la ejecución de la solicitud de manera consistente. Evalúan si se aplica o no la petición. Los gestores también deben decidir en qué orden han de atenderse las peticiones, existen tres ordenamientos:
   • Ordenación FIFO: si un frontal emite una petición r y después una petición r’, cualquier gestor de réplicas correcto que atienda r’, atenderá r antes. Es la que utilizan la mayoría de aplicaciones.
   • Ordenación causal: si el problema de la petición r era anterior al problema de la petición r’, entonces cualquier gestor de réplicas correcto que atienda r’, atenderá r antes.
   • Ordenación total: si un gestor de réplicas correcto atiende r antes de pedir r’, entonces cualquier gestor correcto que atienda r’ atiende r antes.
3. Ejecución: los gestores de réplicas ejecutan la petición de forma tentativa, de tal modo que se puedan deshacer sus efectos más adelante.
4. Acuerdo: los gestores de réplicas alcanzan un consenso sobre el efecto de la petición, que será comprometida. Es decir, en este punto, los gestores de réplicas acuerdan colectivamente si abortar o confirmar la transacción.
5. Respuesta: inicialmente uno o más gestores responden. En algunos casos un solo gestor responde, en otros, el frontal recibe respuestas de diversos gestores y selecciona una única respuesta para devolverla al cliente. Por ejemplo, si se busca alta disponibilidad, el frontal podría devolver al cliente la primera respuesta, mientras que si lo que se busca es Tolerancia a faltas bizantinas, el frontal devolverá la respuesta que brinden la mayoría de los gestores.

El papel de la comunicación grupal

En un servicio que gestiona datos replicados, los usuarios pueden agregar o retirar un gestor de réplicas, o un gestor de réplicas puede bloquearse y, por tanto, debe ser retirado de la operación del sistema. Es importante una gestión adecuada de las membresías del grupo que conforman los diferentes procesos dentro del sistema distribuido.

Los sistemas que pueden adaptarse a medida que los procesos se unen, abandonan o se caen, en particular los sistemas tolerantes a fallos requieren de las funcionalidades más avanzadas de detección de fallos y notificación de cambios de membresía.

Un servicio de membresía de grupo completo mantiene vistas de grupo, que son listas de los miembros del grupo actual, identificados por sus identificadores de proceso únicos. La lista está ordenada, por ejemplo, en base a la secuencia en la que los miembros se unieron al grupo. Se genera una nueva vista de grupo cada vez que se agrega o excluye un proceso.

Cuando se producen cambios en una vista, los procesos deben poder gestionar esta información cumpliendo tres requisitos: orden, integridad y no trivialidad.

• Orden: sirve para darle al programador una garantía de consistencia al garantizar que los cambios en la vista siempre ocurran en el mismo orden en diferentes procesos.
• Integridad: es un control de validez.
• No trivialidad: es un seguro contra soluciones triviales. Establece que, si dos procesos que se han unido al mismo grupo pueden eventualmente comunicarse de manera indefinida, entonces deben considerarse miembros de ese mismo grupo.

Sistema de comunicación grupal de vista síncrona

Este sistema de comunicación ofrece garantías adicionales a las anteriores sobre el orden de entrega de notificaciones de vista con respecto a la entrega de mensajes de multidifusión. Garantías añadidas de este sistema:

• Acuerdo: los procesos correctos entregan la misma secuencia de vistas y el mismo conjunto de mensajes en una vista determinada.
• Integridad: si un proceso correcto p entrega el mensaje m, entonces no entregará m nuevamente.
• Validez: los procesos correctos siempre entregan los mensajes que envían.

Servicios tolerantes a fallos

Deben proporcionar un servicio correcto a pesar de la existencia de fallos un determinado número de procesos, a través del uso de replicación y funcionalidad de los gestores de réplicas. Un servicio con replicación es correcto siempre que responda adecuadamente a pesar de la existencia de fallos y sin que los clientes puedan percibir si se trata de un sistema con datos replicados o no (transparencia).

Criterios de correción

Debemos entender qué se entiende por comportamiento correcto cuando hablamos de un sistema con replicación, existen dos criterios para determinar el grado de corrección: linealizabilidad y consistencia secuencial.

Linealizabilidad

Se dice que un servicio es linealizable si para alguna secuencia de operaciones, hay una serie de operaciones que se intercalan emitidas por todos los clientes que satisfacen dos condiciones:

• La secuencia de operaciones intercalada cumple la especificación de una copia única correcta de los objetos.
• El orden de las operaciones en el intercalado es consistente con los tiempos reales en que se produjeron las operaciones en la ejecución real.

Consistencia secuencial

Se dice que un servicio es consistente secuencialmente si para alguna de las posibles secuencias de operaciones, hay una serie de operaciones que se intercalan emitidas por todos los clientes que satisfacen las condiciones:

• La secuencia de operaciones intercalada cumple la especificación de una copia única correcta de los objetos.
• El orden de las operaciones en el intercalado es consistente con el orden del programa en el que cada cliente individual las ejecutó.

Podemos decir que cualquier servicio linealizable es también consistente secuencialmente, ya que el orden de la ejecución refleja el orden del programa. Pero no podemos decir que un servicio consistente secuencialmente sea linealizable. Lamport utilizó los criterios consistencia secuencial [1979] y linealizabilidad [1986] en relación con los registros de memoria compartida, aunque utilizó el término atomicidad en lugar de linealizabilidad.

Modelos

Replicación pasiva

En este modelo hay un solo gestor de réplicas principal o primario y uno o más gestores secundarios o esclavos. Los frontales se comunican solo con el gestor de réplicas principal para obtener el servicio. El gestor principal ejecuta las operaciones y envía copias de los datos actualizados a los esclavos. Si el primero falla, se promueve que uno de los esclavos actúe como principal. Fases de petición de operación:

1. Petición:el frontal emite la petición, que contiene un identificador único al gestor principal.
2. Coordinación: el gestor principal toma cada petición de forma atómica, en el orden en el que las recibe. Verifica el identificador único, en caso de que ya haya atendido esa petición, reenvía automáticamente la respuesta.
3. Ejecución: el primario ejecuta la solicitud y almacena la respuesta.
4. Acuerdo: si la petición es una actualización, entonces el primario reenvía a todos los secundarios el estado de actualización, la respuesta y el identificador único. Los secundarios envían un acuso de recibo al principal.
5. Respuesta: el primario responde al frontal, que se encarga de devolver la respuesta al cliente.

Este sistema es linealizable si el primario es correcto, ya que las secuencias primarias realizan todas las operaciones sobre los objetos compartidos. Si el primario falla, entonces el sistema conserva la capacidad de linealizabilidad si un solo secundario se convierte en el nuevo primario y si la nueva configuración del sistema toma el control exactamente donde lo dejó la última. Por tanto, también podemos decir que es consistente secuencialmente. Algunas ventajas de este tipo de replicación son: tolera fallos de proceso tanto en el gestor primario como en los secundarios y el frontal requiere de poca funcionalidad. Por otro lado, las desventajas más notables son: no tolera fallos bizantinos y que tiene unos gastos generales relativamente grandes.

Replicación activa

En este modelo de replicación para tolerancia de fallos, los gestores de réplicas son máquinas de estado que desempeñan roles equivalentes y están organizados como un grupo. Los frontales multidifunden las peticiones al grupo de gestores y todos procesan la petición de forma independiente pero idéntica y emiten una respuesta. Si cualquier gestor falla no debe repercutir en el rendimiento del servicio, ya que los demás gestores responderán. La replicación activa tolera fallos bizantinos, porque el frontal puede recopilar y comparar las respuestas que recibe. Fases de petición de operación:

1. Petición: el frontal adjunta un identificador único a la petición y lo envía al grupo de gestores, utilizando una multidifusión fiable y de ordenación total. Si el frontal fallara debido a una caída, no emite más peticiones hasta que no haya recibido una respuesta.
2. Coordinación: el sistema de comunicación en grupo entrega la petición a cada gestor de réplicas correcto en el mismo orden (ordenación total).
3. Ejecución: cada gestor de réplicas ejecuta la petición. Dado que son máquinas de estado y que las peticiones se entregan en base a una ordenación total, los gestores correctos procesan la petición de manera idéntica. La respuesta contiene el identificador único de petición del cliente.
4. Acuerdo: no se necesita una fase de acuerdo, debido a la semántica de entrega de multidifusión
5. Respueta: cada gestor de réplicas envía su respuesta al frontal. El número de respuestas que recopila el frontal depende de los fallos que se produzcan y del algoritmo de difusión. Si el objetivo es tolerar solo los fallos por caídas y la multidifusión satisface las propiedades de fiabilidad y ordenación, entonces el frontal envía la primera respuesta en llegar al cliente y descarta el resto.

El sistema cumple el requisito de consistencia secuencial. La fiabilidad de la multidifusión garantiza que cada gestor de réplicas correcto procese la misma secuencia de peticiones y la ordenación total garantiza que se procesan en el mismo orden. Las solicitudes de cada frontal se atienden en orden FIFO (debido a que el frontal espera una respuesta antes de procesar la siguiente petición), esto es, “orden de programa”, lo que asegura la consistencia secuencial. El modelo de replicación activa no cumple el requisito de linealizabilidad. Debido a que el orden en el que los gestores de réplicas procesan las peticiones no es necesariamente el mismo que los clientes las realizaron.

Servicios de alta disponibilidad

El objetivo es dar servicio a los clientes, con tiempos de respuesta razonables, durante el mayor tiempo posible, aunque los resultados no sean consistentes secuencialmente, esto es, buscar una alta disponibilidad del servicio. Al contrario de lo que ocurre en los sistemas tolerantes a fallos, en los cuales los gestores de réplicas se comunican de forma colectiva para llegar a un acuerdo antes de remitir la respuesta al cliente, en sistemas de alta disponibilidad, el sistema debe proporcionar un nivel de servicio aceptable utilizando un conjunto mínimo de gestores de réplicas conectados al cliente. Y debe minimizar el tiempo que el cliente está esperando mientras los gestores coordinan sus operaciones. Cuanto menor sea grado de consistencia, generalmente, se requiere menos acuerdo y, por tanto, permiten que los datos compartidos estén más disponibles. Ejemplos de diseño de sistemas que proporcionan servicios altamente disponibles son: la arquitectura cotilla, el sistema Bayou y el sistema de archivos Coda.

Arquitectura cotilla

La arquitectura cotilla ​ es un marco o protocolo para implementar servicios altamente disponibles al replicar datos cerca de los puntos donde los clientes lo necesitan. El nombre se debe a que los gestores de réplicas intercambian mensajes de “cotilleo” periódicamente para transmitir las actualizaciones que han recibido de los clientes. Un servicio cotilla permite dos tipos básicos de operación: las consultas, que son operaciones de solo lectura, y las actualizaciones que modifican, pero no leen el estado. Un factor importante es que los frontales envían peticiones y actualizaciones a cualquier gestor de réplicas que elijan, siempre que esté disponible y pueda proporcionar tiempos de espera razonables.

Garantías de esta arquitectura

El sistema ofrece dos garantías, aunque los gestores de réplicas no puedan comunicarse temporalmente entre sí:

• Cada cliente obtiene un servicio consistente en el tiempo: en respuesta a una consulta, los gestores de réplicas solo proporcionan al cliente datos que reflejen al menos las actualizaciones que el cliente ha observado hasta ahora. Esto ocurre a pesar de que los clientes pueden comunicarse con diferentes gestores de réplicas en diferentes momentos y, por tanto, podrían comunicarse con un gestor que está menos actualizado que el que usaron anteriormente.
• Consistencia relajada entre réplicas: todos los gestores de réplicas finalmente reciben todas las actualizaciones y las aplican con garantías de ordenación que hacen que las réplicas sean lo suficientemente similares para satisfacer las necesidades de la aplicación.

Proceso de petición y operanciones de actualización

1. Petición: el frontal normalmente envía peticiones a un solo gestor de réplicas a la vez. Sin embargo, un frontal se comunicará con otro gestor diferente cuando el que usa normalmente falla o se vuelve inalcanzable. Los frontales y por tanto los clientes pueden quedarse bloqueados por peticiones de consulta. Para las peticiones de actualización, el cliente continúa una vez la petición haya pasado al frontal y éste se encarga de propagar la operación en segundo plano.
2. Respuesta a actualización: si la petición es una actualización, entonces el gestor de réplicas responde tan pronto como recibe la actualización.
3. Coordinación: el gestor de réplicas que recibe una petición no la procesa hasta que no puede aplicar las restricciones de orden requeridas. Esto puede implicar recibir actualizaciones de otros gestores en mensajes de “cotilleo”. No existe otra coordinación entre gestores.
4. Ejecución: el gestor de réplicas ejecuta la petición.
5. Respuesta a consulta: si la petición es una consulta, entonces el gestor responde en este momento.
6. Acuerdo: los gestores se actualizan mutuamente intercambiando mensajes de “cotilleo” que contienen las actualizaciones más recientes que han recibido. Se dice que se actualizan mutuamente de manera perezosa, ya que los mensajes de chismes se pueden intercambiar solo ocasionalmente.

Marcas temporales

Con el fin de controlar el orden de procesamiento de la operación, cada frontal mantiene un vector de marcas temporales que refleja la versión de los últimos valores de datos a los que se accedió por el frontal y, por tanto, a los que accedió el cliente. Este vector contiene una entrada para cada gestor de réplicas. El frontal envía el vector en cada petición al gestor junto con una descripción de la consulta o la actualización. Cuando un gestor devuelve un valor como resultado de una consulta, proporciona una nueva marca temporal al vector, ya que las réplicas pueden haberse actualizado desde la última operación. De manera similar, una actualización devuelve un vector de marcas temporales que es único para la actualización. Cada marca temporal devuelta es combinada con la marca temporal anterior del frontal para registrar la versión que ha sido observada por el cliente. Dado que la comunicación de cliente a cliente también puede llevar a relaciones causales entre las operaciones aplicadas al servicio, se intercambian mensajes de “cotilleo” entre los gestores y entre los propios frontales fusionando sus marcas temporales para que las relaciones causales puedan inferirse correctamente.

Operaciones de consulta

Es el tipo de operación más sencilla. Como ya se ha mencionado, una petición de consulta contiene una descripción de la operación y una marca temporal enviada por el frontal. Este último refleja la última versión del valor que el frontal ha leído o enviado como una actualización. Por tanto, la tarea del gestor de réplicas es devolver un valor que sea al menos tan reciente como éste. El gestor mantiene la consulta en una lista de operaciones de consulta pendientes hasta que se cumpla la condición necesaria. Puede esperar las actualizaciones restantes, que llegarán en mensajes de “cotilleo” o solicitar las actualizaciones de los gestores correspondientes. Una vez que se puede aplicar la consulta, el gestor de réplicas devuelve el nuevo valor de la marca temporal, el frontal tendrá que combinar este valor con su marca temporal.

Mensajes de cotilleo

Los gestores de réplicas envían mensajes de “cotilleo” que contienen información sobre una o más actualizaciones para que otros gestores puedan actualizar su estado. Un gestor usa las marcas temporales para estimar qué actualizaciones aún no ha recibido otro administrador de réplicas. Un mensaje de “cotilleo” consta de dos elementos enviados por el gestor origen: su registro y su marca de tiempo de réplica. El gestor de réplicas que recibe un mensaje de “cotilleo” tiene tres tareas principales:

1. Fusionar el registro de llegada con el suyo propio.
2. Aplicar cualquier actualización que se haya estabilizado y no se haya ejecutado anteriormente.
3. Eliminar registros del registro y entradas en la tabla de operaciones ejecutadas cuando se sabe que las actualizaciones se han aplicado en todas partes y para las cuales no hay peligro de repeticiones.

Sistema Bayou

El sistema Bayou ​ proporciona replicación de datos para una alta disponibilidad con garantías más débiles que la consistencia secuencial, como la arquitectura cotilla. Al igual que en ese tipo de sistemas, los gestores de réplicas de Bayou enfrentan la conectividad variable mediante el intercambio de actualizaciones en pares, en lo que los diseñadores denominan un protocolo anti-entropía. Pero Bayou adopta un enfoque marcadamente diferente, ya que permite la detección y resolución de conflictos específicos de dominio. En Bayou los usuarios pueden realizar las actualizaciones que deseen. Todas las actualizaciones se aplican y se registran en cualquier gestor al que lleguen. Sin embargo, cuando las actualizaciones recibidas en cualquiera de los dos gestores se combinan durante un intercambio antientropía, los gestores de réplicas detectan y resuelven los conflictos. Se puede aplicar cualquier criterio específico de dominio para resolver conflictos entre operaciones. La garantía de Bayou es que, eventualmente, cada gestor recibe el mismo conjunto de actualizaciones y las aplica de tal manera que las bases de datos de los gestores son idénticas. En la práctica, puede haber un flujo continuo de actualizaciones y las bases de datos nunca se vuelvan idénticas, pero se volverían idénticas si las actualizaciones cesaran.

Transformación operacional

Por ejemplo, si un ejecutivo y su asistente han agregado citas en el mismo horario a una agenda, entonces un sistema Bayou lo detecta después de que la ejecutiva haya vuelto a conectar su ordenador portátil. Además, resuelve el conflicto de acuerdo con una política específica de dominio. En este caso, podría, por ejemplo, confirmar la cita del ejecutivo y eliminar la reserva del asistente en la ranura. Este efecto, en el que una o varias operaciones están en conflicto se deshace o altera para resolverlas, se denomina transformación operacional.

Actualizaciones comprometidas y tentativas

Las actualizaciones se marcan como tentativas cuando se aplican por primera vez a una base de datos. Bayou acuerda que las actualizaciones tentativas se colocan finalmente en un orden canónico y se marcan como confirmadas. Si bien las actualizaciones son tentativas, el sistema puede deshacerlas y volverlas a aplicar según sea necesario para generar un estado consistente. Una vez comprometidas, permanecen aplicadas en su orden asignado. En la práctica, la petición comprometida se puede lograr al designar a algún gestor de réplicas como el gestor principal de réplicas. El orden en el que se comprometen puede ser aquel en el que se reciben las actualizaciones tentativas y se propaga esa información de petición a otros gestores. O bien, los usuarios pueden elegir, por ejemplo, una máquina rápida que generalmente está disponible, o el gestor de réplicas en el ordenador de un ejecutivo, si las actualizaciones de ese usuario tienen prioridad.

Verificaciones de dependencia y procedimientos de fusión

Una actualización puede entrar en conflicto con alguna otra operación que ya se ha aplicado. Debido a esta posibilidad, cada actualización de Bayou contiene una verificación de dependencia y un procedimiento de fusión además de la especificación de la operación y los parámetros. Un gestor llama al procedimiento de verificación de dependencia antes de aplicar la operación. Comprueba si puede haber un conflicto si se aplicara la actualización. Si la verificación de dependencia indica un conflicto, Bayou invoca el procedimiento de fusión de la operación. Ese procedimiento altera la operación para que logre un resultado similar, pero evitando el conflicto. El procedimiento de fusión puede no encontrar una alteración adecuada de la operación, en ese caso indica un error.

Sistema de archivos Coda

El sistema de archivos Coda es un descendiente de AFS (Andrew File System) que tiene como objetivo abordar varios requisitos que AFS no cumple, especialmente el de proporcionar alta disponibilidad a pesar de las desconexiones. Los requisitos de diseño para Coda se derivan de la experiencia con AFS en sistemas distribuidos a gran escala. Si bien el rendimiento y la facilidad de administración de AFS eran satisfactorios, se consideró que la forma limitad de replicación ofrecida por AFS debía convertirse en un factor limitante a cierta escala, especialmente para acceder a archivos ampliamente compartidos. Además, estaba surgiendo un modo de uso que AFS no atendía: el uso móvil de ordenadores portátiles. Coda trata de cumplir con estos requisitos bajo el encabezado general de disponibilidad constante de datos. El objetivo era proporcionar a los usuarios los beneficios de un repositorio de archivos compartido, pero permitirles confiar plenamente en los recursos locales cuando el repositorio es parcial o totalmente inaccesible. Además de estos objetivos, Coda conserva los objetivos originales de AFS con respecto a la escalabilidad y la emulación de la semántica de archivos UNIX. A diferencia de AFS, donde los volúmenes de lectura y escritura se almacenan en un solo servidor, el diseño de Coda se basa en la replicación de volúmenes de archivos para lograr un rendimiento más alto de las operaciones de acceso a archivos y un mayor grado de tolerancia a fallos. Coda es como Bayou en la medida en que sigue una estrategia optimista. Es decir, permite a los clientes actualizar los datos mientras el sistema está particionado, sobre la base de que los conflictos son relativamente poco probables y que pueden solucionarse si ocurren.

Transacciones con datos replicados

Las transacciones son secuencias de una o más operaciones, aplicadas de tal manera que se aplican las propiedades ACID. Los objetos en sistemas transaccionales pueden replicarse para aumentar la disponibilidad y el rendimiento. Desde el punto de vista de un cliente, una transacción en objetos replicados debe aparecer igual que una con objetos no replicados. Por otro lado, el efecto de las transacciones realizadas por los clientes en los objetos replicados debe ser el mismo que si se hubieran realizado una a la vez en un solo conjunto de objetos.

Esquemas de replicación

Los siguientes esquemas funcionan correctamente cuando la colección de gestores de réplicas se divide en subgrupos por una partición de red:

1. Copias disponibles con validación: la replicación de copias disponibles se aplica en cada partición. Cuando se repara una partición, se aplica un procedimiento de validación y se resuelven las inconsistencias.
2. Consenso por quórum: un subgrupo debe tener un quórum para que se le permita continuar brindando un servicio en presencia de una partición. Cuando se repara una partición (y cuando un gestor se reinicia después de un fallo o caída), los gestores actualizan sus objetos mediante procedimientos de recuperación.
3. Partición virtual: una combinación de consenso de quórum y copias disponibles. Si una partición virtual tiene un quórum, puede usar la replicación de copias disponibles.

Arquitecturas para transacciones replicadas

Asumimos que un frontal envía solicitudes de clientes a uno de los grupos de gestores de réplicas de un objeto lógico. En el caso de replicación de copia primaria, todas las partes frontales se comunican con un gestor primario distinguido para realizar una operación, y ese gestor mantiene copias de seguridad actualizadas. Existen dos estrategias de difusión de la operación:

• Estrategia exhaustiva: difunde a todas las réplicas en cuanto se produce la operación, antes de comprometerla y retornar al cliente
• Estrategia perezosa: se reduce el número de réplicas que reciben antes de comprometer, difundiendo al resto más tarde

Los diferentes esquemas de replicación tienen diferentes reglas en cuanto a cuántos de los gestores de réplicas en un grupo son necesarios para la finalización exitosa de una operación.

Protocolo de confirmación de dos fases

El protocolo de confirmación de dos fases se convierte en un protocolo de confirmación de dos fases anidado de dos niveles. Como antes, el coordinador de una transacción se comunica con los compañeros. Pero si el coordinador o un compañero es un gestor de réplicas, se comunicará con los otros gestores a los que pasó las solicitudes durante la transacción. En la primera fase, el coordinador envía una petición de confirmación a los compañeros, que la pasan a los otros gestores y recopilan sus respuestas antes de responder al coordinador. En la segunda fase, el coordinador envía la solicitud “comprometer” o “abortar”, que se transmite a los miembros de los grupos de gestores.

Replicación de copia primaria

En este esquema, todas las peticiones de los clientes se dirigen a un único gestor primario. Para la replicación de copia primaria, el control de concurrencia se aplica en el primario. Para confirmar una transacción, el principal se comunica con los gestores de respaldo y luego, responde al cliente. Este esquema permite que un gestor de respaldo asuma el control de manera consistente si falla el primario.

Uno lee, todos escriben

Sistema de replicación simple en el que las operaciones de lectura las realiza un solo gestor de réplicas y todos hacen operaciones de escritura. Este esquema de replicación permite usar el bloqueo de dos fases en cada gestor para lograr la serializabilidad de una copia, donde los frontales pueden comunicarse con cualquier gestor. Cada operación de escritura debe realizarse en todos los administradores de réplica, cada uno de los cuales establece un bloqueo de escritura en el objeto afectado por la operación. Cada operación de lectura es realizada por un solo administrador de réplicas, que establece un bloqueo de lectura en el objeto afectado por la operación. Considerando pares de operaciones de diferentes transacciones en el mismo objeto: cualquier par de operaciones de escritura requerirá bloqueos conflictivos en todos los gestores, mientras que una operación de lectura y una operación de escritura requerirán bloqueos conflictivos en un solo gestor. De este modo se logra la seriabilidad de una copia.