Soluciona problemas de balanceadores de cargas de aplicaciones internos

En esta guía, se describe cómo solucionar problemas de configuración de un balanceador de cargas de aplicaciones interno de Google Cloud. Antes de seguir esta guía, familiarízate con los siguientes conceptos:

• Descripción general del balanceador de cargas de aplicaciones interno
• Subredes de solo proxy
• Registro y supervisión del balanceador de cargas de aplicaciones interno

Soluciona los problemas comunes con Network Analyzer

Network Analyzer supervisa de forma automática la configuración de tu red de VPC y detecta configuraciones subóptimas y incorrectas. Identifica fallas de red, proporciona información sobre la causa raíz y sugiere posibles soluciones. Para obtener información sobre las diferentes situaciones de configuración incorrecta que se detectan de forma automática con Network Analyzer, consulta Estadísticas del balanceador de cargas en la documentación de Network Analyzer.

Network Analyzer está disponible en la consola de Google Cloud como parte de Network Intelligence Center.

Ir a Network Analyzer

Los backends tienen modos de balanceo incompatibles

Cuando creas un balanceador de cargas, es posible que veas el siguiente error:

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

Esto sucede cuando intentas usar el mismo backend en dos balanceadores de cargas diferentes y los backends no tienen modos de balanceo compatibles.

Para obtener más información, consulta lo siguiente:

• Restricciones y recomendaciones para grupos de instancias
• Cambia el modo de balanceo de un balanceador de cargas

El tráfico con balanceo de cargas no tiene la dirección de origen del cliente original

Se prevé que esto suceda. Un balanceador de cargas de aplicaciones interno funciona como un proxy inverso (puerta de enlace) HTTP(S). Cuando el programa cliente abre una conexión a la dirección IP de una regla de reenvío INTERNAL_MANAGED, la conexión finaliza en un proxy. El proxy procesa las solicitudes que llegan a través de esa conexión. Para cada solicitud, el proxy selecciona un backend a fin de recibir la solicitud en función del mapa de URL y otros factores. Luego, envía la solicitud al backend seleccionado. Por consiguiente, desde el punto de vista del backend, la fuente de un paquete entrante es una dirección IP de la subred de solo proxy de la región.

El balanceador de cargas rechaza las solicitudes

Para cada solicitud, el proxy selecciona un backend que recibe la solicitud en función de comparador de rutas de acceso en el mapa de URL del balanceador de cargas. Si el mapa de URL no tiene un comparador de rutas de acceso definido para una solicitud, no puede seleccionar un servicio de backend, por lo que muestra un código de respuesta HTTP 404 (No encontrado).

El balanceador de cargas no se conecta a los backends

Los firewalls que protegen tus servidores de backend se tienen que configurar a fin de permitir el ingreso de tráfico desde los proxies en rango de subred de solo proxy que asignaste a la región de tu balanceador de cargas HTTP(S) interno.

Los proxies se conectan a los backends mediante la configuración de conexión especificada por la configuración de tu servicio de backend. Si estos valores no coinciden con la configuración de los servidores que se ejecutan en los backends, el proxy no puede reenviar solicitudes a estos.

Los sondeos de verificación de estado no pueden alcanzar los backends

Para verificar que el tráfico de verificación de estado llegue a tus VM de backend, habilita el registro de verificación de estado y busca entradas de registro exitosas.

Los clientes no pueden conectarse al balanceador de cargas

Los proxies detectan las conexiones con la dirección IP y el puerto del balanceador de cargas que se configuraron en la regla de reenvío (por ejemplo, 10.1.2.3:80) y con el protocolo especificado en la regla de reenvío (HTTP o HTTPS). Si los clientes no se pueden conectar, asegúrate de que usen la dirección, el puerto y el protocolo correctos.

Asegúrate de que un firewall no esté bloqueando el tráfico entre las instancias de los clientes y la dirección IP del balanceo de cargas.

Asegúrate de que los clientes estén en la misma región que el balanceador de cargas. El balanceo de cargas de HTTP(S) interno es un producto regional, por lo que todos los clientes (y backends) deben estar en la misma región que el recurso del balanceador de cargas.

Restricción de la política de la organización para la VPC compartida

Si usas la VPC compartida y no puedes crear un nuevo balanceador de cargas de aplicaciones interno en una subred particular, la causa podría ser una política de la organización. En la política de la organización, agrega la subred a la lista de subredes permitidas o comunícate con el administrador de tu organización. Para obtener más información, consulta constraints/compute.restrictSharedVpcSubnetworks

El balanceador de cargas no distribuye el tráfico de manera uniforme entre las zonas

Es posible que observes un desequilibrio en el tráfico del balanceador de cargas de aplicaciones interno entre las zonas. Esto puede suceder especialmente cuando el uso es bajo (menos del 10%) de tu capacidad de backend.

Este comportamiento puede afectar la latencia general, ya que el tráfico se envía solo a algunos servidores en una zona.

Para equilibrar la distribución del tráfico entre zonas, puedes realizar los siguientes cambios de configuración:

• Usa el modo de balanceo RATE con una capacidad objetivo max-rate-per-instance baja.
• Usa la política de tráfico del backend LocalityLbPolicy con un algoritmo de balanceo de cargas de LEAST_REQUEST.

Errores 5xx sin motivo

Para las condiciones de error causadas por un problema de comunicación entre el proxy del balanceador de cargas y sus backends, el balanceador de cargas genera un código de estado HTTP (5xx) y lo muestra al cliente. El balanceador de cargas no genera todos los errores HTTP 5xx. Por ejemplo, si un backend envía una respuesta HTTP 5xx al balanceador de cargas, el balanceador retransmite esa respuesta a su cliente. Para determinar si una respuesta 5xx HTTP se retransmitió desde un backend o si el proxy del balanceador de cargas la generó, consulta el campo proxyStatus de los registros del balanceador de cargas.

Los cambios de configuración en el balanceador de cargas interno de aplicaciones, como agregar o quitar un servicio de backend, pueden generar un período breve en el que los usuarios ven el código de estado HTTP 503. Si bien estos cambios de configuración se propagan a los Envoys a nivel global, verás entradas de registro en las que el campo proxyStatus coincide con la cadena de registro connection_refused.

Si los códigos de estado HTTP 5xx persisten más de unos minutos después de completar la configuración del balanceador de cargas, sigue estos pasos para solucionar los problemas de las respuestas 5xx HTTP:

1. Comprueba que haya una regla de firewall configurada para permitir verificaciones de estado. Si no hay una, los registros del balanceador de cargas suelen tener un proxyStatus que coincide con destination_unavailable, lo que indica que el balanceador de cargas considera que el backend no está disponible.

2. Verifica que el tráfico de verificación de estado llegue a tus VM de backend. Para ello, habilita el registro de verificación de estado y busca entradas de registro exitosas.

   Para los balanceadores de cargas nuevos, la falta de entradas de registro de verificación de estado correctas no significa que el tráfico de verificación de estado no llegue a los backends. Podría significar que el estado inicial del backend aún no cambió de UNHEALTHY a un estado diferente. Verás entradas de registro de verificaciones de estado exitosas solo después de que el sistema de sondeo de verificación de estado reciba una respuesta 200 OK HTTP del backend.

3. Verifica que el parámetro de configuración de keepalive para el software del servidor HTTP que se ejecuta en la instancia de backend no sea menor que el tiempo de espera de keepalive del balanceador de cargas, cuyo valor se fija en 10 minutos (600 segundos) y es no configurable.

   El balanceador de cargas genera un código de estado HTTP 5xx cuando la conexión al backend se cerró de forma inesperada mientras se envió la solicitud HTTP o antes de que se haya recibido la respuesta HTTP completa. Esto puede suceder porque el parámetro de configuración de keepalive para el software del servidor web que se ejecuta en la instancia de backend es menor que el tiempo de espera de keepalive fijado del balanceador de cargas. Asegúrate de que la configuración del tiempo de espera de keepalive del software del servidor HTTP en cada backend esté configurada en un poco más de 10 minutos (el valor recomendado es de 620 segundos).

Limitaciones

Si tienes problemas para usar el balanceo de cargas de aplicaciones interno con otras funciones de herramientas redes de Google Cloud, ten en cuenta las limitaciones de compatibilidad actuales.