BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Load balancing in a VDI environment can help optimize resource usage and allow for failover.
The ability to scale with resource demands is an important component of virtual desktop infrastructure (VDI) design. Having overtaxed servers and/or overburdened storage can diminish the user experience severely; conversely, wasting expensive hardware resources that aren't being used is also not ideal. Load balancing the VDI workload can maximize your organization's investment and improve overall performance during peak usage times. Plus, spreading workloads across multiple servers increases the availability of those servers, should one fail.
So, what can you load balance in a VDI implementation? First, you should know that load balancing VDI can be lumped into two general categories:
- Server load balancing (the servers that host various VDI roles but not the VDI session itself)
- Session load balancing (the desktop VM or server-based VDI client sessions)
A basic Citrix XenDesktop server architecture consists of the following:
- Desktop Delivery Controller (DDC) -- the "brains" of XenDesktop. This server communicates with the hypervisor to direct the client to the appropriate desktop VM. It controls the state of the VM by starting and stopping it as needed.
- StoreFront -- a Web server that clients connect to the DDC through.
- Hypervisor -- the server that hosts the VDI user VMs.
Also note that XenDesktop allows for hosting desktops and applications on Windows Server OS, which could be on a physical server or a virtual machine.
A basic VMware Horizon View server architecture contains the following:
- Connection Server -- a component of View that acts as a broker for View clients to get directed to the desktop VM or Remote Desktop Session Host server.
- ESX hypervisor -- which hosts the client desktop VMs.
Server load balancing
You can load balance Citrix StoreFront, DDC and the VMware Connection Server like any Web server. Here are a few of the ways for this kind of workload:
DNS round robin. This is a simple method where the DNS server has multiple name or "A" records for the StoreFront or Connection servers. For example, the DNS list for a round robin might look like this: STOREFRONT 192.168.0.10, STOREFRONT 192.168.0.11, etc. The DNS server answers with the next IP address associated with each subsequent request for that name.
The advantage of this method is its utter simplicity, availability and cost (none). On the downside, it is not really load balancing; it just gives out the next server's IP address. This misses the key performance factors that more sophisticated load balancers (LBs) interrogate and use. A dedicated load-balancing server could balance load based on the target server's CPU, network use, disk I/O and service availability. It doesn't do much good to balance to a server where a critical service is offline or crashed.
Microsoft Network Load Balancing service (NLB). NLB is included with the Windows Server license. The Connection Server or StoreFront servers can run NLB locally and be added to a cluster, which has one logical name and IP address. NLB uses network traffic load levels to determine how busy a host is, which provides more meaningful balancing. It is also smart enough to know if a host is not actively part of the cluster and doesn't direct workload to it. This test doesn't include scenarios where the server is active on the cluster but StoreFront or Connection service is not functional.
Dedicated load balancers. Citrix NetScaler, F5's Big IP Local Traffic Manager, Kemp Technologies' LoadMaster and Radware's Alteon tools are all capable of providing dedicated load balancer capabilities for XenDesktop and Horizon View. These LBs can be physical hardware or virtual devices, and they have numerous advantages over the DNS round robin and NLB approaches.
A dedicated LB is much more aware of the many factors that are present in a VDI implementation. It continually assesses the health of the target server, including performance metrics like how much memory or CPU is being used. LBs can assess and routinely test that the server is actually working normally. If it fails a health check, it can automatically remove its availability to users, making downtime effectively transparent.
Load balancing is only one of the many features available on these products. The content caching, compression, prioritization and other optimization of network traffic offered by LB servers can improve performance by offloading work from the VDI servers themselves.
Session load balancing
Load balancing the desktop VMs or server-hosted sessions themselves is more complex than balancing the infrastructure servers because of the many possible configuration combinations.
A VDI session can be persistent or nonpersistent. Regardless of the persistence model, the session ideally should spin up on the least-loaded hypervisor server or server OS hosting the desktop. Load balancing VM sessions means controlling the hypervisor's ability to migrate VMs from server to server, so you need a mechanism that measures the level of resource use on multiple hypervisors.
For VMware-based VMs, the Distributed Resource Scheduler (DRS) feature allows you to build a cluster of ESX hosts and dynamically place the VDI VM on a host. Storage DRS creates clusters of storage pools, so the VM disks can also be dynamically moved based on definable thresholds. Just remember, migrating to or from hosts and/or storage pools can be very I/O intensive. Take care to keep the thresholds high enough to prevent migration from happening too often.
On Citrix XenServer-based hosts, the vendor's Workload Balancing provides some DRS-like functionality, but it was retired when the company released XenServer 6.2. Citrix recommends using third-party products to provide this function. For example, VMTurbo's Operations Manager works on XenServer, Hyper-V and vSphere platforms. This tool evaluates and automates the workload placement decisions about where a VM should be optimally running.
Also, with Citrix XenDesktop, server-OS based desktop and application sessions (formerly known as XenApp) can be balanced with native Citrix load-balancing policies. Citrix calculates a load factor from variables such as the maximum number of sessions, CPU usage and disk usage. This factor computes an integer value from 0 to 10,000 (full load), and sessions get balanced to the server with the lowest load value. Fully loaded servers do not accept new sessions.
Still, one limitation to server-OS based sessions is that they aren't dynamic. These session types can't be transitioned to a new server without going through a logoff and logon process.