THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Buck Woody

Carpe Datum!

The Dark Sides of Consolidation

Consolidation, as it applies to databases, is simply putting more databases or SQL Server Instances on less hardware. This is a good thing, normally, because it allows you to save on hardware costs and use what you have at it’s highest capacity. It also saves on energy costs, floor and rack space, and in some cases even licensing and software.

But there are issues that you need to consider. When more databases or Instances there are on a single server, the higher your risk when that server is unavailable. For instance, let’s say you have 10 servers with various databases that hold your organization’s application data. If one of those servers goes down today due to a hardware failure, then one application is out of commission. Now take those 10 databases and host them on a single Instance, or set up 10 Virtual Servers on a single hardware box. If that system goes down, now 10 applications are out of commission.

And it isn’t just that. It’s the recovery time for all of those systems. Even in a single system failure, it isn’t a matter of simply restoring the last backup. Whenever an application goes down, you have to check the consistency of the system by verifying what data made it in before the failure and what needs to be re-keyed, or if the data made it in whole or in part. Now you have that on 10 systems, not 1, and that takes a lot more time.

How big a risk is this? Well, the other day I lost power to a switch (how in the world does THAT happen) and lost 5 Virtual Servers in the middle of a test run. I had a friend that same week that lost a SAN connection (driver issue) and lost a consolidated Instance of SQL Server with 25 applications on it.

So does that mean you shouldn’t consolidate? No, it just means that you need to consider that risk. Add what you need to make that system redundant as possible, and include the increased process in your Disaster Recovery planning. And you have to communicate that risk and increased time back to the business.

Published Thursday, December 10, 2009 6:56 AM by BuckWoody



Wes Brown said:

We had some growing pains when we consolidated like 90% of our non-sql servers onto a ESX cluster, before if one machine puked no big deal now it took down half of production. Was a motivator to get onto HP hardware off of beige boxes build in house.

December 10, 2009 11:04 AM

Brent Ozar said:

Another problem is that suddenly maintenance windows are much harder to organize.  Instead of getting 1 business manager to pick a time, you have to get 10 of them to agree.

December 10, 2009 12:03 PM

Jonathan Gardner said:

One thing to keep in mind when disaster planning is that some things don't exactly fail like they are supposed to.  You have to plan for that two.

We had drives in our SAN start throwing hard read errors.  This didn't take the SAN offline so it was still trying to serve storage off of LUNs with bad disks.  It caused all kinds of head ache until we figured out what was going on.  By removing the entire NODE we were able to settle everything down.

December 10, 2009 1:48 PM

Jeff Moden said:

It's good to see someone other than me finally say that there is an unconsidered risk to putting all of your eggs in one basket. Thanks.

--Jeff Moden

December 10, 2009 9:16 PM

Marco Kleinert said:

Another problem is security. You cannot isolate all applications on a consolidated instance.

December 11, 2009 4:43 AM

ALZDBA said:

So, you mean it isn't just the "simply install of hyper-V (or so) and copy a syspreped file, bring it up , and off you go" ???

Woeha :)

Don't you just love "shared bottlenecks".

Consolidation always starts with a (relatively) big investment on hardware and redundancy, organizational impact on security,....

It means every hosted system must have its DRP revised. Mainly to determine the minimum hardware requirements of your hosting infrastructure.

But that is being forgotten to many times.

December 13, 2009 3:11 AM
New Comments to this post are disabled

About BuckWoody

This Blog


Privacy Statement