Metody směrování provozu do původu

Důležité

Služba Azure Front Door (Classic) bude vyřazena 31. března 2027. Abyste se vyhnuli přerušení služeb, je důležité do března 2027 migrovat profily služby Azure Front Door (Classic) na úroveň Azure Front Door Standard nebo Premium. Další informace najdete v části Vyřazení služby Azure Front Door (Classic).

Azure Front Door podporuje čtyři metody směrování provozu ke správě způsobu distribuce provozu HTTP/HTTPS mezi různé zdroje. Když se požadavky uživatelů dostanou do hraničních umístění služby Front Door, nakonfigurovaná metoda směrování zajistí, že se požadavky přesměrují na nejlepší back-endový prostředek.

Poznámka:

V tomto článku odkazuje origin na back-end a skupina původu odkazuje na back-endový fond v konfiguraci služby Azure Front Door (Classic).

Čtyři metody směrování provozu jsou:

• Latence: Směruje požadavky na původ s nejnižší latencí v přijatelném rozsahu citlivosti a zajišťuje odesílání požadavků do nejbližšího původu z hlediska latence sítě.

• Priorita: Umožňuje nastavit prioritu pro původ a navrhnout primární zdroj pro zpracování veškerého provozu a sekundárního původu jako zálohy, pokud primární server přestane být dostupný.

• Vážené: Přiřadí každému zdroji váhu k rovnoměrné distribuci provozu nebo podle zadaných koeficientů hmotnosti. Provoz se distribuuje na základě hodnot váhy, pokud jsou latence původu v přijatelném rozsahu citlivosti.

• Spřažení relací: Zajišťuje odesílání požadavků od stejného koncového uživatele do stejného zdroje konfigurací spřažení relace pro hostitele nebo domény front-endu.

Poznámka:

V úrovních Azure Front Door Standard a Premium se název koncového bodu označuje jako hostitel front-endu ve službě Azure Front Door (Classic).

Všechny konfigurace služby Front Door zahrnují monitorování stavu back-endu a automatizované globální převzetí služeb při selhání. Další informace najdete v tématu Monitorování back-endu služby Front Door. Azure Front Door může použít jednu metodu směrování nebo zkombinovat více metod k vytvoření optimální topologie směrování na základě potřeb vaší aplikace.

Poznámka:

Pomocí stroje pravidel služby Front Door můžete nakonfigurovat pravidla pro přepsání konfigurací tras ve úrovních Azure Front Door Standard a Premium nebo přepsání back-endového fondu ve službě Azure Front Door (Classic) pro žádost. Skupina původu nebo back-endový fond nastavený modulem pravidel přepíše proces směrování popsaný v tomto článku.

Celkový rozhodovací tok

Následující diagram znázorňuje celkový tok rozhodování:

Rozhodovací kroky jsou:

1. Dostupné zdroje: Na základě sondy stavu vyberte všechny zdroje, které jsou povolené a v pořádku (200 OK).
   • Příklad: Pokud existuje šest původů A, B, C, D, E a F a C není v pořádku a E je zakázáno, dostupné zdroje jsou A, B, D a F.
2. Priorita: Vyberte zdroje s nejvyšší prioritou z dostupných zdrojů.
   • Příklad: Pokud zdroje A, B a D mají prioritu 1 a počáteční F má prioritu 2, vybrané zdroje jsou A, B a D.
3. Signál latence (na základě sondy stavu): Vyberte původy v rozsahu povolené latence z prostředí služby Front Door, ve kterém žádost přišla. Vychází z nastavení citlivosti latence skupiny původu a latence nejbližších původů.
   • Příklad: Pokud je latence zdroje A 15 ms, na B je 30 ms a D je 60 ms a citlivost latence je nastavená na 30 ms, vybrané zdroje jsou A a B, protože D překračuje rozsah 30 ms.
4. Váhy: Distribuujte provoz mezi konečné vybrané zdroje na základě zadaných poměrů hmotnosti.
   • Příklad: Pokud má původ A váhu 3 a původ B má hmotnost 7, provoz se distribuuje 3/10 do A a 7/10 až B.

Pokud je povolené spřažení relace, první požadavek v relaci se řídí předchozím vysvětlením toku. Další požadavky se posílají do zdroje vybraného v prvním požadavku.

Nejnižší latence na základě směrování provozu

Nasazení původu v několika globálních umístěních může zvýšit rychlost odezvy vaší aplikace směrováním provozu do zdroje, který je "nejblíže" koncovým uživatelům. Metoda směrování latence je výchozí pro konfigurace služby Azure Front Door. Tato metoda směruje požadavky uživatelů na původ s nejnižší latencí sítě, nikoli s nejbližším geografickým umístěním a zajišťuje optimální výkon.

Architektura libovolného vysílání služby Azure Front Door v kombinaci s metodou směrování latence zajišťuje, aby každý uživatel na základě jejich umístění zajistil nejlepší výkon. Každé prostředí služby Front Door nezávisle měří latenci původu, což znamená, že uživatelé v různých umístěních se směrují na zdroj, který nabízí nejlepší výkon pro konkrétní prostředí.

Poznámka:

Ve výchozím nastavení je vlastnost citlivosti latence nastavená na 0 ms. Při tomto nastavení se požadavky vždy předávají nejrychlejším dostupným zdrojům. Váhy původu se projeví jenom v případě, že dva původy mají stejnou latenci sítě.

