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 různé metody směrování provozu, které určují, jak se provoz HTTP/HTTPS distribuuje mezi různé zdroje. Když se požadavky uživatelů dostanou do hraničních umístění služby Front Door, použije se nakonfigurovaná metoda směrování, aby se zajistilo, že se požadavky přesměrují na nejlepší back-endový prostředek.

Poznámka:

Zdroj a skupina původu v tomto článku odkazují na back-endový a back-endový fond konfigurace služby Azure Front Door (Classic).

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

• Latence: Směrování založené na latenci zajišťuje, že se požadavky odesílají do nejnižšího původu latence přijatelné v rozsahu citlivosti. Jinými slovy, požadavky se odesílají do nejbližší sady původů, pokud jde o latenci sítě.

• Priorita: Prioritu můžete nastavit na zdroj, když chcete nakonfigurovat primární zdroj tak, aby obsluhovat veškerý provoz. Sekundárním původem může být záloha v případě, že primární zdroj přestane být dostupný.

• Vážené: Vážená hodnota může být přiřazena vašemu původu, pokud chcete distribuovat provoz mezi sadu původů rovnoměrně nebo podle koeficientů hmotnosti. Provoz se distribuuje podle hodnoty váhy, pokud jsou latence původu v přijatelném rozsahu citlivosti latence ve skupině původu.

• Spřažení relací: Můžete nakonfigurovat spřažení relací pro hostitele nebo domény front-endu, aby se zajistilo, že se požadavky od stejného koncového uživatele odešlou do stejného zdroje.

Poznámka:

Název koncového bodu ve službě Azure Front Door Standard a na úrovni Premium se nazývá hostitel front-endu ve službě Azure Front Door (Classic).

Všechny konfigurace služby Front Door mají monitorování stavu back-endu a automatizované okamžité 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 je možné použít s jednou metodou směrování. V závislosti na potřebách vaší aplikace můžete zkombinovat několik metod směrování a vytvořit optimální topologii směrování.

Poznámka:

Pokud používáte modul pravidel služby Front Door, můžete nakonfigurovat pravidlo pro přepsání konfigurací tras ve službě Azure Front Door Standard a na úrovni Premium nebo přepsání back-endového fondu ve službě 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é zdroje: Vyberte pro sondu stavu všechny zdroje, které jsou povolené a vracené v pořádku (200 OK).
   • Příklad: Předpokládejme, že existuje šest původů A, B, C, D, E a F a mezi nimi C není v pořádku a E je zakázáno. Seznam dostupných zdrojů je A, B, D a F.
2. Priorita: Jsou vybrány zdroje nejvyšší priority mezi dostupnými zdroji.
   • Příklad: Předpokládejme, že původ A, B a D mají prioritu 1 a počáteční F má prioritu 2. Pak jsou vybranými zdroji 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 požadavek přišel. Tento signál vychází z nastavení citlivosti latence ve skupině původu a na latenci bližšího původu.
   • Příklad: Předpokládejme, že služba Front Door změřila latenci z prostředí, ve kterém požadavek přišel do zdroje A na 15 ms, zatímco latence pro B je 30 ms a D je vzdálená 60 ms. Pokud je citlivost na latenci skupiny původu nastavená na 30 ms, pak se fond nejnižší latence skládá z původu A a B, protože D přesahuje 30 ms od nejbližšího původu, který je A.
4. Váhy: Azure Front Door zaokrouhluje dotazování provozu mezi poslední vybranou skupinou původu v poměru zadaných hmotností.
   • Příklad: Pokud má původ A váhu 3 a původ B má 7, pak se provoz distribuuje 3/10 do původu A a 7/10 do původu B.

Pokud je povolené spřažení relace, první požadavek v relaci se řídí tokem uvedeným dříve. 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 na dvou nebo více místech 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. Směrování na základě latence je výchozí metodou směrování provozu v konfiguraci služby Front Door. Tato metoda směrování zajišťuje směrování požadavků od koncových uživatelů do nejbližšího zdroje za službou Azure Front Door. Tento mechanismus směrování v kombinaci s architekturou libovolného vysílání služby Azure Front Door zajišťuje, aby každý koncový uživatel získal nejlepší výkon na základě jejich umístění.

Nejbližší původ nemusí být nutně nejblíže podle zeměpisné vzdálenosti. Místo toho Azure Front Door určuje nejbližší zdroj měřením latence sítě. Přečtěte si další informace o architektuře směrování služby Azure Front Door.

Každé prostředí Služby Front Door měří latenci původu zvlášť. To znamená, že různí uživatelé v různých umístěních se směrují do původu s nejlepším výkonem pro dané prostředí.

Poznámka:

Ve výchozím nastavení je vlastnost citlivosti latence nastavená na 0 ms. Při tomto nastavení se požadavek vždy předává nejrychlejším dostupným zdrojům a váham původu se neprojeví, pokud dva zdroje nemají stejnou latenci sítě.

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

Organizace často chce zajistit vysokou dostupnost svých služeb nasazením více než jedné zálohovací služby v případě výpadku primární služby. V celém odvětví se tento typ topologie označuje také jako aktivní/pohotovostní nebo aktivní/pasivní nasazení. Metoda prioritního směrování provozu umožňuje snadno implementovat tento model převzetí služeb při selhání.

Výchozí služba Azure Front Door obsahuje seznam stejných priorit původu. Služba Azure Front Door ve výchozím nastavení odesílá provoz pouze do zdroje s nejvyšší prioritou (nejnižší hodnota v prioritě) jako primární sada zdrojů. Pokud primární zdroje nejsou dostupné, Azure Front Door směruje provoz do sekundární sady původů (druhá nejnižší hodnota priority). Pokud primární i sekundární původ nejsou dostupné, provoz přejde na třetí a tak dále. Dostupnost původu vychází z nakonfigurovaného stavu a stavu probíhajícího původu určeného sondami stavu.

Konfigurace priority pro zdroje

Každý původ ve vaší skupině původu konfigurace služby Azure Front Door má vlastnost s názvem Priorita, což může být číslo v rozsahu 1 až 5. Pomocí služby Azure Front Door můžete prioritu zdroje nakonfigurovat explicitně pomocí této vlastnosti pro každý zdroj. Tato vlastnost je hodnota mezi 1 a 5. Čím nižší je hodnota, tím vyšší je priorita. Zdroje můžou sdílet stejné hodnoty priority.

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

Metoda váženého směrování provozu umožňuje rovnoměrně distribuovat provoz nebo použít předdefinované váhy.

V vážené metodě směrování provozu přiřadíte váhu každému zdroji v konfiguraci služby Azure Front Door vaší původní skupiny. Hmotnost je celé číslo od 1 do 1 000. Tento parametr používá výchozí váhu 50.

Se seznamem dostupných zdrojů, které mají přijatelnou citlivost latence, se provoz distribuuje pomocí mechanismu kruhového dotazování s použitím zadaného poměru hmotností. Pokud se citlivost latence nastaví na 0 milisekund, tato vlastnost se neprojeví, pokud nejsou dva zdroje se stejnou latencí sítě.

Vážená metoda umožňuje některé užitečné scénáře:

• Postupný upgrade aplikace: Poskytuje procento provozu pro směrování do nového původu a postupně zvyšuje provoz tak, aby byl v souladu s jinými zdroji.
• Migrace aplikací do Azure: Vytvořte skupinu původu s Azure i externími zdroji. Upravte váhu původu tak, aby upřednostňovala nové původy. Můžete ho postupně nastavit tak, že budou nové původy zakázané a pak je přiřadíte nejnižší hmotnosti, pomalu se zvýší na úrovně, ve kterých přebírají většinu provozu. Nakonec zakažte méně upřednostňované zdroje a odeberte je ze skupiny.
• Rozšíření cloudu pro další kapacitu: Rychlé rozšíření místního nasazení do cloudu tím, že ho umístíte za Front Door. Pokud potřebujete další kapacitu v cloudu, můžete přidat nebo povolit další zdroje a určit, jaká část provozu směřuje do jednotlivých zdrojů.

Spřažení relací

Ve výchozím nastavení Azure Front Door bez spřažení relací předává požadavky pocházející ze stejného klienta do různých zdrojů. Některé stavové aplikace nebo v určitých scénářích při vytváření požadavků od stejného uživatele preferuje stejný původ ke zpracování počátečního požadavku. Funkce spřažení relací založená na souborech cookie je užitečná, pokud chcete zachovat uživatelskou relaci ve stejném zdroji, například scénáře, kdy se klienti ověřují v původu. Když jako identifikátor v souboru cookie použijete spravované soubory cookie s adresou URL původu SHA256, azure Front Door může směrovat provoz z uživatelské relace do stejného původu ke zpracování.

Spřažení relací se dá povolit na úrovni skupiny původu ve službě Azure Front Door Standard a na úrovni premium a na úrovni hostitele front-endu ve službě Azure Front Door (classic) pro každou z nakonfigurovaných domén (nebo subdomén). Jakmile je služba Azure Front Door povolená, přidá do relace uživatele soubor cookie. Soubory cookie se nazývají ASLBSA a ASLBSACORS. Spřažení relací založené na souborech cookie umožňuje službě Front Door identifikovat různé uživatele, i když se za stejnou IP adresou, což zase umožňuje rovnoměrnější distribuci provozu mezi různými zdroji.

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:

Bez ohledu na to, kde je nakonfigurovaná, se spřažení relace zapamatuje prostřednictvím souboru cookie relace prohlížeče na úrovni domény. Subdomény ve stejné zástupné doméně můžou spřažení relace sdílet tak dlouho, dokud stejný prohlížeč uživatelů odesílá požadavky na stejný zdroj prostředku původu.

Veřejné proxy servery můžou kolidovat se spřažením relací. Důvodem je to, že vytvoření relace vyžaduje, aby služba Front Door přidala do odpovědi soubor cookie spřažení relace, který nelze provést, pokud je odpověď uložená v mezipaměti, protože by narušila soubory cookie jiných klientů, kteří požadují stejný prostředek. Pro ochranu před tímto vztahem nebude vytvořeno spřažení relace, pokud zdroj odešle odpověď, která je možné uložit do mezipaměti při pokusu. Pokud už relace byla vytvořena, nezáleží na tom, jestli je odpověď z původu uložená v mezipaměti.

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ěď musí obsahovat hlavičku Cache-Control bez úložiště.
• Pokud odpověď obsahuje hlavičku Authorization , nesmí vypršena.
• Odpověď je stavový kód HTTP 302.

Další kroky

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