Teil Eins EinführungTeil Zwei Konfigurieren Sie Firewall- und NAT-RegelnTeil drei. DHCP-SetupTeil vier Routing-SetupDas letzte Mal haben wir über die Funktionen von NSX Edge in Bezug auf statisches und dynamisches Routing gesprochen, und heute werden wir uns mit dem Balancer befassen.
Bevor ich mit dem Setup fortfahre, möchte ich kurz auf die wichtigsten Arten des Auswuchtens eingehen.
Theorie
Alle heutigen Lösungen für den Nutzlastausgleich werden meist in zwei Kategorien unterteilt: Ausgleich auf der vierten (Transport) und der siebten (angewandten) Ebene des
OSI-Modells . Das OSI-Modell ist nicht der beste Bezugspunkt für die Beschreibung von Ausgleichsmethoden. Wenn der L4-Balancer beispielsweise auch die TLS-Terminierung unterstützt, wird er dann zu einem L7-Balancer? Aber das heißt, das ist.
- Der L4-Balancer ist meistens derjenige, der zwischen dem Client und dem Satz verfügbarer mittlerer Proxy-Backends steht, der TCP-Verbindungen beendet (dh unabhängig auf SYN reagiert), ein Backend auswählt und eine neue TCP-Sitzung in seine Richtung initiiert und SYN selbst sendet. Dieser Typ ist eine der grundlegenden, andere Optionen sind möglich.
- Der L7-Balancer verteilt den Datenverkehr an die verfügbaren Backends „ausgefeilter“ als der L4-Balancer. Er kann sich für ein Backend entscheiden, das beispielsweise auf dem Inhalt einer HTTP-Nachricht (URL, Cookie usw.) basiert.
Unabhängig vom Typ kann der Balancer die folgenden Funktionen unterstützen:
- Bei der Serviceerkennung werden die verfügbaren Backends (statisch, DNS, Consul, usw.) ermittelt.
- Überprüfen des Zustands erkannter Backends (aktives "Ping" des Backends mithilfe einer HTTP-Anforderung, passive Erkennung von Problemen in TCP-Verbindungen, Vorhandensein mehrerer 503 HTTP-Codes in den Antworten in einer Reihe usw.).
- Balancing selbst (Round Robin, zufällige Auswahl, Quell-IP-Hash, URI).
- TLS-Beendigung und Zertifikatsüberprüfung.
- Sicherheitsbezogene Optionen (Authentifizierung, Verhinderung von DoS-Angriffen, Geschwindigkeitsbegrenzung) und vieles mehr.
NSX Edge bietet Unterstützung für zwei Balancer-Bereitstellungsmodi:
Proxy-Modus oder einarmig . In diesem Modus verwendet NSX Edge beim Senden einer Anforderung an eines der Backends seine IP-Adresse als Quelladresse. Somit führt der Balancer sowohl die Quell- als auch die Ziel-NAT-Funktionen aus. Das Backend sieht den gesamten vom Balancer gesendeten Datenverkehr und antwortet direkt darauf. In diesem Schema muss sich der Balancer im selben Netzwerksegment wie die internen Server befinden.
So geht's:
- Der Benutzer sendet eine Anfrage an die VIP-Adresse (Balancer-Adresse), die auf Edge konfiguriert ist.
- Edge wählt eines der Backends aus und führt das Ziel-NAT durch, wobei die VIP-Adresse durch die Adresse des ausgewählten Backends ersetzt wird.
- Edge führt Quell-NAT aus und ersetzt die Adresse des Benutzers, der die Anforderung gesendet hat, durch eine eigene.
- Das Paket wird an das ausgewählte Backend gesendet.
- Das Backend reagiert nicht direkt auf den Benutzer, sondern auf Edge, da die ursprüngliche Adresse des Benutzers in die Adresse des Balancers geändert wurde.
- Edge sendet die Serverantwort an den Benutzer.
Schema unten.
Transparenter oder Inline-Modus. In diesem Szenario verfügt der Balancer über Schnittstellen im internen und externen Netzwerk. Es gibt jedoch keinen direkten Zugriff von außen auf das interne Netzwerk. Der integrierte Load Balancer fungiert als NAT-Gateway für virtuelle Maschinen im internen Netzwerk.
Der Mechanismus ist wie folgt:
- Der Benutzer sendet eine Anfrage an die VIP-Adresse (Balancer-Adresse), die auf Edge konfiguriert ist.
- Edge wählt eines der Backends aus und führt das Ziel-NAT durch, wobei die VIP-Adresse durch die Adresse des ausgewählten Backends ersetzt wird.
- Das Paket wird an das ausgewählte Backend gesendet.
- Das Backend empfängt eine Anfrage mit der ursprünglichen Adresse des Benutzers (Quell-NAT wurde nicht ausgeführt) und antwortet direkt darauf.
- Der Datenverkehr wird vom Load Balancer erneut akzeptiert, da er im Inline-Schema normalerweise als Standard-Gateway für die Serverfarm fungiert.
- Edge führt Quell-NAT aus, um Datenverkehr an den Benutzer zu senden, wobei dessen VIP als Quell-IP-Adresse verwendet wird.
Schema unten.

