Freigeben über


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 verschiedene Methoden für das Routing von Datenverkehr, um zu bestimmen, wie HTTP-/HTTPS-Datenverkehr auf verschiedene Ursprünge verteilt wird. Wenn Benutzeranforderungen Front Door-Edgestandorte erreichen, wird die konfigurierte Datenverkehrsrouting-Methode angewendet, um sicherzustellen, dass die Anforderungen an die Back-End-Ressource weitergeleitet werden, die am besten geeignet ist.

Hinweis

In diesem Artikel beziehen sich Ursprung und Ursprungsgruppe auf das Back-End und den Back-End-Pool der Konfiguration von Azure Front Door (klassisch).

Die vier Methoden für das Routing von Datenverkehr sind:

  • Latenz: Durch latenzbasiertes Routing wird sichergestellt, dass Anforderungen an diejenigen Ursprünge gesendet werden, die innerhalb eines akzeptablen Empfindlichkeitsbereichs die niedrigste Latenz aufweisen. Anders ausgedrückt: Anforderungen werden an den nächstgelegenen Satz von Ursprüngen bezogen auf die Netzwerklatenz gesendet.

  • Priorität: Sie können eine Priorität für Ihre Ursprünge festlegten, wenn Sie einen primären Ursprung für die Verarbeitung des gesamten Datenverkehrs konfigurieren möchten. Beim sekundären Ursprung kann es sich um eine Sicherung handeln, falls der primäre Ursprung nicht verfügbar ist.

  • Gewichtet: Sie können Ihren Ursprüngen einen gewichteten Wert zuweisen, wenn Sie Datenverkehr gleichmäßig oder gemäß Gewichtungskoeffizienten auf eine Gruppe von Ursprüngen verteilen möchten. Der Datenverkehr wird anhand des Gewichtungswerts verteilt, wenn die Latenzen der Ursprünge innerhalb des akzeptablen Latenzempfindlichkeitsbereichs in der Ursprungsgruppe liegen.

  • Sitzungsaffinität: Sie können die Sitzungsaffinität für Ihre Front-End-Hosts oder -Domänen konfigurieren, um sicherzustellen, dass Anforderungen desselben Endbenutzers an denselben Ursprung gesendet werden.

Hinweis

Der Endpunktname auf der Standard- und der Premium-Ebene von Azure Front Door heißt Front-End-Host in Azure Front Door (klassisch).

Alle Azure Front Door-Konfigurationen verfügen über die Überwachung der Back-End-Integrität und ein automatisiertes, sofortiges und globales Failover. Weitere Informationen finden Sie unter Überwachen von Azure Front Door-Back-Ends. Azure Front Door kann mit einer einzelnen Routingmethode verwendet werden. Abhängig von den Anforderungen Ihrer Anwendung können Sie mehrere Routingmethoden kombinieren, um eine optimale Routingtopologie zu erstellen.

Hinweis

Wenn Sie das Front Door-Regelmodul verwenden, können Sie eine Regel zum Überschreiben von Routenkonfigurationen auf der Standard- und der Premium-Ebene von Azure Front Door oder zum Überschreiben des Back-End-Pools in Azure Front Door (klassisch) für eine Anforderung konfigurieren. Der vom Regelmodul festgelegte Back-End-Pool überschreibt den in diesem Artikel beschriebenen Routingprozess.

Gesamter Entscheidungsfluss

Das folgende Diagramm zeigt den gesamten Entscheidungsfluss:

Diagramm, das erläutert, wie Ursprünge basierend auf Einstellungen für Priorität, Latenz und Gewichtung in Azure Front Door ausgewählt werden.

Die Entscheidungsschritte sind:

  1. Verfügbare Ursprünge: Wählen Sie alle aktivierten Ursprünge aus, die bei einem Integritätstest den Statuscode „200 OK“ zurückgeben und daher als fehlerfrei beurteilt werden.
    • Beispiel: Angenommen, es sind sechs Ursprünge A, B, C, D, E und F vorhanden. C ist fehlerhaft und E deaktiviert. Die Liste der verfügbaren Ursprünge umfasst damit A, B, D und F.
  2. Priorität: Von den verfügbaren Ursprünge werden diejenigen mit der höchsten Priorität ausgewählt.
    • Beispiel: Angenommen, den Ursprüngen A, B und D ist als Priorität 1 und dem Ursprung F die Priorität 2 zugeordnet. Die ausgewählten Ursprünge sind dann A, B und D.
  3. Latenzsignal (basierend auf Integritätstests): Wählen Sie die Ursprünge innerhalb des zulässigen Latenzbereichs aus der Front Door-Umgebung aus, in der die Anforderung eingegangen ist. Dieses Signal basiert auf der Latenzempfindlichkeitseinstellung für die Ursprungsgruppe sowie auf der Latenz der näher gelegenen Ursprünge.
    • Beispiel: Angenommen, Front Door hat die Latenz aus der Umgebung, in der die Anforderung bei Ursprung A eingegangen ist, als 15 ms gemessen. Die Latenz für B beträgt 30 ms und die für D 60 ms. Wenn die Latenzempfindlichkeit der Ursprungsgruppe auf 30 ms festgelegt ist, besteht der niedrigste Latenzpool aus den Ursprüngen A und B, da D mehr als 30 ms vom nächstgelegenen Ursprung (also A) entfernt ist.
  4. Gewichtungen: Abschließend führt Azure Front Door für den Datenverkehr der zuletzt ausgewählten Gruppe von Ursprüngen einen Roundrobin entsprechend der festgelegten Gewichtungen durch.
    • Beispiel: Wenn Ursprung A eine Gewichtung von 3 und Ursprung B eine Gewichtung von 7 zugeordnet ist, 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 aufgeführten Flow. Nachfolgende Anforderungen werden an den in der ersten Anforderung ausgewählten Ursprung gesendet.

Datenverkehrsrouting auf Grundlage der niedrigsten Latenzen

Die Reaktionsfähigkeit Ihrer Anwendungen kann verbessert werden, indem Sie Ursprünge an mindestens zwei Standorten auf der Welt bereitstellen und Datenverkehr an das Ziel weiterleiten, das den Endbenutzern am „nächsten“ liegt. Latenz ist die Standardmethode für das Routing von Datenverkehr für ihre Front Door-Konfiguration. Diese Routingmethode leitet Anforderungen von Ihren Endbenutzern an den nächstgelegenen Ursprung hinter Azure Front Door weiter. In Kombination mit der Anycast-Architektur von Azure Front Door stellt dieser Routingmechanismus sicher, dass Ihre Endbenutzer je nach Standort von maximaler Leistung profitieren.

Der nächstgelegene Ursprung ist nicht unbedingt derjenige, der geografisch am nächsten liegt. Azure Front Door ermittelt den nächstgelegenen Ursprung durch die Messung der Netzwerklatenz. Weitere Informationen finden Sie unter Azure Front Door-Routingarchitektur.

Jede Front Door-Umgebung misst die Ursprungslatenz separat. Das bedeutet, dass verschiedene Benutzer an unterschiedlichen Standorten mit der besten Leistung für diese Umgebung an den Ursprung weitergeleitet werden.

Hinweis

Standardmäßig ist die Latenzempfindlichkeit-Eigenschaft auf „0 ms“ festgelegt. Mit dieser Einstellung wird die Anforderung immer an die schnellsten verfügbaren Ursprünge weitergeleitet, und Gewichtungen für den Ursprung werden nur wirksam, wenn zwei Ursprünge die gleiche Netzwerklatenz aufweisen.

Prioritätsbasiertes Datenverkehrsrouting

Häufig möchte eine Organisation Hochverfügbarkeit für ihre Dienste gewährleisten, indem sie mehr als einen Sicherungsdienst für den Fall eines Ausfalls des primären Diensts bereitstellt. Diese Art der Topologie wird branchenweit als Aktiv/Standby- oder Aktiv/Passiv-Bereitstellung bezeichnet. Mithilfe der prioritätsbasierten Methode für das Datenverkehrsrouting können Sie dieses Failovermuster problemlos implementieren.

Die Standardkonfiguration von Azure Front Door enthält eine Liste mit Ursprüngen, denen dieselbe Priorität zugeordnet ist. Azure Front Door leitet Datenverkehr standardmäßig nur an die Ursprünge mit der höchsten Priorität (dem niedrigsten Wert für die Priorität) und damit an die primären Ursprünge weiter. Wenn die primären Ursprünge nicht verfügbar sind, wird der Datenverkehr von Azure Front Door an die sekundären Ursprünge (diejenigen, denen der zweitniedrigste Wert für die Priorität zugeordnet wurde) weitergeleitet. Wenn weder die primärem noch die sekundären Ursprünge verfügbar sind, wird der Datenverkehr an den dritten Ursprung gesendet usw. Die Verfügbarkeit des Ursprungs basiert auf dem konfigurierten Status und dem Integritätsstatus des Ursprungs, der regelmäßig durch Integritätstests ermittelt wird.

Konfigurieren der Priorität für Ursprünge

Jeder Ursprung in Ihrer Ursprungsgruppe der Azure Front Door-Konfiguration verfügt über die Eigenschaft Priority (Priorität), die eine Zahl zwischen 1 und 5 sein kann. In Azure Front Door können Sie die Priorität für jeden Ursprung explizit mithilfe dieser Eigenschaft konfigurieren. mithilfe dieser Eigenschaft festlegen. Je niedriger der Wert, desto höher die Priorität. Ursprünge können dieselben Werte für die Priorität haben.

Gewichtete Methode für das Datenverkehrsrouting

Bei der gewichteten Methode für das Datenverkehrsrouting wird der Datenverkehr gleichmäßig verteilt oder eine vordefinierte Gewichtung angewandt.

Bei der gewichteten Methode für das Datenverkehrsrouting weisen Sie jedem Ursprung in der Azure Front Door-Konfiguration Ihrer Ursprungsgruppe eine Gewichtung zu. Die Gewichtung wird als ganzzahliger Bereich zwischen 1 und 1000 angegeben. Als Standardgewichtung für den Parameter wird 50 verwendet.

Mit der Liste der verfügbaren Ursprünge, die eine akzeptable Latenzempfindlichkeit aufweisen, wird der Datenverkehr mit einem Roundrobin-Mechanismus unter Verwendung des angegebenen Gewichtungsverhältnisses verteilt. Wenn für die Latenzempfindlichkeit ein Wert von 0 Millisekunden festgelegt ist, wird diese Eigenschaft nur dann berücksichtigt, wenn die Netzwerklatenz für zwei Ursprünge gleich ist.

Durch die gewichtete Methode werden einige nützliche Szenarios ermöglicht:

  • Allmähliches Anwendungsupgrade: Es wird ein Prozentwert für den Datenverkehr angegeben, der an einen neuen Ursprung weitergeleitet werden soll, und der Datenverkehr wird dann im Laufe der Zeit allmählich erhöht, bis dessen Umfang dem anderer Ursprünge entspricht.
  • Anwendungsmigration zu Azure: Erstellen Sie eine Ursprungsgruppe mit Azure-Ursprüngen und externen Ursprüngen. Passen Sie die Gewichtung der Ursprünge so an, dass neue Ursprünge priorisiert werden. Sie können diese Änderungen schrittweise einführen, in dem Sie zuerst neue Ursprünge deaktivieren, ihnen anschließend die niedrigsten Gewichtungen zuweisen und die Werte dann langsam erhöhen, bis die Ursprünge den größten Teil des Datenverkehrs übernehmen. Abschließend deaktivieren Sie die weniger bevorzugten Ursprünge und entfernen diese aus der Gruppe.
  • Cloudbursting für zusätzliche Kapazität: Stellen Sie in kurzer Zeit für eine lokale Bereitstellung zusätzliche Ressourcen in der Cloud zur Verfügung, indem Sie Azure Front Door Service verwenden. Wenn Sie zusätzliche Kapazität in der Cloud benötigen, können Sie weitere Ursprünge hinzufügen oder aktivieren und dabei angeben, welcher Teil des Datenverkehrs an den jeweiligen Ursprung gesendet wird.

Sitzungsaffinität

Standardmäßig leitet Azure Front Door ohne Sitzungsaffinität Anforderungen, die vom gleichen Client stammen, an verschiedene Ursprünge weiter. In bestimmten zustandsbehafteten Anwendungen oder in bestimmten anderen Szenarien wird jedoch bevorzugt, dass nachfolgende Anforderungen eines Benutzers immer an denselben Ursprung gesendet werden, der die ursprüngliche Anforderung verarbeitet hat. Die cookiebasierte Sitzungsaffinitätsfunktion ist nützlich, wenn Sie eine Benutzersitzung am selben Ursprung beibehalten möchten, z. B. Szenarien, in denen Clients sich beim Ursprung authentifizieren. Wenn Sie verwaltete Cookies mit SHA256 der Ursprungs-URL als Bezeichner im Cookie verwenden, kann Azure Front Door den nachfolgenden Datenverkehr von einer Benutzersitzung zur Verarbeitung an denselben Ursprung weiterleiten.

Sitzungsaffinität kann für jede Ihrer konfigurierten Domänen (oder Unterdomänen) auf der Standard- und der Premium-Ebene von Azure Front Door auf der Ursprungsgruppenebene und in Azure Front Door (klassisch) auf der Front-End-Hostebene aktiviert werden. Nach der Aktivierung fügt Azure Front Door der Sitzung des Benutzers ein Cookie hinzu. Die Cookies heißen ASLBSA und ASLBSACORS. Mithilfe der cookiebasierten Sitzungsaffinität kann Azure Front Door verschiedene Benutzer auch dann identifizieren, wenn für diese die gleiche IP-Adresse verwendet wird. Dadurch kann der Datenverkehr wiederum gleichmäßiger zwischen Ihren unterschiedlichen Ursprüngen verteilt werden.

Die Lebensdauer des Cookies ist identisch mit derjenigen der Benutzersitzung, da Azure Front Door Service derzeit nur Sitzungscookies unterstützt.

Hinweis

Unabhängig davon, wo die Sitzungsaffinität konfiguriert ist, wird sie über das Browsersitzungscookie auf Domänenebene gespeichert. Unterdomänen unter derselben Platzhalterdomäne können die Sitzungsaffinität gemeinsam nutzen, solange derselbe Benutzerbrowser Anforderungen für dieselbe Ursprungsressource sendet.

Öffentlichen Proxys können die Sitzungsaffinität beeinträchtigen. Grund dafür ist, dass Front Door zum Einrichten einer Sitzung ein Sitzungsaffinitätscookie zur Antwort hinzufügen muss. Dies ist jedoch nicht möglich, wenn die Antwort zwischengespeichert werden kann, da dies die Cookies anderer Clients, die die gleiche Ressource anfordern, beeinträchtigen würde. 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 es keine Rolle, ob die Antwort des Ursprungs zwischengespeichert werden kann.

Die Sitzungsaffinität wird über die Standardszenarien ohne Zwischenspeicherung hinaus unter den folgenden Umständen hergestellt:

  • Die Antwort muss im Cache-Control-Header den Wert no-store enthalten.
  • Wenn die Antwort einen Authorization-Header enthält, darf dieser noch nicht abgelaufen sein.
  • Die Antwort ist ein HTTP 302-Statuscode.

Nächste Schritte