Creación de una estrategia de recuperación ante desastres con AWS Elastic Disaster Recovery

Por Gabriel Marchelli, Startups Solution Architect y
Victor I. Yamashita, Startups Solution Architect

Intro

Muchos clientes comienzan su viaje a AWS en busca de una estrategia de recuperación ante desastres para su entorno on-premises. Las justificaciones para elegir un entorno de recuperación ante desastres son diversas, como la recuperación de incidentes impredecibles, proporcionar una mayor credibilidad a la organización, un mayor ahorro teniendo en cuenta que el costo de un escenario de indisponibilidad suele ser considerablemente superior al costo de un entorno de contingencia y, por último, lograr una alta disponibilidad.

Además de la estrategia de recuperación ante desastres del entorno on-premises o de otros proveedores de nube para AWS, los clientes también utilizan AWS Elastic Disaster Recovery (AWS DRS) en servidores que ya se ejecutan en AWS para crear una estrategia de recuperación ante desastres en otra región.

Las estrategias de recuperación ante desastres disponibles en AWS se pueden clasificar en cuatro enfoques, que van desde el bajo costo y la baja complejidad, pasando por la simple realización de copias de seguridad, hasta estrategias más complejas que utilizan varias regiones activas en AWS.

La elección de la estrategia correcta debe tener en cuenta variables como el RTO (objetivo de tiempo de recuperación), que se basa en el tiempo que tarda un sistema en recuperarse y reanudar sus actividades después de sufrir una indisponibilidad; así como el RPO (Recovery Point Objective), el cual consiste en la cantidad de datos que la empresa toleraría perder si se interrumpieran los sistemas.

Los 4 enfoques de recuperación ante desastres tomando en cuenta el RPO/RTO se pueden ver en la siguiente imagen:

AWS DRS permite a las organizaciones elaborar un plan de recuperación para sus aplicaciones con un tiempo de inactividad mínimo y sin cambios en las aplicaciones ni en su arquitectura. AWS DRS utiliza la estrategia Pilot Light, que mantiene una copia de los datos y los recursos necesarios para la replicación (instancias de replicación) en una nube privada virtual de Amazon (Amazon VPC), que se utiliza como área de ensayo. Cuando se desencadena un evento de failover, los recursos preparados se utilizan para crear automáticamente una implementación a plena capacidad en la Amazon VPC de destino, que se utiliza como ubicación de recuperación. Para obtener más información, consulte la documentación del servicio: https://docs.thinkwithwp.com/drs/latest/userguide/what-is-drs.html

La replicación de los datos en el área de preparación reduce los costos de recuperación ante desastres, teniendo en cuenta que los servidores se aprovisionarán en el entorno de contingencia solo cuando sea necesario. AWS DRS permite realizar pruebas sin interrupción para confirmar la integridad del proceso. Cuando sea necesario, podemos iniciar la operación de recuperación ante desastres, eligiendo entre el estado más reciente del servidor o algún punto de recuperación anterior. Una vez iniciada la operación de recuperación ante desastres, AWS DRS aprovisionará el nuevo entorno en unos minutos. Una vez que el problema se haya resuelto en su sitio principal, puede volver a intentarlo. En la continuación de esta entrada de blog, demostraremos cómo ejecutar todos estos procesos.

La siguiente Imagen ilustra cómo funciona AWS DRS:

En este blog, le mostraremos cómo configurar una solución de recuperación ante desastres con AWS DRS en 6 pasos, a saber:

Configuración de AWS DRS
Instalación del agente de replicación
Monitoreo de la replicación
Pruebas de integridad
Activación del entorno de DR
Replicación inversa y failback

