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 unique à zone1 et représente une instance différente de my-vm.zone2.google.com. Cette isolation présente un avantage clé :

  • Disponibilité améliorée : si une zone connaît 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 :
    • Impossibilité de créer des instances : il est possible que vous ne puissiez pas créer d'instances dans les régions où le plan de contrôle présente des défaillances.
    • Indisponibilité des services : 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.

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 pour améliorer la fiabilité et éviter les interruptions de service mentionnées précédemment. De plus, vous devez mettre à jour la règle d'administration 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. 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 un 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 le DNS zonal :

Version de glibc

La migration vers le DNS zonal ajoute un nouveau domaine au chemin de recherche. Les instances de calcul qui exécutent un OS Linux ou Unix et utilisent glibc version 2.25 ou antérieure 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 d'anciennes distributions Linux ou Unix.
  • Instances non concernées : instances dont 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 utilisant glibc version 2.26 ou 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 la version 2.25 ou antérieure de glibc, 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 le nombre de caractères des noms d'instances de calcul à 15. Le DNS zonal ajoute le qualificatif zonal au nom de domaine complet (FQDN) du DNS interne.

La limitation de nommage sur Windows est due à la convention de nommage NetBIOS utilisée dans les versions antérieures de l'OS. Les versions plus récentes de Windows ne sont plus soumises à cette restriction et autorisent les noms d'instance plus longs.

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

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.

Étapes suivantes