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 acheminent le trafic vers ceux-ci à partir d'un équilibreur de charge d'application externe global afin de maintenir une haute disponibilité en cas de pannes de l'infrastructure globale ou d'erreurs 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 fonctionnement 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 d'é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 d'état réussies.
Ce document traite du basculement d'un équilibreur de charge d'application externe global vers des équilibreurs de charge de secours 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, pour les raisons suivantes :
- Les équilibreurs de charge d'application externes régionaux sont autonomes dans des régionsGoogle Cloud individuelles et sont également isolés de toute infrastructure d'équilibreur de charge d'application externe globale 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 mettre en œuvre un 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 mettre en œuvre le basculement pour les équilibreurs de charge d'application externes globaux à l'aide des stratégies suivantes :
- Actif-passif (basculement global vers régional) : vous déployez un ou plusieurs équilibreurs de charge d'application externes régionaux uniquement à des fins de sauvegarde. En régime permanent, Cloud DNS résout l'adresse IP de l'équilibreur de charge d'application externe global. En cas de défaillance de l'équilibreur de charge mondial, Cloud DNS achemine le trafic vers les équilibreurs de charge régionaux de secours. Cette configuration utilise une règle de routage de basculement Cloud DNS.
- Actif-actif (contournement global vers régional) : un équilibreur de charge d'application externe global agit comme un frontend périphérique fournissant des fonctions Cloud CDN telles que la mise en cache périphérique qui transfère les requêtes aux équilibreurs de charge d'application externes régionaux à l'aide de groupes de points de terminaison du réseau (NEG) Internet avec des noms de domaine complets (FQDN). En régime permanent, le trafic passe séquentiellement par les deux couches d'équilibrage de charge. Pour ce faire, vous pouvez utiliser 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 globale et acheminent le trafic client directement vers les équilibreurs de charge régionaux.
Si votre architecture ne repose pas sur l'équilibrage de charge de backend global basé sur la capacité, nous vous recommandons d'utiliser la stratégie actif-actif. Toutefois, si votre application nécessite explicitement un équilibrage de charge de backend global pour répartir et déborder le trafic entre les régions en fonction de la capacité du backend, mettez en œuvre 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 état d'échec | Client → Équilibreur de charge d'application externe régional → Backend. Le service reste disponible, mais peut subir une latence plus élevée en raison de la perte des avantages de performances de 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 peut subir une latence plus élevée en raison de la perte des avantages de performances de périphérie. |
| Gestion de 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 d'application réside sur 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 la 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 régime permanent. Nous vous recommandons d'effectuer des tests périodiques ou d'utiliser un trafic DNS progressif. | Le trafic en régime permanent teste en continu l'équilibreur de charge d'application externe régional. Il est recommandé 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 de configuration de l'équilibreur de charge d'application externe global s'appliquent de manière globale. Les modifications apportées à l'équilibreur de charge d'application externe régional 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. En cas de défaillance d'une région, la couche globale redirige automatiquement le trafic vers des régions opérationnelles. |
| Équilibrage de charge de backend global | Compatible L'équilibreur de charge d'application externe global peut équilibrer le trafic entre des backends situés dans différentes régions en fonction de la capacité. |
Limitée L'équilibreur de charge d'application externe global achemine le trafic vers l'équilibreur de charge d'application externe régional le plus proche. L'équilibreur de charge régional n'équilibre le trafic que localement 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 régime permanent, 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 des frais de traitement des données simultanément, car le trafic transite par les niveaux mondial et régional en régime permanent. |
| 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é entre les régions. | Charges de travail conçues autour de l'isolation régionale qui utilisent la couche globale pour les performances de périphérie et la mise en cache. |
Stratégie active-passive
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 global ou de votre équilibreur de charge d'application 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 d'état configurées avec trois régions sources pour détecter si l'équilibreur de charge principal est opérationnel. Si les vérifications d'état provenant de deux régions sources ou plus é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 secours. Impact sur la latence pendant le basculement : étant donné que 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 augmentation de la latence et des délais aller-retour (DAR) lorsque le basculement est actif.
- Retour arrière : une fois que les vérifications d'état réussissent à nouveau, Cloud DNS restaure automatiquement le trafic vers l'équilibreur de charge principal sans temps d'arrêt, car les deux équilibreurs de charge diffusent le trafic.
Stratégie active-active (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 du 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 sauvegarde, 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 circule du client vers l'équilibreur de charge d'application externe global.
L'équilibreur de charge mondial utilise un groupe de points de terminaison du réseau (NEG) FQDN Internet 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 envoient ensuite le trafic aux backends locaux. - Détection des défaillances : en régime permanent, si un seul équilibreur de charge d'application externe régional ou sa région échoue, l'équilibreur de charge d'application externe global détecte la défaillance à l'aide de la règle de vérification d'état Cloud DNS sur le NEG Internet. L'équilibreur de charge mondial redirige automatiquement le trafic de la région défaillante vers des é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 la défaillance et acheminent le trafic directement vers les équilibreurs de charge d'application externes régionaux, en contournant complètement la couche globale. Impact sur la latence pendant le contournement : l'équilibreur de charge d'application externe global offre des avantages en termes de performances périphériques, tels que l'arrêt des connexions plus proches des utilisateurs et la mise en cache périphérique. Lorsque le trafic contourne l'équilibreur de charge mondial, les connexions client sont établies 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.
- Restauration : lorsque l'équilibreur de charge mondial réussit plusieurs vérifications d'état consécutives, Cloud DNS recommence automatiquement à renvoyer l'adresse IP virtuelle Anycast mondiale dans les réponses DNS, ce qui rétablit le niveau de routage périphérique mondial.
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 secours 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 secours doit être compatible avec des fonctionnalités similaires pour prendre en charge le 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 de périphérie globales, telles que Cloud CDN, sont contournées lors d'une panne globale.
| Fonctionnalité | Configuration requise |
|---|---|
| Déploiements Google Kubernetes Engine | Utilisez la passerelle GKE pour déployer des équilibreurs de charge principaux et de secours. En effet, les équilibreurs de charge déployés à l'aide de la passerelle GKE 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 qui s'appuient sur Cloud CDN sont affectées. |
| Cloud Armor | Si vous utilisez Cloud Armor sur l'équilibreur de charge principal, configurez des stratégies de sécurité Cloud Armor régionales équivalentes sur les équilibreurs de charge de secours. 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 Stratégies de sécurité Cloud Armor régionales et Stratégies 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 secours. 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. |
Remarques concernant 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 secours pour qu'elles soient aussi similaires que possible à celles de l'équilibreur de charge principal, afin que le trafic soit traité de la même manière 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, la parité des fonctionnalités entre l'équilibreur de charge principal et l'équilibreur de charge de secours est plus difficile à atteindre, car l'équilibreur de charge d'application externe régional est un équilibreur de charge basé sur Envoy qui traite le trafic différemment. Veillez à tester minutieusement le basculement et la restauration 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 assurer et maintenir la cohérence des configurations d'équilibreur de charge entre 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 lors d'un basculement sans perturber les autres équilibreurs de charge régionaux de la même région et du 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 la page Configurer un équilibreur de charge d'application externe régional avec des backends de groupe d'instances de VM.
Réserver une capacité de sous-réseau proxy réservé supplémentaire
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. La réservation d'une capacité de proxy suffisante garantit 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 sur le même réseau.
Pour vous assurer que la capacité est toujours disponible pour les équilibreurs de charge de secours, 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 secours dans différentes régions, vous devez en tenir compte lorsque vous estimez les besoins en 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 une 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 principaux et de secours, vous devez créer chaque équilibreur de charge d'application externe régional de secours 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é sur le processeur uniquement. L'autoscaling basé sur l'utilisation de l'équilibreur de charge n'est pas disponible.
- Les services de backend globaux et régionaux doivent utiliser uniquement 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 capacité du groupe pendant les périodes d'inactivité, lorsque le trafic passe de l'équilibreur de charge mondial à l'équilibreur de charge régional. Ce temps d'arrêt peut être aussi élevé que la somme de la valeur TTL (Time To Live) DNS et de l'intervalle de vérification d'é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 :
- Examinez les considérations liées à l'architecture : avant de créer des ressources, consultez les considérations liées aux équilibreurs de charge régionaux pour vérifier la compatibilité des fonctionnalités, la capacité du proxy et les exigences d'autoscaling du backend partagé.
- Configurez 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 en savoir plus sur la configuration d'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 : vérifiez que les fonctionnalités (telles que les fonctionnalités de sécurité, de gestion du trafic et de routage, et Cloud CDN) utilisées par l'équilibreur de charge principal sont disponibles avec l'équilibreur de charge d'application externe régional de secours. Si des fonctionnalités similaires ne sont pas disponibles, cet équilibreur de charge n'est peut-être pas un bon candidat pour le basculement.
- Configurer les équilibreurs de charge d'application externes régionaux de secours : 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 groupe d'instances de VM.
- Configurer le routage DNS et les vérifications d'état : créez une vérification 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 :
Examiner les considérations liées à l'architecture : avant de créer des ressources, examinez les considérations liées aux équilibreurs de charge régionaux pour vérifier la compatibilité des fonctionnalités et vous assurer que la capacité de votre sous-réseau proxy réservé peut gérer le trafic en régime permanent et le trafic 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 stratégies 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.
Configurez 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.Configurer l'équilibreur de charge d'application externe global : réservez une adresse IP externe globale et créez un groupe de points de terminaison du réseau (NEG) Internet global 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 d'é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 le jeu 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 une 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 soit acheminé des équilibreurs de charge principaux vers des é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 le basculement du DNS vers l'équilibreur de charge d'application externe régional de secours.
Configurez les vérification de l'état'état : définissez les paramètres de seuil d'état opérationnel et 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 au basculement du trafic vers les équilibreurs de charge de sauvegarde.
Utiliser le trafic minime pour la validation : configurez l'option
--backup-data-trickle-ratiopour envoyer en continu un faible 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 le retour arrière : incluez des tests de basculement dans votre plan de reprise après sinistre. Vérifiez les transferts progressifs et soudains du trafic des équilibreurs de charge principaux vers les équilibreurs de charge de secours, et vérifiez que le trafic revient sans problème vers l'équilibreur de charge principal après le basculement.