Compartilhar via

Version Compatibility

  • Artigo

To allow for rolling upgrades and backward compatibility, failover clusters allow a certain degree of "mixed mode" clustering; that is, situations in which different cluster nodes are running different versions of the Cluster service. This section describes how the cluster determines whether a node can join a mixed-mode cluster.

Version Numbers

A Cluster service version number is composed of two identifiers: a major version and a minor version.

  • The major version is an integer that identifies a particular release of the Cluster service. Note the following key points about the major version:

    • The major version does not correspond to operating system version numbers.
    • Nodes running different versions of the Cluster service are compatible only if the difference between their major versions is 1 or less.

  • The minor version is the build number of the Cluster service.

To create a version number, the Cluster service combines the major and minor versions as follows:

Version = (major version << 16 ) | minor version

For example, if a release of the Cluster service has a major version of 2 and a minor version of 224. The version is therefore 131296 (0x000200E0). ClusAPI.h defines the CLUSTER_MAKE_VERSION, GET_MINOR_VERSION, and GET_MAJOR_VERSION macros for translating the different version types.

Note

Unless specifically qualified as "major" or "minor," any references to "version" or "version number" in this documentation refer to the combination of major and minor versions.

 

Node Version

Each node stores two Cluster service version numbers:

  • The currently installed version, stored in the NodeHighestVersion property.
  • The earliest version with which the currently installed version is compatible, stored in the NodeLowestVersion property.

These properties are read-only and are set when the Cluster service is installed on a node. They can be retrieved using ClusterNodeControl with the CLUSCTL_NODE_GET_RO_COMMON_PROPERTIES control code.

Note that, as a service, the Cluster service is installed as part of the operating system installation process. In other words, the Cluster service version will change only when a different version of Windows is installed.

Cluster Version

The cluster maintains two Cluster service version numbers, ClusterHighestVersion and ClusterLowestVersion. These numbers are based on the version restrictions of all active nodes, as follows:

ClusterHighestVersion = Min( all active nodes' NodeHighestVersion properties ) +/- mitigating factors
ClusterLowestVersion = Max( all active nodes' NodeLowestVersion properties ) +/- mitigating factors

Where "mitigating factors" involve differences in minor version. Cluster version numbers are dynamic and are recalculated every time a node joins or leaves the cluster. To obtain their current values, call GetClusterInformation and pass in a CLUSTERVERSIONINFO structure. The following structure members will contain version data:

ClusterVersionInfo.dwClusterHighestVersion = ClusterHighestVersion
ClusterVersionInfo.dwClusterLowestVersion = ClusterLowestVersion

When the cluster version changes, each resource DLL in the cluster is notified with the CLUSCTL_RESOURCE_CLUSTER_VERSION_CHANGED control code.

Joining

A node can join cluster only if one of the following is true:

  • NodeHighestVersion = ClusterHighestVersion
  • NodeLowestVersion = ClusterHighestVersion
  • NodeHighestVersion = ClusterLowestVersion.

Programming Considerations

In very rare cases, you may have an application or other resource that is restricted to specific nodes or versions of Windows. Version compatibility then becomes a concern in maintaining the availability of your resource. Note the following:

  • Version number generation and assignment, as well as join protocols, are automatic. There are no points of intervention from the API.
  • You can only detect version changes "after the fact." In other words, when you call GetClusterInformation or receive the CLUSCTL_RESOURCE_CLUSTER_VERSION_CHANGED control code in your resource DLL, the version change has already taken place.

For node- or version- dependent applications or resources, you may want to provide documentation or create private properties that communicate the restrictions to administrators.