Solucionar problemas con los balanceadores de carga de aplicaciones internos

En esta guía se describe cómo solucionar problemas de configuración de un balanceador de carga de aplicaciones interno de Google Cloud . Antes de seguir esta guía, familiarícese con lo siguiente:

• Descripción general del balanceador de carga de aplicaciones interno
• Subredes de solo proxy
• Registro y monitorización del balanceador de carga de aplicación interno

Solucionar problemas habituales con Analizador de red

Network Analyzer monitoriza automáticamente la configuración de tu red de VPC y detecta tanto las configuraciones no óptimas como las erróneas. Identifica los errores de red, proporciona información sobre la causa principal y sugiere posibles soluciones. Para obtener información sobre los diferentes casos de configuración incorrecta que detecta automáticamente Network Analyzer, consulte Estadísticas de balanceadores de carga en la documentación de Network Analyzer.

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

Ir a Network Analyzer

Los back-ends tienen modos de balanceo incompatibles

Al crear un balanceador de carga, puede que aparezca 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 ocurre cuando intentas usar el mismo backend en dos balanceadores de carga diferentes y los backends no tienen modos de balanceo compatibles.

Para obtener más información, consulta las siguientes secciones:

• Restricciones y directrices para grupos de instancias
• Cambiar el modo de balanceo de carga de un balanceador de carga

El tráfico balanceado de carga no tiene la dirección de origen del cliente original

Es completamente normal. Un balanceador de carga de aplicaciones interno funciona como un proxy inverso(una pasarela) HTTP (S). Cuando un 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. En cada solicitud, el proxy selecciona un backend para recibir la solicitud en función del mapa de URLs y otros factores. A continuación, el proxy envía la solicitud al backend seleccionado. Por lo tanto, desde el punto de vista del backend, el origen de un paquete entrante es una dirección IP de la subred solo proxy de la región.

El balanceador de carga rechaza las solicitudes

En cada solicitud, el proxy selecciona un backend para recibir la solicitud en función de un matcher de ruta en el mapa de URLs del balanceador de carga. Si el mapa de URLs no tiene un elemento PathMatcher definido para una solicitud, no puede seleccionar un servicio de backend, por lo que devuelve un código de respuesta HTTP 404 (No encontrado).

El balanceador de carga no se conecta a los backends

Los cortafuegos que protegen tus servidores backend deben configurarse para permitir el tráfico de entrada de los proxies del intervalo de la subred de solo proxy que has asignado a la región de tu balanceador de carga HTTP(S) interno.

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

Las comprobaciones del estado no pueden acceder a los backends

Para verificar que el tráfico de comprobación del estado llega a tus VMs de backend, habilita el registro de comprobación del estado y busca entradas de registro correctas.

Los clientes no pueden conectarse al balanceador de carga

Los proxies escuchan las conexiones a la dirección IP y al puerto del balanceador de carga configurados 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 tus clientes no pueden conectarse, asegúrate de que estén usando la dirección, el puerto y el protocolo correctos.

Asegúrate de que un cortafuegos no esté bloqueando el tráfico entre tus instancias de cliente y la dirección IP balanceada de carga.

Asegúrate de que los clientes estén en la misma región que el balanceador de carga. El balanceo de carga 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 de balanceador de carga.

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

Si utilizas una VPC compartida y no puedes crear un balanceador de carga de aplicaciones interno en una subred concreta, puede que se deba a una política de la organización. En la política de la organización, añade la subred a la lista de subredes permitidas o ponte en contacto con el administrador de tu organización. Para obtener más información, consulta constraints/compute.restrictSharedVpcSubnetworks.

El balanceador de carga no distribuye el tráfico de forma uniforme entre las zonas

Puede que observes un desequilibrio en el tráfico de tu balanceador de carga de aplicación interno entre zonas. Esto puede ocurrir sobre todo cuando la utilización de tu capacidad de backend es baja (menos del 10%).

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

Para equilibrar la distribución del tráfico entre zonas, puede hacer los siguientes cambios en la configuración:

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

Errores 5xx inexplicables

En el caso de los errores causados por un problema de comunicación entre el proxy del balanceador de carga y sus backends, el balanceador de carga genera un código de estado HTTP (5xx) y lo devuelve al cliente. No todos los errores HTTP 5xx los genera el balanceador de carga. Por ejemplo, si un backend envía una respuesta HTTP 5xx al balanceador de carga, este reenvía esa respuesta a su cliente. Para determinar si se ha retransmitido una respuesta HTTP 5xx desde un backend o si la ha generado el proxy del balanceador de carga, consulta el campo proxyStatus de los registros del balanceador de carga.

Los cambios de configuración del balanceador de carga de aplicaciones interno, como la adición o la eliminación de un servicio de backend, pueden provocar que los usuarios vean el código de estado HTTP 503 durante un breve periodo. Mientras estos cambios de configuración se propagan a los Envoys de todo el mundo, verás entradas de registro en las que el campo proxyStatus coincida con la cadena de registro connection_refused.

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

1. Verifica que haya una regla de cortafuegos configurada para permitir las comprobaciones del estado. Si no hay ninguna, los registros del balanceador de carga suelen tener un proxyStatus coincidente con destination_unavailable, lo que indica que el balanceador de carga considera que el backend no está disponible.

2. Verifica que el tráfico de comprobación de estado llegue a tus VMs de backend. Para ello, habilita el registro de comprobaciones del estado y busca entradas de registro correctas.

   En el caso de los balanceadores de carga nuevos, la falta de entradas de registro de comprobaciones del estado correctas no significa que el tráfico de comprobación del estado no llegue a los backends. Puede que el estado inicial del backend aún no haya cambiado de UNHEALTHY a otro estado. Solo verás entradas de registro de comprobación del estado correctas después de que el comprobador de estado reciba una respuesta HTTP 200 OK del backend.

3. Verifica que el parámetro de configuración keepalive del software del servidor HTTP que se ejecuta en la instancia de backend no sea inferior al tiempo de espera keepalive del balanceador de carga, cuyo valor es fijo (10 minutos o 600 segundos) y no se puede configurar.

   El balanceador de carga genera un código de estado HTTP 5xx cuando la conexión con el backend se ha cerrado de forma inesperada mientras se enviaba la solicitud HTTP o antes de que se recibiera la respuesta HTTP completa. Esto puede ocurrir porque el parámetro de configuración keepalive del software del servidor web que se ejecuta en la instancia de backend es inferior al tiempo de espera keepalive fijo del balanceador de carga. Asegúrate de que el tiempo de espera de keep-alive del software del servidor HTTP de cada backend sea ligeramente superior a 10 minutos (el valor recomendado es 620 segundos).

Limitaciones

Si tienes problemas para usar un balanceador de carga de aplicaciones interno con otrasGoogle Cloud funciones de red, ten en cuenta las limitaciones de compatibilidad actuales.