La replicación en informática implica compartir información para garantizar la coherencia entre recursos redundantes, como componentes de software o hardware , para mejorar la confiabilidad, la tolerancia a fallos o la accesibilidad.
La replicación en informática puede referirse a:
La replicación en el espacio o en el tiempo suele estar vinculada a algoritmos de programación. [1]
El acceso a una entidad replicada es generalmente uniforme, mientras que el acceso a una única entidad no replicada es uniforme. La replicación en sí misma debería ser transparente para un usuario externo. En caso de fallo, la conmutación por error de las réplicas debería ocultarse lo máximo posible en lo que respecta a la calidad del servicio . [2]
Los científicos informáticos describen además la replicación como:
Cuando se designa una réplica líder mediante una elección de líder para procesar todas las solicitudes, el sistema utiliza un esquema de réplica principal-de respaldo o de réplica principal , que predomina en los clústeres de alta disponibilidad . En comparación, si cualquier réplica puede procesar una solicitud y distribuir un nuevo estado, el sistema utiliza un esquema de múltiples maestros o múltiples maestros . En este último caso, se debe utilizar alguna forma de control de concurrencia distribuida , como un administrador de bloqueo distribuido .
El equilibrio de carga se diferencia de la replicación de tareas, ya que distribuye una carga de cálculos diferentes entre las máquinas y permite descartar un único cálculo en caso de falla. Sin embargo, el equilibrio de carga a veces utiliza la replicación de datos (especialmente la replicación multimaestro ) internamente para distribuir sus datos entre las máquinas.
La copia de seguridad se diferencia de la replicación en que la copia guardada de los datos permanece inalterada durante un largo período de tiempo. [3] Las réplicas, por otro lado, se someten a actualizaciones frecuentes y pierden rápidamente cualquier estado histórico. La replicación es uno de los temas más antiguos e importantes en el área general de los sistemas distribuidos .
Tanto la replicación de datos como la replicación computacional requieren procesos para manejar los eventos entrantes. Los procesos para la replicación de datos son pasivos y operan únicamente para mantener los datos almacenados, responder a las solicitudes de lectura y aplicar actualizaciones. La replicación computacional se realiza generalmente para proporcionar tolerancia a fallas y tomar el control de una operación si falla un componente. En ambos casos, las necesidades subyacentes son garantizar que las réplicas vean los mismos eventos en órdenes equivalentes, de modo que permanezcan en estados consistentes y cualquier réplica pueda responder a las consultas.
Existen tres modelos ampliamente citados para la replicación de datos, cada uno con sus propias propiedades y rendimiento:
La replicación de bases de datos se puede utilizar en muchos sistemas de gestión de bases de datos (DBMS), normalmente con una relación de réplica/base de datos principal entre el original y las copias. La base de datos principal registra las actualizaciones, que luego se transmiten a las réplicas. Cada réplica emite un mensaje que indica que ha recibido la actualización correctamente, lo que permite el envío de actualizaciones posteriores.
En la replicación multimaestro , las actualizaciones se pueden enviar a cualquier nodo de base de datos y luego propagarse a otros servidores. Esto suele ser deseable, pero introduce costos y complejidad sustancialmente mayores que pueden hacerlo poco práctico en algunas situaciones. El desafío más común que existe en la replicación multimaestro es la prevención o resolución de conflictos transaccionales . La mayoría de las soluciones de replicación sincrónica (o ansiosa) realizan la prevención de conflictos, mientras que las soluciones asincrónicas (o perezosas) tienen que realizar la resolución de conflictos. Por ejemplo, si el mismo registro se cambia en dos nodos simultáneamente, un sistema de replicación ansiosa detectaría el conflicto antes de confirmar la confirmación y abortaría una de las transacciones. Un sistema de replicación perezosa permitiría que ambas transacciones se confirmen y ejecuten una resolución de conflictos durante la resincronización. [7] La resolución de dicho conflicto puede basarse en una marca de tiempo de la transacción, en la jerarquía de los nodos de origen o en una lógica mucho más compleja, que decide de manera consistente en todos los nodos.
La replicación de bases de datos se vuelve más compleja cuando se escala horizontal y verticalmente. El escalamiento horizontal tiene más réplicas de datos, mientras que el escalamiento vertical tiene réplicas de datos ubicadas a mayores distancias físicas. Los problemas que plantea el escalamiento horizontal se pueden aliviar con un protocolo de acceso multicapa y multivista . Los primeros problemas del escalamiento vertical se han abordado en gran medida mejorando la confiabilidad y el rendimiento de Internet. [8] [9]
Cuando los datos se replican entre servidores de bases de datos, de modo que la información permanece consistente en todo el sistema de base de datos y los usuarios no pueden distinguir o incluso saber qué servidor del DBMS están utilizando, se dice que el sistema exhibe transparencia de replicación.
Sin embargo, no siempre se puede lograr la transparencia de la replicación. Cuando los datos se replican en una base de datos, estarán limitados por el teorema CAP o el teorema PACELC . En el movimiento NoSQL, la consistencia de los datos generalmente se sacrifica a cambio de otras propiedades más deseadas, como la disponibilidad (A), la tolerancia de partición (P), etc. También se han desarrollado varios modelos de consistencia de datos para que sirvan como Acuerdo de Nivel de Servicio (SLA) entre los proveedores de servicios y los usuarios.
La replicación de almacenamiento activa (en tiempo real) se implementa generalmente distribuyendo actualizaciones de un dispositivo de bloque a varios discos duros físicos . De esta manera, cualquier sistema de archivos compatible con el sistema operativo se puede replicar sin modificaciones, ya que el código del sistema de archivos funciona en un nivel superior a la capa del controlador del dispositivo de bloque. Se implementa en hardware (en un controlador de matriz de discos ) o en software (en un controlador de dispositivo ).
El método más básico es la duplicación de discos , que es típica para discos conectados localmente. La industria del almacenamiento limita las definiciones, por lo que la duplicación es una operación local (de corta distancia). Una replicación se puede extender a través de una red informática , de modo que los discos se pueden ubicar en ubicaciones físicamente distantes, y generalmente se aplica el modelo de replicación de base de datos principal/réplica. El propósito de la replicación es evitar daños por fallas o desastres que puedan ocurrir en una ubicación o, en caso de que ocurran tales eventos, mejorar la capacidad de recuperar datos. Para la replicación, la latencia es el factor clave porque determina cuán separados pueden estar los sitios o el tipo de replicación que se puede emplear.
La característica principal de dicha replicación entre sitios es cómo se manejan las operaciones de escritura, a través de replicación asincrónica o sincrónica; la replicación sincrónica necesita esperar la respuesta del servidor de destino en cualquier operación de escritura, mientras que la replicación asincrónica no lo hace.
La replicación sincrónica garantiza una "pérdida de datos cero" mediante operaciones de escritura atómica , donde la operación de escritura no se considera completa hasta que la reconocen tanto el almacenamiento local como el remoto. La mayoría de las aplicaciones esperan a que se complete una transacción de escritura antes de continuar con el trabajo, por lo que el rendimiento general disminuye considerablemente. Inherentemente, el rendimiento disminuye proporcionalmente a la distancia, ya que la latencia mínima está determinada por la velocidad de la luz . Para una distancia de 10 km, el viaje de ida y vuelta más rápido posible demora 67 μs, mientras que una escritura completa en caché local se completa en aproximadamente 10–20 μs.
En la replicación asincrónica , la operación de escritura se considera completa tan pronto como el almacenamiento local la reconoce. El almacenamiento remoto se actualiza con un pequeño retraso . El rendimiento aumenta considerablemente, pero en caso de una falla del almacenamiento local, no se garantiza que el almacenamiento remoto tenga la copia actual de los datos (se pueden perder los datos más recientes).
La replicación semisincrónica generalmente considera que una operación de escritura está completa cuando el almacenamiento local la reconoce y el servidor remoto la recibe o registra. La escritura remota real se realiza de forma asincrónica, lo que genera un mejor rendimiento, pero el almacenamiento remoto se retrasará con respecto al almacenamiento local, por lo que no hay garantía de durabilidad (es decir, transparencia perfecta) en caso de falla del almacenamiento local. [ cita requerida ]
La replicación puntual produce instantáneas periódicas que se replican en lugar del almacenamiento principal. El objetivo es replicar solo los datos modificados en lugar de todo el volumen. Como se replica menos información con este método, la replicación puede realizarse a través de enlaces de ancho de banda menos costosos, como iSCSI o T1, en lugar de líneas de fibra óptica.
Muchos sistemas de archivos distribuidos utilizan la replicación para garantizar la tolerancia a fallas y evitar un único punto de falla.
Muchos sistemas comerciales de replicación sincrónica no se congelan cuando la réplica remota falla o pierde la conexión (comportamiento que garantiza cero pérdida de datos), sino que continúan operando localmente, perdiendo el objetivo de punto de recuperación cero deseado .
Se pueden aplicar técnicas de optimización de redes de área amplia (WAN) para abordar los límites impuestos por la latencia.
La replicación basada en archivos realiza la replicación de datos en el nivel lógico (es decir, archivos de datos individuales) en lugar de en el nivel de bloque de almacenamiento. Existen muchas formas diferentes de realizar esto, que dependen casi exclusivamente del software.
Un controlador de núcleo (específicamente un controlador de filtro ) se puede utilizar para interceptar llamadas a las funciones del sistema de archivos, capturando cualquier actividad a medida que ocurre. Esto utiliza el mismo tipo de tecnología que emplean los verificadores de virus activos en tiempo real. En este nivel, se capturan las operaciones lógicas de archivo como abrir, escribir, eliminar, etc. El controlador de núcleo transmite estos comandos a otro proceso, generalmente a través de una red a una máquina diferente, que imitará las operaciones de la máquina de origen. Al igual que la replicación de almacenamiento a nivel de bloque, la replicación a nivel de archivo permite modos sincrónicos y asincrónicos. En el modo sincrónico, las operaciones de escritura en la máquina de origen se retienen y no se permite que ocurran hasta que la máquina de destino haya reconocido la replicación exitosa. El modo sincrónico es menos común con los productos de replicación de archivos, aunque existen algunas soluciones.
Las soluciones de replicación a nivel de archivo permiten tomar decisiones informadas sobre la replicación en función de la ubicación y el tipo de archivo. Por ejemplo, se podrían excluir archivos temporales o partes de un sistema de archivos que no tengan valor comercial. Los datos transmitidos también pueden ser más granulares; si una aplicación escribe 100 bytes, solo se transmiten los 100 bytes en lugar de un bloque de disco completo (generalmente 4096 bytes). Esto reduce sustancialmente la cantidad de datos enviados desde la máquina de origen y la carga de almacenamiento en la máquina de destino.
Las desventajas de esta solución basada únicamente en software incluyen el requisito de implementación y mantenimiento a nivel del sistema operativo y una mayor carga sobre la potencia de procesamiento de la máquina.
De manera similar a los registros de transacciones de bases de datos , muchos sistemas de archivos tienen la capacidad de registrar su actividad. El registro se puede enviar a otra máquina, ya sea de forma periódica o en tiempo real mediante transmisión. En el lado de la réplica, el registro se puede utilizar para reproducir modificaciones del sistema de archivos.
Una de las implementaciones notables es System Center Data Protection Manager (DPM) de Microsoft , lanzado en 2005, que realiza actualizaciones periódicas pero no ofrece replicación en tiempo real. [ cita requerida ]
Se trata del proceso de comparar los sistemas de archivos de origen y destino y garantizar que el destino coincida con el origen. La principal ventaja es que estas soluciones suelen ser gratuitas o económicas. La desventaja es que el proceso de sincronización requiere mucho esfuerzo del sistema y, en consecuencia, este proceso suele ejecutarse con poca frecuencia.
Una de las implementaciones notables es rsync .
En un sistema operativo de paginación , las páginas de un archivo de paginación a veces se replican dentro de una pista para reducir la latencia rotacional.
En VSAM de IBM , los datos de índice a veces se replican dentro de una pista para reducir la latencia rotacional.
Otro ejemplo de uso de la replicación aparece en los sistemas de memoria compartida distribuida , donde muchos nodos del sistema comparten la misma página de memoria. Esto suele significar que cada nodo tiene una copia independiente (réplica) de esta página.
Muchos enfoques clásicos de replicación se basan en un modelo de copia de seguridad primaria, en el que un dispositivo o proceso tiene control unilateral sobre uno o más procesos o dispositivos. Por ejemplo, el principal puede realizar algunos cálculos, transmitiendo un registro de actualizaciones a un proceso de copia de seguridad (en espera), que puede tomar el control si el principal falla. Este enfoque es común para replicar bases de datos, a pesar del riesgo de que si se pierde una parte del registro durante una falla, la copia de seguridad podría no estar en un estado idéntico al principal y, en ese caso, podrían perderse las transacciones.
Una debilidad de los esquemas de respaldo primario es que solo uno de ellos realiza las operaciones. Se gana tolerancia a fallas, pero el sistema de respaldo idéntico duplica los costos. Por esta razón, a partir de 1985 , la comunidad de investigación de sistemas distribuidos comenzó a explorar métodos alternativos para replicar datos. Un resultado de este trabajo fue el surgimiento de esquemas en los que un grupo de réplicas podía cooperar, con cada proceso actuando como respaldo y al mismo tiempo manejando una parte de la carga de trabajo.
El científico informático Jim Gray analizó los esquemas de replicación multiprimaria bajo el modelo transaccional y publicó un artículo ampliamente citado en el que se mostraba escéptico respecto de este enfoque: "Los peligros de la replicación y una solución". [10] [11] Gray argumentó que, a menos que los datos se dividan de alguna manera natural de modo que la base de datos pueda tratarse como n n subbases de datos disjuntas, los conflictos de control de concurrencia darán como resultado una degradación grave del rendimiento y el grupo de réplicas probablemente se ralentizará en función de n . Gray sugirió que los enfoques más comunes probablemente resulten en una degradación que se escala como O(n³) . Su solución, que consiste en particionar los datos, solo es viable en situaciones en las que los datos realmente tienen una clave de partición natural.
Entre 1985 y 1987 se propuso el modelo de sincronía virtual , que surgió como un estándar ampliamente adoptado (se utilizó en los sistemas Isis Toolkit, Horus, Transis, Ensemble, Totem, Spread , C-Ensemble, Phoenix y Quicksilver, y es la base del estándar de computación tolerante a fallos CORBA ). La sincronía virtual permite un enfoque multiprimario en el que un grupo de procesos coopera para paralelizar algunos aspectos del procesamiento de solicitudes. El esquema solo se puede utilizar para algunas formas de datos en memoria, pero puede proporcionar aceleraciones lineales en el tamaño del grupo.
Varios productos modernos admiten esquemas similares. Por ejemplo, Spread Toolkit admite este mismo modelo de sincronía virtual y se puede utilizar para implementar un esquema de replicación multiprimario; también sería posible utilizar C-Ensemble o Quicksilver de esta manera. WANdisco permite la replicación activa, en la que cada nodo de una red es una copia exacta o réplica y, por lo tanto, cada nodo de la red está activo en un momento dado; este esquema está optimizado para su uso en una red de área amplia (WAN).
Los protocolos modernos de replicación multiprimaria optimizan el funcionamiento común sin fallos. La replicación en cadena [12] es una familia popular de dichos protocolos. Las variantes de protocolo de vanguardia [13] de replicación en cadena ofrecen un alto rendimiento y una gran consistencia al organizar las réplicas en una cadena para las escrituras. Este enfoque permite lecturas locales en todos los nodos de réplica, pero tiene una alta latencia para las escrituras que deben atravesar varios nodos de manera secuencial.
Un protocolo multiprimario más reciente, Hermes, [14] combina invalidaciones inspiradas en la coherencia de la memoria caché y marcas de tiempo lógicas para lograr una fuerte coherencia con las lecturas locales y las escrituras de alto rendimiento de todas las réplicas. Durante el funcionamiento sin fallos, sus escrituras basadas en difusión no generan conflictos y se confirman después de un solo viaje de ida y vuelta de multidifusión a los nodos de réplica. Este diseño da como resultado un alto rendimiento y una baja latencia tanto para las lecturas como para las escrituras.