Flera Azure Load Balancer

Azure Load Balancer kan du belastningsutjämna tjänster på flera portar, flera IP-adresser eller både och. Du kan använda offentliga och interna lastbalanseringsdefinitioner för att belastningsutjämna flöden över en uppsättning virtuella datorer.

I den här artikeln beskrivs grunderna i den här möjligheten, viktiga begrepp och begränsningar. Om du bara tänker exponera tjänster på en IP-adress hittar du förenklade instruktioner för offentliga eller interna konfigurationer av lastbalanserare. Att lägga till flera frontends är inkrementellt till en enda konfiguration för frontend. Med hjälp av begreppen i den här artikeln kan du när som helst utöka en förenklad konfiguration.

När du definierar en Azure Load Balancer ansluts en konfiguration för en frontend och en serverpool med regler. Hälsoavsökningen som regeln refererar till används för att avgöra hur nya flöden skickas till en nod i backend-poolen. Frontend (även kallat VIP) definieras av en 3-tuppel bestående av en IP-adress (offentlig eller intern), ett transportprotokoll (UDP eller TCP) och ett portnummer från belastningsutjämningsregeln. Serverdelspoolen är en samling IP-konfigurationer för virtuella datorer (en del av nätverkskortresursen) som refererar Load Balancer serverdelspoolen.

Följande tabell innehåller några exempel på konfigurationer för frontend:

Tabellen visar fyra olika frontends. Frontends #1, #2 och #3 en enda frontend med flera regler. Samma IP-adress används men porten eller protokollet är olika för varje frontend. Frontends #1 and #4 är ett exempel på flera frontends, där samma protokoll och port för frontend återanvänds över flera frontends.

Azure Load Balancer ger flexibilitet när du definierar belastningsutjämningsregler. En regel deklarerar hur en adress och port på frontend mappas till måladressen och porten på backend-platsen. Huruvida backend-portar återanvänds mellan regler beror på typen av regel. Varje typ av regel har specifika krav som kan påverka värdkonfigurationen och avsökningsdesignen. Det finns två typer av regler:

1. Standardregeln utan återanvändning av backend-portar
2. Den flytande IP-regeln där backend-portar återanvänds

Azure Load Balancer kan du blanda båda regeltyperna i samma lastbalanseringskonfiguration. Lastbalanseraren kan använda dem samtidigt för en viss virtuell dator, eller en kombination, så länge du följer regelns begränsningar. Vilken regeltyp du väljer beror på kraven för ditt program och komplexiteten med att stödja den konfigurationen. Du bör utvärdera vilka regeltyper som passar bäst för ditt scenario.

Vi utforskar dessa scenarier ytterligare genom att börja med standardbeteendet.

Regeltyp #1: Ingen återanvändning av backend-port

I det här scenariot konfigureras frontends på följande sätt:

Klientdel	IP-adress	Protokollet	port
1	65.52.0.1	TCP	80
2	65.52.0.2	TCP	80

DIP är målet för det inkommande flödet. I backend-poolen exponerar varje virtuell dator önskad tjänst på en unik port på en DIP. Den här tjänsten är associerad med frontend via en regeldefinition.

Vi definierar två regler:

Regel	Mappa frontend	Till en backend-pool
1	Frontend1:80	DIP1:80, DIP2:80
2	Frontend2:80	DIP1:81, DIP2:81

Den fullständiga mappningen i Azure Load Balancer är nu följande:

Regel	Ip-adress för frontend	Protokollet	port	Mål	port
1	65.52.0.1	TCP	80	DIP IP-adress	80
2	65.52.0.2	TCP	80	DIP IP-adress	81

Varje regel måste skapa ett flöde med en unik kombination av målets IP-adress och målport. Genom att variera målporten för flödet kan flera regler leverera flöden till samma DIP på olika portar.

Hälsoavsökningar dirigeras alltid till DIP för en virtuell dator. Du måste se till att avsökningen återspeglar den virtuella datorns hälsotillstånd.

Regeltyp för #2: återanvändning av backend-port med hjälp av flytande IP

Azure Load Balancer ger flexibiliteten att återanvända frontend-porten över flera frontends oavsett vilken regeltyp som används. Dessutom föredrar eller kräver vissa programscenarier att samma port används av flera programinstanser på en enda virtuell dator i backend-poolen. Vanliga exempel på återanvändning av portar är klustring för hög tillgänglighet, virtuella nätverksutrustning och exponera flera TLS-slutpunkter utan omkryptering.

Om du vill återanvända backend-porten över flera regler måste du aktivera Flytande IP i regeldefinitionen.

"Flytande IP" är Azures terminologi för en del av det som kallas Direct Server Return (DSR). DSR består av två delar: en flödestopologi och ett schema för IP-adressmappning. På plattformsnivå fungerar Azure Load Balancer alltid i en DSR-flödestopologi oavsett om flytande IP är aktiverat eller inte. Det innebär att den utgående delen av ett flöde alltid skrivs om för att flöda direkt tillbaka till ursprunget.

Med standardregeltypen exponerar Azure ett traditionellt schema för IP-adressmappning för belastningsutjämning för enkel användning. Om du aktiverar flytande IP ändras IP-adressmappningsschemat för att ge ytterligare flexibilitet enligt förklaringen nedan.

Följande diagram illustrerar den här konfigurationen:

I det här scenariot har varje virtuell dator i backend-poolen tre nätverksgränssnitt:

• DIP: ett virtuellt nätverkskort som är associerat med den virtuella datorn (IP-konfiguration av Azures NIC-resurs)
• Frontend 1: ett loopback-gränssnitt i gästoperativsystemet som är konfigurerat med IP-adressen för Frontend 1
• Frontend 2: ett loopback-gränssnitt i gästoperativsystemet som är konfigurerat med IP-adressen för Frontend 2

För varje virtuell dator i backend-poolen kör du följande kommandon i en Windows kommandotolk.

Skriv följande kommando för att hämta listan över gränssnittsnamn som du har på den virtuella datorn:

netsh interface show interface 

För vm-nätverkskortet (Azure-hanterat) skriver du det här kommandot:

netsh interface ipv4 set interface “interfacename” weakhostreceive=enabled

(ersätt interfacename med namnet på det här gränssnittet)

Upprepa följande kommandon för varje loopback-gränssnitt som du har lagt till:

netsh interface ipv4 set interface “interfacename” weakhostreceive=enabled 

(ersätt interfacename med namnet på det här loopback-gränssnittet)

netsh interface ipv4 set interface “interfacename” weakhostsend=enabled 

(ersätt interfacename med namnet på det här loopback-gränssnittet)

Vi antar att du har samma konfiguration på serversidan som i föregående scenario:

Klientdel	IP-adress	Protokollet	port
1	65.52.0.1	TCP	80
2	65.52.0.2	TCP	80

Vi definierar två regler:

Regel	Klientdel	Mappa till backend-pool
1	Frontend1:80	Frontend1:80 (i VM1 och VM2)
2	Frontend2:80	Frontend2:80 (i VM1 och VM2)

I följande tabell visas den fullständiga mappningen i lastbalanseraren:

Regel	Ip-adress för frontend	Protokollet	port	Mål	port
1	65.52.0.1	TCP	80	samma som frontend (65.52.0.1)	samma som frontend (80)
2	65.52.0.2	TCP	80	samma som frontend (65.52.0.2)	samma som frontend (80)

Målet för det inkommande flödet är IP-adressen för frontend i loopback-gränssnittet på den virtuella datorn. Varje regel måste skapa ett flöde med en unik kombination av målets IP-adress och målport. Genom att variera flödets mål-IP-adress är portåteranvänt möjligt på samma virtuella dator. Din tjänst exponeras för lastbalanseraren genom att binda den till frontend-IP-adressen och porten för respektive loopback-gränssnitt.

Observera att det här exemplet inte ändrar målporten. Även om det här är ett flytande IP-scenario Azure Load Balancer även stöd för att definiera en regel för att skriva om målporten för backend och göra den annorlunda än målporten för frontend.

Den flytande IP-regeltypen är grunden för flera konfigurationsmönster för lastbalanserare. Ett exempel som för närvarande är tillgängligt är SQL AlwaysOn med flera lyssnare konfiguration. Med tiden kommer vi att dokumentera fler av de här scenarierna.

Begränsningar

• Flera konfigurationer på serversidan stöds endast med virtuella IaaS-datorer.
• Med den flytande IP-regeln måste programmet använda den primära IP-konfigurationen för utgående SNAT-flöden. Om ditt program binder till den IP-adress för frontend som konfigurerats i loopback-gränssnittet i gästoperativsystemet är Azures utgående SNAT inte tillgängligt för att skriva om det utgående flödet och flödet misslyckas. Granska utgående scenarier.
• Flytande IP stöds för närvarande inte i sekundära IP-konfigurationer för scenarier med intern belastningsutjämning.
• Offentliga IP-adresser påverkar faktureringen. Mer information finns i Prissättning för IP-adresser
• Prenumerationsbegränsningar gäller. Mer information finns i Tjänstbegränsningar.

Nästa steg

• Granska Utgående anslutningar för att förstå effekten av flera frontends på utgående anslutningsbeteende.