Replicación (informática)

La replicación se usa mucho en sistema de acceso a datos por varios motivos:

• Rendimiento: El rendimiento es mejorado mediante el uso de cachés en clientes o servidores. El uso de cachés permite mantener copias de los resultados obtenidos en llamadas anteriores, reduciendo el coste de llamadas idénticas. Por otro lado, normalmente, hay más lectura que escritura en una base de datos, por lo que tener varios nodos solo procesando la lectura puede traer un gran beneficio de rendimiento en una base de datos muy consultada.
• A prueba de fallos: Con la replicación ganamos tolerancia a diferentes tipos de fallos:
  • Fallos en el servidor: Un esclavo estando casi sincrónicamente actualizado puede ser útil en caso de que el nodo maestro caiga, ya que puede reemplazarlo sin detener el servicio.
  • Fallos bizantinos: Si f servidores tienen fallos bizantinos, un sistema con 3f+1 servidores proveería un servicio correcto.
• Fiabilidad: La replicación garantiza que los datos han sido copiados a otro nodo en caso de que el nodo maestro haya sufrido un desperfecto.
• Generación de bloqueos: aunque esta es más precisa, también se puede usar para procesos que necesiten leer datos, generando bloqueos. Al hacerlo sobre un esclavo esto no interviene en el funcionamiento de todo el sistema. Es muy usado para, por ejemplo, hacer copias de seguridad o extraer grandes cantidades de datos para generar estadísticas.
• Alta disponibilidad: La proporción de tiempo que el servicio está accesible con tiempos de respuesta razonables es cercana al 100%. Sin embargo, puede haber fallos en el servidor o desconexiones de red que hagan que la disponibilidad disminuya.

En estos modelos se asume que los sistemas son asíncronos, que los procesos fallan solo por caída y que no hay peticiones de red.

Todo modelo de replicación tiene dos componentes:

• Gestor de réplicas: Componente que almacena réplicas de un determinado objeto o servicio y opera sobre ellas.
• Frontal (front end): Componente que atiende las llamadas de los clientes y se comunica con los gestores de réplicas.

Ante una petición realizada por el cliente, todos los modelos realizan las siguientes fases:

1. Petición: El frontal envía la petición a un gestor: O bien envía la petición a un gestor y éste reenvía a otros, o multidifunde la petición a varios gestores.
2. Coordinación: Los gestores se coordinan para ejecutar la petición de manera consistente. En este paso puede aplicar diferentes tipos de ordenación:
   • FIFO: Si un frontal solicita la petición r antes que la petición r’, todos los gestores que resuelvan r’ deben hacerlo después de resolver r (ordenación “local”). La mayoría de las aplicaciones sólo requieren una ordenación FIFO.
   • Causal: Si r->r’, entonces todos los gestores resuelven r antes de resolver r.
   • Total: Si un gestor resuelve r antes que r’, todos los gestores resuelven r antes que r’.
3. Ejecución: Se ejecuta la petición (puede ser de forma tentativa).
4. Acuerdo: Se llega a un consenso antes de consumar la ejecución.
5. Respuesta: Uno o más gestores de réplicas responden al frontal.

Servicios tolerantes de fallos

Sistemas que deben proporcionar un servicio correcto aunque fallen f procesos, mediante la replicación de datos y la funcionalidad asociada a los gestores de réplicas. Para ello utilizan un diseño tolerante de fallos. Mediante el uso de este tipo de servicios, el cliente no debe distinguir una ejecución normal de una con fallos.

Replicación Pasiva (Coulouris 2011)

Existen dos principales modelos de servicios tolerantes de fallos:

• Replicación pasiva o primario-respaldo Utiliza la arquitectura maestro-esclavo, en la que se procesa cada solicitud en el gestor de réplicas primario (maestro) y se envía copias del resultado a los gestores secundarios (esclavos). Los frontales actúan de intermediario entre los clientes y el gestor de réplicas primario.
  

  Replicación pasiva http://www.sc.ehu.es/acwlaalm/sdi/3-Replicacion.pdf

En caso de fallar el gestor primario, uno de los secundarios pasa a ocupar su lugar.

Teniendo en cuenta esta estructura, tras una petición de cualquier cliente que llega a un frontal, se pueden distinguir las siguientes fases:

1. Petición: el frontal envía una petición al gestor primario.
2. Coordinación: el gestor primario ejecuta las peticiones siguiendo un esquema de ordenación FIFO (First In, First Out).
3. Ejecución: se ejecuta la petición y se almacena la respuesta.
4. Acuerdo: si es una petición de actualización, el gestor primario envía la actualización a todos los secundarios, que confirman la recepción mediante el uso de mensajes de tipo ACK.
5. Respuesta: el gestor primario responde al frontal. Este sistema de replicación tiene las siguientes características:

• Tolera fallos de proceso (gestor primario o respaldos)
• No tolera fallos bizantinos
• El frontal requiere poca funcionalidad
• Al controlar el orden de modificación mediante el gestor primario, mantiene la consistencia secuencial.
• Problemas de cuello de botella en el gestor primario debido a que la actualización de todos los respaldos antes de dar respuesta y a que los respaldos no dan servicio directo.

• Replicación activa: El cliente realiza una petición que se difunde a través de los frontales a todas las réplicas por igual, las cuales la gestionan de forma concurrente. El cliente se sincroniza con la primera respuesta que obtiene. Mediante el uso de la replicación activa se consigue reducir la latencia aunque, en consecuencia, se requiere de un alto coste para procesar las actualizaciones en todas las réplicas y la comunicación llevada a cabo.

Replicación activa (Coulouris 2011)

Replicación activa http://www.sc.ehu.es/acwlaalm/sdi/3-Replicacion.pdf

Teniendo en cuenta esta estructura, tras una petición de cualquier cliente que llega a un frontal, se pueden distinguir las siguientes fases:

1. Petición: el frontal multidifunde la petición a los gestores haciendo uso de multidifusión fiable y de ordenación total y espera a recibir la correspondiente respuesta antes de continuar enviando las peticiones siguientes.
2. Coordinación: el sistema de comunicación entrega la petición a todos los gestores según una ordenación total (multidifusión).
3. Ejecución: cada gestor ejecuta la petición de forma independiente, aunque idéntica.
4. Respuesta: cada gestor manda su respuesta al frontal. El número de respuestas que recoge el frontal depende de las asunciones de fallo y del algoritmo de multidifusión. El sistema de replicación activa incluye las siguientes características:

• Tolerancia a fallos proveniente del uso de una multidifusión fiable y totalmente ordenada.
• Este tipo de multidifusión es equivalente a un algoritmo de consenso, con lo que así se resuelven los fallos bizantinos. El frontal recoge f+1 respuestas iguales antes de responder al cliente.

Una transacción es una secuencia de una o más operaciones que tienen que ocurrir de manera atómica.

Los objetos en sistemas transaccionales pueden estar replicados, para mejorar la disponibilidad y el rendimiento. El cliente no debe tener conocimiento de la replicación.

Existen diferentes esquemas de replicación

• Replicación de copia primaria: similar a la replicación pasiva.
  • Un gestor primario se encarga de la concurrencia (FIFO).
  • Para consumar una transacción, el primario comunica con las réplicas y después responde al cliente (estrategia exhaustiva). Esto implica un mayor tiempo de respuesta.
  • O bien, responde inmediatamente y realiza las copias en segundo plano (estrategia perezosa). Si el primario cae, el reemplazo puede no tener la última versión.

• Uno lee, todos escriben: Un cliente puede leer de cualquiera de las réplicas, ya que todas están actualizadas.

Por otro lado, un gestor de réplicas escribe y envía al resto la actualización. Cuando todos han realizado dicha actualización, termina la transacción. Es una operación atómica, ya que tiene que escribir en todas las réplicas.

• Consenso por quórum: El cuórum es un subgrupo de gestores de réplicas autorizado a efectuar operaciones.

Ejemplo [Gifford, 1979]: sean n copias de un archivo F:

• Requisito de lectura: Al menos r copias (cuórum de lectura) de F deben ser consultadas.
• Requisito de escritura: Al menos w copias (cuórum de escritura) de F deben ser escritas.
• Restricción: r+w > n (intersección no nula entre r y w). Hay al menos una copia actualizada en cualquier cuórum. Puede haber diferentes tipos de operaciones:
• Operación de lectura: Recuperar un cuórum de lectura (cualquier conjunto de r copias). De las r copias, seleccionar la copia con el número de versión más alto. Retomar el valor de dicha copia.
• Operación de escritura: Tomar un cuórum de escritura (cualquier conjunto de w copias). De las w copias, obtener el número de versión más alto. Incrementar el número de versión. Escribir el nuevo valor y el nuevo número de versión en todas las w copias del cuórum de escritura. Es un esquema diseñado para reducir el número de réplicas que deben ejecutar las actualizaciones. Al coste de incrementar el número de réplicas que deben ejecutar las lecturas.

• Commit de dos fases (2PC): Es un protocolo de consenso distribuido que permite a todos los nodos de un sistema distribuido ponerse de acuerdo para consolidar una transacción. Su objetivo principal es que todos los nodos realicen un commit de la transacción o la aborten.

• AUTORES, VARIOS (2015). «18.Replication». Distributed Systems, Concepts and Design (en inglés) (5ª edición). Pearson. pp. 765-815. ISBN 978-01-3214-301-1.
• Diferencias entre copia de seguridad y replicación
• Sistemas distribuidos (replicación)
• Replicación
• Rodrigo Santamaría. Apuntes Sistemas Distribuidos Universidad de Salamanca. | Tema 8 - Replicación