Soluciona problemas de balanceadores de cargas de red de transferencia interna

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

Si no te puedes conectar al balanceador de cargas de red de transferencia interna, verifica los siguientes problemas comunes.

Verifica las reglas de firewall

  • 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 existan reglas de firewall relevantes para permitir que el tráfico llegue a las VM de backend en los puertos que usa el balanceador de cargas.
  • Si usas etiquetas de destino para las reglas de firewall, asegúrate de que las VM de backend del balanceador de cargas estén etiquetadas de forma correcta.

Para obtener información sobre cómo configurar las reglas de firewall que requiere el balanceador de cargas de red de transferencia interno, consulta Configura las reglas de firewall.

Verifica que el entorno invitado se ejecute en la VM de backend.

Si puedes conectarte a una VM de backend en buen estado, pero no puedes conectarte al balanceador de cargas, es posible que el entorno invitado (antes llamado entorno invitado de Windows o entorno invitado de Linux) en la VM no se esté ejecutando o no se pueda 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 ejecutándose en la VM de backend.
  • Asegúrate de que las reglas de firewall dentro del sistema operativo invitado de la VM de backend (iptables o firewall de Windows) no bloqueen el acceso al servidor de metadatos.

Verifica que las VM de backend acepten paquetes enviados al balanceador de cargas

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

En las VM creadas a partir de imágenes de Google Cloud, el agente invitado instala la ruta local para la dirección IP del balanceador de cargas. Las instancias de Google Kubernetes Engine basadas en Container-Optimized OS implementan esto mediante iptables en su lugar.

En una VM de backend de Linux, puedes verificar la presencia de la ruta local mediante la ejecución del siguiente comando. Reemplaza LOAD_BALANCER_IP por la dirección IP del balanceador de cargas:

sudo ip route list table local | grep LOAD_BALANCER_IP

Verifica la dirección IP del servicio y la vinculación del puerto en las VM de backend.

Los paquetes enviados a un balanceador de cargas de red de transferencia interno llegan a las VM de backend con la dirección IP de destino del balanceador de cargas. Este tipo de balanceador de cargas no es un proxy, y este es el comportamiento esperado.

El software que se ejecuta en la VM de backend debe realizar las siguientes acciones:

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

Para probar esto, conéctate a una VM de backend con SSH o RDP. Luego, realiza las siguientes pruebas con curl, telnet o una herramienta similar:

  • Para intentar acceder al servicio, comunícate con este mediante la dirección IP interna de la VM de backend, 127.0.0.1 o localhost.
  • Para intentar acceder al servicio, comunícate con este mediante la dirección IP de la regla de reenvío del balanceador de cargas.

Verifica si la VM cliente está en la misma región que el balanceador de cargas.

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

Verifica que el tráfico de verificación de estado pueda llegar a las VM de backend.

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.

También puedes verificar que la funcionalidad del balanceador de cargas esté en buen estado si consultas el estado “En buen estado” del backend.

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

Desde un cliente en 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

Reemplaza lo siguiente:

  • SERVER_IP_ADDRESS: La dirección IP de la VM de backend.
  • PORT: El puerto que configuraste para la verificación de estado. De forma predeterminada, el puerto de verificación de estado es 80.

Como alternativa, puedes usar SSH para conectar la VM de backend y ejecutar el siguiente comando:

curl localhost:PORT

Una vez más, reemplaza PORT por el puerto que configuraste para la verificación de estado.

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

netstat -npal | grep LISTEN

En el resultado, busca lo siguiente:

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

Esto no determina si el enrutamiento está configurado de forma correcta para responder a la dirección IP del balanceador de cargas. Ese es un problema independiente con un síntoma similar. Para el enrutamiento, ejecuta el comando ip route list table local y verifica que la dirección IP del balanceador de cargas aparezca en la lista, como se describe en Verifica que las VM de backend acepten paquetes enviados al balanceador de cargas.

Soluciona problemas de rendimiento

Si observas problemas de rendimiento y un aumento en la latencia, verifica los siguientes problemas comunes.

Verifica la funcionalidad del servidor

Si todos los servidores de backend responden a las verificaciones de estado, verifica que las solicitudes del cliente funcionen de forma correcta cuando se emiten directamente en el servidor. Por ejemplo, si el cliente envía solicitudes HTTP al servidor a través del balanceador de cargas y no hay respuesta, o la respuesta es mucho más lenta de lo normal, emite la misma solicitud HTTP en cada uno de los servidores de backend y observar el comportamiento.

