Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Azure Load Balancer ondersteunt de volgende distributiemodi voor het routeren van verbindingen met exemplaren in de back-endpool:
| Distributiemodus | Hash-gebaseerd | Sessiepersistentie: Client IP | Sessiepersistentie: Client-IP en protocol |
|---|---|---|---|
| Overzicht | Verkeer van hetzelfde client-IP-adres dat is gerouteerd naar een goed functionerend exemplaar in de back-endpool | Verkeer van hetzelfde client-IP-adres wordt doorgestuurd naar dezelfde back-endinstantie. | Verkeer van hetzelfde client-IP en protocol wordt gerouteerd naar hetzelfde back-endexemplaar. |
| Tuples | vijfvoud | twee-tupel | drietupel |
| Configuratie van Azure Portal | Sessiepersistentie: Geen | Sessiepersistentie: CLIENT-IP | Sessiepersistentie: CLIENT-IP en protocol |
| REST API | "loadDistribution":"Default" |
"loadDistribution":SourceIP |
"loadDistribution":SourceIPProtocol |
Er is geen downtime bij het overschakelen van de ene distributiemodus naar een andere op een load balancer.
Hash-gebaseerd
Azure Load Balancer maakt standaard gebruik van een distributiemodus op basis van vijf tuple-hashs.
Het vijftal bestaat uit:
- Bron-IP
- Bronpoort
- Bestemmings-IP
- Doelpoort
- Protocoltype
De hash wordt gebruikt om verkeer te routeren naar gezonde backend-instanties binnen de backendpool. Het algoritme biedt alleen stickiness binnen een transportsessie. Wanneer de client een nieuwe sessie start vanaf hetzelfde bron-IP-adres, wordt de bronpoort gewijzigd en wordt het verkeer naar een ander back-endexemplaren verzonden.
Als u hash-distributie wilt configureren, moet u sessiepersistentie selecteren om Geen te zijn in de Azure-portal. Hiermee geeft u op dat opeenvolgende aanvragen van dezelfde client kunnen worden verwerkt door elke virtuele machine.
Notitie
Wanneer er beperkte variatie is in bron-IP-adressen en poorten, beschikt de load balancer mogelijk niet over voldoende afzonderlijke stroominformatie om verkeer gelijkmatig over back-ends te verdelen. In scenario's waarin tussenliggende apparaten (zoals firewalls die SNAT uitvoeren) het aantal zichtbare bron-IP-adressen verminderen en bronpoorten toewijzen in voorspelbare patronen, kan de beschikbare variatie in verkeersstromen aanzienlijk beperkt zijn, met name wanneer verkeer afkomstig is van een klein aantal clients. Dit kan leiden tot een zeer scheve of helemaal geen verdeling over backend-instanties. Als u een ongelijke verdeling ondervindt, vergroot u het aantal clients dat verkeer via het tussenliggende apparaat verzendt, of probeert u het aantal instanties van het tussenliggende apparaat of back-ends van de load balancer aan te passen om de hashsymmetrie te doorbreken.
Sessiepersistentie
Sessiepersistentie is ook bekend sessieaffiniteit, bron-IP-affiniteit of client-IP-affiniteit. 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, worden verbindingen van dezelfde client naar dezelfde back-endinstantie in de back-endgroep doorgestuurd.
De sessie-persistentiemodus heeft twee configuratietypen:
Client IP (2-tuple) - Geeft aan dat opeenvolgende verzoeken van hetzelfde client-IP-adres worden verwerkt door hetzelfde back-endexemplaar.
Client-IP en protocol (3-tuple): geeft aan dat opeenvolgende aanvragen van hetzelfde client-IP-adres en dezelfde protocolcombinatie worden verwerkt door hetzelfde back-endexemplaar.
In de volgende afbeelding ziet u een configuratie met twee tuples. U ziet hoe de twee tuples via de load balancer worden uitgevoerd naar virtuele machine 1 (VM1). VM1 wordt ondersteund door VM2 en VM3.
Gebruiksgevallen
Bron-IP-affiniteit met client-IP en protocol (bron-IP-affiniteit met drie tuples), lost een incompatibiliteit op tussen Azure Load Balancer en Extern bureaublad-gateway (RD Gateway).
Een ander gebruiksgevalscenario is het uploaden van media. Het uploaden van gegevens vindt plaats via UDP, maar het besturingsvlak wordt bereikt via TCP:
- Een client start een TCP-sessie naar het openbare adres met gelijke taakverdeling en wordt omgeleid naar een specifiek DIP. Het kanaal blijft actief om de verbindingsstatus te bewaken.
- Er wordt een nieuwe UDP-sessie van dezelfde clientcomputer gestart met hetzelfde openbare eindpunt met gelijke taakverdeling. De verbinding wordt omgeleid naar hetzelfde DIP-eindpunt als de vorige TCP-verbinding. Het uploaden van media kan worden uitgevoerd met een hoge doorvoer terwijl een besturingskanaal via TCP wordt onderhouden.
Notitie
Wanneer leden van de back-endpool van Load Balancer worden gewijzigd door een virtuele machine te verwijderen of toe te voegen, wordt de distributie van clientaanvragen opnieuw berekend. U kunt niet afhankelijk zijn van nieuwe verbindingen van bestaande clients om op dezelfde server te eindigen. Daarnaast kan het gebruik van de distributiemodus voor bron-IP-affiniteit een ongelijke verdeling van het verkeer veroorzaken. Clients die achter proxy's draaien, kunnen worden gezien als één unieke klanttoepassing.