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 regional.

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.

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

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.

Nombres de los balanceadores de cargas

En el caso de los balanceadores de cargas de red de 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 Trusted Cloud es el siguiente:

• Trusted Cloud console Si creas un balanceador de cargas de red del proxy o un balanceador de cargas de red de transferencia con la consola de Trusted 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 de 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. Luego, este nombre del servicio de backend se refleja en la consola de Trusted 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 Trusted Cloud by S3NSbalanceador de cargas 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 el mismo modo de balanceo.
• NEG zonal
• 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:

• 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.

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 las siguientes restricciones y recomendaciones cuando crees grupos de instancias para los balanceadores de cargas:

• No pongas una VM en más de un grupo de instancias con balanceo de cargas. Si una VM es miembro de dos o más grupos de instancias no administrados, o de un grupo de instancias administrado y de uno o más grupos de instancias no administrados, Trusted Cloudsolo puedes usar uno de esos grupos de instancias a la vez como backend para un servicio de backend en particular.

  Si necesitas una VM para participar en varios balanceadores de cargas, debes usar el mismo grupo de instancias como backend en cada uno de los servicios de backend.

• Para los balanceadores de cargas de proxy, cuando quieras balancear el tráfico en puertos diferentes, especifica los puertos con nombre necesarios en un grupo de instancias y haz que cada servicio de backend se suscriba a un único nombre llamado puerto.

• Puedes usar el mismo grupo de instancias como backend para 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 deben ser una combinación de modos de balanceo compatibles, por ejemplo, CONNECTION y RATE.

  Las combinaciones de modo de balanceo incompatibles son las siguientes:

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

  Considera el siguiente ejemplo:

  • Tienes dos servicios de backend: external-https-backend-service para un balanceador de cargas de aplicaciones externo y internal-tcp-backend-service para un balanceador de cargas de red de transferencia interno.
  • Usas un grupo de instancias llamado instance-group-a en internal-tcp-backend-service.
  • En internal-tcp-backend-service, debes aplicar el modo de balanceo CONNECTION, porque los balanceadores de cargas de red de transferencia internos solo admiten el modo de balanceo CONNECTION.
  • También puedes usar instance-group-a en external-https-backend-service si aplicas el modo de balanceo RATE en external-https-backend-service.
  • No puedes usar instance-group-a en external-https-backend-service con el modo de balanceo UTILIZATION.

• Si deseas cambiar el modo de balanceo de un grupo de instancias que funciona como backend para varios servicios de backend, haz lo siguiente:

  • 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 agregar el grupo de instancias como backend para los servicios de backend restantes, si es que admiten el modo de balanceo nuevo.

• Si el grupo de instancias está asociado con varios servicios de backend, cada servicio de backend puede hacer referencia al mismo puerto con nombre o a un puerto con nombre diferente en el grupo de instancias.

• Recomendamos que no se agregue un grupo de instancias administrado con ajuste de escala automático a más de un servicio de backend. Esto podría causar un escalamiento impredecible e innecesario de las instancias en el grupo, en especial si usas la métrica de ajuste de escala automático del uso del balanceo de cargas de HTTP.

  • Aunque no se recomienda, esta situación podría funcionar si la métrica de ajuste de escala automático es uso de CPU o una métrica de Cloud Monitoring que no está relacionada con la capacidad de entrega del balanceador de cargas. El uso de una de estas métricas de ajuste de escala automático puede evitar el escalamiento errático.

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 grupos de extremos de red por zonas (NEG) son recursos zonales que representan conjuntos de direcciones IP o combinaciones de direcciones IP y puertos para recursos de Trusted Cloud dentro de una única 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.

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

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.

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.

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.

Distribución del tráfico

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

• Un modo de balanceo define cómo el balanceador de cargas mide la preparación de backend para solicitudes o conexiones nuevas.
• Una capacidad de destino define una cantidad máxima de conexiones de destino, una tasa máxima de destino o el uso máximo de CPU de destino.
• Un escalador de capacidad ajusta la capacidad general disponible sin modificar la capacidad de destino.

Modo de balanceo

El modo de balanceo determina si los backends de un balanceador de cargas pueden manejar el tráfico adicional o si están cargados por completo.

Trusted Cloud tiene cuatro modos de balanceo:

• CONNECTION: Determina cómo se distribuye la carga en función de la cantidad total de conexiones que puede controlar el backend.
• RATE: La cantidad máxima de solicitudes (consultas) de destino por segundo (RPS, QPS). Se puede exceder la cantidad máxima de RPS/QPS si se alcanza o supera la capacidad de todos los backends.
• UTILIZATION: Determina cómo se distribuye la carga en función del uso de las instancias en 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 cargas

