CN111813495A

CN111813495A - Node testing method and device, storage medium and electronic device

Info

Publication number: CN111813495A
Application number: CN202010538251.0A
Authority: CN
Inventors: 杨晶晶
Original assignee: Beijing Kingsoft Cloud Network Technology Co Ltd
Current assignee: Beijing Kingsoft Cloud Network Technology Co Ltd
Priority date: 2020-06-12
Filing date: 2020-06-12
Publication date: 2020-10-23

Abstract

The application relates to a node testing method and device, a storage medium and an electronic device, wherein the method comprises the following steps: testing a target service module of a target node to obtain a first test result of a target kernel, wherein the target service module is used for processing the target service of the target node, and the target kernel is a kernel corresponding to the target node; testing a target service scene of a target virtual machine to obtain a second test result of a target kernel, wherein the target virtual machine is a virtual machine on a target node; and testing the node abnormal scene of the target node to obtain a third test result of the target core, wherein the test result of the target core comprises the first test result, the second test result and the third test result. The method and the device solve the problem that the kernel mode of the computing node in the related technology is not comprehensive in test caused by the limitation of a test tool.

Description

Node testing method and device, storage medium and electronic device

Technical Field

The present application relates to the field of computers, and in particular, to a node testing method and apparatus, a storage medium, and an electronic apparatus.

Background

Currently, when performing kernel stability testing on a compute node, an existing open source LTP (Linux Project, a set of items intended to test and upgrade a Linux system) tool is generally used to perform initialization testing on a kernel, which mainly includes: hard disk, I/O test, memory management stress test, IPC (Inter-Process Communication) stress test, SCHED test, verification test of command function, verification test of system call function, and the like.

However, when the LTP tool is used to perform stability testing on a new version of kernel of a computing node, there are often situations where the LTP (Linux test Project) version is not completely consistent with the kernel version, and some error information (the LTP version does not support) that does not support a module occurs; alternatively, some low-level error messages occur that do not affect the operational stability, which are meaningless for the test conclusion. Meanwhile, the stability test is only carried out by utilizing the LTP, so that the actual online running environment is separated, some important scenes can be omitted, and the test is not comprehensive enough.

Therefore, the kernel mode of the compute node in the related art has the problem of incomplete test caused by the limitation of the test tool.

Disclosure of Invention

The application provides a node testing method and device, a storage medium and an electronic device, which are used for at least solving the problem of incomplete testing caused by the limitation of a testing tool in a computing node kernel mode in the related technology.

According to an aspect of an embodiment of the present application, there is provided a node testing method, including: testing a target service module of a target node to obtain a first test result of a target kernel, wherein the target service module is used for processing the target service of the target node, and the target kernel is a kernel corresponding to the target node; testing a target service scene of a target virtual machine to obtain a second test result of the target kernel, wherein the target virtual machine is a virtual machine on the target node; and testing the node abnormal scene of the target node to obtain a third test result of the target kernel, wherein the test result of the target kernel comprises the first test result, the second test result and the third test result.

Optionally, the testing the target service module of the target node to obtain the first test result of the target kernel includes: acquiring a target test case, wherein the target test case is a test case of the target service module; and controlling the target node to run the target test case to obtain the first test result, wherein the first test result is used for indicating the virtual machine state of the target virtual machine and the node state of the target node.

Optionally, the target test case includes: the first test case is a test case of a first service module of the target node, and the controlling the target node to run the target test case to obtain the first test result includes: controlling the target node to run the first test case; and under the condition that the running time of the first test case is greater than or equal to a first time threshold, obtaining a first sub-test result, wherein the first test result comprises the first sub-test result, and the first sub-test result is used for representing the virtual machine state of the target virtual machine and the node state of the target node.

Optionally, the target test case includes: the second test case is a test case of the virtual gateway of the target node, and the controlling the target node to run the target test case to obtain the first test result includes: controlling the target node to run the second test case; and under the condition that the running time of the second test case is greater than or equal to a second time threshold, obtaining a second sub-test result, wherein the first test result comprises the second sub-test result, and the second sub-test result is used for representing the virtual machine state of the target virtual machine and the node state of the target node.

Optionally, the testing the target service scenario of the target virtual machine, and obtaining the second test result of the target kernel includes: controlling the target virtual machine to run the target service scenario, wherein the target service scenario includes at least one of: the method comprises the following steps that a first service scene related to virtual machine migration and a second service scene unrelated to the virtual machine migration are obtained; and under the condition that the running time of the target service scene is greater than or equal to a third time threshold, obtaining the second test result, wherein the second test result is used for representing the virtual machine state of the target virtual machine and the node state of the target node.

Optionally, in a case that the target service scenario includes the first service scenario, the controlling the target virtual machine to run the target service scenario includes: under the condition that the target virtual machine comprises a plurality of first virtual machines, controlling the plurality of first virtual machines to run the first service scenario, wherein the first service scenario comprises at least one of the following: a round-trip migration of one virtual machine, a concurrent round-trip migration of a plurality of virtual machines, a virtual machine migration calling one or more migration interfaces, and a continuous migration of virtual machines among a plurality of nodes in a virtual machine cluster, wherein each first virtual machine is configured to run at least one first service scenario in at least one load mode, and the load mode includes at least one of: full load, empty load, jump load, gradual load.

Optionally, in a case that the target service scenario includes the second service scenario, the controlling the target virtual machine to run the target service scenario includes: under the condition that the target virtual machine comprises a plurality of second virtual machines, controlling a first part of the plurality of second virtual machines to run a first sub-business scenario, wherein the first sub-business scenario comprises: operating a load in at least one load mode, the load mode comprising at least one of: full load, empty load, jump load, gradual load; and controlling a second part of the plurality of second virtual machines to run a second sub-service scene, wherein the second sub-service scene is a mirror image file manufactured under the condition that the reading and writing operations are continuously executed in the virtual machines, and the second service scene comprises the first sub-service scene and the second sub-service scene.

Optionally, before the testing the target service scenario of the target virtual machine to obtain the second test result of the target kernel, the method further includes: creating the target virtual machine by using a target image file, wherein a target load tool and a load script of multiple load modes are pre-installed in the target image file, the target load tool is used for constructing the target service scene by using the load script, and the load modes comprise at least one of the following modes: full load, empty load, jump load, gradual load.

Optionally, the testing the node exception scenario of the target node to obtain the third test result of the target kernel includes: controlling the target node to run the node exception scenario, wherein the node exception scenario comprises at least one of: the memory of the node is leaked, the second service module on the node is repeatedly restarted, and data is continuously backed up to a target cluster, wherein the target cluster is used for storing the data; and under the condition that the running time of the node abnormal scene is greater than or equal to a fourth time threshold, acquiring the third test result, wherein the third test result is used for representing the virtual machine state of the target virtual machine and the node state of the target node.

Optionally, the controlling the target node to run the node exception scenario includes: using a target memory tool to occupy the memory of the target node, and continuously executing the first sub-time to obtain a third sub-test result, wherein the target memory tool is used for executing a memory pressure test; controlling the second service module to restart repeatedly, and continuously executing the second sub-time to obtain a fourth sub-test result; and controlling the target node to continuously backup data to the target cluster, and continuously executing a third sub-time to obtain a fifth sub-test result, wherein the third test result comprises the third sub-test result, the fourth sub-test result and the fifth sub-test result.

According to another aspect of the embodiments of the present application, there is provided a node testing apparatus, including: the system comprises a first testing unit, a second testing unit and a third testing unit, wherein the first testing unit is used for testing a target service module of a target node to obtain a first testing result of a target kernel, the target service module is used for processing a target service of the target node, and the target kernel is a kernel corresponding to the target node; the second testing unit is used for testing a target service scene of a target virtual machine to obtain a second testing result of the target kernel, wherein the target virtual machine is a virtual machine on the target node; and the third testing unit is used for testing the node exception scene of the target node to obtain a third testing result of the target kernel, wherein the testing result of the target kernel comprises the first testing result, the second testing result and the third testing result.

Optionally, the first test unit comprises: the first obtaining module is used for obtaining a target test case, wherein the target test case is a test case of the target service module; and the first control module is used for controlling the target node to run the target test case to obtain the first test result, wherein the first test result is used for indicating the virtual machine state of the target virtual machine and the node state of the target node.

Optionally, the target test case includes: a first test case, where the first test case is a test case of a first service module of the target node, and the first control module includes: the first control submodule is used for controlling the target node to run the first test case; the first obtaining submodule is configured to obtain a first sub-test result when the running time of the first test case is greater than or equal to a first time threshold, where the first test result includes the first sub-test result, and the first sub-test result is used to represent a virtual machine state of the target virtual machine and a node state of the target node.

Optionally, the target test case includes: a second test case, where the second test case is a test case of the virtual gateway of the target node, and the first control module includes: the second control submodule is used for controlling the target node to run the second test case; and the second obtaining submodule is used for obtaining a second sub-test result under the condition that the running time of the second test case is greater than or equal to a second time threshold, wherein the first test result comprises the second sub-test result, and the second sub-test result is used for representing the virtual machine state of the target virtual machine and the node state of the target node.

Optionally, the second test unit comprises: a second control module, configured to control the target virtual machine to run the target service scenario, where the target service scenario includes at least one of: the method comprises the following steps that a first service scene related to virtual machine migration and a second service scene unrelated to the virtual machine migration are obtained; a second obtaining module, configured to obtain the second test result when a running time of the target service scenario is greater than or equal to a third time threshold, where the second test result is used to represent a virtual machine state of the target virtual machine and a node state of the target node.

Optionally, the second control module comprises: a third control sub-module, configured to control, when the target service scenario includes the first service scenario, a plurality of first virtual machines to run the first service scenario, where the target virtual machine includes the plurality of first virtual machines, and the first service scenario includes at least one of: a round-trip migration of one virtual machine, a concurrent round-trip migration of a plurality of virtual machines, a virtual machine migration calling one or more migration interfaces, and a continuous migration of virtual machines among a plurality of nodes in a virtual machine cluster, wherein each first virtual machine is configured to run at least one first service scenario in at least one load mode, and the load mode includes at least one of: full load, empty load, jump load, gradual load.

Optionally, the second control module comprises: a fourth control sub-module, configured to control a first part of a plurality of second virtual machines to run a first sub-service scenario when the target service scenario includes the second service scenario, where the target virtual machine includes the plurality of second virtual machines, and the first sub-service scenario includes: operating a load in at least one load mode, the load mode comprising at least one of: full load, empty load, jump load, gradual load; and a fifth control sub-module, configured to control a second part of the multiple second virtual machines to run a second sub-service scenario, where the second sub-service scenario is a mirror image file created when a read-write operation is continuously performed inside a virtual machine, and the second service scenario includes the first sub-service scenario and the second sub-service scenario.

Optionally, the apparatus further comprises: a creating unit, configured to create a target virtual machine using a target image file before a second test result of the target kernel is obtained by testing a target service scenario of the target virtual machine, where the target image file is pre-installed with a target load tool and load scripts in multiple load modes, the target load tool is configured to construct the target service scenario using the load scripts, and the load modes include at least one of: full load, empty load, jump load, gradual load.

Optionally, the third test unit comprises: a third control module, configured to control the target node to run the node exception scenario, where the node exception scenario includes at least one of: the memory of the node is leaked, the second service module on the node is repeatedly restarted, and data is continuously backed up to a target cluster, wherein the target cluster is used for storing the data; a third obtaining module, configured to obtain the third test result when a running time of the node abnormal scenario is greater than or equal to a fourth time threshold, where the third test result is used to represent a virtual machine state of the target virtual machine and a node state of the target node.

Optionally, the third control module comprises: the occupation submodule is used for using a target memory tool to occupy the memory of the target node and continuously executing the first sub-time to obtain a third sub-test result, wherein the target memory tool is used for executing a memory pressure test; the sixth control submodule is used for controlling the second service module to be repeatedly restarted and continuously executing the second sub-time to obtain a fourth sub-test result; and the seventh control sub-module is configured to control the target node to continuously backup the data to the target cluster, and continuously execute a third sub-time to obtain a fifth sub-test result, where the third test result includes the third sub-test result, the fourth sub-test result, and the fifth sub-test result.

According to a further aspect of an embodiment of the present application, there is also provided a computer-readable storage medium having a computer program stored thereon, wherein the computer program is configured to perform the steps of any of the above method embodiments when executed.

According to a further aspect of an embodiment of the present application, there is also provided an electronic apparatus, including a memory and a processor, the memory storing a computer program therein, the processor being configured to execute the computer program to perform the steps in any of the above method embodiments.

In the embodiment of the application, a standard-flow kernel test mode is adopted based on an actual service scene of a virtual machine on a computing node, and a target service module of a target node is tested to obtain a first test result of the target kernel, wherein the target service module is used for processing a target service of the target node, and the target kernel is a kernel corresponding to the target node; testing a target service scene of a target virtual machine to obtain a second test result of a target kernel, wherein the target virtual machine is a virtual machine on a target node; the method comprises the steps of testing a node abnormal scene of a target node to obtain a third test result of a target core, wherein the test result of the target core comprises a first test result, a second test result and a third test result, and the core stability test is performed from two aspects of a physical machine and a virtual machine, so that the basic function of testing a computing node is achieved, and the test scene of normal operation and abnormity of the computing node is covered, so that the technical effect of improving the node test comprehensiveness is achieved, and the problem of incomplete test caused by the limitation of a test tool in a computing node core mode in the related technology is solved.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and together with the description, serve to explain the principles of the invention.

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious for those skilled in the art that other drawings can be obtained according to the drawings without inventive exercise.

FIG. 1 is a schematic diagram of a hardware environment for a node testing method according to an embodiment of the present application;

FIG. 2 is a flow chart of an alternative node testing method according to an embodiment of the present application;

FIG. 3 is a flow chart of another alternative node testing method according to an embodiment of the present application;

FIG. 4 is a schematic diagram of an alternative node testing apparatus according to an embodiment of the present application;

fig. 5 is a block diagram of an alternative electronic device according to an embodiment of the present application.

Detailed Description

In order to make the technical solutions better understood by those skilled in the art, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only partial embodiments of the present application, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

It should be noted that the terms "first," "second," and the like in the description and claims of this application and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are capable of operation in sequences other than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

First, partial nouns or terms appearing in the description of the embodiments of the present application are applicable to the following explanations:

1) computing node

In an OpenStack (an open source cloud computing management platform project) distributed framework, the OpenStack can be divided into a control node and a computing node, wherein the control node is responsible for scheduling resources to the corresponding computing node, the computing node is used for allocating actual resources to a virtual machine, and the control node and the computing node are physical machines of a Linux system.

2) Inner core

The kernel is a core module of the Linux operating system and can be responsible for all or part of the following processes: storage management, Central Processing Unit (CPU) and process management, file system, device management and driving, network communication, system initialization (booting), and system call.

3) Stability test

The stability test can also be called a reliability test, and the system is enabled to continuously run for a period of time by loading a certain service pressure to the system, so as to detect whether the system can stably run or not.

4)LTP

LTP is a project collaborated by SGI, IBM, OSDL and Bull, and aims to provide a test suite for open source communities to verify the reliability, robustness and stability of Linux systems.

5) Nova (virtual server deployment and business computation module for NASA development)

Nova is the most core service module in OpenStack, and is responsible for managing and maintaining the computing resources of the cloud computing environment and managing the life cycle of the virtual machine in the whole cloud environment.

6) VGW (Virtual Gateway)

7) Chaosblade, an open-source chaotic engineering tool, can provide rich fault scene realization, help distributed system promote fault tolerance and recoverable chaotic engineering tool.

8) A distributed object storage cluster is a back-end storage and is mainly used for storing mirror images and backup files.

According to one aspect of the embodiments of the present application, a node testing method is provided. Alternatively, in this embodiment, the node testing method may be applied to a hardware environment formed by the terminal 101 and the server 103 as shown in fig. 1. As shown in fig. 1, a server 103 is connected to a terminal 101 through a network, which may be used to provide services (such as game services, application services, etc.) for the terminal or a client installed on the terminal, and a database may be provided on the server or separately from the server for providing data storage services for the server 103, and the network includes but is not limited to: the terminal 101 is not limited to a PC, a mobile phone, a tablet computer, and the like. The node testing method in the embodiment of the present application may be executed by the server 103, the terminal 101, or both the server 103 and the terminal 101. The terminal 101 may execute the node testing method according to the embodiment of the present application by a client installed thereon.

Fig. 2 is a flowchart of an alternative node testing method according to an embodiment of the present application, and as shown in fig. 2, the method may include the following steps:

step S202, testing a target service module of a target node to obtain a first test result of a target kernel, wherein the target service module is used for processing the target service of the target node, and the target kernel is a kernel corresponding to the target node;

step S204, testing a target service scene of a target virtual machine to obtain a second test result of a target kernel, wherein the target virtual machine is a virtual machine on a target node;

step S206, testing the node abnormal scene of the target node to obtain a third test result of the target core, wherein the test result of the target core comprises the first test result, the second test result and the third test result.

Through the steps S202 to S206, a target service module of the target node is tested to obtain a first test result of the target kernel, where the target service module is used to process a target service of the target node, and the target kernel is a kernel corresponding to the target node; testing a target service scene of a target virtual machine to obtain a second test result of a target kernel, wherein the target virtual machine is a virtual machine on a target node; the node exception scene of the target node is tested to obtain a third test result of the target core, wherein the test result of the target core comprises the first test result, the second test result and the third test result, the problem that the test is incomplete due to the fact that the mode of computing the node core in the related art is limited by a test tool is solved, and the completeness of the node test is improved.

In the technical solution provided in step S202, a target service module of a target node is tested to obtain a first test result of a target kernel, where the target service module is used to process a target service of the target node, and the target kernel is a kernel corresponding to the target node.

The node testing method in the embodiment can be applied to a scene of performing kernel stability testing on the computing nodes of the cloud computing platform.

In the related art, the LTP tool is used to test the stability of the new version of the kernel of the computing node, and there are often situations where the LTP version is not completely consistent with the kernel version (that is, the kernel version that can be tested by the LTP version is not consistent with the tested kernel version), some error messages that do not support modules occur (the LTP does not support modules in the kernel), or some low-level error messages that do not affect the operational stability occur (for example, an error is reported using or performance prompts, but these prompts do not affect the operational stability), and it is meaningless to test the conclusion. Meanwhile, only the LTP is used for stability testing, which breaks away from the actual online operating environment and may omit some important scenes (online service scenes).

The node to be tested is a target node, the target node can be a computing node in a cloud computing platform, the kernel of the target node is a target kernel, and the kernel stability of the node is tested. When testing the target node, the tester can perform test control through the terminal equipment of the tester. The tester can operate the terminal device to perform configuration of data required by the test and corresponding test parameters, and perform predetermined operation trigger on the terminal device to start testing a target node, wherein the target node can be a computing node of a server.

In the embodiment, the kernel stability test is memoried from three aspects of primary basic function verification, on-line service scene test of the simulation node and special case test of node abnormity.

The testing of the target node may include: and primary basic function verification, wherein the verification of the basic functions of the nodes is realized by testing a target service module of the nodes: the target service module of the target node can be tested to obtain a first test result of the target kernel, and the first test result is used for representing the stability of the target kernel.

The target service module is configured to process a target service of a target node, for example, the target service module may be responsible for at least one of the following services: managing and maintaining computing resources of a cloud computing environment; managing a life cycle of the cloud environment virtual machine; controlling signaling in the network.

It should be noted that the target service module may be a physical module on the computing node, or may be a program module depending on a hardware module on the computing node, and the target service module may implement the basic function of the target node. The basic functions performed by different nodes may be the same or different.

In the technical solution provided in step S204, a target service scenario of a target virtual machine is tested to obtain a second test result of the target kernel, where the target virtual machine is a virtual machine on a target node.

The node kernel stability test in the related technology is only a test for the performance of a node physical machine, and breaks away from the actual on-line running environment, so that the test is not comprehensive.

Optionally, in this embodiment, the testing performed on the target node may include: and simulating the on-line service scene test of the node. By simulating the online environment as much as possible, the service scene is covered in multiple dimensions, the manual test workload is low, and the comprehensiveness and the high efficiency of the test are both considered.

The simulation of the online service scenario mainly simulates the service scenario of the target virtual machine on the target node, that is, the target service scenario. The simulation of the on-line service scenario test of the node may be: and testing the target service scene of the target virtual machine to obtain a second test result of the target kernel, wherein the second test result is used for expressing the stability of the target kernel.

In the technical solution provided in step S206, a node exception scenario of the target node is tested to obtain a third test result of the target core, where the test result of the target core includes the first test result, the second test result, and the third test result.

The testing of the target node may include: and testing special conditions of node abnormity. Besides the test scenario of normal operation of the target node, the test scenario of the target node when the target node is abnormal can be tested, and the abnormal test scenario can be used for testing the capability of the target node for exception handling.

Special case testing for node anomalies may include: and testing the node abnormal scene of the target node to obtain a third test result of the target kernel, wherein the third test result is used for expressing the stability of the target kernel.

The test results for the target core may include a first test result, a second test result, and a third test result. Whether the kernel can stably run or not can be determined by analyzing the first test result, the second test result and the third test result, and then a basis is provided for performance improvement of the kernel.

As an optional embodiment, the testing the target service module of the target node to obtain the first test result of the target core includes:

s11, acquiring a target test case, wherein the target test case is a test case of the target service module;

and S12, controlling the target node to run the target test case to obtain a first test result, wherein the first test result is used for indicating the virtual machine state of the target virtual machine and the node state of the target node.

The testing of the target business module can be automated testing using preset test cases. In order to test the target service module, a test case for testing the target service module may be obtained.

The target test case may be an automated test case of the target service module, and the manner of obtaining the target test case may be: the stored target test case may be called from a local memory, or the target test case may be received from another device, where the target test case may be generated by a test case generation tool.

After the target test case is obtained, the target node can be controlled to run the target test case to obtain a first test result, and the first test result is used for indicating the virtual machine state of the target virtual machine and the node state of the target node. For example, the target node may be controlled to view the virtual machine and the state of the compute node after running the target test case for a period of time.

The virtual machine state of the virtual machine may be used to represent the state of the virtual machine, may be the running state of the virtual machine, or other states, and the node state of the node may be used to represent the state of the node, may be the running state of the node, or other states. All the virtual machine states and node states capable of representing the stability of the kernel can be used in the node testing method in the embodiment.

By the embodiment, the target service module is tested by using the target test case, so that the target service module can be automatically tested, and the test efficiency of the target node is improved.

As an optional embodiment, controlling the target node to run the target test case, and obtaining the first test result includes:

s21, controlling the target node to run a first test case;

s22, acquiring a first sub-test result under the condition that the running time of the first test case is greater than or equal to a first time threshold, wherein the first test result comprises a first sub-test result, and the first sub-test result is used for representing the virtual machine state of the target virtual machine and the node state of the target node.

Optionally, in this embodiment, the target test case includes: and the first test case is a test case of the first service module of the target node. The first service module may be Nova under an OpenStack distributed framework, and correspondingly, the first test case may be an existing Nova automated test case.

The nova automated test is a test for resource allocation and scheduling of the virtual machine in an OpenStack layer. The Nova automated test case mainly tests part or all of the following flow operations: the method comprises the following steps of creating, shutting down, starting up, restarting, reloading, changing configuration, backing up, snapshotting, migrating, binding a key pair, mounting an auxiliary network card and the like of a host of the two types of virtual machines. The two types of virtual machines comprise: SSD (Solid State Disk, local Disk) and EBS (Elastic block storage, cloud Disk).

When the Nova automation test is performed, the existing Nova automation test case can be utilized to specify that a computing node (an example of a target node) deployed by a specific kernel version (for example, a new kernel version) is started and run the automation case.

When the running time of the first test case is greater than or equal to the first time threshold, a first sub-test result used for representing the virtual machine state of the target virtual machine and the node state of the target node can be obtained, and the test on the first service module is completed.

For example, for Nova automated testing, the computing node can be controlled to run the Nova automated testing case, and after running for 24h (hours), the virtual machine and the computing node state can be checked. An alternative implementation of the test case may be: and calling the nova API based on the TestNG framework, and checking whether the virtual machine state meets the expectation after the API returns success.

It should be noted that the service module tested by the basic function test may be configured as needed, and may include but is not limited to the Nova, and for the service modules in other cloud computing network architectures, the service modules may be tested in a manner similar to that described above, which is not described herein again.

By the embodiment, the test result of the kernel is obtained after the target node is controlled to run the first test case for a certain time, so that the test of the first service module is completed, and the test reliability of the service module can be improved.

s31, controlling the target node to run a second test case;

and S32, acquiring a second sub-test result under the condition that the running time of the second test case is greater than or equal to a second time threshold, wherein the first test result comprises the second sub-test result, and the second sub-test result is used for representing the virtual machine state of the target virtual machine and the node state of the target node.

Optionally, in this embodiment, the target test case includes: and the second test case is a test case of the virtual gateway of the target node. The target service module may include a virtual gateway on the target node, and correspondingly, the test case used for the test of the virtual gateway may be: existing VGW automation test cases.

The VGW automatic test case is used for testing the virtual gateway. The test case may test all or part of the following functions or indicators of the virtual gateway: initializing a VXLAN (Virtual eXtensible LAN) tunnel; a VGW domain; a VXLAN subnet; route; a neighbor; capacity/boundary value of route; capacity/boundary value of neighbor; a DHCP (Dynamic Host Configuration Protocol) function; access control list functions; a security group function; network status and other VGW ADM (admin) functions (the other VGW functions are mainly hellp, version, config, install, uninstall), etc.

When performing the VGW automation test, an existing VGW automation test case may be utilized to specify a computing node (an example of a target node) deployed by a specific kernel version (e.g., a new kernel version) to be powered on and run the automation test case.

When the running time of the second test case is greater than or equal to the second time threshold, a second sub-test result used for representing the virtual machine state of the target virtual machine and the node state of the target node can be obtained, and the VGW test is completed.

For example, for the VGW automation test, the computing node may be controlled to run the VGW automation test case, and after the VGW automation test case is continuously run for 24 hours, the states of the virtual machine and the computing node are checked.

By the embodiment, the target node is controlled to run the second test case for a certain time, and then the test result of the kernel is obtained, so that the test of the virtual gateway is completed, and the reliability of the test of the virtual gateway can be improved.

As an optional embodiment, the step of testing the target service scenario of the target virtual machine to obtain the second test result of the target kernel includes:

s41, controlling the target virtual machine to run a target service scene, wherein the target service scene comprises at least one of the following: the method comprises the following steps that a first service scene related to virtual machine migration and a second service scene unrelated to the virtual machine migration are obtained;

and S42, acquiring a second test result when the running time of the target service scenario is greater than or equal to a third time threshold, wherein the second test result is used for representing the virtual machine state of the target virtual machine and the node state of the target node.

When the target service scene of the target virtual machine is tested, the target virtual machine can be controlled to operate the target service scene, that is, the operation of the target service scene is simulated. One or more of the target service scenarios may include: a service scenario involving virtual machine migration (first service scenario) and a service scenario not involving virtual machine migration (second service scenario).

The number of the target virtual machines can be one or more, and the same virtual machine can run at least one or more service scenes. The different service scenarios may be executed simultaneously (i.e., different virtual machines execute different service scenarios), or sequentially (the same virtual machine executes different service scenarios, or different virtual machines execute different service scenarios).

When the time for the target virtual machine to run the target service scenario reaches a third time threshold, a second test result used for representing the virtual machine state of the target virtual machine and the node state of the target node may be obtained.

When there are multiple target service scenarios, the total running time of the target virtual machine may be: the sum of the running times of the plurality of business scenarios, for example, the running time of the first business scenario and the running time of the second business scenario. When the number of the target virtual machines is multiple, different virtual machines or virtual machine combinations can execute different service scenes simultaneously. In the foregoing case, the total running time of the target virtual machine is related to the number of service scenarios executed simultaneously, and may be determined according to an actual test scenario, which is not specifically limited in this embodiment.

By the embodiment, the test result of the kernel is obtained after the service scene related to the virtual machine migration and the service scene unrelated to the virtual machine migration are operated for a certain time, so that the test of the service scene on the virtual machine line is completed, and the reliability of the virtual machine test can be improved.

As an optional embodiment, in the case that the target service scenario includes the first service scenario, controlling the target virtual machine to run the target service scenario includes:

s51, in a case that the target virtual machine includes a plurality of first virtual machines, controlling the plurality of first virtual machines to run a first service scenario, where the first service scenario includes at least one of: the method comprises the following steps of performing round-trip migration on one virtual machine, performing concurrent round-trip migration on a plurality of virtual machines, calling virtual machine migration of one or more migration interfaces, and continuously migrating the virtual machines among a plurality of nodes in a virtual machine cluster, wherein each first virtual machine is used for running at least one first service scene in at least one load mode, and the load mode comprises at least one of the following modes: full load, empty load, jump load, gradual load.

The target business scenario may include a first business scenario related to virtual machine migration. The first traffic scenario may include at least one of: the method comprises the following steps of carrying out round-trip migration on one virtual machine, carrying out concurrent round-trip migration on a plurality of virtual machines, calling virtual machine migration of one or a plurality of migration interfaces, and continuously migrating the virtual machines among a plurality of nodes in a virtual machine cluster.

A part of virtual machines (first virtual machines) in the target virtual machines can be selected to run the first service scene. The virtual machine migration is a virtual machine under different load modes, and the load modes include at least one of the following: full load, empty load, jump load, gradual load (gradual load). The different first virtual machines can run at least one first service scenario in at least one load mode to model virtual machine migration in different load modes.

When the first service scenario test is performed, the plurality of first virtual machines may be controlled to run the first service scenario. In order to improve the testing efficiency, a first virtual machine can be controlled to operate a first service scenario in a load mode. Correspondingly, the number of virtual machines to be created can be determined according to the number of load patterns and the number of virtual machines involved in the first service scenario.

It should be noted that the virtual machine migration for invoking one or more migration interfaces may be: migration test with/without data disc. The with/without data disc is mainly tested for migration operations of local disc hosts of different configurations. The data disk with data needs to be pre-migrated (migrated data disk) first, online migration can be performed only after pre-migration is successful, and online migration can be performed directly without the data disk. With/without a data disc may be understood as different scenarios of invoking a plurality of different migration interface combinations and invoking a single migration interface.

It should also be noted that the continuous migration of virtual machines between nodes in the virtual machine cluster may be a virtual machine migration between two/three compute nodes. The two-computing node/the three-computing node mainly tests the migration scheduling scene of the virtual machine. When the virtual machine is migrated, a scheduling strategy of nova is involved, and the nova-schedule service selects an optimal computing node (namely a physical machine) according to the resource use condition of each computing node in the cluster to schedule the virtual machine to the node. Generally, scheduling is performed in the same cluster, if the cluster only has two computing nodes and the virtual machine is currently located on a node a, the virtual machine is scheduled to a node B by a scheduling strategy triggered by online migration, and if the virtual machine is scheduled to a node B for the first time under the condition of three computing nodes, the virtual machine may be scheduled to a node B or a node C (node sorting and selecting are optimal based on a scheduling algorithm), and if the virtual machine is continuously migrated and scheduled to a node C or a node B and then to a. The continuous migration of the virtual machine among a plurality of nodes in the virtual machine cluster can be understood as a round-trip migration scenario between two nodes and a round-trip migration scenario between multiple nodes.

Through the embodiment, various service scenes of virtual machine migration are simulated through the first virtual machines, the test comprehensiveness can be ensured, and the test efficiency is considered at the same time.

As an optional embodiment, in a case that the target service scenario includes the second service scenario, controlling the target virtual machine to run the target service scenario includes:

s61, when the target virtual machine includes a plurality of second virtual machines, controlling a first part of the plurality of second virtual machines to run a first sub-service scenario, where the first sub-service scenario includes: operating a load in at least one load mode, the load mode comprising at least one of: full load, empty load, jump load, gradual load;

and S61, controlling a second part of the plurality of second virtual machines to run a second sub-service scene, wherein the second sub-service scene is a mirror image file manufactured under the condition that the reading and writing operations are continuously executed in the virtual machines, and the second service scene comprises a first sub-service scene and a second sub-service scene.

The target business scenario may include a second business scenario unrelated to the virtual machine migration. And selecting a part of virtual machines (second virtual machines) in the target virtual machines to run the second service scene. The second service scenario may include at least one of: different mode loads are operated, and internal I/O is simultaneously mirrored.

The first sub-service scenario may be a service scenario running different mode loads. The first sub-service scenario may be: the virtual machines execute loads of different load patterns, which may include, but are not limited to, at least one of: full load, empty load, jump load, gradual load.

When the first sub-service scenario test is performed, the first parts of the plurality of second virtual machines may be controlled to run the first sub-service scenario. In order to improve the testing efficiency, a second virtual machine can be controlled to run a first sub-service scenario in a load mode. Correspondingly, the number of virtual machines to be created can be determined according to the number of load patterns.

The second sub-service scenario may be a scenario in which an image is made while the I/O is performed inside the virtual machine, that is, an image file is made while the read-write operation is continuously performed inside the virtual machine. The second sub-service scene can call nova-API to make a self-defined mirror image when the internal of the virtual machine continuously performs read-write operation so as to simulate the second sub-service scene.

When the first sub-service scenario test is performed, the plurality of first virtual machines may be controlled to run the first service scenario. In order to improve the testing efficiency, a first virtual machine can be controlled to operate a first service scenario in a load mode. Correspondingly, the number of virtual machines to be created can be determined according to the number of load patterns and the number of virtual machines involved in the first service scenario.

When the second sub-service scenario test is performed, the second part of the plurality of second virtual machines may be controlled to run the second sub-service scenario. The second portion of the plurality of second virtual machines may comprise one virtual machine.

By the embodiment, a plurality of service scenes irrelevant to virtual machine migration are simulated by the plurality of second virtual machines, so that the test comprehensiveness can be ensured, and the test efficiency is considered at the same time.

As an optional embodiment, before the target service scenario of the target virtual machine is tested to obtain the second test result of the target kernel, the method further includes:

s71, creating the target virtual machine by using the target image file, wherein the target image file is pre-installed with a target load tool and a load script of multiple load modes, the target load tool is used for constructing a target service scene by using the load script, and the load mode comprises at least one of the following modes: full load, empty load, jump load, gradual load.

In order to test the target service scenario, a target virtual machine required for the test may be created in advance. The target virtual machine may be created using a target image file in which a target load tool and a load script of a plurality of load modes are pre-installed. The target load tool can use the load script to construct a target business scene. The load pattern may include, but is not limited to, at least one of: full load, empty load, jump load, gradual load.

For example, multiple virtual machines can be created using custom images with the Chaosblade tool pre-installed and different schema load scripts written. The virtual machine running on the computing node carries out load pressure in different modes by means of a Chaosblade tool, and other tools or stress commands can be adopted to simulate the load.

According to the embodiment, the target virtual machine is created through the target image file provided with the target load tool and the load scripts of various load modes, so that the virtual machine creation efficiency can be improved, and the simulation capability of the target service scene is improved.

As an optional embodiment, the step of testing the node exception scenario of the target node to obtain a third test result of the target core includes:

s81, controlling the target node to run a node exception scene, wherein the node exception scene comprises at least one of the following: the memory of the node is leaked, the second service module on the node is repeatedly restarted, and data is continuously backed up to a target cluster, and the target cluster is used for storing the data;

and S82, acquiring a third test result when the running time of the node abnormal scene is greater than or equal to a fourth time threshold, wherein the third test result is used for representing the virtual machine state of the target virtual machine and the node state of the target node.

The node exception scenario may include a variety of exception scenarios, which may include, but are not limited to, at least one of: and (4) the memory of the node is leaked, the second service module on the node is repeatedly restarted, and the data is continuously backed up to the target cluster.

The second service module and the first service module may be the same service module, for example, both may be Nova, and the target cluster is used for data storage, and the storage may be: mirror files and backup files, an example of the target cluster may be a distributed object storage cluster.

The target node can be controlled to run the node exception scenario, and when the running time of the node exception scenario is greater than or equal to a fourth time threshold, a third test result used for representing the virtual machine state of the target virtual machine and the node state of the target node is obtained. When there are multiple node exception scenarios, the target node may be controlled to sequentially execute each node exception scenario. Correspondingly, the fourth time threshold may be a sum of the execution times of the plurality of node exception scenarios.

By the method and the device, the test result of the kernel is obtained after the target node is controlled to operate the node abnormal scene for a certain time, so that the test on the node abnormal scene is completed, and the reliability of the test on the node abnormal scene can be improved.

As an alternative embodiment, the controlling the target node to run the node exception scenario includes:

s91, using the target memory tool to occupy the memory of the target node, and continuously executing the first sub-time to obtain a third sub-test result, wherein the target memory tool is used for executing the memory pressure test;

s92, controlling the second service module to restart repeatedly, and continuously executing the second sub-time to obtain a fourth sub-test result;

and S93, controlling the target node to continuously backup the data to the target cluster, and continuously executing the third sub-time to obtain a fifth sub-test result, wherein the third test result comprises a third sub-test result, a fourth sub-test result and a fifth sub-test result.

The node exception scene comprises the following steps: and (3) the node has memory leakage, and a second service module (such as Nova service) on the node is repeatedly restarted to continuously back up data to a target cluster (such as a distributed object storage cluster).

For the node memory leakage scene, a target memory tool (e.g., a memtest tool) can be used to occupy the memory of the target node, the memory is recovered to be normal after the first sub-time is continuously executed, and the virtual machine state of the target virtual machine and the node state of the target node are checked, so that a third sub-test result is obtained.

For the scenario that the second service module on the node is repeatedly restarted, the service abnormality of the second service module on the target node can be controlled, the second service module is repeatedly restarted, the second service module is recovered to be normal after the second sub-time is continuously executed, the virtual machine state of the target virtual machine and the node state of the target node are checked, and therefore the fourth sub-test result is obtained.

For the scenario of continuously backing up data to the target cluster, the target node can be controlled to be connected with the target cluster, the data is continuously backed up through the communication connection between the target node and the target cluster, the data is recovered to be normal after the third sub-time is continuously executed, the virtual machine state of the target virtual machine and the node state of the target node are checked, and therefore the fifth sub-test result is obtained. In addition, other devices capable of storing data besides the target cluster may also be applied to the above-described abnormal scenario of the persistent backup data.

The first sub-time, the second sub-time, and the third sub-time may be the same or different, and a sum of the first sub-time, the second sub-time, and the third sub-time may be less than or equal to the fourth time threshold. The third test result may include: third, fourth and fifth subtest results

By the embodiment, the test result of each node abnormal scene is obtained by simulating various node abnormal scenes, and the comprehensiveness of the node kernel test can be ensured.

It should be noted that, in this embodiment, the viewing of the virtual machine state may include at least one of the following:

1) checking whether the virtual machine is recovered to an ACTIVE state (an activated state) after the operation is finished;

2) checking whether the shutdown operation is in a shutdown state;

3) checking whether the IP of the virtual machine can be ping;

4) and logging in the virtual machine to execute the shell command, and checking whether the utilization rate of the CPU and the memory is normal.

The corresponding first test result may include at least one of: a state of the virtual machine after the operation is completed (e.g., an active state, not an active state), a state of the virtual machine after the shutdown operation (e.g., a shutdown state, not a shutdown state), a state of the virtual machine after the ping operation (e.g., IP capable ping, IP incapable ping); the CPU and memory utilization (e.g., actual CPU and memory utilization, normal, abnormal) after the shell command is executed inside the virtual machine.

Viewing the target node status may include at least one of:

1) checking the CPU and memory utilization rate of the target node;

2) and checking whether each service is abnormally restarted.

The corresponding first test result may include at least one of: the CPU and memory utilization of the target node (e.g., actual CPU and memory utilization, normal, abnormal); an abnormal restart (e.g., yes, no) occurs for each service.

The stability of the target kernel can be represented by the virtual machine state of the target virtual machine and the node state of the target node. The virtual machine state and the node state are normal, the target kernel stability is good, and the virtual machine state and the node state are abnormal, and the target kernel stability is poor.

The following explains a node testing method in the embodiment of the present application with reference to an alternative example. In this example, the target node is a computing node configured by a new kernel version (the kernel version is not lower than the target kernel version) in the OpenStack distributed framework, and the target service module includes: nova and VGW.

The node testing method provided in the example is a computing node kernel stability testing method for cloud computing, based on an actual service scene of a virtual machine on a computing node, standard flow verification is established from two aspects of a physical machine and the virtual machine to ensure the stability of a new kernel version, an online environment is simulated as much as possible, the service scene is covered in multiple dimensions, the manual testing workload is low, and the test comprehensiveness and the test efficiency are considered.

As shown in fig. 3, the node testing method in this example may include the following steps:

and step S302, verifying the primary basic function.

Preliminary basic functional verification verified Nova automation and VGW network automation.

The existing Nova automated test case can be utilized to designate the computing node deployed by the new kernel version to start and run the automated case, and after the automated case is continuously run for 24 hours (the first time threshold), the states of the virtual machine and the computing node can be checked.

And operating on the computing node deployed by the new kernel version by using the existing VGW automatic test case of the target, and checking the states of the virtual machine and the computing node after continuously operating for 24h (a second time threshold).

The time required for the preliminary basic function verification was 2x24 h.

And step S304, simulating an online service scene, and testing the online service scene.

Operations may be performed on a virtual machine on a compute node, including: various migration scenarios (concurrent, round-trip, virtual machine internal operation different mode loads), and non-migration scenarios (different mode loads, internal I/O simultaneously mirror).

The custom mirror image with the Chaosblade tool installed in advance and the load script written in different modes (acting as the load modes) can be used for creating a plurality of virtual machines so as to simulate the online service scene by using the created plurality of virtual machines.

After a plurality of virtual machines are created, a part of the virtual machines can be selected to respectively execute internal different mode load scripts, such as full load, empty load, jump load and gradual change load, and when the internal continuous read-write operation of one virtual machine is selected, the nova-API is called to make a custom mirror image. After the operation is continued for 24h, the states of the virtual machines and the computing nodes can be checked.

Another part of virtual machines can be selected to not only internally execute load scripts in different modes, but also execute migration scripts on the computing nodes (single virtual machine/multiple virtual machines are simultaneously reciprocated, with/without data disk, two computing nodes/three nodes). After the operation is continued for 24h, the states of the virtual machines and the computing nodes can be checked.

The total time required to test the online traffic scenario is 2x24h (third time threshold).

Step S306, testing the special condition of the abnormal node.

The testing of the special condition of the node exception may be an operation performed on a physical machine, and the special condition of the node exception includes: abnormal memory leakage, repeated restart of nova service, and continuous data backup by connecting the distributed object storage cluster.

And (3) occupying a memory of the computing node by using a memtester tool, simulating memory leakage, recovering to be normal after continuously running for 24h (the first sub-time), and checking the states of the virtual machine and the computing node.

And controlling the abnormal nova-computer service on the computing node, repeatedly restarting, recovering to be normal after lasting for 24h, and checking the states of the virtual machine and the computing node.

And controlling the computing node to be connected with the distributed object storage cluster to continuously backup data, recovering to be normal after the data lasts for 24 hours, and checking the states of the virtual machine and the computing node.

The total time required to test for a special case of node anomaly is 2x24h (fourth time threshold).

The core stability test mode is to perform a stability test of 7x24h on a new version of a core of a compute node. Load pressure in different modes is made in a virtual machine running on a computing node by means of a chaosblade tool, and other tools or stress commands can be adopted to simulate the load. Similarly, the test for special cases of computing node abnormality can also be extended, such as node network abnormality, agent service repeated restart, and the like.

By the example, a set of standard test procedures are provided for the kernel stability test of the computing node of the cloud service: the method combines the automatic test and the functional test of the actual service, executes the stability test of 7x24h from a plurality of scenes of two dimensions of the virtual machine and the physical machine, not only ensures the basic function of the cloud service, but also covers the test scenes when the computing nodes normally run and are abnormal, changes the original single stability test form into more comprehensive and expandable, can continuously fine-tune the test range according to the continuous increase of the service, can not break away from the actual on-line environment and have significant omission, and ensures the test comprehensiveness and high efficiency.

It should be noted that, for simplicity of description, the above-mentioned method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the present application is not limited by the order of acts described, as some steps may occur in other orders or concurrently depending on the application. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required in this application.

Through the above description of the embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but the former is a better implementation mode in many cases. Based on such understanding, the technical solutions of the present application may be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal device (e.g., a mobile phone, a computer, a server, or a network device) to execute the method according to the embodiments of the present application.

According to another aspect of the embodiment of the present application, there is also provided a node testing apparatus for implementing the node testing method. Fig. 4 is a schematic diagram of an alternative node testing apparatus according to an embodiment of the present application, and as shown in fig. 4, the apparatus may include:

(1) a first testing unit 42, configured to test a target service module of a target node to obtain a first test result of a target kernel, where the target service module is configured to process a target service of the target node, and the target kernel is a kernel corresponding to the target node;

(2) a second testing unit 44, configured to test a target service scenario of a target virtual machine to obtain a second test result of the target kernel, where the target virtual machine is a virtual machine on the target node;

(3) a third testing unit 46, configured to test a node exception scenario of the target node to obtain a third testing result of the target kernel, where the testing result of the target kernel includes the first testing result, the second testing result, and the third testing result.

It should be noted that the first testing unit 42 in this embodiment may be configured to execute the step S202, the second testing unit 44 in this embodiment may be configured to execute the step S204, and the third testing unit 46 in this embodiment may be configured to execute the step S206.

Testing a target service module of a target node through the module to obtain a first test result of a target kernel, wherein the target service module is used for processing the target service of the target node, and the target kernel is a kernel corresponding to the target node; testing a target service scene of a target virtual machine to obtain a second test result of a target kernel, wherein the target virtual machine is a virtual machine on a target node; the node exception scene of the target node is tested to obtain a third test result of the target core, wherein the test result of the target core comprises the first test result, the second test result and the third test result, the problem that the test is incomplete due to the fact that the mode of computing the node core in the related art is limited by a test tool is solved, and the completeness of the node test is improved.

As an alternative embodiment, the first test unit 42 comprises:

the first acquisition module is used for acquiring a target test case, wherein the target test case is a test case of the target service module;

the first control module is used for controlling the target node to run the target test case to obtain a first test result, wherein the first test result is used for indicating the virtual machine state of the target virtual machine and the node state of the target node.

As an alternative embodiment, the target test case includes: a first test case, the first test case being a test case of a first service module of the target node,

the first control module includes:

the first control submodule is used for controlling the target node to run a first test case;

the first obtaining submodule is used for obtaining a first sub-test result under the condition that the running time of the first test case is greater than or equal to a first time threshold, wherein the first test result comprises the first sub-test result, and the first sub-test result is used for representing the virtual machine state of the target virtual machine and the node state of the target node.

As an alternative embodiment, the target test case includes: a second test case, which is a test case of the virtual gateway of the target node,

the first control module includes:

the second control submodule is used for controlling the target node to run a second test case;

and the second obtaining submodule is used for obtaining a second sub-test result under the condition that the running time of the second test case is greater than or equal to a second time threshold, wherein the first test result comprises the second sub-test result, and the second sub-test result is used for representing the virtual machine state of the target virtual machine and the node state of the target node.

As an alternative embodiment, the second test unit 44 comprises:

the second control module is used for controlling the target virtual machine to run a target service scene, wherein the target service scene comprises at least one of the following: the method comprises the following steps that a first service scene related to virtual machine migration and a second service scene unrelated to the virtual machine migration are obtained;

and the second obtaining module is used for obtaining a second test result under the condition that the running time of the target service scene is greater than or equal to a third time threshold, wherein the second test result is used for representing the virtual machine state of the target virtual machine and the node state of the target node.

As an alternative embodiment, the second control module comprises:

a third control sub-module, configured to control the plurality of first virtual machines to run the first service scenario when the target service scenario includes the first service scenario, where the target virtual machine includes the plurality of first virtual machines, and the first service scenario includes at least one of: the method comprises the following steps of performing round-trip migration on one virtual machine, performing concurrent round-trip migration on a plurality of virtual machines, calling virtual machine migration of one or more migration interfaces, and continuously migrating the virtual machines among a plurality of nodes in a virtual machine cluster, wherein each first virtual machine is used for running at least one first service scene in at least one load mode, and the load mode comprises at least one of the following modes: full load, empty load, jump load, gradual load.

As an alternative embodiment, the second control module comprises:

a fourth control sub-module, configured to control a first part of the multiple second virtual machines to run a first sub-service scenario when the target service scenario includes a second service scenario, where the target virtual machine includes the multiple second virtual machines, and the first sub-service scenario includes: operating a load in at least one load mode, the load mode comprising at least one of: full load, empty load, jump load, gradual load;

and the fifth control submodule is used for controlling a second part in the plurality of second virtual machines to run a second sub-service scene, wherein the second sub-service scene is a mirror image file manufactured under the condition that the reading and writing operations are continuously executed in the virtual machines, and the second service scene comprises a first sub-service scene and a second sub-service scene.

As an alternative embodiment, the apparatus further comprises:

the creating unit is used for creating the target virtual machine by using a target image file before testing a target service scene of the target virtual machine and obtaining a second test result of the target kernel, wherein a target load tool and load scripts of multiple load modes are pre-installed in the target image file, the target load tool is used for constructing the target service scene by using the load scripts, and the load modes include at least one of the following modes: full load, empty load, jump load, gradual load.

As an alternative embodiment, the third test unit 66 includes:

the third control module is used for controlling the target node to operate a node exception scene, wherein the node exception scene comprises at least one of the following scenes: the memory of the node is leaked, the second service module on the node is repeatedly restarted, and data is continuously backed up to a target cluster, and the target cluster is used for storing the data;

and the third obtaining module is used for obtaining a third test result under the condition that the running time of the node abnormal scene is greater than or equal to a fourth time threshold, wherein the third test result is used for representing the virtual machine state of the target virtual machine and the node state of the target node.

As an alternative embodiment, the third control module includes:

the occupation submodule is used for using a target memory tool to occupy the memory of the target node and continuously executing the first sub-time to obtain a third sub-test result, wherein the target memory tool is used for executing a memory pressure test;

the sixth control submodule is used for controlling the second service module to be repeatedly restarted and continuously executing the second sub-time to obtain a fourth sub-test result;

and the seventh control sub-module is used for controlling the target node to continuously backup the data to the target cluster and continuously execute the third sub-time to obtain a fifth sub-test result, wherein the third test result comprises a third sub-test result, a fourth sub-test result and a fifth sub-test result.

It should be noted here that the modules described above are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the disclosure of the above embodiments. It should be noted that the modules described above as a part of the apparatus may be operated in a hardware environment as shown in fig. 1, and may be implemented by software, or may be implemented by hardware, where the hardware environment includes a network environment.

According to another aspect of the embodiments of the present application, there is also provided an electronic device for implementing the node testing method, where the electronic device may be a server, a terminal, or a combination thereof.

Fig. 5 is a block diagram of an electronic device according to an embodiment of the present application, and as shown in fig. 5, the electronic device includes a memory 502 and a processor 504, the memory 502 stores a computer program therein, and the processor 504 is configured to execute the steps in any one of the method embodiments described above through the computer program.

Optionally, in this embodiment, the electronic apparatus may be located in at least one network device of a plurality of network devices of a computer network.

Optionally, in this embodiment, the processor may be configured to execute the following steps by a computer program:

s1, testing a target service module of the target node to obtain a first test result of a target kernel, wherein the target service module is used for processing the target service of the target node, and the target kernel is a kernel corresponding to the target node;

s2, testing the target service scene of the target virtual machine to obtain a second test result of the target kernel, wherein the target virtual machine is a virtual machine on the target node;

s3, testing the node exception scene of the target node to obtain a third test result of the target core, wherein the test result of the target core comprises the first test result, the second test result and the third test result.

Alternatively, it can be understood by those skilled in the art that the structure shown in fig. 5 is only an illustration, and the electronic device may also be a terminal device such as a smart device (e.g., an Android mobile phone, an iOS mobile phone, etc.), a tablet computer, a palmtop computer, and an MID (mobile internet Devices), a PAD, etc. Fig. 5 is a diagram illustrating a structure of the electronic device. For example, the electronic device may also include more or fewer components (e.g., network interfaces, etc.) than shown in FIG. 5, or have a different configuration than shown in FIG. 5.

The memory 502 may be used to store software programs and modules, such as program instructions/modules corresponding to the node testing method and apparatus in the embodiment of the present application, and the processor 504 executes various functional applications and data processing by running the software programs and modules stored in the memory 502, that is, implements the node testing method. The memory 502 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 502 may further include memory located remotely from the processor 504, which may be connected to the terminal over a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The memory 502 may be, but is not limited to, specifically configured to store data change record information of one or more objects.

As an example, as shown in fig. 5, the memory 502 may include, but is not limited to, the first test unit 42, the second test unit 44, and the third test unit 46 of the node test apparatus. In addition, other module units in the node testing apparatus may also be included, but are not limited to, and are not described in detail in this example.

Optionally, the transmission device 506 is used for receiving or sending data via a network. Examples of the network may include a wired network and a wireless network. In one example, the transmission device 506 includes a NIC (network interface Controller) that can be connected to a router via a network cable and other network devices so as to communicate with the internet or a local area network. In one example, the transmission device 506 is a Radio Frequency (RF) module, which is used for communicating with the internet in a wireless manner.

