Hardware device configuration testing method and device

Abstract

The application provides a hardware device configuration test method and device, wherein the application realizes unified distribution of hardware configuration test data in a large-scale hardware scene with multiple resource pools by using a distributed architecture, improves hardware configuration test data import efficiency, and reduces data maintenance cost. In addition, while multiple modules cooperate to complete hardware configuration testing, each business function module can be independently operated by being decoupled from each other, so that the system modules can be flexibly plugged in and plugged out for different device configuration test scenes; meanwhile, each module continuously and cyclically executes each round of configuration or test at a specific time interval, realizes (quasi-) real-time update of device configuration, and achieves the effect of continuously fitting the device to the desired state. In addition, the application can realize self-identification of a local server to a resource pool, pulling of hardware configuration test data corresponding to the resource pool, and completion of hardware device configuration testing, greatly reducing the manual workload while ensuring the accuracy of related links.

Description

Technical Field

[0001] This invention relates to the field of equipment management technology, specifically to a hardware device configuration testing method and equipment. Background Technology

[0002] Existing hardware equipment configuration and testing systems, such as server initialization systems, typically employ a preboot execution environment (PXE) process for single resource pools to perform batch initialization system installation and network interface IP configuration after server startup. Subsequently, relevant remote batch configuration scripting languages ​​(such as Ansible) are used to perform system service installation, system configuration, and other deployment and installation tasks.

[0003] Existing hardware configuration testing systems are typically deployed within a single hardware resource pool. In scenarios with multiple hardware resource pools, multiple systems need to be deployed. Furthermore, each resource pool system operates independently, and data such as hardware configuration test status and results are generated for a single resource pool.

[0004] Existing hardware device configuration testing systems typically employ separate scripts or a monolithic system to handle the configuration and testing of different device types (servers, switches). These scripts or monolithic systems generally perform command-based configuration and testing of hardware devices through automated or semi-automated methods. After installation and deployment, existing hardware device configuration testing systems require manual identification of the system's resource pool, importing the corresponding device information from that pool, and then executing the relevant hardware device configuration and testing. Summary of the Invention

[0005] At least one embodiment of the present invention provides a hardware device configuration testing method and device, which realizes the unified distribution of hardware configuration test data in large-scale hardware scenarios with multiple resource pools, improves the efficiency of hardware configuration test data import, and reduces data maintenance costs.

[0006] According to one aspect of the present invention, at least one embodiment provides a distributed hardware device configuration testing system, including a central server and local servers distributed among various hardware resource pools, wherein the central server is connected to each local server; wherein:

[0007] The central server is used to determine the hardware resource pool to which the local server belongs based on the hardware device information in the hardware resource pool to which the local server belongs, and to send the hardware configuration data and / or hardware test data of the hardware resource pool to which the local server belongs to the local server to the local server.

[0008] The local server is configured to send hardware device information from the hardware resource pool to which it belongs to the central server, receive hardware configuration data and / or hardware test data from the central server, and perform hardware configuration based on the hardware configuration data, and / or perform hardware testing based on the hardware test data.

[0009] Furthermore, according to at least one embodiment of the present invention, the local server is also used to execute the first process and the second process in parallel to obtain hardware device information within the hardware resource pool to which the local server belongs.

[0010] Furthermore, according to at least one embodiment of the present invention, the local server is also configured to execute one of the first process and the second process to obtain hardware device information within the hardware resource pool to which the local server belongs; when executing one of the first process and the second process fails to obtain hardware device information within the hardware resource pool to which the local server belongs, the other process in the first process and the second process is executed to obtain hardware device information within the hardware resource pool to which the local server belongs.

[0011] Furthermore, according to at least one embodiment of the present invention, the local server is also used for continuous periodic operation. When the internal equipment of the hardware resource pool where the local server is located completes construction and is ready for hardware configuration and / or hardware testing, the local server performs hardware configuration and / or hardware testing of the internal equipment.

[0012] Furthermore, according to at least one embodiment of the present invention, the local server is also used to continuously and periodically operate, and when it obtains the latest hardware configuration data and / or hardware test data from the central server, it performs corresponding hardware configuration and / or hardware test updates based on the latest hardware configuration data and / or hardware test data.

[0013] Furthermore, according to at least one embodiment of the present invention, in the first process, the local server assigns DHCP IP addresses to internal devices in its hardware resource pool and stores the assigned DHCP IP addresses in the local server database.

[0014] Furthermore, according to at least one embodiment of the present invention, in the first process, the local server queries the database to obtain the DHCP IP address, logs into the internal device using the DHCP IP address and device login information, and obtains the device identification information of the internal device.

[0015] Furthermore, according to at least one embodiment of the present invention, in the first process, the local server sends the device identification information of the internal device as a kind of hardware device information to the central server, so that the central server uses the hardware device information to match the hardware resource pool to which the local server belongs, and then obtains the hardware configuration data and / or hardware test data corresponding to the hardware resource pool and sends it to the local server.

[0016] Furthermore, according to at least one embodiment of the present invention, in the second process, the local server obtains the device name of the internal device connected to the local server through the Link Discovery Protocol (LLDP).

[0017] Furthermore, according to at least one embodiment of the present invention, in the second process, the local server sends the device name of the internal device as another type of hardware device information to the central server, so that the central server uses the hardware device information to match the hardware resource pool to which the local server belongs, and then obtains the hardware configuration data and / or hardware test data corresponding to the hardware resource pool.

[0018] Furthermore, according to at least one embodiment of the present invention, in the first or second process, before sending the obtained hardware device information of the internal device to the central server, the local server performs a query and comparison in the local server database. If the device identification information of the internal device is matched, the hardware configuration data and / or hardware test data of the matched internal device are used to perform hardware configuration and / or hardware testing on the device.

[0019] Furthermore, according to at least one embodiment of the present invention, the local server is also used to continuously and periodically operate, assign DHCP IP addresses to internal devices that have completed construction in their respective hardware resource pools, and store the assigned DHCP IP addresses in the local server database.

[0020] Furthermore, according to at least one embodiment of the present invention, the local server is also used to query the database to obtain the DHCP IP address, log in to the internal device using the DHCP IP address and device login information, and obtain the device identification information of the internal device.

[0021] Furthermore, according to at least one embodiment of the present invention, the local server is also configured to query and compare the acquired device identification information of the internal device in the local server database, and perform hardware configuration and / or hardware testing on the device using the matched hardware configuration data and / or hardware test data of the internal device.

[0022] Furthermore, according to at least one embodiment of the present invention, the local server is also used to send the hardware configuration result obtained after performing hardware configuration and / or the hardware test result obtained after performing hardware testing to the central server.

[0023] Furthermore, according to at least one embodiment of the present invention, the central server is connected to each local server via a VPN tunnel.

[0024] According to another aspect of the present invention, at least one embodiment provides a hardware device configuration testing method, applied to a distributed hardware device configuration testing system including a central server and local servers distributed in various hardware resource pools, comprising:

[0025] The local server sends the hardware device information of the hardware resource pool to which the local server belongs to the central server.

[0026] The local server receives hardware configuration data and / or hardware test data from the central server, and performs hardware configuration based on the hardware configuration data, and / or performs hardware testing based on the hardware test data.

[0027] Furthermore, according to at least one embodiment of the present invention, before sending the hardware device information within the hardware resource pool to which the local server belongs to the central server, the method further includes:

[0028] The local server executes the first process and the second process in parallel to obtain hardware device information within the hardware resource pool to which the local server belongs.

[0029] Furthermore, according to at least one embodiment of the present invention, before sending the hardware device information within the hardware resource pool to which the local server belongs to the central server, the method further includes:

[0030] The local server executes one of the first and second processes to obtain hardware device information within the hardware resource pool to which the local server belongs; when executing one of the first and second processes fails to obtain hardware device information within the hardware resource pool to which the local server belongs, the other of the first and second processes is executed to obtain hardware device information within the hardware resource pool to which the local server belongs.

[0031] Furthermore, according to at least one embodiment of the present invention, it further includes:

[0032] The local server runs continuously and periodically. When the internal equipment of the hardware resource pool where the local server is located completes construction and is ready for hardware configuration and / or hardware testing, the local server performs hardware configuration and / or hardware testing on the internal equipment.

[0033] Furthermore, according to at least one embodiment of the present invention, it further includes:

[0034] The local server runs continuously and periodically. When it obtains the latest hardware configuration data and / or hardware test data from the central server, it performs the corresponding hardware configuration and / or hardware test updates based on the latest hardware configuration data and / or hardware test data.

[0035] Furthermore, according to at least one embodiment of the present invention, in the first process, the local server assigns DHCP IP addresses to internal devices in its hardware resource pool and stores the assigned DHCP IP addresses in the local server database.

[0036] Furthermore, according to at least one embodiment of the present invention, in the first process, the local server queries the database to obtain the DHCP IP address, logs into the internal device using the DHCP IP address and device login information, and obtains the device identification information of the internal device.

[0037] Furthermore, according to at least one embodiment of the present invention, in the first process, the local server sends the device identification information of the internal device as a kind of hardware device information to the central server, so that the central server uses the hardware device information to match the hardware resource pool to which the local server belongs, and then obtains the hardware configuration data and / or hardware test data corresponding to the hardware resource pool and sends it to the local server.

[0038] Furthermore, according to at least one embodiment of the present invention, in the second process, the local server obtains the device name of the internal device connected to the local server through the Link Discovery Protocol (LLDP).

[0039] Furthermore, according to at least one embodiment of the present invention, in the second process, the local server sends the device name of the internal device as another type of hardware device information to the central server, so that the central server uses the hardware device information to match the hardware resource pool to which the local server belongs, and then obtains the hardware configuration data and / or hardware test data corresponding to the hardware resource pool.

[0040] Furthermore, according to at least one embodiment of the present invention, in the first or second process, before sending the obtained hardware device information of the internal device to the central server, the local server performs a query and comparison in the local server database. If the device identification information of the internal device is matched, the hardware configuration data and / or hardware test data of the matched internal device are used to perform hardware configuration and / or hardware testing on the device.

[0041] Furthermore, according to at least one embodiment of the present invention, it further includes:

[0042] The local server runs continuously and periodically, assigning DHCP IP addresses to internal devices that have completed construction within its hardware resource pool, and storing the assigned DHCP IP address information in the local server database.

[0043] Furthermore, according to at least one embodiment of the present invention, it further includes:

[0044] The local server queries the database to obtain the DHCP IP address, logs into the internal device using the DHCP IP address and device login information, and obtains the device identification information of the internal device.

[0045] Furthermore, according to at least one embodiment of the present invention, it further includes:

[0046] The local server queries and compares the acquired device identification information of the internal device in the local server database, and performs hardware configuration and / or hardware testing on the device using the matched hardware configuration data and / or hardware test data of the internal device.

[0047] Furthermore, according to at least one embodiment of the present invention, it further includes:

[0048] The local server will send the hardware configuration results obtained after performing hardware configuration and / or the hardware test results obtained after performing hardware testing to the central server.

[0049] According to another aspect of the present invention, at least one embodiment provides a hardware device configuration testing method, applied to a distributed hardware device configuration testing system including a central server and local servers distributed in various hardware resource pools, comprising:

[0050] The central server receives hardware device information from the hardware resource pool to which the local server belongs, sent by the local server.

[0051] The central server determines the hardware resource pool to which the local server belongs based on the hardware device information in the hardware resource pool sent by the local server, and sends the hardware configuration data and / or hardware test data of the hardware resource pool to which the local server belongs to the local server.

[0052] Furthermore, according to at least one embodiment of the present invention, it further includes:

[0053] The central server generates a global view of the configuration and / or test results of each hardware resource pool based on the hardware configuration results and / or hardware test results sent by each local server.

[0054] According to another aspect of the present invention, at least one embodiment provides a local server, including: a processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of the method described above.

[0055] According to another aspect of the present invention, at least one embodiment provides a central server comprising: a processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of the method described above.

[0056] According to another aspect of the present invention, at least one embodiment provides a computer-readable storage medium on which a program is stored, which, when executed by a processor, implements the steps of the method described above.

[0057] Compared with existing technologies, the hardware device configuration testing method and device provided in this invention utilize a distributed architecture to achieve unified distribution and management of hardware configuration test data and a global view of configuration test progress in large-scale hardware scenarios with multiple resource pools. This significantly improves the efficiency of hardware configuration test data import in such scenarios while reducing data maintenance costs. Furthermore, the global view of hardware configuration test status enables multi-dimensional statistical analysis of status progress in large-scale hardware scenarios with multiple resource pools, automatically aggregating and unifying the previously fragmented status and result data of each resource pool. Additionally, this invention completes hardware configuration testing through the cooperation of multiple modules, while each business function module is decoupled and operates independently, ensuring that each module can be flexibly plugged in and out for different device configuration test scenarios. Simultaneously, each module continuously executes each round of configuration or testing at specific time intervals, achieving (quasi) real-time updates of device configuration and continuously fitting the device towards the desired state. In addition, the embodiments of the present invention can enable the local server to automatically identify the resource pool it belongs to, retrieve the hardware configuration test data corresponding to the resource pool, and complete the hardware device configuration test without human intervention. In multi-resource pool scenarios, this greatly reduces the amount of manual work required to determine the resource pool where the system belongs and to manually import the hardware configuration test data of the resource pool, while ensuring the accuracy of related processes. Attached Figure Description

[0058] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0059] Figure 1 This is a schematic diagram of a distributed hardware device configuration test system according to an embodiment of the present invention;

[0060] Figure 2 This is a schematic diagram of the structure of a local server according to an embodiment of the present invention;

[0061] Figure 3 A schematic diagram of the device configuration test module of the local server in an embodiment of the present invention;

[0062] Figure 4 This is an example diagram illustrating the interaction between the main control module and various sub-modules of a local server.

[0063] Figure 5 Another example diagram illustrating the interaction between the main control module and various sub-modules on a local server;

[0064] Figure 6 A flowchart illustrating the hardware device configuration testing method of this invention when applied to a local server;

[0065] Figure 7 A flowchart illustrating the hardware device configuration test method of this invention when applied to a central server;

[0066] Figure 8 A schematic diagram of the structure of a local server for a terminal provided in an embodiment of the present invention;

[0067] Figure 9 This is a schematic diagram of the structure of a central server for a terminal provided in an embodiment of the present invention. Detailed Implementation

[0068] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the invention and to fully convey the scope of the invention to those skilled in the art.

[0069] The terms “first,” “second,” etc., used in the specification and claims of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus. The terms “and / or” in the specification and claims indicate at least one of the connected objects.

[0070] The following description provides examples and is not intended to limit the scope, applicability, or configuration set forth in the claims. Changes may be made to the function and arrangement of the elements discussed without departing from the spirit and scope of this disclosure. Various procedures or components may be appropriately omitted, substituted, or added to the examples. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Furthermore, features described with reference to certain examples may be combined in other examples.

[0071] As described in the background section, existing hardware device configuration testing systems typically suffer from the following problems:

[0072] 1. Existing hardware configuration testing systems are generally deployed for use only for a single hardware resource pool. In scenarios with multiple hardware resource pools, each resource pool system runs independently, and data such as the relevant hardware configuration test status and results generally cannot be automatically summarized, statistically analyzed, and thus cannot achieve a global view in scenarios with multiple resource pools.

[0073] 2. Existing hardware configuration testing systems typically use separate scripts or systems for single-command configuration and testing of different types of devices (servers, switches). When the relevant device configuration and test data are updated, manual intervention is required to re-trigger the configuration and testing to complete the hardware device update. When the hardware resource pool is large and contains a large number of devices, the introduced manual workload is significant and prone to errors.

[0074] 3. Existing hardware configuration testing systems require manual intervention to determine the resource pool where the system resides, import the hardware configuration and test data from the resource pool, and then execute the relevant hardware configuration and testing. This involves high costs for manual communication, coordination, and confirmation, and is prone to errors. When there are many resource pools, especially when a system wants to reuse resources across multiple pools, maintaining the information of the resource pool where a system resides requires a significant amount of manual work, and the real-time nature and accuracy of the information cannot be guaranteed.

[0075] To address the shortcomings of existing technologies, this invention proposes a distributed large-scale hardware device configuration testing system. This system employs a distributed architecture consisting of a central server and local servers distributed across various hardware resource pools (such as data centers) to achieve unified distribution of hardware configuration data and a global view of hardware configuration test status. Local servers located in each resource pool complete hardware configuration testing through multi-module collaboration. Each business function module is decoupled and operates independently, allowing for flexible module plug-and-play functionality to meet the configuration testing needs of different devices. Each business function module can continuously and cyclically execute each round of configuration or testing at specific time intervals, achieving (quasi-)real-time updates of device configuration and continuously fitting the device towards the desired state. Local servers can automatically identify their respective resource pools, retrieve corresponding hardware configuration test data, and complete hardware device configuration testing without any manual intervention.

[0076] like Figure 1 As shown, the distributed hardware device configuration testing system provided in this embodiment of the invention includes a central server (CS) and local servers (LS) distributed across various hardware resource pools (e.g., resource pool 1, 2, ..., n). The central server is connected to each local server. Specifically, the central server and each local server are connected via a VPN tunnel.

[0077] The central server is used to determine the hardware resource pool to which the local server belongs based on the hardware device information in the hardware resource pool to which the local server belongs, and to send the hardware configuration data and / or hardware test data of the hardware resource pool to which the local server belongs to the local server to the local server.

[0078] The local server is configured to send hardware device information from the hardware resource pool to which it belongs to the central server, receive hardware configuration data and / or hardware test data from the central server, and perform hardware configuration based on the hardware configuration data, and / or perform hardware testing based on the hardware test data.

[0079] In addition, the local server is also used to send the hardware configuration results obtained after performing hardware configuration and / or the hardware test results obtained after performing hardware testing to the central server. The central server generates a global view of the configuration and test results of each hardware resource pool based on the hardware configuration results and / or hardware test results sent by each local server. Here, the global view of hardware configuration and test results enables multi-dimensional statistical analysis of the status and progress in large-scale hardware scenarios with multiple resource pools, automatically aggregating and unifying the previously fragmented status and result data of each resource pool.

[0080] This invention utilizes a central server to uniformly distribute hardware configuration data across various hardware resource pools and obtain a global view of the hardware configuration and testing of each resource pool. Each resource pool's local server performs hardware device configuration and acceptance testing, and then reports the configuration and acceptance reports, along with relevant statistical information, to the central server.

[0081] In this embodiment of the invention, the local server can obtain hardware device information within the hardware resource pool to which the local server belongs through at least two processes, such as a first process and a second process.

[0082] Specifically, the local server can execute the first process and the second process in parallel to obtain hardware device information within the hardware resource pool to which the local server belongs. Alternatively, the local server can execute one of the first and second processes to obtain hardware device information within the hardware resource pool to which the local server belongs; if executing either the first or second process fails to obtain hardware device information within the hardware resource pool to which the local server belongs, the other process of the first and second processes is executed to obtain hardware device information within the hardware resource pool to which the local server belongs.

[0083] To facilitate timely configuration or testing of newly added devices within the resource pool, the local server can run continuously and periodically. When an internal device in the hardware resource pool containing the local server completes construction and is ready for hardware configuration and / or hardware testing, the local server performs the hardware configuration and / or hardware testing on that internal device. This continuous periodic operation means that the local server remains operational and periodically performs the aforementioned configuration or testing processes on newly completed devices.

[0084] For example, the local server can run continuously and periodically. When it obtains the latest hardware configuration data and / or hardware test data from the central server, it performs the corresponding hardware configuration and / or hardware test updates based on the latest hardware configuration data and / or hardware test data.

[0085] The following provides specific examples of the first and second processes for a local server to obtain hardware device information from the hardware resource pool to which the local server belongs.

[0086] First step:

[0087] In the first process, the local server assigns DHCP IP addresses to internal devices within its hardware resource pool and stores these addresses in its local database. Additionally, the local server can query the database to obtain the DHCP IP addresses, log in to the internal devices using these addresses and device login information, and retrieve the device identification information of the internal devices. The local server can also send the device identification information of the internal devices as hardware device information to the central server, enabling the central server to use this information to match the hardware resource pool to which the local server belongs, thereby obtaining the corresponding hardware configuration data and / or hardware test data and sending it to the local server.

[0088] Second process:

