Azure Load Balancer hälsoavsökningar

Azure Load Balancer regler kräver en hälsoavsökning för att identifiera slutpunktsstatusen. Konfigurationen av hälsoavsöknings- och avsökningssvaren avgör vilka serverdelspoolinstanser som ska ta emot nya anslutningar. Använd hälsoavsökningar för att identifiera ett programs fel. Generera ett anpassat svar på en hälsoavsökning. Använd hälsoavsökningen för flödeskontroll för att hantera belastning eller planerat driftstopp. 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, endast inkommande.

Hälsoavsökningar stöder flera protokoll. Tillgängligheten för ett specifikt hälsoavsökningsprotokoll varierar beroende på Load Balancer SKU. Dessutom varierar beteendet för tjänsten efter Load Balancer SKU enligt den här tabellen:

Standard-SKU Grundläggande SKU
Avsökningstyper TCP, HTTP, HTTPS TCP, HTTP
Avsökningsbeteende Alla avsökningar är nere, alla TCP-flöden fortsätter. Alla avsökningar är nere, alla TCP-flöden upphör att gälla.

Viktigt

Load Balancer hälsoavsökningar kommer från IP-adressen 168.63.129.16 och får inte blockeras för att avsökningar ska markera instansen som aktuell. Mer information finns i IP-adressen för avsökningskällan . Om du vill se den här avsökningstrafiken i serverdelsinstansen läser du vanliga frågor och svar om Azure Load Balancer.

Oavsett det konfigurerade tröskelvärdet för tidsgränsen markerar HTTP(S) hälsoavsökningar för lastbalanserare automatiskt instansen som ned om servern returnerar någon statuskod som inte är HTTP 200 OK eller om anslutningen avslutas via TCP-återställning.

Avsökningskonfiguration

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

  • Varaktighet för intervallet mellan enskilda avsökningar

  • Protokoll

  • Port

  • HTTP-sökväg att använda för HTTP GET när HTTP(S) avsökningar används

Anteckning

En avsökningsdefinition är inte obligatorisk eller söks efter när du använder Azure PowerShell, Azure CLI, mallar eller API. Valideringstest för avsökningar görs bara när du använder Azure-portalen.

Programsignal, signalidentifiering och Load Balancer reaktion

Intervallvärdet avgör hur ofta hälsoavsökningen avsöker ett svar från dina serverdelspoolinstanser. Om hälsoavsökningen misslyckas markeras dina serverdelspoolinstanser omedelbart som felaktiga. Vid nästa felfria avsökning markerar hälsoavsökningen omedelbart dina serverdelspoolinstanser som felfria.

En hälsoavsökning är till exempel inställd på fem sekunder. Den tid då en avsökning skickas synkroniseras inte med när programmet kan ändra tillstånd. Den totala tid det tar för hälsoavsökningen att återspegla ditt programtillstånd kan hamna i något av följande två scenarier:

  1. Om ditt program genererar ett timeout-svar precis innan nästa avsökning anländer tar det 5 sekunder att identifiera händelserna plus programmets tidsgräns när avsökningen tas emot. Du kan anta att identifieringen tar drygt 5 sekunder.

  2. Om ditt program genererar ett timeout-svar strax efter att nästa avsökning har anlänt, startar inte identifieringen av händelserna förrän avsökningen anländer och tidsgränsen nås, plus ytterligare 5 sekunder. Du kan anta att identifieringen tar knappt 10 sekunder.

I det här exemplet, när identifieringen har inträffat, tar det lite tid för plattformen att reagera på ändringen.

Reaktionen beror på:

  • När programmet ändras tillstånd
  • När ändringen identifieras
  • När nästa hälsoavsökning skickas
  • När identifieringen har kommunicerats över plattformen

Anta att reaktionen på ett timeout-svar tar minst 5 sekunder och högst 10 sekunder att reagera på ändringen.

Det här exemplet tillhandahålls för att illustrera vad som händer. Det går inte att förutse en exakt varaktighet utöver vägledningen i exemplet.

Anteckning

Hälsoavsökningen avsöker alla instanser som körs i serverdelspoolen. Om en instans stoppas avsöks den inte förrän den har startats igen.

Avsökningstyper

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

  • TCP-lyssnare

  • HTTP-slutpunkter

  • HTTPS-slutpunkter

Vilka protokoll som är tillgängliga beror på vilken lastbalanserings-SKU som används:

TCP HTTP HTTPS
Standard-SKU
Grundläggande SKU

TCP-avsökning

TCP-avsökningar initierar en anslutning genom att utföra en trevägs öppen TCP-handskakning med den definierade porten. TCP-avsökningar avslutar en anslutning med en fyrvägs nära TCP-handskakning.

Det minsta avsökningsintervallet är 5 sekunder och får inte överstiga 120 sekunder.

En TCP-avsökning misslyckas när:

  • TCP-lyssnaren på instansen svarar inte alls under tidsgränsen. En avsökning markeras ned baserat på antalet timeout-avsökningsbegäranden, som har konfigurerats för att gå obesvarade innan avsökningen markeras.

  • Avsökningen tar emot en TCP-återställning från instansen.

HTTP/HTTPS-avsökning

Anteckning

HTTPS-avsökningen är endast tillgänglig för usługa Load Balancer w warstwie Standardowa.

HTTP- och HTTPS-avsökningar bygger på TCP-avsökningen och utfärdar en HTTP GET med den angivna sökvägen. Båda dessa avsökningar stöder relativa sökvägar för HTTP GET. HTTPS-avsökningar är samma som HTTP-avsökningar med tillägg av en TLS (Transport Layer Security). Hälsoavsökningen markeras när instansen svarar med HTTP-status 200 inom tidsgränsen. Hälsoavsökningen försöker kontrollera den konfigurerade hälsoavsökningsporten var 15:e sekund som standard. Det minsta avsökningsintervallet är 5 sekunder och får inte överstiga 120 sekunder.

HTTP/HTTPS-avsökningar kan vara användbara för att implementera din egen logik för att ta bort instanser från lastbalanseraren om avsökningsporten också är lyssnaren för tjänsten. Du kan till exempel välja att ta bort en instans om den är över 90 % cpu och returnerar en HTTP-status som inte är 200.

Anteckning

HTTPS-avsökningen kräver användning av certifikat baserade på en minsta signaturhash för SHA256 i hela kedjan.

Om du använder Serviços de Nuvem och har webbroller som använder w3wp.exe får du automatisk övervakning av webbplatsen. Fel i webbplatskoden returnerar statusen icke-200 till lastbalanserarens avsökning.

En HTTP/HTTPS-avsökning misslyckas när:

  • Avsökningsslutpunkten returnerar en annan HTTP-svarskod än 200 (till exempel 403, 404 eller 500). Avsökningen markeras omedelbart.

  • Avsökningsslutpunkten svarar inte alls under det minsta avsökningsintervallet och tidsgränsen på 30 sekunder. Flera avsökningsbegäranden kan gå obesvarade innan avsökningen markeras som inte körs och tills summan av alla tidsgränsintervall har nåtts.

  • Avsökningsslutpunkten stänger anslutningen via en TCP-återställning.

Avsökningsbeteende

TCP-, HTTP- och HTTPS-hälsoavsökningar anses vara felfria och markerar serverdelsslutpunkten som felfri när:

  • Hälsoavsökningen lyckas en gång efter att den virtuella datorn startas.

Alla serverdelsslutpunkter som har uppnått ett felfritt tillstånd är berättigade att ta emot nya flöden.

Anteckning

Om hälsoavsökningen varierar väntar lastbalanseraren längre innan serverdelsslutpunkten hamnar i felfritt tillstånd igen. Den här extra väntetiden skyddar användaren och infrastrukturen och är en avsiktlig princip.

Avsökningsbeteende

TCP-anslutningar

Nya TCP-anslutningar kommer att lyckas med återstående felfria serverdelsslutpunkter.

Om en serverdelsslutpunkts hälsoavsökning misslyckas fortsätter etablerade TCP-anslutningar till den här serverdelsslutpunkten.

Om alla avsökningar för alla instanser i en serverdelspool misslyckas skickas inga nya flöden till serverdelspoolen. usługa Load Balancer w warstwie Standardowa tillåter etablerade TCP-flöden att fortsätta. Grundläggande Load Balancer avslutar alla befintliga TCP-flöden till serverdelspoolen.

Load Balancer är en genomströmningstjänst. Load Balancer avslutar inte TCP-anslutningar. Flödet är alltid mellan klienten och den virtuella datorns gästoperativsystem och program. En pool med alla avsökningar nere resulterar i en klientdel som inte svarar på TCP-anslutningsförsök. Det finns ingen felfri serverdelsslutpunkt för att ta emot flödet och svara med en bekräftelse.

UDP-datagram

UDP-datagram levereras till felfria serverdelsslutpunkter.

UDP är anslutningslös och det finns inget flödestillstånd spårat för UDP. Om någon serverdelsslutpunkts hälsoavsökning misslyckas flyttas befintliga UDP-flöden till en annan felfri instans i serverdelspoolen.

Om alla avsökningar för alla instanser i en serverdelspool misslyckas avslutas befintliga UDP-flöden för grundläggande och standardlastbalanserare.

Avsökning av källans IP-adress

Load Balancer använder en distribuerad avsökningstjänst för sin interna hälsomodell. Avsökningstjänsten finns på varje värd där virtuella datorer och kan programmeras på begäran för att generera hälsoavsökningar enligt kundens konfiguration. Hälsoavsökningstrafiken sker direkt mellan avsökningstjänsten som genererar hälsoavsökningen och kundens virtuella dator. Alla Load Balancer hälsoavsökningar kommer från IP-adressen 168.63.129.16 som källa.

Tjänsttaggen AzureLoadBalancer identifierar den här käll-IP-adressen i dina nätverkssäkerhetsgrupper och tillåter hälsoavsökningstrafik som standard.

Förutom hälsoavsökningar för lastbalanserare använder följande åtgärder den här IP-adressen:

  • Gör det möjligt för VM-agenten att kommunicera med plattformen för att signalera att den är i tillståndet "Klar"

  • Möjliggör kommunikation med den virtuella DNS-servern för att tillhandahålla filtrerad namnmatchning till kunder som inte definierar anpassade DNS-servrar. Den här filtreringen säkerställer att kunderna bara kan matcha värdnamnen för distributionen.

  • Gör att den virtuella datorn kan hämta en dynamisk IP-adress från DHCP-tjänsten i Azure.

Designvägledning

  • Hälsoavsökningar används för att göra din tjänst elastisk skalbar. En felkonfiguration kan påverka tjänstens tillgänglighet och skalbarhet. Granska hela dokumentet och fundera över vad som påverkar ditt scenario när avsökningssvaret är upp eller ned. Överväg hur avsökningssvaret påverkar programmets tillgänglighet.

  • 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 samma. I vissa fall kan det vara önskvärt att avsökningsporten skiljer sig från den port som programmet använder.

  • Det kan vara användbart för ditt program att generera ett hälsoavsökningssvar och signalera lastbalanseraren om din instans ska ta emot nya anslutningar. Du kan ändra avsökningssvaret för att begränsa leveransen av nya anslutningar till en instans genom att misslyckas med hälsoavsökningen. Du kan förbereda för underhåll av ditt program och initiera tömning av anslutningar till ditt program. En avsökningssignal tillåter alltid att TCP-flöden fortsätter tills tidsgränsen för inaktivitet eller anslutningen stängs i en usługa Load Balancer w warstwie Standardowa.

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

  • Lastbalanseringsregel för HA-portar med usługa Load Balancer w warstwie Standardowa. Alla portar är belastningsutjämning och ett enskilt hälsoavsökningssvar måste återspegla statusen för hela instansen.

  • Översätt inte eller skicka inte en hälsoavsökning via den instans som tar emot hälsoavsökningen till en annan instans i det virtuella nätverket. Den här konfigurationen kan leda till sammanhängande fel i ditt scenario. Exempel: En uppsättning enheter från tredje part distribueras i serverdelspoolen för en lastbalanserare för att tillhandahålla skalning och redundans för enheterna. Hälsoavsökningen är konfigurerad för att avsöka en port som tredjepartsinstallationen proxyservrar eller översätter till andra virtuella datorer bakom installationen. Om du avsöker samma port som används för att översätta eller proxybegäranden till de andra virtuella datorerna bakom installationen kommer eventuella avsökningssvar från en enda virtuell dator att markera installationen. Den här konfigurationen kan leda till ett sammanhängande fel i programmet. Utlösaren kan vara ett tillfälligt avsökningsfel som gör att lastbalanseraren markerar installationens instans. Den här åtgärden kan inaktivera ditt program. Avsök själva installationens hälsotillstånd. Valet av avsökning för att fastställa hälsosignalen är ett viktigt övervägande för scenarier med virtuella nätverksinstallationer (NVA). Kontakta programleverantören för att få en lämplig hälsosignal för sådana scenarier.

  • 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. I sin tur markerar Load Balancer din instans på grund av hälsoavsökningsfelet. Den här felkonfigurationen kan göra att ditt belastningsutjämningsprogramsscenario misslyckas.

  • För att Load Balancer hälsoavsökning ska kunna markera din instans måste du tillåta den här IP-adressen i alla Azure-nätverkssäkerhetsgrupper och lokala brandväggsprinciper. Som standard innehåller varje nätverkssäkerhetsgrupp tjänsttaggen AzureLoadBalancer för att tillåta hälsoavsökningstrafik.

  • Om du vill testa ett hälsoavsökningsfel eller markera 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 felet för en avsökning.

  • 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 orsaka att ditt scenario misslyckas.

  • Om du har flera gränssnitt konfigurerade på den virtuella datorn ska du se till att du svarar på avsökningen i gränssnittet 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.

  • Aktivera inte TCP-tidsstämplar. TCP-tidsstämplar kan orsaka att hälsoavsökningar misslyckas på grund av att TCP-paket tas bort av den virtuella datorns gäst-OS TCP-stack. De borttagna paketen kan göra att lastbalanseraren markerar slutpunkten som ur funktion. TCP-tidsstämplar är rutinmässigt aktiverade som standard på säkerhetshärdade VM-avbildningar och måste inaktiveras.

Övervakning

Offentliga och interna usługa Load Balancer w warstwie Standardowa exponerar hälsoavsökningsstatus per slutpunkt och serverdelsslutpunkt via Azure Monitor. Dessa mått kan användas av andra Azure-tjänster eller partnerprogram.

Azure Monitor-loggar är inte tillgängliga för både offentliga och interna Basic Load Balancers.

Begränsningar

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

  • Du bör anta att hälsoavsökningar misslyckas när TCP-tidsstämplar är aktiverade.

  • En hälsoavsökning för basic SKU-lastbalanserare stöds inte med en VM-skalningsuppsättning.

  • 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