December 10, 2016 at 4:20 pm
We have a 2 node AG that we need to move to a new SAN with [obviously] minimal downtime. Trying to figure out the best strategy for moving the databases with the lease amount of downtime while preserving the AG configuration. Has anyone done this? Does anyone have any suggestions/ideas/guidance for this?
The volumes for the new SAN will be presented to both nodes this week.
December 12, 2016 at 5:50 am
Hi!
The easiest way is to convert disks to dynamic and make RAID1 for each data array at windows OS level. When synchronization will complete you should delete old drives from windows RAID1.
December 13, 2016 at 5:03 pm
We are planning to migrate an existing AG (2-node AG cluster, no shared storage) to a new SAN, and want to keep the same drive letters, say F and G . Note that all databases, including the master, model and msdb are all on the same drive. The plan is as follows:
Present new volumes to each node - say M and T
Suspend data movement from the AG to the secondary
Turn SQL off on the secondary
Copy all data files to the new volumes
Rename the M drive to F and rename the T drive to G
Reboot the server
SQL should come up with no issues since the drive and folder structure is the same.
Resume data movement to the secondary.
Failover the cluster to the secondary (the node that just moved to the new san)
Repeat the same steps as above.
See any holes or pitfalls to this? There is no concern for transaction log bloat - - this will be done during a maintenance window, and is very low transaction.
December 14, 2016 at 9:02 am
shadow66 (12/13/2016)
We are planning to migrate an existing AG (2-node AG cluster, no shared storage)to a new SAN, and want to keep the same drive letters, say F and G . Note that all databases, including the master, model
and msdb are all on the same drive. The plan is as follows:
Fairly easy, I'm assuming the local storage on the 2 nodes is physically attached disks, correct?
shadow66 (12/13/2016)
Present new volumes to each node - say M and TSuspend data movement from the AG to the secondary
Turn SQL off on the secondary
Copy all data files to the new volumes
Rename the M drive to F and rename the T drive to G
Reboot the server
SQL should come up with no issues since the drive and folder structure is the same.
Resume data movement to the secondary.
Failover the cluster to the secondary (the node that just moved to the new san)
Repeat the same steps as above.
Sounds reasonable, just watch the time you take and the log growths on the primary. If it's a busy group and you expect a lot of downtime then best to remove the secondary first and reintroduce to the group at a later time
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
December 14, 2016 at 3:59 pm
Yes - both nodes have separate storage. Both will be migrated to the new SAN. Thanks!
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply