Zonales DNS als internen DNS-Typ verwenden

Zonales DNS verringert das Risiko regionsübergreifender Ausfälle und verbessert die Zuverlässigkeit Ihrer Projekte in der Compute Engine insgesamt. Die Verwendung von zonalem DNS reduziert die Auswirkungen von Single-Point-Ausfällen, 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 bei Compute Engine authentifizieren. Wählen Sie dazu eine der folgenden Optionen aus:

    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

    1. Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init
    2. Set a default region and zone.

      3. 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 zuzuweisen, um die Berechtigungen zu erhalten, die Sie zur 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, 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 auf Projekte, Ordner und Organisationen 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:

  • Legen Sie eine Einschränkung für die Organisationsrichtlinie fest: orgpolicy.*
  • Ermitteln, ob ein Ordner für die Migration zu zonalem DNS bereit ist:
    • resourcemanager.folders.get
    • resourcemanager.folders.list
    • resourcemanager.organizations.get
    • resourcemanager.projects.get
    • resourcemanager.projects.list
  • Prüfen Sie, ob globale DNS-Namen und VM-Metadaten vorhanden sind: 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.

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 über einen globalen DNS-Namen aufrufen, gilt Folgendes:

  • 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 der VM mit allen anderen globalen DNS-Namen verglichen werden, die im selben Projekt registriert sind, um DNS-Namenskonflikte zu vermeiden.

Wenn Sie eine VM über einen zonalen DNS-Namen aufrufen, gilt Folgendes:

  • Der Name wird innerhalb einer Zone aufgelöst.
  • Zonen-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 bei der Verwendung von zonalem DNS.

Zonales DNS ist die standardmäßige interne DNS-Auflösungsmethode für die 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ügbarkeit erstellen können. Für die Verwendung von zonalem DNS fallen keine Gebühren an. Zonales DNS ist unabhängig von Cloud DNS.

Projekte, die vor dem 6. September 2018 erstellt wurden, wurden so konfiguriert, dass sie standardmäßig globales DNS verwenden. Für diese Projekte kann weiterhin globales DNS verwendet werden. Google empfiehlt jedoch dringend, diese Projekte auf zonales DNS umzustellen, damit Dienstausfälle in einer anderen Region nicht zu Problemen mit lokalen regionalen Ressourcen führen. Die Verwendung von zonalem DNS bietet im Vergleich zum globalen DNS eine höhere Zuverlässigkeit, da Fehler bei der DNS-Registrierung auf einzelne Zonen isoliert werden. So werden die Auswirkungen von Ausfällen einzelner Komponenten reduziert. Wenn ein Ausfall in Google Cloud auftritt, ist er auf eine einzelne Zone beschränkt und Ressourcen und Kosten sind nicht wesentlich betroffen.

Von globalem DNS zu zonalem 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 zonaler DNS-Namen umzustellen. Wenn Sie nicht zu zonalem DNS migrieren, kann es zu den folgenden Problemen kommen:

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

Eine alternative Möglichkeit, die Zuverlässigkeit Ihrer Arbeitslasten zu verbessern, die globales DNS verwenden, ist die Migration zu privaten Cloud DNS-Zonen. Wenn Sie private Cloud DNS-Zonen verwenden, wird die vom globalen DNS erforderliche Überprüfung der Namenseindeutigkeit aufgehoben und Fehler werden isoliert, um die DNS-Namensauflösung zu ermöglichen. Weitere Informationen zu dieser Option finden Sie in der Cloud DNS-Dokumentation oder wenden Sie sich an den Cloud Customer Care oder Ihren Kundenbetreuer. Informationen dazu, wie Cloud DNS zonale und regionale Ausfälle handhabt, finden Sie unter Architektonische Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur.

Übersicht über den Migrationsprozess

Der Migrationsprozess für zonales DNS umfasst zwei Ebenen:

  • Organisations- oder Ordnerebene: Hier können Sie prüfen, ob ein Ordner oder eine Organisation für die Migration zu zonalem DNS bereit ist. Verhindern, dass neue Projekte globales DNS verwenden Wird vom Administrator der Organisation ausgeführt.
  • Projektebene: Sie können ein einzelnes Projekt vom globalen DNS zum zonalen DNS migrieren. Wird in der Regel vom Projektinhaber durchgeführt.

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

