The present invention relates generally to computer server systems and, more particularly, to a method for interlocking a server to a server system.
In today's environment, a computing system often includes several components, such as servers, hard drives, and other peripheral devices. These components are generally stored in racks. For a large company, the storage racks can number in the hundreds and occupy huge amounts of floor space. Also, because the components are generally free standing components, i.e., they are not integrated, resources such as floppy drives, keyboards and monitors, cannot be shared.
A system has been developed by International Business Machines Corp. of Armonk, N.Y., that bundles the computing system described above into a compact operational unit. The system is known as an IBM eServer BladeCenter.™ The BladeCenter is a 7U modular chassis that is capable of housing up to 14 individual server blades. A server blade or blade is a computer component that provides the processor, memory, hard disk storage and firmware of an industry standard server. Each blade can be “hot-plugged” into a slot in the chassis. The chassis also houses supporting resources such as power, switch, management and blower modules. Thus, the chassis allows the individual blades to share the supporting resources.
In a dense server environment, multiple BladeCenter type products can be utilized. Because the server blades are highly mobile, i.e., they are easily removed from a chassis and easily reinstalled into the same or another chassis, there is a possibility that an unauthorized or hostile server blade can be placed in a chassis. In that case, the hostile server blade could have access to information on the other server blades in the chassis or be privy to information distributed to the authorized server blades in the chassis. Moreover, the hostile server blade could corrupt the other server blades, e.g., by introducing viruses into the system. Clearly, this raises serious security concerns.
Accordingly, a need exists for a method for securely interlocking servers to their respective server systems. The method should be able to detect and isolate a non-interlocked, i.e., unauthorized, server in the server system. The present invention addresses such a need.
The present invention is directed to a method for interlocking a plurality of servers to a server system and a computer system utilizing the same. In a first aspect, the method comprises assigning an identifier to each of the plurality of servers, wherein the identifier associates each of the plurality of servers to the server system, thereby defining a plurality of interlocked servers.
Through the aspects of the present invention, each server is interlocked to its respective server system via an identifier stored in its non-volatile storage. The identifier is unique to the server system. Thus, if an unauthorized server is placed in the server system, it will be identified immediately as such and isolated from the other servers in the system. In this manner, the server system is protected from intruders.
The present invention relates generally to computer server systems and, more particularly, to a method and system for interlocking a server to a server system. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Although the preferred embodiment of the present invention will be described in the context of a BladeCenter, various modifications to the preferred embodiment and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest scope consistent with the principles and features described herein.
According to a preferred embodiment of the present invention, an interlock mechanism allows an administrator to interlock each server in a server system (chassis) to the system by storing an identifier in each server's non-volatile storage. The identifier uniquely identifies the server system. Thus, at appropriate times, the interlock mechanism will autonomously check each server in the system to ensure that each server is interlocked to the server system. If an unauthorized server is detected, the interlock mechanism will take appropriate action to protect the server system from the unauthorized server.
To describe the features of the present invention, please refer to the following discussion and Figures, which describe a computer system, such as the BladeCenter, that can be utilized with the present invention.
A midplane circuit board 106 is positioned approximately in the middle of chassis 102 and includes two rows of connectors 108, 108′. Each one of the 14 slots includes one pair of midplane connectors, e.g., 108a, 108a′, located one above the other, and each pair of midplane connectors, e.g., 108a, 108a′mates to a pair of connectors (not shown) at the rear edge of each server blade, e.g., 104a.
As is shown in
The management modules 208 communicate with all of the key components of the system 100 including the switch 210, power 206, and blower 204 modules as well as the blade servers 104 themselves. The management modules 208 detect the presence, absence, and condition of each of these components. When two management modules are installed, a first module, e.g., MM1 (208a), will assume the active management role, while the second module MM2 (208b) will serve as a standby module.
The second chassis 202 also houses up to four switching modules SM1 through SM4 (210a-210d). Each switch module includes several external data ports (not shown) for connection to the external network infrastructure. The primary purpose of the switch module 210 is to provide interconnectivity between the server blades (104a-104n), management modules (208a, 208b) and the outside network infrastructure.
As is shown in
In general, the management module 302 can detect the presence, quantity, type, and revision level of each blade 304a-304c, power module 206, blower 204, and midplane 106 in the system, and can detect invalid or unsupported configurations. The management module 302 will retrieve and monitor critical information about the chassis 102 and server blades 304a-304c, such as temperature, voltages, power supply, memory, fan and hard drive status. If a problem is detected, the management module 302 can transmit a warning to a system administrator 315 via the port 306 coupled to the management server 314.
Referring again to
Referring again to
In a preferred embodiment of the present invention, the system administrator (or some other authorized entity) (315) invokes the interlock utility 319 via the management server 314 to interlock the server blades 304a-304c to the server system 300. As used in this description, “interlocking” a server blade , e.g., 304a, refers to associating the server blade 304a to an entity, such as the server system 300 or chassis 102. In an initializing session, the interlock mechanism 316 assigns to each server blade 304a-304c an identifier, hereinafter referred to as an interlock record 320a-320c, that uniquely identifies the server system 300.
Each server blade 304a-304c includes non-volatile storage (NVS) 312a-312c, which is accessible by the associated service processor 308a-308c. The NVS 312a-312c can be any storage medium known in the art, such as storage on a hard file partition or non-volatile memory (CMOS). The interlock record 320a-320c is stored in each blade's NVS 312a-312c as well as in the Blade Present Table 318. Thus, at appropriate times, the interlock mechanism 316 will autonomously check each server blade 304a-304c in the system 300 to ensure that each server blade 304a-304c is interlocked to the server system 300. If an unauthorized server blade, e.g., 304b is detected, the interlock mechanism 316 will take appropriate action to protect the server system 300 from the unauthorized server blade 304b.
If none of the server blades 304a-304c are interlocked to the server system 300, the administrator can select an initial interlocking session (in step 406). In step 407, the interlock mechanism 316 interlocks each server blade 304a-304c to the server system 300. In a preferred embodiment, the interlocking process begins by building the Blade Present Table 318 (step 408) so that the table 318 includes an entry for each server blade 304a-304c present in the system 300. The interlock mechanism 316 then generates the interlock record 320 and stores the interlock record 320 in each server blade's non-volatile storage 312a-312c in step 409. In a preferred embodiment, the interlock mechanism 316 transfers the interlock record 320 to each server blade's non-volatile storage 312a-312c in the form of an enumeration, such as an ACPI enumeration. After each server blade 304a-304c has been interlocked, the interlocking utility 319 updates the Blade Present Table 318.
In one preferred embodiment, the interlock record 320a-320c is some alphanumeric string that uniquely identifies the server system 300. For example, the record 320afor a server blade 304a could include the serial number for the management module 302, the server blade's 304a serial number, and the date and time of the session. Moreover, if the server system 300 includes a second management module (not shown), e.g., a backup module, the record 320a-320c could also include the serial number of the second management module. Accordingly, if the second module is activated, the server blades 304a-304c remain automatically interlocked to the server system 300. In this case, the Blade Present Table 318 is copied to the second management module.
If the initial interlocking session has been completed, the administrator 315 can choose to remove an entry in the Blade Present Table 318 (step 412). The administrator 315 might perform this action if he or she were removing one of the interlocked server blades, e.g., 304b, from the server system 300. Here, in step 414, the administrator 315 provides a slot number representing the slot (e.g., 105b) from which the server blade 304b will be removed. The interlock mechanism 316 then disassociates the server blade 304b from the server system 300 in step 416 by erasing the interlock record 320b stored in the server's non-volatile storage 312b. In step 410, the interlock mechanism 316 removes the corresponding entry in the Blade Present Table.
If the administrator wishes to add an entry (step 418), i.e., add a new server blade (304c) into the server system 300, the administrator 315 provides the slot number representing the slot (e.g., 105b) into which the server blade 304c will be placed via step 420. The interlock mechanism 316 then interlocks the server blade 304c to the server system 300 in step 422 by generating the interlock record 320c and storing it in the server's non-volatile storage 312c. In step 410, the interlock mechanism 316 adds the corresponding entry in the Blade Present Table.
If the administrator would like to disassociate each server blade 304a-304c from the server system 300 (step 426), the interlock mechanism 316 disassociates each server blade in step 428 by erasing each interlock record 320a-320c in each server blade's non-volatile storage 312a-312c. In step 430, all entries in the Blade Present Table 318 are cleared.
Once the administrator 315 has interlocked the server blades 304a-304c to the server system 300, the interlock mechanism 316 can detect automatically the presence of a server blade that has not been authorized, i.e., interlocked, by the administrator 315. As stated above, the interlock mechanism 316 checks each server blade 304a-304c in the system 300 to ensure that each server blade 304a-304c is interlocked to the server system 300. Preferably, the interlock mechanism 316 checks each server blade 304a-304c during a power-up sequence for the server system 300, and investigates if a server blade has been added to or removed from the server system 300.
If the interlock mechanism 316 finds an existing interlock record 320b (step 508) in the server blade's non-volatile storage 312b, the interlock mechanism 316 must determine whether the interlock record 320b is valid, i.e., not generated by another interlock mechanism, in step 512. In one preferred embodiment, the interlock mechanism 316 will access the Blade Present Table 318 and compare the existing interlock record 320b to that stored in the table 318. If the values do not match, i.e., the interlock record 320b is invalid, the interlock mechanism 316 erases the existing interlock record 320b in step 514 and instructs the management module 302 to maintain the power off state for that server blade 304b in step 510. If the values do match, i.e., the interlock record 320b is valid, the interlock mechanism 316 instructs the management module 302 to power up the server blade 304b and to release it for booting in step 516. In either case, the next step (step 518) involves determining whether the interlock mechanism 316 must check more blades. If there are more, steps 508-520 are repeated.
After the interlock mechanism 316 has checked each of the server blades 304a-304c in the server system 300 (step 518), it determines which, if any, of the server blades 304a-304c are not interlocked in step 522. The server blades, e.g., 304a, that are held in the power-off state are not interlocked to the server system 300. If there are any server blades that are not interlocked, the interlock mechanism 316 generates an alert and transmits it to the system administrator via the management server 314, in step 524. In a preferred embodiment, the alert includes the slot number into which the non-interlocked server blade(s) 304a is placed.
As stated above, a non-interlocked server blade, e.g., 304a, is not authorized to operate in the server system 300. By holding the non-interlocked server blade 304a in a power-off state, the interlock mechanism 316 isolates the non-interlocked server blade 304a from the interlocked server blades, e.g., 304b, 304c. In another embodiment, the interlock mechanism 316 instructs the management module 302 to power off the entire server system 300 after transmitting the alert if any of the server blades 304a-304c are not interlocked to the server system 300. In either embodiment, the interlock mechanism 316 protects the integrity of the server system 300 from any unauthorized, i.e., non-interlocked, server blades 304a coupled to the system 300.
As mentioned above, the management module 302 and therefore the interlock mechanism 316 are sensitive to the addition or removal of a server blade to and from the server system 300. In both instances, the interlock mechanism 316 ensures that the server system 300 is protected and that the administrator 315 is alerted of any potential security breach.
For instance, in a preferred embodiment, if the management module 302 detects that a blade server, e.g., 304c, is inserted into the server system 300, the interlock mechanism 316 will instruct the management module 302 to hold the newly inserted blade server 304c in a power off state, while it checks the server blade 304c to determine whether it is interlocked to the server system 300 (process steps 506-516 in
If the management module 302 detects that a server blade, e.g., 304b, has been removed or powered off, the interlock mechanism 316 marks the entry in the Blade Present Table 318 corresponding to the removed server blade 304b and generates the alert indicating the slot number of the removed server blade 304b. The interlock mechanism 316 then transmits the alert to the administrator 315. If the removed server blade 304b is reinserted into the slot, the management module 302 detects that a server blade 304b is inserted into the server system 300, and the interlock mechanism 316 instructs the management module 302 to hold the reinserted server blade 304b in a power off state, while it checks the server blade 304b to determine whether it is interlocked to the server system 300 (process steps 506-514 in
The interlock mechanism 316 generates and transmits the alert to the administrator 315 only if a non-interlocked server blade has been detected or if a server blade has been removed, or if a removed server blade has been reinserted. In either case, the administrator 315 utilizes the alert to manage and maintain the server system 300. For example, referring again to
As stated above, the process of interlocking a server, e.g., 304c, to the server system 300 involves generating an interlock record 320c and storing it in the server's non-volatile storage 312c. The interlock record 320c is preferably based on any combination of the serial number for the management module 302, the server blade's 304c serial number, and the date and time of the session. For added security, the interlock mechanism 316 preferably utilizes a hashing algorithm to hash the interlock record 320c to form a nonce. The nonce is then stored in the Blade Present Table 318. When the interlock mechanism 316 stores the nonce in the server blade's non-volatile storage 312c, it instructs the server blade 304c to encrypt the nonce using the server blade's private key. Accordingly, the server blade 304c stores the encrypted nonce in its non-volatile storage 312c.
When the interlock mechanism 316 attempts to validate the interlock record 320c in the server blade 304c, e.g., during a system power up sequence, the interlock mechanism 316 obtains the server blade's public key via the “out-of-band” serial bus 310. The interlock mechanism 316 uses the public key to decrypt the encrypted nonce and compares the nonce in the server blade 304c with that stored in the Blade Present Table 318.
By creating a nonce to represent the interlock record 320 and then encrypting the nonce at the server blade, the interlock mechanism 316 adds several layers of security to the interlocking configuration of the server system 300. Thus, unauthorized access to the server system 300 is further deterred.
Through aspects of the present invention, the interlock mechanism 316 allows an administrator 315 to interlock each server in a server system to the system by storing an interlock record in each server's non-volatile storage. The interlock record uniquely identifies the server system. Thus, at appropriate times, the interlock mechanism will autonomously check each server in the server system to ensure that each server is interlocked. If an unauthorized server is detected, the interlock mechanism will take appropriate action to protect the server system from the unauthorized server.
While the preferred embodiment of the present invention has been described in the context of a BladeCenter environment, the functionality of the interlock mechanism 316 could be implemented in any computer environment where the servers are closely coupled. Thus, although the present invention has been described in accordance with the embodiments shown, one of ordinary skill in the art will readily recognize that there could be variations to the embodiments and those variations would be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.
Number | Name | Date | Kind |
---|---|---|---|
5757920 | Misra et al. | May 1998 | A |
6021493 | Cromer et al. | Feb 2000 | A |
6233246 | Hareski et al. | May 2001 | B1 |
6378009 | Pinkston, II et al. | Apr 2002 | B1 |
6381641 | Iwasaki | Apr 2002 | B1 |
6427176 | Berglund et al. | Jul 2002 | B1 |
6460120 | Bass et al. | Oct 2002 | B1 |
6502129 | Stewart et al. | Dec 2002 | B1 |
6661671 | Franke et al. | Dec 2003 | B1 |
6771499 | Crippen et al. | Aug 2004 | B2 |
6904482 | Rietze et al. | Jun 2005 | B2 |
6968414 | Abbondanzio et al. | Nov 2005 | B2 |
6976112 | Franke et al. | Dec 2005 | B2 |
7034659 | Ungs | Apr 2006 | B2 |
7051215 | Zimmer et al. | May 2006 | B2 |
7137014 | Dake et al. | Nov 2006 | B2 |
7191347 | Bigelow et al. | Mar 2007 | B2 |
7194619 | Abbondanzio et al. | Mar 2007 | B2 |
7308703 | Wright et al. | Dec 2007 | B2 |
7627901 | Elliott | Dec 2009 | B1 |
20020064149 | Elliott et al. | May 2002 | A1 |
20020095487 | Day et al. | Jul 2002 | A1 |
20020104009 | Zodnik | Aug 2002 | A1 |
20020198992 | Stutz et al. | Dec 2002 | A1 |
20030048613 | Garnett et al. | Mar 2003 | A1 |
20030065751 | Autor et al. | Apr 2003 | A1 |
20030069953 | Bottom et al. | Apr 2003 | A1 |
20030105904 | Abbondanzio et al. | Jun 2003 | A1 |
20030181229 | Forster et al. | Sep 2003 | A1 |
20030188176 | Abbondanzio et al. | Oct 2003 | A1 |
20040100765 | Crippen et al. | May 2004 | A1 |
20040103327 | Dake et al. | May 2004 | A1 |
20040109406 | Rothman et al. | Jun 2004 | A1 |
20040117536 | Franke et al. | Jun 2004 | A1 |
20040128562 | Bigelow et al. | Jul 2004 | A1 |
20040165358 | Regimbal et al. | Aug 2004 | A1 |
20040233636 | Crippen et al. | Nov 2004 | A1 |
20040240180 | Crippen et al. | Dec 2004 | A1 |
Number | Date | Country | |
---|---|---|---|
20040257998 A1 | Dec 2004 | US |