Información general sobre los servicios de backend

Un servicio de backend define cómo distribuye el tráfico Cloud Load Balancing. La configuración del servicio de backend contiene un conjunto de valores, como el protocolo utilizado para conectarse a los backends, varios ajustes de distribución y de sesión, comprobaciones de estado y tiempos de espera. Estos ajustes proporcionan un control pormenorizado sobre el comportamiento del balanceador de carga. Para empezar, la mayoría de los ajustes tienen valores predeterminados que permiten una configuración rápida. Un servicio de backend puede ser global o regional.

Los balanceadores de carga, los proxies Envoy y los clientes gRPC sin proxy usan la información de configuración del recurso de servicio de backend para hacer lo siguiente:

  • Dirigir el tráfico a los backends correctos, que son grupos de instancias o grupos de puntos finales de red (NEGs).
  • Distribuir el tráfico según un modo de balanceo, que es un ajuste de cada backend.
  • Determina qué comprobación del estado está monitorizando el estado de los backends.
  • Especifica la afinidad de sesión.
  • Determina si hay otros servicios habilitados, incluidos los siguientes, que solo están disponibles para determinados balanceadores de carga:
    • Cloud CDN
    • Políticas de seguridad de Google Cloud Armor
    • Identity-Aware Proxy
  • Designa servicios backend regionales como un servicio en las aplicaciones de App Hub.

Estos valores se definen al crear un servicio de backend o al añadir un backend al servicio de backend.

Nota: Si usas el balanceador de carga de aplicaciones externo global o el balanceador de carga de aplicaciones clásico y tus backends sirven contenido estático, te recomendamos que uses contenedores de backend en lugar de servicios de backend. Consulta los cubos de backend de los balanceadores de carga de aplicación externos globales o los cubos de backend de los balanceadores de carga de aplicación clásicos.

En la siguiente tabla se resume qué balanceadores de carga usan servicios de backend. El producto que utilices también determina el número máximo de servicios de backend, el ámbito de un servicio de backend, el tipo de backends admitidos y el esquema de balanceo de carga del servicio de backend. El esquema de balanceo de carga es un identificador que Google usa para clasificar las reglas de reenvío y los servicios de backend. Cada producto de balanceo de carga usa un esquema de balanceo de carga para sus reglas de reenvío y servicios de backend. Algunos esquemas se comparten entre productos.

Tabla: servicios de backend y tipos de backend admitidos
Producto Número máximo de servicios de backend Ámbito del servicio de backend Tipos de backend admitidos Esquema de balanceo de carga
Balanceador de carga de aplicación externo global Varios Global Cada servicio backend admite una de las siguientes combinaciones de backend:
  • Todos los backends de grupos de instancias: uno o varios grupos de instancias gestionados, sin gestionar o una combinación de ambos *
  • Todas las NEGs por zonas: una o varias NEGs por zonas de tipo GCE_VM_IP_PORT*
  • Todos los NEGs de conectividad híbrida: uno o varios NEGs de tipo NON_GCP_PRIVATE_IP_PORT
  • Una combinación de NEGs zonales e híbridos: NEGs de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT †
  • Todos los NEGs sin servidor: uno o varios recursos de funciones de App Engine, Cloud Run o Cloud Functions
  • Un NEG de Internet global para un backend externo
  • NEGs de Private Service Connect:
    • APIs de Google: un único NEG de Private Service Connect
    • Servicios gestionados: uno o varios NEGs de Private Service Connect
EXTERNAL_MANAGED
Balanceador de carga de aplicación clásico Varios Global‡ Cada servicio backend admite una de las siguientes combinaciones de backend:
  • Todos los backends de grupos de instancias: uno o varios grupos de instancias gestionados, sin gestionar o una combinación de ambos
  • Todos los NEGs por zonas: uno o varios NEGs por zonas de tipo GCE_VM_IP_PORT
  • Todos los NEGs de conectividad híbrida: uno o varios NEGs de tipo NON_GCP_PRIVATE_IP_PORT
  • Una combinación de NEGs zonales e híbridos: NEGs de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT †
  • Todos los NEGs sin servidor: uno o varios recursos de App Engine, Cloud Run o funciones de Cloud Run, o
  • Un NEG de Internet global para un backend externo
 EXTERNAL#
Balanceador de carga de aplicación externo regional Varios Regional Cada servicio backend admite una de las siguientes combinaciones de backend:
  • Todos los backends de grupos de instancias: uno o varios grupos de instancias gestionados, sin gestionar o una combinación de ambos *
  • Todas las NEGs por zonas: una o varias NEGs por zonas de tipo GCE_VM_IP_PORT. *
  • Todos los NEGs de conectividad híbrida: uno o varios NEGs de tipo NON_GCP_PRIVATE_IP_PORT
  • Una combinación de NEGs zonales e híbridos: NEGs de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT †
  • Un único NEG sin servidor (solo para Cloud Run o Cloud Run Functions de segunda generación)
  • Un único NEG de Private Service Connect
  • Todos los NEGs de Internet regionales de un backend externo
 EXTERNAL_MANAGED
Balanceador de carga de aplicación interno entre regiones Varios Global Cada servicio backend admite una de las siguientes combinaciones de backend:
  • Todos los backends de grupos de instancias: uno o varios grupos de instancias gestionados, sin gestionar o una combinación de ambos *
  • Todas las NEGs por zonas: una o varias NEGs por zonas de tipo GCE_VM_IP_PORT. *
  • Todos los NEGs de conectividad híbrida: uno o varios NEGs de tipo NON_GCP_PRIVATE_IP_PORT
  • Una combinación de NEGs zonales e híbridos: NEGs de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT †
  • Un único NEG sin servidor (solo para Cloud Run o Cloud Run Functions de segunda generación)
  • NEGs de Private Service Connect:
    • APIs de Google: un único NEG de Private Service Connect
    • Servicios gestionados: uno o varios NEGs de Private Service Connect
INTERNAL_MANAGED
Balanceador de carga de aplicación interno regional Varios Regional Cada servicio backend admite una de las siguientes combinaciones de backend:
  • Todos los backends de grupos de instancias: uno o varios grupos de instancias gestionados, sin gestionar o una combinación de ambos *
  • Todas las NEGs por zonas: una o varias NEGs por zonas de tipo GCE_VM_IP_PORT. *
  • Todos los NEGs de conectividad híbrida: uno o varios NEGs de tipo NON_GCP_PRIVATE_IP_PORT
  • Una combinación de NEGs zonales e híbridos: NEGs de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT †
  • Un único NEG sin servidor (solo para Cloud Run o Cloud Run Functions de segunda generación)
  • Un único NEG de Private Service Connect
  • Todos los NEGs de Internet regionales de un backend externo
 INTERNAL_MANAGED
Balanceador de carga de red con proxy externo global 1 Global‡ El servicio de backend admite una de las siguientes combinaciones de backend:
  • Todos los backends de grupos de instancias: uno o varios backends de grupos de instancias gestionados, sin gestionar o una combinación de ambos *
  • Todas las NEGs por zonas: una o varias NEGs por zonas de tipo GCE_VM_IP_PORT*
  • Todos los NEGs de conectividad híbrida: uno o varios NEGs de tipo NON_GCP_PRIVATE_IP_PORT
  • Una combinación de NEGs zonales e híbridos: NEGs de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT †
  • NEGs de Private Service Connect:
    • APIs de Google: un único NEG de Private Service Connect
    • Servicios gestionados: uno o varios NEGs de Private Service Connect
EXTERNAL_MANAGED
Balanceador de carga de red de proxy clásico 1 Global‡ El servicio de backend admite una de las siguientes combinaciones de backend:
  • Todos los backends de grupos de instancias: uno o varios grupos de instancias gestionados, sin gestionar o una combinación de ambos
  • Todos los NEGs por zonas: uno o varios NEGs por zonas de tipo GCE_VM_IP_PORT
  • Todos los NEGs de conectividad híbrida: uno o varios NEGs de tipo NON_GCP_PRIVATE_IP_PORT
  • Una combinación de NEGs zonales e híbridos: NEGs de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT †
 EXTERNO
Balanceador de carga de red con proxy externo regional 1 Regional El servicio de backend admite una de las siguientes combinaciones de backend:
  • Todos los backends de grupos de instancias: uno o varios grupos de instancias gestionados, sin gestionar o una combinación de ambos *
  • Todas las NEGs por zonas: una o varias NEGs por zonas de tipo GCE_VM_IP_PORT. *
  • Todos los NEGs de conectividad híbrida: uno o varios NEGs de tipo NON_GCP_PRIVATE_IP_PORT
  • Una combinación de NEGs de zona e híbridos: NEGs de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT
  • Todos los NEGs de Internet regionales de un backend externo
  • Un único NEG de Private Service Connect
 EXTERNAL_MANAGED
Balanceador de carga de red con proxy interno regional 1 Regional El servicio de backend admite una de las siguientes combinaciones de backend:
  • Todos los backends de grupos de instancias: uno o varios grupos de instancias gestionados, sin gestionar o una combinación de ambos *
  • Todas las NEGs por zonas: una o varias NEGs por zonas de tipo GCE_VM_IP_PORT. *
  • Todos los NEGs de conectividad híbrida: uno o varios NEGs de tipo NON_GCP_PRIVATE_IP_PORT
  • Una combinación de NEGs de zona e híbridos: NEGs de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT
  • Todos los NEGs de Internet regionales de un backend externo
  • Un único NEG de Private Service Connect
 INTERNAL_MANAGED
Balanceador de carga de red con proxy interno interregional Varios Global El servicio de backend admite una de las siguientes combinaciones de backend:
  • Todos los backends de grupos de instancias: uno o varios grupos de instancias gestionados, sin gestionar o una combinación de ambos *
  • Todas las NEGs por zonas: una o varias NEGs por zonas de tipo GCE_VM_IP_PORT. *
  • Todos los NEGs de conectividad híbrida: uno o varios NEGs de tipo NON_GCP_PRIVATE_IP_PORT
  • Una combinación de NEGs de zona e híbridos: NEGs de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT
  • NEGs de Private Service Connect:
    • APIs de Google: un único NEG de Private Service Connect
    • Servicios gestionados: uno o varios NEGs de Private Service Connect
INTERNAL_MANAGED
Balanceador de carga de red de paso a través externo 1 Regional El servicio de backend admite una de las siguientes combinaciones de backend:
  • Todos los backends de grupos de instancias: uno o varios grupos de instancias gestionados, sin gestionar o una combinación de ambos
  • Todos los NEGs por zonas: uno o varios NEGs por zonas de tipo GCE_VM_IP
 EXTERNO
Balanceador de carga de red de paso a través interno 1 Regional, pero se puede configurar para que sea accesible a nivel mundial El servicio de backend admite una de las siguientes combinaciones de backend:
  • Todos los backends de grupos de instancias: uno o varios grupos de instancias gestionados, sin gestionar o una combinación de ambos
  • Todos los NEGs por zonas: uno o varios NEGs por zonas de tipo GCE_VM_IP
  • NEG de asignación de un puerto
 INTERNAL
Cloud Service Mesh Varios Global Cada servicio backend admite una de las siguientes combinaciones de backend:
  • Todos los backends de grupos de instancias: uno o varios grupos de instancias gestionados, sin gestionar o una combinación de ambos
  • Todos los NEGs de zona: uno o varios NEGs de zona de tipo GCE_VM_IP_PORT o NON_GCP_PRIVATE_IP_PORT
  • Un NEG de Internet de tipo INTERNET_FQDN_PORT
  • Una o varias vinculaciones de servicio
 INTERNAL_SELF_MANAGED
* Admite grupos de instancias IPv4 e IPv6 (de pila dual) y backends de NEG de zona. Los NEGs por zonas admiten el doble pila solo en los endpoints de tipo GCE_VM_IP_PORT.

† En las implementaciones de GKE, los back-ends de NEG mixtos solo se admiten con NEGs independientes.
‡ Los servicios de backend que usan los balanceadores de carga de aplicaciones clásicos y los balanceadores de carga de red con proxy clásicos siempre tienen un ámbito global, ya sea en el nivel de red estándar o premium. Sin embargo, en el nivel Estándar se aplican las siguientes restricciones:
# Es posible adjuntar EXTERNAL_MANAGED servicios de backend a EXTERNAL reglas de reenvío. Sin embargo, los servicios de backend de EXTERNAL no se pueden adjuntar a reglas de reenvío de EXTERNAL_MANAGED. Para aprovechar las nuevas funciones disponibles solo con el balanceador de carga de aplicación externo global, te recomendamos que migres tus recursos de EXTERNAL a EXTERNAL_MANAGED mediante el proceso de migración descrito en el artículo Migrar recursos del balanceador de carga de aplicación clásico al balanceador de carga de aplicación externo global.

Nombres de balanceadores de carga

En el caso de los balanceadores de carga de red de proxy y los balanceadores de carga de red con paso a través, el nombre del balanceador de carga siempre es el mismo que el del servicio de backend. El comportamiento de cada interfaz Google Cloud es el siguiente:

  • Google Cloud console. Si crea un balanceador de carga de red de proxy o un balanceador de carga de red de transferencia mediante la consola, el servicio de backend recibe automáticamente el mismo nombre que ha introducido para el balanceador de carga. Google Cloud
  • Google Cloud CLI o API. Si creas un balanceador de carga de red proxy o un balanceador de carga de red de transferencia mediante la CLI de gcloud o la API, debes introducir el nombre que quieras al crear el servicio de backend. El nombre de este servicio de backend se refleja en la Google Cloud consola como el nombre del balanceador de carga.

Para obtener información sobre cómo se asignan los nombres a los balanceadores de carga de aplicaciones, consulta el artículo Descripción general de los mapas de URLs: nombres de los balanceadores de carga.

Backends

Un backend es uno o varios endpoints que reciben tráfico de un Google Cloudbalanceador de carga, un proxy de Envoy configurado con Cloud Service Mesh o un cliente gRPC sin proxy. Hay varios tipos de back-ends:

No puedes eliminar un grupo de instancias de backend ni un NEG asociado a un servicio de backend. Antes de eliminar un grupo de instancias o un NEG, primero debes quitarlo como backend de todos los servicios de backend que hagan referencia a él.

Grupos de instancias

En esta sección se explica cómo funcionan los grupos de instancias con el servicio de backend.

Máquinas virtuales de backend y direcciones IP externas

Las VMs de backend de los servicios de backend no necesitan direcciones IP externas:

  • En el caso de los balanceadores de carga de aplicación externos globales y los balanceadores de carga de red con proxy externo: los clientes se comunican con un frontend de Google (GFE) que aloja la dirección IP externa de tu balanceador de carga. Los GFE se comunican con las VMs o los endpoints de backend enviando paquetes a una dirección interna creada combinando un identificador de la red de VPC del backend con la dirección IPv4 interna del backend. La comunicación entre los GFE y las VMs o los endpoints de backend se facilita a través de rutas especiales.
    • En el caso de los backends de grupos de instancias, la dirección IPv4 interna siempre es la dirección IPv4 interna principal que corresponde a la interfaz nic0 de la máquina virtual.
    • En el caso de los endpoints GCE_VM_IP_PORT de un NEG zonal, puede especificar la dirección IP del endpoint como la dirección IPv4 principal asociada a cualquier interfaz de red de una VM o cualquier dirección IPv4 de un intervalo de direcciones IP de alias asociado a cualquier interfaz de red de una VM.

  • En el caso de los balanceadores de carga de aplicación externos regionales: los clientes se comunican con un proxy de Envoy que aloja la dirección IP externa de tu balanceador de carga. Los proxies de Envoy se comunican con las VMs o los endpoints de backend enviando paquetes a una dirección interna creada al combinar un identificador de la red de VPC del backend con la dirección IPv4 interna del backend.

    • En el caso de los backends de grupos de instancias, la dirección IPv4 interna siempre es la dirección IPv4 interna principal que corresponde a la interfaz nic0 de la VM, y nic0 debe estar en la misma red que el balanceador de carga.
    • En el caso de los endpoints GCE_VM_IP_PORT de un NEG zonal, puede especificar la dirección IP del endpoint como la dirección IPv4 principal asociada a cualquier interfaz de red de una VM o cualquier dirección IPv4 de un intervalo de direcciones IP de alias asociado a cualquier interfaz de red de una VM, siempre que la interfaz de red esté en la misma red que el balanceador de carga.

  • En el caso de los balanceadores de carga de red de paso a través externos: los clientes se comunican directamente con los backends a través de la infraestructura de balanceo de carga de paso a través Maglev de Google. Los paquetes se enrutan y se entregan a los backends con las direcciones IP de origen y destino originales. Los back-ends responden a los clientes mediante la devolución directa del servidor. Los métodos que se usan para seleccionar un backend y monitorizar las conexiones son configurables.

    • En el caso de los backends de grupos de instancias, los paquetes siempre se entregan a la interfaz nic0 de la VM.
    • En el caso de los endpoints de GCE_VM_IP de un NEG zonal, los paquetes se envían a la interfaz de red de la VM que se encuentra en la subred asociada al NEG.

Puertos con nombre

El atributo puerto con nombre del servicio de backend solo se aplica a los balanceadores de carga basados en proxy (balanceadores de carga de aplicaciones y balanceadores de carga de red de proxy) que usan backends de grupos de instancias. El puerto con nombre define el puerto de destino que se usa para la conexión TCP entre el proxy (GFE o Envoy) y la instancia de backend.

Los puertos con nombre se configuran de la siguiente manera:

  • En cada backend de grupo de instancias, debe configurar uno o varios puertos con nombre mediante pares clave-valor. La clave representa un nombre de puerto significativo que elijas, y el valor representa el número de puerto que asignes al nombre. La asignación de nombres a números se realiza de forma individual para cada backend del grupo de instancias.

  • En el servicio de backend, especifica un único puerto con nombre usando solo el nombre del puerto (--port-name).

