A device monitoring method, apparatus, server, and storage medium

Abstract

This application discloses a device monitoring method, apparatus, server, and storage medium. The server includes a Baseboard Management Controller (BMC). The BMC listens for state change events via an MCTP service. The triggering device for a state change event is one of N devices connected to the server via an SMBus bus; all N devices support the MCTP protocol. When a state change event indicates a read operation at the SMBus protocol layer, the BMC encapsulates the MCTP-formatted data in the first data corresponding to the read operation via the SMBus service and sends it to the application service associated with the first data. When a state change event indicates a write operation at the SMBus protocol layer, the BMC encapsulates the second data corresponding to the write operation into an SMBus-based MCTP format via the SMBus service and writes it to the triggering device. This method is not limited to monitoring specific devices manufactured by a particular manufacturer and has a wide range of applications.

Description

Technical Field

[0001] This application relates to the field of server equipment monitoring technology, and in particular to a device monitoring method, apparatus, server, and storage medium. Background Technology

[0002] In server management, real-time monitoring of devices connected to or communicating with the server (referred to as server equipment or server components, hereinafter referred to as equipment) enables efficient management of these devices, which is crucial for ensuring stable system operation and rapid response. However, as server functionality improves, the number of devices requiring monitoring and management continues to increase, rendering some traditional monitoring methods inadequate for the increasingly complex needs.

[0003] In existing technologies, devices are typically monitored and managed using a System Management Bus (SMBus). Generally, a device monitoring method based on SMBus is designed for a specific device manufactured by one vendor that supports a specific protocol parsing method. However, for a different device manufactured by another vendor that supports a different protocol parsing method, a completely new device monitoring method needs to be developed.

[0004] Therefore, the equipment monitoring methods in related technologies have limited applicability. Summary of the Invention

[0005] The exemplary embodiments of this application provide a device monitoring method, apparatus, server, and storage medium. This method is not limited to monitoring specific devices manufactured by a particular manufacturer and has a wide range of applications.

[0006] In a first aspect, one embodiment of this application provides a device monitoring method applied to a baseboard management controller (BMC) of a server. The BMC provides Management Controller Transport Protocol (MCTP) service and System Management Bus (SMBus) service. The method includes:

[0007] The server listens for state change events via the MCTP service; the triggering device for a state change event is any one of N devices connected to the server via the SMBus bus; all N devices are devices that support the MCTP protocol.

[0008] If the state change event indicates a read operation at the SMBus protocol layer, the MCTP format data in the first data corresponding to the read operation is encapsulated through the SMBus service, and the encapsulated data is sent to the application service associated with the first data.

[0009] If the state change event indicates a write operation at the SMBus protocol layer, the second data corresponding to the write operation is encapsulated into the SMBus-based MCTP format and written to the triggering device via the SMBus service.

[0010] In this embodiment, the server connects to N devices via at least one SMBus bus, all of which support the MCTP protocol. Regarding the monitoring process of these N devices, considering the wide applicability of the MCTP service across different hardware platforms and communication environments, an upper-layer MCTP service is integrated on top of the underlying SMBus service. This allows the MCTP service to listen for state change events. The device that triggers this state change event can be called the triggering device. The operation indicated by the state change event at the MCTP protocol layer at the SMBus protocol layer can be either a read operation or a write operation. Therefore, when the operation indicated by the state change event at the SMBus protocol layer is a read operation, the MCTP-formatted data in the first data corresponding to the read operation can be encapsulated using the SMBus service and sent to the application service associated with the first data. When the operation indicated by the state change event at the SMBus protocol layer is a write operation, the second data corresponding to the write operation is encapsulated into an SMBus-based MCTP format and written to the triggering device using the SMBus service. Thus, by applying the method in this application embodiment, it is possible to monitor server devices that support the MCTP protocol, overcoming the limitation that a monitoring method in related technologies is only applicable to a single manufacturer's products that support a single set protocol or a proprietary protocol, and thus has a wide range of applications.

[0011] In one alternative implementation, the method further includes:

[0012] The BMC detects the physical addresses of M devices; where M devices are a subset of N devices; all M devices are connected to the first SMBus bus; the first SMBus bus is any one of multiple SMBus buses; M is less than or equal to N;

[0013] If the physical addresses of the first device and the second device are determined to be the same, then the BMC will reallocate a physical address for either the first device or the second device; where the first device and the second device are among the M devices.

[0014] In the above embodiments, when devices connected to the same SMBus bus have the same physical address, the physical address can be reallocated to ensure that the physical addresses of devices connected to the same SMBus bus are different, thereby overcoming the problem of not being able to monitor when devices conflict with each other in related technologies.

[0015] In one alternative implementation, the BMC reallocates a physical address for either the first or second device, including:

[0016] The BMC selects an unused physical address from the first address conflict protocol ARP address pool and assigns it to the first device or the second device; wherein, the first address conflict protocol ARP address pool is an ARP address pool associated with the first SMBus bus among multiple ARP address pools; the SMBus bus corresponds one-to-one with the ARP address pool; the first address conflict protocol ARP address pool includes at least one available physical address.

[0017] The above embodiments resolve physical address conflicts of devices through ARP, which can meet the monitoring and management needs of multiple devices connected on the same SMBus bus.

[0018] In one alternative implementation, the method further includes:

[0019] BMC constructs a dynamic routing list; the dynamic routing list includes the link information of N devices; the link information of each device includes part or all of the device's node identifier at the MCTP protocol layer, link address, device type, and matching read / write method;

[0020] BMC manages N devices based on a dynamic routing list.

[0021] The above embodiments utilize a dynamic routing list to enable dynamic addition, deletion, modification, and querying of devices. Devices requiring monitoring or management are added to the dynamic routing list; devices no longer requiring monitoring or management are removed. When a new device is added, no new monitoring method needs to be designed, thus improving the efficiency of device monitoring.

[0022] In one alternative implementation, the method further includes:

[0023] BMC parses data packets in state change events according to the MCTP format;

[0024] Based on the header information in the parsing result, BMC searches the dynamic routing list and determines the triggering device from among N devices.

[0025] In the above embodiment, since the dynamic routing list stores the link information of each of the N devices, when there is a state change event, the data packets in the state change event can be directly parsed, and the triggering device can be determined based on the parsing result, thereby realizing the monitoring of the triggering device.

[0026] In one alternative implementation, the method further includes:

[0027] If a new device is detected connecting to the server via the SMBus bus, or if any one of N devices is detected disconnected from the SMBus bus, the BMC updates the dynamic routing list.

[0028] The above embodiments are designed with an automatic update mechanism to realize automatic detection of hot-plugging of devices and update of dynamic routing lists, thereby improving the adaptability of the monitoring method and enabling more efficient monitoring and management of devices.

[0029] In an alternative implementation, before the BMC listens for state change events via the MCTP service, the method further includes:

[0030] BMC starts the MCTP service and establishes the association between the MCTP service and the SMBus service.

[0031] BMC initiates the SMBus service and obtains bus link information and dynamic device information. The bus link information includes the number of SMBus buses and the number of devices connected to each SMBus bus. The dynamic device information includes the device type and function of each of the N devices connected through the SMBus bus.

[0032] In the above embodiments, the MCTP service and SMBus service are started in advance. The BMC can obtain bus link information and dynamic device information, so that the MCTP service and SMBus service can directly apply the bus link information and dynamic device information when monitoring the device, thereby improving the efficiency of device monitoring.

[0033] Secondly, one embodiment of this application provides a device monitoring apparatus applied to a server, the apparatus comprising:

[0034] The first service unit is used to listen for state change events through the MCTP service; wherein, the triggering device for the state change event is any one of N devices connected to the server via the SMBus bus; all N devices are devices that support the MCTP protocol;

[0035] The second service unit is used to encapsulate the MCTP format data in the first data corresponding to the read operation through the SMBus service when the operation indicated by the state change event at the SMBus protocol layer is a read operation, and send the encapsulated data to the application service associated with the first data.

[0036] The second service unit is also used to encapsulate the second data corresponding to the write operation into the SMBus-based MCTP format and write it to the triggering device when the operation indicated by the state change event at the SMBus protocol layer is a write operation.

[0037] Thirdly, one embodiment of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the above methods.

[0038] Fourthly, one embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement the steps of any of the above methods.

[0039] Fifthly, one embodiment of this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the methods described above. Attached Figure Description

[0040] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0041] Figure 1 An exemplary schematic diagram of a device monitoring system provided in an embodiment of this application is shown;

[0042] Figure 2 An exemplary flowchart of a device monitoring method provided in an embodiment of this application is shown;

[0043] Figure 3 An exemplary flowchart of a complete device monitoring method provided in an embodiment of this application is shown;

[0044] Figure 4 An exemplary schematic diagram of a device monitoring apparatus provided in an embodiment of this application is shown;

[0045] Figure 5 An exemplary schematic diagram of a server provided in an embodiment of this application is shown. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0047] For ease of understanding, the terms used in the embodiments of this application are explained below:

[0048] (1) The Baseboard Management Controller (BMC) is a basic core functional subsystem of the server, responsible for core functions such as hardware status management, operating system management, health status management, and power consumption management.

[0049] (2) System Management Bus (SMBus) is a two-wire serial communication protocol used for system management, primarily for communication between low-speed devices in embedded systems. It can be applied to low-speed communication in mobile and desktop computer systems. The SMBus bus is used to control devices on the motherboard and collect corresponding information. Typically, the SMBus bus consists of two lines on the motherboard that connect to devices and provide SMBus services based on the SMBus protocol.

[0050] (3) Management Component Transport Protocol (MCTP) is a standardized protocol for communication between different management controllers in a computer system. It is highly flexible and scalable, and can be used for communication between different management controllers and devices. Because the MCTP protocol can run on various underlying transport media, such as I... 2 C. System Management Bus (SMBus) 3 C. With the support of high-speed serial computer expansion bus standards (Peripheral Component Interconnect Express, PCIE), Universal Serial Bus (USB), and Ethernet, MCTP has wide applicability in different hardware platforms and communication environments.

[0051] (4) Address Resolution Protocol (ARP), also known as the address conflict protocol, is a network transmission protocol that finds the data link layer address by resolving the network layer address. Typically, devices may have the same physical address when they leave the factory. In this embodiment, during SMBus-based processing, when physical address conflicts occur, a new physical address can be dynamically assigned to resolve the issue, ensuring that each device has a unique physical address. Here, the physical address refers to the bus address. In this embodiment, the device refers to a server device, that is, a device that communicates with the server, such as a network card or graphics card.

[0052] (5) Unique Device Identifier (UDID): A unique identifier used to identify a specific device.

[0053] In existing technologies, devices are typically monitored and managed using a System Management Bus (SMBus). Generally, a monitoring method based on SMBus is designed for devices from one vendor that support a specific protocol parsing method. However, for devices from other vendors that support a different protocol parsing method, a completely new monitoring method needs to be designed. This approach to monitoring or managing devices has limitations, poor adaptability, and lacks flexibility.

[0054] Specifically, the device detection method in the aforementioned prior art can be as follows: the BMC performs simple data transmission and status monitoring via SMBus; the device packages its status information into a fixed-format data packet and sends it to the BMC via SMBus; the BMC parses the data packet and displays the corresponding device status. This method is simple to implement, but lacks versatility.

[0055] Therefore, this application provides a device monitoring method that leverages the wide applicability of MCTP service across different hardware platforms and communication environments, as well as the large number of devices supporting MCTP service. Thus, based on the underlying SMBus service, an upper-layer MCTP service is integrated to achieve device monitoring and management. This allows for the monitoring of server devices supporting the MCTP protocol, overcoming the limitation of related technologies where a single monitoring method is only applicable to devices from a single vendor supporting a specific or proprietary protocol, thus offering broader applicability.

[0056] After introducing the design concept of the embodiments of this application, the following is a brief introduction to the application scenarios to which the technical solutions of the embodiments of this application can be applied. It should be noted that the application scenarios described below are only for illustrating the embodiments of this application and are not intended to limit the scope. In specific implementation, the technical solutions provided by the embodiments of this application can be flexibly applied according to actual needs.

[0057] refer to Figure 1 This is a schematic diagram of a device management system provided in an embodiment of this application. The system includes a server and devices. The server includes a BMC, which provides MCTP and SMBus services. The MCTP service runs on the underlying transmission medium SMBus based on the MCTP protocol. The SMBus bus is connected between the server motherboard and the devices in the form of a physical bus.

[0058] Of course, the methods provided in the embodiments of this application are not limited to... Figure 1The application scenarios shown can also be used in other possible scenarios, and this application does not impose any limitations. Figure 1 The functions that each device in the application scenario shown can achieve will be described in subsequent method embodiments, and will not be elaborated on here.

[0059] To further illustrate the technical solutions provided in the embodiments of this application, a detailed description is provided below in conjunction with the accompanying drawings and specific implementation methods. Although the embodiments of this application provide method operation steps as shown in the following embodiments or drawings, the method may include more or fewer operation steps based on conventional or non-inventive methods. In steps where there is no logically necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application.

[0060] The following is combined Figure 1 As shown, for reference Figure 2 A flowchart of a device monitoring method is shown. This method is applied to a server, and the devices in the embodiments of this application are all devices that support the MCTP protocol. The technical solutions provided in the embodiments of this application are described below.

[0061] S201: BMC listens for state change events through the MCTP service.

[0062] S202: If the operation indicated by the state change event at the SMBus protocol layer is a read operation, then the BMC encapsulates the MCTP format data in the first data corresponding to the read operation through the SMBus service, and sends the encapsulated data to the application service associated with the first data.

[0063] S203: If the operation indicated by the state change event at the SMBus protocol layer is a write operation, then the BMC encapsulates the second data corresponding to the write operation into the MCTP format based on SMBus through the SMBus service and writes it to the triggering device.

[0064] In this embodiment, the server connects to N devices via at least one SMBus bus, all of which support the MCTP protocol. For the monitoring process of these N devices, considering the wide applicability of the MCTP service across different hardware platforms and communication environments, an upper-layer MCTP service is integrated on top of the underlying SMBus service. This allows the MCTP service to listen for state change events. The device that triggers this state change event can be called the triggering device. The operation indicated by the state change event at the MCTP protocol layer at the SMBus protocol layer can be a read operation or a write operation. Therefore, when the operation indicated by the state change event at the SMBus protocol layer is a read operation, the MCTP-formatted data in the first data corresponding to the read operation can be encapsulated using the SMBus service and sent to the application service associated with the first data. When the operation indicated by the state change event at the SMBus protocol layer is a write operation, the second data corresponding to the write operation is encapsulated into an SMBus-based MCTP format and written to the triggering device using the SMBus service. Thus, by applying the method in this application embodiment, it is possible to monitor server devices that support the MCTP protocol, overcoming the limitation that a monitoring method in related technologies is only applicable to a single manufacturer's products that support a single set protocol or a proprietary protocol, and thus has a wide range of applications.

[0065] Before managing the device, a series of service startup and initialization operations can be performed to enable subsequent device management using the corresponding services. Optionally, this can be achieved through steps A1-A2:

[0066] A1: BMC starts the MCTP service and establishes the association between the MCTP service and the SMBus service.

[0067] SMBus is a low-level transmission medium, while the MCTP protocol can run on various low-level transmission media, such as I... 2 C, SMBus, I 3 C, PCIe, USB, and Ethernet, etc. In this embodiment, the MCTP protocol runs on top of SMBus. Therefore, after the BMC starts the MCTP service, an association between the MCTP service and the SMBus service is established. This allows the BMC to determine that the device management process is based on the SMBus protocol, not other protocols. This process is the initialization process of the MCTP protocol stack service. After initialization, a configuration file is generated, which stores the association between the MCTP service and the SMBus service.

[0068] A2: The BMC starts the SMBus service and obtains bus link information and dynamic device information.

[0069] The bus link information includes the number of SMBus buses and the number of devices connected to each SMBus bus; the dynamic device information includes the device type and function of each of the N devices connected via the SMBus bus. Optionally, the device type can be a network card or a graphics card, etc.

[0070] In a specific example, the BMC can read the UDID of each device according to the SMBus specification, thus determining the type and function of the device.

[0071] After the MCTP service and SMBus service are started and the corresponding initialization is completed, the device management process can be executed.

[0072] Regarding S201, taking a device that needs to be monitored as an example, this device can be any one of N devices connected to the server via an SMBus bus. When the state of this device changes, for example, when data needs to be transferred from the device to the server, or vice versa, a state change event is generated at the MCTP protocol layer. In this case, the device that triggers the state change event is called the triggering device. BMC listens for state change events through the MCTP service.

[0073] Regarding S202, it is called a state change event in the MCTP protocol layer. The corresponding operation indicated by the SMBus protocol layer can be a read operation or a write operation. A read operation is the data transmission from the device to the server, and a write operation is the data transmission from the server to the device.

[0074] This step primarily addresses the read operation scenario. Specifically, in this case, the BMC retrieves the first data corresponding to the read operation via the SMBus service. Since the first data consists of different fields, including MCTP format fields and other fields, the MCTP format data in the first data is encapsulated, and the encapsulated data is sent to the application service associated with the first data. Optionally, the application service here is related to the type of the first data. For example, if the first data is display data, then the application service could be a display service. This is merely an example and does not constitute a specific limitation.

[0075] Furthermore, since the server does not communicate directly with the device, but rather through the MCTP and SMBus services provided by BMC as intermediaries, the data transmission between the server and the device discussed here is only a simplified explanation and does not constitute a specific limitation.

[0076] Regarding S203, this step pertains to the write operation scenario. Specifically, in this case, the BMC encapsulates the second data corresponding to the write operation into an SMBus-based MCTP format via the SMBus service and then writes it to the triggering device.

[0077] Optionally, data reading and writing are both implemented by the BMC calling the SMBus driver.

[0078] Considering that existing technologies cannot monitor devices with the same physical address, and that many devices are configured with a default physical address at the factory, this can lead to some devices connected to the same SMBus bus having the same physical address. Therefore, this application provides an address conflict solution via APR, which can be achieved through steps B1-B2:

[0079] B1: BMC detects the physical addresses of M devices.

[0080] The server connects to N devices supporting the MCTP protocol via an SMBus bus. There are many SMBus buses, and the physical addresses of devices connected to different SMBus buses are usually different. However, different devices connected to the same SMBus bus may have the same physical address. This explanation uses any one of these SMBus buses as an example. For instance, the server connects to M devices via the first SMBus bus. The BMC detects the physical addresses of these M devices.

[0081] B2: If it is determined that the physical addresses of the first device and the second device are the same, then the BMC will reallocate the physical address for either the first device or the second device.

[0082] Optionally, if two of the M devices have the same physical address, monitoring of these two devices cannot be achieved in related technologies. In this embodiment, the BMC reassigns a physical address to the first or second device to ensure that the physical addresses of each device connected by an SMBus bus are different, thereby ensuring the monitoring effect of the devices.

[0083] Optionally, ARP can be used to implement the process of reallocating physical addresses:

[0084] In this embodiment, each SMBus bus corresponds one-to-one with an ARP address pool. For example, if there are T SMBus buses, then T ARP address pools are set up. Each address pool includes at least one available physical address. In this embodiment, the first address conflict protocol ARP address pool (hereinafter referred to as the first ARP address pool) corresponding to the first SMBus bus is used as an example for illustration.

[0085] The BMC selects an unused physical address from the first ARP address pool and assigns it to either the first device or the second device. This assignment process can be random, and there is no restriction on whether the selected physical address is assigned to the first or second device, as long as the physical addresses of devices connected to the same SMBus bus are all different.

[0086] Therefore, in this embodiment of the application, for devices with physical address conflicts, the problem can be resolved through ARP to automatically allocate new physical addresses. This solves the problem of the inability to monitor devices with physical address conflicts in the prior art.

[0087] As server functionality improves, the number of devices requiring monitoring and management is increasing. To better meet the growing management demands, this application provides a method for constructing a dynamic routing list. This dynamic routing list includes link information for each of N devices. This link information includes each device's node identifier at the MCTP protocol layer, link address, device type, and matching read / write method. The device type can be a network interface card (NIC), graphics card, etc.

[0088] In practical applications, there may be situations where new devices are connected to the server via the SMBus bus, or devices that are already connected to the server via the SMBus bus are removed (disconnected from the server, or connected to the server via other types of buses).

[0089] In cases of newly added devices, related technologies require redesigning monitoring methods based on the device information of the new devices, which is cumbersome. In this embodiment, as long as the new device supports the MCTP protocol, the dynamic routing list can be directly updated based on the device's information. Then, configuration information is adaptively updated according to the updated dynamic routing list to enable MCTP services and SMBus calls within the BMC. This achieves dynamic device management with strong adaptability.

[0090] In the case of device removal, the device-related information is directly deleted from the dynamic routing list, thereby updating the dynamic routing list.

[0091] Therefore, by using a dynamic monitoring mechanism to automatically update the dynamic routing list, devices can be automatically added and deleted, thus achieving unified management of devices.

[0092] Optionally, the triggering device in the above embodiments is determined through the following steps C1-C2.

[0093] C1: BMC parses data packets in state change events according to the MCTP format.

[0094] Each state change event corresponds to a data packet, which is transmitted to the BMC via the MCTP service. The BMC can then parse the data packet according to the MCTP format.

[0095] C1: The BMC searches the dynamic routing list based on the header information in the parsing result and determines the triggering device among N devices.

[0096] The header information in the parsed result carries one or more pieces of information, such as the device's node identifier at the MCTP protocol layer, link address, device type, and matching read / write method. Thus, the BMC can use the header information in the parsed result to search the dynamic routing list and determine the triggering device from among N devices.

[0097] Figure 3 A flowchart illustrating a complete device monitoring method provided in this application embodiment. Figure 3 It should include at least the following steps:

[0098] S301: Initialization.

[0099] Specifically, initialization can include three aspects: D1-D3.

[0100] D1: Protocol stack initialization.

[0101] Optionally, start the MCTP protocol stack service in the MCTP service, load the configuration file, parse the configuration file, and complete the initialization of the protocol stack.

[0102] D2: Bus link information initialization.

[0103] Optionally, scan the physical addresses of the SMBus links to see which physical addresses are on each SMBus link, thereby initializing the SMBus bus link information.

[0104] D3: Address pool initialization.

[0105] Optionally, the BMC can initialize the address pool based on the number of SMBus buses and the maximum number of devices on each bus, and put unused physical addresses into the address pool so that when resolving address conflicts, it can obtain unused physical addresses from the address pool for allocation.

[0106] S302: Physical address conflict resolution.

[0107] In this embodiment, after initialization is complete, the BMC can detect all devices on the SMBus bus. It determines whether a device with the same physical address exists on the same SMBus bus. When a device with the same physical address is detected on the same SMBus bus, an unused physical address (or a free physical address) can be selected from the ARP address pool for reallocation.

[0108] S303: Classification of server equipment types and functions.

[0109] Optionally, the BMC can read the UDID of the server device according to the SMBus specification, and then distinguish the device type and device function based on the UDID.

[0110] S304: Filter devices to be added to the dynamic routing list.

[0111] Optionally, it can be determined whether the server device supports MCTP device communication. If the device supports MCTP, then all MCTP-supporting devices are generated as device nodes, and the access link address and device type of each MCTP-supporting device are recorded. Then, all MCTP-supporting devices are managed uniformly by a dynamic routing list.

[0112] S305: Forwarding of read and write data.

[0113] Optionally, the system can monitor in real time for the occurrence of state change events. When a state change event occurs, the data packets in the event can be parsed, and the triggering device can be queried in the dynamic routing list based on the parsing result. Then, the driver program can be invoked to read and write to the triggering device. After the read and write operations are completed, the information of the triggering device (the information corresponding to the read and write operations) can be updated.

[0114] Specifically, when MCTP detects a state change event, it can parse the packet header information of the state change event data packet according to MCTP, and then query the triggering device in the dynamic routing list based on the packet header information. SMBus can monitor whether there are read or write data forwarding operations. If there is readable data and a read operation is required on the triggering device, it directly reads the data, removes the packet header and trailer information (filtering out the MCTP format data), and sends it to the application service. If a write operation is required on the triggering device, it adds the packet header and trailer information and writes the data to the triggering device. When performing read and write operations, the SMBus driver can be called to implement the read and write operations on the triggering device.

[0115] Therefore, this embodiment of the application, through a new architecture based on SMBus combined with MCTP, automatically detects the physical addresses of all MCTP-enabled devices connected to the SMBus bus via BMC, achieving automatic device monitoring. For devices with physical address conflicts, ARP is used to resolve the conflicts and automatically allocate new physical addresses. Furthermore, this embodiment of the application also supports dynamic adaptive capabilities for devices; for newly added or removed devices, the dynamic routing list can be automatically updated, achieving efficient and flexible unified monitoring and management of various devices on the server.

[0116] like Figure 4As shown, based on the same inventive concept, this application provides a device monitoring apparatus for use on a server. The apparatus includes a first service unit 41 and a second service unit 42.

[0117] The first service unit 41 is used to listen for state change events through the MCTP service; wherein the triggering device for the state change event is any one of N devices connected to the server via the SMBus bus; all N devices are devices that support the MCTP protocol.

[0118] The second service unit 42 is used to encapsulate the MCTP format data in the first data corresponding to the read operation through the SMBus service when the operation indicated by the state change event at the SMBus protocol layer is a read operation, and send the encapsulated data to the application service associated with the first data.

[0119] The second service unit 42 is also used to encapsulate the second data corresponding to the write operation into the MCTP format based on SMBus and write it to the triggering device when the operation indicated by the state change event at the SMBus protocol layer is a write operation.

[0120] In one alternative embodiment, the apparatus further includes a processing unit, the processing unit being configured to:

[0121] Detect the physical addresses of M devices; where M devices are a subset of N devices; all M devices are connected to a first SMBus bus; the first SMBus bus can be any one of multiple SMBus buses; M is less than or equal to N;

[0122] If the physical addresses of the first device and the second device are determined to be the same, then a new physical address is assigned to either the first device or the second device; wherein the first device and the second device are among the M devices.

[0123] In one optional implementation, the processing unit is specifically used for:

[0124] Select an unused physical address from the first address conflict protocol ARP address pool and assign it to the first device or the second device; wherein, the first address conflict protocol ARP address pool is an ARP address pool associated with the first SMBus bus among multiple ARP address pools; the SMBus bus and the ARP address pool are in one-to-one correspondence; the first address conflict protocol ARP address pool includes at least one available physical address.

[0125] In an optional implementation, the processing unit is further configured to:

[0126] Construct a dynamic routing list; the dynamic routing list includes the link information of N devices; the link information of each device includes part or all of the node identifier, link address, device type and matching read / write method of the device at the MCTP protocol layer;

[0127] N devices are managed based on a dynamic routing list.

[0128] In an optional implementation, the processing unit is further configured to:

[0129] Parse data packets in state change events according to the MCTP format;

[0130] Based on the header information in the parsing result, the triggering device is determined from among N devices by searching the dynamic routing list.

[0131] In an optional implementation, the processing unit is further configured to:

[0132] If a new device is detected connecting to the server via the SMBus bus, or if any one of N devices is detected disconnected from the SMBus bus, then the dynamic routing list is updated.

[0133] In an optional implementation, before the BMC listens for state change events via the MCTP service, the processing unit is further configured to:

[0134] Start the MCTP service and establish the association between the MCTP service and the SMBus service.

[0135] Start the SMBus service and obtain bus link information and dynamic device information; the bus link information includes the number of SMBus buses and the number of devices connected to each SMBus bus; the dynamic device information includes the device type and function of each of the N devices connected through the SMBus bus.

[0136] Since this device is the same as the device in the method of this application embodiment, and the principle of the device in solving the problem is similar to that of the method, the implementation of the device can be referred to the implementation of the method, and the repeated parts will not be described again.

[0137] Based on the same inventive concept as the device monitoring method, this application also provides a server, which can specifically be a desktop computer, portable computer, smartphone, tablet computer, personal digital assistant (PDA), cloud server, etc. Figure 5 As shown, the server may include a processor 51 and a memory 52.

[0138] The processor 51 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0139] Memory 52, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic memory, magnetic disk, optical disk, etc. Memory is any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. In the embodiments of this application, memory 52 may also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0140] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned computer storage medium can be any available medium or data storage device that a computer can access, including but not limited to: mobile storage devices, random access memory (RAM), magnetic storage (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc.), optical storage (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor storage (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs)) and other media capable of storing program code.

[0141] Alternatively, if the integrated units described above in this application are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes: mobile storage devices, random access memory (RAM), magnetic memory (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc.), optical memory (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor memory (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs), etc.) and other media capable of storing program code.

[0142] Based on the same inventive concept, this application also provides a computer program product, which includes computer program code. When the computer program code is run on a computer, it causes the computer to execute any of the device monitoring methods discussed above. Since the principle by which the above-described computer program product solves the problem is similar to that of the device monitoring method, the implementation of the above-described computer program product can be referred to the implementation of the method, and repeated details will not be described again.

[0143] The above embodiments are only used to provide a detailed description of the technical solutions of this application. However, the description of the above embodiments is only for the purpose of helping to understand the methods of the embodiments of this application and should not be construed as a limitation on the embodiments of this application. Any changes or substitutions that can be easily conceived by those skilled in the art should be covered within the protection scope of the embodiments of this application.

Claims

1. A method for monitoring equipment, characterized in that, Applied to a server, the server including a baseboard management controller (BMC), the BMC providing Management Controller Transport Protocol (MCTP) service and System Management Bus (SMBus) service, the method includes: The BMC listens for state change events through the MCTP service; wherein, the triggering device for the state change event is any one of N devices connected to the server via the SMBus bus; all N devices are devices that support the MCTP protocol; If the state change event indicates a read operation at the SMBus protocol layer, then the BMC encapsulates the MCTP format data in the first data corresponding to the read operation through the SMBus service, and sends the encapsulated data to the application service associated with the first data. If the operation indicated by the state change event at the SMBus protocol layer is a write operation, then the BMC encapsulates the second data corresponding to the write operation into the MCTP format based on SMBus through the SMBus service and writes it to the triggering device. The triggering device is determined in the following way: The BMC parses the data packets in the state change event according to the MCTP format; The BMC searches the dynamic routing list constructed by the BMC based on the header information in the parsing result, and determines the triggering device among the N devices.

2. The method according to claim 1, characterized in that, The method further includes: The BMC detects the physical addresses of M devices; wherein the M devices are a subset of the N devices; all M devices are connected to a first SMBus bus; the first SMBus bus is any one of multiple SMBus buses; M is less than or equal to N; If it is determined that the physical addresses of the first device and the second device are the same, then the BMC will reallocate a physical address for the first device or the second device; wherein the first device and the second device are devices among the M devices.

3. The method according to claim 2, characterized in that, The BMC reallocates physical addresses for the first device or the second device, including: The BMC selects an unused physical address from the first address conflict protocol ARP address pool and assigns it to the first device or the second device; wherein, the first address conflict protocol ARP address pool is an ARP address pool associated with the first SMBus bus among multiple ARP address pools; the SMBus bus corresponds one-to-one with the ARP address pool; the first address conflict protocol ARP address pool includes at least one available physical address.

4. The method according to claim 1, characterized in that, The dynamic routing list includes the link information of each of the N devices; the link information of each device includes part or all of the node identifier, link address, device type, and matching read / write method of the device at the MCTP protocol layer. The BMC manages the N devices based on the dynamic routing list.

5. The method according to claim 4, characterized in that, The method further includes: If a new device is detected connecting to the server via the SMBus bus, or if any one of the N devices is detected disconnected from the SMBus bus, the BMC updates the dynamic routing list.

6. The method according to any one of claims 1 to 5, characterized in that, Before the BMC listens for state change events through the MCTP service, the method further includes: The BMC starts the MCTP service and establishes the association between the MCTP service and the SMBus service; The BMC initiates the SMBus service and obtains bus link information and dynamic device information; wherein, the bus link information includes the number of SMBus buses and the number of devices connected to each SMBus bus; the dynamic device information includes the device type and function of each of the N devices connected through the SMBus bus.

7. An equipment monitoring device, characterized in that, Applied to a server, the server including a baseboard management controller (BMC), the BMC providing Management Controller Transport Protocol (MCTP) service and System Management Bus (SMBus) service, the device comprising: The first service unit is used to listen for state change events through the MCTP service; wherein the triggering device for the state change event is any one of N devices connected to the server via the SMBus bus; all N devices are devices that support the MCTP protocol; The second service unit is used to encapsulate the MCTP format data in the first data corresponding to the read operation through the SMBus service when the operation indicated by the state change event at the SMBus protocol layer is a read operation, and send the encapsulated data to the application service associated with the first data. The second service unit is further configured to, when the operation indicated by the state change event at the SMBus protocol layer is a write operation, encapsulate the second data corresponding to the write operation into the SMBus-based MCTP format and write it to the triggering device via the SMBus service. The processing unit is configured to determine the triggering device in the following manner: Parse the data packets in the state change event according to the MCTP format; Based on the header information in the parsing result, the triggering device is determined from the N devices by searching the dynamic routing list constructed by the BMC.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When executed by a processor, the computer program instructions implement the steps of the method according to any one of claims 1 to 6.

Images