A method and system for lightweight network deployment and configuration for extended sites

Abstract

The present application relates to the field of communication network, especially to a lightweight network deployment and configuration method and system for extended sites, real-time resource index information of the extended site is collected, the information at least includes network bandwidth, free memory and CPU utilization; the resource adequacy is evaluated according to the collected information, whether the preset deployment condition is satisfied is judged; if satisfied, the complete deployment mode is executed, and the complete containerized network function image is deployed; if not satisfied, the lightweight deployment mode is executed, and the image is deployed after component cutting; after the deployment is completed, the target configuration strategy is obtained, the heterogeneous network equipment is analyzed and the management interface type is identified; the current running configuration of each equipment is obtained, and the difference configuration is generated by difference comparison with the target configuration strategy; according to the identified management interface type, the difference configuration is converted into the configuration command executable by the original equipment and is pushed to the corresponding equipment. The present application realizes the resource adaptive deployment and the intelligent configuration of heterogeneous equipment synchronization.

Description

Technical Field

[0001] This application relates to the field of communication network technology, and in particular to a lightweight network deployment and configuration method and system for extended sites. Background Technology

[0002] In expanded environments, such as temporary event sites and emergency communication points, existing automation solutions typically assume that the target environment has relatively stable and abundant resources when deploying network functions. However, in real-world scenarios, resources such as bandwidth, memory, and CPU often fluctuate dynamically and are often under strain. Existing solutions struggle to detect these real-time changes and cannot adjust deployment strategies based on resource conditions. This leads to deployment failures when resources are scarce, and a lack of mechanisms to proactively restore full functionality when resources are plentiful. This one-size-fits-all deployment approach is ill-suited for resource-constrained edge computing scenarios.

[0003] On the other hand, extended sites often use network devices from different vendors and generations, with significant differences in their management interfaces and configuration syntax. Existing configuration management tools commonly suffer from two easily overlooked problems when issuing unified policies to these heterogeneous devices: first, a lack of differentiation regarding the risk differences of different configuration items; and second, a lack of effective constraints on the execution order of configuration commands between devices or within the same device. In practice, configuration push failures or incorrect ordering occur frequently, and when some succeeds and others fail, existing solutions often struggle to restore the devices to a consistent state. These problems are not prominent in highly standardized data center environments, but they are easily amplified in temporary extended sites. Summary of the Invention

[0004] To address one or more problems in the prior art, the main objective of this application is to provide a lightweight network deployment and configuration method and system for expanding the site.

[0005] To achieve the aforementioned objectives, this application proposes a lightweight network deployment and configuration method for extended sites, the method comprising: Collect real-time resource indicator information for the expanded site, including at least network bandwidth, free memory, and CPU utilization. Based on the real-time resource indicator information, assess the resource sufficiency of the current expansion site; Based on the assessment results of the resource sufficiency, determine whether the resource sufficiency meets the preset deployment conditions; If the resource availability meets the preset deployment conditions, then execute the full deployment mode and deploy the complete containerized network function image; If the resource sufficiency does not meet the preset deployment conditions, a lightweight deployment mode is executed, and the containerized network function image is deployed after component trimming. After completing the deployment of the containerized network function image, obtain the target configuration policy, analyze the heterogeneous network devices in the extended site, and identify the management interface types of the heterogeneous network devices. Obtain the current operating configuration of each device, compare the current operating configuration of each device with the target configuration strategy, and generate a differential configuration. Based on the identified management interface type, the differential configuration is converted into a configuration command that is natively executable by the corresponding device and pushed to the corresponding device.

[0006] This application also provides a lightweight network deployment and configuration system for extended sites, including: The acquisition module is used to collect real-time resource indicator information of the extended site. The real-time resource indicator information includes at least network bandwidth, free memory and CPU utilization. The evaluation module is used to evaluate the resource sufficiency of the current expanded site based on the real-time resource indicator information. The judgment module is used to determine whether the resource sufficiency meets the preset deployment conditions based on the assessment result of the resource sufficiency. The first execution module is used to execute the full deployment mode and deploy the complete containerized network function image if the resource availability meets the preset deployment conditions. The second execution module is used to execute a lightweight deployment mode if the resource sufficiency does not meet the preset deployment conditions, and to deploy the containerized network function image after component trimming. The acquisition module is used to acquire the target configuration policy after the containerized network function image is deployed, analyze the heterogeneous network devices in the extended site, and identify the management interface type of the heterogeneous network devices. The generation module is used to obtain the current operating configuration of each device, compare the current operating configuration of each device with the target configuration strategy, and generate a difference configuration. The push module is used to convert the differential configuration into a configuration command that is natively executable by the corresponding device according to the identified management interface type, and push it to the corresponding device.

[0007] This application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods described above.

[0008] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the methods described above.

[0009] The lightweight network deployment and configuration method and system for extended sites in this application embodiment decomposes the entire process into two consecutive stages: resource awareness and adaptive deployment, and heterogeneous device discovery and differentiated configuration. Each stage employs targeted technical means, transforming the automated network management of extended sites from a traditional static, single-mode approach to a dynamic, adaptive one. The resource awareness and weight evaluation mechanism allows deployment decisions to adjust according to environmental changes, while lightweight pruning ensures successful deployment of images even under resource constraints. The combination of device discovery, interface identification, difference comparison, and protocol conversion makes the configuration synchronization process for heterogeneous devices more reliable and efficient. Overall, this method improves the success rate and automation level of network deployment and configuration in temporary, resource-constrained, and mixed-device extended sites. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating a lightweight network deployment and configuration method for an extended site according to an embodiment of this application. Figure 2 This is a flowchart illustrating a lightweight network deployment and configuration method for an extended site according to an embodiment of this application. Figure 3 This is a schematic block diagram of a lightweight network deployment and configuration system for extended sites according to an embodiment of this application. Figure 4 This is a schematic block diagram of the structure of a computer device according to an embodiment of this application.

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

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0013] Reference Figure 1 This application provides a lightweight network deployment and configuration method for extended sites, the method comprising: S1. Collect real-time resource indicator information of the extended site, wherein the real-time resource indicator information includes at least network bandwidth, free memory and CPU utilization. S2. Based on the real-time resource indicator information, assess the resource sufficiency of the current expanded site; S3. Based on the assessment results of the resource sufficiency, determine whether the resource sufficiency meets the preset deployment conditions; S4. If the resource availability meets the preset deployment conditions, then execute the full deployment mode and deploy the complete containerized network function image. S5. If the resource sufficiency does not meet the preset deployment conditions, then execute the lightweight deployment mode and deploy the containerized network function image after component trimming. S6. After completing the deployment of the containerized network function image, obtain the target configuration policy, analyze the heterogeneous network devices in the extended site, and identify the management interface type of the heterogeneous network devices. S7. Obtain the current operating configuration of each device, compare the current operating configuration of each device with the target configuration strategy, and generate a difference configuration. S8. Based on the identified management interface type, convert the differential configuration into a configuration command that is natively executable by the corresponding device, and push it to the corresponding device.

[0014] As described in steps S1-S5 above, let's first take a typical extended site scenario as an example. For instance, a temporary exhibition center needs to quickly set up a network system, including a virtual firewall and several switches from different vendors. The execution process of this method in this scenario is as follows: First, collect real-time resource metrics information of the extended site. In practice, a lightweight agent can be deployed within the site. This agent continuously monitors the current environment's network bandwidth, free memory, and CPU utilization. These three metrics are collected because network bandwidth determines the speed of container image download or transmission, free memory determines whether containers can start and run smoothly, and CPU utilization reflects the current scarcity of computing resources. Together, they constitute the basic data for assessing whether the environment is "sufficient." For example, a collection might yield available bandwidth of 85 megabits per second, free memory of 1500 megabytes, and CPU utilization of 25%. Second, assess the resource sufficiency of the current extended site based on the collected resource metrics information. The core logic of this step is to comprehensively judge the above three metrics. This can be understood as follows: higher bandwidth and more memory are more beneficial for deployment; while higher CPU utilization means a heavier existing load, and deploying new features may exacerbate resource contention. Therefore, in the evaluation, bandwidth and memory are given a positive effect, while CPU utilization is given a negative effect. A weighted calculation yields a quantified score, with a higher score indicating that the current environment is more suitable for deploying the full functionality. The third step is to determine whether the preset deployment conditions are met based on the evaluation results. The preset conditions are essentially a threshold, for example, setting a score above a certain value to consider resources sufficient, otherwise considering resources strained. This threshold can be flexibly adjusted according to the actual scenario; for example, in temporary sites with frequent resource fluctuations, the threshold can be appropriately lowered to allow for a more lightweight mode in more cases. The fourth step is to execute different deployment modes based on the judgment results. If resources are sufficient, the full deployment mode is executed, directly deploying the complete containerized network function image to the environment. If resources are strained, the lightweight deployment mode is executed, which requires component trimming of the original image. The trimming is based on the image's own metadata, which defines which are core components and which are non-core additional components. For example, a virtual firewall image might include modules such as data forwarding, logging, and advanced monitoring. When resources are limited, logging and advanced monitoring can be temporarily removed, retaining only the core data forwarding function. This results in a smaller, more resource-intensive image for deployment. Through this adaptive mechanism, this method can significantly improve deployment success rates in resource-constrained environments, while avoiding prolonged blocking or failures due to insufficient resources.

[0015] As described in steps S6-S8 above, after deploying the containerized network function, it is also necessary to configure the heterogeneous network devices in the site to enable them to work together with the newly deployed network function. The fifth step is to obtain the target configuration policy and analyze the heterogeneous network devices in the site to identify the management interface type of each device. The target configuration policy is a unified configuration intent predefined by the operations and maintenance personnel, such as requiring all access switches to enable port security. Then, the system discovers devices in the network through active probing or passive listening. For each device, its management interface type is further identified; for example, a new switch supports the NETCONF interface, an older switch only supports the command-line interface, and another device supports the REST interface. The purpose of this step is to prepare for subsequent protocol adaptation. The sixth step is to obtain the current running configuration of each device and compare it with the target configuration policy to generate a differential configuration. The differential comparison involves comparing the device's existing configuration with the desired target state to identify areas that need modification. For example, if a switch currently does not have port security enabled, but the target policy requires it to be enabled, then the differential configuration will include enabling port security. The advantage of this approach is that it avoids full-scale configuration overhaul, only pushing the parts that truly need to be changed, thus minimizing the impact on the devices. The seventh step involves converting the differential configuration into configuration commands natively executable by the corresponding device, based on the identified management interface type, and then pushing these commands to the corresponding device. Since different devices have different interface protocols and command syntaxes, this method selects a corresponding adapter for each interface type. For example, for devices that support NETCONF, the differential configuration is encapsulated into NETCONF protocol messages; for older devices that only support command lines, specific command-line instructions, such as commands to enable port security, are generated through an adapter. After conversion, the commands are pushed to the device for execution.

[0016] As mentioned above, this method is designed this way because existing technologies generally have two shortcomings in extended site scenarios. The first shortcoming is the lack of real-time resource awareness during the deployment phase. This leads to deployment failures due to insufficient resources or unnecessary resource waste when using fixed-size images in environments with low bandwidth, limited memory, or heavy CPU usage. The second shortcoming is the lack of a unified adaptation mechanism for heterogeneous devices during the configuration phase. When facing devices from different manufacturers and with different interface types, maintenance personnel often need to manually write multiple scripts, and problems such as incorrect ordering and partial failures during the configuration process are difficult to automate. This invention breaks down the entire process into two consecutive phases: resource awareness and adaptive deployment, and heterogeneous device discovery and differentiated configuration. Each phase employs targeted technical means, transforming the automated network management of extended sites from a traditional static, single-mode approach to a dynamic, adaptive one. The resource awareness and weight evaluation mechanism allows deployment decisions to adjust according to environmental changes, while lightweight pruning ensures successful image deployment even under resource constraints. The combination of device discovery, interface identification, difference comparison, and protocol conversion makes the configuration synchronization process for heterogeneous devices more reliable and efficient. Overall, this approach improves the success rate and automation of network deployment and configuration in temporary, resource-constrained, and mixed-equipment extended environments.

[0017] In one embodiment, assessing the resource sufficiency of the current expanded site includes: The collected network bandwidth, free memory, and CPU utilization are weighted using preset weighting coefficients to obtain a resource sufficiency score, wherein the weighting coefficients for network bandwidth and free memory are positive, and the weighting coefficient for CPU utilization is negative; the higher the resource sufficiency score, the higher the resource sufficiency of the current expansion site.

[0018] As mentioned above, bandwidth and memory have a positive promoting effect on deployment, while CPU utilization has a negative inhibiting effect. Therefore, during computation, positive weighting coefficients are assigned to bandwidth and memory, and negative weighting coefficients are assigned to CPU utilization. In practice, baseline bandwidth and memory requirements can be preset. For example, a containerized network function image requires at least 100 megabits per second of bandwidth and 1024 megabytes of free memory to operate normally. Then, the actual bandwidth is divided by the baseline bandwidth to obtain a ratio; similarly, the actual free memory is divided by the baseline memory to obtain another ratio. These two ratios are multiplied by their respective positive weighting coefficients and then added together. On the other hand, the current CPU utilization is directly multiplied by a negative weighting coefficient and subtracted from the sum. The final result is the resource adequacy score. In this way, even if the numerical ranges and units of the three indicators are different, they can be unified into a single score. The higher the score, the closer the current environment is to or exceeds the baseline requirements, and the more abundant the resources; the lower the score, the more strained the resources, and the more necessary lightweight pruning is. For example, in a field deployment, the available bandwidth was 85 megabits per second, the idle memory was 1500 megabytes, and the CPU utilization was 25%. The baseline bandwidth was 100 megabits per second, and the baseline memory was 1024 megabytes. The positive weights for bandwidth and memory were set to 0.4, and the negative weight for CPU utilization was set to 0.2. The bandwidth ratio was 0.85, and the memory ratio was 1.465. After weighted summation and subtracting the CPU contribution, the result was approximately 0.876. This score is higher than the typically set threshold of 0.8, therefore it is considered resource-sufficient, and a full deployment is executed. If a data collection showed only 50 megabits per second bandwidth, only 800 megabytes of idle memory, and a CPU utilization as high as 60%, the score would be significantly lower than the threshold, triggering a lightweight deployment mode.

[0019] It's worth noting that existing technologies, when making deployment decisions, either consider only a single resource metric or employ simple AND / OR logic, lacking the ability to comprehensively weigh multiple resource metrics. For example, traditional solutions might set a threshold for both bandwidth and memory to be greater than a certain value before deployment, otherwise, an error message is displayed and the process terminates. This rigid judgment cannot handle situations where bandwidth is insufficient but memory is ample, nor can it quantify the degree of resource strain. Our proposed solution, however, through continuously adjustable weighting coefficients and linear weighted calculations, not only accurately reflects the overall sufficiency of resources but also provides a numerical basis for subsequent closed-loop optimization. If a low deployment success rate is detected, the weighting coefficients can be dynamically adjusted, for example, by appropriately reducing the negative weight of CPU utilization, making it easier for the deployment mode to trigger a full deployment. This flexibility is unmatched by traditional hard threshold judgments.

[0020] Reference Figure 2In one embodiment, the deployment of the containerized network function image after component trimming includes: S51. Obtain the metadata of the containerized network function image, wherein the metadata defines multiple microservice components and the dependency graph between the components; S52. Based on the dependency graph, a topological sorting algorithm is used to determine the set of non-core components; S53. Based on the determined set of non-core components, remove the set of non-core components to obtain the updated image; S54. Deploy the updated image.

[0021] As described above, the first step is to obtain the metadata of the containerized network function image. This metadata is not a simple list of components, but rather a clearly defined dependency graph between the various microservice components within the image. Essentially, the dependency graph describes whether a component depends on the functionality provided by another component at runtime. For example, a virtual firewall image might contain multiple components such as a data forwarding engine, a logging service, a traffic monitoring module, and a management interface. The logging service might depend on the interface provided by the data forwarding engine to collect traffic information, while the management interface might depend on the logging service to display historical logs. Arbitrarily removing a component that is depended upon by other components would cause those dependent components to malfunction or even become completely unusable. Therefore, simply pruning according to a pre-defined priority is insufficient, because priorities are static, while dependencies are dynamic; high-priority components might be depended upon by low-priority components. To address this issue, this embodiment introduces a topology sorting algorithm. Topology sorting is a sorting algorithm for directed acyclic graphs (DAGs) that arranges all nodes in the dependency graph into a linear sequence, ensuring that for each directed edge in the graph, the starting point appears before the ending point. In other words, if one component depends on another, the dependent component will be ranked ahead of the dependent components in the sorting results. Topological sorting clearly identifies which components are at the edge of the dependency graph. Specifically, after topological sorting, components that are not depended on by any other components, or those at the end of the dependency graph, are often non-core components that can be safely removed. This is because removing these components will not affect the normal operation of other components. For example, in the virtual firewall image mentioned above, topological sorting analysis might reveal that the traffic monitoring module only depends on the data forwarding engine and the logging service, but no other component depends on the traffic monitoring module. Therefore, the traffic monitoring module can be included in the non-core component set. Similarly, if a component is depended on by multiple other components, it is clearly a core component and cannot be removed. After determining the non-core component set, the next step is relatively straightforward: remove these components from the original image to obtain an updated image, and then deploy this updated image to the extended environment.

[0022] In one embodiment, the method further includes: Monitor the deployment status of the containerized network function image and the push results of the differential configuration, wherein the deployment status includes deployment success or deployment failure, and the push results include push success or push failure; Based on the monitored deployment status and push results, calculate the deployment success rate and configuration synchronization success rate within a preset historical time period; When the deployment success rate is lower than a preset first success rate threshold, the weighting coefficient of the CPU utilization is reduced. When the configuration synchronization success rate is lower than the preset second success rate threshold, the number of change items pushed in a single batch when the differential configuration is pushed to the corresponding device is reduced.

[0023] As described above, the aforementioned embodiments determined how to select full deployment or lightweight trimmed deployment based on real-time resource assessment results, and how to convert configuration differences into device-native commands and push them. However, the parameters upon which these decisions rely, such as the weighting coefficients of various indicators when assessing resource sufficiency, and the number of change items in a single batch when pushing configurations, may not be optimal when initially set. The environment of expanded sites is dynamically changing; parameters applicable today may no longer be suitable tomorrow. Therefore, a mechanism is needed to allow the system to learn from historical execution results and automatically adjust parameters to adapt to environmental changes. To address this issue, this solution adds a closed-loop monitoring and adaptive adjustment step in addition to the original deployment and configuration steps. Specifically, the system continuously monitors two key results: first, the deployment status of the containerized network function image, i.e., whether the deployment was successful or failed; and second, the push result of the differential configuration, i.e., whether the push was successful or failed. This monitoring data is recorded for subsequent statistical analysis. Based on the monitored data, the system will calculate the deployment success rate and configuration synchronization success rate within a preset historical time period. For example, it can calculate the success rate in the past 24 hours or the past 100 deployment attempts. The statistical time window can be flexibly set according to actual needs. A time window that is too short is easily affected by accidental factors, while a time window that is too long makes it difficult to respond to environmental changes in a timely manner. When the statistics show that the deployment success rate is lower than the preset first success rate threshold, it indicates that the current resource assessment mechanism may have a problem, leading to unreasonable deployment decisions. At this time, the system will automatically reduce the weight coefficient of CPU utilization. Why reduce the weight coefficient of CPU utilization? Because CPU utilization plays a negative role in resource assessment; that is, the higher the CPU utilization, the lower the resource sufficiency score, and the more the system tends to adopt a lightweight deployment mode. If the deployment success rate is low, one possible reason is that even when resources are not scarce, the score is low due to instantaneous CPU fluctuations, and the system incorrectly chooses lightweight deployment. The image after lightweight deployment may not work properly because it is missing some components. Reducing the weight coefficient of CPU utilization will weaken the impact of CPU utilization on the final score, and the system will be more inclined to judge that resources are sufficient, thus adopting a full deployment mode more often and improving the deployment success rate. Similarly, when the statistics show that the configuration synchronization success rate is lower than the preset second success rate threshold, it indicates that the current configuration push mechanism may need optimization. A common cause of configuration synchronization failures is pushing too many changes in a single batch, leading to insufficient processing time on devices or network congestion. In such cases, the system automatically reduces the number of changes pushed in a single batch. Reducing the batch size means fewer configuration commands are pushed each time, less processing pressure on devices, and a naturally higher probability of successful push. Although this increases the number of push batches and prolongs the overall synchronization time, this trade-off is acceptable in reliability-prioritized extended site scenarios.

