TCP-Loadbalancing für robuste Backend-Verbindungen

TL;DR

TCP Loadbalancing verteilt Verbindungen auf der Transportebene, ohne HTTP-Inhalte auszuwerten. Das eignet sich für Protokolle und Dienste, bei denen Transparenz, Protokolltreue und geringe Verarbeitungstiefe wichtiger sind als URL- oder Header-basiertes Routing. Entscheidend sind passende Backend-Pools, Health Checks und ein klares Verständnis bestehender TCP-Verbindungen.

Einleitung

TCP-Loadbalancing ist keine vereinfachte Variante von HTTP-Routing, sondern eine bewusste Architekturentscheidung. Wo ein Dienst keine HTTP-Informationen liefert oder diese nicht ausgewertet werden sollen, verteilt Layer 4 Loadbalancing eingehende TCP-Verbindungen anhand von Netzwerk- und Transportinformationen. Das reduziert die Verarbeitungstiefe und hält die Edge für unterschiedliche TCP-basierte Protokolle offen. Gleichzeitig entfallen Funktionen wie Routing nach Hostnamen, Pfaden oder HTTP-Headern. Unternehmen müssen deshalb vorab klären, ob sie Verbindungen lediglich verteilen oder den Anwendungsverkehr verstehen und steuern wollen. Diese Unterscheidung bestimmt, wie Backend-Pools, Failover und Betriebsprozesse gestaltet werden.

1. Geeignete Einsatzfälle für Layer 4 Loadbalancing

Layer 4 Loadbalancing arbeitet auf Basis von IP-Adressen und Ports sowie dem Zustand der TCP-Verbindung. Die Edge nimmt eine Verbindung an, wählt ein Backend aus einem definierten Pool und leitet den TCP-Datenstrom weiter. Der Inhalt der Anwendung ist für diese Entscheidung nicht erforderlich.

Das ist für Dienste sinnvoll, die nicht über HTTP oder HTTPS kommunizieren. Dazu zählen beispielsweise Datenbankzugriffe, Messaging-Protokolle, proprietäre TCP-Dienste oder Anwendungen, bei denen ein vorgeschalteter Proxy die Protokollsemantik nicht verändern soll. Auch HTTP-Dienste können auf Layer 4 verteilt werden, wenn TLS oder HTTP unverändert bis zum Backend laufen sollen.

Der Vorteil liegt in der Protokolltreue: Die Edge muss keine anwendungsbezogenen Regeln interpretieren. Dadurch bleibt die Architektur für Clients und Backends vergleichsweise transparent. Im Gegenzug ist die Auswahl der Backend-Instanz nicht von URL, Cookie oder Header abhängig. Alle Verbindungen zu einem virtuellen Dienst folgen daher derselben L4-Verteilungslogik, sofern keine getrennten Listener oder Ports verwendet werden.

2. Die Grenzen fehlender HTTP-Informationen

Der Verzicht auf HTTP-Inspektion ist zugleich die wichtigste Einschränkung. Ein Layer-4-System kann nicht erkennen, ob eine Anfrage /login oder /checkout aufruft, welchen Hostnamen ein Client verwendet oder welcher Tenant in einem HTTP-Header steht. Routing-Entscheidungen nach URL-Pfad, Content-Typ oder Session-Cookie sind damit nicht möglich.

Diese Grenze betrifft auch Security- und Betriebsfunktionen. Eine Web Application Firewall benötigt HTTP- beziehungsweise HTTPS-Kontext. Sie kann HTTP-Anfragen auf Layer 7 prüfen, während ein reines TCP-Forwarding den Datenstrom nicht auf Anwendungsebene bewertet. Ebenso sind anwendungsbezogene Metriken wie Requests pro Route oder Statuscodes nicht automatisch verfügbar.

Für die Architektur folgt daraus eine klare Trennung: L4 Loadbalancing verteilt Transportverbindungen, L7 Loadbalancing interpretiert Anwendungsverkehr. Wer beide Anforderungen hat, kann unterschiedliche Listener oder Dienste einsetzen. Bei TLS-Passthrough bleibt die Verschlüsselung bis zum Backend bestehen; eine Auswertung auf HTTP-Ebene erfordert dagegen eine entsprechende Termination und Verarbeitung an der Edge oder im Backend.

3. Backend-Pools und stabile TCP-Verbindungen

Ein Backend-Pool bündelt erreichbare Instanzen eines Dienstes. Für jede neue TCP-Verbindung wird eine Instanz ausgewählt. Während der Verbindung muss der Datenstrom konsistent zu diesem Backend bleiben, weil TCP-Zustand und Anwendungssitzung nicht beliebig zwischen Servern verschoben werden können. Ein Wechsel des Backends ist typischerweise erst bei einer neuen Verbindung möglich.

