A test method, device, electronic device and storage medium

Abstract

Embodiments of the present application disclose a test method, device, electronic equipment and storage medium. The method comprises: obtaining an IP address set corresponding to a cloud platform to be tested; sending test configuration parameters, a test script and the IP address set to each cloud platform computing node, so that each cloud platform computing node selects a corresponding first type virtual machine according to the IP address set, and communicates with a second type virtual machine according to the test configuration parameters and the test script through the first type virtual machine to obtain a corresponding communication test result; determining a maximum bearable data amount corresponding to each cloud platform computing node according to the received communication test result, so as to determine the capacity of virtual machine IP that a single VPC can accommodate. Embodiments of the present application can increase the flow table routing item pressure in the host machine, find the problem of long delay and packet loss caused by the routing design defects of the cloud platform computing node, support large-scale virtual private cloud, find the capacity problem of large-scale virtual private cloud in advance, and predict potential business flow communication risks in advance.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a testing method, apparatus, electronic device, and storage medium. Background Technology

[0002] In traditional Layer 2 network environments, communication within the same broadcast domain relies on Address Resolution Protocol (ARP) caching and MAC address table communication. In cloud software-defined networking (SDN) models, the Layer 2 domain of a single Virtual Private Cloud (VPC) is a virtual network domain. Virtual machine communication relies on centralized management components and a distributed flow table structure on the host side (including models designed using OpenFlow distributed models and flow table-like structures) to achieve end-to-end address lookup. Broadcast issues are generally not present (except in virtual IP scenarios). When a single VPC accommodates a large number of virtual machines, communication between virtual machines still relies on the cloud platform's control plane automatically issuing flow tables to define communication paths. This presents two potential risks: firstly, the cloud platform's control plane has limited issuing capabilities, insufficient to support large-scale VPCs; secondly, in certain situations, when a virtual machine on a physical host needs to communicate with a large number of virtual machines within the same VPC, defects in the host's flow table model design may lead to excessive latency or even packet loss.

[0003] Moreover, traditional stress testing methods for calculating the routing capacity of host flow tables only use the ping tool to test point-to-point communication. This method can only test communication in point-to-point scenarios, and there is currently no relevant testing method to achieve the purpose of testing the routing capacity of host flow tables. It cannot test the upper limit of virtual machine network cards that a single large-scale VPC scenario can accommodate. In addition, due to the limited packet sending capability of the ping tool, even after encapsulation, it cannot be used as a high-efficiency method for sending N:N ping packets. Summary of the Invention

[0004] In view of this, the present invention provides a testing method, apparatus, electronic device and storage medium that can increase the routing pressure of the internal flow table of the host machine, discover problems such as excessive latency and packet loss caused by routing design defects of the PTZ computing node, realize support for large-scale virtual private clouds, discover capacity problems of large-scale virtual private clouds in advance, and predict potential business flow communication risks in advance.

[0005] According to one aspect of the present invention, an embodiment of the present invention provides a testing method, the method comprising:

[0006] Obtain the set of IP addresses corresponding to the cloud platform to be tested; wherein, the set of IP addresses includes the IP addresses corresponding to all virtual machines successfully created within the virtual private cloud corresponding to the cloud platform to be tested;

[0007] Test configuration parameters, test scripts, and the set of IP addresses are sent to each cloud platform computing node, so that each cloud platform computing node selects a corresponding first type virtual machine according to the set of IP addresses, and communicates with a second type virtual machine through the first type virtual machine according to the test configuration parameters and the test script to obtain the corresponding communication test results; wherein, each cloud platform computing node includes at least two virtual machines;

[0008] Based on the received communication test results, the maximum amount of data that each cloud platform computing node can bear is determined, thereby determining the capacity of a single VPC to accommodate virtual machine IPs.

[0009] According to another aspect of the present invention, embodiments of the present invention also provide a testing apparatus, the apparatus comprising:

[0010] The acquisition module is used to acquire the set of IP addresses corresponding to the cloud platform to be tested; wherein, the set of IP addresses includes the IP addresses corresponding to all virtual machines successfully created within the virtual private cloud corresponding to the cloud platform to be tested;

[0011] The result determination module is used to send test configuration parameters, test scripts, and the set of IP addresses to each cloud platform computing node, so that each cloud platform computing node selects a corresponding first type virtual machine according to the set of IP addresses, and communicates with a second type virtual machine through the first type virtual machine according to the test configuration parameters and the test script to obtain the corresponding communication test result; wherein, each cloud platform computing node includes at least two virtual machines;

[0012] The bearer determination module is used to determine the maximum amount of data that each cloud platform computing node can bear based on the received communication test results, thereby determining the capacity of a single VPC to accommodate virtual machine IPs.

[0013] According to another aspect of the present invention, embodiments of the present invention also provide an electronic device, the electronic device comprising:

[0014] At least one processor; and

[0015] A memory communicatively connected to the at least one processor; wherein,

[0016] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the test method described in any embodiment of the present invention.

[0017] According to another aspect of the present invention, embodiments of the present invention also provide a computer-readable storage medium storing computer instructions for causing a processor to execute and implement the test method described in any embodiment of the present invention.

[0018] According to another aspect of the present invention, embodiments of the present invention also provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the testing method described in any embodiment of the present invention.

[0019] The technical solution of this invention sends test configuration parameters, test scripts, and IP address sets to each cloud platform computing node. This enables each cloud platform computing node to select at least two first-type virtual machines based on the IP address set, and communicate with second-type virtual machines through these at least two first-type virtual machines. Based on the received communication test results, the maximum data volume that each cloud platform computing node can handle is determined, thereby determining the capacity of virtual machine IPs that a single VPC can accommodate. This increases the pressure on the routing entries in the host machine's internal flow table, solves the problems of excessive latency and packet loss caused by routing design flaws in cloud computing nodes, supports large-scale virtual private clouds, detects capacity issues in large-scale virtual private clouds in advance, and anticipates potential business flow communication risks.

[0020] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0022] Figure 1 A flowchart of a testing method provided in an embodiment of the present invention;

[0023] Figure 2 This is a schematic diagram illustrating a packet sending time interval according to an embodiment of the present invention;

[0024] Figure 3 A flowchart illustrating yet another testing method provided in an embodiment of the present invention;

[0025] Figure 4 This is a schematic diagram illustrating communication between a first type of virtual machine and a second type of virtual machine according to an embodiment of the present invention;

[0026] Figure 5 A flowchart illustrating yet another testing method provided in an embodiment of the present invention;

[0027] Figure 6 This is a schematic diagram of a packet sending time model provided in an embodiment of the present invention;

[0028] Figure 7 This is a structural block diagram of a testing device provided in an embodiment of the present invention;

[0029] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0030] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

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

[0032] In one embodiment, Figure 1 This is a flowchart of a testing method provided in an embodiment of the present invention. This embodiment is applicable to the situation of testing the capacity of host flow table routing. The method can be executed by a testing device, which can be implemented in hardware and / or software and can be configured in an electronic device.

[0033] like Figure 1 As shown, the specific steps include:

[0034] S110. Obtain the set of IP addresses corresponding to the cloud platform to be tested; wherein, the set of IP addresses includes the IP addresses corresponding to all virtual machines successfully created within the virtual private cloud corresponding to the cloud platform to be tested.

[0035] The cloud platform under test can be understood as a cloud platform awaiting capacity testing. This cloud platform may contain a platform management component and multiple cloud platform computing nodes. The Internet Protocol (IP) address set can be understood as the set of IP addresses corresponding to the virtual machine IP addresses created by calling the Application Programming Interface (API) from the platform management component.

[0036] In this embodiment, a corresponding virtual machine distribution strategy can be set on the cloud platform under test so that each computer node can contain multiple virtual machines. It can be understood that the cloud platform under test can provide a corresponding virtual machine distribution strategy. The distribution strategy corresponding to different cloud environments is generally different. The distribution strategy can select different methods to send virtual machines according to the scheduling strategy provided by each cloud vendor. It can be to distribute virtual machines in a certain order or according to a random order. This embodiment does not impose any restrictions here.

[0037] In this embodiment, the client can call the public API interface from the platform management component of the cloud platform under test to create tens of thousands of virtual machines within a VPC. After the virtual machines are created, the platform management component collects all successfully issued virtual machine IP addresses as an IP address set and sends this set to the client. This IP address set contains the IP addresses corresponding to all successfully created virtual machines within the virtual private cloud corresponding to the cloud platform under test. It should be noted that the number of virtual machines created within a VPC, i.e., the number of virtual machines that a VPC can accommodate, depends on the cloud environment corresponding to the cloud platform under test. For example, if cloud environment resources are sufficient, tens of thousands of virtual machines can be created directly; if cloud environment resources are insufficient, multiple virtual machines can be created by binding multiple network cards to a single virtual machine.

[0038] S120. Send test configuration parameters, test scripts, and IP address sets to each cloud platform computing node, so that each cloud platform computing node selects the corresponding first type virtual machine according to the IP address set, and communicates with the second type virtual machine through the first type virtual machine according to the test configuration parameters and test scripts to obtain the corresponding communication test results.

[0039] The stress test target for the cloud platform compute nodes is the host flow table, and each cloud platform compute node contains multiple successfully created virtual machines. Each cloud platform compute node includes at least two virtual machines executing the test.

[0040] In this embodiment, the test script can be understood as the packet sending interval set during testing. This packet sending interval can be controlled by a Shell script. By setting the packet sending interval, it can be ensured that the packet sending intervals of all virtual machine IPs performing packet sending operations on each cloud platform computing node are consistent and reach the corresponding first preset time interval. For example, the timed packet sending interval of the virtual machine performing packet sending operations can be set to 10 minutes or 15 minutes. This embodiment does not impose any restrictions here.

[0041] In this embodiment, the test configuration parameters refer to the test configuration parameters issued to the virtual machines performing packet sending operations during capacity testing. In some embodiments, the test configuration parameters include at least one of the following: the number of packet sending operations corresponding to each IP address; the packet sending interval between the first type of virtual machine IP address and other virtual machine IP addresses when performing packet sending operations; and the timeout duration between the first type of virtual machine IP address and other virtual machine IP addresses when performing packet sending operations. The other virtual machine IP addresses may include both the first type of virtual machine IP address and the second type of virtual machine IP address.

[0042] In this embodiment, the first type of virtual machine can be understood as the virtual machine selected by the client on each cloud platform computing node to perform packet sending operation. It should be noted that the platform management component distributes virtual machines to a cloud platform computing node, and the cloud platform computing node waits for all virtual machines to be created. On all the successfully distributed virtual machines, the client can select at least two virtual machines to perform packet sending operation on each cloud platform computing node according to the IP address set.

[0043] In this embodiment, the second type of virtual machine can be understood as any virtual machine in each cloud platform computing node other than the virtual machine that performs the packet sending operation. The second type of virtual machine is used to communicate with the first type of virtual machine.

[0044] In this embodiment, the client sends test configuration parameters, test scripts, and a set of IP addresses corresponding to the successfully created virtual machines to at least two virtual machines on each cloud platform compute node. This allows each cloud platform compute node to select at least two virtual machines corresponding to the IP addresses in the set as the first type of virtual machines. These first-type virtual machines then synchronously execute packet sending operations according to the test configuration parameters and test scripts sent by the client within the same test time period to communicate with the second-type virtual machines and obtain the corresponding communication test results. In this embodiment, the communication test results may include, but are not limited to, information such as the maximum latency, average latency, and total packet loss rate corresponding to the test.

[0045] In one embodiment, the total test duration reaches a first preset duration; the packet sending interval of each synchronous packet sending by the first type of virtual machine reaches a first preset time interval; and the packet sending interval between the IP address of the first type of virtual machine and other virtual machine IP addresses when the first type of virtual machine performs packet sending operation reaches a second preset time interval.

[0046] The first preset duration refers to the total test duration, which can be set manually or based on experience. The total test duration refers to the total duration of the test. Generally, the total test duration should be 24 hours or longer to detect physical network stability, host flow table stability, and other occasional network failures.

[0047] In this embodiment, the first preset time interval can be understood as the packet sending interval of the virtual machine performing the packet sending operation for synchronous packet sending. The first preset time interval can be controlled by a shell script. Usually, the first time interval is set relatively large. This first time interval can be set manually or based on experience. This embodiment does not impose any restrictions on this. For example, the first preset time interval can be set to 10 minutes, 15 minutes, 8 minutes, etc.

[0048] In this embodiment, the second preset time interval can be understood as the packet sending interval between the first type of virtual machine IP address and other virtual machine IP addresses when the first type of virtual machine IP address performs a packet sending operation, that is, the packet sending interval between two IP addresses. Typically, the second time interval is set relatively small. This second time interval can also be manually set or set based on experience. For example, the second preset time interval can be set to 100us, 80us, etc.

[0049] In this embodiment, the packet sending interval for each synchronization packet sent by the first type of virtual machine needs to reach a first preset time interval, and the packet sending interval between the IP address of the first type of virtual machine and other virtual machine IP addresses when the first type of virtual machine performs a packet sending operation needs to reach a second preset time interval. In this embodiment, to facilitate a better understanding of the difference between the first preset time interval and the second preset time interval, Figure 2 This is a schematic diagram of a packet sending time interval provided in an embodiment of the present invention, as shown below. Figure 2 As shown, the total test duration is greater than 24 hours; the first preset time interval is the execution timed packet sending interval in the figure, which is 10 minutes; the second preset time interval is the packet sending interval between every two IP addresses in the figure, that is, the packet sending interval between IP1, IP2, IP3 and IP4 in the figure, which can be 100us.

[0050] S130. Based on the received communication test results, determine the maximum amount of data that each cloud platform computing node can bear, thereby determining the capacity of a single VPC to accommodate virtual machine IPs.

[0051] The maximum data capacity can be understood as the maximum amount of data that the first type of virtual machine can carry when communicating with the second type of virtual machine during the total test duration.

[0052] In this embodiment, based on the pre-configured total test duration and information such as maximum latency, average latency, total latency, and total packet loss rate in the communication test results of all first-type virtual machines, the latency and packet loss within the total test duration can be analyzed according to the communication test results to determine the maximum data volume that each cloud platform computing node can bear, thereby determining the capacity of a single VPC to accommodate virtual machine IPs. In some embodiments, the average latency and total packet loss rate within a time interval can also be determined by using a first preset time interval, the number of packet losses within that time interval, and the latency within that time interval.

[0053] The technical solution of this invention sends test configuration parameters, test scripts, and IP address sets to each cloud platform computing node. This enables each cloud platform computing node to select at least two first-type virtual machines based on the IP address set, and communicate with second-type virtual machines through these at least two first-type virtual machines. Based on the received communication test results, the maximum data volume that each cloud platform computing node can handle is determined, thereby determining the capacity of virtual machine IPs that a single VPC can accommodate. This increases the pressure on the routing entries in the host machine's internal flow table, enabling the discovery of problems such as excessive latency and packet loss caused by design flaws in the mainstream flow table routing. This supports large-scale virtual private clouds, detects capacity issues in large-scale virtual private clouds in advance, and anticipates potential business flow communication risks.

[0054] In one embodiment, before obtaining the set of IP addresses corresponding to the cloud platform to be tested, the method further includes:

[0055] The target number of virtual machines is determined based on the environment parameters of the cloud platform to be tested; where the target number is equal to the total number of IP addresses contained in the IP address set.

[0056] Call the API interface to create the target number of virtual machines within the virtual private cloud corresponding to the cloud platform to be tested.

[0057] The target number can be understood as the maximum number of virtual machines in a single VPC that the cloud platform under test can support, or it can be understood as the number of virtual machines to be tested. For example, if the cloud platform under test can support 30,000 virtual machines in a single VPC, then the target number is 30,000.

[0058] In this embodiment, the target number of virtual machines to be created can be determined based on the environment parameters of the cloud platform under test. A certain number of virtual machines are created within a VPC by calling the public API interface of the cloud platform under test. This number is either greater than or equal to the total number of IP addresses contained in the IP address set, or the target number. In this embodiment, environment parameters can be understood as some attributes of the platform under test itself. The values ​​of the platform environment under test can be set manually, and some suggested values ​​can be set. The target number of virtual machines created is related to the size of the environment. It should be noted that the number of virtual machines created must be greater than or equal to the target number of virtual machines to be tested. Each successfully created virtual machine corresponds to a specific IP address to form an IP address set, and the number of IP address sets must at least reach the target number to be tested. For example, if the target number of virtual machines to be tested is 20,000 virtual machines for communication, at least 20,000 virtual machines need to be created for testing.

[0059] In one embodiment, Figure 3 This is a flowchart of another testing method provided in an embodiment of the present invention. Based on the above embodiments, this embodiment further refines the following steps: obtaining the IP address set corresponding to the cloud platform under test; selecting a corresponding first-type virtual machine for each cloud platform computing node according to the IP address set; communicating with a second-type virtual machine through the first-type virtual machine according to the test script and test configuration parameters to obtain the corresponding communication test results; and determining the maximum data volume that each cloud platform computing node can bear based on the received communication test results. Figure 3 As shown, the testing method in this embodiment may specifically include the following steps:

[0060] S310, Access the platform management component in the cloud platform to be tested.

[0061] Among them, the platform management component can be understood as the management component provided by the cloud platform under test to the client.

[0062] In this embodiment, the client can actively access the platform management component in the cloud platform under test and call the cloud platform's public API to create a virtual machine within a VPC.

[0063] S320. Obtain the IP addresses of all successfully created virtual machines from the platform management component, and use them as the corresponding IP address set.

[0064] In this embodiment, the client accesses the platform management component of the cloud platform under test to call the cloud platform's public API to create virtual machines within a VPC. The platform management component collects all successfully created virtual machine IP addresses as the corresponding IP address set and sends it to the client. It should be noted that the number of successfully created virtual machines in each cloud platform compute node can be the same or different, and the number of first-type virtual machines in each cloud platform compute node can also be the same or different. At least two first-type virtual machines are selected in each cloud platform compute node. For example, cloud platform compute node 1 contains 5 virtual machines, of which 2 are used for packet sending operations; cloud platform compute node 2 contains 4 virtual machines, of which 3 are used for packet sending operations; and cloud platform compute node 3 contains 8 virtual machines, of which 3 are used for packet sending operations.

[0065] S330. Select at least two virtual machines corresponding to IP addresses from the IP address set for each cloud platform computing node as the corresponding first type of virtual machine.

[0066] In this embodiment, the platform management component distributes virtual machines to each cloud platform computing node. Each cloud platform computing node waits for all virtual machines to be created and then remains idle for a period of time. This can be understood as each cloud platform computing node waiting for all virtual machines to be created and then remaining idle for a period of time to ensure that all virtual machine network cards in each cloud platform computing node can communicate normally. This is because, in some cases, when the platform side displays the virtual machine creation status as complete, the virtual machine network card corresponding to that virtual machine may not be able to communicate immediately.

[0067] In this embodiment, the client sends test configuration parameters, test scripts, and a set of IP addresses corresponding to the successfully created virtual machines to each cloud platform computing node, so that each cloud platform computing node can sequentially or randomly select at least two virtual machines corresponding to the IP addresses as the first type of virtual machine.

[0068] S340. During the same test period, packets are sent synchronously through the first type of virtual machine according to the test configuration parameters and test script to communicate with the second type of virtual machine and obtain the corresponding communication test results.

[0069] In this embodiment, the client sends test configuration parameters, test scripts, and IP address sets to each cloud platform compute node. On all cloud platform compute nodes that distribute virtual machines, each cloud platform compute node selects the corresponding first type of virtual machine based on the IP address set, that is, selects at least two virtual machines that perform packet sending operations and sets the same period (timed packet sending interval) for packet sending operations to be used as packet sending virtual machines for testing. During the same test time period, all packet sending virtual machines send packets synchronously, so that the virtual machines in the host are actively and passively communicating. It can be understood that the packet sending virtual machine communicates with all IPs in all VPCs multiple times to test the east-west and north-south traffic in the host. The total test duration must be greater than the first preset duration to obtain the corresponding communication test results.

[0070] It's important to note that virtual machines (VMs) on the same cloud platform compute node can be called co-hosted VMs, while VMs on different cloud platform compute nodes can be called dishosted VMs. In VPC communication scenarios, the communication paths between co-hosted and dishosted VMs often differ. By selecting at least two VMs on each cloud platform compute node and configuring them to perform the same scheduled packet sending operation to communicate with other VMs, both internal and external communication paths can be ensured. This can be understood as follows: the IP address ratio for packet sending by a single VM on each cloud platform compute node is 1:N, and the total IP address ratio for packet sending is M:N, where M is the sum of the number of VMs selected from all hosts to perform the packet sending operation.

[0071] In this embodiment, to achieve high-efficiency packet sending, packet sending can be performed using the CLI toolkit. Multiple subnets and IP list files can be set as input parameters for the CLI toolkit. Parameters such as the total test duration, the number of packet sending operations for each IP address, the packet sending interval between the first type of virtual machine IP address and other virtual machine IP addresses when performing packet sending operations, and the timeout duration for each ping of all IPs can be set.

[0072] To better understand the process within the same test period, at least two Type 1 virtual machines are selected from each cloud platform compute node to synchronously send packets according to the test configuration parameters and test scripts to communicate with Type 2 virtual machines. Figure 4 This is a schematic diagram illustrating communication between a first type of virtual machine and a second type of virtual machine according to an embodiment of the present invention, as shown below. Figure 4As shown, the cloud platform under test contains three cloud platform computing nodes, where virtual machines are represented by VMs (Virtual Machines). Two first-type virtual machines are selected from each cloud platform computing node to synchronously send packets according to the test configuration parameters and test script to communicate with second-type virtual machines. Cloud platform computing node 1 contains three virtual machines, namely VM1, VM2, and VM3; cloud platform computing node 2 contains three virtual machines, namely VM4, VM5, and VM6; and cloud platform computing node 3 contains three virtual machines, namely VM7, VM8, and VM9. VM1, VM2, VM4, VM5, VM7, and VM8 are selected as first-type virtual machines, which are the virtual machines that perform packet sending operations. That is, the IP address ratio of packet sending by a single virtual machine is 1:9, so the overall packet sending IP address ratio is 6:9. VM1 communicates with VM2, VM3, VM4, VM5, VM6, VM7, VM8, and VM9 respectively. VM2 communicates with VM1, VM3, VM4, VM5, VM6, VM7, VM8, and VM9 respectively. The communication between VM4, VM5, VM7, and VM8 follows the same pattern.

[0073] S350 determines the average latency and total packet loss rate for each cloud platform computing node based on the pre-configured total test duration, the total number of lost packets, and the total latency.

[0074] Average latency is a crucial indicator for ensuring network quality. Of course, average latency should be within a reasonable range; for example, it could be less than 1ms. Total packet loss refers to the percentage of all packet losses collected over the total test duration.

[0075] It should be noted that the total test duration reaches the first preset time, which can be set manually based on experience or other methods. The total test duration can be set from one day to several days, but the minimum time should be greater than 24 hours, which can detect the physical network stability to a great extent. The test configuration parameters can be set independently according to the cloud environment scenario.

[0076] In this embodiment, the average latency and total packet loss rate for each cloud platform computing node can be determined based on the pre-configured total test duration, the total number of lost packets received by the client, and the total latency. Specifically, each computing node contains at least two Type 1 virtual machines, generating multiple sets of test results within the total test duration. The results from all Type 1 virtual machines across all computing nodes are aggregated to obtain all corresponding aggregated results. The total packet loss rate is determined by the ratio of the total number of lost packets to the total number of sent packets in the aggregated results. Each set of data for each Type 1 virtual machine includes an average latency; the total average latency can be calculated by aggregating the average latency test results from all Type 1 virtual machines.

[0077] In this embodiment, since the packet sending interval of the first type of virtual machine each time it synchronously sends packets reaches the first preset time interval, the average latency and total packet loss rate corresponding to the time interval can be determined by the first preset time interval, that is, the time interval for performing timed packet sending, the number of packet losses in the time interval and the latency in the time interval.

[0078] S360 determines the maximum data volume that each cloud platform computing node can bear based on the average latency, total packet loss rate, and pre-configured maximum latency, thereby determining the capacity of a single VPC to accommodate virtual machine IPs.

[0079] The maximum latency can be understood as the maximum time taken for the virtual machine performing the packet sending operation to communicate with the second type of virtual machine from sending the packet. The maximum latency can be pre-configured manually or set based on experience; this embodiment does not impose any restrictions. Of course, the maximum latency should be within a reasonable range. For example, it can be set to 100ms. Generally, when the maximum latency exceeds 500ms, it can be considered too large.

[0080] In this embodiment, by statistically analyzing the total packet loss rate, if the total packet loss rate is 0 (meaning no packet loss during communication), the average latency of each cloud platform computing node is further checked through a full inspection or sampling inspection. If the average latency is within the pre-configured maximum latency range, then the maximum data volume that each cloud platform computing node can handle is the test capacity value. If packet loss or excessive maximum latency occurs during communication, further investigation is needed based on the detailed IP addresses of the lost packets to determine if it is an environmental issue or other problem. After resolving the issue, a retest can be performed. If the test results are the same, it can be inferred that the cloud platform computing node cannot handle the current test capacity. It should be noted that the average latency and maximum latency should be within a reasonable range to improve the accuracy of the test.

[0081] The above-described technical solution in this embodiment selects at least two virtual machines corresponding to IP addresses from the P address set for each cloud platform computing node as corresponding first-type virtual machines. During the same test period, the first-type virtual machines synchronously send packets according to the test configuration parameters and test scripts to communicate with the second-type virtual machines and obtain the corresponding communication test results. This tests the east-west and north-south traffic within the host, which can put sufficient pressure on the internal flow table routing entries of the host machine to detect any flow table routing design defects and other problems. By pre-configuring the total test duration, as well as the total number of lost packets and the total latency, the average latency and total packet loss rate corresponding to each cloud platform computing node are determined. Based on the average latency, total packet loss rate, and pre-configured maximum latency, the maximum data volume that each cloud platform computing node can bear is determined, thereby determining the capacity of virtual machine IPs that a single VPC can accommodate. This can detect physical network stability, host flow table stability, and other occasional network failures with a high probability.

[0082] In one embodiment, to facilitate a better understanding of the testing method, Figure 5 The flowchart of another testing method provided in an embodiment of the present invention can be used as a preferred embodiment to further illustrate the testing method. In this embodiment, the pre-configured total test duration is greater than 24 hours, the number of successfully created virtual machines is N, the virtual machines that perform the ping packet sending operation are first type virtual machines, and the other virtual machines that do not perform the packet sending operation are second type virtual machines. The number of virtual machines that perform the ping packet sending operation in all PTZ computer nodes is M, the average latency is within 1ms, the pre-configured maximum latency is 100ms, and the host flow table represents the platform computing node in the above embodiment.

[0083] In this embodiment, virtual machines are created primarily by the client calling the API interface from the platform management component. The platform management component collects all successfully issued virtual machine IP addresses and sends them to the client. The platform management component issues virtual machines to at least one host flow table. The host waits for all virtual machines to be created and then remains idle for a period of time to ensure that all virtual machine network cards can communicate normally. The client issues test tools, test scripts, and a set of IP addresses, selects the virtual machines to perform packet sending operations, and on all hosts that have issued virtual machines, at least two virtual machines on each host are selected and set to the same time interval to perform packet sending operations for testing. The packet sending virtual machines communicate multiple times with all IPs in all VPCs to test the east-west and north-south traffic within the host. The total test duration must be greater than 24 hours. The period of packet sending operations (timed packet sending interval), the timeout time for each packet sending, the number of ping packets sent by each IP, and the packet sending interval between two IPs are set independently according to the scenario. After each packet sending operation is completed, the test results of all virtual machines that initiated the execution command are collected, such as maximum latency, average latency, and total packet loss rate. The latency and packet loss situation over the entire time period are analyzed based on the results.

[0084] In this embodiment of the invention, when multiple single-point Type 1 virtual machines communicate 1:N with the IP addresses corresponding to all virtual machines within the same VPC, the pressure on the multi-layer flow table architecture forwarding can be increased, allowing for the detection of defects in the host forwarding layer. If packet loss and excessive latency are detected, it can be inferred that the flow table routing design may have issues such as caching efficiency, table lookup efficiency, excessive truncation of entries, and frequent fetching of forwarding data from the management component, thus enabling the early detection of potential VPC communication vulnerabilities.

[0085] like Figure 5 As shown, the testing method and specific steps are as follows:

[0086] a1. Based on the test cloud environment, call the cloud platform's public API to create a virtual machine for the target data within a VPC, and set the distribution strategy on the cloud platform side so that each compute node contains multiple virtual machines (>>2).

[0087] a2. Collect all successfully issued and created virtual machine IPs, and denote the total number of IPs as N, to form an IP address set.

[0088] a3. The platform management component distributes virtual machines to each cloud platform computing node. The cloud platform computing node needs to wait for all virtual machines to be created and then let it stand still for a period of time to ensure that all virtual machine network cards can communicate normally.

[0089] a4. The client distributes testing tools, test scripts, and IP address sets. At least two virtual machines on each host are selected and set to the same time interval to perform packet sending operations for testing. These packet sending virtual machines communicate multiple times with all IPs within all VPCs. In VPC communication scenarios, communication paths within the same host and between different hosts often differ to ensure both internal and external communication paths are included. The total test duration is greater than 24 hours to test physical network fluctuations. The time interval for executing packet sending operations, the timeout for each packet sending, the number of ping packets sent to each target IP, and the packet sending interval between two IPs can all be set according to the scenario.

[0090] In one embodiment, Figure 6 This is a schematic diagram of a packet sending time model provided in an embodiment of the present invention, as shown below. Figure 6 As shown, the total test duration is greater than 24 hours; the first preset time interval is the packet sending interval of 10 minutes as shown in the figure; the second preset time interval is the packet sending interval between every two IP addresses in the figure, that is, the packet sending interval between IP1, IP2, IP3 and IP4 in the figure, which can be 100us.

[0091] In this embodiment, each packet sending operation ensures that each virtual machine performing the packet sending operation sends ping packets to all virtual machine IP addresses collected in the previous steps. The ratio of IP addresses sent by a single virtual machine is 1:N, so the total ratio of IP addresses sent is M:N (M is the sum of virtual machines selected from all host machines to perform packet sending operations). The results of each command execution unit are recorded in a file.

[0092] a5. Collect test results from all virtual machines that initiate command execution, analyze latency and packet loss over the entire time period based on the results, and set parameters such as packet sending interval, number of ping packets sent from each IP address, and timeout duration for each ping to all IPs. After each packet sending operation is completed, provide summary statistics such as maximum latency, average latency, and total packet loss rate to analyze and statistically analyze ping packet results in a more concise and clear way.

[0093] In one embodiment, Figure 7 This is a structural block diagram of a testing device according to an embodiment of the present invention. This device is suitable for situations involving the pushing of goods and can be implemented in hardware or software. It can be configured in an electronic device to implement a testing method according to an embodiment of the present invention. Figure 7 As shown, the device includes: an acquisition module 710, a result determination module 720, and a load determination module 730.

[0094] The acquisition module 710 is used to acquire the set of IP addresses corresponding to the cloud platform to be tested; wherein, the set of IP addresses includes the IP addresses corresponding to all virtual machines successfully created within the virtual private cloud corresponding to the cloud platform to be tested.

[0095] The result determination module 720 is used to send test configuration parameters, test scripts, and the IP address set to each cloud platform computing node, so that each cloud platform computing node selects a corresponding first type virtual machine according to the IP address set, and communicates with a second type virtual machine through the first type virtual machine according to the test configuration parameters and the test script to obtain the corresponding communication test result; wherein, each cloud platform computing node includes at least two virtual machines;

[0096] The bearer determination module 730 is used to determine the maximum amount of data that each cloud platform computing node can bear based on the received communication test results, thereby determining the capacity of a single VPC to accommodate virtual machine IPs.

[0097] In this embodiment of the invention, the result determination module sends test configuration parameters, test scripts, and IP address sets to each cloud platform computing node, enabling each cloud platform computing node to select at least two corresponding first-type virtual machines based on the IP address set, and communicate with second-type virtual machines through at least two first-type virtual machines. The bearer determination module determines the maximum data volume that each cloud platform computing node can bear based on the received communication test results. This can increase the pressure on the routing entries in the host machine's internal flow table, solve the problems of excessive latency and packet loss caused by the design flaws of the mainstream flow table routing, support large-scale virtual private clouds, detect capacity problems in large-scale virtual private clouds in advance, and predict potential business flow communication risks in advance.

[0098] In one embodiment, the testing apparatus further includes:

[0099] The data determination module is used to determine the target number of virtual machines based on the environment parameters of the cloud platform under test before obtaining the set of IP addresses corresponding to the cloud platform under test; wherein, the target number is equal to the total number of IP addresses contained in the IP address set;

[0100] A module is created to call the API interface to create the target number of virtual machines within the virtual private cloud corresponding to the cloud platform under test.

[0101] In one embodiment, the acquisition module 710 includes:

[0102] The access unit is used to access the platform management components in the cloud platform under test.

[0103] The address creation unit is used to obtain the IP addresses corresponding to all successfully created virtual machines from the platform management component, and use them as the corresponding IP address set.

[0104] In one embodiment, the result determination module 720 includes:

[0105] The first type determination unit is used for each cloud platform computing node to select at least two virtual machines corresponding to IP addresses from the set of IP addresses as the corresponding first type virtual machines;

[0106] The second type determination unit is used to synchronously send packets through the first type virtual machine according to the test configuration parameters and the test script within the same test time period to communicate with the second type virtual machine and obtain the corresponding communication test results.

[0107] In one embodiment, the bearer determination module 730 includes:

[0108] The first determining unit is used to determine the average latency and total packet loss rate of each cloud platform computing node based on the pre-configured total test duration, the total number of lost packets and the total latency received, wherein the total test duration reaches a first preset time.

[0109] The second determining unit is used to determine the maximum amount of data that each cloud platform computing node can bear based on the average latency, the total packet loss rate and the pre-configured maximum latency, thereby determining the capacity of a single VPC to accommodate virtual machine IPs.

[0110] In one embodiment, the total test duration reaches a first preset duration; the packet sending interval of each synchronous packet sending by the first type of virtual machine reaches a first preset time interval; and the packet sending interval between the IP address of the first type of virtual machine and other virtual machine IP addresses when the first type of virtual machine performs packet sending operation reaches a second preset time interval.

[0111] In one embodiment, the test configuration parameters include at least one of the following: the number of packets sent for each IP address; the packet sending interval between the first type of virtual machine IP address and other virtual machine IP addresses when performing packet sending operations; and the timeout duration between the first type of virtual machine IP address and other virtual machine IP addresses when performing packet sending operations.

[0112] The testing apparatus provided in the embodiments of the present invention can execute the testing methods provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects for executing the methods.

[0113] In one embodiment, Figure 8This is a schematic diagram of an electronic device provided for an embodiment of the present invention. The electronic device 10 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0114] like Figure 8 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0115] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0116] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as test methods.

[0117] In some embodiments, the test method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the test method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to execute the test method by any other suitable means (e.g., by means of firmware).

[0118] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0119] Computer programs used to implement the methods of the present invention can be written in any combination of one or more programming languages. These computer programs can be provided to the processor of a general-purpose computer, a special-purpose computer, or other programmable test apparatus, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs can be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0120] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0121] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0122] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0123] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0124] In one embodiment, the present invention further includes a computer program product, the computer program product comprising a computer program that, when executed by a processor, implements the testing method described in any embodiment of the present invention.

[0125] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0126] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0127] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A testing method, characterized in that, include: Obtain the set of IP addresses corresponding to the cloud platform to be tested; wherein, the set of IP addresses includes the IP addresses corresponding to all virtual machines successfully created within the virtual private cloud corresponding to the cloud platform to be tested; the cloud platform to be tested includes multiple cloud platform computing nodes; wherein, virtual machines in the same cloud platform computing node are virtual machines with the same host, and virtual machines in different cloud platform computing nodes are virtual machines with different hosts. Test configuration parameters, test scripts, and the set of IP addresses are sent to each cloud platform computing node, so that each cloud platform computing node selects a corresponding first type virtual machine according to the set of IP addresses, and communicates with a second type virtual machine through the first type virtual machine according to the test configuration parameters and the test script to obtain the corresponding communication test results; wherein, each cloud platform computing node includes at least two virtual machines; Based on the received communication test results, determine the maximum amount of data that each cloud platform computing node can carry, thereby determining the capacity of a single VPC to accommodate virtual machine IPs; The step of enabling each cloud platform computing node to select a corresponding first type virtual machine based on the IP address set, and then communicating with a second type virtual machine through the first type virtual machine according to the test configuration parameters and the test script to obtain the corresponding communication test results includes: Each cloud platform computing node selects at least two virtual machines corresponding to IP addresses from the set of IP addresses as the corresponding first type of virtual machine; During the same test period, packets are sent synchronously through the first type of virtual machine according to the test configuration parameters and the test script to communicate with the second type of virtual machine and obtain the corresponding communication test results.

2. The method according to claim 1, characterized in that, Before obtaining the set of IP addresses corresponding to the cloud platform to be tested, the following steps are also included: The target number of virtual machines is determined based on the environment parameters of the cloud platform to be tested; wherein, the target number is equal to the total number of IP addresses contained in the IP address set; Call the API interface to create the target number of virtual machines within the virtual private cloud corresponding to the cloud platform under test.

3. The method according to claim 1 or 2, characterized in that, The process of obtaining the set of IP addresses corresponding to the cloud platform to be tested includes: Access the platform management components in the cloud platform to be tested; Obtain the IP addresses of all successfully created virtual machines from the platform management component, and use them as the corresponding IP address set.

4. The method according to claim 1 or 2, characterized in that, The step of determining the maximum data volume that each cloud platform computing node can carry based on the received communication test results includes: The average latency and total packet loss rate of each cloud platform computing node are determined based on the pre-configured total test duration, the total number of lost packets, and the total latency, wherein the total test duration reaches a first preset time. The maximum data volume that each cloud platform computing node can carry is determined based on the average latency, the total packet loss rate, and the pre-configured maximum latency.

5. The method according to claim 1 or 2, characterized in that, The test configuration parameters include at least one of the following: the number of packets sent for each IP address; the packet sending interval between the first type of virtual machine IP address and other virtual machine IP addresses when the first type of virtual machine IP address performs a packet sending operation; and the timeout duration between the first type of virtual machine IP address and other virtual machine IP addresses when the first type of virtual machine IP address performs a packet sending operation.

6. The method according to claim 4, characterized in that, The total test duration reaches the first preset duration; the packet sending interval of each synchronous packet sending by the first type of virtual machine reaches the first preset time interval; the packet sending interval between the IP address of the first type of virtual machine and other virtual machine IP addresses when the first type of virtual machine performs packet sending operation reaches the second preset time interval.

7. A testing apparatus, characterized in that, include: The acquisition module is used to acquire the set of IP addresses corresponding to the cloud platform to be tested; wherein, the set of IP addresses includes the IP addresses corresponding to all virtual machines successfully created within the virtual private cloud corresponding to the cloud platform to be tested; the cloud platform to be tested includes multiple cloud platform computing nodes; wherein, virtual machines in the same cloud platform computing node are virtual machines with the same host, and virtual machines in different cloud platform computing nodes are virtual machines with different hosts. The result determination module is used to send test configuration parameters, test scripts, and the set of IP addresses to each cloud platform computing node, so that each cloud platform computing node selects a corresponding first type virtual machine according to the set of IP addresses, and communicates with a second type virtual machine through the first type virtual machine according to the test configuration parameters and the test script to obtain the corresponding communication test result; wherein, each cloud platform computing node includes at least two virtual machines; The bearer determination module is used to determine the maximum amount of data that each cloud platform computing node can bear based on the received communication test results, thereby determining the capacity of a single VPC to accommodate virtual machine IPs. The result determination module includes: The first type determination unit is used for each cloud platform computing node to select at least two virtual machines corresponding to IP addresses from the set of IP addresses as the corresponding first type virtual machines; The second type determination unit is used to synchronously send packets through the first type virtual machine according to the test configuration parameters and the test script within the same test time period to communicate with the second type virtual machine and obtain the corresponding communication test results.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the test method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the test method according to any one of claims 1-6.

Images