Beim letzten Mal haben wir über die Möglichkeiten von NSX Edge in Bezug auf statisches und dynamisches Routing gesprochen, und heute werden wir den Lastausgleich betrachten.
Bevor wir mit der Konfiguration beginnen, möchte ich kurz an die wichtigsten Arten des Lastenausgleichs erinnern.
Theorie
Alle heutigen Lösungen für den Lastenausgleich werden häufig in zwei Kategorien unterteilt: Lastenausgleich auf der vierten (Transportschicht) und der siebten (Anwendungsschicht) Ebene des Modells . Das OSI-Modell ist nicht der beste Referenzpunkt zur Beschreibung von Lastenausgleichsmethoden. Wenn ein L4-Lastausgleicher auch die TLS-Terminierung unterstützt, wird er dann in diesem Fall zu einem L7-Lastausgleicher? Aber was ist, das ist.
- L4-Lastausgleicher stellt in der Regel einen Proxy dar, der zwischen dem Client und einer Gruppe verfügbarer Backends steht, der TCP-Verbindungen terminiert (d.h. selbst auf SYN antwortet), ein Backend auswählt und eine neue TCP-Sitzung in dessen Richtung initiiert, indem er selbst SYN sendet. Dieser Typ ist einer der grundlegenden, es sind auch andere Varianten möglich.
- L7-Lastausgleicher verwendet raffiniertere Methoden, um den Verkehr auf die verfügbaren Backends zu verteilen als der L4-Lastausgleicher. Er kann Entscheidungen über die Auswahl des Backends basierend auf z.B. dem Inhalt einer HTTP-Nachricht (URL, Cookie usw.) treffen.
Unabhängig vom Typ kann der Lastausgleicher folgende Funktionen unterstützen:
- Serviceerkennung – der Prozess der Bestimmung einer Gruppe verfügbarer Backends (statisch, DNS, Consul, Etcd usw.).
- Überprüfung der Verfügbarkeit entdeckter Backends (aktives „Pingen“ des Backends mit HTTP-Anfragen, passive Erkennung von Problemen in TCP-Verbindungen, mehrfach aufeinanderfolgende 503 HTTP-Codes in den Antworten usw.).
- Selbst der Lastenausgleich (Round Robin, zufällige Auswahl, Quell-IP-Hash, URI).
- TLS-Terminierung und Zertifikatsprüfung.
- Sicherheitsbezogene Optionen (Authentifizierung, Schutz vor DoS-Angriffen, Geschwindigkeitsbegrenzung) und vieles mehr.
NSX Edge bietet Unterstützung für zwei Bereitstellungsmodi des Lastausgleichers:
Proxy-Modus oder One-Arm. In diesem Modus verwendet NSX Edge bei der Anfrage an eines der Backends seine IP-Adresse als Quelladresse. Somit führt der Load Balancer gleichzeitig die Funktionen von Source und Destination NAT aus. Das Backend sieht den gesamten Datenverkehr als von dem Load Balancer gesendet und antwortet direkt darauf. In diesem Schema muss der Load Balancer im selben Netzwerksegment wie die internen Server sein.
So funktioniert es:
1. Der Benutzer sendet eine Anfrage an die VIP-Adresse (Adresse des Load Balancers), 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 ausgewählten Backends ersetzt wird.
3. Edge führt ein Source NAT durch, indem es die Adresse des anfragenden Benutzers durch seine eigene ersetzt.
4. Das Paket wird an das gewählte Backend gesendet.
5. Das Backend antwortet nicht direkt an den Benutzer, sondern an Edge, da die ursprüngliche Adresse des Benutzers auf die Adresse des Load Balancers geändert wurde.
6. Edge überträgt die Serverantwort an den Benutzer.
Das Diagramm unten.
Transparenter oder Inline-Modus. In diesem Szenario hat der Load Balancer Schnittstellen in dem internen und externen Netzwerk. Dabei gibt es keinen direkten Zugang zum internen Netzwerk von außen. Der integrierte Lastenausgleich fungiert als NAT-Gateway für virtuelle Maschinen im internen Netzwerk.
Das Verfahren ist folgendermassen:
1. Der Benutzer sendet eine Anfrage an die VIP-Adresse (Adresse des Load Balancers), 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 ausgewählten Backends ersetzt wird.
3. Das Paket wird an das gewählte Backend gesendet.
4. Das Backend erhält die Anfrage mit der ursprünglichen Adresse des Benutzers (Source NAT wurde nicht durchgeführt) und antwortet direkt darauf.
5. Der Datenverkehr wird erneut vom Load Balancer empfangen, da er im Inline-Schema normalerweise als Standardgateway für den Serverpool fungiert.
6. Edge führt ein Source NAT durch, um den Datenverkehr an den Benutzer zu senden, wobei es seine VIP-Adresse als Quell-IP-Adresse verwendet.
Das Diagramm unten.
Praxis
In meiner Testumgebung sind 3 Server mit Apache konfiguriert, das für HTTPS eingerichtet ist. Edge wird das HTTPS-Load Balancing nach dem Round-Robin-Verfahren durchführen und jede neue Anfrage an einen neuen Server weiterleiten.
Legen wir los.
Generieren Sie ein SSL-Zertifikat, das von NSX Edge verwendet wird.
Sie können ein gültiges CA-Zertifikat importieren oder ein selbstsigniertes verwenden. In diesem Test werde ich ein selbstsigniertes verwenden.
- Im vCloud Director-Interface gehen wir zu den Edge-Dienstkonfigurationen.
- Gehen Sie zur Registerkarte Zertifikate. Wählen Sie im Aktionsmenü 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 self-sign CSR.
- Wir wählen die Gültigkeitsdauer des Zertifikats 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 Netzwerkverkehr und machen die Verwaltung einfach und effektiv. Damit kann das Verhalten für bestimmte Arten von Verkehr definiert werden.
- Wir wechseln zum Tab Lastenausgleich und aktivieren den Lastenausgleichsserver. Die Option Beschleunigung aktiviert ermöglicht es dem Lastenausgleich, eine schnellere L4-Balancierung anstelle von L7 zu verwenden.
- Wir wechseln zum Tab Anwendungsprofil, um das Anwendungsprofil festzulegen. Klicken Sie auf +.
- Wir geben den Namen des Profils an und wählen den Verkehrstyp aus, für den das Profil angewendet wird. Lassen Sie mich einige Parameter erklären.
Persistenz – speichert und verfolgt Sitzungsdaten, zum Beispiel: welcher bestimmte Server aus dem Pool die Benutzeranfrage bedient. Dies gewährleistet, dass die Benutzeranfragen während der gesamten Sitzungsdauer oder in Folge-Sitzungen an dasselbe Mitglied des Pools gerichtet werden.
SSL-Passthrough aktivieren – wenn Sie diese Option wählen, hört NSX Edge auf, SSL zu terminieren. Stattdessen erfolgt die Termination direkt auf den Servern, für die der Lastenausgleich durchgeführt wird.
X-Forwarded-For HTTP-Header einfügen – ermöglicht die Identifizierung der ursprünglichen IP-Adresse des Clients, der sich über den Lastenausgleich mit dem Webserver verbindet.
Poolseitiges SSL aktivieren – ermöglicht anzugeben, dass der ausgewählte Pool aus HTTPS-Servern besteht.
- Da ich HTTPS-Verkehr ausbalancieren möchte, muss ich Poolseitiges SSL aktivieren und das zuvor generierte Zertifikat im Tab Virtuelle Serverzertifikate auswählen —> Dienstzertifikat.
- Analog für Poolzertifikate —> Dienstzertifikat.
Wir erstellen einen Serverpool, dessen Verkehr balanciert wird Pools.
- Wir wechseln zum Tab Pools. Klicken Sie auf +.
- Wir geben den Namen des Pools an, wählen den Algorithmus (ich werde Round Robin verwenden) und den Überwachungsmodus für den Health Check des Backends. Die Option Transparent gibt an, ob die ursprünglichen Quell-IP der Clients für die internen Server sichtbar sind.
- Wenn die Option deaktiviert ist, geht der Verkehr für interne Server mit der Quell-IP des Lastenausgleichs.
- Wenn die Option aktiviert ist, sehen die internen Server die Quell-IP der Clients. In dieser Konfiguration muss NSX Edge als Standardgateway fungieren, um sicherzustellen, dass die zurückgegebenen 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 vorhandenen Verbindungen auf einem bestimmten Server. Neue Verbindungen werden an den Server mit der geringsten Anzahl von Verbindungen geleitet.
- ROUND_ROBIN – neue Verbindungen werden nacheinander an jeden Server gemäß dem ihm zugewiesenen Gewicht gesendet.
- URI – der linke Teil der URI (vor dem Fragezeichen) wird gehasht und durch das Gesamtgewicht der Server im Pool geteilt. Das Ergebnis zeigt an, welcher Server die Anfrage erhält, und sorgt dafür, dass die Anfrage immer an denselben Server geleitet wird, solange alle Server verfügbar bleiben.
- HTTPHEADER – Lastenausgleich basierend auf einem bestimmten HTTP-Header, der als Parameter angegeben werden kann. Wenn der Header fehlt oder keinen Wert hat, wird der Algorithmus ROUND_ROBIN angewendet.
- URL – in jeder HTTP GET-Anfrage wird nach dem URL-Parameter gesucht, der als Argument angegeben ist. Wenn nach dem Parameter ein Gleichheitszeichen und ein Wert folgen, wird der Wert gehasht und durch das Gesamtgewicht der laufenden Server geteilt. Das Ergebnis zeigt an, welcher Server die Anfrage erhält. Dieser Prozess wird verwendet, um Benutzer-IDs in Anfragen zu verfolgen und zu gewährleisten, dass dieselbe Benutzer-ID immer an denselben Server gesendet wird, solange alle Server verfügbar bleiben.
- Im Abschnitt Mitglieder drücken wir +, um Server zum Pool hinzuzufügen.
Hier müssen Sie angeben:- Servername;
- IP-Adresse des Servers;
- Port, über den der Server den Verkehr empfangen wird;
- Port für den Health Check (Monitor healthcheck);
- Gewicht (Weight) – mit diesem Parameter kann die proportionale Menge an empfangendem Verkehr für ein bestimmtes Mitglied des Pools geregelt werden;
- Maximale Verbindungen – maximale Anzahl von Verbindungen zum Server;
- Minimale Verbindungen – minimale Anzahl von Verbindungen, die der Server verarbeiten muss, bevor der Verkehr an das nächste Mitglied des Pools umgeleitet wird.
So sieht der endgültige Pool aus drei Servern aus.
Virtuellen Server hinzufügen
- Wir gehen zum Tab Virtuelle Server. Drücken Sie +.
- Aktivieren Sie den virtuellen Server mit der Option Virtuellen Server aktivieren.
Wir geben ihm einen Namen, wählen das zuvor erstellte Application Profile und den Pool aus und geben die IP-Adresse an, an die der Virtual Server Anfragen von außen annehmen wird. Wir wählen das Protokoll HTTPS und den Port 443.
Optionale Parameter hier:
Verbindungsbeschränkung – die maximale Anzahl gleichzeitiger Verbindungen, die der virtuelle Server verarbeiten kann;
Verbindungsrate Limit (CPS) – die maximale Anzahl neuer eingehender Anfragen pro Sekunde.
Damit ist die Konfiguration des Lastenausgleichs abgeschlossen, und wir können die Funktionsfähigkeit überprüfen. Die Server haben eine einfache Konfiguration, die es ermöglicht, zu verstehen, welcher Server aus dem Pool die Anfrage bearbeitet hat. Während 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 im Pool bearbeitet wird.
Wir geben die externe Adresse des Lastenausgleichs im Browser ein und sehen:
Nach dem Aktualisieren der Seite wird die Anfrage vom nächsten Server bearbeitet:
Und noch einmal – um den dritten Server aus dem Pool zu überprüfen:
Bei der Überprüfung kann man sehen, dass das Zertifikat, das uns der Edge sendet, das gleiche 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.
Wir konfigurieren den Service Monitor zur Überprüfung des Status der Server im Pool
Mit dem Service Monitor können wir den Zustand der Server im Backend-Pool überwachen. Wenn die Antwort auf die Anfrage nicht den Erwartungen entspricht, kann der Server aus dem Pool genommen werden, damit er keine neuen Anfragen erhält.
Standardmäßig sind drei Überprüfungsmethoden konfiguriert:
- TCP-Monitor,
- HTTP-Monitor,
- HTTPS-Monitor.
Lass uns einen neuen erstellen.
- Wir gehen zum Tab Dienstüberwachung, klicken auf +.
- Wählen Sie aus:
- einen Namen für die neue Methode;
- das Intervall, in dem Anfragen gesendet werden sollen,
- Timeout für die Antwortwartung,
- Überwachungsart – HTTPS-Anfrage unter Verwendung der Methode GET, erwarteter Statuscode – 200(OK) und URL der Anfrage.
- Damit ist die Einrichtung des neuen Service Monitors abgeschlossen, jetzt können wir ihn bei der Erstellung des Pools verwenden.
Wir konfigurieren Anwendungsregeln
Anwendungsregeln – eine Möglichkeit, den Datenverkehr basierend auf bestimmten Triggern zu steuern. Mit diesem Werkzeug können wir erweiterte Lastenausgleichsregeln erstellen, deren Konfiguration möglicherweise über Anwendungprofile oder mit anderen auf dem Edge Gateway verfügbaren Diensten nicht möglich ist.
- Um eine Regel zu erstellen, wechseln wir zur Registerkarte Anwendungsregeln des Lastenausgleichs.
- Wählen Sie einen Namen, das Skript, das die Regel verwenden wird, und klicken Sie auf Behalten.
- Nachdem die Regel erstellt wurde, müssen wir den bereits konfigurierten Virtuellen Server bearbeiten.
- In der Registerkarte Erweitert fügen wir die von uns erstellte Regel hinzu.
Im obigen Beispiel haben wir die Unterstützung für tlsv1 aktiviert.
Hier sind noch ein paar Beispiele:
Den Verkehr in einen anderen Pool umleiten.
Mit diesem Skript können wir den Verkehr in einen anderen Lastenausgleichspool umleiten, wenn der Hauptpool nicht funktioniert. Damit die Regel funktioniert, müssen mehrere Pools am Lastenausgleich konfiguriert sein und alle Mitglieder des Hauptpools müssen sich im Status down befinden. Es muss der Name des Pools angegeben werden, nicht dessen ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Den Verkehr auf eine externe Ressource umleiten.
Hier leiten wir den Verkehr auf eine externe Website um, wenn alle Teilnehmer des Hauptpools im Status down sind.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Noch mehr Beispiele .
Das wäre alles zum Lastenausgleich. Wenn noch Fragen offen sind, fragen Sie bitte, ich bin bereit zu antworten.
Quelle: habr.com
