Pour vous protéger contre les pannes d'infrastructure ou les erreurs de configuration, vous pouvez concevoir des stratégies de basculement pour les équilibreurs de charge d'application externes globaux. Ces stratégies utilisent des équilibreurs de charge d'application externes régionaux et y acheminent le trafic à partir d'un équilibreur de charge d'application externe mondial pour maintenir une haute disponibilité en cas de panne de l'infrastructure mondiale ou d'erreur de configuration.
Dans une architecture de basculement, vous déployez un équilibreur de charge principal et un ou plusieurs équilibreurs de charge de secours :
- L'équilibreur de charge principal est l'équilibreur de charge d'application externe global qui gère le trafic client en temps normal.
- L'équilibreur de charge de secours est un équilibreur de charge d'application externe régional qui reçoit le trafic lorsque l'équilibreur de charge principal échoue aux vérifications de l'état.
Le basculement et la restauration sont des processus automatiques de routage du trafic :
- Le basculement se produit lorsque Cloud DNS détecte une panne et achemine le trafic de l'équilibreur de charge principal vers les équilibreurs de charge de secours.
- La restauration se produit lorsque Cloud DNS inverse ce routage et redirige le trafic vers l'équilibreur de charge principal une fois les vérifications de l'état réussies.
Ce document explique comment basculer d'un équilibreur de charge d'application externe global vers des équilibreurs de charge de sauvegarde régionaux. Si vous souhaitez configurer le basculement entre des équilibreurs de charge d'application externes régionaux dans différentes régions, consultez Haute disponibilité pour les équilibreurs de charge d'application externes régionaux.
Pourquoi utiliser des équilibreurs de charge régionaux pour le basculement ?
Les équilibreurs de charge d'application externes régionaux sont plus efficaces en tant qu'équilibreurs de charge de basculement pour les équilibreurs de charge d'application externes globaux, car ils présentent les propriétés suivantes :
- Les équilibreurs de charge d'application externes régionaux sont autonomes dans les régionsGoogle Cloud et sont également isolés de toute infrastructure d'équilibreur de charge d'application externe global s'exécutant dans la même région.
- Les équilibreurs de charge d'application externes régionaux et les équilibreurs de charge d'application externes globaux sont tous deux basés sur des proxys Envoy et traitent le trafic de manière similaire.
Pour implémenter le basculement de "global" à "régional" pour les équilibreurs de charge d'application externes globaux, créez deux ou plusieurs équilibreurs de charge d'application externes régionaux dans les régions vers lesquelles vous souhaitez que le trafic bascule.
Stratégies de basculement
Vous pouvez implémenter le basculement pour les équilibreurs de charge d'application externes globaux à l'aide des stratégies suivantes :
- Actif-passif (basculement de global à régional) : vous déployez un ou plusieurs équilibreurs de charge d'application externes régionaux uniquement à des fins de sauvegarde. En état stable, Cloud DNS est résolu en adresse IP de l'équilibreur de charge d'application externe global. Si l'équilibreur de charge mondial échoue, Cloud DNS achemine le trafic vers les équilibreurs de charge régionaux de secours. Cette configuration utilise une règle de routage par basculement Cloud DNS.
- Actif/actif (contournement global vers régional) : un équilibreur de charge d'application externe global sert de frontend de périphérie et fournit des fonctions Cloud CDN telles que la mise en cache de périphérie. Il transfère les requêtes vers des équilibreurs de charge d'application externes régionaux à l'aide de groupes de points de terminaison réseau (NEG) Internet avec des noms de domaine complets (FQDN). En régime permanent, le trafic transite de manière séquentielle par les deux couches d'équilibrage de charge. Vous pouvez configurer cette option à l'aide d'une règle de routage de géolocalisation Cloud DNS. En cas de panne de l'équilibreur de charge mondial, les règles de routage DNS contournent la couche mondiale et acheminent le trafic client directement vers les équilibreurs de charge régionaux.
En règle générale, si votre architecture ne repose pas sur l'équilibrage de charge de backend global tenant compte de la capacité, préférez la stratégie actif-actif. Toutefois, si votre application nécessite explicitement un équilibrage de charge de backend mondial pour distribuer et déverser le trafic entre les régions en fonction de la capacité du backend, implémentez la stratégie actif-passif.
Comparaison des stratégies de basculement
Le tableau suivant compare les stratégies de basculement actif-passif et actif-actif :
| Attribut de stratégie | Actif-Passif | Actif-Actif |
|---|---|---|
| Flux de trafic en régime permanent | Client → Équilibreur de charge d'application externe global → Backend | Client → Équilibreur de charge d'application externe global → Équilibreur de charge d'application externe régional → Backend |
| Flux de trafic en cas d'échec | Client → Équilibreur de charge d'application externe régional → Backend. Le service reste disponible, mais la latence peut être plus élevée en raison de la perte des avantages liés aux performances en périphérie. |
Client → Équilibreur de charge d'application externe régional → Backend (en contournant l'équilibreur de charge d'application externe global). Le service reste disponible, mais la latence peut être plus élevée en raison de la perte des avantages liés aux performances en périphérie. |
| Gestion de la configuration | Nécessite la synchronisation de configurations indépendantes entre les équilibreurs de charge mondiaux et régionaux. | La couche globale nécessite une configuration minimale, car la majeure partie de la logique applicative réside dans les équilibreurs de charge régionaux. Toutefois, vous devez dupliquer les stratégies de sécurité de périphérie (Cloud Armor) et la configuration de terminaison de connexion (certificats TLS) sur les deux couches. |
| Validation de la fiabilité | L'équilibreur de charge d'application externe régional est inactif en état stable. Nous vous recommandons d'effectuer des tests périodiques ou d'envoyer un trafic DNS régulier. | Le trafic à l'état stable teste en continu l'équilibreur de charge d'application externe régional. Nous vous recommandons d'effectuer des tests périodiques ou d'envoyer un trafic minime directement à l'équilibreur de charge régional. |
| Sécurité du déploiement progressif | Les modifications apportées à la configuration de l'équilibreur de charge d'application externe global s'appliquent à l'ensemble du réseau. Les modifications apportées aux équilibreurs de charge d'application externes régionaux sont isolées, mais le trafic en régime permanent ne les teste pas. | Vous pouvez appliquer progressivement les modifications apportées à l'équilibreur de charge d'application externe régional, région par région. Si une région échoue, la couche globale redirige automatiquement le trafic vers des régions opérationnelles. |
| Équilibrage de charge de backend au niveau mondial | Compatible L'équilibreur de charge d'application externe global peut équilibrer le trafic entre les backends de différentes régions en fonction de la capacité. |
Limitée L'équilibreur de charge d'application externe mondial achemine le trafic vers l'équilibreur de charge d'application externe régional le plus proche. L'équilibreur de charge régional équilibre le trafic localement uniquement et ne le répartit pas entre les régions en fonction de la capacité du backend. |
| Coûts et facturation | Les frais de traitement des données s'appliquent à une seule couche d'équilibrage de charge. En état stable, les coûts proviennent de l'équilibreur de charge d'application externe global. Les frais liés à l'équilibreur de charge d'application externe régional ne s'appliquent que lors des tests ou des événements de basculement. | Les deux couches d'équilibrage de charge génèrent simultanément des frais de traitement des données, car le trafic transite par les niveaux mondiaux et régionaux en état stable. |
| Cas d'utilisation recommandé | Charges de travail nécessitant un équilibrage de charge de backend mondial avancé et un débordement du trafic basé sur la capacité dans les régions. | Charges de travail conçues autour de l'isolation régionale qui utilisent la couche globale pour les performances et la mise en cache en périphérie. |
Stratégie actif-passif
Dans une configuration actif-passif, vous déployez des équilibreurs de charge d'application externes régionaux indépendants dans une ou plusieurs régions, en plus de votre équilibreur de charge d'application externe mondial ou classique principal.
Fonctionnement du basculement actif-passif
La configuration suivante illustre le basculement d'un équilibreur de charge d'application externe global vers deux équilibreurs de charge d'application externes régionaux de secours, un dans chaque région où l'équilibreur de charge global a déployé des backends.
Le basculement actif-passif suit ce workflow :
- État stable : Cloud DNS achemine tout le trafic client vers l'équilibreur de charge d'application externe global.
- Détection des défaillances : Google Cloud utilise des vérifications de l'état configurées avec trois régions sources pour détecter si l'équilibreur de charge principal est opérationnel. Si les vérifications de l'état provenant d'au moins deux régions sources échouent, Cloud DNS déclenche le basculement.
- Basculement : les règles de routage avec basculement Cloud DNS acheminent le trafic client directement vers les équilibreurs de charge d'application externes régionaux de sauvegarde. Impact de la latence lors du basculement : comme les équilibreurs de charge d'application externes régionaux mettent fin aux connexions dans une région Google Cloud spécifique, les clients situés loin de la région de destination peuvent subir une latence et des temps d'aller-retour (DAR) plus élevés lorsque le basculement est actif.
- Rétablissement : une fois les vérifications de l'état à nouveau réussies, Cloud DNS restaure automatiquement le trafic vers l'équilibreur de charge principal sans temps d'arrêt, car les deux équilibreurs de charge diffusent du trafic.
Stratégie actif-actif (contournement global vers régional)
Dans une stratégie actif-actif, l'équilibreur de charge d'application externe global utilise un NEG FQDN Internet (INTERNET_FQDN_PORT) pour envoyer le trafic vers des équilibreurs de charge d'application externes régionaux dans au moins deux régions.
Fonctionnement du contournement actif-actif
La configuration suivante illustre le basculement d'un équilibreur de charge d'application externe global vers deux équilibreurs de charge d'application externes régionaux de secours, un dans chaque région où l'équilibreur de charge global a déployé des backends.
Le basculement actif-actif suit ce workflow :
- État stable : le trafic transite du client vers l'équilibreur de charge d'application externe mondial.
L'équilibreur de charge global utilise un groupe de points de terminaison réseau (NEG) Internet avec nom de domaine complet (FQDN) de type
INTERNET_FQDN_PORTpour transférer le trafic vers les équilibreurs de charge d'application externes régionaux les plus proches. Les équilibreurs de charge régionaux distribuent ensuite le trafic vers les backends locaux. - Détection des défaillances : en état stable, si un équilibreur de charge d'application externe régional ou sa région échouent, l'équilibreur de charge d'application externe mondial détecte l'échec à l'aide de la règle de vérification de l'état Cloud DNS sur le NEG Internet. L'équilibreur de charge mondial achemine automatiquement le trafic depuis la région non opérationnelle vers les équilibreurs de charge régionaux opérationnels.
- Contournement : si l'équilibreur de charge d'application externe global subit une panne, les règles de basculement Cloud DNS détectent l'échec et acheminent le trafic directement vers les équilibreurs de charge d'application externes régionaux, en contournant complètement la couche globale. Impact de la latence lors du contournement : l'équilibreur de charge d'application externe mondial offre des avantages en termes de performances en périphérie, comme l'interruption des connexions plus près des utilisateurs et la mise en cache en périphérie. Lorsque le trafic contourne l'équilibreur de charge mondial, les connexions client s'établissent directement avec les adresses IP virtuelles régionales, ce qui peut augmenter la latence de connexion et le DAR pour les clients géographiquement éloignés.
- Rétablissement : lorsque l'équilibreur de charge mondial réussit plusieurs vérifications de l'état consécutives, Cloud DNS recommence automatiquement à renvoyer la VIP Anycast mondiale dans les réponses DNS, ce qui rétablit le niveau de routage mondial en périphérie.
Vérifier la configuration de l'équilibreur de charge principal
Avant de configurer le basculement, vérifiez que l'équilibreur de charge d'application externe régional de sauvegarde est compatible avec les fonctionnalités utilisées par l'équilibreur de charge principal.
- En mode actif-passif, l'équilibreur de charge régional de sauvegarde doit être compatible avec des fonctionnalités similaires pour prendre le relais du trafic de manière fluide en cas de panne.
- En mode actif/actif, les règles de routage et de sécurité de base doivent être configurées directement au niveau régional, tandis que les fonctionnalités périphériques mondiales, telles que Cloud CDN, sont contournées en cas de panne mondiale.
| Fonctionnalité | Configuration requise |
|---|---|
| Déploiements Google Kubernetes Engine | Utilisez GKE Gateway pour déployer les équilibreurs de charge principaux et de sauvegarde. En effet, les équilibreurs de charge déployés à l'aide de GKE Gateway sont plus compatibles avec ce mécanisme de basculement que ceux déployés à l'aide du contrôleur d'entrée GKE. Le contrôleur GKE Ingress n'est compatible qu'avec l'équilibreur de charge d'application classique. |
| Cloud CDN | Les équilibreurs de charge d'application externes régionaux ne sont pas compatibles avec Cloud CDN. En cas de basculement, les opérations reposant sur Cloud CDN sont affectées. |
| Cloud Armor | Si vous utilisez Cloud Armor sur l'équilibreur de charge principal, configurez des règles de sécurité Cloud Armor régionales équivalentes sur les équilibreurs de charge de sauvegarde. Cloud Armor propose différentes fonctionnalités selon qu'il s'agit d'un champ d'application régional ou mondial. Pour en savoir plus, consultez Règles de sécurité Cloud Armor régionales et Règles de sécurité Cloud Armor globales. |
| Certificats SSL | Vérifiez que le type de certificat SSL utilisé par l'équilibreur de charge principal est compatible avec l'équilibreur de charge d'application externe régional de sauvegarde. Examinez les différences entre les certificats SSL disponibles avec les équilibreurs de charge mondiaux, régionaux et classiques. Pour en savoir plus, consultez Certificats SSL Compute Engine et Certificats SSL Certificate Manager. |
Points à prendre en compte pour les équilibreurs de charge régionaux
Configurez et déployez des équilibreurs de charge d'application externes régionaux dans la région vers laquelle vous souhaitez que le trafic soit redirigé en cas de défaillance.
Tenez compte des points suivants pour les architectures de basculement ou de contournement lorsque vous configurez votre équilibreur de charge régional :
Vous devez configurer les fonctionnalités de l'équilibreur de charge d'application externe régional de sauvegarde pour qu'elles soient aussi semblables que possible à celles de l'équilibreur de charge principal. Le trafic sera ainsi traité de manière similaire dans les deux déploiements.
Équilibreur de charge d'application externe mondial. Les équilibreurs de charge d'application externes régionaux sont compatibles avec la plupart des fonctionnalités des équilibreurs de charge d'application externes mondiaux, à quelques exceptions près. L'équilibreur de charge régional est également compatible avec les mêmes fonctionnalités avancées de gestion du trafic que l'équilibreur de charge mondial, ce qui facilite l'obtention d'une équivalence entre les équilibreurs de charge principaux et de secours.
Équilibreur de charge d'application classique. Avec l'équilibreur de charge d'application classique, il est plus difficile d'obtenir une parité des fonctionnalités entre l'équilibreur de charge principal et celui de sauvegarde, car l'équilibreur de charge d'application externe régional est un équilibreur de charge basé sur Envoy qui traite le trafic différemment. Assurez-vous de tester minutieusement le basculement et le retour à l'état initial avant de déployer en production.
Pour consulter les fonctionnalités spécifiques des équilibreurs de charge d'application régionaux, mondiaux et classiques, consultez la page Comparaison des fonctionnalités de l'équilibreur de charge.
Nous vous recommandons d'utiliser un framework d'automatisation tel que Terraform pour vous aider à obtenir et à maintenir la cohérence des configurations d'équilibreur de charge dans les déploiements principaux et de sauvegarde.
Les équilibreurs de charge d'application externes régionaux sont compatibles avec les niveaux de service réseau Premium et Standard. Si la latence n'est pas votre principale préoccupation lors du basculement, nous vous recommandons de configurer les équilibreurs de charge d'application externes régionaux de sauvegarde à l'aide du niveau Standard. L'utilisation de l'infrastructure de niveau Standard offre une isolation supplémentaire par rapport à l'infrastructure de niveau Premium utilisée par les équilibreurs de charge d'application externes mondiaux.
Assurez-vous que le sous-réseau proxy réservé est suffisamment dimensionné pour gérer l'augmentation du trafic en cas de basculement, sans perturber les autres équilibreurs de charge régionaux dans la même région et le même réseau. Pour en savoir plus, consultez la section Réserver de la capacité supplémentaire pour le sous-réseau proxy réservé.
Pour apprendre à configurer un équilibreur de charge d'application externe régional, consultez Configurer un équilibreur de charge d'application externe régional avec des backends de groupes d'instances de VM.
Réserver de la capacité supplémentaire pour le sous-réseau proxy réservé
Tous les équilibreurs de charge régionaux basés sur Envoy d'une région et d'un réseau VPC partagent le même pool de proxys Envoy. En cas de basculement, les équilibreurs de charge d'application externes régionaux de sauvegarde constatent une augmentation de l'utilisation du proxy pour gérer le trafic de basculement provenant de l'équilibreur de charge principal. Réserver une capacité de proxy suffisante permet de s'assurer que les événements de basculement ne perturbent pas les autres équilibreurs de charge régionaux basés sur Envoy dans la même région et le même réseau.
Pour vous assurer que la capacité est toujours disponible pour les équilibreurs de charge de sauvegarde, vérifiez la taille de votre sous-réseau proxy réservé. Nous vous recommandons de calculer le nombre estimé de proxys nécessaires pour gérer le trafic dans une région donnée et d'augmenter la capacité si nécessaire. Pour en savoir plus sur les limites de capacité des proxys et les calculs de dimensionnement, consultez la section Frais d'instance de proxy dans "Tarifs de Cloud Load Balancing".
Si vous utilisez des règles DNS pour répartir le trafic entre plusieurs équilibreurs de charge de sauvegarde dans différentes régions, vous devez en tenir compte lorsque vous estimez les exigences de proxy par région et par réseau. Un sous-réseau proxy réservé plus grand permet àGoogle Cloud d'attribuer un plus grand nombre de proxys Envoy à votre équilibreur de charge si nécessaire.
Vous ne pouvez pas développer un sous-réseau proxy réservé de la même manière qu'une plage d'adresses principale (à l'aide de la commande expand-ip-range). Au lieu de cela, vous devez créer un sous-réseau proxy réservé de secours qui répond à vos besoins, puis le promouvoir à un rôle actif.
Pour savoir comment modifier la taille de votre sous-réseau proxy réservé, consultez Modifier la taille ou la plage d'adresses d'un sous-réseau proxy réservé.
Partager des backends entre les équilibreurs de charge principaux et de secours
Pour obtenir une redondance complète de l'infrastructure, vous devez introduire la redondance au niveau de l'équilibreur de charge et au niveau du backend. Cela signifie que vous devez configurer vos équilibreurs de charge d'application externes régionaux de sauvegarde avec des backends (groupes d'instances ou groupes de points de terminaison du réseau) qui ne se chevauchent pas avec les équilibreurs de charge principaux.
Si vous choisissez d'utiliser les mêmes backends pour les équilibreurs de charge principal et de sauvegarde, vous devez créer chaque équilibreur de charge d'application externe régional de sauvegarde dans la région où se trouvent ces backends. De plus, si l'autoscaling est activé pour les groupes d'instances, vous devez remplir les conditions suivantes pour vous assurer que le basculement se produit correctement :
- Configurez l'autoscaler avec un scaling basé uniquement sur le processeur. L'autoscaling basé sur l'utilisation de l'équilibreur de charge n'est pas accepté.
- Les services de backend globaux et régionaux ne doivent utiliser que le mode d'équilibrage
UTILIZATION. N'utilisez pas le mode d'équilibrageRATE, car vos instances pourraient recevoir deux fois le trafic des équilibreurs de charge mondiaux et régionaux pendant le processus de basculement. - Configurez les commandes de scaling vertical pour empêcher l'autoscaler de réduire prématurément la taille du groupe pendant les périodes d'inactivité, lorsque le trafic passe de l'équilibreur de charge mondial à l'équilibreur de charge régional. Cette indisponibilité peut atteindre la somme du TTL (Time To Live) du DNS et de l'intervalle de vérification de l'état configuré.
Si vous ne configurez pas correctement l'autoscaling, vous risquez de subir une panne secondaire lors du basculement, car la perte de trafic de l'équilibreur de charge mondial entraîne une réduction rapide du groupe d'instances avant que l'équilibreur de charge régional ne prenne le relais.
Configurer le basculement actif-passif
Pour configurer le basculement actif-passif, procédez comme suit :
- Examiner les considérations relatives à l'architecture : avant de créer des ressources, consultez les considérations relatives aux équilibreurs de charge régionaux pour vérifier la compatibilité des fonctionnalités, la capacité du proxy et les exigences d'autoscaling des backends partagés.
- Configurer l'équilibreur de charge principal : configurez votre équilibreur de charge d'application externe global avec des services de backend répartis sur une ou plusieurs régions. Pour savoir comment configurer un équilibreur de charge d'application externe global, consultez Configurer un équilibreur de charge d'application externe global.
- Vérifiez la configuration de l'équilibreur de charge principal : assurez-vous que les fonctionnalités (telles que les fonctionnalités de sécurité, de gestion du trafic et de routage, ainsi que Cloud CDN) utilisées par l'équilibreur de charge principal sont disponibles avec l'équilibreur de charge d'application externe régional de sauvegarde. Si des fonctionnalités similaires ne sont pas disponibles, cet équilibreur de charge n'est peut-être pas un bon candidat pour le basculement.
- Configurez les équilibreurs de charge d'application externes régionaux de sauvegarde : configurez des équilibreurs de charge d'application externes régionaux indépendants dans les régions vers lesquelles vous souhaitez que le trafic bascule. Pour savoir comment configurer un équilibreur de charge d'application externe régional, consultez Configurer un équilibreur de charge d'application externe régional avec des backends de groupes d'instances de VM.
- Configurer le routage DNS et les vérifications de l'état : créez une vérification de l'état de l'état pour l'équilibreur de charge principal et configurez une règle de routage de basculement Cloud DNS pour détecter les pannes et acheminer le trafic client vers les équilibreurs de charge régionaux de secours.
Configurer le contournement actif/actif
Pour configurer l'architecture actif-actif, procédez comme suit :
Examinez les points à prendre en compte concernant l'architecture : avant de créer des ressources, consultez les points à prendre en compte pour les équilibreurs de charge régionaux afin de vérifier la compatibilité des fonctionnalités et de vous assurer que la capacité de votre sous-réseau proxy réservé peut gérer le trafic en état stable et en cas de basculement.
Configurer des équilibreurs de charge d'application externes régionaux : avant de configurer des équilibreurs de charge régionaux, consultez Compatibilité et limites des fonctionnalités. Déployez des équilibreurs de charge d'application externes régionaux dans au moins deux régions avec vos services de backend, vos adresses IP externes, vos certificats SSL et vos règles de sécurité Cloud Armor régionales. Pour obtenir des instructions de configuration, consultez Configurer un équilibreur de charge d'application externe régional avec des backends de groupes d'instances de VM.
Configurer le DNS pour les équilibreurs de charge régionaux : créez un enregistrement DNS (par exemple,
regional-api.example.com) qui pointe vers les adresses IP externes de vos équilibreurs de charge d'application externes régionaux à l'aide d'une règle de routage de géolocalisation ou de latence. Activez la vérification de l'état DNS sur cet enregistrement pour détecter une défaillance dans une région spécifique et rediriger automatiquement le trafic vers d'autres régions opérationnelles.Configurez l'équilibreur de charge d'application externe mondial : réservez une adresse IP externe mondiale et créez un groupe de points de terminaison réseau (NEG) Internet mondial de type
INTERNET_FQDN_PORT. Ajoutez un point de terminaison au NEG Internet pointant vers le nom de domaine complet de l'enregistrement DNS régional, par exempleregional-api.example.com. Configurez un service de backend pour l'équilibreur de charge d'application externe mondial, associez le NEG Internet et activez Cloud CDN ou Cloud Armor si nécessaire. Configurez le mappage d'URL, le proxy HTTP(S) cible et la règle de transfert globale.Configurer le DNS pour le basculement et les vérifications de l'état : créez l'enregistrement DNS du service principal (par exemple,
api.example.com) à l'aide d'une règle de routageFAILOVER. Assurez-vous que l'ensemble d'enregistrements comporte un point de terminaison principal pointant vers l'adresse IP de l'équilibreur de charge d'application externe global et des points de terminaison de sauvegarde pointant vers les adresses IP externes des équilibreurs de charge d'application externes régionaux. Configurez un vérification de l'état DNS pour surveiller l'équilibreur de charge d'application externe global.
Bonnes pratiques
Tenez compte des bonnes pratiques suivantes lorsque vous configurez l'enregistrement Cloud DNS et les vérifications d'état :
Calculer la durée de l'indisponibilité : le temps nécessaire pour que le trafic bascule des équilibreurs de charge principaux vers les équilibreurs de charge de secours dépend de la valeur TTL du DNS, de l'intervalle de vérification de l'état de l'état et du paramètre seuil de non-fonctionnement de la vérification de l'état :
Avec Cloud DNS de Google, la limite supérieure de cette période peut être calculée à l'aide de la formule suivante :
Duration of outage = DNS TTL + Health Check Interval * Unhealthy ThresholdDéfinissez le TTL DNS sur 30 à 60 secondes. Des valeurs TTL plus élevées entraînent des temps de basculement plus longs, car les clients sur Internet continuent d'accéder aux équilibreurs de charge d'application externes principaux, même après que le DNS a basculé vers l'équilibreur de charge d'application externe régional de sauvegarde.
Configurez les vérification de l'état l'état : définissez les paramètres Seuil opérationnel et Seuil non opérationnel pour éviter les basculements causés par des erreurs réseau temporaires. Des seuils plus élevés augmentent le temps nécessaire pour que le trafic bascule vers les équilibreurs de charge de sauvegarde.
Utiliser le trafic minime pour la validation : configurez l'indicateur
--backup-data-trickle-ratiopour envoyer en continu un petit pourcentage de trafic aux équilibreurs de charge de secours, même lorsque les équilibreurs de charge principaux sont opérationnels. Cela garantit que l'infrastructure de sauvegarde est active et prête à gérer le trafic. Vous pouvez configurer le pourcentage du trafic envoyé vers les équilibreurs de charge de secours sous la forme d'une fraction comprise entre 0 et 1. La valeur typique est 0, 1, bien que Cloud DNS vous permette d'envoyer 100 % du trafic vers les adresses VIP de secours pour déclencher manuellement un basculement.Testez régulièrement le basculement et la restauration : incluez des tests de basculement dans votre plan de reprise après sinistre. Vérifiez les changements de trafic progressifs et soudains entre les équilibreurs de charge principal et de sauvegarde, et assurez-vous que le trafic revient en douceur vers l'équilibreur de charge principal après le rétablissement.