Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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
- Quell-Port
- Ziel-IP
- Ziel-Port
- 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.
Hinweis
Wenn es eine begrenzte Variation von Quell-IP-Adressen und Ports gibt, verfügt das Lastenausgleichsmodul möglicherweise nicht über genügend unterschiedliche Flussinformationen, um Datenverkehr gleichmäßig über Back-Ends zu verteilen. In Szenarien, in denen Zwischengeräte (z. B. Firewalls, die SNAT ausführen) die Anzahl der sichtbaren Quell-IP-Adressen reduzieren und Quellports in vorhersagbaren Mustern zuweisen, kann die verfügbare Variation von Datenverkehrsflüssen erheblich eingeschränkt werden, insbesondere, wenn datenverkehr aus einer kleinen Anzahl von Clients stammt. Dies kann zu einer stark unausgewogenen oder gar zu keiner Verteilung auf Backend-Instanzen führen. Wenn eine ungleiche Verteilung auftritt, erhöhen Sie die Anzahl der Clients, die Datenverkehr über das Zwischengerät senden, oder versuchen Sie, die Anzahl der Zwischengeräteinstanzen oder Lastenausgleichs-Back-Ends anzupassen, um die Hashingsymmetrie zu unterbrechen.
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.
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.