Trafikroutningsmetoder till ursprung

Viktigt!

Azure Front Door (klassisk) dras tillbaka den 31 mars 2027. För att undvika avbrott i tjänsten är det viktigt att du migrerar dina Azure Front Door-profiler (klassiska) till Azure Front Door Standard- eller Premium-nivån senast i mars 2027. Mer information finns i Azure Front Door (klassisk) tillbakadragning.

Azure Front Door stöder fyra olika trafikroutningsmetoder för att avgöra hur HTTP/HTTPS-trafiken fördelas mellan olika ursprung. När användarbegäranden når Front Door Edge-platserna tillämpas den konfigurerade routningsmetoden för att säkerställa att begäranden vidarebefordras till den bästa serverdelsresursen.

Kommentar

En ursprungsgrupp och en ursprungsgrupp i den här artikeln refererar till serverdels- och serverdelspoolen i Azure Front Door-konfigurationen (klassisk).

De fyra trafikroutningsmetoderna är:

• Svarstid: Den svarstidsbaserade routningen säkerställer att begäranden skickas till det lägsta svarstids ursprunget som är acceptabelt inom ett känslighetsintervall. Med andra ord skickas begäranden till närmaste ursprungsuppsättning när det gäller nätverksfördröjning.

• Prioritet: En prioritet kan anges till ditt ursprung när du vill konfigurera ett primärt ursprung för att betjäna all trafik. Det sekundära ursprunget kan vara en säkerhetskopia om det primära ursprunget blir otillgängligt.

• Viktad: Ett viktat värde kan tilldelas till ditt ursprung när du vill distribuera trafik över en uppsättning ursprung jämnt eller enligt viktkoefficienterna. Trafiken distribueras med viktvärdet om svarstiderna för ursprungen ligger inom det acceptabla svarstidskänslighetsintervallet i ursprungsgruppen.

• Sessionstillhörighet: Du kan konfigurera sessionstillhörighet för dina klientdelsvärdar eller domäner för att säkerställa att begäranden från samma slutanvändare skickas till samma ursprung.

Kommentar

Slutpunktsnamn i Azure Front Door Standard- och Premium-nivån kallas Klientdelsvärd i Azure Front Door (klassisk).

Alla Front Door-konfigurationer har övervakning av serverdelens hälsotillstånd och automatisk omedelbar global redundans. Mer information finns i Front Door-serverdelsövervakning. Azure Front Door kan användas med en enda routningsmetod. Beroende på programmets behov kan du kombinera flera routningsmetoder för att skapa en optimal routningstopologi.

Kommentar

När du använder Front Door-regelmotorn kan du konfigurera en regel för att åsidosätta routningskonfigurationer på Azure Front Door Standard- och Premium-nivån eller åsidosätta serverdelspoolen i Azure Front Door (klassisk) för en begäran. Ursprungsgruppen eller serverdelspoolen som angetts av regelmotorn åsidosätter routningsprocessen som beskrivs i den här artikeln.

Övergripande beslutsflöde

Följande diagram visar det övergripande beslutsflödet:

Beslutsstegen är:

1. Tillgängligt ursprung: Välj alla ursprung som är aktiverade och returnerade felfria (200 OK) för hälsoavsökningen.
   • Exempel: Anta att det finns sex ursprung A, B, C, D, E och F, och bland dem är C inte felfri och E är inaktiverat. Listan över tillgängliga ursprung är A, B, D och F.
2. Prioritet: Ursprung med högsta prioritet bland de tillgängliga är markerade.
   • Exempel: Anta att ursprung A, B och D har prioritet 1 och ursprung F har prioriteten 2. Sedan är de valda ursprungen A, B och D.
3. Svarstidssignal (baserat på hälsoavsökning): Välj ursprung inom det tillåtna svarstidsintervallet från Front Door-miljön där begäran kom. Den här signalen baseras på känslighetsinställningen för svarstid på ursprungsgruppen och svarstiden för de närmare ursprungen.
   • Exempel: Anta att Front Door har mätt svarstiden från miljön där begäran kom till ursprung A på 15 ms, medan svarstiden för B är 30 ms och D är 60 ms bort. Om ursprungsgruppens svarstidskänslighet är inställd på 30 ms består den lägsta svarstidspoolen av ursprung A och B, eftersom D är längre än 30 ms från närmaste ursprung som är A.
