Migration of SharePoint cluster with SQL DB

Hello Avinash,

Always-On Availability Groups

When protecting Always-On Availability Group based clusters only the IP address is shared between the cluster nodes. It is
therefore possible to protect a single or both nodes with Zerto simultaneously.
Zerto recommends that all nodes are protected together within a single VPG to ensure the entire availability group can be
recovered in sync.

Post Failover Configuration

The biggest consideration here is once again the re-IP aspect, should it be required. As mentioned in the MSSQL Failover cluster
section, Zerto can automatically change the IP address of VMs as part of a failover or failover test operation. That being said, the
Always-On Availability Group itself will need some changes too. While this could be scripted using a post recovery failover script, it is
recommended to perform any re-IP of MSSQL Always On nodes manually post failover to reduce complexity.
It is also recommended for an MSSQL Always-On Availability Group to have listeners pre-configured on both the source and target
IP ranges too, so that again, only a simple DNS update to the new listener IP is required as part of a failover operation. If IP changes
are required, this can easily be tested as part of a failover test operation as covered later in this guide.
Failover Testing

To successfully perform a non-disruptive failover test of an Microsoft SQL virtual machine configured in one of the above high
availability configurations, Active Directory and DNS services are required to be online in the failover test isolated network.
Therefore, Zerto recommends protecting an Active Directory Domain Controller, configured as a global catalog and the primary or
secondary DNS server for the SQL Server virtual machine. Zerto is used to bring an up-to-date copy of Active Directory online with
ease for Failover Testing.

The Active Directory virtual machine should never be recovered to previous points in time in a production/live failover. Therefore,
Zerto recommends placing the Active Directory virtual machine in its own VPG and assigning both failover and failover test Network
Adapters in the virtual machine to connect to an isolated test network. Zerto recommends adhering Microsoft best practices for
Active Directory for production/live failovers.

Note: When booting Active Directory in an isolated test network, a minimum five-minute window is required for Active Directory
services to come fully online to allow the cluster services to start.

Outside of that we don’t have any other specific recommendations for protecting AAG SQL clusters or SharePoint other than our SQL best practices guide and our KB around protecting on MSCS both linked below:

http://s3.amazonaws.com/zertodownload_docs/Latest/SQLBestPractices.pdf

https://www.zrto-dev.com/myzerto/knowledge-base/best-practices-when-protecting-virtual-machines-running-mscs/

We do not update the cluster or listener IP address.  Are you speaking about the tempdb volume for SQL – if you are then you will want to set that volume to Temp Data.

Does anyone have all the steps required needed to fail over a windows cluster and a SQL AAG and its components?

These are the three items I need changed and need help with powershell and change the first three octets to match the failover network, then restart the various cluster components as they are changed.

PS C:\Windows\system32> Get-ClusterResource | Where { $_.ResourceType -eq “IP Address” } | Get-ClusterParameter -Name “Address” | Select ClusterObject, Value

ClusterObject                                   Value

————-            —–

Cluster IP Address                           10.x.x.3

SQL-PRD_10.x.x.xx            10.x.x.4

SQLPRD-PRD_10.x.x.x        10.x.x.5

Or like this if easier?

PS C:\Windows\system32> (Get-ClusterResource “Cluster IP Address” | Get-ClusterParameter)

Object             Name                  Value                                Type

——             —-                  —–                                —-

Cluster IP Address Network               79a28ce8-a4c9-4cc2-9b5c-54136a823ff4 String

Cluster IP Address Address               10.x.x.3                           String