Arquitectura de Recuperación ante Desastres en AWS – Parte 1: Estrategias de recuperación en la nube

Como lead Solutions Architect del pilar de fiabilidad del AWS Well-Architected Framework, ayudo a nuestros clientes a desplegar cargas de trabajo resilientes en AWS, basado en las mejores prácticas . Esto les permite estar preparados para eventos catastróficos, lo cual representa un gran desafío cuando se tienen cargas de trabajo productivas. Dichos eventos incluyen: desastres naturales como un terremoto o inundación, fallas técnicas como perdida de energía o conectividad, y errores humanos como modificaciones no intencionadas o no autorizadas. Las cargas de trabajo resilientes brindan beneficios al minimizar el impacto financiero de posibles fallas de servicios y ataques cibernéticos. Los costes por este tipo de incidentes pueden ser de diversa índole, por ejemplo perdida de clientes, daño a la reputación de negocio, perdida de productividad o multas por fallos en los niveles de servicio. En este blog hablaremos sobre cómo diseñar arquitecturas de recuperación ante desastres, algo crucial como parte de los objetivos del Plan Continuidad de Negocio de toda organización.

Objetivos de recuperación ante desastres

Debido a las consecuencias que un evento catastrófico puede tener para el negocio, los objetivos fundamentales de un plan recuperación ante desastres deben ser recuperar nuestras cargas de trabajo lo más rápido posible y minimizar la perdida de datos. A continuación los objetivos de recuperación que usamos:

• Tiempo de Recuperación Objetivo (RTO por sus siglas en inglés): Es el retraso máximo aceptable entre la interrupción del servicio y su restablecimiento. Esto determina lo que se considera un intervalo de tiempo aceptable cuando el servicio no está disponible.
• Punto de Recuperación Objetivo (RPO por sus siglas en inglés): Es el periodo de tiempo máximo aceptable desde el último punto de recuperación de datos. Determina lo que se considera una pérdida aceptable de datos entre el último punto de recuperación y la interrupción del servicio.

Imagen 1. Puntos de Recuperación: RTO y RPO

Tiempos de RTO y RPO pequeños, representan menor tiempo de interrupción del servicio y pérdida de datos. Sin embargo, esto incrementa los costes de recursos y la complejidad operacional. En consecuencia, los tiempos de RTO y RPO deben ser apropiados y responder a necesidades y valor de negocio.

Alcance del impacto de un evento de recuperación ante desastres

Estrategia de varias Zonas de Disponibilidad (AZs)

Cada región de AWS está compuesta por múltiples Zonas de Disponibilidad (AZs). Cada Zona de Disponibilidad consiste en uno o más centros de datos ubicados en distintas zonas geográficas. Este diseño reduce significativamente el riesgo de que un evento catastrófico afecte a más de una Zona de Disponibilidad. En consecuencia, si busca diseñar una estrategia de recuperación ante desastres que resista eventos como cortes de energía, inundaciones u otros eventos regionales, usar una estrategia de varias zonas de disponibilidad dentro de una región de AWS puede brindar la protección buscada.

Estrategia de múltiples Regiones

AWS brinda múltiples herramientas para implementar una estrategia de recuperación ante desastres de múltiples regiones. Así puede mantener sus cargas de trabajo operativas inclusive durante eventos que impacten múltiples centros de datos en distintas ubicaciones geográficas. La mayoría de los ejemplos en este blog post, se basan en una estrategia de recuperación ante desastres de múltiples regiones. Sin embargo, también podeis usar estas tácticas en una estrategia de varias Zonas de Disponibilidad o híbrida (carga de trabajo on-prem / recuperación en la nube).

Estrategias de recuperación ante desastres

AWS ofrece recursos y servicios que ayudan a construir una estrategia de recuperación ante desastres que acompaña sus necesidades de negocio.

Imagen 2. Estrategias de recuperación ante desastres y las consideraciones a tener en cuenta entre costes y tiempos de RPO y RTO.

La imagen nº2 enumera las cuatro estrategias de recuperación ante desastre que se incluyen en el whitepaper. De izquierda a derecha, la imagen muestra un decremento en los tiempos de RTO y RPO.
Para seleccionar una estrategia adecuada, se deben analizar los beneficios y riesgos con los responsables de negocio para una carga de trabajo específica. Se debe identificar cual es el RTO y RPO necesarios para la carga de trabajo y que inversión monetaria, de tiempo y esfuerzo se está dispuesto a realizar.

Imagen 3. Recuperación ante desastres Activo/pasivo

La imagen 2 categoriza las estrategias de recuperación ante desastres entre activo/pasivo y activo/activo. En la imagen 3 se muestra el funcionamiento de activo/pasivo. La carga de trabajo opera desde una única ubicación (en este caso una región de AWS) y todas las peticiones son trabajadas desde esta ubicación activa. Si un evento de desastre ocurre y la ubicación activa no puede continuar dando soporte a la carga de trabajo, la ubicación pasiva se convierte en la región de recuperación. En ese momento, se deben realizar las tareas necesarias para que la carga de trabajo pueda trabajar desde esa ubicación. A partir de este punto, todas las peticiones son dirigidas hacia la nueva ubicación, en un proceso llamado “failover”. Para requerimientos de RTO/RPO más acotados en tiempo, los datos son mantenidos en vivo y la infraestructura se despliega total o parcialmente en el sitio de recuperación antes del failover. Si es necesario recuperar datos de backup, es posible que esta tarea demore las tareas de recuperación y aumente la cantidad de datos perdidos. Si la infraestructura requiere operaciones adicionales antes de comenzar a recibir peticiones, esto puede incrementar el tiempo de recuperación.

Imagen 4. Recuperación ante desastres activo/activo

La imagen 4 enseña una estrategia activo/activo donde dos o más ubicaciones están recibiendo peticiones y los datos son replicados entre las mismas. Si ocurre un evento de desastre en una de las ubicaciones, la estrategia de failover involucra dirigir el tráfico únicamente a la o las ubicaciones que se mantienen disponibles. Incluso si se replican los datos entre las ubicaciones, es necesario realizar resguardos de seguridad (backups) como parte de la estrategia de recuperación ante desastres. Esto previene accidentes del tipo “errores humanos” u otros tipos de desastres ocasionados por problemas de software. Si dichos desastres incluyen perdida o corrupción de datos, es necesario una estrategia de recuperación-en-el-tiempo (point-in-time recovery) para poder recuperar un último estado válido.

Arquitectura de las estrategias de recuperación ante desastres

A continuación, presentamos un sumario de cada estrategia y su arquitectura.

Backup and Restore

Imagen 5. Arquitectura de recuperación ante desastres – Backup and Restore

La imagen anterior muestra los Backups o respaldos de varios recursos de datos de AWS. Estos respaldos son generados en la misma región de sus servicios origen y copiados posteriormente a otra región de AWS. Esta configuración brinda la protección más efectiva frente a desastres de cualquier alcance. Para realizar el Failover en otra región de AWS, además de los respaldos de datos, debe ser posible recuperar la infraestructura en la región de recuperación. Prácticas de Infrastructure of Code como AWS CloudFormation o AWS Cloud Development Kit (AWS CDK) permite desplegar infraestructura de forma consistente en otras regiones.

La estrategia de Backup and Restore es considerada la menos eficiente en términos de RTO. Sin embargo, se pueden usar recursos de AWS como Amazon EventBridge para armar soluciones serverless que automáticamente el desplieguen y recuperen los datos y la infraestructura, lo cual reduciría el tiempo RTO al disminuir el tiempo de detección y recuperación.

Pilot Light

Imagen 6. Arquitectura de recuperación ante desastres – Pilot Light

La estrategia de Pilot Light se basa en tener una replicación activa de los datos, mientras los servicios están inactivos. Replicación activa de la data significa que los almacenes de datos y las bases de datos están actualizados con la Región activa y preparados para responder a peticiones de lectura. En la imagen 6, la base de datos Amazon Aurora con configuración de Global Databases replica los datos a un cluster de solo lectura en la región de recuperación. Sin embargo, como en todas las estrategias de recuperación ante desastres, los respaldos de datos son necesarios. Esto permite que en caso de un desastre que implique la perdida o corrupción de datos, los respaldos habilitan la recuperación al último punto correcto conocido.

En la estrategia de Pilot Light, los elementos de infraestructura básica están desplegados, tales como Elastic Load Balancing o Amazon EC2 AutoScaling en la figura 6. Mientras los elementos funcionales de infraestructura se encuentran inactivos. En la nube, la mejor forma de mantener inactivas las instancias Amazon EC2 es no desplegarlas. En la figura 6 se ve que no hay instancias desplegadas. Para desplegar estas instancias, hacemos uso de las Amazon Machine Image (AMI) que previamente creamos y copiamos a todas las regiones donde pretendemos desplegar nuestros servicios. Esta AMI crea una instancia Amazon EC2 con el sistema operativos y los paquetes que necesitamos. Es importante recordar que la estrategia de Pilot Light no puede procesar peticiones hasta que se despliegue toda la infraestructura necesaria.

Warm Standby

Imagen 7. Arquitectura de recuperación ante desastres – Warm Standby

Al igual que en la estrategia Pilot Light, se tiene una replicación activa de los datos y se hacen respaldos periódicos. La principal diferencia con Pilot Light está en la infraestructura y los servicios desplegados. La estrategia Warm Standby mantiene un despliegue mínimo de servicios e infraestructura que permite recibir peticiones pero con una capacidad limitada que no permite atender el tráfico del ambiente de producción. En la figura 7 se puede ver un ejemplo donde solo hay una instancia Amazon EC2 desplegada por cada capa. Esta configuración facilita probar la arquitectura Warm Standby ya que no require trabajo adicional en la región de recuperación para realizar pruebas con datos de test. Es importante recordar que antes de hacer el failover, se debe escalar la infraestructura y servicios para atender el tráfico del ambiente de producción.

Multi-site active / active

Imagen 8. Arquitectura de recuperación ante desastres – Multi-site active / active

En la estrategia Multi-site active / active, dos o más Regiones reciben peticiones de producción de forma activa. El failover consiste en redirigir el tráfico hacia las regiones activas que pueden procesar peticiones. Los datos se replican activamente entre regiones y se utilizan activamente para servir peticiones de lectura. Las peticiones de escritura, se pueden gestionar con diferente patrones; por ejemplo escribir los cambios en la Región que recibe la petición o dirigir estas transacciones a regiones específicas. Como en todas las estrategias de recuperación ante desastres, los datos son respaldados en caso de perdida o corrupción de los mismos. La figura 8 muestra Amazon DynamoDB global tables en la capa de datos. Amazon DynamoDB es una excelente elección para las estrategias Multi-site active / active, porque los datos pueden ser escritos en una tabla en cualquier región y los cambios se propagan a las otras regiones, usualmente en un segundo.

Conclusión

La disponibilidad de una carga de trabajo puede ser afectada por eventos de desastres, pero este impacto puede ser mitigado o eliminado utilizando servicios de la nube de AWS. Teniendo claro los requerimientos de negocio para una carga de trabajo, se puede elegir una estrategia de recuperación ante desastres que sea apropiada; y en consecuencia diseñar una arquitectura haciendo uso de servicios de AWS que permite alcanzar los objetivos de RPO y RTO necesarios.

Este blogpost es una traducción por Matías Battaglia (AWS Senior Solutions Architect) y Daniel Merchán (AWS Senior Solutions Architect) del original en Inglés.