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 Platform.

Descripción general

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

  • Problemas generales de conectividad
  • Problemas de conmutación por error de backend (Beta)
  • Problemas de balanceador de cargas como próximo salto (Beta)

Antes de comenzar

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

Sobre conectividad general:

Sobre conmutación por error:

Sobre próximo 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: los balanceadores de cargas TCP/UDP internos son regionales. Solo son accesibles desde su propia región.

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.

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 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:
    • Proporción 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 beta compute backend-services create my-failover-bs
  --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.beta.compute.backend-services.create) Invalid value for
[--protocol]: can only specify --connection-drain-on-failover if the protocol is
TCP.

Versión de API para backends de conmutación por error

En la actualidad, las opciones de conmutación por error solo están disponibles en la API Beta. Si la creación de un servicio de backend tiene errores que indican que failover options no es un campo válido, asegúrate de haber creado el servicio de backend con la API correcta (gcloud beta compute backend-services...).

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 sobre cómo probar conexiones de un solo cliente y sobre cómo enviar 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 GCP realiza la conmutación por error y por recuperación. Inspecciona la configuración del balanceador de cargas:

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

    • Asegúrate de que la proporción de conmutación por error del balanceador de cargas esté configurada de forma correcta. Por ejemplo, si tienes diez VM principales y una proporción de conmutación por error configurada como 0.2, esto significa que GCP realiza una conmutación por error cuando menos de dos (10 × 0.2 = 2) VM principales están en buen estado. Una proporción de conmutación por error de 0.0 tiene un significado especial: GCP 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. Se abandonan otros paquetes de protocolo, como ICMP.

  • 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 ruta de GCP.

Versión de API para el próximo salto

En la actualidad, el balanceador de cargas TCP/UDP interno como próximo salto (--next-hop-ilb) solo está disponible en la API Beta. Si la creación de una ruta estática falla, asegúrate de haber creado la ruta mediante la API correcta (gcloud beta compute routes create...).

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 ve a continuación:

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

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

Próximos pasos

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...