Damit Failover funktioniert, müssen nicht nur IP-Adressen und Ports stimmen. Health Checks müssen zuverlässig feststellen, ob ein Backend Verbindungen annehmen und den vorgesehenen Dienst bereitstellen kann. Ein erreichbarer Port allein beweist nicht, dass die Anwendung betriebsbereit ist. Fällt eine Instanz aus, sollte sie für neue Verbindungen aus dem Pool genommen werden. Bereits etablierte Verbindungen benötigen dagegen eine gesonderte Betrachtung: Ihr Verhalten hängt vom Fehlerbild, vom TCP-Zustand und von den Wiederholungsmechanismen der Anwendung ab.

Die ayedo Edge Cloud unterstützt Backend Health Checks und Failover für solche Verteilungsmodelle. Für den Betrieb bedeutet das, Pools, Prüfintervalle und Fehlerreaktionen gemeinsam mit den Timeout- und Retry-Strategien der Backends zu planen. Zu aggressive Retries können einen bereits überlasteten Pool zusätzlich belasten.

4. Transparenz, Netzwerkpfad und Betriebsmodell

L4 Loadbalancing ist transparent, aber nicht automatisch unsichtbar. Die Edge bildet den öffentlichen Eingang und verbindet Clients mit privaten oder abgeschirmten Backend-Pools. Backend Cloaking kann dabei verhindern, dass die eigentlichen Backend-Adressen öffentlich exponiert werden. Die Anwendung bleibt über einen stabilen Einstiegspunkt erreichbar, während die Infrastruktur hinter diesem Punkt verändert werden kann.

Für die Wahl des Backend-Standorts ist der Ansatz providerunabhängig: Die Zielsysteme können in ayedo Managed Kubernetes , in eigenen Kubernetes-Clustern oder bei anderen Providern betrieben werden. Kubernetes-native Integration ist daher nicht auf einen einzelnen Compute-Betrieb beschränkt. Die Edge Cloud übernimmt den öffentlichen TCP-Eingang und die Verteilung; die Compute-Infrastruktur bleibt für Anwendung und Workload verantwortlich.

Anycast-basierte Layer-4-Verteilung, eigene Netzwerk-Infrastruktur und ein eigenes Autonomous System bilden dabei den Netzwerkkontext der ayedo Edge Cloud. Die verteilte Multi-PoP-Architektur und das Aktiv-Aktiv-Prinzip sind relevant, wenn der öffentliche Einstieg nicht von einem einzelnen Standort abhängen soll. Wirtschaftlich reduziert das die Notwendigkeit, dieselbe öffentliche Erreichbarkeit an jedem Compute-Standort separat zu betreiben. Dafür müssen Routing, Health Checks und Zuständigkeiten zwischen Edge- und Compute-Teams eindeutig dokumentiert sein.

Praxisszenario: TCP-Dienst über mehrere Cluster verteilen

Ein Unternehmen betreibt einen TCP-basierten Dienst in zwei Kubernetes -Clustern: einen Cluster im eigenen Rechenzentrum und einen weiteren bei einem externen Provider. Beide Instanzgruppen werden als Backend-Pool hinter einem gemeinsamen öffentlichen Dienst angelegt. Die ayedo Edge Cloud verteilt neue TCP-Verbindungen per Layer 4 auf die verfügbaren Backends und prüft deren Erreichbarkeit über Health Checks.

Wichtig ist, dass beide Cluster denselben Protokoll- und Kompatibilitätsstand unterstützen. Ein bestehender TCP-Stream wird nicht während der Laufzeit auf den anderen Cluster verschoben. Bei einem Ausfall müssen Clients oder die Anwendung eine neue Verbindung aufbauen können. Werden dagegen unterschiedliche HTTP-Routen oder Mandanten auf verschiedene Cluster verteilt, reicht L4 nicht aus. Dafür wäre anwendungsbezogenes Routing auf Layer 7 erforderlich.

FAQ

Wann ist TCP Loadbalancing besser als HTTP-Loadbalancing?

Wenn Protokolltransparenz, TLS-Passthrough oder ein nicht HTTP-basiertes TCP-Protokoll erforderlich sind. HTTP-Loadbalancing ist geeigneter, sobald Routing oder Security-Regeln den Anwendungsinhalt benötigen.

Kann ein L4-Loadbalancer einzelne Requests umverteilen?

Nein. Er verteilt TCP-Verbindungen, nicht einzelne Anfragen innerhalb einer bestehenden Verbindung. Die Zuordnung bleibt für den TCP-Stream relevant.

Muss der Client die Backend-Adresse kennen?

Nein. Der Client verbindet sich mit dem öffentlichen Dienst der Edge. Backend-Pools und deren Adressen bleiben hinter dem öffentlichen Eingang verborgen.

Fazit

TCP Loadbalancing ist die passende Wahl, wenn Dienste auf stabile Transportverbindungen, Protokolltreue und eine geringe Verarbeitungstiefe angewiesen sind. Die Architektur gewinnt dadurch an Transparenz, verzichtet aber bewusst auf HTTP-basiertes Routing und anwendungsbezogene Inspektion. Entscheidend sind belastbare Health Checks, sauber definierte Backend-Pools und realistische Erwartungen an bestehende Verbindungen. Die ayedo Edge Cloud ordnet diese Aufgaben in eine providerunabhängige, verteilte Edge-Architektur ein, ohne Edge und Compute zu vermischen.