DNS-Routingrichtlinien und ‑Systemdiagnosen

Sie können DNS-Routingrichtlinien für Ressourceneinträge im privaten Modus konfigurieren oder öffentlichen Zonen, um den Verkehr basierend auf bestimmten Kriterien zu steuern. Erstellen Sie Ressourceneinträge mit bestimmten Werten für die Routingrichtlinie, um diese Richtlinien einzurichten. Diese Werte bestimmen, wie Cloud DNS den Abfragetraffic weiterleitet.

Cloud DNS unterstützt die folgenden Routingrichtlinien:

  • WRR-Routingrichtlinie (Weighted Round Robin): WRR verwenden Routingrichtlinie, um jedem Ressourceneintragssatz für eine DNS-Name. Mit einer WRR-Routingrichtlinie wird dafür gesorgt, dass der Traffic gemäß den konfigurierten Gewichtungen verteilt wird. Die Kombination von WRR- und Standortbestimmungs-Routingrichtlinien wird nicht unterstützt.

  • Richtlinie für das Routing zur Standortbestimmung: Verwenden Sie die Standortbestimmung. Routingrichtlinie zum Angeben von Quellstandorten und zur Bereitstellung entsprechender Antworten auf diese Regionen. Die Standortbestimmungs-Routingrichtlinie wendet die nächstgelegene Übereinstimmung für den Quellstandort an, wenn keine Richtlinienelemente genau mit der Besucherquelle übereinstimmen.

  • Failover-Routing-Richtlinie: Mit der Failover-Routing-Richtlinie können Sie aktive Sicherungskonfigurationen einrichten.

DNS-Routingrichtlinien können für die folgenden privaten Zonen nicht konfiguriert werden:

  • Weiterleitungszonen
  • DNS-Peering-Zonen
  • Verwaltete Zonen für den umgekehrten Lookup
  • Service Directory-Zonen

WRR-Routingrichtlinien

Mit einer WRR-Routingrichtlinie können Sie unterschiedliche Gewichtungen angeben pro DNS-Ziel an und Cloud DNS sorgt dafür, dass Ihr Traffic entsprechend den Gewichten. Sie können diese Richtlinie verwenden, um manuelle active-active oder active-passive Konfigurationen. Sie können den Traffic auch auf Produktionsversionen und experimentelle Versionen Ihres Dienstes aufteilen.

Cloud DNS unterstützt Systemdiagnosen und Failovers innerhalb des Routings für interne Load-Balancer und externe Endpunkte. Cloud DNS aktiviert automatisches Failover, wenn die Endpunkte Systemdiagnosen durchführen. Bei einem Failover passt Cloud DNS die Trafficaufteilung automatisch auf die verbleibenden fehlerfreien Endpunkte an. Weitere Informationen finden Sie unter Systemdiagnosen.

Richtlinien für das Routing nach Standortbestimmung

Mit einer Routingrichtlinie für die Standortbestimmung können Sie Traffic, der von Quellregionen (Google Cloud-Regionen) stammt, bestimmten DNS-Zielen zuordnen. Mit dieser Richtlinie können Sie eingehende Anfragen basierend auf dem Ursprung des Traffics an verschiedene Dienstinstanzen verteilen. Sie können diese Funktion mit Traffic von außerhalb von Google Cloud oder mit Traffic aus Google Cloud, der an interne Passthrough Network Load Balancer gebunden ist, verwenden. Cloud DNS verwendet die Region, in der Abfragen in Google Cloud gelangen, als Quellregion.

Eine Routingrichtlinie für die Standortbestimmung ordnet die Quelle für das öffentliche und das private DNS unterschiedlich zu auf folgende Arten:

  • Beim öffentlichen DNS wird die Quell-IP-Adresse oder das -EDNS-Clientsubnetz (Erweiterungsmechanismus für DNS) der Abfrage verwendet.
  • Für ein privates DNS wird das EDNS-Clientsubnetz nicht verwendet. Stattdessen ist der Standort der Abfrage der Standort des Systems, das die Pakete für die Abfrage sendet:
    • Bei Abfragen von einer Compute Engine-VM-Instanz mit einer Netzwerkschnittstelle in einem VPC-Netzwerk ist der Standort der Abfrage die Region, in der sich die VM-Instanz befindet.
    • Für Abfragen, die von einem Serverrichtlinieneintrag für eingehenden Traffic empfangen wurden Punkt, der Die Position der Abfrage ist die Region des Cloud VPN-Tunnels. Cloud Interconnect-VLAN-Anhang oder Router-Appliance die die Pakete für die Abfrage erhalten hat. Die Region der IP-Adresse des Einstiegspunkts ist nicht relevant. Weitere Informationen finden Sie unter Netzwerk und Region für eingehende Abfragen.

