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»»

Standalone to Cluster Expand / Collapse
Author
Message
Posted Tuesday, June 10, 2014 1:14 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, June 12, 2014 8:26 AM
Points: 5, Visits: 12
So here is my situation ... we have a Production SQL 2008 R2 server that is serving up a number of databases right now ... my boss just purchased a second server and wants to cluster these two servers together. From what I have read, you cannot simply upgrade the standalone server to Cluster Mode. Is this correct?

Assuming that this is correct, how would you guys recommend I go about clustering these two servers with minimal downtime to the organization??

Thanks,
Nick
Post #1579378
Posted Tuesday, June 10, 2014 1:25 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 3:55 PM
Points: 256, Visits: 1,445
How much downtime is acceptable? How big are the databases? How similar is the hardware? What sort of storage are you working with?

As far as I know, you can't just "upgrade" an existing stand alone server to a cluster.
Post #1579387
Posted Tuesday, June 10, 2014 1:31 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, June 12, 2014 8:26 AM
Points: 5, Visits: 12
Servers are identical ... Prod box has a locally attached SSD array, Second server has locally attached SAS Array ... Total DB size is 220GB.

If I can get the down time to under 4 hours that would be great!!
Post #1579392
Posted Tuesday, June 10, 2014 1:47 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 3:55 PM
Points: 256, Visits: 1,445
You'll need shared storage for a 2008 cluster.

What types of failures are you trying to prevent with a windows cluster? Have you looked into using VMWare or Hypervisor for HA? I know not an exact replacement but it has some great advantages, and some disadvantages.
Post #1579401
Posted Tuesday, June 10, 2014 1:51 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 3:55 PM
Points: 256, Visits: 1,445
http://technet.microsoft.com/en-us/library/cc771404.aspx


Post #1579403
Posted Tuesday, June 10, 2014 3:10 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, June 12, 2014 8:26 AM
Points: 5, Visits: 12
I will be using Steeleye Datakeeper to do the clustering of SQL 2008 ... it does not require shared storage. See below.

http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-%E2%80%93-part-1/
Post #1579424
Posted Tuesday, June 10, 2014 3:43 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 3:55 PM
Points: 256, Visits: 1,445
ntrovato (6/10/2014)
I will be using Steeleye Datakeeper to do the clustering of SQL 2008 ... it does not require shared storage. See below.

http://clusteringformeremortals.com/2009/09/15/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-%E2%80%93-part-1/




That looks interesting. What's the advantage vs just using VMWare/Hypervisor?

They don't have any of their white papers open without registering.

I would be very wary about putting anything teir 1 on a solution without extensive documentation and wide field adoption. You're probably going to be locked in to the vendor for support if things go bad, make sure you get a support contract with a good sla.


Post #1579429
Posted Tuesday, June 10, 2014 7:53 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, June 12, 2014 8:26 AM
Points: 5, Visits: 12
Quite honestly, most of these decisions were already made before I started on this project ... so I'm pretty much stuck with this solution and I need to run with it.

How would you go about making this transition?? I was thinking of doing the following:

1.) Install Server 2008 and SQL 2008 in cluster mode on the second server
2.) Backup and restore the DB's from the PROD server and restore them onto the second server
3.) The rebuild the PROD server and add it to the exisiting cluster

Does that make sense?? How would I transfer the system databases over??
Post #1579455
Posted Wednesday, June 11, 2014 7:38 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Yesterday @ 8:25 AM
Points: 384, Visits: 1,265
ntrovato (6/10/2014)
Quite honestly, most of these decisions were already made before I started on this project ... so I'm pretty much stuck with this solution and I need to run with it.

How would you go about making this transition?? I was thinking of doing the following:

1.) Install Server 2008 and SQL 2008 in cluster mode on the second server
2.) Backup and restore the DB's from the PROD server and restore them onto the second server
3.) The rebuild the PROD server and add it to the exisiting cluster

Does that make sense?? How would I transfer the system databases over??


I've built several Clusters in my life. SQL 2000, SQL 2008, and most recently, SQL 2012. I never had any problems when the hardware and storage was properly sized by the SAN or IT team. When it was not, it was a real nightmare.

Let me share with you what I've learned from experience,

#1, measure your workload
Before start moving stuff. Measure your workload. You can use perf. mon for that. Measure CPU, RAM and I/O utilization. Also, if you can attach the new storage to a Windows server, measure I/O as well using SQLIO. This is critical! Because if your storage is not fast enough, you will have performance issues. I faced lot of problems with a SQL2012 Cluster because the storage was not properly sized. The Cluster started failing over unexpectedly and I could not even take SQL backups, that will trigger a failover too. It was a nightmare. The SQL Cluster was properly configured, but the SAN was not.

#2 use same hardware
MS clearly states that you should use identical hardware. Mixing hardware, like servers with different RAM or different CPU models will create issues. Long time ago I face a problem with a SQL 2008 Cluster that IT people built with different CPUs. It experienced random failovers and issues. It took a long time to discover and much more to migrate and fix. So, you are warned

#3
Use shared storage.
MS also is clear that using share storage is recommended. You are dealing with databases, so writing stuff to disk without corruption is key. Because the way SANs work, they ensure data corruption won't occur. Some cheap storage solutions like file storage and others, can be used, but they write information in a different way and were not designed for SQL clusters, so you may end with a slow Cluster or one that may corrupt your data. So use an MS endorsed array/SAN for your Cluster.

How to migrate? Well... you can build a one node Cluster and backup and restore your databases or even use Mirroring. Then you destroy the old hardware and join that server to the Windows Cluster. This is assuming you will re-purpose existing hardware. Otherwise, you can do the same and build the Cluster 1st and do a side by side migration.

Forget about master, model, etc. You can't move those. But you can script any T-SQL job you may have. Same goes for SQL logins.

Please Google or look here for step by step process of how to build one. It is complex so I can't explain it on a few lines in a simple post. But you need to assign IPs, setup a Domain account for the SQL server service, and much more. So be prepare to work with your network or IT team, you will need them for the initial setup and on going support.
Post #1579620
Posted Wednesday, June 11, 2014 10:21 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, June 12, 2014 8:26 AM
Points: 5, Visits: 12
Thanks for the advice ... your explanation in step 3 was exactly what I was thinking of doing. When you say ignore the Master, System database ... is this a recommended way to do that?? Should I be scripting that stuff over?
Post #1579723
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse