Soluciona problemas del balanceo de cargas de HTTP(S)

En esta guía, se describe cómo solucionar problemas de configuración de un balanceador de cargas de HTTP(S) externo de Google Cloud.

Descripción general

Los tipos de problemas tratados en esta guía incluyen los siguientes:

  • Problemas generales de conectividad
  • Solución de problemas con HTTP/2 en los backends
  • Problemas de NEG de Internet y de origen personalizado
  • Problemas con NEG sin servidores (Beta)

Antes de comenzar

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

Sobre conectividad general:

Sobre orígenes personalizados y NEG de Internet:

Sobre NEG sin servidores:

Soluciona problemas generales de conectividad

Errores 502 sin motivo

Si los errores 502 persisten durante más de unos minutos después de completar la configuración del balanceador de cargas, puede ser por algunas de las siguientes opciones:

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.

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

El tráfico del balanceador de cargas a las instancias tiene una dirección IP entre 130.211.0.0/2235.191.0.0/16. Cuando visualices los registros de tus instancias de balanceo de cargas, no verás la dirección de origen del cliente original. En su lugar, verás direcciones de origen de este rango.

Aparece un error de permisos cuando intento ver un objeto en mi depósito 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 depósito de backend en tu mapeo de URL, el objeto de Cloud Storage se determina agregando la ruta completa de la solicitud al depósito 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 balanceo de cargas de HTTP(S) 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 balanceo de cargas de HTTP(S) 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 de manera predeterminada, lo que indica que la solicitud se reenvió mediante un proxy. Dado que el balanceo de cargas de HTTP(S) es un proxy, 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 usas el software del servidor web nginx, modifica el archivo de configuración nginx.conf para habilitar la compresión. La ubicación de este archivo depende del lugar en el que está instalado nginx. En muchas distribuciones de Linux, el archivo se almacena en /etc/nginx/nginx.conf. Para permitir que la compresión nginx funcione con el balanceo de cargas de HTTP(S), agrega las siguientes dos líneas a la sección http de nginx.conf:

gzip_proxied any;
gzip_vary on;

La primera línea habilita la compresión, incluso para las solicitudes reenviadas mediante un proxy como el balanceo de cargas de HTTP(S). La segunda línea agrega un encabezado Vary: Accept-Encoding a las respuestas. Vary: Accept-Encoding notifica a los proxies de almacenamiento en caché, como Cloud CDN, que deben mantener entradas de caché separadas para las variantes comprimidas y no comprimidas de los recursos que se pueden comprimir.

Después de modificar nginx.conf, es necesario que reinicies nginx antes de que use la configuración nueva. En muchas distribuciones de Linux, puedes reiniciar nginx si ejecutas sudo service nginx restart o /etc/init.d/nginx restart.

Soluciona problemas con HTTP/2 en los backends

Valor no válido para el campo resource.loadBalancingScheme: "EXTERNAL"

Aún no se admite el balanceo de cargas de red basado en servicios de backend.

Esto puede suceder si creas un servicio de backend sin seleccionar la opción global. Cuando ejecutes un comando de gcloud de la siguiente manera, se te solicitará que designes una región o el balanceador de cargas como global:

gcloud beta compute backend-services create service-test \
    --health-checks=hc-test \
    --project=test1 \
    --protocol=http2

Ten en cuenta lo siguiente para este servicio de backend:

- [service-test] choose a region or global:
[1] global
[2] region: [REGION_A_NAME]
[3] region: [REGION_B_NAME]
....
Please enter your numeric choice:

Para el balanceador de cargas de HTTP(S), los servicios de backend deben ser globales, así que tienes que elegir la opción 1 o emitir el comando de gcloud con la opción --global:

gcloud beta compute backend-services create service-test \
    --health-checks=hc-test \
    --project=test \
    --protocol=http2 \
    --global

Errores 502 sin motivo

Asegúrate de que la 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 de origen personalizado

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 HTTP(S) 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 se genera un código de error de HTTP(S) 502 debido a que el tráfico no puede llegar al extremo, verifica lo siguiente:

  • 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 origen personalizado, las solicitudes a él 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 origen personalizado.
  • 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 haber enviado un encabezado de host HTTP válido al backend mediante la configuración de un encabezado de solicitud definido por el usuario.
  • 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 origen personalizado 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 origen personalizados 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 origen personalizado

Asegúrate de que ocurra lo siguiente:

  • Habilitaste Cloud CDN en el servicio de backend que contiene el NEG que apunta a tu origen personalizado cuando configuraste enableCDN como verdadero.
  • Las respuestas que entrega tu origen personalizado 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

Las solicitudes fallan con un error 404

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

En general, un balanceador de cargas de HTTP(S) externo no puede detectar si el recurso sin servidores subyacente funciona como se espera. Esto significa que si tu servicio muestra errores en una región, pero la infraestructura general de Cloud Run (completamente administrada), Cloud Functions o App Engine en esa región funciona con normalidad, tu balanceador de cargas de HTTP(S) 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 (completamente administrado): 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).

Cloud Functions: 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.