Alta disponibilidad para balanceadores de cargas de aplicaciones externos regionales

En esta página, se describe cómo configurar una implementación con alta disponibilidad con balanceadores de cargas de aplicaciones externos regionales. Para lograr la alta disponibilidad, implementa varios balanceadores de cargas de aplicaciones externos regionales individuales en las regiones que mejor admitan el tráfico de tu aplicación. Esto funciona porque los balanceadores de cargas de aplicaciones externos regionales en distintas regiones no solo están aislados entre sí, 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.

Usa una política de enrutamiento de ubicación geográfica de Cloud DNS para enrutar el tráfico a dos o más balanceadores de cargas en diferentes regiones. La política enruta el tráfico a la región disponible más cercana según el origen de la solicitud del cliente. También te recomendamos que uses verificaciones de estado para que Google Cloud pueda detectar cualquier interrupción regional y enrutar el tráfico solo a los balanceadores de cargas en buen estado.

Esta es una configuración de muestra que muestra dos balanceadores de cargas de aplicaciones externos regionales en dos regio￳nes diferentes.

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

1. Cómo usar las verificaciones de estado para detectar fallas regionales

   Google Cloud usa verificaciones de estado para detectar si los balanceadores de cargas están en buen estado. Configura estas verificaciones de estado para enviar sondeos desde tres regiones de origen. Estas tres regiones de origen deben representar las regiones desde las que los clientes acceden a los balanceadores de cargas. Por ejemplo, si tienes un balanceador de cargas de aplicaciones externo regional y la mayor parte del tráfico de tu cliente se origina en Norteamérica y Europa, puedes tener sondeos que se originen en dos o más regiones en Norteamérica y sondeos que proviene de dos o más regiones de Europa.

   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 en buen estado

   Google Cloud usa una política de enrutamiento de ubicación geográfica de Cloud DNS para dirigir el tráfico a los balanceadores de cargas. Cuando todos los balanceadores de cargas están en buen estado, Cloud DNS enruta el tráfico al balanceador de cargas que está geográficamente más cerca del origen de la solicitud del cliente.

   Cuando un balanceador de cargas en una región en particular comienza a fallar las verificaciones de estado, el tráfico se enruta a los balanceadores de cargas en buen estado disponibles en otras regiones.

3. Vuelve a usar todos los balanceadores de cargas

   La conmutación por error es automática cuando las verificaciones de estado vuelven a realizarse correctamente. No se espera ningún tiempo de inactividad durante la conmutación por error, ya que todos los balanceadores de cargas disponibles entregan tráfico.

Configura el balanceo de cargas entre regiones

Sigue estos pasos para configurar una implementación entre regiones que facilite la alta disponibilidad:

1. Crea balanceadores de cargas de aplicaciones externos regionales en las regiones que consideres que admiten mejor el tráfico de tu aplicación. Cada uno de estos balanceadores de cargas debe tener la misma configuración de seguridad y administración de tráfico.
2. Crea la verificación de estado y la política de enrutamiento de DNS para dirigir el tráfico a los balanceadores de cargas según la ubicación del cliente y desviar el tráfico de un balanceador de cargas en mal estado en caso de una interrupción.

Crea balanceadores de cargas en varias regiones

Ten en cuenta las siguientes consideraciones cuando configures tus balanceadores de cargas redundantes adicionales:

• Configura todos los balanceadores de cargas de aplicaciones externos regionales con funciones similares para que el tráfico se procese de manera coherente, independientemente de qué balanceador de cargas entregue la solicitud. Por ejemplo, debes asegurarte de usar el mismo tipo de certificado SSL, las mismas políticas de Google Cloud Armor y la misma configuración de administración de tráfico para todos los balanceadores de cargas de aplicaciones externos regionales.

  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 diferentes implementaciones regionales.

• Te recomendamos que configures balanceadores de cargas de aplicaciones externos regionales en cada región que determines que sería la más adecuada para admitir el tráfico de tu aplicación.

• Los balanceadores de cargas de aplicaciones externos regionales admiten los Niveles de servicio de red Premium y Estándar. Te recomendamos que configures los balanceadores de cargas de aplicaciones externos regionales adicionales en el nivel Premium para garantizar una latencia baja.

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.

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 Balanceo de cargas de Cloud de modo que detecte interrupciones y enrute el tráfico a balanceadores de cargas en otras regiones.

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

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 envían los sondeos de 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 obtener valores recomendados, consulta Prácticas recomendadas.
   • HEALTHY_THRESHOLD y UNHEALTHY_THRESHOLD especifican 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 que se verifican 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. En Cloud DNS, crea un conjunto de registros y aplícale una política de enrutamiento de ubicación geográfica.

   gcloud beta dns record-sets create DNS_RECORD_SET_NAME \
       --ttl=TIME_TO_LIVE \
       --type=RECORD_TYPE \
       --zone="MANAGED_ZONE_NAME" \
       --routing-policy-type="GEO" \
       --routing-policy-data="FORWARDING_RULE_NAME_A@REGION_A;FORWARDING_RULE_NAME_B@REGION_B[,;FORWARDING_RULE_NAME_C@REGION_C]" \
       --health-check=HEALTH_CHECK_NAME
   

   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), en segundos, para el registro. Para conocer los valores recomendados, consulta Consideraciones de DNS.
   • 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
   • FORWARDING_RULE_NAME: los nombres de las reglas de reenvío del balanceador de cargas en cada REGION
   • REGION: las regiones en las que se implementa cada balanceador de cargas

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 enrutarse desde los balanceadores de cargas en mal estado hasta los de buen estado (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
  

  Te recomendamos que configures el TTL de DNS en un valor de entre 30 y 60 segundos. Los TTL más altos generan tiempos de inactividad más largos, ya que los clientes de Internet siguen accediendo a los balanceadores de cargas que no están en buen estado, incluso después de que el DNS falló en otras regiones.

• Configura los parámetros del umbral de buen estado y mal estado en las verificaciones de estado de modo que evites el redireccionamiento innecesario y abrupto del tráfico debido a errores transitorios. Los umbrales más altos aumentan el tiempo que tarda el tráfico en cambiar a los balanceadores de cargas en otras regiones.