Server Status Monitoring System and Method Using a Baseboard Management Controller

Abstract

In systems and methods that use a Baseboard Management Controller (BMC) to monitor the status of a server, the BMC can access status codes generated in domain 0 of the server via a command-line interface to the server and send these status codes to an alarm management system. The BMC can also listen for status codes generated in the server's management program via input / output port 80h and send these status codes to the alarm management system. Furthermore, the BMC can read status codes generated in the management program and written to a Model-Specific Register (MSR) and send these status codes to the alarm management system. The alarm management system can easily identify the occurrence of errors (including whether the error is a software error) and their causes in real-time or near real-time.

Description

Background Technology

[0001] Cloud-based services provide users with a large pool of shared resources within a cluster of servers. A central management controller (often called a Baseboard Management Controller (BMC)) plays a crucial role in managing the servers at any given time. The BMC also provides functionality for monitoring hardware and detecting hardware failures within the servers. When the BMC is connected to the server, a trust relationship is not established between the BMC and the server for security and confidentiality reasons. Therefore, the BMC cannot directly access the host memory within the server, nor can it initiate communication with the server. Because the BMC can only detect hardware failures and not software failures, it cannot detect failures in software running on the server, such as the hypervisor or domain 0. Due to these access restrictions and the design limitations of the BMC, when software on the server crashes or hangs, the infrastructure connected to the BMC manually initiates a connection to the server and attempts to determine the cause of the software failure after a period of time. This retrospective diagnostics results in time delays and may make it difficult to find the root cause of the system failure. Summary of the Invention

[0002] A first example embodiment relates to a system for monitoring the status of a server using a command-line interface and a Baseboard Management Controller (BMC) on a server. The system includes a BMC. The BMC is configured to connect to the server and open a session of the command-line interface on the server. The BMC sends a status code request to the server through the command-line interface session. In response to the status code request, the BMC determines whether it has received a status code from the server through the command-line interface session. If the BMC does not receive a status code within a predetermined time, the BMC rewrites the previous status code as an error status code. Then, when the status code indicates an error on the server, the BMC sends the status code to an alarm management system.

[0003] The second example embodiment relates to a method for monitoring the status of a server by listening to input / output (I / O) port 80h in the server. The method includes determining whether a status code has been received from the server by reading a status code provided on the server's I / O port 80h. The server's status code indicates the status of software running on the server. When the BMC does not receive a status code within a predetermined time, the BMC rewrites the previous status code as an error status code. Then, when the status code indicates an error on the server, the BMC sends the status code to the alarm management system.

[0004] The third example embodiment relates to a method for monitoring the status of a server by listening to a Model-Specific Register (MSR). The method includes determining whether the BMC has received a server status code by reading the MSR. The server status code indicates the status of the software running on the server. If the BMC does not receive a status code within a predetermined time, the BMC rewrites the previous status code as an error status code. When the status code indicates an error on the server, the BMC can send the status code to an alarm management system.

[0005] These and other embodiments, aspects, advantages, and alternatives will become readily apparent to those skilled in the art upon reading the following detailed description and, where appropriate, referring to the accompanying drawings. Furthermore, it should be understood that the inventive summary and other descriptions and drawings provided herein are intended to illustrate the embodiments by way of example only, and therefore many variations are possible. For example, combinations, distributions, eliminations, or other modifications may be made while remaining within the scope of the claimed embodiments. Attached Figure Description

[0006] Figure 1 The illustration shows an exemplary schematic diagram of a server status monitoring system using a Baseboard Management Controller (BMC).

[0007] Figure 2 An example server system according to an embodiment of the present disclosure is illustrated.

[0008] Figure 3 This is a flowchart based on an example embodiment.

[0009] Figure 4 The illustration shows a second exemplary schematic diagram of a server status monitoring system using BMC.

[0010] Figure 5 This is a flowchart based on the second example embodiment.

[0011] Figure 6 The illustration shows a third exemplary schematic diagram of a server status monitoring system using BMC.

[0012] Figure 7 This is a flowchart based on the third example embodiment. Detailed Implementation

[0013] Reference will now be made in detail to embodiments, examples of which are illustrated in the accompanying drawings. The terminology used in the description herein is for the purpose of describing particular embodiments only and is not intended to be limiting. Any embodiment or feature described herein as “example” or “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or features. Other embodiments may be utilized, and other changes may be made without departing from the scope of the subject matter set forth herein. It will be readily understood that aspects of this disclosure as generally described herein and illustrated in the figures can be arranged, substituted, combined, separated, and designed into a variety of different configurations, all of which are explicitly contemplated herein.

[0014] 1. Overview

[0015] As mentioned above, Figure 1 , Figure 4 and Figure 6 Three exemplary schematic diagrams corresponding to three corresponding example embodiments are illustrated. As a brief overview, to overcome traceability diagnostics problems, the Baseboard Management Controller (BMC) 200 can function by monitoring the status of the software running on server 100 or host processor 160. This disclosure describes how the BMC 200 monitors and detects software errors in the software running on server 100 and how such errors are forwarded to an alarm management system 300, which manages server 100 in a real-time (or near-real-time) manner in an automated manner. First ( Figure 1 The BMC 200 can access the status codes generated in domain 0150 of the server 100 via the command-line interface 130 on the serial port of the BMC 200 or on the universal asynchronous transceiver (UART) 210, and send the status codes to the alarm management system 300. Secondly ( Figure 4 The BMC 200 can provide the status code generated in the management program 110 of server 100 on the input / output (I / O) port 80h 120 of server 100. BMC 200 can listen to I / O port 80h and obtain the status code, and BMC 200 can send the status code to the alarm management system 300. Third ( Figure 6 The status code generated in the management program 110 can be written into a dedicated register (MSR) 121 for the model. The BMC 200 can obtain the status code by reading the MSR 121, and the BMC 200 can send the status code to the alarm management system 300. These exemplary systems and methods for monitoring the status of server 100 enable the alarm management system 300 to easily identify the occurrence of errors (including the type of error, such as software errors) and the cause of errors in real time or near real time. Therefore, these exemplary methods can overcome the time delay and difficulty in finding the root cause of server 100 failures in traceability diagnostic methods.

[0016] 2. Example server status monitoring system using the BMC and command-line interface in the server

[0017] a. Server hardware components

[0018] Figure 1 This is a simplified block diagram illustrating a server status monitoring system 10 using a BMC 200 and a command-line interface 130 running on server 100. In this example, server 100 may include a processor 160, a data storage device 170, a network interface 180, and multiple input / output interfaces 190, all of which may be coupled via a system bus or similar mechanism. Processor 160 may include one or more central processing units (CPUs), such as one or more general-purpose processors and / or one or more special-purpose processors (e.g., application-specific integrated circuits (ASICs), digital signal processors (DSPs), and / or network processors).

[0019] Data storage device 170 may then include volatile and / or non-volatile data storage devices and may be integrated integrally or partially with processor 160. Data storage device 170 may store processor-executable program instructions 160, as well as data that can be manipulated by the instructions to perform the various methods, processes, or functions described herein. Alternatively, these methods, processes, or functions may be defined by hardware, firmware, and / or any combination of hardware, firmware, and software. For example, the data in data storage device 170 may include program instructions, which may be stored on a non-transitory computer-readable medium, executable by processor 160 to perform any methods, processes, or functions disclosed in the specification or drawings.

[0020] The input / output interface 190 can be wired, such as via Ethernet, Token Ring, or T-Carrier. The network interface 180 can also be wireless, such as via IEEE 802.11 (Wi-Fi). Alternatively, a wide-area wireless connection can be used. However, other forms of physical layer connections and other types of standard or proprietary communication protocols can be used. Furthermore, server 100 can have an out-of-band network channel with BMC 200, since server 100 and BMC 200 do not have a trust relationship established for security, confidentiality, or other reasons. An out-of-band network channel is a serial line connection between server 100 and UART 210 in BMC 200. This serial line connection to UART 210 allows BMC 200 to diagnose the software of server 100 in both active and inactive serial sessions to server 100.

[0021] Figure 2A non-limiting embodiment of the server 100 described above is illustrated schematically. The server 100 is shown in a simplified form. The server 100 may take the form of one or more personal computers, server computers, tablet computers, home entertainment computers, network computing devices, gaming devices, mobile computing devices, mobile communication devices (e.g., smartphones), and / or other computing devices and wearable computing devices, such as smartwatches and head-mounted augmented reality devices.

[0022] Server 100 includes a logic processor 101, volatile memory 102, and non-volatile storage device 103. Server 100 may optionally include a display subsystem 104, an input subsystem 105, a communication subsystem 106, and / or... Figure 2 Other components not shown.

[0023] The logic processor 101 includes one or more physical devices configured to execute instructions. For example, the logic processor 101 may be configured to execute instructions that are part of one or more applications, programs, routines, libraries, objects, components, data structures, or other logical constructs. Such instructions can be implemented to perform tasks, implement data types, transform the state of one or more components, achieve technical effects, or otherwise achieve desired results. The logic processor 101 can be coupled with… Figure 1 , Figure 4 and Figure 6 The processor is the same as 160.

[0024] The logic processor 101 may include one or more physical processors (hardware) configured to execute software instructions. Alternatively or additionally, the logic processor 101 may include one or more hardware logic circuits or firmware devices configured to execute hardware-implemented logic or firmware instructions. The processor of the logic processor 101 may be single-core or multi-core, and the instructions executed thereon may be configured for sequential, parallel, and / or distributed processing. Individual components of the logic processor may optionally be distributed across two or more separate devices that may be remotely located and / or configured for coordinated processing. Aspects of the logic processor may be virtualized and executed by remotely accessible networked computing devices configured in a cloud computing configuration. In this case, these virtualized aspects run on different physical logic processors on various different machines.

[0025] The non-volatile storage device 103 includes one or more physical devices configured to store instructions executable by a logic processor to implement the methods and processes described herein. When such methods and processes are implemented, the state of the non-volatile storage device 103 can be transformed—for example, to store different data.

[0026] The non-volatile storage device 103 may include removable and / or built-in physical devices. The non-volatile storage device 103 may include optical memory (e.g., CD, DVD, HD-DVD, Blu-ray disc), semiconductor memory (e.g., ROM, EPROM, EEPROM, flash memory), and / or magnetic memory (e.g., hard disk drive, floppy disk drive, magnetic tape drive, MRAM) or other high-capacity storage technologies. The non-volatile storage device 103 may include non-volatile, dynamic, static, read / write, read-only, sequential access, location-addressable, file-addressable, and / or content-addressable devices. It will be understood that the non-volatile storage device 103 is configured to store instructions even when power to the non-volatile storage device 103 is cut off.

[0027] Volatile memory 102 may include a physical device including random access memory. Volatile memory 102 is typically used by logic processor 101 to temporarily store information during the processing of software instructions. It will be understood that volatile memory 102 typically does not continue storing instructions when power to it is cut off. Figure 1 , Figure 4 and Figure 6 The data storage device 170 includes a volatile memory 102 and a non-volatile memory device 103.

[0028] Various aspects of the logic processor 101, volatile memory 102, and non-volatile storage device 103 can be integrated together into one or more hardware logic components. For example, such hardware logic components may include field-programmable gate arrays (FPGAs), program- and application-specific integrated circuits (PASIC / ASIC), program- and application-specific standard products (PSSP / ASSP), system-on-a-chip (SOC), and complex programmable logic devices (CPLDs).

[0029] The terms "module," "program," "mechanism," and "engine" can be used to describe an aspect of server 100, typically implemented in software by a processor to perform a specific function using a portion of volatile memory. This function involves transformation processing that specifically configures the processor to perform that function. Therefore, a module, program, or engine can be instantiated by executing instructions stored in non-volatile storage device 103 via a portion of volatile memory 102 using logic processor 101. It will be understood that different modules, programs, mechanisms, and / or engines can be instantiated from the same application, service, code block, object, library, routine, API, function, etc. Similarly, the same module, program, mechanism, and / or engine can be instantiated from different applications, services, code blocks, objects, routines, APIs, functions, etc. The terms "module," "program," "mechanism," and "engine" can encompass individual or grouped executable files, data files, libraries, drivers, scripts, database records, etc.

[0030] When included, the display subsystem 104 can be used to present a visual representation of data stored by the non-volatile storage device 103. The visual representation may take the form of a graphical user interface (GUI). Since the methods and processes described herein change the data stored by the non-volatile storage device, and thus transform the state of the non-volatile storage device, the state of the display subsystem 104 can also be transformed to visually represent changes in the underlying data. The display subsystem 104 may include one or more display devices utilizing virtually any type of technology. Such display devices may be combined with the logic processor 101, the volatile memory 102, and / or the non-volatile storage device 103 in a shared housing, or such display devices may be peripheral display devices.

[0031] When included, the input subsystem 105 may include or be connected to one or more user input devices, such as a keyboard, mouse, touchscreen, or game controller.

[0032] When included, the communication subsystem 106 can be configured to communicatively couple the various computing devices described herein to each other and to other devices. The communication subsystem 106 may include wired and / or wireless communication devices compatible with one or more different communication protocols. As a non-limiting example, the communication subsystem can be configured to communicate via a wireless telephone network, or a wired or wireless local area network or wide area network (such as HDMI based on Wi-Fi connectivity). In some embodiments, the communication subsystem may allow server 100 to send messages to and / or receive messages from other devices via a network such as the Internet. The communication subsystem 106 can be coupled with… Figure 1 , Figure 4 and Figure 6 The network interface 180 is the same.

[0033] b. Server software components

[0034] The processor 160 of server 100 can run software including hypervisor 110, command-line interface 130, mini-kernel 140, and domain 0 150. Hypervisor 110, or virtual machine monitoring program, can be computer software that creates and runs virtual machines. Hypervisor 110 virtualizes the server's hardware. Hypervisor 110 shares the server's virtualized CPU, memory, and network resources between domains that are independent of the server's hardware specifications. Hypervisor 110 can control the server's hardware and domains. Hypervisor 110 controls and manages user domains across domains through special domains referred to as domain 0 150, dom0, or enlightened guest domains. In one configuration, a user domain might be a non-privileged domain that does not have direct access to the server's hardware. When hypervisor 110 controls the server's hardware, it can leave its state in data storage device 170. The state of hypervisor 110 can indicate the last process executed by hypervisor 110, or what process hypervisor 110 is currently executing. If the status of the management program 110 indicates an error in the management program 110, then the status can indicate where and why the management program 110 encountered the error (or why the management program 110 has crashed).

[0035] Even when server 100 is unresponsive, command-line interface 130, serial console interface, or the Special Management Console (SAC) of Microsoft Windows can access domain 0 150 and minikernel 140 via a serial port (or other port). Command-line interface 130 acts as an input / output interface for BMC 200 to access server 100, particularly domain 0 150. This out-of-band communication is particularly effective when server 100 is unresponsive or in a crash state. Command-line interface 130 can collect crash dumps of server 100. Therefore, if domain 0 150 or a user domain controlled by domain 0 150 is in a crash state or unresponsive, command-line interface 130 can listen to the crash dump and leave the error state of domain 0 150 or the user domain in data storage device 170. The error state of domain 0 150 or the user domain can indicate where and why the error occurred or why the domain 0 150 or the user domain is in crash mode. If command-line interface 130 can access hypervisor 110, then command-line interface 130 can provide not only the status of domain 0 150 or user domains, but also the status of hypervisor 110. However, some servers do not provide access to command-line interface 130 for hypervisor 110 because command-line interface 130 is in a higher software stack than hypervisor 110. In this case, the example server status monitoring system 20 using I / O ports 80h 120 in server 100, or as described below with... Figure 6 The example server status monitoring system 30, which uses a dedicated register (MSR) 121 for the model, as described in more detail in the related discussion, can be used to monitor the status of the hypervisor 110.

[0036] c. Baseboard Management Controller (BMC)

[0037] The BMC 200 is a central management controller, typically a system-on-a-chip (SoC) embedded on the main board or motherboard. The BMC 200 communicates with the server 100 via out-of-band channels. The BMC 200 can monitor hardware connected to the motherboard, such as power supply voltage, fan speed, humidity, and temperature. Since the BMC 200 does not have any direct capability to monitor the software running on the server 100, the serial port in the BMC 200 can be used to connect to the command-line interface 130 to diagnose the status of the software running on the server 100. The serial port can be a special controller chip, such as the UART 210, which enables the BMC 200 to communicate via a serial line. The BMC 200 can diagnose certain data of the server 100 through the command-line interface on top of the UART 210. However, it should be understood that the serial port is not limited to the UART 210 for communication with the command-line interface 130. Any other suitable interface in the BMC 200 can also be used to communicate with the command-line interface 130. For example, the System Management Bus (SMBus) in BMC 200 can be connected to the BMC's Network Interface Chip (NIC) or Local Area Network (LAN) controller. Therefore, BMC 200 can open a session with the command-line interface 130 of server 100 via the NIC or LAN. LAN traffic from the command-line interface 130 conforms to Serial over LAN (SOL). LAN traffic may include server status codes to allow BMC 200 to access this information.

[0038] The BMC 200 can connect to a non-volatile data storage device. This non-volatile data storage device can be fully or partially integrated with the BMC 200. The data storage device can store System Event Logs (SELs), Sensor Data Records (SDRs) repositories, Field Replaceable Unit (FRU) inventory information, and server status codes. Server status codes can be stored in the non-volatile data storage device. However, server status codes can also be forwarded directly to the alarm management system 300 without first residing in the data storage device. In this case, the server status codes stored in the cache are forwarded directly to the alarm management system 300. This improves efficiency by reducing computational power, saving the time spent storing codes in the data storage device; and also allows the server 300 to...

[0039] The BMC 200 also communicates with the alarm management system 300 via an out-of-band channel. The BMC 200 can forward server software status codes and / or hardware status codes to the alarm management system 300. A serial port in the BMC 200 can be connected to the alarm management system 300 to transmit server software and hardware status codes. The serial port can be a special controller chip, such as the UART 210, which enables the BMC 200 to communicate via a serial line. However, it should be understood that the UART 210 is not the only port for communication with the alarm management system 300. Any other suitable interface in the BMC 200 can be used to communicate with the alarm management system 300. For example, the SMBus in the BMC can be connected to a network interface chip or a LAN controller. The LAN connects the network interface chip to the alarm management system 300. LAN traffic to the alarm management system 300 conforms to the Standard Operating Procedure (SOL). LAN traffic may include server status codes.

[0040] d. Alarm Management System

[0041] The alarm management system 300 is connected to the BMC 200 via an out-of-band channel. The alarm management system 300 receives server status codes from the BMC 200 and provides alerts in real-time or near real-time regarding the presence of errors on the server 100. The alarm management system 300 can be a structured computing system and uses a publish-subscribe or pub / sub mechanism. The pub / sub mechanism allows the alarm management system 300 to operate independently of the BMC 200. Furthermore, the BMC 200 does not need to program the server 100's status codes to be sent directly to subscribers in the pub / sub mechanism. Instead, the server 100's status codes can be categorized into error types such as domain 0 errors, hypervisor errors, and hardware errors. The categorized status codes can be sent to the appropriate alarm management system 300 that can handle specific types of errors. However, it should be understood that the mechanism used to send the server 100's status codes to the alarm management system 300 is not limited to the pub / sub mechanism. Observable patterns and other appropriate mechanisms can be used to send the server 100's status codes to the alarm management system 300.

[0042] e. Communication between the server and BMC

[0043] Command line interface 130 can communicate with server 100 via serial port. The serial port on server 100 can be connected to UART 210 in BMC 200 via LAN using SOL. However, it should be understood that other communication channels can be used to connect server 100 and BMC 200. For example, a low pin counter (LPC) bus can be used to connect server 100 and BMC 200. When using SOL, command line interface 130 can transmit server status codes via LAN. Furthermore, in addition to a physical connection, network interface 180 can also be used for wireless connections, such as IEEE 802.11 (Wi-Fi). Or wide-area wireless connection.

[0044] f. Methods for using BMC to monitor server status

[0045] Figure 3 The diagram illustrates a flowchart of a method for monitoring server status using BMC 200. In operation S410, a status code for server 100 is generated. The status code for server 100 can be generated in data storage device 170 within domain 0 150 of server 100. The status code for server 100 can be the status of software running on server 100. This software may include hypervisor 110, domain 0 150, and user domains. Some command-line interfaces 130 can only access domain 0 150 and user domains, and not hypervisor 110. If this is the case, the status code for server 100 may be restricted to the status of domain 0 150 and user domains. In this case, the status of hypervisor 110 can be determined by the data storage device 170 within server 100 (see [link to documentation]). Figure 4 Example server status monitoring system 20 listens on I / O port 80h 120 in the system, or uses a dedicated register (MSR) 121 as described below (see below). Figure 6 The example server status monitoring system 30 monitors the system. Default status codes indicate that the software is functioning properly or in an error-free state. However, when an error exists in the software, an error status code indicating the error overrides the previous status code. Error status codes can include the location and cause of the error.

[0046] In operation of S420, BMC 200 can connect to server 100 and may be able to open a session of command-line interface 130 on server 100 via the serial port (UART) of BMC 200. Command-line interface 130 can access domain 0150 and retrieve the status code of server 100 located in domain 0150.

[0047] In operation of S430, BMC 200 can send status code requests to server 100 via command line interface 130.

[0048] In operation S440, in response to a status code request from BMC 200, server 100 sends a status code to BMC 200 via command-line interface 130. BMC 200 can diagnose the status codes printed on command-line interface 130 from server 100. BMC 200 can open a session on command-line interface 130 and send status code requests to server 100 at regular intervals. The periodically sent or received signals can be used as heartbeats to synchronize other hardware connected to BMC 200. Furthermore, this can be used as a request-response model.

[0049] In operation S450, it is determined whether BMC 200 has received the status code from server 100. BMC 200 can receive the status code from server 100 by reading the status code printed on command line interface 130. UART 210 in BMC 200 is a serial port used to receive the status code from server 100 via command line interface 130.

[0050] If BMC 200 has received the status code from server 100, then in operation S500, it sends the status code of server 100 to alarm management system 300. If in operation S450 it is determined that BMC 200 has not received the status code from server 100, then in operation S460, BMC 200 determines whether a predetermined time has elapsed. If the predetermined time has not elapsed, then operation S460 returns to operation S450. If the predetermined time has elapsed, then in operation S470, BMC 200 makes a preliminary conclusion that server 100 has encountered an error. This failure to receive a status code can indicate two possible situations: 1) BMC 200 has not received a status code as a server response to a status code request from BMC, or 2) BMC 200 anticipates a status code at regular intervals, but does not receive a status code after the interval.

[0051] The initial conclusion of an error on server 100 prompts BMC 200 to rewrite the status code to an error status code in operation S470. After the status code is rewritten, in operation S480, it is determined again whether BMC 200 has received the status code. If BMC has received the status code from server 100, then in operation S490, the status code is rewritten to the status code received from server 100. This prevents BMC 200 from hastily sending error messages to the alarm management system 300 when network traffic may delay receiving status codes. In operation S500, when the status code indicates an error on server 100, BMC 200 sends the status code to the alarm management system 300. In one configuration, a status code can only be sent to the alarm management system 300 if the status code indicates an error on server 100. In another configuration, a status code can be sent to the alarm management system 300 regardless of the error indication on server 100. In this case, the alarm management system 300 can filter out error status codes and handle errors on server 100.

[0052] Because these operations are handled automatically, the alarm management system 300 can easily detect software errors on the server 100 in almost real time.

[0053] 3. Example of a server status monitoring system using I / O port 80h on the server

[0054] a. Server I / O ports

[0055] Figure 4 This is also a simplified block diagram of a server status monitoring system 20 that listens on I / O port 120 in server 100. The I / O port can be I / O port 80h 120 in the server. Server 100 can send its status code to I / O port 80h 120. BMC 200 can listen on I / O port 80h 120 and receive the server 100's status code by reading the status code on I / O port 80h 120. Then, BMC 200 can send the server 100's status code to alarm management system 300.

[0056] The BMC 200 typically has the capability to listen on server 100 using I / O port 80h 120 with Power-On Self-Test (POST) codes. When the Basic Input / Output System (BIOS) performs a built-in self-test against the hardware, it generates codes and sends them to I / O port 80h 120. Basic hardware health is generally related to the host processor, memory / chipset, input / output buses, output devices, input devices, and boot devices. However, server 100's I / O port 80h 120 can be used in different ways to diagnose the software running on server 100. The software state can be the state of the last process executed by hypervisor 110, domain 0 150, or user domain. The software state can also be the state currently being executed by hypervisor 110, domain 0 150, or user domain. If the state of hypervisor 110, domain 0 150, or user domain indicates an error, that state can indicate where and why hypervisor 110, domain 0 150, or user domain is in an error or crash state. However, the state of the software can be restricted to the state of the hypervisor 110, and the hypervisor 110 may not access domains 0 and 150 and user domains because the hypervisor 110 is a lower-level software in the software stack.

[0057] If the management program 110 can perform monitoring of the status of the management program 110, domain 0 150, and user domains, then the status code can indicate the status of the management program 110, domain 0 150, or user domains. If the management program 110 is limited to monitoring its own status, or if the command-line interface 130 cannot access the management program 110, then the status code can be restricted to the status of the management program 110. In this case, an example monitoring system 10 using BMC 200 and command-line interface 130 can be used instead. Therefore, in addition to monitoring domain 0 150 and user domains via command-line interface 130, the management program 110 can independently send its status to I / O port 80h 120 of server 100.

[0058] b. Methods for using BMC to monitor server status

[0059] Figure 5The diagram illustrates a flowchart of a method for monitoring server status by listening to I / O port 80h 120 in server 100. In operation S510, a status code for server 100 can be generated in the hypervisor 110 of server 100. The status code of server 100 can be stored in data storage device 170, and the hypervisor 110 can access data storage device 170. However, the status code of server 100 can be directly sent to I / O port 80h 120 in the server, without being stored in data storage device 170. The status code of server 100 can be the status of software running on server 100. This software may include hypervisor 110, domain 0 150, and user domains. The default status code indicates that the software is error-free or operating normally. However, when an error exists in the software, the status code will be rewritten to an error status code indicating the error. The error status code may include information related to the timing of the error, the specific point of failure, and the cause of the failure.

[0060] In some cases, due to different software stacks, the hypervisor 110 may not be able to access the status codes of domain 0150 and the user domain. In this case, the hypervisor 110 may only generate the status code for the hypervisor 110. To monitor the status of domain 0150 and the user domain, the exemplary monitoring system described above using the command-line interface 130 and BMC 200 can also be used.

[0061] However, in some embodiments, the management program 110 can monitor the status of the management program 110, domain 0 150, and user domains by accessing status codes stored in the data storage device 170. The data storage device 170 includes the status of domain 0 150 and user domains. In this case, the command-line interface 130 and BMC 200 (see above) are used. Figure 1 The exemplary monitoring system may not be necessary.

[0062] In operation of S520, the hypervisor 110 sends status codes to I / O port 120 of server 100. The hypervisor 110 can send status codes to I / O port 120 at regular intervals. The periodically sent signals can be used as heartbeats to synchronize with other hardware connected to BMC 200. I / O port 120 of server 100 can be I / O port 80h 120 of server 100. This out-of-band communication can remain operational even when server 100 is unresponsive or in a crashed state, and the cause of system failure can be determined by listening to I / O port 80h 120 of server 100, and the failure and its cause can be reported to the alarm management system 300 almost in real time.

[0063] In operation S530, BMC 200 determines whether it has received a status code through I / O port 80h 120 of server 100. BMC 200 can receive the status code of server 100 by reading the status code provided on I / O port 80h 120 of server 100.

[0064] In operation S530, it is determined whether BMC 200 has received the status code from server 100. If BMC 200 has received the status code from server 100, operation S580 is performed. In operation S580, the status code of server 100 is sent to alarm management system 300. If it is determined during operation S530 that BMC 200 has not received the status code from server 100, in operation S540, BMC 200 determines whether a predetermined time has elapsed. If the predetermined time has not elapsed, operation S540 returns to operation S530. On the other hand, if it is determined in operation S540 that the predetermined time has elapsed, in operation S550, BMC 200 makes a preliminary conclusion that server 100 has encountered an error. This failure to receive a status code can include situations where BMC 200 anticipates a status code at fixed intervals but fails to receive a status code after that interval. In operation S550, the preliminary conclusion causes the status code to be rewritten as an error status code. However, after the status code is rewritten due to elapsed time, in operation S560, it is re-determined whether the BMC 200 has received the status code from the server 100. Then, if the BMC has received the status code from the server 100, in operation S570, the status code in operation S550 is rewritten to the status code received from the server 100. This prevents the BMC 200 from hastily sending an error message to the alarm management system 300 when network traffic (or other issues unrelated to the server) might delay the receipt of the status code. In operation S580, when the status code indicates an error on the server 100, the BMC 200 sends the status code to the alarm management system 300. If the status code indicates an error on the server 100, the status code can be sent to the alarm management system 300. However, regardless of the error indication on the server 100, or for a specific set of status codes, the status code can be sent to the alarm management system 300. In this case, the alarm management system 300 can filter out the error status code and handle the error on the server 100.

[0065] Because these operations are handled automatically, the alarm management system 300 can easily detect software errors on the server 100 in almost real time.

[0066] 4. Using MSR's sample server status monitoring system

[0067] a. Model-specific registers (MSR)

[0068] Figure 6 This is a simplified block diagram illustrating a server status monitoring system 30 that uses BMC 200 and the MSR accessible by server 100 and BMC 200. MSR 121 may be referred to as an erase register, a mode-specific register, or a machine-specific register. Some BMCs may not include it. Figure 4 The I / O ports shown are 80h and 120, or alternative systems may be needed or required. Alternatively, alternative systems may also be used. Figure 6 The MSR 121 shown replaces I / O port 80h 120 to receive server status codes. The BMC 200 can provide mechanisms for detecting and reporting hardware (machine) errors, such as system bus errors, ECC errors, parity errors, cache errors, and TLB errors. The BMC 200 can access a set of model-specific registers (MSRs) used to set up machine checks and an additional set of MSRs for logging detected errors. MSRs are typically used to check for hardware errors. However, the MSR 121 can be programmed to detect software errors in server 100. The MSR 121 can be configured on either server 100 or BMC 200.

[0069] Hypervisor 110 can monitor the status of software running on server 100 and request processor 160 in server 100 to write a status code of the software running on server 100 to MSR 121. Processor 160 can instruct the server 100 to write a status code to MSR 121. If hypervisor 110 can monitor (or "can perform its monitoring") the status of hypervisor 110, domain 0 150, and user domains, the status code of server 100 can be the status of hypervisor 110, domain 0 150, or user domains. If hypervisor 110 is limited to performing monitoring of the status of hypervisor 110, or if command-line interface 130 may not be able to access hypervisor 110, the status code will be restricted to the status of hypervisor 110. In this case, BMC 200 and command-line interface 130 can be used instead (see [link to BMC 200]). Figure 1 Example monitoring system 10.

[0070] The BMC 200 can access the status codes written to MSR 121. The BMC 200 can receive the status codes of the server 100 by reading MSR 121. By analyzing the status codes of the server 100, the BMC 200 can identify where the software running on the server 100 is located and why it encountered an error.

[0071] Other components in this exemplary server status monitoring system 30 may be the same as or similar to those in the exemplary server status monitoring system 20 that uses I / O ports 80h 120 of server 100.

[0072] b. Methods for using BMC to monitor server status

[0073] Figure 7 The diagram illustrates a flowchart of a method for monitoring server status using MSR 121, which is accessible from BMC 200. In operation S610, a status code for server 100 can be generated in the hypervisor 110 of server 100. The status code for server 100 can be stored in data storage device 170, and the hypervisor 110 can access data storage device 170. However, the status code for server 100 can be written directly to MSR 121 without being stored in data storage device 170. The status code for server 100 can represent the status of software running on server 100. This software may include hypervisor 110, domain 0150, and user domains. The default status code indicates that the software is in good condition. However, when an error exists in the software, the status code will be rewritten to an error status indicating the error. The error status code may include the location and cause of the error.

[0074] In some cases, management program 110 may not be able to access the status codes of domain 0150 and user domains. In this case, management program 110 may only monitor management program 110 and generate its own status code. To monitor the status of domain 0150 and user domains, the exemplary monitoring system described above using command-line interface 130 and BMC 200 may be additionally required (see [link to documentation]). Figure 1 ).

[0075] However, if the management program 110 monitors the status of the management program 110, domain 0 150 and user domains, or accesses the status codes stored in the data storage device 170 indicating the status of domain 0 150 and user domains, then the exemplary monitoring system using the command line interface 130 and BMC 200 described above may not be required.

[0076] In operation S620, server 100 can write status codes to MSR 121, which is accessible from BMC 200. Specifically, hypervisor 110 can request processor 160 to write status codes to MSR 121. Then, processor 160 of server 100 can write the status codes to MSR 121. MSR 121 can be on server 100 or BMC 200. Server 100 can write status codes to MSR 121 at regular intervals. The periodically written signals can be used as heartbeats to synchronize with other hardware connected to BMC 200. This out-of-band communication remains operational even when server 100 is unresponsive or in a crashed state, and can function to monitor the cause of system failures and report them to alarm management system 300 in near real-time.

[0077] In operation S630, BMC 200 determines whether it has received a status code by reading MSR 121. If BMC 200 has received the status code from server 100, then in operation S680, the status code of server 100 is sent to alarm management system 300. If BMC 200 has not received the status code from server 100, then in operation S640, BMC 200 determines whether a predetermined time has elapsed. If the predetermined time has not elapsed, operation S640 returns to operation S630. If it is determined in operation S640 that the predetermined time has elapsed, then in operation S650, BMC 200 makes a preliminary conclusion that server 100 has encountered an error. This failure to receive a status code can include situations where BMC 200 expects to receive status codes at fixed intervals, but fails to receive a status code after that interval. In operation S650, this preliminary conclusion causes the status code to be rewritten as an error status code. However, after the status code is rewritten due to elapsed time, in operation S660, it is re-determined whether BMC 200 has received the status code from server 100. If BMC 200 has received the status code from server 100, then in operations S670 and S650, the status code is rewritten to the status code received from MSR 121. This prevents BMC 200 from hastily sending error messages to the alarm management system 300 when network traffic may delay receiving the status code. In operation S680, when the status code indicates an error on server 100, BMC 200 sends the status code to the alarm management system 300. In one configuration, a status code can be sent to the alarm management system 300 only when the status code indicates an error on server 100. In another configuration, a status code can be sent to the alarm management system 300 regardless of the error indication on server 100. In this case, the alarm management system 300 can filter out error status codes and handle errors on server 100.

[0078] Because these operations are handled automatically, the alarm management system 300 can easily detect software errors on the server 100 in almost real time.

[0079] 5. Conclusion

[0080] The exemplary server status monitoring system and method using BMC 200 described in detail above enable software errors on server 100 to be identified almost in real time. Therefore, these exemplary systems and methods overcome the time delays and difficulties encountered in retrospective diagnostic methods when identifying the root cause of server 100 failures.

[0081] According to one aspect of this disclosure, a system for monitoring the status of a server using a baseboard management controller includes: a baseboard management controller, wherein the baseboard management controller is configured to: connect to the server; open a command-line interface session on the server; send a status code request to the server through the command-line interface session; in response to the status code request, determine whether the baseboard management controller has received a status code from the server through the command-line interface session; rewrite the status code to an error status code when the baseboard management controller does not receive the status code within a predetermined time; and send the status code to an alarm management system when the status code indicates an error on the server.

[0082] In this respect, the substrate management controller is also configured to: after rewriting the status code to an error status code, determine again whether the substrate management controller has received a second status code from the server; and when the substrate management controller has received a second status code from the server after rewriting the status code to an error status code, rewrite the rewritten status code to the second status code received from the server.

[0083] In this regard, the baseboard management controller is equipped with a universal asynchronous transceiver (UART) to receive status codes from the server, and the baseboard management controller opens a command line interface session via the UART to receive status codes from the server.

[0084] In this regard, status codes are sent to the baseboard management controller at regular intervals.

[0085] In this regard, the command-line interface on the server accesses domain 0 to retrieve the status code.

[0086] In this respect, the server's status code is generated in domain 0 of the server.

[0087] In this respect, the state of the server refers to the state of the software running on the server.

[0088] In this respect, the software includes server domain 0.

[0089] In this regard, when the software is in an error-free state, the status code indicates that the software is in an error-free state, and when an error exists in the software, the status code indicates the cause and location of the error.

[0090] In this regard, the connection between the board management controller and the command line interface conforms to serial communication over a local area network (SOL).

[0091] According to another aspect of this disclosure, a method for monitoring the status of a server using a baseboard management controller includes: determining whether a status code of the server has been received from the server by reading a status code provided on an input / output port of the server, wherein the status code of the server indicates the status of software running on the server; rewriting the status code to an error status code when the baseboard management controller does not receive the status code within a predetermined time; and sending the status code from the baseboard management controller to an alarm management system when the status code indicates an error on the server.

[0092] In this regard, the method also includes generating a server status code in the server's management program; and sending the status code from the server's management program to the serial input / output port of the baseboard management controller.

[0093] In this regard, the server's input / output port is port 80h.

[0094] In this regard, after rewriting the status code to an error status code, it is determined again whether the baseboard management controller has received a second status code from the server; and when the baseboard management controller receives a second status code from the server after rewriting the status code to an error status code, the rewritten status code is rewritten to the second status code received from the server.

[0095] In this regard, the software includes management programs.

[0096] In this regard, when the software is in an error-free state, the status code indicates that the software is in an error-free state, and when an error exists in the software, the status code indicates the cause and location of the error.

[0097] According to another aspect of this disclosure, a method for monitoring the status of a server using a baseboard management controller includes: determining whether the baseboard management controller has received a status code of the server by reading a register dedicated to the model, wherein the status code of the server indicates the status of software running on the server; rewriting the status code to an error status code when the baseboard management controller does not receive the status code within a predetermined time; and sending the status code from the register dedicated to the model to an alarm management system when the status code indicates an error on the server.

[0098] In this regard, the method also includes: generating a server status code in the server's management program; and writing the status code from the server into a register dedicated to the model.

[0099] In this regard, the software includes management programs.

[0100] In this regard, when the software is in an error-free state, the status code indicates that the software is in an error-free state, and when an error exists in the software, the status code indicates the cause and location of the error.

[0101] This disclosure is not limited to the specific embodiments described herein, which are intended as illustrative of various aspects. Many modifications and variations can be made without departing from its scope, as will be apparent to those skilled in the art. Based on the foregoing description, functionally equivalent methods and apparatus within the scope of this disclosure, other than those listed herein, will be readily apparent to those skilled in the art. Such modifications and variations are intended to fall within the scope of the appended claims.

[0102] The detailed description above, with reference to the accompanying drawings, illustrates various features and functions of the disclosed systems, devices, and methods. The exemplary embodiments described herein and in the accompanying drawings are not intended to be limiting. Other embodiments may be utilized, and other changes may be made without departing from the scope of the subject matter set forth herein. It will be readily understood that aspects of this disclosure, as generally described herein and illustrated in the figures, can be arranged, substituted, combined, separated, and designed into various different configurations, all of which are explicitly contemplated herein.

[0103] Regarding the diagrams and any or all message flowcharts, scenarios, and flowcharts discussed herein, each step, block, and / or communication may represent the processing and / or transmission of information according to the example embodiments. Alternative embodiments are included within the scope of these example embodiments. In these alternative embodiments, for example, functions described as steps, blocks, transmissions, communications, requests, responses, and / or messages may be performed out of order with respect to the shown or discussed sequence, including substantially simultaneously or in reverse order, depending on the functionality involved. Furthermore, more or fewer blocks and / or functions may be used with any of the ladder diagrams, scenarios, and flowcharts discussed herein, and these ladder diagrams, scenarios, and flowcharts may be combined with each other in part or in whole.

[0104] A step or block representing information processing may correspond to a circuit system that can be configured to perform a specific logical function of the method or technique described herein. Alternatively or additionally, a step or block representing information processing may correspond to a program code module, segment, or portion (including associated data). Program code may include one or more instructions executable by a processor to implement a specific logical function or action in the method or technique. Program code and / or associated data may be stored on any type of computer-readable medium, such as a storage device, including a disk, hard disk drive, or other storage medium.

[0105] Computer-readable media can also include non-transitory computer-readable media, such as computer-readable media that store data for short periods of time, like register memory, processor cache, and random access memory (RAM). Computer-readable media can also include non-transitory computer-readable media that store program code and / or data for longer periods of time. Therefore, computer-readable media can include secondary or permanent long-term storage devices, such as read-only memory (ROM), optical discs or magnetic disks, and optical disc read-only memory (CD-ROM). Computer-readable media can also be any other volatile or non-volatile storage system. For example, computer-readable media can be considered as computer-readable storage media or tangible storage devices.

[0106] Furthermore, a step or block representing one or more information transfers may correspond to information transfers between software and / or hardware modules within the same physical device. However, other information transfers may occur between software and / or hardware modules in different physical devices.

[0107] The specific arrangements shown in the figures should not be considered limiting. It should be understood that other embodiments may include more or fewer of each of the given elements shown in the figures. Furthermore, some of the illustrated elements may be combined or omitted. Additionally, example embodiments may include elements not shown in the figures.

[0108] While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for illustrative purposes and are not intended to be limiting; the true scope is indicated by the appended claims.

Claims

1. A system for monitoring the status of a server using a baseboard management controller, comprising: The baseboard management controller The baseboard management controller is configured as follows: Connect to the server; A command-line interface session is opened on the server via the serial port of the baseboard management controller; The session through the command-line interface sends a status code request to the server; In response to the status code request, determine whether the baseboard management controller has received a status code from the server through the session of the command line interface, wherein the status code of the server indicates the status of the software running on the server, the software including a management program, domain 0, and user domains; If the baseboard management controller fails to receive the status code within a predetermined time, the status code will be rewritten as an error status code. as well as When the status code indicates an error on the server, the status code is sent to the alarm management system. The status code received from the server is generated in domain 0 of the server, and the command-line interface on the server accesses domain 0 to retrieve the status code.

2. The system of claim 1, wherein the baseboard management controller is further configured to: After rewriting the status code to the error status code, it is determined again whether the baseboard management controller has received the second status code from the server; and When the baseboard management controller has received the second status code from the server after rewriting the status code to the error status code, it rewrites the rewritten status code to the second status code received from the server.

3. The system of claim 1, wherein a Universal Asynchronous Receiver / Transmitter (UART) is disposed on the baseboard management controller. The baseboard management controller opens the session of the command-line interface via the UART to receive the status code from the server.

4. The system of claim 1, wherein the status code is sent to the baseboard management controller at regular intervals.

5. The system of claim 1, wherein when the software has an error-free state, the status code indicates the error-free state of the software, and When the error exists in the software, the status code indicates the cause and location of the error.

6. The system of claim 1, wherein the connection between the baseboard management controller and the command-line interface conforms to Serial Local Area Network (SOL).

7. A method for monitoring the status of a server using a baseboard management controller, comprising: Determine whether the status code has been received from the server by reading the server status code provided on the server's input / output port, wherein the server status code indicates the status of software running on the server, the software including a hypervisor, domain 0, and user domains, and wherein the server status code is generated in the server's hypervisor and sent to the server's input / output port. If the baseboard management controller fails to receive the status code within a predetermined time, the status code will be rewritten as an error status code. as well as When the status code indicates an error on the server, the status code is sent from the baseboard management controller to the alarm management system. The status code is sent from the server's management program to the serial input / output port of the baseboard management controller.

8. The method of claim 7, wherein the input / output port of the server is the input / output port 80h of the server.

9. The method of claim 7, wherein after rewriting the status code to the error status code, it is determined again whether the baseboard management controller has received the second status code from the server; and When the baseboard management controller has received the second status code from the server after rewriting the status code to the error status code, it rewrites the rewritten status code to the second status code received from the server.

10. The method of claim 7, wherein when the software has an error-free state, the status code indicates the error-free state of the software. When the error exists in the software, the status code indicates the cause and location of the error.

11. A method for monitoring the status of a server using a baseboard management controller, comprising: Determine whether the baseboard management controller has received a status code from the server by reading a register dedicated to the model, wherein the status code of the server indicates the status of software running on the server, the software including a hypervisor, domain 0, and a user domain, and wherein the status code of the server is generated in the hypervisor of the server, and the hypervisor requests a processor in the server to write the status code from the server into the register dedicated to the model; If the baseboard management controller fails to receive the status code within a predetermined time, the status code will be rewritten as an error status code. as well as When the status code indicates an error on the server, the server's status code is sent to the alarm management system.

12. The method of claim 11, wherein when the software has an error-free state, the status code indicates the error-free state of the software. When the error exists in the software, the status code indicates the cause and location of the error.

Images