Descripción general de los servicios de backend

Un servicio de backend define cómo Cloud Load Balancing distribuye el tráfico. La configuración del servicio de backend contiene un conjunto de valores, como el protocolo que se usa para conectarse a backends, varios parámetros de configuración de distribución y sesión, verificaciones de estado y tiempos de espera. Esta configuración proporciona un control detallado sobre el comportamiento del balanceador de cargas. Para comenzar, la mayoría de las opciones de configuración tienen valores predeterminados que permiten una configuración rápida. Un servicio de backend puede tener un permiso global oregional.

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

• Dirigir el tráfico a los backends correctos, que son grupos de instancias o grupos de extremos de red (NEG).
• Distribuir el tráfico según un modo de balanceo, que es una configuración para cada backend
• Determinar qué verificación de estado supervisa el estado de los backends
• Especificar la afinidad de sesión.
• Determina si otros servicios están habilitados, incluidos los siguientes que solo están disponibles para ciertos balanceadores de cargas:
  • Cloud CDN
  • Políticas de seguridad de Google Cloud Armor
  • Identity-Aware Proxy
• Designa los servicios de backend globales y regionales como un servicio en las aplicaciones de App Hub.

Establece estos valores cuando creas un servicio de backend o cuando agregas un backend al servicio de backend.

Nota: Si usas el balanceador de cargas de aplicaciones externo global o el balanceador de cargas de aplicaciones clásico, y tus backends entregan contenido estático, considera usar buckets de backend en lugar de los servicios de backend. Consulta Buckets de backend para el balanceador de cargas de aplicaciones externo global o Buckets de backend para el balanceador de cargas de aplicaciones clásico.

En la siguiente tabla, se resumen los balanceadores de cargas que usan servicios de backend. El producto que usas determina la cantidad máxima de servicios de backend, el permiso de un servicio de backend, el tipo de backends compatibles y el esquema de balanceo de cargas del servicio de backend. El esquema de balanceo de cargas es un identificador que Google usa para clasificar reglas de reenvío y servicios de backend. Cada producto de balanceo de cargas usa un esquema de balanceo de cargas para las reglas de reenvío y los servicios de backend. Algunos esquemas se comparten entre los productos.

Tabla: Servicios de backend y tipos de backend compatibles

Producto	Cantidad máxima de servicios de backend	Alcance del servicio de backend	Tipos de backends compatibles	Esquema de balanceo de cargas
Balanceador de cargas de aplicaciones externo global	Varias	Global	Cada servicio de backend admite una de las siguientes combinaciones: Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos ^* Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT ^* Todos los NEG de conectividad híbrida: Uno o más NEG de tipo NON_GCP_PRIVATE_IP_PORT Una combinación de NEG zonales y híbridos: NEG de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT ^† Todos los NEG sin servidores: Uno o más recursos de App Engine, Cloud Run o Cloud Run Functions Un NEG de Internet global para un backend externo NEG de Private Service Connect: APIs de Google: un único NEG de Private Service Connect Servicios administrados: uno o más NEG de Private Service Connect	EXTERNAL_MANAGED
Balanceador de cargas de aplicaciones clásico	Varias	Global^‡	Cada servicio de backend admite una de las siguientes combinaciones: Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT Todos los NEG de conectividad híbrida: Uno o más NEG de tipo NON_GCP_PRIVATE_IP_PORT Una combinación de NEG zonales y híbridos: NEG de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT ^† Todos los NEG sin servidores: Uno o más recursos de App Engine, Cloud Run o Cloud Run Functions Un NEG de Internet global para un backend externo	EXTERNO^#
Balanceador de cargas de aplicaciones externo regional	Varias	Regional	Cada servicio de backend admite una de las siguientes combinaciones: Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos ^* Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT ^* Todos los NEG de conectividad híbrida: Uno o más NEG de tipo NON_GCP_PRIVATE_IP_PORT Una combinación de NEG zonales y híbridos: NEG de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT ^† Un solo NEG sin servidores (solo para Cloud Run o Cloud Run Functions de 2ª gen.) Un NEG de Private Service Connect único Todos los NEGs de Internet regionales para un backend externo	EXTERNAL_MANAGED
Balanceador de cargas de aplicaciones interno entre regiones	Varias	Global	Cada servicio de backend admite una de las siguientes combinaciones: Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos ^* Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT ^* Todos los NEG de conectividad híbrida: Uno o más NEG de tipo NON_GCP_PRIVATE_IP_PORT Una combinación de NEG zonales y híbridos: NEG de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT ^† Un solo NEG sin servidores (solo para Cloud Run o Cloud Run Functions de 2ª gen.) NEG de Private Service Connect: APIs de Google: un único NEG de Private Service Connect Servicios administrados: uno o más NEG de Private Service Connect	INTERNAL_MANAGED
Balanceador de cargas de aplicaciones interno regional	Varias	Regional	Cada servicio de backend admite una de las siguientes combinaciones: Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos ^* Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT ^* Todos los NEG de conectividad híbrida: Uno o más NEG de tipo NON_GCP_PRIVATE_IP_PORT Una combinación de NEG zonales y híbridos: NEG de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT ^† Un solo NEG sin servidores (solo para Cloud Run o Cloud Run Functions de 2ª gen.) Un NEG de Private Service Connect único Todos los NEGs de Internet regionales para un backend externo	INTERNAL_MANAGED
Balanceador de cargas de red del 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 más backends de grupos de instancias administrados, no administrados o una combinación de ambos ^* Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT ^* Todos los NEG de conectividad híbrida: Uno o más NEG de tipo NON_GCP_PRIVATE_IP_PORT Una combinación de NEG zonales y híbridos: NEG de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT ^† NEG de Private Service Connect: APIs de Google: un único NEG de Private Service Connect Servicios administrados: uno o más NEG de Private Service Connect	EXTERNAL_MANAGED
Balanceador de cargas de red del 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 más backends de grupos de instancias administrados, no administrados o una combinación de ambos Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT Todos los NEG de conectividad híbrida: Uno o más NEG de tipo NON_GCP_PRIVATE_IP_PORT Una combinación de NEG zonales y híbridos: NEG de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT ^†	EXTERNO
Balanceador de cargas de red del 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 más backends de grupos de instancias administrados, no administrados o una combinación de ambos ^* Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT ^* Todos los NEG de conectividad híbrida: Uno o más NEG de tipo NON_GCP_PRIVATE_IP_PORT Una combinación de NEG zonales y híbridos: NEG de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT Todos los NEGs de Internet regionales para un backend externo Un NEG de Private Service Connect único	EXTERNAL_MANAGED
Balanceador de cargas de red de 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 más backends de grupos de instancias administrados, no administrados o una combinación de ambos ^* Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT ^* Todos los NEG de conectividad híbrida: Uno o más NEG de tipo NON_GCP_PRIVATE_IP_PORT Una combinación de NEG zonales y híbridos: NEG de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT Todos los NEGs de Internet regionales para un backend externo Un NEG de Private Service Connect único	INTERNAL_MANAGED
Balanceador de cargas de red de proxy interno entre regiones	Varias	Global	El servicio de backend admite una de las siguientes combinaciones de backend: Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos ^* Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT ^* Todos los NEG de conectividad híbrida: Uno o más NEG de tipo NON_GCP_PRIVATE_IP_PORT Una combinación de NEG zonales y híbridos: NEG de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT NEG de Private Service Connect: APIs de Google: un único NEG de Private Service Connect Servicios administrados: uno o más NEG de Private Service Connect	INTERNAL_MANAGED
Balanceador de cargas de red de transferencia externo	1	Regional	El servicio de backend admite una de las siguientes combinaciones de backend: Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP	EXTERNO
Balanceador de cargas de red de transferencia interno	1	Regional, pero configurable para que sea accesible a nivel global	El servicio de backend admite una de las siguientes combinaciones de backend: Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP Un NEG de asignación de puertos	INTERNAL
Cloud Service Mesh	Varias	Global	Cada servicio de backend admite una de las siguientes combinaciones: Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT o NON_GCP_PRIVATE_IP_PORT Un NEG de Internet de tipo INTERNET_FQDN_PORT Una o más vinculaciones del servicio	INTERNAL_SELF_MANAGED

^* Compatible con IPv4 y Grupos de instancias IPv6 (pila doble) y backends de NEG zonales. Compatibilidad con NEG zonales pila doble solo en extremos de tipo GCE_VM_IP_PORT.

^† Para implementaciones de GKE, los backends de NEG mixtos solo son compatibles con NEG independientes.

^‡ Los servicios de backend que usan los balanceadores de cargas de aplicaciones clásicos y los balanceadores de cargas de red del proxy clásicos siempre tienen alcance global, ya sea de nivel de red Estándar o Premium. However, in Standard Tier the following restrictions apply:

• La regla de reenvío y su dirección IP externa son regionales.
• Todos los backends conectados al servicio de backend deben estar ubicados en la misma región que la regla de reenvío.

^# Es posible adjuntar servicios de backend EXTERNAL_MANAGED a reglas de reenvío EXTERNAL. Sin embargo, los servicios de backend EXTERNAL no se pueden adjuntar a las reglas de reenvío EXTERNAL_MANAGED. Para aprovechar las nuevas funciones disponibles solo con el balanceador de cargas de aplicaciones externo global, te recomendamos que migres tus recursos EXTERNAL existentes a EXTERNAL_MANAGED con el proceso de migración que se describe en Migra recursos del balanceador de cargas de aplicaciones clásico al balanceador de cargas de aplicaciones externo global.

Nombres de los balanceadores de cargas

En el caso de los balanceadores de cargas de red del proxy y los balanceadores de cargas de red de transferencia, el nombre del balanceador de cargas siempre es el mismo que el del servicio de backend. El comportamiento de cada interfaz Google Cloud es el siguiente:

• Google Cloud console Si creas un balanceador de cargas de red de proxy o un balanceador de cargas de red de transferencia con la consola de Google Cloud , al servicio de backend se le asignará automáticamente el mismo nombre que ingresaste para el nombre del balanceador de cargas.
• Google Cloud CLI o API Si creas un balanceador de cargas de red proxy o un balanceador de cargas de red de transferencia con gcloud CLI o la API, ingresa el nombre que elijas cuando crees el servicio de backend. El nombre de este servicio de backend se refleja en la consola de Google Cloud como el nombre del balanceador de cargas.

Para obtener información sobre cómo funciona la asignación de nombres para los balanceadores de cargas de aplicaciones, consulta Descripción general de los mapas de URL: Asignación de nombres a los balanceadores de cargas.

Backends

Un backend es uno o más extremos que reciben tráfico de un Google Cloudbalanceador de cargas, un proxy de Envoy configurado por Cloud Service Mesh o un cliente de gRPC sin proxy. Existen varios tipos de backends:

• Grupo de instancias que contiene instancias de máquina virtual (VM). Un grupo de instancias puede ser administrado (MIG), con o sin ajuste de escala automático, o puede ser no administrado. Más de un servicio de backend puede hacer referencia a un grupo de instancias, pero todos los servicios de backend que hacen referencia al grupo de instancias deben usar modos de balanceo compatibles. Para obtener más información, consulta Restricciones y orientación para los grupos de instancias en este documento.
• NEG zonal
• NEG sin servidores
• NEG de Private Service Connect
• NEG de Internet
• NEG de conectividad híbrida
• NEG de asignación de puertos
• Vinculaciones del servicio del Directorio de servicios

No puedes borrar un grupo de instancias de backend o un NEG que estén asociados con un servicio de backend. Antes de borrar un grupo de instancias o un NEG, primero debes quitarlos como un backend de todos los servicios de backend que hacen referencia a ellos.

Grupos de instancias

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

Direcciones IP externas y VM de backend

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

• En el caso de los balanceadores de cargas de aplicaciones externos globales y los balanceadores de cargas de red del proxy externos: los clientes se comunican con un Google Front End (GFE) que aloja la dirección IP externa del balanceador de cargas. Los GFE se comunican con las VMs o los extremos de backend mediante el envío de paquetes a una dirección interna creada mediante la unión de un identificador a la red de VPC del backend con la dirección IPv4 interna del backend. La comunicación entre los GFE y los extremos o VMs de backend se facilita mediante rutas especiales.
  • Para los backends de grupo de instancias, la dirección IPv4 interna siempre es la dirección IPv4 interna principal que corresponde a la interfaz nic0 de la VM.
  • Para extremos GCE_VM_IP_PORT en un NEG zonal, puedes especificar la dirección IP del extremo como la dirección IPv4 principal asociada con cualquier interfaz de red de una VM o cualquier dirección IPv4 de un rango de direcciones IP de alias asociado con cualquier red interfaz de una VM.

• Para los balanceadores de cargas de aplicaciones externos regionales: los clientes se comunican con un proxy de Envoy que aloja la dirección IP externa del balanceador de cargas. Los proxies de Envoy se comunican con las VMa o los extremos de backend mediante el envío de paquetes a una dirección interna creada mediante la unión de un identificador a la red de VPC del backend con la dirección IPv4 interna del backend.

  • Para los backends de grupo 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 cargas.
  • Para extremos GCE_VM_IP_PORT en un NEG zonal, puedes especificar la dirección IP del extremo como la dirección IPv4 principal asociada con cualquier interfaz de red de una VM o cualquier dirección IPv4 de un rango de direcciones IP de alias asociado con cualquier interfaz de red de una VM, siempre que la interfaz de red esté en la misma red que el balanceador de cargas.

• Para los balanceadores de cargas de red externos: los clientes se comunican directamente con los backends a través de la infraestructura de balanceo de cargas de paso de Maglev de Google. Los paquetes se enrutan y se entregan a los backends con las direcciones IP de origen y destino originales conservadas. Los backends responden a los clientes mediante el retorno directo del servidor. Los métodos utilizados para seleccionar un backend y realizar un seguimiento de las conexiones son configurables.

  • Para los backends de grupos de instancias, los paquetes siempre se entregan a la interfaz nic0 de la VM.
  • Para los extremos GCE_VM_IP en un NEG zonal, los paquetes se entregan a la interfaz de red de la VM que se encuentra en la subred asociada con el NEG.

Puertos con nombre

El atributo del puerto con nombre del servicio de backend solo se aplica a los balanceadores de cargas basados en proxy (balanceadores de cargas de aplicaciones y balanceadores de cargas 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 del grupo de instancias, debes configurar uno o más puertos con nombre mediante pares clave-valor. La clave representa un nombre de puerto significativo que eliges y el valor representa el número de puerto que asignas 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, debes especificar un solo puerto con nombre únicamente con el nombre del puerto (--port-name).

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

Por ejemplo, puedes configurar 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

Luego, debes hacer referencia al puerto con nombre en la configuración del servicio de backend mediante el --port-name en el servicio de backend configurado 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 cuando se comunica con las VM en grupos de instancias diferentes si cada grupo de instancias especifica un número de puerto diferente para el mismo nombre de puerto.

No es necesario que el número de puerto resuelto que usa el servicio de backend del balanceador de cargas de proxy coincida con el número de puerto que usan las reglas de reenvío del balanceador de cargas. Un balanceador de cargas de proxy escucha las conexiones TCP enviadas a la dirección IP y al puerto de destino de las reglas de reenvío. Debido a que el proxy abre una segunda conexión de TCP a sus backends, el puerto de destino de la segunda conexión de TCP puede ser diferente.

Los puertos con nombre solo se aplican a los backends de grupos de instancias. Los NEG zonales con extremos GCE_VM_IP_PORT, los NEG híbridos con extremos NON_GCP_PRIVATE_IP_PORT los NEG de Internet definen puertos mediante un mecanismo diferente, es decir, en los extremos. NEG sin servidores hace referencia a los servicios de Google y los NEG de PSC hacen referencia a los adjuntos de servicio mediante abstracciones que no implican especificar un puerto de destino.

Los balanceadores de cargas de red de transferencia internos y los balanceadores de cargas de red de transferencias externos no usan puertos con nombre. Esto se debe a que son balanceadores de cargas de paso que enrutan las conexiones directamente a los backends en lugar de crear conexiones nuevas. Los paquetes se entregan a los backends mediante la preservación de la dirección IP y el puerto de destino de la regla de reenvío del balanceador de cargas.

Para aprender a crear puertos con nombre, consulta las siguientes instrucciones:

• Grupos de instancias no administrados: Trabaja con puertos con nombre
• Grupos de instancias administrados: Asigna puertos con nombre a grupos de instancias administrados

Restricciones y recomendaciones para grupos de instancias

Ten en cuenta lo siguiente cuando uses backends de grupos de instancias:

• Una instancia de VM solo puede pertenecer a un grupo de instancias con balanceo de cargas. Por ejemplo, una VM puede ser miembro de dos grupos de instancias no administrados, o bien de un grupo de instancias administrado y un grupo de instancias no administrado. Cuando una VM es miembro de dos o más grupos de instancias, solo uno de los grupos de instancias puede ser referenciado por uno o más servicios de backend del balanceador de cargas.

• El mismo grupo de instancias se puede usar en dos o más servicios de backend. Cada asignación entre un grupo de instancias y un servicio de backend puede usar un modo de balanceo diferente, excepto para las combinaciones de modos de balanceo incompatibles.

  • Las combinaciones de modo de balanceo incompatibles son las siguientes:

    • El modo de balanceo UTILIZATION no es compatible con ningún otro modo de balanceo. Si un grupo de instancias es un backend de varios servicios de backend, el grupo de instancias debe usar el modo de balanceo UTILIZATION en cada servicio de backend.

    • El modo de balanceo CUSTOM_METRICS no es compatible con ningún otro modo de balanceo. Si un grupo de instancias es un backend de varios servicios de backend, el grupo de instancias debe usar el modo de balanceo CUSTOM_METRICS en cada servicio de backend.

  • Como consecuencia de las combinaciones de modos de balanceo incompatibles, si un grupo de instancias usa el modo de balanceo UTILIZATION o CUSTOM_METRICS como backend para al menos un servicio de backend, el mismo grupo de instancias no se puede usar como backend para un balanceador de cargas de red de transferencia porque estos requieren el modo de balanceo CONNECTION.

• No hay un solo comando que pueda cambiar el modo de balanceo del mismo grupo de instancias en varios servicios de backend. Para cambiar el modo de balanceo de un grupo de instancias que es backend de dos o más servicios de backend, puedes usar esta técnica:

  • Quita el grupo de instancias como backend de todos los servicios de backend, excepto de uno.
  • Cambia el modo de balanceo del grupo de instancias para el servicio de backend restante.
  • Vuelve a agregar el grupo de instancias como backend a los otros servicios de backend.

Considera las siguientes prácticas recomendadas, que proporcionan opciones más flexibles:

• Evita usar el mismo grupo de instancias como backend para dos o más servicios de backend. En su lugar, usa varios NEG.

  • A diferencia de los grupos de instancias, una VM puede tener un extremo en dos o más NEG con balanceo de cargas.

  • Por ejemplo, si una VM necesita ser simultáneamente un backend de un balanceador de cargas de red de transferencia y de un balanceador de cargas de red de proxy o un balanceador de cargas de aplicaciones, usa varios NEG balanceados por carga. Coloca un extremo de VM en un NEG único compatible con cada tipo de balanceador de cargas. Luego, asocia cada NEG con el servicio de backend del balanceador de cargas correspondiente.

• No agregues un grupo de instancias administrado con ajuste de escala automático a más de un servicio de backend cuando uses la métrica de ajuste de escala automático Uso del balanceo de cargas de HTTP. Dos o más servicios de backend que hacen referencia al mismo grupo de instancias administrado con ajuste de escala automático pueden contradecirse entre sí, a menos que la métrica de ajuste de escala automático no esté relacionada con la actividad del balanceador de cargas.

Grupos de extremos de red zonales

Los extremos de red representan servicios por su dirección IP o 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 extremos de red (NEG) es una agrupación lógica de extremos de red.

Los NEG zonales son recursos zonales que representan colecciones de direcciones IP o combinaciones de direcciones IP y puertos para recursos deGoogle Cloud dentro de una sola subred.

Los servicios de backend que usan NEG zonales como backends distribuyen el tráfico entre las aplicaciones o los contenedores que se ejecutan dentro de las VM.

Existen dos tipos de extremos de red disponibles para los NEG zonales:

• Extremos GCE_VM_IP (compatibles solo con balanceadores de cargas de red de transferencia internos y balanceadores de cargas de red de transferencia externos basados en servicios de backend).
• Extremos de GCE_VM_IP_PORT.

Para ver qué productos admiten backends de NEG zonales, consulta Tabla: Servicios de backend y tipos de backends compatibles.

Para obtener más detalles, consulta la Descripción general de los NEG zonales.

Grupos de extremos de red de Internet

Los NEGs de Internet son recursos globales que definen backends externos. Un backend externo es un backend alojado en la infraestructura local o en la 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. Existen dos tipos de extremos de red disponibles para los NEGs de Internet: INTERNET_FQDN_PORT y INTERNET_IP_PORT.

Los NEGs de Internet están disponibles en dos permisos: global y regional. Para ver qué productos admiten backends de NEG de Internet en cada permiso, consulta Tabla: Servicios de backend y tipos de backend compatibles.

Para obtener más información, consulta Descripción general de los grupos de extremos de red de Internet.

Grupos de extremos de red sin servidores

Un grupo de extremos de red (NEG) especifica un grupo de extremos de backend para un balanceador de cargas. Un NEG sin servidores es un backend que apunta a un recurso de Cloud Run, App Engine, Cloud Run Functions o API Gateway.

Un NEG sin servidores puede representar una de las siguientes opciones:

• 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 2ª gen.).
• Una función de Cloud Run (1ª gen.) o un grupo de funciones
• Una app del entorno estándar de App Engine o del entorno flexible de App Engine, un servicio específico dentro de una app, una versión específica de una app o un grupo de servicios.
• Una API Gateway que proporciona acceso a tus servicios a través de una API de REST coherente en todos los servicios, sin importar la implementación de estos. Esta función se encuentra en vista previa.

