Server discovery and management method and system, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a server discovery and management method based on an out-of-band management network, a server discovery and management system based on the out-of-band management network, electronic equipment and a computer readable storage medium. The method comprises the following steps: configuring out-of-band management network information, acquisition node information and access credential information of a server to be discovered; issuing a collection task to a collection node according to the out-of-band management network information and the collection node information; receiving response data returned by the to-be-discovered server, acquiring equipment information from the to-be-discovered server after confirming that the to-be-discovered server exists based on the response data, and analyzing the equipment information to obtain an analysis result; retrieving according to the analysis result to obtain a retrieval result; and updating or creating the management equipment object according to the retrieval result, and displaying the management equipment object. According to the embodiment of the invention, server discovery and redundancy management across data centers are supported, the deployment cost is reduced, and the system reliability and the operation flexibility are improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a server discovery and management method based on an out-of-band management network, a server discovery and management system based on an out-of-band management network, an electronic device, and a computer-readable storage medium. Background Technology

[0002] Currently, most data centers or cloud resource pools deploy independent out-of-band management networks to enable remote monitoring and management of server equipment. This out-of-band management network separates device management and control information from user business data, transmitting it through a dedicated channel, thereby reducing operating costs and improving service quality. The Intelligent Platform Management Interface (IPMI) protocol, as an open standard, is widely used in server management, supporting monitoring across operating systems and hardware platforms, including the collection of physical health indicators such as temperature, voltage, and fan status, as well as the categorized management of BIOS and system management software. This protocol is based on a command / response mechanism and can transmit information in a unified format via network, serial interface, etc., without additional costs.

[0003] However, existing server management platforms typically rely on manual import or batch import methods when adding servers to monitoring. This approach is inefficient and manpower-intensive when dealing with massive scenarios involving hundreds or thousands of servers. While some automated management technologies have emerged in recent years, these technologies are limited to a single data center or cloud pool, and their devices are mostly physically deployed, failing to achieve cloud-based architecture. This results in a lack of cross-data center management and redundancy capabilities in distributed environments, making it difficult to cope with dynamic needs arising from changes in server access. Summary of the Invention

[0004] In view of the above problems, embodiments of the present invention are proposed to provide a server discovery and management method based on an out-of-band management network, a server discovery and management system based on an out-of-band management network, an electronic device, and a computer-readable storage medium to overcome or at least partially solve the above problems.

[0005] To address the aforementioned problems, this invention discloses a server discovery and management method based on an out-of-band management network. The method includes: configuring out-of-band management network information, collection node information, and access credential information of the server to be discovered for automatic device discovery; issuing collection tasks to collection nodes based on the out-of-band management network information and the collection node information, wherein the collection nodes are used to send probe messages containing the access credential information to the server to be discovered; receiving response data returned by the server to be discovered based on the probe messages, and after confirming the existence of the server to be discovered based on the response data, collecting device information from the server to be discovered and parsing the device information to obtain a parsing result; searching in a management list based on the parsing result to obtain a search result; updating or creating a management device object based on the search result, and displaying the management device object in a display list, wherein the management device object represents the management entity of the server to be discovered.

[0006] Optionally, the configuration of out-of-band management network information, data collection node information, and access credential information of the server to be discovered for automatic device discovery includes: setting the out-of-band IP network segment range in the management platform, selecting the data collection node for automatic discovery, and entering the out-of-band management account and password information of the server to be discovered.

[0007] Optionally, issuing a collection task to the collection node based on the out-of-band management network information and the collection node information includes: sending a collection task instruction to a designated management port of the collection node via the TCP protocol to trigger the collection node to execute a server probe task.

[0008] Optionally, the acquisition node is used to send the probe message based on the IPMI protocol to the designated management port of the server to be discovered via the UDP protocol, wherein the probe message carries the out-of-band management account and password information.

[0009] Optionally, after receiving the response data returned by the server to be discovered based on the probe message and confirming the existence of the server to be discovered based on the response data, the step of collecting device information from the server to be discovered includes: after receiving the response data, collecting an IPMI string containing the device information from the HTTP or HTTPS port of the server to be discovered via the TCP protocol.

[0010] Optionally, parsing the device information to obtain the parsing result includes: parsing the collected IPMI string and extracting the IP address, out-of-band MAC address, device type, device serial number, motherboard information, and firmware version of the server to be discovered as the parsing result.

[0011] Optionally, the step of retrieving the results in the management list based on the parsing results includes: querying the database list of the management platform to see if there is a management device object that matches the IP address in the parsing results, and the retrieval results indicate whether there is a matching management device object.

[0012] Optionally, updating the management device object based on the search result includes: when the search result indicates the existence of a management device object matching the IP address, comparing the IP address, out-of-band MAC address, device type, device serial number, motherboard information, and firmware version in the parsing result with the existing information of the management device object, and updating the management device object when there are differences in the information.

[0013] Optionally, updating the management device object when there are discrepancies in the information includes: when the motherboard information or firmware version in the parsing result is inconsistent with the existing information of the management device object, using the motherboard information or firmware version in the parsing result to overwrite the corresponding information of the management device object.

[0014] Optionally, creating a management device object based on the search results includes: when the search results indicate that there is no management device object matching the IP address, creating a new management device object in the management platform, and storing the IP address, out-of-band MAC address, device type, device serial number, motherboard information, and firmware version from the parsing results into the new management device object.

[0015] Optionally, the collection node information includes information distributed across multiple cloud pool nodes. The collection nodes are used to probe the servers to be discovered via a private network to support automatic server discovery across multiple data centers.

[0016] Optionally, the data collection node, the management platform, and the management list adopt a cloud-based primary and backup deployment architecture, wherein the data collection node, the management platform, and the management list are deployed on the primary node and the backup node in the cloud, respectively.

[0017] This invention also discloses a server discovery and management system based on an out-of-band management network. The system includes: an information configuration module for configuring out-of-band management network information, collection node information, and access credential information of the server to be discovered for automatic device discovery; a collection task issuance module for issuing collection tasks to collection nodes based on the out-of-band management network information and the collection node information, wherein the collection nodes are used to send probe messages containing the access credential information to the server to be discovered; a parsing result determination module for receiving response data returned by the server to be discovered based on the probe message, and after confirming the existence of the server to be discovered based on the response data, collecting device information from the server to be discovered and parsing the device information to obtain a parsing result; a parsing result retrieval module for retrieving the parsing result in a management list to obtain a retrieval result; and a management device processing module for updating or creating management device objects based on the retrieval result and displaying the management device objects in a display list, wherein the management device objects represent the management entity of the server to be discovered.

[0018] Optionally, the relevant information configuration module is used to set the out-of-band IP network segment range, select the collection node for automatic discovery, and input the out-of-band management account and password information of the server to be discovered in the management platform.

[0019] Optionally, the data acquisition task issuing module is used to send a data acquisition task instruction to a designated management port of the data acquisition node via the TCP protocol, so as to trigger the data acquisition node to execute a server probe task.

[0020] Optionally, the acquisition node is used to send the probe message based on the IPMI protocol to the designated management port of the server to be discovered via the UDP protocol, wherein the probe message carries the out-of-band management account and password information.

[0021] Optionally, the parsing result determination module is used to collect an IPMI string containing the device information from the HTTP or HTTPS port of the server to be discovered via TCP protocol after receiving the response data.

[0022] Optionally, the parsing result determination module is used to parse the collected IPMI string and extract the IP address, out-of-band MAC address, device type, device serial number, motherboard information, and firmware version of the server to be discovered as the parsing result.

[0023] Optionally, the parsing result retrieval module is used to query the database list of the management platform to see if there is a management device object that matches the IP address in the parsing result, and the retrieval result indicates whether there is a matching management device object.

[0024] Optionally, the management device processing module is configured to, when the search result indicates the existence of a management device object matching the IP address, compare the IP address, out-of-band MAC address, device type, device serial number, motherboard information, and firmware version in the parsing result with the existing information of the management device object, and update the management device object when there are differences in the information.

[0025] Optionally, the management device processing module is configured to use the motherboard information or firmware version in the parsing result to overwrite the corresponding information of the management device object when the motherboard information or firmware version in the parsing result is inconsistent with the existing information of the management device object.

[0026] Optionally, the management device processing module is configured to create a new management device object in the management platform when the search result indicates that there is no management device object matching the IP address, and store the IP address, out-of-band MAC address, device type, device serial number, motherboard information and firmware version from the parsing result into the new management device object.

[0027] Optionally, the collection node information includes information distributed across multiple cloud pool nodes. The collection nodes are used to probe the servers to be discovered via a private network to support automatic server discovery across multiple data centers.

[0028] Optionally, the data collection node, the management platform, and the management list adopt a cloud-based primary and backup deployment architecture, wherein the data collection node, the management platform, and the management list are deployed on the primary node and the backup node in the cloud, respectively.

[0029] This invention also discloses an electronic device, including: one or more processors; and one or more machine-readable media storing instructions thereon, which, when executed by the one or more processors, cause the electronic device to perform a server discovery and management method based on an out-of-band management network as described above.

[0030] This invention also discloses a computer-readable storage medium storing a computer program that causes a processor to execute a server discovery and management method based on an out-of-band management network as described above.

[0031] The embodiments of the present invention have the following advantages:

[0032] This invention provides a server discovery and management scheme based on an out-of-band management network. The scheme configures out-of-band management network information, collection node information, and access credential information of the server to be discovered for automatic device discovery. Based on the out-of-band management network information and collection node information, a collection task is issued to the collection nodes, which send probe messages containing access credential information to the server to be discovered. The scheme receives response data returned by the server to be discovered based on the probe messages. After confirming the existence of the server based on the response data, device information is collected from the server to be discovered, and the device information is parsed to obtain a parsing result. A search is performed in the management list based on the parsing result to obtain a search result. A managed device object is updated or created based on the search result and displayed in the display list. The managed device object represents the management entity of the server to be discovered.

[0033] Compared to the inefficiency and time-consuming nature of manual import in the background technology, the automatic detection, parsing, and object management process of this invention significantly improves management efficiency and reduces manpower input. At the same time, compared to the limitations of existing automatic management technologies that are limited to a single data center and cannot be deployed in the cloud, this invention, with the help of distributed collection nodes and database logical structure, supports server discovery and redundancy management across data centers, reducing deployment costs and improving system reliability and operational flexibility. Attached Figure Description

[0034] Figure 1 This is a flowchart illustrating the steps of a server discovery and management method based on an out-of-band management network according to an embodiment of the present invention.

[0035] Figure 2 This is a schematic diagram illustrating the architectural differences and technological evolution between traditional server management methods, existing automatic management methods, and the cloud-based automatic management method of this invention.

[0036] Figure 3 This is a schematic diagram of the cloud-based distributed architecture deployment structure according to an embodiment of the present invention;

[0037] Figure 4 This is a schematic diagram of module interaction in a cloud-based distributed architecture according to an embodiment of the present invention;

[0038] Figure 5 This is a flowchart illustrating an automatic discovery and management scheme for cloud pool servers according to an embodiment of the present invention.

[0039] Figure 6 This is a structural block diagram of a server discovery and management system based on an out-of-band management network according to an embodiment of the present invention. Detailed Implementation

[0040] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0041] First, let me briefly introduce the technical terms that may be involved in the embodiments of this invention.

[0042] Out-of-band server management: This method uses dedicated hardware modules or special remote management cards to provide a management interface, enabling remote maintenance and management of the device through a dedicated data channel. This management method is completely independent of the device's operating system and can even be remotely monitored and managed when the device is powered off.

[0043] IPMI was originally an industry standard used in peripherals for enterprise systems based on Intel architecture. IPMI is also an open and free standard, meaning users can use it without paying any additional fees. IPMI can operate across different operating systems, firmware, and hardware platforms, intelligently monitoring, controlling, and automatically reporting the operational status of a large number of servers to reduce server system costs.

[0044] Reference Figure 1 This document illustrates a flowchart of a server discovery and management method based on an out-of-band management network, according to an embodiment of the present invention. This out-of-band management network-based server discovery and management method can be implemented in systems such as server management systems or network control systems (hereinafter referred to as the system). Specifically, the method may include the following steps:

[0045] Step 101: Configure out-of-band management network information, data collection node information, and access credential information for the server to be discovered for automatic device discovery.

[0046] Out-of-band management networks refer to dedicated management channels independent of the main data transmission network, used for remote monitoring and control of server equipment, enabling management even when servers are powered off or operating systems are malfunctioning. This network information includes IP address ranges, such as the out-of-band IP address ranges of servers in a data center. These addresses are used to identify the location and scope of servers to be discovered. When configuring out-of-band management network information, system administrators need to input or select these address ranges in the management platform to limit the network boundaries for detection and avoid unnecessary resource waste. Simultaneously, this configuration ensures the secure isolation of the out-of-band management network, preventing management traffic from interfering with business data transmission, thereby improving the overall network security and stability. Collection nodes are distributed components deployed in cloud pools or data centers, typically existing as virtual machines or physical servers, supporting access to server equipment via private networks. This node information includes the node's identifier, location, and deployment status, such as selecting which nodes to enable automatic discovery. The key to configuring collection node information is to leverage the advantages of a distributed architecture, such as deploying collection nodes in multiple data centers to support cross-regional server detection. This not only improves system scalability but also ensures that even if a single node fails, other nodes can continue to operate, thus achieving high availability. In practice, the system verifies the reachability of these nodes and records their network paths to ensure accurate routing to the correct data collection nodes when subsequent tasks are assigned. Access credentials include the server's out-of-band management account and password, used to authenticate access to the server's out-of-band management interface. These credentials are based on standard requirements of the out-of-band management protocol. During configuration, users enter a unified account and password in the management platform, or set up different credential groups for different IP ranges to adapt to the security requirements of multi-tenant environments. Simultaneously, this step performs credential verification, such as confirming the validity of credentials through connection testing, to avoid invalid operations caused by subsequent probe failures.

[0047] Step 102: Based on the out-of-band management network information and the collection node information, issue a collection task to the collection node, wherein the collection node is used to send a probe message containing access credential information to the server to be discovered.

[0048] First, the system generates data collection task instructions based on out-of-band management network information and data collection node information. This information serves as the task's input parameters; for example, the out-of-band IP address range defines the probe range, and the data collection node information specifies the task's execution location. Task issuance is typically achieved through reliable communication protocols, such as Transmission Control Protocol (TCP), to ensure the integrity and order of instructions. In the system architecture, the management platform sends task instructions to the designated data collection nodes. These instructions include IP address ranges, access credential information, and probe parameters such as timeout time and retries. The key to this step lies in task routing and distribution. For example, in a distributed environment, the management platform will allocate tasks to the nearest data collection node based on node load balancing to avoid network latency affecting efficiency.

[0049] After receiving the task, the acquisition node begins sending probe packets containing access credentials to the server to be discovered. These probe packets are standardized data packets based on out-of-band management protocols, such as the command / response mechanism of the IPMI protocol. The IPMI protocol allows these packets to be sent via User Datagram Protocol (UDP) because UDP's low overhead is suitable for fast probing. Access credentials, such as username and password, are embedded in the packet to authenticate the out-of-band management interface of the server to be discovered. The acquisition node iterates through out-of-band IP address ranges, for example, starting from a primary IP address, sending probe packets one by one to the server's designated management port. This process is similar to network scanning but optimized for out-of-band management, ensuring that it does not consume business network bandwidth. While sending probe packets, the acquisition node records a sending log, including timestamps and target IPs, to support subsequent fault diagnosis. If the network environment is complex, such as the presence of firewalls, the system may adjust the packet encapsulation format to bypass security restrictions.

[0050] Step 103: Receive the response data returned by the server to be discovered based on the probe message, and after confirming the existence of the server to be discovered based on the response data, collect device information from the server to be discovered, and parse the device information to obtain the parsing result.

[0051] The response data is a command response packet under the IPMI protocol, returned from the server's designated management port via UDP. It includes authentication results and basic status indicators, such as whether the server is online or supports out-of-band access. After sending a probe packet, the collection node listens on the corresponding port for a response. If data is received within a preset timeout, the probe is considered successful. The process of receiving response data emphasizes network stability and data integrity, for example, using checksum mechanisms to verify packet integrity and avoid misjudgments caused by transmission errors. If no response is received, the system marks the IP address as an invalid server and continues to the next target, thus efficiently filtering out non-existent addresses.

[0052] After confirming the existence of the server to be discovered based on the response data, the system immediately collects device information from it. This confirmation logic is simple yet crucial: the response data contains a positive response code from the IPMI protocol, indicating that the server supports out-of-band management and successful credential verification. Device information collection then switches to a more reliable protocol, such as TCP, retrieving detailed data from the server's Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS) ports. These ports are used to transmit IPMI strings, i.e., structured data packets containing server hardware and configuration information. The collection process involves multiple requests, such as first obtaining basic information and then retrieving extended attributes, ensuring comprehensive data. Compared to the lightweight nature of UDP probing, TCP collection provides reliable transmission and error retransmission mechanisms, making it suitable for transmitting larger volumes of device information, such as sensor readings or firmware details. In a distributed environment, multiple collection nodes can collect data in parallel, improving overall efficiency.

[0053] The collected device information is then parsed to obtain the parsing results. This parsing process is executed by the acquisition node or management platform, using an IPMI protocol decoder to process the string and extract key fields such as IP address, out-of-band Media Access Control Address (MAC) address, device type, device serial number, motherboard information, and firmware version. These fields form a structured parsing result, facilitating subsequent storage and retrieval. The parsing algorithm needs to process the IPMI binary format, such as converting the byte stream into readable attribute values, and verify data consistency, such as checking the validity of the serial number. If parsing fails, the system will retry or log the process.

[0054] Step 104: Based on the parsing results, perform a search in the management list to obtain the search results.

[0055] The input for this step is the parsed results, which contain key identifying information such as IP addresses and out-of-band MAC addresses. The management list is a logical structure in the system database used to store an index of all known managed device objects; it's like an ordered table or view, sorted by IP address or serial number for easy retrieval. The retrieval process uses the IP address from the parsed results as the primary key, performing an exact match query in the management list. For example, it uses Structured Query Language (SQL) to search the database backend for records with the same IP address. This query operation is efficient, supports index optimization, and can be completed in milliseconds for large lists, avoiding the performance bottleneck of full table scans. The system first checks if the IP address already exists in the management list. If a match is found, it further verifies the consistency of other attributes such as the MAC address to rule out the possibility of IP conflicts. If the IP address does not match, the retrieval result will indicate "New Server," triggering subsequent creation operations.

[0056] The search results are the output of this step, including the match status (such as "exist" or "not exist") and relevant metadata, such as the ID of the matched object or the last update time. The search process also supports extended queries, such as filtering the list based on device type to handle compatibility with vendor-specific servers.

[0057] Step 105: Update or create a management device object based on the search results, and display the management device object in the display list, wherein the management device object is used to represent the management entity of the server to be discovered.

[0058] A managed device object is a virtual entity in the system representing a managed entity of a server to be discovered. It includes a complete record of the resolved IP address, out-of-band MAC address, device type, and other relevant information. If the search results indicate the existence of a matching managed device object, the system performs an update operation: comparing the information in the resolved results with the existing object field by field, such as comparing motherboard information or firmware version. If differences exist, the new data overwrites the old data. This update process uses a transaction mechanism to ensure atomicity and records change logs to support auditing. The update logic prioritizes the accuracy of the latest data; for example, after server hardware replacement, the new motherboard information is automatically synchronized to avoid monitoring errors caused by outdated information on the management platform.

[0059] If the search results indicate no matching object exists, the system creates a new management device object: a unique identifier is assigned in the management platform, and all fields from the parsed results are populated into the new object, such as setting the IP address as the primary key and the storage device serial number as the unique identifier. This creation process includes object initialization, such as assigning default monitoring policies and associating data collection nodes. The management device object is designed to support extended attributes, such as adding custom tags or relationships, facilitating subsequent centralized monitoring. In a cloud environment, the creation operation is synchronized to the primary and backup databases to ensure redundant backups.

[0060] After creation or update, the system displays the managed device objects in a display list. The display list is a dynamic view of the user interface, such as a table or card list, that refreshes information about new objects in real time, including server name, status, and discovery time. The display list supports sorting and filtering, such as viewing by IP range or device type, facilitating administrator verification of results. In practical applications, for example, after discovering 5 servers, the display list will highlight the new objects to alert the operator.

[0061] Compared to the inefficiency and time-consuming nature of manual import in the background technology, the automatic detection, parsing, and object management process of this invention significantly improves management efficiency and reduces manpower input. At the same time, compared to the limitations of existing automatic management technologies that are limited to a single data center and cannot be deployed in the cloud, this invention, with the help of distributed collection nodes and database logical structure, supports server discovery and redundancy management across data centers, reducing deployment costs and improving system reliability and operational flexibility.

[0062] In one exemplary embodiment of the present invention, one implementation of configuring out-of-band management network information, collection node information and access credential information of the server to be discovered for automatic device discovery is as follows: setting the out-of-band IP network segment range, selecting the collection node for automatic discovery, and entering the out-of-band management account and password information of the server to be discovered in the management platform.

[0063] First, the out-of-band IP network segment range is configured through the management platform's user interface or configuration file. The out-of-band management network is a dedicated channel independent of the main business network, used for remote management and monitoring of servers. Its IP network segment range defines the scanning boundary for automatic discovery. For example, in a data center environment, a continuous address range from 172.30.18.75 to 172.30.18.154 can be set to cover specific server clusters. This setting ensures the detection process is highly targeted, avoiding resource waste caused by scanning irrelevant networks. The management platform supports batch importing of IP segment information and verifying the validity and connectivity of addresses, such as confirming network segment reachability through ping tests. Simultaneously, selecting the collection nodes for automatic discovery involves specifying the location of distributed components. These nodes are deployed in cloud pools or at the edge of data centers, supporting multi-node collaboration, such as selecting the node with the lowest load from multiple available nodes as the execution point. Collection nodes are key agents in the system, responsible for actual network interactions. Their selection is based on geographical location and network latency, such as prioritizing nodes closer to the servers to be discovered to reduce transmission latency. The out-of-band management account and password information for the servers to be discovered are stored using an encrypted mechanism, such as a hash algorithm to protect credential security. This information corresponds to the authentication requirements of the out-of-band management interface. During configuration, the system verifies credentials, for example, by sending test requests to confirm the validity of the account and password, and supports group management, such as assigning independent credential sets to different IP ranges to adapt to multi-tenant environments. In actual deployments, this approach is suitable for large-scale cloud resource pools, such as the configuration of Sugon servers in a data center, where the IP network range limits the discovery scope to hundreds of servers. After the overall configuration, this information is persisted to the management platform's database, forming task templates for easy reuse and audit logging.

[0064] This embodiment achieves standardization and security in the configuration process by precisely setting the out-of-band IP network segment range, selecting collection nodes, and entering out-of-band management account and password information in the management platform. It improves the targeting and efficiency of automatic discovery and avoids the risks of ambiguous range and credential leakage associated with traditional manual import. At the same time, this configuration supports batch operations and verification mechanisms, significantly reducing the time cost of initial setup. It also optimizes resource allocation in multi-node environments, enhancing the system's scalability and fault tolerance, thus providing a reliable foundation for the management of massive servers.

[0065] In one exemplary embodiment of the present invention, one way to issue a collection task to the collection node based on out-of-band management network information and collection node information is as follows: send a collection task instruction to the designated management port of the collection node via TCP protocol to trigger the collection node to execute a server probe task.

[0066] First, structured collection task instructions are generated based on out-of-band management network information (such as IP network segments) and collection node information (such as node ID and location). The instructions include the probe range, timeout threshold, and priority, specifying, for example, the order in which specific IP segments are scanned. The management platform, acting as the central controller, sends these instructions using the TCP protocol, as TCP's connection-oriented and reliable transmission characteristics ensure that instructions are not lost and arrive in the correct order. The specified management port is a pre-configured listening interface for the collection nodes, such as a custom TCP port, used to receive external commands. This sending process involves network routing; for example, in a distributed system, the management platform routes instructions to target nodes through an internal application programming interface or message queue, ensuring low-latency transmission. After receiving the instructions, the collection nodes parse their parameters, such as extracting IP network segments and verifying node permissions, and then trigger a server probe task. The probe task includes initializing local resources, such as allocating memory buffers and starting the network stack, to prepare for subsequent packet transmission. In practical scenarios, such as for cross-datacenter deployments, the management platform may issue instructions to multiple collection nodes in parallel to achieve load balancing, such as assigning IP segment 1 to node A and IP segment 2 to node B. The triggering of a data collection task marks the transition from configuration to execution. For example, embedding credential references in commands avoids transmitting sensitive information in plaintext. Through logging, the system tracks task status, such as "issued," "in execution," and "completed," facilitating monitoring and debugging.

[0067] This embodiment sends collection task instructions to the designated management port of the collection node via the TCP protocol, thereby ensuring the reliability and order of task distribution, guaranteeing the complete transmission of instructions in complex networks, and avoiding the packet loss risk of unreliable protocols such as UDP. At the same time, this triggering mechanism supports load balancing and error retries, improving the execution efficiency and fault tolerance of the distributed system, thereby reducing the task failure rate and providing an efficient coordination basis for large-scale server probing.

[0068] In an exemplary embodiment of the present invention, the acquisition node is used to send a probe message based on the IPMI protocol to a designated management port of the server to be discovered via the UDP protocol, wherein the probe message carries out-of-band management account and password information.

[0069] The acquisition node, acting as an execution agent, first extracts parameters from the task instructions, such as IP network segments and credential information, and then constructs probe packets. IPMI-based packets have a standardized structure, including a command header, authentication data, and a payload. The payload carries out-of-band management account and password information as authentication credentials, such as using IPMI's user / operator-level authentication mode. UDP is chosen due to its low overhead and connectionless nature, suitable for rapid batch probing and avoiding the additional latency of TCP handshakes. The specified management port is the out-of-band interface port of the server to be discovered, used to receive IPMI commands. The sending process is performed IP address-by-IP, for example, starting from the beginning of the network segment, encapsulating the packet, and sending it via UDP socket broadcast or unicast. The account and password information carried in the packet is encrypted and embedded, for example, using IPMI's remote management control protocol format, to ensure secure transmission. The acquisition node sets the sending interval, such as multiple packets per second, to control network load and records a sending log including the target IP and timestamp. In practical applications, such as probing a node's servers, the data acquisition node sends IPMI probe packets to the range 133.41.15.52-133.41.15.70, discovering 5 servers. This lightweight design reduces bandwidth consumption and does not interfere with business traffic. After sending the packets, the node enters listening mode, ready to receive responses.

[0070] This embodiment sends probe messages based on the IPMI protocol via UDP, carrying out-of-band management account and password information, achieving low-overhead and fast server presence verification, avoiding the additional time consumption of TCP connections; at the same time, the message structure standardizes the authentication process, improves the compatibility and security of probes, thereby improving the efficiency of batch discovery and providing efficient support for isolated transmission of out-of-band management networks.

[0071] In one exemplary embodiment of the present invention, after receiving response data returned by the server to be discovered based on the probe message and confirming the existence of the server to be discovered based on the response data, one implementation method for collecting device information from the server to be discovered is as follows: after receiving the response data, an IPMI string containing device information is collected from the HTTP or HTTPS port of the server to be discovered via the TCP protocol.

[0072] First, the system receives response data, which is an IPMI protocol response packet returned via UDP from a designated management port. This data includes a completion code and basic status information, such as a successful authentication indication. The acquisition node parses the response, checking, for example, whether the IPMI response code is 0, indicating server existence and valid credentials. If existence is confirmed, the system switches to TCP protocol for device information acquisition, as TCP's reliability and flow control are suitable for transmitting structured data. The HTTP or HTTPS port serves as the server's management interface, used to expose IPMI data. The acquisition process involves sending an acquisition request to the port to retrieve the IPMI string, which is a serialized device information packet containing sensor data and configuration attributes. After the TCP connection is established, the system uses persistent connections to optimize multiple requests, for example, acquiring basic information first and then expanding attributes. The response data confirmation logic includes threshold checks; for example, a response delay of less than 1 second is considered valid. In a distributed environment, multiple nodes acquire data in parallel to avoid bottlenecks. In practical scenarios, for example, after response confirmation, the IPMI string is pulled from the Sugon server's HTTPS port to extract the complete device description.

[0073] This embodiment collects IPMI strings from HTTP or HTTPS ports via the TCP protocol and executes the data after confirmation of the response. This achieves a reliable transition from existence verification to detailed data acquisition, avoiding the unreliability of UDP transmission of large amounts of data. At the same time, the HTTPS security option protects the transmission of device information, improves the integrity and privacy of the collection process, and thus provides a solid guarantee for the accuracy of server management.

[0074] In one exemplary embodiment of the present invention, one way to parse device information to obtain parsing results is as follows: the collected IPMI string is parsed to extract the IP address, out-of-band MAC address, device type, device serial number, motherboard information, and firmware version of the server to be discovered as parsing results.

[0075] First, the IPMI string is loaded. This string is structured data, either binary or text-encoded, retrieved from TCP. Parsing uses an IPMI protocol decoding library, such as the open-source IPMI Toolkit, to process the packet header, payload, and checksum. The extraction process is performed field by field: the IP address is obtained from the network layer field as a unique identifier; the out-of-band MAC address is parsed from the hardware description for link layer identification; the device type, such as "Sugon Server," is extracted from the vendor ID field; the device serial number is obtained from a unique identifier; motherboard information, including model and serial number, is parsed from the sensor subsystem; and the firmware version is extracted from the firmware field to identify the software status. In cloud environments, parsing can be performed in parallel, accelerated using multi-core processors. In practical applications, for example, parsing the IPMI string of a server to extract motherboard information to detect hardware changes.

[0076] This embodiment extracts key information such as IP address and out-of-band MAC address from the structured parsing of the IPMI string, achieving standardized and automated acquisition of device data and avoiding the inefficiency and errors of manual interpretation. At the same time, this extraction mechanism covers hardware and firmware attributes, improving the comprehensiveness and accuracy of the parsing results, thereby providing a high-quality data foundation for subsequent management and monitoring.

[0077] In one exemplary embodiment of the present invention, one implementation of obtaining the retrieval result by searching the management list based on the parsing result is as follows: based on the IP address in the parsing result, query the database list of the management platform to see if there is a management device object that matches the IP address, and the retrieval result indicates whether there is a matching management device object.

[0078] First, the IP address is selected as the query key from the parsed results; this address is the core identifier of the server to be discovered. The management platform's database list is an ordered collection storing managed device objects, similar to a relational database table, optimized by IP address indexing. Queries use SQL statements to perform exact matches. The database list supports secondary indexes, such as composite keys combined with MAC addresses, to improve query speed. The retrieval process includes connecting to the database, executing the query, and returning the result set. If a match is found, the object ID and status are returned; otherwise, an empty result is returned. The retrieval results indicate the matching status, such as a Boolean flag "exists / does not exist," with additional confidence scores such as a match score. In a real-world scenario, for example, querying for a node's IP 133.41.15.52; if it matches a Sugon server, the result indicates "exists."

[0079] This embodiment achieves efficient duplicate detection by querying the database list of the management platform based on the IP address and outputting indicative search results, thus avoiding the performance overhead of a full scan. At the same time, this matching mechanism ensures data uniqueness, improves the accuracy and speed of retrieval, and provides a precise decision-making basis for update or creation operations.

[0080] In an exemplary embodiment of the present invention, one implementation of updating the management device object based on the search results is as follows: when the search results indicate the existence of a management device object that matches the IP address, the IP address, out-of-band MAC address, device type, device serial number, motherboard information, and firmware version in the parsing results are compared with the existing information of the management device object, and the management device object is updated when there are differences in the information.

[0081] First, the matching managed device object is loaded based on the search results. This object is a database record containing historical fields. The comparison process is performed field by field: IP address consistency is confirmed; out-of-band MAC address changes are checked; device type manufacturer is verified; device serial number uniqueness is checked; motherboard information model differences are compared; firmware version updates are checked. Discrepancy algorithms, such as string comparison or hash verification, are used to identify inconsistent fields. If discrepancies exist, an update is performed. Updates support partial field modifications, only modifying changed items to avoid overwriting stable data. Transaction rollback ensures consistency. In a cloud environment, updates are synchronized to backup nodes. In practice, for example, after matching and comparing motherboard information, if the motherboard has been changed, the record is updated.

[0082] This embodiment achieves dynamic information synchronization by comparing the parsed results with the fields of existing managed device objects and making targeted updates when there are differences, thus avoiding the lag problem of static records. At the same time, this comparison mechanism covers key attributes such as motherboard and firmware, improving the accuracy and timeliness of objects, thereby ensuring the real-time reliability of server management entities.

[0083] In one exemplary embodiment of the present invention, one way to update the management device object when there are discrepancies in information is as follows: when the motherboard information or firmware version in the parsing result is inconsistent with the existing information of the management device object, the motherboard information or firmware version in the parsing result is used to overwrite the corresponding information of the management device object.

[0084] First, identify the discrepancies. Motherboard information includes model, serial number, and configuration; firmware version refers to the Basic Input Output System (BIOS) version. Extract the new value from the parsed results and compare it with existing values, such as through string matching or version number increment checks. If they don't match, perform an overwrite. Overwriting uses atomic operations to avoid intermediate states. Priority rules follow the principle of new data overwriting old data to ensure up-to-dateness. In practice, for example, after a motherboard replacement, the old model record is overwritten.

[0085] This embodiment achieves immediate response to hardware changes by accurately covering inconsistencies in motherboard information or firmware versions, avoiding the delays of manual intervention. At the same time, this coverage mechanism maintains the latest state of the managed device objects, improving the accuracy and consistency of monitoring, thereby reducing operational risks.

[0086] In one exemplary embodiment of the present invention, one implementation of creating a management device object based on the search results is as follows: when the search results indicate that there is no management device object matching the IP address, a new management device object is created in the management platform, and the IP address, out-of-band MAC address, device type, device serial number, motherboard information and firmware version in the parsing results are stored in the new management device object.

[0087] First, confirm that the search results are empty, then assign a new ID and insert a record into the database. The stored procedure populates the following fields: IP address as the primary key; MAC address for hardware layer storage; device type classification; serial number as a unique identifier; and motherboard and firmware initialization attributes. The new object is associated with a default strategy, such as the monitoring interval. In practice, for example, a new IP address might be used to create an object storing details of the Dawning server.

[0088] This embodiment achieves seamless integration with new servers by creating new management device objects and storing the parsing results when no match is found, avoiding blind spots in access. At the same time, this storage mechanism standardizes the object structure, improves scalability and traceability, and thus provides flexible support for management in dynamic environments.

[0089] In an exemplary embodiment of the present invention, the information collected by the collection node includes information distributed across multiple cloud pool nodes. The collection node is used to probe for servers to be discovered via a private network, so as to support automatic server discovery across multiple data centers.

[0090] The data collection nodes are deployed on cloud pool nodes, such as virtual machine instances, and support horizontal scaling. The private network is an internal network used to isolate probe traffic. Probes are routed through the private network's IP range, supporting cross-datacenter operations, such as probe server B from node A.

[0091] This embodiment achieves seamless coverage across data centers by distributing the deployment across multiple cloud pool nodes and utilizing private network probing, avoiding the limitations of single points of failure. At the same time, this architecture improves the parallelism and geographical adaptability of probing, thereby enhancing the scalability and discovery efficiency of the system.

[0092] In an exemplary embodiment of the present invention, the data acquisition node, management platform, and management list adopt a cloud-based primary and backup deployment architecture, wherein the data acquisition node, management platform, and management list are deployed on the primary node and backup node in the cloud, respectively.

[0093] Employing a cloud-based architecture, a primary / standby mode ensures high availability. The primary node handles normal load, while the standby node provides hot standby for data synchronization. A failover mechanism, such as heartbeat detection, automatically resets the node in case of a failure. The management list is replicated in cloud storage.

[0094] This embodiment achieves redundant backup of components through a cloud-based primary and secondary deployment architecture, avoiding the risk of single point of failure in physical deployment. At the same time, this hot standby mechanism ensures data synchronization and rapid switching, improving the stability and continuity of the system, thereby reducing the cost of operation and maintenance interruption.

[0095] Reference Figure 2 This diagram illustrates the architectural differences and technological evolution between traditional server management methods, existing automatic management methods, and the cloud-based automatic management method of this invention. Figure 2The upper left part depicts the traditional server management method, which usually requires manually filling in the information of the device to be managed (such as IP, device name, model, etc.) on the management platform, or relying on manual pre-filling of information in a template table, which is inefficient. Figure 2 The lower left section shows the existing automatic management method, which uses server search and monitoring devices physically deployed in a single data center to achieve automatic discovery and management. However, its functionality is limited to a single data center, and the deployment cost is still relatively high. Figure 2 The right side of the middle section shows the server automatic management method and management platform architecture of this invention: the platform adopts cloud deployment, no longer relies on physical machines, and reduces deployment costs; at the same time, through distributed deployment of node acquisition machines, it realizes automatic discovery and centralized monitoring across data centers, with high reliability and redundancy, which can improve the overall management efficiency.

[0096] This invention primarily relies on the independent out-of-band network of the cloud pool, and the platform is deployed using a cloud-based distributed architecture. Its overall structure is as follows: Figure 3 As shown, the system includes modules such as node acquisition machines, device management platforms (WEB servers), and databases. Each module can be deployed in the cloud, providing high redundancy and high availability, thus ensuring that multiple node server devices can still be automatically discovered and managed in cross-data center scenarios.

[0097] In the specific implementation process:

[0098] Node acquisition machine: Based on the out-of-band IP address range pre-defined by the user on the management platform, it probes the server devices within the node and returns the probe results. The node acquisition machine can be deployed in a virtual machine environment within the cloud pool node or physically, thus ensuring that the platform can discover and manage server devices even if they can only be probed through a private network.

[0099] Device Management Platform: If the data center already has an out-of-band management platform, only the acquisition module and database system need to be added to the platform. As the core control terminal of the system, the device management platform is responsible for receiving user configurations, issuing acquisition tasks, parsing the returned data, and uniformly managing the automatic discovery and management of servers.

