Delen via

Statuscontroles

  • Artikel

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.

Notitie

Een oorsprongs - en oorsprongsgroep in dit artikel verwijst naar de back-end- en back-endpool van een Azure Front Door-configuratie (klassiek).

Om de status en nabijheid van elke oorsprong voor een bepaalde Azure Front Door-omgeving te bepalen, verzendt elk Front Door-profiel periodiek een synthetische HTTP/HTTPS-aanvraag naar al uw geconfigureerde origins. Front Door gebruikt vervolgens reacties van de statustest om de beste oorsprong te bepalen om uw clientaanvragen naar te routeren.

Waarschuwing

Omdat elke Azure Front Door-edge-locatie statustests naar uw oorsprongen verzendt, kan het statustestvolume voor uw oorsprongen hoog zijn. Het aantal tests is afhankelijk van de verkeerslocatie van uw klant en de frequentie van uw statustest. Als de Edge-locaties van Azure Front Door geen echt verkeer van uw eindgebruikers ontvangen, wordt de frequentie van de statustest vanaf de randlocatie afgenomen van de geconfigureerde frequentie. Als er verkeer is naar alle Edge-locaties van Azure Front Door, kan het statustestvolume hoog zijn, afhankelijk van de frequentie van uw statustests.

Een voorbeeld om een schatting te maken van het volume van de statustest per minuut naar een oorsprong bij gebruik van de standaardtestfrequentie van 30 seconden. Het testvolume op elk van uw oorsprong is gelijk aan het aantal edge-locaties dat twee aanvragen per minuut heeft. De testaanvragen zijn minder als er geen verkeer naar alle edge-locaties wordt verzonden. Zie edge-locaties per regio voor een lijst met edge-locaties.

Ondersteunde protocollen

Azure Front Door biedt ondersteuning voor het verzenden van tests via HTTP- of HTTPS-protocollen. Deze tests worden verzonden via dezelfde TCP-poorten die zijn geconfigureerd voor het routeren van clientaanvragen en kunnen niet worden overschreven. Front Door HTTP/HTTPS-tests worden verzonden met User-Agent headerset met waarde: Edge Health Probe.

Ondersteunde HTTP-methoden voor statustests

Azure Front Door ondersteunt de volgende HTTP-methoden voor het verzenden van de statustests:

  1. GET: De GET-methode betekent dat alle informatie (in de vorm van een entiteit) wordt geïdentificeerd door de aanvraag-URI.
  2. HEAD: De HEAD-methode is identiek aan GET, behalve dat de server GEEN berichttekst in het antwoord mag retourneren. Voor nieuwe Front Door-profielen wordt standaard de testmethode ingesteld als HEAD.

Tip

Als u de belasting en kosten voor uw oorsprong wilt verlagen, raadt Front Door aan head-aanvragen voor statustests te gebruiken.

Statustestantwoorden

Responsen Beschrijving
Status bepalen Een 200 OK-statuscode geeft aan dat de oorsprong in orde is. Elke andere statuscode wordt beschouwd als een fout. Als om welke reden dan ook een geldig HTTP-antwoord niet wordt ontvangen voor een test, wordt de test geteld als een fout.
Latentie meten Latentie is de tijd van de wandklok gemeten vanaf het moment direct voordat de testaanvraag wordt verzonden naar het moment waarop Front Door de laatste byte van het antwoord ontvangt. Front Door maakt gebruik van een nieuwe TCP-verbinding voor elke aanvraag. De meting is niet gericht op oorsprongen met bestaande warme verbindingen.

Hoe Front Door de oorsprongsstatus bepaalt

Azure Front Door maakt gebruik van een proces in drie stappen voor alle algoritmen om de status te bepalen.

  1. Uitgeschakelde origins uitsluiten.

  2. Oorsprongen uitsluiten die statustestsfouten hebben:

    • Deze selectie wordt uitgevoerd door de laatste n statustestreacties te bekijken. Als ten minste x in orde is, wordt de oorsprong als gezond beschouwd.

    • n wordt geconfigureerd door de eigenschap SampleSize te wijzigen in instellingen voor taakverdeling.

    • x wordt geconfigureerd door de eigenschap SuccessfulSamplesRequired te wijzigen in taakverdelingsinstellingen.

  3. Voor sets met gezonde oorsprongen in een oorsprongsgroep meet Front Door de latentie voor elke oorsprong en behoudt deze de latentie.

Notitie

Als één eindpunt lid is van meerdere oorsprongsgroepen, optimaliseert Front Door het aantal statustests dat naar de oorsprong wordt verzonden om de belasting van de oorsprong te verminderen. Statustestaanvragen worden verzonden op basis van het laagste geconfigureerde voorbeeldinterval. De antwoorden van dezelfde statustests bepalen de status van het eindpunt in alle oorsprongsgroepen.

Testinstellingen voor lang startende containers aanpassen

Wanneer u te maken hebt met lang startende containers, kan het aanpassen van de testinstellingen voortijdige fouten voorkomen. Door de ProbeTimeout waarden te verhogen, Interval krijgen uw containers meer tijd om te beginnen voordat Front Door ze als beschadigd markeert.

Waarden voor lang startende containers

  • ProbeTimeout: Verhoog de time-outperiode tot 10-30 seconden.
  • Interval: Stel een langer interval in (bijvoorbeeld 30-60 seconden) tussen tests.
  • Slechte statusThreshold: Verhoog het aantal opeenvolgende mislukte tests voordat de container als beschadigd wordt beschouwd (bijvoorbeeld 3-5 nieuwe pogingen).

Notitie

De waarden die worden opgegeven voor ProbeTimeout, Intervalen UnhealthyThreshold zijn voorbeeldbereiken voor voorbeelddoeleinden. U kunt deze waarden aanpassen op basis van het opstartgedrag en de vereisten van uw specifieke container.

Notitie

Deze wijzigingen kunnen leiden tot een vertraging bij het detecteren van echte fouten, dus zorg ervoor dat deze waarden zorgvuldig worden afgestemd op het opstartgedrag van uw container.

Testinteractie tijdens fasen van de levenscyclus van containers

  1. Beginfase van container: Tijdens deze fase is de container mogelijk niet volledig gereed voor het verwerken van verkeer. Statustests helpen detecteren wanneer een container niet reageert door te controleren op specifieke HTTP-statuscodes (bijvoorbeeld 200 OK). Als de testfrequentie te hoog is of de time-out te kort is, wordt de container gemarkeerd als beschadigd vóór de initialisatie. Verhoog de time-outs of intervallen van de test tijdens deze fase.

  2. Actieve fase: zodra de container wordt uitgevoerd, worden de statusreacties gecontroleerd. Als statuscontroles consistent retourneren 200 OK, houdt Front Door de oorsprong in rotatie voor verkeer. Als tests consistent mislukken (bijvoorbeeld omdat een container vastloopt), markeert Front Door de oorsprong als beschadigd.

  3. Foutfase: als statustests mislukken voor de geconfigureerde drempelwaarde (bijvoorbeeld UnhealthyThreshold), wordt de oorsprong als beschadigd beschouwd en wordt verkeer doorgestuurd naar andere gezonde oorsprongen.

Mislukte statustest voltooien

Als statustests mislukken voor elke oorsprong in een oorsprongsgroep, worden alle oorsprongen beschadigd beschouwd en wordt verkeer gerouteerd in een round robin-distributie over alle oorsprongen.

Zodra een oorsprong terugkeert naar een goede status, hervat Front Door het normale taakverdelingsalgoritmen.

Statustests uitschakelen

Als u één oorsprong in uw oorspronkelijke groep hebt, kunt u ervoor kiezen om statustests uit te schakelen om de belasting van uw toepassing te verminderen. Als u meerdere origins in uw oorspronkelijke groep hebt en er meer dan één van deze is ingeschakeld, kunt u statustests niet uitschakelen.

Notitie

Als er slechts één oorsprong in uw oorspronkelijke groep is, krijgt de ene oorsprong enkele statustests. Dit kan leiden tot een dip in metrische gegevens over de status van oorsprong, maar uw verkeer wordt niet beïnvloed.

Volgende stappen