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

Cette page explique comment configurer un déploiement haute disponibilité avec des équilibreurs de charge d'application externes régionaux. Pour atteindre une haute disponibilité, déployez plusieurs équilibreurs de charge d'application externes régionaux individuels dans les régions qui acceptent le mieux 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.

Utilisez une règle de routage de géolocalisation Cloud DNS pour acheminer le trafic vers deux ou plusieurs équilibreurs de charge dans différentes régions. La règle achemine le trafic vers la région disponible la plus proche en fonction de l'origine de la requête du client. Nous vous recommandons également d'utiliser les vérifications d'état afin que Google Cloud puisse détecter les pannes régionales et acheminer le trafic uniquement vers les équilibreurs de charge opérationnels.

Voici un exemple de configuration affichant 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 un workflow type avec les différents composants impliqués dans cette configuration.

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

    Google Cloud utilise des vérifications de l'état pour détecter si vos équilibreurs de charge 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 d'Amérique du Nord, et des vérifications provenant de deux régions ou plus d'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 en fait d'un point de présence (PoP) sur Internet situé à une courte distance de la région source Google Cloud configurée.
  2. Acheminer le trafic vers des équilibreurs de charge opérationnels

    Google Cloud utilise une règle de routage géolocalisation Cloud DNS pour diriger 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 de l'origine de la requête client.

    Lorsqu'un équilibreur de charge d'une région donnée échoue aux vérifications de l'état, le trafic est acheminé vers les équilibreurs de charge opérationnels disponibles dans d'autres régions.

  3. Retour à l'utilisation de tous les équilibreurs de charge

    La restauration est automatique lorsque les vérifications d'état redeviennent réussies. Aucun temps d'arrêt n'est attendu lors de la restauration, car tous les équilibreurs de charge disponibles diffusent le trafic.

Configurer l'équilibrage de charge interrégional

Pour configurer un déploiement interrégional qui facilite la haute disponibilité, procédez comme suit :

  1. Créez des équilibreurs de charge d'application externes régionaux dans les régions que vous déterminez pour la meilleure compatibilité avec le trafic de votre application. Chacun de ces équilibreurs de charge doit avoir la même configuration de gestion du trafic et de sécurité.
  2. Créez la vérification de l'état et la règle de routage DNS pour diriger le trafic vers les équilibreurs de charge en fonction de l'emplacement du client et pour détourner le trafic d'un équilibreur de charge non opérationnel en cas d'indisponibilité.

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, vous devez vous assurer que vous utilisez le même type de certificat SSL, les mêmes règles Google Cloud Armor et les mêmes paramètres de gestion du trafic pour tous les équilibreurs de charge d'application externes régionaux.

    Nous vous recommandons d'utiliser un framework d'automatisation tel que Terraform pour vous aider à atteindre 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 que vous déterminez pour prendre 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 des équilibreurs de charge d'application externes régionaux supplémentaires de niveau Premium pour garantir une faible latence.

Pour savoir comment 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 groupes d'instances de VM.

Configurer Cloud DNS et les vérifications de l'état

Cette section explique comment utiliser Cloud DNS et les vérifications de l'état de Google Cloud pour configurer votre environnement Cloud Load Balancing afin de détecter les pannes et de router le trafic vers des équilibreurs de charge dans d'autres régions.

Procédez comme suit pour configurer les règles de routage et de vérification d'état requises :

  1. Créez une vérification d'é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_PATH
    

    Remplacez les éléments suivants :

    • HEALTH_CHECK_NAME: nom de la vérification d'état
    • SOURCE_REGION : les trois régions Google Cloud à partir desquelles sont envoyées les vérifications d'état. 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_THRESHOLD et UNHEALTHY_THRESHOLD indiquent le 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 vérifiés pour l'état sont privés, ce qui n'est pas courant pour les adresses IP de règle de transfert externes, vous pouvez définir ce chemin d'accès sur /afhealthz.
  2. Dans Cloud DNS, créez un jeu d'enregistrements et appliquez-lui une règle de routage de géolocalisation.

    gcloud beta 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), en secondes, pour l'enregistrement. Pour connaître les valeurs recommandées, consultez la section Considérations concernant le DNS.
    • 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 : noms des règles de transfert de l'équilibreur de charge dans chaque REGION
    • REGION : régions dans lesquelles chaque équilibreur de charge est déployé

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 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 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 Threshold
    

    Nous vous recommandons de définir la valeur TTL DNS 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 la transition DNS vers d'autres régions.

  • Configurez les paramètres de seuil de santé et de non-santé dans les vérifications d'état afin d'éviter le réacheminement inutile et brusque du trafic en raison d'erreurs temporaires. Des seuils plus élevés augmentent le temps nécessaire pour que le trafic soit redirigé vers des équilibreurs de charge dans d'autres régions.