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.
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.
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.
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.
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.
For deployment across availability zones, there are some important consideration to note with respect to Azure Services that you use to build SAP system.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.