Hälsoavsökningar för Load Balancer

När du använder belastningsutjämningsregler med Azure Load Balancer måste du ange hälsoavsökningar så att Load Balancer kan identifiera status för slutpunkten i backend. Konfigurationen av hälsoavsökningen och avsökningssvaren avgör vilka instanser av serverpoolen som tar emot nya flöden. Du kan använda hälsoavsökningar för att identifiera fel i ett program på en backend-slutpunkt. Du kan också generera ett anpassat svar på en hälsoavsökning och använda hälsoavsökningen för flödeskontroll för att hantera belastning eller planerat driftstopp. När en hälsoavsökning misslyckas slutar Load Balancer att skicka nya flöden till respektive ohälsosamma instans. Utgående anslutningar påverkas inte, endast inkommande anslutningar påverkas.

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

Avsökningskonfiguration

Konfigurationen av hälsoavsökningen består av följande element:

• Varaktigheten för intervallet mellan enskilda avsökningar
• Avsökningens protokoll
• Avsökningens port
• HTTP-sökväg som ska användas för HTTP GET vid användning av HTTP(S)-avsökningar

Förstå programsignal, identifiering av signalen och plattformens reaktion

Intervallets värde avgör hur ofta hälsoavsökningen ska avse ett svar från instanserna i din backend-pool. Om hälsoavsökningen misslyckas markeras instanserna i din backend-pool omedelbart som felaktiga. På samma sätt markerar hälsoavsökningen omedelbart instanserna i backend-poolen som felfria igen vid nästa felfria avsökning.

Vi kan illustrera beteendet ytterligare med ett exempel där ditt intervall för hälsoavsökning har angetts till 5 sekunder. Eftersom tiden då en avsökning skickas inte synkroniseras med när ditt program kan ändra tillstånd, kan den totala tid det tar för hälsoavsökningen att återspegla programtillståndet att hamna i något av följande två scenarier:

1. Om programmet börjar producera ett time out-avsökningssvar precis innan nästa avsökning anländer tar det fem sekunder att identifiera dessa händelser plus programmets varaktighet som börjar signalera en time out tills avsökningen anländer. Du kan anta att den här identifieringen tar något över 5 sekunder.
2. Om ditt program börjar producera ett time out-avsökningssvar precis efter att nästa avsökning anländer, startar inte identifieringen av dessa händelser förrän avsökningen anländer (och når sin time out) plus ytterligare 5 sekunder. Du kan anta att den här identifieringen tar strax under 10 sekunder.

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

1. när programmet börjar ändra tillstånd och
2. när den här ändringen identifieras (när nästa hälsoavsökning skickas) och
3. när identifieringen har kommunicerats via plattformen

Du kan anta att reaktionen på ett time out-avsökningssvar tar mellan minst 5 sekunder och högst något över 10 sekunder för att reagera på en ändring i signalen från programmet. Det här exemplet tillhandahålls för att illustrera vad som händer, men det går inte att förutse en exakt varaktighet utöver ovanstående ungefärliga vägledning som illustreras i det här exemplet.

Avsökningstyper

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

• TCP-lyssnare
• HTTP-slutpunkter
• HTTPS-slutpunkter

Vilka protokoll som är tillgängliga beror på vilken Load Balancer SKU som används:

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 det minsta antalet felaktiga svar är 2. Den totala varaktigheten för alla intervall 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 time out-avsökningsbegäranden, som har konfigurerats att gå obesvarade innan avsökningen markeras.
• Avsökningen tar emot en TCP-återställning från instansen.

Följande illustrerar hur du kan uttrycka den här typen av avsökningskonfiguration i en Resource Manager mall:

    {
      "name": "tcp",
      "properties": {
        "protocol": "Tcp",
        "port": 1234,
        "intervalInSeconds": 5,
        "numberOfProbes": 1
      },

HTTP-/HTTPS-avsökning

HTTP- och HTTPS-avsökningar bygger på TCP-avsökningen och utfärdar en HTTP GET med den angivna sökvägen. Båda avsökningarna 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 (kallades tidigare SSL). Hälsoavsökningen markeras när instansen svarar med HTTP-statusen 200 inom tidsgränsperioden. Hälsoavsökningen försöker som standard kontrollera den konfigurerade hälsoavsökningsporten var 15:e sekund. Det minsta avsökningsintervallet är 5 sekunder. Den totala varaktigheten för alla intervall får inte överstiga 120 sekunder.

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

Om du använder Cloud Services och har webbroller som använder w3wp.exe uppnår du även automatisk övervakning av din webbplats. Fel i din webbplatskod 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). Detta markerar hälsoavsökningen omedelbart.
• Avsökningsslutpunkten svarar inte alls under det minsta avsökningsintervallet och tidsgränsen på 30 sekunder. Flera avsökningsbegäranden kan bli obesvarade innan avsökningen markeras som att den inte körs och tills summan av alla tidsgränsintervall har uppnåtts.
• Avsökningsslutpunkten stänger anslutningen via en TCP-återställning.

Följande illustrerar hur du kan uttrycka den här typen av avsökningskonfiguration i en Resource Manager mall:

    {
      "name": "http",
      "properties": {
        "protocol": "Http",
        "port": 80,
        "requestPath": "/",
        "intervalInSeconds": 5,
        "numberOfProbes": 1
      },

    {
      "name": "https",
      "properties": {
        "protocol": "Https",
        "port": 443,
        "requestPath": "/",
        "intervalInSeconds": 5,
        "numberOfProbes": 1
      },

Beteende för avsökning

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

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

Alla backend-slutpunkter som har uppnått felfritt tillstånd kan ta emot nya flöden.

Beteende för avsökning

TCP-anslutningar

Nya TCP-anslutningar lyckas med att upprätthålla felfria slutpunkter i backend-

Om hälsoavsökningen för en slutpunkt på en backend misslyckas fortsätter etablerade TCP-anslutningar till den här slutpunkten för backend.

Om alla avsökningar för alla instanser i en backend-pool misslyckas skickas inga nya flöden till backend-poolen. Standard Load Balancer tillåter att etablerade TCP-flöden fortsätter. Grundläggande Load Balancer avslutar alla befintliga TCP-flöden till backend-poolen.

Load Balancer är en genomströmningstjänst (avbryter inte TCP-anslutningar) och flödet är alltid mellan klienten och den virtuella datorns gästoperativsystem och program. En pool med alla avsökningar nere gör att klientsidan inte svarar på öppna TCP-anslutningsförsök (SYN) eftersom det inte finns någon felfri slutpunkt för att ta emot flödet och svara med en SYN-ACK.

UDP-datagram

UDP-datagram levereras till felfria slutpunkter i backend.

UDP är anslutningslöst och det finns inget flödestillstånd spårat för UDP. Om hälsoavsökningen för en slutpunkt på backend-instansen misslyckas flyttas befintliga UDP-flöden till en annan felfri instans i backend-poolen.

Om alla avsökningar för alla instanser i en backend-pool misslyckas avslutas befintliga UDP-flöden för Basic- och Standard Load Balancers.

Ip-adress för avsökningskälla

Load Balancer använder en distribuerad avsökningstjänst för den interna hälsomodellen. Avsökningstjänsten finns på varje värd där virtuella datorer kan programmeras på begäran för att generera hälsoavsökningar enligt kundens konfiguration. Hälsoavsökningstrafiken är 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. Du kan använda IP-adressutrymmet i ett VNet som inte är RFC1918-utrymme. Med en globalt reserverad IP-adress som ägs av Microsoft minskar risken för en IP-adresskonflikt med det IP-adressutrymme som du använder i det virtuella nätverket. Den här IP-adressen är densamma i alla regioner och ändras inte och är inte en säkerhetsrisk eftersom endast den interna Azure-plattformskomponenten kan källa ett paket från den här IP-adressen.

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

Förutom att Load Balancer avsökningar 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"
• Gör det möjligt för kommunikation med den virtuella DNS-servern 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 tjänsten motståndskraftig och tillåta skalning. En felaktig konfiguration eller ett felaktigt designmönster kan påverka tjänstens tillgänglighet och skalbarhet. Granska hela dokumentet och fundera över hur ditt scenario påverkas när avsökningssvaret markeras eller markeras, och hur det påverkar tillgängligheten för ditt programscenario.

När du utformar hälsomodellen för ditt program bör du avse en port på en slutpunkt i en backend som återspeglar hälsotillståndet för den instansen och den programtjänst som du tillhandahåller. Programporten och avsökningsporten måste inte vara samma. I vissa fall kan det vara önskvärt att avsökningsporten skiljer sig från porten som programmet tillhandahåller tjänsten på.

Ibland kan det vara användbart för ditt program att generera ett hälsoavsökningssvar för att inte bara identifiera programmets hälsotillstånd, utan även signalera direkt till Load Balancer om din instans ska ta emot eller inte ta emot nya flöden. Du kan ändra avsökningssvaret så att ditt program kan skapa ett undertryck och begränsa leveransen av nya flöden till en instans genom att misslyckas med hälsoavsökningen eller förbereda för underhåll av programmet och initiera tömning av scenariot. När du Standard Load Balancer en avsökningssignal tillåter alltid att TCP-flöden fortsätter tills tidsgränsen för inaktivitet eller anslutningen stängs.

För UDP-belastningsutjämning bör du generera en anpassad hälsoavsökningssignal från backend-slutpunkten och använda antingen en TCP-, HTTP- eller HTTPS-hälsoavsökning som riktar in sig på motsvarande lyssnare för att återspegla hälsotillståndet för ditt UDP-program.

När du använder lastbalanseringsregler för HA-portar med Standard Load Balancerbelastningsutjämnas alla portar och ett enda hälsoavsökningssvar måste återspegla statusen för hela instansen.

Översätt inte eller proxyservern för en hälsoavsökning via den instans som tar emot hälsoavsökningen till en annan instans i ditt VNet eftersom den här konfigurationen kan leda till sammanhängande fel i ditt scenario. Tänk dig följande scenario: en uppsättning tredjepartsinstallationer distribueras i serverpoolen för en Load Balancer-resurs för att tillhandahålla skalning och redundans för apparaterna och hälsoavsökningen konfigureras för att avse en port som tredjepartsinstallationens proxy eller översätter till andra virtuella datorer bakom installationen. Om du avsökning av samma port som du använder för att översätta eller proxybegäranden till de andra virtuella datorerna bakom installationen, kommer alla avsökningssvar från en enda virtuell dator bakom installationen att markera själva installationen som död. Den här konfigurationen kan leda till ett kaskadfel i hela programscenariot som ett resultat av en enda serverslutpunkt bakom installationen. Utlösaren kan vara ett tillfälligt avsökningsfel som gör att Load Balancer markerar det ursprungliga målet (installationens instans) och i sin tur kan inaktivera hela programscenariot. Avsökning av hälsotillståndet för själva installationen i stället. Valet av avsökning för att fastställa hälsosignalen är ett viktigt övervägande vid scenarier med virtuella nätverks installationer (NVA), och du måste kontakta programleverantören för att se vilken hälsosignal som är lämplig 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 Load Balancer ned instansen på grund av fel i hälsoavsökningen. Den här felkonfigurationen kan göra att det belastningsutjämnade programscenariot misslyckas.

För Load Balancer hälsoavsökningen ska 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 fel i hälsoavsökningen eller markera en enskild instans kan du använda nätverkssäkerhetsgrupper för att uttryckligen blockera hälsoavsökningen (målporten eller käll-IP)ochsimulera 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. Sådana konfigurationer krockar med IP-adressen för hälsoavsökningen och kan orsaka att ditt scenario misslyckas.

Om du har flera gränssnitt på den virtuella datorn måste du försäkra dig om att du svarar på avsökningen i det gränssnitt som du fick den på. Du kan behöva källans nätverksadress översätta den här adressen i den virtuella datorn per gränssnitt.

Aktivera inte TCP-tidsstämplar. Aktivering av TCP-tidsstämplar kan orsaka att hälsoavsökningar misslyckas på grund av att TCP-paket tas bort av den virtuella datorns TCP-stack för gästoperativsystem, vilket resulterar i att Load Balancer markerar respektive slutpunkt. TCP-tidsstämplar är rutinmässigt aktiverade som standard på säkerhetshärdade VM-avbildningar och måste inaktiveras.

Övervakning

Både offentliga och interna Standard Load Balancer visar hälsoavsökningsstatus per slutpunkt och slutpunkt på backend-slutpunkten som flerdimensionella mått via Azure Monitor. Dessa mått kan användas av andra Azure-tjänster eller partnerprogram.

Azure Monitor är inte tillgängliga för både offentliga och interna grundläggande lastbalanserare.

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 grundläggande SKU-lastbalanseringshälsoavsökning stöds inte med en VM-skalningsuppsättning.

Nästa steg

• Läs mer om Standard Load Balancer
• Kom igång med att skapa en offentlig lastbalanserare i Resource Manager med hjälp av PowerShell
• REST API för hälsoavsökningar
• Begära nya hälsoavsökningsförmågor Load Balancer användarens UserVoice