Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Consolidation of SQl2008R2 servers to SQL2012? Expand / Collapse
Author
Message
Posted Tuesday, December 17, 2013 1:35 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Today @ 9:32 AM
Points: 102, Visits: 1,077
Dear Friends,

We have 25 SQL Server 2008 servers in our company and my management asked to give proposal for consolidating all sql2008 servers into SQL server 2012 servers.

Please find the attachment for list of SQL servers and suggest me your inputs..like which is suitable for high availability like Failover cluster,Log shipping or Mirroring,etc.

Also provide me the choice to select consolidation type as VM or Multiple Instances in 1 or 2 machines or Multiple databases in a single machine for this type of environment.

Any link or pointers for proposal will be more helpful for me...

Any help will be much appreciated..



Regards,
Kumar


  Post Attachments 
SQL Severs.jpg (38 views, 151.47 KB)
Post #1523560
Posted Tuesday, December 17, 2013 5:25 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 3:26 AM
Points: 14,205, Visits: 28,536
I have to ask, how, possibly, from a listing of servers could I tell you which of the databases on those servers would need mirroring? How could I? Possibly? Further, if I told you which of those servers I think needs to have replication installed, would you really do it? Blindly? Surely I'm misunderstanding the question.

----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of:
SQL Server Query Performance Tuning
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #1523618
Posted Tuesday, December 17, 2013 5:34 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Today @ 9:32 AM
Points: 102, Visits: 1,077
Grant Fritchey (12/17/2013)
I have to ask, how, possibly, from a listing of servers could I tell you which of the databases on those servers would need mirroring?
I'm Collecting those information..
How could I? Possibly? Further, if I told you which of those servers I think needs to have replication installed, would you really do it? Blindly? Surely I'm misunderstanding the question.


Advice me to select consolidation type as VM or Multiple Instances in 1 or 2 machines or Multiple databases in a single machine for this type of environment based on the server list?


Regards,
Kumar
Post #1523628
Posted Tuesday, December 17, 2013 5:39 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 3:26 AM
Points: 14,205, Visits: 28,536
Honestly, I can't.

How much CPU does each of those servers use? If one is maxed out on memory, we probably don't want to put it into a VM, but from a list of servers.... I can't say anything. Which of the servers is IO bound? I don't know. Are any of them basically only using a very small percentage of resources? Then they can be easily consolidated.

But it goes further. Consolidation isn't about servers. It's about databases on servers. You're trying to eliminate the server from your list by moving all the databases onto another server. So we need to understand the loads and requirements of the databases on those servers. Are there any that legally can't share resources? I can't tell.

There's just no real way to provide what you want from the information you've put forward.


----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of:
SQL Server Query Performance Tuning
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #1523633
Posted Tuesday, December 17, 2013 5:44 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 3:05 AM
Points: 969, Visits: 694
OK, I'll bite.

You are looking for a technical solution when you do not have a proper business requirement, or do not fully understand the business requirement.

You mention consolidation. How do you plan to consolidate?
- more databases per instance
- more instances per server
- more guest VM's per physical host

Each of these could work, but without knowing the type of data, your business vector or the workload of any of these databases or servers then it is impossible for us to answer.
If you have PCI-DSS compliance needs for example then you'll probably need to implement TDE, implementing that will also encrypt TempDB which would slow down access to TempDB for those other databases on that instance.

On the other hand if you pay for third party tools for backups or monitoring the more databases per instance the more value for money you get from those products - assuming you have good security models.

In terms of HA/DR, what is the required uptime of each instance and what is your budget?
I could suggest that you have geo-clustered servers with SAN replication, that would provide you with great uptime and availability. I do not know if that would work for your business though.
Database Mirroring may work, but that is being deprecated moving forward, so Availability Groups would be a better choice. I would ask you to read all the info on Availability groups (I can just imagine Grant's face here) to make sure that this would work with your database's as there are a number of caveats.

Hope that helps,
Rich




Hope this helps,
Rich



Post #1523637
Posted Tuesday, December 17, 2013 5:45 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Today @ 9:32 AM
Points: 102, Visits: 1,077
Yes,,Thanks for the help..i will check the loads and requirements of the databases and inventory details on the servers.


Regards,
Kumar
Post #1523639
Posted Tuesday, December 17, 2013 5:47 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 3:05 AM
Points: 969, Visits: 694
No problem, in the meantime can I suggest that you patch all of your existing servers?
RTM isn't the way to go


Hope this helps,
Rich



Post #1523641
Posted Tuesday, December 17, 2013 5:54 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Today @ 9:32 AM
Points: 102, Visits: 1,077
Based on my understanding,Microsoft assessment and planning tool will help to get the load and all details for each and every server.Is it right?

Regards,
Kumar
Post #1523646
Posted Tuesday, December 17, 2013 6:15 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 3:05 AM
Points: 969, Visits: 694
Not to the level of information you require to ensure that all of your business cycles for all of your databases will be able to meet their SLA's.
Ideally you need to baseline each server individually and look at their resource usage to see which if any could play nicely together.
In your initial post you did not mention if you would be using new or existing hardware. If you are buying new hardware this job becomes easier as you can do things like stress test your IO prior to putting any real data on there. i.e. you won't have lots of users complaining whilst running tests.
You can also replay traces from production (assuming you have no compliance issues with that) from boxes you are thinking of consolidating on your new box and monitor the levels of performance.

I did a talk on baselining at the PASS Rally's in Stockholm and Amsterdam last month. Not sure if it's available online yet, but you can see the slides here http://www.slideshare.net/SQLRich/the-day-after-tomorrow-why-you-need-to-baseline-sql-rally-2013-amsterdam
One thing I will say is that the figures in red for counters are now pretty old and I make a point of saying that Moore's law makes a mockery of them. It does give you a starting point though.


Hope this helps,
Rich



Post #1523655
Posted Tuesday, December 17, 2013 6:27 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 3:26 AM
Points: 14,205, Visits: 28,536
KumarVelayutham (12/17/2013)
Based on my understanding,Microsoft assessment and planning tool will help to get the load and all details for each and every server.Is it right?


Not at all.

As Richard says, you'll need to establish a baseline. I'd suggest picking up a copy of the book Troubleshooting SQL Server. You can purchase a paper copy or download an e-book for free. It will give you a lot of information on how to gather metrics on the servers. From there you can start figuring out what kind of consolidations you might be able to do.

I'd strongly suggest that you tell your boss that you're WAY over your head on this one. Get a consultant in to help out. We're talking about a pretty major undertaking to gather all the metrics, evaluate them, make informed decisions based on the business needs and the technology needs and abilities, and then implement all of the above successfully. No offense intended, but you're not even maintaining patches on your servers, so I really don't think you're ready for this.

As a DBA, your primary job is to ensure the protection of the business's data. And sometimes, that means protecting it from yourself.


----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of:
SQL Server Query Performance Tuning
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #1523658
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse