Meerdere front-Azure Load Balancer

Azure Load Balancer kunt u services op meerdere poorten, meerdere IP-adressen of beide load balancen. U kunt openbare en interne definities load balancer voor het laden van stromen over een set VM's.

In dit artikel worden de grondbeginselen van deze mogelijkheid, belangrijke concepten en beperkingen beschreven. Als u alleen services op één IP-adres beschikbaar wilt stellen, vindt u vereenvoudigde instructies voor openbare of interne load balancer configuraties. Het toevoegen van meerdere front-enden is incrementeel aan één front-endconfiguratie. Aan de hand van de concepten in dit artikel kunt u op elk moment een vereenvoudigde configuratie uitbreiden.

Wanneer u een Azure Load Balancer definieert, zijn een front-en-back-en-back-en-poolconfiguratie verbonden met regels. De statustest waarnaar wordt verwezen door de regel wordt gebruikt om te bepalen hoe nieuwe stromen worden verzonden naar een knooppunt in de back-endpool. De front-end (ook wel VIP genoemd) wordt gedefinieerd door een 3-tuple die bestaat uit een IP-adres (openbaar of intern), een transportprotocol (UDP of TCP) en een poortnummer van de taakverdelingsregel. De back-Load Balancer is een verzameling IP-configuraties voor virtuele machines (onderdeel van de NIC-resource).

De volgende tabel bevat enkele voorbeeldconfiguraties voor front-enden:

De tabel bevat vier verschillende front-enden. Front-#1, #2 en #3 zijn één front-end met meerdere regels. Hetzelfde IP-adres wordt gebruikt, maar de poort of het protocol verschilt voor elke front-end. Front-#1 en #4 zijn een voorbeeld van meerdere front-enden, waarbij hetzelfde front-endprotocol en dezelfde poort opnieuw worden gebruikt voor meerdere front-enden.

Azure Load Balancer biedt flexibiliteit bij het definiëren van de taakverdelingsregels. Met een regel wordt gedeclareerd hoe een adres en poort op de front-end worden toekend aan het doeladres en de poort op de back-einde. Of back-endpoorten opnieuw worden gebruikt in regels is afhankelijk van het type regel. Elk type regel heeft specifieke vereisten die van invloed kunnen zijn op de hostconfiguratie en het testontwerp. Er zijn twee soorten regels:

1. De standaardregel zonder dat de back-endpoort opnieuw wordt gebruikt
2. De zwevende IP-regel waarbij back-endpoorten opnieuw worden gebruikt

Azure Load Balancer kunt u beide regeltypen combineren op dezelfde load balancer configuratie. De load balancer kunnen ze tegelijkertijd gebruiken voor een bepaalde VM of een combinatie, zolang u zich houdt aan de beperkingen van de regel. Welk regeltype u kiest, is afhankelijk van de vereisten van uw toepassing en de complexiteit van het ondersteunen van die configuratie. U moet evalueren welke regeltypen het beste zijn voor uw scenario.

We verkennen deze scenario's verder door te beginnen met het standaardgedrag.

Regeltype #1: Geen back-endpoort hergebruiken

In dit scenario worden de front-ends als volgt geconfigureerd:

Front-end	IP-adres	protocol	poort
1	65.52.0.1	TCP	80
2	65.52.0.2	TCP	80

Het DIP is het doel van de binnenkomende stroom. In de back-endpool toont elke VM de gewenste service op een unieke poort in een DIP. Deze service is gekoppeld aan de front-end via een regeldefinitie.

We definiëren twee regels:

Regel	Front-end van kaart	Naar back-endpool
1	Frontend1:80	DIP1:80, DIP2:80
2	Frontend2:80	DIP1:81, DIP2:81

De volledige toewijzing in Azure Load Balancer is nu als volgt:

Regel	IP-adres voor front-end	protocol	poort	Doel	poort
1	65.52.0.1	TCP	80	DIP IP-adres	80
2	65.52.0.2	TCP	80	DIP IP-adres	81

Elke regel moet een stroom produceren met een unieke combinatie van doel-IP-adres en doelpoort. Door de doelpoort van de stroom te variëren, kunnen meerdere regels stromen leveren aan hetzelfde DIP op verschillende poorten.

Statustests worden altijd omgeleid naar het DIP van een VM. U moet ervoor zorgen dat de test de status van de VM wen.

Regeltype #2: back-endpoort hergebruiken met behulp van zwevend IP

Azure Load Balancer biedt de flexibiliteit om de front-endpoort opnieuw te gebruiken voor meerdere front-ends, ongeacht het gebruikte regeltype. Daarnaast geven sommige toepassingsscenario's de voorkeur aan of vereisen ze dat dezelfde poort wordt gebruikt door meerdere exemplaren van een toepassing op één VM in de back-endpool. Veelvoorkomende voorbeelden waarin een poort opnieuw wordt gebruikt, zijn clustering voor hoge beschikbaarheid, virtuele netwerkapparaten en meerdere TLS-eindpunten beschikbaar maken zonder herversleuteling.

Als u de back-endpoort voor meerdere regels opnieuw wilt gebruiken, moet u Zwevend IP inschakelen in de regeldefinitie.

Zwevend IP is de terminologie van Azure voor een deel van wat Direct Server Return (DSR) wordt genoemd. DSR bestaat uit twee delen: een stroomtopologie en een toewijzingsschema voor IP-adressen. Op platformniveau werkt Azure Load Balancer altijd in een DSR-stroomtopologie, ongeacht of Zwevend IP is ingeschakeld of niet. Dit betekent dat het uitgaande deel van een stroom altijd correct wordt herschreven, zodat deze direct naar de oorsprong terugstroomt.

Met het standaardregeltype maakt Azure een traditioneel toewijzingsschema voor IP-adressen voor taakverdeling beschikbaar voor gebruiksgemak. Als u Zwevend IP inschakelen inschakelen, wordt het toewijzingsschema voor IP-adressen gewijzigd, zodat er meer flexibiliteit mogelijk is, zoals hieronder wordt uitgelegd.

Het volgende diagram illustreert deze configuratie:

Voor dit scenario heeft elke VM in de back-endpool drie netwerkinterfaces:

• DIP: een virtuele NIC die is gekoppeld aan de virtuele machine (IP-configuratie van de NIC-resource van Azure)
• Front-end 1: een loopback-interface binnen het gast-besturingssysteem die is geconfigureerd met het IP-adres van Front-end 1
• Front-end 2: een loopback-interface binnen het gast-besturingssysteem die is geconfigureerd met het IP-adres van Frontend 2

Voer voor elke VM in de back-endpool de volgende opdrachten uit Windows opdrachtprompt.

Typ de volgende opdracht om de lijst met interfacenamen op te halen die u op uw VM hebt:

netsh interface show interface 

Voor de VM-NIC (beheerd door Azure) typt u deze opdracht:

netsh interface ipv4 set interface “interfacename” weakhostreceive=enabled

(vervang interfacename door de naam van deze interface)

Herhaal deze opdrachten voor elke loopback-interface die u hebt toegevoegd:

netsh interface ipv4 set interface “interfacename” weakhostreceive=enabled 

(vervang interfacename door de naam van deze loopback-interface)

netsh interface ipv4 set interface “interfacename” weakhostsend=enabled 

(vervang interfacename door de naam van deze loopback-interface)

Laten we uitgaan van dezelfde front-endconfiguratie als in het vorige scenario:

Front-end	IP-adres	protocol	poort
1	65.52.0.1	TCP	80
2	65.52.0.2	TCP	80

We definiëren twee regels:

Regel	Front-end	Aan back-en-pool toe te staan
1	Frontend1:80	Frontend1:80 (in VM1 en VM2)
2	Frontend2:80	Frontend2:80 (in VM1 en VM2)

In de volgende tabel ziet u de volledige toewijzing in de load balancer:

Regel	IP-adres voor front-end	protocol	poort	Doel	poort
1	65.52.0.1	TCP	80	hetzelfde als front-end (65.52.0.1)	hetzelfde als front-end (80)
2	65.52.0.2	TCP	80	hetzelfde als front-end (65.52.0.2)	hetzelfde als front-end (80)

De bestemming van de binnenkomende stroom is het front-end-IP-adres op de loopback-interface in de VM. Elke regel moet een stroom produceren met een unieke combinatie van doel-IP-adres en doelpoort. Door het doel-IP-adres van de stroom te variëren, is hergebruik van de poort mogelijk op dezelfde VM. Uw service wordt blootgesteld aan de load balancer door deze te binden aan het IP-adres en de poort van de respectieve loopback-interface.

U ziet dat in dit voorbeeld de doelpoort niet wordt gewijzigd. Hoewel dit een zwevend IP-scenario is, ondersteunt Azure Load Balancer ook het definiëren van een regel voor het herschrijven van de back-endbestemmingspoort en om deze te laten verschillen van de front-end-doelpoort.

Het type zwevende IP-regel is de basis van verschillende load balancer configuratiepatronen. Een voorbeeld dat momenteel beschikbaar is, is de configuratie SQL AlwaysOn met meerdere listeners. In de toekomst zullen we meer van deze scenario's documenteren.

Beperkingen

• Meerdere front-endconfiguraties worden alleen ondersteund met IaaS-VM's.
• Met de zwevende IP-regel moet uw toepassing de primaire IP-configuratie gebruiken voor uitgaande SNAT-stromen. Als uw toepassing is gebonden aan het front-end-IP-adres dat is geconfigureerd op de loopback-interface in het gast-besturingssysteem, is de uitgaande SNAT van Azure niet beschikbaar om de uitgaande stroom te herschrijven en mislukt de stroom. Bekijk uitgaande scenario's.
• Zwevend IP wordt momenteel niet ondersteund voor secundaire IP-configuraties voor scenario's met interne taakverdeling.
• Openbare IP-adressen hebben invloed op de facturering. Zie Prijzen van IP-adressen voor meer informatie
• Abonnementslimieten zijn van toepassing. Zie Servicelimieten voor meer informatie.

Volgende stappen

• Bekijk Uitgaande verbindingen om inzicht te krijgen in de impact van meerdere frontends op het gedrag van uitgaande verbindingen.