Descripción general del balanceador de cargas de red del proxy externo

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 usuarios de TCP o SSL entrante finaliza en el balanceador de cargas. Luego, una conexión nueva reenvía el tráfico al backend disponible 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 este ejemplo, el tráfico SSL de usuarios de Iowa y Boston finaliza en la capa del balanceo de cargas y se establece una conexión independiente para el backend seleccionado.

Cloud Load Balancing con finalización SSL.
Cloud Load Balancing con finalización SSL (haz clic para ampliar).

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. El balanceador de cargas de red del proxy externo global se encuentra en Vista previa.
  • 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.

Consola

  1. En la consola de Google Cloud, ve a la página Balanceo de cargas.

    Ir a Balanceo de cargas

  2. 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 del proxy clásico Red (proxy, clásico) Externa
    Balanceador de cargas de red del proxy externo global Red (proxy) Externa
    Balanceador de cargas de red del proxy externo regional Red (proxy) Externa Especifica una región

gcloud

  1. Usa el comando gcloud compute forwarding-rules describe:

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
    
  2. 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 del 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 y regional.

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 de proxy global externo y al clásico en el nivel Premium.



  Componentes del balanceador de cargas de red del proxy externo global
Componentes del balanceador de cargas de red del proxy externo global (haz clic para ampliar).

Regional

En este diagrama, se muestran los componentes de una implementación del balanceador de cargas de red del proxy externo regional.



  Componentes del balanceador de cargas de red del proxy externo regional
Componentes del balanceador de cargas de red del proxy externo regional (haz clic para ampliar)

Los siguientes son componentes de balanceadores de cargas de red del proxy externo.

Subred de solo proxy

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.

Cada regla de reenvío proporciona 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, deberás 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.

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 comparan los diferentes tipos de balanceadores de cargas.

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 del proxy clásico Nivel Premium

Regla de reenvío externa global

Dirección IP externa global

Esquema de balanceo de cargas: EXTERNAL

Solicitudes enrutadas a los GFE más cercanos al cliente en Internet.
Nivel Estándar

Regla de reenvío externa regional

Dirección IP externa regional

Esquema de balanceo de cargas: EXTERNAL

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

Dirección IP externa global

Esquema de balanceo de cargas: EXTERNAL_MANAGED

Solicitudes enrutadas a los GFE más cercanos al cliente en Internet.
Balanceador de cargas de red del proxy externo regional Nivel Premium y Estándar

Regla de reenvío externa regional

Dirección IP externa regional

Esquema de balanceo de cargas: EXTERNAL_MANAGED

Solicitudes enrutadas a los proxies de Envoy en la misma región que el balanceador de cargas.

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.

Modo de balanceador de cargas Nivel de servicio de red Proxy de destino
Balanceador de cargas de red del 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 de proxy externo global y un balanceador de cargas de red de 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 llevar 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 atributos de backend compatibles.

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 del proxy clásico Usa NEG zonales independientes
Balanceador de cargas de red del proxy externo global Extremos de tipo GCE_VM_IP_PORT
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

Backends y redes de VPC

Todos los backends deben estar ubicados en el mismo proyecto, pero se pueden ubicar en redes de VPC diferentes. No es necesario que las diferentes redes de VPC estén conectadas mediante el intercambio de tráfico entre redes de VPC, ya que los sistemas proxy de GFE se comunican directamente con los backends en sus respectivas redes de VPC.

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 de proxy clásicos, 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 allow que 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 allow que 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 allow de 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 clásico
  • 35.191.0.0/16
  • 130.211.0.0/22
Estos rangos se aplican a los sondeos de verificación de estado y a las solicitudes del GFE.
Balanceador de cargas de red del proxy externo global
  • 35.191.0.0/16
  • 130.211.0.0/22
Estos rangos se aplican a los sondeos de verificación de estado y a las solicitudes del GFE.
Balanceador de cargas de red del proxy externo regional 1, 2
  • 35.191.0.0/16
  • 130.211.0.0/22
Estos rangos se aplican a los sondeos de verificación de estado.

1 No se requiere incluir en la lista de anunciantes permitidos 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 anunciantes permitidos los rangos de sondeo de verificación de estado de Google para los NEG zonales.

2 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 clásico y los balanceadores de cargas de red de proxy externos globales:
  • 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.

Para los balanceadores de cargas de red del proxy externo regional:
  • 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 puerto diferente no se envían a tus backends. Incluso sin ninguna configuración especial, la infraestructura de Google y los GFE proporcionan una defensa en profundidad para los ataques DSD y los desbordes de SYN.

  • Cualquier paquete de 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 de proxy clásico y los balanceadores de cargas de red de proxy externos regionales 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 TCP o 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 el backend puede manejar.
  • 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 manera en que se distribuye el tráfico entre backends depende del modo 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 mediante el hashing 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 de localidad del balanceo de cargas.

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:

Cómo se distribuyen las conexiones

Un balanceador de cargas de red de 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 mediante el hashing 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 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:

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 (globales y regionales) 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

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. 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 de proxy clásico y los balanceadores de cargas de red de proxy externos globales no admiten la autenticación basada en certificados de cliente, también conocida como autenticación TLS mutua.

    • Los balanceadores de cargas de red de proxy clásico y los balanceadores de cargas de red de proxy externos globales admiten solo caracteres en minúscula en los dominios con un atributo de nombre común (CN) o uno de nombre alternativo de entidad (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?