Consolidating Again and Again and Again

  • Comments posted to this topic are about the item Consolidating Again and Again and Again

  • On the subject of consolidating SQL Server instances, we have the opposite problem of trying to arrange separate groups of databases on one machine. This is really just get round the fact that SSMS doesn't allow you to group them visually in Object Explorer. Are instances the only way to achieve this, e.g. to separate out production and testing databases?

  • The company I work for was bought out so both of our companies are going through an analysis phase of consoldiation. We have more SQL Servers and databases here but they have alot as well. Over the last three months we have identified older less used servers that we can move the databases to existing beefier SQL Servers and eliminate licensing and hardware. So far we have made good progress and are about half done. Going forward all applications instead of using the servername use a dns alias which in the future will make it easier to 'move' an applications databases to another server for either further consolidation or just upgrading. All you do is move the dbs/logins/jobs and change the dns alias. No code changes, no searching to figure out how the app points to the SQL Server.

  • One 'could' argue that the long term cost savings in virtualization/consolidation is not having to maintain the hardware you didn't buy. The three year hardware replacement cycle savings would be huge over the long term.

  • Worked on a lot of consolidation projects, seems to be more the latest buzz word rather than a concept that gives consistent results to the business. Unless it is planned properly it can be more of a cost loser rather than cost saver. maybe i'm too jaded and cynical, seen too many screwups in the pursuit of cost cutting projects by bean counters, voicing the usual words. consolidate, consolidate, consolidate.

    --------------------------------------------------------------------------------------
    [highlight]Recommended Articles on How to help us help you and[/highlight]
    [highlight]solve commonly asked questions[/highlight]

    Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden[/url]
    Managing Transaction Logs by Gail Shaw[/url]
    How to post Performance problems by Gail Shaw[/url]
    Help, my database is corrupt. Now what? by Gail Shaw[/url]

  • I think there needs to be a healthy balance in any consolidation effort. We have a TON of servers in our datacenter that run one app or host one or two small databases and the resources on that hardware average under 10% utililization. If you pick and choose the right things to consolidate it can be benefitial and make everyones job easier as you have less physical hardware to maintain and keep up to date. If you take the opposite approach and just pick things and 'force' a consolidation just to consolidate you are in putting the company at risk. We have already consolidated some small apps/databases and the consolidated servers you cannot even tell there is much more load on them. We had too many projects over the years come in and say we need X number of servers for this and that and we SHOULD have stepped in and said what are the requirments and prove you need seperate hardware first.

  • We had hundreds of instances at JD Edwards, and make regular efforts to consolidate things. We did not take a "everything should be consolidated approach", but rather identified underused instances, talked to business owners/clients, and then regularly would move databases together and retire old hardware or repurpose it.

    There's nothing wrong with bean counters driving it, you just need IT to make good decisions and not buckle under to pressure to just combine things.

  • For years I've been frustrated how often new servers were needed. "You have to add 2 + 2? OK, we'll need another server for that. "

    So it's no surprise to me that now we need to talk about server consolidation.

    Stick around long enough and you'll see IT go 'round in circles.

    The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking

  • Virtualization can save money on an ongoing basis. As already mentioned, less maintenance and upgrade cost because of less hardware. Even more so, when done correctly, it can keep apps and databases up and running despite hardware failure on a server, which serves much the same purpose as clustering/mirroring, but without the "we have a server that just sits around doing nothing but prepare for disaster". Keeping apps and web pages and databases up and running, instead of allowing for downtime, can save a company a lot of money in terms of preventing lost opportunities.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • Still, mirroring, log shipping, or what have you to a server a couple of hundred miles away will save your company's hiney if your building is flooded, get's hit by a tornado, gets burned to the ground, blown up by a nut, or anything else that would take out the important parts of the server room.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden (11/13/2009)


    Still, mirroring, log shipping, or what have you to a server a couple of hundred miles away will save your company's hiney if your building is flooded, get's hit by a tornado, gets burned to the ground, blown up by a nut, or anything else that would take out the important parts of the server room.

    Yep. But that doesn't negate the value of local virtualization for server-specific problems.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • The editorial is quite readable and sensible, but...

    I read the referenced article (actually just a quick skim read) and thought it was rather poor. Sure, we have to get things consistent, avoid overlicensing, not pay for and maintain a large collection of vastly underused servers. Does that really need that much more than 20 words to say?

    In my experience, there haven't been too many servers (so I suspect that virtualisation would not help much) - what I've seen has been people trying to introduce too many instances. That has usually been either because people don't understand security or because they don't realise that next year they will need to scale beyond the number of instances supported on a single server (usually because of both at once), although at least once it was because someone failed to consider renaming carefully enough and ruled it out.

    Consolidatipn should never need to be an objective: the right approach is to avoid ever getting into a situation where consolidation is needed. Of course there are exceptions - for example when two companies merge; but these ARE exceptions, they should not be thought of as the norm.

    Tom

  • Consolidate from our standpoint has resulted because of this situation. A handful of SQL Servers we had here that were underutilized for two different reasons. One was that the hardware is underutilized due to the fact that the software vendor had hardware requirements but they oversold what was needed. The other reason is that a specific SQL Server in say year 2003 hosted 12 databases, over time most of those databases either were upgraded to another release of SQL Server so they moved to another server running a different version of SQL Server or the databases simply were no longer needed and dropped. This leads to having several servers with a sprinkling of databases that can now be consolidated onto one instead of four physical servers.

  • In my experience, and from what I hear other people say of theirs, there has been a significant expansion in the number of SQL Server instances at many places. This naturally leads to a consolidation project.

    For me, a consolidation project has two tasks; consolidate the current servers and setup server evaluation and consolidation as a business as usual (BAU) process i.e. continuous or regular evaluation.

    Only when you have a BAU process covering the analysis for the need to consolidate will you achieve a continually satisfactory state.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • I'd say my answers today are pretty similar to what they were in 2009 when this article was originally posted.

    The main issue I see with consolidation of any type is that you have to know your business requirements, your performance requirements (minimum, average, and peak, particularly IOPS), what the current hardware can handle, and what the new setup will provide. Consolidating five systems that each use most of a 5 year old, 2 core, 2 hyperthread, 2Ghz CPU with 8GB of RAM and 6 15k 3.5" disks onto a new system with 8 modern 1.8 Ghz CPU's, 48GB of RAM and 6 10k 2.5" disks is just asking for IO performance issues (six 10k disks do NOT provide the performance of thirty 15k disks). If you replace the 10k 2.5" disks with SSD's, then unless you have a CPU edge case, you're likely to see better performance.

    The number one planning problem I see is taking N systems with M disks, and consolidating them into N/30 systems with N/15 disks of similar performance; suddenly, you're lacking the IOPS to run most of the loads at once... for instance, at the end of the month/quarter/year.

    If you need either very high minimum or very high maximum performance, then be wary of consolidation. If average performance is what's important, consider consolidation strongly; instance-based consolidation in particular saves on maintenance effort at the expense of everything going down at once for reboots.

    Note that VMWare ESX(i), at least, has quite reasonable resource management - you can assign minimums and maximums, set the number of "shares" for CPU, memory, and disk IO priority, and dedicate resources (dedicating some RAM and a certain amount of CPU is a means I've seen used to tune minimum performance).

Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic. Login to reply