Descripción general del balanceador de cargas de red de transferencia interno

Un balanceador de cargas de red de transferencia interno es un balanceador de cargas regional que se compila en la pila de virtualización de red de Andromeda.

Los balanceadores de cargas de red de transferencia internos distribuyen el tráfico entre las instancias de máquina virtual (VM) internas en la misma región en una red de nube privada virtual (VPC). Te permite ejecutar y escalar tus servicios detrás de una dirección IP interna a la que solo pueden acceder los sistemas en la misma red de VPC o los sistemas conectados a tu red de VPC.

Usa un balanceador de cargas de red de transferencia interno en las siguientes circunstancias:

  • Necesitas un balanceador de cargas de capa 4 de alto rendimiento y de traspaso para los protocolos TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH y GRE.
  • Si se entrega tráfico a través de TLS (SSL), es aceptable que tus backends finalicen el tráfico SSL en lugar de que lo haga el balanceador de cargas. El balanceador de cargas de red de transferencia interno no puede finalizar el tráfico SSL.
  • Úsalo si debes reenviar los paquetes originales sin proxy. Por ejemplo, si necesitas que se conserve la dirección IP de origen de cliente.
  • Si tienes una configuración existente que usa un balanceador de cargas de paso y deseas migrarla sin cambios.

Los balanceadores de cargas de red de transferencia internos abordan muchos casos prácticos. Para ver algunos ejemplos de alto nivel, consulta la descripción general del balanceador de cargas de red de transferencia.

Cómo funcionan los balanceadores de cargas de red de transferencia internos

Un balanceador de cargas de red de transferencia interno tiene un frontend (la regla de reenvío) y un backend (el servicio de backend). Puedes usar grupos de instancias o NEG zonales de GCE_VM_IP como backends en el servicio de backend. En este ejemplo se muestran los backends de grupos de instancias.

Ejemplo de balanceador de cargas de red de transferencia interno de alto nivel
Ejemplo de un balanceador de cargas de red de transferencia interno de alto nivel (haz clic para ampliar).

A diferencia de un balanceador de cargas de proxy, un balanceador de cargas de red interno no finaliza las conexiones de los clientes y, luego, abre conexiones nuevas a los backends. En su lugar, un balanceador de cargas de red de transferencia interno enruta las conexiones directamente desde los clientes hacia los backends en buen estado, sin interrupciones. Las respuestas de las VMs de backend en buen estado se dirigen directamente a los clientes y no pasan a través del balanceador de cargas. Las respuestas de TCP usan el retorno directo del servidor. Para obtener más información, consulta Solicitud de TCP y UDP, y paquetes de retorno.

El balanceador de cargas supervisa el estado del backend a través de sondeos de verificación de estado. Para obtener más información, consulta la sección Verificación de estado.

El entorno invitado de Linux, el entorno invitado de Windows o un proceso equivalente de Google Cloud configuran cada VM de backend con la dirección IP del balanceador de cargas. En las VM creadas a partir de imágenes de Google Cloud, el agente invitado (anteriormente, el entorno invitado de Windows o el entorno de invitado de Linux) instala la ruta local para la dirección IP del balanceador de cargas. Las instancias de Google Kubernetes Engine basadas en Container-Optimized OS implementan esto mediante iptables en su lugar.

Las redes virtuales de Google Cloud administran la entrega y el escalamiento del tráfico según corresponda.

Protocolos, esquema y alcance

Cada balanceador de cargas de red de transferencia interno admite lo siguiente:

  • Un servicio de backend con esquema de balanceo de cargas INTERNAL y un protocolo compatible. Para obtener más información, consulta Servicio de backend.
  • VMs de backend especificadas como una de las siguientes opciones:
  • Compatibilidad con el tráfico IPv4 e IPv6 cuando se usan backends de grupos de instancias. Los grupos de extremos de red (NEG) zonales con extremos GCE_VM_IP solo admiten tráfico IPv4.
  • Una o más reglas de reenvío, cada una con el protocolo TCP, UDP, o L3_DEFAULT, que coincide con el protocolo del servicio de backend.
  • Cada regla de reenvío con su propia dirección IP única o varias reglas de reenvío que comparten una dirección IP común.
  • Cada regla de reenvío con hasta cinco puertos o todos los puertos.
  • Si el acceso global está habilitado, los clientes de cualquier región.
  • Si el acceso global está inhabilitado, los clientes en la misma región que el balanceador de cargas.

Un balanceador de cargas de red de transferencia interno no admite lo siguiente:

Acceso del cliente

De forma predeterminada, el balanceador de cargas solo admite clientes que se encuentren en la misma región que el balanceador de cargas. Los clientes pueden estar en la misma red que el balanceador de cargas o en una red de VPC conectada a través del intercambio de tráfico entre redes de VPC. Puedes habilitar el acceso global para permitir que los clientes de cualquier región accedan al balanceador de cargas de red de transferencia interno.

Balanceador de cargas de red interno con acceso global.
Balanceador de cargas de red de transferencia interno con acceso global (haz clic para ampliar).

En la siguiente tabla, se muestra un resumen del acceso del cliente.

Acceso global inhabilitado Acceso global habilitado
Los clientes deben estar en la misma región que el balanceador de cargas. También deben estar en la misma red de VPC que el balanceador de cargas o en una red de VPC que esté conectada a la red de VPC del balanceador de cargas mediante el intercambio de tráfico entre redes de VPC. Los clientes pueden estar en cualquier región. Aún deben estar en la misma red de VPC que el balanceador de cargas o en una red de VPC que esté conectada a la red de VPC del balanceador de cargas mediante el intercambio de tráfico entre redes de VPC.
Los clientes locales pueden acceder al balanceador de cargas a través de túneles de Cloud VPN o adjuntos de VLAN. Estos túneles o adjuntos deben estar en la misma región que el balanceador de cargas. Los clientes locales pueden acceder al balanceador de cargas a través de túneles de Cloud VPN o adjuntos de VLAN. Estos túneles o adjuntos pueden estar en cualquier región.

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:

  • Origen: la dirección IPv4 interna del cliente, IPv6 o la dirección IPv4 desde uno de los rangos de IPv4 de alias del cliente.
  • Destino: Es la dirección IP de la regla de reenvío del balanceador de cargas. La regla de reenvío usa una sola dirección IPv4 interna o un rango IPv6 interno.

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 no tiene conexión, por lo que las VM 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 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 Fuente Destino
TCP Es la dirección IP de la regla de reenvío del balanceador de cargas. Es el origen del paquete solicitante.
UDP 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.

† Es posible configurar el origen del paquete de respuesta como la dirección IPv4 interna principal de la NIC de la VM o un rango de direcciones IP de alias. Si la VM tiene habilitado el reenvío de IP, también se pueden usar fuentes de direcciones IP arbitrarias. 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 interna que no coincide con la dirección IP a la que envió un paquete de solicitud.

Arquitectura

Un balanceador de cargas de red de transferencia interno con múltiples backends distribuye conexiones entre todos esos backends. Para obtener más información sobre el método de distribución y las opciones de configuración, consulta Distribución de tráfico.

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 interno:

  • 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.

En Alta disponibilidad, se describe cómo diseñar un balanceador de cargas interno que no dependa de una sola zona.

Las instancias que participan como VMs de backend para balanceadores de cargas de red de transferencia internos deben ejecutar el entorno invitado de Linux o Windows adecuado o algún otro proceso que proporcione una funcionalidad equivalente. Este entorno invitado se debe poder comunicar con el servidor de metadatos (metadata.google.internal, 169.254.169.254) para leer los metadatos de la instancia a fin de generar rutas locales y aceptar el tráfico enviado a la dirección IP interna del balanceador de cargas.

En este diagrama, se ilustra la distribución de tráfico entre las VM ubicadas en dos grupos de instancias diferentes. El tráfico enviado de la instancia del cliente a la dirección IP del balanceador de cargas (10.10.10.9) se distribuye entre las VM de backend en cualquier grupo de instancias. Las respuestas enviadas de cualquiera de las VM de backend activas se entregan directamente a la VM de cliente.

Puedes usar un balanceador de cargas de red de transferencia interno con una red de VPC de modo personalizado o automático. También puedes crear balanceadores de cargas de red de transferencia internos con una red heredada existente.

Un balanceador de cargas de red de transferencia interno consta de los siguientes componentes de Google Cloud.

Componente Propósito Requisitos
Dirección IP interna Esta es la dirección del balanceador de cargas. La dirección IP interna debe estar en la misma subred que la regla de reenvío interna. La subred debe estar en la misma región y red de VPC que el servicio de backend.
Regla de reenvío interno Una regla de reenvío interno en combinación con la dirección IP interna es el frontend del balanceador de cargas. Define el protocolo y los puertos que acepta el balanceador de cargas y dirige el tráfico a un servicio de backend interno regional. Las reglas de reenvío para balanceadores de cargas de red de transferencia internos deben cumplir con los siguientes requisitos:
• Tener un load-balancing-scheme de INTERNAL.
• Usar un ip-protocol de TCP o UDP, que coincida con el protocol del servicio de backend
• Hacer referencia a una subnet en la misma red de VPC y región que el servicio de backend
Servicio de backend interno regional El servicio de backend interno regional define el protocolo que se usa para comunicarse con los backends y especifica una verificación de estado. Los backends pueden ser grupos de instancias no administrados, administrados zonales, administrados regionales o NEG zonales con extremos de GCE_VM_IP. El servicio de backend debe cumplir con los siguientes requisitos:
• Tener un load-balancing-scheme de INTERNAL
• Usar un protocol de TCP o UDP, que coincida con el ip-protocol de la regla de reenvío
• Tener una verificación de estado asociada
• Tener una región asociada. La regla de reenvío y todos los backends deben estar en la misma región que el servicio de backend
• Estar asociados con una sola red de VPC. Cuando no se especifica, la red se infiere en función de la red que usa cada interfaz de red predeterminada de VM de backend (nic0).

Aunque el servicio de backend no esté vinculado a una subred específica, la subred de la regla de reenvío debe estar en la misma red de VPC que el servicio de backend.
Verificación de estado Cada servicio de backend debe tener una verificación de estado asociada. La verificación de estado define los parámetros según los cuales Google Cloud considera que los backends que administra son aptos para recibir tráfico. Solo las VM de backend en buen estado reciben tráfico enviado de las VM cliente a la dirección IP del balanceador de cargas.
 Aunque la regla de reenvío y el servicio de backend pueden usar TCP o UDP, Google Cloud no tiene una verificación de estado para el tráfico de UDP. Para obtener más información, consulta Verificaciones de estado y tráfico de UDP.

Un balanceador de cargas de red de transferencia interno no admite lo siguiente:

Dirección IP interna

Los balanceadores de cargas de red de transferencia internos solo admiten subredes IPv4 (pila única) y, también, subredes IPv4 e IPv6 (pila doble). Para obtener más información, consulta Tipos de subredes.

Un balanceador de cargas de red de transferencia interno requiere al menos una regla de reenvío. La regla de reenvío hace referencia a la dirección IP interna:

  • Para el tráfico IPv4, la regla de reenvío hace referencia a una dirección IPv4 del rango de subred IPv4 principal.
  • Para el tráfico IPv6, la regla de reenvío hace referencia a un rango /96 de direcciones IPv6 internas del rango de direcciones IPv6 interno /64 de la subred. La subred debe ser de pila doble con un rango de direcciones IPv6 interno (ipv6-access-type configurado como INTERNAL).

Configuración de firewall

Los balanceadores de cargas de red de transferencia internos requieren la siguiente configuración para las políticas de firewall jerárquicas y las reglas de firewall de VPC:

Para obtener más información, consulta Configura las reglas de firewall.

Reglas de reenvío

Una regla de reenvío especifica el protocolo y los puertos en los que el balanceador de cargas acepta el tráfico. Debido a que los balanceadores de cargas de red de transferencia de internos no son proxies, pasan el tráfico a los backends en el mismo protocolo y puerto.

Un balanceador de cargas de red de transferencia interno requiere al menos una regla de reenvío interno. Puedes definir varias reglas de reenvío para el mismo balanceador de cargas.

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.

La regla de reenvío debe hacer referencia a una subred específica en la misma red de VPC y región que los componentes de backend del balanceador de cargas. Este requisito tiene las siguientes implicaciones:

  • No es necesario que la subred que especificas para la regla de reenvío sea la misma que las subredes que usan las VM de backend. Sin embargo, la subred debe estar en la misma región que la regla de reenvío.
  • Para el tráfico IPv4, la regla de reenvío interno hace referencia a la dirección IPv4 interna regional del rango de direcciones IPv4 principal de la subred que selecciones. Esta dirección IPv4 se puede seleccionar de forma automática o puedes usar una dirección IPv4 estática (reservada).
  • Para el tráfico IPv6, la regla de reenvío hace referencia a un rango /96 de direcciones IPv6 del rango de direcciones IPv6 interno de la subred. La subred debe ser de pila doble con ipv6-access-type configurado como INTERNAL. El rango de direcciones IPv6 /96 se asigna de forma automática o puedes usar una dirección IP interna reservada.

Protocolos de reglas de reenvío

Los balanceadores de cargas de red de transferencia internos admiten las siguientes opciones de protocolo IPv4 para cada regla de reenvío: TCP, UDP o L3_DEFAULT.

Los balanceadores de cargas de red de transferencia internos admiten las siguientes opciones de protocolo IPv6 para cada regla de reenvío: TCP o UDP.

La opción L3_DEFAULT te permite balancear las cargas de protocolos TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH y GRE.

Además de admitir protocolos que no sean TCP ni UDP, la opción L3_DEFAULT permite que una sola regla de reenvío reenvíe el tráfico de forma simultánea para varios protocolos. Por ejemplo, además de realizar solicitudes HTTP, también puedes hacer ping a la dirección IP del balanceador de cargas.

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 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 (IPv4 o IPv6) TCP TCP or UNSPECIFIED
UDP (IPv4 o IPv6) UDP UDP or UNSPECIFIED
TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH y GRE L3_DEFAULT UNSPECIFIED

Reglas de reenvío y acceso global

Las reglas de reenvío del balanceador de cargas de red interno son regionales, incluso cuando el acceso global está habilitado. Después de habilitar el acceso global, la marca allowGlobalAccess de la regla de reenvío interno regional se configura como true.

Reglas de reenvío y especificaciones de puertos

Cuando creas una regla de reenvío interno, debes elegir una de las siguientes especificaciones de puerto:

  • Especifica al menos un puerto (hasta cinco) por número
  • Especifica ALL para reenviar el tráfico a todos los puertos.

Una regla de reenvío interno que admite todos los puertos TCP o UDP permite que las VM de backend ejecuten varias aplicaciones, cada una en su propio puerto. El tráfico enviado a un puerto determinado se entrega a la aplicación correspondiente, y todas las aplicaciones usan la misma dirección IP.

Cuando necesites reenviar el tráfico a más de cinco puertos específicos, combina las reglas de firewall con las reglas de reenvío. Cuando crees la regla de reenvío, especifica todos los puertos y, luego, crea las reglas de firewall de entrada allow que solo permiten el tráfico en los puertos deseados. Aplica las reglas de firewall a las VM de backend.

No puedes modificar una regla de reenvío después de crearla. Si necesitas cambiar los puertos especificados o la dirección IP interna de una regla de reenvío interno, debes borrarla y volver a crearla.

Varias reglas de reenvío para un solo servicio de backend

Puedes configurar varias reglas de reenvío interno que todas hagan referencia al mismo servicio de backend interno. Un balanceador de cargas de red de transferencia interno requiere al menos una regla de reenvío interno.

Configurar varias reglas de reenvío para el mismo servicio de backend te permite hacer lo siguiente:

  • Asignar varias direcciones IP al balanceador de cargas. Puedes crear varias reglas de reenvío, cada una con una dirección IP única. Cada regla de reenvío puede especificar todos los puertos o un conjunto de hasta cinco puertos.

  • Asignar un conjunto específico de puertos con la misma dirección IP al balanceador de cargas. Puedes crear varias reglas de reenvío que compartan la misma dirección IP, y cada regla de reenvío debe usar un conjunto específico de hasta cinco puertos. Esta es una alternativa a la configuración de una sola regla de reenvío que especifique todos los puertos.

Para obtener más información sobre situaciones que involucren dos o más reglas de reenvío interno que compartan una dirección IP interna común, consulta Varias reglas de reenvío con la misma dirección IP.

Cuando uses varias reglas de reenvío interno, asegúrate de configurar el software que se ejecuta en las VMs de backend para vincular a todas las direcciones IP de la regla de reenvío o a cualquier dirección (0.0.0.0/0 para IPv4 o ::/0 para IPv6). La dirección IP de destino de un paquete entregado a través del balanceador de cargas es la dirección IP interna asociada con la regla de reenvío interno correspondiente. Para obtener más información, consulta Solicitud de TCP y UDP, y paquetes de retorno.

Servicio de backend

Cada balanceador de cargas de red de transferencia interno tiene un servicio de backend interno regional que define los parámetros y el comportamiento de backend. El nombre del servicio de backend es el nombre del balanceador de cargas de red de transferencia de interno 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 admite el tráfico IPv4 e IPv6. Si el protocolo tiene un concepto de un puerto (como TCP o UDP), el servicio de backend entrega paquetes a las VM de backend en el mismo puerto de destino al que se envió el tráfico.

    Los servicios de backend admiten las siguientes opciones de protocolo IPv4: TCP, UDP o UNSPECIFIED.

    Los servicios de backend admiten las siguientes opciones de protocolo IPv6: TCP o UDP. El protocolo del servicio de backend debe coordinar con el protocolo de la regla de reenvío.

    Para obtener una tabla con posibles combinaciones de protocolos de reglas de reenvío y servicios de backend, consulta Especificación del protocolo de reglas de reenvío.

  • Distribución de tráfico. Un servicio de backend permite distribuir el tráfico de acuerdo con una afinidad de sesión configurable.

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

Cada servicio de backend opera en una sola región y distribuye el tráfico para las VM de backend en una sola red de VPC:

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.

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.

Especificación de la red del servicio de backend

Puedes asociar de forma explícita una red de VPC con un servicio de backend mediante la marca --network cuando creas el servicio de backend. Las reglas de red del servicio de backend entran en vigor de inmediato.

Si omites la marca --network cuando creas un servicio de backend, Google Cloud usa uno de los siguientes eventos aptos para configurar de forma implícita la red de VPC asociada del servicio de backend. Una vez configurada, no se puede cambiar la red de VPC asociada del servicio de backend:

  • Si el servicio de backend aún no tiene ningún backend asociado y configuras la primera regla de reenvío para hacer referencia al servicio de backend, Google Cloud establece la red de VPC asociada del servicio de backend en la red de VPC que contiene la subred utilizada por esta regla de reenvío.

  • Si el servicio de backend aún no tiene una regla de reenvío que hace referencia a él y agregas el primer backend de grupo de instancias al servicio de backend, Google Cloud establece la red de VPC del servicio de backend como la VPC asociada con ese primer backend de grupo de instancias. Esto significa que la red de VPC asociada del servicio de backend es la red que usa la interfaz de red nic0 de cada VM en el primer backend del grupo de instancias.

  • Si el servicio de backend aún no tiene una regla de reenvío que hace referencia a él y agregas el primer backend de NEG zonal (con extremos GCE_VM_IP) al servicio de backend, Google Cloud establece la red de VPC del servicio de backend como la red de VPC asociada con ese primer backend de NEG.

Después de que la red de VPC del servicio de backend se haya configurado por un evento de calificación, cualquier regla de reenvío adicional, grupo de instancias de backend o NEG zonales de backend que agregues debe seguir las reglas de red del servicio de backend.

Reglas de red del servicio de backend

Las siguientes reglas se aplican después de que un servicio de backend se asocia con una red de VPC específica:

  • Cuando configuras una regla de reenvío para hacer referencia al servicio de backend, esta debe usar una subred de la red de VPC del servicio de backend. La regla de reenvío y el servicio de backend no pueden usar diferentes redes de VPC, incluso si esas redes están conectadas mediante el intercambio de tráfico entre redes de VPC.

  • Cuando se agregan backends de grupos de instancias, se debe cumplir uno de los siguientes valores:

    • La red de VPC asociada con el grupo de instancias (es decir, la red de VPC que usa la interfaz de red nic0 de cada VM en el grupo de instancias) debe coincidir con la red de VPC asociada La red de VPC.
    • Cada VM de backend debe tener una interfaz que no sea nic0 (de nic1 a nic7) en la red de VPC asociada con el servicio de backend.

  • Cuando se agregan backends de NEG zonales con extremos GCE_VM_IP, la red de VPC asociada con el NEG debe coincidir con la red de VPC asociada con el servicio de backend.

Subconjuntos de backend

La subdivisión del backend es una característica opcional que mejora el rendimiento cuando limitas la cantidad de backends a los que se distribuye el tráfico.

Solo debes habilitar la subdivisión si necesitas admitir más de 250 VM de backend en un solo balanceador de cargas. Si deseas obtener más información, consulta Subconjunto del backend para el balanceador de cargas de red de transferencia interno.

Verificación de estado

El servicio de backend del balanceador de cargas debe estar asociado con una verificación de estado global o regional. Las rutas especiales fuera de la red de VPC facilitan la comunicación entre los sistemas de verificación de estado y los backends.

Puedes usar una verificación de estado existente o definir una nueva. Los balanceadores de cargas de TCP/UDP internos usan el estado de verificación de estado para determinar cómo enrutar conexiones nuevas, como se describe en la sección Distribución de tráfico.

Puedes usar cualquiera de los siguientes protocolos de verificación de estado; el protocolo de la verificación de estado no tiene que coincidir con el protocolo del balanceador de cargas:

  • HTTP, HTTPS o HTTP/2. Si las VM de backend entregan tráfico mediante HTTP, HTTPS o HTTP/2, es mejor usar una verificación de estado que coincida con ese protocolo debido a que las verificaciones de estado basadas en HTTP ofrecen opciones adecuadas para ese protocolo. La entrega de tráfico de tipo HTTP a través de un balanceador de cargas de red de transferencia interno significa que el protocolo del balanceador de cargas es TCP.
  • SSL o TCP. Si las VM de backend no entregan tráfico de tipo HTTP, debes usar una verificación de estado de SSL o TCP.

Sin importar el tipo de verificación de estado que crees, Google Cloud envía sondeos de verificación de estado a la dirección IP de la regla de reenvío del balanceador de cargas de red de transferencia interno a la interfaz de red en la red de VPC que selecciona el servicio de backend del balanceador de cargas. Esto simula la forma en que se entrega el tráfico con balanceo de cargas. El software que se ejecuta en las VMs de backend debe responder al tráfico con el balanceo de cargas y a los sondeos de verificación de estado enviados a la dirección IP de cada regla de reenvío (el software debe escuchar en 0.0.0.0:<port> y no en una dirección IP específica asignada a una interfaz de red). Si deseas obtener más información, consulta Destino para paquetes de sondeo.

Verificaciones de estado y tráfico UDP

Google Cloud no ofrece una verificación de estado que use el protocolo UDP. Cuando usas un balanceador de cargas de red de transferencia interno con tráfico UDP, debes ejecutar un servicio basado en TCP en las VMs de backend para proporcionar información de verificación de estado.

En esta configuración, se balancean las cargas de las solicitudes del cliente mediante el protocolo UDP y se usa un servicio de TCP para proporcionar información a los sistemas de sondeo de verificación de estado de Google Cloud. Por ejemplo, puedes ejecutar un servidor HTTP simple en cada VM de backend que muestre una respuesta HTTP 200 a Google Cloud. En este ejemplo, 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.

Arquitectura con alta disponibilidad

El balanceador de cargas de red de transferencia interno está diseñado con alta disponibilidad. No existen pasos especiales para hacer que el balanceador de cargas tenga alta disponibilidad porque el mecanismo no depende de un solo dispositivo o instancia de VM.

Para asegurarte de que las instancias de VM de backend se implementen en varias zonas, sigue estas recomendaciones de implementación:

  • 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.

  • Si usas grupos de instancias no administrados o administrados zonales, usa varios grupos de instancias en diferentes zonas (en la misma región) para el mismo servicio de backend. Usar varias zonas te protege de posibles problemas en cualquier zona.

Arquitectura de VPC compartida

En la siguiente tabla, se resumen los requisitos de los componentes para los balanceadores de cargas de red de transferencia internos que se usan con redes de VPC compartidas. Para ver un ejemplo, consulta Crea un balanceador de cargas de red de transferencia interno en la página Aprovisiona la VPC compartida.

Dirección IP Regla de reenvío Componentes de backend
Debe definirse una dirección IP interna en el mismo proyecto que las VM de backend.

Para que el balanceador de cargas esté disponible en una red de VPC compartida, la dirección IP interna de Google Cloud debe definirse en el mismo proyecto de servicio en el que se encuentran las VM de backend y debe hacer referencia a una subred en la red de VPC compartida deseada en el proyecto host. La dirección en sí proviene del rango de IP principal de la subred a la que se hace referencia.

Si creas una dirección IP interna en un proyecto de servicio y la subred de la dirección IP se encuentra en la red de VPC del proyecto de servicio, el balanceador de cargas de red de transferencia interno es local para el proyecto de servicio. No es local para ningún proyecto host de VPC compartida.		 Se debe definir una regla de reenvío interna en el mismo proyecto que las VM de backend.

Para que el balanceador de cargas esté disponible en una red de VPC compartida, la regla de reenvío interno debe definirse en el mismo proyecto de servicio en el que se encuentran las VM de backend y debe hacer referencia a la misma subred (en la red de VPC compartida) a la que hace referencia la dirección IP interna asociada.

Si creas una regla de reenvío interno en un proyecto de servicio y la subred de la regla de reenvío se encuentra en la red de VPC del proyecto de servicio, el balanceador de cargas de red de transferencia interno es local para el proyecto de servicio. No es local para ningún proyecto host de VPC compartida.		 En una situación de VPC compartida, las VM de backend se ubican en un proyecto de servicio. En ese proyecto de servicio, debe definirse un servicio de backend interno regional y una verificación de estado.

Distribución del tráfico

La forma en que un balanceador de cargas de red de transferencia interno distribuye 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 interno distribuye las conexiones nuevas a las 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 las conexiones nuevas 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 interno distribuye las conexiones nuevas entre las VMs en su grupo activo, según una 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 se configura para abandonar tráfico.

El método para distribuir conexiones nuevas depende de la configuración de afinidad de sesión del balanceador de cargas.

Con la verificación de estado se controla la distribución de conexiones nuevas. De forma predeterminada, las conexiones TCP persisten en backends en mal estado. Para obtener más detalles y cómo cambiar este comportamiento, consulta Persistencia de conexiones en backends en mal estado.

Selección de backend y seguimiento de conexiones

Los balanceadores de cargas de red de transferencia internos 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 internos 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. El balanceador de cargas usa este hash para seleccionar un backend:

      • Si al menos un backend está en buen estado, el hash selecciona uno de los backends en buen estado.
      • Si todos los backends están en mal estado y no hay una política de conmutación por error configurada, el hash selecciona uno de los backends.
      • Si todos los backends están en mal estado, hay una política de conmutación por error configurada y la política de conmutación por error no está configurada para descartar tráfico en esta situación, el hash selecciona uno de los backends de VM principales.

      La afinidad de sesión predeterminada, NONE, usa 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.

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

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

      Para los paquetes TCP y UDP, 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 el hash de seguimiento de conexión es de 5 tuplas, los paquetes TCP SYN siempre crean una entrada nueva en la tabla de seguimiento de conexiones.

      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.

      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:

      • De forma predeterminada, una entrada en la tabla de seguimiento de conexiones vence 600 segundos después de que el balanceador de cargas procesa el último paquete que coincidió con la entrada. Si deseas obtener detalles para personalizar el tiempo de espera de inactividad, consulta Tiempo de espera de inactividad.
      • 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. Configura la afinidad de sesión cuando las VM de backend necesiten realizar un seguimiento de la información de estado de sus clientes. Este es un requisito común para las aplicaciones web.

La afinidad de sesión funciona según el criterio del mejor esfuerzo.

Los balanceadores de cargas de red de transferencia internos admiten las siguientes opciones de afinidad de sesión, que se especifican para todo el servicio de backend interno, no para cada grupo de instancias de backend.

  • 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, sin destino (CLIENT_IP_NO_DESTINATION). Hash de 1 tupla creado solo a partir de la dirección IP de origen.
  • IP de cliente (CLIENT_IP). Hash de 2 tuplas de la dirección IP de origen y la dirección IP de destino. Los balanceadores de cargas de red de transferencia externos llaman a esta opción de afinidad de sesión IP de cliente, IP de 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

A menos que uses el balanceador de cargas como el siguiente salto para una ruta estática personalizada, la dirección IP de destino de un paquete debe coincidir con la dirección IP de la regla de reenvío del balanceador de cargas a fin de que el paquete se entregue al balanceador de cargas. Para las consideraciones de uso del balanceador de cargas como salto siguiente para una ruta estática personalizada, afinidad de sesión y balanceador de cargas de red de transferencia interno de próximo salto.

Afinidad de sesión y balanceador de cargas de red de transferencia interno de próximo salto

Cuando configuras una ruta estática para usar un balanceador de cargas de red de transferencia interno de próximo salto, el balanceador de cargas usa el mismo método de selección de backend y seguimiento de conexiones que se analizó anteriormente. La selección del backend aún se realiza mediante el cálculo de un hash de acuerdo con la afinidad de sesión configurada. Excepto por la afinidad de sesión CLIENT_IP_NO_DESTINATION, el hash de selección de backend depende, en parte, de la dirección IP de destino del paquete.

Cuando un balanceador de cargas de red de transferencia interno es un próximo salto de una ruta estática, la dirección IP de destino no se limita a la dirección IP de la regla de reenvío del balanceador de cargas. En cambio, la dirección IP de destino del paquete puede ser cualquier dirección IP que se ajuste al rango de destino de la ruta estática.

Si la cantidad de VMs de backend configuradas y en buen estado es constante (cuando la conmutación por error no está configurada o, cuando está configurada, pero no se producen eventos de conmutación por error ni de recuperación), el balanceador de cargas se comporta de la siguiente manera:

  • Si solo hay una VM de backend configurada y en buen estado (en el grupo activo, si la conmutación por error está configurada), no importa qué afinidad de sesión uses, ya que todos los hash se asignan a la única VM de backend.

  • Si hay dos o más VMs de backend configuradas y en buen estado (en el grupo activo, si la conmutación por error está configurada), la afinidad de sesión es importante:

    • Si necesitas la misma VM de backend para procesar todos los paquetes de un cliente, en función solo de la dirección IP de origen del paquete, sin importar las direcciones IP de destino del paquete, usa la afinidad de sesión CLIENT_IP_NO_DESTINATION. Según los patrones de tráfico, algunas VMs de backend pueden recibir más paquetes o más conexiones que otras.

    • Si usas una opción de afinidad de sesión que no sea CLIENT_IP_NO_DESTINATION, el balanceador de cargas selecciona una VM de backend según la información que, al menos, incluya ambas direcciones IP: la de origen y la de destino del paquete. Los paquetes que se envían desde el mismo cliente, con la misma dirección IP de origen, pero con diferentes direcciones IP de destino, se pueden enrutar a diferentes VMs de backend.

Modo de seguimiento de conexiones

El modo de seguimiento especifica el algoritmo de seguimiento de conexión que se usará. Hay dos modos de seguimiento: PER_CONNECTION (predeterminado) y PER_SESSION.

  • PER_CONNECTION (predeterminado). En este modo, siempre se realiza un seguimiento del tráfico de TCP y UDP por 5 tuplas, sin importar la configuración de afinidad de sesión. Esto implica que la clave para el seguimiento de conexión (5 tuplas) puede ser diferente de la configuración configurada de afinidad de sesión (por ejemplo, 3 tuplas con la configuración CLIENT_IP_PROTO). Como resultado, la afinidad de la sesión puede dividirse y las conexiones nuevas de una sesión pueden seleccionar un backend diferente si el conjunto de backends o su estado cambian.

  • PER_SESSION. En este modo, se realiza un seguimiento del tráfico de TCP y UDP según la afinidad de sesión configurada. Es decir, 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 conexión de 2 o 3 tuplas, respectivamente. Esto puede ser conveniente en situaciones en las que la afinidad de interrupción es costosa y debe evitarse incluso después de agregar más backends.

La configuración del modo de seguimiento de conexión es redundante si la afinidad de sesión se establece en NONE o CLIENT_IP_PORT_PROTO. 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

 Hash de 5 tuplas Seguimiento de conexión de 5 tuplas Seguimiento de conexión de 5 tuplas

IP de cliente, sin destino

CLIENT_IP_NO_DESTINATION

 Hash de 1 tupla Seguimiento de conexión de 5 tuplas Seguimiento de conexión de 1 tupla

IP de cliente

CLIENT_IP

(igual que la IP de cliente, la IP de destino para los balanceadores de cargas de red de transferencia externos)

 Hash de 2 tuplas Seguimiento de conexión de 5 tuplas Seguimiento de conexión de 2 tuplas

IP de cliente, IP de destino, protocolo

CLIENT_IP_PROTO

 Hash de 3 tuplas Seguimiento de conexión de 5 tuplas Seguimiento de conexión de 3 tuplas

IP de cliente, puerto de cliente, IP de destino, puerto de destino, protocolo

CLIENT_IP_PORT_PROTO

 Hash de 5 tuplas Seguimiento de conexión de 5 tuplas Seguimiento de conexión de 5 tuplas

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 persistencia de la conexión en la configuración de backends en mal estado controla si una conexión existente persiste en un backend seleccionado después de que ese backend esté en mal estado (siempre y cuando el backend permanezca en el grupo de instancias de backend configurado del balanceador de cargas).

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

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

  • DEFAULT_FOR_PROTOCOL (predeterminada)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

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

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

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

UDP: Las conexiones nunca se conservan 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.

UDP: Las conexiones nunca se conservan en backends en mal estado.
NEVER_PERSIST TCP, UDP: Las conexiones nunca se conservan en backends en mal estado.
ALWAYS_PERSIST

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

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

 No es posible realizar la configuración.

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.

Tiempo de espera inactivo

De forma predeterminada, una entrada en la tabla de seguimiento de conexiones vence 600 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 predeterminado solo se puede modificar cuando el seguimiento de conexión es inferior a 5 tuplas (es decir, cuando la afinidad de sesión está configurada para CLIENT_IP o CLIENT_IP_PROTO) y el modo de seguimiento es PER_SESSION).

El valor de tiempo de espera de inactividad máximo configurable es de 57,600 segundos (16 horas).

Si deseas obtener información para cambiar el valor de tiempo de espera de inactividad, consulta Configura una política de seguimiento de conexiones.

Prueba conexiones de un solo cliente

Cuando se prueban las conexiones a la dirección IP de un balanceador de cargas de red de transferencia interno desde un único sistema cliente, debes tener en cuenta lo siguiente:

  • Si el sistema cliente no es una VM cuyas cargas se balancean, es decir, no es una VM de backend, las conexiones nuevas se entregan a las VM de backend en buen estado del balanceador de cargas. Sin embargo, debido a que todas las opciones de afinidad de sesión dependen de al menos la dirección IP del sistema cliente, es posible que las conexiones del mismo cliente se distribuyan a la misma VM de backend con mayor frecuencia de lo esperado.

    Esto significa que no puedes supervisar con precisión la distribución de tráfico a través de un balanceador de cargas de red de transferencia interno si te conectas a este desde un solo cliente. La cantidad de clientes que se necesita para supervisar la distribución de tráfico varía según el tipo de balanceador de cargas, el tipo de tráfico y la cantidad de backends en buen estado.

  • Si la VM de cliente es una VM de backend del balanceador de cargas, la VM de cliente o backend siempre responde a las conexiones enviadas a la dirección IP de la regla de reenvío del balanceador de cargas. Esto sucede sin importar si la VM de backend está en buen estado. Sucede en todo el tráfico enviado a la dirección IP del balanceador de cargas, no solo en el tráfico del protocolo y los puertos especificados en la regla de reenvío interno del balanceador de cargas.

    Para obtener más información, consulta Envía solicitudes desde VM con balanceo de cargas.

Fragmentación UDP

Los balanceadores de cargas de red de transferencia internos 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 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.

Conmutación por error

Un balanceador de cargas de red de transferencia interno te permite designar algunos backends como backends de conmutación por error. Estos backends solo se usan cuando la cantidad de VM en buen estado en los grupos de instancias de backend principales disminuye por debajo de un umbral configurable. De forma predeterminada, si todas las VM principales y de conmutación por error están en mal estado, como último recurso, Google Cloud distribuirá nuevas conexiones solo entre todas las VM principales.

Cuando agregas un backend a un servicio de backend del balanceador de cargas de red de transferencia interno, de forma predeterminada, ese backend es uno primario. 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 una descripción general conceptual detallada de la conmutación por error en los balanceadores de cargas de red de transferencia internos, consulta Conmutación por error para balanceadores de cargas de red de transferencia internos.

Cuotas y límites

Para obtener información sobre las cuotas y los límites, consulta Cuotas de recursos del balanceo de cargas.

Limitaciones

  • No puedes usar la consola de Google Cloud para crear un balanceador de cargas de red de transferencia interno con backends de NEG zonales.

¿Qué sigue?