Soluciona problemas del balanceo de cargas TCP/UDP interno

En esta guía, se describe cómo solucionar problemas de configuración de un balanceador de cargas TCP/UDP interno de Google Cloud.

Resumen

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

  • Problemas generales de conectividad
  • Problemas de conmutación por error de backend
  • Problemas de balanceador de cargas como siguiente salto

Antes de comenzar

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

Sobre conectividad general:

Sobre conmutación por error:

Sobre siguiente salto:

Solución de problemas generales de conectividad

  • Síntoma: no puedo conectarme a mi balanceador de cargas TCP/UDP interno desde un cliente de VM en otra región.
  • Motivo: el acceso global no está habilitado.

Si no puedes conectarte a un balanceador de cargas TCP/UDP interno, verifica los siguientes problemas:

  • Asegúrate de que las reglas de firewall de entrada permitida estén configuradas para permitir las verificaciones de estado en las VM de backend.
  • Asegúrate de que las reglas de firewall de entrada permitida habiliten el tráfico de los clientes a las VM de backend.
  • Asegúrate de que el cliente que se conecta al balanceador de cargas esté en la misma región que el balanceador de cargas. Si el cliente está en otra región, asegúrate de que el acceso global esté habilitado.
  • 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.

  • Síntoma: no puedo conectarme a mi servicio a través del balanceador de cargas TCP/UDP interno, pero puedo conectarme directamente a una VM de backend.

  • Motivo: el entorno invitado no está en ejecución o no se puede comunicar con el servidor de metadatos (metadata.google.internal, 169.254.169.254).

Comprueba lo siguiente:

  • Asegúrate de que el Entorno invitado esté instalado y en ejecución en la VM de backend.
  • Asegúrate de que las reglas de firewall dentro del sistema operativo invitado de la VM de backend (iptables, firewall de Windows) no bloqueen el acceso al servidor de metadatos.
  • Asegúrate de que el servicio en la VM de backend esté escuchando la dirección IP de la regla de reenvío del balanceador de cargas.

Solución de problemas de VPC compartida

Si usas la VPC compartida y no puedes crear un nuevo balanceador de cargas TCP/UDP 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 la restricción constraints/compute.restrictSharedVpcSubnetworks.

Solución de problemas de conmutación por error

Si configuraste la conmutación por error para un balanceador de cargas TCP/UDP interno, en las siguientes secciones se describen los problemas que pueden ocurrir.

Conectividad

  • Asegúrate de haber designado al menos un backend de conmutación por error.
  • Comprueba la configuración de la política de conmutación por error:
    • Índice de conmutación por error
    • Abandono del tráfico cuando todas las VM de backend están en mal estado
    • Inhabilitación del desvío de conexiones en la conmutación por error

Problemas con grupos de instancias administrados y conmutación por error

  • Síntoma: el grupo activo se cambia de un lado a otro (oscilación) entre el backend principal y el de conmutación por error.
  • Posible motivo: el uso de grupos de instancias administrados con ajuste de escala automático y conmutación por error puede provocar que el grupo activo realice conmutaciones por error y por recuperación de forma repetida entre el backend principal y el de conmutación por error. GCP no te impide configurar la conmutación por error con grupos de instancias administrados, ya que la implementación podría beneficiarse de esta configuración.

Inhabilita el desvío de conexiones para grupos de conmutación por error

La inhabilitación del desvío de conexiones solo funciona si el servicio de backend está configurado con el protocolo TCP.

El siguiente mensaje de error aparece si creas un servicio de backend con UDP mientras el drenaje de la conexión está inhabilitado:

gcloud compute backend-services create my-failover-bs
  --global-health-checks \
  --load-balancing-scheme internal
  --health-checks my-tcp-health-check
  --region us-central1
  --no-connection-drain-on-failover
  --drop-traffic-if-unhealthy
  --failover-ratio 0.5
  --protocol UDP
ERROR: (gcloud.compute.backend-services.create) Invalid value for
[--protocol]: can only specify --connection-drain-on-failover if the protocol is
TCP.

El tráfico se envía a VM de backend inesperadas

Primero, verifica lo siguiente: si la VM del cliente también es una VM de backend del balanceador de cargas, se espera que la propia VM de backend responda siempre a las conexiones enviadas a la dirección IP de la regla de reenvío del balanceador de cargas. Para obtener más información, consulta la página Prueba conexiones de un solo cliente y Envía solicitudes desde VM con balanceo de cargas.

Si la VM del cliente no es una VM de backend del balanceador de cargas, haz lo siguiente:

  • Para solicitudes de un solo cliente, consulta la página acerca de cómo probar conexiones de un solo cliente a fin de comprender las limitaciones de este método.

  • Asegúrate de haber configurado las reglas de firewall de entrada permitida para que admitan verificaciones de estado.

  • Para una configuración de conmutación por error, asegúrate de comprender cómo funciona la membresía en el Grupo activo y cuándo Google Cloud realiza la Conmutación por error y por recuperación. Inspecciona la configuración del balanceador de cargas:

    • Usa Cloud Console para comprobar la cantidad de VM de backend en buen estado en cada grupo de instancias de backend. Cloud Console también te muestra qué VM están en el grupo activo.

    • Asegúrate de que el índice de conmutación por error del balanceador de cargas esté configurado de forma correcta. Por ejemplo, si tienes diez VM principales y un índice de conmutación por error establecido en 0.2, Google Cloud realiza una conmutación por error cuando hay menos de dos (10 × 0.2 = 2) VM principales en buen estado. Un índice de conmutación por error de 0.0 tiene un significado especial: Google Cloud realiza una conmutación por error cuando ninguna VM principal está en buen estado.

Las conexiones existentes se finalizan durante la conmutación por error o por recuperación

Edita la política de conmutación por error de tu servicio de backend. Asegúrate de que el desvío de conexiones en conmutación por error esté habilitado.

Solución de problemas del balanceador de cargas como próximo salto

Cuando configuras un balanceador de cargas TCP/UDP interno para que sea el próximo salto de una ruta estática personalizada, pueden ocurrir los siguientes problemas:

Conectividad

  • Si no puedes hacer ping a tu backend, ten en cuenta que una ruta con el balanceador de cargas TCP/UDP interno configurado como próximo salto solo es compatible con tráfico TCP y UDP. El balanceador de cargas ignora otros paquetes de protocolos, como ICMP. Para obtener más información, consulta TCP, UDP y otros tráficos de protocolos.

  • Cuando se usa un balanceador de cargas TCP/UDP interno como próximo salto para una ruta estática personalizada, todo el tráfico de TCP y UDP se entrega a las VM de backend en buen estado del balanceador de cargas, sin importar el protocolo configurado en el servicio de backend interno del balanceador de cargas ni los puertos configurados en la regla de reenvío interno del balanceador de cargas.

  • Asegúrate de haber creado la entrada para permitir reglas de firewall que identifiquen de forma correcta las fuentes de tráfico que deben entregarse a las VM de backend a través del próximo salto de la ruta estática personalizada. Los paquetes que llegan a las VM de backend conservan las direcciones IP de origen, incluso cuando se entregan mediante una ruta estática personalizada.

Valor no válido para el rango de destino

El rango de destino de una ruta estática personalizada no puede ser más específico que cualquier ruta de subred en tu red de VPC. Si recibes el siguiente mensaje de error cuando creas una ruta estática personalizada, haz lo siguiente:

Invalid value for field 'resource.destRange': [ROUTE_DESTINATION].
[ROUTE_DESTINATION] hides the address space of the network .... Cannot change
the routing of packets destined for the network.
  • No puedes crear una ruta estática personalizada con un destino que coincida de manera exacta con una ruta de subred ni que sea más específico (con una máscara más larga) que esta. Consulta la aplicabilidad y el orden para obtener más información.

  • Si los paquetes se dirigen a un destino inesperado, quita otras rutas en tu red de VPC con destinos más específicos. Revisa el Orden de enrutamiento para comprender la selección de rutas de Google Cloud.

Las etiquetas de red no son compatibles

No puedes asignar una etiqueta de red a una ruta estática personalizada cuando el próximo salto es un balanceador de cargas TCP/UDP interno. Por ejemplo, el siguiente comando de gcloud produce el mensaje de error que se encuentra a continuación:

$ gcloud compute routes create example-route \
--destination-range=0.0.0.0/0 \
--next-hop-ilb=internal-lb-forwarding-rule \
--tags='my_tag'

ERROR: (gcloud.compute.routes.create) Could not fetch resource:
 - Invalid value for field 'resource.tags': ''. Tag is not supported for routes
 with next hop ilb.

Qué sigue