Overzicht van statustests van Application Gateway
Azure-toepassing Gateway controleert de status van alle servers in de back-endpool en stopt het automatisch verzenden van verkeer naar elke server die als beschadigd wordt beschouwd. De tests blijven een dergelijke beschadigde server bewaken en de gateway begint het verkeer opnieuw naar de gateway te routeren zodra de tests deze als in orde detecteren.
De standaardtest maakt gebruik van het poortnummer van de bijbehorende back-endinstelling en andere vooraf ingestelde configuraties. U kunt aangepaste tests gebruiken om ze op uw manier te configureren.
Gedrag van tests
IP-adres van bron
Het bron-IP-adres van de tests is afhankelijk van het type back-endserver:
- Als de server in de back-endpool een openbaar eindpunt is, is het bronadres het openbare IP-adres van uw toepassingsgateway.
- Als de server in de back-endpool een privé-eindpunt is, komt het bron-IP-adres uit de adresruimte van uw toepassingsgatewaysubnet.
Testbewerkingen
Een gateway start tests onmiddellijk nadat u een regel hebt geconfigureerd door deze te koppelen aan een back-endinstelling en back-endpool (en natuurlijk de listener). In de afbeelding ziet u dat de gateway onafhankelijk alle back-endpoolservers test. De binnenkomende aanvragen die binnenkomen, worden alleen verzonden naar de servers die in orde zijn. Een back-endserver is standaard gemarkeerd als beschadigd totdat een geslaagde testreactie is ontvangen.
De vereiste tests worden bepaald op basis van de unieke combinatie van de back-endserver en back-endinstelling. Denk bijvoorbeeld aan een gateway met één back-endpool met twee servers en twee back-endinstellingen, elk met verschillende poortnummers. Wanneer deze afzonderlijke back-endinstellingen zijn gekoppeld aan dezelfde back-endpool met behulp van hun respectieve regels, maakt de gateway tests voor elke server en de combinatie van de back-endinstelling. U kunt dit bekijken op de pagina Back-endstatus.
Bovendien test alle exemplaren van de toepassingsgateway de back-endservers onafhankelijk van elkaar.
Testintervallen
Dezelfde testconfiguratie is van toepassing op elk exemplaar van uw Application Gateway. Als een toepassingsgateway bijvoorbeeld twee exemplaren heeft en het testinterval is ingesteld op 20 seconden, verzenden beide exemplaren de statustest om de 20 seconden.
Zodra de test een mislukt antwoord detecteert, wordt de prestatiemeteritem voor 'Drempelwaarde niet in orde' ingesteld en wordt de server gemarkeerd als beschadigd als het aantal opeenvolgende mislukte pogingen overeenkomt met de geconfigureerde drempelwaarde. Als u deze drempelwaarde voor beschadigde status als 2 instelt, detecteert de volgende test eerst deze fout. De toepassingsgateway markeert de server vervolgens als beschadigd na 2 opeenvolgende mislukte tests [Eerste detectie 20 sec + (2 opeenvolgende mislukte tests * 20 sec)].
Notitie
Het back-endstatusrapport wordt bijgewerkt op basis van het vernieuwingsinterval van de desbetreffende test en is niet afhankelijk van de aanvraag van de gebruiker.
Standaardstatustest
Een toepassingsgateway configureert automatisch een standaardstatustest wanneer u geen aangepaste testconfiguratie instelt. Het bewakingsgedrag werkt door een HTTP GET-aanvraag te verzenden naar de IP-adressen of FQDN die zijn geconfigureerd in de back-endpool. Voor standaardtests als de http-instellingen van de back-end zijn geconfigureerd voor HTTPS, gebruikt de test HTTPS om de status van de back-endservers te testen.
Bijvoorbeeld: U configureert uw toepassingsgateway voor het gebruik van back-endservers A, B en C voor het ontvangen van HTTP-netwerkverkeer op poort 80. De standaardstatuscontrole test de drie servers elke 30 seconden voor een goed functionerend HTTP-antwoord met een time-out van 30 seconden voor elke aanvraag. Een in orde HTTP-antwoord heeft een statuscode tussen 200 en 399. In dit geval ziet de HTTP GET-aanvraag voor de statustest er als volgt http://127.0.0.1/uit. Zie ook HTTP-antwoordcodes in Application Gateway.
Als de standaardtestcontrole mislukt voor server A, stopt de toepassingsgateway met het doorsturen van aanvragen naar deze server. De standaardtest blijft elke 30 seconden controleren op server A. Wanneer server A met succes reageert op één aanvraag vanaf een standaardstatustest, wordt de aanvragen opnieuw door de toepassingsgateway doorgestuurd naar de server.
Standaardinstellingen voor statustest
| Testeigenschap | Waarde | Omschrijving |
|---|---|---|
| Test-URL | <protocol>://127.0.0.1:<port>/ | Het protocol en de poort worden overgenomen van de back-end-HTTP-instellingen waaraan de test is gekoppeld |
| Interval | 30 | De hoeveelheid tijd in seconden die moet worden gewacht voordat de volgende statustest wordt verzonden. |
| Time-out | 30 | De hoeveelheid tijd in seconden wacht de toepassingsgateway op een testantwoord voordat de test als beschadigd wordt gemarkeerd. Als een test als in orde retourneert, wordt de bijbehorende back-end onmiddellijk gemarkeerd als in orde. |
| Drempelwaarde voor beschadigde status | 3 | Bepaalt hoeveel tests moeten worden verzonden voor het geval er een fout opgetreden is in de reguliere statustest. In v1 SKU worden deze aanvullende statustests snel achter elkaar verzonden om de status van de back-end snel te bepalen en niet te wachten op het testinterval. Voor v2-SKU wachten de statustests op het interval. De back-endserver wordt gemarkeerd nadat het aantal opeenvolgende testfouten de drempelwaarde voor beschadigde status heeft bereikt. |
De standaardtest kijkt alleen naar <protocol>://127.0.0.1:<poort> om de status te bepalen. Als u de statustest wilt configureren om naar een aangepaste URL te gaan of andere instellingen te wijzigen, moet u aangepaste tests gebruiken. Zie Overzicht van TLS-beëindiging en end-to-end TLS met Application Gateway voor meer informatie over HTTPS-tests.
Aangepaste statustest
Met aangepaste tests kunt u gedetailleerdere controle over de statuscontrole hebben. Wanneer u aangepaste tests gebruikt, kunt u een aangepaste hostnaam, URL-pad, testinterval en hoeveel mislukte antwoorden moeten worden geaccepteerd voordat u het exemplaar van de back-endpool markeert als beschadigd, enzovoort.
Aangepaste statustestinstellingen
De volgende tabel bevat definities voor de eigenschappen van een aangepaste statustest.
| Testeigenschap | Beschrijving |
|---|---|
| Naam | Naam van de test. Deze naam wordt gebruikt om de test te identificeren en te raadplegen in de HTTP-instellingen van de back-end. |
| Protocol | Protocol dat wordt gebruikt om de test te verzenden. Dit moet overeenkomen met het protocol dat is gedefinieerd in de HTTP-instellingen voor de back-end waaraan het is gekoppeld |
| Host | Hostnaam waarmee de test moet worden verzonden. In v1 SKU wordt deze waarde alleen gebruikt voor de hostheader van de testaanvraag. In v2 SKU wordt deze gebruikt als hostheader en SNI |
| Pad | Relatief pad van de test. Een geldig pad begint met '/' |
| Poort | Indien gedefinieerd, wordt dit gebruikt als de doelpoort. Anders wordt dezelfde poort gebruikt als de HTTP-instellingen waaraan deze is gekoppeld. Deze eigenschap is alleen beschikbaar in de v2-SKU |
| Interval | Testinterval in seconden. Deze waarde is het tijdsinterval tussen twee opeenvolgende tests |
| Time-out | Time-out van de test in seconden. Als er binnen deze time-outperiode geen geldig antwoord wordt ontvangen, wordt de test gemarkeerd als mislukt |
| Drempelwaarde voor beschadigde status | Aantal nieuwe pogingen voor de test. De back-endserver wordt gemarkeerd nadat het aantal opeenvolgende mislukte tests de drempelwaarde voor beschadigde status heeft bereikt |
Testkoppeling
Standaard wordt een HTTP(S)-antwoord met statuscode tussen 200 en 399 als in orde beschouwd. Aangepaste statustests ondersteunen bovendien twee overeenkomende criteria. Overeenkomende criteria kunnen worden gebruikt om desgewenst de standaardinterpretatie te wijzigen van wat een gezonde reactie maakt.
Hier volgen overeenkomende criteria:
- Overeenkomst met HTTP-antwoordstatuscode: testkoppelingscriterium voor het accepteren van door de gebruiker opgegeven HTTP-antwoordcode of antwoordcodebereiken. Afzonderlijke door komma's gescheiden antwoordstatuscodes of een bereik van statuscode wordt ondersteund.
- Overeenkomst met HTTP-antwoordtekst : testkoppelingscriterium waarmee wordt gekeken naar de hoofdtekst van het HTTP-antwoord en overeenkomsten met een door de gebruiker opgegeven tekenreeks. De overeenkomst zoekt alleen naar aanwezigheid van de door de gebruiker opgegeven tekenreeks in antwoordtekst en is geen volledige overeenkomst met reguliere expressies. De opgegeven overeenkomst moet 4090 tekens of minder zijn.
Criteria voor overeenkomst kunnen worden opgegeven met behulp van de New-AzApplicationGatewayProbeHealthResponseMatch cmdlet.
Bijvoorbeeld:
$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399
$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"
Criteria kunnen worden gekoppeld aan de testconfiguratie met behulp van een -Match operator in PowerShell.
Enkele gebruiksvoorbeelden voor aangepaste tests
- Als een back-endserver alleen geverifieerde gebruikers toestaat, ontvangen de toepassingsgatewaytests een 403-antwoordcode in plaats van 200. Aangezien de clients (gebruikers) zich moeten verifiëren voor het liveverkeer, kunt u het testverkeer zo configureren dat 403 wordt geaccepteerd als verwacht antwoord.
- Wanneer op een back-endserver een jokertekencertificaat (*.contoso.com) is geïnstalleerd voor verschillende subdomeinen, kunt u een aangepaste test gebruiken met een specifieke hostnaam (vereist voor SNI) die wordt geaccepteerd om een geslaagde TLS-test tot stand te brengen en die server als in orde te rapporteren. Als 'hostnaam overschrijven' in de back-endinstelling is ingesteld op NEE, worden de verschillende binnenkomende hostnamen (subdomeinen) doorgegeven aan de back-end.
Overwegingen voor NSG
Fijnmazige controle over het Application Gateway-subnet via NSG-regels is mogelijk in openbare preview. Hier vindt u meer informatie.
Met de huidige functionaliteit gelden enkele beperkingen:
U moet binnenkomend internetverkeer toestaan op TCP-poorten 65503-65534 voor de Application Gateway v1 SKU en TCP-poorten 65200-65535 voor de v2-SKU met het doelsubnet als Any en source als GatewayManager-servicetag . Dit poortbereik is nodig voor communicatie met de Azure-infrastructuur.
Bovendien kan de uitgaande internetverbinding niet worden geblokkeerd en moet binnenkomend verkeer dat afkomstig is van de AzureLoadBalancer-tag zijn toegestaan.
Zie Overzicht van Application Gateway-configuratie voor meer informatie.
Volgende stappen
Nadat u meer hebt geleerd over de statuscontrole van Application Gateway, kunt u een aangepaste statustest configureren in Azure Portal of een aangepaste statustest met behulp van PowerShell en het Azure Resource Manager-implementatiemodel.