[0100] Database: Used to store information such as device management account passwords, IP addresses, MAC addresses, serial numbers, and device types. The database also uses a primary-backup cloud deployment to ensure data security and high system availability.

[0101] like Figure 4 As shown, the various modules of the platform interact with each other through different communication protocols:

[0102] The web server provides an HTTP / 80 / 443 interface to the outside world for interaction with clients (PCs) and task distribution.

[0103] The web server sends collection tasks to the node collection machine or collection server via the TCP protocol on port 9998;

[0104] The node acquisition device sends IPMI probe packets to the node to be discovered server via UDP-623 port;

[0105] Once a server to be managed is identified, the node data acquisition machine will return the collected information to the web server through TCP port 80 or 443.

[0106] The web server cleans and parses the collected data, and pushes the results to the platform database for storage via TCP-3306.

[0107] Through the above process, this embodiment of the invention can achieve automatic discovery and centralized management of servers across multiple cloud pool nodes, avoiding the limitations of traditional methods that rely on manual data entry or single-node deployment. The platform's cloud-based and distributed deployment structure ensures high system reliability and redundancy, while effectively reducing deployment and maintenance costs.

[0108] Reference Figure 5 This diagram illustrates a flowchart of an automatic discovery and management scheme for cloud pool servers according to an embodiment of the present invention. Specifically, an automatic discovery and management scheme for cloud pool servers may include the following steps:

[0109] Step 51: The user pre-configures automatic device discovery on the management platform.

[0110] Users need to configure the out-of-band IP network segment information for automatic device discovery, select the data collection node to enable automatic discovery, and fill in the out-of-band account and password for the devices to be discovered. This configuration information provides the foundation for subsequent automatic detection.

[0111] Step 52: The platform selects the cloud platform virtual machine or physical server corresponding to the user-defined collection node as the discovery source.

[0112] The platform sends a data collection task to port 9998 of the data collection device at the node via TCP, based on the out-of-band IP network segment information configured by the user. After receiving the task, the data collection device sends IPMI packets carrying account and password information to port 623 of the server to be discovered via UDP to probe the target device.

[0113] Step 53: Determine if a response has been received from the server to be discovered.

[0114] If no response is received, it means the target server device does not exist; if a response is received, it means the server device exists, and you can continue with the subsequent steps.

[0115] Step 54: The management platform (WEB server) collects data via TCP protocol through port 80 or port 443 of the server.

[0116] The platform parses the collected IPMI string to obtain key information about the discovery server, including IP address, out-of-band MAC address, device type, and device serial number.

[0117] Step 55: The platform searches the platform management list according to the IP address of the discovered device.

[0118] This step is used to confirm whether the device already exists in the platform's management objects.

[0119] Step 56: Perform different operations based on the comparison results.

[0120] Step 56-1: If the discovered device IP address already exists in the managed object.

[0121] The platform compares newly collected information with existing information. If discrepancies are found, the existing information is updated to ensure accuracy and timeliness. For example, if the server motherboard is replaced, the platform will overwrite the old motherboard information with the new data.

[0122] Step 56-2: If the platform does not find the device object.

[0123] The platform will create a new management object for the server in the nodes set by auto-discovery and save information including IP address, out-of-band MAC address, device type and device serial number.

[0124] Step 57: Complete the creation of the management object for the new device.

[0125] Newly discovered devices will appear in the discovery list to alert the user. This step signifies the completion of the automatic discovery and management process for servers via out-of-band network.

[0126] The embodiments of the present invention employ an automatic discovery and management technology based on out-of-band networks. This eliminates the need to install agent software on each server, decoupling it from the operating system. It does not increase the server's operational burden or consume business network bandwidth resources. The technology is simple to implement and low in cost.

[0127] Compared to the manual management of current management platforms, the embodiments of the present invention significantly improve efficiency, save labor costs, and contribute to reducing the overall operation and maintenance costs of data centers for enterprises.

[0128] Compared to the automatic management and discovery methods that have emerged in recent years, the automatic management and discovery scheme for cloud pool servers provided in this embodiment of the invention has the advantages of high platform device reliability and redundancy, low deployment cost, and the ability to achieve centralized monitoring and management across multiple cloud pools.

[0129] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0130] Reference Figure 6 This diagram illustrates a structural block diagram of a server discovery and management system based on an out-of-band management network, according to an embodiment of the present invention. Specifically, this out-of-band management network-based server discovery and management system may include the following modules.

[0131] The relevant information configuration module 61 is used to configure out-of-band management network information, data collection node information, and access credential information of the server to be discovered for automatic device discovery.

[0132] The task collection module 62 is used to issue a collection task to the collection node based on the out-of-band management network information and the collection node information, wherein the collection node is used to send a probe message containing the access credential information to the server to be discovered.

[0133] The parsing result determination module 63 is used to receive the response data returned by the server to be discovered based on the probe message, and after confirming the existence of the server to be discovered based on the response data, collect device information from the server to be discovered, and parse the device information to obtain the parsing result;

[0134] The parsing result retrieval module 64 is used to retrieve search results from the management list based on the parsing results.

[0135] The management device processing module 65 is used to update or create management device objects based on the search results and display the management device objects in the display list, wherein the management device objects are used to represent the management entity of the server to be discovered.

[0136] In an exemplary embodiment of the present invention, the relevant information configuration module 61 is used to set the out-of-band IP network segment range, select the collection node for automatic discovery, and input the out-of-band management account and password information of the server to be discovered in the management platform.

[0137] In an exemplary embodiment of the present invention, the data acquisition task issuing module 62 is used to send a data acquisition task instruction to a designated management port of the data acquisition node via the TCP protocol, so as to trigger the data acquisition node to execute a server probe task.

[0138] In an exemplary embodiment of the present invention, the acquisition node is used to send the probe message based on the IPMI protocol to a designated management port of the server to be discovered via the UDP protocol, wherein the probe message carries the out-of-band management account and password information.

[0139] In an exemplary embodiment of the present invention, the parsing result determination module 63 is used to collect an IPMI string containing the device information from the HTTP or HTTPS port of the server to be discovered via TCP protocol after receiving the response data.

[0140] In an exemplary embodiment of the present invention, the parsing result determination module 63 is used to parse the collected IPMI string and extract the IP address, out-of-band MAC address, device type, device serial number, motherboard information and firmware version of the server to be discovered as the parsing result.

[0141] In an exemplary embodiment of the present invention, the parsing result retrieval module 64 is used to query the database list of the management platform for whether there is a management device object that matches the IP address based on the IP address in the parsing result, and the retrieval result indicates whether there is a matching management device object.

[0142] In an exemplary embodiment of the present invention, the management device processing module 65 is configured to, when the search result indicates the existence of a management device object matching the IP address, compare the IP address, out-of-band MAC address, device type, device serial number, motherboard information, and firmware version in the parsing result with the existing information of the management device object, and update the management device object when there are differences in the information.

[0143] In an exemplary embodiment of the present invention, the management device processing module 65 is configured to use the motherboard information or firmware version in the parsing result to overwrite the corresponding information of the management device object when the motherboard information or firmware version in the parsing result is inconsistent with the existing information of the management device object.

[0144] In an exemplary embodiment of the present invention, the management device processing module 65 is configured to create a new management device object in the management platform when the search result indicates that there is no management device object matching the IP address, and store the IP address, out-of-band MAC address, device type, device serial number, motherboard information and firmware version in the parsing result into the new management device object.

[0145] In an exemplary embodiment of the present invention, the collection node information includes information distributed across multiple cloud pool nodes, and the collection node is used to probe the server to be discovered via a private network to support automatic server discovery across multiple data centers.

[0146] In an exemplary embodiment of the present invention, the data acquisition node, the management platform, and the management list adopt a cloud-based primary and backup deployment architecture, wherein the data acquisition node, the management platform, and the management list are respectively deployed on a primary node and a backup node in the cloud.

[0147] As the system implementation is basically similar to the method implementation, it is described in a relatively simple way. For relevant details, please refer to the description of the method implementation.

[0148] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0149] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0150] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1A device that provides the functions specified in one or more boxes.

[0151] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0152] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0153] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0154] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0155] The foregoing has provided a detailed description of a server discovery and management method and a server discovery and management system based on an out-of-band management network provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for server discovery and management based on out-of-band management network, characterized in that, The method comprises: configuring out-of-band management network information for device automatic discovery, collecting node information, and access credential information of a server to be discovered; issuing a collection task to a collection node according to the out-of-band management network information and the collection node information, wherein the collection node is configured to send a probe packet containing the access credential information to the server to be discovered; receiving response data returned by the server to be discovered according to the probe packet, and collecting device information from the server to be discovered after confirming the existence of the server to be discovered based on the response data, and analyzing the device information to obtain an analysis result; searching in a management list according to the analysis result to obtain a search result; updating or creating a management device object according to the search result, and displaying the management device object in a display list, wherein the management device object is used to represent a management entity of the server to be discovered.

2. The method of claim 1, wherein, The configuration of the out-of-band management network information for device automatic discovery, the collection node information, and the access credential information of the server to be discovered comprises: setting an out-of-band IP network segment range in a management platform, selecting the collection node for automatic discovery, and inputting out-of-band management account and password information of the server to be discovered.

3. The method of claim 2, wherein, The issuing of the collection task to the collection node according to the out-of-band management network information and the collection node information comprises: sending a collection task instruction to a specified management port of the collection node through a TCP protocol to trigger the collection node to perform a server probe task.

4. The method of claim 3, wherein, The collection node is configured to send the probe packet based on an IPMI protocol to a specified management port of the server to be discovered through a UDP protocol, wherein the probe packet carries the out-of-band management account and password information.

5. The method of claim 1, wherein, The receiving of the response data returned by the server to be discovered according to the probe packet, and the collection of device information from the server to be discovered after confirming the existence of the server to be discovered based on the response data comprises: after receiving the response data, collecting an IPMI string containing the device information from an HTTP or HTTPS port of the server to be discovered through a TCP protocol.

6. The method of claim 5, wherein, The analysis of the device information to obtain an analysis result comprises: analyzing the collected IPMI string, and extracting an IP address, an out-of-band MAC address, a device type, a device serial number, motherboard information, and a firmware version of the server to be discovered as the analysis result.

7. The method of claim 6, wherein, The searching in a management list according to the analysis result to obtain a search result comprises: according to the IP address in the analysis result, querying whether there is a management device object matching the IP address in a database list of the management platform, and the search result indicating whether there is a matching management device object.

8. The method of claim 7, wherein, The updating of the management device object according to the search result comprises: When the search result indicates that the management device object matching the IP address exists, the IP address, out-of-band MAC address, device type, device serial number, mainboard information, and firmware version in the parsing result are compared with existing information of the management device object, and the management device object is updated when there is a difference in information.

9. The method of claim 8, wherein, The updating of the management device object when there is a difference in information comprises: When the mainboard information or firmware version in the parsing result is inconsistent with the existing information of the management device object, the mainboard information or firmware version in the parsing result is used to overwrite the corresponding information of the management device object.

10. The method of claim 7, wherein, The creating of the management device object according to the search result comprises: When the search result indicates that the management device object matching the IP address does not exist, a new management device object is created in the management platform, and the IP address, out-of-band MAC address, device type, device serial number, mainboard information, and firmware version in the parsing result are stored to the new management device object.

11. The method of claim 2, wherein, The collected node information comprises information distributed in multiple cloud pool nodes, and the collection node is configured to probe the to-be-discovered server through a private network to support automatic discovery of servers across multiple data centers.

12. The method of claim 11, wherein, The collection node, the management platform, and the management list adopt a cloud-based primary-backup deployment architecture, wherein the collection node, the management platform, and the management list are respectively deployed on a cloud primary node and a backup node.

13. A server discovery and management system based on out-of-band management network, characterized by, The system comprises: A related information configuration module configured to configure out-of-band management network information for device automatic discovery, collection node information, and access credential information of a to-be-discovered server; A collection task issuing module configured to issue a collection task to a collection node according to the out-of-band management network information and the collection node information, wherein the collection node is configured to send a probe packet containing the access credential information to the to-be-discovered server; A parsing result determination module configured to receive response data returned by the to-be-discovered server according to the probe packet, and to determine that the to-be-discovered server exists based on the response data, collect device information from the to-be-discovered server, and parse the device information to obtain a parsing result; A parsing result search module configured to search in a management list according to the parsing result to obtain a search result; A management device processing module configured to update or create a management device object according to the search result, and to display the management device object in a display list, wherein the management device object is configured to represent a management entity of the to-be-discovered server.

14. An electronic device, comprising: Comprise: One or more processors; And One or more machine-readable media having instructions stored thereon that, when executed by the one or more processors, cause the electronic device to perform the out-of-band management network-based server discovery and management method of any one of claims 1 to 12.

15. A computer readable storage medium characterized by: The computer program stored therein causes the processor to perform the out-of-band management network-based server discovery and management method of any one of claims 1 to 12.

Images