Network-configured orchestration deployment method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application provide a network configuration orchestration deployment method and device, electronic equipment and storage medium, which can be used in the field of communication technology. The method comprises: in response to receiving a networking change request, generating a configuration type set; the configuration type set contains at least one configuration type to be changed and the affected network elements related to each configuration type; the network elements include at least one of site, device and interface; for each configuration type in the configuration type set, a corresponding orchestration task and deployment task are created and added to the task sequence; and the tasks in the task sequence are executed to realize the orchestration deployment of network configuration. The present application provides a general orchestration deployment method for different networking scenarios, and processes based on task flow, realizes the integration of orchestration and deployment, and effectively improves the overall orchestration and deployment performance of the SDN controller.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method, apparatus, electronic device, and storage medium for orchestrating and deploying network configurations. Background Technology

[0002] Software-defined networking (SDN) controllers are used to uniformly manage network devices. SDN controllers support automated orchestration and deployment of network configurations to meet dynamic business needs. Improving the performance of SDN controllers during orchestration and deployment is a pressing issue that needs to be addressed. Summary of the Invention

[0003] This application provides a method, apparatus, electronic device, and storage medium for orchestrating and deploying network configurations to improve the performance of SDN controllers.

[0004] In a first aspect, embodiments of this application provide a method for orchestrating and deploying network configurations, including:

[0005] In response to receiving a network topology change request, a configuration type set is generated; the configuration type set contains at least one configuration type to be changed and the affected network elements related to each configuration type; the network elements include at least one of sites, devices, and interfaces;

[0006] For each configuration type in the set of configuration types, create corresponding orchestration tasks and deployment tasks, and add them to the task sequence;

[0007] Execute the tasks in the task sequence to orchestrate and deploy the network configuration.

[0008] In some embodiments, the step of generating a configuration type set in response to receiving a network change request includes:

[0009] Receive network change requests sent by user equipment;

[0010] Based on the network change request, determine the network elements in the current network architecture that need to be changed;

[0011] Obtain the configuration template corresponding to the network type of the current network architecture;

[0012] The configuration types related to the network element to be changed are traversed from the configuration template, and the traversed configuration types and the related affected network elements are added to the configuration type set.

[0013] In some embodiments, determining the network elements that need to be changed in the current network architecture based on the network change request includes:

[0014] The network topology change request is parsed to obtain target network element information; the target network element information is used to represent the changed network element indicated by the user.

[0015] The current network element information of the current network architecture is compared with the target network element information to obtain the network elements that need to be changed.

[0016] In some embodiments, the task sequence further includes the execution order of the tasks; the step of creating corresponding orchestration tasks and deployment tasks for each configuration type in the configuration type set and adding them to the task sequence includes:

[0017] Iterate through the set of configuration types and, for the currently iterated configuration type, perform the following operations:

[0018] Determine whether the configuration type requires cross-device orchestration;

[0019] If the configuration type does not require cross-device orchestration, then create orchestration tasks for each network device related to the configuration type, add the created orchestration tasks to the task sequence, and set the execution order information for the created orchestration tasks;

[0020] For each orchestration task created, determine whether the orchestration task is a task that is processed independently by the controller; if the orchestration task is not a task that is processed independently by the controller, then create a deployment task corresponding to the orchestration task, add the deployment task to the task sequence, and set the execution order information for the deployment task.

[0021] Determine whether the configuration type has a configuration dependency relationship with other configuration types;

[0022] If the configuration type has a configuration dependency relationship with other configuration types, additional execution order information is added to the execution order information of each deployment task corresponding to the configuration type. The additional execution order information is used to indicate the execution order between the deployment task and the tasks corresponding to other configuration types.

[0023] In some embodiments, it also includes:

[0024] If the configuration type requires cross-device orchestration, then multiple network devices related to the configuration type are grouped according to preset device association relationships to obtain multiple groups;

[0025] Create orchestration tasks corresponding to each of the aforementioned groups, add the created orchestration tasks to the task sequence, and set the execution order information for the created orchestration tasks.

[0026] In some embodiments, it also includes:

[0027] If the orchestration task is a task that the controller processes independently, then determine whether the configuration type has a configuration dependency relationship with other configuration types;

[0028] If the configuration type has a configuration dependency relationship with other configuration types, additional execution order information is added to the execution order information of each orchestration task corresponding to the configuration type. The additional execution order information is used to indicate the execution order between the orchestration task and the tasks corresponding to other configuration types.

[0029] In some embodiments, the task sequence is a directed acyclic graph, where vertices in the directed acyclic graph represent tasks, and directed edges between vertices represent the execution order of tasks; the directed edges are either unidirectional or bidirectional.

[0030] In some embodiments, the task sequence further includes the execution order of the tasks; executing the tasks in the task sequence includes:

[0031] Activate the tasks in the task sequence that have no preceding dependencies;

[0032] Determine the thread and executor corresponding to the task without prerequisite dependencies;

[0033] The thread and the executor are used to execute the task without prerequisites;

[0034] After completing the task without prerequisites, determine whether the task without prerequisites has a next-level task.

[0035] If a next-level task exists, execute that next-level task until no next-level task exists.

[0036] In some embodiments, the task without prerequisites is an orchestration task; determining the thread and executor corresponding to the task without prerequisites includes:

[0037] An idle thread in the orchestration thread pool is identified as the thread corresponding to the task without prerequisite dependencies;

[0038] The executor corresponding to the task type without prerequisite dependencies is determined as the executor corresponding to the prerequisite dependent task; the task type is a tunnel orchestration type, a route orchestration type, or a route policy orchestration type.

[0039] In some embodiments, executing the next-level task if a next-level task exists includes:

[0040] If a next-level task exists, then that next-level task is triggered;

[0041] If all the parent tasks that have a task dependency relationship with the next-level task have been completed, the next-level task is determined to be successfully activated and is then executed.

[0042] In some embodiments, when the next-level task is a deployment task, executing the next-level task includes:

[0043] The network device corresponding to the next-level task is determined, and the target deployment thread pool corresponding to the network device is determined from multiple deployment thread pools; each deployment thread pool is a single-threaded pool.

[0044] Determine the executor corresponding to the task type of the next-level task; the task type is a tunnel deployment type, a route deployment type, or a route policy deployment type.

[0045] The next-level task is executed using threads from the target deployment thread pool and the executor.

[0046] In some embodiments, it also includes:

[0047] For any task in the task sequence, when starting to execute the task, the task status of the task is updated from "not executed" to "in execution", and when the task is completed, the task status of the task is updated from "in execution" to "execution successful".

[0048] In some embodiments, it also includes:

[0049] If an exception occurs during the execution of the task, the task status will be updated to execution failure.

[0050] The task is retried until the number of retries reaches a preset threshold or until the task is successfully executed; or, in response to receiving a rollback request from the user equipment, the network configuration of the current network architecture is rolled back to the state before the network change request was received, and the network configuration is rearranged and deployed again.

[0051] In some embodiments, it also includes:

[0052] In response to receiving a progress query request from a user equipment, a request processing progress information is sent to the user equipment. The request processing progress information includes the service status, the task status and task information of each task in the task sequence, so that the user equipment can display the request processing progress information. The service status is either request processing in progress or request processing completed. The task information includes at least one of the following: task type, network elements related to the task, and configuration type.

[0053] Secondly, embodiments of this application provide a network configuration orchestration and deployment apparatus, comprising:

[0054] A generation module is used to generate a configuration type set in response to receiving a network change request; the configuration type set includes at least one configuration type to be changed and the affected network elements related to each configuration type; the network elements include at least one of sites, devices and interfaces;

[0055] A creation module is used to create corresponding orchestration tasks and deployment tasks for each configuration type in the configuration type set, and add them to the task sequence;

[0056] The execution module is used to execute tasks in the task sequence to orchestrate and deploy network configurations.

[0057] Thirdly, embodiments of this application provide an electronic device, including: a processor and a memory communicatively connected to the processor;

[0058] The memory stores computer-executed instructions;

[0059] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0060] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0061] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0062] The network configuration orchestration and deployment method, apparatus, electronic device, and storage medium provided in this application, upon receiving a network change request, can make more targeted changes by accurately locating the configuration type to be changed and the affected network elements, avoiding unnecessary resource consumption. This helps optimize network resource utilization and improve overall network performance. Furthermore, by creating corresponding orchestration and deployment tasks based on the configuration type to be changed, each task focuses on a specific configuration type, reducing task complexity and the risk of cross-influence. This reduces the possibility of configuration errors during task execution. Moreover, creating tasks according to configuration type increases the possibility of parallel task processing, thereby reducing dependencies and waiting times between tasks and improving task execution efficiency. Therefore, this application provides a general orchestration and deployment method for different network scenarios, achieving integrated orchestration and deployment and effectively improving the overall orchestration and deployment performance of the SDN controller. Attached Figure Description

[0063] 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.

[0064] Figure 1 This is a schematic diagram of an application scenario provided in this application;

[0065] Figure 2 This is a flowchart illustrating a network configuration orchestration and deployment method provided in this application;

[0066] Figure 3 This is a flowchart illustrating another network configuration orchestration and deployment method provided in this application;

[0067] Figure 4 This is a schematic diagram of an SDWAN networking architecture before modification provided in this application;

[0068] Figure 5 This is a schematic diagram of a modified SDWAN networking architecture provided in this application;

[0069] Figure 6 This is a schematic diagram of the structure of a network configuration orchestration and deployment device provided in this application;

[0070] Figure 7 This is a schematic diagram of the structure of an electronic device provided in this application.

[0071] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0072] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0073] The SDN controller provides a centralized control plane, enabling unified management of network devices and simplifying network configuration and management. In some application scenarios, such as Virtual Private Network (VPN) service provisioning, network configuration and deployment can be automated through network templates or scenarios, reducing manual configuration workload. Therefore, improving the performance of the SDN controller is a pressing issue that needs to be addressed.

[0074] Based on this, this application proposes a network configuration orchestration and deployment method, apparatus, electronic device and storage medium, aiming to solve the above-mentioned technical problems.

[0075] Figure 1 A schematic diagram illustrating an application scenario provided in this application, such as... Figure 1 As shown, this application scenario includes user equipment 10, server 20, and multiple network devices 30 (for ease of representation, ...). Figure 1 (Example using only 3 network devices).

[0076] An SDN controller is a software application responsible for managing and controlling the behavior of network devices. The SDN controller runs on a server, which can be a physical server, a virtual machine, or an instance in a containerized environment. In this application, an SDN controller is installed on server 20, which can be used to implement the orchestration and deployment methods for the network configurations provided in this application.

[0077] The SDN controller provides a unified management platform, and server 20 provides backend services for this management platform. Users can log in to the management platform on user equipment 10 to manage and control multiple network devices 30.

[0078] Network device 30 is a hardware device used to establish, manage, and maintain network connections, responsible for data transmission, routing, and management. Exemplary examples of network device 30 include switches, routers, firewalls, load balancers, wireless access points, or network-attached storage devices, but it is not limited to these. In the SDN architecture, the control plane functions of network devices are abstracted into the SDN controller, while the network devices themselves are primarily responsible for data plane operations. This architecture allows network administrators to centrally manage and configure network devices through the SDN controller, thereby simplifying network management and improving network flexibility and scalability.

[0079] The network configuration orchestration and deployment method provided in this application is implemented by a network configuration orchestration and deployment device, which is integrated into an electronic device. For example, the electronic device is the aforementioned server 20.

[0080] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0081] Figure 2 This is a flowchart illustrating a network configuration orchestration and deployment method provided in this application. For example... Figure 2 As shown, the network configuration orchestration and deployment method provided in this embodiment includes the following steps:

[0082] Step S101: In response to receiving a network change request, a configuration type set is generated; the configuration type set contains at least one configuration type to be changed and the affected network elements related to each configuration type; the network elements include at least one of sites, devices and interfaces.

[0083] In one scenario, a user logs into the management platform corresponding to the SDN controller using a user device, and modifies the relevant configuration information of the current network architecture on the management platform page. This triggers the user device to send a network change request to the server that provides backend services to the SDN controller.

[0084] The network change request is used to instruct on the orchestration and deployment of network configurations for the current network architecture. The request carries information about the target network elements and the action type of the change. This target network element information represents the network elements after the user-instructed change to the current network architecture. Network elements include sites, network devices, and interfaces. Change actions are categorized into the following types: add, update, delete, add on the controller side, and delete on the controller side. The change action determines the processing method during orchestration. For example, add: create configuration and deploy; update: update configuration and deploy; delete: undeploy configuration and delete; add on the controller side: create configuration without deployment; delete on the controller side: delete configuration without deployment.

[0085] In this context, a site refers to a physical location or geographic location that may contain one or more network devices. For example, a site could be an office, data center, factory, or any place that requires network connectivity. The relationship between a site and network devices is that network devices are typically installed within a site to enable its network functionality. An interface refers to a port or connection point on a network device, used to connect to other devices or networks. For example, an interface can be physical (such as an Ethernet port) or logical (such as a VPN interface). The relationship between an interface and a network device is that an interface is part of the network device, providing the means for the network device to communicate with other devices.

[0086] For example, the network elements in the current network architecture include site A, network device 1, network device 2, interface a, interface b, and interface c. If a user wants to update network device 1 to network device 3, they can modify the relevant configuration information of network device 1 to network device 3 on the management platform page and trigger a network change request. The target network element information included in this network change request includes site A, network device 3, network device 2, interface a, interface b, and interface c. The action type of the change action is update, specifically updating network device 1 to network device 3.

[0087] Optionally, the network change request may also include other information, such as the device identifier corresponding to the user equipment and the account identifier corresponding to the account currently logged into the user equipment. The device identifier is used to uniquely identify the user equipment to distinguish different user equipment. The account identifier is used to uniquely identify the account to distinguish different accounts.

[0088] The configuration type set contains at least one element, which consists of a configuration type to be changed and the affected network elements related to that configuration type. This application does not limit the data structure of the configuration type set; for example, the configuration type set can be a list of configuration types, an array of configuration types, a linked list of configuration types, etc.

[0089] Optionally, the configuration types include tunnel, route, routing policy, and other types.

[0090] Step S102: For each configuration type in the configuration type set, create corresponding orchestration tasks and deployment tasks, and add them to the task sequence.

[0091] In this step, a corresponding task is created for each configuration type to be changed. This task includes an orchestration task. In some scenarios, this task also includes a deployment task. For example, when the change action is to add, update, or delete, an orchestration task and a deployment task need to be created; when the change action is to add or delete on the controller side, an orchestration task needs to be created.

[0092] Optionally, after creating a task, the execution order between tasks is also determined. Accordingly, the execution order can be added to the task sequence; or, the execution order between tasks can be stored separately and a mapping relationship between it and the task sequence can be established so that the execution order between tasks can be obtained when executing tasks later.

[0093] This application does not limit the data structure of the task sequence; for example, the task sequence can be in the form of a task list or a task array.

[0094] Step S103: Execute the tasks in the task sequence to orchestrate and deploy the network configuration.

[0095] Optionally, tasks in the task sequence are executed in the order they are executed.

[0096] Upon receiving a network topology change request, this application enables more targeted changes by precisely locating the configuration type to be changed and the affected network elements, avoiding unnecessary resource consumption. This helps optimize network resource utilization and improve overall network performance. Furthermore, by creating corresponding orchestration and deployment tasks based on the configuration type to be changed, each task focuses on a specific configuration type, reducing task complexity and the risk of cross-influence. This lowers the likelihood of configuration errors during task execution. Moreover, creating tasks according to configuration type increases the possibility of parallel task processing, reducing dependencies and waiting times between tasks and improving task execution efficiency. Therefore, this application provides a universal orchestration and deployment method for different network topologies, achieving integrated orchestration and deployment and effectively improving the overall orchestration and deployment performance of the SDN controller.

[0097] In some embodiments, step S101 is specifically implemented as the following steps S1011-S1014:

[0098] Step S1011: Receive a network change request sent by the user equipment.

[0099] Optionally, after receiving a network change request, the action type to which the change action belongs can also be extracted from the network change request.

[0100] Step S1012: Based on the network change request, determine the network elements in the current network architecture that need to be changed.

[0101] In some embodiments, step S1012 includes: parsing the network change request to obtain target network element information; the target network element information is used to represent the changed network element indicated by the user; comparing the current network element information of the current network architecture with the target network element information to obtain the network element that needs to be changed.

[0102] As the current network architecture is used, its network element information may change due to orchestration and deployment. Therefore, the current network element information refers to the latest network element information of the current network architecture, and the current network element information includes: private network, sites, devices, interfaces, etc. Optionally, the latest network element information of the current network architecture can be stored in a database after each orchestration and deployment for retrieval in subsequent orchestration and deployments.

[0103] This embodiment obtains target network element information by parsing network change requests, which can accurately capture the user's intention to change the network. By directly comparing the current network element information with the target network element information, it can effectively identify which elements need to be changed and quickly determine the scope of the change. This differential analysis helps to avoid unnecessary configuration modifications and ensures that only the parts that need to be changed are adjusted.

[0104] In this embodiment, if there are network elements in the current network architecture that need to be changed, it means that the current network architecture needs to change its network configuration, and step S1013 is then executed. Conversely, if there are no network elements in the current network architecture that need to be changed, it means that the current network architecture does not need to change its network configuration, and no processing is required. This application uses the example of a network element in the current network architecture that needs to be changed for illustration.

[0105] Step S1013: Obtain the configuration template corresponding to the network type of the current network architecture.

[0106] The network type refers to the network topology of the current network architecture, which can be either dynamic or static. Different network types correspond to different network configurations, which exist in the form of configuration templates. Optionally, the server pre-configures the network type of the current network architecture and stores the configuration templates corresponding to different network types. This allows the server to directly read the network type of the current network architecture from the configuration information and obtain the corresponding configuration template.

[0107] Step S1014: Iterate through the configuration template to find the configuration types related to the network elements that need to be changed, and add the iterated configuration types and the related affected network elements to the configuration type set.

[0108] This embodiment ensures the accuracy and consistency of configuration types by traversing and matching configuration templates; by identifying affected network elements, it is possible to more clearly understand the scope of the impact of changes on the network.

[0109] In some embodiments, after creating a task, the execution order between tasks is also determined and added to the task sequence. Accordingly, the task sequence also includes the execution order between each task. Step S102 is specifically implemented as follows: traversing the configuration type set and performing the following operations for the currently traversed configuration type, including steps S1021-S1025:

[0110] Step S1021: Determine whether the configuration type currently being traversed requires cross-device orchestration.

[0111] Cross-device orchestration refers to orchestration involving multiple devices. In practical applications, based on historical orchestration and deployment experience, tunnel types involve cross-device orchestration. Optionally, when determining whether the currently traversed configuration type requires cross-device orchestration, it can be determined whether the currently traversed configuration type is a tunnel type. If it is a tunnel type, then cross-device orchestration is required; otherwise, if it is not a tunnel type, then cross-device orchestration is not required.

[0112] Step S1022: If the configuration type currently being traversed does not require cross-device orchestration, then create orchestration tasks for each network device related to that configuration type, add the created orchestration tasks to the task sequence, and set the execution order information for the created orchestration tasks.

[0113] For example, if the current configuration type is routing and there are 3 network devices related to routing, then create a corresponding orchestration task for each network device and add the created orchestration task to the task sequence.

[0114] After creating orchestration tasks for each network device with a configuration type, the corresponding execution order information is set for each orchestration task. Based on historical orchestration and deployment experience, orchestration tasks for multiple network devices with configuration types that do not require cross-device orchestration do not have task dependencies. Therefore, the execution order of the created orchestration tasks can be set to parallel execution. For example, if the created orchestration tasks include Task 1, Task 2, and Task 3, then the execution order information for Task 1 can be set to parallel execution with Task 2 and Task 3, the execution order information for Task 2 can be set to parallel execution with Task 1 and Task 3, and the execution order information for Task 3 can be set to parallel execution with Task 1 and Task 2.

[0115] In some embodiments, if the configuration type currently being traversed requires cross-device orchestration, multiple network devices related to the configuration type are grouped according to a preset device association relationship to obtain multiple groups; orchestration tasks corresponding to each group are created, the created orchestration tasks are added to the task sequence, and execution order information is set for the created orchestration tasks.

[0116] The preset device association relationships are the relationships between network devices. If multiple network devices are associated, they can be grouped into one group. Optionally, multiple network devices that need to be orchestrated together can be considered to have an association relationship. For example, if device A and device C need to be orchestrated together, or if device A and device B need to be orchestrated together, then device A and device C will be assigned to group 1, and device A and device B will be assigned to group 2.

[0117] For example, configuration types that require cross-device orchestration, such as tunnel types, are task-based by device grouping. For instance, in a star topology (Hub-Spoke) network, where Hub represents the central node and Spoke represents the peripheral nodes, tasks are split at the Hub-Spoke site level or Hub-Spoke device level, resulting in multiple groups with corresponding orchestration tasks. Conversely, configuration types that do not require cross-device orchestration, such as routing policies and routes, are task-based by device level, resulting in orchestration tasks for each network device.

[0118] After creating orchestration tasks for each group, the execution order information for each task is set. There may be task dependencies between orchestration tasks in different groups; therefore, the execution order information for each group's orchestration tasks can be set according to these dependencies. Optionally, if any two groups contain the same network device, a task dependency is determined between the orchestration tasks of these two groups. For example, continuing with Group 1 and Group 2, if the orchestration task for Group 1 needs to be executed before the orchestration task for Group 2, then the execution order information for the orchestration task for Group 1 can be set to execute before the orchestration task for Group 2, and the execution order information for the orchestration task for Group 2 can be set to execute after the orchestration task for Group 1.

[0119] Optionally, the orchestration tasks can be further subdivided, and the granularity of the subdivided tasks can be determined based on the orchestration speed and the idempotency of the tasks. For example, regarding the orchestration speed, the execution speed of each orchestration task can be predetermined based on historical experience. If the speed is less than a preset speed threshold, the orchestration task can be further subdivided into multiple sub-tasks that can be executed in parallel, thereby improving the execution speed. Regarding the idempotency of tasks, taking a configuration type that requires cross-device orchestration, such as a tunnel type, as an example, such as a Hub-Spoke network, where one Hub corresponds to 20 Spokes, according to the above scheme, these 20 Spokes corresponding to one Hub need to be grouped into one group, and then the orchestration tasks corresponding to that group need to be created. Considering the idempotency of tasks, it can be further subdivided into one Hub corresponding to 5 Spokes, resulting in 4 groups. Orchestration tasks corresponding to each group can then be created, and the 4 orchestration tasks created can be executed in parallel.

[0120] Step S1023: For each orchestration task created, determine whether the orchestration task is a task that is processed independently by the controller; if the orchestration task is not a task that is processed independently by the controller, create a deployment task corresponding to the orchestration task, add the deployment task to the task sequence, and set the execution order information for the deployment task.

[0121] In this context, "controller-independent processing" refers to orchestration that can be performed on the controller side without issuing deployment commands to network devices. For example, controller-independent processing tasks could include adding or deleting tasks on the controller side. Optionally, the server can pre-store controller-independent processing tasks, for example, in a controller-independent processing task set. Then, for each created orchestration task, it can determine whether the orchestration task belongs to the controller-independent processing task set. If it does, the orchestration task is determined to be a controller-independent processing task; otherwise, if it does not, the orchestration task is determined not to be a controller-independent processing task.

[0122] After creating a deployment task corresponding to an orchestration task, the execution order information for that deployment task is also set. Optionally, deployment tasks of the same configuration type on the same network device must be executed after orchestration tasks. For example, after creating a corresponding deployment task 11 for orchestration task 1, the execution order information for deployment task 11 can be set to execute after orchestration task 1.

[0123] Step S1024: Determine whether the current configuration type has a configuration dependency relationship with other configuration types.

[0124] In this context, configuration dependencies refer to situations where the execution of a task of a certain configuration type depends on the execution of tasks of other configuration types. For example, if a routing deployment task for the same network device needs to be executed after a tunnel deployment task and a routing orchestration task, then there is a configuration dependency between the routing type and the tunnel type.

[0125] Step S1025: If the configuration type currently being traversed has a configuration dependency relationship with other configuration types, then add additional execution order information to the execution order information of each deployment task corresponding to that configuration type.

[0126] The additional execution order information for deployment tasks indicates the execution order of this deployment task relative to tasks corresponding to other configuration types. For example, the additional execution order information for deployment tasks corresponding to the routing type indicates that they will be executed after all deployment tasks of the tunnel type have been completed.

[0127] In some embodiments, if the orchestration task is a task that the controller handles independently, it means that there is no need to create a corresponding deployment task. In this case, the operation of determining whether the currently traversed configuration type has a configuration dependency relationship with other configuration types is directly executed. If the currently traversed configuration type has a configuration dependency relationship with other configuration types, additional execution order information is added to the execution order information of each orchestration task corresponding to the configuration type. The additional execution order information is used to indicate the execution order between the orchestration task and the tasks corresponding to other configuration types.

[0128] In this embodiment, corresponding tasks are set for each configuration type in the configuration type set, and execution order information is set for the tasks to obtain a task sequence, which provides a basis for the execution of subsequent tasks.

[0129] In this embodiment, orchestration tasks corresponding to different configuration types can be executed in parallel.

[0130] In some embodiments, the task sequence is a directed acyclic graph (DAG), where vertices represent tasks and directed edges between vertices represent the execution order of tasks; directed edges can be unidirectional or bidirectional.

[0131] Optionally, all directed edges between vertices can be unidirectional, or all directed edges between vertices can be bidirectional. The bidirectional edges are configured for rollback in case of task failure.

[0132] Optionally, when the task sequence is a bidirectional DAG, bidirectional DAG verification can also be performed to ensure the correctness and consistency of the graph structure. For example, verification methods may include topological sorting of the DAG to verify its acyclicity, using depth-first search (DFS) or other algorithms to detect the presence of cycles in the DAG.

[0133] In some embodiments, the task sequence also includes the execution order of the tasks; then the tasks in the task sequence in step S103 can be tasks executed in the execution order, specifically implemented as the following steps S1031-S1035:

[0134] Step S1031: Activate the task without prerequisites in the task sequence.

[0135] Among them, a task without prerequisites refers to a task that does not need to be executed after other tasks. Optionally, tasks without prerequisites can be determined based on the execution order information of each task in the task sequence.

[0136] It should be noted that there may be one or more tasks without prerequisites. In the case of multiple tasks, each task without prerequisites needs to be activated so that multiple tasks without prerequisites can start and execute in parallel. The following explanation uses the execution process of a single task without prerequisites as an example. The execution path of each task without prerequisites in a multi-task scenario will not be elaborated here.

[0137] In practical applications, the task execution context needs to be saved before activating a task without prerequisites.

[0138] Step S1032: Determine the thread and executor corresponding to the task without any prerequisites.

[0139] In some embodiments, the task without prerequisites is an orchestration task; then determining the thread and executor corresponding to the task without prerequisites includes: identifying an idle thread in the orchestration thread pool as the thread corresponding to the task without prerequisites; and identifying the executor corresponding to the task type of the task without prerequisites as the executor corresponding to the task without prerequisites.

[0140] Optionally, the orchestration thread pool includes multiple threads, and any idle thread can be designated as the thread corresponding to the task without prerequisite dependencies. The task type can be a tunnel orchestration type, a route orchestration type, or a route policy orchestration type. This embodiment sets up a corresponding executor for each task type. The executor exists in the form of a software functional module and is used to execute the corresponding type of task.

[0141] Step S1033: Use threads and executors to execute tasks without prerequisite dependencies.

[0142] In practical applications, the task execution context needs to be populated before executing tasks without prerequisite dependencies.

[0143] Step S1034: After completing the task without prerequisites, determine whether there is a next-level task for the task without prerequisites.

[0144] Optionally, the existence of a next-level task can be determined based on the execution order information of tasks without prerequisite dependencies. Specifically, if the execution order information of tasks without prerequisite dependencies contains information indicating that a task needs to be executed after the task without prerequisite dependencies, then that task is determined to be a next-level task. Conversely, if the execution order information of tasks without prerequisite dependencies does not contain information indicating that a task needs to be executed after the task without prerequisite dependencies, then it is determined that there is no next-level task. For example, if the execution order information of tasks without prerequisite dependencies indicates that they are executed before task 1, then task 1 is a next-level task.

[0145] Step S1035: If a next-level task exists, execute the next-level task until no next-level task exists.

[0146] In some embodiments, if a next-level task exists, the next-level task is executed, including:

[0147] If a next-level task exists, then that next-level task will be triggered;

[0148] Once all parent tasks that have a task dependency relationship with this next-level task have been completed, the next-level task is determined to be successfully activated and executed.

[0149] In this context, "triggering" refers to attempting activation, but activation is not guaranteed to be successful. This next-level task may have one or more prerequisite tasks. If there is one prerequisite task, that prerequisite task is also the task without prerequisites in steps S1031-S1034. Since this task without prerequisites has already been completed, the activation of the next-level task can be directly determined as successful. If there are multiple prerequisite tasks, the activation of the next-level task can only be determined as successful if all of these prerequisite tasks have been completed. A prerequisite task refers to a parent task that has a task dependency relationship with the next-level task.

[0150] In some embodiments, when the next-level task is an orchestration task, executing the next-level task includes: determining an idle thread in the orchestration thread pool as the thread corresponding to the next-level task; determining an executor corresponding to the task type of the next-level task as the executor corresponding to the next-level task; and using the thread and the executor to execute the next-level task.

[0151] In some embodiments, when the next-level task is a deployment task, executing the next-level task includes: determining the network device corresponding to the next-level task, and determining a target deployment thread pool corresponding to the network device from multiple deployment thread pools; each deployment thread pool is a single-threaded pool; determining an executor corresponding to the task type of the next-level task; the task type is a tunnel deployment type, a routing deployment type, or a routing policy deployment type; and executing the next-level task using a thread from the target deployment thread pool and the executor.

