In my last article on virtual desktop infrastructure (VDI), I discussed the three main components of a VDI solution:...
the virtualization servers and supporting infrastructure, the hosted operating system (OS) instances, and the connection broker. In this article, I'd like to take a more detailed look at the connection broker and some of the functionality that brokers provide in a VDI deployment.
Note that this article is intended as a broad overview of connection brokers and connection broker functionality, and is not intended to be a feature comparison of actual shipping products. For a feature comparison of shipping products, I encourage organizations to work with the vendors or a value-added reseller (VAR) to test them in a proof-of-concept implementation.
The functionality that connection brokers provide falls into a few major categories:
- Virtual machine (VM) management
- Pool creation and management
- Network connectivity
- Policy assignment and enforcement
Virtual machine management
Most connection brokers offer ties directly into VirtualCenter -- or ESX Server, in smaller implementations -- to provide VM (virtual machine) management functions. This would include the ability to power on VMs, power off VMs, suspend VMs, or resume suspended VMs. Some brokers also have the ability to provision new VMs from a template, so that new VMs can be created automatically by the broker when needed or requested.
Pool creation and management
The idea of a "pool" of VMs is a concept that many connection brokers leverage. A pool is a group of VMs, possessing similar characteristics or functionality, to which users are assigned by the broker according to predefined policies. In some implementations, VMs can be members of multiple pools; pools can be static in size or can grow and shrink dynamically. Some brokers tie together VM management and pool management functionality, so that as a pool approaches a certain level of utilization new VMs are provisioned and added to the pool. Likewise, as demand falls, the pool will shrink and VMs can be destroyed to return reosurces to the virtualization layer.
From a network connectivity perspective, brokers fall into two families: in-line and out-of-band.
In-line brokers are just that; all connection traffic flows through the broker in order to reach the hosted OS instances. This allows in-line brokers to supply SSL VPN or traffic shaping/Quality of Service (QoS) functionality. Organizations that do not already have remote user VPN capabilities, or who do not want to use existing remote user VPN capabilities for their VDI deployment, should look at in-line brokers to supply that ability.
Out-of-band brokers don't handle the connection traffic itself; they simply redirect the client device to the appropriate hosted OS instance and then hand off the connection. The client device and the hosted OS instance communicate with each other directly. This type of broker assumes the organization already has remote access VPN capacity that can be leveraged, or that all VDI users are within the network perimeter and remote user VPN is not necessary.
Policy assignment and enforcement
Brokers use policies to control the assignment of users to hosted OS instances--or to a pool of hosted OS instances. The policy may create a one-to-one assignment, so that each and every user is represented by a hosted OS instance, and that hosted OS instance is essentially permanently assigned to that user. This can be useful in some instances, depending upon the organization and the business needs. More commonly, the policy assigns a hosted OS instance to a user only for the duration of the connection, returning the instance back to the list of available instances when the user signs out. Of course, there is a multitude of variations between these two endpoints, and it is the role of the connection broker to manage the policy and enforce it. For example, the policy may specify that "rogue users," users not assigned by the broker, will be logged out when the broker needs to assign a hosted OS instance to a valid connection. Or the broker's policy may specify that a hosted OS instance should be suspended when a user logs out, then resumed when it is re-assigned to another user. All of these policy decisions are handled by the connection broker, in close cooperation with VirtualCenter or ESX Server, back-end directory services like Active Directory, and the hosted OS instances themselves.
Now that I've discussed the role of the connection broker in a bit more detail, in the next few articles I'll delve into some of the details of how the connection broker integrates into some of the VDI components and how those details affect a VDI implementation.
About the author: Scott Lowe has had a lifelong love of computers, dating all the way back to his first computer, a Tandy TRS-80 Color Computer. He began working professionally in the technology field in 1994, and has since held the roles of an instructor, technical trainer, server/network administrator, systems engineer, IT manager, and CTO. For the last few years, Scott has worked as a senior systems engineer with a reseller, providing technology solutions to enterprise customers. Scott also runs a virtualization-centric weblog at http:// blog.scottlowe.org.