Lösung

Den richtigen Algorithmus für jede Arbeitslast wählen

Vom klassischen Round-Robin bis zu Maglev-Hashing und TR7s proprietärer zweistufiger Fastest+-Engine — 14 Algorithmen mitgeliefert

Unterschiedliche Arbeitslasten erfordern unterschiedliche Routinglogik. Ein einheitlicher vService mit identischen Webservern? Round-Robin. Langlebige Sitzungen, bei denen die Kapazität entscheidet? Least-Connections. Cache-Affinitätsszenarien? Consistent Hash oder Maglev. Heterogene Hardware oder schwankende Last? Fastest+. TR7 ADC liefert jeden Standardalgorithmus — plus drei moderne Hash-Varianten und eine proprietäre Engine — pro vService wählbar, ohne Neustart austauschbar.

Layer-7-Auswahlkriterien

Layer-4-Scheduler

pro vService

Algorithmenwahl — live ohne Neustart änderbar

Warum unterschiedliche Verkehrsmuster verschiedene Algorithmen erfordern

Jeder klassische Algorithmus basiert auf einer Annahme über den vService, dem er dient. Round-Robin geht davon aus, dass Backends austauschbar sind. Least-Connections setzt voraus, dass die Sitzungsanzahl mit der Backend-Last korreliert. Source-IP setzt Benutzer-zu-Backend-Affinität ohne explizite Persistenz voraus. Cache-Affinitäts-Hashes setzen voraus, dass der Anfrageschlüssel — URL, Header oder Sitzung — stabil ist. Wenn die Annahme zutrifft, ist der Algorithmus die richtige Wahl.

Die schwierigeren Fälle entstehen, wenn diese Annahmen nicht mehr gelten: Backends driften im Laufe des Arbeitstages in der Performance, Hardware-Generationen mischen sich bei einem Rolling-Upgrade, die regionale Latenz variiert von Anfrage zu Anfrage, oder die Arbeitslast selbst weist stoßartige schwere Abfragen auf, die nicht mit der reinen Anfragenanzahl korrelieren. In diesen Szenarien ist es entscheidend, das tatsächlich schnellste Backend pro Anfrage zu wählen — oder einen Hash-Algorithmus zu verwenden, der für die Aufnahme von Backend-Änderungen ohne vollständiges Re-Sharding ausgelegt ist — um die vom Benutzer wahrnehmbare Latenz zu erhalten.

Die richtige Antwort lautet: den Algorithmus an die Arbeitslast anpassen — pro vService, nicht global.

Algorithmenwahl, pro vService

Ein vService in TR7 fasst den Frontend-Listener, Verkehrsregeln, Health Checks und die Backend-Gruppe in einem einzigen Konfigurationsobjekt zusammen — breiter als das klassische Pool-Konzept, das diese Bestandteile auf separate Stellen aufteilt. Jeder vService wählt seinen eigenen Algorithmus aus einer Dropdown-Liste — kein Neuaufbau, kein Neustart. Mischen und anpassen innerhalb einer TR7-Instanz: Round-Robin beim Static-Asset-vService, Fastest+ beim API-vService, Maglev Hash beim Cache-Tier-vService. Die Service-Typ-Filterung erfolgt automatisch; die Benutzeroberfläche zeigt nur Algorithmen an, die für das Protokoll des vService gültig sind.

Algorithmus pro vService

Die Algorithmenwahl liegt im vService-Objekt, nicht in der globalen ADC-Konfiguration. Verschiedene vServices können in derselben TR7-Instanz unterschiedliche Algorithmen verwenden.

Protokollbewusste Filterung

Die Benutzeroberfläche zeigt nur Algorithmen an, die für das Protokoll des vService sinnvoll sind — HTTP-, TCP- und Netzwerkschicht-vServices erhalten jeweils die relevante Teilmenge, ohne dass der Operator raten muss.

Kombinierbar mit Sitzungspersistenz

Der Algorithmus wählt das Backend für die erste Anfrage; die Sitzungspersistenz fixiert dann nachfolgende Anfragen desselben Benutzers. Beide Schichten sind pro vService unabhängig konfigurierbar.

Hot-Swap (kein Neustart)

Den Algorithmus eines laufenden vService ändern und der Verkehr wechselt sofort zur neuen Logik. Kein Service-Neustart, kein Connection-Drain erforderlich.

14 mit TR7 ADC mitgelieferte Algorithmen

Jeder klassische Algorithmus, zwei moderne Consistent-Hash-Varianten, ein Shortest-Delay-Algorithmus sowie TR7s proprietäre Fastest+-Engine. Alle pro vService verfügbar — aus einer Dropdown-Liste wählen, kein Konfigurationscode erforderlich.

Round-Robin (gewichtet + statisch)

Gleichmäßige Verteilung über den vService, gewichtet oder ungewichtet. Der Standard-Standard für einheitliche vServices, bei denen jedes Backend identische Kapazität hat.

Least-Connections (gewichtet)

Leitet an das Backend mit den wenigsten aktuell offenen Verbindungen weiter. Sehr effektiv für langlebige Sitzungen, bei denen die Sitzungsanzahl mit der Backend-Last korreliert. Die gewichtete Variante berücksichtigt Kapazitätsunterschiede.

Kürzeste Antwortzeit

Leitet an das Backend, das aktuell am schnellsten antwortet — kontinuierlich gemessen, nicht stichprobenartig. Geeignet für Pools mit gleicher Kapazität, aber schwankender Latenz je Knoten: aufwärmender Cache, Knoten unter GC-Druck, lauter Nachbar.

Geringste Bandbreite

Leitet an das Backend, das gerade den geringsten Verkehr bewegt. Das richtige Kriterium, wenn sich Antworten in der Größe statt in der Anzahl unterscheiden — Medien, Dateidownloads, Report-Exporte —, wo die Verbindungszahl nichts über die reale Last aussagt.

First-Available

Leitet immer an das erste aufgeführte Backend mit freier Kapazität weiter; fällt erst durch, wenn dieses überlastet ist. Nützlich für die Reihenfolge Warm-dann-Kalt-Backend oder gestaffelte Deployments.

Random

Zufällige Auswahl aus gesunden Backends. Zustandslos, statistisch gleichmäßig — nützlich, wenn der vService groß und einheitlich ist. Unterstützt Power-of-Two-Random für eine lastbewusste Auswahl mit geringem Overhead.

Source-IP-Hash

Dieselbe Client-IP wird immer an dasselbe Backend weitergeleitet. Nützlich für zustandsbehaftete Flows, wenn die Anwendung keine explizite Sitzungspersistenz verwaltet.

URL-Hash (URI / URL-Parameter)

Hash über eine URL-Komponente — die URL-Länge, den URI-Pfad oder einen bestimmten Query-Parameter (z. B. ?user_id). Leitet dieselbe URL oder denselben Benutzer für Cache-Affinität an dasselbe Backend weiter.

Header-Hash

Hash über einen benutzerdefinierten HTTP-Header. Nützlich für Multi-Tenant-Routing (Tenant-ID-Header), Feature-Flagging oder A/B-Test-Szenarien.

RDP-Cookie-Hash

Liest den RDP-Sitzungs-Cookie für die Backend-Auswahl. Nützlich für RDP-Gateways und Remote-Desktop-Farmen, bei denen Sitzungsaffinität erforderlich ist.

Consistent Hash

Moderner Hash-Modus, der Unterbrechungen minimiert, wenn Backends dem vService beitreten oder ihn verlassen — nur ein kleiner Bruchteil der Schlüssel wird neu verteilt, nicht der gesamte vService. Richtig für Cache-Tiers, bei denen Backend-Fluktuation den gesamten Cache nicht ungültig machen sollte.

Maglev-Hash

Googles Consistent-Hashing-Algorithmus, entwickelt für Software-Lastverteiler im großen Maßstab. Geringere Varianz als der klassische Consistent Hash, deterministisch über Replicas hinweg. Hervorragend für zustandslose Services, die eine vorhersagbare Backend-Zuweisung benötigen.

SED — Shortest Expected Delay

Leitet an das Backend mit der niedrigsten erwarteten Wartezeit weiter, unter Berücksichtigung aktiver Verbindungen und des Backend-Gewichts. Eine latenzbewusste Alternative zu Least-Connections, wenn sich Backend-Kapazitäten erheblich unterscheiden.

Fastest

Leitet an das Backend mit der niedrigsten letzten Antwortzeit weiter. Eine einfachere latenzbewusste Option, wenn die Antwortzeit das einzige relevante Signal ist.

Fastest+

TR7s proprietäre zweistufige Engine. Der Operator wählt zwei von acht Live-Service-Signalen — Antwortzeit, Verbindungsaufbauzeit, Warteschlangentiefe, Fehlerraten und mehr; Fastest+ grenzt die Kandidaten nach dem primären Signal ein und differenziert den Gleichstand dann mit dem sekundären Signal aus. Siehe Detailabschnitt unten.

Fastest+ — TR7s zweistufige, vom Operator definierte Engine

Die meisten adaptiven Algorithmen beobachten ein einziges Signal — Antwortzeit oder Verbindungsanzahl. Fastest+ lässt den Operator zwei von acht Live-Service-Signalen wählen: Das primäre Signal grenzt die Kandidaten auf die Backends mit dem besten Wert ein, und das sekundäre Signal differenziert den Gleichstand unter ihnen aus. Backends im Wartungsmodus oder mit ungeeignetem Gesundheitsstatus werden automatisch herausgefiltert, und ein Einzelsignal-Modus steht zur Verfügung, wenn ein Kriterium ausreicht. Das sind die acht Signale, aus denen Sie wählen können:

Antwortzeit

Mittlere Antwortlatenz vom Backend, kontinuierlich gesampelt. Das Hauptsignal — ein Backend, das länger zum Antworten braucht, fällt sofort im Ranking ab.

Verbindungsaufbauzeit

Wie lange es dauert, eine TCP/TLS-Verbindung aufzubauen. Ein Backend, dessen Verbindungsaufbauzeit zunimmt, nähert sich der Sättigung — auch wenn seine Antwortzeit noch gut aussieht.

Warteschlangenzeit

Zeit, die Anfragen in der Warteschlange verbringen, bevor sie das Backend erreichen. Steigende Warteschlangenzeit ist die früheste Warnung, dass ein Backend nicht mehr mitkommt.

Aktive Sitzungen

Aktuell offene Sitzungen pro Backend. Kapazitätsbewusstes Routing ohne das Rauschen historischer Gesamtzahlen.

Aktive Warteschlangentiefe

Aktuell wartende Anfragen. Ein Backend mit 0 in der Warteschlange wird einem gleich schnellen mit 50 wartenden Anfragen vorgezogen.

Verbindungsfehler

Kürzlich fehlgeschlagene Verbindungen. Ein Backend, das 3 der letzten 10 Verbindungsversuche abgelehnt hat, fällt im Ranking ab, bevor ein Health Check es erfassen würde.

Serverseitige Verbindungsabbrüche

Vom Backend initiierte Sitzungsabbrüche im jüngsten Zeitfenster. Erfasst den Fall, bei dem ein Backend läuft, aber mittendrin fehlschlägt.

Genutzte Verbindungen

Verbindungspool-Auslastung — wie nah an der Kapazitätsgrenze der Keep-Alive-Pool jedes Backends ist. Erkennt Pool-Erschöpfung, bevor sie für den Benutzer sichtbar wird.

ZWEI EBENEN, EINE POLICY

Vierzehn auf Layer 7, elf auf Paketebene

Auf Layer 7 entscheidet der Inhalt der Anfrage: Header, Pfad, Cookie, aktuelle Antwortzeit. Auf Layer 4 entscheidet das Paket, bevor der Verkehr die Anwendungsebene überhaupt erreicht — dort liegt der höchste Durchsatz. In beiden Fällen wird der Algorithmus pro Service gewählt und ändert sich im laufenden Betrieb.

Layer 7 — 14 Auswahlkriterien

Round robin — der Reihe nach, gewichtet oder streng gleich

Gewichtetes round robin — Kapazitätsunterschiede werden berücksichtigt

Wenigste Verbindungen — die wenigsten offenen Verbindungen gewinnen

Kürzeste Antwortzeit — das Backend, das gerade am schnellsten antwortet

Geringste Bandbreite — das Backend mit dem derzeit geringsten Verkehr

Erstes verfügbares — ein Backend füllen, bevor das nächste angefasst wird

Zufällig — statistisch flach, ohne Zustand

Fastest — ein Live-Signal, der niedrigste Wert gewinnt

Fastest+ — zwei Live-Signale: das erste grenzt ein, das zweite entscheidet

Quell-IP — gleicher Client, gleiches Backend

URI — gleicher Pfad, gleiches Backend — der Cache bleibt warm

URL-Parameter — Routing anhand eines Werts im Query-String

Header — Routing über jeden Header, auch Ihren eigenen

RDP-Cookie — Desktop-Sitzungen landen bei ihrem Broker

Layer 4 — 11 Scheduler auf Paketebene

rr — round robin

wrr — gewichtetes round robin

lc — wenigste Verbindungen

wlc — gewichtete wenigste Verbindungen

lblc — lokalitätsbasiert, wenigste Verbindungen

lblcr — dasselbe mit Replikation

sh — Quell-Hash

dh — Ziel-Hash

sed — kürzeste erwartete Verzögerung

nq — niemals in die Warteschlange

mh — Maglev-Hash: minimales Remapping bei Pool-Änderungen

Wann jeder Algorithmus glänzt

Einheitliche vServices

Identische Backends, identische Kapazität — Round-Robin hält die Berechnung einfach und die Last symmetrisch. Random für zustandslose große vServices hinzufügen.

Langlebige Sitzungen

WebSockets, Streaming-Dienste, Videoanrufe — Sitzungen bleiben minutenlang oder stundenlang offen. Least-Connections oder SED verfolgen die aktive Last weit besser als die Anfragenanzahl.

Cache-Tier-vServices

Backend-Fluktuation sollte den gesamten Cache nicht ungültig machen. Consistent Hash oder Maglev verteilen nur einen kleinen Bruchteil der Schlüssel neu, wenn Backends wechseln.

Heterogene oder schwankende Last

Gemischte Hardware, Rolling Deployments, regionale Latenzvariation — Fastest+ bewertet Backends live, sodass das Routing das tatsächlich Schnellste wählt, nicht das theoretisch Beste.

Häufig gestellte Fragen

Kann ich den Algorithmus ändern, ohne den Service neu zu starten?

Ja. Der Algorithmus ist eine Dropdown-Auswahl pro vService. Ändern Sie ihn bei einem laufenden vService und der Verkehr wechselt sofort zur neuen Logik — kein Service-Neustart, kein Connection-Drain erforderlich.

In welchem Verhältnis steht Fastest+ zu Least-Connections?

Least-Connections ist für viele vServices sehr effektiv — besonders für langlebige Sitzungen, bei denen die Sitzungsanzahl die Backend-Last genau widerspiegelt. Fastest+ erweitert das Bild, indem Sie aus acht Live-Signalen — Warteschlangentiefe, letzte Antwortzeit, Verbindungsaufbauzeit, Fehlerraten und mehr — zwei wählen und in einer zweistufigen Auswahl entscheiden. Die Anwendungsfälle unterscheiden sich: Least-Connections ist oft die richtige Wahl für einheitliche vServices mit vorhersagbaren Sitzungsmustern; Fastest+ glänzt dort, wo die Sitzungsanzahl allein nicht widerspiegelt, wie ausgelastet ein Backend wirklich ist — bei variablen Abfragezeiten, gemischten Hardware-Generationen oder Rolling Deployments.

Wann sollte ich Consistent Hash vs. Maglev Hash wählen?

Beide minimieren das Re-Sharding, wenn sich Backends ändern. Consistent Hash ist der klassische Algorithmus — einfach, vorhersagbar, gut verstanden. Maglev ist Googles Variante, entwickelt für Software-Lastverteiler im großen Maßstab — geringere Varianz in der Lastverteilung, deterministisch über Replicas. Für die meisten Arbeitslasten ist Consistent Hash ausreichend; wählen Sie Maglev, wenn Sie strenge Lastgleichmäßigkeit benötigen oder wenn Sie mehrere TR7-Instanzen betreiben, die sich beim Routing einigen müssen.

Was macht SED, was Least-Connections nicht macht?

SED (Shortest Expected Delay) berücksichtigt sowohl aktive Verbindungen als auch das Backend-Gewicht, um zu schätzen, welches Backend auf die nächste Anfrage am schnellsten antwortet. Es ist eine Verfeinerung von Weighted-Least-Connections — nützlich, wenn sich Backend-Kapazitäten erheblich unterscheiden und Sie möchten, dass das Routing dies berücksichtigt, ohne die volle Komplexität von Fastest+.

Erfordert die Algorithmenwahl externes Monitoring oder APM-Integration?

Nein. Alle Signale — einschließlich jedes Fastest+-Signals — werden von TR7 aus dem Verkehr gemessen, den es bereits proxyt. Kein Agent, kein APM-Hook, keine externe Metrik-Pipeline.

Was ist der Standard-Algorithmus?

Round-Robin ist der Standard für Abwärtskompatibilität mit bestehenden Deployments. Der Wechsel zu einem anderen Algorithmus ist eine Dropdown-Änderung in der vService-Konfiguration.

Algorithmus an die Arbeitslast anpassen

Sehen Sie, wie TR7 ADC Ihnen ermöglicht, den Algorithmus pro vService einzustellen — und wie Fastest+ die Arbeitslasten bewältigt, mit denen andere nicht zurechtkommen.