How to create a high available SAPMNT share?

In a distributed SAP landscape, there must be a central SAPMNT share. This SAPMNT share will be accessed using the parameter SAPGLOBALHOST. On a Windows Failover Cluster installation, SAPGLOBALHOST is identical to the virtual hostname used for the (A)SCS instance.

But how should you make this very important sapmnt share “high available”?
In a Failover Cluster installation, this is done by default because the share is configured on a shared disk and the disk must be therefore highly available.

In this blog, I want to show you possible solutions for distributed or special Failover Cluster configurations, in which SAPMNT share is configured on a remote SMB file share.

Take a close look at the advantages and disadvantages of each solution to find the right one for your SAP operations.

Watch out, this blog will be updated and enhanced in the future! Follow this blog if you want to stay informed.

Solution 1: A file share on a shared disk in a Windows Failover Cluster

In this example, I have configured a network name “sap-global-host” in DNS and a Client Access Point in a Failover Cluster.

Screenshot of a cluster group which contain the necessary resources:

Screenshot of sapmnt share:

This cluster provides the share \\sap-global-host\sapmnt high available.

There are many solutions available on the market to provide a shared disk in a Failover Cluster:

• iSCSI attached disks
• SAN attached disks
• software mirroring solutions like DoubleTake, SIOS, AFSDrive, etc.

Remark:
The Continuous Availablity feature can be turned on if you are running Windows 2012, 2012 R2 or 2016 with at least the cumulative rollup patch of May, 2017.

For more information about this feature read SAP Note 2287140 – “Support of Failover Cluster Continuous Availabilty feature (CA)”

Advantages:

• High availability of sapmnt share covered by Failover Cluster technology

Disadvantages:

• shared disk needed, in geographically dispersed clusters this can be expensive

Solution 2: A NAS solution from a storage vendor

There are many NAS solutions available on the market. Well-known ones are NetApp Filers, EMC Cellera/Isilon/ScaleIO, HP StoreEasy, Nutanix, and many others.

All these solutions provide high available SMB/CIFS file shares. Contact the vendor for more information. Choose a solution which supports SMB protocol version 3.0 or higher.

The solution must support different additional (= virtual, logical) hostnames to support many different SAPMNT shares of several SAP systems.

Example:

\\networkname1\sapmnt
\\networkname2\sapmnt
\\networkname3\sapmnt
\\networkname4\sapmnt
…

Advantages:

• High availability of sapmnt share covered by proven third-party vendor solutions
• support available from vendor specific solution
• scalable for high performance SMB load (depending on solution)

Disadvantages:

• expensive
• configuration needs special know-how, vendor specific

Solution 3: SAMBA version 4.1 or higher

SAMBA as of version 4.1 supports SMB 3.0 protocol. There are several special HA solutions available on UNIX platforms and Linux distributions.

The solution must support different addtitional (= virtual, logical) hostnames to support many different SAPMNT shares.

Advantages:

• High availability of sapmnt share covered Unix/Linux OS which hosts SAMBA
• cheap

Disadvantages:

• support only available from community
• configuration needs special SAMBA and Unix know-how

For more information about SAMBA follow this link:

https://www.samba.org/samba/docs

Solution 4: A virtual machine (VM) with a Windows configured to host many file shares

Let’s call this “poor man’s high availability”. You configure many SAPMNT shares using different hostnames on a normal Windows Server OS. This Windows runs virtualized on VMware, Hyper-V, or any other Hypervisor.

Advantages:

• For a planned downtime of the Hypervisor host, you can simply “live migrate” the VM to another host with just an interruption of a second
• Cheap implementation

Disadvantages:

• If an unplanned downtime of the Windows VM occured, for example because the Hypervisor host or the guest OS crashed, the SAPMNT shares are not available until the VM will be started on another host
• If you have to apply monthly Windows patches to this VM, the Windows VM is also not available for some time

Solution 5: A Windows Server configured to host many file shares, running on a special solution like VMware FT, Stratus, or similar solutions

This is similar to solution 4. But in this scenario, the Windows OS hosting the SAPMNT shares is provided with high availability by special solutions like VMware’s Fault Tolerance, Stratus, or other solutions available on the market.

Advantage:

• high availability of the Windows OS and the sapmnt shares
• Failover does not cause any interruption

Disadvantages:

• expensive solutions
• no protection against OS crashes
• If you have to apply monthly Windows patches to this VM, the Windows VM is also not available for some time

Solution 6: “Scale out Fileserver” (SoFs) from Microsoft to provide high available file shares.

This solution is similar to solution 1. However, the SoFs provides load balancing to all cluster nodes. It’s limited to one geographically site only.

A share on a SoFs would also support the SMB 3.x CA feature.

Advantage:

• standard solution from Microsoft, good documentation available
• scalable for high performance SMB load

Disadvantages:

• needs a shared disk
• limitations, for example one geographically site only

Solution 7: Use DFS-R to provide sapmnt share

You configure a domain based DFS root in your Active Directory (AD). The DFS replication mechanism is used to replicate the sapmnt data.

<the example in older versions of this blog has been removed. It was correct in theory, but didn’t work with SWPM in the real world>

If you use want to use DFS you need to create a DFS using a hostname of type

\\<hostname>\sapmnt 

In an older version of this blog I use the example

\\<hostname>\<something>\sapmnt

This does not work, because this path will not be recognized by SWPM.

Advantage:

• cheap solution
• DFS is a standard solution from Microsoft and well documented
• many sapmnt shares using different Namespaces

Disadvantages:

• must be monitored and operated separately from SAP or AD operations
• DFS replication is always asynchronous
• cannot be used, if high I/O is expected on sapmnt share
• several sapmnt shares mean higher replication load for DFSR services