U.S. patent application number 13/610939 was filed with the patent office on 2014-03-13 for automated firmware voting to enable multi-enclosure federated systems.
This patent application is currently assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION. The applicant listed for this patent is Fred A. Bower, III, Shunrong Hu, William G. Pagan. Invention is credited to Fred A. Bower, III, Shunrong Hu, William G. Pagan.
Application Number | 20140075170 13/610939 |
Document ID | / |
Family ID | 50234605 |
Filed Date | 2014-03-13 |
United States Patent
Application |
20140075170 |
Kind Code |
A1 |
Bower, III; Fred A. ; et
al. |
March 13, 2014 |
AUTOMATED FIRMWARE VOTING TO ENABLE MULTI-ENCLOSURE FEDERATED
SYSTEMS
Abstract
One embodiment provides a method of initializing a federated
computer system from a fabric of nodes connected by a federated
interface. Each node casts a vote to the federated interface for a
candidate firmware version supported by the node casting the vote.
The candidate firmware version having received the greatest number
of votes is identified, and the computer system is initialized as a
federated system of the nodes that support the firmware version
identified as having received the greatest number of votes. A
process of iterative voting may be used to identify a greater
number of nodes supporting a compatible firmware version.
Inventors: |
Bower, III; Fred A.;
(Durham, NC) ; Hu; Shunrong; (Shanghai, CN)
; Pagan; William G.; (Durham, NC) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Bower, III; Fred A.
Hu; Shunrong
Pagan; William G. |
Durham
Shanghai
Durham |
NC
NC |
US
CN
US |
|
|
Assignee: |
INTERNATIONAL BUSINESS MACHINES
CORPORATION
Armonk
NY
|
Family ID: |
50234605 |
Appl. No.: |
13/610939 |
Filed: |
September 12, 2012 |
Current U.S.
Class: |
713/2 |
Current CPC
Class: |
H04L 67/34 20130101;
G06F 9/4401 20130101 |
Class at
Publication: |
713/2 |
International
Class: |
G06F 9/06 20060101
G06F009/06 |
Claims
1-17. (canceled)
18. A computer system for self-initializing as a federated system,
comprising: a plurality of nodes interconnected by a federated
interface to form a fabric, the federated interface comprising
high-speed links providing functional connections between nodes;
and each node comprising control logic for casting a vote to the
federated interface for a candidate firmware version supported by
the node casting the vote, identifying the candidate firmware
version receiving the greatest number of votes, and initializing
the computer system as a federated system including only the nodes
that support the firmware version identified as receiving the
greatest number of votes.
19. The computer system of claim 18, wherein the high-speed links
of the federated interface provide functional connections from each
node to every other node in the fabric.
20. The method of claim 18, further comprising: a plurality of
server enclosures, with each enclosure configured as a single node,
multiple nodes, or part of a node.
Description
BACKGROUND OF THE INVENTION
[0001] 1. Field of the Invention
[0002] The present disclosure relates to federated computer systems
and methods for initializing a federated computer system.
[0003] 2. Background of the Related Art
[0004] A data center is a facility where computer equipment and
related infrastructure are consolidated for centralized operation
and management. Computer equipment may be interconnected in a
datacenter to produce large, powerful computer systems that are
capable of storing and processing large amounts of data for
entities such as large corporations, web hosting services, and
Internet search engines. A data center may house any number of
racks, each capable of holding a large number of servers and
supporting equipment, such as switches, power supplies, network
communications interfaces, environmental controls, and security
devices. Servers and supporting equipment are typically housed in
rack-mounted, multi-server enclosures (e.g. a multi-blade chassis)
and arranged in a high-density configuration. This type of
arrangement uses space efficiently while providing physical access
to the equipment and enabling the circulation of cool air. As many
servers and rack-mounted enclosures as needed may be interconnected
to produce a system having the desired performance.
[0005] A federated computer system involves multiple nodes
interconnected to form a larger computer system. A federated
computer system also requires the use of multiple firmware images,
with one set of firmware per node. The multiple sets of firmware
are responsible for coordinating an initial sequencing of the
federated system. In order to properly coordinate this sequencing,
the sets of firmware must be compatible or match. Firmware for each
server or node in a federated computer system may be periodically
flash updated. When a node fails to be updated with its peers, such
as through user error or a firmware update process failure, the
system may no longer be able to initialize in the federated
configuration. The conventional response to such a failure is
either to simply stop the initialization and emit an error from all
nodes or to initialize each node as an independent system in a
non-federated configuration.
BRIEF SUMMARY OF THE INVENTION
[0006] A computer-implemented method is described for initializing
a federated computer system from a fabric of nodes connected by a
federated interconnect interface. In one embodiment, each node
casts a vote to the interconnect interface for a candidate firmware
version that is supported by the node casting the vote. The voting
results may be examined to identify the candidate firmware version
having received the greatest number of votes. The computer system
may be initialized as a federated computer system of the nodes that
support the firmware version identified as having received the
greatest number of votes. Programming code for performing the
method may be embodied in the form of computer usable program code
on a non-transient computer usable storage medium.
[0007] A computer system is also described, for self-initializing
as a federated system. A plurality of nodes is interconnected by a
federated interface to form a fabric. The federated interface
comprises high-speed links providing functional connections from
each node to every other node in the fabric. Each node comprises
control logic for casting a vote to the federated interface for a
candidate firmware version supported by the node casting the vote,
identifying the candidate firmware version receiving the greatest
number of votes, and initializing the computer system as a
federated system including only the nodes that support the firmware
version identified as receiving the greatest number of votes.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
[0008] FIG. 1 is a perspective view of a multi-enclosure computer
system that may be physically configured and initialized as a
federated computer system.
[0009] FIG. 2 is a schematic diagram of a computer system having
six nodes interconnected by a fabric comprising high-speed
links.
[0010] FIG. 3 is a flowchart generally outlining an example of a
method for initializing a federated computer system.
[0011] FIG. 4 is a flowchart outlining another method of
initializing one or more federated systems from a fabric of
interconnected nodes that support more than one firmware
version.
[0012] FIG. 5 is a diagram providing two examples of iterative
voting in a hypothetical six-node system.
DETAILED DESCRIPTION OF THE INVENTION
[0013] Systems and methods are disclosed for initializing a
federated computer system from among a plurality of nodes
interconnected on a federated interface, even when not all of the
nodes on the federated interface have compatible firmware versions.
For purposes of this disclosure, a node comprises any group of
compute resources to be initialized from a single firmware set
prior to federation. The minimum set of firmware elements necessary
to initialize the nodes as a federated system may differ in
different federated system architectures. For example, the Basic
Input-Output System (BIOS) firmware may need to be at the same
functional level, while the Ethernet firmware may not. The physical
packaging of the computer system may comprise a plurality of
hardware enclosures with physical connectors for interconnecting
the enclosures, typically using a set of system fabric cables. This
physical packaging is generally independent of the logical
construct of a node, other than that establishing the logical
connections between nodes relies on some sort of inter-enclosure
connection capability. Therefore, each enclosure may be configured
as a single node, multiple nodes, or part of a node.
[0014] Each node may be capable of supporting multiple different
firmware versions. The choice of firmware version used for
initialization determines which nodes may participate in the
federated system. In one application, a low-level wire protocol is
used to communicate firmware version information between nodes for
the purpose of identifying nodes having compatible sets of firmware
necessary for initialization of a federated system. "Compatible
sets of firmware" refers to the minimum set of firmware elements
that must be matched for federation to be supported. This approach
can be used to obtain the optimal configuration from the available
nodes, such as to obtain the largest-possible federated system in
terms of the number of nodes participating in the federated system.
A primary federated system may be determined according to a subset
of nodes that support the highest firmware version to have received
more than one vote. The remaining nodes may be used to create one
or more additional, smaller federated systems within their peer
groups that have compatible firmware versions. The nodes outside of
the primary federated system can alternatively be initialized in a
non-federated mode of operation and sent into a flash update
sequence per customer policy. By utilizing the low-level wire
protocol on federation interconnect links, no additional
configuration of management controllers or other external
communication and discovery mechanism is required. More
specifically, no external configuration and discovery of service
processor elements on the federated nodes is required to perform a
compatibility check during system initialization. This will allow
for immediate federated system initialization after making the
physical connections between nodes such as by connecting the system
fabric cables between enclosures.
[0015] A process of voting may be performed to arrive at a firmware
version supported by at least a subset of the available nodes
interconnected on the federated interface. In one embodiment, the
process of voting may be limited to a single round of voting
wherein each node broadcasts all supported firmware versions to the
federated interface. The nodes then collectively select an optimal
firmware version for initializing a federated system, such as the
version supported by the largest number of nodes. Optionally, the
logic for selecting the optimal firmware version may include
considerations for deciding between two firmware versions that are
supported by an equal number of nodes.
[0016] In another embodiment, the voting process may alternatively
include a sequence of two or more voting rounds. In a first voting
round, each node votes for the highest firmware version it
supports. In each subsequent voting round, a node may change its
vote based on the votes in the preceding round. In any given round
wherein more than one firmware version received a vote, the highest
firmware version and the next highest firmware version to each
receive at least one vote may be determined. Each node that voted
for the highest firmware version in the preceding voting round may
change its vote to the next highest firmware version, and the votes
of the other nodes are not changed. This process is performed
iteratively until a final voting round in which none of the votes
have changed. The primary federated system is then initialized from
the nodes voting for the highest firmware version to receive votes
in the final round. If all of the nodes voted unanimously in the
final voting round, the system is initialized as a fully federated
system. If the votes in the final voting round were not unanimous,
one or more additional federated system may be initialized from
another firmware version(s). Nodes not participating in the primary
federated system may alternatively be placed in a recovery/degraded
mode of operation to receive a flash update.
[0017] FIG. 1 is a perspective view of a multi-enclosure computer
system 10 that may be physically configured and initialized as a
federated computer system according to the principles disclosed
herein. By way of example, the computer system 10 in FIG. 1
includes a total of eight enclosures 20 mounted on two equipment
racks 12 with four enclosures 20 per rack 12, and with each
enclosure 20 receiving up to fourteen blade servers 22. As
understood in the art, each enclosure 20 may include support
modules 24 that provide shared resources to the servers within a
given enclosure, such as one or more management module 25, power
module 26, blower module 27, and switch module 28. The servers 22
and support modules 24 in each enclosure 20 may communicate
electrical power and data signals internally within the enclosure
over a midplane or backplane. The management module 25 may include
a management processor and firmware to manage the enclosure 20,
such as enforcing an enclosure power policy, monitoring
temperatures, generating system alerts, and other enclosure-level
systems management tasks. Each enclosure 20 also provides a
physical interface 30, which may reside on the management module
25, with any number of physical connectors 32 for making functional
connections between the server enclosures 20 using cables. The
federated interface refers to the physical interfaces 30 of the
nodes as connected by high-speed system fabric cables providing
high-speed links between nodes.
[0018] During initialization, the enclosures 20 may communicate
over the federated interface using a low-level wire protocol to
share firmware version information over a signal path via the links
between enclosures available prior to initializing the system. The
wire protocol in a federated system is typically proprietary in
nature, based upon the federation mechanism, which is also usually
proprietary. The basic stages of initialization are for each node
to initialize its hardware, then initialize the interconnect link
to other nodes in order to discover the system topology. The
initialization logic for the disclosed methods may reside in that
topology discovery process. After the population of peers is
determined, a signal to begin firmware signature voting would be
broadcast to the federated interface. The voting would then proceed
as a sequence of one or more voting rounds, with marker events to
signal the beginning and end of each voting round. Finally, an
end-of-voting broadcast would be used to move into the next phase
of federated system initialization. The determination of enclosures
having compatible firmware versions is used to establish a primary
federated configuration for initializing.
[0019] FIG. 2 is a schematic diagram of a computer system 110
having, by way of example, six nodes 120 (Node A-Node F)
interconnected by a fabric comprising high-speed links 40. Since an
enclosure may be configured as a single node, multiple nodes, or
part of a node, there is no required relationship between the
number of nodes and the number of enclosures in a system. Thus, the
six-node system 110 of FIG. 2 may be achieved, for example, by
applying a particular cabling configuration to the eight enclosures
of the computer system 10 of FIG. 1. The nodes 120 are
interconnected by and communicate over the high-speed links 40,
which are functional connections that may be provided by high-speed
system fabric cables. In this example, each node 120 is directly
connected to every other node 120 in the system 110, such as using
specific connectors 32 from the physical interface 30 (see FIG.
1).
[0020] Each node 120 may be operated according to initialization
control logic, which coordinates with the other nodes 120 in the
system 110 to collectively perform an initialization sequence of a
federated system. The control logic would typically reside in the
BIOS or its equivalent system firmware. Each node 120 may support
more than one firmware version. For example, a particular node 120
may include a stored copy of the most current firmware update
installed, along with stored copies of one or more previous
versions of the same firmware. Additionally, a given firmware set
may be capable of operating in multiple modes, with each mode
matched to a different federated firmware set version. To properly
initialize the system 110 as a federated system, the nodes 120 must
have compatible (matching sets of) firmware. The firmware refers to
all of the firmware elements that must be matched for federation to
be supported. The initialization control logic allows the nodes 120
to broadcast their supported firmware versions to the federated
interface.
[0021] The initialization control logic may attempt to achieve the
largest-possible federated system by identifying a firmware version
supported by the great number of nodes in the system 110. Since
this communication between the nodes 120 happens prior the system
being fully initialized, the nodes 120 can communicate over the
links 40 of the system fabric using a low-level wire protocol,
outside of any service processor elements. In one implementation,
each node 120 broadcasts a "vote" for a candidate firmware version
to the federated interface. The firmware version having the
greatest number of votes when voting concludes may then be selected
for operating the system 110 as a federated system. In an
embodiment where one or more nodes supports more than one firmware
version, the nodes may re-vote as necessary in a sequence of two or
more voting rounds, to collectively determine a firmware version
that will allow the greatest number of nodes 120 to participate in
the federated system.
[0022] After the nodes 120 that will participate in a primary
federated system have been determined, the remaining nodes 120 may
repeat the process of identifying nodes with compatible firmware
versions to form one or more additional federated systems from
among those remaining nodes 120. Alternatively, those remaining
nodes 120 that do not participate in the primary federated system
may enter a degraded mode of operation wherein those nodes 120
operate independently. Those remaining nodes 120 may alternatively
enter an automatic flash update sequence. For example, the flash
update sequence may be used to update to the firmware version
currently used by the nodes in the primary federated system.
[0023] By utilizing a low-level wire protocol on the federation
interconnect links 40, no additional configuration of management
controllers or other external communication and discovery mechanism
is required. This will allow for immediate federated system
initialization after connecting the system fabric cables between
enclosures. That is, no external configuration and discovery of
service processor elements on the federated nodes is required to
perform a compatibility check during system initialization.
Additionally, the system nodes not participating in the primary
federation can be identified and sent into a flash update sequence
per customer policy in an environment where the maximum federation
is always desired.
[0024] In the example system 110 of FIG. 2, each node is connected
to every other node. A special case would be when the nodes are not
all connected to one another. The voting algorithm could then be
modified based upon the inability of each node to receive the
version information being broadcast by all other nodes. Such an
implementation would be within the capabilities of one having
ordinary skill in the art based on the methodology described
herein. For example, one implementation would be for each node to
decide whether to change its vote based on the votes that node is
able to receive and read, even though the node may not know what
all of the votes were in a particular round.
[0025] FIG. 3 is a flowchart broadly outlining a method of
initializing a federated computer system. The method may be
implemented, for example, on a computer system having a plurality
of enclosures interconnected as a fabric of nodes by a federated
interface. Each chassis may comprise one or more nodes, or a
portion of one node. The federated interface comprises high-speed
links between the nodes, such as Scalable Coherent Interface (SCI)
per IEEE Standard 1596-1992 and Intel QuickPath Interconnect (QPI).
The nodes are preferably interconnected so that each node is
connected to every other node. The method may be implemented on the
computer system of FIGS. 1 and 2, for example. The flowchart
outlines the method from the perspective of each node; that is, the
method steps may be performed at each node to collectively
determine which nodes will participate in the federated system. The
nodes may collectively initialize as a federated system of nodes
with compatible firmware versions, without the requirement of a
separate controller to coordinate the nodes and without any
additional external communication or user input.
[0026] Step 100 is for each node to cast a vote to the federated
interface for a candidate firmware version supported by that node.
The firmware version includes the aggregated input of all elements
required to be matched at a compatible level in order for
federation to be possible in the system. This may differ for
various embodiments of the federated system, but typical examples
include a node's BIOS or Unified Extensible Firmware Interface
(UEFI) firmware, firmware for the high-speed interconnect, and node
service processor firmware. Version information may be comprised of
a list of individual firmware version elements or may be a hash of
the elements to create a unique signature for each version set. A
node supports a firmware version if that firmware version is
currently installed on and operable from the node. The nodes may
periodically receive firmware updates such as through a flash
update sequence. In some cases, a node may support only the latest
firmware version it has successfully received through a firmware
update, and previous versions may be removed. In other cases, a
node may support more than one firmware version, with the option to
initialize with either the latest firmware version or a previous
firmware version. In the latter case, each node may initially vote
for the latest firmware version it currently supports. To cast a
vote for a candidate firmware version, a node may generate a
firmware signature. The signature can be a composite of hardware
and software version information. In step 102, each node reads the
votes of its peers on the federated interface. A node can read the
vote of a particular peer by processing the firmware signature
generated by that peer.
[0027] Step 104 is to identify a candidate firmware version having
the greatest number of votes. Each node may store the votes of its
peers in local memory in conjunction with step 102 so that each
node may then independently determine the candidate firmware
version with the greatest number of votes in step 104.
Alternatively, a controller on the federated interface (but still
separate from any service processor elements on the enclosures) may
comprise memory for storing the votes and control logic for
tallying the votes and communicate the results of the voting to the
nodes. Any such controller on the federated interface may still be
outside of any service processor elements on the nodes, allowing
the voting process to occur even though the system has not yet been
initialized.
[0028] Step 106 is to initialize a federated system using the nodes
that support the candidate firmware having the greatest number of
votes as determined in step 104. If the voting is unanimous, i.e.
all nodes on the federated interface voted for the same firmware
version, then the system may be initialized as a fully federated
system. If the voting is not unanimous, a set of nodes may be
identified that do not support the firmware version identified as
receiving the greatest number of votes. A second federated system,
alternately referred to as a sub-federation, may be initialized
with a minority subset of nodes that support a firmware version
other than the firmware version receiving the greatest number of
votes. It is also possible for more than one candidate firmware
version to be tied for receiving the greatest number of votes, in
which case two identically-sized federated systems may be created
and initialized. It may be observed that, in the broadly outlined
method of FIG. 3, the nodes to be included in the federated system
may be determined in as few as one voting round, whether or not the
result of that single voting round is unanimous.
[0029] FIG. 4 is a flowchart outlining another method wherein a
sequence of voting rounds is performed to determine one or more
federated systems from a fabric of interconnected nodes. The method
of FIG. 4, like the method of FIG. 3, may be implemented on any
computer system interconnected as a fabric of nodes by a federated
interface. Again, the nodes may comprise one or more server
enclosure per node, where each enclosure has one or more servers,
and the nodes may be linked by high-speed system fabric cables,
such as SCI or QPI. The nodes are preferably interconnected so that
each node is connected to every other node. Each node may support a
plurality of different firmware versions. The method of FIG. 4 may
be implemented on the computer system of FIGS. 1 and 2, for
example.
[0030] Step 150 is for each node to read its firmware (FW)
information stored on the node. The firmware information provides a
detailed description of the available firmware versions currently
supported by that node. The firmware information may include
program code for each of a plurality of hardware devices associated
with that node. The firmware information may include identifying
version information, such as an alphanumeric firmware number that
describes the version. If a plurality of firmware versions are
loaded on and currently supported by a node, the FW information may
identify a chronology of release, such as the dates of their
installation. The firmware versions have an established hierarchy,
which may be based on this chronology. For example, in a
hypothetical group of six different firmware versions A to F,
firmware version F may be the highest firmware version and firmware
version A may be the lowest firmware version. The hierarchy may be
determined by the chronology, e.g., with version A being the
earliest release and version F being the latest release. Version F
is the highest firmware version, version E is the next-highest
firmware version relative to version F, version D is the
next-highest version relative to version E, and so forth.
[0031] Step 152 describes an initial voting round wherein each node
casts a vote to the federated interface for the highest firmware
version supported by that node. The vote to be cast may be embodied
as a signature, which may be selected as a function of the firmware
version generally. In one implementation, the signature may be a
composite of hardware and software version information. The
signature can also be a mathematical hash of version information.
For example, in one embodiment, an algorithm would map all
sub-versions of hardware and firmware to "buckets" of
interoperability, i.e. where each bucket represents one
interoperable combination of hardware and firmware sub-versions.
Then the buckets would be combined, such as using a logical OR, to
form the signature which is used to determine compatibility between
firmware sets. The interpretation of the hash results would need to
be pre-defined in the node firmware. The vote may be an electronic
representation of the firmware signature that is transmitted over
the federated interface so that the signature can be read by the
other nodes interconnected within the fabric.
[0032] Step 154 is for each node to read the current votes of the
other nodes in the fabric, i.e. its peers. Each node casts its vote
for a preferred firmware version to the federated interface in step
152, and each node in the fabric receives the votes of its peers
over the federated interface. By having each node directly
connected to every other node in the fabric, each node may directly
receive and compare the votes from its peers. The votes from the
nodes may be temporarily stored in volatile memory for purpose of
comparison.
[0033] Conditional step 156 is embedded in a flowchart loop and
determines whether the most recent round of voting was unanimous,
which may be determined by comparing signatures. This step may be
performed independently by each node, without the requirement of a
separate controller to coordinate the nodes and without any
additional external communication or user input. The vote may be
deemed unanimous if every node voted for the same candidate
firmware version, which is indicated if the signatures from all of
the nodes are identical. If the most recent round of voting for a
candidate firmware version was unanimous per conditional step 156,
then a fully-federated system is initialized per step 158. A
fully-federated system in this context is a federated system in
which all of the nodes in the fabric participate. It is possible
for the votes to be unanimous on the first (and therefore last)
voting round, in which case only one voting round will occur prior
to initialization. It is alternatively possible to converge to a
unanimous vote after multiple iterations of a flowchart loop that
returns to steps 154-156 with each iteration.
[0034] If the most recent voting round for a candidate firmware
version is not unanimous per conditional step 156, that implies
that more than one firmware version received a vote. Step 160 is to
determine the highest and next-highest firmware versions to each
receive at least one vote in the most recent voting round.
According to step 162, each node that voted for the highest
firmware version to have received a vote in the most recent voting
round changes its vote to the next-highest firmware version to have
received a vote in the most recent voting round. All other nodes
will not change their votes. If any node changes its vote in step
162 then step 162 represents a voting round that reflects any
changed votes.
[0035] Conditional step 164 is to determine whether any nodes
changed their votes in step 162. If one or more votes changed per
conditional step 164, then the changed vote represents another
voting round, and the method returns to step 154 whereby each node
again reads the votes of the other nodes in the most recent round
of voting, and another check for a unanimous vote is performed per
conditional step 156. Alternatively, if no votes changed in
conditional step 164 then the most recent voting round is
considered the final voting round, and each node may output an "end
of vote" signal to the federated interface. A partially-federated
system is then initialized in step 166. The partially-federated
system includes fewer than all of the nodes interconnected on the
federated interface, since the votes in the final voting round were
not unanimous. The partially-federated system is formed from the
nodes that support the highest firmware version to have received
votes in the final voting round.
[0036] FIG. 5 is a diagram providing a sequence of voting rounds in
the hypothetical six-node system of FIG. 2. Sample voting results
are provided in charts 201, 202, 203, 204 corresponding to a
sequence of four voting rounds. In each chart 201-204, a first
column 206 identifies the six nodes by a letter designation (Nodes
A-F). A second column 208 contains numerical designations for the
firmware version(s) currently supported by the nodes. Each row
thereby associates a node with the firmware versions that nodes
supports. Basic integer designations are used for the firmware
versions to simplify discussion, although more elaborate
alphanumeric designations may be used to represent firmware
versions or signatures derived from firmware versions. The firmware
versions range from FW version 1 to FW version 5 in this example.
Node A supports FW versions 1-3; Node B supports FW versions 2-4,
Node C supports FW versions 1-3, Node D supports FW versions 2-5,
and Nodes E and F each support FW versions 1-2 only. After each
voting round, the current vote of each node is indicated using a
bold font for the version number, and the highest version to
receive at least one vote is underlined. Collectively, the nodes
may seek to form a federated system with as many nodes as possible.
All six nodes may participate in a federated system if the nodes
can collectively determine a matching or compatible firmware
version supported by all six nodes.
[0037] An initial voting round (Vote #1) is summarized in the first
chart 201. Each node initially votes for the highest firmware
version it supports. FW version 5 is the highest version to receive
at least one vote, and FW version 4 is the next-highest FW version
to receive at least one vote. Node D was the only node to vote for
FW version 5 in the initial voting round, so in the second round of
voting (chart 202), Node D changes its vote from FW version 5 to FW
version 4. No other node changes its vote in the second voting
round.
[0038] When the second voting round is complete, the highest FW
version to receive at least one vote is FW version 4 (Nodes B and
D). The next-highest FW version to receive at least one vote is FW
version 3. Nodes B and D change their votes from FW version 4 to FW
version 3 in the third round of voting (chart 203).
[0039] When the third voting round is complete, the highest FW
version to receive at least one vote is now FW version 3 (Nodes
A-D). The next-highest FW version to receive at least one vote is
FW version 2. Nodes A-D all support FW version 2, so in the fourth
and final voting round (chart 204), Nodes A-D all change their
votes from FW version 3 to FW version 2. The votes are unanimous,
and no further voting rounds are needed. The system may now
initialize as a fully-federated system with all six nodes A-F.
[0040] In this example, the voting desirably converged to a
unanimous vote, meaning that a matching set of firmware supported
by all the nodes on the federated interface was identified. Thus, a
fully-federated system was achieved. If the sequence of voting did
not arrive at a unanimous vote, then one or more federated systems
could have been initialized from subsets of nodes, wherein each
subset supports the same FW version as its peers in that subset.
Thus, in another example, if Nodes A-D supported FW version 3 but
not FW version 2, then a primary federation of Nodes A-D could have
been initialized using Nodes A-D according to FW version 3, and a
secondary federation could have been initialized using Nodes E-F
according to FW version 2.
[0041] As will be appreciated by one skilled in the art, aspects of
the present invention may be embodied as a system, method or
computer program product. Accordingly, aspects of the present
invention may take the form of an entirely hardware embodiment, an
entirely software embodiment (including firmware, resident
software, micro-code, etc.) or an embodiment combining software and
hardware aspects that may all generally be referred to herein as a
"circuit," "module" or "system." Furthermore, aspects of the
present invention may take the form of a computer program product
embodied in one or more computer readable medium(s) having computer
readable program code embodied thereon.
[0042] Any combination of one or more computer readable medium(s)
may be utilized. The computer readable medium may be a computer
readable signal medium or a computer readable storage medium. A
computer readable storage medium may be, for example, but not
limited to, an electronic, magnetic, optical, electromagnetic,
infrared, or semiconductor system, apparatus, or device, or any
suitable combination of the foregoing. More specific examples (a
non-exhaustive list) of the computer readable storage medium would
include the following: an electrical connection having one or more
wires, a portable computer diskette, a hard disk, a random access
memory (RAM), a read-only memory (ROM), an erasable programmable
read-only memory (EPROM or Flash memory), an optical fiber, a
portable compact disc read-only memory (CD-ROM), an optical storage
device, a magnetic storage device, or any suitable combination of
the foregoing. In the context of this document, a computer readable
storage medium may be any tangible medium that can contain, or
store a program for use by or in connection with an instruction
execution system, apparatus, or device.
[0043] A computer readable signal medium may include a propagated
data signal with computer readable program code embodied therein,
for example, in baseband or as part of a carrier wave. Such a
propagated signal may take any of a variety of forms, including,
but not limited to, electro-magnetic, optical, or any suitable
combination thereof, A computer readable signal medium may be any
computer readable medium that is not a computer readable storage
medium and that can communicate, propagate, or transport a program
for use by or in connection with an instruction execution system,
apparatus, or device.
[0044] Program code embodied on a computer readable medium may be
transmitted using any appropriate medium, including but not limited
to wireless, wireline, optical fiber cable, RF, etc., or any
suitable combination of the foregoing. Computer program code for
carrying out operations for aspects of the present invention may be
written in any combination of one or more programming languages,
including an object oriented programming language such as Java,
Smalltalk, C++ or the like and conventional procedural programming
languages, such as the "C" programming language or similar
programming languages. The program code may execute entirely on the
user's computer, partly on the user's computer, as a stand-alone
software package, partly on the user's computer and partly on a
remote computer or entirely on the remote computer or server. In
the latter scenario, the remote computer may be connected to the
user's computer through any type of network, including a local area
network (LAN) or a wide area network (WAN), or the connection may
be made to an external computer (for example, through the Internet
using an Internet Service Provider).
[0045] Aspects of the present invention are described below with
reference to flowchart illustrations and/or block diagrams of
methods, apparatus (systems) and computer program products
according to embodiments of the invention. It will be understood
that each block of the flowchart illustrations and/or block
diagrams, and combinations of blocks in the flowchart illustrations
and/or block diagrams, can be implemented by computer program
instructions. These computer program instructions may be provided
to a processor of a general purpose computer, special purpose
computer, or other programmable data processing apparatus to
produce a machine, such that the instructions, which execute via
the processor of the computer or other programmable data processing
apparatus, create means for implementing the functions/acts
specified in the flowchart and/or block diagram block or
blocks.
[0046] These computer program instructions may also be stored in a
computer readable medium that can direct a computer, other
programmable data processing apparatus, or other devices to
function in a particular manner, such that the instructions stored
in the computer readable medium produce an article of manufacture
including instructions which implement the function/act specified
in the flowchart and/or block diagram block or blocks.
[0047] The computer program instructions may also be loaded onto a
computer, other programmable data processing apparatus, or other
devices to cause a series of operational steps to be performed on
the computer, other programmable apparatus or other devices to
produce a computer implemented process such that the instructions
which execute on the computer or other programmable apparatus
provide processes for implementing the functions/acts specified in
the flowchart and/or block diagram block or blocks.
[0048] The flowchart and block diagrams in the Figures illustrate
the architecture, functionality, and operation of possible
implementations of systems, methods and computer program products
according to various embodiments of the present invention. In this
regard, each block in the flowchart or block diagrams may represent
a module, segment, or portion of code, which comprises one or more
executable instructions for implementing the specified logical
function(s). It should also be noted that, in some alternative
implementations, the functions noted in the block may occur out of
the order noted in the figures. For example, two blocks shown in
succession may, in fact, be executed substantially concurrently, or
the blocks may sometimes be executed in the reverse order,
depending upon the functionality involved. It will also be noted
that each block of the block diagrams and/or flowchart
illustration, and combinations of blocks in the block diagrams
and/or flowchart illustration, can be implemented by special
purpose hardware-based systems that perform the specified functions
or acts, or combinations of special purpose hardware and computer
instructions.
[0049] The terminology used herein is for the purpose of describing
particular embodiments only and is not intended to be limiting of
the invention. As used herein, the singular forms "a", "an" and
"the" are intended to include the plural forms as well, unless the
context clearly indicates otherwise. It will be further understood
that the terms "comprises" and/or "comprising," when used in this
specification, specify the presence of stated features, integers,
steps, operations, elements, components and/or groups, but do not
preclude the presence or addition of one or more other features,
integers, steps, operations, elements, components, and/or groups
thereof. The terms "preferably," "preferred," "prefer,"
"optionally," "may," and similar terms are used to indicate that an
item, condition or step being referred to is an optional (not
required) feature of the invention.
[0050] The corresponding structures, materials, acts, and
equivalents of all means or steps plus function elements in the
claims below are intended to include any structure, material, or
act for performing the function in combination with other claimed
elements as specifically claimed. The description of the present
invention has been presented for purposes of illustration and
description, but it not intended to be exhaustive or limited to the
invention in the form disclosed. Many modifications and variations
will be apparent to those of ordinary skill in the art without
departing from the scope and spirit of the invention. The
embodiment was chosen and described in order to best explain the
principles of the invention and the practical application, and to
enable others of ordinary skill in the art to understand the
invention for various embodiments with various modifications as are
suited to the particular use contemplated.
* * * * *