Los balanceadores de cargas de red de transferencia son balanceadores de carga de transferencia regionales de capa 4. Estos balanceadores de cargas distribuyen el tráfico entre backends en la misma región que el balanceador de cargas. Tal como lo sugiere el nombre, los balanceadores de cargas de red no son proxies. Las VMs de backend reciben paquetes con balanceo de cargas, direcciones IP de origen y destino, y el protocolo del paquete y, si el protocolo se basa en puertos, los puertos de origen y de destino sin cambios. Las conexiones con balanceo de cargas se finalizan en los backends. Las respuestas de las VMs de backend van directo a los clientes, no pasan a través del balanceador de cargas. El término del sector para esto es retorno directo del servidor (DSR).
En el siguiente diagrama, se muestra un ejemplo de arquitectura de un balanceador de cargas de red.
Deberías usar un balanceador de cargas de red de transferencia en las siguientes circunstancias:
- Si necesitas reenviar los paquetes de clientes originales a los backends sin proxy, por ejemplo, si necesitas que se conserve la dirección IP de origen de cliente.
- Si necesitas balancear las cargas de tráfico de TCP, UDP, ESP, GRE, ICMP e ICMPv6, o necesitas balancear las cargas de un puerto TCP que no sea compatible con otros balanceadores de cargas.
- Si es aceptable hacer que se desencripte el tráfico SSL mediante tus backends en lugar de hacerlo mediante el balanceador de cargas. El balanceador de cargas de red de transferencia no puede realizar esta tarea. Cuando los backends desencriptan el tráfico SSL, hay una mayor carga de CPU en las VM.
- Puedes administrar los certificados SSL de la VM de backend por tu cuenta. Los certificados SSL administrados por Google solo están disponibles para los balanceadores de cargas de proxy.
- Úsalo si tienes una configuración existente que use un balanceador de cargas de transferencia y deseas migrarla sin cambios.
Los balanceadores de cargas de red de transferencia están disponibles en los siguientes modos de implementación.
| Alcance | Tipo de tráfico | Nivel de servicio de red | Esquema de balanceo de cargas † | Dirección IP | Puertos de frontend | Vínculos | |
|---|---|---|---|---|---|---|---|
| Balanceador de cargas de red de transferencia externo
Balancea la carga del tráfico que proviene de los clientes en Internet. |
Regional | TCP, UDP, ESP, GRE, ICMP e ICMPv6 | Premium o Estándar | EXTERNO | IPv4 e IPv6 | Un solo puerto, un rango de puertos o todos los puertos | Detalles de la arquitectura |
| Balanceador de cargas de red de transferencia interno
Balancea las cargas del tráfico dentro de tu red de VPC o las redes 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 rango de puertos o todos los puertos | Detalles de la arquitectura |
† El esquema de balanceo de cargas es un atributo de la regla de reenvío y el servicio de backend de un balanceador de cargas y, luego, indica si el balanceador de cargas se puede usar para tráfico interno o externo.
Balanceadores de cargas de red de transferencia externos
Los balanceadores de cargas de red de transferencia externos son balanceadores de cargas regionales de capa 4 que distribuyen el tráfico externo entre backends (grupos de instancias o grupos de extremos de red [NEG]) en la misma región que el balanceador de cargas. Estos backends deben estar en la misma región y proyecto, pero pueden estar en diferentes redes de VPC. Estos balanceadores de cargas se compilan en Maglev y en la pila de virtualización de red de Andromeda.
Los balanceadores de cargas de red de transferencia externos pueden recibir tráfico de las siguientes fuentes:
- Cualquier cliente en Internet
- VM de Google Cloud con IP externas
- VM de Google Cloud que tienen acceso a Internet a través de Cloud NAT o NAT basada en la instancia
Los balanceadores de cargas de red de transferencia externos no son proxies. El balanceador de cargas no finaliza las conexiones de usuario. Los paquetes con balanceo de cargas se envían a las VMs de backend con las direcciones IP de origen y destino, el protocolo y, si corresponde, los puertos, sin cambios. Luego, las VMs de backend finalizan las conexiones de usuario. Las respuestas de las VMs de backend van directo a los clientes, no pasan a través del balanceador de cargas. Este proceso se conoce como retorno directo del servidor (DSR).
En el siguiente diagrama, se muestra un balanceador de cargas de red de transferencia externo que se configura en la región us-central1 con sus backends ubicados en la misma región. El tráfico
se enruta desde un usuario en Singapur al
balanceador de cargas en us-central1 (dirección IP de la regla de reenvío 120.1.1.1).
Si la dirección IP del balanceador de cargas está en el nivel Premium, el tráfico recorre la red troncal global de alta calidad de Google, con la intención de que los paquetes ingresen y salgan de un punto de intercambio de tráfico perimetral de Google lo más cercano posible al cliente. Si la dirección IP del balanceador de cargas está en el nivel Estándar, el tráfico ingresa y sale de la red de Google en el punto de intercambio de tráfico más cercano a la región de Google Cloud en la que se configuró el balanceador de cargas.
La arquitectura de un balanceador de cargas de red de transferencia externo depende de si usas un servicio de backend o un grupo de destino para configurar el backend.
Balanceadores de cargas basados en servicios de backend
Los balanceadores de cargas de red de transferencia externos se pueden crear con un servicio de backend regional que define el comportamiento del balanceador de cargas y cómo este distribuye el tráfico a sus backends. Los balanceadores de cargas de red de traspaso externos basados en servicios de backend admiten tráfico IPv4 e IPv6, varios protocolos (TCP, UDP, ESP, GRE, ICMP y ICMPv6), y backends de grupos de instancias administrados y no administrados , backends de grupo de extremos de red (NEG) zonales con extremos GCE_VM_IP, controles detallados de distribución de tráfico, políticas de conmutación por error y te permiten usar verificaciones de estado no heredadas que coincidan con el tipo de tráfico (TCP, SSL, HTTP, HTTPS o HTTP/2) que distribuyes.
El balanceo de cargas en Google Kubernetes Engine (GKE) se controla mediante el controlador de servicios de GKE integrado. Además, los balanceadores de cargas de red de transferencia externos basados en servicios de backend son compatibles con App Hub, que está en vista previa.
Para obtener detalles sobre la arquitectura y más información sobre las funciones compatibles, consulta Descripción general del balanceador de cargas de red de transferencia externo basado en servicios de backend.
Puedes hacer la transición de un balanceador de cargas de basado en grupos de destino existente para usar un servicio de backend. Para obtener instrucciones, consulta Migra balanceadores de cargas de grupos de destino a servicios de backend.
Balanceadores de cargas basados en grupos de destino
Un grupo de destino es el backend heredado compatible con los balanceadores de cargas de red de transferencia externos. Un grupo de destino define un grupo de instancias que deben recibir tráfico entrante desde el balanceador de cargas.
Los balanceadores de cargas basados en grupos de destino admiten tráfico TCP o UDP. Las reglas de reenvío para balanceadores de cargas de red de transferencia externos basados en grupos de destino solo admiten direcciones IPv4 externas.
Para obtener detalles sobre la arquitectura, consulta Descripción general del balanceador de cargas de red de transferencia externo basado en grupos de destino.
Balanceadores de cargas de red de transferencia interno
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 permiten 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.
Estos balanceadores de cargas se compilan en la pila de virtualización de red de Andromeda. Solo admiten backends regionales para que puedas realizar un ajuste de escala automático en una región, y así proteger tu servicio de fallas zonales. Además, este balanceador de cargas solo se puede configurar en el nivel Premium.
Los balanceadores de cargas de red de transferencia internos abordan muchos casos prácticos. En las siguientes secciones, se muestran algunos ejemplos de alto nivel.
Acceso a redes conectadas
Puedes acceder a un balanceador de cargas de red de transferencia interno en tu red de VPC desde una red conectada mediante lo siguiente:
- Intercambio de tráfico entre redes de VPC
- Cloud VPN y Cloud Interconnect
Para ver ejemplos detallados, consulta Balanceadores de cargas de red de transferencia internos y redes conectadas.
Servicio web de tres niveles
Puedes usar los balanceadores de cargas de red de transferencia internos junto con otros balanceadores de cargas. Por ejemplo, si incorporas balanceadores de cargas de aplicaciones externos, el balanceador de cargas de aplicaciones externo es el nivel web y depende de los servicios detrás del balanceador de cargas de red de transferencia interno.
En el siguiente diagrama, se muestra un ejemplo de una configuración de tres niveles que utiliza balanceadores de cargas de aplicaciones externos y balanceadores de cargas de red de transferencia internos:
Ejemplo de servicio web de tres niveles con acceso global
Si habilitas el acceso global, las VMs de nivel web pueden estar en otra región, como se muestra en el siguiente diagrama.
En este ejemplo de aplicación de varios niveles, se muestra la siguiente información:
- Un nivel web orientado a Internet con disponibilidad global que balancea las cargas del tráfico con un balanceador de cargas de aplicaciones externo.
- Un nivel de base de datos de backend interno con balanceo de cargas en la región
us-east1al que accede el nivel web global - Una VM de cliente que forma parte del nivel web en la región
europe-west1y que accede al nivel de base de datos interno con balanceo de cargas ubicado enus-east1
Usa balanceadores de cargas de red de transferencia internos como próximos saltos
Puedes usar un balanceador de cargas de red de transferencia interno como la próxima puerta de enlace a la cual se reenvían los paquetes en la ruta a su destino final. Para ello, configura el balanceador de cargas como el próximo salto en una ruta estática.
Un balanceador de cargas de red de transferencia interno de próximo salto procesa paquetes para todo el tráfico compatible, independientemente de los protocolos de la regla de reenvío y del servicio de backend que especificaste cuando creaste el balanceador de cargas.
A continuación, figura una arquitectura de muestra que usa un balanceador de cargas de red de transferencia interno como próximo salto a una puerta de enlace NAT. Puedes enrutar el tráfico a los backends del dispositivo virtual de tu puerta de enlace o firewall a través de un balanceador de cargas de red de transferencia interno.
Los casos de uso adicionales incluyen los siguientes:
- Concentrador y radio: intercambio de rutas de salto siguiente mediante el intercambio de tráfico entre redes de VPC para configurar una topología de concentrador y radio con los dispositivos virtuales de firewall de salto siguiente ubicados en la red de VPC de
hub. Las rutas que usan el balanceador de cargas como el salto siguiente en la red de VPC dehubse pueden usar en cada red despoke. - Balanceo de cargas a interfaces de red múltiples (
nic0anic7) en las VMs de backend.
Para obtener más información sobre estos casos de uso, consulta Balanceadores de cargas de red de transferencia internos como próximos saltos.
Balanceadores de cargas de red de transferencia internos y GKE
Si deseas obtener detalles sobre cómo GKE crea balanceadores de cargas de red de transferencia internos para servicios, consulta los conceptos del objeto Service LoadBalancer en la documentación de GKE.
Balanceadores de cargas de red de transferencia internos y App Hub
Los recursos que usan los balanceadores de cargas de red de transferencia internos se pueden designar como servicios en App Hub, que se encuentra en vista previa.
Asignación de puertos de Private Service Connect
Los servicios de asignación de puertos de Private Service Connect usan NEG de asignación de puertos y tienen parámetros de configuración similares a los balanceadores de cargas de red de transferencia internos. Sin embargo, los servicios de asignación de puertos no balancean las cargas de tráfico. En cambio, Private Service Connect reenvía el tráfico a los puertos de servicio en las VMs del productor de servicios según el 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, se descartan los paquetes.
Para obtener más información, consulta Acerca de la asignación de puertos de Private Service Connect.
¿Qué sigue?
- Para obtener información detallada sobre la arquitectura de los balanceadores de cargas de red de transferencia internos, consulta Descripción general de la arquitectura del balanceador de cargas de red de transferencia interno.
- Para obtener información detallada sobre la arquitectura de los balanceadores de cargas de red de transferencia externos, consulta Descripción general de la arquitectura del balanceador de cargas de red de transferencia externo.