Statustests van Azure Load Balancer

  • Artikel

Een Azure Load Balancer-statustest is een functie waarmee de status van uw toepassingsexemplaren wordt gedetecteerd. Er wordt een aanvraag naar de instanties verzonden om te controleren of deze beschikbaar zijn en te reageren op aanvragen. De statustest kan worden geconfigureerd voor het gebruik van 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 statustests om de fout van een toepassing te detecteren. 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 inkomend.

Testprotocollen

Statustests 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:

Standaard SKU Basis-SKU
Testprotocol TCP, HTTP, HTTPS TCP, HTTP
Gedrag van testen naar beneden Alle tests worden uitgeschakeld, alle TCP-stromen worden voortgezet. Alle tests zijn offline, alle TCP-stromen verlopen.

Testeigenschappen

Statustests hebben de volgende eigenschappen:

Naam van statustesteigenschap DETAILS
Naam Naam van de statustest. Dit is een naam die u kunt definiëren voor uw statustest
Protocol Protocol van statustest. Dit is het protocoltype dat u wilt gebruiken voor de statustest. Opties zijn: TCP, HTTP, HTTPS
Poort Poort van de statustest. De doelpoort die u wilt gebruiken als de statustest wordt gebruikt wanneer deze verbinding maakt met de virtuele machine om de status ervan te controleren
Interval (seconden) Interval van statustest. De hoeveelheid tijd (in seconden) tussen verschillende tests op twee opeenvolgende statuscontrolepogingen naar de virtuele machine
Wordt gebruikt door De lijst met load balancer-regels die gebruikmaken van deze specifieke statustest. U moet ten minste één regel hebben die de statustest gebruikt om deze effectief te laten zijn

Testconfiguratie

De configuratie van de statustest bestaat uit de volgende elementen:

Configuratie van statustest DETAILS
Protocol Protocol van statustest. Dit is het protocoltype dat u wilt gebruiken voor de statustest. Beschikbare opties zijn: TCP, HTTP, HTTPS
Poort Poort van de statustest. De doelpoort die u wilt gebruiken als de statustest wordt 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 luistert op deze poort (dat wil gezegd, de poort is geopend).
Interval Interval van statustest. De hoeveelheid tijd (in seconden) tussen opeenvolgende statuscontrolepogingen naar de virtuele machine

Testprotocol

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

Scenario TPC-test HTTP/HTTPS-test
Overzicht TCP-tests initiëren een verbinding door een open TCP-handshake in drie richtingen uit te voeren met de gedefinieerde poort. TCP-tests beëindigen een verbinding met een vierrichtingsverbinding sluiten TCP-handshake. HTTP en HTTPS geven een HTTP GET met het opgegeven pad. Beide tests ondersteunen relatieve paden voor de HTTP GET. 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 van testfouten Een TCP-test mislukt wanneer: 1. De TCP-listener op het exemplaar reageert helemaal niet tijdens de time-outperiode. Een test wordt gemarkeerd op basis van het aantal time-outtestaanvragen, die zijn geconfigureerd om onbeantwoord te gaan voordat de test wordt gemarkeerd. 2. De test ontvangt een TCP-reset van het exemplaar. 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-statustests worden beschouwd als in orde en markeren het back-endeindpunt als in orde wanneer: 1. De statustest is eenmaal geslaagd nadat de VM is opgestart. 2. Elk back-endeindpunt dat een goede status heeft bereikt, komt in aanmerking voor het ontvangen van nieuwe stromen. De statustest wordt gemarkeerd wanneer het exemplaar reageert met een HTTP-status 200 binnen de time-outperiode. HTTP/HTTPS-statustests worden beschouwd als in orde en markeren het back-endeindpunt als in orde wanneer: 1. De statustest is eenmaal geslaagd nadat de VM is opgestart. 2. Elk back-endeindpunt dat een goede status heeft bereikt, komt in aanmerking voor het ontvangen van nieuwe stromen.

Notitie

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

Gedrag van testen naar beneden

Scenario TCP-verbindingen UDP-datagrammen
Tests met één exemplaar omlaag Nieuwe TCP-verbindingen slagen erin om het back-endeindpunt in orde te houden. Tot stand gebrachte TCP-verbindingen met dit back-endeindpunt worden voortgezet. Bestaande UDP-stromen worden verplaatst naar een ander exemplaar in orde in de back-endpool.
Test alle exemplaren omlaag Er worden geen nieuwe stromen verzonden naar de back-endpool. 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 beëindigt alle bestaande TCP-stromen naar de back-endpool. Alle bestaande UDP-stromen worden beëindigd.

Testinterval en time-out

De intervalwaarde bepaalt hoe vaak de statustest controleert op een reactie van uw back-endpoolexemplaren. Als de statustest mislukt, worden de exemplaren van de back-endpool onmiddellijk gemarkeerd als beschadigd. Als de statustest slaagt bij de volgende statustest, markeert Azure Load Balancer de exemplaren van uw back-endpool als in orde. De statustest probeert standaard elke 5 seconden de geconfigureerde statustestpoort te controleren, maar kan expliciet worden ingesteld op een andere waarde.

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-test: N/B (tests mislukken zodra de geconfigureerde duur van het testinterval is verstreken en de volgende test is verzonden)
  • Time-outduur http/S-test: 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 antwoord wordt ontvangen. Als een HTTP-statustest bijvoorbeeld is geconfigureerd met een testinterval van 120 seconden (elke 2 minuten) en er geen testreactie binnen de eerste 30 seconden wordt ontvangen, heeft de test de time-outperiode bereikt en mislukt.

Ontwerprichtlijnen

  • Wanneer u het statusmodel voor uw toepassing ontwerpt, test u een poort op een back-endeindpunt dat de status van het exemplaar en de toepassingsservice 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 deze dezelfde poort zijn.

  • 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 van de test manipuleren om de levering van nieuwe verbindingen met een exemplaar te beperken door de statustest te mislukken. U kunt het onderhoud van uw toepassing voorbereiden en het leegmaken van verbindingen met uw toepassing initiëren. Met een test downsignaal kunnen TCP-stromen altijd doorgaan totdat de time-out voor inactiviteit of het sluiten van de verbinding in een Standard Load Balancer wordt gesloten.

  • Genereer voor een UDP-toepassing met gelijke taakverdeling een aangepast statustestsignaal van het back-endeindpunt. Gebruik TCP, HTTP of HTTPS voor de statustest die overeenkomt met de bijbehorende listener.

  • Taakverdelingsregel ha-poorten met Standard Load Balancer. Alle poorten zijn taakverdeling en één statustestantwoord moet de status van het hele exemplaar weerspiegelen.

  • Vertaal of proxy geen statustest via het exemplaar dat de statustest 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 statustest is geconfigureerd om een poort te testen die door de externe apparaatproxy's wordt gebruikt of wordt omgezet naar andere virtuele machines achter het apparaat. Als u dezelfde poort test die wordt gebruikt voor het vertalen of proxyaanvragen naar de andere virtuele machines achter het apparaat, markeert elke testreactie van één virtuele machine het apparaat. Deze configuratie kan leiden tot een trapsgewijze fout van de toepassing. De trigger kan een onregelmatige testfout zijn die ervoor zorgt dat de load balancer het apparaatexemplaren markeert. Met deze actie kunt u uw toepassing uitschakelen. Test de status van het apparaat zelf. De selectie van de test om het statussignaal te bepalen, is een belangrijke overweging voor scenario's met virtuele netwerkapparaten (NVA). 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 het bronnetwerk per interface vertalen in de VIRTUELE machine.

  • Houd er rekening mee dat een testdefinitie niet verplicht of gecontroleerd is wanneer u Azure PowerShell, Azure CLI, Sjablonen of API gebruikt. Testvalidatietests worden alleen uitgevoerd wanneer u Azure Portal gebruikt.

  • Als de statustest fluctueert, wacht de load balancer langer voordat het back-endeindpunt weer in orde is. Deze extra wachttijd beschermt de gebruiker en de infrastructuur en is een opzettelijk beleid.

  • Zorg ervoor dat de exemplaren van de virtuele machine worden uitgevoerd. Voor elk actief exemplaar in de back-endpool controleert de statustest op beschikbaarheid. Als een exemplaar is gestopt, wordt deze pas opnieuw uitgevoerd nadat het 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.

Controleren

Standard Load Balancer maakt per eindpunt en statustest voor back-endeindpunten beschikbaar via Azure Monitor. Andere Azure-services of partnertoepassingen kunnen deze metrische gegevens gebruiken. Azure Monitor-logboeken worden niet ondersteund voor Basic Load Balancer.

IP-adres van testbron

Voor de statustest van Load Balancer om uw exemplaar te markeren, moet u 168.63.129.16 IP-adres toestaan in alle Azure-netwerkbeveiligingsgroepen en lokaal 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. Op zijn beurt markeert Azure Load Balancer uw exemplaar als offline vanwege de fout in 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-tests gebruiken een koppelingsadres als bron.

Beperkingen

  • HTTPS-tests bieden geen ondersteuning voor wederzijdse verificatie met een clientcertificaat.

  • Stel dat statustests mislukken wanneer TCP-tijdstempels zijn ingeschakeld.

  • Een statustest voor de load balancer van de Basic-SKU wordt niet ondersteund met een virtuele-machineschaalset.

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

Volgende stappen