Shared Storage and Load Balancer Deep Dive
Configure shared storage for SAP HA clusters on Windows and Linux, master Azure Load Balancer settings including floating IP, health probes, custom ports 620xx/621xx, multi-SID frontends, and zone-redundant load balancing.
The glue that holds clusters together
π‘οΈ Lars reviews the cluster architecture. βWe have covered the theory of ASCS and HANA HA. Now I need to get the shared storage and Load Balancer details exactly right. One misconfigured health probe port and the whole failover chain breaks.β
βοΈ Mei agrees. βShared storage and Load Balancer are the two infrastructure components that make SAP clustering actually work on Azure. Let me walk you through the details for both Windows and Linux.β
Think of shared storage like a shared locker at a train station.
Two workers (cluster nodes) need access to the same tools and documents. The shared locker (storage) ensures whoever is on shift can grab what they need. The Load Balancer is like the stationβs information desk β customers always ask the desk for help, and the desk directs them to whichever worker is currently available. The desk checks a sign-in sheet (health probe) to know who is active.
Shared storage for ASCS clusters
Windows ASCS β Azure Shared Disk
Windows ASCS HA uses WSFC which requires a shared disk:
- Azure Shared Disk (Premium SSD with multi-attach) is attached to both cluster nodes
- WSFC manages disk ownership β only the active node writes to it
- Stores SAP instance profiles, global directory, and transport files
- ZRS (Zone Redundant Storage) Shared Disk for cross-zone deployments
Alternative: SOFS (Scale-Out File Server) β Windows file shares hosted on a separate cluster. More complex but avoids Shared Disk limitations.
Linux ASCS β ANF or NFS Azure Files
Linux ASCS HA uses NFS-based shared storage:
- Azure NetApp Files (ANF) β high-performance NFS volumes, recommended for large deployments
- NFS on Azure Files β managed NFS shares, simpler and lower cost
- Both provide the /sapmnt and /usr/sap/trans mount points that ASCS needs
- Pacemaker does not manage the storage β it is always available to both nodes
| Feature | Windows (Azure Shared Disk) | Linux (ANF) | Linux (NFS Azure Files) |
|---|---|---|---|
| Protocol | Block (shared SCSI) | NFS v4.1 | NFS v4.1 |
| Cluster software | WSFC | Pacemaker | Pacemaker |
| Storage management | WSFC manages disk ownership | Always mounted on both nodes | Always mounted on both nodes |
| Cross-zone support | ZRS Shared Disk | ANF cross-zone placement | ZRS option available |
| Performance | Disk-tier dependent | Premium/Ultra tiers available | Premium tier recommended |
| Cost | Per-disk pricing | Capacity pool pricing | Per-share pricing |
| Best for | Windows-only SAP environments | Large Linux SAP deployments | Cost-sensitive Linux deployments |
HANA shared storage
HANA clusters also need shared storage for /hana/shared (HANA binaries, configuration, trace files):
- Scale-up HA: /hana/shared must be on ANF, NFS on Azure Files, or Azure Shared Disk β it must be accessible from both cluster nodes during failover (a simple locally attached disk cannot be shared across HA nodes)
- Scale-out HA: /hana/shared must be on ANF or NFS on Azure Files (multiple nodes need concurrent access)
- /hana/data and /hana/log are always local to each node (replicated via HSR, not shared storage)
Transport directory
The SAP transport directory (/usr/sap/trans) needs to be accessible from all SAP systems in the landscape. Options:
- ANF volume shared across all SAP VMs
- NFS Azure Files share mounted on all systems
- This is not a cluster resource β it is a shared file system used by all SAP systems
Azure Load Balancer deep dive
The Standard internal Load Balancer is the backbone of SAP clustering on Azure. Every SAP cluster (ASCS, HANA) needs one.
Mandatory settings for SAP
Floating IP (Direct Server Return) β must be enabled. Without it, the Load Balancer performs NAT, changing the destination IP. SAPβs virtual hostname mechanism requires the original IP to arrive at the backend VM unchanged.
Health probes β the Load Balancer sends TCP probes to a specific port on each backend VM. Only the active cluster node responds (via a lightweight helper process), so traffic routes only to the active node.
Port patterns:
- ASCS: 620xx (where xx = instance number)
- ERS: 621xx
- HANA: 625xx
- Example: ASCS instance 00 = port 62000, HANA instance 03 = port 62503
HA ports rule β instead of defining individual port forwarding rules for every SAP port (32xx, 33xx, 36xx, etc.), an HA ports rule forwards ALL ports through a single rule. This simplifies configuration significantly.
Idle timeout β set to 30 minutes (maximum). SAP connections are long-lived, and the default 4-minute timeout causes disconnections.
Exam tip: Health probe port patterns
The exam will give you an SAP instance number and ask what health probe port to configure. The formula is straightforward: 620xx for ASCS, 621xx for ERS, 625xx for HANA. Always replace xx with the instance number (zero-padded to two digits). Multi-SID setups need separate frontend IPs and probes for each SID.
Multi-SID Load Balancer
When multiple SAP SIDs share the same cluster pair (e.g., DEV and QA ASCS on the same two VMs):
- Each SID gets its own frontend IP address
- Each SID gets its own health probe on a unique port
- The backend pool remains the same (both VMs)
- HA ports rules apply per frontend IP
This reduces the number of VMs needed but increases cluster complexity.
Zone-redundant Load Balancer
For cross-zone SAP deployments:
- Standard Load Balancer with a zone-redundant frontend IP
- Survives an entire zone failure β the frontend IP remains reachable
- Backend VMs in different zones are reached through the surviving zoneβs path
- This is the recommended configuration for new deployments using availability zones
Knowledge check
Lars is configuring shared storage for Linux ASCS HA. The deployment uses availability zones and needs high performance. What should he choose?
Lars needs to configure the Azure Load Balancer idle timeout for SAP. What value should he set?
GlobalPharma runs three SAP SIDs (ERP, BW, SolMan) with ASCS instance numbers 00, 01, and 02 on the same cluster pair. How should the Load Balancer be configured?
Summary
You now have the detailed knowledge of shared storage and Load Balancer configuration for SAP HA: Azure Shared Disk for Windows, ANF/NFS Azure Files for Linux, floating IP and health probes on the Load Balancer, port patterns (620xx/621xx/625xx), HA ports rules, multi-SID frontends, and zone-redundant configuration. These details are heavily tested on the exam.
Next, we shift from HA (protecting against component failure) to DR (protecting against regional disasters) β a fundamentally different challenge with different solutions.
π¬ Video coming soon