ERS Resource Types in LifeKeeper

*IMPORTANT: In keeping with industry best practices and announced with the release of v9.6.2, beginning with v9.7.0 SIOS will no longer support new or existing configurations with NFS servers/clients on the same nodes as the SAP services when setting up an SAP system (also known as “loopback configuration”).  Instead, we require using alternate configurations such as:
• EFS in AWS
• Azure Premium File Shares with NFS
• Google NFS Share
• NFS as separate cluster

*Important: Please see the SAP Recovery Kit – Known Issues / Restrictions

The design and implementation of the ERS resource type was modified in LifeKeeper 9.4.0. This page describes the differences between the implementation prior to version 9.4.0 and the implementation in versions 9.4.0 and later, how to determine which version exists on your system, and how to upgrade to the new resource type.

ERS Resources Prior to LifeKeeper 9.4.0

In versions of LifeKeeper prior to 9.4.0, the ERS resource was designed to sit at the top of an SAP hierarchy with a dependency on the Central Services (ASCS/SCS) resource that it provides lock table redundancy for.

The behavior of this resource was designed such that it would start the ERS instance on the backup node (where the ERS resource was listed as Standby in the LifeKeeper GUI). Upon switchover or failover of the SAP hierarchy, the ASCS/SCS instance would be started on the backup node and would obtain the backup copy of the lock table (i.e., the replication table) from shared memory on that system. Once the enqueue server successfully obtained the lock table, it would send a signal to notify the ERS instance to terminate itself. Once the ERS resource became Active (ISP) in LifeKeeper on the backup node, the ERS instance would be started on the original primary node when it became available. At that point the replication server would reconnect to the enqueue server and resume lock table replication. When the ERS instance is running on the backup node the LifeKeeper GUI status will change from ‘StandBy’ to ‘ERS Running’.

ERS Resources in LifeKeeper 9.4.0 and Later

In LifeKeeper 9.4.0 and later, the ERS resource was redesigned to operate in its own independent hierarchy.

ERSv1 Resource in an Independent Hierarchy

ERSv2 Resource in an Independent Hierarchy with Virtual IP and Highly Available Dependent Filesystem

This newer ERS resource design supports ERSv1 instances in two-node clusters and ERSv2 instances in clusters with any number of nodes. When using this resource type, the ERS instance will be started on the same node where the LifeKeeper is currently Active (ISP). The design change was made to facilitate the ability for an ERSv2 hierarchy (including its dependent virtual IP and filesystem resources) to failover independently of its corresponding Central Services resource hierarchy.

In order to attempt to keep the ERS resource from being Active (ISP) on the same node as its corresponding Central Services resource, this newer ERS resource type will check during each quickCheck interval (default: two minutes) whether:

1. The ERS resource is Active on the same node as its corresponding Central Services resource,
2. The lock table replication is in-sync between the enqueue server and the replication server, and
3. There is a different node available in the cluster that all resources in the ERS hierarchy could successfully relocate to.

If all three of these conditions are met, LifeKeeper will automatically relocate the ERS hierarchy to a different cluster node in order to provide redundancy of the enqueue server lock table data across cluster nodes. This automatic relocation behavior can be disabled by setting the flag ‘sap_no_ers_relocation_<ERS Tag>’ in LifeKeeper. This can be accomplished with a command similar to the following (where SAP-EXM_ERS12 is the example tag for the ERS resource):

/opt/LifeKeeper/bin/flg_create -f
“sap_no_ers_relocation_SAP-EXM_ERS12”

Creating this flag will not disable failover due to a failed local recovery of the ERS instance.

Note when using NFS: Since this design eliminates the LifeKeeper dependency of the ERS resource on the sapmnt filesystem, it is important to make appropriate use of the tunable value SAP_NFS_CHECK_DIRS to help prevent action scripts from hanging due to the sapmnt NFS share being inaccessible. See NFS Considerations for more details.

Which ERS Resource Type Do I Have in My Hierarchy?

If you are not sure in which version of LifeKeeper your existing ERS resource was created, run the following command (replacing <ERS Tag> with the tag name of your ERS resource):

/opt/LifeKeeper/bin/ins_list -f: -t <ERS Tag> | cut -d: -f6

The output of this command should be similar to:

EXMERS12sap2/sapmntFULLFULL5

• If the last digit in the output is 2, then this resource was created in LifeKeeper 9.3.2 or earlier. This type of resource may only be used to represent an ERSv1 instance in a two-node cluster and should sit at the top of the SAP hierarchy with a dependency on its corresponding Central Services (ASCS/SCS) instance below it. See the Upgrading the ERS Resource Type section below for instructions on how to switch to the newer design that operates in an independent hierarchy.

• If the last digit in the output is 5, then this resource was created in LifeKeeper 9.4.0 or later. This type of resource can be used to represent either an ERSv1 instance in a two-node cluster or an ERSv2 instance in a cluster with any number of nodes. It should operate in a hierarchy independent of its corresponding Central Services resource.

Upgrading the ERS Resource Type

*This example is showing NFS loopback but the configuration should be reimplemented to avoid the loopback configuration.

To upgrade to the newer ERS resource type in LifeKeeper 9.4.0 or later, complete the following steps.

1. Before attempting the upgrade process, create a backup of your LifeKeeper hierarchies on all cluster nodes by running the command:

• If you make a mistake at any point, the saved hierarchy configuration can be restored by stopping LifeKeeper on all nodes and running the command:

2. Right-click the ERS resource in the LifeKeeper hierarchy panel and select Delete Dependency…

3. Delete all dependencies of the ERS resource. You may need to select Delete Dependency… multiple times in order to delete all dependencies. When you are finished, the ERS resource should exist in a hierarchy by itself with no child dependencies and no other resources dependent on it, as shown in the following image.

4. Right-click the ERS resource in the LifeKeeper hierarchy panel and select Delete Resource Hierarchy… Select any server as the Target Server and click Next. Click Delete to delete the ERS resource on all nodes. Warning: If you did not successfully delete all dependencies between the ERS resource and other resources in the SAP hierarchy in the previous step, then this step could delete your entire SAP hierarchy.

5. Once the ERS resource has been successfully deleted on all nodes, follow the instructions in the “Create the ERS Resource” section in SAP Installation → Creating an SAP Hierarchy to create a new ERS resource and extend it to the desired cluster nodes.