File Server with SOFS and S2D as an Alternative to Cluster Shared Disk for Clustering of an SAP (A)SCS Instance in Azure is Generally Available
We are excited to announce general availability of clustering of an SAP (A)SCS instance on Windows Server Failover Cluster (WSFC) with file server, e.g. Scale Out File Server (SOFS) and Storage Spaces Direct (S2D) in Azure cloud. This is an alternative option for clustering of an SAP (A)SCS instance, to the existing option with cluster shared disks.
Many SAP customers who run their SAP system on Azure configure their SAP systems as high availability (HA) systems using Microsoft Windows Server Failover Cluster. They cluster SAP single point of failures (SPOF), that is DBMS and SAP (A)SCS instance.
When you cluster an SAP (A)SCS instance, a typical setting is to use cluster share disks.
Whoever worked with Windows Failover Cluster and cluster shared disks, knows that cluster shared disks are often hardware based solutions. As hardware-based solutions, you cannot always use it in each environment. Azure is one such example.
Microsoft in the past didn’t offer own solution for cluster shared disks. Typically, SAP customers on Azure would use some of the 3rd party solutions for a cluster shared disk for the HA of an SAP (A)SCS instance.
One of the top request from SAP customers running their SAP HA systems in Azure was an alternative Microsoft solution for clustered shared disks.
SAP developed new HA architecture for clustering SAP (A)SCS instance using file share, as additional option to cluster shared disks. SAP also developed a new SAP cluster resource DLL which is file share aware. For more information, check this blog: New SAP cluster resource DLL is available!
Clustering of an SAP (A)SCS instances with file share is supported for SAP NetWeaver 7.40 (and higher) products, with SAP Kernel 7.49 (and higher) .
Existing SAP HA Architecture with Cluster Shared Disk
When you install an SAP (A)SCS instance on a cluster shared disk, you install not only SAP (A)SCS<Nr> instance, but also SAP GLOBAL HOST folder, e.g. SYS folder. The virtual cluster host network name of the (A)SCS instance (e.g. of message and enqueue server processes) is also at the same time the SAP GLOBAL HOST name.
Figure 1: Existing SAP (A)SCS HA architecture with cluster shared disks
New SAP HA Architecture With File Share
With the new SAP (A)SCS HA architecture, the most important changes are the following:
- SAP (A)SCS instance (message and enqueue server processes) is separated from SAP GLOBAL HOST SYS folder
- SAP central services run under an SAP (A)SCS instance
- SAP (A)SCS instance is clustered and is accessible using the virtual host name <(A)SCSVirtualHostName>
- Clustered SAP (A)SCS<InstNr> instance is installed on local disks on both nodes of SAP (A)SCS cluster – therefore we do not need a shared disk
- SAP GLOBAL files are placed on SMB file share and are accessed using the host name \\<SAPGLOBALHost>\sapmnt\<SID>\SYS ...
- The <(A)SCSVirtualHostName> network name is different from <SAPGLOBALHost> name
Figure 2: New SAP (A)SCS HA architecture with SMB file share
If we would install file server on standalone Windows machine, we would create a single point of failure. Therefore, high availability of a file share server is also an important part of the overall SAP system HA story.
To achieve high availability of a file share:
- You must ensure that planned or unplanned downtime of Windows servers/VMs is not causing downtime of the file share
- Disks used to store files must not be a single point of failure
With Windows Server 2016, Microsoft offers two features which fulfil these requests:
- Scale Out File Server (SOFS)
- Storage Spaces Direct (S2D)
Scale Out File Server as Microsoft File Share HA Solution
Microsoft recommends the Scale Out File Share (SOFS) solution for enabling HA file shares. In SAP case, SAPMNT file share is protected with the HA SOFS solution. 
Figure 3: SAP (A)SCS instance and SOFS deployed in TWO clusters
As the name implies, this solution is “scale-out”, e.g. access to file share is parallelized. Different clients (in our case SAP application servers and an SAP (A)SCS instance) are accessing through all cluster nodes. This is a big advantage in comparison to a Generic File share, another HA file share feature of Windows Cluster, where access to file share is running through an active node.
Storage Spaces Direct (S2D) as Cluster Shared Storage HA Solution
SOFS stores files on a cluster shared disk, e.g. on cluster shared volumes (CSV). SOFS is supports different shared storages technologies.
For running SOFS on Azure, two criteria are important for cluster shared disks:
- Support of cluster shared disks for SOFS on Azure environment
- High availability and resiliency of cluster shared storage
Storage spaces direct (S2D) feature that comes with Windows Server 2016 fulfills both of these criteria.
S2D enables us to stripe local disks and create storage pool across different cluster nodes. Inside of those pools, we can create volumes which are presented to a cluster as shared storage e.g. as cluster shared volumes.
S2D is synchronously replicating disk content and offering different resilience, so loosing of some disks will NOT bring the whole shared storage down. 
Figure 4: SOFS file share used to protect SAP GLOBAL Host files
The nice thing about S2D is that it is a software-based shared storage solution that works transparently in Azure cloud, as well as in on-premises physical or virtual environments.
End-to-End Architecture
Complete end-to-end architecture of SAP NetWeaver HA with File Share looks like this: 
Figure 5: End-to-End SAP NetWeaver HA Architecture with SOFS File Share
Multi-SID Support
SAP (A)SCS Multi-SID enables us to install and consolidate multiple SAP (A)SCS instances in one cluster. Through consolidation, your overall Azure infrastructure costs will be reduced.
SAP (A)SCS Multi-SID clustering is also supported with a file share.
To enable a file share for the second the SAP <SID2> GLOBAHOST on the SAME SOFS cluster, you can use the same existing SAP <SID1> <SAPGLOBAlHOST> network name and same Volume1. 
Figure 6: SAP Multi-SID configuration in two clusters
Figure 7: Multi-SID SOFS using same SAP GLOBAL host name
Another option, is to use new <SAPGLOBAlHOST2> network name and new Volume2 for the second <SID2> file share.
Figure 8: Multi-SID SOFS with a different SAP GLOBAL host name 2
Available Documentation
For more information, have a look at the new documentation and white papers on Microsoft SAP on Azure site:
From SAP side, you can check this new white paper: Installation of an (A)SCS Instance on a Failover Cluster with no Shared Disks.
You can find more information on SOFS and S2D here: