Microsoft Azure: Traffic Manager y Azure Site Recovery

Vamos a seguir viendo alguna de las aplicaciones prácticas que tiene Traffic Manager, en concreto con Azure Site Recovery. Si queremos/necesitamos tener un sitio de respaldo para nuestro CPD, podemos apoyarnos en la infraestructura que nos provee Azure para tener una réplica de una o todas nuestras máquinas (físicas o virtuales) en Azure.

Si en algún momento tenemos que ejecutar el proceso de recuperación  de nuestras máquinas, uno de los proceso en los que invertimos un tiempo “importante” es la reconfiguración de los registro DNS para que los usuarios puedan recuperar el acceso a los servicios. En la definición de RTO (Recovery Time Objective) debemos tener en cuenta el tiempo de recuperación/modificación de cada servicio implicado en la recuperación del servicio en su totalidad. Si podemos configurar servicios que se adapten a los cambios de forma automática, es tiempo que ganamos.

Hoy voy a comentar como Traffic Manager juega un papel “fundamental” en el proceso de recuperación de nuestro CPD, independientemente de donde esté ubicado (On-Premises o Azure). En este caso voy a mostrar la parte teórica en este artículo, pero haré referencia a otros artículos que había publicado en su momento para que podáis ver como ejecutarlo por partes. Mi idea es comentar las partes del proceso que son fundamentales para que podáis recuperar vuestro CPD, en el menor tiempo posible y con una topología muy común en las empresas:

Viendo la topología de la que partimos, vemos que tenemos en una región de Azure (Norte de Europa) activa con:

• 2 Controladores de dominio
• 1 Servidor web
• 1 Servidor de SQL
• 1 Servidor de Escritorio Remoto
• 2 Balanceadores con IPs Públicas

Y en la otra región de Azure (Oeste de Europa) tenemos los mismos servidores replicados vía Azure Site Recovery:

• 2 Controladores de dominio
• 1 Servidor web
• 1 Servidor de SQL
• 1 Servidor de Escritorio Remoto

Los 2 balanceadores (con sus IPs Públicas) es algo que tenemos que tener pre-configurado, para que, cuando tengamos que ejecutar el proceso de recuperación de nuestro servidores podamos realizar las configuraciones finales sobre los servidores que vayamos recuperando. Pues ahora vayamos comentado las diferentes configuraciones que debemos ir realizando para llegar a tener el entorno replicado y, como os había comentado, aquí va el primer enlace a un artículo que había escrito sobre  Azure Site Recovery en otra región de Azure:

• Azure: Site Recovery A2A

Ahí explico paso a paso como configurar la replicación de servidores de una región a otra en Azure, son tres sencillos pasos y tendréis vuestras máquinas replicadas. Pero antes de empezar con la replicación, voy a comentaros algo que debéis tener en cuenta para el proceso de recuperación sea lo más transparente posible.

Para que los equipos se puedan recuperar en otra región necesitarán un vNet ya en la otra región, sino queréis tener que reconfigurar las direcciones IP de los servidores, tenéis que:

• Configurar una vNet con el mismo espacio de direcciones IP
• Crear las subredes con el mismo nombre que la región principal
• El DNS para la vNet deben ser las IPs de los 2 controladores de dominio

Con esta configuración, cuando el servidor se recupera desde Azure Site Recovery se configurará en la subred correspondiente, asignará la misma IP y DNS que tenían en la vNet de la región original. Esto es fundamental, sino entonces si que tendréis que reconfigurar las IPs de todos los servidores y aquí el RTO se verá penalizado claramente, puesto que:

• Tendrías que acceder a cada servidor y cambiar su dirección IP
• Configurar cada servidor en cada subred manualmente (sino tiene el mismo nombre que la red original se configurará en cualquier subred)
• Cambiar los DNS de la vNet por la de los controladores de dominio con la IP que les hayamos asignado

Al final, esto es un tiempo precioso que estamos perdiendo y por lo tanto el RTO se ve aumentado, además, cuando más servidores .. más cambios manuales que tenemos que hacer.

Una vez que, tenemos la vNet de destino creada conforme a lo que he comentado en los puntos anteriores, entonces si podemos configurar el Azure Site Recovery: Azure: Site Recovery A2A. Aunque para este artículo es posible que no sea de mucha ayuda, seguro que si lo es para entornos de replicación desde On-Premises, aquí os dejo otros artículos que había publicado en su momento:

• Moviendo nuestros servicios y máquinas virtuales a Azure (Parte IV)
• Moviendo nuestros servicios y máquinas virtuales a Azure (Parte IV) – Parte II
• Reglas de QoS aplicadas evitando flujos de tráfico de datos incontrolados

Con esto tendríamos el proceso de recuperación de los servidores simplificado, pero lo que no podemos replicar son los balanceadores que tenemos en nuestra topología. Dichos balanceadores en esta configuración, simplemente es para mostraros que podemos añadirlos a nuestra topología y seguir utilizándolos una vez recuperado el CPD en otra región de Azure. Eso sí, tenemos que tenerlos pre-configurados ya son sus IPs Públicas, etc.. a la espera de recuperar los servidores y finalizar la publicación de los diferentes servicios hacia internet, que en mi caso era una Web y un RemoteApp vía TSGateway. A continuación os dejo un artículo sobre balanceadores en Azure:

• Azure: Balanceador de carga interno y Azure Firewall

Aunque aquí yo los haya utilizado para servicios internos, la configuración es “similar” para publicar servicios a internet con una IP Pública en el balanceador. Pero para que nada quede a la imaginación, aquí tenéis un artículo de MSFT donde lo explica muy bien: Tutorial: Configuración del enrutamiento de puerto en Azure Load Balancer mediante Azure Portal. Ya veréis que es muy sencillo, básicamente como “abrir” un puerto en el router (PAT).

Pues una vez que ya tenemos claro que configuraciones debemos aplicar a nuestro entorno de producción y recuperación, veamos como ajustar nuestros DNS con Traffic Manager. Cuando tengamos nuestro entorno recuperado en la otra región de Azure, tenemos que llevar las conexiones de los usuarios hacia las nuevas IPs Públicas que tenemos en los balanceadores. Sino contásemos con Traffic Manager tendríamos que cambiar los registros DNS de forma manual, esto al final, siempre puede ser un “foco de problemas” sino lo hacemos en tiempo y forma.  También os voy a dejar como configurar los DNS públicos en una zona de Azure, que, aunque el artículo es de como migrar nuestros NS a Azure se muestra como crear registros DNS:

• Microsoft Azure: Migración una zona DNS pública a Azure

Antes de seguir con la  configuración de Traffic Manager para este artículo, os dejo un artículo de iniciación sobre Traffic Manager para los que no conozcáis este servicio de balanceo de DNS de Azure:

• Microsoft Azure: Equilibrio de carga basado en DNS via Traffic Manager

Antes de continuar con la configuración a tener en cuenta del Traffic Manager, comentar que, en vez de tener dos balanceadores  con sendas IPs Públicas y configuraciones hacia los servidores internos, podríamos tener un Reserve-Proxy y y publicar los diferentes servicios mediante dicho servicio. Lo comento por si os lo habías planteado, es que hay múltiples configuraciones que se pueden implementar, pero mi idea es que las configuraciones comentadas siempre tengan un “plus” de “dificultad” y que veáis que hay muchos elementos en la red con los que podamos jugar.

Ahora si, después de conocer el punto más crítico de la recuperación que es tener una vNet igual que la principal (espacio de direcciones, nombres de las subredes, DNS) ahora le toca del turno al Traffic Manager para que tenga constancia de las IPs públicas y los servidores que está en activos en todo momento.

Como en el artículo tenemos dos IPs Públicas y sendos servicios por cada IP, tenemos que crearnos dos Traffic Manger uno por servicio. En mi caso, tengo una web y un RemoteApp vía TsGateway, por lo que son  todo servicios publicados en el puerto 443 y estos serían los registros DNS de cada servicio:

• web.dominio.com
• rds.dominio.com

La configuración por cada Traffic Manger tiene que ser la siguiente:

• Método de Enrutamiento: Prioridad

• Tipo Punto de Conexión: Punto de conexión externo para agregar el punto de conexión del servidor que estará en la zona  de recovery.

El método de enrutamiento tiene que ser prioridad, porque tenemos una región pasiva que es la que no tiene servidores activos, simplemente se utiliza Azure Site Recovery para mantener replicados los servidores de la región principal los cuales están activos. Pero, cuando agreguemos los puntos de conexión, el primero será de tipo Punto de conexión Azure, puesto que tenemos el servidor o balanceador funcionando, pero cuando agreguemos el segundo punto de conexión, tendrá que ser Punto de conexión externo porque como de momento no hay servidor, tendremos que poner la IP Pública que tendrá el servidor o balanceador cuando estén activos.

Con esto hemos dado por finalizada la configuración, ahora, cuando tengamos que ejecutar un Disaster Recovery Plan este será el proceso:

• Iniciar el proceso de recuperación de los servidores (Azure Site Recovery)
• Como las vNet está creada igual que la del site de producción, los servidores se asignarán en las subredes correspondientes y con las mismas IPs que tenían antes (sino tenéis algún hosts que la tenga cogida claro)
• Debemos ajustar manualmente la configuración del balanceador hacia los servidores publicados hacia internet

Con esto en funcionamiento ya Traffic Manager se encargará del resto, los usuarios tendrán un corte de servicio en base al RTO, pero en cuanto tengamos todo recuperado, los usuarios tendrán acceso a los servicios.

Como veis, no es muy complejo, es cuestión de tener algunos conceptos claros (sobre todo las vNets) y poco más, a disfrutar de un RTO optimizado!!!