How to move exisiting production Availability Group to new SAN

  • 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.

  • 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.

  • 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.

  • 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 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.

    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" 😉

  • 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