Los balanceadores de carga de red con paso a través son balanceadores de carga de capa 4 regionales con paso a través. Estos balanceadores de carga distribuyen el tráfico entre los backends de la misma región que el balanceador de carga. Como su nombre indica, los balanceadores de carga de red con paso a través no son proxies. Las máquinas virtuales de backend reciben los paquetes balanceados de carga con las direcciones IP de origen y destino, el protocolo y, si el protocolo se basa en puertos, los puertos de origen y destino del paquete sin cambios. Las conexiones balanceadas se terminan en los backends. Las respuestas de las VMs backend van directamente a los clientes, no vuelven a pasar por el balanceador de carga. El término del sector para esto es retorno directo del servidor (DSR).
En el siguiente diagrama se muestra una arquitectura de ejemplo de balanceador de carga de red de paso a través.
Utilizarías un balanceador de carga de red de paso a través en las siguientes circunstancias:
- Debes reenviar los paquetes del cliente original a los back-ends sin proxy, por ejemplo, si necesitas que se conserve la dirección IP de origen del cliente.
- Necesitas balancear la carga del tráfico TCP, UDP, ESP, GRE, ICMP e ICMPv6, o bien necesitas balancear la carga de un puerto TCP que no sea compatible con otros balanceadores de carga.
- Es aceptable que tus backends descifren el tráfico SSL en lugar del balanceador de carga. El balanceador de carga de red de paso a través no puede realizar esta tarea. Cuando los back-ends descifran el tráfico SSL, las VMs tienen una mayor carga de CPU.
- Puedes gestionar los certificados SSL de la VM backend por tu cuenta. Los certificados SSL gestionados por Google solo están disponibles para los balanceadores de carga proxy.
- 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 con paso a través están disponibles en los siguientes modos de implementación.
| Ámbito | Tipo de tráfico | Nivel de servicio de red | Esquema de balanceo de carga † | Dirección IP | Puertos de frontend | Enlaces | |
|---|---|---|---|---|---|---|---|
| Balanceador de carga de red de paso a través externo
Balancea la carga del tráfico procedente de clientes en Internet. |
Regional | TCP, UDP, ESP, GRE, ICMP e ICMPv6 | Premium o Estándar | EXTERNO | IPv4 e IPv6 | Un solo puerto, un intervalo de puertos o todos los puertos | Detalles de la arquitectura |
| Balanceador de carga de red de paso a través interno
Balancear la carga del tráfico en tu red o redes de VPC conectadas a tu red de VPC. |
Regional | TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH y GRE | Premium | INTERNAL | IPv4 e IPv6 | Un solo puerto, un intervalo de puertos o todos los puertos | Detalles de la arquitectura |
† El esquema de balanceo de carga es un atributo de la regla de reenvío y del servicio de backend de un balanceador de carga, e indica si el balanceador de carga se puede usar para el tráfico interno o externo.
Balanceadores de carga de red de paso a través externos
Los balanceadores de carga de red de paso a través externos son balanceadores de carga de capa 4 regionales que distribuyen el tráfico externo entre backends (grupos de instancias o grupos de endpoints de red [NEGs]) de la misma región que el balanceador de carga. Estos backends deben estar en la misma región y proyecto, pero pueden estar en redes de VPC diferentes. Estos balanceadores de carga se basan en Maglev y en la pila de virtualización de redes Andromeda.
Los balanceadores de carga de red de paso a través externos pueden recibir tráfico de los siguientes elementos:
- Cualquier cliente de Internet
- Google Cloud Máquinas virtuales con IPs externas
- Google Cloud Máquinas virtuales que tienen acceso a Internet a través de Cloud NAT o NAT basado en instancias
Los balanceadores de carga de red de paso a través externos no son proxies. El balanceador de carga no finaliza las conexiones de los usuarios. Los paquetes con balanceo de carga se envían a las VMs de backend con sus direcciones IP de origen y destino, su protocolo y, si procede, sus puertos sin cambios. A continuación, las VMs de backend terminan las conexiones de los usuarios. Las respuestas de las VMs backend van directamente a los clientes, no vuelven a pasar por el balanceador de carga. Este proceso se conoce como retorno directo del servidor (DSR).
En el siguiente diagrama se muestra un balanceador de carga de red de paso a través externo configurado en la región us-central1 con sus backends ubicados en la misma región. El tráfico se
ruta desde un usuario de Singapur al
balanceador de carga de us-central1 (dirección IP de la regla de reenvío 120.1.1.1).
Si la dirección IP del balanceador de carga está en el nivel Premium, el tráfico atraviesa la red troncal mundial de alta calidad de Google con el objetivo de que los paquetes entren y salgan de un punto de emparejamiento perimetral de Google lo más cerca posible del cliente. Si la dirección IP del balanceador de carga está en el nivel Estándar, el tráfico entra en la red de Google y sale de ella por el punto de emparejamiento más cercano a laGoogle Cloud región en la que está configurado el balanceador de carga.
La arquitectura de un balanceador de carga de red de paso a través externo depende de si usas un servicio de backend o un grupo de destino para configurar el backend.
Balanceadores de carga basados en servicios de backend
Los balanceadores de carga de red de paso a través externos se pueden crear con un servicio de backend regional que defina el comportamiento del balanceador de carga y cómo distribuye el tráfico a sus backends. Los balanceadores de carga de red de pases externos basados en servicios de backend admiten tráfico IPv4 e IPv6, varios protocolos (TCP, UDP, ESP, GRE, ICMP e ICMPv6), backends de grupos de instancias gestionados y sin gestionar, backends de grupos de puntos de conexión de red (NEG) zonales con GCE_VM_IP puntos de conexión, controles de distribución de tráfico detallados y políticas de conmutación por error. Además, permiten usar comprobaciones de estado no antiguas que coincidan con el tipo de tráfico (TCP, SSL, HTTP, HTTPS o HTTP/2) que estés distribuyendo.
El balanceo de carga en Google Kubernetes Engine (GKE) se gestiona mediante el controlador de servicio de GKE integrado. Además, los balanceadores de carga de red de paso a través externos basados en servicios de backend son compatibles con App Hub.
Para obtener información sobre la arquitectura y las funciones admitidas, consulta el resumen del balanceador de carga de red externo de pasarela basado en el servicio de backend.
Puedes cambiar un balanceador de carga basado en grupos de destino para que use un servicio de backend. Para obtener instrucciones, consulta Migrar balanceadores de carga de grupos de destino a servicios de backend.
Balanceadores de carga basados en grupos de destino
Un grupo de destino es el backend antiguo compatible con los balanceadores de carga de red de paso a través externos. Un grupo de destino define un grupo de instancias que debe recibir el tráfico entrante del balanceador de carga.
Los balanceadores de carga basados en grupos de destino admiten tráfico TCP o UDP. Las reglas de reenvío de los balanceadores de carga de red de paso a través externos basados en grupos de destino solo admiten direcciones IPv4 externas.
Para obtener información sobre la arquitectura, consulta la descripción general del balanceador de carga de red de paso a través externo basado en grupos de destino.
Balanceadores de carga de red de paso a través internos
Los balanceadores de carga de red internos con paso a través distribuyen el tráfico entre instancias de máquinas virtuales (VM) internas en la misma región de una red de nube privada virtual (VPC). Te permiten 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.
Estos balanceadores de carga se basan en la pila de virtualización de redes de Andromeda. Solo admiten backends regionales para que puedas escalar automáticamente en una región y proteger tu servicio frente a fallos zonales. Además, este balanceador de carga solo se puede configurar en el nivel Premium.
Los balanceadores de carga de red de paso a través internos se adaptan a muchos casos prácticos. En las siguientes secciones se muestran algunos ejemplos generales.
Acceso a redes conectadas
Puedes acceder a un balanceador de carga de red de paso a través interno de tu red de VPC desde una red conectada mediante lo siguiente:
- Emparejamiento entre redes VPC
- Cloud VPN y Cloud Interconnect
Para ver ejemplos detallados, consulta Balanceadores de carga de red de paso a través internos y redes conectadas.
Servicio web de tres niveles
Puede usar balanceadores de carga de red de paso a través internos junto con otros balanceadores de carga. Por ejemplo, si incorporas balanceadores de carga de aplicación externos, el balanceador de carga de aplicación externo es el nivel web y depende de los servicios que se encuentran detrás del balanceador de carga de red de paso a través interno.
En el siguiente diagrama se muestra un ejemplo de una configuración de tres niveles que usa balanceadores de carga de aplicaciones externos y balanceadores de carga de red de paso a través internos:
Servicio web de tres niveles con acceso global
Si habilitas el acceso global, tus máquinas virtuales de nivel web pueden estar en otra región, como se muestra en el siguiente diagrama.
En este ejemplo de aplicación multinivel se muestra lo siguiente:
- Un nivel web accesible desde Internet a nivel mundial que balancea la carga del tráfico con un balanceador de carga de aplicación externo.
- Una capa de base de datos con balanceo de carga de backend interno en la región
us-east1a la que accede la capa web global. - Una VM cliente que forma parte del nivel web de la región
europe-west1y que accede al nivel de base de datos interno con balanceo de carga ubicado enus-east1.
Usar balanceadores de carga de red de paso a través internos como siguientes saltos
Puedes usar un balanceador de carga de red de paso a través interno como la siguiente puerta de enlace a la que se reenvían los paquetes en la ruta hacia su destino final. Para ello, debes definir el balanceador de carga como siguiente salto en una ruta estática.
Un balanceador de carga de red de paso a través interno del siguiente salto procesa los paquetes de todo el tráfico admitido, independientemente de los protocolos de la regla de reenvío y del servicio de backend que hayas especificado al crear el balanceador de carga.
Esta función admite el uso de direcciones IPv4 o IPv6.
A continuación, se muestra una arquitectura de ejemplo que usa un balanceador de carga de red de paso a través interno como siguiente salto a una pasarela NAT. Puede dirigir el tráfico a los back-ends de su cortafuegos o dispositivo virtual de pasarela a través de un balanceador de carga de red de paso a través interno.
Otros casos prácticos:
- Topología de concentrador y radios: intercambiar rutas de salto siguiente mediante el emparejamiento entre redes de VPC. Puedes configurar una topología de concentrador y radios con tus dispositivos virtuales de cortafuegos de salto siguiente ubicados en la red de VPC
hub. Las rutas que usan el balanceador de carga como siguiente salto en la red de VPChubse pueden usar en cada redspoke. - Balanceo de carga en varias interfaces de red (de
nic0anic7) en las VMs de backend.
Para obtener más información sobre estos casos prácticos, consulta Balanceadores de carga de red de paso a través internos como saltos siguientes.
Balanceadores de carga de red de paso a través internos y GKE
Para obtener información sobre cómo crea GKE balanceadores de carga de red de pases internos para los servicios, consulta la sección Conceptos de servicio LoadBalancer de la documentación de GKE.
Balanceadores de carga de red de paso a través internos y App Hub
Los recursos que usan los balanceadores de carga de red de paso a través internos se pueden designar como servicios en las aplicaciones de App Hub.
Asignación de puertos de Private Service Connect
Los servicios de asignación de puertos de Private Service Connect usan NEGs de asignación de puertos y tienen configuraciones similares a las de los balanceadores de carga de red de pases internos. Sin embargo, los servicios de asignación de puertos no balancean la carga del tráfico. En su lugar, Private Service Connect reenvía el tráfico a los puertos de servicio de las VMs del productor de servicios en función del puerto de destino del cliente que recibe el tráfico.
Si envías tráfico a un servicio de asignación de puertos desde la misma red de VPC que el servicio, los paquetes se descartarán.
Para obtener más información, consulta Información sobre la asignación de puertos de Private Service Connect.
Siguientes pasos
- Para obtener información detallada sobre la arquitectura de los balanceadores de carga de red de paso a través internos, consulta el resumen de la arquitectura de los balanceadores de carga de red de paso a través internos.
- Para obtener información detallada sobre la arquitectura de los balanceadores de carga de red de paso a través externos, consulta la descripción general de la arquitectura de los balanceadores de carga de red de paso a través externos.