Información general sobre los balanceadores de carga de red de paso a través externos basados en servicios de backend

Los balanceadores de carga de red de paso a través externos son balanceadores de carga de capa 4 regionales que distribuyen el tráfico externo entre backends (grupos de instancias o grupos de endpoints de red [NEGs]) de la misma región que el balanceador de carga. Estos backends deben estar en la misma región y proyecto, pero pueden estar en redes de VPC diferentes. Estos balanceadores de carga se basan en Maglev y en la pila de virtualización de redes Andromeda.

Los balanceadores de carga de red de paso a través externos pueden recibir tráfico de los siguientes elementos:

  • Cualquier cliente de Internet
  • Google Cloud Máquinas virtuales con IPs externas
  • Google Cloud Máquinas virtuales que tienen acceso a Internet a través de Cloud NAT o NAT basado en instancias

Los balanceadores de carga de red de paso a través externos no son proxies. El balanceador de carga no finaliza las conexiones de los usuarios. Los paquetes con balanceo de carga se envían a las VMs de backend con sus direcciones IP de origen y destino, su protocolo y, si procede, sus puertos sin cambios. A continuación, las VMs de backend terminan las conexiones de los usuarios. Las respuestas de las VMs backend van directamente a los clientes, no vuelven a pasar por el balanceador de carga. Este proceso se conoce como retorno directo del servidor (DSR).

Los balanceadores de carga de red de paso a través externos basados en servicios de backend admiten las siguientes funciones:

  • Backends de grupos de instancias gestionados y sin gestionar. Los balanceadores de carga de red de paso a través externos basados en servicios de backend admiten grupos de instancias gestionados y sin gestionar como backends. Los grupos de instancias gestionados automatizan ciertos aspectos de la gestión del backend y proporcionan una mejor escalabilidad y fiabilidad en comparación con los grupos de instancias no gestionados.
  • Backends de zonas de NEG por zonas. Los balanceadores de carga de red de paso a través externos basados en servicios de backend admiten el uso de NEGs por zonas con GCE_VM_IP endpoints. Los puntos finales de GCE_VM_IP de NEG por zonas te permiten hacer lo siguiente:
    • Reenvía paquetes a cualquier interfaz de red, no solo a nic0.
    • Coloca el mismo endpoint GCE_VM_IP en dos o más NEGs zonales conectados a diferentes servicios de backend.
  • Compatibilidad con varios protocolos. Los balanceadores de carga de red de paso a través externos basados en servicios de backend pueden balancear la carga del tráfico TCP, UDP, ESP, GRE, ICMP e ICMPv6.
  • Compatibilidad con la conectividad IPv6. Los balanceadores de carga de red de paso a través externos basados en servicios de backend pueden gestionar tráfico IPv4 e IPv6.
  • Control pormenorizado de la distribución del tráfico. Un servicio de backend permite distribuir el tráfico según la afinidad de sesión configurada, la política de seguimiento de conexiones y los ajustes de balanceo de carga ponderado. El servicio de backend también se puede configurar para habilitar el drenaje de conexiones y designar backends de conmutación por error para el balanceador de carga. La mayoría de estos ajustes tienen valores predeterminados que te permiten empezar rápidamente. Para obtener más información, consulta el artículo sobre la distribución del tráfico de los balanceadores de carga de red de transferencia externos.
  • Compatibilidad con comprobaciones del estado no antiguas. Los balanceadores de carga de red externos de pases basados en servicios de backend te permiten usar comprobaciones de estado que coincidan con el tipo de tráfico (TCP, SSL, HTTP, HTTPS o HTTP/2) que distribuyen.
  • Integración de Google Cloud Armor. Cloud Armor admite la protección de red avanzada contra DDoS para balanceadores de carga de red de paso a través externos. Para obtener más información, consulta Configurar la protección de red avanzada contra DDoS.

  • Integración con GKE. Si vas a crear aplicaciones en GKE, te recomendamos que uses el controlador de servicio de GKE integrado, que implementaGoogle Cloud balanceadores de carga en nombre de los usuarios de GKE. Es la misma que la arquitectura de balanceo de carga independiente que se describe en esta página, excepto que su ciclo de vida está totalmente automatizado y controlado por GKE.

    Documentación relacionada de GKE:

Arquitectura

En el siguiente diagrama se muestran los componentes de un balanceador de carga de red de paso a través externo:

Balanceador de carga de red de paso a través externo con un servicio de backend regional
Balanceador de carga de red de paso a través externo con un servicio de backend regional

El balanceador de carga se compone de varios componentes de configuración. Un solo balanceador de carga puede tener lo siguiente:

  • Una o varias direcciones IP externas regionales
  • Una o varias reglas de reenvío externas regionales
  • Un servicio backend externo regional
  • Uno o varios backends: todos los grupos de instancias o todos los backends de NEG zonales (GCE_VM_IP endpoints)
  • Comprobación del estado asociada al servicio de backend

Además, debes crear reglas de cortafuegos que permitan que el tráfico de balanceo de carga y las comprobaciones del estado lleguen a las VMs de backend.

Dirección IP

Un balanceador de carga de red de paso a través 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 desde cualquier lugar de Internet.

  • En el caso del tráfico IPv4, la regla de reenvío hace referencia a una sola dirección IPv4 externa regional. Las direcciones IPv4 externas regionales proceden de un grupo único para cada Google Cloud región. La dirección IP puede ser una dirección estática reservada o una dirección efímera.

  • En el caso del tráfico IPv6, la regla de reenvío hace referencia a un /96 intervalo de direcciones IPv6 de una subred de doble pila o solo IPv6. La subred debe tener un intervalo de subred IPv6 externa asignado en la red de VPC. Las direcciones IPv6 externas solo están disponibles en el nivel Premium.

    Para obtener más información sobre la compatibilidad con IPv6, consulta la documentación de VPC sobre los intervalos de subredes IPv6 y las direcciones IPv6.

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 eliminar 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 carga de red de paso a través externos admiten los niveles Estándar y Premium para las direcciones IPv4 externas regionales. Tanto la dirección IP como 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 carga acepta el tráfico. Como los balanceadores de carga de red de paso a través externos no son proxies, reenvían el tráfico a los backends con el mismo protocolo y los mismos puertos, si el paquete incluye información sobre los puertos. La regla de reenvío, junto con la dirección IP, forma el frontend del balanceador de carga.

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

El tráfico entrante se asocia a una regla de reenvío, que es una combinación de una dirección IP concreta (una dirección IPv4 o un intervalo de direcciones IPv6), un protocolo y, si el protocolo se basa en puertos, uno o varios puertos, un intervalo de puertos o todos los puertos. A continuación, la regla de reenvío dirige el tráfico al servicio de backend del balanceador de carga.

  • Si la regla de reenvío hace referencia a una dirección IPv4, no se asociará a ninguna subred. Es decir, su dirección IP procede de fuera de cualquier intervalo de subredGoogle Cloud .

  • Si la regla de reenvío hace referencia a un /96 intervalo de direcciones IPv6, la regla de reenvío debe estar asociada a una subred, y esa subred debe ser de doble pila (a) y tener un intervalo de subred IPv6 externa (--ipv6-access-type definido como EXTERNAL). La subred a la que hace referencia la regla de reenvío puede ser la misma que utilizan las instancias de backend. Sin embargo, las instancias de backend pueden usar una subred independiente si así lo eligen. Cuando las instancias de backend usan una subred independiente, se deben cumplir las siguientes condiciones:

Un balanceador de carga de red de paso a través externo requiere al menos una regla de reenvío. Las reglas de reenvío se pueden configurar para dirigir el tráfico procedente de un intervalo específico de direcciones IP de origen a un servicio de backend (o instancia de destino) concreto. Para obtener más información, consulta Dirección del tráfico. Puedes definir varias reglas de reenvío para el mismo balanceador de carga, tal como se describe en Varias reglas de reenvío.

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

Protocolos de reglas de reenvío

Los balanceadores de carga de red de paso a través 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 carga TCP o UDP. La opción de protocolo L3_DEFAULT permite que un balanceador de carga de red con paso a través externo balancee la carga del tráfico TCP, UDP, ESP, GRE, ICMP e ICMPv6.

Además de admitir protocolos distintos de TCP y UDP, L3_DEFAULT permite que una sola regla de reenvío sirva para varios protocolos. Por ejemplo, los servicios de IPsec suelen gestionar alguna combinación de tráfico ESP e IKE y NAT-T basado en UDP. La opción L3_DEFAULT permite configurar una única 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 que use el mismo protocolo que la regla de reenvío o un servicio de backend cuyo protocolo sea UNSPECIFIED. Las reglas de reenvío L3_DEFAULTsolo 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 que acepte tráfico en todos los puertos. Para configurar todos los puertos, defina --ports=ALL mediante la CLI de Google Cloud o defina allPorts en True mediante la API.

En la siguiente tabla se resume cómo usar estos ajustes para diferentes protocolos.

Tráfico que se va a balancear Protocolo de la 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 solicitud de eco) L3_DEFAULT UNSPECIFIED

Varias reglas de reenvío

Puede configurar varias reglas de reenvío externas regionales para el mismo balanceador de carga de red de paso a través externo. Cada regla de reenvío puede tener una dirección IP externa regional diferente, o bien varias reglas de reenvío pueden tener la misma dirección IP externa regional.

Configurar varias reglas de reenvío externas regionales puede ser útil en los siguientes casos prácticos:

  • Necesitas configurar más de una dirección IP externa para el mismo servicio de backend.
  • Debe configurar protocolos diferentes o puertos o intervalos de puertos que no se solapen para la misma dirección IP externa.
  • Necesitas dirigir el tráfico de determinadas direcciones IP de origen a back-ends de balanceadores de carga específicos.

