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

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

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é, abyste do března 2027 migrovali 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 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 mechanismu služby Front Door můžete nakonfigurovat pravidla pro přepsání konfigurací tras na úrovních Azure Front Door Standard a Premium nebo přepsání back-endového poolu ve službě Azure Front Door (Classic) pro žádost. Skupina zdroje nebo back-endový pool nastavený procesorem 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. 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 je povoleno spřažení relace, první požadavek v relaci následuje dříve vysvětlený tok. 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í 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

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

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. 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ými RPS (požadavky za sekundu), vzhledem k způsobu distribuce AFD POPů a počítačů, nemůžeme zaručit, že zákazníkem nastavené váhy budou striktně dodrženy a vyrovnávání zatížení se může zdát nevyvážené.

Metoda váženého směrování provozu umožňuje distribuovat provoz podle 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 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ých váhových poměrů, pokud zdroje 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é 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. Tím se směruje následný provoz z uživatelské relace na stejný server.

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 je shodná s relací uživatele, protože služba Front Door v současné době podporuje pouze cookies pro relace.

Poznámka:

Vazba relace se udržuje prostřednictvím session cookie prohlížeče 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 mohou narušovat afinitu relací, protože vytvoření relace vyžaduje, aby Front Door přidal do odpovědi cookie afinity 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 se tomu zabránilo, přidružení relace se nenaváže pokud zdroj odešle odpověď ke cachování. Pokud je relace již navázána, na cache odpovědi nezáleží.

Afinitu relací se vytvoří za následujících okolností mimo standardní scénáře, které nelze uložit 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.