This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.
Management Summary
A disaster exists if a primary side (Region) becomes entirely unavailable due to major outages. Within the region the system is protected by WSFC and redundancy measures from single points of failure.
In this example the focus is on the ASCS/ERS functionality. In another Azure region, a second SAP system is built, acting as for example a QAS system. This allows the virtual machines making up this system to be temporarily repurposed for the PRD DR system. This is a very cost-effective measure since there’re no idle machines. Both systems are installed with virtual hostnames. Following SAP Note 1564275, CNAMES should not be used to implement virtual hostnames. For the virtual machines acting as SAP application servers a second IP address needs to be added. This doesn’t apply to the WSFC ASCS cluster role. Here a CNAME is used. In a disaster the SAP system running on the DR site will be shut down. The DNS entries will be adjusted to reflect the virtual hostnames of the PRD system. For the ASCS cluster role the CNAME needs to be adjusted. Additionally, the entry for SAPGLOBALHOST in the DEFAULT.PFL profile needs to be changed from the PRD site to the DR site. To ensure the consistency of the DR system, OS patches and SAP configuration changes should be made at the same time they’re done on the PRD site. These are mainly changes to the file system level like profiles. Changes stored within the database are replicated through the database. This measure preserves all the DNS names used in the SAP PRD system thus avoiding the need for adjustments within the SAP system. Printer definitions, logon groups, external interfaces etc. will work immediately after the system is online.
This solution supports all Windows based application server scenarios. The underlying database can of course be an SAP HANA database, Microsoft SQL Server or any other SAP certified database which supports data replication.
The same scenario could also be used for Windows based scenarios using ANF.
The clustered Enqueue Replication Server can only be installed for SAP HANA based system which are installed using SWPM2. For installations based on SWPM1 the cluster functionality can be retrofitted according to SAP Note 263928. You must be careful because after the ERS2 conversion was done, the current version of SWPM1 version doesn’t allow for additional application server installations.
Prerequisites
For the DR site to be consistent apply OS patches and changes to the SAP system configuration at the same time to both sites. Make sure that the SAP kernel repository is in sync on both SAPGLOBALHOST (robocopy). This also applies to any other information you want to preserve like SAP job logs. Changes stored within the DB will be taken care of by system replication.
Perform a standard SAP installation based on the High Availability scenario. For the Windows Failover Cluster installation use FSC (File Share Cluster) based on High availability for SAP NetWeaver on Azure VMs on Windows with Azure Files Premium SMB for SAP applications
Installing the PRD (East) system and QAS (West) systems result in the following DNS/HOST file entries.
These are the DNS/hosts file entries during normal operation.
The 10.19.x.x VNET is the production site.
VM IP address Alias/CNAME
mswinnode43 10.19.0.52 #VM cluster node 1
mswinnode44 10.19.0.53 #VM cluster node 2
ts6ascseast 10.19.0.54 ts6ascs
ts6erseast 10.19.0.55
mswinapp01 10.19.0.56 #Application server 1
mswinapp02 10.19.0.57 #Application server 2
mswinapp03 10.19.0.58 #Application server 3
mswinapp04 10.19.0.59 #Application server 4
mswinapp05 10.19.0.60 #Application server 5
ts6app01 10.19.0.71 #Virt. hostname 1 second IP address for 10.19.0.56
ts6app02 10.19.0.72 #Virt. hostname 2 second IP address for 10.19.0.57
ts6app03 10.19.0.73 #Virt. hostname 3 second IP address for 10.19.0.58
ts6app04 10.19.0.74 #Virt. hostname 4 second IP address for 10.19.0.59
ts6app05 10.19.0.75 #Virt. hostname 5 second IP address for 10.19.0.60
The 10.20.x.x VNET is the DR site.
ts6ascswest 10.20.0.40 #CNAME ts6asc must be activated here in case of DR.
ts6erswest 10.20.0.41
mswinnode53 10.20.0.52 #VM cluster node 1
mswinnode54 10.20.0.53 #VM cluster node 2
ts7ascswest 10.20.0.54 ts7ascs
ts7erswest 10.20.0.55
mswinapp61 10.20.0.101 #Application server 1
mswinapp62 10.20.0.102 #Application server 2
mswinapp63 10.20.0.103 #Application server 3
mswinapp64 10.20.0.104 #Application server 4
mswinapp65 10.20.0.105 #Application server 5
ts7app01 10.20.0.111 #Virt. hostname 1 second IP address for10.20.0.101
ts7app02 10.20.0.112 #Virt. hostname 1 second IP address for10.20.0.102
ts7app03 10.20.0.113 #Virt. hostname 1 second IP address for10.20.0.103
ts7app04 10.20.0.114 #Virt. hostname 1 second IP address for10.20.0.104
ts7app05 10.20.0.115 #Virt. hostname 1 second IP address for10.20.0.105
ts6app01 10.20.0.121 #Placwholder entry for speedy address change
ts6app02 10.20.0.122 #Placwholder entry for speedy address change
ts6app03 10.20.0.123 #Placwholder entry for speedy address change
ts6app04 10.20.0.124 #Placwholder entry for speedy address change
ts6app05 10.20.0.125 #Placwholder entry for speedy address change
Activating DR scenario
DNS/host file entries during active DR scenario.
The 10.19.x.x VNET is the production site.
VM IP address Alias/CNAME
mswinnode43 10.19.0.52 #VM cluster node 1
mswinnode44 10.19.0.53 #VM cluster node 2
ts6ascseast 10.19.0.54
ts6erseast 10.19.0.55
mswinapp01 10.19.0.56 #Application server 1
mswinapp02 10.19.0.57 #Application server 2
mswinapp03 10.19.0.58 #Application server 3
mswinapp04 10.19.0.59 #Application server 4
mswinapp05 10.19.0.60 #Application server 5
ts6app01 10.19.0.71 #Virt. hostname 1 second IP address for 10.19.0.56
ts6app02 10.19.0.72 #Virt. hostname 2 second IP address for 10.19.0.57
ts6app03 10.19.0.73 #Virt. hostname 3 second IP address for 10.19.0.58
ts6app04 10.19.0.74 #Virt. hostname 4 second IP address for 10.19.0.59
ts6app05 10.19.0.75 #Virt. hostname 5 second IP address for 10.19.0.60
The 10.20.x.x VNET is the DR site.
ts6ascswest 10.20.0.40 #CNAME ts6asc must be activated here in case of DR.
ts6erswest 10.20.0.41 ts6ascs
mswinnode53 10.20.0.52 #VM cluster node 1
mswinnode54 10.20.0.53 #VM cluster node 2
ts7ascswest 10.20.0.54
ts7erswest 10.20.0.55
mswinapp61 10.20.0.101 #Application server 1
mswinapp62 10.20.0.102 #Application server 2
mswinapp63 10.20.0.103 #Application server 3
mswinapp64 10.20.0.104 #Application server 4
mswinapp65 10.20.0.105 #Application server 5
ts6app01 10.20.0.111 #Virt. hostname 1 second IP address for10.20.0.101
ts6app02 10.20.0.112 #Virt. hostname 1 second IP address for10.20.0.102
ts6app03 10.20.0.113 #Virt. hostname 1 second IP address for10.20.0.103
ts6app04 10.20.0.114 #Virt. hostname 1 second IP address for10.20.0.104
ts6app05 10.20.0.115 #Virt. hostname 1 second IP address for10.20.0.105
- Shutdown QAS SAP TS7 system on DR site
Stop application servers and the 2 cluster roles. - Making DNS changes
Replace the CNAME of the PRD ASCS cluster role with ts6ascs. Change the DNS/host file entries from ts7appxx to ts6appxx by switching the ts6appxx addresses to 10.20.0.111 – 10.20.0.115. Delete 10.20.0.121 – to 10.20.0.124 entries. - SAPGLOBALHOST change.
Verify that the SAPGLOBALHOST entry in the DEFAULT.PFL points to the DR site (ts6ascswest). - Make sure that SAPDBHOST points to the replicated database on the DR site.
- Use robocopy (ideally already scheduled to run on a regular base) to copy the desired files (SAP kernel repository, Job logs etc.) from ts6smbeast.file.core.windows.net to ts6smbwest.file.core.windows.net.
The following command is an example for copying the SAP job logs.
Robocopy \\ts6smbeast.file.core.windows.net\sapmnt\TS6\sys\global \\ts6smbwest.file.core.windows.net\sapmnt\TS6\sys\global /s /e /mir
A full documentation of the robocopy command can be found here robocopy | Microsoft Learn. - ILBs
Due to the unique cluster roles, no changes to any ILB are required. - Start SAP PRD on the DR site.
Since the system uses the same hostnames used on the primary site, all SAP system specific settings remain intact. No configuration changes to logon groups, printer definitions, interfaces etc. are required.
Failback
- Stop PRD TS6 on DR site.
- Make sure DB is synced to primary site (East)
- Copy log files etc. back from ts6smbwest.file.core.windows.net to ts6smbeast.file.core.windows.net.
- Reverse DNS/host file entries back to pre-failover settings.
- Start PRD on primary site (East).
- Start QAS on DR site (West).
Appendix
Assign multiple IP addresses to virtual machines using the Azure portal