Solución de problemas del equilibrador de carga de red

La siguiente información puede ayudarlo a solucionar problemas del equilibrador de carga de red.

Un destino registrado no está operativo

Si un destino está tardando más de lo previsto en pasar al estado InService, es posible que no esté superando las comprobaciones de estado. El destino no estará operativo hasta que supere la comprobación de estado. Para obtener más información, consulte Comprobaciones de estado de los grupos de destino.

Examine la instancia para ver si hay algún error en las comprobaciones de estado y revise lo siguiente:

Hay un grupo de seguridad que no permite el tráfico

Los grupos de seguridad asociados a una instancia deben permitir el tráfico del balanceador de carga a través del puerto y el protocolo de comprobación de estado. Para obtener más información, consulte Grupos de seguridad de destino.

Hay una lista de control de acceso (ACL) de red que no permite el tráfico

La ACL de red asociada a las subredes de sus instancias y a las subredes del equilibrador de carga debe permitir que el equilibrador de carga realice comprobaciones de estado y tráfico. Para obtener más información, consulte ACL de red.

Las solicitudes no se direccionan a los destinos.

Compruebe lo siguiente:

Hay un grupo de seguridad que no permite el tráfico

Los grupos de seguridad asociados a las instancias deben permitir el tráfico procedente de las direcciones IP (si los destinos se especifican mediante el ID de instancia) o de los nodos del balanceador de carga (si los destinos se especifican mediante una dirección IP) en el puerto de escucha. Para obtener más información, consulte Grupos de seguridad de destino.

Hay una lista de control de acceso (ACL) de red que no permite el tráfico

Las ACL de red asociadas con las subredes de la VPC deben permitir que el balanceador de carga y los destinos se comuniquen en ambas direcciones en el puerto de escucha. Para obtener más información, consulte ACL de red.

Los destinos se encuentran en una zona de disponibilidad que no está habilitada

Si registra los destinos en una zona de disponibilidad pero no la habilita, estos destinos registrados no recibirán tráfico del balanceador de carga.

La instancia está en una VPC interconectada

Si tiene instancias en una VPC interconectada con la VPC del balanceador de carga, debe registrarlas en el balanceador de carga por dirección IP, no por ID de instancia.

Los destinos reciben más solicitudes de comprobación de estado de las que se esperaban

Las comprobaciones de estado de un equilibrador de carga de red se distribuyen y utilizan un mecanismo de consenso para determinar el estado del destino. Por tanto, los destinos reciben un número mayor de comprobaciones de estado que el que se estableció en el ajuste HealthCheckIntervalSeconds.

Los destinos reciben menos solicitudes de comprobación de estado de las que se esperaban

Compruebe si net.ipv4.tcp_tw_recycle está habilitado. Se sabe que este ajuste causa problemas con los balanceadores de carga. El ajuste net.ipv4.tcp_tw_reuse se considera una alternativa más segura.

Destinos en mal estado reciben solicitudes del balanceador de carga

Esto ocurre cuando todos los destinos registrados están en mal estado. Si hay al menos un destino registrado en buen estado, el equilibrador de carga de red solamente enrutará las solicitudes a los destinos registrados en buen estado.

Cuando todos los destinos registrados están en mal estado, el equilibrador de carga de red enruta las solicitudes a todos los destinos registrados, lo que se conoce como modo de apertura por error. El equilibrador de carga de red hace esto en lugar de eliminar todas las direcciones IP del DNS cuando todos los destinos están en mal estado y las zonas de disponibilidad respectivas no tienen un destino en buen estado al que enviar la solicitud.

El destino falla en las comprobaciones de estado HTTP o HTTPS debido a la falta de coincidencia del encabezado de host

El encabezado de host HTTP en la solicitud de comprobación de estado contiene la dirección IP del nodo del balanceador de carga y el puerto del agente de escucha, no la dirección IP del destino y el puerto de comprobación de estado. Si está asignando solicitudes entrantes por encabezado de host, debe asegurarse de que las comprobaciones de estado coincidan con cualquier encabezado de host HTTP. Otra opción es agregar un servicio HTTP independiente en un puerto diferente y configurar el grupo de destino para que utilice ese puerto para comprobaciones de estado en su lugar. Alternativamente, plantéese el uso de comprobaciones de estado TCP.

No se puede asociar un grupo de seguridad a un equilibrador de carga

Si el equilibrador de carga de red se creó sin grupos de seguridad, no podrá admitir grupos de seguridad después de su creación. Solo puede asociar un grupo de seguridad a un equilibrador de carga durante la creación, o a equilibrador de carga existente que se creó originalmente con grupos de seguridad.

No se pueden eliminar todos los grupos de seguridad

Si el equilibrador de carga de red se creó con grupos de seguridad, debe haber al menos un grupo de seguridad asociado a él en todo momento. No pueden eliminar todos los grupos de seguridad del equilibrador de carga al mismo tiempo.

Aumento de la métrica TCP_ELB_Reset_Count

Para cada solicitud de TCP que un cliente realiza a través de un equilibrador de carga de red, se controla el estado de la conexión. Si transcurre el tiempo de inactividad sin que el cliente ni el destino envíen datos a través de la conexión, esta se cierra. Si un cliente o un destino envía datos una vez transcurrido el tiempo de inactividad, recibirá un paquete TCP RST que indicará que la conexión ya no es válida. Además, si un destino no está en buen estado, el equilibrador de carga envía un RST TCP para los paquetes recibidos en las conexiones de cliente asociadas al destino, a menos que el destino en mal estado active el modo de apertura por error en el equilibrador de carga.

Si observa un aumento en la métrica TCP_ELB_Reset_Count justo antes o justo a medida que la métrica UnhealthyHostCount aumenta, es probable que los paquetes RST de TCP se hayan enviado porque el destino estaba empezando a fallar, pero no se había marcado como en mal estado. Si observa aumentos persistentes en TCP_ELB_Reset_Count sin que los destinos estén marcados como en mal estado, puede comprobar los registros de flujo de la VPC para ver si hay clientes que envíen datos sobre flujos caducados.

Se agota el tiempo de espera de conexión para las solicitudes enviadas desde un destino a su balanceador de carga

Compruebe si la preservación de la IP del cliente está habilitada en su grupo de destino. El bucle invertido de NAT, también conocido como horquilla, no se admite cuando la preservación de la IP del cliente está habilitada. Si una instancia es un cliente de un equilibrador de carga que está registrado y tiene activada la preservación de IP de cliente, la conexión solo se realizará correctamente si la solicitud se enruta a otra instancia. Si la solicitud se enruta a la misma instancia desde la que se envió, se agota el tiempo de espera de la conexión porque las direcciones IP de origen y destino son las mismas.

Si una instancia debe enviar solicitudes a un balanceador de carga con el que está registrada, realice una de las siguientes operaciones:

• Preservación de la IP del cliente

• Asegúrese de que los contenedores que deben comunicarse se encuentran en diferentes instancias de contenedor.

El rendimiento se reduce cuando se trasladan destinos a un equilibrador de carga de red.

Tanto los equilibradores de carga clásicos como los equilibradores de carga de conexión utilizan la multiplexación de conexiones, pero los equilibradores de carga de red no. Por tanto, los destinos puede recibir más conexiones TCP detrás de un equilibrador de carga de red. Asegúrese de que los destinos estén listos para administrar el volumen de solicitudes de conexión que reciben.

Errores de asignación de puertos al conectarse a través de AWS PrivateLink

Si el equilibrador de carga de red está asociado con un servicio de punto de conexión de VPC, admitirá 55 000 conexiones simultáneas o unas 55 000 conexiones por minuto con cada uno de los distintos destinos (dirección IP y puerto). Si se superan estas conexiones, el riesgo de que se produzcan errores de asignación de puertos será mayor. Los errores de asignación de puertos se pueden rastrear mediante la métrica PortAllocationErrorCount. Para solucionar los errores de asignación de puertos, agregue más destinos al grupo de destino. Para obtener más información, consulte CloudWatch métricas para su Network Load Balancer.

Fallo de conexión intermitente cuando la preservación de IP del cliente está habilitada

Si la preservación de la IP del cliente está habilitada, es posible que se produzcan limitaciones en la conexión TCP/IP relacionadas con la reutilización observada de los sockets en los destinos. Estas limitaciones de conexión pueden producirse cuando un cliente, o un dispositivo NAT situado delante del cliente, utiliza la misma dirección IP y el mismo puerto de origen al conectarse a varios nodos del equilibrador de carga simultáneamente. Si el equilibrador de carga enruta estas conexiones al mismo destino, el destino ve las conexiones como si procedieran del mismo socket de origen, lo que provoca errores de conexión. Si esto ocurre, los clientes pueden volver a intentarlo (si la conexión falla) o volver a conectarse (si la conexión se interrumpe). Puede reducir este tipo de error de conexión aumentando la cantidad de puertos efímeros de origen o la cantidad de destinos para el equilibrador de carga. Puede evitar este tipo de error de conexión si deshabilita la preservación de la IP del cliente o el equilibrio de carga entre zonas.

Además, cuando la preservación de la IP del cliente está habilitada, la conectividad puede fallar si los clientes que se conectan al equilibrador de carga de red también están conectados a los destinos situados detrás del equilibrador de carga. Para solucionar este problema, puede deshabilitar la preservación de la IP del cliente en los grupos de destino afectados. Como alternativa, haga que sus clientes se conecten solo al equilibrador de carga de red o solo a los destinos, pero no a ambos.

Retrasos en la conexión TCP

Cuando se habilitan tanto el equilibrio de carga entre zonas como la preservación de la IP del cliente, un cliente que se conecte a diferentes IP del mismo equilibrador de carga puede enrutarse al mismo destino. Si el cliente usa el mismo puerto de origen para ambas conexiones, el destino recibirá lo que parece ser una conexión duplicada, lo que puede provocar errores de conexión y demoras en el TCP a la hora de establecer nuevas conexiones. Puede evitar este tipo de error de conexión si deshabilita el equilibrio de carga entre zonas. Para obtener más información, consulte Equilibrio de carga entre zonas.

Posible error al aprovisionar el equilibrador de carga

Una de las razones por las que un equilibrador de carga de red puede fallar durante el aprovisionamiento es si utiliza una dirección IP que ya está asignada o que está asignada en otro lugar (por ejemplo, asignada como dirección IP secundaria para una instancia de EC2). Esta dirección IP impide que se configure el equilibrador de carga y su estado es failed. Para resolver este problema, desasigne la dirección IP asociada y vuelva a intentar el proceso de creación.

La resolución de nombres DNS contiene menos direcciones IP que las zonas de disponibilidad habilitadas

Lo ideal sería que su equilibrador de carga de red proporcionara una dirección IP por cada zona de disponibilidad habilitada, cuando tuviera al menos un host en buen estado en la zona de disponibilidad. Si no hay un host en buen estado en una zona de disponibilidad determinada y el equilibrio de carga entre zonas está deshabilitado, la dirección IP del equilibrador de carga de red correspondiente a esa zona de disponibilidad se eliminará del DNS.

Por ejemplo, supongamos que su equilibrador de carga de red tiene habilitadas tres zonas de disponibilidad y todas tienen al menos una instancia de destino registrada en buen estado.

• Si las instancias de destino registradas en la zona de disponibilidad A dejan de funcionar, la dirección IP correspondiente de la zona de disponibilidad A para el equilibrador de carga de red se elimina del DNS.

• Si dos de las zonas de disponibilidad habilitadas no tienen ninguna instancia de destino registrada en buen estado, las dos direcciones IP respectivas del equilibrador de carga de red se eliminarán del DNS.

• Si no hay ninguna instancia de destino registrada en buen estado en todas las zonas de disponibilidad habilitadas, se habilita el modo de apertura por error y, como resultado, el DNS proporcionará todas las direcciones IP de las tres zonas de disponibilidad habilitadas.

Solucione los problemas de los objetivos en mal estado mediante el mapa de recursos

Si los objetivos de Network Load Balancer no superan las comprobaciones de estado, puede utilizar el mapa de recursos para encontrar los objetivos en mal estado y tomar medidas en función del código del motivo del error. Para obtener más información, consulte Mapa de recursos de Network Load Balancer.

El mapa de recursos ofrece dos vistas: vista general y mapa objetivo en mal estado. La vista general está seleccionada de forma predeterminada y muestra todos los recursos del balanceador de cargas. Al seleccionar la vista Mapa de objetivos en mal estado, solo se mostrarán los objetivos en mal estado de cada grupo de objetivos asociado al Network Load Balancer.

nota

La opción Mostrar detalles de los recursos debe estar habilitada para ver el resumen de la comprobación de estado y los mensajes de error de todos los recursos aplicables del mapa de recursos. Si no está activado, debe seleccionar cada recurso para ver sus detalles.

La columna Grupos objetivo muestra un resumen de los objetivos saludables y no saludables de cada grupo objetivo. Esto puede ayudar a determinar si todos los objetivos están fallando en los controles de estado o solo algunos objetivos específicos están fallando. Si todos los objetivos de un grupo objetivo no pasan los controles de estado, compruebe la configuración de los controles de estado del grupo objetivo. Seleccione el nombre de un grupo objetivo para abrir su página de detalles en una pestaña nueva.

La columna TargetID muestra el TargetID y el estado actual de la comprobación de estado de cada objetivo. Cuando un objetivo no está en buen estado, se muestra el código del motivo del error en la comprobación de estado. Cuando un solo objetivo no supere una comprobación de estado, compruebe que el objetivo tiene recursos suficientes. Selecciona el ID de un objetivo para abrir su página de detalles en una pestaña nueva.

Al seleccionar Exportar, tiene la opción de exportar la vista actual del mapa de recursos de su balanceador de carga de red en formato PDF.

Compruebe que su instancia no supere las comprobaciones de estado y, a continuación, compruebe el código del motivo de la falla para detectar los siguientes problemas:

• Incorrecto: se agotó el tiempo de espera de la solicitud

  • Compruebe que los grupos de seguridad y las listas de control de acceso a la red (ACL) asociados a sus objetivos y a Network Load Balancer no bloqueen la conectividad.

  • Compruebe que el destino tenga suficiente capacidad disponible para aceptar conexiones desde el Network Load Balancer.

  • Las respuestas a las comprobaciones de estado del balanceador de carga de red se pueden ver en los registros de aplicaciones de cada destino. Para obtener más información, consulta los códigos de motivo de Health Check.

• Insalubre: FailedHealthChecks

  • Compruebe que el objetivo esté escuchando el tráfico en el puerto de comprobación de estado.

    Cuando se utiliza un detector de TLS

    Usted elige qué política de seguridad se utilizará para las conexiones front-end. La política de seguridad utilizada para las conexiones de back-end se selecciona automáticamente en función de la política de seguridad de front-end que se utilice.

    • Si su agente de escucha de TLS utiliza una política de seguridad de TLS 1.3 para las conexiones de front-end, la política de seguridad se utiliza para las conexiones de back-end. ELBSecurityPolicy-TLS13-1-0-2021-06

    • Si su agente de escucha de TLS no utiliza una política de seguridad de TLS 1.3 para las conexiones de front-end, la política de seguridad se utilizará para las conexiones de back-end. ELBSecurityPolicy-2016-08

    Para obtener más información, consulte Políticas de seguridad.

  • Compruebe que el destino proporciona un certificado y una clave de servidor en el formato correcto especificado en la política de seguridad.

  • Compruebe que el destino admita uno o más cifrados coincidentes y un protocolo proporcionado por el Network Load Balancer para establecer protocolos de enlace TLS.