August 1, 2011 at 2:37 pm
I need to migrate a SQL2008R2 instance from a non-clustered, virtual environment to a physical cluster on a new SAN, while trying to retain the network name and IP address. I'm trying to come up with the best method that is "safe" and involves the least amount of downtime. Below are the options I've come up with so far. I'd appreciate your thoughts/ideas/experiences.
Option 1 - SAN Copy:
Stop existing Instance1
Remove Instance1 from the network
Install new Instance1 on cluster
Stop new Instance1
Restart old Instance1
Begin SAN copy of all mount points from old Instance1 to new Instance1 (including system databases)
At predetermined time, stop old Instance1
Final SAN copy delta
Start new Instance1
Pros:
If it works, most comprehensive plan, straightforward
Concerns:
SAN copy includes volume information which will be different that original disks presented to new cluster. This should be transparent to SQL Server, but OS/Cluster manager may balk?
Any problems overwriting clustered system databases with non-clustered master?
Option 2 - Robocopy/Restore:
Detach user databases on Instance1
Stop existing Instance1
Remove Instance1 from the network
Install new Instance1 on cluster
Stop new Instance1
Copy old Instance1 system database files to new Instance1
Restart old Instance1
Attach user databases
At predetermined time, backup user databases on old Instance1, copy to new Instance1
Stop old Instance1
Start new Instance1
Restore user databases
Pros:
Eliminates concerns regarding SAN copy
Since backups are compressed, faster than copying datafiles themselves
Concerns:
Same concern about system databases
Option 3 - Rename:
Install Instance2
Script all logins, linked servers, jobs, operators, etc on Instance1
Recreate logins, linked servers, jobs, operators, etc on Instance2
Mirror user databases from Instance1 to Instance2
At predetermined time, stop mirroring
Bring user databases online on Instance2
Stop Instance1 and remove from network
Stop Instance2
Rename Instance2 to Instance1
Restart new Instance1
Pros:
Seems "safe" if somewhat inelegant.
Concerns:
No real concerns, other than missing objects that need to be scripted/recreated.
Option 4 - ?
I'm open to suggestions.
Thank you.
August 1, 2011 at 9:07 pm
I'd go for Option 4..
Install Instance2
Script all logins, linked servers, jobs, operators, etc on Instance1
Recreate logins, linked servers, jobs, operators, etc on Instance2
Backup and restore (with no-recovery) databases from Instance1 to Instance2
Aplly the tran logs to keep in sync.
At predetermined time stop activity on instance1
Apply the last tran log with recovery and bring user databases online on Instance2
Stop Instance1 - Power down, you don't need to remove from network - THis is your fall back plan.
Create a DNS with the Instance1 Name, pointing to Instance2
The beauty of this is testing is easy and you have a good rollback option and has the lowest risk all round.
Don't do things like renameing the server. Although this can be done, it is fraught with risks and not for the faint of heart, particulalry since this is a cluster.
So you know where I'm comming from, this type of work is our bread and butter in the company I'm working for. In the past years we have done multiple cluster installs and migrations from old to new environments, often with an upgrade thrown in just for fun. I've never had an issue using Option 4 except where an ugly application used hard coded IP addresses or some other equally nasty way to connect to the server.
I have however had issues with renaming servers, and trying to have two servers with the same name in the environment at the same time doesn't work. You either need to restrict the time you can work to times when the one can be removed so the other one can be added, or you need to put the new server in it's own domain. Either way there are risks with IP addresses etc.
Keep it simple 🙂
Cheers
Leo
Leo
Nothing in life is ever so complicated that with a little work it can't be made more complicated.
August 2, 2011 at 11:58 am
Thanks for your input Leo. So, basically, you'd recommend Option 3, with log shipping rather than mirroring, and without the final step of renaming the instance? We'd really like to retain the instance name. I found this page, which makes it seem pretty straightforward. Perhaps deceptively so?
edit:I should make it clear that this is a default instance.
August 2, 2011 at 2:00 pm
I would definitely test this before I did it for live. If you follow Option 3 with the log shipping you can change the server name to something other than your current live server as a test. I'd be interested to hear if you have any issues.
Leo
Leo
Nothing in life is ever so complicated that with a little work it can't be made more complicated.
August 2, 2011 at 2:50 pm
Another advantage to either option 3 or 4 is that you can test the whole process up to either renaming SQL Server or creating a DNS record to point the old name to the new IP address.
If you are not installing a default instance into the cluster, you won't be able to rename the SQL Server instance so it will work.
I prefer Option 4 - because it is simpler and we can make sure new server names follow the latest naming standards if they have changed.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
August 19, 2011 at 7:54 am
I just wanted to post a followup to this for anyone looking to do the same thing. I went with the log shipping option and did the rename and everything went perfectly.
From start to finish:
Start with ServerA, standalone SQL 2008 R2 instance on a virtual server.
Build ServerB, clustered SQL 2008 R2 instance
Configure log shipping from ServerA to ServerB
Script all logins, linked servers, jobs, proxies, credentials, etc from ServerA and recreate on ServerB
At predetermined cutover time, perform last transaction log backup on ServerA
Run the copy and restore log jobs on ServerB, confirm the last log was restored
On ServerB, Restore database WITH RECOVERY to bring it online
Shut down ServerA
Remove ServerA from Active Directory
Rename ServerB's Network Name to ServerA
Test failover to remaining cluster node(s)
Update DNS with IP address of new ServerA
Thanks everyone for your input. Hope this helps someone else.
Colleen
August 22, 2011 at 4:03 am
Colleen M. Morrow (8/1/2011)
Any problems overwriting clustered system databases with non-clustered master?
never tried it but cant see why it wouldnt work. Most of the cluster info is held in the registry and replicated between nodes. I'll test it if i get time
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply