Azure Site Recovery es el servicio de recuperación que contribuye a la continuidad de negocio a la estrategia de recuperación ante desastres (BCDR) orquestando la replicación, la conmutación por error y recuperación de máquinas virtuales y servidores físicos. Este servicio, cuya capacidad y versatilidad está más que comprobada en entorno multihost (Enterprise to Enterprise E2E) o híbridos (Enterprise to Azure E2A) se ha enriquecido en los últimos tiempos con la adquisición por parte de Microsoft de InMage. Este software permite la salvaguarda de prácticamente cualquier plataforma, pero en particular viene a resolver un caso que a menudo nos encontramos en muchos clientes: La plataforma de virtualización VMWare.
Muchos clientes, en su etapa de virtualización, virtualizaron sus máquinas sobre plataformas host VMWare. Esta situación, hasta ahora, ha sido un impedimento para proteger sus máquinas con Azure Site Recovery, y en muchos casos ralentizaba su adopción por la necesidad de convertir de forma manual sus máquinas antes de ser subidas a la nube. Mediante el uso de InMage, y de nuevas herramientas que hay en camino nacidas de la integración entre ambos servicios, este camino ha sido allanado, y en este artículo vamos a hablar sobre cómo implementar Site Recovery en Azure para proteger VMs alojadas en un VMWare ESXi.
Algunas de las ventajas que ofrece son:
Arquitectura de la solución
Para empezar, un pequeño mapa de cómo va a funcionar:
El servidor de proceso debe ser un servidor virtual o físico Windows Server 2012 R2 y se recomienda que esté situado en el mismo segmento LAN y red que las máquinas a proteger, aunque es posible ejecutarlo en una red diferente siempre y cuando las máquinas protegidas tengan visibilidad con el servidor. Durante despliegue podrás configurar el servidor de procesos e inscríbete para el servidor de configuración.
El servidor maestro de destino posee los datos replicados de sus máquinas protegidas utilizando VHD adjuntos creados en el almacenamiento de blob en su cuenta de almacenamiento Azure. Un servidor maestro se puede implementar como una máquina virtual Azure ejecutando Windows 2012 R2 y basado en una de las imágenes de la galería cuando se van a proteger máquinas Windows, y como una servidor OpenLogic CentOS 6.6 cuando se van a proteger máquinas Linux. Para ambos casos, las opciones de dimensionamiento son A3 de la serie estándar, o D14 de la serie D. Este servidor debe estar conectado a la misma red de Azure que el servidor de configuración, y también ha de ser registrado en el servicio de Almacenamiento, y en el servidor de configuración.
Para la comunicación de datos y el canal de replicación existen un par de opciones. En ninguno de los casos se requiere abrir puertos de red en las máquinas protegidas, por lo que la seguridad se mantiene en todos los casos:
Opción 1: A través de una conexión site-to-site: Este canal seguro permite la comunicación y replicación desde la red local hasta Azure a través de una conexión segura y cifrada mediante un protocolo de IpSec
Opción 2: A través de una conexión ExpressRoute: Para los casos en los que se estima que existirá una alta demanda de traspaso de información hacia/desde la nube, y se requieren unos estándares muy altos de seguridad, es posible establecer la conexión VPN a través de ExpressRoute, la cual ejerce como una fibra negra entre nuestros entornos On-Premise y la nube y requiere ser contratada a través de un ISP Provider
Manos a la obra
Ya hemos repasado la teoría que sustenta la conexión, pero ahora, vamos a configurar una conexión segura.
Nos descargamos la versión más reciente de Azure Site Recovery para el servidor de Configuración.
Nota: Cada vez que se descarga una clave de registro, se genera una nueva y solo la última será la valida.
Añadimos una cuenta de almacenamiento. Debe ser con geo-redundancia activa en la misma región que la vault.
En este paso también vamos a instalar el agente del servidor de Proceso On-Premise
Debemos indicar la IP interna así como la URL del servidor de configuración por HTTPS
Una vez registrado veremos una pantalla como esta:
Configuramos la nube que va albergar las máquinas virtuales.
Nos descargamos el agente y lo instalamos en las VMs que vamos a proteger
Una vez instalado los agentes los veremos en la consola
Asignamos las redes de destino para las VMs tras la conmutación por error
Activamos la protección de las VMs ubicadas en la nube VMM
y por último, definimos el plan de recuperación, y lanzamos un test para comprobar que todo funciona adecuadamente
Una vez lanzado podemos ver usar la pestaña de Trabajos para seguir el proceso de replicación.
y eso es todo! esperamos que os haya parecido sencillo y si tenéis cualquier duda sobre el detalle del proceso, podéis aprovechar y escribirnos a cualquier de los dos autores
Fabián Calvo Valmorisco Gerente Soluciones Cloud Encamina fcalvo@encamina.com @rainfc https://blogs.encamina.com/elsextosharepoint
Israel Urrea Carballo Consultor Infraestructuras y Cloud Encamina iurrea@encamina.com
@israurrea