¿Cómo funciona el método Performance en Traffic Manager?

El método de Performance del Traffic Manager permite distribuir la carga dependiendo de la latencia más baja.

Recientemente recibí una pregunta muy interesante sobre cómo hacía Traffic Manager con el algoritmo de Performance para elegir la región más óptima entre los diferentes datacenters, donde agradezco enormemente a mi compañero Sergio Medina por su gran ayuda y sus pruebas donde podemos ver el funcionamiento del mismo.

La clave a la respuesta de la pregunta está en las siguientes líneas de la documentación:

https://msdn.microsoft.com/en-us/library/azure/dn339010.aspx

Traffic Manager locates the row in the Internet Latency Table for the IP address of the incoming DNS request. Because the user's local DNS server is performing an iterative DNS query to find the authoritative DNS server for the Traffic Manager profile name, the DNS query is sent from the IP address of the client's local DNS server.

Traffic Manager localiza la fila en la tabla de latencias de internet para la dirección IP de la petición DNS entrante. Debido a que el servidor DNS local realiza peticiones DNS iterativas para encontrar los servidores DNS autorizados para el nombre de perfil de Traffic Manager, la petición DNS es enviada desde la dirección IP del servidor DNS local del cliente.

Esto significa que si se configura un servidor DNS que esté cerca de nosotros se comportará bien.

El problema es que muchos usuarios configuran el DNS de Google 8.8.8.8, por facilidad de recordar, que está en Mountain View:

Geolocation data from IPligence (Product: Max updated on 11/30/2014)

IP Address

Country

Region

City

ISP

8.8.8.8

United States clip_image001[4]

California

Mountain View

Level 3 Communications Inc

Continent

Latitude

Longitude

Time Zone

North America

37.3801

-122.0865

PST

Google Map for MOUNTAIN VIEW, CALIFORNIA, UNITED STATES (New window)

Entonces aunque el cliente esté en Europa, Traffic Manager nos devolvería el Cloud Service con menos latencia a la dirección IP 8.8.8.8.

Esto es especialmente importante si desplegamos un servicio con Azure Traffic Manager y Cloud Services en distintas regiones del mundo, por ejemplo entre Estados Unidos y Europa. En ese caso los clientes de Europa que usen el DNS 8.8.8.8 se conectarían al Cloud Service de Estados Unidos. Aquí las pruebas que lo confirman:

Resolviendo con un DNS de Europa nos devuelve la IP del Cloud Service de Western Europe:

clip_image003

Sin embargo, resolviendo a través de ese DNS 8.8.8.8, nos devuelve la IP del Cloud Service de East US:

clip_image005

En conclusión, es muy importante que el servidor DNS local configurado sea próximo a nuestra localización y evitar los servidores DNS lejanos, pese a que algunos sean más fácil de recordar. En caso contrario, el impacto de rendimiento que tendremos será considerable y no deseado.

Un especial agradecimiento a Sergio Medina por las pruebas e información.

Sergio Guerrero Haro

Azure IaaS Premier Field Engineer