Para protegerte contra las interrupciones de la infraestructura o los errores de configuración, puedes diseñar estrategias de conmutación por error para los balanceadores de cargas de aplicaciones externos globales. Estas estrategias usan balanceadores de cargas de aplicaciones externos regionales y enrutan el tráfico hacia ellos desde un balanceador de cargas de aplicaciones externo global para mantener una alta disponibilidad durante las interrupciones de la infraestructura global o los errores de configuración.
En una arquitectura de conmutación por error, implementas un balanceador de cargas principal y uno o más balanceadores de cargas de resguardo:
- El balanceador de cargas principal es el balanceador de cargas de aplicaciones externo global que controla el tráfico de clientes durante las operaciones normales.
- El balanceador de cargas de respaldo es un balanceador de cargas de aplicaciones externo regional que recibe tráfico cuando el balanceador de cargas principal no supera las verificaciones de estado.
La conmutación por error y la conmutación por recuperación son procesos automáticos de enrutamiento del tráfico:
- La conmutación por error se produce cuando Cloud DNS detecta una interrupción y enruta el tráfico del balanceador de cargas principal a los balanceadores de cargas de copia de seguridad.
- La conmutación por recuperación se produce cuando Cloud DNS revierte este enrutamiento y redirecciona el tráfico al balanceador de cargas principal después de que se aprueban las verificaciones de estado.
En este documento, se explica la conmutación por error de un balanceador de cargas de aplicaciones externo global a balanceadores de cargas de copia de seguridad regionales. Si deseas configurar la conmutación por error entre balanceadores de cargas de aplicaciones externos regionales en diferentes regiones, consulta Alta disponibilidad para los balanceadores de cargas de aplicaciones externos regionales.
Por qué usar balanceadores de cargas regionales para la conmutación por error
Los balanceadores de cargas de aplicaciones externos regionales funcionan mejor como balanceadores de cargas de conmutación por error para los balanceadores de cargas de aplicaciones externos globales debido a las siguientes propiedades:
- Los balanceadores de cargas de aplicaciones externos regionales son autónomos dentro de las regiones individuales deGoogle Cloud y también están aislados de cualquier infraestructura de balanceador de cargas de aplicaciones externo global que se ejecute en la misma región.
- Los balanceadores de cargas de aplicaciones externos regionales y los balanceadores de cargas de aplicaciones externos globales se basan en proxies de Envoy y procesan el tráfico de manera similar.
Para implementar la conmutación por error de global a regional para los balanceadores de cargas de aplicaciones externos globales, crea dos o más balanceadores de cargas de aplicaciones externos regionales en las regiones a las que deseas que se conmute el tráfico por error.
Estrategias de conmutación por error
Puedes implementar la conmutación por error para los balanceadores de cargas de aplicaciones externos globales con las siguientes estrategias:
- Activo-pasivo (conmutación por error de global a regional): Implementas uno o más balanceadores de cargas de aplicaciones externos regionales solo con fines de copia de seguridad. En estado estable, Cloud DNS se resuelve en la dirección IP del balanceador de cargas de aplicaciones externo global. Si falla el balanceador de cargas global, Cloud DNS enruta el tráfico a los balanceadores de cargas regionales de copia de seguridad. Esta configuración usa una política de enrutamiento por conmutación por error de Cloud DNS.
- Activo-activo (omisión de global a regional): Un balanceador de cargas de aplicaciones externo global actúa como un frontend perimetral que proporciona funciones de Cloud CDN, como el almacenamiento en caché perimetral, que reenvía solicitudes a balanceadores de cargas de aplicaciones externos regionales a través de grupos de extremos de red (NEG) de Internet con nombres de dominio completamente calificados (FQDN). En estado estable, el tráfico fluye de forma secuencial a través de ambas capas de balanceo de cargas. Esto se puede configurar con una política de enrutamiento de ubicación geográfica de Cloud DNS. Si el balanceador de cargas global experimenta una interrupción, las políticas de enrutamiento de DNS omiten la capa global y enrutan el tráfico del cliente directamente a los balanceadores de cargas regionales.
Como práctica recomendada, si tu arquitectura no depende del balanceo de cargas global del backend que tiene en cuenta la capacidad, prefiere la estrategia activo-activo. Sin embargo, si tu aplicación requiere explícitamente el balanceo de cargas de backend global para distribuir y desbordar el tráfico entre regiones según la capacidad del backend, implementa la estrategia activo-pasivo.
Comparación de las estrategias de conmutación por error
En la siguiente tabla, se comparan las estrategias de conmutación por error activa-pasiva y activa-activa:
| Atributo de la estrategia | Activa-pasiva | Activa-activa |
|---|---|---|
| Flujo de tráfico en estado estable | Cliente → Balanceador de cargas de aplicaciones externo global → Backend | Cliente → Balanceador de cargas de aplicaciones externo global → Balanceador de cargas de aplicaciones externo regional → Backend |
| Flujo de tráfico en estado de falla | Cliente → Balanceador de cargas de aplicaciones externo regional → Backend. El servicio sigue disponible, pero es posible que experimente una latencia más alta debido a la pérdida de los beneficios de rendimiento del borde. |
Cliente → Balanceador de cargas de aplicaciones externo regional → Backend (se omite el balanceador de cargas de aplicaciones externo global). El servicio sigue disponible, pero es posible que experimente una latencia más alta debido a la pérdida de los beneficios de rendimiento del borde. |
| Administración de configuración | Requiere la sincronización de configuraciones independientes en los balanceadores de cargas globales y regionales. | La capa global requiere una configuración mínima, ya que la mayor parte de la lógica de la aplicación reside en los balanceadores de cargas regionales. Sin embargo, debes duplicar las políticas de seguridad perimetral (Cloud Armor) y la configuración de finalización de la conexión (certificados TLS) en ambas capas. |
| Verificación de confiabilidad | El balanceador de cargas de aplicaciones externo regional está inactivo en estado estable. Se recomienda realizar pruebas periódicas o enviar tráfico de goteo de DNS. | El tráfico en estado estable prueba continuamente el balanceador de cargas de aplicaciones externo regional. Se recomienda realizar pruebas periódicas o enviar tráfico de goteo directamente al balanceador de cargas regional. |
| Seguridad de la implementación progresiva | Los cambios en la configuración del balanceador de cargas de aplicaciones externo global se aplican a nivel global. Los cambios en el balanceador de cargas de aplicaciones externo regional están aislados, pero el tráfico en estado estable no los prueba. | Puedes aplicar los cambios del balanceador de cargas de aplicaciones externo regional de forma progresiva, región por región. Si falla una región, la capa global enruta automáticamente el tráfico fuera de ella hacia regiones en buen estado. |
| Balanceo de cargas de backend global | Admitido El balanceador de cargas de aplicaciones externo global puede balancear el tráfico entre los backends de diferentes regiones según la capacidad. |
Limitado El balanceador de cargas de aplicaciones externo global enruta el tráfico al balanceador de cargas de aplicaciones externo regional más cercano. El balanceador de cargas regional solo balancea el tráfico de forma local y no lo distribuye entre regiones según la capacidad del backend. |
| Costo y facturación | Las tarifas por procesamiento de datos se aplican a una sola capa de balanceo de cargas. En condiciones normales, los costos provienen del balanceador de cargas de aplicaciones externo global. Los cargos por el balanceador de cargas de aplicaciones externo regional solo se aplican durante las pruebas o los eventos de conmutación por error. | Ambas capas de balanceo de cargas generan cargos por procesamiento de datos de forma simultánea, ya que el tráfico fluye a través de los niveles globales y regionales en estado estable. |
| Caso práctico recomendado | Cargas de trabajo que requieren balanceo de cargas de backend global avanzado y desbordamiento de tráfico basado en la capacidad en todas las regiones. | Cargas de trabajo diseñadas en torno al aislamiento regional que usan la capa global para el rendimiento y el almacenamiento en caché perimetrales. |
Estrategia activa-pasiva
En una configuración activa-pasiva, implementas balanceadores de cargas de aplicaciones externos regionales independientes en una o más regiones junto con tu balanceador de cargas de aplicaciones externo global o balanceador de cargas de aplicaciones clásico principal.
Cómo funciona la conmutación por error activa-pasiva
En la siguiente configuración, se muestra la conmutación por error de un balanceador de cargas de aplicaciones externo global a dos balanceadores de cargas de aplicaciones externos regionales de copia de seguridad, uno en cada región en la que el balanceador de cargas global implementó backends.
La conmutación por error activa-pasiva sigue este flujo de trabajo:
- Estado estable: Cloud DNS enruta todo el tráfico de clientes al balanceador de cargas de aplicaciones externo global.
- Detección de fallas: Google Cloud usa verificaciones de estado configuradas con tres regiones de origen para detectar si el balanceador de cargas principal está en buen estado. Si fallan las verificaciones de estado que se originan en dos o más regiones de origen, Cloud DNS activa la conmutación por error.
- Conmutación por error: Las políticas de enrutamiento de conmutación por error de Cloud DNS enrutan el tráfico del cliente directamente a los balanceadores de cargas de aplicaciones externos regionales de copia de seguridad. Impacto en la latencia durante la conmutación por error: Debido a que los balanceadores de cargas de aplicaciones externos regionales finalizan las conexiones dentro de una Google Cloud región específica, los clientes ubicados lejos de la región de destino pueden experimentar una mayor latencia y tiempos de ida y vuelta (RTT) mientras la conmutación por error está activa.
- Conmutación por recuperación: Después de que las verificaciones de estado vuelvan a tener éxito, Cloud DNS restablece automáticamente el tráfico al balanceador de cargas principal sin tiempo de inactividad, ya que ambos balanceadores de cargas entregan tráfico.
Estrategia activa-activa (omisión de global a regional)
En una estrategia activo-activo, el balanceador de cargas de aplicaciones externo global usa un NEG de FQDN de Internet (INTERNET_FQDN_PORT) para enviar tráfico a los balanceadores de cargas de aplicaciones externos regionales en dos o más regiones.
Cómo funciona la derivación activa-activa
En la siguiente configuración, se muestra la conmutación por error de un balanceador de cargas de aplicaciones externo global a dos balanceadores de cargas de aplicaciones externos regionales de copia de seguridad, uno en cada región en la que el balanceador de cargas global implementó backends.
La conmutación por error activa-activa sigue este flujo de trabajo:
- Estado estable: El tráfico fluye del cliente al balanceador de cargas de aplicaciones externo global.
El balanceador de cargas global usa un grupo de extremos de red (NEG) de FQDN de Internet de tipo
INTERNET_FQDN_PORTpara reenviar el tráfico a los balanceadores de cargas de aplicaciones externos regionales más cercanos. Luego, los balanceadores de cargas regionales entregan el tráfico a los backends locales. - Detección de fallas: En estado estable, si falla un solo balanceador de cargas de aplicaciones externo regional o su región, el balanceador de cargas de aplicaciones externo global detecta la falla con la política de verificación de estado de Cloud DNS en el NEG de Internet. El balanceador de cargas global enruta automáticamente el tráfico desde la región en mal estado hacia los balanceadores de cargas regionales en buen estado.
- Omisión: Si el balanceador de cargas de aplicaciones externo global experimenta una interrupción, las políticas de conmutación por error de Cloud DNS detectan la falla y enrutan el tráfico directamente a los balanceadores de cargas de aplicaciones externos regionales, lo que omite por completo la capa global. Impacto en la latencia durante la omisión: El balanceador de cargas de aplicaciones externo global proporciona beneficios de rendimiento perimetral, como la finalización de conexiones más cerca de los usuarios y el almacenamiento en caché perimetral. Cuando el tráfico omite el balanceador de cargas global, las conexiones de los clientes se establecen directamente con las VIP regionales, lo que puede aumentar la latencia de conexión y el RTT para los clientes geográficamente distantes.
- Conmutación por recuperación: Cuando el balanceador de cargas global pasa verificaciones de estado consecutivas, Cloud DNS reanuda automáticamente la devolución de la VIP de Anycast global en las respuestas de DNS, lo que restablece el nivel de enrutamiento perimetral global.
Revisa la configuración del balanceador de cargas principal
Antes de configurar la conmutación por error, confirma que el balanceador de cargas de aplicaciones externo regional de respaldo admita las funciones que usa el balanceador de cargas principal.
- En el modo activo-pasivo, el balanceador de cargas regional de copia de seguridad debe admitir funciones similares para asumir el tráfico sin problemas durante una interrupción.
- En el modo activo-activo, las reglas de seguridad y de enrutamiento principales deben configurarse directamente en el nivel regional, mientras que las funciones perimetrales globales, como Cloud CDN, se omiten durante una interrupción global.
| Función | Requisitos de compatibilidad |
|---|---|
| Implementaciones de Google Kubernetes Engine | Usa la puerta de enlace de GKE para implementar el balanceador de cargas principal y el de copia de seguridad. Esto se debe a que los balanceadores de cargas implementados con la puerta de enlace de GKE son más compatibles con este mecanismo de conmutación por error que los balanceadores de cargas implementados con el controlador de entrada de GKE. El controlador de Ingress de GKE solo admite el balanceador de cargas de aplicaciones clásico. |
| Cloud CDN | Los balanceadores de cargas de aplicaciones externos regionales no son compatibles con Cloud CDN. Si se produce una conmutación por error, se verán afectadas las operaciones que dependan de Cloud CDN. |
| Cloud Armor | Si usas Cloud Armor en el balanceador de cargas principal, configura políticas de seguridad regionales equivalentes de Cloud Armor en los balanceadores de cargas de copia de seguridad. Cloud Armor tiene diferentes funciones disponibles a nivel regional y global. Para obtener más información, consulta Políticas de seguridad regionales de Cloud Armor y Políticas de seguridad globales de Cloud Armor. |
| Certificado SSL | Verifica que el tipo de certificado SSL que usa el balanceador de cargas principal sea compatible con el balanceador de cargas de aplicaciones externo regional de copia de seguridad. Revisa las diferencias entre los certificados SSL disponibles con los balanceadores de cargas globales, regionales y clásicos. Para obtener más información, consulta Certificados SSL de Compute Engine y Certificados SSL del Administrador de certificados. |
Consideraciones para los balanceadores de cargas regionales
Configura y, luego, implementa balanceadores de cargas de aplicaciones externos regionales en la región a la que deseas que se redireccione el tráfico en caso de falla.
Ten en cuenta las siguientes consideraciones para las arquitecturas de conmutación por error o de bypass mientras configuras tu balanceador de cargas regional:
Debes configurar las funciones del balanceador de cargas de aplicaciones externo regional de copia de seguridad para que sean lo más similares posible al balanceador de cargas principal, de modo que el tráfico se procese de manera similar en ambas implementaciones.
Balanceador de cargas de aplicaciones externo global Los balanceadores de cargas de aplicaciones externos regionales admiten la mayoría de las mismas funciones que los balanceadores de cargas de aplicaciones externos globales, con algunas excepciones. El balanceador de cargas regional también admite las mismas funciones avanzadas de administración de tráfico que el balanceador de cargas global, lo que facilita lograr la equivalencia entre los balanceadores de cargas principal y de copia de seguridad.
Balanceador de cargas de aplicaciones clásico Con el balanceador de cargas de aplicaciones clásico, es más difícil lograr la paridad de funciones entre el balanceador de cargas principal y el de copia de seguridad, ya que el balanceador de cargas de aplicaciones externo regional es un balanceador de cargas basado en Envoy que procesa el tráfico de manera diferente. Asegúrate de probar la conmutación por error y la recuperación antes de realizar la implementación en producción.
Para ver las capacidades específicas de los balanceadores de cargas de aplicaciones regionales, globales y clásicos, consulta la página de comparación de funciones del balanceador de cargas.
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 implementaciones principales y de copia de seguridad.
Los balanceadores de cargas de aplicaciones externos regionales admiten los Niveles de servicio de red Premium y Estándar. Si la latencia no es tu principal preocupación durante la conmutación por error, te recomendamos que configures los balanceadores de cargas de aplicaciones externos regionales de respaldo con el nivel Estándar. El uso de la infraestructura del nivel estándar ofrece aislamiento adicional de la infraestructura del nivel Premium que usan los balanceadores de cargas de aplicaciones externos globales.
Asegúrate de que la subred de solo proxy tenga el tamaño suficiente para admitir el aumento del tráfico durante un evento de conmutación por error sin interrumpir otros balanceadores de cargas regionales en la misma región y red. Para obtener más detalles, consulta Cómo reservar capacidad adicional de subred de solo proxy.
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.
Reserva capacidad adicional de subred de solo proxy
Todos los balanceadores de cargas regionales basados en Envoy en una región y red de VPC comparten el mismo grupo de proxies de Envoy. En un evento de conmutación por error, los balanceadores de cargas de aplicaciones externos regionales de respaldo experimentan un aumento en el uso del proxy para controlar el tráfico de conmutación por error del balanceador de cargas principal. Reservar capacidad de proxy suficiente garantiza que los eventos de conmutación por error no interrumpan otros balanceadores de cargas regionales basados en Envoy en la misma región y red.
Para garantizar que la capacidad siempre esté disponible para los balanceadores de cargas de copia de seguridad, revisa el tamaño de tu subred de solo proxy. Te recomendamos que calcules la cantidad estimada de proxies necesarios para controlar el tráfico en una región determinada y que aumentes la capacidad si es necesario. Para obtener más información sobre los límites de capacidad del proxy y los cálculos de tamaño, consulta la sección Cargos por instancia de proxy en "Precios de Cloud Load Balancing".
Si usas políticas de DNS para dividir el tráfico entre varios balanceadores de cargas de respaldo en diferentes regiones, debes tenerlo en cuenta cuando estimes los requisitos de proxy por región y red. Una subred de solo proxy más grande permite queGoogle Cloud asigne una mayor cantidad de proxies de Envoy a tu balanceador de cargas cuando sea necesario.
No puedes expandir una subred de solo proxy de la misma manera que lo harías para un rango de direcciones principal (con el comando expand-ip-range). En su lugar, debes crear una subred de solo proxy de copia de seguridad que satisfaga tus necesidades y, luego, promoverla al rol activo.
Para obtener información sobre cómo cambiar el tamaño de tu subred de solo proxy, consulta Cambia el tamaño o el rango de direcciones de una subred de solo proxy.
Cómo compartir backends entre balanceadores de cargas principales y de respaldo
Para lograr una redundancia completa de la infraestructura, debes introducir redundancia tanto a nivel del balanceador de cargas como a nivel del backend. Esto significa que debes configurar tus balanceadores de cargas de aplicaciones externos regionales de copia de seguridad con backends (grupos de instancias o grupos de extremos de red) que no se superpongan con los balanceadores de cargas principales.
Si, en cambio, eliges usar los mismos backends para los balanceadores de cargas principal y de copia de seguridad, debes crear cada balanceador de cargas de aplicaciones externo regional de copia de seguridad en la región en la que se encuentran esos backends. Además, si el ajuste de escala automático está habilitado para los grupos de instancias, debes cumplir con los siguientes requisitos para garantizar que se produzca una conmutación por error correcta:
- Configura el escalador automático solo con el ajuste de escala basado en CPU. No se admite el ajuste de escala automático basado en el uso del balanceador de cargas.
- Tanto los servicios de backend globales como los regionales deben usar solo el modo de balanceo
UTILIZATION. No uses el modo de balanceoRATE, ya que tus instancias podrían recibir el doble de tráfico de los balanceadores de cargas globales y regionales durante el proceso de conmutación por error. - Configura los controles de reducción de escalamiento para evitar que el escalador automático reduzca prematuramente el grupo durante el tiempo de inactividad cuando el tráfico cambia del balanceador de cargas global al regional. Este tiempo de inactividad puede ser tan alto como la suma del TTL (tiempo de actividad) del DNS más el intervalo de verificación de estado configurado.
Si no configuras el ajuste de escala automático correctamente, es posible que se produzca una interrupción secundaria durante la conmutación por error, ya que la pérdida de tráfico del balanceador de cargas global hace que el grupo de instancias se reduzca rápidamente antes de que el balanceador de cargas regional tome el control.
Configura la conmutación por error activa-pasiva
Para configurar la conmutación por error activa-pasiva, sigue estos pasos:
- Revisa las consideraciones de la arquitectura: Antes de crear recursos, revisa las consideraciones para los balanceadores de cargas regionales para verificar la compatibilidad de las funciones, la capacidad del proxy y los requisitos de ajuste de escala automático del backend compartido.
- Configura el balanceador de cargas principal: Configura tu balanceador de cargas de aplicaciones externo global con servicios de backend distribuidos en una o más regiones. Para obtener más información sobre cómo configurar un balanceador de cargas de aplicaciones externo global, consulta Configura un balanceador de cargas de aplicaciones externo global.
- Revisa la configuración del balanceador de cargas principal: Confirma que las funciones (como las funciones de seguridad, las funciones de administración y enrutamiento de tráfico y Cloud CDN) que usa el balanceador de cargas principal estén disponibles con el balanceador de cargas de aplicaciones externo regional de copia de seguridad. Si no hay funciones similares disponibles, es posible que este balanceador de cargas no sea una buena opción para la conmutación por error.
- Configura los balanceadores de cargas de aplicaciones externos regionales de copia de seguridad: Configura balanceadores de cargas de aplicaciones externos regionales independientes en las regiones en las que deseas que se produzca la conmutación por error del tráfico. Para obtener información sobre cómo 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 el enrutamiento de DNS y las verificaciones de estado: Crea una verificación de estado para el balanceador de cargas principal y configura una política de enrutamiento de conmutación por error de Cloud DNS para detectar interrupciones y enrutar el tráfico del cliente a los balanceadores de cargas regionales de copia de seguridad.
Configura la omisión activa-activa
Para configurar la arquitectura activo-activo, sigue estos pasos:
Revisa las consideraciones de la arquitectura: Antes de crear recursos, revisa las consideraciones para los balanceadores de cargas regionales para verificar la compatibilidad de las funciones y asegúrate de que la capacidad de tu subred de solo proxy pueda controlar el tráfico en estado estable y de conmutación por error.
Configura balanceadores de cargas de aplicaciones externos regionales: Antes de configurar balanceadores de cargas regionales, revisa la compatibilidad y las limitaciones de las funciones. Implementa balanceadores de cargas de aplicaciones externos regionales en dos o más regiones con tus servicios de backend, direcciones IP externas, certificados SSL y políticas de seguridad regionales de Cloud Armor. Para obtener instrucciones de configuración, consulta Configura un balanceador de cargas de aplicaciones externo regional con backends de grupos de instancias de VM.
Configura el DNS para los balanceadores de cargas regionales: Crea un registro DNS (por ejemplo,
regional-api.example.com) que apunte a las direcciones IP externas de tus balanceadores de cargas de aplicaciones externos regionales con una política de enrutamiento de ubicación geográfica o latencia. Habilita la verificación de estado de DNS en este registro para detectar una falla en una región específica y enrutar automáticamente el tráfico fuera de ella hacia otras regiones en buen estado.Configura el balanceador de cargas de aplicaciones externo global: Reserva una dirección IP externa global y crea un grupo de extremos de red (NEG) de Internet global de tipo
INTERNET_FQDN_PORT. Agrega un extremo al NEG de Internet que apunte al FQDN del registro DNS regional, por ejemplo,regional-api.example.com. Configura un servicio de backend para el balanceador de cargas de aplicaciones externo global, adjunta el NEG de Internet y habilita Cloud CDN o Cloud Armor si es necesario. Configura el mapa de URL, el proxy HTTP(S) de destino y la regla de reenvío global.Configura el DNS para la conmutación por error y las verificaciones de estado: Crea el registro DNS del servicio principal (por ejemplo,
api.example.com) con una política de enrutamientoFAILOVER. Asegúrate de que el conjunto de registros tenga un extremo principal que apunte a la dirección IP del balanceador de cargas de aplicaciones externo global y extremos de copia de seguridad que apunten a las direcciones IP externas de los balanceadores de cargas de aplicaciones externos regionales. Configura una verificación de estado del DNS para supervisar el balanceador de cargas de aplicaciones externo global.
Prácticas recomendadas
Ten en cuenta las siguientes prácticas recomendadas cuando configures el registro DNS de Cloud DNS y las verificaciones de estado:
Calcular la duración de la interrupción: El tiempo necesario para que el tráfico conmute por error de los balanceadores de cargas principales a los de copia de seguridad depende del TTL de DNS, el intervalo de verificación de estado y el parámetro límite de la verificación de 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 ThresholdEstablece el TTL del DNS en un período de entre 30 y 60 segundos. Los valores de TTL más altos generan tiempos de conmutación por error más largos, ya que los clientes en Internet siguen accediendo a los balanceadores de cargas de aplicaciones externos principales incluso después de que el DNS conmutó por error al balanceador de cargas de aplicaciones externo regional de copia de seguridad.
Configura los umbrales de verificación de estado: Establece los parámetros de umbral de buen estado y mal estado para evitar conmutaciones por error causadas por errores de red transitorios. Los umbrales más altos aumentan el tiempo necesario para que el tráfico conmute por error a los balanceadores de cargas de copia de seguridad.
Usa el tráfico de goteo para la validación: Configura la marca
--backup-data-trickle-ratiopara enviar de forma continua un pequeño porcentaje de tráfico a los balanceadores de cargas de copia de seguridad, incluso cuando los balanceadores de cargas principales estén en buen estado. Esto garantiza que la infraestructura de respaldo esté activa y lista para controlar el tráfico. Puedes configurar el porcentaje del tráfico que se envía a los balanceadores de cargas de copia de seguridad como una fracción de 0 a 1. El valor típico 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.Prueba la conmutación por error y por recuperación periódicamente: Incluye pruebas de conmutación por error en tu plan de recuperación ante desastres. Verifica los cambios graduales y repentinos en el tráfico de los balanceadores de cargas principales a los de respaldo, y verifica que el tráfico vuelva sin problemas al balanceador de cargas principal después de la conmutación por recuperación.