General hardware-based lightweight simulation verification system for complex edge computing environment

Abstract

The invention discloses a lightweight simulation verification system for a complex edge computing environment based on general hardware, and the system comprises a workload manager which receives a task request, manages the whole process of a task from the beginning to the end, recovers an execution result, and returns the result to a user; the network topology manager receives the network topology information transmitted by the workload manager and configures network topology for the task; the scheduling subsystem is used for sending the selected working node to the working load manager after receiving the task request; the rapid distribution subsystem is responsible for rapidly transmitting the container mirror image of the task to each selected working node; and the monitoring subsystem is responsible for collecting parameters during system operation, transmitting the parameters to the scheduling subsystem for task decision making and transmitting the parameters to the workload manager after the tasks are finished. The system has the characteristics of light weight and high performance, and can make a light-weight analogue simulation scheme conforming to a real scene for an edge computing scene comprising complex and dynamic network topology and various heterogeneous hardware.

Description

Technical Field

[0001] The present invention relates to various edge computing algorithm implementation verification methods, and in particular to a lightweight simulation verification system for a complex edge computing environment based on general-purpose hardware. Background Art

[0002] The edge computing paradigm has become one of the hot topics in current research because it can place computing resources and storage resources at the edge of the network, thereby reducing data transmission delays and improving data processing efficiency. The application scenarios of edge computing include but are not limited to smart homes, smart transportation, smart healthcare, smart industry, etc., and its research directions mainly focus on the network topology of edge computing, resource scheduling of edge computing, and security of edge computing. However, compared with the traditional cloud computing model, edge computing naturally has a more complex network topology and a more diverse software and hardware composition paradigm, and its application scenarios are more diverse. This brings greater challenges to the simulation and verification of edge computing. The challenges are mainly concentrated in several aspects: (1) The simulation of complex and changeable network topologies using general routers, switches, etc. requires more manual intervention, including plugging and unplugging and configuration, etc. (2) There are obstacles in the unified management of various hardware devices, such as CPU architecture support and adaptation of devices such as graphics cards, etc. (3) In order to support different task types, it is often necessary to design the architecture according to the characteristics of the task itself, and (4) It is necessary to efficiently distribute the workload to the terminal computing device to speed up the testing process. For example, a Chinese patent with publication number CN113157431A discloses a method for distributing computing task copies for edge network application environments: the method divides the user tasks of the cloud service center into multiple subtasks, and distributes these subtasks to the edge nodes in the network through a roulette algorithm, so that nodes with more neighbor nodes undertake more subtasks, while those with fewer neighbor nodes undertake fewer subtasks. And a Chinese patent with publication number CN111597043A discloses a full-scenario edge computing method, device and system, which includes the following steps: a resource scheduling node receives a user's computing request, generates a full-scenario edge computing task and generates a mirror file dockerfile; obtains an indifferent computing program executed by an edge computing node or compiles the program using source code; selects an edge scheduling algorithm and selects available edge computing nodes according to the edge scheduling algorithm, splits the edge computing task into work tasks that can be executed by each edge computing node and distributes them.

[0003] In addition, the cost of hardware is also a very real problem. There are many types of hardware devices used for edge computing, with different performances. In complex scenarios, it takes a lot of economic and manpower costs to prepare and use a large number of different devices. Under cost constraints, the reliability of test verification will be affected. Adapting general hardware to different scenarios can effectively improve this situation.

[0004] Edge computing environments often have resource constraints. In edge computing scenarios, due to the limited computing and storage capabilities of devices, it is a challenging problem to conduct simulation tests under limited resource constraints while minimizing interference with the actual workload itself. This scenario requires the simulation test system to be lightweight enough: that is, it does not occupy too many computing, storage, bandwidth and other resources; accordingly, the functionality does not need to meet commercial production standards. This is somewhat different from the production environment cluster scheduling solution represented by Kubernetes. Summary of the invention

[0005] The purpose of the present invention is to provide a lightweight simulation and verification system for complex edge computing environments based on general-purpose hardware, which has the characteristics of lightweight and high performance and can make lightweight simulation solutions that conform to real scenarios for edge computing scenarios that include complex and dynamic network topologies and a variety of heterogeneous hardware.

[0006] The present invention provides the following technical solutions:

[0007] A lightweight simulation verification system for a complex edge computing environment based on general hardware, the system comprising:

[0008] The workload manager is responsible for receiving task requests from the user side, managing the entire process of the task from start to finish, and recycling the execution results of the working nodes and returning them to the user;

[0009] The network topology manager is responsible for managing and controlling the backbone network connecting the local area networks of each work node: receiving the network topology information transmitted by the workload manager and configuring the network topology for the task;

[0010] The scheduling subsystem is responsible for deciding the execution of tasks at the start and during the execution of tasks. Physical devices: after receiving the task request forwarded by the workload manager, it sends the selected working node to the workload manager;

[0011] The fast distribution subsystem receives requests from the workload manager and is responsible for quickly delivering the task's container image to each selected worker node;

[0012] The monitoring subsystem is responsible for collecting parameters during system runtime, which are then passed to the scheduling subsystem for decision-making tasks, and the parameters are passed to the workload manager after the task is completed.

[0013] The selected working node is the working node that needs to execute the task.

[0014] In the present invention, the workload manager is the main part directly facing the user, and is provided with an HTTP interface for user operation.

[0015] Furthermore, the workload manager includes two parts: a user interface and a backend:

[0016] User interface, used by users to submit task requests, view task execution status, and view task execution results after the task is completed;

[0017] The backend is used to manage the entire process of the task from start to finish. Its workflow is as follows:

[0018] The workload manager backend receives the task request;

[0019] The workload manager's backend confirms whether the system is able to complete the task;

[0020] The backend of the workload manager forwards the task request to the scheduling subsystem and receives the work node selected by the scheduling subsystem;

[0021] The workload manager's backend requests the fast distribution subsystem to pass the task's container image to the worker node;

[0022] The workload manager's backend passes the network topology information to the network topology manager;

[0023] The backend of the workload manager instructs each worker node to start tasks;

[0024] The workload manager's backend keeps in touch with the worker nodes and monitors the tasks until they are completed;

[0025] The workload manager backend collects the execution results of tasks from each worker node;

[0026] The workload manager backend returns the task execution results to the user.

[0027] Further, several of the selected working nodes are divided into a group, each group is in a local area network connected by a switch, and each local area network is connected through an upper layer switch and a general device for simulating a router, wherein the general device for simulating a router is called a backbone network router;

[0028] The network topology manager adopts a server-client architecture: the server is located on the management node, and the client is located on the backbone network router and is responsible for configuring the network topology of the router according to the instructions of the server.

[0029] In the present invention, the backbone network router simulates several routers according to the real Internet structure by software (such as using Linux network namespace and other mechanisms), so that one device can replace multiple real routers. The specific simulation parameters, including topology structure and link quality, are dynamically managed by the network topology manager during runtime.

[0030] In each logical LAN, or in other words, in each network namespace, there is a dedicated logical device that is responsible for managing the network topology. The "client" here runs on this dedicated device.

[0031] When the task starts, the interaction process between the server and the client of the network topology manager is as follows:

[0032] (1) The server of the network topology manager receives the network topology structure given by the user and sends the relevant information to the client of the network topology manager;

[0033] (2) The client of the network topology manager confirms the number of LANs to be simulated and sets the Linux network namespace.

[0034] (3) The client of the network topology manager configures information including IP addresses and routing tables for each network namespace based on the network topology structure given by the user;

[0035] (4) The client of the network topology manager applies bandwidth, latency, and packet loss constraints to each simulated LAN;

[0036] (5) The server of the network topology manager opens an API interface to allow the user to dynamically update the network topology during runtime; the updated network topology is re-executed starting from step (2).

[0037] Specifically, the process of configuring the network topology by the client of the network topology manager is as follows:

[0038] Create a Linux network namespace for each LAN to be simulated;

[0039] Determine the LANs that need to be connected to each other, configure a pair of vethpairs (virtual Ethernet interfaces) between the LANs that need to be connected to each other, and put each end into the corresponding network namespace;

[0040] Configure each network namespace with information including IP addresses and routing tables to connect various LANs;

[0041] Use the tc command to set bandwidth, latency, and packet loss limits for each veth pair;

[0042] Determine the devices that need to be connected to each LAN, and route the devices that need to be connected to each network namespace.

[0043] By default, the scheduling subsystem only adopts the simplest scheduling strategy. However, this section also includes an interface that allows users to customize the scheduling method. Furthermore, the workflow of the scheduling subsystem is: filter out unqualified work nodes according to task requests; use the scheduling algorithm to select a set of work nodes that actually undertake the task as the selected work nodes.

[0044] The user can use the system runtime parameters obtained by the monitoring subsystem to write the scheduling strategy by himself. Further preferably, the system includes an API interface for providing the user side with real-time data from the monitoring subsystem, and for the user side to formulate a scheduling plan based on the real-time data and hand it over to the scheduling subsystem to execute the working node of the decision-making task.

[0045] In the present invention, scheduling can be performed when a task starts, or the task can be frozen during runtime and transferred to other physical devices.

[0046] Furthermore, the fast distribution subsystem is responsible for quickly delivering the container image of the task to each selected working node based on IP multicast; the specific transmission process is:

[0047] The server of the fast distribution subsystem running on the management node receives the container image provided by the user;

[0048] The server of the fast distribution subsystem splits the container image and builds a hash tree for verification. This hash tree is sent to each selected working node before the transmission begins.

[0049] The server of the fast distribution subsystem instructs the clients on each selected working node to join the multicast group and prepare to receive the container image;

[0050] The server of the fast distribution subsystem sends container image data to the multicast group;

[0051] During the receiving process, the client on each selected working node verifies the data according to the hash tree to ensure data integrity.

[0052] The present invention realizes task distribution by adopting IP multicast technology, and can achieve extremely high transmission speed while reducing occupation of system resources.

[0053] Furthermore, the monitoring subsystem is responsible for monitoring the environmental information of the working node itself, including the usage of system resources such as CPU, disk, and memory, as well as the running status of each task. The parameters obtained include CPU usage, memory usage, and network bandwidth usage. The monitoring subsystem includes a server and a client. The server of the monitoring subsystem is located on the management node, and the client of the monitoring subsystem is located on each working node.

[0054] Among other things, these parameters will be used by the scheduling subsystem for decision making and by the workload manager to generate reports after the task is completed.

[0055] In the present invention, the system comprises:

[0056] The end device acts as a management node, a backbone switch acts as a connection point for each LAN, and an end device acts as a simulated backbone router. Each LAN is connected to the backbone router through an upper-layer backbone switch.

[0057] Several working nodes, each of which includes a switch and several end devices. Each working node network also has an end device as a router, which is connected to the backbone network switch; Several working nodes are divided into several groups of working nodes, and each group of working nodes is in a local area network connected by a switch;

[0058] The server end of the network topology manager and the server end of the rapid distribution subsystem are located on the management node, the client end of the network topology manager is located on the router, and the client end of the rapid distribution subsystem is located on the working node.

[0059] The above technical solution has the following advantages or beneficial effects:

[0060] In summary, the present invention provides a lightweight simulation verification system for a complex edge computing environment based on general hardware: the system can be deployed on general hardware including x86, ARM, etc., supports programming simulation of complex network structures through a small amount of hardware, and allows convenient and rapid management of various tasks through a user-friendly interface; the system does not rely on hardware from a specific supplier and can run on general hardware such as x86 and ARM. This allows the present invention to be deployed at a lower cost; the system allows a large number of programmable control adjustments, so that users can design the simulation environment according to their needs without adjusting the hardware composition, thus having very high flexibility; the system takes into account many characteristics of the edge computing environment, and completes many targeted designs for the performance-first environment, with lightweight and high-performance characteristics; in addition, the fast distribution subsystem provided by the present invention is a task distribution system based on the IP multicast mode, which is used to speed up the cold start deployment speed of tasks. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Figure 1 It is the overall hardware composition of a lightweight simulation verification system for a complex edge computing environment based on general hardware provided by the present invention;

[0062] Figure 2 The present invention provides a design architecture for lightweight simulation verification system software in a complex edge computing environment based on general hardware. DETAILED DESCRIPTION

[0063] The present invention will be further described below in conjunction with the accompanying drawings.

[0064] like Figure 1 As shown, in terms of the hardware environment for running the system, the lightweight simulation verification system for complex edge computing environments based on general hardware provided by the present invention requires at least one general-purpose computing device of x86 or ARM architecture (hereinafter referred to as "end device") as a management node, a switch as a connection point for each network, and an end device as a simulated backbone network router. In addition, it should also include several working node networks. Each working node network should include a switch and several end devices. In addition, each working node network also has an end device as a router, which is connected to the backbone network switch.

[0065] like Figure 2 As shown, based on the above-mentioned hardware environment, the software composition of the lightweight simulation verification system for complex edge computing environment based on general hardware provided by the present invention is as follows: the server of each component is located on the management node, which is used to coordinate the operation of the entire system. In addition, the management node also includes an HTTP interface for users. The client of the network topology manager runs on the router, and uses the infrastructure of the Linux operating system to apply the network topology required by the user. Finally, the clients of all components except the network topology manager run on the working node, and complete the tasks required by the user. The container runtime environment (such as Docker or containerd) also needs to be run on the working node as the infrastructure for running and managing tasks.

[0066] In terms of program implementation, in order to facilitate system maintenance, all components are implemented into the same code base and compiled into a binary. When the binary runs on different devices, it can be configured as different roles (management node, router, working node, etc.). The binary is also managed by the container to support rapid expansion and contraction and rapid deployment of the system on newly added devices.

[0067] In the next few sections, we will explain the functions of each component, the relationship between components, and the implementation process details.

[0068] The workload manager consists of two parts: the user interface and the backend. The user interface presents a web page interface to the user. After logging in, the user can provide the container, startup instructions, required hardware architecture, and other information of the task he wants to execute on the interface, and specify the network topology he wants to use. After the task is submitted, the user can view the execution status of the task on the interface, and view the execution results of the task after the task is completed. Therefore, the user interface is the main way for users to interact with the system.

[0069] The backend is connected to other components of the system. From the process of the task from start to finish, the order of interaction with other components is:

[0070] 1. The workload manager backend receives a task request.

[0071] 2. The backend of the workload manager confirms whether the system can complete the task (whether the system is already occupied by other tasks, or whether the required hardware resources exist, etc.). If not, the user is prompted to reject the task, and the task process ends;

[0072] 3. The backend of the workload manager forwards the request information to the scheduling subsystem, thereby receiving the information of the working node selected by the scheduling subsystem (i.e., the working node selected to participate in the task execution);

[0073] 4. The workload manager's backend requests the fast distribution subsystem to pass the task's container image to the selected worker node;

[0074] 5. The backend of the workload manager passes the network topology information to the network topology manager so that the network topology manager configures the network topology for the task;

[0075] 6. The backend of the workload manager instructs each worker node to start tasks;

[0076] 7. The workload manager backend keeps in touch with the worker nodes and monitors the tasks until they are completed;

[0077] 8. The backend of the workload manager collects the execution results of the tasks from each worker node;

[0078] 9. The backend of the workload manager returns the execution results of the task to the user;

[0079] 10. If necessary (when the storage space of the working node is insufficient), clear the cached container image. This completes the task process.

[0080] In summary, the workload manager is responsible for the overall overview and is therefore the core part of the system. From the perspective of program implementation, the workload manager should also be the core part. Other components should register with the workload manager after startup to accept calls.

[0081] The specific contents of the network topology manager are as follows:

[0082] The network topology manager adopts a server-client architecture. The server is located on the management node and works with components such as the workload manager. The client is located on each router and is responsible for configuring the router's network topology according to the server's instructions. At the beginning of the task, the interaction process between the server and the client of the network topology manager is as follows:

[0083] 1. The server of the network topology manager receives the network topology structure given by the user and sends the relevant information to each client;

[0084] 2. The client of the Network Topology Manager confirms the number of LANs to be simulated and sets the Linux networknamespace;

[0085] 3. The client of the network topology manager configures IP addresses, routing tables and other information for each network namespace according to the network topology structure given by the user;

[0086] 4. The client of the network topology manager applies bandwidth, latency, packet loss and other restrictions to each simulated LAN;

[0087] 5. The server of the network topology manager opens the API interface, allowing users to dynamically update the network topology during runtime. The updated network topology is re-executed from step 2.

[0088] The process of configuring the topology of the client root of the network topology manager is as follows:

[0089] 1. Create a Linux network namespace for each LAN to be simulated;

[0090] 2. Determine the LANs that need to be connected to each other, configure a veth pair between each of these LANs, and put each end into the corresponding network namespace;

[0091] 3. Configure IP addresses, routing tables and other information for each network namespace to connect various LANs;

[0092] 4. Use the tc command to set bandwidth, latency, packet loss and other limits for each veth pair;

[0093] 5. Determine the devices that need to be connected to each LAN and route them to each network namespace. This completes the process.

[0094] In a real edge computing environment, the network topology is not static, so the network topology manager supports dynamic topology adjustment at runtime. As another implementation method, users can send a new network topology structure to the network topology manager through the server API interface of the network topology manager. Next, the server will calculate the difference between the new topology and the current topology, and send the parts that need to be adjusted to each client for execution. The process is the same as above.

[0095] The specific contents of the scheduling subsystem are as follows:

[0096] The scheduling subsystem is responsible for determining which worker nodes the task will run on. First, the worker nodes that do not meet the requirements should be filtered out according to the task requirements. For example, if the task requires the use of a GPU but a worker node cannot provide a GPU, the node should be excluded. After that, a scheduling algorithm should be used to select the set of worker nodes that actually undertake the task as the worker nodes. If the user does not specify, the default algorithm is used for random selection, that is, for each terminal device that requires simulation, a worker node is randomly selected.

[0097] In addition, as another implementation method, users are allowed to design their own scheduling algorithms through an API interface. In this case, the API interface will provide real-time data from the monitoring subsystem to the user side, and the user side should formulate a scheduling plan based on the acquired environmental information and provide an API interface for the scheduling subsystem to execute.

[0098] In addition, in order to allow tasks to be dynamically migrated to other devices while they are running, the scheduling subsystem also includes support for CRIU. CRIU is used to freeze processes on the Linux system and can be restored at the appropriate time. This system uses CRIU to achieve hot migration of tasks across devices. Combined with the dynamic topology function provided by the network topology manager, this system can achieve highly realistic modeling of highly dynamically changing edge computing tasks in real scenarios.

[0099] The specific contents of the rapid distribution subsystem are as follows:

[0100] Edge computing tasks sometimes involve large initial task data. For example, a machine learning task may require the initial data set to be transferred to all training nodes. In this system, the user packages all content into a container image, so the volume of this container image may be very large. In order to speed up the startup of the task, the present invention introduces a fast distribution subsystem. Fast container distribution has been practiced in the industry and is generally based on P2P technology. P2P technology is fast and can effectively utilize the available bandwidth of the entire network, making it a very good candidate technology. However, P2P technology is relatively complex to implement and has a large performance overhead (because a large number of peer relationships need to be maintained), and there are certain challenges in its application in an edge computing environment. Therefore, the present invention adopts a more lightweight means: content distribution based on IP multicast.

[0101] Since its birth, IP multicast technology has been used in limited occasions. This is mainly because IP multicast is difficult to implement in the Internet environment due to hardware support. However, considering that the system environment is relatively simple and controllable (composed of switches and routers implemented by general hardware), IP multicast can be used. The following is the high-performance task mirror transmission process based on IP multicast:

[0102] 1. The server of the fast distribution subsystem running on the management node receives the container image provided by the user;

[0103] 2. The server of the fast distribution subsystem splits the image and builds a hash tree for verification. This hash tree is sent to each working node before the transmission begins;

[0104] 3. The server of the fast distribution subsystem instructs the clients on each working node to join the multicast group and prepare to receive the image;

[0105] 4. The fast distribution subsystem server sends mirrored data to the multicast group;

[0106] 5. During the receiving process, the client on each working node verifies the data according to the hash tree to ensure data integrity.

[0107] After all transfers are completed, the process ends;

[0108] In this way, it can save the cost of nodes maintaining a large number of peer (peer or peer) relationships, and avoid introducing a large amount of redundant traffic in the network system. This method has a high cost-effectiveness in the edge computing environment.

[0109] The specific contents of the monitoring subsystem are as follows:

[0110] The monitoring subsystem is responsible for monitoring the working node's own environmental information, including the usage of system resources such as CPU, disk, and memory, as well as the running status of each task. The server of the monitoring subsystem is located on the management node, and the client is located on each working node. On the client, data about the system environment is collected through relevant system calls (i.e., using the functions of the operating system itself), and the task running status is obtained using the API of the container runtime environment (such as Docker). The data is aggregated on the client and transmitted to the server.

[0111] Users can obtain this data through the API provided by the server to observe the system operation status or formulate scheduling strategies. In addition, various anomaly detection strategies can also be connected to better ensure the robustness of the system.

[0112] The system has a large number of runtime customizable features, so it can simulate a variety of edge computing scenarios. For example, if the user needs to simulate a busy host under high load, they can arrange some tasks to occupy resources and deploy some tasks as the workload they really want to test. In this way, customized environments can be simulated as needed without the direct support of the system. Therefore, the system is very flexible.

[0113] The above is only an implementation method of the core process of the present invention. It should be pointed out that ordinary technicians in this technical field can make several improvements and modifications without departing from the concept of the present invention. These improvements and modifications should also be regarded as within the scope of protection of the present invention.

Claims

1. A lightweight simulation verification system for complex edge computing environments based on general hardware, characterized in that: The system comprises: The workload manager is responsible for receiving task requests from the user side, managing the entire process of the task from start to finish, and recycling the execution results of the working nodes and returning them to the user; The network topology manager is responsible for managing and controlling the backbone network connecting the local area networks of each work node: receiving the network topology information transmitted by the workload manager and configuring the network topology for the task; The scheduling subsystem is responsible for deciding the execution of tasks at the start and during the execution of tasks. Physical devices: after receiving the task request forwarded by the workload manager, it sends the selected working node to the workload manager; The fast distribution subsystem receives requests from the workload manager and is responsible for quickly delivering the task's container image to each selected worker node; The monitoring subsystem is responsible for collecting parameters during system runtime, which are then passed to the scheduling subsystem for decision-making tasks, and the parameters are passed to the workload manager after the task is completed.

2. According to claim 1, the lightweight simulation verification system for complex edge computing environment based on general hardware is characterized in that: The workload manager consists of two parts: the user interface and the backend: User interface, used by users to submit task requests, view task execution status, and view task execution results after the task is completed; The backend is used to manage the entire process of the task from start to finish. Its workflow is as follows: The workload manager backend receives the task request; The workload manager's backend confirms whether the system is capable of completing the task; The backend of the workload manager forwards the task request to the scheduling subsystem and receives the work node selected by the scheduling subsystem; The workload manager's backend requests the fast distribution subsystem to pass the task's container image to the worker node; The workload manager’s backend passes the network topology information to the network topology manager; The backend of the workload manager instructs each worker node to start tasks; The workload manager's backend keeps in touch with the worker nodes and monitors the tasks until they are completed; The workload manager backend collects the execution results of tasks from each worker node; The workload manager backend returns the task execution results to the user.

3. According to claim 1, the lightweight simulation verification system for complex edge computing environment based on general hardware is characterized in that: Several of the selected working nodes are divided into a group, each group is in a local area network connected by a switch, and each local area network is connected through an upper layer switch and a general device for simulating a router, wherein the general device for simulating a router is called a backbone network router; The network topology manager adopts a server-client architecture: the server is located on the management node, and the client is located on the backbone network router and is responsible for configuring the network topology of the router according to the instructions of the server.

4. The lightweight simulation verification system for complex edge computing environment based on general hardware according to claim 3 is characterized in that: When the task starts, the interaction process between the server and the client of the network topology manager is as follows: (1) The server of the network topology manager receives the network topology structure given by the user and sends the relevant information to the client of the network topology manager; (2) The client of the network topology manager confirms the number of LANs to be simulated and sets the Linux networknamespace; (3) The client of the network topology manager configures information including IP addresses and routing tables for each network namespace based on the network topology structure given by the user; (4) The client of the network topology manager applies bandwidth, latency, and packet loss constraints to each simulated LAN; (5) The server of the network topology manager opens an API interface to allow the user to dynamically update the network topology during runtime; the updated network topology is re-executed starting from step (2).

5. The lightweight simulation verification system for complex edge computing environment based on general hardware according to claim 4 is characterized in that: The process of configuring the network topology on the client side of the network topology manager is as follows: Create a Linux network namespace for each LAN to be simulated; Determine the LANs that need to be connected to each other, configure a pair of vethpairs between the LANs that need to be connected to each other, and put each end into the corresponding network namespace; Configure each network namespace with information including IP addresses and routing tables to connect various LANs; Use the tc command to set bandwidth, latency, and packet loss limits for each veth pair; Determine the devices that need to be connected to each LAN, and route the devices that need to be connected to each network namespace.

6. The lightweight simulation verification system for complex edge computing environment based on general hardware according to claim 1 is characterized in that: The workflow of the scheduling subsystem is as follows: filtering out unqualified working nodes according to task requests; and using a scheduling algorithm to select a set of working nodes that actually undertake tasks as selected working nodes.

7. The lightweight simulation verification system for complex edge computing environment based on general hardware according to claim 6 is characterized in that: The system includes an API interface for providing real-time data from the monitoring subsystem to the user side, and a working node for the user side to formulate a scheduling plan based on the real-time data and hand it over to the scheduling subsystem to execute the decision-making task.

8. The lightweight simulation verification system for complex edge computing environment based on general hardware according to claim 1 is characterized in that: The fast distribution subsystem is responsible for quickly delivering the container image of the task to each selected working node based on IP multicast; the specific transmission process is as follows: The server of the fast distribution subsystem running on the management node receives the container image provided by the user; The server of the fast distribution subsystem splits the container image and builds a hash tree for verification. This hash tree is sent to each selected working node before the transmission begins. The server of the fast distribution subsystem instructs the clients on each selected working node to join the multicast group and prepare to receive the container image; The server of the fast distribution subsystem sends container image data to the multicast group; During the receiving process, the client on each selected working node verifies the data according to the hash tree to ensure data integrity.

9. The lightweight simulation verification system for complex edge computing environment based on general hardware according to claim 1, characterized in that: The monitoring subsystem is responsible for monitoring the working node's own environmental information, including the usage of system resources such as CPU, disk, and memory, as well as the running status of each task. The parameters obtained include CPU usage, memory usage, and network bandwidth usage. The monitoring subsystem includes a server and a client. The server of the monitoring subsystem is located on the management node, and the client of the monitoring subsystem is located on each working node.

10. The lightweight simulation verification system for complex edge computing environment based on general hardware according to any one of claims 1 to 9, characterized in that: The system comprises: The end device acts as a management node, a backbone switch acts as a connection point for each LAN, and an end device acts as a simulated backbone router. Each LAN is connected to the backbone router through an upper-layer backbone switch. Several working nodes, each of which includes a switch and several end devices. Each working node network also has an end device as a router, which is connected to the backbone network switch; Several working nodes are divided into several groups of working nodes, and each group of working nodes is in a local area network connected by a switch; The server end of the network topology manager and the server end of the rapid distribution subsystem are located on the management node, the client end of the network topology manager is located on the router, and the client end of the rapid distribution subsystem is located on the working node.

Images