Einleitung
Load Balancing ist das Rückgrat moderner Application Delivery. Greifen Tausende – oder Millionen – Nutzer gleichzeitig auf Ihre Anwendung zu, kann ein einzelner Server die Last nicht bewältigen. Load Balancer verteilen eingehenden Traffic auf mehrere Backend-Server und sichern so Hochverfügbarkeit, optimale Performance und Fehlertoleranz.
Doch wie entscheidet ein Load Balancer, welcher Server eine Anfrage bearbeitet? Die Antwort liegt in den Load-Balancing-Algorithmen. Der richtige Algorithmus kann den Unterschied zwischen einer reaktionsschnellen Anwendung und einer, die von Timeouts und ungleichmäßiger Serverlast geplagt ist, ausmachen.
Dieser Leitfaden behandelt Load-Balancing-Algorithmen in zwei Kategorien: Verteilungsalgorithmen, die bestimmen, wie der Traffic auf die Server verteilt wird, und Persistenzmethoden, die für zustandsbehaftete Anwendungen Session-Kontinuität sicherstellen.
Warum die Algorithmuswahl zählt
Der richtige Load-Balancing-Algorithmus wirkt sich direkt auf Performance, Nutzererlebnis und Infrastruktureffizienz aus:
Verbesserung der Antwortzeit bei optimaler Algorithmuswahl gegenüber einfachem Round Robin
NGINX Performance StudieUnternehmensanforderung – nur 52 Minuten Ausfall pro Jahr
Branchenstandard-SLAKapazitätssteigerung mit intelligenter Verteilung im Vergleich zum Einzelserver
Best Practices Load BalancingAlgorithmus-Kategorien
Load-Balancing-Algorithmen lassen sich in zwei Hauptkategorien einteilen, die jeweils unterschiedliche Architekturanforderungen bedienen:
Verteilungsalgorithmen
Bestimmen, wie der Traffic auf die Server verteilt wird – sequenziell, zufällig oder auf Basis von Echtzeit-Metriken wie Verbindungen oder Antwortzeit.
Persistenzmethoden
Sichern Session-Kontinuität, indem Anfragen desselben Clients, derselben URI oder Nutzer-ID konsequent an denselben Server geleitet werden.
Performancebasiert
Fortgeschrittene Algorithmen, die Server-Health-Metriken – Antwortzeit, Queue-Tiefe, Verbindungsfehler – für optimale Routing-Entscheidungen berücksichtigen.
Hybride Ansätze
Kombinieren Verteilung mit Persistenz oder nutzen Multi-Kriterien-Auswahl (z. B. Fastest+) für anspruchsvolle Load-Balancing-Szenarien.
Verteilungsalgorithmen
Verteilungsalgorithmen verteilen den Traffic über Ihren Server-Pool. Die Wahl hängt von Ihrer Server-Infrastruktur, den Anfrage-Charakteristika und den Performance-Anforderungen ab.
Round Robin
Round Robin ist der einfachste und am weitesten verbreitete Load-Balancing-Algorithmus. Er funktioniert genau, wie der Name vermuten lässt: Anfragen werden in zirkulärer, sequenzieller Reihenfolge an die Server verteilt. Die erste Anfrage geht an Server 1, die zweite an Server 2 und so weiter. Nach dem letzten Server beginnt der Zyklus erneut.
Der Algorithmus geht davon aus, dass alle Server gleiche Kapazität haben und alle Anfragen ähnliche Verarbeitungsleistung benötigen. Außer der Information, welcher Server als Nächstes drankommt, ist kein State erforderlich – das macht ihn extrem effizient mit minimalem Rechenaufwand.
Round Robin glänzt in homogenen Umgebungen mit identischen Servern und relativ einheitlichen Anfragen – etwa beim Ausliefern statischer Inhalte, einfacher API-Endpunkte oder zustandsloser Microservices.
Round Robin: Auf einen Blick
| Aspekt | Details |
|---|---|
| Funktionsweise | Sequenzielle Verteilung: Server 1 → Server 2 → Server 3 → wiederholt |
| Geeignet für | Homogene Server, gleichmäßige Anfragenlast, zustandslose Anwendungen |
| Stärken | Einfach, vorhersehbar, null Rechenaufwand, einfach zu debuggen |
| Schwächen | Ignoriert Serverlast und Kapazitätsunterschiede |
| Anwendungsfälle | Statische Inhalte, CDN-Edge-Knoten, zustandslose APIs |
Weighted Round Robin
Weighted Round Robin erweitert den Basis-Algorithmus, indem jedem Server ein Gewicht entsprechend seiner Kapazität zugewiesen wird. Server mit höheren Gewichten erhalten anteilig mehr Traffic. Hat Server A Gewicht 3 und Server B Gewicht 1, bearbeitet Server A drei Anfragen, während Server B eine bearbeitet.
Dieser Algorithmus ist für heterogene Server-Umgebungen unverzichtbar. Organisationen betreiben oft eine Mischung aus Hardware – leistungsstarke neue Server neben älteren Maschinen oder Cloud-Instanzen mit unterschiedlicher vCPU-Anzahl. Weighted Round Robin sorgt dafür, dass ein 16-Core-Server mehr Traffic erhält als ein 4-Core-Server.
Gewichte werden typischerweise auf Basis von CPU-Kernen, Arbeitsspeicher oder Benchmark-Tests konfiguriert. Flexibler als einfaches Round Robin, berücksichtigt jedoch auch dieser Algorithmus keine Echtzeitlast – ein hoch gewichteter Server unter Last erhält weiterhin Traffic gemäß seinem Gewicht, nicht seiner aktuellen Kapazität.
Beginnen Sie mit Gewichten proportional zu CPU-Kernen oder Arbeitsspeicher. Hat Server A z. B. 8 Kerne und Server B 4, vergeben Sie Gewichte 8 und 4 (oder 2 und 1). Beobachten und justieren Sie anhand realer Performance-Metriken – Durchsatz, Antwortzeiten und Fehlerraten.
Least Connection
Least Connection verfolgt einen dynamischen Ansatz: Jede neue Anfrage geht an den Server mit den wenigsten aktiven Verbindungen. Anders als Round Robin passt sich der Algorithmus den Echtzeitbedingungen an – verarbeitet ein Server viele langsame Anfragen, gehen neue Anfragen an weniger belastete Server.
Besonders empfohlen ist er für Server mit langen Sitzungszeiten. Datenbankverbindungen (SQL), Verzeichnisdienste (LDAP) und Anwendungen mit persistenten Verbindungen profitieren spürbar von Least Connection.
Der Load Balancer verfolgt die aktiven Verbindungen pro Backend-Server. Trifft eine neue Anfrage ein, prüft er diese Tabelle und wählt den Server mit dem niedrigsten Wert. Dieser geringe Overhead ist im Vergleich zu den Performance-Vorteilen bei verbindungsintensiven Workloads vernachlässigbar.
Least Connection: Auf einen Blick
| Aspekt | Details |
|---|---|
| Funktionsweise | Routet zum Server mit den wenigsten aktiven Verbindungen |
| Geeignet für | Lange Sitzungen, persistente Verbindungen, Datenbank-Workloads |
| Stärken | Passt sich Echtzeitlast an, verhindert Überlast, kommt mit langsamen Anfragen zurecht |
| Schwächen | Geringer Overhead für das Verbindungs-Tracking |
| Anwendungsfälle | SQL-Datenbanken, LDAP-Verzeichnisse, WebSocket-Anwendungen, APIs mit langen Laufzeiten |
First
Der First-Algorithmus verfolgt einen besonderen Ansatz: Er leitet den gesamten Traffic an den ersten Server im Pool, bis dieser sein Verbindungslimit erreicht. Erst dann fließt Traffic an den nächsten Server.
Nützlich ist das für Aktiv-Passiv-Konfigurationen, in denen ein primärer Server die gesamte Last übernimmt und andere im Standby bleiben. Auch bei Lizenz-Szenarien ist er sinnvoll, wenn Sie einen einzelnen lizenzierten Server maximal auslasten möchten, bevor weitere Kapazität hinzukommt.
First bietet vorhersehbares Verhalten und vereinfacht die Fehlersuche, weil bekannt ist, welcher Server gerade arbeitet. Lastverteilung bietet er jedoch nicht und setzt vollständig auf die Konfiguration des Max-Connection-Limits für das Failover.
First: Auf einen Blick
| Aspekt | Details |
|---|---|
| Funktionsweise | Der erste Server erhält die gesamte Last bis zum Erreichen des Verbindungslimits |
| Geeignet für | Aktiv-Passiv-Setups, Lizenzoptimierung, vorhersehbares Routing |
| Stärken | Einfach, vorhersehbar, maximale Auslastung eines einzelnen Servers |
| Schwächen | Keine Lastverteilung, abhängig von der Max-Connection-Konfiguration |
| Anwendungsfälle | Primär-Backup-Konfigurationen, lizenzierte Software, Kapazitätsüberlauf |
Random
Der Random-Algorithmus wählt Server zufällig für jede eingehende Anfrage aus. Anders als reine Zufallswahl berücksichtigt diese Implementierung jedoch sowohl Server-Gewichte als auch Antwortzeiten in der Auswahlwahrscheinlichkeit.
Dieser gewichtete Zufallsansatz liefert statistische Lastverteilung und vermeidet zugleich die vorhersehbaren Muster von Round Robin. Über die Zeit erhalten Server proportional zu ihren Gewichten Traffic, die Zufallskomponente verhindert jedoch synchronisierte Anfragemuster, die periodische Lastspitzen verursachen können.
Zufällige Auswahl ist besonders wirksam in großen Server-Pools, in denen das Gesetz der großen Zahlen für gleichmäßige Verteilung sorgt. Sie hilft auch, das 'Thundering-Herd'-Problem zu vermeiden, bei dem mehrere Clients gleichzeitig denselben Server adressieren.
Random: Auf einen Blick
| Aspekt | Details |
|---|---|
| Funktionsweise | Zufällige Serverauswahl unter Berücksichtigung von Gewicht und Antwortzeit |
| Geeignet für | Große Server-Pools, Vermeidung synchronisierter Muster |
| Stärken | Verhindert Thundering Herd, statistisch gleichmäßig, berücksichtigt Performance |
| Schwächen | Weniger vorhersehbar als Round Robin, kurzfristige Ungleichgewichte möglich |
| Anwendungsfälle | Hoch frequentierte Anwendungen, große Cluster, Cache-Server |
Fastest
Der Fastest-Algorithmus leitet Anfragen an den Server mit der besten Antwortzeit. Der Load Balancer überwacht die Server-Performance kontinuierlich und routet Traffic an den jeweils am schnellsten antwortenden Server.
Dieser Ansatz optimiert das Nutzererlebnis, da Anfragen zum reaktionsschnellsten Server gehen. Er passt sich automatisch wechselnden Bedingungen an: Wird ein Server durch hohe CPU-Last, Speicherdruck oder externe Abhängigkeiten langsam, verlagert sich der Traffic auf schnellere Alternativen.
Fastest eignet sich ideal für latenzsensitive Anwendungen, in denen die Antwortzeit direkt das Nutzererlebnis oder geschäftliche Kennzahlen beeinflusst. E-Commerce-Checkouts, Echtzeit-APIs und interaktive Anwendungen profitieren von antwortzeitbasiertem Routing.
Fastest+
Fastest+ ist der anspruchsvollste Algorithmus und bietet zweistufige Optimierung mit konfigurierbaren Kriterien. Sie wählen eine primäre Metrik (Opt-1) für die Serverauswahl und eine sekundäre Metrik (Opt-2), die bei Gleichstand mehrerer Server den Ausschlag gibt.
Verfügbare Optimierungskriterien sind unter anderem Least Response Time, Least Connection Time, Least Queue Time, Least Queues, Least Connection Error, Least Aborted Connections und Least Used Connections. Diese Flexibilität ermöglicht eine feingranulare Abstimmung auf Ihre spezifischen Workload-Eigenschaften.
Beispielsweise lässt sich Opt-1 als 'Least Response Time' und Opt-2 als 'Least Connection Error' konfigurieren. Der Algorithmus wählt zunächst Server mit den besten Antwortzeiten aus und entscheidet sich unter diesen für jenen mit den wenigsten Verbindungsfehlern. Dieser Multi-Kriterien-Ansatz löst komplexe Produktionsszenarien, in denen einzelne Metriken nicht ausreichen.
Fastest+-Optimierungsoptionen
| Option | Beschreibung | Geeignet für |
|---|---|---|
| Least Response Time | Server mit der schnellsten Antwortzeit | Latenzsensitive Anwendungen |
| Least Connection Time | Server, der Verbindungen am schnellsten aufbaut | Workloads mit hoher Verbindungsfluktuation |
| Least Queue Time | Server mit der kürzesten Wartezeit in der Anfrage-Queue | Burstige Verkehrsmuster |
| Least Queues | Server mit den wenigsten anstehenden Anfragen | Vermeidung von Anfrage-Rückstaus |
| Least Connection Error | Server mit den wenigsten fehlgeschlagenen Verbindungen | Zuverlässigkeitskritische Anwendungen |
| Least Aborted Connections | Server mit den wenigsten abgebrochenen Verbindungen | Workloads mit langen Anfragen |
| Least Used Connections | Server mit der niedrigsten Verbindungsauslastung | Verbindungspool-Anwendungen |
Fastest+ nutzt das sekundäre Kriterium (Opt-2) nur, wenn mehrere Server beim primären Kriterium (Opt-1) gleichauf liegen. Das sichert die optimale Auswahl auch in homogenen Umgebungen, in denen Server oft ähnliche Performance haben.
Persistenzmethoden (Selbst-persistent)
Persistenzmethoden sorgen dafür, dass zusammengehörige Anfragen desselben Clients, derselben Sitzung oder desselben Kontexts immer denselben Backend-Server erreichen. Das ist essenziell für zustandsbehaftete Anwendungen, die Session-Daten lokal statt in einem gemeinsamen Speicher halten.
Source (IP-Persistenz)
Source-Persistenz nutzt einen Hash der Client-Quell-IP zur Serverauswahl. Der Hash-Wert wird mit den Server-Gewichten kombiniert, um das Routing zu bestimmen. Dieselbe Client-IP erzeugt stets denselben Hash und sorgt so für konsistentes Routing zum selben Server.
Diese Methode bietet Session-Persistenz ohne Cookies oder Anpassungen auf Anwendungsebene. Alle Anfragen einer bestimmten IP gehen an denselben Server, wodurch auf diesem Server vorgehaltene Session-Zustände erhalten bleiben.
Einschränkungen entstehen in NAT-Umgebungen, in denen mehrere Nutzer eine IP teilen, sowie bei mobilen Nutzern mit wechselnden IPs. Für solche Szenarien liefern Persistenzmethoden auf Anwendungsebene (URI, URL-Param, HDR) bessere Ergebnisse.
URI (Pfad-Persistenz)
URI-Persistenz hasht den Anfragepfad zur Bestimmung des Routings. Der URI-Text bis zu einer definierten Länge (oder bis zum Zeichen '?' bei Query-Parametern) wird gehasht und mit den Server-Gewichten kombiniert. Gleiche URIs werden stets an denselben Server geroutet.
Konfigurationsoptionen umfassen URI-Zeichenlänge und URI-Tiefe (Anzahl der zu berücksichtigenden Pfadsegmente). Mit Tiefe 2 hashen sowohl '/api/users/123' als auch '/api/users/456' denselben Präfix '/api/users'.
Diese Methode eignet sich hervorragend für Caching-Szenarien, in denen alle Anfragen zur gleichen Ressource denselben Server treffen sollen, um die Cache-Effizienz zu maximieren. Sie ist außerdem nützlich für gesplittete Backends, bei denen unterschiedliche URI-Muster auf verschiedene Datenpartitionen zeigen.
URL-Param (Parameter-Persistenz)
URL-Param-Persistenz extrahiert einen definierten Parameter aus der URL (oder dem POST-Body) und nutzt dessen Wert für das Routing. Üblicherweise werden so Nutzer-IDs, Session-Tokens oder anwendungsspezifische Bezeichner verfolgt. Gleiche Parameterwerte werden stets an denselben Server geroutet.
Sie konfigurieren den auszulesenden URL-Parameternamen und können optional die POST-Parameterprüfung für Formularübermittlungen aktivieren. So entsteht anwendungsbewusste Persistenz, die Nutzer-Sessions unabhängig von IP-Wechseln folgt.
Diese Methode ist ideal für Anwendungen, die Session- oder Nutzer-Bezeichner in URLs oder Formularen mitführen. Für mobile oder NAT-Nutzer liefert sie zuverlässigere Persistenz als IP-basierte Verfahren.
HDR (Header-Persistenz)
HDR-Persistenz untersucht einen bestimmten HTTP-Header in jeder Anfrage und routet basierend auf dessen Inhalt. Anfragen mit gleichem Header-Wert gehen stets an denselben Server. Sie konfigurieren den zu prüfenden Header-Namen.
Häufige Anwendungsfälle sind Routing nach eigenen Session-Headern, API-Keys, Mandanten-Bezeichnern in Multi-Tenant-Anwendungen oder JWT-Tokens. Das bietet maximale Flexibilität für Anwendungen, die ihre Session-Bezeichner selbst verwalten.
HDR-Persistenz ist besonders wertvoll für API-zentrische Architekturen und Microservices, in denen Sitzungszustand über Header statt Cookies abgebildet wird. Sie lässt sich nahtlos in tokenbasierte Authentifizierungssysteme integrieren.
Hash (erweiterte, individuelle Persistenz)
Hash-Persistenz ist die mächtigste und flexibelste Methode: Sie können benutzerdefinierte Persistenz-Schlüssel aus nahezu jedem Element des Traffic-Flows bilden. Der Load Balancer pflegt eine Hash-Tabelle (standardmäßig bis zu 3 Millionen Einträge), die Schlüsselwerte auf Backend-Server abbildet, mit konfigurierbarer Ablaufzeit (Standard 7 Tage).
Der Hash-Key kann aus Hunderten verfügbaren Variablen gebildet werden: Client-IP und -Port, Zeitstempel, SSL-Zertifikatsfelder, Frontend-Informationen, URL-Pfad und -Methode, HTTP-Header, Inhalte des Request-Bodys, WAAP-Ergebnisse und vieles mehr. Sie können mehrere Variablen kombinieren und Transformationsfunktionen anwenden, um exakt die Persistenzlogik abzubilden, die Ihre Anwendung erfordert.
Beispiel: Sie könnten einen Hash-Key erzeugen, der das Land aus der Client-IP extrahiert, prüft, ob es in einer bestimmten Liste ist, und das mit dem Benutzernamen aus dem SSL-Client-Zertifikat kombiniert. Alle Anfragen, die denselben Hash aus dieser Kombination erzeugen – also Nutzer aus derselben Region mit derselben Zertifikatsidentität – werden stets demselben Backend-Server zugewiesen. Das ermöglicht extrem feingranulare Persistenzsteuerung und erhält gleichzeitig den Anwendungs-Sessionzustand. Solche Customization-Tiefe ist mit anderen Load Balancern oft nicht erreichbar – sie ist eine der differenzierenden Fähigkeiten von TR7.
Bausteine für Hash-Keys
Der Hash-Key lässt sich aus beliebigen Kombinationen folgender Traffic-Elemente bilden:
| Kategorie | Verfügbare Variablen | Beispielanwendung |
|---|---|---|
| Netzwerkebene | Client-IP, Client-Port, Server-IP, Server-Port | Geobasiertes Routing, Affinität pro Netzwerksegment |
| SSL/TLS | Zertifikats-CN, Zertifikats-DN, SNI, Cipher Suite | Routing auf Basis von Client-Zertifikaten, mTLS-Szenarien |
| HTTP-Request | Methode, Pfad, URL, Query-Parameter, Host-Header | Content-basiertes Routing, API-Versionierung |
| HTTP-Header | Beliebige Header-Werte (Authorization, X-Tenant-ID etc.) | Multi-Tenant-Routing, API-Key-Affinität |
| Request-Body | POST-Parameter, JSON-Felder, Formulardaten | Transaktionsbasierte Persistenz |
| Kontext | Uhrzeit, Datum, Frontend-Name, WAAP-Entscheidung, GeoIP-Land | Zeitbasiertes Routing, Compliance-Routing |
Hash-Keys unterstützen Funktionen zur Transformation: String-Manipulation (Substring, RegEx), Codierung (Base64, URL-Encode), Lookups (GeoIP-Land, ASN) und bedingte Logik. Kombinieren Sie diese, um komplexe Persistenzregeln zu bauen. Beispiel: 'Wenn der Client aus EU-Ländern stammt UND ein gültiges Client-Zertifikat hat, bilde den Hash aus dem Zertifikats-CN; andernfalls aus dem Authorization-Header' – Anfragen mit denselben Bedingungen erreichen so stets denselben Backend-Server.
Vergleich der Persistenzmethoden
| Methode | Basis | Konfiguration | Geeignet für |
|---|---|---|---|
| Source | Hash der Client-IP | Keine (automatisch) | Einfache Webanwendungen, Legacy-Systeme |
| URI | Hash des Anfragepfads | URI-Länge, URI-Tiefe | Caching, Content-Routing, gesplittete Backends |
| URL-Param | Wert eines URL-/POST-Parameters | Parametername, POST-Check-Option | Session-Tracking, nutzerspezifisches Routing |
| HDR | HTTP-Header-Wert | Header-Name | API-Authentifizierung, Multi-Tenant-Apps, JWT-Routing |
| New Cookie | LB-verwaltetes Cookie | Cookie-Name, Max-Idle, Max-Life | Keine App-Änderungen nötig, Steuerung des Session-Timeouts |
| Current Cookie | Bestehendes Anwendungs-Cookie | Zu trackender Cookie-Name | Vorhandene App-Sessions nutzen |
| Hash | Eigener Schlüsselausdruck | Variablen, Funktionen, 3 Mio. Einträge, 7-Tage-TTL | Komplexe Multi-Faktor-Persistenz, maximale Flexibilität |
Leitfaden zur Algorithmusauswahl
Die Wahl des passenden Algorithmus hängt von Ihren Anforderungen ab. Dieser Vergleich verdeutlicht die wichtigsten Trade-offs:
| Algorithmus | Lastbewusstsein | Komplexität | Persistenz | Primärer Anwendungsfall |
|---|---|---|---|---|
| Round Robin | Keine | Minimal | Nein | Homogene, zustandslose Workloads |
| Weighted Round Robin | Statisch (Gewichte) | Niedrig | Nein | Server unterschiedlicher Kapazität |
| Least Connection | Dynamisch (Verbindungen) | Mittel | Nein | Lange Sitzungen, Datenbanken |
| First | Keine | Minimal | Nein | Aktiv-Passiv, Lizenzoptimierung |
| Random | Dynamisch (Antwortzeit) | Niedrig | Nein | Große Cluster, Cache-Server |
| Fastest | Dynamisch (Antwortzeit) | Mittel | Nein | Latenzsensitive Anwendungen |
| Fastest+ | Multi-Kriterien | Hoch | Nein | Komplexe Produktionsumgebungen |
| Source | Über Gewichte | Niedrig | Ja (IP) | Einfache Session-Persistenz |
| URI | Über Gewichte | Mittel | Ja (Pfad) | Caching, Content-Routing |
| URL-Param | Über Gewichte | Mittel | Ja (Nutzer-ID) | Tracking von Nutzer-Sessions |
| HDR | Über Gewichte | Mittel | Ja (Header) | API-Routing, Multi-Tenant |
Algorithmus wählen
Verteilungsalgorithmen einsetzen, wenn
- die Anwendung zustandslos ist oder einen gemeinsamen Session-Store nutzt
- Sie Last über einen Server-Pool verteilen müssen
- Server unterschiedliche Kapazitäten haben (Weighted)
- Antwortzeit kritisch ist (Fastest/Fastest+)
Persistenzmethoden einsetzen, wenn
- die Anwendung Session-Daten lokal auf Servern speichert
- Backend-Services nach Nutzer oder Content gesplittet sind
- Caching-Effizienz konsistentes Routing erfordert
- Token- oder Header-basierte Authentifizierung im Einsatz ist
Fastest+ einsetzen, wenn
- eine einzelne Metrik Ihr Optimierungsziel nicht abbildet
- Sie Tie-Breaking-Logik für homogene Server benötigen
- Performance und Zuverlässigkeit gleichermaßen wichtig sind
- Sie eine komplexe Produktionsumgebung mit unterschiedlichen Workloads haben
Best Practices für die Umsetzung
Unabhängig vom gewählten Algorithmus sichern diese Praktiken optimale Load-Balancing-Performance:
Robuste Health Checks implementieren
Konfigurieren Sie aktive Health Checks, die die Anwendungsfunktionalität prüfen, nicht nur TCP-Erreichbarkeit. Ein Server, der auf Pings antwortet, aber 500er zurückgibt, sollte aus der Rotation entfernt werden.
Gewichte überwachen und anpassen
Überprüfen Sie Gewichtszuweisungen quartalsweise oder nach Infrastrukturänderungen. Benchmarken Sie Server unter realistischer Last, um genaue Kapazitätsverhältnisse zu bestimmen.
Persistenz mit Bedacht wählen
Gestalten Sie Anwendungen nach Möglichkeit zustandslos und legen Sie Sessions in externen Stores wie Redis ab. Wenn Persistenz nötig ist, wählen Sie die Methode, die zu Ihrem Session-Bezeichner passt (IP, URI, Parameter oder Header).
Failover-Szenarien testen
Testen Sie regelmäßig Server-Ausfälle, um sanftes Failover zu gewährleisten. Prüfen Sie das Algorithmus-Verhalten bei Entfernen und Wiedereinhängen von Servern.
Fastest+ für komplexe Szenarien einsetzen
Wenn einzelne Metriken nicht reichen, konfigurieren Sie Fastest+ mit primären und sekundären Kriterien. Starten Sie mit Least Response Time als Opt-1 und Least Connection Error als Opt-2.
Häufig gestellte Fragen
Ja, Persistenzmethoden (Source, URI, URL-Param, HDR) beziehen Server-Gewichte bereits in ihre Routing-Entscheidungen ein. Sie erhalten damit Session-Affinität und kapazitätsbewusste Verteilung. Die Hash-basierte Auswahl ist gemäß Serverkonfiguration gewichtet.
Nutzen Sie Fastest, wenn die Antwortzeit Ihre einzige Sorge ist und Server klar unterschiedliche Performance haben. Wählen Sie Fastest+, wenn Sie differenzierter auswählen müssen – etwa, wenn Sie auf Antwortzeit optimieren, aber bei vergleichbaren Werten Server mit weniger Fehlern bevorzugen.
Wird ein persistenter Server nicht mehr verfügbar, werden Anfragen anhand der Hash-Umverteilung des Persistenz-Algorithmus auf einen anderen Server umgeleitet. Die Session-Daten des ausgefallenen Servers gehen verloren, sofern Sie keinen externen Session-Store nutzen. Health Checks sorgen dafür, dass ausgefallene Server zügig aus dem Pool entfernt werden.
Least Connection als eigenständiger Algorithmus routet zum Server mit den wenigsten aktiven Verbindungen. 'Least Used Connections' in Fastest+ berücksichtigt die Verbindungsauslastung relativ zur Kapazität des Servers und eignet sich daher besser für heterogene Server-Umgebungen.
Für mobile Anwendungen sollten Sie Source-(IP-)Persistenz vermeiden, da mobile Geräte häufig IPs wechseln. Setzen Sie URL-Param-Persistenz mit Nutzer-ID oder Session-Token ein oder HDR-Persistenz mit einem Authentifizierungs-Header. Diese Methoden folgen der Session unabhängig von Netzwerkwechseln.
Fazit
Load-Balancing-Algorithmen sind grundlegend für die Application Delivery, werden aber bei Architekturentscheidungen oft unterschätzt. Der richtige Algorithmus sorgt für gleichmäßige Server-Auslastung, optimale Antwortzeiten und robustes Failover – die falsche Wahl erzeugt Hotspots, verschlechtert die Performance und erschwert die Fehlersuche.
Für die meisten Produktionsumgebungen empfiehlt sich der Einstieg mit Least Connection für dynamische Workloads oder Weighted Round Robin für statische Kapazitätsverteilung. Mit reiferer Beobachtbarkeit eröffnen sich die Möglichkeiten von Fastest+ für die Multi-Kriterien-Optimierung. Wählen Sie Persistenzmethoden anhand Ihrer Session-Strategie – Source für Einfachheit oder URI/URL-Param/HDR für anwendungsbewusstes Routing.
Intelligente Verkehrsverteilung
Der TR7-ADC unterstützt alle wichtigen Algorithmen, einschließlich des erweiterten Fastest+ mit Multi-Kriterien-Optimierung sowie flexibler Persistenzoptionen für session-bewusstes Routing. Optimieren Sie Ihre Application Delivery mit Load Balancing der Enterprise-Klasse.
ADC entdecken