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 Platform:

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

Un servicio de backend dirige el tráfico a los backends, que son grupos de instancias o grupos de extremos de red.

El servicio de backend realiza varias funciones, como las que se mencionan a continuación:

  • Dirige el tráfico de acuerdo con el modo de balanceo. El modo de balanceo se define en el servicio de backend para cada backend.
  • Supervisa el estado del backend de acuerdo con una verificación de estado.
  • Mantiene 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 de HTTP(S) Varios
Balanceo de cargas de SSL 1
Balanceo de cargas del proxy TCP 1
Balanceo de cargas TCP/UDP interno 1
Balanceo de cargas de HTTP(S) interno Varios

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 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 una tupla de 5). 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 tráfico 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 pasan la verificación de estado pueden recibir solicitudes nuevas. Las instancias en mal estado no reciben solicitudes hasta que estén en buen estado de nuevo.

Consulta el recurso de la API de 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

Cada backend es un recurso al que un balanceador de cargas de GCP distribuye el tráfico. Existen dos tipos diferentes de recursos que se pueden usar como backends:

Para un servicio de backend determinado, los backends deben ser todos grupos de instancias o, si se admite, NEG. No puedes usar grupos de instancias ni NEG como backends en el mismo servicio de backend. Además, ten en cuenta la información siguiente:

  • Los backends para balanceadores de cargas TCP/UDP internos solo admiten backends de grupo de instancias.
  • 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 para un balanceador de cargas interno no necesitan direcciones IP externas.

Distribución del tráfico

Los valores de los campos siguientes 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 cuándo el backend está en uso pleno. Si todos los backends para el 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 puede basarse en las conexiones, el uso de CPU 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 por lo general quieres que las instancias funcionen con un uso máximo de CPU del 80%, puedes establecer el modo de balanceo en uso de CPU y la capacidad al 80%. Si quieres reducir el uso de instancias a la mitad, puedes dejar la capacidad al 80% de uso de CPU y establecer la capacidad de ajuste de escala en 0.5. Para desviar el servicio de backend, establece la capacidad de ajuste de escala en 0 y deja la capacidad como está. Para obtener más información acerca de la capacidad y el uso de CPU, consulta esta página sobre el ajuste de escala en función de la capacidad de entrega del balanceo de cargas o CPU.

Ten en cuenta la información siguiente:

  • Si el uso de CPU promedio de todas las instancias en los grupos de instancias de backend conectados al mismo servicio de backend es inferior al 10%, puede 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. En particular, Traffic Director usa servicios de backend cuyo esquema de balanceo de cargas es INTERNAL_SELF_MANAGED. Para un servicio de backend interno automático, la distribución del tráfico se realiza 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 del 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 balanceo 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.

Servicios de backend y regiones

El balanceo de cargas HTTP(S) es un servicio global. Es posible que tengas más de un servicio de backend en una región y que asignes servicios de backend a más de una región, todos atendidos por el mismo balanceador de cargas global. El tráfico se asigna a los servicios de backend de la manera siguiente:

  1. Cuando llega una solicitud de usuario, el servicio de balanceo de cargas determina el origen aproximado de la solicitud a partir de la dirección IP de origen.
  2. El servicio de balanceo de cargas conoce las ubicaciones de las instancias que posee el servicio de backend, su capacidad general y uso actual general.
  3. Si las instancias más cercanas al usuario tienen capacidad disponible, la solicitud se reenvía a ese conjunto de instancias.
  4. Las solicitudes entrantes a la región determinada se distribuyen de manera uniforme entre todos los servicios de backend y las instancias disponibles en esa región. Sin embargo, con cargas muy pequeñas, la distribución puede parecer desigual.
  5. Si no hay instancias en buen estado con capacidad disponible en una región determinada, el balanceador de cargas envía la solicitud a la siguiente región más cercana con capacidad disponible.

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, supón que estableces el modo de balanceo en un uso de CPU del 80%, dejas la capacidad de ajuste de escala en 100% y estableces el uso de balanceo de cargas de destino en el escalador automático en 80%. Cada vez que el uso de CPU del grupo supere el 64% (80% del 80%), el escalador automático creará instancias nuevas 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% de uso de CPU 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 la cantidad de instancias alcanza el máximo permitido por la configuración del escalador automático, este dejará de agregar instancias sin importar el uso. En este caso, el tráfico adicional se balanceará a 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 pasos siguientes:

  1. Crea una plantilla de instancias para el 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 restricciones y orientaciones siguientes 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 de forma conjunta. Es posible establecer un backend para usar maxRatePerInstance y el otro para 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 debes usar 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 maneras siguientes:

  • 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 forma 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 backends distribuye el tráfico entre aplicaciones o contenedores que se ejecutan dentro de instancias de VM. Para obtener más información, consulta esta página sobre 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 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, y se dirigen esas solicitudes 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.

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

Balanceador de cargas Opciones de afinidad de sesión
Interno • Ninguna
• IP de cliente
• IP de cliente y protocolo
• IP de cliente, protocolo y puerto
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 cada balanceador de cargas de GCP que usa 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 Platform Console, dirígete a la parte de 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 de 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 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 establecer la afinidad de sesión para un servicio de backend nuevo o el comando update si quieres establecer 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 generadas, el balanceador de cargas emite una cookie denominada GCLB en la primera solicitud y, luego, dirige cada solicitud posterior que tiene la misma cookie a la misma instancia. La afinidad en función de cookies permite que el balanceador de cargas distinga entre diferentes clientes que usan la misma dirección IP. Así, puede distribuir esos clientes entre las instancias de manera más uniforme. La afinidad en función de cookies permite que el balanceador de cargas mantenga la afinidad de la instancia, incluso cuando cambia la dirección IP de cliente.

La ruta de la cookie siempre es /, de modo que si hay dos servicios de backend en el mismo nombre de host que habilitan la afinidad en función de cookies, ambos se balancean con la misma cookie.

La vida útil de la cookie HTTP generada por el balanceador de cargas se puede configurar. Se puede establecer en 0 (valor predeterminado), lo que implica que la cookie sea solo una cookie de sesión, o pueda tener una vida útil de entre 1 a 86400 segundos (24 horas).

Console


Sigue estos pasos para establecer la afinidad de cookie generada:

  1. En Google Cloud Platform Console, puedes modificar la afinidad de cookie generada en la parte de 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 de 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


Para activar la afinidad de cookie generada, establece la configuración de --session-affinity en generated_cookie y --affinity-cookie-ttl en la vida útil de la cookie en segundos. Puedes usar el comando create para configurarla en un servicio de backend nuevo o el comando update a fin de configurarlo en 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 la afinidad de sesión si actualizas el servicio de backend y estableces la afinidad de sesión en none, o puedes editar el servicio de backend y establecer 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 Platform 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 de 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 en el menú desplegable Afinidad de sesión para desactivar la afinidad de sesiones.
  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 la afinidad de sesión

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

  • 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 evitarlo, 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 CPU, lo que puede provocar que cambien las capacidades calculadas en las zonas y se envíe 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 Platform 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 del balanceo de cargas
  2. Selecciona el lápiz de Editar de tu balanceador de cargas.
  3. Selecciona Configuración de backend.
  4. Selecciona el lápiz de 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 de 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 modificar 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 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 cargas 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. Una verificación de estado se ejecuta de manera continua y sus resultados ayudan a determinar qué instancias deben recibir solicitudes nuevas.

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

Prácticas recomendadas para verificaciones de estado

La práctica recomendada cuando se configura una verificación de estado es verificar el estado y entregar tráfico en el mismo puerto. Sin embargo, es posible realizar verificaciones de estado en un puerto mientras se entrega tráfico en otro. Si usas dos puertos diferentes, asegúrate de que las reglas de firewall y los servicios que se ejecutan en instancias estén configurados de manera correcta. Si ejecutas verificaciones de estado y entregas tráfico en el mismo puerto, pero decides cambiar de puerto en algún momento, asegúrate de actualizar el servicio de backend y la verificación de estado.

Los servicios de backend que no tienen una regla de reenvío válida que haga referencia a ellos no se verifican y, por ende, no tendrán estado.

Crea verificaciones de estado

Debes crear una verificación de estado antes de crear un servicio de backend. Te recomendamos que crees una verificación de estado para el mismo protocolo que el tráfico que cuya carga balanceas.

Console

En la consola, puedes crear una verificación de estado cuando creas tu servicio de backend.

gcloud

Para los comandos de gcloud, consulta la página sobre verificaciones de estado a fin de crear una.

API

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

Crea un servicio de backend

Console


Sigue estos pasos para crear un servicio de backend nuevo:

  1. En Google Cloud Platform Console, puedes crear un servicio de backend 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 de Editar de tu balanceador de cargas.
  3. Selecciona Configuración de backend.
  4. En el menú desplegable Crear o seleccionar servicios y depósitos de backend, selecciona Servicios de backend -> crear un servicio de backend.
  5. Ingresa un Nombre para el servicio de backend.
  6. De manera opcional, ingresa una Descripción.
  7. Selecciona el lápiz de Editar en la línea para la configuración de Protocolo, puerto y tiempo de espera.
    • Elige un Protocolo de http, https o http2.
    • Ingresa un port name para el Puerto con nombre.
    • De manera opcional, cambia la configuración predeterminada de tiempo de espera.
  8. En Tipo de backend, elige el botón de selección Grupo de instancias.
  9. En el cuadro de diálogo Backends, puedes crear uno o más backends.
    1. En el cuadro de diálogo Backend nuevo, selecciona un grupo de instancias existente en el menú desplegable.
    2. Ingresa uno o más números de puerto separados por comas, a través de los cuales el backend recibirá solicitudes.
      • Para un Protocolo de http, este campo se establece en 80.
      • Para un Protocolo de https, este campo se establece en 443.
      • Para un Protocolo de http2, este campo se establece en 443.
    3. Establece el porcentaje de Uso de CPU máximo.
    4. De manera opcional, configura el RPS máximo y deja el campo en blanco para unlimited. Establece RPS por instancia o RPS por grupo.
    5. Establece el porcentaje de Capacidad.
    6. Haz clic en el botón Listo.
  10. Marca o desmarca la casilla Habilitar Cloud CDN.
  11. En el menú desplegable Verificación de estado, selecciona una verificación de estado existente o Crea otra verificación de estado mediante los pasos siguientes:
    1. Establece el Nombre.
    2. De manera opcional, configura la Descripción.
    3. Configura el Protocolo y el Puerto. Consulta la sección de verificaciones de estado para conocer las prácticas recomendadas.
    4. Establece el Protocolo de proxy.
    5. De manera opcional, establece los valores de Solicitud y Respuesta.
    6. En Criterios de estado, establece los elementos siguientes:
      1. Establece el Intervalo de verificación en segundos.
      2. Establece el Tiempo de espera en segundos.
      3. Establece number of consecutive successes en el Umbral de buen estado.
      4. Establece number of consecutive failures en el Umbral de mal estado.
      5. Haz clic en Guardar y continuar.
    7. Haz clic en Configuración avanzada para modificar la afinidad de sesión, el tiempo de espera de desvío de la conexión, los encabezados de solicitud personalizados o las políticas de seguridad.
      1. Para establecer la afinidad de sesión, selecciona IP de cliente o cookie generada. Si seleccionaste *Cookie generada, establece una afinidad de cookie TTL en segundos.
      2. Para establecer el tiempo de espera de desvío de la conexión, ingresa la cantidad de segundos que la instancia espera para que se completen las conexiones en curso.
      3. Para crear encabezados de solicitud personalizados, haz clic en + Agregar encabezado, luego, agrega el nombre del encabezado y el valor del encabezado.
      4. Para habilitar una política de seguridad, selecciona una en el menú desplegable.
    8. Haz clic en el botón Actualizar para el Servicio de backend.
    9. Haz clic en el botón Actualizar para el balanceador de cargas.

gcloud


Para crear un servicio de backend con la herramienta de línea de comandos de gcloud, consulta la documentación del SDK de Cloud.

API


Para los comandos de la API, consulta la página de los servicios de backend a fin de crear un servicio de backend.

Modifica un servicio de backend

Los cambios a tus servicios de backend no se aplican de forma instantánea. Estos pueden demorar varios minutos en propagarse por toda la red.

Console


Sigue estos pasos para modificar un servicio de backend existente:

  1. En Google Cloud Platform Console, puedes editar un servicio de backend en la sección Configuración de backend de la página del balanceador de cargas HTTP(S).
    Ir a la página del balanceo de cargas
  2. Selecciona el lápiz de Editar de tu balanceador de cargas.
  3. Selecciona Configuración de backend.
  4. En Servicios de backend, selecciona el lápiz de Editar de un servicio de backend. Puedes modificar los campos siguientes:
    1. En Backends, agrega un Backend nuevo o selecciona el lápiz de Editar de un backend existente.
    2. Selecciona el lápiz de Editar en la línea para la configuración de Protocolo, puerto y tiempo de espera.
    3. Selecciona una Verificación de estado existente o crea una nueva mediante los pasos anteriores de creación de verificaciones de estado.
    4. Modifica la Afinidad de sesión y, cuando sea necesario, la Afinidad de cookie de TTL.
    5. Haz clic en Ajustes avanzados para modificar el tiempo de espera de desvío de la conexión.
    6. Marca o desmarca la casilla Habilitar Cloud CDN.
  5. Haz clic en Configuración avanzada para modificar la afinidad de sesión, el tiempo de espera de desvío de la conexión, los encabezados de solicitud personalizados o las políticas de seguridad.
    1. Para establecer la afinidad de sesión, selecciona IP de cliente o cookie generada. Si seleccionaste *Cookie generada, establece una afinidad de cookie TTL en segundos.
    2. Para establecer el tiempo de espera de desvío de la conexión, ingresa la cantidad de segundos que la instancia espera para que se completen las conexiones en curso.
    3. Para crear encabezados de solicitud personalizados, haz clic en + Agregar encabezado, luego, agrega el nombre del encabezado y el valor del encabezado.
    4. Para habilitar una política de seguridad, selecciona una en el menú desplegable.
    5. Haz clic en el botón Actualizar para el Servicio de backend.
    6. Haz clic en el botón Actualizar para el balanceador de cargas.

gcloud


Para modificar un servicio de backend con la herramienta de línea de comandos de gcloud, consulta la documentación del SDK de Cloud.

API


Para modificar un servicio de backend con la API, consulta los documentos de la API.

Agrega grupos de instancias a un servicio de backend

Para definir las instancias que se incluyen en un servicio de backend, debes agregar un backend y asignarle un grupo de instancias. Debes crear el grupo de instancias antes de agregarlo al backend.

Cuando agregas el grupo de instancias al backend, también debes definir ciertos parámetros.

Console


Sigue estos pasos para agregar un grupo de instancias a un servicio de backend:

  1. En Google Cloud Platform Console, puedes agregar un grupo de instancias a un backend 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 de Editar de tu balanceador de cargas.
  3. Selecciona Configuración de backend.
  4. Selecciona el lápiz de Editar para la Configuración de backend.
  5. Selecciona el lápiz de Editar de un Backend.
  6. En el cuadro de diálogo Editar backend, en el menú desplegable del Grupo de instancias, selecciona un Instance group.
  7. Haz clic en el botón Listo para Editar el backend.
  8. Haz clic en el botón Actualizar para el Servicio de backend.
  9. Haz clic en el botón Actualizar para el balanceador de cargas.

gcloud


Para agregar un grupo de instancias a un servicio de backend con la herramienta de línea de comandos de gcloud, consulta el SDK de Cloud.

API


Para agregar un grupo de instancias a un servicio de backend con la API, consulta los documentos de la API.

Agrega grupos de extremo de red a un servicio de backend

Para agregar un grupo de extremos de red a un servicio de backend, consulta cómo agregar un grupo de extremos de red a un servicio de backend.

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

Una vez que crees las verificaciones de estado y el servicio de backend, podrás 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 verificación de estado más reciente 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ágina sobre verificaciones de estado.

Otras notas

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

  • Disyuntores
  • 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 páginas siguientes:

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…