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 |
---|---|
8 | V7R2M0 |
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 |
|
Change Cluster Resource Group |
|
Change Cluster Resource Group Device Entry |
|
Create Cluster Resource Group |
|
Remove Cluster Resource Group Device Entry |
|
Cluster Resource Group Exit Program |
|
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 |
|
Create Cluster Resource Group |
|
List Cluster Resource Group Information |
|
Cluster Resource Group Exit Program |
|
API changes allowed for CCV 4 (implies all of the below plus the following):
API name | Brief Description |
---|---|
CRG APIs | |
Change Cluster Resource Group |
|
Create Cluster Resource Group |
|
List Cluster Resource Group Information |
|
Cluster Resource Group Exit Program |
|
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:
|
The identified objects are not allowed to be in an independent auxiliary storage pool. |
Add Cluster Resource Group Device Entry |
|
Add Node To Recovery Domain |
|
Change Cluster Resource Group |
|
Change Cluster Resource Group Device Entry |
|
Create Cluster Resource Group |
|
Initiate Switchover |
|
List Cluster Resource Group Information |
|
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 |
|
Start Cluster Resource Group |
|
Cluster Resource Group Exit Program |
|
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 |
|
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 ]