Další informace najdete v tématu Architektura směrování služby Azure Front Door.

Směrování provozu na základě priority

Aby organizace zajistily vysokou dostupnost, často nasazují služby zálohování, které se převezmou v případě selhání primární služby. Toto nastavení se označuje jako aktivní/pohotovostní nebo aktivní/pasivní nasazení. Metoda prioritního směrování provozu ve službě Azure Front Door umožňuje efektivně implementovat tento model převzetí služeb při selhání.

Ve výchozím nastavení Azure Front Door směruje provoz do původu s nejvyšší prioritou (nejnižší hodnotou priority). Pokud se tyto primární zdroje stanou nedostupnými, směruje provoz do sekundárních zdrojů (další hodnota s nejnižší prioritou). Tento proces pokračuje terciárním původem, pokud primární i sekundární původ nejsou k dispozici. Sondy stavu monitorují dostupnost zdrojů na základě jejich nakonfigurovaného stavu a stavu.

Konfigurace priority pro zdroje

Každý původ ve skupině původu služby Azure Front Door má vlastnost Priority , která se dá nastavit na hodnotu mezi 1 a 5. Nižší hodnoty označují vyšší prioritu. Stejnou hodnotu priority může sdílet více zdrojů.

Vážená metoda směrování provozu

Metoda váženého směrování provozu umožňuje distribuovat provoz na základě předdefinovaných váhy.

V této metodě přiřadíte váhu každému původu ve skupině původu služby Azure Front Door. Váha je celé číslo od 1 do 1000 s výchozí hodnotou 50.

Provoz se distribuuje mezi dostupné zdroje pomocí mechanismu kruhového dotazování na základě zadaného poměru hmotnosti za předpokladu, že původy splňují přijatelnou citlivost latence. Pokud je citlivost latence nastavená na 0 milisekund, projeví se váhy pouze v případě, že dva zdroje mají stejnou latenci sítě.

Vážená metoda podporuje několik scénářů:

• Postupný upgrade aplikace: Směrujte procento provozu do nového původu a postupně ho v průběhu času zvyšte.
• Migrace aplikací do Azure: Vytvořte skupinu původu s Azure i externími zdroji. Upravte váhy tak, aby preferovaly nové původy, postupně se zvětšovaly jejich sdílení provozu, dokud nezpracují většinu provozu, a pak zakažte a odeberte méně upřednostňované zdroje.
• Rozšíření cloudu pro další kapacitu: Rozšíření místních nasazení do cloudu přidáním nebo povolením dalších zdrojů a určením distribuce provozu

Spřažení relací

Azure Front Door ve výchozím nastavení předává požadavky ze stejného klienta do různých zdrojů. Spřažení relací je však užitečné pro stavové aplikace nebo scénáře, kdy následné požadavky od stejného uživatele musí být zpracovány stejným původem. Tato funkce zajišťuje, že stejný zdroj zpracovává relaci uživatele, což je výhodné pro scénáře, jako je ověřování klientů.

Azure Front Door používá spřažení relací na základě souborů cookie, kdy se používají spravované soubory cookie s SHA256 původní adresy URL. Tím se směruje následný provoz z uživatelské relace do stejného původu.

Spřažení relací je možné povolit na úrovni skupiny původu v úrovních Azure Front Door Standard a Premium a na úrovni hostitele front-endu ve službě Azure Front Door (Classic) pro každou nakonfigurovanou doménu nebo subdoménu. Po povolení služba Azure Front Door přidá soubory cookie s názvem ASLBSA a ASLBSACORS do relace uživatele. Tyto soubory cookie pomáhají identifikovat různé uživatele, i když sdílejí stejnou IP adresu, což umožňuje rovnoměrnější distribuci provozu mezi zdroji.

Životnost souboru cookie odpovídá relaci uživatele, protože služba Front Door v současné době podporuje pouze soubory cookie relace.

Poznámka:

Spřažení relací se udržuje prostřednictvím souboru cookie relace prohlížeče na úrovni domény. Subdomény ve stejné doméně se zástupným znakem můžou sdílet spřažení relací, pokud prohlížeč uživatele odesílá požadavky na stejný zdroj prostředku původu.

Veřejné proxy servery můžou kolidovat se spřažením relací, protože vytvoření relace vyžaduje, aby služba Front Door přidala do odpovědi soubor cookie spřažení relací. Tuto možnost nelze provést, pokud je odpověď uložená v mezipaměti, protože by narušovala soubory cookie pro ostatní klienty, kteří požadují stejný prostředek. Aby tomu tak nebylo možné, přidružení relace se nenaváže , pokud zdroj odešle odpověď s možnou mezipamětí. Pokud je relace již navázána, nepůleže na mezipaměti odpovědi.

Spřažení relací se vytvoří za následujících okolností nad rámec standardních scénářů, které se nedají uložit do mezipaměti:

• Odpověď obsahuje hlavičku Cache-Control bez uložení.
• Odpověď obsahuje platnou Authorization hlavičku.
• Odpověď je stavový kód HTTP 302.

Další kroky

• Zjistěte, jak vytvořit Azure Front Door.
• Zjistěte , jak Azure Front Door funguje.