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 du DNS global vers le 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

Google Cloud 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 propre à 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, il peut affecter 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 en cas de défaillance du plan de contrôle.
    • Interruptions de service: les services Compute Engine critiques tels que l'autoscaling ou l'autoréparation pour les groupes d'instances gérés (MIG) peuvent ne pas fonctionner correctement.

Les organisations intégrées à Google Cloud avant le 6 septembre 2018 sont configurées pour utiliser le DNS global par défaut pour tous les nouveaux projets. Google recommande vivement de migrer ces projets vers un DNS zonal afin d'améliorer la fiabilité et d'éviter les interruptions de service mentionnées précédemment. De plus, vous devez mettre à jour la règle d'administration de l'organisation pour appliquer l'utilisation du DNS zonal pour tous les nouveaux projets créés dans l'organisation.

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. Configurez 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 des métadonnées DNS internes.

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.

Limites concernant la migration

L'évaluation de l'état de préparation fournie par Compute Engine s'appuie sur l'historique des requêtes DNS internes des 30 derniers jours. Toutefois, d'autres facteurs peuvent affecter votre capacité à migrer vers un DNS zonal:

Version de glibc

La migration vers le DNS zonal ajoute un nouveau domaine au chemin de recherche. Les instances Compute qui exécutent un OS Linux ou Unix et utilisent la version 2.25 ou antérieure de glibc sont limitées à six domaines de recherche. Dépasser cette limite peut entraîner des problèmes.

  • Instances concernées: cette limitation s'applique aux VM utilisant des distributions Linux ou Unix plus anciennes.
  • Instances non affectées: instances pour lesquelles les systèmes d'exploitation suivants ne sont pas concernés :
    • 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 qui utilisent glibc 2.26 ou version ultérieure

Pour vérifier la version de glibc utilisée par votre instance, procédez comme suit:

  1. Connectez-vous à la VM Linux.
  2. Exécutez la commande ldd --version.

Si votre instance utilise glibc version 2.25 ou antérieure, vérifiez les domaines de recherche:

  1. Connectez-vous à la VM Linux.
  2. Exécutez la commande cat /etc/resolv.conf.

Version de l'OS

Certains systèmes d'exploitation, tels que Windows Server 2003 et versions antérieures, limitent les noms d'instance de calcul à 15 caractères. Le DNS zonal ajoute le qualificatif zonal au nom de domaine complet (FQDN) du DNS interne.

La limitation de dénomination sous Windows est le résultat de la convention d'attribution de noms NetBIOS utilisée dans les versions antérieures de l'OS. Les versions plus récentes de Windows ont abandonné cette restriction et autorisent des noms d'instance plus longs.

Si vous utilisez d'anciens systèmes Windows, gardez à l'esprit la limite de dénomination lors de la migration vers le DNS zonal, car les noms DNS zonaux plus longs peuvent dépasser cette limite de longueur de nom.

Réseaux VPC partagés

Pour résoudre les noms DNS des instances dans les projets de service qui utilisent un VPC partagé, vous devez utiliser le nom de domaine complet zonal, qui inclut la zone.

Étape suivante