Server hardware compatibility testing method and electronic device

Abstract

The application discloses a kind of server hardware compatibility test method and electronic equipment, it is related to server technical field, the application is based on container technology to test hardware compatibility, can realize the quick deployment and efficient isolation of test environment, avoid mutual interference between test threads, through dynamic task scheduling and resource allocation, improve the utilization of server hardware resources, through real-time data acquisition and intelligent analysis, to determine abnormal event in the test process, and through abnormal event processing mechanism guarantee the continuous stable execution of test task, reduce the cost of manual intervention and maintenance difficulty, improve compatibility test efficiency and accuracy.

Description

Technical Field

[0001] This application relates to the field of server technology, and in particular to a server hardware compatibility testing method and electronic device. Background Technology

[0002] Currently, relevant testing platforms utilize virtual machine technology to build testing environments for testing server software systems and some hardware. Some solutions employ containerization technology for application deployment. However, a systematic solution has not yet been formed for testing the compatibility of underlying hardware components, stress testing, and multi-module collaborative operation. The relevant technologies mainly exhibit the following characteristics: Complex environment deployment: Testing environments require the pre-configuration of a large amount of hardware resources and testing platforms, and there is a lack of effective isolation between different testing environments, leading to resource conflicts, inaccurate test results, and difficulty in comprehensively verifying hardware compatibility; Non-automated testing processes: Test tasks typically require manual scheduling, making fully automated testing impossible, and data collection and anomaly handling also heavily rely on manual analysis; Lack of real-time monitoring and data feedback: During testing, hardware status monitoring and data collection lack real-time performance and granularity, focusing primarily on single performance indicators, failing to achieve multi-angle data collection and dynamic analysis, resulting in insufficiently detailed test reports and inability to promptly report hardware compatibility anomalies; Poor scalability: Most testing processes are fixed, and updates to these processes and hardware environments are not timely, making it difficult to flexibly adjust to new hardware and new requirements. Summary of the Invention

[0003] This application provides server hardware compatibility testing methods and electronic devices to at least address the problems of high maintenance costs and low testing efficiency in related technologies.

[0004] This application provides a server hardware compatibility testing method, including:

[0005] Receive server hardware compatibility test requests;

[0006] Based on the server hardware compatibility test request, the target server node for responding to the server hardware compatibility test request is determined in the container orchestration management system cluster, which includes multiple server nodes.

[0007] Based on the server hardware compatibility test request, determine the server hardware compatibility test task and send the server hardware compatibility test task to the target server node;

[0008] Based on the server hardware compatibility testing task, the target testing tools are determined, and based on the target testing tools, the target container image containing the target testing tools is determined. The container image contains multiple testing tools, and the container image is stored in the container image repository deployed in the container orchestration management system cluster.

[0009] Start the container corresponding to the target container image, execute the test instructions generated by the server hardware compatibility test task in the container, and at the same time, obtain the performance data of the target server hardware. Based on the performance data, identify abnormal events and mark them in the generated test report.

[0010] This application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the following steps of a server hardware compatibility testing method when executing the computer program:

[0011] Receive server hardware compatibility test requests;

[0012] Based on the server hardware compatibility test request, the target server node for responding to the server hardware compatibility test request is determined in the container orchestration management system cluster, which includes multiple server nodes.

[0013] Based on the server hardware compatibility test request, determine the server hardware compatibility test task and send the server hardware compatibility test task to the target server node;

[0014] Based on the server hardware compatibility testing task, the target testing tools are determined, and based on the target testing tools, the target container image containing the target testing tools is determined. The container image contains multiple testing tools, and the container image is stored in the container image repository deployed in the container orchestration management system cluster.

[0015] Start the container corresponding to the target container image, execute the test instructions generated by the server hardware compatibility test task in the container, and at the same time, obtain the performance data of the target server hardware. Based on the performance data, identify abnormal events and mark them in the generated test report.

[0016] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the following steps of a server hardware compatibility testing method:

[0017] Receive server hardware compatibility test requests;

[0018] Based on the server hardware compatibility test request, the target server node for responding to the server hardware compatibility test request is determined in the container orchestration management system cluster, which includes multiple server nodes.

[0019] Based on the server hardware compatibility test request, determine the server hardware compatibility test task and send the server hardware compatibility test task to the target server node;

[0020] Based on the server hardware compatibility testing task, the target testing tools are determined, and based on the target testing tools, the target container image containing the target testing tools is determined. The container image contains multiple testing tools, and the container image is stored in the container image repository deployed in the container orchestration management system cluster.

[0021] Start the container corresponding to the target container image, execute the test instructions generated by the server hardware compatibility test task in the container, and at the same time, obtain the performance data of the target server hardware. Based on the performance data, identify abnormal events and mark them in the generated test report.

[0022] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the following steps of a server hardware compatibility testing method:

[0023] Receive server hardware compatibility test requests;

[0024] Based on the server hardware compatibility test request, the target server node for responding to the server hardware compatibility test request is determined in the container orchestration management system cluster, which includes multiple server nodes.

[0025] Based on the server hardware compatibility test request, determine the server hardware compatibility test task and send the server hardware compatibility test task to the target server node;

[0026] Based on the server hardware compatibility testing task, the target testing tools are determined, and based on the target testing tools, the target container image containing the target testing tools is determined. The container image contains multiple testing tools, and the container image is stored in the container image repository deployed in the container orchestration management system cluster.

[0027] Start the container corresponding to the target container image, execute the test instructions generated by the server hardware compatibility test task in the container, and at the same time, obtain the performance data of the target server hardware. Based on the performance data, identify abnormal events and mark them in the generated test report.

[0028] This application uses container technology to test hardware compatibility, enabling rapid deployment and efficient isolation of the test environment, avoiding interference between test threads, improving the utilization of server hardware resources through dynamic task scheduling and resource allocation, identifying abnormal events during testing through real-time data collection and intelligent analysis, and ensuring the continuous and stable execution of test tasks through an abnormal event handling mechanism. This reduces the cost of manual intervention and maintenance difficulty, and improves the efficiency and accuracy of compatibility testing. Attached Figure Description

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

[0030] Figure 1 This application provides an application environment diagram for a server hardware compatibility testing method according to an embodiment of the present application.

[0031] Figure 2 This application provides an overall flowchart of a server hardware compatibility testing method.

[0032] Figure 3 This is a schematic diagram illustrating the construction of the test environment provided in the embodiments of this application;

[0033] Figure 4 This is a schematic diagram illustrating the deployment of various services under a microservice architecture provided in the embodiments of this application;

[0034] Figure 5 This is a diagram of the internal structure of an electronic device in one embodiment. Detailed Implementation

[0035] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0036] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus 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 apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0037] It should be noted that the terms "S1," "S2," etc., are used only for descriptive purposes and do not specifically refer to the order or sequence, nor are they intended to limit this application. They are merely for the convenience of describing the method of this application and should not be construed as indicating the sequential order of the steps. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0038] Server compatibility testing primarily focuses on system stability, performance metrics, and verification of individual hardware functions. However, in actual use, complex compatibility issues exist between various hardware components. For example, CPUs (Central Processing Units), memory, storage, network cards, and other peripherals exhibit varying performance under different workloads and environments. Furthermore, as the background technology indicates, related testing methods often rely on dedicated hardware testing platforms, independent testing software, and manual intervention. This results in long test environment construction cycles, low resource utilization, high costs, and difficulty in responding to hardware changes and upgrades in real time, significantly impacting testing efficiency. To address these issues, related technologies employ virtualization and container technologies to build flexible testing platforms. Containerized deployment enables rapid construction and isolation of test environments, reducing the difficulty of setting up testing environments. However, these systems are often single-scenario testing solutions, failing to comprehensively cover the compatibility testing needs of various hardware components in x86 general-purpose servers. They also fail to form an automated, data-driven testing loop and suffer from insufficient environment isolation, incomplete test data, and high maintenance and upgrade costs.

[0039] To address the aforementioned technical issues, this application provides a server hardware compatibility testing method and electronic device. By utilizing container technology to test hardware compatibility, it enables rapid deployment and efficient isolation of the testing environment, avoiding interference between test threads. Through dynamic task scheduling and resource allocation, it improves the utilization rate of server hardware resources. Real-time data acquisition and intelligent analysis identify abnormal events during the testing process, and an abnormal event handling mechanism ensures the continuous and stable execution of test tasks, reducing manual intervention costs and maintenance difficulty, and improving the efficiency and accuracy of compatibility testing.

[0040] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0041] The server hardware compatibility testing method provided in this application can be applied to, for example... Figure 1In the application environment shown, terminal 102 communicates with a data processing platform set on server 104 via a network. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. Server 104 can be implemented as a standalone server or a server cluster consisting of multiple servers.

[0042] like Figure 2 As shown, embodiments of this application provide a server hardware compatibility testing method, which is applied to... Figure 1 Taking the terminal in the example, the explanation includes the following steps:

[0043] S1: Receive server hardware compatibility test requests.

[0044] It should be noted that server hardware refers to all physical components that make up a physical server, such as CPU (Central Processing Unit), memory, storage, and network interfaces. A server hardware compatibility test request refers to a request to verify the working ability of specific hardware components added, replaced, or upgraded in the server, as well as their combination with other existing hardware, drivers, firmware, and operating systems in the system. This is to conduct isolated tests on various hardware components of the server, such as whether there are compatibility issues between the CPU and hardware such as memory, expansion cards, and motherboard chipsets under high load and long-term operating pressure.

[0045] S2: Based on the server hardware compatibility test request, determine the target server node in the container orchestration management system cluster to respond to the server hardware compatibility test request. The container orchestration management system cluster includes multiple server nodes.

[0046] It should be noted that the container orchestration management system cluster refers to the Kubernetes cluster. The Kubernetes cluster consists of multiple Node nodes, which are server nodes.

[0047] S3: Based on the server hardware compatibility test request, determine the server hardware compatibility test task and send the server hardware compatibility test task to the target server node.

[0048] It should be noted that a server hardware compatibility test task refers to a specific, automated test execution unit designed to test whether a particular hardware component can work properly in a server system. This is the container orchestration management system task list file, which may include test objectives, test parameters, etc. The target server node refers to the optimal server node selected for testing through screening.

[0049] S4: Based on the server hardware compatibility testing task, determine the target testing tool, and based on the target testing tool, determine the target container image containing the target testing tool. The container image contains multiple testing tools, and the container image is stored in the container image repository deployed in the container orchestration management system cluster.

[0050] It should be noted that testing tools are specialized software or programs used to verify, evaluate, or measure the performance, functionality, stability, and compatibility of hardware, software, or a combination thereof. These tools are command-line or graphical tools capable of directly interacting with hardware, applying workloads, or querying its status. Examples include CPU stress testing (stress-ng, Linpack), memory testing (memtester, Stream), storage performance testing (fio (Flexible I / O Tester)), network performance testing (iperf3), and hardware information and monitoring (lm-sensors for temperature monitoring, smartmontools for SMART data reading from hard drives). A container image refers to a Docker image, a lightweight, executable, standalone software package containing all the necessary components for running software, such as code, runtime environment, system tools, system libraries, and settings. In this application, a container image can refer to a test image containing multiple testing tools. A container image repository refers to a service system used to store and manage Docker images required for testing, such as Harbor.

[0051] S5: Start the container corresponding to the target container image, execute the test instructions generated by the server hardware compatibility test task in the container, and at the same time, obtain the performance data of the target server hardware, identify abnormal events based on the performance data, and mark them in the generated test report.

[0052] It should be noted that server hardware performance data refers to key indicators used to quantitatively evaluate the working status and efficiency of each hardware component, such as CPU utilization, memory usage, disk I / O, network traffic, temperature, etc. Abnormal events include events such as test containers crashing due to internal software errors and tasks continuously failing due to hardware failures of specific nodes.

[0053] In the above implementation, testing hardware compatibility based on container technology enables rapid deployment and efficient isolation of the test environment, avoids mutual interference between test threads, improves the utilization rate of server hardware resources through dynamic task scheduling and resource allocation, identifies abnormal events during the test through real-time data collection and intelligent analysis, and ensures the continuous and stable execution of test tasks through an abnormal event handling mechanism, reducing the cost of manual intervention and maintenance difficulty, and improving the efficiency and accuracy of compatibility testing.

[0054] In some specific implementations, the method includes the following steps before receiving a server hardware compatibility test request:

[0055] The process involves defining a server group and deploying a container orchestration management system cluster on it. The server group comprises multiple servers; the server group refers to a general-purpose x86 server group, and the container orchestration management system cluster refers to a Kubernetes cluster. This means deploying a standard Kubernetes cluster on a group of general-purpose x86 servers to achieve environment initialization. Specifically, each server in the server group is treated as a Node node with the kubelet service installed. After environment initialization, the Linux kernel's namespaces and cgroups features, combined with Kubernetes' resource management mechanisms, are used to achieve environment isolation and resource allocation. This allows for isolated testing of various server hardware components (such as CPU, memory, storage, and network interfaces). Figure 3 As shown, hardware interface mapping and isolation are specifically as follows:

[0056] CPU: By using CPU Manager for Kubernetes, specific CPU cores are exclusively allocated to test containers, achieving CPU pinning and preventing performance fluctuations caused by CPU context switching in test tasks.

[0057] Memory / Storage: In the container's configuration file (Pod Spec), the available memory and temporary storage space are precisely limited through the resources.limits and resources.requests fields;

[0058] PCIe / I / O devices: For hardware that requires direct access, such as specific network cards, RAID (Redundant Array of Independent Disks) cards, or GPUs, the Kubernetes Device Plugin framework is used to develop or deploy corresponding Device Plugins for specific devices (such as Mellanox network cards and NVIDIA GPUs). This plugin reports the available device resources on the node to the kubelet. When scheduling Pods, the scheduler can schedule them to the node that has the device based on the Pod's (container application's) need for a specific device, and complete the mounting of the device to the container to achieve high-precision hardware testing.

[0059] Storage devices: For storage I / O testing, physical disks or logical volumes (such as / dev / sdb) on the server can be directly mapped into the test container via hostPath volumes or local persistent volumes, allowing tools such as fio to perform read and write tests;

[0060] Build a container image containing multiple testing tools and store the container image in a container image repository. The container image repository is deployed on a container orchestration management system cluster. Specifically, the container image is a standardized Docker base image that contains a lightweight operating system (such as Alpine Linux), necessary drivers, and a comprehensive testing toolkit.

[0061] In some specific implementations, building a container image that includes multiple testing tools includes:

[0062] Determine the standardized base image, i.e., the Docker base image;

[0063] The package management tool is used to install multiple testing tools in a standardized base image. The package management tool is a system tool in the operating system or programming environment used to automate the installation, upgrade, configuration and uninstallation of software packages.

[0064] Upon completion of installation, an aggregated test image is built based on a standardized base image containing multiple test tools. An aggregated test image is defined as a container image containing multiple test tools. In this context, an aggregated test image refers to a single container image that pre-integrates and encapsulates various different test tools, libraries, and their dependencies.

[0065] In the above implementation, building a test environment and configuring containers based on container technology can achieve precise isolation and rapid provisioning of hardware resources, effective isolation between various test tasks, avoid test errors caused by system interference, shorten the deployment cycle and improve test efficiency through standardized images and dynamic resource scheduling, as well as pre-built test tools and automated configuration within the containers.

[0066] In some specific implementations, the target server node determined in the container orchestration management system cluster to respond to the server hardware compatibility test request includes:

[0067] The server hardware compatibility test request is parsed to obtain the parsing result. The parsing result includes at least the hardware identifier, which is used to indicate the specific model and type of the hardware, such as a new model of RAID card.

[0068] Based on the hardware identifier, the first set of server nodes in the container orchestration management system cluster is determined by matching, and the node status of the server nodes in the first set of server nodes is obtained. That is, all servers in the first set of server nodes contain the hardware corresponding to the hardware identifier, such as all containing RAID cards. The node status refers to whether they are online.

[0069] Identify the server nodes that are online, and based on these online server nodes, construct a second set of server nodes, which is to select online server nodes from the first set of server nodes.

[0070] Obtain the current load and historical operating parameters of the server nodes in the second set of server nodes. The historical operating parameters are used to describe the operating stability of the server nodes. The current load refers to the amount of computing and I / O pressure that the server node is bearing at a certain moment, which is used to indicate its resource consumption. The historical operating parameters refer to the performance and status data of the server hardware recorded in the past test or operation, such as whether performance jitter, error alarms or abnormal restarts occur frequently, which are used to evaluate the stability and reliability of its long-term performance.

[0071] Based on the current load and historical operating parameters, a comprehensive evaluation value for each server node is determined. Based on this comprehensive evaluation value, the server nodes are prioritized and ranked. The comprehensive evaluation value can be determined using a weighted scoring method. First, the current load and historical operating parameters are normalized. Then, the normalized data is weighted and calculated using the formula K = w1h1 + w2t1 + ... + w n t n-1 Where K represents the comprehensive evaluation value, w1, w2, ..., w n All represent weighting coefficients, h1 represents the current load, t1, ..., t n-1 This represents historical operating parameters. Furthermore, the comprehensive evaluation values ​​of multiple server nodes are sorted in descending order, with higher priority for those sorted earlier and lower priority for those sorted later.

[0072] Based on the sorting results, the server node with the highest priority is defined as the target server node, where the server node here is the one with the highest priority in the sorting results.

[0073] In the above implementation, the test task is executed by selecting the server node with the lowest current load and the most stable historical operation based on the comprehensive evaluation value, so as to ensure that the test environment has sufficient resources and minimal interference, thereby improving the reliability of the test.

[0074] In some specific implementations, the server hardware compatibility testing task, based on the server hardware compatibility testing request, includes:

[0075] The server hardware compatibility test request is parsed to obtain the parsing result. The parsing result includes at least the hardware identifier, test type, and test parameters. The hardware identifier can be a node name, device ID, etc. The test type refers to the classification of hardware compatibility tests according to different test objectives. It defines the specific direction of the test, the tools, methods, and evaluation criteria used, such as memory full load compatibility test. The test parameters refer to the configurable variables that need to be set in advance to execute a specific test type. They define the specific behavior, scale, intensity, and time of the test task. The test parameters can include read / write mode (such as sequential read, random write), block size (such as 4KB, 1MB), queue depth, test duration, and number of concurrent threads.

[0076] Based on the test type, select the corresponding target template from the preset task template library. The target template is a YAML format Kubernetes Job or Pod manifest file, etc.

[0077] The test parameters are populated into the corresponding variables of the selected target template, and a server node scheduling constraint mechanism is added to the target template according to the hardware identifier and the target server node to generate a container orchestration management system task list file. The server node scheduling constraint mechanism refers to the user-defined rules used to restrict or guide the Kubernetes scheduler's decision-making process of allocating Pods to specific Node nodes, such as the target server node determined according to the hardware identifier.

[0078] Define the container orchestration management system task manifest file as a server hardware compatibility test task.

[0079] Specifically, test tasks exist in the form of templates, usually Kubernetes Job or Pod manifest files in YAML format. Through an API or web interface provided by the system, users can select the test type (such as "memory full load compatibility test") and fill in parameters such as target hardware, test duration, and concurrency. Based on the user input, a specific Job manifest file is dynamically generated from the template.

[0080] In the above implementation, by transforming test requirements into parameterized standard templates, the rapid, batch, and consistent automatic generation of test tasks is achieved. Based on this, the error rate and cost of manually writing tasks are reduced, the standardization and repeatability of the test process are ensured, and the flexible configuration capability of the templates supports diverse test scenarios, thereby improving test efficiency and system maintainability.

[0081] In some specific implementations, based on the server hardware compatibility testing task, a target testing tool is determined, and based on the target testing tool, a target container image containing the target testing tool is determined, including:

[0082] Based on the test type and hardware identifier in the server hardware compatibility test task, the test objectives are determined, wherein the test objectives are composed of the test type and hardware identifier;

[0083] Based on the test objectives and the mapping relationship between the test objectives and the test tools, the initial test tools and their identifiers are determined. The mapping relationship between the test objectives and the test tools is pre-stored in the database.

[0084] Based on the identifier of the initial test tool, select the matching initial container image containing the initial test tool from the container image repository. That is, select industry standard or recognized effective test tools based on the identifier of the test tool. These tools must be able to produce the required key performance indicators or trigger specific hardware behaviors.

[0085] Perform availability verification on the initial testing tools and initial container image, that is, verify whether the image can run correctly on the target server and whether the tools can correctly identify and test the hardware;

[0086] Since both the initial testing tool and the initial container image have been successfully verified, the initial testing tool is defined as the target testing tool, and the initial container image is defined as the target container image.

[0087] Furthermore, by executing `kubectl apply -f`<job-manifest.yaml> The command submits the server hardware compatibility test task to the Kubernetes API Server. The Kubernetes scheduler schedules the test Pod to the most suitable Node for execution based on the resource requirements defined in the manifest file, the node affinity rules (to ensure that the task runs on the server with the specified hardware), and the device plugin requirements.

[0088] In the above implementation, the target testing tool is accurately determined according to the testing task, and the target container image containing the tool is selected accordingly. This achieves a precise match between the testing environment and the requirements. This method ensures the usability and version consistency of the testing tool, avoids environment configuration errors, and improves the accuracy of the test. At the same time, containerized encapsulation makes the testing process standardized and portable, improves testing efficiency, and reduces maintenance costs.

[0089] In some specific implementations, starting the container corresponding to the target container image and executing the test instructions generated based on the server hardware compatibility test task within the container includes:

[0090] Create a container on the target server node based on the target container image;

[0091] Start the container and execute the test instructions generated based on the server hardware compatibility test task within the container.

[0092] Specifically, the kubelet pulls the specified test image on the target Node and starts the container. After the container starts, it executes the startup command (command or args) defined in the manifest file. For example, command: ["fio","--filename= / dev / sdb","--rw=randwrite","--bs=4k","--runtime=3600", "--time_based"] will perform a 4KB random write stress test on the / dev / sdb device mapped to the container for 1 hour.

[0093] In the above implementation, by starting the container corresponding to the target container image and executing the instructions generated based on the test task, the rapid deployment, strict isolation, and high consistency of the test environment are achieved. Containerization ensures that the test process is not interfered with by other tasks, thus guaranteeing the accuracy and reliability of the results.

[0094] In some specific implementations, the performance data of the target server hardware is obtained, and based on the performance data, abnormal events are identified and marked in the generated test report, including:

[0095] Collect performance data of the target server hardware. This performance data refers to physical hardware metrics such as CPU utilization, memory usage, disk I / O, network traffic, and temperature.

[0096] The performance data is correlated with the metadata of server hardware compatibility test tasks, and the correlated data is preprocessed to obtain target performance data. The correlation process includes: first, generating a unique identifier (such as task ID) for each test task and injecting this identifier into all relevant performance metrics during data acquisition; then, during the data storage stage, real-time collected performance data (such as CPU utilization) is correlated and matched with task metadata (such as test type, target hardware model, and test parameters) using timestamps and task identifiers, thereby forming a complete and traceable test data record, providing a structured data foundation for subsequent analysis and report generation. The preprocessing process includes: first, cleaning the raw data and handling missing values ​​and outliers; then, aligning and concatenating the performance metrics and task metadata according to timestamps and task IDs; then, standardizing or normalizing the numerical data to eliminate the influence of units; finally, extracting key features (such as mean, peak value, and variance) and constructing a structured dataset suitable for analysis and modeling.

[0097] Based on threshold analysis mechanisms and / or anomaly analysis models, target performance data is analyzed to determine whether any abnormal events exist. Threshold analysis mechanisms refer to setting corresponding indicator thresholds to determine the presence of abnormal events, such as a hardware temperature threshold of 95 degrees Celsius. Anomaly analysis models involve processing historical data extracted from the Spark MLlib library to pre-train a defined anomaly detection model based on IsolationForest or LSTM (Long Short-Term Memory) to identify subtle performance degradation or irregular fluctuations in hardware under normal stress. The trained model is deployed as an online service that consumes monitoring data streams in real time, predicts the hardware's "health score" under the current load, or provides early warnings of potential compatibility issues (e.g., predicting a high probability of speed drops for a certain SSD model after 48 hours of continuous writing). Based on this, the presence of abnormal events can be determined.

[0098] The selection methods for threshold analysis mechanisms and anomaly analysis models include:

[0099] Receive real-time collected server hardware target performance data;

[0100] Based on the target performance data, determine whether the features of the anomaly to be detected are known quantifiable faults. Known quantifiable faults are those where one or more indicators clearly and stably exceed (or fall below) a certain definable threshold, such as CPU temperature exceeding 95°C alarms, hard disk SMART error count greater than 0, network packet loss rate exceeding 5%, etc. Unknown quantifiable faults refer to anomalies where there is no clear threshold definition, or they manifest as anomalies in combination of multiple indicators, trend decay, or periodic fluctuations, such as hard disk performance exhibiting regular jitter under specific loads, or performance slowing down due to memory leaks, etc.

[0101] In response to the characteristic of the anomaly to be detected being a known and quantifiable fault, a threshold analysis mechanism is selected to compare the target performance data with a preset threshold to determine whether an abnormal event exists. The preset threshold can be set according to actual needs.

[0102] If the characteristics of the anomaly to be detected are not known and quantifiable faults, then an anomaly analysis model is selected, the target performance data is input into the anomaly analysis model, and the existence of an anomaly event is determined based on the output result, i.e., the anomaly score.

[0103] Based on this, by providing optional strategies of threshold analysis and machine learning analysis, the flexibility and accuracy of anomaly detection are achieved. The threshold analysis mechanism can provide millisecond-level real-time response to known and serious hardware failures, ensuring the immediate security of testing. Meanwhile, the machine learning model can uncover deep patterns in historical data, effectively identifying hidden performance degradation and complex anomaly patterns that the threshold analysis mechanism cannot detect, thus achieving predictive maintenance. The combination of the two improves the automation level and reliability of hardware compatibility testing.

[0104] In response to the presence of an abnormal event, log the abnormal event;

[0105] In response to the completion of the server hardware compatibility test task, a test report is generated, and abnormal events are marked in the test report.

[0106] Specifically, Prometheus is used as the core monitoring solution. The Prometheus Operator is deployed in the Kubernetes cluster to simplify deployment and management. On each Node, a node-exporter is deployed as a DaemonSet to collect the server's physical hardware metrics (CPU utilization, memory usage, disk I / O, network traffic, temperature, etc.). The Kubernetes built-in cAdvisor component automatically collects the resource usage of each container. The Prometheus server automatically captures all the metric data exposed by the Exporter and cAdvisor through the service discovery mechanism, and the collected time-series data is stored in the Prometheus TSDB database. Simultaneously, configure Alertmanager and define alarm rules. For example, when node_hwmon_temp_celsius is greater than 95 (i.e., hardware temperature exceeds 95 degrees Celsius) or container_memory_usage_bytes / container_spec_memory_limit_bytes is greater than 0.98 (container memory usage is close to the limit), an alarm can be automatically triggered. Alternatively, a trained model can monitor the data stream in real time to predict the hardware's "health score" under the current load. When the health score is lower than a preset value, an alert is issued, along with early warnings of potential compatibility issues. After the test job is completed, a separate "report generation service" (which can be used as another Kubernetes Pod) is triggered. This service queries all relevant metric data within the test time window through the Prometheus API (PromQL) and combines it with abnormal events obtained from the logging module to automatically generate an HTML or PDF report containing data charts, KPI statistics, anomaly records, and test conclusions (Pass / Fail).

[0107] In the above implementation, by automatically acquiring and analyzing the performance data of the target server hardware, abnormal events (such as sudden performance drops and excessive temperature) can be accurately identified, and these abnormalities can be automatically marked in the test report. This significantly improves the accuracy and reliability of the test results, provides a direct and reliable basis for quickly diagnosing hardware compatibility issues, and greatly reduces the cost of manual troubleshooting and the risk of misjudgment.

[0108] In some specific embodiments, the method further includes:

[0109] In response to the presence of an abnormal event, determine the event type of the abnormal event;

[0110] In response to an event type of software failure, the container is recreated to continue the server hardware compatibility testing task.

[0111] In response to an event type of hardware failure, the server hardware compatibility test task is rescheduled to another server node to continue executing the server hardware compatibility test task.

[0112] Specifically, Alertmanager analyzes the metric data stream in real time according to preset rules. Once an anomaly is detected, it notifies the administrator via email, Slack, etc., and determines the event type of the anomaly. Based on the event type, it determines the corresponding self-healing strategy, specifically: Container-level self-healing: If the test container crashes due to an internal software error, the Kubernetes Job controller will attempt to recreate the Pod according to its restartPolicy to continue executing the task; Task-level self-healing: If a task continues to fail due to a hardware failure of a specific Node, the test scheduling module, after receiving multiple failure alerts, can reschedule the task to a standby node for retry and mark the original Node as requiring manual inspection.

[0113] Specifically, such as Figure 4As shown, this application breaks down the original monolithic scheduling and analysis module into multiple independent microservices, each running in its own Pod. Examples include: APIService (responsible for receiving requests), SchedulingService (responsible for task scheduling), DataAnalysisService (responsible for data analysis), and ReportService (responsible for report generation). APIService provides a standardized RESTful API and is documented using the Swagger / OpenAPI specification, enabling seamless integration of the test system into CI / CD processes (such as Jenkins and GitLab CI) to automate testing after hardware changes. The communication mechanisms employed include synchronous and asynchronous communication. Synchronous communication involves direct calls between services via a lightweight RESTful API; for example, SchedulingService calls Kubernetes. API; Asynchronous Communication: Introducing message queues (such as RabbitMQ or Kafka). For example, after the test is completed, the execution container publishes a "TestCompleted" message. ReportService and DataAnalysisService subscribe to this message and asynchronously execute subsequent work, which can improve the system's responsiveness and robustness. After the test is completed, the historical test data accumulated in Prometheus is periodically exported to a big data storage system (such as HDFS or cloud storage S3), and the test progress and test results are displayed through a data visualization platform. Data visualization platform: Deploy Grafana and configure it to pull data from Prometheus (for real-time data) and the big data platform (for historical trends and prediction results). Create multiple customized dashboards (visual interfaces integrating key information) to intuitively display the real-time health status of the server cluster, test task progress, hardware performance KPIs (key performance indicators), and intelligent analysis prediction results in the form of charts, providing technical personnel with one-stop monitoring and decision support.

[0114] Furthermore, this application illustrates the above process using a complete end-to-end example, specifically: Hardware entry and test planning: Upon receiving a new RAID card, the system's web interface is used to enter the card's model, manufacturer, firmware version, and other information in the "Hardware Asset Library." Subsequently, the "Storage Controller Standard Certification Test Set" is selected from the "Test Plan Template Library." This test set contains a series of predefined test tasks, such as: large file sequential read / write performance test, 4K random read / write stress test, RAID 5 / 6 degradation and reconstruction performance test, etc.; Automated scheduling and execution: Clicking "Start Test" generates a test request. Upon receiving the test request, a weighted scoring algorithm is initiated to filter all server nodes in the Kubernetes cluster that have the new RAID card installed (reported via Device Plugin) and are online. After calculation, a node with the lowest current load and the most stable historical operation is selected, and a series of Kubernetes Job lists are dynamically generated and implemented via API. The server dispatches these tasks sequentially or in parallel to the target server nodes. Once the test begins, the kubelet starts a test container containing tools such as fio on that node. The fio within the container begins reading and writing to the logical disks created by the RAID card. Simultaneously, the Grafana "Real-time Test Monitoring" dashboard clearly displays the RAID card's real-time IOPS, throughput, average / maximum latency curves, and the server node's CPU temperature and power consumption changes. During the third hour of the high-intensity 4K random write test, the intelligent anomaly detection model's output score began to climb continuously, eventually exceeding the alarm threshold. The system immediately triggered the anomaly correlation process, discovering that the RAID card driver was outputting a large number of "firmware lock contention" errors in the system logs. Upon receiving the "detected" warning message, Alertmanager immediately sent an alert to the engineer via email and instant messaging: "Potential performance bottleneck: High latency jitter detected under 4K random write load, suspected to be related to firmware lock contention." After the entire test suite was completed, the report generation service was automatically triggered. It pulled all performance indicator charts from Prometheus, extracted all relevant warnings and errors from the log system, summarized the final results of the fio test, and attached the conclusions of the intelligent analysis module. It automatically generated a PDF test report and sent it to the user's client. The report conclusion was: "The basic functions of this RAID card passed, but there is a firmware performance bottleneck under high-concurrency random write scenarios. Firmware optimization is recommended." At the same time, all data and conclusions of this test were archived to the historical database to provide a more accurate performance baseline for future testing of this model or other RAID card models.

[0115] In the above embodiments, this application integrates real-time monitoring, multi-level alarms and automatic response strategies, which can detect hardware performance anomalies and container failures in real time and automatically trigger alarm notifications. Through self-healing mechanisms such as Pod restart and task rescheduling, it can effectively deal with software and hardware anomalies, ensure the continuous execution of test tasks, and greatly reduce the need for manual intervention. At the same time, by accurately marking faulty nodes and guiding repair, it improves testing efficiency and reliability.

