Tuesday Dec 05, 2006

Virtualising the Desktop

In spring 2005, nearly 2 years ago, I started on a brainstorming session with a couple of people from Reuter's CTO office which started a train of events that was to lead to the delivery of a virtual desktop infrastructure that has now been deployed in Reuter's newest development facility in Beijing.

The problem that Reuter's were facing and trying to address is one that is common to many software development organisations. Each developer had on his or her desk several machines. One which acted as their main “desktop” running standard things like email, web, desktop publishing, etc, these machines were centrally managed. The other machines were behind a local firewall/router and had little or no central control, these machines were to provide development, test and build environments and were unique to the developer or the project that they were assigned to. The problem was that when you looked at the total estate it was large (typical estimates for this type of environment are between 2 to 4 machines per developer), heavily under utilised, taking developers time away from their day jobs to administer the systems and not standardisation of tools or versions of applications being used. It was also difficult if not impossible to get a handle on when or indeed if resources (software and hardware) were being re-used or recycled between project or if geographically distributed development teams were duplicating resources. The solution that we were looking for therefore needed to address the following needs.

  • Reduce Costs – Ownership and aquisition
  • Improve Standardisation – Common tools and environments, enable sharing and re-use
  • Share Infrastructure – enhance utilisation
  • Asset Management
  • Security & Audit
  • Mobility
  • Resilience – Political, Pandemic, Geophysical, Meteorological
  • Support for Windows, Solaris and Linux developers

 

The solution that we came up with has been called a number of things none of which truly describe the solution adequately. These include Common Developer Desktop, Thin Client Desktop, Utility Desktop and Display Utility. In actual fact what we did was to first virtualise the machines that developers had previously had on or around their desks and move them back into a shared piece of infrastructure that could be housed in a machine room or data centre. We then provided an access layer that allowed access to the system through a variety of client devices. The client devices included a browser based thin client application (Sun Secure Global Desktop) either locally or remotely, Sun Ray devices on a local area network and remote Sun Ray devices. Access control was managed by interfacing to the Reuter's pre-existing Active Directory system for authentication and authorisation and was via secure username/password authentication from SSGD or JavaCard when using the Sun Ray devices. The infrastructure virtualisation was provided by Vmware ESX for the Windows environments and by Solaris Zones and Logical Domains for the Solaris Environments.

I will talk in some more detail around the solution architecture and how it delivers the various benefits requested in later postings but it does seem that increasing numbers of people are beginning to wake up to this type of approach. Desktop Virtualisation is in danger of being deployed before data centre virtualisation. Also as the pressures of space, power and cooling start to hit office facilities in our big cities this approach provides a solution.

 

Architecture Overview
 

 

About

seanharris

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today