Many of us understand the nuances of server virtualisation —you take a server, you replicate it into a hosted environment using some sort of Virtual Machine Software and then you retire the physical machine from its former purpose. Sounds simple, and for the most part it is. Software products like VMware have made the process very simple and have made virtual server utilisation a very commonplace event. But, in the mad rush to virtualise everything there has to be an
evaluation of what to virtualise.

Everything is beautiful
I recently attended a conference where virtualisation was the hot opic. One CTO even boasted about how many physical servers he had retired — it was impressive. But, when I asked him what his effective throughput rate or transaction was with the new virtual environment as opposed to his physical server infrastructure he had no answer. It is not an uncommon occurrence. Many top IT professionals don't look at their metrics before they do something, and then have no idea how they have helped, or hurt, themselves.

The obvious positives of virtualisation are clear — lower power consumption, simpler server duplication/replication, easier server management, simpler IP address and VLAN management, etc. The Aberdeen Group conducted a study in 2008 which outlines some of these issues. In it, they found that organisations experienced 18 percent reductions in infrastructure cost and 15 percent savings in utility cost by virtualising their server environments.

But, there are times when other performance measures need to be considered. There is a quantitative aspect to everything — that is a given, but there is also a qualitative aspect to most things — and that is often more important.

Honey, I shrunk the server!
So, this CTO took his server environment from 180+ servers to fewer than 60. What did he virtualise? In his own words, "everything." I followed up with him on the details and they have indeed virtualised everything. But after our meeting at the conference he began to think more on what we had discussed about performance and throughput. Since he had no metrics prior to virtualising he had to use a more ad hoc method — user feedback. This is often very problematic unless you have vetted the responses objectively.

To his chagrin, he noticed that trouble tickets related to his BES (blackberry enterprise server) had risen by 25% in the 30 days since that environment was virtualised. A huge rise given his company has more than 1300 Blackberry users. If only his people had done their homework ahead of time they would have realised, based on other companies experiences, that BES can be virtualised, but there can be some sever IO penalties and performance can (and most often does) suffer.

To P2V or not to P2V: That is the question?
E-commerce systems were some of the frst to be virtualised because of their, typically, web based components. Web servers, typically, do very well in a virtualised environment. Some will argue that virtualisation was made for web servers and internet application servers. But is this a global truth? There is a great deal of evidence that virtualisation can muddy the waters when it comes to performance.

The Aberdeen Group's June 2008 report shows that organisations can experience up to a 9 percent loss of overall revenue if issues exist with business-critical application performance. Seventy four percent of the organisations surveyed also reported problems with application performance which coincided with a signifcant drop in customer satisfaction.

A key challenge for organisations adopting virtualisation is effectively managing application performance in virtualised environments. The capabilities required in a virtual environment were not necessary when these organisations were looking to achieve the same performance goals in physical environments.

Full speed ahead..
One of the biggest uses of virtualisation is server consolidation. Many larger companies had, for the longest time, multiple data centres that interacted and interfaced continually (or using batch processing). Users in each location logged onto their local servers which then exchanged data between sister servers in other locations. WAN traffc was, thus, consolidated and data greatly compressed.

With virtualisation, many companies have opted for more centralised computing environments. So, users in Europe now have to log on to servers in the US, whereas before they logged onto servers locally. WAN traffc then starts to increase and system bottlenecks become more common. These are not abstract observations or "what-if's." They are real life occurrences that companies have experienced. Because of the increased WAN traffc, the end user experience, for internal and external users, was not improved and actually degraded.

Thus moral to this story is — PRIOR PLANNING PREVENTS POTENTIALLY POOR PERFORMANCE. For many companies, the gains they see in virtualisation can be quickly wiped out by the need for larger internet or network bandwidth. Thankfully, for many, WAN accelerators can be put in place, but it is always better to consider this as part of the initial virtualisation plan instead of provisioning it on an afterthought.-

Recap
Here are a few factors to consider when making the move from physical to virtual environments:

• Obtain performance metrics for as many aspects of your physical environment as possible so you can actually see what has improved and what has not as a result of virtualisation.
• Identify, in advance, what technologies are not suited to being virtualised.
• Consider what you are consolidating and look at bandwidth as a factor — you can recover from poor planning, but you only get one chance to make a good frst impression.
• The WAN is often more sensitive than the LAN — look at what impact virtualisation will have on your Wide Area Network.
• Ensure that visibility into your entire transaction fow is not lost by moving from a physical to a virtual environment. This is one of the areas where individual server statistics can be obscured in a virtualised environment.
• Measure the quality of your end user experience before you start a virtualisation project.
• Identify ways of managing your Service Level Agreements around applications hosted in a virtual environment.
• Anticipate performance issues in the planning stages of your P2V project. The more you think of ahead of time the better the overall experience will be for all involved.

This list is by no means defnitive, and best practices would be the forum for another article. However, these factors are meant as a beginning point and as a means of initiating the thought process before engaging in a virtualisation project. It is the minutia that will kill you (or your career) when it comes to high profle projects of this magnitude.

—Thomas Struan is Principal and Senior Consultant at Thomas Struan Consulting