[0024] In one embodiment, the step of pushing to the corresponding device includes: Identify the configuration item type corresponding to each change item in the differential configuration; Based on the identification results, the risk level of each change item is determined according to the preset risk level mapping table. The risk level is positively correlated with the impact range of the configuration item. The interface configuration is set to the first risk level, and the routing protocol configuration is set to the second risk level, which is higher than the first risk level. For changes with a risk level lower than the preset risk threshold, the changes are pushed directly to the corresponding devices. For changes with a risk level higher than or equal to a preset risk threshold, first start a sandbox simulation environment, simulate the execution of the changes in the sandbox, and push them to the corresponding device after verification. The sandbox simulation environment replicates a portion of the operating state of the corresponding device and automatically rolls back after the simulation is executed.

[0025] As mentioned above, the system identifies the configuration item type corresponding to each change in the differential configuration. The configuration item type can be parsed from the change content. For example, if a change command involves modifying the attributes of a switch port, it is an interface configuration; if it involves modifying parameters related to a routing protocol, it is a routing protocol configuration. Different types of configuration items have significantly different impacts on the network. Based on the identified type, the system queries a preset risk level mapping table to determine the risk level of each change item. The core principle of this mapping table is that the risk level is positively correlated with the scope of influence of the configuration item. The wider the scope of influence of a configuration item, the higher its risk level. As a specific example, interface configuration usually only affects a single port and belongs to a lower risk level; routing protocol configuration may affect the routing tables of the entire device and even adjacent devices, with a wider scope of influence, and therefore belongs to a higher risk level. This level classification is not arbitrarily set, but is based on network operation and maintenance engineering experience, reflecting the degree of loss that different types of configuration errors may cause. After determining the risk level, the system compares it with a preset risk threshold. For change items with a risk level below this threshold, the system considers their impact to be limited, and even if an error occurs, it will not cause serious consequences, so it can be directly pushed to the corresponding device. For changes with a risk level equal to or higher than the threshold, the system adopts a more cautious strategy: first, a sandbox simulation environment is started, and the change is simulated and executed within the sandbox. Only after successful verification is it pushed to the corresponding device. The implementation of the sandbox simulation environment is a crucial detail of this solution. It does not simulate the entire functionality of the device, but rather replicates a portion of the device's operational state, primarily the configuration and status information related to the change to be verified. This approach offers advantages such as low resource overhead, fast startup speed, and suitability for expansion sites with limited resources. After executing the change in the sandbox, the system observes the execution results for normality and the presence of errors or anomalies. If verification passes, it indicates a high probability of successful execution on the actual device, at which point it is pushed to the real device. If verification fails, it indicates a problem with the change, and the system can refuse to push it and generate an alarm, awaiting manual intervention or automatically skipping it. Simultaneously, the sandbox simulation environment automatically rolls back after verification, restoring to the state before simulation, ensuring that each verification begins in a clean environment and avoiding interference between multiple verifications.

[0026] In one embodiment, the step of pushing to the corresponding device further includes: Obtain the configuration dependencies between the heterogeneous network devices, wherein the configuration dependencies include at least one of resource dependencies, sequence dependencies, or mutual exclusion dependencies; Based on the configuration dependencies, construct a configuration dependency graph with configuration items as nodes and dependencies as directed edges; The configuration dependency graph is sorted using a topological sorting algorithm to obtain the push order of configuration items; Based on the order in which the configuration items are pushed, each configuration item is pushed to the corresponding heterogeneous network device in sequence according to the order. Based on the push results, if any configuration item fails to be pushed, subsequent pushes are stopped, and a rollback command is sent to the devices that have been successfully pushed in the reverse order of the push, so that the configuration of the devices can be restored to the state before the push.

[0027] As mentioned above, the configuration dependencies between heterogeneous network devices need to be obtained. Such dependencies are common in extended environments, and common types include resource dependencies, sequential dependencies, and mutual exclusion dependencies. Resource dependencies refer to a configuration item on one device requiring a configuration item on another device as a prerequisite. For example, after creating a virtual LAN on a core switch, an access switch can then configure that LAN on its ports. If the access switch is configured first and then the LAN is created, the access switch's configuration will fail because the corresponding LAN cannot be found. Sequential dependencies refer to configuration items that must be executed in a fixed order; for example, the neighbor relationship of a routing protocol must be configured before a routing policy can be configured. Mutually exclusive dependencies refer to two configuration items that cannot exist simultaneously; for example, enabling a certain security mode requires disabling another conflicting mode. After obtaining these dependencies, they need to be transformed into computable structured data. Specifically, a configuration dependency graph is constructed, where each independent configuration item is a node, and the dependencies are directed edges. If configuration item A depends on configuration item B, then an arrow is drawn from B to A, indicating that B must be completed before A. The resulting graph is a directed graph, which may contain multiple paths. Next, a topological sorting algorithm is used to sort this configuration dependency graph. Topological sorting is a classic algorithm in graph theory that arranges all nodes in the graph into a linear sequence, ensuring that for every directed edge, the starting point precedes the ending point. In other words, if configuration item B must be executed before configuration item A, then in the sorting result, B will always appear before A. The result of topological sorting is the push order of the configuration items, which naturally satisfies all dependencies and prevents configuration failures due to incorrect order. After obtaining the push order, each configuration item is pushed to its corresponding heterogeneous network device in this order. Since the order is guaranteed by dependency analysis, the preconditions that each configuration item depends on are theoretically satisfied when it is pushed, greatly increasing the probability of successful configuration. However, even with the correct order, a configuration item may still fail to push due to network failures, temporary device malfunctions, insufficient permissions, etc. Simply recording the failure and continuing with subsequent pushes would result in an inconsistent state where some devices are configured successfully while others fail. Such inconsistencies are often more difficult to handle than total failures because successfully configured parts may have altered the network environment, making subsequent recovery operations more complex. To address this, this solution introduces an atomic rollback mechanism. Specifically, if any configuration item fails during the push process, the system immediately aborts all subsequent pushes and ceases further attempts. Then, the system sends rollback commands to the devices that have already been successfully pushed, in the reverse order of the push sequence. This reverse order is because the push order ensures dependencies; earlier configuration items are often the foundation upon which other configuration items depend.If the rollback is performed in reverse order, the configuration items executed later will be rolled back first, followed by those executed earlier, thus avoiding further violation of dependencies during the rollback process. For example, if a virtual LAN was created first, and then the access switch port was configured, the port configuration should be revoked first, followed by the deletion of the virtual LAN. The purpose of the rollback command is to restore the device configuration to its state before the push began, ensuring that the entire configuration operation either succeeds completely or fails completely, without any intermediate states.

[0028] In one embodiment, the step of pushing to the corresponding device further includes: For each heterogeneous network device, obtain the internal dependencies of each change item in the differential configuration corresponding to the heterogeneous network device. The internal dependencies define the execution order constraints between different configuration items on the same device. Based on the internal dependencies, the differential configurations of the heterogeneous network devices are sorted topologically to obtain the configuration push sub-order within the heterogeneous network devices; According to the configuration push sub-order, adjust the relative order of each configuration item belonging to the heterogeneous network device in the push order, so that each change item of the heterogeneous network device is arranged in sequence according to the internal dependency relationship; Based on the results, each configuration item is pushed to the corresponding heterogeneous network device in the adjusted push order.

[0029] As mentioned above, each heterogeneous network device needs to be analyzed individually first. Specifically, the system will obtain the internal dependencies of each change item in the differential configuration corresponding to that device. Internal dependencies refer to the execution order constraints between different configuration items on the same device. These constraints usually come from the command-line specifications or inherent requirements of the device's operating system or configuration model. For example, when configuring port security on a switch, port security must be enabled globally first, and then the maximum number of learning addresses can be set on a specific interface. If the order is reversed, the switch may reject the second command. Another example is configuring a Virtual LAN (VLAN). The VLAN must be created and assigned a number first, then the VLAN name can be configured, and finally the interface can be added to the VLAN. If the creation step is skipped and the name is configured directly, the device will report an error because it cannot find the corresponding VLAN. Yet another example is configuring an Access Control List (ACL). The ACL rules must be defined first, and then the list can be applied to the interface. These are typical examples of device internal dependencies. After obtaining the internal dependencies, the system needs to perform topology sorting for the differential configuration of this device itself. Similar to handling inter-device dependencies, the system constructs an internal dependency subgraph, using each configuration item on the device as a node and internal dependencies as directed edges. A topological sorting algorithm is then used to obtain a linear sequence. This sequence represents the configuration push sub-order within the device, ensuring that all configuration items on that device are arranged according to their dependencies, with dependent configuration items always preceding those that depend on them. However, simply obtaining the sub-order within each device is insufficient, as the cross-device push order has already been determined. Directly replacing the device-specific portion of the original cross-device order with the device-specific sub-order might violate cross-device dependencies. For example, device A's internal order might require configuration item A1 to execute before A2, while the cross-device order might require A2 to execute before B1. Simply overwriting with the internal order could result in A1 being placed after B1, violating cross-device dependencies. Therefore, it is necessary to integrate the device-specific sub-order with the original cross-device push order. The specific approach to integration is as follows: while maintaining the overall framework of the cross-device push order, for each device, the relative positions of its original configuration items in the push order are rearranged according to the sub-order within that device. In other words, configuration items A1 and A2 of device A, which might have been scattered in different positions in the push order, will be arranged adjacently according to their internal dependencies after integration. However, the overall order of these configuration items with configuration items of other devices still follows the original cross-device order. This satisfies the internal order constraints of each device without disrupting the dependencies between devices. After obtaining the adjusted push order, the system pushes each configuration item to the corresponding heterogeneous network devices in this order.In actual execution, configuration commands on each device will arrive at the device in the correct order according to the internal dependencies, thereby minimizing configuration failures caused by incorrect order.

[0030] It's worth noting that existing technologies, when handling multi-device configuration, often only focus on batch operations at the device level. They assume that the device itself can correctly receive and process commands in any order, or rely on the device's own configuration engine to resolve dependencies. However, many older devices or command-line interface devices lack this capability; they strictly adhere to the command reception order, and will directly report an error if the order is incorrect. While maintenance personnel typically follow an experienced sequence when manually configuring, this implicit sequence knowledge is often not encoded into automated systems, leading to frequent failures of automated scripts on older devices. This solution explicitly defines internal device dependencies and predefines internal dependency templates for each device type, enabling the automated system to issue configuration commands in the correct order, just like experienced maintenance personnel. Simultaneously, by integrating a cross-device dependency ordering algorithm, it ensures that two different levels of dependencies can coexist without conflict. This layered dependency handling approach extends from inter-device dependencies to internal device dependencies, forming a complete, multi-layered configuration order guarantee mechanism, improving the success rate and reliability of configuration synchronization in heterogeneous device environments.

[0031] Reference Figure 3 This application also provides a lightweight network deployment and configuration system for extended sites, including: The acquisition module 1 is used to acquire real-time resource indicator information of the extended site. The real-time resource indicator information includes at least network bandwidth, free memory and CPU utilization. Evaluation module 2 is used to evaluate the resource sufficiency of the current expanded site based on the real-time resource indicator information. The judgment module 3 is used to determine whether the resource sufficiency meets the preset deployment conditions based on the assessment result of the resource sufficiency. The first execution module 4 is used to execute the full deployment mode and deploy the complete containerized network function image if the resource sufficiency meets the preset deployment conditions. The second execution module 5 is used to execute a lightweight deployment mode if the resource sufficiency does not meet the preset deployment conditions, and to deploy the containerized network function image after component trimming. Module 6 is used to obtain the target configuration policy after the containerized network function image is deployed, analyze the heterogeneous network devices in the extended site, and identify the management interface type of the heterogeneous network devices. Generation module 7 is used to obtain the current running configuration of each device, compare the current running configuration of each device with the target configuration strategy, and generate a difference configuration. The push module 8 is used to convert the differential configuration into a configuration command that is natively executable by the corresponding device according to the identified management interface type, and push it to the corresponding device.

[0032] As described above, it is understood that each component of the lightweight network deployment and configuration system for extended sites proposed in this application can realize the function of any of the lightweight network deployment and configuration methods for extended sites as described above, and the specific structure will not be repeated.

[0033] Reference Figure 4 This application also provides a computer device, which may be a server, and its internal structure may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data such as monitoring data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements a lightweight network deployment and configuration method for expanding the operational space.

[0034] The processor described above executes the lightweight network deployment and configuration method for the extended site, including: collecting real-time resource indicator information of the extended site, the real-time resource indicator information including at least network bandwidth, idle memory, and CPU utilization; evaluating the resource sufficiency of the current extended site based on the real-time resource indicator information; determining whether the resource sufficiency meets the preset deployment conditions based on the evaluation result of the resource sufficiency; if the resource sufficiency meets the preset deployment conditions, executing the full deployment mode to deploy the complete containerized network function image; if the resource sufficiency does not meet the preset deployment conditions, executing the lightweight deployment mode to deploy the containerized network function image after component trimming; after completing the deployment of the containerized network function image, obtaining the target configuration policy, analyzing the heterogeneous network devices in the extended site, and identifying the management interface types of the heterogeneous network devices; obtaining the current running configuration of each device, comparing the current running configuration of each device with the target configuration policy to generate a differential configuration; and converting the differential configuration into a configuration command natively executable by the corresponding device according to the identified management interface type, and pushing it to the corresponding device.

[0035] One embodiment of this application also provides a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements a lightweight network deployment and configuration method for an extended site, comprising the steps of: collecting real-time resource indicator information of the extended site, the real-time resource indicator information including at least network bandwidth, free memory, and CPU utilization; assessing the resource sufficiency of the current extended site based on the real-time resource indicator information; determining whether the resource sufficiency meets preset deployment conditions based on the assessment result of the resource sufficiency; and if the resource sufficiency meets the preset deployment conditions, executing a full deployment mode to deploy a complete network. Containerized network function image; if resource sufficiency does not meet the preset deployment conditions, a lightweight deployment mode is executed, and the containerized network function image is deployed after component trimming; after the deployment of the containerized network function image is completed, the target configuration policy is obtained, and the heterogeneous network devices in the extended site are analyzed, and the management interface type of the heterogeneous network devices is identified; the current running configuration of each device is obtained, and the current running configuration of each device is compared with the target configuration policy to generate a differential configuration; according to the identified management interface type, the differential configuration is converted into a configuration command that is natively executable by the corresponding device and pushed to the corresponding device.

[0036] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in this application and in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

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

[0038] The above description is only a preferred embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural changes made based on the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A lightweight network deployment and configuration method for extended sites, characterized in that, The method includes: Collect real-time resource indicator information for the expanded site, including at least network bandwidth, free memory, and CPU utilization. Based on the real-time resource indicator information, assess the resource sufficiency of the current expansion site; Based on the assessment results of the resource sufficiency, determine whether the resource sufficiency meets the preset deployment conditions; If the resource availability meets the preset deployment conditions, then execute the full deployment mode and deploy the complete containerized network function image; If the resource sufficiency does not meet the preset deployment conditions, a lightweight deployment mode is executed, and the containerized network function image is deployed after component trimming. After completing the deployment of the containerized network function image, obtain the target configuration policy, analyze the heterogeneous network devices in the extended site, and identify the management interface types of the heterogeneous network devices. Obtain the current operating configuration of each device, compare the current operating configuration of each device with the target configuration strategy, and generate a differential configuration. Based on the identified management interface type, the differential configuration is converted into a configuration command that is natively executable by the corresponding device and pushed to the corresponding device.

