Status van Load Balancer testen

Wanneer u taakverdelingsregels gebruikt met Azure Load Balancer, moet u statustests opgeven zodat Load Balancer de status van het back-end-eindpunt kan detecteren. De configuratie van de statustest en de testreacties bepalen welke back-ende pool-exemplaren nieuwe stromen ontvangen. U kunt statustests gebruiken om het mislukken van een toepassing op een back-end-eindpunt te detecteren. U kunt ook een aangepast antwoord op een statustest genereren en de statustest voor stroombeheer gebruiken om de belasting of geplande downtime te beheren. Wanneer een statustest mislukt, Load Balancer geen nieuwe stromen meer verzenden naar het betreffende exemplaar met een slechte status. De uitgaande connectiviteit wordt niet beïnvloed, alleen de binnenkomende connectiviteit wordt beïnvloed.

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

Testconfiguratie

De configuratie van de statustest bestaat uit de volgende elementen:

• Duur van het interval tussen afzonderlijke tests
• Protocol van de test
• Poort van de test
• HTTP-pad dat moet worden gebruikt voor HTTP GET bij het gebruik van HTTP(S)-tests

Inzicht in het signaal van de toepassing, de detectie van het signaal en de reactie van het platform

De intervalwaarde bepaalt hoe vaak de statustest een reactie van uw back-endpool-exemplaren test. Als de statustest mislukt, worden de exemplaren van de back-endpool onmiddellijk als beschadigd markeren. Op dezelfde manier worden bij de volgende gezonde test de exemplaren van de back-uppool onmiddellijk opnieuw als in orde markeren.

We kunnen het gedrag verder illustreren met een voorbeeld, waarbij uw statustestinterval is ingesteld op 5 seconden. Omdat de tijd waarop een test wordt verzonden niet wordt gesynchroniseerd met wanneer uw toepassing de status kan wijzigen, kan de totale tijd die het kost om de status van uw toepassing weer te geven, in een van de volgende twee scenario's vallen:

1. Als uw toepassing een time-out testreactie produceert net voordat de volgende test binnenkomt, duurt de detectie van deze gebeurtenissen 5 seconden plus de duur van de toepassing die begint met het signaleren van een time-out naar wanneer de test aankomt. U kunt ervan uitgaan dat deze detectie iets langer duurt dan 5 seconden.
2. Als uw toepassing een time-out testreactie produceert net nadat de volgende test is aangekomen, wordt de detectie van deze gebeurtenissen pas gestart als de test binnenkomt (en er een time-out is) plus nog eens 5 seconden. U kunt ervan uitgaan dat deze detectie iets minder dan 10 seconden duurt.

Zodra de detectie is opgetreden, duurt het platform in dit voorbeeld even om op deze wijziging te reageren. Dit betekent dat afhankelijk van

1. wanneer de toepassing begint met het wijzigen van de status en
2. wanneer deze wijziging wordt gedetecteerd (wanneer de volgende statustest wordt verzonden) en
3. wanneer de detectie is gecommuniceerd op het platform

U kunt ervan uitgaan dat de reactie op een time-outtest tussen minimaal iets meer dan 5 seconden en een maximum van iets meer dan 10 seconden duurt om te reageren op een wijziging in het signaal van de toepassing. Dit voorbeeld wordt gegeven ter illustratie van wat er plaatsvindt, maar het is niet mogelijk om een exacte duur te voorspellen die hoger is dan de bovenstaande ruwe richtlijnen die in dit voorbeeld worden geïllustreerd.

Testtypen

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

• TCP-listeners
• HTTP-eindpunten
• HTTPS-eindpunten

De beschikbare protocollen zijn afhankelijk van de Load Balancer SKU die wordt gebruikt:

TCP-test

TCP-tests initiëren een verbinding door een open TCP-handshake in drie punten uit te voeren met de gedefinieerde poort. TCP-tests beëindigen een verbinding met een vier way close TCP-handshake.

Het minimale testinterval is 5 seconden en het minimale aantal slechte reacties is 2. De totale duur van alle intervallen mag niet langer zijn dan 120 seconden.

Een TCP-test mislukt wanneer:

• De TCP-listener op het exemplaar reageert helemaal niet tijdens de time-outperiode. Een test wordt gemarkeerd op basis van het aantal time-out testaanvragen, die zijn geconfigureerd om onbeantwoord te blijven voordat de test wordt gemarkeerd.
• De test ontvangt een TCP-reset van het exemplaar.

Hieronder ziet u hoe u dit soort testconfiguratie kunt uitdrukken in een Resource Manager sjabloon:

    {
      "name": "tcp",
      "properties": {
        "protocol": "Tcp",
        "port": 1234,
        "intervalInSeconds": 5,
        "numberOfProbes": 1
      },

HTTP-/HTTPS-test

HTTP- en HTTPS-tests bouwen voort op de TCP-test en geven een HTTP GET uit met het opgegeven pad. Beide tests ondersteunen relatieve paden voor de HTTP GET. HTTPS-tests zijn hetzelfde als HTTP-tests met de toevoeging van een Transport Layer Security-wrapper (TLS, voorheen bekend als SSL). De statustest wordt gemarkeerd wanneer het exemplaar binnen de time-outperiode reageert met de HTTP-status 200. De statustest probeert standaard elke 15 seconden de geconfigureerde statustestpoort te controleren. Het minimale testinterval is 5 seconden. De totale duur van alle intervallen mag niet langer zijn dan 120 seconden.

HTTP-/HTTPS-tests kunnen ook nuttig zijn om uw eigen logica te implementeren om exemplaren te verwijderen uit load balancer rotatie als de testpoort ook de listener voor de service zelf is. U kunt bijvoorbeeld besluiten om een instantie te verwijderen als deze hoger is dan 90% CPU en een niet-200 HTTP-status retournt.

Als u Cloud Services webrollen gebruikt die gebruikmaken van w3wp.exe, kunt u ook uw website automatisch controleren. Fouten in de websitecode retourneren een niet-200-status aan de load balancer test.

Een HTTP-/HTTPS-test mislukt wanneer:

• Test-eindpunt retourneert een andere HTTP-antwoordcode dan 200 (bijvoorbeeld 403, 404 of 500). Hiermee wordt de statustest onmiddellijk gemerkt.
• Test-eindpunt reageert helemaal niet tijdens het minimale testinterval en de 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.
• Het test-eindpunt sluit de verbinding via het opnieuw instellen van TCP.

Hieronder ziet u hoe u dit soort testconfiguratie kunt uitdrukken in een Resource Manager sjabloon:

    {
      "name": "http",
      "properties": {
        "protocol": "Http",
        "port": 80,
        "requestPath": "/",
        "intervalInSeconds": 5,
        "numberOfProbes": 1
      },

    {
      "name": "https",
      "properties": {
        "protocol": "Https",
        "port": 443,
        "requestPath": "/",
        "intervalInSeconds": 5,
        "numberOfProbes": 1
      },

Gedrag van de test

TCP-, HTTP- en HTTPS-statustests worden als in orde beschouwd en markeren het back-end-eindpunt als in orde wanneer:

• De statustest is eenmaal geslaagd nadat de VM is geboot.

Elk back-end-eindpunt dat een goede status heeft bereikt, komt in aanmerking voor het ontvangen van nieuwe stromen.

Gedrag van test omlaag

TCP-verbindingen

Nieuwe TCP-verbindingen slagen om het back-end-eindpunt in orde te houden.

Als de statustest van een back-end-eindpunt mislukt, worden TCP-verbindingen met dit back-end-eindpunt voortgezet.

Als alle tests voor alle exemplaren in een back-endpool mislukken, worden er geen nieuwe stromen verzonden naar de back-endpool. Standard Load Balancer worden ingesteld TCP-stromen om door te gaan. Basic Load Balancer beëindigt alle bestaande TCP-stromen naar de back-endpool.

Load Balancer is een pass through-service (beëindigt TCP-verbindingen niet) en de stroom loopt altijd tussen de client en het gast-besturingssysteem en de toepassing van de VM. Een pool met alle tests in de lucht zorgt ervoor dat een front-end niet reageert op open pogingen van de TCP-verbinding (SYN), omdat er geen goed back-end-eindpunt is om de stroom te ontvangen en te reageren met een SYN-ACK.

UDP-datagrammen

UDP-datagrammen worden geleverd aan goede back-end-eindpunten.

UDP is verbindingloos en er wordt geen stroomtoestand bijgespoord voor UDP. Als de statustest van een back-end-eindpunt mislukt, worden bestaande UDP-stromen verplaatst naar een andere gezonde instantie in de back-endpool.

Als alle tests voor alle exemplaren in een back-endpool mislukken, worden bestaande UDP-stromen beëindigd voor Basic- en Standard Load Balancers.

IP-adres van testbron

Load Balancer maakt gebruik van een gedistribueerde service voor het interne statusmodel. De testservice bevindt zich op elke host waar VM's zich bevinden en kan op aanvraag worden geprogrammeerd om statustests te genereren volgens de configuratie van de klant. Het statustestverkeer is rechtstreeks tussen de testservice die de statustest genereert en de klant-VM. Alle Load Balancer tests zijn afkomstig van het IP-adres 168.63.129.16 als bron. U kunt ip-adresruimte in een VNet gebruiken die geen RFC1918-ruimte is. Door gebruik te maken van een wereldwijd gereserveerd IP-adres dat eigendom is van Microsoft, is er minder kans op een conflict met een IP-adres met de IP-adresruimte die u in het VNet gebruikt. Dit IP-adres is hetzelfde in alle regio's en verandert niet en is geen beveiligingsrisico omdat alleen het interne Azure-platformonderdeel een pakket van dit IP-adres kan bron.

De servicetag AzureLoadBalancer identificeert dit bron-IP-adres in uw netwerkbeveiligingsgroepen en staat standaard statustestverkeer toe.

Naast het uitvoeren Load Balancer statustests, gebruiken de volgende bewerkingen dit IP-adres:

• Hiermee kan de VM-agent communiceren met het platform om aan te geven dat deze de status Gereed heeft
• Maakt communicatie met de virtuele DNS-server mogelijk om gefilterde naamresolutie te bieden aan klanten die geen aangepaste DNS-servers definiëren. Deze filtering zorgt ervoor dat klanten alleen de hostnamen van hun implementatie kunnen oplossen.
• Hiermee kan de VM een dynamisch IP-adres verkrijgen van de DHCP-service in Azure.

Ontwerpadviezen

Statustests worden gebruikt om uw service robuust te maken en te schalen. Een onjuiste configuratie of een onjuist ontwerppatroon kan van invloed zijn op de beschikbaarheid en schaalbaarheid van uw service. Bekijk dit hele document en bedenk wat de impact op uw scenario is wanneer dit testreactie wordt gemarkeerd of gemarkeerd, en hoe dit van invloed is op de beschikbaarheid van uw toepassingsscenario.

Wanneer u het statusmodel voor uw toepassing ontwerpt, moet u een poort op een back-end-eindpunt onderzoeken die de status van dat exemplaar en de toepassingsservice die u aan het leveren bent, weerspiegelt. De poort van de toepassing en de testpoort zijn niet hetzelfde. In sommige scenario's kan het wenselijk zijn dat de testpoort anders is dan de poort waar uw toepassing service aan levert.

Soms kan het handig zijn voor uw toepassing om een statustestreactie te genereren om niet alleen de status van uw toepassing te detecteren, maar ook om rechtstreeks naar Load Balancer te signaleren of uw exemplaar al dan niet nieuwe stromen moet ontvangen. U kunt het antwoord van de test bewerken zodat uw toepassing tegendruk kan creëren en de levering van nieuwe stromen aan een exemplaar kan onderdrukken door de statustest te laten mislukken of door het onderhoud van uw toepassing voor te bereiden en uw scenario leeg te maken. Wanneer u Standard Load Balancer, staat een signaal voor test down altijd toe dat TCP-stromen worden voortgezet totdat er een time-out voor inactief is of de verbinding wordt gesloten.

Voor UDP-taakverdeling moet u een aangepast statustestsignaal genereren vanaf het back-endeindpunt en een TCP-, HTTP- of HTTPS-statustest gebruiken die is gericht op de bijbehorende listener om de status van uw UDP-toepassing weer te geven.

Wanneer u ha-poorten taakverdelingsregels met Standard Load Balancergebruikt, worden alle poorten verdeeld en moet één statustestreactie de status van het hele exemplaar weergeven.

Vertaal of proxy geen statustest via het exemplaar dat de statustest ontvangt naar een ander exemplaar in uw VNet, omdat deze configuratie kan leiden tot opeenvatbare fouten in uw scenario. Neem het volgende scenario: er wordt een set apparaten van derden geïmplementeerd in de back-Load Balancer-groep van een Load Balancer-resource om schaal en redundantie voor de apparaten te bieden. De statustest wordt geconfigureerd om een poort te onderzoeken die het apparaat van derden gebruikt of wordt omgezet naar andere virtuele machines achter het apparaat. Als u dezelfde poort test die u gebruikt voor het vertalen van aanvragen of proxyaanvragen naar de andere virtuele machines achter het apparaat, wordt het apparaat door een testreactie van één virtuele machine achter het apparaat als in een impasse aangetroffen. Deze configuratie kan leiden tot een trapsgetalde fout in het hele toepassingsscenario als gevolg van één back-end-eindpunt achter het apparaat. De trigger kan een onregelmatige testfout zijn die ervoor zorgt dat Load Balancer de oorspronkelijke bestemming (het exemplaar van het apparaat) zal markeren en op zijn beurt uw hele toepassingsscenario kan uitschakelen. Test in plaats daarvan 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) en u moet de leverancier van uw toepassing raadplegen voor wat het juiste statussignaal is voor dergelijke scenario's.

Als u het bron-IP-adres van de test in uw firewallbeleid niet toestaat, mislukt de statustest omdat deze uw exemplaar niet kan bereiken. Op zijn beurt Load Balancer uw exemplaar markeren vanwege een fout in de statustest. Deze onjuiste configuratie kan ertoe leiden dat uw toepassingsscenario met load balanced mislukt.

Als Load Balancer uw exemplaar wilt markeren, moet u dit IP-adres toestaan in alle Azure-netwerkbeveiligingsgroepen en lokale firewallbeleidsregels. Standaard bevat elke netwerkbeveiligingsgroep de servicetag AzureLoadBalancer om statustestverkeer toe te staan.

Als u een statustestfout wilt testen of een afzonderlijk exemplaar wilt markeren, kunt u een netwerkbeveiligingsgroep gebruiken om de statustest (doelpoort of bron-IP)expliciet te blokkeren en het mislukken van een test te simuleren.

Configureer uw VNet niet met het IP-adresbereik van Microsoft dat 168.63.129.16 bevat. Dergelijke configuraties botsen met het IP-adres van de statustest en kunnen ertoe leiden dat uw scenario mislukt.

Als uw VM meerdere interfaces heeft, moet u zorgen dat u reageert op de test op de interface waarin u deze hebt ontvangen. Mogelijk moet u het bronnetwerkadres dit adres in de VM per interface vertalen.

Schakel TCP-tijdstempels niet in. Het inschakelen van TCP-tijdstempels kan ertoe leiden dat statustests mislukken omdat TCP-pakketten worden uitgevallen door de TCP-stack van het gast-besturingssysteem van de VM, wat resulteert in Load Balancer markering van het respectieve eindpunt. TCP-tijdstempels worden standaard regelmatig ingeschakeld op VM-afbeeldingen die zijn gehard voor beveiliging en moeten worden uitgeschakeld.

Bewaking

Zowel openbare als interne Standard Load Balancer statustests per eindpunt en back-end-eindpunt weergeven als multidimensionale metrische gegevens via Azure Monitor. Deze metrische gegevens kunnen worden gebruikt door andere Azure-services of partnertoepassingen.

Azure Monitor zijn niet beschikbaar voor openbare en interne Basic Load Balancers.

Beperkingen

• HTTPS-tests bieden geen ondersteuning voor wederzijdse verificatie met een clientcertificaat.
• Stel dat statustests mislukken wanneer TCP-tijdstempels zijn ingeschakeld.
• Een basis-SKU load balancer statustest wordt niet ondersteund met een virtuele-machineschaalset.

Volgende stappen

• Meer informatie over Standard Load Balancer
• Aan de slag met het maken van een load balancer in Resource Manager met behulp van PowerShell
• REST API voor statustests
• Nieuwe statustestmogelijkheden aanvragen met Load Balancer Uservoice van de gebruiker