Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Failover für globale externe Application Load Balancer

Zum Schutz vor Infrastrukturausfällen oder Konfigurationsfehlern können Sie Failover-Strategien für globale externe Application Load Balancer entwerfen. Bei diesen Strategien werden regionale externe Application Load Balancer verwendet und der Traffic wird von einem globalen externen Application Load Balancer an sie weitergeleitet, um die Hochverfügbarkeit bei globalen Infrastrukturausfällen oder Konfigurationsfehlern aufrechtzuerhalten.

In einer Failover-Architektur stellen Sie einen primären Load Balancer und einen oder mehrere Backup-Load-Balancer bereit:

Der primäre Load Balancer ist der globale externe Application Load Balancer, der den Client-Traffic im Normalbetrieb verarbeitet.
Der Ersatz-Load-Balancer ist ein regionaler externer Application Load Balancer, der Traffic empfängt, wenn der primäre Load Balancer die Systemdiagnosen nicht besteht.

Failover und Failback sind automatische Prozesse zur Traffic-Weiterleitung:

Ein Failover tritt auf, wenn Cloud DNS einen Ausfall erkennt und Traffic vom primären Load Balancer an die Ersatz-Load Balancer weiterleitet.
Ein Failback erfolgt, wenn Cloud DNS dieses Routing umkehrt und Traffic an den primären Load Balancer weiterleitet, nachdem die Systemdiagnosen bestanden wurden.

In diesem Dokument wird der Failover von einem globalen externen Application Load Balancer zu regionalen Backup-Load-Balancern beschrieben. Wenn Sie ein Failover zwischen regionalen externen Application Load Balancern in verschiedenen Regionen konfigurieren möchten, finden Sie weitere Informationen unter Hochverfügbarkeit für regionale externe Application Load Balancer.

Warum regionale Load Balancer für Failover verwenden?

Regionale externe Application Load Balancer sind aufgrund der folgenden Eigenschaften als Failover-Load-Balancer für globale externe Application Load Balancer ideal:

Regionale externe Application Load Balancer sind in einzelnenGoogle Cloud -Regionen abgeschlossen und auch von allen globalen externen Application Load Balancer-Infrastrukturen isoliert, die in derselben Region ausgeführt werden.
Regionale externe Application Load Balancer und globale externe Application Load Balancer basieren beide auf Envoy-Proxys und verarbeiten Traffic auf ähnliche Weise.

Wenn Sie ein Global-auf-Regional-Failover für globale externe Application Load Balancer implementieren möchten, erstellen Sie zwei oder mehr regionale externe Application Load Balancer in den Regionen, in die der Traffic beim Failover geleitet werden soll.

Failover-Strategien

Sie können Failover für globale externe Application Load Balancer mit den folgenden Strategien implementieren:

Aktiv/Passiv (global-zu-regional-Failover): Sie stellen einen oder mehrere regionale externe Application Load Balancer ausschließlich für Sicherungszwecke bereit. Im stabilen Zustand wird Cloud DNS in die IP-Adresse des globalen externen Application Load Balancers aufgelöst. Wenn der globale Load Balancer ausfällt, leitet Cloud DNS den Traffic an die regionalen Backup-Load-Balancer weiter. Diese Konfiguration verwendet eine Failover-Routingrichtlinie von Cloud DNS.
Aktiv-aktiv (global-zu-regionaler Bypass): Ein globaler externer Application Load Balancer fungiert als Edge-Frontend und bietet Cloud CDN-Funktionen wie Edge-Caching, die Anfragen an regionale externe Application Load Balancer weiterleiten. Dazu werden Internet-Netzwerk-Endpunktgruppen (NEGs) mit voll qualifizierten Domainnamen (FQDNs) verwendet. Im stabilen Zustand fließt der Traffic sequenziell durch beide Load-Balancing-Ebenen. Dies kann mit einer Cloud DNS-Routingrichtlinie zur Standortbestimmung konfiguriert werden. Wenn der globale Load Balancer ausfällt, umgehen DNS-Routingrichtlinien die globale Ebene und leiten den Client-Traffic direkt an die regionalen Load Balancer weiter.

Wenn Ihre Architektur nicht auf kapazitätsbewusstes globales Backend-Load-Balancing angewiesen ist, sollten Sie die Aktiv-Aktiv-Strategie bevorzugen. Wenn Ihre Anwendung jedoch explizit globales Backend-Load-Balancing erfordert, um Traffic basierend auf der Backend-Kapazität auf Regionen zu verteilen und zu übertragen, implementieren Sie die Aktiv-Passiv-Strategie.

Vergleich von Failover-Strategien

In der folgenden Tabelle werden die Aktiv/Passiv- und Aktiv/Aktiv-Failover-Strategien verglichen:

Attribut „Strategie“	Aktiv/Passiv	Aktiv/Aktiv
Gleichmäßiger Trafficfluss	Client → Globaler externer Application Load Balancer → Backend	Client → Globaler externer Application Load Balancer → Regionaler externer Application Load Balancer → Backend
Traffic-Fluss im Fehlerzustand	Client → Regionaler externer Application Load Balancer → Backend. Der Dienst bleibt verfügbar, aber die Latenz kann aufgrund des Verlusts von Edge-Leistungsvorteilen höher sein.	Client → Regionaler externer Application Load Balancer → Backend (der globale externe Application Load Balancer wird umgangen). Der Dienst bleibt verfügbar, aber die Latenz kann aufgrund des Verlusts von Edge-Leistungsvorteilen höher sein.
Konfigurationsverwaltung	Erfordert die Synchronisierung unabhängiger Konfigurationen über globale und regionale Load Balancer hinweg.	Die globale Ebene erfordert nur eine minimale Konfiguration, da sich der Großteil der Anwendungslogik auf regionalen Load Balancern befindet. Sie müssen jedoch Edge-Sicherheitsrichtlinien (Cloud Armor) und die Konfiguration für die Verbindungsbeendigung (TLS-Zertifikate) auf beiden Ebenen duplizieren.
Zuverlässigkeitsprüfung	Der regionale externe Application Load Balancer befindet sich im Ruhezustand. Es werden regelmäßige Tests oder DNS-Teiltraffic empfohlen.	Der regionale externe Application Load Balancer wird kontinuierlich mit Traffic im stabilen Zustand getestet. Es werden regelmäßige Tests oder die Ausleitung von Teiltraffic direkt an den regionalen Load Balancer empfohlen.
Sicherheit bei der progressiven Bereitstellung	Konfigurationsänderungen am globalen externen Application Load Balancer gelten global. Änderungen an regionalen externen Application Load Balancern sind isoliert, werden aber nicht durch Traffic im stabilen Zustand getestet.	Sie können Änderungen am regionalen externen Application Load Balancer schrittweise, Region für Region, anwenden. Wenn eine Region ausfällt, leitet die globale Ebene den Traffic automatisch von ihr weg zu fehlerfreien Regionen.
Globales Backend-Load-Balancing	Unterstützt Der globale externe Application Load Balancer kann Traffic je nach Kapazität auf Backends in verschiedenen Regionen verteilen.	Begrenzt Der globale externe Application Load Balancer leitet den Traffic an den nächstgelegenen regionalen externen Application Load Balancer weiter. Der regionale Load Balancer verteilt den Traffic nur lokal und nicht basierend auf der Backend-Kapazität über Regionen hinweg.
Kosten und Abrechnung	Datenverarbeitungsgebühren fallen für eine einzelne Load-Balancing-Ebene an. Im stabilen Zustand entstehen Kosten durch den globalen externen Application Load Balancer. Gebühren für den regionalen externen Application Load Balancer fallen nur während Tests oder Failover-Ereignissen an.	Beide Load-Balancing-Ebenen generieren gleichzeitig Gebühren für die Datenverarbeitung, da der Traffic im stabilen Zustand sowohl durch globale als auch durch regionale Stufen fließt.
Empfohlener Anwendungsfall	Arbeitslasten, die erweitertes globales Backend-Load-Balancing und kapazitätsbasiertes Traffic-Spilling über Regionen hinweg erfordern.	Arbeitslasten, die auf regionale Isolation ausgelegt sind und die globale Ebene für Edge-Leistung und Caching verwenden.

Aktiv/Passiv-Strategie

In einer Aktiv/Passiv-Konfiguration stellen Sie unabhängige regionale externe Application Load Balancer in einer oder mehreren Regionen zusammen mit Ihrem primären globalen externen Application Load Balancer oder klassischen Application Load Balancer bereit.

So funktioniert das aktiv-passive Failover

Die folgende Einrichtung zeigt den Failover von einem globalen externen Application Load Balancer zu zwei regionalen externen Application Load Balancern, die sich in je einer in den beiden Regionen befindet, in denen der globale Load Balancer Backends bereitgestellt hat.

Failover von einem globalen externen Application Load Balancer zu zwei regionalen externen Application Load Balancern. — Failover von einem globalen externen Application Load Balancer zu zwei regionalen externen Application Load Balancern (zum Vergrößern klicken).

Das Aktiv/Passiv-Failover folgt diesem Workflow:

Steady State: Cloud DNS leitet den gesamten Client-Traffic an den globalen externen Application Load Balancer weiter.
Fehlererkennung: Google Cloud verwendet Systemdiagnosen, die mit drei Quellregionen konfiguriert sind, um zu ermitteln, ob der primäre Load Balancer fehlerfrei ist. Wenn Systemdiagnosen aus zwei oder mehr Quellregionen fehlschlagen, löst Cloud DNS ein Failover aus.
Failover: Cloud DNS-Failover-Routingrichtlinien leiten Client-Traffic direkt an die regionalen externen Application Load Balancer weiter. Auswirkungen auf die Latenz während des Failovers: Da regionale externe Application Load Balancer Verbindungen innerhalb einer bestimmten Google Cloud -Region beenden, kann es bei Clients, die weit von der Zielregion entfernt sind, zu erhöhter Latenz und Umlaufzeiten (RTT) kommen, während das Failover aktiv ist.
Failback: Nachdem die Systemdiagnosen wieder erfolgreich sind, stellt Cloud DNS den Traffic zum primären Load Balancer automatisch ohne Ausfallzeit wieder her, da beide Load Balancer Traffic verarbeiten.

Aktiv/Aktiv-Strategie (globaler zu regionaler Bypass)

In einer Aktiv-Aktiv-Strategie verwendet der globale externe Application Load Balancer eine Internet-FQDN-NEG (INTERNET_FQDN_PORT), um Traffic an regionale externe Application Load Balancer in zwei oder mehr Regionen zu senden.

So funktioniert die Aktiv/Aktiv-Bypass-Funktion

Das Aktiv/Aktiv-Failover folgt diesem Workflow:

Steady State: Der Traffic fließt vom Client zum globalen externen Application Load Balancer. Der globale Load Balancer verwendet eine Internet-FQDN-Netzwerk-Endpunktgruppe (NEG) vom Typ INTERNET_FQDN_PORT, um Traffic an die nächstgelegenen regionalen externen Application Load Balancer weiterzuleiten. Die regionalen Load Balancer leiten den Traffic dann an lokale Back-Ends weiter.
Fehlererkennung: Wenn im stabilen Zustand ein einzelner regionaler externer Application Load Balancer oder seine Region ausfällt, erkennt der globale externe Application Load Balancer den Fehler mithilfe der Cloud DNS-Systemdiagnoserichtlinie für die Internet-NEG. Der globale Load Balancer leitet den Traffic automatisch von der fehlerhaften Region zu fehlerfreien regionalen Load Balancern weiter.
Umgehung: Wenn der globale externe Application Load Balancer ausfällt, erkennen die Cloud DNS-Failover-Richtlinien den Ausfall und leiten den Traffic direkt an die regionalen externen Application Load Balancer weiter. Die globale Ebene wird dabei vollständig umgangen. Auswirkungen auf die Latenz während der Umgehung: Der globale externe Application Load Balancer bietet Edge-Leistungsvorteile, z. B. das Beenden von Verbindungen näher an den Nutzern und Edge-Caching. Wenn der Traffic den globalen Load Balancer umgeht, werden Clientverbindungen direkt mit den regionalen VIPs hergestellt. Dies kann die Verbindungslatenz und die RTT für geografisch entfernte Clients erhöhen.
Failback: Wenn der globale Load Balancer aufeinanderfolgende Systemdiagnosen besteht, gibt Cloud DNS die globale Anycast-VIP automatisch wieder in DNS-Antworten zurück und stellt die globale Edge-Routing-Stufe wieder her.

Konfiguration des primären Load Balancers prüfen

Prüfen Sie vor dem Konfigurieren des Failovers, ob der regionale externe Ersatz-Application Load Balancer die vom primären Load Balancer verwendeten Features unterstützt.

Im Aktiv/Passiv-Modus muss der regionale Backup-Load-Balancer ähnliche Features unterstützen, um den Traffic bei einem Ausfall nahtlos zu übernehmen.
Im Aktiv-Aktiv-Modus müssen die wichtigsten Routing- und Sicherheitsregeln direkt auf der regionalen Ebene konfiguriert werden. Globale Edge-Features wie Cloud CDN werden bei einem globalen Ausfall umgangen.

Funktion	Anforderungen an kompatible Geräte
Google Kubernetes Engine-Deployments	Verwenden Sie GKE Gateway, um sowohl den primären als auch den Ersatz-Load-Balancer bereitzustellen. Das liegt daran, dass mit GKE Gateway bereitgestellte Load Balancer mit diesem Failover-Mechanismus besser kompatibel sind als Load Balancer, die mit dem GKE-Ingress-Controller bereitgestellt werden. Der GKE-Ingress-Controller unterstützt nur den klassischen Application Load Balancer.
Cloud CDN	Regionale externe Application Load Balancer unterstützen Cloud CDN nicht. Bei einem Failover sind Vorgänge betroffen, die auf Cloud CDN angewiesen sind.
Cloud Armor	Wenn Sie Cloud Armor auf dem primären Load Balancer verwenden, konfigurieren Sie entsprechende regionale Cloud Armor-Sicherheitsrichtlinien auf den Ersatz-Load Balancern. Cloud Armor bietet im regionalen und globalen Bereich unterschiedliche Funktionen. Weitere Informationen finden Sie unter Regionale Cloud Armor-Sicherheitsrichtlinien und Globale Cloud Armor-Sicherheitsrichtlinien.
SSL-Zertifikate	Prüfen Sie, ob der vom primären Load Balancer verwendete SSL-Zertifikatstyp mit dem regionalen externen Ersatz-Application Load Balancer kompatibel ist. Sehen Sie sich die Unterschiede zwischen den SSL-Zertifikaten an, die für globale, regionale und klassische Load Balancer verfügbar sind. Weitere Informationen finden Sie unter Compute Engine-SSL-Zertifikate und Zertifikatmanager-SSL-Zertifikate.

Überlegungen zu regionalen Load Balancern

Konfigurieren und stellen Sie regionale externe Application Load Balancer in der Region bereit, in die der Traffic bei einem Fehler weitergeleitet werden soll.

Beachten Sie beim Konfigurieren des regionalen Load Balancers die folgenden Überlegungen zu Failover- oder Bypass-Architekturen:

Sie müssen die Features des regionalen externen Ersatz-Application Load Balancers so konfigurieren, dass sie dem primären Load Balancer so ähnlich wie möglich sind, damit der Traffic in beiden Bereitstellungen ähnlich verarbeitet wird.
- Globale externe Application Load Balancer. Regionale externe Application Load Balancer unterstützen die meisten Funktionen globaler externer Application Load Balancer, mit einigen Ausnahmen. Regionale Load Balancer unterstützen außerdem dieselben erweiterten Funktionen zur Trafficverwaltung wie globale Load Balancer. So lässt sich die Gleichwertigkeit zwischen dem primären und dem Ersatz-Load Balancer leichter erreichen.
- Klassische Application Load Balancer. Bei klassischen Application Load Balancern ist es schwieriger, die Funktionsparität zwischen dem primären und dem Ersatz-Load Balancer zu erreichen, da regionale externe Application Load Balancer Envoy-basierte Load Balancer sind, die Traffic anders verarbeitet. Testen Sie Failover und Failback gründlich, bevor Sie diese in der Produktion nutzen.
Die spezifischen Funktionen der regionalen, globalen und klassischen Application Load Balancer finden Sie auf der Seite Load-Balancer-Features im Vergleich.

Wir empfehlen die Verwendung eines Automatisierungsframeworks wie Terraform, um die Konsistenz der Load-Balancer-Konfigurationen sowohl in primären als auch in Sicherungsbereitstellungen zu erreichen und aufrechtzuerhalten.
Regionale externe Application Load Balancer unterstützen sowohl die Premium- als auch die Standard-Netzwerkdienststufen. Wenn die Latenz während des Failovers nicht Ihr Hauptanliegen ist, empfehlen wir, die regionalen externen Ersatz-Application Load Balancer in der Standardstufe einzurichten. Die Verwendung der Standardstufe bietet zusätzliche Isolation von der Premium-Stufe, die von globalen externen Application Load Balancern verwendet wird.
Achten Sie darauf, dass das Nur-Proxy-Subnetz ausreichend dimensioniert ist, um den erhöhten Traffic während eines Failovers zu bewältigen, ohne andere regionale Load Balancer in derselben Region und demselben Netzwerk zu beeinträchtigen. Weitere Informationen finden Sie unter Zusätzliche Nur-Proxy-Subnetzkapazität reservieren.

Informationen zum Konfigurieren eines regionalen externen Application Load Balancers finden Sie unter Regionalen externen Application Load Balancer mit VM-Instanzgruppen-Backends einrichten.

Zusätzliche Nur-Proxy-Subnetzkapazität reservieren

Alle regionalen Envoy-basierten Load Balancer in einer Region und einem VPC-Netzwerk verwenden denselben Pool an Envoy-Proxys. Bei einem Failover-Ereignis steigt die Proxy-Nutzung der regionalen externen Ersatz-Application Load Balancer, um den Failover-Traffic vom primären Load Balancer zu verarbeiten. Durch die Reservierung ausreichender Proxy-Kapazität wird sichergestellt, dass Failovers keine anderen regionalen Envoy-basierten Load Balancer in derselben Region und demselben Netzwerk beeinträchtigen.

Damit für die Ersatz-Load Balancer immer genügend Kapazität verfügbar ist, prüfen Sie die Größe Ihres Nur-Proxy-Subnetzes. Wir empfehlen, die geschätzte Anzahl der Proxys zu berechnen, die für die Verarbeitung des Traffics in einer bestimmten Region erforderlich sind, und die Kapazität bei Bedarf zu erhöhen. Weitere Informationen zu Proxy-Kapazitätslimits und Größenberechnungen finden Sie im Abschnitt Gebühr für Proxy-Instanz unter „Cloud Load Balancing – Preise“.

Wenn Sie mithilfe von DNS-Richtlinien den Traffic auf mehrere Ersatz-Load Balancer in verschiedenen Regionen aufteilen, müssen Sie dies bei der Schätzung der Proxyanforderungen pro Region und Netzwerk berücksichtigen. Mit einem größeren Nur-Proxy-Subnetz kannGoogle Cloud Ihrem Load Balancer bei Bedarf eine größere Anzahl von Envoy-Proxys zuweisen.

Sie können ein Nur-Proxy-Subnetz nicht auf dieselbe Weise erweitern wie bei einem primären Adressbereich (mit dem Befehl expand-ip-range). Stattdessen müssen Sie ein Nur-Proxy-Subnetz als Sicherung erstellen, das Ihren Anforderungen entspricht, und es dann zur aktiven Rolle hochstufen.

Informationen zum Ändern der Größe Ihres Nur-Proxy-Subnetzes finden Sie unter Größe oder Adressbereich eines Nur-Proxy-Subnetzes ändern.

Backends zwischen primären und Ersatz-Load-Balancern freigeben

Um eine vollständige infrastrukturelle Redundanz zu erreichen, müssen Sie sowohl auf Load Balancer- als auch auf Backend-Ebene für Redundanz sorgen. Das bedeutet, dass Sie Ihre regionalen externen Ersatz-Application Load Balancer mit Backends (Instanzgruppen oder Netzwerk-Endpunktgruppen) konfigurieren müssen, die sich nicht mit den primären Load-Balancern überschneiden.

Wenn Sie stattdessen dieselben Backends sowohl für den primären als auch für den Ersatz-Load-Balancer verwenden möchten, müssen Sie jeden regionalen externen Application Load Balancer in der Region erstellen, in der sich diese Backends befinden. Wenn das Autoscaling für die Instanzgruppen aktiviert ist, müssen Sie außerdem die folgenden Anforderungen erfüllen, damit ein ordnungsgemäßer Failover erfolgt:

Konfigurieren Sie das Autoscaling nur mit CPU-basierter Skalierung. Autoscaling auf Basis der Load-Balancer-Auslastung wird nicht unterstützt.
Sowohl die globalen als auch die regionalen Backend-Dienste dürfen nur den Balancing-Modus UTILIZATION verwenden. Verwenden Sie nicht den Balancing-Modus RATE, da Ihre Instanzen während des Failover-Prozesses die doppelte Menge an Traffic von globalen und regionalen Load Balancern erhalten können.
Konfigurieren Sie die Skalierungssteuerung so, dass der Autoscaler die Gruppe während der Ausfallzeit nicht vorzeitig herunterskaliert, wenn der Traffic vom globalen Load Balancer zum regionalen Load Balancer umgeleitet wird. Diese Ausfallzeit kann der Summe aus DNS-TTL (Time to Live) und dem konfigurierten Systemdiagnoseintervall entsprechen.

Wenn das Autoscaling nicht korrekt eingerichtet wird, kann das während des Failovers einen sekundären Ausfall bedingen, da der Traffic-Verlust vom globalen Load Balancer dazu führt, dass die Instanzgruppe schnell verkleinert wird, bevor der regionale Load Balancer übernimmt.

Aktiv/Passiv-Failover konfigurieren

So konfigurieren Sie ein Aktiv/Passiv-Failover:

Architekturüberlegungen prüfen: Bevor Sie Ressourcen erstellen, sollten Sie die Überlegungen für regionale Load Balancer prüfen, um die Featurekompatibilität, die Proxykapazität und die Anforderungen für das Autoscaling von freigegebenen Backends zu prüfen.
Primären Load Balancer konfigurieren: Richten Sie Ihren globalen externen Application Load Balancer mit Backend-Diensten ein, die auf eine oder mehrere Regionen verteilt sind. Weitere Informationen zum Konfigurieren eines globalen externen Application Load Balancers finden Sie unter Globalen externen Application Load Balancer einrichten.
Prüfen Sie die Konfiguration des primären Load Balancers: Bestätigen Sie, dass die vom primären Load Balancer verwendeten Funktionen (z. B. Sicherheitsfunktionen, Funktionen zur Traffic-Verwaltung und Routingfunktionen sowie Cloud CDN) auch für den regionalen externen Ersatz-Application Load Balancer verfügbar sind. Sind keine ähnlichen Features verfügbar, ist dieser Load Balancer möglicherweise kein guter Kandidat für ein Failover.
Regionale externe Application Load Balancer zur Sicherung konfigurieren: Richten Sie unabhängige regionale externe Application Load Balancer in den Regionen ein, in die der Traffic beim Failover geleitet werden soll. Informationen zum Konfigurieren eines regionalen externen Application Load Balancers finden Sie unter Regionalen externen Application Load Balancer mit VM-Instanzgruppen-Backends einrichten.
DNS-Routing und Systemdiagnosen konfigurieren: Erstellen Sie eine Systemdiagnose für den primären Load Balancer und konfigurieren Sie eine Cloud DNS-Failover-Routingrichtlinie, um Ausfälle zu erkennen und Clienttraffic an regionale Ersatz-Load-Balancer weiterzuleiten.

Aktiv/Aktiv-Bypass konfigurieren

So konfigurieren Sie die Aktiv-Aktiv-Architektur:

Architekturüberlegungen prüfen: Bevor Sie Ressourcen erstellen, sollten Sie die Überlegungen für regionale Load Balancer prüfen, um die Featurekompatibilität zu überprüfen und sicherzustellen, dass die Kapazität Ihres Nur-Proxy-Subnetzes den Traffic im Normalbetrieb und im Failover-Fall bewältigen kann.
Regionale externe Application Load Balancer konfigurieren: Bevor Sie regionale Load Balancer konfigurieren, lesen Sie die Informationen unter Featurekompatibilität und Einschränkungen. Stellen Sie regionale externe Application Load Balancer in zwei oder mehr Regionen mit Ihren Backend-Diensten, externen IP-Adressen, SSL-Zertifikaten und regionalen Cloud Armor-Sicherheitsrichtlinien bereit. Eine Einrichtungsanleitung finden Sie unter Regionalen externen Application Load Balancer mit VM-Instanzgruppen-Backends einrichten.
DNS für regionale Load Balancer konfigurieren: Erstellen Sie einen DNS-Eintrag (z. B. regional-api.example.com), der auf die externen IP-Adressen Ihrer regionalen externen Application Load Balancer verweist. Verwenden Sie dazu eine Routingrichtlinie für die Standortbestimmung oder Latenz. Aktivieren Sie die DNS-Systemdiagnose für diesen Eintrag, um einen Ausfall in einer bestimmten Region zu erkennen und den Traffic automatisch von dieser Region zu anderen fehlerfreien Regionen weiterzuleiten.
Globalen externen Application Load Balancer konfigurieren: Reservieren Sie eine globale externe IP-Adresse und erstellen Sie eine globale Internet-Netzwerk-Endpunktgruppe (NEG) vom Typ INTERNET_FQDN_PORT. Fügen Sie der Internet-NEG einen Endpunkt hinzu, der auf den FQDN des regionalen DNS-Eintrags verweist, z. B. regional-api.example.com. Konfigurieren Sie einen Backend-Dienst für den globalen externen Application Load Balancer, hängen Sie die Internet-NEG an und aktivieren Sie bei Bedarf Cloud CDN oder Cloud Armor. Konfigurieren Sie die URL-Zuordnung, den Ziel-HTTP(S)-Proxy und die globale Weiterleitungsregel.
DNS für Failover und Systemdiagnosen konfigurieren: Erstellen Sie den DNS-Eintrag für den Hauptdienst (z. B. api.example.com) mit einer FAILOVER-Routingrichtlinie. Achten Sie darauf, dass der Eintragssatz einen primären Endpunkt hat, der auf die IP-Adresse des globalen externen Application Load Balancers verweist, und Backup-Endpunkte, die auf die externen IP-Adressen der regionalen externen Application Load Balancer verweisen. Konfigurieren Sie eine DNS-Systemdiagnose, um den globalen externen Application Load Balancer zu überwachen.

Best Practices

Beachten Sie die folgenden Best Practices, wenn Sie den Cloud DNS-Eintrag und die Systemdiagnosen konfigurieren:

Ausfalldauer berechnen: Die Zeit, die der Traffic für das Failover vom primären zum Ersatz-Load-Balancer benötigt, hängt vom DNS-TTL-Wert, dem Intervall der Systemdiagnose und dem Fehlerschwellenwert der Systemdiagnose ab:

Mit Cloud DNS von Google kann die Obergrenze für diesen Zeitraum mit der folgenden Formel berechnet werden:
```
Duration of outage = DNS TTL + Health Check Interval * Unhealthy Threshold
```
Legen Sie die DNS-TTL auf 30–60 Sekunden fest. Höhere TTL-Werte führen zu längeren Failover-Zeiten, da Clients im Internet weiterhin auf den primären externen Application Load Balancer zugreifen, auch nachdem das DNS ein Failover zum regionalen externen Ersatz-Application Load Balancer durchgeführt hat.
Schwellenwerte für die Systemdiagnose konfigurieren: Legen Sie die Parameter für die Schwellenwerte „Fehlerfrei“ und „Fehlerhaft“ fest, um Failovers zu vermeiden, die durch vorübergehende Netzwerkfehler verursacht werden. Höhere Schwellenwerte erhöhen die Zeit, die für das Failover des Traffics zu Ersatz-Load-Balancern benötigt wird.
Teiltraffic zur Validierung verwenden: Konfigurieren Sie das Flag --backup-data-trickle-ratio, um kontinuierlich einen kleinen Prozentsatz des Traffics an die Ersatz-Load-Balancer zu senden, auch wenn die primären Load-Balancer fehlerfrei sind. So wird sichergestellt, dass die Sicherungsinfrastruktur aktiv und bereit ist, Traffic zu verarbeiten. Sie können den Prozentsatz des Traffics, der an die Ersatz-Load-Balancer gesendet wird, als Bruch von 0 bis 1 konfigurieren. Der typische Wert ist 0, 1.Mit Cloud DNS können Sie jedoch 100 % des Traffics an die VIP-Ersatzadressen senden, um einen Failover manuell auszulösen.
Failover und Failback regelmäßig testen: Nehmen Sie Failover-Tests in Ihren Notfallwiederherstellungsplan auf. Prüfen Sie sowohl allmähliche als auch plötzliche Traffic-Verschiebungen vom primären zum Ersatz-Load Balancer und prüfen Sie, ob der Traffic nach dem Failback reibungslos zum primären Load Balancer zurückgeleitet wird.