Server hardware compatibility test method and electronic equipment

Abstract

The invention discloses a server hardware compatibility testing method and electronic equipment, and relates to the technical field of servers. Hardware compatibility is tested based on a container technology, rapid deployment and efficient isolation of a testing environment can be achieved, mutual interference between testing threads is avoided, and the compatibility of the server hardware is improved through dynamic task scheduling and resource allocation. The utilization rate of server hardware resources is improved, the abnormal events are determined in the test process through real-time data collection and intelligent analysis, continuous and stable execution of the test tasks is guaranteed through an abnormal event processing mechanism, the manual intervention cost and the maintenance difficulty are reduced, and the compatibility test efficiency and accuracy are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of servers, and in particular to a server hardware compatibility testing method and an electronic device. BACKGROUND

[0002] At present, related test platforms construct a test environment by using virtual machine technology to realize testing of server software systems and part of the hardware. Some solutions use container technology to realize application deployment, but there is no systematic solution for the compatibility of underlying hardware components, stress testing and testing of multi-module collaborative work. The related technologies mainly have the following characteristics: complex environment deployment: the test environment needs to be configured with a large number of hardware resources and test platforms in advance, and there is a lack of effective isolation between test environments, which is prone to resource conflicts, inaccurate test results, and difficulty in fully verifying hardware compatibility; non-automated testing process: test tasks usually need to be manually scheduled, and full-process automated testing cannot be realized, and data collection and exception handling also rely more on manual analysis; lack of real-time monitoring and data feedback: during the testing process, the real-time and refinement of hardware state monitoring and data collection are insufficient, and only a single performance indicator is mainly concerned, which cannot realize multi-angle data collection and dynamic analysis, and the test report is not detailed enough, and thus the hardware compatibility exceptions cannot be timely fed back; poor scalability: mostly fixed testing process, and the fixed testing process and hardware environment are not updated in time, and it is difficult to flexibly adjust to new hardware and new needs. SUMMARY

[0003] The present application provides a server hardware compatibility testing method and an electronic device to at least solve the problems of high maintenance cost and low testing efficiency in related technologies.

[0004] The present application provides a server hardware compatibility testing method, which includes: receiving a server hardware compatibility testing request; determining a target server node for responding to the server hardware compatibility testing request in a container orchestration management system cluster according to the server hardware compatibility testing request, the container orchestration management system cluster including a plurality of server nodes; determining a server hardware compatibility testing task based on the server hardware compatibility testing request, and sending the server hardware compatibility testing task to the target server node; determining a target test tool according to the server hardware compatibility testing task, and determining a target container image containing the target test tool based on the target test tool, wherein the container image includes a plurality of test tools, and the container image is stored in a container image warehouse deployed in the container orchestration management system cluster; Start a container corresponding to the target container image, execute the test instruction generated based on the server hardware compatibility test task in the container, at the same time, obtain the performance data of the target server hardware, determine the abnormal event based on the performance data, and mark in the generated test report.

[0005] The application also provides an electronic device, comprising: a memory for storing a computer program; a processor for executing the computer program to implement the following steps of the server hardware compatibility test method: receiving a server hardware compatibility test request; determining a target server node for responding to the server hardware compatibility test request in a container orchestration management system cluster according to the server hardware compatibility test request, the container orchestration management system cluster comprising a plurality of server nodes; 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 test tool according to the server hardware compatibility test task, and determining a target container image containing the target test tool based on the target test tool, wherein the container image comprises a plurality of test tools, and the container image is stored in a container image warehouse deployed in the container orchestration management system cluster; starting a container corresponding to the target container image, executing the test instruction generated based on the server hardware compatibility test task in the container, at the same time, obtaining the performance data of the target server hardware, determining the abnormal event based on the performance data, and marking in the generated test report.

[0006] The application also provides a computer readable storage medium, the computer readable storage medium storing a computer program, wherein the computer program is executed by a processor to implement the following steps of the server hardware compatibility test method: receiving a server hardware compatibility test request; determining a target server node for responding to the server hardware compatibility test request in a container orchestration management system cluster according to the server hardware compatibility test request, the container orchestration management system cluster comprising a plurality of server nodes; 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 test tool according to the server hardware compatibility test task, and determining a target container image containing the target test tool based on the target test tool, wherein the container image comprises a plurality of test tools, and the container image is stored in a container image warehouse deployed in the container orchestration management system cluster; Start the container corresponding to the target container image, execute the test instruction generated based on the server hardware compatibility test task in the container, at the same time, obtain the performance data of the target server hardware, determine the abnormal event based on the performance data, and mark in the generated test report.

[0007] The application further provides a computer program product comprising a computer program, which, when executed by a processor, implements the following steps of the server hardware compatibility test method: receiving a server hardware compatibility test request; determining a target server node for responding to the server hardware compatibility test request in a container orchestration management system cluster according to the server hardware compatibility test request, wherein the container orchestration management system cluster comprises a plurality of server nodes; 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 test tool according to the server hardware compatibility test task, and determining a target container image comprising the target test tool based on the target test tool, wherein the container image comprises a plurality of test tools, and the container image is stored in a container image warehouse deployed in the container orchestration management system cluster; starting a container corresponding to the target container image, executing a test instruction generated based on the server hardware compatibility test task in the container, at the same time, obtaining performance data of the target server hardware, determining an abnormal event based on the performance data, and marking in the generated test report.

[0008] The application tests hardware compatibility based on container technology, can realize rapid deployment and efficient isolation of a test environment, avoids mutual interference between test threads, improves the utilization rate of server hardware resources through dynamic task scheduling and resource allocation, determines an abnormal event in the test process through real-time data acquisition and intelligent analysis, and guarantees continuous and stable execution of a test task through an abnormal event processing mechanism, reduces the cost of manual intervention and maintenance difficulty, and improves compatibility test efficiency and accuracy. BRIEF DESCRIPTION OF DRAWINGS

[0009] In order to more clearly illustrate the embodiments of the application, the drawings needed in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor.

[0010] Figure 1 An application environment diagram of a server hardware compatibility test method is provided for the embodiments of the application; Figure 2 A schematic diagram of the overall flow of a server hardware compatibility test method is provided for an embodiment of the present application. Figure 3 A test environment construction schematic diagram is provided for an embodiment of the present application. Figure 4 A schematic diagram of deployment of each service under a micro-service architecture is provided for an embodiment of the present application. Figure 5 An internal structure diagram of an electronic device in an embodiment. DETAILED DESCRIPTION

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

[0012] It should be noted that, in the description of the present application, the terms “include”, “contain” or any other variant thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. The terms “first”, “second” and the like in the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0013] It should be noted that the terms “S1”, “S2” and the like are only used for the purpose of describing the steps, and do not specifically refer to the order or sequence, nor are they used to limit the present application. They are only used to facilitate the description of the method of the present application, and cannot be understood as indicating the order of the steps. In addition, the technical solutions of each embodiment can be combined with each other, but it must be based on the realization of those of ordinary skill in the art. When the combination of technical solutions contradicts each other or cannot be realized, it should be considered that the combination of technical solutions does not exist, nor is it within the protection scope of the present application.

[0014] The related server compatibility test mainly focuses on system stability, performance indicators and single hardware function verification, but in actual use, there are complex compatibility problems between hardware components, such as CPU (central processing unit), memory, storage, network card and other peripherals, which behave differently under different workloads and environments. At the same time, according to the background art, the related test method often relies on special hardware test platform, independent test software and manual intervention, which leads to long test environment construction period, low resource utilization, high cost, and difficulty in real-time response to hardware changes and upgrade requirements, greatly affecting the test efficiency. In order to solve the above problems, the related technology uses virtualization and container technology to build a flexible test platform, and realizes the rapid construction and isolation of the test environment through containerized deployment, which reduces the difficulty of test environment construction. However, in the related technology, such systems are mostly test solutions for single scenarios, and it is difficult to comprehensively cover the compatibility test requirements of multiple hardware components in x86 general servers. It also fails to form an automated and data-based test closed loop, and it has problems of insufficient environment isolation, incomplete test data and high maintenance and upgrade costs.

[0015] To solve the above technical problems, the server hardware compatibility test method and electronic equipment provided by the present application test hardware compatibility through container technology, which can realize rapid deployment and efficient isolation of the test environment, avoid mutual interference between test threads, improve the utilization rate of server hardware resources through dynamic task scheduling and resource allocation, determine abnormal events during testing through real-time data collection and intelligent analysis, and ensure the continuous and stable execution of test tasks through the abnormal event handling mechanism, reducing the cost and difficulty of manual intervention, improving the compatibility test efficiency and accuracy.

[0016] In order to enable the person skilled in the art to better understand the present application scheme, the present application will be further described in detail below in combination with the drawings and specific embodiments.

[0017] The server hardware compatibility test method provided by the present application can be applied to the application environment as shown in Figure 1 . Among them, the terminal 102 communicates with the data processing platform set on the server 104 through the network, wherein the terminal 102 can be but is not limited to various personal computers, notebook computers, smart phones, tablet computers and portable wearable devices, and the server 104 can be realized by an independent server or a server cluster composed of multiple servers.

[0018] As shown in Figure 2 , the embodiment of the present application provides a server hardware compatibility test method. Taking the terminal in Figure 1 as an example, the method includes the following steps: S1: receiving a server hardware compatibility test request.

[0019] It should be noted that the server hardware refers to all physical components of a server, such as CPU (central processing unit), memory, storage, and network interface, and the server hardware compatibility test request refers to the request for verifying the cooperative working ability of the newly added, replaced, or upgraded specific hardware components in the server and the combination of other existing hardware, drivers, firmware, and operating system in the system, so as to perform isolation test on each hardware component of the server, such as whether there is a compatibility problem between CPU and memory, expansion card, mainboard chipset, and other hardware under high load and long time running pressure.

[0020] S2: According to the server hardware compatibility test request, determine the target server node for responding to the server hardware compatibility test request in the container orchestration management system cluster, and the container orchestration management system cluster includes multiple server nodes.

[0021] It should be noted that the container orchestration management system cluster refers to the Kubernetes cluster, and the Kubernetes cluster is composed of multiple Node nodes, and the Node node refers to the server node, that is, the Kubernetes cluster is composed of multiple server nodes.

[0022] 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.

[0023] It should be noted that the server hardware compatibility test task refers to a specific and automatic test execution unit designed for testing whether a specific hardware component can work normally in the server system, that is, the container orchestration management system task list file, which can include test target and test parameter; The target server node refers to the optimal server node determined by screening for testing.

[0024] S4: According to 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, wherein the container image includes multiple test tools, and the container image is stored in the container image warehouse deployed in the container orchestration management system cluster.

[0025] It should be noted that the test tool is a special software or program for verifying, evaluating or measuring the performance, function, stability and compatibility of hardware, software or their combination, which can directly interact with hardware, and command line or graphical tools that can apply work load or query the state of the hardware, which can include CPU stress test (stress-ng, Linpack), memory test (memtester, Stream), storage performance test (fio (Flexible I / O Tester)), network performance test (iperf3), hardware information and monitoring (lm-sensors for temperature monitoring, smartmontools for hard disk S.M.A.R.T. Data reading) and the like; the container image refers to the Docker image, which is a lightweight, executable independent software package that contains all the contents required for running a certain software, such as code, runtime environment, system tools, system library and settings, etc. In the present application, the container image can refer to the test image, which contains a plurality of test tools; the container image repository refers to a service system for storing and managing the Docker images required for testing, such as Harbor and the like.

[0026] S5: starting the container corresponding to the target container image, executing the test instructions generated based on the server hardware compatibility test task in the container, at the same time, obtaining the performance data of the target server hardware, determining the abnormal event based on the performance data, and marking in the generated test report.

[0027] It should be noted that the performance data of the server hardware refers to the key indicators for quantitatively evaluating the working state and efficiency of each hardware component, such as CPU utilization, memory usage, disk I / O, network traffic, temperature, etc., and the abnormal event includes the crash of the test container due to internal software error and the continuous failure of the task due to the hardware failure of a specific Node and the like.

[0028] In the above embodiment, the hardware compatibility is tested based on the container technology, which can realize the rapid deployment and efficient isolation of the test environment, avoid the mutual interference between the test threads, improve the utilization rate of the server hardware resources through dynamic task scheduling and resource allocation, determine the abnormal event in the test process through real-time data acquisition and intelligent analysis, and guarantee the continuous and stable execution of the test task through the abnormal event processing mechanism, reduce the cost and difficulty of manual intervention, and improve the compatibility test efficiency and accuracy.

[0029] In some specific embodiments, before receiving the server hardware compatibility test request, the method comprises: Determine a server group, deploy a container orchestration management system cluster on the server group, and the server group includes a plurality of servers, wherein the server group refers to an x86 general server group, and the container orchestration management system cluster refers to a Kubernetes cluster, that is, a standard Kubernetes cluster is deployed on a group of x86 general servers to achieve the effect of environment initialization, specifically, each server in the server group is installed as a Node node kubelet service, after initializing the environment, the namespaces and cgroups characteristics of the Linux kernel are used in combination with the resource management mechanism of Kubernetes to realize environment isolation and resource allocation, and then realize the isolation test of each hardware component (such as CPU, memory, storage, network interface, etc.) of the server, such as Figure 3 As shown in the figure, the hardware interface mapping and isolation are specifically as follows: CPU: Through the CPU manager (CPU Manager for Kubernetes), a specific CPU core is allocated to the test container in an exclusive manner to realize CPU Pinning (‌CPU fixed binding) and avoid performance jitter of the test task due to CPU context switching.

[0030] Memory / storage space: In the configuration file (Pod Spec) of the container, the available memory and temporary storage space are accurately limited through the resources.limits and resources.requests fields; PCIe / I / O device: For hardware that needs to be directly accessed, such as a specific network card, RAID (Redundant Array of Independent Disks) card or GPU, the Device Plugin framework of Kubernetes is adopted, a corresponding Device Plugin is developed or deployed for a specific device (such as a Mellanox network card or an NVIDIA GPU), the plugin reports the available device resources on the node to the kubelet, and the scheduler can schedule the Pod (container application) to the node with the device according to the demand of the Pod for the specific device, and complete the mounting of the device to the container to realize high-precision hardware testing; Storage device: For storage I / O testing, a physical disk or logical volume (such as / dev / sdb) on the server can be directly mapped to the test container inside through a hostPath volume or a local persistent volume for read and write testing by tools such as fio; The container image containing the plurality of test tools is constructed, the container image is stored in a container image warehouse, and the container image warehouse is deployed in a container orchestration management system cluster. Specifically, the container image is a standardized Docker base image, the image contains a lightweight operating system (such as Alpine Linux), necessary drivers, and a comprehensive test tool package.

[0031] In some embodiments, constructing the container image containing the plurality of test tools includes: determining a standardized base image, that is, a Docker base image; calling a package management tool to install the plurality of test tools in the standardized base image, wherein the package management tool is a system tool in an operating system or a programming environment for automatically installing, upgrading, configuring, and uninstalling software packages; in response to completion of the installation, constructing an aggregated test image based on the standardized base image in which the plurality of test tools are installed, the aggregated test image being defined as the container image containing the plurality of test tools, wherein the aggregated test image refers to a single container image in which a plurality of different test tools, libraries, and their dependencies are pre-integrated and encapsulated together.

[0032] In the above embodiments, the test environment is constructed based on the container technology and the containers are configured, which can achieve precise isolation and rapid supply of hardware resources, effective isolation between test tasks, avoidance of test errors caused by system interference, shortening of the deployment period and improvement of the test efficiency through standardized images and dynamic resource scheduling, and pre-provisioning of test tools and automatic configuration in the containers.

[0033] In some embodiments, in response to a server hardware compatibility test request, determining a target server node in the container orchestration management system cluster for responding to the server hardware compatibility test request includes: parsing the server hardware compatibility test request to obtain a parsing result, the parsing result at least including a hardware identifier, wherein the hardware identifier is used to represent a specific model and type of the hardware, such as a new model of a RAID card; based on the hardware identifier, matching and determining a first server node set in the container orchestration management system cluster, and obtaining a node state of a server node in the first server node set, that is, the servers in the first server node set all contain the hardware corresponding to the hardware identifier, such as all containing a RAID card, and the node state refers to whether the server is in an online state; determining a server node with an online state, and based on the server node with the online state, constructing a second server node set, that is, screening the server nodes in the online state from the first server node set; obtaining current load and historical running parameters of the server nodes in the second server node set, the historical running parameters being used to describe running stability of the server nodes, wherein the current load refers to the size of the computing and I / O pressure that the server nodes are currently bearing, and is used to represent the implementation resource consumption, and the historical running parameters refer to performance and state data of the server hardware recorded in the past test or running process, such as whether performance jitter, error alarm or abnormal restart frequently occurs, and are used to evaluate the stability and reliability of long-term performance; According to the current load and the historical running parameters, a comprehensive evaluation value of the server nodes is determined, and the server nodes are prioritized based on the comprehensive evaluation value to obtain a sorting result, wherein the comprehensive evaluation value can be determined by a weighted scoring method, first, the current load and the historical running parameters are normalized, and the normalized data is weighted calculated, and the specific calculation formula is K = w1h1 + w2t1 +…+ w n t n-1 , wherein K represents the comprehensive evaluation value, w2, …, w n , h1 all represent weight coefficients, h1 represents the current load, t1, …, t n-1 represent the historical running parameters, further, the comprehensive evaluation values of the plurality of server nodes are sorted in descending order, and the priority of the server nodes at the front of the sorting result is high, and the priority of the server nodes at the back of the sorting result is low. According to the sorting result, the server node with high priority is defined as a target server node, wherein the server node here is the server node with the highest priority in the sorting result.

[0034] In the above embodiment, the server node with the lowest current load and the most stable historical running is selected to execute the test task according to the comprehensive evaluation value, so as to ensure that the test environment has sufficient resources and the interference is minimized, thereby improving the reliability of the test.

[0035] In some specific embodiments, based on the server hardware compatibility test request, the server hardware compatibility test task includes: The server hardware compatibility test request is parsed to obtain a parsing result, and the parsing result at least includes a hardware identifier, a test type and a test parameter, wherein the hardware identifier can be a node name, a device ID, etc., the test type refers to classification of the hardware compatibility test according to different test targets, which defines the specific direction of the test, the tools used, the method and the evaluation standard, such as memory full load compatibility test, etc., and the test parameter refers to a configurable variable that needs to be preset for executing a specific test type, which defines the specific behavior, scale, intensity and time of the test task, etc., and the test parameter can include read-write mode (such as sequential read, random write), block size (such as 4KB, 1MB), queue depth, test duration, number of concurrent threads. According to the test type, a corresponding target template is selected from a preset task template library, wherein the target template is a YAML format Kubernetes Job or Pod manifest file, etc. 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 manifest file, wherein the server node scheduling constraint mechanism refers to a rule defined by the user in advance, which is used to limit or guide the decision-making process of the Kubernetes scheduler to assign the Pod to a specific Node node, such as the target server node determined according to the hardware identifier. The container orchestration management system task manifest file is defined as a server hardware compatibility test task.

[0036] Specifically, the test task exists in the form of a template, which is usually a YAML format Kubernetes Job or Pod manifest file. Through an API or a web interface provided by the system, the user is allowed to select a test type (such as “memory full compatibility test”) and fill in the target hardware, test duration, number of concurrent tests, etc. According to the user input, a specific Job manifest file is dynamically generated from the template.

[0037] In the above embodiments, by converting the test requirements into a parameterized standard template, the rapid, batch and consistent automatic generation of test tasks is realized. Based on this, the error rate and cost of manual task writing are reduced, the standardization and repeatability of the test process are guaranteed, at the same time, the flexible configuration capability of the template supports diversified test scenarios, and the test efficiency and system maintainability are improved.

[0038] In some specific embodiments, according to 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, including: Based on the test type and hardware identifier in the server hardware compatibility test task, a test target is determined, wherein the test target is composed of the test type and the hardware identifier; Based on the test target and the mapping relationship between the test target and the test tool, an initial test tool and an identifier of the initial test tool are determined, wherein the mapping relationship between the test target and the test tool is pre-stored in a database; According to the identifier of the initial test tool, an initial container image containing the initial test tool is selected from a container image repository, that is, according to the identifier of the test tool, an industry standard or a recognized effective test tool is selected. These tools must be able to produce the required key performance indicators or trigger specific hardware behaviors; The initial test tool and the initial container image are verified for availability, i.e., whether the image can correctly run on the target server and whether the tool can normally identify and test the hardware; In response to the initial test tool and the initial container image being successfully verified, the initial test tool is defined as the target test tool, and the initial container image is defined as the target container image.

[0039] Further, by executing the command kubectl apply -f<job-manifest.yaml>, the server hardware compatibility test task is submitted to the Kubernetes API Server, and the Kubernetes scheduler schedules the test Pod to the most suitable Node for execution according to the resource requirements, Node Affinity rules (to ensure that the task runs on the specified hardware server), and device plugin requirements defined in the manifest file.

[0040] In the above embodiments, the target test tool is accurately determined according to the test task, and the target container image containing the tool is selected based on this, which realizes accurate matching of the test environment and requirements, guarantees the usability and version consistency of the test tool, avoids environment configuration errors, improves the accuracy of the test, and at the same time, the encapsulation of the container makes the test process standardized and portable, improves the test efficiency and reduces the maintenance cost.

[0041] In some specific embodiments, the container corresponding to the target container image is started, and the test instructions generated based on the server hardware compatibility test task are executed in the container, including: The container is created based on the target container image on the target server node; The container is started, and the test instructions generated based on the server hardware compatibility test task are executed in the container.

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

[0043] In the above embodiments, by starting the container corresponding to the target container image and executing the instructions generated based on the test task in the container, the rapid deployment, strict isolation and high consistency of the test environment are achieved, the containerization ensures that the test process is not disturbed by other tasks, and the accuracy and reliability of the results are guaranteed.

[0044] In some specific embodiments, the performance data of the target server hardware is acquired, the abnormal event is determined based on the performance data, and the abnormal event is marked in the generated test report, which includes: The performance data of the target server hardware is collected. The performance data refers to physical hardware indicators such as CPU utilization, memory usage, disk I / O, network traffic, temperature, etc. The performance data is associated with the metadata of the server hardware compatibility test task, and the associated data is preprocessed to obtain target performance data. The association processing process includes: first, a unique identifier (such as task ID) is generated for each test task, and the identifier is injected into all related performance indicators during data collection; then, in the data storage stage, the real-time collected performance data (such as CPU utilization) is associated and matched with the task metadata (such as test type, target hardware model, test parameters) through time stamp and task identifier, so as to form complete and traceable test data records, providing a structured data basis for subsequent analysis and report generation. The preprocessing process includes: first, cleaning the original data, processing missing values and outliers; then aligning and splicing the performance indicators with the task metadata according to the time stamp and task ID; then normalizing or normalizing the numerical data to eliminate the influence of dimension; finally, extracting key features (such as mean, peak, variance) and constructing a structured data set suitable for analysis and modeling; The target performance data is analyzed based on a threshold analysis mechanism and / or an abnormal analysis model to determine whether there is an abnormal event. The threshold analysis mechanism refers to setting corresponding indicator thresholds to determine whether there is an abnormal event, such as a hardware temperature threshold of 95 degrees Celsius, etc. The abnormal analysis model refers to processing historical data extracted from the Spark MLlib library to pre-train a determined abnormal detection model based on IsolationForest (Isolation Forest) or LSTM (Long Short Term Memory Network) to identify subtle performance degradation or irregular fluctuations of hardware under normal stress. The trained model is deployed as an online service that consumes real-time monitoring data streams to predict the "health score" of the hardware under current load, or to provide early warning of possible compatibility problems (for example, predicting that a certain model of SSD has a high probability of speed drop after continuous writing for 48 hours). Based on this, it can be determined whether there is an abnormal event. The selection method of the threshold analysis mechanism and the abnormal analysis model includes: receiving real-time collected server hardware target performance data; based on the target performance data, determining whether the feature of the to-be-detected anomaly is a known quantifiable fault, wherein the known quantifiable fault is one or more indicators that explicitly and stably exceed (or are lower than) a certain definable threshold value, such as a CPU temperature exceeding 95°C alarm, a hard disk SMART error count greater than 0, a network packet loss rate exceeding 5%, etc., and the non-known quantifiable fault refers to an abnormal feature without a clear threshold value definition, or an abnormal pattern, a trend attenuation, or a periodic fluctuation represented by a combination of multiple indicators, such as regular jitter of hard disk performance under certain load, performance slow decline caused by memory leakage, etc.; in response to the feature of the to-be-detected anomaly being a known quantifiable fault, selecting a threshold analysis mechanism to compare the target performance data with a preset threshold value to determine whether there is an abnormal event, and the preset threshold value can be set according to actual needs; in response to the feature of the to-be-detected anomaly not being a known quantifiable fault, selecting an anomaly analysis model to input the target performance data into the anomaly analysis model, and determining whether there is an abnormal event according to an output result, i.e., an anomaly score; Based on this, by providing the optional strategies of threshold analysis and machine learning analysis, the flexibility and accuracy of anomaly detection are realized, the threshold analysis mechanism can respond to known and serious hardware faults in milliseconds, which guarantees the instant safety of the test, and the machine learning model can mine deep rules in historical data, effectively identify implicit performance degradation and complex abnormal patterns that cannot be found by the threshold analysis mechanism, realize predictive maintenance, and in combination, improve the automation level and reliability of hardware compatibility testing; in response to the existence of the abnormal event, recording the abnormal event; in response to the completion of the server hardware compatibility test task, generating a test report and marking the abnormal event in the test report.

[0045] Specifically, Prometheus is used as the core monitoring solution. Prometheus Operator is deployed in the Kubernetes cluster to simplify deployment and management. node-exporter is deployed in DaemonSet mode on each Node to collect physical hardware indicators (CPU utilization, memory usage, disk I / O, network traffic, temperature, etc.) of the server. The built-in cAdvisor component of Kubernetes automatically collects resource usage of each container. The Prometheus server automatically captures all the indicator data exposed by the above-mentioned Exporter and cAdvisor through the service discovery mechanism. The collected time series data is stored in the TSDB database of Prometheus. At the same time, Alertmanager is configured, and alarm rules are defined, for example, when node_hwmon_temp_celsius is greater than 95 (i.e., the hardware temperature exceeds 95 degrees Celsius) or container_memory_usage_bytes / container_spec_memory_limit_bytes is greater than 0.98 (the container memory usage is close to the upper limit), an alarm is automatically triggered, or a trained model is used to monitor data streams in real time to predict the "health score" of the hardware under the current load. When the health score is lower than the preset value, a warning is given and a compatibility problem that may occur is predicted in advance. After the test Job is completed, a separate "report generation service" (which can be another Kubernetes Pod) is triggered. The service queries all relevant indicator data in the test time window through the Prometheus API (PromQL), combines the abnormal events obtained from the log recording module, and automatically generates an HTML or PDF report containing data charts, KPI statistics, abnormal records, and test conclusions (Pass / Fail).

[0046] In the above embodiments, by automatically obtaining and analyzing the performance data of the target server hardware, abnormal events (such as performance drop and temperature exceeding) can be accurately identified, and these abnormalities can be automatically marked in the test report, which significantly improves the accuracy and reliability of the test results, provides a direct and reliable basis for quickly diagnosing hardware compatibility problems, and greatly reduces the manual troubleshooting cost and misjudgment risk.

[0047] In some specific embodiments, the method further includes: in response to the presence of an abnormal event, determining an event type of the abnormal event; in response to the event type being a software failure, recreating the container to continue executing the server hardware compatibility test task; In response to the event type being a hardware failure, a server hardware compatibility test task is scheduled to other server nodes to continue execution of the server hardware compatibility test task.

[0048] Specifically, the Alertmanager analyzes the index data stream in real time according to preset rules, and once an exception is found, notifies the administrator through Email, Slack or the like, determines the event type of the exception event, determines the corresponding self-recovery strategy according to the event type, and specifically: container-level self-recovery: if a test container crashes due to internal software errors, the Job controller of Kubernetes attempts to recreate the Pod according to its restartPolicy (restart policy) to continue executing the task; task-level self-recovery: if a task continuously fails due to hardware failure of a specific Node, the test scheduling module can reschedule the task to a backup Node to attempt again after receiving multiple failure alarms, and mark the original Node for manual maintenance.

[0049] Specifically, as Figure 4As shown, the original monolithic scheduling and analysis module is split into multiple independent microservices, each running in its own Pod, such as: APIService (responsible for receiving requests), SchedulingService (responsible for task scheduling), DataAnalysisService (responsible for data analysis), ReportService (responsible for report generation), etc. Among them, APIService provides a set of standardized RESTful APIs and uses Swagger / OpenAPI specifications for documentation, which can seamlessly integrate the test system into the CI / CD process (such as Jenkins, GitLab CI), enabling automatic triggering of tests after hardware changes. The communication mechanisms it adopts include synchronous and asynchronous communication. Synchronous communication: services call each other directly through lightweight RESTful APIs, such as SchedulingService calling Kubernetes API. Asynchronous communication: message queues (such as RabbitMQ or Kafka) are introduced. For example, after the test is completed, the execution container publishes a "TestCompleted" message, and ReportService and DataAnalysisService subscribe to this message and perform subsequent work asynchronously, which can improve the response capability and robustness of the system. After the test is completed, the historical test data accumulated in Prometheus is regularly exported to a big data storage system (such as HDFS or cloud storage S3), and the test process 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 big data platform (for historical trends and prediction results), create multiple customized Dashboards (visual interfaces that integrate key information) to visually display the real-time health status of the server cluster, test task progress, hardware performance KPI (key performance indicators), and intelligent analysis prediction results, providing one-stop monitoring and decision support for technical personnel.

[0050] Further, the present application uses a complete end-to-end example to illustrate the above process, specifically: hardware entry and test planning: when receiving a new model of RAID card, through the Web interface of the system, enter the model, manufacturer, firmware version, etc. Information of the card in the "hardware asset library", and then select "storage controller standard certification test set" from the "test plan template library". The 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 reconstruction performance test, etc.; automatic scheduling and execution: click "start test" to generate a test request, after receiving the test request, start the weighted scoring algorithm, select all server nodes installed with the new model of RAID card (reported through Device Plugin) and in online state from the Kubernetes cluster, after calculation, select a node with the lowest current load and the most stable historical running, and dynamically generate a series of KubernetesJob manifests, and through the API Server, they are sequentially or in parallel dispatched to the target server node; after the test starts, kubelet starts a test container containing tools such as fio on the node, and fio in the container starts read-write operation on the logical disk created by the RAID card. At the same time, on the "real-time test monitoring" dashboard of Grafana, the real-time IOPS, throughput, average / maximum delay curve of the RAID card, and the CPU temperature and power consumption change of the server node can be clearly seen; during the high-intensity 4K random write test, the output score of the intelligent anomaly detection model starts to rise continuously, and finally exceeds the alarm threshold, the system immediately triggers the abnormal association process, finds that the driver of the RAID card outputs a large number of "firmware lock contention detected" warning information in the system log, and Alertmanager immediately sends an alarm to the engineer through email and instant message: "Potential performance bottleneck: high delay jitter is detected under 4K random write load, suspected to be related to firmware lock contention"; after the entire test set is executed, the report generation service is automatically triggered, which pulls all performance indicator charts from Prometheus, extracts all related warnings and errors from the log system, summarizes the final results of the fio test, and attaches the conclusion of the intelligent analysis module, automatically generates a PDF test report and sends it to the user end. The report conclusion is: "the basic function of the RAID card passes, but there is a firmware performance bottleneck in the high-concurrency random write scenario, and firmware optimization is recommended", at the same time, all data and conclusions of this test are archived in the historical database, providing a more accurate performance baseline for future testing of this model or other models of RAID cards.

[0051] In the above-mentioned embodiments, by integrating real-time monitoring, multi-level alarm and automatic response strategy, the application can detect hardware performance abnormalities and container failures in real time, automatically trigger alarm notifications, and effectively deal with hardware and software abnormalities through self-healing mechanisms such as Pod restart and task rescheduling, thereby ensuring the continuous execution of test tasks, greatly reducing the need for manual intervention, and at the same time, through precise marking of faulty nodes and guiding repair, improving test efficiency and reliability.

[0052] In the server hardware compatibility test method, the server hardware compatibility test request is received, the target server node for responding to the server hardware compatibility test request is determined in the container orchestration management system cluster according to the server hardware compatibility test request, the container orchestration management system cluster includes a plurality of server nodes, the server hardware compatibility test task is determined based on the server hardware compatibility test request, and the server hardware compatibility test task is sent to the target server node, the target test tool is determined according to the server hardware compatibility test task, and the target container image containing the target test tool is determined based on the target test tool, wherein the container image includes a plurality of test tools, and the container image is stored in the container image warehouse deployed in the container orchestration management system cluster, the container corresponding to the target container image is started, the test instruction generated based on the server hardware compatibility test task is executed in the container, the performance data of the target server hardware is obtained, the abnormal event is determined based on the performance data, and the abnormal event is marked in the generated test report, the hardware compatibility is tested based on the container technology, the test environment can be quickly deployed and efficiently isolated, the mutual interference between test threads is avoided, the utilization rate of server hardware resources is improved through dynamic task scheduling and resource allocation, the abnormal event is determined in the test process through real-time data acquisition and intelligent analysis, and the continuous and stable execution of the test task is ensured through the abnormal event processing mechanism, the manual intervention cost and maintenance difficulty are reduced, the compatibility test efficiency and accuracy are improved, and in order to ensure the safety and stability of the test environment and prevent the test tasks from interfering with each other or damaging the host system, a plurality of security mechanisms are implemented, such as network isolation: the NetworkPolicy resource object of Kubernetes is used to implement strict network access control, by default, the network policy of all test namespaces (Namespace) is “default deny” (Default Deny), only the defined policy is allowed, for example, the test container of a web server is allowed to receive traffic from the load generator container on port 80, based on this, malicious or misconfigured test programs can be effectively prevented from scanning the internal network or attacking other services, and the maximum resource usage of each test task is limited, and the overall availability of the platform is ensured.Capability restrictions: Adopt Kubernetes Pod Security Standards (PSS), all test containers run in Baseline or Restricted policy by default, based on this, the container runs by default as a non-root user (runAsNonRoot: true), prohibits the container from requesting privileged mode (privileged: false), limits the host paths that the container can mount, only allows access to pre-approved devices or directories, limits the system calls (syscalls) that the container can perform through the seccomp configuration file, and further narrows the attack surface.

[0053] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be realized by means of software and the necessary general hardware platform, of course, it can also be realized by hardware, but in many cases the former is a better embodiment.

[0054] It should be understood that, although Figures 2-4 The steps in the flowchart of the method are displayed in sequence according to the arrows, but these steps are not necessarily executed in sequence according to the arrows. Unless otherwise stated herein, the execution of these steps is not strictly limited in sequence, and these steps can be executed in other sequences. Moreover, Figures 2-4 At least part of the steps in the method can include multiple sub-steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution sequence of these sub-steps or stages is not necessarily sequential, but can be executed in rotation or alternation with other steps or at least part of the sub-steps or stages of other steps.

[0055] In one embodiment, an electronic device, which can be a terminal, is provided, and an internal structure diagram of the electronic device can be as shown in Figure 5As shown in the figure. The electronic device includes a processor, a memory, a network interface, a display screen and an input device connected through a system bus. Among them, the processor of the electronic device is used to provide computing and control capability. The memory of the electronic device includes non-volatile storage medium, internal memory. The non-volatile storage medium stores the operating system and the computer program. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium to run. The network interface of the electronic device is used to communicate with the external terminal through the network connection. The computer program is executed by the processor to implement a server hardware compatibility test method. The display screen of the electronic device can be a liquid crystal display screen or an electronic ink display screen, and the input device of the electronic device can be a touch layer overlaid on the display screen, or a key, trackball or touchpad arranged on the shell of the electronic device, or an external keyboard, touchpad or mouse, etc.

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

[0057] The embodiments of the present 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 execute the steps in the server hardware compatibility test method embodiment, including: S1: receiving a server hardware compatibility test request; S2: determining a target server node for responding to the server hardware compatibility test request in a container orchestration management system cluster according to the server hardware compatibility test request, the container orchestration management system cluster including a plurality of server nodes; S3: 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; S4: determining a target test tool according to the server hardware compatibility test task, and determining a target container image containing the target test tool based on the target test tool, wherein the container image includes a plurality of test tools, and the container image is stored in a container image warehouse deployed in the container orchestration management system cluster; S5: starting a container corresponding to the target container image, executing test instructions generated based on the server hardware compatibility test task in the container, simultaneously, obtaining performance data of the target server hardware, determining an abnormal event based on the performance data, and marking in the generated test report.

[0058] The embodiment of the application further provides a computer readable storage medium, and the computer readable storage medium stores a computer program. S1: receiving a server hardware compatibility test request; S2: determining a target server node for responding to the server hardware compatibility test request in a container orchestration management system cluster according to the server hardware compatibility test request, the container orchestration management system cluster comprising a plurality of server nodes; S3: 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; S4: determining a target test tool according to the server hardware compatibility test task, and determining a target container image comprising the target test tool based on the target test tool, wherein the container image comprises a plurality of test tools, and the container image is stored in a container image warehouse deployed in the container orchestration management system cluster; S5: starting a container corresponding to the target container image, executing a test instruction generated based on the server hardware compatibility test task in the container, simultaneously, obtaining performance data of the target server hardware, determining an abnormal event based on the performance data, and marking in a generated test report.

[0059] In an example embodiment, the computer readable storage medium can include, but is not limited to, a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media capable of storing a computer program.

[0060] The embodiment of the application further provides a computer program product, and the computer program product comprises a computer program, and the computer program is executed by a processor to implement the steps in the server hardware compatibility test method embodiment, comprising: S1: receiving a server hardware compatibility test request; S2: determining a target server node for responding to the server hardware compatibility test request in a container orchestration management system cluster according to the server hardware compatibility test request, the container orchestration management system cluster comprising a plurality of server nodes; S3: 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; S4: determining a target test tool according to the server hardware compatibility test task, and determining a target container image containing the target test tool based on the target test tool, wherein the container image contains a plurality of test tools, and the container image is stored in a container image warehouse deployed in a container orchestration management system cluster; S5: starting a container corresponding to the target container image, executing test instructions generated based on the server hardware compatibility test task in the container, obtaining performance data of the target server hardware, determining an abnormal event based on the performance data, and marking the abnormal event in a generated test report.

[0061] Embodiments of the present application also provide another computer program product, including a non-volatile computer readable storage medium, the non-volatile computer readable storage medium storing a computer program, the computer program being executed by a processor to implement the steps in the server hardware compatibility test method embodiments, including: S1: receiving a server hardware compatibility test request; S2: determining a target server node for responding to the server hardware compatibility test request in a container orchestration management system cluster according to the server hardware compatibility test request, the container orchestration management system cluster including a plurality of server nodes; S3: 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; S4: determining a target test tool according to the server hardware compatibility test task, and determining a target container image containing the target test tool based on the target test tool, wherein the container image contains a plurality of test tools, and the container image is stored in a container image warehouse deployed in a container orchestration management system cluster; S5: starting a container corresponding to the target container image, executing test instructions generated based on the server hardware compatibility test task in the container, obtaining performance data of the target server hardware, determining an abnormal event based on the performance data, and marking the abnormal event in a generated test report.

[0062] Those skilled in the art can further understand that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software or a combination of both. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been described in general terms in the above description. Whether the 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 the present application.

[0063] The above describes in detail a server hardware compatibility test method, device, electronic equipment and storage medium provided by the present application. The principles and implementation modes of the present application are described by applying specific examples, and the above description of the embodiments is only applicable to help understand the method of the present application and its core idea. It should be pointed out that, for ordinary skilled persons in the technical field, some improvements and modifications can be made to the present application without departing from the principles of the present application, and these improvements and modifications also fall within the protection scope of the present 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. Based on the performance data, identify abnormal events and mark them in the generated test report.

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 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 the server node is determined, and the server nodes are prioritized based on the comprehensive evaluation value to obtain a ranking result. Based on the sorting results, the server node with the highest priority is defined as the target server node.

5. The server hardware compatibility testing method according to claim 4, characterized in that, 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.

6. 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.

7. 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.

8. 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.

9. The server hardware compatibility testing method according to claim 8, 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.

10. 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 9 when executing the computer program.

Images