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 demy-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.
- 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 :
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:
- Configurez les nouveaux projets pour qu'ils utilisent le DNS zonal par défaut.
- 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:
- Connectez-vous à la VM Linux.
- Exécutez la commande
ldd --version
.
Si votre instance utilise glibc
version 2.25 ou antérieure, vérifiez les domaines de recherche:
- Connectez-vous à la VM Linux.
- 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
- Consultez la hiérarchie des ressourcesGoogle Cloud pour en savoir plus sur la relation entre les organisations, les dossiers et les projets.
- Apprenez-en plus sur le DNS interne pour Compute Engine.