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 maximum (65535 for header size and at least 52428800 for body size as ISO/OVA uploads use 50 MB chunks). 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.
Hi Tomas,
I have a problem regarding LoadBalancing to VCD 10 through NSX-T LoadBalancer.
I did the configuration as described in in this article.
Further I configured the public addresses inside VCD for Web, API and Consoleproxy.
As soon as I did the public addresses configuration, I was not longer able to access the /provider part of VCD through the NSX-T LoadBalancer.
I will get always HTTP Status Code “502 Bad Gateway”, as soon as the web browser try to access /cloudapi
I do not have this problem when connecting via a tenant URL.
If I set a static host entry to resolve one specific cell instead of walking though the NSX-T LoadBalancer, I am able to use /provider without any problems as well.
Do you have any idea what could be the problem?
Best Regards
Steven
Hi Tomas,
I found the reason for the problem written few minutes ago. As described in your article the response header size is important.
I changed the response header size and could fix the problem.
Really nice blog article.
Best Regards
Steven
Hi Tomas
I leveraged your great post to implement LB with NSX-T in front of 3 vCD 10 appliances. We’re running NSX-T 2.5.1 so I could set size values in NSX UI but I also checked with PostMan.
{
“x_forwarded_for”: “INSERT”,
“http_redirect_to_https”: false,
“ntlm”: false,
“idle_timeout”: 15,
“request_header_size”: 65535,
“request_body_size”: 52428800,
“response_timeout”: 60,
“response_header_size”: 50000,
“resource_type”: “LBHttpProfile”,
“id”: “vcloud-https”,
“display_name”: “vcloud-https”,
“path”: “/infra/lb-app-profiles/vcloud-https”,
“relative_path”: “vcloud-https”,
“parent_path”: “/infra/lb-app-profiles/vcloud-https”,
“marked_for_delete”: false,
“_create_user”: “admin”,
“_create_time”: 1583481137289,
“_last_modified_user”: “admin”,
“_last_modified_time”: 1583506743631,
“_system_owned”: false,
“_protection”: “NOT_PROTECTED”,
“_revision”: 5
}
Yet I face 502 Bad Gateway error. Did I miss something?
thanks
It looks good to me. Did you try GET and PUT back the same payload you got from the GET?
Thanks Tomas for the suggestion but that didn’t help.
Hello Tomas
I had a typo in the Monitor HTTP Request Configuration…
Thanks for your help, keep on posting great content please.
Hello Tomas, I wish to try this using NSX-V and your post: https://fojta.wordpress.com/2018/11/02/vcloud-openapi-large-payload-issue-with-load-balancer/ what you think about that ? In NSX-V theres these request header size or response header size options also ?
NSX-V LB works without those settings.
Yes I agree, it works, but not using SSL-Offload, and I need SSL-Offload to deliver some URL filters….when I activate SSL-Offload the connection fails with 500 Internal Error…..
The error using SSL Offload is 502 bad gateway and not 500….
Try this NSX-V API:
PUT /api/4.0/edges/EDGE-ID/systemcontrol/config
Content-Type: application/xml
<systemControl>
lb.global.tune.http.maxhdr=32767
lb.global.tune.bufsize=65536
</systemControl>
https://fojta.wordpress.com/2018/11/02/vcloud-openapi-large-payload-issue-with-load-balancer/
Instead of putting these configs the 502 Bad Gateway stills =(
And now I cannot edit the config anymore on Edge Gateway screen of NSX, I had to delete the configs….
* Connection #0 to host localhost left intact
lb.global.tune.http.maxhdr=32767lb.global.tune.bufsize=65536[root@d4-vca-nsxmgt-a1 ~]#
Sorry, not sure why it is not working for you. I run NSX-V LB with VCD in my lab with SSL offload without any issues.
and you use these two options to get it working ?
sorry for be persistent with this matter but if you can please create a post showing us the configurations you did using NSX-V + vCloud + SSL Offload, so I can compare with mine and see where I error!
VCD HTTPS application profile: HTTPS End-to-End, persistence Cookie, Cookie Name: vcd-fojta, Mode: Insert, Insert X-Forwarded-For HTTP header enable; Client SSL: Cipher default, Client Authentication: Ignore, Service Certificates: my VCD cert, Server SSL: nothing selected.
System Control config via API as above (lb.global.tune.http.maxhdr=32767, lb.global.tune.bufsize=65536)
ohhh this one works for me too, but I need to work with the option HTTPS Offloading because I need to use Application Rules to filters some tenant URLs, you could do a post about that, a lot of customers are complaining about their vCloud Director tenant URLs be exposed to Internet, I already contacted VMware Support without news….
HTTPS End-To-End will do SSL termnation, process any rules and establish another HTTPS session to the pool member.
HTTPs offloading works similarly but uses HTTP session to the pool member. That will not work with VCD.
Hi Tomas. There is any link to the official documentation on how vCD should be balanced with NSX-T?