September 2, 2015 at 10:51 pm
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 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.
September 3, 2015 at 6:03 pm
Have you considered simply adding the two new servers to the cluster first?
Then just install SQL/zone in storage/etc as if you're growing the cluster. When done, you can validate the cluster and fail the instances back and forth to be sure all is good.
Then, just evict the two old servers from the cluster when you're 100% sure everything works right.
It's not a matter of just shutting the old machines down. You can't just simply create a new cluster and clustered virtual names with the old still-existing names, unless you first remove those objects from Active Directory. Doing that pretty much means you will be down hard, with no way to go back, from the time you delete the Active Directory objects until after you finish installing, copying, and configuring the two new servers.
The plan you're asked to implement, as presented, is loaded with wholly-avoidable risk. By pulling you into this project to be "the DBA", late enough that you have no input, really just sets you up to eat the blame. Tread lightly.
The far, far, far better choice is for folks to step up and accept that a change of clusters means a change of connection strings. Then you can build that cluster and those instances properly, using unique identities in the domain. (I know you didn't specify that being the case for the non-safe approach, but it smells that way.)
-Eddie
Eddie Wuerch
MCM: SQL
September 8, 2015 at 4:09 am
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" 😉
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply