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.
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.
Die Algorithmenwahl liegt im vService-Objekt, nicht in der globalen ADC-Konfiguration. Verschiedene vServices können in derselben TR7-Instanz unterschiedliche Algorithmen verwenden.
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.
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.
Den Algorithmus eines laufenden vService ändern und der Verkehr wechselt sofort zur neuen Logik. Kein Service-Neustart, kein Connection-Drain erforderlich.
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.
Gleichmäßige Verteilung über den vService, gewichtet oder ungewichtet. Der Standard-Standard für einheitliche vServices, bei denen jedes Backend identische Kapazität hat.
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.
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.
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.
Dieselbe Client-IP wird immer an dasselbe Backend weitergeleitet. Nützlich für zustandsbehaftete Flows, wenn die Anwendung keine explizite Sitzungspersistenz verwaltet.
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.
Hash über einen benutzerdefinierten HTTP-Header. Nützlich für Multi-Tenant-Routing (Tenant-ID-Header), Feature-Flagging oder A/B-Test-Szenarien.
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.
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.
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.
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.
Leitet an das Backend mit der niedrigsten letzten Antwortzeit weiter. Eine einfachere latenzbewusste Option, wenn die Antwortzeit das einzige relevante Signal ist.
TR7s proprietäre 8-Signal-Adaptivmaschine. Kombiniert Antwortzeit, Verbindungsaufbauzeit, Warteschlangentiefe, aktive Sitzungen, Fehlerraten und mehr zu einem pro Anfrage berechneten Schnelligkeits-Score. Siehe Detailabschnitt unten.
Die meisten adaptiven Algorithmen beobachten ein einziges Signal — Antwortzeit oder Verbindungsanzahl. Fastest+ sampelt kontinuierlich 8 unabhängige Performance-Signale pro Backend und kombiniert sie zu einem einzigen Schnelligkeits-Score, der für jede eingehende Anfrage neu berechnet wird.
Mittlere Antwortlatenz vom Backend, kontinuierlich gesampelt. Das Hauptsignal — ein Backend, das länger zum Antworten braucht, fällt sofort im Ranking ab.
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.
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.
Aktuell offene Sitzungen pro Backend. Kapazitätsbewusstes Routing ohne das Rauschen historischer Gesamtzahlen.
Aktuell wartende Anfragen. Ein Backend mit 0 in der Warteschlange wird einem gleich schnellen mit 50 wartenden Anfragen vorgezogen.
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.
Vom Backend initiierte Sitzungsabbrüche im jüngsten Zeitfenster. Erfasst den Fall, bei dem ein Backend läuft, aber mittendrin fehlschlägt.
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.
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.
WebSockets, Streaming-Dienste, Videoanrufe — Sitzungen bleiben minutenlang oder stundenlang offen. Least-Connections oder SED verfolgen die aktive Last weit besser als die Anfragenanzahl.
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.
Gemischte Hardware, Rolling Deployments, regionale Latenzvariation — Fastest+ bewertet Backends live, sodass das Routing das tatsächlich Schnellste wählt, nicht das theoretisch Beste.
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.