En este documento se presentan los conceptos que debes conocer para configurar un balanceador de carga de red de proxy externo. Google Cloud
El balanceador de carga de red del proxy externo es un balanceador de carga de proxy inverso que distribuye el tráfico TCP procedente de Internet a las instancias de máquinas virtuales (VM) de tuGoogle Cloud red de nube privada virtual (VPC). Cuando se usa un balanceador de carga de red de proxy externo, el tráfico TCP o SSL entrante se termina en el balanceador de carga. A continuación, una nueva conexión reenvía el tráfico al backend disponible más cercano mediante TCP o SSL (opción recomendada). Para ver más casos prácticos, consulta la descripción general del balanceador de carga de red de proxy.
Los balanceadores de carga de red con proxy externo te permiten usar una sola dirección IP para todos los usuarios del mundo. El balanceador de carga dirige automáticamente el tráfico a los back-ends que están más cerca del usuario.
En este ejemplo, el tráfico SSL de los usuarios de la ciudad A y la ciudad B se termina en la capa de balanceo de carga y se establece una conexión independiente con el backend seleccionado.
Modos de funcionamiento
Puede configurar un balanceador de carga de red de proxy externo en los siguientes modos:
- Un balanceador de carga de red con proxy clásico se implementa en Google Front Ends (GFEs) distribuidos a nivel mundial. Este balanceador de carga se puede configurar para gestionar el tráfico TCP o SSL mediante un proxy TCP de destino o un proxy SSL de destino, respectivamente. Con el nivel Premium, este balanceador de carga se puede configurar como un servicio de balanceo de carga global. Con el nivel Estándar, este balanceador de carga se configura como un servicio de balanceo de carga regional. Los balanceadores de carga de red de proxy clásicos también se pueden usar con otros protocolos que usen SSL, como WebSockets e IMAP sobre SSL.
- Un balanceador de carga de red con proxy externo global se implementa en GFEs distribuidos por todo el mundo y admite funciones de gestión de tráfico avanzada. Este balanceador de carga se puede configurar para gestionar el tráfico TCP o SSL mediante un proxy TCP de destino o un proxy SSL de destino, respectivamente. Este balanceador de carga está configurado como un servicio de balanceo de carga global con el nivel Premium. Los balanceadores de carga de red con proxy externo global también se pueden usar con otros protocolos que utilizan SSL, como WebSockets e IMAP sobre SSL.
- Un balanceador de carga de red de proxy externo regional se implementa en la pila de software de código abierto proxy Envoy. Solo puede gestionar el tráfico TCP. Este balanceador de carga está configurado como un servicio de balanceo de carga regional que puede usar el nivel Premium o el Estándar.
Identificar el modo
Para determinar el modo de un balanceador de carga, sigue estos pasos:
Consola
En la Google Cloud consola, ve a la página Balanceo de carga.
En la pestaña Balanceadores de carga, se muestran el tipo, el protocolo y la región del balanceador de carga. Si la región está en blanco, el balanceador de carga es global.
En la siguiente tabla se resume cómo identificar el modo del balanceador de carga.
Modo del balanceador de carga Tipo de balanceador de carga Tipo de acceso Región Balanceador de carga de red de proxy clásico Red (proxy clásico) Externo Balanceador de carga de red con proxy externo global Red (proxy) Externo Balanceador de carga de red con 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, comprueba el esquema de balanceo de carga, la región y el nivel de red. En la siguiente tabla se resume cómo identificar el modo del balanceador de carga.
Modo del balanceador de carga Esquema de balanceo de carga Regla de reenvío Nivel de red Balanceador de carga de red de proxy clásico EXTERNO Global Estándar o Premium Balanceador de carga de red con proxy externo global EXTERNAL_MANAGED Global Premium Balanceador de carga de red con proxy externo regional EXTERNAL_MANAGED Regional Estándar o Premium
Arquitectura
En los siguientes diagramas se muestran los componentes de los balanceadores de carga de red de proxy externos.
Global
En este diagrama se muestran los componentes de una implementación de un balanceador de carga de red con proxy externo global. Esta arquitectura se aplica tanto al balanceador de carga de red con proxy externo global como al balanceador de carga de red con proxy clásico en el nivel Premium.
Regional
En este diagrama se muestran los componentes de una implementación de un balanceador de carga de red de proxy externo regional.
Estos son los componentes de los balanceadores de carga de red de proxy externo.
Subred de solo proxy
Nota: Las subredes de solo proxy solo son necesarias para los balanceadores de carga de red de proxy externos regionales.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 carga. La marca --purpose de esta subred de solo proxy se ha definido como REGIONAL_MANAGED_PROXY. Todos los balanceadores de carga regionales basados en Envoy de la misma región y red VPC comparten un grupo de proxies Envoy de la misma subred de solo proxy.
Las VMs o los endpoints de backend de todos los balanceadores de carga de una región y una red de VPC reciben conexiones de la subred de solo proxy.
Aspectos que debes tener en cuenta:
- Las subredes de solo proxy se usan únicamente para los proxies de Envoy, no para tus back-ends.
- La dirección IP del balanceador de carga no se encuentra en la subred de solo proxy. La dirección IP del balanceador de carga se define mediante su regla de reenvío gestionada externa.
Reglas de reenvío y direcciones IP
Las reglas de reenvío dirigen el tráfico a una configuración de balanceo de carga según la dirección IP, el puerto y el protocolo. Esta configuración consta de 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 que puedas usar o dejar que Cloud Load Balancing te asigne una. Te recomendamos que reserves una dirección IP estática. De lo contrario, deberá actualizar su registro DNS con la dirección IP efímera recién asignada cada vez que elimine una regla de reenvío y cree una nueva.
Especificación de puerto. Las reglas de reenvío externas que se usan en la definición de este balanceador de carga pueden hacer referencia exactamente a un puerto del intervalo 1-65535. Si quieres 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 proxyizar varias aplicaciones con puertos personalizados independientes a la misma dirección IP virtual de proxy TCP. Para obtener más información, consulta las especificaciones de los puertos para las 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 un proxy para varias aplicaciones con puertos personalizados independientes en la misma dirección IP virtual de proxy TCP.
En la siguiente tabla se muestran los requisitos de las reglas de reenvío de los balanceadores de carga de red de proxy externos.
| Modo del balanceador de carga | Nivel de servicio de red | Regla de reenvío, dirección IP y esquema de balanceo de carga | Enrutamiento de Internet al frontend del balanceador de carga |
|---|---|---|---|
| Balanceador de carga de red de proxy clásico | Nivel premium | Regla de reenvío externa global Esquema de balanceo de carga: |
Solicitudes dirigidas a los GFEs más cercanos al cliente en Internet. |
| Nivel Estándar | Regla de reenvío externa regional Esquema de balanceo de carga: |
Las solicitudes se enrutan a un GFE en la región del balanceador de carga. | |
| Balanceador de carga de red con proxy externo global | Nivel premium | Regla de reenvío externa global Esquema de balanceo de carga: |
Solicitudes dirigidas a los GFEs más cercanos al cliente en Internet. |
| Balanceador de carga de red con proxy externo regional | Niveles Premiumy Estándar | Regla de reenvío externa regional Esquema de balanceo de carga: |
Solicitudes enrutadas a los proxies de Envoy de la misma región que el balanceador de carga. |
Reglas de reenvío y redes de VPC
En esta sección se describe cómo se asocian las reglas de reenvío que usan los balanceadores de carga de aplicaciones externos con las redes de VPC.
| Modo del balanceador de carga | Asociación de redes VPC |
|---|---|
| Balanceador de carga de red con proxy externo global Balanceador de carga de red con proxy clásico |
No hay ninguna red de VPC asociada. La regla de reenvío siempre usa una dirección IP que está fuera de la red VPC. Por lo tanto, la regla de reenvío no tiene ninguna red de VPC asociada. |
| Balanceador de carga de red con proxy externo regional | La red VPC de la regla de reenvío es la red en la que se ha creado la subred de solo proxy. La red se especifica al crear la regla de reenvío. |
Proxies de destino
Los balanceadores de carga de red de proxy externos finalizan las conexiones del cliente y crean nuevas conexiones con los back-ends. El proxy de destino dirige estas nuevas conexiones al servicio de backend.
En función del tipo de tráfico que tenga que gestionar tu aplicación, puedes configurar un balanceador de carga de red de proxy externo con un proxy TCP de destino o un proxy SSL de destino.
- Proxy TCP de destino: configura el balanceador de carga con un proxy TCP de destino si esperas tráfico TCP.
- Proxy SSL de destino: configura el balanceador de carga con un proxy SSL de destino si esperas tráfico de cliente cifrado. Este tipo de balanceador de carga solo está diseñado para el tráfico que no sea HTTP(S). Para el tráfico HTTP(S), te recomendamos que uses un balanceador de carga de aplicaciones externo.
De forma predeterminada, el proxy de destino no conserva la dirección IP del cliente original ni la información del puerto. Para conservar esta información, puedes habilitar el protocolo PROXY en el proxy de destino.
En la siguiente tabla se muestran los requisitos del proxy de destino de los balanceadores de carga de red de proxy externo.
| Modo del balanceador de carga | Nivel de servicio de red | Proxy de destino |
|---|---|---|
| Balanceador de carga de red de proxy clásico | Nivel premium | targetTcpProxies o targetSslProxies |
| Nivel Estándar | targetTcpProxies o targetSslProxies |
|
| Balanceador de carga de red con proxy externo global | Nivel premium | targetTcpProxies o targetSslProxies |
| Balanceador de carga de red con proxy externo regional | Nivel Premium y Estándar | regionTargetTcpProxies |
Certificados SSL
Los certificados SSL solo son obligatorios si implementas un balanceador de carga de red con proxy externo global y un balanceador de carga de red con proxy clásico con un proxy SSL de destino.
Los balanceadores de carga de red de proxy externos que usan proxies SSL de destino requieren claves privadas y certificados SSL como parte de la configuración del balanceador de carga.
Google Cloud ofrece dos métodos de configuración para asignar claves privadas y certificados SSL a proxies SSL de destino: certificados SSL de Compute Engine y Certificate Manager. Para ver una descripción de cada configuración, consulta Métodos de configuración de certificados en la información general sobre los certificados SSL.
Google Cloud proporciona dos tipos de certificados: autogestionados y gestionados por Google. Para ver una descripción de cada tipo, consulta Tipos de certificados en la información general sobre los certificados SSL.
Servicios de backend
Los servicios de backend dirigen el tráfico entrante a uno o varios backends conectados. Cada backend se compone de un grupo de instancias o un grupo de puntos finales de red, así como de información sobre la capacidad de servicio del backend. La capacidad de servicio del backend puede basarse en la CPU o en las solicitudes por segundo (SPS).
Cada balanceador de carga tiene un único recurso de servicio de backend que especifica la comprobación del estado que se debe realizar en los backends disponibles.
Los cambios realizados en el servicio de backend no son instantáneos. Los cambios pueden tardar varios minutos en propagarse a los GFE. Para minimizar las interrupciones para tus usuarios, puedes habilitar el drenaje de conexiones en los servicios de backend. Estas interrupciones pueden producirse cuando se termina un backend, se elimina manualmente o se elimina mediante un escalador automático. Para obtener más información sobre cómo usar la purga de conexiones para minimizar las interrupciones del servicio, consulta Habilitar la purga de conexiones.
Para obtener más información sobre el recurso de servicio backend, consulta el artículo Descripción general de los servicios backend.
En la siguiente tabla se especifican los diferentes backends admitidos en el servicio de backend de los balanceadores de carga de red de proxy externo.
| Modo del balanceador de carga | Backends admitidos en un servicio backend | ||||||
|---|---|---|---|---|---|---|---|
| Grupos de instancias | NEGs por zonas | NEGs de Internet | NEGs sin servidor | NEGs híbridas | NEGs de Private Service Connect | GKE | |
| Balanceador de carga de red de proxy clásico | Usar NEGs por zonas independientes | ||||||
| Balanceador de carga de red con proxy externo global | * | GCE_VM_IP_PORT type
endpoints * |
|||||
| Balanceador de carga de red con proxy externo regional | Endpoints de tipo GCE_VM_IP_PORT |
Solo NEGs regionales | Añadir un NEG de Private Service Connect | ||||
* Los balanceadores de carga de red con proxy externo global admiten grupos de instancias y backends de NEG zonales con GCE_VM_IP_PORT puntos finales IPv4 e IPv6 (de pila dual).
Back-ends y redes de VPC
En el caso de los backends de los balanceadores de carga de red con proxy externo global y de los balanceadores de carga de red con proxy clásico, todas las instancias de backend de los backends de grupos de instancias y todos los endpoints de backend de los backends de NEGs deben estar ubicados en el mismo proyecto. Sin embargo, un backend de grupo de instancias o un NEG pueden usar otra red de VPC en ese proyecto. No es necesario que las distintas redes VPC estén conectadas mediante el emparejamiento entre redes VPC, ya que los GFEs se comunican directamente con los back-ends de sus respectivas redes VPC.
En el caso de los backends de los balanceadores de carga de red con proxy externos regionales, se aplican las siguientes condiciones:
En el caso de los grupos de instancias, los NEGs zonales y los NEGs de conectividad híbrida, todos los backends deben estar ubicados en el mismo proyecto y en la misma región que el servicio de backend. Sin embargo, un balanceador de carga puede hacer referencia a un backend que utilice una red de VPC diferente en el mismo proyecto que el servicio de backend. La conectividad entre la red de VPC del balanceador de carga y la red de VPC de backend se puede configurar mediante el emparejamiento entre redes de VPC, los túneles de Cloud VPN, las vinculaciones de VLAN de Cloud Interconnect o un marco de Network Connectivity Center.
Definición de la red de backend
- En el caso de los NEG zonales y los NEG híbridos, debes especificar explícitamente la red de VPC al crear el NEG.
- En el caso de los grupos de instancias gestionados, la red VPC se define en la plantilla de instancia.
- En los grupos de instancias no gestionados, la red VPC del grupo de instancias se configura para que coincida con la red VPC de la interfaz
nic0de la primera VM que se añade al grupo de instancias.
Requisitos de red del backend
La red de tu backend debe cumplir 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 emparejamiento entre redes de VPC. Debes configurar los intercambios de rutas de subred para permitir la comunicación entre la subred solo proxy de la red de VPC de la regla de reenvío y las subredes que usan las instancias o los endpoints 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 conectados al mismo hub de Network Connectivity Center. Los filtros de importación y exportación deben permitir la comunicación entre la subred de solo proxy de la red de VPC de la regla de reenvío y las subredes que usan las instancias o los endpoints de backend.
En el resto de los tipos de backend, todos los backends deben estar ubicados en la misma red VPC y región.
Backends e interfaces de red
Si usas backends de grupos de instancias, los paquetes siempre se envían a nic0. Si quieres enviar paquetes a interfaces que no sean nic0 (ya sean NICs virtuales o interfaces de red dinámicas), usa back-ends de NEG.
Si usas backends de NEG por zonas, los paquetes se envían a la interfaz de red que represente el endpoint en el NEG. Los endpoints del NEG deben estar en la misma red VPC que la red VPC definida explícitamente del NEG.
Protocolo para comunicarse con los backends
Cuando configuras un servicio de backend para un balanceador de carga de red proxy externo, defines el protocolo que utiliza el servicio de backend para comunicarse con los backends.
- En los balanceadores de carga de red de proxy clásicos, puedes elegir entre TCP o SSL.
- En el caso de los balanceadores de carga de red con proxy externo global, puedes elegir entre TCP o SSL.
- En el caso de los balanceadores de carga de red de proxy externo regionales, puedes usar TCP.
El balanceador de carga solo usa el protocolo que especifiques y no intenta negociar una conexión con el otro protocolo.
Reglas de cortafuegos
Se necesitan las siguientes reglas de cortafuegos:
En el caso de los balanceadores de carga de red de proxy clásicos, una regla de cortafuegos de entrada
allowpara permitir que el tráfico de las GFEs llegue a tus backends.En el caso de los balanceadores de carga de red con proxy externo globales, una regla de cortafuegos de entrada
allowpara permitir que el tráfico de los GFE llegue a tus backends.
En el caso de los balanceadores de carga de red de proxy externos regionales, una regla de cortafuegos de entrada para permitir que el tráfico de la subred de solo proxy llegue a tus backends.
Una regla de cortafuegos de entrada
allowpara permitir que el tráfico de los intervalos de comprobación del estado llegue a tus backends. Para obtener más información sobre las sondas de comprobación del estado y por qué es necesario permitir el tráfico procedente de ellas, consulta Intervalos de IP de las sondas y reglas de cortafuegos.
Las reglas de cortafuegos se implementan a nivel de instancia de VM, no a nivel de proxies de GFE. No puedes usar reglas de cortafuegos para evitar que el tráfico llegue al balanceador de carga.
Los puertos de estas reglas de cortafuegos deben configurarse de la siguiente manera:
- Permite el tráfico al puerto de destino para la comprobación del estado de cada servicio de backend.
- En el caso de los backends de grupos de instancias, determine los puertos que se van a configurar mediante la asignación entre el puerto con nombre del servicio de backend y los números de puerto asociados a ese puerto con nombre en cada grupo de instancias. Los números de puerto pueden variar entre los grupos de instancias asignados al mismo servicio de backend.
- En el caso de los backends de NEG zonales
GCE_VM_IP_PORT NEG, permite el tráfico a los números de puerto de los endpoints.
En la siguiente tabla se resumen los intervalos de direcciones IP de origen necesarios para las reglas de cortafuegos.
| Modo del balanceador de carga | Intervalos de origen de las comprobaciones del estado | Intervalos de origen de la solicitud |
|---|---|---|
| Balanceador de carga de red con proxy externo global |
Para el tráfico IPv6 a los back-ends:
|
La fuente del tráfico de GFE depende del tipo de backend:
|
| Balanceador de carga de red de proxy clásico |
|
Estos intervalos se aplican a las comprobaciones de estado y a las solicitudes de GFE. |
| Balanceador de carga de red con proxy externo regional *, † |
Para el tráfico IPv6 a los back-ends:
|
Estos intervalos se aplican a las sondas de comprobación del estado. |
* No es necesario permitir el tráfico de los intervalos de sondeo de comprobación de estado de Google para los NEG híbridos. Sin embargo, si utilizas una combinación de NEGs híbridos y zonales en un mismo servicio de backend, debes permitir el tráfico de los intervalos de sondeo de comprobación de estado de Google para los NEGs zonales.
† En el caso de las NEGs de Internet regionales, las comprobaciones del estado son opcionales. El tráfico de los balanceadores de carga que usan NEGs de Internet regionales procede de la subred solo de proxy y, a continuación, se traduce mediante NAT (con Cloud NAT) a direcciones IP de NAT asignadas de forma manual o automática. Este tráfico incluye tanto las comprobaciones del estado como las solicitudes de los usuarios del balanceador de carga a los backends. Para obtener más información, consulta NEGs regionales: usar una pasarela de Cloud NAT.
Direcciones IP de origen
La dirección IP de origen de los paquetes, tal como la ven los backends, no es laGoogle Cloud dirección IP externa del balanceador de carga. En otras palabras, hay dos conexiones TCP.
En el caso de los balanceadores de carga de red de proxy clásicos y los balanceadores de carga de red de proxy externos globales:Conexión 1, del cliente original al balanceador de carga (GFE):
- Dirección IP de origen: el cliente original (o la dirección IP externa si el cliente está detrás de una pasarela NAT o un proxy de reenvío).
- Dirección IP de destino: la dirección IP de tu balanceador de carga.
Conexión 2, del balanceador de carga (GFE) a la máquina virtual o al endpoint de backend:
Dirección IP de origen: una dirección IP de uno de los intervalos especificados en Reglas de cortafuegos.
Dirección IP de destino: la dirección IP interna de la VM o el contenedor backend de la red de VPC.
Conexión 1, del cliente original al balanceador de carga (subred de solo proxy):
- Dirección IP de origen: el cliente original (o la dirección IP externa si el cliente está detrás de una pasarela NAT o un proxy de reenvío).
- Dirección IP de destino: la dirección IP de tu balanceador de carga.
Conexión 2, del balanceador de carga (subred de solo proxy) a la máquina virtual o el endpoint de backend:
Dirección IP de origen: una dirección IP de la subred solo proxy que comparten todos los balanceadores de carga basados en Envoy implementados en la misma región y red que el balanceador de carga.
Dirección IP de destino: la dirección IP interna de la VM o el contenedor backend de la red de VPC.
Puertos abiertos
Los balanceadores de carga de red de proxy externo son balanceadores de carga de proxy inverso. El balanceador de carga finaliza las conexiones entrantes y, a continuación, abre nuevas conexiones desde el balanceador de carga a los back-ends. Estos balanceadores de carga 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 puertos, es posible que veas otros puertos abiertos de otros servicios de Google que se ejecutan en GFE.
No es útil realizar un análisis de puertos en la dirección IP de un balanceador de carga basado en GFE desde el punto de vista de la auditoría por los siguientes motivos:
En un análisis de puertos (por ejemplo, con
nmap), normalmente no se espera ningún paquete de respuesta o un paquete TCP RST al realizar un sondeo TCP SYN. Los GFE solo envían paquetes SYN-ACK en respuesta a las sondas SYN de los puertos en los que haya configurado una regla de reenvío. Los GFE solo envían paquetes a tus back-ends en respuesta a los paquetes enviados a la dirección IP de tu balanceador de carga 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 tus back-ends.Los GFE implementan funciones de seguridad como Google Cloud Armor. Con Cloud Armor Standard, las GFEs ofrecen protección continua frente a ataques DDoS volumétricos y basados en protocolos, así como frente a inundaciones SYN. Esta protección está disponible aunque no hayas configurado Cloud Armor de forma explícita. Solo se te cobrará si configuras políticas de seguridad o si te registras en Managed Protection Plus.
Los paquetes enviados a la dirección IP de tu balanceador de carga pueden responderse con cualquier GFE de la flota de Google. Sin embargo, al analizar una combinación de dirección IP y puerto de destino de un balanceador de carga, solo se interroga a un GFE por conexión TCP. La dirección IP de tu balanceador de carga no se asigna a un solo dispositivo o sistema. Por lo tanto, al analizar la dirección IP de un balanceador de carga basado en GFE, no se analizan todos los GFEs de la flota de Google.
Teniendo esto en cuenta, a continuación se indican algunas formas más eficaces de auditar la seguridad de tus instancias de backend:
Un auditor de seguridad debe inspeccionar la configuración de las reglas de reenvío de la configuración del balanceador de carga. Las reglas de reenvío definen el puerto de destino para el que el balanceador de carga acepta paquetes y los reenvía a los backends. En los balanceadores de carga basados en GFE, cada regla de reenvío externa solo puede hacer referencia a un puerto TCP de destino.
Un auditor de seguridad debe inspeccionar la configuración de las reglas de cortafuegos aplicables a las VMs backend. Las reglas de cortafuegos que definas bloquearán el tráfico de los GFEs a las VMs de backend, pero no bloquearán el tráfico entrante a los GFEs. Para consultar las prácticas recomendadas, ve a la sección Reglas de cortafuegos.
Arquitectura de VPC compartida
Los balanceadores de carga de red de proxy externo regionales y los balanceadores de carga de red de proxy clásicos admiten implementaciones que usan redes de VPC compartidas. Las VPC compartidas te permiten mantener una separación clara de las responsabilidades entre los administradores de redes y los desarrolladores de servicios. Tus equipos de desarrollo pueden centrarse en crear servicios en proyectos de servicio, y los equipos de infraestructura de red pueden aprovisionar y administrar el balanceo de carga. Si no conoces la VPC compartida, consulta la documentación general sobre 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 carga. | La regla de reenvío externa debe definirse en el mismo proyecto que las instancias de backend (el proyecto de servicio). | El proxy TCP o SSL de destino debe definirse en el mismo proyecto que las instancias de backend. |
En el caso de los balanceadores de carga de red proxy clásicos, debe definirse un servicio de backend global en el mismo proyecto que las instancias de backend. Estas instancias deben estar en grupos de instancias asociados al servicio de backend como backends. Las comprobaciones de estado asociadas a los servicios de backend deben definirse en el mismo proyecto que el servicio de backend. En el caso de los balanceadores de carga de red de proxy externo regionales, las VMs de backend suelen estar ubicadas en un proyecto de servicio. En ese proyecto de servicio se deben definir un servicio backend regional y una comprobación del estado. |
Distribución del tráfico
Cuando añades un grupo de instancias de backend o un NEG a un servicio de backend, debes especificar un modo de balanceo de carga, que define un método para medir la carga del backend y la capacidad objetivo.
En el caso de los balanceadores de carga de red de proxy externo, el modo de balanceo puede ser CONNECTION
o UTILIZATION:
- Si el modo de balanceo de carga es
CONNECTION, la carga se distribuye en función del número total de conexiones que puede gestionar el backend. - Si el modo de balanceo de carga es
UTILIZATION, la carga se distribuye en función del uso de las instancias de un grupo de instancias. Este modo de balanceo solo se aplica a los backends de grupos de instancias de VM.
La distribución del tráfico entre los backends se determina mediante el modo de balanceo del balanceador de carga.
Balanceador de carga de red de proxy clásico
En el caso del balanceador de carga de red de proxy clásico, el modo de balanceo se usa para seleccionar el backend más favorable (grupo de instancias o NEG). A continuación, el tráfico se distribuye de forma rotatoria entre las instancias o los endpoints del backend.
Cómo se distribuyen las conexiones
Un balanceador de carga de red proxy clásico se puede configurar como un servicio de balanceo de carga global con el nivel Premium y como un servicio regional con el nivel Estándar.
El modo de balanceo y la elección del destino determinan la capacidad de la backend desde la perspectiva de cada GCE_VM_IP_PORT NEG zonal, grupo de instancias zonal o zona de un grupo de instancias regional. A continuación, el tráfico se distribuye en una zona mediante el
hash coherente.
Nivel Premium
Solo puedes tener un servicio de backend, y este puede tener backends en varias regiones. Para el balanceo de carga global, despliega tus back-ends en varias regiones y el balanceador de carga dirige automáticamente el tráfico a la región más cercana al usuario. Si una región está al máximo de su capacidad, el balanceador de carga dirige automáticamente las nuevas conexiones a otra región con capacidad disponible. Las conexiones de los usuarios actuales se mantienen en la región actual.
Google anuncia la dirección IP de tu balanceador de carga desde todos los puntos de presencia del mundo. Cada dirección IP de balanceador de carga es anycast global.
Si configura un servicio de backend con backends en varias regiones, los front-ends de Google (GFEs) intentarán dirigir las solicitudes a grupos de instancias de backend o NEGs en buen estado de la región más cercana al usuario.
Para el nivel Estándar
Google anuncia la dirección IP de tu balanceador de carga desde puntos de presencia asociados a la región de la regla de reenvío. El balanceador de carga usa una dirección IP externa regional.
Solo puede configurar backends en la misma región que la regla de reenvío. El balanceador de carga solo dirige las solicitudes a los backends en buen estado de esa región.
Balanceador de carga de red con proxy externo global
En el caso del balanceador de carga de red con proxy externo global, la distribución del tráfico se basa en el modo de balanceo de carga y en la política de localidad del balanceo de carga.
El modo de balanceo determina el peso y la fracción del tráfico que se enviará a cada grupo (grupo de instancias o NEG). La política de localidad del balanceo de carga (LocalityLbPolicy) determina cómo se balancea la carga de los backends 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. Una vez que se ha seleccionado un backend, el tráfico se distribuye entre las instancias o los endpoints de ese grupo de backend según la política de localidad del balanceo de carga.
Para obtener más información, consulta las siguientes secciones:
- Modo de balanceo.
- Política de localidad de balanceo de carga (documentación de la API de servicio de backend global)
Cómo se distribuyen las conexiones
Un balanceador de carga de red con proxy externo global se puede configurar como un servicio de balanceo de carga global con el nivel Premium.
El modo de balanceo y la elección del destino determinan la capacidad del backend desde la perspectiva de cada GCE_VM_IP_PORT NEG zonal o grupo de instancias zonal.
A continuación, el tráfico se distribuye en una zona mediante el hash coherente.
Solo puedes tener un servicio de backend, y este puede tener backends en varias regiones. Para el balanceo de carga global, despliega tus back-ends en varias regiones y el balanceador de carga dirige automáticamente el tráfico a la región más cercana al usuario. Si una región está al máximo de su capacidad, el balanceador de carga dirige automáticamente las nuevas conexiones a otra región con capacidad disponible. Las conexiones de los usuarios actuales se mantienen en la región actual.
Google anuncia la dirección IP de tu balanceador de carga desde todos los puntos de presencia del mundo. Cada dirección IP de balanceador de carga es anycast global.
Si configura un servicio de backend con backends en varias regiones, los front-ends de Google (GFEs) intentarán dirigir las solicitudes a grupos de instancias de backend o NEGs en buen estado de la región más cercana al usuario.
Balanceador de carga de red con proxy externo regional
En el caso de los balanceadores de carga de red de proxy externos regionales, la distribución del tráfico se basa en el modo de balanceo de carga y en la política de localidad del balanceo de carga.
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 carga (LocalityLbPolicy) determina cómo se balancea la carga de los backends 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. Una vez que se ha seleccionado un backend, el tráfico se distribuye entre las instancias o los endpoints de ese grupo de backend según la política de localidad del balanceo de carga.
Para obtener más información, consulta las siguientes secciones:
- Modos de balanceo
- Política de localidad de balanceo de carga (documentación de la API de servicio backend regional)
Afinidad de sesión
La afinidad de sesión te permite configurar el servicio de backend del balanceador de carga para que envíe todas las solicitudes del mismo cliente al mismo backend, siempre que el backend esté en buen estado y tenga capacidad.
Los balanceadores de carga de red de proxy externos ofrecen los siguientes tipos de afinidad de sesión:Ninguno
Si el ajuste de afinidad de sesión es
NONE, no significa que no haya afinidad de sesión. Esto significa que no se ha configurado explícitamente ninguna opción de afinidad de sesión.El hashing siempre se realiza para seleccionar un backend. Si la afinidad de sesión es
NONE, el balanceador de carga usa un hash de 5 tuplas para seleccionar un backend. El hash de 5 tuplas está formado por la dirección IP de origen, el puerto de origen, el protocolo, la dirección IP de destino y el puerto de destino.El valor predeterminado de la afinidad de sesión es
NONE.Afinidad de IP de cliente
La afinidad de sesión por IP de cliente (
CLIENT_IP) es un hash de dos tuplas creado a partir de las direcciones IP de origen y de destino del paquete. La afinidad de IP de cliente reenvía todas las solicitudes de la misma dirección IP de cliente al mismo backend, siempre que este tenga capacidad y se mantenga en buen estado.Cuando uses la afinidad de IP de cliente, ten en cuenta lo siguiente:
- La dirección IP de destino del paquete solo es la misma que la dirección IP de la regla de reenvío del balanceador de carga si el paquete se envía directamente al balanceador de carga.
- Es posible que la dirección IP de origen del paquete no coincida con una dirección IP asociada al cliente original si el paquete se procesa mediante un sistema NAT o proxy intermedio antes de enviarse a un balanceador de carga. Google Cloud En situaciones en las que muchos clientes comparten la misma dirección IP de origen efectiva, algunas VMs backend pueden recibir más conexiones o solicitudes que otras.
Tenga en cuenta lo siguiente al configurar la afinidad de sesión:
No confíes en la afinidad de sesión para fines de autenticación o seguridad. La afinidad de sesión puede dejar de funcionar cuando cambia el número de back-ends activos y correctos. Para obtener más información, consulta Pérdida de la afinidad de sesión.
Los valores predeterminados de las marcas
--session-affinityy--subsetting-policysonNONE, y solo se puede asignar un valor diferente a una de ellas a la vez.
Pérdida de la afinidad de sesión
Todas las opciones de afinidad de sesión requieren lo siguiente:
- La instancia o el endpoint de backend seleccionados deben seguir configurados como backend. La afinidad de sesión puede dejar de funcionar cuando se produce uno de los siguientes eventos:
- Se elimina la instancia seleccionada de su grupo de instancias.
- La función de autoescalado o de reparación automática de grupos de instancias gestionados elimina la instancia seleccionada de su grupo de instancias gestionado.
- Eliminas el endpoint seleccionado de su NEG.
- Elimina del servicio de backend el grupo de instancias o el NEG que contenga la instancia o el endpoint seleccionados.
- La instancia o el endpoint de backend seleccionados deben mantener su buen estado. La afinidad de sesión puede dejar de funcionar cuando la instancia o el endpoint seleccionados no superan las comprobaciones de estado.
- En el caso de los balanceadores de carga de red proxy externos globales y los balanceadores de carga de red proxy clásicos, la afinidad de sesión puede dejar de funcionar si se usa un Google Front End (GFE) de primera capa diferente para las solicitudes o conexiones posteriores al cambio en la ruta. Es posible que se seleccione otra GFE de primera capa si la ruta de acceso de un cliente de Internet a Google cambia entre solicitudes o conexiones.
El grupo de instancias o NEG que contiene la instancia o el endpoint seleccionados no debe estar lleno, tal como se define en su capacidad objetivo. En el caso de los grupos de instancias gestionados regionales, el componente de zona del grupo de instancias que contiene la instancia seleccionada no debe estar lleno. La afinidad de sesión puede dejar de funcionar cuando el grupo de instancias o el NEG están llenos y otros grupos de instancias o NEGs no. Como la capacidad puede cambiar de forma impredecible al usar el modo de balanceo
UTILIZATION, debes usar el modo de balanceoRATEoCONNECTIONpara minimizar las situaciones en las que la afinidad de sesión pueda fallar.El número total de instancias o endpoints de backend configurados debe permanecer constante. Cuando se produce al menos uno de los siguientes eventos, cambia el número de instancias o endpoints de backend configurados y se puede interrumpir la afinidad de sesión:
Añadir nuevas instancias o endpoints:
- Añade instancias a un grupo de instancias que ya tengas en el servicio de backend.
- El autoescalado de grupos de instancias gestionados añade instancias a un grupo de instancias gestionado en el servicio de backend.
- Añade puntos finales a un NEG que ya esté en el servicio backend.
- Añade grupos de instancias o NEGs no vacíos al servicio de backend.
Para quitar cualquier instancia o endpoint, no solo la instancia o el endpoint seleccionados:
- Elimina cualquier instancia de un backend de grupo de instancias.
- El autoescalado o la reparación automática de grupos de instancias gestionados elimina cualquier instancia de un backend de grupo de instancias gestionado.
- Puedes quitar cualquier endpoint de un backend de NEG.
- Elimina cualquier grupo de instancias de backend o NEG no vacío del servicio de backend.
El número total de instancias o endpoints de backend en buen estado debe mantenerse constante. Cuando se produce al menos uno de los siguientes eventos, cambia el número de instancias o endpoints de backend correctos y se puede interrumpir la afinidad de sesión:
- Cualquier instancia o endpoint supera su comprobación de estado y pasa de estar en mal estado a estar en buen estado.
- Si alguna instancia o endpoint no supera la comprobación del estado, pasa de estar en buen estado a no estarlo o a agotar el tiempo de espera.
Conmutación por error
La conmutación por error de los balanceadores de carga de red de proxy externo funciona de la siguiente manera:
- Si un backend deja de estar en buen estado, el tráfico se redirige automáticamente a los backends en buen estado de la misma región.
- Si todos los backends de una región no están en buen estado, el tráfico se distribuye a los backends en buen estado de otras regiones (solo en los modos global y clásico).
- Si todos los backends están en mal estado, el balanceador de carga rechaza el tráfico.
Balanceo de carga para aplicaciones de GKE
Si creas aplicaciones en Google Kubernetes Engine, puedes usar NEGs independientes para balancear la carga del tráfico directamente a los contenedores. Con los NEGs independientes, eres responsable de crear el objeto Service que crea el NEG y, a continuación, de asociar el NEG al servicio de backend para que el balanceador de carga pueda conectarse a los pods.
Para consultar la documentación relacionada, consulta Balanceo de carga nativo de contenedores mediante NEGs de zona independientes.
Limitaciones
No puedes crear un balanceador de carga de red proxy externo regional en el nivel Premium mediante laGoogle Cloud consola .Además, solo están disponibles las regiones que admiten el nivel Estándar para estos balanceadores de carga en laGoogle Cloud consola .En su lugar, usa la interfaz de línea de comandos de gcloud o la API.
Google Cloud no ofrece ninguna garantía sobre la duración de las conexiones TCP cuando se usan balanceadores de carga de red de proxy externos. Los clientes deben ser resistentes a las conexiones interrumpidas, tanto por problemas generales de Internet como por los reinicios programados periódicamente de los proxies que gestionan las conexiones.
Las siguientes limitaciones solo se aplican a los balanceadores de carga de red de proxy clásicos y a los balanceadores de carga de red de proxy externos globales que se implementan con un proxy de destino SSL:
Los balanceadores de carga de red con proxy clásicos y los balanceadores de carga de red con proxy externos globales no admiten la autenticación basada en certificados de cliente, también conocida como autenticación TLS mutua.
Los balanceadores de carga de red de proxy clásicos y los balanceadores de carga de red de proxy externos globales solo admiten caracteres en minúsculas en los dominios de un atributo de nombre común (
CN) o de un atributo de nombre alternativo del sujeto (SAN) del certificado. Los certificados con caracteres en mayúsculas en los dominios solo se devuelven cuando se definen como el certificado principal en el proxy de destino.
Siguientes pasos
- Configura un balanceador de carga de red de proxy clásico (proxy TCP).
- Configura un balanceador de carga de red de proxy clásico (proxy SSL).
- Configura un balanceador de carga de red con proxy externo global (proxy TCP).
- Configura un balanceador de carga de red con proxy externo global (proxy SSL).
- Configura un balanceador de carga de red de proxy externo regional (proxy TCP).
- Registro y monitorización de balanceadores de carga de red de proxy.