Migration of Always On Availability Group from old to new SAN within same data center

Question

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?

Answer 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).

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.

Answer 3

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.