[0089] In the second process, the local server obtains the device names of the internal devices it connects to via the Link Discovery Protocol (LLDP). Additionally, the local server can send these device names as another type of hardware device information to the central server, enabling the central server to use this information to match the hardware resource pool to which the local server belongs, and subsequently obtain the corresponding hardware configuration data and / or hardware test data for that hardware resource pool.

[0090] It should be noted that, in the first or second process, before sending the obtained hardware device information of the internal device to the central server, the local server can perform a query and comparison in the local server database. If the device identification information of the internal device is matched, the hardware configuration data and / or hardware test data of the matched internal device are used to perform hardware configuration and / or hardware testing on the device.

[0091] For newly added devices in the resource pool, this embodiment of the invention can discover new devices, obtain new device information, match new device data, and perform configuration or testing processes through the following processes. Specifically, the local server can run continuously and periodically, assigning DHCP IP addresses to internal devices that have completed construction in their respective hardware resource pools, and storing the assigned DHCP IP addresses in the local server database. The local server can also query the database to obtain the DHCP IP addresses, log in to the internal devices using the DHCP IP addresses and device login information, and obtain the device identification information of the internal devices. Then, the local server can further query and compare the obtained device identification information of the internal devices in the local server database, and perform hardware configuration and / or hardware testing on the devices using the matched hardware configuration data and / or hardware test data of the internal devices.

[0092] The following example illustrates the specific functional structure of a local server.

[0093] like Figure 2 As shown, the local server in this embodiment of the invention may include a main control module, a service providing module, a device discovery module, and a device configuration testing module; wherein:

[0094] The service providing module is used to provide DHCP and / or PXE services for the initial configuration of hardware devices in the hardware resource pool to which the local server belongs;

[0095] The device discovery module is used to obtain hardware device information from the hardware resource pool to which the local server belongs and send it to the main control module;

[0096] The main control module is used as a web server to communicate with the central server and the device configuration test module, receive hardware device information sent by the device discovery module and send it to the central server, receive hardware configuration data and / or hardware test data sent by the central server and send it to the corresponding device configuration test module, and receive hardware configuration results and / or hardware test results sent by the device configuration test module and send them to the central server.

[0097] The device configuration test module is used to receive hardware configuration data and / or hardware test data sent by the main control module, perform hardware initialization configuration and / or test processing on the hardware devices in the hardware resource pool to which the local server belongs, and send the obtained hardware configuration results and / or hardware test results to the main control module.

[0098] In this embodiment of the invention, the configuration module and test module for various devices (such as servers or switches) are collectively referred to as the device configuration test module. Figure 2 As shown, the device configuration test module may specifically include a device initialization configuration module, a device configuration module, and a device test module. For different types of devices, the device configuration module may specifically include a server configuration module and a switch configuration module, etc., and the device test module may specifically include a server test module, a switch test module, and a connection test module, etc.

[0099] It can be seen that the local servers distributed across various hardware resource pools have the function of configuring and testing the hardware devices (switches, servers) of the resource pools. This function can be implemented through multiple logical modules. These logical modules use corresponding protocols to implement different functions (configuration or testing) for different types of devices (switches or servers), such as... Figure 3As shown, the local server's device configuration testing module specifically includes a server configuration module, a server testing module, a switch configuration module, a switch testing module, and a connectivity testing module. For example, the Secure Shell (SSH) protocol is used for switches, while the Redfish protocol or the Intelligent Platform Management Interface (IMPI) protocol is used for servers. Logical modules with different functions can be configured flexibly as needed through configuration files, ensuring that the system can use appropriate module configurations to meet corresponding requirements when facing different hardware configuration testing scenarios. Additionally, as... Figure 3 As shown, the internal devices of the hardware resource pool include internal switches and internal servers. Here, the internal switches and internal servers are switches / servers to be configured or tested.

[0100] In this embodiment of the invention, the device configuration testing module includes a device initialization configuration module, a device configuration module, and a device testing module; wherein, the device initialization configuration module includes a switch initialization configuration module and a server initialization configuration module; the device testing module includes a switch testing module and a server testing module.

[0101] The switch initialization configuration module and the server initialization configuration module are respectively used to receive hardware configuration data sent by the main control module, execute the corresponding hardware configuration, and return the hardware configuration result to the main control module;

[0102] The switch testing module and the server testing module are respectively used to receive hardware test data sent by the main control module, execute the corresponding hardware tests, and return the hardware test results to the main control module.

[0103] In addition, such as Figure 3 As shown, the local server may further include:

[0104] The connection test module is used to compare the expected connection information with the actual connection information obtained by the switch test module and perform connection tests.

[0105] To achieve near-real-time updates of device configuration and testing, in this embodiment of the invention, each submodule in the local server periodically obtains its latest hardware configuration data and / or hardware test data from the main control module, and executes the corresponding hardware configuration and / or hardware test when it determines that the latest hardware configuration data and / or hardware test data of its submodule has been updated. Here, each submodule includes the service providing module, each device discovery module, each device configuration testing module, and the connectivity testing module.

[0106] As one implementation, the local server is further configured to execute a first process to obtain hardware configuration data and / or hardware test data issued by the central server and perform corresponding hardware configuration or hardware testing; wherein, in the first process:

[0107] The service providing module is also used to assign DHCP IP addresses to the management ports of internal devices in the hardware resource pool to which the local server belongs;

[0108] The device discovery module is also used to obtain the DHCP IP address assigned by the service providing module to the management port of the internal device and send it to the main control module so that the main control module saves the DHCP IP address in the local database;

[0109] The device initialization configuration module is used to obtain the DHCP IP address from the main control module, log in to the internal device using the DHCP IP address and the device's pre-configured login information (such as the SSH remote login information configured on the switch device, including username and password), obtain the device identification information of the internal device, and send it to the main control module.

[0110] The main control module is used to send the device identification information of the internal device as a kind of hardware device information to the central server, so that the central server can use the hardware device information to match the hardware resource pool to which the local server belongs, and then obtain the hardware configuration data and / or hardware test data corresponding to the hardware resource pool and send them to the main control module.

[0111] As another implementation, the local server is further configured to execute a second process to obtain hardware configuration data and / or hardware test data issued by the central server and to perform corresponding hardware configuration or hardware testing; wherein, in the second process:

[0112] The device discovery module is also used to obtain the device name of the internal device connected to the local server through the Link Discovery Protocol (LLDP) and send it to the main control module.

[0113] The main control module is used to send the device name of the internal device as another type of hardware device information to the central server, so that the central server can use the hardware device information to match the hardware resource pool to which the local server belongs, and then obtain the hardware configuration data and / or hardware test data corresponding to the hardware resource pool and send them to the main control module.

[0114] As another implementation, the local server is also used to repeatedly execute the first process and the second process according to a preset time period, thereby achieving the effect of continuously fitting the device to the desired state.

[0115] As can be seen from the above, the local server system of this embodiment of the invention has a main logic module (main control module), which is responsible for interacting with the central server and various hardware device configuration and testing sub-modules. The main control module interacts with the central server to obtain hardware configuration or test data from the resource pool where the local server resides, and feeds back information such as hardware device configuration or test results to the central server. Through interaction with the various hardware device configuration and testing sub-modules in the local server, the main control module enables each module to obtain hardware configuration or test data, complete the corresponding device configuration and testing functions, and then each sub-module returns the result data to the main control module. Under this architecture, each business function sub-module only needs to interact with the main control module; there is no need for interaction between sub-modules.

[0116] Each submodule of the local server runs continuously in a loop. At the beginning of each loop, it obtains the latest hardware configuration or test data from the main control module through a specific interface. This ensures that when the hardware configuration or test data is updated and synchronized from the central server to the local server, the relevant submodules can update the device configuration or test data in near real time, thereby achieving the effect of continuously fitting the device to the desired state.

[0117] The continuous operation of each submodule simplifies the configuration process control for different types of devices with configuration dependencies. For example, server configuration depends on the PXE boot process, while the PXE boot process of the server to be configured depends on the switch completing VLAN-related configuration. The server-related modules execute cyclically. Once the switch initialization module completes the necessary configuration, the server-related modules will complete the relevant configuration and testing in the next cycle. The previous cycles were just idle.

[0118] Please refer to Figure 4 and Figure 5 This document provides an example of the interaction between the main control module and its various sub-modules on a local server. Using this example, the functions of each module are explained in more detail.

[0119] The main control module of the local server acts as a web server, providing a RESTful interface to communicate with the central server and various hardware configuration testing sub-modules on the local server. As the core of the local server, this main control module is responsible for providing hardware device configuration test data to each sub-module, retrieving hardware configuration test results from each sub-module, and writing the results to the local server's database. Each sub-module only interacts with the main module to obtain the necessary data. This design pattern decouples the sub-modules, ensuring that the flexible plugging and unplugging of relevant sub-modules according to different configuration test scenarios will not affect other modules.

[0120] DHCP Server / PXE Service Module: Provides the necessary DHCP / PXE server services for initializing and configuring hardware devices (switches, servers).

[0121] Resource Pool Device Information Discovery Module: This module is responsible for obtaining the device information required for the local server to self-identify its resource pool. It polls at specific time intervals to obtain the DHCP IP assigned by the DHCP / PXE service module and the device name of the switch connected to the local server. This supports resource pool self-identification in different scenarios.

[0122] (1) The DHCP LEASE file generated by the DHCP / PXE service is read to obtain the DHCP IP assigned to the hardware device by the local server, and this information is sent back to the main module. Subsequently, the switch initialization configuration module reads the DHCP IP information from the main module and uses the DHCP IP to log in to the switch and obtain the device SN code for subsequent matching to determine the resource pool corresponding to the device, such as... Figure 5 1.1 to 1.8 in the range.

[0123] (2) Obtain the uplink peer switch name (hostname) information by reading the Link Layer Discovery Protocol (LLDP) information of the local server's network interface, and use this information for subsequent device name matching to determine the resource pool where the local server is located, such as... Figure 5 Sections 2.1 to 2.3.

[0124] Server Initialization Configuration Module: This module is responsible for the initialization configuration of the Baseboard Management Controller (BMC). The main configuration content includes the BMC IP address and gateway. This module is stored in the PXE memory image used by the DHCP / PXE service module. When the server to be configured is powered on and started by the DHCP / PXE service module, this module is executed as a system startup service. During execution, it first obtains the serial number (SN) information of the server to be configured, then sends it back to the local server master module to match the corresponding configuration data for that server, and finally completes the server BMC configuration based on the matched configuration data.

[0125] Switch Initialization Configuration Module: This module is responsible for the initial configuration of the switch. The main configuration contents include the switch management port IP address and gateway, VLAN configuration, and VLAN enabling configuration for switch ports. This module obtains the switch serial number (SN) by logging into the switch with the assigned DHCP IP (the assigned DHCP IP information is obtained from the resource pool device information discovery module) and sends it back to the local server main module to match the corresponding device configuration data for that switch. Based on the obtained data, it completes the switch initialization configuration.

[0126] Server Testing Module: This module uses the server Redfish protocol to connect to the server BMC IP address to complete server-related tests. The main test contents include server component testing, BMC / BIOS configuration testing, and management interface specification testing.

[0127] Switch testing module: This module logs into the switch via the switch's out-of-band management address (configured on the management port) to complete relevant test items. The main test contents are component testing, optical power testing, etc., and obtains LLDP information for connection testing.

[0128] Connection test module: This module is responsible for comparing the expected connection information (hardware configuration test data) with the actual connection information (obtained by the switch test module) to complete the connection test.

[0129] In this embodiment of the invention, after connecting to a specific switch in the resource pool, the local server can self-identify its resource pool and retrieve the corresponding hardware configuration or test data from the central server, automatically starting hardware device configuration or testing. The local server's resource pool self-identification occurs in two scenarios:

[0130] The first scenario is a "clean" resource pool that has not undergone any device configuration (the devices remain in their factory pre-configured state). In this scenario, the local server assigns DHCP IP addresses to the management ports of the switches within the resource pool using its built-in DHCP server service. It then uses these IP addresses to log in to the switches using the devices' pre-configured login information to obtain device identification information (SN codes). The device SN codes are then fed back to the central server to retrieve the resource pool corresponding to each SN code (the central server's database contains information on the correspondence between all resource pools and their device SNs). Once the central server matches a resource pool using the SN code, it returns the corresponding hardware configuration or test data to the local server, triggering the local server to begin hardware configuration and testing. Figure 5 1.1 to 1.8 in the range.

[0131] The second scenario involves a resource pool with completed hardware configuration. In this case, the switches connected to the local server have already been configured according to the hardware configuration data, including the device name (hostname). The local server obtains the device name of the uplink switch via the Link Discovery Protocol (LLDP). Then, similar to the first scenario, it sends the obtained "device name" back to the central server to match the corresponding resource pool, receives the resource pool's hardware configuration data, and initiates hardware configuration and testing. Figure 5 Sections 2.1 to 2.3.

[0132] The processes described above—logging into the switch to obtain the device serial number via DHCP IP information and obtaining the switch device name via LLDP information—can be performed simultaneously. The resource pool device information discovery module polls for both types of information at specific time intervals and sends back the information obtained by the local server main module for subsequent resource pool matching. Regardless of which process matches a resource pool, the resource pool hardware device configuration or test data is imported into the local server database, triggering the relevant configuration and testing to begin. This mode ensures automatic resource pool discovery in both "no device configuration" and "complete device configuration" scenarios.

[0133] The aforementioned resource pool self-identification process supports resource pool switching scenarios. In actual use, a single local server can configure and test hardware devices from multiple hardware resource pools simultaneously (time-sharing). When a local server switches from resource pool A to resource pool B, the self-identification process determines that the current resource pool is resource pool B and imports the corresponding hardware device configuration or test data. Before importing, the hardware configuration and test results from the original pool (resource pool A) are exported for subsequent configuration and testing of hardware devices in resource pool A.

[0134] As can be seen from the above, the distributed hardware device configuration testing system of this invention has at least the following advantages:

[0135] 1. Compared to existing hardware configuration testing systems, the system in this embodiment utilizes a distributed architecture to achieve unified distribution and management of hardware configuration test data and a global view of configuration test progress in large-scale hardware scenarios with multiple resource pools. This significantly improves the efficiency of hardware configuration test data import in such scenarios while reducing data maintenance costs. The global view of hardware configuration test status enables multi-dimensional statistical analysis of status and progress in large-scale hardware scenarios with multiple resource pools, automatically aggregating and unifying the previously fragmented status and result data of each resource pool.

[0136] 2. Compared to existing hardware configuration testing systems, the system implementation in this embodiment completes hardware configuration testing through the cooperation of multiple modules, while each business function module is decoupled and operates independently, ensuring that each module can be flexibly plugged in and out for different device configuration testing scenarios. Simultaneously, each module continuously and cyclically executes each round of configuration or testing at specific time intervals, achieving (quasi-)real-time updates to the device configuration and continuously fitting the device towards the desired state. Compared to the single-command configuration and testing method used in general systems, a declarative configuration and testing method is used to further reduce the workload of manual intervention.

[0137] 3. Compared with existing hardware configuration testing systems, the system implementation of this invention enables the local server to automatically identify the resource pool it belongs to, retrieve the corresponding hardware configuration test data of the resource pool, and complete the hardware device configuration test without any human intervention. In multi-resource pool scenarios, this greatly reduces the amount of manual work required to determine the resource pool where the system is located and to manually import the hardware configuration test data of the resource pool, while ensuring the accuracy of related processes.

[0138] Please refer to Figure 6 This invention also provides a hardware device configuration testing method, applied to a distributed hardware device configuration testing system including a central server and local servers distributed across various hardware resource pools. The method includes:

[0139] Step 61: The local server sends the hardware device information of the hardware resource pool to which the local server belongs to the central server.

[0140] Step 62: The local server receives hardware configuration data and / or hardware test data sent by the central server, and performs hardware configuration according to the hardware configuration data, and / or performs hardware testing according to the hardware test data.

[0141] Optionally, the above method further includes, before sending the hardware device information from the hardware resource pool to which the local server belongs to the central server:

[0142] The local server executes the first process and the second process in parallel to obtain hardware device information within the hardware resource pool to which the local server belongs.

[0143] Optionally, the above method further includes, before sending the hardware device information from the hardware resource pool to which the local server belongs to the central server:

[0144] The local server executes one of the first and second processes to obtain hardware device information within the hardware resource pool to which the local server belongs; when executing one of the first and second processes fails to obtain hardware device information within the hardware resource pool to which the local server belongs, the other of the first and second processes is executed to obtain hardware device information within the hardware resource pool to which the local server belongs.

[0145] Optionally, the above methods also include:

[0146] The local server runs continuously and periodically. When the internal equipment of the hardware resource pool where the local server is located completes construction and is ready for hardware configuration and / or hardware testing, the local server performs hardware configuration and / or hardware testing on the internal equipment.

[0147] Optionally, the above methods also include:

[0148] The local server runs continuously and periodically. When it obtains the latest hardware configuration data and / or hardware test data from the central server, it performs the corresponding hardware configuration and / or hardware test updates based on the latest hardware configuration data and / or hardware test data.

[0149] Optionally, in the first process, the local server assigns DHCP IP addresses to the internal devices in its hardware resource pool and saves the assigned DHCP IP addresses in the local server database.

[0150] Optionally, in the first process, the local server queries the database to obtain the DHCP IP address, logs into the internal device using the DHCP IP address and device login information, and obtains the device identification information of the internal device.

[0151] Optionally, in the first process, the local server sends the device identification information of the internal device as a kind of hardware device information to the central server, so that the central server can use the hardware device information to match the hardware resource pool to which the local server belongs, and then obtain the hardware configuration data and / or hardware test data corresponding to the hardware resource pool and send them to the local server.

[0152] Optionally, in the second process, the local server obtains the device name of the internal device connected to the local server through the Link Discovery Protocol (LLDP).

[0153] Optionally, in the second process, the local server sends the device name of the internal device as another type of hardware device information to the central server, so that the central server can use the hardware device information to match the hardware resource pool to which the local server belongs, and then obtain the hardware configuration data and / or hardware test data corresponding to the hardware resource pool.

[0154] Optionally, in the first or second process, before sending the obtained hardware device information of the internal device to the central server, the local server performs a query and comparison in the local server database. If the device identification information of the internal device is matched, the hardware configuration data and / or hardware test data of the matched internal device are used to perform hardware configuration and / or hardware testing on the device.

[0155] Optionally, the above methods also include:

[0156] The local server runs continuously and periodically, assigning DHCP IP addresses to internal devices that have completed construction within its hardware resource pool, and storing the assigned DHCP IP addresses in the local server database.

[0157] Optionally, the above methods also include:

[0158] The local server queries the database to obtain the DHCP IP address, logs into the internal device using the DHCP IP address and device login information, and obtains the device identification information of the internal device.

[0159] Optionally, the above methods also include:

[0160] The local server queries and compares the acquired device identification information of the internal device in the local server database, and performs hardware configuration and / or hardware testing on the device using the matched hardware configuration data and / or hardware test data of the internal device.

[0161] Optionally, the above methods also include:

[0162] The local server will send the hardware configuration results obtained after performing hardware configuration and / or the hardware test results obtained after performing hardware testing to the central server.

[0163] Please refer to Figure 7This invention also provides a hardware device configuration testing method, applied to a distributed hardware device configuration testing system including a central server and local servers distributed across various hardware resource pools. The method includes:

[0164] The central server receives hardware device information from the hardware resource pool to which the local server belongs, sent by the local server.

[0165] The central server determines the hardware resource pool to which the local server belongs based on the hardware device information in the hardware resource pool sent by the local server, and sends the hardware configuration data and / or hardware test data of the hardware resource pool to which the local server belongs to the local server.

[0166] Optionally, in the above method, the central server generates a global view of the configuration and / or hardware test results of each hardware resource pool based on the hardware configuration results and / or hardware test results sent by each local server.

[0167] Please refer to Figure 8 This invention provides another schematic diagram of a local server, including: a processor 801, a transceiver 802, a memory 803, and a bus interface, wherein:

[0168] In this embodiment of the invention, the local server further includes: a program stored on memory 803 and executable on processor 801, wherein the program, when executed by processor 801, performs the following steps:

[0169] Send the hardware device information from the hardware resource pool to which the local server belongs to the central server;

[0170] Receive hardware configuration data and / or hardware test data sent by the central server, and perform hardware configuration according to the hardware configuration data, and / or perform hardware testing according to the hardware test data.

[0171] Optionally, when the processor executes the program, it further implements the following steps:

[0172] Before sending the hardware device information from the hardware resource pool to which the local server belongs to the central server, the first process and the second process are executed in parallel to obtain the hardware device information from the hardware resource pool to which the local server belongs.

[0173] Optionally, when the processor executes the program, it further implements the following steps:

[0174] Before sending the hardware device information in the hardware resource pool to which the local server belongs to the central server, one of the first and second processes is executed to obtain the hardware device information in the hardware resource pool to which the local server belongs; if the execution of one of the first and second processes fails to obtain the hardware device information in the hardware resource pool to which the local server belongs, the other of the first and second processes is executed to obtain the hardware device information in the hardware resource pool to which the local server belongs.

[0175] Optionally, when the processor executes the program, it further implements the following steps:

[0176] When the internal devices of the hardware resource pool where the local server is located have completed construction and are ready for hardware configuration and / or hardware testing, the local server performs hardware configuration and / or hardware testing on the internal devices.

[0177] Optionally, when the processor executes the program, it further implements the following steps:

[0178] When the latest hardware configuration data and / or hardware test data are obtained from the central server, the corresponding hardware configuration and / or hardware test updates are performed based on the latest hardware configuration data and / or hardware test data.

[0179] Optionally, in the first process, the local server assigns DHCP IP addresses to the internal devices in its hardware resource pool and saves the assigned DHCP IP addresses in the local server database.

[0180] Optionally, in the first process, the local server queries the database to obtain the DHCP IP address, logs into the internal device using the DHCP IP address and device login information, and obtains the device identification information of the internal device.

[0181] Optionally, in the first process, the local server sends the device identification information of the internal device as a kind of hardware device information to the central server, so that the central server can use the hardware device information to match the hardware resource pool to which the local server belongs, and then obtain the hardware configuration data and / or hardware test data corresponding to the hardware resource pool and send them to the local server.

[0182] Optionally, in the second process, the local server obtains the device name of the internal device connected to the local server through the Link Discovery Protocol (LLDP).

[0183] Optionally, in the second process, the local server sends the device name of the internal device as another type of hardware device information to the central server, so that the central server can use the hardware device information to match the hardware resource pool to which the local server belongs, and then obtain the hardware configuration data and / or hardware test data corresponding to the hardware resource pool.

[0184] Optionally, in the first or second process, before sending the obtained hardware device information of the internal device to the central server, the local server performs a query and comparison in the local server database. If the device identification information of the internal device is matched, the hardware configuration data and / or hardware test data of the matched internal device are used to perform hardware configuration and / or hardware testing on the device.

[0185] Optionally, when the processor executes the program, it further implements the following steps:

[0186] Assign DHCP IP addresses to the internal devices that have completed construction within the hardware resource pool, and save the assigned DHCP IP addresses in the local server database.

[0187] Optionally, when the processor executes the program, it further implements the following steps:

[0188] The database is queried to obtain the DHCP IP address. The internal device is then logged in using the DHCP IP address and the device login information to obtain the device identification information of the internal device.

[0189] Optionally, when the processor executes the program, it further implements the following steps:

[0190] The device identification information of the internal device is queried and compared in the local server database, and the hardware configuration data and / or hardware test data of the matched internal device are used to perform hardware configuration and / or hardware test on the device.

[0191] Optionally, when the processor executes the program, it further implements the following steps:

[0192] The hardware configuration results obtained after performing hardware configuration, and / or the hardware test results obtained after performing hardware testing, are sent to the central server.

[0193] Understandably, in this embodiment of the invention, the computer program executed by the processor 801 can achieve the above-mentioned functions. Figure 6 The various processes of the method embodiments shown can achieve the same technical effect, and will not be described again here to avoid repetition.

[0194] exist Figure 8In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits together, represented by one or more processors (processor 801) and memory (memory 803). The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 802 can be multiple elements, including transmitters and receivers, providing a unit for communicating with various other devices over a transmission medium.

[0195] The processor 801 is responsible for managing the bus architecture and general processing, while the memory 803 can store the data used by the processor 801 when performing operations.

[0196] It should be noted that the terminal in this embodiment is the same as the one described above. Figure 6 The device corresponding to the method shown above, and the implementation methods in each embodiment above, are all applicable to the embodiments of this terminal, and can achieve the same technical effect. In this device, the transceiver 802 and the memory 803, as well as the transceiver 802 and the processor 801, can be connected for communication via a bus interface. The functions of the processor 801 can also be implemented by the transceiver 802, and the functions of the transceiver 802 can also be implemented by the processor 801. It should be noted that the device provided by the embodiments of the present invention can implement all the method steps implemented in the above method embodiments and can achieve the same technical effect. Therefore, the parts that are the same as those in the method embodiments and the beneficial effects will not be described in detail here.

[0197] In some embodiments of the present invention, a computer-readable storage medium is also provided, on which a program is stored, which, when executed by a processor, performs the following steps:

[0198] Send the hardware device information from the hardware resource pool to which the local server belongs to the central server;

[0199] Receive hardware configuration data and / or hardware test data sent by the central server, and perform hardware configuration according to the hardware configuration data, and / or perform hardware testing according to the hardware test data.

[0200] When executed by the processor, this program can implement all the above-mentioned hardware device configuration test methods applied to the local server and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0201] Please refer to Figure 9 This invention provides another schematic diagram of the structure of a central server, including: a processor 901, a transceiver 902, a memory 903, and a bus interface, wherein:

[0202] In this embodiment of the invention, the central server further includes: a program stored on memory 903 and executable on processor 901, wherein the program, when executed by processor 901, performs the following steps:

[0203] Receive hardware device information from the hardware resource pool to which the local server belongs, sent by the local server;

[0204] Based on the hardware device information within the hardware resource pool sent by the local server, determine the hardware resource pool to which the local server belongs, and send the hardware configuration data and / or hardware test data of the hardware resource pool to which the local server belongs to the local server.

[0205] Optionally, when the processor executes the program, it further implements the following steps:

[0206] Based on the hardware configuration results and / or hardware test results sent by each local server, a global view of the configuration test results for each hardware resource pool is generated.

[0207] Understandably, in this embodiment of the invention, the computer program executed by the processor 901 can achieve the above-mentioned functions. Figure 7 The various processes of the method embodiments shown can achieve the same technical effect, and will not be described again here to avoid repetition.

[0208] exist Figure 9 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits together, represented by one or more processors (processor 901) and memory (memory 903). The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 902 can be multiple elements, including transmitters and receivers, providing a unit for communicating with various other devices over a transmission medium.

[0209] The processor 901 is responsible for managing the bus architecture and general processing, while the memory 903 can store the data used by the processor 901 when performing operations.

[0210] It should be noted that the terminal in this embodiment is the same as the one described above. Figure 7The device corresponding to the method shown above, and the implementation methods in each embodiment, are all applicable to the embodiments of this terminal, and can achieve the same technical effect. In this device, the transceiver 902 and the memory 903, as well as the transceiver 902 and the processor 901, can be connected for communication via a bus interface. The function of the processor 901 can also be implemented by the transceiver 902, and the function of the transceiver 902 can also be implemented by the processor 901. It should be noted that the device provided by the embodiments of the present invention can implement all the method steps implemented in the above method embodiments and can achieve the same technical effect. Therefore, the parts that are the same as those in the method embodiments and the beneficial effects will not be described in detail here.

[0211] In some embodiments of the present invention, a computer-readable storage medium is also provided, on which a program is stored, which, when executed by a processor, performs the following steps:

[0212] Receive hardware device information from the hardware resource pool to which the local server belongs, sent by the local server;

[0213] Based on the hardware device information within the hardware resource pool sent by the local server, determine the hardware resource pool to which the local server belongs, and send the hardware configuration data and / or hardware test data of the hardware resource pool to which the local server belongs to the local server.

[0214] When this program is executed by the processor, it can achieve the above-mentioned applications. Figure 7 All implementation methods in the hardware device configuration test method can achieve the same technical effect, and will not be elaborated here to avoid duplication.

[0215] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0216] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0217] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0218] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of the present invention, depending on actual needs.

[0219] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0220] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, 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 steps described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0221] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A distributed hardware device configuration testing system, characterized in that, It includes a central server and local servers distributed across various hardware resource pools, wherein the central server is connected to each local server; wherein: The central server is used to determine the hardware resource pool to which the local server belongs based on the hardware device information in the hardware resource pool to which the local server belongs, and to send the hardware configuration data and / or hardware test data of the hardware resource pool to which the local server belongs to the local server to the local server. The local server is configured to send hardware device information from the hardware resource pool to which the local server belongs to the central server, receive hardware configuration data and / or hardware test data issued by the central server, and perform hardware configuration according to the hardware configuration data, and / or perform hardware testing according to the hardware test data. The local server is also used to execute the first process and the second process in parallel to obtain hardware device information in the hardware resource pool to which the local server belongs; or, execute one of the first process and the second process to obtain hardware device information in the hardware resource pool to which the local server belongs; when executing one of the first process and the second process fails to obtain hardware device information in the hardware resource pool to which the local server belongs, execute the other process in the first process and the second process to obtain hardware device information in the hardware resource pool to which the local server belongs. In the first process, the local server assigns DHCP IP addresses to internal devices in its hardware resource pool and stores the assigned DHCP IP addresses in the local server database. The local server queries the database to obtain the DHCP IP addresses, logs into the internal devices using the DHCP IP addresses and device login information, and obtains the device identification information of the internal devices. The device identification information of the internal devices is sent to the central server as a type of hardware device information, so that the central server can use the hardware device information to match the hardware resource pool to which the local server belongs, and then obtain the hardware configuration data and / or hardware test data corresponding to the hardware resource pool and send it to the local server. In the second process, the local server obtains the device name of the internal device connected to the local server through the Link Discovery Protocol (LLDP); the local server sends the device name of the internal device as another type of hardware device information to the central server, so that the central server can use the hardware device information to match the hardware resource pool to which the local server belongs, and then obtain the hardware configuration data and / or hardware test data corresponding to the hardware resource pool.

2. The system as described in claim 1, characterized in that, The local server is also used for continuous periodic operation. When the internal equipment of the hardware resource pool where the local server is located completes construction and is ready for hardware configuration and / or hardware testing, the local server performs hardware configuration and / or hardware testing of the internal equipment.

3. The system as described in claim 1, characterized in that, The local server is also used for continuous periodic operation. When it obtains the latest hardware configuration data and / or hardware test data from the central server, it performs corresponding hardware configuration and / or hardware test updates based on the latest hardware configuration data and / or hardware test data.

4. The system as described in claim 1, characterized in that, In the first or second process, before sending the obtained hardware device information of the internal device to the central server, the local server performs a query and comparison in the local server database. If the device identification information of the internal device is matched, the hardware configuration data and / or hardware test data of the matched internal device are used to perform hardware configuration and / or hardware testing on the device.

5. The system as described in claim 2, characterized in that, The local server is also used for continuous periodic operation to assign DHCP IP addresses to internal devices that have completed construction in the hardware resource pool, and to store the assigned DHCP IP addresses in the local server database.

6. The system as described in claim 5, characterized in that, The local server is also used to query the database to obtain the DHCP IP address, log in to the internal device using the DHCP IP address and device login information, and obtain the device identification information of the internal device.

7. The system as described in claim 6, characterized in that, The local server is also used to query and compare the acquired device identification information of the internal device in the local server database, and to perform hardware configuration and / or hardware testing on the device using the matched hardware configuration data and / or hardware test data of the internal device.

8. The system as described in claim 1, characterized in that, The local server is also used to send the hardware configuration results obtained after performing hardware configuration and / or the hardware test results obtained after performing hardware testing to the central server.

9. A hardware device configuration testing method, applied to a distributed hardware device configuration testing system including a central server and local servers distributed across various hardware resource pools, characterized in that, include: The local server sends the hardware device information of the hardware resource pool to which the local server belongs to the central server. The local server receives hardware configuration data and / or hardware test data sent by the central server, and performs hardware configuration according to the hardware configuration data, and / or performs hardware testing according to the hardware test data. The local server is also used to execute the first process and the second process in parallel to obtain hardware device information within the hardware resource pool to which the local server belongs. Alternatively, one of the first and second processes may be executed to obtain hardware device information within the hardware resource pool to which the local server belongs; if the execution of one of the first and second processes fails to obtain hardware device information within the hardware resource pool to which the local server belongs, the other of the first and second processes may be executed to obtain hardware device information within the hardware resource pool to which the local server belongs. In the first process, the local server assigns DHCP IP addresses to internal devices in its hardware resource pool and stores the assigned DHCP IP addresses in the local server database. The local server queries the database to obtain the DHCP IP addresses, logs into the internal devices using the DHCP IP addresses and device login information, and obtains the device identification information of the internal devices. The device identification information of the internal devices is sent to the central server as a type of hardware device information, so that the central server can use the hardware device information to match the hardware resource pool to which the local server belongs, and then obtain the hardware configuration data and / or hardware test data corresponding to the hardware resource pool and send it to the local server. In the second process, the local server obtains the device name of the internal device connected to the local server through the Link Discovery Protocol (LLDP); the local server sends the device name of the internal device as another type of hardware device information to the central server, so that the central server can use the hardware device information to match the hardware resource pool to which the local server belongs, and then obtain the hardware configuration data and / or hardware test data corresponding to the hardware resource pool.

10. A local server, characterized in that, include: A processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of the method as described in claim 9.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in claim 9.

Images