Unternehmensverkehr besteht nicht nur aus HTTP-Anwendungen. DNS, SIP, RADIUS, NTP, rohe TCP-Services, Tunnel-Protokolle und hochvolumige Streaming-Flüsse verhalten sich anders. Bei diesen Services sind statt Inhaltsverarbeitung niedrige Latenz, geringer CPU-Verbrauch, schnelle Entscheidung und der richtige Rückweg kritischer.
Wenn L4- und L7-Load-Balancing als separate Produkte, separate Konsolen oder separate Lizenzstufen verwaltet werden, wird der Betrieb komplexer. Ein Team muss eine separate Netzwerkkomponente für DNS- und UDP-Services, ein separates ADC für Webanwendungen und eine separate Schicht für die Sicherheit verwalten. Im Problemfall kostet allein die Frage, welcher Verkehr durch welches Produkt lief, Zeit.
UDP-Verkehr erfordert besondere Aufmerksamkeit. Da der Verbindungszustand nicht so ausgeprägt ist wie bei TCP, müssen Persistence, das Verhalten der Quell-IP, der NAT-Effekt und der Antwortweg des Backends richtig entworfen werden. Während bei Protokollen wie SIP die Sitzung auf demselben Service bleiben muss, steht bei Services wie DNS und NTP die geringstmögliche Latenz im Vordergrund.
Modi wie Direct Return und IP-Tunnel bringen, richtig eingerichtet, große Vorteile; wenn die Netzwerkanforderungen aber nicht klar bekannt sind, erzeugen sie Probleme. Im Direct-Routing-Modus müssen auf den Backends VIP-Loopback-Alias, ARP-Verhalten und Rückweg-Einstellungen korrekt vorgenommen werden. Andernfalls entsteht statt eines Performance-Gewinns ein Erreichbarkeitsproblem.
Die L4-Modi von TR7 fassen latenzarme Verkehrsverteilung auf Kernel-Ebene, die zu verschiedenen Netzwerktopologien passende Moduswahl und den gemischten L4+L7-Betrieb unter einem ADC-Verwaltungsmodell zusammen.
Während TR7 L4-Verkehr auf Kernel-Ebene verarbeitet, bietet es die Verwaltung von Modus, Algorithmus, Health-Check und gemischten Services zentral an.
TR7 nutzt für das L4-Load-Balancing die Linux-LVS/IPVS-Infrastruktur. Dieser Ansatz reduziert die Verarbeitungskosten im User Space und ermöglicht schnelle Entscheidungen bei TCP- und UDP-Verkehr.
Für jeden L4-Service-Pool werden Protokoll, Algorithmus, Backend-Liste, Gewicht, Verbindungslimit und Health-Check konfiguriert. Die L4-Orchestrierungsschicht von TR7 wandelt diese Konfiguration in ausführbares L4-Balancing-Verhalten um.
NAT-, SNAT-, Direct-Routing-, IP-Tunnel- und allgemeine Protokoll-Weiterleitungsmodi dienen unterschiedlichen Bedürfnissen. Der Operator wählt den passenden Modus nach Rückweg des Verkehrs, Erhalt der Quell-IP und Platzierung des Backends.
Auf demselben TR7 können HTTP/TCP-basierte L7-Services und IPVS-basierte L4-Services Seite an Seite laufen. So können auf einer VIP verschiedene Ports an verschiedene Verarbeitungs-Engines geleitet werden.
TR7 L4-Modi bieten flexible Balancing-Optionen für verschiedene Protokolle, Netzwerktopologien und Service-Verhaltensweisen.
TR7 unterstützt NAT-, SNAT-, Direct-Routing-, IP-Tunnel- und allgemeine Protokoll-Weiterleitungsmodi. Im NAT-Modus geht der Rückverkehr über den Load Balancer. Im Direct-Routing-Modus fließt der Rückweg direkt vom Backend zum Client. Der IP-Tunnel-Modus kann in Szenarien verwendet werden, die einen entfernten Standort oder einen Übergang über ein anderes Netzwerk erfordern.
Ein L4-Service-Pool kann mit dem TCP- oder UDP-Protokoll definiert werden. UDP-Services wie DNS, SIP, RADIUS und NTP können balanciert werden, ohne sie durch die L7-Verarbeitungspipeline zu zwingen. TCP-Services können für portbasierte latenzarme Verteilung verwendet werden. Jeder Pool arbeitet mit einer Einzelprotokoll-Logik schlicht und vorhersehbar.
TR7 unterstützt Round Robin, Weighted Round Robin, Least Connection, Weighted Least Connection, Source Hash und Destination Hash. Gewichtete Algorithmen können verwendet werden, um leistungsstärkeren Backends mehr Verkehr zu senden. Hash-basierte Algorithmen erleichtern es, dieselbe Quelle oder dasselbe Ziel an denselben Service zu leiten. Diese Algorithmen laufen unabhängig von den L7-Algorithmen in den L4-Pools.
Für quell-IP-basierte Persistence kann ein Timeout-Wert definiert werden. Der Standardansatz sorgt dafür, dass dieselbe Quelle für eine bestimmte Zeit an dasselbe Backend geleitet wird. Bei SIP-Verkehr kann eine Call-ID-basierte Persistence-Engine verwendet werden. Diese Struktur hilft, das Abreißen von UDP-basiertem Sitzungsverhalten zu verhindern.
L4-Service-Pools können zusammen mit einem Health-Check verwaltet werden. Der L4-Health-Check-Mechanismus kann nicht verfügbare Backends aus der Verteilung nehmen. Über einen HTTP-basierten Check können die Management-API oder ein spezieller Health-Endpoint überwacht werden. So werden L4-Entscheidungen nicht nur nach der Portdefinition, sondern nach der tatsächlichen Service-Verfügbarkeit getroffen.
Für jedes Backend kann ein Gewichtswert definiert werden, und bei gewichteten Algorithmen wird das Verkehrsverhältnis entsprechend bestimmt. Mit einem Verbindungslimit kann die Überlastung eines einzelnen Backends begrenzt werden. Dieses Merkmal sorgt für eine ausgewogenere Nutzung von Services mit unterschiedlicher Kapazität im selben Pool. Das Operations-Team verwaltet Prozesse zum Hinzufügen von Services und zur Kapazitätserhöhung kontrollierter.
Der VRRP-Failover-Mechanismus sorgt dafür, dass die VIP zwischen dem HA-Paar verschoben wird. Beim Ausfall eines ADC-Knotens kann die VIP auf dem anderen Knoten übernommen werden. Während bei UDP-Services ein kurzzeitiger Sitzungsverlust in den meisten Szenarien akzeptabel ist, sollte bei TCP-Services das Failover-Verhalten je nach Anwendungs- und Sitzungsstruktur bewertet werden. Dieses Modell bindet L4-Services an die Hochverfügbarkeitsarchitektur.
Über die IPVS-Statistiken können Verbindungs-, Paket- und Bandbreitenverhältnisse überwacht werden. Aktuelle CPS-, Ein-/Ausgangs-Paketrate und Ein-/Ausgangs-Bandbreitenwerte können verfolgt werden. TR7 kann diese Statistiken in einer mit der Monitoring-Struktur der Plattform kompatiblen Form erzeugen. Das Operations-Team kann sehen, wie die L4-Pools tatsächlich Verkehr tragen.
Der allgemeine Protokollmodus kann für Protokolle außer TCP und UDP in allgemeinen L3-Weiterleitungsszenarien verwendet werden. Bei Verkehrsarten wie ESP, GRE oder ICMP reicht das klassische portbasierte L4-Modell möglicherweise nicht aus. In diesem Modus sind detaillierte Verbindungsstatistiken begrenzt; die Sichtbarkeit wird über grundlegende Byte-Zähler gewährleistet. Es bildet eine praktische Weiterleitungsoption für spezielle Netzwerkübergänge.
Mit der L4-Namespace-Einstellung kann ein L4-Service-Pool in einem separaten Network-Namespace-Kontext betrieben werden. Diese Struktur ist wichtig für Organisationen, die zwischen verschiedenen Mandanten oder Netzwerkbereichen trennen wollen. Mehrere Netzwerkkontexte auf demselben Gerät können kontrollierter verwaltet werden. Die Isolation erhöht in gemischten Deployment-Designs die operationelle Sicherheit.
Damit die L4-Modi korrekt funktionieren, müssen Verbindungsverfolgung, Failover-Verhalten, Direct-Routing-Anforderungen, Statistikgrenzen und Service-Verwaltung klar geplant werden.
IPVS-basiertes L4-Load-Balancing eignet sich für Services, die niedrige Latenz und hohen Durchsatz erfordern. Da im Direct-Routing-Modus der Rückverkehr den Load Balancer umgeht, bringt es besonders bei Services mit hochvolumiger Antworterzeugung Vorteile. Die reale Kapazität hängt von Netzwerkkarte, CPU, Moduswahl und Backend-Topologie ab.
Bei UDP- und intensiven L4-Services wird die Größe der Linux-Conntrack-Tabelle kritisch. Die Standardwerte reichen für großvolumigen Verkehr möglicherweise nicht aus; sie müssen nach Verkehrsvolumen geplant werden.
Die VIP kann mit VRRP zwischen dem HA-Paar verschoben werden. Beim Ausfall eines Knotens läuft der Service auf dem anderen Knoten weiter. Während sich UDP-Services oft leichter erholen, da sie meist stateless sind, sollte bei TCP-Sitzungen das Unterbrechungsverhalten je nach Anwendungstoleranz bewertet werden.
Im Direct-Routing-Modus muss das Backend die VIP als Loopback-Alias erkennen. Für das ARP-Verhalten ist die korrekte Einstellung von arp_ignore und arp_announce wichtig. Werden diese Anforderungen nicht erfüllt, kann statt des Rückweg-Vorteils ein Erreichbarkeitsproblem entstehen.
Im allgemeinen Protokoll-Weiterleitungsmodus sind die Per-Connection-Details begrenzt. Dieser Modus deckt eher den Bedarf an spezieller L3-Weiterleitung ab und wird über grundlegende Byte-Zähler überwacht. Bei Services, die eine tiefe Verbindungsanalyse erfordern, können die TCP- oder UDP-Modi besser geeignet sein.
Die L4-Pool-Statistiken können gesammelt und mit der allgemeinen Monitoring-Form der Plattform kompatibel gemacht werden. Verbindungs-, Paket- und Bandbreitenwerte können in Verlaufsspeichersysteme geschrieben werden. Dies erleichtert es, L4-Services im selben Operations-Panel wie die L7-Services zu überwachen.
Bei SIP-UDP-Verkehr kann die Nutzung von NAT das Verhalten von Quell-IP und Rückweg beeinflussen. Wenn das Backend dem Client direkt eine Antwort erzeugen möchte, muss die Moduswahl sorgfältig erfolgen. SIP-Persistence- und Direct-Routing-Optionen können in solchen Szenarien ein besser geeignetes Design ermöglichen.
Für jeden L4-Pool kann der zugehörige L4-Orchestrierungsservice überwacht werden. Service-Status, Laufzeit und letzte Statusänderung sind für das operationelle Audit wertvoll. Diese Informationen unterstützen bei L4-Konfigurationsänderungen und Failover-Untersuchungen.
Ein Telekommunikations- oder Service-Provider kann mehrere DNS-Recursor-Backends über UDP 53 balancieren. Durch Deaktivieren der Persistence wird eine latenzarme und ausgewogene DNS-Verteilung erreicht.
Eine Organisation kann mit dem Source-Hash-Algorithmus den Verkehr auf UDP 1812 und 1813 so leiten, dass derselbe Client an denselben Authentifizierungsdienst geht. Diese Struktur sorgt für eine konsistente Service-Auswahl im Authentifizierungsfluss.
In einer Telekommunikationsumgebung kann SIP-Verkehr auf UDP 5060 mit Call-ID-basierter Persistence balanciert werden. Dass derselbe Anruffluss an dasselbe Backend geht, hilft, das Sitzungsverhalten zu erhalten.
In einem Medien- oder CDN-Szenario kann der Verkehr auf TCP 80/443 im Direct-Routing-Modus betrieben werden. Da der Rückverkehr direkt vom Backend zum Client fließt, sinkt die Rücklast auf dem Load Balancer.
Bei Infrastrukturdiensten kann NTP-Verkehr auf UDP 123 mit Round Robin ausgewogen und latenzarm an die Backends verteilt werden. Für diese Verkehrsart ohne Persistence-Bedarf reicht eine schlichte Pool-Definition.
Auf derselben VIP können die Ports 80 und 443 an die L7-Verarbeitungs-Engine, Port 53 hingegen an die L4-IPVS-Engine geleitet werden. Unter einer Lizenz und einer Konsole wird eine separate Optimierung für gemischte Verkehrsarten erreicht.
Latenzarmes, modusbasiertes L4-Load-Balancing für Services wie DNS, SIP, RADIUS, NTP und Streaming. Wir führen Sie in einem Live-Setup mit Ihren eigenen Services hindurch.