Conmutación por error para balanceadores de cargas de aplicaciones externos

En esta página, se describe cómo funciona la conmutación por error en los balanceadores de cargas de aplicaciones externos. La configuración de conmutación por error implica dos balanceadores de cargas: un balanceador de cargas principal y un balanceador de cargas de resguardo. A los efectos de esta discusión, el balanceador de cargas principal es el balanceador de cargas para el que deseas configurar la conmutación por error. El balanceador de cargas de copia de seguridad es el balanceador de cargas que recibe conexiones cuando el balanceador de cargas principal comienza a fallar en las verificaciones de estado.

La conmutación por error y la conmutación por recuperación son los procesos automáticos que enrutan el tráfico hacia y desde un balanceador de cargas. Cuando Cloud DNS detecta una interrupción y enruta el tráfico del balanceador de cargas principal al balanceador de cargas de reserva, el proceso se denomina failover. Cuando Cloud DNS revierte esto y redirecciona el tráfico al balanceador de cargas principal, el proceso se denomina conmutación por recuperación.

Cómo funciona la conmutación por error

Para controlar la conmutación por error de global a regional en los balanceadores de cargas de aplicaciones externos, crea dos o más balanceadores de cargas de aplicaciones externos regionales en las regiones a las que deseas que se realice la conmutación por error del tráfico. Solo los balanceadores de cargas de aplicaciones externos regionales se pueden usar como balanceadores de cargas de reserva. Los balanceadores de cargas de aplicaciones externos regionales no solo son independientes dentro de regiones individuales de Google Cloud, sino que también están aislados de cualquier infraestructura de balanceador de cargas de aplicaciones externo global o balanceador de cargas de aplicaciones clásico que se ejecute en la misma región.

Los balanceadores de cargas de aplicaciones externos regionales funcionan mejor como balanceadores de cargas de conmutación por error para los balanceadores de cargas de aplicaciones externos globales, ya que ambos se basan en proxies de Envoy y procesan el tráfico de formas muy similares. Esto contrasta con un balanceador de cargas de aplicaciones clásico que tiene diferencias notables en la forma en que se maneja el tráfico.

En resumen, se admiten las siguientes situaciones de conmutación por error:

  • De un balanceador de cargas de aplicaciones externo global a un balanceador de cargas de aplicaciones externo regional
  • De un balanceador de cargas de aplicaciones externo regional a otro
  • De un balanceador de cargas de aplicaciones clásico a un balanceador de cargas de aplicaciones externo regional

Flujo de trabajo de conmutación por error y por recuperación

En la siguiente configuración, se muestra la conmutación por error de un balanceador de cargas de aplicaciones externo global a dos balanceadores de cargas de aplicaciones externos regionales, con uno en cada región donde el balanceador de cargas global implementó backends.

Conmutación por error de un balanceador de cargas de aplicaciones externo global a dos balanceadores de cargas de aplicaciones externos regionales
Conmutación por error de un balanceador de cargas de aplicaciones externo global a dos balanceadores de cargas de aplicaciones externos regionales (haz clic para ampliar).

En las siguientes secciones, se describe un flujo de trabajo típico con los diferentes componentes involucrados en una configuración de conmutación por error.

  1. Cómo detectar fallas en el balanceador de cargas principal

    Google Cloud usa verificaciones de estado para detectar si tu balanceador de cargas de aplicaciones externo principal está en buen estado. Configura estas verificaciones de estado para que envíen sondeos desde tres regiones de origen. Estas tres regiones de origen deben ser representativas de las regiones desde las que tus clientes accederán al balanceador de cargas. Por ejemplo, si tienes un balanceador de cargas de aplicaciones externo global y la mayor parte de tu tráfico de clientes proviene de Norteamérica y Europa, puedes configurar pruebas que se originen en dos regiones de Norteamérica y una región de Europa.

    Si fallan las verificaciones de estado que se originan en dos o más de estas regiones, se activa la conmutación por error al balanceador de cargas de aplicaciones externo regional de reserva.

    Notas adicionales:

    • Debes especificar exactamente tres regiones de origen cuando crees la verificación de estado. Solo las verificaciones de estado globales pueden especificar regiones de origen.
    • Se admiten las verificaciones de estado HTTP, HTTPS y TCP.
    • En realidad, los sondeos de verificación de estado se originan en un punto de presencia (PoP) en Internet dentro de una pequeña distancia de la región de origen de Google Cloud configurada.

  2. Enruta el tráfico a los balanceadores de cargas de copia de seguridad

    Si el balanceador de cargas principal comienza a fallar en las verificaciones de estado, Google Cloud usa las políticas de enrutamiento de conmutación por error de Cloud DNS para determinar cómo enrutar el tráfico a los balanceadores de cargas de reserva.

    La duración de la interrupción, o el tiempo que tarda el tráfico en conmutarse por error del balanceador de cargas principal a los de copia de seguridad, se determina según el valor de TTL de DNS, el intervalo de verificación de estado y el umbral de mal estado de la verificación de estado. Para conocer la configuración recomendada, consulta las Prácticas recomendadas.

  3. Conmutación por error al balanceador de cargas principal

    Después de que las verificaciones de estado vuelvan a realizarse correctamente, la conmutación por recuperación al balanceador de cargas principal se realiza automáticamente. No se espera tiempo de inactividad durante la conmutación por recuperación, ya que el balanceador de cargas principal y el de resguardo entregan tráfico.

  4. Cómo probar la conmutación por error de forma periódica

    Te recomendamos que pruebes el flujo de trabajo de conmutación por error de forma periódica como parte de tu plan de continuidad del negocio. Asegúrate de probar los cambios graduales y los instantáneos en el tráfico de los balanceadores de cargas principales a los de respaldo. Después de verificar que la conmutación por error funcione, activa una conmutación por recuperación para verificar que el tráfico se redireccione al balanceador de cargas principal como se espera.

Configurar la conmutación por error

Para configurar la conmutación por error, sigue estos pasos:

  1. Revisa la configuración del balanceador de cargas principal existente y verifica que las funciones (como las funciones de seguridad, las funciones de administración y enrutamiento de tráfico y CDN) usen el balanceador de cargas principal disponible con el balanceador de cargas de aplicaciones externo regional de copia de seguridad. Si no hay funciones similares disponibles, es posible que este balanceador de cargas no sea una buena opción para la conmutación por error.
  2. Crea el balanceador de cargas de aplicaciones externo regional de copia de seguridad con una configuración que refleje el balanceador de cargas principal tanto como sea posible.
  3. Crea la verificación de estado y la política de enrutamiento de DNS para detectar interrupciones y enrutar el tráfico del balanceador de cargas principal al de reserva durante la conmutación por error.

Revisa la configuración del balanceador de cargas principal

Antes de comenzar, verifica que el balanceador de cargas de aplicaciones externo regional de respaldo admita todas las funciones que se usan actualmente con tu balanceador de cargas principal.

Para evitar interrupciones en el tráfico, revisa las siguientes diferencias:

  • Implementaciones de GKE. Los usuarios de GKE deben tener en cuenta que los balanceadores de cargas implementados con la puerta de enlace de GKE son más compatibles con este mecanismo de conmutación por error que los balanceadores de cargas implementados con el controlador de Ingress de GKE. Esto se debe a que la puerta de enlace de GKE admite la configuración de los balanceadores de cargas de aplicaciones externos regionales y globales. Sin embargo, el controlador de Ingress de GKE solo es compatible con el balanceador de cargas de aplicaciones clásico.

    Para obtener los mejores resultados, usa la puerta de enlace de GKE para implementar el balanceador de cargas principal y el de copia de seguridad.

  • Cloud CDN. Los balanceadores de cargas de aplicaciones externos regionales no son compatibles con Cloud CDN. Por lo tanto, en caso de que se produzca una falla, las operaciones que dependan de Cloud CDN también se verán afectadas. Para obtener una mejor redundancia, recomendamos configurar una solución de CDN de terceros que pueda actuar como resguardo de Cloud CDN.

  • Google Cloud Armor. Si usas Google Cloud Armor para tu balanceador de cargas principal, asegúrate de configurar también las mismas funciones de Google Cloud Armor cuando configures el balanceador de cargas de aplicaciones externo regional de copia de seguridad. Google Cloud Armor tiene diferentes funciones disponibles a nivel regional y global. Para obtener más información, consulta las siguientes secciones de la documentación de Google Cloud Armor:

  • Certificados SSL. Si deseas usar un certificado SSL común para los balanceadores de cargas principales y de copia de seguridad, confirma que el tipo de certificado SSL que se usa con el balanceador de cargas principal sea compatible con el balanceador de cargas de aplicaciones externa regional de copia de seguridad. Revisa las diferencias entre los certificados SSL disponibles con los balanceadores de cargas globales, regionales y clásicos. Para obtener detalles, consulta las siguientes secciones:

  • Buckets de backend. Los balanceadores de cargas de aplicaciones externos regionales no admiten buckets de Cloud Storage como backends. No puedes configurar la conmutación por error para los balanceadores de cargas con buckets de backend.

Configura el balanceador de cargas de respaldo

El balanceador de cargas de copia de seguridad es un balanceador de cargas de aplicaciones externo regional que configuras en la región en la que deseas que se redireccione el tráfico en caso de falla.

Ten en cuenta las siguientes consideraciones cuando configures tu balanceador de cargas de respaldo:

  • Debes configurar las funciones del balanceador de cargas de aplicaciones externo regional de copia de seguridad para que sean lo más similares posible al balanceador de cargas principal, de modo que el tráfico se procese de manera similar en ambas implementaciones.

    • Balanceador de cargas de aplicaciones externo global Los balanceadores de cargas de aplicaciones externos regionales admiten la mayoría de las mismas funciones que los balanceadores de cargas de aplicaciones externos globales, con algunas excepciones. El balanceador de cargas regional también admite las mismas funciones avanzadas de administración de tráfico que el balanceador de cargas global, lo que facilita lograr la equivalencia entre los balanceadores de cargas principal y de copia de seguridad.

    • Balanceador de cargas de aplicaciones clásico Con el balanceador de cargas de aplicaciones clásico, es más difícil lograr la paridad de funciones entre el balanceador de cargas principal y el de copia de seguridad, ya que el balanceador de cargas de aplicaciones externo regional es un balanceador de cargas basado en Envoy que procesa el tráfico de manera diferente. Asegúrate de probar la conmutación por error y la recuperación antes de realizar la implementación en producción.

    Para ver las capacidades específicas de los balanceadores de cargas de aplicaciones regionales, globales y clásicos, consulta la página de comparación de funciones del balanceador de cargas.

    Te recomendamos que uses un framework de automatización, como Terraform, para lograr y mantener la coherencia en las configuraciones del balanceador de cargas en las implementaciones principales y de copia de seguridad.

  • Te recomendamos que configures balanceadores de cargas de aplicaciones externos regionales de respaldo en cada región en la que tengas backends. Por ejemplo, si realizas la conmutación por error de una implementación global con grupos de instancias en cinco regiones para crear una copia de seguridad de los balanceadores de cargas regionales solo en tres regiones, corres el riesgo de sobrecargar tus servicios de backend en estas tres regiones mientras los servicios de backend de las dos regiones restantes están inactivos.

    Además, te recomendamos que configures Cloud DNS para que use políticas round robin ponderadas cuando redireccionas el tráfico de conmutación por error de un balanceador de cargas global principal a estos balanceadores de cargas regionales de reserva. Asigna ponderaciones a cada balanceador de cargas de resguardo teniendo en cuenta los tamaños máximos de los grupos de instancias de backend en diferentes regiones.

  • Los balanceadores de cargas de aplicaciones externos regionales admiten los Niveles de servicio de red Premium y Estándar. Si la latencia no es tu principal preocupación durante la conmutación por error, te recomendamos que configures los balanceadores de cargas de aplicaciones externos regionales de respaldo con el nivel estándar. El uso de la infraestructura del nivel estándar ofrece aislamiento adicional de la infraestructura del nivel Premium que usan los balanceadores de cargas de aplicaciones externos globales.

  • Si deseas usar los mismos backends para los balanceadores de cargas principales y de copia de seguridad, crea el balanceador de cargas de aplicaciones externo regional de copia de seguridad en la región donde se encuentran los backends. Si habilitaste el ajuste de escala automático para los grupos de instancias de backend, debes cumplir con los requisitos para compartir backends en todas las implementaciones.

  • Si es necesario, reserva proxies de Envoy adicionales para los balanceadores de cargas de aplicaciones externos regionales para garantizar que, en caso de un evento de conmutación por error, el tráfico adicional no interrumpa ninguna otra implementación de balanceador de cargas en la misma región. Para obtener más información, consulta Cómo reservar capacidad adicional de subred de solo proxy.

Si deseas obtener información para configurar un balanceador de cargas de aplicaciones externo regional, consulta Configura un balanceador de cargas de aplicaciones externo regional con backends de grupos de instancias de VM.

Reserva capacidad adicional de subred de solo proxy

Todos los balanceadores de cargas regionales basados en Envoy en una región y red de VPC comparten el mismo grupo de proxies de Envoy. En un evento de conmutación por error, los balanceadores de cargas de aplicaciones externos regionales de resguardo observan un aumento en el uso de proxy para controlar el tráfico de conmutación por error del balanceador de cargas principal. Para garantizar que la capacidad siempre esté disponible para los balanceadores de cargas de copia de seguridad, te recomendamos que revises el tamaño de tu subred de solo proxy. Te recomendamos que calcules la cantidad estimada de proxies necesarios para controlar el tráfico en una región determinada y aumentes la capacidad si es necesario. Esto también ayuda a garantizar que los eventos de conmutación por error no interrumpan otros balanceadores de cargas regionales basados en Envoy en la misma región y red.

Por lo general, un proxy de balanceador de cargas de aplicaciones externo regional puede administrar hasta lo siguiente:

  • 600 (HTTP) o 150 (HTTPS) conexiones nuevas por segundo
  • 3,000 conexiones activas
  • 1,400 solicitudes por segundo

Si usas políticas de DNS para dividir el tráfico entre varios balanceadores de cargas de respaldo en diferentes regiones, debes tener en cuenta esto cuando estimes los requisitos de proxy por región y red. Una subred de solo proxy más grande permite que Google Cloud asigne una mayor cantidad de proxies de Envoy a tu balanceador de cargas cuando sea necesario.

No puedes expandir una subred de solo proxy de la misma manera que lo harías para un rango de direcciones principal (con el comando expand-ip-range). En su lugar, debes crear una subred de solo proxy de copia de seguridad que satisfaga tus necesidades y, luego, promoverla al rol activo.

Para obtener información sobre cómo cambiar el tamaño de tu subred de solo proxy, consulta Cambia el tamaño o el rango de direcciones de una subred de solo proxy.

Cómo compartir backends entre balanceadores de cargas principales y de resguardo

Para lograr una redundancia de infraestructura completa, debes introducir redundancia tanto a nivel del balanceador de cargas como a nivel del backend. Esto significa que debes configurar tus balanceadores de cargas de aplicaciones externos regionales de reserva con backends (grupos de instancias o grupos de extremos de red) que no se superpongan con los balanceadores de cargas principales.

Sin embargo, si quieres compartir un grupo de instancias de backend entre el balanceador de cargas principal y el secundario, y el ajuste de escala automático está habilitado para los grupos de instancias, debes cumplir con los siguientes requisitos para garantizar que se produzca una conmutación por error correcta:

  • El escalador automático debe configurarse solo con el escalamiento basado en la CPU. No se admite el método de escalamiento basado en el uso del balanceador de cargas.
  • Los servicios de backend globales y regionales deben usar solo el modo de balanceo UTILIZATION. No se recomienda usar el modo de balanceo RATE porque tus instancias podrían recibir el doble de tráfico de los balanceadores de cargas globales y regionales durante el proceso de conmutación por error.
  • Se deben configurar los controles de escalamiento para evitar que el escalador automático reduzca el grupo de forma prematura durante el tiempo de inactividad cuando el tráfico cambia del balanceador de cargas global al balanceador de cargas regional. Este tiempo de inactividad puede ser tan alto como la suma del TTL de DNS más el intervalo de verificación de estado configurado.

Si no configuras el ajuste de escala automático correctamente, es posible que se produzca una interrupción secundaria durante la conmutación por error, ya que la pérdida de tráfico del balanceador de cargas global hace que el grupo de instancias se reduzca rápidamente.

Configura Cloud DNS y las verificaciones de estado

En esta sección, se describe cómo usar Cloud DNS y verificaciones de estado de Google Cloud para configurar tu entorno de Cloud Load Balancing de modo que detecte interrupciones y enrute el tráfico a los balanceadores de cargas de reserva.

Sigue estos pasos para configurar las políticas de verificación de estado y enrutamiento requeridas:

  1. Crea una verificación de estado para la dirección IP de la regla de reenvío del balanceador de cargas principal.

    gcloud beta compute health-checks create http HEALTH_CHECK_NAME \
    --global \
    --source-regions=SOURCE_REGION_1,SOURCE_REGION_2,SOURCE_REGION_3 \
    --use-serving-port \
    --check-interval=HEALTH_CHECK_INTERVAL \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --request-path=REQUEST_PATH

    Reemplaza lo siguiente:

    • HEALTH_CHECK_NAME: el nombre de la verificación de estado.
    • SOURCE_REGION: Las tres regiones de Google Cloud desde las que se realizan las verificaciones de estado Debes especificar examente tres regiones de origen.
    • HEALTH_CHECK_INTERVAL: Es la cantidad de tiempo en segundos desde el inicio de un sondeo emitido por un sistema de sondeo hasta el inicio del siguiente sondeo emitido por el mismo sistema de sondeo. El valor mínimo admitido es de 30 segundos. Para conocer los valores recomendados, consulta las Prácticas recomendadas.
    • HEALTHY_THRESHOLD y UNHEALTHY_THRESHOLD: Es la cantidad de sondeos secuenciales que deben tener éxito o fallar para que la instancia de VM se considere en buen o mal estado. Si se omite alguno, Google Cloud usa un umbral predeterminado de 2.
    • REQUEST_PATH: Especifica la ruta de URL a la que Google Cloud envía las solicitudes de sondeo de verificación de estado. Si se omite, Google Cloud enviará las solicitudes de sondeo a la ruta raíz, /. Si los extremos a los que se les realiza la verificación de estado son privados, lo que no es habitual para las direcciones IP de las reglas de reenvío externas, puedes establecer esta ruta en /afhealthz.

  2. Crea un conjunto de registros de Cloud DNS en Cloud DNS y aplícale una política de enrutamiento. La política de enrutamiento debe configurarse para resolver el nombre de dominio a la dirección IP de la regla de reenvío del balanceador de cargas principal o, en caso de una falla de verificación de estado, a una de las direcciones IP de la regla de reenvío de los balanceadores de cargas de copia de seguridad.

    gcloud beta dns record-sets create DNS_RECORD_SET_NAME \
    --ttl=TIME_TO_LIVE \
    --type=RECORD_TYPE \
    --zone="MANAGED_ZONE_NAME" \
    --routing-policy-type=FAILOVER \
    --routing-policy-primary-data=PRIMARY_LOAD_BALANCER_FORWARDING_RULE \
    --routing-policy-backup-data_type=GEO \
    --routing-policy-backup-data="BACKUP_REGION_1=BACKUP_LOAD_BALANCER_1_IP_ADDRESS[;BACKUP_REGION_2=BACKUP_LOAD_BALANCER_2_IP_ADDRESS;BACKUP_REGION_3=BACKUP_LOAD_BALANCER_3_IP_ADDRESS]" \
    --health-check=HEALTH_CHECK_NAME \
    --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO

    Reemplaza lo siguiente:

    • DNS_RECORD_SET_NAME: el nombre de dominio o DNS del conjunto de registros que se agregará, por ejemplo, test.example.com
    • TIME_TO_LIVE: el tiempo de actividad (TTL) para el conjunto de registros en cantidad de segundos. Para conocer los valores recomendados, consulta las Prácticas recomendadas.
    • RECORD_TYPE: el tipo de registro, por ejemplo, A
    • MANAGED_ZONE_NAME: El nombre de la zona administrada cuyos conjuntos de registros quieres administrar, por ejemplo, my-zone-name
    • PRIMARY_LOAD_BALANCER_FORWARDING_RULE: el nombre de la regla de reenvío del balanceador de cargas principal.
    • BACKUP_REGION: Las regiones en las que se implementan los balanceadores de cargas de copia de seguridad
    • BACKUP_LOAD_BALANCER_IP_ADDRESS: las direcciones IP de la regla de reenvío de los balanceadores de cargas de copia de seguridad correspondientes a cada región
    • BACKUP_DATA_TRICKLE_RATIO: Es la proporción de tráfico que se enviará a los balanceadores de cargas de copia de seguridad, incluso cuando el balanceador de cargas principal esté en buen estado. La proporción debe estar entre 0 y 1, como 0.1. El valor predeterminado es 0.

Prácticas recomendadas

Estas son algunas prácticas recomendadas que debes tener en cuenta cuando configures el registro de Cloud DNS y las verificaciones de estado:

  • El tiempo que tarda el tráfico en conmutar por error del balanceador de cargas principal a los de copia de seguridad (es decir, la duración de la interrupción) depende del valor de TTL de DNS, el intervalo de verificación de estado y los límites de la verificación de estado parámetro de umbral de mal estado.

    Con Cloud DNS de Google, el límite superior de este período se puede calcular con la siguiente fórmula:

    Duration of outage = DNS TTL + Health Check Interval * Unhealthy Threshold

    Para la configuración de conmutación por error, te recomendamos que configures el TTL de DNS entre 30 y 60 segundos. Los TTL más altos generan tiempos de inactividad más largos, ya que los clientes en Internet continúan accediendo a los balanceadores de cargas de aplicaciones externos principales incluso después de que el DNS falló en el balanceador de cargas de aplicaciones externo regional de reserva.

  • Configura los parámetros de umbral de buen y mal estado en las verificaciones de estado para evitar conmutaciones por error innecesarias causadas por errores transitorios. Los umbrales más altos aumentan el tiempo que tarda el tráfico en conmutarse por error a los balanceadores de cargas de reserva.

  • Para garantizar que la configuración de la conmutación por error funcione como se espera, puedes configurar tu política de enrutamiento de DNS para enviar siempre un pequeño porcentaje de tráfico a los balanceadores de cargas de copia de seguridad, incluso cuando los balanceadores de cargas principales estén en buen estado. Para ello, puedes usar el parámetro --backup-data-trickle-ratio cuando crees el conjunto de registros DNS.

    Puedes configurar el porcentaje del tráfico que se envía a la copia de seguridad como una fracción de 0 a 1. El valor típico es 0.1, aunque Cloud DNS te permite enviar el 100% del tráfico a las direcciones VIP de reserva para activar manualmente un resguardo.