11 Min. Lesezeit

Lernziele

Am Ende dieses Moduls werden Sie in der Lage sein:

  • Entscheiden, wann Schicht 4 TCP-Durchleitung die richtige Lastverteilungsebene ist, anstelle der Schicht 7-Inhaltsweiterleitung
  • Ein Managed Network Load Balancer-Verteilungsalgorithmus auswählen und Zielgewichtung für ein kontrolliertes Canary-Testen verwenden
  • Erklären, warum Ende-zu-Ende-Verschlüsselung und nicht-HTTP-Datenverkehr das Zertifikat auf dem Backend halten und eine TLS-Beendigung am Lastenausgleich ausgeschlossen wird
  • Eine öffentliche Schicht 7-Kante mit einem privaten Schicht 4-Lastenausgleich vor der Datenebene komponieren
  • Ein privaten Schicht 4-Lastenausgleich im Data Center Designer aufbauen

Einheit 3.4: Lastverteilung - Schicht 4 (Netzwerk)

Einführung

Einheit 3.3 beendete TLS an einem öffentlichen Layer-7-Lastenausgleich, da die Kante HTTP lesen und basierend auf Inhalten routen musste. Die Datenebene hat das gegenteilige Erfordernis. Sie spricht Datenbank und andere nicht-HTTP-Protokolle, und FinCorps GDPR-/BSI-Haltung möchte die Nutzlast vom Anwendungstier bis zur Datenbank verschlüsselt haben, ohne Zwischeninstanz, die sie lesen kann. Ein inhaltsbehafteter Lastenausgleich kann diese Ebene nicht bedienen und sollte es auch nicht versuchen.

Diese Einheit behandelt den Managed Network Load Balancer (NLB), die Plattform-Layer-4-TCP-Load Balancer und endet mit dem Aufbau eines privaten NLB vor FinCorps Datenebene innerhalb des virtuellen Rechenzentrums, das Sie in Einheit 3.1 erstellt haben. Die Designentscheidung ist bewusst eng gefasst: TCP-Verbindungen auf gesunde Ziele verteilen, ohne sie jemals zu entschlüsseln oder zu untersuchen.

1. Layer 4 TCP-Durchleitung und wann sie gewinnt

Das Managed Network Load Balancer operiert auf TCP/IP Layer 4 des OSI-Modells und bietet connectionsbasiertes Lastenausgleichsverfahren. Es ist ein vor konfiguriertes VDC-Element, vollständig gemanagt, in einer hochverfügbaren Einrichtung bereitgestellt und in die softwaredefinierte Netzwerktopologie der Plattform integriert. Es dient als einziger Eingangs- und Ausgangspunkt für Client-Datenverkehr: der Listener akzeptiert Verbindungen und Weiterleitungsregeln verteilen die Sitzungen auf mehrere Rechenziele für die parallele Verarbeitung.

Die definierende Eigenschaft ist, was der NLB nicht tut. Er verteilt jeden TCP-basierten Datenverkehr, einschließlich höherer Protokolle wie HTTP und HTTPS, aber seine Weiterleitungsregeln und Gesundheitsprüfungen sind strikt TCP. Routenentscheidungen basierend auf einer URL oder HTTP-Kopfzeile werden nicht unterstützt. Der NLB entschlüsselt die Verbindung nie, daher beendet er nie TLS. Wenn ein Client eine verschlüsselte Verbindung öffnet, wird die TLS-Sitzung mit dem Backend-Ziel hergestellt und das Zertifikat und der private Schlüssel leben auf diesem Backend, nicht auf dem Lastenausgleich. Dies ist genau das Verhalten, das die Datenebene wünscht.

Zwei Situationen machen Layer 4 zur obligatorischen Wahl anstelle einer Vorliebe:

  • End-to-End-Verschlüsselung. Wenn das Sicherheitsmodell erfordert, dass die Nutzlast vom Client (oder der vorherigen Ebene) bis zum Backend ohne Entschlüsselungssprung dazwischen verschlüsselt bleibt, ist ein Layer-7-Lastenausgleich disqualifiziert, da die Beendigung von TLS eine Entschlüsselung bedeutet. Der NLB lässt den verschlüsselten TCP-Datenstrom unberührt durch, sodass das Backend das Zertifikat behält und der einzige Ort bleibt, an dem der Klartext existiert. Für den regulierten Datenpfad von FinCorp entfernt dies den Lastenausgleich aus der Menge der Komponenten, die mit Klartext-Kundendaten arbeiten, was die Datenschutzbewertung vereinfacht.
  • Nicht-HTTP-Datenverkehr. Datenbankprotokolle (PostgreSQL, MariaDB-Drahtprotokolle), Message-Broker und andere TCP-Dienste sind nicht HTTP, daher gibt es nichts für einen Layer-7-Lastenausgleich, auf dem er routingen kann. Layer 4 ist die einzige Ebene, die passt.

Da der NLB keinen Anwendungsinhalt lesen kann, kann er auch nichts bewusst machen: keine Pfadregeln, keine Host-Weiterleitung, keine HTTP-bewusste Gesundheitsprüfung. Wenn Sie diese benötigen, sind Sie auf der falschen Ebene und Einheit 3.3 ist die Antwort. Die ehrliche Darstellung ist, dass Layer 4 und Layer 7 nicht rangiert sind; sie sitzen an verschiedenen Punkten in der Architektur und lösen unterschiedliche Probleme.

1.1 Adressübersetzung und Verbindungsmodell

Das Verständnis, wie der Datenverkehr tatsächlich durch den NLB fließt, erklärt mehrere seiner Einschränkungen. Der NLB führt eine Ziel-NAT (DNAT) durch: Client-Verbindungen enden auf dem Load Balancer und der Lastenausgleich initiiert dann eine separate, dedizierte Verbindung zum gewählten Backend-Ziel. Quell-NAT (SNAT) wird nicht unterstützt, was bedeutet, dass Ziele keine ausgehenden Verbindungen über den Load Balancer herstellen können. Der NLB ist ein Gerät für die Verteilung von eingehenden Daten, nicht für den Ausgangspfad. Wenn private Workloads ausgehenden Internetzugriff benötigen, ist das die Aufgabe des NAT-Gateways (SNAT-only, in Einheit 3.6 behandelt) und die beiden Produkte sind komplementär und nicht austauschbar.

Da der Lastenausgleich seine eigene Verbindung zum Ziel herstellt, sieht das Backend standardmäßig die Adresse des Lastenausgleichs anstelle der ursprünglichen Client-Adresse. Wo das Backend die reale Client-IP (für Protokollierung, Geo-Logik oder Rate-Limiting) benötigt, aktivieren Sie das Proxy-Protokoll auf dem Ziel, damit die ursprüngliche Verbindungsinformation erhalten und weitergeleitet wird. Der Backend-Service (z.B. Apache, NGINX oder ein Ingress-Controller innerhalb von Cluster) muss so konfiguriert sein, dass er das Proxy-Protokoll-Header erwartet und analysiert, oder die Verbindungen schlagen fehl.

1.2 Verteilungsalgorithmen und Canary-Gewichtung

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

  • Round Robin: verteilt Verbindungen in einer kreisförmigen, sequenziellen Reihenfolge, wobei jedem Ziel sein Gewicht zugewiesen wird.
  • Least Connections: sendet die nächste Verbindung an das Ziel mit den wenigsten aktiven Verbindungen, was für langfristige oder ungleichmäßige Sitzungen geeignet ist.
  • Zufällig: verteilt Verbindungen zufällig auf die Ziele.
  • Quell-IP: ordnet einem Client konsistent das gleiche Ziel basierend auf seiner Quelladresse zu.

Unabhängig vom Algorithmus behält der NLB aktive Sitzungen über die Quell-IP-Affinität (sticky Sitzungen) solange auf dem gleichen Ziel, wie die zugrunde liegenden TCP-Sitzungen aktiv bleiben. Die Quell-IP-Affinität ist es, die eine Verbindung auf einem Backend hält; die Auswahl des Quell-IP-Algorithmus verlängert diese Klebrigkeit, um einen gegebenen Client auf dem gleichen Server über Verbindungen hinweg zu halten, was wichtig ist, wenn Backends keinen TLS-Zustand teilen und Sie eine Neuvereinbarung gegen ein anderes Node vermeiden möchten.

Jedes Ziel trägt ein Gewicht von 1 bis 256, das standardmäßig auf 1 gesetzt ist, und der Datenverkehr wird im Verhältnis zum Gewicht des Ziels im Vergleich zum kombinierten Gewicht aller Ziele verteilt. Dies ist der Mechanismus für eine kontrollierte Canary. Um etwa zehn Prozent der neuen Verbindungen an einen Kandidaten-Build zu senden, registrieren Sie das Canary-Ziel mit einem niedrigen Gewicht gegenüber höher gewichteten stabilen Zielen (z.B. Gewicht 1 auf dem Canary gegenüber Gewicht 9 auf dem etablierten) und beobachten Sie seine Gesundheit und Metriken, bevor Sie das Gewicht erhöhen. Die Gewichtung lenkt neue Verbindungen nur; Sitzungen, die bereits durch Quell-IP-Affinität festgelegt sind, bleiben, wo sie sind, bis sie geschlossen werden, sodass eine Gewichtsänderung allmählich abläuft, anstatt sofort zu erfolgen. Für FinCorp ermöglicht die Canary-Gewichtung es, dass ein neuer Datenzugriffsdienst einen kleinen, beobachtbaren Anteil des realen Datenverkehrs ohne eine Flag-Tag-Übernahme erhält.

2. Zusammensetzung der öffentlichen Schicht 7 mit der privaten Schicht 4

Die kanonische geschichtete Form aus Einheit 1.2 platziert einen öffentlichen Lastenausgleich der Schicht 7 am Rand und einen privaten Lastenausgleich der Schicht 4 vor der Datenebene. Die beiden sind nicht redundant; jeder erfüllt eine Funktion, die der andere nicht kann.

Der öffentliche Lastenausgleich der Schicht 7 (Einheit 3.3) befindet sich am öffentlichen Rand, beendet TLS und leitet HTTP basierend auf dem Inhalt an die stateless-Anwendungsebene weiter. Der private NLB befindet sich vollständig in einem privaten Netzwerk: sein Listener ist nur internen Datenverkehrs ausgesetzt, daher behandelt er Verbindungen innerhalb des Rechenzentrums anstelle von Internet-Datenverkehr von Nord nach Süd. Die Anwendungsebene öffnet verschlüsselte TCP-Verbindungen zum privaten Listener des NLB, der NLB verteilt sie auf die Ziele der Datenebene, und TLS wird auf diesen Zielen beendet. Kein öffentlicher IP erreicht die Datenebene, und kein Komponente zwischen der Anwendung und der Datenbank kann die Nutzlast lesen.

Diese Zusammensetzung klärt auch eine Sicherheitsgrenze, die viele Menschen nicht beachten. NIC-Feuerwände und Network Security Groups binden nur an Server-NICs; sie gelten nicht für die gemanagte Load Balancer (Einheit 3.2). Der NLB trägt grundlegende Firewall-Regeln, die automatisch von seinen Weiterleitungsregeln angewendet werden und nicht bearbeitet werden können, aber Sie können keine NSG daran anhängen und es gibt keine IP-Zulassungsliste auf dem Lastenausgleich selbst. Die Zugriffskontrolle für die Datenebene gehört daher auf die NIC-Feuerwände der Ziele und auf die Topologie: die Daten LAN bleiben privat, und das Einzige, das sie erreichen sollte, ist die Anwendungsebene durch den NLB. Die Tatsache, dass der NLB privat ist, ist selbst eine primäre Kontrolle, da ein privater Listener von Natur aus nicht von Internet aus erreichbar ist.

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

DCD Implementierung Schritt-für-Schritt

Sie werden einen privaten Layer-4-Lastverteiler vor dem Datentier von FinCorp erstellen, indem Sie das virtuelle Rechenzentrum und die drei-LAN-Topologie aus Einheit 3.1 wiederverwenden. Das Ziel ist ein privater NLB, dessen Listener der Anwendungs-LAN zugewandt ist und dessen Backend dem privaten Daten-LAN zugewandt ist, wobei verschlüsselte TCP-Verbindungen auf die Datentier-Ziele verteilt werden, ohne dass TLS beendet wird. Die Voraussetzung ist, dass die Ziele (die Datentier-Server) bereits auf einem privaten LAN bereitgestellt sind; der NLB benötigt vorhandene Ziele, um Sitzungen darauf zu verteilen.

Ziel: Erstellen Sie einen privaten Layer-4-Lastverteiler vor dem Datentier.

Schritte (im Data Center Designer):

  1. Öffnen Sie das FinCorp-virtuelle Rechenzentrum aus Einheit 3.1 im Data Center Designer.
  2. Ziehen Sie das Netzwerk-Load Balancer-Element in den Arbeitsbereich.
  3. Verbinden Sie die beiden Schnittstellen des NLB. Verbinden Sie die nördliche Schnittstelle (den Listener) mit dem privaten Anwendungs-LAN, sodass der Lastverteiler interne Clients anstelle des Internets anspricht. Verbinden Sie die südliche Schnittstelle (das Backend) mit dem privaten LAN, das die Datentier-Ziele enthält. Durch die Verbindung beider Seiten mit privaten LANs wird dieser Lastverteiler zu einem privaten, ost-west-Lastverteiler.
  4. Im Inspector öffnen Sie die Registerkarte Einstellungen und konfigurieren die Listener-IP. Ein privater NLB benötigt eine private IP; weisen Sie sie dem Anwendungs-LAN zu, damit die Anwendungsebene eine stabile Adresse zum Verbinden hat.
  5. Öffnen Sie die Registerkarte Weiterleitungsregeln und wählen Sie Weiterleitungsregel hinzufügen. Benennen Sie die Regel, wählen Sie den Verteilungsalgorithmus (z. B. Least Connections für Datenbankverbindungen oder Quell-IP, wenn Sie einen Client an einen Node binden müssen) und bestätigen Sie das Protokollfeld, das standardmäßig auf TCP eingestellt ist. Legen Sie die Listener-IP und den Listener-Port fest, auf dem der Lastverteiler Verbindungen annimmt (z. B. den Datenbank-Port).
  6. Innerhalb der Regel wählen Sie für jeden Datentier-Server Ziel hinzufügen. Geben Sie die Ziel-IP und den Ziel-Port an und legen Sie das Gewicht (1 bis 256, Standard 1) fest; verwenden Sie ungleiche Gewichte, um eine Canary-Testumgebung zu erstellen. Aktivieren Sie das Proxy-Protokoll auf dem Ziel, wenn das Backend die ursprüngliche Client-IP benötigt, und konfigurieren Sie das Backend, um es zu parsen.
  7. Konfigurieren Sie die Einstellungen für die Integritätsprüfung der Weiterleitungsregel. Die Prüfungen basieren auf TCP. Die Standardwerte sind ein Client-Timeout von 50000 ms, ein Verbindungstimeout von 5000 ms und ein Ziel-Timeout von 50000 ms; passen Sie den Verbindungstimeout an, um zu bestimmen, wie schnell ein unresponsives Ziel als nicht gesund markiert und aus der Rotation entfernt werden soll.
  8. Stellen Sie die Änderungen bereit. Der Lastverteiler wird gemäß den Einstellungen aktiv und leitet nur an Ziele weiter, die die Integritätsprüfung bestehen.

Häufige Fehler:

  • Erwarten, dass der NLB TLS beendet. Das tut er nicht. Das Zertifikat und der private Schlüssel bleiben auf den Backend-Zielen; planen Sie kein Zertifikat-auf-dem-Lastverteiler-Design auf Layer 4.
  • Versuchen, auf URL oder HTTP-Pfad zu routen. Weiterleitungsregeln und Integritätsprüfungen sind strikt TCP-basiert; Inhaltsrouten sind ein Layer-7-Job (Einheit 3.3).
  • Versuchen, eine Netzwerksicherheitsgruppe oder eine IP-Zulassungsliste an den NLB anzuhängen. Es gibt keine. Die automatisch generierten Firewall-Regeln des NLB können nicht bearbeitet werden; legen Sie Filter auf die Netzwerkkarten-Feuerwände der Ziele und halten Sie den Listener privat.
  • Annehmen, dass der NLB den Zielen ausgehenden Internetzugang gewährt. Er unterstützt nur eingehenden DNAT; SNAT wird nicht unterstützt. Stellen Sie ein NAT-Gateway (Einheit 3.6) für privaten Egress bereit.
  • Vergessen, dass das Backend die Adresse des Lastverteilers sieht. Wenn die Anwendung die tatsächliche Client-IP benötigt, aktivieren Sie das Proxy-Protokoll auf dem Ziel und konfigurieren Sie das Backend, um es zu erwarten, oder die Verbindungen werden abgebrochen.
  • Den NLB auf Ziele ausrichten, die noch nicht existieren. Die Ziele müssen vorher auf ihrem privaten LAN bereitgestellt werden, bevor der Lastverteiler etwas zu verteilen hat.

Zusammenfassung

Das Managed Network Load Balancer ist der Layer-4-TCP-Lastverteiler der Plattform: Es verteilt Verbindungen auf gesunde Ziele mithilfe von Round Robin, Least Connections, Random oder Quell-IP, gewichtet Ziele von 1 bis 256 für den Kanarienmechanismus und führt DNAT durch, sodass Clientverbindungen auf dem Lastverteiler enden und eine neue Verbindung zum Ziel geöffnet wird. Es entschlüsselt nie den Datenverkehr, sodass es nie TLS beendet, was genau der Grund ist, warum es für nicht-HTTP-Protokolle und end-to-end-verschlüsselte Datenpfade geeignet ist, bei denen das Zertifikat auf der Backend-Ebene bleiben muss. Wenn es privat vor der Daten-Ebene von FinCorp platziert wird, hinter der öffentlichen Layer-7-Kante, vervollständigt es die geschichtete Form aus Einheit 1.2 ohne öffentliche Exposition und ohne lesbaren Hop zwischen Anwendung und Datenbank.

Wichtige Punkte:

  • Layer 4 ist TCP-Durchleitung: Jeder TCP-Datenverkehr wird verteilt, aber Regeln und Gesundheitsprüfungen sind streng TCP, sodass es keine Inhaltsrouting gibt.
  • Der NLB beendet nicht TLS; die Backend-Ebene behält das Zertifikat, was es ermöglicht, end-to-end-Verschlüsselung und nicht-HTTP-Datenverkehr zu realisieren.
  • Die Algorithmen sind Round Robin, Least Connections, Random und Quell-IP; sogenannte "sticky sessions" sind Quell-IP-Affinität, die solange aufrechterhalten wird, wie die TCP-Sitzungen aktiv sind.
  • Zielgewichte (1 bis 256, Standard 1) verteilen den Datenverkehr proportional und sind der Kanarienmechanismus; das Gewichten lenkt neue Verbindungen.
  • DNAT nur für eingehenden Datenverkehr, kein SNAT; der NLB bietet keinen Egress (verwenden Sie ein NAT-Gateway). Keine NSG oder IP-Allowlist bindet sich an den gemanagten Lastverteiler, sodass die Filterung auf den Zielen erfolgt.
  • Komponieren Sie eine öffentliche Layer-7-Kante mit einem privaten Layer-4-Lastverteiler vor einer privaten Daten-Ebene.