Solución de problemas de respuestas de tráfico de back-end de Azure Load Balancer
En esta página se proporciona información de solución de problemas para preguntas de Azure Load Balancer.
Las máquinas virtuales detrás de un equilibrador de carga reciben una distribución desigual del tráfico
Si sospecha que los miembros del grupo de back-end reciben tráfico, podría deberse a las siguientes causas. Azure Load Balancer distribuye el tráfico en función de las conexiones. Asegúrese de comprobar la distribución del tráfico por conexión y no por paquete. Compruebe el uso de la pestaña Distribución del flujo en el panel preconfigurado de información de Load Balancer.
Azure Load Balancer no admite un verdadero equilibrio de carga round robin, pero admite un modo de distribución basado en hash.
Causa 1: Tiene configurada la persistencia de la sesión
Usar el modo de distribución de persistencia de origen puede provocar una distribución desigual del tráfico. Si no desea esta distribución, actualice la persistencia de la sesión para que sea Ninguna y que así el tráfico se distribuya entre todas las instancias en buen estado del grupo de back-end. Obtenga más información sobre los modos de distribución de Azure Load Balancer.
Causa 2: Tiene un proxy configurado
Los clientes que se ejecutan detrás de servidores proxy pueden verse como una única aplicación cliente desde el punto de vista del equilibrador de carga.
Las máquinas virtuales detrás de un equilibrador de carga no responden al tráfico en el puerto de datos configurado
Si una máquina virtual del grupo de back-end aparece como correcta y responde a los sondeos de estado, pero aun así no participa en el equilibrio de carga o no responde al tráfico de datos, puede deberse a alguno de los motivos siguientes:
Una máquina virtual del grupo de back-end del equilibrador de carga no escucha en el puerto de datos.
Un grupo de seguridad de red está bloqueando el puerto en la máquina virtual del grupo de back-end del equilibrador de carga.
El acceso al equilibrador de carga tiene lugar desde la misma máquina virtual y NIC.
El acceso al front-end del equilibrador de carga en Internet tiene lugar desde la máquina virtual del grupo de back-end del equilibrador de carga participante.
Motivo 1: Una máquina virtual del grupo de back-end del equilibrador de carga no escucha en el puerto de datos
Si una máquina virtual no responde al tráfico de datos, puede deberse a que el puerto de destino no esté abierto en la máquina virtual participante, o a que la máquina virtual no escuche en ese puerto.
Validación y resolución
Inicie sesión en la máquina virtual de back-end.
Abra un símbolo del sistema y ejecute el siguiente comando para validar que existe una aplicación de escucha en el puerto de datos:
netstat -anSi el puerto no aparece con el estado ESCUCHANDO, configure el puerto de escucha adecuado.
Si el puerto está marcado como ESCUCHANDO, compruebe si hay problemas en la aplicación de destino en ese puerto.
Motivo 2: Un grupo de seguridad de red está bloqueando el puerto de la máquina virtual del grupo de back-end del equilibrador de carga
Si uno o varios grupos de seguridad de red configurados en la subred o en la máquina virtual bloquean la dirección IP de origen o el puerto, la máquina virtual no puede responder.
En el caso del equilibrador de carga público, la dirección IP de los clientes de Internet se usará para la comunicación entre los clientes y las VM de back-end del equilibrador de carga. Asegúrese de que la dirección IP de los clientes esté permitida en el grupo de seguridad de red de la VM de back-end.
Enumere los grupos de seguridad de red configurados en la máquina virtual de back-end. Para más información, consulte Administración de los grupos de seguridad de red.
En la lista de grupos de seguridad de red, compruebe si:
El tráfico entrante o saliente del puerto de datos tiene interferencias.
Hay una regla de grupos de seguridad de red Denegar todo en la NIC de la máquina virtual o en la subred que tiene una prioridad mayor que la regla predeterminada que permite los sondeos del equilibrador de carga y el tráfico (los grupos de seguridad de red deben permitir la dirección IP del equilibrador de carga 168.63.129.16, que es el puerto de sondeo)
Si cualquiera de estas reglas bloquea el tráfico, elimine y vuelva a configurar las reglas para permitir el tráfico de datos.
Pruebe si la máquina virtual ahora responde a los sondeos de estado.
Motivo 3: Acceso al equilibrador de carga interno desde la misma máquina virtual e interfaz de red
No se admite el escenario de que la aplicación hospedada en la máquina virtual de back-end de un equilibrador de carga interno intente acceder a otra aplicación hospedada en la misma máquina virtual de back-end a través de la misma interfaz de red y se producirá un error.
Resolución
Este problema se puede resolver por uno de los siguientes métodos:
Configure las máquinas virtuales del grupo de back-end por separado para cada aplicación.
Configure la aplicación en máquinas virtuales de NIC dual para que cada aplicación use su propia interfaz de red y dirección IP.
Motivo 4: Acceso al front-end del equilibrador de carga interno desde la máquina virtual del grupo de back-end del equilibrador de carga participante
Si se configura un equilibrador de carga interno dentro de una red virtual y una de las máquinas virtuales de back-end participantes intenta acceder al front-end de este, pueden producirse errores al asignar el flujo a la máquina virtual original. Este escenario no se admite.
Solución
Hay varias maneras de desbloquear este escenario, incluido el uso de un proxy. Evalúe Application Gateway u otros proxys de terceros (por ejemplo, nginx o haproxy). Para más información acerca de Application Gateway, consulte Introducción a Application Gateway
Detalles
Las instancias internas de Load Balancer no traducen las conexiones originadas salientes en el front-end de un equilibrador de carga interno, porque ambos están en un espacio de direcciones IP privado. Los equilibradores de carga públicos proporcionan conexiones salientes desde direcciones IP privadas dentro de la red virtual a las direcciones IP públicas. En el caso de los equilibradores de carga internos, este enfoque evita el posible agotamiento de puertos SNAT en un espacio de direcciones IP interno único, donde no se requiere traducción.
Un efecto secundario es que si un flujo de salida de una máquina virtual del grupo de servidores back-end intenta un flujo hacia el front-end del equilibrador de carga interno en su grupo y se asigna a sí mismo, las dos piernas del flujo no coinciden. Dado que no coinciden, se produce un error en el flujo. El flujo se realiza correctamente si no se ha asignado a la misma máquina virtual del grupo de back-end que creó el flujo al front-end.
Cuando el flujo se mapea hacia sí mismo, el flujo de salida parece originarse desde la máquina virtual hasta el front-end y el flujo de entrada correspondiente parece provenir de la máquina virtual. Desde el punto de vista del sistema operativo invitado, las partes entrantes y salientes del mismo flujo no coinciden dentro de la máquina virtual. La pila TCP no reconocerá estas mitades del mismo flujo como parte del mismo flujo. El origen y el destino no coinciden. Cuando el flujo se asigna a cualquier otra máquina virtual del grupo de back-end, las mitades del flujo coinciden y la máquina virtual puede responder al flujo.
El síntoma de este escenario es el tiempo de espera de conexión intermitente cuando el flujo vuelve al mismo back-end que originó el flujo. Las soluciones alternativas comunes incluyen la inserción de una capa de proxy detrás del equilibrador de carga interno y el uso de reglas de estilo de Direct Server Return (DSR). Para obtener más información, consulte Varios front-ends para Azure Load Balancer.
Puede combinar un equilibrador de carga interno con cualquier proxy de terceros o usar la instancia de Application Gateway interna para escenarios de proxy con HTTP o HTTPS. Aunque podría usar un equilibrador de carga público para mitigar este problema, el escenario resultante es propenso al agotamiento de SNAT. Evite este segundo enfoque a menos que se administre con cuidado.
Pasos siguientes
Si los pasos anteriores no resuelven el problema, abra una incidencia de soporte técnico.