El servicio de backend traduce el nombre del puerto a un número de puerto por cada backend del grupo de instancias. Cuando el puerto con nombre de un grupo de instancias coincide con el --port-name de un servicio de backend, el servicio de backend usa este número de puerto para comunicarse con las VMs del grupo de instancias.

Por ejemplo, puedes definir el puerto con nombre en un grupo de instancias con el nombre my-service-name y el puerto 8888:

gcloud compute instance-groups unmanaged set-named-ports my-unmanaged-ig \
    --named-ports=my-service-name:8888

A continuación, haga referencia al puerto con nombre en la configuración del servicio de backend con el valor --port-name del servicio de backend definido como my-service-name:

gcloud compute backend-services update my-backend-service \
    --port-name=my-service-name

Un servicio de backend puede usar un número de puerto diferente al comunicarse con VMs de distintos grupos de instancias si cada grupo de instancias especifica un número de puerto diferente para el mismo nombre de puerto.

El número de puerto resuelto que usa el servicio de backend del balanceador de carga proxy no tiene por qué coincidir con el número de puerto que usan las reglas de reenvío del balanceador de carga. Un balanceador de carga de proxy escucha las conexiones TCP enviadas a la dirección IP y al puerto de destino de sus reglas de reenvío. Como el proxy abre una segunda conexión TCP a sus back-ends, el puerto de destino de la segunda conexión TCP puede ser diferente.

Los puertos con nombre solo se pueden aplicar a back-ends de grupos de instancias. Los NEG zonales con GCE_VM_IP_PORTpuntos finalesNON_GCP_PRIVATE_IP_PORT, los NEG híbridos con NON_GCP_PRIVATE_IP_PORTpuntos finales y los NEG de Internet definen los puertos mediante un mecanismo diferente, es decir, en los propios puntos finales.Los NEG sin servidor hacen referencia a servicios de Google y los NEG de PSC hacen referencia a adjuntos de servicio mediante abstracciones que no implican especificar un puerto de destino.

Los balanceadores de carga de red de paso a través internos y externos no usan puertos con nombre. Esto se debe a que son balanceadores de carga de transferencia que enrutan las conexiones directamente a las back-ends en lugar de crear nuevas conexiones. Los paquetes se entregan a los backends conservando la dirección IP y el puerto de destino de la regla de reenvío del balanceador de carga.

Para saber cómo crear puertos con nombre, sigue estas instrucciones:

Restricciones y directrices para grupos de instancias

Ten en cuenta las siguientes restricciones y directrices al crear grupos de instancias para tus balanceadores de carga:

  • No incluyas una VM en más de un grupo de instancias con balanceo de carga. Si una VM es miembro de dos o más grupos de instancias no gestionados, o de un grupo de instancias gestionado y uno o varios grupos de instancias no gestionados, Google Cloud solo podrás usar uno de esos grupos de instancias a la vez como backend de un servicio de backend concreto.

    Si necesitas que una VM participe en varios balanceadores de carga, debes usar el mismo grupo de instancias como backend en cada uno de los servicios de backend.

  • En el caso de los balanceadores de carga proxy, si quieres balancear el tráfico a diferentes puertos, especifica los puertos con nombre necesarios en un grupo de instancias y haz que cada servicio de backend se suscriba a un puerto con nombre único.

  • Puede usar el mismo grupo de instancias como backend de más de un servicio de backend. En esta situación, los backends deben usar modos de balanceo compatibles. Compatible significa que los modos de balanceo deben ser iguales o una combinación de modos de balanceo compatibles (por ejemplo, CONNECTION y RATE).

    Las combinaciones de modos de equilibrio incompatibles son las siguientes:

    • CONNECTION con UTILIZATION
    • RATE con UTILIZATION
    • CUSTOM_METRICS con UTILIZATION
    • CUSTOM_METRICS con RATE
    • CUSTOM_METRICS con CONNECTION

    Veamos un ejemplo:

    • Tienes dos servicios de backend: external-https-backend-service para un balanceador de carga de aplicación externo y internal-tcp-backend-service para un balanceador de carga de red con paso a través interno.
    • Estás usando un grupo de instancias llamado instance-group-a en internal-tcp-backend-service.
    • En internal-tcp-backend-service, debes aplicar el modo de CONNECTION balanceo, ya que los balanceadores de carga de red de paso a través internos solo admiten el modo de CONNECTION balanceo.
    • También puedes usar instance-group-a en external-https-backend-service si aplicas el modo de balanceo RATE en external-https-backend-service.
    • Tampoco puedes usar en instance-group-a external-https-backend-service con el modo de balanceo UTILIZATION.

  • Para cambiar el modo de balanceo de un grupo de instancias que actúa como backend de varios servicios de backend, sigue estos pasos:

    • Quita el grupo de instancias de todos los servicios de backend, excepto de uno.
    • Cambia el modo de balanceo del backend en el servicio de backend restante.
    • Vuelve a añadir el grupo de instancias como backend a los servicios de backend restantes, si admiten el nuevo modo de balanceo.

  • Si tu grupo de instancias está asociado a varios servicios de backend, cada servicio de backend puede hacer referencia al mismo puerto con nombre o a otro puerto con nombre del grupo de instancias.

  • Te recomendamos que no añadas un grupo de instancias gestionado con autoescalado a más de un servicio de backend. Si lo haces, puede que se produzca un escalado impredecible e innecesario de las instancias del grupo, sobre todo si usas la métrica de autoescalado Uso del balanceo de carga HTTP.

    • Aunque no es recomendable, este escenario puede funcionar si la métrica de autoescalado es Uso de CPU o una métrica de Cloud Monitoring que no esté relacionada con la capacidad de servicio del balanceador de carga. Si usas una de estas métricas de autoescalado, es posible que evites que el escalado sea errático.

Grupos de puntos finales de red por zonas

Los puntos finales de red representan los servicios por su dirección IP o por una combinación de dirección IP y puerto, en lugar de hacer referencia a una VM de un grupo de instancias. Un grupo de puntos finales de red (NEG) es una agrupación lógica de puntos finales de red.

Los grupos de puntos finales de red (NEGs) zonales son recursos zonales que representan colecciones de direcciones IP o de combinaciones de direcciones IP y puertos para recursos de Google Cloud en una sola subred.

Un servicio de backend que usa NEGs zonales como backends distribuye el tráfico entre las aplicaciones o los contenedores que se ejecutan en máquinas virtuales.

Hay dos tipos de endpoints de red disponibles para los NEGs zonales:

  • Endpoints GCE_VM_IP (solo se admiten con balanceadores de carga de red de paso a través internos y balanceadores de carga de red de paso a través externos basados en servicios de backend).
  • GCE_VM_IP_PORT endpoints.

Para ver qué productos admiten back-ends de NEG zonales, consulta la tabla de servicios de back-end y tipos de back-end admitidos.

Para obtener más información, consulta la descripción general de los NEGs zonales.

Grupos de puntos finales de red de Internet

Los NEGs de Internet son recursos que definen backends externos. Un backend externo es un backend alojado en una infraestructura local o en una infraestructura proporcionada por terceros.

Un NEG de Internet es una combinación de un nombre de host o una dirección IP, más un puerto opcional. Hay dos tipos de puntos finales de red disponibles para los NEGs de Internet: INTERNET_FQDN_PORT y INTERNET_IP_PORT.

Las NEG de Internet están disponibles en dos ámbitos: global y regional. Para ver qué productos admiten backends de NEGs de Internet en cada ámbito, consulta la tabla Servicios de backend y tipos de backend admitidos.

Para obtener más información, consulta el resumen de los grupos de puntos de conexión de red de Internet.

Grupos de puntos finales de red sin servidor

Un grupo de endpoints de red (NEG) especifica un grupo de endpoints de backend para un balanceador de carga. Un NEG sin servidor es un backend que apunta a un recurso de Cloud Run, App Engine, Cloud Run functions o API Gateway.

Un NEG sin servidor puede representar uno de los siguientes elementos:

  • Un recurso de Cloud Run o un grupo de recursos.
  • Una función o un grupo de funciones de Cloud Run (antes, Cloud Run Functions de 2.ª gen.).
  • Una función de Cloud Run (1.ª gen.) o un grupo de funciones
  • Una aplicación del entorno estándar o del entorno flexible de App Engine, un servicio específico de una aplicación, una versión específica de una aplicación o un grupo de servicios.
  • Una API Gateway que proporciona acceso a tus servicios a través de una API REST coherente en todos los servicios, independientemente de la implementación del servicio. Esta función está en versión preliminar.

Para configurar un NEG sin servidor para aplicaciones sin servidor que compartan un patrón de URL, usa una máscara de URL. Una máscara de URL es una plantilla de tu esquema de URL (por ejemplo, example.com/<service>). El NEG sin servidor usará esta plantilla para extraer el nombre <service> de la URL de la solicitud entrante y enrutar la solicitud al servicio de Cloud Run, Cloud Run Functions o App Engine que coincida y tenga el mismo nombre.

Para ver qué balanceadores de carga admiten backends de NEG sin servidor, consulta la tabla Servicios de backend y tipos de backend admitidos.

Para obtener más información sobre los NEGs sin servidor, consulta la descripción general de los grupos de puntos finales de red sin servidor.

Enlaces a servicios

Un enlace de servicio es un backend que establece una conexión entre un servicio de backend de Cloud Service Mesh y un servicio registrado en el Directorio de servicios. Un servicio de backend puede hacer referencia a varios enlaces de servicio. Un servicio de backend con un enlace de servicio no puede hacer referencia a ningún otro tipo de backend.

Backends mixtos

Cuando añades diferentes tipos de backends a un mismo servicio de backend, se aplican las siguientes consideraciones de uso:

  • Un servicio de backend no puede usar simultáneamente grupos de instancias y NEGs zonales.
  • Puedes usar una combinación de diferentes tipos de grupos de instancias en el mismo servicio de backend. Por ejemplo, un único servicio de backend puede hacer referencia a una combinación de grupos de instancias gestionados y sin gestionar. Para obtener información completa sobre qué back-ends son compatibles con qué servicios de back-end, consulta la tabla de la sección anterior.
  • Con determinados balanceadores de carga proxy, puedes usar una combinación de NEGs zonales (con endpoints GCE_VM_IP_PORT) y NEGs de conectividad híbrida (con endpoints NON_GCP_PRIVATE_IP_PORT) para configurar el balanceo de carga híbrido. Para ver qué balanceadores de carga tienen esta función, consulta la tabla de servicios de backend y tipos de backend admitidos.

Protocolo a los backends

Cuando crees un servicio de backend, debes especificar el protocolo que se usará para comunicarse con los backends. Solo puedes especificar un protocolo por servicio de backend. No puedes especificar un protocolo secundario para usarlo como alternativa.

Los protocolos válidos dependen del tipo de balanceador de carga o de si usas Cloud Service Mesh.

Tabla: protocolo para las back-ends
Producto Opciones de protocolo de servicios de backend
Balanceador de carga de aplicación HTTP, HTTPS y HTTP/2
Balanceador de carga de red de proxy

TCP o SSL

Los balanceadores de carga de red de proxy regionales solo admiten TCP.
Balanceador de carga de red de paso a través TCP, UDP o UNSPECIFIED
Cloud Service Mesh HTTP, HTTPS, HTTP/2, gRPC y TCP

Si cambia el protocolo de un servicio de backend, los backends no se podrán acceder a través de los balanceadores de carga durante unos minutos.

Política de selección de direcciones IP

Este campo se aplica a los balanceadores de carga proxy. Debe usar la política de selección de direcciones IP para especificar el tipo de tráfico que se envía desde el servicio de backend a sus backends.

Cuando selecciones la política de selección de direcciones IP, asegúrate de que tus back-ends admitan el tipo de tráfico seleccionado. Para obtener más información, consulta la tabla de servicios backend y tipos de backend admitidos.

La política de selección de direcciones IP se usa cuando quieres convertir el servicio de backend de tu balanceador de carga para que admita otro tipo de tráfico. Para obtener más información, consulta Convertir de pila única a pila dual.

Puede especificar los siguientes valores para la política de selección de direcciones IP:

Política de selección de direcciones IP Descripción
Solo IPv4 Solo envía tráfico IPv4 a los backends del servicio de backend, independientemente del tráfico del cliente al GFE. Solo se utilizan comprobaciones del estado IPv4 para comprobar el estado de los backends.
Preferir IPv6

Prioriza la conexión IPv6 del backend sobre la conexión IPv4 (siempre que haya un backend correcto con direcciones IPv6).

Las comprobaciones del estado monitorizan periódicamente las conexiones IPv6 e IPv4 de los backends. El GFE primero intenta establecer la conexión IPv6. Si la conexión IPv6 se interrumpe o es lenta, el GFE usa Happy Eyeballs para volver a IPv4 y conectarse a ella.

Aunque una de las conexiones IPv6 o IPv4 no esté en buen estado, el backend se sigue considerando en buen estado y el GFE puede probar ambas conexiones. Finalmente, Happy Eyeballs selecciona cuál usar.
Solo IPv6

Solo envía tráfico IPv6 a los backends del servicio de backend, independientemente del tráfico del cliente al proxy. Solo se usan comprobaciones del estado de IPv6 para comprobar el estado de los backends.

No se realiza ninguna validación para comprobar si el tipo de tráfico de backend coincide con la política de selección de direcciones IP. Por ejemplo, si tienes back-ends solo IPv4 y seleccionas Only IPv6 como política de selección de direcciones IP, la configuración dará como resultado back-ends no operativos porque el tráfico no puede llegar a esos back-ends y se devuelve el código de respuesta HTTP 503 a los clientes.

Encriptado entre el balanceador de carga y los backends

Para obtener información sobre el cifrado entre el balanceador de carga y los backends, consulta Cifrado a los backends.

Distribución del tráfico

Los valores de los siguientes campos del recurso de servicios backend determinan algunos aspectos del comportamiento del backend:

  • Un modo de balanceo define cómo mide el balanceador de carga la disponibilidad del backend para las nuevas solicitudes o conexiones.
  • Una capacidad objetivo define un número máximo objetivo de conexiones, una tasa máxima objetivo o un uso máximo objetivo de la CPU.
  • Un escalador de capacidad ajusta la capacidad total disponible sin modificar la capacidad objetivo.

Modo de balanceo

El modo de balanceo determina si los backends de un balanceador de carga o de Cloud Service Mesh pueden gestionar tráfico adicional o están totalmente cargados.

Google Cloud tiene cuatro modos de balanceo:

  • CONNECTION: determina cómo se distribuye la carga en función del número total de conexiones que puede gestionar el backend.
  • RATE: número máximo de solicitudes (consultas) por segundo (RPS o QPS) objetivo. Se puede superar el RPS o QPS máximo objetivo si todos los backends están al máximo de su capacidad o por encima.
  • UTILIZATION: determina cómo se distribuye la carga en función de la utilización de las instancias de un grupo de instancias.
  • CUSTOM_METRICS: determina cómo se distribuye la carga en función de las métricas personalizadas definidas por el usuario.

Modos de balanceo disponibles para cada balanceador de carga

El modo de balanceo se define al añadir un backend al servicio de backend. Los modos de balanceo disponibles para un balanceador de carga dependen del tipo de balanceador de carga y del tipo de backends.

Los balanceadores de carga de red con paso a través requieren el CONNECTIONmodo de balanceo, pero no admiten la configuración de ninguna capacidad de destino.

Los balanceadores de carga de aplicaciones admiten los modos de balanceo RATE, UTILIZATION o CUSTOM_METRICS para los backends de grupos de instancias, y los modos de balanceo RATE o CUSTOM_METRICS para los NEGs zonales (puntos finales GCE_VM_IP_PORT) y los NEGs híbridos (puntos finales NON_GCP_PRIVATE_IP_PORT). En el caso de cualquier otro tipo de backend admitido, se debe omitir el modo de balanceo.

  • En el caso de los balanceadores de carga de aplicaciones clásicos, se selecciona una región en función de la ubicación del cliente y de si la región tiene capacidad disponible, según la capacidad de destino del modo de balanceo de carga. Después, en una región, la capacidad objetivo del modo de balanceo se usa para calcular las proporciones de cuántas solicitudes deben ir a cada backend de la región. Las solicitudes o conexiones se distribuyen de forma rotatoria entre las instancias o los endpoints del backend.

  • En el caso de los balanceadores de carga de aplicaciones externos globales, se selecciona una región en función de la ubicación del cliente y de si la región tiene capacidad disponible, según la capacidad de destino del modo de balanceo de carga. En una región, la capacidad objetivo del modo de balanceo se usa para calcular las proporciones de cuántas solicitudes deben dirigirse a cada backend (grupo de instancias o NEG) de la región. Puedes usar la política de balanceo de carga de servicios (serviceLbPolicy) y el ajuste de backend preferido para influir en la selección de backends específicos de una región. Además, en cada grupo de instancias o NEG, la política de balanceo de carga (LocalityLbPolicy) determina cómo se distribuye el tráfico a las instancias o los endpoints del grupo.

  • En el caso de los balanceadores de carga de aplicaciones internos entre regiones , los balanceadores de carga de aplicaciones externos regionales y los balanceadores de carga de aplicaciones internos regionales, la capacidad de destino del modo de balanceo se usa para calcular las proporciones de cuántas solicitudes deben dirigirse a cada backend (grupo de instancias o NEG) de la región. En cada grupo de instancias o NEG, la política de balanceo de carga (LocalityLbPolicy) determina cómo se distribuye el tráfico a las instancias o los endpoints del grupo. Solo el balanceador de carga de aplicaciones interno entre regiones admite el uso de la política de balanceo de carga de servicio (serviceLbPolicy) y los ajustes de backend preferido para influir en la selección de backends específicos de una región.

Los balanceadores de carga de red de proxy admiten los modos de balanceo CONNECTION o UTILIZATION para los backends de grupos de instancias de VM, el modo de balanceo CONNECTION para los NEGs zonales con GCE_VM_IP_PORT endpoints y el modo de balanceo CONNECTION para los NEGs híbridos (NON_GCP_PRIVATE_IP_PORT endpoints). En el caso de cualquier otro tipo de backend admitido, se debe omitir el modo de balanceo.

  • En el caso de los balanceadores de carga de red con proxy externos globales, se selecciona una región en función de la ubicación del cliente y de si la región tiene capacidad disponible, según la capacidad de destino del modo de balanceo de carga. En una región, la capacidad objetivo del modo de balanceo se usa para calcular las proporciones de cuántas solicitudes deben dirigirse a cada backend (grupo de instancias o NEG) de la región. Puedes usar la política de balanceo de carga de servicios (serviceLbPolicy) y el ajuste de backend preferido para influir en la selección de backends específicos de una región. Además, en cada grupo de instancias o NEG, la política de balanceo de carga (LocalityLbPolicy) determina cómo se distribuye el tráfico a las instancias o los endpoints del grupo.

  • En el caso de los balanceadores de carga de red con proxy internos interregionales, primero se selecciona la región configurada. En una región, la capacidad objetivo del modo de balanceo se usa para calcular las proporciones de cuántas solicitudes deben ir a cada backend (grupo de instancias o NEG) de la región. Puedes usar la política de balanceo de carga de servicios (serviceLbPolicy) y el ajuste de backend preferido para influir en la selección de backends específicos de una región. Además, en cada grupo de instancias o NEG, la política de balanceo de carga (LocalityLbPolicy) determina cómo se distribuye el tráfico a las instancias o los endpoints del grupo.

  • En el caso de los balanceadores de carga de red proxy clásicos, se selecciona una región en función de la ubicación del cliente y de si la región tiene capacidad disponible en función de la capacidad de destino del modo de balanceo de carga. A continuación, en una región, se usa la capacidad objetivo del modo de equilibrio de carga para calcular las proporciones de cuántas solicitudes o conexiones deben dirigirse a cada backend (grupo de instancias o NEG) de la región. Una vez que el balanceador de carga ha seleccionado un backend, las solicitudes o las conexiones se distribuyen de forma rotatoria entre las instancias de VM o los endpoints de red de cada backend.

  • En el caso de los balanceadores de carga de red de proxy externos regionales y los balanceadores de carga de red de proxy internos regionales, la capacidad de destino del modo de balanceo de carga se usa para calcular las proporciones de cuántas solicitudes deben dirigirse a cada backend (grupo de instancias o NEG). En cada grupo de instancias o NEG, la política de balanceo de carga (localityLbPolicy) determina cómo se distribuye el tráfico a las instancias o los endpoints del grupo.

En la siguiente tabla se resumen los modos de balanceo de carga disponibles para cada combinación de balanceador de carga y backend.

Tabla: Modos de balanceo de carga disponibles para cada balanceador de carga
Balanceador de carga Backends Modos de balanceo disponibles
Balanceador de carga de aplicación Grupos de instancias RATE, UTILIZATION o CUSTOM_METRICS
NEGs por zonas (puntos finales GCE_VM_IP_PORT) RATE o CUSTOM_METRICS
NEGs híbridas (puntos finales NON_GCP_PRIVATE_IP_PORT) RATE o CUSTOM_METRICS

Balanceador de carga de red de proxy

  • Balanceador de carga de red con proxy externo global
  • Balanceador de carga de red de proxy clásico
  • Balanceador de carga de red con proxy externo regional
  • Balanceador de carga de red con proxy interno regional
  • Balanceador de carga de red con proxy interno interregional
 Grupos de instancias CONNECTION o UTILIZATION
NEGs por zonas (puntos finales GCE_VM_IP_PORT) CONNECTION

NEGs híbridas (puntos finales NON_GCP_PRIVATE_IP_PORT)

 CONNECTION
Balanceador de carga de red de paso a través Grupos de instancias CONNECTION
NEGs por zonas (puntos finales GCE_VM_IP) CONNECTION

Si la utilización media de todas las VMs asociadas a un servicio de backend es inferior al 10%, Google Cloud puede que prefiera zonas específicas. Esto puede ocurrir cuando usas grupos de instancias gestionadas regionales, grupos de instancias gestionadas zonales en diferentes zonas y grupos de instancias sin gestionar zonales. Este desequilibrio zonal se resuelve automáticamente a medida que se envía más tráfico al balanceador de carga.

Para obtener más información, consulta gcloud compute backend-services add-backend.

Capacidad objetivo

Cada modo de balanceo tiene una capacidad objetivo correspondiente, que define uno de los siguientes máximos objetivo:

  • Número de conexiones
  • Tarifa
  • Uso de CPU

En todos los modos de balanceo, la capacidad objetivo no es un interruptor automático. Un balanceador de carga puede superar el máximo en determinadas condiciones, por ejemplo, si todas las VMs o los endpoints de backend han alcanzado el máximo.

Modo de balanceo de conexiones

En el modo de balanceo CONNECTION, la capacidad de destino define un número máximo de conexiones abiertas. A excepción de los balanceadores de carga de red de paso a través internos y externos, debes usar uno de los siguientes ajustes para especificar un número máximo de conexiones de destino:

  • max-connections-per-instance (por VM): número medio objetivo de conexiones de una sola VM.
  • max-connections-per-endpoint (por punto final de un NEG zonal): número medio de conexiones de destino de un solo punto final.
  • max-connections (por NEGs zonales y grupos de instancias zonales): número medio de conexiones de destino de todo el NEG o del grupo de instancias. En el caso de los grupos de instancias gestionadas regionales, usa max-connections-per-instance.

En la siguiente tabla se muestra cómo define el parámetro de capacidad objetivo lo siguiente:

  • La capacidad objetivo de todo el backend
  • La capacidad objetivo esperada de cada instancia o endpoint
Tabla: Capacidad objetivo de los back-ends que usan el modo de balanceo CONNECTION
Tipo de backend Capacidad objetivo
Si especifica Capacidad de todo el backend Capacidad esperada por instancia o por endpoint
Grupo de instancias
N instancias,
H en buen estado
 max-connections-per-instance=X X × N (X × N)/H
NEG por zonas
N puntos finales
H en buen estado 		max-connections-per-endpoint=X X × N (X × N)/H
Grupos de instancias
(excepto los grupos de instancias gestionadas regionales)

H instancias en buen estado 		max-connections=Y Y Y/H

Como se muestra, los ajustes max-connections-per-instance y max-connections-per-endpoint son proxies para calcular el número máximo de conexiones de todo el grupo de instancias de máquina virtual o de todo el NEG zonal:

  • En un grupo de instancias de VM con N instancias, el ajuste max-connections-per-instance=X tiene el mismo significado que el ajuste max-connections=X × N.
  • En un NEG zonal con N endpoints, definir max-connections-per-endpoint=X tiene el mismo significado que definir max-connections=X × N.

Modo de balanceo de tarifas

En el modo de balanceo RATE, debe definir la capacidad objetivo mediante uno de los siguientes parámetros:

  • max-rate-per-instance (por VM): proporciona una tasa de solicitudes HTTP media objetivo para una sola VM.
  • max-rate-per-endpoint (por endpoint en un NEG zonal): proporciona una tasa de solicitudes HTTP media de destino para un solo endpoint.
  • max-rate (por NEGs zonales y grupos de instancias zonales): proporciona una frecuencia media de solicitudes HTTP de destino para todo el NEG o el grupo de instancias. En el caso de los grupos de instancias gestionadas regionales, usa max-rate-per-instance.

En la siguiente tabla se muestra cómo define el parámetro de capacidad objetivo lo siguiente:

  • La capacidad objetivo de todo el backend
  • La capacidad objetivo esperada de cada instancia o endpoint
Tabla: Capacidad objetivo de los back-ends que usan el modo de equilibrio RATE
Tipo de backend Capacidad objetivo
Si especifica Capacidad de todo el backend Capacidad esperada por instancia o por endpoint
Grupo de instancias
N instancias,
H en buen estado
 max-rate-per-instance=X X × N (X × N)/H
NEG por zonas
N puntos finales,
H en buen estado 		max-rate-per-endpoint=X X × N (X × N)/H
Grupos de instancias
(excepto los grupos de instancias gestionadas regionales)

H instancias en buen estado 		max-rate=Y Y Y/H

Como se muestra, los ajustes max-rate-per-instance y max-rate-per-endpoint son proxies para calcular una frecuencia máxima objetivo de solicitudes HTTP para todo el grupo de instancias o todo el NEG zonal:

  • En un grupo de instancias con N instancias, definir max-rate-per-instance=X tiene el mismo significado que definir max-rate=X × N.
  • En un NEG por zona con N endpoints, definir max-rate-per-endpoint=X tiene el mismo significado que definir max-rate=X × N.

Modo de balanceo de la utilización

El modo de balanceo UTILIZATION no tiene una capacidad objetivo obligatoria. Tienes varias opciones que dependen del tipo de backend, tal como se resume en la tabla de la siguiente sección.

La capacidad objetivo max-utilization solo se puede especificar por grupo de instancias y no se puede aplicar a una VM concreta del grupo.

El modo de balanceo UTILIZATION no tiene una capacidad objetivo obligatoria. Cuando usas la consola para añadir un grupo de instancias de backend a un servicio de backend, la consola asigna el valor 0,8 (80%) a max-utilization si se selecciona el modo de balanceo de carga UTILIZATION. Google Cloud Google Cloud Además de max-utilization, el modo de balanceo UTILIZATION admite capacidades de destino más complejas, tal como se resume en la tabla de la siguiente sección.

Modo de balanceo de métricas personalizadas

El modo de balanceo CUSTOM_METRICS te permite definir tus propias métricas personalizadas que se pueden usar para determinar cómo se distribuye la carga. Las métricas personalizadas le permiten configurar el comportamiento de distribución del tráfico de su balanceador de carga en función de métricas específicas de los requisitos de su aplicación o infraestructura, en lugar de las métricas estándar de utilización o basadas en tarifas deGoogle Cloud.

Para obtener más información, consulte Métricas personalizadas de balanceadores de carga de aplicaciones.

Cambiar el modo de balanceo de un balanceador de carga

En algunos balanceadores de carga o configuraciones de balanceadores de carga, no puedes cambiar el modo de balanceo porque el servicio de backend solo tiene un modo de balanceo posible. En otros casos, en función del backend utilizado, puedes cambiar el modo de balanceo porque hay más de un modo disponible para esos servicios de backend.

Para ver qué modos de balanceo se admiten en cada balanceador de carga, consulta la tabla de modos de balanceo disponibles para cada balanceador de carga.

Modos de equilibrio y configuración de la capacidad objetivo

En los productos que admiten una especificación de capacidad objetivo, la capacidad objetivo no es un interruptor automático. Cuando se alcanza el máximo de capacidad objetivo configurado en una zona determinada, las nuevas solicitudes o conexiones se distribuyen a otras zonas que no estén procesando solicitudes o conexiones con la capacidad objetivo. Si todas las zonas han alcanzado la capacidad objetivo, las nuevas solicitudes o conexiones se distribuyen por sobrellenado.

Balanceadores de carga de aplicaciones y Cloud Service Mesh

En esta tabla se muestran las combinaciones disponibles de modo de balanceo y capacidad objetivo para balanceadores de carga de aplicaciones y Cloud Service Mesh.

Tabla: combinaciones de modo de balanceo y capacidad de destino para balanceadores de carga de aplicaciones y Cloud Service Mesh
Tipo de backend Modo de balanceo Especificación de capacidad objetivo
Grupos de instancias
  • zonales no gestionados
  • gestionado por zonas
  • gestionado regional
 RATE Debe especificar una de las siguientes opciones:
  • max-rate
     (solo se admite en grupos de instancias zonales)
  • max-rate-per-instance
     (compatible con todos los grupos de instancias)
UTILIZATION Puedes especificar opcionalmente una de las siguientes opciones:
  • (1) max-utilization
  • (2) max-rate
     (solo se admite en grupos de instancias zonales)
  • (3) max-rate-per-instance
     (compatible con todos los grupos de instancias)
  • (1) y (2) juntos
  • (1) y (3) juntos
CUSTOM_METRICS Puedes especificar opcionalmente una de las siguientes opciones:
  • 1) El max-utilization de la métrica (es decir, el campo backends[].customMetrics[].maxUtilization de la métrica).
  • (2) max-rate
     (solo se admite en grupos de instancias por zonas)
  • (3) max-rate-per-instance
     (compatible con todos los grupos de instancias)
  • (1) y (2) juntos
  • (1) y (3) juntos
No se admite max-utilization por backend.

NEGs por zonas

  • GCP_VM_IP_PORT

NEGs híbridas

  • NON_GCP_PRIVATE_IP_PORT
 RATE Debe especificar una de las siguientes opciones:
  • max-rate por NEG por zonas
  • max-rate-per-endpoint
CUSTOM_METRICS Puedes especificar opcionalmente una de las siguientes opciones:
  • 1) El max-utilization de la métrica (es decir, el campo backends[].customMetrics[].maxUtilization de la métrica).
  • (2) max-rate por NEG por zonas
  • (3) max-rate-per-endpoint
  • (1) y (2) juntos
  • (1) y (3) juntos
No se admite max-utilization por backend.

Balanceadores de carga de red de proxy

En esta tabla se enumeran las combinaciones de modo de balanceo y capacidad de destino disponibles para los balanceadores de carga de red de proxy.

Tabla: Combinaciones de modo de balanceo y capacidad de destino para balanceadores de carga de red de proxy
Tipo de backend Modo de balanceo Especificación de capacidad objetivo
Grupos de instancias
  • zonales no gestionados
  • gestionado por zonas
  • gestionado regional
 CONNECTION Debe especificar una de las siguientes opciones:
  • max-connections
     (solo se admite en grupos de instancias zonales)
  • max-rate-per-instance
     (compatible con todos los grupos de instancias)
UTILIZATION Puedes especificar opcionalmente una de las siguientes opciones:
  • (1) max-utilization
  • (2) max-connections
     (solo se admite en grupos de instancias zonales)
  • (3) max-connections-per-instance
     (compatible con todos los grupos de instancias)
  • (1) y (2) juntos
  • (1) y (3) juntos

NEGs por zonas

  • GCP_VM_IP_PORT

NEGs híbridas

  • NON_GCP_PRIVATE_IP_PORT
 CONNECTION Debe especificar una de las siguientes opciones:
  • max-connections por NEG por zonas
  • max-connections-per-endpoint

Balanceadores de carga de red de paso a través

En esta tabla se muestran las combinaciones disponibles de modo de balanceo y capacidad de destino para los balanceadores de carga de red con paso a través.

Tabla: combinaciones de modo de balanceo y capacidad de destino para balanceadores de carga de red con paso a través
Tipo de backend Modo de balanceo Especificación de capacidad objetivo
Grupos de instancias
  • zonales no gestionados
  • gestionado por zonas
  • gestionado regional
 CONNECTION No puedes especificar un número máximo de conexiones de destino.
NEGs por zonas
  • GCP_VM_IP
 CONNECTION No puedes especificar un número máximo de conexiones de destino.

Escalador de capacidad

Usa el escalador de capacidad para escalar la capacidad objetivo (utilización máxima, tasa máxima o conexiones máximas) sin cambiarla.

Para consultar la Google Cloud documentación de referencia, consulta lo siguiente:

Puedes ajustar el escalador de capacidad para escalar la capacidad objetivo efectiva sin cambiar explícitamente uno de los parámetros --max-*.

Puede asignar al escalador de capacidad cualquiera de estos valores:

  • El valor predeterminado es 1, lo que significa que el grupo sirve hasta el 100% de su capacidad configurada (en función de balancingMode).
  • El valor 0 significa que el grupo está completamente agotado y ofrece el 0% de su capacidad disponible. No puedes configurar un ajuste de 0 cuando solo hay un backend asociado al servicio de backend.
  • Un valor de 0.1 (10%) a 1.0 (100%).

En los siguientes ejemplos se muestra cómo funciona el escalador de capacidad junto con el ajuste de capacidad objetivo:

  • Si el modo de balanceo es RATE, el max-rate se define en 80 SPS y el escalador de capacidad es 1.0, la capacidad disponible también es 80 SPS.

  • Si el modo de balanceo es RATE, el max-rate se define en 80 SPS y el escalador de capacidad es 0.5, la capacidad disponible es 40 SPS (0.5 times 80).

  • Si el modo de balanceo es RATE, el max-rate se define en 80 SPS y el escalador de capacidad es 0.0, la capacidad disponible es cero (0).

Política de balanceo de carga de servicio

Una política de balanceo de carga del servicio (serviceLbPolicy) es un recurso asociado al servicio de backend del balanceador de carga. Te permite personalizar los parámetros que influyen en la forma en que se distribuye el tráfico entre los backends asociados a un servicio de backend:

  • Personaliza el algoritmo de balanceo de carga que se usa para determinar cómo se distribuye el tráfico entre regiones o zonas.
  • Habilita el drenaje automático de capacidad para que el balanceador de carga pueda drenar rápidamente el tráfico de los backends que no estén en buen estado.

Además, puedes designar back-ends específicos como back-ends preferidos. Estos back-ends deben usarse hasta su capacidad (es decir, la capacidad objetivo especificada por el modo de balanceo del back-end) antes de que se envíen solicitudes a los back-ends restantes.

Para obtener más información, consulta Optimizaciones avanzadas del balanceo de carga con una política de balanceo de carga de servicio.

Política de localidad de balanceo de carga

En el caso de un servicio de backend, la distribución del tráfico se basa en un modo de balanceo y en una política de localidad de balanceo de carga. El modo de balanceo determina la fracción del tráfico que se debe enviar a cada backend (grupo de instancias o NEG). A continuación, la política de localidad del balanceo de carga (LocalityLbPolicy) determina cómo se distribuye el tráfico entre las instancias o los endpoints de cada zona. En el caso de los grupos de instancias gestionados regionales, la política de localidad se aplica a cada zona que los compone.

La política de localidad del balanceo de carga se configura por servicio de backend. Puedes usar los siguientes ajustes:

  • ROUND_ROBIN (predeterminada): es la política de localidad de balanceo de carga predeterminada, en la que el balanceador de carga selecciona un backend en buen estado de forma rotatoria.

  • WEIGHTED_ROUND_ROBIN: el balanceador de carga usa métricas personalizadas definidas por el usuario para seleccionar la instancia o el endpoint óptimos del backend que atenderán la solicitud.

  • LEAST_REQUEST: un algoritmo O(1) en el que el balanceador de carga selecciona dos hosts aleatorios en buen estado y elige el que tenga menos solicitudes activas.

  • RING_HASH: este algoritmo implementa el cifrado con hash coherente en los backend. El algoritmo tiene la propiedad de que al añadir o retirar un host de un conjunto de N hosts solo se ven afectadas 1/N de las solicitudes.

  • RANDOM: el balanceador de carga selecciona un host aleatorio en buen estado.

  • ORIGINAL_DESTINATION: el balanceador de carga selecciona un backend en función de los metadatos de conexión del cliente. Las conexiones se abren a la dirección IP de destino original especificada en la solicitud del cliente entrante, antes de que la solicitud se redirigiera al balanceador de carga.

    ORIGINAL_DESTINATION no es compatible con los balanceadores de carga de aplicación externos globales y regionales.

  • MAGLEV: implementa un hash coherente en los back-ends y se puede usar como sustituto de la política RING_HASH. Maglev no es tan estable como RING_HASH pero ofrece tiempos más rápidos tanto de compilación de búsquedas en tablas como de selección de hosts. Para obtener más información sobre Maglev, consulta el documento técnico de Maglev.

  • WEIGHTED_MAGLEV: Implementa el balanceo de carga ponderado por instancia mediante los pesos que indican las comprobaciones de estado. Si se usa esta política, el servicio de backend debe configurar una comprobación del estado basada en HTTP que no sea antigua, y se espera que las respuestas de la comprobación del estado contengan el campo de encabezado de respuesta HTTP no estándar X-Load-Balancing-Endpoint-Weight para especificar los pesos por instancia. Las decisiones de balanceo de carga se toman en función de los pesos por instancia que se hayan notificado en las últimas respuestas de comprobación de estado procesadas, siempre que cada instancia notifique un peso válido o UNAVAILABLE_WEIGHT. De lo contrario, el balanceo de carga seguirá siendo de igual peso.

    WEIGHTED_MAGLEV solo se admite en balanceadores de carga de red de paso a través externos. Para ver un ejemplo, consulta Configurar el balanceo de carga ponderado para balanceadores de carga de red de paso a través externos.

La configuración de una política de localidad de balanceo de carga solo se admite en los servicios de backend que se usan con los siguientes balanceadores de carga:

  • Balanceador de carga de aplicación externo global
  • Balanceador de carga de aplicación externo regional
  • Balanceador de carga de aplicación interno entre regiones
  • Balanceador de carga de aplicación interno regional
  • Balanceador de carga de red de paso a través externo

Ten en cuenta que el valor predeterminado efectivo de la política de localidad de balanceo de carga (localityLbPolicy) cambia en función de los ajustes de afinidad de sesión. Si no se configura la afinidad de sesión (es decir, si sessionAffinity mantiene el valor predeterminado NONE), el valor predeterminado de localityLbPolicy es ROUND_ROBIN. Si la afinidad de sesión tiene un valor distinto de NONE, el valor predeterminado de localityLbPolicy es MAGLEV.

Para configurar una política de localidad de balanceo de carga, puedes usar la consola deGoogle Cloud , gcloud (--locality-lb-policy) o la API (localityLbPolicy).

Cloud Service Mesh y distribución del tráfico

Cloud Service Mesh también usa recursos de servicio backend. En concreto, Cloud Service Mesh usa servicios de backend cuyo esquema de balanceo de carga es INTERNAL_SELF_MANAGED. En el caso de un servicio de backend interno autogestionado, la distribución del tráfico se basa en la combinación de un modo de balanceo de carga y una política de balanceo de carga. El servicio de backend dirige el tráfico a un backend según el modo de balanceo del backend. A continuación, Cloud Service Mesh distribuye el tráfico según una política de balanceo de carga.

Los servicios de backend internos autogestionados admiten los siguientes modos de balanceo:

  • UTILIZATION, si todos los backends son grupos de instancias
  • RATE, si todos los backends son grupos de instancias o NEGs por zonas

Si elige el modo de equilibrio RATE, debe especificar una tasa máxima, una tasa máxima por instancia o una tasa máxima por endpoint.

Para obtener más información sobre Cloud Service Mesh, consulta los conceptos de Cloud Service Mesh.

Subconjunto de backend

La creación de subconjuntos de backend es una función opcional que mejora el rendimiento y la escalabilidad al asignar un subconjunto de backends a cada una de las instancias de proxy.

Se admite la creación de subconjuntos de backend en los siguientes casos:

  • Balanceador de carga de aplicación interno regional
  • Balanceador de carga de red de paso a través interno

Subconjuntos de backend para balanceadores de carga de aplicaciones internos regionales

El balanceador de carga de aplicación interno entre regiones no admite subconjuntos de backend.

En el caso de los balanceadores de carga de aplicaciones internos regionales, la creación de subconjuntos de backend asigna automáticamente solo un subconjunto de los backends del servicio de backend regional a cada instancia de proxy. De forma predeterminada, cada instancia de proxy abre conexiones a todos los backends de un servicio de backend. Cuando el número de instancias de proxy y de back-ends es elevado, abrir conexiones a todos los back-ends puede provocar problemas de rendimiento.

Al habilitar la creación de subconjuntos, cada proxy solo abre conexiones a un subconjunto de los back-ends, lo que reduce el número de conexiones que se mantienen abiertas a cada back-end. Reducir el número de conexiones abiertas simultáneamente a cada backend puede mejorar el rendimiento tanto de los backends como de los proxies.

En el siguiente diagrama se muestra un balanceador de carga con dos proxies. Sin la creación de subconjuntos de backend, el tráfico de ambos proxies se distribuye a todos los backends del servicio de backend 1. Si el subconjunto de backend está habilitado, el tráfico de cada proxy se distribuye a un subconjunto de los backends. El tráfico del proxy 1 se distribuye a los back-ends 1 y 2, y el tráfico del proxy 2 se distribuye a los back-ends 3 y 4.

Comparación del balanceador de carga de aplicación interno sin y con subconjuntos de backend.
Comparación del balanceador de carga de aplicación interno sin y con subconjuntos de backend (haga clic para ampliar).

Además, puedes acotar el tráfico de balanceo de carga a los backends configurando la política localityLbPolicy. Para obtener más información, consulta las políticas de tráfico.

Para obtener información sobre cómo configurar el subconjunto de backend en balanceadores de carga de aplicación internos, consulta Configurar subconjuntos de backend.

Advertencias relacionadas con la creación de subconjuntos de backends para el balanceador de carga de aplicaciones interno
  • Aunque el subconjunto de backend está diseñado para asegurar que todas las instancias de backend se utilicen correctamente, puede introducir cierto sesgo en la cantidad de tráfico que recibe cada backend. Se recomienda definir localityLbPolicy en LEAST_REQUEST para los servicios de backend que sean sensibles al equilibrio de la carga del backend.
  • Si se habilita o inhabilita la creación de subconjuntos, se interrumpirán las conexiones.
  • Para que el backend pueda crear subconjuntos, la afinidad de sesión debe ser NONE (un hash de 5 tuplas). Otras opciones de afinidad de sesión solo se pueden usar si la creación de subconjuntos de backend está inhabilitada. Los valores predeterminados de las marcas --subsetting-policy y --session-affinity son NONE, y solo se puede asignar un valor diferente a una de ellas a la vez.

Subconjuntos de backend para balanceadores de carga de red de paso a través internos

La creación de subconjuntos de backend para balanceadores de carga de red de paso a través internos te permite escalar tu balanceador de carga de red de paso a través interno para admitir un mayor número de instancias de máquina virtual de backend por servicio de backend interno.

Para obtener información sobre cómo afecta la creación de subconjuntos a este límite, consulta la sección Servicios backend del artículo Cuotas y límites de los recursos de balanceo de carga.

De forma predeterminada, la creación de subconjuntos está inhabilitada, lo que limita el servicio de backend a distribuir contenido a un máximo de 250 instancias o endpoints de backend. Si tu servicio backend necesita admitir más de 250 backends, puedes habilitar la creación de subconjuntos. Cuando se habilita la creación de subconjuntos, se selecciona un subconjunto de instancias de backend para cada conexión de cliente.

En el siguiente diagrama se muestra un modelo reducido de la diferencia entre estos dos modos de funcionamiento.

Comparación de un balanceador de carga de red de paso a través interno sin subconjuntos y con subconjuntos.
Comparación de un balanceador de carga de red de paso a través interno sin y con subconjuntos (haz clic para ampliar).

Sin subconjuntos, se utiliza mejor el conjunto completo de back-ends correctos y las nuevas conexiones de clientes se distribuyen entre todos los back-ends correctos según la distribución del tráfico. La creación de subconjuntos impone restricciones de balanceo de carga, pero permite que el balanceador de carga admita más de 250 back-ends.

Para obtener instrucciones de configuración, consulta Subconjuntos.

Advertencias relacionadas con la creación de subconjuntos de backend para el balanceador de carga de red de paso a través interno
  • Cuando se habilita la creación de subconjuntos, no todos los back-ends recibirán tráfico de un remitente determinado, aunque el número de back-ends sea pequeño.
  • Para ver el número máximo de instancias de backend cuando se habilita la creación de subconjuntos, consulta la página de cuotas .
  • Solo se admite la afinidad de sesión de 5 tuplas con subconjuntos.
  • Packet Mirroring no es compatible con la creación de subconjuntos.
  • Si se habilita o inhabilita la creación de subconjuntos, se interrumpirán las conexiones.
  • Si los clientes locales necesitan acceder a un balanceador de carga de red de paso a través interno, la creación de subconjuntos puede reducir considerablemente el número de back-ends que reciben conexiones de sus clientes locales. Esto se debe a que la región del túnel de Cloud VPN o de la vinculación de VLAN de Cloud Interconnect determina el subconjunto de los back-ends del balanceador de carga. Todos los puntos finales de Cloud VPN y Cloud Interconnect de una región específica usan el mismo subconjunto. Se usan diferentes subconjuntos en distintas regiones.

Precios de subconjuntos de backend

No se aplican cargos por usar el subconjunto de backend. Para obtener más información, consulta la página Todos los precios de redes.

Afinidad de sesión

La afinidad de sesión te permite controlar cómo selecciona el balanceador de carga los backends para las conexiones nuevas de forma predecible, siempre que el número de backends en buen estado se mantenga constante. Esto es útil para las aplicaciones que necesitan que varias solicitudes de un usuario determinado se dirijan al mismo backend o endpoint. Estas aplicaciones suelen incluir servidores con estado que se usan para servir anuncios, juegos o servicios con un almacenamiento en caché interno elevado.

Los balanceadores de cargaGoogle Cloud proporcionan afinidad de sesión en la medida de lo posible. Factores como los cambios en los estados de las comprobaciones de estado del backend, la adición o eliminación de backends, los cambios en los pesos del backend (incluida la habilitación o inhabilitación del balanceo ponderado) o los cambios en la capacidad del backend, medidos por el modo de balanceo, pueden interrumpir la afinidad de sesión.

El balanceo de carga con afinidad de sesión funciona bien cuando hay una distribución razonablemente grande de conexiones únicas. Razonablemente grande significa al menos varias veces el número de back-ends. Si pruebas un balanceador de carga con un número reducido de conexiones, no obtendrás una representación precisa de la distribución de las conexiones de cliente entre los back-ends.

De forma predeterminada, todos los balanceadores de carga Google Cloud seleccionan los backends mediante un hash de cinco tuplas (--session-affinity=NONE), de la siguiente manera:

  • Dirección IP de origen del paquete
  • Puerto de origen del paquete (si está presente en el encabezado del paquete)
  • Dirección IP de destino del paquete
  • Puerto de destino del paquete (si está presente en el encabezado del paquete)
  • Protocolo del paquete

Para obtener más información sobre la afinidad de sesión en los balanceadores de carga de red de paso a través, consulta los siguientes documentos:

Para obtener más información sobre la afinidad de sesión de los balanceadores de carga de aplicaciones, consulte los siguientes documentos:

Para obtener más información sobre la afinidad de sesión de los balanceadores de carga de red proxy, consulta los siguientes documentos:

Tiempo de espera del servicio de backend

La mayoría de los Google Cloud balanceadores de carga tienen un tiempo de espera del servicio de backend. El valor predeterminado es 30 segundos. El intervalo completo de valores de tiempo de espera permitidos es de 1 a 2.147.483.647 segundos.

  • En el caso de los balanceadores de carga de aplicaciones externos e internos que usan el protocolo HTTP, HTTPS o HTTP/2, el tiempo de espera del servicio de backend es un tiempo de espera de solicitud y respuesta para el tráfico HTTP(S).

    Para obtener más información sobre el tiempo de espera del servicio de backend de cada balanceador de carga, consulta lo siguiente:

  • En el caso de los balanceadores de carga de red de proxy externo, el tiempo de espera es un tiempo de espera inactivo. Para permitir que pase más o menos tiempo antes de que se elimine la conexión, cambia el valor del tiempo de espera. Este tiempo de espera también se usa en las conexiones WebSocket.

  • En el caso de los balanceadores de carga de red de paso a través internos y externos, puede definir el valor del tiempo de espera del servicio de backend mediante gcloud o la API, pero el valor se ignora. El tiempo de espera del servicio de backend no tiene ningún significado para estos balanceadores de carga de transferencia.

  • En Cloud Service Mesh, el campo de tiempo de espera del servicio de backend (especificado mediante timeoutSec) no se admite con los servicios gRPC sin proxy. En el caso de estos servicios, configura el tiempo de espera del servicio de backend mediante el campo maxStreamDuration. Esto se debe a que gRPC no admite la semántica de timeoutSec, que especifica el tiempo que se debe esperar a que un backend devuelva una respuesta completa después de enviar la solicitud. El tiempo de espera de gRPC especifica el tiempo que se debe esperar desde el inicio de la emisión hasta que la respuesta se haya procesado por completo, incluidos todos los reintentos.

Comprobaciones del estado

Cada servicio de backend cuyos backends sean grupos de instancias o NEGs zonales debe tener una comprobación de estado asociada. Los servicios de backend que usen un NEG sin servidor o un NEG de Internet global como backend no deben hacer referencia a una comprobación de estado.

Cuando creas un balanceador de carga con la Google Cloud consola, puedes crear la comprobación de estado, si es necesario, al crear el balanceador de carga o puedes hacer referencia a una comprobación de estado que ya tengas.

Cuando creas un servicio backend con backends de grupo de instancias o NEG zonales mediante la CLI de Google Cloud o la API, debes hacer referencia a una comprobación de estado ya creada. Consulta la guía de balanceadores de carga de la descripción general de las comprobaciones del estado para obtener información sobre el tipo y el ámbito de la comprobación del estado que se requiere.

Para obtener más información, consulta los siguientes documentos:

Funciones adicionales habilitadas en el recurso de servicio backend

Algunos servicios backend admiten las siguientes funciones opcionales.

Cloud CDN

Cloud CDN usa la red perimetral mundial de Google para mostrar el contenido que se encuentre más cerca de los usuarios, lo que acelera tus sitios web y aplicaciones. Cloud CDN está habilitado en los servicios de backend que usan los balanceadores de carga de aplicación externos globales. El balanceador de carga proporciona las direcciones IP de frontend y los puertos que reciben las solicitudes, así como los backends que responden a ellas.

Para obtener más información, consulta la documentación de Cloud CDN.

Cloud CDN no es compatible con IAP. No se pueden habilitar en el mismo servicio de backend.

Cloud Armor

Si usas uno de los siguientes balanceadores de carga, puedes añadir protección adicional a tus aplicaciones habilitando Cloud Armor en el servicio de backend durante la creación del balanceador de carga:

Si usas la Google Cloud consola, puedes hacer lo siguiente:

  • Selecciona una política de seguridad de Cloud Armor.
  • Aceptar la configuración de una política de seguridad de limitación de frecuencia de Cloud Armor predeterminada con un nombre, un recuento de solicitudes, un intervalo, una clave y parámetros de limitación de frecuencia personalizables. Si usas Cloud Armor con un servicio de proxy upstream, como un proveedor de CDN, Enforce_on_key debe definirse como una dirección IP XFF.
  • Para inhabilitar la protección de Cloud Armor, selecciona Ninguno.

IAP

IAP te permite establecer una capa de autorización central para las aplicaciones a las que se accede mediante HTTPS, de forma que puedas usar un modelo de control de acceso a nivel de aplicación en lugar de depender de cortafuegos a nivel de red. IAP es compatible con determinados balanceadores de carga de aplicaciones.

IAP no es compatible con Cloud CDN. No se pueden habilitar en el mismo servicio de backend.

Funciones avanzadas de gestión del tráfico

Para obtener información sobre las funciones avanzadas de gestión del tráfico que se configuran en los servicios de backend y los mapas de URLs asociados a los balanceadores de carga, consulta los siguientes artículos:

API y referencia de gcloud

Para obtener más información sobre las propiedades del recurso de servicio backend, consulta las siguientes referencias:

Siguientes pasos

Para consultar la documentación relacionada e información sobre cómo se usan los servicios backend en el balanceo de carga, consulta lo siguiente:

En el caso de los vídeos relacionados: