A method, device and medium for SDN controller fault processing

Abstract

The application discloses an SDN controller fault processing method, equipment and medium, the method comprises the following steps: an SDN controller comprises a WEB service container running a WEB service and a container engine, the WEB service container comprises a health monitoring interface created for the WEB service, and the SDN controller accesses the health monitoring interface through the container engine; according to the returned access result, the WEB service container state is identified; when the WEB service container state is abnormal, the WEB service container is restarted through the container engine. By using the container technology, the SDN function is containerized, the deployment is simple and fast, the operation and maintenance cost is low, only one node is needed to run, the service is automatically restarted after failure, and the recovery speed is fast. Because of the container, each function is relatively independent, so that the influence on the whole business when the module is restarted is reduced.

Description

Technical Field

[0001] This application relates to the field of SDN technology, and in particular to an SDN controller fault handling method, device and medium. Background Technology

[0002] Network virtualization is typically divided into a control plane and a data plane. The data plane is responsible for network data transmission and reception, encapsulation / decapsulation, and forwarding. The control plane (i.e., the SDN controller) provides an interface to translate user network intentions into configuration items for the corresponding devices, controlling the forwarding paths of the devices. During service operation, the SDN controller needs to be on standby 24 / 7 to respond to user input. In actual operation, if the SDN controller stops running for any reason and cannot restart automatically, maintenance personnel may not be aware of it for a long time, affecting the user experience. However, the SDN controller stopping does not affect network virtualization data forwarding, but there are certain reliability requirements; therefore, measures are needed to ensure the operation of the SDN controller.

[0003] Currently, to ensure the reliability of SDN controllers, a multi-node SDN controller cluster is deployed. When more than half of the SDN controller nodes are running normally, the SDN controller cluster is connected to an external load balancer to forward external information to the surviving SDN controller nodes, thereby achieving traffic forwarding control.

[0004] However, because it requires multiple (at least 3) SDN controller nodes and additional deployment / configuration of load balancing devices / software to distribute requests to live nodes, the deployment is cumbersome and costly, making it particularly unsuitable for small to medium-sized network virtualization scenarios. Summary of the Invention

[0005] This application provides an SDN controller fault handling method, device, and medium to solve the problems of a single SDN controller being unable to handle faults during operation and the difficulty and high cost of deploying multiple nodes.

[0006] The embodiments of this application adopt the following technical solutions:

[0007] On one hand, this application provides an SDN controller fault handling method, which includes: the SDN controller includes a WEB service container running a WEB service and a container engine, the WEB service container includes a health monitoring interface created for the WEB service, the SDN controller accesses the health monitoring interface through the container engine; the status of the WEB service container is identified according to the returned access result; when the status of the WEB service container is abnormal, the WEB service container is restarted through the container engine.

[0008] In one example, identifying the status of the WEB service container based on the returned access result specifically includes: if the returned access result does not contain the running status data of the WEB service container, determining that the WEB service container status is abnormal; if the returned access result contains the running status data of the WEB service container, determining that the WEB service container status is normal.

[0009] In one example, the SDN controller further includes a task query container that runs the query task and a scheduled task scheduling tool. The method further includes: triggering the query task through the scheduled task scheduling tool; querying the status of each device in the SDN environment through the task query container; identifying the status of the task query container based on the exit status code of the foreground process of the task query container; and restarting the task query container through the container engine when the status of the task query container is abnormal.

[0010] In one example, identifying the status of the task query container based on the exit status code of the foreground process of the task query container specifically includes: determining that the status of the task query container is abnormal when the exit status code of the foreground process of the task query container is non-zero; and determining that the status of the task query container is normal when the exit status code of the foreground process of the task query container is zero.

[0011] In one example, the method further includes: when the task query container is in a normal state, controlling the task query container to exit through the Docker container engine; and when the scheduled task tool triggers the query task again, generating a new task query container through the container engine.

[0012] In one example, the SDN controller further includes a node operating system, and the method further includes: generating a restart log from the restart information of the WEB service container, saving the restart log to the node operating system, and persisting the restart log in the node operating system.

[0013] In one example, when the WEB service container is in an abnormal state, after restarting the WEB service container, the method further includes: accessing the health monitoring interface again through the container engine; identifying the WEB service container state based on the returned re-access result; restarting the WEB service container again when the WEB service container state is abnormal again; and generating an unresolved fault notification message for the WEB service container when the number of restarts exceeds a preset threshold, and sending the unresolved fault notification message to the management user terminal.

[0014] In one example, the method further includes: both the web service container and the task query container are Docker containers, the health monitoring interface is a REST interface, and the scheduled task tool is Cron.

[0015] On the other hand, embodiments of this application provide an SDN controller fault handling device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform an SDN controller fault handling method as described above.

[0016] On the other hand, embodiments of this application provide a non-volatile computer storage medium for SDN controller fault handling, which stores computer-executable instructions capable of executing any of the above-described SDN controller fault handling methods.

[0017] The above-mentioned at least one technical solution adopted in the embodiments of this application can achieve the following beneficial effects: by creating a health monitoring interface on the WEB service container, the real-time monitoring of the WEB running status is realized; by containerizing the functional parts of SDN, the deployment is simple and fast; the operation and maintenance cost is low, only one node is needed to run, it automatically restarts after failure, and the service recovery speed is fast. Because it is a container, the WEB function is relatively independent, and the restart of the module will not affect the entire business. Attached Figure Description

[0018] To more clearly illustrate the technical solution of this application, some embodiments of this application will be described in detail below with reference to the accompanying drawings, in which:

[0019] Figure 1 A flowchart illustrating an SDN controller fault handling method provided in an embodiment of this application;

[0020] Figure 2 A schematic diagram of the SDN controller layout for an SDN controller fault handling method provided in this application embodiment;

[0021] Figure 3 This is a schematic diagram of the structure of an SDN controller fault handling device provided in an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] Some embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0024] Figure 1 This is a flowchart illustrating an SDN controller fault handling method provided in an embodiment of this application. This method can be applied to different business domains. Certain input parameters or intermediate results in this process allow for manual adjustment to help improve accuracy.

[0025] The analysis method involved in the embodiments of this application can be implemented by a terminal device or a server, and this application does not impose any special limitations on it. For ease of understanding and description, the following embodiments all use an SDN controller as an example for detailed description.

[0026] Figure 1 The process may include the following steps:

[0027] It's important to clarify beforehand that containerization is a technology that packages an application and all its dependencies into a single container, enabling the application to maintain a consistent running state across different environments. Containerization requires a container engine, which is responsible for creating, running, and managing containers. Existing container engines include Docker, Podman, and containerd. Docker is the most widely used container engine, simplifying the creation, deployment, and management of containers.

[0028] In this embodiment, both the WEB service container and the task query container are Docker containers, the health monitoring interface is a REST interface, and the scheduled task tool is Cron.

[0029] S101: The SDN controller accesses the health monitoring interface through the container engine.

[0030] In this embodiment of the application, before the SDN controller accesses the health monitoring interface through the container engine, it should be noted that the SDN controller includes a web service container running a web service and a container engine, and the web service container includes a health monitoring interface created for the web service.

[0031] The health monitoring interface, also known as the REST interface, is a communication method based on the HTTP protocol used to exchange data between the client and the server. It follows the REST (Representational State Transfer) architectural style, emphasizing the transfer of resource representation state, and implements resource operations through a unified interface and standard HTTP methods. It is easy to learn and use, and can be easily extended with new resources and operations.

[0032] S102: Identify the status of the WEB service container based on the returned access result.

[0033] In the embodiments of this application, the SDN controller accesses the health monitoring interface through the container engine, and identifies the status of the WEB service container based on the returned access result. If the returned access result does not contain the running status data of the WEB service container, the WEB service container status is determined to be abnormal; if the returned access result contains the running status data of the WEB service container, the WEB service container status is determined to be normal.

[0034] It should be noted that this application uses container technology to place the web service in a created container. That is, if the health monitoring interface on the container can receive and return the web service's running status information, it means that the web service is running normally and has no abnormal state; if the web service's running status information is not received, it means that the web service is abnormal.

[0035] S103: When the WEB service container is in an abnormal state, the WEB service container is restarted through the container engine.

[0036] In the embodiments of this application, if the WEB service container is in an abnormal state, the SDN controller will restart the WEB service container through the container engine, generate a restart log for the restart information of the WEB service container, save the restart log to the node operating system, and persist the restart log data in the node operating system.

[0037] It's important to note that data persistence is the process of transforming data from a temporary state into something that can be permanently stored on a storage medium, ensuring that the data remains accessible and usable even after the program stops running. It is the core of information systems, and with the development of information technology, data persistence technology has expanded from traditional file systems to more complex systems such as relational databases, non-relational databases, and cloud storage.

[0038] It should also be noted that, in this embodiment of the application, users can choose whether to separate the data persistence part of the SDN controller according to their own needs.

[0039] Furthermore, after restarting the WEB service container through the container engine, this application also accesses the health monitoring interface again through the container engine. Based on the returned re-access result, the status of the WEB service container is identified. When the WEB service container status is abnormal again, the WEB service container is restarted again. If the number of restarts exceeds a preset threshold, a fault-unresolved notification message for the WEB service container is generated and sent to the management user terminal. This helps users better understand issues related to the SDN controller.

[0040] In addition to the above embodiments, the technical solution of this application also includes:

[0041] The SDN controller includes a task query container that runs query tasks and a scheduled task scheduling tool. The scheduled task scheduling tool triggers the query task, and the task query container queries the status of each device in the SDN environment.

[0042] It should be noted that the query task is triggered by the scheduled task tool. In this embodiment of the application, a period is set for the query task of the SDN controller by the scheduled task tool Corn, so that the task query container executes the query task periodically.

[0043] Furthermore, the status of the task query container is identified based on the exit status code of the foreground process of the task query container. When the exit status code of the foreground process of the task query container is non-zero, the status of the task query container is determined to be abnormal. When the exit status code of the foreground process of the task query container is zero, the status of the task query container is determined to be normal. When the status of the task query container is abnormal, the task query container is restarted through the container engine. When the status of the task query container is normal, the task query container is exited through the Docker container engine. When the scheduled task tool triggers the query task again, a new task query container is generated through the container engine.

[0044] It should be noted that the query task is a foreground task. If this task fails, the Docker engine will directly restart the container according to the restart policy, rather than automatically exiting after the query task is completed when the task fails. The restart policy is configured by the user through the SDN controller. In this embodiment, `on-failure[:max-retries]:` configures the instruction to restart the container only when the exit status code of the foreground process is not 0, and `max-retries` configures the maximum number of restarts.

[0045] To further explain, a foreground task is a task that runs within a container and blocks the container's main process, keeping the container running. In other words, a foreground task will continuously occupy the container's resources until the task is completed or terminated. If a foreground task terminates abnormally, the container will also exit.

[0046] It should be noted that, although the embodiments in this application are based on... Figure 1 Steps S101 to S103 will be described sequentially, but this does not mean that steps S101 and S103 must be performed in a strict order. The reason this embodiment follows this order is... Figure 1 The order in which steps S101 to S103 are described is provided to facilitate understanding of the technical solutions of the embodiments of this application by those skilled in the art. In other words, in the embodiments of this application, the order of steps S101 to S103 can be appropriately adjusted according to actual needs.

[0047] pass Figure 1 This method creates a health monitoring interface on the web service container, enabling real-time monitoring of the web service's operational status. By containerizing the functionalities of SDN, deployment is simple and quick; the entire deployment requires only one SDN node, resulting in low maintenance costs, automatic restart after failures, and fast service recovery. Due to the independence of containers, the web service functions are relatively independent, and module restarts do not affect the overall business. This increases the fault tolerance of the SDN controller and reduces the impact of a single module failure on the entire business.

[0048] Figure 2 This is a schematic diagram of the SDN controller layout for an SDN controller fault handling method provided in an embodiment of this application.

[0049] exist Figure 2 In the middle, the upper left section contains the web service container, including WEB1, WEB2, etc. To the right of the web service container are the TASK containers, which are task query containers, including TASK1, TASK2, etc. To the right of the TASK containers are numerous components responsible for data persistence. Below the web service container and TASK container are the Docker container engine and the Corn scheduling tool, and at the very bottom is the Linux OS system.

[0050] Figure 3 A schematic diagram of the structure of an SDN controller fault handling device provided in this application embodiment includes:

[0051] At least one processor; and,

[0052] A memory communicatively connected to the at least one processor; wherein,

[0053] The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform an SDN controller fault handling method as described above.

[0054] Some embodiments of this application provide a non-volatile computer storage medium for SDN controller fault handling, which stores computer-executable instructions capable of executing any of the above-described SDN controller fault handling methods.

[0055] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and medium embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the description of the method embodiments.

[0056] The devices and media provided in this application are one-to-one with the methods. Therefore, the devices and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be repeated here.

[0057] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0058] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0059] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0060] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0061] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0062] Memory may include non-persistent storage in computer-readable media, random access memory (RAM), and non-volatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0063] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0064] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0065] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the technical principles of this application should fall within the protection scope of this application.

Claims

1. A fault handling method for an SDN controller, characterized in that, The SDN controller includes a web service container that runs web services and a container engine. The web service container includes a health monitoring interface created for the web services. The method includes: The SDN controller accesses the health monitoring interface through the container engine; The status of the WEB service container is identified based on the returned access results; When the WEB service container is in an abnormal state, the WEB service container is restarted through the container engine; The SDN controller also includes a task query container for running query tasks and a scheduled task scheduling tool, and the method further includes: The query task is triggered by the scheduled task tool, and the status of each device in the SDN environment is queried through the task query container. The status of the task query container is identified based on the exit status code of the foreground process of the task query container. When the task query container is in an abnormal state, the task query container is restarted through the container engine; The status of the task query container is identified based on the exit status code of the foreground process of the task query container, specifically including: When the exit status code of the foreground process of the task query container is non-zero, the status of the task query container is determined to be abnormal. When the exit status code of the foreground process of the task query container is 0, the status of the task query container is determined to be normal.

2. The method according to claim 1, characterized in that, The step of identifying the status of the WEB service container based on the returned access result specifically includes: If the returned access result does not contain the running status data of the WEB service container, the WEB service container status is determined to be abnormal. If the returned access result contains the running status data of the WEB service container, the WEB service container is determined to be in normal status.

3. The method according to claim 1, characterized in that, The method further includes: When the task query container is in a normal state, the container engine controls the task query container to exit. When the scheduled task tool triggers the query task again, a new task query container is generated by the container engine.

4. The method according to claim 1, characterized in that, The SDN controller also includes a node operating system, and the method further includes: The restart information of the WEB service container is used to generate a restart log, which is then saved to the node operating system and persisted in the node operating system.

5. The method according to claim 1, characterized in that, When the web service container is in an abnormal state, after restarting the web service container, the method further includes: The health monitoring interface can be accessed again through the container engine; The status of the WEB service container is identified based on the returned re-access result; If the WEB service container becomes abnormal again, the WEB service container will be restarted again. When the number of restarts exceeds a preset threshold, a fault-unresolved notification message for the WEB service container is generated and sent to the management user terminal.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: Both the web service container and the task query container are Docker containers, the health monitoring interface is a REST interface, and the scheduled task tool is Cron.

7. An SDN controller fault handling device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform an SDN controller fault handling method according to any one of claims 1-6.

8. A non-volatile computer storage medium for SDN controller fault handling, storing computer-executable instructions, characterized in that, The computer-executable instructions are capable of executing the SDN controller fault handling method described in any one of claims 1-6.

Images