Conectando Microsoft Azure con Amazon Web Services: Traffic Manager

Como continuación del artículo anterior en el que explicábamos como conectar Amazon y Azure, basado en la charla que dimos Carlos Milán y yo en Global Azure BOOTCAMP 2015 de Madrid, vamos a dedicar un artículo del blog a explicar cómo balancear la carga entre las dos nubes.

Si recordáis el escenario que conseguimos montar, a través de una conexión VPN S2S teníamos visibilidad de las máquinas virtuales de ambas nubes como si estuvieran en la misma red local. Esto nos permitía dejar volar nuestra imaginación y construir prácticamente cualquier entorno.

¿Qué vamos a hacer?

La idea es continuar desarrollando un escenario un poco más complejo aprovechando que tenemos visibilidad entre ambas nubes. Lo que se nos ocurrió es montar una aplicación web que estuviera replicada, balanceada y con soporte de failover entre Amazon y Azure. Casi nada, eh 🙂

 

Como veis en el dibujo tenemos un bosque de AD replicando con DCs en cada nube, y unos servidores IIS que van a formar la granja sobre la que se hospedará la aplicación web. La sincronización de los cambios en la web será tanto a nivel de código como de configuración, pero la explicación de como lo hemos hecho nos la guardamos para otro post 🙂

Partiendo de que la aplicación web es la misma en todo momento si accedemos al IIS de Amazon y de Azure, ¿cómo podemos tener un balanceo real de la carga, y que además sea susceptible de hacer un failover si una nube entera falla? Aquí es donde entra en juego un servicio que nos proporciona Azure llamado Traffic Manager.

Azure Traffic Manager

Se trata de un servicio de balanceo de red basado en DNS. Básicamente lo que hacemos es establecer unos extremos o “endpoints” y en función de la política que elijamos dirigirá el tráfico de manera inteligente a los mismos.

Las políticas que podemos seleccionar son las siguientes:

• PERFORMANCE – Dirige al extremo “más cercano” basado en la latencia.
• ROUND-ROBIN – Distribuye equitativamente el tráfico entre todas las localizaciones. Se pueden establecer pesos.
• FAILOVER – Dirige a la localización de “backup” si el primario falla.

Citando directamente la documentación oficial, este servicio nos aporta las siguientes ventajas:

• Mejorar la disponibilidad de las aplicaciones críticas:  permite mejorar la disponibilidad de las aplicaciones críticas supervisando los extremos y ofreciendo funcionalidad de conmutación por error automática cuando un extremo deja de estar activo.
• Mejorar la capacidad de respuesta para las aplicaciones de alto rendimiento: Azure permite ejecutar servicios en la nube en los centros de datos ubicados en todo el mundo. Traffic Manager puede mejorar la capacidad de respuesta de las aplicaciones y los tiempos de entrega de contenido dirigiendo a los usuarios finales al extremo con la latencia de red más baja del cliente.
• Actualizar y realizar el mantenimiento del servicio sin tiempo de inactividad:  admite escenarios extendidos para implementaciones en la nube híbrida y locales, entre los que se incluyen los escenarios “burst-to-cloud”, “migrate-to-cloud” y “failover-to-cloud”.
• Distribución de tráfico para implementaciones grandes y complejas: con los perfiles anidados del Traffic Manager, en que un perfil puede tener otro perfil como extremo, puede crear configuraciones para optimizar el rendimiento y la distribución para implementaciones más grandes y complejas. Para obtener más información, vea Perfiles anidados.

Implementando el escenario

La implementación es tremendamente sencilla ya que únicamente debemos utilizar PowerShell para definir el perfil de Traffic Manager. No nos vale la interfaz gráfica dado que todavía no nos permite establecer extremos externos, como es Amazon en nuestro caso.

Vamos a analizar la configuración que nosotros definimos:

• TimeToLiveInSeconds: este valor representa el TTL (TimeToLive) durante el cual va a mantener los endpoints en la resolución DNS. Nosotros lo hemos establecido en el mínimo posible (30 segundos) para que en caso de caída de un extremo, ese cambio se refleje lo más rápido posible en todos los servidores DNS con los que nos podamos cruzar.
• MonitorRelativePath: es la ruta de la aplicación web que utilizará para monitorizar si el extremo está vivo. Básicamente intenta acceder y espera un 200 OK.
• MonitorPort: el puerto de monitorización.
• MonitorProtocol: el protocolo de acceso para la monitorización (http/https)
• LoadBalancingMethod: aquí definimos el tipo de política o método de balanceo que va a utilizar Traffic Manager. Entre los 3 que veíamos antes, nosotros escogimos Round Robin, y al no especificarle pesos, por defecto es 50%-50%.
• Endpoints: con este parámetro definimos todos los extremos de nuestra aplicación, en nuestro caso uno está en Azure y otro en Amazon.
• MonitorStatus: nos indica el estado del servicio de Traffic Manager y de los endpoints definidos.
• Name: es el nombre del perfil de Traffic Manager.
• DomainName: es el nombre de acceso a Traffic Manager y por ende a nuestra aplicación. Si luego definimos un CNAME como es lo usual, tenemos que apuntar a este registro. En nuestro caso tenemos azurezon.plainconcepts.com –> azurezon.trafficmanager.net.
• Status: los perfiles los podemos tener activados o desactivados, y eso nos da mucho juego. Imaginaros dos perfiles con los mismos endpoints, donde por defecto el perfil activo sea uno que funcione por “performance” pero ante cierta situación lo podamos cambiar a “failover”.

Este es el diagrama que nos quedaría:

Atendiendo a los parámetros que podemos configurar, y los tipos de balanceo que nos permite Traffic Manager, podemos conseguir escenarios tan interesantes como realizar una migración controlada de una nube a otra. ¿Os imagináis ir balanceando la carga de vuestra aplicación a otra nube e ir viendo como responde? Todo eso es perfectamente posible con Traffic Manager:

Otro detalle que debemos tener en cuenta, aunque el impacto es mínimo, es el precio de Traffic Manager y como varía en función de los endpoints. Por ejemplo un extremo “externo a Azure” tiene un coste que es casi el doble (€0,4022/mes), respecto a los extremos que estén en Azure (€0,2681/mes).

Una vez tengamos este entorno configurado, sólo nos queda… ¡la demo final!

Vamos a tirar abajo las máquinas de una nube y automáticamente el tráfico se balanceará a la otra, donde la aplicación estará replicada y actualizada.

Pero… ¿cuánto tiempo tarda Traffic Manager en darse cuenta de que un extremo está caído? Con el TTL de 30 segundos que hemos definido, la respuesta es… 2,5 min. Creo que dos minutos y medio para un failover entre entornos cloud de proveedores distintos no está nada mal 🙂

El dato del RTO (Recovery Time Objective) se calcula en base al número de intentos que realiza Traffic Manager antes de dar un extremo como “caído” (4), por el tiempo que espera entre cada intento (30 seg), más el TTL del registro DNS que tendrá que actualizar eliminando el extremo caído (30 seg): 4*30 + 30 = 150 seg = 2,5 min

En el siguiente gráfico se ve más claro:

Podéis encontrar más información al respecto en este artículo.

Con los dos entornos activos, y con clientes distribuidos geográficamente y sin pasar por los mismos servidores DNS intermedios, la distribución de la carga será homogénea.

 

Una vez el acceso a una de las nubes se vea afectada, como hicimos parando las máquinas de Amazon en nuestra demo, al cabo de 2,5 min todo el tráfico será dirigido únicamente a Azure.

Esperamos que os haya gustado esta segunda parte sobre como montamos un entorno de alta disponibilidad entre nubes y queda pendiente explicaros como hicimos para replicar la aplicación web.

Os dejamos con alguna foto más de la sesión, cortesía de Carmen.

Happy networking!