Statuscontroles van Azure Load Balancer

Een Azure Load Balancer-statustest is een functie waarmee de status van uw toepassingsexemplaren wordt gedetecteerd. Het verzendt een verzoek naar de instanties om te controleren of ze beschikbaar zijn en op verzoeken reageren. De healthprobe kan worden geconfigureerd voor verschillende protocollen, zoals TCP, HTTP of HTTPS. Het is een belangrijke functie omdat u hiermee toepassingsfouten kunt detecteren, belasting kunt beheren en downtime kunt plannen.

Azure Load Balancer-regels vereisen een statustest om de eindpuntstatus te detecteren. De configuratie van de statustest en testreacties bepaalt welke exemplaren van de back-endpool nieuwe verbindingen ontvangen. Gebruik healthprobes om te detecteren wanneer een toepassing uitvalt. Genereer een aangepast antwoord op een statustest. Gebruik de statustest voor stroombeheer om belasting of geplande downtime te beheren. Wanneer een statustest mislukt, stopt de load balancer met het verzenden van nieuwe verbindingen naar het respectieve beschadigde exemplaar. De uitgaande connectiviteit wordt niet beïnvloed, alleen de inkomende.

Probeprotocollen

Statuscontroles ondersteunen meerdere protocollen. De beschikbaarheid van een specifiek statustestprotocol verschilt per Load Balancer-SKU. Daarnaast varieert het gedrag van de service per Load Balancer-SKU, zoals wordt weergegeven in deze tabel:

SKU Testprotocol Gedrag bij neergelaten sonde
Standaard TCP, HTTP, HTTPS Alle probes zijn uitgevallen, alle TCP-verbindingen blijven actief.
Basis TCP, HTTP Alle probes zijn uitgevallen, alle TCP-sessies vervallen.

Sonde-eigenschappen

Statustests hebben de volgende eigenschappen:

Naam van eigenschap van health probe Details
Name Naam van de health-probe. Dit is een naam die u zelf kunt opgeven voor uw health probe
Protocol Protocol van de gezondheidscontrole. Dit is het type protocol dat de health probe moet gebruiken. Opties zijn: TCP, HTTP, HTTPS
Poort Poort van de gezondheidscontrole. De doelpoort die u wilt dat de statuscontrole gebruikt wanneer deze verbinding maakt met de virtuele machine om de status te controleren
Interval (seconden) Interval voor gezondheidscontrole. De hoeveelheid tijd (in seconden) tussen verschillende sondes tijdens twee opeenvolgende statuscontroles van de virtuele machine
Drempel Drempelwaarde van de statuscontrole. Het aantal keren dat de statuscontrole moet slagen of mislukken om verkeer naar de virtuele machine toe te laten of te blokkeren
Wordt gebruikt door Lijst met regels voor de load balancer die deze statustest gebruiken. Er moet ten minste één regel zijn die de statusprobe gebruikt, zodat deze effectief is.

Testconfiguratie

De configuratie van de statusprobe bestaat uit de volgende elementen:

Configuratie van statustest Details
Protocol Protocol van de gezondheidscontrole. Dit is het type protocol dat de health probe moet gebruiken. Beschikbare opties zijn: TCP, HTTP, HTTPS
Poort Poort van de gezondheidscontrole. De bestemmingspoort die u wilt dat de statustest gebruikt wanneer deze verbinding maakt met de virtuele machine om de status van de virtuele machine te controleren. U moet ervoor zorgen dat de virtuele machine ook op deze poort luistert (dat wil zeggen dat de poort open staat).
Interval Interval voor gezondheidscontrole. De hoeveelheid tijd (in seconden) tussen opeenvolgende statuscontrolepogingen naar de virtuele machine

Probeprotocol

Het protocol dat door de statustest wordt gebruikt, kan worden geconfigureerd op een van de volgende opties: TCP, HTTP, HTTPS.

Scenario TCP-onderzoek HTTP/HTTPS-test
Overview TCP-probes brengen een verbinding tot stand door een TCP-handshake in drie stappen uit te voeren met de opgegeven poort. TCP-probes beëindigen een verbinding met een TCP-afsluitingshandshake in vier stappen. HTTP en HTTPS geven een HTTP GET met het opgegeven pad. Beide probes ondersteunen relatieve paden bij HTTP GET-verzoeken. HTTPS-tests zijn hetzelfde als HTTP-tests met de toevoeging van tls (Transport Layer Security). HTTP-/HTTPS-tests kunnen handig zijn om uw eigen logica te implementeren om exemplaren uit de load balancer te verwijderen als de testpoort ook de listener voor de service is.
Gedrag bij probefouten Een TCP-test mislukt wanneer:
1. De TCP-listener op het exemplaar reageert helemaal niet tijdens de time-outperiode. Een probe wordt als niet beschikbaar gemarkeerd op basis van het aantal probeaanvragen waarvoor een time-out is opgetreden en die zo zijn geconfigureerd dat ze onbeantwoord blijven voordat de probe als niet beschikbaar wordt gemarkeerd.
2. De probe ontvangt een TCP-reset van de instantie.		 Een HTTP/HTTPS-test mislukt wanneer:
1. Testeindpunt retourneert een andere HTTP-antwoordcode dan 200 (bijvoorbeeld 403, 404 of 500).
2. Het testeindpunt reageert helemaal niet tijdens het minimum van het testinterval en een time-outperiode van 30 seconden. Meerdere testaanvragen kunnen onbeantwoord blijven voordat de test wordt gemarkeerd als niet actief en totdat de som van alle time-outintervallen is bereikt.
3. Het testeindpunt sluit de verbinding via een TCP-reset.
Gedrag testen TCP-statuscontroles worden als gezond beschouwd en markeren het back-end-eindpunt als gezond wanneer:
1. De health-probe slaagt één keer nadat de VM is opgestart.
2. Elk back-end-eindpunt dat zich in een gezonde toestand bevindt, kan nieuwe datastromen ontvangen.		 De statuscontrole wordt als geslaagd beschouwd wanneer de instantie binnen de time-outperiode reageert met een HTTP-statuscode 200. HTTP/HTTPS-statuscontroles worden als gezond beschouwd en markeren het back-end-eindpunt als gezond wanneer:
1. De health-probe slaagt één keer nadat de VM is opgestart.
2. Elk back-end-eindpunt dat zich in een gezonde toestand bevindt, kan nieuwe datastromen ontvangen.

Opmerking

Voor de HTTPS-test is het gebruik van certificaten vereist op basis van een minimale handtekeninghash van SHA256 in de hele keten.

Gedrag bij uitval van de sonde

Scenario TCP-verbindingen UDP-datagrammen
Tests met één exemplaar omlaag Nieuwe TCP-verbindingen slagen erin om het back-endeindpunt in orde te houden. Bestaande TCP-verbindingen met dit back-end-eindpunt blijven bestaan. Bestaande UDP-verkeersstromen worden verplaatst naar een andere gezonde instantie in de back-endpool.
Controleer alle instanties naar beneden Er worden geen nieuwe verbindingen naar de back-endpool verzonden. Met Standard Load Balancer kunnen bestaande TCP-stromen worden voortgezet, gezien het feit dat een back-endpool meer dan één back-endinstantie heeft. Basic Load Balancer (met pensioen) beëindigt alle bestaande TCP-stromen naar de backendpool. Alle bestaande UDP-stromen worden beëindigd.

Sonde-interval en time-out

De intervalwaarde bepaalt hoe vaak de statusprobe controleert of er een reactie is van de instanties in uw back-endpool. Als de statuscontrole mislukt, markeert de load balancer de instanties in uw backendpool onmiddellijk als ongezond. Als de health probe slaagt bij de volgende controle, markeert Azure Load Balancer je backend-poolinstanties als gezond. De health probe probeert standaard elke 5 seconden de geconfigureerde health probe-poort te controleren in het Azure-portaal, maar je kunt deze op een andere waarde zetten. Wanneer je deployt via ARM-sjablonen, de REST API, de Azure CLI of PowerShell, is het standaardinterval 15 seconden (minimaal 5 seconden).

Om ervoor te zorgen dat een tijdig antwoord wordt ontvangen, hebben HTTP/S-statustests ingebouwde time-outs. Hier volgen de time-outduur voor TCP- en HTTP/S-tests:

  • Time-outduur van TCP-probe: n.v.t. (probes mislukken zodra het geconfigureerde probe-interval is verstreken en de volgende probe wordt verstuurd)
  • Time-outduur van de HTTP/S-controle: 30 seconden

Als voor HTTP/S-tests het geconfigureerde interval langer is dan de bovenstaande time-outperiode, treedt er een time-out op en mislukt de statustest als er tijdens de time-outperiode geen reactie wordt ontvangen. Als een HTTP-statustest bijvoorbeeld is geconfigureerd met een testinterval van 120 seconden (elke 2 minuten) en er binnen de eerste 30 seconden geen testreactie wordt ontvangen, wordt de time-outperiode bereikt en mislukt de test. Wanneer het geconfigureerde interval korter is dan de bovenstaande time-outperiode, mislukt de statustest als er geen antwoord wordt ontvangen voordat de geconfigureerde intervalperiode is voltooid en de volgende test onmiddellijk wordt verzonden.

Probedrempel

De drempelwaarde van de probe is het aantal opeenvolgende keren dat een health probe moet slagen of mislukken voordat de probe een back-endexemplaar als respectievelijk gezond of ongezond markeert.

Als de testdrempel voor TCP-tests is geconfigureerd op 2, moet de test twee opeenvolgende antwoorden ontvangen voordat een back-endinstantie verkeer begint te ontvangen. Evenzo geldt dat, zodra een back-endinstantie als gezond wordt beschouwd, er twee opeenvolgende fouten of time-outs nodig zijn voordat de instantie als ongezond wordt beschouwd en geen nieuw verkeer meer doorgestuurd krijgt.

Voor HTTP-probes zorgen expliciete antwoorden er onmiddellijk voor dat de probe bij 200- en niet-200-antwoorden als beschikbaar of niet beschikbaar wordt gemarkeerd, en wordt de drempelwaarde effectief opnieuw ingesteld. Dit betekent dat de drempelwaarde alleen van toepassing is op HTTP-probes als de probe een time-out geeft doordat er geen reactie komt.

Ontwerprichtlijnen

  • Wanneer u het gezondheidsmodel voor uw toepassing ontwerpt, controleert u een poort op een backend-eindpunt dat de gezondheid van het exemplaar en de applicatieservice weerspiegelt. De toepassingspoort en de testpoort hoeven niet hetzelfde te zijn. In sommige scenario's kan het wenselijk zijn dat de testpoort anders is dan de poort die uw toepassing gebruikt, maar over het algemeen wordt aanbevolen dat tests dezelfde poort gebruiken.

  • Het kan handig zijn voor uw toepassing om een statustestreactie te genereren en de load balancer te signaleren of uw exemplaar nieuwe verbindingen moet ontvangen. U kunt het antwoord op de probe manipuleren om het doorsturen van nieuwe verbindingen naar een exemplaar te vertragen door de health probe te laten mislukken. U kunt het onderhoud van uw toepassing voorbereiden en het leegmaken van verbindingen met uw toepassing initiëren. Een 'probe down'-signaal zorgt er in een Standard Load Balancer altijd voor dat TCP-stromen doorgaan totdat een time-out wegens inactiviteit optreedt of de verbinding wordt gesloten.

  • Genereer voor een UDP-toepassing met load balancing een aangepast healthprobesignaal vanaf het back-end-eindpunt. Gebruik TCP, HTTP of HTTPS voor de statustest die overeenkomt met de bijbehorende listener.

  • Load balanceringsregel voor HA-poorten met Standard Load Balancer. Alle poorten zijn taakgebalanceerd en het antwoord op één statusprobe moet de status van de volledige instantie weerspiegelen.

  • Vertaal een statusprobe niet en stuur deze ook niet via een proxy door via het exemplaar dat de statusprobe ontvangt naar een ander exemplaar in uw virtuele netwerk. Deze configuratie kan leiden tot fouten in uw scenario. Bijvoorbeeld: Een set apparaten van derden wordt geïmplementeerd in de back-endpool van een load balancer om schaal en redundantie voor de apparaten te bieden. De statusprobe is geconfigureerd om een poort te testen die door het apparaat van derden wordt geproxyd of vertaald naar andere virtuele machines achter het apparaat. Als u dezelfde poort controleert die wordt gebruikt om aanvragen te vertalen of als proxy door te sturen naar de andere virtuele machines achter het apparaat, wordt het apparaat door elke controlereactie van één virtuele machine als niet beschikbaar gemarkeerd. Deze configuratie kan leiden tot een trapsgewijze fout van de toepassing. De oorzaak kan een intermitterende storing in een probe zijn, waardoor de load balancer de appliance-instantie als niet beschikbaar markeert. Met deze actie kunt u uw toepassing uitschakelen. Test de status van het apparaat zelf. De selectie van de probe om het gezondheidssignaal te bepalen is een belangrijke overweging voor scenario's met network virtual appliances (NVA's). Raadpleeg de leverancier van uw toepassing voor het juiste statussignaal voor dergelijke scenario's.

  • Als u meerdere interfaces hebt geconfigureerd in uw virtuele machine, moet u reageren op de test op de interface waarop u deze hebt ontvangen. Mogelijk moet u dit adres in de VM per interface met bronnetwerkadresvertaling vertalen.

  • Een testdefinitie is niet verplicht of gecontroleerd wanneer u Azure PowerShell, Azure CLI, Sjablonen of API gebruikt. Validatietests voor probes worden alleen uitgevoerd bij het gebruik van de Azure-portal.

  • Als de statuscontrole schommelt, wacht de load balancer langer voordat deze het backend-eindpunt weer naar een gezonde status terugzet. Deze extra wachttijd beschermt de gebruiker en de infrastructuur en is een opzettelijk beleid.

  • Zorg ervoor dat uw virtuele-machine-instanties actief zijn. Voor elke actieve instantie in de back-endpool controleert de statusprobe of deze beschikbaar is. Als een instantie is gestopt, wordt de instantie pas gecontroleerd nadat deze opnieuw is gestart.

  • Configureer uw virtuele netwerk niet met het IP-adresbereik van Microsoft dat 168.63.129.16 bevat. De configuratie botst met het IP-adres van de statustest en kan ervoor zorgen dat uw scenario mislukt.

  • Als u een statustestfout wilt testen of een afzonderlijk exemplaar wilt markeren, gebruikt u een netwerkbeveiligingsgroep om de statustest expliciet te blokkeren. Maak een NSG-regel om de doelpoort of het bron-IP-adres te blokkeren om de fout van een test te simuleren.

  • In tegenstelling tot loadbalancerregels hoeven inkomende NAT-regels niet te zijn gekoppeld aan een statusprobe.

  • Het wordt niet aanbevolen om het IP-adres of de poort van de Azure Load Balancer-statustest met NSG-regels te blokkeren. Dit is een scenario dat niet wordt ondersteund en kan ertoe leiden dat de NSG-regels met vertraging van kracht worden, waardoor de statuscontroles geen nauwkeurig beeld geven van de beschikbaarheid van uw back-endinstanties.

Bewaking

Standard Load Balancer stelt via Azure Monitor per eindpunt en backend-eindpunt de status van de statuscontrole beschikbaar. Andere Azure-services of partnertoepassingen kunnen deze metrische gegevens gebruiken. Azure Monitor-logboeken worden niet ondersteund voor Basic Load Balancer (buiten gebruik gesteld).

IP-adres van testbron

Als de statusprobe van Azure Load Balancer uw exemplaar als beschikbaar moet aanmerken, moet u het IP-adres 168.63.129.16 toestaan in Azure-netwerkbeveiligingsgroepen en in het lokale firewallbeleid. De AzureLoadBalancer servicetag identificeert dit bron-IP-adres in uw netwerkbeveiligingsgroepen en staat standaard statustestverkeer toe. Hier vindt u meer informatie over dit IP-adres.

Als u het bron-IP-adres van de test in uw firewallbeleid niet toestaat, mislukt de statustest omdat het uw exemplaar niet kan bereiken. Daardoor markeert Azure Load Balancer uw instantie als -down- vanwege het mislukken van de statustest. Deze onjuiste configuratie kan ertoe leiden dat uw toepassingsscenario met gelijke taakverdeling mislukt. Alle IPv4 Load Balancer-statustests zijn afkomstig van het IP-adres 168.63.129.16 als bron. IPv6-probes gebruiken een link-local-adres (fe80::1234:5678:9abc) als bronadres. Voor een Azure Load Balancer met twee stacks moet u een netwerkbeveiligingsgroep configureren voor de IPv6-statustest om te kunnen functioneren.

Limitations

  • HTTPS-probes ondersteunen geen wederzijdse authenticatie met een clientcertificaat.

  • HTTP-probes ondersteunen het gebruik van hostnamen voor probeback-ends niet.

  • Het inschakelen van TCP-tijdstempels kan leiden tot afknijping of andere prestatieproblemen, waardoor statuscontroles een time-out kunnen krijgen.

  • Gezondheidsprobes voor Basic Load Balancer (met pensioen) worden niet ondersteund met een virtuele machine scale set.

  • HTTP-tests bieden geen ondersteuning voor testen op de volgende poorten vanwege beveiligingsproblemen: 19, 21, 25, 70, 110, 119, 143, 220, 993.

Volgende stappen

  • Last updated on