SAP HANA is the well-known technology from SAP, powering different SAP applications like SAP S/4 HANA, SAP BW for HANA, SAP Business Suite on HANA, etc.
High availability (HA) is a current commodity and must-have feature expected by many SAP customers running their productive SAP HANA systems in the Azure cloud.
SAP HANA runs only on Linux distributions.
Typically, in an HA scenario we would cluster SAP Single Points of Failures (SPOFS) like DBMS and SAP central services (SAP ASCS / SCS instance), and we have at least two redundant SAP application servers.
If you would deploy an SAP system completely on Linux OS (using SLES or Red Hat), the SAP HA architecture would include:
- [Linux] Clustered SAP HANA with Pacemaker on Linux
- [Linux] Clustered SAP ASCS/SCS with Pacemaker on Linux
- [Linux] A file share for SAP GLOBAL host
- [Linux] At least two SAP application servers on Linux
So, what does the Windows and Windows Failover Clustering have to do with SAP HA systems running on HANA?
- [Linux] Cluster SAP HANA with Pacemaker on Linux
- [Windows] Use Windows Failover Cluster for SAP ASCS/SCS instance
- One option is to use HA file share, for SAP GLOBAL host
- Another option is to use shared disks
- [Windows] At least two SAP application servers are on Windows
In below architecture, we use a file share construct (instead of share disks) for the SAP ASCS/SCS instance.
The highly available SMB file share is implemented using Windows Scale-Out File server (SOFS) and Storage Spaces Direct (S2D).
This scenario is supported by SAP, as HANA client is available and supported on Windows OS.
The main question is – why would some customer run such a heterogenous OS/clustering scenario?
Well, there are a few cool features on Windows Clustering for SAP ACS/SCS instance that bring valuable benefits that are unfortunately not available on Linux Pacemaker cluster for ASCS/SCS, like:
- Fault-Tolerant SAPMNT file share on Windows Cluster
In a Windows failover cluster, there is a feature called Continuous Availability (CA) which offers fault-tolerant SAPMNT share during the failover.
CA is available on :
– Clustered File Server for general use (in combination with shared disk)
– and clustered Scale-Out File Share (in combination with S2D )
A typical benefit would be, for example, for active SAP batch process that continuously write their logs on SAP GLOBAL host via SAPMNT file share.Without this feature, failover of SAPMNT file share will cause cancelation of active SAP batch (due to loss of file handle), and you need to restart them from the beginning, which is a not a funny situation if you run business critical reports that must be finished on time.With an enabled CA feature, batch jobs are not canceled during the SAPMNT file share fail over (for unplanned or planned downtime) and are running happily until they are finished!
More details can be found in this blog New Failover Clustering Improvements in Windows Server 2012 and Its Benefits for SAP NetWeaver High Availability and SAP note 2287140 – Support of Failover Cluster Continuous Availability feature (CA).This feature is available inWindows 2012 and higher releases.
- The SAP Installer fully supports Windows failover clustering with shared disks as well as file share, which greatly simplifies deployment procedure.
- SAP documentation fully describes high availability with Windows clustering for SAP ASCS/SCS instance
- On Azure Windows Failover Cluster supports Multi-SID option,
e.g. ability to install more SAP ASCS/SCS instances belonging to different SAP systems into one cluster. In this way, customers can consolidate SAP load and reduce the cost in Azure.
More information on Multi-SID can be found in official SAP on Azure guides:
SAP ASCS/SCS instance multi-SID high availability with Windows Server Failover Clustering and file share on Azure
SAP ASCS/SCS instance multi-SID high availability with Windows Server Failover Clustering and shared disk on Azure
- Azure Cloud Witness
Cloud Witness is a type of Failover Cluster quorum witness that uses Microsoft Azure to provide a vote on cluster quorum. For more information check Deploy a Cloud Witness for a Failover Cluster.
Azure cloud witness replaces the cluster Quorum with file share on the stand alone VM. As Azure cloud witness is cloud service, the whole solution is much easier to manage and overall TCO is reduced.
The following table gives a comparison overview:
|Windows Failover Cluster||Linux Pacemaker Cluster|
|Cluster software included in OS License||Yes||Yes|
|Integrated with Enqueue Replication Service (ERS instance)
(Fault tolerant SAP transaction lock)
|Fault Tolerant SAPMNT File Share
(No downtime for SAP Batch Jobs)
(Continuous Availability feature)
(cancelation of SAP Batch Jobs)
Cluster Share Disk
|Direct support by SAP||Yes||No
|Integrated in SAP installer||Yes
(SWPM supports both
file share and shared disks)
|Described in SAP Installation Guides||Yes||No
|Regular Installation & upgrade test by SAP||Yes||No
|Can be used for NW on HANA||Yes||Yes|
|ASCS/SCS Multi-SID support in Azure
(Consolidation & TCO Reduction)
|Cloud Cluster Quorum Service||Yes||No*
* although Azure Fence is supported, SBD fencing (which requires extra VM) is preferred option due to faster failover
In addition to SAP HANA, the same HA architecture can be used with any other DB running on Linux that supports DB client on Windows OS like:
- SAP Sybase
- SAP Max DB
- IBM DB2