Application Gateway statuscontrole
Azure Application Gateway bewaakt standaard de status van alle resources in de back-endpool en verwijdert automatisch alle resources die als niet in orde worden beschouwd. Application Gateway blijft de exemplaren met slechte status bewaken en voegt deze weer aan de goede back-end-adrespool toe zodra ze beschikbaar komen en beantwoorden aan de statuscontroles. Standaard verzendt Application Gateway de statustests met dezelfde poort die is gedefinieerd in de BACK-end-HTTP-instellingen. Een aangepaste testpoort kan worden geconfigureerd met behulp van een aangepaste statustest.
Het BRON-IP-adres Application Gateway gebruikt voor statustests, is afhankelijk van de back-endpool:
- Als het serveradres in de back-endpool een openbaar eindpunt is, is het bronadres het openbare IP-adres van de toepassingsgateway.
- Als het serveradres in de back-endpool een privé-eindpunt is, is het bron-IP-adres afkomstig van de privé-IP-adresruimte van het subnet van de toepassingsgateway.
Naast het gebruik van standaardcontrole van de statustest kunt u de statustest ook aanpassen aan de vereisten van uw toepassing. In dit artikel worden zowel standaardtests als aangepaste statustests behandeld.
Notitie
In dit artikel wordt de Azure Az PowerShell-module gebruikt. Dit is de aanbevolen PowerShell-module voor interactie met Azure. Raadpleeg Azure PowerShell installeren om aan de slag te gaan met de Az PowerShell-module. Raadpleeg Azure PowerShell migreren van AzureRM naar Az om te leren hoe u naar de Azure PowerShell-module migreert.
Standaard statustest
Een toepassingsgateway configureert automatisch een standaard statustest wanneer u geen aangepaste testconfiguratie in stelt. Het bewakingsgedrag werkt door een HTTP GET-aanvraag te maken voor de IP-adressen of FQDN die in de back-endpool zijn geconfigureerd. Voor standaardtests als de HTTP-instellingen voor de back-ende back-ende 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 standaard statuscontrole test de drie servers elke 30 seconden op een goed HTTP-antwoord met een time-out van 30 seconden voor elke aanvraag. Een goed http-antwoord heeft een statuscode tussen 200 en 399. In dit geval ziet de HTTP GET-aanvraag voor de statustest eruit als http://127.0.0.1/ .
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 op één aanvraag van een standaard statustest reageert, begint Application Gateway de aanvragen opnieuw door te sturen naar de server.
Standaardinstellingen voor statustest
| Test-eigenschap | Waarde | Beschrijving |
|---|---|---|
| Test-URL | <protocol>://127.0.0.1:<port>/ | Het protocol en de poort worden overgenomen van de HTTP-instellingen van de back-end 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 dat de toepassingsgateway wacht op een testreactie voordat de test als niet in orde wordt markeert. Als een test retourneert als in orde, wordt de bijbehorende back-end onmiddellijk gemarkeerd als in orde. |
| Drempelwaarde voor beschadigde status | 3 | Bepaalt hoeveel tests er moeten worden verzenden als er een storing in de normale statustest is. 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. In het geval van v2 SKU wachten de statustests op het interval. De back-endserver wordt omlaag gemarkeerd nadat het aantal mislukte tests de drempelwaarde voor onjuiste status heeft bereikt. |
De standaardtest kijkt alleen naar <protocol> : / /127.0.0.1: om <port> de status te bepalen. Als u de statustest moet 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-TLSmet Application Gateway voor meer informatie over HTTPS-tests.
Testintervallen
Alle exemplaren van Application Gateway de back-end onafhankelijk van elkaar te onderzoeken. Dezelfde testconfiguratie is van toepassing op elk Application Gateway exemplaar. Als de testconfiguratie bijvoorbeeld is om elke 30 seconden statustests te verzenden en de toepassingsgateway twee exemplaren heeft, verzenden beide exemplaren de statustest om de 30 seconden.
Ook als er meerdere listeners zijn, test elke listener de back-end onafhankelijk van elkaar. Als er bijvoorbeeld twee listeners zijn die naar dezelfde back-endpool op twee verschillende poorten wijzen (geconfigureerd door twee http-instellingen voor back-enden), test elke listener dezelfde back-end onafhankelijk. In dit geval zijn er twee tests van elk toepassingsgateway-exemplaar voor de twee listeners. Als er in dit scenario twee exemplaren van de toepassingsgateway zijn, ziet de virtuele back-machine vier tests per geconfigureerd testinterval.
Aangepaste statustest
Met aangepaste tests kunt u de statuscontrole gedetailleerder controleren. Wanneer u aangepaste tests gebruikt, kunt u een aangepaste hostnaam, URL-pad, testinterval en het aantal mislukte reacties configureren dat moet worden geaccepteerd voordat het exemplaar van de back-endpool als niet in orde wordt weergegeven, enzovoort.
Aangepaste statustestinstellingen
De volgende tabel bevat definities voor de eigenschappen van een aangepaste statustest.
| Test-eigenschap | Beschrijving |
|---|---|
| Name | Naam van de test. Deze naam wordt gebruikt om de test te identificeren en te verwijzen in back-end-HTTP-instellingen. |
| Protocol | Protocol dat wordt gebruikt om de test te verzenden. Dit moet overeenkomen met het protocol dat is gedefinieerd in de BACK-end-HTTP-instellingen waar het aan is gekoppeld |
| Host | Hostnaam om de test mee te verzenden. In v1 SKU wordt deze waarde alleen gebruikt voor de hostheader van de testaanvraag. In v2 SKU wordt deze zowel als hostheader als SNI gebruikt |
| 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 waar deze aan 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 | Test time-out in seconden. Als er binnen deze time-outperiode geen geldig antwoord is ontvangen, wordt de test gemarkeerd als mislukt |
| Drempelwaarde voor beschadigde status | Aantal nieuwe tests. De back-endserver wordt omlaag gemarkeerd nadat het aantal mislukte tests de drempelwaarde voor onjuiste status heeft bereikt |
Overeenkomende tests
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 optioneel de standaardinterpretatie te wijzigen van wat een goed antwoord maakt.
Hieronder volgen overeenkomende criteria:
- Overeenkomende HTTP-antwoordstatuscode: testcriteria voor het accepteren van door de gebruiker opgegeven HTTP-antwoordcode of antwoordcodebereiken. Afzonderlijke door komma's gescheiden antwoordstatuscodes of een reeks statuscodes worden ondersteund.
- HTTP-antwoord body match- Test matching criterion that looks at HTTP response body and matches with a user specified string. De overeenkomst zoekt alleen naar aanwezigheid van een door de gebruiker opgegeven tekenreeks in de antwoord body en is geen volledige reguliere expressiematch.
Criteria voor overeenkomst kunnen worden opgegeven met behulp van New-AzApplicationGatewayProbeHealthResponseMatch de cmdlet .
Bijvoorbeeld:
$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399
$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"
Zodra de overeenkomstcriteria zijn opgegeven, kan deze worden gekoppeld aan de testconfiguratie met behulp van een -Match parameter in PowerShell.
NSG-overwegingen
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 any en bron als GatewayManager-servicetag. Dit poortbereik is vereist voor communicatie met de Azure-infrastructuur.
Daarnaast kan uitgaande internetverbinding niet worden geblokkeerd en moet het inkomende verkeer dat afkomstig is van de AzureLoadBalancer-tag worden toegestaan.
Zie Overzicht van Application Gateway-configuratie voor meer informatie.
Volgende stappen
Nadat u meer Application Gateway statuscontrole hebt geleerd, kunt u een aangepaste statustest configureren in de Azure Portal of een aangepaste statustest met behulp van PowerShell en het Azure Resource Manager-implementatiemodel.