Importante: Para que un grupo de recursos esté en el mismo NEG sin servidores, deben tener un patrón de URL común.

A fin de configurar un NEG sin servidores para aplicaciones sin servidores que comparten un patrón de URL, usa una máscara de URL. Una máscara de URL es una plantilla del esquema de URL (por ejemplo, example.com/<service>). El NEG sin servidores 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 coincidente con el mismo nombre.

Para ver qué balanceadores de cargas admiten backends de NEG sin servidores, consulta Tabla: Servicios de backend y tipos de backends compatibles.

Para obtener más información sobre los NEG sin servidores, consulta la descripción general de los grupos de extremos de red sin servidores.

Vinculaciones del servicio

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

Backends mixtos

Las siguientes consideraciones de uso se aplican cuando agregas diferentes tipos de backends a un solo servicio de backend:

• Un solo servicio de backend no puede usar simultáneamente grupos de instancias y NEG zonales.
• Puedes usar una combinación de tipos de grupos de instancias diferentes en el mismo servicio de backend. Por ejemplo, un solo servicio de backend puede hacer referencia a una combinación de grupos de instancias administrados y no administrados. Para obtener información completa sobre la compatibilidad de los backends con los servicios de backend, consulta la tabla de la sección anterior.
• Con ciertos balanceadores de cargas de proxy, puedes usar una combinación de NEG zonales (con extremos GCE_VM_IP_PORT) y NEG de conectividad híbrida (con extremos NON_GCP_PRIVATE_IP_PORT) para configurar el balanceo de cargas híbrido. Para ver qué balanceadores de cargas tienen esta capacidad, consulta Tabla: Servicios de backend y tipos de backend compatibles.

Protocolo para los backends

Cuando creas un servicio de backend, debes especificar el protocolo que se usa para comunicarse con los backends. Puedes especificar solo un protocolo por servicio de backend; no puedes especificar un protocolo secundario para usar como resguardo.

Los protocolos válidos dependen del tipo de balanceador de cargas o de si se usa Cloud Service Mesh.

Tabla: Protocolo para los backends

Producto	Opciones de protocolo del servicio de backend
Balanceador de cargas de aplicaciones	HTTP, HTTPS, HTTP/2
Balanceador de cargas de red del proxy	TCP o SSL Los balanceadores de cargas de red del proxy regional solo admiten TCP.
Balanceador de cargas de red de transferencia	TCP, UDP, o UNSPECIFIED
Cloud Service Mesh	HTTP, HTTPS, HTTP/2, gRPC, TCP

Cuando cambias el protocolo de un servicio de backend, no se puede acceder a los backends a través de los balanceadores de cargas durante unos minutos.

Política de selección de direcciones IP

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

Cuando selecciones la política de selección de dirección IP, asegúrate de que tus backends admitan el tipo de tráfico seleccionado. Para obtener más información, consulta Tabla: Servicios de backend y backends compatibles tipos.

La política de selección de direcciones IP se usa cuando deseas convertir tu servicio de backend del balanceador de cargas para admitir un tipo de tráfico diferente. Para obtener más información, consulta Convierte de pila única a pila doble.

Puedes 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, sin importar el tráfico del cliente al GFE. Solo IPv4 de estado se usan para comprobar el estado de los backends.
Preferir IPv6	Prioriza la conexión IPv6 del backend sobre el Conexión IPv4 (siempre que haya un backend en buen estado con direcciones IPv6). Las verificaciones de estado supervisan de forma periódica las conexiones IPv6 e IPv4 de los backends. GFE primero intenta establecer la conexión IPv6. Si la conexión IPv6 está interrumpida o es lenta, GFE usa visitantes felices para recurrir y conectarse a IPv4. Incluso si una de las conexiones IPv6 o IPv4 está en mal estado, el backend se considera en buen estado, y GFE puede probar ambas conexiones, y los visitantes felices, en última instancia, seleccionan cuál usar.
Solo IPv6	Solo envía tráfico IPv6 a los backends del servicio de backend, sin importar el tráfico del cliente al proxy. Solo IPv6 de estado se usan para comprobar el estado de los backends. No hay validación para verificar si el tipo de tráfico de backend coincide con la política de selección de direcciones IP. Por ejemplo, si tienes backends solo IPv4 y seleccionas Only IPv6 como la política de selección de direcciones IP, la configuración generará backends en mal estado porque el tráfico no llegará a esos backends y se devolverá el código de respuesta HTTP 503 a los clientes.

Encriptación entre el balanceador de cargas y los backends

Para obtener más información sobre la encriptación entre el balanceador de cargas y los backends, consulta Encriptación en los backends.

Modo de balanceo, capacidad de destino y escalador de capacidad

En el caso de los balanceadores de cargas de aplicaciones, Cloud Service Mesh y los balanceadores de cargas de red de proxy, el modo de balanceo, la capacidad objetivo y el factor de ajuste de capacidad son parámetros que proporcionas cuando agregas un backend compatible a un servicio de backend. Los balanceadores de cargas usan estos parámetros para administrar la distribución de solicitudes o conexiones nuevas a las zonas que contienen backends compatibles:

• El modo de balanceo define cómo el balanceador de cargas mide la capacidad. Google Cloud tiene los siguientes modos de balanceo:
  • CONNECTION: Define la capacidad en función de la cantidad de conexiones TCP nuevas.
  • RATE: Define la capacidad en función de la tasa de solicitudes HTTP nuevas.
  • IN-FLIGHT (Versión preliminar): Define la capacidad en función de la cantidad de solicitudes HTTP en curso en lugar de la tasa de solicitudes HTTP. Usa este modo de balanceo en lugar de RATE si las solicitudes tardan más de un segundo en completarse.
  • UTILIZATION: Define la capacidad en función del uso aproximado de CPU de las VMs en una zona de un grupo de instancias.
  • CUSTOM_METRICS: Define la capacidad en función de las métricas personalizadas definidas por el usuario.
• La capacidad objetivo define la cantidad de capacidad objetivo.
  • La capacidad de destino no es un disyuntor.
  • Cuando el uso de la capacidad alcanza la capacidad objetivo, el balanceador de cargas dirige las solicitudes o conexiones nuevas a una zona diferente si los backends están configurados en dos o más zonas.
  • Los balanceadores de cargas de aplicaciones externos globales, los balanceadores de cargas de red de proxy externos globales, los balanceadores de cargas de aplicaciones internos entre regiones y los balanceadores de cargas de red de proxy internos entre regiones también usan capacidad para dirigir solicitudes a zonas en diferentes regiones, si configuraste backends en más de una región.
  • Cuando todas las zonas alcanzan la capacidad objetivo, las solicitudes o conexiones nuevas se distribuyen por sobrecarga de forma proporcional.
• El escalador de capacidad proporciona una forma de escalar la capacidad de destino de forma manual. Los valores del escalador de capacidad son los siguientes:
  • 0: Indica que el backend se desvió por completo. No puedes usar un valor de 0 si un servicio de backend solo tiene un backend.
  • 0.1 (10%) - 1.0 (100%): Indica el porcentaje de capacidad del backend que se está usando.

Los balanceadores de cargas de red de transferencia usan simbólicamente el modo de balanceo CONNECTION, pero no admiten una capacidad de destino ni un escalador de capacidad. Para obtener más información sobre cómo los balanceadores de cargas de red de transferencia distribuyen las conexiones nuevas, consulta lo siguiente:

• Distribución del tráfico en los balanceadores de cargas de red de transferencia internos
• Distribución del tráfico en los balanceadores de cargas de red de transferencia externos

Backends compatibles

En el caso de los balanceadores de cargas de aplicaciones, Cloud Service Mesh y los balanceadores de cargas de red de proxy, los siguientes tipos de backends admiten los parámetros del modo de balanceo, la capacidad objetivo y el factor de ajuste de capacidad:

• Backends de grupos de instancias
• NEG zonales con extremos GCE_VM_IP_PORT
• NEGs de conectividad híbrida zonal

Los parámetros de modo de balanceo, capacidad objetivo y factor de ajuste de capacidad no son compatibles con los NEG de Internet, los NEG sin servidores ni los NEG de Private Service Connect.

Modos de balanceo para balanceadores de cargas de aplicaciones y Cloud Service Mesh

Los modos de balanceo disponibles para los backends del balanceador de cargas de aplicaciones y de Cloud Service Mesh dependen del tipo de backend compatible y de un parámetro de configuración de duración del tráfico (vista previa).

Parámetro de configuración de la duración del tráfico

Versión preliminar

Este producto o función está con sujeción a las "Condiciones de las Ofertas de la Fase Previa a la DG" de la sección de Términos Generales del Servicio de los Términos Específicos del Servicio. Los productos y las funciones de la fase previa a la DG están disponibles sin modificaciones y pueden estar sujetos a asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

En el caso de los backends del balanceador de cargas de aplicaciones y de Cloud Service Mesh, puedes especificar de forma opcional un parámetro de configuración de duración del tráfico. Este parámetro de configuración es único para la asignación entre un backend compatible y un servicio de backend. El parámetro de configuración de duración del tráfico tiene dos valores válidos:

• SHORT: Se recomienda para las solicitudes HTTP que se responden con respuestas de backends en menos de un segundo. Si no especificas explícitamente una duración del tráfico, el balanceador de cargas funcionará como si hubieras especificado SHORT.
• LONG: Se recomienda para las solicitudes HTTP en las que el backend necesita más de un segundo para generar respuestas.

Para establecer de forma explícita la duración del tráfico cuando agregas un backend a un servicio de backend, haz una de las siguientes acciones:

• Ejecuta el comando gcloud compute backend-services add-backend con la marca --traffic-duration.
• Crea o actualiza un servicio de backend con el atributo trafficDuration.

Modos de balanceo para la duración corta del tráfico

Cuando no se especifica el parámetro de configuración de duración del tráfico o se establece en SHORT(versión preliminar), los modos de balanceo disponibles para los backends del balanceador de cargas de aplicaciones y de Cloud Service Mesh dependen del tipo de backend compatible.

Tabla: Modos de balanceo para los backends del balanceador de cargas de aplicaciones y de Cloud Service Mesh que usan el parámetro de configuración de duración del tráfico corta

Backend compatible	Modo de balanceo
	CONNECTION	RATE	IN_FLIGHT	UTILIZATION	CUSTOM_METRICS
Grupos de instancias
NEG zonales con extremos GCE_VM_IP_PORT
NEG de conectividad híbrida zonal

Modos de balanceo para la duración del tráfico prolongada

Versión preliminar

Este producto o función está con sujeción a las "Condiciones de las Ofertas de la Fase Previa a la DG" de la sección de Términos Generales del Servicio de los Términos Específicos del Servicio. Los productos y las funciones de la fase previa a la DG están disponibles sin modificaciones y pueden estar sujetos a asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Cuando el parámetro de configuración de duración del tráfico es LONG, los modos de balanceo disponibles para los backends del balanceador de cargas de aplicaciones y de Cloud Service Mesh dependen del tipo de backend compatible.

Tabla: Modos de balanceo para los backends del balanceador de cargas de aplicaciones y de Cloud Service Mesh que usan el parámetro de configuración de duración del tráfico prolongada

Backend compatible	Modo de balanceo
	CONNECTION	RATE	IN_FLIGHT	UTILIZATION	CUSTOM_METRICS
Grupos de instancias
NEG zonales con extremos GCE_VM_IP_PORT
NEG de conectividad híbrida zonal

Modos de balanceo para los balanceadores de cargas de red del proxy

Los modos de balanceo disponibles para los backends del balanceador de cargas de red del proxy dependen del tipo de backend compatible.

Tabla: Modos de balanceo para los balanceadores de cargas de red de proxy

Backend compatible	Modo de balanceo
	CONNECTION	RATE	IN_FLIGHT	UTILIZATION	CUSTOM_METRICS
Grupos de instancias
NEG zonales con extremos GCE_VM_IP_PORT
NEG de conectividad híbrida zonal

Especificaciones de la capacidad objetivo

Las especificaciones de capacidad objetivo son relevantes para los backends de balanceadores de cargas de aplicaciones, Cloud Service Mesh y balanceadores de cargas de red de proxy que admiten la configuración de modo de balanceo, capacidad objetivo y escalador de capacidad.

Las especificaciones de capacidad objetivo no son relevantes para los balanceadores de cargas de red de transferencia.

Modo de balanceo de conexiones

Los backends del balanceador de cargas de red del proxy pueden usar el modo de balanceo CONNECTION con uno de los siguientes parámetros de capacidad objetivo obligatorios:

Parámetros de capacidad objetivo para el modo de balanceo CONNECTION

Parámetro de capacidad objetivo	Backend compatible
	Grupos de instancias zonales (administrados o no administrados)	Grupos de instancias administrados regionales	NEG zonales con extremos GCE_VM_IP_PORT	NEG de conectividad híbrida zonal
max-connections Conexiones TCP de destino por zona de backend
max-connections-per-instance Conexiones TCP objetivo por instancia de VM. Cloud Load Balancing usa este parámetro para calcular las conexiones TCP de destino por zona de backend.
max-connections-per-endpoint Conexiones TCP de destino por extremo de NEG. Cloud Load Balancing usa este parámetro para calcular las conexiones TCP de destino por zona de backend.

Cómo usar el parámetro max-connections

Cuando especificas el parámetro max-connections, el valor que proporcionas define la capacidad de toda una zona.

• Para un grupo de instancias zonal con N instancias totales y h instancias en buen estado (donde h ≤ N), los cálculos son los siguientes:

  • Si estableces max-connections en X, la capacidad objetivo zonal es X.
  • El promedio de conexiones por instancia es de X / h.

• Los grupos de instancias administrados regionales no admiten el parámetro max-connections porque constan de varias zonas. En su lugar, usa el parámetro max-connections-per-instance.

• Para un NEG zonal con N extremos totales y h extremos en buen estado (donde h ≤ N), los cálculos son los siguientes:

  • Si estableces max-connections en X, la capacidad objetivo zonal es X.
  • El promedio de conexiones por extremo es X / h.

Usa el parámetro max-connections-per-instance o max-connections-per-endpoint

Cuando especificas el parámetro max-connections-per-instance o max-connections-per-endpoint, el balanceador de cargas usa el valor que proporcionas para calcular una capacidad por zona:

• Para un grupo de instancias zonal con N instancias totales y h instancias en buen estado (donde h ≤ N), los cálculos son los siguientes:

  • Si configuras max-connections-per-instance como X, la capacidad objetivo zonal es N * X. Esto equivale a establecer max-connections en N * X.
  • El promedio de conexiones por instancia es de (N * X) / h.

• En el caso de un grupo de instancias administrado regional, si configuras max-connections-per-instance como X, Google Cloud calcula una capacidad objetivo por zona para cada zona del grupo de instancias. En cada zona, si hay K instancias en total y h instancias en buen estado (donde h ≤ K), los cálculos son los siguientes:

  • La capacidad objetivo de la zona es K * X.
  • La cantidad promedio de conexiones por instancia en la zona es (K * X) / h.

• Para un NEG zonal con N extremos totales y h extremos en buen estado (donde h ≤ N), los cálculos son los siguientes:

  • Si configuras max-connections-per-endpoint como X, la capacidad objetivo zonal es N * X. Esto equivale a establecer max-connections en N * X.
  • El promedio de conexiones por extremo es (N * X) / h.

Modo de balanceo de tarifas

Los backends del balanceador de cargas de aplicaciones y de Cloud Service Mesh con un parámetro de configuración de duración del tráfico no especificado o corto (versión preliminar) pueden usar el modo de balanceo RATE con uno de los siguientes parámetros de capacidad objetivo obligatorios:

Tabla: Parámetros de capacidad objetivo para el modo de balanceo RATE

Parámetro de capacidad objetivo	Backend compatible
	Grupos de instancias zonales (administrados o no administrados)	Grupos de instancias administrados regionales	NEG zonales con extremos GCE_VM_IP_PORT	NEG de conectividad híbrida zonal
