Network equipment deactivation method and device, equipment, storage medium and program product

Abstract

The invention relates to a network equipment deactivation method and device, equipment, a storage medium and a program product. The method is used in a controller of a software-defined network, the software-defined network comprises the controller, a protocol stack and a plurality of network devices, and the method comprises the following steps: receiving a deactivation instruction, the deactivation instruction being used for disconnecting a connection relationship among the network devices on a data plane level; a parent workflow is determined according to the deactivation instruction, the parent workflow comprises a plurality of child workflows, and each child workflow is used for deleting configuration of each network device; and asynchronously executing each sub-workflow to complete deactivation of each network device. By adopting the method, the deactivation efficiency of the network equipment can be improved.

Description

Technical Field

[0001] The present application relates to the field of network technology, and in particular to a network device deactivation method, apparatus, device, storage medium and program product. Background Art

[0002] In software-defined networks, network devices need to be activated before they can be used. This means sending relevant configurations to network devices EDGE and POP to open up the connection between the two on the data plane. Deactivation means deleting the connection-related configurations on EDGE and POP and disconnecting the connection between the two on the data plane.

[0003] In the current deactivation process, there is a problem of low deactivation efficiency. Summary of the invention

[0004] Based on this, it is necessary to provide a network device deactivation method, apparatus, device, storage medium and program product that can improve deactivation efficiency in response to the above technical problems.

[0005] In a first aspect, the present application provides a network device deactivation method, which is used in a controller of a software-defined network, wherein the software-defined network includes a controller, a protocol stack, and multiple network devices, and the method includes:

[0006] receiving a deactivation instruction, the deactivation instruction being used to disconnect the connection relationship between the network devices at the data plane level;

[0007] Determine a parent workflow according to the deactivation instruction, the parent workflow includes multiple sub-workflows, and each sub-workflow is used to delete the configuration of each network device;

[0008] Each sub-workflow is executed asynchronously to complete the deactivation of each network device.

[0009] In one of the embodiments, each sub-workflow is asynchronously executed to complete the deactivation of each network device, including: asynchronously executing each sub-workflow and obtaining the execution result of each sub-workflow; if each sub-workflow is successfully executed, determining that the deactivation of each network device is completed.

[0010] In one embodiment, each sub-workflow includes multiple execution steps, each sub-workflow is executed asynchronously, and the execution result of each sub-workflow is obtained, including: obtaining multiple execution steps in each sub-workflow and the execution order of each execution step; for each sub-workflow, executing each execution step in sequence according to the execution order, and updating the execution result of each execution step; determining the execution result of each sub-workflow according to the execution result of each execution step.

[0011] In one of the embodiments, for each sub-workflow, each execution step is executed in sequence according to the execution order, including: determining whether each execution step has a dependency relationship with any execution step in other sub-workflows; for each execution step, if a dependency relationship exists, based on the workflow subscription function of the Spring Workflow framework, obtaining the execution result of the dependent step, and executing the execution step when the execution result of the dependent step is successful, wherein the dependent step is an execution step in other sub-workflows corresponding to the execution step.

[0012] In one of the embodiments, the network device deactivation method further includes: if the execution result of any execution step is failure, obtaining a retry strategy corresponding to the execution step to re-determine the timing of executing the execution step according to the retry strategy.

[0013] In one embodiment, the retry strategy includes immediate retry, no retry and suspension; immediate retry includes retry frequency and maximum retry time, so that when the execution result of the execution step is failure, the execution step is re-executed according to the retry frequency until the execution result of the execution step is success, or the maximum retry time is reached; no retry includes constant no retry or conditional no retry; suspension includes releasing the preset conditions of suspension, so that the execution step is executed when the preset conditions are met.

[0014] In a second aspect, the present application further provides a network device deactivation device, which is arranged in a controller of a software-defined network, the software-defined network including a controller, a protocol stack and a plurality of network devices, the device including:

[0015] A receiving module, used for receiving a deactivation instruction, where the deactivation instruction is used for disconnecting the connection between the network devices at the data plane level;

[0016] A determination module, used to determine a parent workflow according to the deactivation instruction, the parent workflow includes multiple sub-workflows, and each sub-workflow is used to delete the configuration of each network device;

[0017] The deactivation module is used to asynchronously execute each sub-workflow to complete the deactivation of each network device.

[0018] In one of the embodiments, the deactivation module is specifically used to asynchronously execute each sub-workflow and obtain the execution result of each sub-workflow; if each sub-workflow is successfully executed, it is determined that the deactivation of each network device is completed.

[0019] In one of the embodiments, the deactivation module is specifically used to obtain multiple execution steps in each sub-workflow and the execution order of each execution step; for each sub-workflow, each execution step is executed in sequence according to the execution order, and the execution result of each execution step is updated; and the execution result of each sub-workflow is determined according to the execution result of each execution step.

[0020] In one embodiment, the deactivation module is specifically used to determine whether each execution step has a dependency relationship with any execution step in other sub-workflows; for each execution step, if a dependency relationship exists, the execution result of the dependent step is obtained based on the workflow subscription function of the SpringWorkflow framework, and when the execution result of the dependent step is successful, the execution step is executed, wherein the dependent step is the execution step in other sub-workflows corresponding to the execution step.

[0021] In one of the embodiments, the deactivation module is further used to obtain a retry strategy corresponding to any execution step if the execution result of any execution step is failure, so as to re-determine the timing of executing the execution step according to the retry strategy.

[0022] In one embodiment, the retry strategy includes immediate retry, no retry and suspension; immediate retry includes retry frequency and maximum retry time, so that when the execution result of the execution step is failure, the execution step is re-executed according to the retry frequency until the execution result of the execution step is success, or the maximum retry time is reached; no retry includes constant no retry or conditional no retry; suspension includes releasing the preset conditions of suspension, so that the execution step is executed when the preset conditions are met.

[0023] In a third aspect, the present application further provides a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements any of the methods described in the first aspect when executing the computer program.

[0024] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements any of the methods described in the first aspect above.

[0025] In a fifth aspect, the present application further provides a computer program product, comprising a computer program, which, when executed by a processor, implements any of the methods described in the first aspect above.

[0026] The above-mentioned network device deactivation method, apparatus, device, storage medium and program product receive a deactivation instruction, which is used to disconnect the connection relationship between each network device at the data plane level; then, determine the parent workflow according to the deactivation instruction, the parent workflow includes multiple sub-workflows, and each sub-workflow is used to delete the configuration of each network device; finally, asynchronously execute each sub-workflow to complete the deactivation of each network device. In this way, by asynchronously executing the deactivation operation with the network device as the granularity, it is not necessary to delete the configuration of each network device in sequence according to the order of the network devices. At the same time, compared with the multi-threaded processing method of opening an independent thread for each network device and deleting the configuration in the thread, the workflow method can effectively avoid abnormalities such as deadlock caused by thread collaboration risks, and can effectively improve the efficiency of network device deactivation. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0028] FIG1 is a diagram showing an application environment of a method for deactivating a network device in one embodiment;

[0029] FIG2 is a schematic diagram of a flow chart of a method for deactivating a network device in one embodiment;

[0030] FIG3 is a schematic diagram of the parent workflow execution process in one embodiment;

[0031] FIG4 is a schematic diagram of a flow chart of deactivation steps of each network device in one embodiment;

[0032] FIG5 is a schematic diagram of a flow chart of completing the steps of deactivating each network device in another embodiment;

[0033] FIG6 is a schematic diagram of a flow chart of executing various execution steps in one embodiment;

[0034] FIG7 is a schematic diagram of a collaborative processing flow of each execution step in a sub-workflow in one embodiment;

[0035] FIG8 is a schematic flow chart of a method for deactivating a network device in another embodiment;

[0036] FIG9 is a structural block diagram of a network device deactivation apparatus according to an embodiment;

[0037] FIG. 10 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0038] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0039] The network device deactivation method provided in the embodiment of the present application can be applied in the application environment as shown in Figure 1. The software-defined network includes a controller 10, a protocol stack 11 and multiple network devices 12. The controller 10 is used for logical control, and the protocol stack 11 is used to manage network devices. The controller can send the arranged configuration to the protocol stack, and then the protocol stack sends it to the network device. Taking the network devices as the main and standby EDGE and the main and standby POP as examples, the software-defined network architecture diagram is shown in Figure 1. The main and standby EDGE need to establish connections with the main and standby POPs respectively. The controller can be a computer device, such as a server or a terminal, wherein the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud computing services.

[0040] In an exemplary embodiment, as shown in FIG2 , a network device deactivation method is provided, which is described by taking the method applied to the controller 10 in FIG1 as an example, and includes the following steps 201 to 203. Among them:

[0041] S201, receiving a deactivation instruction.

[0042] The deactivation instruction is used to disconnect the connection between network devices at the data plane level.

[0043] Optionally, the deactivation instruction can be triggered through a northbound interface, where the northbound interface can be an interface used by an upper-level system (for example, a management system and a business application system, etc.) to obtain information about lower-level network devices, services, or resources, or to configure, manage, and control lower-level network devices, services, or resources. The northbound interface is mainly an interface for the user end, business end, or management end.

[0044] Optionally, after receiving the deactivation instruction, the parameters in the deactivation instruction are checked to verify the validity of the deactivation instruction, wherein the deactivation instruction may include unique identification information of each network device.

[0045] Optionally, verifying the parameters of the deactivation instruction may include: verifying whether the network device exists in the software-defined network based on the unique identification information of each network device; or verifying whether the network device in the software-defined network has been activated based on the unique identification information of each network device, etc. If each network device exists in the software-defined network or each network device has been activated, the verification is passed and an "operation successful" instruction can be returned to the upper-level system. The instruction is used to indicate that the controller has successfully received the deactivation instruction and performed a deactivation operation according to the activation instruction. It can be understood that the "operation successful" instruction does not mean that the deactivation is successful.

[0046] S202: Determine a parent workflow according to the deactivation instruction.

[0047] The parent workflow includes multiple sub-workflows, and each sub-workflow is used to delete the configuration of each network device.

[0048] Optionally, as shown in Figure 3, which is a schematic diagram of the parent workflow execution process, taking the network devices as the main EDGE, backup EDGE and the main POP, backup POP as examples, the parent workflow is started according to the deactivation instruction, and the parent workflow includes the sub-workflows corresponding to each network device.

[0049] In a possible implementation, when determining the parent workflow according to the deactivation instruction, the parent workflow may be preset, and the parent workflow is determined from a plurality of preset candidate parent workflows according to an identifier of the parent workflow in the deactivation instruction.

[0050] In another possible implementation, when determining the parent workflow based on the deactivation instruction, a blank parent workflow can be created as the initial parent workflow, and then the sub-workflows corresponding to each network device are determined based on each network device in the deactivation instruction to form the parent workflow; in this case, the workflow of the sub-workflow can be pre-set, and the corresponding sub-workflow is determined according to the type of network device, or the corresponding sub-workflow is determined from multiple candidate sub-workflows based on the identification of the network device.

[0051] Optionally, when a sub-workflow deletes the configuration of each network device, the process of the sub-workflow may be different according to the type of network device. It can be understood that each sub-workflow can be completed independently, or there may be a dependency relationship, that is, the execution step of a sub-workflow depends on the completion of a certain execution step in another sub-workflow. The embodiments of the present application are not limited to this.

[0052] S203, asynchronously executing each sub-workflow to complete the deactivation of each network device.

[0053] In one possible implementation, each sub-workflow can be asynchronously executed through an integrated workflow engine, and each sub-workflow is placed in an asynchronous task queue. The workflow is designed to automatically handle collaborative relationships, and business processes can be freely arranged in synchronization, asynchrony, and dependency order. The underlying layer shields collaborative processes such as waiting, notification, and exception handling, and users do not need to explicitly consider deadlock or thread synchronization. Stability is greatly improved, and the workflow engine can be based on the Spring Workflow framework or Activiti, an open source engine.

[0054] In another possible implementation, the asynchronous execution of sub-workflows can be achieved through message queues (for example, RabbitMQ, Kafka, etc.). When a sub-workflow is started in the parent workflow, a message containing information related to the sub-workflow is sent to the message queue. At the other end of the message queue, a dedicated message consumer (which can be an independent service or process) is responsible for parsing the message and starting and executing the corresponding sub-workflow based on the message content.

[0055] In another possible implementation manner, each sub-workflow may be asynchronously executed through an asynchronous programming model (eg, an asyn function).

[0056] Optionally, before each sub-workflow is executed, the deactivation status is updated to being processed. After each sub-workflow is executed, the execution result is returned. If all sub-workflows are executed successfully, the deactivation status is updated to success, otherwise it is failure.

[0057] Optionally, the deactivation status can be obtained through continuous polling by the front end and displayed to the operator, or the deactivation status can be sent to the operator through communication or sound and light, so that the operator can understand the deactivation status in time and discover it in time when deactivation fails.

[0058] The above-mentioned network device deactivation method receives a deactivation instruction, which is used to disconnect the connection relationship between each network device at the data plane level; then, the parent workflow is determined according to the deactivation instruction, and the parent workflow includes multiple sub-workflows, each of which is used to delete the configuration of each network device; finally, each sub-workflow is asynchronously executed to complete the deactivation of each network device. In this way, by asynchronously executing the deactivation operation with the network device as the granularity, it is not necessary to delete the configuration of each network device in sequence according to the order of the network devices. At the same time, compared with the multi-threaded processing method of opening an independent thread for each network device and deleting the configuration in the thread, the workflow method can effectively avoid abnormalities such as deadlock caused by thread collaboration risks, and can effectively improve the efficiency of network device deactivation.

[0059] In an exemplary embodiment, as shown in FIG4 , each sub-workflow is optionally executed asynchronously to complete the deactivation of each network device, including the following steps 401 to 402. Among them:

[0060] S401, asynchronously executing each sub-workflow and obtaining the execution result of each sub-workflow.

[0061] Optionally, the execution result of each sub-workflow can be obtained through a callback function. Alternatively, when implementing asynchronous execution of sub-workflows through a message queue, the message consumer can send a confirmation message to the message queue, and the parent workflow can obtain the execution result of the sub-workflow by subscribing to the confirmation message. The execution result of the sub-workflow can be obtained by querying database records or other storage mechanisms, that is, each sub-workflow can store the corresponding execution result after execution is completed.

[0062] S402: If all sub-workflows are executed successfully, it is determined that the deactivation of each network device is completed.

[0063] Optionally, when all the sub-workflows included in the parent workflow are executed successfully, it can be determined that the deactivation operation is successful, and the connection relationship between each network device in the software-defined network at the data plane level is disconnected.

[0064] Optionally, if a sub-workflow fails to execute, the sub-workflow can be re-executed through a retry mechanism, because most network instabilities or device abnormalities are temporary, such as the network returning to normal after a short jitter or the device process recovering after a short jam. In this case, you only need to retry several times until the network or device returns to normal to complete the entire process.

[0065] In the above, each sub-workflow is executed asynchronously and the execution result of each sub-workflow is obtained. If each sub-workflow is executed successfully, it is determined that the deactivation of each network device is completed. The parent workflow is viewed as a whole and each sub-workflow is executed asynchronously. Only when each sub-workflow is executed successfully, the parent workflow is executed successfully, and the deactivation operation can be determined to be completed, which can improve the accuracy of the deactivation operation.

[0066] In an exemplary embodiment, as shown in FIG5 , optionally, each sub-workflow includes multiple execution steps, and each sub-workflow is asynchronously executed, and the execution results of each sub-workflow are obtained, including the following steps 501 to 503. Among them:

[0067] S501, obtaining multiple execution steps in each sub-workflow and the execution order of each execution step.

[0068] Optionally, each network device has multiple configuration information, and one execution step may correspond to one configuration information or one type of configuration information. In the deactivation process of a network device, there may be at least one execution step.

[0069] In a possible implementation, log information of an activation process of a network device may be obtained, and multiple execution steps and execution orders in a sub-workflow corresponding to the network device may be generated according to the log information of the activation process.

[0070] In another possible implementation, the workflow of the sub-workflow may be preset, that is, the sub-workflow may be parsed according to a preset parsing rule to obtain the execution steps in each sub-workflow and the execution order of each execution step.

[0071] Optionally, the execution order of multiple execution steps may be different, and one execution must be completed before the next one can be executed. There may also be some execution steps that can be executed simultaneously. The embodiments of the present application are not limited to this.

[0072] S502: For each sub-workflow, execute each execution step in sequence according to the execution order, and update the execution result of each execution step.

[0073] Optionally, during the execution of a sub-workflow, the execution steps in the sub-workflow can be executed in order, and the execution status of each execution step can be recorded in the storage medium. For example, before preparing to execute an execution step, the execution status of the execution step is pending execution. When the execution of the execution step starts, the execution status can be updated to executing. Finally, the execution status can be updated to success or failure based on the execution result of the execution step.

[0074] S503: Determine the execution result of each sub-workflow according to the execution result of each execution step.

[0075] In a possible implementation, for each sub-workflow, if any execution step has an execution result of failure, the execution result of the sub-workflow is failure.

[0076] In another possible implementation, for each sub-workflow, the execution result of the sub-workflow can be determined based on the importance of the execution step and the execution result. It can be understood that when obtaining the execution steps of the sub-workflow and the execution order of each execution step, the importance of the execution step can be obtained. The importance of the execution step can be the degree of influence of the execution step on the subsequent execution step and the degree of influence on the deactivation process. If the importance of the execution step is relatively low, the degree of influence of the failure of the execution step on the subsequent execution steps and the degree of influence on the deactivation process can be ignored, and the execution result of the execution step can be ignored; for example, if there is an execution step in the sub-workflow whose execution result is a failure and has a relatively low importance, and the execution results of other execution steps are all successful, then the execution result of the sub-workflow is successful.

[0077] Optionally, the workflow supports a rich set of retry strategies, and when retrying, all execution progress can be maintained and can be recovered from the latest failed state.

[0078] Optionally, if the execution result of any execution step is failure, a retry strategy corresponding to the execution step is obtained to re-determine the timing of executing the execution step according to the retry strategy.

[0079] Optionally, the retry strategies include immediate retry, no retry and suspension; immediate retry includes retry frequency and maximum retry time, so that when the execution result of the execution step is failure, the execution step is re-executed according to the retry frequency until the execution result of the execution step is success, or the maximum retry time is reached; no retry includes constant no retry or conditional no retry; suspend includes releasing the preset conditions of suspension, so that the execution step is executed when the preset conditions are met.

[0080] Optionally, if the execution result of any execution step is failure, the existing deactivation method may ignore the failure and continue to execute or terminate directly, which may easily cause residual network device configuration. If there is no automatic processing mechanism, manual deletion is required, which is time-consuming, labor-intensive and error-prone.

[0081] Exemplarily, the default retry frequency of immediate retry can be 5S / time, and the maximum retry time is 7 days. It can generally be used in scenarios where the cause of the failure can be resolved in a short time and retrying can succeed after the resolution; No retry is set by default as no retry, which is generally used for some non-essential execution steps or execution steps of lower importance, such as message notifications, etc. Even if these execution steps fail, they will not affect the execution results of the entire process, and the efficiency of the entire process can be avoided from being affected by continuous retries of these actions. Conditional no retry can be no retry when the execution step fails and returns a preset specific value; when the retry policy is suspended, the sub-workflow will be paused, and the pre-set unsuspend conditions need to be obtained. When the conditions are met, the execution will continue to be re-executed. The unsuspend conditions generally default to the switch in the workflow configuration file, and the waiting time can also be used. This scenario is generally used in situations where a major network or device failure cannot be resolved in a short time, and even if retries are continued, it will fail.

[0082] Optionally, each execution step may preset at least one retry strategy.

[0083] The above-mentioned multiple execution steps in each sub-workflow and the execution order of each execution step are obtained. For each sub-workflow, each execution step is executed in sequence according to the execution order, and the execution result of each execution step is updated. The execution result of each sub-workflow is determined according to the execution result of each execution step, and when the execution step fails, the execution step can be re-executed according to the preset retry strategy, which can effectively improve the deactivation efficiency of the network device.

[0084] In an exemplary embodiment, as shown in FIG6 , optionally, for each sub-workflow, each execution step is executed in sequence according to the execution order, including the following steps 601 to 602 . Among them:

[0085] S601, determining whether each execution step has a dependency relationship with any execution step in other sub-workflows.

[0086] In a possible implementation, when parsing a sub-workflow according to a preset parsing rule, the dependency relationship between each execution step in a sub-workflow and any execution step in other sub-workflows can be determined.

[0087] In another possible implementation, when executing the execution step, if the execution step has a prerequisite, the dependency relationship between the execution step and any execution step in other sub-workflows can be determined, and the prerequisite and execution steps in other sub-workflows can be analyzed to determine the execution steps in other sub-workflows that have a dependency relationship with the execution step and any execution step in other sub-workflows.

[0088] S602: For each execution step, if there is a dependency relationship, the execution result of the dependent step is obtained based on the workflow subscription function of the Spring Workflow framework, and the execution step is executed when the execution result of the dependent step is successful.

[0089] The dependent steps are execution steps in other sub-workflows corresponding to the execution steps.

[0090] Optionally, the Spring Workflow framework can be a lightweight workflow framework based on the Spring framework, which can implement the workflow subscription function through the event publish-subscribe mode, and can conveniently subscribe to the execution results of dependent steps. The underlying Spring framework can implicitly handle the collaborative relationship between the execution steps in different sub-workflows, so that for the execution steps of each sub-workflow, it can focus on business logic rather than collaborative relationship processing.

[0091] Optionally, as shown in Figure 7, it is a collaborative processing flow of each execution step in a sub-workflow. It can be understood that when the execution result of the dependent step is not successful, polling and waiting can be performed to obtain the execution result of the dependent step according to the preset event interval until the execution of the dependent step is successful.

[0092] In an exemplary embodiment, optionally, the network device deactivation method further includes:

[0093] As an optional implementation, as shown in FIG8 , the network device deactivation provided in the embodiment of the present application may include the following specific steps:

[0094] S801, receiving a deactivation instruction.

[0095] The deactivation instruction is used to disconnect the connection between network devices at the data plane level.

[0096] S802: Determine a parent workflow according to the deactivation instruction.

[0097] The parent workflow includes multiple sub-workflows, and each sub-workflow is used to delete the configuration of each network device.

[0098] S803: Acquire multiple execution steps in each sub-workflow and the execution order of each execution step.

[0099] S804: For each sub-workflow, determine whether each execution step has a dependency relationship with any execution step in other sub-workflows.

[0100] S805: For each execution step, if there is a dependency relationship, the execution result of the dependent step is obtained based on the workflow subscription function of the Spring Workflow framework, and the execution step is executed when the execution result of the dependent step is successful.

[0101] The dependent steps are execution steps in other sub-workflows corresponding to the execution steps.

[0102] S806: If the execution result of any execution step is failure, a retry strategy corresponding to the execution step is obtained to re-determine the timing of executing the execution step according to the retry strategy.

[0103] S807: Determine the execution result of each sub-workflow according to the execution result of each execution step.

[0104] S808: If all sub-workflows are executed successfully, it is determined that the deactivation of each network device is completed.

[0105] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0106] Based on the same inventive concept, the embodiment of the present application also provides a network device deactivation device for implementing the network device deactivation method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more network device deactivation device embodiments provided below can refer to the limitations of the network device deactivation method above, and will not be repeated here.

[0107] In an exemplary embodiment, as shown in FIG. 9 , a network device deactivation apparatus 900 is provided, which is arranged in a controller of a software defined network, wherein the software defined network includes a controller, a protocol stack and a plurality of network devices, and includes: a receiving module 901, a determining module 902 and a deactivation module 903, wherein:

[0108] A receiving module 901 is used to receive a deactivation instruction, where the deactivation instruction is used to disconnect the connection relationship between the network devices at the data plane level;

[0109] A determination module 902 is used to determine a parent workflow according to the deactivation instruction, wherein the parent workflow includes multiple sub-workflows, and each sub-workflow is used to delete the configuration of each network device;

[0110] The deactivation module 903 is used to asynchronously execute each of the sub-workflows to complete the deactivation of each of the network devices.

[0111] In an exemplary embodiment, the deactivation module 903 is specifically used to asynchronously execute each sub-workflow and obtain the execution result of each sub-workflow; if each sub-workflow is executed successfully, it is determined that the deactivation of each network device is completed.

[0112] In an exemplary embodiment, the deactivation module 903 is specifically used to obtain multiple execution steps in each sub-workflow and the execution order of each execution step; for each sub-workflow, each execution step is executed in sequence according to the execution order, and the execution result of each execution step is updated; the execution result of each sub-workflow is determined according to the execution result of each execution step.

[0113] In an exemplary embodiment, the deactivation module 903 is specifically used to determine whether each execution step has a dependency relationship with any execution step in other sub-workflows; for each execution step, if a dependency relationship exists, the execution result of the dependent step is obtained based on the workflow subscription function of the Spring Workflow framework, and when the execution result of the dependent step is successful, the execution step is executed, wherein the dependent step is the execution step in other sub-workflows corresponding to the execution step.

[0114] In an exemplary embodiment, the deactivation module 903 is further used to obtain a retry strategy corresponding to any execution step if the execution result of any execution step is failure, so as to re-determine the timing of executing the execution step according to the retry strategy.

