1

What are the steps required to move AAGs (version=SQL 2012 and OS=Windows 2012 R2 O) to new SAN within same data center?

It is a virtualized environment.

Instead of building new servers - can the VM and storage be v-motioned to new storage?

Improve this question
3
  • 1
    Is this a virtualized or physical environment?
    – alroc
    Commented Dec 12, 2017 at 22:01
  • virtualized environment.
    – IMADBA
    Commented Dec 13, 2017 at 16:17
  • 2
    If you're using VMWare then yes, you can vMotion the storage to the new SAN with no downtime.
    – alroc
    Commented Dec 13, 2017 at 16:50

3 Answers 3

Reset to default
1

Because you are working with Virtual Environments, you can just do a storage migration. This will probably cause some performance problems so I would do the following:

  1. Set the Secondary to be async
  2. Use VMWare to migrate the storage to the new SAN
  3. Put the secondary back to synchronous commit
  4. Failover to secondary
  5. Repeat for next server

I am aware that it takes longer to migrate storage when the VM is running. It may be quicker to shutdown the Secondary, then move the storage, then start it back up again, failover and then do the other server.

There is no need to remove servers from the Availability Group. AAG's are designed to be able to shutdown a node for a period of time.

If you shutdown or change to async, you'll need to make sure there is enough storage space to keep the transaction log until the server is running at full speed again (or comes back online if you shutdown).

Improve this answer
2

Method 4

Depending on the size (and contents) of the data store, if you connect your new SAN to your VMWare infrastructure, you can storage vMotion in addition to moving the guest itself.

If you have large databases in the Availability Group, I'd recommend a modification of Tony Hinkle's answer under Method 1.

  1. Remove secondary replica (call it "B") from the AG
  2. Stop the "B" guest
  3. Storage vMotion "B"'s data store to the new SAN
  4. Bring "B" guest online
  5. Rejoin "B" to Availability Group
  6. Manually failover the Availability Group to "B"
  7. Remove the secondary (former primary, call it "A") from Availability Group
  8. Stop the "A" guest
  9. Storage vMotion "A"'s data store to the new SAN
  10. Bring "A" guest online.
  11. Rejoin "A" to Availability Group
  12. Test with a failover to "A"

Note that depending on how long this takes, you may have to apply any log backups (WITH NORECOVERY, remember) taken during the storage vMotion process on the primary (either time) as part of steps 5 and 11.

Improve this answer
2
  • I don't know why you need to remove/add the replica to the availability group. You can do this live with some latency (make the server moving the secondary and make the replication Async so you don't affect live). Once it's moved, switch back to Sync, failover and move the next server. If you are going to kick it out of the Availability Group and readd it, you might as well just build a new server
    – Greg
    Commented Dec 13, 2017 at 23:10
  • 1
    That's certainly true. If you make the synchronization async then you run the risk of data loss. If you keep synchronization sync, then you run the risk of blowing out the log. I've done this exact process quite a few times and many times I've not been able to switch back to sync for a variety of reasons. I was just trying to give the "safest" answer and not necessarily the "fastest" answer with the least amount of effort.
    – swasheck
    Commented Dec 13, 2017 at 23:13
0

Method 1

  1. Remove a secondary replica from the AG
  2. On this secondary that is no longer a secondary, replace the database and log volumes on the old SAN with volumes on the new SAN. Lots of things to consider here--files that aren't part of the replicated databases will need to be restored or copied from the old volume. If SQL Server is using those volumes for databases, error logs, etc., you'll have to stop SQL Server while this is done.
  3. Add this secondary back to the AG replicas. You may want to do a manual restore and sync if the databases are large.
  4. Fail over to the secondary that is on the new SAN, and repeat this process until all of the servers are on the new SAN

Method 2
Build new servers with volumes on the new SAN, and add them to the cluster / AG. Once they are synched up, fail over to one of the new servers and remove the old servers.

Method 3
Stop SQL Server on a secondary, swap the drives and copy the .mdf, .ndf, .ldf files from the old volumes, and then start SQL Server. Fail over to this server, then repeat the process on the other server(s). Again, there are lots of details to consider with this approach.

Improve this answer
2
  • Is there an option 4 where VMs and storage can be v-motioned to the new storage ?
    – IMADBA
    Commented Dec 13, 2017 at 16:21
  • I don't know VMware capabilities well enough to answer that, but in general, method 4 would be to mirror the data at the vm host or hardware layer, and then switch it out. It may depend on your version and edition of VMware, your storage, etc.
    – Tony Hinkle
    Commented Dec 13, 2017 at 16:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.