Descripción general del balanceo de cargas de redes TCP/UDP externo basado en servicios de backend

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

El balanceo de cargas de red TCP/UDP externo de Google Cloud (a partir de ahora, balanceo de cargas de red) es un balanceador de cargas regional de transferencia. Un balanceador de cargas de red distribuye el tráfico externo entre instancias de máquinas virtuales (VM) en la misma región.

Puedes configurar un balanceador de cargas de red para el tráfico de TCP, UDP, ESP, GRE, ICMP y ICMPv6.

Un balanceador de cargas de red puede recibir tráfico de los siguientes servidores:

  • Cualquier cliente en Internet
  • VM de Google Cloud con IP externas
  • VM de Google Cloud que tienen acceso a Internet a través de Cloud NAT o NAT basada en la instancia

El balanceo de cargas de red tiene las siguientes características:

  • Es un servicio administrado.
  • El balanceo de cargas de red se implementa mediante las herramientas de redes virtuales de Andromeda y Google Maglev.
  • Los balanceadores de cargas de red no son proxies.
    • Las VM de backend reciben paquetes con balanceo de cargas, direcciones IP de origen y destino, y el protocolo del paquete y, si el protocolo se basa en puertos, los puertos de origen y de destino sin cambios.
    • Las VM de backend finalizan las conexiones de balanceo de cargas.
    • Las respuestas de las VM de backend van directo a los clientes, no pasan a través del balanceador de cargas. El término del sector para esto es retorno directo del servidor (DSR).

Los balanceadores de cargas de red basados en servicios de backend tienen las siguientes características:

  • Backends de grupos de instancias administrados. Los balanceadores de cargas de red basados en servicios de backend admiten el uso de grupos de instancias administrados (MIG) como backends. Los grupos de instancias administrados automatizan ciertos aspectos de la administración de backend y proporcionan una mejor escalabilidad y confiabilidad en comparación con los grupos de instancias no administrados.
  • Compatibilidad con la conectividad IPv6. Los balanceadores de cargas de red basados en servicios de backend pueden controlar tráfico IPv4 e IPv6.
  • Control detallado de la distribución del tráfico. La configuración de un servicio de backend contiene un conjunto de valores, como políticas de verificaciones de estado, afinidad de sesión, seguimiento de conexiones, vaciado de conexiones, y conmutación por error. La mayoría de estas opciones de configuración tienen valores predeterminados que te permiten comenzar con rapidez.
  • Verificaciones de estado. Los balanceadores de cargas de red basados en servicios de backend usan verificaciones de estado que coinciden con el tipo de tráfico (TCP, SSL, HTTP, HTTPS o HTTP/2) que distribuyen.
  • Integración en Google Cloud Armor. Google Cloud Armor admite la protección avanzada contra DSD de las redes para balanceadores de cargas de red. Para obtener más información, consulta Configura la protección contra DSD de red avanzada.

Balanceo de cargas para aplicaciones de GKE

Si compilas aplicaciones en GKE, te recomendamos que uses el controlador de servicios de GKE integrado, que implementa balanceadores de cargas de Google Cloud en nombre de los usuarios de GKE. Esto es lo mismo que la arquitectura de balanceo de cargas independiente que se describe en esta página, excepto que su ciclo de vida está completamente automatizado y controlado por GKE.

Documentación de GKE relacionada:

Arquitectura

En el siguiente diagrama, se ilustran los componentes de un balanceador de cargas de red:

Balanceador de cargas de red TCP/UDP externo con servicio de backend regional
Balanceo de cargas de red con servicio de backend regional

El balanceador de cargas está compuesto por varios componentes de configuración. Un solo balanceador de cargas puede tener lo siguiente:

  • Una o más direcciones IP externas regionales
  • Una o más reglas de reenvío externas regionales
  • Un servicio de backend externo regional
  • Uno o más grupos de instancias de backend
  • Verificación de estado asociada al servicio de backend

Además, debes crear reglas de firewall que permitan que el tráfico del balanceo de cargas y los sondeos de verificación de estado lleguen a las VM de backend.

Dirección IP

Un balanceador de cargas de red requiere al menos una regla de reenvío. La regla de reenvío hace referencia a una dirección IP externa regional a la que se puede acceder en cualquier lugar de Internet.

  • Para el tráfico IPv4, la regla de reenvío hace referencia a una sola dirección IPv4 externa regional. Las direcciones IPv4 externas regionales provienen de un grupo único para cada región de Google Cloud. La dirección IP puede ser una dirección estática reservada o una dirección efímera.
  • Para el tráfico IPv6, la regla de reenvío hace referencia a un rango de direcciones IP /96 del rango de direcciones IPv6 externo de la subred /64. La subred debe ser de pila doble con ipv6-access-type configurado como EXTERNAL. Las direcciones IPv6 externas solo están disponibles en el nivel Premium. La reserva de una dirección IPv6 externa regional solo es compatible con las instancias, por lo que debes usar una dirección IPv6 efímera para la regla de reenvío.

Usa una dirección IP reservada para la regla de reenvío si necesitas mantener la dirección asociada a tu proyecto para reutilizarla después de borrar una regla de reenvío o si necesitas que varias reglas de reenvío hagan referencia a la misma dirección IP.

El balanceo de cargas de red admite los niveles Estándar y Premium para direcciones IPv4 externas regionales. La dirección IP y la regla de reenvío deben usar el mismo nivel de red. Las direcciones IPv6 externas regionales solo están disponibles en el nivel Premium.

Regla de reenvío

Una regla de reenvío externa regional especifica el protocolo y los puertos en los que el balanceador de cargas acepta tráfico. Debido a que los balanceadores de cargas de red no son proxies, pasan el tráfico a los backends en el mismo protocolo y los mismos puertos, si el paquete lleva información del puerto. La regla de reenvío y la dirección IP forman el frontend del balanceador de cargas.

El balanceador de cargas conserva las direcciones IP de origen de los paquetes entrantes. La dirección IP de destino para los paquetes entrantes es una dirección IP asociada con la regla de reenvío del balanceador de cargas.

El tráfico entrante se hace coincidir con una regla de reenvío, que es una combinación de una dirección IP en particular (una dirección IPv4 o un rango de direcciones IPv6), un protocolo y, si el protocolo se basa en puertos, uno de los puertos, un rango de puertos o todos los puertos. Luego, la regla de reenvío dirige el tráfico al servicio de backend del balanceador de cargas.

  • Si la regla de reenvío hace referencia a una dirección IPv4, la regla de reenvío no está asociada con ninguna subred. Es decir, su dirección IP proviene de fuera de cualquier rango de subred de Google Cloud.

  • Si la regla de reenvío hace referencia a una dirección IPv6, la regla de reenvío debe estar asociada con una subred, y esa subred debe ser (a) de pila doble y (b) tener --ipv6-access-type establecido como EXTERNAL.

