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 atteindre 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 implémenter 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 sauvegarde dans les 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 de l'état, Cloud DNS utilise une règle de routage de basculement pour acheminer le trafic vers les équilibreurs de charge régionaux de sauvegarde.

    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 de géolocalisation Cloud DNS pour rediriger 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 depuis la région non opérationnelle vers des équilibreurs de charge opérationnels dans 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 des vérifications d'état et de l'orientation du trafic dans les régions, dans un workflow typique :

  1. Utiliser des vérifications de l'é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 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 configurer des vérifications provenant de deux régions ou plus en Amérique du Nord et 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 de présence (PoP) sur Internet, à une courte distance de la région source Google Cloudconfigurée.

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

    • Actif/passif : Cloud DNS utilise une règle de routage de basculement pour orienter 100% du trafic client vers l'équilibreur de charge régional principal en état stable. Lorsque l'équilibreur de charge régional principal échoue aux vérifications de l'état, Cloud DNS redirige le trafic vers les équilibreurs de charge régionaux de sauvegarde.
    • Actif/Actif : Cloud DNS utilise une règle de routage par 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 de l'état, le trafic est automatiquement redirigé vers les équilibreurs de charge opérationnels disponibles dans d'autres régions.

  3. Revenir à l'équilibreur de charge principal

    Le retour à l'état initial est automatique lorsque les vérifications de l'état recommencent à réussir. Le trafic est rétabli 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égion 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 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 traite la requête. Par exemple, assurez-vous d'utiliser le même type de certificat SSL, les mêmes règles 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 vous aider à obtenir et à maintenir la cohérence des configurations d'équilibreur de charge dans 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, prendrait 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 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 Bonnes pratiques.
  • HEALTHY_THRESHOLD et UNHEALTHY_THRESHOLD : spécifient 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. 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 auquelGoogle 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 typique des adresses IP des règles de transfert externes, vous pouvez définir ce chemin 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 à 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 dans lesquelles 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 des règles de transfert des équilibreurs de charge d'application externes régionaux de sauvegarde
  • 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 état stable pour s'assurer que la sauvegarde est prête. La valeur par défaut est de 0.

Configurer le routage actif/actif des 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 vers 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), en secondes, de l'enregistrement. 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 lorsque vous configurez 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 (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 le TTL DNS sur 30 à 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 que le DNS a basculé vers d'autres régions.

  • Configurer les vérification de l'état'état : configurez les paramètres de seuils "opérationnel" et "non opérationnel" pour éviter le réacheminement inutile et brutal du trafic en raison d'erreurs temporaires. Plus les seuils sont élevés, plus le trafic mettra du temps à être redirigé vers les équilibreurs de charge d'autres régions.

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