SDN (Software Defined Network) controller fault processing method, equipment and medium

Abstract

The invention discloses an SDN controller fault processing method and device and a medium, and the method comprises the steps: an SDN controller comprises a WEB service container for operating 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; identifying the state of the WEB service container according to the returned access result; and when the state of the WEB service container is abnormal, restarting the WEB service container through the container engine. SDN functions are containerized by applying a container technology, so that simple and quick deployment is realized; the method is low in operation and maintenance cost, can be operated by only one node, can be automatically restarted after a fault occurs, is high in service recovery speed, is relatively independent in function due to the reason of a container, and reduces the influence on the whole service when the module is restarted.

Description

Technical Field

[0001] The present application relates to the field of SDN technology, and in particular to a method, device and medium for handling SDN controller faults. Background Art

[0002] Network virtualization is usually 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., SDN controller) provides an interface to convert the user's network intention into the configuration items of the corresponding device and control the device forwarding path. During the business operation phase, the SDN controller needs to be on standby 24 hours a day to respond to user input. During the actual operation process, if the SDN controller stops running for some reason and cannot be automatically restarted, it may take a long time for the operation and maintenance personnel to perceive it, affecting the user experience. However, the suspension of the SDN controller does not affect the network virtualization data forwarding, but there are some reliability requirements, so measures are needed to ensure the operation of the SDN controller.

[0003] At present, in order to ensure the reliability of SDN controllers, a multi-node SDN controller cluster is deployed. When more than 1 / 2 of the SDN controllers are running normally, the SDN controller cluster is connected to an external load balancer to forward external situations to the surviving SDN controller nodes to achieve traffic forwarding control.

[0004] However, since multiple (at least 3) SDN controller nodes are required and additional deployment / configuration of responsible balancing devices / software is required, and the responsible balancing devices / software are used to distribute requests to surviving nodes, the deployment is cumbersome and costly, which is especially not suitable for small and medium-sized network virtualization scenarios. Summary of the invention

[0005] The embodiments of the present application provide an SDN controller fault handling method, device and medium, which are used to solve the problem that a single SDN controller cannot handle a fault during operation and that multi-node deployment is difficult and costly.

[0006] The present application embodiment adopts the following technical solutions:

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

[0008] In one example, the identifying the state of the WEB service container according to the returned access result specifically includes: if the returned access result does not have the running state data of the WEB service container, determining that the state of the WEB service container is abnormal; if the returned access result has the running state data of the WEB service container, determining that the state of the WEB service container is normal.

[0009] In one example, the SDN controller also includes a task query container for running query tasks and a scheduled task scheduling tool, and the method also 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 according to the foreground process exit status code of the task query container; when the status of the task query container is abnormal, restarting the task query container through the container engine.

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

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

[0012] In one example, the SDN controller also includes a node operating system, and the method also 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 state of the WEB service container is abnormal, after restarting the WEB service container, the method further includes: accessing the health monitoring interface again through the container engine; identifying the state of the WEB service container according to the returned re-access result; when the state of the WEB service container is abnormal again, restarting the WEB service container again; when the number of restarts is greater than a preset number threshold, generating a fault unrepaired notification information of the WEB service container, and sending the fault unrepaired notification information to a management user terminal.

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

[0015] On the other hand, an embodiment of the present application provides an SDN controller fault handling device, comprising: 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, and the instructions are executed by the at least one processor so that the at least one processor can execute any one of the SDN controller fault handling methods described above.

[0016] On the other hand, an embodiment of the present application provides a non-volatile computer storage medium for SDN controller fault processing, storing computer executable instructions, wherein the computer executable instructions can execute any one of the above-mentioned SDN controller fault processing methods.

[0017] At least one of the above-mentioned technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects: by creating a health monitoring interface on the WEB service container, real-time monitoring of the running status of the WEB is realized, and by containerizing the functional part of the SDN, simple and fast deployment is achieved; the operation and maintenance cost is low, only one node is needed to run, and it automatically restarts after a failure, and the service recovery speed is fast. Because it is a container, the WEB function is relatively independent, and the entire business will not be affected when the module is restarted. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solution of the present application, some embodiments of the present application will be described in detail below in conjunction with the accompanying drawings, in which:

[0019] Figure 1 A flowchart of a method for handling SDN controller failures provided in an embodiment of the present application;

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

[0021] Figure 3 A schematic diagram of the structure of an SDN controller fault handling device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0022] In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work are within the scope of protection of the present application.

[0023] Some embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0024] Figure 1 A flow chart of a SDN controller fault handling method provided in an embodiment of the present application. The method can be applied to different business fields. Certain input parameters or intermediate results in the process allow manual intervention and adjustment to help improve accuracy.

[0025] The analysis method involved in the embodiment of the present application can be implemented by a terminal device or a server, and the present application does not impose any special restrictions on this. For the convenience of understanding and description, the following embodiments are described in detail by taking the SDN controller as an example.

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

[0027] It should be noted that containerization is a technology that packages an application and all its dependencies into an independent container, allowing the application to maintain a consistent running state in different environments. Containerization requires a container engine to be implemented, which is responsible for creating, running, and managing containers. Existing container engines include Docker, Podman, containerd, etc. Docker is the most widely used container engine, which simplifies the creation, deployment, and management of containers.

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

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

[0030] In an embodiment of the present 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 detection interface, namely the REST interface, is a communication method based on the HTTP protocol, which is used to realize data exchange between the client and the server. It follows the REST (Representational State Transfer) architectural style, emphasizes the state transfer of the presentation layer of resources, and realizes the operation of resources through a unified interface and standard HTTP methods. It is easy to learn and use, and can easily expand new resources and operations.

[0032] S102: Identify the state of the WEB service container according to the returned access result.

[0033] In an embodiment of the present application, the SDN controller accesses the health monitoring interface through the container engine, and identifies the state of the WEB service container based on the returned access result. If the returned access result does not have the running status data of the WEB service container, it is determined that the state of the WEB service container is abnormal; if the returned access result has the running status data of the WEB service container, it is determined that the state of the WEB service container is normal.

[0034] It should be noted that the present application uses container technology to place the WEB service in the created container, that is, the health monitoring interface on the container can receive and return the WEB's operating status information, indicating that the WEB service is running normally and has no abnormal status; if the WEB's operating status information cannot be received, it means that the WEB service is abnormal.

[0035] S103: When the state of the web service container is abnormal, restart the web service container through the container engine.

[0036] In an embodiment of the present application, if the state of the WEB service container is abnormal, the SDN controller will restart the service of the WEB service container through the container engine, and 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 should be noted that data persistence is the process of converting data from a temporary state to a permanently stored storage medium, ensuring that the data can still be accessed and used after the program stops running. It is the core of the information system. 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 the embodiment of the present application, you can choose whether to separate the SDN controller into a data persistence part according to your own needs.

[0039] Furthermore, after the WEB service container is restarted through the container engine, the present application also accesses the health monitoring interface again through the container engine, and identifies the state of the WEB service container according to the returned re-access result; when the WEB service container state is abnormal again, the WEB service container is restarted again, and when the number of restarts is greater than the preset number threshold, the fault unrepaired notification information of the WEB service container is generated, and the fault unrepaired notification information is sent to the management user terminal. Help users better understand the relevant issues of 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 for running query tasks and a scheduled task scheduling tool. The query task is triggered by the scheduled task scheduling tool, and the status of each device in the SDN environment is queried through the task query container.

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

[0043] Furthermore, the task query container status is identified according to the foreground process exit status code of the task query container; when the foreground process exit status code of the task query container is non-0, the task query container status is determined to be abnormal; when the foreground process exit status code of the task query container is 0, the task query container status is determined to be normal; when the task query container status is abnormal, the task query container is restarted through the container engine; when the task query container status is normal, the task query container is controlled to exit through the Docker container engine; and when the scheduled task scheduling tool triggers the query task next time, a new task query container is generated through the container engine.

[0044] It should be noted that the query task is a foreground task. When the task ends abnormally, the Docker engine will directly restart the container according to the restart strategy. If it ends abnormally, the container will exit automatically after executing the query task. The restart strategy is configured by the user through the SDN controller. In the embodiment of the present application, the on-failure[:max-retries]: command is used to configure the restart of the container only when the foreground process exits with a status code other than 0, and the maximum number of restarts is configured through max-retries.

[0045] To further explain, a foreground task is a task that, when running in a container, blocks the main process of the container and keeps the container running. In other words, the foreground task will occupy the container's resources until the task is completed or terminated. If the foreground task ends abnormally, the container will also exit.

[0046] It should be noted that although the embodiments of the present application are based on Figure 1 Steps S101 to S103 are described in sequence, but this does not mean that steps S101 to S103 must be performed in a strict order. Figure 1 The order shown in the figure is to introduce and explain step S101 to step S103 in sequence, in order to facilitate those skilled in the art to understand the technical solution of the embodiment of the present application. In other words, in the embodiment of the present application, the order between step S101 to step S103 can be appropriately adjusted according to actual needs.

[0047] pass Figure 1 The method creates a health monitoring interface on the WEB service container to monitor the running status of the WEB service in real time. By containerizing the functional part of SDN, the deployment is simple and fast. The entire deployment only requires one SDN node, with low operation and maintenance costs, automatic restart after failure, and fast service recovery. Due to the independence of the container, the WEB service function is relatively independent, and the module restart will not affect the entire business. The fault tolerance of the SDN controller is increased, and the impact of a module failure on the entire business is reduced.

[0048] Figure 2 A schematic diagram of an SDN controller layout of an SDN controller fault handling method provided in an embodiment of the present application.

[0049] exist Figure 2 In the figure, the upper left part is the WEB service container, including WEB1, WEB2, etc. To the right of the WEB service container is the TASK container, which is the task query container. The TASK container includes TASK1, TASK2, etc. To the right of the TASK container are many components responsible for data persistence. Below the WEB service container and the TASK container are the Docker container engine and the timer scheduling tool Corn, and at the bottom is the Linux OS system.

[0050] Figure 3 A structural diagram of an SDN controller fault handling device provided in an embodiment of the present application 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, and the instructions are executed by the at least one processor so that the at least one processor can execute any one of the above-mentioned SDN controller fault processing methods.

[0054] Some embodiments of the present application provide a non-volatile computer storage medium for SDN controller fault processing, storing computer executable instructions, wherein the computer executable instructions can execute any one of the above-mentioned SDN controller fault processing methods.

[0055] Each embodiment in this application is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0056] The devices and media provided in the embodiments of the present application correspond one-to-one to the methods. Therefore, the devices and media also have similar beneficial technical effects as the 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 appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented 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] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0059] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0060] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions 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-permanent storage in a computer-readable medium, random access memory (RAM), and non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0063] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules 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 technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0064] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0065] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the technical principle of the present application should all fall within the protection scope of the present application.

Claims

1. A method for handling SDN controller failures, characterized in that: The SDN controller includes a web service container and a container engine for running a web service, wherein the web service container includes a health monitoring interface created for the web service, and the method includes: The SDN controller accesses the health monitoring interface through the container engine; According to the returned access result, the state of the WEB service container is identified; When the state of the WEB service container is abnormal, the WEB service container is restarted by the container engine.

2. The method according to claim 1, characterized in that: The identifying the web service container state according to the returned access result specifically includes: If the returned access result does not have the running status data of the WEB service container, determining that the state of the WEB service container is abnormal; If the returned access result has the running status data of the WEB service container, it is determined that the status of the WEB service container is normal.

3. The method according to claim 1, characterized in that The SDN controller also includes a task query container and a scheduled task scheduling tool for running query tasks, and the method also includes: Trigger this query task through the scheduled task scheduling tool, and query the status of each device in the SDN environment through the task query container; Identifying the task query container status according to the foreground process exit status code of the task query container; When the state of the task query container is abnormal, the task query container is restarted by the container engine.

4. The method according to claim 3, characterized in that: The identifying the task query container status according to the foreground process exit status code of the task query container specifically includes: When the foreground process exit status code of the task query container is non-0, determining that the task query container status is abnormal; When the foreground process exit status code of the task query container is 0, it is determined that the task query container status is normal.

5. The method according to claim 3, characterized in that: The method further comprises: When the task query container state is normal, controlling the task query container to exit through the container engine; When the scheduled task scheduling tool triggers the query task next time, a new task query container is generated by the container engine.

6. The method according to claim 1, characterized in that The SDN controller further includes a node operating system, and the method further includes: Generate a restart log based on the restart information of the WEB service container, save the restart log to the node operating system, and perform data persistence on the restart log in the node operating system.

7. The method according to claim 1, characterized in that When the state of the WEB service container is abnormal, after restarting the WEB service container, the method further includes: Access the health monitoring interface again through the container engine; Identify the state of the WEB service container according to the returned re-access result; When the state of the WEB service container is abnormal again, restart the WEB service container again; When the number of restarts is greater than a preset number threshold, a failure unrepaired notification information of the WEB service container is generated, and the failure unrepaired notification information is sent to a management user terminal.

8. The method according to any one of claims 1 to 7, characterized in that: The method further comprises: The WEB service container and the task query container are both Docker containers, the health monitoring interface is a REST interface, and the scheduled task scheduling tool is Cron.

9. 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 executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the SDN controller fault processing method according to any one of claims 1 to 8.

10. A non-volatile computer storage medium for SDN controller fault handling, storing computer executable instructions, characterized in that: The computer executable instructions can execute the SDN controller fault handling method described in any one of claims 1 to 8.

Images