Enforcing ASCS/ERS Avoidance Behavior When Using ENSA2/ERSv2

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-EXM_ASCS02 SAP-EXM_ERS12

The terminal leaf node has now been attached:

The avoid_SAP-EXM_ERS12 resource will not allow the SAP-EXM_ASCS02 hierarchy to come in-service on a node if the avoid_SAP-EXM_ASCS02 resource (in the SAP-EXM_ERS12 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.

*NOTE: The flags will not affect the SAP quickCheck from migrating ERS when it detects it is running on ASCS. The flag “sap_no_ers_relocation_<tag>” will disable quickCheck from relocating ERS where <tag> is the ERS resource tag.

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: