Preparación para la Certificación Microsoft AZ-104
Azure Load Balancer: distribución en la capa 4, sondeos de estado, NAT y selección de la solución
Comprende balanceadores públicos e internos, distribución por cinco tuplas, persistencia de sesión, sondeos de estado, puertos HA, NAT de entrada, reglas explícitas de salida y cuándo conviene otro servicio de tráfico de Azure.
Tiempo de estudio sugerido: 60 minutos • Nivel intermedio • Reescritura original basada en el módulo proporcionado de Microsoft Learn y corregida con la documentación vigente de Azure Load Balancer
Por João Ricardo Dutra••Contenido original completo
1. Sustituye dispositivos físicos de capa 4 por un servicio nativo de
Adatum está migrando aplicaciones comerciales de tres niveles desde centros de datos locales hacia máquinas virtuales de repartidas entre redes virtuales. Algunas aplicaciones deben atender Internet y otras solo a la oficina de Sídney. Los antiguos dispositivos físicos equilibraban los niveles web y de procesamiento, dejaban de enviar trabajo nuevo a servidores con errores, conservaban cada sesión en un servidor y reenviaban conexiones administrativas a máquinas concretas.
reproduce esas funciones de transporte para máquinas virtuales y . Este capítulo explica arquitectura, algoritmo, sondeos, , salida y el límite entre y los demás servicios de tráfico de .
Explicar qué hace y cómo aporta disponibilidad.
Seguir una conexión por el front-end, la regla, el sondeo y el grupo de back-end.
Elegir una implementación pública o interna y el modo de distribución.
Diferenciar reglas de equilibrio, de entrada, puertos HA y salida.
Decidir si u otro servicio de satisface la carga de trabajo.
El requisito previo es comprender fundamentos de ,,, puertos, redes virtuales y máquinas virtuales.
El diseño combina una decisión de tráfico, otra de estado y un plan explícito de conectividad.
2. El equilibrio escala horizontalmente en lugar de ampliar sin un servidor
Incluso un servidor potente puede convertirse en cuello de botella. El equilibrio distribuye las solicitudes entre varios equipos para que ninguna instancia absorba toda la demanda. Un grupo de máquinas más pequeñas puede ofrecer mayor rendimiento, resiliencia y flexibilidad de mantenimiento que una sola máquina sobredimensionada.
reparte flujos de red entre máquinas virtuales o instancias de . Las reglas definen destinos aptos y los sondeos impiden que lleguen flujos nuevos a puntos incorrectos. La redundancia mejora capacidad y disponibilidad.
3. distribuye flujos regionales en la capa 4
funciona en la capa de transporte del modelo OSI. Decide con direcciones, puertos y protocolo o , no con , encabezados, ni contenido de aplicación. Procesa cada flujo sin actuar como inverso ni almacenar datos de la aplicación.
Qué puede evaluar la capa 4.
Puede evaluar
No puede evaluar
Direcciones de origen y destino
Ruta de como /imagenes o /
Puertos de origen y destino
Host o encabezado
Protocolo o
, identidad o carga útil
Estado del flujo y de persistencia
Reglas de firewall de aplicaciones web
Úsalo cuando la latencia mínima, el alto rendimiento y el transporte transparente de o importen más que la inspección de capa 7.
4. Los balanceadores públicos e internos exponen front-ends distintos
La de front-end define el acceso.
Tipo
Front-end
Uso típico
Balanceador de carga público
Dirección pública
Recibir Internet en un nivel web y, con salida explícita, traducir direcciones privadas del back-end.
Balanceador de carga interno
Dirección privada
Distribuir tráfico privado en la red virtual o desde el entorno local mediante o .
El front-end interno nunca se expone directamente a Internet. Sirve para tráfico dentro de una red virtual, acceso híbrido, distribución del nivel web público al procesamiento privado y aplicaciones LOB. Ambos tipos manejan gran cantidad de flujos y .
Usa front-end público para Internet y privado para tráfico o híbrido.
5. Siete componentes cooperan en la ruta de datos
Componentes principales de .
Componente
Responsabilidad
Configuración de de front-end
Dirección pública o privada que contactan los clientes.
Regla de equilibrio
Asigna , puerto y protocolo de front-end a grupo y puerto de back-end.
Grupo de back-end
Máquinas o instancias aptas para recibir flujos.
Sondeo de estado
Decide qué puntos reciben flujos nuevos.
Persistencia de sesión
Selecciona distribución de cinco, dos o tres tuplas.
Puertos HA o regla de entrada
Equilibra todos los puertos de una NVA interna o reenvía un puerto a una instancia.
Regla de salida
Define explícita para el grupo de un Standard público.
Una dirección front-end por sí sola no basta. La regla referencia grupo y sondeo, los controles de seguridad permiten clientes y sondeos, y la salida se diseña por separado.
6. El front-end es el punto de contacto del cliente
El cliente se conecta a una configuración de de front-end. La pública asigna una y un puerto de Internet a direcciones privadas del back-end y devuelve la respuesta por la tupla pública. La interna usa una dirección privada accesible solo desde la red conectada.
Un admite varias de front-end, cada una con sus reglas, de modo que un servicio compartido puede publicar varias direcciones o aplicaciones sin dejar la capa 4.
7. El grupo de back-end es el conjunto escalable de instancias aptas
El grupo contiene máquinas virtuales o instancias de . La asociación puede usar interfaces de red o direcciones ; una máquina detrás de un público no necesita pública individual. El servicio actual permite varios grupos, aunque cada regla elige uno.
Al agregar o quitar instancias, se reconfigura automáticamente. Los recursos de una regla permanecen en una sola red virtual; la regla no cruza dos redes virtuales.
8. La regla une front-end, back-end, protocolo y sondeo
Una regla de entrada asigna una combinación de y puerto de front-end a un grupo y puerto de back-end para o . Por ejemplo, 80 público puede llegar al 80 de cada servidor web correcto; otra dirección o puerto puede usar otra regla y grupo.
Las reglas de equilibrio distribuyen entrada y no son reglas de salida. Se pueden publicar varios puertos, varias direcciones de front-end o ambos.
La regla conecta la tupla de front-end con un grupo correcto.
9. El algoritmo predeterminado calcula un de cinco tuplas
usa y puerto de origen, y puerto de destino y protocolo. El elige un back-end correcto. Los paquetes de una sesión conservan la tupla; una conexión posterior puede cambiar el puerto de origen y llegar a otra máquina.
de origen: dirección del cliente.
Puerto de origen: puerto usado por el flujo del cliente.
de destino: dirección de front-end contactada.
Puerto de destino: puerto del servicio.
Protocolo: o .
No es necesariamente round-robin. Si muchos clientes aparecen detrás de la misma y ofrecen poca variedad de tuplas, la distribución puede quedar sesgada.
La persistencia predeterminada dura el flujo, no todas las solicitudes futuras.
10. La persistencia de sesión cambia uniformidad por afinidad
Modos de distribución.
Opción del portal
Entradas del
Efecto
Ninguno (predeterminado)
Cinco tuplas
Una conexión nueva puede ir a cualquier back-end correcto.
de cliente
de origen + de destino
Los flujos del mismo permanecen en la misma instancia.
de cliente y protocolo
de origen + de destino + protocolo
La afinidad se separa para y .
También se llama afinidad de sesión, de de origen o de de cliente. Ayuda si el estado no se comparte entre servidores, pero concentra tráfico cuando muchos usuarios comparten o . Prefiere aplicaciones sin estado cuando sea posible.
Aplica solo la afinidad que realmente necesita la aplicación.
11. Los sondeos de estado retiran instancias de los flujos nuevos
El sondeo prueba periódicamente un puerto del back-end. Su resultado define qué instancias reciben flujos de entrada nuevos. Cuando se supera el umbral incorrecto, deja de asignar conexiones nuevas; la conectividad saliente no cambia.
Sondeos de Standard .
Tipo
Resultado correcto
Ejemplos de error
El agente de escucha completa el protocolo de enlace .
Tiempo de espera, puerto sin escuchar o reset.
La ruta responde 200 dentro del plazo.
Estado distinto de 200, espera o reset.
Como , con y cadena firmada como mínimo con .
Error ,, de espera o conexión.
Configura protocolo, puerto, intervalo, ruta (S) y umbral de éxitos/errores consecutivos. Los valores actuales del portal y de las pueden diferir; comprueba lo implementado. Permite 168.63.129.16 o la etiqueta AzureLoadBalancer en grupos de seguridad de red y firewalls invitados.
El sondeo valida la aplicación, no solo la existencia de la máquina virtual.
12. Las conexiones existentes y todos los sondeos caídos tienen matices
Si falla un back-end Standard, las conexiones establecidas continúan hasta que termine la aplicación, venza la inactividad o se detenga la máquina; las nuevas usan instancias correctas. Los flujos existentes pueden moverse a otro punto correcto.
Si fallan todos los sondeos Standard, no llegan flujos nuevos, aunque establecido puede continuar si el grupo tiene más de una instancia. Esta diferencia importa en mantenimiento y diagnóstico.
13. Los puertos HA equilibran todos los puertos para NVA internas
Una regla de puertos HA usa protocolo Todos y puerto 0 para cubrir todos los puertos y de un Standard interno. La decisión de cinco tuplas sirve a firewalls, , SD-WAN y otras NVA de alta disponibilidad con muchos puertos.
No sustituye reglas web específicas ni funciona en público; evita crear miles de reglas para la capa de dispositivos internos.
14. de entrada reenvía un puerto a una instancia concreta
Una regla de entrada reenvía una y un puerto de front-end a una máquina y puerto de back-end determinados. Por ejemplo, 50001 público puede asignarse a 3389 en una máquina Windows y otra puerta a otra máquina. Así se administra cada instancia sin pública propia.
no equilibra: selecciona deliberadamente una instancia. Restringe el origen, prefiere o administración privada y no confundas con autorización.
15. Las reglas de salida definen explícita para el back-end
La regla de salida de un Standard público traduce direcciones privadas del grupo a una o varias públicas de front-end. Controla grupo, front-end, y/o , puertos , inactividad y reset opcional.
La salida es independiente de la entrada. El acceso saliente predeterminado se retiró para máquinas nuevas y Basic se retiró el 30 de septiembre de 2025. Usa reglas de salida Standard, o una pública por instancia. suele ser preferible para salida predecible y escalable de subred y menor riesgo de agotamiento .
Puertos HA, de entrada y salida resuelven direcciones y selecciones distintas.
16. El diseño de Adatum usa dos balanceadores para dos niveles
Coloca un Standard público delante de las máquinas web. Su sondeo elimina nodos con errores y la afinidad solo se activa si la aplicación la necesita. Entre web y análisis o transformación, usa un Standard interno para conservar privadas las máquinas secundarias.
de entrada permite administración específica, pero o acceso privado son más seguros que RDP abierto. Salida explícita, grupos de seguridad de red, zonas de disponibilidad, supervisión y dos instancias correctas completan la producción.
Elige por capa, alcance, protocolo, aceleración y seguridad.
17. Usa para flujos o de alto rendimiento
Sustituir un dispositivo físico de capa 4 por distribución administrada.
Exponer un nivel redundante de máquinas o conjunto de escalado.
Equilibrar tráfico privado entre niveles o desde una red híbrida.
Detener flujos nuevos a aplicaciones con errores mediante sondeos.
Mantener afinidad cuando el cliente debe permanecer en un back-end.
Usar puertos HA para NVA internas con muchos puertos o .
Reenviar un puerto a una instancia mediante de entrada controlada.
Definir salida explícita cuando el Standard público sea el método elegido.
18. No añadas si no existe necesidad de distribución
Una aplicación con poco tráfico que funciona bien en una máquina gana poco con un grupo, salvo que disponibilidad o crecimiento exijan redundancia. Tampoco es la herramienta correcta para contenido , terminación ,, rutas , aceleración global o selección .
El servicio no es firewall, puerta de enlace de aplicación, director ni regla universal entre redes. Empieza por el requisito arquitectónico.
19. Selecciona el servicio de tráfico por capa y alcance
Comparación de los servicios del módulo.
Servicio
Alcance y capa
Cuándo elegirlo
Regional, capa 4; y
Distribución de latencia mínima para máquinas, niveles privados o NVA.
regional de capa 7
(S), terminación , decisión por host/ruta o .
Red global de entrega de aplicaciones, capa 7
Aceleración web global, borde, caché, conmutación rápida y .
Traffic Manager
Dirección global basada en
Elegir puntos regionales aceptando caché del resolvedor y .
Se pueden combinar: selecciona una región correcta y o distribuye dentro de ella.
20. Respuestas de la evaluación y prioridades de diagnóstico
Respuestas correctas.
Pregunta
Respuesta
Motivo
¿En qué capa OSI funciona ?
Capa 4
Evalúa direcciones, puertos y o .
¿Qué mantiene al cliente en el mismo back-end?
Persistencia de sesión
La afinidad de dos o tres tuplas selecciona la instancia.
¿Qué detiene nuevos flujos 443 a un back-end sin respuesta?
Sondeo de estado
Marca el punto como incorrecto y lo retira de flujos nuevos.
Orden de diagnóstico
Confirma de front-end, protocolo/puertos, grupo y sondeo de la regla.
Comprueba que un back-end escucha el puerto y devuelve 200 si corresponde.
Permite AzureLoadBalancer y 168.63.129.16 en y firewalls locales.
Comprueba permiso del cliente y agente de escucha en el puerto de back-end.
Revisa estado, métricas, registros, inactividad, reset y distribución.
Para salida, verifica un método explícito y puertos , no la regla de entrada.
Para carga desigual, revisa persistencia y variedad de tuplas de origen.
21. Repaso compacto, recuperación activa y recursos oficiales
Versión resumida de todos los temas.
Tema
Recuerde
Finalidad
Distribuir o entre máquinas o instancias correctas.
