Configuration management method and device and related equipment

By maintaining a configuration snapshot database in the controller, subscribing to device configuration change events and storing snapshots, the problems of configuration loss and incomplete auditing during device restarts are solved, achieving efficient configuration recovery and unified management, and simplifying the configuration auditing process.

CN120856573APending Publication Date: 2025-10-28NEW H3C TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511090040.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-08-05
Publication Date
2025-10-28

AI Technical Summary

Technical Problem

The existing unified configuration distribution framework suffers from configuration loss upon device restart, slow and inefficient configuration recovery, and incomplete configuration auditing functionality, making it unable to uniformly manage configuration recovery and auditing for different southbound protocols.

Method used

By maintaining a configuration snapshot database in the controller, subscribing to device configuration change events, storing configuration snapshots, and uniformly converting them into NETCONF messages for configuration recovery when the device restarts, the configuration auditing process is simplified.

Benefits of technology

It achieves efficient configuration recovery when the device restarts, simplifies the configuration audit process, improves configuration recovery efficiency and audit efficiency, and supports unified management of multiple southbound protocols.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120856573A_ABST
    Figure CN120856573A_ABST
Patent Text Reader

Abstract

The invention relates to the technical field of network operation and maintenance, in particular to a configuration management method and device and related equipment. The method is applied to a controller, and the controller comprises a configuration snapshot database for maintaining service configuration which corresponds to each service and is not persisted into a starting configuration file during operation of each piece of equipment which is managed; the method comprises the following steps: sending first service configuration in a first format to target equipment through a first southbound management channel; subscribing to obtain a configuration change event of the service of the target device, the target device converting the first service configuration into a second service configuration in a second format supported by the service during operation, and the configuration change event comprising a configuration snapshot of the second service configuration; and storing the configuration snapshot of the second service configuration into a configuration snapshot data table corresponding to the service of the target equipment in the configuration snapshot database.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of network operation and maintenance technology, and in particular to a configuration management method, apparatus and related equipment. Background Technology

[0002] The unified configuration distribution framework involves interfacing with SDN controllers and other third-party applications for configuration distribution. Different upper-layer applications may use different southbound management channel protocols. The southbound unified configuration framework supports protocols such as NETCONF, SNMP, and command line, and uses channels such as WEBSOCKET, TELNET, and SSH for configuration distribution. The message formats carried by each protocol are also different. NETCONF messages are generally distributed in XML format, SNMP messages are generally distributed in BER encoded format, and SSH and TELNET channels generally handle command line format messages. The current solution to address the potential configuration loss due to device reboots in the unified configuration distribution framework is as follows:

[0003] Messages for different southbound protocols are stored in different configuration recovery queue databases. Each configuration recovery queue has a maximum length set for a single device, typically 1000 based on experience. This means that when configuration is distributed after the maximum length of the device's configuration recovery queue has been exceeded, a save operation is first performed on the device to persist the previously distributed configuration to the device's next startup configuration file. After the save operation is successful, all configuration data for that device is deleted from each configuration recovery queue. At the same time, to ensure the timely synchronization of the device's configuration file with the customer's orchestration configuration, the unified configuration distribution framework periodically saves the device's configuration to the device's next startup configuration file.

[0004] When a device restarts, the unified configuration distribution framework detects the restart event and reorders the configurations in the command line, SNMP, and NETCONF configuration recovery queues in ascending order of time. It then sequentially executes the configuration data in each configuration recovery queue to restore the configuration one by one, ensuring that configurations not persisted to the device's configuration file for the next startup are not lost.

[0005] Meanwhile, to address configuration auditing, separate configuration auditing is performed based on the configuration data of each southbound channel. SNMP records the OID and attribute values ​​for configurations issued to the channels, and configuration auditing uses the OID to query the corresponding value for comparison. For configurations issued via NETCONF messages, the corresponding configuration needs to be queried from the device based on the service identifier and compared with the data in the configuration audit database stored in the controller. As for configuration auditing using command lines as messages, the current auditing strategy is to ignore them directly, resulting in an incomplete overall configuration auditing function that is difficult to use. Summary of the Invention

[0006] This application provides a configuration management method, apparatus, and related equipment.

[0007] Firstly, this application provides a configuration management method applied to a controller, wherein the controller includes a configuration snapshot database that maintains service configurations corresponding to each service during the operation of each managed device, which are not persisted to the startup configuration file; the method includes:

[0008] Send the first service configuration in the first format to the target device through the first southbound management channel;

[0009] Subscribe to obtain the configuration change event of the service of the target device, wherein the target device converts the first service configuration into a second service configuration in a second format supported by the service runtime, and the configuration change event includes a configuration snapshot of the second service configuration;

[0010] The configuration snapshot of the second service configuration is stored in the configuration snapshot data table corresponding to the service of the target device in the configuration snapshot database.

[0011] Optionally, the data structure of the second service configuration is a tree table structure; the second service configuration includes the path, operation type, and configuration attribute value configured in the tree table.

[0012] Optionally, the configuration change event is:

[0013] Add configuration event, and / or delete configuration event, and / or update configuration property value event.

[0014] Optionally, the controller further includes a configuration audit database that maintains the service configurations corresponding to each service during the operation of each managed device; the method further includes:

[0015] When it is determined that the target device will persist the second service configuration to the startup configuration file, the configuration snapshot of the second service configuration in the configuration snapshot database is deleted.

[0016] Optionally, the method further includes:

[0017] When the target device is determined to restart, the configuration snapshots of each service corresponding to the target device in the configuration snapshot database are converted into messages of a specified format and sent to the target device through a preset management connection channel, so that the target device can perform a configuration recovery operation based on the configuration snapshots of each service.

[0018] Optionally, the step of converting the configuration snapshots of each service corresponding to the target device in the configuration snapshot database into a message of a specified format and sending the message to the target device through a preset management connection channel includes:

[0019] The configuration snapshots of each service corresponding to the target device in the configuration snapshot database are converted into NETCONF messages, and the NETCONF messages are sent to the target device through the WEBSOCKET channel.

[0020] Secondly, this application provides a configuration management device applied to a controller, the controller including a configuration snapshot database that maintains service configurations corresponding to each service during the operation of each managed device, which are not persisted to the startup configuration file; the device includes:

[0021] The sending unit is used to send a first service configuration in a first format to the target device through a first southbound management channel;

[0022] The acquisition unit is used to subscribe to and acquire configuration change events of the service of the target device, wherein the target device converts the first service configuration into a second service configuration in a second format supported by the service runtime, and the configuration change event includes a configuration snapshot of the second service configuration;

[0023] The storage unit is used to store the configuration snapshot of the second service configuration into the configuration snapshot data table corresponding to the service of the target device in the configuration snapshot database.

[0024] Optionally, the data structure of the second service configuration is a tree table structure; the second service configuration includes the path, operation type, and configuration attribute value configured in the tree table.

[0025] Optionally, the configuration change event is:

[0026] Add configuration event, and / or delete configuration event, and / or update configuration property value event.

[0027] Optionally, the controller further includes a configuration audit database that maintains the service configurations corresponding to each service during the operation of each managed device; the device further includes:

[0028] The deletion unit is used to delete the configuration snapshot of the second service configuration in the configuration snapshot database when it is determined that the target device will persist the second service configuration to the startup configuration file.

[0029] Optionally, the sending unit is further configured to:

[0030] When the target device is determined to restart, the configuration snapshots of each service corresponding to the target device in the configuration snapshot database are converted into messages of a specified format and sent to the target device through a preset management connection channel, so that the target device can perform a configuration recovery operation based on the configuration snapshots of each service.

[0031] Optionally, when converting the configuration snapshots of each service corresponding to the target device in the configuration snapshot database into a message of a specified format and sending the message to the target device through a preset management connection channel, the sending unit is specifically used for:

[0032] The configuration snapshots of each service corresponding to the target device in the configuration snapshot database are converted into NETCONF messages, and the NETCONF messages are sent to the target device through the WEBSOCKET channel.

[0033] Thirdly, embodiments of this application provide a configuration management device, which includes:

[0034] Memory, used to store program instructions;

[0035] A processor is configured to invoke program instructions stored in the memory and execute the steps of the method as described in any one of the first aspects above, according to the obtained program instructions.

[0036] Fourthly, embodiments of this application also provide a computer-readable storage medium storing computer-executable instructions for causing a computer to perform the steps of the method as described in any of the first aspects above.

[0037] In summary, the configuration management method provided in this application is applied to a controller, which includes a configuration snapshot database that maintains service configurations corresponding to each service of each managed device during runtime, which are not persisted to the startup configuration file. The method includes: sending a first service configuration in a first format to a target device through a first southbound management channel; subscribing to and obtaining configuration change events of the service of the target device, wherein the target device converts the first service configuration into a second service configuration in a second format supported by the service during runtime, and the configuration change event includes a configuration snapshot of the second service configuration; and storing the configuration snapshot of the second service configuration in the configuration snapshot database in the configuration snapshot data table corresponding to the service of the target device.

[0038] The configuration management method provided in this application allows the controller to manage configuration snapshots of runtime configuration commands for each service on each device in terms of service dimensions. This makes configuration recovery more efficient when the device restarts, and eliminates concerns about the configuration formats supported by various southbound management protocols. For configurations issued by different southbound management protocols, a unified configuration snapshot format is maintained, simplifying the auditing process and improving auditing efficiency. Attached Figure Description

[0039] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments of this application or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings of the embodiments of this application.

[0040] Figure 1 A detailed flowchart of a configuration management method provided in an embodiment of this application;

[0041] Figure 2 This is a schematic diagram of the structure of a configuration management device provided in an embodiment of this application;

[0042] Figure 3 This is a schematic diagram of the hardware architecture of a configuration management device provided in an embodiment of this application. Detailed Implementation

[0043] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “the,” and “the” as used in this application and claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to any and all possible combinations comprising one or more of the associated listed items.

[0044] It should be understood that although the terms first, second, third, etc., may be used to describe various information in embodiments of this application, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" may also be interpreted as "when," "when," or "in response to a determination."

[0045] In related technologies, the unified configuration framework's device restart, configuration recovery, and configuration auditing processes are as follows:

[0046] At time T1, the controller or third-party APP sends the C1 configuration to the command line to restore the queue database;

[0047] At time T2, the controller or third-party APP sends the C2 configuration to the SNMP recovery queue database.

[0048] At time T3, the controller or third-party APP sends C3 configuration to the command line to restore the queue database;

[0049] At time Tn, the controller or third-party application sends the Cn configuration to the NETCONF recovery queue database.

[0050] If the device restarts at time T(n+1) and the configurations of C1 to Cn have not yet been persisted to the device configuration file (startup configuration file), the configurations of C1 to Cn need to be persisted to the device's next startup configuration file in sequence when the device comes back online. Otherwise, the device configuration will be lost, which may cause interruption of customer services and other unknown impacts.

[0051] The configurations in each configuration recovery queue are sorted by time, and the configurations from C1 to Cn are sent out one by one.

[0052] After the configuration is restored, perform a configuration audit.

[0053] C2 is configured as an SNMP configuration. The configuration audit strategy under the SNMP southbound channel is to record the list of OIDs of historical configurations and their corresponding attribute parameters in the audit configuration snapshot database. Then, the system queries the device one by one according to the OID and compares the value of the corresponding attribute parameter with the value stored in the configuration snapshot database to perform configuration auditing and maintenance.

[0054] Cn is configured as NETCONF configuration and is distributed through the WEBSOCKET configuration distribution channel. The strategy for handling configuration auditing in this channel is to store business configuration data based on business dimensions, and then query the corresponding configuration data on the device according to the business. The two are compared to perform configuration auditing and operation and maintenance.

[0055] C1 and C3 are command configurations, which are currently ignored by the configuration audit framework.

[0056] The solutions for device restart and configuration auditing under the above unified configuration distribution framework mainly have the following three problems:

[0057] 1) Different southbound protocols correspond to different configuration recovery queues, which is relatively complex to implement and lacks scalability.

[0058] 2) The configuration recovery process requires first obtaining all the configuration data about the device in the configuration recovery database, sorting them by time, and then performing configuration recovery message by message in chronological order. Configuration recovery is time-consuming and has poor performance.

[0059] 3) Meanwhile, in order to deal with configuration auditing, each southbound channel protocol handles it independently. For example, the business configuration auditing using the NETCONF configuration issued through the WEBSOCKET channel is one implementation, while the business configuration auditing using the SNMP channel is another implementation. The overall implementation is fragmented, and users cannot see the specific differences between the configuration on the device and the configuration orchestrated by the controller and third-party APP, which is not convenient for unified auditing and operation and maintenance.

[0060] Based on the technical problems of the above-mentioned solution for solving device restart and configuration auditing using the SDN unified configuration distribution framework, this application proposes a new solution for device restart, configuration recovery, and configuration auditing that enables multiple southbound channels to be managed.

[0061] For example, see Figure 1 The diagram shown is a detailed flowchart of a configuration management method provided in an embodiment of this application. This method is applied to a controller, which includes a configuration snapshot database that maintains service configurations for each managed device during runtime that are not persisted to the startup configuration file. The method includes the following steps:

[0062] Step 100: Send the first service configuration in the first format to the target device through the first southbound management channel.

[0063] In this embodiment of the application, if the controller determines that the target device needs to change the service configuration, it can send the service configuration in the first format supported by the Southbound Management Protocol to the target device through the Southbound Management Channel corresponding to the Southbound Management Protocol that the service has always supported.

[0064] For example, the first southbound management protocol can be any of the following protocols: NETCONF, SNMP, command line, etc. If the first southbound management protocol is NETCONF, then the first format of the first service configuration is a format supported by the NETCONF protocol.

[0065] Step 110: Subscribe to obtain the configuration change event of the service of the target device, wherein the target device converts the first service configuration into a second service configuration in a second format supported by the service runtime, and the configuration change event includes a configuration snapshot of the second service configuration.

[0066] In this embodiment of the application, after receiving the first service configuration in the first format sent by the controller, the target device needs to parse the first service configuration and convert it into a second service configuration in the second format supported by the service runtime. The service runs based on the second service configuration.

[0067] The controller can subscribe to configuration events of each device. When a target device determines that a configuration change has occurred, it generates a configuration change event. In other words, through a subscription-based reporting method, the target device reports the service configuration change event to the controller. In this embodiment, the configuration change event can carry a configuration snapshot of the second service configuration in a second format. In this way, the controller can obtain the configuration snapshot of the second service configuration in the second format of the first service configuration.

[0068] Step 120: Store the configuration snapshot of the second service configuration in the configuration snapshot database of the configuration snapshot data table corresponding to the service of the target device.

[0069] In this embodiment, for each device, a configuration snapshot database is maintained containing service configurations for each service during target device runtime that are not persisted to the startup configuration file. After subscribing to and obtaining a configuration change event of the target device, the second service configuration included in the configuration change event is obtained, and this second service configuration is stored in the configuration snapshot data table corresponding to that service of the target device in the configuration snapshot database. It should be noted that the snapshot data of each service configuration maintained in the configuration snapshot database are configurations that are not persisted to the startup configuration file on the device side.

[0070] In this embodiment of the application, the data structure of the second service configuration is a tree table structure; the second service configuration includes the path, operation type, and configuration attribute value configured in the tree table.

[0071] Based on the configuration management method of this application embodiment, when the multi-southbound configuration framework distributes configurations, it is no longer necessary to maintain separate configuration recovery queues and configuration audit databases for each southbound channel. Instead, it is only necessary to maintain a device runtime configuration snapshot database. The configuration snapshot database stores the various service tree table entries for each device. Since the number of services on the device side is limited, the configuration snapshot database can store a large amount of device configuration data. Moreover, the data in a single service tree structure table entry is not too much. Therefore, the configuration snapshot database can store a large amount of device configuration data in terms of the device's service tree structure dimension.

[0072] The configuration change event is:

[0073] Add configuration event, and / or delete configuration event, and / or update configuration property value event.

[0074] Specifically, for configuration types such as CLI, SNMP, and NETCONF, after each successful configuration distribution through the unified configuration distribution framework, the device proactively reports the names of tree structure entries, the values ​​of added, deleted, and updated configuration attributes, and the key Path and Key attributes through a subscription reporting method. The unified configuration distribution framework detects the configuration changes and specific changed values ​​on the device, thereby modifying the values ​​in the corresponding tree structure entries in the configuration snapshot database, ensuring that the runtime configuration on the device and the business tree structure data stored in the configuration snapshot database remain consistent in real time.

[0075] For example, taking the TUNNEL (service type, tunnel) tree table entry as an example, at a certain moment, the device sends out the runtime configuration of Tunnel1 and sets its Mode attribute parameter value to ModeValue1. At this time, the device side subscribes to and reports the tree structure table entry TUNNEL, whose Path and Key are TUNNEL->Tunnels->Tunnel->key(1)->configured parameter value, the operation type is creation, and sets the Mode value of Tunnel1 to ModeValue1. Then, the created TUNNEL tree structure table entry Tunnel1 is stored in the configuration snapshot database. If the device updates the configuration value of Tunnel1's Mode, at this time the device side subscribes to the tree structure table entry TUNNEL. The reported tree structure table entry is TUNNEL, whose Path and Key are TUNNEL->Tunnels->Tunnel->key(1), and the Mode of Tunnel1 is set to ModeValue2. The operation type is update, and the updated TUNNEL tree structure table entry Tunnel1 is stored in the configuration snapshot database. Finally, if the runtime configuration of Tunnel1 is deleted on the device, the reported tree structure table entry is TUNNEL, whose Path and Key are TUNNEL->Tunnels->Tunnel->key(1), and the operation type is delete. At this time, the Tunnel1 table entry data is deleted from the configuration snapshot database.

[0076] Furthermore, in this embodiment of the application, the controller further includes a configuration audit database that maintains the service configurations corresponding to each service during the operation of each managed device. Therefore, the method may further include the following steps:

[0077] After subscribing to and obtaining the configuration change event of the service of the target device, a configuration snapshot of the second service configuration is stored in the configuration audit database for subsequent configuration auditing.

[0078] When it is determined that the target device will persist the second service configuration to the startup configuration file, the configuration snapshot of the second service configuration in the configuration snapshot database is deleted.

[0079] Specifically, the device persists the configuration file according to a preset period, embedding the new configuration into the device's startup configuration file. At this point, the controller is notified that the configuration persistence operation is complete, allowing the controller to delete the locally stored service configuration persisted to the startup configuration file from the configuration snapshot database. In practical applications, if a device persists a new configuration to its startup configuration file, the device will not lose the configuration files included in the startup configuration file upon restart.

[0080] In this embodiment of the application, the above method may further include the following steps:

[0081] When the target device is determined to restart, the configuration snapshots of each service corresponding to the target device in the configuration snapshot database are converted into messages of a specified format and sent to the target device through a preset management connection channel, so that the target device can perform a configuration recovery operation based on the configuration snapshots of each service.

[0082] Specifically, the steps of converting the configuration snapshots of each service corresponding to the target device in the configuration snapshot database into messages of a specified format and sending the messages to the target device through a preset management connection channel include:

[0083] The configuration snapshots of each service corresponding to the target device in the configuration snapshot database are converted into NETCONF messages, and the NETCONF messages are sent to the target device through the WEBSOCKET channel.

[0084] In this way, after detecting that the target device has restarted, the configuration snapshot set of all services corresponding to the target device is queried in the configuration snapshot database. The configuration snapshots of all services corresponding to the target device are carried in the NETCONF message and sent to the target device side in one go through the WEBSOCKET channel so that the target device can perform configuration recovery.

[0085] The configuration management method provided in this application embodiment will be described in detail below with reference to specific application scenarios. For example, the device restart, configuration recovery, and configuration auditing process provided in this application embodiment is as follows:

[0086] At time T1, the controller or third-party APP issues C1 configuration. After the issuance is completed, the device reports the data changes of the ACL business tree structure. Here it is an addition, that is, the ACL related configuration attribute values ​​will be inserted into the configuration snapshot database.

[0087] At time T2, the controller or third-party APP sends out the C2 configuration. After the sending is completed, the device reports the data changes in the DEVICE service tree structure. Here it is a new addition, that is, the DEVICE related configuration attribute values ​​will be inserted into the configuration snapshot database.

[0088] At time T3, the controller or third-party APP sends out the C3 configuration. After the sending is completed, the device reports the data changes of the TUNNEL business tree structure. Here it is a new addition, that is, the TUNNEL related configuration attribute values ​​will be inserted into the configuration snapshot database.

[0089] At time Tn, the controller or third-party APP sends out the Cn configuration. After the sending is completed, the device reports the data changes of the OSPF service tree structure. Here it is a new addition, that is, the OSPF related configuration attribute values ​​will be inserted into the configuration snapshot database.

[0090] If the device restarts at time T(n+1) and the configurations of C1 to Cn have not yet been persisted to the device configuration file (startup configuration file), the configurations of C1 to Cn need to be persisted to the device's next startup configuration file when the device comes back online. Otherwise, the device configuration will be lost, which may cause interruption of customer services and other unknown impacts.

[0091] Once the device is online, the controller detects that the device has restarted, queries the configuration snapshot database for the complete set of business tree structure configurations for the device, converts all the business tree structure configurations into NETCONF messages, and sends them to the device side in one go through the WEBSOCKET channel to perform configuration restoration.

[0092] After the device configuration is restored, perform a configuration audit. Directly query the configuration data of the SDN controller and third-party APP from the configuration snapshot database and compare it with the value of the business tree configuration read on the device to see the configuration audit results.

[0093] The configuration management method provided in this application eliminates the need for a database design with multiple configuration recovery queues, offering only a single database source, thus simplifying the software architecture and reducing operational costs. The unified southbound framework supports any other southbound management protocol, providing a solid foundation for future software architecture expansion. Configuration auditing within the unified southbound framework is independent of specific southbound management protocols, further simplifying operations. Device restart and configuration recovery efficiency are significantly improved.

[0094] Based on the same inventive concept as the above-described method embodiments, see, for example, the following: Figure 2The diagram shown is a structural schematic of a configuration management device provided in an embodiment of this application. This device is applied to a controller, which includes a configuration snapshot database that maintains service configurations corresponding to each service running on each managed device, but which are not persisted to the startup configuration file. The device includes:

[0095] The sending unit 20 is used to send a first service configuration in a first format to the target device through a first southbound management channel;

[0096] The acquisition unit 21 is used to subscribe to and acquire configuration change events of the service of the target device, wherein the target device converts the first service configuration into a second service configuration in a second format supported by the service during runtime, and the configuration change event includes a configuration snapshot of the second service configuration;

[0097] Storage unit 22 is used to store the configuration snapshot of the second service configuration into the configuration snapshot data table corresponding to the service of the target device in the configuration snapshot database.

[0098] Optionally, the data structure of the second service configuration is a tree table structure; the second service configuration includes the path, operation type, and configuration attribute value configured in the tree table.

[0099] Optionally, the configuration change event is:

[0100] Add configuration event, and / or delete configuration event, and / or update configuration property value event.

[0101] Optionally, the controller further includes a configuration audit database that maintains the service configurations corresponding to each service during the operation of each managed device; the device further includes:

[0102] The deletion unit is used to delete the configuration snapshot of the second service configuration in the configuration snapshot database when it is determined that the target device will persist the second service configuration to the startup configuration file.

[0103] Optionally, the transmitting unit 20 is also used for:

[0104] When the target device is determined to restart, the configuration snapshots of each service corresponding to the target device in the configuration snapshot database are converted into messages of a specified format and sent to the target device through a preset management connection channel, so that the target device can perform a configuration recovery operation based on the configuration snapshots of each service.

[0105] Optionally, when converting the configuration snapshots of each service corresponding to the target device in the configuration snapshot database into a message of a specified format and sending the message to the target device through a preset management connection channel, the sending unit 20 is specifically used for:

[0106] The configuration snapshots of each service corresponding to the target device in the configuration snapshot database are converted into NETCONF messages, and the NETCONF messages are sent to the target device through the WEBSOCKET channel.

[0107] These units can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more digital signal processors (DSPs), or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when one of these units is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these units can be integrated together to form a system-on-a-chip (SOC).

[0108] Furthermore, regarding the configuration management device provided in this application embodiment, from a hardware perspective, the hardware architecture diagram of the configuration management device can be found in [reference needed]. Figure 3 As shown, the configuration management device may include: a memory 30 and a processor 31.

[0109] The memory 30 is used to store program instructions; the processor 31 calls the program instructions stored in the memory 30 and executes the above method embodiment according to the obtained program instructions. The specific implementation method and technical effect are similar, and will not be described again here.

[0110] Optionally, this application also provides a controller, including at least one processing element (or chip) for performing the above method embodiments.

[0111] Optionally, this application also provides a program product, such as a computer-readable storage medium storing computer-executable instructions for causing the computer to perform the above-described method embodiments.

[0112] Here, a machine-readable storage medium can be any electronic, magnetic, optical, or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, a machine-readable storage medium can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), solid-state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0113] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0114] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0115] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of this application can 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.

[0116] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. 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... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0117] Furthermore, these computer program instructions can also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate 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 the process. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

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

[0119] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A configuration management method, characterized in that, The method is applied to a controller, which includes a configuration snapshot database that maintains service configurations for each service corresponding to each managed device during runtime, but which are not persisted to the startup configuration file; the method includes: Send the first service configuration in the first format to the target device through the first southbound management channel; Subscribe to obtain the configuration change event of the service of the target device, wherein the target device converts the first service configuration into a second service configuration in a second format supported by the service runtime, and the configuration change event includes a configuration snapshot of the second service configuration; The configuration snapshot of the second service configuration is stored in the configuration snapshot data table corresponding to the service of the target device in the configuration snapshot database.

2. The method as described in claim 1, characterized in that, The data structure of the second service configuration is a tree table structure; the second service configuration includes the path, operation type, and configuration attribute value configured in the tree table.

3. The method as described in claim 1 or 2, characterized in that, The configuration change event is: Add configuration event, and / or delete configuration event, and / or update configuration property value event.

4. The method as described in claim 1 or 2, characterized in that, The controller also includes a configuration audit database that maintains the service configurations corresponding to each service during the operation of each managed device; The method further includes: When it is determined that the target device will persist the second service configuration to the startup configuration file, the configuration snapshot of the second service configuration in the configuration snapshot database is deleted.

5. The method as described in claim 1 or 2, characterized in that, The method further includes: When the target device is determined to restart, the configuration snapshots of each service corresponding to the target device in the configuration snapshot database are converted into messages of a specified format and sent to the target device through a preset management connection channel, so that the target device can perform a configuration recovery operation based on the configuration snapshots of each service.

6. The method as described in claim 5, characterized in that, The steps of converting the configuration snapshots of each service corresponding to the target device in the configuration snapshot database into a message of a specified format and sending the message to the target device through a preset management connection channel include: The configuration snapshots of each service corresponding to the target device in the configuration snapshot database are converted into NETCONF messages, and the NETCONF messages are sent to the target device through the WEBSOCKET channel.

7. A configuration management device, characterized in that, The device is applied to a controller, which includes a configuration snapshot database that maintains service configurations for each service corresponding to each managed device during runtime, which are not persisted to the startup configuration file; the device includes: The sending unit is used to send a first service configuration in a first format to the target device through a first southbound management channel; The acquisition unit is used to subscribe to and acquire configuration change events of the service of the target device, wherein the target device converts the first service configuration into a second service configuration in a second format supported by the service runtime, and the configuration change event includes a configuration snapshot of the second service configuration; The storage unit is used to store the configuration snapshot of the second service configuration into the configuration snapshot data table corresponding to the service of the target device in the configuration snapshot database.

8. The apparatus as claimed in claim 7, characterized in that, The data structure of the second service configuration is a tree table structure; the second service configuration includes the path, operation type, and configuration attribute value configured in the tree table.

9. A configuration management device, characterized in that, The configuration management device includes: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the steps of the method as described in any one of claims 1-6 according to the obtained program instructions.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing the computer to perform the steps of the method as described in any one of claims 1-6.