Cluster Version

Terminology for Cluster Version

Cluster version. The cluster version identifies the communication level of the nodes in the cluster, the ability of a node to join the cluster and the ability of the cluster to support new function. It is composed of two parts, the version and the modification level. There are two representations of the cluster version, Current cluster version and Potential node version.

Current cluster version. The version at which the nodes in the cluster are actively communicating with each other. This value in conjunction with the Potential node version determines which nodes can join in the cluster. This value also determines the cluster's ability to use new functions supported by the node's potential node version. It is set when the cluster is created and can be changed by the Adjust Cluster Version (QcstAdjustClusterVersion) API.

Modification level. The modification level further identifies the version at which the nodes in the cluster communicate. It is updated when code changes that impact the communication between the cluster nodes are applied.

Potential node version. The version at which the node is capable of communicating with the other nodes in the cluster. This is the value associated with the cluster code installed on the node. It will be used to determine if the node can join a cluster. If communications have not yet been established with the node (status of New), then the potential node version will be reported as 0.

Version Restrictions

A cluster can be composed of cluster nodes that are at different cluster versions. There are, however, restrictions that are enforced:

New cluster version function is not available until all cluster nodes are at the new cluster version. The current cluster version must be equal to the new functions version. This implies the potential node version of all the nodes must be at the same version. For example, assume new function is provided in cluster version 2. The new function of cluster version 2 cannot be used if the current cluster version equals 1. The current cluster version cannot be adjusted to the new level until all cluster nodes are upgraded to version 2.
If N is the current cluster version, only nodes with potential node version of N and N+1 can join the cluster. N is defined when the cluster is created. This will either be the potential node version of the node that originated the create cluster, or the potential node version previous to the node that originated the create cluster request. For example if it is desired to have cluster nodes with a previous potential node version join the cluster, one of the following must be done:
- Create the cluster on the node with the previous potential node version and add nodes with a higher potential node version to the cluster. The potential node version of the node being added must only be one version higher.
- Create the cluster on the node with the higher potential node version specifying a target cluster version of -1. Then add the nodes with a lower potential node version to the cluster. The nodes being added must only be one version difference.
A cluster will run protocols at the lowest potential node version (N) only. This is defined when the cluster is first created. N can either be set to the potential node version running on the node that originated the create request or one potential node version previous to the originator's potential node version.

When adjusting the cluster version, the version is adjusted to be one level greater than the current cluster version. All nodes must have the same potential cluster version before the cluster version can be adjusted.

Relationship of Cluster Version to IBM i VRMs

Cluster Version	IBM^® i VRM
7	V7R1M0
6	V6R1M0
5	V5R4M0
4	V5R3M0
3	V5R2M0
2	V5R1M0

How to View the Cluster Versions

The current cluster version and the potential node version are retrieveable through the List Cluster Information and the Retrieve Cluster Information APIs.

Summary of API Changes by Cluster Version

This documents the actual changes to the parameters on the APIs. The intent is to show which changes are allowed for the value of the current cluster version (CCV). The API changes for CCV 3 are only allowed on a V5R2M0 operating system or greater.

API changes allowed for CCV 6 (implies all of the below plus the following):

API name	Brief Description
Add Cluster Resource Group Device Entry	Allows additional configuration object types.
Change Cluster Resource Group	Support cross site mirroring other than geo mirror.
Change Cluster Resource Group Device Entry	Allows additional configuration object types.
Create Cluster Resource Group	Allows additional configuration object types. Support cross site mirroring other than geo mirror.
Remove Cluster Resource Group Device Entry	Allows additional configuration object types.
Cluster Resource Group Exit Program	Update EXTP0100 format to include configuration object vary status.

API changes allowed for CCV 5 (implies all of the below plus the following):

API name	Brief Description
CRG APIs
All Cluster Resource Group APIs	Support new Peer cluster resource group.
Create Cluster Resource Group	Update RGDC0200 format to add allow active takeover IP address.
List Cluster Resource Group Information	Update LRGI0200 format to return allow active takeover IP address.
Cluster Resource Group Exit Program	Update EXTP0100 format to include allow active takeover IP address.

API changes allowed for CCV 4 (implies all of the below plus the following):

API name	Brief Description
CRG APIs
Change Cluster Resource Group	Update RGDC0300 format to allow changes for site name and data port IP addresses when changing current recovery domain. Allow change to the new EXTP0200 format for cluster resource group exit program. Support a new value (-2 = no change) for the node role field.
Create Cluster Resource Group	Update RGDC0300 format to add site name and data port IP addresses to the recovery domain array. Add a new EXTP0200 format for cluster resource group exit program.
List Cluster Resource Group Information	Add a new LRGI0300 format to return site name and data port IP addresses for the recovery domain array.
Cluster Resource Group Exit Program	Support a new EXTP0200 format to include site name and data port IP addresses for the recovery domain array.

API changes allowed for CCV 3 (implies all of the below plus the following):

API name	Brief Description
CCTL APIs
All APIs that support the Request Information Queue (RIQ) parameter	The RIQ is not allowed to be in an independent auxiliary storage pool.
Start Cluster Node	If any node that had been previously but not currently ACTIVE starts itself, it will be able to rejoin the current active cluster if it can find other active node in the cluster, otherwise it will become a singleton cluster.
CRG APIs
Following objects: Request Information Queue (RIQ) Cluster Resource Group Exit Program Distribute Information Queue	The identified objects are not allowed to be in an independent auxiliary storage pool.
Add Cluster Resource Group Device Entry	Primary and secondary auxiliary storage pools can be specified in a resilient device cluster resource group. A new value is added to the configuration object online field. If the auxiliary storage pool has been created, the configuration object online value is validated. If a server takeover IP address is specified, it must exist on all nodes in the recovery domain if the cluster resource group is active. If a data base name is specified in the configuration object, it must be the same on all nodes in the recovery domain.
Add Node To Recovery Domain	If the node being added is the new primary node, all auxiliary storage group members must be specified as device entries in a resilient device cluster resource group. If a server takeover IP address is specified, it must exist on all nodes in the recovery domain if the cluster resource group is active. If a data base name is specified in the configuration object, it must be the same on all nodes in the recovery domain.
Change Cluster Resource Group	If the primary node is being changed in the current recovery domain, all auxiliary storage group members must be specified as device entries in a resilient device cluster resource group. New RGDC0110 format in support of failover message queue.
Change Cluster Resource Group Device Entry	A new value is added to the configuration object online field. If the auxiliary storage pool has been created, the configuration object online value is validated. If a server takeover IP address is specified, it must exist on all nodes in the recovery domain if the cluster resource group is active.
Create Cluster Resource Group	Primary and secondary auxiliary storage pools can be specified in a resilient device cluster resource group. A new value is added to the configuration object online field. If the auxiliary storage pool has been created, the configuration object online value is validated. If a data base name is specified in a configuration object, it must be the same on all nodes in the recovery domain. The server takeover IP address must be unique. It can only be associated with a Primary auxiliary storage pool.
Initiate Switchover	All auxiliary storage group members must be specified as device entries in a resilient device cluster resource group.
List Cluster Resource Group Information	Information about auxiliary storage pool device types is returned. Information about failover message queue is returned. Information about server takeover IP address is returned. The user space cannot be in an independent auxiliary storage pool.
Remove Cluster Resource Group Device Entry	If the cluster resource group is active, all members of an auxiliary storage pool group must be removed at the same time.
Remove Node From Recovery Domain	If the node being removed is the primary node, all auxiliary storage group members must be specified as device entries in a resilient device cluster resource group.
Start Cluster Resource Group	All auxiliary storage group members must be specified as device entries in a resilient device cluster resource group. The value of the configuration object online field must be correct for the type of auxiliary storage pool. If a data base name has been specified for a configuration object, it must be the same on all active nodes in the recovery domain. If a server takeover IP address is specified, it must exist on all nodes in the recovery domain.
Cluster Resource Group Exit Program	Format changes New action code - Verification Phase New action code - Failover Cancelled
Clustered Hash Table APIs
Connect Clustered Hash Table	New API
Disconnect Clustered Hash Table	New API
Generate Clustered Hash Table Key	New API
List Clustered Hash Table Keys	New API
Retrieve Clustered Hash Table Entry	New API
Store Clustered Hash Table Entry	New API

API changes allowed for CCV 2:

API name	Brief Description
CCTL APIs
Add Device Domain Entry	New API
Change Cluster Resource Services	New API
Change Cluster Node Entry	New format STSC0100 for changing node status from Partition to Failed.
List Device Domain Information	New API
Retrieve Cluster Information	New API
Remove Device Domain Entry	New API
CRG APIs
Add Cluster Resource Group Device Entry	New API
Change Cluster Resource Group	New RGDC0300 format in support of device cluster resource groups
Change Cluster Resource Group Device Entry	New API
Create Cluster Resource Group	New format RGDI0300 to support device cluster resource groups New configure takeover IP address option New distribute information queue field
Distribute Information	New API
List Cluster Resource Group Information	New format LRGI0200 for device cluster resource groups
Remove Cluster Resource Group Device Entry	New API

[ Back to top | Cluster APIs | APIs by category ]