In diesem Dokument werden die Vorteile und der empfohlene Ansatz für die Migration Ihrer Arbeitslasten und Ihrer Organisation von globalem DNS zu zonalem DNS beschrieben.
Zonales DNS verringert das Risiko regionsübergreifender Ausfälle und verbessert die Zuverlässigkeit Ihrer Projekte in der Compute Engine insgesamt.
Vorteile der Verwendung zonaler DNS-Namen
Google Cloud bietet zwei Arten von internen DNS-Namen: zonale und globale.
- 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 innerhalb einer bestimmten Zone aufgelöst. Daher ist
my-vm.zone1.google.com
fürzone1
eindeutig und stellt eine andere Instanz alsmy-vm.zone2.google.com
dar. Diese Isolation bietet einen wichtigen Vorteil:- Verbesserte Verfügbarkeit: Wenn in einer Zone ein Ausfall auftritt, hat dies keine Auswirkungen auf die DNS-Auflösung in anderen Zonen. 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 einen eindeutigen DNS-Namen in allen Zonen Ihres Projekts haben muss. Dieser Ansatz hat einen erheblichen Nachteil:
- Single Point of Failure: Wenn Probleme mit dem globalen DNS-Dienst auftreten, kann das Auswirkungen auf alle Ihre Instanzen haben, unabhängig von der Zone, in der sie sich befinden. Dies kann zu den folgenden Problemen führen:
- Keine neuen Instanzen können erstellt werden: In Regionen, in denen Fehler auf der Steuerungsebene auftreten, können möglicherweise keine neuen Instanzen erstellt werden.
- 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 Probleme mit dem globalen DNS-Dienst auftreten, kann das Auswirkungen auf alle Ihre Instanzen haben, unabhängig von der Zone, in der sie sich befinden. Dies kann zu den folgenden Problemen führen:
Organisationen, die vor dem 6. September 2018 in Google Cloud eingebunden wurden, sind so konfiguriert, dass für alle neuen Projekte standardmäßig globales DNS verwendet wird. 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 in der Organisation zu erzwingen.
Empfohlener Ansatz für die Migration von globalem DNS zu zonalem 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.
- Sie können vorhandene Projekte von der Verwendung des globalen DNS auf das zonale DNS umstellen, indem Sie die Einstellung für interne DNS-Metadaten ändern.
Einige Projekte sind möglicherweise nicht mit zonalen DNS-Einträgen kompatibel. Diese Projekte müssen analysiert und Fehler behoben werden, bevor sie zu einem zonalen DNS migriert werden können.
Migrationseinschränkungen
Die von der Compute Engine bereitgestellte Bereitschaftsbewertung basiert auf dem internen DNS-Abfrageverlauf der letzten 30 Tage. Es gibt jedoch weitere Faktoren, die sich auf die erfolgreiche Migration zu zonalem DNS auswirken können:
glibc-Version
Wenn Sie zu zonalem DNS migrieren, wird dem Suchpfad eine neue Domain hinzugefügt. Bei Compute-Instanzen, auf denen ein Linux- oder Unix-Betriebssystem ausgeführt wird und die glibc
Version 2.25 oder niedriger verwenden, ist die Anzahl der Suchdomains auf sechs beschränkt. 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 mit den folgenden Betriebssystemen sind nicht betroffen:
- 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, für die
glibc
-Version 2.26 oder höher verwendet wird
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 in Ihrer Instanz glibc
-Version 2.25 oder niedriger 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 maximale Länge von Namen für Compute-Instanzen auf 15 Zeichen beschränkt. Beim zonalen DNS wird dem voll qualifizierten Domainnamen (Fully Qualified Domain Name, FQDN) des internen DNS der zonale Kvalifikator hinzugefügt.
Die Namensbeschränkung unter Windows ist auf die NetBIOS-Namenskonvention zurückzuführen, die in früheren Versionen des Betriebssystems verwendet wurde. In neueren Windows-Versionen ist diese Einschränkung aufgehoben und längere Instanznamen sind zulässig.
Wenn Sie mit älteren Windows-Systemen arbeiten, denken Sie bei der Migration zu zonalen DNS-Namen an die Namensbeschränkung, da die längeren zonalen DNS-Namen diese Längenbeschränkung möglicherweise überschreiten.
Freigegebene VPC-Netzwerke
Zum Auflösen der DNS-Namen von Instanzen in Dienstprojekten, die Shared VPC verwenden, müssen Sie den zonalen voll qualifizierten Domainnamen (FQDN) verwenden, der die Zone enthält.
Nächste Schritte
- In der Google Cloud Ressourcenhierarchie finden Sie Informationen zur Beziehung zwischen Organisationen, Ordnern und Projekten.
- Weitere Informationen zum internen DNS für Compute Engine.