[0115] In one embodiment, the retry strategy includes immediate retry, no retry and suspension; immediate retry includes retry frequency and maximum retry time, so that when the execution result of the execution step is failure, the execution step is re-executed according to the retry frequency until the execution result of the execution step is success, or the maximum retry time is reached; no retry includes constant no retry or conditional no retry; suspension includes releasing the preset conditions of suspension, so that the execution step is executed when the preset conditions are met.

[0116] Each module in the above network device deactivation device can be implemented in whole or in part by software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module.

[0117] In an exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be shown in FIG10. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. The processor, the memory and the input / output interface are connected via a system bus, and the communication interface is connected to the system bus via the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a network device deactivation method is implemented.

[0118] Those skilled in the art will understand that the structure shown in FIG. 10 is merely a block diagram of a partial structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different arrangement of components.

[0119] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps described in any of the above method embodiments when executing the computer program.

[0120] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps described in any of the above method embodiments are implemented.

[0121] In one embodiment, a computer program product is provided, including a computer program, which implements the steps described in any of the above method embodiments when executed by a processor.

[0122] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0123] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0124] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A method for deactivating a network device, characterized in that: In a controller for a software-defined network, the software-defined network includes a controller, a protocol stack, and a plurality of network devices, the method comprising: receiving a deactivation instruction, wherein the deactivation instruction is used to disconnect the connection relationship between each of the network devices at the data plane level; Determine a parent workflow according to the deactivation instruction, wherein the parent workflow includes a plurality of sub-workflows, and each of the sub-workflows is used to delete the configuration of each of the network devices; The sub-workflows are executed asynchronously to complete the deactivation of the network devices.

2. The method according to claim 1, characterized in that The asynchronously executing each of the sub-workflows to complete the deactivation of each of the network devices includes: Asynchronously executing each of the sub-workflows, and obtaining the execution results of each of the sub-workflows; If all the sub-workflows are executed successfully, it is determined that the deactivation of all the network devices is completed.

3. The method according to claim 2, characterized in that Each of the sub-workflows includes a plurality of execution steps, and the asynchronous execution of each of the sub-workflows and obtaining the execution results of each of the sub-workflows include: Acquire multiple execution steps in each of the sub-workflows and the execution order of each of the execution steps; For each of the sub-workflows, executing each of the execution steps in sequence according to the execution order, and updating the execution result of each of the execution steps; The execution result of each of the sub-workflows is determined according to the execution result of each of the execution steps.

4. The method according to claim 3, characterized in that For each of the sub-workflows, executing each of the execution steps in sequence according to the execution order includes: Determine whether each of the execution steps has a dependency relationship with any execution step in other sub-workflows; For each of the execution steps, if the dependency relationship exists, the execution result of the dependent step is obtained based on the workflow subscription function of the Spring Workflow framework, and when the execution result of the dependent step is successful, the execution step is executed, wherein the dependent step is the execution step in other sub-workflows corresponding to the execution step.

5. The method according to claim 3, characterized in that: The method further comprises: If the execution result of any of the execution steps is failure, a retry strategy corresponding to the execution step is obtained to re-determine the timing of executing the execution step according to the retry strategy.

6. The method according to claim 5, characterized in that The retry strategies include immediate retry, no retry required, and suspension; The immediate retry includes a retry frequency and a maximum retry time, so that when the execution result of the execution step is failure, the execution step is re-executed according to the retry frequency until the execution result of the execution step is success, or the maximum retry time is reached; The no need to retry includes constant no need to retry or conditional no need to retry; The suspension includes releasing a preset condition of the suspension, so as to execute the execution step when the preset condition is met.

7. A network device deactivation device, characterized in that: The device is provided in a controller of a software-defined network, wherein the software-defined network includes a controller, a protocol stack, and a plurality of network devices, and includes: A receiving module, used for receiving a deactivation instruction, wherein the deactivation instruction is used for disconnecting the connection relationship between the network devices at the data plane level; A determination module, configured to determine a parent workflow according to the deactivation instruction, wherein the parent workflow includes a plurality of sub-workflows, each of which is respectively used to delete the configuration of each of the network devices; The deactivation module is used to asynchronously execute each of the sub-workflows to complete the deactivation of each of the network devices.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images