I just have had a chance for the first time to set up vCloud Director installation that was fronted by NSX-T based load balancer (version 2.4.1). In the past I have blogged how to load balance vCloud Director cells with NSX-V:
Load Balancing vCloud Director Cells with NSX Edge Gateway
vCloud OpenAPI – Large Payload Issue with Load Balancer
NSX-T differs quite a lot from NSX-V therefore the need for this article. The load balancer instance is deployed into the NSX-T Edge Cluster which is a set of virtual or physical NSX-T Edge Nodes. There are also strict sizing guidelines related to the size and number of LB and size of Edge Nodes – see the official docs.
Certificates
Import your VCD public cert in the NSX Manager UI: System > Certificates > Import Certificate. You will need to provide name, full certificate chain, private key and set is as Service Certificate. If it is signed by Enterprise CA you will also before that import the CA cert.
Monitor
Create new monitor in Networking > Load Balancing > Monitors > Add Active Monitor HTTPs
- protocol HTTPs
- monitoring port 443
- default timers
- HTTP Request Configuration: GET /cloud/server_status, HTTP Request Version: 1
- HTTP Response Configuration: HTTP response body: Service is up.
- SSL Configuration: Enabled, Client Certificate: None
Profiles
Application Profile
Networking > Load Balancing > Profiles > Select Profile Type: Application > Add Application Profile > HTTP
Here in the UI we can set only Request Header Size and Request Body Size. Set both to 65535. We will later use API to also configure Response Header Size.
Persistence and SSL Profiles
I will reuse existing default-source-ip-lb-persistence-profile and default-balanced-client-ssl-profile.
Server Pools
Networking > Load Balancing > Server Pools > Add Server Pool
- Algorithm: Least Connection
- Active Monitor: picked the one created before
- Select members: Enter individual members (do not enter port as we will reuse the pool for multiple ports)
![]()
![]()
Virtual Servers
We will add two virtual servers. One for UI/API and another for VM Remote Console connections. For both I have picked the same IP address from the cell logical segment. Ports will be different (443 vs 8443).
vCloud UI
- Add virtual server: L7 HTTP
- Ports: 443
- Ignore Load Balancer placement for now
- Server Pool: the one we created before
- Application Profile: the one we created before
- Persistence: default-source-ip-lb-persistence-profile
- SSL Configuration: Client SSL: Enabled, Default Certificate: the one we imported before, Client SSL Profile: default-balanced-client-ssl-profile
Server SSL: Enabled, Client Certificate: None, Server SSL Profile: default-balanced-client-ssl-profile
vCloud Console
- Add virtual server: L4 TCP
- Ports: 8443
- Ignore Load Balancer placement for now
- Server Pool: the one we created before
- Application Profile: default-tcp-lb-app-profile
- Persistence: disabled
Load Balancer
Now we can create load balancer instance and associate the virtual servers with it. Create the LB instance on the Tier 1 Gateway which routes to your VCD cell network. Make sure the Tier 1 Gateway runs on an Edge node with the proper size (see the doc link before).
Networking > Load Balancing > Load Balancers > Add Load Balancer
- Size: small
- Tier 1 Gateway
- Add Virtual Servers: add the 2 virtual servers created in the previous step
Now we have the load balancer up and running you should get all green in the status column. We are not done yet though.
Firstly we need to increase the response header size as vCloud Director Open API sends huge headers with links. Without this, you would get H5 UI errors (Nginx 502 Bad Gateway) and some API calls would fail. This can be currently done only with NSX Policy API. Fire up Postman or Curl and do GET and then PUT on the following URI:
NSX-manager/policy/api/v1/infra/lb-app-profiles/<profile-name>
in the payload change the response_header_size to at least 10240 50000 bytes.
And finally we will need to set up NAT so our load balanced virtual servers are available both from the outside world (on Tier-0 Gateway) as well from the internal networks. This is quite network topology specific, but do not forget the cells itself must properly connect to the public (load balanced) URL configured in vCloud Director public addresses.