12 Min. Lesezeit

Lernziele

Am Ende dieses Moduls werden Sie in der Lage sein:

  • Entscheiden, wann die TCP-Durchleitung auf Ebene 4 die richtige Ebene für die Lastverteilung ist, anstelle der Inhaltsrouting auf Ebene 7
  • Einen Verteilungsalgorithmus für den Managed Network Load Balancer auswählen und Zielgewichtung für einen kontrollierten Canary-Test verwenden
  • Erklären, warum Ende-zu-Ende-Verschlüsselung und nicht-HTTP-Verkehr das Zertifikat auf dem Backend belassen und die TLS-Terminierung am Balancer ausschließen
  • Eine öffentliche Kante auf Ebene 7 mit einem privaten Balancer auf Ebene 4 vor der Datenebene kombinieren
  • Einen privaten Balancer auf Ebene 4 im Data Center Designer erstellen

Einheit 3.4: Lastverteilung - Ebene 4 (Netzwerk)

Einführung

Einheit 3.3 beendete TLS an einem öffentlichen Layer-7-Load Balancer, da die Edge-Ebene HTTP lesen und auf Basis des Inhalts routen musste. Die Datenebene hat das genaue Gegenteil an Anforderungen. Sie spricht Datenbank- und andere Nicht-HTTP-Protokolle, und die DSGVO- und BSI-Konformität von FinCorp verlangt, dass die Nutzlast von der Anwendungsebene bis zur Datenbank verschlüsselt bleibt, ohne dass ein Zwischenpunkt sie lesen kann. Ein inhaltsbewusster Load Balancer kann diese Ebene nicht bedienen und sollte es auch nicht versuchen.

Diese Einheit behandelt den Managed Network Load Balancer (NLB), den Layer-4-TCP-Load Balancer der Plattform, und schließt mit dem Aufbau eines privaten NLB vor der Datenebene von FinCorp innerhalb des in Einheit 3.1 erstellten VDC ab. Die Designentscheidung ist bewusst eng gefasst: TCP-Verbindungen über gesunde Ziele verteilen, ohne sie jemals zu entschlüsseln oder zu inspizieren.

1. Layer 4 TCP Pass-Through und wann es sich durchsetzt

Der Managed Network Load Balancer arbeitet auf der TCP/IP-Ebene 4 des OSI-Modells und bietet verbindungsbasierte Lastverteilung. Es handelt sich um ein vorkonfiguriertes VDC-Element, das vollständig verwaltet wird, in einer hochverfügbaren Konfiguration bereitgestellt ist und in das softwaredefinierte Netzwerk der Plattform integriert ist. Es dient als einziger Ein- und Ausgangspunkt für den Client-Verkehr: Der Listener nimmt Verbindungen an, und Weiterleitungsregeln verteilen die Sitzungen auf mehrere Berechnungsziele zur parallelen Verarbeitung.

Das entscheidende Merkmal ist, was der NLB nicht tut. Er verteilt jeden TCP-basierten Verkehr, einschließlich Protokolle höherer Ebenen wie HTTP und HTTPS, aber seine Weiterleitungsregeln und Health Checks sind strikt TCP. Routing-Entscheidungen auf Basis einer URL oder eines HTTP-Headers werden nicht unterstützt. Der NLB entschlüsselt die Verbindung niemals, daher terminiert er TLS nie. Wenn ein Client eine verschlüsselte Verbindung öffnet, wird die TLS-Sitzung mit dem Backend-Ziel aufgebaut, und das Zertifikat sowie der private Schlüssel befinden sich auf diesem Backend, nicht auf dem Load Balancer. Genau dieses Verhalten wird von der Daten-Ebene benötigt.

Zwei Situationen machen Layer 4 zur zwingenden Wahl und nicht nur zu einer Präferenz:

  • End-to-End-Verschlüsselung. Wenn das Sicherheitsmodell erfordert, dass die Nutzlast vom Client (oder der vorgelagerten Ebene) bis zum Backend verschlüsselt bleibt, ohne dass ein dazwischenliegender Entschlüsselungsschritt erfolgt, ist ein Layer 7 Load Balancer nicht geeignet, da die Terminierung von TLS eine Entschlüsselung bedeutet. Der NLB leitet den verschlüsselten TCP-Stream unverändert weiter, sodass das Backend das Zertifikat behält und der einzige Ort ist, an dem Klartextdaten existieren. Für den regulierten Datenpfad von FinCorp schließt dies den Load Balancer aus der Menge der Komponenten aus, die Klartext-Kundendaten verarbeiten, was die Datenschutzprüfung vereinfacht.
  • Nicht-HTTP-Verkehr. Datenbankprotokolle (PostgreSQL, MariaDB Wire Protocols), Message Broker und andere TCP-Dienste sind kein HTTP, daher gibt es nichts, worauf ein Layer 7 Load Balancer routen könnte. Layer 4 ist die einzige Ebene, die passt.

Da der NLB den Anwendungsinhalt nicht lesen kann, kann er auch keine inhaltsbewussten Funktionen ausführen: keine Pfadregeln, kein Host-Routing, keine HTTP-bewusste Health Probing. Wenn Sie diese Funktionen benötigen, befinden Sie sich auf der falschen Ebene, und Einheit 3.3 ist die Antwort. Die ehrliche Einordnung ist, dass Layer 4 und Layer 7 nicht hierarchisch geordnet sind; sie befinden sich an verschiedenen Punkten der Architektur und lösen unterschiedliche Probleme.

1.1 Adressübersetzung und das Verbindungsmodell

Das Verständnis, wie der Verkehr tatsächlich durch den NLB fließt, erklärt einige seiner Einschränkungen. Der NLB führt eine Ziel-NAT (DNAT) durch: Client-Verbindungen enden am Load Balancer, und der Load Balancer initiiert dann eine separate, dedizierte Verbindung zum gewählten Backend-Ziel. Source NAT (SNAT) wird nicht unterstützt, was bedeutet, dass Ziele keine ausgehenden Verbindungen über den Load Balancer initiieren können. Der NLB ist ein Gerät für die eingehende Verteilung, kein Ausgangspfad. Wenn private Workloads ausgehenden Internetzugang benötigen, ist das die Aufgabe des NAT Gateway (nur SNAT, behandelt in Einheit 3.6), und die beiden Produkte sind komplementär und nicht austauschbar.

Da der Load Balancer seine eigene Verbindung zum Ziel öffnet, sieht das Backend standardmäßig die Adresse des Load Balancers und nicht die ursprüngliche Client-Adresse. Wenn das Backend die echte Client-IP benötigt (für Protokollierung, Geo-Logik oder Rate Limiting), aktivieren Sie Proxy Protocol am Ziel, damit die ursprünglichen Verbindungsinformationen erhalten und weitergeleitet werden. Der Backend-Dienst (zum Beispiel Apache, NGINX oder ein In-Cluster-Ingress-Controller) muss so konfiguriert sein, dass er den Proxy Protocol-Header erwartet und analysiert, andernfalls schlagen die Verbindungen fehl.

1.2 Verteilungsalgorithmen und Canary-Gewichtung

Eine Weiterleitungsregel enthält einen Verteilungsalgorithmus. Der NLB bietet vier an:

  • Round Robin: verteilt Verbindungen in einer kreisförmigen, sequenziellen Reihenfolge auf die Ziele, wobei das Gewicht jedes Ziels berücksichtigt wird.
  • Least Connections: sendet die nächste Verbindung an das Ziel mit der geringsten Anzahl aktiver Verbindungen, was für langlebige oder ungleichmäßige Sitzungen geeignet ist.
  • Random: verteilt Verbindungen zufällig auf die Ziele.
  • Source IP: ordnet einen Client basierend auf seiner Quelladresse konsistent demselben Ziel zu.

Unabhängig vom Algorithmus hält der NLB aktive Sitzungen über die Quell-IP-Affinität (sticky sessions) an demselben Ziel fest, solange die zugrunde liegenden TCP-Sitzungen aktiv bleiben. Die Quell-IP-Affinität ist das, was eine Verbindung an einem Backend festhält; die Auswahl des Source IP-Algorithmus erweitert diese Festigkeit, um einen bestimmten Client über mehrere Verbindungen hinweg auf demselben Server zu halten, was wichtig ist, wenn Backends keinen TLS-Zustand teilen und Sie eine erneute Aushandlung mit einem anderen Knoten vermeiden möchten.

Jedes Ziel hat ein Gewicht von 1 bis 256, standardmäßig 1, und der Verkehr wird proportional zum Gewicht eines Ziels im Verhältnis zum Gesamtgewicht aller Ziele verteilt. Dies ist der Mechanismus für eine kontrollierte Canary-Strategie. Um etwa zehn Prozent der neuen Verbindungen zu einem Kandidaten-Build zu senden, registrieren Sie das Canary-Ziel mit einem niedrigen Gewicht gegenüber stabilen Zielen mit höherem Gewicht (zum Beispiel Gewicht 1 für das Canary-Ziel gegenüber Gewicht 9 für das bestehende Ziel) und überwachen Sie dessen Gesundheit und Metriken, bevor Sie das Gewicht erhöhen. Die Gewichtung steuert nur neue Verbindungen; Sitzungen, die bereits durch die Quell-IP-Affinität festgelegt sind, bleiben an ihrem Ort, bis sie geschlossen werden, daher erfolgt ein Gewichtswechsel schrittweise und nicht sofort. Für FinCorp ermöglicht die Canary-Gewichtung, dass ein neuer Datenzugriffsdienst einen kleinen, beobachtbaren Anteil des realen Verkehrs übernimmt, ohne einen Flag-Day-Wechsel.

2. Zusammensetzung von öffentlichem Layer 7 mit privatem Layer 4

Die kanonische geschichtete Struktur aus Einheit 1.2 platziert einen öffentlichen Layer-7-Load Balancer an der Kante und einen privaten Layer-4-Load Balancer vor der Datenschicht. Die beiden sind nicht redundant; jeder übernimmt Aufgaben, die der andere nicht erfüllen kann.

Der öffentliche Layer-7-Load Balancer (Einheit 3.3) befindet sich an der öffentlichen Kante, beendet TLS und routet HTTP nach Inhalt auf die zustandslose Anwendungsschicht. Der private NLB befindet sich vollständig in einem privaten Netzwerk: Sein Listener ist nur internem Traffic ausgesetzt, sodass er Ost-West-Verbindungen innerhalb des Rechenzentrums verarbeitet, statt Nord-Süd-Internet-Traffic. Die Anwendungsschicht öffnet verschlüsselte TCP-Verbindungen zum privaten Listener des NLB, der NLB verteilt diese auf die Ziele der Datenschicht, und TLS wird auf diesen Zielen beendet. Keine öffentliche IP berührt die Datenschicht, und keine Komponente zwischen der Anwendung und der Datenbank kann die Nutzlast lesen.

Diese Zusammensetzung verdeutlicht auch eine Sicherheitsgrenze, die viele überrascht. NIC-Firewalls und Network Security Groups sind nur an Server-NICs gebunden; sie gelten nicht für den verwalteten Load Balancer (Einheit 3.2). Der NLB trägt zwar grundlegende Firewall-Regeln, die automatisch aus seinen Weiterleitungsregeln abgeleitet werden und nicht bearbeitet werden können, aber es ist nicht möglich, eine NSG daran anzubinden, und es gibt keine IP-Zugriffsliste auf dem Balancer selbst. Die Zugriffskontrolle für die Datenschicht liegt daher in den eigenen NIC-Firewalls der Ziele und in der Topologie: Das Daten-LAN bleibt privat, und das Einzige, das es erreichen sollte, ist die Anwendungsschicht über den NLB. Die Beibehaltung des NLB als privat ist selbst eine primäre Kontrolle, da ein privater Listener per Konstruktion aus dem Internet nicht erreichbar ist.

Ein praktischer Hinweis zur Platzierung: Im Data Center Designer hat das NLB-Element zwei Schnittstellen. Die nördliche Schnittstelle ist der Listener und verbindet in Richtung der Clients (ein Internet-Zugriffselement für einen öffentlichen NLB oder ein privates LAN für einen privaten); die südliche Schnittstelle ist das Backend und verbindet mit dem privaten LAN, das die Ziele enthält. Für die Datenschicht von FinCorp bleiben sowohl die Listener-Seite als auch die Backend-Seite auf privaten LANs.

Implementierungsdurchlauf für DCD

Sie erstellen einen privaten Layer-4-Load Balancer vor der Datenebene von FinCorp und verwenden dabei das VDC sowie die Topologie mit drei LANs aus Einheit 3.1 wieder. Das Ziel ist ein privater NLB, dessen Listener dem Anwendungslan zugewandt ist und dessen Backend dem privaten Datenlan zugewandt ist. Der Load Balancer verteilt verschlüsselte TCP-Verbindungen auf die Ziele der Datenebene, ohne TLS zu terminieren. Voraussetzung ist, dass die Ziele (die Server der Datenebene) bereits auf einem privaten LAN bereitgestellt wurden; der NLB benötigt vorhandene Ziele, um Sitzungen darauf zu verteilen.

Bauziel: Erstellen eines privaten Layer-4-Load Balancers vor der Datenebene.

Schritte (im Data Center Designer):

  1. Öffnen Sie das FinCorp VDC aus Einheit 3.1 im Data Center Designer.
  2. Ziehen Sie das Element Network Load Balancer in den Arbeitsbereich.
  3. Verknüpfen Sie die beiden Schnittstellen des NLB. Verknüpfen Sie die nördliche Schnittstelle (den Listener) mit dem privaten Anwendungslan, damit der Load Balancer internen Clients zugewandt ist und nicht dem Internet. Verknüpfen Sie die südliche Schnittstelle (das Backend) mit dem privaten LAN, das die Ziele der Datenebene hostet. Die Tatsache, dass beide Seiten an private LANs angeschlossen sind, macht dies zu einem privaten, Ost-West-Load Balancer.
  4. Öffnen Sie im Inspector den Tab Einstellungen und konfigurieren Sie die Listener-IP. Ein privater NLB erhält eine private IP; weisen Sie sie aus dem Anwendungslan zu, damit die Anwendungsebene eine stabile Adresse hat, mit der sie sich verbinden kann.
  5. Öffnen Sie den Tab Weiterleitungsregeln und wählen Sie Weiterleitungsregel hinzufügen aus. Benennen Sie die Regel, wählen Sie den Verteilungsalgorithmus (zum Beispiel Least Connections für Datenbankverbindungen oder Source IP, wenn ein Client an einem Knoten festgebunden werden soll), und bestätigen Sie das Feld Protokoll, das auf TCP voreingestellt ist. Setzen Sie die Listener-IP und den Listener-Port, auf dem der Load Balancer Verbindungen annimmt (zum Beispiel den Datenbankport).
  6. Wählen Sie innerhalb der Regel für jeden Server der Datenebene Ziel hinzufügen aus. Geben Sie die Ziel-IP und den Zielport an und setzen Sie das Gewicht (1 bis 256, Standardwert 1); verwenden Sie ungleiche Gewichte, um einen Canary-Test durchzuführen. Aktivieren Sie Proxy Protocol am Ziel, falls das Backend die ursprüngliche Client-IP benötigt, und konfigurieren Sie das Backend entsprechend zum Auslesen.
  7. Konfigurieren Sie die Einstellungen für die Health Check der Weiterleitungsregel. Die Prüfungen sind TCP-basiert. Die Standardwerte sind eine Client-Timeout von 50000 ms, eine Verbindungs-Timeout von 5000 ms und eine Ziel-Timeout von 50000 ms; passen Sie die Verbindungs-Timeout an die Geschwindigkeit an, mit der Sie ein nicht reagierendes Ziel als ungültig markieren und aus der Rotation entfernen möchten.
  8. Stellen Sie die Änderungen bereit. Der Load Balancer wird gemäß den Einstellungen aktiv und leitet nur an Ziele weiter, die den Health Check bestehen.

Häufige Fehler:

  • Die Erwartung, dass der NLB TLS terminiert. Das tut er nicht. Das Zertifikat und der private Schlüssel verbleiben auf den Backend-Zielen; planen Sie kein Design mit Zertifikat am Load Balancer auf Layer 4.
  • Der Versuch, nach URL oder HTTP-Pfad zu routen. Weiterleitungsregeln und Health Checks sind strikt TCP; Inhaltsrouting ist eine Aufgabe für Layer 7 (Einheit 3.3).
  • Der Versuch, eine Network Security Group oder eine IP-Zulassungsliste am NLB anzuhängen. Es gibt keine. Die automatisch generierten Firewall-Regeln des NLB können nicht bearbeitet werden; setzen Sie die Filterung in den NIC-Firewalls der Ziele und halten Sie den Listener privat.
  • Die Annahme, dass der NLB den Zielen ausgehenden Internetzugang bietet. Es handelt sich nur um DNAT für eingehenden Verkehr; SNAT wird nicht unterstützt. Stellen Sie ein NAT Gateway bereit (Einheit 3.6) für privaten ausgehenden Verkehr.
  • Die Vergesslichkeit, dass das Backend die Adresse des Load Balancers sieht. Wenn die Anwendung die echte Client-IP benötigt, aktivieren Sie Proxy Protocol am Ziel und konfigurieren Sie das Backend entsprechend, andernfalls brechen die Verbindungen ab.
  • Das Zeigen des NLB auf Ziele, die noch nicht existieren. Die Ziele müssen auf ihrem privaten LAN bereitgestellt sein, bevor der Load Balancer etwas zum Verteilen hat.

Zusammenfassung

Der Managed Network Load Balancer ist der Layer-4-TCP-Load Balancer der Plattform: Er verteilt Verbindungen auf gesunde Ziele mit Round Robin, Least Connections, Random oder Source IP, gewichtet Ziele von 1 bis 256 zur Canary-Steuerung und führt DNAT durch, sodass Client-Verbindungen am Load Balancer enden und eine neue Verbindung zum Ziel geöffnet wird. Er entschlüsselt den Datenverkehr niemals und beendet daher TLS nie, was genau der Grund ist, warum er für nicht-HTTP-Protokolle und durchgängig verschlüsselte Datenpfade geeignet ist, bei denen das Zertifikat auf dem Backend verbleiben muss. Privat vor der Datenebene von FinCorp platziert, hinter der öffentlichen Layer-7-Kante, vervollständigt er die geschichtete Struktur aus Einheit 1.2, ohne öffentliche Erreichbarkeit und ohne einen lesbaren Zwischenstopp zwischen Anwendung und Datenbank.

Wichtige Punkte:

  • Layer 4 ist TCP-Pass-through: Jeder TCP-Datenverkehr wird verteilt, aber Regeln und Health Checks sind strikt TCP, sodass keine Inhaltsbasierung möglich ist.
  • Der NLB beendet TLS nicht; das Backend behält das Zertifikat, was durchgängige Verschlüsselung und nicht-HTTP-Datenverkehr ermöglicht.
  • Die Algorithmen sind Round Robin, Least Connections, Random und Source IP; Sticky Sessions sind Source-IP-Affinität, die gehalten wird, solange TCP-Verbindungen aktiv sind.
  • Zielgewichte (1 bis 256, Standard 1) verteilen den Datenverkehr proportional und sind der Canary-Mechanismus; Gewichtung steuert nur neue Verbindungen.
  • DNAT nur eingehend, kein SNAT; der NLB bietet keinen Ausgangsverkehr (NAT Gateway verwenden). Keine NSG oder IP-Allowlist ist an den verwalteten Load Balancer gebunden, daher gehört die Filterung zu den Zielen.
  • Kombinieren Sie eine öffentliche Layer-7-Kante mit einem privaten Layer-4-Load Balancer vor einer nur privat zugänglichen Datenebene.