In the following article I am going to tell you how easy it is to set up a load balanced Horizon View environment. But remember: Just because something is easy to install it is not necessarily easy to design. There are multiple design affecting factors I am going to discuss in my #design guide. There are many Installation Guidelines out there, so I will keep it quick and simple and try to give you some hints what to do or not to do.
What do I want to achieve or show to you in this blog post?
- Creation Redundant Connection Server to access virtual Desktops
- A redundant Load Balancer in front of it (#NSX ftw)
- Internal Access only – I spent a lot of time with the Unified Access Gateway and show you in the second blog post about how to enable access over the Internet into your Horizon Homelab
Connection Server
The Connection Server is a core component within our Horizon View environment. It gives us the opportunity to create Desktop Pools out of Windows / Linux machines or Application Pools (based on Microsoft RDSH-Hosts) and entitle them to any Active Directory User in our environment. It offers us the following key functionality
- Brokering between Endpoints (that have the Horizon Client installed) and a virtual Desktop / Remote Desktop Session Host (Application)
- Authentication Handler (AD only or 2nd factor)
- View Administration via web-based (Flash :-/ ) user interface
- HTML5-Client to access the Desktops/Applications without the need of a client
- Connection to the vCenter Server to create new VMs / Desktops
*taken from the Horizon Reference Architecture
You are going to install the Connection Server on two Windows machines. The first one will be a Standard Server. All other Connection Server will act as a replica. Remember: The Connection Server DOES NOT need a dedicated external database. All relevant data is stored within a Microsoft Active Directory Lightweight Data Services (AD-LDS) database. The advantage here is that we have a level simplicity since we (and the VMware’s developer) don’t need to care about replication of data. The problem with AD-LDS is that we might end up in a bad situation when Connection Server member get out-of sync or if you are going to recover them from a backup.
Two type of data exchange are occurring within our max. 7 Connection Server.
- Slow data exchange via AD-LDS replication (All settings within the Horizon View Admin interface)
- Ultra fast data exchange via Java Messaging Service (JMS) (Brokering and availability information of the desktop state and assignments). This protocol is f*****g latency sensitive
### Lab-Design Decision. For production use discuss implications of every Parameter
- Virtual Hardware: 2 vCPU, 3GB Memory, 40GB Disk (In Production I made good experience with 4vCPU, 12GB Memory, 100GB Disk)
- Version: 7.2
- Connection to Desktop: Direct (I just prefer the direct approach ;)
Input required for installation / configuration:
- Horizon View Data Recovery Password
- Connection Server IP/DNS for Replica installations
- A vCenter service user and dedicated vCenter role (with minimal privileges)
Dependencies for Installation:
- Windows Server OS (Windows 2012 R2 or 2016 recommended)
- Adobe Flash for the View Admin Interface
- Network Management Connectivity
- IP-Address, DNS-Server, Gateway
- Computer Joined to an Active Directory Domain
- Hostname & DNS-Entry (Forward and Reverse Lookup)
- Active Directory User that can install the Connection Server
- Horizon 7 Binaries (Horizon 7.2.0 View Connection Server (64-bit)) downloaded from here
- All Connection Server must reside in the same datacenter due to a lowest latency requirements of JMS. Connection Sever on a stretched vSphere Cluster is NOT supported
Recommendation:
- Maximum of 7 Connection Server in a production environment.
- You can change the connection settings on every Connection Server (tunneled or direct connect). Make sure to have a consistent setup – see the load balancer section.
- Create an Active Directory Group which Users will be entitled as Horizon View Administrator.
- Use an Operating System configured with English language.
- The Connection Server must not have more than 1 Network Adapter.
- Create anti-affinity rules for the connection server and place them on different datastores (in best case physically separated).
- If you have multiple vSphere Clusters – Go with the Cloud Pod Architecture right from the beginning.
- If you require the Cloud Pod architecture the Windows machine name MUST match the DNS entry. Otherwise create hosts.conf entries.
- A single Connection Server can handle up to 4000 Sessions (Horizon 7.2++).
- Increase the View Administrator session timeout to 600 minutes.
- Use a dedicated Service account to interact with the vCenter. That makes troubleshooting sooo much easier.
- Always imagine that the integration between View and the vCenter seems to be slow and unidirectional ;-). This is for sure not true, but that sentence helps you to understand that sometimes changes in the Horizon world take sometime until they get applied in the vSphere world.
The following video shows you how I have installed and configured Horizon View within my homelab environment. Feel free to ask if you have further questions.
NSX Load Balancer
NSX is quite a cool technology. With NSX you are able to create software-defined networks based on VXLAN, Integrate Security solutions and create Micro-segmentation (pretty powerful within VDI) and for sure it is offering Edge Services like a load-balancer that we need within the Horizon world all of the Time.
Within the access layer we put a Load-Balancer in front of our multiple connection server. We create a monitoring to listen if a Connection Server is available and balance the load across multiple Connection Server nodes.
Within an internal network (we are connecting to the Desktop over a secure LAN connection) the NSX Load Balancer can be configured quite simple (as you will see in the Vide0). The big question is if the Connection Server is just initially brokering between the Endpoint (where die Horizon client is installed) and the virtual Desktop or if the Connection should be tunneled. In the tunneling case we would rely on the availability of the Connection Server. If we have tunneled connections and you reboot/update the connection server the Desktop access will drop.
If the checkboxes are deselected a direct connection between Endpoint (with Horizon Client) and the virtual Desktop is created. In this case the network must be able to establish a connection between the Endpoint and virtual desktop in the relevant ports.
If the checkboxes are selected a tunneled connection between Endpoint (with Horizon Client) and the virtual Desktop is created. The tunneled is created against the
FYI:
You can have different direct/tunneling options depending on the protocol that you want to use to access your desktop. HTTP(S) Secure Tunnel is defining a RDP connection, PCoIP Secure Gateway for PCoIP connections and Blast Secure Gateway for the HTML5 blast or Horizon Client Blast Extreme connection.
### Lab-Design Decision. For production use discuss implications of every Parameter
- One-Arm vs In-Line LoadBalancer: For simplicity reasons I have used a one-arm load balancer
- SSH: enabled
- Edge Services Gateway Size: Compact
- HA-Mode: Enabled (Always enabled HA for your load-balancer ;-)
- SSL-Passthrough vs SSL-Terminated: Go with Passthrough ;-)
- Session-Persistence: SSL Session ID to make sure your session remain at the correct Connection-Server
- Service-Monitor: Interval 10, Time-Out: 5 seconds, Max-Retries: 3, Type: HTTPS, Method: Get, URL: favicon.ico
- Pool: Algorithm: IP-Hash, Monitors (above defined), member: All Connection Server
Input required for installation / configuration:
- NSX Manager CLI Password
- A vCenter user with NSX permissions
Dependencies for Installation:
- Connection Server IP-Address
- A vSphere Cluster for the load balancer aka NSX Edge Services Gateway
- Load Balancer IP aka VIP
- Load Balancer IP aka VIP DNS entry (forward and reverse)
Recommendation:
- Use High-Availability whenever possible. Anti-Affinity rules are created automatically. If possible place the load balancer instances on different storage devices to make sure a storage failure won’t affect the connectivity. You can easily upgrade your Load Balancer into an HA-mode afterwards.
- In Production use Quad-Large size for the NSX Edge.
- Do failover tests before going to production. Shutdown load-balancer instances, connection server and ESXi hosts to make sure the Access-Level has a maximum availability.
- Before updating the Connection Server OS / Horizon View version make sure to edit the pool member to drain. In this case no new sessions will balanced to the defined connection server and you can easily shutdown your connection server.
- Disabling the Connection-Server within the Horizon View interface has no impact on the health-state the load-balancer is seeing.
- If you want to easily sniff-network traffic and verify connections/tunnel settings you can use Flow Monitoring -> Live flow feature from within the NSX manager (Make sure your ESXi hosts have been prepared for NSX).
- You can figure out to which Connection Server you have been balanced by navigating to the load-balancer VIP / Hostname and check the certificate.
- Make sure to include the Load balancer hostname / DNS entry into a signed certificate that is getting installed on the Connection Server. I will have a dedicated blog post on the SSL topic.
- If Horizon HTML5 access won’t work make sure to follow the steps in the following KB.
- Check this brilliant network port diagram to have an overview of all protocols and components used within an Horizon environment. If you meet up with the network/firewall guys? Bring this poster with you.
The following video shows you how I have installed and configured the internal load balancer for Horizon View within my homelab environment. Feel free to ask if you have further questions.