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

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 est en 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 : il est possible que vous ne puissiez pas créer de nouvelles 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.

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

En règle générale, le processus de migration du DNS global vers le 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 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 votre historique de votre DNS interne des 30 jours précédents 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 spécifique de votre charge de travail 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 au DNS zonal, Compute Engine ajoute un nouveau domaine au chemin de recherche de l'instance.

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

  • Quand ignorer : 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 la version 2.26 ou ultérieure de glibc

Comment 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 la version 2.25 ou antérieure de glibc, affichez vos domaines de recherche actuels en exécutant la commande suivante :

    cat /etc/resolv.conf

    La ligne search de la sortie affiche les domaines de recherche actuels. Vous ne devez pas avoir plus de cinq domaines pour ajouter un nouveau domaine de recherche en toute sécurité et éviter de dépasser la limite de six du système d'exploitation.

Minimiser le problème

Si votre instance dépasse la limite de domaine de recherche sur une version de système d'exploitation affecté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 système d'exploitation compatible (telle que Debian 10+ ou RHEL 8+).
  • Mettre à jour l'instance existante : mettez à jour le système d'exploitation invité sur votre instance de calcul afin qu'elle exécute un système d'exploitation compatible.

2. Longueur du nom d'instance (systèmes d'exploitation hérités)

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

  • Quand vérifier : les systèmes hérités tels que Windows Server 2003 ou version antérieure sont limités à 15 caractères en raison des anciennes conventions NetBIOS.
  • Que faire : si vous utilisez ces systèmes hérités, vérifiez que les noms DNS zonaux plus longs ne dépassent pas cette limite de caractères.

Les images de système d'exploitation Windows modernes ne sont pas concernées.

Minimiser le problème

Si un nom d'instance sur un système d'exploitation hérité dépasse 15 caractères après l'ajout du qualificatif zonal, vous pouvez résoudre le problème en utilisant l'une des méthodes suivantes :

  • Renommer l'instance : arrêtez l'instance et renommez-la afin que le nom de domaine complet combiné reste dans la limite de 15 caractères de NetBIOS.
  • Mettre à niveau le système d'exploitation : mettez à jour le système d'exploitation invité de l'instance de calcul vers une image de système d'exploitation Windows moderne pour laquelle les restrictions de nommage 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 dans 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 nom de domaine complet zonal inclut le nom de zone spécifique.

Étape suivante