Solucionar problemas de balanceadores de carga de red de paso a través internos

En esta guía se describe cómo solucionar problemas de configuración de un balanceador de carga de red interno de transferencia directa. Google Cloud 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

Si no puedes conectarte a tu balanceador de carga de red de paso a través interno, comprueba los siguientes problemas habituales.

Verificar las reglas de cortafuegos

  • Asegúrate de que se hayan definido reglas de cortafuegos de entrada para permitir que se realicen comprobaciones del estado en las VMs de backend.
  • Asegúrate de que las reglas de cortafuegos de entrada permiten que los clientes envíen tráfico a las VMs de backend.
  • Asegúrate de que existen reglas de cortafuegos relevantes para permitir que el tráfico llegue a las VMs de backend en los puertos que usa el balanceador de carga.
  • Si usas etiquetas de destino para las reglas de firewall, asegúrate de que las VMs backend del balanceador de carga estén etiquetadas correctamente.

Para saber cómo configurar las reglas de cortafuegos que requiere tu balanceador de carga de red interno de tipo pasarela, consulta el artículo Configurar reglas de cortafuegos.

Verifica que el entorno de invitado se esté ejecutando en la VM backend

Si puedes conectarte a una VM de backend en buen estado, pero no al balanceador de carga, puede que el entorno de invitado (antes, el entorno de invitado de Windows o el entorno de invitado de Linux) de la VM no se esté ejecutando o no pueda comunicarse 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 del cortafuegos del sistema operativo invitado de la VM de backend (iptables o Firewall de Windows) no bloqueen el acceso al servidor de metadatos.

Verificar que las VMs de backend aceptan los paquetes enviados al balanceador de carga

Cada VM de backend debe configurarse para aceptar los paquetes enviados al balanceador de carga. Es decir, el destino de los paquetes enviados a las VMs backend es la dirección IP del balanceador de carga. En la mayoría de los casos, esto se hace con una ruta local.

En las VMs creadas a partir de Google Cloud imágenes, el agente invitado instala la ruta local de la dirección IP del balanceador de carga. Las instancias de Google Kubernetes Engine basadas en Container-Optimized OS implementan esta función mediante iptables.

En una VM backend de Linux, puedes verificar la presencia de la ruta local ejecutando el siguiente comando. Sustituye LOAD_BALANCER_IP por la dirección IP del balanceador de carga:

sudo ip route list table local | grep LOAD_BALANCER_IP

Verificar la dirección IP del servicio y la vinculación de puertos en las VMs de backend

Los paquetes enviados a un balanceador de carga de red de paso a través interno llegan a las VMs de backend con la dirección IP de destino del propio balanceador de carga. Este tipo de balanceador de carga no es un proxy, y este es el comportamiento esperado.

El software que se ejecuta en la VM de backend debe hacer lo siguiente:

  • Escucha en la dirección IP del balanceador de carga o en cualquier dirección IP (0.0.0.0 o ::).
  • Escuchando (vinculado a) un puerto incluido en la regla de reenvío del balanceador de carga

Para probarlo, conéctate a una VM backend mediante SSH o RDP. A continuación, realiza las siguientes pruebas con curl, telnet o una herramienta similar:

  • Intenta acceder al servicio poniéndote en contacto con él mediante la dirección IP interna de la propia VM de backend, 127.0.0.1, o localhost.
  • Intenta acceder al servicio poniéndote en contacto con él mediante la dirección IP de la regla de reenvío del balanceador de carga.

Comprobar si la VM cliente está en la misma región que el balanceador de carga

Si el cliente que se conecta al balanceador de carga se encuentra en otra región, asegúrate de que el acceso global esté habilitado.

Verificar que el tráfico de comprobación de estado puede llegar a las VMs de backend

Para verificar que el tráfico de comprobación del estado llega a tus VMs de backend, habilita el registro de comprobación del estado y busca entradas de registro correctas.

También puede comprobar que el balanceador de carga funciona correctamente consultando el estado "Correcto" del backend.

