Cuando necesitamos distribuir el tráfico entre varias instancias de máquinas virtuales o de servicios en Azure tenemos varias opciones:
- Azure Load Balancer: Hace la misma función que un balanceador de carga de tipo NLB. Las máquinas virtuales se conectan al backend del balanceador de carga y la dirección IP pública se asigna al frontend. También implementa el servicio de NAT. El NAT inverso recibe la petición en la IP pública y la redirige a la máquina que el algoritmo considere como óptima en cada momento.
- Azure Application Gateway: Ofrece capacidades de
balanceo de carga geográfica, es decir, podemos balancear carga entre
diferentes regiones de Azure y garantizar que los usuarios siempre acceden a la
región que tienen más cerca. Tiene capacidades de Web Application Firewall:
- SSL Offloading: Descarga a los servidores del proceso de cifrar y descifrar la información mediante SSL.
- Enrutamiento basado en cookies de sesión
- Azure Traffic Manager: Es la parte de Application Gateway que se encarga del balanceo de carga entre regiones de Azure.
Y cada una de ellas está diseñada para escenarios de uso diferentes. Por supuesto, también es posible utilizar en Azure appliances para balanceo de carga creadas por otros fabricantes como F5.
En este post nos centraremos en la solución Azure Load Balancer.
Azure Load Balancer se parece a la característica Network Load Balancing (NLB) que se incluye en Windows Server, aunque añade nuevas capacidades y no está tan limitado como NLB. Trabaja en la capa 4 del modelo OSI usando los protocolos TCP y UDP para distribuir el tráfico entre los recursos que se encuentran en el backend del balanceador. Dispone de sonda de salud para monitorizar la disponibilidad de estos recursos y también de reglas de balanceo para configurar su modo de funcionamiento. A diferencia de la característica NLB, no tenemos que instalarla en cada una de las máquinas virtuales entre las que queremos balancear la carga.
Azure Load Balancer puede configurarse como un balanceador público o interno:
- Público: Tendrá una IP pública en el frontend en la que recibirá peticiones que repartirá entre las máquinas del backend.
- Interno: Tendrá una IP privada y no será accesible desde Internet. Igual que en el público, las peticiones que lleguen a la IP del frontend se distribuirán entre las máquinas del backend.
Y no puede ser al mismo tiempo interno y público.
Vamos a partir de un escenario en el que tenemos 2 máquinas virtuales en un mismo Availability Set (una máquina se puede añadir a un Availability Set durante su creación, pero no una vez creada). Esto es necesario porque el backend de un Load Balancer puede ser cualquier de estos objetos:
- Una máquina virtual individual
- Un Availability Set
- Un Scale Set
Y empezamos creando nuestro Load Balancer, que para este ejemplo será de tipo público:
Donde damos un nombre al Load Balancer (LB1), asignamos de forma dinámica una IP pública (IP-LB1) y seleccionamos el grupo de recursos y la región donde lo vamos a crear.
Vemos que en el apartado de SKU (Stock Keeping Unit) podemos seleccionar entre Básico y Estándar. Cualquier configuración que podamos hacer con un Load Balancer Básico también la podemos hacer con un Load Balancer Estándar, pero este último incluye algunas características que no estén en el básico:
- Hasta 1.000 instancias de máquinas virtuales en el backend frente a 100 que permite como máximo el básico.
- Sondas de salud TCP, HTTP y HTTPS, mientras que el básico sólo permite sondas de tipo TCP y HTTP, pero no HTTPS.
- Uso de zonas de disponibilidad, lo que no es posible en el básico.
Y otras diferencias que podemos ver en detalle en el siguiente enlace:
https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview
Además, debemos tener en cuenta que no habrá ningún coste adicional por el uso de un Load Balancer Básico, pero sí por uno de tipo Estándar:
https://azure.microsoft.com/es-es/pricing/details/load-balancer/
Ya que tenemos creado el Load Balancer, vamos a configurarlo para que las máquinas que tenemos en el Availability Set pasen formar parte del backend. Pulsamos en “Grupos de back-end”:
Y después en “Agregar”:
La configuración es muy sencilla. Primero seleccionamos nuestro Availability Set (AvSet1) y después elegimos las interfaces de las máquinas virtuales que van a ser destino de las peticiones balanceadas por LB1. En este caso seleccionamos las 2 máquinas virtuales:
En pocos segundos obtenemos el resultado:
Ahora vamos a configurar las sondas de estado:
Por ejemplo, podemos monitorizar el puerto 3389 de las máquinas para determinar su estado:
Una vez creada esta sonda ya la podemos usar en una regla de balanceo de carga:
Agregamos una regla:
Le damos un nombre, por ejemplo Regla1, y especificamos el puerto que queremos poner a la escucha en el frontend y a qué puerto de destino queremos enviar las peticiones en el backend. En esta imagen estamos usando el puerto 3389, que también es el puerto que usamos para la sonda, aunque no es necesario que esto sea así.
Podríamos aplicar persistencia a la sesión, de forma que un cliente siempre sería dirigido a la misma máquina del backend. Las opciones de persistencia son:
- Ninguno: Sucesivas peticiones de un mismo cliente podrían ser atendidas por máquinas diferentes del backend.
- IP del cliente: Todas las peticiones que procedan de una misma IP de origen serás atendidas por la misma máquina del backend.
- IP y protocolo del cliente: Todas las peticiones que procedan de una misma IP y puerto de origen serán atendidas por la misma máquina del backend, pero si vienen de la misma IP pero con un puerto de origen diferente podrían ser atendidas por otra máquina del backend.
Tenemos más información sobre la persistencia en:
https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-distribution-mode
También podemos seleccionar el tiempo en minutos de inactividad que harán que se cierre una sesión TCP o HTTP:
Y también podríamos utilizar la característica Direct Server Return, aunque es una configuración avanzad y sólo se recomienda en el caso de que estemos trabajando con un grupo de disponibilidad de SQL Server Always On :
Una vez creada la regla ya podemos tratar de acceder vía Escritorio Remoto a nuestras máquinas utilizando la IP pública del Load Balancer:
Como vemos, apuntando a la IP pública del balanceador nos ha dirigido a la máquina VM2, aunque también podría habernos dirigido a la VM1.
En otro post veremos una configuración avanzada de Azure Load Balancer.