Another layer that will hit your end users is the connectivity from the client device to the EUC solution. No intermitted errors allowed in this communication. Users very rarely like connection server is not reachable pop ups. Getting your users securely and reliable connected to your organizations data, desktops and applications while guaranteeing connection quality and performance is key for any EUC solution. For a secure workspace protecting and reacting to threats as they happen even makes software defined networking more important for EUC. Dynamic software is required. And that all for any place, any device and any time solution. And if something breaks well….

Rest of the fire

One of the first things we talk about is the need for reliable load balance several components as they scale out. And for not getting in to all the networking bits in one blog post, I am sticking with load balancing for this part.

As Horizon does not have a one package deal with networking or load balancing, you have to look use an add on to the Horizon offering or outside the VMware Product suite. Options are:

  • interacting with physical components,
  • depending on other infrastructure components such as DNS RR (that is a poor mans load balancing) preferably with something extra like Infoblox DNS RR with service checks,
  • using virtual appliances like Kemp or NetScaler VPX. VPX Express is a great free load balancer and more.
  • Specific Software-Defined Networking for desktops, using NSX for Desktop as an add-on. Now instantly that question pops up why isn’t NSX included in for example Horizon Enterprise like vSAN? I have no idea but probably has something to do money (and cue Pink Floyd for the ear worm).

And some people will also hear about the option of doing nothing. Well nothing isn’t an option if you have two components. At a minimum you will have to do a manual or scripted way of redirecting your users to the second component when the first hits the load mark, needs maintenance or fails. I doubt that you or your environment will remain long loved when trying this in a manual way…..

The best fit all depends on what you are trying to achieve with the networking as a larger picture or for example load balancing specifically. Are you load balancing the user connections to two connection servers for availability, doing tunneled desktop sessions, or doing a cloud pod architecture over multiple sites and thus globally. That all has to be taken into account.

In this blog post I want to show you using NSX for load balancing connection server resources.

Horizon Architecture and load balancers

Where in the Horizon architecture do we need load balancers? Well the parts that connect to our user sessions and a scaled out for resources or availability. We need them in our local pods and global load balancers when we have several sites.

Externally:

  • Unified Access Gateway (formally known as Access point)
  • Security Server (if you happen to have that one lying around)

Internally:

  • Workspace ONE/vIDM.
  • Connection Servers within a Pod, with or without CPA. However with CPA we need some more than just local traffic.
  • AppVolumes Managers.

And maybe you have other components to load balance, such as multiple vROPS analytical nodes for user interface load not hitting one node. As long as the node the Horizon for adapter connects to or from is not load balanced.

Load Balancers

To improve the availability of all these kind of components, a load balancer is used to publish a single virtual service that internal or external clients connect to. For example for the connection server load balanced configuration, the load balancer serves as a central point for authentication traffic flow between clients and the Horizon infrastructure, sending clients to the best performing and most available connection server instance. I will keep the lab a bit simple by just load balancing two connection server resources.

Want to read up more about load balancing CPA? EUC Junkie Bearded VDI Junkie vHojan (https://twitter.com/vhojan) has an excellent blog post about CPA and impact of certain load balancing decisions. Read it here https://vhojan.nl/deploy-cpa-without-f5-gtm-nsx/.

For this one here, on to the Bat-Lab….

Bat-Labbing NSX Edge Load Balancing

Lets make the theory stick and get it up and running in a Horizon lab I have added to Ravello. Cloned from an application blueprint I use for almost all my Horizon labs and ready for adding a load balancing option NSX for Desktop. Scenario is load balancing the connection servers. In this particular example, we are going for one-armed. this means the load balancer node will live on the same network segment as the connection servers. Start your engines!

Deploying NSX Manager

Now how do your get NSX in Ravello? Well either deploy it on a nested ESXi or import method to deploy NSX directly on Ravello Cloud AWS or GC. I’m doing the last. As you did not set a password you can log in to the manager with user admin and password ‘default’.
That is the same password you can use to go to enable mode, type enable. And if you wish config t for configuration mode. Flashback to my Cisco days :))….In configuration mode you can set host names, IP and such via CLI.
But the easiest way is to type setup in basic/enable mode. Afterwards you should be able to login via the HTTPS interface. Use that default password and we are in.

NSX - vTestlab

Add a vCenter registration for allowing NSX components to be deployed. On to the vSphere Web Client. Add this point you must register a NSX license else you will fail to deploy the NSX Edge Security Gateway Appliance.

Next prepare the cluster for a network fabric to receive the Edges. Goto Installation and click the Host Preparation tab. Prepare hosts in your cluster you want to deploy to (and have licensed for VDI components or NSX for Desktop is no option). Click on actions – install when you are all set.

NSX - Prepare Host

For this Edge Load Balancer services deployment you don’t need a VXLAN or NSX Controller. So for this blog part I will skip this.

Next up deploying a NSX Edge. Go to NSX Edge and client on the green cross to add. Fill in the details, configure a minimum of one interface (depending on the deployment type) as I am using a one-arm – select the pools, networks and fill in the details. In a production you would also want some sort of cluster for your load balancers, but I have only deployed one for now. Link the network to logical switch, distributed vSwitch or standard vswitch. I have only one, so the same network standard vSwitch. Put in the IP addresses. Put in gateway and decide on your firewall settings. And let it deploy the OVA.

If you forgot to allow for nested in the /etc/vmware/config and get You are running VMware ESX through an incompatible hypervisor error. Add vmx.allowNested = “TRUE” to that file on the ESXi host nested on Ravello. Run /sbin/auto-backup.sh after that. If you retry the deployment this will normally work.

Load Balancing

We have two connection servers in vTestLab

Connection Servers

Go back to the vSphere web client and double-click the just created NSX edge. Go to Manage and tab Load Balancer. Enable the Load Balancer.

Horizon LB - Enable Global

Create an Application Profile. For this configuration I used a SSL pass through for HTTPS protocol with Session persistency.

NSX LB - Application Profile

For this setup you can leave the default HTTPS service monitor. Normally you would also want to have service checks on for example the Blast gateway (8443) or PCoIP (4172) if components use this.
Next setup your pool to include your virtual servers (the connection servers) and the service check, monitor port and connections to take in to account.

NSX Hor Pool Detail

Next up create the virtual server with the load balancing VIP and match that one to the just created pool.

Virtual Server

After this look at the status and select pool

NSX Pool Status.png

Both are up.
You can now test if a HTTPS to 10.0.0.12 will show you the connection server login page.

Connected.png

Connected. Using HTML Access will fail with an error connecting to the connection server (Horizon 7.1) as I did not change the origin checking. You can disable this protection by adding the following entry to the file locked.properties (C:\Program Files\VMware\VMware View\Server\sslgateway\conf) on each connection server:

checkOrigin=false
balancedHost=load-balancer-name

Restart the VMware Horizon View Connection Server service.
And of course you would add a DNS record to 10.0.0.12 to let your users use in the connection to the connection servers, like vdi.vtest.lab. And use a SSL certificate with that name.

Now a last check if the load balancing is working correctly. I kill of one of the connection server.

Man down

And let see what the URL is doing now:

Admin after man down

Perfect the load balancer connects to the remaining connection server. This time for the admin page.

This concludes this small demonstration of using NSX for Load Balancing Horizon components.

– Happy load balancing the EUC world!

Sources: vmware.com

Share this: