Network element intelligent disaster recovery method, system, device, storage medium and product
By performing pattern matching and dynamically updating disaster recovery scripts in the network element pattern library, changes to virtual machines are automatically identified and disaster recovery operation instructions are generated. This solves the problem of disaster recovery scripts relying on manual updates and improves the accuracy, timeliness, and efficiency of disaster recovery operations.
Patent Information
- Application Number
- CN202411069669.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-05
- Publication Date
- 2025-11-18
- Estimated Expiration
- 2044-08-05
AI Technical Summary
In existing technologies, disaster recovery scripts rely on manual updates and maintenance, which affects the accuracy and timeliness of disaster recovery operations.
When virtual machines of network elements in the resource pool change, the name field information of the virtual machine is matched with the naming encoding pattern stored in the network element pattern library to determine the key information of the virtual machine. The script library is dynamically updated to store the disaster recovery scripts corresponding to each network element in different disaster recovery operations. Based on the target network element and operation input by the user, disaster recovery operation instructions are generated and the disaster recovery scripts are executed automatically.
It improves the accuracy and timeliness of disaster recovery operations, enhances the efficiency and convenience of disaster recovery operations, and reduces the maintenance pressure on operation and maintenance personnel.
Smart Images

Figure CN118900230B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of IT infrastructure, and in particular to network element intelligent disaster recovery methods, systems, devices, storage media and products. Background Technology
[0002] From its inception, 5G services have been fundamentally characterized by cloudification. Services are centrally deployed on operator-built cloud resource pools, typically with regional centers for resource pool construction. Similar network elements are distributed across different resource pools, forming service pools (POOLs). Network elements within a POOL serve as mutual disaster recovery backups. By design, when a resource pool failure causes service disruption, or when a network element itself fails, the service should be able to automatically migrate users to the disaster recovery network element, thus achieving service disaster recovery protection.
[0003] Currently, a centralized built-in disaster recovery script can be used to check the status of network elements when a fault occurs, and perform disaster recovery switching according to service switching requirements, thereby improving the accuracy and timeliness of disaster recovery processing on the network element side. However, the scripts need to be pre-configured and rely on manual updates and maintenance, which has a certain impact on accuracy and timeliness, and further optimization is needed.
[0004] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention
[0005] The main purpose of this application is to provide a network element intelligent disaster recovery method, system, device, storage medium and product, which aims to solve the technical problem that disaster recovery scripts rely on manual updates and maintenance in the prior art, affecting the accuracy and timeliness of disaster recovery operations.
[0006] To achieve the above objectives, this application provides a network element intelligent disaster recovery method, the method comprising:
[0007] When the virtual machine of a network element in the resource pool changes, the name field information of the virtual machine is matched based on the naming encoding pattern stored in the network element pattern library to determine the key information of the virtual machine.
[0008] Based on the key information of the virtual machine, the script library is dynamically updated. The script library stores the disaster recovery scripts corresponding to each network element in different disaster recovery operations.
[0009] Based on the name of the target network element and the target disaster recovery operation input by the user in the disaster recovery scenario, the target disaster recovery script is determined in the dynamically updated script library.
[0010] Based on the target disaster recovery script, a disaster recovery operation instruction is generated and sent to the proxy server of the resource pool where the target network element is located, so that the corresponding proxy server can log in to the cloud computing platform and execute the target disaster recovery script.
[0011] In one embodiment, the key information includes at least the virtual machine name, the name of the network element to which it belongs, and the function type. The step of dynamically updating the script library based on the key information of the virtual machine includes:
[0012] Based on the virtual machine name, obtain the identification code of the virtual machine from the cloud computing platform;
[0013] Based on the network element name to which the virtual machine belongs, determine the changing network element;
[0014] Based on the functional type of the virtual machine, the key virtual machines of the changed network element in different disaster recovery operations are determined. The disaster recovery operations include at least network element isolation, network element recovery, and network element status check.
[0015] Based on the identification code of the key virtual machine of the modified network element in different disaster recovery operations, a new disaster recovery script for the modified network element in different disaster recovery operations is generated.
[0016] Based on the identifier of the changed network element, a script update request is sent to the script library so that the script library can be dynamically updated according to the new disaster recovery script.
[0017] In one embodiment, before the step of determining the key information of a virtual machine by performing pattern matching on the name field information of the virtual machine based on the naming encoding patterns stored in the network element pattern library when a virtual machine in a network element changes, the method further includes:
[0018] Send performance data subscription information to the resource pool;
[0019] After the resource pool confirms successful subscription, it receives performance data reported by each resource pool according to a preset period.
[0020] The performance data is parsed to determine the virtual machine's name field information and other field information. The other field information includes at least the encoding type, geographical location, hardware resource pool number, vendor identifier, and virtual resource pool number.
[0021] Based on the virtual machine's name field information, determine whether the virtual machine of the network element in the resource pool has changed.
[0022] In one embodiment, the step of determining the target disaster recovery script from a dynamically updated script library based on the name of the target network element and the target disaster recovery operation input by the user in the disaster recovery scenario includes:
[0023] Upon receiving the disaster recovery task initiation information input by the user, a disaster recovery scenario is determined to be triggered.
[0024] Send task input prompt information to the user terminal to obtain the name of the target network element and the target disaster recovery operation input by the user terminal;
[0025] Based on the name of the target network element and the target disaster recovery operation, the script library is queried to determine the target disaster recovery script.
[0026] In one embodiment, the step of generating disaster recovery operation instructions based on the target disaster recovery script includes:
[0027] Based on the target disaster recovery script, determine the target virtual machine's identification code and task identification code;
[0028] Based on the name of the target network element, the identification code of the target virtual machine, and the task identification code, a disaster recovery execution prompt message is generated and sent to the user terminal.
[0029] Upon receiving confirmation from the user terminal regarding the disaster recovery execution prompt, the system generates the disaster recovery operation instruction based on the task identification code and the target disaster recovery operation.
[0030] In one embodiment, after the step of generating a disaster recovery operation instruction based on the target disaster recovery script and issuing the disaster recovery operation instruction to the proxy server of the resource pool where the target network element is located, so that the corresponding proxy server logs into the cloud computing platform to execute the target disaster recovery script, the method further includes:
[0031] Obtain the disaster recovery operation execution log recorded by the proxy server during the execution of the target disaster recovery script;
[0032] Based on the disaster recovery operation execution log, the disaster recovery operation execution result is determined;
[0033] Based on the disaster recovery operation execution result and the disaster recovery operation execution log, the execution result prompt information is output to the user terminal.
[0034] Furthermore, to achieve the above objectives, this application also proposes a network element intelligent disaster recovery system, which includes:
[0035] The system includes an external interaction interface, a control node, a network element pattern library, and a proxy server. The control node is connected to the external interaction interface, the network element pattern library, and the proxy server, respectively. The proxy server is deployed in various resource pools.
[0036] The control node is used to perform pattern matching on the name field information of the virtual machine based on the naming encoding pattern stored in the network element pattern library when the virtual machine of the network element in the resource pool changes, so as to determine the key information of the virtual machine.
[0037] The control node is also used to dynamically update the script library based on the key information of the virtual machine. The script library stores the disaster recovery scripts corresponding to each network element in different disaster recovery operations.
[0038] The external interaction interface is used to obtain the name of the target network element and the target disaster recovery operation input by the user terminal in the disaster recovery scenario, and send the name of the target network element and the target disaster recovery operation to the control node.
[0039] The control node is also configured to determine the target disaster recovery script from the dynamically updated script library based on the name of the target network element and the target disaster recovery operation, and send the target disaster recovery script to the external interaction interface.
[0040] The external interaction interface is also used to generate disaster recovery operation instructions based on the target disaster recovery script, and send the disaster recovery operation instructions to the control node;
[0041] The control node is also used to send the disaster recovery operation instruction to the proxy server of the resource pool where the target network element is located, so that the corresponding proxy server logs into the cloud computing platform to execute the target disaster recovery script.
[0042] In addition, to achieve the above objectives, this application also proposes a network element intelligent disaster recovery device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the network element intelligent disaster recovery method described above.
[0043] In addition, to achieve the above objectives, the present invention also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the network element intelligent disaster recovery method described above.
[0044] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the network element intelligent disaster recovery method described above.
[0045] This application provides a network element intelligent disaster recovery method. When a virtual machine of a network element in a resource pool changes, the method performs pattern matching on the name field information of the virtual machine based on the naming encoding pattern stored in the network element pattern library to determine the key information of the virtual machine. Based on the key information of the virtual machine, the method dynamically updates the script library, which stores the disaster recovery scripts corresponding to each network element in different disaster recovery operations. Based on the name of the target network element and the target disaster recovery operation input by the user terminal in the disaster recovery scenario, the method determines the target disaster recovery script in the dynamically updated script library. Based on the target disaster recovery script, the method generates a disaster recovery operation instruction and sends the disaster recovery operation instruction to the proxy server of the resource pool where the target network element is located, so that the corresponding proxy server logs into the cloud computing platform to execute the target disaster recovery script. This application utilizes a network element model library to parse the virtual machine name field, enabling automatic identification and classification of virtual machines. It can automatically identify changes in virtual machines within a network element, thereby dynamically updating the disaster recovery scripts in the script library. This improves the accuracy and timeliness of disaster recovery operations, as well as their efficiency. Furthermore, users only need to input the network element name and operation type to determine the corresponding disaster recovery operation instructions and execute the appropriate disaster recovery scripts, further enhancing the convenience and accuracy of disaster recovery operations. This solves the technical problem of disaster recovery scripts relying on manual updates and maintenance, which affects the accuracy and timeliness of disaster recovery operations. Attached Figure Description
[0046] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0047] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0048] Figure 1 This is a schematic diagram of the structure of Embodiment 1 of the intelligent disaster recovery system for network elements in this application;
[0049] Figure 2 This is a flowchart illustrating an embodiment of the intelligent disaster recovery method for network elements in this application.
[0050] Figure 3 This is a flowchart illustrating Embodiment 2 of the intelligent disaster recovery method for network elements in this application;
[0051] Figure 4 This is a schematic diagram of the overall architecture of the intelligent disaster recovery method for network elements provided in Embodiment 2 of this application;
[0052] Figure 5This is a simplified flowchart illustrating the disaster recovery information update process of the intelligent disaster recovery method for network elements provided in Embodiment 2 of this application.
[0053] Figure 6 This is a simplified flowchart illustrating the disaster recovery execution of the intelligent disaster recovery method for network elements provided in Embodiment 2 of this application.
[0054] Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the network element intelligent disaster recovery method in the embodiments of this application.
[0055] Explanation of icon numbers:
[0056] 10. External interaction interface; 20. Control node; 30. Network element model library; 40. Proxy server; 50. Resource pool;
[0057] 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
[0058] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.
[0059] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.
[0060] The main solution of this application embodiment is as follows: When the virtual machine of a network element in the resource pool changes, the name field information of the virtual machine is matched based on the naming encoding pattern stored in the network element pattern library to determine the key information of the virtual machine; based on the key information of the virtual machine, the script library is dynamically updated, and the script library stores the disaster recovery scripts corresponding to each network element in different disaster recovery operations; based on the name of the target network element and the target disaster recovery operation input by the user terminal in the disaster recovery scenario, the target disaster recovery script is determined in the dynamically updated script library; based on the target disaster recovery script, a disaster recovery operation instruction is generated and sent to the proxy server of the resource pool where the target network element is located, so that the corresponding proxy server logs into the cloud computing platform to execute the target disaster recovery script.
[0061] According to the deployment specifications of Phase I and Phase II of the Network Cloud, network elements in each province are currently deployed across major regions with disaster recovery nodes. This means that half of each type of network element is deployed in multiple resource pools in two different major regions, forming a mutual disaster recovery backup relationship. When a network element fails, the external interface of the failed node can be shut down, allowing users to automatically switch to the backup node, achieving disaster recovery protection. For example, if two sets of network elements are deployed, one primary and one backup, located in mutually disaster recovery resource pools, and both provide access services (N1 and N2 interfaces) to the province's 5G base stations, when one set of network elements fails (manifested as an unavailable interface), the base station or terminal will automatically switch services to the backup network element, achieving service disaster recovery. This is achieved by manually shutting down the interface-type virtual machine (PBU_I) of the primary network element and blocking the N1 and N2 interfaces, triggering automatic service switching, thus isolating network elements and quickly switching services.
[0062] It is evident that there are two key elements to achieving business disaster recovery: first, ensuring accurate acquisition of information about relevant virtual machines in network elements; and second, quickly generating disaster recovery operation instructions and rapidly issuing them after acquiring the virtual machine information to achieve rapid response.
[0063] Currently, a centralized built-in disaster recovery script can be used to check the status of network elements when a fault occurs, and perform disaster recovery switching according to service switching requirements, thereby improving the accuracy and timeliness of disaster recovery processing on the network element side. However, the scripts need to be pre-configured and rely on manual updates and maintenance, which has a certain impact on accuracy and timeliness, and further optimization is needed.
[0064] This application provides a solution that uses a network element model library to parse the virtual machine name field, enabling automatic identification and classification of virtual machines. It can automatically identify changes in virtual machines within a network element, thereby dynamically updating the disaster recovery scripts in the script library. This improves the accuracy and timeliness of disaster recovery operations, enhancing their efficiency. Furthermore, the user only needs to input the network element name and operation type to determine the corresponding disaster recovery operation instructions and execute the appropriate disaster recovery script, further improving the convenience and accuracy of disaster recovery operations. This solves the technical problem of disaster recovery scripts relying on manual updates and maintenance, which affects the accuracy and timeliness of disaster recovery operations.
[0065] This application provides a network element intelligent disaster recovery system, referring to... Figure 1 , Figure 1 This is a schematic diagram of the structure of the first embodiment of the intelligent disaster recovery system for network elements in this application.
[0066] In this embodiment, the network element intelligent disaster recovery system includes an external interaction interface 10, a control node 20, a network element model library 30, and a proxy server 40. The control node 20 is connected to the external interaction interface 10, the network element model library 30, and the proxy server 40, respectively. The proxy server 40 is deployed in each resource pool 50.
[0067] It should be noted that the external interaction interface 10 provides an external interaction window for interaction with the user terminal. Internally, it can communicate with the control node 20, sending query commands or disaster recovery operation commands to the control node 20 and receiving the results processed and returned by the control node 20. This embodiment uses the Chatops external interface, but it can be adjusted according to actual needs in practical applications, and no specific limitation is made. The control node 20 is the core control module in this embodiment. It is mainly responsible for receiving performance files reported by the resource pool 50, parsing and storing them in the database, and handling the updating of virtual machine information in the background process. It is also responsible for establishing command channels, receiving commands issued by the external interaction interface 10, and issuing commands and providing feedback on results after the external interaction interface 10 completes the interaction confirmation process. The proxy server 40 is usually responsible for encapsulating the cloud computing platform environment and login information (executing environment variables, logging into the KVM backend, etc.), executing and providing feedback on command results. The cloud computing platform used in this embodiment is OpenStack, and no specific limitation is made. The user terminal can be an APP or a web page, and no specific limitation is made.
[0068] Control node 20 is used to perform pattern matching on the name field information of virtual machines based on the naming encoding pattern stored in network element pattern library 30 when changes occur in the virtual machines of network elements in resource pool 50, in order to determine the key information of virtual machines.
[0069] It should be noted that there can be multiple resource pools of 50, depending on the actual situation. Each resource pool of 50 typically contains multiple network elements, and each network element typically contains multiple virtual machines. All virtual machines are assigned corresponding identification numbers according to the network cloud instance naming convention, which typically consists of 7 fields: encoding type, geographical location, hardware resource pool number, VIM vendor identifier, virtual resource pool number, resource type code, and resource instance number, with each field connected by a hyphen "-". The encoding type, geographical location, hardware resource pool number, vendor identifier, and virtual resource pool number can usually be set according to existing specifications. The resource instance number typically includes information such as the virtual machine's name, the name of the network element it belongs to, and its function type, and is defined by the manufacturer, not exceeding 32 characters. For example, if the virtual machine's identifier is NFV-R-HDBNJ-04A-HW-01-VM-HDBNJjsSMF001BHW-PBU_L2_ARM-0, where HDBNJ represents the region, 04A is the resource pool number, HW is the VIM vendor identifier, VM indicates that the device is a virtual machine, and HDBNJjsSMF001BHW-PBU_L2_ARM-0 is the virtual machine's resource instance number, its network element name is jsSMF001BHW, its function type is PBU_L2_ARM, and the ID of the same type of virtual machine in this network element is 0, then the virtual machine's name field information is the virtual machine's resource instance number.
[0070] Additionally, it should be noted that the key information for the virtual machine, i.e., the relevant information needed to generate the disaster recovery script, includes at least the virtual machine name, the name of the network element to which it belongs, and the function type. Since different manufacturers use different rules / standards to encode resource instance numbers, this embodiment sets up a network element pattern library 30 to quickly identify different virtual machines. The network element pattern library 30 stores various naming encoding patterns. These naming encoding patterns represent the rules / standards used by the manufacturers to encode resource instance numbers. By using the naming encoding patterns stored in the network element pattern library 30 to perform pattern matching on the virtual machine's name field information, the virtual machine name, the name of the network element to which it belongs, and the function type, etc., can be quickly parsed and obtained.
[0071] Understandably, when changes occur to the virtual machines of network elements in resource pool 50, the disaster recovery script needs to be updated in a timely manner. Therefore, it is necessary to determine the key information of the virtual machines in a timely and rapid manner, and to mark the virtual machines so as to identify the key virtual machines for subsequent disaster recovery operations and generate the corresponding disaster recovery scripts.
[0072] It should be understood that, in specific implementations, pattern matching may be performed only on the changing virtual machine, and this embodiment does not impose any specific limitations on this.
[0073] In one feasible implementation, the control node 20 is also used to send performance data subscription information to the resource pool 50; after the resource pool 50 confirms the successful subscription, it receives the performance data reported by each resource pool 50 according to a preset period; it parses the performance data to determine the virtual machine name field information and other field information, the other field information including at least the encoding type, geographical location, hardware resource pool number, vendor identifier and virtual resource pool number; and based on the virtual machine name field information, it determines whether the virtual machine of the network element in the resource pool 50 has changed.
[0074] It should be noted that performance data, i.e., VIM / PIM performance files, typically contains the latest information on network elements, virtual machines, etc. Performance data subscription information refers to the subscription request for VIM / PIM performance files. Control node 20 sends the VIM / PIM performance file subscription request to the NFV-O (one of the MNAO components) of each resource pool 50. If resource pool 50 confirms successful subscription, it will report the corresponding performance data according to a preset period, which is the set data reporting cycle, for example, 15 minutes. In this case, resource pool 50 generates performance data every 15 minutes and sends it to control node 20. The subscription operation only needs to be performed once after the entire system is established.
[0075] Understandably, other fields in the virtual machine's identifier, excluding the resource instance number, include fields such as encoding type, geographical location, hardware resource pool number, vendor identifier, and virtual resource pool number. According to the network cloud instance naming convention, the resource instance number, encoding type, geographical location, hardware resource pool number, vendor identifier, and virtual resource pool number are parsed out. If the resource instance number changes, it indicates that the virtual machines in resource pool 50 have changed; if the resource instance number does not change, it indicates that the virtual machines in resource pool 50 have not changed.
[0076] Control node 20 is also used to dynamically update the script library based on key information from virtual machines. The script library stores the disaster recovery scripts corresponding to each network element in different disaster recovery operations.
[0077] It should be noted that the script library is the database that stores disaster recovery scripts. Generally, different disaster recovery operations require the execution of different disaster recovery scripts. Therefore, the script library needs to store the corresponding disaster recovery scripts for each network element in different disaster recovery operations. If the virtual machines of the network elements in resource pool 50 change, the corresponding disaster recovery operations need to use new disaster recovery scripts. In other words, the existing disaster recovery scripts in the script library need to be dynamically updated.
[0078] In one feasible implementation, the control node 20 is further configured to: obtain the virtual machine's identification code from the cloud computing platform based on the virtual machine's name; determine the changing network element based on the virtual machine's home network element name; determine the key virtual machines of the changing network element in different disaster recovery operations based on the virtual machine's functional type, wherein the disaster recovery operations include at least network element isolation, network element recovery, and network element status checks; generate new disaster recovery scripts for the changing network element in different disaster recovery operations based on the identification codes of the key virtual machines of the changing network element; and send a script update request to the script library based on the changing network element's identification code, so that the script library can be dynamically updated according to the new disaster recovery scripts.
[0079] It should be noted that the virtual machine's identification code is its UUID (Universally Unique Identifier). Control node 20 queries OpenStack for the virtual machine's UUID and other information based on its name. A changed network element refers to a network element where a virtual machine has changed; its corresponding disaster recovery script needs to be updated. The identifier of a changed network element is its ID.
[0080] It is understood that the disaster recovery operation in this embodiment includes at least network element isolation, network element recovery, and network element status check. The critical virtual machine is the virtual machine that needs to perform the disaster recovery operation. Different disaster recovery operations can have different critical virtual machines, and this is not specifically limited. For example, the critical virtual machine for network element isolation is the interface virtual machine. Based on the functional type of the virtual machine, the control node 20 can determine the critical virtual machines for the changed network element in different disaster recovery operations. Using the UUIDs of these critical virtual machines, it sequentially generates disaster recovery scripts for network element isolation, network element status check, and network element recovery. Based on the ID of the changed network element, it initiates a script update request to the script library, and the script library updates and saves the new disaster recovery script.
[0081] The external interaction interface 10 is used to obtain the name of the target network element and the target disaster recovery operation input by the user terminal in the disaster recovery scenario, and send the name of the target network element and the target disaster recovery operation to the control node 20; the control node 20 is also used to determine the target disaster recovery script in the dynamically updated script library based on the name of the target network element and the target disaster recovery operation, and send the target disaster recovery script to the external interaction interface 10.
[0082] It should be noted that a disaster recovery scenario is a scenario in which disaster recovery needs to be performed, usually triggered by the user end. The target network element is the network element in which disaster recovery needs to be performed, the target disaster recovery operation is the disaster recovery operation to be performed, and the target disaster recovery script is the disaster recovery script required by the target network element to perform the target disaster recovery operation.
[0083] In one feasible implementation, the external interaction interface 10 is also used to determine the triggered disaster recovery scenario when it receives disaster recovery task initiation information input by the user terminal, and send task input prompt information to the user terminal to obtain the name of the target network element and the target disaster recovery operation input by the user terminal. Based on the name of the target network element and the target disaster recovery operation, it sends a query request to the control node 20. The control node 20 is also used to query the script library and determine the target disaster recovery script when it receives the query request.
[0084] It should be noted that the disaster recovery task initiation information refers to the keywords used to initiate the disaster recovery task, such as "disaster recovery initiation." This can be set according to actual needs and is not specifically limited. When operations and maintenance personnel enter the disaster recovery task initiation information on the user terminal, it is considered that the disaster recovery process has been initiated. The task input prompt information refers to the prompts for entering the name of the target network element and the target disaster recovery operation, such as: "Please enter the name of the disaster recovery network element and the type of disaster recovery operation to be initiated." This can be set according to actual needs and is not specifically limited.
[0085] Understandably, when disaster recovery is required, the operations and maintenance personnel enter the keywords for initiating the disaster recovery task on the user terminal (APP) to initiate the disaster recovery process. The external interaction interface 10 returns task input prompt information. The operations and maintenance personnel enter the name of the target network element and the target disaster recovery operation on the user terminal. The external interaction interface 10 queries the script library based on the name of the target network element and the target disaster recovery operation. After receiving the query request, the control node 20 queries the script library to obtain the disaster recovery script for the target network element.
[0086] The external interaction interface 10 is also used to generate disaster recovery operation instructions based on the target disaster recovery script and send the disaster recovery operation instructions to the control node 20; the control node 20 is also used to issue disaster recovery operation instructions to the proxy server of the resource pool where the target network element is located, so that the corresponding proxy server can log in to the cloud computing platform to execute the target disaster recovery script.
[0087] In one feasible implementation, the control node 20 is further configured to determine the target virtual machine and task identification code based on the target disaster recovery script, and send the name of the target network element, the identification code of the target virtual machine, and the task identification code to the external interaction interface 10; the external interaction interface 10 is further configured to generate disaster recovery execution prompt information based on the name of the target network element, the identification code of the target virtual machine, and the task identification code, and send the disaster recovery execution prompt information to the user terminal; upon receiving the user terminal's confirmation information on the disaster recovery execution prompt information, it generates a disaster recovery operation instruction based on the task identification code and the target disaster recovery operation, and sends the disaster recovery operation instruction to the control node 20.
[0088] It should be noted that the target virtual machine refers to the virtual machine involved in the target network element when performing the target disaster recovery operation. Since the virtual machine's identification code is used when generating the disaster recovery script, the identification codes of all target virtual machines can be found in the target disaster recovery script. The task identification code is the task ID. The disaster recovery execution prompt message is used to confirm whether to execute the target disaster recovery operation. It typically includes the name of the target network element and the identification code of the target virtual machine. For example: "You will perform isolation operations on interface virtual machines A and B of network element jsAMF001. Please reply 1 to confirm." If the user enters 1, it is considered that the user has received confirmation of the disaster recovery execution prompt message. This can be configured according to actual needs. The disaster recovery operation command is the execution command corresponding to the target disaster recovery operation.
[0089] Understandably, control node 20 returns the name of the target network element, the identification code of the target virtual machine, and the task identification code to the external interaction interface 10. The external interaction interface 10 returns disaster recovery execution prompt information to the user terminal. If the user terminal confirms that the information is correct, it sends a confirmation message. After receiving the confirmation message, the external interaction interface 10 generates a disaster recovery operation instruction carrying information such as the task ID and the target disaster recovery operation, and sends it to control node 20. Control node 20 queries the local database, selects the resource pool where the target network element is located, selects the corresponding proxy server 40, and issues the disaster recovery operation instruction. Proxy server 40 logs into OpenStack and executes the target disaster recovery script.
[0090] It should be understood that in this embodiment, an interactive entry point is built based on Chatops technology, the backend connects to the network element pattern library, and establishes an instruction channel with the cloud computing platform. When a disaster recovery scenario is triggered, operations and maintenance personnel only need to provide simple network element names, disaster recovery operation instruction keywords, etc. The system backend automatically completes the confirmation of network element information and instructions based on the provided information. After confirmation, operations and maintenance personnel can issue instructions for execution, avoiding the operation of writing and inputting instructions. Only simple confirmation is needed to complete the confirmation and issuance of disaster recovery operation instructions, greatly improving the convenience, accuracy, and security of disaster recovery operations.
[0091] In one feasible implementation, the control node 20 is further configured to obtain the disaster recovery operation execution log recorded by the proxy server 40 during the execution of the target disaster recovery script, determine the disaster recovery operation execution result based on the disaster recovery operation execution log, and send the disaster recovery operation execution result and the disaster recovery operation execution log to the external interaction interface 10; the external interaction interface 10 is further configured to output the execution result prompt information to the user terminal based on the disaster recovery operation execution result and the disaster recovery operation execution log.
[0092] It should be noted that the disaster recovery operation execution log is the log of the target disaster recovery script during execution, recorded by proxy server 40 and returned to control node 20. The disaster recovery operation execution result is the execution result of the target disaster recovery operation. The execution result prompt information is the prompt for the execution result, for example: the isolation operation of network element jsAMF001 was successfully executed, and the log is as follows: XXX, which can be set according to actual needs.
[0093] Understandably, proxy server 40 logs into OpenStack, executes scripts and records OpenStack logs, returns the relevant results to control node 20, the control node forwards the results to external interaction interface 10, and external interaction interface 10 outputs execution result prompt information to operations and maintenance personnel.
[0094] It should be understood that different disaster recovery operations can be carried out sequentially according to actual needs.
[0095] This embodiment provides a network element intelligent disaster recovery system. It utilizes a network element pattern library to parse the virtual machine name field, enabling automatic identification and classification of virtual machines. This allows for automatic identification of changes in virtual machines within a network element, thereby dynamically updating the disaster recovery scripts in the script library. This improves the accuracy and timeliness of disaster recovery operations, enhancing their efficiency. Furthermore, the user only needs to input the network element name and operation type to determine the corresponding disaster recovery operation instructions and execute the appropriate disaster recovery script, further improving the convenience and accuracy of disaster recovery operations.
[0096] This application provides a network element intelligent disaster recovery method, referring to... Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the intelligent disaster recovery method for network elements in this application.
[0097] In this embodiment, the intelligent disaster recovery method for network elements includes steps S10 to S40:
[0098] Step S10: When the virtual machine of the network element in the resource pool changes, the name field information of the virtual machine is matched based on the naming encoding pattern stored in the network element pattern library to determine the key information of the virtual machine.
[0099] It should be noted that this embodiment applies to a network element intelligent disaster recovery system. A network element intelligent disaster recovery system typically includes an external interaction interface, a control node, a network element pattern library, and a proxy server. The control node connects to the external interaction interface, the network element pattern library, and the proxy server, respectively. The proxy server is deployed in each resource pool. For a detailed structure, please refer to [reference needed]. Figure 1 In this embodiment, the external interaction interface is the Chatops external interface.
[0100] Additionally, it should be noted that there can be multiple resource pools, depending on the actual situation. Each resource pool typically contains multiple network elements, and each network element typically contains multiple virtual machines. All virtual machines are assigned corresponding identification numbers according to the network cloud instance naming convention, which typically consists of 7 fields: encoding type, geographical location, hardware resource pool number, VIM vendor identifier, virtual resource pool number, resource type code, and resource instance number, with each field connected by a hyphen (-). The encoding type, geographical location, hardware resource pool number, vendor identifier, and virtual resource pool number are usually set according to existing specifications. The resource instance number typically includes information such as the virtual machine's name, the name of the network element it belongs to, and its function type, and is defined by the manufacturer, not exceeding 32 characters. For example, if the virtual machine's identifier is NFV-R-HDBNJ-04A-HW-01-VM-HDBNJjsSMF001BHW-PBU_L2_ARM-0, where HDBNJ represents the region, 04A is the resource pool number, HW is the VIM vendor identifier, VM indicates that the device is a virtual machine, and HDBNJjsSMF001BHW-PBU_L2_ARM-0 is the virtual machine's resource instance number, its network element name is jsSMF001BHW, its function type is PBU_L2_ARM, and the ID of the same type of virtual machine in this network element is 0, then the virtual machine's name field information is the virtual machine's resource instance number.
[0101] It is understandable that the key information for a virtual machine, namely the information needed to generate a disaster recovery script, includes at least the virtual machine name, the name of the network element to which it belongs, and its function type. Since different manufacturers use different rules / standards to encode resource instance numbers, this embodiment sets up a network element pattern library to quickly identify different virtual machines. The network element pattern library stores various naming encoding patterns, which are the rules / standards used by the manufacturer to encode resource instance numbers. By using the naming encoding patterns stored in the network element pattern library to perform pattern matching on the virtual machine's name field information, the virtual machine name, the name of the network element to which it belongs, and its function type, etc., can be quickly parsed and obtained.
[0102] It should be understood that when virtual machines of network elements in the resource pool change, the disaster recovery script needs to be updated in a timely manner. Therefore, it is necessary to determine the key information of the virtual machines in a timely and rapid manner, and mark the virtual machines so as to identify the key virtual machines for disaster recovery operations and generate the corresponding disaster recovery scripts.
[0103] In practice, pattern matching can be performed only on the changing virtual machine; this embodiment does not impose any specific limitations on this.
[0104] Step S20: Based on the key information of the virtual machine, dynamically update the script library, which stores the disaster recovery scripts corresponding to each network element in different disaster recovery operations;
[0105] It should be noted that the script library is a database that stores disaster recovery scripts. Generally, different disaster recovery operations require the execution of different disaster recovery scripts. Therefore, the script library needs to store the corresponding disaster recovery scripts for each network element in different disaster recovery operations. If the virtual machines of network elements in the resource pool change, the corresponding disaster recovery operations need to use new disaster recovery scripts. In other words, the existing disaster recovery scripts in the script library need to be dynamically updated.
[0106] In one feasible implementation, step S20 may include steps S201 to S204:
[0107] Step S201: Obtain the identification code of the virtual machine from the cloud computing platform based on the virtual machine name;
[0108] It should be noted that the cloud computing platform used in this embodiment is OpenStack, but no specific limitation is made thereto.
[0109] It is understandable that the identification code of a virtual machine is its UUID. The control node queries OpenStack for information such as the virtual machine's UUID based on the virtual machine's name.
[0110] Step S202: Based on the network element name to which the virtual machine belongs, determine the changing network element; based on the function type of the virtual machine, determine the key virtual machines of the changing network element in different disaster recovery operations.
[0111] It should be noted that a changed network element refers to a network element where the virtual machine changes, and its corresponding disaster recovery script needs to be updated. Disaster recovery operations can be of different types; in this embodiment, the disaster recovery operations at least include network element isolation, network element recovery, and network element status checks. A critical virtual machine is a virtual machine that requires disaster recovery operations. For example, the critical virtual machine for network element isolation is the interface virtual machine. Different disaster recovery operations can correspond to different critical virtual machines; this embodiment does not specifically limit this.
[0112] Understandably, the control node can determine the critical virtual machines for changing network elements in different disaster recovery operations based on the functional type of the virtual machine.
[0113] Step S203: Based on the identification code of the key virtual machine of the changed network element in different disaster recovery operations, generate a new disaster recovery script for the changed network element in different disaster recovery operations.
[0114] It should be noted that the identifier code of the changing network element is the ID of the changing network element.
[0115] It is understandable that the UUIDs of these critical virtual machines are used to generate disaster recovery scripts for network element isolation, network element status checking, and network element recovery in sequence.
[0116] Step S204: Based on the identifier of the changed network element, a script update request is sent to the script library so that the script library can be dynamically updated according to the new disaster recovery script.
[0117] Understandably, a script update request is sent to the script library based on the ID of the changed network element, and the script library updates and saves the new disaster recovery script.
[0118] In this embodiment, disaster recovery scripts are dynamically generated based on pattern matching. This method has high accuracy and real-time performance, which can reduce the pressure on maintenance personnel to maintain and update disaster recovery scripts, while improving the overall operational efficiency of the disaster recovery system.
[0119] Step S30: Based on the name of the target network element and the target disaster recovery operation input by the user terminal in the disaster recovery scenario, determine the target disaster recovery script in the dynamically updated script library;
[0120] It should be noted that a disaster recovery scenario refers to a scenario requiring disaster recovery, typically triggered by the user end. The target network element is the network element for which disaster recovery needs to be performed, the target disaster recovery operation is the disaster recovery operation to be performed, and the target disaster recovery script is the disaster recovery script required for the target network element to perform the target disaster recovery operation. The user end can be an app or a web page; there are no specific limitations.
[0121] In one feasible implementation, step S30 may include steps S301 to S303:
[0122] Step S301: Upon receiving the disaster recovery task initiation information input by the user terminal, determine that a disaster recovery scenario is triggered.
[0123] It should be noted that the disaster recovery task initiation information is the keyword for initiating the disaster recovery task, such as "disaster recovery initiation". It can be set according to actual needs and there are no specific restrictions. When the operation and maintenance personnel enter the disaster recovery task initiation information on the user terminal, it is considered that the disaster recovery process is initiated and the disaster recovery scenario is triggered.
[0124] Step S302: Send task input prompt information to the user terminal to obtain the name of the target network element and the target disaster recovery operation input by the user terminal;
[0125] It should be noted that the task input prompts are the prompts for entering the name of the target network element and the target disaster recovery operation. For example: Please enter the name of the disaster recovery network element and the type of disaster recovery operation to be initiated. These can be set according to actual needs, and there are no specific limitations on them.
[0126] Understandably, the target disaster recovery operation can be entered in the form of keywords. For example, if the target disaster recovery operation is network element isolation, then enter "isolation".
[0127] Step S303: Based on the name of the target network element and the target disaster recovery operation, query the script library to determine the target disaster recovery script.
[0128] Understandably, when disaster recovery needs to be performed, the operations and maintenance personnel enter the keywords for initiating the disaster recovery task on the user terminal to initiate the disaster recovery process. The external interaction interface returns task input prompt information. The operations and maintenance personnel enter the name of the target network element and the target disaster recovery operation on the user terminal. The external interaction interface queries the script library based on the name of the target network element and the target disaster recovery operation. After receiving the query request, the control node queries the script library to obtain the disaster recovery script for the target network element.
[0129] Step S40: Based on the target disaster recovery script, generate a disaster recovery operation instruction and send the disaster recovery operation instruction to the proxy server of the resource pool where the target network element is located, so that the corresponding proxy server logs into the cloud computing platform to execute the target disaster recovery script.
[0130] It should be noted that the target virtual machine refers to the virtual machine involved in the target network element when performing the target disaster recovery operation. Since the identification code of the virtual machine is used when generating the disaster recovery script, the identification codes of all target virtual machines can be found in the target disaster recovery script.
[0131] In one feasible implementation, the step of generating a disaster recovery operation instruction based on a target disaster recovery script includes: determining the identification code and task identification code of a target virtual machine based on the target disaster recovery script; generating a disaster recovery execution prompt message based on the name of the target network element, the identification code of the target virtual machine, and the task identification code, and sending the disaster recovery execution prompt message to the user terminal; and generating the disaster recovery operation instruction based on the task identification code and the target disaster recovery operation when the user terminal confirms the disaster recovery execution prompt message.
[0132] It should be noted that the task identification code is the same as the task ID. The disaster recovery execution prompt message is used to confirm whether to execute the target disaster recovery operation. It typically includes the name of the target network element and the identification code of the target virtual machine. For example: "You will perform an isolation operation on interface virtual machines A and B of network element jsAMF001. Please reply with '1' to confirm." If the user enters '1', it is considered that the user has received confirmation of the disaster recovery execution prompt message. This can be configured according to actual needs. The disaster recovery operation command is the execution command corresponding to the target disaster recovery operation.
[0133] Understandably, the control node returns the name of the target network element, the identifier of the target virtual machine, and the task identifier to the external interaction interface. The external interaction interface returns disaster recovery execution prompt information to the user terminal. If the user terminal confirms that the information is correct, it sends a confirmation message. After receiving the confirmation message, the external interaction interface generates a disaster recovery operation instruction carrying information such as the task ID and the target disaster recovery operation, and sends it to the control node. The control node queries the local database, selects the resource pool where the target network element is located, selects the corresponding proxy server, and issues the disaster recovery operation instruction. The proxy server logs into OpenStack and executes the target disaster recovery script.
[0134] In this implementation, an interactive entry point is built based on Chatops technology, with the backend connecting to a network element model library and establishing a command channel with the cloud computing platform. When a disaster recovery scenario is triggered, operations and maintenance personnel only need to provide simple network element names and keywords for disaster recovery operation commands. The system backend automatically completes the confirmation of network element information and commands based on the provided information. After confirmation, operations and maintenance personnel can issue commands for execution, avoiding the need for users to write and input commands. Only simple confirmation is required to complete the confirmation and issuance of disaster recovery operation commands, greatly improving the convenience, accuracy, and security of disaster recovery operations.
[0135] This embodiment provides a network element intelligent disaster recovery method. When the virtual machine of a network element in the resource pool changes, the name field information of the virtual machine is pattern matched based on the naming encoding pattern stored in the network element pattern library to determine the key information of the virtual machine. Based on the key information of the virtual machine, the script library is dynamically updated. The script library stores the disaster recovery scripts corresponding to each network element in different disaster recovery operations. Based on the name of the target network element and the target disaster recovery operation input by the user terminal in the disaster recovery scenario, the target disaster recovery script is determined in the dynamically updated script library. Based on the target disaster recovery script, a disaster recovery operation instruction is generated and sent to the proxy server of the resource pool where the target network element is located, so that the corresponding proxy server logs into the cloud computing platform to execute the target disaster recovery script. By parsing the virtual machine name field using the network element model library, virtual machines can be automatically identified and classified. This allows for the automatic identification of changes in virtual machines within a network element, thereby automatically updating the disaster recovery scripts in the script library. This improves the accuracy and timeliness of disaster recovery operations, as well as their efficiency. Furthermore, users only need to input the network element name and operation type to determine the corresponding disaster recovery operation instructions and execute the appropriate disaster recovery scripts, further enhancing the convenience and accuracy of disaster recovery operations.
[0136] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 Steps S01 to S03 may be included before step S10:
[0137] Step S01: Send performance data subscription information to the resource pool. After the resource pool confirms the successful subscription, receive the performance data reported by each resource pool according to a preset period.
[0138] It should be noted that performance data, i.e., VIM / PIM performance files, typically contains the latest information on network elements, virtual machines, etc., while performance data subscription information refers to subscription requests for VIM / PIM performance files. The overall architecture of this example can be found by referring to... Figure 4 .
[0139] Understandably, the control node sends subscription requests for VIM / PIM performance files to the NFV-O (one of the MNAO components) of each resource pool. If the resource pool confirms a successful subscription, it will report the corresponding performance data according to a preset period, which is the set data reporting cycle, for example, 15 minutes. In this case, the resource pool generates performance data every 15 minutes and sends it to the control node. The subscription operation only needs to be performed once after the entire system is established.
[0140] Step S02: Parse the performance data to determine the virtual machine's name field information and other field information;
[0141] It should be noted that other fields in the virtual machine's identifier number, excluding the resource instance number, include fields such as encoding type, geographical location, hardware resource pool number, vendor identifier, and virtual resource pool number.
[0142] Understandably, according to the network cloud instance naming convention, the resource instance number, encoding type, geographical location, hardware resource pool number, vendor identifier, and virtual resource pool number are parsed out.
[0143] Step S03: Based on the virtual machine name field information, determine whether the virtual machine of the network element in the resource pool has changed.
[0144] It is understandable that if the resource instance number changes, it indicates that the virtual machine of the network element in the resource pool has changed; if the resource instance number does not change, it indicates that the virtual machine of the network element in the resource pool has not changed.
[0145] Furthermore, steps S501 to S502 may be included after step S40:
[0146] Step S501: Obtain the disaster recovery operation execution log recorded by the proxy server during the execution of the target disaster recovery script, and determine the disaster recovery operation execution result based on the disaster recovery operation execution log;
[0147] It should be noted that the disaster recovery operation execution log, i.e., the log of the target disaster recovery script during execution, is recorded by the proxy server and returned to the control node. The disaster recovery operation execution result is the result of the target disaster recovery operation.
[0148] Step S502: Based on the disaster recovery operation execution result and the disaster recovery operation execution log, output the execution result prompt information to the user terminal.
[0149] It should be noted that the execution result prompt message is a prompt for the execution result, for example: the isolation operation of network element jsAMF001 was successfully executed, and the log is as follows: XXX. This can be set according to actual needs.
[0150] Understandably, the proxy server logs into OpenStack, executes scripts and records OpenStack logs, returns the relevant results to the control node, the control node forwards the results to the external interaction interface, and the external interaction interface outputs execution result prompts to the operations and maintenance personnel.
[0151] It should be understood that different disaster recovery operations can be carried out sequentially according to actual needs.
[0152] This embodiment provides a network element intelligent disaster recovery method. By parsing the virtual machine name field using a network element pattern library, it achieves automatic identification and classification of virtual machines. It can automatically identify changes in virtual machines within a network element, thereby automatically updating the disaster recovery scripts in the script library. This improves the accuracy and timeliness of disaster recovery operations, as well as their efficiency. Furthermore, the user only needs to input the network element name and operation type to determine the corresponding disaster recovery operation instructions and execute the corresponding disaster recovery script, further enhancing the convenience and accuracy of disaster recovery operations.
[0153] For example, to help understand the implementation process of the network element intelligent disaster recovery method obtained by combining this embodiment with the above-described embodiment two, please refer to... Figure 5 , Figure 5 A simplified flowchart illustrating the disaster recovery information update process of a network element intelligent disaster recovery method is provided, specifically:
[0154] Step 1: The control node sends a performance file subscription request to the NFV-O of each resource pool;
[0155] Step 2: NFV-O confirms successful subscription (this step only needs to be performed once after the entire system is set up);
[0156] Step 3: NFV-O generates a VIM / PIM performance file (containing the latest information on network elements, virtual machines, etc.) every 15 minutes. After generation, NFV-O queries the subscription relationship and sends the VIM / PIM performance file to the control node.
[0157] Step 4: The control node receives the performance file, parses it into the database according to the rules, and checks for changes in virtual machines. If any virtual machines are added or removed, it initiates a pattern matching process to perform pattern matching on the added or changed virtual machines and assigns them the corresponding tags.
[0158] Step 5: For virtual machines that successfully match the pattern, the control node queries OpenStack for information such as the virtual machine's UUID based on the virtual machine's name, which is used to generate scripts;
[0159] Step 6: The control node generates scripts for different disaster recovery operations such as network element isolation, network element status check, and network element recovery in sequence according to the virtual machine UUID, and sends a script update request to the script library according to the network element ID;
[0160] Step 7: Update and save the disaster recovery script in the script library.
[0161] Please refer to Figure 6 , Figure 6 A simplified flowchart illustrating the disaster recovery execution process of a network element intelligent disaster recovery method is provided, specifically:
[0162] Step 1: Maintenance personnel initiate the disaster recovery process via the APP (e.g., by entering keywords such as "disaster recovery initiation");
[0163] Step 2: The Chatops frontend returns the following prompt: Please enter the name of the disaster recovery network element and the type of operation to be initiated;
[0164] Step 3: Maintenance personnel enter the network element name and operation type (e.g., jsAMF001, isolation);
[0165] Step 4: The Chatops front-end queries the script library based on the input network element name and operation type;
[0166] Step 5: After receiving the query request, the control terminal queries the script library and returns the basic information of the network element and the disaster recovery script information of the network element;
[0167] Step 6: The chatops frontend returns an execution prompt message to the user: You will perform isolation operations on virtual machines A and B of the network element jsAMF001 interface. Please reply with 1 to confirm.
[0168] Step 7: The user confirms the information is correct and replies with "1" as confirmation.
[0169] Step 8: After receiving the confirmation message, Chatops queries the local database with keywords such as task ID and operation type, selects the corresponding resource pool and the corresponding proxy server, and issues the disaster recovery task.
[0170] Step 9: The proxy server logs into OpenStack, executes scripts and records OpenStack logs, returns the relevant results to the control node, and the control node forwards the results to the chattops frontend;
[0171] Step 10: The chatops frontend returns the result to the operations and maintenance personnel: The isolation operation of the network element jsAMF001 was successfully executed, and the log is as follows: XXX.
[0172] This application provides a network element intelligent disaster recovery device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the network element intelligent disaster recovery method in the above embodiment 1.
[0173] The following is for reference. Figure 7 The diagram illustrates a structural schematic suitable for implementing the network element intelligent disaster recovery device in the embodiments of this application. The network element intelligent disaster recovery device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), vehicle terminals (e.g., vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The network element intelligent disaster recovery device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.
[0174] like Figure 7As shown, the network element intelligent disaster recovery device may include a processing system 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1002 or the program loaded from the storage system 1003 into the random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the network element intelligent disaster recovery device. The processing system 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input systems 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output systems 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage systems 1003 including, for example, magnetic tapes, hard disks, etc.; and communication systems 1009. Communication system 1009 allows the network element intelligent disaster recovery device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a network element intelligent disaster recovery device with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.
[0175] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication system, or installed from storage system 1003, or installed from ROM 1002. When the computer program is executed by processing system 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.
[0176] The intelligent disaster recovery device for network elements provided in this application, employing the intelligent disaster recovery method for network elements in the above embodiments, can solve the technical problem that the reliance on manual updates and maintenance of disaster recovery scripts affects the accuracy and timeliness of disaster recovery operations. Compared with the prior art, the beneficial effects of the intelligent disaster recovery device for network elements provided in this application are the same as those of the intelligent disaster recovery method for network elements provided in the above embodiments, and other technical features in this intelligent disaster recovery device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.
[0177] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.
[0178] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
[0179] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the network element intelligent disaster recovery method in the above embodiments.
[0180] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.
[0181] The aforementioned computer-readable storage medium may be included in the network element intelligent disaster recovery device; or it may exist independently and not be assembled into the network element intelligent disaster recovery device.
[0182] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the network element intelligent disaster recovery device, the network element intelligent disaster recovery device: when a virtual machine of a network element in the resource pool changes, it performs pattern matching on the name field information of the virtual machine based on the naming encoding pattern stored in the network element pattern library to determine the key information of the virtual machine; based on the key information of the virtual machine, it dynamically updates the script library, which stores the disaster recovery scripts corresponding to each network element in different disaster recovery operations; based on the name of the target network element and the target disaster recovery operation input by the user terminal in the disaster recovery scenario, it determines the target disaster recovery script in the dynamically updated script library; based on the target disaster recovery script, it generates a disaster recovery operation instruction and sends the disaster recovery operation instruction to the proxy server of the resource pool where the target network element is located, so that the corresponding proxy server logs into the cloud computing platform to execute the target disaster recovery script.
[0183] Computer program code for performing the operations of this application can be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, and C++, and conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0184] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0185] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.
[0186] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described intelligent disaster recovery method for network elements. This solves the technical problem that disaster recovery scripts rely on manual updates and maintenance, affecting the accuracy and timeliness of disaster recovery operations. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the intelligent disaster recovery method for network elements provided in the above embodiments, and will not be elaborated upon here.
[0187] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the network element intelligent disaster recovery method described above.
[0188] The computer program product provided in this application can solve the technical problem that disaster recovery scripts rely on manual updates and maintenance, affecting the accuracy and timeliness of disaster recovery operations. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the intelligent disaster recovery method for network elements provided in the above embodiments, and will not be repeated here.
[0189] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.
Claims
1. A method for intelligent disaster recovery of network elements, characterized in that, The method includes: When the virtual machine of a network element in the resource pool changes, the name field information of the virtual machine is matched based on the naming encoding pattern stored in the network element pattern library to determine the key information of the virtual machine. Based on the key information of the virtual machine, the script library is dynamically updated. The script library stores the disaster recovery scripts corresponding to each network element in different disaster recovery operations. Based on the name of the target network element and the target disaster recovery operation input by the user in the disaster recovery scenario, the target disaster recovery script is determined in the dynamically updated script library. Based on the target disaster recovery script, a disaster recovery operation instruction is generated and sent to the proxy server of the resource pool where the target network element is located, so that the corresponding proxy server can log in to the cloud computing platform and execute the target disaster recovery script.
2. The method as described in claim 1, characterized in that, The key information includes at least the virtual machine name, the name of the network element to which it belongs, and the function type. The step of dynamically updating the script library based on the key information of the virtual machine includes: Based on the virtual machine name, obtain the identification code of the virtual machine from the cloud computing platform; Based on the network element name to which the virtual machine belongs, determine the changing network element; Based on the functional type of the virtual machine, the key virtual machines of the changed network element in different disaster recovery operations are determined. The disaster recovery operations include at least network element isolation, network element recovery, and network element status check. Based on the identification code of the key virtual machine of the modified network element in different disaster recovery operations, a new disaster recovery script for the modified network element in different disaster recovery operations is generated. Based on the identifier of the changed network element, a script update request is sent to the script library so that the script library can be dynamically updated according to the new disaster recovery script.
3. The method as described in claim 1, characterized in that, Before the step of determining the key information of a virtual machine by performing pattern matching on the name field information of the virtual machine based on the naming encoding pattern stored in the network element pattern library when a virtual machine in the network element changes, the method further includes: Send performance data subscription information to the resource pool; After the resource pool confirms successful subscription, it receives performance data reported by each resource pool according to a preset period. The performance data is parsed to determine the virtual machine's name field information and other field information. The other field information includes at least the encoding type, geographical location, hardware resource pool number, vendor identifier, and virtual resource pool number. Based on the virtual machine's name field information, determine whether the virtual machine of the network element in the resource pool has changed.
4. The method as described in claim 1, characterized in that, The step of determining the target disaster recovery script from the dynamically updated script library based on the name of the target network element and the target disaster recovery operation input by the user in the disaster recovery scenario includes: Upon receiving the disaster recovery task initiation information input by the user, a disaster recovery scenario is determined to be triggered. Send task input prompt information to the user terminal to obtain the name of the target network element and the target disaster recovery operation input by the user terminal; Based on the name of the target network element and the target disaster recovery operation, the script library is queried to determine the target disaster recovery script.
5. The method as described in claim 1, characterized in that, The step of generating disaster recovery operation instructions based on the target disaster recovery script includes: Based on the target disaster recovery script, determine the target virtual machine's identification code and the task identification code; Based on the name of the target network element, the identification code of the target virtual machine, and the task identification code, a disaster recovery execution prompt message is generated and sent to the user terminal. Upon receiving confirmation from the user terminal regarding the disaster recovery execution prompt, the system generates the disaster recovery operation instruction based on the task identification code and the target disaster recovery operation.
6. The method according to any one of claims 1 to 5, characterized in that, The step of generating disaster recovery operation instructions based on the target disaster recovery script and sending the disaster recovery operation instructions to the proxy server of the resource pool where the target network element is located, so that the corresponding proxy server logs into the cloud computing platform to execute the target disaster recovery script, further includes: Obtain the disaster recovery operation execution log recorded by the proxy server during the execution of the target disaster recovery script; Based on the disaster recovery operation execution log, the disaster recovery operation execution result is determined; Based on the disaster recovery operation execution result and the disaster recovery operation execution log, the execution result prompt information is output to the user terminal.
7. A network element intelligent disaster recovery system, characterized in that, The system includes an external interaction interface, a control node, a network element pattern library, and a proxy server. The control node is connected to the external interaction interface, the network element pattern library, and the proxy server, respectively. The proxy server is deployed in various resource pools. The control node is used to perform pattern matching on the name field information of the virtual machine based on the naming encoding pattern stored in the network element pattern library when the virtual machine of the network element in the resource pool changes, so as to determine the key information of the virtual machine. The control node is also used to dynamically update the script library based on the key information of the virtual machine. The script library stores the disaster recovery scripts corresponding to each network element in different disaster recovery operations. The external interaction interface is used to obtain the name of the target network element and the target disaster recovery operation input by the user terminal in the disaster recovery scenario, and send the name of the target network element and the target disaster recovery operation to the control node. The control node is also configured to determine the target disaster recovery script from the dynamically updated script library based on the name of the target network element and the target disaster recovery operation, and send the target disaster recovery script to the external interaction interface. The external interaction interface is also used to generate disaster recovery operation instructions based on the target disaster recovery script, and send the disaster recovery operation instructions to the control node; The control node is also used to send the disaster recovery operation instruction to the proxy server of the resource pool where the target network element is located, so that the corresponding proxy server logs into the cloud computing platform to execute the target disaster recovery script.
8. A network element intelligent disaster recovery device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the network element intelligent disaster recovery method as described in any one of claims 1 to 6.
9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the network element intelligent disaster recovery method as described in any one of claims 1 to 6.
10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the network element intelligent disaster recovery method as described in any one of claims 1 to 6.
Citation Information
Patent Citations
Database remote disaster recovery system and deployment method and deployment device thereof
CN109947591A
Core network element disaster recovery processing method and system
CN117082546A