Esta página se ha traducido con Cloud Translation API.

Solucionar problemas con balanceadores de carga de aplicación externos

En esta guía se describe cómo solucionar problemas de configuración de balanceadores de carga de aplicaciones externos. Antes de investigar los problemas, familiarízate con las siguientes páginas:

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:

Solucionar problemas generales de conectividad

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 back-ends, el balanceador de carga genera un código de respuesta de error 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 una respuesta HTTP 5XX se ha retransmitido desde un backend o si la ha generado el proxy del balanceador de carga, consulta el campo statusDetails de los registros del balanceador de carga.

Si statusDetails devuelve una cadena de registro response_sent_by_backend, el balanceador de carga solo retransmite el código de respuesta que le haya enviado el backend. En ese caso, debes solucionar los problemas de las respuestas de error HTTP en tus backends.

En el caso de las respuestas de error HTTP con statusDetails que no coincidan con la cadena de registro response_sent_by_backend:

El balanceador de carga de aplicaciones externo global y el balanceador de carga de aplicaciones externo regional generan códigos de error de respuesta HTTP significativos, como 503 (Servicio no disponible) y 504 (Tiempo de espera de pasarela agotado).
El balanceador de carga de aplicaciones clásico siempre usa el código de error de respuesta HTTP 502.

Los cambios de configuración del balanceador de carga de aplicaciones externo global, como la adición o la eliminación de un servicio de backend, pueden provocar que los usuarios vean brevemente el código de error de respuesta HTTP 502. Aunque estos cambios de configuración se propaguen a los GFEs de todo el mundo, verás entradas de registro en las que el campo statusDetails coincida con la cadena de registro failed_to_pick_backend.

Si los errores 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 de las respuestas HTTP 5XX:

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 statusDetails coincidente failed_to_pick_backend, lo que indica que el balanceador de carga no ha podido elegir un backend en buen estado para gestionar la solicitud.
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 de salud 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.

Verifica que el software de los back-ends se esté ejecutando. Para ello, comprueba si el balanceador de carga está sirviendo la respuesta 5xx o si se genera desde los backends. Sigue estos pasos:

Usa Cloud Logging para ver los registros del balanceador de carga. Puedes crear una consulta para buscar solo códigos de respuesta 5xx.

Comprueba el valor del campo statusDetails:

Si statusDetails devuelve un mensaje de éxito, como response_sent_by_backend, significa que el backend es el que está sirviendo respuestas HTTP 502. Consulta los registros del backend y soluciona el problema en función del servicio que se esté ejecutando en el backend.
Si statusDetails devuelve un mensaje de error, consulta la siguiente lista de soluciones para algunos errores habituales relacionados con las respuestas 5xx:

Mensaje de error de statusDetail	Posibles causas y soluciones
`failed_to_connect_to_backend`	El balanceador de carga no ha podido establecer una conexión con el backend. Esto podría significar que el servicio que se ejecuta en el backend no está escuchando en el puerto definido en el servicio de backend. Recomendaciones: Define el puerto que debe usar la comprobación del estado: el puerto activo. Esto significa que el backend no estará en buen estado hasta que pueda servir tráfico real. Usa el siguiente comando para asegurarte de que hay un servicio que se ejecuta en el puerto con nombre del servicio de backend: $ netstat -tnl \| grep `PORT`
`failed_to_pick_backend`	El balanceador de carga no ha podido elegir un backend. Esto podría significar que todos los backends están en mal estado. Asegúrate de haber configurado las reglas de cortafuegos correctas para las comprobaciones del estado.
`backend_connection_closed_before_data_sent_to_client`	El backend ha cerrado inesperadamente su conexión con el balanceador de carga antes de que la respuesta se enviara al cliente a través de un proxy. Esto puede ocurrir si el balanceador de carga envía tráfico a otra entidad. La otra entidad puede ser un balanceador de carga de terceros que tenga un tiempo de espera de TCP inferior al del balanceador de carga. Para obtener más información, consulta Tiempos de espera y reintentos.
`backend_timeout`	El backend ha tardado demasiado en responder. Es posible que el tiempo de espera del servicio de backend sea demasiado bajo para que el servicio en cuestión responda. Te recomendamos que aumentes el tiempo de espera del servicio backend o que investigues por qué tu servicio tarda tanto en responder.

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 respuesta HTTP 5XX cuando la conexión con el backend se ha cerrado inesperadamente 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).

Solucionar errores HTTP `408`

En el tráfico HTTP, el tiempo máximo que tiene el cliente para completar el envío de su solicitud es igual al tiempo de espera del servicio de backend. Si ves respuestas HTTP 408 con el código jsonPayload.statusDetail client_timed_out, significa que no se ha avanzado lo suficiente mientras se ha proxyado la solicitud del cliente o la respuesta del backend. Si el problema se debe a que los clientes tienen problemas de rendimiento, puedes solucionarlo aumentando el tiempo de espera del servicio backend.

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

La dirección IP de origen de los paquetes, tal como la ven los backends, no es la dirección IP externa del balanceador de carga. Los balanceadores de carga basados en proxy, como los balanceadores de carga de aplicaciones externos, usan dos conexiones TCP para transmitir el tráfico del cliente a los backends:

Conexión 1, del cliente original al balanceador de carga (GFE o subred solo proxy)
Conexión 2, del balanceador de carga (GFE o subred solo proxy) a la VM o el endpoint de backend

Las direcciones IP de origen y destino de cada conexión varían en función del tipo de balanceador de carga de aplicaciones externo que utilices. Para obtener más información, consulta Direcciones IP de origen de los paquetes de clientes .

Recibo un error de permisos al intentar ver un objeto en mi segmento de Cloud Storage

Para servir objetos a través del balanceo de carga, los objetos de Cloud Storage deben ser accesibles públicamente. Asegúrate de actualizar los permisos de los objetos que se sirven para que se puedan leer públicamente.

La URL no proporciona el objeto de Cloud Storage esperado

El objeto de Cloud Storage que se va a servir se determina en función de tu mapa de URLs y de la URL que solicites. Si la ruta de la solicitud se asigna a un segmento de backend en tu mapa de URLs, el objeto de Cloud Storage se determina añadiendo la ruta de la solicitud completa al segmento de Cloud Storage que especifica el mapa de URLs.

