Routeringsmethoden voor verkeer naar oorsprong

Belangrijk

Azure Front Door (klassiek) wordt op 31 maart 2027 buiten gebruik gesteld. Om serviceonderbrekingen te voorkomen, is het belangrijk dat u uw Azure Front Door-profielen (klassiek) tegen maart 2027 migreert naar de Azure Front Door Standard- of Premium-laag. Zie De buitengebruikstelling van Azure Front Door (klassiek) voor meer informatie.

Azure Front Door ondersteunt vier methoden voor verkeersroutering om te beheren hoe uw HTTP/HTTPS-verkeer wordt verdeeld over verschillende oorsprongen. Wanneer gebruikersaanvragen de Edge-locaties van Front Door bereiken, zorgt de geconfigureerde routeringsmethode ervoor dat aanvragen worden doorgestuurd naar de beste back-endresource.

Notitie

In dit artikel verwijst een Origin naar de back-end en een oorspronkelijke groep verwijst naar de back-endpool in de configuratie van Azure Front Door (klassiek).

De vier verkeersrouteringsmethoden zijn:

• Latentie: stuurt aanvragen naar de oorsprongen met de laagste latentie binnen een acceptabel gevoeligheidsbereik, zodat aanvragen worden verzonden naar de dichtstbijzijnde oorsprong in termen van netwerklatentie.

• Prioriteit: Hiermee kunt u een prioriteit instellen voor uw oorsprongen, waarbij u een primaire oorsprong aangeeft om al het verkeer en een secundaire oorsprong als back-up te verwerken als de primaire bron niet beschikbaar is.

• Gewogen: Wijst een gewicht toe aan elke oorsprong om verkeer gelijkmatig te verdelen of volgens de opgegeven gewichtscoëfficiënten. Verkeer wordt gedistribueerd op basis van gewichtswaarden als de latenties van de oorsprong binnen het acceptabele gevoeligheidsbereik vallen.

• Sessieaffiniteit: zorgt ervoor dat aanvragen van dezelfde eindgebruiker naar dezelfde oorsprong worden verzonden door sessieaffiniteit te configureren voor uw front-endhosts of -domeinen.

Notitie

In Azure Front Door Standard- en Premium-lagen wordt de naam van het eindpunt aangeduid als Front-endhost in Azure Front Door (klassiek).

Alle Front Door-configuraties omvatten back-endstatusbewaking en geautomatiseerde globale failover. Zie Front Door-back-endbewaking voor meer informatie. Azure Front Door kan één routeringsmethode gebruiken of meerdere methoden combineren om een optimale routeringstopologie te maken op basis van uw toepassingsbehoeften.

Notitie

Met behulp van de Front Door-regelengine kunt u regels configureren om routeconfiguraties in Azure Front Door Standard- en Premium-lagen te overschrijven of de back-endpool in Azure Front Door (klassiek) te overschrijven voor een aanvraag. De oorspronkelijke groep of back-endpool die door de regelengine is ingesteld, overschrijft het routeringsproces dat in dit artikel wordt beschreven.

Algemene beslissingsstroom

In het volgende diagram ziet u de algemene beslissingsstroom:

De beslissingsstappen zijn:

1. Beschikbare origins: Selecteer alle oorsprongen die zijn ingeschakeld en in orde zijn (200 OK) op basis van de statustest.
   • Voorbeeld: Als er zes origins A, B, C, D, E en F zijn en C is beschadigd en E is uitgeschakeld, zijn de beschikbare origins A, B, D en F.
2. Prioriteit: Selecteer de oorsprongen met de hoogste prioriteit uit de beschikbare.
   • Voorbeeld: Als oorsprong A, B en D prioriteit 1 en oorsprong F prioriteit 2 heeft, zijn de geselecteerde oorsprongen A, B en D.
3. Latentiesignaal (op basis van statustest): Selecteer oorsprongen binnen het toegestane latentiebereik van de Front Door-omgeving waar de aanvraag is aangekomen. Dit is gebaseerd op de instelling voor latentiegevoeligheid van de oorspronkelijke groep en de latentie van de dichtstbijzijnde oorsprongen.
   • Voorbeeld: Als de latentie voor oorsprong A 15 ms is, is B 30 ms en D 60 ms, en de latentiegevoeligheid is ingesteld op 30 ms, zijn de geselecteerde oorsprongen A en B, omdat D het bereik van 30 ms overschrijdt.
4. Gewichten: Verkeer verdelen over de uiteindelijke geselecteerde oorsprongen op basis van de opgegeven gewichtsverhoudingen.
   • Voorbeeld: Als oorsprong A een gewicht van 3 heeft en B een gewicht van 7 heeft, wordt verkeer 3/10 gedistribueerd naar A en 7/10 naar B.

Als sessieaffiniteit is ingeschakeld, volgt de eerste aanvraag in een sessie de eerder uitgelegde stroom. Volgende aanvragen worden verzonden naar de oorsprong die in de eerste aanvraag is geselecteerd.

Laagste latentie op basis van verkeersroutering

Door origins op meerdere globale locaties te implementeren, kan de reactiesnelheid van uw toepassing worden verbeterd door verkeer naar de oorsprong te routeren die zich 'het dichtst bij uw eindgebruikers' bevindt. De routeringsmethode Latentie is de standaardmethode voor Azure Front Door-configuraties. Deze methode stuurt gebruikersaanvragen naar de oorsprong met de laagste netwerklatentie, in plaats van de dichtstbijzijnde geografische locatie, waardoor optimale prestaties worden gegarandeerd.

De anycast-architectuur van Azure Front Door, gecombineerd met de routeringsmethode Latentie, zorgt ervoor dat elke gebruiker de beste prestaties ervaart op basis van hun locatie. Elke Front Door-omgeving meet onafhankelijk de latentie van oorsprongen, wat betekent dat gebruikers op verschillende locaties worden doorgestuurd naar de oorsprong die de beste prestaties biedt voor hun specifieke omgeving.

Notitie

De eigenschap latentiegevoeligheid is standaard ingesteld op 0 ms. Met deze instelling worden aanvragen altijd doorgestuurd naar de snelste beschikbare origins. Gewichten op de oorsprong worden alleen van kracht als twee oorsprongen dezelfde netwerklatentie hebben.

Zie de Routeringsarchitectuur van Azure Front Door voor meer informatie.

Verkeersroutering op basis van prioriteit

Om hoge beschikbaarheid te garanderen, implementeren organisaties vaak back-upservices om over te nemen als de primaire service uitvalt. Deze installatie wordt active/stand-by- of actief/passieve implementatie genoemd. Met de methode Prioriteit voor verkeersroutering in Azure Front Door kunt u dit failoverpatroon effectief implementeren.

Standaard routeert Azure Front Door verkeer naar de oorsprongen met de hoogste prioriteit (laagste prioriteitswaarde). Als deze primaire oorsprongen niet beschikbaar zijn, wordt verkeer gerouteerd naar de secundaire oorsprongen (de eerstvolgende laagste prioriteitswaarde). Dit proces gaat verder met tertiaire oorsprongen als zowel primaire als secundaire oorsprongen niet beschikbaar zijn. Statustests controleren de beschikbaarheid van oorsprongen op basis van hun geconfigureerde status en status.

Prioriteit voor oorsprong configureren

Elke oorsprong in uw Azure Front Door-oorsprongsgroep heeft een eigenschap Prioriteit , die kan worden ingesteld op een waarde tussen 1 en 5. Lagere waarden geven een hogere prioriteit aan. Meerdere origins kunnen dezelfde prioriteitswaarde delen.

Gewogen verkeersrouteringsmethode

Met de gewogen verkeersrouteringsmethode kunt u verkeer distribueren op basis van vooraf gedefinieerde gewichten.

In deze methode wijst u een gewicht toe aan elke oorsprong in uw Azure Front Door-oorsprongsgroep. Het gewicht is een geheel getal tussen 1 en 1000, met een standaardwaarde van 50.

Verkeer wordt verdeeld over beschikbare origins met behulp van een round robin-mechanisme op basis van de opgegeven gewichtsverhoudingen, mits de oorsprongen voldoen aan de acceptabele latentiegevoeligheid. Als de latentiegevoeligheid is ingesteld op 0 milliseconden, worden gewichten alleen van kracht als twee oorsprongen dezelfde netwerklatentie hebben.

De gewogen methode ondersteunt verschillende scenario's:

• Geleidelijke toepassingsupgrade: routeer een percentage verkeer naar een nieuwe oorsprong en verhoog deze geleidelijk in de loop van de tijd.
• Toepassingsmigratie naar Azure: maak een origin-groep met zowel Azure als externe origins. Pas gewichten aan om de voorkeur te geven aan nieuwe origins, waardoor de verkeersshare geleidelijk wordt verhoogd totdat het meeste verkeer wordt verwerkt, en vervolgens minder voorkeursoorsprongen worden uitgeschakeld en verwijderd.
• Cloud-bursting voor extra capaciteit: breid on-premises implementaties uit in de cloud door meer origins toe te voegen of in te schakelen en verkeersdistributie op te geven.

Sessieaffiniteit

Standaard stuurt Azure Front Door aanvragen van dezelfde client door naar verschillende origins. Sessieaffiniteit is echter handig voor stateful toepassingen of scenario's waarbij volgende aanvragen van dezelfde gebruiker door dezelfde oorsprong moeten worden verwerkt. Deze functie zorgt ervoor dat dezelfde oorsprong de sessie van een gebruiker afhandelt, wat nuttig is voor scenario's zoals clientverificatie.

Azure Front Door maakt gebruik van sessieaffiniteit op basis van cookies, waarbij beheerde cookies met SHA256 van de oorspronkelijke URL worden gebruikt als de id wordt gebruikt. Hiermee wordt volgend verkeer van een gebruikerssessie naar dezelfde oorsprong doorgestuurd.

Sessieaffiniteit kan worden ingeschakeld op het niveau van de oorspronkelijke groep in Azure Front Door Standard- en Premium-lagen en op het front-endhostniveau in Azure Front Door (klassiek) voor elk geconfigureerd domein of subdomein. Zodra deze functie is ingeschakeld, voegt Azure Front Door cookies met de naam ASLBSA en ASLBSACORS de sessie van de gebruiker toe. Deze cookies helpen bij het identificeren van verschillende gebruikers, zelfs als ze hetzelfde IP-adres delen, waardoor een meer gelijkmatige distributie van verkeer tussen oorsprongen mogelijk is.

De levensduur van de cookie komt overeen met de sessie van de gebruiker, omdat Front Door momenteel alleen sessiecookies ondersteunt.

Notitie

Sessieaffiniteit wordt onderhouden via de browsersessiecookie op domeinniveau. Subdomeinen onder hetzelfde domein met jokertekens kunnen sessieaffiniteit delen zolang de browser van de gebruiker aanvragen verzendt voor dezelfde bron van oorsprong.

Openbare proxy's kunnen de sessieaffiniteit verstoren omdat voor het tot stand brengen van een sessie Front Door een sessieaffiniteitscookie aan het antwoord moet worden toegevoegd. Dit kan niet worden gedaan als het antwoord in de cache kan worden opgeslagen, omdat cookies worden onderbroken voor andere clients die dezelfde resource aanvragen. Om dit te voorkomen, wordt sessieaffiniteit niet tot stand gebracht als de origin een cachebaar antwoord verzendt. Als de sessie al tot stand is gebracht, maakt de cachebaarheid van het antwoord niet uit.

Sessieaffiniteit wordt in de volgende omstandigheden tot stand gebracht buiten de standaardscenario's die niet in de cache kunnen worden opgeslagen:

• Het antwoord bevat de Cache-Control header zonder store.
• Het antwoord bevat een geldige Authorization header.
• Het antwoord is een HTTP 302-statuscode.

Volgende stappen

• Meer informatie over het maken van een Azure Front Door.
• Meer informatie over hoe Azure Front Door werkt.