Shooting range resource reuse and security isolation method and system in high-concurrency scene

Abstract

The invention discloses a target range resource reuse and security isolation method and system in a high-concurrency scene, and belongs to the technical field of network simulation. The method comprises the following steps: receiving a network topology and initial network parameters defined by a user, and storing the network topology and initial network parameters as a topology description file; the system supports concurrent receiving and processing of a plurality of independent instantiation requests for the same topology; distributing a unique identifier for the instance corresponding to each request; for each instance, quickly cloning the virtual device based on a copy-on-write mechanism; creating an independent network namespace for each instance, distributing a unique VXLAN network identifier from the global VNI pool, and injecting the unique VXLAN network identifier into the namespace; automatically injecting the initial network parameters as fixed configuration into each device in an instance; and finally, accessing the equipment into the exclusive namespace and starting the equipment. According to the invention, the problems of large resource consumption and difficult network isolation in a large-scale concurrent simulation scene are solved, and the concurrent processing capability and the operation efficiency of a target range system are remarkably improved.

Description

Technical Field

[0001] This invention relates to the fields of computer network simulation, virtualization, and cloud computing technologies, and specifically to a method and system that supports efficient creation of simulation instances, resource reuse, and network security isolation in a virtualized test range environment under large-scale concurrent scenarios. Background Technology

[0002] With the rapid development of information technology, the scale and complexity of network systems are increasing, and network security threats are becoming more diversified and complex. Against this backdrop, network simulation ranges, as core infrastructure capable of simulating real network environments for network technology testing, network security attack and defense drills, and technology research and development verification, are becoming increasingly important. At the same time, the large-scale development of network systems places higher demands on the high-concurrency operation capabilities of network simulation ranges.

[0003] The development of network simulation range technology can be roughly divided into three stages. The first stage is the physical equipment stage. In this stage, the range is entirely built from real physical devices, such as routers, switches, servers, and firewalls. Its advantage lies in providing extremely high environmental fidelity, accurately reflecting the performance of devices and network behavior in a real network. However, its drawbacks are also significant: high construction costs, requiring the purchase of a large number of expensive physical devices; long deployment cycles, involving complex physical wiring, device debugging, and network configuration; and poor scalability, as whenever a new network scenario needs to be built or devices added, hardware redeployment and configuration are often required, making it difficult to meet the testing needs of the rapid iteration of modern network technologies.

[0004] The second stage is the semi-virtual simulation stage. With the maturity of virtualization technologies such as VMware and KVM, a hybrid architecture of "physical core devices + virtual terminal devices" has emerged. For example, enterprises use physical firewalls in conjunction with virtual servers to build test environments. This stage reduces the cost of terminal devices to some extent, but is still limited by the number of ports and topology flexibility of the physical core devices. At the same time, network adaptation between virtual and physical devices still requires tedious debugging by professionals, and deployment efficiency has not been fundamentally improved.

[0005] The third stage is the pure virtual simulation stage. In recent years, fully virtual network testbeds have gradually become mainstream. Through Software-Defined Networking (SDN) and virtualization technologies, they enable software simulation of all network devices, including routers, switches, firewalls, etc. Currently, the industry's core needs focus on four points: first, component flexibility (supporting custom target machines and importing multi-format images); second, deployment efficiency (requiring scenario construction to be completed in minutes or even seconds); third, configuration convenience (significantly reducing the requirements for professional technical personnel); and fourth, scalability (supporting parallel and isolated operation of multiple scenarios). Although the technological direction is clear, existing solutions still have significant shortcomings in simultaneously meeting the above requirements.

[0006] For example, in a large-scale attack and defense competition, it may be necessary to provide independent and uniformly configured simulation environments for dozens or even hundreds of participating teams simultaneously. While existing mainstream virtualization network simulation platforms (such as EVE-NG and GNS3) support the construction of virtual network topologies, they have significant shortcomings in handling high-concurrency scenarios. First, resource reuse efficiency is low. Each time a new simulation scenario instance is created, a full copy of the virtual machine image is typically required, leading to a linear increase in storage space usage, low physical resource utilization, and slow instance creation speed. Second, network isolation capabilities are weak. Existing solutions mostly rely on manual or simple network partitioning (such as VLANs), making it difficult to automatically and scalably create a large number of completely isolated virtual networks. Network conflicts or leaks between different instances are prone to occur, failing to meet the strict isolation requirements of multi-tenant environments. Finally, deployment automation is insufficient. From a topology map to generating multiple isolated and usable simulation instances, the process involves multiple stages such as computing resource allocation and network isolation configuration. Existing technologies lack end-to-end automated concurrency mechanisms, making efficient batch deployment difficult.

[0007] In summary, there is an urgent need for a new technical solution to address the key technical challenges of high resource consumption and network isolation in large-scale concurrent simulation scenarios, thereby achieving fully automated management of efficient reuse of range resources and strict automatic network isolation. Summary of the Invention

[0008] The purpose of this invention is to provide a method and system for reusing and securing target range resources in high-concurrency scenarios, so as to solve the technical problems of high resource consumption and difficult network isolation in large-scale concurrent simulation scenarios in the prior art.

[0009] To achieve this objective, one aspect of the present invention provides a method for reusing and securing test range resources in high-concurrency scenarios, comprising the following steps: receiving a network topology defined by a user through a graphical interface, the network topology including multiple nodes, connections between nodes, and initial network parameters configured on the connections or nodes; storing the network topology as a topology description file; the system supports concurrent reception and processing of multiple independent instantiation requests for the topology description file, each request corresponding to the generation of a simulation scenario instance; assigning a unique instance identifier to each instance to be generated; for the i-th instance (i=1,2,..., N, where N is the total number of concurrently processed instances), executing the instantiation sub-process: S1: Based on the copy-on-write mechanism, clone a set of virtual device instances corresponding to the instance according to the node information in the topology description file; S2: Create an independent network namespace for the i-th instance, and allocate one or more unique Virtual Extensible Local Area Network (VXLAN) network identifiers for the namespace from the global resource pool; S3: Based on the initial network parameters in the topology description file, configure network parameters for each virtual device instance within the i-th instance; wherein, in different instances generated based on the same topology description file, devices at the same logical location are configured with the same network parameters; S4: Automatically inject the determined network configuration parameters into each virtual device instance corresponding to the i-th instance through the underlying configuration interface; S5: Connect the network interfaces of all virtual device instances in the i-th instance to the independent network namespace created for that instance; Start all virtual device instances in the i-th instance to form the i-th runnable, network-isolated simulation scenario. Through the above steps, multiple simulation scenario instances that are completely isolated on the network, efficiently reuse resources, and have consistent internal network configurations can be automatically and concurrently generated based on a single topology description file.

[0010] Preferably, allocating VXLAN network identifiers from the global resource pool includes: in step S2, retrieving a VNI with an idle state from the global VNI pool managed by the database, allocating it to the current instance, and marking the VNI state as occupied; when the instance is destroyed, reclaiming the corresponding VNI state as idle.

[0011] Preferably, the concurrent processing is implemented through a thread pool mechanism, whereby the system allocates a worker thread for each independent instantiation request, and each worker thread independently executes the complete instantiation sub-process from step S1 to S5.

[0012] Preferably, in step S1, cloning the virtual device instance based on the copy-on-write mechanism specifically involves: obtaining the corresponding read-only base disk image according to the virtual device component identifier; when creating the virtual device instance, linking its system disk to the base disk image in read-only mode, and creating an independent incremental disk file for the instance to save all runtime data changes.

[0013] Preferably, before receiving the user-defined network topology, a component preparation step is also included: receiving the virtual machine disk image file or system installation image file uploaded by the user, and through installation or import operations, encapsulating it into a reusable virtual device component containing a read-only base image and component metadata, and storing it in the component repository.

[0014] A second aspect of this invention provides a target range resource reuse and security isolation system for high-concurrency scenarios, comprising: a topology management module, used to provide a graphical interface for receiving user-defined network topology and initial network parameters, and generating and storing a topology description file; an instantiation request interface, used to receive one or more independent instantiation requests initiated by the user for the topology description file; an instance scheduler, used to respond to the requests, assign a unique instance identifier to each instance to be generated, and schedule independent worker threads for each request based on a thread pool mechanism to concurrently execute the instance creation process; and a resource cloning engine, used to quickly clone the corresponding virtual device instance group for each instance identifier based on a copy-on-write mechanism according to the node component identifier in the topology; The network isolation and configuration engine, which communicates with the instance scheduler and resource cloning engine, includes: a VNI management unit for maintaining the state of the global VNI resource pool and allocating and reclaiming VXLAN network identifiers for instances; an isolation environment construction unit for creating an independent network namespace for each instance identifier and placing the virtual network devices corresponding to the allocated VXLAN network identifiers within that namespace; a configuration injection unit for automatically injecting network configurations into the virtual device instances of the corresponding instance by calling the underlying interface based on the initial network parameters in the topology description file; and an instance lifecycle manager for connecting the virtual device instance groups of each instance to its dedicated network namespace and starting them, forming multiple independently running simulation scenarios.

[0015] Preferably, the system further includes a component repository module for storing and managing virtual device components, wherein the components contain read-only base images; the component repository module supports the creation of user-defined components by uploading image files.

[0016] Preferably, cloning a set of virtual device instances corresponding to the topology description file based on the copy-on-write mechanism includes: obtaining a read-only base disk image corresponding to the virtual device component; when creating a virtual device instance, linking its system disk to the read-only base disk image, and creating an independent incremental disk file for the instance.

[0017] Preferably, allocating VXLAN network identifiers from the global VNI resource pool includes: retrieving a VNI in an idle state from the global VNI pool managed by the database, allocating it to the current instance, and marking the VNI state as occupied; when the instance is destroyed, reclaiming the corresponding VNI state as idle.

[0018] Preferably, in the concurrent execution instance creation process, multiple instantiation requests are implemented through a thread pool mechanism. The instance scheduler allocates an independent worker thread for each instantiation request, and each worker thread independently executes the complete instantiation sub-process from resource cloning to instance startup.

[0019] In summary, the core of the technical solution provided in this application lies in achieving efficient resource reuse through copy-on-write, achieving strong network isolation through dynamic construction of VNI and network namespaces, and achieving high-concurrency fully automated processing through a thread pool mechanism. This solves the fundamental technical challenges of high resource consumption and difficult network isolation when rapidly generating large-scale simulation scenario instances based on the same topology template on a single physical cluster.

[0020] Compared to existing technologies, the benefits of this application are significant. First, resource utilization efficiency is improved by orders of magnitude. By cloning virtual devices through the Copy-on-Write (CoW) mechanism, all instances share a read-only base image, and changed data is written only in independent incremental blocks. This reduces the storage overhead of concurrently creating N instances of the same scenario from O(N) of traditional full copy to approximately O(1), significantly saving storage resources and enabling second-level fast cloning of instances. Second, strong network isolation is achieved under large-scale concurrency. By dynamically assigning a unique VXLAN network identifier (VNI) to each simulation scenario instance and creating an independent network namespace, the networks of different instances are completely isolated at Layer 2 (VNI tunnel isolation) and Layer 3 (namespace routing isolation), meeting the strict isolation requirements of high security and multi-tenant concurrent scenarios. Third, high-concurrency one-click deployment and elastic scaling are supported. Users only need to draw the topology once and submit multiple creation requests. The system can automatically complete the entire process from resource scheduling, instance cloning, network isolation to configuration injection through a thread pool, achieving efficient concurrent generation of simulation scenarios. Meanwhile, the architecture is easily scalable, allowing instances to be dynamically created or destroyed based on load. Fourth, it reduces operational complexity and technical barriers by encapsulating complex resource isolation and network configuration logic in high-concurrency environments within automated processes, enabling operators to easily manage large-scale concurrent simulation tasks without requiring extensive expertise in virtual networks. Attached Figure Description

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

[0022] Figure 1 This is an overall architecture diagram of a target range resource reuse and security isolation system in a high-concurrency scenario, provided by an embodiment of the present invention.

[0023] Figure 2 This is a technical architecture diagram of a target range resource reuse and security isolation system in a high-concurrency scenario, provided by an embodiment of the present invention.

[0024] Figure 3 This is a general business process diagram of a target range resource reuse and security isolation system in a high-concurrency scenario, provided by an embodiment of the present invention.

[0025] Figure 4 This is a flowchart illustrating a method for reusing and securing target range resources in a high-concurrency scenario, as provided in an embodiment of the present invention.

[0026] Figure 5 This is a functional block diagram of a target range resource reuse and security isolation system in a high-concurrency scenario, provided as another embodiment of the present invention.

[0027] Figure 6 A schematic diagram illustrating the principle of strong isolation between VNI and network namespace in one embodiment of the present invention. Detailed Implementation

[0028] 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. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0029] It should be noted that, in the description of this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0030] Example 1

[0031] This embodiment combines Figure 1 , Figure 2 and Figure 5 This invention details the system architecture and the collaborative workflow of each module in high-concurrency scenarios. The system design goal is to rapidly generate hundreds or thousands of completely isolated simulation scenario instances based on a single topology template.

[0032] Please see Figure 1 This illustrates the overall system architecture of an embodiment of the present invention. The architecture adopts a layered design, consisting of an infrastructure layer, a resource management layer, a functional service layer, and an application interface layer from bottom to top.

[0033] The infrastructure layer consists of multiple x86 physical servers supporting KVM virtualization, a Ceph distributed storage cluster providing a unified storage pool, and physical / virtual switches supporting VXLAN.

[0034] The resource management layer, built on top of the infrastructure layer, is responsible for virtualizing and pooling physical hardware resources to achieve dynamic allocation and scheduling of resources. It uses a unified virtualization management platform (such as Libvirt) to pool and manage computing, storage, and network resources.

[0035] The functional service layer is the core business logic layer of the system, which contains multiple microservices that work together and is the core of achieving high-concurrency instantiation.

[0036] The application interface layer provides a web management interface and a RESTful API to receive user operation commands.

[0037] like Figure 2 , 3 and Figure 5 As shown, where Figure 2 This invention demonstrates a microservice architecture, where the core business logic of the system is carried by the following microservice modules:

[0038] Topology Management Module: Provides a graphical web interface, allowing users to draw network topology diagrams by dragging and dropping preset or custom virtual device components. When drawing connections, users directly configure the initial network parameters for each link. Finally, the topology structure and all initial parameters are serialized into a lightweight topology description file (such as JSON format).

[0039] Instantiation Request Interface: When users need to prepare an environment for a large-scale attack and defense competition involving hundreds of participants, they can initiate multiple independent instantiation requests concurrently through this frontend or API. Each request body example contains the target topology template ID. The interface places the requests into a message queue, which is then consumed by the instance scheduler.

[0040] Instance Scheduler: As the "central control," this module consumes instantiation requests from the queue. Its core responsibilities are: first, to assign a globally unique instance identifier to each instance to be created, such as INS-001, INS-002,...; second, to formulate resource scheduling strategies based on the current cluster resource load. Most importantly, the instance scheduler maintains a thread pool. For each instantiation request, it allocates an independent worker thread from the thread pool, which is responsible for the entire instance creation process, thus enabling parallel processing of multiple instances.

[0041] Resource Cloning Engine: This engine, invoked by various worker threads, is responsible for efficiently creating virtual device instances. For instance INS-i, it performs the following operations: extracts the read-only base disk image of the corresponding component from the component repository; quickly clones the component using the Copy-on-Write (CoW) mechanism, creating a new storage volume for each virtual device of instance INS-i, with the component's base image as the parent image, forming a snapshot chain; and calls the underlying virtualization interface to define the virtual machine on the specified host machine and point its disk to the newly created CoW cloned volume.

[0042] Network Isolation and Configuration Engine: The core of achieving secure isolation between multiple instances, internally divided into three units:

[0043] VNI Management Unit: Maintains a global VNI database, recording the status (idle / occupied) of each VNI. When a VNI needs to be allocated to an instance, an idle VNI is obtained from this unit and marked as occupied. When the instance is destroyed, the VNI is reclaimed.

[0044] The isolation environment building unit dynamically constructs an independent network sandbox for each instance-identified INS-i. Specifically, this includes: obtaining a unique VXLAN network identifier (VNI) from the VNI management unit; creating an independent Linux network namespace, such as ns-INS-i; creating the corresponding VXLAN virtual interface and moving it into that namespace. A namespace can contain multiple such virtual network interfaces. The configuration injection unit directly reads the initial network parameters (user-preset fixed IPs, gateways, etc.) from the topology description file and injects these parameters as fixed configurations into all virtual devices of the instance INS-i through methods such as cloud-init, QEMU Guest Agent, or SSH automation.

[0045] Instance Lifecycle Manager: This module performs the final assembly and startup of each instance: connects the virtual network adapters of all virtual devices in instance INS-i to the virtual network devices created for this instance and located in the namespace ns-INS-i; starts all virtual machines in this instance; updates the instance status and provides feedback.

[0046] The above modules work together under the drive of worker threads. When handling concurrent requests for 100 instances, the system starts multiple worker threads simultaneously through a thread pool. Each thread independently and in parallel processes the complete creation process of an instance, thereby significantly reducing the total time.

[0047] Example 2

[0048] This embodiment combines Figure 4 The flowchart details each core operation from receiving a user request to generating N isolated instances.

[0049] Topology Design and Parameter Configuration. Users complete a typical attack and defense scenario topology design within the graphical interface of the topology management module, including nodes such as attacking machines, target machines, firewalls, and routers, and configure initial network parameters (e.g., configuring a fixed IP address for a server: 192.168.212.12). The system saves this as a topology description file, topo.json.

[0050] Submit concurrent instantiation requests. Users select topo.json through the interface and initiate N (e.g., 50) independent instance creation requests. The system instance scheduler receives these requests.

[0051] Instance identifier generation and thread scheduling. The instance scheduler generates a unique identifier sequence for 50 instances: INS-001, INS-002, ..., INS-050. Simultaneously, the scheduler allocates up to N worker threads from its thread pool, each thread bound to an instance identifier, and begins parallel execution.

[0052] Parallel Instantiation Process. The system enters the parallel processing phase, where each worker thread independently executes the following steps for its bound instance INS-i (taking thread processing INS-005 as an example): Step S1: Resource Cloning. The resource cloning engine works for INS-005. Based on the node list in topo.json, it retrieves the corresponding read-only base image from the component repository and, through the storage system's snapshot cloning function, creates a set of disks for a group of virtual device instances for INS-005 within seconds. Step S2: Network Isolation Environment Construction. The isolation environment construction unit of the network isolation and configuration engine works for INS-005. It first requests an idle VNI (e.g., 10005) from the VNI management unit, then executes a command to create the namespace ns-INS-005 and creates a VXLAN interface vxlan10005, moving it into this namespace. Step S3: Network Parameter Configuration. The configuration injection unit within the network isolation and configuration engine works for INS-005. It reads the initial network parameters configured in topo.json (e.g., a fixed IP address 192.168.212.12) and sets these parameters as the final configuration of the corresponding device within instance INS-005. Step S4: Automatic Configuration Injection. The configuration injection unit injects the network configuration determined in S3 into the virtual machine automatically. For example, for a Linux target machine, the network configuration is passed through cloud-init. Step S5: Instance Assembly and Startup. The instance lifecycle manager works for INS-005. It bridges the virtual network cards of all virtual machines in INS-005 to the virtual bridge within the namespace ns-INS-005, and then starts these virtual machines in batches. Process End. When all worker threads have completed their bound instance creation processes, concurrent processing ends. At this point, 50 simulation scenarios with the same topology as the original, completely isolated networks (different VNIs and namespaces), and identical internal device network configurations are ready for use by 50 teams simultaneously.

[0053] Please see Figure 5 The figure illustrates the system functional module block diagram of the present invention. Its workflow corresponds to Embodiment 1 and the steps described above, demonstrating a complete closed loop from topology design, concurrent request scheduling, resource cloning, network isolation construction, fixed parameter configuration to instance startup.

[0054] Example 3

[0055] This embodiment combines Figure 6 This paper provides a detailed explanation of the key technical details of resolving IP conflicts and achieving network isolation in this invention.

[0056] like Figure 6As shown, this invention constructs a dual isolation barrier at both Layer 2 and Layer 3 by creating an independent network namespace for each instance and assigning a unique VXLAN network identifier (VNI).

[0057] Layer 2 isolation based on VXLAN: Each instance is assigned a unique VNI (e.g., INS-001 uses VNI10001). All Layer 2 Ethernet frames from virtual devices within the instance are encapsulated in VXLAN tunnels with the instance-specific VNI label when forwarded over the physical network. The network infrastructure (physical switches or virtual switches) strictly distinguishes and isolates traffic based on the VNI. Therefore, broadcast or multicast frames sent by devices within instance INS-001 will never be received by devices within instance INS-002, achieving complete isolation of Layer 2 broadcast domains.

[0058] Layer 3 isolation based on network namespaces: Each instance has its own independent Linux network namespace. This means that each instance has its own independent routing table, ARP table, network interface list, iptables / Netfilter rule set, and other Layer 3 network stack resources. Even if devices within different instances are configured with the same IP address (e.g., all 192.168.212.12), because they belong to different routing domains, packets destined for other instance IP addresses cannot find a valid route within this namespace and are therefore dropped. This fundamentally prevents address conflicts and traffic leakage in the Layer 3 network.

[0059] Physical and virtual connections: such as Figure 6 As shown, all virtual network interface cards (vNICs) of instance INS-i are connected to a dedicated VXLAN virtual interface (vxlan$VNI) via a virtual bridge (vSwitch). This VXLAN interface is created and placed in the instance's dedicated network namespace (ns-INS-i). This binding relationship is established once when the instance is created, forming a complete isolated link from virtual devices to virtual network interfaces, and then to independent network protocol stacks.

[0060] Example of isolation effect: An attacking machine (IP: 192.168.212.12) in instance INS-001 attempts to scan the 192.168.212.0 / 24 network segment. Since this IP is in the same network segment as itself, but the destination address is not its own, the data packet will attempt to broadcast or search for a gateway within the namespace ns-INS-001. First, its Layer 2 packets, such as ARP requests, are restricted to the tunnel of VNI 10001. Second, even if the MAC address of the same IP device in instance INS-002 is obtained through some means, the data packet cannot be correctly forwarded across namespaces due to routing isolation. Therefore, strict network isolation is achieved, perfectly supporting multi-tenant, high-concurrency security drill scenarios.

[0061] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer programs. When the computer program is loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this disclosure are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer program can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program can be transferred from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., high-density digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0062] Those skilled in the art will understand that the various numerical designations such as "first," "second," etc., used in this disclosure are merely for the convenience of description and are not intended to limit the scope of the embodiments of this disclosure, nor do they indicate the order of events.

[0063] At least one of the features described in this disclosure can also be described as one or more, and multiple features can be two, three, four or more, and this disclosure does not impose any limitations. In the embodiments of this disclosure, for a technical feature, the technical features in that technical feature are distinguished by "first", "second", "third", "A", "B", "C" and "D", etc., and there is no sequential order or size order among the technical features described by "first", "second", "third", "A", "B", "C" and "D".

[0064] The correspondences shown in the tables of this disclosure can be configured or predefined. The values ​​of the information in each table are merely examples and can be configured to other values; this disclosure is not limiting. When configuring the correspondences between information and parameters, it is not necessarily required to configure all the correspondences shown in each table. For example, the correspondences shown in some rows of the tables in this disclosure may not be configured. Furthermore, appropriate modifications and adjustments can be made based on the above tables, such as splitting, merging, etc. The names of the parameters shown in the headers of the above tables can also use other names that the communication device can understand, and the values ​​or representations of the parameters can also use other values ​​or representations that the communication device can understand. In the implementation of the above tables, other data structures can also be used, such as arrays, queues, containers, stacks, linear lists, pointers, linked lists, trees, graphs, structures, classes, heaps, hash tables, or hash tables, etc.

[0065] The predefined terms in this disclosure can be understood as defined, pre-defined, stored, pre-stored, pre-negotiated, pre-configured, solidified, or pre-burned. Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0066] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0067] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A method for reusing and securingly isolating target range resources in high-concurrency scenarios, characterized in that, include: Receive the user-defined network topology and the initial network parameters configured on it, and store them as a topology description file; The system receives one or more independent instantiation requests for the topology description file. Multiple instantiation requests can be processed concurrently, with each request corresponding to the generation of a simulation scenario instance. A unique instance identifier is assigned to each instance to be generated. For each instance identifier, the following instantiation sub-process is executed: S1: Based on the copy-on-write mechanism, a group of virtual device instances are cloned according to the node information in the topology description file. S2: An independent network namespace is created for each instance, and one or more unique Virtual Extensible Local Area Network (VXLAN) network identifiers are allocated to this namespace from the global resource pool. S3: Based on the initial network parameters in the topology description file, network parameters are configured for each virtual device instance within the instance. Devices at the same logical location in different instances generated from the same topology description file are configured with the same network parameters. S4: The configured network parameters are automatically injected into the corresponding virtual device instances. S5: The network interfaces of all virtual device instances in the instance are connected to their respective independent network namespaces and started, forming a network-isolated simulation scenario.

2. The method according to claim 1, characterized in that, In step S2, allocating one or more unique Virtual Extensible Local Area Network (VXLAN) network identifiers from the global resource pool includes: retrieving a VNI in an idle state from the global VNI pool managed by the database, allocating it to the current instance, and marking the VNI state as occupied; when the instance is destroyed, reclaiming the corresponding VNI state as idle.

3. The method according to claim 1, characterized in that, The concurrent processing of multiple instantiation requests is achieved through a thread pool mechanism. The instance scheduler uses the thread pool to schedule and allocate a worker thread for each instantiation request to execute the complete instantiation sub-process from resource cloning to instance startup.

4. The method according to claim 1, characterized in that, In step S1, cloning a virtual device instance based on the copy-on-write mechanism includes: obtaining a read-only base disk image corresponding to the virtual device component; when creating a virtual device instance, linking its system disk to the read-only base disk image, and creating an independent incremental disk file for the instance to save data changes.

5. The method according to claim 1, characterized in that, Before receiving the user-defined network topology, the process also includes a component preparation step: receiving the virtual machine disk image file or system installation image file uploaded by the user, encapsulating it into a reusable virtual device component containing a read-only base image and component metadata, and storing it in the component repository.

6. A target range resource reuse and security isolation system for high-concurrency scenarios, characterized in that, include: The topology management module is used to generate and store topology description files containing initial network parameters; The instantiation request interface is used to receive one or more independent instantiation requests; An instance scheduler is used to respond to the request, assign a unique instance identifier to each instance, and schedule independent worker threads for each request to concurrently execute the instance creation process based on a thread pool mechanism; The resource cloning engine is used to clone a set of virtual device instances corresponding to the topology description file for each instance identifier based on the copy-on-write mechanism; The network isolation and configuration engine includes: a VNI management unit, used to maintain the state of the global VNI resource pool and to allocate and reclaim VXLAN network identifiers for instances; The isolation environment construction unit is used to create an independent network namespace for each instance identifier and place the virtual network device corresponding to the assigned VXLAN network identifier in the namespace; the configuration injection unit is used to automatically inject the initial network parameters in the topology description file into the virtual device instance of the corresponding instance; the instance lifecycle manager is used to connect the virtual device instance group of each instance to its corresponding network namespace and start it.

7. The system according to claim 6, characterized in that, Also includes: The component repository module is used to store and manage virtual device components containing read-only base images.

8. The system according to claim 6, characterized in that, Cloning a virtual device instance based on the copy-on-write mechanism includes: obtaining a read-only base disk image corresponding to the virtual device component; when creating a virtual device instance, linking its system disk to the read-only base disk image, and creating an independent incremental disk file for the instance to save data changes.

9. The system according to claim 6, characterized in that, Allocating VXLAN network identifiers from the global VNI resource pool includes: retrieving a VNI in an idle state from the global VNI pool managed by the database, allocating it to the current instance, and marking the VNI state as occupied; when the instance is destroyed, the corresponding VNI state is reclaimed to idle.

10. The system according to claim 6, characterized in that, The concurrent execution instance creation process is implemented through a thread pool mechanism, where multiple instantiation requests are executed. The instance scheduler uses the thread pool to schedule and allocate a worker thread to each instantiation request to execute the complete instantiation sub-process from resource cloning to instance startup.

Images