Por ejemplo, si asignas /static/* a gs://[EXAMPLE_BUCKET], la solicitud a https://<GCLB IP or Host>/static/path/to/content.jpg intentará servir gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg. Si ese objeto no existe, recibirás el siguiente mensaje de error en lugar del objeto:


NoSuchKey
The specified key does not exist.

La compresión no funciona

Un balanceador de carga de aplicaciones externo no comprime ni descomprime las respuestas, pero puede servir respuestas generadas por tu servicio de backend que estén comprimidas mediante herramientas como gzip o DEFLATE.

Si las respuestas que sirve el balanceador de carga no están comprimidas, pero deberían estarlo, compruebe que el software del servidor web que se ejecuta en sus instancias esté configurado para comprimir las respuestas. De forma predeterminada, algunos software de servidor web inhabilitan automáticamente la compresión de las solicitudes que incluyen un encabezado Via, lo que indica que un proxy ha reenviado la solicitud. Como es un proxy, el balanceador de carga de aplicaciones externo añade un encabezado Via a cada solicitud, tal como requiere la especificación HTTP. Para habilitar la compresión, es posible que tengas que anular la configuración predeterminada de tu servidor web para indicarle que comprima las respuestas aunque la solicitud tenga un encabezado Via.

Para configurar backends de nginx para que sirvan respuestas comprimidas proxyizadas a través de un balanceador de carga de aplicaciones externo, sigue estos pasos:

Define la directiva gzip_proxied de forma adecuada (por ejemplo, como any) y
Asigna el valor on a la directiva gzip_vary.

Para configurar los backends de Apache para que sirvan respuestas comprimidas proxyizadas a través de un balanceador de carga de aplicaciones externo, sigue estos pasos:

Usa el filtro DEFLATE.
Añade Vary Accept-Encoding al encabezado de respuesta con el módulo mod_headers.

Solucionar problemas de backends en mal estado

Solucionar problemas con HTTP/2 en los backends

Asegúrate de que tu instancia de backend esté en buen estado y admita el protocolo HTTP/2. Puedes comprobarlo probando la conectividad a la instancia de backend mediante HTTP/2. Asegúrate de que la VM usa conjuntos de cifrado que cumplen la especificación HTTP/2. Por ejemplo, HTTP/2 no permite determinados conjuntos de cifrado TLS 1.2. Consulta la lista negra de conjuntos de cifrado TLS 1.2.

Después de verificar que la VM usa el protocolo HTTP/2, asegúrese de que la configuración de su firewall permite que pasen el comprobador de estado y el balanceador de carga.

Si no hay ningún problema con la configuración del cortafuegos, asegúrate de que el balanceador de carga esté configurado para comunicarse con el puerto correcto de la VM.

Solucionar problemas de backends externos y NEGs de Internet

Antes de investigar los problemas, familiarízate con las siguientes páginas:

El tráfico no llega a los endpoints

Una vez que hayas configurado un servicio, se podrá acceder al nuevo endpoint a través del balanceador de carga de aplicaciones externo cuando se cumplan las siguientes condiciones:

El punto final está asociado al NEG de Internet.
El FQDN asociado se puede resolver correctamente mediante DNS (si usas el tipo de endpoint FQDN).
Se puede acceder al endpoint a través de Internet.

Si el tráfico no puede llegar al endpoint, lo que da como resultado un código de error 502, consulta el registro TXT de DNS _cloud-eoips.googleusercontent.com con una herramienta como dig o nslookup. Anota los CIDRs (después de ip4:) y asegúrate de que tu cortafuegos o lista de control de acceso (LCA) de la nube permitan estos intervalos.

Después de configurar un backend externo, las solicitudes al backend externo fallan con un error 5xx

Marca Logging (Registro).
Verifica que el grupo de puntos finales de red esté configurado con la IP:puerto o el FQDN:puerto correctos de tu backend externo.
Si usas un FQDN, asegúrate de que se pueda resolver a través de Google Public DNS. Puedes verificar que el FQDN se puede resolver a través de Google Public DNS siguiendo estos pasos o directamente en la interfaz web.
Si solo accedes al balanceador de carga a través de su dirección IP externa y tu servidor web de origen espera un nombre de host, asegúrate de enviar un encabezado Host HTTP válido a tu backend configurando un encabezado de solicitud personalizado.
Si te comunicas con un backend a través de HTTPS o HTTP2 (como se define en el campo protocol del servicio de backend) configurado como un endpoint de backend externo INTERNET_FQDN_PORT, asegúrate de que tu origen presente un certificado TLS (SSL) válido y de que el FQDN configurado coincida con un SAN (nombre alternativo del sujeto) de la lista de SANs de los certificados. Un certificado válido es aquel que está firmado por una autoridad de certificación pública y que no ha caducado.
Cuando se usan endpoints de backend externos de INTERNET_FQDN_PORT, el balanceador de carga no acepta los certificados autofirmados y los rechaza.
Cuando se usa HTTPS o HTTP/2 con endpoints de tipo INTERNET_IP_PORT, no se realiza ninguna validación de certificado SSL ni comprobación de SAN. Esto significa que se pueden usar certificados autofirmados. Cuando utilice SSL, le recomendamos que use los endpoints INTERNET_FQDN_PORT para asegurarse de que se puedan validar los certificados de servidor y los SANs.

Cloud CDN no almacena en caché las respuestas de mi backend externo

Asegúrate de que:

Has habilitado Cloud CDN en el servicio de backend que contiene el NEG que apunta a tu backend externo. Para ello, has asignado el valor true a enableCDN.
Las respuestas que sirve tu backend externo cumplen los requisitos de almacenamiento en caché de Cloud CDN. Por ejemplo, estás enviando Cache-Control: public, max-age=3600encabezados de respuestaCache-Control: public, max-age=3600 desde el origen.

Solucionar problemas con NEGs sin servidor

Antes de investigar los problemas, familiarízate con las siguientes páginas:

Las solicitudes fallan y devuelven un error 404

Asegúrate de que el recurso sin servidor subyacente (como un servicio de App Engine, Cloud Run functions o Cloud Run) siga en ejecución. Si se elimina el recurso sin servidor, pero el NEG sin servidor sigue existiendo, el balanceador de carga de aplicaciones externo seguirá intentando enrutar las solicitudes al servicio que ya no existe. Esto da como resultado una respuesta 404.

Por lo general, un balanceador de carga de aplicaciones externo no puede detectar si el recurso sin servidor subyacente funciona correctamente. Esto significa que, si tu servicio de una región devuelve errores, pero la infraestructura general de Cloud Run, Cloud Functions o App Engine de esa región funciona con normalidad, tu balanceador de carga de aplicaciones externo no dirigirá automáticamente el tráfico a otras regiones. Asegúrate de probar a fondo las nuevas versiones de tus servicios antes de dirigir el tráfico de usuarios a ellas.

Gestionar errores de coincidencia de máscaras de URL

Si al aplicar la máscara de URL configurada a la URL de una solicitud de usuario no se obtiene ningún nombre de servicio o se obtiene un nombre de servicio que no existe, el balanceador de carga puede gestionar estas discrepancias de forma diferente en función de la plataforma de computación sin servidor que se utilice.

Cloud Run: si no coincide la máscara de URL, el balanceador de carga devuelve un error HTTP 404 (No encontrado).

Funciones de Cloud Run: si no coincide la máscara de URL, el balanceador de carga devuelve un error HTTP 404 (No encontrado).

App Engine: si no coincide la máscara de URL, App Engine usa dispatch.yaml y la lógica de enrutamiento predeterminada de App Engine para determinar a qué servicio enviar la solicitud.

Solucionar problemas con balanceadores de carga de aplicación externos Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.