4. Vikter: Slutligen resursallokerar Azure Front Door trafiken bland den slutliga valda ursprungsgruppen i förhållandet mellan angivna vikter.
   • Exempel: Om ursprung A har en vikt på 3 och ursprung B har en vikt på 7, distribueras trafiken 3/10 till ursprung A och 7/10 till ursprung B.

Om sessionstillhörighet är aktiverat följer den första begäran i en session det flöde som angavs tidigare. Efterföljande begäranden skickas till det ursprung som valdes i den första begäran.

Lägsta svarstidsbaserad trafikroutning

Att distribuera ursprung på två eller flera platser över hela världen kan förbättra svarstiden för dina program genom att dirigera trafik till målet som är "närmast" dina slutanvändare. Svarstid är standardmetoden för trafikdirigering för din Front Door-konfiguration. Med den här routningsmetoden vidarebefordras begäranden från slutanvändarna till närmaste ursprung bakom Azure Front Door. Den här routningsmekanismen i kombination med anycast-arkitekturen i Azure Front Door säkerställer att var och en av dina slutanvändare får bästa möjliga prestanda baserat på deras plats.

Det "närmaste" ursprunget är inte nödvändigtvis närmast mätt med geografiskt avstånd. I stället avgör Azure Front Door det närmaste ursprunget genom att mäta nätverksfördröjningen. Läs mer om Azure Front Door-routningsarkitektur.

Varje Front Door-miljö mäter ursprungets svarstid separat. Det innebär att olika användare på olika platser dirigeras till ursprunget med bästa prestanda för den miljön.

Kommentar

Som standard är känslighetsegenskapen för svarstid inställd på 0 ms. Med den här inställningen vidarebefordras begäran alltid till det snabbaste tillgängliga ursprunget och vikterna för ursprunget börjar inte gälla om inte två ursprung har samma nätverksfördröjning.

Prioritetsbaserad trafikroutning

Ofta vill en organisation tillhandahålla hög tillgänglighet för sina tjänster genom att distribuera mer än en säkerhetskopieringstjänst om den primära slutar fungera. I hela branschen kallas den här typen av topologi även för aktiv/vänteläge eller aktiv/passiv distribution. Med trafikroutningsmetoden Prioritet kan du enkelt implementera det här redundansmönstret.

Standardvärdet för Azure Front Door innehåller en lista över ursprung med samma prioritet. Som standard skickar Azure Front Door endast trafik till ursprung med högsta prioritet (lägst värde i prioritet) som primär uppsättning ursprung. Om det primära ursprunget inte är tillgängligt dirigerar Azure Front Door trafiken till den sekundära ursprungsuppsättningen (det näst lägsta värdet för prioritet). Om både det primära och sekundära ursprunget inte är tillgängliga går trafiken till den tredje och så vidare. Ursprungets tillgänglighet baseras på den konfigurerade statusen och den pågående hälsostatusen för ursprunget som bestäms av hälsoavsökningarna.

Konfigurera prioritet för ursprung

Varje ursprung i ursprungsgruppen för Azure Front Door-konfigurationen har en egenskap som kallas Prioritet, som kan vara ett tal mellan 1 och 5. Med Azure Front Door kan du konfigurera ursprungsprioriteten explicit med hjälp av den här egenskapen för varje ursprung. Den här egenskapen är ett värde mellan 1 och 5. Desto lägre värde desto högre prioritet. Ursprung kan dela samma prioritetsvärden.

Vägd trafikroutningsmetod

Med metoden Viktad trafikroutning kan du distribuera trafik jämnt eller använda en fördefinierad viktning.

I den viktade trafikroutningsmetoden tilldelar du en vikt till varje ursprung i Azure Front Door-konfigurationen för din ursprungsgrupp. Vikten är ett heltal mellan 1 och 1 000. Den här parametern använder en standardvikt på 50.

Med listan över tillgängliga ursprung som har en acceptabel svarstidskänslighet distribueras trafiken med en resursallokeringsmekanism med hjälp av förhållandet mellan angivna vikter. Om svarstidskänsligheten anges till 0 millisekunder börjar den här egenskapen inte gälla om det inte finns två ursprung med samma nätverksfördröjning.

Den viktade metoden möjliggör några användbara scenarier:

• Gradvis programuppgradering: Ger en procentandel trafik för att dirigera till ett nytt ursprung och ökar gradvis trafiken över tid för att få den i nivå med andra ursprung.
• Programmigrering till Azure: Skapa en ursprungsgrupp med både Azure och externt ursprung. Justera ursprungets vikt så att de föredrar det nya ursprunget. Du kan gradvis konfigurera det här från och med att de nya ursprungen är inaktiverade och sedan tilldela dem de lägsta vikterna, vilket långsamt ökar det till nivåer där de tar mest trafik. Inaktivera sedan de mindre önskade ursprungen och ta bort dem från gruppen.
• Molnsprängning för ytterligare kapacitet: Expandera snabbt en lokal distribution till molnet genom att placera den bakom Front Door. När du behöver extra kapacitet i molnet kan du lägga till eller aktivera fler ursprung och ange vilken del av trafiken som går till varje ursprung.

Sessionstillhörighet

Utan sessionstillhörighet vidarebefordrar Azure Front Door som standard begäranden från samma klient till olika ursprung. Vissa tillståndskänsliga program eller i vissa scenarier när efterföljande begäranden från samma användare föredrar samma ursprung för att bearbeta den första begäran. Funktionen cookiebaserad sessionstillhörighet är användbar när du vill behålla en användarsession med samma ursprung. När du använder hanterade cookies med SHA256 av ursprungs-URL:en som identifierare i cookien kan Azure Front Door dirigera efterföljande trafik från en användarsession till samma ursprung för bearbetning.

Sessionstillhörighet kan aktiveras på ursprungsgruppsnivån i Azure Front Door Standard- och Premium-nivå och klientdelsvärdnivå i Azure Front Door (klassisk) för var och en av dina konfigurerade domäner (eller underdomäner). När det är aktiverat lägger Azure Front Door till en cookie i användarens session. Cookies kallas ASLBSA och ASLBSACORS. Med cookiebaserad sessionstillhörighet kan Front Door identifiera olika användare även om de finns bakom samma IP-adress, vilket i sin tur möjliggör en jämnare distribution av trafik mellan dina olika ursprung.

Livslängden för cookien är samma som användarens session eftersom Front Door för närvarande endast stöder sessions-cookies.

Kommentar

Oavsett var den har konfigurerats kommer sessionstillhörigheten att sparas via webbläsarsessionscookien på domännivå. Underdomäner under samma jokerteckendomän kan dela sessionstillhörigheten så länge samma webbläsare skickar begäranden för samma ursprungsresurs.

Offentliga proxyservrar kan störa sessionstillhörigheten. Detta beror på att upprättandet av en session kräver att Front Door lägger till en cookie för sessionstillhörighet i svaret, vilket inte kan göras om svaret kan cachelagras eftersom det skulle störa cookies från andra klienter som begär samma resurs. För att skydda mot detta upprättas inte sessionstillhörighet om ursprunget skickar ett cacheminnesbart svar när detta görs. Om sessionen redan har upprättats spelar det ingen roll om svaret från ursprunget kan cachelagrats.

Sessionstillhörighet upprättas under följande omständigheter utöver standardscenarier som inte går att cachelagrar:

• Svaret måste innehålla huvudet för Cache-Control no-store.
• Om svaret innehåller en Authorization rubrik får det inte ha upphört att gälla.
• Svaret är en HTTP 302-statuskod.

Nästa steg

• Lär dig hur du skapar en Azure Front Door.
• Lär dig hur Azure Front Door fungerar.