Blog de Amazon Web Services (AWS)
Automatización de la replicación para recuperación ante desastres con CloudEndure y Ansible
Por Juliano Fernandes Baeta, Arquitecto de Soluciones para Integradores Globales de Sistemas
La continuidad del negocio es un aspecto crítico para muchas empresas de diferentes industrias. Los desastres pueden afectar a los ingresos, causar pérdida de datos y dañar la reputación de una empresa. Dependiendo del negocio, el punto de recuperación objetivo (Recovery Point Objective, RPO por sus siglas en ingles) y el tiempo de recuperación objetivo (Recovery Time Objective , RTO por sus siglas en inglés) pueden ser más agresivos y una ventana de horas puede no ser aceptable. Existen algunas estrategias de configuración que tendrán un impacto directo en los valores de RPO y RTO, que van desde «sin contingencia» hasta una solución de recuperación ante desastres altamente automatizada.
¿ Por qué CloudEndure Disaster Recovery?
Ahí es donde CloudEndure Disaster Recovery entra en juego. Puede usarlo para proteger sus bases de datos más críticas, incluidas Oracle, MySQL y SQL Server, así como aplicaciones empresariales como SAP.
CloudEndure Disaster Recovery replica continuamente sus máquinas (incluido el sistema operativo, la configuración del estado del sistema, las bases de datos, las aplicaciones y los archivos) en un área transición (staging, en inglés) de bajo costo en su cuenta de AWS de destino y región preferida. En caso de desastre, puede indicar a CloudEndure Disaster Recovery que inicie automáticamente miles de máquinas en su estado completamente aprovisionadas en cuestión de minutos.
Al replicar sus máquinas en el área de transición y seguir siendo capaz de ejecutar máquinas completamente aprovisionadas en cuestión de minutos, CloudEndure Disaster Recovery puede reducir significativamente el costo de su infraestructura de recuperación ante desastres.
CloudEndure Disaster Recovery también facilita las pruebas recurrentes que exige un entorno de recuperación ante desastres. Gracias a esta función es posible crear un entorno de prueba simulando un desastre sin afectar la producción o la sincronización de datos. De esta manera, puede validar el tiempo y los procedimientos para el ascenso del entorno de desastre de forma automatizada. Además, un registro de actividades ayuda a verificar que estas pruebas se llevan a cabo regularmente con fines de auditoría o cumplimiento.
¿ Por qué Ansible?
Ansible es una herramienta de administración de configuración sin agente de código abierto que se conecta a máquinas remotas mediante SSH o Administración remota de Windows para realizar sus tareas. Puede ejecutar Ansible desde máquinas locales, en la nube o incluso desde su portátil, siempre y cuando tenga el acceso necesario a máquinas remotas.
Descargar, instalar y configurar cualquier herramienta, una por una en cientos o incluso miles de máquinas, puede ser propenso a errores, tedioso, lento e ineficiente. Ansible puede simplificar enormemente el proceso de protección de sus máquinas a través de CloudEndure Disaster Recovery realizando las mismas tareas en paralelo para varias máquinas remotas.
Objetivo:
En esta publicación, configuraremos nuestro entorno CloudEndure Disaster Recovery, automatizaremos la descarga, la instalación y la replicación en varios servidores CentOS a través de un playbook de Ansible. Al final, lanzaremos algunas instancias de Amazon EC2 en la región de destino como parte de una prueba de recuperación ante desastres.
Arquitectura:
CloudEndure Disaster Recovery replica continuamente su entorno en volúmenes de EBS utilizados como transición. Esta replicación se realiza mediante instancias de transición, denominadas Staging Area Replication Servers en la figura 1. No es necesario configurar estos servidores; se crean automáticamente como parte del proceso al replicar el primer servidor. Además, las instancias EC2 de destino solo se inician cuando se prueba o se inicia una conmutación por error, lo que proporciona una solución rentable ya que no existe un entorno informático duplicado.
Figura 1: Arquitectura de CloudEndure
Requisitos:
- Una cuenta de AWS: Si no tiene una cuenta de AWS, siga estas instrucciones para abrir una.
- Licencias de recuperación ante desastres de CloudEndure: Se pueden comprar a través de AWS Marketplace.
- Ansible instalado: Un ordenador portátil, escritorio u otra máquina con Ansible instalado. Si no tiene Ansible, visite esta documentación para ver cómo proceder.
- Servidores remotos: Uno o más servidores lo replican a través de CloudEndure Disaster Recovery. Puede iniciar una instancia de Amazon EC2 para sus pruebas.
- Conectividad de red: Se requiere la siguiente conectividad de red:
- Comunicación a través del protocolo TCP en el puerto 443:
- Entre las máquinas de origen y CloudEndure Service Manager.
- Entre el área de transición(staging) y CloudEndure Service Manager.
- Comunicación a través del protocolo TCP en el puerto 1500:
- Entre las máquinas de origen y el área de transición.
- Comunicación a través del protocolo TCP en el puerto 443:
¡ Manos a la obra!
Inicie sesión en la consola de CloudEndure utilizando la siguiente dirección URL:
https://console.cloudendure.com/#/signIn
Figura 2: Inicio de sesión en la consola de usuario de CloudEndure
La experiencia de CloudEndure se basa en Proyectos, que son las unidades organizativas básicas para sus migraciones o entornos de recuperación ante desastres. Después del proceso de inicio de sesión, haga clic en el icono en la esquina superior izquierda para crear un nuevo proyecto:
Figura 3 – Icono en la esquina superior izquierda para crear un nuevo proyecto
Rellene los cuadros con el nombre del proyecto, el tipo de proyecto y elija la licencia correspondiente. Para el tipo de proyecto, elija «Disaster Recovery». Después de completar la información, haga clic en «CREATE PROJECT»:
Figura 4: Crear nuevo proyecto
La siguiente ventana emergente le guiará a través de la configuración del proyecto. Haga clic en «Continue»:
Figura 5: Proyecto creado pero no configurado aún
En «AWS CREDENTIALS», especifique el ID de clave de acceso de AWS y la clave de acceso secreto de AWS. CloudEndure llama a las API apropiadas para replicaciones a través de esta clave de acceso. Si no tiene un usuario de IAM con los permisos necesarios para que CloudEndure funcione, consulte esta documentación.
Figura 6: Credenciales de AWS para el proyecto
En «REPLICATION SETTINGS», seleccione la región de origen, la región de destino, el tipo de instancia del servidor de replicación, el tipo de disco predeterminado y la subred donde se iniciarán los servidores de replicación. En el siguiente ejemplo, estamos definiendo un entorno primario en América del Sur (sa-east-1) con el objetivo de Recuperación ante Desastres en Norte de Virginia (us-east-1):
Figura 7: Configuración de replicación para el proyecto
Una vez finalizada la configuración del proyecto, haga clic en el botón «SHOW ME HOW»:
Figura 8: Configuración del proyecto finalizada
La siguiente ventana muestra instrucciones para agregar máquinas para la replicación, que incluyen el token de instalación del agente y los comandos adecuados para descargar y ejecutar el instalador de CloudEndure. Usaremos esta información para crear nuestro sencillo playbook Ansible:
Figura 9 – Instrucciones de adición de máquinas
En su equipo Ansible, defina los hosts donde se instalará CloudEndure. En el ejemplo siguiente, se creó un grupo de hosts llamado «aws» y se hará referencia más adelante en el playbook de Ansible. Además, establecemos la variable «ansible_user» como «centos» para especificar el usuario del sistema operativo que Ansible utilizará para realizar conexiones remotas.
$ cat /etc/ansible/hosts [aws] ec2-18-230-57-120.sa-east-1.compute.amazonaws.com ansible_user=centos ec2-54-207-23-166.sa-east-1.compute.amazonaws.com ansible_user=centos ec2-18-228-26-68.sa-east-1.compute.amazonaws.com ansible_user=centos ec2-18-230-6-97.sa-east-1.compute.amazonaws.com ansible_user=centos ec2-54-232-135-107.sa-east-1.compute.amazonaws.com ansible_user=centos ec2-18-228-241-215.sa-east-1.compute.amazonaws.com ansible_user=centos ec2-18-229-161-31.sa-east-1.compute.amazonaws.com ansible_user=centos ec2-54-94-30-48.sa-east-1.compute.amazonaws.com ansible_user=centos ec2-18-230-124-24.sa-east-1.compute.amazonaws.com ansible_user=centos
El archivo YAML del playbook de Ansible, tiene los siguientes parámetros:
- hosts: Los hosts donde se ejecutarán las sentencias. Como se mencionó anteriormente, estamos proporcionando un grupo llamado «aws» como los hosts remotos;
- gather_facts: Recopila y recopila información sobre máquinas remotas. Desactivaremos este módulo configurándolo en «false», para acelerar nuestra ejecución;
- tasks: Este libro consta de dos tareas (tasks), una para descargar el instalador y una para realizarlo.
La primera tarea utiliza el módulo get_url que es similar al comando wget recomendado por CloudEndure. Especificamos la URL, el nombre de archivo de destino, el owner, el, group y el mode. La segunda tarea ejecuta el comando como se especifica en la consola de CloudEndure. Para las tareas, también especificamos el parámetro «become: true» para elevar nuestros privilegios en el sistema operativo para ejecutar correctamente los comandos necesarios. En el comando «shell», reemplace la cadena siguiente después del indicador «-t» por la cadena de licencia especificada en la consola de CloudEndure.
$ cat cloud-endure.yaml --- - hosts: aws gather_facts: false tasks: - name: Download CloudEndure Installer get_url: url: https://console.cloudendure.com/installer_linux.py dest: /home/centos/install_linux.py owner: centos group: centos mode: '0755' - name: Install CloudEndure shell: /usr/bin/python /home/centos/install_linux.py -t AAAA-BBBB-CCCC-DDDD-EEEE-FFFF-GGGG-HHHH-IIII-JJJJ-KKKK-LLLL-MMMM-NNNN-OOOO-PPPP --no-prompt become: true ...
En su máquina Ansible, cuando ejecuta el playbook, Ansible se conecta a cada host especificado en el archivo de playbook. Si los hosts requieren una clave y los hosts comparten la misma clave, una manera fácil de ejecutar el playbook es crear una sesión agregando una clave de antemano, como en el siguiente ejemplo:
$eval «$(ssh-agent)» Agente pid 59392 $ssh-add -K [ruta a su archivo key.pem] Luego ejecute su playbook usando el comando ansible-playbook: $ ansible-playbook cloud-endure.yaml PLAY [aws] ***************************************************************************************** TASK [Download CloudEndure Installer] ***************************************************************************************** changed: [ec2-54-207-23-166.sa-east-1.compute.amazonaws.com] changed: [ec2-18-230-6-97.sa-east-1.compute.amazonaws.com] changed: [ec2-18-230-57-120.sa-east-1.compute.amazonaws.com] changed: [ec2-54-232-135-107.sa-east-1.compute.amazonaws.com] changed: [ec2-18-228-26-68.sa-east-1.compute.amazonaws.com] changed: [ec2-54-94-30-48.sa-east-1.compute.amazonaws.com] changed: [ec2-18-228-241-215.sa-east-1.compute.amazonaws.com] changed: [ec2-18-230-124-24.sa-east-1.compute.amazonaws.com] changed: [ec2-18-229-161-31.sa-east-1.compute.amazonaws.com] TASK [Install CloudEndure] ***************************************************************************************** changed: [ec2-54-207-23-166.sa-east-1.compute.amazonaws.com] changed: [ec2-18-230-6-97.sa-east-1.compute.amazonaws.com] changed: [ec2-18-230-57-120.sa-east-1.compute.amazonaws.com] changed: [ec2-54-232-135-107.sa-east-1.compute.amazonaws.com] changed: [ec2-18-228-26-68.sa-east-1.compute.amazonaws.com] changed: [ec2-54-94-30-48.sa-east-1.compute.amazonaws.com] changed: [ec2-18-228-241-215.sa-east-1.compute.amazonaws.com] changed: [ec2-18-230-124-24.sa-east-1.compute.amazonaws.com] changed: [ec2-18-229-161-31.sa-east-1.compute.amazonaws.com] PLAY RECAP ***************************************************************************************** ec2-18-228-241-215.sa-east-1.compute.amazonaws.com : ok=2 changed=2 unreachable=0 failed=0 ec2-18-228-26-68.sa-east-1.compute.amazonaws.com : ok=2 changed=2 unreachable=0 failed=0 ec2-18-229-161-31.sa-east-1.compute.amazonaws.com : ok=2 changed=2 unreachable=0 failed=0 ec2-18-230-124-24.sa-east-1.compute.amazonaws.com : ok=2 changed=2 unreachable=0 failed=0 ec2-18-230-57-120.sa-east-1.compute.amazonaws.com : ok=2 changed=2 unreachable=0 failed=0 ec2-18-230-6-97.sa-east-1.compute.amazonaws.com : ok=2 changed=2 unreachable=0 failed=0 ec2-54-207-23-166.sa-east-1.compute.amazonaws.com : ok=2 changed=2 unreachable=0 failed=0 ec2-54-232-135-107.sa-east-1.compute.amazonaws.com : ok=2 changed=2 unreachable=0 failed=0 ec2-54-94-30-48.sa-east-1.compute.amazonaws.com : ok=2 changed=2 unreachable=0 failed=0
Después de instalar el agente de CloudEndure en cada equipo, el proceso de replicación de datos debe comenzar inmediatamente y puede ver el progreso a través del panel de CloudEndure:
Figura 10: Progreso de la replicación de datos
Una vez completada la replicación inicial, debería ver en el panel el cuadro «Require Attention» con el número de máquinas replicadas. Esto significa que las máquinas se están replicando, pero nunca se han probado:
Figura 11: Mensaje «Requerir Atencion» en el panel de control
Mientras se replican las máquinas, puede configurar el blueprint de máquina de destino, que es el conjunto de instrucciones sobre cómo iniciar la máquina, deberá especificar valores como tamaño, subred, grupos de seguridad, direcciones IP y tipo de disco. Puede revisar cómo configurar el blueprint aquí.
Como práctica recomendada, es importante probar la recuperación ante desastres y puede hacerlo iniciando las máquinas en la región de destino en «Test Mode». Seleccione las máquinas que desea probar y en la esquina superior derecha, haga clic en «Test Mode»:
Figura 12: Lanzamiento de máquinas en la región de destino en modo de prueba
Confirme el lanzamiento de las máquinas de destino y haga clic en «NEXT»:
Figura 13: Confirmación de inicio de instancias
Los puntos de recuperación funcionan como una «máquina del tiempo» y puede volver a cualquier punto de tiempo disponible. En el siguiente ejemplo vemos que tenemos puntos en el tiempo cada 10 minutos, CloudEndure también proporciona puntos de tiempo consolidados para hasta hace 30 días.
Elija el punto de recuperación que desea probar y haga clic en «CONTINUE WITH LAUNCH»:
Figura 14: Elegir el punto de recuperación
Puede supervisar el inicio de las máquinas en la región de destino utilizando la opción «Job Progress» de la izquierda:
Figura 15: Progreso del trabajo
El estado de las máquinas probadas ahora cambia de «Require Attention» a «Ready».
Figura 16: Máquinas preparadas en el panel
En la consola de CloudEndure, el estado de «DESASTRY RECOVERY LIFECYCLE» se cambiará a «Tested Recently» para cada equipo probado durante este proceso. Para «DATA REPLICATION PROGRESS», el estado será «Continuous Data Protection».
Figura 17: Máquinas probadas recientemente
Al final de la prueba, en la consola de AWS, debería ver las instancias lanzadas en la región de destino:
Figura 18: Consola de AWS con máquinas lanzadas en la región de destino
Limpieza
Para evitar que se incurran en cargos futuros, elimine los recursos de las regiones de origen y destino y cancele la suscripción de CloudEndure en AWS Marketplace.
Conclusión
Con CloudEndure Disaster Recovery, puede simplificar la implementación y aumentar la confiabilidad al proporcionar replicación continua a una región de destino. CloudEndure Disaster Recovery permite RPO de subsegundos y, con la conversión y orquestación automatizadas, puede reducir el RTO a minutos. Con Ansible, puede asegurarse de que un entorno esté protegido por CloudEndure Disaster Recovery a escala ejecutando su libro de jugadas en cientos de máquinas locales o instancias de Amazon EC2.
Este artículo fue traducido del Blog de AWS en Portugués.
Sobre el autor
Juliano Fernandes Baeta es Arquitecto de Soluciones para Integradores Globales de Sistemas para América Latina. Es un entusiasta de Big Data, Analytics y Machine Learning y su misión es ayudar a los partners a crear soluciones seguras, eficaces y confiables en AWS.
Revisor:
Gustavo Fandiño es un Arquitecto de Soluciones, para América Latina. Ha realizado proyectos de modernización, migración y microservicios. Dentro de sus objetivos está el expandir el uso de AWS en el territorio y colaborar muy de cerca con los partners y clientes, para facilitar el uso y adopción de soluciones costos eficientes en AWS.