Descripción general del balanceador de carga de red de paso a través interno

Un balanceador de carga de red de paso a través interno es un balanceador de carga regional creado en la pila de virtualización de redes de Andromeda.

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

Usa un balanceador de carga de red de paso a través interno en las siguientes circunstancias:

  • Necesitas un balanceador de carga de capa 4 de alto rendimiento y de transferencia para los protocolos TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH y GRE.
  • Si sirve tráfico a través de TLS (SSL), puede hacer que sus backends terminen el tráfico SSL en lugar del balanceador de carga. El balanceador de carga de red de paso a través interno no puede finalizar el tráfico SSL.
  • Debes reenviar los paquetes originales sin proxy. Por ejemplo, si necesitas que se conserve la dirección IP de origen del cliente.
  • Tienes una configuración que usa un balanceador de carga de paso a través y quieres migrarla sin hacer cambios.

Los balanceadores de carga de red de paso a través internos se adaptan a muchos casos prácticos. Para ver algunos ejemplos generales, consulta el resumen del balanceador de carga de red de paso a través.

Cómo funcionan los balanceadores de carga de red de paso a través internos

Un balanceador de carga de red de paso a través interno tiene un frontend (la regla de reenvío) y un backend (el servicio de backend). Puedes usar grupos de instancias o GCE_VM_IP NEGs de zona como backends en el servicio de backend. En este ejemplo se muestran backends de grupos de instancias.

Ejemplo de balanceador de carga de red de paso a través interno de alto nivel.
Ejemplo de alto nivel de balanceador de carga de red de paso a través interno (haz clic para ampliar).

A diferencia de un balanceador de carga de proxy, un balanceador de carga de red de paso a través interno no finaliza las conexiones de los clientes y, a continuación, abre nuevas conexiones con los back-ends. En su lugar, un balanceador de carga de red interno de tipo pasarela enruta las conexiones directamente desde los clientes a los backends en buen estado, sin interrupciones. Las respuestas de las VMs de backend en buen estado van directamente a los clientes, no vuelven a pasar por el balanceador de carga. Las respuestas TCP usan el servidor directo return. Para obtener más información, consulta Paquetes de solicitud y respuesta TCP y UDP.

El balanceador de carga monitoriza el estado del backend mediante comprobaciones del estado. Para obtener más información, consulta la sección Comprobación del estado.

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

LaGoogle Cloud red virtual gestiona la entrega del tráfico y el escalado según sea necesario.

Protocolos, esquemas y ámbitos

Cada balanceador de carga de red de paso a través interno admite lo siguiente:

  • Un servicio de backend con el esquema de balanceo de carga INTERNAL y un protocolo compatible. Para obtener más información, consulta Servicio backend.
  • Las VMs de backend se especifican de una de las siguientes formas:
  • Compatibilidad con el tráfico IPv4 e IPv6 al usar backends de grupos de instancias. Los grupos de puntos finales de red (NEGs) por zonas con GCE_VM_IP puntos finales solo admiten tráfico IPv4.
  • Una o varias reglas de reenvío, cada una de ellas con el protocolo TCP, UDP o L3_DEFAULT, que coincida 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 compartan 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 se encuentran en la misma región que el balanceador de carga.

Un balanceador de carga de red de paso a través interno no admite lo siguiente:

Acceso de cliente

De forma predeterminada, el balanceador de carga solo admite clientes que se encuentren en la misma región que el balanceador de carga. Los clientes pueden estar en la misma red que el balanceador de carga o en una red de VPC conectada mediante el emparejamiento entre redes de VPC. Puedes habilitar el acceso global para permitir que los clientes de cualquier región accedan a tu balanceador de carga de red con paso a través interno.

Balanceador de carga de red de paso a través interno con acceso global.
Balanceador de carga de red de paso a través interno con acceso global (haz clic para ampliar).

En la siguiente tabla se resume el acceso de los clientes.

Acceso global inhabilitado Acceso global habilitado
Los clientes deben estar en la misma región que el balanceador de carga. También deben estar en la misma red de VPC que el balanceador de carga o en una red de VPC conectada a la red de VPC del balanceador de carga mediante el emparejamiento entre redes de VPC. Los clientes pueden estar en cualquier región. Sin embargo, deben estar en la misma red de VPC que el balanceador de carga o en una red de VPC conectada a la red de VPC del balanceador de carga mediante el emparejamiento entre redes de VPC.
Los clientes on‐premise pueden acceder al balanceador de carga a través de túneles de Cloud VPN o vinculaciones de VLAN. Estos túneles o adjuntos deben estar en la misma región que el balanceador de carga. Los clientes locales pueden acceder al balanceador de carga a través de túneles de Cloud VPN o vinculaciones de VLAN. Estos túneles o archivos adjuntos pueden estar en cualquier región.

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 IPv4 o IPv6 interna del cliente, o la dirección IPv4 de uno de los intervalos de IPv4 de alias del cliente.
  • Destino: la dirección IP de la regla de reenvío del balanceador de carga. La regla de reenvío usa una sola dirección IPv4 interna o un intervalo IPv6 interno.

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 no tiene conexión, por lo que las VMs 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 asignada a la VM. 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 En la mayoría de los casos, la dirección IP de la regla de reenvío del balanceador de carga 1 Origen del paquete solicitante

1 Es posible definir el origen del paquete de respuesta como la dirección IPv4 interna principal de la NIC de la VM o un intervalo 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 un caso avanzado, ya que 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 carga de red de paso a través interno con varios backends distribuye las conexiones entre todos esos backends. Para obtener información sobre el método de distribución y sus opciones de configuración, consulta Distribución del tráfico.

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

  • Si eliges grupos de instancias, puedes usar grupos de instancias sin gestionar, 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.

La alta disponibilidad describe cómo diseñar un balanceador de carga interno que no dependa de una sola zona.

Las instancias que participan como VMs de backend de balanceadores de carga de red internos de tipo pasarela deben ejecutar el entorno de invitado de Linux o Windows adecuado u otros procesos que proporcionen una funcionalidad equivalente. Este entorno de invitado debe poder ponerse en contacto con el servidor de metadatos (metadata.google.internal, 169.254.169.254) para leer los metadatos de la instancia y, de este modo, generar rutas locales para aceptar el tráfico enviado a la dirección IP interna del balanceador de carga.

Este diagrama muestra la distribución del tráfico entre las VMs ubicadas en dos grupos de instancias independientes. El tráfico enviado desde la instancia de cliente a la dirección IP del balanceador de carga (10.10.10.9) se distribuye entre las VMs de backend de cualquiera de los grupos de instancias. Las respuestas enviadas desde cualquiera de las VMs backend de servicio se envían directamente a la VM cliente.

Puedes usar un balanceador de carga de red interno de tipo pasarela con una red de VPC en modo personalizado o automático. También puedes crear balanceadores de carga de red de paso a través internos con una red antigua.

Un balanceador de carga de red de paso a través interno no admite lo siguiente:

Dirección IP interna

Los balanceadores de carga de red de paso a través internos admiten subredes solo IPv4, de pila dual y solo IPv6. Para obtener más información sobre cada una de ellas, consulta Tipos de subredes.

Un balanceador de carga de red de paso a través interno requiere al menos una regla de reenvío. La regla de reenvío hace referencia a la dirección IP interna:

  • En el caso del tráfico IPv4, la regla de reenvío hace referencia a una dirección IPv4 del intervalo de la subred IPv4 principal.

  • En el caso del tráfico IPv6, la regla de reenvío hace referencia a un intervalo /96 de direcciones IPv6 internas del intervalo de direcciones IPv6 internas /64 de la subred. La subred debe ser de doble pila o de pila única solo IPv6 con un intervalo de direcciones IPv6 interno (ipv6-access-type definido como INTERNAL). El intervalo de direcciones IPv6 puede ser una dirección estática reservada o una dirección efímera.

    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.

Configuración del cortafuegos

Los balanceadores de carga de red de pases internos requieren la siguiente configuración para las políticas de cortafuegos jerárquicas y las reglas de cortafuegos de VPC:

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

Reglas de reenvío

Una regla de reenvío especifica el protocolo y los puertos en los que el balanceador de carga acepta tráfico. Como los balanceadores de carga de red de paso a través internos no son proxies, envían tráfico a los backends con el mismo protocolo y puerto.

Un balanceador de carga de red de paso a través interno requiere al menos una regla de reenvío interno. Puedes definir varias reglas de reenvío para el mismo balanceador de carga.

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.

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

  • La subred que especifiques para la regla de reenvío no tiene por qué ser la misma que ninguna de las subredes que utilicen las VMs de backend. Sin embargo, la subred debe estar en la misma región que la regla de reenvío.
  • En el caso del tráfico IPv4, la regla de reenvío interna hace referencia a una dirección IPv4 interna regional del intervalo de direcciones IPv4 principal de la subred que selecciones. Esta dirección IPv4 se puede seleccionar automáticamente o puedes usar una dirección IPv4 estática (reservada).
  • En el caso del tráfico IPv6, la regla de reenvío hace referencia a un intervalo /96 de direcciones IPv6 del intervalo de direcciones IPv6 internas /64 de la subred. La subred debe ser una subred de pila dual con el valor ipv6-access-type definido como INTERNAL. El intervalo de direcciones IPv6 /96 se asigna automáticamente o puedes usar una dirección IP interna reservada.

Protocolos de reglas de reenvío

Los balanceadores de carga de red de paso a través internos admiten las siguientes opciones de protocolo IPv4 para cada regla de reenvío: TCP, UDP o L3_DEFAULT.

Los balanceadores de carga de red de paso a través 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 la carga de los protocolos TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH y GRE.

Además de admitir protocolos distintos de TCP y UDP, la opción L3_DEFAULT permite que una sola regla de reenvío reenvíe simultáneamente el tráfico de varios protocolos. Por ejemplo, además de enviar solicitudes HTTP, también puedes hacer ping a la dirección IP del balanceador de carga.

Las reglas de reenvío que usan los protocolos TCP o UDP pueden hacer referencia a un servicio de backend usando el mismo protocolo que la regla de reenvío o un servicio de backend que use el protocolo UNSPECIFIED.

Si usas el protocolo L3_DEFAULT, debes configurar la regla de reenvío para que acepte el 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 en diferentes protocolos:

Tráfico que se va a balancear Protocolo de la 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 de un balanceador de carga de red con paso a través 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 define como true.

Reglas de reenvío y especificaciones de puertos

Cuando cree una regla de reenvío interna, debe elegir una de las siguientes especificaciones de puerto:

  • Especifica entre uno y cinco puertos, por número.
  • Especifica ALL para reenviar el tráfico de todos los puertos.

Una regla de reenvío interna que admita todos los puertos TCP o todos los puertos UDP permite que las VMs 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.

Si necesitas reenviar tráfico en más de cinco puertos específicos, combina las reglas de cortafuegos con las reglas de reenvío. Cuando crees la regla de reenvío, especifica todos los puertos y, a continuación, crea reglas de cortafuegos de entrada allow que solo permitan el tráfico a los puertos deseados. Aplica las reglas de cortafuegos a las VMs de backend.

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

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

Puede configurar varias reglas de reenvío internas que hagan referencia al mismo servicio de backend interno. Un balanceador de carga de red de paso a través interno requiere al menos una regla de reenvío interna.

Si configuras varias reglas de reenvío para el mismo servicio de backend, podrás hacer lo siguiente:

  • Asigna varias direcciones IP al balanceador de carga. 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.

  • Asigna un conjunto específico de puertos, con la misma dirección IP, al balanceador de carga. Puede crear varias reglas de reenvío que compartan la misma dirección IP, donde cada regla de reenvío use un conjunto específico de hasta cinco puertos. Esta es una alternativa a la configuración de una única regla de reenvío que especifica todos los puertos.

Para obtener más información sobre los casos en los que hay dos o más reglas de reenvío internas que comparten una misma dirección IP interna, consulta Varias reglas de reenvío con la misma dirección IP.

Cuando uses varias reglas de reenvío internas, asegúrate de configurar el software que se ejecuta en tus VMs de backend para que se vincule a todas las direcciones IP de las reglas 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 carga es la dirección IP interna asociada a la regla de reenvío interna correspondiente. Para obtener más información, consulta Paquetes de solicitud y respuesta TCP y UDP.

Servicio de backend

Cada balanceador de carga de red de paso a través interno tiene un servicio backend interno regional que define los parámetros y el comportamiento del backend. El nombre del servicio de backend es el nombre del balanceador de carga de red de paso a través interno que se muestra en la Google Cloud consola.

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

  • Protocolo. Un servicio de backend admite tráfico IPv4 e IPv6. Si el protocolo tiene un concepto de puerto (como TCP o UDP), el servicio de backend envía paquetes a las VMs de backend en el mismo puerto de destino al que se envió el tráfico.

    Los servicios de backend admiten las siguientes opciones del 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 coordinarse con el 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, consulta Especificación del protocolo de la regla de reenvío.

  • Distribución del tráfico. Un servicio de backend permite distribuir el tráfico según una afinidades de sesión configurables.

  • Comprobación del estado. Un servicio backend debe tener una comprobación del estado asociada.

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

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.
Cada VM miembro puede tener, opcionalmente, interfaces de red adicionales (vNICs o interfaces de red dinámicas), pero cada interfaz de red debe conectarse a una red VPC diferente. Estas redes también deben ser diferentes de la red VPC asociada al grupo de instancias.

Una NIC dinámica se puede eliminar si pertenece a una VM que es miembro de un grupo de instancias con balanceo de carga.

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.

Especificación de la red del servicio de backend

Puede asociar explícitamente una red de VPC a un servicio de backend mediante la marca --network al crear el servicio de backend. Las reglas de red del servicio backend se aplican inmediatamente.

Si omite la marca --network al crear un servicio de backend,Google Cloud usa uno de los siguientes eventos aptos para definir implícitamente la red de VPC asociada al servicio de backend. Una vez configurada, no se puede cambiar la red VPC asociada al servicio backend:

  • Si el servicio de backend aún no tiene ningún backend asociado y configuras la primera regla de reenvío para que haga referencia al servicio de backend,Google Cloud asigna al servicio de backend la red VPC asociada 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 haga referencia a él y añades el primer backend de grupo de instancias al servicio de backend,Google Cloud establece la red VPC del servicio de backend en la red VPC asociada a ese primer backend de grupo de instancias. Esto significa que la red de VPC asociada al servicio backend es la red que usa la interfaz de red nic0 de cada VM del primer backend del grupo de instancias.

  • Si el servicio de backend aún no tiene una regla de reenvío que haga referencia a él y añades el primer backend de NEG zonal (con GCE_VM_IP endpoints) al servicio de backend,Google Cloud asigna al servicio de backend la red VPC asociada a ese primer backend de NEG.

Una vez que se haya definido la red VPC del servicio de backend mediante un evento apto, las reglas de reenvío, los grupos de instancias de backend o los NEGs zonales de backend adicionales que añadas deberán seguir las reglas de red del servicio de backend.

Reglas de red de servicios de backend

Se aplican las siguientes reglas después de que un servicio de backend se asocie a una red de VPC específica:

  • Al configurar una regla de reenvío para hacer referencia al servicio de backend, la regla de reenvío 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 redes de VPC diferentes, aunque estén conectadas (por ejemplo, mediante el emparejamiento entre redes de VPC).

  • Al añadir backends de grupos de instancias, una de las siguientes condiciones debe cumplirse:

    • La red de VPC asociada al grupo de instancias (es decir, la red de VPC que usa la nic0interfaz de red de cada VM del grupo de instancias) debe coincidir con la red de VPC asociada al servicio de backend.
    • Cada VM de backend debe tener una interfaz nic0en la red de VPC asociada al servicio de backend.

  • Cuando añadas back-ends de NEG zonales con GCE_VM_IP puntos finales, la red de VPC asociada al NEG debe coincidir con la red de VPC asociada al servicio de back-end.

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 INTERNAL o EXTERNAL. Si el valor de ipv6-access-type de la subred de backend es EXTERNAL, debes usar otra subred de doble pila o solo IPv6 con el valor INTERNAL en ipv6-access-type para la regla de reenvío interna del balanceador de carga. Para obtener más información, consulta Añadir una subred de doble pila.
  • 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 más información, 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 EXTERNAL, debe usar otra subred solo IPv6 con ipv6-access-type definido como INTERNAL para la regla de reenvío interna 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 más información, 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.

Subconjunto de backend

La creación de subconjuntos de backend es una función opcional que mejora el rendimiento al limitar el número de backends a los que se distribuye el tráfico.

Te recomendamos que solo habilites el subconjunto si necesitas admitir más de 250 VMs de backend en un solo balanceador de carga. Para obtener más información, consulta Subconjuntos de backend para el balanceador de carga de red de paso a través interno.

Comprobación del estado

El servicio de backend del balanceador de carga debe estar asociado a una comprobación de estado global o regional. Las rutas especiales fuera de la red VPC facilitan la comunicación entre los sistemas de comprobación del estado y los back-ends.

Puede usar una comprobación de estado que ya tenga o definir una nueva. Los balanceadores de carga de red de transferencia internos usan el estado de la comprobación de estado para determinar cómo enrutar las nuevas conexiones, tal como se describe en Distribución del tráfico.

