Cluster version

A cluster version represents the level of function available on the cluster.

Versioning is a technique that allows the cluster to contain systems at multiple release levels and fully interoperate by determining the communications protocol level to be used. If you are using a cluster that will contain systems of varying release levels, see Multiple-release clusters.

There are actually two cluster versions:

Potential cluster version: Represents the most advanced level of cluster function available for a given node. This is the version at which the node is capable of communicating with the other cluster nodes.
Current cluster version: Represents the version currently being used for all cluster operations. This is the version of communications between the nodes in the cluster.

The potential cluster version is incremented on every operating system release which has significant new clustering functionality not available in earlier cluster versions. If the current cluster version is less than the potential cluster version, then that function cannot be used since some nodes cannot recognize or process the request. To take advantage of such new function, every system in the cluster needs to be at the same potential cluster version and the current cluster version must also be set to that level.

When a node attempts to join a cluster, its potential cluster version is compared against the current cluster version. If the value of the potential cluster version is not the same as current (N) or not equal to the next version level (N+1), then the node is not allowed to join the cluster. Note that the current cluster version is initially set by the first node defined in the cluster using the value specified on the create cluster API or command.

Start of change For example if you want V5R3 nodes to exist with V5R4 nodes you can do one of the following: End of change

Create the cluster on a V5R3 system and add in the V5R4 node.
Create the cluster on a V5R4 system specifying to allow previous nodes to be added to the cluster, then add V5R3 systems to the cluster.

In a multiple-release cluster, cluster protocols will always be run at the lowest node release level, the current cluster version. 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 cluster request or one cluster version previous to the originators potential node version. Nodes in the cluster can differ by at most one cluster version level.

Once all systems in the cluster have been upgraded to the next release, the cluster version can be upgraded so that new functions are available. This can be accomplished by adjusting the cluster version.

Attention: If the new version of the operating system is not equal or one version higher to the current cluster version, then the cluster node will fail when it is restarted. To recover from this situation, the node must be deleted and recreated with the correct version.

Attention: Start of change

When you are using switchable independent disk pools in your cluster, there are restrictions in performing switchover between releases. You need to switch a previous release independent disk pool to a system running the current release of i5/OS™ and make it available. After it is made available on the system running the current release of i5/OS, its internal contents are changed and it cannot be made available to the previous release system again. End of change

Read more on cluster versions in the Cluster APIs documentation, including information about restrictions and how cluster versions correspond to i5/OS releases.