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 verschillende verkeersrouteringsmethoden om te bepalen hoe uw HTTP/HTTPS-verkeer wordt verdeeld tussen verschillende oorsprongen. Wanneer gebruikersaanvragen de Edge-locaties van Front Door bereiken, wordt de geconfigureerde routeringsmethode toegepast om ervoor te zorgen dat aanvragen worden doorgestuurd naar de beste back-endresource.

Notitie

Een Origin- en origin-groep in dit artikel verwijst naar de back-end- en back-endpool van de Configuratie van Azure Front Door (klassiek).

De vier verkeersrouteringsmethoden zijn:

• Latentie: De routering op basis van latentie zorgt ervoor dat aanvragen worden verzonden naar de laagste latentieoorsprongen die acceptabel zijn binnen een gevoeligheidsbereik. Met andere woorden, aanvragen worden verzonden naar de dichtstbijzijnde set origins met betrekking tot netwerklatentie.

• Prioriteit: Een prioriteit kan worden ingesteld op uw origins wanneer u een primaire origin wilt configureren om al het verkeer te verwerken. De secundaire oorsprong kan een back-up zijn als de primaire oorsprong niet meer beschikbaar is.

• Gewogen: Een gewogen waarde kan worden toegewezen aan uw oorsprongen wanneer u verkeer gelijkmatig over een reeks oorsprongen of volgens de gewichtscoëfficiënten wilt verdelen. Verkeer wordt gedistribueerd door de gewichtswaarde als de latenties van de oorsprongen binnen het acceptabele gevoeligheidsbereik voor latentie in de oorsprongsgroep vallen.

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

Notitie

De eindpuntnaam in de Azure Front Door Standard- en Premium-laag wordt front-endhost genoemd in Azure Front Door (klassiek).

Alle Front Door-configuraties hebben back-endstatusbewaking en automatische automatische globale failover. Zie Front Door-back-endbewaking voor meer informatie. Azure Front Door kan worden gebruikt met één routeringsmethode. Afhankelijk van uw toepassingsbehoeften kunt u meerdere routeringsmethoden combineren om een optimale routeringstopologie te bouwen.

Notitie

Wanneer u de Front Door-regelengine gebruikt, kunt u een regel configureren voor het overschrijven van routeconfiguraties in de Azure Front Door Standard- en Premium-laag of de back-endpool in Azure Front Door (klassiek) 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 die in orde zijn geretourneerd (200 OK) voor de statustest.
   • Voorbeeld: Stel dat er zes oorsprongen A, B, C, D, E en F zijn, en dat onder hen C niet in orde is en E is uitgeschakeld. De lijst met beschikbare origins is A, B, D en F.
2. Prioriteit: De oorsprongen met de hoogste prioriteit onder de beschikbare oorsprongen zijn geselecteerd.
   • Voorbeeld: Stel dat oorsprong A, B en D prioriteit 1 en oorsprong F heeft een prioriteit van 2. Vervolgens zijn de geselecteerde oorsprongen A, B en D.
3. Latentiesignaal (op basis van statustest): Selecteer de oorsprongen binnen het toegestane latentiebereik van de Front Door-omgeving waar de aanvraag is aangekomen. Dit signaal is gebaseerd op de instelling voor latentiegevoeligheid voor de oorspronkelijke groep en de latentie van de dichtere oorsprongen.
   • Voorbeeld: Stel dat Front Door de latentie van de omgeving waar de aanvraag om 15 ms is aangekomen, heeft gemeten, terwijl de latentie voor B 30 ms is en D 60 ms verwijderd is. Als de latentiegevoeligheid van de oorspronkelijke groep is ingesteld op 30 ms, bestaat de laagste latentiegroep uit oorsprongS A en B, omdat D meer dan 30 ms verwijderd is van de dichtstbijzijnde oorsprong die A is.
4. Gewichten: Ten slotte rondt Azure Front Door het verkeer af tussen de uiteindelijke geselecteerde groep oorsprongen in de opgegeven verhouding van gewichten.
   • Voorbeeld: Als oorsprong A een gewicht van 3 heeft en B een gewicht van 7 heeft, wordt het verkeer 3/10 gedistribueerd naar oorsprong A en 7/10 naar oorsprong B.

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

Laagste latentie op basis van verkeersroutering

Het implementeren van oorsprongen op twee of meer locaties over de hele wereld kan de reactiesnelheid van uw toepassingen verbeteren door verkeer door te sturen naar de bestemming die zich 'het dichtst bij uw eindgebruikers' bevindt. Latentie is de standaardmethode voor verkeersroutering voor uw Front Door-configuratie. Met deze routeringsmethode worden aanvragen van uw eindgebruikers doorgestuurd naar de dichtstbijzijnde oorsprong achter Azure Front Door. Dit routeringsmechanisme in combinatie met de anycast-architectuur van Azure Front Door zorgt ervoor dat elk van uw eindgebruikers de beste prestaties krijgt op basis van hun locatie.

De dichtstbijzijnde oorsprong ligt niet noodzakelijkerwijs het dichtst bij de geografische afstand. In plaats daarvan bepaalt Azure Front Door de dichtstbijzijnde oorsprong door de netwerklatentie te meten. Meer informatie over azure Front Door-routeringsarchitectuur.

Elke Front Door-omgeving meet de oorspronkelijke latentie afzonderlijk. Dit betekent dat verschillende gebruikers op verschillende locaties worden doorgestuurd naar de oorsprong met de beste prestaties voor die omgeving.

Notitie

De eigenschap latentiegevoeligheid is standaard ingesteld op 0 ms. Met deze instelling wordt de aanvraag altijd doorgestuurd naar de snelste beschikbare origins en gewichten op de oorsprong, tenzij twee origins dezelfde netwerklatentie hebben.

Verkeersroutering op basis van prioriteit

Vaak wil een organisatie hoge beschikbaarheid bieden voor hun services door meer dan één back-upservice te implementeren voor het geval de primaire service uitvalt. In de hele branche wordt dit type topologie ook wel actief/stand-by- of actief/passieve implementatie genoemd. Met de methode Prioriteit voor verkeersroutering kunt u dit failoverpatroon eenvoudig implementeren.

De standaard azure Front Door bevat een lijst met gelijke prioriteit van oorsprongen. Standaard verzendt Azure Front Door alleen verkeer naar de oorsprongen met de hoogste prioriteit (laagste waarde in prioriteit) als de primaire set origins. Als de primaire origins niet beschikbaar zijn, stuurt Azure Front Door het verkeer naar de secundaire set origins (tweede laagste waarde voor prioriteit). Als zowel de primaire als de secundaire oorsprong niet beschikbaar zijn, gaat het verkeer naar de derde, enzovoort. De beschikbaarheid van de oorsprong is gebaseerd op de geconfigureerde status en de doorlopende status van de oorsprong die wordt bepaald door de statustests.

Prioriteit voor oorsprong configureren

Elke oorsprong in uw oorspronkelijke groep van de Azure Front Door-configuratie heeft een eigenschap met de naam Priority, die een getal tussen 1 en 5 kan zijn. Met Azure Front Door kunt u de oorsprongsprioriteit expliciet configureren met behulp van deze eigenschap voor elke oorsprong. Deze eigenschap is een waarde tussen 1 en 5. Hoe lager de waarde hoe hoger de prioriteit. Origins kunnen dezelfde prioriteitswaarden delen.

Gewogen verkeersrouteringsmethode

Met de gewogen verkeersrouteringsmethode kunt u verkeer gelijkmatig verdelen of een vooraf gedefinieerde weging gebruiken.

In de gewogen verkeersrouteringsmethode wijst u een gewicht toe aan elke oorsprong in de Azure Front Door-configuratie van uw oorspronkelijke groep. Het gewicht is een geheel getal tussen 1 en 1000. Deze parameter gebruikt een standaardgewicht van 50.

Met de lijst met beschikbare origins die een acceptabele latentiegevoeligheid hebben, wordt het verkeer gedistribueerd met een round robin-mechanisme met behulp van de opgegeven verhouding van gewichten. Als de latentiegevoeligheid wordt ingesteld op 0 milliseconden, wordt deze eigenschap pas van kracht als er twee oorsprongen zijn met dezelfde netwerklatentie.

De gewogen methode maakt enkele nuttige scenario's mogelijk:

• Geleidelijke toepassingsupgrade: biedt een percentage verkeer om naar een nieuwe oorsprong te routeren en verhoogt geleidelijk het verkeer in de loop van de tijd om het te pareren met andere oorsprongen.
• Toepassingsmigratie naar Azure: maak een origin-groep met zowel Azure als externe origins. Pas het gewicht van de oorsprongen aan om de voorkeur te geven aan de nieuwe oorsprongen. U kunt dit geleidelijk instellen met het feit dat de nieuwe origins zijn uitgeschakeld en ze vervolgens de laagste gewichten toewijzen, waardoor het langzaam toeneemt naar niveaus waar het meeste verkeer wordt gebruikt. Schakel ten slotte de minder voorkeursoorsprongen uit en verwijder ze uit de groep.
• Cloud-bursting voor extra capaciteit: Breid een on-premises implementatie snel uit in de cloud door deze achter Front Door te plaatsen. Wanneer u extra capaciteit in de cloud nodig hebt, kunt u meer origins toevoegen of inschakelen en opgeven welk deel van het verkeer naar elke oorsprong gaat.

Sessieaffiniteit

Standaard stuurt Azure Front Door aanvragen die afkomstig zijn van dezelfde client door naar verschillende origins zonder sessieaffiniteit. Bepaalde stateful toepassingen of in bepaalde scenario's bij het uitgeven van aanvragen van dezelfde gebruiker geeft de voorkeur aan dezelfde oorsprong om de eerste aanvraag te verwerken. De functie sessieaffiniteit op basis van cookies is handig als u een gebruikerssessie op dezelfde oorsprong wilt houden, zoals scenario's waarin clients zich verifiëren bij de oorsprong. Wanneer u beheerde cookies gebruikt met SHA256 van de oorspronkelijke URL als de id in de cookie, kan Azure Front Door het verlenen van verkeer van een gebruikerssessie naar dezelfde oorsprong leiden voor verwerking.

Sessieaffiniteit kan worden ingeschakeld op het niveau van de oorspronkelijke groep in de Azure Front Door Standard- en Premium-laag en het front-endhostniveau in Azure Front Door (klassiek) voor elk van uw geconfigureerde domeinen (of subdomeinen). Zodra deze functie is ingeschakeld, voegt Azure Front Door een cookie toe aan de sessie van de gebruiker. De cookies worden ASLBSA en ASLBSACORS genoemd. Met sessieaffiniteit op basis van cookies kan Front Door verschillende gebruikers identificeren, zelfs als ze zich achter hetzelfde IP-adres bevinden, wat op zijn beurt een meer gelijkmatige distributie van verkeer tussen uw verschillende oorsprongen toestaat.

De cookie blijft even lang actief als de gebruikerssessie, omdat Front Door momenteel alleen ondersteuning biedt voor sessiecookies.

Notitie

Ongeacht waar deze is geconfigureerd, wordt sessieaffiniteit onthouden via de browsersessiecookie op domeinniveau. Subdomeinen onder hetzelfde domein met jokertekens kunnen de sessieaffiniteit delen zolang dezelfde gebruikersbrowser aanvragen verzendt voor dezelfde bron van oorsprong.

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

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

• Het antwoord moet de Cache-Control header van no-store bevatten.
• Als het antwoord een Authorization header bevat, mag het niet verlopen zijn.
• 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.