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.
Without this policy, when a monitored resource in the administrative domain is deleted on any node in the administrative domain, the global status of the monitored resource changes to *FAILED. This indicates that the resource has been deleted on at least one node in the administrative domain, but still may need to be deleted from other nodes.
| 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 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 policies. |
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. |
...
PowerHA policies for administrative domain resources contain policy qualifiers designated as resource types (RSCTYPE). Supported resource types and the associated policy values are listed in the table below:
Policy Qualifier | Policy Value |
|---|---|
RSCTYPE(*ALL) | LIB(*ALL) LIB(NAME1 NAME2 …) |
RSCTYPE(*ASPDEV) | *BLANK |
RSCTYPE(*AUTL) | *BLANK |
RSCTYPE(*CLS) | LIB(*ALL) LIB(NAME1 NAME2 …) |
RSCTYPE(*ENVVAR) | *BLANK |
RSCTYPE(*ETHLIN) | *BLANK |
RSCTYPE(*JOBD) | LIB(*ALL) LIB(NAME1 NAME2 …) |
RSCTYPE(*OPTDEV) | *BLANK |
RSCTYPE(*PRTDEV) | *BLANK |
RSCTYPE(*SBSD) | LIB(*ALL) LIB(NAME1 NAME2 …) |
RSCTYPE(*TAPDEV) | *BLANK |
RSCTYPE(*USRPRF) | *BLANK |
Policy value definitions
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:
|
...
Example 1 - Default Policies Created by PowerHA
PowerHA now automatically creates default policies when CFGPCY(*YES) is specified on the Create Cluster Admin Domain (CRTCAD) command. The following lists the example commands to add the same policies in an administrative domain, ADMDMN:
...
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. |
Example 2 - Changing the resource type for an existing policy
The resource type for an existing policy cannot be changed. Instead, the policy must be removed and a new policy added. For
In this example, if a policy was added for *ALL resource types and the desire is to change the policy so that it is only for user profiles, the following commands would be required for administrative domain ADMDMN.Existing Policyyou have an existing QCST_AD_DELETE policy that applies to *ALL resource types:
Policy Name | Policy Domain | Policy Qualifier | Policy Value |
|---|---|---|---|
QCST_AD_DELETE | ADMDMN | RSCTYPE(*ALL) | LIB(*ALL) |
If you want to change it to apply to only user profiles and authorization lists, you need to remove the existing policy and add the new policies:
| Code Block |
|---|
ADDHAPCY PCY(QCST_AD_DELETE) PCYDMN(ADMDMN) QUAL('RSCTYPE(*ALLUSRPRF)') VALUE('LIB(*ALL)') |
Changing Policy:
| Code Block |
|---|
RMVHAPCYBLANK) ADDHAPCY PCY(QCST_AD_DELETE) PCYDMN(ADMDMN) QUAL('RSCTYPE(*ALLAUTL)') ADDHAPCYVALUE(*BLANK) RMVHAPCY PCY(QCST_AD_DELETE) PCYDMN(ADMDMN) QUAL('RSCTYPE(*USRPRFALL)') VALUE(*BLANK) |
The above commands add new policies specific to user profiles and authorization lists and then remove the existing policy for all resource types and add a new policy specific to user profiles.
| 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. |