Cloud network simulation test system, method, device, storage medium and program product

Abstract

The application discloses a cloud network simulation test system, method, equipment, storage medium and program product, the test system comprises a calculation simulation module, a network agent simulation module and a test module, the calculation simulation module utilizes an application program interface to create at least one simulation calculation node of a measured system, and provides network environment configuration and life cycle management functions for each simulation calculation node; the network agent simulation module deploys at least one simulation network agent component for each simulation calculation node, and executes the information interaction process of the simulation calculation node and the control plane of the measured system through the simulation network agent component; the test module tests the simulation environment constructed, and generates a test result. The test system can simulate large-scale calculation nodes with less physical resources, quickly build an SDN control plane test environment, improve the efficiency and feasibility of large-scale cloud network testing, and adapt to the demand of an intelligent computing center for large-scale, low-latency and high-bandwidth cloud networks.

Description

Technical Field

[0001] This invention relates to the field of cloud computing, and in particular to a cloud network simulation testing system, method, device, storage medium, and program product. Background Technology

[0002] The booming development of the artificial intelligence industry has provided tremendous opportunities for the construction and development of intelligent computing centers. As core infrastructure, intelligent computing centers undertake critical tasks such as AI model training and large-scale data processing. Their computing power requirements of "tens of thousands of cards" of clusters have redefined the performance and scale of cloud networks. Cloud networks are dedicated networks adapted to the scenarios of intelligent computing centers, and they not only need to meet the requirements of low latency and high bandwidth transmission, but also need to have the ability to support large-scale management of tens of thousands or even hundreds of thousands of computing nodes. However, when verifying whether cloud networks, especially SDN (Software Defined Network) control planes, meet the above-mentioned large-scale scenario requirements, real physical nodes are usually used for testing. Deploying real nodes requires a large number of physical servers, and the deployment cost increases exponentially with the scale of nodes. Furthermore, the deployment of real nodes involves multiple stages such as server initialization, operating system installation, network component configuration, and service cluster construction. It takes weeks or even months to complete the environment setup for tens of thousands of nodes, and the deployment cycle is far from matching the rapid iteration construction needs of intelligent computing centers. In addition, real node testing also suffers from problems such as low resource reuse rate and poor flexibility in adjusting test scenarios, which further restricts the efficiency and feasibility of large-scale cloud network testing. Summary of the Invention

[0003] The purpose of this invention is to provide a cloud network simulation testing system, method, device, storage medium, and program product. Through computational simulation, network proxy simulation, and test service collaboration, it can simulate large-scale computing nodes with fewer physical resources, quickly build an SDN control plane test environment, improve the efficiency and feasibility of large-scale cloud network testing, and adapt to the needs of intelligent computing centers for large-scale, low-latency, and high-bandwidth cloud networks.

[0004] To achieve the above objectives, embodiments of the present invention provide a cloud network simulation testing system, comprising:

[0005] The computational simulation module is used to create at least one simulated computing node of the system under test using an application programming interface (API), and to provide network environment configuration and lifecycle management functions for each simulated computing node; wherein, the system under test is a cloud network management and control system built on software-defined networking.

[0006] The network proxy simulation module is used to deploy at least one simulated network proxy component for each simulated computing node, and to execute the information interaction process between the simulated computing node and the control plane of the system under test through the simulated network proxy component.

[0007] The testing module is used to test the simulation environment constructed by the computation simulation module and the network proxy simulation module, and generate test results.

[0008] As an improvement to the above scheme, the computational simulation module includes:

[0009] An interface unit is used to provide interface services for the application programming interface (API) to receive lifecycle management requests from simulated computing nodes through the API.

[0010] The configuration unit is used to perform corresponding lifecycle management functions on the simulated computing node according to the lifecycle management request, and to create the simulated computing node and configure the network environment of the newly created simulated computing node when the lifecycle management request is a node creation request.

[0011] As an improvement to the above scheme, the lifecycle management request includes at least one of node creation request, node deletion request, node query request, node configuration update request, node enable request, and node deactivation request; the network environment configuration includes at least one of network namespace configuration, virtual port configuration, and routing configuration.

[0012] As an improvement to the above solution, the simulated network proxy component provides pseudo-proxy services and / or lightweight proxy services; wherein, the pseudo-proxy service provides complete information interaction logic with the control plane; and the lightweight proxy service provides basic information interaction logic with the control plane.

[0013] As an improvement to the above solution, both the pseudo-proxy service and the lightweight proxy service can provide at least one of the following functions:

[0014] Establish a communication connection with the distributed coordination server; wherein the distributed coordination server is associated with the application programming interface server of the system under test;

[0015] Periodically write timestamps to the node paths of the distributed coordination server;

[0016] Monitor network layer resource update operations.

[0017] As an improvement to the above solution, the pseudo-proxy service also provides the function of data interaction with the simulated virtual switch.

[0018] As an improvement to the above solution, the function of interacting with the simulated virtual switch includes at least one of the following functions:

[0019] Request port information from the simulated virtual switch;

[0020] Send update instructions for flow table information and / or group information to the simulated virtual switch;

[0021] Forward the data packet output request to the simulated virtual switch;

[0022] Request residual flow table information from the simulated virtual switch.

[0023] As an improvement to the above solution, the testing module includes:

[0024] The data plane traffic monitoring unit is used to receive traffic monitoring requests and send monitoring parameters to the data plane device of the system under test to start the monitoring service;

[0025] A cluster scheduling unit is used to concurrently create virtual private networks and ports, and allocate simulated network proxy components to each tenant; wherein the resources of the tenant are distributed on at least one simulated computing node;

[0026] The resource test scenario creation unit is used to configure business resource parameters and create network layer resources;

[0027] An exception simulation unit is used to simulate abnormal conditions of system components and / or system services through service restart operations;

[0028] The operation check unit is used to check the operating status of the system components and / or the system services.

[0029] As an improvement to the above solution, the cloud network simulation testing system further includes:

[0030] The deployment module is used to set up the simulation environment and perform initialization operations.

[0031] To achieve the above objectives, embodiments of the present invention also provide a cloud network simulation testing method, comprising:

[0032] At least one simulated computing node of the system under test is created using an application programming interface (API), and network environment configuration and lifecycle management functions are provided for each simulated computing node; wherein, the system under test is a cloud network management and control system built on software-defined networking.

[0033] Deploy at least one simulated network proxy component for each simulated computing node, and perform the information interaction process between the simulated computing node and the control plane of the system under test through the simulated network proxy component;

[0034] The simulation environment constructed by the simulated computing node and the simulated network proxy component is tested, and test results are generated.

[0035] As an improvement to the above solution, the method further includes:

[0036] Set up the simulation environment and perform initialization operations.

[0037] To achieve the above objectives, embodiments of the present invention also provide a cloud network simulation testing device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements the cloud network simulation testing method as described in any of the above embodiments.

[0038] To achieve the above objectives, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, wherein the computer program, when running, controls the device where the computer-readable storage medium is located to execute the cloud network simulation testing method as described in any of the above embodiments.

[0039] To achieve the above objectives, embodiments of the present invention also provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements the cloud network simulation testing method as described in any of the above embodiments.

[0040] Compared to existing technologies, the cloud network simulation testing system, method, equipment, storage medium, and program products disclosed in this invention construct simulation units highly similar to real cloud network computing nodes through a computational simulation module. This provides computational support for the entire simulation test that closely resembles real-world scenarios, making subsequent tests based on these simulation nodes more realistic and valuable for reference. The network proxy simulation module establishes an information channel between the simulated computing nodes and the control plane, ensuring that the linkage between computation and control in the simulation environment is consistent with real cloud network scenarios. This makes the entire simulation environment more realistic at the network interaction level, providing a realistic network interaction scenario for the testing module. The testing module comprehensively checks the entire simulation environment, and the generated test results clearly reveal the operational status of the cloud network control system in the simulated scenario, identifying potential functional defects and performance bottlenecks. This provides strong evidence for the optimization and improvement of the cloud network control system, ensuring the stable and efficient operation of the real cloud network environment. The cloud network simulation testing system disclosed in this invention can simulate large-scale computing nodes with fewer physical resources, quickly building an SDN control plane test environment, improving the efficiency and feasibility of large-scale cloud network testing, and adapting to the needs of intelligent computing centers for large-scale, low-latency, and high-bandwidth cloud networks. Attached Figure Description

[0041] Figure 1 This is a structural block diagram of the cloud network simulation and testing system provided in this embodiment of the invention;

[0042] Figure 2 This is a structural block diagram of the computational simulation module provided in an embodiment of the present invention;

[0043] Figure 3 This is another structural block diagram of the cloud network simulation and testing system provided in this embodiment of the invention;

[0044] Figure 4 This is an application diagram of the network proxy simulation module provided in an embodiment of the present invention;

[0045] Figure 5 This is a schematic diagram illustrating the information interaction between the pseudo-proxy service and the simulated virtual switch provided in an embodiment of the present invention;

[0046] Figure 6 This is a structural block diagram of the test module provided in an embodiment of the present invention;

[0047] Figure 7 This is a flowchart of the cluster scheduling unit in the test module provided in this embodiment of the invention;

[0048] Figure 8 This is a flowchart of the deployment module provided in an embodiment of the present invention;

[0049] Figure 9 This is a flowchart of a cloud network simulation testing method provided in an embodiment of the present invention;

[0050] Figure 10 This is a structural block diagram of a cloud network simulation test device provided in an embodiment of the present invention. Detailed Implementation

[0051] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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 are within the scope of protection of the present invention.

[0052] See Figure 1 , Figure 1 This is a structural block diagram of a cloud network simulation testing system 100 provided in an embodiment of the present invention. The cloud network simulation testing system 100 includes:

[0053] The computational simulation module 10 is used to create at least one simulated computing node of the system under test using an application programming interface, and to provide network environment configuration and lifecycle management functions for each simulated computing node; wherein, the system under test is a cloud network management and control system built on software-defined networking;

[0054] The network proxy simulation module 20 is used to deploy at least one simulated network proxy component for each simulated computing node, and to perform the information interaction process between the simulated computing node and the control plane of the system under test through the simulated network proxy component.

[0055] The test module 30 is used to test the simulation environment constructed by the computation simulation module and the network proxy simulation module, and generate test results.

[0056] It should be noted that the system under test in this embodiment of the invention is a cloud network management and control system built on Software Defined Networking (SDN). The core of SDN is to use software to achieve flexible management and control of the network through an architecture that separates the control plane from the data plane, breaking the limitations of traditional network hardware being fixed and having complex configurations.

[0057] The computational simulation module 10 is used to replace the OpenStack Nova service in a real software-defined networking (SDN) system, thereby decoupling network data plane testing from the Nova component. OpenStack Nova is a core component of the open-source cloud computing platform OpenStack, responsible for managing the entire lifecycle of all virtual machines (real compute nodes) in the cloud environment, including virtual machine creation, startup, shutdown, and deletion. It is the core of computing resource management in a real cloud environment. This invention replicates the core functionality of OpenStack Nova using the computational simulation module 10, allowing cloud network testing to operate without relying on a real Nova environment or incurring the cost of building real hardware. This completes the decoupling from Nova, enabling large-scale testing at a lower cost and faster speed, ultimately improving testing efficiency.

[0058] The network agent simulation module 20 replaces the OVS Agent (Open vSwitch Agent, a virtual switch instance) of a real software-defined networking (SDN) system, thereby simulating a large scale of compute nodes with fewer physical resources. The OVS Agent is responsible for performing operations related to the virtual switch on the compute nodes, such as managing virtual ports (ovs ports), configuring flow tables, and handling packet forwarding. It is a key component for communication between the compute nodes and the SDN controller, as well as for the network functions of the compute nodes. This invention uses the network agent simulation module 20 to simulate these functions, mimicking its behavior and functionality without relying on the real OVS Agent, enabling the simulated compute nodes to possess network capabilities similar to real compute nodes in the simulation environment.

[0059] In this embodiment of the invention, a simulation unit highly similar to a real cloud network computing node is constructed through the computational simulation module 10, providing computational support close to the actual scenario for the entire simulation test, making subsequent tests based on these simulation nodes more realistic and valuable for reference. The network proxy simulation module 20 establishes an information channel between the simulated computing nodes and the control plane, ensuring that the linkage between computation and control in the simulation environment is consistent with the real cloud network scenario, making the entire simulation environment closer to reality at the network interaction level, and providing a realistic network interaction scenario for the testing module. The testing module 30 performs a comprehensive check on the entire simulation environment. Through the generated test results, the operating status of the cloud network control system in the simulation scenario can be clearly understood, identifying potential functional defects, performance bottlenecks, and other problems, providing strong evidence for the optimization and improvement of the cloud network control system, and ensuring the stable and efficient operation of the real cloud network environment. The cloud network simulation testing system 100 disclosed in this invention can simulate a large number of computing nodes with fewer physical resources, quickly build an SDN control plane test environment, improve the efficiency and feasibility of large-scale cloud network testing, and adapt to the needs of intelligent computing centers for large-scale, low-latency, and high-bandwidth cloud networks.

[0060] See Figure 2 , Figure 2 This is a structural block diagram of the computational simulation module 10 provided in an embodiment of the present invention. The computational simulation module 10 includes:

[0061] Interface unit 11 is used to provide interface services for the application programming interface (API) to receive lifecycle management requests from the simulated computing node through the API.

[0062] Configuration unit 12 is used to perform corresponding lifecycle management functions on the simulated computing node according to the lifecycle management request, and when the lifecycle management request is a node creation request, to create the simulated computing node and configure the network environment of the newly created simulated computing node.

[0063] It should be noted that the computational simulation module 10 belongs to the control plane and a part of the data plane components in the entire cloud network simulation test system 100. Simulated computing nodes simulate real computing nodes in the system under test. For example, a simulated computing node can be a virtual machine, while a real computing node is a physical server or virtual machine that carries actual business loads, runs real network proxy components, and directly participates in data forwarding. Simulated computing nodes, on the other hand, are virtual nodes built in the test environment. Their hardware resources and network environment are logical abstractions, used only to simulate the network behavior of real nodes (such as receiving control plane instructions and reporting status), and do not carry actual business. The role of simulated computing nodes is to replace real computing nodes in the test scenario, allowing the cloud network control system (control plane + data plane) to undergo complete process testing without deploying real hardware.

[0064] For example, interface unit 11 is a functional component in the computing simulation module 10 responsible for providing standardized interface services to the outside world. Its core function is to expose the Application Programming Interface (API) as the entry point for external (such as users, test modules, or management platforms) interaction with the system, specifically receiving and parsing various requests related to the lifecycle management of simulated computing nodes. Configuration unit 12 is a functional component in the computing simulation module 10 responsible for executing specific management operations. After receiving the lifecycle management requests forwarded by interface unit 11, it completes the corresponding operations and is the executor of the actual management logic of simulated computing nodes. Interface unit 11 and configuration unit 12 exchange information through a message middleware, such as NATS (Cloud Native Messaging System), which is used to store and transmit test-related data. When interface unit 11 receives a lifecycle management request, it writes the information that needs to be persisted (such as node configuration and status) into the DB (Database). It can also read historical data from the DB to support business logic. Then, interface unit 11 sends the lifecycle management request for the simulated computing node to NATS. After receiving the instruction sent by interface unit 11, NATS routes and distributes it to the corresponding configuration unit 12. Multiple configuration units 12 can receive messages from NATS at the same time to achieve distributed processing. After the configuration unit 12 completes the corresponding request, it can send the operation result or node status information back to interface unit 11 through NATS so that interface unit 11 can perform subsequent processing (such as feedback to the requester).

[0065] For example, when interface unit 11 receives a request to create a simulated computing node (simulated virtual machine), it will perform message processing and routing according to the following steps:

[0066] 1) Based on the request content, interface unit 11 generates a message containing Action (e.g., CreateNode), DstNode (hostname of the simulated computing node), CorrelationID (generated unique association identifier), and payload (inserting the business data required to create the simulated computing node, such as the simulated computing node name, number of CPU cores, memory size, network configuration, etc.).

[0067] 2) Send this message through the NATS message middleware and register a Reply topic at the same time. It can usually be named in combination with information such as CorrelationID for easy identification later.

[0068] 3) After receiving the message, the configuration unit 12 parses the Action to learn that the operation of creating a simulated computing node needs to be performed, extracts business data from the payload, and completes the creation of the simulated computing node and other related processing.

[0069] 4) After processing is complete, the configuration unit 12 sends a message containing the same CorrelationID and indicating that the operation was successful to the Reply topic registered by the interface unit 11;

[0070] 5) After receiving the success message by listening to the Reply topic, the interface unit 11 matches the corresponding creation request according to the CorrelationID and confirms that the simulation computing node creation operation has been successfully completed.

[0071] In this embodiment of the invention, the architecture of the computation simulation module 10 achieves asynchronous communication and decoupling between components through NATS, making the system more scalable. In addition, the number of configuration units 12 can be flexibly increased to cope with large-scale requests. At the same time, the database ensures the persistence and consistency of data, making it suitable for scenarios such as cloud network simulation testing that require large-scale, distributed management of simulation computing nodes.

[0072] Furthermore, lifecycle management refers to the operation instructions for the entire lifecycle of a simulated computing node (from creation to destruction); wherein, the lifecycle management request includes at least one of node creation request, node deletion request, node query request, node configuration update request, node enable request, and node de-enable request.

[0073] For example, when interface unit 11 receives a node creation request, it sends a message containing the Action "CreateNode" to configuration unit 12 via message middleware. After receiving the message, configuration unit 12 parses it and executes the node initialization logic. If it is a node deletion request, the message Action is set to "DeleteNode". After receiving the request, configuration unit 12 cleans up the network namespace, virtual port, and other resources associated with the node and returns the operation result through a Reply topic. If it is a node query request, the message Action is set to "QueryNode". After receiving the request, configuration unit 12 queries the current status of the node (e.g., running / already) from the database or local cache. Information such as stop), resource utilization, and associated virtual port list; if it is a node configuration update request, the message Action is set to UpdateConfig, and the adjustment values ​​of resource parameters such as CPU and memory can be passed through the payload, and the configuration unit 12 completes the configuration update of the simulated computing node; if it is a node enable request, the message Action is set to StartNode, and after receiving the request, the configuration unit 12 enables the node and updates the node status from "stopped" to "running"; if it is a node stop enable request, the message Action is set to StopNode, and after receiving the request, the configuration unit 12 shuts down the node and updates the node status from "running" to "stopped".

[0074] Furthermore, network environment configuration refers to the process of allocating network-related parameters to simulated computing nodes, thereby integrating them into the simulated network topology. This network environment configuration includes at least one of network namespace configuration, virtual port configuration, and routing configuration.

[0075] For example, when creating a simulated computing node, the configuration unit 12 performs network environment configuration according to the port information specified in the message. First, it creates a Linux network namespace to achieve network isolation from other virtual instances; second, it creates an OVS virtual port and binds the port to the newly created namespace to establish a connection between the virtual instance and the simulated switch; finally, it configures default routing rules to ensure that the virtual instances in this namespace can communicate with other network nodes, thereby completing the network access configuration of the virtual instance in the simulated network.

[0076] See Figure 3 , Figure 3 This is another structural block diagram of the cloud network simulation test system 100 provided in this embodiment of the invention. The specific working process of the test module 30 and the deployment module 40 will be given in detail later. Here, the workflow of the client, control plane and data plane will be explained.

[0077] The client, located at the top layer of the architecture, serves as the entry point for interaction between users (or automated testing programs) and the system. Users initiate testing operations on the cloud network through the client, such as sending requests to create simulated computing nodes or configure the network, thus triggering the entire simulation testing process.

[0078] The Control Plane is responsible for the system's logical control and command distribution. It serves as the core hub connecting clients and the Data Plane, comprising Interface Unit 11, the Application Programming Interface Server (Api-Server) of the System Under Test (SUT), the Database (DB), the NATS message broker, and ZooKeeper (a distributed coordination server). Interface Unit 11 provides external interface services to the Control Plane, receiving requests from clients (such as node lifecycle management and network configuration requests) and forwarding them to subsequent components, such as the SUT Api-Server and Configuration Unit 12. The SUT Api-Server is the core control component of the cloud network management system under test, serving as the API entry point for services like Keystone and Nova in OpenStack. Interface Unit 11 forwards client requests to this component to test whether its cloud network management logic meets expectations. The Database (DB) stores the system's core configuration data, such as the attributes of simulated compute nodes (IP, VPC affiliation), network topology information, and test task status, providing data support for the Control Plane's decision-making and operations. The message middleware NATS plays the role of asynchronous message communication, realizing the transmission of instructions and status between the control plane and the data plane (such as configuration unit 12 and network proxy simulation module 20), decoupling the strong dependency between the control plane and the data plane, and improving system scalability. ZK, as a distributed coordination service, is used to manage the distributed state of the system (such as the registration status of simulated computing nodes and cluster configuration consistency), ensuring consistency and reliability when multiple components work together.

[0079] The Data Plane is responsible for actual network traffic forwarding, node simulation, and monitoring. It serves as the execution layer for simulation testing and includes configuration unit 12, network proxy simulation module 20, and a network monitoring unit deployed in a namespace. Configuration unit 12 receives instructions from the control plane (such as interface unit 11) and executes specific resource configuration operations. For example, it calls Ovs-vsctl (the Open vSwitch command-line tool) to configure the ports and flow tables of the virtual switch (OVS); and it creates and manages network namespaces through Ip netns (a Linux network namespace tool) to achieve network isolation and simulate multi-tenant or multi-node network environments. The network proxy simulation module 20 deploys simulated network proxy components (such as Fake-Agent) on the simulated computing nodes, enabling them to interact with the control plane (such as the tested system API-Server) and simulating the communication logic between real computing nodes and the control system. The network monitoring unit is a monitoring component deployed in the network namespace of real computing nodes and simulated computing nodes. It is used to collect data such as network traffic and node status, providing observation basis for data plane behavior of the test module and verifying the cloud network management and control system's ability to monitor and manage the data plane.

[0080] In this embodiment of the invention, these components work together to form a complete large-scale cloud network simulation testing system 100. Its main function is to achieve automated deployment and testing of large-scale clusters, thereby locating potential bugs and system bottlenecks in the tested system. Compared with large-scale testing schemes using real nodes, the cloud network simulation testing system 100 has many advantages, such as rapid deployment, flexible expansion, and cost savings. Furthermore, the cloud network simulation testing system 100 can simulate various network environments, providing more possibilities for cloud network testing and optimization.

[0081] Specifically, the simulated network proxy component provides a fake proxy service (Fake-Agent) and / or a lightweight proxy service (Mock-Agent); wherein the fake proxy service provides complete information interaction logic with the control plane; and the lightweight proxy service provides basic information interaction logic with the control plane.

[0082] For example, the Fake-Agent service provides more functionality than the Mock-Agent service. The Fake-Agent service is a simplified version of the OVS Agent in the original SDN system, shielding the underlying OVS and DPDK (Data Plane Development Kit) services. It is primarily used to observe whether the behavior of network agent services in a normal system under test meets expectations in large-scale scenarios. The Mock-Agent service uses lightweight third-party software to simulate the interaction between the OVS Agent and ZooKeeper (ZK) in the system under test, enabling ZK connection, monitoring ZK data, and simulating the heartbeat maintenance behavior of the OVS Agent in the system under test. This is used for large-scale stress testing of the control plane data of the system under test. The Fake-Agent and Mock-Agent services can be deployed together or separately on simulated computing nodes. In the cloud network simulation test system 100, after creating simulated computing nodes through the application programming interface (API), either the Fake-Agent service or the Mock-Agent service can be deployed to these nodes according to testing requirements. For example, in test scenarios requiring more comprehensive and realistic proxy behavior, the fake proxy service Fake-Agent should be deployed; while in test scenarios sensitive to resource consumption and requiring only simple node registration and basic information transmission, the lightweight proxy service Mock-Agent should be deployed. In some complex test scenarios, both the fake proxy service Fake-Agent and the lightweight proxy service Mock-Agent can be deployed simultaneously on a single simulated computing node.

[0083] See Figure 4 , Figure 4 This is an application diagram of the network proxy simulation module provided in this embodiment of the invention. The ApiServer cluster serves as the management and control entry point, the ZK cluster serves as the distributed coordination hub, and network proxies with Fake-Agent / Mock-Agent are deployed on multiple simulated computing node hosts. Through this architecture, high-density proxy deployment on a small number of physical hosts is achieved. It can simulate the "management plane-proxy-computing node" interaction logic of a real SDN system, and can support simulation testing of large-scale computing node clusters (such as the concurrent creation and management of millions of ports and VPCs) at low cost.

[0084] For example, the ApiServer cluster module consists of a cluster of Api-Servers (such as api-server-1, api-server-2, and api-server-3) from multiple systems under test. As the entry point for the control plane of the systems under test, it is responsible for receiving upper-layer business requests (such as creating virtual networks and configuring flow tables) and, through interaction with the ZK cluster, managing the underlying proxy services (Fake-Agent / Mock-Agent). The ZK cluster is a ZooKeeper cluster (distributed coordination service) composed of ZK1, ZK2, and ZK3. As a distributed state storage and coordination center, it stores the registration information, heartbeat status, and network resource metadata (such as ports and flow tables) of the proxy services (Fake-Agent / Mock-Agent), enabling decoupled communication between the ApiServer and the proxy services. For example, the ApiServer cluster writes control commands to ZK, and the proxy services listen for and read commands from ZK; the proxy services report their status to ZK, and the ApiServer cluster detects status changes from ZK. The diagram shows four simulated computing nodes: Host1, Host2, Host3, and Host4. Each simulated computing node can deploy different types of proxy services or the same type of proxy services. These proxy services interact with the ZooKeeper cluster, registering their own state with ZooKeeper (by writing timestamps via heartbeats) and receiving network configuration commands (such as creating virtual ports and updating flow tables) from the APIServer cluster.

[0085] Specifically, the fake agent service Fake-Agent is a simplified implementation of the OVS Agent in the tested SDN system that shields the underlying services. Multiple fake agent services can be deployed on a single simulated computing node. The fake agent service can provide at least one of the following functions: 1.1) to 1.4).

[0086] 1.1) Establish a communication connection with the distributed coordination server; wherein the distributed coordination server is associated with the application programming interface server of the system under test;

[0087] For example, the fake agent service Fake-Agent establishes a communication connection with the distributed coordination server (ZooKeeper) through a distributed coordination client (such as the Apache Curator tool), realizes the interaction with the application interface server (Api-Server) of the system under test, and supports automatic reconnection and state recovery after the connection is lost, ensuring continuous communication between the agent service and the control plane.

[0088] 1.2) Periodically write timestamps to the node paths of the distributed coordination server;

[0089] For example, the fake agent service Fake-Agent retains the original heartbeat mechanism of the tested system. By periodically writing timestamps to the corresponding node path (ZK PATH) in ZooKeeper, the API-Server of the tested system can recognize that the Fake-Agent is in an Active state, thus maintaining the online identity of the agent service.

[0090] 1.3) Monitor network layer resource update operations;

[0091] For example, the fake agent service Fake-Agent monitors in real time the addition, deletion, modification and other update operations of network layer resources such as network, port, security group and route under its simulated computing node, and synchronizes the resource change information to the API-Server of the system under test, so as to ensure that the control plane can perceive the status changes of the underlying network resources in a timely manner.

[0092] 1.4) Data interaction with the simulated virtual switch; including at least one of the following functions: requesting port information from the simulated virtual switch; sending update instructions for flow table information and / or group information to the simulated virtual switch; forwarding packet output requests to the simulated virtual switch; requesting residual flow table information from the simulated virtual switch.

[0093] For example, see Figure 5 , Figure 5 This is a schematic diagram illustrating the information interaction between the fake proxy service and the simulated virtual switch provided in this embodiment of the invention. When the fake proxy service Fake-Agent interacts with the simulated virtual switch Fake-OVS, it needs to provide simulated underlying resource information. Fake-OVS is used to simulate OVS and intercepts and responds to requests sent by Fake-Agent to the underlying service. The main interactions are as follows:

[0094] 1. Simulate the handshake interaction between the virtual switch and the pseudo-proxy service using the Open Flow protocol to establish a communication connection;

[0095] 2. The pseudo-proxy service requests port information from the simulated virtual switch, such as VXLAN port, bond port, tap port (including MAC address), and port number.

[0096] 3. The simulated virtual switch returns port information to the pseudo-proxy service; the simulated virtual switch needs to process the message requesting port information, and simulate OVS DB to construct fake MAC addresses, port numbers and other information to reply; other messages can be ignored and not replied to.

[0097] 4. The pseudo-proxy service sends commands to the simulated virtual switch to add, delete, and modify flow tables;

[0098] 5. The pseudo-proxy service sends commands to the simulated virtual switch to add, delete, and modify groups;

[0099] 6. The pseudo-proxy service sends a packet out command to the simulated virtual switch;

[0100] 7. The pseudo-proxy service sends a request for residual flow table information (dump flows) to the simulated virtual switch, i.e., to obtain residual flow table information;

[0101] 8. The simulated virtual switch replies with residual flow table information (flow stats) to the pseudo-proxy service.

[0102] Specifically, the OVS Agent in actual SDN systems consumes a large amount of memory, making large-scale deployment on a single node impossible. To conduct large-scale testing with as few physical servers as possible, the Agent is further lightweighted based on the aforementioned fake agent service, Fake-Agent, resulting in the lightweight agent service, Mock-Agent. Specifically, the lightweight agent service, Mock-Agent, can connect to and operate ZooKeeper through the ZooKeeper client provided by Kazoo. It establishes and disconnects connections with ZooKeeper via Kazoo, creates, deletes, queries, and updates ZK nodes, monitors ZK node data, and implements periodic updates of ZK data to ensure the Agent's heartbeat is normal. The lightweight agent service, Mock-Agent, can be deployed on a large number of nodes, facilitating stress testing at the SDN management layer. The lightweight agent service, Mock-Agent, can provide at least one of the following functions: 2.1) to 2.3).

[0103] 2.1) Establish a communication connection with the distributed coordination server; wherein the distributed coordination server is associated with the application programming interface server of the system under test;

[0104] For example, the lightweight proxy service Mock-Agent establishes a communication connection with the distributed coordination server (ZooKeeper) through a distributed coordination client (such as Kazoo), realizes the interaction with the application programming interface server (Api-Server) of the system under test, and supports automatic reconnection and state recovery after the connection is lost, ensuring continuous communication between the proxy service and the control plane.

[0105] 2.2) Periodically write timestamps to the node paths of the distributed coordination server;

[0106] For example, the lightweight proxy service Mock-Agent retains the original heartbeat mechanism of the system under test. By periodically writing timestamps to the corresponding node path (ZK PATH) in ZooKeeper, the API-Server of the system under test can recognize that Mock-Agent is in an Active state, thus maintaining the online identity of the proxy service.

[0107] 2.3) Monitor network layer resource update operations;

[0108] For example, the lightweight proxy service Mock-Agent monitors in real time the addition, deletion, modification and other update operations of network layer resources such as network, port, and firewall under its simulated computing node, and synchronizes the resource change information to the API-Server of the system under test, so as to ensure that the control plane can perceive the status changes of the underlying network resources in a timely manner.

[0109] In this embodiment of the invention, the communication connection functions provided by the pseudo-proxy service and the lightweight proxy service can quickly establish a stable connection with the distributed coordination server. Leveraging the distributed coordination client's support for reconnection after disconnection, continuous interaction with the API-Server of the system under test is ensured, laying a solid communication foundation for subsequent data transmission and command response. Simultaneously, the original heartbeat mechanism of the system under test is retained, periodically writing timestamps to the corresponding node path of the distributed coordination server, allowing the API-Server to recognize in real time that the service is in an active state, avoiding misjudgments of service offline due to heartbeat interruptions. Furthermore, real-time capture of network layer resource dynamics allows for accurate monitoring of resource addition, deletion, and modification operations, promptly synchronizing change information to the management plane, ensuring that the API-Server can dynamically grasp the underlying resource status and support the accuracy of cloud network management decisions. In addition, the pseudo-proxy service can achieve efficient data interaction with simulated virtual switches. It can actively request port information to provide basic data for network configuration; it can send flow table and group information update instructions to dynamically adjust forwarding rules; it can forward packet output requests to the switch to ensure smooth data path; it can also request residual flow table information to facilitate the cleanup of redundant rules. These functions work together to accurately simulate the interaction logic between real network proxies and switches, support core scenario testing such as flow table management and data forwarding, and ensure the consistency and reliability of network control and data forwarding in the simulation environment.

[0110] Specifically, Test Module 30 is a test management tool for large-scale simulation system development. It is used to test the functionality, stability, and reliability of the system under large-scale simulation to help discover potential bugs and performance bottlenecks in the SDN system. Users can design test cases for products or requirements, manage test resources, provide feedback on test results and record defects generated during the testing process, and generate test reports upon completion of test tasks, thus achieving quality assurance throughout the entire lifecycle of project development and deployment.

[0111] See Figure 6 , Figure 6 This is a structural block diagram of the test module 30 provided in this embodiment of the invention. The test module 30 includes a data plane traffic monitoring unit 31, a cluster scheduling unit 32, a resource test scenario creation unit 33, an anomaly simulation unit 34, and a runtime inspection unit 35. Specifically, the data plane traffic monitoring unit 31 receives traffic monitoring requests and sends monitoring parameters to the data plane device of the system under test to initiate the monitoring service; the cluster scheduling unit 32 concurrently creates virtual private networks and ports and allocates simulated network proxy components to each tenant; the resource test scenario creation unit 33 configures service resource parameters and creates network layer resources; the anomaly simulation unit 34 simulates abnormal conditions of system components and / or system services through service restart operations; and the runtime inspection unit 35 checks the runtime status of the system components and / or system services.

[0112] The data plane traffic monitoring unit 31 is used to simulate data plane network connectivity testing between computing nodes in a large-scale testing environment, covering test task issuance, test execution, and test result feedback and collection. It supports specified ICMP (Internet Control Message Protocol) traffic monitoring and TCP (Transmission Control Protocol) traffic monitoring, and can also be extended to support the execution of custom shells (command line interpreters). Custom shells refer to shell scripts or sets of operation instructions written or customized by users according to their specific needs. For example, net-insight-server monitors and manages the traffic of simulated computing nodes (emu-vm) and associated network components (easeprobe) on real computing nodes. Each real computing node runs multiple simulated computing nodes to simulate a virtual host cluster in a large-scale test environment and test the network interaction between different virtual machines. As the main body of the data plane traffic monitoring unit 31, net-insight-server is responsible for receiving users' data plane traffic monitoring requests, and then sending the monitoring parameters to the devices executing the data plane according to the parameter mode specified by the user. Subsequently, a lightweight monitoring probe tool (such as EaseProbe) is started on the corresponding device to continuously monitor the data plane traffic.

[0113] The cluster scheduling unit 32 implements VPC and port data preparation and test tenant management in large-scale simulation systems. It is mainly used for testing the capacity scale of VPCs and virtual machines in SDN systems, as well as for preparing test data to test the pressure on the SDN system's control plane. It supports the concurrent creation and deletion of millions of VPCs and ports.

[0114] For example, taking port-based scheduling as an example, the main implementation process of cluster scheduling unit 32 is illustrated below. See [link to documentation]. Figure 7 , Figure 7 This is a flowchart of the cluster scheduling unit in the test module provided in this embodiment of the invention, including the following steps:

[0115] 1. Obtain and filter real computing nodes. Send a request to the API-Server of the system under test to obtain information on all currently registered real computing nodes. Then, according to specific naming rules, filter out the nodes with an active status from these nodes, and obtain the fake agent service Fake-Agent and the lightweight agent service Mock-Agent running on these nodes.

[0116] 2. Assess the capacity of real computing nodes. Obtain the maximum number of ports configured for each selected real computing node. Based on the target port scale to be created, calculate the total number of ports that these currently active real computing nodes can support. If the calculated support capacity is less than the target port scale, it indicates that the existing node resources are insufficient to complete the task, and an error will occur, exiting the process to avoid subsequent invalid operations.

[0117] 3. Calculate the number of tenants and persist information. Based on the pre-defined number of ports that each large and small tenant should contain, calculate the number of large and small tenants that need to be created. Complete the concurrent creation of large and small tenants, and persistently store the information of these tenants (such as tenant identifier, number of ports, etc.) locally for subsequent process use and anomaly recovery. It should be noted that the resources of the tenants are distributed across at least one simulated computing node, and one simulated computing node can deploy the resources of multiple tenants.

[0118] 4. Greedy Algorithm for Allocating Simulated Network Proxy Components. To ensure that both simulated computing nodes and simulated network proxy components participate in the port creation task as much as possible, a greedy algorithm is used to allocate simulated network proxy components to each large and small tenant. The core of the greedy algorithm is to adopt the strategy that seems optimal at each step, which means allocating tenants to different types of simulated network proxy components as evenly as possible to make full use of resources and cover more node types.

[0119] 5. Concurrent creation of Virtual Private Clouds (VPCs). To improve the efficiency of concurrent port creation, use IPv6 subnets. Because the IPv6 address space is very large, the probability of address collisions during address allocation is much lower than that of IPv4, which can reduce the overhead of collision handling during address allocation and speed up port creation.

[0120] 6. Assemble port request data. Construct the port creation request data, which includes parameters such as device_owner (device owner, used to identify the device or service to which the port belongs) and binding_host (binding host, specifying the host where the port resides). To speed up the deployment process, a fixed IP address is specified when creating the port. This avoids potential conflicts that may occur when the SDN system dynamically allocates IP addresses, reducing creation failures and retries due to address conflicts and improving creation efficiency.

[0121] 7. Port Creation and Resume Operations. The assembled port request data is output to files by tenant. These files are read concurrently, and requests are sent to the API server of the system under test to create ports. To ensure that port creation can continue after abnormal interruptions (such as system crashes or network failures), the number of ports already created by a tenant is queried from the local storage before port creation. Based on this information, the file data is segmented, and concurrent creation operations resume from the point of last interruption, achieving resume operation and avoiding duplicate creation and resource waste.

[0122] The resource test scenario creation unit 33, based on an automated testing framework (such as pytest), configures core business resource-related parameters to achieve full coverage testing of all core parameters of business resources. These parameters include key configuration items at the network and compute layers (such as subnet mask, protocol type, routing table entries, virtual machine specifications, and tenant ID). It also supports concurrent testing of network layer resources such as networks, subnets, and ports for verifying system functionality in large-scale simulation systems.

[0123] The anomaly simulation unit 34 simulates abnormal situations of the API-Server component, ZK component, Agent service, etc. in the system under test by service restart operation, and tests the availability of each component and / or service in a large-scale SDN system. It can also work with the tenant and cluster scheduling module to explore the availability of the system when Agents restart concurrently in large-scale scenarios.

[0124] The operation check unit 35 provides a health status check. The health check of the cloud network simulation test system 100 of this invention is divided into two types: control plane detection service and data plane detection service. The control plane detection service covers the API-Server of the system under test, the cloud network simulation test system 100's own management platform, and ZooKeeper. The data plane detection service covers the configuration unit 12 and the network proxy simulation module 20. During the check, the health status can be obtained by acquiring and analyzing the operating parameters of these components.

[0125] In this embodiment of the invention, the testing module 30 possesses diverse and practical functions. The data plane traffic monitoring unit 31 can respond to traffic monitoring requests, send monitoring parameters to the data plane device, and thus initiate the monitoring service to help grasp the dynamics of data transmission. The cluster scheduling unit 32 can perform concurrent creation operations on virtual private networks and ports, and also allocate simulated network proxy components to each tenant. Tenant resources can be distributed across at least one simulated computing node, efficiently supporting network resource allocation in multi-tenant scenarios. The resource test scenario creation unit 33 is responsible for configuring business resource parameters and creating network layer resources, laying the foundation for various test scenarios. The anomaly simulation unit 34 simulates abnormal situations of system components and system services through service restarts to verify the system's fault tolerance and recovery capabilities. The operation check unit 35 is used to check the operating status of system components and system services to ensure that the system maintains a normal and stable operating state during the testing process. These units work together to comprehensively meet the testing needs for traffic monitoring, resource scheduling, scenario construction, anomaly verification, and status detection.

[0126] Furthermore, the cloud network simulation testing system 100 is a system for testing large-scale cloud service applications by simulating cloud networks, cloud computing environments, and scenarios. The cloud network simulation testing system 100 also includes:

[0127] Deployment module 40 is used to build the simulation environment and perform initialization operations.

[0128] For example, see Figure 8 , Figure 8 This is a flowchart of the deployment module 40 provided in this embodiment of the invention, including the following steps:

[0129] 1. Node Deployment Planning. Based on the simulation target scale (e.g., how many real computing nodes need to be simulated, how many ports need to be supported) and component requirements (e.g., which nodes run the database, which run simulation services), the specific services that need to be deployed on each server in a cluster consisting of dozens to hundreds of servers need to be clearly defined to avoid resource waste or chaotic component allocation.

[0130] 2. Node connectivity testing. Use Ansible to batch test the network connectivity of all real compute nodes to ensure that the servers can communicate normally. This is the foundation for subsequent batch software deployment and synchronous configuration, and avoids deployment failure due to a single node disconnection.

[0131] 3. Obtain software packages. Gather the core software packages required for deployment, including Virtual Switch (OVS), a compute simulation module that simulates compute node functions, a network proxy simulation module that simulates network proxies, and test modules for testing, ensuring all materials are ready for subsequent installation and deployment.

[0132] 4. Deployment of basic components. Install the underlying basic services that support the operation of the simulation test system, such as the database service for storing data and NATS (message broker) for communication between components; note that the system under test and its dependent components are not included in this step and need to be deployed separately.

[0133] 5. Deployment of computing services. This step is optional and is generally performed after the deployment of the system under test. It is only executed when additional simulated computing resources are needed, and usually follows up after the deployment of the system under test is completed to avoid conflicts with the computing resources of the system under test.

[0134] 6. Simulation Service Deployment. Deploy services that support the core simulation functions, including computing simulation services that simulate the behavior of real computing nodes, network proxy simulation services that simulate network proxies (such as Fake-Agent / Mock-Agent), and OVS simulation services that simulate virtual switches. After these three steps are completed, the core capabilities of the simulation platform are basically formed.

[0135] 7. Deployment of Simulation Management and Testing Services. Deploy simulation management services (such as unified scheduling and status monitoring) and testing services (such as port mapping and traffic monitoring) to manage the simulation environment and execute tests.

[0136] 8. Environment Verification and Initialization. Verify the connectivity between the control plane (such as simulation control service) and the data plane (such as OVS simulation service, network proxy) to ensure that commands can be issued and responded to normally; at the same time, initialize the large-scale simulation service, and batch register the fake agent service Fake-Agent and the lightweight agent service Mock-Agent in the simulation test system to the API-Server of the system under test, completing the readiness of the entire simulation environment and preparing for subsequent testing.

[0137] In this embodiment of the invention, the deployment process ensures reasonable resource allocation and stable communication for large-scale clusters through clear node planning and automated connectivity testing; the deployment of basic components and core simulation services in stages clarifies boundaries and reduces the risk of dependency conflicts, ultimately enabling the efficient construction of a stable large-scale cloud network simulation platform, quickly completing environment readiness, providing reliable support for subsequent SDN system testing, while reducing deployment errors and repetitive operations, and improving overall deployment efficiency.

[0138] See Figure 9 , Figure 9 This is a flowchart of a cloud network simulation testing method provided in an embodiment of the present invention. The cloud network simulation testing method includes:

[0139] S1. Create at least one simulated computing node for the system under test using an application programming interface (API), and provide network environment configuration and lifecycle management functions for each simulated computing node; wherein, the system under test is a cloud network management and control system built on software-defined networking.

[0140] S2. Deploy at least one simulated network proxy component for each simulated computing node, and execute the information interaction process between the simulated computing node and the control plane of the system under test through the simulated network proxy component.

[0141] S3. Test the simulation environment constructed by the simulated computing node and the simulated network proxy component, and generate test results.

[0142] Furthermore, the method also includes:

[0143] Set up the simulation environment and perform initialization operations.

[0144] It is worth noting that the specific working process of the cloud network simulation test method described in the embodiments of the present invention can be referred to the working process of each module in the cloud network simulation test system 100 described in the above embodiments, and will not be repeated here.

[0145] See Figure 10 , Figure 10 This is a structural block diagram of a cloud network simulation testing device 200 provided in an embodiment of the present invention. The cloud network simulation testing device 200 includes a processor 21, a memory 22, and a computer program stored in the memory 22 and executable on the processor 21. When the processor 21 executes the computer program, it implements the steps in the various cloud network simulation testing method embodiments described above.

[0146] For example, the computer program can be divided into one or more modules / units, which are stored in the memory 22 and executed by the processor 21 to complete the present invention. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program in the cloud network simulation test device 200.

[0147] The cloud network simulation test device 200 may include, but is not limited to, a processor 21 and a memory 22. Those skilled in the art will understand that the schematic diagram is merely an example of the cloud network simulation test device 200 and does not constitute a limitation on the cloud network simulation test device 200. It may include more or fewer components than illustrated, or combine certain components, or different components. For example, the cloud network simulation test device 200 may also include input / output devices, network access devices, buses, etc.

[0148] The processor 21 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. The processor 21 is the control center of the cloud network simulation test equipment 200, connecting all parts of the cloud network simulation test equipment 200 via various interfaces and lines.

[0149] The memory 22 can be used to store the computer programs and / or modules. The processor 21 implements various functions of the cloud network simulation test device 200 by running or executing the computer programs and / or modules stored in the memory 22 and calling the data stored in the memory 22. The memory 22 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory 22 may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0150] The modules / units integrated in the cloud network simulation testing equipment 200, if implemented as software functional units and sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by the processor 21, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0151] Furthermore, the present invention also provides a computer program product, including a computer program / instructions, which, when executed by a processor, implement the cloud network simulation testing method as described in any of the above embodiments.

[0152] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A cloud network simulation testing system, characterized in that, include: The computational simulation module is used to create at least one simulated computing node of the system under test using an application programming interface (API), and to provide network environment configuration and lifecycle management functions for each simulated computing node; wherein, the system under test is a cloud network management and control system built on software-defined networking. A network proxy simulation module is used to deploy at least one simulated network proxy component for each simulated computing node, and to execute the information interaction process between the simulated computing node and the control plane of the system under test through the simulated network proxy component; wherein, the simulated network proxy component provides pseudo-proxy service and / or lightweight proxy service; wherein, the pseudo-proxy service provides complete information interaction logic with the control plane; and the lightweight proxy service provides basic information interaction logic with the control plane; The testing module is used to test the simulation environment constructed by the computation simulation module and the network proxy simulation module, and generate test results.

2. The cloud network simulation testing system as described in claim 1, characterized in that, The computational simulation module includes: An interface unit is used to provide interface services for the application programming interface (API) to receive lifecycle management requests from simulated computing nodes through the API. The configuration unit is used to perform corresponding lifecycle management functions on the simulated computing node according to the lifecycle management request, and to create the simulated computing node and configure the network environment of the newly created simulated computing node when the lifecycle management request is a node creation request.

3. The cloud network simulation testing system as described in claim 2, characterized in that, The lifecycle management request includes at least one of the following: node creation request, node deletion request, node query request, node configuration update request, node enable request, and node deactivation request; the network environment configuration includes at least one of the following: network namespace configuration, virtual port configuration, and routing configuration.

4. The cloud network simulation testing system as described in claim 1, characterized in that, Both the pseudo-proxy service and the lightweight proxy service can provide at least one of the following functions: Establish a communication connection with the distributed coordination server; wherein the distributed coordination server is associated with the application programming interface server of the system under test; Periodically write timestamps to the node paths of the distributed coordination server; Monitor network layer resource update operations.

5. The cloud network simulation testing system as described in claim 1, characterized in that, The pseudo-proxy service also provides the ability to interact with simulated virtual switches.

6. The cloud network simulation testing system as described in claim 5, characterized in that, The function of interacting with the simulated virtual switch includes at least one of the following functions: Request port information from the simulated virtual switch; Send update instructions for flow table information and / or group information to the simulated virtual switch; Forward the data packet output request to the simulated virtual switch; Request residual flow table information from the simulated virtual switch.

7. The cloud network simulation testing system as described in claim 1, characterized in that, The testing module includes: The data plane traffic monitoring unit is used to receive traffic monitoring requests and send monitoring parameters to the data plane device of the system under test to start the monitoring service; A cluster scheduling unit is used to concurrently create virtual private networks and ports, and allocate simulated network proxy components to each tenant; wherein the resources of the tenant are distributed on at least one simulated computing node; The resource test scenario creation unit is used to configure business resource parameters and create network layer resources; An exception simulation unit is used to simulate abnormal conditions of system components and / or system services through service restart operations; The operation check unit is used to check the operating status of the system components and / or the system services.

8. The cloud network simulation testing system as described in claim 1, characterized in that, The cloud network simulation testing system also includes: The deployment module is used to set up the simulation environment and perform initialization operations.

9. A cloud network simulation testing method, characterized in that, include: At least one simulated computing node of the system under test is created using an application programming interface (API), and network environment configuration and lifecycle management functions are provided for each simulated computing node; wherein, the system under test is a cloud network management and control system built on software-defined networking. At least one simulated network proxy component is deployed for each simulated computing node, and the information interaction process between the simulated computing node and the control plane of the system under test is executed through the simulated network proxy component; wherein, the simulated network proxy component provides pseudo proxy service and / or lightweight proxy service; wherein, the pseudo proxy service provides complete information interaction logic with the control plane; and the lightweight proxy service provides basic information interaction logic with the control plane; The simulation environment constructed by the simulated computing node and the simulated network proxy component is tested, and test results are generated.

10. The cloud network simulation testing method as described in claim 9, characterized in that, The method further includes: Set up the simulation environment and perform initialization operations.

11. A cloud network simulation testing device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor executes the computer program to implement the cloud network simulation test method as described in any one of claims 9 to 10.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform the cloud network simulation test method as described in any one of claims 9 to 10.

13. A computer program product, characterized in that, It includes a computer program / instruction that, when executed by a processor, implements the cloud network simulation test method as described in any one of claims 9 to 10.

Images