Failover für externe Application Load Balancer

Vorschau

Dieses Produkt oder diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Funktionen sind unverändert verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Auf dieser Seite wird beschrieben, wie der Failover für externe Application Load Balancer funktioniert. Die Failover-Konfiguration umfasst zwei Load-Balancer: einen primären Load-Balancer und einen Sicherungs-Load-Balancer. In diesem Artikel ist der primäre Load-Balancer der Load-Balancer, für den Sie ein Failover konfigurieren möchten. Der Sicherungs-Load Balancer ist der Load Balancer, der Verbindungen empfängt, wenn der primäre Load Balancer Systemdiagnosen nicht besteht.

Failover und Failback sind die automatischen Prozesse, die Traffic an und von einem Load-Balancer weiterleiten. Der Vorgang, bei dem Cloud DNS einen Ausfall erkennt und den Traffic vom primären Load-Balancer an den Backup-Load-Balancer weiterleitet, wird als failover bezeichnet. Der Vorgang, bei dem Cloud DNS dies umkehrt und Traffic an den primären Load-Balancer weiterleitet, wird als Failback bezeichnet.

So funktioniert der Failover

Für das Global-auf-Regional-Failover für externe Application Load Balancer werden zwei oder mehr regionale externe Application Load Balancer in den Regionen erstellt, in die der Traffic beim Failover geleitet werden soll. Nur regionale externe Application Load Balancer können als Ersatz-Load Balancer verwendet werden. Regionale externe Application Load Balancer sind nicht nur in einzelnen Google Cloud-Regionen abgeschlossen, sondern auch von allen globalen externen Application Load Balancer- oder klassischen Application Load Balancer-Infrastrukturen isoliert, die in derselben Region ausgeführt werden.

Regionale externe Application Load Balancer sind als Failover-Load-Balancer für globale externe Application Load Balancer ideal, da beide Elemente auf Envoy-Proxys basieren und Traffic auf sehr ähnliche Weise verarbeiten. Dies steht im Gegensatz zu klassischen Application Load Balancern, die wichtige Unterschiede bei der Verarbeitung des Traffics haben.

Zusammenfassend werden die folgenden Failover-Szenarien unterstützt:

• Von einem globalen externen Application Load Balancer zu einem regionalen externen Application Load Balancer
• Von einem regionalen externen Application Load Balancer zu einem regionalen externen Application Load Balancer
• Von einem klassischen Application Load Balancer zu einem regionalen externen Application Load Balancer

Wichtig: Die auf dieser Seite beschriebene Failover-Konfiguration ist eine Aktiv/Passiv-Failover-Konfiguration, bei der Traffic auf einen Sicherungs-Load-Balancer weitergeleitet wird, falls der primäre Load-Balancer nicht verfügbar ist. Dies wird mithilfe einer Failover-Routingrichtlinie von Cloud DNS erreicht. Regionale externe Application Load Balancer unterstützen auch Aktiv/Aktiv-Konfigurationen, bei denen Sie mehrere Load Balancer in verschiedenen Regionen bereitstellen können, die alle gleichzeitig Traffic verarbeiten. Dies kann mithilfe einer Routingrichtlinie für die Standortbestimmung von Cloud DNS konfiguriert werden. Weitere Informationen finden Sie unter Hochverfügbarkeit für regionale externe Application Load Balancer.

Failover- und Failback-Workflow

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 (zum Vergrößern klicken).

In den folgenden Abschnitten wird ein typischer Workflow unter Einsatz der verschiedenen Komponenten beschrieben, die an einer Failover-Konfiguration beteiligt sind.

