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:
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:
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:
Y empezamos a crear las Web Apps por la de Central US:
Le damos un nombre y le asociamos un App Service Plan de tipo F1 (Free):
Y repetimos el proceso para crear una Web App en la región East US:
Vemos que podemos acceder a cualquiera de ellas:
Y ahora vamos a crear la instancia de Traffic Manager para distribuir la carga entre las dos regiones. Creamos un Traffic Manager Profile:
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:
Una vez creado el perfil pasamos a configurarlo, para lo que vamos “Endpoints”:
Y añadimos las Web Apps que hemos creado como endpoints:
En pocos segundos nos aparecerán los dos endpoints y en “Monitor Status” veremos “Online”:
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:
Y por último vamos a comprobar que está funcionando Traffic Manager. Para esto vamos a la pestaña Overview y comprobamos nuestra URL:
