In a virtual desktop deployment, the connection broker is the component that brings users and back-end resources together. It is a part of VMware, Citrix and Microsoft virtual desktop infrastructure implementations. But what happens in organizations with really large numbers of virtual desktops available from one or more of these competitive vendors?
One answer is the Leostream Connection Broker, which has the ability to interoperate with all three major VDI vendors to provide a seamless connection interface to end users regardless of which platform is supplying the virtual desktop. Version 6.3 of Leostream's offering started shipping on Feb. 17 for $75 per seat. While I didn't test Connection Broker 6.3's capacity-the company says thousands of users can be supported with the product-I did look at the new access and management additions, including Web access to client virtual desktop systems.
The Leostream Connection Broker fits into the broader VDI implementation as a virtually transparent facilitator for end-user access. For desktop administrators, it is a powerful ally in melding policy, usage and authorized access in a single, easily managed tool. To bring all the pieces together, I used the Leostream Connection Broker, with a variety of thin clients, Windows fat clients and a VMware vSphere 4 infrastructure to host the virtual desktops. I used Microsoft Active Directory against which to authenticate my users. Overall, the Leostream Connection Broker worked well to put my users and virtual desktop resources together.
Besides the Connection Broker, which ran on a Linux-based virtual machine in my tests, Leostream can use an agent on the Microsoft Windows systems and Linux operating systems based on Red Hat. The agents aren't required for regular operation of the Connection Broker but do provide additional connection information that the Connection Broker can use to improve performance and, in some cases, provide additional functionality. For example, the Windows agent supports USB management, location-based printing and multimonitor support. These features are not currently available in the Linux-based agent.
I used an agent on several systems and found that I got some important, but not essential information on virtual desktop usage. I would be inclined to use the agent for high-value virtual desktop users and skip it for routine information workers. For example, the agent gave me greater detail on user log-in, disconnect and log-off, as well as running desktop processes. The agent also enables location (locations are created in the Connection Broker administrative interface) based printing. Leostream is aware of the stigma associated with widely deployed agents-they are generally a nuisance to maintain-and goes out of its way to say the agent is not required. But the documentation also recommends that the agent be deployed into every desktop managed by the Connection Broker. Since these desktops are centrally stored and managed in the data center, I think that agent usage is much more manageable. Further, it's a good example of one of the chief advantages of a VDI implementation: central IT control over what would otherwise be a highly distributed and difficult-to-manage compute resource.
Web access was added to the Leostream Connect application as a way for fat and thin clients to communicate with the Connection Broker. The Leostream Connect application got revved with fixes but not especially enhanced capability. The Web viewer is a neat addition to the product that made it possible for me to access virtual desktop systems without having to install the Connect software.
When using IE to get to my virtual desktops, the Web viewer worked just as well as the Leostream Connect software. While the Connect client is better suited for use in environments that need more secure access, for convenient access to workloads it was hard to beat the ease of use enabled by the Web client. Users log in by accessing the Leostream Connection Broker via a Web browser and then choosing to view the desktop.
As with any broker, there was a lot of setup to be done after the relatively simple Connection Broker appliance installation. I used the demo appliance that is available in an .OVF format. It literally took just moments to install the appliance in my VMware vSphere 4 environment. While there is a lot of policy that needs to be supplied to get the system up and running, for IT managers who are already familiar with the concepts and practices of using a broker, it shouldn't take that long to get up to speed on Leostream's Connection Broker. Those who have been using earlier versions of the product should have no trouble at all getting to work in the new version.
Without going into all the ins and outs, virtual desktop sources-in my case, those desktops and desktop template systems in my VMware vSphere environment-must be identified, users must be authenticated, and a variety of policies governing persistence and maintenance must be defined. While there are a lot of policies and procedural decisions that must be crafted in the Leostream Connection Broker, they are not extraordinarily more involved than what would be needed in a stand-alone implementation of VMware View 4 or a Citrix environment.
The amount of setup and policy development time has almost nothing to do with technology and everything to do with 1) the highly personalized nature of desktop systems and 2) the fact that life cycle issues-which are easy to ignore in server virtualization-are front and center for virtual desktop implementations. The Leostream Connection Broker makes it fairly easy to translate the intensely important questions of what happens to a virtual desktop when a user is finished with it for the day into actionable policy. I was able to easily assign persistent desktops to high-value users while pools of desktops used by routine knowledge workers were reverted to a pristine snapshot at the end of the day.
Editor's Note: This story has been updated. An earlier version indicated that Leostream Connect web access suppoted only Internet Explorer.