Présentation de l'utilisation du DNS zonal

Ce document décrit les avantages et l'approche recommandée pour migrer vos charges de travail et votre organisation d'un DNS global vers un DNS zonal.

Le DNS zonal réduit les risques de pannes interrégionales et améliore la fiabilité globale de vos projets sur Compute Engine.

Avantages de l'utilisation de noms DNS zonaux

Cloud de Confiance by S3NS propose deux types de noms DNS internes : zonaux et globaux.

DNS zonal

Les noms DNS zonaux incluent le nom de votre instance Compute Engine, la zone dans laquelle elle se trouve et le projet auquel elle appartient. Ces noms sont résolus dans une zone spécifique. Par conséquent, my-vm.zone1.google.com est unique à zone1 et représente une instance différente de my-vm.zone2.google.com. Cette isolation offre un avantage clé :

  • Disponibilité améliorée : si une zone subit une panne, cela n'affecte pas la résolution DNS dans les autres zones, ce qui améliore la disponibilité de vos applications.

Le DNS zonal est la méthode de résolution DNS interne par défaut pour les organisations créées après le 6 septembre 2018.

DNS global

Les noms DNS globaux n'incluent pas la zone dans laquelle se trouve l'instance. Cela signifie que chaque instance doit avoir un nom DNS unique dans toutes les zones de votre projet. Cette approche présente un inconvénient majeur :

  • Point de défaillance unique : si le service DNS global rencontre des problèmes, cela peut avoir un impact sur toutes vos instances, quelle que soit la zone dans laquelle elles se trouvent. Cela peut entraîner les problèmes suivants :
    • Impossible de créer des instances : vous ne pourrez peut-être pas créer d'instances dans une région qui rencontre des défaillances du plan de contrôle.
    • Interruptions de service : il est possible que les services Compute Engine critiques, tels que l'autoscaling ou l'autoréparation pour les groupes d'instances gérés (MIG), ne fonctionnent pas correctement.

Approche recommandée pour migrer du DNS global vers le DNS zonal

En règle générale, le processus de migration DNS global vers DNS zonal comporte deux étapes :

  1. Configurer les nouveaux projets pour qu'ils utilisent le DNS zonal par défaut
  2. Migrez les projets existants du DNS global vers le DNS zonal en modifiant le paramètre de métadonnées DNS interne.

Il est possible que certains projets ne soient pas compatibles avec le DNS zonal. Ces projets nécessitent une analyse et un dépannage avant d'être migrés vers le DNS zonal.

Conseils sur la compatibilité des projets

Compute Engine vérifie l'historique DNS interne des 30 derniers jours pour déterminer si vous pouvez migrer vers le DNS zonal sans modifier le code. Même si la migration de votre projet est recommandée, Google vous conseille de vérifier que la configuration de votre charge de travail spécifique est prête pour le passage au DNS zonal. Pour vous assurer que tout se passe bien après la migration, examinez les facteurs environnementaux suivants :

1. Domaines de recherche DNS (Linux ou Unix uniquement)

Lorsque vous passez à un DNS zonal, Compute Engine ajoute un nouveau domaine au chemin de recherche de l'instance.

  • Quand effectuer la vérification : si vous exécutez des distributions Linux ou Unix plus anciennes qui utilisent glibc version 2.25 ou antérieure, le système est limité à six domaines de recherche.

  • Quand ignorer cette étape : si l'instance exécute l'un des systèmes d'exploitation suivants, vous n'avez rien à vérifier :

    • Windows
    • Container-Optimized OS
    • Debian 10 ou version ultérieure
    • Fedora CoreOS 27 ou version ultérieure
    • RHEL 8 ou version ultérieure
    • Ubuntu 18.04 ou version ultérieure
    • Images personnalisées utilisant glibc 2.26 ou version ultérieure

Pour vérifier votre environnement :

  1. Connectez-vous à votre instance Linux et vérifiez la version de glibc en exécutant la commande suivante :

    ldd --version

  2. Si vous utilisez glibc version 2.25 ou antérieure, affichez vos domaines de recherche actuels en exécutant la commande suivante :

    cat /etc/resolv.conf

    La ligne search dans le résultat affiche les domaines de recherche actuels. Pour ajouter un nouveau domaine de recherche sans dépasser la limite de six du système d'exploitation, vous ne devez pas avoir plus de cinq domaines.

Comment atténuer le problème :

Si votre instance dépasse la limite de domaine de recherche sur une version d'OS concernée, vous pouvez résoudre le problème en utilisant l'une des approches suivantes :

  • Créer une instance : créez une instance de remplacement à l'aide d'une image de l'OS conforme (par exemple, Debian 10 ou version ultérieure, ou RHEL 8 ou version ultérieure).
  • Mettez à jour l'instance existante : mettez à jour l'OS invité sur votre instance de calcul pour qu'il exécute un système d'exploitation conforme.

2. Longueur du nom de l'instance (anciens systèmes d'exploitation)

Le DNS zonal ajoute un qualificatif zonal au nom de domaine complet (FQDN) interne, ce qui allonge le nom global.

  • Quand effectuer la vérification : les anciens systèmes tels que Windows Server 2003 ou les versions antérieures sont limités à 15 caractères pour les noms en raison des anciennes conventions NetBIOS.
  • Que faire : si vous utilisez ces anciens systèmes, vérifiez que les noms DNS zonaux plus longs ne dépassent pas ce nombre maximal de caractères.

Les images d'OS Windows modernes ne sont pas concernées.

Comment atténuer le problème :

Si le nom d'une instance sur un ancien OS dépasse 15 caractères après l'ajout du qualificatif de zone, vous pouvez résoudre le problème en utilisant l'une des méthodes suivantes :

  • Renommez l'instance : arrêtez l'instance et renommez-la de sorte que le nom de domaine complet combiné ne dépasse pas la limite de 15 caractères de NetBIOS.
  • Mettez à niveau le système d'exploitation : mettez à jour l'OS invité de l'instance de calcul vers une image de système d'exploitation Windows moderne pour laquelle les restrictions de dénomination NetBIOS ne s'appliquent plus.

3. Réseaux VPC partagés

Si votre infrastructure utilise des projets de service connectés à l'aide d'un VPC partagé, la résolution de noms se comporte légèrement différemment après le passage au DNS zonal.

  • Que faire ? Pour assurer une communication fluide sur votre VPC partagé, vérifiez que vos applications résolvent les noms d'instance dans ces projets de service à l'aide du nom de domaine complet zonal. Le FQDN zonal inclut le nom de la zone spécifique.

Étapes suivantes