Front Door benötigt mehrere Origins? Konfiguriere eine Origin Group

Veröffentlicht am:
#networking

CloudTrips besitzt jetzt einen globalen Front-Door-Endpunkt, aber seine Origin Group enthält nur das Application Gateway in West Europe. Wenn dieser Origin nicht verfügbar ist, hat Front Door kein alternatives Ziel für die Anfrage.

Füge eine statische Azure-Storage-Website in North Europe als kleinen Maintenance-Origin hinzu. Das Application Gateway bleibt der primäre Origin. Front Door verwendet die statische Website nur, wenn der primäre Origin deaktiviert oder fehlerhaft ist.

Azure-Front-Door-Endpunkt
          |
og-cloudtrips-weu
          |
          |-- Priorität 1: Application Gateway in West Europe
          |
          `-- Priorität 2: Statische Maintenance-Site in North Europe

Dies ist ein Active/Passive-Design: Der Origin mit Priorität 1 ist aktiv, der Origin mit Priorität 2 ist das Fallback. Damit lässt sich die Origin-Auswahl ohne die Kosten einer weiteren VM- und Application-Gateway-Bereitstellung demonstrieren. Eine produktive Multi-Region-Anwendung würde in beiden Regionen dieselbe Anwendung ausführen, anstatt eine Maintenance-Seite zurückzugeben.

Dieser Trip hängt von Eine globale Webanwendung benötigt einen Edge-Einstieg? Erstelle Azure Front Door ab. Behalte afd-cloudtrips-test, route-cloudtrips-all, og-cloudtrips-weu und origin-appgw-weu.

Einen eindeutigen Storage-Account-Namen erstellen

Erzeuge aus der aktuellen Abonnement-ID einen global eindeutigen Storage-Account-Namen:

FALLBACK_STORAGE="stctfd$(az account show \
  --query id \
  --output tsv | tr -d '-' | cut -c1-8)"

printf 'Fallback-Storage-Account: %s\n' "$FALLBACK_STORAGE"

Kopiere den angezeigten Wert für das Portal. Storage-Account-Namen dürfen nur Kleinbuchstaben und Zahlen enthalten und müssen Azure-weit eindeutig sein.

Den Maintenance Storage Account erstellen

Suche nach Storage accounts, wähle Create und konfiguriere:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Storage account name: Use the FALLBACK_STORAGE value
Region: North Europe
Performance: Standard
Redundancy: Locally-redundant storage (LRS)
Require secure transfer: Disabled
Minimum TLS version: 1.2
Allow public network access: Enabled

Wähle Review + create und anschließend Create. North Europe speichert den Fallback-Inhalt in einer anderen Region als das primäre Application Gateway. LRS reicht für diese temporäre Lab-Seite aus.

Dieses Lab erlaubt am Storage-Origin bewusst HTTP, weil die vorhandene Front-Door-Route, ihr gemeinsamer Health Probe und der Application-Gateway- Listener aus dem vorausgesetzten Trip alle HTTP verwenden. Client-Verbindungen zum Front-Door-Endpunkt bleiben HTTPS. Konfiguriere für eine produktive Umgebung zuerst HTTPS auf jedem Origin und stelle danach sowohl den gemeinsamen Probe als auch das Forwarding Protocol der Route auf HTTPS um.

Die statische Website aktivieren

Öffne den Storage Account und wähle Capabilities > Static website. Wenn das aktuelle Portal die Funktion stattdessen in der Navigation anzeigt, öffne Data management > Static website. Konfiguriere:

Static website: Enabled
Index document name: index.html
Error document path: 404.html

Wähle Save. Azure erstellt einen Container namens $web und zeigt den Primary endpoint der Website an.

Erstelle die Maintenance-Seite auf deinem Computer:

printf '%s\n' \
  '<!doctype html>' \
  '<html lang="en">' \
  '<head><meta charset="utf-8"><title>CloudTrips maintenance</title></head>' \
  '<body>' \
  '<h1>CloudTrips is temporarily unavailable</h1>' \
  '<p>Front Door reached the secondary maintenance origin.</p>' \
  '</body>' \
  '</html>' \
  > index.html

Öffne im Storage Account Data storage > Containers > $web und wähle Upload. Wähle die lokale Datei index.html, erweitere die erweiterten Optionen und bestätige:

Content type: text/html

Wähle Upload. Öffne den Primary endpoint auf der Seite Static website. Der Browser sollte die CloudTrips-Maintenance-Meldung anzeigen.

Statische Azure-Storage-Website in North Europe mit der CloudTrips-Maintenance-Seite an ihrem Primary Endpoint

Den Fallback-Origin hinzufügen

Öffne afd-cloudtrips-test, wähle Settings > Origin groups und öffne og-cloudtrips-weu. Der Gruppenname spiegelt den ursprünglichen primären Origin wider; eine Origin Group kann Endpunkte aus anderen Regionen enthalten.

Bestätige, dass der gemeinsame Health Probe weiterhin Folgendes verwendet:

Health probe status: Enabled
Path: /
Protocol: HTTP
Request type: GET
Interval: 30 seconds

Die Probe-Einstellungen gehören zur Origin Group und gelten deshalb für beide Origins. / gibt sowohl vom Application Gateway als auch von der statischen Storage-Website eine erfolgreiche Seite zurück, weil Require secure transfer beim Erstellen des Storage Accounts deaktiviert wurde.

Wähle + Add an origin und konfiguriere:

Name: origin-maintenance-neu
Origin type: Storage (Static website)
Host name: Select the new fallback storage account
Origin host header: Keep the generated static-website hostname
HTTP port: 80
HTTPS port: 443
Priority: 2
Weight: 1000
Status: Enabled
Private Link: Disabled

Lasse die Prüfung des Zertifikat-Subject-Namens aktiviert, wenn sie angezeigt wird. Der Storage-Hostname und das von Microsoft verwaltete Zertifikat passen zusammen. Die aktuelle Route leitet über HTTP weiter. Die Einstellung wird daher erst relevant, wenn alle Origins für HTTPS vorbereitet sind und die Route auf HTTPS umgestellt wird.

Wähle Add und danach Update oder Save für die Origin Group. Warte, bis der Deployment Status wieder Succeeded lautet.

Die kleinere Prioritätsnummer gewinnt. Front Door sendet Datenverkehr an origin-appgw-weu mit Priorität 1, solange dieser Origin fehlerfrei ist. Der Origin origin-maintenance-neu mit Priorität 2 wird nur berücksichtigt, wenn kein Origin mit Priorität 1 verfügbar ist. Weight verteilt Datenverkehr nur zwischen fehlerfreien Origins derselben Priorität. Der Wert 1000 teilt den Datenverkehr daher nicht zwischen diesen beiden Origins auf.

Azure-Front-Door-Origin-Group mit origin-appgw-weu auf Priorität 1 und origin-maintenance-neu auf Priorität 2

Den primären Origin bestätigen

Rufe den Front-Door-Hostnamen ab:

AFD_HOST=$(az afd endpoint list \
  --resource-group rg-cloudtrips-network-test-weu \
  --profile-name afd-cloudtrips-test \
  --query '[0].hostName' \
  --output tsv)

Rufe die Root-Seite mehrmals ab:

for request in {1..3}; do
  curl --silent --show-error "https://${AFD_HOST}/"
  printf '\n'
done

Die Antworten sollten von den normalen CloudTrips-Web-VMs hinter dem Application Gateway stammen. Solange der Origin mit Priorität 1 verfügbar ist, darf die Maintenance-Seite nicht erscheinen.

Lokales Terminal, in dem der Front-Door-Endpunkt die primäre CloudTrips-Anwendung statt des Maintenance-Origins zurückgibt

Den Fallback-Origin testen

Kehre zu og-cloudtrips-weu zurück, öffne origin-appgw-weu, ändere Status auf Disabled und speichere. Das Deaktivieren eines Origins beendet sowohl Routing als auch Health Probes zu diesem Origin. Es stoppt oder verändert das Application Gateway nicht.

Warte, bis die Front-Door-Bereitstellung wieder Succeeded anzeigt, und rufe danach dieselbe URL auf:

curl --silent --show-error "https://${AFD_HOST}/"

Die Antwort sollte nun enthalten:

CloudTrips is temporarily unavailable
Front Door reached the secondary maintenance origin.

Wenn die Antwort stattdessen AccountRequiresHttps enthält, kehre zur Seite Configuration des Storage Accounts zurück und deaktiviere Require secure transfer. Stelle nicht nur die Front-Door-Route auf HTTPS um: Das Application Gateway aus dem vorausgesetzten Trip besitzt nur einen HTTP-Listener und würde nach seiner Wiederherstellung als primärer Origin nicht mehr funktionieren.

Der Client verwendet weiterhin denselben Front-Door-Hostnamen und dieselbe Route. Nur der ausgewählte Origin hat sich geändert.

Browser mit der CloudTrips-Maintenance-Seite über den unveränderten Azure-Front-Door-Endpunkt nach Deaktivierung des primären Origins

Dieser kontrollierte Test belegt das Prioritätsverhalten, ohne gemeinsam genutzte VMs oder das Application Gateway zu stoppen. Bei einem echten Ausfall würden fehlgeschlagene Health Probes Front Door veranlassen, den fehlerhaften primären Origin automatisch auszuschließen.

Den primären Origin wiederherstellen

Öffne origin-appgw-weu erneut, ändere Status auf Enabled und speichere. Warte auf die Bereitstellung der Konfiguration und mehrere erfolgreiche Health Probes. Bei einem Probe-Intervall von 30 Sekunden kann die Wiederherstellung einige Minuten dauern.

Führe die Anfrage erneut aus und bestätige, dass die normale CloudTrips-Anwendung die Maintenance-Seite ersetzt hat.

Die statische Fallback-Website ist öffentlich und durchläuft nicht die regionale Application-Gateway-WAF. Für diese schreibgeschützte Lab-Seite ist das akzeptabel. Ein Produktivdesign sollte geeigneten Edge-Schutz anwenden und den direkten Zugriff auf seine Origins einschränken.

Behalte das Front-Door-Profil, die Route, beide Origins und den Maintenance-Storage-Account für den folgenden Trip zu Front-Door-Routingregeln. Wenn du hier stoppst, entferne den Maintenance-Origin, bevor du seinen Storage Account löschst.