Un balanceador de cargas de red requiere al menos una regla de reenvío. Las reglas de reenvío se pueden configurar para dirigir el tráfico que proviene de un rango específico de direcciones IP de origen a un servicio de backend (o instancia de destino) específico. Para obtener detalles, consulta Direccionamiento del tráfico. Puedes definir varias reglas de reenvío para el mismo balanceador de cargas como se describe en Múltiples reglas de reenvío.

Si deseas que el balanceador de cargas controle el tráfico IPv4 e IPv6, crea dos reglas de reenvío: una para el tráfico IPv4 que apunte a los backends de IPv4 (o de pila doble) y una para el tráfico de IPv6 que apunte solo a backends de pila doble. Es posible hacer que una regla de reenvío de IPv4 y una de IPv6 hagan referencia al mismo servicio de backend, pero el servicio de backend debe hacer referencia a los backends de pila doble.

Protocolos de reglas de reenvío

El balanceo de cargas de red admite las siguientes opciones de protocolo para cada regla de reenvío: TCP, UDP y L3_DEFAULT.

Usa las opciones TCP y UDP para configurar el balanceo de cargas de TCP o UDP. La opción del protocolo L3_DEFAULT permite que un balanceador de cargas de red balancee las cargas de tráfico de TCP, UDP, ESP, GRE, ICMP y ICMPv6.

Además de admitir protocolos que no sean TCP ni UDP, L3_DEFAULT permite que una sola regla de reenvío entregue varios protocolos. Por ejemplo, los servicios IPSec suelen controlar una combinación de tráfico IKE y NAT-T basado en ESP y UDP. La opción L3_DEFAULT permite que se configure una sola regla de reenvío para procesar todos esos protocolos.

Las reglas de reenvío que usan los protocolos TCP o UDP pueden hacer referencia a un servicio de backend con el mismo protocolo que la regla de reenvío o un servicio de backend cuyo protocolo es UNSPECIFIED. Las reglas de reenvío L3_DEFAULT solo pueden hacer referencia a un servicio de backend con el protocolo UNSPECIFIED.

Si usas el protocolo L3_DEFAULT, debes configurar la regla de reenvío para aceptar tráfico en todos los puertos. Para configurar todos los puertos, configura --ports=ALL mediante Google Cloud CLI o configura allPorts como True mediante la API.

En la siguiente tabla, se resume cómo usar esta configuración para diferentes protocolos.

Tráfico con balanceo de cargas Protocolo de regla de reenvío Protocolo de servicio de backend
TCP TCP TCP o UNSPECIFIED
L3_DEFAULT UNSPECIFIED
UDP UDP UDP o UNSPECIFIED
L3_DEFAULT UNSPECIFIED
ESP, GRE,
ICMP/ICMPv6 (solo solicitudes de eco)
L3_DEFAULT UNSPECIFIED

Varias reglas de reenvío

Puedes configurar varias reglas de reenvío externas regionales para el mismo balanceador de cargas de red. Cada regla de reenvío puede tener una dirección IP externa regional diferente, o múltiples reglas de reenvío pueden tener la misma dirección IP externa regional.

La configuración de múltiples reglas de reenvío externas regionales puede ser útil para estos casos prácticos:

  • Si debes configurar más de una dirección IP externa para el mismo servicio de backend.
  • Debes configurar diferentes protocolos o puertos, o rangos de puertos no superpuestos para la misma dirección IP externa.
  • Debes dirigir el tráfico de ciertas direcciones IP de origen a backends de balanceadores de cargas específicos.

Google Cloud requiere que los paquetes entrantes no coincidan con más de una regla de reenvío. Excepto por las reglas de reenvío de dirección, que se analizan en la siguiente sección, dos o más reglas de reenvío que usan la misma dirección IP externa regional deben tener combinaciones de protocolo y puerto únicas de acuerdo con estas restricciones:

  • Una regla de reenvío configurada para todos los puertos de un protocolo evita que se creen otras reglas de reenvío mediante el mismo protocolo y la misma dirección IP. Las reglas de reenvío que usan los protocolos TCP o UDP se pueden configurar para usar todos los puertos, o bien se pueden configurar para puertos específicos. Por ejemplo, si creas una regla de reenvío mediante la dirección IP 198.51.100.1 , el protocol TCP y todos los puertos, no puedes crear ninguna otra regla de reenvío mediante la dirección IP 198.51.100.1 y el protocolo TCP. Puedes crear dos reglas de reenvío, ambas con la dirección IP 198.51.100.1 y el protocolo TCP, si cada una tiene puertos únicos o rangos de puertos no superpuestos. Por ejemplo, puedes crear dos reglas de reenvío mediante la dirección IP 198.51.100.1 y el protocolo TCP, en el que los puertos de una regla de reenvío son 80,443 y el otro usa el rango de puertos 81-442.
  • Solo se puede crear una regla de reenvío L3_DEFAULT por dirección IP. Esto se debe a que el protocolo L3_DEFAULT usa todos los puertos por definición. En este contexto, el término todos los puertos incluye protocolos sin información de puerto.
  • Una única regla de reenvío L3_DEFAULT puede coexistir con otras reglas de reenvío que usan protocolos específicos (TCP o UDP). La regla de reenvío L3_DEFAULT se puede usar como último recurso cuando se aplican reglas de reenvío con la misma dirección IP, pero existen protocolos más específicos. Una regla de reenvío L3_DEFAULT procesa los paquetes que se envían a su dirección IP de destino solo si la dirección IP, el protocolo y el puerto de destino del paquete no coinciden con una regla de reenvío específica del protocolo.

    A modo de ejemplo, considera estas dos situaciones. En ambas situaciones, las reglas de reenvío usan la misma dirección IP 198.51.100.1.

    • Situación 1. La primera regla de reenvío usa el protocolo L3_DEFAULT. La segunda regla de reenvío usa el protocolo TCP y todos los puertos. Los paquetes de TCP enviados a cualquier puerto de destino de 198.51.100.1 se procesan mediante la segunda regla de reenvío. La primera regla de reenvío procesa los paquetes que usan diferentes protocolos.
    • Situación 2. La primera regla de reenvío usa el protocolo L3_DEFAULT. La segunda regla de reenvío usa el protocolo TCP y el puerto 8080. La segunda regla de reenvío procesa los paquetes de TCP enviados a 198.51.100.1:8080. Todos los demás paquetes, incluidos los paquetes de TCP enviados a diferentes puertos de destino, se procesan mediante la primera regla de reenvío.

Selección de la regla de reenvío

Google Cloud selecciona una o cero reglas de reenvío para procesar un paquete entrante mediante este proceso de eliminación, a partir del conjunto de opciones de reglas de reenvío que coinciden con la dirección IP de destino del paquete:

  • Elimina las reglas de reenvío cuyo protocolo no coincide con el protocolo del paquete, excepto las reglas de reenvío de L3_DEFAULT. Las reglas de reenvío que usan el protocolo L3_DEFAULT nunca se borran en este paso porque L3_DEFAULT coincide con todos los protocolos. Por ejemplo, si el protocolo del paquete es TCP, solo se borran las reglas de reenvío que usan el protocolo UDP.

  • Elimina las reglas de reenvío cuyo puerto no coincida con el puerto del paquete. Las reglas de reenvío de todos los puertos configuradas nunca se borran con este paso, ya que una regla de reenvío de todos los puertos coincide con cualquier puerto.

  • Si las reglas de reenvío restantes incluyen L3_DEFAULT y reglas de reenvío específicas del protocolo, elimina las reglas de reenvío L3_DEFAULT. Si las reglas de reenvío restantes son todas reglas de reenvío L3_DEFAULT, ninguna se borra en este paso.

  • En este punto, las opciones de la regla de reenvío restante se dividen en una de las siguientes categorías:

    • Existe una única regla de reenvío que coincide con la dirección IP, el protocolo y el puerto de destino del paquete, y se usa para enrutar el paquete.
    • Quedan dos o más opciones de reglas de reenvío que coinciden con el protocolo, el puerto y la dirección IP de destino del paquete. Esto significa que las opciones de reglas de reenvío restantes incluyen reglas de reenvío de dirección (que se analizan en la siguiente sección). Selecciona la regla de reenvío de dirección cuyo rango de origen incluya el CIDR más específico (coincidencia de prefijo más largo) que contiene la dirección IP de origen del paquete. Si ninguna regla de reenvío de dirección tiene un rango de origen que incluya la dirección IP de origen del paquete, selecciona la regla de reenvío superior.
    • Los candidatos de la regla de reenvío cero permanecen y el paquete se descarta.

Cuando uses varias reglas de reenvío, asegúrate de configurar el software que se ejecuta en tus VM de backend para que se vincule a todas las direcciones IP externas de las reglas de reenvío del balanceador de cargas.

Direccionamiento del tráfico

Las reglas de reenvío para los balanceadores de cargas de red se pueden configurar a fin de dirigir el tráfico que proviene de un rango específico de direcciones IP de origen a un servicio de backend (o instancia de destino) específico.

El direccionamiento del tráfico es útil para solucionar problemas y realizar configuraciones avanzadas. Con la dirección de tráfico, puedes dirigir ciertos clientes a un conjunto diferente de backends, a una configuración de servicio de backend diferente o a ambas. Por ejemplo:

  • El direccionamiento del tráfico te permite crear dos reglas de reenvío que dirigen el tráfico al mismo grupo de instancias de backend a través de dos servicios de backend. Los dos servicios de backend se pueden configurar con diferentes verificaciones de estado, afinidades de sesión diferentes o políticas de control de distribución de tráfico diferentes (seguimiento de conexión, vaciado de conexiones y conmutación por error).
  • El direccionamiento del tráfico te permite crear dos reglas de reenvío que dirigen el tráfico a diferentes servicios de backend, con diferentes grupos de instancias de backend. Por ejemplo, un grupo de instancias se podría configurar con diferentes tipos de máquinas para procesar mejor el tráfico de un conjunto determinado de direcciones IP de origen.

El direccionamiento del tráfico se configura con un parámetro de la API de reglas de reenvío llamado sourceIPRanges. Las reglas de reenvío que tienen al menos un rango de IP de origen configurado se llaman reglas de reenvío de dirección.

Una regla de reenvío de dirección puede tener una lista de hasta 64 rangos de IP de origen. Puedes actualizar la lista de rangos de IP de origen configurados para una regla de reenvío de dirección en cualquier momento.

Cada regla de reenvío de dirección requiere que primero crees una regla de reenvío superior. Las reglas de reenvío principales y de desvío comparten la misma dirección IP externa regional, la información del puerto y el protocolo IP. Sin embargo, la regla de reenvío superior no tiene información de la dirección IP de origen. Por ejemplo:

  • Regla de reenvío superior: dirección IP: 198.51.100.1, protocolo IP: TCP, puertos: 80
  • Regla de reenvío de dirección: dirección IP: 198.51.100.1, protocolo IP: TCP, puertos: 80, sourceIPRanges: 203.0.113.0/24

Una regla de reenvío superior que apunta a un servicio de backend se puede asociar con una regla de reenvío de dirección que apunta a un servicio de backend o a una instancia de destino.

Para una regla de reenvío superior determinada, dos o más reglas de reenvío de dirección pueden tener rangos de IP de origen superpuestos, pero no idénticos. Por ejemplo, una regla de reenvío de dirección puede tener el rango de IP de origen 203.0.113.0/24 y otra regla de reenvío de dirección para la misma superior puede tener el rango de IP de origen 203.0.113.0.

Debes borrar todas las reglas de reenvío de dirección antes de borrar la regla de reenvío superior de la que dependen.

Para obtener información sobre cómo se procesan los paquetes entrantes cuando se usan reglas de reenvío de dirección, consulta Selección de reglas de reenvío.

Comportamiento de la afinidad de sesión en los cambios de dirección

En esta sección, se describen las condiciones en las que la afinidad de sesión se puede interrumpir cuando se actualizan los rangos de IP de origen para las reglas de reenvío de dirección:

  • Si una conexión existente coincide con la misma regla de reenvío después de cambiar los rangos de IP de origen para una regla de reenvío de dirección, la afinidad de sesión no se interrumpirá. Si tu cambio genera una conexión existente que coincide con una regla de reenvío diferente, realiza lo siguiente:
  • La afinidad de sesión siempre se interrumpe en las siguientes circunstancias:
    • La regla de reenvío recién coincidente dirige una conexión establecida a un servicio de backend (o instancia de destino) que no hace referencia a la VM de backend seleccionada previamente.
    • La regla de reenvío que coincidió de forma reciente dirige una conexión establecida a un servicio de backend que hace referencia a la VM de backend seleccionada previamente, pero el servicio de backend no está configurado con las conexiones persistentes cuando los backends están en mal estado, y la VM de backend lo logra la verificación de estado del servicio de backend.
  • La afinidad de sesión puede fallar cuando la regla de reenvío que coincidió de forma reciente dirige una conexión establecida a un servicio de backend, y el servicio de backend hace referencia a la VM seleccionada previamente, pero la combinación de la afinidad de sesión del servicio de backend y el modo de seguimiento de conexión da como resultado un hash de seguimiento de conexión diferente.

Preserva la afinidad de sesión en los cambios de dirección

En esta sección, se describe cómo evitar interrumpir la afinidad de sesión cuando se actualizan los rangos de IP de origen para las reglas de reenvío de dirección:

  • Dirige las reglas de reenvío que apuntan a los servicios de backend. Si la regla de reenvío principal y la de dirección apuntan a los servicios de backend, deberás asegurarte de forma manual de que la configuración de la afinidad de sesión y la política de seguimiento de conexiones sea idéntica. Google Cloud no rechaza de manera automática las configuraciones si no son idénticas.
  • Dirige las reglas de reenvío dirigidas a las instancias de destino. Una regla de reenvío superior que se dirige a un servicio de backend se puede asociar con una regla de reenvío de dirección que apunta a una instancia de destino. En este caso, la regla de reenvío de dirección hereda la configuración de afinidad de sesión y de la política de seguimiento de conexión de la regla de reenvío superior.

Si deseas obtener instrucciones para configurar la dirección de tráfico, consulta Configura la dirección de tráfico.

Servicio de backend regional

Cada balanceador de cargas de red tiene un servicio de backend regional que define el comportamiento del balanceador de cargas y cómo se distribuye el tráfico a sus backends. El nombre del servicio de backend es el nombre del balanceador de cargas de red que se muestra en Google Cloud Console.

Cada servicio de backend define los siguientes parámetros de backend:

  • Protocolo. Un servicio de backend acepta el tráfico en la dirección IP y los puertos (si están configurados) especificados por una o más reglas de reenvío externas regionales. El servicio de backend pasa paquetes a las VM de backend mientras conserva las direcciones IP de origen y destino y el protocolo del paquete y, si el protocolo está basado en puertos, los puertos de origen y destino.

    Los servicios de backend que se usan con balanceadores de cargas de red admiten las siguientes opciones de protocolos: TCP, UDP o UNSPECIFIED.

    Los servicios de backend con el protocolo UNSPECIFIED se pueden usar con cualquier regla de reenvío, sin importar el protocolo de reglas de reenvío. Solo se puede hacer referencia a los servicios de backend con un protocolo específico (TCP o UDP) mediante reglas de reenvío con el mismo protocolo (TCP o UDP). Las reglas de reenvío con el protocolo L3_DEFAULT solo pueden hacer referencia a los servicios de backend con el protocolo UNSPECIFIED.

    Consulta la especificación del protocolo de las reglas de reenvío para obtener una tabla con posibles combinaciones de protocolos de reglas de reenvío y servicios de backend.

  • Distribución de tráfico. Un servicio de backend permite distribuir el tráfico de acuerdo con una afinidad de sesión configurable y políticas de seguimiento de conexión. El servicio de backend también se puede configurar para habilitar el vaciado de conexiones y designar backends de conmutación por error para el balanceador de cargas.

  • Verificación de estado. Un servicio de backend debe tener una verificación de estado asociada regional.

Cada servicio de backend opera en una sola región y distribuye el tráfico a la primera interfaz de red (nic0) de las VM de backend. Los backends deben ser grupos de instancias ubicados en la misma región que el servicio de backend (y la regla de reenvío). Los backends pueden ser grupos de instancias no administrados zonales, administrados zonales o administrados regionales.

Los balanceadores de cargas de red basados en servicios de backend admiten grupos de instancias cuyas instancias miembro usan cualquier red de VPC en la misma región, siempre y cuando la red de VPC esté en el mismo proyecto que el servicio de backend. (Todas las VM dentro de un grupo de instancias determinado deben usar la misma red de VPC).

Si deseas que el balanceador de cargas admita el tráfico IPv6, el servicio de backend debe hacer referencia a los backends que cumplan con los requisitos para manejar el tráfico IPv6.

Grupos de instancias de backend

Un balanceador de cargas de red distribuye las conexiones entre las VM de backend contenidas en grupos de instancias administrados o no administrados. Los grupos de instancias pueden ser de alcance regional o zonal.

  • Grupos de instancias administrados regionales Usa los grupos de instancias administrados regionales si puedes implementar tu software mediante plantillas de instancias. Los grupos de instancias administrados regionales distribuyen de manera automática el tráfico entre varias zonas, lo que brinda la mejor opción para evitar posibles problemas en una zona determinada.

    Aquí se muestra un ejemplo de implementación con un grupo de instancias administrado regional. El grupo de instancias tiene una plantilla de instancias que define cómo se deben aprovisionar las instancias, y cada grupo implementa instancias dentro de tres zonas de la región us-central1.

    Balanceador de cargas de red con un grupo de instancias administrado regional
    Balanceo de cargas de red con un grupo de instancias administrado regional
  • Grupos de instancias zonales administrados o no administrados. Usa grupos de instancias zonales en diferentes zonas (en la misma región) para protegerte de posibles problemas en una zona determinada.

    Aquí se muestra un ejemplo de implementación con grupos de instancias zonales. Este balanceador de cargas proporciona disponibilidad en dos zonas.

    Balanceador de cargas de red con grupos de instancias zonales
    Balanceo de cargas de red con grupos de instancias zonales

Si quieres que el balanceador de cargas admita el tráfico IPv6, los backends deben cumplir los siguientes requisitos:

  • Los backends deben configurarse en subredes de pila doble que se encuentran en la misma región que la regla de reenvío IPv6 del balanceador de cargas. Para los backends, puedes usar una subred con ipv6-access-type configurado como EXTERNAL o INTERNAL. Para usar una subred con ipv6-access-type configurado como INTERNAL, debes usar una subred de pila doble separada con ipv6-access-type configurado como EXTERNAL para la regla de reenvío externa del balanceador de cargas. Para obtener instrucciones, consulta Agrega una subred de pila doble.
  • Los grupos de instancias de backend deben configurarse para ser de pila doble con --ipv6-network-tier establecido como PREMIUM. Para obtener instrucciones, consulta Crea una plantilla de instancias con direcciones IPv6.

Verificaciones de estado

El balanceo de cargas de red usa verificaciones de estado regionales para determinar qué instancias pueden recibir conexiones nuevas. Cada servicio de backend del balanceador de cargas de red debe estar asociado con una verificación de estado regional. Los balanceadores de cargas usan el resultado de la verificación de estado para determinar cómo enrutar conexiones nuevas a instancias de backend.

Para obtener más detalles sobre cómo funcionan las verificaciones de estado de Google Cloud, consulta Cómo funcionan las verificaciones de estado.

El balanceo de cargas de red admite los siguientes tipos de verificaciones de estado:

Verificaciones de estado para otro tráfico de protocolo

Google Cloud no ofrece ninguna verificación de estado específica del protocolo más allá de las que se enumeran aquí. Cuando usas el balanceo de cargas de red para balancear las cargas de un protocolo que no sea TCP, debes ejecutar un servicio basado en TCP en las VMs de backend a fin de proporcionar la información de verificación de estado requerida.

Por ejemplo, si realizas un balanceo de cargas del tráfico de UDP, las solicitudes del cliente se balancean mediante el protocolo UDP, y debes ejecutar un servicio de TCP para proporcionar información a los sistemas de sondeo de verificación de estado de Google Cloud. Para lograrlo, puedes ejecutar un servidor HTTP simple en cada VM de backend que muestre una respuesta HTTP 200 a los sistemas de sondeo de la verificación de estado. Debes usar tu propia lógica que se ejecuta en la VM de backend para asegurarte de que el servidor HTTP muestre 200 solo si el servicio de UDP está en ejecución y configurado de forma correcta.

Reglas de firewall

Debido a que el balanceo de cargas de red es un balanceador de cargas de paso, puedes controlar el acceso a los backends del balanceador de cargas con las reglas de firewall de Google Cloud. Debes crear reglas de firewall de permiso de entrada o una política de firewall jerárquica de permiso de entrada para autorizar las verificaciones de estado y el tráfico en el que realizas el balanceo de cargas.

Las reglas de reenvío y las reglas de firewall de permiso de entrada o las políticas de firewall jerárquicas de permiso de entrada trabajan juntas de la siguiente manera: una regla de reenvío especifica el protocolo y, si están definidos, los requisitos del puerto que un paquete debe cumplir para que se lo reenvíe a una VM de backend. Las reglas de firewall de permiso de entrada controlan si los paquetes reenviados se entregan a la VM o se descartan. Todas las redes de VPC tienen una regla de firewall de entrada denegada implícita que bloquea los paquetes entrantes de cualquier fuente. La red de VPC predeterminada de Google Cloud incluye un conjunto limitado de reglas de firewall de permiso de entrada prepropagadas.

  • Para aceptar el tráfico de cualquier dirección IP en Internet, debes crear una regla de firewall de permiso de entrada con el rango de origen 0.0.0.0/0. Para permitir solo el tráfico de ciertos rangos de direcciones IP, usa rangos de origen más restrictivos.

  • Como práctica recomendada de seguridad, las reglas de firewall de permiso de entrada solo deben autorizar los protocolos y puertos IP que necesitas. La restricción de la configuración del protocolo (y, si es posible, el puerto) es muy importante cuando se usan reglas de reenvío cuyo protocolo se establece en L3_DEFAULT. Las reglas de reenvío L3_DEFAULT reenvían paquetes para todos los protocolos IP admitidos (en todos los puertos si el protocolo y el paquete tienen información del puerto).

  • El balanceo de cargas de red usa las verificaciones de estado de Google Cloud. Por lo tanto, siempre debes permitir el tráfico de los rangos de direcciones IP de verificación de estado. Puede especificarse que estas reglas de firewall de permiso de entrada sean específicas para el protocolo y los puertos de la verificación de estado del balanceador de cargas.

Direcciones IP para paquetes de solicitud y devolución

Cuando una VM de backend recibe un paquete con balanceo de cargas de un cliente, el origen y el destino del paquete son los siguientes:

  • Fuente: Es la dirección IP externa asociada con una VM de Google Cloud o una dirección IP enrutable por Internet de un sistema que se conecta al balanceador de cargas.
  • Destino: Es la dirección IP de la regla de reenvío del balanceador de cargas.

Debido a que el balanceador de cargas es un balanceador de cargas de paso (no un proxy), los paquetes llegan a la dirección IP de destino de la regla de reenvío del balanceador de cargas. El software que se ejecuta en las VM de backend se debe configurar para hacer lo siguiente:

  • Detecta (vincula) la dirección IP de la regla de reenvío del balanceador de cargas o cualquier dirección IP (0.0.0.0 o ::)
  • Si el protocolo de la regla de reenvío del balanceador de cargas admite puertos: Detecta (vincula a) un puerto que se incluye en la regla de reenvío del balanceador de cargas.

Los paquetes de retorno se envían directamente desde las VM de backend del balanceador de cargas al cliente. Las direcciones IP de origen y destino del paquete de retorno dependen del protocolo:

  • TCP está orientado a la conexión, por lo que las VM de backend deben responder con paquetes cuyas direcciones IP de origen coincidan con la dirección IP de la regla de reenvío. De esta forma, el cliente puede asociar los paquetes de respuesta con la conexión TCP adecuada.
  • UDP, ICMP, GRE y ESP no tienen conexión. Las VMs de backend pueden enviar paquetes de respuesta cuyas direcciones IP de origen coincidan con la dirección IP de la regla de reenvío o con cualquier dirección IP externa asignada para la VM. En términos prácticos, la mayoría de los clientes esperan que la respuesta provenga de la misma dirección IP a la que enviaron paquetes.

En la siguiente tabla, se muestra un resumen de los orígenes y destinos de los paquetes de respuesta:

Tipo de tráfico Origen Destino
TCP Es la dirección IP de la regla de reenvío del balanceador de cargas. Es el origen del paquete solicitante.
UDP, ESP, GRE, ICMP En la mayoría de los casos prácticos, la dirección IP de la regla de reenvío del balanceador de cargas Es el origen del paquete solicitante.

Cuando una VM tiene una dirección IP externa o cuando usas Cloud NAT, también es posible establecer la dirección IP de origen del paquete de respuesta a la dirección IPv4 interna principal de la NIC de la VM. Google Cloud o Cloud NAT cambian la dirección IP de origen del paquete de respuesta a la dirección IPv4 externa de la NIC o a una dirección IPv4 externa de Cloud NAT para enviar el paquete de respuesta a la dirección IP externa del cliente. No usar la dirección IP de la regla de reenvío como origen es una situación avanzada porque el cliente recibe un paquete de respuesta de una dirección IP externa que no coincide con la dirección IP a la que envió un paquete de solicitud.

Ruta de acceso de retorno

El balanceo de cargas de red usa rutas especiales fuera de tu red de VPC para dirigir las solicitudes y los sondeos de verificación de estado entrantes a cada VM de backend.

El balanceador de cargas conserva las direcciones IP de origen de los paquetes. Las respuestas de las VM de backend van directo a los clientes, no pasan a través del balanceador de cargas. El término del sector para esto es retorno directo del servidor.

Arquitectura de VPC compartida

A excepción de la dirección IP, todos los componentes de un balanceador de cargas de red deben existir en el mismo proyecto. En la siguiente tabla, se resumen los componentes de la VPC compartida para el balanceo de cargas de red:

Dirección IP Regla de reenvío Componentes de backend
Debe definirse una dirección IP externa regional en el mismo proyecto que el balanceador de cargas o el proyecto host de VPC compartida. Se debe definir una regla de reenvío regional externa en el mismo proyecto que las instancias del servicio de backend.

El servicio de backend regional debe definirse en el mismo proyecto y en la misma región donde existen las instancias del grupo de instancias de backend.

Las verificaciones de estado asociadas al servicio de backend deben definirse en el mismo proyecto y en la misma región que el servicio de backend.

Distribución de tráfico

La forma en que un balanceador de cargas de red distribuye las conexiones nuevas depende de si configuraste la conmutación por error:

  • Si no configuraste la conmutación por error, un balanceador de cargas de red distribuye conexiones nuevas a las VM de backend en buen estado, si al menos una VM de backend está en buen estado. Cuando todas las VM de backend están en mal estado, el balanceador de cargas distribuye nuevas conexiones entre todos los backends como último recurso. En esta situación, el balanceador de cargas enruta cada conexión nueva a una VM de backend en mal estado.
  • Si configuraste la conmutación por error, un balanceador de cargas de red distribuye las conexiones nuevas entre las VM de backend en buen estado en su grupo activo, de acuerdo con la política de conmutación por error que configures. Cuando todas las VM de backend están en mal estado, puedes elegir uno de los siguientes comportamientos:
    • El balanceador de cargas distribuye el tráfico solo a las VM principales (predeterminado). Esto se hace como último recurso. Las VM de copia de seguridad se excluyen de esta distribución de conexiones de último recurso.
    • El balanceador de cargas descarta el tráfico.

Para obtener detalles sobre cómo se distribuyen las conexiones, consulta la siguiente sección Selección de backend y seguimiento de conexiones.

Para obtener detalles sobre cómo funciona la conmutación por error, consulta la sección Conmutación por error.

Selección de backend y seguimiento de conexiones

El balanceo de cargas de red usa algoritmos configurables de selección de backend y seguimiento de conexiones para determinar cómo se distribuye el tráfico a las VM de backend.

El balanceo de cargas de red usa el siguiente algoritmo para distribuir paquetes entre las VM de backend (en su grupo activo, si configuraste la conmutación por error):

  1. Si el balanceador de cargas tiene una entrada en su tabla de seguimiento de conexiones que coincide con las características de un paquete entrante, el paquete se envía al backend que especifica la entrada de la tabla de seguimiento de conexiones. Se considera que el paquete forma parte de una conexión ya establecida, por lo que el paquete se envía a la VM de backend que el balanceador de cargas determinó y registró en su tabla de seguimiento de conexiones.
  2. Cuando el balanceador de cargas hace lo siguiente cuando recibe un paquete que no tiene una entrada de seguimiento de conexión:

    1. El balanceador de cargas selecciona un backend. El balanceador de cargas calcula un hash según la afinidad de sesión configurada. Usa este hash para seleccionar un backend entre los que están actualmente en buen estado (a menos que todos estén en mal estado, en cuyo caso se considerarán todos los backends, siempre y cuando la política de conmutación por error no se haya configurado para descartar el tráfico en esta situación). La afinidad de sesión predeterminada, NONE, usa los siguientes algoritmos de hash:

      • Para paquetes TCP y UDP sin fragmentar, un hash 5 tuplas de la dirección IP de origen del paquete, el puerto de origen, la dirección IP de destino, el puerto de destino y el protocolo
      • Para paquetes UDP fragmentados y todos los demás protocolos, un hash de 3 tuplas de la dirección IP de origen del paquete, la dirección IP de destino y el protocolo

      La selección del backend se puede personalizar mediante un algoritmo de hash que usa menos información. Para ver todas las opciones compatibles, consulta las opciones de afinidad de sesión.

    2. El balanceador de cargas agrega una entrada a su tabla de seguimiento de conexiones. En esta entrada, se registra el backend seleccionado para la conexión del paquete a fin de que todos los paquetes futuros de esta conexión se envíen al mismo backend. El uso del seguimiento de conexiones depende del protocolo:

      • Paquetes de TCP. El seguimiento de conexiones siempre está habilitado y no se puede desactivar. De forma predeterminada, el seguimiento de conexiones es de 5 tuplas, pero se puede configurar para que sea menor que 5. Cuando es de 5 tuplas, los paquetes de TCP SYN se tratan de manera diferente. A diferencia de los paquetes que no son SYN, descartan cualquier entrada de seguimiento de conexiones que coincida y siempre seleccionan un backend nuevo.

        El seguimiento de conexiones predeterminado de 5 tuplas se usa en los siguientes casos:

        • el modo de seguimiento es PER_CONNECTION (todas las afinidades de sesión), o,
        • el modo de seguimiento es PER_SESSION, y la afinidad de sesión es NONE, o,
        • el modo de seguimiento es PER_SESSION, y la afinidad de sesión es CLIENT_IP_PORT_PROTO.
      • Paquetes UDP, ESP y GRE. El seguimiento de conexiones solo está habilitado si la afinidad de sesión se configura en un elemento que no sea NONE.

      • Paquetes ICMP y ICMP.6. No se puede usar el seguimiento de conexiones.

      Para obtener más detalles sobre cuándo se habilita el seguimiento de conexiones y qué método se usa cuando dicho seguimiento está habilitado, consulta el modo de seguimiento de conexiones.

      Además, ten en cuenta lo siguiente:

      • Una entrada en la tabla de seguimiento de conexión vence 60 segundos después de que el balanceador de cargas procesa el último paquete que coincidió con la entrada. Este valor de tiempo de espera de inactividad de 60 segundos no se puede configurar.
      • Según el protocolo, el balanceador de cargas podría quitar las entradas de la tabla de seguimiento de conexiones cuando los backends están en mal estado. Para obtener detalles e información sobre cómo personalizar este comportamiento, consulta Persistencia de la conexión en backends en mal estado.

Opciones de afinidad de sesión

La afinidad de sesión controla la distribución de las conexiones nuevas de los clientes a las VM de backend del balanceador de cargas. La afinidad de sesión se especifica para todo el servicio de backend externo regional, no por cada grupo de instancias de backend.

El balanceo de cargas de red admite las siguientes opciones de afinidad de sesión:

  • Ninguna (NONE). Hash de 5 tuplas de la dirección IP de origen, el puerto de origen, el protocolo, la dirección IP de destino y el puerto de destino
  • IP de cliente, IP de destino (CLIENT_IP). Hash de 2 tuplas de la dirección IP de origen y destino
  • IP de cliente, IP de destino, protocolo (CLIENT_IP_PROTO). Hash de 3 tuplas de la dirección IP de origen, dirección IP de destino y protocolo
  • IP de cliente, puerto de cliente, IP de destino, puerto de destino, protocolo (CLIENT_IP_PORT_PROTO). Hash de 5 tuplas de la dirección IP de origen, puerto de origen, protocolo, dirección IP de destino y puerto de destino

Para obtener información sobre cómo estas opciones de afinidad de sesión afectan la selección del backend y los métodos de seguimiento de conexiones, consulta esta tabla.

Modo de seguimiento de conexiones

La habilitación del seguimiento de conexiones depende solo del protocolo del tráfico con balanceo de cargas y de la configuración de afinidad de sesión. El modo de seguimiento especifica el algoritmo de seguimiento de conexiones que se usará cuando esté habilitado el seguimiento de conexiones. Hay dos modos de seguimiento: PER_CONNECTION (predeterminado) y PER_SESSION.

  • PER_CONNECTION (predeterminado). Este es el modo de seguimiento predeterminado. Con este modo de seguimiento de conexiones, siempre se realiza un seguimiento del tráfico de TCP por 5 tuplas, sin importar la configuración de afinidad de sesión. Para el tráfico de UDP, ESP y GRE, el seguimiento de conexiones se habilita cuando la afinidad de sesión seleccionada no es NONE. Se realiza un seguimiento de los paquetes UDP, ESP y GRE mediante los métodos de seguimiento descritos en esta tabla.

  • PER_SESSION. Si la afinidad de sesión es CLIENT_IP o CLIENT_IP_PROTO, la configuración de este modo da como resultado un seguimiento de conexiones de 2 y 3 tuplas, respectivamente, para todos los protocolos (excepto ICMP e ICMPv6, a los que no se puede hacer un seguimiento de conexiones). Para otras configuraciones de afinidad de sesión, el modo PER_SESSION se comporta de manera idéntica al modo PER_CONNECTION.

A fin de obtener información sobre cómo funcionan estos modos de seguimiento con diferentes opciones de configuración de afinidad de sesión para cada protocolo, consulta la siguiente tabla.

Selección de backend Modo de seguimiento de conexiones
Configuración de afinidad de sesión Método hash para la selección de backend PER_CONNECTION (predeterminada) PER_SESSION
Predeterminado: sin afinidad de sesión

(NONE)

TCP y UDP sin fragmentar: Hash de 5 tuplas

UDP fragmentado y todos los otros protocolos: Hash de 3 tuplas

  • TCP: Seguimiento de conexión de 5 tuplas
  • Todos los demás protocolos: Seguimiento de conexión desactivado
  • TCP: Seguimiento de conexión de 5 tuplas
  • Todos los demás protocolos: Seguimiento de conexión desactivado
IP de cliente, IP de destino

(CLIENT_IP)

Todos los protocolos: Hash de 2 tuplas
  • TCP y UDP no fragmentado: Seguimiento de conexión de 5 tuplas
  • UDP fragmentado, ESP y GRE: seguimiento de conexión de 3 tuplas
  • Todos los demás protocolos: Seguimiento de conexión desactivado
  • TCP, UDP, ESP, GRE: Seguimiento de conexiones de 2 tuplas
  • Todos los demás protocolos: Seguimiento de conexión desactivado
IP de cliente, IP de destino, protocolo

(CLIENT_IP_PROTO)

Todos los protocolos: Hash de 3 tuplas
  • TCP y UDP no fragmentado: Seguimiento de conexión de 5 tuplas
  • UDP fragmentado, ESP y GRE: seguimiento de conexión de 3 tuplas
  • Todos los demás protocolos: Seguimiento de conexión desactivado
  • TCP, UDP, ESP, GRE: Seguimiento de conexión de 3 tuplas
  • Todos los demás protocolos: Seguimiento de conexión desactivado
IP de cliente, puerto de cliente, IP de destino, puerto de destino, protocolo

(CLIENT_IP_PORT_PROTO)

TCP y UDP sin fragmentar: Hash de 5 tuplas

UDP fragmentado y todos los demás protocolos: Hash de 3 tuplas

  • TCP y UDP no fragmentado: Seguimiento de conexión de 5 tuplas
  • UDP fragmentado, ESP y GRE: seguimiento de conexión de 3 tuplas
  • Todos los demás protocolos: Seguimiento de conexión desactivado
  • TCP y UDP no fragmentado: Seguimiento de conexión de 5 tuplas
  • UDP fragmentado, ESP y GRE: seguimiento de conexión de 3 tuplas
  • Todos los demás protocolos: Seguimiento de conexión desactivado

Para obtener información sobre cómo cambiar el modo de seguimiento de conexiones, consulta Configura una política de seguimiento de conexiones.

Persistencia de la conexión en backends en mal estado

La configuración de la persistencia de la conexión controla si una conexión existente permanece en un backend seleccionado después de que ese backend se encuentre en mal estado (siempre que el backend permanezca en el grupo de instancias de backend configurado del balanceador de cargas).

El comportamiento descrito en esta sección no se aplica a los casos en los que quitas una VM de backend de su grupo de instancias o quitas el grupo de instancias del servicio de backend. En esos casos, las conexiones establecidas solo se conservan como se describe en el vaciado de conexiones.

Las siguientes opciones de persistencia de la conexión están disponibles:

  • DEFAULT_FOR_PROTOCOL (predeterminada)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

En la siguiente tabla, se resumen las opciones de persistencia de la conexión y cómo persisten las conexiones para diferentes protocolos, opciones de afinidad de sesión y modos de seguimiento.

Opción de persistencia de conexión en backends en mal estado Modo de seguimiento de conexiones
PER_CONNECTION PER_SESSION
DEFAULT_FOR_PROTOCOL

TCP: las conexiones persisten en backends en mal estado (todas las afinidades de sesión).

Todos los demás protocolos: las conexiones nunca persisten en backends en mal estado.

TCP: las conexiones persisten en backends en mal estado si la afinidad de sesión es NONE o CLIENT_IP_PORT_PROTO.

Todos los demás protocolos: las conexiones nunca persisten en backends en mal estado.

NEVER_PERSIST Todos los protocolos: las conexiones nunca persisten en backends en mal estado.
ALWAYS_PERSIST

TCP: las conexiones persisten en backends en mal estado (todas las afinidades de sesión).

ESP, GRE, UDP: las conexiones persisten en backends en mal estado si la afinidad de sesión no es NONE.

ICMP, ICMPv6: No se aplica porque no se puede realizar un seguimiento de la conexión.

Esta opción solo se debe usar para casos de uso avanzados.

No es posible realizar la configuración.

Comportamiento de la persistencia de conexión TCP en backends en mal estado

Cuando una conexión TCP con seguimiento de 5 tuplas se mantiene en un backend en mal estado, ocurre lo siguiente:

  • Si el backend en mal estado sigue respondiendo a los paquetes, la conexión continúa hasta que se restablece o se cierra (ya sea por el backend en mal estado o el cliente).
  • Si el backend en mal estado envía un paquete de restablecimiento de TCP (RST) o no responde a los paquetes, el cliente puede volver a intentarlo con una conexión nueva, lo que permite que el balanceador de cargas seleccione otro backend en buen estado. Los paquetes de TCP SYN siempre seleccionan un backend nuevo y en buen estado.

Para obtener información sobre cómo cambiar el comportamiento de persistencia de la conexión, consulta Configura una política de seguimiento de conexiones.

Vaciado de conexiones

El vaciado de conexiones es un proceso que se aplica a las conexiones establecidas cuando sucede lo siguiente:

  • se quita una VM de backend de un grupo de instancias, o
  • cuando un grupo de instancias administrado quita una VM de backend (por reemplazo, abandono, cuando se actualiza o reduce el escalamiento)
  • cuando se quita un grupo de instancias de un servicio de backend.

De forma predeterminada, el vaciado de conexiones está inhabilitado. Cuando se inhabilita, las conexiones establecidas se finalizan lo más rápido posible. Cuando el vaciado de conexiones está habilitado, las conexiones establecidas pueden persistir durante un tiempo de espera configurable, tras lo cual finaliza la instancia de VM de backend.

Para obtener más información sobre cómo se habilita el vaciado de conexiones y cómo habilitarlo, consulta Habilita el vaciado de conexiones.

Fragmentación UDP

Los balanceadores de cargas de red basados en servicios de backend pueden procesar paquetes UDP fragmentados y no fragmentados. Si tu aplicación usa paquetes UDP fragmentados, ten en cuenta lo siguiente:

  • Los paquetes UDP pueden fragmentarse antes de llegar a una red de VPC de Google Cloud.
  • Las redes de VPC de Google Cloud reenvían fragmentos UDP a medida que llegan (sin esperar a que lleguen todos los fragmentos).
  • Las redes que no son de Google Cloud y el equipo de red local pueden reenviar fragmentos UDP a medida que llegan, retrasar los paquetes UDP fragmentados hasta que todos los fragmentos hayan llegado, o descartar paquetes UDP fragmentados. Para obtener más información, consulta la documentación del proveedor de red o el equipo de red.

Si esperas paquetes UDP fragmentados y necesitas enrutarlos a los mismos backends, usa la siguiente regla de reenvío y parámetros de configuración del servicio de backend:

  • Configuración de reglas de reenvío: Usa solo una regla de reenvío UDP o L3_DEFAULT por dirección IP con balanceo de cargas y configura la regla de reenvío para aceptar tráfico en todos los puertos. Esto garantiza que todos los fragmentos lleguen a la misma regla de reenvío. Aunque los paquetes fragmentados (que no sea el primer fragmento) no tienen un puerto de destino, configurar la regla de reenvío para procesar el tráfico en todos los puertos también la configura para recibir fragmentos UDP que no tienen información de puertos. A fin de configurar todos los puertos, usa Google Cloud CLI para configurar --ports=ALL o usa la API a fin de configurar allPorts en True.

  • Configuración del servicio de backend: establece la afinidad de sesión del servicio de backend en CLIENT_IP (hash de 2 tuplas) o CLIENT_IP_PROTO (hash de 3 tuplas), de manera que se seleccione el mismo backend para paquetes de UDP que incluyen información de puertos y fragmentos UDP (que no sean el primer fragmento) que carecen de información de puertos. Establece el modo de seguimiento de conexión del servicio de backend en PER_SESSION para que las entradas de la tabla de seguimiento de conexión se compilen mediante los mismos valores hash de 2 o 3 tuplas.

Usa instancias de destino como backends

Si usas instancias de destino como backends para el balanceador de cargas de red y esperas paquetes UDP fragmentados, usa solo una regla de reenvío UDP o L3_DEFAULT por dirección IP y configura la regla de reenvío para aceptar tráfico en todos los puertos. Esto garantiza que todos los fragmentos lleguen a la misma regla de reenvío, incluso si no tienen el mismo puerto de destino. Para configurar todos los puertos, configura --ports=ALL mediante gcloud, o configura allPorts en True mediante la API.

Conmutación por error

Puedes configurar un balanceador de cargas de red para distribuir conexiones entre instancias de máquina virtual (VM) en grupos de instancias de backend principales y, si es necesario, cambiar a grupos de instancias de backend de conmutación por error. La conmutación por error proporciona otro método para aumentar la disponibilidad y, también, te brinda un mayor control sobre cómo administrar la carga de trabajo cuando las VM de backend principales no están en buen estado.

De forma predeterminada, cuando agregas un backend al servicio de backend de un balanceador de cargas de red, ese backend será principal. Puedes designar un backend para que sea de conmutación por error cuando lo agregues al servicio de backend del balanceador de cargas o si editas el servicio de backend más adelante.

Si quieres obtener más detalles sobre cómo funciona la conmutación por error, consulta Descripción general de la conmutación por error para el balanceo de cargas de red.

Limitaciones

  • Los grupos de extremos de red (NEG) no se admiten como backends para balanceadores de cargas de red.
  • No puedes usar Google Cloud Console para realizar las siguientes tareas:

    • Crear o modificar un balanceador de cargas de red cuya regla de reenvío usa el protocolo L3_DEFAULT.
    • Crear o modificar un balanceador de cargas de red cuyo protocolo de servicio de backend está configurado como UNSPECIFIED.
    • Crear o modificar un balanceador de cargas de red que configure una política de seguimiento de conexión
    • Crea o modifica el direccionamiento del tráfico basado en IP de origen para una regla de reenvío.

    Usa Google Cloud CLI o la API de REST.

  • Los balanceadores de cargas de red no admiten el intercambio de tráfico entre redes de VPC.

¿Qué sigue?