Starting cluster services on a node with a resource group in the UNMANAGED state

Resource groups may be in the UNMANAGED state on a node if cluster services on that node have been stopped using the Unmanage resource groups option.

This Unmanage resource groups option causes PowerHA® SystemMirror® to stop providing high availability services to the resource group; that is, the resource groups will not fall over due to resource failures. This option is intended for temporary situations, such as when you want to upgrade PowerHA SystemMirror or perform maintenance without bringing your applications offline.

Starting cluster services on the node after it had been stopped with the resource group option set to UNMANAGED, therefore, puts any resource group that is in the UNMANAGED state on that node back to the state in which it was prior to being UNMANAGED. While bringing the resource group ONLINE from the UNMANAGED state, PowerHA SystemMirror checks every resource in the resource group to see whether it is active and activates it if it is found inactive. Thus, it is critical to configure the application monitors so that PowerHA SystemMirror can correctly detect a running application and so PowerHA SystemMirror does not try to start a second instance.

If you start cluster services on the node where the parent resource group is in an UNMANAGED state in a parent-and-child resource-group configuration that has different home nodes, the corresponding child resource group is not released and reacquired.

If you are using PowerHA SystemMirror Version 7.2.5, or later, after restarting the cluster services that is stopped by using the Unmanaged resource groups option, you can skip cluster resource processing by using the SKIP_EVENT_PROCESSING_MANAGE_MODE tunable. By default, the SKIP_EVENT_PROCESSING_MANAGE_MODE tunable is disabled and the initial configuration of cluster services that was set during cluster startup is preserved. If you enable the SKIP_EVENT_PROCESSING_MANAGE_MODE tunable, it restores the state of the cluster resource group to the previous state without disturbing the current state during the cluster restart operation. To enable the SKIP_EVENT_PROCESSING_MANAGE_MODE tunable, you must modify the cluster definition by using the clmgr commands. After you enable the SKIP_EVENT_PROCESSING_MANAGE_MODE tunable in the hacmp.out log file, the new forced option of the node_up events directs the node_up event to skip processing of the cluster resources.
Notes:
  • You can use the SKIP_EVENT_PROCESSING_MANAGE_MODE tunable only during restart of the cluster services after it is stopped by using the Unmanaged resource groups option.
  • If you use the SKIP_EVENT_PROCESSING_MANAGE_MODE tunable, any cluster resource processing is ignored after the cluster services are restarted. After restarting the node, if the cluster resource processing is ignored, you must ensure that current state of the cluster resource group is not changed when the node is stopped by using the Unmanage resource groups option. If the current state of the cluster resource group is changed when cluster services are in the UNMANAGED state, you must manually restore the cluster resources to its previous state once the cluster services are started.

The purpose of the following steps is to give you the option to bring the resource group online on a different node if it is in the UNMANAGED state on a specified node because the current node might be down for prolonged maintenance. Regardless of the state of the node, the cluster manager might be in a FORCED DOWN state on that node, or the system might be down, or might have been rebooted. Bringing the resource group to the OFFLINE state on this node does not affect the state of its resources. If the resource group is online on this node, it needs to be brought offline manually if it is being brought to the OFFLINE state.

In cases where you want to bring a resource group from an UNMANAGED state to an ONLINE state on a different node (because the node that was stopped by using UNMANAGED option is unavailable), you should do the following:

  1. Bring the resource groups to the OFFLINE state using a user-requested rg-move SMIT panel. Note that during this operation, PowerHA SystemMirror will not stop any resources as the node that originally hosted the resource group is no longer available.
  2. Ensure that all the resources that are configured in the resource group are OFFLINE, including the application, if any.
  3. Bring the resource groups from their OFFLINE state to the ONLINE state, just as was necessary in previous releases using the resource group migration utility clRGmove or the SMIT option.