Cluster an SAP ASCS/SCS instance on a Windows failover cluster by using a cluster shared disk in Azure

Article
02/10/2023

Windows

Windows Server failover clustering is the foundation of a high-availability SAP ASCS/SCS installation and DBMS in Windows.

A failover cluster is a group of 1+n-independent servers (nodes) that work together to increase the availability of applications and services. If a node failure occurs, Windows Server failover clustering calculates the number of failures that can occur and still maintain a healthy cluster to provide applications and services. You can choose from different quorum modes to achieve failover clustering.

Prerequisites

Before you begin the tasks in this article, review the following article:

Azure Virtual Machines high-availability architecture and scenarios for SAP NetWeaver

Windows Server failover clustering in Azure

Windows Server failover clustering with Azure Virtual Machines requires additional configuration steps. When you build a cluster, you need to set several IP addresses and virtual host names for the SAP ASCS/SCS instance.

Name resolution in Azure and the cluster virtual host name

The Azure cloud platform doesn't offer the option to configure virtual IP addresses, such as floating IP addresses. You need an alternative solution to set up a virtual IP address to reach the cluster resource in the cloud.

The Azure Load Balancer service provides an internal load balancer for Azure. With the internal load balancer, clients reach the cluster over the cluster virtual IP address.

Deploy the internal load balancer in the resource group that contains the cluster nodes. Then, configure all necessary port forwarding rules by using the probe ports of the internal load balancer. Clients can connect via the virtual host name. The DNS server resolves the cluster IP address, and the internal load balancer handles port forwarding to the active node of the cluster.

Important

Floating IP is not supported on a NIC secondary IP configuration in load-balancing scenarios. For details see Azure Load balancer Limitations. If you need additional IP address for the VM, deploy a second NIC.

Figure 1: Windows failover clustering configuration in Azure without a shared disk

Windows Server failover clustering configuration in Azure without a shared disk

SAP ASCS/SCS HA with cluster shared disks

In Windows, an SAP ASCS/SCS instance contains SAP central services, the SAP message server, enqueue server processes, and SAP global host files. SAP global host files store central files for the entire SAP system.

An SAP ASCS/SCS instance has the following components:

SAP central services:
- Two processes, a message and enqueue server, and an <ASCS/SCS virtual host name>, which is used to access these two processes.
- File structure: S:\usr\sap\<SID>\ASCS/SCS<instance number>
SAP global host files:
- File structure: S:\usr\sap\<SID>\SYS...
- The sapmnt file share, which enables access to these global S:\usr\sap\<SID>\SYS... files by using the following UNC path:
  
  \\<ASCS/SCS virtual host name>\sapmnt\<SID>\SYS...

Figure 2: Processes, file structure, and global host sapmnt file share of an SAP ASCS/SCS instance

Processes, file structure, and global host sapmnt file share of an SAP ASCS/SCS instance

In a high-availability setting, you cluster SAP ASCS/SCS instances. We use clustered shared disks (drive S, in our example), to place the SAP ASCS/SCS and SAP global host files.

Figure 3: SAP ASCS/SCS HA architecture with shared disk

SAP ASCS/SCS HA architecture with shared disk

With Enqueue server replication 1 architecture:

The same <ASCS/SCS virtual host name> is used to access the SAP message and enqueue server processes, and the SAP global host files via the sapmnt file share.
The same cluster shared disk drive S is shared between them.

With Enqueue server replication 2 architecture:

The same <ASCS/SCS virtual host name> is used to access the SAP message server process, and the SAP global host files via the sapmnt file share.
The same cluster shared disk drive S is shared between them.
There is separate <ERS virtual host name> to access the enqueue server process

Figure 4: SAP ASCS/SCS HA architecture with shared disk

SAP ASCS/SCS HA architecture with shared disk

Shared Disk and Enqueue Replication Server

Shared disk is supported with Enqueue server replication 1 architecture, where Enqueue Replication Server (ERS) instance:
- is not clustered
- uses localhost name
- is deployed on local disks on each of the cluster nodes
Shared disk is also supported with Enqueue server replication 2 architecture, where the Enqueue Replication Server 2 (ERS2) instance:
- is clustered
- uses dedicated virtual/network host name
- needs the IP address of ERS virtual hostname to be configured on Azure Internal Load Balancer, in addition to the (A)SCS IP address
- is deployed on local disks on each of the clustered nodes, therefore there is no need for shared disk
Tip

You can find more information about Enqueue Replication Server 1 and 2 (ERS1 and ERS2) here:
Enqueue Replication Server in a Microsoft Failover Cluster
New Enqueue Replicator in Failover Cluster environments

Options for shared disk in Azure for SAP workloads

There are two options for shared disk in a windows failover cluster in Azure:

Azure shared disks - feature, that allows to attach Azure managed disk to multiple VMs simultaneously.
Using 3rd-party software SIOS DataKeeper Cluster Edition to create a mirrored storage that simulates cluster shared storage.

When selecting the technology for shared disk, keep in mind the following considerations:

Azure shared disk for SAP workloads

Allows you to attach Azure managed disk to multiple VMs simultaneously without the need for additional software to maintain and operate.
Azure shared disk with Premium SSD disks is supported for SAP deployment in availability set and availability zones.
Azure Ultra disk and Azure Standard disks is not supported as Azure shared disk for SAP workloads.
Make sure to provision Azure Premium disk with a minimum disk size as specified in Premium SSD ranges to be able to attach to the required number of VMs simultaneously (typically 2 for SAP ASCS Windows Failover cluster).

SIOS

The SIOS solution provides real-time synchronous data replication between two disks
With the SIOS solution you operate with two managed disks, and if using either Availability sets or Availability zones, the managed disks will land on different storage clusters.
Deployment in Availability zones is supported
Requires installing and operating third-party software, which you will need to purchase additionally

Shared Disk using Azure shared disk

Microsoft is offering Azure shared disks, which can be used to implement SAP ASCS/SCS High Availability with a shared disk option.

Prerequisites and limitations

Currently you can use Azure Premium SSD disks as an Azure shared disk for the SAP ASCS/SCS instance. The following limitations are currently in place:

Azure Ultra disk and Standard SSD disks is not supported as Azure Shared Disk for SAP workloads.
Azure Shared disk with Premium SSD disks is supported for SAP deployment in availability set and availability zones.
Azure shared disk with Premium SSD disks comes with two storage SKUs.
- Locally redundant storage (LRS) for premium shared disk (skuName - Premium_LRS) is supported with deployment in Azure availability set.
- Zone-redundant storage (ZRS) for premium shared disk (skuName - Premium_ZRS) is supported with deployment in Azure availability zones.
Azure shared disk value maxShares determines how many cluster nodes can use the shared disk. Typically for SAP ASCS/SCS instance you will configure two nodes in Windows Failover Cluster, therefore the value for maxShares must be set to two.
Azure proximity placement group is not required for Azure shared disk. But for SAP deployment with PPG, follow below guidelines:
- If you are using PPG for SAP system deployed in a region then all virtual machines sharing a disk must be part of the same PPG.
- If you are using PPG for SAP system deployed across zones like described in the document Proximity placement groups with zonal deployments, you can attach Premium_ZRS storage to virtual machines sharing a disk.

For further details on limitations for Azure shared disk, please review carefully the limitations section of Azure Shared Disk documentation.

Important consideration for Premium shared disk

Following are some of the important points to consider for Azure Premium shared disk:

LRS for Premium shared disk
- SAP deployment with LRS for Premium shared disk will be operating with a single Azure shared disk on one storage cluster. Your SAP ASCS/SCS instance would be impacted, in case of issues with the storage cluster, where the Azure shared disk is deployed.
ZRS for Premium shared disk
- Write latency for ZRS is higher than that of LRS due to cross-zonal copy of data.
- The distance between availability zones in different region varies and with that ZRS disk latency across availability zones as well. Benchmark your disks to identify the latency of ZRS disk in your region.
- ZRS for Premium shared disk synchronously replicates data across three availability zones in the region. In case of any issue in one of the storage clusters, your SAP ASCS/SCS will continue to run as storage failover is transparent to the application layer.
- Review the limitations section of ZRS for managed disks for more details.

Tip

Review the SAP Netweaver on Azure planning guide and the Azure Storage guide for SAP workloads for important considerations, when planning your SAP deployment.

Supported OS versions

Windows Servers 2016, 2019 and higher are supported (use the latest data center images).

We strongly recommend using at least Windows Server 2019 Datacenter, as:

Windows 2019 Failover Cluster Service is Azure aware
There is added integration and awareness of Azure Host Maintenance and improved experience by monitoring for Azure schedule events.
It is possible to use Distributed network name(it is the default option). Therefore, there is no need to have a dedicated IP address for the cluster network name. Also, there is no need to configure this IP address on Azure Internal Load Balancer.

Shared disks in Azure with SIOS DataKeeper

Another option for shared disk is to use third-party software SIOS DataKeeper Cluster Edition to create a mirrored storage that simulates cluster shared storage. The SIOS solution provides real-time synchronous data replication.

To create a shared disk resource for a cluster:

Attach an additional disk to each of the virtual machines in a Windows cluster configuration.
Run SIOS DataKeeper Cluster Edition on both virtual machine nodes.
Configure SIOS DataKeeper Cluster Edition so that it mirrors the content of the additional disk attached volume from the source virtual machine to the additional disk attached volume of the target virtual machine. SIOS DataKeeper abstracts the source and target local volumes, and then presents them to Windows Server failover clustering as one shared disk.

Get more information about SIOS DataKeeper.

Figure 5: Windows Server failover clustering configuration in Azure with SIOS DataKeeper

Windows failover clustering configuration in Azure with SIOS DataKeeper

Note

You don't need shared disks for high availability with some DBMS products, like SQL Server. SQL Server Always On replicates DBMS data and log files from the local disk of one cluster node to the local disk of another cluster node. In this case, the Windows cluster configuration doesn't need a shared disk.

Optional configurations

The following diagrams show multiple SAP instances on Azure VMs running Microsoft Windows Failover Cluster to reduce the total number of VMs.

This can either be local SAP Application Servers on a SAP ASCS/SCS cluster or a SAP ASCS/SCS Cluster Role on Microsoft SQL Server Always On nodes.

Important

Installing a local SAP Application Server on a SQL Server Always On node is not supported.

Both, SAP ASCS/SCS and the Microsoft SQL Server database, are single points of failure (SPOF). To protect these SPOFs in a Windows environment WSFC is used.

While the resource consumption of the SAP ASCS/SCS is fairly small, a reduction of the memory configuration for either SQL Server or the SAP Application Server by 2 GB is recommended.