Flera frontends för Azure Load Balancer

Azure Load Balancer du belastningsutjämna tjänster på flera portar, flera IP-adresser eller båda. Du kan använda offentliga och interna definitioner av belastningsutjämning för att balansera flöden i en uppsättning virtuella maskiner.

I den här artikeln beskrivs grunderna för den här möjligheten, viktiga begrepp och begränsningar. Om du bara tänker visa tjänster på en IP-adress kan du hitta förenklade instruktioner för offentligaeller interna belastningsutjämningkonfigurationer. Om du vill lägga till flera frontend måste du stegvis lägga till flera frontend-konfigurationer. Med hjälp av begreppen i den här artikeln kan du utöka en förenklad konfiguration när som helst.

När du definierar Azure Load Balancer enhet är konfiguration av en frontend och en backendpool anslutna till regler. Hälsoproben som refereras av regeln används för att fastställa hur nya flöden skickas till en nod i backendpoolen. Frontend (även kallat VIP) definieras av ett tre par som består av en IP-adress (offentlig eller intern), ett transportprotokoll (UDP eller TCP) och ett portnummer från belastningsutjämningsregeln. Serverdelspoolen är en samling Virtual Machine IP-konfigurationer (en del av NIC-resursen) som refererar till poolen Load Balancer backend.

Följande tabell innehåller några exempelkonfigurationer:

Framsida IP-adress protokoll port
1 65.52.0.1 TCP 80
2 65.52.0.1 TCP 8080
3 65.52.0.1 UDP 80
4 65.52.0.2 TCP 80

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

Azure Load Balancer är flexibelt att definiera regler för belastningsutjämning. En regel förklarar hur en adress och port på framsidan mappas till måladressen och port på backend. Huruvida backend-portar återanvänds i olika regler beror på typen av regel. Varje typ av regel har specifika krav som kan påverka värdkonfiguration och mätdesign. Det finns två typer av regler:

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

Azure Load Balancer kan du kombinera båda regeltyperna i samma konfiguration för belastningsutjämning. Belastningsutjämaren kan använda dem samtidigt för en viss VM, eller en kombination, så länge du följer villkoren i regeln. Vilken regeltyp du väljer beror på kraven i programmet och hur komplex stödkonfigurationen är. Du bör utvärdera vilka regeltyper som passar bäst för ditt scenario.

Vi utforskar scenarierna ytterligare genom att börja med standardbeteendet.

Regeltyp #1: Ingen återanvändning av backendport

Multiple frontend illustration with green and purple frontend

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

Framsida IP-adress protokoll port
green frontend 1 65.52.0.1 TCP 80
purple frontend 2 65.52.0.2 TCP 80

DIP är målet för det inkommande flödet. I backendpoolen visar varje VM önskad tjänst på en unik port på en DIP. Den här tjänsten är kopplad till frontend genom en regeldefinition.

Vi definierar två regler:

Regel Karta, framsida Till backendpool
1 green frontend Frontend1:80 green backendgreen backendDIP1:80,IPIP2:80
2 VIP Frontend2:80 purple backendpurple backendDIP1:81,IPIP2:81

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

Regel IP-adress på framsidan protokoll port Mål port
green rule 1 65.52.0.1 TCP 80 DIP IP Address 80
purple rule 2 65.52.0.2 TCP 80 DIP IP Address 81

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

Hälsoprondenser dirigeras alltid till DIP för en VM. Du måste se till att en sonder visar den virtuella maskinernas hälsa.

Regeltyp nr 2: återanvändning av backendport genom att använda flytande IP

Azure Load Balancer får flexibiliteten att återanvända frontendporten på 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 VM i backendpoolen. Vanliga exempel på återanvändning av portar är gruppering för hög tillgänglighet, virtuella nätverksutrustning och att flera TLS-slutpunkter visas utan omkryptering.

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

"Flytande IP" är Azures terminologi för en del av vad som kallas Direct Server Return (DSR). DSR består av två delar: en flödestopologi och ett IP-adressmappningsschema. På en plattformsnivå 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 korrekt för att flöda direkt tillbaka till ursprunget.

Med standardregeltypen visar Azure ett traditionellt mappningsschema för belastningsutjämning av IP-adresser så att det blir enklare att använda det. Om flytande IP tillåts ändras mappningsschemat för IP-adresser så att det blir mer flexibelt enligt nedan.

Följande diagram visar den här konfigurationen:

Multiple frontend illustration with green and purple frontend with DSR

I det här scenariot har varje VM i backendpool tre nätverksgränssnitt:

  • DIP: en virtuell NIC som är kopplad till VM (IP-konfiguration av Azures NIC-resurs)
  • Frontend 1: ett loopback-gränssnitt i gästoperativsystem som är konfigurerat med IP-adressen Frontend 1
  • Frontend 2: ett loopback-gränssnitt i gästoperativsystem som är konfigurerat med IP-adressen Frontend 2

För varje VM i backendpoolen kör du följande kommandon på en Windows Kommandotolken.

Om du vill visa listan med gränssnittsnamn som du har på den virtuella datorn skriver du det här kommandot:

netsh interface show interface 

För VM NIC (Azure managed) skriver du det här kommandot:

netsh interface ipv4 set interface “interfacename” weakhostreceive=enabled

(ersätt gränssnittsnamn 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 gränssnittsnamn med namnet på det här loopback-gränssnittet)

netsh interface ipv4 set interface “interfacename” weakhostsend=enabled 

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

Viktigt

Konfigurationen av loopback-gränssnitt utförs i gästoperativsystemet. Den här konfigurationen utförs inte eller hanteras av Azure. Utan den här konfigurationen fungerar reglerna inte. Hälsodefinitioner använderIP för den virtuella maskinerna i stället för loopback-gränssnittet som representerar DSR-frontend. Därför måste tjänsten tillhandahålla sondesvar på en DIP-port som återspeglar statusen för den tjänst som erbjuds i loopback-gränssnittet som representerar DSR-frontend.

Låt oss anta samma konfiguration som i föregående scenario:

Framsida IP-adress protokoll port
green frontend 1 65.52.0.1 TCP 80
purple frontend 2 65.52.0.2 TCP 80

Vi definierar två regler:

Regel Framsida Karta till backendpool
1 green rule Frontend1:80 green backend Frontend1:80 (i VM1 och VM2)
2 purple rule Frontend2:80 purple backend Frontend2:80 (i VM1 och VM2)

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

Regel IP-adress på framsidan protokoll port Mål port
green rule 1 65.52.0.1 TCP 80 samma som frontend (65.52.0.1) samma som frontend (80)
purple rule 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 frontend-IP-adressen i loopback-gränssnittet i den virtuella maskinerna. Varje regel måste skapa ett flöde med en unik kombination av MÅL-IP-adress och målport. Genom att ange en varierande IP-adress för flödet går det att återanvända port på samma VM. Tjänsten exponeras för belastningsutjämaren genom att binda den till frontends IP-adress och port i det respektive loopback-gränssnittet.

Observera att detta exempel inte ändrar målporten. Även om det här är ett flytande IP-scenario har 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 på framsidan.

Den flytande IP-regeltypen är grunden för flera konfigurationsmönster för belastningsutjämning. Ett exempel som för närvarande är tillgängligt är konfigurationen SQL AlwaysOn med flera lyssnare. Med tiden dokumenterar vi mer av scenarierna.

Begränsningar

  • Flera konfigurationer av frontend stöds endast med virtuella IaaS-maskiner.
  • Med den flytande IP-regeln måste programmet använda den primära IP-konfigurationen för utgående SNAT-flöden. Om programmet binder till frontend-IP-adressen som konfigurerats i gränssnittet för loopback i gäst-operativsystemet ä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 för sekundära IP-konfigurationer för scenarier med intern belastningsutjämning.
  • Offentliga IP-adresser påverkar faktureringen. Mer information finns i Priser för IP-adresser
  • Prenumerationsbegränsningar gäller. Mer information finns i Tjänstbegränsningar för mer information.

Nästa steg