Vorhandene Cloud DNS-Weiterleitungskonfiguration zu ausgehenden Endpunkten migrieren

In diesem Dokument erhalten Sie einen allgemeinen Überblick darüber, was Sie tun müssen, um eine vorhandene Cloud DNS-Weiterleitungskonfiguration für die Verwendung von ausgehenden Endpunkten zu migrieren.

Vorhandene Cloud DNS-Weiterleitungseinrichtung migrieren

Die Migration einer vorhandenen Cloud DNS-Weiterleitungskonfiguration zur Verwendung ausgehender Endpunkte erfolgt in vier Phasen:

Vorbereitung

In der Vorbereitungsphase, bevor Sie mit der Migration beginnen können, erstellen Sie die Nur-Proxy-Subnetze, reguläre Subnetze und ausgehende Endpunkte. Achten Sie außerdem darauf, dass Ihr lokales Netzwerk eine Rückgaberoute für den IP-Adressbereich des regionalen Nur-Proxy-Subnetzes hat und dass Ihre lokalen Firewallregeln eingehenden DNS-Traffic aus dem IP-Adressbereich Ihres regionalen Nur-Proxy-Subnetzes zulassen.

  1. Nur-Proxy-Subnetze erstellen: Erstellen Sie in jeder Region, in der Sie einen ausgehenden Endpunkt bereitstellen möchten, ein Nur-Proxy-Subnetz mit einer Mindestgröße von /26 (64 Adressen), falls noch nicht vorhanden.
  2. Reguläres Subnetz identifizieren oder erstellen: Identifizieren oder erstellen Sie in jeder Region, in der Sie einen ausgehenden Endpunkt bereitstellen möchten, ein reguläres Subnetz mit einer verfügbaren internen IPv4-Adresse im primären IP-Bereich.
  3. Ausgehende Endpunkte erstellen: Erstellen Sie Ihre ausgehenden Endpunkte und verknüpfen Sie sie mit Ihrem Ziel-VPC-Netzwerk, Ihrer Region, Ihrem regulären Subnetz (--subnetwork=REGULAR_SUBNET) und einer verfügbaren internen IPv4-Adresse (--endpoint-ip=IP_ADDRESS_STRING). Cloud DNS erstellt und verwaltet automatisch die statische IP-Reservierungsressource und bindet den Endpunkt an das regionale Nur-Proxy-Subnetz im VPC-Netzwerk.

  4. Lokale Firewalls und Routen aktualisieren: Achten Sie darauf, dass Ihr lokales Netzwerk eine Rückroute für den IP-Adressbereich des regionalen Nur-Proxy-Subnetzes hat. Fügen Sie in Ihren lokalen und externen Umgebungen Firewallregeln hinzu, um eingehenden DNS-Traffic (UDP- und TCP-Port 53) aus dem IP-Adressbereich Ihres regionalen Nur-Proxy-Subnetzes zuzulassen.

Bestätigung (optional)

Optional können Sie die Überprüfungsphase verwenden, um die Konfiguration des ausgehenden Endpunkts zu überprüfen.

  1. Testweiterleitungszone erstellen: Erstellen Sie eine neue, temporäre Weiterleitungszone für eine Testdomain (z. B. test.corp.example.com).
  2. Für die Endpunkte konfigurieren: Konfigurieren Sie die Testzone so, dass die neuen ausgehenden Endpunkte verwendet werden.
  3. Test-VM starten: Starten Sie in einem relevanten VPC-Netzwerk eine temporäre Test-VM.
  4. Auflösung prüfen: Fragen Sie von der Test-VM aus mit dig oder nslookup einen Host in Ihrer Testzone ab (z. B. dig host.test.corp.example.com). Bestätigen Sie, dass Sie eine erfolgreiche DNS-Antwort erhalten. Prüfen Sie in den Server-Logs Ihres lokalen oder externen DNS-Servers, ob der Server die Anfrage von einer Quell-IP-Adresse im neuen regionalen Nur-Proxy-Subnetz erhalten hat. Prüfen Sie außerdem in den dns_query-Logs, ob jsonPayload.egressPath auf OUTBOUND_ENDPOINT gesetzt ist.

Produktionsmigration

Während der Produktionsmigrationsphase aktualisieren Sie Ihre Weiterleitungszonen und Serverrichtlinien, um Ihre ausgehenden Endpunkte zu verwenden, und prüfen die Abfragelogs, um sicherzustellen, dass Abfragen erfolgreich aufgelöst werden.

  1. Weiterleitungszonen und Serverrichtlinien aktualisieren: Bearbeiten Sie für jede Weiterleitungszone oder Serverrichtlinie, die Sie migrieren möchten, die Konfiguration und ändern Sie den Weiterleitungspfad vom Standardbereich 35.199.192.0/19 in Ihre Endpunkte für ausgehenden Traffic.
  2. Auflösung und Zustand überwachen: Prüfen Sie Ihre Cloud DNS-Abfragelogs (jsonPayload.egressPath=OUTBOUND_ENDPOINT, jsonPayload.outboundEndpoint und jsonPayload.egressError) und die vorhandenen Monitoring-Messwerte für die migrierten Zonen, um zu bestätigen, dass Abfragen erfolgreich aufgelöst werden.
    • Verwenden Sie dns.googleapis.com/query/response_count, um das Abfragevolumen und die Antwortstatuscodes zu verfolgen.
  3. Strategie für Migrationen mit hohem Volumen und Vorwärmen:
    • Autoscaling-Latenz: Für die zugrunde liegende, von Google verwaltete Proxy-Infrastruktur gilt eine Autoscaling-Latenz von etwa 10 Minuten.
    • Inkrementelles Roll-out: Migrieren Sie Zonen inkrementell (eine Zone nach der anderen), wenn Ihr aggregiertes Abfragevolumen 10.000 Abfragen pro Sekunde (QPS) pro Region überschreitet, um zu vermeiden, dass Abfragen während des Autoscaling-Hochfahrens verworfen werden.
    • Unterstützung beim Vorwärmen: Bei großen Migrationen in einer einzelnen Zone, die sofort 10.000 QPS pro Region überschreiten, sollten Sie den Traffic schrittweise erhöhen (z. B. 10%, 25%, 50 % und dann 100%) oder sich vor der geplanten Migration an Ihr Account-Management-Team von Google Cloudoder den Support wenden, um ein Vorwärmen der Infrastruktur während des geplanten Wartungsfensters anzufordern. Geben Sie in Ihrer Anfrage Folgendes an:
      • Projekt-ID
      • Zielregion(en)
      • Geschätzte Spitzen-QPS

Bereinigen

Nachdem Sie bestätigt haben, dass die Produktionsmigration erfolgreich war, müssen Sie den vorherigen Weiterleitungsmechanismus bereinigen.

  1. Vollständige Migration bestätigen: Prüfen Sie, ob alle erforderlichen Weiterleitungszonen und Serverrichtlinien in Ihrem Projekt nicht den Standardbereich 35.199.192.0/19 verwenden.
    • Prüfen Sie Ihre lokalen DNS-Logs und achten Sie darauf, dass für einen sicheren Zeitraum (z. B. 24 Stunden) kein Traffic aus diesem Bereich stammt.
  2. Vorherige Firewallregel entfernen: Nachdem Sie bestätigt haben, dass der gesamte Traffic zu ausgehenden Endpunkten verschoben wurde, können Sie die lokale Firewallregel, die eingehenden DNS-Traffic aus dem Standardbereich 35.199.192.0/19 zugelassen hat, sicher entfernen. Achten Sie darauf, dass keine anderen Google Cloud -Dienste diese Regel verwenden, bevor Sie sie entfernen oder anpassen.

Rollback

Wenn Sie ein Rollback für die Migration durchführen müssen, gehen Sie so vor:

  1. Weiterleitungszonen- oder Serverrichtlinien zurücksetzen: Bearbeiten Sie die betroffene Zonen- oder Serverrichtlinie und ändern Sie die Weiterleitung wieder in den Standardbereich 35.199.192.0/19.
  2. Firewallregeln wiederherstellen: Prüfen Sie, ob die Regel, die eingehenden DNS-Traffic von 35.199.192.0/19 zulässt, noch aktiv ist. Entfernen Sie diese Regel erst nach der Bereinigungsphase einer erfolgreichen Migration.

Nächste Schritte