Between VDI and SBC

Meet the rock - VDI - and the hard place: SBC. Server Based Computing (SBC) might not be the most exciting technology, but it is exciting from a cost point of view. It requires one large server, which means that you have to maintain only one server OS, which can support - depending on the amount of RAM you put in that machine - up to 100 users or more. As sessions don't require that much memory and you have only one kernel running, the memory demands are generally low too. The bandwidth demands are ridiculously low: one user can work over an ISDN line. Best of all, it is much cheaper to let 100 users access one server than paying for 100 OS licenses. Of course, SBC can only be used for "CPU light" software, and for software that is compatible with Terminal Services or Citrix.

VDI doesn't have these limitations. Basically you run a lot of desktops in separate virtual machines on one or more servers. Compatibility is not a problem, as each application gets its own OS running on its own virtual machine. In a sense VDI offers the same thing as CCI, but on virtual instead of physical machines. Our own research shows that if you attach one virtual machine to one CPU core, the performance loss of virtual machine manager is negligible, between 1% (CPU intensive applications) and 8% (memory intensive applications). Once you use more virtual machines than CPUs, this quickly rises to 15% and more in some cases. This is still acceptable, but if you absolutely want the same performance as CCI, you need one core per desktop.

The disadvantage is that VMWare ESX licenses are not cheap, unless you run a lot of virtual machines per socket. It is clear that quad core CPUs are the way to go here: it makes the Intel Xeon 53xx ("Clovertown") very attractive. VDI is certainly not a replacement for Terminal Services (TS). With TS you have to manage one OS for maybe 100 users; with VDI you have to manage 100 OSes for 100 users. For those of you that are relatively new to SBC, VDI, and blade PCs, you can get a brief overview in the table below.

SBC Overview
Feature Server based computing VDI Blade PC Workstation blade Traditional fat Client
Client Terminal PC thin PC Thin PC Thin PC desktop PC
Task of the Terminal server Server processes application data for many clients One virtual PC processes data for one thin client One blade PC processes data for one thin client One blade PC does it all, sends compressed and encrypted graphics stream to one thin client No terminal server
Task of the client Displaying GUI Displaying GUI Displaying GUI Displaying the graphics stream from the workstation blade Displaying GUI & processing business logic
Relation Client - terminal server n to 1 1 to 1 1 to 1 1 to 1 N/A
3D graphics? No No No Yes Yes
Typical tasks Light office work Software that is not too intensive and that doesn't work with SBC Data mining, application development CAD Light office work to Heavy CAD
Impossible tasks CPU or graphics intensive apps Graphics intensive apps Graphics intensive apps High-end CAD applications Nothing
Protocol ICA (Citrix), RDP (MS) RDP RDP RGS (HP), IBM prop. Protocol N/A
Bandwidth 0.02 to 0.03 Mbit/s 0.03 Mbit/s 0.03 Mbit/s 2-4 Mbit/s N/A

So where does CCI fit? This is how HP positions Blade PCs relative to SBC and VDI. The X-axis represenst the increasing complexity of the user's required software, the Y-axis the level of performance one needs.


HP sees a lot overlap between blade PCs and SBC. We don't see so much space. With quad core CPUs, 64-bit Windows 2003 (and Linux), and decent Gigabit NICs, performance shouldn't be a problem for SBC. We mention the 64-bit OS as it is important because it allows servers to take advantage of large swap spaces and more than 4GB of physical RAM. It is hard to see any reason to go blade PC when your application is compatible with Terminal Services.

Making sense of CCI Conclusion
Comments Locked

39 Comments

View All Comments

  • smokenjoe - Wednesday, July 25, 2007 - link

    I just thought I would post some end user experience as these are not all that common. We had an intel based thin client. When they were fist implemented last year they were OK slower than the dated computers they replaced but usable. Unfortunatly as time went oth they started having more and more issues to the point that it was common to have only one working thin client out of 6. We had to boot the clerks off their old PIII computers from the dark ages because they were the only ones that worked. People literally jumped for joy when we got the PC's back.

    Without being part of the IT department it is hard to say where the fault was but at the bare minimum make sure you have people that have the training and security privileges to fix problems any time they are needed. I had multiple reports of "I cant fix that I dont have the security privileges we will have someone fix it on Monday."

    Thank god they did not think the clerks important enough to upgrade or we would have been lost.



  • yanman - Monday, July 23, 2007 - link

    Another alternative which is available through a mix of technologies is removing only the local storage of your corporate desktop fleet and replacing this with a PXE-boot solution. There are vendors that can allow iSCSI boot of XP installs via a proprietary solution using PXE.

    i.e. Dell Optiplex with onboard GbE, boots from PXE, loads iSCSI stack, mounts guest LUN on the SAN for it's XP image, boots. Possibly you could leave the local hard disk in and use it only for swap space.

    Advantages
    - Less forced change on the users
    - Better workstation performance
    - Retains the thin-client advantages of ensuring all data is on the SAN

    Disadvantages
    - Can significantly increase SAN and network utilisation
    - Slightly exotic setup that may not be fully supported by the hardware vendor.
  • Ajax9000 - Thursday, July 19, 2007 - link

    Could you please spell out VDI on page 9. I knew pretty much what was being talked about, but I still had to Google to be sure.

    The workstation blades are an interesting development. Would it be possible to do VDI over workstation blades?

    I ask because where I work (a government department) went Citrix in about 2001. At that time performance was reasonable in Head Office, but flaky in the handful of regional offices. We had thin clients, skinny clients (PCs stripped down to act as thin clients -- to save on TCA of course), and fat clients for specialised uses. It worked quite well -- I'd run 20MB+ spreadsheets under Citrix and use a fat client for publishing & graphics apps that wouldn't run under Citrix.
    The only problem was making sure IT didn't downgrade you from fat client. :-)

    But the government then amalgamated us with some other agencies (with standard PC setups) and we went from ~800 staff to over 2500 staff with many regional offices with poor network connections. And there was much more specialised uses such as greatly expanded GIS/mapping, web mapping, publishing, etc. Trying to get a sensible IT setup took three years ... and then there was another round of amalgamations with another round of IT integration issues that still haven't been resolved (and again involving lots more GIS/mapping, web mapping, etc).

    So, would it be possible to do VDI over workstation blades as a way of distributing ARCinfo "floating" licences, Adobe apps, etc, across multiple sites rather than having dedicated workstations in "fixed" sites?
  • RandyDGroves - Thursday, July 19, 2007 - link

    This was a nice detailed review of CCI, but completely missed the fact that IBM is using PC-over-IP technology from Teradici (www.teradici.com) instead of a Thin Client. Unlike software solutions such as ICA, RDP, and RGS; Teradici's PC-over-IP processors use hardware to bridge the video, audio, and USB traffic between the desktop device (called a Portal) and the blade workstation. This enables a perception-free experience in which the end user cannot detect that their PC has been remoted. Furthermore, since the Portal only has a hardware decoder chip, it is lower power than a Thin Client.

    For full disclosure, I am the CTO for Teradici and obviously biased. But, here are some links to recent articles in other publications that may be of interest:

    Wall Street Journal - http://webreprints.djreprints.com/1722520524296.ht...">http://webreprints.djreprints.com/1722520524296.ht...
    EETimes - http://www.eetimes.com/news/latest/showArticle.jht...">http://www.eetimes.com/news/latest/showArticle.jht...
    The Register - http://www.theregister.co.uk/2007/06/06/teradici_b...">http://www.theregister.co.uk/2007/06/06/teradici_b...
  • JohanAnandtech - Thursday, July 19, 2007 - link

    The briefing we got in IBM's blade HQ in Raleigh about the IBM HC10 was a lot more about the concept. The actual hardware and software was not discussed in detail. That is why I focused mostly on CCI, as I had been shown the exact specifications.
  • florrv - Thursday, July 19, 2007 - link

    As a network security manager for an F100, we've found a very useful niche for VDI technology: 3rd party developers.

    Rather than have a 3rd party connect directly into your dev environment, you set up a VDI environment and give them a controlled sandbox. This way, you can lock down what data goes back and forth to the 3rd party.
  • senseamp - Thursday, July 19, 2007 - link

    As mentioned, this has been out for 8 years as SunRays.
    http://en.wikipedia.org/wiki/Sun_Ray">http://en.wikipedia.org/wiki/Sun_Ray
    You can take your badge out, go to any place in the company with a Sunray (like drop in office), put your badge in, and it will pop up the desktop where you left off. Unix (such as Solaris) is designed from ground up for this kind of work (multiple users running on same OS with remote display), so it works very well, if the network is behaving well. With star/open office and firefox/thunderbird, that's good enough for most office work, and if you need a lot of performance, you can dispatch jobs to bigger machines or compute farms in the company.
  • szaijan - Thursday, July 19, 2007 - link

    Sun has been pushing the thin client architecture for years, yet there's no mention in the article. Having worked on multiple Sunray clusters, and many PC netwroks, I have the say the thin client setup is much better for day-to-day office and e-mail work, simply based on the lack of overhead in installation, bug resolution, boot times, et. al. Cost is much lower overall. The downside is that network problems make work impossible, while you can still utilize a PC when the network is down or overloaded. A decent netwrok infrastructure makes this a minor issue.

    All that said, CAD, Photoshop, 3D Modeling, et. al., while not impossible, are badly hampered by the mouse latency, and the precision needed for such endeavors just isn't there. Of course you can just add a work station to the network for employees who require that level of client power.
  • Adul - Thursday, July 19, 2007 - link

    We've been on a mission to getting rid of our thin clients as they been a source of pain since they keep getting infected with viruses, we can't patch them with normal updates, etc.
  • JohanAnandtech - Thursday, July 19, 2007 - link

    Very interesting. As you might have noticed, there are a lot "should" and "might" in the article :-). Could you tell me what kind of thin clients you are using? Running XP Embbedded? Why can't you patch them?

Log in

Don't have an account? Sign up now