The QCST_AD_DELETE policy automates and simplifies management of the removal of monitored resources and their respective MREs from a cluster. If an administrative domain uses the QCST_AD_DELETE policy with its monitored resources, then a resource deleted on one node of the cluster administrative domain can be deleted on all other active cluster nodes. Once the resource has been deleted on all cluster nodes, the MRE for the resource is also removed from the cluster administrative domain.
...
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Understanding Administrative Domain’s Peer Architecture The administrative domain is a peer architecture. This means that there is no concept of a primary node as far as the administrative domain is concerned, ensuring changes are synchronized in all directions regardless of which node a change occurs on. The QCST_AD_DELETE policy follows the peer-based architecture in the administrative domain. This means that a delete of any resource that is matches a QCST_AD_DELETE policy and is monitored by the administrative domain will be deleted across all nodes in the administrative domain. While this policy can simplify management, this behavior can lead to unexpected deletion of resources on a production system in certain instances. The following example illustrates this behavior and the importance of selecting the correct values for this policy in your environment:
Other ways that this can happen are with conflicts between PowerHA policies and logical replication solutions where are both trying to manage the same resources. It is important to ensure that only one of the solutions is managing the resources to prevent conflicts. One common way to reduce the chances of unexpected interactions is to carefully decide on the resource types for this policy in your environment. As an example, some administrators prefer to limit use the QCST_AD_DELETE automation to select resources such as only user profiles (*USRPRF) or only user profiles (*USRPRF) and authorization lists (*AUTL). See example 2 below for an example of moving from a QCST_AD_DELETE policy that applies to all resources to a set of more restrictive policypolicies. |
Adding a PowerHA policy for administrative domain resources
...
The name of the administrative domain the policy will apply to.
The names of the resource type or types that the policy will create resource entries for.
| Info |
|---|
Note: Depending on the resource type, a list of libraries may be required for the policy. |
...
LIB(*ALL) indicates that the resource type can be created in any library. *BLANK indicating that the resource type does not require any library. LIB(NAME1 NAME2...) using only resources contained in the specified libraries.
| Note |
|---|
Important:
|
...
These policies specify that when any of the MRE types supported by this policy are deleted on any node in the administrative domain, the resource will be deleted from all other nodes in the administrative domain and removed from the administrative domain. If the cluster is inactive or partitioned at the time of the creation of the resource, the resource is deleted when clustering is started or the partition condition is resolved.
| Tip |
|---|
Tip: The CFGPCY(*YES) parameter on CRTCAD also adds policies of type QCST_AD_CREATE and QCST_AD_RESTORE. |
...
The above commands add new policies specific to user profiles and authorization lists and then remove the existing policy for all resource types.
| Tip |
|---|
Tip: In this example, the new policies for user profiles and authorization lists are added first, followed by the removal of the more general policy. This is done so that there is not a period of time where there is no policy that applies to user profiles or authorization lists. If the policy for all was removed first, then a user profile was deleted before the new policy was added, the behavior would be as if there was no policy defined. |