Si alguno de los servidores de backend individuales no se comporta de forma correcta cuando se emite la solicitud desde el mismo servidor, puedes concluir que la pila de aplicaciones del servidor no funciona de forma correcta. Puedes enfocarte aún más en la solución de problemas de la aplicación. Si todos los servidores se comportan de manera correcta, el siguiente paso es observar el lado del cliente y la red.

Verifica la conectividad de red y la latencia

Si todos los servidores de backend responden a las solicitudes de forma correcta, verifica la latencia de la red. Desde una VM de cliente, emite 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 descarta paquetes. En algunos casos, las reglas de firewall podrían bloquear el tráfico de ICMP. Si es así, esta prueba no puede producir ningún resultado. Verifica con el administrador de reglas de firewall si este es el caso.

Si el comando ping muestra una latencia bastante más alta de lo normal o una pérdida de paquetes significativa, abre un caso de asistencia de Google Cloud para investigar más.

Identifica combinaciones de cliente y servidor problemáticas

Si la prueba de red ping sugiere una latencia baja y que no hay pérdida de paquetes, el siguiente paso es identificar qué combinación específica de cliente y servidor, si existe alguna, produce resultados problemáticos. Puedes hacerlo mediante la reducción de la cantidad de servidores de backend a la mitad hasta que la cantidad de servidores alcance 1 y, al mismo tiempo, reproducir el comportamiento problemático (por ejemplo, alta latencia o ninguna respuesta).

Si identificas una o más combinaciones de cliente y servidor problemáticas, realiza la captura y análisis de tráfico.

Si no se identifica una combinación problemática de cliente y servidor, ve a prueba de rendimiento.

Realiza la captura y el análisis de tráfico

Si identificas una combinación problemática específica de cliente y servidor, puedes usar la captura de paquetes para identificar la parte de la comunicación que causa el retraso o la falla. La captura de paquetes se puede realizar 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 muestra, como la que se muestra a continuación:

    curl URL

  4. Analiza el resultado de tcpdump para identificar el problema.

Realiza pruebas de rendimiento

Si no identificas combinaciones de cliente y servidor problemáticas y el rendimiento agregado de todos los clientes y servidores juntos es más bajo de lo esperado, considera las siguientes pruebas:

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

  2. Un cliente y un servidor, con balanceo de cargas.

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

  3. Un cliente y varios servidores, con balanceo de cargas.

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

  4. Varios clientes y un servidor, con balanceo de cargas.

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

  5. Varios clientes y servidores, sin balanceo de cargas.

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

Cuando se ejecuta una prueba de esfuerzo con varios clientes y servidores, los recursos de cliente o servidor (CPU, memoria, E/S) pueden convertirse en cuellos de botella y reducir los resultados agregados. Los resultados agregados degradados pueden ocurrir incluso si cada cliente y servidor se comporta de forma correcta.

Soluciona problemas de VPC compartida

Si usas la VPC compartida y no puedes crear un nuevo balanceador de cargas de red de transferencia 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.

Soluciona problemas de conmutación por error

Si configuraste la conmutación por error para un balanceador de cargas de red de transferencia 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. Google Cloud no te impide configurar la conmutación por error con grupos de instancias administrados, ya que tu implementación podría beneficiarse con 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 vaciado 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 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 la consola de Google Cloud para comprobar la cantidad de VM de backend en buen estado en cada grupo de instancias de backend. La consola de Google Cloud 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.

Soluciona problemas de balanceador de cargas como siguiente salto

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

Problemas de conectividad

  • Si no puedes hacer ping a una dirección IP en el rango de destino de una ruta cuyo siguiente salto es una regla de reenvío para un balanceador de cargas de red de transferencia interno, ten en cuenta que es posible que una ruta que usa este tipo de siguiente salto no procese el tráfico ICMP según la fecha de creación de la ruta. Si la ruta se creó antes del 15 de mayo de 2021, solo procesa el tráfico de TCP y UDP hasta el 16 de agosto de 2021. A partir del 16 de agosto de 2021, todas las rutas reenviarán de forma automática todo el tráfico de protocolo (TCP, ICMP y UDP), sin importar cuándo se creó una ruta. Si no quieres esperar hasta entonces, puedes habilitar la funcionalidad de ping ahora mediante la creación de nuevas rutas y la eliminación de las anteriores.

  • Cuando se usa un balanceador de cargas de red de transferencia interno como próximo salto para una ruta estática personalizada, todo el tráfico se entrega a las VMs 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 el puerto o los puertos configurados en la regla de reenvío interna 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.

Soluciona problemas de registro

Si configuras el registro para un balanceador de cargas de red de transferencia interno, pueden ocurrir 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 suceda con 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 realizan muestras sobre paquetes de solo encabezado, el valor en bytes es 0.

¿Qué sigue?