Soluciona problemas de balanceadores de cargas de aplicaciones externos

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

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:

Soluciona problemas generales de conectividad

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 respuesta de error HTTP (5XX) y lo muestra al cliente. El balanceador de cargas no genera todos los errores HTTP . Por ejemplo, si un backend envía una respuesta HTTP 5XX al balanceador de cargas y el balanceador retransmite esa respuesta a su cliente. Para determinar si una respuesta HTTP 5XX se retransmitió desde un backend o si el proxy del balanceador de cargas la generó, consulta campo statusDetails de los registros del balanceador de cargas.

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

Para las respuestas de errores HTTP con statusDetails que no coinciden con la cadena de registro response_sent_by_backend, haz lo siguiente:

  • El balanceador de cargas de aplicaciones externo global y el balanceador de cargas de aplicaciones externo regional generan códigos de error de respuesta HTTP significativos, como 503 (servicio no disponible) y 504 (tiempo de espera de puerta de enlace).

  • El balanceador de cargas de aplicaciones clásico siempre usa el código de error de respuesta HTTP 502.

Los cambios de configuración en el balanceador de cargas de aplicaciones externo global, como la adición o eliminación de un servicio de backend, pueden dar como resultado un breve período en el que los usuarios ven el código de error de respuesta HTTP 502. Si bien estos cambios de configuración se propagan a los GFE a nivel global, verás entradas de registro en las que el campo statusDetails coincide con la string de registro failed_to_pick_backend.

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

  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 statusDetails que coincide con failed_to_pick_backend, lo que indica que el balanceador de cargas no pudo elegir un backend en buen estado para manejar la solicitud.

  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 HTTP 200 OK del backend.

  3. Verifica que el software en los backends esté en ejecución. Para ello, comprueba si el balanceador de cargas entrega la respuesta 5xx o si esta se genera desde los backends. Sigue los siguientes pasos:

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

    2. Comprueba el valor del campo statusDetails:

      • Si statusDetails muestra un mensaje de éxito, como response_sent_by_backend, significa que es el backend que entrega respuestas HTTP 502. Verifica los registros del backend y soluciona problemas cualquier problema adicional según el servicio que se ejecuta en el backend.
      • Si statusDetails muestra un mensaje de error, consulta la siguiente lista de soluciones para algunos de los errores comunes relacionados con las respuestas 5xx:
      Mensaje de error de statusDetail Posibles causas y soluciones
      failed_to_connect_to_backend

      El balanceador de cargas no pudo establecer una conexión con el backend. Esto podría significar que el servicio que se ejecuta en el backend no escucha en el puerto definido en el servicio de backend.

      Recomendaciones:

      • Configura el puerto de verificación de estado para usar el puerto de entrega. Esto significa que el backend se verá en mal estado antes de que sea apto para entregar tráfico real.
      • Usa el siguiente comando para asegurarte de que haya un servicio en ejecución en el puerto con nombre del servicio de backend: 
        $ netstat -tnl | grep PORT
      failed_to_pick_backend

      El balanceador de cargas no pudo elegir un backend. Esto podría significar que todos los backends están en mal estado. Asegúrate de haber configurado las reglas de firewall correctas para las verificaciones de estado.

      backend_connection_closed_before_data_sent_to_client El backend cerró su conexión con el balanceador de cargas de forma inesperada antes de que la respuesta se enviara al cliente mediante proxy. Esto puede suceder si el balanceador de cargas envía tráfico a otra entidad. La otra entidad puede ser un balanceador de cargas de terceros que tiene un tiempo de espera de TCP más corto que el del balanceador de cargas. Para obtener más detalles, consulta Tiempos de espera y reintentos.
      backend_timeout El backend tardó demasiado en responder. Es posible que el tiempo de espera del servicio de backend esté configurado en un valor demasiado bajo para que el servicio determinado responda. Considera aumentar el tiempo de espera del servicio de backend o averigua por qué tu servicio tarda tanto en responder.

  4. 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).

Resuelve errores HTTP 408

