In diesem Dokument werden die Vorteile und der empfohlene Ansatz für die Migration Ihrer Arbeitslasten und Organisation von globalem DNS zu zonalem DNS beschrieben.
Zonales DNS verringert das Risiko regionsübergreifender Ausfälle und verbessert die allgemeine Zuverlässigkeit Ihrer Projekte in Compute Engine.
Vorteile der Verwendung von zonalen DNS-Namen
Google Cloud bietet zwei Arten von internen DNS-Namen: zonal und global.
- Zonales DNS
Zonale DNS-Namen umfassen den Namen Ihrer Compute Engine-Instanz, die Zone, in der sich die Instanz befindet, und das Projekt, zu dem die Instanz gehört. Diese Namen werden in einer bestimmten Zone aufgelöst. Daher ist
my-vm.zone1.google.com
eindeutig fürzone1
und stellt eine andere Instanz alsmy-vm.zone2.google.com
dar. Diese Isolation bietet einen entscheidenden Vorteil:- Verbesserte Verfügbarkeit: Wenn es in einer Zone zu einem Ausfall kommt, wirkt sich das nicht auf die DNS-Auflösung in anderen Zonen aus. Das führt zu einer höheren Verfügbarkeit Ihrer Anwendungen.
Zonales DNS ist die standardmäßige interne DNS-Auflösungsmethode für Organisationen, die nach dem 6. September 2018 erstellt wurden.
- Globales DNS
Globale DNS-Namen umfassen nicht die Zone, in der sich die Instanz befindet. Das bedeutet, dass jede Instanz in allen Zonen Ihres Projekts einen eindeutigen DNS-Namen haben muss. Dieser Ansatz hat einen erheblichen Nachteil:
- Single Point of Failure: Wenn der globale DNS-Dienst Probleme hat, kann dies alle Ihre Instanzen beeinträchtigen, unabhängig davon, in welcher Zone sie sich befinden. Dies kann zu folgenden Problemen führen:
- Neue Instanzen können nicht erstellt werden: Möglicherweise können Sie in keiner Region, in der Fehler auf der Steuerungsebene auftreten, neue Instanzen erstellen.
- Dienstunterbrechungen: Wichtige Compute Engine-Dienste wie Autoscaling oder automatische Reparatur für verwaltete Instanzgruppen (MIGs) funktionieren möglicherweise nicht richtig.
- Single Point of Failure: Wenn der globale DNS-Dienst Probleme hat, kann dies alle Ihre Instanzen beeinträchtigen, unabhängig davon, in welcher Zone sie sich befinden. Dies kann zu folgenden Problemen führen:
Organisationen, die vor dem 6. September 2018 in Google Cloud eingebunden wurden, sind so konfiguriert, dass sie standardmäßig globales DNS für alle neuen Projekte verwenden. Google empfiehlt dringend, diese Projekte auf zonales DNS umzustellen, um die Zuverlässigkeit zu erhöhen und die oben genannten Dienstausfälle zu vermeiden. Außerdem sollten Sie die Organisationsrichtlinie aktualisieren, um die Verwendung von zonalem DNS für alle neuen Projekte zu erzwingen, die in der Organisation erstellt werden.
Empfohlene Vorgehensweise für die Migration vom globalen DNS zum zonalen DNS
Im Allgemeinen umfasst die Migration vom globalen DNS zum zonalen DNS zwei Schritte:
- Konfigurieren Sie neue Projekte so, dass sie standardmäßig zonales DNS verwenden.
- Migrieren Sie vorhandene Projekte von der Verwendung des globalen DNS zum zonalen DNS, indem Sie die Metadateneinstellung für das interne DNS ändern.
Einige Projekte sind möglicherweise nicht mit zonalem DNS kompatibel. Diese Projekte müssen analysiert und Fehler behoben werden, bevor sie zu zonalem DNS migriert werden können.
Migrationseinschränkungen
Die von Compute Engine bereitgestellte Bereitschaftsbewertung basiert auf dem internen DNS-Abfrageverlauf der letzten 30 Tage. Es gibt jedoch auch andere Faktoren, die sich auf die erfolgreiche Migration zu zonalem DNS auswirken können:
glibc-Version
Bei der Migration zu zonalem DNS wird dem Suchpfad eine neue Domain hinzugefügt. Für Compute-Instanzen, auf denen ein Linux- oder Unix-Betriebssystem ausgeführt wird und die glibc
-Version 2.25 oder früher verwenden, gilt ein Limit von sechs Suchdomains. Das Überschreiten dieses Limits kann zu Problemen führen.
- Betroffene Instanzen: Diese Einschränkung gilt für VMs mit älteren Linux- oder Unix-Distributionen.
- Nicht betroffene Instanzen: Instanzen, die nicht von den folgenden Betriebssystemen betroffen sind:
- Windows
- Container-Optimized OS
- Debian 10 oder höher
- Fedora CoreOS (Version 27 oder höher)
- RHEL 8 oder höher
- Ubuntu 18.04 oder höher
- Benutzerdefinierte Images, die
glibc
-Version 2.26 oder höher verwenden
So prüfen Sie die von Ihrer Instanz verwendete glibc-Version:
- Stellen Sie eine Verbindung zu Ihrer Linux-VM her.
- Führen Sie den Befehl
ldd --version
aus:
Wenn auf Ihrer Instanz glibc
-Version 2.25 oder früher verwendet wird, prüfen Sie die Suchdomains:
- Stellen Sie eine Verbindung zu Ihrer Linux-VM her.
- Führen Sie den Befehl
cat /etc/resolv.conf
aus.
Betriebssystemversion
Bei einigen Betriebssystemen, z. B. Windows Server 2003 und älter, ist die Länge von Namen von Compute-Instanzen auf 15 Zeichen begrenzt. Beim zonalen DNS wird dem vollständig qualifizierten Domainnamen (Fully Qualified Domain Name, FQDN) des internen DNS der zonale Qualifikator hinzugefügt.
Die Namensbeschränkung unter Windows ist auf die NetBIOS-Namenskonvention zurückzuführen, die in früheren Versionen des Betriebssystems verwendet wurde. Bei neueren Windows-Versionen wurde diese Einschränkung aufgehoben und längere Instanznamen sind zulässig.
Wenn Sie mit älteren Windows-Systemen arbeiten, sollten Sie die Namensbeschränkung bei der Migration zu zonalen DNS-Namen beachten, da die längeren zonalen DNS-Namen dieses Namenslängenlimit überschreiten könnten.
Freigegebene VPC-Netzwerke
Zum Auflösen von DNS-Namen von Instanzen in Dienstprojekten, die freigegebene VPC verwenden, müssen Sie den zonalen voll qualifizierten Domainnamen (Fully Qualified Domain Name, FQDN) verwenden, der die Zone enthält.
Nächste Schritte
- Informationen zur Beziehung zwischen Organisationen, Ordnern und Projekten finden Sie in der Google Cloud Ressourcenhierarchie.
- Weitere Informationen zum internen DNS für Compute Engine.