Top 10 Server Consolidation issues - Part 5

This is the fifth instalment covering server consolidation issues.  In the original post I highlighted 10 issues that are frequently mentioned, these additional posts are intended to cover one or more of these issues in more detail.   Today were are dealing with licensing and support:

6. Licensing – what effect does this have?

First I’ll cover virtualisation licensing, and a couple of issues, the first being that a server (Microsoft) OEM licence is often specific to the server as purchased from the OEM.  So if you decide to migrate the server operating system and line of business application, you may have to buy a new copy of the OS (or ensure you are covered).  The second and it’s on the same theme is to remember that the host OS (the one that sits on the physical hardware) does need a licence and you may need to licence the entire software stack on that machine as well.  I know that the last point sounds obvious but there have been some instances when just the virtual machine licensing (guest) has been considered in business cases.

The other main issue with licensing (and I can only point this out – as there is no easy resolution) is specific to co-hosting, the issue is that some vendors licence per CPU and if you consolidate workloads from many smaller servers to a co-hosted system such as a 4 or 8way server you may have to over buy licences.  Let me make that clear, say you move a SQL server database that was on a 1 CPU system to a 4 CPU system, even though you only need one CPU’s worth of use from the solution you may have to buy (check your options here) an extra licence to cover the additional 3 cpus.  This can be a costly approach unless you can move (as per my last example) many other SQL workloads onto the 4 cpu system and make use of the additional licences purchased.
In addition there are still instances where an ISV charges you if you move servers, even if you move from their product to their product (and keep the versions the same) as there can be a tie in to the server name or IP address.

It’s a shame but licensing isn’t straightforward and can be doubly confusing when you consolidate, the good news is that consolidation is now common place and that is helping vendors structure the offering they 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)

When looking to consolidate there are many support angles to consider; your own internal support (which can be via many teams or groups), support from the software vendor and maybe even from the hardware provider.  You may need to look at the licensing small print to see what your options are, but in most cases support contracts only consider the case of one application on a single server.  Two common issues with support are:   

         a) An application is given full administrator rights to the entire server (because that was ok when it had the server to itself)

         b) The software provider will only provide support if the application is the only application on that server. 

There is a third issue which is that some organisations allow remote support into servers, via dial-up, RAS or VPN – not a good situation when consolidating.
In my experience most vendors when you explain what you are trying to achieve with consolidation are willing to listen, initially they may be sceptical but will usually accept the situation (they don’t want to loose your custom after all).  Actually the last sentence applies equally well to licensing – and consolidation is your opportunity to renegotiate or improve both your licensing and support requirements.