Azure Traffic Manager
Cuando queremos distribuir el tráfico entre diferentes máquinas virtuales o entre diferentes servicios pensamos automáticamente en los balanceadores de carga. En Azure podemos desplegar varios tipos de balanceadores de carga:
![](/wp-content/uploads/2019/02/1.jpg)
En muchos casos, los balanceadores de carga que podemos desplegar tienen como limitación que los recursos entre los que queremos balancear la carga deben encontrarse en la misma región, o en algunos casos en la misma VNet.
En este post queremos distribuir la carga entre recursos que se encuentran en diferentes regiones de Azure y para conseguir esto vamos a utilizar Azure Traffic Manager.
Supongamos el siguiente escenario:
![](/wp-content/uploads/2019/02/2.jpg)
Traffic Manager se basa en el servicio DNS para redirigir las peticiones al endpoint más adecuado. Los tipos de endpoints soportados por Traffic Manager son máquinas virtuales, Web Apps y Cloud Service. También es posible utilizar Traffic Manager para endpoints que no pertenezcan a Azure.
- En nuestro esquema el cliente hace una petición de un recurso, por ejemplo, una Web App. Mediante DNS la petición llega a nuestra instancia de Traffic Manager.
- Traffic Manager utiliza un método de enrutamiento para seleccionar el endpoint. Un poco más adelante veremos en este post cuáles son los métodos de enrutamiento que podemos usar.
- Traffic Manager devuelve la respuesta DNS al cliente. En esta respuesta ya ha seleccionado el endpoint.
- El cliente se conecta directamente al endpoint. Esta conexión no pasa a través de Traffic Manager.
Traffic Manager lleva a cabo comprobaciones de salud (Health Checks) periódicas de los endpoints, por lo que proporciona alta disponibilidad con failover automático.
Vamos a configurar Traffic Manager para distribuir el tráfico entre dos Web Apps que tendremos en las regiones de Central US y East US. Ya tenemos los Resource Groups creados:
Vamos a configurar Traffic Manager para distribuir el tráfico entre dos Web Apps que tendremos en las regiones de Central US y East US. Ya tenemos los Resource Groups creados:
![](/wp-content/uploads/2019/02/3.jpg)
Y empezamos a crear las Web Apps por la de Central US:
![](/wp-content/uploads/2019/02/4-1024x487.jpg)
![](/wp-content/uploads/2019/02/2019-02-02_131632.jpg)
Le damos un nombre y le asociamos un App Service Plan de tipo F1 (Free):
![](/wp-content/uploads/2019/02/5-1.jpg)
Y repetimos el proceso para crear una Web App en la región East US:
![](/wp-content/uploads/2019/02/6.jpg)
![](/wp-content/uploads/2019/02/7.jpg)
Vemos que podemos acceder a cualquiera de ellas:
![](/wp-content/uploads/2019/02/8.jpg)
Y ahora vamos a crear la instancia de Traffic Manager para distribuir la carga entre las dos regiones. Creamos un Traffic Manager Profile:
![](/wp-content/uploads/2019/02/9.jpg)
Vemos que nos ofrece varios métodos de enrutamiento:
- Performance: Se utiliza para redirigir las peticiones al endpoint que tenga la latencia más baja respecto al cliente.
- Weighted: Nos permite especificar la cantidad de tráfico que va a recibir cada endpoint. Por ejemplo, si en Central US damos un peso de 7 y en East US un peso de 3, el 70% del tráfico irá a Central US y el resto a East US.
- Priority: Se utiliza cuando queremos que un endpoint reciba todo el tráfico y el resto actúen como reservas si el primero falla.
- Geographic: Redirige las peticiones en función de la localización geográfica más cercana al cliente, que no tiene por qué ser necesariamente la de menor latencia.
- Multivalue: Se utiliza cuando lo endpoints son direcciones IPv4 o IPv6.
- Subnet: Permite asignar rangos de direcciones IP origen a los endpoints de forma que cuando llega una petición se redirige al endpoint que tenga asignado el rango de IPs correspondiente.
Vamos a crear un perfil que utilice el tipo de enrutamiento Performance:
![](/wp-content/uploads/2019/02/10.jpg)
Una vez creado el perfil pasamos a configurarlo, para lo que vamos “Endpoints”:
![](/wp-content/uploads/2019/02/11.jpg)
Y añadimos las Web Apps que hemos creado como endpoints:
![](/wp-content/uploads/2019/02/12.jpg)
![](/wp-content/uploads/2019/02/13-1024x366.jpg)
En pocos segundos nos aparecerán los dos endpoints y en “Monitor Status” veremos “Online”:
![](/wp-content/uploads/2019/02/14.jpg)
Esto significa que los dos están disponibles y Traffic Manager repartirá la carga entre ambos.
Es posible habilitar la característica Traffic View para obtener información sobre localizaciones, volumen de peticiones e información de latencia para las conexiones, aunque esto tiene un precio adicional:
![](/wp-content/uploads/2019/02/15.jpg)
Y por último vamos a comprobar que está funcionando Traffic Manager. Para esto vamos a la pestaña Overview y comprobamos nuestra URL:
![](/wp-content/uploads/2019/02/16-1024x335.jpg)
![](/wp-content/uploads/2019/02/17.jpg)