Letztes Mal haben wir über die Fähigkeiten von NSX Edge in Bezug auf statisches und dynamisches Routing gesprochen, und heute beschäftigen wir uns mit dem Load Balancer.
Bevor wir mit der Einrichtung beginnen, möchte ich Sie kurz an die wichtigsten Arten des Auswuchtens erinnern.
Теория
Alle heutigen Nutzlastausgleichslösungen werden meist in zwei Kategorien unterteilt: Ausgleich auf der vierten (Transport) und siebten (Anwendungs) Ebene des Modells . Das OSI-Modell ist nicht der beste Bezugspunkt für die Beschreibung von Ausgleichsmethoden. Wenn beispielsweise ein L4-Balancer auch die TLS-Terminierung unterstützt, wird er dann zu einem L7-Balancer? Aber es ist, was es ist.
- Balancer L4 Meistens handelt es sich um einen mittleren Proxy, der zwischen dem Client und einer Reihe verfügbarer Backends steht, der TCP-Verbindungen beendet (d. h. unabhängig auf SYN antwortet), ein Backend auswählt und eine neue TCP-Sitzung in seine Richtung initiiert, wobei er unabhängig SYN sendet. Dieser Typ ist einer der Grundtypen; andere Optionen sind möglich.
- Balancer L7 verteilt den Datenverkehr „ausgefeilter“ auf die verfügbaren Backends als der L4-Balancer. Es kann beispielsweise anhand des Inhalts der HTTP-Nachricht (URL, Cookie usw.) entscheiden, welches Backend ausgewählt werden soll.
Unabhängig vom Typ kann der Balancer folgende Funktionen unterstützen:
- Bei der Diensterkennung handelt es sich um den Prozess der Bestimmung der verfügbaren Backends (Static, DNS, Consul usw.).
- Überprüfung der Funktionalität der erkannten Backends (aktives „Ping“ des Backends mithilfe einer HTTP-Anfrage, passive Erkennung von Problemen bei TCP-Verbindungen, Vorhandensein mehrerer 503-HTTP-Codes in den Antworten usw.).
- Der Ausgleich selbst (Round-Robin, Zufallsauswahl, Quell-IP-Hash, URI).
- TLS-Terminierung und Zertifikatsüberprüfung.
- Sicherheitsrelevante Optionen (Authentifizierung, DoS-Angriffsschutz, Geschwindigkeitsbegrenzung) und vieles mehr.
NSX Edge bietet Unterstützung für zwei Load-Balancer-Bereitstellungsmodi:
Proxy-Modus oder einarmig. In diesem Modus verwendet NSX Edge seine IP-Adresse als Quelladresse, wenn eine Anfrage an eines der Backends gesendet wird. Somit übernimmt der Balancer gleichzeitig die Funktionen von Quell- und Ziel-NAT. Das Backend sieht den gesamten vom Balancer gesendeten Datenverkehr und antwortet direkt darauf. Bei einem solchen Schema muss sich der Balancer im selben Netzwerksegment wie die internen Server befinden.
So geht es:
1. Der Benutzer sendet eine Anfrage an die VIP-Adresse (Balancer-Adresse), die auf dem Edge konfiguriert ist.
2. Edge wählt eines der Backends aus und führt Ziel-NAT durch, wobei die VIP-Adresse durch die Adresse des ausgewählten Backends ersetzt wird.
3. Edge führt Quell-NAT durch und ersetzt die Adresse des Benutzers, der die Anfrage gesendet hat, durch seine eigene.
4. Das Paket wird an das ausgewählte Backend gesendet.
5. Das Backend antwortet nicht direkt dem Benutzer, sondern dem Edge, da die ursprüngliche Adresse des Benutzers in die Adresse des Balancers geändert wurde.
6. Edge übermittelt die Antwort des Servers an den Benutzer.
Das Diagramm ist unten.
Transparenter oder Inline-Modus. In diesem Szenario verfügt der Balancer über Schnittstellen im internen und externen Netzwerk. Gleichzeitig besteht kein direkter Zugriff vom externen auf das interne Netzwerk. Der integrierte Load Balancer fungiert als NAT-Gateway für virtuelle Maschinen im internen Netzwerk.
Der Mechanismus ist wie folgt:
1. Der Benutzer sendet eine Anfrage an die VIP-Adresse (Balancer-Adresse), die auf dem Edge konfiguriert ist.
2. Edge wählt eines der Backends aus und führt Ziel-NAT durch, wobei die VIP-Adresse durch die Adresse des ausgewählten Backends ersetzt wird.
3. Das Paket wird an das ausgewählte Backend gesendet.
4. Das Backend erhält eine Anfrage mit der Originaladresse des Benutzers (Quell-NAT wurde nicht durchgeführt) und antwortet direkt darauf.
5. Der Datenverkehr wird wieder vom Load Balancer akzeptiert, da dieser in einem Inline-Schema normalerweise als Standard-Gateway für die Serverfarm fungiert.
6. Edge führt Quell-NAT durch, um Datenverkehr an den Benutzer zu senden, und verwendet dabei seine VIP als Quell-IP-Adresse.
Das Diagramm ist unten.
Praxis
Auf meinem Prüfstand laufen drei Server mit Apache, der für die Arbeit über HTTPS konfiguriert ist. Edge führt einen Round-Robin-Balancing von HTTPS-Anfragen durch und leitet jede neue Anfrage per Proxy an einen neuen Server weiter.
Lass uns anfangen.
Generieren eines SSL-Zertifikats, das von NSX Edge verwendet wird
Sie können ein gültiges CA-Zertifikat importieren oder ein selbstsigniertes Zertifikat verwenden. Für diesen Test verwende ich selbstsigniert.
- Gehen Sie in der vCloud Director-Benutzeroberfläche zu den Edge-Services-Einstellungen.
- Gehen Sie zur Registerkarte Zertifikate. Wählen Sie aus der Liste der Aktionen das Hinzufügen eines neuen CSR aus.
- Füllen Sie die erforderlichen Felder aus und klicken Sie auf „Behalten“.
- Wählen Sie die neu erstellte CSR aus und wählen Sie die Option „CSR selbst signieren“.
- Wählen Sie den Gültigkeitszeitraum des Zertifikats aus und klicken Sie auf „Behalten“.
- Das selbstsignierte Zertifikat wird in der Liste der verfügbaren Zertifikate angezeigt.
Anwendungsprofil einrichten
Anwendungsprofile geben Ihnen eine umfassendere Kontrolle über den Netzwerkverkehr und machen dessen Verwaltung einfach und effektiv. Sie können verwendet werden, um das Verhalten für bestimmte Verkehrsarten zu definieren.
- Gehen Sie zur Registerkarte Load Balancer und aktivieren Sie den Balancer. Die aktivierte Option „Beschleunigung“ ermöglicht es dem Balancer, einen schnelleren L4-Ausgleich anstelle von L7 zu verwenden.
- Gehen Sie zur Registerkarte Anwendungsprofil, um das Anwendungsprofil festzulegen. Klicken Sie auf +.
- Legen Sie den Namen des Profils fest und wählen Sie die Art des Datenverkehrs aus, für den das Profil angewendet werden soll. Lassen Sie mich einige Parameter erklären.
Beharrlichkeit – speichert und verfolgt Sitzungsdaten, zum Beispiel: welcher spezifische Server im Pool die Benutzeranfrage bearbeitet. Dadurch wird sichergestellt, dass Benutzeranfragen für die gesamte Lebensdauer der Sitzung oder nachfolgender Sitzungen an dasselbe Poolmitglied weitergeleitet werden.
Aktivieren Sie SSL-Passthrough – Wenn diese Option ausgewählt ist, stoppt NSX Edge die Beendigung von SSL. Stattdessen erfolgt die Beendigung direkt auf den Servern, die ausgeglichen werden.
Fügen Sie den HTTP-Header „X-Forwarded-For“ ein – ermöglicht es Ihnen, die Quell-IP-Adresse des Clients zu ermitteln, der über den Load Balancer eine Verbindung zum Webserver herstellt.
Aktivieren Sie Pool-seitiges SSL – ermöglicht Ihnen anzugeben, dass der ausgewählte Pool aus HTTPS-Servern besteht.
- Da ich den HTTPS-Verkehr ausgleichen werde, muss ich Pool-Side-SSL aktivieren und das zuvor generierte Zertifikat auf der Registerkarte „Virtuelle Serverzertifikate -> Dienstzertifikat“ auswählen.
- Ähnliches gilt für Poolzertifikate -> Servicezertifikat.
Wir erstellen einen Pool von Servern, deren Datenverkehr ausgeglichen wird
- Gehen Sie zur Registerkarte Pools. Klicken Sie auf +.
- Wir legen den Namen des Pools fest, wählen den Algorithmus (ich verwende Round Robin) und die Art der Überwachung für das Health-Check-Backend. Die Option „Transparent“ gibt an, ob die anfänglichen Quell-IPs der Clients für interne Server sichtbar sind.
- Wenn die Option deaktiviert ist, kommt der Datenverkehr für interne Server von der Quell-IP des Balancers.
- Wenn die Option aktiviert ist, sehen interne Server die Quell-IP der Clients. In dieser Konfiguration muss NSX Edge als Standard-Gateway fungieren, um sicherzustellen, dass zurückgegebene Pakete über NSX Edge weitergeleitet werden.
NSX unterstützt die folgenden Ausgleichsalgorithmen:
- IP_HASH – Serverauswahl basierend auf den Ergebnissen einer Hash-Funktion für die Quell- und Ziel-IP jedes Pakets.
- LEASTCONN – Ausgleich eingehender Verbindungen, abhängig von der Anzahl, die bereits auf einem bestimmten Server verfügbar ist. Neue Verbindungen werden an den Server mit den wenigsten Verbindungen weitergeleitet.
- ROUND_ROBIN – Neue Verbindungen werden der Reihe nach an jeden Server gesendet, entsprechend der ihm zugewiesenen Gewichtung.
- URI – Der linke Teil des URI (vor dem Fragezeichen) wird gehasht und durch das Gesamtgewicht der Server im Pool geteilt. Das Ergebnis gibt an, welcher Server die Anfrage empfängt. Dadurch wird sichergestellt, dass die Anfrage immer an denselben Server weitergeleitet wird, solange alle Server verfügbar bleiben.
- HTTPHEADER – Ausgleich basierend 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 – Jede HTTP-GET-Anfrage sucht nach dem als Argument angegebenen URL-Parameter. Wenn auf den Parameter ein Gleichheitszeichen und ein Wert folgen, wird der Wert gehasht und durch die Gesamtgewichtung der laufenden Server dividiert. Das Ergebnis gibt an, welcher Server die Anfrage erhält. Dieser Prozess wird verwendet, um Benutzer-IDs in Anfragen zu verfolgen und sicherzustellen, dass immer dieselbe Benutzer-ID an denselben Server gesendet wird, solange alle Server verfügbar bleiben.
- Klicken Sie im Mitgliederblock auf +, um Server zum Pool hinzuzufügen.
Hier müssen Sie angeben:- Servername;
- Server IP Adresse;
- der Port, über den der Server Datenverkehr empfängt;
- Port für Gesundheitscheck (Monitor Healthcheck);
- Gewicht – mit diesem Parameter können Sie die proportionale Menge des empfangenen Datenverkehrs für ein bestimmtes Poolmitglied anpassen;
- Max. Verbindungen – maximale Anzahl von Verbindungen zum Server;
- Min. Verbindungen – die Mindestanzahl an Verbindungen, die der Server verarbeiten muss, bevor der Datenverkehr an das nächste Poolmitglied weitergeleitet wird.
So sieht der endgültige Pool aus drei Servern aus.
Hinzufügen eines virtuellen Servers
- Gehen Sie zur Registerkarte Virtuelle Server. Klicken Sie auf +.
- Wir aktivieren den virtuellen Server mit Enable Virtual Server.
Wir geben ihm einen Namen, wählen das zuvor erstellte Anwendungsprofil Pool aus und geben die IP-Adresse an, an die der virtuelle Server Anfragen von außen empfängt. Wir geben das HTTPS-Protokoll und den Port 443 an.
Optionale Parameter hier:
Verbindungslimit – die maximale Anzahl gleichzeitiger Verbindungen, die der virtuelle Server verarbeiten kann;
Verbindungsgeschwindigkeitsbegrenzung (CPS) – die maximale Anzahl neuer eingehender Anfragen pro Sekunde.
Damit ist die Konfiguration des Balancers abgeschlossen und Sie können seine Funktionalität überprüfen. Die Server verfügen über eine einfache Konfiguration, die es Ihnen ermöglicht zu verstehen, welcher Server aus dem Pool die Anfrage verarbeitet hat. Während der Einrichtung haben wir den Round-Robin-Ausgleichsalgorithmus gewählt und der Gewichtungsparameter für jeden Server ist gleich eins, sodass jede nachfolgende Anfrage vom nächsten Server aus dem Pool verarbeitet wird.
Wir geben die externe Adresse des Balancers in den Browser ein und sehen:
Nach dem Aktualisieren der Seite wird die Anfrage von folgendem Server verarbeitet:
Und noch einmal – um den dritten Server aus dem Pool zu überprüfen:
Bei der Überprüfung können Sie erkennen, dass das Zertifikat, das Edge uns sendet, dasselbe ist, das wir ganz am Anfang generiert haben.
Überprüfen des Balancer-Status über die Edge-Gateway-Konsole. Geben Sie dazu ein Service-Loadbalancer-Pool anzeigen.
Konfigurieren Sie Service Monitor, um den Status der Server im Pool zu überprüfen
Mit Service Monitor können wir den Status der Server im Backend-Pool überwachen. Sollte die Antwort auf eine Anfrage nicht wie erwartet ausfallen, kann der Server aus dem Pool genommen werden, sodass er keine neuen Anfragen mehr erhält.
Standardmäßig sind drei Überprüfungsmethoden konfiguriert:
- TCP-Monitor,
- HTTP-Monitor,
- HTTPS-Monitor.
Lassen Sie uns ein neues erstellen.
- Gehen Sie zur Registerkarte Serviceüberwachung und klicken Sie auf +.
- Wählen:
- Name für die neue Methode;
- das Intervall, in dem Anfragen gesendet werden,
- Zeitüberschreitung beim Warten auf eine Antwort,
- Überwachungstyp – HTTPS-Anfrage mit der GET-Methode, erwarteter Statuscode – 200 (OK) und Anfrage-URL.
- Damit ist die Einrichtung des neuen Service Monitors abgeschlossen; jetzt können wir ihn beim Erstellen eines Pools verwenden.
Anwendungsregeln einrichten
Anwendungsregeln sind eine Möglichkeit, den Datenverkehr basierend auf bestimmten Auslösern zu manipulieren. Mit diesem Tool können wir erweiterte Lastausgleichsregeln erstellen, die über Anwendungsprofile oder andere auf dem Edge Gateway verfügbare Dienste möglicherweise nicht möglich sind.
- Um eine Regel zu erstellen, gehen Sie zur Registerkarte „Anwendungsregeln“ des Balancers.
- Wählen Sie einen Namen und ein Skript aus, das die Regel verwenden soll, und klicken Sie auf „Behalten“.
- Nachdem die Regel erstellt wurde, müssen wir den bereits konfigurierten virtuellen Server bearbeiten.
- Fügen Sie auf der Registerkarte „Erweitert“ die von uns erstellte Regel hinzu.
Im obigen Beispiel haben wir die TLSV1-Unterstützung aktiviert.
Noch ein paar Beispiele:
Leiten Sie den Datenverkehr zu einem anderen Pool um.
Mit diesem Skript können wir den Datenverkehr auf einen anderen Ausgleichspool umleiten, wenn der Hauptpool ausgefallen ist. Damit die Regel funktioniert, müssen mehrere Pools auf dem Balancer konfiguriert sein und alle Mitglieder des Hauptpools müssen sich im Down-Zustand befinden. Sie müssen den Namen des Pools angeben, nicht seine ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Leiten Sie den Datenverkehr an eine externe Ressource um.
Hier leiten wir den Datenverkehr auf die externe Website um, wenn alle Mitglieder des Hauptpools ausgefallen sind.
acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down
Noch mehr Beispiele .
Das ist für mich alles über den Balancer. Wenn Sie Fragen haben, stellen Sie sie, ich stehe Ihnen gerne zur Verfügung.
Source: habr.com