Si no hay instancias en buen estado en el backend, asegúrate de que la comprobación del estado adecuada esté configurada y de que cada VM del backend esté escuchando en los puertos de comprobación del estado configurados.

Desde un cliente de la misma red de VPC, ejecuta el siguiente comando para verificar que la VM de backend está escuchando en un puerto TCP específico:

telnet SERVER_IP_ADDRESS PORT

Haz los cambios siguientes:

  • SERVER_IP_ADDRESS: dirección IP de la VM de backend.
  • PORT: el puerto que has configurado para la comprobación del estado. De forma predeterminada, el puerto de comprobación del estado es 80.

También puedes usar SSH para conectar la VM backend y ejecutar el siguiente comando:

curl localhost:PORT

De nuevo, sustituye PORT por el puerto que has configurado para tu comprobación de estado.

Otra forma de realizar esta prueba es ejecutar el siguiente comando:

netstat -npal | grep LISTEN

En el resultado, comprueba lo siguiente:

  • <var>LB_IP_ADDRESS</var>:<var>PORT</var>
  • 0.0.0.0:<var>PORT</var>
  • :::<var>PORT</var>

No determina si el enrutamiento está configurado correctamente para responder a la dirección IP del balanceador de carga. Se trata de un problema distinto con un síntoma similar. Para el enrutamiento, ejecuta el comando ip route list table local y comprueba que la dirección IP del balanceador de carga aparece en la lista, tal como se describe en Verificar que las VMs de backend aceptan los paquetes enviados al balanceador de carga.

Solucionar problemas de rendimiento

Si detecta problemas de rendimiento y un aumento de la latencia, compruebe si se dan los siguientes problemas habituales.

Verificar la funcionalidad del servidor

Si todos los servidores backend responden a las comprobaciones de estado, compruebe que las solicitudes del cliente funcionan correctamente cuando se emiten directamente en el servidor. Por ejemplo, si el cliente envía solicitudes HTTP al servidor a través del balanceador de carga y no hay respuesta o la respuesta es considerablemente más lenta de lo normal, envía la misma solicitud HTTP a cada uno de los servidores backend y observa el comportamiento.

Si alguno de los servidores backend individuales no se comporta correctamente cuando se emite la solicitud desde el propio servidor, puedes concluir que la pila de aplicaciones del servidor no funciona correctamente. Puedes centrarte en solucionar problemas de la aplicación. Si todos los servidores funcionan correctamente, el siguiente paso es analizar el lado del cliente y la red.

Verificar la conectividad y la latencia de la red

Si todos los servidores backend responden correctamente a las solicitudes, comprueba la latencia de la red. Desde una VM cliente, envía un comando ping constante a cada uno de los servidores de la siguiente manera:

ping SERVER_IP_ADDRESS

Esta prueba muestra la latencia de red integrada y si la red está descartando paquetes. En algunos casos, las reglas de cortafuegos pueden bloquear el tráfico ICMP. Si es así, esta prueba no producirá ningún resultado. Pregunta al administrador de las reglas de tu cortafuegos si es así.

Si el comando ping muestra una latencia significativamente mayor de lo normal o una pérdida de paquetes significativa, abre un Google Cloud caso de asistencia para investigar el problema.

Identificar combinaciones problemáticas de cliente y servidor

Si la prueba de red ping sugiere una latencia baja y no se ha perdido ningún paquete, el siguiente paso es identificar qué combinación específica de cliente y servidor, si la hay, produce resultados problemáticos. Para ello, reduce a la mitad el número de servidores backend hasta que llegue a 1, mientras reproduces simultáneamente el comportamiento problemático (por ejemplo, una latencia alta o la ausencia de respuestas).

Si identificas una o varias combinaciones de cliente-servidor problemáticas, realiza una captura y un análisis del tráfico.

Si no se identifica ninguna combinación problemática de cliente y servidor, vaya a la sección sobre pruebas de rendimiento.

Realizar capturas y análisis de tráfico

Si identificas una combinación problemática específica de cliente-servidor, puedes usar la captura de paquetes para determinar qué parte de la comunicación está provocando el retraso o la interrupción. La captura de paquetes se puede hacer con tcpdump de la siguiente manera:

  1. Instala tcpdump en el servidor.
  2. Inicia la captura de tcpdump en el servidor.

  3. Desde un cliente, emite una solicitud de ejemplo, como la siguiente:

    curl URL

  4. Analiza la salida de tcpdump para identificar el problema.

Hacer pruebas de rendimiento

Si no identifica ninguna combinación de cliente y servidor problemática y el rendimiento agregado de todos los clientes y servidores es inferior al esperado, considere la posibilidad de realizar las siguientes pruebas:

  1. Un cliente y un servidor, sin balanceo de carga.

  2. Un cliente y un servidor con balanceo de carga.

    Resultado: la combinación de los resultados de las pruebas [1] y [2] identifica si el balanceador de carga está causando el problema.

  3. Un cliente y varios servidores con balanceo de carga.

    Resultado: identifica el límite de rendimiento de un cliente.

  4. Varios clientes y un servidor con balanceo de carga.

    Resultado: identifica el límite de rendimiento de un servidor.

  5. Varios clientes y varios servidores, sin balanceo de carga.

    Resultado: identifica el límite de rendimiento de la red.

Al realizar una prueba de carga con varios clientes y servidores, los recursos de los clientes o servidores (CPU, memoria, E/S) pueden convertirse en cuellos de botella y reducir los resultados agregados. Los resultados agregados degradados pueden producirse incluso si cada cliente y servidor se comporta correctamente.

Solucionar problemas de VPC compartida

Si utilizas una VPC compartida y no puedes crear un balanceador de carga de red interno de tipo pasarela en una subred concreta, puede que el problema se deba a una política de la organización. En la política de la organización, añade la subred a la lista de subredes permitidas o ponte en contacto con el administrador de tu organización. Para obtener más información, consulta la restricción constraints/compute.restrictSharedVpcSubnetworks.

Solucionar problemas de conmutación por error

Si has configurado la conmutación por error para un balanceador de carga de red interno de tipo pasarela, en las siguientes secciones se describen los problemas que pueden producirse.

Conectividad

  • Asegúrate de haber designado al menos un backend de conmutación por error.
  • Verifica la configuración de tu política de conmutación por error:
    • Índice de conmutación por error
    • Eliminar el tráfico cuando todas las VMs de backend estén en mal estado
    • Inhabilitar la purga de conexiones al producirse una conmutación por error

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

  • Síntoma: el grupo activo cambia constantemente entre los back-ends principal y de failover.
  • Posible motivo: Si se usan grupos de instancias gestionados con autoescalado y conmutación por error, es posible que la conmutación por error y la conmutación por recuperación de la agrupación activa se produzcan repetidamente entre los back-ends principal y de conmutación por error. Google Cloud no impide que configures la conmutación por error con grupos de instancias gestionados, ya que tu implementación puede beneficiarse de esta configuración.

Inhabilitar la restricción de desviación de conexiones para grupos de conmutación por error

La inhabilitación de la purga de conexión solo funciona si el servicio de backend se ha configurado con el protocolo TCP.

Aparecerá el siguiente mensaje de error si creas un servicio backend con UDP mientras el drenaje de conexiones 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 VMs de backend inesperadas

Primero, comprueba lo siguiente: si la VM cliente también es una VM de backend del balanceador de carga, es normal que la VM de backend responda siempre a las conexiones enviadas a la dirección IP de la regla de reenvío del balanceador de carga. Para obtener más información, consulta Probar las conexiones de un solo cliente y Enviar solicitudes desde VMs con balanceo de carga.

