Introduction: This blog explains a reference architecture of a High available SAP system in Windows in Azure Cloud  with DR solution. This is one of the recommended architectures from Microsoft & SAP in Windows in Azure cloud where we will be utilizing Windows DFS-N to support flexible SAP shared file systems.

We will be referring shared file system as below, but same architecture can also be followed in case we have any other shared file system (e.g Interfaces which we would like to have in both regions):

1. \<ANF or AFS name >sapmnt
2. \<ANF or AFS name >trans

Scenario: We can refer this in below scenario:

• Implementation of SAP systems in High available scenario
• Configuring SAP Disaster Recovery Solution
• Operating System will be Windows
• Azure Site Recovery (ASR) is used for creating Application VMs in DR Region

Benefits:

• Significant reduction of RTO during Disaster
• Controlling number of characters on hostname which has limitations (Refer SAP NOTE: 611361,2718300)

Motivation:  

Here is a high level architecture (See Fig 1):

• ASCS, ERS, PAS and AS are part of Application Subnet which will access their sapmnt or trans directory configured in AFS or ANF which is accessible in that region.
• AFS or ANF has been provisioned with their physical name as result of that all the profiles, registry, Configtools parameters, interfaces will point to that physical name.
• Database subnets are not shown below as they used local FS ( e.g /hana/data, /hana/log) and async mode replication is configured between primary and secondary region.

Fig 1

Now during Disaster, as per recommendation from Microsoft Azure, ASR will be used to provision VMs in secondary DR region as below (Check Fig 2):

Fig 2

Now, here it comes the difficulties as with ASR , all details of registry values, profiles, configtool  parameters of region1 has come to region2. Basis team will need significant amount of time to change this and aligned as per Region2. Also when we need to fail back again to Region1, that time also we need to change those details as per Region1.

Hence, instead of using direct AFS or ANF physical name its strongly advised to use windows DFS-N which will support the naming convention of all these File shares(Check Fig 3).

                                                                   Fig 3

And During Disaster, here is what can be achieved as target architecture ( Fig4):

Fig 4

With this, we can achieve significant reduction of RTO and completely reduce entire steps of changing registry values, profiles or configtool parameters which will help Basis team. During failback to Region1 also, same can be followed without any manual intervention.

NOTE: We still need to perform few parameters changes ( e.g ASCS, DB load balancers in default profiles).

High Level Technical Steps:

Here is the high level steps I tried to update :

• Install and Configure DFS-N for /sapmnt and /trans shared FS which should point as per above diagram( Please refer : https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/dfs-overview)
• Make sure newly DFS are pointing correctly from all the Azure Application Subnet VMs.
• Install SAP HA system with File share Cluster mentioning DFS-N names.
• Check window registry , profile parameters. Now all should point to DFS-N names and should not point to any physical AFS/ANF names.

NOTE: In case , SAP is already installed and we need to change from physical name to DFS-N names , then we need to change registry , profiles and configtool parameters manually which will be one time activity.