Cluster version
A cluster version represents the level of function available on the cluster.
Versioning is a technique that allows the cluster to contain nodes at multiple release levels and fully interoperate by determining the communications protocol level to be used.
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 IBM i 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 node 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+2), 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. 
For example if you want 5.4 nodes to exist with 6.1 nodes you can do one of the following:
- Create the cluster on a 5.4 node and add in the 6.1 node.
- Create the cluster on a 6.1 node specifying to allow previous nodes to be added to the cluster, then add 5.4 nodes 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 two cluster version level.
Once all nodes 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.
If the new version of the cluster
is not equal, one or two versions higher to the current cluster version,
then the cluster node will fail when it is restarted. To recover from
this situation, the cluster on that node must be deleted and the cluster version adjusted
before the node can be re-added to the cluster. When you are using independent auxiliary storage pools
(IASPs) in your cluster, there are restrictions in doing a switchover between releases. If an
independent disk pool is switched from a node running a previous release of IBM i to a node running the current release of IBM i, when it is made available on the node, its internal contents
are changed and it cannot be made available to the previous release node again. Read more on cluster versions in the Clusters APIs documentation, including information about restrictions and how cluster versions correspond to IBM i releases.