Beim letzten Mal haben wir die Möglichkeiten des NSX Edge in Bezug auf statisches und dynamisches Routing besprochen. Heute werden wir uns mit dem Lastenausgleich beschäftigen.
Bevor wir mit der Konfiguration beginnen, möchte ich kurz die wichtigsten Arten der Lastenverteilung in Erinnerung rufen.
Theorie
Die heutigen Lastenausgleichslösungen werden häufig in zwei Kategorien unterteilt: Lastenverteilung auf der vierten (Transport-) und der siebten (Anwendungs-) Ebene des Modells. Das OSI-Modell ist nicht der beste Referenzpunkt zur Beschreibung von Lastenausgleichsmethoden. Wenn beispielsweise ein L4-Lastenverteiler auch TLS-Termination unterstützt, wird er dann zu einem L7-Lastenverteiler? Aber was soll's.
- L4-Lastenverteiler stellt in der Regel einen middle Proxy dar, der zwischen dem Client und einer Gruppe verfügbarer Backends steht. Dieser Proxy beendet TCP-Verbindungen (d.h. er antwortet selbst auf SYN), wählt das Backend aus und initiiert eine neue TCP-Sitzung in dessen Richtung, indem er selbständig SYN sendet. Dieser Typ ist einer der grundlegenden, es gibt jedoch auch andere Varianten.
- L7-Lastenausgleich verteilt den Datenverkehr auf verfügbare Backends „raffinierter“ als ein L4-Lastenausgleich. Er kann Entscheidungen über die Auswahl des Backends beispielsweise basierend auf dem Inhalt der HTTP-Nachricht (URL, Cookie usw.) treffen.
Unabhängig vom Typ kann der Lastenausgleich folgende Funktionen unterstützen:
- Serviceerkennung – der Prozess der Identifizierung der verfügbaren Backends (Static, DNS, Consul, Etcd usw.).
- Überprüfung der Betriebsbereitschaft der erkannten Backends (aktives „Ping“ des Backends mit einer HTTP-Anfrage, passive Erkennung von Problemen in TCP-Verbindungen, das Vorhandensein mehrerer aufeinanderfolgender 503 HTTP-Codes in den Antworten usw.).
- Die eigentliche Lastenverteilung (Round Robin, zufällige Auswahl, Hashing der Quell-IP, URI).
- TLS-Beendigung und Zertifikatsvalidierung.
- Sicherheitsbezogene Optionen (Authentifizierung, DoS-Angriffsschutz, Bandbreitenbeschränkung) und vieles mehr.
NSX Edge unterstützt zwei Bereitstellungsmodi für den Lastenausgleich:
Proxy-Modus oder One-Arm. In diesem Modus verwendet NSX Edge seine eigene IP-Adresse als Quelladresse, wenn es eine Anfrage an einen der Backends sendet. Somit agiert der Lastenausgleich sowohl als Source als auch als Destination NAT. Das Backend sieht den gesamten Verkehr als von der Lastenausgleichseinheit gesendet und antwortet direkt darauf. In diesem Szenario muss der Lastenausgleich im selben Netzwerksegment wie die internen Server sein.
So funktioniert das:
1. Der Benutzer sendet eine Anfrage an die VIP-Adresse (die Adresse des Lastenausgleichs), die auf dem Edge konfiguriert ist.
2. Edge wählt eines der Backends aus und führt ein Destination NAT durch, indem die VIP-Adresse durch die Adresse des gewählten Backends ersetzt wird.
3. Edge führt ein Source NAT durch, indem die Adresse des anfragenden Benutzers durch seine eigene ersetzt wird.
4. Das Paket wird an das gewählte Backend gesendet.
5. Der Backend-Server kommuniziert nicht direkt mit dem Benutzer, sondern über den Edge, da die ursprüngliche Adresse des Benutzers durch die Adresse des Lastenausgleichs ersetzt wurde.
6. Der Edge überträgt die Antwort des Servers an den Benutzer.
Die folgende Grafik.
Transparenter oder Inline-Modus. In diesem Szenario hat der Lastenausgleich Schnittstellen im internen und externen Netzwerk. Dabei gibt es keinen direkten Zugriff auf das interne Netzwerk von außen. Der integrierte Lastenausgleich fungiert als NAT-Gateway für die virtuellen Maschinen im internen Netzwerk.
Der Mechanismus ist wie folgt:
1. Der Benutzer sendet eine Anfrage an die VIP-Adresse (die Adresse des Lastenausgleichs), die auf dem Edge konfiguriert ist.
2. Edge wählt eines der Backends aus und führt ein Destination NAT durch, indem die VIP-Adresse durch die Adresse des gewählten Backends ersetzt wird.
3. Das Paket wird an den ausgewählten Backend-Server gesendet.
4. Der Backend-Server erhält die Anfrage mit der ursprünglichen Benutzeradresse (es wurde kein Source NAT durchgeführt) und antwortet direkt darauf.
5. Der Verkehr wird erneut vom Lastenausgleich empfangen, da er im Inline-Modus normalerweise als Standardgateway für die Serverfarm fungiert.
6. Der Edge führt ein Source NAT durch, um den Verkehr an den Benutzer zu senden, wobei er seine VIP als Source-IP-Adresse verwendet.
Die folgende Grafik.
Praxis
In meiner Testumgebung sind 3 Server mit Apache eingerichtet, der für HTTPS konfiguriert ist. Der Edge wird die HTTPS-Anfragen nach dem Round-Robin-Verfahren ausbalancieren und jede neue Anfrage an einen neuen Server weiterleiten.
Legen wir los.
Wir generieren ein SSL-Zertifikat, das mit NSX Edge verwendet wird.
Sie können ein gültiges CA-Zertifikat importieren oder ein selbstsigniertes verwenden. In diesem Test werde ich ein selbstsigniertes nehmen.
- Im vCloud Director-Interface gehen wir zu den Edge-Service-Einstellungen.
- Wir wechseln zur Registerkarte Zertifikate. Im Aktionsmenü wählen wir die Option zum Hinzufügen eines neuen CSR.
- Wir füllen die erforderlichen Felder aus und klicken auf Beibehalten.
- Wir wählen das gerade erstellte CSR aus und wählen die Option Selbstsigniertes CSR.
- Wir legen die Gültigkeitsdauer des Zertifikats fest und klicken auf Beibehalten.
- Das selbstsignierte Zertifikat ist in der Liste der verfügbaren Zertifikate erschienen.
Wir konfigurieren das Anwendungsprofil.
Anwendungsprofile bieten eine umfassendere Kontrolle über den Datenverkehr und machen das Management einfach und effizient. Sie ermöglichen die Definition von Verhalten für spezifische Verkehrsarten.
- Wir wechseln zur Registerkarte Load Balancer und aktivieren den Lastverteiler. Die Option Beschleunigung aktiviert hier ermöglicht dem Lastverteiler, eine schnellere L4-Balancierung anstelle von L7 zu verwenden.
- Wir wechseln zum Reiter Anwendungsprofil, um das Anwendungsprofil festzulegen. Klicken Sie auf +.
- Geben Sie den Namen des Profils ein und wählen Sie den Verkehrstyp aus, für den das Profil angewendet werden soll. Ich werde einige Parameter erklären.
Persistenz – speichert und verfolgt Sitzungsdaten, zum Beispiel: welcher spezifische Server aus dem Pool die Benutzeranfrage bearbeitet. Dies stellt sicher, dass die Anfragen des Benutzers während der gesamten Sitzungsdauer oder in nachfolgenden Sitzungen an dasselbe Mitglied des Pools gerichtet werden.
SSL-Passthrough aktivieren – wenn diese Option ausgewählt ist, terminiert NSX Edge das SSL nicht mehr. Stattdessen erfolgt die Terminierung direkt auf den Servern, für die die Lastverteilung durchgeführt wird.
X-Forwarded-For HTTP-Header einfügen – ermöglicht es, die ursprüngliche IP-Adresse des Clients zu bestimmen, der über den Lastverteiler eine Verbindung zum Webserver herstellt.
Pool-seitige SSL aktivieren – ermöglicht die Angabe, dass der ausgewählte Pool aus HTTPS-Servern besteht.
- Da ich HTTPS-Verkehr ausbalanciere, muss ich Pool-seitige SSL aktivieren und das zuvor generierte Zertifikat im Reiter Virtuelle Serverzertifikate -> Dienstzertifikat auswählen.
- Ähnlich für Poolzertifikate -> Dienstzertifikat.
Wir erstellen einen Serverpool, dessen Traffic balanciert wird.
- Wir wechseln zur Registerkarte Pools. Klicken Sie auf +.
- Geben Sie den Namen des Pools ein, wählen Sie den Algorithmus (ich werde Round Robin verwenden) und den Überwachungstyp für den Health Check des Backends. Die Option Transparent gibt an, ob die ursprünglichen Quell-IP-Adressen der Kunden für die internen Server sichtbar sind.
- Wenn die Option deaktiviert ist, kommt der Traffic für die internen Server mit der Quell-IP des Load Balancers.
- Wenn die Option aktiviert ist, sehen die internen Server die Quell-IP der Kunden. In dieser Konfiguration muss NSX Edge als Standard-Gateway fungieren, um sicherzustellen, dass die zurückgeschickten Pakete über NSX Edge geleitet werden.
NSX unterstützt die folgenden Lastenausgleichsalgorithmen:
- IP_HASH – Auswahl des Servers basierend auf den Ergebnissen der Hash-Funktion für die Quell- und Ziel-IP jedes Pakets.
- LEASTCONN – Lastenausgleich eingehender Verbindungen, abhängig von der Anzahl der bereits auf einem bestimmten Server vorhandenen Verbindungen. Neue Verbindungen werden an den Server mit der geringsten Anzahl von Verbindungen weitergeleitet.
- ROUND_ROBIN – Neue Verbindungen werden abwechselnd an jeden Server gemäß dem festgelegten Gewicht gesendet.
- URI – Der linke Teil der URI (bis zum Fragezeichen) wird gehasht und auf das Gesamtgewicht der Server im Pool verteilt. Das Ergebnis gibt an, welcher Server die Anfrage erhält, wobei sichergestellt wird, dass die Anfrage immer an denselben Server geleitet wird, solange alle Server verfügbar sind.
- HTTPHEADER – Die Lastverteilung basiert auf einem bestimmten HTTP-Header, der als Parameter angegeben werden kann. Wenn der Header fehlt oder keinen Wert hat, wird der ROUND_ROBIN-Algorithmus angewendet.
- URL – Bei jeder HTTP GET-Anfrage erfolgt die Suche nach dem im Argument angegebenen URL-Parameter. Wenn hinter dem Parameter ein Gleichheitszeichen und ein Wert folgen, wird der Wert gehasht und auf das Gesamtgewicht der laufenden Server verteilt. Das Ergebnis gibt an, welcher Server die Anfrage erhält. Dieser Prozess wird verwendet, um Benutzer-IDs in den Anfragen zu verfolgen und sicherzustellen, dass dieselbe Benutzer-ID immer an denselben Server gesendet wird, solange alle Server verfügbar sind.
- Im Block Mitglieder klicken wir auf +, um Server zum Pool hinzuzufügen.
1. Die Adresse des Elasticsearch-Servers (wird bei der Installation festgelegt).- Servername;
- IP-Adresse des Servers;
- Port, auf den der Server den Datenverkehr empfangen wird;
- Port für den Health Check (Überwachung des Gesundheitschecks);
- Gewicht (Weight) – mit diesem Parameter kann die proportionale Menge des empfangenen Traffics für ein bestimmtes Mitglied des Pools geregelt werden;
- Maximale Verbindungen – die maximale Anzahl von Verbindungen zum Server;
- Minimale Verbindungen – die minimale Anzahl von Verbindungen, die der Server verarbeiten muss, bevor der Traffic an das nächste Mitglied des Pools umgeleitet wird.
So sieht der endgültige Pool aus drei Servern aus.
Virtuellen Server hinzufügen
- Wechseln Sie zum Tab "Virtuelle Server". Klicken Sie auf +.
- Aktivieren Sie den virtuellen Server mit "Virtuellen Server aktivieren".
Geben Sie ihm einen Namen, wählen Sie das zuvor erstellte Anwendungsprofil, den Pool aus und geben Sie die IP-Adresse an, auf die der virtuelle Server externe Anfragen empfangen wird. Geben Sie das Protokoll HTTPS und den Port 443 an.
Optionale Parameter hier:
Verbindungsgrenze – die maximale Anzahl von gleichzeitigen Verbindungen, die der virtuelle Server verarbeiten kann;
Verbindungslimit (CPS) – die maximale Anzahl neuer eingehender Anfragen pro Sekunde.
Die Konfiguration des Lastenausgleichs ist hiermit abgeschlossen. Wir können seine Funktionalität überprüfen. Die Server verfügen über eine einfache Konfiguration, die es ermöglicht, zu erkennen, welcher Server aus dem Pool die Anfrage bearbeitet hat. Bei der Einrichtung haben wir den Round-Robin-Balancing-Algorithmus ausgewählt, und der Gewichtungsparameter für jeden Server beträgt eins, sodass jede nachfolgende Anfrage vom nächsten Server aus dem Pool bearbeitet wird.
Wir geben die externe Adresse des Lastenausgleichs in den Browser ein und sehen:
Nach dem Aktualisieren der Seite wird die Anfrage vom nächsten Server bearbeitet:
Und nochmals – um den dritten Server aus dem Pool zu überprüfen:
Bei der Überprüfung sehen wir, dass das Zertifikat, das uns von Edge gesendet wird, dasselbe ist, das wir zu Beginn generiert haben.
Überprüfung des Status des Lastenausgleichs aus der Edge-Gateway-Konsole. Geben Sie dazu ein: show service loadbalancer pool.
Konfiguration des Service Monitors zur Überprüfung des Serverstatus im Pool
Mit dem Service Monitor können wir den Status der Server im Backend-Pool überwachen. Wenn die Antwort auf eine Anfrage nicht dem Erwarteten entspricht, kann der Server aus dem Pool entfernt werden, damit er keine neuen Anfragen mehr erhält.
Standardmäßig sind drei Überwachungsmethoden konfiguriert:
- TCP-Monitor,
- HTTP-Überwachung,
- HTTPS-Überwachung.
Neuen erstellen.
- Wechseln Sie zum Tab Service Monitoring und klicken Sie auf +.
- Wählen Sie:
- einen Namen für die neue Methode;
- das Intervall, in dem die Anfragen gesendet werden,
- die Wartezeit auf eine Antwort,
- den Überwachungsmodus – HTTPS-Anfrage mit der Methode GET, erwarteter Status-Code – 200 (OK) und die URL der Anfrage.
- Mit dieser Konfiguration ist der neue Service-Monitor eingerichtet, nun können wir ihn bei der Erstellung eines Pools verwenden.
Anwendung Regeln konfigurieren
Anwendungsregeln sind Methoden zur Steuerung des Datenverkehrs basierend auf bestimmten Triggern. Mit diesem Tool können wir erweiterte Lastenausgleichsregeln erstellen, deren Konfiguration möglicherweise nicht über Anwendungsprofile oder andere auf dem Edge Gateway verfügbare Dienste möglich ist.
- Um eine Regel zu erstellen, wechseln Sie zum Tab der Anwendungsregeln des Lastenausgleichs.
- Wählen Sie den Namen, das Skript, das die Regel verwenden wird, und klicken Sie auf Beibehalten.
- Nachdem die Regel erstellt wurde, müssen wir den bereits konfigurierten Virtuellen Server bearbeiten.
- Im Tab Erweiterte Einstellungen fügen wir die von uns erstellte Regel hinzu.
Im obigen Beispiel haben wir die Unterstützung für tlsv1 aktiviert.
Ein paar weitere Beispiele:
Den Datenverkehr zu einem anderen Pool umleiten.
Mit diesem Skript können wir den Traffic auf einen anderen Load-Balancing-Pool umleiten, wenn der Hauptpool nicht funktioniert. Damit die Regel greift, müssen auf dem Load-Balancer mehrere Pools konfiguriert sein und alle Mitglieder des Hauptpools müssen im Status 'down' sein. Es muss der Name des Pools angegeben werden, nicht seine ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Traffic-Redirect auf eine externe Ressource.
Hier leiten wir den Traffic auf eine externe Webseite um, wenn alle Teilnehmer des Hauptpools im Status 'down' sind.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
Weiterleitung an http://www.example.com, wenn pool_down
Noch mehr Beispiele .
Das war alles zum Load-Balancer. Wenn Sie Fragen haben, zögern Sie nicht zu fragen, ich bin bereit, zu antworten.
Quelle: habr.com
