Översikt över Hälsoavsökningar för Application Gateway

Azure Application Gateway övervakar hälsotillståndet för alla servrar i serverdelspoolen och slutar automatiskt att skicka trafik till alla servrar som den anser vara felfria. Avsökningarna fortsätter att övervaka en sådan felaktig server och gatewayen börjar dirigera trafiken till den igen så snart avsökningarna identifierar den som felfri.

Standardavsökningen använder portnumret från den associerade serverdelsinställningen och andra förinställda konfigurationer. Du kan använda anpassade avsökningar för att konfigurera dem på ditt sätt.

Beteende för avsökningar

Källans IP-adress

Käll-IP-adressen för avsökningarna beror på serverdelsservertypen:

• Om servern i serverdelspoolen är en offentlig slutpunkt blir källadressen programgatewayens offentliga IP-adress för klientdelen.
• Om servern i serverdelspoolen är en privat slutpunkt kommer käll-IP-adressen att komma från programgatewayens adressutrymme.

Avsökningsåtgärder

En gateway börjar starta avsökningar omedelbart efter att du har konfigurerat en regel genom att associera den med en serverdelsinställning och serverdelspool (och lyssnaren, naturligtvis). Bilden visar att gatewayen oberoende avsöker alla serverdelspoolservrar. Inkommande begäranden som börjar anlända skickas endast till de felfria servrarna. En serverdelsserver markeras som felaktig som standard tills ett lyckat avsökningssvar tas emot.

De nödvändiga avsökningarna bestäms baserat på den unika kombinationen av serverdelsservern och serverdelsinställningen. Tänk dig till exempel en gateway med en enda serverdelspool med två servrar och två serverdelsinställningar, där var och en har olika portnummer. När dessa distinkta serverdelsinställningar associeras med samma serverdelspool med hjälp av respektive regler skapar gatewayen avsökningar för varje server och kombinationen av serverdelsinställningen. Du kan visa detta på sidan Serverdelshälsa.

Dessutom avsöker alla instanser av programgatewayen serverdelsservrarna oberoende av varandra.

Avsökningsintervall

Samma avsökningskonfiguration gäller för varje instans av din Application Gateway. Om en programgateway till exempel har två instanser och avsökningsintervallet är inställt på 20 sekunder, skickar båda instanserna hälsoavsökningen var 20:e sekund.

När avsökningen identifierar ett misslyckat svar, avsätts räknaren för tröskelvärdet "Ej felfri" och markerar servern som felaktig om det på varandra följande misslyckade antalet matchar det konfigurerade tröskelvärdet. Om du anger det här tröskelvärdet för fel som 2 identifierar den efterföljande avsökningen det här felet. Programgatewayen markerar sedan servern som felfri efter två misslyckade avsökningar i följd [Första identifieringen 20 sekunder + (2 misslyckade avsökningar i följd * 20 sekunder)].

Kommentar

Hälsorapporten för serverdelen uppdateras baserat på respektive avsökningsintervall och är inte beroende av användarens begäran.

Standardhälsoavsökning

En programgateway konfigurerar automatiskt en standardhälsoavsökning när du inte konfigurerar någon anpassad avsökningskonfiguration. Övervakningsbeteendet fungerar genom att göra en HTTP GET-begäran till IP-adresser eller FQDN som konfigurerats i serverdelspoolen. För standardavsökningar om http-inställningarna för serverdelen har konfigurerats för HTTPS använder avsökningen HTTPS för att testa serverdelsservrarnas hälsotillstånd.

Till exempel: Du konfigurerar programgatewayen så att den använder serverdelsservrarna A, B och C för att ta emot HTTP-nätverkstrafik på port 80. Standardhälsoövervakningen testar de tre servrarna var 30:e sekund för ett felfritt HTTP-svar med en tidsgräns på 30 sekunder för varje begäran. Ett felfritt HTTP-svar har en statuskod mellan 200 och 399. I det här fallet ser HTTP GET-begäran för hälsoavsökningen ut som http://127.0.0.1/. Se även HTTP-svarskoder i Application Gateway.

Om standardavsökningskontrollen misslyckas för server A slutar programgatewayen att vidarebefordra begäranden till den här servern. Standardavsökningen fortsätter fortfarande att söka efter server A var 30:e sekund. När server A svarar på en begäran från en standardhälsoavsökning börjar programgatewayen vidarebefordra begäranden till servern igen.

Standardinställningar för hälsoavsökning

Avsökningsegenskap	Värde	Description
Avsöknings-URL	<protocol>://127.0.0.1:<port>/	Protokollet och porten ärvs från http-inställningarna för serverdelen som avsökningen är associerad med
Intervall	30	Hur lång tid i sekunder som ska vänta innan nästa hälsoavsökning skickas.
Timeout	30	Hur lång tid i sekunder programgatewayen väntar på ett avsökningssvar innan avsökningen markeras som felaktig. Om en avsökning returneras som felfri markeras motsvarande serverdel omedelbart som felfri.
Defekt tröskelvärde	3	Styr hur många avsökningar som ska skickas om den vanliga hälsoavsökningen misslyckas. I v1 SKU skickas dessa ytterligare hälsoavsökningar i snabb följd för att snabbt fastställa hälsotillståndet för serverdelen och vänta inte på avsökningsintervallet. För v2 SKU väntar hälsoavsökningarna i intervallet. Serverdelsservern markeras nedåt efter att antalet på varandra följande avsökningsfel når tröskelvärdet för fel som inte är felfri.

Standardavsökningen tittar bara på <protocol>://127.0.0.1:<port> för att fastställa hälsostatus. Om du behöver konfigurera hälsoavsökningen så att den går till en anpassad URL eller ändrar andra inställningar måste du använda anpassade avsökningar. Mer information om HTTPS-avsökningar finns i Översikt över TLS-avslutning och TLS från slutpunkt till slutpunkt med Application Gateway.

Anpassad hälsoavsökning

Med anpassade avsökningar kan du ha mer detaljerad kontroll över hälsoövervakningen. När du använder anpassade avsökningar kan du konfigurera ett anpassat värdnamn, URL-sökväg, avsökningsintervall och hur många misslyckade svar som ska accepteras innan du markerar serverdelspoolinstansen som felaktig osv.

Inställningar för anpassad hälsoavsökning

Följande tabell innehåller definitioner för egenskaperna för en anpassad hälsoavsökning.

Avsökningsegenskap	Beskrivning
Namn	Avsökningens namn. Det här namnet används för att identifiera och referera till avsökningen i HTTP-inställningarna för serverdelen.
Protokoll	Protokoll som används för att skicka avsökningen. Detta måste matcha med det protokoll som definierats i http-inställningarna för serverdelen som det är associerat med
Host	Värdnamn som avsökningen ska skickas med. I v1 SKU används det här värdet endast för värdhuvudet för avsökningsbegäran. I v2 SKU används den både som värdhuvud och SNI
Sökväg	Avsökningens relativa sökväg. En giltig sökväg börjar med "/"
Port	Om det definieras används detta som målport. Annars använder den samma port som DE HTTP-inställningar som den är associerad med. Den här egenskapen är endast tillgänglig i V2 SKU:n
Intervall	Avsökningsintervall i sekunder. Det här värdet är tidsintervallet mellan två på varandra följande avsökningar
Timeout	Tidsgräns för avsökning i sekunder. Om ett giltigt svar inte tas emot inom den här tidsgränsen markeras avsökningen som misslyckad
Defekt tröskelvärde	Antal återförsök av avsökning. Serverdelsservern markeras som nedmarkerad efter att antalet på varandra följande avsökningsfel når tröskelvärdet för fel som inte är felfri

Matchning av avsökning

Som standard anses ett HTTP(S)-svar med statuskod mellan 200 och 399 vara felfritt. Anpassade hälsoavsökningar stöder dessutom två matchande villkor. Matchande kriterier kan användas för att ändra standardtolkningen av vad som gör ett felfritt svar.

Följande är matchande kriterier:

• HTTP-svarsstatuskodmatchning – Matchningsvillkor för avsökning för att acceptera angiven http-svarskod eller svarskodintervall. Enskilda kommaavgränsade svarsstatuskoder eller ett intervall med statuskod stöds.
• HTTP-svarstextmatchning – Matchningsvillkor för avsökning som tittar på HTTP-svarstexten och matchar med en angiven sträng. Matchningen söker bara efter närvaro av användar angiven sträng i svarstexten och är inte en fullständig reguljär uttrycksmatchning. Den angivna matchningen måste vara högst 4 090 tecken.

Matchningsvillkor kan anges med hjälp av cmdleten New-AzApplicationGatewayProbeHealthResponseMatch .

Till exempel:

$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399
$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"

Matchningsvillkor kan kopplas till avsökningskonfigurationen med hjälp av en -Match operator i PowerShell.

Vissa användningsfall för anpassade avsökningar

• Om en serverdelsserver endast tillåter åtkomst till autentiserade användare får application gateway-avsökningarna en 403-svarskod i stället för 200. Eftersom klienterna (användarna) är bundna att autentisera sig själva för livetrafiken kan du konfigurera avsökningstrafiken så att den accepterar 403 som ett förväntat svar.
• När en serverdelsserver har ett jokerteckencertifikat (*.contoso.com) installerat för att hantera olika underdomäner kan du använda en anpassad avsökning med ett specifikt värdnamn (krävs för SNI) som godkänns för att upprätta en lyckad TLS-avsökning och rapportera servern som felfri. Med "åsidosätt värdnamn" i serverdelsinställningen inställd på NEJ skickas de olika inkommande värdnamnen (underdomänerna) som till serverdelen.

NSG-överväganden

Detaljerad kontroll över Application Gateway-undernätet via NSG-regler är möjlig i offentlig förhandsversion. Mer information finns här.

Med aktuella funktioner finns det vissa begränsningar:

Du måste tillåta inkommande Internettrafik på TCP-portarna 65503-65534 för Application Gateway v1 SKU och TCP-portarna 65200-65535 för V2 SKU:n med målundernätet som Alla och källa som GatewayManager-tjänsttagg . Det här portintervallet krävs för Azure-infrastrukturkommunikation.

Dessutom kan utgående Internetanslutning inte blockeras och inkommande trafik som kommer från Taggen AzureLoadBalancer måste tillåtas.

Mer information finns i Översikt över Application Gateway-konfiguration.

Nästa steg

När du har lärt dig mer om hälsoövervakning av Application Gateway kan du konfigurera en anpassad hälsoavsökning i Azure-portalen eller en anpassad hälsoavsökning med hjälp av PowerShell och Azure Resource Manager-distributionsmodellen.