Top 10 Server Consolidation issues - Part 1

Yesterday for the first time in a month or two I presented on Server Consolidation, it made me think of a few things:

1. Many people don’t know what resources exist, where to get advice on consolidation
2. Its often assumed that there isn’t any advice especially from Microsoft on this subject
3. This blog was supposed to be about consolidation, and so far it’s contained very little until now… 

Here are my top 10 reasons people give for not consolidating or they quote these during the initial phases when scoping or preparing for a consolidation project.  From personal experience I agree with these, you may know of others but these seem to be the common ones.

1. Organisations lack up to date inventories
2. Application dependency or reliance isn’t known
3. Knowledge of applications isn’t readily available – often reliant on a single person
4. Many organisations have interdepartmental issues, every group needs to be involved and bought into (committed) to consolidation   
5. Testing has a new significance (especially true for mixed workload / co-hosted consolidation), reliance on doing this manually might not be sufficient
6. Licensing – what effect does this have?
7. Support (namely OEM and ISV’s who wont support you in a ‘shared’ situation – or the support of a application requires ‘ full admin’ rights)
8. Legacy hardware – modem cards, fax boards
9. Change control or the lack of
10. Re-writing an application isn’t possible (might not be now but may be in the future) or what applications can I consolidate?
 

So let’s discuss these points in some detail (and by the way if you want to skip ahead here, most of the advice I’ve summarised can also be found in detail within the documents I have linked to in this prior consolidation post)

I will deal primarily with co-hosting (or mixed workload) when I talk about consolidation, the alternative is virtualisation, using such tools as Virtual Server 2005.  Co-hosting deals with running multiple copies of the same application on a single Operating System image, or running different applications on a single OS image.  Virtualisation includes but isn’t limited to running a separate OS image from within another to host the application – giving you a reduction in hardware rather than OS’s.  For a comprehensive description of consolidation terms please see this post by Chris.

So lets address the first point

1. Organisations lack up to date inventories

This is typically the situation that most Windows sites find themselves in, due to rapid expansion, de-centralised IT, it’s often difficult to get even a simple count of the number of server’s yet alone complex detail. 

It’s the detail as well as the inventory that you need for consolidation.

Most if not all consolidation exercises are undertaken to streamline, improve efficiency become more agile or dynamic but ultimately to save the organisation money – so to measure you must [obviously] first know your starting point or baseline – how many servers, what type and what are they running is a minimum.  In addition to the inventory you may also need to look at utilisation levels – so that you focus on those servers that are barely being utilised, as consolidating high utilisation servers may cause conflicts – you need to balance the workloads when/if you combine them.  Gartner says that the average workload is approx 15% - so that leaves 85% of resource free that you have paid for, are paying to manage that isn’t helping your business – actually in my experience 15% is actually more like 5%!!!

So how do you go about obtaining an inventory, it may be as simple as going into the computer room and counting (but that is very basic), or if you have an installed systems management utility pulling off a report. 

What do you look for, well servers of a similar build are easier to co-host than those that run different components – this goes down to the drivers, service packs, hotfixes as well as application versions (ideally cross referencing DLL’s is desirable), and this is a lot of detail to obtain.  Due the potential effort involved the use of a tool is preferred (it also helps as automation is desirable so that you can keep the inventory current); tools such as Microsoft SMS and other management tools provided by our partners are recommended. 

Remember consolidation isn’t an end state – you will always be adding services into your consolidated environment – consolidation therefore never ends.

In addition some of our partner consultancy organisations offer services and or tools in this space.  If the tool used can also capture performance data (and be able to model it) then you have all the bases covered.

When you have this data you can begin the analysis – again the consulting organisations have skills in this area.  The Microsoft guides mentioned in the links I have provided are crucial to walking the decision tree of what should be considered and to recommend the desired platform. 

You may perform simple analysis yourselves, perhaps grouping the servers into functions, such as File & Print, LOB applications, Messaging, Database etc… 

You can then break down the individual services or applications within these groups in more detail – Homogeneous and Heterogeneous is a good starting point as is grouping by criticality or even by location (location maybe crucial if low bandwidth or latency is a issue to you).

At this point you will (almost certainly) exclude some servers from the plan…I’ve never seen [yet] a consolidation project where all servers were deemed ‘in-scope’, normal resilience and redundancy requirements mandate that two physical servers are the minimum for some key services, such as Active Directory…so if you have two servers that probably is the minimum already.

 

That's it for now...which leaves 9 points to cover for another day (or over 9 days?)