In the case where the ASCS instance is running ENSAv2, the ERS instance is running ERSv2, and the hierarchies have been extended to the same systems in a cluster with three or more nodes, the ASCS and ERS resource hierarchies can be forced to attempt to avoid each other on switchover and failover by using special “hierarchy avoidance” generic application resources. Note: These hierarchy avoidance resources should not be used in an ENSAv1/ERSv1 configuration or in a 2 node cluster. The following is a 3 node cluster with the “hierarchy avoidance” resources configured:
To create the avoidance terminal leaf the utility requires 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. The terminal leaf nodes for the previous example were created by the command:
/opt/LifeKeeper/bin/create_terminal_leaf SAP-SHC_ASCS10 SAP-SHC_ERS20
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:
- The node is not responding.
- LifeKeeper is not running on the node.
- 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:
- “ignore_avoidance_leaf” – will disable the avoidance leaf checking for any resource, aka the avoidance leaf will come in-service at all times.
- “ignore_<tag>” – will disable checking the particular <tag> 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.
Select “Create Resource Hierarchy” by right clicking on the server icon.
Select the Generic Application recovery kit and click on Next.
Enter for the Restore script “/opt/LifeKeeper/lkadm/bin/avoid_restore” and click Next.
Enter for the Remove script “/bin/true” and click Next.
There is no quickCheck script needed, leave the field blank and click Next.
Fill in the “Application Info” with the tag name for the avoidance resource that will be created for the other hierarchy. For this example, “avoid_app1” and click Next.
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:
Post your comment on this topic.