March 30, 2009 at 9:10 pm
Hello to all 🙂
I have a project that i am going to present in a couple of days and i wanted to have the SQL gurus of SSC give me a few pointers if possible. I will say thanks many times (thanks X 1000) now to all that contribute any time reading or responding. All number are approximates but you will get the idea hopefully.
In my environment i have approx 150 servers (over 2500 databases )... with the break down looking like this SQL 7 5 servers....SQL 2000 115 servers....SQL 2005 30 servers. Now i need to consolidate this to save money for the company and not exactly sure of whats the best route. I have plenty of ideas but not sure which way to go. My first thought is this... Dont focus any attention on the SQL 7 servers ..leave those alone for "legacy systems" any client that wants them are pretty much on their own. As for the other i was thinking of going with a few clusters maybe 10 servers (5 clusters) and using some nice DL580 machines with 32 GB RAM, 3 TB hdd with Enterprise Edition(EE) across the board for OS and SQL. Now this will decrease the number of servers supported but increase the likelihood of other problems. This is where i need some assistance as i have not done this before and wonder what to prepare for 🙂 🙂 (besides getting the blame if problems occur). I have overly simplified this and hopefully you get the idea as i dont want to write a book trying to explain.
Any thoughts ..suggestions.. or ideas would be greatly appreciated..
Thanks again
DHeath
DHeath
March 31, 2009 at 1:03 am
Hello DHeath,
Looks like challenging and time consuming process. If I understand it correctly you are planning a few 1 or two powerful server with SAN storage to remove or reduce the hardware cost.
And if your answer is yes you might think about the virtualization.
1. As a first step to start you need to calculate the Hardware requirement like CPU, RAM, Storage etc. Your hardware vendor can also help you to achieve this.
2. Next step is to one by one you need to upgrade the database and check the compatibility with higher version which is more time consuming and tedious.
Note: DB upgrade include all DTS, users, stored procedures, Business rules, triggers etc.
HTH
Cheers!
---------------------------------------------------
"Thare are only 10 types of people in the world:
Those who understand binary, and those who don't."
March 31, 2009 at 7:35 am
Thanks for the reply and i do understand the fact that i will be checking and migrating all the components as well. To answer your first question that would be a yes ...trying to reduce hardware costs. My concerns are things like this which i dont have any experience with but only the thought process answers... If i place 200 databases on one server...(yes SQL can handle that easily and much much more) but does that cause problems with backups. I dont have any servers that have over 150 databases(this structure was inherited) so i see lots of places to consolidate the servers. Is this just an idea and you go for it kind of situation or has anyone seen and good white papers or anything on it. I like to get some research to better my knowledge before moving forward if possible.
Thanks Again,
DHeath
DHeath
March 31, 2009 at 8:02 am
Hi Dheath,
We are approximately 90% through a SQL Server consolidation programme albeit on a much smaller scale. The main business driver for this work was reducing hardware costs and we've certainly done that by using VMware ESX. Now I know there have been plenty of threads and articles discussing the pros and cons of 'virtualisation' but for us it has worked out really well. You may wish to investigate this possible environment further?
My concerns are things like this which i dont have any experience with but only the thought process answers... If i place 200 databases on one server...(yes SQL can handle that easily and much much more) but does that cause problems with backups.
Ever heard of 'Proof of concept'? It very much depends upon how big these databases are?
As free_mascot has already mention you will need to perform a Hardware requirement needs analysis. How critical are these db's? Do they require 24x7x365 uptime? This may influence the type of SQL environment you create. Do you require Dev/Test SQL environemnts?
So many questions to ask...
I'll try and find some links for you to aid your research.
Cheers,
Mark
April 1, 2009 at 6:49 am
What are you guys using for Shared storage as part of your POC? I wanted to get some thoughts from some folks around using iSCSI as shared storage in setting up a SQL Server cluster? I work for a company that produces iSCSI Target software (full disclosure), would love to hear your thoughts around iSCSI as a lower cost to using FC SAN.
Thanks
Bob
April 1, 2009 at 7:02 am
Hi Bob,
Sorry, can't really help you there as our SAN storage is FC based (even for POC!)
April 1, 2009 at 7:24 am
Thanks a ton for the replys....all is appreciated. The systems will be 24x7x365 and to some extent when i consolidate i will set some overall ground rules as to downtimes and the likes so that i can keep the maintenance to a minimum but updated. As for storage i will hopefully run this on a SAN so that we can add with ease if needed. I guess mostly its a situation of having the responsibility of everything going into one area and a trying to educate yourself to do this in a perfect manner. More than likely there will be bumps and bruises just trying to minimize them.
Thanks to everyone that has read or replied..Always appreciated.
DHeath
DHeath
April 1, 2009 at 8:06 am
Oh great 😛 Thanks all :w00t:
[font="Comic Sans MS"]+++BLADE+++[/font]:cool:
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply