Node automatic arrangement and interconnection method, system and device based on virtual experiment environment and medium

Abstract

The invention discloses a node automatic arrangement and interconnection method, system and device based on a virtual experiment environment and a medium, and relates to the technical field of testing. The method comprises the following steps: analyzing virtual node attributes required in a test set, and calling a node configuration generation function to construct a node configuration file; according to the node configuration file, calling a virtual experiment environment API to automatically create virtual nodes in batches, and starting the virtual nodes; calling a virtual experiment environment API (Application Program Interface) to carry out Telnet automatic login, and configuring a Telnet script according to the node configuration file; determining a topological interconnection relationship of the virtual nodes according to the configured Telnet script, and calling a virtual experimental environment API (Application Program Interface) to complete wiring; the virtual nodes after wiring are utilized to execute testing; and after the test is completed, calling the virtual experiment environment API to delete all the created virtual nodes, and releasing resources. According to the invention, rapid and accurate configuration and automatic management of the laboratory topology can be realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of testing, in particular to a node automatic arrangement and interconnection method, system, device and medium based on a virtual experiment environment. BACKGROUND

[0002] With the development of SD-WAN (Software Defined Wide Area Network) and cloud network integration, enterprises increasingly rely on virtualized network environments in research and development and testing. Although traditional virtualization platforms (such as EVE-NG, etc.) provide underlying node simulation capabilities, there are still the following problems in actual use: 1. Nodes need to be created and configured one by one manually, which is low in efficiency and prone to errors; 2. The topology connection between nodes and networks needs to be manually dragged, which is difficult to support large-scale automated experiments; 3. The IP configuration inside the node needs to be manually logged in and operated, which is repetitive and tedious; 4. There is a lack of unified automated management framework, and the test topology is difficult to achieve standardization and reproducibility, the test suite is strongly bound to the preset environment, and the migration flexibility is poor; for individual new or verification scripts, due to the large difference in test suite requirements, it is often difficult to obtain a suitable test environment in time, resulting in low execution efficiency.

[0003] Therefore, there is an urgent need for a node automatic arrangement and interconnection method based on a virtual experiment environment to realize rapid configuration, batch deployment and automated management of laboratory topology. SUMMARY

[0004] The purpose of the present application is to provide a node automatic arrangement and interconnection method, system, device and medium based on a virtual experiment environment, which can realize rapid and accurate configuration and automated management of laboratory topology.

[0005] To achieve the above purpose, the present application provides the following solutions: In a first aspect, the present application provides a node automatic arrangement and interconnection method based on a virtual experiment environment, comprising: analyzing the virtual node attributes required in the test suite defined by the user; According to the required virtual node attributes, a node configuration generation function is called to build a node configuration file; According to the node configuration file, a virtual experiment environment API is called to automatically create virtual nodes in batches and start the virtual nodes; A Telnet automatic login is performed by calling the virtual experiment environment API, and a Telnet script is configured according to the node configuration file; Based on the configured Telnet script, determine the topology of the virtual nodes and, according to the topology of the virtual nodes, call the virtual experimental environment API to complete the wiring. Perform the test using the virtual node after wiring; After the test is completed, call the Virtual Experiment Environment API to delete all created virtual nodes and release resources.

[0006] Secondly, this application provides an automated node orchestration and interconnection system based on a virtual experimental environment, comprising: The automatic node creation module is used to parse the virtual node attributes required in the user-defined test suite; based on the required virtual node attributes, it calls the node configuration generation function to build the node configuration file; based on the node configuration file, it calls the virtual experimental environment API to automatically create virtual nodes in batches. The startup and status monitoring module is used to start virtual nodes; The Telnet configuration module is used to call the virtual experiment environment API for automated Telnet login and to configure Telnet scripts according to the node configuration file. The topology interconnection module is used to determine the topology interconnection relationship of virtual nodes according to the configured Telnet script, and to call the virtual experimental environment API to complete the wiring according to the topology interconnection relationship of virtual nodes; The progress management module uses the connected virtual nodes to execute tests; after the tests are completed, it calls the virtual experimental environment API to delete all created virtual nodes and release resources.

[0007] Thirdly, this application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and capable of running on the processor, wherein the processor executes the computer program to implement the above-described method for automated node orchestration and interconnection based on a virtual experimental environment.

[0008] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method for automated node orchestration and interconnection based on a virtual experimental environment.

[0009] According to the specific embodiments provided in this application, this application has the following technical effects: This application provides a method, system, device, and medium for automated node orchestration and interconnection based on a virtual experimental environment. It automatically parses the required virtual node attributes according to test suite needs and supports template-based generation of node configuration files, avoiding manual creation and configuration operations and improving the efficiency and accuracy of node orchestration. It calls the virtual experimental environment API for automated Telnet login and configures Telnet scripts according to the node configuration files, eliminating manual login operations. Based on the configured Telnet scripts, it determines the topology interconnection relationship of virtual nodes, achieving fully automated node-to-node direct connections and node-to-network bridging, eliminating reliance on manual drag-and-drop connections. After the test task is completed, it automatically deletes useless nodes, avoiding long-term occupation of computing resources. In summary, it achieves rapid, accurate configuration and automated management of laboratory topology. Attached Figure Description

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

[0011] Figure 1 A flowchart illustrating an automated node orchestration and interconnection method based on a virtual experimental environment, provided in an embodiment of this application; Figure 2 A schematic diagram illustrating the principle of an automated node orchestration and interconnection method based on a virtual experimental environment, provided in an embodiment of this application; Figure 3 A schematic diagram of the functional modules of a node automated orchestration and interconnection system based on a virtual experimental environment provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0014] Key terms: EVE-NG (Emulated Virtual Environment-Next Generation): A virtual network simulation platform that supports the virtualization of various network devices and system images, commonly used for network testing, experiments, and teaching. The virtual experimental environment in this application is based on EVE-NG.

[0015] CPE (Customer Premises Equipment): Network equipment deployed on the user's premises, typically serving as an edge node for enterprise access to the wide area network (WAN), such as routers and firewalls.

[0016] POP (Point of Presence): An access device located in the network of an operator or service provider, used to access and aggregate user traffic.

[0017] Client: Refers to a virtual node used to simulate end-user access. It typically runs a desktop operating system or a lightweight server system and is connected to a CPE for application access testing.

[0018] Current automated testing processes typically employ a combination of the EVE-NG virtual experimental environment and automated scripts for network function verification. While existing solutions can execute test cases via scripts to some extent, they still have significant shortcomings in test topology management and node resource scheduling, primarily in the following aspects: 1. Manual configuration issues caused by differences in test suite scenarios.

[0019] The existing automated testing process includes multiple test suites, each with different functions, and the number and types of equipment and network connection methods required also vary.

[0020] When adding a new test suite, testers must first log in to the existing EVE-NG experimental environment, manually add the required virtual nodes, and then adjust the node parameters, configure the IP address, and connect the network one by one.

[0021] This method of operation relies on human experience, which is both time-consuming and labor-intensive, and it is difficult to guarantee the consistency and correctness of the configuration.

[0022] 2. Some network tests cannot be executed via scripting.

[0023] Interconnection testing with certain devices requires specific network topology configurations. In existing solutions, these connections cannot be triggered or modified by automated scripts; instead, manual wiring operations are required on the EVE platform's graphical interface.

[0024] This results in the testing process not being fully automated, with points of interruption and manual intervention.

[0025] 3. It consumes a lot of resources and lacks an automatic recycling mechanism.

[0026] Once a test node is created in EVE-NG, it will occupy server resources (CPU, memory, disk) for a long time and will not be automatically cleaned up even after the test script finishes execution.

[0027] This not only wastes server resources, but also affects the execution efficiency of other test suites.

[0028] 4. Individual testing and verification lack convenience.

[0029] When testers write new automated test scripts, if verification is required, they must manually create the corresponding EVE nodes in advance and configure the IP address and wiring for each node.

[0030] This approach is inefficient and not conducive to rapid iteration and individual development and verification.

[0031] In summary, existing technical solutions have significant shortcomings in version subscription, information transmission, progress tracking, anomaly handling, and responsibility allocation. There is an urgent need for a comprehensive solution that can uniformly manage version targets within a CI / CD platform, automatically synchronize information, track progress in real time, handle anomalies promptly, and clearly define responsibility, so as to significantly improve the efficiency and quality of version releases.

[0032] In view of the above, in an exemplary embodiment, such as Figure 1 As shown, an automated node orchestration and interconnection method based on a virtual experimental environment is provided, including the following steps 101 to 107. Wherein: Step 101: Parse the virtual node attributes required in the user-defined test suite.

[0033] Step 102: Based on the required virtual node attributes, call the node configuration generation function to build the node configuration file.

[0034] Step 103: Based on the node configuration file, call the Virtual Experiment Environment API to automatically create virtual nodes in batches and start the virtual nodes.

[0035] Step 104: Call the virtual experiment environment API to perform automated Telnet login, and configure the Telnet script according to the node configuration file.

[0036] Step 105: Based on the configured Telnet script, determine the topology of the virtual nodes and, according to the topology of the virtual nodes, call the virtual experimental environment API to complete the wiring.

[0037] Step 106: Perform the test using the virtual node after wiring.

[0038] Step 107: After the test is completed, call the Virtual Experiment Environment API to delete all created virtual nodes and release resources.

[0039] Implementing steps 101 to 107 above enables an automated node orchestration method that can automatically create nodes, configure networks, and automate wiring according to test suite requirements, and automatically release resources as needed after the task is completed. This solves the problems of cumbersome manual configuration, difficulty in scripting topology interconnection, long-term resource occupation, and low test development efficiency in existing technologies.

[0040] In another exemplary embodiment of this application, step 101 described above may be replaced by steps 201 to 203.

[0041] Step 201: Define the attributes of virtual nodes, including their roles, number, and topological relationships.

[0042] Step 202: Based on the definition file of the test scenario or the specified parameters, parse the roles, number, and topological relationships of the required virtual nodes.

[0043] Based on the test scenario definition file (cpe_map, pop_map, client_map, etc. configuration) or the specified parameter map, parse out the required virtual node types, quantities, roles, and topological relationships: Load the definition file (YAML / JSON) into cpe_map, client_map, pop_map, and optional autoconnect; then, according to the above rules: pair the CPE and Client with the same index using the number at the end of the key name, and generate their respective configurations, names, and layouts; extract IP information from the values ​​to infer network access; if autoconnect is provided, append node ↔ node / node ↔ network connection according to the rules.

[0044] The parameter dictionary is directly used as input to cpe_map, client_map, and pop_map, and the above process is executed in the same way; the role is determined by the map name, the number is the number of valid keys of each map, and the topology is determined by three parts: "direct connection with the same index + prefix inference / default connection + autoconnect".

[0045] Step 203: Standardize the roles of the required virtual nodes into three types: CPE, POP, and Client.

[0046] The grouping from the input determines the role type of the node: CPE group → normalized to CPE; POP group → normalized to POP; Client group → normalized to Client. If an entry provides an explicit role field, the explicit field takes precedence; in case of conflict, the decision order of "explicit priority, group as fallback" is adopted. For entries that are not in any of the three main groups but have declared a role, the system merges them into one of the three basic role categories; if merging is not possible, an input inconsistency is indicated and execution is refused.

[0047] In another exemplary embodiment of this application, step 102 described above may be replaced by steps 301 to 302.

[0048] Step 301: Select the corresponding baseline template from the character template library according to the required virtual node attributes.

[0049] Node configuration generation function (module): Used to generate configuration documents for virtual nodes based on standardized roles and test suite requirements. Role template function (library): Used to maintain the baseline template set for each standardized role, providing an overridable set of default parameters for the node configuration generation module. The two are decoupled modules: the template library provides the "defaults," and the generation module produces the "final" output.

[0050] Step 302: Merge the explicit parameters of the test suite with the deduced parameters (naming, layout, etc.) of the baseline template, complete the consistency verification, and output a node configuration file that can be directly used to create virtual nodes; the node configuration file includes virtual node type, CPU, memory, image, number of interfaces, console type and initial coordinate information.

[0051] The template parameters matched for the role are as follows: (1) CPE (User Edge Equipment) Virtualization type: General purpose computing virtual machine; Resource quota: The example defaults to 2 CPU cores and 2048MB of memory; Interface scale: The example defaults to 7 Ethernet interfaces to cover access, management, and business sides; System image: Selects an image family for CPE functionality; Console and visual identifier: Uses remote console access and CPE icon; Initial layout: Provides default coordinates, which can be overridden by automatic layout or user parameters.

[0052] (2) POP (Network Access Point Equipment) Virtualization type: General purpose computing virtual machine; Resource quota: The example defaults to 2 CPU cores and 2048MB of memory; Interface scale: The example defaults to 6 Ethernet interfaces, covering uplink and management; System image: Selects an image family for POP functionality; Console and visual identifier: Uses remote console access and POP icons; Initial layout: Provides default coordinates, which can be overridden by automatic layout or user parameters.

[0053] (3) Client (Terminal / Business-side Client) Virtualization type: General purpose computing virtual machine; Resource quota: The example defaults to 2 CPU cores and 2048MB of memory; Interface scale: The example defaults to 6 Ethernet interfaces, covering business and management links; System image: Selects an image family for client operating systems; Console and visual identifier: Uses remote console access and client icons; Initial layout: Provides default coordinates, which can be overridden by automatic layout or user parameters.

[0054] The above is the set of default parameters that can be overridden. The system supports adjusting CPU, memory, number of interfaces, image, and layout by overriding fields in the scene definition or parameter map, so as to achieve differentiated configuration of the same role in different test suites.

[0055] The calling relationship between steps 101 and 102 above can be summarized as follows: test suite parsing → role normalization → baseline retrieval from role template library → node configuration generation module performs fusion / verification / output → used as input parameters for node creation.

[0056] In another exemplary embodiment of this application, after step 102 above, the method can also automatically generate node names and topology layout positions, avoiding manual repetitive input and overlapping issues. Specifically, based on node index, IP suffix, or batch hash algorithm, a unique node name for the virtual node is automatically generated; a layout algorithm is used to assign GUI coordinates to the virtual node, generating a topology layout where nodes do not overlap.

[0057] The detailed explanation of the node names is as follows: The core idea is to generate names by combining information with a fixed priority, aiming for "readable, unique, and reproducible" results.

[0058] Rules and order: Standardized roles: CPE / POP / Client (determined by group or explicit identifier).

[0059] Extract the index: Get the sequence number from the number at the end of the entry name (e.g., dut_cpe_12→12).

[0060] Select the octet of the IP suffix: prioritize mgmt_ip; if not found, select any one of wan_ip / to_cpe_eth_ip / lan_ip; take the last segment of its IPv4 (e.g., 10.5.38.90→90).

[0061] Aliases take precedence: If an entry contains an alias, it takes precedence. If a POP's alias contains multiple or cumulative aliases, only the last POP tag is retained (e.g., LW3001_POP3).

[0062] Batch prefix: If a batch name (such as name1) is provided, place it at the beginning as a prefix to improve readability across batches.

[0063] Combination rules (from highest to lowest): If there is an alias: the name is the batch prefix + alias (POP is standardized according to the above rules).

[0064] Otherwise: the name is batch prefix + role name + serial number; if the last segment of the IP is obtained, append "last segment" (e.g., name1_cpe3_90).

[0065] Special case addition: If CPE / POP extracts the end segment of mgmt_ip, then append another "end segment" to the end to quickly locate the management address (for easy retrieval and troubleshooting).

[0066] Results characteristics: The same input and batch name will generate the same name at any time; names from different batches, different indexes, or different IP suffixes are naturally distinguishable.

[0067] Layout Explanation: Objective: To ensure that nodes of the same type are arranged regularly in the interface without overlapping; to ensure that nodes in different batches are staggered to avoid overlapping; and to ensure that the layout is reproducible.

[0068] Base coordinates (based on the character's base point): CPE: Base point (left, top) ≈ (141, 96) POP: Base point ≈ (1192, 147) Client: Base point ≈ (1328, 98) Grid layout (within the same batch): Each row has a fixed number of columns (e.g., 4 columns); the horizontal spacing between columns is approximately 220, and the vertical spacing between rows is approximately 180.

[0069] Calculate columns and rows using the index idx: Column = (idx - 1) mod number of columns; Row = ... .

[0070] Node coordinates = base point + column × horizontal step + row × vertical step.

[0071] Batch misalignment (preventing overlap across batches): Calculate a stable group number from "role + batch name" (e.g., take the hash and then modulo 8) to get group_idx.

[0072] Apply a fixed offset to each group_idx: left_offset ≈ group_idx × 300, top_offset ≈ group_idx × 200.

[0073] Final coordinates = grid coordinates + batch offset. Different batches (or different characters in the same batch) will be shifted to different areas as a whole.

[0074] Conflict and safety net: If the user explicitly provides coordinates, the explicit coordinates will be used (overriding Auto Layout).

[0075] If the sequence number is missing, the default sequence number 1 will be used for grid calculation.

[0076] Since both the step size and offset are larger than the icon size, overlap is naturally avoided; the same input consistently generates the same coordinates, ensuring reproducibility.

[0077] Key points for scalability and implementation: The base point, number of columns, and step size are configurable to adapt to different canvas and node sizes.

[0078] The number of group numbers and the increment of batch offset are adjustable to accommodate larger-scale batch coexistence.

[0079] Both the layout and naming are deterministic rules, which facilitates automated alignment and regression verification.

[0080] Each virtual node is given a unique name to avoid conflicts. Left / top coordinates are automatically calculated to prevent nodes from overlapping within the GUI, improving readability.

[0081] In another exemplary embodiment of this application, device nodes are created in batches within the laboratory by calling an open API for the virtual experimental environment (such as EVE-NGAPI). Starting the virtual nodes specifically includes: simultaneously sending a start command to all virtual nodes via the virtual experimental environment API; and polling the status of each virtual node through a status query interface until each virtual node enters the running state.

[0082] In another exemplary embodiment of this application, step 104 described above may be replaced by steps 401 to 404.

[0083] Step 401: Call the Virtual Experiment Environment API to obtain the Telnet access address of the virtual node.

[0084] Step 402: Connect to the Telnet access address and establish a Telnet connection.

[0085] For example, a Telnet connection can be established by calling the Telnet module's API.

[0086] Step 403: Enter your username and password to access the node command line.

[0087] Step 404: Configure the Telnet script according to the node configuration file and write it to the virtual node.

[0088] Upload and execute the Telnet configuration script to achieve the following: i. Assign an IP address and subnet mask to the interface; ii. Modify the network configuration file (e.g., ifcfg-ethX); iii. Activate the interface and restart the network service; iv. Output the execution log and the final configuration results.

[0089] In another exemplary embodiment of this application, the target network is automatically selected based on configuration information (such as IP prefix and interface number): for example, 10.4.. automatically connects to the "WAN network bridge", and 10.5.. automatically connects to the "management network bridge". The API is called to automatically bind the corresponding virtual network to the node interface, realizing node-to-node and node-to-network bridge interconnection. Direct connection operations between nodes are supported according to rules or user-defined input (e.g., CPE ↔ Client eth0). The network interconnection relationship derivation process is as follows: Input elements: 1. Interface address information for each node (a list of "interface → IP / mask" provided by the test suite or compiled by the system).

[0090] 2. Optional "explicit interconnection rules" (e.g., a node interface must be connected to a named network, or nodes must be directly connected to each other).

[0091] 3. Role default strategy (backup wiring rules for CPE / POP / Client).

[0092] 4. Configurable prefix → network mapping table (supports prefix, CIDR or keyword).

[0093] 5. Rule priority (from high to low) 6.1) Explicit interconnection rules (autoconnect / user specified) 2) IP prefix / test suite rules (prefix or CIDR matching) 3) Role default rules (fallback)

[0094] Matching and derivation methods: 1. Standardize interface identifiers into recognizable indexes (supporting standardization of formats such as ethX, Gi slots / ports, and pure numbers).

[0095] 2. For each interface, determine the target network in the following order: 3. If an "explicit interconnect" exists, use it directly.

[0096] 4. Otherwise, perform "IP prefix / CIDR matching": 5. Perform longest prefix matching based on the configurable table (example: 10.4.0.0 / 16→WAN, 10.5.0.0 / 16→Mgmt); in case of the same score, match according to rule priority or time order.

[0097] 6. Generate a plan for "interface → network name" (e.g., eth1 → Net-10.4.xx, eth6 → Net-10.5.xx).

[0098] 7. If the target is still not hit, apply "Default Role": 8. CPE: Uplink interface → WAN (e.g., interface 1), Management interface → Mgmt (e.g., interface 6) 9. POP: Uplink interface → WAN (e.g., interface 0), Management interface → Mgmt (e.g., interface 5) 10. Client: Management interface → Mgmt (e.g., interface 5) 11. Resolve the “Network Name” into an executable “Network ID” (obtain the name→id mapping through the network query interface of the virtual platform) and generate the final “Interface→Network ID” wiring plan.

[0099] Therefore, the implementation process of step 105 above can be summarized as follows: For the interface of each virtual node: if there is an explicit interconnection rule in the configured Telnet script, the node interface defined by the explicit interconnection rule is directly used to access the network, or the nodes are directly connected to each other; if there is no explicit interconnection rule in the configured Telnet script, prefix matching is performed in the IP prefix-network mapping table to obtain the matching network; when prefix matching cannot be performed in the IP prefix-network mapping table, the role default rule is used to match the network; the matching network name is resolved into a network ID to generate the topology interconnection relationship of the virtual nodes.

[0100] Test execution and topology operation: After node configuration and network interconnection are completed, the test script is executed; each node interacts in the virtual network topology environment to complete the automated test case execution.

[0101] Automatic resource reclamation: After the test task is completed, the system automatically deletes the created virtual nodes; releases server CPU, memory and storage resources, avoids long-term resource occupation, and ensures the sustainable use of the platform.

[0102] In another exemplary embodiment of this application, the method can also perform exception handling and progress management: "errors are visible, automatically processed, and progress is traceable" throughout the entire orchestration process.

[0103] Error handling: Categorize issues into input / session / API / resource / startup / login / script, etc.; perform a limited number of retries for timeouts, 5xx errors, and session expirations; and fail directly for parameter errors and insufficient permissions.

[0104] Strategy: Retry with an exponential backoff and set an upper limit; roll back upon failure (delete existing nodes, unbind the network, and clean up temporary scripts / files) to ensure no resources are consumed.

[0105] Progress management: Update milestones and percentages by stage (certification → creation → wiring → startup → configuration → completion), and support continuing execution from the most recent successful stage.

[0106] Externally visible: Outputs structured logs and error codes, and provides a query interface for the current stage, remaining retries, and suggestions.

[0107] Figure 2 This illustrates the principle of the method in this application. Based on Figure 1 and Figure 2 The following three examples further illustrate the method of this application.

[0108] Example 1: Automated Network Testing of CPE and Client 1. Test kit input The user defines a set of test suites in the test framework, and the requirements involve a CPE node and a Client node.

[0109] Requirements specified: The CPE's eth0 interface should be directly connected to the Client's eth0 interface; the CPE's eth1 interface should be connected to the 10.4.xx WAN; the CPE's eth6 interface should be connected to the 10.5.xx management network; and the Client's eth5 interface should be connected to the 10.5.xx management network.

[0110] 2. Node configuration generation After parsing the input, the system automatically calls the character template function to generate the node configuration: CPE configuration: CPU=2 cores, memory 2048MB, image=cpe-lightwan, number of interfaces=7; Client configuration: CPU=2 cores, memory 1024MB, image=client-centos7, number of interfaces=6; The system automatically generates node names based on the index and IP suffix, and assigns GUI coordinates based on the layout algorithm to ensure that multiple nodes do not overlap.

[0111] 3. Node Creation and Startup This system automatically creates nodes in a laboratory environment using the API provided by EVE-NG.

[0112] After the batch start commands are initiated, the system monitors the running status of the nodes in real time and waits automatically until both nodes reach the "running" state.

[0113] 4. Telnet scripting configuration The system automatically obtains the Telnet address of the node, for example: telnet: / / 10.5.252.84:32769.

[0114] Establish a Telnet session, automatically complete the username and password login, and enter the node command line.

[0115] The system will write the configuration script to the node and execute it: Configure on CPE: eth1 → 10.4.38.10 / 16 eth6 → 10.5.38.10 / 16 eth0→192.168.10.254 / 24 Configure on the client: eth0 → 192.168.10.1 / 24 eth5 → 10.5.38.20 / 16 The script modifies the ifcfg-ethX file and restarts the network service to ensure configuration persistence.

[0116] 5. Automatic topology interconnection The system derives the following connection strategies based on IP prefixes and rules: CPEeth0↔Clienteth0 CPEeth1↔Net-10.4.xx CPEeth6↔Net-10.5.xx Clienteth5↔Net-10.5.xx The system calls the API to automatically complete the wiring, requiring no manual operation.

[0117] 6. Operation and Verification The test script drives the interaction between the client and the CPE node to verify whether the LAN-to-WAN forwarding is normal. The system collects the results and determines whether the test kit passes based on preset expectations.

[0118] 7. Automatic resource recycling After the test is completed, the system calls the API to automatically delete the CPE and Client nodes, freeing up memory and CPU and keeping server resources available.

[0119] Example 2: Automated Testing of POP Nodes 1. User-defined test suite, requiring a POP node, whose eth0 interface is connected to the WAN network (10.4.xx), and whose eth5 interface is connected to the management network (10.5.xx).

[0120] 2. The system generates POP node configuration (CPU=2 cores, RAM=2048MB, image=pop-secure, number of interfaces=6) and creates nodes via API.

[0121] 3. After startup, the system obtains the Telnet address and logs in automatically, executing a script to configure the network: eth0=10.4.38.170 / 16 eth5=10.5.38.170 / 16 4. The system automatically connects the node's eth0 interface to the "Net-10.4.xx" network and the eth5 interface to the "Net-10.5.xx" network.

[0122] 5. Then, the corresponding test cases are triggered to verify the POP function.

[0123] 6. After the test is completed, the POP node will be automatically destroyed to release resources.

[0124] Example 3: Multi-node batch topology In another embodiment, when the test suite defines multiple CPEs and multiple Clients, the system can execute them sequentially: 1. Automatically configure the interface relationship (eth0) for each CPE and Client pair. eth0); 2. Automatically connect all CPE nodes to the Net-10.4.xx (WAN) and Net-10.5.xx (management) networks; 3. Automatically connect all Client nodes to Net-10.5.xx (management) and automatically generate interconnection topology based on IP configuration; 4. Start all nodes in parallel and distribute network configuration scripts in batches via Telnet; 5. After the test suite is completed, all newly created nodes will be automatically cleaned up.

[0125] This example demonstrates that the application can be applied to large-scale automated testing environments, supporting batch execution of multiple test suites while maintaining high reproducibility and resource utilization efficiency.

[0126] The key technical points of this application are as follows: 1. Automated node orchestration Based on the test suite requirements, automatically parse the required node types (CPE / POP / Client), quantities, and interface topology; It supports template-based generation of node configurations (CPU, memory, image, interface, coordinates, etc.), avoiding manual operation one by one.

[0127] 2. Node lifecycle management Provides a unified API for the entire process of node creation, startup, status monitoring, and deletion; It supports batch parallel operations and automatically polls and detects node status during startup until it enters operation.

[0128] 3. Telnet script-based configuration After the node is running, it will automatically log in to the system via Telnet; Upload and execute the script to complete the configuration of the interface IP address / subnet mask, start the network service, and persist the configuration. Automatically identifies the reason for failure and supports re-login.

[0129] 4. Automatic topology interconnection The network interconnection relationship is automatically deduced based on the IP prefix / test suite rules (e.g., 10.4 segment connects to WAN, 10.5 segment connects to Mgmt). Achieve full automation of node-to-node direct connections and node-to-network bridging; It supports connecting to external networks, eliminating the need for manual drag-and-drop connections via the GUI.

[0130] 5. Automatic resource recycling It supports automatic node destruction after testing to release CPU and memory resources and avoid long-term resource occupation. Ensure the sustainability of multiple rounds of test suite operation.

[0131] 6. Automatic naming and visual layout algorithm Based on algorithms such as node indexing, IP suffix, and batch hashing, unique node names are automatically generated to avoid conflicts. Automatically calculate left / top coordinates to avoid node overlap within the GUI and improve readability.

[0132] 7. Adapt to different testing scenarios By using a unified configuration input (maps), different topologies can be automatically generated to dynamically meet various testing needs; It supports rapid personal verification, reducing development and debugging costs.

[0133] The technical points that this application seeks to protect include: 1. An automated node orchestration method based on input test suite requirements, including the entire process of node configuration generation, automatic creation, startup, Telnet configuration, topology interconnection and resource reclamation; 2. A method for automatic node configuration, characterized in that: it can automatically match the image, CPU, memory, number of interfaces and layout coordinates according to the role type (CPE / POP / Client); 3. A node lifecycle management method that uses an API to uniformly manage the creation, startup, operation monitoring, and destruction of nodes; 4. A method for setting network parameters of virtual nodes based on Telnet script configuration, which can automatically log in and batch complete IP address configuration and network service restart after the test virtual node is started; 5. An automatic topology interconnection method, capable of automatically deriving network relationships based on IP prefixes and rules, and executing connections between nodes and between nodes and the network; 6. A method for dynamic scheduling of virtual test environment resources, which supports deleting nodes to release computing resources after the test is completed, and ensures that the test environment can be recreated; 7. A node naming and layout control method, characterized in that: node names are generated based on index / IP suffix / batch hash, and a visual topology non-overlapping layout is generated through a position calculation algorithm.

[0134] Compared with the prior art, this application has the following advantages: 1. High degree of automation: It realizes the automatic creation, configuration and interconnection of the nodes required for the test suite without manual intervention.

[0135] 2. High reusability: Topology dependency configuration is automatically generated, ensuring consistency in each generation and avoiding problems caused by human differences.

[0136] 3. High resource utilization efficiency: Unused nodes are automatically deleted after the test task is completed, avoiding long-term occupation of computing resources.

[0137] 4. Supports dynamic topology adjustment: The corresponding topology can be quickly generated based on the definition of the newly added test suite, flexibly supporting different testing needs.

[0138] 5. Improved development efficiency: Individual developers no longer need to manually prepare the environment in advance for testing, which improves the speed of verifying new scripts.

[0139] Based on the same inventive concept, this application also provides a system for implementing the above-described method for automated node orchestration and interconnection in a virtual experimental environment. The solution provided by this system is similar to the implementation described in the above method. Therefore, the specific limitations of one or more embodiments of the system for automated node orchestration and interconnection in a virtual experimental environment provided below can be found in the limitations of the method for automated node orchestration and interconnection in a virtual experimental environment described above, and will not be repeated here.

[0140] In one exemplary embodiment, such as Figure 3 As shown, an automated node orchestration and interconnection system based on a virtual experimental environment is provided, including: an automatic node creation module, a startup and status monitoring module, a Telnet configuration module, a topology interconnection module, and a progress management module.

[0141] The module automatically creates virtual nodes, parsing the required attributes of the virtual nodes in the user-defined test suite. Based on these attributes, it calls the node configuration generation function to construct the node configuration file. Then, based on the configuration file, it calls the virtual experimental environment API to automatically create virtual nodes in batches. The startup and status monitoring module starts the virtual nodes. The Telnet configuration module calls the virtual experimental environment API for automated Telnet login and configures the Telnet script based on the node configuration file. The topology interconnection module determines the topology interconnection relationship of the virtual nodes based on the configured Telnet script and calls the virtual experimental environment API to complete the wiring according to this relationship. The progress management module executes tests using the wired virtual nodes; after testing, it calls the virtual experimental environment API to delete all created virtual nodes and release resources.

[0142] The progress management module can also have exception handling functions; therefore, the progress management module can also be called the exception handling and progress management module.

[0143] In one exemplary embodiment, a computer device is provided, which may be a server or a terminal, and its internal structure diagram may be as follows. Figure 4As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores created virtual nodes. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements an automated node orchestration and interconnection method based on a virtual experimental environment.

[0144] Those skilled in the art will understand that Figure 4 The structures shown are merely block diagrams of some structures related to the present application and do not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than shown in the figures, or combine certain components, or have different component arrangements. In an exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0145] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0146] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0147] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0148] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0149] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0150] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for automated node orchestration and interconnection based on a virtual experimental environment, characterized in that, include: Parse the virtual node attributes required in the user-defined test suite; Based on the required virtual node attributes, call the node configuration generation function to build the node configuration file; Based on the node configuration file, the virtual experiment environment API is called to automatically create virtual nodes in batches and start the virtual nodes. Call the virtual experiment environment API to automate Telnet login, and configure the Telnet script according to the node configuration file; Based on the configured Telnet script, determine the topology of the virtual nodes and, according to the topology of the virtual nodes, call the virtual experimental environment API to complete the wiring. Perform the test using the virtual node after wiring; After the test is completed, call the Virtual Experiment Environment API to delete all created virtual nodes and release resources.

2. The method for automated node orchestration and interconnection based on a virtual experimental environment according to claim 1, characterized in that, Parse the virtual node attributes required in the user-defined test suite, specifically including: Define the attributes of virtual nodes, including their roles, number, and topological relationships; Based on the definition file of the test scenario or the specified parameters, parse the roles, number, and topological relationships of the required virtual nodes; The required virtual node roles are standardized into three types: CPE, POP, and Client.

3. The method for automated node orchestration and interconnection based on a virtual experimental environment according to claim 1, characterized in that, Based on the required virtual node attributes, the node configuration generation function is called to construct the node configuration file, specifically including: Based on the required virtual node attributes, select the corresponding baseline template from the character template library; The explicit parameters of the test suite are fused with the derived parameters of the baseline template, and a consistency check is performed. The output is a node configuration file that can be directly used to create virtual nodes. The node configuration file includes virtual node type, CPU, memory, image, number of interfaces, console type, and initial coordinate information.

4. The method for automated node orchestration and interconnection based on a virtual experimental environment according to claim 1, characterized in that, Based on the required virtual node attributes, the node configuration generation function is called to construct the node configuration file, which then includes: Automatically generate unique node names for virtual nodes based on node index, IP suffix, or batch hash algorithm; A layout algorithm is used to assign GUI coordinates to virtual nodes, generating a topology layout in which nodes do not overlap.

5. The method for automated node orchestration and interconnection based on a virtual experimental environment according to claim 1, characterized in that, Starting a virtual node specifically includes: Send a start command to all virtual nodes simultaneously via the virtual experiment environment API; The status of each virtual node is checked by polling through the status query interface until each virtual node enters the running state.

6. The method for automated node orchestration and interconnection based on a virtual experimental environment according to claim 1, characterized in that, The system calls the virtual experiment environment API to automate Telnet login and configures the Telnet script according to the node configuration file, specifically including: Call the virtual experiment environment API to obtain the Telnet access address of the virtual node; Connect to the Telnet access address and establish a Telnet connection; Enter your username and password to access the node command line; Configure the Telnet script according to the node configuration file and write it to the virtual node.

7. The method for automated node orchestration and interconnection based on a virtual experimental environment according to claim 1, characterized in that, Based on the configured Telnet script, determine the topological interconnection relationship of the virtual nodes, specifically including: Interface for each virtual node: If there are explicit interconnection rules in the configured Telnet script, the node interface defined by the explicit interconnection rules will be used to access the network directly, or the nodes will be directly connected to each other. If no explicit interconnection rules are present in the configured Telnet script, prefix matching is performed in the IP prefix-network mapping table to obtain the matching network; When a prefix cannot be matched in the IP prefix-network mapping table, the role default rule is used to match the network. The matched network name is parsed into a network ID, and the topological interconnection relationship of the virtual nodes is generated.

8. A node automated orchestration and interconnection system based on a virtual experimental environment, characterized in that, include: The automatic node creation module is used to parse the virtual node attributes required in the user-defined test suite; based on the required virtual node attributes, it calls the node configuration generation function to build the node configuration file; based on the node configuration file, it calls the virtual experimental environment API to automatically create virtual nodes in batches. The startup and status monitoring module is used to start virtual nodes; The Telnet configuration module is used to call the virtual experiment environment API for automated Telnet login and to configure Telnet scripts according to the node configuration file. The topology interconnection module is used to determine the topology interconnection relationship of virtual nodes according to the configured Telnet script, and to call the virtual experimental environment API to complete the wiring according to the topology interconnection relationship of virtual nodes; The progress management module uses the connected virtual nodes to execute tests; after the tests are completed, it calls the virtual experimental environment API to delete all created virtual nodes and release resources.

9. A computer device, comprising: A memory, a processor, and a computer program stored in the memory and capable of running on the processor, characterized in that the processor executes the computer program to implement the node automated orchestration and interconnection method based on a virtual experimental environment according to any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the node automated orchestration and interconnection method based on the virtual experimental environment as described in any one of claims 1-7.

Images