Explicación de los servicios de backend

Un servicio de backend es un recurso con campos que contienen valores de configuración para los siguientes servicios de balanceo de cargas de Google Cloud:

  • Balanceo de cargas HTTP(S) externo
  • Balanceo de cargas HTTP(S) interno
  • Balanceo de cargas del proxy SSL
  • Balanceo de cargas del proxy TCP
  • Balanceo de cargas TCP/UDP interno

El balanceo de cargas de red no usa un servicio de backend.

Los balanceadores de cargas usan la información de configuración en el recurso de servicio de backend para las siguientes funciones:

  • Para dirigir el tráfico a los backends correctos, que son grupos de instancias o grupos de extremos de red
  • Para distribuir el tráfico según un modo de equilibrio El modo de balanceo se define en el servicio de backend para cada backend.
  • Para supervisar el estado del backend mediante la verificación de estado designada en el servicio de backend
  • Para mantener la afinidad de sesión

Arquitectura

La cantidad de servicios de backend por balanceador de cargas depende del tipo de balanceador de cargas:

Tipo de balanceador de cargas Cantidad de servicios de backend
Balanceo de cargas HTTP(S) externo Varias
Balanceo de cargas HTTP(S) interno Varias
Balanceo de cargas del proxy SSL 1
Balanceo de cargas del proxy TCP 1
Balanceo de cargas TCP/UDP interno 1

Cada servicio de backend contiene uno o más backends.

Para un servicio de backend determinado, todos los backends deben ser grupos de instancias o grupos de extremos de red. Puedes asociar diferentes tipos de grupos de instancias (por ejemplo, grupos de instancias administrados y no administrados) con el mismo servicio de backend, pero no puedes asociar grupos de instancias y grupos de extremos de red al mismo servicio de backend.

Configuración del servicio de backend

Se puede establecer la configuración siguiente para cada servicio de backend:

  • Afinidad de sesión (opcional). Por lo general, los balanceadores de cargas usan un algoritmo hash para distribuir las solicitudes entre las instancias disponibles. Durante el uso normal, el hash se basa en la dirección IP de origen, la dirección IP de destino, el puerto de origen, el puerto de destino y el protocolo (un hash de 5-tupla). La afinidad de sesión ajusta lo que se incluye en el hash y, luego, intenta enviar todas las solicitudes del mismo cliente a la misma instancia de máquina virtual.
  • El tiempo de espera del servicio de backend. Este valor se interpreta de diferentes maneras según el tipo de balanceador de cargas y el protocolo que se use:
    • Para un balanceador de cargas HTTP(S), el tiempo de espera del servicio de backend es un tiempo de espera de solicitud/respuesta, excepto las conexiones que se actualizan a fin de usar el protocolo de Websocket.
    • Cuando se envía el tráfico de WebSocket a un balanceador de cargas HTTP(S), el tiempo de espera del servicio de backend se interpreta como la cantidad máxima de tiempo que un WebSocket, inactivo o activo, puede permanecer abierto.
    • Para un balanceador de cargas de proxy SSL o TCP, el tiempo de espera del servicio de backend se interpreta como un tiempo de espera inactivo para todo el tráfico.
    • Para un balanceador de cargas TCP/UDP interno, se ignora el parámetro de tiempo de espera del servicio de backend.
  • Una verificación de estado. El verificador de estado sondea instancias adjuntas al servicio de backend en intervalos configurados. Las instancias que aprueban la verificación de estado pueden recibir solicitudes nuevas. Las instancias en mal estado no reciben solicitudes hasta que vuelvan a estar en buen estado.

Consulta el recurso de la API del servicio de backend o la guía del usuario de la herramienta de línea de comandos de gcloud para obtener descripciones de las propiedades disponibles cuando trabajas con servicios de backend.

Backends

Puedes agregar varios backends a un solo servicio de backend. Cada backend es un recurso al que un balanceador de cargas de Google Cloud distribuye el tráfico. Existen tres tipos diferentes de recursos que se pueden usar como backends:

Para un servicio de backend determinado, todos los backends deben ser grupos de instancias o, si se admiten, NEG o depósitos de backend. No puedes usar diferentes tipos de backends con el mismo servicio de backend. Además:

  • Los backends para balanceadores de cargas TCP/UDP internos solo admiten backends de grupo de instancia.
  • Si un balanceador de cargas HTTP(S) tiene dos (o más) servicios de backend, puedes usar grupos de instancias como backends para un servicio de backend y NEG como backends para el otro servicio.

Backends y direcciones IP externas

Las VM de backend no necesitan direcciones IP externas:

  • Para los balanceadores de cargas HTTP(S), Proxy SSL y Proxy TCP, los clientes se comunican con Google Front End (GFE) mediante la dirección IP externa del balanceador de cargas. GFE se comunica con las VM de backend mediante las direcciones IP internas de la interfaz de la red principal. Debido a que GFE es un proxy, las VM de backend no requieren direcciones IP externas.

  • Para los balanceadores de cargas de red, los balanceadores de cargas de red enrutan paquetes mediante la traducción bidireccional de direcciones de red (NAT). Cuando las VM de backend envían respuestas a los clientes, usan la dirección IP externa de la regla de reenvío del balanceador de cargas como la dirección IP de origen.

  • Para los balanceadores de cargas internos, las VM de backend no necesitan direcciones IP externas.

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, que indica al sistema de balanceo de cargas cómo determinar cuando el backend está en uso pleno. Si todos los backends del servicio de backend en una región están en uso pleno, las solicitudes nuevas se enrutan de manera automática a la región más cercana que aún puede manejar solicitudes. El modo de balanceo se puede basar en las conexiones, el uso del backend o las solicitudes por segundo (tasa).
  • Una configuración de capacidad. La capacidad es un control adicional que interactúa con la configuración del modo de balanceo. Por ejemplo, si normalmente quieres que tus instancias funcionen con un uso de backend del 80% como máximo, deberías establecer tu modo de balanceo en uso de backend y tu capacidad al 80%. Si quieres reducir el uso de instancias a la mitad, puedes dejar la capacidad en un 80% del uso de backend y establecer el escalador de capacidad a 0.5. Para drenar el servicio de backend, establece el escalador de capacidad a 0 y deja la capacidad tal como está. Para obtener más información sobre la capacidad y el uso de backend, consulta Escalamiento en función de la CPU o la capacidad de entrega de balanceo de cargas.

Ten en cuenta lo siguiente:

  • Si el uso promedio de todas las instancias en los grupos de instancias de backend conectados al mismo servicio de backend es inferior al 10%, es posible que GCP prefiera zonas específicas. Esto puede suceder cuando usas grupos de instancias regionales administrados, grupos de instancias zonales administrados y grupos de instancias zonales no administrados. Este desequilibrio zonal se resolverá de manera automática a medida que se envíe más tráfico al balanceador de cargas. Los servicios de backend en otras regiones no afectan nada de esto.

Traffic Director también usa recursos de servicio de backend. Específicamente, Traffic Director usa los servicios de backend cuyo esquema de balanceo de cargas es INTERNAL_SELF_MANAGED. Para un servicio de backend interno administrado, la distribución del tráfico se logra mediante una combinación de un modo de balanceo de cargas y una política de balanceo de cargas. El servicio de backend dirige el tráfico a un backend (grupo de instancias o NEG) de acuerdo con el modo de balanceo de backend. Luego, una vez que se selecciona un backend, Traffic Director distribuye el tráfico en función de una política de balanceo de cargas.

Los servicios de backend internos autoadministrados son compatibles con los modos de balanceo siguientes:

  • UTILIZATION, si todos los backends son grupos de instancias
  • RATE, si todos los backends son grupos de instancias o NEG

Si eliges el modo de equilibrio RATE, debes especificar una tasa máxima por backend, instancia o extremo.

Protocolo para los backends

Cuando creas un servicio de backend, debes especificar un protocolo que se usará para la comunicación con sus backends. Un servicio de backend solo puede usar un protocolo. No se puede especificar un protocolo secundario para usar como resguardo.

Estos son los protocolos disponibles:

  • HTTP
  • HTTPS
  • HTTP/2
  • SSL
  • TCP
  • UDP

El protocolo válido depende del tipo de balanceador de cargas que crees, incluido su esquema de balanceo de cargas. Consulta la documentación de cada tipo de balanceador de cargas a fin de obtener más información sobre qué protocolos se pueden usar para sus servicios de backend.

HTTP/2 como protocolo para los backends también está disponible a fin de balancear cargas con Ingress.

Cuando cambias el protocolo de un servicio de backend, los backends permanecen inaccesibles a través de los balanceadores de cargas durante unos minutos.

Grupos de instancias

Servicios de backend y grupos de instancias administrados con ajuste de escala automático

Los grupos de instancias administrados con ajuste de escala automático son útiles si necesitas muchas máquinas configuradas de la misma manera y quieres agregar o quitar instancias de manera automática según sea necesario.

El porcentaje de ajuste de escala automático funciona con el modo de balanceo del servicio de backend. Por ejemplo, supongamos que estableces el modo de balanceo en un uso de backend del 80%, dejas la capacidad de ajuste en un 100% y configuras el uso de balanceo de cargas de destino en el escalador automático en un 80%. Cada vez que el uso de backend del grupo supere el 64% (el 80% del 80%), el escalador automático creará nuevas instancias de la plantilla hasta que el uso disminuya al 64%. Si el uso general cae por debajo del 64%, el escalador automático quitará las instancias hasta que el uso vuelva al 64%.

Las instancias nuevas tienen un período de enfriamiento antes de que se consideren parte del grupo, por lo que es posible que el tráfico exceda el 80% del uso de backend durante ese período, lo que hace que el exceso de tráfico se dirija al siguiente servicio de backend disponible. Una vez que las instancias estén disponibles, se les enrutará tráfico nuevo. Además, si el número de instancias alcanza el máximo permitido por la configuración del escalador automático, el escalador automático dejará de agregar instancias sin importar el uso. En este caso, el tráfico adicional se balanceará en la siguiente región disponible.

Configura grupos de instancias administrados con ajuste de escala automático

Para configurar grupos de instancias administrados con ajuste de escala automático, sigue los siguientes pasos:

  1. Crea una plantilla de instancias para tu grupo de instancias.
  2. Crea un grupo de instancias administrado y asígnale la plantilla.
  3. Activa el ajuste de escala automático según la capacidad de entrega del balanceo de cargas.

Restricciones y orientación para grupos de instancias

Debido a que Cloud Load Balancing ofrece una gran flexibilidad en cuanto al método de configuración del balanceo de cargas, es posible crear una configuración que no se comporte bien. Ten en cuenta las siguientes restricciones y orientaciones cuando crees grupos de instancias para usar con el balanceo de cargas.

  • No pongas una instancia de máquina virtual en más de un grupo de instancias.
  • No borres un grupo de instancias si un backend lo está usando.
  • Tu configuración será más simple si no agregas el mismo grupo de instancias a dos backends diferentes. Esto es lo que sucede si agregas el mismo grupo de instancias a dos backends:
    • Ambos deberán usar el mismo modo de balanceo, ya sea UTILIZATION o RATE.
    • Puedes usar maxRatePerInstance y maxRatePerGroup juntos. Es aceptable configurar un backend para que use maxRatePerInstance y el otro maxRatePerGroup.
    • Si tu grupo de instancias entrega a dos o más puertos para varios backends de forma respectiva, debes especificar distintos nombres de puerto en el grupo de instancias.
  • Todas las instancias en un grupo de instancias administrado o no administrado deben estar en la misma red de VPC y, si corresponde, en la misma subred.
  • Si usas un grupo de instancias administrado con ajuste de escala automático, no uses el modo de balanceo maxRate en el servicio de backend. Puedes usar el modo maxUtilization o maxRatePerInstance.
  • No conviertas un grupo de instancias administrado con ajuste de escala automático en el destino de dos balanceadores de cargas diferentes.
  • Cuando cambias el tamaño de un grupo de instancias administrado, el tamaño máximo del grupo debe ser menor o igual que el tamaño de la subred.

Grupos de extremos de red

Un extremo de red es una combinación de una dirección IP y un puerto, especificada de una de las siguientes maneras:

  • Con la especificación de un par IP address:port, como 10.0.1.1:80.
  • Con la especificación de solo una dirección IP de extremo de red. El puerto predeterminado para el NEG se usa de manera automática como el puerto del par IP address:port.

Los extremos de red representan servicios por su dirección IP y puerto, en lugar de hacer referencia a una VM específica. Un grupo de extremos de red (NEG) es una agrupación lógica de extremos de red.

Un servicio de backend que usa grupos de extremo de red como sus backends distribuye el tráfico entre aplicaciones o contenedores que se ejecutan dentro de instancias de VM. Para obtener más información, consulta Grupos de extremos de red en conceptos de balanceo de cargas.

Afinidad de sesión

Sin la afinidad de sesión, los balanceadores de cargas distribuyen solicitudes nuevas según el modo de balanceo del grupo de instancias de backend o NEG. Algunas aplicaciones, como los servidores con estado que usan la entrega de anuncios, juegos o servicios con almacenamiento en caché interno pesado, necesitan que varias solicitudes de un usuario determinado se dirijan a la misma instancia.

La afinidad de sesión permite identificar el tráfico de TCP del mismo cliente en función de parámetros como la dirección IP del cliente o el valor de una cookie, luego, esas solicitudes se dirigen a la misma instancia de backend si el backend está en buen estado y tiene capacidad (según su modo de balanceo).

La afinidad de sesión tiene poco efecto significativo en el tráfico UDP, ya que una sesión para UDP es una sola solicitud y respuesta.

La afinidad de sesión puede interrumpirse si la instancia está en mal estado o sobrecargada, por lo que no debes suponer que la afinidad es perfecta.

Para el balanceo de cargas HTTP(S), la afinidad de sesión funciona mejor con el modo de balanceo RATE.

Los diferentes balanceadores de cargas admiten distintas opciones de afinidad de sesión, como se resume en la siguiente tabla:

Balanceador de cargas Opciones de afinidad de sesión
Interno • Ninguna
• IP de cliente
• IP y protocolo de cliente
• IP, protocolo y puerto de cliente
Proxy TCP
Proxy SSL
• Ninguna
• IP de cliente
HTTP(S) • Ninguna
• IP de cliente
• Cookie generada
Red El balanceo de cargas de red no usa servicios de backend. En su lugar, debes establecer la afinidad de sesión para los balanceadores de cargas de red a través de grupos de destino. Consulta el parámetro sessionAffinity en grupos de destino.

En las secciones siguientes, se analizan dos tipos comunes de afinidad de sesión.

Uso de afinidad de IP de cliente

La afinidad de IP de cliente dirige las solicitudes desde la misma dirección IP de cliente a la misma instancia de backend en función de un hash de la dirección IP de cliente. La afinidad de IP de cliente es una opción para todos los balanceadores de cargas de Google Cloud que usan servicios de backend.

Cuando uses la afinidad de IP de cliente, ten esto en cuenta:

  • Es posible que la dirección IP de cliente, como la ve el balanceador de cargas, no sea el cliente de origen si está detrás de NAT o realiza solicitudes a través de un proxy. Las solicitudes realizadas a través de NAT o un proxy usan la dirección IP del proxy o enrutador NAT como la dirección IP de cliente. Esto puede hacer que el tráfico entrante se acumule de manera innecesaria en las mismas instancias de backend.

  • Si un cliente se traslada de una red a otra, su dirección IP cambiará, lo que da como resultado una afinidad interrumpida.

Console


Sigue estos pasos para establecer la afinidad de IP de cliente:

  1. En Google Cloud Console, ve a la sección Configuración de backend de la página del balanceador de cargas.
    Ir a la página Balanceo de cargas
  2. Selecciona el lápiz Editar de tu balanceador de cargas.
  3. Selecciona Configuración de backend.
  4. Selecciona el lápiz Editar para un Servicio de backend.
  5. En el cuadro de diálogo Editar servicio de backend, selecciona Client IP en el menú desplegable Afinidad de sesión.
    Esta acción habilita la afinidad de sesión de la IP de cliente. El campo Cookie de afinidad de TTL está inhabilitado porque no tiene relevancia para la afinidad de IP de cliente.
  6. Haz clic en el botón Actualizar para el Servicio de backend.
  7. Haz clic en el botón Actualizar para el balanceador de cargas.

gcloud


Puedes usar el comando create a fin de configurar la afinidad de sesión para un nuevo servicio de backend, o el comando update si quieres configurarlo para un servicio de backend existente. En este ejemplo se muestra su uso con el comando update.

gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
        --session-affinity client_ip
    

API


Consulta la referencia de la API para servicios de backend.

Cuando se establece la afinidad de cookie generada, el balanceador de cargas emite una cookie en la primera solicitud. Para cada solicitud posterior con la misma cookie, el balanceador de cargas dirige la solicitud a la misma VM o extremo de backend.

  • Para los balanceadores de cargas HTTP(S) externos, la cookie se llama GCLB.
  • Para los balanceadores de cargas internos  HTTP(S) y Traffic Director, la cookie se llama GCILB.

La afinidad basada en cookies puede identificar con mayor precisión un cliente a un balanceador de cargas, en comparación con la afinidad basada en IP de cliente. Por ejemplo:

  1. Con la afinidad basada en cookies, el balanceador de cargas puede identificar de forma única dos o más sistemas cliente que comparten la misma dirección IP de origen. Mediante la afinidad basada en IP de cliente, el balanceador de cargas trata todas las conexiones desde la misma dirección IP de origen como si fueran del mismo sistema cliente.

  2. Si un cliente cambia su dirección IP (por ejemplo, un dispositivo móvil que pasa de red a red), la afinidad basada en cookies permite que el balanceador de cargas reconozca las conexiones posteriores de ese cliente en lugar de tratar la conexión como nueva.

Cuando un balanceador de cargas crea una cookie para la afinidad basada en cookies generadas, establece el atributo path de la cookie en /. Si el mapa de URL del balanceador de cargas tiene una coincidencia de ruta que especifica más de un servicio de backend para un nombre de host determinado, todos los servicios de backend que usan afinidades de sesión basadas en cookies comparten la misma cookie de sesión.

La vida útil de la cookie HTTP generada por el balanceador de cargas se puede configurar. Puedes configurarla en 0 (predeterminado), lo que significa que la cookie es solo de sesión, o puedes establecer la duración de la cookie entre 1 y 86400 segundos (24 horas) inclusive.

Console


Sigue estos pasos para establecer la afinidad de cookie generada:

  1. En Google Cloud Console, puedes modificar la afinidad de cookie generada en la sección Configuración de backend de la página del balanceador de cargas de HTTP(S).
    Ir a la página Balanceo de cargas
  2. Selecciona el lápiz Editar de tu balanceador de cargas.
  3. Selecciona Configuración de backend.
  4. Selecciona el lápiz Editar para un Servicio de backend.
  5. Selecciona Generated cookie en el menú desplegable Afinidad de sesión para seleccionar Afinidad de cookie generada.
  6. En el campo Afinidad de la cookie TTL, establece la vida útil de la cookie en segundos.
  7. Haz clic en el botón Actualizar para el Servicio de backend.
  8. Haz clic en el botón Actualizar para el balanceador de cargas.

gcloud


Activa la afinidad de cookie generada mediante la configuración --session-affinity en generated_cookie, y --affinity-cookie-ttl en la duración de la cookie en segundos. Puedes usar el comando create a fin de configurarla para un nuevo servicio de backend o el comando update a fin de configurarla para un servicio de backend existente. En este ejemplo se muestra su uso con el comando update.

gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
        --session-affinity generated_cookie \
        --affinity-cookie-ttl 86400
    

API


Consulta la Referencia de la API para servicios de backend.

Inhabilita la afinidad de sesión

Puedes desactivar el afinidad de sesión mediante la actualización del servicio de backend y la afinidad de sesión en none, o puedes editar el servicio de backend y configurar la afinidad de sesión en none en un editor de texto. También puedes usar cualquiera de los comandos para modificar la vida útil de la cookie.

