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

Platí pro: ✔️ Front Door Standard ✔️ Front Door Premium ✔️ Front Door (Classic)

Důležité

Azure Front Door (Classic) bude vyřazena 31. března 2027. Protože služba končí, již nepodporuje vytváření profilů, nové doménové onboardingy ani spravované certifikáty. Pokud se chcete vyhnout přerušení služeb, migrovat na Azure Front Door Standard nebo Premium. Další informace najdete v tématu Azure Front Door (klasické) vyřazení.

Azure Front Door v rámci správy způsobu distribuce přenosu HTTP/HTTPS mezi různé zdroje podporuje čtyři metody směrování přenosu. Když se požadavky uživatelů dostanou do okrajových umístění služby Front Door, nakonfigurovaná metoda směrování zajistí, že budou přesměrovány na nejlepší backendový zdroj.

Poznámka:

V tomto článku Origin označuje back-end a skupina zdrojů označuje fond back-endů 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 vaše zdroje, označit primární zdroj pro zpracování veškeré provozní zátěže a sekundární zdroj jako záložní, pokud se primární stane nedostupným.

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

• Vazba relací: Zajišťuje, že požadavky od stejného koncového uživatele jsou odesílány do stejného zdroje nastavením vazby relací pro vaše front-end hostitele nebo domény.

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 backendu a automatizované globální zotavení po 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í pravidlového modulu Front Door můžete nakonfigurovat pravidla pro přepsání konfigurací tras v úrovních Azure Front Door Standard a Premium nebo přepsání fondu back-endů v Azure Front Door (classic) pro požadavek. 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é původy: Vyberte všechny původy, které jsou povolené a v pořádku (200 OK) na základě zdravotní kontroly.
   • 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 zdroje v rozsahu povolené latence z prostředí služby Front Door, kam žádost přišla. Tento rozsah 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á zdroj A váhu 3 a zdroj B váhu 7, provoz se distribuuje 3/10 k A a 7/10 k B.

Pokud povolíte spřažení relací, první požadavek v relaci se řídí dříve vysvětleným tokem. Další žádosti přejdou na původ vybraný 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í pomocí 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.

Anycastová architektura služby Azure Front Door v kombinaci s metodou směrování na základě latence zajišťuje, že každý uživatel zažije co nejlepší výkon v závislosti na svém umístění. 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 na původech se uplatní 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

Pokud chcete zajistit vysokou dostupnost, nasaďte služby backup, které se mají převzít, pokud primární služba selže. Toto nastavení se označuje jako aktivní/pohotovostní nebo aktivní/pasivní nasazení. Metoda směrování provozu Priority v Azure Front Door vám pomůže tento model převzetí služeb při selhání implementovat.

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 zdraví.

Konfigurace priority pro zdroje

Každý zdroj ve skupině původu Azure Front Door má vlastnost Priority, kterou můžete nastavit na hodnotu v rozmezí 1 až 5. Nižší hodnoty označují vyšší prioritu. Více zdrojů může mít stejnou prioritu.

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

Poznámka:

Pro zákazníky s velmi nízkým RPS (požadavky za sekundu), kvůli distribuované povaze Azure Front Door bodů přítomnosti (POP) a strojů, Azure Front Door nemůže zaručit, že váhy, které konfigurujete, jsou přísně dodržovány, a vyvažování zátěže může působit zkresleně.

Metoda vážená směrování provozu distribuuje provoz na základě předdefinovaných vah.

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 mezi 1 a 1 000 a výchozí hodnotou 50.

Provoz se distribuuje mezi dostupné zdroje pomocí mechanismu kruhového dotazování založeného na zadaných poměrech hmotnosti za předpokladu, že původy splňují přijatelnou citlivost latence. Pokud nastavíte citlivost latence 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é zdroje, a postupně zvyšujte jejich podíl na provozu, dokud nezpracovávají většinu provozu, poté 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

Vazba relace

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 pro scénáře, kdy následné požadavky od stejného uživatele musí být zpracovány stejným zdrojem. Tato funkce zaručuje, že relaci uživatele zpracovává stejný zdroj, což je výhodné pro scénáře typu 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 zdrojové URL jako identifikátorem. Tato metoda směruje pozdější provoz z uživatelské relace do stejného zdroje.

Spřažení relací můžete povolit na úrovni skupiny původu v úrovních Azure Front Door Standard a Premium a na úrovni hostitele front-endu v Azure Front Door (classic) pro každou nakonfigurovanou doménu nebo subdoménu. Když tuto funkci povolíte, Azure Front Door do relace uživatele přidá soubory cookie s názvem ASLBSA a ASLBSACORS. 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 je shodná s relací uživatele, protože služba Front Door v současné době podporuje pouze cookies pro relace.

Poznámka:

Soubor cookie relace prohlížeče udržuje spřažení relací na úrovni domény. Subdomény pod stejnou zástupnou doménou mohou sdílet afinitu relací, pokud prohlížeč uživatele odesílá požadavky na stejný původní zdroj.

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 akci 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. Chcete-li zabránit tomuto problému, spřažení relace není nastaveno, pokud zdroj odešle odpověď, kterou lze ukládat do mezipaměti. Pokud je relace již navázána, nezáleží na ukládání odpovědi do mezipaměti.

Afinitu relací se vytváří za následujících okolností nad rámec standardních scénářů, které nejsou ukládány do mezipaměti:

• Odpověď obsahuje hlavičku Cache-Control s no-store.
• 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.