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?
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It only takes a minute to sign up.Sign up to join this community
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:
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).
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.
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.
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.
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.