Moving Resource Groups at HACMP 5.1

Answer

Priority Override Location, (POL), is a new feature introduced in HACMP 5.1. The purpose of this document is to highlight the feature and clarify how using this function may override the expected failover behavior. Being aware of this option when moving resource groups via the HACMP menus, especially in Cascading without failback or rotating configurations, will assist administrators in removing the sticky bit, POL, and resetting the cluster to its original failover behavior.

This document applies to AIX versions 5.1 and 5.2.

Procedure

Enter the SMIT fastpath:

1. smitty hacmp
2. Select Cluster System Management.
3. Select Resource Group & Application Managment.
4. Select Move a Resource Group.

   When using SMIT to move a resource group, there are two available selections:

   1. Restore_Node_Priority_Order
   2. Choose a specific node from the list

Restore_Node_Priority_Order

If you select Restore_Node_Priority_Order, the resource group moves to the highest priority node currently available. This selection also removes any persistent priority override locations that were previously set for the resource group. It also restores the node priority order for the resource group, so that the resource group moves to the highest priority node currently available.

NOTE: The Restore_Node_Priority_Order is only available for non-concurrent resource groups.

Choose a specific node from the list

If you select a specific destination node, this will set a priority override location to the node to which the resource group will be moved. The resource group remains on this node if a higher priority node joins the cluster. In a cascading without failback environment, this will basically mean that if your resource group is sitting on the standby node and you specifically select the primary node (instead of the restore_node_priority) to move the resource group back, you will set the persistent attribute for that resource group to always be on the primary node.

Unless you specifically select Restore_Node_Priority_Order at some point, or reboot (assuming you took the default of false for the persist across a cluster reboot option), you will have disabled the cascading without failback option, since every time you reintegrate the primary node it will pull the resource group back.

The behavior is similar in a rotating configuration. If you move a resource group by selecting the node name, you bind the resource group to that target node if it is up. You could run into a situation where the node that the resource group is bound to is reintegrated back into the cluster and it pulls the resource group back to itself. This does not follow the normal rotating environment behavior and should therefore be considered when moving a resource group.

When using SMIT panels to move a resource group, you will also notice a Persist across Cluster Reboot option. If you leave this flag to the default (false), the destination node that you specified does not become a persistent priority override location for the resource group, and the resource group falls back to its default behavior after you stop and restart the cluster services on all nodes (cluster reboot). If you set this flag to true, the destination node that you specified becomes a persistent priority override location for this resource group. That is, once the resource group is moved to the specified destination node, it stays on that node after a cluster reboot.

NOTE: If you accidentally moved a resource group back to the primary node by selecting the node name and not the Restore_Node_Priority_Order option, you can reset the persistent priority override location by running another move and selecting the Restore option instead. If the resource group is already on the higher priority node, it will only clear the persistent bind and reset the behavior back to what it should be.

When the POL bit is set, it is stored in the following file:

     /usr/es/sbin/cluster/etc/clpol