New Enqueue Replicator in Failover Cluster environments

[karl-heinz_hochmuth]

In this blog, I will show you the new Enqueue Server 2 in conjunction with the new Enqueue Replicator. You will learn the differences to the old Enqueue Replication Server (ERS) and the changes in the operations concept.

NetWeaver based HA configuration

NetWeaver-based systems use the two executables "enserver.exe" (Enqueue Server) and the "enrepserver.exe" (Enqueue Replication Server). Here are two example screens:

ASCS instance (#00) in a Failover Cluster:



 

ERS instance (#10) in a Failover Cluster (installed on each cluster node locally):



 

In this configuration, the ERS instance which does not run on the same host where the ASCS instance is running connects to the Enqueue Server and starts the replication of the lock table.

Lesson learned: The ERS connects to the Enqueue Server.

 

New concept, starting with S/4 HANA 1809

SWPM 2.0 uses the new executables and concept for S/4 HANA 1809 installations or higher. The executables are "enq_server.exe" (Enqueue Server 2) and "enq_replicator.exe" (Enqueue Replicator). Here are two example screens:

ASCS instance (#00) in a Failover Cluster:



 

ERS instance (#10) in a Failover Cluster (now clustered like the ASCS!):



 

The main difference of the new concept is that now the Enqueue Server 2 starts a connection to the Enqueue Replicator and initiates the replication of the lock table.

Lesson learned: The Enqueue Server 2 connects to the Enqueue Replicator.

To be able to do this, the ASCS profile must contain the (virtual) hostname of the Enqueue Replicator instance.

For more information on how to configure new Enqueue Server 2 and Enqueue Replicator instances, visit the SAP Help Portal.

SWPM 2.0 installs and configures this automatically.

If you upgrade from a NetWeaver-based system with the SAP SUM tool, be aware that SUM can upgrade the system, it's configuration, and the profiles, but is not able to change the configuration in Failover Cluster!
See this important SAP Note: 2639281 - "Migration to Standalone Enqueue Server 2 in Windows Failover Cluster environments"

The new concept has big advantages for HA scenarios with more than 2 cluster nodes. The ERS is now a clustered instance. SWPM automatically configures a so-called "affinity" in the Failover Cluster to prevent the cluster to operate both cluster groups (ASCS and ERS) on the same cluster node. Only if there is just one cluster node left, the cluster will bring both cluster groups online.

You can check the affinity with these PowerShell commands:

(Get-ClusterGroup -Name "SAP <SID>").AntiAffinityClassNames
(Get-ClusterGroup -Name "SAP <SID> ERS").AntiAffinityClassNames

The result must be in both cases the same affinity name. All cluster groups that belong to this affinity, will not be brought online on the same cluster node. With just one exception: if there is just one node left.

In Failover Cluster Manager you now see two cluster groups:

ASCS:


ERS:


Important!
Do not change the name of these cluster groups!


Depending on the installation method you have chosen in SWPM, the cluster group for the ASCS instance may contain additional cluster resources, like a shared disk and File Server resource.

The Enqueue Replicator instance will be installed locally (in SAPLOC), as the old ERS instance before.

 

Questions and answers:

Question: My ERS instance does not automatically fail back to another cluster node, if it runs together with the ASCS instance on one node?

Answer: Check the properties of the ERS cluster group.

You need to change two things there:

1. Enable the Failover / Failback option. Change it from the default value "Prevent failback" to "Allow failback -> Immediately".Here is an example of my SAP system "KAL":
   


2. On "General" tab make sure to enable all cluster nodes as "Preferred Owners". (all checkboxes must be activated). Here is an example of my SAP system "KAL":
   
   
   Remark:
   It is not necessary to enable the preferred owners on two-node clusters!
   Set in on more than two cluster nodes.

Question: The new ERS is great! Can I use it with older NetWeaver versions?

Answer:  No. The new ERS can only be used in conjunction with the new Enqueue Server 2. Both can be used as of NetWeaver 7.52 - or higher.

 

Question: I am confused. My ASCS instance was automatically moved to another cluster node. What is the root cause for this?

Answer: Please check the ERS cluster group configuration! If you didn't maintain the preferred owner list correctly, then the Failover Cluster may chose the ASCS cluster group to be moved.

Anyway, we found at least two configurations where everything was configured correctly, but the ASCS cluster group was used by the cluster for failover! The AntiAffinity cluster feature is not nicely documented by Microsoft. The GUID of the cluster group with the lowest value will be used for failover.

Here is how it works 100% correct:

1. Identify the two cluster groups. In this example I use the groups for SAP System "KAL", therefore the cluster groups are named:SAP KAL
   SAP KAL ERS


2. Open Windows Registry editor and navigate to HKLM\Cluster\Groups.SAP KAL:
   
   SAP KAL ERS:
   The GUID of the ASCS cluster group "SAP KAL" is less than the GUID of "SAP KAL ERS":GUID of ASCS starts with 9c...., ERS b4...
   Hexadecimal 9c is less than b4.
   
   The cluster will maybe use ASCS cluster group for the failback, even if you have not configured this! The AntiAffinity works this way.
   
   Important:
   Do not try to change anything here!


3. Create two new, empty cluster groups:
   


4. Add a generic application cluster resource and use "notepad.exe" for the generic app in both cluster groups. (this is just temporary. Without a resource, the cluster will not generate a GUID for the group).


5. Open Registry editor again and identify the cluster group with the lower GUID.Let's assume, the first role's GUID is starting with 68.
   Let's assume, the second role's GUID is starting with 6a.
   The GUID "68.." is less than "6a.." therefore, we use the lower GUID cluster group for the ERS instance!


6. Move all cluster resources from "SAP KAL ERS" to "New Role".


7. Move all cluster resources from "SAP KAL" to "New Role (2)".


8. Delete empty cluster groups "SAP KAL ERS" and  "SAP KAL".


9. Rename cluster group "New Role" to "SAP KAL ERS".


10. Rename cluster group "New Role (2)" to "SAP KAL".


11. Set the AntiAffinity again:(Get-ClusterGroup -Name "SAP KAL").AntiAffinityClassNames =@("SAP KAL Affinity")
    (Get-ClusterGroup -Name "SAP KAL ERS").AntiAffinityClassNames =@("SAP KAL Affinity")


12. Test Failover ...