This blog discusses the installation and configuration of SAP NetWeaver or S/4 HANA in a Windows Failover cluster, which cluster nodes are located in different subnets.

The configuration of the cluster, the configuration of network related things like dynamic DNS synchronisation, DNS server synchronisation, Windows OS configuration, etc. are mandatory for operations of SAP NetWeaver and S/4 HANA based installations.

The blog is not specific to a particular infrastructure or cloud environment.

Prequisites:

In this example we use a Windows Failover cluster, which has two cluster nodes in geographically dispersed locations. The Windows Server OS version is not relevant.

The network name of the cluster and its related IP addresses in Failover Cluster Manager, look like this:

This example shows two different IP addresses, which are dynamically registered in the DNS, if the related cluster group failovers from one node to another. Only one IP address can be online at one point in time.

We need the same configuration for the clustered ASCS and SCS instances!

Requirements on DNS server side:

1. The Windows Failover cluster nodes must be allowed to dynamically update DNS records on all involved DNS servers.
2. The DNS servers must be configured to synchronize changes immediately between them.
3. TTL must be lowered to 1.

Requirements on Windows:

1. The DNS cache on Windows must be disabled.
   See MS KB:  https://docs.microsoft.com/en-us/windows-server/networking/dns/troubleshoot/disable-dns-client-side-caching
2. TTL must be lowered to 1.

Requirements in Failover cluster:

Create an empty cluster group and rename it to “SAP <SID>”, where <SID> is the SAP SID you want to use for your new system:

Create a new “Client Access Point” cluster resource in this cluster group:

You have to configure TWO IP addresses for this network name:

The result should look like this:

Open a command prompt or PowerShell on both cluster nodes and use the following commands to check, if the name will be resolved with the correct IP address:

   ping <hostname>

   nslookup <hostname>

Failover the cluster group to the other cluster node.

Repeat the tests.

It should take just a few seconds (3-5 seconds) to reflect the changes in DNS and on OS level. If you face problems here, don’t start with the SAP installation! The failover must work properly.

Depending on your network infrastructure, DNS architecture and DNS vendor, maybe additional configuration steps are necessary.

Alternatively, the cluster group, the network name and the IP addresses can be configured using PowerShell.

Example:

Create a new, empty cluster group:
Add-Clustergroup -Name “SAP BOG”

Create the network name cluster resource:
Add-ClusterResource -Name “SAP BOG NetName” -ResourceType “Network Name” -Group “SAP BOG” | Set-ClusterParameter -Multiple @{“DnsName” = “ascs-bog”; }

Create both IP address cluster resources:
Add-ClusterResource -Name “SAP BOG IP” -ResourceType “IP Address” -Group “SAP BOG” | Set-ClusterParameter -Multiple @{“Address” = “10.98.5.252”; “SubnetMask” = “255.255.252.0”; “Network” = “cluster network 2”; “EnableDhcp” = 0}

Add-ClusterResource -Name “SAP BOG IP2” -ResourceType “IP Address” -Group “SAP BOG” | Set-ClusterParameter -Multiple @{“Address” = “10.20.50.252”; “SubnetMask” = “255.255.252.0”; “Network” = “cluster network 1”; “EnableDhcp” = 0}

Create the dependencies:
Set-ClusterResourceDependency -Resource “SAP BOG NetName” -Dependency “[SAP BOG IP] or [SAP BOG IP2]”

Note:
Depending on your network configuration, above commands must be modified, for example, if you want to use DHCP.

SAP installation

Make sure to always use the latest available SWPM from SAP Service Marketplace.

You can start SWPM on any cluster node with the step “First Cluster Node”:

SWPM will detect the existing cluster group and the network name and will use it to complete the installation.

The result should look like this (if you use shared disk, then you will also see the shared disk and the cluster file server resource):

Continue the installation on the next cluster node. This time choose “Additional Cluster Node” option:

Post-installation steps

Steps:

1. SAP Note 1425520 “Disable NI cache for host and service names” must be applied. Set the environment variables accordingly on all cluster nodes.
2. Install the application server instances on the cluster node or on other Windows VM.
3. Test the failover of the ASCS or SCS cluster group carefully!
4. Make sure to use the latest available SAPRC.DLL. See SAP note 1596496 how to update the
   DLL.

Checklist for testing

Enqueue server:
Check the dev_enrepha trace file in both Enqueue Replication Server (ERS) work folders. One ERS must be “active”, the other one must report “inactive”.

Failover cluster:
Run SAP’s Cluster Check Tool, which you find attached to SAP note 2624843. Look for “red” findings in the report.

Question and answers:

Q: I’d like to add another cluster node. What is the correct procedure?

A: Start SWPM with option “Additional Cluster Node” on the third, fourth … cluster node.
Make sure to upgrade the SAPRC.DLL after SWPM installation on the new cluster node!

Otherwise, you will have a mix of different SAPRC.DLLs on different cluster nodes.

Q: I have to use an older SWPM version (SP33 or older). How can I use this for a shared subnet  cluster configuration?

A: Evict the second cluster node from the cluster. Start SWPM with “First Cluster Node” option on the first cluster node. Complete the installation. Then add the second cluster node to the cluster. Afterwards start SWPM with “Additional Cluster Node” on the second cluster node and complete the installation. If SWPM stops during installation, press the “Retry” button to overcome a possible timing problem.

Q: I have problems with DNS. Who can help me?

A: The DNS configuration is part of the cluster infrastructure. All cloud providers must provide a  validated documentation. This documentation must contain the network configuration related changes to the landscape, including DNS.

Q: The Failover cluster doesn’t update DNS records as fast as expected. What can be the root cause?

A: Check the “HostRecordTTL” parameter with PowerShell and change it according to your landscape:

The TTL can be changed using this PS command:

Get-ClusterResource -Name “<network name resource>” | Set-ClusterParameter -Name HostRecordTTL -Value 15