Cette page décrit le fonctionnement du basculement pour les équilibreurs de charge d'application externes. La configuration de basculement implique deux équilibreurs de charge : un équilibreur de charge principal et un équilibreur de charge de secours. Pour les besoins de cette discussion, l'équilibreur de charge principal est l'équilibreur de charge pour lequel vous souhaitez configurer le basculement. L'équilibreur de charge de secours est l'équilibreur de charge qui reçoit les connexions lorsque l'équilibreur de charge principal commence à échouer aux vérifications d'état.
Le basculement et la restauration sont des processus automatiques qui acheminent le trafic vers et depuis un équilibreur de charge. Lorsque Cloud DNS détecte une panne et achemine le trafic de l'équilibreur de charge principal vers l'équilibreur de charge de secours, le processus est appelé basculement. Lorsque Cloud DNS inverse cette opération et redirige le trafic vers l'équilibreur de charge principal, le processus est appelé restauration.
Fonctionnement du basculement
Le basculement de "global" à "régional" pour les équilibreurs de charge d'application externes est géré en créant deux ou plusieurs équilibreurs de charge d'application externes régionaux dans les régions vers lesquelles vous souhaitez que le trafic bascule. Seuls les équilibreurs de charge d'application externes régionaux peuvent être utilisés comme équilibreurs de charge de secours. Les équilibreurs de charge d'application externes régionaux ne sont pas seulement autonomes dans des régions Google Cloud individuelles, mais sont également isolés de tout équilibreur de charge d'application externe global ou de toute infrastructure d'équilibreur de charge d'application classique s'exécutant dans la même région.
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 sont tous deux basés sur des proxys Envoy et traitent le trafic de manière très similaire. Contrairement à un équilibreur de charge d'application classique, qui présente des différences notables dans la gestion du trafic.
En résumé, les scénarios de basculement suivants sont acceptés :
- D'un équilibreur de charge d'application externe global à un équilibreur de charge d'application externe régional
- D'un équilibreur de charge d'application externe régional à un autre
- Passer d'un équilibreur de charge d'application classique à un équilibreur de charge d'application externe régional
Workflow de basculement et de restauration
La configuration suivante illustre le basculement d'un équilibreur de charge d'application externe global vers deux équilibreurs de charge d'application externe régionaux, un dans chaque région où l'équilibreur de charge global a déployé des backends.
Les sections suivantes décrivent un workflow type avec les différents composants impliqués dans une configuration de basculement.
Détecter les défaillances de l'équilibreur de charge principal
Google Cloud utilise des vérifications d'état pour détecter si votre équilibreur de charge d'application externe principal est opérationnel. Vous configurez ces vérifications d'état pour envoyer des vérifications à partir de trois régions sources. Ces trois régions sources doivent représenter les régions à partir desquelles vos clients accéderont à l'équilibreur de charge. Par exemple, si vous disposez d'un équilibreur de charge d'application externe global et que la majeure partie de votre trafic client provient d'Amérique du Nord et d'Europe, vous pouvez configurer des sondes provenant de deux régions en Amérique du Nord et d'une région en Europe.
Si les vérifications d'état provenant de deux régions ou plus échouent, le basculement vers l'équilibreur de charge d'application externe régional de secours est déclenché.
Remarques supplémentaires :
- Vous devez spécifier exactement trois régions sources lorsque vous créez la vérification d'état. Seules les vérifications d'état globales peuvent spécifier des régions sources.
- Les vérifications d'état HTTP, HTTPS et TCP sont prise en charge.
- Les vérifications d'état proviennent en fait d'un point de présence (PoP) sur Internet situé à une courte distance de la région source Google Cloud configurée.
Router le trafic vers les équilibreurs de charge de secours
Si l'équilibreur de charge principal commence à échouer aux vérifications d'état, Google Cloud utilise les règles de routage de basculement Cloud DNS pour déterminer comment acheminer le trafic vers les équilibreurs de charge de secours.
La durée de l'indisponibilité, ou le temps nécessaire pour que le trafic bascule de l'équilibreur de charge principal vers l'équilibreur de charge de secours, est déterminée par la valeur TTL du DNS, l'intervalle de vérification de l'état l'état et le seuil de non-fonctionnement de la vérification de l'état. Pour connaître les paramètres recommandés, consultez la section Bonnes pratiques.
Retour à l'équilibreur de charge principal
Une fois que les vérifications d'état commencent à réussir à nouveau, le basculement vers l'équilibreur de charge principal est automatique. Aucun temps d'arrêt n'est prévu lors du basculement, car les équilibreurs de charge de secours et principaux desservent le trafic.
Testez le basculement régulièrement.
Nous vous recommandons de tester régulièrement le workflow de basculement dans le cadre de votre plan de continuité d'activité. Veillez à tester les transferts de trafic graduels et instantanés de l'équilibreur de charge principal vers l'équilibreur de charge de secours. Après avoir vérifié que le basculement fonctionne, déclenchez un basculement pour vérifier que le trafic est redirigé vers l'équilibreur de charge principal comme prévu.
Configurer le basculement
Pour configurer le basculement, procédez comme suit :
- Vérifiez la configuration de votre équilibreur de charge principal existant et assurez-vous que les fonctionnalités (telles que les fonctionnalités de sécurité, de gestion du trafic et de routage, ainsi que le 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 adapté à la bascule.
- Créez l'équilibreur de charge d'application externe régional de secours avec une configuration qui reflète autant que possible l'équilibreur de charge principal.
- Créez la vérification de l'état et la règle de routage DNS pour détecter les pannes et acheminer le trafic de l'équilibreur de charge principal vers l'équilibreur de charge de secours en cas de basculement.
Vérifier la configuration de l'équilibreur de charge principal
Avant de commencer, vérifiez que l'équilibreur de charge d'application externe régional de secours est compatible avec toutes les fonctionnalités actuellement utilisées avec votre équilibreur de charge principal.
Pour éviter toute interruption du trafic, examinez les différences suivantes :
Déploiements GKE. Les utilisateurs de GKE doivent noter que les équilibreurs de charge déployés à l'aide de GKE Gateway sont plus compatibles avec ce mécanisme de basculement que les équilibreurs de charge déployés à l'aide du contrôleur GKE Ingress. En effet, GKE Gateway prend en charge la configuration des équilibreurs de charge d'application externes globaux et régionaux. Toutefois, le contrôleur GKE Ingress n'est compatible qu'avec l'équilibreur de charge d'application classique.
Pour de meilleurs résultats, utilisez GKE Gateway pour déployer à la fois l'équilibreur de charge principal et de secours.
Cloud CDN. Les équilibreurs de charge d'application externes régionaux ne sont pas compatibles avec Cloud CDN. Par conséquent, en cas de défaillance, toutes les opérations reposant sur Cloud CDN sont également affectées. Pour une meilleure redondance, nous vous recommandons de configurer une solution CDN tierce pouvant servir de solution de secours à Cloud CDN.
Google Cloud Armor. Si vous utilisez Google Cloud Armor pour votre équilibreur de charge principal, assurez-vous de configurer également les mêmes fonctionnalités Google Cloud Armor lorsque vous configurez l'équilibreur de charge d'application externe régional de secours. Google Cloud Armor propose différentes fonctionnalités en fonction de la portée régionale ou mondiale. Pour en savoir plus, consultez les sections suivantes de la documentation Google Cloud Armor :
Certificats SSL. Si vous souhaitez utiliser un certificat SSL commun pour les équilibreurs de charge principaux et de secours, vérifiez que le type de certificat SSL utilisé avec 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 les sections suivantes :
Buckets backend. Les équilibreurs de charge d'application externes régionaux ne sont pas compatibles avec les buckets Cloud Storage en tant que backends. Vous ne pouvez pas configurer le basculement pour les équilibreurs de charge à l'aide de buckets backend.
Configurer l'équilibreur de charge de secours
L'équilibreur de charge de secours est un équilibreur de charge d'application externe régional que vous configurez dans la région vers laquelle vous souhaitez rediriger le trafic en cas de défaillance.
Tenez compte des points suivants lorsque vous configurez votre équilibreur de charge de secours :
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 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 la parité des fonctionnalités entre l'équilibreur de charge principal et l'équilibreur de charge de secours, 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 le basculement et le basculement inverse de manière approfondie 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 la cohérence des configurations d'équilibreur de charge à la fois pour les déploiements principaux et de secours.
Nous vous recommandons de configurer des équilibreurs de charge d'application externes régionaux de secours dans chaque région où vous disposez de backends. Par exemple, si vous effectuez un basculement à partir d'un déploiement mondial avec des groupes d'instances dans cinq régions pour sauvegarder des équilibreurs de charge régionaux dans trois régions seulement, vous risquez de surcharger vos services de backend dans ces trois régions, tandis que les services de backend des deux autres régions sont inactifs.
De plus, nous vous recommandons de configurer Cloud DNS pour qu'il utilise des règles de round robin pondéré lors du réacheminement du trafic de basculement d'un équilibreur de charge mondial principal vers ces équilibreurs de charge régionaux de secours. Attribuez des pondérations à chaque équilibreur de charge de secours en tenant compte des tailles maximales des groupes d'instances backend dans différentes régions.
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 secours à 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.
Si vous souhaitez utiliser les mêmes backends pour les équilibreurs de charge principaux et de secours, créez l'équilibreur de charge d'application externe régional de secours dans la région où se trouvent les backends. Si vous avez activé l'autoscaling pour les groupes d'instances backend, vous devez respecter les exigences de partage des backends entre les déploiements.
Si nécessaire, réservez des proxys Envoy supplémentaires pour les équilibreurs de charge d'application externes régionaux afin de vous assurer qu'en cas de basculement, le trafic supplémentaire ne perturbe pas les autres déploiements d'équilibreurs de charge dans la même région. 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, l'utilisation des proxys augmente pour les équilibreurs de charge d'application externes régionaux de secours afin de gérer le trafic de basculement de l'équilibreur de charge principal. Pour vous assurer que la capacité est toujours disponible pour les équilibreurs de charge de secours, nous vous recommandons de vérifier 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. Cela permet également 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 sur le même réseau.
En règle générale, un proxy d'équilibreur de charge d'application externe régional peut gérer jusqu'à :
- 600 nouvelles connexions HTTP ou 150 nouvelles connexions HTTPS par seconde
- 3 000 connexions actives
- 1 400 requêtes par seconde
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 exigences de proxy par région et par réseau. Un sous-réseau proxy réservé plus volumineux 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 la section 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 d'infrastructure complète, vous devez introduire une redondance au niveau de l'équilibreur de charge et du backend. Cela signifie que vous devez configurer vos équilibreurs de charge d'application externes régionaux de secours avec des backends (groupes d'instances ou groupes de points de terminaison réseau) qui ne se chevauchent pas avec les équilibreurs de charge principaux.
Toutefois, si vous souhaitez partager un groupe d'instances backend entre les équilibreurs de charge principaux et secondaires, et que l'autoscaling est activé pour les groupes d'instances, vous devez remplir les conditions suivantes pour vous assurer que le basculement se produit correctement :
- L'autoscaler doit être configuré avec un scaling basé sur le processeur uniquement. La méthode d'ajustement basée sur l'utilisation de l'équilibreur de charge n'est pas prise en charge.
- Les services de backend globaux et régionaux ne doivent utiliser que le mode d'équilibrage
UTILIZATION. Il est déconseillé d'utiliser 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. - Les commandes de scaling vertical doivent être configurées 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 période d'indisponibilité peut être aussi longue que la somme du TTL DNS et de l'intervalle de vérification de l'état'é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.
Configurer Cloud DNS et les vérifications de l'état
Cette section explique comment utiliser Cloud DNS et les vérifications de l'état Google Cloud pour configurer votre environnement Cloud Load Balancing afin de détecter les pannes et de router le trafic vers les équilibreurs de charge de secours.
Procédez comme suit pour configurer les règles de routage et de vérification d'état requises :
Créez une vérification de l'état pour l'adresse IP de la règle de transfert de l'équilibreur de charge principal.
gcloud beta 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_PATHRemplacez les éléments suivants :
HEALTH_CHECK_NAME: nom de la vérification d'étatSOURCE_REGION: les trois régions Google Cloud à partir desquelles les vérifications d'état sont effectuées. Vous devez spécifier exactement trois régions sources.HEALTH_CHECK_INTERVAL: durée en secondes entre le début d'une vérification émise par un vérificateur et le début de la vérification suivante émise par le même vérificateur. La valeur minimale acceptée est de 30 secondes. Pour connaître les valeurs recommandées, consultez la section Bonnes pratiques.HEALTHY_THRESHOLDetUNHEALTHY_THRESHOLD: nombre de tests séquentiels qui doivent réussir ou échouer pour que l'instance de VM soit considérée comme opérationnelle ou non opérationnelle. Si l'une de ces valeurs est omise, Google Cloud utilise le seuil par défaut défini sur 2.REQUEST_PATH: Indique le chemin de l'URL à laquelle Google Cloud envoie des requêtes de vérification d'état. En cas d'omission, Google Cloud envoie les requêtes de vérification au chemin racine, /. Si les points de terminaison faisant l'objet d'une vérification de l'état sont privés, ce qui n'est pas courant pour les adresses IP de règles de transfert externes, vous pouvez définir ce chemin sur/afhealthz.
Créez un jeu d'enregistrements Cloud DNS dans Cloud DNS et appliquez-lui une règle de routage. La stratégie de routage doit être configurée pour résoudre votre nom de domaine en l'adressant à l'adresse IP de la règle de transfert de l'équilibreur de charge principal ou, en cas d'échec de la vérification de l'état de l'état, à l'une des adresses IP de la règle de transfert des équilibreurs de charge de secours.
gcloud beta 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_RATIORemplacez les éléments suivants :
DNS_RECORD_SET_NAME: nom DNS ou nom de domaine du jeu d'enregistrements à ajouter (par exemple,test.example.com)TIME_TO_LIVE: valeur TTL (Time To Live) du jeu d'enregistrements exprimée en nombre de secondes. Pour connaître les valeurs recommandées, consultez la section Bonnes pratiques.RECORD_TYPE: type d'enregistrement (par exemple,A)MANAGED_ZONE_NAME: nom de la zone gérée dont vous souhaitez gérer les jeux d'enregistrements (par exemple,my-zone-name)PRIMARY_LOAD_BALANCER_FORWARDING_RULE: nom de la règle de transfert de l'équilibreur de charge principalBACKUP_REGION: régions où les équilibreurs de charge de secours sont déployésBACKUP_LOAD_BALANCER_IP_ADDRESS: adresses IP de la règle de transfert des équilibreurs de charge de secours correspondant à chaque régionBACKUP_DATA_TRICKLE_RATIO: ratio de trafic à envoyer aux équilibreurs de charge de secours, même si l'équilibreur de charge principal est opérationnel. Le ratio doit être entre 0 et 1 (par exemple 0,1). La valeur par défaut est 0.
Bonnes pratiques
Voici quelques bonnes pratiques à prendre en compte lors de la configuration de l'enregistrement Cloud DNS et des vérifications d'état :
Le temps nécessaire pour que le trafic soit acheminé des équilibreurs de charge principaux vers des équilibreurs de charge de secours (c'est-à-dire la durée de l'indisponibilité) dépend de la valeur TTL du DNS, de l'intervalle de vérification 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 ThresholdPour la configuration de basculement, nous vous recommandons de définir le TTL DNS sur 30 à 60 secondes. Des TTL plus élevés entraînent des temps d'arrêt plus longs, car les clients sur Internet continuent d'accéder aux équilibreurs de charge d'application externes principaux, même après la transition du DNS vers l'équilibreur de charge d'application externe régional de secours.
Configurez les paramètres de seuils "opérationnel" et "non opérationnel" dans les vérifications d'état afin d'éviter les basculements inutiles causés par des erreurs temporaires. Des seuils plus élevés augmentent le temps nécessaire pour que le trafic bascule vers les équilibreurs de charge de secours.
Pour vous assurer que votre configuration de basculement fonctionne comme prévu, vous pouvez configurer votre règle de routage DNS pour qu'elle envoie toujours un petit pourcentage de trafic aux équilibreurs de charge de secours, même lorsque les équilibreurs de charge principaux sont opérationnels. Pour ce faire, utilisez le paramètre
--backup-data-trickle-ratiolorsque vous créez l'ensemble d'enregistrements DNS.Vous pouvez configurer le pourcentage du trafic envoyé à la sauvegarde 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.