Ten common mistakes when consolidating servers
Consolidation projects are easy to cost-justify, but rarely easy to execute.
By Andrew Hillier, CiRBA | Published: 01:00, 17 January 2007
As enterprises look to squeeze cost savings out of their IT infrastructure, CIOs and data centre managers alike are turning to server consolidation as a way to meet this objective. According to Gartner Research, 60 per cent of surveyed companies are in the process of consolidating their infrastructure, and 28 per cent are planning or considering consolidation.
Server consolidation projects are easy to justify financially, but that doesn't mean that they're easy to execute. From believing new hardware must be purchased and deployed, to thinking virtualisation is the only route to success, miscues and misconceptions cloud the route to true cost savings and a more efficient data centre. The following list contains some of the most common mistakes made in server consolidation projects, along with advice on how to avoid them.
Equating consolidation with new hardware purchases
Consolidation doesn’t necessarily mean expensive new hardware is required. Consolidation onto what you already own is a far more cost-effective approach, and in many cases, should be the first thing you consider. Once you have maximized the utilisation of the best of what you have, you can move on to new purchases.
Looking at simple workload patterns
While workload is an important factor in considering consolidation, it only shows you what might be compatible due to slack and fit. It tells you nothing about server compatibility or what the right things to virtualise are. Additionally, workload analysis is often overly simplistic. Analysis should consider how servers spend most of their time, or even the time of day when they are the busiest. Server workload patterns usually show specific spikes and if you can find servers that spike at very different times of day, although average workload would suggest their workloads could not be combined, more sophisticated analysis would suggest they can.
Failing to consider non-technical constraints
Rapidly moving to consolidation and or virtualisation and not considering non-technical factors can cause problems later. While it may be attractive to move many applications onto the same physical server, by doing so you subject all of the applications to the influence of that one piece of hardware. If the applications have different service-level requirements or change windows then you will experience issues.
Acting on dated information
Consolidation analysis projects can sometimes take months. In some cases professional services firms are hired to conduct these types of analysis. The result of this work is usually a paper report at the end of the engagement. Taking action on the results of such an analysis can be risky. Considering the rate of change in many IT shops, it is critical to be acting on fresh information.
Broadcasting your intent prior to gathering data
IT staff may consider consolidation as a negative. Some might perceive it as shrinking their influence or importance due to a reduction in what they are managing or even a threat to their jobs. It is not unheard of to have staff find ways to make servers busy during the analysis phase in order to “shape” the results. It is best to gather empirical information from the environment prior to engaging staff in interviews etc. that telegraph your intent.
Using virtualisation as the only strategy for consolidation
Many think only of virtualisation when considering server consolidation. This thinking can limit impact. Virtualisation is powerful and flexible but strategies such as application and OS stacking are often attractive because they do not add the overhead, licensing and complexity of virtualisation. Additionally, some servers and their applications simply do not suit virtualisation and would as a result be left out of scope.
Leaving database servers out of scope
As a follow up to No. 6, I/O limitations mean that database servers are not good candidates for virtualisation. Database server sprawl is a major issue for many organisations and there are ways to reduce numbers significantly with the right kind of consolidation analysis and action.
Leaving application servers out of scope
Application servers often go untouched in consolidation projects. With the right planning, application servers (J2EE environments and accompanying web servers which are usually drastically over provisioned) can be consolidated for big gains.
Leaving test/development environments out of scope
Development and test environments are often the worst offenders when it comes to hardware and software sprawl. They are also least sensitive to workload issues as they are not customer-facing. In many cases a significant number of database servers can be consolidated without any impact on productivity or utility.
Failure to look into financial benefits and the variables that affect ROI
There are many factors that contribute to the financial impact of consolidation. For example, consolidating database servers tends to return significantly in cost savings because it is relatively easy to action. Consolidating complex applications that require significant testing can kill return on investment because of the time and effort required. Make sure you are choosing the right targets.
Andrew Hillier is co-founder and CTO of CiRBA.