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

En esta página, se proporciona una descripción general de las funciones avanzadas de administración del tráfico disponibles para balanceadores de cargas de aplicaciones globales. Esta página es solo para el balanceador de cargas de aplicaciones externo global. Estos balanceadores de cargas son siempre globales y siempre están en el nivel Premium. Si usas un balanceador de cargas en un modo diferente, consulta una de las siguientes páginas:

Los balanceadores de cargas de aplicaciones externos globales admiten funciones avanzadas de administración del tráfico que te permiten usar las siguientes características:
  • Direccionamiento del tráfico: Enrutar de manera inteligente el tráfico en función de los parámetros HTTP(S) (por ejemplo, host, ruta de acceso, encabezados y otros parámetros de solicitud)
  • Acciones de tráfico: Realizar acciones basadas en solicitudes y en respuestas (por ejemplo, redireccionamientos y transformaciones de encabezados)
  • Políticas de tráfico: Ajustar con detalle el comportamiento del balanceo de cargas (por ejemplo, algoritmos de balanceo de cargas avanzados)

Puedes configurar estas funciones mediante mapas de URL y servicios de backend. Para obtener más información, consulta los siguientes temas:

Ejemplos de casos prácticos

La administración del tráfico abarca muchos casos prácticos. En esta sección, se proporcionan algunos ejemplos de alto nivel.

Direccionamiento del tráfico: enrutamiento basado en encabezados

El direccionamiento del tráfico te permite dirigir el tráfico a las instancias de servicio según los parámetros HTTP, como los encabezados de las solicitudes. Por ejemplo, si el dispositivo de un usuario es un dispositivo móvil con user-agent:Mobile en el encabezado de la solicitud, el direccionamiento del tráfico puede enviar ese tráfico a instancias de servicio designadas para controlar el tráfico de dispositivos móviles y enviar tráfico que no tenga user-agent:Mobile a instancias designadas que controlan el tráfico desde otros dispositivos.

Direccionamiento de tráfico de Cloud Load Balancing
Figura 1. Direccionamiento de tráfico de Cloud Load Balancing (haz clic para agrandar).

Acciones de tráfico: división del tráfico según el peso

Por lo general, implementar una versión nueva de un servicio de producción existente implica cierto riesgo. Incluso si tus pruebas pasan la etapa de pruebas, es probable que no quieras someter al 100% de tus usuarios a la nueva versión de inmediato. Con la administración del tráfico, puedes definir divisiones de tráfico porcentuales en varios servicios de backend.

Por ejemplo, puedes enviar el 95% del tráfico a la versión anterior de tu servicio y el 5% a la nueva versión de tu servicio. Después de verificar que la nueva versión de producción funciona como se espera, puedes cambiar de forma gradual los porcentajes hasta que todo el tráfico llegue a la nueva versión de tu servicio. La división del tráfico suele usarse para implementar versiones nuevas, pruebas A/B, migración de servicios y procesos similares.

División del tráfico de Cloud Load Balancing
Figura 2. División de tráfico del balanceo de cargas de Google Cloud (haz clic para ampliarla).
No configures la afinidad de sesión si usas la división de tráfico ponderada. Si lo haces, la configuración de división de tráfico ponderada tiene prioridad.

Políticas de tráfico: solicitud de duplicación

Tu organización podría tener requisitos de cumplimiento específicos que obliguen a que todo el tráfico se duplique en un servicio adicional que pueda, por ejemplo, registrar los detalles de la solicitud en una base de datos para volver a reproducirlos después.

Extensibilidad con extensiones del servicio

Los textos destacados de las extensiones de servicio te permiten incorporar lógica personalizada en la ruta de acceso de los datos del balanceo de cargas. Estas extensiones te permiten indicarle a los balanceadores de cargas de aplicaciones compatibles que realicen llamadas gRPC a aplicaciones o servicios administrados por el usuario durante el procesamiento de datos.

Para obtener más información, consulta la Descripción general de las extensiones de servicio.

Componentes de la administración del tráfico

En un nivel alto, los balanceadores de cargas proporcionan administración del tráfico cuando se aprovechan los recursos de mapas de URL globales y los servicios de backend globales.

Puedes configurar el direccionamiento del tráfico y las acciones de tráfico con mapas de URL. Los recursos de Google Cloud que están asociados a los mapas de URL incluyen los siguientes:

  • Regla de ruta
  • Coincidencias de la regla
  • Acción de la regla

Puedes configurar las políticas de tráfico mediante servicios de backend. Los recursos de Google Cloud que están asociados a los servicios de backend incluyen lo siguiente:

  • Política de balanceador de cargas de localidad
  • Configuración del balanceador de cargas hash coherente
  • Detección de valores atípicos

En el siguiente diagrama, se muestran los recursos que se usan para implementar cada función.

Modelo de datos de Cloud Load Balancing.
Figura 3. Modelo de datos de Cloud Load Balancing (haz clic para ampliar).

Enrutamiento de solicitudes a backends

En los balanceadores de cargas de aplicaciones externos globales, el backend de tu tráfico se determina mediante un enfoque de dos fases:

  • El balanceador de cargas selecciona un servicio de backend o un bucket de backend según las reglas definidas en un mapa de URL global.
  • El servicio de backend selecciona una instancia de backend según las políticas definidas en un servicio de backend global.

Cuando configuras el enrutamiento, puedes elegir entre los siguientes modos:

  • Regla simple de host y ruta de acceso
  • Regla avanzada de host, ruta de acceso y enrutamiento

Los dos modos son mutuamente exclusivos. Cada mapa de URL puede contener solo un modo o el otro.

Regla sencilla de host y ruta de acceso

En una regla simple de host y ruta de acceso, los mapas de URL funcionan como se indica en la descripción general de los mapas de URL.

En el siguiente diagrama, se muestra el flujo lógico de una regla simple de host y ruta de acceso.

Flujo de mapa de URL con una regla sencilla de host y ruta de acceso.
Figura 4. Flujo de mapa de URL con una regla simple de host y ruta de acceso (haz clic para ampliar).

Una solicitud se evalúa en un inicio mediante reglas de host. Un host es el dominio que la solicitud especifica. Si la solicitud host coincide con una de las entradas del campo hosts, se usa el comparador de rutas de acceso asociado.

A continuación, se evalúa el comparador de rutas de acceso. Las reglas de ruta de acceso se pueden especificar en cualquier orden y se evalúan según el principio de hacer coincidir primero la ruta de acceso más larga. Después de encontrar la coincidencia más específica, la solicitud se enruta al servicio de backend correspondiente. Si la solicitud no coincide, se usa el servicio de backend predeterminado.

Una regla típica y simple de host y ruta de acceso puede tener un aspecto similar al siguiente, en el que el tráfico de video se dirige a video-backend-service y el resto del tráfico a web-backend-service. defaultService y service pueden apuntar a un servicio de backend o a un bucket de backend. En este ejemplo, se muestran servicios de backend.

gcloud compute url-maps describe lb-map
defaultService: global/backendServices/web-backend-service
hostRules:
- hosts:
  - '*'
  pathMatcher: pathmap
name: lb-map
pathMatchers:
- defaultService: global/backendServices/web-backend-service
  name: pathmap
  pathRules:
  - paths:
    - /video
    - /video/*
    service: global/backendServices/video-backend-service

Regla avanzada de host, ruta de acceso y enrutamiento

Las reglas avanzadas de host, ruta de acceso y enrutamiento proporcionan opciones de configuración adicionales en comparación con las reglas simples de host y ruta de acceso. Estas opciones habilitan patrones de administración de tráfico más avanzados y también modifican algunas de las semánticas. Por ejemplo, las reglas de ruta tienen un valor de prioridad asociado y se interpretan en orden de prioridad (en lugar de usar la semántica de hacer coincidir primero la ruta de acceso más larga).

Al igual que en el ejemplo de la regla simple de host y ruta de acceso anterior, puedes configurar la administración avanzada del tráfico mediante un mapa de URL. Por ejemplo, el siguiente mapa de URL configura el enrutamiento en el que el 95% del tráfico se enruta a un servicio de backend y el 5% del tráfico a otro servicio de backend.

defaultService y service pueden apuntar a un servicio de backend o a un bucket de backend. En este ejemplo, se muestran servicios de backend.

gcloud compute url-maps describe lb-map
defaultService: global/backendServices/service-a
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: lb-map
pathMatchers:
- defaultService: global/backendServices/service-a
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: ''
    routeAction:
      weightedBackendServices:
      - backendService: global/backendServices/service-a
        weight: 95
      - backendService: global/backendServices/service-b
        weight: 5

Reglas de host

Cuando una solicitud llega al balanceador de cargas, el campo host de la solicitud se evalúa en comparación con las hostRules que se definen en el mapa de URL. Cada regla de host consta de una lista de uno o más hosts y un solo comparador de rutas de acceso (pathMatcher). Si no se definen hostRules, la solicitud se direcciona al defaultService.

Para obtener más información, consulta hostRules[] y defaultService en la documentación de la API de mapas de URL globales.

Comparador de rutas de acceso

Una vez que una solicitud coincide con una regla de host, el balanceador de cargas evalúa el comparador de rutas de acceso correspondiente al host.

Un comparador de rutas de acceso se compone de lo siguiente:

  • Una o más reglas de ruta de acceso (pathRules) o reglas de enrutamiento (routeRules).
  • Un servicio predeterminado (defaultService), que es el servicio o bucket de backend predeterminado que se usa cuando no hay otros servicios o buckets de backend.
Para obtener más información, consulta pathMatchers[], pathMatchers[].pathRules[] y pathMatchers[].routeRules[] en la documentación de la API de mapas de URL globales.

Reglas de ruta de acceso

Las reglas de ruta de acceso (pathRules) especifican una o más rutas de URL, como / o /video. Las reglas de ruta de acceso, en general, están diseñadas para el tipo de enrutamiento simple basado en hosts y rutas de acceso que se describió antes.

Para obtener más información, consulta pathRules[] en la documentación de la API de mapas de URL globales.

Reglas de enrutamiento

Una regla de enrutamiento routeRules compara la información de una solicitud entrante y toma una decisión de enrutamiento en función de la coincidencia.

Las reglas de enrutamiento pueden contener una variedad de reglas de coincidencia diferentes (matchRules) y una variedad de acciones de rutas diferentes (routeAction).

Una regla de coincidencia evalúa la solicitud entrante según la ruta de acceso, los encabezados y los parámetros de búsqueda de la solicitud HTTP(S). Las reglas de coincidencia admiten varios tipos de coincidencia (por ejemplo, coincidencia de prefijo), así como modificadores (por ejemplo, distinción entre mayúsculas y minúsculas). Esto te permite enviar solicitudes HTTP(S) a un conjunto de backends según la presencia de un encabezado HTTP personalizado.

Nota: Las opciones de concordancia y la semántica varían según la parte de la solicitud con la que coincida. Para obtener más información, consulta matchRules[] en la documentación de la API de mapas de URL globales.

Si tienes varias reglas de ruta, el balanceador de cargas las ejecuta en orden de prioridad (según el campo priority), lo que te permite especificar lógica personalizada para coincidencias, enrutamiento y otras acciones.

Dentro de una regla de enrutamiento determinada, cuando se realiza la primera coincidencia, el balanceador de cargas deja de evaluar las reglas de coincidencia, y se ignoran las reglas restantes.

Google Cloud realiza las siguientes acciones:

  1. Busca la primera regla de coincidencia que coincida con la solicitud.
  2. Deja de mirar a las otras reglas de coincidencia.
  3. Aplica las tareas en las acciones de ruta correspondientes.

Las reglas de ruta tienen varios componentes, como se describe en la siguiente tabla.

Componente de regla de ruta (API field name) Descripción
Prioridad (priority) Un número del 0 hasta 2,147,483,647 (es decir, (2^31) - 1) asignado a una regla de ruta dentro de un comparador de rutas de acceso determinado.

La prioridad determina el orden de la evaluación de la regla de ruta. La prioridad de una regla disminuye a medida que aumenta su número, de modo que una regla con prioridad 4 se evalúa antes que una regla con prioridad 25. Se aplica la primera regla que coincida con la solicitud.

Las cifras de prioridad pueden tener brechas. No se puede crear más de una regla con la misma prioridad.
Descripción (description) Una descripción opcional de hasta 1,024 caracteres.
Servicio (service) La URL completa o parcial del recurso de servicio de backend al que se dirige el tráfico si esta regla coincide.
Reglas de coincidencia (matchRules) Una o más reglas que se evalúan en relación con la solicitud. Estas matchRules pueden coincidir con todos los atributos HTTP de la solicitud o con un subconjunto de ellos, como la ruta de acceso, los encabezados HTTP y los parámetros de consulta (GET).

En una matchRule, deben cumplirse todos los criterios de coincidencia para que se apliquen las routeActions de la routeRule. Si una routeRule tiene varias matchRules, las routeActions de la routeRule tienen efecto cuando una solicitud coincide con cualquiera de las matchRules de la routeRule.
Acción de ruta (routeAction) Te permite especificar qué acciones realizar cuando se cumplen los criterios de la regla de coincidencia. Estas acciones incluyen división de tráfico, reescrituras de URL, reintentos y duplicación, inyección de fallas y políticas de CORS.
Acción de redireccionamiento (urlRedirect) Puedes configurar una acción para responder con un redireccionamiento HTTP cuando se cumplan los criterios de la regla de coincidencia. Este campo no se puede usar junto con una acción de ruta.
Acción del encabezado (headerAction) Puedes configurar reglas de transformación de encabezado de respuesta y solicitud cuando se cumplen los criterios dentro de matchRules.
Para obtener más información sobre los siguientes campos, consulta la documentación de la API de mapas de URL globales.
  • routeRules[]
  • routeRules[].priority
  • routeRules[].description
  • routeRules[].service
  • routeRules[].matchRules[]
  • routeRules[].routeAction
  • routeRules[].urlRedirect
  • routeRules[].headerAction

Reglas de coincidencia

Las reglas de coincidencia (matchRules) comparan uno o más atributos de una solicitud y realizan acciones especificadas en la regla de enrutamiento. En la siguiente lista, se brindan algunos ejemplos de atributos de solicitud que pueden coincidir mediante las reglas de coincidencia:

  • Host: Un nombre de host es la parte del nombre de dominio de una URL, por ejemplo, la parte del nombre del host de la URL http://example.net/video/hd es example.net. En la solicitud, el nombre de host proviene del encabezado del Host, como se muestra en este comando curl de ejemplo, en el que 10.1.2.9 es la dirección IP del balanceo de cargas:

    curl -v http://10.1.2.9/video/hd --header 'Host: example.com'
    
  • Las rutas de acceso siguen el nombre del host, por ejemplo, /images. La regla puede especificar si se debe hacer coincidir la ruta de acceso completa o solo la parte inicial.

  • Otros parámetros de solicitud HTTP, como los encabezados HTTP, que permiten la coincidencia de cookies, además de la coincidencia basada en parámetros de consulta (variables GET).

Para obtener una lista completa de las reglas de coincidencia compatibles, consulta pathMatchers[].routeRules[].matchRules[] en la documentación de la API de mapas de URL globales.

Acciones de ruta

Las acciones de ruta son acciones específicas que se deben realizar cuando una regla de ruta coincide con los atributos de una solicitud.

Acción de ruta (API field name) Descripción
Redireccionamientos (urlRedirect) Muestra un código de respuesta 3xx configurable. También establece el encabezado de respuesta Location con el URI apropiado y reemplaza el host y la ruta como se especifica en la acción de redireccionamiento.
Reescritura de URL (urlRewrite) Reescribe la parte del nombre de host de la URL, la parte de la ruta de la URL o ambas antes de enviar una solicitud al servicio de backend seleccionado. Para las reescrituras de la parte de la ruta, puedes usar comodines en pathTemplateRewrite.
Transformaciones del encabezado (headerAction) Agrega o quita encabezados de solicitud antes de enviar una solicitud al servicio de backend. También puede agregar o quitar encabezados de respuesta después de recibir una respuesta del servicio de backend.
Duplicación de tráfico (requestMirrorPolicy)

Además de reenviar la solicitud al servicio de backend seleccionado, envía una solicitud idéntica al servicio de backend duplicado y configurado en una base enviar y olvidar. El balanceador de cargas no espera una respuesta del backend al que envía la solicitud duplicada.

La duplicación es útil para probar una versión nueva de un servicio de backend. También puedes usarla para depurar errores de producción en una versión de depuración de tu servicio de backend, en lugar de hacerlo en la versión de producción.

La duplicación de tráfico es compatible con los siguientes elementos:

  • Grupos de instancias administrados, NEG zonales y backends híbridos de NEG. No es compatible con NEG de Internet, NEG sin servidores y Private Service Connect.
  • Las solicitudes HTTP que no tienen cuerpos.
División del tráfico ponderado (weightedBackendServices) Permite que el tráfico de una regla coincidente se distribuya a varios servicios de backend, proporcional a un peso definido por el usuario asignado al servicio de backend individual.

Esta capacidad es útil para configurar implementaciones por etapas o pruebas A/B. Por ejemplo, la acción de ruta se podría configurar, de manera que el 99% del tráfico se envíe a un servicio que ejecuta una versión estable de una aplicación, mientras que el 1% del tráfico se envíe a un servicio independiente con una versión más reciente de esa aplicación.
Reintentos (retryPolicy)

Configuran las condiciones en las que el balanceador de cargas reintenta enviar solicitudes fallidas, cuánto espera el balanceador de cargas antes de volver a intentarlo y la cantidad máxima de reintentos permitidos.

Las políticas de reintento no son compatibles con los backends de NEG de Internet.

Tiempo de espera (timeout) Especifica el tiempo de espera para la ruta seleccionada. El tiempo de espera se calcula desde el momento en que la solicitud se procesa por completo hasta el momento en que la respuesta se procesa por completo. El tiempo de espera incluye todos los reintentos.
Inyección de fallas (faultInjectionPolicy) Presenta errores cuando se atienden solicitudes para simular fallas, incluida la latencia alta, la sobrecarga del servicio, las fallas del servicio y la partición de la red. Esta función es útil a fin de probar la resistencia de un servicio para fallas simuladas.
Inyección de demora (faultInjectionPolicy) Presenta retrasos para una parte de solicitudes definidas por el usuario antes de enviar la solicitud al servicio de backend seleccionado.
Inyección de anulación (faultInjectionPolicy) Responde directamente a una fracción de las solicitudes con códigos de estado HTTP definidos por el usuario, en lugar de reenviar esas solicitudes al servicio de backend.
Políticas de seguridad (corsPolicy) Las políticas de uso compartido de recursos entre dominios (CORS) controlan la configuración para aplicar las solicitudes de CORS.

Puedes especificar una de las siguientes acciones de ruta:

  • Enrutar el tráfico a un solo servicio (service)
  • Dividir el tráfico entre varios servicios (weightedBackendServices weight:x, en el que x debe ser de 0 a 1000).
  • Redireccionar las URL (urlRedirect)

Además, puedes combinar cualquiera de las acciones de ruta mencionadas antes con una o más de las siguientes acciones de ruta:

  • Tráfico de duplicación (requestMirrorPolicy)
  • Reescribe la ruta de acceso y el host de URL (urlRewrite)
  • Reintentar con las solicitudes que fallaron (retryPolicy)
  • Configurar el tiempo de espera (timeout)
  • Ingresar errores en un porcentaje del tráfico (faultInjectionPolicy)
  • Agregar política de CORS (corsPolicy)
  • Manipular los encabezados de respuesta o solicitud (headerAction).
Para obtener más información sobre la configuración y la semántica de las acciones de ruta, consulta la documentación de la API de mapas de URL globales.
  • urlRedirect
  • urlRewrite
  • headerAction
  • requestMirrorPolicy
  • weightedBackendServices
  • retryPolicy
  • timeout
  • faultInjectionPolicy
  • corsPolicy

Redireccionamientos HTTP a HTTPS

Si necesitas redireccionar el tráfico HTTP a HTTPS, puedes crear dos reglas de reenvío con una dirección IP común.

Si quieres ver un ejemplo completo, consulta Configura el redireccionamiento de HTTP a HTTPS para los balanceadores de cargas de aplicaciones externos globales.

Políticas de tráfico

Mediante los recursos de servicios de backend, puedes configurar políticas de tráfico para ajustar el balanceo de cargas dentro de un grupo de instancias o un grupo de extremos de red (NEG). Estas políticas solo se aplican después de que se selecciona un servicio de backend con tu mapa de URL (como se describió antes).

Las políticas de tráfico te permiten hacer lo siguiente:

  • Controlar el algoritmo del balanceo de cargas entre instancias dentro del servicio de backend
  • Controlar el volumen de conexiones a un servicio ascendente
  • Controlar el desalojo de hosts que no están en buen estado desde un servicio de backend
Las siguientes funciones de la política de tráfico se configuran en el servicio de backend regional.

Política de tráfico (API field name) Descripción
Política de balanceo de cargas de la localidad (LocalityLbPolicy)

Para un servicio o un bucket de backend, la distribución del tráfico se basa en un modo de balanceo de cargas y una política de localidad de balanceo de cargas.

El modo de balanceo determina la fracción del tráfico que se debe enviar a cada backend (bucket, grupo de instancias o NEG GCE_VM_IP_PORT). La política del balanceo de cargas (LocalityLbPolicy) determina cómo se balancean las cargas de los backends dentro de la zona o del grupo. Cuando un servicio de backend recibe tráfico, primero lo dirige a un backend (bucket, grupo de instancias o NEG GCE_VM_IP_PORT) según el modo de balanceo del backend. Después de seleccionar un backend, el tráfico se distribuye entre instancias o extremos dentro de cada zona, en función de la política de localidad. En los grupos de instancias administrados regionales, la política de localidad se aplica a cada zona constituyente.

Para conocer los modos de balanceo admitidos, consulta Modos de balanceo.

Para obtener información sobre los algoritmos de la política de balanceo de cargas compatibles, consulta localityLbPolicy en la documentación de la API del servicio de backend global.

Afinidad de sesión (consistentHash)

Incluye afinidad basada en cookies HTTP, afinidad basada en encabezados HTTP, afinidad de direcciones IP de clientes y afinidad de cookie generada. La afinidad de sesión hace su mejor esfuerzo para enviar solicitudes de un cliente en particular al mismo backend, siempre que el backend esté en buen estado y tenga capacidad.

La configuración de afinidad de sesión se cumple solo si la política de localidad del balanceo de cargas se establece en RING_HASH o MAGLEV.

Para obtener más información sobre la afinidad de sesión, consulta consistentHash en la documentación de la API del servicio de backend regional.

Detección de valores atípicos (outlierDetection)

Un conjunto de políticas que especifican los criterios para retirar VM o extremos de backend en mal estado de los NEG, junto con criterios que definen cuándo un backend o extremo se considera lo bastante saludable como para volver a recibir tráfico.

Para obtener más información sobre la detección de valores atípicos, consulta outlierDetection en la documentación de la API del servicio de backend global.

¿Qué sigue?