Basculement multirégional à l'aide de règles de routage Cloud DNS et de vérifications de l'état pour l'équilibreur de charge TCP/UDP interne

1. Introduction

Dernière mise à jour:22/09/2022

Qu'est-ce qu'une règle de routage DNS ?

Les règles de routage Cloud DNS permettent aux utilisateurs de configurer l'orientation du trafic basée sur le DNS en fonction de critères spécifiques tels que la pondération, la géolocalisation ou les vérifications de l'état.

Cloud DNS est compatible avec les règles de routage suivantes :

• Règle de routage round robin pondéré
• Règle de routage de géolocalisation
• Règle de routage avec géorepérage
• Règle de routage avec basculement

Dans cet atelier, vous allez configurer et tester la règle de routage de basculement.

Remarque:Au moment de la rédaction de cet atelier, les stratégies de basculement et la prise en charge des vérifications d'état sont disponibles en version Preview publique.

Règle de routage avec basculement

Cloud DNS accepte les vérifications de l'état pour les équilibreurs de charge TCP/UDP internes dont l'accès mondial est activé. Avec une règle de routage de basculement, vous pouvez configurer l'adresse IP principale et l'adresse IP de sauvegarde pour un enregistrement de ressources. En fonctionnement normal, Cloud DNS répond aux requêtes avec les adresses IP provisionnées dans l'ensemble principal. Lorsque toutes les adresses IP de l'ensemble principal échouent (c'est-à-dire lorsque l'état de fonctionnement devient "non opérationnel"), Cloud DNS commence à diffuser les adresses IP du jeu de sauvegarde.

Remarque:Pour que Cloud DNS fonctionne comme prévu avec les vérifications d'état, l'accès mondial doit être activé sur l'équilibreur de charge. Les utilisateurs pourront créer des règles de routage pour les équilibreurs de charge internes dont l'accès global est désactivé, mais le basculement Cloud DNS ne fonctionnera pas.

Vérifications d'état

La règle de routage DNS dépendra des vérifications d'état unifiées natives de l'équilibreur de charge interne(UHC). Un équilibreur de charge interne est considéré comme opérationnel si au moins 20 % des backends sont opérationnels. Les vérifications de l'état des équilibreurs de charge TCP/UDP internes et HTTP(S) internes fournissent des informations différentes. Pour un équilibreur de charge HTTP(S) interne, UHC fournit l'état de santé de tous les proxys Envoy. Pour un équilibreur de charge TCP/UDP interne, Cloud DNS reçoit des signaux d'état directs à partir des instances backend individuelles. Pour en savoir plus sur les vérifications d'état, cliquez ici .

Objectifs de l'atelier

Dans cet atelier de programmation, vous allez créer un site Web s'exécutant dans deux régions et lui associer une règle de routage DNS de basculement. La configuration comprend les éléments suivants:

Ressources actives –

• Équilibreur de charge interne L4 dans la région REGION_1
• Une VM exécutant le serveur Web Apache dans la région REGION_1

Ressources de sauvegarde :

• Équilibreur de charge interne L4 dans la région REGION_2
• Une VM exécutant le serveur Web Apache dans la région REGION_2

La configuration est illustrée ci-dessous :

Remarque:Pour simplifier cet atelier de programmation, nous allons disposer d'un seul équilibreur de charge dans chacune des régions configurées en tant qu'ensembles actifs et de secours de la règle de routage de basculement.

Points abordés

• Créer une règle de routage de basculement
• Déclencher le basculement DNS
• Rediriger le trafic vers le jeu de sauvegarde

Prérequis

• Connaissances de base sur le DNS
• Connaissance de base de Google Compute Engine
• Connaissances de base sur l'équilibreur de charge interne L4

2. Préparation

1. Connectez-vous à la console Google Cloud, puis créez un projet ou réutilisez un projet existant. (Si vous ne possédez pas encore de compte Gmail ou Google Workspace, vous devez en créer un.)

• Le nom du projet est le nom à afficher pour les participants au projet. Il s'agit d'une chaîne de caractères non utilisée par les API Google. Vous pouvez le modifier à tout moment.
• L'ID du projet doit être unique sur l'ensemble des projets Google Cloud et doit être immuable (vous ne pouvez pas le modifier une fois que vous l'avez défini). La console Cloud génère automatiquement une chaîne unique. généralement, vous ne vous souciez pas de ce que c’est. Dans la plupart des ateliers de programmation, vous devrez référencer l'ID du projet (il est généralement identifié comme PROJECT_ID). Si l'ID généré ne vous convient pas, vous pouvez en générer un autre au hasard. Vous pouvez également essayer la vôtre pour voir si elle est disponible. Il ne peut pas être modifié après cette étape et restera actif pendant toute la durée du projet.
• Pour votre information, il existe une troisième valeur, le numéro de projet, utilisé par certaines API. Pour en savoir plus sur ces trois valeurs, consultez la documentation.

Attention : Un ID de projet doit être unique au niveau mondial. Personne d'autre ne peut l'employer une fois que vous l'avez sélectionné. Vous en êtes le seul utilisateur. Même si un projet est supprimé, l'ID ne peut plus jamais être utilisé

Remarque : Si vous utilisez un compte Gmail, vous pouvez conserver l'emplacement par défaut défini sur Aucune organisation. Si vous utilisez un compte Google Workspace, choisissez un emplacement pertinent pour votre organisation.

2. Vous devez ensuite activer la facturation dans la console Cloud pour utiliser les ressources/API Cloud. L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Pour arrêter les ressources afin d'éviter que des frais ne vous soient facturés au-delà de ce tutoriel, vous pouvez supprimer les ressources que vous avez créées ou l'ensemble du projet. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai gratuit pour bénéficier d'un crédit de 300 $.

Démarrer Cloud Shell

Bien que Google Cloud puisse être utilisé à distance depuis votre ordinateur portable, nous allons nous servir de Google Cloud Shell pour cet atelier de programmation, un environnement de ligne de commande exécuté dans le cloud.

Dans la console Google Cloud, cliquez sur l'icône Cloud Shell dans la barre d'outils supérieure :

Le provisionnement et la connexion à l'environnement prennent quelques instants seulement. Une fois l'opération terminée, le résultat devrait ressembler à ceci :

Cette machine virtuelle contient tous les outils de développement nécessaires. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud, ce qui améliore nettement les performances du réseau et l'authentification. Vous pouvez effectuer toutes les tâches de cet atelier de programmation dans un navigateur. Vous n'avez rien à installer.

3. Version du SDK Google Cloud

Au moment de la rédaction de ce document, 401.0.0 correspond à la dernière version du SDK Google Cloud. Toutes les commandes de cet atelier ont été testées à l'aide de la dernière version de Google Cloud SDK. Avant de continuer, assurez-vous que Cloud Shell utilise la dernière version du SDK.

Vérifier la version du SDK

Utilisez la commande gcloud version pour vérifier la version du SDK. Exécutez les commandes suivantes dans Cloud Shell

Commande

gcloud version | grep "Google Cloud SDK"

Exemple de résultat

Google Cloud SDK 401.0.0

Étapes suivantes

Attention:Sélectionnez l'option 1 ou 2 en fonction du résultat de la commande gcloud version.

1. Si la version du SDK est 401.0.0 ou ultérieure, passez à la section suivante.
2. Si la version du SDK est antérieure à 401.0.0, exécutez la commande ci-dessous pour le mettre à jour.

Commande facultative

sudo apt-get update && sudo apt-get install google-cloud-sdk

4. Avant de commencer

Avant de commencer à déployer l'architecture décrite ci-dessus, assurez-vous que Cloud Shell est correctement configuré et que toutes les API requises sont activées.

Configurer un ID de projet

Dans Cloud Shell, assurez-vous que votre ID de projet est configuré. Si votre invite Cloud Shell ressemble à la sortie ci-dessous et que vous ne prévoyez pas de modifier l'ID du projet, vous pouvez passer à l'étape suivante (Définir les variables d'environnement).

USER@cloudshell:~ (PROJECT_ID)$

Si vous souhaitez toujours modifier l'ID du projet, utilisez la commande ci-dessous. L'invite Cloud Shell passera de (PROJECT_ID) à (YOUR-PROJECT-ID).

Commande facultative

gcloud config set project [YOUR-PROJECT-ID]

Exemple de résultat

Updated property [core/project].
USER@cloudshell:~ (YOUR-PROJECT-ID)$

Définir les variables d'environnement

Définir les variables d'environnement

Nous allons utiliser la commande export pour définir les variables d'environnement. Exécutez les commandes suivantes dans Cloud Shell

Commandes

export REGION_1=us-west1

export REGION_1_ZONE=us-west1-a

export REGION_2=us-east4

export REGION_2_ZONE=us-east4-a

Remarque:Dans cet atelier, nous utilisons les régions us-west1 et us-east4. La capacité de calcul peut être limitée dans une zone. Si vous constatez des erreurs de capacité lors de la création des VM, veuillez utiliser une autre région/zone. Pour consulter la liste des régions et zones disponibles, cliquez ici.

Valider

Maintenant que les variables d'environnement sont définies, vérifiez-les à l'aide de la commande echo. Le résultat de chaque commande doit correspondre à la valeur que nous avons configurée ci-dessus à l'aide de la commande export. Exécutez les commandes suivantes dans Cloud Shell

Commandes

echo $REGION_1

echo $REGION_1_ZONE

echo $REGION_2

echo $REGION_2_ZONE

Activer tous les services nécessaires

Utilisez la commande gcloud services enable pour activer les API Compute et DNS. Exécutez les commandes suivantes dans Cloud Shell

Activer l'API Compute

Commande

gcloud services enable compute.googleapis.com

Activer l'API DNS

Commande

gcloud services enable dns.googleapis.com

Valider

Maintenant que les services sont activés, vérifions la liste de toutes les API activées à l'aide de la commande gcloud services list.

Commande

gcloud services list | grep -E 'compute|dns'

Exemple de résultat

NAME: compute.googleapis.com
NAME: dns.googleapis.com

5. Créer des règles de réseau VPC, de sous-réseaux et de pare-feu

Dans cette section, nous allons créer le réseau VPC, deux sous-réseaux (un dans chaque région) ainsi que les règles de pare-feu requises.

Créer un réseau VPC

Utilisez la commande gcloud compute networks create pour créer le réseau VPC. Nous allons définir le mode sous-réseau sur "Personnalisé", car nous créerons nos propres sous-réseaux à l'étape suivante. Exécutez les commandes suivantes dans Cloud Shell.

Commande

gcloud compute networks create my-vpc --subnet-mode custom

Créer des sous-réseaux

Utilisez la commande gcloud compute networks subnets create pour créer deux sous-réseaux, l'un dans la région REGION_1 et l'autre dans la région REGION_2. Exécutez les commandes suivantes dans Cloud Shell

Sous-réseau REGION_1

Commande

gcloud compute networks subnets create ${REGION_1}-subnet \
--network my-vpc \
--range 10.1.0.0/24 \
--region $REGION_1

Sous-réseau REGION_2

Commande

gcloud compute networks subnets create ${REGION_2}-subnet \
--network my-vpc \
--range 10.2.0.0/24 \
--region $REGION_2

Créer des règles de pare-feu

Vous devez autoriser le trafic sur le port 80 à partir des sous-réseaux VPC et des plages d'adresses IP de vérification de l'état de l'équilibreur de charge.

Vous devez également créer une règle de pare-feu pour autoriser le trafic SSH sur les VM clientes.

Utilisez la commande gcloud compute firewall-rules create pour créer les règles de pare-feu. Exécutez les commandes suivantes dans Cloud Shell

Allow Traffic on Port 80 (Autoriser le trafic sur le port 80)

Commande

gcloud compute firewall-rules create allow-http-lb-hc \
--allow tcp:80 --network my-vpc \
--source-ranges 10.1.0.0/24,10.2.0.0/24,35.191.0.0/16,130.211.0.0/22 \
--target-tags=allow-http

Autoriser le trafic SSH sur la VM cliente

Commande

gcloud compute firewall-rules create allow-ssh \
--allow tcp:22 --network my-vpc \
--source-ranges 0.0.0.0/0 \
--target-tags=allow-ssh

6. Créer Cloud NAT

Vous avez besoin de passerelles Cloud NAT dans les deux régions pour que les VM privées puissent télécharger et installer des packages depuis Internet.

• Les VM de notre serveur Web devront télécharger et installer le serveur Web Apache.
• La VM cliente devra télécharger et installer le package dnsutils que nous utiliserons pour nos tests.

Chaque passerelle Cloud NAT est associée à un seul réseau VPC, à une seule région et à un seul routeur Cloud Router. Avant de créer les passerelles NAT, nous devons donc créer des routeurs cloud dans chaque région.

Créer des routeurs cloud

Utilisez la commande gcloud compute routers create pour créer des routeurs cloud dans les régions us-west1 et us-east4. Exécutez les commandes suivantes dans Cloud Shell.

Routeur cloud régional_1

Commandes

gcloud compute routers create "${REGION_1}-cloudrouter" \
--region $REGION_1 --network=my-vpc --asn=65501

Routeur cloud régional_2

Commandes

gcloud compute routers create "${REGION_2}-cloudrouter" \
--region $REGION_2 --network=my-vpc --asn=65501

Créer les passerelles NAT

Utilisez la commande gcloud compute routers nat create pour créer les passerelles NAT dans les régions us-west1 et us-east4. Exécutez les commandes suivantes dans Cloud Shell.

Passerelle NAT Region_1

Commandes

gcloud compute routers nats create "${REGION_1}-nat-gw" \
--router="${REGION_1}-cloudrouter" \
--router-region=$REGION_1 \
--nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips

Passerelle NAT Region_2

Commandes

gcloud compute routers nats create "${REGION_2}-nat-gw" \
--router="${REGION_2}-cloudrouter" \
--router-region=$REGION_2 \
--nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips

7. Créer des VM Compute Engine

Dans cette section, vous allez créer les serveurs Web, les groupes d'instances non gérés pour les serveurs Web et la VM cliente.

Remarque:Dans cet atelier, nous utilisons les régions us-west1 et us-east4. La capacité de calcul peut être limitée dans une zone. Si vous constatez des erreurs de capacité lors de la création des VM, veuillez utiliser une autre région/zone. Pour consulter la liste des régions et zones disponibles, cliquez ici.

Créer des VM sur serveur Web

Utilisez la commande gcloud compute instances create pour créer les serveurs Web. Nous devons créer deux serveurs Web, l'un dans la région REGION_1 et l'autre dans la région REGION_2. Nous utilisons des scripts de démarrage pour installer et configurer Apache sur les serveurs Web.

Serveur Web REGION_1

Exécutez la commande suivante dans Cloud Shell

Commande

gcloud compute instances create "${REGION_1}-instance" \
--image-family=debian-11 --image-project=debian-cloud \
--zone=$REGION_1_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_1}-subnet,no-address \
--tags=allow-http \
--metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

Serveur Web REGION_2

Exécutez la commande suivante dans Cloud Shell

Commande

gcloud compute instances create "${REGION_2}-instance" \
--image-family=debian-11 --image-project=debian-cloud \
--zone=$REGION_2_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_2}-subnet,no-address \
--tags=allow-http \
--metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

Créer des groupes d'instances non gérés

Dans cette section, nous allons créer deux groupes d'instances non gérés. Dans la section suivante, nous utiliserons ces groupes d'instances pour configurer les services de backend d'ILB. Une fois les groupes d'instances créés, nous ajouterons les VM des serveurs Web à ces groupes d'instances.

Créer les groupes d'instances non gérés

Utilisez la commande gcloud compute instance-groups unmanaged create pour créer deux groupes d'instances non gérés, l'un pour le serveur Web us-west1 et l'autre pour le serveur Web us-east4.

Groupe d'instances Region_1

Commandes

gcloud compute instance-groups unmanaged create \
"${REGION_1}-instance-group" --zone=$REGION_1_ZONE

Groupe d'instances Region_2

Commandes

gcloud compute instance-groups unmanaged create \
"${REGION_2}-instance-group" --zone=$REGION_2_ZONE

Ajouter des VM aux groupes d'instances

Utilisez la commande gcloud compute instance-groups unmanaged add-instances pour ajouter les instances aux groupes d'instances que nous venons de créer. Ajoutez le serveur Web REGION_1 au groupe d'instances REGION_1 et le serveur Web REGION_2 au groupe d'instances REGION_2.

Groupe d'instances Region_1

Commandes

gcloud compute instance-groups unmanaged add-instances \
"${REGION_1}-instance-group" --instances $REGION_1-instance \
--zone=$REGION_1_ZONE

Groupe d'instances Region_2

Commandes

gcloud compute instance-groups unmanaged add-instances \
"${REGION_2}-instance-group" --instances $REGION_2-instance \
--zone=$REGION_2_ZONE

Créer une VM cliente

Nous utiliserons cette VM pour exécuter des tests et vérifier notre configuration DNS. Nous utilisons un script de démarrage pour installer le package dnsutils. Exécutez les commandes suivantes dans Cloud Shell.

Commande

gcloud compute instances create client-instance --image-family=debian-11 \
--image-project=debian-cloud \
--zone=$REGION_1_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_1}-subnet,no-address \
--tags=allow-ssh \
--metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install dnsutils -y'

8. Créer des équilibreurs de charge internes L4

Pour créer l'ILB L4, nous devons créer une vérification d'état, un service de backend et une règle de transfert.

Créer une vérification d'état

Utilisez la commande gcloud compute health-checks create pour créer la vérification d'état. Nous créons une vérification d'état HTTP de base et le port cible est le port 80. Exécutez les commandes suivantes dans Cloud Shell

Commande

gcloud compute health-checks create http http-hc --port 80

Configurer des services de backend

Utilisez la commande gcloud compute backend-services create pour créer le service de backend. Une fois les services de backend créés, nous ajouterons les groupes d'instances non gérés aux services de backend à l'aide de la commande gcloud compute backend-services add-backend. Exécutez les commandes suivantes dans Cloud Shell.

Créer un service de backend

Commandes

gcloud compute backend-services create $REGION_1-backend-service \
--load-balancing-scheme=INTERNAL --protocol=TCP \
--health-checks=http-hc --region=$REGION_1

gcloud compute backend-services create $REGION_2-backend-service \
--load-balancing-scheme=INTERNAL --protocol=TCP \
--health-checks=http-hc --region=$REGION_2

Ajouter un backend

Commande

gcloud compute backend-services add-backend $REGION_1-backend-service \
--instance-group=$REGION_1-instance-group \
--region=$REGION_1 \
--instance-group-zone=$REGION_1_ZONE

gcloud compute backend-services add-backend $REGION_2-backend-service \
--instance-group=$REGION_2-instance-group \
--region=$REGION_2 \
--instance-group-zone=$REGION_2_ZONE

Créer des règles de transfert

Utilisez la commande gcloud compute forwarding-rules create pour créer les règles de transfert dans les deux régions. Exécutez les commandes suivantes dans Cloud Shell

Règle de transfert REGION_1

Commandes

gcloud compute forwarding-rules create $REGION_1-ilb \
    --region=$REGION_1 \
    --load-balancing-scheme=internal \
    --network=my-vpc \
    --subnet=$REGION_1-subnet \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=$REGION_1-backend-service \
    --backend-service-region=$REGION_1 \
    --allow-global-access

Règle de transfert REGION_2

gcloud compute forwarding-rules create $REGION_2-ilb \
    --region=$REGION_2 \
    --load-balancing-scheme=internal \
    --network=my-vpc \
    --subnet=$REGION_2-subnet \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=$REGION_2-backend-service \
    --backend-service-region=$REGION_2 \
    --allow-global-access

9. Configurer les paramètres DNS

Dans cette section, nous allons créer la zone privée et un jeu d'enregistrements DNS avec la règle de routage de basculement.

Créer une zone DNS privée

Utilisez la commande gcloud dns managed-zones create afin de créer une zone privée pour example.com. Nous utiliserons cette zone pour créer un jeu d'enregistrements de ressources avec une règle de routage de basculement. Exécutez la commande suivante dans Cloud Shell

Commandes

gcloud dns managed-zones create example-com \
--dns-name example.com. --description="My private zone" \
--visibility=private --networks my-vpc 

Créer un enregistrement DNS avec une règle de routage de basculement

Utilisez la commande gcloud dns record-sets create pour créer un enregistrement DNS avec la règle de routage de basculement. La cible principale est l'équilibreur de charge situé dans la région REGION_1. Cloud DNS n'accepte que les cibles de sauvegarde basées sur la géolocalisation. L'ensemble de sauvegarde est une règle de géolocalisation avec un équilibreur de charge REGION_2 comme cible pour REGION_1 et REGION_2. Exécutez les commandes suivantes dans Cloud Shell

Commande

gcloud dns record-sets create failover.example.com --ttl 5 --type A \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=$REGION_1-ilb \
--routing-policy-backup-data="${REGION_1}=${REGION_2}-ilb;${REGION_2}=${REGION_2}-ilb" \
--routing-policy-backup-data-type=GEO \
--zone=example-com \
--enable-health-checking

Exemple de résultat

NAME: failover.example.com.
TYPE: A
TTL: 5
DATA: Primary: "10.1.0.4, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-west1, regionalL4ilb" Backup: us-west1: "10.2.0.3, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-east4, regionalL4ilb";us-east4: "10.2.0.3, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-east4, regionalL4ilb"

10. Tester la résolution DNS

Avant de tester la configuration de notre basculement, notez les adresses IP des deux équilibreurs de charge internes. Exécutez les commandes suivantes dans Cloud Shell.

Commande

gcloud compute forwarding-rules list --filter="name:($REGION_1-ilb $REGION_2-ilb)"

Exemple de résultat

Dans cet exemple, us-west1-ilb a une adresse IP de 10.1.0.4 et us-east4-ilb a une adresse IP de 10.2.0.3.

NAME: us-west1-ilb
REGION: us-west1
IP_ADDRESS: 10.1.0.4
IP_PROTOCOL: TCP
TARGET: us-west1/backendServices/us-west1-backend-service

NAME: us-east4-ilb
REGION: us-east4
IP_ADDRESS: 10.2.0.3
IP_PROTOCOL: TCP
TARGET: us-east4/backendServices/us-east4-backend-service

Nous allons maintenant nous connecter à l'instance client-instance et tester la résolution DNS. Dans la console Web, accédez à "Compute Engine | "Instances de VM".

Cliquez sur le bouton SSH pour vous connecter à l'instance client-instance à partir de la console.

Maintenant que nous sommes dans la VM cliente, utilisez la commande dig pour résoudre le nom de domaine failover.example.com.

La boucle est configurée pour exécuter la commande 10 fois avec un délai de mise en veille de 6 secondes.

Commande

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

Puisque la valeur TTL de l'enregistrement DNS est définie sur cinq secondes, un délai de mise en veille de six secondes a été ajouté. Le délai de mise en veille vous garantit d'obtenir une réponse DNS non mise en cache pour chaque requête DNS. L'exécution de cette commande prend environ une minute.

Dans le résultat, vous verrez l'adresse IP de l'équilibreur de charge dans l'ensemble principal de l'enregistrement de ressources. Dans notre configuration, il s'agit de l'adresse IP de l'équilibreur de charge dans la région us-west1.

11. Tester le basculement

Nous allons simuler un basculement en supprimant le tag réseau de la VM REGION_1. Cette action bloque l'accès au port 80, ce qui entraîne l'échec des vérifications d'état.

Supprimer le tag réseau

Utilisez la commande gcloud compute instances remove-tags pour supprimer le tag réseau de la VM. Exécutez la commande suivante dans Cloud Shell

Commande

gcloud compute instances remove-tags $REGION_1-instance \
--zone=$REGION_1_ZONE --tags=allow-http

La vérification de l'état échouera dans 10 secondes. Exécutez à nouveau le test de résolution DNS.

Résolution DNS

Depuis l'instance client, exécutez la commande suivante :

Commande

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

Dans le résultat, vous verrez l'adresse IP de l'équilibreur de charge dans le jeu de sauvegarde de l'enregistrement de ressources. Dans notre configuration, il s'agit de l'adresse IP de l'équilibreur de charge situé dans la région us-east4.

12. Tester le trafic minime

Par défaut, la règle de basculement renvoie l'adresse IP du point de terminaison principal pour toutes les requêtes DNS et ne renvoie les adresses IP de secours que si l'adresse IP principale échoue aux vérifications de l'état. Cloud DNS permet aux utilisateurs de configurer le taux de perte, qui permet à Cloud DNS d'envoyer une partie du trafic aux cibles de sauvegarde, même lorsque les cibles principales sont opérationnelles. Le ratio doit être une valeur comprise entre 0 et 1. La valeur par défaut est 0.

Pour tester cela, rajoutons le tag réseau au serveur Web REGION_1.

Ajouter un tag réseau

Ajoutez à nouveau le tag à la VM du serveur Web pour autoriser le trafic HTTP vers la VM de la région principale. Exécutez la commande suivante dans Cloud Shell.

Commande

gcloud compute instances add-tags $REGION_1-instance \
--zone $REGION_1_ZONE --tags allow-http

Les vérifications de l'état réussiront dans 10 secondes.

Vérifiez que la résolution DNS pointe vers l'équilibreur de charge principal. Dans notre configuration, il s'agira de l'adresse IP de l'équilibreur de charge dans la région us-west1.

Depuis l'instance client, exécutez la commande suivante :

Commande

dig +short failover.example.com

Mettre à jour l'enregistrement DNS

Nous allons maintenant modifier l'enregistrement DNS de failover.example.com afin de transférer 30% du trafic vers l'ensemble de sauvegarde, même lorsque l'instance principale est opérationnelle. Exécutez la commande suivante dans Cloud Shell

Commande

gcloud dns record-sets update failover.example.com --ttl 30 --type A \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=$REGION_1-ilb \
--routing-policy-backup-data="${REGION_1}=${REGION_2}-ilb;${REGION_2}=${REGION_2}-ilb" \
--routing-policy-backup-data-type=GEO \
--zone=example-com --enable-health-checking \
--backup-data-trickle-ratio=0.3

Résolution DNS

Exécutez la commande suivante à partir de la VM cliente. Vous remarquerez que l'enregistrement DNS failover.example.com sera associé à l'adresse IP de l'équilibreur de charge principal environ. vers l'adresse IP de l'équilibreur de charge de secours (environ 70% du temps) dans 30% des cas.

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

13. Étapes de nettoyage

Pour nettoyer les ressources utilisées dans cet atelier, exécutez les commandes suivantes depuis Cloud Shell

gcloud dns record-sets delete failover.example.com --type=A \
--zone=example-com --quiet

gcloud dns managed-zones delete example-com --quiet

gcloud compute forwarding-rules delete $REGION_1-ilb \
--region=$REGION_1 --quiet

gcloud compute forwarding-rules delete $REGION_2-ilb \
--region=$REGION_2 --quiet

gcloud compute backend-services delete $REGION_1-backend-service \
--region=$REGION_1 --quiet

gcloud compute backend-services delete $REGION_2-backend-service \
--region=$REGION_2 --quiet

gcloud compute health-checks delete http-hc --quiet

gcloud compute instances delete client-instance --zone=$REGION_1_ZONE --quiet

gcloud compute instance-groups unmanaged delete $REGION_1-instance-group \
--zone=$REGION_1_ZONE --quiet

gcloud compute instance-groups unmanaged delete $REGION_2-instance-group \
--zone=$REGION_2_ZONE --quiet

gcloud compute instances delete $REGION_1-instance \
--zone=$REGION_1_ZONE --quiet

gcloud compute instances delete $REGION_2-instance \
--zone=$REGION_2_ZONE --quiet

gcloud compute routers nats delete $REGION_1-nat-gw \
--router=$REGION_1-cloudrouter --region=$REGION_1 --quiet

gcloud compute routers nats delete $REGION_2-nat-gw \
--router=$REGION_2-cloudrouter --region=$REGION_2 --quiet

gcloud compute routers delete $REGION_1-cloudrouter \
--region=$REGION_1 --quiet

gcloud compute routers delete $REGION_2-cloudrouter \
--region=$REGION_2 --quiet

gcloud compute firewall-rules delete allow-ssh allow-http-lb-hc --quiet

gcloud compute networks subnets delete $REGION_1-subnet \
--region=$REGION_1 --quiet

gcloud compute networks subnets delete $REGION_2-subnet \
--region=$REGION_2 --quiet

gcloud compute networks delete my-vpc --quiet

14. Félicitations

Félicitations, vous avez déployé et testé la règle de routage de basculement Cloud DNS

Points abordés

• Configurer une règle de routage de basculement Cloud DNS
• Tester le basculement DNS
• Rediriger le trafic vers l'ensemble de sauvegarde

Et ensuite ?

• Essayez de configurer plusieurs adresses IP pour les ensembles actifs et de sauvegarde
• Essayez d'ajouter plusieurs VM de backend à vos groupes d'instances non gérés
• Essayez de configurer plusieurs équilibreurs de charge dans différentes régions pour la règle de géolocalisation dans le jeu de sauvegarde.

En savoir plus

https://cloud.google.com/dns/docs/zones/manage-routing-policies