[0116] The aforementioned server hardware compatibility testing method includes: receiving a server hardware compatibility test request; determining a target server node in a container orchestration management system cluster (including multiple server nodes) to respond to the server hardware compatibility test request; determining a server hardware compatibility test task based on the server hardware compatibility test request and sending the server hardware compatibility test task to the target server node; determining a target testing tool based on the server hardware compatibility test task, and determining a target container image containing the target testing tool based on the target testing tool, wherein the container image includes multiple testing tools, and the container image is stored in a container image repository deployed in the container orchestration management system cluster; starting the container corresponding to the target container image, executing test instructions generated based on the server hardware compatibility test task in the container, and simultaneously acquiring performance data of the target server hardware; and determining the target server hardware based on the performance data. This application uses container technology for hardware compatibility testing, enabling rapid deployment and efficient isolation of the test environment, avoiding interference between test threads. Dynamic task scheduling and resource allocation improve server hardware resource utilization. Real-time data acquisition and intelligent analysis identify abnormal events during testing, and an abnormal event handling mechanism ensures continuous and stable execution of test tasks, reducing manual intervention costs and maintenance difficulty, and improving the efficiency and accuracy of compatibility testing. Furthermore, to ensure the security and stability of the test environment and prevent mutual interference between test tasks or damage to the host system, this application implements multi-layered security mechanisms, such as network isolation: utilizing Kubernetes' NetworkPolicy resource object to implement strict network access control. By default, the network policy for all test namespaces is "default deny". Deny: Only explicitly defined policies are allowed. For example, allowing a web server test container to receive traffic from the load generator container on port 80 can effectively prevent malicious or misconfigured test programs from scanning the internal network or attacking other services. Computational resource limits: Through ResourceQuota and LimitRange objects, the total quota of computational resources and the maximum resource usage of a single container can be set for each test project or namespace. This ensures that even if a single test task has a memory leak or CPU deadlock bug, it will not exhaust the resources of the entire cluster, thus guaranteeing the overall availability of the platform.Permissions and Capability Restrictions: Adopting Kubernetes Pod Security Standards (PSS), all test containers run under either the Baseline or Restricted policy by default. Based on this, containers run as a non-root user by default (runAsNonRoot: true), privileged mode requests are prohibited (privileged: false), the host paths that containers can mount are restricted, allowing access only to pre-approved devices or directories, and system calls (syscalls) that containers can perform are restricted through seccomp configuration files, further reducing their attack surface.

[0117] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0118] It should be understood that, although Figures 2-4 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order in which these steps are executed, and they can be performed in other orders. Furthermore, Figures 2-4 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0119] In one embodiment, an electronic device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 5As shown, the electronic device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage medium. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a server hardware compatibility testing method. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the device's casing, or an external keyboard, touchpad, or mouse.

[0120] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0121] Embodiments of this application provide an electronic device, including a memory and a processor. The memory stores a computer program, and the processor is configured to run the computer program to perform the steps in the server hardware compatibility testing method embodiments, including:

[0122] S1: Receive server hardware compatibility test requests;

[0123] S2: Based on the server hardware compatibility test request, determine the target server node in the container orchestration management system cluster to respond to the server hardware compatibility test request. The container orchestration management system cluster includes multiple server nodes.

[0124] S3: Based on the server hardware compatibility test request, determine the server hardware compatibility test task and send the server hardware compatibility test task to the target server node;

[0125] S4: Based on the server hardware compatibility test task, determine the target test tool, and based on the target test tool, determine the target container image containing the target test tool. The container image contains multiple test tools, and the container image is stored in the container image repository deployed in the container orchestration management system cluster.

[0126] S5: Start the container corresponding to the target container image, execute the test instructions generated by the server hardware compatibility test task in the container, and at the same time, obtain the performance data of the target server hardware, identify abnormal events based on the performance data, and mark them in the generated test report.

[0127] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in the server hardware compatibility testing method embodiments at runtime, including:

[0128] S1: Receive server hardware compatibility test requests;

[0129] S2: Based on the server hardware compatibility test request, determine the target server node in the container orchestration management system cluster to respond to the server hardware compatibility test request. The container orchestration management system cluster includes multiple server nodes.

[0130] S3: Based on the server hardware compatibility test request, determine the server hardware compatibility test task and send the server hardware compatibility test task to the target server node;

[0131] S4: Based on the server hardware compatibility test task, determine the target test tool, and based on the target test tool, determine the target container image containing the target test tool. The container image contains multiple test tools, and the container image is stored in the container image repository deployed in the container orchestration management system cluster.

[0132] S5: Start the container corresponding to the target container image, execute the test instructions generated by the server hardware compatibility test task in the container, and at the same time, obtain the performance data of the target server hardware, identify abnormal events based on the performance data, and mark them in the generated test report.

[0133] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0134] Embodiments of this application also provide a computer program product, which includes a computer program. When executed by a processor, the computer program implements the steps in the server hardware compatibility testing method embodiment, including:

[0135] S1: Receive server hardware compatibility test requests;

[0136] S2: Based on the server hardware compatibility test request, determine the target server node in the container orchestration management system cluster to respond to the server hardware compatibility test request. The container orchestration management system cluster includes multiple server nodes.

[0137] S3: Based on the server hardware compatibility test request, determine the server hardware compatibility test task and send the server hardware compatibility test task to the target server node;

[0138] S4: Based on the server hardware compatibility test task, determine the target test tool, and based on the target test tool, determine the target container image containing the target test tool. The container image contains multiple test tools, and the container image is stored in the container image repository deployed in the container orchestration management system cluster.

[0139] S5: Start the container corresponding to the target container image, execute the test instructions generated by the server hardware compatibility test task in the container, and at the same time, obtain the performance data of the target server hardware, identify abnormal events based on the performance data, and mark them in the generated test report.

[0140] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the steps in the server hardware compatibility testing method embodiments, including:

[0141] S1: Receive server hardware compatibility test requests;

[0142] S2: Based on the server hardware compatibility test request, determine the target server node in the container orchestration management system cluster to respond to the server hardware compatibility test request. The container orchestration management system cluster includes multiple server nodes.

[0143] S3: Based on the server hardware compatibility test request, determine the server hardware compatibility test task and send the server hardware compatibility test task to the target server node;

[0144] S4: Based on the server hardware compatibility test task, determine the target test tool, and based on the target test tool, determine the target container image containing the target test tool. The container image contains multiple test tools, and the container image is stored in the container image repository deployed in the container orchestration management system cluster.

[0145] S5: Start the container corresponding to the target container image, execute the test instructions generated by the server hardware compatibility test task in the container, and at the same time, obtain the performance data of the target server hardware, identify abnormal events based on the performance data, and mark them in the generated test report.

[0146] Those skilled in the art will further 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, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. 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 implementation should not be considered beyond the scope of this application.

[0147] The foregoing has provided a detailed description of a server hardware compatibility testing method, apparatus, electronic device, and storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to aid in understanding the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A server hardware compatibility testing method, characterized in that, The method includes: Receive server hardware compatibility test requests; Based on the server hardware compatibility test request, a target server node is determined in the container orchestration management system cluster to respond to the server hardware compatibility test request. The container orchestration management system cluster includes multiple server nodes. Based on the server hardware compatibility test request, a server hardware compatibility test task is determined and the server hardware compatibility test task is sent to the target server node; Based on the server hardware compatibility test task, a target test tool is determined, and based on the target test tool, a target container image containing the target test tool is determined. The container image includes multiple test tools, and the container image is stored in a container image repository deployed in the container orchestration management system cluster. Start the container corresponding to the target container image, execute the test instructions generated based on the server hardware compatibility test task in the container, and at the same time, obtain the performance data of the target server hardware, identify abnormal events based on the performance data, and mark them in the generated test report. Based on the server hardware compatibility test request, the target server nodes identified in the container orchestration and management system cluster for responding to the server hardware compatibility test request include: The server hardware compatibility test request is parsed to obtain a parsing result, which includes at least a hardware identifier. Based on the hardware identifier, the first set of server nodes in the container orchestration management system cluster is determined by matching, and the node status of the server nodes in the first set of server nodes is obtained. Identify the server nodes whose status is online, and construct a second set of server nodes based on the server nodes whose status is online; Obtain the current load and historical operating parameters of the server nodes in the second set of server nodes, wherein the historical operating parameters are used to describe the operating stability of the server nodes; Based on the current load and the historical operating parameters, a comprehensive evaluation value for each server node is determined. Then, based on this comprehensive evaluation value, the server nodes are prioritized to obtain a ranking result. The comprehensive evaluation value is determined using a weighted scoring method, calculated as K = w1h1 + w2t1 + ... + w n t n-1 Where K represents the comprehensive evaluation value, w1, w2, ..., w n All represent weighting coefficients, h1 represents the current load, t1, ..., t n-1 Indicates historical operating parameters; Based on the sorting results, the server node with the highest priority is defined as the target server node; Based on the server hardware compatibility test request, the server hardware compatibility test tasks include: The server hardware compatibility test request is parsed to obtain a parsing result, which includes at least the hardware identifier, test type, and test parameters. Based on the test type, select the corresponding target template from the preset task template library; The test parameters are filled into the corresponding variables of the selected target template, and a server node scheduling constraint mechanism is added to the target template according to the hardware identifier and the target server node to generate a container orchestration management system task list file. Define the container orchestration management system task list file as the server hardware compatibility test task.

2. The server hardware compatibility testing method according to claim 1, characterized in that, Before receiving a server hardware compatibility test request, the method includes: Identify a server group, and deploy a container orchestration and management system cluster on the server group, wherein the server group includes multiple servers; Build a container image containing multiple testing tools, store the container image in a container image repository, and deploy the container image repository in the container orchestration management system cluster.

3. The server hardware compatibility testing method according to claim 2, characterized in that, Building a container image that includes multiple testing tools includes: Determine the standardized base image; The package management tool is invoked to install multiple testing tools in the standardized base image. Upon completion of installation, an aggregated test image is built based on the standardized base image containing the multiple testing tools, and the aggregated test image is defined as the container image containing the multiple testing tools.

4. The server hardware compatibility testing method according to claim 1, characterized in that, Based on the server hardware compatibility testing task, a target testing tool is determined, and based on the target testing tool, a target container image containing the target testing tool is determined, including: Based on the test type and hardware identifier in the server hardware compatibility test task, the test objectives are determined; Based on the test objectives and the mapping relationship between the test objectives and the test tools, the initial test tool and its identifier are determined. Based on the identifier of the initial testing tool, select an initial container image from the container image repository that matches the initial testing tool; The availability of the initial testing tool and the initial container image is verified. In response to the successful verification of both the initial testing tool and the initial container image, the initial testing tool is defined as the target testing tool, and the initial container image is defined as the target container image.

5. The server hardware compatibility testing method according to claim 1, characterized in that, Start the container corresponding to the target container image, and execute the test instructions generated based on the server hardware compatibility test task within the container, including: The container is created on the target server node based on the target container image; Start the container and execute the test instructions generated based on the server hardware compatibility test task within the container.

6. The server hardware compatibility testing method according to claim 1, characterized in that, Obtain performance data of the target server hardware, identify abnormal events based on the performance data, and mark them in the generated test report, including: Collect performance data of the target server hardware; The performance data is correlated with the metadata of the server hardware compatibility test task, and the correlated data is preprocessed to obtain the target performance data. Based on threshold analysis mechanisms and / or anomaly analysis models, the target performance data is analyzed to determine whether any abnormal events exist. In response to the existence of the aforementioned abnormal event, the abnormal event is recorded; In response to the completion of the server hardware compatibility test task, a test report is generated, and the abnormal event is marked in the test report.

7. The server hardware compatibility testing method according to claim 6, characterized in that, The method further includes: In response to the existence of the abnormal event, determine the event type of the abnormal event; In response to the event type being a software failure, the container is recreated to continue executing the server hardware compatibility test task; In response to the event type being hardware failure, the server hardware compatibility test task is rescheduled to another server node to continue executing the server hardware compatibility test task.

8. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the server hardware compatibility testing method as described in any one of claims 1 to 7 when executing the computer program.

Images