Furthermore, the electronic device may further include: a connection bus 508 for connecting the respective module components in the electronic apparatus.

Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments, and this embodiment is not described herein again.

Those skilled in the art will appreciate that all or part of the steps in the methods of the above embodiments may be implemented by a program instructing hardware associated with the terminal device, where the program may be stored in a computer-readable storage medium, and the storage medium may include: flash disks, ROM (Read-Only Memory), RAM (Random access Memory), magnetic or optical disks, and the like.

According to still another aspect of an embodiment of the present application, there is also provided a storage medium. Alternatively, in this embodiment, the storage medium may be a program code for executing the node testing method.

Optionally, in this embodiment, the storage medium may be located on at least one of a plurality of network devices in a network shown in the above embodiment.

Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps:

Optionally, the specific example in this embodiment may refer to the example described in the above embodiment, which is not described again in this embodiment.

Optionally, in this embodiment, the storage medium may include, but is not limited to: various media capable of storing program codes, such as a U disk, a ROM, a RAM, a removable hard disk, a magnetic disk, or an optical disk.

The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.

The integrated unit in the above embodiments, if implemented in the form of a software functional unit and sold or used as a separate product, may be stored in the above computer-readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or a part of or all or part of the technical solution contributing to the prior art may be embodied in the form of a software product stored in a storage medium, and including instructions for causing one or more computer devices (which may be personal computers, servers, network devices, or the like) to execute all or part of the steps of the method described in the embodiments of the present application.

In the above embodiments of the present application, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

In the several embodiments provided in the present application, it should be understood that the disclosed client may be implemented in other manners. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one type of division of logical functions, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, units or modules, and may be in an electrical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution provided in the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The foregoing is only a preferred embodiment of the present application and it should be noted that those skilled in the art can make several improvements and modifications without departing from the principle of the present application, and these improvements and modifications should also be considered as the protection scope of the present application.

Claims

1. A node testing method, comprising:

testing a target service module of a target node to obtain a first test result of a target kernel, wherein the target service module is used for processing the target service of the target node, and the target kernel is a kernel corresponding to the target node;

testing a target service scene of a target virtual machine to obtain a second test result of the target kernel, wherein the target virtual machine is a virtual machine on the target node;

and testing the node abnormal scene of the target node to obtain a third test result of the target kernel, wherein the test result of the target kernel comprises the first test result, the second test result and the third test result.

2. The method of claim 1, wherein the testing the target service module of the target node to obtain the first test result of the target core comprises:

acquiring a target test case, wherein the target test case is a test case of the target service module;

and controlling the target node to run the target test case to obtain the first test result, wherein the first test result is used for indicating the virtual machine state of the target virtual machine and the node state of the target node.

3. The method of claim 2,

the target test case comprises: a first test case, which is a test case of a first service module of the target node,

the controlling the target node to run the target test case, and obtaining the first test result includes:

controlling the target node to run the first test case;

and under the condition that the running time of the first test case is greater than or equal to a first time threshold, obtaining a first sub-test result, wherein the first test result comprises the first sub-test result, and the first sub-test result is used for representing the virtual machine state of the target virtual machine and the node state of the target node.

4. The method of claim 2,

the target test case comprises: a second test case, which is a test case of the virtual gateway of the target node,

controlling the target node to run the second test case;

and under the condition that the running time of the second test case is greater than or equal to a second time threshold, obtaining a second sub-test result, wherein the first test result comprises the second sub-test result, and the second sub-test result is used for representing the virtual machine state of the target virtual machine and the node state of the target node.

5. The method of claim 1, wherein the testing the target service scenario of the target virtual machine to obtain the second test result of the target kernel comprises:

controlling the target virtual machine to run the target service scenario, wherein the target service scenario includes at least one of: the method comprises the following steps that a first service scene related to virtual machine migration and a second service scene unrelated to the virtual machine migration are obtained;

and under the condition that the running time of the target service scene is greater than or equal to a third time threshold, obtaining the second test result, wherein the second test result is used for representing the virtual machine state of the target virtual machine and the node state of the target node.

6. The method of claim 5, wherein in the case that the target service scenario comprises the first service scenario, the controlling the target virtual machine to execute the target service scenario comprises:

under the condition that the target virtual machine comprises a plurality of first virtual machines, controlling the plurality of first virtual machines to run the first service scenario, wherein the first service scenario comprises at least one of the following: a round-trip migration of one virtual machine, a concurrent round-trip migration of a plurality of virtual machines, a virtual machine migration calling one or more migration interfaces, and a continuous migration of virtual machines among a plurality of nodes in a virtual machine cluster, wherein each first virtual machine is configured to run at least one first service scenario in at least one load mode, and the load mode includes at least one of: full load, empty load, jump load, gradual load.

7. The method of claim 5, wherein in the case that the target service scenario comprises the second service scenario, the controlling the target virtual machine to execute the target service scenario comprises:

under the condition that the target virtual machine comprises a plurality of second virtual machines, controlling a first part of the plurality of second virtual machines to run a first sub-business scenario, wherein the first sub-business scenario comprises: operating a load in at least one load mode, the load mode comprising at least one of: full load, empty load, jump load, gradual load;

and controlling a second part of the plurality of second virtual machines to run a second sub-service scene, wherein the second sub-service scene is a mirror image file manufactured under the condition that the reading and writing operations are continuously executed in the virtual machines, and the second service scene comprises the first sub-service scene and the second sub-service scene.

8. The method according to claim 1, wherein before the testing the target service scenario of the target virtual machine to obtain the second test result of the target kernel, the method further comprises:

creating the target virtual machine by using a target image file, wherein a target load tool and a load script of multiple load modes are pre-installed in the target image file, the target load tool is used for constructing the target service scene by using the load script, and the load modes comprise at least one of the following modes: full load, empty load, jump load, gradual load.

9. The method according to any one of claims 1 to 8, wherein the testing the node exception scenario of the target node to obtain the third test result of the target kernel comprises:

controlling the target node to run the node exception scenario, wherein the node exception scenario comprises at least one of: the memory of the node is leaked, the second service module on the node is repeatedly restarted, and data is continuously backed up to a target cluster, wherein the target cluster is used for storing the data;

and under the condition that the running time of the node abnormal scene is greater than or equal to a fourth time threshold, acquiring the third test result, wherein the third test result is used for representing the virtual machine state of the target virtual machine and the node state of the target node.

10. The method of claim 9, wherein the controlling the target node to execute the node exception scenario comprises:

using a target memory tool to occupy the memory of the target node, and continuously executing the first sub-time to obtain a third sub-test result, wherein the target memory tool is used for executing a memory pressure test;

controlling the second service module to restart repeatedly, and continuously executing the second sub-time to obtain a fourth sub-test result;

and controlling the target node to continuously backup data to the target cluster, and continuously executing a third sub-time to obtain a fifth sub-test result, wherein the third test result comprises the third sub-test result, the fourth sub-test result and the fifth sub-test result.

11. A node testing apparatus, comprising:

the system comprises a first testing unit, a second testing unit and a third testing unit, wherein the first testing unit is used for testing a target service module of a target node to obtain a first testing result of a target kernel, the target service module is used for processing a target service of the target node, and the target kernel is a kernel corresponding to the target node;

the second testing unit is used for testing a target service scene of a target virtual machine to obtain a second testing result of the target kernel, wherein the target virtual machine is a virtual machine on the target node;

and the third testing unit is used for testing the node exception scene of the target node to obtain a third testing result of the target kernel, wherein the testing result of the target kernel comprises the first testing result, the second testing result and the third testing result.

12. A computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to carry out the method of any one of claims 1 to 10 when executed.

13. An electronic device comprising a memory and a processor, characterized in that the memory has stored therein a computer program, the processor being arranged to execute the method of any of claims 1 to 10 by means of the computer program.