IBM Support

Clustering Enhancements for IBM i 7.4

News


Abstract

Clustering enhancements for IBM i 7.4 allow for more automation of operations.

Content

You are in: IBM i Technology Updates > General IBM i Operating System > Clustering Enhancements for IBM i 7.4

New clustering policies allow for more automation of an administrative domain.  One can now automatically add resources to the cluster administrative domain when the resources are created or added on a node in the cluster administrative domain. Previously, each monitored resource entry (MRE) needed to be added manually after it was created.  One can now also automatically delete resources and remove them from the cluster administrative domain. Previously, a delete needed to be issued on each system in the cluster. Then the administrative domain would show the resource as Failed and changes to the resource would no longer propagate.

The QCST_AD_CREATE policy tells the Administrative Domain which resource types should be automatically added to Administrative Domain when the user creates the resource. If the QCST_AD_CREATE policy is used, the resource can automatically be added to Administrative Domain when a resource is created, This will then create the resource on all nodes in the Administrative Domain.

The QCST_AD_DELETE policy tells the Administrative Domain which resources should be automatically deleted.  If the QCST_AD_DELETE policy is used, the resource can automatically be removed on all nodes in the Administrative Domain when a resource is deleted on any node in the Administrative Domain and then the Administrative Domain will  remove the MRE.

See the IBM i Knowledge Center topic Cluster Policy APIs for more details.

There are enhancements to the behavior of restore handling in a cluster administrative domain to honor the restored values.  Previously, after a restore the admin domain would essentially undo the restore operation.  The new QCST_AD_RESTORE policy tells the Administrative Domain that restore operations should be honored for the specified resources.

The default behavior for a specified failover event when the primary node fails in a cluster resource group (CRG) is now to ‘cancel failover’.   Previously, a failing node would vary off independent auxiliary storage pools (IASPs) and the recovery domain was reordered on active nodes if the failover was cancelled.  The new Cancel failover policy is QCST_CRG_CANCEL_FAILOVER.  This will allow the user to cleanly perform a manual failover later. 

The new Cluster Resource Group (CRG) Container allows for management of a group of CRGs as a single entity for the purposes of operations.

An iASP may now be specified in more than one CRG.  This function is especially useful in  Db2 Mirror configurations.  Previously, an IASP was limited to a single CRG.  When an IASP appears in more than one CRG, the CRG recovery domains must have no nodes in common.

Start Cluster Administrative Domain support is enhanced to allow specification of a source node. Previously, when resource changes were made to nodes in an inactive Admin Domain, multiple nodes could change the same resource and there was no coordination for multiple different changes to the same resource.

As is typical for Clustering functions in the base IBM i operating system,  many of these technologies have already been seamlessly integrated into the licensed program product IBM PowerHA SystemMirror for i.  See more information on the PowerHA SystemMirror for i website.

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Component":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"IBM i 7.4","Edition":"","Line of Business":{"code":"LOB57","label":"Power"}}]

Document Information

Modified date:
09 January 2020

UID

ibm11126881