1. Technical Field
The present invention relates to compatibility between a server node and a shared resource. More specifically, the invention relates to a method and system to efficiently determine compatibility of the server node and the shared resource prior to cluster membership.
2. Description of the Prior Art
A node could include a computer running single or multiple operating system instances. Each node in a computing environment includes a network interface that enables the node to communicate in a local area network. A cluster includes a set of one or more nodes coordinating access to a set of shared storage subsystems typically through a storage area network. The shared storage subsystem may include a plurality of storage media.
Prior to joining a cluster, it is important for the node to determine it's compatibility with other members of the cluster, as well as compatibility with data stored in the storage subsystem. For example, it is known in the art to conduct upgrades to software operating on a server, as well as converting data to ensure compatibility with the upgrade of the software. Prior art systems allow server nodes to join the cluster prior to determining software compatibility between the software operating on the joining server and data stored within an area of the storage area network assigned to the cluster.
There are several shortcomings associated with the prior art method for cluster membership. If it is determined that the new server node is incompatible with the data, either at steps (60) or (70), the server node is denied access. However, this is not indicative as to whether the server node has already initiated a process that it is now unable to complete because of an incompatibility that may have developed subsequent to the initial access of the data. This may result in wasting of time by starting a process on a portion of data that cannot be completed. Alternatively, the server node may have started a process and may be unable to reverse the work already completed, which would result in corrupted data. Accordingly, the prior art system for determining server and shared resource compatibility is inefficient and unreliable in assuring compatibility between the server node and data within the shared resource.
There is therefore a need for a method and system to avoid initiating an action that would be prematurely terminated based upon incompatibility of a server node with a shared resource.
This invention comprises a method and system to determine compatibility between a server node and a shared resource.
In one aspect of the invention, a method is provided for controlling interoperability of members of a cluster. A version control record comprising all versions of each type of data structure in a shared resource is created. Software compatibility of a new cluster member with each data structure is validated, using the version control record, prior to a new cluster member joining the cluster.
In another aspect of the invention, a computer system is provided with at least two nodes adapted to operate in a computer cluster. A version control record is provided in a shared resource of the cluster. The version control record is inclusive of all versions of each type of data structure in the shared resource. In addition, a membership manager is provided to validate compatibility of a new cluster member with each data structure, with use of the version control record, prior to acceptance of the new cluster member.
In yet another aspect of the invention, an article is provided with a computer-readable signal-bearing medium. Means in the medium are provided for a version control record inclusive of each type of data structure in a shared resource. In addition, means in the medium are provided for validating compatibility of a new cluster member with each data structure in the shared resource, using the version control record, prior to joining the cluster.
Other features and advantages of this invention will become apparent from the following detailed description of the presently preferred embodiment of the invention, taken in conjunction with the accompanying drawings.
A summary of the data structure version of each type of persistent data item, known as a version control record, is retained in a known location in a storage area network assigned to a cluster of server nodes. The version control record organizes meta data, which is defined as data or information about other data. The version control record is accessible by all members of the cluster. Prior to joining the cluster, a server node may scan the version control record to expeditiously determine it's compatibility with data maintained in persistent storage for the cluster. Accordingly, the version control record enables a server node to determine if membership with the cluster is optimal based upon shared resource data compatibility prior to joining the cluster.
In a distributed computing system, multiple server nodes are in communication with a storage area network which functions as a shared resource for all of the server nodes. The storage area network may include a plurality of storage media. A version control system is implemented to insure that a server node requesting or considering membership in a cluster is compatible with the storage media of the storage area network assigned to the cluster, as well as the data structures within the storage media.
The version control system manages validation of compatibility of a requesting node prior to completion of the cluster membership process. One part of the version control system includes a disk header record which is maintained within each shared resource of the cluster. Each disk in the storage area network includes a disk header version associated therewith. The disk header record functions to organize and manage a storage area network with multiple storage disks and/or media. At an initial stage of cluster membership of a new server node, it is important to determine if the disk header of the master disk in the storage area network is compatible with the software operating on the requesting server node. Since the master disk houses a version control record of the version control system, it is important to determine if the requesting node is compatible with the disk header version of the master disk. Accordingly, the disk header version is determinative of accessibility of the requesting server node to the master disk of the storage area network.
As noted above, the version control system is comprised of two primary components, a disk header record and a version control record. In order to determine compatibility of a server node requesting membership in a cluster, a version control record in the form of a data structure is created to maintain information about the versions of all data structures within a shared resource of the cluster. The version control record is preferably maintained in non-volatile memory, and is available to all server nodes that are members of the cluster as well as any server node that wants to join the cluster. Each data structure in the shared resource is permanently assigned a position within the version control record. If the data structure becomes retired, the position for that data structure within the version control record remains. This prevents a future software version from using that position for a different data structure version. The misuse of a retired data structure position could lead to the older software version making an incorrect decision pertaining to incompatibility. Accordingly, the version control record maintains a master record of all data structures within the shared resource of a cluster.
In addition, the version control record maintains a version table of all versions of each data structure type in the shared resource of the cluster within the version control record. At the time of installation of the version control record in conjunction with the associated version table, each data structure type will have an initial assignment. A data structure may contain information about a file, such as it's size, creation time, owner, permission bits, and a version number associated with the operating system and/or software utilized at the time of creation. At such time as the format of this data structure changes, the associated version number in the version table will change as well. Accordingly, the version table will retain information for the data structure associated with both the version number at the time of creation, as well as the version number associated with the format change of the data structure.
When an upgrade to software operating on each of the server nodes is conducted, this process is uniform across all server nodes in the cluster. New versions of software introduce changes to one or more of the data structures in the area of the storage area network assigned to the cluster. At such time as the software upgrade is complete across each of the server nodes in the cluster, the version table will be updated to include any new versions of each data structure, while retaining the previous version of the data structure. The version table functions as a resource for a prior software version of the data structure if there should be any issues at a later time that arise between the software upgrade and the previous versions of data structures. Accordingly, the version table retains records of versions of the software used to create and/or edit the data structures of the shared resource.
At such time as all of the data structures retained in the shared resource are converted to a new version number, the version control record may cease referencing the original or previous version number of the data structure. A server node running a particular software version may determine whether any data conversion is necessary in order to migrate the system from a previous software version to the current software version by referencing the version table of the version control record. Accordingly, the version control record maintains a version table to reference each of the data structures in the shared resource and the version under which the associated data structure is maintained.
The version control record also maintains a node table referencing the software versions operating within the member server nodes of the cluster. This table assures that all nodes are running identical software versions when data conversion for an upgrade is commenced. The node table may be stored in persistent memory to allow consideration of both active and inactive server nodes. Accordingly, the node table may be utilized to manage upgrades to system resources for both active and inactive cluster members.
The version control system enables a server node to determine compatibility with shared resources in a cluster prior to joining the cluster. The system enables efficient use of resources to a joining member as well as existing cluster members. The information maintained in the version control system may be used to prevent an upgrade of data structures in the shared resource when all members of the cluster are not running compatible or identical software versions. In addition, a server node considering membership in the cluster has three opportunities to determine system compatibility prior to committing resources to joining the cluster. Accordingly, the version control system is a screening tool for cluster membership compatibility as well as a control mechanism for upgrades to system resources for existing cluster members.
It will be appreciated that, although specific embodiments of the invention have been described herein for purposes of illustration, various modifications may be made without departing from the spirit and scope of the invention. In particular, the shared resource may be in the form of a storage area network with a plurality of storage media, or it may be in the form of shared memory. Additionally, information in the version control system may be used by a system administrator as a summary of the versioning state of the persistent data. Also, in the event incompatibility is determined at any stage in the control system, a notification may not be provided to the system operator. A notification may be in the form of a report or a message detailing reasons for failure of the server node to join the cluster. Such a report may include detailing information pertaining to an area in which a server node may require an upgrade. Accordingly, the scope of protection of this invention is limited only by the following claims and their equivalents.