[0152] Optionally, the target deployment thread pool corresponding to the network device can be determined from multiple deployment thread pools. Specifically, the key value of the network device is input into a hash function to obtain a hash value. The generated hash value is then modulo the total number of deployment thread pools to determine the thread pool index corresponding to the key value. This thread pool index refers to the target deployment thread pool. The key value can be determined based on specific application scenarios and requirements; for example, it could be a unique device identifier (ID) or other unique identifier.

[0153] Optionally, a corresponding executor can be set for each task type. The executor exists in the form of a software functional module and is used to execute the corresponding type of task.

[0154] In this embodiment, orchestration tasks are submitted to the orchestration thread pool for processing, and deployment tasks are submitted to the deployment thread pool for processing, ensuring the orderly execution of different types of tasks.

[0155] Optionally, the number of orchestrated thread pools and the number of deployed thread pools are determined by the number of CPU cores in the server.

[0156] This application integrates orchestration and deployment tasks, allowing for simultaneous orchestration and deployment for different configuration types. The more devices involved, the higher the concurrency and the faster the speed.

[0157] In some embodiments, the method provided in this application further includes:

[0158] For any task in the task sequence, upon initiating its execution, the task status is updated from "not executed" to "in execution," and upon completion, the task status is updated from "in execution" to "executed successfully." Timely updates to task execution status facilitate subsequent queries.

[0159] In some embodiments, this application also provides a retryable and rollback-enabled task flow processing framework, and correspondingly, the method provided by this application further includes:

[0160] If an exception occurs during the execution of the task, the task status will be updated to execution failed.

[0161] If the task fails, retry it until the number of retries reaches the preset threshold or until the task succeeds; or, in response to a rollback request from the user equipment, roll back the network configuration of the current network architecture to the state before the network change request was received, and re-orchestrate and deploy the network configuration.

[0162] The preset threshold number of times can be set according to actual needs. Rollback requests rely on bidirectional edges between vertices in the directed acyclic graph. The operation of reconfiguring and re-deploying the network configuration can be implemented according to the network configuration orchestration and deployment method provided in this application.

[0163] This application effectively addresses abnormal scenarios, providing an instant retry function for abnormal tasks to ensure network reliability. Thus, in failure scenarios, only a specific configuration on a few devices with the abnormality fails, while other configurations execute normally. Fine-tuning to the correct configuration is possible before continuing execution, making it suitable for significant network adjustments such as adding or deleting core device configurations. Furthermore, this application provides a rollback function; the bidirectional DAG constraint ensures that in case of anomalies during task execution, reverse operations can be performed to roll back the task.

[0164] In some embodiments, during task execution, the current progress can also be displayed to the user. Accordingly, the method provided in this application further includes:

[0165] In response to receiving a progress query request from a user equipment, the system sends a request processing progress information to the user equipment. The request processing progress information includes the service status, the task status and task information of each task in the task sequence, so that the user equipment can display the request processing progress information.

[0166] The service status is either "request processing in progress" or "request processing completed," specifically referring to the processing status of a network topology change request. Task information includes at least one of the following: task type, task-related network elements, and configuration type. Task-related network elements can be represented by network element identifiers.

[0167] This application breaks down a complete network configuration orchestration into a binary processing task of device + configuration type. For each task, it can display the devices involved in the current task and the processing type, which is user-friendly. For example, users can effectively view the current task progress.

[0168] Figure 3 This is a flowchart illustrating another network configuration orchestration and deployment method provided in this application. Based on any of the above embodiments, this embodiment involves the overall orchestration and deployment process, such as... Figure 3 As shown, the overall orchestration and deployment process includes three stages:

[0169] Orchestration Pre-launch Phase: For network changes, identify the affected devices and the types of configurations that need modification. For example, adding a device within a site will lead to configuration changes for devices across different types of sites and other devices within the same site. The main affected configuration types include tunnels, routing, and routing policies.

[0170] Automatic task generation phase: Based on the list of configuration types that need to be changed extracted in the orchestration pre-phase, tasks are split and a list of tasks to be executed is generated.

[0171] Task execution phase: Task execution flow is based on the task list.

[0172] For example, such as Figure 4 and Figure 5The document presents the orchestration structures of the Software-Defined Wide Area Network (SDWAN) before and after the upgrade. Before the upgrade: Configuration types such as tunnels, routes, and routing policies were first orchestrated serially on the controller side, and then deployed serially across multiple devices based on task allocation. After the upgrade: Task allocation and topology settings are based on different configuration types and device dimensions. For example, a route deployment task depends on both a route orchestration task and a tunnel deployment task; therefore, when creating a task, these two tasks need to be set as prerequisites for the route deployment task. All tasks without topology connections can be executed in parallel. It is evident that this application effectively improves the performance of the SDN controller and eliminates the need to wait for all configurations to be orchestrated before deployment, thus significantly enhancing the performance of network devices.

[0173] Regarding application scenarios, this application is applicable to scenarios with long-link scheduling, and is not limited to SDN controller orchestration deployment scenarios.

[0174] Figure 6 This is a schematic diagram of the structure of a network configuration orchestration and deployment device provided in this application, such as... Figure 6 As shown, in this embodiment, the network configuration orchestration and deployment device 40 can be installed in an electronic device, and the network configuration orchestration and deployment device 40 includes:

[0175] The generation module 401 is used to generate a configuration type set in response to receiving a network change request; the configuration type set contains at least one configuration type to be changed and the affected network elements related to each configuration type; the network elements include at least one of sites, devices and interfaces;

[0176] Create module 402 to create corresponding orchestration and deployment tasks for each configuration type in the configuration type set and add them to the task sequence;

[0177] Execution module 403 is used to execute tasks in the task sequence to orchestrate and deploy network configurations.

[0178] In some embodiments, when generating a configuration type set in response to receiving a network change request, the generation module 401 is specifically used for:

[0179] Receive network change requests sent by user equipment;

[0180] Based on the network change request, identify the network elements in the current network architecture that need to be changed;

[0181] Retrieve the configuration template corresponding to the network type of the current network architecture;

[0182] Iterate through the configuration template to find the configuration types related to the network elements that need to be changed, and add the iterated configuration types and the relevant affected network elements to the configuration type set.

[0183] In some embodiments, when generating module 401 determines the network elements that need to be changed in the current network architecture based on the network change request, it is specifically used for:

[0184] Parse the network topology change request to obtain the target network element information; the target network element information is used to represent the changed network elements indicated by the user.

[0185] The current network element information of the current network architecture is compared with the target network element information to obtain the network elements that need to be changed.

[0186] In some embodiments, the task sequence further includes the execution order of the tasks; the creation module 402, when creating corresponding orchestration tasks and deployment tasks for each configuration type in the configuration type set and adding them to the task sequence, is specifically used for:

[0187] Iterate through the set of configuration types and, for the currently iterated configuration type, perform the following operations:

[0188] Determine whether the configuration type requires cross-device orchestration;

[0189] If the configuration type does not require cross-device orchestration, then create orchestration tasks for each network device related to the configuration type, add the created orchestration tasks to the task sequence, and set the execution order information for the created orchestration tasks;

[0190] For each orchestration task created, determine whether the orchestration task is a task that is handled independently by the controller; if the orchestration task is not a task that is handled independently by the controller, create a deployment task corresponding to the orchestration task, add the deployment task to the task sequence, and set the execution order information for the deployment task.

[0191] Determine whether the configuration type has configuration dependencies on other configuration types;

[0192] If there is a configuration dependency relationship between configuration types and other configuration types, additional execution order information is added to the execution order information of each deployment task corresponding to the configuration type. The additional execution order information is used to indicate the execution order between the deployment task and the tasks corresponding to other configuration types.

[0193] In some embodiments, creation module 402 is further configured to:

[0194] If the configuration type needs to be orchestrated across devices, then the multiple network devices related to the configuration type are grouped according to the preset device association relationship to obtain multiple groups;

[0195] Create orchestration tasks for each group, add the created orchestration tasks to the task sequence, and set the execution order information for the created orchestration tasks.

[0196] In some embodiments, creation module 402 is further configured to:

[0197] If the orchestration task is a task that the controller handles independently, then determine whether the configuration type has a configuration dependency relationship with other configuration types;

[0198] If there is a configuration dependency relationship between configuration types and other configuration types, additional execution order information is added to the execution order information of each orchestration task corresponding to the configuration type. The additional execution order information is used to indicate the execution order between the orchestration task and the tasks corresponding to other configuration types.

[0199] In some embodiments, the task sequence is a directed acyclic graph, where vertices represent tasks and directed edges between vertices represent the execution order of tasks; directed edges can be unidirectional or bidirectional.

[0200] In some embodiments, the task sequence further includes the execution order of the tasks; the execution module 403, when executing the tasks in the task sequence, is specifically used for:

[0201] Activate tasks in the task sequence that have no preceding dependencies;

[0202] Determine the thread and executor for tasks without prerequisite dependencies;

[0203] Execute tasks with no prerequisites using threads and executors;

[0204] After completing a task without any prerequisites, determine whether there is a next-level task for the task without prerequisites.

[0205] If a next-level task exists, execute that task until no next-level task exists.

[0206] In some embodiments, tasks without prerequisite dependencies belong to orchestration tasks; the execution module 403, when determining the thread and executor corresponding to a task without prerequisite dependencies, is specifically used for:

[0207] Identify an idle thread in the orchestration thread pool as the thread corresponding to a task without prerequisite dependencies;

[0208] The executor corresponding to the task type without any preceding dependent tasks is determined as the executor corresponding to the preceding dependent tasks; the task type is tunnel orchestration type, route orchestration type, or route policy orchestration type.

[0209] In some embodiments, when executing a next-level task if one exists, the execution module 403 is specifically configured to:

[0210] If a next-level task exists, then the next-level task will be triggered;

[0211] Once all parent tasks that have dependencies on the next level task have been completed, the activation of the next level task is confirmed as successful, and the next level task is then executed.

[0212] In some embodiments, when the next-level task is a deployment task, the execution module 403, when executing the next-level task, is specifically used for:

[0213] Determine the network device corresponding to the next level task, and select the target deployment thread pool corresponding to the network device from multiple deployment thread pools; each deployment thread pool is a single-threaded pool.

[0214] Determine the executor corresponding to the task type of the next level task; the task type is either tunnel deployment type, route deployment type, or route policy deployment type.

[0215] The target deployment thread pool uses threads and executors to execute the next level of tasks.

[0216] In some embodiments, the execution module 403 is further configured to:

[0217] For any task in the task sequence, when starting to execute the task, the task status is updated from "not executed" to "in execution", and when the task is completed, the task status is updated from "in execution" to "execution successful".

[0218] In some embodiments, the execution module 403 is further configured to:

[0219] If an exception occurs during the execution of the task, the task status will be updated to execution failed.

[0220] Re-execute the task until the number of retries reaches the preset threshold or until the task is successfully executed; or, in response to receiving a rollback request from the user equipment, roll back the network configuration of the current network architecture to the state before the network change request was received, and re-orchestrate and deploy the network configuration.

[0221] In some embodiments, a query module is also included, for:

[0222] In response to receiving a progress query request from a user equipment, the system sends request processing progress information to the user equipment. The request processing progress information includes the service status, the task status and task information of each task in the task sequence, so that the user equipment can display the request processing progress information. The service status is either request processing in progress or request processing completed. The task information includes at least one of the following: task type, task-related network elements and configuration type.

[0223] The network configuration orchestration and deployment device 40 provided in this embodiment can execute the technical solution of the corresponding method embodiment. Its implementation principle and technical effect are similar to those of the corresponding method embodiment, and will not be described again here.

[0224] This application also provides an electronic device. Figure 7 This is a schematic diagram of the structure of an electronic device provided in this application. For example... Figure 7 As shown, the electronic device 50 includes a processor 501 and a memory 502 communicatively connected to the processor 501.

[0225] The memory 502 stores computer-executable instructions; the processor 501 executes the computer-executable instructions stored in the memory 502 to implement the network configuration orchestration and deployment method provided in this application.

[0226] In this embodiment, the memory 502 and the processor 501 are connected via a bus. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be categorized as an address bus, a data bus, a control bus, etc.

[0227] The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein. The various components are interconnected via different buses and can be mounted on a common motherboard or otherwise as required.

[0228] In an exemplary embodiment, a computer-readable storage medium is also provided, which stores computer-executable instructions that, when executed by a processor, are used to implement the network configuration orchestration and deployment method provided in this application.

[0229] In an exemplary embodiment, a computer program product is also provided, including a computer program, which, when executed by a processor, is used to implement the network configuration orchestration and deployment method provided in this application.

[0230] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0231] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0232] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0233] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0234] When an integrated unit / module is implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), controller, microcontroller, microprocessor, or other electronic component. Unless otherwise specified, memory can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as USB flash drives, random-access memory (RAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), enhanced dynamic random-access memory (EDRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), high-bandwidth memory (HBM), or hybrid memory cube (HMC) and other media capable of storing program code.

[0235] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause an electronic device to execute all or part of the steps of the methods of the various embodiments of this application.

[0236] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0237] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0238] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for orchestrating and deploying network configurations, characterized in that, include: In response to receiving a network topology change request, a configuration type set is generated; the configuration type set contains at least one configuration type to be changed and the affected network elements related to each configuration type; The network elements include at least one of stations, devices, and interfaces; For each configuration type in the set of configuration types, create corresponding orchestration tasks and deployment tasks, and add them to the task sequence; Execute the tasks in the task sequence to orchestrate and deploy the network configuration.

2. The method according to claim 1, characterized in that, The response to receiving a network change request generates a set of configuration types, including: Receive network change requests sent by user equipment; Based on the network change request, determine the network elements in the current network architecture that need to be changed; Obtain the configuration template corresponding to the network type of the current network architecture; The configuration types related to the network element to be changed are traversed from the configuration template, and the traversed configuration types and the related affected network elements are added to the configuration type set.

3. The method according to claim 2, characterized in that, The step of determining the network elements that need to be changed in the current network architecture based on the network change request includes: The network topology change request is parsed to obtain target network element information; the target network element information is used to represent the changed network element indicated by the user. The current network element information of the current network architecture is compared with the target network element information to obtain the network elements that need to be changed.

4. The method according to claim 1, characterized in that, The task sequence also includes the execution order of each task; the step of creating corresponding orchestration and deployment tasks for each configuration type in the configuration type set and adding them to the task sequence includes: Iterate through the set of configuration types and, for the currently iterated configuration type, perform the following operations: Determine whether the configuration type requires cross-device orchestration; If the configuration type does not require cross-device orchestration, then create orchestration tasks for each network device related to the configuration type, add the created orchestration tasks to the task sequence, and set the execution order information for the created orchestration tasks; For each orchestration task created, determine whether the orchestration task is a task that is processed independently by the controller; if the orchestration task is not a task that is processed independently by the controller, then create a deployment task corresponding to the orchestration task, add the deployment task to the task sequence, and set the execution order information for the deployment task. Determine whether the configuration type has a configuration dependency relationship with other configuration types; If the configuration type has a configuration dependency relationship with other configuration types, additional execution order information is added to the execution order information of each deployment task corresponding to the configuration type. The additional execution order information is used to indicate the execution order between the deployment task and the tasks corresponding to other configuration types.

5. The method according to claim 1, characterized in that, The task sequence is a directed acyclic graph, where vertices represent tasks and directed edges between vertices represent the execution order of tasks; the directed edges can be unidirectional or bidirectional.

6. The method according to claim 1, characterized in that, The task sequence also includes the execution order of the tasks; executing the tasks in the task sequence includes: Activate the tasks in the task sequence that have no preceding dependencies; Determine the thread and executor corresponding to the task without prerequisite dependencies; The thread and the executor are used to execute the task without prerequisites; After completing the task without prerequisites, determine whether the task without prerequisites has a next-level task. If a next-level task exists, execute that next-level task until no next-level task exists.

7. The method according to claim 6, characterized in that, The task without prerequisites is an orchestration task. Determining the thread and executor corresponding to the task without prerequisite dependencies includes: An idle thread in the orchestration thread pool is identified as the thread corresponding to the task without prerequisite dependencies; The executor corresponding to the task type without prerequisite dependencies is determined as the executor corresponding to the prerequisite dependent task; the task type is a tunnel orchestration type, a route orchestration type, or a route policy orchestration type.

8. The method according to claim 6, characterized in that, If the next-level task is a deployment task, executing the next-level task includes: The network device corresponding to the next-level task is determined, and the target deployment thread pool corresponding to the network device is determined from multiple deployment thread pools; each deployment thread pool is a single-threaded pool. Determine the executor corresponding to the task type of the next-level task; the task type is a tunnel deployment type, a route deployment type, or a route policy deployment type. The next-level task is executed using threads from the target deployment thread pool and the executor.

9. The method according to claim 1, characterized in that, Also includes: If an exception occurs during the execution of the task, the task status will be updated to execution failure. The task is retried until the number of retries reaches a preset threshold or until the task is successfully executed; or, in response to receiving a rollback request from the user equipment, the network configuration of the current network architecture is rolled back to the state before the network change request was received, and the network configuration is rearranged and deployed again.

10. The method according to claim 1, characterized in that, Also includes: In response to receiving a progress query request from a user equipment, a request to process progress information is sent to the user equipment; The request processing progress information includes the service status, the task status and task information of each task in the task sequence, so that the user equipment can display the request processing progress information; the service status is request processing in progress or request processing completed; the task information includes at least one of the following: task type, network elements related to the task and configuration type.

11. A network configuration orchestration and deployment apparatus, characterized in that, include: A generation module is used to generate a set of configuration types in response to a received network change request; the set of configuration types includes at least one configuration type to be changed and the affected network elements related to each configuration type; The network elements include at least one of stations, devices, and interfaces; A creation module is used to create corresponding orchestration tasks and deployment tasks for each configuration type in the configuration type set, and add them to the task sequence; The execution module is used to execute tasks in the task sequence to orchestrate and deploy network configurations.

12. An electronic device, characterized in that, include: A processor and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the network configuration orchestration and deployment method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the network configuration orchestration and deployment method as described in any one of claims 1 to 10.

Images