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 VMs 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 deGoogle Cloud administran la entrega y la escala 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 no admite lo siguiente:

Dirección IP interna

Los balanceadores de cargas de red de transferencia interna admiten subredes solo de IPv4, de pila doble y solo de IPv6. Para obtener más información sobre cada uno, 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 o de pila única solo IPv6 (versión preliminar) con un rango de direcciones IPv6 interno (ipv6-access-type configurado como INTERNAL). El rango 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 rangos de subredes IPv6 y direcciones IPv6.

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 /64 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 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 el caso de los grupos de instancias administrados (MIG), la red de VPC del 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 Cloudelige 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. Después de configurarla, 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 que usa 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 red de 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 redes de VPC diferentes, incluso si esas redes están conectadas (por ejemplo, a través del 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.

Backends de doble pila (IPv4 e IPv6)

Si deseas que el balanceador de cargas use backends de pila doble que controlen el tráfico IPv4 y IPv6, ten en cuenta los siguientes requisitos:

  • Los backends deben configurarse en subredes de pila doble que se encuentran en la misma región que la regla de reenvío IPv6 del balanceador de cargas. Para los backends, puedes usar una subred con ipv6-access-type configurado como INTERNAL o EXTERNAL. Si el ipv6-access-type de la subred de backend está configurado como EXTERNAL, debes usar una subred de pila doble o solo IPv6 diferente con ipv6-access-type configurado como INTERNAL para la regla de reenvío interna del balanceador de cargas. Para obtener más información, consulta Agrega una subred de pila doble.
  • Los backends deben configurarse para ser de pila doble con stack-type establecido como IPv4_IPv6. Si el ipv6-access-type de la subred del backend está configurado como EXTERNAL, también debes configurar --ipv6-network-tier como PREMIUM. Para obtener más información, consulta Crea una plantilla de instancias con direcciones IPv6.

Backends solo IPv6

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

  • Las instancias solo IPv6 solo se admiten en grupos de instancias no administrados. No se admite ningún otro tipo de backend.
  • Los backends deben configurarse en subredes de pila doble o solo IPv6 que se encuentren en la misma región que la regla de reenvío IPv6 del balanceador de cargas. Para los backends, puedes usar una subred con ipv6-access-type configurado como INTERNAL o EXTERNAL. Si el ipv6-access-type de la subred de backend está configurado como EXTERNAL, debes usar una subred diferente de solo IPv6 con ipv6-access-type configurado como INTERNAL para la regla de reenvío interna del balanceador de cargas.
  • Los backends deben configurarse para ser solo IPv6 con el stack-type de la VM establecido como IPv6_ONLY. Si el ipv6-access-type de la subred del backend está configurado como EXTERNAL, también debes configurar --ipv6-network-tier como PREMIUM. Para obtener más información, consulta Crea una plantilla de instancias con direcciones IPv6.

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

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 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). Para 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, se debe definir la dirección IP interna de Google Cloud en el mismo proyecto de servicio en el que se encuentran las VMs 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

Los balanceadores de cargas de red de transferencia internos admiten una variedad de opciones de personalización de distribución de tráfico, como la afinidad de sesión, el seguimiento de conexiones y la conmutación por error. Para obtener detalles sobre cómo los balanceadores de cargas de red de transferencia interna distribuyen el tráfico y cómo estas opciones interactúan entre sí, consulta Distribución del tráfico para balanceadores de cargas de red de transferencia interna.

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?