Cloud DNS unterstützt Systemdiagnosen und Failovers innerhalb des Routings für interne Load-Balancer und externe Endpunkte. Cloud DNS aktiviert automatisches Failover, wenn die Endpunkte Systemdiagnosen durchführen. Wenn Sie Richtlinien zur Standortbestimmung verwenden, schlägt der Traffic fehl der dem Quell-Traffic am nächsten ist.

Routingrichtlinie für Standortbestimmung mit Geofence

Mit einem Geofence wird sichergestellt, dass Traffic an eine bestimmte Region weitergeleitet wird, auch wenn alle Endpunkte in dieser Region die Systemdiagnosen nicht bestehen.

Wenn die Geofencing-Funktion deaktiviert ist und für eine bestimmte Region ein Systemdiagnosefehler auftritt, wird der Traffic automatisch auf die nächstgelegene Region umgeleitet. Wenn Geofencing jedoch aktiviert ist, kommt es nicht zu diesem automatischen Failover. Als autoritativer Server muss Cloud DNS einen Wert zurückgeben. Szenario, gibt Cloud DNS alle IP-Adressen unverändert zurück, wenn der die Endpunkte die Systemdiagnosen nicht bestehen.

Failover-Routingrichtlinien

Mit der Failover-Routingrichtlinie können Sie aktive Sicherungskonfigurationen einrichten, Hochverfügbarkeit für interne Ressourcen in Ihrem VPC-Netzwerk.

Im Normalbetrieb gibt Cloud DNS immer die IP-Adresse zurück, Adressen aus dem Satz active. Wenn alle IP-Adressen in active festgelegt sind fehlerhaft werden, stellt Cloud DNS die IP-Adressen aus der backup festgelegt. Wenn Sie backup als Richtlinie für das Routing zur Standortbestimmung konfigurieren, wie in den Richtlinien für die Standortbestimmung beschrieben. . Wenn Sie die backup-Gruppe für einen internen Load Balancer konfigurieren, werden alle virtuellen IP-Adressen (VIP) für die Sicherung durch Cloud DNS geprüft.

Mit Cloud DNS können Sie den Traffic nach und nach an die virtuellen Sicherungsadressen ausleiten. um zu überprüfen, ob die virtuellen Backup-Adressen funktionieren. Sie können Konfigurieren Sie den Prozentsatz des an die Sicherung gesendeten Traffics als Bruchteil zwischen 0 und 1 liegen. Sie können einen Failover manuell auslösen, indem Sie 100 % des Traffics an die VIP-Ersatzadressen senden. Der typische Wert ist 0,1. Systemdiagnosen können nur auf interne Load Balancer und externe Endpunkte angewendet werden.

Systemdiagnosen

Cloud DNS unterstützt Systemdiagnosen und Failover innerhalb von Routingrichtlinien für die folgenden internen Load Balancer und externen Endpunkte:

Wenn Sie Systemdiagnosen mit einer verwalteten Zone und DNS-Sicherheitserweiterungen (DNSSEC) verwenden möchten aktiviert ist, kann pro Richtlinienelement nur eine IP-Adresse verwendet werden (ein WRR oder Geolocation). Systemdiagnose-IP-Adressen dürfen nicht kombiniert werden Adressen und nicht geprüfte IP-Adressen in einer bestimmten Richtlinie.

Informationen zu Best Practices bei der Konfiguration des Cloud DNS-Eintrags und der Systemdiagnosen finden Sie unter Best Practices.

Systemdiagnosen für interne Load-Balancer

Systemdiagnosen für interne Load Balancer sind nur in privaten Zonen verfügbar.

Für interne Application Load Balancer und interne Proxy-Network Load Balancer berücksichtigt Cloud DNS den Zustand des Load-Balancers selbst während der Routing-Entscheidung überprüfen. Wenn ein erhält der Load-Balancer eine Abfrage, verteilt den Traffic nur auf die fehlerfreien Back-End-Dienste. Damit es immer fehlerfreie Back-Ends gibt, können Sie den Lebenszyklus der Back-Ends mithilfe von Diensten wie verwalteten Instanzgruppen (Managed Instance Groups, MIGs) verwalten. Cloud DNS muss den Systemstatus nicht kennen der einzelnen Back-Ends; erledigt der Load-Balancer diese Aufgabe.

Bei internen Passthrough-Network Load Balancern prüft Cloud DNS die Systeminformationen auf der Back-End-Instanzen des Lastenausgleichsmoduls. Cloud DNS verwendet standardmäßig einen Grenzwert von 20 %. Wenn mindestens 20 % der Backend-Instanzen fehlerfrei sind, gilt der Load Balancer-Endpunkt als fehlerfrei. DNS-Routingrichtlinien kennzeichnen den Endpunkt basierend auf diesem Schwellenwert als fehlerfrei oder fehlerhaft und leiten den Traffic entsprechend weiter.

Eine einzelne virtuelle IP-Adresse (VIP) des internen Passthrough-Network Load Balancers kann mehrere Back-Ends haben Instanzen. Wenn ein interner Passthrough-Network Load Balancer keine Backend-Instanzen hat, als gesund erachtet. Damit die Systemdiagnose korrekt funktioniert, geben Sie Folgendes unter mindestens eine Back-End-Instanz in der Konfiguration des Lastenausgleichsmoduls enthält.

Wenn der Endpunkt als fehlerhaft markiert wird, können die folgenden Bedingungen eintreten:

  • Wenn für eine Richtlinie mehrere VIP-Adressen programmiert sind, werden nur fehlerfreie VIP-Adressen zurückgegeben.

  • Wenn alle für einen Richtlinien-Bucket programmierten VIP-Adressen fehlerhaft sind, diese Richtlinienzeile fehlgeschlagen ist. Das folgende Verhalten gilt:

    • Bei einer WRR-Richtlinie verteilt Cloud DNS den Traffic proportional auf die verbleibenden fehlerfreien Endpunkte, die in der Richtlinie definiert sind.
    • Bei einer Richtlinie für die Standortbestimmung, für die keine Begrenzung aktiviert ist, wird der Traffic an Endpunkte in der Region in der Nähe der in der Richtlinie definierten Google Cloud-Quellregion weitergeleitet.
    • Bei einer Standortbestimmungsrichtlinie, für die Geofencing aktiviert ist, verteilt Cloud DNS den Traffic an die VIP-Adresse, die der in der Richtlinie definierten Google Cloud-Quellregion am nächsten ist.
    • Bei einer Failover-Richtlinie leitet Cloud DNS den Traffic an die in der Richtlinie definierten Ersatzendpunkte weiter.
    • Wenn alle Richtlinien-Buckets nicht fehlerfrei sind, verhält sich Cloud DNS so, als wären alle Endpunkte fehlerfrei. Dieses Szenario kann dazu führen, dass Traffic an nicht reagierende Endpunkte weitergeleitet wird.

Weitere Informationen zu Systemdiagnosen für interne Load-Balancer Siehe Systemdiagnosen – Übersicht.

Systemdiagnosen für externe Endpunkte (Vorschau)

Systemdiagnosen für externe Endpunkte sind nur in öffentlichen Zonen verfügbar. Die Endpunkte, für die Sie eine Systemdiagnose durchführen möchten, müssen öffentlich zugänglich sein Internet. Der angegebene Endpunkt kann eine beliebige externe IP-Adresse und ein beliebiger Port sein. einschließlich einer globalen virtuellen IP-Adresse des externen Application Load Balancers und einer regionalen, Virtuelle IP-Adresse des externen Proxy-Network Load Balancers, lokal oder anderen Endpunkten, auf die über das öffentliche Internet zugegriffen werden kann.

Verwenden Sie Systemdiagnosen für externe Endpunkte in den folgenden Fällen:

  • Traffic an einen regionalen externen Application Load Balancer umleiten, wenn ein globaler externer Application Load Balancer verwendet wird oder ein globales externes Network Load Balancer-Back-End fehlerhaft wird.
  • Damit wird der Traffic an einen anderen regionalen externen Application Load Balancer weitergeleitet, wenn das Backend eines bestimmten regionalen externen Application Load Balancers nicht mehr betriebsbereit ist.
  • Überwachen Sie den Status von lokalen Endpunkten oder anderen Endpunkten, die über das öffentliche Internet erreichbar sind.

Wenn Sie eine DNS-Routingrichtlinie mit Systemdiagnosen für externe Endpunkte erstellen, sendet Cloud DNS Systemdiagnosen an Ihre Endpunkte. Diese die Systemdiagnoseprüfungen aus drei Google Cloud-Quellregionen, die Sie angeben. Die Systemdiagnose-Prober der einzelnen Regionen werden unabhängig voneinander ausgeführt und die Ergebnisse werden in Cloud DNS zusammengefasst, um den Gesamtstatus des Endpunkts zu ermitteln. Innerhalb jeder Region prüfen drei Systemdiagnose-Proberinstanzen jeden Endpunkt. Wenn eine Prüfung fehlschlägt, kann Cloud DNS trotzdem Endpunktzustand mithilfe der verbleibenden Prüfungen ermitteln. Das bedeutet, dass Sie für jeden Endpunkt insgesamt neun Prober haben und jede Prüfung mit der Häufigkeit erfolgt, die Sie im Prüfintervall der Systemdiagnose angeben. Anhand der Parameter der Routingrichtlinie und der Informationen zur Systemdiagnose wählt Cloud DNS einen Endpunkt aus und leitet den Traffic an den ausgewählten Endpunkt weiter.

Cloud DNS unterstützt die Protokolle TCP, HTTP und HTTPS mit den folgenden Einschränkungen:

  • Das Feld für die TCP-Anfrage wird nicht unterstützt.
  • Das Feld proxyHeader für HTTP, HTTPS und TCP wird nicht unterstützt.

SSL-, HTTP/2- und gRPC-Protokolle werden nicht unterstützt.

Beim TCP-Protokoll versucht Cloud DNS, eine Verbindung zum Endpunkt herzustellen. Bei den HTTP- und HTTPS-Protokollen prüft Cloud DNS, ob der Endpunkt einen HTTP-Antwortcode 200 zurückgibt. Sie können auch einen inhaltsbasierten Status konfigurieren. Dabei prüft Cloud DNS, ob die Antwort eine bestimmte .

Im Gegensatz zur Systemdiagnose für interne Load-Balancer Systemdiagnosen für externe Endpunkte stammen nicht aus festen IP-Adressbereichen. Die Quell-IP-Adressbereiche der Prüfung können sich im Laufe der Zeit ändern.

Das Protokoll und der Port, die Sie beim Erstellen der Systemdiagnose angeben, bestimmen, wie Systemdiagnoseprüfungen durchgeführt werden. Wenn Sie keinen Port angeben, verwendet Port 80. Damit Systemdiagnosen korrekt funktionieren, Firewallregeln so konfigurieren, dass Systemdiagnoseprüfungen von beliebigen Quellen zugelassen werden IP-Adresse und auf dem spezifischen Port, der in der Systemdiagnose konfiguriert ist.

Wenn Sie Ihre Firewall nicht so konfiguriert haben, dass Systemdiagnosetests zulässig sind, schlagen die Tests fehl. Cloud DNS betrachtet die blockierten Endpunkte dann als nicht betriebsbereit. Wenn alle Endpunkte als nicht betriebsbereit zurückgegeben werden, stellt Cloud DNS sie trotzdem bereit, auch wenn sie nicht betriebsbereit sind.

Intervall der Systemdiagnose

Cloud DNS sendet regelmäßig Systemdiagnosen gemäß dem Systemdiagnoseintervall. Wenn das Intervall für die Systemdiagnose beispielsweise 30 Sekunden beträgt, sendet Cloud DNS alle 30 Sekunden eine Systemdiagnose.

Bei der Systemdiagnose für externe Cloud DNS-Endpunkte muss zwischen 30 und 300 Sekunden liegen.

Routingrichtlinien und Systemdiagnosen für gewichteten Round Robin

Cloud DNS unterstützt Gewichte von 0 bis 1.000, einschließlich dieser Werte. Wenn Systemdiagnosen enthalten sind, geschieht Folgendes:

  • Wenn Sie mehrere Ziele mit dem Gewicht „0“ konfigurieren, wird der Traffic gleichmäßig auf die Ziele verteilt.
  • Wenn Sie ein neues Ziel mit einer Gewichtung ungleich Null konfigurieren, wird es zum primären Ziel und der gesamte Traffic wird an dieses Ziel weitergeleitet.
  • Wenn Sie weitere Ziele mit nicht nullwertigen Gewichten hinzufügen, berechnet Cloud DNS bei jeder Anfrage dynamisch die Aufteilung des Traffics auf die Ziele und verteilt den Traffic entsprechend. Wenn Sie beispielsweise drei Ziele mit den Gewichten 0, 25 und 75 konfiguriert haben, erhält das Ziel mit dem Wert 0 keinen Traffic, das Ziel mit dem Wert 25 ein Viertel des Traffics und das verbleibende Ziel drei Viertel des eingehenden Traffics.
  • Wenn Systemdiagnosen mit Zielen mit einer Gewichtung ungleich Null, aber nicht mit Zielen mit einer Gewichtung von null verknüpft sind, werden die Ziele mit einer Gewichtung von null immer als fehlerfrei betrachtet. Wenn alle Einträge ungleich null fehlerhaft sind, gibt die mit null gewichteten Datensätze zurück.
  • Wenn Systemdiagnosen sowohl mit Einträgen mit einem Wert ungleich null als auch mit Einträgen mit dem Wert null verknüpft sind und alle Einträge die Systemdiagnosen nicht bestehen, gibt Cloud DNS alle Ziele mit einem Wert ungleich null zurück und ignoriert die Ziele mit dem Wert null.
  • Wenn Cloud DNS einen Gewichtungs-Bucket auswählt, der an den Anfragenden zurückgegeben werden soll (ein einzelnes Richtlinienelement), wird nur die IP-Adresse in diesem Gewichtungs-Bucket zurückgegeben. Wenn Sie nur eine IP-Adresse im Gewichtungs-Bucket angeben, wird nur diese Die IP-Adresse ist in der Antwort enthalten. Wenn sich mehr als eine IP-Adresse im Gewichts-Bucket befindet, gibt Cloud DNS alle IP-Adressen in einer zufälligen Reihenfolge zurück.

Routingrichtlinien und Systemdiagnosen für die Standortbestimmung

Bei Geolokalisierungs-Routingrichtlinien mit aktivierten Systemdiagnosen passiert Folgendes:

  • Wenn für eine Richtlinie mehrere IP-Adressen konfiguriert sind und für alle IP-Adressen eine Systemdiagnose ausgeführt wird, werden nur die fehlerfreien IP-Adressen zurückgegeben.
  • Wenn IP-Adressen mit und ohne Systemdiagnose verwendet werden und alle IP-Adressen mit Systemdiagnose fehlschlagen, gibt Cloud DNS alle IP-Adressen zurück, für die keine Systemdiagnose konfiguriert ist. In diesem Szenario erfolgt kein automatischer Failover in die nächste Region.

Logging für Systemdiagnosen

Cloud DNS unterstützt das Logging von Systemdiagnosen und protokolliert den Status Ihrer IP-Adressen mit aktivierter Systemdiagnose, wenn Sie den DNS-Namen abfragen, der sich auf diese IP-Adressen bezieht.

Das Logging der Systemdiagnose bietet Ihnen folgende Möglichkeiten:

  • Prüfen Sie, ob die Routingrichtlinien wie erwartet funktionieren. Beispiel:
    • Bei Richtlinien für die Standortbestimmung können Sie prüfen, ob die Richtlinien die richtige Region erkennen und den richtigen Datensatz mit Ressourceneinträgen zurückgeben.
    • Bei WRR-Richtlinien können Sie prüfen, ob die Richtlinien die IP-Adressen mit der richtigen Gewichtung zurückgeben.
  • Infrastrukturprobleme mit bestimmten Back-Ends und IP-Adressen identifizieren, die Fehler auftreten.
  • Fehlerbehebung, wenn bestimmte Back-Ends nie enthalten oder die einzigen sind die zurückgegeben werden.

Weitere Informationen finden Sie unter Logging von Systemdiagnosen.

Unterstützte Datensatztypen für DNS-Routingrichtlinien

DNS-Routingrichtlinien unterstützen nicht alle Eintragstypen, die von Cloud DNS unterstützt wird.

Die folgenden Datensatztypen werden unterstützt:

Datensatztyp Beschreibung
A IPv4-Adressen für interne (private Zone) und externe Systemdiagnosen (öffentliche Zone).
AAAA IPv6-Adressen für externe Systemdiagnosen (öffentliche Zone).
CNAME Kanonische Namen Systemdiagnosen werden nicht unterstützt.
MX Mail-Exchange-Einträge Systemdiagnosen werden nicht unterstützt.
SRV Host/Port (RFC 2782). Systemdiagnosen werden nicht unterstützt.
TXT Textdaten Systemdiagnosen werden nicht unterstützt.

Nächste Schritte