- This topic has 1 reply, 2 voices, and was last updated October 4, 2019 by Aaron S.
Migration of SharePoint cluster with SQL DB
Avinash SOctober 4, 2019 04:31:01 PM
I need to migrate Microsoft SharePoint cluster which has its database on MS SQL (AAG cluster) from one VMware vSphere6.5 environment to other.
Are there any specific steps, guide or best practices involved around it specially in terms of below queries—
- Can Zerto update the AAG SQL’s Cluster IP and Listener IP as well? If not, how to deal with this?
- How to deal with “temp data” w.r.t. DB
- Is there any specific guideline/steps/best practices around SharePoint replication and migration? I was going through “Protecting Microsoft SQL Server with Zerto” by Zerto but it does not talk about AAG cluster’s requirements like Cluster IP and Listener IP configuration. Also, it is not specific to SharePoint.
Please help.Aaron SOctober 4, 2019 09:40:11 PM
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.
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:
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.