Descripción general del balanceador de cargas de red de transferencia externa basado en servicios de backend.

Los balanceadores de cargas de red de transferencia externos son balanceadores de cargas regionales de capa 4 que distribuyen el tráfico externo entre backends (grupos de instancias o grupos de extremos de red [NEG]) en la misma región que el balanceador de cargas. Estos backends deben estar en la misma región y proyecto, pero pueden estar en diferentes redes de VPC. Estos balanceadores de cargas se compilan en Maglev y en la pila de virtualización de red de Andromeda.

Los balanceadores de cargas de red de transferencia externos pueden recibir tráfico de las siguientes fuentes:

  • 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

Los balanceadores de cargas de red de transferencia externos no son proxies. El balanceador de cargas no finaliza las conexiones de usuario. Los paquetes con balanceo de cargas se envían a las VMs de backend con las direcciones IP de origen y destino, el protocolo y, si corresponde, los puertos, sin cambios. Luego, las VMs de backend finalizan las conexiones de usuario. Las respuestas de las VMs de backend van directo a los clientes, no pasan a través del balanceador de cargas. Este proceso se conoce como retorno directo del servidor (DSR).

Los balanceadores de cargas de red de transferencia externos basados en servicios de backend admiten las siguientes funciones:

  • Backends de grupos de instancias administrados y no administrados. Los balanceadores de cargas de red de transferencia externos basados en servicios de backend admiten grupos de instancias administrados y no administrados 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.
  • Backends de NEG zonales Los balanceadores de cargas de red de transferencia externos basados en servicios de backend admiten el uso de NEG zonales con extremos GCE_VM_IP. Los extremos de NEG zonales GCE_VM_IP te permiten hacer lo siguiente:
    • Reenviar paquetes a cualquier interfaz de red, no solo a nic0.
    • Colocar el mismo extremo GCE_VM_IP en dos o más NEG zonales conectados a diferentes servicios de backend.
  • Compatibilidad con varios protocolos. Los balanceadores de cargas de red de transferencia externos basados en servicios de backend pueden balancear las cargas de tráfico de TCP, UDP, ESP, GRE, ICMP y ICMPv6.
  • Compatibilidad con la conectividad IPv6. Los balanceadores de cargas de red de transferencia externos basados en servicios de backend pueden controlar tráfico IPv4 e IPv6.
  • Control detallado de la distribución del tráfico. Un servicio de backend permite distribuir el tráfico de acuerdo con una afinidad de sesión configurable, un modo de seguimiento de conexiones y un balanceo de cargas ponderado. 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. La mayoría de estas opciones de configuración tienen valores predeterminados que te permiten comenzar con rapidez.
  • Compatibilidad con verificaciones de estado no heredadas. Los balanceadores de cargas de red de transferencia externos basados en servicios de backend te permiten 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 de transferencia externos. Para obtener más información, consulta Configura la protección contra DSD de red avanzada.

  • Integración en 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 de transferencia externo:

Balanceador de cargas de red de traspaso externo con un servicio de backend regional
Balanceador de cargas de red de transferencia externo con un 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 backends: todos los grupos de instancias o todos los backends de NEG zonales (extremos GCE_VM_IP)
  • 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 de transferencia externo 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 /96 de una subred de pila doble con un rango de subred IPv6 externo en la red de VPC. Las direcciones IPv6 externas solo están disponibles en el nivel Premium. La dirección IPv6 puede ser una dirección estática reservada o una dirección efímera.

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.

Los balanceadores de cargas de red de transferencia externos admiten el nivel Estándar y el nivel 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 detransferencia externos 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 un rango de direcciones IPv6 /96, la regla de reenvío debe estar asociada con una subred, y esa subred debe ser (a) de pila doble y (b) tener una subred IPv6 externa. rango (--ipv6-access-type configurado como EXTERNAL) La subred a la que hace referencia la regla de reenvío puede ser la misma subred que usan las instancias de backend; sin embargo, las instancias de backend pueden usar una subred separada si lo eliges. Cuando las instancias de backend usan una subred separada, se deben cumplir los siguientes requisitos:

Un balanceador de cargas de red de transferencia externo 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

Los balanceadores de cargas de red de transferencia externos admiten 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 de transferencia externo 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 múltiples reglas de reenvío externas regionales para el mismo balanceador de cargas de red de transferencia externo. 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 de transferencia externos 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 backend (grupo de instancias o NEG) 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 una regla de reenvío para redireccionar el tráfico desde un servicio de backend con ancho de banda bajo a un servicio de backend con ancho de banda alto. Ambos servicios de backend contienen el mismo conjunto de extremos o VMs de backend, pero tienen balanceo de cargas con diferentes ponderaciones con el balanceo de cargas ponderado.
  • 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 backends (grupos de instancias o NEG). Por ejemplo, un backend 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 interrumpe. 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 de transferencia externo 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 de transferencia externo que se muestra en la consola de Google Cloud.

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 de transferencia externos admiten las siguientes opciones de protocolo: 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, un modo de seguimiento de conexiones y un balanceo de cargas ponderado. 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.

  • Backends: cada servicio de backend opera en una sola región y distribuye el tráfico a grupos de instancias o NEG zonales en la misma región. Puedes usar grupos de instancias o NEG zonales, pero no una combinación de ambos, como backends para un balanceador de cargas de red de transferencia externo:

    • Si eliges grupos de instancias, puedes usar los no administrados, los administrados zonales, los administrados regionales o una combinación de tipos de grupos de instancias.
    • Si eliges NEG zonales, debes usar NEG zonales de GCE_VM_IP.

    Cada grupo de instancias o backend de NEG tiene una red de VPC asociada, incluso si ese grupo de instancias o NEG aún no se conectó a un servicio de backend. Para obtener más información sobre cómo se asocia una red con cada tipo de backend, consulta Interfaces de red y backends de grupos de instancias e Interfaces de red y backends de NEG zonales.

Grupos de instancias

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

Un balanceador de cargas de red de transferencia externo solo distribuye el tráfico a la primera interfaz de red (nic0) de las VMs de backend. El balanceador de cargas admite 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).

Cada grupo de instancias tiene una red de VPC asociada, incluso si ese grupo aún no se conectó a un servicio de backend. Para obtener más información sobre cómo se asocia una red con los grupos de instancias, consulta Interfaces de red y backends de grupos de instancias.

  • 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 de transferencia externa con un grupo de instancias administrado regional
    Balanceador de cargas de red de transferencia externo 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 de transferencia externo con grupos de instancias zonales
    Balanceador de cargas de red de transferencia externo con grupos de instancias zonales

NEG zonales

Un balanceador de cargas de red de transferencia externo distribuye las conexiones entre los extremos GCE_VM_IP contenidos en los grupos de extremos de red zonales. Estos extremos deben estar ubicados en la misma región que el balanceador de cargas. Para ver algunos casos de uso de NEG zonales recomendados, consulta Descripción general de los grupos de extremos de red zonales.

Los extremos del NEG deben ser direcciones IPv4 internas principales de las interfaces de red de la VM que se encuentren en la misma subred y la misma zona que el NEG zonal. La dirección IPv4 interna principal de cualquier interfaz de red de una instancia de VM con varias NIC se puede agregar a un NEG, siempre que esté en la subred del NEG.

Los NEG zonales admiten VMs de IPv4 y de pila doble (IPv4 e IPv6). Para las VMs de IPv4 y de pila doble, es suficiente especificar solo la instancia de VM cuando se adjunta un extremo a un NEG. No necesitas especificar la dirección IP del extremo. La instancia de VM siempre debe estar en la misma zona que el NEG.

