Funktionsweise von Azure Load Balancer

  • 5 Minuten

Azure Load Balancer wird in der Transportschicht des OSI-Modells verwendet. Diese Funktionalität der 4. Schicht ermöglicht die Datenverkehrsverwaltung basierend auf bestimmten Eigenschaften des Datenverkehrs. Eigenschaften, einschließlich Quell- und Zieladresse, TCP- oder UDP-Protokolltyp und Portnummer.

Load Balancer umfasst mehrere Elemente, die zusammenarbeiten, um die Hochverfügbarkeit und Leistung einer Anwendung sicherzustellen:

  • Front-End-IP
  • Lastenausgleichsregeln
  • Back-End-Pool
  • Integritätstests
  • Eingehende NAT-Regeln
  • Hochverfügbarkeitsports
  • Ausgangsregeln

Front-End-IP

Die Front-End-IP-Adresse ist die Adresse, die von Clients verwendet wird, um eine Verbindung mit Ihrer Webanwendung herstellen. Eine Front-End-IP-Adresse kann entweder eine öffentliche oder eine private IP-Adresse sein. Azure Load Balancer-Instanzen können über mehrere Front-End-IP-Adressen verfügen. Die Auswahl einer öffentlichen oder privaten IP-Adresse bestimmt, welcher Lastenausgleichstyp erstellt wird:

  • Öffentliche IP-Adresse: Ein öffentlicher Lastenausgleich: Bei einem öffentlichen Lastenausgleich werden die öffentliche IP-Adresse und der Port des eingehenden Datenverkehrs der privaten IP-Adresse und dem Port des virtuellen Computers zugeordnet. Sie können bestimmte Typen von Datenverkehr auf verschiedene VMs oder Dienste verteilen, indem Sie Lastenausgleichsregeln anwenden. Sie können zum Beispiel die Netzwerklast von Webanforderungen auf mehrere Webserver verteilen. Der Lastenausgleich ordnet den Antwortdatenverkehr von der privaten IP-Adresse und dem Port des virtuellen Computers der öffentlichen IP-Adresse und dem Port des Lastenausgleichs zu. Anschließend wird die Antwort zurück an den anfordernden Client übermittelt.

  • Private IP-Adresse: Ein interner Lastenausgleich: Ein interner Lastenausgleich verteilt Datenverkehr an Ressourcen, die sich in einem virtuellen Netzwerk befinden. Azure schränkt den Zugriff auf die Front-End-IP-Adressen eines virtuellen Netzwerks ein, für die ein Lastenausgleich vorgenommen wird. Front-End-IP-Adressen und virtuelle Netzwerke werden nie direkt für einen Internetendpunkt verfügbar gemacht. Interne Branchenanwendungen werden in Azure ausgeführt. Auf sie wird über Azure oder von lokalen Ressourcen aus über eine VPN- oder eine ExpressRoute-Verbindung zugegriffen.

    Diagram that depicts how public and internal load balancers work in Azure Load Balancer.

Load Balancer-Regeln

Mit einer Lastenausgleichsregel wird definiert, wie Datenverkehr auf den Back-End-Pool verteilt wird. Die Regel ordnet einer Kombination aus den IP-Adressen und dem Port des Back-Ends eine bestimmte Kombination aus der IP-Adresse und dem Ports des Front-Ends zu.

Diagram that depicts how load balancer rules work in Azure Load Balancer.

Der Datenverkehr wird mithilfe eines 5-Tupel-Hashs verwaltet, der aus den folgenden Elementen erstellt wurde:

  • Quell-IP: Dies ist die IP-Adresse des anfordernden Clients.
  • Quellport: Dies ist der Port des anfordernden Clients.
  • Ziel-IP: Dies ist die Ziel-IP-Adresse der Anforderung.
  • Zielport: Dies ist der Zielport der Anforderung.
  • Protokolltyp: Der angegebene Protokolltyp TCP oder UDP.
  • Sitzungsaffinität: Stellt sicher, dass immer derselbe Poolknoten den Datenverkehr für einen Client verarbeitet.

Mit Load Balancer können Sie Lastenausgleiche für Dienste an mehreren Ports oder im Zusammenhang mit mehreren IP-Adressen bzw. beidem vornehmen. Sie können unterschiedliche Lastenausgleichsregeln für jede Front-End-IP-Adresse konfigurieren. Konfigurationen mit mehreren Front-Ends werden nur für IaaS-VMs unterstützt.

Load Balancer kann keine anderen Regeln basierend auf internen Datenverkehrsinhalten anwenden, da er auf Schicht 4 (Transportschicht) des OSI-Modells ausgeführt wird. Wenn Sie Datenverkehr basierend auf den Eigenschaften von Schicht 7 (Anwendungsschicht) verwalten müssen, müssen Sie eine Lösung wie Azure Application Gateway bereitstellen.

Back-End-Pool

Der Back-End-Pool ist eine Gruppe von VMs oder Instanzen in einer VM-Skalierungsgruppe, die auf die eingehende Anforderung reagieren. Für eine kosteneffiziente Skalierung zur Bewältigung großer Mengen an eingehendem Datenverkehr empfiehlt es sich in der Regel, dem Back-End-Pool weitere Instanzen hinzuzufügen.

Load Balancer implementiert eine automatische Neukonfiguration, um die Last auf die geänderte Anzahl von Instanzen zu verteilen, wenn Sie Instanzen hoch- oder herunterskalieren. Wenn Sie dem Back-End-Pool beispielsweise zwei weitere VM-Instanzen hinzufügen würden, würde Load Balancer sich neu konfigurieren, um basierend auf den bereits konfigurierten Lastenausgleichsregeln mit dem Lastenausgleich für den Datenverkehr dieser Instanzen zu beginnen.

Integritätstests

Mithilfe eines Integritätstest wird der Integritätsstatus der Instanzen im Back-End-Pool ermittelt. Dieser Integritätstest bestimmt, ob eine Instanz fehlerfrei ist und Datenverkehr empfangen kann. Sie können den gewünschten Fehlerschwellenwert für Ihre Integritätstests definieren. Wenn ein Test nicht reagiert, beendet der Load Balancer das Senden neuer Verbindungen an die fehlerhaften Instanzen. Ein Testfehler wirkt sich nicht auf vorhandene Verbindungen aus. Die Verbindung wird fortgesetzt, bis:

  • Die Anwendung den Flow beendet.
  • Auftreten eines Leerlauftimeouts
  • Herunterfahren der VM

Load Balancer ermöglicht Ihnen das Konfigurieren unterschiedlicher Integritätstesttypen für Endpunkte: TCP, HTTP und HTTPS.

  • Benutzerdefinierter TCP-Test: TCP-Tests basieren auf der erfolgreichen Einrichtung von TCP-Sitzungen an einem definierten Testport. Solange der angegebene Listener auf der VM vorhanden ist, ist dieser Test erfolgreich. Wenn die Verbindung abgelehnt wird, schlägt der Test fehl. Sie können den Port, das Intervall und den Fehlerschwellenwert angeben.
  • Benutzerdefinierter HTTP- oder HTTPS-Test: Der Lastenausgleich testet Ihren Endpunkt regelmäßig (standardmäßig alle 15 Sekunden). Die Instanz ist fehlerfrei, wenn sie innerhalb des Zeitlimits (standardmäßig 31 Sekunden) mit einem HTTP-Code 200 antwortet. Bei jedem anderen Status als HTTP 200 schlägt der Test fehl. Sie können den Port („Port“), den URI zum Anfordern des Integritätsstatus vom Back-End („URI“), die Zeitspanne zwischen Testversuchen („Intervall“) und die Anzahl der Fehler angeben, die auftreten müssen, damit die Instanz als fehlerhaft betrachtet wird („Fehlergrenzwert“).

Sitzungspersistenz

Standardmäßig verteilt Load Balancer Netzwerkdatenverkehr gleichmäßig auf mehrere VM-Instanzen. Dabei wird Bindung nur in einer Transportsitzung angeboten. Die Sitzungspersistenz gibt an, wie Datenverkehr von einem Client verarbeitet werden soll. Das Standardverhalten („Keine“) ist, dass aufeinanderfolgende Anforderungen eines Clients von jeder fehlerfreien VM verarbeitet werden können.

Die Sitzungspersistenz wird auch als Sitzungsaffinität, Quell-IP-Affinität oder Client-IP-Affinität bezeichnet. Bei diesem Verteilungsmodus wird ein Zwei-Tupel-Hash (Quell-IP-Adresse und Ziel-IP-Adresse) oder Drei-Tupel-Hash (Quell-IP-Adresse, Ziel-IP-Adresse und Protokolltyp) verwendet, um den Datenverkehr an die Back-End-Instanzen weiterzuleiten. Bei Verwendung der Sitzungspersistenz werden Verbindungen vom selben Client an dieselbe Back-End-Instanz innerhalb des Back-End-Pools weitergeleitet. Sie können eine der folgenden Sitzungspersistenzoptionen konfigurieren:

  • Keine (Standard): Hiermit wird angegeben, dass jede fehlerfreie VM die Anforderung verarbeiten kann.
  • Client-IP (2 Tupel): Hiermit wird angegeben, dass aufeinanderfolgende Anforderungen von derselben Client-IP-Adresse in derselben Back-End-Instanz verarbeitet werden.
  • Client-IP und Protokoll (3 Tupel): Hiermit wird angegeben, dass aufeinanderfolgende Anforderungen von derselben Kombination aus Client-IP-Adresse und Protokoll in derselben Back-End-Instanz verarbeitet werden.

Sie können dieses Verhalten ändern, indem Sie eine der in den folgenden Abschnitten beschriebenen Optionen konfigurieren.

Hochverfügbarkeitsports

Eine Lastenausgleichsregel, die mithilfe von protocol - all and port - 0 konfiguriert wurde, wird als Regel für Hochverfügbarkeitsports (High Availability, HA) bezeichnet. Diese Regel ermöglicht es, dass eine einzige Regel den Lastenausgleich aller TCP- und UDP-Datenflüsse vornimmt, die an allen Ports einer internen Load Balancer Standard-Instanz eingehen.

Die Entscheidung über den Lastenausgleich erfolgt pro Datenfluss. Diese Lösung basiert auf der folgenden Verbindung mit fünf Tupeln:

  • Quell-IP-Adresse
  • Quellport
  • IP-Zieladresse
  • Zielport
  • Protokoll

Die Lastenausgleichsregeln für Hochverfügbarkeitsports unterstützen Sie bei wichtigen Szenarios (z. B. Hochverfügbarkeit und Skalierung für virtuelle Netzwerkgeräte in virtuellen Netzwerken). Das Feature kann hilfreich sein, wenn für eine große Anzahl von Ports ein Lastenausgleich vorgenommen werden muss.

Diagram that shows how high availability ports work in Azure Load Balancer.

Eingehende NAT-Regeln

Sie können Lastenausgleichsregeln in Kombination mit NAT-Regeln (Network Address Translation) verwenden. Beispielsweise können Sie die NAT der öffentlichen Adresse des Lastenausgleichs zu TCP 3389 auf einem bestimmten virtuellen Computer verwenden. Diese Regelkombination ermöglicht einen Remotedesktopzugriff von außerhalb von Azure.

Diagram that shows how inbound NAT rules work in Azure Load Balancer.

Ausgangsregeln

Eine Ausgangsregel konfiguriert die Quellnetzwerkadressenübersetzung (Source Network Address Translation, SNAT) für alle VMs oder Instanzen, die vom Back-End-Pool identifiziert werden. Durch diese Regel können Instanzen im Back-End (ausgehend) mit dem Internet oder anderen öffentlichen Endpunkten kommunizieren.

Diagram that shows how outbound rules work in Azure Load Balancer.