Hochverfügbarkeit für regionale externe Application Load Balancer

Auf dieser Seite wird beschrieben, wie Sie eine hochverfügbare Bereitstellung mit regionalen externen Application Load Balancern konfigurieren. Stellen Sie mehrere einzelne regionale externe Application Load Balancer in Regionen bereit, die den Traffic Ihrer Anwendung am besten unterstützen, um Hochverfügbarkeit zu erreichen. Dies funktioniert, da regionale externe Application Load Balancer in verschiedenen Regionen nicht nur voneinander isoliert sind, sondern auch von jeder globalen externen Application Load Balancer- oder klassischen Application Load Balancer-Infrastruktur, die in der gleichen Region läuft.

Verwenden Sie eine Cloud DNS-Routingrichtlinie für die Standortbestimmung, um Traffic an zwei oder mehr Load Balancer in verschiedenen Regionen weiterzuleiten. Die Richtlinie leitet den Traffic basierend auf dem Ursprung der Clientanfrage an die nächstgelegene verfügbare Region weiter. Wir empfehlen außerdem die Verwendung von Systemdiagnosen, damit Google Cloud regionale Ausfälle erkennen und den Traffic nur an die fehlerfreien Load-Balancer weiterleiten kann.

Die folgende Beispieleinrichtung zeigt zwei regionale externe Application Load Balancer in zwei verschiedenen Regionen.

Hochverfügbarkeit mit zwei regionalen externen Application Load Balancern (zum Vergrößern klicken)

In den folgenden Abschnitten wird ein typischer Workflow mit den verschiedenen Komponenten beschrieben, die an dieser Konfiguration beteiligt sind.

Regionale Fehler mithilfe von Systemdiagnosen erkennen

Google Cloud verwendet Systemdiagnosen, um zu ermitteln, ob Ihre Load-Balancer fehlerfrei sind. Sie konfigurieren diese Systemdiagnosen so, dass Prüfungen aus drei Quellregionen gesendet werden. Diese drei Quellregionen müssen für die Regionen repräsentativ sein, von denen aus Ihre Clients auf die Load-Balancer zugreifen. Wenn Sie beispielsweise einen regionalen externen Application Load Balancer haben, bei dem der Großteil Ihres Client-Traffics aus Nordamerika und Europa stammt, können Sie Prüfungen aus zwei oder mehr Regionen in Nordamerika und Prüfungen aus zwei oder mehr Regionen in Europa verwenden.

Zusätzliche Hinweise:
- Sie müssen beim Erstellen der Systemdiagnose genau drei Quellregionen angeben. Nur globale Systemdiagnosen können Quellregionen angeben.
- Es werden HTTP-, HTTPS- und TCP-Systemdiagnosen unterstützt.
- Die Systemdiagnoseprüfungen stammen von einem Point of Presence (PoP) im Internet unweit der konfigurierten Google Cloud-Quellregion.
Traffic an fehlerfreie Load Balancer weiterleiten

In Google Cloud wird eine Cloud DNS-Routingrichtlinie für die Standortbestimmung verwendet, um Traffic an die Load Balancer weiterzuleiten. Wenn alle Load Balancer fehlerfrei sind, leitet Cloud DNS den Traffic an den Load Balancer weiter, der dem Ursprung der Clientanfrage geografisch am nächsten ist.

Wenn ein Load Balancer in einer bestimmten Region fehlerhafte Systemdiagnosen durchführt, wird der Traffic an verfügbare fehlerfreie Load Balancer in anderen Regionen weitergeleitet.
Failover auf die Verwendung aller Load Balancer

Failback erfolgt automatisch, wenn die Systemdiagnosen wieder bestanden werden. Während des Failbacks sind keine Ausfallzeiten zu erwarten, da alle verfügbaren Load-Balancer Traffic bereitstellen.

Regionenübergreifendes Load Balancing konfigurieren

Führen Sie die folgenden Schritte aus, um eine regionsübergreifende Bereitstellung zu konfigurieren, die eine hohe Verfügbarkeit ermöglicht:

Erstellen Sie regionale externe Application Load Balancer in den Regionen, aus denen Sie den besten Support-Traffic für Ihre Anwendung ermitteln. Jeder dieser Load-Balancer muss die gleiche Traffic-Verwaltung und die gleiche Sicherheitskonfiguration haben.
Erstellen Sie die Systemdiagnose und die DNS-Routing-Richtlinie, um den Traffic zu den Load Balancern auf der Grundlage des Client-Standorts zu leiten und um den Traffic im Falle eines Ausfalls von einem fehlerhaften Load Balancer wegzuleiten.

Load Balancer in mehreren Regionen erstellen

Beachten Sie beim Konfigurieren Ihrer zusätzlichen redundanten Load-Balancer die folgenden Überlegungen:

Konfigurieren Sie alle regionalen externen Application Load Balancer mit ähnlichen Funktionen, damit der Traffic unabhängig davon, welcher Load Balancer die Anfrage verarbeitet, einheitlich verarbeitet wird. Sie müssen beispielsweise dafür sorgen, dass Sie denselben SSL-Zertifikatstyp, dieselben Google Cloud Armor-Richtlinien und dieselben Einstellungen zur Trafficverwaltung für alle regionalen externen Application Load Balancer verwenden.

Wir empfehlen die Verwendung eines Automatisierungs-Frameworks wie Terraform, um Konsistenz von Load-Balancer-Konfigurationen für die verschiedenen regionalen Bereitstellungen zu erreichen und zu wahren.
Wir empfehlen, regionale externe Application Load Balancer in jeder Region einzurichten, die Ihrer Meinung nach den Traffic für Ihre Anwendung am besten unterstützt.
Regionale externe Application Load Balancer unterstützen sowohl die Premium- als auch die Standard-Netzwerkdienststufen. Wir empfehlen, die zusätzlichen regionalen externen Application Load Balancer in der Premium-Stufe einzurichten, um eine niedrige Latenz zu gewährleisten.

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

Cloud DNS und Systemdiagnosen konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie mit Cloud DNS und Google Cloud-Systemüberprüfungen Ihre Cloud Load Balancing-Umgebung so konfigurieren, dass Ausfälle erkannt und Traffic an Load Balancer in anderen Regionen weitergeleitet wird.

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

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, aus denen Systemdiagnoseprüfungen gesendet werden. Sie müssen genau drei Quellregionen angeben.
- HEALTH_CHECK_INTERVAL: Die Zeit in Sekunden vom Start einer von einem Prober ausgegebenen Prüfung bis zum Start der nächsten Prüfung, die vom selben Prober ausgegeben wird. Der unterstützte Mindestwert beträgt 30 Sekunden. Empfohlene Werte finden Sie unter Best Practices.
- HEALTHY_THRESHOLD und UNHEALTHY_THRESHOLD geben die Anzahl der sequenziellen Testdurchläufe an, 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 keine Angabe gemacht wird, sendet Google Cloud Prüfungsanfragen an den Stammpfad /. Wenn die Endpunkte, für die die Systemdiagnose ausgeführt wird, privat sind, was für externe IP-Adressen von Weiterleitungsregeln nicht typisch ist, können Sie diesen Pfad auf /afhealthz festlegen.
Erstellen Sie in Cloud DNS einen Datensatz und wenden Sie eine Routingrichtlinie für die Standortbestimmung darauf an.
```
gcloud beta dns record-sets create DNS_RECORD_SET_NAME \
    --ttl=TIME_TO_LIVE \
    --type=RECORD_TYPE \
    --zone="MANAGED_ZONE_NAME" \
    --routing-policy-type="GEO" \
    --routing-policy-data="FORWARDING_RULE_NAME_A@REGION_A;FORWARDING_RULE_NAME_B@REGION_B[,;FORWARDING_RULE_NAME_C@REGION_C]" \
    --health-check=HEALTH_CHECK_NAME
```
Ersetzen Sie Folgendes:
- DNS_RECORD_SET_NAME ist der DNS- oder Domainname des hinzuzufügenden Datensatzes, z. B. test.example.com.
- TIME_TO_LIVE: die Gültigkeitsdauer (TTL) in Sekunden für den Eintrag. Empfohlene Werte finden Sie unter DNS-Überlegungen.
- 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.
- FORWARDING_RULE_NAME: die Namen der Weiterleitungsregeln für den Load-Balancer in jeder REGION
- REGION: die Regionen, in denen jeder Load-Balancer bereitgestellt wird

Best Practices

Hier sind einige Best Practices, die Sie beim Konfigurieren des Cloud DNS-Eintrags und der Systemdiagnosen beachten sollten:

Die Zeit, die der Traffic benötigt, um von fehlerhaften zu fehlerfreien Load Balancern umgeleitet zu werden (d. h. die Dauer der Ausfallzeit) hängt vom DNS-TTL-Wert, dem Intervall für die 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
```
Wir empfehlen, die DNS-TTL auf 30 bis 60 Sekunden zu setzen. Höhere TTLs führen zu längeren Ausfallzeiten, da Clients im Internet auch nach einem Failover des DNS auf andere Regionen weiterhin auf die fehlerhaften Load Balancer zugreifen können.
Konfigurieren Sie die Parameter für die Schwellenwerte "Fehlerfrei" und "Fehlerhaft" in den Systemdiagnosen, um unnötige Failovers und abrupte Weiterleitungen von Traffic zu vermeiden, die durch vorübergehende Fehler verursacht werden. Je höher die Grenzwerte sind, desto länger dauert es, bis der Traffic auf Load Balancer in anderen Regionen umgeleitet wird.