1. Fehler im primären Load-Balancer erkennen

   Google Cloud verwendet Systemdiagnosen, um zu ermitteln, ob Ihr primärer externer Application Load Balancer fehlerfrei arbeitet. Sie konfigurieren diese Systemdiagnosen so, dass Proben aus drei Quellregionen gesendet werden. Diese drei Quellregionen müssen für die Regionen repräsentativ sein, von denen aus Ihre Clients auf den Load-Balancer zugreifen. Wenn Sie beispielsweise einen globalen externen Application Load Balancer haben und der Großteil Ihres Client-Traffics aus Nordamerika und Europa stammt, können Sie Proben aus zwei Regionen in Nordamerika und einer Region in Europa konfigurieren.

   Wenn Systemdiagnosen aus zwei oder mehr dieser Regionen fehlschlagen, wird ein Failover auf den regionalen externen Ersatz-Application Load Balancer ausgelöst.

   Zusätzliche Hinweise:

   • Sie müssen beim Erstellen der Systemdiagnose genau drei Quellregionen angeben. Nur globale Systemdiagnosen können Quellregionen angeben.
   • HTTP-, HTTPS- und TCP-Systemdiagnosen werden unterstützt.
   • Die Systemdiagnoseprüfungen stammen von einem Point of Presence (PoP) im Internet unweit der konfigurierten Google Cloud-Quellregion.

2. Traffic an Ersatz-Load Balancer weiterleiten

   Wenn die Systemdiagnosen des primären Load Balancers fehlschlagen, verwendet Google Cloud Cloud DNS-Failover-Routingrichtlinien, um zu bestimmen, wie Traffic an die Ersatz-Load Balancer weitergeleitet wird.

   Die Dauer des Ausfalls oder die Zeit, die für den Traffic vom primären zu den Ersatz-Load-Balancern benötigt wird, wird durch den DNS-TTL-Wert, das Systemdiagnoseintervall und den Fehler-Schwellenwert der Systemdiagnose bestimmt. Empfohlene Einstellungen finden Sie unter Best Practices.

3. Failover zum primären Load Balancer

   Sobald die Systemdiagnosen wieder bestanden werden, erfolgen Failbacks an den primären Load-Balancer automatisch. Während eines Failbacks ist keine Ausfallzeit zu erwarten, da sowohl der Ersatz- als auch der primäre Load-Balancer Traffic verarbeiten.

4. Failover regelmäßig testen

   Wir empfehlen, den Failover-Workflow im Rahmen Ihres Notfallplans regelmäßig zu testen. Testen Sie sowohl allmähliche als auch sofortige Traffic-Verschiebungen vom primären zum Ersatz-Load Balancer. Nachdem Sie geprüft haben, ob der Failover funktioniert, lösen Sie einen Failback aus, um zu prüfen, ob der Traffic wie erwartet an den primären Load Balancer zurückgeleitet wird.

Failover konfigurieren

So konfigurieren Sie einen Failover:

1. Prüfen Sie die vorhandene Konfiguration des primären Load Balancers und prüfen Sie, ob die vom primären Load Balancer verwendeten Funktionen (z. B. Sicherheitsfunktionen, Funktionen zur Traffic-Verwaltung und Routingfunktionen sowie 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.
2. Erstellen Sie den regionalen externen Ersatz-Application Load Balancer mit einer Konfiguration, die den primären Load Balancer so weit wie möglich widerspiegelt.
3. Erstellen Sie die Systemdiagnose und die DNS-Routingrichtlinie, um Ausfälle zu erkennen und den Traffic während des Failover vom primären zum Ersatz-Load Balancer weiterzuleiten.

Konfiguration des primären Load-Balancers prüfen

Prüfen Sie zuerst, ob der regionale externe Ersatz-Application Load Balancer alle Features unterstützt, die derzeit mit Ihrem primären Load-Balancer genutzt werden.

Sehen Sie sich die folgenden Unterschiede an, um Störungen des Traffics zu vermeiden:

• GKE-Deployments. GKE-Nutzer sollten beachten, 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. Dies liegt daran, dass GKE Gateway die Konfiguration sowohl globaler als auch regionaler externer Application Load Balancer unterstützt. Der GKE-Ingress-Controller unterstützt jedoch nur klassische Application Load Balancer.

  Die besten Ergebnisse erzielen Sie, wenn Sie GKE Gateway zum Bereitstellen des primären und des Ersatz-Load-Balancers verwenden.

• Cloud CDN. Regionale externe Application Load Balancer unterstützen Cloud CDN nicht. Bei einem Ausfall sind daher auch alle Vorgänge betroffen, die auf Cloud CDN angewiesen sind. Für eine bessere Redundanz empfehlen wir, eine CDN-Lösung eines Drittanbieters zu konfigurieren, die als Fallback für Cloud CDN dienen kann.

• Google Cloud Armor. Wenn Sie Google Cloud Armor als primären Load Balancer verwenden, müssen Sie die verwendeten Google Cloud Armor-Funktionen auch für den regionalen externen Ersatz-Application Load Balancer konfigurieren. Google Cloud Armor bietet unterschiedliche Funktionen auf regionaler und globaler Ebene. Weitere Informationen finden Sie in den folgenden Abschnitten der Dokumentation zu Google Cloud Armor:

  • Regionale Google Cloud Armor-Sicherheitsrichtlinien
  • Globale Google Cloud Armor-Sicherheitsrichtlinien

• SSL-Zertifikate. Wenn Sie ein gemeinsames SSL-Zertifikat für den primären und den Ersatz-Load-Balancer verwenden möchten, prüfen Sie, ob der Typ des SSL-Zertifikats, das mit dem primären Load-Balancer verwendet wird, mit dem regionalen externen Ersatz-Application-Load-Balancer kompatibel ist. Machen Sie sich mit den Unterschieden zwischen den SSL-Zertifikaten vertraut, die für globale, regionale und klassische Load-Balancer verfügbar sind. Details zu diesen Schritten finden Sie in den folgenden Abschnitten.

  • Compute Engine-SSL-Zertifikate
  • Certificate Manager-SSL-Zertifikate

• Backend-Buckets. Regionale externe Application Load Balancer unterstützen Cloud Storage-Buckets nicht als Backends. Sie können kein Failover für Load Balancer mit Backend-Buckets einrichten.

Ersatz-Load Balancer konfigurieren

Der Ersatz-Load-Balancer ist ein regionaler externer Application Load Balancer, den Sie in der Region konfigurieren, an die der Traffic bei einem Fehler weitergeleitet werden soll.

Beachten Sie beim Konfigurieren des Ersatz-Load Balancers die folgenden Hinweise:

• 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 mit wenigen Ausnahmen die meisten Funktionen der globalen externen Application Load Balancer. 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.

  Informationen zu den 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 für Konsistenz bei den Load Balancer-Konfigurationen sowohl in primären als auch in Sicherungsbereitstellungen zu sorgen.

• Wir empfehlen, regionale externe Application Load Balancer in allen Regionen einzurichten, in denen Sie Backends haben. Beispiel: Beim Failover von einer globalen Bereitstellung mit Instanzgruppen in fünf Regionen zu regionalen Load Balancern in nur drei Regionen besteht die Gefahr, dass Ihre Backend-Dienste in diesen drei Regionen überlastet werden, während die Backend-Dienste in den verbleibenden zwei Regionen inaktiv sind.

  Außerdem empfehlen wir, Cloud DNS so zu konfigurieren, dass beim Umleiten von Failover-Traffic von einem primären globalen Load Balancer an diese regionalen Ersatz-Load Balancer gewichtete Round-Robin-Richtlinien verwendet werden. Weisen Sie jedem Ersatz-Load-Balancer Gewichtungen zu. Berücksichtigen Sie dazu die maximalen Größen der Backend-Instanzgruppen in verschiedenen Regionen.

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

• Wenn Sie dieselben Backends sowohl für den primären als auch für den Ersatz-Load Balancer verwenden möchten, erstellen Sie den regionalen externen Application Load Balancer in der Region, in der sich die Backends befinden. Wenn Sie das Autoscaling für die Back-End-Instanzgruppen aktiviert haben, müssen Sie die Anforderungen für die Freigabe von Backends über die Bereitstellungen hinweg erfüllen.

• Reservieren Sie bei Bedarf zusätzliche Envoy-Proxys für regionale externe Application Load Balancer, um sicherzustellen, dass bei einem Failover keine anderen Load-Balancer-Bereitstellungen in derselben Region beeinträchtigt werden. 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 steigt die Proxynutzung der regionalen externen Application Load Balancer, um den Failover-Traffic vom primären Load Balancer zu verarbeiten. Damit für die Ersatz-Load Balancer immer genügend Kapazität verfügbar ist, empfehlen wir, die Größe Ihres Nur-Proxy-Subnetzes zu prüfen. Wir empfehlen Ihnen, die geschätzte Anzahl der Proxys zu berechnen, die zum Bewältigen des Traffics in einer bestimmten Region erforderlich sind, und die Kapazität bei Bedarf zu erhöhen. Dadurch wird auch sichergestellt, dass Failovers keine anderen regionalen Envoy-basierten Load-Balancer in derselben Region und demselben Netzwerk beeinträchtigen.

Im Allgemeinen kann ein regionaler externer Application Load Balancer-Proxy folgende Elemente verarbeiten:

• 600 (HTTP) oder 150 (HTTPS) neue Verbindungen pro Sekunde
• 3.000 aktive Verbindungen
• 1.400 Anfragen pro Sekunde

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. Bei einem größeren Nur-Proxy-Subnetz kann Google 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 aber doch eine Backend-Instanzgruppe mit dem primären und dem Ersatz-Load Balancer nutzen möchten und die automatische Skalierung für die Instanzgruppen aktiviert ist, müssen die folgenden Anforderungen erfüllt werden, damit ein ordnungsgemäßer Failover erfolgt:

• Das Autoscaling muss mit mehreren Signalen eingerichtet sein. Wir empfehlen eine Kombination aus CPU-Skalierungssignalen und Load-Balancer-Auslastungssignalen für Instanzgruppen.
• Sowohl die globalen als auch die regionalen Backend-Dienste dürfen nur den Balancing-Modus UTILIZATION verwenden. Die Verwendung des Balancing-Modus RATE wird nicht empfohlen, da Ihre Instanzen während des Failover-Prozesses die doppelte Menge an Traffic von globalen und regionalen Load Balancern erhalten können.
• Die Skalierungsteuerung muss so konfiguriert werden, 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 so hoch sein wie die Summe der DNS-TTL plus dem konfigurierten Systemdiagnoseintervall.

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.

Cloud DNS und Systemdiagnosen konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie mit Cloud DNS und Google Cloud-Systemdiagnosen Ihre Cloud Load Balancing-Umgebung so konfigurieren, dass Ausfälle erkannt und Traffic an die Ersatz-Load-Balancer weitergeleitet werden.

Führen Sie die folgenden Schritte aus, um die erforderlichen Systemdiagnose- und Routingrichtlinien zu konfigurieren:

1. Erstellen Sie eine Systemdiagnose für die IP-Adresse der Weiterleitungsregel des primären Load-Balancers.

   gcloud beta compute health-checks create http HEALTH_CHECK_NAME \
       --global \
       --source-regions=SOURCE_REGION_1,SOURCE_REGION_2,SOURCE_REGION_3 \
       --use-serving-port \
       --check-interval=HEALTH_CHECK_INTERVAL \
       --healthy-threshold=HEALTHY_THRESHOLD \
       --unhealthy-threshold=UNHEALTHY_THRESHOLD \
       --request-path=REQUEST_PATH
   

   Ersetzen Sie Folgendes:

   • HEALTH_CHECK_NAME: der Name der Systemdiagnose
   • SOURCE_REGION: Die drei Google Cloud-Regionen, von denen aus Systemdiagnosen ausgeführt werden. Sie müssen genau drei Quellregionen angeben.
   • HEALTH_CHECK_INTERVAL: Die Zeitspanne in Sekunden vom Start einer Prüfung, die von einem Prober aus erfolgt, bis zum Start der nächsten Prüfung, die vom selben Prober aus erfolgt. Der unterstützte Mindestwert beträgt 30 Sekunden. Empfohlene Werte finden Sie unter Best Practices.
   • HEALTHY_THRESHOLD und UNHEALTHY_THRESHOLD: Die Anzahl der sequenziellen Testdurchläufe, die bestanden werden oder fehlschlagen müssen, damit die VM-Instanz als fehlerfrei oder fehlerhaft eingestuft wird. Wenn einer der Parameter nicht angegeben ist, verwendet Google Cloud den Standardschwellenwert 2.
   • REQUEST_PATH: Der URL-Pfad, an den Google Cloud Prüfungsanfragen zur Systemdiagnose sendet. Wenn Sie diesen Parameter weglassen, sendet Google Cloud Prüfanfragen an den Stammpfad „/“. Wenn die zu prüfenden Endpunkte privat sind, was für IP-Adressen externer Weiterleitungsregeln nicht typisch ist, können Sie diesen Pfad auf /afhealthz festlegen.

2. Erstellen Sie einen Cloud DNS-Eintragssatz in Cloud DNS und wenden Sie eine Routingrichtlinie darauf an. Die Routing-Richtlinie muss so konfiguriert sein, dass Ihr Domainname entweder in die IP-Adresse der Weiterleitungsregel des primären Load Balancers oder (bei einem Systemdiagnosefehler) in eine der IP-Adressen der Weiterleitungsregel für Ersatz-Load Balancer aufgelöst wird.

   gcloud beta dns record-sets create DNS_RECORD_SET_NAME \
       --ttl=TIME_TO_LIVE \
       --type=RECORD_TYPE \
       --zone="MANAGED_ZONE_NAME" \
       --routing-policy-type=FAILOVER \
       --routing-policy-primary-data=PRIMARY_LOAD_BALANCER_FORWARDING_RULE \
       --routing-policy-backup-data_type=GEO \
       --routing-policy-backup-data="BACKUP_REGION_1=BACKUP_LOAD_BALANCER_1_IP_ADDRESS[;BACKUP_REGION_2=BACKUP_LOAD_BALANCER_2_IP_ADDRESS;BACKUP_REGION_3=BACKUP_LOAD_BALANCER_3_IP_ADDRESS]" \
       --health-check=HEALTH_CHECK_NAME \
       --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO
   

   Ersetzen Sie Folgendes:

   • DNS_RECORD_SET_NAME ist der DNS- oder Domainname des hinzuzufügenden Datensatzes, z. B. test.example.com.
   • TIME_TO_LIVE ist die Gültigkeitsdauer (TTL, Time To Live) für den Datensatz in Sekunden. Empfohlene Werte finden Sie unter Best Practices.
   • RECORD_TYPE ist der Datensatztyp, z. B. A.
   • MANAGED_ZONE_NAME ist der Name der verwalteten Zone, deren Datensätze Sie verwalten möchten, z. B. my-zone-name.
   • PRIMARY_LOAD_BALANCER_FORWARDING_RULE ist der Name der Weiterleitungsregel des primären Load Balancers
   • BACKUP_REGION sind die Regionen, in denen die Ersatz-Load Balancer bereitgestellt sind
   • BACKUP_LOAD_BALANCER_IP_ADDRESS meint die IP-Adressen der Weiterleitungsregel für die Ersatz-Load Balancer für die einzelnen Regionen
   • BACKUP_DATA_TRICKLE_RATIO ist das Traffic-Ratio, das an die Ersatz-Load-Balancer gesendet wird, auch wenn der primäre Load-Balancer fehlerfrei ist. Das Verhältnis muss zwischen 0 und 1 liegen, z. B. 0,1. Der Standardwert ist 0.

Best Practices

Im Folgenden finden Sie einige Best Practices, die Sie beim Konfigurieren des Cloud DNS-Eintrags und der Systemdiagnosen beachten sollten:

• Die Zeit, die der Traffic für das Failover vom primären zum Ersatz-Load Balancer benötigt (d. h. die Dauer der Ausfallzeit), 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
  

  Für die Failover-Konfiguration empfehlen wir, die DNS-TTL auf 30 bis 60 Sekunden festzulegen. Höhere TTLs führen zu längeren Ausfallzeiten, 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.

• Konfigurieren Sie die Parameter für die Schwellenwerte "Fehlerfrei" und "Fehlerhaft" in den Systemdiagnosen, um unnötige Failovers zu vermeiden, die durch vorübergehende Fehler verursacht werden. Höhere Schwellenwerte erhöhen die Zeit, die für das Failover des Traffics zu Ersatz-Load-Balancern benötigt wird.

• Damit die Failover-Einrichtung wie erwartet funktioniert, können Sie Ihre DNS-Routingrichtlinie so konfigurieren, dass immer ein kleiner Prozentsatz des Traffics an die Ersatz-Load Balancer gesendet wird, auch wenn die primären Load Balancer fehlerfrei sind. Dazu können Sie beim Erstellen des DNS-Eintragssatzes den Parameter --backup-data-trickle-ratio verwenden.

  Sie können den Prozentsatz des Traffics, der an die Sicherung gesendet wird, als Bruchteil 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.