Estrategias de recuperación ante desastres de AWS

La recuperación ante desastres es uno de los principales requisitos para hacer arquitecturas en la nube hoy en día. Este desastre puede ser un error de producción, una falla de los desarrolladores o tal vez una falla al final del propio servicio de AWS. La recuperación ante desastres es una parte esencial de las aplicaciones. Antes de sumergirnos en las estrategias de recuperación ante desastres de AWS, comprendamos algunos términos relacionados con la recuperación ante desastres.

Objetivo de tiempo de recuperación (RTO): RTO es el período de tiempo máximo en el que un servicio puede permanecer no disponible antes de dañar el negocio.   

Objetivo de punto de recuperación (RPO): RPO es el tiempo máximo durante el cual se pueden perder los datos si un sistema deja de funcionar.

En el ejemplo anterior, el sistema se cae a las 2 pm y se recupera a su estado normal a las 6 pm de la tarde. Esto significa que el objetivo de tiempo de recuperación para la situación anterior es de 4 horas. Del mismo modo, digamos que el escenario anterior realiza una copia de seguridad cada 2 horas y que la última copia de seguridad del sistema se realizó a las 12 p. m. (marcada con la flecha verde). Dado que el sistema se cayó a Esto significa que los datos entre las 12:00 p. m. y las 2:00 p. m. se pierden y solo se pueden recuperar los datos o el estado del sistema a las 12:00 p. m. Esto significa que el objetivo del punto de recuperación para el problema anterior es de 2 horas.

La elección de su arquitectura y solución de copia de seguridad de datos dependerá únicamente de cuánto RPO y RTO puede soportar su aplicación sin ser perjudicial para su negocio.

Diferentes estrategias de recuperación ante desastres

Copia de seguridad y restaurar:

En esta estrategia, toma instantáneas frecuentes de sus datos almacenados en volúmenes de EBS y bases de datos RDS y almacena estas instantáneas en un espacio de almacenamiento confiable como AWS S3. Puede crear regularmente AMI de sus servidores para preservar el estado de su servidor. Esto preservará todo el software y las actualizaciones de software en su servidor y los permisos de IAM asociados con el servidor. Backup and Restore básicamente usa AWS como su biblioteca de cintas virtuales. Esta estrategia no solo se puede realizar para las aplicaciones de AWS, sino también para sus aplicaciones locales. AWS Storage Gateway le permite tomar instantáneas y hacer copias de seguridad de sus volúmenes locales y almacenar estas instantáneas en AWS S3. Esta es la más lenta de las estrategias de recuperación ante desastres y se utiliza mejor de acuerdo con otras estrategias. Almacenamiento de datos de copia de seguridad en AWS Glacierpuede ayudar a reducir aún más los costos de la estrategia.

• RTO- Alto (Ejemplo: 10-24 horas)
• RPO- Depende de la frecuencia de las copias de seguridad. Que puede ser cada hora, cada 3 horas, cada 6 horas o diariamente.

Luz piloto: 

En esta estrategia, una versión mínima del entorno de producción se mantiene ejecutándose en AWS. Esto no significa que toda la aplicación se reduzca (modo de espera cálido), sino configurar y ejecutar solo el núcleo y los componentes más críticos del entorno de producción. Cuando ocurre un desastre, una aplicación completa se reinicia alrededor de este núcleo en ejecución. Pilot Light es más costoso que Backup and Restore ya que tiene algunos servicios mínimos de AWS ejecutándose todo el tiempo. Esta estrategia también implica el aprovisionamiento de infraestructura mediante scripts en la nube como los scripts de AWS CloudFormation para una restauración rápida y eficiente del sistema.

• RTO: alto pero menor que la copia de seguridad y la restauración. Ejemplo: 5-10 horas.
• RPO: igual que RPO para copia de seguridad y restauración, es decir, depende de la frecuencia de las copias de seguridad. Aunque se está ejecutando un entorno central mínimo, la recuperación de datos aún depende de las copias de seguridad.

Modo de espera caliente:

Como sugiere el nombre, la estrategia de espera cálida implica ejecutar una aplicación extremadamente reducida, pero completamente funcional, similar a su aplicación de producción que siempre se ejecuta en la nube. En caso de falla o desastre, la aplicación de espera en caliente se puede escalar inmediatamente para servir como la aplicación de producción. Los servidores EC2 se pueden dejar en ejecución en un número y tipo de servidor mínimos y se pueden escalar para servir como una aplicación completamente funcional utilizando las características de AWS AutoScaling . Además, en caso de falla, todos los registros DNS y las tablas de enrutamiento de tráfico se cambian para apuntar a la aplicación en espera en lugar de a la aplicación de producción. Para cambios rápidos de datos, los arquitectos tendrán que revertir los datos duplicados del sitio en espera al sitio principal cuando el entorno de producción principal se haga cargo.

• RTO: inferior a la luz piloto. Ejemplo: < 5 horas.
• RPO: Desde la última escritura de datos en la base de datos Multi-AZ maestro-esclavo.

Multisitio :

Como sugiere el nombre, la estrategia de sitios múltiples implica ejecutar una versión completamente funcional del entorno de producción como respaldo en la nube. Esta es una copia uno a uno de su aplicación principal que normalmente se ejecuta en una zona de disponibilidad diferente o en una región completamente diferente para mayor durabilidad. Esta es la más costosa de todas las opciones de recuperación ante desastres, ya que hace que sus costos de funcionamiento se dupliquen para ejecutar una sola aplicación. El costo general se compensa con el RPO y el RTO más pequeños que ofrece la estrategia de recuperación ante desastres multisitio. Sin embargo, los tiempos de RPO pueden variar de un sistema a otro según su elección de métodos de replicación de datos (sincrónicos y asincrónicos). Tan pronto como ocurre la falla, los desarrolladores solo tienen que cambiar los registros DNS y las tablas de enrutamiento para apuntar a la aplicación secundaria. 

• RTO: la más baja de todas las estrategias DR. Ejemplo: < 1 hora.
• RPO: la más baja de todas las estrategias DR. La elección de la replicación de datos afecta al RPO. Los últimos datos se escriben en una base de datos síncrona.

La computación en la nube es uno de los mayores activos para los desarrolladores e inversores que existen para crear aplicaciones simples y altamente eficientes y aún así tener una estructura de costos más económica. Las copias de seguridad de forma tradicional (no en la nube) pueden ser más costosas, ineficientes y propensas a problemas de hardware y errores manuales. AWS ofrece estrategias de copia de seguridad, no solo para las aplicaciones de AWS, sino también para sus aplicaciones locales que pueden aprovechar AWS para tener una copia de seguridad. Las copias de seguridad en la nube brindan muchos beneficios sobre el sistema de copia de seguridad tradicional. Como:

• Bajos costos
• Totalmente administrado por AWS.
• Seguro y confiable.
• Sin mantenimiento de hardware.
• Copia de seguridad fuera del sitio
• Fácil de acceder y probar utilizando la infraestructura de la nube.