Puedes usar cualquiera de los siguientes protocolos de comprobación del estado. El protocolo de la comprobación del estado no tiene por qué coincidir con el del balanceador de carga:

  • HTTP, HTTPS o HTTP/2. Si tus VMs de backend sirven tráfico mediante HTTP, HTTPS o HTTP/2, lo mejor es usar una comprobación de estado que coincida con ese protocolo, ya que las comprobaciones de estado basadas en HTTP ofrecen opciones adecuadas para ese protocolo. Servir tráfico de tipo HTTP a través de un balanceador de carga de red de paso a través interno significa que el protocolo del balanceador de carga es TCP.
  • SSL o TCP. Si tus VMs de backend no sirven tráfico de tipo HTTP, te recomendamos que uses una comprobación de estado SSL o TCP.

Independientemente del tipo de comprobación del estado que crees, Google Cloud envía sondas de comprobación del estado a la dirección IP de la regla de reenvío del balanceador de carga de red pasante interno, a la interfaz de red de la red de VPC seleccionada por el servicio de backend del balanceador de carga. Simula cómo se entrega el tráfico balanceado de carga. El software que se ejecuta en las máquinas virtuales de backend debe responder al tráfico balanceado de carga y a las sondas de comprobación de estado que se envían 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). Para obtener más información, consulta Destino de los paquetes de sondeo.

Comprobaciones del estado y tráfico UDP

Google Cloud no ofrece una comprobación de estado que utilice el protocolo UDP. Cuando usas un balanceador de carga de red interno de tipo Pasarela con tráfico UDP, debes ejecutar un servicio basado en TCP en tus VMs de backend para proporcionar información de comprobación de estado.

En esta configuración, las solicitudes de los clientes se balancean mediante el protocolo UDP y se usa un servicio TCP para proporcionar información a los verificadores de estado. Google Cloud Por ejemplo, puedes ejecutar un servidor HTTP sencillo en cada VM de backend que devuelva un código de estado HTTP 200 a Google Cloud. En este ejemplo, te recomendamos que uses tu propia lógica en la VM de backend para asegurarte de que el servidor HTTP devuelva 200 solo si el servicio UDP está configurado correctamente y en funcionamiento.

Arquitectura de alta disponibilidad

El balanceador de carga de red de paso a través interno 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.

Para desplegar tus instancias de VM de backend en varias zonas, sigue estas recomendaciones de despliegue:

Arquitectura de VPC compartida

En la siguiente tabla se resumen los requisitos de los componentes de los balanceadores de carga de red de pases internos que se usan con redes de VPC compartidas. Para ver un ejemplo, consulta la sección sobre creación de un balanceador de carga de red interno de transferencia en la página de aprovisionamiento de VPC compartida.

Dirección IP Regla de reenvío Componentes de backend
Se debe definir una dirección IP interna en el mismo proyecto que las VMs de backend.

Para que el balanceador de carga esté disponible en una red de VPC compartida, la Google Cloud dirección IP interna debe definirse en el mismo proyecto de servicio en el que se encuentran las VMs de backend y debe hacer referencia a una subred de la red de VPC compartida deseada en el proyecto host. La dirección en sí procede del intervalo 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 está en la red de VPC del proyecto de servicio, tu balanceador de carga de red de pases interno será local para el proyecto de servicio. Tu balanceador de carga de red de paso a través interno no es local de ningún proyecto host de VPC compartida.		 Se debe definir una regla de reenvío interna en el mismo proyecto que las VMs de backend.

Para que el balanceador de carga esté disponible en una red de VPC compartida, la regla de reenvío interna debe definirse en el mismo proyecto de servicio en el que se encuentran las VMs 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 interna en un proyecto de servicio y la subred de la regla de reenvío está en la red de VPC del proyecto de servicio, tu balanceador de carga de red interno de transferencia directa será local al proyecto de servicio. Tu balanceador de carga de red de paso a través interno no es local de ningún proyecto host de VPC compartida.		 En un escenario de VPC compartida, las VMs de backend se encuentran en un proyecto de servicio. Se deben definir un servicio backend interno regional y una comprobación del estado en ese proyecto de servicio.

Distribución del tráfico

Los balanceadores de carga de red de paso a través internos admiten varias opciones de personalización de la distribución del tráfico, como la afinidad de sesión, el seguimiento de conexiones y la conmutación por error. Para obtener más información sobre cómo distribuyen el tráfico los balanceadores de carga de red de paso a través internos 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 internos.

Cuotas y límites

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

Limitaciones

  • No puedes usar la Google Cloud consola para crear un balanceador de carga de red de paso a través interno con backends de NEG zonales.

Siguientes pasos