Im Allgemeinen umfasst der Prozess 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 zu zonalem DNS bereit ist:
    1. Der Administrator der Organisation legt eine Organisationsrichtlinie für den Ordner oder die Organisation fest, um die zukünftige Verwendung von globalem DNS zu verhindern.
    2. Projektinhaber migrieren ihre Projekte auf zonales DNS.
  3. Wenn der Ordner oder die Organisation nicht für die Migration zu zonalem DNS bereit ist:
    1. Projektinhaber migrieren fertige Projekte zu zonalem DNS.
    2. Projektinhaber prüfen die Verwendung des globalen DNS in Projekten, die noch nicht bereit sind.
    3. Projektinhaber wenden Suchpfadverbesserungen oder andere Änderungen an, damit das Projekt zu einem zonalen DNS migriert werden kann.
    4. Der Administrator der Organisation prüft noch einmal den Status der Ordner- oder Organisationsbereitschaft für die Migration zu zonalem DNS.

Beschränkungen

  • Zonales DNS ist kein vollständiger Ersatz für globales DNS. Es gibt einige Abfragetypen (zonenübergreifend), die möglicherweise nicht vom zonalen DNS mit automatischer Suche nach dem 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 vom globalen DNS zum zonalen DNS wird eine neue Domain (ZONE.c.PROJECT_ID.internal) in den Suchpfad aufgenommen. 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 niedriger unterstützen nur bis zu sechs Suchdomains. Es besteht also das Risiko, dass eine vorhandene Suchdomain verworfen wird. Dieses Limit gilt nicht für VMs mit:

    • Windows-Images
    • Container-Optimized OS-Images
    • Images von Debian 10 oder höher
    • Fedora CoreOS (Version 27 oder höher)
    • Images von RHEL 8 oder höher
    • Images von 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 bereits bei der vorherigen Einschränkung erwähnt, werden vorhandene Domains im Suchpfad möglicherweise entfernt, wenn die Domainbeschränkung des Suchpfads bei Verwendung von glibc Version 2.25 oder niedriger überschritten wird.

  • Wenn Sie die Verbesserungen des Suchpfads mit der Google Kubernetes Engine verwenden möchten, benötigen Sie die Google Kubernetes Engine-Version 1.26 oder höher.

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 zu erhalten.

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 Datum der Registrierung 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 sie 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. Rufen Sie in der Google Cloud -Konsole die Seite IAM & Verwaltung> Organisationsrichtlinien auf.
    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 zonales DNS der Standard-interne DNS-Typ für alle neuen Projekte, die in der Organisation erstellt werden.
      • Andernfalls wird der Standard-DNS-Typ des Projekts 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 die Erstellungszeit 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 ermitteln.

  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 sie standardmäßig globales DNS und sollte zu zonalem DNS migriert werden.

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

    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 zonales DNS der Standard-interne DNS-Typ für alle neu in der Organisation erstellten Projekte.
    2. Wenn die Einschränkung nicht für die Organisation konfiguriert oder nicht erzwungen wurde, wird der interne DNS-Standardtyp durch die Erstellungszeit der Organisation bestimmt, wie im ersten Schritt beschrieben.

Festlegen, welche Projekte in einem Ordner oder einer Organisation ein globales DNS verwenden.

Wenn Sie herausfinden möchten, wie viele Projekte das globale DNS verwenden, empfehlen wir, in BigQuery eine Tabelle mit den zugehörigen Projekten für Ihre Organisation und ihren Metadaten zu erstellen. Sie können dann mit dieser Tabelle eine Abfrage ausführen, mit der die Gesamtzahl der Projekte ermittelt wird, für die globales DNS verwendet wird.

  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 compute.googleapis.com/Project-Asset 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 derGoogle Cloud -Konsole die Seite BigQuery auf.

  4. Klicken Sie auf Neue Abfrage erstellen.

  5. Geben Sie im Textfeld des Abfrageeditors die folgende GoogleSQL-Abfrage ein und klicken Sie 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.

    Bei Projekten mit dem Wert ZONAL_ONLY für vmDnsSetting ist ein zonales DNS konfiguriert. Andernfalls wird für die Projekte globales DNS verwendet.

  6. Optional: Wenn Sie eine detaillierte Ansicht der 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 in den letzten 30 Tagen keine Abfragen für alle Projekte ausgeführt wurden, 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 weitere Maßnahmen.

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. Stellen Sie eine Abfrage an die BigQuery-Tabelle mit den exportierten compute.Project assets-Daten.

    Eine Anleitung zum Erstellen der BigQuery-Tabelle finden Sie unter Festlegen, welche Projekte in einem Ordner oder einer Organisation ein globales DNS verwenden.

    Geben Sie die folgende GoogleSQL-Abfrage ein und klicken Sie 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 Liste der Projekt-IDs 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 Liste der Projekt-IDs gespeichert haben.

Teilen Sie die Ergebnisse der Migrationsbereitschaftsanalyse mit den Projektinhabern:

Zonales DNS standardmäßig für neue Projekte 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. Um Fehler bei der DNS-Registrierung in einzelne Zonen zu isolieren, können Sie die Organisationsrichtlinie constraints/compute.setNewProjectDefaultToZonalDNSOnly auf Organisations- oder Ordnerebene erzwingen.

Wenn Sie eine Organisationsrichtlinie festlegen, um den Standardtyp für internes DNS zu überschreiben, 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 -Konsole 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 interne DNS-Standardtyp 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, die nicht zu zonalem DNS migriert werden können

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 für die Migration zu zonalem DNS bereit ist.

organization/Example.com

  • folders/101
    • projects/301 (migrationsbereit)
    • folders/201
      • projects/303 (NICHT bereit)
      • projects/304 (migrationsbereit)
  • folders/102
    • projects/302 (migrationsbereit)

Wenn Sie einen Ordner von der Organisationsrichtlinie ausnehmen möchten, führen Sie die folgenden Schritte aus, um die Erzwingungsoption für die Richtlinie auf Ordnerebene auf Off festzulegen.

  1. Melden Sie sich in der Google Cloud -Konsole 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 von der Organisationsrichtlinie ausgenommen werden sollen.

    In der Google Cloud Console wird auf einer oder mehreren Seiten eine Liste der Einschränkungen für Organisationsrichtlinien für diesen Ordner angezeigt.

  4. So ermitteln Sie die Einschränkung der Organisationsrichtlinie, die das zonale DNS erzwingt:

    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 verwendet wird fest.

  5. Klicken Sie auf den Namen der Einschränkung der Organisationsrichtlinie, 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. Das bedeutet, dass der interne DNS-Standardtyp für alle Projekte im Ordner durch die Erstellungszeit 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 von globalem DNS zu zonalem 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 Ihre Projekte, um festzustellen, ob sie von der Verwendung des globalen DNS zu zonalem DNS migriert werden 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. Rufen Sie auf dem Tab Metadaten die Einstellung vmdnssetting auf. Der Wert gibt an, ob für das Projekt standardmäßig globales DNS verwendet wird.

    • GlobalDefault: Im Projekt ist globales DNS aktiviert.
    • ZonalOnly: Im Projekt ist das zonale DNS aktiviert. Dieses Projekt muss nicht migriert werden.

gcloud

    In the Google Cloud console, activate Cloud Shell.

    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.

  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: Im Projekt ist globales DNS aktiviert.
    • ZONAL_ONLY: Im Projekt ist das zonale DNS aktiviert. Dieses Projekt muss nicht migriert werden.

REST

Prüfen Sie den Wert von vmDnsSetting mit der Methode projects.get. In diesem Beispiel wird der Abfrageparameter fields verwendet, um nur die Felder einzubeziehen, die Sie sehen 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: Im Projekt ist globales DNS aktiviert.
  • ZONAL_ONLY: Im Projekt ist das zonale DNS aktiviert. Dieses Projekt muss nicht migriert werden.

Prüfen, ob Ihr Projekt für die Migration bereit ist

Wenn Ihr Projekt in der Google Cloud Console auf der Seite VM-Instanzen zu zonalem DNS migriert werden muss, sollte ein Benachrichtigungsbanner zur zonalen DNS-Migration angezeigt werden.

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 aber auf die letzten 100 Tage beschränkt.

Screenshot des Banners „Bereit für die Migration zu zonalem DNS“ in der Console

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

Screenshot des Banners „Nicht bereit für die Migration zu zonalem DNS“ in der Console

Klicken Sie auf die Schaltfläche Globale DNS-Nutzung ansehen, um sich die globale DNS-Nutzung anzusehen. Daraufhin wird die Seite Log-Explorer in der Google Cloud -Konsole geöffnet. 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 globale DNS-Abfragen und relative Protokollfelder mit dem Filter logName abgerufen werden.

Wenn Sie diese Informationen ohne die Schaltfläche im Banner aufrufen möchten, gehen Sie so vor:

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

    Zum Log-Explorer

  2. Wählen Sie das Projekt aus.

  3. Wenden Sie die Filter für Ressourcen und Lognamen 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 dann 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 Projektbereitschaft für die Migration zu zonalem DNS erfasst wird:

  • zonal_dns_ready: Die Gesamtzahl der Abfragen, die im angegebenen Zeitraum abgeschlossen wurden und mit zonalem DNS anstelle von globalem DNS aufgelöst werden können.
  • zonal_dns_risky: Die Gesamtzahl der Abfragen, die im angegebenen Zeitraum abgeschlossen wurden und nicht mithilfe des zonalen DNS aufgelöst werden können. Bei diesen Abfragen konnte die Compute Engine die relative interne IP-Adresse nicht aus dem aktuellen Hostnamen ermitteln. Wenn dieser Messwert einen Wert ungleich 0 hat, ist das Projekt noch nicht für die Migration bereit.

Für diese Messwerte wird ein Zeitraum von 100 Tagen verwendet.

Sie können diese Messwerte in der Metrics Explorer in der Google Cloud -Konsole aufrufen.

  1. Rufen Sie in der Google Cloud -Konsole die Seite  Metrics Explorer auf:

    Zum Metrics Explorer

    Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

  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 den folgenden Text genau so in das Abfrageeingabefeld 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.

    In der Google Cloud -Konsole wird ein Diagramm mit den beiden Messwerten (zonal_dns_ready und zonal_dns_risky) und der entsprechenden Anzahl von Abfragen angezeigt, die im angegebenen Zeitraum für jeden Messwert ausgeführt wurden.

    Screenshot des Diagramms für Messwerte zur globalen DNS-Nutzung

  6. Prüfen Sie den Wert für den Messwert zonal_dns_risky.

Projekte migrieren, die für zonales 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 sie, um zonale DNS-Namen zu verwenden.
    • 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 freigegebene VPC-Netzwerk verwenden, müssen Sie den zonalen voll qualifizierten Domainnamen (FQDN) der VMs verwenden.

  2. Klicken Sie in der Google Cloud Console auf der Seite VM-Instanzen im Banner 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 aktualisieren, um zonales DNS zu verwenden

Wenn Sie festgestellt haben, dass Ihr Projekt für die Migration zu zonalem DNS bereit ist, können Sie das Projekt und die VMs so konfigurieren, dass nur zonale DNS-Namen verwendet werden. Aktualisieren Sie dazu die Metadaten. Aktivieren Sie zonales 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, werden alle vmDnsSetting-Einstellungen überschrieben, die aus den Projektmetadaten für diese VM übernommen wurden.

Die Variable vmDnsSetting unterstützt die folgenden Einstellungen:

  • Empfohlen:Legen Sie vmDnsSetting=ZonalOnly in den Projektmetadaten fest. Das bedeutet, dass auf Ihre VMs bei Verwendung von Suchpfaden nur über ihre zonalen DNS-Namen (VM_NAME.ZONE.c.PROJECT_ID.internal) zugegriffen werden kann. Die VMs behalten weiterhin sowohl den zonalen als auch den globalen Suchpfad bei, ihre globalen DNS-Namen, die ZONE nicht als Teil des internen DNS-Namens enthalten, funktionieren jedoch nicht mehr. Wenn diese Einstellung aktiviert ist, können nur VMs in derselben Zone und im selben Projekt über den globalen Namen auf andere zugreifen. Andere VMs können auf VMs mit vmDnsSetting, die auf ZonalOnly festgelegt sind, nur über ihre zonalen DNS-Namen zugreifen und können auf diese VMs nicht über ihre globalen DNS-Namen oder Suchpfade zugreifen. 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.

Verwenden Sie eine der folgenden Methoden, um die Metadaten auf Projektebene oder für einzelne Instanzen zu konfigurieren und den Metadateneintrag vmDnsSetting zu aktualisieren. Weitere Informationen finden Sie unter Benutzerdefinierte Metadaten festlegen und entfernen.

Console

  1. Wenn Sie die Einstellung auf Projektebene aktualisieren möchten, rufen Sie in der Google Cloud -Konsole die Seite Metadaten auf.

    Zur Seite „Benutzerdefinierte Metadaten“

    1. Klicken Sie auf  Bearbeiten.
    2. Wenn ein Schlüssel mit dem Wert VmDnsSetting vorhanden ist, ändern Sie den Wert in ZonalOnly.
    3. Wenn kein Schlüssel mit dem Wert VmDnsSetting vorhanden ist, klicken Sie auf Element hinzufügen.
      • Geben Sie im Feld Schlüssel VmDnsSetting ein.
      • Geben Sie im Feld Wert den Wert ZonalOnly ein.
    4. Klicken Sie auf Speichern, um die Änderungen an den benutzerdefinierten Metadateneinträgen abzuschließen.

  2. Wenn Sie die Metadateneinstellung für eine Instanz aktualisieren möchten, rufen Sie in der Google Cloud -Konsole die Seite VM-Instanzen auf.

    Zu "VM-Instanzen"

    1. Klicken Sie in der Spalte Name auf den Namen der Instanz.

      Die Detailseite der Instanz wird geöffnet.

    2. Klicken Sie auf  Bearbeiten.

    3. Prüfen Sie im Abschnitt Verwaltung im Unterabschnitt Metadaten die vorhandenen Metadatenschlüssel.

    4. Wenn ein Schlüssel mit dem Wert VmDnsSetting vorhanden ist, ändern Sie den Wert in ZonalOnly.

    5. Wenn kein Schlüssel mit dem Wert VmDnsSetting vorhanden ist, klicken Sie auf Element hinzufügen.

      • Geben Sie im Feld Schlüssel VmDnsSetting ein.
      • Geben Sie im Feld Wert den Wert ZonalOnly ein.

    6. Klicken Sie auf Speichern, um die Änderungen an den benutzerdefinierten Metadateneinträgen abzuschließen.

gcloud

  1. Verwenden Sie den Befehl project-info add-metadata, um die Metadateneinstellung für das aktuelle Projekt zu aktualisieren.

    gcloud compute project-info add-metadata \
    --metadata vmDnsSetting=ZonalOnly

  2. Optional: Verwenden Sie den folgenden Befehl, um die Metadateneinstellungen für ein Projekt zu prüfen:

    gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"

    Ersetzen Sie PROJECT_ID durch den Namen des zu abfragenden Projekts.

  3. Verwenden Sie den Befehl compute instances add-metadata, um die Metadateneinstellung auf Instanzebene zu aktualisieren.

    Wenn Sie Instanzmetadaten mit der gcloud CLI aktualisieren, fügen Sie neue Daten hinzu. Geben Sie nur die Metadatenschlüssel an, die Sie hinzufügen oder ändern möchten. Wenn ein Schlüssel bereits existiert, wird der Wert des Schlüssels mit dem neuen Wert aktualisiert.

    gcloud compute instances add-metadata INSTANCE_NAME\
   --metadata vmDnsSetting=ZonalOnly

    Ersetzen Sie INSTANCE_NAME durch den Namen der Instanz, die Sie ändern möchten.

  4. Optional: Verwenden Sie den folgenden Befehl, um die Metadateneinstellungen für die Instanz zu prüfen:

    gcloud compute instances describe INSTANCE_NAME --flatten="metadata[]"

    Ersetzen Sie INSTANCE_NAME durch den Namen der Instanz, die abgefragt werden soll.

REST

  1. Wenn Sie die Metadateneinstellung auf Projektebene aktualisieren möchten, erstellen Sie eine POST-Anfrage an die Methode „projects.setCommonInstanceMetadata“.

    1. Optional: Für ein optimistisches Sperrverfahren können Sie optional einen Fingerabdruck angeben.

      Ein Fingerabdruck ist eine Reihe zufälliger Zeichen, die von Compute Engine erstellt wird. Dieser Fingerabdruck ändert sich nach jeder Anfrage. Geben Sie einen falschen an, wird Ihre Anfrage abgelehnt.

      Wenn Sie keinen Fingerabdruck angeben, wird keine Konsistenzprüfung durchgeführt. Die projects.setCommonInstanceMetadata-Anfrage ist dann erfolgreich. Dieses Verhalten unterscheidet sich von instances.setMetadata, bei dem immer ein Fingerabdruck erforderlich ist.

      Rufen Sie die Methode project.get auf, um den aktuellen Fingerabdruck eines Projekts abzurufen.

      GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID

      Die Ausgabe sieht in etwa so aus:

      {
 "name": "myproject",
 "commonInstanceMetadata": {
   "kind": "compute#metadata",
   "fingerprint": "FikclA7UBC0=",
   ...
 }
}

    2. Senden Sie eine POST-Anfrage an die Methode projects.setCommonInstanceMetadata, um das Metadaten-Schlüssel/Wert-Paar festzulegen:

      POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/setCommonInstanceMetadata

{
"fingerprint": "FikclA7UBC0=",
"items": [
  {
  "key": "vmDnsSetting",
  "value": "ZonalOnly"
  }
]
}

    Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

  2. So aktualisieren Sie die Metadateneinstellung auf Instanzebene:

    1. Rufen Sie den aktuellen Fingerabdruck ab und rufen Sie alle vorhandenen Schlüssel/Wert-Paare für die Instanz auf. Rufen Sie dazu die Methode instances.get auf.

      Ein Fingerabdruck ist eine Reihe zufälliger Zeichen, die von Compute Engine erstellt und für ein optimistisches Sperrverfahren genutzt werden. Zum Aktualisieren der Instanz müssen Sie den entsprechenden Fingerabdruckwert angeben. Dieser Fingerabdruck ändert sich nach jeder Anfrage. Geben Sie einen falschen an, wird Ihre Anfrage abgelehnt. Das führt dazu, dass nur jeweils eine Aktualisierung auf einmal durchgeführt wird und Konflikte vermieden werden.

      GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME

      Ersetzen Sie Folgendes:

      • PROJECT_ID: Ihre Projekt-ID.
      • ZONE: die Zone, in der sich die Instanz befindet.
      • INSTANCE_NAME: Name der Instanz

      Die Ausgabe sieht in etwa so aus:

      {
 ...
 "name": "example-instance",
 "metadata": {
     "kind": "compute#metadata",
     "fingerprint": "zhma6O1w2l8="
     "items": [
        {
          "key": "foo",
          "value": "bar"
        }
     ]
 },
...
}

    2. Senden Sie eine POST-Anfrage an die Methode instances.setMetadata und geben Sie die benutzerdefinierten Metadaten als Teil des Metadatenattributs in Ihrer Anfrage an.

      Sie müssen alle Schlüssel/Wert-Paare, die Sie behalten möchten, sowie die neuen Schlüssel/Wert-Paare in die Anfrage aufnehmen, z. B.:

      POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME/setMetadata

{
"fingerprint": "FINGERPRINT_ID",
"items": [
  {
    "key": "vmDnsSetting",
    "value": "zonalOnly"
  },
  {
    "key":"enable-oslogin",
    "value":"TRUE"
  },
  {
    "key":"enable-oslogin-2fa",
    "value":"TRUE"
  }
]
}

      Ersetzen Sie Folgendes:

      • PROJECT_ID: Ihre Projekt-ID.
      • ZONE: die Zone, in der sich die Instanz befindet.
      • INSTANCE_NAME: Name der Instanz
      • FINGERPRINT_ID: Der aktuelle Fingerabdruckwert für die Instanz

  3. Optional: Verwenden Sie den folgenden Befehl, um die Metadateneinstellungen für die Instanz zu prüfen:

    GET https://compute.googleapis.com/compute/v1/projects/PROJECT/zones/ZONE/instances/INSTANCE_NAME?fields="metadata"

    Ersetzen Sie Folgendes:

    • PROJECT_ID: Ihre Projekt-ID.
    • ZONE: die Zone, in der sich die Instanz befindet.
    • INSTANCE_NAME: Name der abzufragenden Instanz

    Die Ausgabe sieht in etwa so aus:

    {
 "metadata": {
   "kind": "compute#metadata",
   "fingerprint": "_du-LbdwokE=",
   "items": [
     {
       "key": "ssh-keys",
       "value": "..."
     },
     {
       "key": "vmDnsSetting",
       "value": "zonalOnly"
     }
   ]
 }
}

Nachdem Sie den Metadateneintrag vmDnsSetting für ein Projekt oder eine Instanz konfiguriert haben, aktualisieren Sie die DHCP-Freigabe für die Instanz. Dazu können Sie die Instanz neu starten, auf den Ablauf der Freigabe warten oder einen der folgenden Befehle im Gastbetriebssystem 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 noch nicht zur Migration bereit sind

Wenn ein Projekt nicht für die Migration bereit ist, bedeutet das, dass innerhalb eines bestimmten Zeitraums, z. B. der letzten 30 Tage oder der letzten 100 Tage, mindestens eine riskante DNS-Abfrage erfolgt ist. 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. Risikoreiche Abfragen können die folgenden Attribute haben:

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

Bei Projekten mit riskanten Abfragen ist in der Regel zusätzliche Arbeit erforderlich, um vor der Migration alle riskanten DNS-Suchanfragen zu entfernen.

Führen Sie für Projekte, die noch nicht für die Migration bereit sind, die folgenden Schritte aus:

  1. Aktivieren Sie die Suchpfadverbesserung, um zonenübergreifende DNS-Namenssuchen zu lösen. So können Ihre Projekte für die Migration vorbereitet werden, ohne dass Ihre Ressourcen beeinträchtigt werden.
  2. Wenn durch die Anpassung des Suchpfads nicht alle zonenübergreifenden Abfragen übertragen werden, können Sie die Abfragen manuell auf zonale DNS-Namen aktualisieren.

Funktion zur Verbesserung des Suchpfads

Standardmäßig speichern die meisten Linux-Distributionen DHCP-Informationen in resolv.conf. Das folgende Beispiel zeigt eine minimale globale 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 bei der DNS-Auflösung verwendet werden sollen. Der DNS-Server versucht, die Abfrage nacheinander mit jedem der Hostnamen im Suchpfad aufzulösen, bis eine Übereinstimmung mit einem DNS-Eintrag gefunden wird. Wenn eine VM beispielsweise ping my-vm aufruft, werden die Domains im Suchpfad an die ursprüngliche Abfrage angehängt, um die voll qualifizierten Domainnamen (FQDN) zu erhalten, z. B. mit my-vm.c.PROJECT_ID.internal. Wenn eine Übereinstimmung gefunden wird, gibt der DNS-Resolver in der Antwort eine interne IP-Adresse zurück. Andernfalls wird versucht, den DNS-Namen anhand der nächsten Domain im Suchpfad aufzulösen.

Wenn Sie dem VM-Suchpfad zusätzliche zonale Domains hinzufügen, können einige Projekte für die Migration vorbereitet werden. Angenommen, Ihre VM befindet sich in der Zone us-west4-c. Diese VM ruft eine andere VM mit dem Namen 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 mit einem FQDN aufzulösen, der dem VM-Namen einen der Suchpfade 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 zur Suchliste hinzufügen, 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 die Funktion Suchpfadverbesserung an, mit der automatisch in allen Zonen in derselben Region wie die VM nach dem zonalen DNS-Namen für eine VM gesucht wird. So können zonalübergreifende Abfragen aufgelöst werden, ohne dass die Datei resolv.conf oder die DHCP-Richtlinie aktualisiert werden muss. Mit Suchpfadverbesserungen können zonenübergreifende Abfragen innerhalb einer Region bis zu 80% der Zeit gelöst werden. Mit dieser Funktion sollte die Mehrheit der Projekte mit riskanten Abfragen für die Migration zu zonalem DNS bereit sein.

Aktivieren Sie die Suchpfadverbesserung, um zonenübergreifende DNS-Namenssuchen zu lösen.

So aktivieren Sie die Funktion zur Verbesserung des Suchpfads:

  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 die Einstellung für das Projekt einige Tage lang aktiv und prüfen Sie den Monitoring-Messwert, um festzustellen, ob es noch riskante oder zonalübergreifende globale DNS-Abfragen gibt.

    • Wenn der Wert für das Projekt 0 ist, kann es jetzt migriert werden.
    • Wenn das Projekt einen Wert ungleich null zurückgibt, ändern Sie alle Namen der globalen DNS-Abfragen so, dass der zonale FQDN verwendet wird, wie im nächsten Abschnitt beschrieben.

Abfragen manuell auf zonale DNS-Namen umstellen

Wenn Sie mit der Funktion zur Suchpfadverbesserung zusätzliche zonale Domains in den Suchpfad für DNS-Namen einfügen, aber nicht alle zonenübergreifenden Abfragen übertragen werden, können Sie sich die globale DNS-Nutzung im Projekt im Log-Explorer ansehen.

So ermitteln Sie die globalen DNS-Abfragen, die manuell geändert werden müssen, um stattdessen zonenspezifische voll qualifizierte Domainnamen (FQDNs) zu verwenden:

  1. Folgen Sie der Anleitung unter Prüfen, ob das Projekt migriert werden kann, um die globale DNS-Nutzung für ein Projekt aufzurufen. Im Log-Explorer können Sie auf die globale DNS-Nutzung für VMs in Ihrem Projekt zugreifen und sie abfragen.

  2. Im Bereich Abfrageergebnisse hat jede Abfrage ein jsonPayload-Feld. Jedes jsonPayload-Feld enthält die folgenden Informationen:

    • Der Name der Quell-VM, ihre Projekt-ID und der Zonenname.
    • Der Name der Ziel-VM, ihre Projekt-ID und der Zonenname.

    • Eine Debug-Nachricht mit Informationen zum Aktualisieren der globalen DNS-Abfrage, die nicht mithilfe zonaler DNS-Namen aufgelöst werden kann. Diese Abfragen blockieren die Migration und sollten behoben werden.

      "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 angibt, wie viele Migrationsblockierungsanfragen die Quell-VM an diesem 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. Anhand der Informationen in jsonPayload können Sie den FQDN ermitteln, mit dem Sie Ihre globalen DNS-Abfragen manuell auf zonales DNS umstellen und das Projekt für die Migration vorbereiten. Die häufigsten Anwendungsfälle für die Aktualisierung des FQDN und die Behebung von Kompatibilitätsproblemen sind:

    • Interne DNS-Namen vom Metadatenserver: Es sind keine Maßnahmen erforderlich, da sich der zurückgegebene DNS-Name unmittelbar nach der Migration zu zonalen DNS-Namen in einen zonalen FQDN ändert. Wenn der DNS-Name im Cache ist, müssen Sie nur noch einmal aufrufen, um den Cachewert 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 so aktualisieren, dass stattdessen der interne DNS-Name oder der zonale FQDN verwendet wird. Sie können diese Änderung durch eine Code- oder Konfigurationsänderung in Terraform vornehmen.
    • VMs in Dienstprojekten, die ein freigegebene VPC-Netzwerk verwenden: Zum Auflösen der DNS-Namen von VMs in Dienstprojekten, die ein freigegebene VPC-Netzwerk verwenden, müssen Sie die zonalen FQDNs der VMs verwenden.

Nachdem Sie die globalen DNS-Abfragen auf zonales DNS umgestellt haben, gehen Sie so vor:

  1. Rufen Sie die Seite „Log-Explorer“ auf, um die globale DNS-Nutzung noch einmal abzufragen. Nachdem Sie alle blockierenden globalen DNS-Abfragen behoben haben, sollten in den Abfrageergebnissen keine Debug-Logs angezeigt werden.
  2. Prüfen Sie den Monitoring-Messwert 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 für den internen DNS-Namen einer VM ein zonaler DNS-Name verwendet wird.

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

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

Zur Verwendung des globalen DNS zurückkehren

Sie können die Migration zum zonalen DNS rückgängig machen, indem Sie den standardmäßigen internen DNS-Typ wieder in „Globales DNS“ ändern. Das ist auf Organisations-, Projekt-, VM- oder Containerebene möglich.

Zur Verwendung des globalen DNS für eine Organisation oder einen Ordner zurückkehren

So kehren Sie bei einer Organisation oder einem Ordner zur Verwendung des globalen DNS zurück:

  1. Deaktivieren Sie die Organisationsrichtlinieconstraints/compute.setNewProjectDefaultToZonalDNSOnly auf Organisations- oder Ordnerebene. Eine Anleitung zum Ändern dieser Richtlinie finden Sie unter Zonales DNS standardmäßig für neue Projekte erzwingen.

    Legen Sie die Erzwingung der Richtlinie Legt die interne DNS-Einstellung für neue Projekte so fest, dass nur zonales DNS verwendet wird auf Aus fest.

  2. Wenn Sie für die gesamte Organisation wieder zum globalen DNS zurückkehren möchten, prüfen Sie, ob für keinen der Ordner in der Organisation die Organisationsrichtlinie constraints/compute.setNewProjectDefaultToZonalDNSOnly erzwungen wird.

  3. In den folgenden Abschnitten wird beschrieben, wie Sie prüfen, ob globales 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 wieder auf die Verwendung des globalen DNS umzustellen.

  1. Fügen Sie den Metadaten des Projekts Folgendes hinzu: vmDnsSetting=GlobalDefault.

    Folgen Sie der Anleitung unter Projekte und VMs manuell aktualisieren, um zonales DNS zu verwenden und verwenden Sie den Wert GlobalDefault anstelle von ZonalOnly.

  2. Prüfen Sie, ob bei keiner der Instanzen im Projekt der Metadatenwert vmDnsSetting auf ZonalOnly festgelegt ist. Sie können einen Befehl wie den folgenden verwenden:

    gcloud compute instances describe INSTANCE_NAME --flatten="metadata[]"

    Ersetzen Sie INSTANCE_NAME durch den Namen der Instanz, die abgefragt werden soll.

  3. Aktualisieren Sie die DHCP-Freigabe auf jeder Instanz. Dazu können Sie die Instanz neu starten, auf den Ablauf der Freigabe warten oder einen der folgenden Befehle im Gastbetriebssystem ausführen:

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

Zur Verwendung des globalen DNS für eine VM zurückkehren

Führen Sie die folgenden Schritte aus, um für eine bestimmte Instanz wieder das globale DNS zu verwenden.

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

    Folgen Sie der Anleitung unter Projekte und VMs manuell aktualisieren, um zonales DNS zu verwenden und verwenden Sie den Wert GlobalDefault anstelle von ZonalOnly.

  2. Starten Sie das Netzwerk der Instanz 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

    oder

    sudo systemctl restart NetworkManager.service

  • Für Debian:

    sudo systemctl restart networking

  • Für Linux-Systeme mit nmcli:

    sudo nmcli networking off
sudo nmcli networking on

  • 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. So deaktivieren Sie das zonale DNS für diese Container-Apps:

  1. Legen Sie die Projektmetadateneinstellung vmDnsSetting in den Projekten, 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

Wenn bei der Migration Probleme auftreten, lesen Sie den Leitfaden zur Fehlerbehebung.

Migrationsbanner für zonale DNS in der Google Cloud Console ausblenden

Sie können auf die Schaltfläche Schließen im Banner mit der Benachrichtigung zur zonalen DNS-Migration klicken, das auf der Seite VM-Instanzen der Google Cloud -Konsole angezeigt wird. So wird verhindert, dass das Banner für das Projekt auf unbestimmte Zeit angezeigt wird.

Wenn Sie das Banner geschlossen haben, es aber wieder angezeigt werden soll, wenden Sie sich bitte an den Cloud Customer Care.

Nächste Schritte