Methoden für das Routing von Datenverkehr an den Ursprung
Wichtig
Azure Front Door (klassisch) wird am 31. März 2027 eingestellt. Um Dienstunterbrechungen zu vermeiden, ist es wichtig, dass Sie Ihre (klassischen) Azure Front Door-Profile bis März 2027 zur Azure Front Door Standard- oder Premium-Stufe migrieren. Weitere Informationen finden Sie unter Einstellung von Azure Front Door (klassisch).
Azure Front Door unterstützt vier Methoden für das Routing von Datenverkehr, um zu verwalten, wie HTTP-/HTTPS-Datenverkehr auf verschiedene Ursprünge verteilt wird. Wenn Benutzeranforderungen Front Door-Edgestandorte erreichen, stellt die konfigurierte Datenverkehrsrouting-Methode sicher, dass die Anforderungen an die Back-End-Ressource weitergeleitet werden, die am besten geeignet ist.
Hinweis
In diesem Artikel bezieht sich Ursprung auf das Back-End und Ursprungsgruppe auf den Back-End-Pool in der Konfiguration von Azure Front Door (klassisch).
Die vier Methoden für das Routing von Datenverkehr sind:
Latenz: Leitet Anforderungen an die Ursprünge mit der niedrigsten Latenz innerhalb eines akzeptablen Empfindlichkeitsbereichs weiter, um sicherzustellen, dass Anforderungen bezogen auf die Netzwerklatenz an die nächstgelegenen Ursprünge gesendet werden.
Priorität: Ermöglicht ihnen, eine Priorität für Ihre Ursprünge festzulegen, wobei ein primärer Ursprung zur Behandlung des gesamten Datenverkehrs und ein sekundärer Ursprung als Sicherung festgelegt wird, falls der primäre nicht verfügbar ist.
Gewichtet: Weist jedem Ursprung eine Gewichtung zu, um den Verkehr gleichmäßig oder entsprechend den angegebenen Gewichtungskoeffizienten zu verteilen. Datenverkehr wird basierend auf Gewichtungswerten verteilt, wenn sich die Latenzen der Ursprünge innerhalb des zulässigen Empfindlichkeitsbereichs befinden.
Sitzungsaffinität: Stellt sicher, dass Anforderungen desselben Endbenutzers an denselben Ursprung gesendet werden, indem für Ihre Front-End-Hosts oder -Domänen die Sitzungsaffinität konfiguriert wird.
Hinweis
Im Standard- und Premium-Tarif von Azure Front Door wird der Endpunktname als Front-End-Host in Azure Front Door (klassisch) bezeichnet.
Alle Azure Front Door-Konfigurationen umfassen die Überwachung der Back-End-Integrität und ein automatisiertes globales Failover. Weitere Informationen finden Sie unter Überwachen von Azure Front Door-Back-Ends. Azure Front Door kann eine einzelne Routingmethode verwenden oder mehrere Methoden kombinieren, um basierend auf den Anforderungen Ihrer Anwendung eine optimale Routingtopologie zu erstellen.
Hinweis
Mithilfe des Front Door-Regelmoduls können Sie für eine Anforderung Regeln zum Überschreiben von Routenkonfigurationen im Standard- und Premium-Tarif von Azure Front Door oder zum Überschreiben des Back-End-Pools in Azure Front Door (klassisch) konfigurieren. Der vom Regelmodul festgelegte Back-End-Pool oder die Ursprungsgruppe überschreibt den in diesem Artikel beschriebenen Routingprozess.
Gesamter Entscheidungsfluss
Das folgende Diagramm zeigt den gesamten Entscheidungsfluss:
Die Entscheidungsschritte sind:
- Verfügbare Ursprünge: Wählen Sie basierend auf dem Integritätstest alle aktivierten und fehlerfreien Ursprünge aus (Statuscode „200 OK“).
- Beispiel: Wenn die sechs Ursprünge A, B, C, D, E und F vorhanden und C fehlerhaft und E deaktiviert ist, dann sind die verfügbaren Ursprünge A, B, D und F.
- Priorität: Wählen Sie unter den verfügbaren Ursprünge diejenigen mit der höchsten Priorität aus.
- Beispiel: Wenn die Ursprünge A, B und D die Priorität 1 haben und der Ursprung F die Priorität 2 hat, sind die ausgewählten Ursprünge A, B und D.
- Latenzsignal (basierend auf Integritätstests): Wählen Sie Ursprünge innerhalb des zulässigen Latenzbereichs aus der Front Door-Umgebung aus, in der die Anforderung eingegangen ist. Dieses basiert auf der Latenzempfindlichkeitseinstellung für die Ursprungsgruppe sowie auf der Latenz der am nächsten gelegenen Ursprünge.
- Beispiel: Wenn die Latenz für den Ursprung A 15 ms, für den Ursprung B 30 ms und für den Ursprung D 60 ms beträgt und die Latenzempfindlichkeit auf 30 ms festgelegt ist, sind die ausgewählten Ursprünge A und B, da D den Bereich von 30 ms überschreitet.
- Gewichtungen: Verteilen Sie den Datenverkehr zwischen den final ausgewählten Ursprüngen basierend auf den angegebenen Gewichtungsverhältnissen.
- Beispiel: Wenn der Ursprung A eine Gewichtung von 3 und der Ursprung B eine Gewichtung von 7 erhalten hat, wird der Datenverkehr im Verhältnis 3/10 auf Ursprung A und 7/10 auf Ursprung B aufgeteilt.
Wenn die Sitzungsaffinität aktiviert ist, folgt die erste Anforderung in einer Sitzung dem oben erläuterten Flow. Nachfolgende Anforderungen werden an den in der ersten Anforderung ausgewählten Ursprung gesendet.
Datenverkehrsrouting auf Grundlage der niedrigsten Latenzen
Durch die Bereitstellung von Ursprüngen an mehreren globalen Standorten kann die Reaktionsfähigkeit Ihrer Anwendung verbessert werden, indem Datenverkehr an den Ursprung weitergeleitet wird, der Ihren Endbenutzern „am nächsten“ ist. Die auf Latenz basierende Routingmethode ist die Standardeinstellung für Azure Front Door-Konfigurationen. Diese Methode leitet Benutzeranforderungen an den Ursprung mit der niedrigsten Netzwerklatenz statt an den nächstgelegenen geografischen Standort weiter, um eine optimale Leistung sicherzustellen.
Die Anycast-Architektur von Azure Front Door in Kombination mit der auf Latenz basierenden Routingmethode stellt sicher, dass jeder Benutzer basierend auf seinem Standort die optimale Leistung erhält. Jede Front Door-Umgebung misst die Latenz zu Ursprüngen unabhängig, d. h. Benutzer an verschiedenen Standorten werden an den Ursprung weitergeleitet, der die beste Leistung für ihre spezifische Umgebung bietet.
Hinweis
Standardmäßig ist die Latenzempfindlichkeit-Eigenschaft auf „0 ms“ festgelegt. Mit dieser Einstellung werden Anforderungen immer an die schnellsten verfügbaren Ursprünge weitergeleitet. Gewichtungen auf den Ursprüngen werden nur wirksam, wenn zwei Ursprünge dieselbe Netzwerklatenz aufweisen.
Weitere Informationen finden Sie unter Azure Front Door-Routingarchitektur.
Prioritätsbasiertes Datenverkehrsrouting
Um Hochverfügbarkeit sicherzustellen, stellen Organisationen häufig Sicherungsdienste bereit, die übernehmen, wenn der primäre Dienst fehlschlägt. Dieses Setup wird als Aktiv/Standby- oder Aktiv/Passiv-Bereitstellung bezeichnet. Mithilfe der auf Priorität basierenden Methode für das Datenverkehrsrouting in Azure Front Door können Sie dieses Failovermuster effektiv implementieren.
Standardmäßig leitet Azure Front Door den Datenverkehr an die Ursprünge mit der höchsten Priorität (dem niedrigsten Prioritätswert) weiter. Wenn diese primären Ursprünge nicht verfügbar sind, leitet es Datenverkehr an die sekundären Ursprünge (mit dem nächstniedrigen Prioritätswert) weiter. Dieser Prozess wird auch mit tertiären Ursprüngen fortgesetzt, wenn sowohl primäre als auch sekundäre Ursprünge nicht verfügbar sind. Integritätstests überwachen die Verfügbarkeit von Ursprüngen basierend auf ihrem konfigurierten Status und ihrer Integrität.
Konfigurieren der Priorität für Ursprünge
Jeder Ursprung in Ihrer Azure Front Door-Ursprungsgruppe verfügt über eine Priorität-Eigenschaft, die auf einen Wert zwischen 1 und 5 festgelegt werden kann. Niedrigere Werte stehen für eine höhere Priorität. Mehrere Ursprünge können denselben Prioritätswert haben.
Gewichtete Methode für das Datenverkehrsrouting
Bei der gewichteten Methode für das Datenverkehrsrouting wird der Datenverkehr basierend auf einer vordefinierte Gewichtung verteilt.
Bei dieser Methode weisen Sie jedem Ursprung in Ihrer Azure Front Door-Ursprungsgruppe eine Gewichtung zu. Die Gewichtung ist eine ganze Zahl zwischen 1 und 1000, wobei der Standardwert bei 50 liegt.
Der Datenverkehr wird mithilfe eines Roundrobin-Mechanismus basierend auf den angegebenen Gewichtungsverhältnissen auf die verfügbaren Ursprünge verteilt, sofern sie die Anforderung an die akzeptable Latenzempfindlichkeit erfüllen. Wenn die Latenzempfindlichkeit auf 0 Millisekunden festgelegt ist, werden Gewichtungen nur wirksam, wenn zwei Ursprünge dieselbe Netzwerklatenz aufweisen.
Die gewichtete Methode unterstützt mehrere Szenarien:
- Allmähliches Anwendungsupgrade: Leiten Sie einen Prozentsatz des Datenverkehrs an einen neuen Ursprung, und erhöhen Sie ihn dann im Lauf der Zeit allmählich.
- Anwendungsmigration zu Azure: Erstellen Sie eine Ursprungsgruppe mit Azure-Ursprüngen und externen Ursprüngen. Passen Sie die Gewichtungen so an, dass neue Ursprünge bevorzugt werden, wodurch Sie ihren Anteil am Datenverkehr allmählich erhöhen, bis sie den meisten Datenverkehr verarbeiten. Deaktivieren und entfernen Sie dann weniger bevorzugte Ursprünge.
- Cloudbursting für zusätzliche Kapazität: Erweitern Sie lokale Bereitstellungen in der Cloud, indem Sie weitere Ursprünge hinzufügen oder aktivieren und die Verteilung des Datenverkehrs angeben.
Sitzungsaffinität
Standardmäßig leitet Azure Front Door Anforderungen vom gleichen Client an verschiedene Ursprünge weiter. Die Sitzungsaffinität ist jedoch für zustandsbehaftete Anwendungen oder Szenarien nützlich, in denen nachfolgende Anforderungen desselben Benutzers vom gleichen Ursprung verarbeitet werden müssen. Diese Funktion stellt sicher, dass derselbe Ursprung die gesamte Sitzung eines Benutzers behandelt, was für Szenarien wie die Clientauthentifizierung von Vorteil ist.
Azure Front Door verwendet cookiebasierte Sitzungsaffinität, bei der verwaltete Cookies mit SHA256 der Ursprungs-URL als Bezeichner verwendet werden. Dadurch wird der nachfolgende Datenverkehr von einer Benutzersitzung an denselben Ursprung geleitet.
Sitzungsaffinität kann für jede konfigurierte Domäne oder Unterdomäne im Standard- und Premium-Tarif von Azure Front Door auf der Ebene der Ursprungsgruppe und in Azure Front Door (klassisch) auf der Ebene des Front-End-Hosts aktiviert werden. Nach der Aktivierung fügt Azure Front Door der Sitzung des Benutzers Cookies mit den Namen ASLBSA
und ASLBSACORS
hinzu. Diese Cookies helfen dabei, unterschiedliche Benutzer zu identifizieren, auch wenn sie sich die gleiche IP-Adresse teilen. Dadurch wird eine gleichmäßigere Verteilung des Datenverkehrs zwischen Ursprüngen ermöglicht.
Die Lebensdauer des Cookies ist identisch mit der der Benutzersitzung, da Front Door derzeit nur Sitzungscookies unterstützt.
Hinweis
Die Sitzungsaffinität wird über das Browsersitzungscookie auf Domänenebene verwaltet. Unterdomänen unter derselben Platzhalterdomäne können die Sitzungsaffinität gemeinsam nutzen, solange der Browser des Benutzers Anforderungen für dieselbe Ursprungsressource sendet.
Öffentliche Proxys können die Sitzungsaffinität beeinträchtigen, da das Einrichten einer Sitzung Front Door erfordert, um der Antwort ein Sitzungsaffinitätscookie hinzuzufügen. Das ist unmöglich, wenn die Antwort zwischengespeichert werden kann, da dies Cookies für andere Clients unterbrechen würde, die dieselbe Ressource anfordern. Um dies zu verhindern, wird die Sitzungsaffinität nicht hergestellt, wenn der Ursprung bei einem Versuch eine zwischenspeicherbare Antwort sendet. Wenn die Sitzung bereits eingerichtet ist, spielt die Zwischenspeicherbarkeit der Antwort keine Rolle.
Die Sitzungsaffinität wird über die Standardszenarien ohne Zwischenspeicherung hinaus unter den folgenden Umständen hergestellt:
- Die Antwort enthält den
Cache-Control
-Header mit dem Wert no-store. - Die Antwort enthält einen gültigen
Authorization
-Header. - Die Antwort ist ein HTTP 302-Statuscode.
Nächste Schritte
- Erfahren Sie, wie Sie eine Azure Front Door-Instanz erstellen.
- Erfahren Sie mehr über die Funktionsweise von Azure Front Door.