Device configuration method

Abstract

The application discloses a device configuration method, relates to the technical field of data processing, and converts the configuration change request into a structured standard configuration data object, analyzes the influence range of the configuration change according to the standard configuration data object, outputs a configuration change plan, and then decomposes the configuration change plan into multiple configuration tasks and puts all the configuration tasks into a message queue, so that the production of the configuration tasks is completely decoupled from the actual execution on the device side, thereby breaking the serial blocking chain under the synchronous Push mode, eliminating the bottleneck that the total time consumption is linearly accumulated with the number of devices, and generating corresponding native execution instructions for different types of devices after the target configuration task is taken out from the message queue, so that unified configuration management of heterogeneous network devices is realized. The application meets the requirement on the response time of configuration change under the cloud network sensitive state service scenario.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a device configuration method. Background Technology

[0002] In cloud data centers and cloud-network converged environments, network device configuration management is a critical aspect of ensuring normal business operations. With the rapid development of cloud computing technology, the network scale of data centers continues to expand, the number of network devices increases, and the frequency of configuration changes rises, placing higher demands on the performance of network configuration management systems.

[0003] Currently, mainstream network configuration management tools typically employ a centralized management architecture when dealing with large-scale network devices, using a synchronous push mode for configuration distribution. Synchronous push mode refers to establishing a one-to-many direct connection between the management server and the target devices. The management server pushes configuration commands to the devices individually or in batches, and synchronously waits for the execution results from each device before continuing to distribute configurations to the next batch of devices.

[0004] In the above mode, the total time for configuration distribution directly depends on the number of target devices and the response time of each device. The total time increases linearly with the number of devices, which is difficult to meet the requirements for configuration change response time in cloud-network agile business scenarios. Summary of the Invention

[0005] The main purpose of this application is to provide a device configuration method that aims to solve the technical problem that current device configuration methods are unable to meet the requirements for configuration change response time in cloud-network agile business scenarios.

[0006] To achieve the above objectives, this application proposes a device configuration method, which includes: Upon receiving a configuration change request, the system converts the configuration change request into a structured standard configuration data object based on a preset standardized configuration model. Based on the standard configuration data object, analyze the scope of impact of the configuration change and output a configuration change plan; The configuration change plan is decomposed into multiple configuration tasks, and each configuration task is added to a message queue to decouple each configuration task from the device side asynchronously. The target configuration task is obtained from the message queue. Based on the type of the device to be configured, the standardized instructions in the target configuration task are converted into native execution instructions adapted to the device to be configured, and the native execution instructions are sent to the device to be configured.

[0007] In one embodiment, after the step of converting the configuration change request into a structured standard configuration data object according to a preset standardized configuration model, the method further includes: The standard configuration data object is updated to the preset configuration database as the target configuration state. The preset configuration database is independent of the running device to be configured. The preset configuration database is used to store the target configuration state of the device to be configured. The target configuration state is separate from the actual running configuration state of the device to be configured. The steps of analyzing the impact scope of configuration changes and outputting a configuration change plan based on the standard configuration data object include: Based on the standard configuration data object, analyze the scope of impact of the configuration changes; Based on the scope of impact and the updated configuration status in the preset configuration database, a configuration change plan is output.

[0008] In one embodiment, the step of analyzing the impact scope of the configuration change based on the standard configuration data object and outputting a configuration change plan further includes: Based on the device identification information in the standard configuration data object, determine the devices to be configured that are associated with this configuration change and generate a list of devices to be configured; Based on the connection relationships between the devices to be configured in the list of devices to be configured, and the dependencies between the configuration parameters corresponding to each device to be configured, the task distribution order of each device to be configured is determined. A configuration change plan is generated based on the list of devices to be configured and the order in which the tasks are issued.

[0009] In one embodiment, after updating the standard configuration data object to the preset configuration database as the target configuration state, the method further includes: Each configuration task is encapsulated into a configuration transaction, and a transaction identifier is assigned to the configuration transaction. After the step of sending the native execution command to the device to be configured, the method further includes: The final execution results of all configuration tasks in the configuration transaction are summarized and determined based on the transaction identifier. If all configuration tasks are executed successfully, the configuration snapshot of this configuration change is stored in the version history of the preset configuration database. If any configuration task fails to execute, the configuration transaction is rolled back, so that the device to be configured is restored to the configuration state before this configuration change.

[0010] In one embodiment, the step of adding each of the configuration tasks to the message queue includes: Each of the configuration tasks is published to the topic corresponding to the configuration change plan in the message queue; The step of retrieving the target configuration task from the message queue includes: Multiple configuration execution agents subscribe to the topic and pull the corresponding target configuration tasks from the topic in a concurrent consumer mode to achieve parallel execution of configuration tasks.

[0011] In one embodiment, the step of adding each of the configuration tasks to the message queue further includes: Obtain the complexity and urgency levels of this configuration change; Based on the complexity level and urgency level, a target scheduling strategy is determined from a variety of preset scheduling strategies; According to the target scheduling strategy, each of the configured tasks is added to the message queue, wherein the multiple preset scheduling strategies include concurrent scheduling strategy, sequential scheduling strategy and batch scheduling strategy.

[0012] In one embodiment, converting standardized instructions in the target configuration task into native execution instructions adapted to the device to be configured, based on the type of the device to be configured, includes: Based on the type of the device to be configured, a corresponding target adapter class is matched from the heterogeneous device abstraction layer. The heterogeneous device abstraction layer has pre-defined adapter classes corresponding to various device types. Each adapter class implements the unified device abstraction interface. Each adapter class is used to convert standardized operations into specific operations of the corresponding manufacturer's device. The standardized instructions in the target configuration task are converted into native execution instructions adapted to the device to be configured by using the unified device abstraction interface implemented in the target adapter class.

[0013] In one embodiment, the target adapter class includes a protocol adapter class, and the step of converting standardized instructions in the target configuration task into native execution instructions adapted to the device to be configured through a unified device abstraction interface implemented in the target adapter class includes: Obtain the device capability information and device version information of the device to be configured; Based on the device capability information and the device version information, determine the target management protocol and target command syntax version supported by the device to be configured; Through the unified device abstraction interface implemented in the protocol adapter class, the standardized instructions in the target configuration task are adapted into protocol data units that conform to the target management protocol format according to the target management protocol; The command converter in the heterogeneous device abstraction and encapsulation layer matches the target command template from the preset command template library according to the target command syntax version, and dynamically converts the standardized instructions into native execution instructions adapted to the device to be configured through the target command template.

[0014] In one embodiment, when there are multiple devices to be configured, before the step of sending the native execution instruction to the devices to be configured, the method further includes: Send a preparation request to the device to be configured, the preparation request being used to detect whether each of the devices to be configured has the conditions for configuration execution; Receive the preparation response returned by each of the devices to be configured; If all the prepared responses indicate that the conditions for configuration execution are met, the native execution command may be issued; If any of the prepared response indications does not meet the conditions for configuration execution, a rollback command is sent to the device to be configured that has been successfully prepared to cancel the configuration change.

[0015] In one embodiment, before the step of analyzing the impact scope of the configuration change based on the standard configuration data object and outputting the configuration change plan, the method further includes: The standard configuration data object is pre-verified; wherein the pre-verification includes at least one of the following: performing compliance verification on the configuration instruction format and configuration parameter value range in the standard configuration data object, performing consistency verification on the logical dependency relationship between configuration parameters in the standard configuration data object, retrieving the current existing configuration data from the preset configuration database, comparing the configuration parameter fields in the standard configuration data object with the existing configuration data, and detecting whether there are Internet Protocol address conflicts and / or routing policy conflicts. If the pre-verification fails, the configuration change process will be terminated and an error feedback message will be output.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: This application transforms the configuration change request into a structured standard configuration data object. Based on this standard configuration data object, it analyzes the impact scope of the configuration change, outputs a configuration change plan, and then decomposes the configuration change plan into multiple configuration tasks, all of which are placed into a message queue. This completely decouples the production of configuration tasks from the actual execution on the device side, thereby breaking the serial blocking chain in the synchronous push mode and eliminating the bottleneck of total time increasing linearly with the number of devices. Simultaneously, after retrieving the target configuration task from the message queue, corresponding native execution instructions are generated for different types of devices, thus achieving unified configuration management for heterogeneous network devices. This meets the requirements for configuration change response time in cloud-network agile service scenarios. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] 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 or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the device configuration method of this application in Embodiment 1. Figure 2 The system architecture diagram provided in Embodiment 1 of the device configuration method of this application; Figure 3 This is a flowchart illustrating the third embodiment of the device configuration method of this application.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] Based on this, embodiments of this application provide a device configuration method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the device configuration method of this application.

[0024] In this embodiment, the device configuration method includes steps S10 to S40: Step S10: Receive a configuration change request and convert the configuration change request into a structured standard configuration data object according to a preset standardized configuration model. It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device or device configuration system that can realize the above functions.

[0025] Optionally, refer to Figure 2 The configuration system architecture can adopt a five-layer architecture, including a user layer, a core engine layer, a middleware layer, an edge proxy layer, and a device layer. The core engine layer includes a configuration management engine, an asynchronous driver engine, and a consistency guarantee engine; the middleware layer includes a message queue; the edge proxy layer includes configuration execution agents deployed in various network device areas; and the device layer includes multiple heterogeneous network devices.

[0026] The configuration management engine is responsible for modeling, version management and change planning of configuration data; the asynchronous driving engine is responsible for the asynchronous scheduling and execution of configuration tasks; the consistency guarantee engine is responsible for transaction management and consistency guarantee of configuration changes; the message queue is used to realize task persistence and asynchronous decoupling; and the configuration execution agent is used to receive configuration tasks and execute specific configuration operations, thus forming a complete closed-loop link from the issuance of configuration intent to the final execution of the device.

[0027] Optionally, the device configuration system receives configuration change requests from users or external automation platforms through a configuration management interface or application programming interface provided by the user layer. The original data of the request contains the network configuration changes that the user expects.

[0028] The configuration management engine obtains the configuration change request and parses and maps its fields according to a predefined standardized configuration model. It extracts the unstructured or semi-structured configuration description information from the user's original request and fills it into the fields defined in the standardized configuration model, generating a structured standard configuration data object containing device identification information and configuration parameter fields. This allows all subsequent processing steps to operate based on a unified format configuration data object, eliminating the need for repeated parsing or format adaptation of the user's original request.

[0029] For example, the configuration-state management engine can maintain a field mapping table that records the mapping relationship between common field names in configuration change requests and their corresponding field names in the standardized configuration model. When the configuration-state management engine receives a configuration change request, it first parses the data format of the request. If the request is in JSON (JavaScript Object Notation, a lightweight data exchange format), the engine directly reads the values ​​of each field from the JSON object. If the request is in command-line text format, the engine extracts key parameters such as device identifier, interface name, and IP (Internet Protocol) address from the text using regular expression matching. The configuration-state management engine then iterates through each field in the extracted results, looks up the corresponding standardized model field name in the field mapping table, and then fills the extracted value into the corresponding field of the standardized configuration data object, completing the structured transformation.

[0030] Optionally, the preset standardized configuration model can be predefined and stored in the configuration management engine; the preset standardized configuration model is a data structure template that describes the configuration information of network devices. This data structure template uniformly specifies the field names, data types, value ranges and nesting relationships of device configuration in the form of structured data objects, so that the configuration information of devices from different manufacturers and different models can be expressed under the same data structure framework.

[0031] In one feasible implementation, after the step of converting the configuration change request into a structured standard configuration data object according to a preset standardized configuration model, the following may also be added: The standard configuration data object is updated to the preset configuration database as the target configuration state. The preset configuration database is independent of the running device to be configured. The preset configuration database is used to store the target configuration state of the device to be configured. The target configuration state is separate from the actual running configuration state of the device to be configured. Optionally, a preset configuration database is pre-deployed in the configuration management engine; this preset configuration database is independent of the central database in the local storage of each device to be configured; this preset configuration database does not directly interact with the running devices and is used to store planning data for device configuration.

[0032] Optionally, the configuration management tool writes the standard configuration data object as the target configuration state into the preset configuration database. This preset configuration database is physically or logically independent from the local storage of each device to be configured, and does not directly connect to or operate on the running devices to be configured. The preset configuration database maintains the target configuration state record corresponding to each device to be configured according to the device identifier. The newly written target configuration state will overwrite or add the expected configuration data corresponding to the device to be configured.

[0033] There is no automatic synchronization binding relationship between the target configuration state and the actual running configuration state currently in effect on each device to be configured. The system allows numerical differences between the target configuration state and the device to be configured.

[0034] Optionally, the default configuration database can be deployed using a relational database (such as MySQL or PostgreSQL). The default configuration database internally establishes a device configuration master table according to a standardized design. This device configuration master table uses the device identifier as the primary key and stores the complete standardized configuration data object of the device to be configured in JSONB or XML field type. At the same time, the default configuration database also maintains a configuration version history table, which is used to record the device identifier, version number, write timestamp and operation source involved in each write operation.

[0035] The configuration management engine first queries the configuration database main table to see if the configuration record for the device to be configured already exists, based on the device identification information in the standard configuration data object. If it exists, it uses an atomic update operation to overwrite the old record with the newly generated configuration data object and adds a new record in the version history table to mark the version number increment. If it does not exist, it directly inserts a new record and creates an initial version record in the version history table.

[0036] After the write operation is completed, the configuration management engine returns a write success response to the caller. At this time, the standard configuration data object becomes the current target configuration state of the device to be configured, while the actual local running configuration state of the device to be configured remains unchanged, and the two are in a separate state.

[0037] Because the pre-configured database is isolated from the running devices, the configuration data has been persisted in an independent storage space before entering the actual distribution process. All verification and analysis can be performed without interfering with the normal operation of the device to be configured. Furthermore, since the target configuration state and the actual running configuration state are independent of each other and differences are allowed, the system can complete multiple rounds of configuration adjustment and verification without changing the current running state of the device to be configured. After verification, the system will uniformly drive the distribution, avoiding the risk of configuration errors directly penetrating the running network and causing business interruption in traditional solutions.

[0038] In one feasible implementation, after updating the standard configuration data object as the target configuration state to the preset configuration database, it is also possible to: encapsulate each configuration task into a configuration transaction and assign a transaction identifier to the configuration transaction.

[0039] Optionally, the configuration-state management engine obtains all configuration tasks involved in this configuration change, associates and groups these tasks according to the same change operation they belong to, and encapsulates them into a configuration transaction. This configuration transaction exists in the system as a logical unit, containing a complete set of all configuration tasks to be executed in this change and the relationships between these tasks. After encapsulation, the configuration-state management engine calls its internal transaction identifier generator to generate a globally unique transaction identifier for the configuration transaction, and establishes an association record between this transaction identifier and each configuration task within the transaction. This ensures that in subsequent, dispersed processing stages such as task decomposition, message queue transmission, device execution, and status reporting, each task can be traced and grouped to the same change operation through this transaction identifier.

[0040] Optionally, the configuration-state management engine internally maintains a transaction context manager. This manager uses a UUID (Universally Unique Identifier) ​​generation algorithm to generate a 128-bit unique identifier as the transaction identifier at the start of each change operation. When encapsulating a configuration transaction, the configuration-state management engine first retrieves a list of references to all configuration tasks involved in this change from the memory cache, and then creates a transaction context object. This object contains four fields: transaction identifier, creation timestamp, change operation type, and a list of associated tasks. After encapsulation, the configuration-state management engine writes the transaction identifier to the configuration record corresponding to this change in the preset configuration database, and simultaneously persists the complete information of the transaction context object to the transaction log table for subsequent status tracking and fault recovery.

[0041] For example, if a configuration change involves three devices (device A, device B, and device C), after generating the configuration tasks for the three devices, the configuration management engine creates a configuration transaction with the transaction identifier "TX-20260728-ABC123" and records this transaction identifier in the corresponding configuration records for the three devices. This allows the system to query all devices to be configured and their execution status involved in this change at any time later through this transaction identifier.

[0042] Since all configuration tasks generated by the same change operation are encapsulated into the same transaction and share a unique transaction identifier, the system can perform unified state tracking and atomic control of each task in subsequent stages such as asynchronous distribution, parallel execution on multiple devices, and state aggregation. This makes the configuration operations scattered on different devices logically bound into a whole, providing a data organization foundation for achieving atomic commit and unified rollback of configuration changes on multiple devices.

[0043] Step S20: Based on the standard configuration data object, analyze the scope of impact of the configuration change and output the configuration change plan; Optionally, the configuration management engine uses the device identification information and configuration parameter fields in the standard configuration data object as the main basis for analysis. It identifies the network elements involved in the configuration parameter fields, such as the devices to be configured, interfaces, and protocol instances, one by one, and combines the topological connection relationship between the devices to be configured and the reference dependency relationship between the configuration parameters to comprehensively determine the configuration change plan.

[0044] Optionally, the configuration change plan shall include at least the identifiers of all devices to be configured involved in this change and the specific configuration sub-items corresponding to each device to be configured.

[0045] Optionally, the configuration-state management engine internally maintains a global network topology graph. This graph stores network devices as nodes and physical or logical connections between devices as edges using a graph data structure. When the configuration-state management engine obtains a standard configuration data object, it first parses the device identifier field in the object to determine the starting device directly involved in this change. Then, with the starting device as the center, it searches for other devices associated with that interface in the global network topology graph based on the interface information (such as VLAN configuration and IP address configuration) in the configuration parameter fields, and includes the searched associated devices in the scope of influence.

[0046] For example, when a user requests to change the IP address of a certain interface of device A from 192.168.1.1 to 192.168.2.1, the configuration-state management engine first identifies device A as the starting device. Then, it detects that this IP address change may affect the routing neighbor relationships within the network segment where device A resides. Next, it retrieves devices B and C, which have routing neighbor relationships with device A, from the topology graph. Finally, it determines that the scope of the change includes devices A, B, and C, and writes these three devices and their corresponding configuration sub-items into the configuration change plan. Simultaneously, the configuration-state management engine also determines the execution order based on the dependencies between devices. Configuration operations for devices without dependencies are orchestrated into multiple parallel task groups, while configuration operations for devices with dependencies are ordered according to the direction of dependency. Finally, the configuration change plan is output in the form of a dependency graph.

[0047] Because the configuration change plan is generated based on a thorough analysis of device topology relationships and configuration parameter dependencies, it avoids configuration failures or network faults caused by missing associated devices or disrupting the configuration order during the subsequent execution phase. At the same time, the structured plan output provides a clear basis for decomposing the overall change into multiple independent tasks, enabling large-scale configuration changes to be decomposed and managed in an orderly manner, thus improving the completeness and executability of configuration changes at the planning level.

[0048] In one feasible implementation, the method for analyzing the impact scope of configuration changes based on the standard configuration data object and outputting a configuration change plan can be: Based on the standard configuration data object, analyze the scope of impact of the configuration change; based on the scope of impact and the updated configuration status in the preset configuration database, output a configuration change plan.

[0049] Optionally, the configuration management engine analyzes the scope of impact of the configuration change based on the standard configuration data object, and combines the scope of impact with the updated target configuration status in the preset configuration database. That is, it reads the target configuration status data of each device to be configured currently stored in the configuration database, compares and confirms the list of devices to be configured and configuration sub-items determined by the scope of impact with the target configuration status of the device in the configuration database, and generates a structured configuration change plan based on this.

[0050] Optionally, the configuration management engine queries the preset configuration database using a structured query language to retrieve the latest target configuration status records for all devices to be configured within the affected area. Specifically, the configuration management engine can first extract a list of device identifiers to be configured from the impact area analysis results, and then send a batch query request to the preset configuration database to retrieve the latest target configuration status data corresponding to each device identifier in the list.

[0051] After the default configuration database returns the query results, the configuration management engine merges the current complete target configuration status of each device with some configuration parameter fields involved in this change request: for specific configuration sub-items involved in this change, the configuration content in the standard configuration data object shall prevail; for configuration sub-items not involved in this change, the existing configuration content in the configuration database shall remain unchanged.

[0052] After the merge is complete, the configuration management engine can organize the complete target configuration status of each device to be configured into structured change plan entries. Each change plan entry contains the device identifier and the complete target configuration data object of the device after the change. Finally, all entries are summarized and output as the configuration change plan.

[0053] In one feasible implementation, the step of analyzing the impact scope of the configuration change based on the standard configuration data object and outputting a configuration change plan may also include: Based on the device identification information in the standard configuration data object, determine the devices to be configured associated with this configuration change and generate a list of devices to be configured; based on the connection relationships between the devices to be configured in the list and the dependencies between the configuration parameters corresponding to each device to be configured, determine the task delivery order for each device to be configured; based on the list of devices to be configured and the task delivery order, generate a configuration change plan.

[0054] Optionally, the configuration management engine first parses the standard configuration data object, extracts the device identification information field contained in the object, and performs a matching search in the network topology information maintained internally by the system based on the device identification information to determine all devices to be configured associated with this configuration change request, and organizes the search results to generate a list of devices to be configured.

[0055] The configuration management engine obtains the physical or logical connection relationships between the devices in the list of devices to be configured, and also obtains the reference dependencies between the configuration parameters corresponding to each device. Based on the comprehensive analysis results of the above connection relationships and dependencies, the configuration change operations of each device to be configured in the list are sorted: for configuration operations with dependencies, the configuration operations of the dependent device are arranged to be executed after the configuration operations of the dependent device; for configuration operations without dependencies, they are arranged in a parallel execution order.

[0056] After sorting, the configuration management engine integrates the list of devices to be configured with the sorted task distribution order to generate a structured configuration change plan. Each entry in the plan contains a device identifier and a configuration sub-item for the device to be configured, arranged in the determined distribution order.

[0057] Since the task distribution order is determined by a combination of the actual connection relationship between devices and the logical dependency relationship of configuration parameters, it ensures that in the subsequent execution phase, the configuration changes of the dependent devices are completed before the configuration changes of the dependent devices, avoiding configuration failures or network interruptions caused by improper configuration distribution order, and improving the success rate of configuration changes in cross-device collaborative scenarios.

[0058] In one feasible implementation, after the configuration management engine updates the standard configuration data object to the preset configuration database and before performing impact analysis and generating a configuration change plan, the configuration management engine can first obtain the change level information of this configuration change.

[0059] This change level information can be read directly from the change level field carried when the user initiates a configuration change request, or it can be automatically evaluated and generated by the configuration management engine based on the number of devices involved in the change, the type of change, and its criticality.

[0060] After obtaining the change level information, the configuration-state management engine matches this information against a pre-defined approval process configuration table to determine the approval process corresponding to the current change level. This approval process contains one or more sequentially arranged approval nodes. Once the approval process is determined, the configuration-state management engine submits the standard configuration data object and its associated information to the first approval node of that process, awaiting review and approval from the approver at that node.

[0061] After receiving the approval result from the first approval node, the configuration management engine will proceed with the configuration data to the next approval node if the result is "passed." If the result is "failed," the approval process will be terminated and a failure message will be output. Once all approval nodes have returned "passed" results, the configuration management engine will allow the subsequent impact analysis and change plan generation steps to continue. If any approval node returns a "failed" result, the configuration management engine will terminate all subsequent processes for this configuration change and return a failure message to the user.

[0062] For configuration operations with a wide impact, involving critical business equipment, or with high risk of change, the system can automatically match a more stringent approval process to ensure that high-risk changes can only be executed after obtaining full authorization; for routine changes with a small impact and low risk, the system can match a simplified approval process to avoid excessive approval affecting operation and maintenance efficiency.

[0063] In one feasible implementation, before the step of analyzing the scope of impact of configuration changes based on the standard configuration data object and outputting a configuration change plan, the following may also be done: The standard configuration data object is pre-verified; wherein the pre-verification includes at least one of the following: verifying the compliance of the configuration instruction format and configuration parameter value range in the standard configuration data object; verifying the consistency of the logical dependencies between configuration parameters in the standard configuration data object; retrieving the current existing configuration data from the preset configuration database; comparing the configuration parameter fields in the standard configuration data object with the existing configuration data; and detecting whether there are Internet Protocol address conflicts and / or routing policy conflicts. If the pre-verification fails, the configuration change process is terminated and error feedback information is output.

[0064] Optionally, after converting the user configuration change request into a standard configuration data object and before performing impact analysis and generating a configuration change plan, the configuration management engine performs a pre-verification operation on the standard configuration data object. During the pre-verification process, the configuration management engine checks whether the configuration command format and configuration parameter values ​​in the standard configuration data object are within the legal range; it checks the logical dependencies between the configuration parameters within the standard configuration data object to confirm that all referenced parameters are defined and their values ​​meet dependency constraints; and it retrieves the current existing configuration data from the preset configuration database, comparing the configuration parameter fields in the standard configuration data object with the existing configuration data item by item to check for resource conflicts such as Internet protocol address conflicts or routing policy conflicts.

[0065] If any of the above pre-verification checks fail, the configuration management engine immediately terminates all subsequent processes for this configuration change and returns error feedback information containing the specific reasons for the error to the user layer.

[0066] Optionally, the configuration-state management engine may have a built-in pre-validation rule base, which predefines three types of rules—syntax validation rules, logic validation rules, and conflict detection rules—in the form of configuration files. Upon receiving a standard configuration data object, the configuration-state management engine executes the following validation process sequentially: During the syntax validation phase, the configuration management engine first determines the applicable syntax rule set based on the device type field in the standard configuration data object. Then, it checks each configuration instruction in the object to see if it is defined in the rule set, and whether the values ​​of each configuration parameter fall within the legal value range specified in the rule set. Taking IP address configuration as an example, the engine checks whether the address is in a valid dotted decimal format and whether the value is within the valid range of 0 to 255.

[0067] During the logic validation phase, the configuration management engine performs cross-validation on the configuration parameters in the standard configuration data object. For example, if the engine detects that the configuration data contains a sub-interface IP address configuration but not the corresponding parent interface configuration, it determines that a logical dependency is missing, triggering a logic validation failure.

[0068] During the conflict detection phase, the configuration management engine sends a structured query request to the preset configuration database to retrieve the current existing configuration data of all devices in the network segment or fault domain where the device to be configured is located. Then, it compares key resource fields such as IP address, VLAN (Virtual Local Area Network) number, and AS (Autonomous System) number from the standard configuration data object with the existing configuration data. If an IP address in the standard configuration data object is found to be the same as an IP address already used by a device in the existing configuration data, the engine determines that an Internet Protocol address conflict exists. Similarly, if a newly configured routing policy and an existing routing policy have the same destination network segment but different next hops, the engine determines that a routing policy conflict exists.

[0069] After pre-verification is completed, if an error is found in any verification stage, the configuration-state management engine will combine the error type, error location, and suggested correction method into standardized error feedback information and return it to the user through the user interface or application programming interface.

[0070] For example, when an IP address conflict is detected, the configuration management engine returns feedback information containing the conflicting device identifier and the conflicting IP address, prompting the user to change the IP address configuration.

[0071] Because pre-verification is completed before change planning and is performed entirely offline without involving any running devices, it can prevent the potential impact of configuration errors from spreading before they can occur. This avoids misconfigurations from entering subsequent change planning, task decomposition, message queue transmission, and device execution, thereby saving system processing and network transmission resources and avoiding the risk of network outages caused by configuration errors.

[0072] Step S30: Decompose the configuration change plan into multiple configuration tasks, and add each configuration task to a message queue so that each configuration task is asynchronously decoupled from the device side. Optionally, the asynchronous drive engine breaks down the overall configuration change plan into multiple independent configuration tasks according to the device dimension in the configuration change plan. Each configuration task corresponds uniquely to a device to be configured, and the task encapsulates the device identifier of the device and the set of standardized configuration instructions to be executed.

[0073] After the configuration tasks are split, the asynchronous driver engine publishes them one by one to the message queue of the middleware layer according to a preset routing strategy. The message queue persistently stores the received configuration tasks. After the publication operation is completed, the asynchronous driver engine returns immediately without waiting for the configuration tasks to be pulled and executed by the consumer, thus achieving complete decoupling of the publication of configuration tasks from the execution on the device side in terms of time.

[0074] Since the task publisher does not need to wait for the consumer to complete the processing before continuing to execute subsequent operations, the configuration change command operation itself is no longer subject to the execution time of the slowest device, fundamentally breaking through the performance bottleneck of the total time increasing linearly with the number of devices in the traditional synchronous mode.

[0075] Step S40: Obtain the target configuration task from the message queue; convert the standardized instructions in the target configuration task into native execution instructions adapted to the device to be configured according to the type of the device to be configured; and send the native execution instructions to the device to be configured.

[0076] Optionally, when the published configuration task arrives at the corresponding topic or partition of the message queue, the configuration execution agent deployed in the network area where the device to be configured is located actively pulls the configuration task from the message queue as the target configuration task.

[0077] Optionally, the configuration execution agent converts the standardized instructions in the target configuration task into native execution instructions adapted to the device to be configured, based on the type of the device to be configured.

[0078] For example, different types of devices support different formats. For devices using a command-line interface as their management interface, the configuration execution agent translates standardized commands into command-line configuration statements natively supported by their operating system. For devices using the NETCONF (Network Configuration Protocol) as their management interface, the configuration execution agent translates standardized commands into XML (Extensible Markup Language) format configuration messages conforming to the NETCONF protocol specification, rather than command-line strings. For devices using a Representational State Transfer Protocol interface, the configuration execution agent translates standardized commands into JSON or XML messages in a specific format and sends them to the device's northbound application programming interface via Hypertext Transfer Protocol requests.

[0079] Optionally, the execution agent is configured to send the native execution instructions to the device to be configured.

[0080] Different conversion strategies are adopted for different types of devices. Standardized instructions remain completely consistent across different devices, while the converted native execution instructions can be dynamically generated according to the specific type of device, thereby achieving unified configuration management for heterogeneous network devices.

[0081] In one feasible implementation, the configuration execution agent stores the standardized instructions from the target configuration task, along with the converted native execution instructions, in its local cache. During subsequent execution, if the configuration execution agent detects an interruption in the management connection with the device to be configured, preventing the immediate delivery of the native execution instructions, it marks the task status as "waiting for connection restoration" and continuously monitors the connection status with the device. Once the connection is restored, the configuration execution agent reads the previously stored native execution instructions from its local cache and resends them to the device to be configured for execution.

[0082] In addition, when the configuration execution agent receives a local rollback instruction from the consistency assurance engine, the configuration execution agent reads the configuration data of the device before the execution of this configuration task from the local cache, generates a recovery configuration instruction and sends it to the device to be configured, so that the device configuration is restored to the state before the change.

[0083] Since the configuration task data and the converted native execution instructions are stored in the local cache, the agent does not need to retrieve the task from the message queue or re-execute the instruction conversion after the connection is restored. It can directly issue the execution, reducing the overhead of repeated processing and improving the execution efficiency. At the same time, since the configuration data before the change is also cached locally, when a rollback operation is required, the agent does not need to retrieve the configuration before the change from the remote configuration database. It can complete the generation and issuance of the rollback instruction locally, speeding up the rollback response and improving the system's reliability and fault recovery capability in weak network environments.

[0084] In one feasible implementation, after the native execution instruction is sent to the device to be configured, the configuration execution agent sends the native execution instruction to the device to be configured, and the device to be configured executes the instruction and returns the original status information.

[0085] The format of the raw status information varies significantly depending on the device type and management protocol: command-line interface protocols return text-based command echoes and error messages; descriptive status transmission protocols return structured response messages in JSON or XML format; and simple network management protocols return a list of variable bindings.

[0086] After receiving the raw state information, the configuration execution agent passes it to the state resolver in the heterogeneous device abstraction layer. Based on the type of the device to be configured and the management protocol type used, the state resolver selects the appropriate parsing strategy, extracts key fields from the raw state information such as execution success status, error code, error description, and execution time, and then fills these extracted field values ​​into the corresponding field positions in the standardized state data object according to the field names and data types defined by the unified state model. After the transformation is complete, the state resolver returns the standardized state data object to the configuration execution agent, which then reports it as the execution result of the device to the consistency assurance engine.

[0087] Since the raw status information returned by all devices is converted into standard status data objects in the same format, the consistency assurance engine only needs to read the status fields according to the unified status model to complete the judgment when summarizing and judging the execution results of multiple devices. There is no need to write independent response parsing logic for each device type or each management protocol, which simplifies the implementation complexity of the upper-layer consistency assurance logic and improves the scalability and maintainability of the system in a multi-vendor heterogeneous environment.

[0088] In one feasible implementation, after the step of sending the native execution command to the device to be configured, the following may also be performed: The final execution results of all configuration tasks in the configuration transaction are summarized and determined based on the transaction identifier. If all configuration tasks are executed successfully, the configuration snapshot of this configuration change is stored in the version history of the preset configuration database. If any configuration task fails to execute, the configuration transaction is rolled back, so that the device to be configured is restored to the configuration state before this configuration change.

[0089] Optionally, the configuration execution agent reports the execution responses of each device as the final execution result to the consistency assurance engine. Based on the transaction identifier of the configuration transaction, the consistency assurance engine retrieves a list of identifiers for all configuration tasks associated with that transaction identifier from the message queue or system log, then collects the corresponding final execution results reported by each configuration execution agent, and summarizes and determines the final execution results of all configuration tasks in that transaction.

[0090] If the summary judgment result indicates that all configuration tasks in the transaction have been executed successfully, the consistency guarantee engine will store the complete configuration data of each device to be configured involved in this configuration change in the form of a configuration snapshot in the version history of the preset configuration database, and record the version number, timestamp and transaction identifier corresponding to this change.

[0091] If the summary judgment result indicates that the final execution result of any configuration task in the transaction fails, the consistency guarantee engine starts the rollback process. Based on the transaction identifier, it finds the devices to be configured that have successfully performed configuration changes in the transaction and their corresponding pre-change configuration states, and issues rollback instructions to these devices to restore their configuration states to the state before the start of this configuration change operation.

[0092] Because all configuration tasks within the same configuration transaction are uniformly tracked and aggregated using transaction identifiers, and the failure of any task triggers a complete rollback, the atomicity of configuration changes between related devices is ensured. That is, either all devices are changed to the new configuration state, or all devices retain their original configuration state, avoiding the cross-device configuration inconsistency problem caused by some devices succeeding while others fail in traditional solutions. Furthermore, since configuration snapshots are stored in the version history, the complete configuration state of each change is persistently saved, providing a reliable data foundation for subsequent configuration rollback and fault recovery.

[0093] In one feasible implementation, after the configuration snapshot is successfully stored in the version history of the preset configuration database, the configuration management engine or consistency assurance engine responds to the version comparison request initiated by the user or external system through the application programming interface or management interface, and reads the first configuration snapshot corresponding to the first version number and the second configuration snapshot corresponding to the second version number specified in the request from the version history of the preset configuration database.

[0094] After obtaining two configuration snapshots, the configuration management engine performs a field-by-field comparison between the two snapshots. This means comparing the values ​​of the same field name in both snapshots according to the field order defined in the standardized configuration model. For fields with different values, the engine records the field name, the field value in the first configuration snapshot (before the change), and the field value in the second configuration snapshot (after the change). The comparison results of all differing fields are summarized into a structured version difference report. This report includes at least a list of changed configuration fields, the before and after values ​​of each changed field, and the timestamp information related to the change.

[0095] Because configuration snapshots are stored in the form of structured, standardized data objects, version differences can be compared precisely at the structured field level without having to compare unstructured text line by line. This allows for accurate identification of which configuration fields were modified in each configuration change and their values ​​before and after the modification, providing precise visual evidence for operations and maintenance personnel to review changes, troubleshoot problems, and audit configurations.

[0096] In one feasible implementation, after sending the native execution command to the device to be configured and receiving the execution response from the device, the configuration execution agent first extracts the execution result from the execution response, including whether the operation was successful, the error code (if any), and the detailed output information returned by the device. Subsequently, the configuration execution agent integrates the above execution result with locally recorded information such as task identifier, device identifier, execution start time, and execution end time, and encapsulates it into a structured status reporting message according to a preset status reporting message format. This message contains at least four fields: device identifier, task identifier, execution status code, and execution log.

[0097] After encapsulation, the configuration execution agent sends the status reporting message to the execution monitoring component of the asynchronous driver engine through a pre-established status reporting channel (which is independent of the task distribution channel of the message queue). After receiving the message, the execution monitoring component updates the status record of the corresponding task.

[0098] Because the status reporting channel and the task distribution channel are independent of each other, the reporting of execution results will not be affected by the backlog of other tasks in the task queue. This ensures that the execution status can be transmitted to the asynchronous drive engine in a timely and reliable manner, providing real-time status data input to the execution monitoring component. This enables the system to promptly detect failed tasks and trigger corresponding retry or rollback processes, thereby improving the system's real-time response capability and reliability.

[0099] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Based on this, the method of adding each of the configuration tasks to the message queue can be: Each configuration task is published to the topic corresponding to the configuration change plan in the message queue.

[0100] Optionally, after decomposing the configuration change plan into multiple configuration tasks, the asynchronous drive engine does not send each configuration task randomly or uniformly to a single channel of the message queue. Instead, it first obtains the identification information carried in the configuration change plan (such as the network area identifier, fault domain identifier, or change type identifier of the change), and matches the corresponding topic in the topic set pre-created on the message queue server based on the identification information.

[0101] Once the corresponding topic is determined, the asynchronous driver engine publishes all configuration tasks generated from the decomposition of this configuration change plan to that topic one by one. This ensures that all configuration tasks belonging to the same configuration change plan are aggregated within the same logical channel, while configuration tasks from different configuration change plans are published to different topics. The configuration execution agent subscribes to topics corresponding to the network area or device range it is responsible for, pulls configuration tasks from those topics, and executes them.

[0102] Since all configuration tasks for the same configuration change plan are published to the same topic, the configuration execution agent can subscribe to specific topics to receive only the configuration tasks relevant to its scope of responsibility. This avoids interference from irrelevant tasks and reduces the overhead of filtering tasks. At the same time, tasks for different change plans are distributed across different topics. Backlog or processing delays of tasks in one topic will not affect the normal consumption of tasks in other topics, achieving resource isolation between change plans and improving system stability and scalability.

[0103] In one feasible implementation, the method of obtaining the target configuration task from the message queue may be: subscribing to the topic through multiple configuration execution agents, and pulling the corresponding target configuration task from the topic in a concurrent consumer mode to achieve parallel execution of the configuration task.

[0104] Optionally, multiple configuration execution agents initiate subscription requests to the message queue server via the message queue client upon startup, subscribing to topics corresponding to the network area or device range they are responsible for, and establishing long-lived connections with the message queue server. When there are unconsumed configuration tasks in the topic, each configuration execution agent pulls different configuration tasks from the topic as its target configuration tasks according to the message queue server's allocation mechanism. Subsequently, each agent independently and in parallel executes its pulled configuration tasks, including calling the heterogeneous device abstraction layer to complete the conversion of standardized instructions to native execution instructions and sending the native execution instructions to the corresponding devices to be configured.

[0105] Since multiple configuration execution agents can simultaneously pull different configuration tasks from the same topic and execute them in parallel, the processing capacity of configuration tasks expands almost linearly with the increase in the number of configuration execution agents, which greatly shortens the total completion time of the same number of configuration tasks. This further improves the system's concurrent processing capacity and overall throughput in large-scale device configuration scenarios, enabling the system to make full use of distributed agent resources and avoid a single agent becoming a performance bottleneck.

[0106] In one feasible implementation, the configuration execution agent sends a subscription request to the message queue server via the aforementioned long-lived connection. This request carries the name of the topic the agent is subscribing to (e.g., the topic corresponding to the network area it manages), declaring that the agent wishes to receive configuration tasks from that topic. Upon receiving the subscription request, the message queue server registers the agent as a consumer of that topic. When new configuration tasks arrive in that topic, the server pushes the configuration tasks to the configuration execution agent via the long-lived connection, or allows the agent to actively pull them via the long-lived connection.

[0107] During the maintenance of a persistent connection, if a network failure causes the connection to be interrupted, the configuration execution agent, upon detecting the interruption, immediately records the progress information of all configuration tasks currently received from the message queue but not yet processed, including the identifier of each task and its current execution stage. Once the network recovers and the persistent connection is re-established, the configuration execution agent continues receiving unfinished configuration tasks from the point of interruption based on the recorded progress information, without needing to re-acquire already received but unfinished tasks.

[0108] Because the configuration execution agent maintains a long connection with the message queue, configuration tasks can be pushed or pulled in real time after publication, avoiding the overhead of frequent connection establishment and disconnection in short connection mode and improving the timeliness of task transmission. At the same time, because progress information is recorded when the connection is interrupted and reception continues from the breakpoint after recovery, even in unstable network environments, the configuration execution agent can resume task reception from the breakpoint without re-acquiring all tasks, avoiding duplicate processing or omission of tasks.

[0109] In one feasible implementation, the method of adding each of the configuration tasks to the message queue can also be: Obtain the complexity level and urgency level of this configuration change; determine the target scheduling strategy from multiple preset scheduling strategies based on the complexity level and urgency level; add each configuration task to the message queue according to the target scheduling strategy, wherein the multiple preset scheduling strategies include concurrent scheduling strategy, sequential scheduling strategy and batch scheduling strategy.

[0110] Optionally, the asynchronous driver engine can obtain the complexity level and urgency level of this configuration change by directly reading the level field that the configuration management engine pre-evaluates and writes when generating the plan from the configuration change plan, or by calculating and generating it itself based on the number of devices and dependencies of the configuration task.

[0111] The asynchronous drive engine takes the complexity level and urgency level as input parameters, matches them among a variety of preset scheduling strategies, and selects the scheduling strategy that best suits the current configuration change request as the target scheduling strategy. For example, for changes with low complexity and high urgency, a concurrent scheduling strategy is selected; for changes with strong inter-device dependencies and high complexity, a sequential scheduling strategy is selected; and for changes with large scale and the need to control concurrent pressure, a batch scheduling strategy is selected.

[0112] After determining the target scheduling strategy, the asynchronous driver engine adds each configuration task to the message queue according to the execution logic of the strategy: if the target scheduling strategy is a concurrent scheduling strategy, all configuration tasks are published to the topic corresponding to the configuration change plan in the message queue at once; if the target scheduling strategy is a sequential scheduling strategy, the configuration tasks are published to the message queue one by one according to the device dependency order determined in the configuration change plan; if the target scheduling strategy is a batch scheduling strategy, the configuration tasks are grouped according to the preset batch size, and all configuration tasks in the group are published to the message queue at once in batches. After the configuration tasks of the current batch are pulled and confirmed by the consumer, the next batch of configuration tasks is published.

[0113] For change tasks with high urgency and no dependencies between devices, the system can automatically select a concurrent scheduling strategy to publish all tasks to the message queue at once for multiple agents to consume in parallel, minimizing the total change time and quickly responding to the urgent needs of agile services. For change tasks with strong dependencies between devices and high complexity, the system can automatically select a sequential scheduling strategy to ensure that the configuration tasks of dependent devices are consumed and executed first, and the configuration tasks of dependent devices are executed later, avoiding configuration failures due to disordered order. For change tasks with a large scale involving hundreds of devices, the system can automatically select a batch scheduling strategy to gradually advance the change with a controllable level of concurrency, avoiding the instantaneous impact on network bandwidth and device management interfaces caused by simultaneously distributing configurations to a large number of devices, thus improving the stability of the system in large-scale change scenarios.

[0114] In one feasible implementation, after the asynchronous driving engine publishes the configuration task to the message queue, the execution monitoring component in the asynchronous driving engine starts tracking the full lifecycle status of the configuration task. The execution monitoring component obtains the current execution status of each configuration task in real time by listening to the consumption confirmation information of the message queue, the status reporting messages of the configuration execution agent, and the heartbeat information of each agent. This includes whether the task has been pulled by an agent, whether it is being executed, whether it has been completed, and whether the completion result is success or failure.

[0115] When the execution monitoring component detects that the execution status of a configuration task has changed to execution failure, the component obtains the failure reason information returned by the task and classifies the failure reason according to the preset failure type classification rules to determine whether the failure is retryable or non-retryable. If it is determined to be retryable, the execution monitoring component adds the configuration task back to the corresponding topic in the message queue according to the preset retry strategy (including the maximum number of retries and the retry interval), waiting for the configuration execution agent to pull and execute it again. If it is determined to be non-retryable, or the number of retries for the task has reached the preset maximum number of retries threshold, the execution monitoring component marks the configuration task as a final failure and reports this final failure status to the consistency guarantee engine, which then triggers the overall rollback process of the configuration transaction to which the configuration task belongs.

[0116] For execution failures caused by temporary factors such as network fluctuations or temporary device overload, the system can automatically retry execution without manual intervention, improving the overall success rate of configuration changes and the system's self-healing capabilities. For failures caused by permanent factors such as command errors or device incompatibility, the system can promptly identify and trigger an overall rollback, avoiding resource waste and time delays caused by endless retries, and improving the system's fault handling efficiency and user experience.

[0117] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 Step S40 also includes steps S01~S02: Step S01: According to the type of the device to be configured, match the corresponding target adapter class from the heterogeneous device abstraction layer. The heterogeneous device abstraction layer has pre-set adapter classes corresponding to multiple device types. Each adapter class implements the unified device abstraction interface. Each adapter class is used to convert standardized operations into specific operations of the corresponding manufacturer's device. Optionally, after obtaining the target configuration task, the configuration execution agent parses the device identification information of the device to be configured from the target configuration task and passes the device identification information as a query condition to the heterogeneous device abstraction and encapsulation layer.

[0118] The heterogeneous device abstraction and encapsulation layer maintains a mapping relationship between device types and adapter classes. Based on the received device identification information, the encapsulation layer retrieves the corresponding manufacturer information, model information, and software version information of the device from the local device fingerprint database, and comprehensively determines the type identifier of the device.

[0119] The heterogeneous device abstraction layer uses the device type identifier as the matching key to search among multiple pre-defined adapter classes. It then identifies the adapter class uniquely corresponding to the device type to be configured from among the adapter classes written for devices from different manufacturers, selecting it as the target adapter class. During this matching process, the heterogeneous device abstraction layer ensures that the selected target adapter class fully implements all methods specified by the unified device abstraction interface.

[0120] Step S02: Through the unified device abstraction interface implemented in the target adapter class, the standardized instructions in the target configuration task are converted into native execution instructions adapted to the device to be configured.

[0121] Optionally, the configuration execution proxy calls the unified device abstraction interface provided by the matched target adapter class, and passes the standardized instructions in the target configuration task as parameters to the operation method corresponding to the unified device abstraction interface.

[0122] After receiving the standardized instruction, the target adapter class parses the standardized instruction into a specific operation type and parameter value according to its internally encapsulated command conversion rules and syntax templates corresponding to the device type. Then, it generates the corresponding native execution instruction according to the command format specific to the device type and returns the native execution instruction to the configuration execution agent for subsequent distribution.

[0123] By calling the unified interface mentioned above, the configuration execution agent can obtain native execution instructions applicable to the device to be configured without needing to understand the specific conversion logic inside the target adapter class.

[0124] Optionally, the heterogeneous device abstraction layer matches the corresponding adapter class based on the device type information. The command conversion logic implemented within the adapter class dynamically converts standardized instructions into configuration command strings or protocol data units that the device to be configured can natively recognize, i.e., native execution instructions. After the conversion is completed, the configuration execution agent sends the native execution instructions to the management interface of the device to be configured through a network management protocol (such as command line interface protocol, simple network management protocol, or representational state transfer protocol), completing the configuration instruction distribution operation.

[0125] Since the conversion logic for each device type is isolated in its own independent adapter class, when adding a new device type, it is only necessary to add a new adapter class in the heterogeneous device abstraction layer and implement the unified interface. There is no need to modify any code of the configuration execution agent or the upper-level process, which realizes the openness of the system to device type extension. At the same time, since the configuration execution agent only interacts with the adapter class through the unified interface, it does not need to pay attention to the specific implementation differences of the underlying adapter classes. This completely decouples the upper-level process from the differences of the underlying devices, further reducing the maintenance complexity of the system.

[0126] In one feasible implementation, the target adapter class includes a protocol adapter class, and the method of converting the standardized instructions in the target configuration task into native execution instructions adapted to the device to be configured through the unified device abstraction interface implemented in the target adapter class can be as follows: Obtain the device capability information and device version information of the device to be configured; based on the device capability information and device version information, determine the target management protocol and target command syntax version supported by the device to be configured; through the unified device abstraction interface implemented in the protocol adapter class, adapt the standardized instructions in the target configuration task into protocol data units conforming to the target management protocol format according to the target management protocol; through the command converter in the heterogeneous device abstraction encapsulation layer, match the target command template from the preset command template library according to the target command syntax version, and dynamically convert the standardized instructions into native execution instructions adapted to the device to be configured through the target command template.

[0127] Optionally, when the configuration execution agent calls the protocol adapter class through the unified device abstraction interface to perform instruction conversion, it first sends a probe request to the device to be configured through the device capability detection component to obtain the device capability information and device version information of the device.

[0128] The protocol adapter class parses the list of management protocols supported by the device from the device capability information, and combines it with the device version information to determine the target management protocol to be used in this communication (e.g., when the device supports multiple protocols at the same time, the protocol with the highest priority is selected according to the preset protocol priority order). At the same time, it parses the operating system version number of the device from the device version information to determine the corresponding target command syntax version.

[0129] After the target management protocol is determined, the protocol adapter class calls the adaptation method in the unified device abstraction interface it implements to encapsulate the standardized instructions according to the data format requirements of the target management protocol, generating a protocol data unit that conforms to the protocol format specification. This protocol data unit can be directly sent to the device to be configured through the corresponding protocol stack.

[0130] The command converter in the heterogeneous device abstraction and encapsulation layer matches the target command syntax version in a preset command template library to find the target command template that corresponds to the current device type and syntax version. Then, the operation type and parameter value in the standardized instruction are filled into the corresponding placeholder position of the template using the target command template, and the native execution instruction in the form of a command string that is natively recognized by the device is dynamically generated.

[0131] Because the protocol adapter class can dynamically select the most suitable communication protocol based on the capability information reported by the device in real time, and automatically select the best protocol according to priority when the device supports multiple protocols, the system can adapt to the protocol preferences of different devices and avoid communication failures caused by protocol incompatibility. At the same time, since protocol adaptation and command conversion are separated into two independent processing stages, when the device only needs to change the management protocol and the command syntax remains unchanged, only the protocol adaptation part needs to be adjusted. Conversely, when the device upgrades the software version and the command syntax changes, only the corresponding template in the command template library needs to be updated. The two do not affect each other, reducing the coupling of system maintenance.

[0132] In one feasible implementation, when there are multiple devices to be configured, before the step of sending the native execution command to the devices to be configured, the following may also be done: A preparation request is sent to the device to be configured, the preparation request being used to detect whether each device to be configured has the conditions for configuration execution; a preparation response is received from each device to be configured; if all the preparation responses indicate that the conditions for configuration execution are met, the native execution instruction is allowed to be issued; if any of the preparation responses indicate that the conditions for configuration execution are not met, a rollback instruction is sent to the device to be configured that has been successfully prepared to cancel the current configuration change.

[0133] Optionally, when the configuration change involves multiple devices to be configured, the consistency guarantee engine sends a preparation request to all devices to be configured concurrently. The preparation request requires each device to check whether its current state meets the conditions for performing the configuration change, including at least whether the device management interface is reachable, whether it is in an idle state and not occupied by other configuration tasks, and whether system resources are sufficient.

[0134] After receiving the preparation request, each device to be configured makes a judgment based on its current status and encapsulates the judgment result into a preparation response and returns it to the consistency guarantee engine.

[0135] After receiving and aggregating the preparation responses returned by all devices to be configured, the consistency assurance engine makes a comprehensive judgment on all responses: If the preparation responses of all devices to be configured indicate that the configuration execution conditions are met, the consistency assurance engine returns an instruction that allows the issuance of the instruction to the configuration execution agent, which then issues the native execution instruction to each device to be configured for execution; if any device to be configured indicates that the preparation response does not meet the configuration execution conditions, the consistency assurance engine immediately determines that the configuration change as a whole does not meet the execution conditions, does not issue a native execution instruction to any device, but instead sends a rollback instruction to all devices to be configured that have returned that the configuration execution conditions are met, releases the temporary resources that these devices may have occupied during the preparation phase, keeps all devices in the state before the configuration change, and cancels the entire configuration change.

[0136] Since the native execution command is only allowed to be issued after all devices to be configured have confirmed that they meet the execution conditions, it avoids the intermediate state in traditional solutions where some devices are configured successfully while others fail due to some devices being unreachable, resources being insufficient, or being occupied. This ensures the atomicity of configuration changes from the execution entry point in multi-device configuration scenarios. At the same time, since a rollback command is sent to the devices that are ready to succeed in advance when any device does not meet the conditions, the occupied device resources can be released in a timely manner when a failure occurs, avoiding long-term invalid occupation of resources and improving the system's resource utilization efficiency and fault recovery capability.

[0137] The above descriptions are merely some embodiments of this application and do not limit the scope of protection of this application. Any equivalent structural transformations made based on the technical concept of this application and the content of this specification and drawings, or direct / indirect applications in other related technical fields, are included within the scope of protection of this application. All actions involving the acquisition of signals, information, or data in this application are performed in accordance with the relevant data protection laws and policies of the country where the application is located and with authorization from the owner of the corresponding device.

Claims

1. A device configuration method, characterized in that, The device configuration method includes: Upon receiving a configuration change request, the system converts the configuration change request into a structured standard configuration data object based on a preset standardized configuration model. Based on the standard configuration data object, analyze the scope of impact of the configuration change and output a configuration change plan; The configuration change plan is decomposed into multiple configuration tasks, and each configuration task is added to a message queue to decouple each configuration task from the device side asynchronously. The target configuration task is obtained from the message queue. Based on the type of the device to be configured, the standardized instructions in the target configuration task are converted into native execution instructions adapted to the device to be configured, and the native execution instructions are sent to the device to be configured.

2. The device configuration method as described in claim 1, characterized in that, After the step of converting the configuration change request into a structured standard configuration data object according to the preset standardized configuration model, the method further includes: The standard configuration data object is updated to the preset configuration database as the target configuration state. The preset configuration database is independent of the running device to be configured. The preset configuration database is used to store the target configuration state of the device to be configured. The target configuration state is separate from the actual running configuration state of the device to be configured. The steps of analyzing the impact scope of configuration changes and outputting a configuration change plan based on the standard configuration data object include: Based on the standard configuration data object, analyze the scope of impact of the configuration changes; Based on the scope of impact and the updated configuration status in the preset configuration database, a configuration change plan is output.

3. The device configuration method as described in claim 1, characterized in that, The step of analyzing the impact scope of configuration changes and outputting a configuration change plan based on the standard configuration data object further includes: Based on the device identification information in the standard configuration data object, determine the devices to be configured that are associated with this configuration change and generate a list of devices to be configured; Based on the connection relationships between the devices to be configured in the list of devices to be configured, and the dependencies between the configuration parameters corresponding to each device to be configured, the task distribution order of each device to be configured is determined. A configuration change plan is generated based on the list of devices to be configured and the order in which the tasks are issued.

4. The device configuration method as described in claim 3, characterized in that, After updating the standard configuration data object to the preset configuration database as the target configuration state, the method further includes: Each configuration task is encapsulated into a configuration transaction, and a transaction identifier is assigned to the configuration transaction. After the step of sending the native execution command to the device to be configured, the method further includes: The final execution results of all configuration tasks in the configuration transaction are summarized and determined based on the transaction identifier. If all configuration tasks are executed successfully, the configuration snapshot of this configuration change is stored in the version history of the preset configuration database. If any configuration task fails to execute, the configuration transaction is rolled back, so that the device to be configured is restored to the configuration state before this configuration change.

5. The device configuration method as described in claim 1, characterized in that, The step of adding each of the configuration tasks to the message queue includes: Each of the configuration tasks is published to the topic corresponding to the configuration change plan in the message queue; The step of retrieving the target configuration task from the message queue includes: Multiple configuration execution agents subscribe to the topic and pull the corresponding target configuration tasks from the topic in a concurrent consumer mode to achieve parallel execution of configuration tasks.

6. The device configuration method as described in claim 1, characterized in that, The step of adding each of the configuration tasks to the message queue further includes: Obtain the complexity and urgency levels of this configuration change; Based on the complexity level and urgency level, a target scheduling strategy is determined from a variety of preset scheduling strategies; According to the target scheduling strategy, each of the configured tasks is added to the message queue, wherein the multiple preset scheduling strategies include concurrent scheduling strategy, sequential scheduling strategy and batch scheduling strategy.

7. The device configuration method as described in claim 1, characterized in that, The step of converting standardized instructions in the target configuration task into native execution instructions adapted to the device to be configured, based on the type of the device to be configured, includes: Based on the type of the device to be configured, a corresponding target adapter class is matched from the heterogeneous device abstraction layer. The heterogeneous device abstraction layer has pre-defined adapter classes corresponding to various device types. Each adapter class implements the unified device abstraction interface. Each adapter class is used to convert standardized operations into specific operations of the corresponding manufacturer's device. The standardized instructions in the target configuration task are converted into native execution instructions adapted to the device to be configured by using the unified device abstraction interface implemented in the target adapter class.

8. The device configuration method as described in claim 7, characterized in that, The target adapter class includes a protocol adapter class. The step of converting the standardized instructions in the target configuration task into native execution instructions adapted to the device to be configured through the unified device abstraction interface implemented in the target adapter class includes: Obtain the device capability information and device version information of the device to be configured; Based on the device capability information and the device version information, determine the target management protocol and target command syntax version supported by the device to be configured; Through the unified device abstraction interface implemented in the protocol adapter class, the standardized instructions in the target configuration task are adapted into protocol data units that conform to the target management protocol format according to the target management protocol; The command converter in the heterogeneous device abstraction and encapsulation layer matches the target command template from the preset command template library according to the target command syntax version, and dynamically converts the standardized instructions into native execution instructions adapted to the device to be configured through the target command template.

9. The device configuration method as described in claim 1, characterized in that, When there are multiple devices to be configured, before the step of sending the native execution command to the devices to be configured, the method further includes: Send a preparation request to the device to be configured, the preparation request being used to detect whether each of the devices to be configured has the conditions for configuration execution; Receive the preparation response returned by each of the devices to be configured; If all the prepared responses indicate that the conditions for configuration execution are met, the native execution command may be issued; If any of the prepared response indications does not meet the conditions for configuration execution, a rollback command is sent to the device to be configured that has been successfully prepared to cancel the configuration change.

10. The device configuration method as described in claim 1, characterized in that, Before the step of analyzing the impact scope of the configuration change based on the standard configuration data object and outputting the configuration change plan, the following steps are also included: The standard configuration data object is pre-verified; wherein the pre-verification includes at least one of the following: performing compliance verification on the configuration instruction format and configuration parameter value range in the standard configuration data object, performing consistency verification on the logical dependency relationship between configuration parameters in the standard configuration data object, retrieving the current existing configuration data from the preset configuration database, comparing the configuration parameter fields in the standard configuration data object with the existing configuration data, and detecting whether there are Internet Protocol address conflicts and / or routing policy conflicts. If the pre-verification fails, the configuration change process will be terminated and an error feedback message will be output.

Images