Con el tráfico HTTP, la cantidad máxima de tiempo para que el cliente complete el envío de su solicitud es igual al tiempo de espera del servicio de backend. Si ves respuestas HTTP 408 con jsonPayload.statusDetail client_timed_out, esto significa que no hubo un progreso suficiente mientras la solicitud del cliente o la respuesta del backend se envió a través de un proxy. Si el problema se debe a clientes que tienen problemas de rendimiento, puedes resolverlo con el aumento del tiempo de espera del servicio de backend.

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

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

  • Conexión 1, desde el cliente original hasta el balanceador de cargas (GFE o subred de solo proxy)
  • Conexión 2, desde el balanceador de cargas (GFE o subred de solo proxy) hasta el extremo o la VM de backend

Las direcciones IP de origen y destino de cada conexión difieren según el tipo de balanceador de cargas de aplicaciones externo que uses. Para obtener más información, consulta Direcciones IP de origen de paquetes de clientes.

Aparece un error de permisos cuando intento ver un objeto en mi bucket de Cloud Storage

Para entregar objetos mediante el balanceo de cargas, los objetos de Cloud Storage deben ser de acceso público. Actualiza los permisos de los objetos que necesitas entregar para que puedan leerse de forma pública.

La URL no entrega el objeto de Cloud Storage esperado

El objeto de Cloud Storage que se entrega se determina en función de tu mapeo de URL y la URL que solicitas. Si la ruta de solicitud se mapea a un bucket de backend en tu mapeo de URL, el objeto de Cloud Storage se determina agregando la ruta completa de la solicitud al bucket de Cloud Storage especificado en el mapeo de URL.

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


NoSuchKey
The specified key does not exist.

La compresión no funciona

El balanceador de cargas de aplicaciones externo no comprime ni descomprime las respuestas, pero puede entregar respuestas generadas por el servicio de backend comprimidas mediante herramientas como gzip o DEFLATE.

Si las respuestas que entrega el balanceador de cargas no están comprimidas, pero deberían estarlo, verifica si el software del servidor web que se ejecuta en tus instancias está configurado para comprimir las respuestas. De forma predeterminada, hay software de servidor web que inhabilita la compresión para las solicitudes que incluyen un encabezado Via, lo que indica que la solicitud se reenvió mediante un proxy. Dado que es un proxy, el balanceador de cargas de aplicaciones externo agrega un encabezado Via a cada solicitud según se requiere en la especificación HTTP. A fin de habilitar la compresión, es posible que tengas que anular la configuración predeterminada del servidor web para indicarle que comprima las respuestas, incluso si la solicitud tiene un encabezado Via.

Si deseas configurar los backends de NGINX para que entreguen respuestas comprimidas mediante un proxy a través de un balanceador de cargas de aplicaciones externo, haz lo siguiente:

Si deseas configurar los backends Apache para que entreguen respuestas comprimidas mediante un proxy a través de un balanceador de cargas de aplicaciones externo, haz lo siguiente:

Solucionar problemas de backends en mal estado

Soluciona problemas de HTTP/2 en los backends

Asegúrate de que tu instancia de backend esté en buen estado y sea compatible con el protocolo HTTP/2. Para verificar esto, prueba la conectividad a la instancia de backend mediante HTTP/2. Cerciórate de que la VM utilice conjuntos de cifrado HTTP/2 que cumplan con las especificaciones. Por ejemplo, HTTP/2 no permite determinados conjuntos de cifrado de TLS 1.2. Consulta la lista negra de conjuntos de cifrado de TLS 1.2.

Una vez que hayas verificado que la VM utiliza el protocolo HTTP/2, asegúrate de que la configuración de tu firewall permita el paso del verificador de estado y el balanceador de cargas.

Si no hay problemas con la configuración del firewall, asegúrate de que el balanceador de cargas esté configurado para comunicarse con el puerto correcto de la VM.

Soluciona problemas de NEG de Internet y backend externo

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

El tráfico no llega a los extremos

Después de configurar un servicio, se puede acceder al extremo nuevo mediante el balanceador de cargas de aplicaciones externo en estas situaciones:

  • El extremo está conectado a NEG de Internet.
  • El FQDN asociado puede resolverse con DNS de forma adecuada (si usas el tipo de extremo FQDN).
  • Se puede acceder al extremo a través de Internet.

Si el tráfico no puede llegar al extremo, y se genera un código de error 502, consulta el registro TXT _cloud-eoips.googleusercontent.com del DNS con una herramienta como dig o nslookup. Toma nota de los CIDR (después de ip4:) y asegúrate de que se permitan esos rangos en el firewall o la lista de control de acceso (LCA) en la nube.

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

  • Comprueba Logging.
  • Verifica que el grupo de extremos de red esté configurado con la IP:Puerto o el FQDN:Puerto correcto para tu backend externo.
  • Si usas un FQDN, asegúrate de que se pueda resolver a través del DNS público de Google. Puedes verificar que el FQDN se pueda resolver a través del DNS público de Google mediante estos pasos o directamente desde la interfaz web.
  • Si accedes al balanceador de cargas de HTTP(S) solo en su IP externa, y tu servidor web de origen espera un nombre de host, asegúrate de enviar un encabezado HTTP de host válido a tu backend mediante la configuración de un encabezado de solicitud personalizado.
  • Si te comunicas con un backend mediante HTTPS o HTTP2 (como se establece en el campo protocol del servicio de backend) configurado como un extremo de backend externo INTERNET_FQDN_PORT, asegúrate de que tu origen presente un certificado TLS (SSL) válido y que el FQDN configurado coincida con un SAN (nombre alternativo del asunto) en la lista de SAN de los certificados. Un certificado válido se define como uno firmado por una autoridad certificada pública que no esté vencido.
  • Cuando se usan extremos de backend externos INTERNET_FQDN_PORT, el balanceador de cargas de HTTPS no acepta los certificados autofirmados y estos se rechazan.
  • Cuando se usa HTTPS o HTTP/2 con extremos de tipo INTERNET_IP_PORT, no se realiza ninguna validación de certificado SSL o verificación de SAN. Esto significa que se pueden usar certificados autofirmados. Cuando se usa SSL, nuestra recomendación es usar extremos INTERNET_FQDN_PORT para asegurarnos de que los certificados de servidor y los SAN se puedan validar.

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

Asegúrate de que ocurra lo siguiente:

  • Habilitaste Cloud CDN en el servicio de backend que contiene el NEG que apunta a tu backend externo cuando configuraste enableCDN como verdadero.
  • Las respuestas que entrega tu backend externo cumplen con los requisitos de almacenamiento en caché de Cloud CDN. Por ejemplo, estás enviando encabezados de respuesta Cache-Control: public, max-age=3600 desde el origen.

Soluciona problemas de NEG sin servidores

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

Las solicitudes fallan con un error 404

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

En general, un balanceador de cargas de aplicaciones externo no puede detectar si el recurso sin servidores subyacente funciona como se espera. Esto significa que si el servicio muestra errores en una región, pero la infraestructura general de Cloud Run, funciones de Cloud Run o App Engine en esa región funciona con normalidad, el balanceador de cargas de aplicaciones externo no dirigirá el tráfico a otras regiones de forma automática. Asegúrate de probar de forma exhaustiva las versiones nuevas de los servicios antes de enrutar el tráfico de usuarios a ellos.

Controla las discrepancias de la máscara de URL

Si aplicar la máscara de URL configurada a una URL de solicitud de usuario da como resultado un nombre de servicio que no existe o no da ninguno, el balanceador de cargas podría manejar estas discrepancias de diferentes maneras según la plataforma de procesamiento sin servidores en uso.

Cloud Run: en caso de que una máscara de URL no coincida, el balanceador de cargas muestra un error de HTTP 404 (no se ha encontrado).

Funciones de Cloud Run: En caso de que una máscara de URL no coincida, el balanceador de cargas muestra un error de HTTP 404 (no se ha encontrado).

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