Back to it20.info

WARNING: this page is deprecated and doesn't get updated any more. I have consolidated all these information (updated) into a single "Virtualization Comparison page that you can find here in the Desktop Virtualization section (10th June - 2009)

Brokering technologies for Clients Consolidation  LAST UPDATED on 18th February 2008

This is a high-level introduction to Client Consolidation. 

Things change on a weekly basis and I usually don't have enough (spare) time to keep this site up-to-date on an hour base: double check is strongly required (as always).

Any feedback please send me a private e-mail to massimo@it20.info.

If you are interested I have just published a 60 charts presentation on "Client Consolidation" technologies. You can download it here.

Client Consolidation is a concept aimed at simplifying desktop deployments removing as much logic (i.e. software) as possible from the end-user's desk. Ideally Client Consolidation deployments leverages thin clients in order to keep remote hardware and software maintenance to a minimum.

There are 3 Client Consolidation models (CCON) and they are are:

• Shared Services (Windows Terminal Services, ...)
• Virtual Clients (VMware VDI, ...)
• PC/Workstation Blades (Clearcube, IBM HC10...)

Shared Services remains a very valid model for many circumstances. The PC/Workstation Blade model will most likely be a niche one for traders and advanced workstation users. The table below summarize briefly "pros & cons" of the three models:

This is for what concerns the "back-end". As far as the front-end is concerned (i.e. the access device) or <the thing> you would put on the end-user's desk it really depends on what you want to achieve / do. The picture below outlines some of the options:

And this brings us to the other important point which is: how do I get from the "client access device" to the back-end resource that I need ? And this is where the concept of the connection broker comes into play. As soon as I started working on these projects two things became clear:

1. While the idea of the connection broker was initially associated to the VMware VDI initiative, the concept and values of these brokers (or "infrastructure access" packages) has expanded a bit to encompass other client consolidation models such as the more traditional "Terminal Services" model as well as the niche "Workstation Blades" model. Shared Services (i.e. TS / Citrix deployments) are just not death and certainly virtual desktop can't be a good fit for everything either. Not to mention that these connection brokers are or will be able to broker virtual machines hosted also on non-VMware type of hypervisors so tieing this brokering concept to 1 out of 3 models and even worse to 1 single implementation (i.e. VMware) of the single model (i.e. Virtual Clients) didn't make much sense.

2. Connection brokering is only one piece of the functionality that these "infrastructure access" packages provide. Session brokering is the simple concept of redirecting an end-user to an available OS/application image (either from a pool or his/her own end-user image). As you can see below these packages (at least some of those) provide much more than that. That's the reason for which referring to them as "connection brokers" is kind of limited.

So in a nutshell: what started to be the "VMware VDI connection brokers" are now brokering other things than simply VDI vm's as well as these "VDI connection brokers" are doing more than "simply brokering". These are some of the features that a "connection broker" (or better "infrastructure access") package is supposed to provide:

The table below tries to summarize the various "connection broker" / "infrastrcuture access" products available in the market.

Consider that simplifying in a chart what you can and cannot do is not very simple since, most of the time, what you could do is determined by the client device you use, the broker software you use as well as the back-end service model you use.   

Explanation of the various characteristics in the table above

Web Site: this is the root web site of the ISV. It is not the specific product(s) web page.

License Cost per User: this is generally the list price per connected user that the ISV will charge you.

Easy to setup: this is a very generic and general statement about the complexity of the software setup. Just to give you an example I love Leostream for its simple setup (it's a Virtual Appliance). This is not an objective parameter though. Other products are known to be more complex and cumbersome to implement (especially when it comes to software that leverages multiple tiers of components etc etc).

Easy to configure/use: this is again not a very objective parameter. But it gives you an idea. So with this respect I find the Leostream product a bit more difficult to deal with compared to other products such as the Network Provision VAS. This describes the level of intuitiveness of the interface, if you will.

Scalability and High Availability: describes the fact that a given broker scales as the number of users increases and that it provides resiliency of operations.

Broker / Client relationship: This describes whether the connection broker solution requires a "proprietary" thin client to work or it can use an "open" and standard RDP/ICA thin client. Some vendors are providing end-to-end solutions which require all components to be aligned and do not provide the flexibility to use third party devices. This has of course positive and negative aspects.

CCON Models supported: here we would list which back-end CCON technologies the broker package would support. They are:

• Shared Services
• Virtual Clients
• PC Blades

Currently the table is comprised of more implementations for some of the models. For example the "virtual client" model can be implemented by a number of different technologies that are VMware VI3, MS Virtual Server (and future MS Virtualization technologies), VirtualIron and XenSource. Another important thing to notice is the notion of "Native support" Vs "Non native support" for each of these models. "Native support" means that the broker package can interact with the specific hosting platform management API's so that it integrates nicely. "Non native support" simply means the broker package can support virtual machines hosted on those platforms by mean of the virtual machines IP addresses. This in turn means the broker package would not have any level of integration with the hosting platforms. A sort of mid-way support which is "Native AD Support" is the capability for the broker to query the Active Directory in order to get the IP/names of client OS'es hosted on non otherwise natively integrated platforms.

Client Device Supported: this is a list of the available "client interfaces" available in the market. So this ranges from standard Win32 PC's to thin clients etc etc. Notice that "Win32 PC" means that the software has a native WIN32 client. On the other hand a software that has a WinCE or a Linux version for these nature of thin clients doesn't automatically means that it's available on ALL Linux/CE thin clients (it depends if the TC vendor has integrated it)

Seamless end-user migration: this usually would apply to a hosted client scenario only and it's a very important feature. Basically it describes the capability of providing a seamless swap for the end-user from the old PC to a very thin client. Brokers that are able to present to the user at logon a full OS desktop usually have a Yes here. Brokers that are only able to provide OS desktops (and other targets) via a portal from within another local environment usually have a No. The idea here is to be able to swap a legacy desktop and put a thin client under the user desk without him/her to even understand what happened (i.e. no re-training). Note: in this case we accept that the first login screen (of the broker software) is somewhat different from what the user is used to see at the standard Windows ctrl-alt-canc.

Client Device local peripherals support: some of these brokers leverage standard KVM protocols (such as RDP and other standard packages) while some other brokers use their own implementation of the protocol. An example of this (but not limited to it) is Provision Networks that implements its own RDP stack so that its peripherals support can go beyond that supported out-of-the-box using the standard MS RDP implementation.

Client Device Awareness: this identifies the capability of the infrastructure access solution to discriminate what to give to the users not only based on who he/she is but also based on what client devices he is using. The discriminator could be either the location (i.e. IP address etc etc) or the the type of physical device he/she is logging in from.

Guest Status Awareness: typically virtual client brokers trust what the virtual client managers (read Virtual Center) gets back to them. Unfortunately Virtual Center only knows whether a vm is running or not and has little knowledge granularity about the real status of a virtual machine. So for example a vm might be "running" but it might not be accepting RDP connections. Should the broker include this functionality it could ascertain with much more granularity whether a vm should be considered available for general use or not.

Role based security: this identifies those brokers that support different level of security and administration as far as the broker itself is concerned. So ideally there would be a broker administrator that could potentially delegate part of the broker administration to other people.

Telephony Support (Integrated VoIP): Some vendors are enabling end-to-end capabilities in their solutions that allows to get rid of the physical phone on the desk and use instead this new architecture to provide VoIP phone support. This could be a hardware or software based feature.

Video & Multimedia protocol performance enhancements: This would be a technology (independent from the Client Device being used) that would provide performance boosts when dealing with remote Video & Multimedia redirection (which has historically been a problem for RDP connection). Consider that some Thin Client vendors (such as Wyse) are offering similar solutions that are of course bound to the usage of those specific devices.

Act as a Data Stream proxy: this concept identifies an "access infrastructure" (remember that defining this a broker is becoming a bit limiting) that acts as a proxy between the client device and the target for remote video rendering. There are two philosophies/architectures: one for which the broker "stands in the way" and the other for which it "gets out of the way" once the target has been assigned. Client Device -> Broker protocol" and "Broker -> Client/Session OS protocol" characteristics are only available for those brokers that act as "data-stream proxy" between the client device and the Client/Session OS (this is today only the case for the Citrix Desktop Broker). On the other hand the "Client Device -> Client/Session OS protocol" characteristic is only meaningful for all other brokers that do not act as "data-stream proxy". The picture below explains this concept.

It is important to notice that the remote KVM protocols being supported by the broker packages in the table will also determine which Client OS I can install on top of a back-end virtual Infrastructure. So for example if a broker only supports the RDP protocol it won't be able to deal with a farm of NT 4.0 workstations since there is not an RDP server deamon for the NT 4.0 OS (at least as far as I am aware of).

Broker / Client relationship: This describes whether the connection broker solution requires a "proprietary" thin client to work or it can use an "open" and standard RDP/ICA thin client. Some vendors are providing end-to-end solutions which require all components to be aligned and do not provide the flexibility to use third party devices. This has of course positive and negative aspects.

Shared pools: This is one of the core functionalities for a broker. The concept is that a group of users has access to a common set of virtual machines (i.e. a pool of vm's) so that they are served with the first vm available from the pool. It goes without saying that the pool has neither persistent data nor personal settings on them (usually you have to implement roaming profiles and folder redirects for this model).

Dedicated Guest OS at first logon: Some brokers allow dedicating personal vm's to specific users. Some of these brokers allow a user to be assigned a generic vm from a pool at first logon and then create a persistent dedicated association to that vm.

Pre-dedicated Guest OS: Similar in concept to the "Dedicated Guest OS at first logon" but the assignment is done at the administration level and not when the user logs in for the first time.

Multi machines user support: This describes the capability of the broker to assign more than a single resource (vm, pc blade etc) to a given user. Notice that this capability could vary depending on the client device being used.

Single Sign-on: These brokers (or "infrastructure access packages") can provide a certain level of integration between login processes. One of the major roles of the broker is to profile users (against the Active Directories / LDAP). They could then use the same credentials and pass them on onto the target resource they have identified (a vm for example). This way the user only logs on once when they connect to the broker.

Automatic provision of pools: This is an extension to the "Integrates/Talks to Virtual Center". Other than being only able to "import" the existing vm's available in the VC catalog some brokers are also able to instruct VC to instantiate vm's that are going to be part of a pool that the broker administrator has just defined (or modified in quantity of vm's).

Pools usage reporting: Some of these infrastructure access software allows for a certain level of historical data of pools usage. Th emost advanced have algrythms that allows for vm's to be deployed, powered on, powered off and decommitted based on usage patterns monitored in the past.

Snapshot and roll-back: This feature would be of most interest for those set of users that needs to be able to control the standard snapshotting features of a virtual infrastructure but without having access to the administrative interfaces. Typical users would be developers and those working in testing environment. You could also associate this feature to self-service backup / restore of vm's for standard end-users.

Check in/out support: This describes the capability of letting the user, through a friendly UI, to check out a specific virtual machine for off-line work and be able to later check it in again onto the virtual infrastructure (possibly via differential export / import). This feature would be of most interest for users that spend most of the time in the office but yet would need a certain level of flexibility and support for off-line periods.

Secure Connectivity provided out of the box: This describes the feature of these "infrastructure access" brokers to be able to create secure channels between the client device and the target object (i.e. a vm for example). Some brokers do not have this feature and they only rely on network security channels such as VPN's etc etc.

Printing optimization out of the box: this describes whether the infrastructure access software provides printing optimizations (such as universal printer drivers etc etc) that simplify printer management. There are third parties on the market that provides similar features but having it integrated with the product out of the box is certainly an advantage.

Seamless Application Publishing: this is a concept that has been around for years in the Citrix deployments: being able to publish an application hosted on a Terminal Server seamlessly onto a standard Windows PC (so the end-user would be able to access it without even knowing it is not installed on the PC). I have reported the same concept for all three models (Shared Services / Hosted Virtual Clients / PC Blades) to see where it applies. Doing the very same thing with an application installed on virtual client (Vs a Terminal Server) is very powerful because all those applications that cannot work or are not certified in a Shared Services environment can now be installed in standard XP os (for example) and be distributed in the same seamless way.

********************************************* UNDER DEVELOPMENT ******************************************************************

The following table is currently work in progress. The idea is to expand on the "Client Device Supported" above to explicity state which thin client model works with which broker software. This is important due to the fact that, although a Windows CE / Linux agent is made available by a given broker ISV, it doesn't automatically mean that every CE / Linux device will support it due to the integration work the IHV is supposed to do in order to make it available for its own set of thin clients. Same (if not worse) is true for Linux thin clients as every vendor tends to use its own flavour/variation of Linux.

Before you refer to the column below please notice that some thin client vendors, Neoware being an example, have thin client hw models that they can mix and match with any OS (CE, XPe, Linux...). That's why in the chart below I refer to WinXPe-based, Linux-based or WinCE-based since the integration depends on the OS and not on the hw device being used. On the other hand there are other vendors, Wyse being an example, where a given thin client model name specifies the hw being used as well as the OS being installed on top of it.

Back to it20.info