Sie können einen externen Load Balancer konfigurieren, um den Datenverkehr an die NSX Manager in einem Manager-Cluster zu verteilen.

Ein NSX Manager-Cluster erfordert keinen externen Load Balancer. Die virtuelle NSX Manager-IP (VIP) sorgt beim Ausfall eines Manager-Knotens für Stabilität, hat aber die folgenden Einschränkungen:
  • VIP führt keinen Load Balancing für die NSX Manager durch.
  • VIP erfordert, dass sich alle NSX Manager im selben Subnetz befinden.
  • Die Wiederherstellung der VIP dauert etwa 1–3 Minuten, falls ein Manager-Knoten ausfällt.
Ein externer Load Balancer kann die folgenden Vorteile bieten:
  • Lastenausgleich zwischen den NSX Managern.
  • Die NSX Manager können sich in unterschiedlichen Subnetzen befinden.
  • Schnelle Wiederherstellungszeit beim Ausfall eines Manager-Knotens.

Die NSX Manager-VIP kann nicht für einen externen Load Balancer verwendet werden. Konfigurieren Sie keine NSX Manager-VIP, wenn Sie einen externen Load Balancer verwenden.

Authentifizierungsmethoden beim Zugriff auf NSX Manager

Die folgenden Authentifizierungsmethoden werden von NSX Manager unterstützt. Informationen zu Authentifizierungsmethoden finden Sie im Handbuch zu NSX-API.
  • HTTP-Standardauthentifizierung
  • Sitzungsbasierte Authentifizierung
  • Authentifizierung mit einem X.509-Zertifikat und einer Prinzipalidentität
  • Authentifizierung in VMware Cloud on AWS

Die sitzungsbasierte Authentifizierungsmethode (die beim Zugriff auf NSX Manager über einen Browser verwendet wird) erfordert Persistenz der Quell-IP (alle Anforderungen vom Client müssen an denselben NSX Manager gesendet werden). Die anderen Methoden erfordern keine Persistenz der Quell-IP (Anforderungen vom Client können an verschiedene NSX Manager gesendet werden).

Empfehlungen

  • Erstellen Sie eine einzelne VIP auf dem Load Balancer mit Persistenz der Quell-IP, die für die Verarbeitung aller Authentifizierungsmethoden konfiguriert ist.
  • Wenn Sie über Anwendungen oder Skripts verfügen, die möglicherweise viele Anforderungen an NSX Manager generieren, erstellen Sie eine zweite VIP ohne Persistenz der Quell-IP für diese Anwendungen oder Skripte. Verwenden Sie die erste VIP nur für den Browserzugriff auf NSX Manager.
Die VIP muss die folgenden Konfigurationen aufweisen:
  • Typ: Layer4-TCP
  • Port: 443
  • Pool: NSX Manager-Pool
  • Persistenz: Persistenz der Quell-IP für die erste VIP. Keine für die zweite VIP (falls vorhanden).

Beispiel für eine externe Load Balancer-Konfiguration:

Ein Beispiel für eine externe Load Balancer-Konfiguration

NSX Manager-Zertifikat

Die Clients greifen über den FQDN-Namen (z. B. nsx.mycompany.com) auf NSX Manager zu. Dieser FQDN wird in die VIP des Load Balancers aufgelöst. Um Zertifikatskonflikte zu vermeiden, muss jeder NSX Manager über ein Zertifikat verfügen, das für den FQDN-Namen der VIP gültig ist. Aus diesem Grund müssen Sie jeden NSX Manager mit einem SAN-Zertifikat konfigurieren, das für seinen eigenen Namen (z. B. nsxmgr1.mycompany.com) und den FQDN der VIP gültig ist.

Überwachen der Integrität von NSX Managern

Der Load Balancer kann überprüfen, ob jeder NSX Manager smit der folgenden API ausgeführt wird: 
GET /api/v1/reverse-proxy/node/health
Die Anforderungsheader sind:
  • Header1
    • Name: Authorization
    • Wert: Basic <Base64 Value>

    Hinweis: <Base64 Value> ist „Benutzername:Kennwort“ in Base64 codiert. Sie können https://www.base64encode.net für die Kodierung verwenden. Header1 könnte beispielsweise Authorization: Basic YWRtaW46Vk13YXJlMSFWTXdhcmUxIQ== für admin:VMware1!VMware1! sein.

  • Header2
    • Name: Content-Type
    • Wert: application/json
  • Header3
    • Name: Accept
    • Wert: application/json
Eine Antwort, die angibt, dass NSX Manager ausgeführt wird, lautet: 
"healthy" : true

Beachten Sie, dass das Format der Antwort “healthy”<space>:<space>true ist.

Wenn Sie das Kennwort des Benutzers ändern, den Sie in Header1 angeben, müssen Sie Header1 entsprechend aktualisieren.