Recuperación ante desastres con AWS Elastic Disaster Recovery - Replicación continua y pruebas de recuperación
Replica servidores on-premises a AWS con replicación continua y verifica los procedimientos con simulacros de recuperación. Presentamos el flujo completo hasta el failback.
Descripción general de Elastic Disaster Recovery
Elastic Disaster Recovery (DRS) es un servicio que replica continuamente servidores on-premises o de otras nubes a AWS y permite una recuperación rápida en caso de desastre. Al instalar el AWS Replication Agent en el servidor de origen, los cambios a nivel de bloque se replican continuamente al área de staging en AWS a través del puerto TCP 1500. La sincronización inicial realiza una transferencia completa del disco, tras lo cual solo se transmiten los bloques modificados de forma incremental, manteniendo un RPO de segundos mientras se minimiza el consumo de ancho de banda de red. El agente es compatible con Windows Server 2012 R2 y posteriores, así como con las principales distribuciones Linux (Amazon Linux, RHEL, CentOS, Ubuntu, SUSE, Debian). El área de staging utiliza volúmenes EBS de bajo costo (gp3 o st1) para almacenar los datos del disco de origen sin compresión.
Simulacros de recuperación y failover
Los simulacros de recuperación son pruebas que lanzan instancias EC2 a partir de los datos replicados y verifican el funcionamiento de la aplicación. Se pueden ejecutar sin afectar la replicación de producción y permiten obtener valores reales de RTO. Los simulacros pueden restaurar un estado específico a partir de snapshots point-in-time, permitiendo especificar un momento anterior a la corrupción de datos. DRS retiene snapshots durante varios días, lo que lo hace adecuado para escenarios de recuperación ante ransomware. El failover lanza instancias EC2 con el mismo procedimiento que el simulacro y cambia el DNS para dirigir el tráfico de producción a AWS. La función Recovery Plan permite hacer failover por lotes de múltiples servidores desde la consola de DRS, definiendo el orden de lanzamiento y tiempos de espera para recuperar grupos de servidores interdependientes en la secuencia correcta. El failback devuelve los datos desde AWS al entorno on-premises original, lanzando un Failback Client dedicado en el sitio de origen mientras DRS gestiona la replicación inversa.
Diseño de red y automatización de recuperación
Los servidores de replicación de DRS se ubican en una subred de staging y reciben datos del servidor de origen. Las instancias que se lanzan durante la recuperación se ubican en una subred diferente (subred de recuperación), donde se predefine la configuración de red del entorno de producción. Con las plantillas de lanzamiento se configuran el tipo de instancia, grupo de seguridad, subred y rol IAM, minimizando el trabajo manual durante la recuperación. Con las acciones post-lanzamiento se automatizan el cambio de DNS y la configuración de la aplicación después del inicio de la instancia. La subred de staging no requiere acceso a internet de salida, permitiendo completar la replicación enteramente a través de conexiones privadas vía VPN o Direct Connect. También es posible mantener la IP privada del servidor de origen en la instancia de recuperación, preservando las configuraciones de aplicación que dependen de la dirección IP. Puede encontrar información sobre mejores prácticas de diseño DRP en libros relacionados (Amazon).
Precios de DRS y consideraciones sobre límites
Los precios de DRS se componen de las instancias EC2 del servidor de replicación y los volúmenes EBS. El servidor de replicación funciona con instancias pequeñas como t3.small, manteniendo un costo mensual relativamente bajo por servidor. Las instancias lanzadas durante simulacros o failover se cobran solo por el tiempo de ejecución. Los costos de almacenamiento de snapshots EBS se acumulan según el volumen de datos. Los límites importantes a considerar incluyen un máximo de servidores de origen por cuenta AWS; los entornos grandes pueden necesitar solicitar un aumento de cuota de servicio. El ancho de banda de replicación está limitado a un máximo de 10 Gbps por servidor, por lo que para servidores de bases de datos con alta escritura se debe estimar el tiempo de sincronización inicial. La replicación entre regiones también incurre en cargos de transferencia de datos entre regiones, siendo importante pre-calcular los costos mensuales para servidores de alta capacidad.
Comparación con otros enfoques de DR
AWS ofrece varios métodos para lograr DR además de DRS. AWS Backup proporciona copias de seguridad programadas basadas en snapshots con un RPO mínimo de aproximadamente una hora, pero con configuración más simple y menor costo. CloudEndure Disaster Recovery fue el predecesor de DRS y se recomienda la migración a DRS. El enfoque pilot light mantiene una configuración mínima de infraestructura siempre activa que se escala durante desastres, combinándola con RDS o Route 53 failover. Warm standby mantiene una configuración reducida similar a producción siempre activa, ofreciendo menor RTO pero mayor costo que DRS. La fortaleza de DRS radica en su RPO de segundos mediante replicación continua y la eliminación de entornos standby de tamaño completo siempre activos. Si solo se necesita DR para la capa de base de datos (por ejemplo, RDS Multi-Region Read Replica más Route 53 failover), puede implementarse una solución más simple sin DRS.
Mejores prácticas de diseño y errores comunes
Al adoptar DRS, programe simulacros de recuperación mensuales para validar los procedimientos y la funcionalidad de las aplicaciones. Versione los scripts usados en las acciones post-lanzamiento y verifíquelos con simulacros después de cada cambio. Un error común es que el agente de replicación se detenga tras parches del SO en el servidor de origen. Construya una alarma de CloudWatch para detectar cuando el retraso de replicación supere un umbral. Además, cuando los servidores de origen están unidos a un dominio de Active Directory, verifique previamente la configuración DNS y la conectividad con los controladores de dominio para que las instancias de recuperación puedan reunirse al dominio. Al usar Recovery Plans, documente las dependencias entre servidores (orden de inicio DB, luego App, luego Web) y defina correctamente los grupos de lanzamiento y tiempos de espera. Antes de iniciar el failback, confirme primero la restauración de la red del sitio de origen y verifique que el Failback Client pueda conectarse al servidor staging de AWS.
Resumen
Elastic Disaster Recovery es un servicio de DR que reduce el RPO a segundos mediante replicación continua y logra la recuperación en minutos. Las plantillas de lanzamiento y Recovery Plans predefinen la configuración de instancias y el orden de inicio para la recuperación, y las acciones post-lanzamiento automatizan el cambio de DNS. Los simulacros periódicos validan los objetivos de RTO/RPO, y la recuperación point-in-time proporciona protección contra ransomware. Comparado con enfoques basados en backup el RPO es dramáticamente menor, y comparado con standby siempre activo los costos se reducen significativamente, haciendo de DRS una solución de DR bien equilibrada.