Load Balancing vCloud Director with NSX-T

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.

Advertisement

19 thoughts on “Load Balancing vCloud Director with NSX-T

  1. 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

  2. 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

  3. 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

      1. Hello Tomas

        I had a typo in the Monitor HTTP Request Configuration…

        Thanks for your help, keep on posting great content please.

      1. 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…..

      2. 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 ~]#

      3. 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!

      4. 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)

      5. 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….

    1. 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.

  4. Hi Tomas. There is any link to the official documentation on how vCD should be balanced with NSX-T?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.