Conmutación por error de balanceadores de carga de aplicación externos

En esta página se describe cómo funciona la conmutación por error en los balanceadores de carga de aplicaciones externos. La configuración de conmutación por error implica dos balanceadores de carga: uno principal y otro de reserva. En este artículo, el balanceador de carga principal es el balanceador de carga para el que quieres configurar la conmutación por error. El balanceador de carga de copia de seguridad es el que recibe las conexiones cuando el balanceador de carga principal empieza a fallar en las comprobaciones del estado.

La conmutación por error y la conmutación por recuperación son los procesos automáticos que dirigen el tráfico hacia y desde un balanceador de carga. Cuando Cloud DNS detecta una interrupción y dirige el tráfico del balanceador de carga principal al de respaldo, el proceso se denomina conmutación por error. Cuando Cloud DNS invierte este proceso y redirige el tráfico al balanceador de carga principal, se denomina restauración.

Cómo funciona la conmutación por error

La conmutación por error de global a regional de los balanceadores de carga de aplicaciones externos se gestiona creando dos o más balanceadores de carga de aplicaciones externos regionales en las regiones a las que quieras que se conmute el tráfico. Solo se pueden usar balanceadores de carga de aplicación externos regionales como balanceadores de carga de respaldo. Los balanceadores de carga de aplicación externos regionales no solo están aislados en regiones concretas, 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.Google Cloud

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

En resumen, se admiten los siguientes casos de conmutación por error:

  • De un balanceador de carga de aplicación externo global a un balanceador de carga de aplicación externo regional
  • De un balanceador de carga de aplicación externo regional a otro
  • De un balanceador de carga de aplicación clásico a un balanceador de carga de aplicación externo regional

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

En la siguiente configuración se muestra la conmutación por error de un balanceador de carga de aplicación externo global a dos balanceadores de carga de aplicación externos regionales, uno en cada región en la que el balanceador de carga global ha desplegado backends.

Conmutación por error de un balanceador de carga de aplicación externo global a dos balanceadores de carga de aplicación externos regionales.
Conmutación por error de un balanceador de carga de aplicación externo global a dos balanceadores de carga de aplicación externos regionales (haz clic en la imagen para ampliarla).

En las siguientes secciones se describe un flujo de trabajo habitual con los diferentes componentes implicados en una configuración de conmutación por error.

  1. Detectar fallos en el balanceador de carga principal

    Google Cloud usa comprobaciones del estado para detectar si tu balanceador de carga de aplicación externo principal está 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 accederán al balanceador de carga. Por ejemplo, si tiene un balanceador de carga de aplicaciones externo global y la mayor parte del tráfico de sus clientes procede de Norteamérica y Europa, puede configurar sondeos procedentes de dos regiones de Norteamérica y una de Europa.

    Si fallan las comprobaciones del estado procedentes de dos o más de estas regiones, se activa la conmutación por error al balanceador de carga de aplicación externo regional de copia de seguridad.

    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.

  2. Dirigir el tráfico a balanceadores de carga de reserva

    Si el balanceador de carga principal empieza a fallar en las comprobaciones del estado, Google Cloud utiliza 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 carga de copia de seguridad.

    La duración de la interrupción o el tiempo que tarda el tráfico en conmutar por error de los balanceadores de carga principales a los de copia de seguridad se determina mediante el valor TTL del DNS, el intervalo de comprobación del estado y el umbral de mal estado de la comprobación del estado. Para ver los ajustes recomendados, consulta las prácticas recomendadas.

  3. Volver al balanceador de carga principal

    Cuando las comprobaciones de estado vuelvan a dar resultados positivos, la conmutación por error al balanceador de carga principal se realizará automáticamente. No se espera ningún tiempo de inactividad durante la conmutación por recuperación, ya que tanto el balanceador de carga de copia de seguridad como el principal están sirviendo tráfico.

  4. Prueba la conmutación por error periódicamente

    Te recomendamos que pruebes periódicamente el flujo de trabajo de conmutación por error como parte de tu plan de continuidad empresarial. Asegúrate de probar tanto los cambios graduales como los instantáneos en el tráfico de los balanceadores de carga principales a los de respaldo. Después de verificar que la conmutación por error funciona, activa una conmutación por recuperación para comprobar que el tráfico se redirige al balanceador de carga principal como se espera.

Configurar conmutación por error

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

  1. Revisa la configuración del balanceador de carga principal y comprueba que las funciones (como las de seguridad, gestión del tráfico y enrutamiento, así como la CDN) que usa el balanceador de carga principal estén disponibles en el balanceador de carga de aplicaciones externo regional de respaldo. Si no hay funciones similares disponibles, es posible que este balanceador de carga no sea un buen candidato para la conmutación por error.
  2. Crea el balanceador de carga de aplicación externo regional de copia de seguridad con una configuración que refleje el balanceador de carga principal en la medida de lo posible.
  3. Crea la comprobación del estado y la política de enrutamiento de DNS para detectar interrupciones y enrutar el tráfico del balanceador de carga principal al de respaldo durante la conmutación por error.

Revisar la configuración del balanceador de carga principal

Antes de empezar, comprueba que el balanceador de carga de aplicación externo regional de copia de seguridad admita todas las funciones que se usan actualmente con el balanceador de carga principal.

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

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

    Para obtener los mejores resultados, usa GKE Gateway para implementar los balanceadores de carga principal y de copia de seguridad.

  • Cloud CDN. Los balanceadores de carga de aplicación externos regionales no admiten Cloud CDN. Por lo tanto, en caso de fallo, las operaciones que dependan de Cloud CDN también se verán afectadas. Para mejorar la redundancia, le recomendamos que configure una solución de CDN de terceros que pueda actuar como alternativa a Cloud CDN.

  • Cloud Armor. Si usas Cloud Armor en tu balanceador de carga principal, asegúrate de configurar las mismas funciones de Cloud Armor al configurar el balanceador de carga de aplicaciones externo regional de copia de seguridad. Cloud Armor tiene diferentes funciones disponibles en el ámbito regional y en el global. Para obtener más información, consulta las siguientes secciones de la documentación de Cloud Armor:

  • Certificados SSL. Si quieres usar un certificado SSL común para los balanceadores de carga principal y de copia de seguridad, confirma que el tipo de certificado SSL que se usa con el balanceador de carga principal es compatible con el balanceador de carga de aplicaciones externo regional de copia de seguridad. Consulta las diferencias entre los certificados SSL disponibles con los balanceadores de carga globales, regionales y clásicos. Para obtener más información, consulta las siguientes secciones:

  • Segmentos de backend. Los balanceadores de carga de aplicaciones externos regionales no admiten segmentos de Cloud Storage como backends. No puedes configurar la conmutación por error para balanceadores de carga que usen contenedores de backend.

Configurar el balanceador de carga de copia de seguridad

El balanceador de carga de copia de seguridad es un balanceador de carga de aplicación externo regional que se configura en la región a la que quieres que se redirija el tráfico en caso de fallo.

Ten en cuenta lo siguiente al configurar el balanceador de carga de respaldo:

  • Debe configurar las funciones del balanceador de carga de aplicación externo regional de copia de seguridad para que sean lo más parecidas posible al balanceador de carga principal, de modo que el tráfico se procese de forma similar en ambos despliegues.

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

    • Balanceador de carga de aplicaciones clásico. Con el balanceador de carga de aplicación clásico, es más difícil conseguir la paridad de funciones entre el balanceador de carga principal y el de reserva, ya que el balanceador de carga de aplicación externo regional es un balanceador de carga basado en Envoy que procesa el tráfico de forma diferente. Asegúrate de probar la conmutación por error y la recuperación tras un fallo a fondo antes de implementar el cambio en producción.

    Para ver las funciones específicas de los balanceadores de carga de aplicación regionales, globales y clásicos, consulta la página de comparación de funciones de los balanceadores de carga.

    Te recomendamos que uses un framework de automatización como Terraform para conseguir y mantener la coherencia en las configuraciones de balanceadores de carga en las implementaciones principales y de copia de seguridad.

  • Te recomendamos que configures balanceadores de carga de aplicaciones externos regionales de respaldo en todas las regiones en las que tengas back-ends. Por ejemplo, si pasas de una implementación global con grupos de instancias en cinco regiones a balanceadores de carga regionales de respaldo en solo tres regiones, corres el riesgo de sobrecargar los servicios de backend en esas tres regiones, mientras que los servicios de backend de las dos regiones restantes estarán inactivos.

    Además, te recomendamos que configures Cloud DNS para que use políticas de asignación cíclica ponderada al redirigir el tráfico de conmutación por error de un balanceador de carga global principal a estos balanceadores de carga regionales de reserva. Asigna pesos a cada balanceador de carga de copia de seguridad teniendo en cuenta los tamaños máximos de los grupos de instancias de backend en diferentes regiones.

  • Los balanceadores de carga de aplicaciones externos regionales admiten los niveles de servicio de red Premium y Estándar. Si la latencia no es su principal preocupación durante la conmutación por error, le recomendamos que configure los balanceadores de carga de aplicaciones externos regionales de copia de seguridad con el nivel Estándar. Usar la infraestructura del nivel Estándar ofrece un aislamiento adicional de la infraestructura del nivel Premium que usan los balanceadores de carga de aplicación externos globales.

  • Si quieres usar los mismos backends para los balanceadores de carga principales y de backup, crea el balanceador de carga de aplicaciones externo regional de backup en la región en la que se encuentren los backends. Si has habilitado el autoescalado en los grupos de instancias de backend, debes cumplir los requisitos para compartir backends entre implementaciones.

  • Si es necesario, reserva proxies de Envoy adicionales para los balanceadores de carga de aplicaciones externos regionales para asegurarte de que, en caso de que se produzca una conmutación por error, el tráfico adicional no interrumpa ninguna otra implementación de balanceador de carga en la misma región. Para obtener más información, consulta Reservar capacidad adicional de subred de solo proxy.

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.

Reservar capacidad adicional de subred de solo proxy

Todos los balanceadores de carga regionales basados en Envoy de una región y una red de VPC comparten el mismo grupo de proxies de Envoy. En caso de conmutación por error, los balanceadores de carga de aplicación externos regionales de copia de seguridad experimentan un aumento del uso de proxies para gestionar el tráfico de conmutación por error del balanceador de carga principal. Para asegurarte de que siempre haya capacidad disponible para los balanceadores de carga de backup, te recomendamos que revises el tamaño de tu subred de solo proxy. Te recomendamos que calcules el número estimado de proxies que necesitas para gestionar el tráfico en una región determinada y que aumentes la capacidad si es necesario. Esto también ayuda a asegurar que los eventos de conmutación por error no interrumpan otros balanceadores de carga basados en Envoy de la misma región y red.

Por lo general, un proxy de balanceador de carga de aplicación externo regional puede gestionar hasta lo siguiente:

  • 600 o 150 conexiones nuevas (HTTP o HTTPS, respectivamente) por segundo
  • 3000 conexiones activas
  • 1400 solicitudes por segundo

Si usas políticas de DNS para dividir el tráfico entre varios balanceadores de carga de copia de seguridad en diferentes regiones, debes tenerlo en cuenta al estimar los requisitos de proxy por región y red. Una subred de solo proxy más grande permite aGoogle Cloud asignar un mayor número de proxies Envoy a tu balanceador de carga cuando sea necesario.

No puedes ampliar una subred solo de proxy de la misma forma que lo harías con un intervalo de direcciones principal (con el comando expand-ip-range). En su lugar, debes crear una subred de solo proxy de copia de seguridad que se ajuste a tus necesidades y, a continuación, asignarle el rol activo.

Para saber cómo cambiar el tamaño de tu subred de solo proxy, consulta Cambiar el tamaño o el intervalo de direcciones de una subred de solo proxy.

Compartir backends entre balanceadores de carga principales y de backup

Para conseguir una redundancia completa de la infraestructura, debes introducir redundancia tanto en el nivel del balanceador de carga como en el nivel del backend. Esto significa que debes configurar tus balanceadores de carga de aplicación externos regionales de reserva con backends (grupos de instancias o grupos de puntos finales de red) que no se solapen con los balanceadores de carga principales.

Sin embargo, si quieres compartir un grupo de instancias de backend entre los balanceadores de carga principal y secundario y el autoescalado está habilitado en los grupos de instancias, debes cumplir los siguientes requisitos para asegurarte de que se produzca una conmutación por error adecuada:

  • El autoescalador debe configurarse solo con el escalado basado en la CPU. No se admite el método de escalado basado en la utilización del balanceador de carga.
  • Tanto el servicio de backend global como el regional deben usar únicamente 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 carga globales y regionales durante el proceso de conmutación por error.
  • Los controles de reducción horizontal deben configurarse para evitar que la herramienta de ajuste de escala reduzca el tamaño del grupo de forma prematura durante el tiempo de inactividad cuando el tráfico cambie del balanceador de carga global al regional. Este tiempo de inactividad puede ser igual a la suma del TTL de DNS más el intervalo de comprobación del estado configurado.

Si no configuras el autoescalado correctamente, puede producirse una interrupción secundaria durante la conmutación por error, ya que la pérdida de tráfico del balanceador de carga global provoca que el grupo de instancias se reduzca rápidamente.

Configurar Cloud DNS y comprobaciones de estado

En esta sección se describe cómo usar Cloud DNS y 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 backup.

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

  1. 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_PATH

    Haz los cambios siguientes:

    • HEALTH_CHECK_NAME: el nombre de la comprobación del estado
    • SOURCE_REGION: las tres Google Cloud regiones desde las que se realizan las comprobaciones 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_THRESHOLD y UNHEALTHY_THRESHOLD: 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 cuyo estado se está comprobando son privados, lo que no es habitual en las direcciones IP de las reglas de reenvío externas, puede definir esta ruta como /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 en la dirección IP de la regla de reenvío del balanceador de carga principal o, en caso de que falle una comprobación de estado, en una de las direcciones IP de las reglas de reenvío de los balanceadores de carga de copia de seguridad.

    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_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

    Haz los cambios siguientes:

    • DNS_RECORD_SET_NAME: el DNS o el nombre de dominio del conjunto de registros que se va a añadir. Por ejemplo, test.example.com.
    • TIME_TO_LIVE: el tiempo de vida (TTL) del conjunto de registros en número de segundos. Para ver 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 gestionada cuyos conjuntos de registros quieras gestionar. Por ejemplo, my-zone-name
    • PRIMARY_LOAD_BALANCER_FORWARDING_RULE: nombre de la regla de reenvío del balanceador de carga principal
    • BACKUP_REGION: las regiones donde se implementan los balanceadores de carga de copia de seguridad
    • BACKUP_LOAD_BALANCER_IP_ADDRESS: las direcciones IP de las reglas de reenvío de los balanceadores de carga de copia de seguridad correspondientes a cada región
    • BACKUP_DATA_TRICKLE_RATIO: la proporción de tráfico que se debe enviar a los balanceadores de carga de copia de seguridad, incluso cuando el balanceador de carga principal está en buen estado. La relación debe estar comprendida entre 0 y 1, como 0,1. El valor predeterminado es 0.

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 el tráfico en conmutar por error de los balanceadores de carga principales a los de respaldo (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 Threshold

    Para la configuración de conmutación por error, recomendamos definir 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, ya que los clientes de Internet siguen accediendo a los balanceadores de carga de aplicaciones externos principales incluso después de que el DNS haya conmutado por error al balanceador de carga de aplicaciones externo regional de copia de seguridad.

  • Configura los parámetros de umbral de estado correcto y incorrecto en las comprobaciones de estado para evitar conmutaciones por error innecesarias causadas por errores transitorios. Si los umbrales son más altos, el tráfico tardará más en conmutar por error a los balanceadores de carga de backup.

  • Para asegurarte de que tu configuración de conmutación por error funciona como esperas, puedes configurar tu política de enrutamiento de DNS para que siempre envíe un pequeño porcentaje del tráfico a los balanceadores de carga de copia de seguridad, incluso cuando los balanceadores de carga principales estén en buen estado. Para ello, puedes usar el parámetro --backup-data-trickle-ratio al crear el conjunto de registros DNS.

    Puede configurar el porcentaje del tráfico que se envía a la copia de seguridad como una fracción entre 0 y 1. El valor habitual es 0, 1, aunque Cloud DNS te permite enviar el 100 % del tráfico a las direcciones IP virtuales de copia de seguridad para activar manualmente una conmutación por error.