Para esta demostración, configuramos un servidor de WordPress en la región de AWS Sudamérica (São Paulo) (sa-east-1) (https://docs.thinkwithwp.com/AmazonRDS/latest/UserGuide/Concepts.RegionsAndAvailabilityZones.html) para que funcione como nuestro centro de datos corporativo (figura 3) y crearemos nuestro entorno de recuperación ante desastres en la región de AWS del Norte de Virginia (us-east-1), donde se ubicarán el «área de ensayo» y la «zona de recuperación».

El primer paso consiste en definir la región de AWS que utilizará para su entorno de recuperación ante desastres y configurar la base, como Amazon VPC, subredes públicas/privadas, tablas de enrutamiento, grupos de seguridad, etc. Utilizaremos esta información y recursos para crear un modelo de ejecución (plantilla de lanzamiento) de Amazon Elastic Compute Cloud (Amazon EC2). Si desea comprender mejor qué son los modelos de ejecución, visite https://docs.thinkwithwp.com/pt_br/AWSEC2/latest/UserGuide/ec2-launch-templates.html.

Una vez creada la base, accederemos al servicio AWS DRS. Para ello, utilice el cuadro de búsqueda de la consola de AWS y busque AWS DRS o el menú Servicios/Storage/AWS Elastic Disaster Recovery.

Al acceder al servicio, si nunca ha utilizado AWS DRS en esta región, se le dirigirá a la página de configuración, donde en solo 4 pasos estará listo para iniciar la replicación.

Si ya ha realizado estos ajustes y desea modificarlos, puede hacerlo a través del menú Configuración.

1 – Configuración de AWS DRS

Paso 1: Configuración de los servidores de replicación

En este paso, definirá la subred del área de ensayo y el tipo de instancia de los servidores de replicación. Para obtener más información sobre la mejor forma de definir un tipo de instancia, visite https://docs.thinkwithwp.com/drs/latest/userguide/replication-server-settings.html?icmpid=docs_console_unmapped#instance-type.

Paso 2: Volúmenes y grupos de seguridad

Aquí definiremos el tipo de volumen que se utilizará en los servidores de replicación, el cifrado de volúmenes y los grupos de seguridad. Los valores que se muestran en la siguiente figura están configurados de forma predeterminada, pero puede personalizarlos según sea necesario.

Paso 3: Ajustes adicionales

En esta etapa, puede configurar si la comunicación entre los servidores locales y los servidores de replicación se realizará de forma pública (a través de Internet) o privada, mediante conexiones VPN, DirectConnect o VPC Peering.

También es posible limitar el ancho de banda de red utilizado en función de las limitaciones de conexión que tenga. Por ejemplo, si solo tiene un enlace de Internet en su entorno on-premises y los servidores deben utilizar parte de ese enlace, puede limitar el uso del ancho de banda para no afectar a esas comunicaciones.

Y, por último, el tiempo de retención de los snapshots(más común en español) generados y las etiquetas de asignación.

Paso 4: Revisión

Este último paso es una revisión de lo que se configuró. Revise, y si todo está correcto, haga clic en «Crear predeterminado».

Tras esta configuración, estaremos listos para instalar el agente en nuestro servidor local e iniciar la replicación.

Vale la pena recordar que estas configuraciones se pueden personalizar para cada servidor si es necesario.

2 – Instalación del agente de replicación

El agente de replicación AWS DRS es compatible con los sistemas operativos Linux y Microsoft Windows. Las versiones compatibles pueden ser consultadas en la documentación https://docs.thinkwithwp.com/drs/latest/userguide/Supported-Operating-Systems.html.

Durante la instalación del agente, se le solicitarán el ID de la clave de acceso y la clave de acceso secreta, que son las credenciales que permitirán a los servidores comunicarse con los servicios de AWS. Para crear estas credenciales, siga los pasos que se indican en la documentación https://docs.thinkwithwp.com/drs/latest/userguide/credentials.html.

Con las credenciales creadas, podemos continuar con la instalación del agente. Para ello, acceda al menú «Acciones/Agregar servidores de origen replicantes», ubicado en la pestaña «Servidores de origen» de AWS DRS, y haga clic en «Más información», o vaya directamente al enlace https://docs.thinkwithwp.com/drs/latest/userguide/adding-servers.html.

Al acceder a esta página, seleccionará el sistema operativo en el que desea realizar la instalación y seguirá las instrucciones. En el entorno mostrado, el servidor está basado en Linux. En este enlace puede encontrar la instalación paso a paso del agente https://docs.thinkwithwp.com/drs/latest/userguide/agent-installation-instructions.html

Tras instalar el agente, puede ver los servidores y realizar un seguimiento de todo el progreso de la replicación desde la pestaña «Servidores de origen» de AWS DRS. El primer estado que aparecerá es «Iniciando», que es la primera fase en la que AWS DRS configura las instancias de replicación, crea los componentes de red necesarios e inicia la replicación.

3 – Monitoreo de la replicación

Podemos rastrear el estado de la replicación accediendo a los detalles de cada «Servidor fuente». Si los pasos anteriores se han realizado correctamente, podrá ver el porcentaje de replicación, así como otra información relacionada con su servidor.

Algunos de los datos más relevantes sobre el estado de la replicación son:

Retraso: RPO (punto de recuperación objetivo)
Progreso de la replicación: el progreso en porcentaje de la replicación.
Registro atrasado: la cantidad (en MiB) de datos que se escribieron en el servidor y que aún no se han replicado en AWS DRS.

4 – Prueba de integridad

Es posible realizar una prueba de integridad del entorno de recuperación ante desastres; esta prueba aprovisionará los servidores de la región de AWS elegida. Este escenario permite validar el correcto funcionamiento de la estrategia de recuperación ante desastres.

Antes de realizar la prueba de integridad, es necesario validar que el «Servidor de origen» ya tenga el estado «Listo» dentro de la columna «Listo para la recuperación». Una vez validado el estado «Listo», el siguiente paso es seleccionar «Iniciar trabajo de recuperación» y, a continuación, seleccionar «Iniciar simulacro de recuperación».

El siguiente paso es elegir a partir de qué «puntos en el tiempo» quiere recuperarse. Los «Puntos en el tiempo» son imágenes del servidor de origen en diferentes momentos, donde puede elegir si desea utilizar la sincronización más reciente o elegir un momento anterior en el servidor. En este ejemplo, se eligió la versión más reciente y, después de elegir la opción deseada, simplemente se hizo clic en «Iniciar el simulacro».

Para hacer un seguimiento del estado de las pruebas de estado, puede hacer clic en «Historial de trabajos de recuperación» en la parte izquierda de la pantalla y, a continuación, en el «ID de trabajo» correspondiente:

En la siguiente pantalla, puede seguir todas las tareas que se realizaron hasta que finalice la recuperación y los registros de eventos aparecerán en el cuadro «Registro de trabajos». Tenga en cuenta que algunos registros de conversión aparecerán entre los registros; estos registros corresponden a la conversión automática que AWS DRS realiza para que las instancias sean compatibles con la nube.

Una vez finalizada la recuperación, observará que la nueva instancia aparecerá en la lista de instancias de Amazon EC2 (Cómo consultar las instancias de Amazon EC2: https://docs.thinkwithwp.com/AWSEC2/latest/UserGuide/concepts.html). A partir de ese momento, puede acceder a la instancia y validar la funcionalidad de DR. Tenga en cuenta que en el ejemplo solo hay una instancia, pero este ejemplo es escalable a toda una granja de servidores.

Para obtener más información sobre las pruebas de integridad, consulte la documentación de AWS DRS: https://docs.thinkwithwp.com/drs/latest/userguide/failback-overview.html

5 – Ativação do ambiente DR

En cualquier momento, podemos activar el entorno de recuperación ante desastres, que se aprovisionará de acuerdo con las configuraciones de instancia y red elegidas en la fase «Configuración de AWS DRS» del tutorial.

Antes de aprovisionar el entorno de recuperación ante desastres, es necesario validar que el «Servidor de origen» ya tenga el estado «Listo» en la columna «Preparado para la recuperación». Una vez validado el estado «Listo», el siguiente paso es seleccionar «Iniciar trabajo de recuperación» y, a continuación, seleccionar «Iniciar recuperación».

Luego, debemos elegir a partir de cual punto en el tiempo queremos hacer la recuperación. Los «puntos en el tiempo» son imágenes de los servidores de origen en diferentes momentos, donde puede elegir si desea utilizar la sincronización más reciente o elegir un momento anterior en el servidor. En este ejemplo, se eligió la versión más reciente y, después de elegir la opción deseada, simplemente haga clic en «Iniciar la recuperación».

Para realizar un seguimiento del estado del aprovisionamiento, puede hacer clic en «Historial de trabajos de recuperación» en la parte izquierda de la pantalla y, a continuación, en el «ID de trabajo» correspondiente.

La principal diferencia entre la prueba de integridad y la activación del entorno de recuperación ante desastres radica en la sincronización continua de los datos del entorno principal. Durante la prueba, los datos se siguen replicando en el área de ensayo, a diferencia de lo que ocurre durante la activación del entorno. Tras completar el aprovisionamiento del entorno de contingencia, se detiene la sincronización con el entorno principal. Si observamos la siguiente figura, podemos ver el estado «No iniciado» en la columna «Estado de lanzamiento en dirección inversa». El servicio está esperando el inicio de la replicación inversa para poder realizar un failback, que se espera tras resolver los problemas que provocaron la falta de disponibilidad del entorno principal.

Cuando termine de aprovisionar el entorno de recuperación, observará que la nueva instancia aparecerá en la lista de instancias de Amazon EC2 (Cómo consultar las instancias de Amazon EC2: https://docs.thinkwithwp.com/AWSEC2/latest/UserGuide/concepts.html). Tenga en cuenta que en el ejemplo solo hay una instancia, pero este ejemplo se puede replicar para todo una granja de servidores. Las instancias aprovisionadas en Amazon EC2 durante la prueba se finalizan automáticamente durante la activación del entorno de DR.

Para obtener más información, consulte la documentación de AWS DRS: https://docs.thinkwithwp.com/drs/latest/userguide/failback-overview.html

6 – Replicación inversa y Failback

Algo que nos preguntamos cuando tenemos un entorno de recuperación ante desastres activado es: ¿cómo mantener actualizado mi entorno on-premises? La respuesta a esto es la función de replicación inversa de AWS DRS, que permite sincronizar los datos modificados en los servidores, iniciados por el proceso de recuperación ante desastres, con los servidores on-premises, preservando la integridad de los datos y permitiendo una respuesta por recuperación más transparente.

Es posible llevar a cabo esta estrategia de replicación inversa para ambos escenarios, es decir, cuando tiene un entorno on-premises y realiza la recuperación ante desastres en AWS, o cuando sus servidores ya están en AWS y realiza la recuperación ante desastres en otra región. Sin embargo, para cada estrategia, la forma de configurar la replicación inversa es diferente.

Para habilitar la replicación inversa para su entorno on-premises, siga los pasos que se muestran en la documentación https://docs.thinkwithwp.com/drs/latest/userguide/failback-performing-on-prem.html o https://docs.thinkwithwp.com/drs/latest/userguide/failback-failover-drsfa.html, si su entorno se encuentra en VMware vCenter.

El siguiente ejemplo, de replicación inversa y failoback, corresponde al escenario de prueba que se presenta en esta entrada de blog, es decir, los servidores de origen son de Amazon EC2 y el entorno de recuperación ante desastres se encuentra en otra región de AWS. Para obtener más información, consulte la documentación https://docs.thinkwithwp.com/drs/latest/userguide/failback-failover-region-region.html.

Para simplificar la comprensión, a continuación puede ver la arquitectura de replicación inversa.

Primero, asegurémonos de que la recuperación ante desastres esté activada. Tras activar la recuperación ante desastres, seleccione la instancia de recuperación y haga clic en «Iniciar la replicación inversa», como se muestra a continuación. En este escenario, los bloques de disco de la instancia iniciada por Disaster Recovery comenzarán a replicarse en los servidores de replicación de la región de origen. AWS DRS utilizará los mismos mecanismos de replicación para la replicación inversa.

Si aparece un error que indica que el agente no está conectado a AWS DRS, compruebe primero que se cumplen todos los requisitos previos (https://docs.thinkwithwp.com/drs/latest/userguide/preparing-environments.html) y, a continuación, vuelva a instalar el agente mediante el parámetro «—install-as-recovery-instance» y pasando el ID de la instancia replicada como valor.

Ejemplo del comando:

sudo python3 aws-replication-installer-init.py —install-as-recovery-instance s-35def9e56643ef778

Una vez que la replicación inversa se haya iniciado correctamente, podrá realizar un seguimiento del estado del mismo modo que lo hizo para rastrear el estado de la instancia de recuperación, como se muestra en la siguiente imagen.

Una vez finalizada la replicación inversa, podemos ver en el AWS DRS de la región de origen, en este caso sa-east-1, un nuevo «servidor de origen», que hace referencia al servidor iniciado mediante la operación de recuperación ante desastres que se muestra a continuación.

Para iniciar la operación de failback simplemente seleccione los servidores que desee, haga clic en la opción «Iniciar para failback», seleccione el «punto temporal» que desee que inicie el failback.

Es importante recordar que todos los trabajos, ya sean de recuperación ante desastres o de recuperación por failback, pueden consultarse en el «Historial de trabajos de recuperación», que se encuentra en el menú lateral de AWS DRS. En la siguiente figura, podemos ver que el trabajo de failback por error se completó correctamente y se lanzó una nueva instancia de Amazon EC2 en la región de origen que contiene los datos actualizados del entorno de recuperación ante desastres.

Ahora podemos redirigir el tráfico al entorno local y listo, la operación de failback se completó correctamente.

Conclusión

En esta entrada de blog se describen algunas de las estrategias de recuperación ante desastres y se demuestra cómo utilizar el servicio AWS Elastic Disaster Recovery (DRS) para lograr una replicación continua entre el entorno on-premises y AWS. Entre las ventajas de utilizar esta arquitectura se encuentran el bajo RTO y el RPO y la posibilidad de realizar pruebas de integridad de su entorno de recuperación ante desastres.

Este artículo fue traducido del Blog de AWS en Portugués

Sobre os autores

Gabriel Marchelli es Startups Solution Architect en AWS.

Victor I. Yamashita es Startups Solution Architect en AWS

Blog de Amazon Web Services (AWS)