Hoe Azure Load Balancer werkt

Voltooid

Azure Load Balancer werkt op de transportlaag van het OSI-model. Met deze laag 4-functionaliteit kan verkeerbeheer worden uitgevoerd op basis van specifieke eigenschappen van het verkeer. Eigenschappen, waaronder bron- en doeladres, TCP- of UDP-protocoltype en poortnummer.

Load Balancer heeft verschillende elementen die samenwerken om de hoge beschikbaarheid en prestaties van een toepassing te garanderen:

• Front-end-IP
• Load balancer-regels
• Back-end-pool
• Gezondheidscontroles
• Binnenkomende NAT-regels
• Poorten voor hoge beschikbaarheid
• Regels voor uitgaand verkeer

Front-end IP

Het front-end-IP-adres is het adres dat clients gebruiken om verbinding te maken met uw webtoepassing. Een front-end-IP-adres kan een openbaar of een privé-IP-adres zijn. Azure Load Balancers kunnen meerdere front-end-IP-adressen hebben. De selectie van een openbaar of privé-IP-adres bepaalt welk type load balancer u wilt maken:

• Openbaar IP-adres: Een openbare load balancer: Een openbare load balancer wijst het openbare IP-adres en de poort van binnenkomend verkeer toe aan het privé-IP-adres en de poort van de virtuele machine. U kunt specifieke typen verkeer verdelen over meerdere VM's of services door taakverdelingsregels toe te passen. U kunt bijvoorbeeld het verkeer van webaanvragen over meerdere webservers verdelen. De load balancer wijst het antwoordverkeer van het privé-IP-adres en de poort van de VIRTUELE machine toe aan het openbare IP-adres en de poort van de load balancer. Vervolgens wordt het antwoord teruggestuurd naar de aanvragende client.

• privé-IP-adres: een interne load balancer: een interne load balancer verdeelt verkeer naar resources die zich in een virtueel netwerk bevinden. Azure beperkt de toegang tot de front-end-IP-adressen van een virtueel netwerk met gelijke taakverdeling. Front-end-IP-adressen en virtuele netwerken worden nooit rechtstreeks blootgesteld aan een interneteindpunt. Interne Line-Of-Business-toepassingen worden uitgevoerd in Azure en zijn toegankelijk vanuit Azure of on-premises resources via een VPN- of ExpressRoute-verbinding.

  

Load Balancer-regels

Een load balancer-regel definieert hoe verkeer wordt gedistribueerd naar de back-endpool. De regel wijst een bepaalde front-end-IP- en poortcombinatie toe aan een set back-end-IP-adressen en poortcombinaties.

Verkeer wordt beheerd met behulp van een hash van vijf tuples die is gemaakt op basis van de volgende elementen:

• bron-IP-: het IP-adres van de aanvragende client.
• bronpoort: de poort van de aanvragende client.
• doel-IP-: het doel-IP-adres van de aanvraag.
• doelpoort: de doelpoort van de aanvraag.
• Protocoltype: het opgegeven protocoltype, TCP of UDP.
• sessieaffiniteit: zorgt ervoor dat hetzelfde poolknooppunt altijd verkeer voor een client afhandelt.

Met Load Balancer kunt u services verdelen over meerdere poorten, meerdere IP-adressen of beide. U kunt verschillende taakverdelingsregels configureren voor elk front-end-IP-adres. Meerdere front-endconfiguraties worden alleen ondersteund met IaaS-VM's.

Load Balancer kan geen verschillende regels toepassen op basis van inhoud van intern verkeer, omdat deze werkt op laag 4 (transportlaag) van het OSI-model. Als u verkeer wilt beheren op basis van de laag 7-eigenschappen (toepassingslaag), moet u een oplossing implementeren zoals Azure Application Gateway.

Back-end-pool

De back-end-pool is een groep virtuele machines of instanties in een virtuele-machineschaalset die reageert op de binnenkomende aanvraag. Als u rendabel wilt schalen om te voldoen aan grote hoeveelheden binnenkomend verkeer, raden computingrichtlijnen over het algemeen aan om meer exemplaren toe te voegen aan de back-endpool.

Load Balancer implementeert automatische herconfiguratie om de belasting opnieuw te distribueren over het gewijzigde aantal exemplaren wanneer u exemplaren omhoog of omlaag schaalt. Als u bijvoorbeeld twee vm-exemplaren aan de back-endpool hebt toegevoegd, configureert Load Balancer zichzelf opnieuw om het verkeer naar die exemplaren te verdelen op basis van de reeds geconfigureerde taakverdelingsregels.

Gezondheidscontroles

Er wordt een gezondheidscontrole gebruikt om de status van de instanties in de back-end-pool te bepalen. Deze gezondheidstest bepaalt of een instantie gezond is en verkeer kan ontvangen. U kunt de drempelwaarde voor ongezonde statussen van uw gezondheidstesten definiëren. Wanneer een probe niet reageert, stopt de load balancer met het sturen van nieuwe verbindingen naar de ongezonde exemplaren. Een testfout heeft geen invloed op bestaande verbindingen. De verbinding gaat door tot:

• De toepassing beëindigt het proces.
• Time-out voor inactiviteit vindt plaats.
• De virtuele machine wordt afgesloten.

Met Load Balancer kunt u verschillende statustesttypen configureren voor eindpunten: TCP, HTTP en HTTPS.

• aangepaste TCP-test: deze test is afhankelijk van het tot stand brengen van een geslaagde TCP-sessie op een gedefinieerde testpoort. Als de opgegeven listener op de virtuele machine bestaat, slaagt de test. Als de verbinding wordt geweigerd, mislukt de test. U kunt de poort, het interval en de ongezonde drempelwaarde opgeven.
• aangepaste HTTP- of HTTPS-test: de load balancer test regelmatig uw eindpunt (standaard elke 15 seconden). Het exemplaar is in orde als het reageert met een HTTP 200 binnen de time-outperiode (standaard 31 seconden). Elke andere status dan HTTP 200 zorgt ervoor dat de test mislukt. U kunt de poort (poort), de URI opgeven om de status van de back-end op te vragen (URI), de tijdsduur tussen testpogingen (interval) en het aantal mislukte pogingen dat moet optreden voordat het exemplaar als ongezond wordt beschouwd (drempelwaarde voor ongezonde status).

Sessiepersistentie

Load Balancer verdeelt standaard netwerkverkeer gelijkmatig over meerdere VM-exemplaren. Het biedt stickiness alleen binnen een transportsessie. Sessiepersistentie geeft aan hoe verkeer van een client moet worden verwerkt. Het standaardgedrag (Geen) is dat elke vm die in orde is, opeenvolgende aanvragen van een client kan verwerken.

Sessiepersistentie wordt ook wel sessieaffiniteit, bron-IP-affiniteit of client-IP-affiniteit genoemd. In deze distributiemodus wordt een hash met twee tuples (bron-IP en doel-IP) of drie tuples (bron-IP, doel-IP en protocoltype) gebruikt om naar back-endexemplaren te routeren. Wanneer u sessiepersistentie gebruikt, gaan verbindingen van dezelfde client naar hetzelfde back-endexemplaar binnen de back-endpool. U kunt een van de volgende opties voor sessiepersistentie configureren:

• Geen (standaard): hiermee geeft u op dat elke vm die in orde is, de aanvraag kan verwerken.
• client-IP (2-tuple): hiermee geeft u op dat dezelfde back-endinstantie opeenvolgende aanvragen van hetzelfde client-IP-adres kan verwerken.
• Client-IP en protocol (3-tuple): geeft aan dat hetzelfde back-endexemplaar opeenvolgende aanvragen van dezelfde client-IP-adres en protocolcombinatie kan verwerken.

U kunt dit gedrag wijzigen door een van de opties te configureren die in de volgende secties worden beschreven.

Poorten voor hoge beschikbaarheid

Een load balancer-regel die is geconfigureerd met protocol - all and port - 0 wordt een poortregel voor hoge beschikbaarheid (HA)genoemd. Met deze regel kan één regel alle TCP- en UDP-stromen verdelen die op alle poorten van een interne standaard load balancer binnenkomen.

De taakverdelingsbeslissing wordt per stroom genomen. Deze actie is gebaseerd op de volgende vijf tuple-verbindingen:

• Bron-IP-adres
• Bronpoort
• Doel-IP-adres
• Doelpoort
• Protocol

Taakverdelingsregels voor ha-poorten helpen u bij kritieke scenario's, zoals hoge beschikbaarheid en schaal voor virtuele netwerkapparaten (NVA's) in virtuele netwerken. De functie kan helpen wanneer een groot aantal poorten moet worden gebalanceerd.

Binnenkomende NAT-regels

U kunt taakverdelingsregels gebruiken in combinatie met NAT-regels (Network Address Translation). U kunt bijvoorbeeld NAT van het openbare adres van de load balancer gebruiken naar TCP 3389 op een specifieke VM. Met deze regelcombinatie is het mogelijk om externe bureaubladtoegang van buiten Azure te hebben.

Regels voor uitgaand verkeer

Een uitgaande regel configureert SNAT (Source Network Address Translation) voor alle VM's of exemplaren die worden geïdentificeerd door de back-endpool. Met deze regel kunnen exemplaren in de back-end communiceren (uitgaand) naar internet of andere openbare eindpunten.