First published on MSDN on Nov 14, 2017
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 3
rd
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: