A method, device and medium for reporting service status of an ODL controller

Abstract

This application discloses a service status reporting method, device, and medium for an ODL controller. The method includes: a first ODL node establishing an initial WebSocket connection with a Neutron Server based on its own first IP address using a networking-odl plugin; wherein the first ODL node is the master node; creating an associated first database listener using the networking-odl plugin; disconnecting the WebSocket connection with the Neutron Server; the master node switching from the first ODL node to a second ODL node, the second ODL node establishing a WebSocket connection with the Neutron Server based on its own second IP address using a networking-odl plugin; creating an associated second database listener using the networking-odl plugin; and listening for service status change data of the virtual networking environment from the MDSAL database using the second database listener, and reporting the service status change data to the Neutron Server via the WebSocket connection. This method enables automatic reporting of virtual service status data after switching master nodes.

Description

Technical Field

[0001] This application relates to the field of SDN controller technology, and in particular to a service status reporting method, device and medium for an ODL controller. Background Technology

[0002] OpenDayLight (ODL) is a microservice-based SDN controller that supports a wide range of network protocols, such as OpenFlow, SNMP, NETCONF, OVSDB, BGP, and LISP. ODL boasts excellent programmability, employing OSGi Karaf as its underlying service module implementation and exposing module interfaces through MDSAL and the yang model. This model embeds LevelDB and includes a cluster communication solution based on Akka Cluster, offering rich functionality and out-of-the-box usability.

[0003] The OpenStack ML2 plugin for ODL – networking-odl – provides a mechanism for updating routing port status. Simply put, this plugin creates a websocket server. After the ODL controller starts, it connects to this websocket and sends the MDSAL operational database data change events of the Neutron port to this websocket server. After receiving the message, the plugin parses the port status (status) from it and updates it in the Neutron Server, thus realizing the reporting of Underlay routing port status.

[0004] However, in a hardware overlay networking environment under an ODL cluster, since the networking-odl plugin only knows the unique virtual IP of the controller cluster, when implementing the virtual IP through solutions such as keepAlive, the initialization of the websocket connection will create a database listener on a specific ODL node. However, after switching the master node, the websocket will not be able to find the database listener after re-establishing the connection with the new master node, and it will be unable to automatically report the business status change data to the Neutron Server. Summary of the Invention

[0005] This application provides a method, device, and medium for reporting the business status of an ODL controller, which solves the problem that after switching master nodes, the database listener cannot be found after the websocket and the new master node re-establish a connection, and the business status change data cannot be automatically reported to the Neutron Server.

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

[0007] On one hand, this application provides a method for reporting the service status of an ODL controller. The method includes: a first ODL node establishing an initial WebSocket connection with a Neutron Server using a networking-odl plugin based on its first IP address; wherein the first ODL node is a master node; creating an associated first database listener using the networking-odl plugin; disconnecting the WebSocket connection with the Neutron Server; if the master node switches from the first ODL node to a second ODL node, the second ODL node establishing an initial WebSocket connection with the Neutron Server using the networking-odl plugin based on its second IP address; creating an associated second database listener using the networking-odl plugin; and, based on the second database listener, monitoring service status change data of the virtual networking environment from the MDSAL database, reporting the service status change data to the Neutron Server via the WebSocket connection.

[0008] In one example, the step of listening to service status change data of the virtual networking environment from the MDSAL database according to the second database listener specifically includes: within a preset period, the second ODL node extracts the configuration information of the preset listening type of the physical network device through the MDSAL database listening mechanism; based on the configuration information, determines the virtual service status data corresponding to the virtual networking environment, and stores the virtual service status data in the MDSAL database; in the MDSAL database, compares the virtual service status data with the historical virtual service status data; if they are inconsistent, generates service status change data of the virtual networking environment, and listens to the service status change data of the virtual networking environment according to the second database listener.

[0009] In one example, before determining the virtual service status data corresponding to the virtual networking environment based on the configuration information and storing the virtual service status data in the MDSAL database, the method further includes: the second ODL node creating a compatibility layer for the MDSAL database; and through the compatibility layer, setting the listening field type for the physical network device to register field listening for the MDSAL database.

[0010] In one example, the configuration information is text information. The second ODL node extracts the configuration information of the preset listening type of the physical network device through the listening mechanism of the MDSAL database. Specifically, the second ODL node parses the configuration information to obtain tree configuration information in a tree structure. Then, it extracts the configuration information of the preset listening type of the physical network device from the tree configuration information using regular expressions.

[0011] In one example, the second ODL node parses the configuration information to obtain tree-structured configuration information in a tree-like display format. Specifically, when the second ODL node traverses the configuration information, if a parent node is detected, a tree-structured group is generated for the parent node; it is determined whether the parent node includes child nodes; if so, the child nodes are assigned to the tree-structured group; after traversal, multiple tree-structured groups are generated to obtain tree-structured configuration information in a tree-like display format.

[0012] In one example, disconnecting the websocket connection with the Neutron Server specifically includes: disconnecting the websocket connection with the Neutron Server if the first ODL node is offline in a non-faulty state or is unable to run in a faulty state; after creating the associated second database listener through the networking-odl plugin, the method further includes: if an error message is detected in the first database listener when the first ODL node changes from an offline state to an online state, deleting the first database listener.

[0013] In one example, after reporting the business status change data to the Neutron Server via the WebSocket connection, the method further includes: retrieving the management interface display model corresponding to the field type of the business status data change in a pre-built mapping table; and displaying the business status data change on the management interface based on the management interface model.

[0014] In one example, the method further includes: if the virtual service status data is consistent with the historical virtual service status data, the second ODL node calculates the time difference between the acquisition time of the virtual service status data and the acquisition time of the historical virtual service status data; calculates the difference between the time difference and the time of a preset period; if the difference is greater than a preset difference threshold, it is determined that the first ODL node and the second ODL node have simultaneously suspended operation.

[0015] On the other hand, embodiments of this application provide a service status reporting device for an ODL controller, applied to a second ODL node, 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, the instructions being executed by the at least one processor to enable the at least one processor to: if the master node switches from a first ODL node to a second ODL node, the second ODL node establishes an initial websocket connection with the Neutron Server based on its second IP address through the networking-odl plugin; wherein the first ODL node establishes an initial websocket connection with the Neutron Server based on its first IP address through the networking-odl plugin; create an associated first database listener through the networking-odl plugin; disconnect the websocket connection with the Neutron Server; create an associated second database listener through the networking-odl plugin; and, based on the second database listener, listen for service status change data of the virtual networking environment from the MDSAL database, and report the service status change data to the Neutron Server through the websocket connection.

[0016] On the other hand, embodiments of this application provide a non-volatile computer storage medium for reporting the service status of an ODL controller, storing computer-executable instructions applied to a second ODL node. The computer-executable instructions are configured as follows: if the master node switches from a first ODL node to a second ODL node, the second ODL node, based on its second IP address, establishes an initial WebSocket connection with the Neutron Server through the networking-odl plugin; wherein, the first ODL node, based on its first IP address, establishes an initial WebSocket connection with the Neutron Server through the networking-odl plugin; creates an associated first database listener through the networking-odl plugin; disconnects the WebSocket connection with the Neutron Server; creates an associated second database listener through the networking-odl plugin; and, based on the second database listener, listens for service status change data of the virtual networking environment from the MDSAL database, and reports the service status change data to the Neutron Server through the WebSocket connection.

[0017] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

[0018] By using the networking-odl plugin, the Neutron Server is connected to the real IP address of the ODL node. In a cluster environment, this allows the ODL node of the new master node to re-establish an initial WebSocket connection with the Neutron Server after the WebSocket connection is lost each time the master node is switched. This enables the automatic creation of a database listener, allowing it to establish a listening relationship with the specific MDSAL database associated with the ODL node and continue to receive event dispatches from the listener regarding changes in the MDSAL database. Attached Figure Description

[0019] 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:

[0020] Figure 1 A flowchart illustrating a service status reporting method for an ODL controller provided in an embodiment of this application;

[0021] Figure 2 This application provides a schematic diagram of the framework of an ODL controller service status reporting system in an application scenario.

[0022] Figure 3 This is a schematic diagram of the structure of a service status reporting device for an ODL controller provided in an embodiment of this application. Detailed Implementation

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

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

[0025] Figure 1 This is a flowchart illustrating a service status reporting method for an ODL controller, provided in an embodiment of this application. Certain input parameters or intermediate results in this process can be manually adjusted to help improve accuracy.

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

[0027] S101: The first ODL node establishes an initial websocket connection with the Neutron Server through the networking-odl plugin based on its own first IP address.

[0028] The first ODL node is the master node.

[0029] It's important to note that the networking-odl plugin is crucial for the OpenStack cloud platform to call the SDN controller. The neutron-server is the server that provides neutron network services; any request from an individual with network needs will be sent to this server for network processing.

[0030] S102: Create the associated first database listener using the networking-odl plugin.

[0031] S103: Disconnect the websocket connection with the Neutron Server.

[0032] Specifically, if the first ODL node goes offline while not in a faulty state, or is unable to run while in a faulty state, the websocket connection with the Neutron Server will be disconnected. For example, if the first ODL node is powered off, it is in a faulty and inoperable state. If the first ODL node is offline while not in a faulty state due to a network interruption, it will be in a non-faulty offline state.

[0033] S104: If the master node switches from the first ODL node to the second ODL node, the second ODL node establishes an initial websocket connection with the Neutron Server through the networking-odl plugin based on its own second IP address.

[0034] S105: Create an associated second database listener using the networking-odl plugin.

[0035] Specifically, when the first ODL node transitions from an offline state to an online state, if an error message is detected in the first database listener, the first database listener will be deleted.

[0036] S106: According to the second database listener, the service status change data of the virtual networking environment is listened to from the MDSAL database, and the service status change data is reported to the NeutronServer server through the websocket connection.

[0037] In some embodiments of this application, a management interface display model corresponding to the field type of the business status data change is retrieved from a pre-built mapping table. Based on the management interface model, the business status data change is displayed on the management interface.

[0038] In some embodiments of this application, within a preset period, the second ODL node extracts the configuration information of the preset listening type of the physical network device through the listening mechanism of the MDSAL database.

[0039] Then, based on the configuration information, the corresponding virtual service status data in the virtual networking environment is determined, and the virtual service status data is stored in the MDSAL database.

[0040] In the MDSAL database, virtual service status data is compared with historical virtual service status data.

[0041] If there is a discrepancy, data on the changes in the service status of the virtual networking environment is generated, and the second database listener listens for these changes.

[0042] If they match, no more service status change data for the virtual networking environment will be generated.

[0043] In addition, due to certain special needs, the developers need to pause the operation of the ODL node cluster. At this time, the ODL node cluster cannot obtain business status data within the preset period.

[0044] Based on this, when the virtual service status data of the second ODL node is consistent with the historical virtual service status data, the second ODL node calculates the time difference between the acquisition time of the virtual service status data and the acquisition time of the historical virtual service status data.

[0045] Calculate the difference between the time difference and the preset period.

[0046] If the difference is greater than the preset difference threshold, it is determined that the first ODL node and the second ODL node have both stopped working at the same time; otherwise, it is determined that no simultaneous work stoppage has occurred.

[0047] In some embodiments of this application, for the MDSAL database, the listening mechanism of the ODL built-in database is used, but a compatibility layer is provided on the basis of the MDSAL database. It is not necessary to define yang for each database and then manually create a cluster listener and process WebSocket messages. That is, it is not necessary to create multiple MDSAL databases with different yang for the second ODL node. Instead, it is possible to use a shard on different nodes. That is, multiple ODL nodes are in the same shard, and the content between the databases associated with each ODL node is the same. Furthermore, with the help of a separate state database synchronized at the bottom layer of the Raft algorithm, it is only necessary to register a listener for a certain field of this database, and the generation of change events of its field data can be realized by using a global listener.

[0048] Based on this, the second ODL node creates a compatibility layer for the MDSAL database; through the compatibility layer, it sets the listening field type for the physical network device to register field listening for the MDSAL database.

[0049] In some embodiments of this application, the configuration information extracted by the second ODL node from the physical network device is text information. Instead of directly using regular expressions to restore it into a tree structure, the text information is modeled into a tree structure, which can more flexibly and accurately restore the pre-set configuration information of the physical network device into a tree structure, and has higher fault tolerance.

[0050] Specifically, the second ODL node parses the configuration information to obtain tree-structured configuration information.

[0051] When the second ODL node traverses the configuration information, if a parent node is detected, a tree structure group is generated for the parent node.

[0052] Determine if the parent node includes child nodes; if so, assign the child nodes to the tree structure group. If not, re-examine the parent node.

[0053] After traversal is complete, multiple tree structure groups are generated, resulting in tree configuration information displayed in a tree structure format.

[0054] Then, using regular expressions, the configuration information of the preset listening type of the physical network device is extracted from the tree-structured configuration information.

[0055] This application provides a fast, efficient, and compatible parsing solution for tree-structured configurations, enabling the determination of virtual service status based on configuration information. For example, the connectivity of a routing port depends on the correct routing configuration of its underlying network devices: appropriate VRF, VRF configuration, VNI, and VLAN mappings. For non-network devices, such as firewall hardware, configuration commands are generally returned based on tree structures. Therefore, this part requires a general tree-structured configuration parser, rather than hardcoding it into regular expressions or string searches, as the latter are difficult to handle correctly. For instance, in an indentation-based tree structure like `part1 part1.1 part1.2 part1.3`, if `part1` contains `part1.1`, a direct regular expression search is sufficient. However, if the configuration later changes to `part1 part1.0 part1.1 part1.2 part1.3`, this would break the regular expression rules. The function implemented in this invention can model tree-like commands: typically, show running-config, and then quickly find whether a parent node contains child nodes, or whether a child node exists on a parent node. Based on this method, the state detection is more robust and does not require separate adaptation for each hardware network device or even different versions of network devices, thus improving reliability.

[0056] It provides an abstraction for tree-structured command status checks, database listening, and message push processes in a hardware overlay networking environment. Compared to regular expressions and string searches, tree-structured command parsing offers better robustness at the data acquisition end and eliminates the need for compatibility issues with different switch versions and various switch or firewall models. The status check logic is also very simple. Compared to the single-node, single-database solution provided by ODL, the database listening and message push processes are easier to use, requiring no template code and only two or three lines of configuration for business integration. Furthermore, it adapts well to master node switching within the ODL cluster.

[0057] It should be noted that, although the embodiments in this application are based on... Figure 1 Steps S101 to S106 will be described sequentially, but this does not mean that steps S101 to S106 must be performed in a strict order. The reason this embodiment follows this order is... Figure 1 The order in which steps S101 to S106 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 S106 can be appropriately adjusted according to actual needs.

[0058] pass Figure 1The method uses the networking-odl plugin to connect the Neutron Server to the real IP address of the ODL node. In a cluster environment, this allows the ODL node of the new master node to re-establish an initial WebSocket connection with the Neutron Server after the WebSocket connection is lost each time the master node is switched. This enables the automatic creation of a database listener, allowing it to establish a listening relationship with the specific MDSAL database associated with the ODL node and continue to receive event dispatches from the Listener regarding changes in the MDSAL database.

[0059] Figure 2 This is a schematic diagram of the framework of an ODL controller service status reporting system in an application scenario provided by an embodiment of this application.

[0060] exist Figure 2 This paper presents an abstraction mechanism for extracting service status data of the virtual network environment from the tree configuration of the underlying network devices in an SDN environment based on Spine-Leaf hardware overlay networking on the OpenDaylight+OpenStack platform. Then, by leveraging OpenDaylight's MDSAL database listening mechanism, the status is updated to the MDSAL database, thereby triggering the Listener to exchange data with the Neutron Server with the established WebSocket connection. The changed status is then obtained in the networking-odl plugin and updated to the OpenStack platform. This mechanism can be used to quickly update the service status data of any stateful virtual service, such as the connection status of virtual overlay routing ports, VPN sites, and VPN IPSec sites, to OpenStack or OpenStack-compatible cloud platforms, thereby improving network status observability.

[0061] pass Figure 2 The system implements the reporting function of virtual router port status, VPN service, VPN IPSEC site connection, etc. in the hardware overlay networking environment of the OpenDayLight controller cluster. In other words, it implements an abstraction based on the basic ODL state communication mechanism. This abstraction can perform various targeted service detections on the switch configuration and status in the hardware overlay environment and reliably and stably report them to the Neutron server, including but not limited to the abstraction of router port status, VPN service status, and VPN IPSEC tree command parsing.

[0062] Based on the abstraction of data update listening and push processes for a single database on each ODL node, WebSocket is more suitable for state event change notifications compared to REST requests, with lower overhead. This abstraction is adaptable to different brands and versions of switches, load balancers, firewalls, and other devices, offering good versatility, low difficulty in adapting to business needs, and greater robustness and stability. (Site connection status, etc.)

[0063] For example, in existing technologies, separate code is used to obtain the configuration of each model and system version of switch and firewall. Then, regular expressions and strings are parsed, exposed as REST interfaces, and the networking-odl in the Neutron server polls for data, performs diffing on the data, and obtains state change information. Compared with this solution, this solution lacks a level of abstraction, the various parts are heavily coupled (switch configuration and code, switch version and code, code for parsing state changes, and code for sending state changes all rely on database transfers), and the performance is poor (the polling performance of the Neutron server cluster and ODL cluster for data changes is poor).

[0064] Based on the same idea, some embodiments of this application also provide devices and non-volatile computer storage media corresponding to the above methods.

[0065] Figure 3 This application provides a schematic diagram of the structure of a service status reporting device for an ODL controller, applied to a second ODL node, comprising:

[0066] At least one processor; and,

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

[0068] The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to:

[0069] If the master node switches from the first ODL node to the second ODL node, the second ODL node establishes an initial WebSocket connection with the Neutron Server using the networking-odl plugin based on its second IP address; wherein, the first ODL node establishes an initial WebSocket connection with the Neutron Server using the networking-odl plugin based on its first IP address; creates an associated first database listener using the networking-odl plugin; and disconnects the WebSocket connection with the Neutron Server.

[0070] Create a second associated database listener using the networking-odl plugin;

[0071] According to the second database listener, the service status change data of the virtual networking environment is listened to from the MDSAL database, and the service status change data is reported to the Neutron Server through the websocket connection.

[0072] Some embodiments of this application provide a non-volatile computer storage medium for reporting the service status of an ODL controller, storing computer-executable instructions, wherein the computer-executable instructions are configured as follows:

[0073] If the master node switches from the first ODL node to the second ODL node, the second ODL node establishes an initial WebSocket connection with the Neutron Server using the networking-odl plugin based on its second IP address; wherein, the first ODL node establishes an initial WebSocket connection with the Neutron Server using the networking-odl plugin based on its first IP address; creates an associated first database listener using the networking-odl plugin; and disconnects the WebSocket connection with the Neutron Server.

[0074] Create a second associated database listener using the networking-odl plugin;

[0075] According to the second database listener, the service status change data of the virtual networking environment is listened to from the MDSAL database, and the service status change data is reported to the Neutron Server through the websocket connection.

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

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

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

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

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

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

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

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

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

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

[0086] 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 service state reporting method of an ODL controller, characterized in that, The method includes: The first ODL node establishes an initial websocket connection with the NeutronServer server based on its own first IP address through the networking-odl plugin; wherein, the first ODL node is the master node; Create the associated first database listener using the networking-odl plugin; Disconnect the websocket connection with the Neutron Server. If the master node switches from the first ODL node to the second ODL node, the second ODL node establishes an initial websocket connection with the Neutron Server through the networking-odl plugin based on its own second IP address; Create a second associated database listener using the networking-odl plugin; According to the second database listener, the service status change data of the virtual networking environment is listened to from the MDSAL database, and the service status change data is reported to the Neutron Server through the websocket connection; The step of listening to service status change data of the virtual networking environment from the MDSAL database according to the second database listener specifically includes: Within a preset period, the second ODL node extracts the configuration information of the preset listening type of the physical network device through the listening mechanism of the MDSAL database; Based on the configuration information, determine the virtual service status data corresponding to the virtual networking environment, and store the virtual service status data in the MDSAL database; In the MDSAL database, the virtual service status data is compared with historical virtual service status data; If there is a discrepancy, service status change data of the virtual networking environment is generated, and the service status change data of the virtual networking environment is monitored by the second database listener. Before determining the virtual service status data corresponding to the virtual networking environment based on the configuration information and storing the virtual service status data in the MDSAL database, the method further includes: The second ODL node creates a compatibility layer for the MDSAL database; Through the compatibility layer, the listening field type for the physical network device is set to register field listening for the MDSAL database; The configuration information is text information. The second ODL node extracts the configuration information of the preset listening type of the physical network device through the listening mechanism of the MDSAL database, specifically including: The second ODL node parses the configuration information to obtain tree-structured configuration information. Using regular expressions, the configuration information of the preset listening type of the physical network device is extracted from the tree-structured configuration information; The method further includes: If the virtual service status data is consistent with the historical virtual service status data, the second ODL node calculates the time difference between the acquisition time of the virtual service status data and the acquisition time of the historical virtual service status data. The difference between the time difference and the time of the preset period is calculated. If the difference is greater than a preset difference threshold, it is determined that the first ODL node and the second ODL node have both stopped working at the same time.

2. The method according to claim 1, characterized in that, The second ODL node parses the configuration information to obtain tree-structured configuration information, specifically including: When the second ODL node traverses the configuration information, if a parent node is detected, a tree structure group is generated for the parent node. Determine whether the parent node includes child nodes; If so, the child node is assigned to the tree structure group; After traversal is complete, multiple tree structure groups are generated, resulting in tree configuration information displayed in a tree structure format.

3. The method according to claim 1, characterized in that, Disconnecting the websocket connection with the Neutron Server specifically includes: If the first ODL node is offline while in a non-faulty state, or is unable to run while in a faulty state, the websocket connection with the Neutron Server is disconnected. After creating the associated second database listener through the networking-odl plugin, the method further includes: When the first ODL node transitions from an offline state to an online state, if an error message is detected in the first database listener, the first database listener will be deleted.

4. The method according to claim 1, characterized in that, After reporting the business status change data to the Neutron Server via the WebSocket connection, the method further includes: In the pre-built mapping table, retrieve the management interface display model corresponding to the field type of the business status data change; Based on the management interface model, the changes in the business status data are displayed on the management interface.

5. A service status reporting device for an ODL controller, characterized in that, Applied to the second ODL node, including: At least one processor; and, 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: execute the service status reporting method for an ODL controller as described in claims 1-4.

6. A non-volatile computer storage medium for reporting the service status of an ODL controller, storing computer-executable instructions, characterized in that, Applied to the second ODL node, the computer-executable instructions are configured to execute the service status reporting method of an ODL controller as described in claims 1-4.

Images