Hoe Azure Load Balancer werkt
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
- Regels voor load balancers
- Back-endgroep
- Statuscontroles
- Inkomende NAT-regels
- Poorten voor hoge beschikbaarheid
- Uitgaande regels
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. Door het toepassen van regels voor taakverdeling, kunt u specifieke soorten verkeer verdelen voor meerdere virtuele machines of services. U kunt bijvoorbeeld de werkbelasting door webverkeeraanvragen over meerdere webservers spreiden. 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 distribueert 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 communiceren nooit rechtstreeks met 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-toepassing Gateway.
Back-endgroep
De back-endpool is een groep virtuele machines of exemplaren 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.
Statuscontroles
Er wordt een statustest gebruikt om de status van de exemplaren in de back-endpool te bepalen. Deze statustest bepaalt of een exemplaar in orde is en verkeer kan ontvangen. U kunt de drempelwaarde onjuiste status voor de statuscontroles definiëren. Wanneer een test niet reageert, stopt de load balancer met het verzenden van nieuwe verbindingen naar de slechte instanties. Een controlefout heeft geen invloed op bestaande verbindingen. De verbinding gaat door tot:
- De toepassing beëindigt de stroom.
- 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 drempelwaarde voor poort, interval en onjuiste status 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 voor het aanvragen van de status van de back-end (URI), de hoeveelheid tijd tussen testpogingen (interval) en het aantal mislukte pogingen dat moet optreden voor het exemplaar als beschadigd (drempelwaarde voor beschadigde 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-endexemplaren in de back-endpool. U kunt een van de volgende opties voor sessiepersistentie configureren:
- Geen (standaardinstelling): hiermee geeft u op dat elke vm die in orde is, de aanvraag kan verwerken.
- Client-IP (2-tuple): hiermee geeft u op dat hetzelfde back-endexemplaren opeenvolgende aanvragen van hetzelfde client-IP-adres kunnen verwerken.
- Client-IP en protocol (3-tuple): hiermee geeft u op dat hetzelfde back-endexemplaren opeenvolgende aanvragen van dezelfde client-IP-adres en protocolcombinatie kunnen 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 metprotocol - all and port - 0, wordt een poortregel met 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.
Er wordt per stroom een beslissing voor taakverdeling gemaakt. Deze actie is gebaseerd op de volgende vijf-tupleverbinding:
- IP-adres van bron
- Bronpoort
- IP-adres van doel
- 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 taakverdeling moet hebben.
Inkomende 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 extern bureaublad toegang mogelijk van buiten Azure.
Uitgaande regels
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.
