Implementó tres máquinas virtuales detrás de una única IP pública y lo llamó “alta disponibilidad”. Luego, el disco de una VM se llenó, su aplicación comenzó a arrojar errores 502 y pasó las siguientes cuatro horas eliminando manualmente la instancia en mal estado del DNS mientras su jefe observaba el panel de tiempo de actividad como si le debiera dinero. ¿Te suena familiar?

Equilibrador de carga de Azure existe para que nunca más tengas esa noche. Se ubica frente a sus máquinas virtuales, distribuye el tráfico entrante entre instancias de backend en buen estado y automáticamente deja de enviar solicitudes a cualquier cosa que no pase una verificación de estado. Opera en la Capa 4 del modelo OSI (la capa de transporte), lo que significa que enruta según encabezados TCP y UDP en lugar de inspeccionar las cargas útiles de las aplicaciones. Rápido, de baja latencia y completamente inconsciente de lo que realmente está haciendo su aplicación, exactamente como debería funcionar un balanceador de carga de red.

En este tutorial, creará un equilibrador de carga estándar público mediante la CLI de Azure, configurará un grupo de backend con varias máquinas virtuales, configurará sondeos de estado y creará reglas de equilibrio de carga. Al final, tendrás una distribución del tráfico que realmente funciona sin que tengas que cuidar los registros DNS a medianoche.

Requisitos previos

Antes de comenzar, asegúrese de tener lo siguiente:

• Una suscripción activa de Azure. Si no tienes uno, crear una cuenta gratis.

• CLI de Azure versión 2.49.0 o posterior instalada en su máquina local.

• Permisos para crear recursos en su suscripción (rol de Colaborador o equivalente).

Verifique su versión de CLI y que haya iniciado sesión:

az version --query '"azure-cli"' -o tsv
az account show --query name -o tsv

Si alguno de los comandos falla, ejecute az login e inténtalo de nuevo.

Crear el grupo de recursos y la red virtual

Cada implementación de Azure comienza con un grupo de recursos y una red. Creará ambos, además de una subred específica para sus máquinas virtuales backend.

az group create \
  --name lb-demo-rg \
  --location eastus

Ahora cree la red virtual y la subred:

az network vnet create \
  --resource-group lb-demo-rg \
  --name lb-vnet \
  --address-prefix 10.0.0.0/16 \
  --subnet-name backend-subnet \
  --subnet-prefix 10.0.1.0/24

Confirme que la red existe:

az network vnet show \
  --resource-group lb-demo-rg \
  --name lb-vnet \
  --query '{name:name, addressSpace:addressSpace.addressPrefixes[0]}' \
  -o table

Deberías ver tu 10.0.0.0/16 espacio de dirección. Si no lo hace, algo salió mal con sus permisos de suscripción.

Crear el equilibrador de carga

Aquí es donde se pone interesante. Estás creando un SKU estándar equilibrador de carga, no básico. La SKU básica se retiró y ya no acepta nuevas implementaciones. Estándar es el único SKU que debe utilizar y le brinda soporte de zona de disponibilidad, un SLA del 99,99 % y un modelo de seguridad que es cerrado por defecto.

Cree el equilibrador de carga con una IP de interfaz pública:

az network public-ip create \
  --resource-group lb-demo-rg \
  --name lb-public-ip \
  --sku Standard \
  --allocation-method Static \
  --zone 1 2 3

az network lb create \
  --resource-group lb-demo-rg \
  --name my-load-balancer \
  --sku Standard \
  --public-ip-address lb-public-ip \
  --frontend-ip-name lb-frontend \
  --backend-pool-name lb-backend-pool

El --zone 1 2 3 La bandera en la IP pública lo hace zona redundantelo que significa que su IP frontend sobrevive a una zona de disponibilidad completa que cae. Una cosa menos de qué preocuparse a las 3 de la madrugada.

Verifique que se haya creado el equilibrador de carga:

az network lb show \
  --resource-group lb-demo-rg \
  --name my-load-balancer \
  --query '{name:name, sku:sku.name, frontendIP:frontendIPConfigurations[0].name}' \
  -o table

Configurar sondas de estado

Las sondas de estado son la forma en que el balanceador de carga decide qué instancias de backend merecen tráfico. Sin sondas, el balanceador de carga envía solicitudes a cada máquina virtual del grupo, incluida la que falló hace diez minutos.

Tiene tres tipos de sonda para elegir:

• tcp: completa un protocolo de enlace de tres vías. Si la conexión se realiza correctamente, la instancia está en buen estado. Simple, pero solo le indica que la pila de red se está ejecutando.

• HTTP: envía un GET solicitud a una ruta que usted especifique (como /health). La instancia está en buen estado sólo si regresa HTTP 200. En realidad, esto verifica que su aplicación esté respondiendo.

• HTTPS: Igual que HTTP pero sobre TLS. Utilícelo cuando su punto final de salud requiera cifrado.

Para la mayoría de las cargas de trabajo web, las sondas HTTP son la opción correcta. Crea uno:

az network lb probe create \
  --resource-group lb-demo-rg \
  --lb-name my-load-balancer \
  --name http-health-probe \
  --protocol Http \
  --port 80 \
  --path "/health" \
  --interval 5 \
  --probe-threshold 2

El --interval 5 significa que la sonda se dispara cada cinco segundos. El --probe-threshold 2 significa que dos fallas consecutivas marcan una instancia como en mal estado. Esa es una ventana de detección de diez segundos, lo suficientemente rápida para la mayoría de los escenarios de producción.

Advertencia: Sus grupos de seguridad de red (NSG) y cualquier firewall local en las máquinas virtuales backend deben permitir el tráfico entrante desde 168.63.129.16. Este es el IP de la plataforma Azure que origina todas las sondas sanitarias. Bloquéelo y cada instancia de backend se marcará como no saludable. Tendrá un equilibrador de carga sin objetivos saludables, que es una forma elegante de decir “interrupción total”.

Crear reglas de equilibrio de carga

A regla de equilibrio de carga une su IP de frontend, su grupo de backend y su sonda de estado. Le dice al balanceador de carga: “Cuando el tráfico llegue a este puerto, distribúyalo a instancias saludables en ese puerto”.

az network lb rule create \
  --resource-group lb-demo-rg \
  --lb-name my-load-balancer \
  --name http-lb-rule \
  --protocol Tcp \
  --frontend-port 80 \
  --backend-port 80 \
  --frontend-ip-name lb-frontend \
  --backend-pool-name lb-backend-pool \
  --probe-name http-health-probe \
  --idle-timeout 15 \
  --enable-tcp-reset true

El --enable-tcp-reset true flag envía un paquete TCP RST cuando una conexión alcanza el tiempo de espera de inactividad. Esto evita que sus clientes se queden colgados de conexiones inactivas: obtendrán un reinicio limpio y podrán volver a conectarse inmediatamente.

De forma predeterminada, Azure Load Balancer usa un hash de cinco tuplas para distribuir el tráfico: IP de origen, puerto de origen, IP de destino, puerto de destino y protocolo. Cada paquete en la misma sesión TCP aterriza en la misma VM backend. Pero si un cliente abre una nueva conexión (puerto de origen diferente), podría llegar a una máquina virtual diferente.

Si su aplicación necesita sesiones fijas (como un carrito de compras que almacena el estado de la sesión localmente), puede cambiar el modo de distribución a persistencia de la sesión:

az network lb rule update \
  --resource-group lb-demo-rg \
  --lb-name my-load-balancer \
  --name http-lb-rule \
  --load-distribution SourceIP

Eso cambia a un hash de dos tuplas (IP de origen + IP de destino), por lo que todas las conexiones de la misma IP del cliente siempre llegan al mismo backend. Advertencia justa: esto reduce la eficiencia de su distribución. Si la mayor parte de su tráfico proviene de algunas puertas de enlace NAT grandes, esas máquinas virtuales de backend se verán afectadas mientras otras permanecerán inactivas.

Implementar máquinas virtuales backend

Ahora necesita máquinas virtuales reales para recibir tráfico. Crearás un Grupo de seguridad de red primero para permitir el tráfico HTTP, luego active dos máquinas virtuales.

Cree el GSN:

az network nsg create \
  --resource-group lb-demo-rg \
  --name lb-nsg

az network nsg rule create \
  --resource-group lb-demo-rg \
  --nsg-name lb-nsg \
  --name allow-http \
  --protocol Tcp \
  --priority 100 \
  --destination-port-range 80 \
  --access Allow \
  --direction Inbound

az network nsg rule create \
  --resource-group lb-demo-rg \
  --nsg-name lb-nsg \
  --name allow-health-probe \
  --protocol Tcp \
  --priority 110 \
  --source-address-prefix 168.63.129.16 \
  --destination-port-range 80 \
  --access Allow \
  --direction Inbound

Observe que la segunda regla permite explícitamente la IP de la sonda de estado. Omita esto y volverá al escenario de “interrupción total” mencionado anteriormente.

Cree dos máquinas virtuales y asócielas al grupo de backend:

for i in 1 2; do
  az network nic create \
    --resource-group lb-demo-rg \
    --name vm${i}-nic \
    --vnet-name lb-vnet \
    --subnet backend-subnet \
    --network-security-group lb-nsg \
    --lb-name my-load-balancer \
    --lb-address-pools lb-backend-pool

  az vm create \
    --resource-group lb-demo-rg \
    --name backend-vm${i} \
    --nics vm${i}-nic \
    --image Ubuntu2204 \
    --admin-username azureuser \
    --generate-ssh-keys \
    --zone ${i} \
    --size Standard_B1s \
    --custom-data cloud-init.txt \
    --no-wait
done

Cada VM aterriza en una zona de disponibilidad diferente (--zone ${i}), por lo que una falla en una sola zona no eliminará todo su backend. El --no-wait flag permite que ambas máquinas virtuales se implementen en paralelo en lugar de obligarte a mirar la barra de progreso dos veces.

Consejo profesional: el --custom-data cloud-init.txt La referencia supone que tiene un archivo cloud-init que instala e inicia un servidor web. Para una prueba rápida, cree un archivo llamado cloud-init.txt con una instalación de nginx: #cloud-config\npackage_upgrade: true\npackages:\n - nginx

Verifique que ambas máquinas virtuales estén en el grupo de backend:

az network lb address-pool show \
  --resource-group lb-demo-rg \
  --lb-name my-load-balancer \
  --name lb-backend-pool \
  --query 'backendIPConfigurations[].id' \
  -o tsv

Deberías ver dos referencias de NIC. Si ve cero, verifique que las NIC se crearon con el --lb-address-pools bandera.

Pruebe su equilibrador de carga

Toma la IP pública de tu balanceador de carga:

az network public-ip show \
  --resource-group lb-demo-rg \
  --name lb-public-ip \
  --query ipAddress \
  -o tsv

Golpéalo con curl unas cuantas veces:

LB_IP=$(az network public-ip show \
  --resource-group lb-demo-rg \
  --name lb-public-ip \
  --query ipAddress -o tsv)

for i in $(seq 1 10); do
  curl -s http://$LB_IP | grep -o '<title>.*</title>'
done

Debería ver respuestas provenientes de ambas máquinas virtuales backend. Si cada respuesta proviene de la misma máquina virtual, recuerde ese hash de cinco tuplas: probablemente esté usando el mismo puerto de origen cada vez. Pruebe desde diferentes terminales o máquinas.

Limpiar recursos

Cuando haya terminado de realizar las pruebas, desmonte todo para no pagar por máquinas virtuales inactivas:

az group delete \
  --name lb-demo-rg \
  --yes \
  --no-wait

Victoria rápida: la --no-wait El indicador en el comando de eliminación regresa inmediatamente y permite que la limpieza se realice en segundo plano. Su terminal es gratuita y Azure se encarga del resto. No olvide verificar que el grupo de recursos realmente haya desaparecido más tarde.az group show --name lb-demo-rg debería devolver un error “no encontrado”.

Lo que construiste

Ahora tiene una implementación de Azure Load Balancer en funcionamiento que controla la distribución del tráfico sin intervención manual. Los sondeos de estado eliminan automáticamente de la rotación las máquinas virtuales en mal estado. La IP frontal con redundancia de zona sobrevive a las fallas de la zona de disponibilidad. El hash de cinco tuplas distribuye las conexiones a través de su grupo de backend. Y las reglas de NSG garantizan que los sondeos de estado realmente puedan llegar a sus máquinas virtuales, que es la parte que la mayoría de la gente olvida en su primera implementación.

La próxima vez que una máquina virtual backend llene su disco o falle, el balanceador de carga dejará de enviarle tráfico silenciosamente mientras usted duerme toda la noche. Ese es el punto.