AZURE NETWORKING / LAB-003

Recuperación de un Load Balancer interno

Diagnóstico de un timeout: de tres backends no saludables a respuestas verificadas de tres servidores IIS a través de una IP privada.

AZ-700 · M419 de septiembre de 2026Evidencia histórica recuperada

Resultado documentado: Las capturas muestran el cambio de 0% a 100% de instancias saludables y una prueba desde myTestVM que devuelve myVM1, myVM2 y myVM3.

01 / Arquitectura y objetivo

El laboratorio M4 utilizó un Azure Load Balancer Standard interno, tres VM backend y una VM cliente. Juan llegó al chat con el despliegue adaptado parcialmente con ayuda de Claude, pero la prueba a la IP privada terminaba en timeout.

myTestVM → 10.1.2.4:80 → myIntLoadBalancer (interno)
                       → regla TCP/80 → backend pool
                           ├─ myVM1 · 10.1.0.5 · IIS
                           ├─ myVM2 · 10.1.0.6 · IIS
                           └─ myVM3 · 10.1.0.4 · IIS
Administración histórica: Azure Bastion / Run Command

La VIP privada 10.1.2.4 era el punto de entrada del servicio, no la dirección de una VM. La asignación VM/IP procede de la captura de salud. El cliente de la prueba estaba dentro del entorno de red.

02 / Adaptaciones y decisiones

Separar fallo de aplicación y fallo de balanceador

El panel mostraba tres destinos Down y timeout del probe. La extensión VMConfig de myVM1 mostraba Provisioning failed: no pudo descargar install-iis.ps1 desde raw.githubusercontent.com. Esa captura identifica un fallo de la dependencia de instalación; no determina qué ruta, firewall o mecanismo de salida lo causó.

Reparar IIS antes de recrear infraestructura

Se utilizó Run Command para instalar Web-Server y escribir el nombre de cada VM en su página inicial. Se comprobó primero una reparación y luego las restantes. La evidencia conserva la ejecución satisfactoria y la recuperación a tres destinos Up.

Adaptar la práctica a las restricciones de la cuenta

Los archivos locales M4 conservados usan Standard_B1s y contienen parámetros separados para myVM1, myVM2 y myVM3. Juan reportó modificaciones por límites de la cuenta y asistencia de Claude. Los archivos demuestran la configuración preparada, pero no prueban por sí solos los tamaños finales desplegados ni una cuota universal de cuatro vCPU.

Comprobar más de una respuesta

El navegador mostraba repetidamente myVM2. Se ejecutaron quince invocaciones independientes de curl.exe desde myTestVM y la salida mostró los tres nombres. El balanceo por flujo no exige que cada recarga de navegador elija una VM distinta.

Comando histórico de validación desde myTestVM

1..15 | ForEach-Object {
    curl.exe -s --no-keepalive http://10.1.2.4
}

Transcrito de E05; no se ejecutó durante esta recuperación. Cada iteración lanza un proceso curl independiente. La captura acredita los nombres recibidos, no una medición de distribución estadística.

03 / Validación y resultados

Qué demuestra cada comprobación
Comprobación	Resultado registrado	Límite
Estado inicial	0% healthy; tres Down	E01 muestra el síntoma, no su causa por sí sola.
Extensión de instalación	VMConfig: descarga fallida	E02 corresponde a myVM1; no se generaliza el mismo mensaje a las otras VM sin evidencia.
Reparación	Web-Server: Success True	E03 conserva script y salida de la reparación de myVM1.
Estado posterior	100% healthy; tres Up	E04 prueba la salud observada en ese momento.
Prueba del cliente	Respuestas myVM1 / myVM2 / myVM3	E05 demuestra respuestas desde los tres backends; no failover, carga o reparto garantizado.

04 / Evidencias originales

Capturas enviadas durante el laboratorio y recuperadas del historial local. Las copias se recortaron con autorización para excluir datos personales e interfaz ajena al resultado. No se reconstruyeron ni generaron con IA. Se conservan los originales y el registro de procedencia. Las capturas mantienen su idioma original.

E01 · Tres backends Down y 0% healthy antes de la reparación. Encabezado de cuenta excluido.

E02 · VMConfig: fallo al descargar install-iis.ps1 desde GitHub. Se excluyó el identificador de suscripción.

E03 · Instalación de IIS y página con nombre de VM; salida Success True de myVM1.

E04 · Tres backends Up y 100% healthy tras las reparaciones.

E05 · Prueba hacia la VIP privada: quince ejecuciones y respuestas de myVM1, myVM2 y myVM3.

05 / Alcance y lecciones

No se hizo una nueva consulta a Azure ni se probaron estos endpoints históricos.
No se determinó la causa de red exacta del fallo de descarga. No se atribuye automáticamente a la cuenta Free, a un NSG o a la ausencia de NAT.
No se afirma failover probado, resistencia a carga, reparto uniforme ni tolerancia a una caída de zona.
Los archivos de parámetros son evidencia de preparación; no sustituyen una exportación del estado desplegado.
Traffic Manager se evaluó después y quedó bloqueado por cuotas de App Service. Ese intento no forma parte del resultado completado de este caso.

Lección práctica: Una VM desplegada no garantiza una aplicación disponible. Correlacionar extensión, servicio, probes y respuesta del cliente evita cambiar el balanceador a ciegas.

Procedencia y referencias

Recuperado de «Continuar preparación AZ-700», con capturas del 19 de septiembre de 2026 y archivos M4. El usuario informó de trabajo previo asistido por Claude; el diagnóstico y la validación continuaron en ChatGPT. Recuperación documental: 16 de octubre de 2026.

Microsoft Learn · Azure Load Balancer algorithm