Hälsoavsökningar för Azure Load Balancer

  • Artikel

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älsoavsöknings- och avsökningssvaren avgör vilka serverdelspoolinstanser som tar 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 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.

Avsökningsprotokoll

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

Standard-SKU Grundläggande SKU
Avsökningsprotokoll 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.

Avsökningsegenskaper

Hälsoavsökningar har följande egenskaper:

Namn på hälsoavsökningsegenskap Details
Name Namnet på hälsoavsökningen. Det här är ett namn som du får definiera för hälsoavsökningen
Protokoll Protokoll för hälsoavsökning. Det här är den protokolltyp som du vill att hälsoavsökningen ska använda. Alternativen är: TCP, HTTP, HTTPS
Port Port för hälsoavsökningen. Den målport som du vill att hälsoavsökningen ska använda när den ansluter till den virtuella datorn för att kontrollera dess hälsa
Intervall (sekunder) Intervall för hälsoavsökning. Hur lång tid (i sekunder) mellan olika avsökningar vid två på varandra följande hälsokontrollförsök till den virtuella datorn
Används av Listan över regler för lastbalanserare med den här specifika hälsoavsökningen. Du bör ha minst en regel som använder hälsoavsökningen för att den ska vara effektiv

Avsökningskonfiguration

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

Konfiguration av hälsoavsökning Details
Protokoll Protokoll för hälsoavsökning. Det här är den protokolltyp som du vill att hälsoavsökningen ska använda. Tillgängliga alternativ är: TCP, HTTP, HTTPS
Port Port för hälsoavsökningen. Den målport som du vill att hälsoavsökningen ska använda när den ansluter till den virtuella datorn för att kontrollera den virtuella datorns hälsostatus. Du måste se till att den virtuella datorn också lyssnar på den här porten (d.v.s. porten är öppen).
Intervall Intervall för hälsoavsökning. Hur lång tid (i sekunder) mellan efterföljande hälsokontrollförsök till den virtuella datorn

Avsökningsprotokoll

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

Scenario TCP-avsökning HTTP/HTTPS-avsökning
Översikt 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. HTTP och HTTPS 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ägget av en TLS (Transport Layer Security). 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.
Beteende för avsökningsfel En TCP-avsökning misslyckas när: 1. TCP-lyssnaren på instansen svarar inte alls under tidsgränsen. En avsökning markeras nedåt baserat på antalet timeout-avsökningsbegäranden, som har konfigurerats för att gå obesvarade innan avsökningen markeras. 2. Avsökningen tar emot en TCP-återställning från instansen. En HTTP/HTTPS-avsökning misslyckas när: 1. Avsökningsslutpunkten returnerar en annan HTTP-svarskod än 200 (till exempel 403, 404 eller 500). 2. Avsökningsslutpunkten svarar inte alls under minimiintervallet för avsökningen och tidsgränsen på 30 sekunder. Flera avsökningsbegäranden kan gå obesvarade innan avsökningen markeras som att den inte körs och tills summan av alla tidsgränsintervall har nåtts. 3. Avsökningsslutpunkten stänger anslutningen via en TCP-återställning.
Avsökningsbeteende TCP-hälsoavsökningar anses vara felfria och markerar serverdelsslutpunkten som felfri när: 1. Hälsoavsökningen lyckas en gång efter att den virtuella datorn har startats. 2. Alla serverdelsslutpunkter som har uppnått ett felfritt tillstånd är berättigade att ta emot nya flöden. Hälsoavsökningen markeras när instansen svarar med HTTP-status 200 inom tidsgränsen. HTTP/HTTPS-hälsoavsökningar anses vara felfria och markerar serverdelsslutpunkten som felfri när: 1. Hälsoavsökningen lyckas en gång efter att den virtuella datorn har startats. 2. Alla serverdelsslutpunkter som har uppnått ett felfritt tillstånd är berättigade att ta emot nya flöden.

Kommentar

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

Avsökningsbeteende

Scenario TCP-anslutningar UDP-datagram
Enstaka instansavsökningar är nere Nya TCP-anslutningar lyckas med att förbli felfria serverdelsslutpunkter. Upprättade TCP-anslutningar till den här serverdelsslutpunkten fortsätter. Befintliga UDP-flöden flyttas till en annan felfri instans i serverdelspoolen.
Alla instanser avsöker nedåt Inga nya flöden skickas till serverdelspoolen. Med Standard Load Balancer kan etablerade TCP-flöden fortsätta eftersom en serverdelspool har fler än en serverdelsinstans. Basic Load Balancer avslutar alla befintliga TCP-flöden till serverdelspoolen. Alla befintliga UDP-flöden avslutas.

Avsökningsintervall & timeout

Intervallvärdet avgör hur ofta hälsoavsökningen söker efter ett svar från dina serverdelspoolinstanser. Om hälsoavsökningen misslyckas markeras dina serverdelspoolinstanser omedelbart som felaktiga. Om hälsoavsökningen lyckas vid nästa felfria avsökning markerar Azure Load Balancer dina serverdelspoolinstanser som felfria. Hälsoavsökningen försöker kontrollera den konfigurerade hälsoavsökningsporten var 5:e sekund som standard, men kan uttryckligen anges till 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 har skickats)
  • Tidsgräns för HTTP/S-avsökning: 30 sekunder

Om det konfigurerade intervallet är längre än tidsgränsen ovan för HTTP/S-avsökningar kommer hälsoavsökningen att överskrida 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 har avsökningen nått sin tidsgräns och misslyckas.

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 samma. 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 det att dessa är samma port.

  • 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 gör alltid att TCP-flöden kan fortsätta tills tidsgränsen för inaktivitet eller anslutningen stängs i en Standard Load Balancer.

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

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

  • Översätt inte eller proxy 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 fel i ditt scenario. Till exempel: En uppsättning tredjepartsinstallationer 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 markerar alla avsökningssvar från en enda virtuell dator enheten. 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 installationsinstansen. Den här åtgärden kan inaktivera ditt program. Avsöka själva installationens hälsa. Valet av avsökningen 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.

  • Observera att en avsökningsdefinition inte är obligatorisk eller sökbar när du använder Azure PowerShell, Azure CLI, mallar eller API. Avsökningsverifieringstester görs endast när du använder Azure-portalen.

  • Om hälsoavsökningen fluktuerar väntar lastbalanseraren längre innan serverdelsslutpunkten återgår till felfritt 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 serverdelspoolen söker hälsoavsökningen efter 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 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.

Övervakning

Standard Load Balancer exponerar hälsoavsökningsstatus per slutpunkt och serverdelsslutpunkt 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 avsökningskälla

För att 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äkerhetsgrupperoch lokala brandväggsprinciper. AzureLoadBalancer-tjänsttaggen 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 den här 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 instansen som nere på grund av hälsoavsökningsfelet. Den här felkonfigurationen kan göra att ditt belastningsbalanserade programscenario misslyckas. Alla hälsoavsökningar för IPv4 Load Balancer kommer från IP-adressen 168.63.129.16 som källa. IPv6-avsökningar använder en länklokal adress som källa.

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