How to choose correct Availability Zones for SAP Application cross-zone deployment

This article is contributed. See the original author and article here.

In Azure, availability zones are physically separate locations within an Azure region. Each availability zone is made up of one or more datacenters equipped with independent power, cooling, and networking. So, deploying virtual machines across availability zones along with high-availability framework can provide you the best SLA in Azure. But as the Azure regions developed and extended rapidly over the last years, the topology of the different Azure regions, number of physical datacenters, distance among those datacenters, and the distance between Azure availability zones may be different. That means, network latency may vary between availability zones.

 

With that in mind, choosing the correct zones for SAP Application in cross availability zone deployment is important. This article is focused on addressing this concern where we will discuss on methods to identify the network latency between zones, and brainstorm different options to deploy SAP system across Azure availability zones.

 

Step 1: Identify Network Latency across Availability Zones

 

An Azure region, which offers availability zones has a minimum of three separate zones to ensure resiliency. The availability zone identifiers (Zone 1, Zone 2, and Zone 3) are logically mapped to the actual physical zones for each subscription independently. That means, availability zone 1 in one subscription can refer to a different physical zone than availability zone 1 in a different subscription. So, the network latency between Zone 1 and Zone 2 can be different between different subscriptions used in the same Azure region. Therefore, it is recommended not to rely on availability zone IDs across different subscriptions for virtual machine placement within one Azure region.

 

To identify the network latency and throughput across availability zones within a region, provision a virtual machine in each availability zone with accelerated networking enabled. Run network measurement tools (like qperf, niping) to test latency and throughput between availability zones. The result will help you identify the availability zones which have the lowest latency and highest throughput. To simplify this task, one of our colleague Philipp Leitenbauer has developed a script which automates this entire scenario. You can find the script on GitHub.

 

Below is the output of the script for Subscription 1 on “eastus” region. It indicates zone 1 <> zone 3 offers lowest latency for Subscription 1. As mentioned earlier, availability zone identifiers are logically mapped to the actual physical zones for each subscription, which means the lowest network latency that is show below between zone 1 <> zone 3 for subscription 1, may not be the same for my other subscriptions. So, if you are planning to deploy SAP systems in multiple subscriptions, it is essential that you follow the guidelines mentioned in this article to identify the best zones for each subscription.

 

 

Alongside identifying the network latency across availability zones, you need to measure the network latency between two virtual machines within zones. You can refer Test VM network latency article which describe method to perform the test. It is important to get this insight as it helps to understand the delta between network latency within zones and cross zone latency.

 

Step 2: Different options for SAP deployment across Availability Zones

 

The distance between availability zones in the different region can be different and with that network latency across AZs as well. One SAP deployment strategy fit all regions cannot be implied, when brainstorming SAP implementation in multiple regions. Based on the network latency across AZs, different architecture strategies may need to be adopted for cross-zone deployment. You can either have active/active deployment where the delta between network latency within zones and cross-zone latency is not too large, or active/passive deployment where cross-zone network latency is high.

 

Scenario 1: Active/Active Deployment

 

In this deployment where cross-zone network latency is low, you can deploy and run SAP application servers across different zones as the network latency from one zone to active database virtual machine is acceptable for SAP business processes. The SAP Central Service instances that uses enqueue replication, and the database instances that performs replication will be distributed across two availability zones. The delta in runtime of business process or batch jobs for the in-zone and cross-zone workload should not be too large. The architecture for this type of active/active deployment between two zones could look like below –

 

 

The idea to deploy dormant dialog instance in each availability zones can help business to run system with former resource capacity, when the zone that runs part of SAP application instances becomes unavailable due to zone failure.

 

IMPORTANT: In active/active scenario, there is extensive data transfer between SAP application server (zone 2) and database (zone 1) which can result in higher bandwidth cost. Check Bandwidth Pricing Details for more information.

 

Scenario 2: Active/Passive Deployment

 

This deployment can be leveraged when cross-zone network latency is high. Instead of distributing SAP application servers across availability zones, you can deploy and run all SAP application servers on one active zone. The SAP Central Services instances that uses enqueue replication, and database instances that performs replication will be distributed across two availability zones. In this configuration there should be no delta in runtime of business process or batch jobs for cross-zone workload as all the active SAP application servers and database will be running on one availability zone. The layout of this type of architecture could look like below –

 

 

The important thing to consider while using this architecture is that you need to closely monitor your system to keep the active database and SAP central services in the same zone as the deployed application servers. So that in case of failover of database or SAP central services, you need to make sure that you manually fail them back as soon as possible into the zone where SAP application servers are deployed.

 

To prevent SAP application instances unavailability due to zone failure, you should deploy dormant dialog instances in other availability zone.

 

IMPORTANT: Alongside the option you choose for SAP deployment across availability zones, there are some important considerations on Azure for SAP system configuration that applies to both options, which is described in following section.

 

Step 3: Important Consideration for SAP Deployment across Availability Zones

 

For deployment across availability zones, there are some important consideration to note with respect to Azure Services that you use to build SAP system.

 

1. The concepts of Azure Availability zones and Azure availability sets are mutually exclusive. That means, you can either deploy a pair or multiple VMs into a specific Availability zone or an Azure Availability Set. But not both. To compensate for that, you can use Azure proximity placement groups as documented in the article Azure Proximity Placement Groups for optimal network latency with SAP applications.


2. There are VMs like M/Mv2 families, which are deployed only in a subset of the regions. You can find out what exact VM, types, Azure storage types or, other Azure Services are available in which of the regions with the help of the site Products available by region.


3. Distributing VMs across Availability zones, will only take care of virtual machines redundancy. Consider the scope of other Azure Services for zone redundancy which are part of SAP Application. For example, storage, load balancer and so on.


4. Use Standard SKU Load Balancer to load balancer failover cluster for SAP central services and database.


5. Virtual network span across availability zones. So, you do not need separate virtual network for each zone.


6. Use  Azure Managed Disks for all virtual machines. Unmanaged disks are not supported for zonal deployments.


7. Azure Premium storage and Ultra SSD storage do not support any type of storage replication across zones. So, the application must replicate important data.


8. Even for shared directory like sapmnt, which is either shared disk (Windows), or CIFS share (Windows), or NFS share (Linux) do not replicate data across zones.

 

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.