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 fallas o la accesibilidad.
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 suele ser uniforme con el acceso a una única entidad no replicada. La replicación en sí debe ser transparente para un usuario externo. En un escenario de falla, una conmutación por error de réplicas debe ocultarse tanto como sea posible con respecto 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 elección de líder para procesar todas las solicitudes, el sistema utiliza un esquema de respaldo primario o de réplica primaria , 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 está utilizando un esquema multiprimario o multimaestro . En el ú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 diferentes cálculos 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 sin cambios durante un largo período de tiempo. [3] Las réplicas, por otro lado, se actualizan frecuentemente 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 de cálculos requieren procesos para manejar los eventos entrantes. Los procesos de replicación de datos son pasivos y funcionan únicamente para mantener los datos almacenados, responder a solicitudes de lectura y aplicar actualizaciones. La replicación informática generalmente se realiza para proporcionar tolerancia a fallas y hacerse cargo 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 administración de bases de datos (DBMS), generalmente con una relación primario/réplica entre el original y las copias. El principal registra las actualizaciones, que luego se transmiten a las réplicas. Cada réplica genera un mensaje indicando que ha recibido la actualización exitosamente, permitiendo así 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 transmitirse 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 entusiasta) realizan la prevención de conflictos, mientras que las soluciones asincrónicas (o diferidas) 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 ansioso detectaría el conflicto antes de confirmar la confirmación y abortaría una de las transacciones. Un sistema de replicación diferido permitiría que ambas transacciones se comprometan y ejecuten una resolución de conflictos durante la resincronización. [7] La resolución de tal 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 amplía horizontal y verticalmente. La ampliación horizontal tiene más réplicas de datos, mientras que la ampliación vertical tiene réplicas de datos ubicadas a mayores distancias físicas. Los problemas planteados por la ampliación horizontal se pueden aliviar mediante un protocolo de acceso multicapa y multivista . Los primeros problemas de la ampliación 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 decir o siquiera 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 restringidos por el teorema CAP o el teorema PACELC . En el movimiento NoSQL, la coherencia de los datos suele sacrificarse 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 coherencia 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) generalmente se implementa 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 disco , que es típica de los 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 primaria/réplica. El propósito de la replicación es evitar daños causados por fallas o desastres que puedan ocurrir en una ubicación o, en caso de que tales eventos ocurran, mejorar la capacidad de recuperar datos. Para la replicación, la latencia es el factor clave porque determina qué tan lejos 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, ya sea mediante replicación asíncrona o síncrona; 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.
La replicación síncrona 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 sea reconocida tanto por el almacenamiento local como por 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. De manera inherente, el rendimiento cae proporcionalmente a la distancia, ya que la latencia mínima viene dictada por la velocidad de la luz . Para una distancia de 10 km, el viaje de ida y vuelta más rápido posible tarda 67 μs, mientras que una escritura completa en caché local se completa en aproximadamente 10 a 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 semisíncrona generalmente considera que una operación de escritura se completa cuando la reconoce el almacenamiento local y la recibe o registra el servidor remoto. La escritura remota real se realiza de forma asincrónica, lo que resulta en un mejor rendimiento, pero el almacenamiento remoto quedará rezagado 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 necesaria ]
La replicación en un momento dado produce instantáneas periódicas que se replican en lugar del almacenamiento primario. Esto tiene como objetivo 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 fallos y evitar un único punto de fallo.
Muchos sistemas comerciales de replicación síncrona 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 deseado de punto de recuperación cero .
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 a nivel lógico (es decir, archivos de datos individuales) en lugar de a nivel de bloque de almacenamiento. Hay muchas formas diferentes de realizar esto, que dependen casi exclusivamente del software.
Se puede utilizar un controlador de kernel (específicamente un controlador de filtro ) para interceptar llamadas a las funciones del sistema de archivos, capturando cualquier actividad a medida que ocurre. Utiliza el mismo tipo de tecnología que emplean los verificadores de virus activos en tiempo real. En este nivel, las operaciones lógicas de archivos se capturan como abrir archivos, escribir, eliminar, etc. El controlador del kernel 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 modo síncrono, las operaciones de escritura en la máquina de origen se retienen y no se permiten hasta que la máquina de destino haya reconocido la replicación exitosa. El modo síncrono es menos común con los productos de replicación de archivos, aunque existen algunas soluciones.
Las soluciones de replicación a nivel de archivos permiten tomar decisiones informadas sobre la replicación según 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, sólo se transmiten esos 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.
Los inconvenientes de esta solución exclusivamente de 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 diario se puede enviar a otra máquina, ya sea periódicamente o en tiempo real mediante streaming. En el lado de la réplica, el diario 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 necesaria ]
Este es el proceso de comparar los sistemas de archivos de origen y destino y garantizar que el destino coincida con el origen. El beneficio clave es que estas soluciones generalmente son gratuitas o económicas. La desventaja es que el proceso de sincronización requiere bastante uso del sistema y, en consecuencia, este proceso generalmente se ejecuta 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 del 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. Normalmente, esto significa que cada nodo tiene una copia separada (réplica) de esta página.
Muchos enfoques clásicos de replicación se basan en un modelo de respaldo primario donde un dispositivo o proceso tiene control unilateral sobre uno o más procesos o dispositivos. Por ejemplo, el primario podría realizar algún cálculo, transmitiendo un registro de actualizaciones a un proceso de respaldo (en espera), que luego puede tomar el control si el primario falla. Este enfoque es común para replicar bases de datos, a pesar del riesgo de que si una parte del registro se pierde durante una falla, la copia de seguridad podría no estar en un estado idéntico al principal y las transacciones podrían perderse.
Una debilidad de los esquemas de respaldo primario es que en realidad sólo uno realiza operaciones. Se gana tolerancia a fallos, pero el mismo sistema de respaldo duplica los costos. Por esta razón, a partir de c. En 1985 , la comunidad de investigación de sistemas distribuidos comenzó a explorar métodos alternativos para replicar datos. Una consecuencia de este trabajo fue la aparición de esquemas en los que un grupo de réplicas podía cooperar, donde cada proceso actuaba como respaldo y al mismo tiempo manejaba una parte de la carga de trabajo.
El informático Jim Gray analizó esquemas de replicación multiprimaria bajo el modelo transaccional y publicó un artículo ampliamente citado escéptico ante el enfoque "Los peligros de la replicación y una solución". [10] [11] Argumentó que a menos que los datos se divida de alguna manera natural para que la base de datos pueda ser tratada como n n subbases de datos separadas, los conflictos de control de concurrencia resultarán en un rendimiento seriamente degradado y el grupo de réplicas probablemente se ralentizará a medida que una función de n . Gray sugirió que los enfoques más comunes probablemente resulten en una degradación que alcance O(n³) . Su solución, que consiste en particionar los datos, sólo es viable en situaciones en las que los datos realmente tienen una clave de partición natural.
En 1985-1987, se propuso el modelo de sincronía virtual y 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 el modelo de sincronía virtual). base para el 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 sólo se puede utilizar para algunas formas de datos en memoria, pero puede proporcionar aceleraciones lineales en el tamaño del grupo.
Varios productos modernos apoyan esquemas similares. Por ejemplo, Spread Toolkit admite este mismo modelo de sincronía virtual y puede usarse 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 donde cada nodo de una red es una copia o réplica exacta y, por lo tanto, cada nodo de la red está activo al mismo tiempo; Este esquema está optimizado para su uso en una red de área amplia (WAN).
Los protocolos de replicación multiprimarios modernos se optimizan para lograr un funcionamiento común sin fallos. La replicación en cadena [12] es una familia popular de este tipo de protocolos. Las variantes de protocolo de última generación [13] de replicación en cadena ofrecen un alto rendimiento y una gran coherencia al organizar las réplicas en una cadena para 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 secuencialmente.
Un protocolo multiprimario más reciente, Hermes, [14] combina invalidaciones inspiradas en caché coherente y marcas de tiempo lógicas para lograr una fuerte coherencia con lecturas locales y escrituras de alto rendimiento de todas las réplicas. Durante el funcionamiento sin fallos, sus escrituras basadas en difusión no son conflictivas 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 lectura como para escritura.