Übe
Auf meinem Testbed sind 3 Server mit Apache konfiguriert, die für die Arbeit mit HTTPS konfiguriert sind. Edge gleicht HTTPS-Anforderungen mithilfe der Round-Robin-Methode aus und überträgt jede neue Anforderung an einen neuen Server.
Fangen wir an.
Generieren eines SSL-Zertifikats, das NSX Edge verwendet
Sie können ein gültiges CA-Zertifikat importieren oder ein selbstsigniertes Zertifikat verwenden. In diesem Test werde ich selbstsigniert verwenden.
- Wechseln Sie in der vCloud Director-Benutzeroberfläche zu den Einstellungen für die Edge-Dienste.

- Wechseln 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 zur Selbstsignierung aus.

- Wählen Sie die Gültigkeitsdauer des Zertifikats aus und klicken Sie auf Behalten

- Ein selbstsigniertes Zertifikat wurde in der Liste der verfügbaren Zertifikate angezeigt.

Anwendungsprofil konfigurieren
Anwendungsprofile geben Ihnen mehr Kontrolle über den Netzwerkverkehr und machen die Verwaltung einfach und effizient. Mit ihrer Hilfe können Sie das Verhalten für bestimmte Arten von Verkehr bestimmen.
- Gehen Sie zur Registerkarte Load Balancer und aktivieren Sie den Balancer. Mit der Option Beschleunigung aktiviert kann der Balancer einen schnelleren L4-Ausgleich anstelle von L7 verwenden.

- Wechseln Sie zur Registerkarte Anwendungsprofil, um das Anwendungsprofil festzulegen. Klicken Sie auf +.

- Legen Sie den Profilnamen fest 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 bestimmte Server aus dem Pool bedient eine Benutzeranforderung. Dadurch wird sichergestellt, dass Benutzeranforderungen während der gesamten Dauer der Sitzung oder nachfolgender Sitzungen an dasselbe Poolmitglied gesendet werden.
SSL-Passthrough aktivieren - Wenn diese Option ausgewählt ist, beendet NSX Edge das Beenden von SSL. Stattdessen erfolgt die Beendigung direkt auf den Servern, für die der Ausgleich durchgeführt wird.
X-Forwarded-For-HTTP-Header einfügen - Ermöglicht die Ermittlung der Quell-IP-Adresse des Clients, der über den Balancer eine Verbindung zum Webserver herstellt.
Pool Side SSL aktivieren - Mit dieser Option können Sie festlegen, 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 Virtual Server Certificates -> Service Certificate auswählen.

- Ähnliches gilt für Pool-Zertifikate -> Service-Zertifikat.

Wir erstellen einen Pool von Servern, deren Datenverkehr ausgeglichen wird
- Gehen Sie zur Registerkarte Pools. Klicken Sie auf +.

- Legen Sie den Poolnamen fest, wählen Sie den Algorithmus (ich verwende Round Robin) und den Überwachungstyp für die Integritätsprüfung des Backends aus. Die Option Transparent gibt an, ob die anfänglichen Quell-IP-Clients für die internen Server sichtbar sind.
- Wenn diese Option deaktiviert ist, stammt der Datenverkehr für interne Server von der Quell-IP des Balancers.
- Wenn diese Option aktiviert ist, sehen interne Server die Quell-IP-Clients. In dieser Konfiguration muss der NSX Edge als Standardgateway fungieren, um sicherzustellen, dass die zurückgegebenen Pakete den NSX Edge passieren.
NSX unterstützt die folgenden Ausgleichsalgorithmen:
- IP_HASH - Serverauswahl basierend auf den Ergebnissen der Hash-Funktion für die Quell- und Ziel-IP jedes Pakets.
- LEASTCONN - Ausgleich eingehender Verbindungen, abhängig von der Anzahl der bereits auf einem bestimmten Server verfügbaren Verbindungen. Neue Verbindungen werden an den Server mit der geringsten Anzahl von Verbindungen weitergeleitet.
- ROUND_ROBIN - Neue Verbindungen werden nacheinander entsprechend dem angegebenen Gewicht an jeden Server gesendet.
- URI - Der linke Teil der URI (vor dem Fragezeichen) wird gehasht und durch das Gesamtgewicht der Server im Pool geteilt. Das Ergebnis gibt an, welcher Server die Anforderung empfängt, und stellt sicher, dass die Anforderung 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 keine Bedeutung hat, wird der ROUND_ROBIN-Algorithmus verwendet.
- URL - Jede HTTP-GET-Anforderung sucht nach dem als Argument angegebenen URL-Parameter. Wenn auf den Parameter ein Gleichheitszeichen und ein Wert folgen, wird der Wert gehasht und durch das Gesamtgewicht der laufenden Server geteilt. Das Ergebnis gibt an, welcher Server die Anforderung empfängt. Dieser Prozess wird verwendet, um Benutzerkennungen in Anforderungen zu verfolgen und sicherzustellen, dass immer dieselbe Benutzer-ID an denselben Server gesendet wird, solange alle Server verfügbar bleiben.

- Klicken Sie im Block Mitglieder auf +, um dem Pool Server hinzuzufügen.

Hier müssen Sie angeben:
- Servername
- Server IP Adresse;
- der Port, an 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 Mitglied des Pools anpassen.
- Max. Verbindungen - Die maximale Anzahl von Verbindungen zum Server.
- Min. Verbindungen - Die Mindestanzahl von Verbindungen, die der Server verarbeiten muss, bevor der Datenverkehr zum nächsten Poolmitglied umgeleitet wird.

So sieht der endgültige Pool von drei Servern aus.

Virtuellen Server hinzufügen
- Wechseln 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 und den Pool aus und geben die IP-Adresse an, an die Virtual Server Anforderungen von außerhalb akzeptiert. Geben Sie das HTTPS-Protokoll und den Port 443 an.
Optionale Parameter hier:
Verbindungslimit - Die maximale Anzahl gleichzeitiger Verbindungen, die ein virtueller Server verarbeiten kann.
Verbindungsratenlimit (CPS) - Die maximale Anzahl neuer eingehender Anforderungen pro Sekunde.

Damit ist die Balancer-Konfiguration abgeschlossen. Sie können die Leistung überprüfen. Server haben die einfachste Konfiguration, mit der Sie nachvollziehen können, welcher Server aus dem Pool die Anforderung verarbeitet hat. Während des Setups haben wir den Round Robin-Ausgleichsalgorithmus ausgewählt, und der Weight-Parameter für jeden Server ist gleich eins, sodass jede nächste Anforderung vom nächsten Server aus dem Pool verarbeitet wird.
Geben Sie die externe Adresse des Balancers in den Browser ein und sehen Sie:

Nach dem Aktualisieren der Seite wird die Anforderung vom folgenden Server verarbeitet:

Und noch einmal - um den dritten Server aus dem Pool zu überprüfen:

Bei der Überprüfung können Sie feststellen, dass das Zertifikat, das Edge uns sendet, das gleiche ist, das wir zu Beginn generiert haben.
Überprüfen Sie den Status des Balancers über die Edge-Gateway-Konsole.
Geben Sie dazu den
Show Service Loadbalancer Pool ein .

Konfigurieren Sie Service Monitor, um den Status der Server im Pool zu überprüfen
Mit Service Monitor können wir den Status von Servern im Backend-Pool überwachen. Wenn die Antwort auf die Anforderung nicht den Erwartungen entspricht, kann der Server aus dem Pool entfernt werden, sodass keine neuen Anforderungen empfangen werden.
Standardmäßig sind drei Überprüfungsmethoden konfiguriert:
- TCP-Monitor
- HTTP-Monitor
- HTTPS-Monitor.
Erstellen Sie eine neue.
- Gehen Sie zur Registerkarte Service Monitoring und klicken Sie auf +.

- Wählen Sie:
- Name für die neue Methode;
- Intervall, in dem Anfragen gesendet werden,
- Antwortzeitlimit
- Der Überwachungstyp ist eine HTTPS-Anforderung mit der GET-Methode, der erwartete Statuscode ist 200 (OK) und die Anforderungs-URL.
- Damit ist die Konfiguration des neuen Service Monitors abgeschlossen. Jetzt können wir ihn beim Erstellen eines Pools verwenden.

Anwendungsregeln konfigurieren
Anwendungsregeln sind eine Möglichkeit, den Datenverkehr basierend auf bestimmten Triggern zu manipulieren. Mit diesem Tool können wir erweiterte Lastausgleichsregeln erstellen, die möglicherweise nicht über Anwendungsprofile oder andere auf Edge Gateway verfügbare Dienste konfiguriert werden können.
- Um eine Regel zu erstellen, wechseln Sie zur Registerkarte Anwendungsregeln des Balancers.

- Wählen Sie einen Namen, ein Skript, das die Regel verwendet, 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 Unterstützung von tlsv1 aufgenommen.
Noch ein paar Beispiele:
Leiten Sie den Datenverkehr in einen anderen Pool um.
Mit diesem Skript können wir den Datenverkehr in einen anderen Ausgleichspool umleiten, wenn der Hauptpool nicht funktioniert. Damit die Regel funktioniert, müssen auf dem Balancer mehrere Pools konfiguriert sein und alle Mitglieder des Hauptpools müssen sich im Status "Down" befinden. Geben Sie den Namen des Pools an, nicht dessen ID.
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0 use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME
Leiten Sie den Datenverkehr zu einer externen Ressource um.
Hier leiten wir den Datenverkehr auf eine externe Website um, wenn sich alle Mitglieder des Hauptpools im Status "Down" befinden.
acl pool_down nbsrv(NAME_OF_POOL) eq 0 redirect location http://www.example.com if pool_down
Weitere Beispiele
hier .
Das ist alles über den Balancer. Wenn Sie Fragen haben, fragen Sie, ich bin bereit zu beantworten.