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 :-)
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.