Zonales DNS verringert das Risiko regionsübergreifender Ausfälle und verbessert die Zuverlässigkeit der Projekte in Compute Engine. Die Verwendung von zonalem DNS reduziert die Auswirkungen von Einzelpunktfehlern, die bei der Verwendung von globalem DNS auftreten können.
Hinweise
-
Richten Sie die Authentifizierung ein, falls Sie dies noch nicht getan haben.
Bei der Authentifizierung wird Ihre Identität für den Zugriff auf Google Cloud-Dienste und APIs überprüft.
Zur Ausführung von Code oder Beispielen aus einer lokalen Entwicklungsumgebung können Sie sich so bei Compute Engine authentifizieren.
Select the tab for how you plan to use the samples on this page:
Console
When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.
gcloud
-
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init
- Set a default region and zone.
-
Erstellen oder aktualisieren Sie eine Organisationsrichtlinie:
Organization Policy Administrator (
roles/orgpolicy.policyAdmin
) für den Ordner oder die Organisation -
Prüfen Sie, ob ein Ordner für die Migration zu zonalem DNS bereit ist:
Browser (
roles/browser
) für den Ordner oder die Organisation -
Projekt für die Verwendung des zonalen DNS migrieren:
Project Editor (
roles/resourcemanager.projectEditor
) für das Projekt -
VMs zum zonalen DNS innerhalb eines Projekts migrieren:
Compute Instance Admin (v1) (
roles/compute.instanceAdmin.v1
) für das Projekt -
Wenn Ihre VM ein Dienstkonto verwendet: Service Account User (
roles/iam.serviceAccountUser
) für das Dienstkonto oder Projekt -
Organisationsrichtlinieneinschränkung festlegen:
orgpolicy.*
-
Ermitteln Sie, ob ein Ordner zu einem zonalen DNS migriert werden kann:
-
resourcemanager.folders.get
-
resourcemanager.folders.list
-
resourcemanager.organizations.get
-
resourcemanager.projects.get
-
resourcemanager.projects.list
-
-
Suchen Sie nach globalen DNS-Namen und VM-Metadaten:
compute.projects.get
-
Metadaten auf einer VM festlegen:
compute.instances.setMetadata
-
Projektweite Metadaten festlegen:
compute.projects.setCommonInstanceMetadata
-
Wenn Ihre VMs Dienstkonten verwenden:
iam.serviceAccounts.actAs
- Der Name wird auf globaler Ebene aufgelöst.
- Jede VM muss einen eindeutigen DNS-Namen haben.
- Beim Erstellen einer neuen VM muss der DNS-Name für die VM mit allen anderen globalen DNS-Namen verglichen werden, die im selben Projekt registriert sind, um einen DNS-Namenskonflikt zu vermeiden.
- Der Name wird innerhalb einer Zone aufgelöst.
- Zonale DNS-Namen müssen innerhalb einer Zone eindeutig sein. Beispiel:
my-vm.zone1.google.com
muss fürzone1
eindeutig sein. Im Gegensatz zu globalen DNS-Namen istmy-vm.zone2.google.com
jedoch auch ein gültiger DNS-Name, wenn zonales DNS verwendet wird. - Es können keine neuen VMs in einer Region erstellt werden, bei der ein Fehler auf der Steuerungsebene auftritt, in der Sie ein Projekt haben oder zuvor hatten.
- Unfähigkeit, einige für Ihre Arbeitslasten wichtige Compute Engine-Dienste zu verwenden, z. B. Autoscaling oder die automatische Reparatur für verwaltete Instanzgruppen (MIGs).
- Organisations- oder Ordnerebene: Bestimmen Sie die Ordner- oder Organisationsbereitschaft für die Migration zu zonalem DNS. Verhindern Sie, dass neue Projekte das globale DNS verwenden. Wird vom Organisationsadministrator ausgeführt.
- Projektebene: Migrieren Sie ein einzelnes Projekt von globalem DNS zu zonalem DNS. Wird normalerweise vom Projektinhaber ausgeführt.
- Prüfen Sie, ob der Ordner oder die Organisation für die Migration zu zonalem DNS bereit ist.
- Wenn der Ordner oder die Organisation für die Migration zum zonalen DNS bereit ist:
- Der Organisationsadministrator legt eine Organisationsrichtlinie für den Ordner oder die Organisation fest, um die zukünftige Verwendung des globalen DNS zu verhindern.
- Projektinhaber migrieren ihre Projekte zur Verwendung des zonalen DNS.
- Wenn der Ordner oder die Organisation nicht für die Migration zu zonalem DNS bereit ist:
- Projektinhaber migrieren einsatzbereite Projekte zu zonalem DNS.
- Projektinhaber untersuchen die globale DNS-Nutzung in Projekten, die nicht bereit sind.
- Projektinhaber wenden Verbesserungen des Suchpfads oder andere Änderungen an, um das Projekt für die Migration zu zonalem DNS vorzubereiten.
- Der Organisationsadministrator prüft den Status des Ordners oder der Bereitschaft der Organisation für die zonale DNS-Migration noch einmal.
Zonales DNS ist kein vollständiger Ersatz des globalen DNS. Es gibt einige Abfragetypen (zonenübergreifend), die möglicherweise nicht von zonalem DNS mit automatischem Suchpfad aufgelöst werden. Prüfen Sie die Migrationsbereitschaft der Ordner und Projekte Ihres Unternehmens, um sicherzustellen, dass sie vor der Migration mit dem zonalen DNS kompatibel sind.
Bei der Migration von globalem DNS zu zonalem DNS wird im Suchpfad eine neue Domain (
ZONE.c.PROJECT_ID.internal
) eingeführt. Wenn eine VM, auf der Linux oder Unix ausgeführt wird, bereits sechs Domains im Suchpfad hat, achten Sie darauf, dass die VM mitglibc
Version 2.26 oder höher ausgeführt wird. DHCP-Clients mitglibc
2.25 und früheren Versionen unterstützen nur bis zu sechs Suchdomains. Daher besteht das Risiko, eine vorhandene Suchdomain zu verwerfen. Dieses Limit gilt nicht für VMs, die Folgendes verwenden:- Windows-Images
- Container-Optimized OS-Images
- Debian 10 oder höher
- Fedora CoreOS (Version 27 oder höher)
- Images von RHEL 8 oder höher
- Ubuntu-Release 18.04 oder höher
- Andere Images mit
glibc
-Version 2.26 oder höher
Wenn Sie die Suchpfadverbesserung aktivieren, werden einige weitere Suchdomains hinzugefügt, z. B.
NEIGHBOR_ZONE.c.PROJECT_ID.internal
. Wie in der vorherigen Einschränkung erwähnt, werden vorhandene Domains im Suchpfad möglicherweise entfernt, wenn das Domainlimit des Suchpfads bei Verwendung vonglibc
Version 2.25 oder früher überschritten wird.Wenn Sie die Suchpfadverbesserungen mit Google Kubernetes Engine verwenden möchten, müssen Sie die Google Kubernetes Engine-Version 1.26 oder höher verwenden.
- Stellen Sie eine Verbindung zu Ihrer Linux-VM her.
- Führen Sie
ldd --version
aus, um die Versionglibc
abzurufen. Prüfen Sie, ob Ihre Linux-VM bereits sechs Domains im Suchpfad hat. Sie können
cat /etc/resolv.conf
ausführen, um diese Informationen aufzurufen.- Prüfen, ob Ihre Organisation standardmäßig globales DNS verwendet.
- Festlegen, welche Projekte in einem Ordner oder einer Organisation ein globales DNS verwenden.
- Prüfen, ob ein Ordner für die Migration zu zonalem DNS bereit ist.
- Zonales DNS als Standard für neue Projekte konfigurieren.
- Ausgenommene Ordner sind nicht bereit, von der Organisationsrichtlinieneinschränkung zu einem zonalen DNS zu migrieren.
Gehen Sie zu IAM und Verwaltung> Identität und Organisation in der Console.
Prüfen Sie das Registrierungsdatum der Organisation.
- Wenn Ihre Organisation nach dem 6. September 2018 erstellt wurde, verwendet sie standardmäßig zonales DNS. In diesem Fall sind keine weiteren Maßnahmen erforderlich.
- Wenn Ihre Organisation vor dem 6. September 2018 erstellt wurde, verwendet Ihre Organisation standardmäßig globales DNS und sollte zu zonalem DNS migriert werden.
Wenn Ihre Organisation standardmäßig globales DNS verwendet, prüfen Sie, ob eine Organisationsrichtlinieneinschränkung den Standard-DNS-Typ für alle neu erstellten Projekte auf zonales DNS setzt.
- Wechseln Sie in der Google Cloud Console zur Seite IAM & Verwaltung> Organisationsrichtlinien.
- Geben Sie im Filter
constraints/compute.setNewProjectDefaultToZonalDNSOnly
ein: - Wenn die Einschränkung konfiguriert ist, klicken Sie auf den Namen Legt die interne DNS-Einstellung für neue Projekte so fest, dass nur zonales DNS verwendet wird.
- Prüfen Sie auf der Seite Richtliniendetails den Status.
- Wenn der Status Erzwungen lautet, ist der interne DNS-Standardtyp für alle neuen Projekte, die in der Organisation erstellt werden, zonales DNS.
- Andernfalls wird der Standard-DNS-Typ für das Projekt weiterhin durch die Erstellungszeit der Organisation bestimmt.
- Wenn die Einschränkung nicht für die Organisation konfiguriert wurde, wird der Standard-DNS-Typ für das Projekt durch den Erstellungszeitpunkt der Organisation bestimmt, wie im ersten Schritt beschrieben.
Prüfen Sie den Metadatenwert
creationTime
der Organisation.gcloud organizations describe ORGANIZATION_ID
Ersetzen Sie ORGANIZATION_ID durch die Organisations-ID oder den Domainnamen der Organisation.
- Wenn Ihre Organisation nach dem 6. September 2018 erstellt wurde, verwendet sie standardmäßig zonales DNS. In diesem Fall verwendet Ihre Organisation bereits zonales DNS und es sind keine weiteren Maßnahmen erforderlich.
- Wenn Ihre Organisation vor dem 6. September 2018 erstellt wurde, verwendet Ihre Organisation standardmäßig globales DNS und sollte zu zonalem DNS migriert werden.
Wenn Ihre Organisation standardmäßig globales DNS verwendet, können Sie prüfen, ob eine Einschränkung der Organisationsrichtlinie konfiguriert ist, um den Standard-DNS-Typ für alle neu erstellten Projekte auf zonales DNS festzulegen.
gcloud resource-manager org-policies list --organization=ORGANIZATION_ID \ --filter="constraints/compute"
Suchen Sie in der Ausgabe nach
constraints/compute.setNewProjectDefaultToZonalDNSOnly
.- Wenn die Einschränkung konfiguriert ist und
Status
Enforced
ist, ist der interne DNS-Standardtyp zonales DNS für alle neuen Projekte, die in der Organisation erstellt werden. - Wenn die Einschränkung nicht für die Organisation konfiguriert wurde oder nicht erzwungen wird, wird der standardmäßige interne DNS-Typ durch den Erstellungszeitpunkt der Organisation bestimmt, wie im ersten Schritt beschrieben.
- Wenn die Einschränkung konfiguriert ist und
- Erstellen Sie ein BigQuery-Dataset.
Exportieren Sie die Asset-Metadaten für Ihre Organisation in eine BigQuery-Tabelle.
- Prüfen Sie, ob die Cloud Asset Inventory API aktiviert ist.
- Konfigurieren Sie die Berechtigungen, die für die Verwendung der Cloud Asset Inventory API erforderlich sind.
Verwenden Sie den folgenden gcloud CLI-Befehl, um das Asset
compute.googleapis.com/Project
zu exportieren:gcloud asset export \ --content-type resource \ --organization 'ORGANIZATION_ID' \ --bigquery-table 'projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_NAME' \ --asset-types='compute.googleapis.com/Project' \ --output-bigquery-force
Ersetzen Sie Folgendes:
- ORGANIZATION_ID: die Organisations-ID
- PROJECT_ID: die Projekt-ID
- DATASET_ID: den Namen des BigQuery-Datasets
- TABLE_NAME: die Tabelle, in die Sie Ihre Metadaten exportieren. Wenn die Tabelle nicht vorhanden ist, wird sie erstellt.
Rufen Sie in der Google Cloud Console die Seite BigQuery auf.
Wählen Sie
Neue Abfrage erstellen aus.Geben Sie im Textbereich des Abfrageeditors die folgende GoogleSQL-Abfrage ein und klicken Sie dann auf
Ausführen.SELECT JSON_VALUE(SAFE.PARSE_JSON(resource.data).vmDnsSetting) AS vmDnsSetting, count(*) as project_count FROM PROJECT_ID.DATASET_ID.TABLE_NAME GROUP BY 1
Ersetzen Sie Folgendes:
- PROJECT_ID: die Projekt-ID
- DATASET_ID: den Namen des BigQuery-Datasets
- TABLE_NAME: die Tabelle, die die exportierten Metadaten enthält, aus Schritt 2.
Projekte mit dem Wert
ZONAL_ONLY
fürvmDnsSetting
haben ein zonales DNS. Andernfalls wird für die Projekte globales DNS verwendet.Optional: Wenn Sie eine detaillierte Ansicht von
vmDnsSetting
für jedes Projekt aufrufen möchten, geben Sie die folgende GoogleSQL-Abfrage ein und klicken Sie dann auf Ausführen.SELECT SUBSTR(name,35) as project_id, JSON_VALUE(SAFE.PARSE_JSON(resource.data).vmDnsSetting) AS vmDnsSetting FROM PROJECT_ID.DATASET_ID.TABLE_NAME
- Der Ordner ist bereit, wenn alle Projekte in den letzten 30 Tagen keine Abfragen ausgeführt haben, die nicht mit zonalem DNS kompatibel sind.
- Wenn ein Ordner nicht für die Migration bereit ist, antwortet das Script mit den Projekt-IDs in dem Ordner, die dazu führen, dass der Ordner nicht für die Migration bereit ist. Die Projekte in dieser Ergebnisliste sind noch nicht mit zonalem DNS kompatibel und erfordern zusätzliche Aktionen.
- Rufen Sie die Ordner-ID ab. Wenn Sie die Ordner-ID nicht kennen:
- Rufen Sie in der Google Cloud Console die Seite Verwaltete Ressourcen auf.
- Wenden Sie den Filter
Name:FOLDER_NAME
an, um die Ordner-ID abzurufen.
Fragen Sie die BigQuery-Tabelle mit den exportierten
compute.Project assets
-Daten ab.Eine Anleitung zum Erstellen der BigQuery-Tabelle finden Sie unter Festlegen, welche Projekte in einem Ordner oder einer Organisation globales DNS verwenden.
Geben Sie die folgende GoogleSQL-Abfrage ein und klicken Sie dann auf
Ausführen:SELECT SUBSTR(name,35) AS project_id, FROM PROJECT_ID.DATASET_ID.TABLE_NAME WHERE CONTAINS_SUBSTR(ancestors, 'FOLDER_NUMBER')
Ersetzen Sie Folgendes:
- PROJECT_ID: die Projekt-ID
- DATASET_ID: den Namen des BigQuery-Datasets
- TABLE_NAME: die Tabelle mit den exportierten Metadaten.
- FOLDER_NUMBER: die Ordner-ID
Kopieren Sie die Projekt-ID-Liste und speichern Sie sie in einer Datei.
Führen Sie das folgende Script
bash
aus: Das Script durchläuft die Projekt-IDs in der gespeicherten Datei, um festzustellen, ob ein Ordner für die Migration bereit ist.- Ordner und Projekte, die sicher migriert werden können, müssen die Projektinhaber darüber informieren, dass sie mit der Migration von einsatzbereiten Projekten beginnen können.
- Weisen Sie Projektinhabern bei Ordnern, die nicht sicher migriert werden können, die Projektinhaber an, Projekte zu ändern, die nicht migriert werden können.
Melden Sie sich in der Google Cloud Console als Super Admin für Google Workspace oder Cloud Identity an.
Wechseln Sie in der Konsole zur Seite Organisationsrichtlinien.
Wählen Sie den Ordner oder die Organisation aus, für die Sie Organisationsrichtlinien aufrufen möchten. In der Google Cloud Console wird eine Liste der verfügbaren Einschränkungen für Organisationsrichtlinien angezeigt. Die Liste kann mehrere Seiten umfassen.
Um die Richtlinie zum Erzwingen des zonalen DNS zu ermitteln, klicken Sie auf Filter und wählen Sie Name aus. Setzen Sie dann den Filternamen auf Legt die interne DNS-Einstellung für neue Projekte so fest, dass nur zonales DNS verwendet wird.
Klicken Sie auf den Richtliniennamen, um die Details aufzurufen.
Auf der Seite „Richtliniendetails“ finden Sie Informationen zur Einschränkung und zur aktuellen Anwendung der Einschränkung.
Standardmäßig ist die Erzwingung für einen Ordner oder eine Organisation nicht definiert. Wenn jedoch ein übergeordneter Ordner eine definierte Erzwingung hat, wird die Erzwingung vom nächstgelegenen übergeordneten Ordner übernommen, der eine definierte Erzwingung hat. Weitere Informationen finden Sie unter Informationen zu Evaluierungen der Hierarchie.
Klicken Sie auf Bearbeiten, um die Organisationsrichtlinie anzupassen.
Wählen Sie auf der Bearbeitungsseite Anpassen aus.
Wählen Sie unter Erzwingung die Option An aus.
Dadurch wird der standardmäßige interne DNS-Typ für alle neuen Projekte in der Organisation auf zonales DNS festgelegt.
Klicken Sie auf Speichern.
folders/101
projects/301
(bereit für die Migration)folders/201
projects/303
(NICHT bereit)projects/304
(bereit für die Migration)
folders/102
projects/302
(bereit für die Migration)
- Melden Sie sich in der Google Cloud Console als Super Admin für Google Workspace oder Cloud Identity an.
Wechseln Sie in der Konsole zur Seite Organisationsrichtlinien.
Klicken Sie auf Auswählen und wählen Sie die Ordner aus, die Sie von der Organisationsrichtlinie ausnehmen möchten.
Die Google Cloud Console zeigt eine Liste von Einschränkungen für Organisationsrichtlinien für diesen Ordner auf einer oder mehreren Seiten an.
So ermitteln Sie die Einschränkung der Organisationsrichtlinie für das zonale DNS:
- Klicken Sie auf Filtern.
- Name auswählen.
- Legen Sie den Filternamen auf Legt die interne DNS-Einstellung für neue Projekte so fest, dass nur zonales DNS angezeigt wird.
Klicken Sie auf den Namen der Organisationsrichtlinieneinschränkung, um die Seite Richtliniendetails zu öffnen.
Klicken Sie auf Bearbeiten.
Wählen Sie auf der Seite Bearbeiten die Option Anpassen aus.
Wählen Sie unter Erzwingung die Option Aus aus, um die Erzwingung der Einschränkung zu deaktivieren. Dies bedeutet, dass der standardmäßige interne DNS-Typ für alle Projekte im Ordner durch den Erstellungszeitpunkt der Organisation bestimmt wird.
Klicken Sie auf Speichern.
- Den internen DNS-Standardtyp für Ihr Projekt festlegen.
- Prüfen, ob das Projekt zu einem zonalen DNS migriert werden kann.
- Projekt mit zonalem DNS migrieren.
- Globale DNS-Nutzung im Projekt verfolgen.
- Projekte ändern, die nicht zur Migration auf ein zonales DNS bereit sind.
- Prüfen, ob die Projektmigration zu zonalem DNS abgeschlossen ist.
- Projekt auf die Verwendung des globalen DNS zurücksetzen.
- Ausblenden der zonalen DNS-Migrationsbanner.
Rufen Sie in der Google Cloud Console die Seite Metadaten auf.
Sehen Sie sich auf dem Tab Metadaten die Einstellung
vmdnssetting
an. Der Wert gibt an, ob das Projekt standardmäßig globales DNS verwendet.GlobalDefault
: Für das Projekt ist das globale DNS aktiviert.ZonalOnly
: Projekt ist für das zonale DNS aktiviert. Dieses Projekt muss nicht migriert werden.
Führen Sie den folgenden gcloud CLI-Befehl aus, um den Wert von
vmDnsSetting
zu prüfen.gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"
Ersetzen Sie PROJECT_ID durch den Namen des Projekts.
Der zurückgegebene Wert gibt an, ob das Projekt standardmäßig globales DNS verwendet.
GLOBAL_DEFAULT
: Für das Projekt ist das globale DNS aktiviert.ZONAL_ONLY
: Das Projekt hat zonales DNS aktiviert. Dieses Projekt muss nicht migriert werden.
GLOBAL_DEFAULT
: Für das Projekt ist das globale DNS aktiviert.ZONAL_ONLY
: Projekt ist für das zonale DNS aktiviert. Dieses Projekt muss nicht migriert werden.Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.
Wählen Sie das Projekt aus.
Wenden Sie die Ressourcen- und Lognamenfilter an:
- Klicken Sie auf Ressource.
- Wählen Sie im Dialogfeld Ressource auswählen die Option VM-Instanz aus und klicken Sie dann auf Übernehmen.
- Klicken Sie auf Logname.
- Wählen Sie im Dialogfeld Lognamen auswählen die Option gdnsusage aus und klicken Sie auf Übernehmen.
zonal_dns_ready
: Die aggregierte Anzahl von Abfragen, die über das angegebene Zeitintervall abgeschlossen werden und die mithilfe eines zonalen DNS anstelle eines globalen DNS aufgelöst werden kann.zonal_dns_risky
: Die aggregierte Anzahl von Abfragen, die im angegebenen Zeitintervall abgeschlossen wurden und nicht mit zonalem DNS aufgelöst werden können. Für diese Abfragen konnte Compute Engine die relative interne IP-Adresse nicht vom aktuellen Hostnamen ermitteln. Wenn dieser Messwert einen Wert ungleich null hat, ist das Projekt nicht für die Migration bereit.-
Wählen Sie im Navigationsbereich der Google Cloud Console Monitoring und anschließend leaderboard Metrics Explorer aus:
Klicken Sie auf der rechten Seite der Symbolleiste, die das Feld Messwert auswählen enthält, auf Code-Editor, MQL oder PromQL.
Wenn das Abfrage-Eingabefeld nicht mit MQL-Abfrage betitelt ist, dann wählen Sie in der unteren rechten Ecke des Abfrage-Eingabefelds für Sprache die Option MQL.
Geben Sie im Eingabefeld für die Abfrage genau den folgenden Text ein:
fetch compute.googleapis.com/Location | metric 'compute.googleapis.com/global_dns/request_count' | every 1d | within 7d
Klicken Sie auf Abfrage ausführen.
Die Google Cloud Console zeigt ein Diagramm der beiden Messwerte (
zonal_dns_ready
undzonal_dns_risky
) und die entsprechende Anzahl von Abfragen im Zeitverlauf für jeden Messwert an.Prüfen Sie den Wert für den Messwert
zonal_dns_risky
.- Wenn der Wert
0
ist, kann das Projekt zu zonalem DNS migriert werden. Sie können das Projekt wie unter Projekte zum zonalen DNS migrieren beschrieben migrieren. - Wenn der Wert eine Zahl ungleich null ist, z. B.
0.02k
wie im vorherigen Screenshot gezeigt, gibt es einige Abfragen, die nach der Migration zu zonalem DNS möglicherweise nicht funktionieren. Das Projekt ist nicht für die Migration bereit. Fahren Sie mit dem Abschnitt Projekte ändern, die nicht zur Migration bereit sind fort.
- Wenn der Wert
- Überprüfen Sie Ihre Anwendungen und aktualisieren Sie sie, um Kompatibilitätsprobleme bei ausschließlich zonalen Einstellungen zu beheben:
- Wenn Sie eine Anwendung haben, die hartcodierte globale DNS-Namen verwendet, aktualisieren Sie diese so, dass zonale DNS-Namen verwendet werden.
- Wenn eine Anwendung VM-Namen für den Zugriff auf VMs in einer anderen Zone verwendet, muss der Name der Zielzone in der Abfrage hinzugefügt werden, z. B.
DESTINATION_VM_NAME.DESTINATION_ZONE_NAME
. - Zum Auflösen der DNS-Namen von VMs in Dienstprojekten, die ein freigegebenes VPC-Netzwerk verwenden, müssen Sie den zonalen voll qualifizierten Domainnamen (Fully Qualified Domain Name, FQDN) der VMs verwenden.
Klicken Sie im Banner auf der Seite VM-Instanzen der Google Cloud Console auf die Schaltfläche Zonales DNS verwenden. Dadurch werden die Projektmetadaten so geändert, dass zonales DNS verwendet wird.
Alternativ können Sie Ihre Projekte manuell so ändern, dass sie standardmäßig zonales DNS verwenden, wie in Projekte und VMs manuell aktualisieren, um zonales DNS zu verwenden und Neue Projekte daran hindern, standardmäßig globales DNS zu verwenden beschrieben.
Empfohlen: Legen Sie in den Projektmetadaten
vmDnsSetting=ZonalOnly
fest. Das bedeutet, dass auf Ihre VMs nur über ihre zonalen DNS-Namen (VM_NAME.ZONE.c.PROJECT_ID.internal
) zugegriffen werden kann. Die VMs behalten sowohl den zonalen als auch den globalen Suchpfad bei, aber ihre globalen DNS-Namen, dieZONE
nicht als Teil des internen DNS-Namens enthalten, funktionieren nicht mehr. Andere VMs können VMs mitvmDnsSetting
, die aufZonalOnly
festgelegt sind, nur über ihre zonalen DNS-Namen adressieren und können diese VMs nicht über ihre globalen DNS-Namen oder Suchpfade ansprechen. Dies ist die bevorzugte und zuverlässigere Option, sofern die Anwendungen dies unterstützen können.Dies ist die Standardeinstellung
vmDnsSetting=ZonalOnly
für VMs in eigenständigen Projekten und in einer Organisation erstellten Projekten, bei denen die Compute Engine API nach dem 06. September 2018 aktiviert wurde.Legen Sie
vmDnsSetting=GlobalDefault
so fest, dass VMs sowohl globale als auch zonale DNS-Namen registrieren, aber nur globale DNS-Namen als Standarddomainnamen und Suchpfadeinträge verwenden. Dies ist die Standardeinstellung für VMs in eigenständigen Projekten und in einer Organisation erstellten Projekten, bei denen die Compute Engine API vor dem 06. September 2018 aktiviert wurde.- Linux-VMs:
sudo dhclient -v -r
- Windows Server-VMs:
ipconfig /renew
- VM in einem anderen Projekt aufrufen
- VM in einer anderen Zone aufrufen
- Verbesserung des Suchpfads aktivieren, um zonenübergreifende DNS-Namenssuchen aufzulösen. Dadurch können Ihre Projekte möglicherweise für die Migration vorbereitet werden, ohne dass sich dies auf Ihre Ressourcen auswirkt.
- Wenn durch die Anpassung des Suchpfads nicht alle Ihre zonenübergreifenden Abfragen umgestellt werden, können Sie die Abfragen manuell aktualisieren, um zonale DNS-Namen zu verwenden.
- Wenn Sie die VM als
myapp-vm
aufrufen, versucht Compute Engine, den DNS-Namen mithilfe eines FQDN aufzulösen, der einen der Suchpfade an den VM-Namen anhängt, z. B.myapp-vm.c.PROJECT_ID.internal
. “ - Wenn die Ziel-VM zonales DNS verwendet, wird der FQDN für die Ziel-VM als
myapp-vm.us-west4-b.c.PROJECT_ID
.internal registriert. Daher kann der DNS-Name nicht aufgelöst werden. - Wenn Sie
us-west4-b.c.PROJECT_ID.internal
in die Suchliste aufnehmen, kann der DNS-Namemyapp-vm
aufgelöst werden, wennus-west4-b.c.PROJECT_ID.internal
an den VM-Namen angehängt wird. Führen Sie den Befehl
project-info add-metadata
so aus:gcloud compute project-info add-metadata \ --metadata=enable-search-path-improvement=true
Lassen Sie das Projekt einige Tage lang diese Einstellung verwenden und prüfen Sie dann den Monitoring-Messwert, um festzustellen, ob noch riskante oder zonenübergreifende globale DNS-Abfragen vorhanden sind.
- Wenn der Wert für das Projekt
0
lautet, kann das Projekt jetzt migriert werden. - Wenn das Projekt einen Wert ungleich null zurückgibt, ändern Sie alle globalen DNS-Abfragenamen so, dass der zonale FQDN verwendet wird, wie im nächsten Abschnitt beschrieben.
- Wenn der Wert für das Projekt
Führen Sie die Schritte unter Prüfen, ob Ihr Projekt für die Migration bereit ist aus, um die globale DNS-Nutzung für ein Projekt aufzurufen. Verwenden Sie den Log-Explorer, um auf die globale DNS-Nutzung für VMs in Ihrem Projekt zuzugreifen und sie abzufragen.
Im Bereich Abfrageergebnisse enthält jede Abfrage das Feld
jsonPayload
. JedesjsonPayload
-Feld enthält die folgenden Informationen:- Der Name der Quell-VM, ihre Projekt-ID und der Zonenname.
- Der Name der Ziel-VM, die Projekt-ID und der Zonenname.
Eine Debug-Nachricht mit Informationen zum Aktualisieren der globalen DNS-Abfrage, die nicht mithilfe von zonalen DNS-Namen aufgelöst werden kann. Dies sind Abfragen, die bei der Migration blockiert werden und die Sie beheben sollten.
"To use Zonal DNS, update the Global DNS query sent from the source VM VM_NAME.c.PROJECT_ID.internal to the following zonal FQDN: VM_NAME.ZONE.c.PROJECT_ID.internal"
Eine Abfrageanzahl, die zeigt, wie viele Migrationsblockierungsabfragen die Quell-VM für diesen Tag an die Ziel-VM sendet.
Der folgende Screenshot zeigt die Feldinformationen
jsonPayload
auf der Console-Seite des Log-Explorers.Ermitteln Sie anhand der Informationen in
jsonPayload
, welcher FQDN verwendet werden soll, um Ihre globalen DNS-Abfragen manuell für die Verwendung des zonalen DNS zu aktualisieren und das Projekt für die Migration vorzubereiten. Die häufigsten Anwendungsfälle, in denen der FQDN aktualisiert und die Kompatibilität aufgelöst wird, sind:- Interne DNS-Namen vom Metadatenserver: Es sind keine Maßnahmen erforderlich, da sich der zurückgegebene DNS-Name unmittelbar nach der Migration zum zonalen DNS in einen zonalen FQDN ändert. Wenn der DNS-Name im Cache gespeichert wird, müssen Sie nur einen weiteren Aufruf ausführen, um den Cache-Wert zu aktualisieren.
- Interne DNS-Namen, die für den Zugriff auf VMs in einer anderen Region verwendet werden: Wenn Sie eine Anwendung haben, die die internen DNS-Namen für VMs in verschiedenen Regionen verwendet, können Sie die DHCP-Richtlinie oder Konfigurationsdatei so ändern, dass die Zone in der anderen Region enthalten ist.
- Hartcodierter globaler FQDN: Wenn Sie eine Anwendung haben, die hartcodierte globale FQDN-Namen für VMs verwendet, können Sie den Aufruf innerhalb der Anwendung aktualisieren, um stattdessen den internen DNS-Namen oder den zonalen FQDN zu verwenden. Sie können diese Änderung über eine Code- oder Konfigurationsänderung in Terraform vornehmen.
- VMs in Dienstprojekten, die ein freigegebenes VPC-Netzwerk verwenden: Zum Auflösen von DNS-Namen von VMs in Dienstprojekten, die ein freigegebenes VPC-Netzwerk verwenden, müssen Sie die zonalen FQDNs der VMs verwenden.
- Verwenden Sie die Seite „Log-Explorer“, um die globale DNS-Nutzung noch einmal abzufragen. Nachdem Sie alle blockierenden globalen DNS-Abfragen korrigiert haben, sollten in den Abfrageergebnissen keine Debugging-Logs angezeigt werden.
- Prüfen Sie den Monitoringmesswert noch einmal, um festzustellen, ob alle riskanten DNS-Abfragen entfernt wurden.
Wiederholen Sie die Schritte unter Prüfen, ob Ihr Projekt standardmäßig globales DNS verwendet.
Wenn Sie testen möchten, ob die Projektmetadaten aktualisiert wurden, können Sie den folgenden Befehl ausführen:
gcloud compute project-info describe --flatten="vmDnsSetting"
Der Befehl sollte
ZONAL_ONLY
zurückgeben.Prüfen Sie, ob der interne DNS-Name für eine VM einen zonalen DNS-Namen verwendet.
So prüfen Sie, ob die Organisationsrichtlinie
constraints/compute.setNewProjectDefaultToZonalDNSOnly
erzwungen wird:- Erstellen Sie ein neues Projekt in dem Ordner oder der Organisation.
- VM-Instanz erstellen und starten
- Prüfen Sie, ob die VM einen zonalen DNS-Namen verwendet.
Deaktivieren Sie die Organisationsrichtlinie
constraints/compute.setNewProjectDefaultToZonalDNSOnly
auf Organisations- oder Ordnerebene. Eine Anleitung zum Ändern dieser Richtlinie finden Sie unter Zonales DNS standardmäßig für neue Projekte erzwingen.Setzen Sie die Einstellung Legt die interne DNS-Einstellung für neue Projekte so fest, dass nur zonales DNS verwendet wird auf Aus.
Wenn Sie das globale DNS für die gesamte Organisation wiederherstellen möchten, prüfen Sie, ob keiner der Ordner in der Organisation die Organisationsrichtlinie
constraints/compute.setNewProjectDefaultToZonalDNSOnly
erzwingt.Mit den folgenden Abschnitten können Sie prüfen, ob das globale DNS für Projekte, VMs und Container konfiguriert ist.
Fügen Sie den Metadaten des Projekts Folgendes hinzu:
vmDnsSetting=GlobalDefault
.Informationen zum Festlegen von Werten für Projekt- oder VM-Metadaten finden Sie unter Benutzerdefinierte Metadaten festlegen.
Prüfen Sie, dass für keine der VMs im Projekt der Metadatenwert
vmDnsSetting
aufZonalOnly
gesetzt ist.Aktualisieren Sie die DHCP-Freigabe für jede VM. Dazu können Sie die VM neu starten, auf den Ablauf der Freigabe warten oder einen der folgenden Befehle ausführen:
- Linux-VMs:
sudo dhclient -v -r
- Windows Server-VMs:
ipconfig /renew
- Linux-VMs:
Fügen Sie den Metadaten der VM Folgendes hinzu:
vmDnsSetting=GlobalDefault
.Informationen zum Festlegen von VM-Metadatenwerten finden Sie unter Benutzerdefinierte Metadaten festlegen.
Starten Sie das Netzwerk der VM mit einem der folgenden Befehle neu, um die Änderung der DNS-Konfiguration zu erzwingen:
Für Container-Optimized OS oder Ubuntu:
sudo systemctl restart systemd-networkd
Für CentOS, RedHat EL, Fedora CoreOS oder Rocky Linux:
sudo systemctl restart network
Für Debian:
sudo systemctl restart networking
Für Windows:
ipconfig /renew
Legen Sie die Projektmetadateneinstellung
vmDnsSetting
für die Projekte, zu denen die Container und VMs gehören, aufGlobalDefault
fest.Starten Sie die Container neu, damit die DNS-Einstellungen in den ursprünglichen Zustand zurückgesetzt werden.
- Weitere Informationen zur Beziehung zwischen Organisationen, Ordnern und Projekten finden Sie in der Google Cloud-Ressourcenhierarchie.
- Weitere Informationen zum internen DNS für Compute Engine.
REST
Verwenden Sie die von der gcloud CLI bereitgestellten Anmeldedaten, um die REST API-Beispiele auf dieser Seite in einer lokalen Entwicklungsumgebung zu verwenden.
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init
Weitere Informationen finden Sie unter Für die Verwendung von REST authentifizieren in der Dokumentation zur Google Cloud-Authentifizierung.
Erforderliche Rollen
Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zu gewähren, um die Berechtigungen zu erhalten, die Sie für die Migration zu zonalem DNS benötigen:
Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.
Diese vordefinierten Rollen enthalten die Berechtigungen, die für die Migration zu zonalem DNS erforderlich sind. Erweitern Sie den Abschnitt Erforderliche Berechtigungen, um die erforderlichen Berechtigungen anzuzeigen:
Erforderliche Berechtigungen
Die folgenden Berechtigungen sind für die Migration zu zonalem DNS erforderlich:
Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.
Informationen zu DNS-Namen
Zonale DNS-Namen umfassen den Namen Ihrer VM, die Zone, in der sich Ihre VM befindet, und das Projekt, zu dem die VM gehört. Globale DNS-Namen umfassen nicht die Zone, in der sich die VM befindet.
Wenn Sie eine VM mit einem globalen DNS-Namen aufrufen:
Wenn Sie eine VM mit einem zonalen DNS-Namen aufrufen:
Zonales DNS ist die standardmäßige interne DNS-Auflösungsmethode für Compute Engine für Organisationen, die nach dem 6. September 2018 erstellt wurden. Zonale DNS-Namen in einer Zone funktionieren unabhängig von anderen Zonen, sodass Sie mehr fehlertolerante multiregionale Anwendungen mit verbesserter Verfügbarkeitsmerkmale erstellen können. Für die Verwendung eines zonalen DNS fallen keine Gebühren an. Zonales DNS ist von Cloud DNS getrennt.
Projekte, die vor dem 6. September 2018 erstellt wurden, wurden standardmäßig so konfiguriert, dass globales DNS verwendet wird. Diese Projekte können weiterhin globales DNS verwenden. Google empfiehlt jedoch dringend, dass Organisationen diese Projekte zu zonalem DNS migrieren, um zu verhindern, dass Dienstunterbrechungen in einer anderen Region lokale regionale Ressourcen beeinträchtigen. Die Verwendung des zonalen DNS bietet im Vergleich zum globalen DNS eine höhere Zuverlässigkeit, indem Fehler bei der DNS-Registrierung auf einzelne Zonen isoliert werden. Dadurch werden die Auswirkungen von Einzelpunktausfällen reduziert. Wenn ein Ausfall in Google Cloud auftritt, wird dieser in einer einzelnen Zone isoliert, und die Ressourcen und Kosten werden nicht erheblich beeinträchtigt.
Vom globalen DNS zum zonalen DNS migrieren
Zonales DNS hat das globale DNS als standardmäßigen internen DNS-Typ für alle neuen Organisationen ersetzt, die nach dem 6. September 2018 in Google Cloud eingebunden wurden. Wenn Ihre vorhandenen Projekte noch globales DNS verwenden, empfiehlt Google dringend, diese Projekte auf die Verwendung interner zonaler DNS-Namen umzustellen. Wenn Sie nicht zu zonalem DNS migrieren, können folgende Probleme auftreten:
Ein alternativer Ansatz zur Verbesserung der Zuverlässigkeit Ihrer Arbeitslasten, die globales DNS verwenden, ist die Migration zu privaten Cloud DNS-Zonen. Bei Verwendung von privaten Cloud DNS-Zonen wird die Überprüfung der Eindeutigkeit von Namen für das globale DNS entfernt und Fehler werden isoliert, um die DNS-Namensauflösung zu ermöglichen. Weitere Informationen zu dieser Option finden Sie in der Cloud DNS-Dokumentation. Sie können sich auch an Ihren Cloud Customer Care oder Ihren Account-Management-Ansprechpartner wenden. Informationen dazu, wie Cloud DNS mit zonalen und regionalen Ausfällen umgeht, finden Sie unter Architektur der Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur.
Übersicht über den Migrationsprozess
Der zonale DNS-Migrationsprozess umfasst zwei Ebenen:
Der Vorgang umfasst im Allgemeinen die folgenden Schritte:
Beschränkungen
Version von glibc prüfen
So prüfen Sie die von Ihrer VM verwendete
glibc
-Version:Anzahl der Suchdomains prüfen, wenn Sie glibc 2.25 oder früher verwenden
Schritte des Organization Administrator
Als Organisationsadministrator führen Sie die folgenden Aufgaben aus:
Prüfen, ob Ihre Organisation standardmäßig globales DNS verwendet
Der Standardtyp des internen DNS-Namens für Ihre Organisation wird durch das Datum bestimmt, an dem die Organisation erstellt wurde und ob die Organisationsrichtlinieneinschränkung
constraints/compute.setNewProjectDefaultToZonalDNSOnly
erzwungen wird.Console
gcloud
Verwenden Sie den Befehl
organizations describe
und den Befehlresource-manager org-policies list
, um den Standard-DNS-Typ für eine Organisation zu bestimmen.Ermitteln, welche Projekte in einem Ordner oder einer Organisation das globale DNS verwenden
Um zu ermitteln, wie viele Projekte globales DNS verwenden, empfehlen wir, mithilfe von BigQuery eine Tabelle zu erstellen, in der die relativen Projekte für Ihre Organisation und deren Metadaten aufgelistet sind. Anschließend können Sie mit dieser Tabelle eine Abfrage ausführen, die die Gesamtzahl der Projekte mit globalem DNS bereitstellt.
Ermitteln, ob ein Ordner für die Migration zu zonalem DNS bereit ist
In diesem Schritt werden ein
bash
-Script und die im vorherigen Abschnitt erstellte BigQuery-Tabelle verwendet, um die Migrationsbereitschaft des Ordners zu ermitteln.Gehen Sie folgendermaßen vor:
#!/bin/bash inaccessible_projects=() unready_projects=() for project in $(cat ~/FILENAME | tr '\n' ' '); do echo -e "Checking project $project..." ERROR=`curl -s --request POST "https://monitoring.googleapis.com/v3/projects/$project/timeSeries:query" -H "Authorization: Bearer $(gcloud auth print-access-token)" -H "Accept: application/json" -H "Content-Type: application/json" --data '{"query":"fetch compute.googleapis.com/Location | metric '"'"'compute.googleapis.com/global_dns/request_count'"'"' | filter metric.zonal_dns_readiness = '"'"'zonal_dns_risky'"'"' | every 30d | within 30d"}' --compressed | jq --raw-output '.error'` if ! [[ "$ERROR" -eq "null" ]]; then inaccessible_projects+=($project) continue fi QUERY_COUNT=`curl -s --request POST "https://monitoring.googleapis.com/v3/projects/$project/timeSeries:query" -H "Authorization: Bearer $(gcloud auth print-access-token)" -H "Accept: application/json" -H "Content-Type: application/json" --data '{"query":"fetch compute.googleapis.com/Location | metric '"'"'compute.googleapis.com/global_dns/request_count'"'"' | filter metric.zonal_dns_readiness = '"'"'zonal_dns_risky'"'"' | every 30d | within 30d"}' --compressed | jq --raw-output '.timeSeriesData[0].pointData[0].values[0].int64Value'` if [[ "$QUERY_COUNT" -ne "null" ]] && [[ "$QUERY_COUNT" -ne "0" ]]; then unready_projects+=($project) fi done error_len=${#inaccessible_projects[@]} unready_len=${#unready_projects[@]} echo -e "$error_len projects were inaccessible" echo -e "$unready_len projects were not ready for migration" if [ $error_len -ne 0 ]; then echo "Unable to access the following projects:" for project in "${inaccessible_projects[@]}"; do echo "$project" done fi if [ $unready_len -ne 0 ]; then echo "The following projects are not ready for migration:" for project in "${unready_projects[@]}"; do echo "$project" done fi if (( $error_len + $unready_len > 0 )); then echo "This folder is NOT ready for gDNS -> zDNS migration." else echo "This folder is ready for gDNS -> zDNS migration." fi
Ersetzen Sie FILENAME durch den Namen der Datei, in der Sie die Projekt-ID-Liste gespeichert haben.
Teilen Sie die Ergebnisse der Migrationsbereitschaftsanalyse mit den Projektinhabern:
Zonales DNS für neue Projekte standardmäßig erzwingen
Wenn ein neues Projekt in einer Organisation erstellt wird, die vor dem 6. September 2018 erstellt wurde, ist der vom Projekt verwendete interne DNS-Typ standardmäßig globales DNS. Sie können die Organisationsrichtlinie
constraints/compute.setNewProjectDefaultToZonalDNSOnly
auf Organisations- oder Ordnerebene erzwingen, um Fehler bei der DNS-Registrierung in einzelne Zonen zu isolieren.Wenn Sie eine Organisationsrichtlinie festlegen, die den standardmäßigen internen DNS-Typ überschreibt, verwenden neu erstellte Projekte standardmäßig zonales DNS. Die Organisationsrichtlinie wirkt sich nicht auf vorhandene Projekte aus, in denen die Compute Engine API bereits aktiviert ist. Informationen zum Umstellen vorhandener Projekte auf die Verwendung des zonalen DNS finden Sie unter Vorhandene Projekte auf zonales DNS umstellen.
Wenn Sie diese Richtlinienänderung erzwingen möchten, benötigen Sie Zugriff auf Ordner- oder Organisationsebene mit der IAM-Rolle roles/orgpolicy.policyAdmin.
Gehen Sie so vor, um die Organisationsrichtlinie für einen Ordner oder eine Organisation festzulegen:
Wenn Sie die Änderung der Organisationsrichtlinie validieren möchten, können Sie ein neues Projekt in dem Ordner oder der Organisation erstellen, dann eine VM-Instanz erstellen und starten sowie prüfen, ob Ihre VM für zonales DNS aktiviert ist.
Wenn das interne globale DNS erforderlich ist, um eine in Ihrer Arbeitslast integrierte DNS-Namensabfrage aufzulösen, können Sie diese Änderung auf Organisations- oder Ordnerebene rückgängig machen, indem Sie die Erzwingung deaktivieren.
Ausgenommene Ordner sind nicht für die Migration zu zonalem DNS bereit
Wenn es in einer Organisation nur einige wenige Ordner gibt, die noch nicht bereit für die Migration auf zonales DNS sind, empfehlen wir, eine Organisationsrichtlinie auf Organisationsebene festzulegen, aber eine Ausnahme für Ordner zu gewähren, die noch nicht bereit für die Migration sind.
Das folgende Beispiel zeigt eine Organisationshierarchie, in der nur ein Ordner nicht zu einem zonalen DNS migriert werden kann.
organization/Example.com
Führen Sie die folgenden Schritte aus, um einen Ordner von der Organisationsrichtlinie auszuschließen und die Erzwingungsoption für die Richtlinie auf Ordnerebene auf
Off
festzulegen.Weitere Informationen zum Anpassen von Einschränkungen für Organisationsrichtlinien finden Sie in der Resource Manager-Dokumentation unter Richtlinien für boolesche Einschränkungen anpassen.
Schritte des Project Owner
Als Projektinhaber führen Sie während der Migration vom globalen DNS zum zonalen DNS die folgenden Aufgaben aus:
Projektinhaber können auch diese optionalen Aufgaben ausführen:
Prüfen, ob Ihr Projekt standardmäßig globales DNS verwendet
Prüfen Sie in Ihren Projekten, ob sie von globalem DNS zu zonalem DNS migrieren müssen. Sie müssen nur Projekte migrieren, die so konfiguriert sind, dass sie globales DNS als Standard für alle internen DNS-Namen verwenden, die innerhalb des Projekts erstellt werden.
Console
gcloud
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
REST
Prüfen Sie den Wert von
vmDnsSetting
mit der Methodeprojects.get
. In diesem Beispiel werden mithilfe eines Abfrageparametersfields
nur die Felder eingeschlossen, die Sie aufrufen möchten.GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID?fields=id,name,vmDnsSetting
Ersetzen Sie PROJECT_ID durch die Projekt-ID.
Der Wert von
vmDnsSetting
gibt an, ob das Projekt standardmäßig globales DNS verwendet.Ermitteln, ob Ihr Projekt zur Migration bereit ist
Wenn Ihr Projekt in der Google Cloud Console auf der Seite VM-Instanzen zu zonalem DNS migriert werden muss, sollten Sie ein Benachrichtigungsbanner zur zonalen DNS-Migration sehen.
Wenn Sie die Seite VM-Instanzen für Ihr Projekt aufrufen und Ihr Projekt für die Migration bereit ist (mit zonalem DNS kompatibel), enthält das Banner eine Empfehlung zur Verwendung von zonalem DNS Diese Empfehlung basiert auf der internen DNS-Nutzung im Projekt, ist jedoch auf die letzten 100 Tage beschränkt.
Wenn Ihr Projekt nicht für die Migration zu zonalem DNS bereit ist, wird ein anderes Banner angezeigt.
Klicken Sie auf die Schaltfläche Globale DNS-Nutzung aufrufen, um die globale DNS-Nutzung aufzurufen. Sie werden zur Seite Log-Explorer in der Google Cloud Console weitergeleitet. Auf dieser Seite können Sie die Abfragelogs der letzten 30 Tage zur Migrationsblockierung einsehen. Wenn Sie auf den Link im Banner klicken, wird die Seite Log-Explorer so konfiguriert, dass sie den Filter logName verwendet, um globale DNS-Abfragen und relative Logfelder abzurufen.
So rufen Sie diese Informationen auf, ohne die Schaltfläche im Banner zu verwenden:
Alternativ können Sie Folgendes in das Abfragefeld eingeben:
resource.type="gce-instance" log_name="projects/PROJECT_ID/logs/compute.googleapis.com%2Fgdnsusage"
Globale DNS-Nutzung im Projekt verfolgen
Es gibt zwei Messwerte, mit denen die Bereitschaft des Projekts zur Migration zu zonalem DNS verfolgt wird:
Das von diesen Messwerten verwendete Zeitintervall ist 100 Tage.
Verwenden Sie den Metrics Explorer in der Google Cloud Console, um diese Messwerte anzuzeigen.
Projekte migrieren, die zu zonalem DNS bereit sind
Die Migration können Sie im Allgemeinen so vornehmen:
Projekte und VMs manuell zur Verwendung von zonalem DNS aktualisieren
Nachdem Sie festgestellt haben, dass Ihr Projekt zu zonalem DNS migriert werden kann, können Sie das Projekt und die VMs so konfigurieren, dass nur zonale DNS-Namen verwendet werden. Aktualisieren Sie dazu die Metadaten. Aktivieren Sie das zonale DNS für Ihre VMs. Legen Sie dazu den Metadateneintrag
vmDnsSetting
für das Projekt oder die VM fest. Wenn Sie den MetadateneintragvmDnsSetting
für eine bestimmte VM festlegen, wird jedevmDnsSetting
-Einstellung, die aus den Projektmetadaten für diese VM übernommen wurde, überschrieben.Die Variable
vmDnsSetting
unterstützt die folgenden Einstellungen:Informationen zum Festlegen von Werten für Projekt- oder MV-Metadaten finden Sie unter Benutzerdefinierte Metadaten festlegen.
Nachdem Sie den Metadateneintrag
vmDnsSetting
für eine VM konfiguriert haben, aktualisieren Sie die DHCP-Freigabe für die VM. Dazu können Sie die VM neu starten, auf den Ablauf der Freigabe warten oder einen der folgenden Befehle ausführen:Prüfen Sie nach dem Aktualisieren der DHCP-Freigabe, ob die VM für das zonale DNS aktiviert ist.
Projekte ändern, die nicht migriert werden können
Ein Projekt, das nicht migriert werden kann, bedeutet, dass innerhalb eines bestimmten Zeitraums, z. B. in den letzten 30 oder 100 Tagen, mindestens eine riskante DNS-Abfrage gestellt wurde. Eine riskante Abfrage ist ein Aufruf einer VM mit einem globalen DNS-Namen (
VM_NAME.c.PROJECT_ID.internal
), der nicht nahtlos mit einem zonalen DNS-Namen (VM_NAME.ZONE.c.PROJECT_ID.internal
) aufgelöst werden kann. Riskante Abfragen können die folgenden Attribute haben:Bei Projekten mit riskanten Abfragen ist in der Regel ein gewisser Mehraufwand erforderlich, um vor der Migration alle riskanten DNS-Lookups zu entfernen.
Führen Sie für Projekte, die noch nicht für die Migration bereit sind, die folgenden Schritte aus:
Funktion zur Verbesserung des Suchpfads
Standardmäßig speichern die meisten Linux-Distributionen DHCP-Informationen in
resolv.conf
. Hier ein einfaches globalesresolv.conf file
:domain c.PROJECT_ID.internal search c.PROJECT_ID.internal. google.internal. nameserver 169.254.169.254
Mit der Konfigurationsoption
search
werden die Hostnamen aufgelistet, die für die DNS-Auflösung verwendet werden sollen. Der DNS-Server versucht, die Abfrage mit jedem der Hostnamen im Suchpfad aufzulösen, bis eine DNS-Datensatzübereinstimmung gefunden wird. Wenn eine VM beispielsweiseping my-vm
aufruft, werden die Domains im Suchpfad an die ursprüngliche Abfrage angehängt, um die vollqualifizierten Domainnamen (FQDN) abzurufen. Beispiel:my-vm.c.PROJECT_ID.internal
. “ Wenn es eine Übereinstimmung gibt, gibt der DNS-Resolver in der Antwort eine interne IP-Adresse zurück. Andernfalls wird versucht, den DNS-Namen mithilfe der nächsten Domain im Suchpfad aufzulösen.Das Hinzufügen zusätzlicher zonaler Domains im VM-Suchpfad kann einige Projekte für die Migration vorbereiten. Angenommen, Ihre VM befindet sich in der Zone
us-west4-c
. Diese VM ruft eine andere VM namensmyapp-vm
auf, die sich in der Zoneus-west4-b
befindet.Google bietet eine Funktion zur Optimierung des Suchpfads, die in allen Zonen in derselben Region wie die VM automatisch nach dem zonalen DNS-Namen für eine VM sucht. Daher können zonale Abfragen aufgelöst werden, ohne dass eine Aktualisierung der Datei
resolv.conf
oder Ihrer DHCP-Richtlinie erforderlich ist. Mit Verbesserungen des Suchpfads können regionenübergreifende Abfragen in bis zu 80% der Zeit behoben werden. Dieses Feature sollte dazu beitragen, dass die meisten Projekte mit riskanten Abfragen für die Migration zu zonalem DNS bereit sind.Verbesserung des Suchpfads aktivieren, um zonale DNS-Namenssuchen aufzulösen
Führen Sie die folgenden Schritte aus, um die Funktion zur Optimierung des Suchpfads zu aktivieren.
Abfragen manuell aktualisieren, um zonale DNS-Namen zu verwenden
Wenn Sie mithilfe der Funktion zur Verbesserung des Suchpfads zusätzliche zonale Domains im DNS-Namenssuchpfad hinzufügen, werden nicht alle Ihre zonenübergreifenden Abfragen umgestellt. In diesem Fall können Sie mit dem Log-Explorer die globale DNS-Nutzung innerhalb des Projekts aufrufen.
Führen Sie die folgenden Schritte aus, um die globalen DNS-Abfragen zu ermitteln, die manuell geändert werden müssen, um stattdessen zonale voll qualifizierte Domainnamen (FQDN) zu verwenden:
Nachdem Sie die globalen DNS-Abfragen für die Verwendung des zonalen DNS aktualisiert haben:
Prüfen, ob die Projektmigration zu zonalem DNS abgeschlossen ist
Auf globales DNS zurücksetzen
Sie können die Migration zum zonalen DNS rückgängig machen, indem Sie den standardmäßigen internen DNS-Typ wieder in ein globales DNS ändern. Dies kann auf Organisations-, Projekt-, VM- oder Containerebene erfolgen.
Zur Verwendung von globalem DNS für eine Organisation oder einen Ordner zurückkehren
Führen Sie die folgenden Schritte aus, um eine Organisation oder einen Ordner auf das globale DNS zurückzusetzen.
Zur Verwendung des globalen DNS für ein Projekt zurückkehren
Führen Sie die folgenden Schritte aus, um ein Projekt auf das globale DNS zurückzusetzen.
Zur Verwendung des globalen DNS für eine VM zurückkehren
Führen Sie die folgenden Schritte aus, um eine bestimmte VM auf das globale DNS zurückzusetzen.
Zur Verwendung eines globalen DNS für einen Container zurückkehren
Wenn Sie Ihre Anwendung in Containern, in Google Kubernetes Engine oder in einer flexiblen App Engine-Umgebung ausführen, wird die DNS-Konfiguration in den Containereinstellungen möglicherweise erst automatisch aktualisiert, nachdem Sie die Container neu gestartet haben. Führen Sie die folgenden Schritte aus, um das zonale DNS für diese Containeranwendungen zu deaktivieren.
Fehlerbehebung bei der Migration vom globalen DNS zum zonalen DNS
Informationen zu Problemen mit dem Migrationsprozess finden Sie im Leitfaden zur Fehlerbehebung.
Migrationsbanner für zonale DNS in der Google Cloud Console ausblenden
Sie können im zonalen DNS-Migrationsbenachrichtigungsbanner, das auf der Seite VM-Instanzen der Google Cloud Console angezeigt wird, auf die Schaltfläche Schließen klicken. Dadurch wird verhindert, dass das Banner für das Projekt unbegrenzt angezeigt wird.
Wenn Sie das Banner geschlossen haben, es aber wieder angezeigt werden soll, wenden Sie sich an Cloud Customer Care.
Nächste Schritte
Sofern nicht anders angegeben, sind die Inhalte dieser Seite unter der Creative Commons Attribution 4.0 License und Codebeispiele unter der Apache 2.0 License lizenziert. Weitere Informationen finden Sie in den Websiterichtlinien von Google Developers. Java ist eine eingetragene Marke von Oracle und/oder seinen Partnern.
Zuletzt aktualisiert: 2024-08-21 (UTC).
[{ "type": "thumb-down", "id": "hardToUnderstand", "label":"Hard to understand" },{ "type": "thumb-down", "id": "incorrectInformationOrSampleCode", "label":"Incorrect information or sample code" },{ "type": "thumb-down", "id": "missingTheInformationSamplesINeed", "label":"Missing the information/samples I need" },{ "type": "thumb-down", "id": "translationIssue", "label":"Problem mit der Übersetzung" },{ "type": "thumb-down", "id": "otherDown", "label":"Sonstiges" }] [{ "type": "thumb-up", "id": "easyToUnderstand", "label":"Leicht verständlich" },{ "type": "thumb-up", "id": "solvedMyProblem", "label":"Mein Problem wurde gelöst" },{ "type": "thumb-up", "id": "otherUp", "label":"Sonstiges" }] -