Debes establecer el modo de balanceo cuando agregas un backend al servicio de backend. Los modos de balanceo disponibles para un balanceador de cargas dependen del tipo de balanceador de cargas y de los backends.

Los balanceadores de cargas de red de transferencia requieren el modo de balanceo CONNECTION, pero no admiten la configuración de ninguna capacidad objetivo.

Los balanceadores de cargas de aplicaciones admiten los modos de balanceo RATE, UTILIZATION o CUSTOM_METRICS para backends de grupo de instancias, y los modos de balanceo RATE o CUSTOM_METRICS para NEG zonales (extremos GCE_VM_IP_PORT) y NEG híbridos (extremos NON_GCP_PRIVATE_IP_PORT). Para cualquier otro tipo de backend compatible, se debe omitir el modo de balanceo.

• Duración balanceadores de cargas de aplicaciones externos regionales y balanceadores de cargas de aplicaciones internos regionales, la capacidad objetivo del modo de balanceo se usa para calcular las proporciones sobre cuántas solicitudes deben ir a cada backend (grupo de instancias o NEG) en la región. Dentro de cada grupo de instancias o NEG, la política de balanceo de cargas (LocalityLbPolicy) determina cómo se distribuye el tráfico en las instancias o extremos del grupo.

Los balanceadores de cargas de red de proxy admiten los modos de balanceo CONNECTION o UTILIZATION para backends de grupo de instancias, el modo de balanceo CONNECTION para NEG zonales con extremos GCE_VM_IP_PORT, y el modo de balanceo CONNECTION para los NEG híbridos (extremos NON_GCP_PRIVATE_IP_PORT). Para cualquier otro tipo de backend compatible, se debe omitir el modo de balanceo.

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

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

Si el uso promedio de todas las VMs asociadas con un servicio de backend es inferior al 10%, Trusted Cloud puede preferir zonas específicas. Esto puede suceder cuando usas grupos de instancias regionales administrados, grupos de instancias administrados zonales en zonas diferentes y grupos de instancias zonales no administrados. Este desequilibrio zonal se resuelve de forma automática a medida que se envía más tráfico al balanceador de cargas.

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

Capacidad de destino

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

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

En cada modo de balanceo, la capacidad de destino no es un disyuntor. Un balanceador de cargas puede exceder el máximo en ciertas condiciones, por ejemplo, si todas las VM o los extremos de backend lo alcanzaron.

Modo de balanceo de conexiones

En el modo de balanceo CONNECTION, la capacidad de destino define una cantidad máxima de destino de conexiones abiertas. Excepto por los balanceadores de cargas de red de transferencia internos y los balanceadores de cargas de red de transferencia externos, debes usar una de las siguientes opciones de configuración para especificar una cantidad máxima de conexiones de destino:

• max-connections-per-instance (por VM): Cantidad promedio de conexiones de destino para una sola VM.
• max-connections-per-endpoint (por extremo en un NEG zonal): Cantidad promedio de conexiones de destino para un solo extremo.
• max-connections (por NEG zonales y para grupos de instancias zonales): Cantidad promedio de conexiones de destino en todo el NEG o grupo de instancias. Para los grupos de instancias administrados regionales, usa max-connections-per-instance en su lugar.

En la siguiente tabla, se muestra cómo el parámetro de capacidad de destino define los siguientes aspectos:

• La capacidad de destino de todo el backend
• La capacidad de destino esperada para cada instancia o extremo

Como se ilustra, la configuración max-connections-per-instance y max-connections-per-endpoint son proxies para calcular una cantidad máxima de conexiones de destino en todo el grupo de instancias de VM o en el NEG zonal completo:

• En un grupo de instancias de VMs con instancias N, configurar max-connections-per-instance=X tiene el mismo significado que configurar max-connections=X × N.
• En un NEG zonal con extremos N, la configuración de max-connections-per-endpoint=X tiene el mismo significado que la opción de configuración max-connections=X × N.

Modo de balanceo de tarifas

Para el modo de balanceo RATE, debes definir la capacidad de destino mediante uno de los siguientes parámetros:

• max-rate-per-instance (por VM): Proporciona una tasa promedio de solicitudes HTTP de destino para una sola VM.
• max-rate-per-endpoint (por extremo en un NEG zonal): Proporciona una tasa promedio de solicitudes HTTP de destino para un solo extremo.
• max-rate (por NEG zonales y para grupos de instancias zonales): Proporciona una tasa promedio de solicitudes HTTP de destino para todo el NEG o todo grupo de instancias. Para los grupos de instancias administrados regionales, usa max-rate-per-instance en su lugar.

En la siguiente tabla, se muestra cómo el parámetro de capacidad de destino define los siguientes aspectos:

• La capacidad de destino de todo el backend
• La capacidad de destino esperada para cada instancia o extremo

