Technical Articles
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
Hello Karl-Heinz,
Many thanks for updating the Solution 7, ignoring the path to sapmnt that has to be \\<hostname>\sapmnt there was additional information around using C-Name with DFS-Namespace. It now makes sense to stick with the DFS-Namespace root directory to be part of the UNC path for SWPM to work.
We have a scenario where we are using Domain-Based-DFS-Namespace, and your update helps.
Thanks again!
Regards,
Jitendra Singh
Even if the question from Jitendra has been answered some time ago via e-mail ... 🙂 ... here is the answer.
Don't use a variant like \\<hostname>\<fileshare>\sapmnt!
Use this variant to provide several SAPMNT shares for several systems:
Examples:
\\SAP_ABC_host\sapmnt
\\<name of your Windows domain>\sapmnt (this means, sapmnt is a DFS namespace)
\\SAP_PROD_ABC\sapmnt
...