Alta disponibilidad para balanceadores de cargas de aplicaciones externos regionales

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

Estrategias de alta disponibilidad

Puedes implementar la resiliencia entre regiones para los balanceadores de cargas de aplicaciones externos regionales con una de las siguientes estrategias:

  • Activo-pasivo (conmutación por error regional): Implementa un balanceador de cargas de aplicaciones externo regional principal en tu región principal y uno o más balanceadores de cargas de aplicaciones externos regionales de copia de seguridad en regiones secundarias. En estado estable, Cloud DNS enruta todo el tráfico al balanceador de cargas principal. Si el balanceador de cargas principal falla en las verificaciones de estado, Cloud DNS usa una política de enrutamiento de conmutación por error para enrutar el tráfico a los balanceadores de cargas regionales de copia de seguridad.

    Esta es una configuración activa-pasiva de muestra que muestra dos balanceadores de cargas de aplicaciones externos regionales en dos regiones diferentes.

Alta disponibilidad con dos balanceadores de cargas de aplicaciones externos regionales.
Alta disponibilidad con dos balanceadores de cargas de aplicaciones externos regionales (haz clic para ampliar).

  • Activo-activo (enrutamiento por proximidad): Implementa varios balanceadores de cargas de aplicaciones externos regionales en diferentes regiones que atiendan el tráfico de forma simultánea. Usa una política de enrutamiento de ubicación geográfica de Cloud DNS para dirigir a los clientes a la región en buen estado más cercana. Si un balanceador de cargas en una región experimenta una interrupción, Cloud DNS enruta automáticamente el tráfico desde la región en mal estado a los balanceadores de cargas en buen estado en otras regiones.

    Esta es una configuración de muestra activa-activa que muestra dos balanceadores de cargas de aplicaciones externos regionales en dos regiones diferentes.

    Alta disponibilidad con dos balanceadores de cargas de aplicaciones externos regionales.
    Alta disponibilidad con dos balanceadores de cargas de aplicaciones externos regionales (haz clic para ampliar).

En las siguientes secciones, se describe cómo funcionan las verificaciones de estado y el redireccionamiento del tráfico en las regiones en un flujo de trabajo típico:

  1. Usa verificaciones de estado para detectar fallas regionales

    Google Cloud usa verificaciones de estado para detectar si tus balanceadores de cargas regionales 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 según las políticas de enrutamiento

    • Activa-pasiva: Cloud DNS usa una política de enrutamiento de conmutación por error para dirigir el 100% del tráfico de clientes al balanceador de cargas regional principal durante el estado estable. Cuando el balanceador de cargas regional principal falla en las verificaciones de estado, Cloud DNS dirige el tráfico a los balanceadores de cargas regionales de copia de seguridad.
    • Activo-activo: Cloud DNS usa una política de enrutamiento de ubicación geográfica 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 geográficamente más cercano al cliente. Cuando un balanceador de cargas de una región comienza a fallar en las verificaciones de estado, el tráfico se dirige automáticamente a los balanceadores de cargas en buen estado disponibles en otras regiones.

  3. Conmuta por error al balanceador de cargas principal

    La conmutación por recuperación es automática cuando las verificaciones de estado vuelven a realizarse correctamente. El tráfico se restablece sin tiempo de inactividad porque los balanceadores de cargas están publicando tráfico.

Configura el balanceo de cargas multirregión

Para configurar una implementación multirregional que facilite la alta disponibilidad, sigue estos pasos:

  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 administración del tráfico y seguridad.
  2. Crea verificaciones de estado para supervisar las direcciones IP de las reglas de reenvío de tus balanceadores de cargas regionales.
  3. Configura tu política de enrutamiento de DNS en Cloud DNS:

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 procese la solicitud. Por ejemplo, asegúrate de usar el mismo tipo de certificado SSL, las mismas políticas de seguridad regionales de Cloud Armor y la misma configuración de enrutamiento del mapa de URL 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 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.

Crea la verificación de estado

Crea una verificación de estado global para supervisar la dirección IP externa de la regla de reenvío de cada balanceador de cargas regional:

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_1, SOURCE_REGION_2 y SOURCE_REGION_3: Son las tres regiones de Google Clouddesde 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 el balanceador de cargas 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.

Configura la conmutación por error regional activa-pasiva

En Cloud DNS, crea un conjunto de registros y aplica una política de enrutamiento FAILOVER para enviar tráfico en estado estable al balanceador de cargas regional principal y conmutar por error al balanceador de cargas regional de copia de seguridad durante una interrupción:

gcloud 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_REGIONAL_FORWARDING_RULE \
    --routing-policy-backup-data_type=GEO \
    --routing-policy-backup-data="BACKUP_REGION_1=BACKUP_LOAD_BALANCER_1_IP[;BACKUP_REGION_2=BACKUP_LOAD_BALANCER_2_IP]" \
    --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: Es el TTL en segundos del registro. 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 tu zona administrada de Cloud DNS, por ejemplo, my-zone-name
  • PRIMARY_REGIONAL_FORWARDING_RULE: El nombre de la regla de reenvío del balanceador de cargas de aplicaciones externo regional principal
  • BACKUP_REGION_1 y BACKUP_REGION_2: Las regiones en las que se implementan los balanceadores de cargas de aplicaciones externos regionales de copia de seguridad
  • BACKUP_LOAD_BALANCER_1_IP y BACKUP_LOAD_BALANCER_2_IP: Direcciones IP externas de las reglas de reenvío de los balanceadores de cargas de aplicaciones externos regionales de copia de seguridad
  • HEALTH_CHECK_NAME: el nombre de la verificación de estado.
  • BACKUP_DATA_TRICKLE_RATIO: Es la fracción de tráfico (de 0 a 1, como 0.1) que se enviará al balanceador de cargas regional de copia de seguridad durante el estado estable para garantizar que la copia de seguridad esté preparada y lista. El valor predeterminado es 0.

Configura el enrutamiento de regiones activo-activo

En Cloud DNS, crea un conjunto de registros y aplica una política de enrutamiento por ubicación geográfica para dirigir el tráfico de forma simultánea a través de balanceadores de cargas regionales en buen estado:

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 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
  • FORWARDING_RULE_NAME_A, FORWARDING_RULE_NAME_B y FORWARDING_RULE_NAME_C: Son los nombres de las reglas de reenvío de los balanceadores de cargas en cada región correspondiente.
  • REGION_A, REGION_B y REGION_C: Las regiones en las que se implementa cada balanceador de cargas
  • HEALTH_CHECK_NAME: el nombre de la verificación de estado.

Prácticas recomendadas

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

  • Calcula la duración de la interrupción: El tiempo que tarda el tráfico en enrutarse desde los balanceadores de cargas en mal estado hasta los de buen estado (la duración de la interrupción) depende del valor de TTL de DNS, el intervalo de verificación de estado y el parámetro de límite de la verificación de estado de umbral de mal estado:

    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 porque 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 umbrales de verificación de estado: Configura los parámetros de umbral de buen estado y mal estado para evitar 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.

  • Usa el tráfico de goteo para la validación activa-pasiva: En las configuraciones activa-pasiva, configura la marca --backup-data-trickle-ratio para enviar continuamente un pequeño porcentaje de tráfico (por ejemplo, 0.1) al balanceador de cargas regional de copia de seguridad durante el estado estable. Esto verifica que la infraestructura de copias de seguridad esté activa y lista para controlar el tráfico durante un evento de conmutación por error.