En esta página se describe cómo configurar una implementación de alta disponibilidad con balanceadores de carga de aplicación externos regionales. Para conseguir una alta disponibilidad, despliega varios balanceadores de carga de aplicación externos regionales individuales en las regiones que mejor se adapten al tráfico de tu aplicación. Esto funciona porque los balanceadores de carga de aplicación externos regionales de diferentes regiones no solo están aislados entre sí, sino que también están aislados de cualquier infraestructura de balanceador de carga de aplicación externo global o de balanceador de carga de aplicación clásico que se ejecute en la misma región.
Usa una política de enrutamiento por geolocalización de Cloud DNS para dirigir el tráfico a dos o más balanceadores de carga en diferentes regiones. La política dirige el tráfico a la región disponible más cercana en función del origen de la solicitud del cliente. También te recomendamos que uses comprobaciones de estado para que Google Cloud pueda detectar cualquier interrupción regional y dirigir el tráfico solo a los balanceadores de carga en buen estado.
A continuación, se muestra una configuración de ejemplo con dos balanceadores de carga de aplicaciones externos regionales en dos regiones diferentes.
En las secciones siguientes se describe un flujo de trabajo habitual con los diferentes componentes implicados en esta configuración.
Usar comprobaciones del estado para detectar fallos regionales
Google Cloud usa comprobaciones del estado para detectar si tus balanceadores de carga están en buen estado. Configura estas comprobaciones del 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 carga. Por ejemplo, si tiene un balanceador de carga de aplicaciones externo regional y la mayoría del tráfico de sus clientes procede de Norteamérica y Europa, puede tener sondeos procedentes de dos o más regiones de Norteamérica y sondeos procedentes de dos o más regiones de Europa.
Notas adicionales:
- Debe especificar exactamente tres regiones de origen cuando cree la comprobación de estado. Solo las comprobaciones del estado globales pueden especificar regiones de origen.
- Se admiten comprobaciones del estado HTTP, HTTPS y TCP.
- Las sondas de comprobación de estado proceden de un punto de presencia (PoP) de Internet que se encuentra a una distancia reducida de la región de origen Google Cloudconfigurada.
Dirigir el tráfico a balanceadores de carga en buen estado
Google Cloud usa una política de enrutamiento por geolocalización de Cloud DNS para dirigir el tráfico a los balanceadores de carga. Cuando todos los balanceadores de carga están en buen estado, Cloud DNS dirige el tráfico al balanceador de carga que esté geográficamente más cerca del origen de la solicitud del cliente.
Cuando un balanceador de carga de una región concreta empieza a fallar en las comprobaciones del estado, el tráfico se dirige a los balanceadores de carga disponibles y en buen estado de otras regiones.
Volver a usar todos los balanceadores de carga
La conmutación por recuperación es automática cuando las comprobaciones de estado vuelven a dar resultados positivos. No se espera que haya tiempo de inactividad durante la conmutación por recuperación, ya que todos los balanceadores de carga disponibles están sirviendo tráfico.
Configurar el balanceo de carga interregional
Sigue estos pasos para configurar una implementación entre regiones que facilite la alta disponibilidad:
- Crea balanceadores de carga de aplicación externos regionales en las regiones que consideres que mejor admiten el tráfico de tu aplicación. Cada uno de estos balanceadores de carga debe tener la misma configuración de gestión del tráfico y de seguridad.
- Crea la comprobación del estado y la política de enrutamiento de DNS para dirigir el tráfico a los balanceadores de carga en función de la ubicación del cliente y para desviar el tráfico de un balanceador de carga que no esté en buen estado en caso de interrupción.
Crear balanceadores de carga en varias regiones
Ten en cuenta lo siguiente al configurar los balanceadores de carga redundantes adicionales:
Configura todos los balanceadores de carga de aplicación externos regionales con funciones similares para que el tráfico se procese de forma coherente, independientemente del balanceador de carga que atienda la solicitud. Por ejemplo, debes asegurarte de que usas el mismo tipo de certificado SSL, las mismas políticas de Cloud Armor y los mismos ajustes de gestión del tráfico en todos los balanceadores de carga de aplicaciones externos regionales.
Te recomendamos que utilices un framework de automatización como Terraform para conseguir y mantener la coherencia en las configuraciones de balanceadores de carga en las diferentes implementaciones regionales.
Te recomendamos que configures balanceadores de carga de aplicaciones externos regionales en cada región que consideres que se adapta mejor al tráfico de tu aplicación.
Los balanceadores de carga de aplicaciones externos regionales admiten los niveles de servicio de red Premium y Estándar. Te recomendamos que configures los balanceadores de carga de aplicaciones externos regionales adicionales en el nivel Premium para asegurar una latencia baja.
Para saber cómo configurar un balanceador de carga de aplicación externo regional, consulta Configurar un balanceador de carga de aplicación externo regional con backends de grupos de instancias de máquina virtual.
Configurar Cloud DNS y comprobaciones de estado
En esta sección se describe cómo usar Cloud DNS y las Google Cloud comprobaciones de estado para configurar tu entorno de Cloud Load Balancing de forma que detecte las interrupciones y dirija el tráfico a los balanceadores de carga de otras regiones.
Sigue estos pasos para configurar las políticas de comprobación del estado y de enrutamiento necesarias:
Crea una comprobación del estado para la dirección IP de la regla de reenvío del balanceador de carga 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_PATHHaz los cambios siguientes:
HEALTH_CHECK_NAME: el nombre de la comprobación del estadoSOURCE_REGION: las tres Google Cloud regiones desde las que se envían las sondas de comprobación del estado. Debes especificar exactamente tres regiones de origen.HEALTH_CHECK_INTERVAL: la cantidad de tiempo en segundos desde el inicio de una sonda emitida por un comprobador hasta el inicio de la siguiente sonda emitida por el mismo comprobador. El valor mínimo admitido es de 30 segundos. Para ver los valores recomendados, consulta las prácticas recomendadas.HEALTHY_THRESHOLDyUNHEALTHY_THRESHOLD: especifica el número de sondeos secuenciales que deben completarse correctamente o fallar para que la instancia de VM se considere en buen estado o en mal estado. Si se omite alguno de los dos, Google Cloud usa un umbral predeterminado de 2.REQUEST_PATH: la ruta de URL a la queGoogle Cloud envía solicitudes de comprobación del estado. Si se omite, Google Cloud envía solicitudes de sondeo a la ruta raíz,/. Si los endpoints cuya salud se está comprobando son privados, lo que no es habitual en las direcciones IP de las reglas de reenvío externas, puedes definir esta ruta como/afhealthz.
En Cloud DNS, crea un conjunto de registros y aplícale una política de enrutamiento por geolocalización.
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_NAMEHaz los cambios siguientes:
DNS_RECORD_SET_NAME: el nombre de dominio o DNS del conjunto de registros que se va a añadir. Por ejemplo,test.example.com.TIME_TO_LIVE: el tiempo de vida (TTL) del registro, en segundos. Para ver los valores recomendados, consulta las consideraciones sobre DNS.RECORD_TYPE: el tipo de registro, por ejemplo,AMANAGED_ZONE_NAME: el nombre de la zona gestionada cuyos conjuntos de registros quieres gestionar. Por ejemplo,my-zone-nameFORWARDING_RULE_NAME: los nombres de las reglas de reenvío del balanceador de carga de cadaREGIONREGION: las regiones en las que se ha implementado cada balanceador de carga
Prácticas recomendadas
A continuación, te indicamos algunas prácticas recomendadas que debes tener en cuenta al configurar el registro de Cloud DNS y las comprobaciones de estado:
El tiempo que tarda en enrutarse el tráfico de los balanceadores de carga que no están en buen estado a los que sí lo están (es decir, la duración de la interrupción) depende del valor de TTL del DNS, del intervalo de comprobación del estado y del parámetro Umbral de mal estado de la comprobación del estado.
Con Cloud DNS de Google, el límite superior de este periodo se puede calcular con la siguiente fórmula:
Duration of outage = DNS TTL + Health Check Interval * Unhealthy ThresholdTe recomendamos que definas el TTL de DNS en un valor de entre 30 y 60 segundos. Los TTLs más altos provocan tiempos de inactividad más largos porque los clientes de Internet siguen accediendo a los balanceadores de carga no operativos incluso después de que el DNS haya conmutado por error a otras regiones.
Configura los parámetros de umbral de estado correcto y incorrecto en las comprobaciones de estado para evitar que el tráfico se redirija de forma innecesaria y abrupta debido a errores transitorios. Si se usan umbrales más altos, el tráfico tardará más en cambiar a los balanceadores de carga de otras regiones.