max-rate Tasa de solicitudes HTTP objetivo por zona de backend
max-rate-per-instance Es la tasa de solicitudes HTTP objetivo por instancia de VM. Cloud Load Balancing usa este parámetro para calcular la tasa de solicitudes HTTP objetivo por zona de backend.
max-rate-per-endpoint Es la tasa de solicitudes HTTP objetivo por extremo del NEG. Cloud Load Balancing usa este parámetro para calcular la tasa de solicitudes HTTP objetivo por zona de backend.

Cómo usar el parámetro max-rate

Cuando especificas el parámetro max-rate, el valor que proporcionas define la capacidad de toda una zona.

• Para un grupo de instancias zonal con N instancias totales y h instancias en buen estado (donde h ≤ N), los cálculos son los siguientes:

  • Si configuras max-rate como X, la capacidad objetivo zonal es de X solicitudes por segundo.
  • El promedio de solicitudes por segundo por instancia es X / h.

• Los grupos de instancias administrados regionales no admiten el parámetro max-rate porque constan de varias zonas. En su lugar, usa el parámetro max-rate-per-instance.

• Para un NEG zonal con N extremos totales y h extremos en buen estado (donde h ≤ N), los cálculos son los siguientes:

  • Si configuras max-rate como X, la capacidad objetivo zonal es de X solicitudes por segundo.
  • El promedio de solicitudes por segundo por extremo es X / h.

Usa el parámetro max-rate-per-instance o max-rate-per-endpoint

Cuando especificas el parámetro max-rate-per-instance o max-rate-per-endpoint, el balanceador de cargas usa el valor que proporcionas para calcular la capacidad por zona:

• Para un grupo de instancias zonal con N instancias totales y h instancias en buen estado (donde h ≤ N), los cálculos son los siguientes:

  • Si configuras max-rate-per-instance como X, la capacidad objetivo zonal es de N * X solicitudes por segundo. Esto equivale a establecer max-rate en N * X.
  • El promedio de solicitudes por segundo por instancia es (N * X) / h.

• En el caso de un grupo de instancias administrado regional, si configuras max-rate-per-instance como X, Google Cloud calcula una capacidad objetivo por zona para cada zona del grupo de instancias. En cada zona, si hay K instancias totales y h instancias en buen estado (donde h≤ K), los cálculos son los siguientes:

  • La capacidad objetivo de la zona es de K * X solicitudes por segundo.
  • El promedio de solicitudes por segundo por instancia en la zona es (K * X) / h.

• Para un NEG zonal con N extremos totales y h extremos en buen estado (donde h ≤ N), los cálculos son los siguientes:

  • Si configuras max-rate-per-endpoint como X, la capacidad objetivo zonal es de N * X solicitudes por segundo. Esto equivale a establecer max-rate en N * X.
  • El promedio de solicitudes por segundo por extremo es (N * X) / h.

Modo de balanceo durante el vuelo

Versión preliminar

Este producto o función está con sujeción a las "Condiciones de las Ofertas de la Fase Previa a la DG" de la sección de Términos Generales del Servicio de los Términos Específicos del Servicio. Los productos y las funciones de la fase previa a la DG están disponibles sin modificaciones y pueden estar sujetos a asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Los backends del balanceador de cargas de aplicaciones y de Cloud Service Mesh con un parámetro de configuración de duración del tráfico prolongado pueden usar el modo de balanceo IN_FLIGHT con uno de los siguientes parámetros obligatorios de capacidad objetivo:

Tabla: Parámetros de capacidad objetivo para el modo de balanceo IN_FLIGHT

Parámetro de capacidad objetivo	Backend compatible
	Grupos de instancias zonales (administrados o no administrados)	Grupos de instancias administrados regionales	NEG zonales con extremos GCE_VM_IP_PORT	NEG de conectividad híbrida zonal
max-in-flight-requests Cantidad objetivo de solicitudes HTTP en curso por zona de backend
max-in-flight-requests-per-instance Es la cantidad objetivo de solicitudes HTTP en curso por instancia de VM. Cloud Load Balancing usa este parámetro para calcular la cantidad objetivo de solicitudes HTTP en curso por zona de backend.
max-in-flight-requests-per-endpoint Es la cantidad objetivo de solicitudes HTTP en curso por extremo del NEG. El balanceo de cargas usa este parámetro para calcular la cantidad objetivo de solicitudes HTTP en curso por zona de backend.

Cómo usar el parámetro max-in-flight-requests

Cuando especificas el parámetro max-in-flight-requests, el valor que proporcionas define la capacidad de toda una zona.

• Para un grupo de instancias zonal con N instancias totales y h instancias en buen estado (donde h ≤ N), los cálculos son los siguientes:

  • Si configuras max-in-flight-requests como X, la capacidad objetivo zonal será de X solicitudes HTTP en curso.
  • La cantidad promedio de solicitudes HTTP en curso por instancia es X / h.

• Los grupos de instancias administrados regionales no admiten el parámetro max-in-flight-requests porque constan de varias zonas. En su lugar, usa el parámetro max-in-flight-requests-per-instance.

• Para un NEG zonal con N extremos totales y h extremos en buen estado (donde h ≤ N), los cálculos son los siguientes:

  • Si configuras max-in-flight-requests como X, la capacidad objetivo zonal será de X solicitudes HTTP en curso.
  • La cantidad promedio de solicitudes HTTP en curso por extremo es X / h.

Usa los parámetros max-in-flight-requests-per-instance o max-in-flight-requests-per-endpoint

Cuando especificas el parámetro max-in-flight-requests-per-instance o max-in-flight-requests-per-endpoint, el balanceador de cargas usa el valor que proporcionas para calcular la capacidad por zona:

• Para un grupo de instancias zonal con N instancias totales y h instancias en buen estado (donde h ≤ N), los cálculos son los siguientes:

  • Si configuras max-in-flight-requests-per-instance como X, la capacidad objetivo zonal es de N * X solicitudes HTTP en curso. Esto equivale a configurar max-in-flight-requests en N * X.
  • El promedio de solicitudes HTTP en curso por instancia es de (N * X) / h.

• En el caso de un grupo de instancias administrado regional, si configuras max-in-flight-requests-per-instance como X, Google Cloud calcula una capacidad objetivo por zona para cada zona del grupo de instancias. En cada zona, si hay K instancias en total y h instancias en buen estado (donde h ≤ K), los cálculos son los siguientes:

  • La capacidad objetivo de la zona es de K * X solicitudes HTTP en curso.
  • El promedio de solicitudes HTTP en curso por instancia en la zona es (K * X) / h.

• Para un NEG zonal con N extremos totales y h extremos en buen estado (donde h ≤ N), los cálculos son los siguientes:

  • Si configuras max-in-flight-requests-per-endpoint como X, la capacidad objetivo zonal es de N * X solicitudes HTTP en curso. Esto equivale a configurar max-in-flight-requests en N * X.
  • El promedio de solicitudes HTTP en curso por extremo es (N * X) / h.

Modo de balanceo de uso

Los backends de grupos de instancias del balanceador de cargas de aplicaciones, Cloud Service Mesh y el balanceador de cargas de red de proxy pueden usar el modo de balanceo UTILIZATION. Los backends de NEG no admiten este modo de balanceo.

El modo de balanceo UTILIZATION depende del uso de CPU de la VM, además de otros factores. Cuando estos factores fluctúan, el balanceador de cargas podría calcular la utilización de una manera que haga que algunas VMs reciban más solicitudes o conexiones que otras. Por lo tanto, ten en cuenta lo siguiente:

• Solo usa el modo de balanceo UTILIZATION con la afinidad de sesión establecida en NONE. Si tu servicio de backend usa una afinidad de sesión diferente de NONE, usa los modos de balanceo RATE, IN-FLIGHT o CONNECTION.

• Si el uso promedio de las VMs en todos los grupos de instancias es inferior al 10%, algunos balanceadores de cargas prefieren distribuir las solicitudes o conexiones nuevas a zonas específicas. Esta preferencia zonal se vuelve menos frecuente cuando aumenta la cantidad de solicitudes o de conexiones.

El modo de balanceo UTILIZATION no tiene un parámetro de configuración de capacidad de destino obligatorio, pero puedes definir una capacidad de destino de forma opcional con uno de los parámetros de capacidad de destino o las combinaciones de parámetros de capacidad de destino que se describen en las siguientes secciones.

Parámetros de capacidad objetivo de utilización para backends de balanceadores de cargas de aplicaciones y Cloud Service Mesh con un parámetro de configuración de duración del tráfico no especificado o breve

Los backends de Application Load Balancer y Cloud Service Mesh con un parámetro de configuración de duración del tráfico no especificado o corto (vista previa) pueden usar el modo de balanceo UTILIZATION con uno de los siguientes parámetros de capacidad objetivo o combinaciones de parámetros:

Tabla: Parámetros y combinaciones de parámetros de capacidad objetivo del modo de balanceo UTILIZATION para los backends del balanceador de cargas de aplicaciones y de Cloud Service Mesh con un parámetro de configuración de duración del tráfico no especificado o breve

Parámetro de capacidad objetivo o combinación de parámetros	Backend compatible
	Grupos de instancias zonales (administrados o no administrados)	Grupos de instancias administrados regionales	NEG zonales con extremos GCE_VM_IP_PORT	NEG de conectividad híbrida zonal
max-utilization Utilización objetivo por zona de backend
max-rate Tasa de solicitudes HTTP objetivo por zona de backend
max-rate y max-utilization El destino es el primero al que se llega en la zona de backend: Utilización objetivo de la zona Tasa de solicitudes HTTP objetivo de la zona
max-rate-per-instance Es la tasa de solicitudes HTTP objetivo por instancia de VM. Cloud Load Balancing usa este parámetro para calcular la tasa de solicitudes HTTP objetivo por zona de backend.
max-rate-per-instance y max-utilization El objetivo es el primero en alcanzarse en la zona de backend: Utilización objetivo de la zona Tasa de solicitudes HTTP objetivo de la zona (se calcula a partir de la tasa de solicitudes HTTP objetivo por instancia de VM de las VMs en la zona)

Para obtener más información sobre los parámetros de capacidad objetivo max-rate y max-rate-per-instance, consulta Modo de balanceo de la tasa en este documento.

Parámetros de capacidad objetivo de utilización para backends de balanceadores de cargas de aplicaciones y Cloud Service Mesh con un parámetro de configuración de duración del tráfico prolongada

Los backends de los balanceadores de cargas de aplicaciones y de Cloud Service Mesh con un parámetro de configuración de duración del tráfico prolongado (vista previa) pueden usar el modo de balanceo UTILIZATION con uno de los siguientes parámetros de capacidad objetivo o combinaciones de parámetros:

Tabla: Parámetros y combinaciones de parámetros de capacidad objetivo del modo de balanceo UTILIZATION para los backends del balanceador de cargas de aplicaciones y de Cloud Service Mesh con un parámetro de configuración de duración del tráfico prolongada (versión preliminar)

Parámetro de capacidad objetivo o combinación de parámetros	Backend compatible
	Grupos de instancias zonales (administrados o no administrados)	Grupos de instancias administrados regionales	NEG zonales con extremos GCE_VM_IP_PORT	NEG de conectividad híbrida zonal
max-utilization Utilización objetivo por zona de backend
max-in-flight-requests Cantidad objetivo de solicitudes HTTP en curso por zona de backend
max-in-flight-requests y max-utilization El destino es el primero al que se llega en la zona de backend: Utilización objetivo de la zona Cantidad objetivo de solicitudes HTTP en curso de la zona
max-in-flight-requests-per-instance Es la cantidad objetivo de solicitudes HTTP en curso por instancia de VM. Cloud Load Balancing usa este parámetro para calcular la cantidad objetivo de solicitudes HTTP en curso por zona de backend.
max-in-flight-requests-per-instance y max-utilization El objetivo es el primero en alcanzarse en la zona de backend: Utilización objetivo de la zona Cantidad objetivo de solicitudes HTTP en curso de la zona (calculada a partir de la cantidad objetivo de solicitudes HTTP en curso por instancia de VM de las VMs en la zona)

Para obtener más información sobre los parámetros de capacidad objetivo max-in-flight-requests y max-in-flight-requests-per-instance, consulta Modo de balanceo en vuelo en este documento.

Parámetros de capacidad objetivo de utilización para balanceadores de cargas de red de proxy

Los backends de grupos de instancias de los balanceadores de cargas de red de proxy pueden usar el modo de balanceo UTILIZATION con uno de los siguientes parámetros de capacidad objetivo o combinaciones de parámetros.

Tabla: Parámetros y combinaciones de parámetros de capacidad objetivo del modo de balanceo UTILIZATION para los backends del balanceador de cargas de red de proxy

Parámetro de capacidad objetivo o combinación de parámetros	Backend compatible
	Grupos de instancias zonales (administrados o no administrados)	Grupos de instancias administrados regionales	NEG zonales con extremos GCE_VM_IP_PORT	NEG de conectividad híbrida zonal
max-utilization Utilización objetivo por zona de backend
max-connections Conexiones TCP de destino por zona de backend
max-connections y max-utilization El destino es el primero al que se llega en la zona de backend: Utilización objetivo de la zona Conexiones TCP de destino de la zona
max-connections-per-instance Conexiones TCP objetivo por instancia de VM. Cloud Load Balancing usa este parámetro para calcular las conexiones TCP de destino por zona de backend.
max-connections-per-instance y max-utilization El objetivo es el primero en alcanzarse en la zona de backend: Utilización objetivo de la zona Conexiones TCP objetivo de la zona (calculadas a partir de las conexiones TCP objetivo por instancia de VM de las VMs en la zona)

Para obtener más información sobre los parámetros de capacidad objetivo max-connections y max-connections-per-instance, consulta Modo de balanceo de conexiones en este documento.

Modo de balanceo de métricas personalizadas

Los backends de los balanceadores de cargas de aplicaciones y los balanceadores de cargas de red de proxy pueden usar el modo de balanceo CUSTOM_METRICS. Las métricas personalizadas te permiten definir la capacidad objetivo en función de los datos de la aplicación o la infraestructura que son más importantes para ti. Para obtener más información, consulta Métricas personalizadas para balanceadores de cargas de aplicaciones.

El modo de balanceo CUSTOM_METRICS no tiene un parámetro de configuración de capacidad de destino obligatorio, pero puedes definir una capacidad de destino de forma opcional con uno de los parámetros de capacidad de destino o las combinaciones de parámetros de capacidad de destino que se describen en las siguientes secciones.

Parámetros de capacidad objetivo de métricas personalizadas para backends de balanceadores de cargas de aplicaciones con un parámetro de configuración de duración del tráfico no especificado o corto

Los backends del balanceador de cargas de aplicaciones con un parámetro de configuración de duración del tráfico no especificado o corto (versión preliminar) pueden usar el modo de balanceo CUSTOM_METRICS con uno de los siguientes parámetros de capacidad objetivo o combinaciones de parámetros:

Tabla: Parámetros de capacidad objetivo del modo de balanceo CUSTOM_METRICS y combinaciones de parámetros para los backends del balanceador de cargas de aplicaciones con un parámetro de configuración de duración del tráfico no especificado o corto

Parámetro de capacidad objetivo o combinación de parámetros	Backend compatible
	Grupos de instancias zonales (administrados o no administrados)	Grupos de instancias administrados regionales	NEG zonales con extremos GCE_VM_IP_PORT	NEG de conectividad híbrida zonal
backends[].customMetrics[].maxUtilization Uso de métricas personalizadas objetivo por zona de backend
max-rate Tasa de solicitudes HTTP objetivo por zona de backend
max-rate y backends[].customMetrics[].maxUtilization El objetivo es el primero en alcanzarse en la zona de backend: Utilización de la métrica personalizada objetivo de la zona Tasa de solicitudes HTTP objetivo de la zona
max-rate-per-instance Es la tasa de solicitudes HTTP objetivo por instancia de VM. Cloud Load Balancing usa este parámetro para calcular la tasa de solicitudes HTTP objetivo por zona de backend.
max-rate-per-instance y backends[].customMetrics[].maxUtilization El objetivo es el primero en alcanzarse en la zona de backend: Utilización de la métrica personalizada objetivo de la zona Tasa de solicitudes HTTP objetivo de la zona (se calcula a partir de la tasa de solicitudes HTTP objetivo por instancia de VM de las VMs en la zona)
max-rate-per-endpoint Es la tasa de solicitudes HTTP objetivo por extremo del NEG. Cloud Load Balancing usa este parámetro para calcular la tasa de solicitudes HTTP objetivo por zona de backend.
max-rate-per-endpoint y backends[].customMetrics[].maxUtilization El objetivo es el primero en alcanzarse en la zona de backend: Utilización de la métrica personalizada objetivo de la zona Tasa de solicitudes HTTP objetivo de la zona (calculada a partir de la tasa de solicitudes HTTP objetivo por extremo del NEG de los extremos en la zona)

Para obtener más información sobre los parámetros de capacidad objetivo max-rate, max-rate-per-instance y max-rate-per-endpoint, consulta Modo de balanceo RATE en este documento.

Parámetros de capacidad objetivo de métricas personalizadas para backends de balanceadores de cargas de aplicaciones con un parámetro de configuración de duración del tráfico prolongada

Los backends del balanceador de cargas de aplicaciones con un parámetro de configuración de duración del tráfico prolongado pueden usar el modo de balanceo CUSTOM_METRICS con uno de los siguientes parámetros de capacidad de destino o combinaciones de parámetros:

Tabla: Parámetros de capacidad objetivo del modo de balanceo CUSTOM_METRICS y combinaciones de parámetros para los backends del balanceador de cargas de aplicaciones con un parámetro de configuración de duración del tráfico prolongada (versión preliminar)

Parámetro de capacidad objetivo o combinación de parámetros	Backend compatible
	Grupos de instancias zonales (administrados o no administrados)	Grupos de instancias administrados regionales	NEG zonales con extremos GCE_VM_IP_PORT	NEG de conectividad híbrida zonal
backends[].customMetrics[].maxUtilization Uso de métricas personalizadas objetivo por zona de backend
max-in-flight-requests Cantidad objetivo de solicitudes HTTP en curso por zona de backend
max-in-flight-requests y backends[].customMetrics[].maxUtilization El objetivo es el primero en alcanzarse en la zona de backend: Utilización de la métrica personalizada objetivo de la zona Cantidad objetivo de solicitudes HTTP en curso de la zona
max-in-flight-requests-per-instance Es la cantidad objetivo de solicitudes HTTP en curso por instancia de VM. Cloud Load Balancing usa este parámetro para calcular la cantidad objetivo de solicitudes HTTP en curso por zona de backend.
max-in-flight-requests-per-instance y backends[].customMetrics[].maxUtilization El objetivo es el primero en alcanzarse en la zona de backend: Utilización de la métrica personalizada objetivo de la zona Cantidad objetivo de solicitudes HTTP en curso de la zona (calculada a partir de la cantidad objetivo de solicitudes HTTP en curso por instancia de VM de las VMs en la zona)
max-in-flight-requests-per-endpoint Es la cantidad objetivo de solicitudes HTTP en curso por extremo del NEG. El balanceo de cargas usa este parámetro para calcular la cantidad objetivo de solicitudes HTTP en curso por zona de backend.
max-in-flight-requests-per-endpoint y backends[].customMetrics[].maxUtilization El objetivo es el primero en alcanzarse en la zona de backend: Utilización de la métrica personalizada objetivo de la zona Cantidad objetivo de solicitudes HTTP en curso de la zona (calculada a partir de la cantidad objetivo de solicitudes HTTP en curso por extremo del NEG de los extremos en la zona)

