Tags: Azure, Hochverfügbarkeit, Load Balancing
Eingehende TCP-Anfragen von stark genutzten Anwendungen werden on-prem meist über Hardware-Load-Balancer auf mehrere Backend-Systeme verteilt. Auch für Traffic nach und in Azure lässt sich eine Lastverteilung mit Load-Balancern (LB) konfigurieren. Azure LB gewährleistet zudem die Verfügbarkeit der Dienste.
Load-Balancer als erster Anlaufpunkt verteilen die Last der Anfragen an dahinterliegende Dienste wie IIS-Server oder Exchange. Das soll Server-Farmen gleichmäßig beanspruchen, für Hochverfügbarkeit gegenüber Clients sorgen und die Performance verbessern.
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 Transportschicht (Transport Layer). Dort operieren das verbindungsorientierte TCP-Protokoll und das verbindungslose 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 Verteilungsalgorithmus zugeordnet. Standardmäß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 dementsprechend 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 dahinterliegenden Dienste generell erreichbar sind, bevor die Anfragen verteilt werden. Ist der Server im Backend-Pool samt Dienst down, vielleicht nur zu Wartungszwecken, macht es keinen Sinn, ihm weitere Anfragen durchzureichen. 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: zonenredundanter, zonenübergreifender Lastenausgleich
- 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 Lastausgleichsregeln verwenden. Für VMs, Verfügbarkeits-Set, VM-Scale-Set muss explizit ein Ausgangsszenario 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
Täglich Know-how für IT-Pros mit unserem Newsletter
Marcel Küppers arbeitet seit über 25 Jahren in der IT, aktuell als Team Leader, zuvor als Consultant und Infrastructure Architect unter anderem für den japanischen Konzern JTEKT/TOYODA mit Verantwortung über die Europastandorte Krefeld und Paris. Darüber hinaus wirkte er als Berater im EU-Projekt-Team für alle Lokationen des Konzerns mit und ist spezialisiert auf hochverfügbare virtualisierte Microsoft-Umgebungen plus Hybrid Cloud Solutions. Zertifizierungen: MS Specialist und MCTS für Hyper-V/SCVMM, MCSE, MCITP, MCSA. Zusätzlich zertifiziert für PRINCE2 Projektmanagementmethode.
// Kontakt: E-Mail, Twitter, LinkedIn //
Verwandte Beiträge
- Verfügbarkeit von Azure-VMs: SLA abhängig von Disk-Typ und Availability Set
- Network Load Balancing (NLB) für Windows konfigurieren
- Web-Anwendungen über Azure App Services (hochverfügbar) betreiben
- VMware vSphere: Hyperkonvergente Cluster einrichten, VMs hochverfügbar machen, Last verteilen mit DRS
- vSphere vMotion: LACP und Distributed vSwitch
Weitere Links