Haute disponibilité pour les équilibreurs de charge d'application externes régionaux

Cette page explique comment configurer un déploiement multirégional à disponibilité élevée avec des équilibreurs de charge d'application externes régionaux. Pour obtenir une haute disponibilité, déployez plusieurs équilibreurs de charge d'application externes régionaux individuels dans les régions qui prennent le mieux en charge le trafic de votre application. Cela fonctionne, car les équilibreurs de charge d'application externes régionaux de différentes régions ne sont pas seulement isolés les uns des autres, 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.

Stratégies de haute disponibilité

Vous pouvez mettre en œuvre la résilience interrégionale pour les équilibreurs de charge d'application externes régionaux en utilisant l'une des stratégies suivantes :

  • Actif/passif (basculement de région) : déployez un équilibreur de charge d'application externe régional principal dans votre région principale et un ou plusieurs équilibreurs de charge d'application externes régionaux de secours dans des régions secondaires. En régime permanent, Cloud DNS achemine tout le trafic vers l'équilibreur de charge principal. Si l'équilibreur de charge principal échoue aux vérifications d'état, Cloud DNS utilise une règle de routage de basculement pour acheminer le trafic vers les équilibreurs de charge régionaux de secours.

    Voici un exemple de configuration actif-passif qui montre deux équilibreurs de charge d'application externes régionaux dans deux régions différentes.

Haute disponibilité avec deux équilibreurs de charge d'application externes régionaux
Haute disponibilité avec deux équilibreurs de charge d'application externes régionaux (cliquez pour agrandir).

  • Actif-actif (routage de proximité) : déployez plusieurs équilibreurs de charge d'application externes régionaux dans différentes régions qui diffusent le trafic simultanément. Utilisez une règle de routage avec géolocalisation Cloud DNS pour diriger les clients vers la région opérationnelle la plus proche. Si un équilibreur de charge d'une région subit une panne, Cloud DNS achemine automatiquement le trafic de la région non opérationnelle vers des équilibreurs de charge opérationnels d'autres régions.

    Voici un exemple de configuration active-active qui montre deux équilibreurs de charge d'application externes régionaux dans deux régions différentes.

    Haute disponibilité avec deux équilibreurs de charge d'application externes régionaux
    Haute disponibilité avec deux équilibreurs de charge d'application externes régionaux (cliquez pour agrandir)

Les sections suivantes décrivent le fonctionnement de la vérification de l'état et de l'orientation du trafic entre les régions dans un workflow standard :

  1. Utiliser des vérifications d'état pour détecter les défaillances régionales

    Google Cloud utilise des vérifications d'état pour détecter si vos équilibreurs de charge régionaux sont opérationnels. Vous configurez ces vérifications d'état pour envoyer des vérifications à partir de trois régions sources. Ces trois régions sources doivent être représentatives des régions à partir desquelles vos clients accèdent aux équilibreurs de charge. Par exemple, si vous disposez d'un équilibreur de charge d'application externe régional dont la majorité du trafic client provient d'Amérique du Nord et d'Europe, vous pouvez avoir des vérifications provenant de deux régions ou plus en Amérique du Nord et des vérifications provenant de deux régions ou plus en Europe.

    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 d'un point of presence (PoP) sur Internet, à une courte distance de la région source Google Cloudconfigurée.

  2. Acheminer le trafic en fonction de règles de routage

    • Actif/Passif : Cloud DNS utilise une règle de routage avec basculement pour orienter 100 % du trafic client vers l'équilibreur de charge régional principal en régime permanent. Lorsque l'équilibreur de charge régional principal échoue aux vérifications d'état, Cloud DNS dirige le trafic vers les équilibreurs de charge régionaux de secours.
    • Actif-actif : Cloud DNS utilise une règle de routage de géolocalisation pour orienter le trafic vers les équilibreurs de charge. Lorsque tous les équilibreurs de charge sont opérationnels, Cloud DNS achemine le trafic vers l'équilibreur de charge le plus proche géographiquement du client. Lorsqu'un équilibreur de charge d'une région commence à échouer aux vérifications d'état, le trafic est automatiquement redirigé vers les équilibreurs de charge disponibles et opérationnels dans d'autres régions.

  3. Retour arrière vers l'équilibreur de charge principal

    Le failback est automatique lorsque les vérifications d'état redeviennent positives. Le trafic est restauré sans temps d'arrêt, car les équilibreurs de charge diffusent le trafic.

Configurer l'équilibrage de charge multirégional

Pour configurer un déploiement multirégional facilitant la haute disponibilité, procédez comme suit :

  1. Créez des équilibreurs de charge d'application externes régionaux dans les régions qui, selon vous, prennent le mieux en charge le trafic de votre application. Chacun de ces équilibreurs de charge doit avoir les mêmes configurations de gestion du trafic et de sécurité.
  2. Créez des vérifications d'état pour surveiller les adresses IP des règles de transfert de vos équilibreurs de charge régionaux.
  3. Configurez votre règle de routage DNS dans Cloud DNS :

Créer des équilibreurs de charge dans plusieurs régions

Tenez compte des points suivants lorsque vous configurez vos équilibreurs de charge redondants supplémentaires :

  • Configurez tous les équilibreurs de charge d'application externes régionaux avec des fonctionnalités similaires afin que le trafic soit traité de manière cohérente, quel que soit l'équilibreur de charge qui diffuse la requête. Par exemple, assurez-vous d'utiliser le même type de certificat SSL, les mêmes stratégies de sécurité régionales Cloud Armor et les mêmes paramètres de routage de mappage d'URL pour tous les équilibreurs de charge d'application externes régionaux.

    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 différents déploiements régionaux.

  • Nous vous recommandons de configurer des équilibreurs de charge d'application externes régionaux dans chaque région qui, selon vous, prend le mieux en charge le trafic de votre application.

  • Les équilibreurs de charge d'application externes régionaux sont compatibles avec les niveaux de service réseau Premium et Standard. Nous vous recommandons de configurer les équilibreurs de charge d'application externes régionaux au niveau Premium pour garantir une faible latence.

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.

Créer la vérification de l'état

Créez une vérification de l'état globale pour surveiller l'adresse IP externe de la règle de transfert de chaque équilibreur de charge régional :

gcloud compute health-checks create http HEALTH_CHECK_NAME \
    --global \
    --source-regions=SOURCE_REGION_1,SOURCE_REGION_2,SOURCE_REGION_3 \
    --use-serving-port \
    --check-interval=HEALTH_CHECK_INTERVAL \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --request-path=REQUEST_PATH

Remplacez les éléments suivants :

  • HEALTH_CHECK_NAME: nom de la vérification d'état
  • SOURCE_REGION_1, SOURCE_REGION_2 et SOURCE_REGION_3 : les trois régions Google Cloudà partir desquelles les vérifications d'état sont envoyé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 Bonnes pratiques.
  • HEALTHY_THRESHOLD et UNHEALTHY_THRESHOLD indiquent le nombre de tests séquentiels qui doivent réussir ou échouer pour que l'équilibreur de charge soit considéré comme opérationnel ou non opérationnel. Si l'une de ces valeurs est omise, Google Cloud utilise le seuil par défaut défini sur 2.
  • REQUEST_PATH : chemin de l'URL à laquelleGoogle 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 dont l'état est vérifié sont privés, ce qui n'est pas habituel pour les adresses IP des règles de transfert externes, vous pouvez définir ce chemin d'accès sur /afhealthz.

Configurer le basculement régional actif-passif

Dans Cloud DNS, créez un jeu d'enregistrements et appliquez une règle de routage FAILOVER pour envoyer le trafic en régime permanent vers l'équilibreur de charge régional principal et basculer vers l'équilibreur de charge régional de secours en cas de panne :

gcloud dns record-sets create DNS_RECORD_SET_NAME \
    --ttl=TIME_TO_LIVE \
    --type=RECORD_TYPE \
    --zone="MANAGED_ZONE_NAME" \
    --routing-policy-type=FAILOVER \
    --routing-policy-primary-data=PRIMARY_REGIONAL_FORWARDING_RULE \
    --routing-policy-backup-data_type=GEO \
    --routing-policy-backup-data="BACKUP_REGION_1=BACKUP_LOAD_BALANCER_1_IP[;BACKUP_REGION_2=BACKUP_LOAD_BALANCER_2_IP]" \
    --health-check=HEALTH_CHECK_NAME \
    --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO

Remplacez 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 de l'enregistrement, en secondes. Pour connaître les valeurs recommandées, consultez Bonnes pratiques.
  • RECORD_TYPE : type d'enregistrement (par exemple, A)
  • MANAGED_ZONE_NAME : nom de votre zone gérée Cloud DNS (par exemple, my-zone-name)
  • PRIMARY_REGIONAL_FORWARDING_RULE : nom de la règle de transfert de l'équilibreur de charge d'application externe régional principal
  • BACKUP_REGION_1 et BACKUP_REGION_2 : régions où les équilibreurs de charge d'application externes régionaux de secours sont déployés
  • BACKUP_LOAD_BALANCER_1_IP et BACKUP_LOAD_BALANCER_2_IP : adresses IP externes de la règle de transfert des équilibreurs de charge d'application externes régionaux de secours
  • HEALTH_CHECK_NAME: nom de la vérification d'état
  • BACKUP_DATA_TRICKLE_RATIO : fraction du trafic (de 0 à 1, par exemple 0.1) à envoyer à l'équilibreur de charge régional de secours en régime permanent pour s'assurer que la sauvegarde est amorcée et prête. La valeur par défaut est de 0.

Configurer le routage actif-actif entre régions

Dans Cloud DNS, créez un jeu d'enregistrements et appliquez une règle de routage de géolocalisation pour orienter le trafic simultanément entre les équilibreurs de charge régionaux opérationnels :

gcloud dns record-sets create DNS_RECORD_SET_NAME \
    --ttl=TIME_TO_LIVE \
    --type=RECORD_TYPE \
    --zone="MANAGED_ZONE_NAME" \
    --routing-policy-type="GEO" \
    --routing-policy-data="FORWARDING_RULE_NAME_A@REGION_A;FORWARDING_RULE_NAME_B@REGION_B[,;FORWARDING_RULE_NAME_C@REGION_C]" \
    --health-check=HEALTH_CHECK_NAME

Remplacez 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) de l'enregistrement, en secondes. Pour connaître les valeurs recommandées, consultez 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)
  • FORWARDING_RULE_NAME_A, FORWARDING_RULE_NAME_B et FORWARDING_RULE_NAME_C : noms des règles de transfert pour les équilibreurs de charge dans chaque région correspondante
  • REGION_A, REGION_B et REGION_C : régions dans lesquelles chaque équilibreur de charge est déployé
  • HEALTH_CHECK_NAME: nom de la vérification d'état

Bonnes pratiques

Voici quelques bonnes pratiques à prendre en compte lors de la configuration des enregistrements Cloud DNS et des 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 non opérationnels vers des équilibreurs de charge opérationnels (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 de l'état et du paramètre seuil de non-fonctionnement de la vérification de l'état :

    Duration of outage = DNS TTL + Health Check Interval * Unhealthy Threshold

    Nous vous recommandons de définir la valeur TTL du DNS sur une durée comprise entre 30 et 60 secondes. Des valeurs TTL plus élevées entraînent des temps d'arrêt plus longs, car les clients sur Internet continuent d'accéder aux équilibreurs de charge non opérationnels même après le basculement du DNS vers d'autres régions.

  • Configurer les seuils de vérification de l'état d'état : configurez les paramètres de seuils "opérationnel" et "non opérationnel" pour éviter de rediriger le trafic de manière inutile et brutale en raison d'erreurs temporaires. Des seuils plus élevés augmentent le temps nécessaire pour que le trafic soit transféré vers les équilibreurs de charge d'autres régions.

  • Utiliser le trafic minime pour la validation actif-passif : dans les configurations actif-passif, configurez l'option --backup-data-trickle-ratio pour envoyer en continu un faible pourcentage de trafic (par exemple, 0.1) à l'équilibreur de charge régional de secours en régime permanent. Cela permet de vérifier que l'infrastructure de sauvegarde est active et prête à gérer le trafic en cas de basculement.