You can configure an external load balancer to distribute traffic to the NSX Managers in a manager cluster.
- VIP does not perform load balancing across the NSX Managers.
- VIP requires all the NSX Managers to be in the same subnet.
- VIP recovery takes about 1 - 3 minutes in the event of a Manager node failure.
- Load balance across the NSX Managers.
- The NSX Managers can be in different subnets.
- Fast recovery time in the event of a Manager node failure.
An external load balancer will not work with the NSX Manager VIP. Do not configure an NSX Manager VIP if you use an external load balancer.
Authentication Methods When Accessing NSX Manager
- HTTP Basic Authentication
- Session-Based Authentication
- Authentication using an X.509 certificate and a Principal Identity
- Authentication in VMware Cloud on AWS (VMC)
The session-based authentication method (used when you access NSX Manager from a browser) requires source-IP persistence (all requests from the client must go to the same NSX Manager). The other methods do not require source-IP persistence (requests from the client can go to different NSX Managers).
Recommendations
- Create a single VIP on the load balancer with source-IP persistence configured to handle all the authentication methods.
- If you have applications or scripts that might generate a lot of requests to NSX Manager, create a second VIP without source-IP persistence for these applications or scripts. Use the first VIP for browser access to NSX Manager only.
- Type: Layer4-TCP
- Port: 443
- Pool: NSX Manager Pool
- Persistence: Source-IP persistence for the first VIP. None for the second VIP (if present).
Example of an external load balancer configuration:
NSX Manager's Certificate
The clients access NSX Manager using a FQDN name (for example, nsx.mycompany.com). This FQDN is resolved to the load balancer's VIP. To avoid any certificate mismatch, each NSX Manager must have a certificate that is valid for the VIP's FQDN name. Therefore, you must configure each NSX Manager with a SAN certificate that is valid for its own name (for example, nsxmgr1.mycompany.com) and the VIP's FQDN.
Monitoring the Health of NSX Managers
GET /api/v1/reverse-proxy/node/health
- Header1
- Name: Authorization
- Value: Basic <Base64 Value>
Note: <Base64 Value> is Username:Password encoded in Base64. You can use https://www.base64encode.net to do the encoding. For example, Header1 might be
Authorization: Basic YWRtaW46Vk13YXJlMSFWTXdhcmUxIQ==
for admin:VMware1!VMware1!. - Header2
- Name: Content-Type
- Value: application/json
- Header3
- Name: Accept
- Value: application/json
"healthy" : true
Note that the format of the response is “healthy”<space>:<space>true
.
If you change the password of the user that you specify in Header1, you must update Header1 accordingly.