Alta disponibilidad para balanceadores de cargas de aplicaciones externos regionales

En esta página, se describe cómo configurar una implementación de 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.

Importante: La configuración multirregional de alta disponibilidad que se describe en esta página es una configuración activa-activa en la que implementas varios balanceadores de cargas en diferentes regiones que atienden el tráfico de forma simultánea. Se puede configurar una implementación activa-activa con una política de enrutamiento de ubicación geográfica de Cloud DNS. Los balanceadores de cargas de aplicaciones externos regionales también admiten una configuración activa-pasiva en la que el tráfico conmuta por error a un balanceador de cargas de copia de seguridad solo cuando el balanceador de cargas principal no está disponible. Se puede configurar una implementación activa-pasiva con una política de enrutamiento de conmutación por error de Cloud DNS. Para obtener más información, consulta Conmutación por error para balanceadores de cargas de aplicaciones externos.

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

Alta disponibilidad con 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 esta configuración.

1. Usa verificaciones de estado para detectar fallas regionales

   Google Cloud usa verificaciones de estado para detectar si tus balanceadores de cargas están en buen estado. Configuras estas verificaciones de estado para enviar sondeos desde tres regiones de origen. Estas tres regiones de origen deben ser representativas de las regiones desde las que tus clientes acceden a los balanceadores de cargas. Por ejemplo, si tienes un balanceador de cargas de aplicaciones externo regional con la mayoría del tráfico de clientes que se origina en América del Norte y Europa, puedes tener sondeos que se originen en dos o más regiones de América del Norte y sondeos que se originen en 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.
   • Los sondeos de verificación de estado se originan en un punto de presencia (PoP) en Internet a una distancia pequeña de la región de origen Google Cloudconfigurada.

2. Cómo enrutar el tráfico a 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 en las verificaciones de estado, el tráfico se enruta a los balanceadores de cargas disponibles en buen estado en otras regiones.

3. Vuelve a usar todos los balanceadores de cargas

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

Configura el balanceo de cargas entre regiones

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

1. Crea balanceadores de cargas de aplicaciones externos regionales en las regiones que consideres que mejor admiten 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 del 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 para 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 del balanceador de cargas que entregue la solicitud. Por ejemplo, debes asegurarte de usar el mismo tipo de certificado SSL, las mismas políticas de 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 consideres que admitirá mejor 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 las Google Cloud verificaciones de estado para configurar tu entorno de Cloud Load Balancing de modo que detecte interrupciones y enrute el tráfico a balanceadores de cargas en otras regiones.

Sigue estos pasos para configurar las políticas de enrutamiento y verificación de estado 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 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: Son las tres Google Cloudregiones desde las que se envían los sondeos de verificación 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 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: Es la ruta de URL a la queGoogle Cloud envía solicitudes de sondeo de verificación de estado. Si se omite, Google Cloud envía 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 como /afhealthz.

2. En Cloud DNS, crea un conjunto de registros y aplícale una política de enrutamiento de ubicación geográfica.

   gcloud 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: Es el tiempo de actividad (TTL) del registro en segundos. Para conocer los valores recomendados, consulta Consideraciones sobre el 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: Son 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 prolongados, ya que los clientes de Internet siguen accediendo a los balanceadores de cargas en mal estado incluso después de que el DNS conmutó por error a otras regiones.

• Configura los parámetros de 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.