En este documento, se presentan los conceptos que debes comprender para configurar un balanceador de cargas de red del proxy externo de Google Cloud.
El balanceador de cargas de red del proxy externo es un balanceador de cargas del proxy inverso que distribuye el tráfico TCP proveniente de Internet a instancias de máquinas virtuales (VM) en tu red de nube privada virtual (VPC) de Google Cloud. Cuando se usa un balanceador de cargas de red del proxy externo, el tráfico de TCPo SSL entrante finaliza en el balanceador de cargas. Luego, una conexión nueva reenvía el tráfico al backenddisponible más cercano mediante TCP o SSL (recomendado). Para obtener más casos de uso, consulta Descripción general del balanceador de cargas de red del proxy.
Los balanceadores de cargas de red del proxy externo te permiten usar una sola dirección IP para todos los usuarios en todo el mundo. El balanceador de cargas enruta el tráfico de manera automática a los backends que están más cerca del usuario.
En el siguiente ejemplo, el tráfico de los usuarios de la ciudad A y la ciudad B finaliza en la capa del balanceo de cargas y se establece una conexión independiente para el backend seleccionado.
Modos de operación
Puedes configurar un balanceador de cargas de red del proxy externo de los siguientes modos:
- Un balanceador de cargas de red de proxy clásico se implementa en Google Front End (GFE) distribuido a nivel global. Este balanceador de cargas se puede configurar para controlar el tráfico de TCP o SSL con un proxy TCP de destino o un proxy SSL de destino, respectivamente. Con el nivel Premium, este balanceador de cargas se puede configurar como un servicio de balanceo de cargas global. Con el nivel Estándar, este balanceador de cargas se configura como un servicio de balanceo de cargas regional. Los balanceadores de cargas de red del proxy clásico también se pueden usar para otros protocolos que usan SSL, como IMAP y WebSockets mediante SSL.
- ABalanceador de cargas de red del proxy externo global Se implementa en distribución global.GFE y es compatible las funciones deadministración avanzada del tráfico. Este balanceador de cargas se puede configurar para controlar el tráfico de TCP o SSL con un proxy TCP de destino o un proxy SSL de destino, respectivamente. Este balanceador de cargas se configura como un servicio de balanceo de cargas global con el nivel Premium. Los balanceadores de cargas de red del proxy externo global también se pueden usar para otros protocolos que usan SSL, como IMAP y WebSockets mediante SSL.
- Se implementa un balanceador de cargas de red del proxy externo regional en la pila de software de proxy de código abierto de Envoy. Solo puede controlar el tráfico de TCP. Este balanceador de cargas se configura como un servicio de balanceo de cargas regional que puede usar los niveles Premium o Estándar.
Identifica el modo
Para determinar el modo de un balanceador de cargas, completa los siguientes pasos.
Console
En la consola de Google Cloud, ve a la página Balanceo de cargas.
En la pestaña Balanceadores de cargas, se muestran el tipo, el protocolo y la región del balanceador de cargas. Si la región está en blanco, entonces el balanceador de cargas es global.
En la siguiente tabla, se resume cómo identificar el modo del balanceador de cargas.
Modo de balanceador de cargas Tipo de balanceador de cargas Tipo de acceso Región Balanceador de cargas de red de proxy clásico Red (proxy, clásico) Externo Balanceador de cargas de red del proxy externo global Red (proxy) Externo Balanceador de cargas de red del proxy externo regional Red (proxy) Externo Especifica una región
gcloud
Usa el comando
gcloud compute forwarding-rules describe:gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
En el resultado del comando, verifica el esquema de balanceo de cargas, la región y el nivel de red. En la siguiente tabla, se resume cómo identificar el modo del balanceador de cargas.
Modo de balanceador de cargas Esquema de balanceo de cargas Regla de reenvío Nivel de red Balanceador de cargas de red de proxy clásico EXTERNO Global Estándar o Premium Balanceador de cargas de red del proxy externo global EXTERNAL_MANAGED Global Premium Balanceador de cargas de red del proxy externo regional EXTERNAL_MANAGED Regional Estándar o Premium
Arquitectura
En los siguientes diagramas, se muestran los componentes de los balanceadores de cargas de red del proxy externo.
Global
En este diagrama, se muestran los componentes de una implementación del balanceador de cargas de red del proxy externo global. Esta arquitectura se aplica al balanceador de cargas de red del proxy externo global y al balanceador de cargas de red del proxy clásico en el nivel Premium.
Regional
En este diagrama, se muestran los componentes de una implementación del balanceador de cargas de red del proxy externo regional.
Los siguientes son componentes de balanceadores de cargas de red del proxy externo.
Subred de solo proxy
Nota: Las subredes de solo proxy solo son necesarias para los balanceadores de cargas de red del proxy externo regional.La subred de solo proxy proporciona un conjunto de direcciones IP que Google usa para ejecutar proxies de Envoy en tu nombre. Debes crear una subred de solo proxy en cada región de una red de VPC en la que uses balanceadores de cargas. La marca --purpose para esta subred de solo proxy se configura como REGIONAL_MANAGED_PROXY. Todos los balanceadores de cargas basados en Envoy en la misma región y red de VPC comparten un grupo de proxies de Envoy de la misma subred de solo proxy.
Las VM de backend o los extremos de todos los balanceadores de cargas en una región y una red de VPC reciben conexiones desde la subred de solo proxy.
Puntos que debes recordar:
- Las subredes de solo proxy se usan solo para los proxies de Envoy, no para tus backends.
- La dirección IP del balanceador de cargas no se encuentra en la subred de solo proxy. La dirección IP del balanceador de cargas se define según su regla de reenvío administrada externa.
Reglas de reenvío y direcciones IP
Las reglas de reenvío enrutan el tráfico por dirección IP, puerto y protocolo a una configuración de balanceo de cargas que consiste en un proxy de destino y un servicio de backend.
Especificación de la dirección IP. Cada regla de reenvío hace referencia a una sola dirección IP que puedes usar en los registros DNS de tu aplicación. Puedes reservar una dirección IP estática para usarla o permitir que Cloud Load Balancing te asigne una. Te recomendamos reservar una dirección IP estática. De lo contrario, debes actualizar tu registro DNS con la dirección IP efímera recién asignada cada vez que borres una regla de reenvío y crees una nueva.
Especificación de puerto Las reglas de reenvío externas que se usan en la definición de este balanceador de cargas pueden hacer referencia exactamente a un puerto del 1 al 65535. Si deseas admitir varios puertos consecutivos, debes configurar varias reglas de reenvío. Se pueden configurar varias reglas de reenvío con la misma dirección IP virtual y diferentes puertos. Por lo tanto, puedes usar proxies en varias aplicaciones con puertos personalizados independientes a la misma dirección IP virtual del proxy TCP. Si deseas obtener más detalles, consulta Especificaciones de puertos para reglas de reenvío.
Para admitir varios puertos consecutivos, debes configurar varias reglas de reenvío. Se pueden configurar varias reglas de reenvío con la misma dirección IP virtual y puertos diferentes. Por lo tanto, puedes usar proxies en varias aplicaciones con puertos personalizados independientes a la misma dirección IP virtual del proxy TCP.
En la siguiente tabla, se muestran los requisitos de las reglas de reenvío para los balanceadores de cargas de red de proxy externos.
| Modo de balanceador de cargas | Nivel de servicio de red | Regla de reenvío, dirección IP y esquema de balanceo de cargas | Enrutamiento de Internet al frontend del balanceador de cargas |
|---|---|---|---|
| Balanceador de cargas de red de proxy clásico | Nivel Premium | Regla de reenvío externa global Esquema de balanceo de cargas: |
Solicitudes enrutadas a los GFE más cercanos al cliente en Internet. |
| Nivel Estándar | Regla de reenvío externa regional Esquema de balanceo de cargas: |
Solicitudes enrutadas a un GFE en la región del balanceador de cargas. | |
| Balanceador de cargas de red del proxy externo global | Nivel Premium | Regla de reenvío externa global Esquema de balanceo de cargas: |
Solicitudes enrutadas a los GFE más cercanos al cliente en Internet. |
| Balanceador de cargas de red del proxy externo regional | Nivel Premiumy Estándar * | Regla de reenvío externa regional Esquema de balanceo de cargas: |
Solicitudes enrutadas a los proxies de Envoy en la misma región que el balanceador de cargas. |
Reglas de reenvío y redes de VPC
En esta sección, se describe cómo las reglas de reenvío que usan los balanceadores de cargas de aplicaciones externos se asocian con las redes de VPC.
| Modo de balanceador de cargas | Asociación de redes de VPC |
|---|---|
| Balanceador de cargas de red de proxy externo global Balanceador de cargas de red de proxy clásico |
No hay una red de VPC asociada. La regla de reenvío siempre usa una dirección IP que está fuera de la red de VPC. Por lo tanto, la regla de reenvío no tiene una red de VPC asociada. |
| Balanceador de cargas de red del proxy externo regional | La red de VPC de la regla de reenvío es la red en la que se creó la subred de solo proxy. Debes especificar la red cuando creas la regla de reenvío. |
Proxies de destino
Los balanceadores de cargas de red del proxy externo finalizan las conexiones del cliente y crean conexiones nuevas a los backends. El proxy de destino enruta estas conexiones nuevas al servicio de backend.
Según el tipo de tráfico que necesite controlar tu aplicación, puedes configurar un balanceador de cargas de red del proxy externo con un proxy TCP de destino o un proxy SSL de destino.
- Proxy TCP de destino: Configura el balanceador de cargas con un proxy TCP de destino si esperas tráfico TCP.
- Proxy SSL de destino: Configura el balanceador de cargas con un proxy SSL de destino si esperas tráfico de cliente encriptado. Este tipo de balanceador de cargas está diseñado solo para el tráfico que no es de HTTP(S). Para el tráfico HTTP(S), te recomendamos que uses un balanceador de cargas de aplicaciones externo.
De forma predeterminada, el proxy de destino no conserva la dirección IP de cliente original y la información del puerto. Para conservar esta información, habilita el protocolo PROXY en el proxy de destino.
En la siguiente tabla, se muestran los requisitos de proxy de destino para los balanceadores de cargas de red de proxy externos.
| Modo de balanceador de cargas | Nivel de servicio de red | Proxy de destino |
|---|---|---|
| Balanceador de cargas de red de proxy clásico | Nivel Premium | targetTcpProxies o targetSslProxies |
| Nivel Estándar | targetTcpProxies o targetSslProxies |
|
| Balanceador de cargas de red del proxy externo global | Nivel Premium | targetTcpProxies o targetSslProxies |
| Balanceador de cargas de red del proxy externo regional | Nivel Premium y Estándar | regionTargetTcpProxies |
Certificados SSL
Los certificados SSL solo son necesarios si implementas un balanceador de cargas de red del proxy externo global y un balanceador de cargas de red del proxy clásico con un proxy SSL de destino.
Los balanceadores de cargas de red del proxy externo que usan proxies SSL de destino requieren claves privadas y certificados SSL como parte de la configuración del balanceador de cargas:
Google Cloud proporciona dos métodos de configuración para asignar claves privadas y certificados SSL a los proxies SSL de destino: los certificados SSL de Compute Engine y el Administrador de certificados. Para obtener una descripción de cada configuración, consulta Métodos de configuración de certificados en la descripción general de certificados SSL.
Google Cloud proporciona dos tipos de certificado: autoadministrados y administrados por Google. Para obtener una descripción de cada tipo, consulta Tipos de certificados en la descripción general de certificados SSL.
Servicios de backend
Los servicios de backend dirigen el tráfico entrante a uno o más backends adjuntos. Cada backend está compuesto por un grupo de instancias o un grupo de extremos de red, además de información sobre la capacidad de entrega del backend. La capacidad de entrega del backend se puede basar en CPU o en solicitudes por segundo (RPS).
Cada balanceador de cargas tiene un solo recurso de servicio de backend que especifica la verificación de estado que se realizará para los backends disponibles.
Los cambios que se realicen en el servicio de backend no son instantáneos. Los cambios pueden demorar varios minutos en propagarse a los GFE. Para garantizar interrupciones mínimas a tus usuarios, puedes habilitar el vaciado de conexiones en los servicios de backend. Estas interrupciones pueden ocurrir cuando un backend se finaliza, se quita de forma manual, o lo quita un escalador automático. Si quieres obtener más información sobre el uso del vaciado de conexiones para minimizar las interrupciones del servicio, consulta Habilita el vaciado de conexiones.
Para obtener más información sobre el recurso de servicio de backend, consulta Descripción general de los servicios de backend.
En la siguiente tabla, se especifican los diferentes backends compatibles con el servicio de backend de los balanceadores de cargas de red del proxy externo.
| Modo de balanceador de cargas | Backends compatibles en un servicio de backend | ||||||
|---|---|---|---|---|---|---|---|
| Grupos de instancias | NEG zonales | NEG de Internet | NEG sin servidores | NEG híbridos | NEGs de Private Service Connect | GKE | |
| Balanceador de cargas de red de proxy clásico | Usa NEG zonales independientes | ||||||
| Balanceador de cargas de red del proxy externo global | * | GCE_VM_IP_PORT Extremos de tipo * |
|||||
| Balanceador de cargas de red del proxy externo regional | Extremos de tipo GCE_VM_IP_PORT |
Solo NEG regionales | Agrega un NEG de Private Service Connect | ||||
* Los balanceadores de cargas de red del proxy externo global admiten grupos de instancias IPv4 e IPv6 (pila doble) y backends de NEG zonales con extremos GCE_VM_IP_PORT.
Backends y redes de VPC
Las restricciones sobre dónde se pueden ubicar los backends dependen del tipo de balanceador de cargas.
Para el balanceador de cargas de red del proxy externo global y el balanceador de cargas de red del proxy clásico, todas las instancias de backend de los backends de grupos de instancias y todos los extremos de backend de los backends de NEG deben estar ubicados en el mismo proyecto. Sin embargo, un backend de grupo de instancias o un NEG pueden usar una red de VPC diferente en ese proyecto. No es necesario que las diferentes redes de VPC estén conectadas a través del intercambio de tráfico entre redes de VPC, ya que los GFEs se comunican de forma directa con los backends en sus respectivas redes de VPC.
En el caso del balanceador de cargas de red del proxy externo regional, esto depende del tipo de backend.
Para los grupos de instancias, los NEGs zonales y los NEG de conectividad híbrida, todos los backends deben estar ubicados en el mismo proyecto y región que el servicio de backend. Sin embargo, un balanceador de cargas puede hacer referencia a un backend que usa una red de VPC diferente en el mismo proyecto que el servicio de backend (esta función está en versión preliminar). La conectividad entre la red de VPC del balanceador de cargas y la red de VPC del backend se puede configurar mediante el intercambio de tráfico entre redes de VPC, túneles de Cloud VPN, adjuntos de VLAN de Cloud Interconnect o un framework de Network Connectivity Center.
Definición de la red de backend
- En el caso de los NEGs zonales y los híbridos, debes especificar de forma explícita la red de VPC cuando creas el NEG.
- En los grupos de instancias administrados, la red de VPC se define en la plantilla de instancias.
- En los grupos de instancias no administrados, la red de VPC del grupo de instancias se configura para que coincida con la red de VPC de la interfaz
nic0de la primera VM que se agrega al grupo de instancias.
Requisitos de red del backend
La red de tu backend debe satisfacer uno de los siguientes requisitos de red:
La red de VPC del backend debe coincidir exactamente con la red de VPC de la regla de reenvío.
La red de VPC del backend debe estar conectada a la red de VPC de la regla de reenvío mediante el intercambio de tráfico entre redes de VPC. Debes configurar intercambios de rutas de subred para permitir la comunicación entre la subred de solo proxy en la red de VPC de la regla de reenvío y las subredes que usan las instancias o los extremos de backend.
- Tanto la red de VPC del backend como la red de VPC de la regla de reenvío deben ser radios de VPC en el mismo concentrador de Network Connectivity Center. Los filtros de importación y exportación deben permitir la comunicación entre la subred de solo proxy en la red de VPC de la regla de reenvío y las subredes que usan las instancias o los extremos de backend.
- Para todos los demás tipos de backends, todos deben estar ubicados en la misma red de VPC y región.
Interfaces de red y backends
Si usas backends de grupos de instancias, los paquetes siempre se entregan a nic0. Si quieres enviar paquetes a diferentes NICs, usa backends de NEG en su lugar.
Si usas backends de NEG zonales, los paquetes se envían a cualquier interfaz de red que represente el extremo en el NEG. Los extremos del NEG deben estar en la misma red de VPC que la red de VPC definida explícitamente en el NEG.
Protocolo para comunicarse con los backends
Cuando configuras un servicio de backend para un balanceador de cargas de red del proxy externo, configuras el protocolo que usa el servicio de backend a fin de comunicarse con estos.
- Para los balanceadores de cargas de red del proxy clásico, puedes elegir TCP o SSL.
- Para los balanceadores de cargas de red del proxy externo global, puedes elegir TCP o SSL.
- Para los balanceadores de cargas de red del proxy externo regional, puedes usar TCP.
El balanceador de cargas solo usa el protocolo que especifiques y no intenta negociar una conexión con el otro protocolo.
Reglas de firewall
Se requieren las siguientes reglas de firewall:
Para los balanceadores de cargas de red del proxy externo clásico, se necesita una regla de firewall de entrada
allowque permita que el tráfico de los GFE llegue a tus backends.Para los balanceadores de cargas de red del proxy externo global, se necesita una regla de firewall de entrada
allowque permita que el tráfico de los GFE llegue a tus backends.
Para los balanceadores de cargas de red del proxy externo regional, se necesita una regla de firewall de entrada que permita que el tráfico de la subred de solo proxy llegue a tus backends.
Una regla de firewall
allowde entrada para permitir que el tráfico de los rangos de sondeo de verificación de estado llegue a tus backends. Para obtener más información sobre los sondeos de verificación de estado y por qué es necesario permitir el tráfico, consulta Rangos de IP del sondeo y reglas de firewall.
Las reglas de firewall se implementan a nivel de la instancia de VM, no en el nivel de los proxies de GFE. No puedes usar reglas de firewall para evitar que el tráfico llegue al balanceador de cargas.
Los puertos de estas reglas de firewall deben configurarse de la siguiente manera:
- Permite el tráfico al puerto de destino para cada verificación de estado del servicio de backend.
- Para los backends de grupos de instancias: determina los puertos que se configurarán mediante la asignación entre el puerto con nombre del servicio de backend y los números de puerto asociados con ese puerto con nombre en cada grupo de instancias. Los números pueden variar entre grupos de instancias asignados al mismo servicio de backend.
- Para los backends de NEG zonal
GCE_VM_IP_PORT NEG: permite el tráfico a los números de puerto de los extremos.
En la siguiente tabla, se resumen los rangos de direcciones IP de origen necesarios para las reglas de firewall.
| Modo de balanceador de cargas | Rangos de origen de la verificación de estado | Rangos de origen de solicitud |
|---|---|---|
| Balanceador de cargas de red del proxy externo global |
Para el tráfico IPv6 a los backends:
|
La fuente de tráfico del GFE depende del tipo de backend:
|
| Balanceador de cargas de red de proxy clásico |
|
Estos rangos se aplican a los sondeos de verificación de estado y a las solicitudes del GFE. |
| Balanceador de cargas de red de proxy externo regional *, † |
Para el tráfico IPv6 a los backends:
|
Estos rangos se aplican a los sondeos de verificación de estado. |
* No se requiere incluir en la lista de entidades permitidas los rangos de sondeo de verificación de estado de Google para los NEG híbridos. Sin embargo, si usas una combinación de NEG híbridos y zonales en un solo servicio de backend, debes incluir en la lista de entidades permitidas los rangos de sondeo de verificación de estado de Google para los NEG zonales.
† Para los NEGs de Internet regionales, las verificaciones de estado son opcionales. El tráfico de los balanceadores de cargas que usan NEGs de Internet regionales se origina desde la subred de solo proxy y, luego, se traduce con NAT (mediante Cloud NAT) a cualquiera de los manuales o direcciones IP de NAT asignadas automáticamente. Este tráfico incluye sondeos de verificación de estado y solicitudes de usuario del balanceador de cargas a los backends. Para obtener más detalles, consulta NEG regionales: Usa Cloud NAT para la salida.
Direcciones IP de origen
La dirección IP de origen de los paquetes, como la ven los backends, no es la dirección IP externa de Google Cloud del balanceador de cargas. En otras palabras, existen dos conexiones TCP.
Para los balanceadores de cargas de red del proxy externo clásico y los balanceadores de cargas de red del proxy externo global:Sesión 1, que abarca desde el cliente original hasta el balanceador de cargas (GFE):
- Dirección IP de origen: Es el cliente original (o la dirección IP externa si el cliente usa NAT o un proxy de reenvío).
- Dirección IP de destino: Es la dirección IP del balanceador de cargas.
Conexión 2, desde el balanceador de cargas (GFE) hasta el extremo o la VM de backend:
Dirección IP de origen: Es una dirección IP en uno de los rangos especificados en Reglas de firewall.
Dirección IP de destino: La dirección IP interna del contenedor o la VM de backend en la red de VPC.
Conexión 1, desde el cliente original hasta el balanceador de cargas (subred de solo proxy):
- Dirección IP de origen: Es el cliente original (o la dirección IP externa si el cliente usa NAT o un proxy de reenvío).
- Dirección IP de destino: Es la dirección IP del balanceador de cargas.
Conexión 2, desde el balanceador de cargas (subred de solo proxy) hasta la VM o el extremo de backend:
Dirección IP de origen: Una dirección IP en la subred de solo proxy que se comparte entre todos los balanceadores de cargas basados en Envoy implementados en la misma región y la red como el balanceador de cargas.
Dirección IP de destino: La dirección IP interna del contenedor o la VM de backend en la red de VPC.
Puertos abiertos
Los balanceadores de cargas de red del proxy externo son balanceadores de cargas del proxy inverso. El balanceador de cargas finaliza las conexiones entrantes y abre conexiones nuevas del balanceador de cargas a los backends. Estos balanceadores de cargas se implementan mediante proxies de Google Front End (GFE) en todo el mundo.
Los GFE tienen varios puertos abiertos para admitir otros servicios de Google que se ejecutan en la misma arquitectura. Cuando ejecutas un análisis de puerto, es posible que veas otros puertos abiertos para otros servicios de Google que se ejecutan en GFE.
Ejecutar un análisis de puerto en la dirección IP de un balanceador de cargas basado en GFE no es útil desde la perspectiva de la auditoría por los siguientes motivos:
Por lo general, un análisis de puerto (por ejemplo, con
nmap) no espera ningún paquete de respuesta o un paquete RST de TCP cuando realiza sondeos de TCP SYN. Los GFE enviarán paquetes SYN-ACK en respuesta a los sondeos de SYN solo para los puertos en los que configuraste una regla de reenvío. Los GFE solo envían paquetes a tus backends en respuesta a los paquetes enviados a la dirección IP del balanceador de cargas y al puerto de destino configurado en su regla de reenvío. Los paquetes que se envían a una dirección IP o un puerto diferentes no se envían a los backends.Los GFE implementan funciones de seguridad como Google Cloud Armor. Con Google Cloud Armor Standard, los GFE proporcionan protección siempre encendida contra ataques de DSD volumétricos basados en protocolos y desbordamientos SYN. Esta protección está disponible incluso si no configuraste Google Cloud Armor de forma explícita. Solo se te cobrará si configuras políticas de seguridad o si te inscribes en Managed Protection Plus.
Cualquier GFE en la flota de Google puede responder a los paquetes enviados a la dirección IP de tu balanceador de cargas. Sin embargo, el análisis de una combinación de direcciones IP del balanceador de cargas y del puerto de destino solo intercepta un solo GFE por conexión TCP. La dirección IP de tu balanceador de cargas no se asigna a un solo dispositivo o sistema. Por lo tanto, analizar la dirección IP de un balanceador de cargas basado en GFE no analiza todos los GFE de la flota de Google.
Con esto en mente, las siguientes son algunas formas más efectivas de auditar la seguridad de tus instancias de backend:
Un auditor de seguridad debe inspeccionar la configuración de reglas de reenvío para la configuración del balanceador de cargas. Las reglas de reenvío definen el puerto de destino para el que tu balanceador de cargas acepta paquetes y los reenvía a los backends. Para los balanceadores de cargas basados en GFE, cada regla de reenvío externo solo puede hacer referencia a un solo puerto TCP de destino.
Un auditor de seguridad debe inspeccionar la configuración de la regla de firewall aplicable a las VMs de backend. Las reglas de firewall que configuras bloquean el tráfico desde los GFE hacia las VMs de backend, pero no bloquean el tráfico entrante a los GFE. Para conocer las prácticas recomendadas, consulta la sección de reglas de firewall.
Arquitectura de VPC compartida
Los balanceadores de cargas de red del proxy externo regional y los balanceadores de cargas de red del proxy clásico admiten implementaciones que usan redes de VPC compartida. La VPC compartida te permite mantener una separación clara de las responsabilidades entre los administradores de red y los desarrolladores de servicios. Tus equipos de desarrollo pueden enfocarse en compilar servicios en proyectos de servicio, y los equipos de infraestructura de red pueden aprovisionar y administrar el balanceo de cargas. Si aún no estás familiarizado con la VPC compartida, lee la Documentación de la descripción general de la VPC compartida.
| Dirección IP | Regla de reenvío | Proxy de destino | Componentes de backend |
|---|---|---|---|
| Se debe definir una dirección IP externa en el mismo proyecto que el balanceador de cargas. | La regla de reenvío externa debe definirse en el mismo proyecto que las instancias de backend (el proyecto de servicio). | El proxy TCPo SSL de destino debe definirse en el mismo proyecto que las instancias de backend. |
Para los balanceadores de cargas de red del proxy clásico, se debe definir un servicio de backend global en el mismo proyecto que las instancias de backend. Estas instancias deben estar en grupos de instancias conectadas al servicio de backend como backends. Las verificaciones de estado asociadas con los servicios de backend deben definirse en el mismo proyecto que el servicio de backend. Para los balanceadores de cargas de red del proxy externo regional, las VM de backend se suelen ubicar en un proyecto de servicio. En ese proyecto de servicio, debe definirse un servicio de backend regional y una verificación de estado. |
Distribución del tráfico
Cuando agregas un grupo de instancias de backend o un NEG a un servicio de backend, debes especificar un modo de balanceo de cargas, que define un método que mide la carga de backend y una capacidad objetivo.
Para los balanceadores de cargas de red del proxy externs, el modo de balanceo puede ser CONNECTION o UTILIZATION:
- Si el modo de balanceo de cargas es
CONNECTION, la carga se distribuye según la cantidad total de conexiones que puede controlar el backend. - Si el modo de balanceo de cargas es
UTILIZATION, la carga se distribuye según el uso de instancias en un grupo de instancias. Este modo de balanceo se aplica solo a los backends de grupos de instancias de VM.
La distribución del tráfico entre backends se determina según el modo de balanceo del balanceador de cargas.
Balanceador de cargas de red del proxy clásico
Para el balanceador de cargas de red del proxy clásico, el modo de balanceo se usa a fin de seleccionar el backend más favorable (grupo de instancias o NEG). Luego, el tráfico se distribuye de forma round robin entre las instancias o los extremos dentro del backend.
Cómo se distribuyen las conexiones
Un balanceador de cargas de red del proxy clásico se puede configurar como un servicio de balanceo de cargas global con el nivel Premium y como un servicio regional en el nivel Estándar.
El modo de balanceo y la elección del destino determinan la capacidad total del backend desde la perspectiva de cada NEG zonal GCE_VM_IP_PORT, grupo de instancias zonal o zona de un grupo de instancias regional. Luego, el tráfico se distribuye dentro de una zona con
un hash coherente.
Para el nivel Premium:
Solo puedes tener un servicio de backend, y este puede tener backends en varias regiones. Para el balanceo de cargas global, implementas tus backends en varias regiones, y el balanceador de cargas dirige automáticamente el tráfico a la región más cercana al usuario. Si una región está al máximo de capacidad, el balanceador de cargas dirige de forma automática las conexiones nuevas a otra región con capacidad disponible. Las conexiones de los usuarios existentes permanecen en la región actual.
Google hace pública la dirección IP del balanceador de cargas desde todos los puntos de presencia y en todo el mundo. Cada dirección IP del balanceador de cargas es Anycast global.
Si configuras un servicio de backend con backends en varias regiones, Google Front End (GFE) intenta dirigir las solicitudes a grupos de instancias de backend o NEG en buen estado en la región más cercana al usuario.
Para el nivel Estándar:
Google hace pública la dirección IP del balanceador de cargas desde los puntos de presencia asociados con la región de la regla de reenvío. El balanceador de cargas usa una dirección IP externa regional.
Solo puedes configurar backends en la misma región que la regla de reenvío. El balanceador de cargas solo dirige las solicitudes a backends en buen estado en esa región.
Balanceador de cargas de red del proxy externo global
Para el balanceador de cargas de red del proxy externo global, la distribución del tráfico se basa en el modo de balanceo de cargas y la política del balanceo de cargas de la localidad.
El modo de balanceo determina el peso o la fracción del tráfico que se debe enviar a cada grupo (grupo de instancias o NEG). La política de localidad del balanceo de cargas (LocalityLbPolicy) determina cómo se balancean las cargas del backend dentro del grupo.
Cuando un servicio de backend recibe tráfico, primero lo dirige a un backend (grupo de instancias o NEG) según el modo de balanceo del backend. Después de seleccionar un backend, el tráfico se distribuye entre instancias o extremos en ese grupo de backend de acuerdo con la política de localidad del balanceo de cargas.
Para obtener más información, consulta lo siguiente:
- Modo de balanceo.
- Política de balanceo de cargas de la localidad (documentación de la API de servicio de backend regional).
Cómo se distribuyen las conexiones
Un balanceador de cargas de red del proxy externo global se puede configurar como un servicio de balanceo de cargas global con el nivel Premium.
El modo de balanceo y la elección del destino determinan la capacidad total del
backend desde la perspectiva de cada NEG zonal GCE_VM_IP_PORT o grupo de instancias zonal.
Luego, el tráfico se distribuye dentro de una zona con un hash coherente.
Solo puedes tener un servicio de backend, y este puede tener backends en varias regiones. Para el balanceo de cargas global, implementas tus backends en varias regiones, y el balanceador de cargas dirige automáticamente el tráfico a la región más cercana al usuario. Si una región está al máximo de capacidad, el balanceador de cargas dirige de forma automática las conexiones nuevas a otra región con capacidad disponible. Las conexiones de los usuarios existentes permanecen en la región actual.
Google hace pública la dirección IP del balanceador de cargas desde todos los puntos de presencia y en todo el mundo. Cada dirección IP del balanceador de cargas es Anycast global.
Si configuras un servicio de backend con backends en varias regiones, Google Front End (GFE) intenta dirigir las solicitudes a grupos de instancias de backend o NEG en buen estado en la región más cercana al usuario.
Balanceador de cargas de red del proxy externo regional
Para los balanceadores de cargas de red del proxy externo regional, la distribución del tráfico se basa en el modo de balanceo de cargas y la política de localidad del balanceo de cargas.
El modo de balanceo determina el peso y la fracción del tráfico que se debe enviar a cada backend (grupo de instancias o NEG). La política de localidad del balanceo de cargas (LocalityLbPolicy) determina cómo se balancean las cargas del backend dentro del grupo.
Cuando un servicio de backend recibe tráfico, primero lo dirige a un backend (grupo de instancias o NEG) según su modo de balanceo. Después de seleccionar un backend, el tráfico se distribuye entre instancias o extremos en ese grupo de backend de acuerdo con la política de localidad del balanceo de cargas.
Para obtener más información, consulta lo siguiente:
- Modos de balanceo
- Política de balanceo de cargas de la localidad (documentación de la API de servicio de backend regional).
Afinidad de sesión
La afinidad de sesión envía todas las solicitudes del mismo cliente al mismo backend si este se encuentra en buen estado y tiene capacidad.
Los balanceadores de cargas de red del proxy externo ofrecen los siguientes tipos de afinidad de sesión:
NONE. No se configuró la afinidad de sesión para el balanceador de cargas.- Afinidad de IP de cliente, que reenvía todas las solicitudes de la misma dirección IP de cliente al mismo backend.
Conmutación por error
La conmutación por error para los balanceadores de cargas de red del proxy externo funciona de la siguiente manera:
- Si un backend se encuentra en mal estado, el tráfico se redireccionará de forma automática a los backends en buen estado dentro de la misma región.
- Si todos los backends de una región están en mal estado, el tráfico se distribuirá a los backends en buen estado en otras regiones (solo modos global y clásico).
- Si todos los backends están en mal estado, el balanceador de cargas descartará el tráfico.
Balanceo de cargas para aplicaciones de GKE
Si compilas aplicaciones en Google Kubernetes Engine, puedes usar NEG independientes para balancear las cargas del tráfico directamente a los contenedores. Con los NEG independientes, eres responsable de crear el objeto Service que crea el NEG y, luego, asociar el NEG con el servicio de backend para que el balanceador de cargas pueda se conectan a los Pods.
Para obtener documentación relacionada, consulta Balanceo de cargas nativo del contenedor mediante NEG zonales independientes.
Limitaciones
- No puedes crear un balanceador de cargas de red de proxy externo regional en el nivel Premium con la consola de Google Cloud. Además, solo las regiones que admiten el nivel estándar están disponibles para estos balanceadores de cargas en la consola de Google Cloud. En su lugar, usa gcloud CLI o la API.
Las siguientes limitaciones se aplican solo a los balanceadores de cargas de red de proxy clásico y al balanceador de cargas de red de proxy externo global que se implementan con un proxy de destino SSL:
Los balanceadores de cargas de red del proxy clásico y los balanceadores de cargas de red del proxy externo global no admiten la autenticación basada en certificados de cliente, también denominada autenticación TLS mutua.
Los balanceadores de cargas de red del proxy clásico y los balanceadores de cargas de red del proxy externo global solo admiten caracteres en minúsculas en dominios en un atributo de nombre común (
CN) o un nombre de entidad alternativo (SAN) del certificado. Los certificados con caracteres en mayúscula en los dominios solo se muestran cuando se configuran como el certificado principal en el proxy de destino.
¿Qué sigue?
- Configura un balanceador de cargas de red de proxy externo (proxy TCP).
- Configura un balanceador de cargas de red de proxy externo (proxy SSL).
- Configura un balanceador de cargas de red del proxy externo global (proxy TCP).
- Configura un balanceador de cargas de red del proxy externo global (proxy SSL).
- Configura un balanceador de cargas de red del proxy externo regional (proxy TCP).
- Registro y supervisión del balanceador de cargas de red del proxy.