Azure Load-Balancer: Lastverteilung für Cloud-Dienste und virtuelle Maschinen

In größeren On-Prem-Infrastrukturen werden dafür bevorzugt Hardware-Appliances eingesetzt, meist in einer HA-Konfiguration. Doch auch innerhalb Azure kann man ein Load-Balancing einrichten.

Microsoft Azure Load-Balancer

Der Azure Load-Balancer arbeitet auf Layer-4 (L4) des OSI-Stacks. Wer dieses Modell nicht vor Augen hat, L4 ist die Transport­schicht (Transport Layer). Dort operieren das verbindungs­orientierte TCP-Protokoll und das verbindungs­lose UDP.

Azure Load-Balancer arbeiten somit nicht auf dem Application Layer-7 (L7) und verstehen daher Protokolle wie HTTP oder HTTPS nicht. Wer eine solche Anforderung hat, wird beim Azure Application Gateway fündig. Das Arbeiten auf dem simpleren L4 benötigt weniger Ressourcen, bietet zudem großen Durchsatz und geringe Latenzen.

Fähigkeiten von Azures Lastenausgleich

Der Datenverkehr wird auf Basis eines Hash-basierten Verteilungs­algorithmus zugeordnet. Standard­mäßig kommt hier ein 5-Tuple-Hash zum Einsatz. Dieser berücksichtigt die Quell-IP, den Quell-Port, Ziel-IP, Ziel-Port und den Protokoll-Typ.

Ändert sich zum Beispiel der Quell-Port bei einer erneuten Verbindung, dann leitet der Load-Balancer dement­sprechend auch wieder an einen anderen Endpoint weiter. Der Verteilmodus lässt sich in Richtung 2-Tupel (Quell-IP und Ziel-IP) oder 3-Tupel (Quell-IP, Ziel-IP und Protokoll-Typ) über das Az-Modul von Azure PowerShell ändern und bietet dann Affinität.

Ein guter Load-Balancer prüft zudem, ob die dahinter­liegenden Dienste generell erreichbar sind, bevor die Anfragen verteilt werden. Ist der Server im Backend-Pool samt Dienst down, vielleicht nur zu Wartungs­zwecken, macht es keinen Sinn, ihm weitere Anfragen durch­zureichen. Azure Load-Balancer verwendet dafür Health Probes.

Zudem lässt sich der Backend-Server-Pool dynamisch erweitern, so dass der Traffic automatisch auf neue Server verteilt wird.

Anwendungsgebiete

Die Anwendungen eines Azure Load-Balancer können je nach Anforderung unterschiedlich sein. Zum einen ist es möglich, diesen für den öffentlichen Internet-Verkehr zu verwenden, zum anderen für ein internes virtuelles Azure-Netzwerk.

Der öffentliche Load-Balancer (Public LB) leitet beispielsweise die Anfragen an eine statische öffentliche IP und Anfragen auf Port 443 zu den entsprechenden virtuellen Web-Server-Instanzen weiter.

Intern kann man dann über eine optionale Ebene die Last auf einen Pool aus Datenbank-Servern verteilen. In einer hybriden Infrastruktur können On-prem-Systeme über einen Azure Load-Balancer auf VMs des gleichen virtuellen Netzwerkes zugreifen.

Basic- oder Standard-Version

Azure Load-Balancer lassen sich in zwei Versionen wählen, die SKU-Bezeichnungen lauten hier Basic (kostenlos) und Standard. Möchten Sie die möglichen Kosten für den Einsatz der Standard-Version überschlagen, hilft wie so oft der Azure Calculator. Die Features der Units unterscheiden sich wie folgt:

Basic

• Support für bis zu 100 Instanzen im Backend-Pool
• Backend-Pool-Endpunkte: VMs in einem einzelnen Verfügbarkeits-Set oder VM-Scale-Set
• Health Probes für TCP und HTTP
• Verfügbarkeitszonen stehen nicht zur Verfügung
• Diagnose: Azure Log Analytics für öffentliche LB, Backend-Pool Health Count und SNAT, Erschöpfungs-Warnung
• HA-Ports nicht verfügbar
• Standard-Sicherheit: geöffnet, NSG optional
• Ausgehende Verbindungen: Ein einzelnes Frontend, zufällig gewählt, wird unterstützt, wenn mehrere vorhanden sind. Wenn nur der interne LB eine VM, Verfügbarkeits-Set oder Scale-Set bedient, wird standardmäßig SNAT verwendet.
• TCP Reset (TCP RST) bei Leerlauf steht nicht zur Verfügung
• Mehrere Frontends, nur eingehend
• Verwaltungs-Operationen typisch bei 60 bis 90+ Sekunden
• SLA nicht verfügbar

Standard:

• Support für bis zu 1000 Instanzen im Backend-Pool
• Backend-Pool-Endpunkte: Jegliche VM in einzelnen virtuellen Netzwerken, Verfügbarkeits- oder Scale-Sets
• Health Probes für TCP, HTTP und HTTPS
• Verfügbarkeitszonen: zonen­redundanter, zonen­übergreifender Lasten­aus­gleich
• Diagnose: Azure Monitor, multi-dimensionale Metriken inklusive Byte- und Paketzähler, Health Probe
• Status: TCP SYN, Integrität ausgehender Verbindungen, aktive Daten-Ebene Messungen
• HA Ports für interne Load-Balancer
• Standard-Sicherheit: Öffentliche IPs, öffentliche LB-Endpunkte und interne Endpunkte sind für eingehenden Datenfluss gesperrt, sofern sie nicht in einer NSG auf die Whitelist gesetzt werden.
• Ausgehende Verbindungen: Es kann Pool-basiertes ausgehendes NAT mit ausgehenden Regeln definiert werden. Mehrere Frontends mit Opt-out-Funktion lassen sich für Lastaus­gleichsregeln verwenden. Für VMs, Verfügbarkeits-Set, VM-Scale-Set muss explizit ein Ausgangs­szenario erstellt werden, um ausgehende Konnektivität zu verwenden.
• TCP Reset (TCP RST) bei Leerlauf für jegliche Regel
• Mehrere Frontends, ein- und ausgehend
• Verwaltungs-Operationen meist bei < 30 Sekunden
• SLA 99,99% bei einem Datenpfad zu zwei intakten VMs