Aligning SAP application servers with the HANA primary zone on Azure (Public Preview) — Part 1

Many SAP on Azure customers improve resilience by deploying critical SAP tiers across two distinct Azure Availability Zones. A common pattern for the SAP application layer in cross-zone designs is Active/Passive:

• One set of SAP application servers is active in the same zone as the database primary.
• A second, identical set is passive in another zone, ready to be activated when needed.

This pattern is described in Microsoft guidance (and is often the starting point for cross-zone SAP discussions): https://learn.microsoft.com/en-us/azure/sap/workloads/high-availability-zones

The operational challenge is what happens after a failover.

When the HANA primary moves to another zone, customers typically want the SAP application layer to follow so that the active application servers remain co-located with the database primary. In many environments, cross-zone network performance is well within acceptable ranges; however, for latency-sensitive workloads and specific regional topologies, keeping application and database tiers in the same zone can be a useful optimization. As always, validate with measurements for your own workload and region.

This post introduces a new Pacemaker resource agent for SAP on Azure deployments, that helps automate the Active/Passive application-server alignment. The resource agent is currently in a public preview.

Why align the SAP application tier?

In SAP HANA deployments on Azure, it's common to place the HANA primary and secondary VMs, as well as the SAP application VMs in different availability zones to improve resilience.

SAP workloads are sensitive to latency, and while cross-zone latency is often acceptable for SAP workloads, it can become a factor in certain regional topologies - especially when application-to-database round trips are frequent. Keeping the active application tier in the same zone as the HANA primary reduces those cross-zone hops and helps make performance more consistent during steady state and after a failover.

To achieve minimal latency, many customers choose to:

• Keep application servers deployed across zones for resiliency, and
• When the HANA primary changes zones, switch which application-server set is active, so it runs in the same zone as the primary.

Doing this manually is possible, but it adds steps during an already time-sensitive event and increases the chance of running "active" application capacity in the wrong zone longer than intended. This pacemaker resource agent addresses this gap: it keeps the application tier aligned with the current HANA primary in a predictable way after failovers, while preserving an active/passive design across zones.

Introducing the resource agent

Azure SAP Zone Resource Agent is a Pacemaker resource agent that aligns SAP application server VMs with the current HANA primary VM.

At a high level, the agent:

• Detects where HANA primary is running (Azure Availability Zone, or a customer-provided logical group)
• Ensures the "same zone" SAP application server VMs are running.
• Starts SAP on those VMs.
• Deactivates or stops SAP on application servers in the other availability zone and optionally stops or deallocates the corresponding VMs.

This gives you an automated way to keep the application tier aligned with the database tier after failovers, while preserving the active/standby design across zones.

Architecture at a glance

The resource agent is designed for an Active/Passive application tier across zones: Only one availability zone should have active application servers at any given time.

 

What the agent automates

• Automates application-server alignment to the HANA primary zone for Active/Passive application-tier designs.
• Provides clear operational choices (fast "passive mode" vs "stop/deallocate" for cost management)

Supported placement patterns

This Resource Agent targets cross-zone SAP deployments for Active-Passive deployment patterns:

• Explicit zone assignment: where VM zone information is available (the agent can read the HANA primary VM's and application server VMs' zone and align the application tier accordingly).
• Zone placement achieved indirectly: in some architectures using Proximity Placement Groups (PPG) and Availability Sets, the deployment achieves cross-zone separation, but the VM zone metadata isn't available to the agent. In those cases, you can provide the zone/group as an input by mapping HANA VMs and application server VMs into logical groups.

How it works (conceptually)

Think of Azure SAP Zone Alignment Resource Agent as an orchestration layer that sits alongside your existing Pacemaker-managed HANA high availability setup:

• Signal: Pacemaker knows which HANA node is primary.
• Decision: determine the target zone/group of the HANA primary.
• Action: interact with Azure to start/stop VMs and invoke SAP start/stop actions remotely.

Under the hood, the agent uses:

• Azure Instance Metadata Service (IMDS) to understand VM context.
• Azure Resource Manager APIs to manage application VMs (start/stop/deallocate) and run remote commands.
• Standard SAP control operations to start/stop or make instances inactive.

You do not need to change how HANA failover is handled. HANA failover decisions remain exclusively managed by the SAPHANA-SR-* agents. This Resource Agent focuses solely on ensuring the application tier follows the database tier in a predictable and repeatable manner.

Two operational modes: fast recovery vs cost optimization

Customers have different priorities during failovers. The preview supports two modes so you can choose the trade-off that best matches your operational goals.

Option 1: Deactivate (passive mode)

In this mode, SAP instances in the non-primary zone are placed into an inactive/passive state (so they don't take new workload), while the VMs remain running.

Best for: fastest "swing back" during failover

Trade-off: the inactive-zone VMs are still running (no compute cost reduction)

Option 2: Soft shutdown + stop/deallocate.

In this mode, the agent initiates a graceful stop of SAP Application Servers in the non-primary zone and then stops/deallocates the VMs.

Best for: reducing compute usage of SAP application servers in the inactive zone in Pay as You Go model.

Trade-off: reactivation takes longer (VM boot + SAP start)

What you need (high level)

This Pacemaker resource agent assumes a specific but common topology:

• Two identical sets of SAP application server VMs (one set per zone/group)
• A Pacemaker cluster managing HANA system replication (primary/secondary)
• Application-side routing configured so users and jobs can run on either set when activated.

Operationally, you'll also need:

• A managed identity with permissions to perform the required VM operations against the application VMs.
• Azure Linux Agent installed and running on the SAP application VMs (for remote command execution)

Note on operating system.

This public preview focuses on SUSE Linux Enterprise Server (SLES), specifically SLES 15 SP5 and later.

Current scope and limitations

This preview is intentionally focused so we can learn quickly and make improvements based on customer feedback.

• Supported: SAP ABAP systems on HANA scale-up running on SLES
• Not supported: SAP Java, HANA scale-out, multi-SID environments

Getting started

If you'd like to evaluate the preview, start here:

The resource agent is available upstream in the ClusterLabs resource-agents repository.

For detailed technical guidance - including prerequisites, installation steps, configuration examples, and troubleshooting - see Part 2 of this blog series.

If you encounter issues or have suggestions, please file them via GitHub Issues so we can track and respond.

What's next

This post covered the concepts, features, and operational modes of the Azure SAP Zone Resource Agent. In Part 2 of this series, we go hands-on with the technical details - architecture deep dive, prerequisites, step-by-step installation, cluster configuration examples, and troubleshooting guidance.

Public preview expectations

During public preview:

• This solution is provided as a Public Preview for evaluation and feedback.
• It is not covered by a formal support commitment.
• The design, configuration, and behaviors may evolve based on learnings.

Because of that, we recommend using this in non-production environments while it is in preview.

If you're interested in piloting the preview, your feedback will help shape what becomes generally available and supported.

Disclaimer

This post describes a public preview capability. It is shared for informational purposes only and is subject to change. It is not a substitute for your organization's validation, testing, and operational readiness reviews.