Cerrar
InicioAzureMicrosoft Azure: Equilibrio de carga basado en DNS via Traffic Manager

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

Muchas empresas tienen presencial en internet de forma global, bien sea por una web corporativa como por aplicaciones web para dar servicio a diferentes clientes. Esto, en ocasiones (o casi siempre) conlleva en si mismo una problemática: como llevar al usuario final a su servicio web con cierta eficiencia. Ahí está el reto, ser capaces de hacer que los usuarios se conecten a los servicios que tenemos expuestos a internet de forma rápida desde cualquier parte del mundo.

Hoy voy a iniciar una serie de artículos donde vamos a publicar ciertos servicios de nuestra infraestructura, los cuales, tendremos ubicados en diferentes zonas geográficas y tendremos que ver la forma de entregarlas a los usuarios con la mayor eficiencia posible. Para ello, vamos a desplegar un servicio muy interesante que tenemos en Azure: Traffic Manager.

Traffic Manager es un servicio es un equilibrador de carga de tráfico basado en DNS, lo que nos permite distribuir el tráfico de forma óptima a servicios de regiones de Azure globales, además, nos proporciona alta disponibilidad. Esto nos vendrá muy bien para por ejemplo tener desplegados en Azure varios servidores Web o WebApp Service y publicarlos con balanceo de carga en la misma región y optimización de entrega de contenido en otras regiones del mundo. 

El siguiente esquema que os voy a mostrar muestra como facilitar el acceso a los usuarios a una web corporativa (web.dominio.com), la cual la tenemos desplegada en varios servidores web en Azure y en distintas regiones de Azure en el mundo:

Para este artículo, he desplegado varios servidores web (IIS)  los cuales vamos a utilizar para realizar las primeras pruebas de funcionamiento de Traffic Manager. A continuación os muestro los servicios utilizados para este artículo:

  • Zona DNS: asirlab.com
  • Servidor Web: ubicado en el Norte de Europa
  • Servidor Web: ubicado en el Oeste de Europa
  • Servidor Web: ubicado en Canada Central
  • Servidor Web: ubicado en el Este de US

Lo primero que haremos será desplegar el Traffic Manager y configurar el acceso a los dos servidores ubicados en Europa utilizando como método de enrutamiento la prioridad establecida manualmente por servidor. Antes de desplegar el Traffic Manager vamos a realizar algunas configuraciones necesarias:

  • Establecer una dirección IP Pública a cada servidor (esto luego lo podéis cambiar por balanceadores, etc… esto es un artículo de iniciación)
  • Establecer un nombre público asociado a la dirección IP Pública de cada servidor.

La configuración de una dirección IP Pública es muy sencilla, simplemente accedemos a la interface de red del servidor, editamos la dirección IP Privada y añadimos una IP Pública (la elegimos si ya la tenemos creada o la creamos en ese momento). Una vez que tenemos configurada la IP Pública en cada servidor, ahora accedemos a su configuración y añadimos un nombre DNS en cada IP de cada servidor, yo voy a utilizar webasirlab.región.cloudapp.azure.com:

Servidor del Norte de Europa: para que ver el nombre ya está disponible lo consulto vía PowerShell con el cmdlet Resolver-DnsName

Servidor del Oeste de Europa: para que ver el nombre ya está disponible lo consulto vía PowerShell con el cmdlet Resolver-DnsName

Todos los servidores tienen configurado un IIS con el siguiente script por servidor:

Install-WindowsFeature -name Web-Server -IncludeManagementTools
Remove-item C:\inetpub\wwwroot\iisstart.htm
Add-Content -Path “C:\inetpub\wwwroot\iisstart.htm” -Value $(“Servidor en el Norte de Europa”)

Install-WindowsFeature -name Web-Server -IncludeManagementTools
Remove-item C:\inetpub\wwwroot\iisstart.htm
Add-Content -Path “C:\inetpub\wwwroot\iisstart.htm” -Value $(“Servidor en el Oeste de Europa”)

*Lo mismo con el resto de los servidores (Canada Central y Este de US)

Ahora que ya tenemos todo lo necesario para este escenario, vamos a crear nuestro primer perfil de Traffic Manager. Desde el Portal de Azure  si ya tenéis un grupo de recursos, desde ahí pulsamos en Agregar:

Buscamos por Traffic y elegimos Traffic Manager Profile:

Pulsamos en Crear:

Ahora definimos un nombre para este nuevo perfil, tiene que ser un nombre único en Azure (es un servicio global) y elegimos un método de enrutamiento (por defecto está en Rendimiento, pero lo podemos cambiar en cualquier momento a posteriori), la suscripción. Para que tengáis información de los métodos del enrutamiento antes de continuar, aquí os dejo los diferentes métodos de enrutamiento disponibles (Métodos de enrutamiento del Administrador de tráfico):

  • Prioridad: Seleccione Prioridad cuando quiera usar un punto de conexión de servicio primario para todo el tráfico y proporcionar reservas en caso de que los puntos de conexión principal o de reserva no estén disponibles.
  • Ponderado: Seleccione Ponderado cuando quiera distribuir el tráfico entre un conjunto de puntos de conexión, bien de manera uniforme o en función a pesos definidos.
  • Rendimiento: Seleccione Rendimiento cuanto tenga puntos de conexión en ubicaciones geográficas diferentes y quiera que los usuarios finales utilicen el punto de conexión “más cercano” según la latencia de red más baja.
  • Geográfico: Seleccione Geográfico para dirigir a los usuarios a puntos de conexión concretos (Azure, Externo o Anidado) en función de la ubicación geográfica de la que parta su consulta de DNS. Esto permite a los clientes de Traffic Manager habilitar escenarios en los que es importante conocer la región geográfica de un usuario y enrutarlo en función de dicha región. Algunos ejemplos incluyen cumplir los mandatos de soberanía de datos, la localización del contenido y de la experiencia del usuario, y la medición del tráfico de otras regiones.
  • Multivalor: seleccione Multivalor para los perfiles de Traffic Manager que solo pueden tener direcciones IPv4/IPv6 como puntos de conexión. Cuando se recibe una consulta para este perfil, se devuelven todos los puntos de conexión correctos.
  • Subred: seleccione el método de enrutamiento de tráfico se subred para asignar conjuntos de rangos de direcciones IP de usuario final a un punto de conexión específico dentro de un perfil de Traffic Manager. Al recibirse una solicitud, se devuelve el punto de conexión asignado a esa dirección IP de origen de la solicitud.

Antes de pulsar en crear, os muestro una información adicional sobre la ubicación del grupo de recursos, importante tenerlo en cuenta para conocer el comportamiento del Traffic Manager:

Una vez que tengamos todo configurado, pulsamos en Crear, pero antes de hacerlo he cambiado el método de enrutamiento a prioridad:

Se inicia un proceso de validación…  

En cuestión de segundos tenemos creado nuestro perfil de Traffic Manager y pulsando en Ir al recurso podemos acceder a su configuración.

Cuando accedemos, de forma predeterminada (como todos los recursos en Azure) nos muestra información sobre el recurso creado/configurado.

Lo primero que haremos sería ir a la configuración del servicio, para ello nos vamos a la sección Configuración desde donde encontraremos las siguientes opciones disponibles que podemos modificar a nuestro antojo:

Creo que todos son bastantes descriptivos, voy a mostrar los protocolos que soporta y que serán los que el servicio comprobará para saber que servicio está activo y cual no. Tenemos el método de enrutamiento, el periodo de vida (TTL) de DNS, el cual se utilizará para mantener el registro DNS activo para que los usuarios se conecten al servicio activo.

Ahora tenemos que configurar los puntos de conexión, dichos puntos de conexión serán los servidores o servicios web que tengamos configurados y a los que queremos que los usuarios puedan conectarse. Debemos elegir varias configuraciones:

  • Tipo: nos permite elegir donde tenemos ubicado el servicio y el tipo de servicio
    • Azure: permite equilibrar la carga del tráfico a un servicio en la nube, aplicación web o dirección IP pública en la misma suscripción.
    • Externo: permite equilibrar la carga del tráfico a cualquier nombre de dominio completo (FQDN), incluso para aplicaciones no hospedadas en Azure.
    • Anidado: permite anidar diferentes Traffic Manager entre si (lo veremos más adelante)
  • Nombre: nombre que le damos al Endpoint

En función del tipo elegido veremos unas u otras opciones, como en mi caso he elegido Punto de conexión de Azure, el tipo de recurso de destino cambiará, en este caso nos mostrará los recursos ubicados en Azure:

Yo elegiré Dirección IP Pública, por lo que nos mostrará un listado de las IPs Públicas que tengamos configuradas en Azure, debemos elegir las que estén asociadas a las máquinas virtuales y tengan un nombre DNS asociado (de ahí el haberlo hecho previamente). Además, debemos darle una prioridad, porque recordad que el método de enrutamiento elegido por mi ha sido prioridad, de tal forma que debemos añadir diferentes Endpoint y asignarles diferentes prioridades (el número más bajo es el que más prioridad tiene, vamos, al que primero nos conectaremos) 

Tenemos que ir agregando tantos servidores como tengamos y queramos configurado para un mismo Traffic Manager, cada uno con su prioridad.

Una vez agregados, chequeará ambos puntos de conexión realizando diferentes testeos en base al tipo de monitor elegido (HTTP, HTTPS o TCP) en la configuración general del Traffic Manager.

Mientras esperamos que el estado de supervisión se complete, vamos a crear el registro DNS que utilizarán los usuarios finales para conectarse a nuestro servicio. Para ello, debemos crear un registro DNS de tipo CNAME que apunte el FQDN de nuestro perfil de Traffic Manager:

Y una vez que tengamos el FQDN del perfil de Traffic Manager, nos vamos al DNS (en mi caso Azure, de paso os dejo el enlace del artículo de como migrar los DNS a Azure: Microsoft Azure: Migración una zona DNS pública a Azure ) y crear el registro CNAME como os muestro a continuación:

Las conexiones se harán directamente a los servicios, no mediante el Traffic Manager, es importante que lo tengamos claro

Pues ahora lo único que nos queda es probar el acceso web a http://web.asirlab.com, en mi caso el servidor del Oeste de Europa era el que tenía el número más bajo en cuanto a la prioridad, con lo cual será el servidor “activo” para los usuarios que se conecten a él:

Si ahora paramos el servidor web (IIS) y , si teníamos la web abierta, veremos que durante uno segundos nuestro navegador está intentando conectarse …

Fijaros que aún no ha cambiado el estado de supervisión de los servidores, para Traffic Manager ambos están disponibles .. recordar que tenemos configurado unos timers a nivel global

En cuestión de segundos veremos como va cambiando el estado de supervisión, ahora el Endpoint con menos prioridad tiene un estado cambiado a Degradada:

Una vez que tenga el estado actualizado, veremos como la conexión se enviará al otro servidor (en mi caso Norte de Europa) y ya podremos conectarnos a él. Además, si ahora tiráis de PowerShell para ver la configuración del registro web.asirlab.com veréis como el CNAME apunta al Traffic Manager y ha cambiado la IP del servidor que responderá a las solicitudes de conexión web hacia web.asirlab.com de ahí que ya tengamos acceso a dicha web:

En cuanto recuperemos el servidor con mayor prioridad (menor número de prioridad), el DNS se volverá a actualizar y volveremos a conectarnos a dicho servidor (en mi caso el que tengo en la región del Oeste de Europa):

Habéis podido apreciar que funciona perfectamente, simplemente ajustamos prioridades y poco más, pero si ahora queremos que alguien de US se puedan conectar a nuestra web sin tener que atravesar el charco … pues vamos a configurar  el método de enrutamiento a Rendimiento:

  • Rendimiento: Seleccione Rendimiento cuanto tenga puntos de conexión en ubicaciones geográficas diferentes y quiera que los usuarios finales utilicen el punto de conexión “más cercano” según la latencia de red más baja.

Ahora la idea es  tener un tercer servidor web pero fuera de Europa, ahora lo vamos a implementar en US y concretamente en la región de Canada Central. Una vez configurado, nos vamos al perfil de Traffic Manager y cambiamos el método de enrutamiento a Rendimiento:

Añadimos el registro DNS a la IP Pública del servidor:

Y configuramos este nuevo destino en los Puntos de conexión de nuestro perfil de Traffic Manager:

Esperamos unos minutos a que se actualice el estado de supervisión:

En cuestión de 1  o 2 minutos si todo está correcto, podéis ver que el estado de supervisión está En línea para todos los servidores (mejor quedarnos con el término de Endpoints): 

Pues venga, ahora toca probarlo. A continuación os muestro una ventana de PowerShell con dos configuraciones a tener en cuenta:

  • Mi dirección IP Pública (los dos primeros octetos) para que se vea que es una IP de España
  • Resolución DNS para el registro web.asirlab.com y la IP del servidor al cual me va a llegar

Pues como podéis apreciar me está llevando al servidor con menos latencia para mi ubicación, en este caso al servidor del Norte de Europa:

Si ahora, me cambio de IP Púbilca de alguna zona de US veréis que el servidor al que me conecta es de la región de Canada Central, el servidor al que menos latencia tendría llegar si estoy en US.

Os comento que para cambiar de IP Pública lo que he hecho es utilizar Tunnel Bear, una aplicación que lanza una conexión VPN (sin split-tunneling) a diferentes partes del mundo y te conectas a Internet mediante su conexión y por tanto tu IP Pública será la que tenga el destino VPN al que me he conectado. De esta forma puedo probar este tipo de servicios, bueno, sino también creando otra VM en Azure en una región del US u otra parte del mundo y probarlo desde ahí, pero con Tunnel Bear es más práctico :-).

Como vemos funciona muy bien, rápido y sencillo, pero … y si ahora lo queremos hacer globalmente porque tenemos servidores  web diferentes regiones del mundo para que los usuarios de diferentes continentes puedan visualizar nuestra web de forma rápida …? Pues ahora veréis como se pueden utilizar diferentes perfiles de Traffic Manager encadenados para utilizar enrutamiento geográfico:

  • Geográfico: Seleccione Geográfico para dirigir a los usuarios a puntos de conexión concretos (Azure, Externo o Anidado) en función de la ubicación geográfica de la que parta su consulta de DNS. Esto permite a los clientes de Traffic Manager habilitar escenarios en los que es importante conocer la región geográfica de un usuario y enrutarlo en función de dicha región. Algunos ejemplos incluyen cumplir los mandatos de soberanía de datos, la localización del contenido y de la experiencia del usuario, y la medición del tráfico de otras regiones.

Para probar este servicio, lo que he hecho es crear otro servidor web en otra zona de US, ahora en la región de Azure del Este de US y configurado también su registro DNS para la IP Pública de la interface del servidor. Luego lo que haremos será crea dos perfiles más de Traffic Manager, unos para los servidores ubicados en Europa y otro para los de US:

La configuración de los nuevos perfiles de Traffic Manager es la siguiente:

Por último, la configuración del Tráffic Manager principal (el original que habíamos creado al principio del artículo) tendrá como método de enrutamiento Geográfico:

Y los Endpoint serán cada uno de los otros dos Traffic Manager y la configuración será la siguiente:

Ahora debemos elegir las regiones  y paises donde queramos que esta configuración tenga efecto, yo lo he hecho para Europa con Francia:

Para US con  Canadá y México

Más de lo mismo, se debe esperar a que se actualice el estado del Traffic Manager:

Y ahora toca probar, como vemos desde una IP de España me llevará al servidor con menos latencia por zona (método de enrutamiento: rendimiento):

Ahora haremos las prueba de conexión a los servidores de US, para ello cambiamos de IP Pública con Tunnel Bear y veremos que nos llevará  a algún servidor del Traffic Manager de US:

He modificado el fichero web para que muestre la región del servidor y así podemos ver que nos estamos conectando al servidor del Este de US:

En función de a donde me vaya conectando con Tunnel Bear voy saltando de servidor al que me conecto:

En esta ocasión lo que había hecho es cambiar la configuración del perfil del Traffic Manager de los servidores de US, he modificado el método de enrutamiento a prioridad dándole la prioridad más alta al servidor de Canadá y … ahí tenemos!!

Es muy sencillo manejarlo, además, en este caso lo he ajustado a web muy simples, pero se puede configurar con Azure Site Recovery para levantar en otra región nuestra infraestructura y no tener que tocar los DNS para nada (próximo artículo).

Por aclararlo, en la configuración más GEO, lo que habíamos hecho es crear tres perfiles de Traffic Manager, los cuales encadenamos para  manejar enrutamientos diferentes por destinos y en base al origen de las conexiones, muy potente y eso que solo hemos tocado la configuración básica.

Nota mental para recordar: Las conexiones se harán directamente a los servicios, no mediante el Traffic Manager, es importante que lo tengamos claro

Lo dejo aquí, sino este artículo sería inmenso, pero iremos descubriendo donde podemos ir aplicando Traffic Manager.

Ahora, como siempre, os toca a vosotros probarlo!!

Microsoft Azure: Mig
Microsoft Teams: con
NO HAY COMENTARIOS

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies
Share This