Console


Sigue estos pasos para inhabilitar la afinidad de sesión:

  1. En Google Cloud Console, puedes inhabilitar la afinidad de sesión en la sección Configuración de backend de la página del balanceador de cargas.
    Ir a la página Balanceo de cargas
  2. Selecciona el lápiz Editar de tu balanceador de cargas.
  3. Selecciona Configuración de backend.
  4. Selecciona el lápiz Editar para un Servicio de backend.
  5. Selecciona None del menú desplegable Afinidad de sesión para desactivar la afinidad de sesión.
  6. Haz clic en el botón Actualizar para el Servicio de backend.
  7. Haz clic en el botón Actualizar para el balanceador de cargas.

gcloud


Para inhabilitar la afinidad de sesión, ejecuta el comando siguiente:

      gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
      --session-affinity none
    


O

gcloud compute backend-services edit [BACKEND_SERVICE_NAME]

API


Consulta la referencia de la API para servicios de backend.

Pérdida de la afinidad de sesión

Sin importar el tipo de afinidad elegida, un cliente puede perder afinidad con la instancia en las siguientes situaciones.

  • El grupo de instancias se queda sin capacidad, y el tráfico debe dirigirse a una zona diferente. En este caso, el tráfico de las sesiones existentes puede enviarse a la zona nueva, lo que interrumpe la afinidad. A fin de mitigar esto, asegúrate de que los grupos de instancias tengan la capacidad suficiente para manejar todos los usuarios locales.
  • El ajuste de escala automático agrega instancias al grupo de instancias o las quita. En cualquier caso, el servicio de backend reasigna la carga y el destino puede moverse. Para mitigarlo, asegúrate de que la cantidad mínima de instancias que aprovisiona el ajuste de escala automático sea suficiente a fin de manejar la carga esperada; luego, solo usa el ajuste de escala automático para aumentos de carga inesperados.
  • La instancia de destino falla las verificaciones de estado. La afinidad se pierde cuando la sesión se traslada a una instancia en buen estado.
  • El modo de balanceo está configurado en uso de backend, esto puede provocar que tus capacidades calculadas entre zonas cambien, lo que envía parte del tráfico a otra zona dentro de la región. Esto es más probable con poco tráfico cuando la capacidad calculada es menos estable.
  • Puedes perder afinidad de sesión cuando los backends se encuentran en varias regiones de la nube y el enrutamiento del cliente está diseñado para que la primera solicitud y las posteriores en una conexión salgan de diferentes ubicaciones geográficas. Esto se debe a que las solicitudes adicionales podrían enrutarse a una región de la nube diferente determinada por su ubicación de salida nueva.

Establece la configuración de tiempo de espera

Para conexiones de larga duración al servicio de backend del balanceador de cargas, establece una configuración de tiempo de espera superior a la predeterminada de 30 segundos.

Console


Sigue estos pasos para configurar el tiempo de espera:

  1. En Google Cloud Console, puedes modificar la configuración del tiempo de espera en la sección Configuración de backend de la página del balanceador de cargas HTTP(S).
    Ir a la página Balanceo de cargas
  2. Selecciona el lápiz Editar de tu balanceador de cargas.
  3. Selecciona Configuración de backend.
  4. Selecciona el lápiz Editar para el Servicio de backend.
  5. En la línea para la configuración de Protocolo, puerto y tiempo de espera, selecciona el lápiz Editar.
  6. Ingresa una Configuración de tiempo de espera nueva en segundos.
  7. Haz clic en el botón Actualizar para el Servicio de backend.
  8. Haz clic en el botón Actualizar para el balanceador de cargas.

gcloud


Para cambiar la configuración de tiempo de espera con la herramienta de línea de comandos de gcloud, usa el comando “gcloud compute backend-services update”. Agrega el comando con --help para obtener información detallada.

gcloud compute backend-services update [BACKEND_SERVICE] [--timeout=TIMEOUT]
    

API


Consulta la referencia de la API de REST para los servicios de backend.

Puertos con nombre

Para los balanceadores de cargas HTTP(S) interno, HTTP(S) externo, proxy SSL y proxy TCP, los servicios de backend deben tener un puerto con nombre asociado si sus backends son grupos de instancias. El puerto con nombre informa al balanceador de cargas que debe usar ese puerto con nombre configurado en el grupo de instancias de backend, lo que se traduce en un número de puerto. Este es el puerto que usa el balanceador de cargas a fin de conectarse a las VM de backend, que puede ser diferente del puerto que los clientes usan para contactar al balanceador de cargas.

Los puertos con nombre son pares clave-valor que representan un nombre de servicio y un número de puerto en el que se ejecuta un servicio. El par clave-valor se define en un grupo de instancias. Cuando un servicio de backend usa ese grupo de instancias como backend, puede “suscribirse” al puerto con nombre:

  • Cada grupo de instancias puede tener hasta cinco puertos con nombre (pares clave-valor) definidos.
  • Cada servicio de backend para un balanceador de cargas HTTP(S), proxy SSL o proxy TCP que usa backends de grupo de instancias solo puede “suscribirse” a un único puerto con nombre.
  • Cuando especificas un puerto con nombre para un servicio de backend, todos los grupos de instancias de backend deben tener, al menos, un puerto con nombre definido que use ese mismo nombre.

Los puertos con nombre no se pueden usar en estas circunstancias:

  • Para los backends NEG: los NEG definen puertos por extremo y no hay un par clave-valor de puerto con nombre asociado a un NEG.
  • Para balanceadores de cargas TCP/UDP internos: dado que los balanceadores de cargas TCP/UDP internos son balanceadores de paso (no proxies), sus servicios de backend no admiten la configuración de un puerto con nombre.

Verificaciones de estado

Cada servicio de backend debe tener una verificación de estado asociada. La verificación de estado debe existir antes de que crees el servicio de backend.

Una verificación de estado se ejecuta de forma continua y sus resultados ayudan a determinar qué instancias pueden recibir solicitudes nuevas.

Las instancias en mal estado no reciben solicitudes nuevas y se siguen sondeando. Si una instancia en mal estado realiza una verificación, se considera que está en buen estado y comienza a recibir conexiones nuevas.

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

Visualiza los resultados de una verificación de estado de los servicios de backend

Después de crear los controles de estado y el servicio de backend, puedes ver los resultados de la verificación de estado.

Console


Sigue estos pasos para ver el resultado de una verificación de estado en un servicio de backend:

  1. Dirígete a la página Balanceo de cargas.
    Ir a la página Balanceo de cargas
  2. Haz clic en el nombre de un balanceador de cargas.
  3. En Backend, para un Servicio de backend, observa la columna En buen estado en la tabla del Grupo de instancias.

gcloud


Para ver los resultados de la última verificación de estado con la herramienta de línea de comandos de gcloud, usa el comando backend-services get-health.

gcloud compute backend-services get-health [BACKEND_SERVICE]
    

El comando muestra un valor healthState para todas las instancias del servicio de backend especificado, con un valor HEALTHY o UNHEALTHY:

      healthStatus:
        - healthState: UNHEALTHY
          instance: us-central1-b/instances/www-video1
        - healthState: HEALTHY
          instance: us-central1-b/instances/www-video2
      kind: compute#backendServiceGroupHealth
      

API


Para ver los comandos de la API, consulta la páginaVerificaciones de estado.

Funciones adicionales habilitadas en el recurso de servicio de backend

Las siguientes funciones opcionales de Google Cloud, que se habilitan mediante el recurso de servicio de backend, no se tratan en este documento:

Otras notas

Los cambios a tus servicios de backend no se aplican de forma instantánea. Pueden tomar varios minutos en propagarse por la red.

Las siguientes funciones de Traffic Director no son compatibles con los balanceadores de cargas de Google Cloud:

  • Interrupción de circuitos
  • Detección de valores atípicos
  • Políticas de balanceo de cargas
  • Afinidad de sesión en función de cookies HTTP
  • Afinidad de sesión en función de encabezados HTTP

Próximos pasos

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: