Hälsokontroller för Azure Load Balancer

En Hälsoavsökning i Azure Load Balancer är en funktion som identifierar hälsostatusen för dina programinstanser. Den skickar en begäran till instanserna för att kontrollera om de är tillgängliga och svara på begäranden. Hälsoavsökningen kan konfigureras för att använda olika protokoll, till exempel TCP, HTTP eller HTTPS. Det är en viktig funktion eftersom den hjälper dig att identifiera programfel, hantera belastning och planera för driftstopp.

Azure Load Balancer-regler kräver en hälsoavsökning för att identifiera slutpunktsstatusen. Konfigurationen av hälsokontroll och kontrollsvar avgör vilka backendpoolinstanser som tar emot nya anslutningar. Använd hälsoövervakning för att upptäcka ett programs fel. Generera ett anpassat svar på en hälsoavsökning. Använd hälsoproben för flödeskontroll för att hantera belastning eller planerad stilleståndstid. När en hälsoavsökning misslyckas slutar lastbalanseraren att skicka nya anslutningar till respektive instans med feltillstånd. Utgående anslutning påverkas inte, bara inkommande.

Probeprotokoll

Hälsoprober stöder flera protokoll. Tillgängligheten för ett specifikt hälsoavsökningsprotokoll varierar beroende på lastbalanserarens SKU. Dessutom varierar tjänstens beteende beroende på Load Balancer SKU som visas i den här tabellen:

Proberingsegenskaper

Hälsoavsökningar har följande egenskaper:

Probkonfiguration

Konfiguration av hälsoavsökning består av följande element:

Undersökningsprotokoll

Det protokoll som används av hälsoavsökningen kan konfigureras till något av följande alternativ: TCP, HTTP, HTTPS.

Avsökningsbeteende

Avsökningsintervall och tidsgräns

Intervallvärdet avgör hur ofta hälso-sonden söker efter ett svar från dina backend pool-instanser. Om hälsoavsökningen misslyckas markeras dina serverdelspoolinstanser omedelbart som felaktiga. Om hälsoavsökningen lyckas vid nästa lyckade avsökning markerar Azure Load Balancer dina backend-poolinstanser som felfria. Hälsoavsökningen försöker kontrollera den konfigurerade hälsoavsökningsporten varje 5:e sekund som standard i Azure-portalen, men det kan uttryckligen ställas in på ett annat värde.

För att säkerställa att ett snabbt svar tas emot har HTTP/S-hälsoavsökningar inbyggda tidsgränser. Följande är tidsgränsvaraktigheterna för TCP- och HTTP/S-avsökningar:

• Tidsgräns för TCP-avsökning: N/A (avsökningar misslyckas när den konfigurerade varaktigheten för avsökningsintervallet har passerat och nästa avsökning skickas)
• Tidsgräns för HTTP/S-avsökning: 30 sekunder

För HTTP/S-avsökningar, om det konfigurerade intervallet är längre än tidsgränsen ovan, överskrider hälsoavsökningen tidsgränsen och misslyckas om inget svar tas emot under tidsgränsperioden. Om en HTTP-hälsoavsökning till exempel har konfigurerats med ett avsökningsintervall på 120 sekunder (var 2:e minut) och inget avsökningssvar tas emot inom de första 30 sekunderna når avsökningen sin tidsgräns och misslyckas. När det konfigurerade intervallet är kortare än tidsgränsen ovan misslyckas hälsoavsökningen om inget svar tas emot innan den konfigurerade intervallperioden har slutförts och nästa avsökning skickas omedelbart.

Tröskelvärde för avsökning

Tröskelvärdet för avsökningen är det antal gånger som en hälsoavsökning måste lyckas eller misslyckas i följd för att avsökningen ska markera en serverdelsinstans som felfri eller inte felfri.

För TCP-avsökningar måste avsökningen ta emot två svar i följd innan en serverdelsinstans börjar ta emot trafik om avsökningströskelvärdet är konfigurerat till 2. När en serverdelsinstans bedöms vara felfri krävs på samma sätt två efterföljande fel eller timeouter för att instansen ska betraktas som felaktig och sluta ta emot ny trafik.

För HTTP-avsökningar markerar explicita svar omedelbart avsökningen som upp eller ned för 200 och icke-200 svar och återställer tröskelvärdet effektivt. Det innebär att tröskelvärdet endast gäller för HTTP-avsökningar om avsökningen överskrider tidsgränsen på grund av inget svar.

Riktlinjer för design

• När du utformar hälsomodellen för ditt program avsöker du en port på en serverdelsslutpunkt som återspeglar hälsotillståndet för instansen och programtjänsten. Programporten och avsökningsporten behöver inte vara desamma. I vissa scenarier kan det vara önskvärt att avsökningsporten skiljer sig från den port som programmet använder, men i allmänhet rekommenderas att avsökningar använder samma port.

• Det kan vara användbart för din applikation att generera en hälsorespons och signalera till lastbalanseraren om din instans ska ta emot nya anslutningar. Du kan justera sondsvaret för att strypa leveransen av nya anslutningar till en instans genom att låta hälsoavsökningen misslyckas. Du kan förbereda för underhåll av ditt program och initiera tömning av anslutningar till ditt program. En nedskanningssignal gör alltid att TCP-flöden kan fortsätta tills inaktivitetens tidsgräns är nådd eller anslutningen stängs i en Standardlastbalanserare.

• För ett UDP-lastbalanserat program genererar du en anpassad hälsoavsökningssignal från serverdelsslutpunkten. Använd TCP, HTTP eller HTTPS för en hälsoprob som matchar motsvarande lyssnare.

• Lastbalanseringsregel för HA-portar med Standard Load Balancer. Alla portar är lastbalanserade och ett enda hälsoundersökningssvar måste återspegla statusen för hela instansen.

• Översätt inte eller vidarebefordra en hälsoavsökning från den instans som tar emot hälsoavsökningen till en annan instans i det virtuella nätverket. Den här konfigurationen kan leda till fel i ditt scenario. Till exempel: En uppsättning tredjepartsenheter distribueras i backend-poolen för en lastbalanserare för att tillhandahålla skala och redundans för enheterna. Hälsoavsökningen är konfigurerad för att avsöka en port som tredjepartsenheten använder som proxy eller översätter till andra virtuella datorer bakom enheten. Om du undersöker samma port som används för att översätta eller styra begäranden till de andra virtuella datorerna bakom enheten, leder varje svar på en avsökning från en enda virtuell dator till att enheten bedöms som otillgänglig. Den här konfigurationen kan leda till ett sammanhängande fel i programmet. Utlösaren kan vara ett tillfälligt probefel som får lastbalanseraren att märka ner applikationsinstansen. Den här åtgärden kan inaktivera ditt program. Avsöka själva installationens hälsa. Valet av sond för att fastställa hälsosignalen är ett viktigt övervägande för NVA-scenarier (network virtual appliances). Kontakta programleverantören för att få lämplig hälsosignal för sådana scenarier.

• Om du har flera gränssnitt konfigurerade på den virtuella datorn ska du se till att du svarar på avsökningen i det gränssnitt som du tog emot den på. Du kan behöva källnätverksadressen översätta den här adressen på den virtuella datorn per gränssnitt.

• En probe-definition är varken obligatorisk eller kontrolleras när du använder Azure PowerShell, Azure CLI, mallar eller API. Probvalideringstester görs endast när du använder Azure-portalen.

• Om hälsoövervakningen fluktuerar väntar lastbalanseraren längre innan den bakomliggande slutpunkten återgår till ett hälsosamt tillstånd. Den här extra väntetiden skyddar användaren och infrastrukturen och är en avsiktlig princip.

• Kontrollera att dina virtuella datorinstanser körs. För varje instans som körs i backend-poolen kontrollerar hälsokontrollen tillgänglighet. Om en instans stoppas avsöks den inte förrän den har startats igen.

• Konfigurera inte ditt virtuella nätverk med det Microsoft-ägda IP-adressintervallet som innehåller 168.63.129.16. Konfigurationen kolliderar med IP-adressen för hälsoavsökningen och kan leda till att scenariot misslyckas.

• Om du vill testa ett fel i hälsoavsökningen eller notera en enskild instans använder du en nätverkssäkerhetsgrupp för att uttryckligen blockera hälsoavsökningen. Skapa en NSG-regel för att blockera målporten eller käll-IP-adressen för att simulera ett sondfel.

• Till skillnad från belastningsutjämningsregler behöver inkommande NAT-regler inte någon hälsokontroll som är kopplad till dem.

• Det rekommenderas inte att blockera IP-adressen eller porten för Azure Load Balancer-hälsokontroll med NSG-regler. Detta är en situation som inte stöds och kan leda till att NSG-reglerna får fördröjd effekt, vilket resulterar i att hälsokontrollerna felaktigt visar tillgängligheten för dina bakgrundsinstanser.

Övervakning

Standard Load Balancer exponerar hälsoprobsstatus per slutpunkt och bakgrundsslutpunkt via Azure Monitor. Andra Azure-tjänster eller partnerprogram kan använda dessa mått. Azure Monitor-loggar stöds inte för Basic Load Balancer.

IP-adress för probkälla

För att Azure Load Balancers hälsoavsökning ska kunna markera din instans måste du tillåta IP-adressen 168.63.129.16 i alla Azure-nätverkssäkerhetsgrupper och lokala brandväggsprinciper. Tjänsttaggen AzureLoadBalancer identifierar den här käll-IP-adressen i dina nätverkssäkerhetsgrupper och tillåter hälsoavsökningstrafik som standard. Du kan läsa mer om denna IP-adressen här.

Om du inte tillåter käll-IP-adressen för avsökningen i brandväggsprinciperna misslyckas hälsoavsökningen eftersom den inte kan nå din instans. Azure Load Balancer markerar i sin tur din instans som –down – på grund av hälsoavsökningsfelet. Den här felkonfigurationen kan göra att ditt belastningsbalanserade programscenario misslyckas. Alla hälsoavsökningar från IPv4 Load Balancer har IP-adressen 168.63.129.16 som ursprung. IPv6-avsökningar använder en länklokal adress (fe80::1234:5678:9abc) som källadress. För en Azure Load Balancer med dubbla staplar måste du konfigurera en nätverkssäkerhetsgrupp för att IPv6-hälsoavsökningen ska fungera.

Begränsningar

• HTTPS-avsökningar stöder inte ömsesidig autentisering med ett klientcertifikat.

• HTTP-avsökningar stöder inte användning av värdnamn för bakändar för avsökningar.

• Aktivering av TCP-tidsstämplar kan orsaka begränsning eller andra prestandaproblem, vilket sedan kan leda till att hälsoavsökningar överskrider tidsgränsen.

• En hälsoavsökning för en Basic SKU-lastbalanserare stöds inte med en uppsättning av virtuella maskiner i skala.

• HTTP-avsökningar stöder inte avsökning på följande portar på grund av säkerhetsproblem: 19, 21, 25, 70, 110, 119, 143, 220, 993.

Nästa steg

• Mer information finns i Standard Load Balancer
• Lär dig hur du hanterar hälsoundersökningar
• Kom igång att skapa en offentlig lastbalanserare i Resource Manager med hjälp av PowerShell
• REST API för hälsokontroller