codykonior (9/2/2015)
I've been included into the tail end of a plan to migrate a two node Windows Server 2008 / SQL Server 2008 R2 cluster.The plan:
* Create a new cluster on two new servers with the same instance names and mount points.
* Install SQL Server on both nodes.
* Shut down the original two nodes.
* Configure the virtual network names on the new cluster.
* Switch the disks between the old and new nodes.
* Start up SQL Server on the new cluster. It will operate with the old system and user databases and just work...
I'm always uncomfortable with just "switching the disks", this is generally borne from someone who doesn't understand how SQL server installs onto the server(s). In the interim it looks like it just works and sometimes it does, but there can be issues, not least if the install paths used are not exactly the same.
Are you planning to upgrade the node Operating system too?
A clean install and migration of the objects between the clusters allows you to keep both systems online, you just need to assign one of the clusters a temporary networkname and swap them between the clusters when ready to go live, it's easy and something I have done a lot and in fact quite recently.
codykonior (9/2/2015)
I did mention that this isn't standard practice, and it turns out that objection had been brought up previously, but the plan is going to go ahead anyway. So I've been thinking about what things I can do to try to aid in the process where it could go awry:* Confirming the new servers are on the exact same service pack level.
* Confirming the mount point names are exactly the same.
* Checking the port numbers. These are stored in the registry and the old cluster is stupidly using dynamic ports. I will grab the ones in use beforehand and set them on the new cluster as static ports.
* Backing up the service master key and the master database key from the old server, to restore on the new server when it starts up.
* Checking sys.server_principals for any machine-accounts or cluster service accounts that may have changed.
* I thought about sp_dropserver sp_addserver but these shouldn't be necessary as it's configured with the virtual name which won't change.
I was wondering if anyone else has any ideas of things I may have missed.
You don't need the SMK or the DMK, for the SMK just ensure you use the same network name and domain account for the SQL Server service.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