Patent Application
20080313319
The present invention is directed to a method and system for providing multi-protocol access to remote computers, and in one embodiment to a method and system for providing in-band and out-of-band access to a remote computer with automatic failover between the two types of access.
U.S. patent application Ser. No. 10/881,211 discloses, as described in its abstract, a system and method for out-of-band network management wherein one or more different management interfaces are converted into a common format management data. In that application, a number of various communications protocols can be used to communicate between a remote administration system and the computer(s) being monitored. The entire contents of that application are incorporated herein by reference.
The following description, given with respect to the attached drawings, may be better understood with reference to the non-limiting examples of the drawings, wherein:
In systems such as those disclosed in U.S. patent application Ser. No. 10/881,211, a remote administrator can configure his/her computer to select from one of a plurality of different connection protocols when attempting to connect to remote computers which he/she is administering. The protocols may be either in-band protocols, that rely on the computer's normal communication network, or out-of-band protocols, that rely on alternative communication connections. Examples of in-band management tools include HP OPEN VIEW IBM TIVOLI, BMC PATROL, and CA UNICENTER remote computer management products. The in-band management tools generally rely on network protocols, such as Simple Network Management Protocol (SNMP), which are commonly used to manage large networks. Use of in-band management tools can reduce the needed hardware required to remotely manage computer systems as the computer being monitored can be at least partially responsible for transmitting its own keyboard, video and mouse signals to the remote administration system. Such systems may also benefit from the ability to upgrade the monitored system's software without the need for a hardware upgrade as might be needed with an out-of-band-solution. Such systems may also provide information between the remote administration system and the remotely monitored system that is not available in out-of-band communications.
However, in-band tools become ineffective whenever the data network associated with the network nodes fails or a managed device loses network connectivity. Thus, these in-band network management tools leave network administrators in a deadlock position (e.g., the device fails and brings the data network down and the administrator cannot reach the device because the data network is down). Examples of common causes of the deadlock position include software crashes, configuration errors, hardware malfunctions caused by power surges, need to upgrade firmware and/or network failures. Thus, failures that cause the network node to be disconnected from the data network require a human operator to travel to the location where the network node is located so that the human operator can interact with the piece of failing equipment through a terminal directly connected to a management port or actuate physical control switches to restore functionality of the failing equipment. The need to have a human operator travel to the location of the network node is expensive, causes a great amount of time to be spent by the human operator, and causes business losses by causing long data network downtime.
To overcome this limitation of in-band network management tools, systems can use out-of-band management ports and other control functions, such as power-cycling, monitoring of temperature and other health indicators, without the need for a human operator to physically travel to the location where the incident occurred. Typically, the physical interfaces for out-of-band access includes serial consoles, KVM ports, power circuits, temperature and humidity probes and/or remote actuators. While effective, the building of an alternative, independent network using different connection media for out-of-band access increases the cost of building a data center.
In an effort to standardize the physical interface and reduce the cost of out-of-band access, an industry consortium has developed an interface called Intelligent Platform Management Interface (IPMI). Other vendors have created similar proprietary interfaces. For example, HP has its INTEGRATED LIGHTS-OUT (ILO) management interface and Sun Microsystems has its ADVANCED LIGHTS OUT MODULE (ALOM) management interface. The protocols for these interfaces are well known. These out-of-band management interfaces can only be used with certain types of network nodes and define a protocol above TCP/IP and utilize common Ethernet media for transport of the management information.
As shown in
Turning to
Using the in-band communication, the remote administration system may receive keyboard, video and mouse information as well as any other information that can be sent via in-band communications. Such other information may include information known to the computers (C1, C2 and C3) but which cannot be communicated over the out-of-band connection. Because of this additional information, or for any other reason, a user of the remote administration system may elect to preferably administer one or more of the computers (e.g., C1, C2 or C3) via an in-band communications protocol.
However, while a user may prefer to use in-band communication, the remote administration system's ability to communicate with the illustrated remote computers using in-band communications is contingent on many factors (e.g., the operability of the network over which the in-band communications is carried and, to some extent, the correct operation of the software on the remote computer). Accordingly, there may come a time (e.g., during a network outage) where the remote administration system can no longer communicate with the remote computer over the preferred communications protocol (e.g., using in-band communications). In such a case, a status detector of the remote administration system may detect that an error has occurred (e.g., by “pinging” the remote computer and getting no response or by losing an open network connection) and then switch to a less preferred communications protocol (e.g., using out-of-band communications).
Alternatively, in the case of a remote computer “crashing” and becoming incapable of sending its own keyboard, video, and mouse signals over an in-band connection, the status detector of the remote administration system may detect that it has not received any data (e.g., keyboard, video or mouse data) from the remote computer within a set period of time and switch to a less preferred communications protocol (e.g., using out-of-band communications). Using out-of-band communication, the administration system can then connect to a converter 210 that is connected to a corresponding computer (e.g., using conventional KVM connections 220). By using this out-of-band communications, the administrator at the remote administration computer may see the state of the machine during times when the in-band software is not available (e.g., after crashes or during power-up).
Each of the converters of
A preference setting interface (e.g., a command line interface, a custom graphical user interface or a web interface) specifies the relative preferences between the various communications protocols. Although the relative preferences described above set the in-band communication protocol to be of a higher preference than the out-of-band communication protocol, the reverse is also possible.
Although separate converters 210 were illustrated with respect to
In addition to the other methods described above for determining when a remote administration system should switch between protocols, the switch can also occur based on a request received from a converter 210 or 310. For example, if the converter detects a specified output on a video connection (e.g., mostly a blue screen) of a computer which has been specified as a computer running MICROSOFT WINDOWS operating system, the converter may automatically send a message to the status detector of the remote administration system over the out-of-band communication channel. Similarly, if a computer (e.g., C1) detects an error condition (e.g., a failed network card) that may not have been detected by the remote administration system yet, the computer may send a message (e.g., using a peripheral connection such as a USB connection) to its associated converter 210 or 310 such that the converter may automatically send a message to the remote administration system over the out-of-band communication channel. The status detector of the remote administration system may even detect degradations in performance which would warrant a change from a more preferred protocol to a less preferred protocol. The status detector may also detect that a status has changed such that communication using the more preferred communications protocol is possible again (e.g., after the repair of a network or a network card or after the rebooting of a crashed computer). The status detector may also respond to a command (e.g., a mouse or keyboard command) of a user or the expiration of a particular time period.
While the above has described a two-level set of preferences for connecting a remote computer to a remote administration system, several levels of preference may instead be used. For example, as shown in
Communication between a converter 210 or 310 and a computer need not be via peripheral connections or by any physical connections. The converter 210 or 310 and its computer may communicate over Ethernet cable and/or wirelessly. For example, the converter 210 or 310 and its computer may communicate over wireless USB. The converter 210 or 310 may also be connected optically.
While certain configurations of structures have been illustrated for the purposes of presenting the basic structures of the present invention, one of ordinary skill in the art will appreciate that other variations are possible which would still fall within the scope of the appended claims.
