|Publication number||US6993566 B2|
|Application number||US 09/952,592|
|Publication date||Jan 31, 2006|
|Filing date||Sep 13, 2001|
|Priority date||Sep 13, 2001|
|Also published as||US20030050993|
|Publication number||09952592, 952592, US 6993566 B2, US 6993566B2, US-B2-6993566, US6993566 B2, US6993566B2|
|Inventors||Brad A. Davis, Henry J. DiVincenzo, Richard A. Lary, Thomas E. Malone, Patrick D. Mason, Lee G. Rosenbaum, Manoj R. Sastry, Patrick W. White|
|Original Assignee||International Business Machines Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (17), Referenced by (3), Classifications (15), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Technical Field
This invention relates generally to entities, such as service processors that may be found within nodes of a system, and more particularly to the self-clustering of such entities, so that, for instance, a single image of the service processors appears to the operating system of the system and/or a management console for the system.
2. Description of the Prior Art
As computer systems, such as server systems, become more complex, they have been divided into different nodes that operate as separate units. Each node may have its own processors, memory, and input/output (I/O) modules. Functionality performed by a system may be divided among its various nodes, such that each node is responsible for one or more different functions. Each node has a service processor (SP) that functions independently of the service processors of the other nodes, but which allows external access to the hardware of its node.
A complication to dividing a system into different nodes is that the operating system (OS) running collectively on the system, and the management consoles used to manage the system externally, have traditionally had to be aware of the specific aspects of this division into nodes. The operating system, for instance, has to know which service processor is responsible for which hardware and functionality of the system, so that messages can be routed to the appropriate service processor. Similarly, management consoles have to know the mapping of the service processors to the system's hardware and functionality.
This adds increased complexity to the operating system and the management consoles. Significant configuration may have to be accomplished to ensure that the operating system and the consoles are properly aware of the different service processors and the functions that have been assigned to them. Furthermore, like all system components, service processors sometimes fail. To ensure that the system itself does not fail, another service processor may have to temporarily act as the failover processor for the down processor. The operating system and the consoles must be aware of such failover procedures, too. Load balancing and other inter-service processor procedures also require knowledge of the distribution of functionality over the service processors.
In addition, traditional communication between an operating system and the service processors of the system occurs within the firmware of the system. Firmware is software that is stored in hardware, such that the software is retained even after no power is applied to the hardware. The use of conventional firmware, however, degrades performance significantly. For instance, firmware is not re-entrant. That is, only one processor can execute the firmware at a single time. This means that the firmware may present a bottleneck to the efficient running of the system.
In other contexts, the management of multiple resources is accomplished on a simplistic basis. For example, in the context of storage devices, such as hard disk drives, a redundant array of information disks (RAID) provides for limited interaction among resources. A RAID may be configured so that each hard drive redundantly stores the same information, that data is striped across the hard drives of the array for increased storage and performance, or for additional or other purposes. However, the drives themselves do not actively participate in their aggregation. Rather, a master controller is responsible for managing the drives, such that the drives themselves are not aware of one another.
Therefore, such solutions are not particularly apt in the system division of functionality and hardware over multiple service processors scenario that has been described. For example, having a master controller in this scenario just shifts the burden of knowing the functionality and hardware division from the management consoles and the operating systems to the controller. This does not reduce complexity, and likely does not prevent reductions in system performance.
Other seemingly analogous resource management approaches have similar pitfalls. Network adapters that can be aggregated to provide greater bandwidth, for instance, are typically aggregated not among themselves, but by a host operating system and/or device driver. This host operating system and/or device driver thus still takes on the complex management duties that result when multiple resources are managed as a single resource. In other words, complexity is still not reduced, and potential performance degradation is still not prevented.
For these described reasons, as well as other reasons, there is a need for the present invention.
The invention relates to entities, such as service processors, within a system. In a method of the invention, each entity self-discovers all the other entities, such that the entities are aggregated as a cluster. Each entity maintains an object map that represents the hardware of the system for which it is responsible as objects. A first identifier and a second identifier uniquely identify each object. The first identifier corresponds to the entity on which the object resides, whereas the second identifier distinguishes the object from other objects also residing on the entity.
A system of the invention includes a self-aggregated cluster of entities, and a host. The host communicates with the cluster of entities such that it need not be aware which of the entities performs a given function. An article of manufacture of the invention includes a computer-readable medium and means in the medium. The means is for an entity of a system self-discovering all the other entities of the system to aggregate the entities as a cluster. The means is further for the entity maintaining an object map representing the resources of the system for which it is responsible as objects.
Other features and advantages of the invention will become apparent from the following detailed description of the presently preferred embodiment of the invention, taken in conjunction with the accompanying drawings.
In the preferred embodiment of the invention, a number of service processors are self-aggregated together in a single cluster.
The service processors 102 a, 102 b, . . . , 102 n appear as a single cluster 102 to an operating system (OS) 106 and a management console 108. For instance, with respect to the OS 106, the cluster 102 communicates with the OS 106 through a shared memory 104. The memory 104 is shared by all the processors 102 a, 102 b, . . . , 102 n within the cluster 102. Communication between the cluster 102 and the OS 106 is such that the OS 106 is preferably unaware which of the processors 102 a, 102 b, . . . , 102 n performs a given function. For example, the OS 106 may place a message in a part of the memory 104 allocated for a certain function, such that the one of the processors 102 a, 102 b, . . . , 102 n responsible for this function monitors this part of the memory 104 and processes the message.
With respect to the console 108, the console 108 preferably communicates through any one of the service processors 102 a, 102 b, . . . , 102 n of the cluster 102. As shown in
The service processors first self-discover one another (502), such that the service processors are aggregated as a cluster. Each service processor also maintains an object map representing the hardware of the system for which it is responsible as objects (504). Two identifiers uniquely identify each object. The first identifier corresponds to the service processor on which the object resides. The second identifier distinguishes the object from other objects residing on the same service processor.
The first identifier 608 may be any identifier unique to the service processor 602, such as the service processor's serial number or its Ethernet address. Other unique identifiers include combinations of one or more of the media access controller (MAC) address of the service processor 602, and the port over which the service processor 602 communicates. The first identifier 608 may or may not include a network-related unique identifier. The second identifiers 610 and 612 may be the object instance numbers of the objects instantiated to represent the hardware 604 and 606, respectively. For example, if the object representing the hardware 604 is initiated first, it may have an instance number of one, whereas if the object representing the hardware 606 is instantiated second, it may have an instance number of two.
Referring back to
The discovery process outlined in
Embodiments of the invention can also incorporate a pre-discovery process not specifically outlined in
The OS communicates with the cluster of service processors through a memory shared by all the service processors, such that the OS is preferably unaware which of the service processors performs a given function. First, the OS stores a message in a part of the shared memory allocated for a given type of messages (802). The service processor that has responsibility for this part of the shared memory, such that it is responsible for performing the functionality associated with the type of messages for which this part of the memory is allocated, processes the message (804). The service processor may, for instance, send data stored in the message over the service processor network 204 to the console 108. The service processor then stores a response in the part of the shared memory (806), so that the OS is aware that the message has been properly processed.
The messages stored in the different parts of the memory 104, and thus the channels into which the memory 104 has been divided, may be of different types. For example, a billboard type represents a generic memory data structure in which data is stored in the channel. A flow-controlled type represents a flow-controlled data structure in which the order of processing of the data is specified. A first-in-first-out (FIFO) type represents a FIFO-queuing data structure in which the first data stored is the first data processed. As a final example, an interrupt type represents a hardware feature which may be manipulated according to instructions stored in a data structure, to alert a service processor that a given event has occurred, such as work has arrived, such that particular actions may have to be performed.
Because each of the service processors 102 a, 102 b, . . . , 102 n is responsible for a specific subset of the channels at different points in time, it is said that the channels are dynamically allocated among the service processors. Dynamic allocation of the channels among the service processors in particular allows for failover and load balancing among the service processors. For example, if one channel is receiving an inordinate amount of traffic, the other channels handled by the same responsible service processor may be dynamically allocated to other service processors, for load-balancing purposes. As another example, if a service processor fails, the channels for which it is responsible may be dynamically allocated to other service processors, for failover purposes.
The console communicates with the cluster of service processors through any one of the service processors of a cluster, such that the console is preferably unaware that the service processors have been clustered to perform functionality for the console. This service processor first receives a message from the console (1002), and determines whether the message is intended for itself or another service processor within the cluster (1004). For instance, the message may relate to hardware that is stored in the same node as the service processor, or in the same node as another service processor. As another example, the message may relate to a function for which the service processor is responsible, or for which another service processor is responsible.
If the message is intended for the service processor that received the message, then this service processor processes the message appropriately (1006), and sends a response back to the console (1008). However, if the message is intended for a different service processor, the service processor that received the message sends, or routes, the message to this other service processor (1010), which itself processes the message. The service processor that received the message then receives a response from this other service processor (1012), which it routes back to the console (1014).
Other types of routing can also be accomplished of messages among service processors and the console, in addition to or in lieu of that shown specifically shown in
Furthermore, the console can become aware of a given object representing specific hardware on a specific service processor in a number of different ways not limited by the invention itself. The console may, for instance, ask for enumeration of the objects from the service processor it knows. For example, one of the service processors may maintain what is referred to as a service processor type root class node, which has the specific service processor instances as first-level children nodes. The children nodes of these first-level children nodes are second-level children nodes maintained by the individual service processors themselves, which can be directly queried for the enumeration of the second-level children nodes. The second-level children nodes may correspond to, for instance, the objects representing the hardware on a given service processor.
Embodiments of the invention allow for advantages over the prior art. The service processors of the nodes of a system aggregate themselves in a cluster, such that the operating system (OS) and the management console do not have added overhead responsibilities. That is, the service processors are clustered without assistance from a controller, host, master service processor, or other entity. This means that the OS and the console are not themselves required to perform service processor cluster management duties.
Because the OS places messages in different channels of memory shared among all the service processors, the OS is preferably unaware which of the service processors actually handles a given type of message. The OS thus does not have to track which service processors handle which types of messages, and, significantly, does not have to concern itself with load balancing and failover among the service processors. Similarly, the console communicates with the cluster of service processors through a given service processor, and thus is preferably unaware that the cluster is performing functionality for the console. The console also does not have to track which service processors handle which types of messages, and does not have to concern itself with load balancing and failover.
In addition, embodiments of the invention can be performed within the firmware of the service processor, avoiding modification of the OS to ensure compatibility. This means that significant coding effort is avoided to implement the invention in such embodiments, because the different types of operating systems that may be used do not have to be modified in order to implement the invention, since the invention is implemented in service processor firmware. Such service processor firmware implementation also increases behavioral consistency of service processor functionality from OS to OS.
Aspects of the invention are applicable in other contexts besides an operating system (OS) communicating with a self-aggregated cluster of service processors through a shared memory.
The shared memory 1104 is allocated into different parts, or channels, one or more of which each of the entities 1102 a, 1102 b, . . . , 1102 n monitors for messages from the host 1106 for processing. Thus, communication between the host 1106 and the cluster 1102 can be accomplished as has been more particularly described in conjunction with the method 800 of
As an example, the entities 1102 a, 1102 b, . . . , 1102 n may be network adapters each having a given bandwidth, and which can self-discover one another to form the cluster 1102. The bandwidth constituting the resource on the network adapters. The host 1106 may be an OS that sends data over the cluster 1102 through the shared memory 1104. In this way, the OS does not have to be reconfigured to support multiple network adapters, but rather treats the cluster 1102 as a single, high-bandwidth network adapter. The adapters themselves handle failover, load balancing, and connection routing among the network adapters, such that the OS does not have to take on additional overhead for such functionality.
As another example, clustering of mass storage controllers may be performed, to allow a common queue of read/write/verify commands to be executed by any storage controller with access to the data. This is referred to as self-aggregating RAID. The number and type of storage controllers can vary, as well as which of them handles a particular region of clusters. The resources in this case are the storage devices, such as hard disk drives or other mass storage devices, managed by the mass storage controllers. Furthermore, the controllers may, for example, dynamically enable extra redundancy by initiating mirroring to unallocated storage, which is known as RAID-1, or initiating striping for regions experiencing large reads/writes, which is known as RAID-0. Another example is a cluster of coprocessors, such as floating point, vector, graphics, or other types of processors, which can result in high resource utilization with low overhead.
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. For example, whereas four different types of messages that can be communicated between the operating system (OS) and the cluster of service processors have been described, other types of messages can also be communicated between the OS and the cluster. As another example, the first identifier has been described as the Ethernet address of a service processor. However, other types and combinations of identifiers can also be used as the first identifier.
As another example, discovery of cluster peers can be accomplished by multicasting rather than broadcasting. The role ascribed to the OS can also be performed by other software code executing on the host, such as host firmware, a driver, a diagnostic program, and so on. Furthermore, the OS and/or the console may be aware of which service processor in the cluster is responsible for processing their requests, even though the invention has been substantially described as the OS and the console being unaware of which service processor is so responsible. In addition, whereas the invention has been substantially described as pertaining to a shared memory, it is also applicable to other types of shared resources, such as computer-readable media like hard disk drives and other storage media. Accordingly, the scope of protection of this invention is limited only by the following claims and their equivalents.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5410688 *||Jul 16, 1990||Apr 25, 1995||Hewlett-Packard Company||Distributed object based systems for communicating object data among different storage domains|
|US5655101 *||May 27, 1994||Aug 5, 1997||International Business Machines Corporation||Accessing remote data objects in a distributed memory environment using parallel address locations at each local memory to reference a same data object|
|US5694550 *||Nov 15, 1996||Dec 2, 1997||Fujitsu Limited||Automatic switching method of a right of management/control for shared-storage unit|
|US5855013 *||Jul 1, 1996||Dec 29, 1998||Sun Microsystems, Inc.||Method and apparatus for creating and maintaining a computer database utilizing a multi-purpose data format|
|US5862357 *||Jul 2, 1996||Jan 19, 1999||Sun Microsystems, Inc.||Hierarchical SMP computer system|
|US5946685 *||Jun 27, 1997||Aug 31, 1999||Sun Microsystems, Inc.||Global mount mechanism used in maintaining a global name space utilizing a distributed locking mechanism|
|US6029168 *||Jan 23, 1998||Feb 22, 2000||Tricord Systems, Inc.||Decentralized file mapping in a striped network file system in a distributed computing environment|
|US6038677 *||Mar 31, 1997||Mar 14, 2000||International Business Machines Corporation||Automatic resource group formation and maintenance in a high availability cluster configuration|
|US6047323 *||Jun 27, 1996||Apr 4, 2000||Hewlett-Packard Company||Creation and migration of distributed streams in clusters of networked computers|
|US6151639 *||Jun 19, 1997||Nov 21, 2000||Sun Microsystems, Inc.||System and method for remote object invocation|
|US6189111 *||Mar 26, 1998||Feb 13, 2001||Tandem Computers Incorporated||Resource harvesting in scalable, fault tolerant, single system image clusters|
|US6195680 *||Jul 23, 1998||Feb 27, 2001||International Business Machines Corporation||Client-based dynamic switching of streaming servers for fault-tolerance and load balancing|
|US6351775 *||May 30, 1997||Feb 26, 2002||International Business Machines Corporation||Loading balancing across servers in a computer network|
|US6353898 *||May 18, 2000||Mar 5, 2002||Novell, Inc.||Resource management in a clustered computer system|
|US6665304 *||Dec 31, 1998||Dec 16, 2003||Hewlett-Packard Development Company, L.P.||Method and apparatus for providing an integrated cluster alias address|
|US6701382 *||Dec 23, 1998||Mar 2, 2004||Nortel Networks Limited||Name service for transparent container objects|
|US6834298 *||Sep 21, 1999||Dec 21, 2004||Siemens Information And Communication Networks, Inc.||System and method for network auto-discovery and configuration|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7225356 *||Feb 6, 2004||May 29, 2007||Siemens Medical Solutions Health Services Corporation||System for managing operational failure occurrences in processing devices|
|US7689862 *||Jan 23, 2007||Mar 30, 2010||Emc Corporation||Application failover in a cluster environment|
|US20050138517 *||Feb 6, 2004||Jun 23, 2005||Arnold Monitzer||Processing device management system|
|U.S. Classification||709/213, 709/238|
|International Classification||G06F15/167, G06F9/46, G06F9/50, H04L29/08|
|Cooperative Classification||H04L67/16, H04L69/329, G06F9/5061, G06F9/544, G06F2209/505|
|European Classification||G06F9/54F, H04L29/08N15, G06F9/50C, H04L29/08A7|
|Sep 13, 2001||AS||Assignment|
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DAVIS, BRAD A.;DIVINCENZO, HENRY J.;LARY, RICHARD A.;ANDOTHERS;REEL/FRAME:012191/0793;SIGNING DATES FROM 20010806 TO 20010912
|Sep 7, 2009||REMI||Maintenance fee reminder mailed|
|Jan 31, 2010||LAPS||Lapse for failure to pay maintenance fees|
|Mar 23, 2010||FP||Expired due to failure to pay maintenance fee|
Effective date: 20100131