Implementierungshandbuch für hohe Verfügbarkeit für die Verwendung von Azure Front Door und alternativen Eingangslösungen

Azure Front Door wurde entwickelt, um außergewöhnliche Resilienz und Verfügbarkeit sowohl für externe Kunden als auch für die internen Eigenschaften von Microsoft bereitzustellen. Obwohl die Architektur von Azure Front Door die Anforderungen der meisten Produktionsworkloads erfüllt oder überschreitet, ist kein verteiltes System immun gegen Fehler.

Dieser Artikel enthält schrittweise Anleitungen auf hoher Ebene für die Implementierung von Azure Traffic Manager, um manuelles Failover von Azure Front Door zu einem alternativen CdN (Content Delivery Network) oder einer Azure Application Gateway-Webanwendungsfirewall (WAF) während seltener Azure Front Door-Dienstunterbrechungen zu ermöglichen. Es ergänzt die Anleitungen zur globalen Routingredundanz für unternehmenskritische Webanwendungen.

Es gibt mehrere Strategien innerhalb der Branche, um hohe Verfügbarkeit (HA) in CDN- und Webanwendungsarchitekturen zu erreichen. Der in diesem Artikel beschriebene Ansatz konzentriert sich auf ein einfaches, manuelles Notfallfailovermuster. Kunden können das Muster verwenden, um den Datenverkehr während eines Ausfalls schnell umzuleiten und das Routing an Azure Front Door nahtlos wiederherzustellen, nachdem der Dienststatus bestätigt wurde.

Der Artikel enthält außerdem Anleitungen für die Implementierung von HA-Mustern in Produktionsumgebungen, das Einrichten der Gesundheitsüberwachung und das Erstellen von betrieblichen Runbooks zur Unterstützung der fortlaufenden Einsatzbereitschaft.

Wichtige operative Unterschiede

Dieses Handbuch enthält zwei bewährte Architekturen, die Traffic Manager verwenden, um automatisiertes Failover bereitzustellen. In der folgenden Tabelle sind die wichtigsten betrieblichen Unterschiede zusammengefasst, die sie berücksichtigen sollten:

Aspekt Szenario 1 (Azure Front Door + Anwendungsgateway) Szenario 2 (Azure Front Door + sonstiges CDN)
Failover Ziel Sekundäre Traffic Manager-Instanz und mehrere Anwendungsgatewayinstanzen. Einzelner anderer CDN-Endpunkt.
Zwischenspeichern während des Failovers Nein. Das Anwendungsgateway führt kein Caching durch. Ja.
Geografische Verteilung Zwei bestimmte Azure-Regionen. Das globale Edge-Netzwerk eines anderen CDN.
WAF-Schutz Azure Web Application Firewall (konsistente Regelsätze). WaF eines anderen CDN (unterschiedliche Regelsätze).
Kosten während des Standbymodus Fixe Berechnungskosten. Anwendungsgatewaygebühren auch bei Leerlauf: ~200-400/Monat für WAF_v2 mit minimaler Kapazität. Abhängig von den Preisen des CDN-Anbieters.

Überlegungen für Produktionsumgebungen

Berücksichtigen Sie beim Implementieren von HA-Architekturen für Produktionsworkloads die folgenden bewährten Methoden und wichtigen Hinweise:

  • Konfigurieren Sie die primäre Traffic Manager-Instanz nicht für automatisches Failover.

    Azure Traffic Manager-Integritätstests stammen nur aus US-basierten Azure-Regionen. Bei Probes von Azure Front Door-Endpunkten (oder einem beliebigen CDN mithilfe von Anycast-Routing) erreichen diese US-basierten Probes fast immer US-POP-Server und überprüfen nicht den Zustand von Nicht-US-POP-Servern. Dadurch kann Traffic Manager nicht automatisch ein Failover zwischen Azure Front Door und einem anderen Eingangsdienst wechseln, wenn die tatsächliche globale Integrität eines Anycast-CDN wie Azure Front Door bekannt ist.

    Für globale Workloads, die eine Gesundheitsüberprüfung von mehreren Regionen erfordern, bietet manuelles Failover mit gewichtetem Routing und deaktivierten Überwachung eine zuverlässigere Kontrolle als automatisiertes gesundheitsbasiertes Routing.

  • Wenn Sie derzeit von Azure Front Door verwaltete Zertifikate verwenden, müssen Sie auf BYO-Zertifikate (Bring-your-own, BYO) migrieren. Wenn Sie Ihr eigenes Zertifikat verwenden, können Sie die TLS-Zertifikate unabhängig davon konsistent halten, welchem Pfad der Datenverkehr folgt.

    Stellen Sie sicher, dass Ihre TLS-Zertifikate mit Azure Front Door kompatibel sind. Weitere Informationen finden Sie unter Konfigurieren von HTTPS in einer benutzerdefinierten Azure Front Door-Domäne und TLS-Verschlüsselung mit Azure Front Door.

  • Testen Sie failoverprozeduren immer zuerst in Nichtproduktionsumgebungen.

  • Der Datenverkehrs-Manager unterstützt keine CNAME-Flattening in der DNS-Zone apex (Stammdomäne). Wenn Sie Traffic Manager an der Spitze benötigen, müssen Sie DNS-Anbieter verwenden, die Aliaseinträge oder ähnliche Mechanismen unterstützen. Azure DNS ist ein solcher DNS-Anbieter.

  • Verwenden Sie kurze TTL-Werte (Time-to-Live) von 300-600 Sekunden. Überwachen der DNS-TTL-Verteilungszeiten.

  • Sperren Sie Application Gateway mit Netzwerksicherheitsgruppen (NSGs) and Zugriffssteuerungslisten (Access Control Lists, ACLs). Lassen Sie erforderliche Plattformbereiche und eingehende Anwendungsports zu. Sichern Sie Ursprünge für alle Eingangspfade. Weitere Informationen finden Sie unter Netzwerksicherheitsgruppen.

    Eine Application Gateway-WAF-Instanz wehrt zwar HTTP/L7-Angriffe ab, aber NSGs bieten nur Paketfilterung und keinen Schutz vor volumetrischen DDoS-Angriffen oder DDoS-Angriffen auf Protokollebene (L3/L4). Alle öffentlichen Azure-Endpunkte profitieren von dem grundlegenden DDoS-Schutz in der Azure-Plattform. Sie trägt zum Schutz der Azure-Infrastruktur bei, umfasst jedoch keine workloadspezifische Optimierung, Telemetrie, Kostenschutz oder Verfügbarkeitsgarantien.

    Bei produktions- und unternehmenskritischen Workloads sollten Sie den Azure DDoS Protection-Dienst verwenden, um öffentliche IPs des Anwendungsgateways zu schützen. Weitere Informationen finden Sie unter Azure DDoS Protection-Preise.

  • Dokument-WAF-Regelunterschiede zwischen Azure Front Door und Failoverlösungen.

  • Wir empfehlen azure Private Link für diese HA-Architekturen nicht, da alternative CDN-Plattformen nicht auf Ursprünge zugreifen können, die durch die Integration von privatem Link in Azure Front Door geschützt sind.

    Außerdem erfordert das Application Gateway eine zusätzliche virtuelle Netzwerk- und private Endpunktkonfiguration, um private Ursprünge zu erreichen. Das Anwendungsgateway kann die nativen Funktionen für private Verknüpfungen von Azure Front Door nicht verwenden.

    Für Produktionsumgebungen, die Azure Front Door zusammen mit anderen CDN-Anbietern verwenden, sollten Sie alternative, CDN-agnostische Ursprungssicherheitskontrollen verwenden, um die Ursprungsvertrauensstellung zu erzwingen, wenn Sie keine private Verknüpfung oder X‑Azure‑FDID Überprüfung verwenden können. Diese Steuerelemente können die tokenbasierte Ursprungsauthentifizierung (HMAC oder signierte URLs), gegenseitiges TLS (mTLS), benutzerdefinierte Ursprungsheader und IP-Adressfilterung umfassen.

  • Bearbeiten Sie die in diesem Handbuch aufgeführten Beispielbefehle so, dass sie auf Ihre Umgebung für Automatisierungs- und Runbooks zugeschnitten sind.

  • Erstellen Sie klare Runbooks. Testen Sie Failover- und Failbackprozeduren.

  • Konfigurieren Sie umfassende Überwachung und Warnung für alle Endpunkte.

  • Überprüfen Sie die Funktionalität während des Failovers auf alternative Eingangslösungen.

  • Testzertifikaterneuerungsprozesse auf allen Plattformen.

  • Überprüfen Sie regelmäßig, ob Failoverendpunkte funktionsfähig bleiben. Wir empfehlen vierteljährliche Tests.

  • In diesem Handbuch werden Azure CLI-Beispielbefehle verwendet, die Sie über PowerShell ausführen.

  • Bevor Sie fortfahren, überprüfen Sie die globale Routingredundanz für unternehmenskritische Webanwendungen.

Szenario 1: Traffic Manager Failover von Azure Front Door zu einem Application Gateway WAF

Diese DNS-basierte Lastenausgleichslösung verwendet mehrere Azure Traffic Manager-Profile. Im unwahrscheinlichen Fall eines Verfügbarkeitsproblems mit Azure Front Door leitet Traffic Manager Datenverkehr über das Anwendungsgateway WAF um. Die primäre Traffic Manager-Instanz leitet Datenverkehr zwischen Azure Front Door (primär) und einer geschachtelten sekundären Traffic Manager-Instanz weiter, die auf Anwendungsgatewayinstanzen mit mehreren Regionen verweist. Während eines Ausfalls von Azure Front Door wird der Datenverkehr manuell auf regionale Application Gateway-Bereitstellungen mit WAF-Schutz umgeleitet.

Diagramm, das den Traffic Manager mit gewichtetem Routing zu Azure Front Door und ein geschachteltes Traffic Manager-Profil zeigt, das Leistungsrouting zum Senden an Application Gateway-Instanzen in zwei Regionen verwendet.

  • Datenverkehrsfluss (normaler Vorgang): Benutzer → DNS-Abfrage → primäre Traffic Manager-Instanz (gewichtet/always-serve routing) → Azure Front Door (Priorität 1) → Ursprungsserver.

  • Datenverkehrsfluss (Azure Front Door-Fehler): Benutzer → DNS-Abfrage → primäre Traffic Manager-Instanz (gewichtet/always-serve Routing) → sekundäre Traffic Manager-Instanz (Prioritätsmodus) → Application Gateway → Ursprungsserver.

Vor der Bereitstellung: Azure Front Door vs. Application Gateway

Es ist wichtig, die Featureunterschiede zwischen Azure Front Door und einem Anwendungsgateway-WAF zu verstehen, falls Sie alle Features verwenden, die ein Anwendungsgateway WAF nicht bietet. In den folgenden Tabellen finden Sie eine Übersicht.

Von Bedeutung

Bei dieser Lösung wird davon ausgegangen, dass Sie derzeit Azure Front Door verwenden, um Datenverkehr über mehrere Regionen oder global zu bedienen. In diesem Entwurf führen die folgenden Schritte eine sekundäre Traffic Manager-Instanz ein, die mit dem Leistungsrouting zwischen der primären Traffic Manager-Instanz und regionalen Anwendungsgatewayinstanzen konfiguriert ist.

Dieser Ansatz ist erforderlich, da Azure Front Door ein globaler Layer-7-Dienst ist. Die sekundäre Traffic Manager-Instanz ersetzt das globale latenzbasierte Routing in Azure Front Door effektiv, indem sie als globale Lastenausgleichsebene fungiert. Daher behält Traffic Manager das latenzoptimierte Benutzerrouting für eine geografisch verteilte Zielgruppe bei.

Angesichts dieser Architekturverschiebung müssen Sie globale Datenverkehrsmuster auswerten und Anwendungsgateway-Instanzen in Regionen bereitstellen, die über ein aussagekräftiges Benutzervolumen verfügen, um eine optimale Leistung und Resilienz sicherzustellen.

Featureunterschiede

Merkmal Azure Front Door – der Dienst für Web-Traffic-Management Application Gateway
Kernarchitektur und Merkmale
Dienstbereich Globaler Dienst Regionaler Dienst
OSI-Ebene Ebene 7 (Anwendungsschicht) Ebene 7 (Anwendungsschicht)
Lastenausgleichsebene Regionenübergreifend Innerhalb einer Region oder eines virtuellen Netzwerks
Bereitstellungsmodell Einzelne globale Instanz Instanzen pro Region
Backend Bereich Alle öffentlichen Endpunkte (Azure oder extern) und ausgewählte Endpunkte für private Verknüpfungen Alle öffentlichen Endpunkte (Azure oder extern), private IP-Adressen und Kubernetes-Pods in einem virtuellen Netzwerk
Edge-Caching von Inhalten Yes Nein
Netzwerkarchitektur Microsofts globales Edgenetzwerk mit Anycast Azure-Regionale Bereitstellung (kein Anycast)
Konfigurationsunterschiede
Pfadmustersyntax /path/* oder genau /path Regex-Muster, Pfadzuordnungen
WAF-Regelsätze Standardregelsatz (OWASP), Bot-Manager-Regelsatz, HTTP-DDoS-Regelsatz Standardregelsatz (OWASP), Bot-Manager-Regelsatz, HTTP-DDoS-Regelsatz
Evaluierung des Integritätstests Latenz + Zustand für Routing Nur Gesundheitsstatus
Backend-Auswahl Basierend auf Priorität, Gewichtung, Latenz Round-Robin, Cookie-Affinität
Routing-Regeln
Pfadbasiertes Routing ✓ Ja ✓ Ja
Musterabgleich Exakt übereinstimmende Pfade, Platzhalterpfade (/*), Groß-/Kleinschreibung wird nicht beachtet, dem Platzhalter muss / vorangestellt werden URL-Pfadzuordnungen, pfadbasierte Regeln und regex-Muster werden unterstützt
Hostbasiertes Routing • Mehrere Frontend-Hosts • Hosting mit mehreren Websites
URL rewrite Statischer Pfad zum statischen Pfad (klassisch) URL-Pfad-Neuschreibung
Routingmethoden Priorität, Gewichtung, Latenzbasis Lastabhängig zur Optimierung der Latenz*, gewichtet*, Sitzungsaffinität (*verfügbar mit Application Gateway für Container)
Routing-Funktionen
Regelmodul/Regeln neu schreiben Regelsätze mit Bedingungen und Aktionen Neuschreiben von Regelsätzen mit Bedingungen und Aktionen
Regex in Pfadmustern Nicht unterstützt in Mustern, die übereinstimmen sollen Unterstützt mit PCRE
Header- und Anforderungsmanipulation
Erneutes Generieren von Headern ✓ Anforderungs- und Antwortheader ✓ Anforderungs- und Antwortheader
Zeichenbegrenzung für Kopfzeilenwert Kein dokumentierter Grenzwert 1.000 Zeichen bei Neuschreibregeln
Hostheader neu schreiben ✓ Unterstützt • Unterstützt (kann nicht in externe Domänen umgeschrieben werden)
Servervariablen ✓ Unterstützt ✓ Unterstützt
Kopfzeilenmusterabgleich Bedingungen mit Mustern Regex-Musterabgleich
Sicherheitsfeatures
WAF-Verfügbarkeit • Optional (Premium-Stufe) ✓ Optional (WAF-Ebene)
L3/4 DDoS-Schutz ✓ Integriert Über den Azure DDoS Protection-Dienst
SSL/TLS-Richtlinien • Konfigurierbar • Konfigurierbar
End-to-End-Verschlüsselung mit SSL ✓ Unterstützt ✓ Unterstützt
Private Link-Unterstützung • Premium-Stufe • V2-Ebene
Benutzerdefinierte WAF-Regeln ✓ Unterstützt ✓ Unterstützt

WAF-Unterschiede

Azure Front Door – der Dienst für Web-Traffic-Management Application Gateway
Microsoft Default Rule Set (DRS) 2.1 OWASP Core Rule Set (CRS) 3.2 oder 4.0
Regel-IDs: 949xxx-Serie Regel-IDs: 9xxxxx-Serie
Azure Front Door WAF (DRS): prüft die ersten 128 KB des Anforderungstexts Anwendungsgateway WAF (CRS 3.2+): bis zu 2 MB Inspektion; 4-GB Dateiupload; Erzwingung und Inspektion können unabhängig voneinander konfiguriert werden

Recommendations

  • Da Sie für jede WAF unterschiedliche Regelsätze beibehalten müssen, verwenden Sie den Azure Front Door-Regelsatz als Ihre Grundlage. Erstellen Sie einen Anwendungsgateway-Regelsatz, der dem Azure Front Door-Regelsatz so genau wie möglich entspricht.

  • Testen Sie das Anwendungsgateway WAF separat und unabhängig.

  • Dokumentieren Sie alle benutzerdefinierten Ausschlüsse für beide Plattformen.

  • Prüfen Sie Regelsätze regelmäßig auf Konsistenz.

  • Befolgen Sie die Netzwerkanleitungen in der Azure Application Gateway-Infrastrukturkonfiguration. Achten Sie darauf, die folgenden Anforderungen für virtuelle Netzwerke und Subnetze auszuführen:

    • Verwenden Sie die folgende Subnetzgröße (pro Region):

      • Minimum: /27 (32 Adressen)

      • Empfohlen: /24 (256 Adressen) für die automatische Skalierung und die hitlose Wartung

      • Formel: (maximale Instanzen * 10) + 5 reservierte Azure-IPs

      • Beispiel: 20 maximal zulässige Instanzen führen zu (20 * 10) + 5 = 205 IPs, daher Nutzung von /24 empfohlen.

    • Verwenden Sie für optimale Sicherheit ein dediziertes Subnetz für das Anwendungsgateway (keine anderen Ressourcen).

    • Stellen Sie sicher, dass die eingehende Verbindung Folgendes zulässt:

      • 443/80 aus dem Internet (oder bestimmten Quellbereichen)

      • 65200-5535 von Azure Gateway Manager (Anwendungsgateway v2)

      • Azure-Lastenausgleich

    • Blockieren anderer eingehender Verbindungen. Blockieren Sie keine erforderlichen ausgehenden Internetverbindungen.

    • Verwenden Sie Anwendungssicherheitsgruppen für Back-End-Segmentierung und Regeln mit den geringsten Berechtigungen.

Informationen zur Kapazitätsplanung und automatischen Skalierungsstrategie finden Sie unter Architektur bewährte Methoden für Azure Application Gateway v2.

Wichtige Implementierungsschritte

Schritt 1: Bereitstellen von Voraussetzungen

  • Azure Front Door mit einer benutzerdefinierten Domäne und einem BYO-Zertifikat konfiguriert.

  • Eine niedrigere DNS-TTL für Ihren CNAME-Eintrag, sodass Azure Front Door Datenverkehr zur niedrigsten Zeiteinstellung bereitstellt.

  • Azure-Abonnement mit Berechtigungen zum Erstellen virtueller Netzwerke, einer Anwendungsgatewayinstanz und einer Traffic Manager-Instanz.

  • SSL/TLS-Zertifikat im Azure Key Vault oder für den Upload verfügbar.

  • Origin-Server, auf die über virtuelle Azure-Netzwerke zugegriffen werden kann.

Von Bedeutung

Wenn Sie derzeit azure Front Door-verwaltete Zertifikate verwenden, müssen Sie zu BYO-Zertifikaten migrieren, bevor Sie diese Lösung implementieren. Von Azure Front Door verwaltete Zertifikate können nicht exportiert und auf alternativen CDNs installiert werden. Weitere Informationen finden Sie unter Konfigurieren von HTTPS in einer benutzerdefinierten Azure Front Door-Domäne.

Schritt 2: Bereitstellen des Anwendungsgateways in der ersten Region

  1. Erstellen Sie eine Netzwerkinfrastruktur für das Anwendungsgateway. Weitere Informationen finden Sie unter Konfiguration der Application Gateway-Infrastruktur.

  2. Erstellen Sie eine verwaltete Identität, und gewähren Sie Key Vault-Zugriff. Weitere Informationen finden Sie unter TLS-Terminierung mit Key Vault-Zertifikaten.

    Für das Anwendungsgateway ist das SSL/TLS-Zertifikat im PFX-Format mit einem privaten Schlüssel erforderlich. Auf das Zertifikat muss über Key Vault zugegriffen oder direkt hochgeladen werden. Verwenden Sie dasselbe Zertifikat, das Azure Front Door verwendet, um ein konsistentes TLS-Verhalten sicherzustellen.

  3. Erstellen einer WAF-Richtlinie. Weitere Informationen finden Sie unter Erstellen von WAF-Richtlinien für das Anwendungsgateway.

  4. Erstellen Sie eine Anwendungsgateway-Instanz mit HTTPS und WAF. Weitere Informationen finden Sie unter Konfigurieren einer Anwendungsgatewayinstanz mit TLS-Beendigung.

  5. Konfigurieren Sie einen Back-End-Hostheader. Weitere Informationen finden Sie unter "Problembehandlung bei Backend-Gesundheitsproblemen in Application Gateway".

  6. Anwendungsgateway überprüfen:

    # Get Application Gateway public IP
$APPGW_IP = az network public-ip show `
    --name $APPGW_PIP_NAME_R1 `
    --resource-group $RESOURCE_GROUP `
    --query ipAddress -o tsv
Write-Host "Application Gateway IP: $APPGW_IP"

# Test Application Gateway directly (SkipCertificateCheck because certificate is for domain, not IP)
Invoke-WebRequest -Uri "https://$APPGW_IP/index.html" -Method Head -SkipCertificateCheck

    Das erwartete Ergebnis ist Statuscode 200. Wenn Sie "502 Bad Gateway" erhalten, stellen Sie sicher, dass die Back-End-HTTP-Einstellungen aktiviert sind --host-name-from-backend-pool true .

Schritt 3: Konfigurieren von WAF-Richtlinieneinstellungen (optional)

Standardmäßig wird ein WAF im Erkennungsmodus erstellt. Der Präventionsmodus blockiert aktiv böswillige Anfragen. Testen Sie sorgfältig, bevor Sie den Präventionsmodus in der Produktion aktivieren.

Bewerten Sie Ihre globalen Datenverkehrsmuster, und stellen Sie Anwendungsgateway-Instanzen in Regionen bereit, die ein aussagekräftiges Benutzervolumen aufweisen. Wenn Sie das Anwendungsgateway in mehreren Regionen bereitstellen, wiederholen Sie die Schritte 2 und 3 für jede zusätzliche Region (z. B. West US 2). Verwenden Sie unterschiedliche Virtuelle Netzwerkadressen (10.2.0.0/16, 10.3.0.0/16 usw.) und regionsspezifische Variablensuffixe (R2, R3 usw.).

Schritt 4: Erstellen einer Traffic Manager-Architektur zur Unterstützung der WAF-Endpunkte des Anwendungsgateways

  1. Erstellen Sie eine sekundäre Traffic Manager-Instanz im Leistungsmodus, wie weiter oben im Diagramm für dieses Szenario gezeigt. Weitere Informationen finden Sie unter Erstellen eines Traffic Manager-Profils.

    Verwenden Sie für eine Konfiguration mit einer Region die folgenden Details:

    • Routingmethode: Priorität.
    • Endpunkt: Öffentliche IP-Adresse des einzelnen Anwendungsgateways.

    Verwenden Sie für eine Konfiguration mit mehreren Regionen die folgenden Details:

    • Routingmethode: Leistung (leitet Benutzer an die nächste fehlerfreie Anwendungsgatewayinstanz weiter).
    • Endpunkte: Mehrere öffentliche IP-Adressen des Anwendungsgateways in allen Regionen.
    • Endpunktstandorte: Die Azure-Region für jeden Endpunkt (erforderlich für das Leistungsrouting).

    Verwenden Sie die folgenden Konfigurationseinstellungen:

    Setting Wert Hinweise
    Routingmethode Leistung (Multiregion) oder Priorität (Einzelregion) Die Leistung optimiert die Latenz für eine Konfiguration mit mehreren Regionen.
    Protokoll HTTPS Überprüft die Integrität des Anwendungsgateways über HTTPS.
    Hafen 443 Standardmäßiger HTTPS-Port.
    Pfad /health oder /index.html Muss dem Pfad der Application Gateway-Backend-Gesundheitsprüfung entsprechen.
    TTL 300 Sekunden Verteilt die Last und Reaktionsfähigkeit von DNS-Abfragen gleichmäßig.

    Hinweis

    Standardmäßig sind öffentliche Azure-IPs für das Anwendungsgateway nicht mit DNS-Namen konfiguriert. Sie müssen die öffentliche IP-Adresse direkt in Traffic Manager-Endpunkten und nicht in einem DNS-Namen verwenden. Der --endpoint-location Parameter ist für das Leistungsrouting erforderlich, um das geografische Routing zu aktivieren.

  2. Erstellen Sie eine primäre gewichtete/immer bediente Traffic Manager-Instanz, wie weiter oben im Diagramm für dieses Szenario gezeigt. Weitere Informationen finden Sie unter Erstellen eines Traffic Manager-Profils.

    Verwenden Sie für beide Endpunkte die folgenden Konfigurationen:

    Setting Wert Hinweise
    Routingmethode Gewichtet Ermöglicht die manuelle Steuerung über den Endpunktstatus (aktiviert oder deaktiviert).
    Gewicht 100  
    Protokoll HTTPS Erforderlich für die Überprüfung von SSL/TLS-Endpunkten.
    Hafen 443 Standardmäßiger HTTPS-Port.
    Pfad /index.html Wählen Sie einen schlanken Endpunkt für Integritätsprüfungen.
    TTL 300 Sekunden DNS TTL. Niedrigere Werte ermöglichen ein schnelleres Failover, erhöhen aber DNS-Abfragen.
    Integritätsprüfung Immer Verkehr bereitstellen Aktivieren Sie keine Gesundheitsprüfungen.

    Diese Konfigurationen sind spezifisch für den primären Endpunkt:

    • Typ: Externer Endpunkt

    • Name: endpoint-afd-primary

    • Vollqualifizierter Domänenname (FQDN) oder IP-Adresse: Hostname des Azure Front Door-Endpunkts (z. B myapp-12345.z01.azurefd.net. )

    • Endpunkt aktivieren: Ausgewählt (aktiviert)

    • Benutzerdefinierte Kopfzeileneinstellungen: Host=$CUSTOM_DOMAIN (erforderlich, damit Azure Front Door zur richtigen benutzerdefinierten Domäne weitergeleitet werden kann)

    • Gesundheitsprüfungen: Immer Verkehr bedienen (Gesundheitsprüfungen deaktivieren)

    Screenshot der Konfigurationen zum Hinzufügen eines primären Traffic Manager-Endpunkts im Azure-Portal.

    Diese Konfigurationen sind spezifisch für den sekundären Endpunkt:

    • Typ: Externer Endpunkt

    • Name: endpoint-appgw-secondary

    • Vollqualifizierter Domänenname (FQDN) oder IP-Adresse: FQDN des sekundären Datenverkehrs-Managers (zum Beispiel myapp-appgw.trafficmanager.net).

    • Endpunkt aktivieren: Gelöscht (deaktiviert)

    Screenshot der Konfigurationen zum Hinzufügen eines sekundären Endpunkts von Traffic Manager.

  3. Überprüfung der Gesundheit des Traffic Managers:

    # Check endpoint health status
az network traffic-manager profile show `
    --name $ATM_PRIMARY_PROFILE `
    --resource-group $RESOURCE_GROUP `
    --query "{ProfileStatus:profileStatus, MonitorStatus:monitorConfig.profileMonitorStatus, Endpoints:endpoints\[\].{Name:name, Target:target, Priority:priority, Status:endpointMonitorStatus}}"

    Beide Endpunkte sollten Status: Online anzeigen. Wenn ein Endpunkt Degraded oder CheckingEndpoint zeigt, warten Sie 1-2 Minuten, bis die Gesundheitsprüfungen abgeschlossen sind.

Schritt 5: Aktualisieren von DNS-CNAME auf Traffic Manager und Überprüfen des Updates

Warnung

Die folgenden Schritte leiten Ihren Produktionsdatenverkehr direkt von Azure Front Door zu Traffic Manager um und führen zu möglichen Auswirkungen auf den Dienst. Bevor Sie fortfahren:

  • Testen Sie diese Schritte zuerst in einer Nichtproduktionsumgebung. Ändern Sie beispielsweise vorübergehend die lokale hosts-Datei auf einer Nicht-Produktions-Arbeitsstation, um die benutzerdefinierte Domäne in den Traffic Manager-Endpunkt aufzulösen. Diese Änderung ermöglicht die Überprüfung, ohne dass sich der Livedatenverkehr auswirkt.
  • Verringern Sie die DNS-CNAME-TTL auf den niedrigsten möglichen Wert (z. B. 60-300 Sekunden), mindestens 24 Stunden, bevor Sie Änderungen vornehmen.
  • Planen Sie nach Möglichkeit ein Wartungsfenster in Zeiten mit geringem Datenverkehr.
  • Stellen Sie Rollbackprozeduren bereit, falls Probleme auftreten.

  1. Aktualisieren Sie Ihren DNS-CNAME-Eintrag so, dass er auf die primäre Traffic Manager-Instanz anstatt direkt auf Azure Front Door verweist.

    Feld Alter Wert Neuer Wert
    Name/Host www www (keine Änderung)
    Wert/verweist auf Hostname des Azure Front Door-Endpunkts $ATM_DNS_NAME.trafficmanager.net

  2. Überprüfung der Traffic-Manager-Auflösung

    # Verify Traffic Manager profile is resolving
nslookup "$ATM_DNS_NAME.trafficmanager.net"

    Der Test sollte die IP-Adresse des Azure Front Door-Endpunkts zurückgeben.

  3. Warten Sie auf die DNS-Verteilung, und testen Sie dann die HTTPS-Konnektivität. Die DNS-Verteilung dauert in der Regel 5-10 Minuten, kann jedoch bis zu 48 Stunden global dauern.

    # Check DNS from different resolvers
nslookup $CUSTOM_DOMAIN 8.8.8.8 # Google DNS

# Test HTTPS connectivity
Invoke-WebRequest -Uri "https://$CUSTOM_DOMAIN/index.html" -Method Head

    Dieser Test sollte den Statuscode 200 zurückgeben.

  4. Überwachen Sie nach der DNS-Umstellung die folgenden Azure Front Door Metriken aktiv:

    • Anforderungsanzahl: Die Anzahl sollte konsistent bleiben, ohne dass der Datenverkehr sinkt.

    • Antwortzeit: Die Zeit sollte innerhalb normaler Bereiche verbleiben.

    • Fehlerraten: 4xx/5xx Fehler sollten nicht zunehmen.

    • Ursprungsgesundheit: Backend-Gesundheit sollte beibehalten werden Online.

Schritt 6: Testen von Failoverprozeduren

  1. Simulieren eines Azure Front Door-Fehlers (manuelles Failover zum Anwendungsgateway):

    # Manual failover to Application Gateway
# Disable Azure Front Door endpoint
az network traffic-manager endpoint update `
    --name "endpoint-afd-primary" `
    --profile-name $ATM_PRIMARY_PROFILE `
    --resource-group $RESOURCE_GROUP `
    --type externalEndpoints `
    --endpoint-status Disabled

# Enable secondary Traffic Manager endpoint (Application Gateway)
az network traffic-manager endpoint update `
    --name "endpoint-appgw-secondary" `
    --profile-name $ATM_PRIMARY_PROFILE `
    --resource-group $RESOURCE_GROUP `
    --type externalEndpoints `
    --endpoint-status Enabled

# Verify Traffic Manager endpoint status
az network traffic-manager endpoint list `
    --profile-name $ATM_PRIMARY_PROFILE `
    --resource-group $RESOURCE_GROUP `
    --query "[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus}" `
    --output table

# Flush DNS cache (Windows)
ipconfig /flushdns

# Verify DNS resolution (should now point to secondary Traffic Manager instance and Application Gateway)
nslookup $CUSTOM_DOMAIN

# Test - should now work via Application Gateway
curl --head https://$CUSTOM_DOMAIN/

    Hinweis

    DNS-TTL wirkt sich auf die Failoverzeit aus. Bei einer TTL von 60 Sekunden kann es bis zu 60 Sekunden dauern, bis die Änderung angezeigt wird. Verwenden Sie nslookup, um zu überprüfen, ob die Auflösung auf das Anwendungsgateway verweist.

  2. Failback auf Azure Front Door:

    # Re-enable Azure Front Door endpoint
az network traffic-manager endpoint update `
    --name "endpoint-afd-primary" `
    --profile-name $ATM_PRIMARY_PROFILE `
    --resource-group $RESOURCE_GROUP `
    --type externalEndpoints `
    --endpoint-status Enabled

# Disable Application Gateway (via Secondary Traffic Manager)
az network traffic-manager endpoint update `
    --name "endpoint-appgw-secondary" `
    --profile-name $ATM_PRIMARY_PROFILE `
    --resource-group $RESOURCE_GROUP `
    --type externalEndpoints `
    --endpoint-status Disabled

# Verify endpoint status
az network traffic-manager endpoint list `
    --profile-name $ATM_PRIMARY_PROFILE `
    --resource-group $RESOURCE_GROUP `
    --query "[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus}" `
    --output table

# Flush DNS cache (Windows)
ipconfig /flushdns

# Verify DNS resolution (should now point back to Azure Front Door)
nslookup $CUSTOM_DOMAIN

# Test - should now work via Azure Front Door
curl --head https://$CUSTOM_DOMAIN/

  3. Überprüfen Sie das aktuelle Routing:

    # Check which endpoint is serving traffic
nslookup $CUSTOM_DOMAIN

Invoke-WebRequest -Uri "https://$CUSTOM_DOMAIN/index.html" -Method Head | Select-Object -ExpandProperty Headers

    Die Antwortheader können helfen, den bereitstellenden Endpunkt zu identifizieren.

    • Azure Front Door enthält die x-azure-ref Kopfzeile.
    • Datenverkehr, der über das Anwendungsgateway durchläuft, kann Server: Microsoft-IIS oder Ähnliches enthalten.

Szenario 2: Traffic Manager-Failover von Azure Front Door zu einem alternativen CDN

Diese Lösung verwendet ein einzelnes Traffic Manager-Profil mit Gewichtungs-/Always-Serve-Routing, sodass Sie den Datenverkehr zwischen Azure Front Door und einem alternativen CDN manuell wechseln können.

Diagramm des Routings von Traffic Manager zwischen Azure Front Door und einem anderen CDN.

  • Primärer Endpunkt: Benutzerdefinierter Azure Front Door-Domänenendpunkt.

  • Sekundärer Endpunkt: Alternativer CDN-Endpunkt.

  • Traffic Flow (Normalbetrieb): Benutzer → DNS Abfrage → Traffic Manager (gewichtetes/immer bedientes Routing) → Azure Front Door (Priorität 1) → Ursprungsserver.

  • Traffic Flow (Ausfall von Azure Front Door): Benutzer → DNS Abfrage → Traffic Manager (gewichtetes/immer bedientes Routing) → Alternatives CDN (Priorität 2) → Ursprungsserver.

Wichtige Implementierungsschritte

Schritt 1: Bereitstellen von Voraussetzungen

Konfigurieren Sie Ihren sekundären CDN-Anbieter mit:

  • Azure Front Door mit einer benutzerdefinierten Domäne und einem BYO-Zertifikat konfiguriert.

  • Ein alternatives CDN-Konto.

  • Eine niedrigere DNS-TTL für Ihren CNAME-Eintrag, sodass Azure Front Door Datenverkehr zur niedrigsten Zeiteinstellung bereitstellt.

  • Origin-Server, auf die sowohl Azure Front Door als auch das alternative CDN zugreifen können.

  • Eine benutzerdefinierte Domäne, die DNS-Einträge ändern kann.

Von Bedeutung

Wenn Sie derzeit azure Front Door-verwaltete Zertifikate verwenden, müssen Sie zu BYO-Zertifikaten migrieren, bevor Sie diese HA-Lösung implementieren. Von Azure Front Door verwaltete Zertifikate können nicht exportiert und auf alternativen CDNs installiert werden. Weitere Informationen und Konfigurationsanweisungen für BYO-Zertifikate finden Sie unter Konfigurieren von HTTPS in einer benutzerdefinierten Azure Front Door-Domäne.

Schritt 2: Konfigurieren eines alternativen CDN

Konfigurieren Sie Ihren sekundären CDN-Anbieter:

  • Richten Sie die CDN-Zone oder -Eigenschaft mit Ihrer benutzerdefinierten Domäne ein.

  • Konfigurieren Sie Origin-Server auf die gleiche Weise wie den Azure Front Door-Back-End-Pool.

  • Laden Sie das BYO SSL/TLS-Zertifikat hoch. Dieses Zertifikat ist dasselbe, das Sie in Azure Front Door verwendet haben.

  • Konfigurieren Sie CDN-Zwischenspeicherungsregeln für das Verhalten von Azure Front Door. Konfigurieren Sie z. B. Cachedauern und Abfragezeichenfolgenbehandlung.

  • Richten Sie Zwischenspeicherungseinstellungen, Steuerkopfzeilen und Komprimierungseinstellungen ein, um Ihrer Azure Front Door-Konfiguration zu entsprechen.

  • Richten Sie WAF-Regeln ein, wenn der CDN-Anbieter WAF-Funktionen bietet. Versuchen Sie, der WAF-Richtlinie von Azure Front Door zu entsprechen.

  • Konfigurieren Sie eine benutzerdefinierte Domäne so, dass sie Ihrer benutzerdefinierten Azure Front Door-Domäne entspricht (z. B www.contoso.com. ).

  • Notieren Sie den Hostnamen des CDN-Edges für die Datenverkehrs-Manager-Konfiguration (z. B your-site.cdn.provider.net. ).

Schritt 3: Erstellen eines Traffic Manager-Profils

Wenden Sie die folgenden Konfigurationen an, um das Traffic Manager-Profil zu erstellen. Weitere Informationen finden Sie unter Erstellen eines Traffic Manager-Profils.

Setting Wert Hinweise
Routingmethode Gewichtet Ermöglicht die manuelle Steuerung über den Endpunktstatus (aktiviert oder deaktiviert).
Gewicht 100 Geben Sie 100 ein, wenn das Traffic Manager-Profil erstellt wird, und für beide Endpunkte.
Protokoll HTTPS Erforderlich für die Überprüfung von SSL/TLS-Endpunkten.
Hafen 443 Standardmäßiger HTTPS-Port.
Pfad /index.html Wählen Sie einen schlanken Endpunkt für Integritätsprüfungen.
TTL 300 Sekunden DNS TTL. Niedrigere Werte ermöglichen ein schnelleres Failover, erhöhen aber DNS-Abfragen.

Schritt 4: Konfigurieren von Traffic Manager-Endpunkten

Erstellen Sie zwei Endpunkte im Traffic Manager-Profil.

Verwenden Sie diese Konfigurationen für den primären Endpunkt (Azure Front Door):

  • Typ: Externer Endpunkt

  • Name: endpoint-afd-primary

  • Vollqualifizierter Domänenname (FQDN) oder IP-Adresse: Hostname des Azure Front Door-Endpunkts (z. B myapp-endpoint-12345.z01.azurefd.net. )

  • Gewicht: 100

  • Endpunkt aktivieren: Ursprünglich ausgewählt (aktiviert)

  • Benutzerdefinierte Kopfzeileneinstellungen: Host=$CUSTOM_DOMAIN (erforderlich, damit Azure Front Door zur richtigen benutzerdefinierten Domäne weitergeleitet werden kann)

  • Gesundheitsprüfungen: Immer Verkehr bedienen (Gesundheitsprüfungen deaktivieren)

Screenshot der Konfigurationen zum Hinzufügen eines primären Traffic Manager-Endpunkts im Azure-Portal.

Hinweis

Der --custom-headers "Host=$CUSTOM_DOMAIN" Parameter ist für Azure Front Door-Endpunkte wichtig. Ohne diese Methode leitet Azure Front Door anforderungen möglicherweise nicht ordnungsgemäß an Ihre benutzerdefinierte Domänenkonfiguration weiter. Es ist ein unterstütztes Feature von Azure Traffic Manager.

Verwenden Sie diese Konfigurationen für den sekundären Endpunkt (alternatives CDN):

  • Typ: Externer Endpunkt

  • Name: endpoint-cdn-secondary

  • Vollqualifizierter Domänenname (FQDN) oder IP-Adresse: Hostname des CDN-Edges (z. B. myapp.cdn.net)

  • Gewicht: 100

  • Endpunkt aktivieren: Zunächst gelöscht (deaktiviert) für den Standby-Modus

Screenshot der Konfigurationen zum Hinzufügen eines sekundären Traffic Manager-Endpunkts im Azure-Portal.

Schritt 5: Aktualisieren von DNS-CNAME auf Traffic Manager und Überprüfen des Updates

Warnung

Die folgenden Schritte leiten Ihren Produktionsdatenverkehr direkt von Azure Front Door zu Traffic Manager um. Bevor Sie fortfahren:

  • Testen Sie diese Schritte zuerst in einer Nichtproduktionsumgebung.
  • Verringern Sie die DNS-CNAME-TTL auf den niedrigsten möglichen Wert (z. B. 60-300 Sekunden), mindestens 24 Stunden, bevor Sie Änderungen vornehmen.
  • Planen Sie nach Möglichkeit ein Wartungsfenster in Zeiten mit geringem Datenverkehr.
  • Stellen Sie Rollbackprozeduren bereit, falls Probleme auftreten.

  1. Aktualisieren Sie Ihren DNS-CNAME-Eintrag so, dass er auf Traffic Manager anstatt direkt auf Azure Front Door verweist:

    Feld Alter Wert Neuer Wert
    Name/Host www www (keine Änderung)
    Wert/verweist auf Hostname des Azure Front Door-Endpunkts $ATM_CDN_DNS_NAME.trafficmanager.net

    Die DNS-Verteilung dauert in der Regel 5-10 Minuten, kann jedoch bis zu 48 Stunden global dauern.

  2. Überprüfen Sie die Traffic Manager-Auflösung. Warten Sie auf die DNS-Verteilung, und testen Sie dann die HTTPS-Konnektivität.

    # Verify Traffic Manager profile is resolving
nslookup "$ATM_CDN_DNS_NAME.trafficmanager.net"
# Expected result: Should return IP address of Azure Front Door endpoint

# Check DNS from different resolvers
nslookup $CUSTOM_DOMAIN 8.8.8.8    # Google DNS

# Test HTTPS connectivity
Invoke-WebRequest -Uri "https://$CUSTOM_DOMAIN/index.html" -Method Head
# Expected result: Status code 200

  3. Überwachen Sie nach der DNS-Umstellung die folgenden Azure Front Door Metriken aktiv:

    • Anforderungsanzahl: Die Anzahl sollte konsistent bleiben, ohne dass der Datenverkehr sinkt.

    • Antwortzeit: Die Zeit sollte innerhalb normaler Bereiche verbleiben.

    • Fehlerraten: 4xx/5xx Fehler sollten nicht zunehmen.

    • Ursprungsgesundheit: Backend-Gesundheit sollte beibehalten werden Online.

Schritt 6: Testen von Failoverprozeduren

  1. Manuelles Umschalten auf das alternative CDN:

    # Failover: Disable Azure Front Door and enable CDN
az network traffic-manager endpoint update `
    --name "endpoint-afd-primary" `
    --profile-name $ATM_CDN_PROFILE_NAME `
    --resource-group $RESOURCE_GROUP `
    --type externalEndpoints `
    --endpoint-status Disabled

az network traffic-manager endpoint update `
    --name "endpoint-cdn-secondary" `
    --profile-name $ATM_CDN_PROFILE_NAME `
    --resource-group $RESOURCE_GROUP `
    --type externalEndpoints `
    --endpoint-status Enabled

# Verify endpoint status
az network traffic-manager profile show `
    --name $ATM_CDN_PROFILE_NAME `
    --resource-group $RESOURCE_GROUP `
    --query "endpoints[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus, Target:target}"

# Flush local DNS cache and verify resolution
ipconfig /flushdns
nslookup "$ATM_CDN_DNS_NAME.trafficmanager.net"

# Test HTTPS access
curl --head https://$CUSTOM_DOMAIN/

  2. Failback auf Azure Front Door:

    # Failback: Enable Azure Front Door, disable CDN
az network traffic-manager endpoint update `
    --name "endpoint-afd-primary" `
    --profile-name $ATM_CDN_PROFILE_NAME `
    --resource-group $RESOURCE_GROUP `
    --type externalEndpoints `
    --endpoint-status Enabled

az network traffic-manager endpoint update `
    --name "endpoint-cdn-secondary" `
    --profile-name $ATM_CDN_PROFILE_NAME `
    --resource-group $RESOURCE_GROUP `
    --type externalEndpoints `
    --endpoint-status Disabled

# Verify
az network traffic-manager profile show `
    --name $ATM_CDN_PROFILE_NAME `
    --resource-group $RESOURCE_GROUP `
    --query "endpoints[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus}"

Überwachung

Von Bedeutung

Konfigurieren Sie synthetische Monitore so, dass sie sofort auf Fehler aufmerksam werden. Diese Warnungen sollten manuelles Failover auslösen, wenn das automatische Failover nicht ausreicht (z. B. benutzerdefinierte Azure Front Door-Domänenprobleme, die Traffic Manager nicht erkennen kann).

Wir empfehlen die folgenden Überwachungslösungen für Produktionsumgebungen:

  • Azure Monitor Arbeitsmappen: Überwachen Sie Traffic Manager-Abfragen, Azure Front Door-Anforderungen und den Zustand von Application Gateways. Weitere Informationen finden Sie in der Übersicht über Arbeitsmappen.

  • Externe Überwachung zur Erkennung globaler Azure Front Door-Probleme: Implementieren Sie externe synthetische Überwachungslösungen (z. B. Catchpoint oder ThousandEyes), um Endpunkte zu überwachen. Dienste wie WebPageTest bieten eine kostenlose Alternative, die eingeschränkte globale Sichtbarkeit bietet.

  • Verfügbarkeitstests für Application Insights: Verwenden Sie HTTP-Prüfungen mit mehreren Regionen. Weitere Informationen finden Sie unter Application Insights-Verfügbarkeitstests.

  • DNS-Überwachung: Überprüfen sie die CNAME-Auflösungskette und die TTL-Verteilung über DNSPerf, Pingdom oder Uptime.com.

  • Zertifikatüberwachung: Verwenden Sie den SSL-Servertest von Qualys SSL Labs, um die Konfiguration Ihres Servers zu analysieren.

  • Last updated on