Full-life-cycle management method, system and equipment for SD-WAN (Secure Digital-Wide Area Network) access unit

Abstract

The invention discloses a full life cycle management method, system and device of an SD-WAN access unit, and relates to the technical field of communication, and the method comprises the steps: creating an atomic AU, a combined AU and a client AU, and building a DAG dependence topology; when the version is updated, parallel gray migration of the double-version service domain name set is executed, a new-version atomic AU is synchronized step by step according to a downstream influence range, the service domain name access success rate is monitored, and when a preset condition is not met, automatic rollback is carried out before the version is updated; and detecting idle AUs in the database by combining the DAG dependent topology, the reference count corresponding to each AU and the operation flow access data, and after the operation and maintenance approval is passed, sequentially executing the cleaning processes of unbinding an association network strategy, filing and automatically deleting and releasing resources. According to the method, the AU creation efficiency can be improved, the dependency relationship between the AUs can be visually tracked, the out-of-control change influence is avoided, version upgrading can be safely and efficiently completed, idle resources are automatically cleaned, and the storage utilization rate is improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method, system and device for full lifecycle management of SD-WAN access units. Background Technology

[0002] In SD-WAN (Software-Defined Wide Area Network), the full lifecycle management of AU (Access Unit) needs to address four major pain points: low creation efficiency, chaotic dependencies, risky version migration, and significant resource waste. Specifically, existing technologies suffer from the following problems due to the lack of a tag-based composition mechanism and structured dependency management: 1) Inefficient creation of combined AUs: Without tag-based categorization, atomic AU retrieval relies on manual memory, and filtering with 100+ atomic AUs takes more than 1 hour; combined AUs need to be associated with atomic AUs one by one, resulting in many repetitive operations and low creation efficiency.

[0003] 2) Dependencies are not visible: Dependency chains are only recorded in documents, and changes require manual investigation of downstream impacts. This process takes more than 12 hours for 100 customers. Furthermore, there is no reference count, making it easy to accidentally delete atomic AU versions that still have references, leading to business interruptions.

[0004] 3) High risk of version migration: There is no standardized process, and because there are multiple AUs, the amount of changes is large and error-prone; in addition, rollback depends on manual configuration.

[0005] 4) Manual lifecycle management: Idle AU identification relies on regular inspections, which takes 2 days per inspection for a scale of 1000+ AUs, and is prone to omissions; in addition, there are no standards for cleaning up, resulting in a high proportion of idle resources and low storage utilization. Summary of the Invention

[0006] The purpose of this application is to provide a method, system, and device for full lifecycle management of SD-WAN access units, which can improve the efficiency of AU creation, visualize and track the dependencies between AUs, avoid the loss of control due to changes, and also complete version upgrades securely and efficiently, and automatically clean up idle resources to improve storage utilization.

[0007] To achieve the above objectives, this application provides the following solution: Firstly, this application provides a method for full lifecycle management of SD-WAN access units, including: Atomic AUs, composite AUs, and customer AUs are created and stored in the database; different composite AUs correspond to different business scenarios, different customer AUs correspond to different customer needs, and each AU has a corresponding reference count and tag; Based on the atomic AUs, combined AUs, and customer AUs in the database, a DAG dependency topology is established and visualized. When any atomic AU changes, the downstream impact range is quantitatively deduced based on the DAG dependency topology and the corresponding reference count. When the change is a version update, a parallel gray-scale migration of the dual-version business domain name set is performed, and the new version atomic AU is gradually synchronized according to the downstream impact range while monitoring the success rate of business domain name access. If the preset conditions are not met, the atomic AU is automatically rolled back to the version update-previous atomic AU. The system periodically detects idle AUs in the database by combining the DAG dependency topology, the reference counts of each AU, and the running traffic access data. After approval by the operations and maintenance department, it sequentially executes the cleanup process of unbinding associated network policies, archiving, and automatically deleting and releasing resources to achieve full lifecycle management.

[0008] Secondly, this application provides a full lifecycle management system for SD-WAN access units, including: The AU creation module is used to create atomic AUs, composite AUs, and customer AUs, all of which are stored in the database. Different composite AUs correspond to different business scenarios, and different customer AUs correspond to different customer needs. Each AU also has a corresponding reference count and tag. The DAG dependency topology construction module is used to build and visualize the DAG dependency topology based on the atomic AUs, combined AUs and customer AUs in the database. The gray-scale migration module is used to quantify and extrapolate the downstream impact range based on the DAG dependency topology and the corresponding reference count when any atomic AU changes. When the change is a version update, it performs a parallel gray-scale migration of the dual-version business domain name set, and gradually synchronizes the new version atomic AU according to the downstream impact range while monitoring the success rate of business domain name access. If the preset conditions are not met, it automatically rolls back to the atomic AU before the version update. The idle cleanup module is used to periodically detect idle AUs in the database by combining the DAG dependency topology, the reference count of each AU, and the running traffic access data. After approval by the operation and maintenance department, the cleanup process of unbinding associated network policies, archiving, and automatically deleting and releasing resources is executed in sequence to achieve full lifecycle management.

[0009] Thirdly, this application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a method for full lifecycle management of an SD-WAN access unit.

[0010] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application creates atomic AUs, combined AUs, and customer AUs and stores them in a database. Each AU has a corresponding tag to ensure accurate characterization of AU business attributes and to quickly create combined AUs that meet business scenarios and customer AUs that meet customer needs. Then, a DAG dependency topology is established and visualized. Since each AU has a corresponding reference count, it can reflect the reference popularity of each AU, and further quantify and extrapolate the downstream impact range. This allows for the rapid location of downstream AUs with matching business attributes, high dependency popularity, and the need for synchronous updates when changes occur. Furthermore, due to the use of a visualized DAG dependency topology, the dependency relationships between AUs can be visually tracked, preventing the impact of changes from spiraling out of control. During version updates, a parallel gray-scale migration of dual-version business domain name sets is performed, and the new version atomic AUs are gradually synchronized according to the downstream impact range while monitoring the success rate of business domain name access. If the preset conditions are not met, the system automatically rolls back to the atomic AUs before the version update. Through this migration process, downstream access interruption caused by domain name version changes can be avoided, and atomic AU version upgrades can be completed safely and efficiently. Finally, idle AUs are detected periodically by combining the DAG dependency topology, the reference count of each AU, and the running traffic access data. After approval by the operations and maintenance department, the cleanup process of unbinding associated network policies (to avoid the failure of associated network policies), archiving, and automatically deleting and releasing resources is executed in sequence, thereby automatically cleaning up idle resources and improving storage utilization. Attached Figure Description

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

[0012] Figure 1 This is a flowchart illustrating the full lifecycle management method of an SD-WAN access unit in one embodiment of this application.

[0013] Figure 2 This is a flowchart illustrating the full lifecycle management method of the SD-WAN access unit in another embodiment of this application.

[0014] Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0015] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0016] This application achieves fully automated and visualized management of the entire process of AU from creation to destruction through tag-based combination, DAG dependency management, versioned migration, and full lifecycle control, with the core process led by operations and maintenance.

[0017] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, this application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0018] It should be noted that: AU stands for Access Unit, which is the smallest unit of SD-WAN policy configuration based on a set of business domain names, and is centrally managed by operations and maintenance (O&M). Atomic AU is the smallest set of domain names aggregated according to business scenarios (at least one domain name), containing metadata such as version, reference count, and multiple tags, and is created and maintained by O&M. Composite AU is an industry-standard unit formed by O&M based on the combination of atomic AUs, generated through multi-tag filtering, and includes a reference list and reference count. Customer AU is a dedicated unit configured by O&M for customers, referencing only composite AUs / atomic AUs. DAG (Directed Acyclic Graph) records AU dependency relationships (Customer AU → Composite AU → Atomic AU), with nodes containing metadata such as version, count, and tags. The reference count records the number of times an AU is referenced downstream (e.g., if an atomic AU is referenced by 3 composite AUs, the reference count = 3), used for dependency quantification and idleness determination. The standardized multiple tags of atomic AUs are the classification identifiers of atomic AUs (e.g., business scenario, function type, etc.), supporting multi-tag association, such as {remote office, SaaS}. The tag pool is a set of standardized tags preset by O&M (e.g., business category, compliance category) to avoid tag confusion. The composite AUlist is a candidate set formed by filtering atomic AUs with multiple tags, and becomes a composite AU after being confirmed by operations and maintenance. Idle AUs are atomic AUs / composite AUs with a reference count of 0 and no traffic access for 3 consecutive months.

[0019] In one exemplary embodiment, such as Figure 1 As shown, a method for full lifecycle management of an SD-WAN access unit is provided. This method is executed by a computer device, specifically by a terminal or server alone, or by both a terminal and a server. In this embodiment, it includes the following steps 101 to 104.

[0020] Step 101: Create atomic AUs, composite AUs, and customer AUs, and store them in the database. Different composite AUs correspond to different business scenarios, and different customer AUs correspond to different customer needs. Each AU also has a corresponding reference count and tag.

[0021] (a) The process of creating the atom AU includes: 11) For any atomic AU creation request, parse the core data contained in the atomic AU creation request; the core data includes at least: a set of business domain names (such as [" .microsoft365.com", " The business domain name set includes: .sharepoint.com, version number (e.g., v1, v2, etc.), temporary business tags (e.g., ["temporary-remote office", "temporary-SaaS"]), and basic metadata (creation time, business line ID).

[0022] 12) Verify the core data, and after the verification is passed, create an atomic AU based on the core data; specifically, the verification is the verification of domain name format compliance and version number uniqueness.

[0023] 13) Store the atomic AU in the database and assign a unique identifier (e.g., AU_ATOM_001) to the atomic AU. At this time, the reference count of the atomic AU is zero, and the information contained in the corresponding atomic AU is shown in Table 1.

[0024] Table 1

[0025] At this point, a new atomic AU record is added to the database, containing the domain name, version number, temporary tag, unique identifier, and initial count (0), providing basic data for subsequent tag standardization and combination creation.

[0026] 14) Extract the temporary business tags from the atomic AU and match them with the enabled tags in the preset standardized tag pool to obtain the corresponding standardized multi-tags.

[0027] The pre-defined standardized tag pool includes business scenario tags (such as cross-border e-commerce, remote work), compliance attribute tags, and function type tags (such as SaaS, CDN). Each tag corresponds to a tag ID and a tag status, which is either enabled or disabled. Each atomic AU is associated with at least one business scenario tag and one function type tag. The pre-defined standardized tag pool can also be updated, and the corresponding update tasks include the following three types: First, receive new tag data from the operation and maintenance configuration, such as adding a "remote office" tag, classifying it as "business scenario", inserting it into the tag pool table, and waiting for use.

[0028] Second, receive abandoned tags marked by operations and maintenance, such as updating the status of the tag "working from home" to "abandoned".

[0029] Third, corresponding to step 41 above, scan the atomic AU, extract temporary business tags, match them with tags in the tag pool that are enabled, replace the temporary business tags of the atomic AU with standardized tags, and update the tag field of the atomic AU in the database. Specifically, tag matching is achieved through fuzzy matching + operation and maintenance preset mapping relationship, such as mapping "temporary-remote office" to "remote office".

[0030] 15) Update the temporary business label in the atomic AU to the standardized multi-label.

[0031] Thus, this application maintains a standardized tag set by pre-setting a standardized tag pool, ensuring that all generated atomic AU tags are enabled standardized tags in the tag pool, providing a unified search benchmark for subsequent combined AU screening.

[0032] (ii) The creation process of the combined AU includes: 21) For any target business scenario, parse out the target business tag; specifically, receive the combined AU scenario filtering request and parse the target business tag in the request. In practical applications, it is necessary to first confirm that all target business tags are enabled according to the preset standardized tag pool before proceeding with subsequent steps. In addition, the target business tag of the combined AU is the intersection of the standardized multiple tags of the atomic AU it references, such as ["cross-border e-commerce", "SaaS"].

[0033] 22) Based on the full-label hit strategy, atomic AUs are filtered from the database according to the target business labels, and the unique identifiers of the corresponding atomic AUs are recorded to form a combined AU list. Specifically, the generation records of atomic AUs are queried, and atomic AUs whose label fields contain all target business labels are filtered out. An example of the full-label hit strategy is as follows: the standardized multi-label of atomic AU AU_ATOM_001 is ["remote office", "SaaS", "international whitelist"], which does not contain "cross-border e-commerce", so it does not hit; the standardized multi-label of atomic AU AU_ATOM_002 is ["cross-border e-commerce", "SaaS", "international whitelist"], so it hits. Then, the records of the hit atomic AUs are integrated into a combined AU candidate list and stored in a temporary table.

[0034] At this point, a candidate list of combined AUs is generated in the temporary table, containing all atomic AUs that match the target business tag, providing a candidate set for the next step of creating combined AUs.

[0035] 23) After the combined AU list has been reviewed and approved by the operations and maintenance department, a combined AU is created based on the combined AU list.

[0036] 24) Store the combined AU in the database, assign a unique identifier to the combined AU, and increment the reference count of the atomic AU referenced by the combined AU.

[0037] Specifically, upon receiving a combined AU creation request, the system parses the candidate listID (associated with the temporary table mentioned above, i.e., the combined AU list after operation and maintenance review), combined AU name (e.g., "Cross-border Office Combination"), and industry (e.g., "Cross-border E-commerce") contained in the combined AU creation request. It reads the unique identifier of the atomic AU corresponding to the candidate list ID from the temporary table, such as ["AU_ATOM_002", "AU_ATOM_003"]. Then, it generates a combined AU in the database, assigns a unique identifier, such as AU_COMBO_001, and stores the identifier list, name, and industry of the referenced atomic AUs. For each referenced atomic AU (corresponding to AU_ATOM_002 and AU_ATOM_003 mentioned above), it performs a reference count update: reads the current count from the database (e.g., 0), increments it by 1, and writes it back (updating it to 1).

[0038] At this point, a new composite AU has been added to the database, and the reference count of the referenced atomic AU is updated synchronously, providing an intermediate unit for subsequent client AU references.

[0039] (iii) The process of creating the aforementioned customer AU includes: 31) For any customer request, parse the customer ID and the corresponding reference AU identifier; the reference AU identifier is a unique identifier of the combined AU or the unique identifier of the atomic AU; specifically, receive the creation request of the customer AU, and parse the customer ID (such as CUST_001) and reference AU identifier (such as AU_COMBO_001, i.e. the combined AU mentioned above) contained in the creation request of the user AU.

[0040] 32) Create a customer AU based on the customer ID and the corresponding reference AU identifier.

[0041] 33) Store the customer AU in the database, assign a unique identifier to the customer AU (e.g., AU_CUST_001), and increment the reference count of the combined AUs and / or atomic AUs referenced by the customer AU. If it is a combined AU (e.g., AU_COMBO_001), read its current count (e.g., 0) from the database, increment it by 1, and write it back (updating it to 1); if it is an atomic AU, directly update its count.

[0042] At this point, a new record for the customer AU has been added to the database, and the reference counts of the referenced combined AUs (or atomic AUs) have been updated synchronously, providing node data for the subsequent construction of the DAG topology.

[0043] Step 102: Based on the atomic AUs, combined AUs, and customer AUs in the database, construct the DAG dependency topology and visualize it. In a specific application, the following DAG dependency topology construction task can be executed periodically (e.g., every five minutes): (1) Read all atomic AUs, combined AUs and customer AUs from the database and extract the corresponding core metadata; wherein, the core metadata of the customer AU includes: unique identifier, customer ID, referencing AU identifier and reference count; the core metadata of the combined AU includes: unique identifier, target business tag, unique identifier and reference count of the filtered atomic AU; the core metadata of the atomic AU includes: unique identifier, business domain name set, version number of business domain name set, standardized multi-tag and reference count.

[0044] (2) Construct a node set with the customer AU as the root node, the combined AU as the intermediate node, and the atom AU as the leaf node; the node attributes of each node in the node set contain the corresponding core metadata.

[0045] (3) Generate directed edges based on the reference relationships between each AU to obtain edge data; specifically, generate edges based on the reference relationships. According to the numbering signals of each AU recorded above, we can assume AU_CUST_001→AU_COMBO_001, AU_COMBO_001→AU_ATOM_002. We can also ensure that there are no circular references through recursive detection, and finally construct a dependency topology that conforms to the DAG rules.

[0046] (4) Store the node set and edge data in the DAG topology library to generate a DAG dependency topology. At this point, a complete dependency network is formed in the DAG topology library. The nodes contain metadata such as tags, versions, and counts, providing a visual dependency chain for subsequent version migration and lifecycle management.

[0047] Step 103: When any atomic AU changes, based on the DAG dependency topology and the corresponding reference count, perform a quantitative deduction of the downstream impact scope. Changes to atomic AUs can be data changes, functional changes, and configuration changes, etc. Version changes fall under configuration changes.

[0048] When a version update is implemented, a parallel canary migration of the dual-version business domain sets is performed. The new version atomic AU is gradually synchronized based on the downstream impact scope, and the success rate of business domain access is monitored. If preset conditions are not met, the system automatically rolls back to the atomic AU before the version update, including: (1) Upon receiving an atomic AU version update request (e.g., AU_ATOM_002 upgraded from v1 to v2), resolve the set of new business domain names in the atomic AU version update request (e.g., newly added " .m365.com).

[0049] (2) Based on the new business domain name set, create a new version of the atomic AU (e.g., AU_ATOM_002_v2) in the database; the new version of the atomic AU has the same tag as the old version of the atomic AU, and the old version of the atomic AU refers to the atomic AU before receiving the atomic AU version update request; at this time, the reference count of the new version of the atomic AU is zero.

[0050] (3) Generate an impact list based on the downstream impact range of the old version of the atomic AU; as mentioned above, query the downstream dependent nodes of the old version of the atomic AU AU_ATOM_002_v1 from the DAG topology library. This operation is achieved by edge traversal and generates an impact list containing node identifiers, customer IDs, and the number of devices.

[0051] (4) For any downstream dependent node in the impact list, perform parallel processing of the dual-version business domain name set; specifically, update the reference list of AU_COMBO_001 to include both v1 and v2. At this time, the reference count of the new version atomic AU is enabled and begins to accumulate; the reference count of the old version atomic AU is retained.

[0052] (5) Based on the count ratio of each downstream dependent node in the impact list, the new version of the atomic AU is gradually synchronized from low to high, the corresponding reference count is updated, and the access success rate of the new business domain name set is monitored.

[0053] (6) When the access success rate reaches the preset condition, all downstream dependent nodes reference the new version of the atomic AU, and the reference count of the old version of the atomic AU is reduced to zero. The preset condition is that the access success rate is ≥99.9%. After the access success rate reaches the standard, all downstream dependent nodes are updated to v2, the v1 reference count is reduced to 0, and the v2 reference count is updated to the original v1 reference count.

[0054] (7) When the access success rate does not meet the preset conditions, the references of all downstream dependent nodes are automatically rolled back to the old version of the atomic AU, and the reference count of the new version of the atomic AU is reduced to zero; that is, if the access success rate does not meet the standard, it will be rolled back within 1 minute. At this time, the v2 reference count is deleted and the v1 reference count is restored.

[0055] Once the atomic AU completes the version migration (or rollback), the node versions and counts in the DAG topology are updated synchronously to ensure the continuity of dependent links.

[0056] Step 104: Periodically detect idle AUs in the database by combining the DAG dependency topology, the reference count of each AU, and the running traffic access data. After approval by the operation and maintenance department, execute the cleanup process of unbinding associated network policies, archiving, and automatically deleting and releasing resources in sequence to achieve full lifecycle management.

[0057] In a practical application, step 104 includes: (1) Scheduled triggering of idle screening; specifically, it can be set to trigger the execution of full life cycle management tasks weekly.

[0058] (2) After the idle screening is triggered, based on the DAG dependency topology, atomic AUs and combined AUs that meet the preset idle conditions are selected; wherein, the preset idle conditions are: the reference count is zero and the running traffic access data is zero within a first duration (e.g., three months).

[0059] (3) Push the atomic AU and combined AU that meet the preset idle conditions to the operation and maintenance approval interface and receive the approval result, which is either passed or rejected.

[0060] (4) When the approval result is passed, for the corresponding atomic AU and combined AU, the network policy associated with the policy is removed from the SD-WAN policy library (the identifier of the AU associated with the policy is updated to null), and then archived to the history library for a second period of time (e.g., one year). After the second period of time, the policy is automatically deleted from the history library. In addition, the node and associated edge are removed from the DAG topology library. At this point, the idle AU is safely cleaned up, the DAG topology library and the database are updated synchronously, and storage resources are released.

[0061] In this application, reference counting is used to reflect the dependency heat of AUs in real time, providing a quantitative basis for DAG analysis, migration priority determination, and idle AU detection. In summary, the reference count update scenarios are as follows: When creating a composite AU: for the referenced atomic AU, the execution count = current count + 1; When creating a customer AU: for the referenced composite AU / atomic AU, the execution count = current count + 1; During the grayscale migration process, after full synchronization, the execution count of the old version atomic AU = 0, and the execution count of the new version atomic AU = the original count of the old version; During the idle AU processing, it is necessary to verify whether the AU count is 0 as a prerequisite for cleanup; In addition, when dereferencing (such as deleting a customer AU), for the originally referenced composite AU / atomic AU, the execution count = current count - 1.

[0062] All reference count updates are synchronously written to the node attributes in the database and the DAG topology library.

[0063] like Figure 2As shown, in a specific practical application, the overall architecture and full lifecycle process are as follows: (1) Create atomic AUs and manage the tag pool to implement tag configuration (standardized tags for operation and maintenance).

[0064] Atomic AU1 (Microsoft 365_v1): Domain { .microsoft365.com}, Standardized Multi-Tag {Cross-border E-commerce, SaaS, International Whitelist}, Citation Count = 0.

[0065] Atomic AU2 (Alibaba Cloud CDN_v1): Domain { .aliyuncs.com}, standardized multi-tag {cross-border e-commerce, CDN, domestic filing}, citation count = 0.

[0066] (2) Generate a list of combined AUs and create combined AUs.

[0067] The target business scenario for operation and maintenance input is: "Office and content acceleration for cross-border e-commerce enterprises".

[0068] Filter target business tags: {cross-border e-commerce, SaaS∨CDN} (“∨” represents OR logic).

[0069] Generate a combined AU list: Atomic AU1 (hitting cross-border e-commerce + SaaS) + Atomic AU2 (hitting cross-border e-commerce + CDN).

[0070] After the operations and maintenance team confirms, a cross-border office combination AU is created, and the counts of atomic AU1 and AU2 are each incremented by 1, thus becoming 1.

[0071] (3) Create customer AU (reference composition / atomic AU, count +1) and DAG dependency topology (record dependency + label + count).

[0072] Both customers AU of companies A and B reference cross-border office combination AU, so the combination AU count becomes 2, and the atomic AU1 and AU2 counts become 2.

[0073] The DAG automatically generates dependency links: Client AU1 / 2 → Combination AU → Atom AU1_v1 / Atom AU2_v1, with nodes containing labels and counts.

[0074] (4) Version migration (dual version parallel + gray-scale synchronization).

[0075] Atomic AU1 adds a new domain name The v2 version of .m365.com has a reference count of 0.

[0076] The impact of DAG deduction: The reference count corresponding to the combined AU is 2 → Customer AU1 / 2 (50 devices).

[0077] Dual versions running in parallel for 7 days → Gray-scale synchronization of 20% of devices (success rate 99.97%) → Full synchronization, v1 reference count is 0, v2 reference count is 2.

[0078] (5) Full lifecycle management (idle detection + approval + cleanup), citation count update.

[0079] If the reference count of the atom AU1_v1 is 0 and there has been no traffic for 3 months, it will be marked as idle and the operations and maintenance personnel will be notified. After the operations and maintenance personnel approve it, the system will unbind it according to the following policy: archive it for 1 year, then delete it automatically and release the storage.

[0080] Compared with the prior art, this application has the following advantages: (1) Based on the business scenarios, compliance attributes, domain name types, and preset standardized tag pool of SD-WAN AU, the AU business attributes are accurately characterized. A combined AU list is generated by full-hit filtering of multiple tags (which must simultaneously meet the business characteristics corresponding to the target tags). After confirmation by operation and maintenance, the combined AU is created to ensure that the domain name set of the combined AU can directly support the target business scenario, thus improving the creation efficiency.

[0081] (2) The DAG topology nodes integrate AU-specific metadata, supporting the linkage of tag filtering → dependency link visualization → count quantification of impact scope → version migration simulation. When changes occur, downstream AUs with matching business attributes, high dependency popularity, and requiring synchronous updates can be quickly located. Due to the collaborative management of DAG topology and tags / counts, DAG nodes integrate tags, reference counts, and version information, realizing a closed loop of tag retrieval → dependency visualization → change impact simulation, reducing the location time.

[0082] (3) The parallel gray-scale migration and automatic rollback of the two versions coexist for 7 days. The gray-scale verification is carried out at a ratio of 20%. In case of an anomaly, the rollback is carried out within 1 minute, which reduces the interruption rate.

[0083] (4) Idle AUs are determined by two dimensions of full lifecycle automated management based on counting and traffic. After approval by operation and maintenance, they are automatically unbound, archived and deleted, which improves the cleanup rate and storage utilization.

[0084] Based on the same inventive concept, this application also provides a system. The solution provided by this system is similar to the solution described in the above method. Therefore, the specific limitations of one or more system embodiments provided below can be found in the limitations of the method above, and will not be repeated here.

[0085] In one exemplary embodiment, a full lifecycle management system for an SD-WAN access unit is provided, comprising: The AU creation module is used to create atomic AUs, composite AUs, and customer AUs, all of which are stored in the database. Different composite AUs correspond to different business scenarios, and different customer AUs correspond to different customer needs. Each AU also has a corresponding reference count and tag.

[0086] This module constructs a three-tier AU architecture: Atomic AUs (containing a set of business-scenario-based domain names, version information, and multiple tags), Composite AUs (created from an atomic AU list filtered by multiple tags, the list being confirmed by operations and maintenance), and Customer AUs (referring only to Composite AUs or Atomic AUs). Each AU has an associated reference count (dynamically increasing or decreasing based on upstream and downstream reference relationships). During the creation of Composite AUs, atomic AUs containing all target business tags are selected to ensure the domain name set matches business requirements, generating a Composite AU list. After review and confirmation by operations and maintenance, Composite AUs are created based on this list, and the tags of a Composite AU are the intersection of the tags of the atomic AUs it references.

[0087] The DAG dependency topology construction module is used to build and visualize DAG dependency topologies based on atomic AUs, combined AUs, and customer AUs in the database.

[0088] This module uses a DAG topology to record AU dependencies. DAG nodes integrate tags (business attributes), reference counts (dependency popularity), and versions (domain set iterations), supporting the visualization of dependency links and the quantitative deduction of the downstream impact range of atomic AU changes. Specifically, by recursively traversing the DAG topology, all downstream affected nodes of an atomic AU change can be located, and the impact range can be quantified by combining the node reference count (e.g., a reference count of 5 represents affecting 5 downstream AUs).

[0089] The grayscale migration module is used to quantify and extrapolate the downstream impact range based on the DAG dependency topology and the corresponding reference count when any atomic AU changes. When the change is a version update, it performs a parallel grayscale migration of the dual-version business domain name set, and gradually synchronizes the new version atomic AU according to the downstream impact range while monitoring the success rate of business domain name access. If the preset conditions are not met, it automatically rolls back to the atomic AU before the version update.

[0090] In this module, when upgrading the atomic AU version, a parallel canary migration of the two versions of the domain name set is performed. Synchronization is performed according to the downstream AU reference count ratio, and the domain name access success rate is verified. If an anomaly occurs, the system automatically reverts to the old version. The canary migration includes: the coexistence of the old and new atomic AU domain name sets for ≥7 days; gradual synchronization according to the downstream AU reference count ratio from low to high (e.g., first synchronizing the test AU with a reference count of 1, then synchronizing the core AU with a reference count of 10); real-time monitoring of the domain name access success rate, performing a full synchronization when the success rate is ≥99.9%, otherwise automatically rolling back to the old version of the domain name set within 1 minute.

[0091] The idle cleanup module is used to periodically detect idle AUs in the database by combining the DAG dependency topology, the reference count of each AU, and the running traffic access data. After approval by the operation and maintenance department, the cleanup process of unbinding associated network policies, archiving, and automatically deleting and releasing resources is executed in sequence to achieve full lifecycle management.

[0092] In this module, idle AUs with zero reference counts and no traffic access for three consecutive months and no indirect dependencies in the DAG are detected. After approval by operations and maintenance, a cleanup process is executed: unbinding the associated network policy → archiving for ≥1 year → automatic deletion. Unbinding the associated network policy is a prerequisite for cleanup, ensuring that deleting the AU does not affect the effectiveness of existing SD-WAN policies; archiving for ≥1 year is used to retain historical AU configurations to meet operations and maintenance audit requirements; automatic deletion is only performed after the archiving period expires and it is confirmed that there is no need for recovery.

[0093] In one exemplary embodiment, a computer device is provided, which may be a server or a terminal, and its internal structure diagram may be as follows. Figure 3 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. 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 databases. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media to run. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a full lifecycle management method for the SD-WAN access unit.

[0094] Those skilled in the art will understand that Figure 3The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0095] In one exemplary embodiment, a computer device is also provided, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps in the above-described method embodiments.

[0096] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0097] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0098] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0099] Those skilled in the art will understand that all or part of the processes in 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 described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0100] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0101] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0102] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for full lifecycle management of an SD-WAN access unit, characterized in that, The method includes: Atomic AUs, composite AUs, and customer AUs are created and stored in the database; different composite AUs correspond to different business scenarios, different customer AUs correspond to different customer needs, and each AU has a corresponding reference count and tag; Based on the atomic AUs, combined AUs, and customer AUs in the database, a DAG dependency topology is established and visualized. When any atomic AU changes, the downstream impact range is quantitatively deduced based on the DAG dependency topology and the corresponding reference count. When the change is a version update, a parallel gray-scale migration of the dual-version business domain name set is performed, and the new version atomic AU is gradually synchronized according to the downstream impact range while monitoring the success rate of business domain name access. If the preset conditions are not met, the atomic AU is automatically rolled back to the version update-previous atomic AU. The system periodically detects idle AUs in the database by combining the DAG dependency topology, the reference counts of each AU, and the running traffic access data. After approval by the operations and maintenance department, it sequentially executes the cleanup process of unbinding associated network policies, archiving, and automatically deleting and releasing resources to achieve full lifecycle management.

2. The method for full lifecycle management of SD-WAN access units according to claim 1, characterized in that, The process of creating the atom AU includes: For any atomic AU creation request, parse the core data contained in the atomic AU creation request; the core data includes at least: a set of business domain names, a version number of the set of business domain names, temporary business tags, and basic metadata; The core data is verified, and an atomic AU is created based on the core data after the verification is passed. The atomic AU is stored in the database, and a unique identifier is assigned to the atomic AU. Extract the temporary business tags from the atomic AU and match them with the enabled tags in the preset standardized tag pool to obtain the corresponding standardized multi-tags; Update the temporary business label in the atomic AU to the standardized multi-label.

3. The method for full lifecycle management of SD-WAN access units according to claim 1, characterized in that, The process of creating the combined AU includes: For any given target business scenario, the target business tag is parsed and obtained; Based on the full-label hit strategy, atomic AUs are selected from the database according to the target business labels, and the unique identifiers of the corresponding atomic AUs are recorded to form a combined AU list; After the combined AU list is approved by the operations and maintenance department, a combined AU is created based on the combined AU list; The combined AU is stored in the database, a unique identifier is assigned to the combined AU, and the reference count of the atomic AU referenced by the combined AU is incremented by one.

4. The method for full lifecycle management of SD-WAN access units according to claim 1, characterized in that, The process of creating the customer AU includes: For any customer requirement, the customer ID and the corresponding reference AU identifier are parsed to obtain the customer ID and the corresponding reference AU identifier; the reference AU identifier is either a unique identifier of the combined AU or a unique identifier of the atomic AU. Create a customer AU based on the customer ID and the corresponding referenced AU identifier; The customer AU is stored in the database, a unique identifier is assigned to the customer AU, and the reference count of the combined AUs and / or atomic AUs referenced by the customer AU is incremented by one.

5. The method for full lifecycle management of SD-WAN access units according to claim 1, characterized in that, Based on the atomic AUs, composite AUs, and client AUs in the database, a DAG dependency topology is established, including: Read all atomic AUs, combined AUs, and customer AUs from the database and extract the corresponding core metadata. The core metadata of the customer AU includes: unique identifier, customer ID, referencing AU identifier, and reference count. The core metadata of the combined AU includes: unique identifier, target business tag, unique identifier and reference count of the filtered atomic AUs. The core metadata of the atomic AU includes: unique identifier, business domain name set, version number of the business domain name set, standardized multi-tag, and reference count. A node set is constructed with the customer AU as the root node, the combined AU as the intermediate node, and the atomic AU as the leaf node; the node attributes of each node in the node set contain the corresponding core metadata. Directed edges are generated based on the reference relationships between each AU to obtain edge data; The node set and the edge data are stored in the DAG topology library to generate a DAG dependency topology.

6. The method for full lifecycle management of SD-WAN access units according to claim 1, characterized in that, When a version update is implemented, a parallel canary migration of the dual-version business domain sets is performed. The new version atomic AU is gradually synchronized based on the downstream impact scope, and the success rate of business domain access is monitored. If preset conditions are not met, the system automatically rolls back to the atomic AU before the version update, including: Upon receiving the Atomic AU version update request, the set of new business domain names in the Atomic AU version update request is parsed. Based on the new business domain name set, a new version of Atomic AU is created in the database; the new version of Atomic AU has the same tag as the old version of Atomic AU, and the old version of Atomic AU refers to the Atomic AU before receiving the Atomic AU version update request; Based on the downstream impact range of the old version of the atomic AU, generate an impact list; For any downstream dependent node in the impact list, parallel processing of the dual-version business domain name set is performed; at this time, the reference count of the new version atomic AU is enabled, and the reference count of the old version atomic AU is retained; Based on the count ratio of each downstream dependent node in the impact list, the new version of the atomic AU is gradually synchronized from low to high, the corresponding reference count is updated, and the access success rate of the new business domain name set is monitored. When the access success rate reaches a preset condition, all downstream dependent nodes reference the new version of the atomic AU, and the reference count of the old version of the atomic AU is reduced to zero. When the access success rate does not meet the preset conditions, all references to the downstream dependent nodes are automatically rolled back to the old version of the atomic AU, and the reference count of the new version of the atomic AU is reduced to zero.

7. The method for full lifecycle management of SD-WAN access units according to claim 1, characterized in that, The system periodically detects idle AUs in the database by combining the DAG dependency topology, the reference counts of each AU, and the running traffic access data. After approval by operations and maintenance personnel, it sequentially executes a cleanup process of unbinding associated network policies, archiving, and automatically deleting and releasing resources to achieve full lifecycle management, including: Scheduled triggering of idle item filtering; After the idle screening is triggered, based on the DAG dependency topology, atomic AUs and combined AUs that meet the preset idle conditions are selected; wherein, the preset idle conditions are: the reference count is zero and the running traffic access data is zero within the first time period; Push atomic AUs and combined AUs that meet the preset idle conditions to the operation and maintenance approval interface and receive the approval results; When the approval result is passed, for the corresponding atomic AU and combined AU, the network policy is unassociated from the SD-WAN policy library, then archived to the history library for a second period of time, and automatically deleted from the history library after the second period of time.

8. The method for full lifecycle management of SD-WAN access units according to claim 2, characterized in that, The preset standardized tag pool includes business scenario tags, compliance attribute tags, and function type tags. Each tag corresponds to a tag ID and a tag status, which is either enabled or disabled. Each atomic AU is associated with at least one business scenario tag and one function type tag.

9. A full lifecycle management system for an SD-WAN access unit, characterized in that, The system includes: The AU creation module is used to create atomic AUs, composite AUs, and customer AUs, all of which are stored in the database. Different composite AUs correspond to different business scenarios, and different customer AUs correspond to different customer needs. Each AU also has a corresponding reference count and tag. The DAG dependency topology construction module is used to build and visualize the DAG dependency topology based on the atomic AUs, combined AUs and customer AUs in the database. The gray-scale migration module is used to quantify and extrapolate the downstream impact range based on the DAG dependency topology and the corresponding reference count when any atomic AU changes. When the change is a version update, it performs a parallel gray-scale migration of the dual-version business domain name set, and gradually synchronizes the new version atomic AU according to the downstream impact range while monitoring the success rate of business domain name access. If the preset conditions are not met, it automatically rolls back to the atomic AU before the version update. The idle cleanup module is used to periodically detect idle AUs in the database by combining the DAG dependency topology, the reference count of each AU, and the running traffic access data. After approval by the operation and maintenance department, the cleanup process of unbinding associated network policies, archiving, and automatically deleting and releasing resources is executed in sequence to achieve full lifecycle management.

10. A computer device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the full lifecycle management method for the SD-WAN access unit according to any one of claims 1-8.

Images