Front Door směrování

  • Článek
  • 6 min ke čtení

Azure Front Door podporuje různé druhy metod směrování provozu a určuje, jak směrovat provoz HTTP/HTTPS do různých koncových bodů služby. Když požadavky klientů dosáhne Front Door, použije se nakonfigurovaná metoda směrování, aby se zajistilo, že se požadavky předá do nejlepší back-endové instance.

V systému jsou k dispozici čtyři metody směrování Front Door:

  • Latence: Směrování na základě latence zajišťuje, aby se požadavky odesílaly do back-endů s nejnižší latencí, která je přijatelná v rámci rozsahu citlivosti. V podstatě se požadavky uživatelů odesílaly do nejbližší sady back-endů z hlediska latence sítě.
  • Priorita: Pokud chcete nakonfigurovat primární back-end pro všechny přenosy, můžete svým back-endům přiřadit priority. Sekundární back-end může být záloha v případě, že primární back-end přestane být dostupný.
  • Vážená: Pokud chcete distribuovat provoz mezi sadu back-endů rovnoměrně nebo podle koeficientů hmotnosti, můžete k back-endům přiřadit váhy. Provoz se distribuuje podle váze, pokud jsou latence back-endů v přijatelném rozsahu citlivosti latence v back-endového fondu.
  • Spřažení relací: Pro front-endové hostitele nebo domény můžete nakonfigurovat spřažení relací, abyste zajistili, že se požadavky od stejného koncového uživatele budou odesílat do stejného back-endu.

Všechny konfigurace služby Front Door zahrnují monitorování stavu back-endu a automatické okamžité globální převzetí služeb při selhání. Další informace najdete v tématu Front Door monitorování back-endu. Váš Front Door může fungovat na základě jedné metody směrování. Ale v závislosti na potřebách vaší aplikace můžete také kombinovat několik metod směrování a vytvořit optimální topologii směrování.

Směrování provozu na základě nejnižší latence

Nasazení back-endů ve dvou nebo více umístěních po celém světě může zlepšit odezvu vašich aplikací směrováním provozu do cíle, který je "nejblíže" koncovým uživatelům. Výchozí metoda směrování provozu pro vaši konfiguraci Front Door předává požadavky od koncových uživatelů do nejbližšího back-endu Front Door prostředí, které požadavek přijalo. V kombinaci s architekturou Anycast Azure Front Door tento přístup zajišťuje, aby každý z vašich koncových uživatelů byl přizpůsobený maximální výkon na základě jejich umístění.

"Nejbližší" back-end nemusí být nutně nejbližší měřený geografickou vzdáleností. Místo Front Door určí nejbližší back-endy měřením latence sítě. Přečtěte si Front Door o architektuře směrování služby .

Níže je uvedený celkový rozhodovací tok:

Dostupné back-endy Priorita Signál latence (na základě sondy stavu) Hmotnosti
Nejprve vyberte pro sondu stavu všechny back-endy, které jsou povolené a vrácené v pořádku (200 OK). Pokud existuje šest back-endů A, B, C, D, E a F a mezi nimi C není v pořádku a E je zakázané. Seznam dostupných back-endů je A, B, D a F. Dále jsou vybrány back-endy s nejvyšší prioritou z dostupných. Pokud mají back-end A, B a D prioritu 1 a back-end F má prioritu 2. Vybrané back-endy pak budou A, B a D. Vyberte back-endy s rozsahem latence (minimální latence a & latence v zadaném ms). Pokud je back-end A 15 ms, B je 30 ms a D je 60 ms od prostředí Front Door, ve kterém se požadavek překládá, a citlivost latence je 30 ms, pak se fond nejnižší latence skládá z back-endu A a B, protože D přesahuje 30 ms od nejbližšího back-endu, který je A. A konečně Front Door kruhové dotazování provozu mezi konečným vybraným fondem back-endů v zadaném poměru váze. Řekněme, že pokud má back-end A váhu 5 a back-end B má váhu 8, pak se provoz rozdělí v poměru 5:8 mezi back-endy A a B.

Poznámka

Ve výchozím nastavení je vlastnost citlivosti latence nastavená na 0 ms, to znamená, že požadavek se vždy předává do nejrychlejšího dostupného back-endu a váhy na back-endech se projeví, pokud dva back-endy nemají stejnou latenci sítě.

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

Organizace často chce poskytovat vysokou dostupnost pro své služby nasazením více než jedné služby zálohování v případě, že primární služba se zkrátí. V celém odvětví se tato topologie označuje také jako topologie nasazení Aktivní/Pohotovostní nebo Aktivní/Pasivní. Metoda prioritního směrování provozu umožňuje zákazníkům Azure snadno implementovat tento model převzetí služeb při selhání.

Výchozí Front Door obsahuje seznam back-endů se stejnou prioritou. Ve výchozím nastavení Front Door provoz pouze do back-endů s nejvyšší prioritou (nejnižší hodnota priority), to znamená primární sady back-endů. Pokud primární back-endy nejsou k dispozici, Front Door provoz směruje do sekundární sady back-endů (druhá nejnižší hodnota priority). Pokud nejsou k dispozici primární i sekundární back-endy, provoz se směruje do třetího a tak dále. Dostupnost back-endu vychází z nakonfigurovaného stavu (povoleného nebo zakázaného) a průběžného stavu back-endu podle sond stavu.

Konfigurace priority pro back-endy

Každý back-end v back-endových fondech konfigurace Front Door má vlastnost s názvem Priority, což může být číslo v rozmezí 1 až 5. V Azure Front Door nakonfigurujete prioritu back-endu explicitně pomocí této vlastnosti pro každý back-end. Tato vlastnost je hodnota mezi 1 a 5. Nižší hodnoty představují vyšší prioritu. Back-endy mohou sdílet hodnoty priority.

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

"Vážená" metoda směrování provozu umožňuje rovnoměrně distribuovat provoz nebo používat předdefinované váhy.

V metodě vážené směrování provozu přiřadíte každému back-endu váhu v konfiguraci Front Door back-endového fondu. Váha je celé číslo od 1 do 1000. Tento parametr používá výchozí váhu 50.

Se seznamem dostupných back-endů, které mají přijatelnou latenci, se provoz distribuuje s mechanismem kruhového dotazování s využitím zadaného poměru váze. Pokud se citlivost latence nastaví na 0 milisekund, pak se tato vlastnost nebude projeví, pokud neexistují dva back-endy se stejnou latencí sítě.

Vážená metoda umožňuje několik užitečných scénářů:

  • Postupný upgrade aplikace: Poskytuje procento provozu pro směrování do nového back-endu a postupně zvyšuje provoz v průběhu času, aby byl v souladu s jinými back-endy.
  • Migrace aplikací do Azure: Vytvořte back-endový fond s Azure i externími back-endy. Upravte váhu back-endů tak, aby upřednostňoval nové back-endy. Můžete to postupně nastavit tak, že nové back-endy budete mít zakázané, přiřadíte jim nejnižší váhy a pomalu ji zvýšíte na úrovně, kde přecházejí většinu provozu. Nakonec zakážete méně upřednostňované back-endy a odeberete je z fondu.
  • Cloudové rozšíření pro další kapacitu: Rychle rozšiřte místní nasazení do cloudu jeho umístěním za Front Door. Pokud potřebujete v cloudu další kapacitu, můžete přidat nebo povolit více back-endů a určit, jaká část provozu se bude do jednotlivých back-endů vracet.

Spřažení relací

Ve výchozím nastavení nástroj bez spřažení relací Front Door požadavky pocházející ze stejného klienta do různých back-endů. Některé stavové aplikace nebo v určitých scénářích vyústující požadavky od stejného uživatele dávají přednost stejnému back-endu, který zpracuje počáteční požadavek. Funkce spřažení relací na základě souborů cookie je užitečná v případě, že chcete zachovat uživatelskou relaci na stejném back-endu. Pomocí spravovaných souborů cookie Azure Front Door směrovat provoz z uživatelské relace do stejného back-endu pro zpracování.

Spřažení relací je možné povolit na úrovni hostitele front-endu, to znamená pro všechny nakonfigurované domény (nebo subdomény). Po povolení přidá služba Front Door k relaci uživatele soubor cookie. Spřažení relací na základě souborů cookie umožňuje službě Front Door identifikovat různé uživatele i v případě, že jsou skryti za stejnou IP adresou. Díky tomu je možné rovnoměrněji distribuovat provoz mezi různé back-endy.

Doba života souboru cookie je stejná jako doba života relace uživatele, protože služba Front Door v současné době podporuje pouze soubor cookie relace.

Poznámka

Veřejné afinity relace mohou narušovat. Je to proto, že vytvoření relace vyžaduje Front Door k přidání souboru cookie spřažení relace do odpovědi. To se ne dělat, pokud je odpověď možné ukládat do mezipaměti, protože by to narušilo soubory cookie jiných klientů požadujících stejný prostředek. Pokud back-end při tomto pokusu odešle odpověď, která je možné ukládat do mezipaměti, spřažení relace se nenastane. Pokud už je relace vytvořená, nezáleží na tom, jestli je odpověď z back-endu možné ukládat do mezipaměti. Spřažení relace bude vytvořeno za následujících okolností, pokud odpověď nemá stavový kód HTTP 304:

  • Odpověď má pro hlavičku nastavené konkrétní hodnoty, které brání ukládání do mezipaměti, například Cache-Control "privátní" nebo no-store.
  • Odpověď obsahuje Authorization hlavičku, která nevyšle její platnost.
  • Odpověď má stavový kód HTTP 302.

Další kroky