ERSv2 is intended to be active (in-service) on a node in the cluster where the ASCS resource is not active. The ERS quickCheck will automatically transfer the ERS hierarchy if ERS and ASCS are active on the same node and another node is available. To avoid getting into the situation where ASCS and ERS are both active (in-service) on the same node after a switchover or failover, a gen/app terminal leaf resource can be created to automatically route the in-service to a node where the corresponding resource hierarchy is not active (in-service). To facilitate creating this terminal leaf node a new utility is provided, /opt/LifeKeeper/bin/create_terminal_leaf (1M).

To create the avoidance terminal leaf the utility takes two parameters, the ASCS and ERS hierarchy root resource tags. The two hierarchies should be fully extended to all nodes in the cluster and in-service on a node in the cluster. It does not require that the hierarchies be in-service on the node where the utility is run as long as the utility is run on a node in the cluster. The terminal leaf node will be named “avoid_<tag>” where tag is the appropriate root node to be avoided. The terminal leaf node will be attached as a child dependency on each branch of the hierarchy.

For example, in a configuration with SAP-EXM_ASCS02 and SAP-EXM_ERS12 as the root nodes:

The appropriate terminal leaf nodes are created by running /opt/LifeKeeper/bin/create_terminal_leaf SAP-SHC_ASCS10 SAP-SHC_ERS20

The terminal leaf node has now been attached:

The avoid_SAP-SHC_ERS20 resource will not allow the SAP-SHC_ASCS10 hierarchy to come in-service on a node if the avoid_SAP-SHC_ASCS10 resource (in the SAP-SHC_ERS20 hierarchy) is in-service on that node and there is another viable node available in the cluster. A node is NOT a viable option when:

  1. The node is not responding.
  2. LifeKeeper is not running on the node.
  3. A local recovery has failed on the node. This is determined by checking the output of /opt/LifeKeeper/bin/flg_list for the flag ‘!volatile!recover_fail_<tag>’.

The avoidance leaf can be disabled on a particular system by creating the flag:

  1. “ignore_avoidance_leaf” – will disable the avoidance leaf checking for any resource, aka the avoidance leaf will come in-service at all times.
  2. “ignore_<tag>” – will disable the particular so that it will always come in-service but other avoidance leafs will still avoid in-service.

Creating Avoidance Terminal Leaf Node Using the GUI

The avoidance terminal leaf node is a gen/app resource that can be created using the GUI. The restore script for the avoidance terminal leaf is ‘/opt/LifeKeeper/lkadm/bin/avoid_restore’. The remove script should be ‘/bin/true’. There is no quickCheck script. The info field should be the name of the tag to avoid.

For example, there are two resources, app1 and app2, that you want to be on different nodes when possible. You can create two gen/app resources, “avoid_app1” and “avoid_app2”. The ‘info’ field for avoid_app1 would have ‘avoid_app2’. The ‘info’ field for avoid_app2 would have ‘avoid_app1’. The ‘avoid_app2’ is a dependent child resource to ‘app1’ and ‘avoid_app1’ is a child resource to ‘app2’. Note: The tag name is not required to be ‘avoid_<tag>’ but this makes it clear what the resource is doing.

After creating ‘avoid_app2’ extend it to all nodes with the same priorities that app1 has.

Then select the ‘app1’ resource and create a child dependency with ‘avoid_app2’.

After creating the avoid_app1 resource similarly the hierarchy will look like:


Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.

Post your comment on this topic.

Post Comment