Como se ilustra, la configuración max-rate-per-instance y max-rate-per-endpoint son proxies para calcular una tasa máxima de solicitudes HTTP de destino en todo el grupo de instancias o en el NEG zonal completo:

• En un grupo de instancias con instancias N, configurar max-rate-per-instance=X tiene el mismo significado que configurar max-rate=X × N.
• En un NEG zonal con extremos N, la configuración de max-rate-per-endpoint=X tiene el mismo significado que la opción de configuración max-rate=X × N.

Modo de balanceo de uso

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

La capacidad de destino max-utilization solo se puede especificar por grupo de instancias y no se puede aplicar a una VM específica del grupo.

El modo de balanceo UTILIZATION no tiene una capacidad de destino requerida. Cuando usas la consola de Trusted Cloud para agregar un grupo de instancias de backend a un servicio de backend, la consola deTrusted Cloud establece el valor de max-utilization en 0.8 (80%) si se selecciona el modo de balanceo deUTILIZATION. Además de max-utilization, el modo de balanceo UTILIZATION admite capacidades de destino más complejas, como se resume en la tabla en 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 te permiten configurar el comportamiento de distribución del tráfico de tu balanceador de cargas para que se base en métricas específicas de los requisitos de tu aplicación o infraestructura, en lugar de las métricas estándar de utilización o basadas en la tasa deTrusted Cloud.

Para obtener más información, consulta Métricas personalizadas para balanceadores de cargas de aplicaciones.

Cambia el modo de balanceo de un balanceador de cargas

En algunos balanceadores de cargas o sus configuraciones, no puedes cambiar el modo de balanceo porque el servicio de backend tiene solo un modo de balanceo posible. Para otros, según el backend usado, puedes cambiar el modo de balanceo porque hay más de un modo disponible para esos servicios de backend.

A fin de ver qué modos de balanceo son compatibles para cada balanceador de cargas, consulta Tabla: Modos de balanceo disponibles para cada balanceador de cargas.

Modos de balanceo y configuración de la capacidad objetivo

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

Balanceadores de cargas de aplicaciones y Cloud Service Mesh

En esta tabla, se enumeran las combinaciones de modo de balanceo y capacidad objetivo disponibles para los balanceadores de cargas de aplicaciones y Cloud Service Mesh.

Balanceadores de cargas de red de proxy

En esta tabla, se enumeran las combinaciones de modo de balanceo y capacidad objetivo disponibles para los balanceadores de cargas de red de proxy.

Balanceadores de cargas de red de transferencia

En esta tabla, se enumeran las combinaciones de modo de balanceo y capacidad objetivo disponibles para los balanceadores de cargas de red de transferencia.

Escalador de capacidad

Usa el escalador de capacidad para escalar la capacidad de destino (uso máximo, tasa máxima o cantidad máxima de conexiones) sin cambiar la capacidad de destino.

Para obtener la documentación de referencia de Trusted Cloud , consulta lo siguiente:

• Google Cloud CLI: capacidad de escalamiento
• API:
  • Regional

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

Puedes configurar el escalador de capacidad con cualquiera de estos valores:

• El valor predeterminado es 1, lo que significa que el grupo entrega hasta el 100% de su capacidad configurada (según balancingMode).
• Un valor de 0 significa que el grupo se desvía por completo y ofrece el 0% de su capacidad disponible. No puedes establecer una configuración de 0 cuando solo hay un backend conectado al servicio de backend.
• Un valor de 0.1 (10%) a 1.0 (100%).

En los siguientes ejemplos, se demuestra cómo funciona el escalador de capacidad junto con la configuración de capacidad objetivo.

• Si el modo de balanceo esRATE, max-rate se configura como 80 RPS y el escalador de capacidad 1.0, la capacidad disponible también es80 RPS.

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

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

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 con una política de balanceo de cargas de servicios.

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 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 deTrusted 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

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.

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 la sección “Servicios de backend” de las cuotas y los límites de recursos del balanceo de cargas.

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.

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 deTrusted 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 Trusted Cloud seleccionan backends mediante un hash quíntuple (--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 en los balanceadores de cargas de red de transferencia externos
• Distribución del tráfico para 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 los 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 Trusted 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 , 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 del proxy externos, el tiempo de espera es de inactividad. Para permitir más o menos tiempo antes de que se borre la conexión, cambia el valor del tiempo de espera. Este tiempo de espera de inactividad también se usa para las conexiones de WebSocket.

• 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.

Verificaciones de estado

Cada servicio de backend cuyos backends son grupos de instancias o NEG zonales debe tener una verificación de estado asociada.

Cuando creas un balanceador de cargas con la consola de Trusted 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

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 regional

• Página de gcloud compute backend-services, para .

¿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 Trusted Cloud