Para obtener más información sobre los parámetros de capacidad objetivo max-in-flight-requests, max-in-flight-requests-per-instance y max-flight-requests-per-endpoint, consulta el modo de balanceo en vuelo.

Política de balanceo de cargas de servicios

Una política de balanceo de cargas de servicio (serviceLbPolicy) es un recurso asociado con el servicio de backend del balanceador de cargas. Te permite personalizar los parámetros que influyen en cómo se distribuye el tráfico dentro de los backends asociados con un servicio de backend:

• Personaliza el algoritmo de balanceo de cargas que se usa para determinar cómo se distribuye el tráfico entre regiones o zonas
• Habilita el vaciado de capacidad automática para que el balanceador de cargas pueda vaciar rápidamente el tráfico de los backends en mal estado.

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

Para obtener más información, consulta Optimizaciones avanzadas del balanceo de cargas.

Política de balanceo de cargas de la localidad

Para un servicio de backend, la distribución del tráfico se basa en un modo de balanceo y una política de localidad del balanceo de cargas. El modo de balanceo determina la fracción del tráfico que se debe enviar a cada backend (grupo de instancias o NEG ). Luego, la política de localidad de balanceo de cargas (LocalityLbPolicy) determina cómo se distribuye el tráfico entre las instancias o los extremos dentro de cada zona. En los grupos de instancias administrados regionales, la política de localidad se aplica a cada zona constituyente.

La política de localidad de balanceo de cargas se configura por servicio de backend. Podrás configurar los siguientes parámetros:

• ROUND_ROBIN (predeterminado): Es la configuración predeterminada de la política de localidad de balanceo de cargas en la que el balanceador de cargas selecciona un backend en buen estado en orden de reparto de turnos.

• WEIGHTED_ROUND_ROBIN: El balanceador de cargas usa métricas personalizadas definidas por el usuario para seleccionar la instancia o el extremo óptimos dentro del backend para entregar la solicitud.

• LEAST_REQUEST: Un algoritmo O(1) en el que el balanceador de cargas selecciona dos hosts en buen estado aleatorios y elige el host que tiene menos solicitudes activas.

• RING_HASH: Este algoritmo implementa un hash coherente en los backends. El algoritmo tiene la propiedad de que la adición o eliminación de un host de un conjunto de hosts N solo afecta a 1/N de las solicitudes.

• RANDOM: El balanceador de cargas selecciona un host en buen estado de forma aleatoria.

• ORIGINAL_DESTINATION: El balanceador de cargas selecciona un backend según 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 redirecciona al balanceador de cargas.

  ORIGINAL_DESTINATION no es compatible con los balanceadores de cargas de aplicaciones externos regionales ni globales.

• MAGLEV: Implementa un hash coherente en los backends y se puede usar como reemplazo de la política RING_HASH. Maglev no es tan estable como RING_HASH, pero tiene tiempos de compilación de búsqueda de tabla y tiempos de selección de host más rápidos. Para obtener más información sobre Maglev, consulta el documento informativo de Maglev.

• WEIGHTED_MAGLEV: Implementa el balanceo de cargas ponderado por instancia mediante las ponderaciones que informan las verificaciones de estado. Si se usa esta política, el servicio de backend debe configurar una verificación de estado no heredada basada en HTTP, y se espera que las respuestas de la verificación de estado contengan el campo de encabezado de respuesta HTTP no estándar, X-Load-Balancing-Endpoint-Weight, para especificar las ponderaciones por instancia. Las decisiones de equilibrio de carga se toman en función de las ponderaciones por instancia que se informan en las últimas respuestas de la verificación de estado procesadas, siempre y cuando cada instancia informe una ponderación válida o UNAVAILABLE_WEIGHT. De lo contrario, el balanceo de cargas seguirá teniendo el mismo peso.

  WEIGHTED_MAGLEV solo es compatible con los balanceadores de cargas de red de transferencia externos. Para ver un ejemplo, consulta Configura el balanceo de cargas ponderado para los balanceadores de cargas de red de transferencia externos.

La configuración de una política de localidad de balanceo de cargas solo es compatible con los servicios de backend que se usan con los siguientes balanceadores de cargas:

• Balanceador de cargas de aplicaciones externo global
• Balanceador de cargas de aplicaciones externo regional
• Balanceador de cargas de aplicaciones interno entre regiones
• Balanceador de cargas de aplicaciones interno regional
• Balanceador de cargas de red del proxy externo global
• Balanceador de cargas de red del proxy externo regional
• Balanceador de cargas de red del proxy interno entre regiones
• Balanceador de cargas de red del proxy interno regional
• Balanceador de cargas de red de transferencia externo

Ten en cuenta que el valor predeterminado efectivo de la política de localidad del balanceo de cargas (localityLbPolicy) cambia según la configuración de afinidad de sesión. Si la afinidad de sesión no está configurada, es decir, si permanece en el valor predeterminado de NONE, el valor predeterminado para localityLbPolicy es ROUND_ROBIN. Si la afinidad de sesión se establece en un valor distinto de NONE, el valor predeterminado para localityLbPolicy es MAGLEV.

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

Subconjuntos de backend

La subdivisión de backends es una función opcional que mejora el rendimiento y la escalabilidad mediante la asignación de un subconjunto de backends a cada una de las instancias de proxy.

La subdivisión de backends es compatible con lo siguiente:

• Balanceador de cargas de aplicaciones interno regional
• Balanceador de cargas de red de transferencia interno

Subconjuntos de backends para balanceadores de cargas de aplicaciones internos regionales

Versión preliminar

Este producto o función está con sujeción a las "Condiciones de las Ofertas de la Fase Previa a la DG" de la sección de Términos Generales del Servicio de los Términos Específicos del Servicio. Los productos y las funciones de la fase previa a la DG están disponibles sin modificaciones y pueden estar sujetos a asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

El balanceador de cargas de aplicaciones interno entre regiones no admite la subdivisión de backends.

Para los balanceadores de cargas de aplicaciones internos regionales, la subdivisión de backends asigna automáticamente solo una subdivisión de los backends dentro del servicio de backend regional a cada instancia de proxy. De forma predeterminada, cada instancia de proxy abre conexiones con todos los backends dentro de un servicio de backend. Cuando la cantidad de instancias de proxy y los backends son conexiones grandes de apertura a todos los backends, puede haber problemas de rendimiento.

Mediante la habilitación del subconjunto, cada proxy solo abre conexiones a un subconjunto de backends, lo que reduce la cantidad de conexiones que se mantienen abiertas a cada backend. Reducir la cantidad de conexiones abiertas a cada backend puede mejorar el rendimiento de los backends y los proxies.

En el siguiente diagrama, se muestra un balanceador de cargas con dos proxies. Sin la subconfiguración de backend, el tráfico de ambos proxies se distribuye a todos los backends en el servicio de backend 1. Con el subconjunto del backend 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 backends 1 y 2, y el tráfico del proxy 2 se distribuye a los backends 3 y 4.

Compara el balanceador de cargas de aplicaciones interno sin y con subconjuntos de backend (haz clic para ampliar).

Además, puedes definir mejor el tráfico del balanceo de cargas en los backends si configuras la política localityLbPolicy. Para obtener más información, consulta Políticas de tráfico.

Si deseas leer sobre la configuración de los subconjuntos de backends para los balanceadores de cargas de aplicaciones internos, consulta Configura los subconjuntos de backends.

Advertencias relacionadas con los subconjuntos de backends para el balanceador de cargas de aplicaciones interno

• Aunque los subconjuntos de backend están diseñados para garantizar que todas las instancias de backend se mantengan bien usadas, pueden generar sesgos en la cantidad de tráfico que recibe cada backend. Se recomienda configurar localityLbPolicy en LEAST_REQUEST para los servicios de backend sensibles al balanceo de cargas de backend.
• Si se habilita o se inhabilita la subdivisión, se interrumpen las conexiones existentes.
• La subdivisión de backends requiere que la afinidad de sesión sea NONE (un hash de 5 tuplas). Otras opciones de afinidad de sesión solo se pueden usar si la subdivisión de backends está inhabilitada. Los valores predeterminados de las marcas --subsetting-policy y --session-affinity son NONE, y solo uno de ellos a la vez se puede establecer en un valor diferente.

Subconjuntos de backends para el balanceador de cargas de red de transferencia interno

Los subconjuntos de backends para los balanceadores de cargas de red de transferencia internos te permiten escalar tu balanceador de cargas de red de transferencia interno a fin de admitir una mayor cantidad de instancias de VM de backend por servicio de backend interno.

Para obtener información sobre cómo la subdivisión afecta este límite, consulta Servicios de backend en "Cuotas y límites".

De forma predeterminada, la subdivisión está inhabilitada, lo que limita el servicio de backend a una distribución de hasta 250 instancias de backend o extremos. Si tu servicio de backend necesita admitir más de 250 backends, puedes habilitar la subdivisión. Cuando se habilita la subdivisión, 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 operación.

Compara un balanceador de cargas de red de transferencia interno sin y con subconjuntos (haz clic para ampliar)

Sin la subdivisión, el conjunto completo de backends en buen estado se usa mejor, y las conexiones de clientes nuevas se distribuyen entre todos los backends en buen estado según la distribución de tráfico. La subposición impone restricciones de balanceo de cargas, pero permite que el balanceador de cargas admita más de 250 backends.

Para obtener instrucciones de configuración, consulta Subdivisión.

Advertencias relacionadas con los subconjuntos de backends para el balanceador de cargas de red de transferencia interno

• Cuando la subdivisión está habilitada, no todos los backends recibirán tráfico de un remitente determinado, incluso cuando la cantidad de backends sea pequeña.
• Para obtener la cantidad máxima de instancias de backend cuando los subconjuntos están habilitados, consulta la página de cuotas.
• Solo la afinidad de sesión de 5 tuplas es compatible con la subdivisión.
• La duplicación de paquetes no es compatible con la subdivisión.
• Si se habilita o se inhabilita la subdivisión, se interrumpen las conexiones existentes.
• Si los clientes locales necesitan acceder a un balanceador de cargas de red de transferencia interno, los subconjuntos pueden reducir de forma sustancial la cantidad de backends que reciben conexiones de tus clientes locales. Esto se debe a que la región del túnel de Cloud VPN o el adjunto de VLAN de Cloud Interconnect determina el subconjunto de backends del balanceador de cargas. Todos los extremos de Cloud VPN y Cloud Interconnect en una región específica usan el mismo subconjunto. Se usan diferentes subconjuntos en diferentes regiones.

Precios de la división de backend

No se aplican cargos por el uso de división de backend. Para obtener más información, consulta Todos los precios de herramientas de redes.

Afinidad de sesión

La afinidad de sesión te permite controlar cómo el balanceador de cargas selecciona backends para conexiones nuevas de manera predecible, siempre que la cantidad 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 extremo. Estas aplicaciones incluyen servidores con estado que usan la publicación de anuncios, los juegos o los servicios con almacenamiento en caché interno intenso.

Los balanceadores de cargas deGoogle Cloud proporcionan afinidad de sesión en función del mejor esfuerzo. Factores como cambiar los estados de la verificación de estado del backend, agregar o quitar backends, cambios en las ponderaciones del backend (incluida la habilitación o inhabilitación del balanceo ponderado) o cambios en el contenido total del backend, según la medición del modo de balanceo, pueden interrumpir la afinidad de sesión.

El balanceo de cargas con afinidad de sesión funciona bien cuando hay una distribución razonablemente grande de conexiones únicas. Razonablemente grande significa al menos varias veces la cantidad de backends. Probar un balanceador de cargas con una cantidad pequeña de conexiones no dará como resultado una representación precisa de la distribución de las conexiones de cliente entre backends.

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

• Dirección IP de origen del paquete
• El puerto de origen del paquete (si está presente en el encabezado del paquete)
• Dirección IP de destino del paquete
• El 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 para los balanceadores de cargas de red de transferencia, consulta los siguientes documentos:

• Distribución del tráfico para los balanceadores de cargas de red de transferencia externos
• Distribución del tráfico para los balanceadores de cargas de red de transferencia internos

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

• Afinidad de sesión para balanceadores de cargas de aplicaciones externos
• Afinidad de sesión para balanceadores de cargas de aplicaciones internos

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

• Afinidad de sesión para balanceadores de cargas de red del proxy externo
• Afinidad de sesión para balanceadores de cargas de red de proxy interno

Tiempo de espera del servicio de backend

La mayoría de los Google Cloud balanceadores de cargas tienen un tiempo de espera del servicio de backend. El valor predeterminado es 30 segundos. El rango completo de valores de tiempo de espera permitidos es de 1 a 2,147,483,647 segundos.

• Para los balanceadores de cargas de aplicaciones externos y los balanceadores de cargas de aplicaciones internos que usan el protocolo HTTP, HTTPS o HTTP/2, el tiempo de espera del servicio de backend es un tiempo de espera de solicitudes y respuestas para el tráfico HTTP(S).

  A fin de obtener más detalles sobre el tiempo de espera del servicio de backend para cada balanceador de cargas, consulta los siguientes vínculos:

  • Para los balanceadores de cargas de aplicaciones externos globales y los balanceadores de cargas de aplicaciones externos regionales , consulta Tiempos de espera y reintentos.
  • Para los balanceadores de cargas de aplicaciones internos, consulta Tiempos de espera y reintentos.

• Para los balanceadores de cargas de red de proxy externo y los balanceadores de cargas de red de proxy interno, el tiempo de espera configurado del servicio de backend es el período durante el cual el balanceador de cargas mantiene abierta la conexión TCP en ausencia de datos transmitidos desde el cliente o el backend. Una vez que transcurre este tiempo sin que se transmitan datos, el proxy cierra la conexión.

  • Valor predeterminado: 30 segundos
  • Rango configurable: de 1 a 2,147,483,647 segundos

• Para los balanceadores de cargas de red de transferencia internos y los balanceadores de cargas de red de transferencia externos, puedes establecer el valor del tiempo de espera del servicio de backend con gcloud o la API, pero se ignorará el valor. El tiempo de espera del servicio de backend no significa nada para estos balanceadores de cargas de paso.

• Para Cloud Service Mesh, el campo del tiempo de espera del servicio de backend (especificado con timeoutSec) no es compatible con los servicios de gRPC sin proxy. Para esos 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 la cantidad de tiempo que se debe esperar para que un backend muestre una respuesta completa después de enviar la solicitud. El tiempo de espera de gRPC especifica el tiempo que se debe esperar desde el comienzo de la transmisión hasta que la respuesta se haya procesado por completo, incluidos todos los reintentos.

Verificaciones de estado

Cada servicio de backend cuyos backends son grupos de instancias o NEG zonales debe tener una verificación de estado asociada. Los servicios de backend que usan un NEG sin servidores o un NEG de Internet global como backend no deben hacer referencia a una verificación de estado.

Cuando creas un balanceador de cargas con la consola de Google Cloud , puedes crear la verificación de estado, si es necesaria, cuando creas el balanceador de cargas, o puedes hacer referencia a una verificación de estado existente.

Cuando creas un servicio de backend mediante backends de grupo de instancias o de NEG zonales con Google Cloud CLI o la API, debes hacer referencia a una verificación de estado existente. Consulta la guía de balanceadores de cargas en la Descripción general de las verificaciones de estado para obtener detalles sobre el tipo y el alcance de la verificación de estado requerida.

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

• Descripción general de las verificaciones de estado
• Crea verificaciones de estado
• Página de verificación de estado de gcloud
• Página de verificación de estado de la API de REST

Funciones adicionales habilitadas en el recurso de servicio de backend

Los siguientes servicios de backend admiten las siguientes funciones opcionales.

Cloud CDN

Cloud CDN usa la red perimetral global de Google para entregar contenido más cerca de los usuarios, lo que acelera los sitios web y aplicaciones. Cloud CDN está habilitado en los servicios de backend que usan los balanceadores de cargas de aplicaciones externos globales. El balanceador de cargas proporciona las direcciones IP y los puertos de frontend que reciben solicitudes y los backends que responden a esas solicitudes.

Para obtener más detalles, 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 cargas, puedes agregar protección adicional a tus aplicaciones si habilitas Cloud Armor en el servicio de backend durante la creación del balanceador de cargas:

• Balanceador de cargas de aplicaciones externo global
• Balanceador de cargas de aplicaciones clásico
• Balanceador de cargas de red del proxy externo global
• Balanceador de cargas de red del proxy clásico

Si usas la consola de Google Cloud , puedes realizar una de las siguientes acciones:

• Selecciona una política de seguridad de Cloud Armor existente.
• Acepta la configuración de una política de seguridad predeterminada para el límite de frecuencia de Cloud Armor con un nombre, recuento de solicitudes, intervalo, clave y parámetros de límite de frecuencia personalizables. Si usas Cloud Armor con un servicio de proxy ascendente, como un proveedor de CDN, Enforce_on_key debe configurarse como una dirección IP de XFF.
• Si deseas inhabilitar la protección de Cloud Armor, selecciona Ninguna.

IAP

IAP te permite establecer una capa de autorización central para las aplicaciones a las que se accede mediante HTTPS, por lo que puedes usar un modelo de control de acceso a nivel de aplicación en lugar de firewalls a nivel de red. IAP es compatible con ciertos balanceadores de cargas de aplicaciones.

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

Funciones avanzadas de administración del tráfico

Para obtener información sobre las funciones avanzadas de administración de tráfico que se configuran en los servicios de backend y los mapas de URL asociados con los balanceadores de cargas, consulta lo siguiente:

• Descripción general de la administración del tráfico en los balanceadores de cargas de aplicaciones internos
• Descripción general de la administración del tráfico en los balanceadores de cargas de aplicaciones externos globales
• Descripción general de la administración del tráfico en los balanceadores de cargas de aplicaciones externos regionales

API y referencia de gcloud

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

• Recurso de la API del servicio de backend global

• Recurso de la API del servicio de backend regional

• Página de gcloud compute backend-services, para servicios de backend globales y regionales

¿Qué sigue?

Para obtener información y documentación sobre cómo se usan los servicios de backend en el balanceo de cargas, consulta las siguientes páginas:

• Crear encabezados personalizados
• Crea un balanceador de cargas de aplicaciones externo
• Descripción general del balanceador de cargas de aplicaciones externo
• Habilita el vaciado de conexiones
• Encriptación en tránsito en Google Cloud

Para ver videos relacionados, consulta lo siguiente:

• Cómo configurar los servicios de backend para los balanceadores de cargas de aplicaciones externos globales