Cada NEG zonal tiene una red de VPC y una subred asociadas, incluso si ese NEG zonal aún no se conectó a un servicio de backend. Para obtener más información sobre cómo se asocia una red con los NEG zonales, consulta Interfaces de red y backends de NEG zonales.

Interfaces de red y backends de grupos de instancias

La red de VPC asociada con un grupo de instancias es la red de VPC que usa la interfaz de red nic0 de cada VM miembro.

  • En los grupos de instancias administrados (MIG), la red de VPC para el grupo de instancias se define en la plantilla de instancias.
  • En los grupos de instancias no administrados, la red de VPC para el grupo de instancias se define como la red de VPC que usa la interfaz de red nic0 de la primera instancia de VM que agregas al grupo de instancias no administrado.

Dentro de un grupo de instancias determinado (administrado o no administrado), todas las instancias de VM deben tener sus interfaces de red nic0 en la misma red de VPC. De forma opcional, cada VM miembro puede tener interfaces de red adicionales (de nic1 a nic7), pero cada interfaz de red debe conectarse a una red de VPC diferente. Estas redes también deben ser diferentes de la red de VPC asociada con el grupo de instancias.

Los servicios de backend no pueden distribuir el tráfico a las VMs miembro del grupo de instancias en interfaces que no sean nic0. Si deseas recibir tráfico en una interfaz de red no predeterminada (de nic1 a nic7), debes usar NEG zonales con extremos GCE_VM_IP.

Interfaces de red y backends de NEG zonales

Cuando creas un NEG zonal nuevo con extremos GCE_VM_IP, debes asociar el NEG de forma explícita con una subred de una red de VPC para poder agregar extremos al NEG. Ni la subred ni la red de VPC se pueden cambiar después de que se crea el NEG.

Dentro de un NEG determinado, cada extremo GCE_VM_IP en realidad representa una interfaz de red. La interfaz de red debe estar en la subred asociada con el NEG. Desde la perspectiva de una instancia de Compute Engine, la interfaz de red puede usar cualquier identificador (nic0 a nic7). Desde la perspectiva de los extremos en un NEG, la interfaz de red se identifica mediante su dirección IPv4 principal.

Existen dos maneras de agregar un extremo GCE_VM_IP a un NEG:

  • Si especificas solo un nombre de VM (sin ninguna dirección IP) cuando agregas un extremo, Google Cloud requiere que la VM tenga una interfaz de red en la subred asociada con el NEG. La dirección IP que Google Cloud elige para el extremo es la dirección IPv4 interna principal de la interfaz de red de la VM en la subred asociada con el NEG.
  • Si especificas un nombre de VM y una dirección IP cuando agregas un extremo, la dirección IP que proporciones debe ser una dirección IPv4 interna principal para una de las interfaces de red de la VM. Esa interfaz de red debe estar en la subred asociada con el NEG. Ten en cuenta que especificar una dirección IP es redundante porque solo puede haber una única interfaz de red que esté en la subred asociada con el NEG.

Servicios de backend y redes de VPC

El servicio de backend no está asociado con ninguna red de VPC; sin embargo, cada grupo de instancias de backend o NEG zonal está asociado con una red de VPC, como se indicó antes. Siempre que todos los backends estén ubicados en la misma región y proyecto, y siempre que todos los backends sean del mismo tipo (grupos de instancias o NEG zonales), puedes agregar backends que usen las mismas redes de VPC u otras.

Para distribuir paquetes a nic1 a través de nic7, debes usar backends de NEG zonales (con extremos GCE_VM_IP) porque la red de VPC asociada de un grupo de instancias siempre coincide con la red de VPC que se usa por la interfaz nic0 de todas las instancias miembro.

Backends de doble pila (IPv4 e IPv6)

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 backends 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

Los balanceadores de cargas de red de transferencia externos usan verificaciones de estado regionales para determinar qué instancias pueden recibir conexiones nuevas. Cada servicio de backend del balanceador de cargas de red de transferencia externo 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.

Los balanceadores de cargas de red de transferencia externos admiten 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 en la sección Verificaciones de estado, antes en esta página. Cuando usas un balanceador de cargas de red de transferencia externo 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 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 los balanceadores de cargas de red de transferencia externos son balanceadores de cargas de paso, puedes controlar el acceso a los backends del balanceador de cargas mediante 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).

  • Los balanceadores de cargas de red de transferencia externos usan 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

Los balanceadores de cargas de red de transferencia externos 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 de transferencia externo deben existir en el mismo proyecto. En la siguiente tabla, se resumen los componentes de la VPC compartida para los balanceadores de cargas de red de traspaso externos:

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 los backends (grupo de instancias o NEG zonal).

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 del tráfico

La forma en que los balanceadores de cargas de red de transferencia externos distribuyen 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 de transferencia externo distribuye las conexiones nuevas a sus VMs 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 de transferencia externo distribuye las conexiones nuevas entre las VMs 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

Los balanceadores de cargas de red de transferencia externos usan algoritmos configurables de selección de backend y seguimiento de conexiones para determinar cómo se distribuye el tráfico a las VMs de backend.

Los balanceadores de cargas de red de transferencia externos usan el siguiente algoritmo para distribuir paquetes entre las VMs 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 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 de 5 tuplas de la dirección IP de origen, el puerto de origen, la dirección IP de destino, el puerto de destino y el protocolo del paquete.
      • Para paquetes UDP fragmentados y todos los demás protocolos, un hash de 3 tuplas de la dirección IP de origen, la dirección IP de destino y el protocolo del paquete.

      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.

      Además, ten en cuenta lo siguiente:

      Si habilitas el balanceo de cargas ponderado, la selección de backend basada en hash se pondera en función de los pesos informados por las instancias de backend. Por ejemplo:

      • Considera un servicio de backend configurado con afinidad de sesión establecida en NONE y una regla de reenvío con el protocolo UDP. Si hay dos instancias de backend en buen estado con pesos 1 y 4, los backends obtendrán el 20% y el 80% de los paquetes UDP, respectivamente.
      • Considera un servicio de backend configurado con afinidad de sesión de 3 tuplas y seguimiento de conexión. La afinidad de sesión es CLIENT_IP_PROTO y el modo de seguimiento de conexiones es PER_SESSION. Si hay tres instancias de backend en buen estado con ponderaciones 0, 2 y 6, los backends obtendrán tráfico para el 0%, el 25% y el 75% de las nuevas direcciones IP de origen (las direcciones IP para las que no hay entradas de tablas de seguimiento de conexiones existentes), respectivamente. El tráfico de las conexiones existentes se dirigirá a los backends asignados previamente.

    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 e ICMPv6. 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 backend.

Los balanceadores de cargas de red de transferencia externos admiten 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 persistencia de la conexión controla si una conexión existente persiste en una VM o extremo de backend seleccionado después de que ese backend esté en mal estado, siempre que el backend permanezca en el grupo de backend configurado del balanceador de cargas (en un grupo de instancias o un NEG).

El comportamiento descrito en esta sección no se aplica a los casos en los que quitas una instancia de backend de un grupo de instancias o quitas un extremo de backend de su NEG, o quitas el grupo de instancias o el NEG 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 aplicable 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.

Balanceo de cargas ponderado

Puedes configurar un balanceador de cargas de red para distribuir el tráfico entre las instancias de backend del balanceador de cargas según las ponderaciones que informa una verificación de estado HTTP mediante el balanceo de cargas ponderado.

El balanceo de cargas ponderado requiere que configures lo siguiente:

  • Debes establecer la política del balanceador de cargas de localidad (localityLbPolicy) del servicio de backend como WEIGHTED_MAGLEV.
  • Debes configurar el servicio de backend con una verificación de estado de HTTP. Las respuestas de verificación de estado de HTTP deben contener un campo de encabezado de respuesta HTTP personalizado X-Load-Balancing-Endpoint-Weight para especificar los pesos con valores de 0 a 1000 para cada instancia de backend.

Si usas el mismo backend (grupo de instancias o NEG) para varios balanceadores de cargas de red de transferencia externos basados en servicios de backend mediante el balanceo de cargas ponderado, te recomendamos usar una request-path única para cada verificación de estado del servicio de backend. Esto permite que la instancia de extremo asigne diferentes ponderaciones a los servicios de backend diferentes. A fin de obtener más información, consulta Criterios de éxito para verificaciones de estado HTTP, HTTPS y HTTP/2.

A fin de seleccionar un backend para una conexión nueva, se les asigna un orden de prioridad estricto según su ponderación y estado, como se muestra en la siguiente tabla:

Peso En buen estado Prioridad de selección del backend
Ponderación mayor que cero Sí 4
Ponderación mayor que cero No 3
Ponderación igual a cero. Sí 2
Ponderación igual a cero. No 1

Solo los backends de mayor prioridad son aptos para la selección de backend. Si todos los backends aptos tienen ponderación cero, el balanceador de cargas distribuye las conexiones nuevas entre todos los backends aptos y los trata con la misma ponderación. Para ver ejemplos del balanceo de cargas ponderado, consulta Selección de backend y seguimiento de conexiones.

El balanceo de cargas ponderado se puede usar en las siguientes situaciones:

  • Si algunas conexiones procesan más datos que otras, o algunas conexiones duran más que otras, la distribución de la carga del backend podría volverse desigual. Cuando se indica una ponderación menor por instancia, una instancia con carga alta puede reducir su cuota de conexiones nuevas, a la vez que mantiene las conexiones existentes.

  • Si un backend está sobrecargado y la asignación de más conexiones puede interrumpir las conexiones existentes, esos backends se asignan una ponderación de cero a sí mismos. Cuando se indica una ponderación de cero, una instancia de backend deja de entregar conexiones nuevas, pero continúa entregando servicios a las existentes.

  • Si un backend vacía las conexiones existentes antes del mantenimiento, se asigna ponderación cero a sí mismo. Cuando se indica una ponderación de cero, la instancia de backend deja de entregar conexiones nuevas, pero continúa entregando servicios a las existentes.

Para obtener más información, consulta Configura el balanceo de cargas ponderado.

Vaciado de conexiones

El vaciado de conexiones es un proceso que se aplica a las conexiones establecidas en los siguientes casos:

  • Se quita una VM o extremo de un backend (grupo de instancias o NEG).
  • Un backend quita una VM o extremo (por reemplazo, abandono, actualizaciones o reducción de la escala verticalmente).
  • Se quita un backend 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 de transferencia externos 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 de transferencia externo 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 de transferencia externo para distribuir conexiones entre instancias o extremos de VM en backends principales (grupos de instancias o NEG) y, si es necesario, cambiar a backends 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 los backends principales no están en buen estado.

De forma predeterminada, cuando agregas un backend al servicio de backend del balanceador de cargas de red de transferencia externo, ese backend es el 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.

Para obtener más detalles sobre cómo funciona la conmutación por error, consulta Descripción general de los balanceadores de cargas de red de transferencia externos.

Limitaciones

  • No puedes usar la consola de Google Cloud para realizar las siguientes tareas:

    • Crea o modifica un balanceador de cargas de red de transferencia externo cuya regla de reenvío usa el protocolo L3_DEFAULT.
    • Crea o modificar un balanceador de cargas de red de transferencia externo cuyo protocolo de servicio de backend está configurado como UNSPECIFIED.
    • Crea o modifica un balanceador de cargas de red de transferencia externo que configure una política de seguimiento de conexiones.
    • 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 de transferencia externos no admiten el intercambio de tráfico entre redes de VPC.

¿Qué sigue?