
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.
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:
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:
Disadvantages:
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:
Disadvantages:
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:
Disadvantages:
For more information about SAMBA follow this link:
https://www.samba.org/samba/docs
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:
Disadvantages:
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:
Disadvantages:
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:
Disadvantages:
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:
Disadvantages:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
19 | |
19 | |
15 | |
9 | |
9 | |
8 | |
7 | |
6 | |
6 | |
6 |