Pilot Light y sistema en espera activa

Cuando su requisito de RTO es inferior a unas pocas horas, la copia de seguridad y restauración no es suficiente. Los dos siguientes niveles de recuperación ante desastres, Pilot Light y Warm Standby, mantienen parte o la totalidad de su infraestructura en funcionamiento en la región de recuperación en todo momento, lo que reduce considerablemente el tiempo de recuperación. Ambas estrategias implican mantener continuamente un entorno de recuperación ante desastres y utilizar el failover mediante comprobaciones de estado de Route 53 para redirigir el tráfico durante un desastre. La diferencia está en cuánto del entorno de recuperación permanece activo.

En la estrategia Pilot Light, solo mantiene en funcionamiento el núcleo crítico del sistema en la región de recuperación ante desastres, normalmente únicamente la capa de base de datos con replicación continua. Los servidores de aplicaciones NO están en ejecución; en su lugar, mantiene AMI, plantillas de lanzamiento o infraestructura como código previamente preparados para poder iniciarlos rápidamente. Es como una llama piloto de gas, pequeña pero capaz de encender la llama completa en cuestión de minutos cuando sea necesario. El RTO suele ser de 30 a 60 minutos.

Cuando la región principal falla y se activa el failover de Pilot Light: Paso 1: promueva la réplica de lectura de RDS de la región de recuperación a una base de datos principal independiente. Paso 2: lance instancias de EC2 a partir de la AMI o la plantilla de lanzamiento previamente preparadas. Paso 3: cree o active el Application Load Balancer y registre las nuevas instancias de EC2. Paso 4: actualice la configuración de la aplicación para que apunte al endpoint de la base de datos promovida. Paso 5: el failover de la comprobación de estado de Route 53 completa el cambio de DNS. Tiempo total: 30 a 60 minutos.

En la estrategia Warm Standby, una versión completa, pero reducida, de su entorno de producción se ejecuta continuamente en la región de recuperación ante desastres. Todas las capas de la aplicación están activas —servidores web, servidores de aplicaciones y base de datos—, pero con una capacidad reducida (por ejemplo, 2 instancias en lugar de 20). Durante el failover, aumenta la capacidad del entorno de recuperación para adaptarla a la carga de producción. Route 53 cambia automáticamente el tráfico mediante el failover basado en comprobaciones de estado. El RTO suele ser inferior a 15 minutos. Warm Standby es el nivel de recuperación ante desastres más utilizado para aplicaciones críticas para el negocio.

Aurora Global Database es la tecnología de base de datos ideal para la recuperación ante desastres con Warm Standby. El clúster de la región secundaria está siempre en ejecución y recibe continuamente la replicación (con un retraso de <1 segundo), y puede promoverse a principal en menos de 1 minuto, mucho más rápido que promover una réplica de lectura de RDS (lo que requiere detener la replicación y aplicar el retraso restante). Por ello, Aurora Global Database es la opción recomendada cuando el requisito de RTO se mide en minutos y no en decenas de minutos.

Tanto Pilot Light como Warm Standby dependen del enrutamiento de failover de Route 53 para redirigir automáticamente el tráfico. Configure un registro Primary que apunte al ALB o endpoint de la región de producción y asígnele una comprobación de estado. Configure un registro Secondary que apunte al endpoint de la región de recuperación. Cuando Route 53 detecta que la comprobación de estado principal ha fallado durante el umbral configurado, deja de devolver el registro principal y solo sirve el registro secundario, todo ello dentro del periodo de TTL de DNS.

Para que Warm Standby alcance su objetivo de RTO, el entorno de recuperación ante desastres debe estar precalentado: completamente configurado y probado, de modo que aumentar la capacidad durante el failover sea la única acción necesaria. Esto significa que las conexiones de base de datos están establecidas y en caché, los archivos de configuración de la aplicación hacen referencia a los endpoints de la región de recuperación, las instancias de EC2 están en servicio detrás del ALB (aunque sean pocas) y las comprobaciones de estado se realizan correctamente. Realice simulacros mensuales de recuperación ante desastres en los que simule un failover para asegurarse de que el entorno se mantiene actualizado con la configuración de producción.

Mantener el entorno de recuperación ante desastres sincronizado con producción es el desafío operativo más difícil. Si configura producción manualmente y olvida actualizar la recuperación ante desastres, es posible que el entorno no funcione correctamente durante un desastre real. La solución es utilizar Infrastructure as Code (IaC) con las mismas plantillas implementadas en ambas regiones. Utilice AWS CloudFormation StackSets o Terraform con varios espacios de trabajo para implementar una infraestructura idéntica en ambas regiones desde una única base de código. Esto elimina la desviación de configuración.

La diferencia de coste entre ambas estrategias es considerable. Pilot Light solo implica el coste de la réplica de la base de datos (normalmente entre el 50 y el 100 % del coste de la base de datos principal), además de un coste mínimo de red en la región de recuperación. Los servidores de aplicaciones están apagados, por lo que no hay costes de EC2. Warm Standby añade el coste de ejecutar instancias de EC2 a menor escala, un ALB y, posiblemente, un clúster de caché más pequeño: normalmente entre el 15 y el 30 % del coste total del entorno de producción. La cuestión es si el RTO más rápido de Warm Standby justifica el mayor coste continuo.

Una vez restaurada la región primaria, necesita un plan de failback para volver a utilizarla. El failback suele ser la parte más compleja de la recuperación ante desastres (DR): durante la interrupción, es posible que la región de DR haya procesado datos nuevos que deban sincronizarse con la región primaria. En el caso de las bases de datos, puede ser necesario configurar la replicación inversa o volver a sincronizar los datos desde la región de DR hacia la primaria. Para Route 53, debe restablecer el registro primario con su comprobación de estado. Planifique y pruebe siempre el procedimiento de failback con el mismo cuidado que el failover.

Elija Pilot Light cuando su RTO permita entre 30 y 60 minutos y desee minimizar los costes de DR. El principal riesgo es el tiempo necesario para lanzar y configurar los servidores de aplicaciones durante un desastre y bajo presión. Elija Warm Standby cuando su RTO requiera una recuperación en menos de 15 minutos, cuando su aplicación sea lo bastante compleja como para que lanzarla desde cero durante un desastre resulte arriesgado, o cuando su compromiso de SLA con los clientes exija una recuperación más rápida. Para la mayoría de las cargas de trabajo de producción de criticidad media, Warm Standby ofrece el equilibrio adecuado.

Compruebe sus conocimientos sobre los conceptos de AWS Solutions Architect (SAA-C03) tratados en esta lección.

En esta lección ha aprendido que Pilot Light mantiene únicamente la base de datos en ejecución en la región de DR y lanza los servidores de aplicaciones durante el failover, que Warm Standby ejecuta un entorno completo a menor escala que aumenta su capacidad durante el failover y que Infrastructure as Code evita la desviación de configuración entre los entornos primario y de DR. Pruebe y planifique siempre los procedimientos de failback, además de los de failover. A continuación, exploraremos la configuración activa-activa en varios sitios con DynamoDB Global Tables y Route 53.