¿Qué son la redundancia, la replicación y la copia de seguridad?

A menudo pensamos en la nube como un sistema omnipresente y distribuido globalmente. Sin embargo, en realidad, la nube se compone de hardware que se ejecuta en centros de datos. La resistencia requiere que tenga en cuenta algunos de los riesgos asociados a las ubicaciones físicas en las que se ejecutan los componentes hospedados en la nube.

En este artículo se proporciona una introducción general a la redundancia, la replicación y la copia de seguridad, que son métodos que se usan para crear cargas de trabajo resistentes a los riesgos físicos que provocan interrupciones del servicio, interrupciones o pérdida de datos.

La redundancia es la capacidad de mantener varias copias idénticas de un componente de servicio y usar esas copias de una manera que impida que cualquier componente se convierta en un único punto de error.

La replicación o la redundancia de datos es la capacidad de mantener varias copias de datos, denominadas réplicas.

La copia de seguridad es la capacidad de mantener una copia con marca de tiempo de los datos que se pueden usar para restaurar los datos que se han perdido.

Desde una perspectiva de confiabilidad, una manera importante de mitigar muchos riesgos es incluir alguna forma de redundancia, replicación o copia de seguridad en el planeamiento de continuidad empresarial.

Redundancia

La redundancia consiste en implementar varias instancias de un componente. Aunque la redundancia es sencilla de entender, en algunas situaciones, puede ser compleja de implementar.

Al empezar a comprender la redundancia, es más fácil considerar la redundancia en relación con los componentes sin estado, que son componentes que no almacenan datos. Aunque la mayoría de las soluciones del mundo real requieren administrar el estado, en esta sección se describe la redundancia en términos de una interfaz de programación de aplicaciones sin estado (API) de ejemplo. La API de ejemplo acepta la entrada, funciona en esa entrada y, a continuación, devuelve una salida, sin almacenar ningún dato. En la siguiente sección, Replicación: Redundancia para los datos, añadiremos consideraciones sobre la redundancia de estado.

Escenario: Redundancia sin estado

En este ejemplo, se implementa un componente de API sin estado en una máquina virtual. Para evitar el tiempo de inactividad del componente de API si se produce un error de hardware en el host físico, el ejemplo implementa una solución redundante que:

• Implementa varias copias de la instancia de API.
• Implementa un equilibrador de carga para distribuir solicitudes entre instancias de API.

El equilibrador de carga supervisa el estado de cada instancia para enviar solicitudes solo a instancias correctas.

Consideraciones sobre redundancia

Al implementar soluciones redundantes, como en el escenario anterior, es importante tener en cuenta lo siguiente:

• Costos de recursos. Por definición, la redundancia implica tener varias copias de algo, lo que aumenta el costo total para hospedar la solución.

• Rendimiento. Cuanto más amplio sea un área geográfica que distribuya las copias de las cosas, más riesgos le ayudará a mitigar. Sin embargo, las solicitudes de los clientes tardarán más tiempo en recorrer distancias más largas porque tienen que atravesar más infraestructura de red y esto aumenta la latencia de red.

  En la mayoría de las situaciones reales, la latencia de red es inconsecuente para distancias cortas, como dentro de un centro de datos o incluso entre centros de datos a través de una ciudad. Pero si distribuye copias a una larga distancia, la latencia de red puede ser más significativa.

• Coherencia de instancias. Es importante mantener las instancias coherentes entre sí y evitar configurar instancias individualmente, ya que puede introducir accidentalmente diferencias entre las instancias. Si hay diferencias entre instancias, es posible que las solicitudes se procesen de forma diferente en función de la instancia que las sirva. Esto puede provocar errores y comportamientos difíciles de diagnosticar.

• Distribución del trabajo. Cuando tenga varias instancias de un componente, debe distribuir el trabajo entre ellos. Puede distribuir el trabajo en todas las instancias de la misma manera, o puede enviar solicitudes a una sola instancia principal y usar solo una instancia secundaria si la instancia principal no está disponible.

  En el caso de los componentes que reciben las solicitudes entrantes, los equilibradores de carga a menudo se utilizan para enviar esas solicitudes a las instancias. Sin embargo, a veces los componentes funcionan de forma independiente y no reciben solicitudes de los clientes, por lo que, en estas situaciones, es posible que las instancias deban coordinar su trabajo entre sí.

• Supervisión de estado. El estado de cada instancia determina si esa instancia puede realizar su trabajo y la supervisión de estado es importante para habilitar la recuperación rápida si hay un problema.

  Normalmente, los equilibradores de carga realizan el monitoreo de salud. En el caso de los componentes que no incluyen un equilibrador de carga, es posible que tenga un componente externo que supervise el estado de todas las instancias o que cada instancia pueda supervisar el estado de otras instancias.

Ubicaciones físicas en la nube

La necesidad de redundancia es clara cuando comprende que, incluso en un entorno de nube, una instancia o un fragmento de datos se almacenan en una ubicación física específica.

Por ejemplo:

• Una máquina virtual se ejecuta en un único lugar físico en cualquier momento.
• Los datos se almacenan en una ubicación física específica, como en una unidad de estado sólido (SSD) o en un disco duro conectado a los servidores.

Incluso si hay varias copias de un fragmento de datos o instancias de un componente, cada copia está vinculada al hardware físico en el que se almacena.

La ubicación física de un entorno en la nube se puede organizar en ámbitos físicos. En cada ámbito físico, hay posibles riesgos que podrían poner en peligro los componentes o los datos dentro de ese ámbito. Esta es una lista no exhaustiva de riesgos que se pueden definir en términos de ámbito físico:

Desde una perspectiva de confiabilidad, una manera importante de mitigar los riesgos asociados a un ámbito físico es distribuir instancias de un componente en distintos ámbitos físicos. Los servicios de Azure con redundancia integrada pueden ofrecer una o varias de las tres maneras siguientes de implementar instancias redundantes:

• La redundancia local coloca instancias en varias partes de un único centro de datos de Azure y protege frente a errores de hardware que podrían afectar a una sola instancia. La redundancia local normalmente proporciona el menor costo y latencia. Sin embargo, un error del centro de datos podría significar que todas las instancias no están disponibles.

• La redundancia de zona distribuye instancias en varias zonas de disponibilidad en una sola región de Azure. La redundancia de zona protege frente a errores del centro de datos, además de errores de hardware.

• La redundancia geográfica coloca instancias en varias regiones de Azure y proporciona protección contra interrupciones regionales a gran escala. La redundancia geográfica conlleva un costo más alto y requiere tener en cuenta el diseño más amplio de la solución y cómo cambiará entre instancias de los componentes de cada región. También debe tener en cuenta la latencia, que se describe en Replicación sincrónica y asincrónica.

Funcionamiento de la redundancia en Azure: Servicios de proceso

La redundancia se emplea en casi todas las partes de Azure. Como ejemplo de cómo implementa Azure redundancia, tenga en cuenta los servicios que ejecutan cargas de trabajo de cómputo.

En Azure, una máquina virtual individual se ejecuta en un único host físico en un centro de datos de Azure. Puede proporcionar instrucciones a Azure para asegurarse de que la máquina virtual se ejecuta en el lugar esperado, como la región y la zona de disponibilidad, y en algunas situaciones, es posible que incluso quiera colocarla en un host dedicado a usted.

Es habitual ejecutar varias instancias de una máquina virtual. En ese escenario, puede optar por administrarlos individualmente o mediante un conjunto de escalado de máquinas virtuales. Cuando se usa un conjunto de escalado, todavía puede ver las máquinas virtuales individuales que lo sustentan, pero el conjunto de escalado proporciona una serie de funcionalidades para ayudar a administrar máquinas virtuales redundantes. Estas funcionalidades incluyen la colocación automática de las máquinas virtuales en función de las reglas que especifique, como distribuirlas entre dominios de error dentro de la región o zona de disponibilidad.

Hay muchos otros servicios de proceso de Azure que dependen de máquinas virtuales para realizar tareas de proceso. Los servicios de proceso suelen ofrecer varias opciones de redundancia que determinan cómo se distribuyen las máquinas virtuales. Por ejemplo, un servicio podría proporcionar una configuración de redundancia de zona, que puede habilitar para distribuir automáticamente máquinas virtuales entre zonas de disponibilidad y configurar el equilibrio de carga.

Replicación: Redundancia para los datos

La redundancia, cuando se aplica al estado (datos), se denomina replicación. Con la replicación, puede mantener varias copias en tiempo real o casi en tiempo real de datos activos, denominadas réplicas. Para mejorar la resistencia a los riesgos, puede distribuir réplicas en diferentes ubicaciones. Si una réplica deja de estar disponible, el sistema podría conmutar por error para que otra réplica tome el control de su función.

Hay diferentes tipos de replicación y cada uno coloca prioridades diferentes en la coherencia de los datos, el rendimiento y el costo. Cada tipo de replicación afecta a dos métricas clave que se usan en discusiones de continuidad empresarial: objetivo de tiempo de recuperación (RTO), que es la cantidad máxima de tiempo de inactividad que puede tolerar en un escenario de desastre y el objetivo de punto de recuperación (RPO), que es la cantidad máxima de pérdida de datos que puede tolerar en un escenario de desastre. Para obtener más información sobre estas métricas y cómo se relacionan con la continuidad empresarial, consulte ¿Qué son la continuidad empresarial, la alta disponibilidad y la recuperación ante desastres?.

Debido a la importancia de la replicación en cumplir los requisitos funcionales y de rendimiento, la mayoría de los sistemas de base de datos y otros productos y servicios de almacenamiento de datos incluyen algún tipo de replicación como una característica estrechamente integrada. Los tipos de replicación que ofrecen suelen basarse en su arquitectura y en las formas en que están diseñados para usarse. Para más información sobre los tipos de replicación admitidos por los servicios de Azure, consulte Guías de confiabilidad de los servicios de Azure.

Replicación sincrónica y asincrónica

Al replicar datos, los cambios realizados en esos datos se deben mantener sincronizados entre las réplicas. Hay un par de desafíos principales al intentar mantener la coherencia cuando cambian los datos:

• Latencia. La actualización de una réplica lleva tiempo, y cuanto más alejadas estén las réplicas entre sí, más tarda en transmitirse los datos a través de la distancia entre ellas y en recibir una confirmación.

• Administración de cambios. Los datos pueden cambiar mientras se sincronizan las réplicas y, por tanto, administrar la coherencia de los datos puede ser compleja.

Para abordar estos desafíos, hay dos maneras principales de replicar los cambios de datos y administrar la coherencia de los datos:

• La replicación sincrónica requiere que se realicen actualizaciones en varias réplicas antes de que la actualización se considere completada. En el diagrama siguiente se muestra cómo funciona la replicación sincrónica:

  

  En este ejemplo, se produce la siguiente secuencia de pasos:

  1. Un cliente cambia los datos y la solicitud se envía a la réplica 1, que procesa la solicitud y almacena los datos modificados.
  2. La réplica 1 envía los cambios a la réplica 2, que procesa la solicitud y almacena los datos modificados.
  3. La réplica 2 confirma el cambio a la réplica 1.
  4. La réplica 1 confirma el cambio al cliente.

  La replicación sincrónica puede garantizar la coherencia, lo que significa que puede admitir un RPO de cero. Sin embargo, esto conlleva el costo del rendimiento. Cuantos más separados sean las réplicas geográficamente y cuantos más saltos de red deban atravesarse, el proceso de replicación introducirá más latencia.

• La replicación asincrónica se produce en segundo plano. En el diagrama siguiente se muestra cómo funciona la replicación asincrónica:

  

  En este ejemplo, se produce la siguiente secuencia de pasos:

  1. Un cliente cambia los datos y la solicitud se envía a la réplica 1.
  2. La réplica 1 procesa la solicitud, almacena los datos modificados y confirma inmediatamente el cambio al cliente.
  3. En algún momento posterior, la réplica 1 sincroniza el cambio en la réplica 2.

  Dado que la replicación asincrónica se produce fuera de los flujos de transacción, quita la replicación como una restricción en el rendimiento de la aplicación. Sin embargo, si necesita conmutar por error a otra réplica, es posible que no tenga los datos más recientes y, por tanto, el RPO debe ser mayor que cero. El RPO exacto que la replicación asincrónica puede admitir depende de la frecuencia de replicación.

Roles de réplica

En muchos sistemas de replicación, las réplicas pueden asumir diferentes roles, lo que ayuda a coordinar los cambios en los datos y reduce la posibilidad de conflictos. Hay dos tipos principales de roles, activos y pasivos. Hay dos formas comunes de distribuir réplicas con estos roles:

• La replicación activa-pasiva significa que tiene una réplica activa, que es responsable de actuar como fuente de verdad. Los cambios realizados en los datos deben aplicarse a esa réplica. Cualquier otra réplica actúa en un rol pasivo , lo que significa que reciben actualizaciones de los datos de la réplica activa, pero no procesan los cambios directamente de los clientes. Las réplicas pasivas no se usan para el tráfico activo a menos que ocurra una conmutación por error y los roles de las réplicas cambien. En el diagrama siguiente se muestra un sistema activo-pasivo con una réplica pasiva:

  

  En un sistema activo-pasivo, el tiempo que se tarda en la conmutación ante fallos determina el RTO. Normalmente, el RTO para un sistema activo-pasivo se mide en minutos.

  Algunas soluciones de replicación también admiten réplicas de solo lectura, lo que permite leer (pero no escribir) datos de las réplicas pasivas. Este enfoque puede ser útil para obtener más uso de las réplicas, como cuando necesite realizar análisis o informes sobre datos sin afectar a la réplica principal que usa para el trabajo transaccional de la aplicación. Varios servicios de Azure admiten réplicas de solo lectura, como Azure Storage con replicación GRS de acceso de lectura (RA-GRS) y la replicación geográfica activa de Azure SQL Database.

• La replicación activa-activa permite usar varias réplicas activas para el tráfico activo simultáneamente y cualquiera de las réplicas puede procesar solicitudes:

  

  La replicación activa-activa permite un alto nivel de rendimiento porque el sistema puede usar los recursos en todas las réplicas. La replicación activa-activa puede admitir un RTO de cero en algunas situaciones. Sin embargo, estas ventajas tienen el costo de complicar la coherencia de los datos, ya que es posible que los cambios simultáneos en varias réplicas deban conciliarse de forma asincrónica.

Los servicios de datos complejos pueden combinar la replicación activa-activa y activa-pasiva. Por ejemplo, podrían implementar un conjunto de réplicas en una región de Azure y otra en otra región diferente. Dentro de cada región, una única réplica activa atiende solicitudes mientras que una o varias réplicas pasivas están en espera de la conmutación por error. Mientras tanto, ambas regiones operan en un modelo activo-activo, lo que permite distribuir el tráfico entre ellas.

Funcionamiento de la replicación en los servicios de datos de Azure

Cada servicio de Azure que almacena los datos ofrece alguna forma de replicación. Sin embargo, cada servicio puede usar un enfoque diferente específico de la arquitectura del servicio y los usos previstos.

Por ejemplo, Azure Storage puede proporcionar replicación sincrónica y asincrónica a través de un conjunto de funcionalidades:

• Varias copias de los datos se replican sincrónicamente dentro de la región primaria. Puede elegir si colocar réplicas en hardware físico diferente en un único centro de datos en almacenamiento con redundancia local (LRS) o distribuirlas entre varias zonas de disponibilidad para el almacenamiento con redundancia de zona (ZRS).
• Si la región primaria está emparejada y habilita el almacenamiento con redundancia geográfica (GRS), los datos también se replican en la región emparejada. Dado que las regiones emparejadas están geográficamente distantes, esta replicación se produce de forma asincrónica para reducir el impacto en el rendimiento de la aplicación.
• Puede optar por usar almacenamiento con redundancia de zona y almacenamiento con redundancia geográfica simultánea mediante el nivel de almacenamiento con redundancia de zona geográfica (GZRS). Los datos de la región se replican de forma sincrónica y los datos entre regiones se replican de forma asincrónica.

Para más información, vea Redundancia de Azure Storage.

Otro ejemplo es Azure Cosmos DB, que también proporciona replicación. Todas las bases de datos de Azure Cosmos DB tienen varias réplicas. Al distribuir réplicas globalmente, admite escrituras en varias regiones, donde los clientes pueden escribir en una réplica en cualquiera de las regiones que use. Esas operaciones de escritura se replican sincrónicamente dentro de la región y, a continuación, se replican de forma asincrónica en otras regiones. Azure Cosmos DB proporciona un mecanismo de resolución de conflictos en caso de que haya conflictos de escritura en las distintas réplicas. Para más información, consulte Distribución global de datos con Azure Cosmos DB en segundo plano.

Si usa máquinas virtuales, puede usar Azure Site Recovery para replicar máquinas virtuales y sus discos entre zonas de disponibilidad o en otra región de Azure.

Al diseñar una solución de Azure, consulte las guías de confiabilidad de cada servicio para comprender cómo ese servicio proporciona redundancia y replicación, incluida en diferentes ubicaciones.

Copia de seguridad

La copia de seguridad guarda una copia de tus datos en un momento específico. Si hay un problema, puede restaurar la copia de seguridad más adelante. Sin embargo, los cambios realizados en los datos que se produjeron después de realizar la copia de seguridad no estarán en la copia de seguridad y podrían perderse.

Mediante la copia de seguridad, puede proporcionar soluciones para realizar copias de seguridad y recuperar los datos dentro o en la nube de Microsoft Azure. La copia de seguridad puede protegerle de diversos riesgos, entre los que se incluyen:

• Pérdidas catastróficas de hardware u otra infraestructura.
• Corrupción y eliminación de datos.
• Ciberataques, como ransomware.

Cómo afecta la copia de seguridad a los requisitos

Cuando se usa como parte de una estrategia de recuperación ante desastres, las copias de seguridad suelen admitir un RTO y un RPO medidos en horas:

• RTO se ve afectado por el tiempo necesario para iniciar y completar los procesos de recuperación, incluida la restauración de una copia de seguridad y la validación de que la restauración se completó correctamente. Según el tamaño de la copia de seguridad y el número de archivos de copia de seguridad que se deben leer, es habitual tardar varias horas o incluso más tiempo en restaurar completamente una copia de seguridad.

• El RPO se ve afectado por la frecuencia del proceso de copia de seguridad. Si hace copias de seguridad con más frecuencia, significa que pierde menos datos si tiene que restaurar desde una copia de seguridad. Sin embargo, las copias de seguridad requieren almacenamiento y, en algunas situaciones, pueden afectar al rendimiento del servicio mientras se realizan copias de seguridad. Por este motivo, debe tener en cuenta la frecuencia de copia de seguridad y encontrar el equilibrio adecuado para los requisitos de su organización. La frecuencia de copia de seguridad debe considerarse en la planificación de la continuidad empresarial.

Algunos sistemas de copia de seguridad admiten requisitos de copia de seguridad más complejos, incluidos varios niveles de copia de seguridad con diferentes períodos de retención, y copias de seguridad diferenciales o incrementales que son más rápidas para ahorrar y consumir menos almacenamiento.

Copia de seguridad en servicios de Azure

Muchos servicios de Azure proporcionan funcionalidades de copia de seguridad para los datos.

Azure Backup es una solución de copia de seguridad dedicada para varios servicios clave de Azure, como máquinas virtuales, Azure Storage y Azure Kubernetes Service (AKS).

Además, muchas bases de datos administradas proporcionan sus propias funcionalidades de copia de seguridad como parte del servicio, como:

• Azure SQL Database proporciona copias de seguridad automatizadas.
• Azure Cosmos DB proporciona funcionalidades de copia de seguridad continuas y periódicas.
• Azure Key Vault le permite descargar una copia de seguridad de los datos del almacén.
• Azure App Service proporciona copias de seguridad automáticas y personalizadas para aplicaciones web y también puede realizar copias de seguridad de sus bases de datos.

Copia de seguridad frente a replicación

La copia de seguridad y la replicación le protegen contra distintos riesgos, y los dos enfoques son complementarios entre sí.

La replicación apoya la resiliencia cotidiana y se usa habitualmente en una estrategia de alta disponibilidad. Algunos enfoques de replicación requieren poco o ningún tiempo de inactividad o pérdida de datos y admiten un RTO y RPO bajo. Sin embargo, la replicación no le protege frente a riesgos que provocan pérdida de datos o daños.

En cambio, la copia de seguridad suele ser una última línea de defensa frente a riesgos catastróficos. Las copias de seguridad a menudo requieren un RTO y RPO relativamente altos, aunque la forma en que se configuren afectará qué tan altos serán. Una restauración total a partir de una copia de seguridad suele formar parte de un plan de recuperación ante desastres.

Preparación de componentes para redundancia

Al diseñar un sistema que use redundancia como parte de su arquitectura, también es importante tener en cuenta cómo:

• Configuración de recursos duplicada para la coherencia.
• Administre la capacidad durante los errores de instancia mediante el aprovisionamiento.

Configuración de recursos duplicados

En entornos en la nube, la configuración de cada uno de los recursos es fundamental. Por ejemplo, cuando se crea un equilibrador de carga de red, se configuran diversas opciones que afectan a cómo funciona; y al implementar una función mediante Azure Functions, se configuran las opciones relacionadas con la seguridad, el rendimiento y las opciones de configuración de la aplicación. Cada recurso de Azure tiene algún tipo de configuración que impulsa su comportamiento.

Al administrar copias redundantes de recursos en diferentes lugares, es importante controlar su configuración. Muchas configuraciones deberán configurarse de la misma manera en cada copia, de modo que los recursos se comporten de la misma manera. Pero algunas opciones de configuración pueden ser diferentes entre cada copia, como referencias a la red virtual de una región específica.

Un enfoque común para mantener la coherencia en los recursos es usar la infraestructura como código (IaC), como Bicep o Terraform. Estas herramientas le permiten crear archivos que definen un recurso y puede reutilizar esas definiciones para cada instancia del recurso. Al usar IaC, puede reducir la carga de crear y administrar varias instancias de recursos con fines de resistencia y también hay muchas otras ventajas. Para más información, consulte ¿Qué es la infraestructura como código (IaC)? y Recomendaciones para usar la infraestructura como código.

Administración de la capacidad con aprovisionamiento excesivo

Cuando se produce un error en una instancia, la capacidad general del sistema puede ser diferente de la capacidad necesaria durante las operaciones correctas. Por ejemplo, supongamos que normalmente tiene seis instancias de un servidor web para procesar el tráfico web entrante y esas instancias se distribuyen igualmente entre tres zonas de disponibilidad de Azure en una región:

Si una zona de disponibilidad experimenta una interrupción, puede perder temporalmente dos instancias y dejarse con solo cuatro instancias de servidor web. Si tu aplicación normalmente está ocupada y requiere las seis instancias para gestionar el tráfico habitual, entonces operar con una capacidad reducida podría afectar al rendimiento de tu solución.

Para prepararse para errores, puede sobreaprovisionar la capacidad del servicio. El sobreaprovisionamiento permite a la solución tolerar cierto grado de pérdida de capacidad y seguir funcionando sin degradar el rendimiento.

Para sobreaprovisionar instancias del servidor web para tener en cuenta el error de una zona de disponibilidad, siga estos pasos:

1. Determine el número de instancias necesarias en una situación de carga de trabajo máxima.
2. Multiplique el número máximo de instancias de carga de trabajo por un factor de [(zonas/(zonas - 1)] para encontrar el número de instancias que debe sobreaprovisionar.
3. Redondea el resultado al número entero más cercano.

En el ejemplo anterior, la carga de trabajo máxima requiere seis instancias del servidor web, por lo que el aprovisionamiento excesivo requiere un total de nueve instancias:

Pasos siguientes

Obtenga información sobre conmutación por error y conmutación por recuperación.