Si la VM cliente no es una VM de backend del balanceador de carga:

  • En el caso de las solicitudes de un solo cliente, consulta el artículo sobre pruebas de conexiones de un solo cliente para conocer las limitaciones de este método.

  • Asegúrate de que has configurado reglas de cortafuegos de entrada para permitir las comprobaciones de estado.

  • En una configuración de conmutación por error, asegúrate de que sabes cómo funciona la pertenencia al grupo activo y cuándoGoogle Cloud realiza la conmutación por error y la conmutación por recuperación. Inspecciona la configuración del balanceador de carga:

    • Usa la Google Cloud consola para comprobar el número de VMs de backend en buen estado de cada grupo de instancias de backend. La Google Cloud consola también muestra qué máquinas virtuales están en el grupo activo.

    • Asegúrate de que la proporción de conmutación por error del balanceador de carga esté configurada correctamente. Por ejemplo, si tienes diez VMs principales y el índice de conmutación por error es 0.2, significa que Google Cloud realiza una conmutación por error cuando menos de dos (10 × 0.2 = 2) VMs principales están en buen estado. El índice de conmutación por error 0.0 tiene un significado especial: Google Cloud realiza una conmutación por error cuando ninguna VM principal está en buen estado.

Las conexiones se terminan durante la conmutación por error o la restauración

Edita la política de conmutación por error de tu servicio de backend. Comprueba que la opción de desviación de conexiones al producirse una conmutación por error esté habilitada.

Solucionar problemas de balanceadores de carga como siguientes saltos

Si configuras un balanceador de carga de red de paso a través interno como salto siguiente de una ruta estática personalizada, pueden producirse los siguientes problemas:

Problemas de conectividad

  • Si no puedes hacer ping a una dirección IP del intervalo de destino de una ruta cuyo siguiente salto es una regla de reenvío de un balanceador de carga de red interno de tipo pasarela, ten en cuenta que es posible que una ruta que use este tipo de siguiente salto no procese el tráfico ICMP en función de cuándo se haya creado la ruta. Si la ruta se creó antes del 15 de mayo del 2021, solo procesará el tráfico TCP y UDP hasta el 16 de agosto del 2021. A partir del 16 de agosto del 2021, todas las rutas reenviarán automáticamente todo el tráfico de protocolos (TCP, UDP e ICMP), independientemente de cuándo se hayan creado. Si no quieres esperar hasta entonces, puedes habilitar la función de ping ahora creando nuevas rutas y eliminando las antiguas.

  • Cuando se usa un balanceador de carga de red de paso a través interno como siguiente salto de una ruta estática personalizada, todo el tráfico se envía a las VMs de backend en buen estado del balanceador de carga, independientemente del protocolo configurado para el servicio de backend interno del balanceador de carga y del puerto o los puertos configurados en la regla de reenvío interna del balanceador de carga.

  • Asegúrate de haber creado reglas de cortafuegos que permitan el tráfico de entrada y que identifiquen correctamente las fuentes de tráfico que se deben enviar a las VMs de backend a través del siguiente salto de la ruta estática personalizada. Los paquetes que llegan a las VMs de backend conservan sus direcciones IP de origen, incluso cuando se entregan a través de una ruta estática personalizada.

Valor no válido para el intervalo de destino

El intervalo de destino de una ruta estática personalizada no puede ser más específico que ninguna ruta de subred de tu red de VPC. Si recibes el siguiente mensaje de error al crear una ruta estática personalizada:

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 exactamente o sea más específico (con una máscara más larga) que una ruta de subred. Consulta la aplicabilidad y el orden para obtener más información.

  • Si los paquetes van a un destino inesperado, elimina otras rutas de tu red VPC con destinos más específicos. Consulta el orden de enrutamiento para entender la selección de rutas. Google Cloud

Solucionar problemas de registro

Si configura el registro de un balanceador de carga de red de paso a través interno, pueden producirse los siguientes problemas:

  • Es posible que falten mediciones de RTT, como los valores de bytes, en algunos de los registros si no se muestrean suficientes paquetes para capturar el RTT. Es más probable que esto ocurra en conexiones de bajo volumen.
  • Los valores de RTT solo están disponibles para los flujos TCP.
  • Algunos paquetes se envían sin carga útil. Si se muestrean paquetes que solo contienen encabezados, el valor de bytes es 0.

Siguientes pasos