Google Cloud requiere que los paquetes entrantes coincidan con una sola regla de reenvío. A excepción de las reglas de reenvío de dirección, que se describen en la siguiente sección, dos o más reglas de reenvío que usen 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 impide que se creen otras reglas de reenvío con el mismo protocolo y dirección IP. Las reglas de reenvío que usan los protocolos TCP o UDP se pueden configurar para que usen todos los puertos o para que usen puertos específicos. Por ejemplo, si creas una regla de reenvío con la dirección IP 198.51.100.1, el protocolo TCP y todos los puertos, no podrás crear ninguna otra regla de reenvío con la dirección IP 198.51.100.1 y el protocolo TCP. Puedes crear dos reglas de reenvío que usen la dirección IP 198.51.100.1 y el protocolo TCP, siempre que cada una tenga puertos únicos o intervalos de puertos que no se solapen. Por ejemplo, puedes crear dos reglas de reenvío con la dirección IP 198.51.100.1 y el protocolo TCP, donde los puertos de una regla de reenvío sean 80,443 y la otra use el intervalo 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 sola regla de reenvío L3_DEFAULT puede coexistir con otras reglas de reenvío que usen protocolos específicos (TCP o UDP). La regla de reenvío L3_DEFAULT se puede usar como último recurso cuando haya reglas de reenvío que usen la misma dirección IP, pero protocolos más específicos. Una regla de reenvío L3_DEFAULTprocesa los paquetes enviados a su dirección IP de destino si y solo si la dirección IP de destino, el protocolo y el puerto de destino del paquete no coinciden con una regla de reenvío específica del protocolo.

    Para ilustrarlo, veamos estas dos situaciones. Las reglas de reenvío de ambos casos 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 TCP enviados a cualquier puerto de destino de 198.51.100.1 se procesan mediante la segunda regla de reenvío. Los paquetes que usan protocolos diferentes se procesan con la primera regla de reenvío.
    • 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. Los paquetes TCP enviados a 198.51.100.1:8080 se procesan mediante la segunda regla de reenvío. El resto de los paquetes, incluidos los paquetes TCP enviados a puertos de destino diferentes, se procesan mediante la primera regla de reenvío.

Selección de reglas de reenvío

Google Cloud selecciona una o ninguna regla de reenvío para procesar un paquete entrante mediante este proceso de eliminación, empezando por el conjunto de reglas de reenvío candidatas que coinciden con la dirección IP de destino del paquete:

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

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

  • Si entre las reglas de reenvío candidatas restantes se incluyen reglas de reenvío L3_DEFAULT y reglas de reenvío específicas de protocolos, elimina las reglas de reenvío L3_DEFAULT. Si todos los candidatos a reglas de reenvío restantes son reglas de reenvío L3_DEFAULT, no se elimina ninguno en este paso.

  • En este punto, los candidatos a reglas de reenvío restantes se incluyen en una de las siguientes categorías:

    • Se mantiene 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 reglas de reenvío candidatas que coinciden con la dirección IP, el protocolo y el puerto de destino del paquete. Esto significa que los candidatos a reglas de reenvío restantes incluyen reglas de reenvío de dirección (que se explican en la siguiente sección). Selecciona la regla de reenvío de dirección cuyo intervalo de fuente incluya el CIDR más específico (la coincidencia de prefijo más larga) que contenga la dirección IP de origen del paquete. Si ninguna regla de reenvío de dirección tiene un intervalo de origen que incluya la dirección IP de origen del paquete, selecciona la regla de reenvío principal.
    • No quedan candidatos para la regla de reenvío y el paquete se descarta.

Cuando utilices varias reglas de reenvío, asegúrate de configurar el software que se ejecuta en tus VMs de backend para que se enlace a todas las direcciones IP externas de las reglas de reenvío del balanceador de carga.

Dirección del tráfico

Las reglas de reenvío de los balanceadores de carga de red de pases externos se pueden configurar para dirigir el tráfico procedente de una dirección IP de origen específica o de un intervalo de direcciones IP a un servicio de backend (o instancia de destino) específico.

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

  • La dirección del tráfico te permite crear dos reglas de reenvío que dirijan el tráfico al mismo backend (grupo de instancias o NEG) mediante dos servicios de backend. Los dos servicios de backend se pueden configurar con comprobaciones de estado, afinidades de sesión o políticas de control de distribución de tráfico diferentes (seguimiento de conexiones, purga de conexiones y conmutación por error).
  • La dirección de tráfico te permite crear una regla de reenvío para redirigir el tráfico de un servicio de backend de bajo ancho de banda a un servicio de backend de alto ancho de banda. Ambos servicios de backend contienen el mismo conjunto de VMs o endpoints de backend, pero se balancean con pesos diferentes mediante el balanceo de carga ponderado.
  • La dirección de tráfico te permite crear dos reglas de reenvío que dirijan el tráfico a diferentes servicios de backend, con diferentes backends (grupos de instancias o NEGs). Por ejemplo, un backend se puede configurar con diferentes tipos de máquina para procesar mejor el tráfico de determinadas direcciones IP de origen.

La dirección del tráfico se configura con un parámetro de la API de la regla de reenvío llamado sourceIPRanges. Las reglas de reenvío que tienen configurado al menos un intervalo de IPs de origen se denominan reglas de reenvío de dirección.

Una regla de reenvío de dirección puede usar el parámetro sourceIPRanges para especificar una lista separada por comas de hasta 64 direcciones IP de origen o intervalos de direcciones IP. Puede actualizar esta lista de intervalos de direcciones IP de origen en cualquier momento.

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

  • Regla de reenvío principal: 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 principal que apunta a un servicio de backend se puede asociar a una regla de reenvío de dirección que apunte a un servicio de backend o a una instancia de destino.

En una regla de reenvío principal determinada, dos o más reglas de reenvío de direccionamiento pueden tener intervalos de direcciones IP de origen superpuestos, pero no idénticos,así como direcciones IP. Por ejemplo, una regla de reenvío de dirección puede tener el intervalo de IP de origen 203.0.113.0/24 y otra regla de reenvío de dirección del mismo elemento superior puede tener la dirección IP de origen 203.0.113.0.

Para poder eliminar la regla de reenvío principal de la que dependen, debes eliminar todas las reglas de reenvío de dirección.

Para saber 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 puede dejar de funcionar cuando se actualizan los intervalos de direcciones IP de origen configurados en una regla de reenvío de dirección:

  • Si una conexión sigue coincidiendo con la misma regla de reenvío después de cambiar los intervalos de IPs de origen de una regla de reenvío de dirección, la afinidad de sesión no se interrumpe. Si el cambio hace que una conexión ya establecida coincida con otra regla de reenvío, ocurrirá lo siguiente:
  • La afinidad de sesión siempre se rompe en las siguientes circunstancias:
    • La regla de reenvío recién creada dirige una conexión establecida a un servicio de backend (o instancia de destino) que no hace referencia a la máquina virtual de backend seleccionada anteriormente.
    • La regla de reenvío recién asociada dirige una conexión establecida a un servicio de backend que hace referencia a la VM de backend seleccionada anteriormente, pero el servicio de backend no está configurado para mantener las conexiones cuando los backends no están en buen estado y la VM de backend no supera la comprobación del estado del servicio de backend.
  • La afinidad de sesión puede dejar de funcionar cuando la regla de reenvío recién asignada dirige una conexión establecida a un servicio de backend y el servicio de backend hace referencia a la VM seleccionada anteriormente, pero la combinación de la afinidad de sesión y el modo de seguimiento de conexiones del servicio de backend da como resultado un hash de seguimiento de conexiones diferente.

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

En esta sección se describe cómo evitar que se rompa la afinidad de sesión cuando se actualizan los intervalos de IP de origen de las reglas de reenvío de la dirección:

  • Dirigir reglas de reenvío a servicios de backend. Si tanto la regla de reenvío principal como la de dirección apuntan a servicios de backend, tendrás que asegurarte manualmente de que los ajustes de afinidad de sesión y política de seguimiento de conexiones sean idénticos.Google Cloud no rechaza automáticamente las configuraciones si no son idénticas.
  • Dirigir reglas de reenvío que apunten a instancias de destino. Una regla de reenvío principal que apunta a un servicio de backend se puede asociar a 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 los ajustes de afinidad de sesión y política de seguimiento de conexiones de la regla de reenvío superior.

Para obtener instrucciones sobre cómo configurar la dirección del tráfico, consulta Configurar la dirección del tráfico.

Servicio backend regional

Cada balanceador de carga de red de paso a través externo tiene un servicio de backend regional que define el comportamiento del balanceador de carga y cómo se distribuye el tráfico a sus backends. El nombre del servicio de backend es el nombre del balanceador de carga de red de paso a través externo que se muestra en la Google Cloud consola.

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

  • Protocolo. Un servicio de backend acepta tráfico en la dirección IP y los puertos (si se han configurado) especificados por una o varias reglas de reenvío externas regionales. El servicio de backend envía paquetes a las VMs de backend y conserva las direcciones IP de origen y de destino, el protocolo y, si el protocolo se basa en puertos, los puertos de origen y de destino.

    Los servicios de backend que se usan con balanceadores de carga de red de paso a través 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, independientemente del protocolo de la regla 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 servicios de backend con el protocolo UNSPECIFIED.

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

  • Distribución del tráfico. Un servicio de backend permite distribuir el tráfico según la afinidad de sesión configurada, la política de seguimiento de conexiones y los ajustes de balanceo de carga ponderado. El servicio de backend también se puede configurar para habilitar el drenaje de conexiones y designar backends de conmutación por error para el balanceador de carga. La mayoría de estos ajustes tienen valores predeterminados que te permiten empezar rápidamente. Para obtener más información, consulta el artículo sobre la distribución del tráfico de los balanceadores de carga de red de transferencia externos.

  • Comprobación del estado. Un servicio backend debe tener un chequeo de salud regional asociado.

  • Back-ends. Cada servicio de backend opera en una sola región y distribuye el tráfico a grupos de instancias o NEGs zonales de la misma región. Puede usar grupos de instancias o NEGs zonales, pero no una combinación de ambos, como backends de un balanceador de carga de red de paso a través externo:

    • Si eliges grupos de instancias, puedes usar grupos de instancias no gestionados, grupos de instancias gestionados zonales, grupos de instancias gestionados regionales o una combinación de tipos de grupos de instancias.
    • Si eliges NEGs de zona, debes usar GCE_VM_IP NEGs de zona.

    Cada grupo de instancias o backend de NEG tiene una red de VPC asociada, aunque ese grupo de instancias o NEG aún no se haya conectado a un servicio de backend. Para obtener más información sobre cómo se asocia una red a cada tipo de backend, consulta Backends de grupos de instancias e interfaces de red y Backends de NEG zonales e interfaces de red.

Grupos de instancias

Un balanceador de carga de red de paso a través externo distribuye las conexiones entre las VMs de backend que se encuentran en grupos de instancias gestionados o no gestionados. Los grupos de instancias pueden ser regionales o zonales.

Cada grupo de instancias tiene una red de VPC asociada, aunque aún no se haya conectado a un servicio de backend. Para obtener más información sobre cómo se asocia una red a grupos de instancias, consulta Backends de grupos de instancias e interfaces de red.

El balanceador de carga de red de paso a través externo tiene una alta disponibilidad por diseño. No es necesario seguir ningún paso especial para que el balanceador de carga tenga una alta disponibilidad, ya que el mecanismo no depende de un solo dispositivo ni de una sola instancia de VM. Solo tienes que asegurarte de que tus instancias de VM de backend se implementen en varias zonas para que el balanceador de carga pueda evitar posibles problemas en cualquier zona.

  • Grupos de instancias gestionados regionales. Usa grupos de instancias gestionadas regionales si puedes implementar tu software mediante plantillas de instancia. Los grupos de instancias gestionadas regionales distribuyen automáticamente el tráfico entre varias zonas, lo que ofrece la mejor opción para evitar posibles problemas en cualquier zona.

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

    Balanceador de carga de red de paso a través externo con un grupo de instancias gestionadas regional
    Balanceador de carga de red de paso a través externo con un grupo de instancias gestionado regional

  • Grupos de instancias gestionados o sin gestionar zonales. Usa grupos de instancias zonales en diferentes zonas (de la misma región) para protegerte frente a posibles problemas en cualquier zona.

    A continuación, se muestra un ejemplo de implementación con grupos de instancias zonales. Este balanceador de carga proporciona disponibilidad en dos zonas.

    Balanceador de carga de red de paso a través externo con grupos de instancias zonales
    Balanceador de carga de red de paso a través externo con grupos de instancias zonales

NEGs por zonas

Un balanceador de carga de red de paso a través externo distribuye las conexiones entre los GCE_VM_IPendpoints contenidos en grupos de endpoints de red por zonas. Estos puntos finales deben estar ubicados en la misma región que el balanceador de carga. Para ver algunos casos prácticos recomendados de NEG por zonas, consulta la descripción general de los grupos de puntos finales de red por zonas.

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

Los NEGs zonales admiten máquinas virtuales de doble pila (IPv4 e IPv6) e IPv4. En el caso de las VMs IPv4 y de doble pila, basta con especificar la instancia de VM al adjuntar un endpoint a un NEG. No es necesario que especifiques la dirección IP del endpoint. 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, aunque ese NEG zonal aún no se haya conectado a un servicio de backend. Para obtener más información sobre cómo se asocia una red a los NEG zonales, consulta Back-ends e interfaces de red de los NEG zonales.

Backends de grupos de instancias e interfaces de red

En un grupo de instancias (gestionado o no gestionado), todas las instancias de VM deben tener sus nic0 interfaces de red en la misma red de VPC.

  • En el caso de los grupos de instancias gestionados, la red VPC del grupo de instancias se define en la plantilla de instancia.
  • En el caso de los grupos de instancias no gestionados, la red de VPC del grupo de instancias se define como la red de VPC que utiliza la nic0interfaz de red de la primera instancia de VM que añadas al grupo de instancias no gestionado.
Los servicios de backend no pueden distribuir el tráfico a las máquinas virtuales miembro de un grupo de instancias en interfaces que no sean nic0. Si quieres recibir tráfico en una interfaz de red que no sea nic0 (NICs virtuales o interfaces de red dinámicas), debes usar NEGs zonales con endpoints GCE_VM_IP.

Backends de NEGs por zonas e interfaces de red

Cuando creas un NEG zonal con GCE_VM_IP puntos finales, debes asociar explícitamente el NEG a una subred de una red de VPC antes de poder añadir puntos finales al NEG. Ni la subred ni la red VPC se pueden cambiar una vez creado el NEG.

En un NEG determinado, cada endpoint GCE_VM_IP representa una interfaz de red. La interfaz de red debe estar en la subred asociada al NEG. Desde el punto de vista de una instancia de Compute Engine, la interfaz de red puede usar cualquier identificador. Desde la perspectiva de ser un endpoint de un NEG, la interfaz de red se identifica mediante su dirección IPv4 interna principal.

Hay dos formas de añadir un endpoint GCE_VM_IP a un NEG:

  • Si solo especifica el nombre de una VM (sin ninguna dirección IP) al añadir un endpoint, Google Cloud requiere que la VM tenga una interfaz de red en la subred asociada al NEG. La dirección IP que Google Cloud elige para el endpoint es la dirección IPv4 interna principal de la interfaz de red de la VM en la subred asociada al NEG.
  • Si especificas tanto un nombre de VM como una dirección IP al añadir un endpoint, la dirección IP que proporciones debe ser una dirección IPv4 interna principal de una de las interfaces de red de la VM. Esa interfaz de red debe estar en la subred asociada al NEG. Ten en cuenta que especificar una dirección IP es redundante, ya que solo puede haber una interfaz de red en la subred asociada al NEG.

No se puede eliminar una NIC dinámica si es un endpoint de un grupo de endpoints de red con balanceo de carga.

Servicios de backend y redes VPC

El servicio de backend no está asociado a ninguna red de VPC. Sin embargo, cada grupo de instancias de backend o NEG zonal está asociado a una red de VPC, como se ha indicado anteriormente. Siempre que todos los backends se encuentren en la misma región y proyecto, y que todos los backends sean del mismo tipo (grupos de instancias o NEGs zonales), puedes añadir backends que usen la misma red VPC o redes VPC diferentes.

Para distribuir paquetes a una interfaz que no sea nic0, debes usar back-ends de NEG zonales (con endpoints GCE_VM_IP).

Back-ends de doble pila (IPv4 e IPv6)

Si quieres que el balanceador de carga use backends de doble pila que gestionen el tráfico IPv4 e IPv6, ten en cuenta los siguientes requisitos:

  • Los backends deben configurarse en subredes de pila dual que estén en la misma región que la regla de reenvío IPv6 del balanceador de carga. En el caso de los back-ends, puedes usar una subred con el valor ipv6-access-type definido como EXTERNAL o INTERNAL. Si el valor de ipv6-access-type de la subred de backend es INTERNAL, debes usar otra subred solo IPv6 o una subred de doble pila con el valor EXTERNAL en ipv6-access-type para la regla de reenvío externa del balanceador de carga.
  • Los back-ends deben configurarse para que sean de pila dual con stack-type definido como IPV4_IPV6. Si el valor de ipv6-access-type de la subred backend es EXTERNAL, también debes asignar el valor PREMIUM a --ipv6-network-tier. Para obtener instrucciones, consulta Crear una plantilla de instancia con direcciones IPv6.

Back-ends solo IPv6

Si quieres que el balanceador de carga use backends solo IPv6, ten en cuenta los siguientes requisitos:

  • Las instancias solo IPv6 solo se admiten en grupos de instancias sin gestionar. No se admite ningún otro tipo de backend.
  • Los backends deben configurarse en subredes de doble pila o solo IPv6 que estén en la misma región que la regla de reenvío IPv6 del balanceador de carga. En el caso de los back-ends, puedes usar una subred con el valor ipv6-access-type definido como INTERNAL o EXTERNAL. Si el ipv6-access-type de la subred de backend se ha definido como INTERNAL, debe usar otra subred solo IPv6 con ipv6-access-type definido como EXTERNAL para la regla de reenvío externa del balanceador de carga.
  • Los backends deben configurarse para que solo usen IPv6 con la VM stack-type definida como IPV6_ONLY. Si el valor de ipv6-access-type de la subred backend es EXTERNAL, también debes asignar el valor PREMIUM a --ipv6-network-tier. Para obtener instrucciones, consulta Crear una plantilla de instancia con direcciones IPv6.

Ten en cuenta que las VMs solo con IPv6 se pueden crear en subredes de doble pila y solo con IPv6, pero las VMs de doble pila no se pueden crear en subredes solo con IPv6.

Comprobaciones del estado

Los balanceadores de carga de red de paso a través externos usan comprobaciones del estado regionales para determinar qué instancias pueden recibir nuevas conexiones. El servicio de backend de cada balanceador de carga de red de paso a través externo debe estar asociado a una comprobación de estado regional. Los balanceadores de carga usan el estado de las comprobaciones de estado para determinar cómo enrutar las conexiones nuevas a las instancias de backend.

Para obtener más información sobre cómo funcionan las comprobaciones del estado, consulta el artículo Cómo funcionan las comprobaciones del estado. Google Cloud

Los balanceadores de carga de red de paso a través externos admiten los siguientes tipos de comprobaciones de estado:

Comprobaciones del estado para el tráfico de otros protocolos

Google Cloud no ofrece ninguna comprobación del estado específica de un protocolo más allá de las que se indican en la sección Comprobaciones del estado, más arriba en esta página. Cuando usas un balanceador de carga de red de paso a través externo para balancear la carga de un protocolo que no sea TCP, debes ejecutar un servicio basado en TCP en tus VMs de backend para proporcionar la información de comprobación de estado necesaria.

Por ejemplo, si estás balanceando la carga del tráfico UDP, las solicitudes de los clientes se balancean mediante el protocolo UDP y debes ejecutar un servicio TCP para proporcionar información a los verificadores de estado. Google Cloud Para ello, puedes ejecutar un servidor HTTP en cada VM de backend que devuelva una respuesta HTTP 200 a los verificadores de estado. Debes usar tu propia lógica en la VM de backend para asegurarte de que el servidor HTTP devuelva el código 200 solo si el servicio UDP está configurado correctamente y en ejecución.

Reglas de cortafuegos

Como los balanceadores de carga de red de paso a través externos son balanceadores de carga de paso a través, puedes controlar el acceso a los backends del balanceador de carga mediante Google Cloud reglas de firewall. Debes crear reglas de cortafuegos de entrada o una política de cortafuegos jerárquica de entrada para permitir las comprobaciones del estado y el tráfico que estás balanceando.

Las reglas de reenvío y las reglas de cortafuegos de entrada o las políticas de cortafuegos jerárquicas funcionan conjuntamente de la siguiente manera: una regla de reenvío especifica el protocolo y, si se define, los requisitos de puerto que debe cumplir un paquete para reenviarse a una VM backend. Las reglas de cortafuegos de entrada permiten controlar si los paquetes reenviados se entregan a la VM o se descartan. Todas las redes de VPC tienen una regla de cortafuegos de denegación de entrada implícita que bloquea los paquetes entrantes de cualquier origen. La Google Cloud red de VPC predeterminada Google Cloud incluye un conjunto limitado de reglas de cortafuegos de entrada permitidas predefinidas.

  • Para aceptar el tráfico de cualquier dirección IP de Internet, debe crear una regla de cortafuegos de entrada que permita el tráfico con el intervalo de origen 0.0.0.0/0. Para permitir el tráfico solo de determinados intervalos de direcciones IP, usa intervalos de origen más restrictivos.

  • Como práctica recomendada de seguridad, las reglas de cortafuegos de entrada solo deben permitir los protocolos y puertos IP que necesites. Restringir la configuración del protocolo (y, si es posible, del puerto) es especialmente importante cuando se usan reglas de reenvío cuyo protocolo se ha definido como L3_DEFAULT. L3_DEFAULT reglas de reenvío reenvían paquetes de todos los protocolos IP admitidos (en todos los puertos si el protocolo y el paquete tienen información de puerto).

  • Los balanceadores de carga de red de paso a través externos usan Google Cloud comprobaciones del estado. Por lo tanto, siempre debe permitir el tráfico de los intervalos de direcciones IP de comprobación del estado. Estas reglas de cortafuegos de entrada se pueden especificar para el protocolo y los puertos de la comprobación del estado del balanceador de carga.

Direcciones IP de los paquetes de solicitud y de respuesta

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

  • Origen: la dirección IP externa asociada a una Google Cloud VM o la dirección IP de un sistema que se puede enrutar a través de Internet y que se conecta al balanceador de carga.
  • Destino: la dirección IP de la regla de reenvío del balanceador de carga.

Como el balanceador de carga es de paso (no un proxy), los paquetes llegan con la dirección IP de destino de la regla de reenvío del balanceador de carga. Configura el software que se ejecuta en las VMs de backend para que haga lo siguiente:

  • Escuchar (enlace a) la dirección IP de la regla de reenvío del balanceador de carga o cualquier dirección IP (0.0.0.0 o ::)
  • Si el protocolo de la regla de reenvío del balanceador de carga admite puertos, escucha (enlace a) un puerto incluido en la regla de reenvío del balanceador de carga.

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

  • TCP está orientado a la conexión, por lo que las VMs de backend deben responder con paquetes cuyas direcciones IP de origen coincidan con la dirección IP de la regla de reenvío para que el cliente pueda asociar los paquetes de respuesta con la conexión TCP adecuada.
  • UDP, ESP, GRE e ICMP no tienen conexión. Las máquinas virtuales de backend pueden enviar paquetes de respuesta cuya dirección IP de origen coincida con la dirección IP de la regla de reenvío o con cualquier dirección IP externa asignada a la máquina virtual. En la práctica, la mayoría de los clientes esperan que la respuesta proceda de la misma dirección IP a la que enviaron los paquetes.

En la siguiente tabla se resumen las fuentes y los destinos de los paquetes de respuesta:

Tipo de tráfico Fuente Destino
TCP La dirección IP de la regla de reenvío del balanceador de carga Origen del paquete solicitante
UDP, ESP, GRE e ICMP En la mayoría de los casos, la dirección IP de la regla de reenvío del balanceador de carga 1 El origen del paquete de solicitud.

1 Cuando una VM tiene una dirección IP externa o cuando usas Cloud NAT, también puedes definir la dirección IP de origen del paquete de respuesta como la dirección IPv4 interna principal de la NIC de la VM. Google Cloud o Cloud NAT cambia 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 un caso avanzado, ya que 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 retorno

Los balanceadores de carga de red de paso a través externos usan rutas especiales fuera de tu red de VPC para dirigir las solicitudes entrantes y las sondas de comprobación del estado a cada máquina virtual de backend.

El balanceador de carga conserva las direcciones IP de origen de los paquetes. Las respuestas de las VMs backend van directamente a los clientes, no vuelven a pasar por el balanceador de carga. El término del sector para esto es respuesta directa del servidor.

Conectividad a Internet saliente desde los backends

Las instancias de máquina virtual configuradas como puntos finales de backend de un balanceador de carga de red de pases externo pueden iniciar conexiones a Internet mediante la dirección IP de la regla de reenvío del balanceador de carga como dirección IP de origen de la conexión saliente.

Por lo general, una instancia de VM siempre usa su propia dirección IP externa o Cloud NAT para iniciar conexiones. Utiliza la dirección IP de la regla de reenvío para iniciar conexiones desde endpoints de backend solo en casos especiales, como cuando necesitas que las instancias de VM inicien y reciban conexiones en la misma dirección IP externa, y también necesitas la redundancia de backend que proporciona el balanceador de carga de red de transferencia externo para las conexiones entrantes.

Los paquetes salientes enviados desde las VMs de backend directamente a Internet no tienen restricciones en cuanto a protocolos y puertos de tráfico. Aunque un paquete de salida use la dirección IP de la regla de reenvío como origen, el protocolo y el puerto de origen del paquete no tienen que coincidir con el protocolo y la especificación de puerto de la regla de reenvío. Sin embargo, los paquetes de respuesta entrantes deben coincidir con la dirección IP, el protocolo y el puerto de destino de la regla de reenvío. Para obtener más información, consulta Rutas de los balanceadores de carga de red de paso a través externos y reenvío de protocolos externos.

Además, todas las respuestas a las conexiones salientes de la VM están sujetas al balanceo de carga, al igual que todos los demás paquetes entrantes destinados al balanceador de carga. Esto significa que es posible que las respuestas no lleguen a la misma VM de backend que inició la conexión a Internet. Si las conexiones salientes y las conexiones entrantes balanceadas de carga comparten protocolos y puertos comunes, puedes probar una de las siguientes sugerencias:

  • Sincroniza el estado de la conexión saliente en todas las VMs de backend para que las conexiones se puedan atender aunque las respuestas lleguen a una VM de backend distinta de la que ha iniciado la conexión.

  • Usa una configuración de conmutación por error con una sola VM principal y una sola VM de copia de seguridad. A continuación, la VM de backend activa que inicia las conexiones salientes siempre recibe los paquetes de respuesta.

Esta ruta de conectividad a Internet desde los backends de un balanceador de carga de red de paso a través externo es el comportamiento predeterminado previsto según las reglas de firewall implícitas de Google Cloud. Sin embargo, si te preocupa la seguridad de dejar esta ruta abierta, puedes usar reglas de cortafuegos de salida específicas para bloquear el tráfico saliente no solicitado a Internet.

Arquitectura de VPC compartida

A excepción de la dirección IP, todos los componentes de un balanceador de carga de red de paso a través externo deben estar en el mismo proyecto. En la siguiente tabla se resumen los componentes de VPC compartida para los balanceadores de carga de red de paso a través externos:

Dirección IP Regla de reenvío Componentes de backend
Una dirección IP externa regional debe definirse en el mismo proyecto que el balanceador de carga o en el proyecto host de la VPC compartida. Una regla de reenvío externa regional debe definirse 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 en los que se encuentren los backends (grupo de instancias o NEG zonal).

Las comprobaciones 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

Los balanceadores de carga de red de paso a través externos admiten varias opciones de personalización de la distribución del tráfico, como la afinidad de sesión, el seguimiento de conexiones, el balanceo de carga ponderado y la conmutación por error. Para obtener información sobre cómo distribuyen el tráfico los balanceadores de carga de red de paso a través externos y cómo interactúan entre sí estas opciones, consulta Distribución del tráfico de los balanceadores de carga de red de paso a través externos.

Limitaciones

  • No puedes usar la consola Google Cloud para hacer lo siguiente:

    • Crea o modifica un balanceador de carga de red de paso a través externo cuya regla de reenvío use el protocolo L3_DEFAULT.
    • Crea o modifica un balanceador de carga de red de paso a través externo cuyo protocolo de servicio de backend sea UNSPECIFIED.
    • Crea o modifica un balanceador de carga de red de paso a través externo que configure una política de seguimiento de conexiones.
    • Crea o modifica la dirección del tráfico basada en la IP de origen de una regla de reenvío.

    Usa la CLI de Google Cloud o la API REST.

  • Los balanceadores de carga de red de paso a través externos no admiten el emparejamiento entre redes de VPC.

Precios

Para obtener información sobre los precios, consulta la página Precios.

Siguientes pasos