Zonales DNS für den internen DNS-Typ verwenden

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.

    Wählen Sie den Tab für die Verwendung der Beispiele auf dieser Seite aus:

    Console

    Wenn Sie über die Google Cloud Console auf Google Cloud-Dienste und -APIs zugreifen, müssen Sie die Authentifizierung nicht einrichten.

    gcloud

    1. Installieren Sie die Google Cloud CLI und initialisieren Sie sie mit folgendem Befehl: 

      gcloud init
    2. Legen Sie eine Standardregion und -zone fest.

    REST

    Verwenden Sie die von der gcloud CLI bereitgestellten Anmeldedaten, um die REST API-Beispiele auf dieser Seite in einer lokalen Entwicklungsumgebung zu verwenden.

      Installieren Sie die Google Cloud CLI und initialisieren Sie sie mit folgendem Befehl: 

      gcloud init

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:

  • 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

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:

  • 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

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:

  • 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.

Wenn Sie eine VM mit einem zonalen DNS-Namen aufrufen:

  • 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ür zone1 eindeutig sein. Im Gegensatz zu globalen DNS-Namen ist my-vm.zone2.google.com jedoch auch ein gültiger DNS-Name, wenn zonales DNS verwendet wird.

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:

  • 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).

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:

  • 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.

Die Abbildung zeigt ein Flussdiagramm der Schritte zur Migration zu einem zonalen DNS.

Der Vorgang umfasst im Allgemeinen die folgenden Schritte:

  1. Prüfen Sie, ob der Ordner oder die Organisation für die Migration zu zonalem DNS bereit ist.
  2. Wenn der Ordner oder die Organisation für die Migration zum zonalen DNS bereit ist:
    1. Der Organisationsadministrator legt eine Organisationsrichtlinie für den Ordner oder die Organisation fest, um die zukünftige Verwendung des globalen DNS zu verhindern.
    2. Projektinhaber migrieren ihre Projekte zur Verwendung des zonalen DNS.
  3. Wenn der Ordner oder die Organisation nicht für die Migration zu zonalem DNS bereit ist:
    1. Projektinhaber migrieren einsatzbereite Projekte zu zonalem DNS.
    2. Projektinhaber untersuchen die globale DNS-Nutzung in Projekten, die nicht bereit sind.
    3. Projektinhaber wenden Verbesserungen des Suchpfads oder andere Änderungen an, um das Projekt für die Migration zu zonalem DNS vorzubereiten.
    4. Der Organisationsadministrator prüft den Status des Ordners oder der Bereitschaft der Organisation für die zonale DNS-Migration noch einmal.

Beschränkungen

  • 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 mit glibc Version 2.26 oder höher ausgeführt wird. DHCP-Clients mit glibc 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 von glibc 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.

Version von glibc prüfen

So prüfen Sie die von Ihrer VM verwendete glibc-Version:

  1. Stellen Sie eine Verbindung zu Ihrer Linux-VM her.
  2. Führen Sie ldd --version aus, um die Version glibc abzurufen.

Anzahl der Suchdomains prüfen, wenn Sie glibc 2.25 oder früher verwenden

  1. Stellen Sie eine Verbindung zu Ihrer Linux-VM her.

  2. 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.

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

  1. Gehen Sie zu IAM und Verwaltung> Identität und Organisation in der Console.

    Zu „Identität und Organisation“

  2. Prüfen Sie das Registrierungsdatum der Organisation.

    Ein Screenshot der Seite „Identität und Organisation“ mit dem Datum der Registrierung

    • 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.

  3. 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.

    1. Wechseln Sie in der Google Cloud Console zur Seite IAM & Verwaltung> Organisationsrichtlinien.
    2. Geben Sie im Filter constraints/compute.setNewProjectDefaultToZonalDNSOnly ein:
    3. 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.
    4. 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.
    5. 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.

gcloud

Verwenden Sie den Befehl organizations describe und den Befehl resource-manager org-policies list, um den Standard-DNS-Typ für eine Organisation zu bestimmen.

  1. 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.

  2. 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.

    1. 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.
    2. 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.

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.

  1. Erstellen Sie ein BigQuery-Dataset.

  2. Exportieren Sie die Asset-Metadaten für Ihre Organisation in eine BigQuery-Tabelle.

    1. Prüfen Sie, ob die Cloud Asset Inventory API aktiviert ist.
    2. Konfigurieren Sie die Berechtigungen, die für die Verwendung der Cloud Asset Inventory API erforderlich sind.

    3. 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.

  3. Rufen Sie in der Google Cloud Console die Seite BigQuery auf.

  4. Wählen Sie Neue Abfrage erstellen aus.

  5. 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ür vmDnsSetting haben ein zonales DNS. Andernfalls wird für die Projekte globales DNS verwendet.

  6. 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

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.

  • 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.

Gehen Sie folgendermaßen vor:

  1. Rufen Sie die Ordner-ID ab. Wenn Sie die Ordner-ID nicht kennen:
    1. Rufen Sie in der Google Cloud Console die Seite Verwaltete Ressourcen auf.
    2. Wenden Sie den Filter Name:FOLDER_NAME an, um die Ordner-ID abzurufen.

  2. 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

  3. Kopieren Sie die Projekt-ID-Liste und speichern Sie sie in einer Datei.

  4. 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.

#!/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:

  1. Melden Sie sich in der Google Cloud Console als Super Admin für Google Workspace oder Cloud Identity an.

  2. Wechseln Sie in der Konsole zur Seite Organisationsrichtlinien.

    Zu den Organisationsrichtlinien

  3. 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.

  4. 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.

  5. 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.

  6. Klicken Sie auf Bearbeiten, um die Organisationsrichtlinie anzupassen.

  7. Wählen Sie auf der Bearbeitungsseite Anpassen aus.

  8. 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.

  9. Klicken Sie auf Speichern.

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

  • 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)

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.

  1. Melden Sie sich in der Google Cloud Console als Super Admin für Google Workspace oder Cloud Identity an.

  2. Wechseln Sie in der Konsole zur Seite Organisationsrichtlinien.

    Zu den Organisationsrichtlinien

  3. 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.

  4. So ermitteln Sie die Einschränkung der Organisationsrichtlinie für das zonale DNS:

    1. Klicken Sie auf Filtern.
    2. Name auswählen.
    3. Legen Sie den Filternamen auf Legt die interne DNS-Einstellung für neue Projekte so fest, dass nur zonales DNS angezeigt wird.

  5. Klicken Sie auf den Namen der Organisationsrichtlinieneinschränkung, um die Seite Richtliniendetails zu öffnen.

  6. Klicken Sie auf Bearbeiten.

  7. Wählen Sie auf der Seite Bearbeiten die Option Anpassen aus.

  8. 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.

  9. Klicken Sie auf Speichern.

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

  1. Rufen Sie in der Google Cloud Console die Seite Metadaten auf.

    Zur Seite "Metadaten"

  2. 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.

gcloud

    Aktivieren Sie Cloud Shell in der Google Cloud Console.

    Cloud Shell aktivieren

    Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.

  1. 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.

REST

Prüfen Sie den Wert von vmDnsSetting mit der Methode projects.get. In diesem Beispiel werden mithilfe eines Abfrageparameters fields 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.

  • 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.

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.

Screenshot der Migration zu zonalem DNS-Banner in der Console

Wenn Ihr Projekt nicht für die Migration zu zonalem DNS bereit ist, wird ein anderes Banner angezeigt.

Screenshot der Migration für das zonale DNS-Banner in der Console

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:

  1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.

    Zum Log-Explorer

  2. Wählen Sie das Projekt aus.

  3. Wenden Sie die Ressourcen- und Lognamenfilter an:

    1. Klicken Sie auf Ressource.
    2. Wählen Sie im Dialogfeld Ressource auswählen die Option VM-Instanz aus und klicken Sie dann auf Übernehmen.
    3. Klicken Sie auf Logname.
    4. Wählen Sie im Dialogfeld Lognamen auswählen die Option gdnsusage aus und klicken Sie auf Übernehmen.

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:

  • 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.

Das von diesen Messwerten verwendete Zeitintervall ist 100 Tage.

Verwenden Sie den Metrics Explorer in der Google Cloud Console, um diese Messwerte anzuzeigen.

  1. Wählen Sie im Navigationsbereich der Google Cloud Console Monitoring und anschließend  Metrics Explorer aus:

    Zum Metrics explorer

  2. Klicken Sie auf der rechten Seite der Symbolleiste, die das Feld Messwert auswählen enthält, auf Code-Editor, MQL oder PromQL.

  3. 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.

  4. 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

  5. Klicken Sie auf Abfrage ausführen.

    Die Google Cloud Console zeigt ein Diagramm der beiden Messwerte (zonal_dns_ready und zonal_dns_risky) und die entsprechende Anzahl von Abfragen im Zeitverlauf für jeden Messwert an.

    Screenshot des Diagramms für globale DNS-Nutzungsmesswerte

  6. 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.

Projekte migrieren, die zu zonalem DNS bereit sind

Die Migration können Sie im Allgemeinen so vornehmen:

  1. Ü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.

  2. 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.

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 Metadateneintrag vmDnsSetting für eine bestimmte VM festlegen, wird jede vmDnsSetting-Einstellung, die aus den Projektmetadaten für diese VM übernommen wurde, überschrieben.

Die Variable vmDnsSetting unterstützt die folgenden Einstellungen:

  • 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, die ZONE nicht als Teil des internen DNS-Namens enthalten, funktionieren nicht mehr. Andere VMs können VMs mit vmDnsSetting, die auf ZonalOnly 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.

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:

  • Linux-VMs: sudo dhclient -v -r
  • Windows Server-VMs: ipconfig /renew

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:

  • VM in einem anderen Projekt aufrufen
  • VM in einer anderen Zone aufrufen

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:

  1. 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.
  2. 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.

Funktion zur Verbesserung des Suchpfads

Standardmäßig speichern die meisten Linux-Distributionen DHCP-Informationen in resolv.conf. Hier ein einfaches globales resolv.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 beispielsweise ping 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 namens myapp-vm auf, die sich in der Zone us-west4-b befindet.

  • 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-Name myapp-vm aufgelöst werden, wenn us-west4-b.c.PROJECT_ID.internal an den VM-Namen angehängt wird.

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.

  1. Führen Sie den Befehl project-info add-metadata so aus:

    gcloud compute project-info add-metadata  \
    --metadata=enable-search-path-improvement=true

  2. 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.

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:

  1. 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.

  2. Im Bereich Abfrageergebnisse enthält jede Abfrage das Feld jsonPayload. Jedes jsonPayload-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.

    Screenshot der jsonPayload in den Ergebnissen der Log-Abfrage von gdnsusage

  3. 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.

Nachdem Sie die globalen DNS-Abfragen für die Verwendung des zonalen DNS aktualisiert haben:

  1. 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.
  2. Prüfen Sie den Monitoringmesswert noch einmal, um festzustellen, ob alle riskanten DNS-Abfragen entfernt wurden.

Prüfen, ob die Projektmigration zu zonalem DNS abgeschlossen ist

  1. Wiederholen Sie die Schritte unter Prüfen, ob Ihr Projekt standardmäßig globales DNS verwendet.

  2. 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.

  3. Prüfen Sie, ob der interne DNS-Name für eine VM einen zonalen DNS-Namen verwendet.

  4. So prüfen Sie, ob die Organisationsrichtlinie constraints/compute.setNewProjectDefaultToZonalDNSOnly erzwungen wird:

    1. Erstellen Sie ein neues Projekt in dem Ordner oder der Organisation.
    2. VM-Instanz erstellen und starten
    3. Prüfen Sie, ob die VM einen zonalen DNS-Namen verwendet.

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.

  1. 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.

  2. 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.

  3. Mit den folgenden Abschnitten können Sie prüfen, ob das globale DNS für Projekte, VMs und Container konfiguriert ist.

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.

  1. 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.

  2. Prüfen Sie, dass für keine der VMs im Projekt der Metadatenwert vmDnsSetting auf ZonalOnly gesetzt ist.

  3. 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

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.

  1. Fügen Sie den Metadaten der VM Folgendes hinzu: vmDnsSetting=GlobalDefault.

    Informationen zum Festlegen von VM-Metadatenwerten finden Sie unter Benutzerdefinierte Metadaten festlegen.

  2. 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

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.

  1. Legen Sie die Projektmetadateneinstellung vmDnsSetting für die Projekte, zu denen die Container und VMs gehören, auf GlobalDefault fest.

  2. Starten Sie die Container neu, damit die DNS-Einstellungen in den ursprünglichen Zustand zurückgesetzt werden.

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