Verteilungsmodi von Azure Load Balancer

  • Artikel

Azure Load Balancer unterstützt die folgenden Verteilungsmodi für Routingverbindungen zu Instanzen im Back-End-Pool:

Verteilungsmodi Hashbasiert Sitzungs-Persistenz: Client-IP Sitzungs-Persistenz: Client-IP und Protokoll
Überblick Datenverkehr von der gleichen Client-IP, der an eine fehlerfreie Instanz im Back-End-Pool weitergeleitet wird Datenverkehr von derselben Client-IP wird an dieselbe Back-End-Instanz weitergeleitet. Datenverkehr von derselben Client-IP und Protokoll werden an dieselbe Back-End-Instanz weitergeleitet.
Tupel fünf Tupel zwei Tupel drei Tupel
Konfiguration des Azure-Portals Sitzungspersistenz: Keine Sitzungs-Persistenz: Client-IP Sitzungs-Persistenz: Client-IP und Protokoll
REST-API "loadDistribution":"Default" "loadDistribution":SourceIP "loadDistribution":SourceIPProtocol

Beim Wechsel von einem Verteilungsmodus zu einem anderen mit einem Lastenausgleich gibt es keine Ausfallzeiten.

Hashbasiert

Azure Load Balancer verwendet standardmäßig einen hashbasierten Verteilungsmodus mit fünf Tupeln.

Das 5-Tupel besteht aus den folgenden Elementen:

  • Quell-IP
  • Quellport
  • Ziel-IP
  • Zielport
  • Protokolltyp

Der Hash wird verwendet, um Datenverkehr an fehlerfreie Back-End-Instanzen innerhalb des Back-End-Pools weiter zu routen. Der Algorithmus stellt Bindung nur innerhalb einer Transportsitzung bereit. Wenn der Client eine neue Sitzung über die gleiche Quell-IP startet, wird der Quellport geändert, wodurch der Datenverkehr an eine andere Back-End-Instanz geleitet wird.

Um eine hashbasierte Verteilung zu konfigurieren, müssen Sie „Sitzungspersistenz“ im Azure-Portal auf Keine setzen. Dadurch wird angegeben, dass aufeinander folgende Anforderungen des gleichen Clients von jedem virtuellen Computer verarbeitet werden können.

Abbildung des hashbasierten Fünf-Tupel-Standardverteilungsmodus mit VMs

Sitzungspersistenz

Sitzungspersistenz ist auch bekannte Sitzungsaffinität, Quell-IP-Affinität oder Client-IP-Affinität. Der Modus verwendet einen Zwei-Tupel-Hash (Quell-IP und Ziel-IP) oder Drei-Tupel-Hash (Quell-IP, Ziel-IP und Protokolltyp) um zu Back-End-Instanzen weiterzuleiten. Bei Verwendung der Sitzungspersistenz gehen die Verbindungen desselben Clients zur selben Back-End-Instanz innerhalb des Back-End-Pools.

Es gibt zwei Konfigurationstypen für den Sitzungspersistenzmodus:

  • Client-IP-Adresse (zwei Tupel): Gibt an, dass aufeinanderfolgende Anforderungen von derselben Client-IP-Adresse von derselben Back-End-Instanz bearbeitet werden.
  • Client-IP-Adresse und Protokoll (drei Tupel):Gibt an, dass aufeinanderfolgende Anforderungen von derselben Kombination aus Client-IP-Adresse und Protokoll von derselben Back-End-Instanz bearbeitet werden.

Die folgende Abbildung veranschaulicht eine Konfiguration mit zwei Tupeln. Beachten Sie, wie der Zwei-Tupel-Hash durch den Lastenausgleich zum ersten virtuellen Computer (VM1) führt. VM1 wird durch VM2 und VM3 abgesichert.

Verteilungsmodus „Zwei-Tupel-Sitzungsaffinität“

Anwendungsfälle

Mit dem Modus „Quell-IP-Affinität“ mit Client-IP-Adresse und Protokoll (Quell-IP-Affinität, drei Tupel) wird das Problem der Inkompatibilität zwischen Azure Load Balancer und Remotedesktopgateway (RD-Gateway) gelöst.

Ein weiterer Anwendungsfall ist das Hochladen von Medien. Der Datenupload erfolgt über UDP, während die Steuerungsebene über TCP realisiert wird:

  • Ein Client startet eine TCP-Sitzung zur öffentlichen Adresse mit Lastenausgleich und wird zu einer bestimmten DIP-Adresse geleitet. Der Kanal bleibt zur Überwachung der Verbindungsintegrität aktiv.
  • Es wird eine neue UDP-Sitzung vom gleichen Clientcomputer zum gleichen öffentlichen Endpunkt mit Lastenausgleich gestartet. Die Verbindung wird zum gleichen DIP-Endpunkt wie bei der vorherigen TCP-Verbindung geleitet. Das Hochladen von Medien kann mit hohem Durchsatz erfolgen, während gleichzeitig ein Steuerkanal über TCP betrieben wird.

Hinweis

Wenn sich die Mitglieder des Load Balancer-Back-End-Pools ändern, indem entweder ein virtueller Computer entfernt oder hinzugefügt wird, wird die Verteilung der Clientanforderungen neu verteilt. Sie können sich nicht darauf verlassen, dass neue Verbindungen von vorhandenen Clients beim gleichen Server landen. Darüber hinaus kann die Verwendung des Quell-IP-Affinitäts-Verteilungsmodus zu einer ungleichen Verteilung des Datenverkehrs führen. Clients, die hinter Proxys ausgeführt werden, können als eine einzige Clientanwendung betrachtet werden.

Nächste Schritte

Weitere Informationen zum Konfigurieren des Verteilungsmodus von Azure Load Balancer finden Sie unter Konfigurieren des Verteilungsmodus für Azure Load Balancer.