IPMI server management system and method

An intelligent platform management interface (IPMI) server management system includes a managing side and a plurality of managed sides. The managed sides includes at least on active IPMI managed sides, wherein each of the active IPMI managed side actively provides its service information to the managing side so as to establish a first list, and then the managing side searches out the managed sides which are not on the first list one by one so as to establish a second list. Therefore, the IPMI server management system may effectively sort out the managed sides which are available for application.

RELATED APPLICATIONS

This application claims priority to Taiwan Application Serial Number 98120448, filed Jun. 18, 2009, which is herein incorporated by reference.

BACKGROUND

1. Field of Invention

The present invention relates to a management interface. More particularly, the present invention relates to an intelligent platform management interface (IPMI).

2. Description of Related Art

The IPMI was presented by Intel, Dell, HP and NEC in 1998. An IPMI server management system provides a cross-platform standard interface for monitoring certain conditions of a system, such as temperature, voltage and fan speed, etc., and informs system administrators of the current system conditions by event trigger.

Concretely speaking, the IPMI server management system establishes a sever mechanism among a plurality of managed sides using the IPMI, and builds a resource list when a managing side sends a service request to each of the managed sides, thereby list all of the available managed sides in detail.

However, the process for building the resource list is quite cumbersome and lacks of efficiency. For example, when a network submask address is 192.168.1.255, besides a generic broadcast address 192.168.1.0, the managing side has to send ping signals one by one to a total of 254 server nodes of which the addresses are from 192.168.1.1 to 192.168.1.254, and waits for each of the server nodes to return a pong signal. After receiving the pong signals of the respective server nodes, the managing side asks the available server nodes for their service information.

The aforementioned process is cumbersome and inefficient. Meanwhile, when a managed side at a certain server node is withdrawn from or added to providing service halfway, the managing side will not learn the change until the next round of rescanning the server nodes one by one.

SUMMARY

An aspect of the present invention is to provide an IPMI server management system for speeding up the establishment of resource list.

According to an embodiment, the IPMI server management system includes a managing side and a plurality of managed sides. The managed sides include at least one active IPMI managed side, wherein each of the at least one active IPMI managed side actively provides its service information to the managing side so as to establish a first list, and then the managing side searches out the managed sides which are not on the first list one by one so as to establish a second list. Therefore, the IPMI server management system can effectively sort out a plurality of managed sides which are available for application.

Another aspect of the present invention is to provide an IPMI server management method for promoting the efficiency of the IPMI.

According to an embodiment, the IPMI server management method includes the following steps. At least one active IPMI managed side is controlled to provide at least one set of service information to a managed side, and a first list is built at the managing side in accordance with the service information. Then, the managing side is controlled to search out a plurality of managed sides which are not included in the first list, so as to establish a second list. Therefore, the IPMI server management method can list the available managed sides in the first list shortly.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring toFIG. 1,FIG. 1is a functional block diagram showing an IPMI server management system according to an embodiment of the present invention. InFIG. 1, the IPMI server management system of this embodiment includes a managing side100and a plurality of managed sides. The managed sides210can be further divided into a plurality of active IPMI managed sides210and a plurality of non-active IPMI managed sides220. Each of the active IPMI managed sides210first provides service information211actively to the managing side100for establishing a first list110, so that a user at the managing side100may perform operation onto a plurality of active IPMI managed sides210which have first returned responses to the managing side100actively, and does not need to wait until all of the server nodes have returned responses, thus promoting the operation efficiency of the IPMI server management system.

Subsequently, referring toFIG. 2,FIG. 2is a functional block diagram for explaining a method for building a second list120by the IPMI server management system ofFIG. 1. While the user at the managing side100is performing operation, the managing side100also sends an inquiry signal101to each of the nodes which have not ever returned responses actively, thereby confirming if there exist tangible managed sides at the node addresses. Thereafter, the managing side100further requests these managed sides to return their respective service information, thereby establishing a second list120. Then, the managing side100provides the second list120to the user for continuing the user's operation.

In view of the forgoing, the IPMI server management system of this embodiment can greatly reduce the time for waiting a plurality of managed sides (such as various servers or signal sensors) to return responses while the user is performing operation at the managing side100, thus promoting the operation efficiency of the IPMI server management system. Concretely speaking, the managing side100first performs broadcast via an address protocol (ARP) to confirm if tangible managed sides at the node addresses exist at the respective server nodes, and then requests each of the managed sides to return its available service information to establish the second list120. Hence, the service information211actively returned by each of the active IPMI managed sides210include its address message, which is advantageous to establishing the first list110.

Referring toFIG. 3,FIG. 3is a flow chart showing an IPMI server management method according to an embodiment of the present invention. The IPMI server management method includes the following steps. At first, in step310, at least one active IPMI managed side actively provides at least one set of service information to a managing side. Then, in step320, a first list is established at the managing side in accordance with the aforementioned service information, and the first list is provided to a user for performing operation. Thereafter, in step330, the managing side searches out a plurality of managed sides which are not included in the first list, so as to establish a second list, and then provided the second list to the user. Therefore, the IPMI server management method can list the available managed sides in the first list shortly, thus effectively sorting out a plurality of managed sides which are available for application.

It is noted that, whenever a new active IPMI managed side is added to the server nodes, the newly added active IPMI managed side also will send new service information for updating the first list. Further, in this embodiment, the active IPMI managed sides can be set to update their respective service information in every predetermined period of time, and thus, when an active IPMI managed side is withdrawn from providing service halfway, the change can be reflected on the first list timely. Alternatively, in this embodiment, the active IPMI managed sides also can be set to actively issue an empty signal when withdrawing from the server nodes, so as to notify the managing side to update the first list timely. Therefore, the related variations are all within the scope of this embodiment.

In view of the forgoing, in this embodiment, the managing side also may issue inquiry signals in every predetermined period of time to confirm the managed sides (i.e. non-active IPMI managed sides) which are not included in the first list one by one, thereby updating the second list timely.

Further, this embodiment also may optionally merge the first list with the second list for displaying them to the user simultaneously; or separately displays those two lists. For the sake of completeness, the managing side of this embodiment also may issue inquiry signals to the active IPMI managed sides at an idle period after obtaining the first list and the second list, thereby confirming if the first list is correct.

Referring toFIG. 4(a) andFIG. 4(b),FIG. 4(a) andFIG. 4(b) depict a flow chart showing the detailed steps of the IPMI server management method shown inFIG. 3. This embodiment first confirms if a plurality of network addresses are binding to the respective tangible managed sides, and then obtains the service information of the respective tangible managed sides. At first, step411is performed to activate the managed sides, and step421is performed to activate the managing side. Then step412is performed to arrange their service information including address messages, wherein the service information further includes notification time setting data. The notification time setting data define a predetermined period of time, wherein the active IPMI managed sides will actively issue notification packets to the managing side in very predetermined period of time; a waiting period of time, wherein the active IPMI managed sides will wait the waiting period of time to issue notification packets again to the managing side, when having not received return packets from the managing side for a certain period of time after first issuing the notification packets to the managing side; and a number of times of the notification packets issued when the active IPMI managed sides do not receive return packets from the managing side. Thereafter, step413is performed to deliver the address messages, and step414is performed to confirm if the delivery of the address messages is successful. When the result of step414is yes, it means to the managing side that a certain address has been successfully binding to a tangible active IPMI managed side. Meanwhile, in step422, the managing side starts collecting the address messages actively returned after being activated, meaning that there are tangible managed sides existing on those network addresses.

Thereafter, in steps415and423, the active IPMI managed sides send their service information, and the managing side collects the service information. Then, in step424, the managing side establishes the first list, and the first list has included a few of network addresses and their corresponding service information.

Then, step431is performed to activate searching function at the managing side for learning at what addresses the tangible managed sides still exist, and inquire of each tangible managed side about its service information.

It is noted that, in step432, the managing side first excludes the addresses listed in the first list from the addresses to be searched. In other words, the managing side first checks if the addresses to be searched are within the range of the first list. If the result is yes, step500is performed to display the list, since the addresses to be searched have existed in the first list, and the managing side does not need to waste time and effort for searching them. If the result is no, in step433, the managing side further checks if these addresses have been binding to the second list generated in the previous operation. If a certain address has existed in the second list, step500is performed and the certain address does not need to be checked again.

Thereafter, if an address does not exist in the first list or the second list, step434is performed to perform an ARP broadcast for confirming if the address is corresponding to a tangible managed side. If the address is an empty address, this embodiment returns to step433to search for a next address which does not exist in the first list and the second list, thereby checking the next address.

If there is a tangible managed side actually existing at the address mentioned in step434, step435is performed to perform a ping-pong process of IPMI. When the tangible managed side at the address smoothly produces a pong response, step436is performed to obtain the service information of the tangible managed side, and step437is performed to add its address and service information to the second list.