November 11, 2009 at 8:28 pm
Comments posted to this topic are about the item Consolidating Again and Again and Again
November 12, 2009 at 5:02 am
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?
November 12, 2009 at 7:04 am
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.
November 12, 2009 at 9:31 am
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.
November 12, 2009 at 9:40 am
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]
November 12, 2009 at 10:06 am
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.
November 12, 2009 at 10:16 am
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.
November 12, 2009 at 10:46 am
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
November 13, 2009 at 7:11 am
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
November 13, 2009 at 11:18 am
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
Change is inevitable... Change for the better is not.
November 16, 2009 at 7:22 am
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
January 20, 2010 at 8:28 pm
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
January 21, 2010 at 5:53 am
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.
November 25, 2014 at 2:11 am
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!!!
November 25, 2014 at 8:42 am
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