Muchas organizaciones operan sus aplicaciones críticas desde un centro de datos propio. Sin embargo, cuando toda la infraestructura depende de una única ubicación física, cualquier incidente puede afectar la continuidad del negocio.
Cuando un único centro de datos representa un riesgo
Una empresa del sector industrial operaba todas sus aplicaciones desde un centro de datos propio, donde alojaba su infraestructura de virtualización basada en VMware. Entre sus cargas de trabajo se encontraban:
2 servidores de aplicaciones
- 16 vCPU
- 64 GB de memoria RAM
- 500 GB de almacenamiento SSD
1 servidor de base de datos Microsoft SQL Server
- 32 vCPU
- 128 GB de memoria RAM
- 4 TB de almacenamiento de alto rendimiento
1 servidor de archivos
- 8 vCPU
- 32 GB de memoria RAM
- 12 TB de almacenamiento
2 controladores de dominio Windows Server
- 4 vCPU
- 16 GB de memoria RAM
- 150 GB de almacenamiento
Toda esta infraestructura residía en un único centro de datos corporativo.
Estrategia de recuperación actual
La empresa contaba con una estrategia de respaldo tradicional basada en copias de seguridad programadas diariamente hacia un dispositivo de almacenamiento local y una copia externa. Si bien esta estrategia permitía recuperar la información en caso de incidentes, no garantizaba la continuidad inmediata de las operaciones.
Ante una falla crítica del centro de datos, el proceso de recuperación implicaba restaurar los respaldos, aprovisionar nuevamente la infraestructura y validar el funcionamiento de las aplicaciones antes de ponerlas en producción.
Como resultado, la organización manejaba los siguientes objetivos de recuperación:
- RTO (Recovery Time Objective): hasta 48 horas, tiempo estimado para restablecer la operación de los servicios.
- RPO (Recovery Point Objective): hasta 24 horas, con el riesgo de perder la información generada desde el último punto de recuperación disponible.
La problemática
La empresa contaba con una infraestructura con redundancia local y una estrategia de respaldos diarios, validada y probada periódicamente. Sin embargo, el mecanismo de recuperación se basaba en la restauración de las copias de seguridad, lo que implicaba un RTO de hasta 48 horas y un RPO de hasta 24 horas en un escenario de desastre mayor.
Si bien esta estrategia permitía recuperar la información, no era suficiente para garantizar la continuidad operativa de los servicios críticos, ya que los tiempos de recuperación y la posible pérdida de datos superaban los objetivos del negocio.
Ante un evento que comprometiera la disponibilidad del centro de datos —como una falla eléctrica prolongada, un incidente de hardware o un desastre natural—, las aplicaciones críticas podrían permanecer fuera de operación durante un periodo considerable mientras se restauraban los respaldos y se reconstruía la infraestructura.
La indisponibilidad de estos sistemas afectaría directamente la productividad de los colaboradores al impedir el acceso a aplicaciones esenciales para el negocio, generando retrasos en los procesos operativos y en la atención a los clientes. Asimismo, una interrupción prolongada podría impactar la imagen y reputación de la empresa, al comprometer la continuidad de los servicios y el cumplimiento de los acuerdos de nivel de servicio (SLA).
Por ello, la organización identificó la necesidad de complementar su estrategia de respaldos con una solución de recuperación ante desastres que permitiera reducir significativamente los tiempos de recuperación y minimizar la pérdida de información ante una contingencia
La solución
Con el objetivo de fortalecer la estrategia de continuidad del negocio, la empresa implementó AWS Elastic Disaster Recovery (AWS DRS) como solución de recuperación ante desastres.
Se instaló el agente de replicación en los servidores críticos, permitiendo replicar continuamente la información desde el centro de datos hacia AWS. Esta replicación se realiza a nivel de bloques y mantiene una copia actualizada de los servidores con un impacto mínimo sobre el ambiente de producción.
En condiciones normales, las aplicaciones continúan ejecutándose en el centro de datos de la empresa. En caso de una contingencia, AWS Elastic Disaster Recovery permite iniciar las réplicas como instancias de Amazon EC2, reduciendo significativamente los tiempos de recuperación y evitando la necesidad de construir un segundo centro de datos.
Al finalizar la implementación de Elastic Disaster Recovery se obtiene una arquitectura como se muestra en la imagen
Beneficios Obtenidos
La implementación de AWS Elastic Disaster Recovery permitió a la organización:
- Ejecutar pruebas de recuperación sin afectar el ambiente de producción.
- Automatizar el proceso de recuperación ante desastres.
- Reducir la complejidad operativa del plan de contingencia.
- Disminuir los tiempos de indisponibilidad de los servicios.
Conclusión
AWS Elastic Disaster Recovery permitió a la empresa evolucionar desde un esquema tradicional basado únicamente en respaldos hacia una estrategia moderna de recuperación ante desastres. Gracias a la replicación continua y a la capacidad de recuperar automáticamente los servidores como instancias de Amazon EC2, la organización fortaleció su continuidad del negocio sin realizar la inversión necesaria para construir un segundo centro de datos.
