Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

SAP on Azure: Quick guide for deploying SAP workloads across Azure Availability Zones

mary_chen
Explorer
‎06-27-2023 10:10 PM

Introduction


Deploying SAP workload across Azure Availability Zones ensures high availability and fault tolerance for your mission-critical business applications.  Azure Availability Zones provide physically separate data centres within an Azure region, each with its own power, cooling, and networking infrastructure.  By strategically distributing your SAP components across zones, you can protect your SAP systems from zone-level failures and provide a robust infrastructure for uninterrupted operations.

Purpose


In this blog, we will outline some best practices to follow when deploying SAP workloads across Azure Availability Zones.  These guidelines cover various aspects, including architecture planning, compute, storage and network.  By adhering to these guidelines, you can ensure the resilience, scalability, and optimal performance of your SAP systems on Azure.

Note that deploying SAP workloads requires collaboration between your SAP and Microsoft Azure teams to align with SAP's specific requirements and best practices.

Quick guide for deploying SAP with Azure Availability Zones


When deploying SAP workloads across Azure Availability Zones, here are some guidelines to follow:

  • Region Choice: Refer to my colleague Etienne Dittrich’s blog SAP on Azure: Quantifying your Region Choice.  All architectures start with defining your primary and DR regions, but note that not all Azure regions support Availability Zones: Azure regions currently support availability zones.

  • Architecture Planning: Work closely with your SAP and Azure architects to design a robust and high-availability architecture that leverages Azure Availability Zones. Consider factors such as the number of SAP application servers, database servers, Azure Load Balancers, and any other components required for your SAP deployment.  For more information, see SAP workload configurations with Azure Availability Zones for SAP on Azure zonal deployment reference architecture.

  • Understand Active/Active vs. Active/Passive:

    • Active/Active: This deployment architecture is called active/active because you deploy your active SAP application servers across two or three zones.  At any point of time, there will be active application servers running in a minimum of two zones.  The SAP Central Services instance that uses enqueue replication will be deployed between two zones.  The same is true for the DBMS layer, which will be deployed across the same zones as SAP Central Service.  Whilst SAP Central Services and DBMS layer are also deployed across two zones, only one will be active at any point in time.

    • Active/Passive: The only difference to an active/active deployment is that your active SAP application servers are running in only one zone at any point in time. In this scenario, you can leverage zone to zone Azure Site Recovery (ASR) to replicate your application servers into the secondary zone.  Another alternative is pre-provision application servers in the secondary zone, which will remain shut down until required.



  • Physical zone <-> Logical zone mapping: Physical zones are mapped to logical zones in your Azure subscription. Azure subscriptions are automatically assigned this mapping at the time a subscription is created.  You want to make sure to repeat this exercise for each of your Azure subscriptions if there’s more than one subscription.  PowerShell script - Avzone-Mapping script can be used to find out the mapping of the new subscription relative to the old subscription.

  • Support prerequisites: to ensure full supportability and optimal performance of SAP systems on Microsoft Azure Virtual Machine Service, refer to SAP Note 2015553 - SAP on Microsoft Azure: Support prerequisites for support prerequisites that have to be met.



Figure 1 – Example SAP S/4HANA on Linux - Azure AvZones Architecture Diagram


 *Credit by Leon Davis (Snr SAP Cloud Solution Architect in Microsoft Partner Success Organisation)




Compute



  • Azure Virtual Machines: Select appropriate Azure Virtual Machine (VM) size and configuration that meets the SAP system requirements. Ensure that you choose VMs that are certified for SAP workloads.  For more information, see SAP Note 1928533 - SAP Applications on Microsoft Azure: Supported Products and Azure VM types for VM SKUs that are certified by SAP to run SAP NetWeaver and AnyDB and Certified and Supported SAP HANA® Hardware to run SAP HANA.

  • High Availability for SAP Components: Distribute your SAP components across different Availability Zones. For example, deploy SAP application servers, database servers, and other critical components in separate zones.  This configuration ensures that if one zone experiences an outage, your SAP system remains operational in the other zones.

  • Not all Azure VM SKUs (Virtual Machine Sizes) are available in every Azure region and zone.  To determine the availability of a specific VM SKU in a particular zone, you can use PowerShell script - Get VMs available in zones to explore the available options for VM SKUs in your desired region and zone.


Storage



Network



  • Network Connectivity: Set up a reliable and high-bandwidth network connectivity solution between the SAP components deployed across Availability Zones. Consider using Azure ExpressRoute for a private and dedicated connection to Azure, ensuring low-latency and high-performance connectivity.

  • Ensure Accelerated Networking is enabled on all Azure VMs on which the SAP components run. This includes Central Services, Application Servers and Database VMs. For more information, see Accelerated Networking overview.  Accelerated Network is default for most of the VM deployments and is recommended for every VM hosting an SAP workload.  Accelerated Network improves the network performance by bypassing the physical switch.  By enabling accelerated networking on your SAP Azure VMs, you can take advantage of improved network performance and reduced latency.

  • Use Standard SKU size for Azure Load Balancer (not Basic SKU size) in front of your SAP HA components to remove Single Points of Failure (SPOF), e.g. SAP (A)SCS servers and Database servers. The Standard Azure load balancer offers some advantages over the Basic SKU such as working across Azure Availability zones, improved monitoring and logging capabilities as well as reduced latency.

  • The region list provided at Active/Active deployment serves as a guide for zonal deployments, however customers should execute comprehensive testing in order to make an informed decision with regards to following a deployment architecture.

  • The following script can be used to determine Inter-zone Round Trip Time (RTT) network latency – PowerShell script - Availability Zone Latency Test. This script deploys 1 VM into each of the 3 AZs within the region, installs qperf on them, and finally measures the latency between each of the VM’s. This information is taken into consideration when deciding on which deployment architecture (Active/Active vs Active/Passive) to follow.  It is important to note the result is for one way latency and should be multiplied by two, in order to get the total RTT.  The SAP workload would be deployed into the two AZs with the lowest latency between them.

  • In addition to the above, you should test the latency between the SAP application server and database using the SAP ABAP report /SSA/CAT for ABAP-based systems.  For more information, see SAP Note 2879613 - ABAPMETER in NetWeaver AS ABAP.  Execute /SSA/CAT to check ABAPMETER several times (to get an average) and then from time to time (as things might move around in Azure) or after any kind of Infrastructure change (upgrading to a larger or new VM).  Refer to Acc DB and E. Acc DB. This note contains recommended threshold values for this report:



Figure 2 - ABAPMETER showing concerningly high DB response times only on instance xxxxxxxxxxxxxxx_02 (source: SAP Note 2879613)


 


Figure 3 - Command used to measure RTT (source: SAP Note 500235)


 


Figure 4 - Threshold value of latency between app and DB recommended by SAP (source: SAP Note 1100926)


 

 

Conclusion


In this blog, we have seen a list of considerations for deploying SAP workload across Azure Availability Zones.

It's crucial to engage with Microsoft Azure team (SAP Cloud Solution Architects and SAP on Azure engineering) and SAP experts for guidance and best practices specific to your SAP workload.

References


SAP workloads on Azure: planning and deployment checklist

SAP on Azure: Quantifying your Region Choice

Azure regions currently support availability zones

SAP workload configurations with Azure Availability Zones

zone to zone Azure Site Recovery (ASR)

PowerShell script - Avzone-Mapping script

Certified and Supported SAP HANA® Hardware

PowerShell script - Get VMs available in zones

Azure Storage types for SAP workload

SAP HANA Azure virtual machine Premium SSD storage configurations

SAP HANA Azure virtual machine Premium SSD v2 configurations

SAP HANA Azure virtual machine Ultra Disk storage configurations

NFS v4.1 volumes on Azure NetApp Files for SAP HANA

Accelerated Networking (AccelNet) overview

PowerShell script - Availability Zone Latency Test

SAP Notes


SAP Note 1928533 - SAP Applications on Microsoft Azure: Supported Products and Azure VM types

SAP Note 2367194 - Use of Azure Premium SSD Storage for SAP DBMS Instance

SAP Note 2879613 - ABAPMETER in NetWeaver AS ABAP

SAP Note 500235 - Network Diagnosis with NIPING

SAP Note 1100926 - FAQ: Network performance

SAP Note 2931465 - When to use Proximity Placement Groups on Azure to Reduce Network Latency – 3 Tie...
2 Comments
Labels in this area
Popular Blog Posts