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 en fonction du DNS, selon des critères spécifiques tels que le poids, 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.

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é. Une règle de routage avec basculement vous permet de configurer des adresses IP principales et de secours pour un enregistrement de ressource. 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 du jeu principal échouent (c'est-à-dire lorsque l'état de santé devient "non opérationnel"), Cloud DNS commence à utiliser les adresses IP du jeu de sauvegarde.

Vérifications d'état

La règle de routage DNS dépendra des vérifications de l'état unifiées(UHC) de l'équilibreur de charge interne natif. Un équilibreur de charge interne est considéré comme opérationnel si 20 % (ou plus) 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. En revanche, pour un équilibreur de charge TCP/UDP interne, Cloud DNS reçoit des signaux d'état directs de chaque instance backend. Pour en savoir plus sur les vérifications de l'état de santé, 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 comprendra :

Ressources actives :

  • Équilibreur de charge interne L4 dans REGION_1
  • Une VM exécutant un serveur Web Apache dans REGION_1

Ressources de sauvegarde :

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

La configuration est la suivante :

d0a91d3d3698f544.png

Points abordés

  • Créer une règle de routage avec basculement
  • Déclencher le basculement DNS
  • Diffuser progressivement le trafic vers l'ensemble de sauvegarde

Prérequis

  • Connaissances de base sur le DNS
  • Connaissance de base de Google Compute Engine
  • Connaissances de base de 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.)

b35bf95b8bf3d5d8.png

a99b7ace416376c4.png

bd84a6d3004737c5.png

  • 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 (en général, vous n'y accordez d'importance particulière). Dans la plupart des ateliers de programmation, vous devrez indiquer l'ID du projet (généralement identifié par PROJECT_ID). Si l'ID généré ne vous convient pas, vous pouvez en générer un autre de manière aléatoire. Vous pouvez également en spécifier un et voir s'il est disponible. Après cette étape, l'ID n'est plus modifiable et restera donc le même pour toute la durée du projet.
  • Pour information, il existe une troisième valeur (le numéro de projet) que certaines API utilisent. Pour en savoir plus sur ces trois valeurs, consultez la documentation.
  1. 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 désactiver les ressources et éviter ainsi que des frais ne vous soient facturés après ce tutoriel, vous pouvez supprimer le projet ou les ressources que vous avez créées. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai sans frais 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 :

55efc1aaa7a4d3ad.png

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

7ffe5cbb04455448.png

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 de Google Cloud SDK

Au moment de la rédaction de cet article, 401.0.0 est la dernière version du SDK Google Cloud. Toutes les commandes de cet atelier ont été testées avec la dernière version du SDK Google Cloud. 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

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

Commande facultative

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

4. Avant de commencer

Avant de commencer à déployer l'architecture que nous avons expliquée ci-dessus, vérifions que Cloud Shell est correctement configuré et que toutes les API requises sont activées.

Configurer l'ID du projet

Dans Cloud Shell, assurez-vous que l'ID de votre projet est configuré. Si l'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 de 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 utiliserons 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

Valider

Maintenant que les variables d'environnement sont définies, vérifions-les à l'aide de la commande echo. La sortie 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 Engine 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-le à l'aide de la commande gcloud services list pour lister toutes les API activées.

Commande

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

Exemple de résultat

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

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

Dans cette section, nous allons créer le réseau VPC, deux sous-réseaux (un dans chaque région) et 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 définissons le mode sous-réseau sur "Personnalisé" car nous allons créer 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 REGION_1 et l'autre dans 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.

De plus, vous devez 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.

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.

  • Nos VM de 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 Router dans chaque région.

Créer des routeurs cloud

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

Routeur cloud Region_1

Commandes

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

Routeur cloud Region_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 pour créer les passerelles NAT dans les régions us-west1 et us-east4.gcloud compute routers nat create 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.

Créer des VM de 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 REGION_1 et l'autre dans 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. Nous utiliserons ces groupes d'instances dans la section suivante pour configurer les services de backend ILB. Une fois les groupes d'instances créés, nous y ajouterons les VM du serveur Web.

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'équilibreur de charge interne de couche 4, 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 allons créer 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 les services de backend

Exécutez 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 pour 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 par 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 par 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 dans 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 l'é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 notre configuration de basculement, notons 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 l'adresse IP 10.1.0.4 et us-east4-ilb a l'adresse IP 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 cliente et tester la résolution DNS. Dans la console Web, accédez à "Compute Engine | Instances de VM".

5c824940bf414501.png

Cliquez sur le bouton SSH pour vous connecter à l'instance cliente depuis la console.

b916eb32c60a4156.png

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 de façon à exécuter la commande dix fois avec un délai de mise en veille de six 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é. Ce 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 ressource. 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. Cela bloquera l'accès au port 80, ce qui entraînera 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

À partir de l'instance cliente, 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 l'ensemble de sauvegarde de l'enregistrement de ressource. Dans notre configuration, il s'agit de l'adresse IP de l'équilibreur de charge dans la région us-east4.

12. Tester le trafic progressif

Par défaut, la stratégie 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 le point de terminaison principal échoue aux vérifications de l'état. Cloud DNS permet aux utilisateurs de configurer le ratio de transfert progressif, qui permet à Cloud DNS d'envoyer une partie du trafic vers les 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, ajoutons à nouveau le tag réseau au serveur Web REGION_1.

Ajouter une balise 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 d'état seront réussies dans 10 secondes.

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

À partir de l'instance cliente, exécutez la commande suivante :

Commande

dig +short failover.example.com

Mettre à jour l'enregistrement DNS

Nous allons maintenant modifier l'enregistrement DNS pour failover.example.com afin de rediriger 30 % du trafic vers l'ensemble de sauvegarde, même lorsque le serveur principal est opérationnel. 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 constaterez que l'enregistrement DNS failover.example.com renvoie à l'adresse IP de l'équilibreur de charge principal environ 70 % du temps et à l'adresse IP de l'équilibreur de charge de secours environ 30 % du temps.

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 à partir de 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 correctement déployé et testé la règle de routage avec basculement Cloud DNS.

Points abordés

  • Configurer une règle de routage de basculement Cloud DNS
  • Tester le basculement DNS
  • Diffuser progressivement 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 l'ensemble de sauvegarde.

En savoir plus

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