Cluster an SAP ASCS/SCS instance on a Windows failover cluster by using a cluster shared disk in Azure
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.
Before you begin the tasks in this article, review the following article:
Windows Server failover clustering in Azure
Compared to bare-metal or private cloud deployments, Azure Virtual Machines requires additional steps to configure Windows Server failover clustering. 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.
Figure 1: 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
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
These two components run under the same SAP ASCS/SCS instance:
- 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.
Figure 4: SAP ASCS/SCS HA architecture with shared disk
Shared disks in Azure with SIOS DataKeeper
You need cluster shared storage for a high-availability SAP ASCS/SCS instance.
You can 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 failover clustering configuration in Azure with SIOS DataKeeper
You don't need shared disks for high availability with some DBMS products, like SQL Server. SQL Server AlwaysOn 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.