2. The lightweight network deployment and configuration method for extended sites according to claim 1, characterized in that, The assessment of the resource adequacy of the current expanded site includes: The collected network bandwidth, free memory, and CPU utilization are weighted using preset weighting coefficients to obtain a resource sufficiency score, wherein the weighting coefficients for network bandwidth and free memory are positive, and the weighting coefficient for CPU utilization is negative; the higher the resource sufficiency score, the higher the resource sufficiency of the current expansion site.

3. The lightweight network deployment and configuration method for extended sites according to claim 1, characterized in that, The deployment of the containerized network function image after component trimming includes: Obtain the metadata of the containerized network function image, which defines multiple microservice components and the dependency graph between the components; Based on the dependency graph, a topological sorting algorithm is used to determine the set of non-core components; Based on the determined set of non-core components, the non-core component set is removed to obtain the updated image; Deploy the updated image.

4. The lightweight network deployment and configuration method for extended sites according to claim 1, characterized in that, The method further includes: Monitor the deployment status of the containerized network function image and the push results of the differential configuration, wherein the deployment status includes deployment success or deployment failure, and the push results include push success or push failure; Based on the monitored deployment status and push results, calculate the deployment success rate and configuration synchronization success rate within a preset historical time period; When the deployment success rate is lower than a preset first success rate threshold, the weighting coefficient of the CPU utilization is reduced. When the configuration synchronization success rate is lower than the preset second success rate threshold, the number of change items pushed in a single batch when the differential configuration is pushed to the corresponding device is reduced.

5. The lightweight network deployment and configuration method for extended sites according to claim 1, characterized in that, The steps for pushing the message to the corresponding device include: Identify the configuration item type corresponding to each change item in the differential configuration; Based on the identification results, the risk level of each change item is determined according to the preset risk level mapping table. The risk level is positively correlated with the impact range of the configuration item. The interface configuration is set to the first risk level, and the routing protocol configuration is set to the second risk level, which is higher than the first risk level. For changes with a risk level lower than the preset risk threshold, the changes are pushed directly to the corresponding devices. For changes with a risk level higher than or equal to a preset risk threshold, first start a sandbox simulation environment, simulate the execution of the changes in the sandbox, and push them to the corresponding device after verification. The sandbox simulation environment replicates a portion of the operating state of the corresponding device and automatically rolls back after the simulation is executed.

6. The lightweight network deployment and configuration method for extended sites according to claim 5, characterized in that, The step of pushing the device to the corresponding device further includes: Obtain the configuration dependencies between the heterogeneous network devices, wherein the configuration dependencies include at least one of resource dependencies, sequence dependencies, or mutual exclusion dependencies; Based on the configuration dependencies, construct a configuration dependency graph with configuration items as nodes and dependencies as directed edges; The configuration dependency graph is sorted using a topological sorting algorithm to obtain the push order of configuration items; Based on the order in which the configuration items are pushed, each configuration item is pushed to the corresponding heterogeneous network device in sequence according to the order. Based on the push results, if any configuration item fails to be pushed, subsequent pushes are stopped, and a rollback command is sent to the devices that have been successfully pushed in the reverse order of the push, so that the configuration of the devices can be restored to the state before the push.

7. The lightweight network deployment and configuration method for extended sites according to claim 6, characterized in that, The push to the corresponding device also includes: For each heterogeneous network device, obtain the internal dependencies of each change item in the differential configuration corresponding to the heterogeneous network device. The internal dependencies define the execution order constraints between different configuration items on the same device. Based on the internal dependencies, the differential configurations of the heterogeneous network devices are sorted topologically to obtain the configuration push sub-order within the heterogeneous network devices; According to the configuration push sub-order, adjust the relative order of each configuration item belonging to the heterogeneous network device in the push order, so that each change item of the heterogeneous network device is arranged in sequence according to the internal dependency relationship; Based on the results, each configuration item is pushed to the corresponding heterogeneous network device in the adjusted push order.

8. A lightweight network deployment and configuration system for extended sites, characterized in that, include: The acquisition module is used to collect real-time resource indicator information of the extended site. The real-time resource indicator information includes at least network bandwidth, free memory and CPU utilization. The evaluation module is used to evaluate the resource sufficiency of the current expanded site based on the real-time resource indicator information. The judgment module is used to determine whether the resource sufficiency meets the preset deployment conditions based on the assessment result of the resource sufficiency. The first execution module is used to execute the full deployment mode and deploy the complete containerized network function image if the resource availability meets the preset deployment conditions. The second execution module is used to execute a lightweight deployment mode if the resource sufficiency does not meet the preset deployment conditions, and to deploy the containerized network function image after component trimming. The acquisition module is used to acquire the target configuration policy after the containerized network function image is deployed, analyze the heterogeneous network devices in the extended site, and identify the management interface type of the heterogeneous network devices. The generation module is used to obtain the current operating configuration of each device, compare the current operating configuration of each device with the target configuration strategy, and generate a difference configuration. The push module is used to convert the differential configuration into a configuration command that is natively executable by the corresponding device according to the identified management interface type, and push it to the corresponding device.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images