Cloud network orchestration method and device, storage medium and electronic equipment

Abstract

The application provides a cloud network arrangement method and device, a storage medium and an electronic device, and relates to the field of cloud network arrangement. The method comprises the following steps: receiving a natural language business intention for creating a target project in a cloud network; inputting the natural language business intention into a large language model for multi-step logical reasoning to generate a structured network configuration parameter corresponding to the target project, wherein the structured network configuration parameter comprises a subnet address mask scale and a security group rule, the subnet address mask scale is determined according to a host scale demand in the natural language business intention, and the security group rule is determined according to an access control demand in the natural language business intention; and creating corresponding network resources in the cloud network according to the structured network configuration parameter to complete network delivery of the target project. The application solves the problem that a complex network project cannot be dynamically derived and generated according to dynamic demands of a user in the cloud network.

Description

Technical Field

[0001] This application relates to the field of cloud network orchestration, to the provision of network services based on cloud computing or SDN, and particularly to a cloud network orchestration method, apparatus, storage medium, and electronic device. Background Technology

[0002] In existing technologies, during the orchestration of cloud networks, a network chain diagram or a unified network security policy can be generated at the business layer, and then the control layer can break it down and distribute it to heterogeneous network nodes for execution. However, this approach can only execute preset, rigid templates and cannot dynamically derive and generate complex network projects based on the user's dynamic needs. Summary of the Invention

[0003] This application provides a cloud network orchestration method, apparatus, storage medium, and electronic device to solve the problem that complex network projects cannot be dynamically derived and generated based on the dynamic needs of users in cloud networks.

[0004] In a first aspect, this application provides a cloud network orchestration method, comprising: receiving a natural language service intent for creating a target project in the cloud network; inputting the natural language service intent into a large language model for multi-step logical reasoning to generate structured network configuration parameters corresponding to the target project, wherein the structured network configuration parameters include a subnet address mask size and security group rules, the subnet address mask size being determined based on the host size requirements in the natural language service intent, and the security group rules being determined based on the access control requirements in the natural language service intent; creating corresponding network resources in the cloud network according to the structured network configuration parameters to complete the network delivery of the target project; and creating the network resources in the cloud network. After obtaining the source, acquire at least one performance indicator data from the cloud link of the target project, including packet loss rate, latency jitter, TCP retransmission rate, or effective throughput. If any of the performance indicator data triggers a preset fault threshold, generate a fault context containing the faulty link, the damaged service flow, and the current network topology status. Input the fault context into the large language model, and the large language model diagnoses the root cause and impact range of the target project based on the fault context. Based on the root cause, the impact range, the current network topology status, and the remaining bandwidth capacity of the existing backup path, generate a composite self-healing strategy that includes traffic tiered scheduling and dynamic capacity expansion. Perform a reconstruction operation on the target project according to the composite self-healing strategy.

[0005] Secondly, this application provides an orchestration apparatus for a cloud network, comprising: a receiving module for receiving a natural language service intent for creating a target project in the cloud network; an input module for inputting the natural language service intent into a large language model for multi-step logical reasoning to generate structured network configuration parameters corresponding to the target project, wherein the structured network configuration parameters include a subnet address mask size and security group rules, the subnet address mask size being determined based on the host size requirements in the natural language service intent, and the security group rules being determined based on the access control requirements in the natural language service intent; a creation module for creating corresponding network resources in the cloud network according to the structured network configuration parameters to complete the network delivery of the target project; and a reconfiguration module for... After creating the network resource in the cloud network, at least one performance indicator data of the cloud link in the target project is obtained, including packet loss rate, latency jitter, TCP retransmission rate, or effective throughput. If any of the performance indicator data triggers a preset fault threshold, a fault context is generated, including the faulty link, the damaged service flow, and the current network topology. The fault context is input into the large language model, which diagnoses the root cause and scope of the fault in the target project based on the fault context. Based on the root cause, the scope of impact, the current network topology, and the remaining bandwidth capacity of the existing backup path, a composite self-healing strategy including traffic tiered scheduling and dynamic capacity expansion is generated. A reconstruction operation is performed on the target project according to the composite self-healing strategy.

[0006] Thirdly, this application provides an electronic device, comprising: at least one communication interface; at least one bus connected to the at least one communication interface; at least one processor connected to the at least one bus; and at least one memory connected to the at least one bus, wherein the memory stores a computer program, and the processor executes the computer program to implement the method of any of the above.

[0007] Fourthly, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements any of the methods described above.

[0008] Compared with the prior art, the technical solution provided in this application has the following advantages: In this application, by receiving a natural language service intent for creating a target project in a cloud network; inputting the natural language service intent into a large language model for multi-step logical reasoning to generate structured network configuration parameters corresponding to the target project, wherein the structured network configuration parameters include subnet address mask size and security group rules, the subnet address mask size is determined according to the host size requirement in the natural language service intent, and the security group rules are determined according to the access control requirements in the natural language service intent; and creating corresponding network resources in the cloud network according to the structured network configuration parameters to complete the network delivery of the target project, the logical reasoning capability of the large language model for intent is used. Based on the user's natural language service intent, structured network configuration parameters including subnet address mask size and security group rules for creating the target project are inferred, thereby realizing the accurate conversion of the user's fuzzy natural language service intent into structured configuration parameters that conform to the underlying engineering logic of the cloud network, achieving the effect of automated delivery of cloud network resources. Furthermore, through the self-healing strategy after the target project is created, the target project achieves accurate and timely self-healing. Attached Figure Description

[0009] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0010] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0012] Figure 1 A flowchart illustrating the cloud network orchestration method provided in this application embodiment; Figure 2 A flowchart illustrating a cloud network orchestration method for single-cloud, multi-cloud, or hybrid cloud network scenarios provided in this application embodiment; Figure 3 A flowchart illustrating the adjustment of target items according to a second intent in an orchestration method for a cloud network provided in this application embodiment; Figure 4 A flowchart illustrating a cloud network orchestration method provided in this application, which involves inputting natural language business intent into a large language model for multi-step logical reasoning; Figure 5 A flowchart illustrating the use of a syntax-constrained decoding header for an orchestration method of a cloud network provided in this application embodiment; Figure 6 A flowchart illustrating a cloud network orchestration method provided in this application for determining whether a gray fault has occurred based on multiple performance index data; Figure 7 A schematic diagram of a hybrid cloud scenario provided in an embodiment of this application; Figure 8 An intent recognition diagram illustrating an orchestration method for a cloud network provided in an embodiment of this application; Figure 9 A system architecture diagram provided for an embodiment of this application; Figure 10 A flowchart illustrating a fault self-healing process is provided as an embodiment of this application; Figure 11 A schematic diagram of the structure of an orchestration device for a cloud network provided in an embodiment of this application; Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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, 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.

[0014] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0015] The following will describe in detail, with reference to specific implementation methods, a cloud network orchestration method provided in the embodiments of this application, such as... Figure 1 As shown, the above method includes: S102, Receive natural language business intent for creating a target project in the cloud network; S104, input the natural language business intent into the large language model for multi-step logical reasoning to generate structured network configuration parameters corresponding to the target project. The structured network configuration parameters include the subnet address mask size and security group rules. The subnet address mask size is determined according to the host size requirements in the natural language business intent, and the security group rules are determined according to the access control requirements in the natural language business intent. S106. Based on the structured network configuration parameters, create the corresponding network resources in the cloud network to complete the network delivery of the target project. S108, after creating the network resource in the cloud network, acquire at least one performance indicator data of the cloud link in the target project, including packet loss rate, latency jitter, TCP retransmission rate, or effective throughput; if any of the performance indicator data triggers a preset fault threshold, generate a fault context including the faulty link, the damaged service flow, and the current network topology status; input the fault context into the large language model, and the large language model diagnoses the root cause and impact range of the target project based on the fault context; and generate a composite self-healing strategy including traffic hierarchical scheduling and dynamic capacity expansion according to the root cause, the impact range, the current network topology status, and the remaining bandwidth capacity of the existing backup path; and perform a reconstruction operation on the target project according to the composite self-healing strategy.

[0016] This application relates to a network service provision solution based on cloud computing or Software-Defined Networking (SDN), which can be applied in various scenarios, such as the setup of cloud application development and testing environments. With existing technologies, development teams need to frequently create test environments, requiring coordination with network engineers each time, resulting in extremely high communication costs. Using the solution in this application, developers simply input: "Build me a test environment, approximately 150 servers, allowing only the bastion host (e.g., 192.168.1.100) to access it." The application's large-scale model automatically infers the required / 24 subnet mask for 150 hosts and derives security group rules that only allow Internet Protocol (IP) access to the bastion host, completing the creation and delivery of the Virtual Private Cloud (VPC), subnet, and security group with a single click.

[0017] Alternatively, it can be applied to compliant network isolation and deployment scenarios in the financial industry. Financial clients have extremely high security and compliance requirements, and network deployment must strictly adhere to the principle of least privilege. Manual configuration is highly susceptible to security vulnerabilities caused by accidentally opening ports. With the solution proposed in this application, security compliance personnel input: "Create a core trading zone accommodating 500 hosts. The security policy should only allow access from the internal network database cluster (IP segment 10.0.0.0 / 16) via port 3306, and deny all public network access." Then, the large-scale model in this application calculates a reasonable mask size based on 500 hosts and accurately derives the inbound security group rules for the source IP 10.0.0.0 / 16, destination port 3306, and protocol Transmission Control Protocol (TCP), ensuring that the delivered network environment 100% complies with security audit requirements.

[0018] Other scenarios will not be exemplified. The core solution of this application in various scenarios is to perform multi-step logical reasoning on the input natural language business intent through a large language model, generate structured network configuration parameters, and automatically create the target project in the cloud network based on the subnet address mask size and security group rules.

[0019] To achieve the above process, this application uses the following method.

[0020] First, the system receives natural language business intents for creating a target project in the cloud network. In this application, a natural language business intent is a description of the business purpose and core requirements of a cloud network project that a user (such as business personnel, developers, or operations personnel) wants to build, using everyday human natural language. In practical applications, business personnel or operations personnel can use a human-computer interaction interface (such as a dialog box, chatbot, or Application Programming Interface (API)) to input their business requirements for creating a cloud network project using natural language. This natural language business intent typically includes descriptions of business dimensions such as business scale and access control requirements. For example, a user might input: "Help me create a test environment for an e-commerce promotional activity, which needs to accommodate approximately 200 servers, and for security reasons, only allow the operations bastion host IP (such as 192.168.1.100) to access the environment's backend management port." After the user generates a natural language business intent, the natural language business intent is input into the large language model for multi-step logical reasoning to generate structured network configuration parameters corresponding to the target project.

[0021] The Large Language Model (LLM) in this application does not perform simple text translation, but rather executes multi-step logical reasoning to accurately transform unstructured business language into underlying network engineering parameters. The specific reasoning process includes: Subnet mask size calculation: The large language model first parses the host size requirement in natural language (e.g., "200 servers"), and then performs mathematical calculations based on the IP address planning rules of the cloud network. The model infers that accommodating 200 hosts requires at least 254 available IP addresses, therefore automatically calculating and determining that the subnet mask size should be / 24.

[0022] Derivation of Security Group Rules: The large language model further analyzes the access control requirements in natural language (such as "only allow the bastion host IP to access the backend management port") and transforms them into specific network security policies. The model derives the corresponding security group rule as follows: In the inbound direction, allow traffic with a source IP of 192.168.1.100, a destination port of the backend management port (such as 22 or 3389), and a TCP protocol to pass through, and deny all other inbound traffic.

[0023] Finally, the large language model integrates the above calculations and derivations to generate structured network configuration parameters (such as JavaScript Object Notation (JSON) format files conforming to cloud vendor API specifications) that include the subnet address mask size ( / 24) and security group rules.

[0024] In the process of creating corresponding network resources in the cloud network based on structured network configuration parameters to complete the network delivery of the target project, since the structured network configuration parameters currently only include the subnet address mask size and security group rules, the corresponding network resources are created based on these two parameters.

[0025] After obtaining the JSON file, the corresponding network resources are created in the cloud network based on the structured network configuration parameters in the JSON file to complete the network delivery of the target project. In this application, a cloud network orchestrator can be used to parse the JSON file and automatically call the underlying cloud vendor's API interface to perform the creation of physical and logical resources. Specific operations include: The orchestrator, based on the resolved subnet address mask size ( / 24), requests and divides the corresponding subnet (Subnet / VSwitch) within the specified VPC, and configures the corresponding routing table for it.

[0026] Based on the derived security group rules, the orchestrator calls the security group API to create a dedicated security group entity, and sends inbound and outbound access control policies to the security group. Then, it binds the security group to the subnet created above.

[0027] Through the above automated operations, the system can accurately complete the creation and delivery of network resources for the target project without human intervention, completely eliminating the risk of address conflicts or security policy configuration omissions caused by manual calculation of network segments. It can flexibly create cloud network projects based on human natural language, shortening the delivery cycle from days to minutes.

[0028] This application utilizes the logical reasoning capabilities of a large language model to generate structured network configuration parameters corresponding to the target project. This is achieved by receiving a natural language business intent for creating a target project in a cloud network; inputting the natural language business intent into a large language model for multi-step logical reasoning to generate structured network configuration parameters corresponding to the target project. These structured network configuration parameters include subnet address mask size and security group rules. The subnet address mask size is determined based on the host size requirements in the natural language business intent, and the security group rules are determined based on the access control requirements in the natural language business intent. Based on these structured network configuration parameters, corresponding network resources are created in the cloud network to complete the network delivery of the target project. This process leverages the logical reasoning capabilities of the large language model to derive structured network configuration parameters, including subnet address mask size and security group rules, for creating the target project based on the user's natural language business intent. This accurately transforms the user's ambiguous natural language business intent into structured configuration parameters that conform to the underlying engineering logic of the cloud network, thereby achieving automated delivery of cloud network resources. Furthermore, a self-healing strategy after the target project is created enables accurate and timely self-healing of the target project.

[0029] As an optional implementation method, the cloud network can be a single-cloud network, a multi-cloud network, or a hybrid cloud network, such as... Figure 2 As shown, the above method also includes: S202, If the network is a hybrid cloud network, the structured network configuration parameters also include network environment classification parameters, which are determined based on the network interoperability requirements in the natural language service intent.

[0030] In this application, users can create target projects on single-cloud networks, multi-cloud networks, or hybrid cloud networks using natural language.

[0031] In real-world enterprise architectures, business operations often need to collaborate across public clouds and on-premises data centers (Internet Data Centers, IDCs). To address this scenario, this embodiment uses a large language model to automatically identify network connectivity requirements and generate corresponding network environment classification parameters, thereby breaking down network barriers in hybrid clouds.

[0032] Upon receiving the user's natural language business intent, this application first determines the type of cloud network architecture upon which the target project relies using a large language model. If the system identifies that the target project involves resources from only a single cloud vendor, it is determined to be a single-cloud network; if it involves resources from multiple public cloud vendors, it is determined to be a multi-cloud network; if the user's intent involves interaction between public cloud resources and local data center (IDC) or private cloud resources, it is determined to be a hybrid cloud network.

[0033] When a cloud network is determined to be a hybrid cloud network, the large language model will perform deep semantic analysis on the natural language business intent. In addition to the subnet address mask size and security group rules extracted from single-cloud or multi-cloud networks, it will also extract the network interconnection requirements and determine the network environment classification parameters accordingly.

[0034] For example, when a user inputs a natural language business intent such as, "Create a hybrid cloud project that requires direct access to the local IDC database and allows bastion host access," the large language model identifies this core interoperability requirement—direct access to the local IDC database—through multi-step logical reasoning. Based on this requirement, the large language model automatically determines the project's network environment classification parameter as hybrid cloud direct access type.

[0035] Finally, the large language model generates structured network configuration parameters that include network environment classification parameters.

[0036] In the process of creating corresponding network resources in the cloud network based on structured network configuration parameters to complete the network delivery of the target project, the structured network configuration parameters include subnet address mask size, security group rules, and network environment classification parameters. Therefore, corresponding network resources are created based on these three parameters. The large language model integrates the network environment classification parameters with the aforementioned generated subnet address mask size and security group rules to generate complete structured network configuration parameters. For example, when the network environment classification parameters are determined to be hybrid cloud pass-through type, the large language model will automatically append the underlying configuration instructions required for cross-domain interconnection to the structured configuration parameters. For example, it will automatically generate parameters for creating a Cloud Enterprise Network (CEN) or a Virtual Private Network Gateway (VPN Gateway) and automatically plan the routing announcement policy between the public cloud VPC network segment and the local IDC intranet network segment. The cloud network orchestrator parses the structured file containing network environment classification parameters, automatically calls the public cloud vendor's API to create cross-domain gateways and routing configurations, and simultaneously establishes physical or logical tunnels with the local data center network via leased lines or Software-Defined Wide Area Network (SD-WAN) interfaces. In this way, the system not only completes the creation of cloud subnets and security groups, but also automatically establishes network links between the cloud and the local data center, achieving one-click automated delivery of hybrid cloud projects.

[0037] As an optional implementation method, such as Figure 3 As shown, after creating corresponding network resources in the cloud network according to the structured network configuration parameters to complete the network delivery of the target project, the above method also includes: S302, Receive a second intent for configuring the target project; S304, the second intent is input into the large language model for multi-step logical reasoning to generate second configuration parameters corresponding to the target project; wherein, if the second intent includes external network access requirements, the second configuration parameters include network address translation gateway configuration and elastic public IP configuration; or, if the second intent includes high concurrency requirements, the second configuration parameters include load balancer configuration parameters; or, if the second intent includes storage configuration requirements, the second configuration parameters include storage capacity and performance requirement parameters; or, if the second intent includes elastic scaling requirements, the second configuration parameters include scaling rule configuration. S306, adjust the target project in the cloud network according to the second configuration parameters.

[0038] In this application, after the initial delivery of the target project, new network requirements often arise as business develops. This embodiment, by receiving a second intent, utilizes a large language model for multi-step logical reasoning to achieve dynamic adjustment and expansion of existing cloud network resources. The second intent, like the natural language business intent, is generated through a mechanism similar to that of user-input natural language requests.

[0039] In this application, after the network delivery of the target project is completed based on the initial structured network configuration parameters, the system can continuously monitor the user's subsequent business needs. When the user needs to add or modify the configuration for the delivered project, they can input a second intent through the human-computer interaction interface. This second intent usually reflects new needs generated during business operation, such as: "The project is ready to go online and public network access needs to be enabled," "Business traffic is surging and load balancing needs to be configured," or "Data volume is skyrocketing and storage needs to be expanded."

[0040] The second intent is input into a large language model for multi-step logical reasoning to generate the second configuration parameters. Specifically, the large language model can combine the current network state of the target project to perform multi-step logical reasoning on the second intent and generate the corresponding second configuration parameters. Depending on different business needs, the reasoning process can be divided into the following typical scenarios: External network access requirement scenario: If the large language model recognizes that the second intent contains requirements such as "enable public network access" or "allow external users to access", then it infers and generates the second configuration parameters. These parameters specifically include the configuration information of the Network Address Translation Gateway (NAT Gateway) and the allocation and binding rules of the Elastic IP Address (EIP).

[0041] High-concurrency scenarios: If the large language model recognizes that the second intent contains requirements such as "traffic surge" or "load balancing is required", then it infers and generates second configuration parameters. These parameters specifically include the creation instructions for the load balancer (SLB / Elastic Load Balancing, ELB), the listening port configuration, and the mounting rules for the backend server group.

[0042] Storage configuration requirement scenario: If the large language model recognizes that the second intent contains requirements such as "expand storage" or "improve disk performance", then it infers and generates the second configuration parameters. These parameters specifically include the capacity of the new cloud disk, the storage type (such as a high-performance solid state drive (SSD)) and the mount point configuration.

[0043] Elastic scaling requirement scenario: If the large language model recognizes that the second intent contains requirements such as "automatic scaling" or "responding to sudden traffic", then it infers and generates the second configuration parameters. These parameters specifically include scaling group configuration, scaling rules (such as triggering scaling when CPU utilization is greater than 70%), and cooldown time settings.

[0044] After the large language model generates the second configuration parameter, the cloud network orchestrator parses the parameter and automatically calls the underlying cloud vendor's API to perform adjustment operations on the delivered target project. Specific operations include: For external network access requirements, the orchestrator automatically creates a NAT gateway, requests elastic public IPs, and binds the public IPs to the NAT gateway, while adding a default route to the NAT gateway in the routing table. For high concurrency requirements, the orchestrator automatically creates a load balancer instance, configures a listener, and adds existing server instances from the target project to the backend server group. For storage configuration requirements, the orchestrator automatically creates cloud disks of specified capacity and type and mounts them to the specified server instances. For elastic scaling requirements, the orchestrator automatically creates scaling groups and scaling configurations, and binds preset scaling rules, enabling the target project to dynamically add or remove instances based on real-time load.

[0045] In this way, users can configure or adjust cloud network projects using natural language, greatly improving the efficiency and accuracy of project configuration and adjustment.

[0046] As an optional implementation method, such as Figure 4 As shown, the natural language business intent is input into the large language model for multi-step logical reasoning, including: S402, obtain the topology data of the cloud network; S404 converts the topology graph structure data into a topology vector matrix; S406 converts natural language business intent into a text word sequence; S408 inputs the topological vector matrix and the text word sequence into the large language model. Through the topological vector cross-attention module of the large language model, the topological vector matrix and the text word sequence are fused to generate a fused feature vector, and multi-step logical reasoning is performed based on the fused feature vector.

[0047] Since this application utilizes a large language model, it is crucial that the large language model accurately understands the natural language business intent to obtain structured network configuration parameters (or understands the second intent to obtain the second configuration parameters). Because general-purpose large language models typically lack the ability to perceive the physical network topology, the generated network configurations are often logically disconnected. Therefore, this application introduces a topology vector cross-attention module to enable the large language model to truly "understand" the network physical structure, thereby generating accurate structured network configuration parameters (second configuration parameters). The specific process is as follows.

[0048] First, the cloud network topology graph data is acquired and transformed. Before performing multi-step logical reasoning, this application acquires the current cloud network topology graph data in real time through a cloud network monitoring interface or SDN controller. This topology graph data typically exists in the form of a graph, containing network nodes (such as VPCs, routers, switches, etc.) and physical or logical connection edges between nodes. In this application, this topology graph data can be converted into a topology vector matrix so that the large language model can perform mathematical operations.

[0049] In the process of converting the topology graph structure data into a topology vector matrix in this application, the topology graph structure data of the cloud network can be parsed to identify all network nodes (such as VPCs, subnets, routers, gateways, etc.) and the physical or logical connection edges between nodes. Then, a [database name] is created. The square matrix is ​​used as the topological adjacency matrix (where (The total number of network nodes). Traverse all edges in the topology graph; if a node... With nodes If an edge exists, a value of 1 is assigned to the corresponding position in the adjacency matrix (or, for a weighted graph, the value is the link's bandwidth, latency, or other weights); if no edge exists, a value of 0 is assigned. This adjacency matrix accurately describes the connection status and physical topology between nodes in the cloud network.

[0050] Further extract the attribute information of each network node (such as node type, IP segment, availability zone, current load status, etc.), and encode the attributes of each node into a low-dimensional feature vector. Then, extract all... The feature vectors of each node are stacked row by row to generate a... The node feature matrix (where (Dimension of node features).

[0051] Finally, the above generated Topological adjacency matrix and The node feature matrices are combined (either through matrix concatenation or as different input channels of a graph neural network) to form a topological vector matrix for input to a large language model.

[0052] In addition to converting the cloud network topology data into a topology vector matrix, this application also converts natural language business intents. Using natural language processing (NLP) techniques, the received NLP business intent (such as "Create a test environment, which needs to connect to the existing database cluster") is converted into a text token sequence. A token is the smallest unit of text segmentation in NLP. Converting the NLP business intent into a text token sequence allows it to be combined with the topology vector matrix.

[0053] In this application, the generated topology vector matrix and the text word sequence are input into a large language model. During the internal processing of the large language model, a specially designed TopologyVector Cross-Attention Module is used to perform deep feature fusion on the topology vector matrix and the text word sequence.

[0054] The fusion process involves using textual terms as query vectors and the topological vector matrix as key and value vectors. An attention mechanism is then used to calculate the association weights between textual intent and network physical nodes. This process enables the large language model to understand user business intent while simultaneously perceiving and fusing the real physical topology of the current cloud network in real time, ultimately generating a fused feature vector that integrates network topology and business intent.

[0055] The large language model performs subsequent multi-step logical reasoning based on the aforementioned fused feature vectors. Since the fused feature vectors already contain both business requirements and physical topology information, the large language model can automatically avoid already occupied IP network segments when deriving subnet address mask sizes and security group rules, and ensure that the generated security group rules match existing network routing paths. This approach eliminates the possibility of the large model generating logically disconnected and invalid network configurations, significantly improving the accuracy of cloud network orchestration.

[0056] As an optional implementation, the output layer of the large language model integrates a syntax constraint decoding head; such as Figure 5 As shown, the natural language business intent is input into a large language model for multi-step logical reasoning to generate structured network configuration parameters corresponding to the target project, including: S502 verifies the currently generated lexical units of the large language model in real time through the syntax mask in the syntax constraint decoding head; S504, if the currently generated lexical does not conform to the preset application programming interface specification of the cloud network, the output of the currently generated lexical is blocked by the syntax mask; S506, resample from the candidate lexical set that conforms to the preset application programming interface specification to generate structured network configuration parameters that conform to the preset application programming interface specification.

[0057] In this application, since the structured network configuration parameters (or second configuration parameters) identified and output by the large language model may not be accurate, a monitoring mechanism is provided. By integrating a syntax constraint decoding head into the model output layer, the mismatch between the parameters output by the large language model and the cloud network is fundamentally eliminated.

[0058] In this application, the output layer of the large language model deployed at the bottom layer is specifically integrated with a syntax-constrained decoding head. This decoding head has a pre-built syntax tree or regular expression rule of the cloud network's preset application programming interface (API) specification, and is configured with a syntax masker for real-time compliance verification when the model generates each lexical unit.

[0059] During the process of generating structured network configuration parameters step by step through multi-step logical reasoning based on fused feature vectors in the large language model, the syntax constraint decoding head intercepts and verifies each word that the model is currently predicting and preparing to output. The system compares the word with the pre-set cloud network API specification to determine whether it conforms to the expected grammatical structure (e.g., whether a JSON key should be output, or whether a valid port number should be output).

[0060] If the syntax mask detects that the currently generated token does not conform to the cloud vendor's default application programming interface specification (e.g., the model attempts to output a non-existent cloud resource type, or outputs an illegal character), the syntax mask will immediately block the output of the offending token.

[0061] By dynamically updating the candidate word list at the current generation position, the probability of all words that do not conform to the API specification is forced to negative infinity (or an extremely low value), thereby constructing a candidate word set containing only compliant words. The large language model is then forced to resample probabilities from this compliant candidate word set to output the correct words.

[0062] This application employs a word-by-word constraint mechanism of generation-verification-blocking-resampling to strictly confine the large language model within legal grammatical boundaries throughout the entire inference and generation process. Ultimately, the structured network configuration parameters output by the large language model (such as a complete JSON configuration file) conform to the cloud vendor's API specifications, ensuring that the cloud network orchestrator can seamlessly parse and successfully execute subsequent physical resource creation operations.

[0063] As an optional implementation, in this application, after creating the network resources in the cloud network, at least one performance indicator data among packet loss rate, latency jitter, TCP retransmission rate, or effective throughput of the cloud link in the target project can be obtained; if any of the performance indicator data triggers a preset fault threshold, a fault context including the faulty link, the damaged service flow, and the current network topology status is generated; the fault context is input into the large language model, and the large language model diagnoses the root cause and impact range of the fault in the target project based on the fault context; and according to the root cause, the impact range, the current network topology status, and the remaining bandwidth capacity of the existing backup path, a composite self-healing strategy including traffic hierarchical scheduling and dynamic capacity expansion is generated; and a reconstruction operation is performed on the target project according to the composite self-healing strategy.

[0064] This application provides a self-healing method for cloud network projects in the event of intermittent or near-failure conditions.

[0065] In actual cloud network operation, links often experience gray faults—performance degradation without complete failure. This application utilizes the thought chain reasoning of a large language model to diagnose the root cause and generate a composite self-healing strategy.

[0066] After the network delivery of the target project is completed, this application continuously acquires real-time performance metrics data of the cloud link through telemetry components deployed at each network node. These metrics data include, but are not limited to, at least one of packet loss rate, latency jitter, TCP retransmission rate, or effective throughput.

[0067] The fault threshold in this application can be determined based on empirical values. Alternatively, the threshold can be dynamically adjusted. Different services have different tolerances for latency and packet loss. For example, the core payment transaction flow is extremely sensitive to latency jitter, and its fault threshold should be set more stringently than that of the offline log synchronization flow. Furthermore, the type of network endpoint (such as office terminals, servers, and IoT devices) and differences in protocol version compatibility can be identified to generate specific fault thresholds for particular environments.

[0068] When any performance metric triggers a preset fault threshold (i.e., performance deteriorates severely but the physical link is not completely interrupted), the system automatically packages the current fault link identifier, the affected damaged service flow, and the current network topology status to generate a complete fault context.

[0069] The above describes the judgment of single performance index data. This application also proposes a method to determine whether to generate a composite self-healing strategy by combining multiple performance index data with the total fault threshold.

[0070] like Figure 6 As shown, the above method also includes: S602, if the performance index data includes multiple items, then each performance index data is compared with the historical baseline obtained based on the historical normal range; S604 normalizes the degree of deviation from the historical baseline to obtain a single outlier score; S606 assigns corresponding weights based on the impact of each performance indicator on network health. S608, the individual abnormality scores are summed with their corresponding weights to obtain the comprehensive fault score; S610, based on the comprehensive fault score and the total fault threshold, determine whether a gray fault has occurred, wherein the gray fault is a fault in which performance is severely degraded but the physical link is not completely interrupted.

[0071] For example, this application can establish historical normal ranges as baselines for various parameters (such as packet loss rate, one-way and round-trip latency, TCP retransmission rate, effective throughput degradation rate, etc.). When a parameter is collected in real time, the system will compare the parameter with the historical baseline, calculate the degree to which it deviates from the normal range, and convert the degree of deviation into a single abnormal score between 0 and 1 (the closer the score is to 1, the more serious the abnormality of the indicator).

[0072] Based on the magnitude of different parameters' impact on network health, each parameter is assigned a corresponding weight (e.g., packet loss rate and TCP retransmission rate are assigned higher weights, while latency and application timeout are assigned medium weights). The system multiplies the individual anomaly score of each parameter by its weight and then sums them to obtain the final comprehensive fault score. Based on the comprehensive fault score and the overall fault threshold, it determines whether a gray fault (i.e., poor performance but not yet a complete failure) has occurred.

[0073] After confirming the occurrence of a gray fault, logical judgments are made using the combined relationships between multiple parameters to accurately distinguish the specific type of gray fault: Physical link degradation type: If it manifests as high packet loss rate and high TCP retransmission rate, but the latency only increases slightly, it is judged to be fiber optic aging or physical interface quality degradation.

[0074] Intermediate node congestion type: If the packet loss rate is extremely low, but the latency and jitter are extremely high and the TCP receive window is frozen, it is determined to be an intermediate network device buffer overflow or a traffic burst.

[0075] Finally, the identified gray fault types and detailed parameters are packaged together as a fault context.

[0076] The generated fault context can be input into the large language model. The large language model combines historical cases and real-time topology from the Retrieval-Augmented Generation (RAG) knowledge base to initiate thought chain reasoning. First, it diagnoses the root cause of the fault in the target project (e.g., optical attenuation of a cross-cloud dedicated line, congestion of a cloud vendor's gateway, etc.) and accurately tracks all business flows affected by the fault and their priorities.

[0077] The knowledge base in this application can be continuously populated with success cases as the cloud network is configured and adjusted (described below). In addition, the initial knowledge base can be built using pre-defined domain prior knowledge, such as cloud vendor network product API documentation, architecture white papers, best practice guidelines, manually processed and archived network troubleshooting records and standard operating procedures accumulated by the enterprise in the past, current and historical network physical / logical topology diagrams, IP address allocation tables, routing policies, etc.

[0078] Furthermore, regarding the knowledge base, during the target project construction phase, the large language model can be limited to using the initial knowledge base, excluding successful cases. During the fault self-healing phase, the large language model can be limited to using the successful case library and the live network topology map library, etc. This limits the retrieval scope of the knowledge base for different stages. This allows the large language model to retrieve knowledge from more relevant libraries based on the different task stages, reducing the amount of data retrieved and improving the retrieval hit rate.

[0079] To prevent noise, expired routing policies, or low-relevance information in the knowledge base from interfering with LLM decisions, this application uses metadata constraints and timeliness for filtering. For the initial candidate set, strong conditional filtering is performed in conjunction with metadata: Timeliness / Expiration Filtering: Resources marked as offline / expired (e.g., the corresponding cloud vendor API version has been deprecated, or the routing policy creation time is far beyond the validity period) are automatically filtered out; Topology and Cloud Vendor Strong Matching Filtering: If the current failure occurs on a "cloud to IDC dedicated line", specific self-healing policies that only apply to other clouds are forcibly filtered out to ensure that the retrieved information completely overlaps with the current environment.

[0080] After identifying the root cause and scope of the failure using a knowledge base, the large language model further queries the remaining bandwidth capacity of existing backup paths in the current network topology and performs capacity assessment. Based on the assessment results, the large language model generates a composite self-healing strategy that includes traffic tiered scheduling and dynamic capacity expansion. Specifically, if the remaining bandwidth of the backup paths is insufficient to handle all affected service flows, the large language model prioritizes scheduling core service flows with a priority higher than a preset threshold (such as payment transaction flows) to existing backup paths to ensure the continuity of core services. For lower-priority non-core service flows (such as log reporting flows) within the affected service flows, the large language model automatically generates instructions to call the cloud vendor's API, immediately opening a pay-as-you-go temporary disaster recovery dedicated line to handle the overflow of non-core traffic.

[0081] The thought chain in this application can be configured, and the thought chain reasoning process described above can be configured as follows: analyze the fault type and the extent of business damage, compare the total damaged traffic with the available bandwidth of the backup path, assess the avalanche risk, decide whether to adopt a tiered traffic switching or dynamic expansion composite strategy, generate specific route modification strategies and channel creation strategies, assess the link utilization and security risks after traffic switching, and output the final compliant JSON orchestration instructions.

[0082] The cloud network orchestrator receives a structured, composite self-healing strategy generated by a large language model and automatically invokes the underlying cloud network interface to perform reconstruction operations. Specific operations include: modifying Border Gateway Protocol (BGP) routing weights or SDN flow tables to direct core service traffic to the backup gateway; simultaneously, invoking the cloud vendor's interface to create a temporary disaster recovery leased line and binding it to the routing table of non-core service flows. Through this reconstruction operation, cross-cloud service connectivity is restored without causing congestion on the backup link.

[0083] As an optional implementation, after performing a refactoring operation on the target project according to the composite self-healing strategy, the above method further includes: Continuously monitor the performance metrics of the cloud link in the target project; If the monitoring results meet the self-healing conditions, the fault context, composite self-healing strategy, and performance indicators obtained from monitoring will be encapsulated into a new success case and stored in the knowledge base. Update or remove historical cases from the knowledge base based on their confidence level. When the number of newly added successful cases reaches a preset threshold, the large language model is fine-tuned offline using the newly added successful cases.

[0084] This application further provides the continuous learning capability of a large language model in cloud network operation and maintenance. In a real cloud network environment, network architecture and business models are constantly evolving, and traditional static rules and knowledge bases are easily outdated. This embodiment constructs a closed-loop feedback mechanism to transform each successful self-healing experience into learnable knowledge for the model, enabling the model to continuously improve.

[0085] After performing a reconstruction operation on the target project according to the composite self-healing strategy, real-time performance metrics (such as packet loss rate, latency jitter, and effective throughput) of the cloud link in the target project can be continuously monitored. The reconstructed performance metrics are compared with the baseline data before the fault was triggered to objectively evaluate the actual effectiveness of the self-healing strategy. If the real-time performance metrics show a significant improvement compared to before reconstruction, the strategy is considered effective.

[0086] If the monitoring results confirm that the network performance has recovered, that is, the preset self-healing success conditions are met (e.g., the value drops to the normal range), the system will automatically trigger the knowledge recording operation, which will encapsulate the fault context of this event (including faulty links, damaged service flows, etc.), the composite self-healing strategy generated by the large language model, and the performance indicators after recovery obtained from the monitoring in a structured way to form a high-quality success case, and store it securely in the system's RAG (Retrieval Enhanced Generation) knowledge base.

[0087] To prevent outdated network architectures or obsolete cloud vendor APIs from interfering with the reasoning of large language models, the system performs lifecycle management on historical cases in the knowledge base. Specifically, the system dynamically calculates and updates the confidence weight of historical cases based on changes in the cloud network environment, API version iterations, and the frequency of successful calls to historical cases. For outdated cases with confidence scores below the safety threshold or those that have not been hit for a long time, the system will automatically perform degradation or eviction operations to ensure that the knowledge base always retains the latest and most accurate operational experience.

[0088] When the number of newly added successful cases in the knowledge base reaches a preset threshold (e.g., 50 new cases covering different fault scenarios), the system will automatically trigger an offline fine-tuning task for the large language model. These high-quality new successful cases will be used as training data to update the underlying parameters of the large language model in a targeted manner. Through this offline fine-tuning, the large language model thoroughly internalizes the temporary experience in the external knowledge base into its own long-term memory, thereby enabling it to generate optimal strategies more quickly and accurately in future network orchestration and fault self-healing.

[0089] This application also provides a mechanism for validating and correcting the natural language business intent input by the user, ensuring that the final generated network configuration is executable and conflict-free.

[0090] The first level of validation and error correction mechanism is integrity validation. When user input information is missing or logically ambiguous (e.g., only "Starting a new service requires connection to the IDC," but without providing the expected number of hosts or access control requirements), the system checks whether the critical slot information is complete. If critical slots (such as host size, access permissions, internal / external network requirements) are missing, the LLM will not directly issue incorrect configurations, but will instead generate clarification prompts to guide the user to complete the information or provide default recommended values.

[0091] The second level of verification and error correction mechanism is physical network rule and resource conflict verification. If the user's input intent violates network physical rules or contains logical conflicts (such as requesting a / 28 subnet but needing to accommodate 300 hosts, or a requested Classless Inter-Domain Routing (CIDR) segment conflicting with an existing VPC / IDC), the initial parameters derived by the LLM (such as CIDR / 28) are verified by a deterministic network verification engine and the multi-cloud IP address management system before generating JSON. Automatic capacity correction: The verification engine forcibly corrects the mask to / 24 (capable of accommodating 251 hosts) and marks the reason for the correction in the feedback log; Network segment overlap correction: The verification engine compares the existing network routing table. If it finds that the generated CIDR 10.0.1.0 / 24 is already in use, it will automatically retrieve and replace it with an unused network segment, such as 10.0.2.0 / 24, from the available CIDR pool.

[0092] Figure 7 This is a schematic diagram of a hybrid cloud scenario proposed in this application. In this hybrid cloud scenario, the IDC is connected to six other clouds. Users can initiate natural language business intents, which are analyzed and understood by a large language model combined with a knowledge base, outputting structured network configuration parameters including subnet address mask size, security group rules, and network environment classification parameters. Figure 8 As shown, the user's intent is inferred by LLM, which parses the environment classification, calculates the mask, and parses the security group to obtain the network segment configuration in the VPC of the development environment of project A.

[0093] Figure 9 This is a system architecture diagram of this application. The user's intent is parsed by the intent parser, combined with cloud data obtained from the hybrid cloud API, and fed to the LLM. The LLM is a large language model that has been fine-tuned for the domain by combining the RAG knowledge base. After constructing joint features of intent and cloud architecture based on the prompt word construction engine, intent recognition is performed, the recognition result is obtained, and the target item is created. The telemetry component monitors the link, obtains performance index data, and generates a composite self-healing strategy based on the state matrix to adjust the target item.

[0094] Figure 10This is a flowchart of the fault self-healing process described in this application. When a gray fault warning is triggered, the perception layer collects performance index data, converts it into a fault context, and then passes it to the LLM for inference. The LLM provides a composite self-healing strategy. If the strategy is effective, successful cases are generated and summarized into the knowledge base for offline training of the LLM.

[0095] This application also provides a cloud network orchestration device, such as Figure 11 As shown, it includes: The receiving module 1102 is used to receive natural language business intent for creating a target project in the cloud network; Input module 1104 is used to input natural language business intent into the large language model for multi-step logical reasoning to generate structured network configuration parameters corresponding to the target project. The structured network configuration parameters include subnet address mask size and security group rules. The subnet address mask size is determined according to the host size requirements in the natural language business intent, and the security group rules are determined according to the access control requirements in the natural language business intent. Create module 1106 to create corresponding network resources in the cloud network based on structured network configuration parameters in order to complete the network delivery of the target project; The reconstruction module 1108 is used to, after creating the network resources in the cloud network, obtain at least one performance indicator data of the cloud link in the target project, including packet loss rate, latency jitter, TCP retransmission rate, or effective throughput; if any of the performance indicator data triggers a preset fault threshold, a fault context is generated, including the faulty link, the damaged service flow, and the current network topology status; the fault context is input into the large language model, which diagnoses the root cause and impact range of the target project based on the fault context; and a composite self-healing strategy including traffic hierarchical scheduling and dynamic capacity expansion is generated based on the root cause, the impact range, the current network topology status, and the remaining bandwidth capacity of the existing backup path; and a reconstruction operation is performed on the target project according to the composite self-healing strategy.

[0096] This application can be applied in various scenarios, such as building cloud application development and testing environments. With existing technology, development teams need to frequently create test environments, requiring network engineers each time, resulting in extremely high communication costs. Using this application's solution, developers simply input: "Build me a test environment, requiring approximately 150 servers, allowing only the bastion host (e.g., 192.168.1.100) to access it." The application's large-scale model automatically infers the required / 24 subnet mask for 150 hosts and derives the Internet Protocol (IP) security group rules that only allow access to the bastion host, completing the creation and delivery of the Virtual Private Cloud (VPC), subnet, and security group with a single click.

[0097] Alternatively, it can be applied to compliant network isolation and deployment scenarios in the financial industry. Financial clients have extremely high security and compliance requirements, and network deployment must strictly adhere to the principle of least privilege. Manual configuration is highly susceptible to security vulnerabilities caused by accidentally opening ports. With the solution proposed in this application, security compliance personnel input: "Create a core trading zone accommodating 500 hosts. The security policy should only allow access from the internal network database cluster (IP segment 10.0.0.0 / 16) via port 3306, and deny all public network access." Then, the large-scale model in this application calculates a reasonable mask size based on 500 hosts and accurately derives the inbound security group rules for the source IP 10.0.0.0 / 16, destination port 3306, and protocol Transmission Control Protocol (TCP), ensuring that the delivered network environment 100% complies with security audit requirements.

[0098] Other scenarios will not be exemplified. The core solution of this application in various scenarios is to perform multi-step logical reasoning on the input natural language business intent through a large language model, generate structured network configuration parameters, and automatically create the target project in the cloud network based on the subnet address mask size and security group rules.

[0099] In this application, the following approach is employed: receiving a natural language business intent for creating a target project in a cloud network; inputting the natural language business intent into a large language model for multi-step logical reasoning to generate structured network configuration parameters corresponding to the target project. These structured network configuration parameters include subnet address mask size and security group rules. The subnet address mask size is determined based on the host size requirements in the natural language business intent, and the security group rules are determined based on the access control requirements in the natural language business intent. Based on these structured network configuration parameters, corresponding network resources are created in the cloud network to complete the network delivery of the target project. This approach utilizes the logical reasoning capability of the large language model to infer structured network configuration parameters for creating the target project, including subnet address mask size and security group rules, based on the user's natural language business intent. This achieves the precise conversion of the user's ambiguous natural language business intent into structured configuration parameters that conform to the underlying engineering logic of the cloud network, thereby realizing the automated delivery of cloud network resources.

[0100] Other examples of this application can be found in the examples above, and will not be repeated here.

[0101] like Figure 12 As shown, this application provides an electronic device including a processor 111, a communication interface 112, a memory 113, and a communication bus 114, wherein the processor 111, the communication interface 112, and the memory 113 communicate with each other through the communication bus 114.

[0102] Memory 113 is used to store computer programs.

[0103] In one embodiment of this application, the processor 111, when executing a program stored in the memory 113, implements the method provided in any of the foregoing method embodiments.

[0104] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method provided in any of the foregoing method embodiments.

[0105] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0106] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0107] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0108] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A cloud network orchestration method, characterized in that, include: Receive natural language business intents for creating a target project in the cloud network; The natural language service intent is input into a large language model for multi-step logical reasoning to generate structured network configuration parameters corresponding to the target project. The structured network configuration parameters include subnet address mask size and security group rules. The subnet address mask size is determined according to the host size requirements in the natural language service intent, and the security group rules are determined according to the access control requirements in the natural language service intent. Based on the structured network configuration parameters, corresponding network resources are created in the cloud network to complete the network delivery of the target project; After creating the network resource in the cloud network, at least one performance indicator data of the cloud link in the target project is obtained, including packet loss rate, latency jitter, TCP retransmission rate, or effective throughput. If any of the performance indicator data triggers a preset fault threshold, a fault context is generated, including the faulty link, the damaged service flow, and the current network topology. The fault context is input into the large language model, which diagnoses the root cause and scope of the fault in the target project based on the fault context. Based on the root cause, the scope of impact, the current network topology, and the remaining bandwidth capacity of the existing backup path, a composite self-healing strategy including traffic tiered scheduling and dynamic capacity expansion is generated. A reconstruction operation is performed on the target project according to the composite self-healing strategy.

2. The method according to claim 1, characterized in that, The method further includes: If the network is a hybrid cloud network, the structured network configuration parameters also include network environment classification parameters, which are determined based on the network interoperability requirements in the natural language service intent.

3. The method according to claim 1, characterized in that, After creating corresponding network resources in the cloud network according to the structured network configuration parameters to complete the network delivery of the target project, the method further includes: Receive a second intent for configuring the target project; The second intent is input into the large language model for multi-step logical reasoning to generate a second configuration parameter corresponding to the target item; Wherein, if the second intent includes external network access requirements, the second configuration parameters include network address translation gateway configuration and elastic public IP configuration; or, if the second intent includes high concurrency requirements, the second configuration parameters include load balancer configuration parameters; or, if the second intent includes storage configuration requirements, the second configuration parameters include storage capacity and performance requirement parameters; or, if the second intent includes elastic scaling requirements, the second configuration parameters include scaling rule configuration. Adjust the target project in the cloud network according to the second configuration parameters.

4. The method according to any one of claims 1 to 3, characterized in that, The step of inputting the natural language business intent into the large language model for multi-step logical reasoning includes: Obtain the topology data of the cloud network; Convert the topology graph structure data into a topology vector matrix; Convert the natural language business intent into a text word sequence; The topological vector matrix and the text word sequence are input into the large language model. The topological vector cross-attention module of the large language model is used to fuse the features of the topological vector matrix and the text word sequence to generate a fused feature vector. The multi-step logical reasoning is then performed based on the fused feature vector.

5. The method according to any one of claims 1 to 3, characterized in that, The output layer of the large language model integrates a syntax constraint decoding head; the step of inputting the natural language business intent into the large language model for multi-step logical reasoning to generate structured network configuration parameters corresponding to the target project includes: The syntax mask in the syntax constraint decoding head is used to verify the currently generated lexical units of the large language model in real time. If the currently generated lexical does not conform to the preset application programming interface specification of the cloud network, the output of the currently generated lexical is blocked by the syntax mask; Resample from the candidate lexicon set that conforms to the preset application programming interface specification to generate the structured network configuration parameters that conform to the preset application programming interface specification.

6. The method according to any one of claims 1 to 3, characterized in that, The method further includes: If the performance index data includes multiple items, then each performance index data item is compared with the historical baseline obtained based on the historical normal range; The degree of deviation from the historical baseline is normalized to obtain an individual anomaly score; Assign corresponding weights based on the magnitude of the impact of each performance metric on network health. The individual anomaly scores are weighted and summed with their corresponding weights to obtain the comprehensive fault score. Based on the comprehensive fault score and the total fault threshold, it is determined whether a gray fault has occurred, wherein the gray fault is a fault in which performance is severely degraded but the physical link is not completely interrupted.

7. The method according to any one of claims 1 to 3, characterized in that, After performing a reconstruction operation on the target project according to the aforementioned composite self-healing strategy, the method further includes: Continuously monitor the performance metrics data of the cloud link in the target project; If the monitoring results meet the self-healing conditions, the fault context, the composite self-healing strategy, and the performance indicators obtained from the monitoring are encapsulated into a new success case and stored in the knowledge base. The confidence level of historical cases in the knowledge base is updated or eliminated. When the number of newly added successful cases reaches a preset threshold, the newly added successful cases are used to fine-tune the large language model offline.

8. A cloud network orchestration device, characterized in that, include: The receiving module is used to receive natural language business intents for creating target projects in the cloud network; The input module is used to input the natural language business intent into the large language model for multi-step logical reasoning to generate structured network configuration parameters corresponding to the target project. The structured network configuration parameters include subnet address mask size and security group rules. The subnet address mask size is determined according to the host size requirement in the natural language business intent, and the security group rules are determined according to the access control requirements in the natural language business intent. A creation module is used to create corresponding network resources in the cloud network according to the structured network configuration parameters, so as to complete the network delivery of the target project; The reconstruction module is used to, after creating the network resources in the cloud network, acquire at least one performance indicator data of the cloud link in the target project, including packet loss rate, latency jitter, TCP retransmission rate, or effective throughput; if any of the performance indicator data triggers a preset fault threshold, a fault context is generated, including the faulty link, the damaged service flow, and the current network topology status; the fault context is input into the large language model, which diagnoses the root cause and impact range of the target project based on the fault context; and, based on the root cause, the impact range, the current network topology status, and the remaining bandwidth capacity of the existing backup path, a composite self-healing strategy including traffic tiered scheduling and dynamic capacity expansion is generated; and a reconstruction operation is performed on the target project according to the composite self-healing strategy.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method as described in any one of claims 1-7.

10. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method as claimed in any one of claims 1 to 7.

Images