Front Door routeringsmethoden

  • Artikel
  • 7 minuten om te lezen

Azure Front Door biedt ondersteuning voor verschillende soorten verkeersrouteringsmethoden om te bepalen hoe u uw HTTP/HTTPS-verkeer naar verschillende service-eindpunten routeert. Wanneer uw clientaanvragen de Front Door, wordt de geconfigureerde routeringsmethode toegepast om ervoor te zorgen dat de aanvragen worden doorgestuurd naar het beste back-end-exemplaar.

Er zijn vier verkeersrouteringsmethoden beschikbaar in Front Door:

  • Latentie: De routering op basis van latentie zorgt ervoor dat aanvragen worden verzonden naar de back-enden met de laagste latentie die acceptabel zijn binnen een gevoeligheidsbereik. In principe worden uw gebruikersaanvragen verzonden naar de 'dichtstbijzijnde' set back-enden met betrekking tot netwerklatentie.
  • Prioriteit: U kunt prioriteiten toewijzen aan uw back-enden wanneer u een primaire back-end wilt configureren voor al het verkeer. De secundaire back-up kan een back-up zijn voor het geval de primaire back-up niet meer beschikbaar is.
  • Gewogen: U kunt gewichten toewijzen aan uw back-enden wanneer u verkeer gelijkmatig wilt verdelen over een set back-enden of op basis van de gewichtscoëfficiënten. Verkeer wordt gedistribueerd op gewicht als de latentie van de back-ends binnen het acceptabele gevoeligheidsbereik voor latentie in de back-endpool valt.
  • Sessie-affiniteit: U kunt sessie-affiniteit configureren voor uw front-endhosts of -domeinen om ervoor te zorgen dat aanvragen van dezelfde eindgebruiker naar dezelfde back-end worden verzonden.

Alle Front Door-configuraties omvatten bewaking van de back-endstatus en geautomatiseerde, directe failover wereldwijd. Zie back-Front Door voor meer informatie. Uw Front Door werken op basis van één routeringsmethode. Afhankelijk van de behoeften van uw toepassing kunt u echter ook meerdere routeringsmethoden combineren om een optimale routeringstopologie te bouwen.

Laagste verkeersroutering op basis van latentie

Het implementeren van back-ends op twee of meer locaties over de hele wereld kan de reactiesnelheid van uw toepassingen verbeteren door verkeer te routeren naar de bestemming die het dichtst bij uw eindgebruikers ligt. Met de standaardmethode voor verkeersroutering voor uw Front Door-configuratie worden aanvragen van uw eindgebruikers doorgestuurd naar de dichtstbijzijnde back-end van de Front Door-omgeving die de aanvraag heeft ontvangen. In combinatie met de Anycast-architectuur van Azure Front Door zorgt deze aanpak ervoor dat al uw eindgebruikers maximale prestaties kunnen personaliseren op basis van hun locatie.

De 'dichtstbijzijnde' back-enge komt niet noodzakelijkerwijs het dichtst in de buurt, zoals gemeten op geografische afstand. In plaats daarvan Front Door de dichtstbijzijnde back-enden door de netwerklatentie te meten. Lees meer over de routeringsarchitectuur Front Door van uw Front Door.

Hieronder vindt u de algehele beslissingsstroom:

Beschikbare back-enden Prioriteit Latentiesignaal (op basis van statustest) Gewichten
Selecteer eerst alle back-enden die zijn ingeschakeld en die goed zijn geretourneerd (200 OK) voor de statustest. Als er zes back-enden A, B, C, D, E en F zijn en C is beschadigd en E is uitgeschakeld. De lijst met beschikbare back-enden is A, B, D en F. Vervolgens worden de back-enden met de hoogste prioriteit van de beschikbare back-enden geselecteerd. Als back-end A, B en D prioriteit 1 hebben en back-end F een prioriteit van 2 heeft. De geselecteerde back-enden zijn dan A, B en D. Selecteer de back-enden met latentiebereik (minimale latentie & gevoeligheid voor latentie in ms opgegeven). Als back-end A 15 ms is, is B 30 ms en D 60 ms verwijderd van de Front Door-omgeving waar de aanvraag is geland en de latentiegevoeligheid 30 ms is, dan bestaat de laagste latentiegroep uit back-en-a en B, omdat D zich meer dan 30 ms verwijderd van de dichtstbijzijnde back-end van A. Tot slot wordt Front Door verkeer round robin de uiteindelijke geselecteerde groep back-enden in de opgegeven verhouding van gewichten. Stel dat back-end A een gewicht van 5 heeft en back-end B een gewicht van 8 heeft, dan wordt het verkeer verdeeld in de verhouding van 5:8 tussen back-en -a en B.

Notitie

Standaard is de eigenschap latentiegevoeligheid ingesteld op 0 ms, dat wil zeggen dat de aanvraag altijd wordt doorgestuurd naar de snelste beschikbare back-end en gewichten op de back-ends niet van kracht zijn, tenzij twee back-ends dezelfde netwerklatentie hebben.

Op prioriteit gebaseerde verkeersroutering

Vaak wil een organisatie hoge beschikbaarheid voor hun services bieden door meer dan één back-upservice te implementeren voor het geval de primaire uit bedrijf gaat. In de branche wordt deze topologie ook wel de topologie Actief/Stand-by of Actief/Passief genoemd. Met de verkeersrouteringsmethode Prioriteit kunnen Azure-klanten dit failoverpatroon eenvoudig implementeren.

Uw standaard Front Door bevat een lijst met back-enden met gelijke prioriteit. Standaard verzendt Front Door alleen verkeer naar de back-einden met de hoogste prioriteit (laagste waarde voor prioriteit), dat wil zeggen, de primaire set back-ends. Als de primaire back-enden niet beschikbaar zijn, Front Door het verkeer door naar de secundaire set back-ends (op een na laagste waarde voor prioriteit). Als zowel de primaire als de secundaire back-en -back-en niet beschikbaar zijn, gaat het verkeer naar de derde, en ga zo maar door. Beschikbaarheid van de back-end is gebaseerd op de geconfigureerde status (ingeschakeld of uitgeschakeld) en de voortdurende status van de back-en-mail, zoals wordt bepaald door de statustests.

Prioriteit voor back-enden configureren

Elke back-end in de back-Front Door van de Front Door-configuratie heeft een eigenschap met de naam Prioriteit. Dit kan een getal tussen 1 en 5 zijn. Met Azure Front Door configureert u de back-endprioriteit expliciet met behulp van deze eigenschap voor elke back-end. Deze eigenschap is een waarde tussen 1 en 5. Lagere waarden vertegenwoordigen een hogere prioriteit. Back-enden kunnen prioriteitswaarden delen.

Methode voor gewogen verkeersroutering

Met de methode Gewogen verkeersroutering kunt u verkeer gelijkmatig verdelen of een vooraf gedefinieerde weging gebruiken.

In de methode Gewogen verkeersroutering wijst u een gewicht toe aan elke back-Front Door configuratie van uw back-endpool. Het gewicht is een geheel getal tussen 1 en 1000. Deze parameter gebruikt een standaardgewicht van '50'.

Met de lijst met beschikbare back-eindes die een acceptabele latentiegevoeligheid hebben, wordt het verkeer gedistribueerd met een round robin-mechanisme met behulp van de opgegeven gewichtsverhouding. Als de latentiegevoeligheid wordt ingesteld op 0 milliseconden, wordt deze eigenschap niet van kracht, tenzij er twee back-enden met dezelfde netwerklatentie zijn.

De gewogen methode maakt een aantal nuttige scenario's mogelijk:

  • Geleidelijke toepassingsupgrade: geeft een percentage van het verkeer dat naar een nieuwe back-end moet worden gerouteerd en verhoog het verkeer geleidelijk in de tijd om het op één lijn te krijgen met andere back-enden.
  • Toepassingsmigratie naar Azure: maak een back-endpool met zowel Azure- als externe back-ends. Pas het gewicht van de back-ends aan om de voorkeur te geven aan de nieuwe back-enden. U kunt dit geleidelijk instellen door de nieuwe back-enden uit te stellen en ze vervolgens het laagste gewicht toe te wijzen, waardoor ze langzaam worden oplopende niveaus waar ze het meeste verkeer nemen. Ten slotte worden de minder voorkeurs-back-ends uit de pool verwijderd.
  • Cloud-bursting voor extra capaciteit: breid snel een on-premises implementatie in de cloud uit door deze achter de Front Door. Wanneer u extra capaciteit in de cloud nodig hebt, kunt u meer back-enden toevoegen of inschakelen en opgeven welk deel van het verkeer naar elke back-end gaat.

Sessieaffiniteit

Standaard worden, zonder sessie-affiniteit, Front Door aanvragen die afkomstig zijn van dezelfde client, doorgestuurd naar verschillende back-enden. Sommige stateful toepassingen of in bepaalde scenario's die aanvragen van dezelfde gebruiker uitgeven, geven de voorkeur aan dezelfde back-end die de eerste aanvraag heeft verwerkt. De functie Sessieaffiniteit op basis van cookies is handig als u een gebruikerssessie op dezelfde back-end wilt behouden. Met behulp van beheerde cookies Azure Front Door verkeer van een gebruikerssessie om te leiden naar dezelfde back-end voor verwerking.

U kunt sessieaffiniteit inschakelen op het hostniveau van de front-end, voor elk van de geconfigureerde domeinen (of subdomeinen). Na het inschakelen voegt Front Door een cookie toe aan de gebruikerssessie. Met op cookies gebaseerde sessieaffiniteit kan Front Door verschillende gebruikers herkennen, zelfs als deze hetzelfde IP-adres hebben. Hierdoor kan er nog meer verkeer worden verdeeld tussen uw verschillende back-ends.

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

Notitie

Openbare proxies kunnen de sessie-affiniteit verstoren. Dit komt doordat het tot stand brengen van een sessie vereist dat Front Door een sessie-affiniteitscookie toevoegt aan het antwoord. Dit kan niet worden gedaan als het antwoord in de cache kan worden opgeslagen, omdat dit de cookies van andere clients die dezelfde resource aanvragen, zou verstoren. Om dit te beschermen, wordt sessie-affiniteit niet tot stand gebracht als de back-end een antwoord in de cache verzendt wanneer dit wordt geprobeerd. Als de sessie al tot stand is gebracht, maakt het niet uit of het antwoord van de back-end in de cache kan worden opgeslagen. Sessie-affiniteit wordt in de volgende omstandigheden tot stand gebracht, tenzij het antwoord een HTTP 304-statuscode heeft:

  • Voor het antwoord zijn specifieke waarden ingesteld voor de header die Cache-Control caching voorkomt, zoals 'privé' of 'geen opslag'.
  • Het antwoord bevat een Authorization header die niet is verlopen.
  • Het antwoord heeft een HTTP 302-statuscode.

Volgende stappen