Service system disaster recovery system and method based on cloud computing, electronic equipment and storage medium

Abstract

The invention provides a service system disaster recovery system based on cloud computing, and relates to the technical field of disaster recovery backup recovery and cloud computing, and the system comprises a software application registration and arrangement module which is used for registering an entity object of a service application to a software warehouse, arranging a topological structure of the service application according to a dependency relationship, and configuring a disaster recovery strategy; the software application deployment disaster recovery module is used for automatically deploying a pull-up service application and backing up the pull-up service application according to a disaster recovery strategy; the fault monitoring and damage decision-making module is used for performing fault monitoring and damage decision-making on the application instance, and sending out an alarm notification when a fault or a disaster is monitored; and the system recovery disaster recovery switching module is used for executing system recovery operation when receiving the alarm notification, executing disaster recovery switching operation such as upstream data flow and service access entry redirection, and realizing system recombination recovery and service replacement. The invention further provides a service system disaster recovery method based on cloud computing, electronic equipment and a storage medium.

Description

Technical Field

[0001] The present application relates to the fields of disaster recovery, backup and recovery, and cloud computing technology, and more specifically, to a business system disaster recovery system, method, electronic device, and storage medium based on cloud computing. Background Art

[0002] In recent years, my country's aerospace remote sensing satellite technology has developed rapidly, and its ground systems have been widely used in key areas such as military, meteorology, agriculture, and disaster prevention and mitigation. With the surge in the number of satellites and users, the software scale and data volume of ground systems have grown exponentially, and system concentration has continued to increase, creating an increasingly urgent need for high availability and disaster recovery capabilities. Traditional disaster recovery technology has evolved over nearly half a century, from early tape backups to real-time data protection in the cloud computing era. Cloud disaster recovery, through a flexible and scalable cloud service platform, provides a new solution for aerospace remote sensing ground systems. Currently, mainstream domestic cloud platforms (such as Alibaba Cloud and Huawei Cloud) as well as industry-built private clouds have become the primary foundation for ground systems. Establishing a flexible and efficient cloud disaster recovery mechanism is crucial to ensuring business continuity.

[0003] Disaster recovery technology can be divided into three levels: data level, application level, and business level. Data level disaster recovery focuses on data backup and achieves data redundancy through off-site storage, but the recovery time is long; application level disaster recovery builds a backup application system based on data backup, supports rapid switching, and ensures business continuity; business level disaster recovery covers all infrastructure and non-IT systems, and is suitable for fields such as finance that have extremely high continuity requirements. The current mainstream solutions focus on data level and application level disaster recovery, and typical technologies include the "two-site three-center" model (such as Figure 1 As shown in Figure 1, the system consists of a production center, a local backup center, and a remote backup center. Data from the production center is synchronously replicated to the local center and asynchronously replicated to the remote center. Each center must deploy a unified version of application software (except for grayscale releases), and switch to it through disaster recovery control in the event of a disaster. However, this type of solution suffers from low resource utilization and high costs, and the disaster recovery center is often idle, resulting in high O&M complexity. Although existing patented technologies (such as CN118779159A and CN117851122A) attempt to optimize the disaster recovery process through cloud native and automated means, they are mostly limited to a single deployment form (such as virtual machines or containers), making it difficult to cope with the complexity of hybrid architectures and lacking global management of software configurations and dependencies.

[0004] Current disaster recovery technology faces four core challenges: First, a holistic business system perspective makes global coordination difficult during recovery. Second, a focus on data over applications means that software deployment and version synchronization rely on manual labor, limiting the application of cold standby models. Third, insufficient automation means the recovery process relies on manual operations, resulting in low efficiency and error-prone performance. Fourth, limited compatibility makes it difficult to support hybrid deployment environments such as bare metal, virtual machines, and containers. Future development requires addressing the resource-wasting bottlenecks of the traditional "two-site, three-center" model and exploring dynamic resource scheduling and intelligent disaster recovery management. For example, by combining the elastic scalability of cloud-native technologies (such as Kubernetes), an automated disaster recovery platform supporting multi-modal deployments can be built, ultimately achieving a low-cost, efficient, and highly available disaster recovery system for aerospace remote sensing ground systems. Summary of the Invention

[0005] In view of this, the present application provides a business system disaster recovery system, method, electronic device and computer-readable storage medium based on cloud computing.

[0006] The first aspect of the present application provides a business system disaster recovery system based on cloud computing, including: a software application registration and orchestration module, which is used to register the entity objects of each business application in the business system to a software warehouse, and upload the entity files of the entity objects, arrange the topology of the business system according to the dependency relationship between the entity objects, and configure the disaster recovery strategy required by the business system, the entity objects include the software products, external dependencies, deployment units and application instances of the business applications, and the entity files include deployment packages, scripts and images; a software application deployment disaster recovery module, which is used to automatically deploy and pull up all application instances in the business system after the business application registration in the business system is completed, and deploy the entity files of each business application according to the disaster recovery strategy. The physical objects and physical files are synchronously backed up to at least one standby node; a fault monitoring and damage decision module is used to collect status, monitor faults and make damage decisions for each application instance of the business system, and issue an alarm notification when a fault or disaster is detected; a system recovery and disaster recovery switching module is used to execute the system recovery operation of the business application on the primary node or the standby node according to the disaster recovery strategy when receiving the alarm notification, and after the recovery is completed, redirect the upstream data traffic and business access entry by configuring the external access entry information of the business system to achieve business reorganization recovery and business disaster recovery switching. The system recovery operation includes automatically restoring the business system according to the topology of the business system, the registration information of the software warehouse and the physical files.

[0007] According to an embodiment of the present application, the topology structure is defined based on a business system topology orchestration model, the nodes of the business system topology orchestration model represent the entity objects, and the connecting lines between the nodes represent the dependency relationships between the entity objects, and the dependency relationships include the relationship types of "running on", "depending on", "connected to", "belonging to" and "copied to" between the entity objects, wherein the relationship type "copied to" is used to represent the relationship between multiple copies in the cluster or load balancing in the business system; the nodes and the connecting lines both support on-demand definition of attributes and operations, and the attributes and the operations are used to automatically recover the business system in the system recovery operation.

[0008] According to an embodiment of the present application, the software application registration orchestration module supports basic information management and maintenance of the business application and provides a graphical topology structure orchestration interface.

[0009] According to an embodiment of the present application, the software application deployment disaster recovery module includes: an automatic pipeline execution unit, which is used to traverse each node of the topology structure in sequence based on the metadata of the business application and the topology structure stored in the software warehouse using a recursive algorithm, determine the serial or parallel logic and sequence from bottom to top according to the relationship between the nodes, construct a sequential pipeline of a directed acyclic graph, and automatically execute the sequential pipeline through a workflow engine to achieve the deployment, backup and data synchronization of the business application; a deployment resource automatic opening unit, which is used to call the resource service of the cloud platform based on the cloud resource access interface provided by the basic capability support layer, automatically apply for, create and activate the deployment unit and external dependencies of the business application, and create and set the cloud products required for the business application; a dependency injection and service discovery unit, which is used to perform dependency injection on the application instance of the business application according to the dependency; a software and data automatic disaster recovery unit, which is used to automatically back up the software and data of the business application from the primary node to one or more backup nodes according to the disaster recovery strategy after the business application is registered in the software application registration and orchestration module.

[0010] According to an embodiment of the present application, the fault monitoring and damage decision module includes: an information collection unit, which is used for status perception and information collection of each application instance in the business system, and collects status information of each application instance; a decision analysis unit, which is used to detect various types of anomalies in the status information, aggregate the anomalies, perform multi-level decision analysis on the anomalies based on a decision tree, and generate anomaly records of the business application; a fault monitoring unit, which is used to perform comprehensive fault judgment and damage judgment on the anomaly records based on the configured multiple fault judgment rules, and generate the alarm notification when the status is judged to be faulty or damaged.

[0011] According to an embodiment of the present application, the system recovery disaster recovery switching module includes: a preparation and inspection unit, which is used to respond to the alarm notification, check whether the status of the master node and the backup node meets the conditions for disaster recovery according to the registration information and topology structure of the software warehouse, and perform disaster recovery preparation; an application disaster recovery strategy selection and monitoring unit, which is used to select a disaster recovery strategy based on the status of the master node or the backup node, execute the system recovery operation and monitor the recovery status based on the disaster recovery strategy, and upgrade the disaster recovery strategy when the recovery status is abnormal, and execute the system recovery operation again until the system recovery operation is completed. The disaster recovery strategy includes local restart strategy, local reconstruction strategy and off-site reconstruction strategy in order of priority from high to low; a system recovery judgment unit, which is used to determine whether the business application of the business system has recovered successfully; a disaster recovery switching unit, which is used to execute the redirection operation of the upstream data traffic and business access entrance of the business application when the business application recovers successfully, and restore the business access of the business application.

[0012] According to an embodiment of the present application, the application disaster recovery strategy selection and monitoring unit includes: a strategy selection subunit, which is used to confirm and select one of the local restart strategy, the local reconstruction strategy and the off-site reconstruction strategy in sequence according to priority to enter the next subunit; a local restart strategy monitoring subunit, which is used to execute the local restart task on the master node and monitor the task status when the disaster recovery strategy is the local restart strategy, and re-execute the local restart task when the local restart task fails to execute until the restart number is reached; a local reconstruction strategy monitoring subunit, which is used to execute the local reconstruction task on the master node and monitor the task status when the disaster recovery strategy is the local reconstruction strategy or the local restart task reaches the restart number, and re-execute the local reconstruction task when the local reconstruction task fails to execute until the reconstruction number is reached; an off-site reconstruction strategy monitoring subunit, which is used to execute the off-site reconstruction task on the standby node and monitor the task status when the disaster recovery strategy is the off-site reconstruction strategy or the local reconstruction task reaches the reconstruction number, and re-execute the off-site reconstruction task when the off-site reconstruction task fails to execute until the reconstruction number is reached. A second aspect of the present application provides a cloud computing-based business system disaster recovery method, which is applied to the cloud computing-based business system disaster recovery system according to any one of the first aspects, comprising: sorting out entity objects in the business system and the dependency relationships between entity objects according to business applications, wherein the entity objects include software products, external dependencies, deployment units, and application instances of the business applications; Registering the entity objects of the business applications in a software warehouse and uploading the entity files of the entity objects, arranging the topology of the business system according to the dependency relationships, and configuring the disaster recovery strategy required by the business system, wherein the entity files include deployment packages, script files, image files, configuration files, and databases; after the business applications in the business system are registered, all application instances in the business system are automatically deployed and pulled up on the primary node, and the software and data of each business application are synchronously backed up to at least one backup node according to the disaster recovery strategy; performing status collection, fault monitoring, and damage decision analysis on each application instance of the business system, and issuing an alarm notification when a fault or disaster is detected; upon receiving the alarm notification, executing a system recovery operation of the business application on the primary node or the backup node according to the disaster recovery strategy, and after the recovery is completed, redirecting upstream data traffic and business access portals by configuring external access portal information of the business system to achieve system reorganization recovery and business disaster recovery switching, wherein the system recovery operation includes restoring the business system according to the topology of the business system, the registration information of the software warehouse, and the entity files.

[0013] Another aspect of the present application provides an electronic device, comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method described above.

[0014] Another aspect of the present application provides a computer-readable storage medium storing computer-executable instructions, which are used to implement the method described above when executed.

[0015] The embodiments of the present application provide a cloud computing-based business system disaster recovery system and method, which supports the overall local / remote disaster recovery of software applications in virtual machines, containers, and bare metal instances distributed on the cloud platform; supports the automatic creation of application deployment resources through dynamic scheduling of cloud platform computing, storage, network, and middleware services and other resources, and completely rebuilds and restores the service capabilities of software applications starting from the software's operating environment; thereby enabling the implementation of various fault recovery methods such as local restart, local reconstruction, and remote reconstruction based on the backed-up software applications. In the event of abnormal failure or damage to the cloud node of the aerospace remote sensing ground system, based on the implementation of this solution, it is possible to quickly restore business locally or remotely, realize application recovery and service replacement, and ensure the normal operation of the aerospace remote sensing ground system. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The above and other objects, features and advantages of the present application will become more apparent through the following description of the embodiments of the present application with reference to the accompanying drawings, in which:

[0017] Figure 1 This diagram schematically illustrates a typical "two-site, three-center" disaster recovery solution.

[0018] Figure 2 The following schematically illustrates the overall layered architecture of a cloud computing-based business system disaster recovery system provided in accordance with an embodiment of the present application;

[0019] Figure 3 The following schematically illustrates a block diagram of a cloud computing-based business system disaster recovery system according to an embodiment of the present application;

[0020] Figure 4 Schematically shows a logical structure diagram of a business system topology orchestration model according to an embodiment of the present application;

[0021] Figure 5 A schematic diagram of domain name access redirection according to an embodiment of the present application is shown;

[0022] Figure 6 Schematically shows a schematic diagram of access entry redirection in a load balancing manner according to another embodiment of the present application;

[0023] Figure 7 The following schematically illustrates an application diagram of a business system disaster recovery system based on cloud computing provided in accordance with an embodiment of the present application;

[0024] Figure 8 A flowchart of a cloud computing-based business system disaster recovery method according to an embodiment of the present application is schematically shown;

[0025] Figure 9 The following schematically illustrates a logic diagram of the application topology structure of the pre-processing subsystem of the aerospace remote sensing ground system provided in an embodiment of the present application;

[0026] Figure 10 Schematically shows the orbit calculation application arrangement diagram of the task control subsystem provided in an embodiment of the present application;

[0027] Figure 11 The following schematically illustrates a flow chart of fault monitoring and damage decision-making provided by an embodiment of the present application;

[0028] Figure 12 Schematic diagram of the system recovery and disaster recovery switching flow provided by the embodiment of the present application

[0029] Figure 13 A block diagram of an electronic device 1300 suitable for implementing a cloud computing-based business system disaster recovery system according to an embodiment of the present application is schematically shown. DETAILED DESCRIPTION

[0030] Hereinafter, embodiments of the present application will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present application. In the detailed description below, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present application. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of known structures and technologies are omitted to avoid unnecessarily confusing the concepts of the present application.

[0031] The terms used herein are only for describing specific embodiments and are not intended to limit this application. The terms "comprise," "include," etc. used herein indicate the presence of the features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0032] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification and should not be interpreted in an idealized or overly rigid manner.

[0033] When expressions such as "at least one of A, B, and C, etc." are used, they should generally be interpreted in accordance with the meaning commonly understood by those skilled in the art (for example, "a system having at least one of A, B, and C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.).

[0034] To achieve disaster recovery of the entire business system, we must first take the business system as the object, be able to clearly describe the business system to be disaster recovered, and build the business system metadata, including its business applications, software composition, service and data dependencies, deployment form, resource requirements, topology structure and disaster recovery strategy requirements; secondly, based on the metadata of the business system, we can manage the entire life cycle of instances such as software units, deployment units, services and data dependencies involved in various applications of the business system, including registration, update, version management, offline and synchronization, backup, recovery, etc.; thirdly, based on the metadata of the business system and disaster recovery strategy, we can quickly deploy and pull up the business system to be disaster recovered on multiple cloud platforms on demand; thirdly, we can perceive and monitor the operating status of the business application system, and in the event of a failure or disaster, provide fault identification and damage decision support, and automatically trigger disaster recovery tasks; finally, we can achieve rapid disaster recovery switching of the business system and realize rapid business succession and recovery.

[0035] Figure 2 The overall layered architecture diagram of a business system disaster recovery system based on cloud computing provided in accordance with an embodiment of the present application is schematically shown.

[0036] like Figure 2 As shown, in the embodiment of this application, the overall layered architecture of the business system disaster recovery system includes a cloud foundation platform layer, a basic capability support layer, a business system layer, and a disaster recovery service layer. The cloud foundation platform layer primarily provides various cloud platforms with resources and services such as computing, storage, networking, and middleware services for upper-layer business systems, and is the infrastructure layer that supports the disaster recovery system of this solution.

[0037] The basic capability support layer is a capability abstraction layer defined to achieve cloud platform independence. It abstracts the common support capabilities required for disaster recovery services, such as identity authentication and authorization, cloud resource access interfaces, data synchronization and backup, and cloud status monitoring. It defines a set of abstract service interfaces for access by upper-layer disaster recovery services, which are then implemented on demand for each cloud platform in the cloud foundation layer. Through the basic capability support layer, the cloud computing-based business system disaster recovery system provided in the embodiments of this application can be independent of specific cloud platforms, achieving support for heterogeneous cloud platforms.

[0038] The business system layer is the service object of the cloud computing-based business system disaster recovery system provided in the embodiment of this application. It is a collection of cloud-based business applications that undertake actual business based on the cloud platform. The business system layer must include static metadata describing the business system and its components and business system application instances that are dynamically deployed and pulled up based on the metadata. In the embodiment of this application, constructing a metadata model that describes the business system and its components, and dynamically creating application instances based on the metadata model are the core content of this solution.

[0039] The disaster recovery service layer calls the cloud platform and basic capability support layer based on user needs and instructions to implement the various service components of the disaster recovery process for the business system, including software application registration orchestration, software application deployment disaster recovery, fault monitoring and damage decision support, system recovery and disaster recovery switching and other software modules.

[0040] Figure 3 The following schematically shows a block diagram of a cloud computing-based business system disaster recovery system according to an embodiment of the present application.

[0041] like Figure 3 As shown, the cloud computing-based business system disaster recovery system 300 provided by the embodiment of the present application includes: a software application registration and orchestration module 310, a software application deployment disaster recovery module 320, a fault detection and damage decision module 330 and a system recovery disaster recovery switching module 340. Figures 3 to 7 The functions of each component of the system are described in detail.

[0042] To describe the composition and topology of business systems, this application draws on and adheres to the Topology and Orchestration Specification for Cloud Applications (TOSCA) developed by the OASIS (Organization for the Advancement of Structured Information Standards) organization to build and implement a topology orchestration model for aerospace remote sensing ground business systems. Following the TOSCA specification, this solution describes the static structure of cloud applications using two basic concepts: nodes and relationships. Nodes describe application software or resource objects, while relationships describe the dependencies or connections between application components.

[0043] For nodes, this solution defines node types such as business systems, business applications, deployment units, external dependencies, and software products (including basic software, business software, and business images) to represent model entity objects. The definitions of various model objects are described as follows:

[0044] (1) Basic software: refers to common components such as basic class libraries, system tools or development frameworks that support the operation of business software and provide a basic dependency environment, such as JDK, Python, Nginx, Tomcat, NFS client, FTP tools, etc., which are usually provided in the form of installation packages in business systems;

[0045] (2) Business software: application software that completes business functions, usually provided in the form of deployment packages. The attributes of business software include: basic information, deployment packages, deployment scripts, etc., and it relies on deployment units to complete deployment and operation;

[0046] (3) Business image: Business software in the form of an image, including a virtual machine image or a container image, is formed by the business system encapsulating the business application software and its dependent environment on the basis of the general basic image of the cloud platform. Deployment units can be created based on the business image to complete the deployment and operation of the business software;

[0047] (4) External dependencies: mainly refer to data dependencies such as stateful databases, message queues, NAS shared storage, and OSS object storage in cloud applications. Business systems rely on mature middleware services on external cloud platforms to create, bind, and manage these dependencies, helping business applications quickly inject and access data dependencies.

[0048] (5) Deployment unit: refers to the resource entity such as virtual machine, bare metal, container, etc. on the cloud platform that carries business software. It is the smallest entity unit for cloud application deployment and operation and the atomic resource object for performing deployment operations;

[0049] (6) Business application: referred to as "application", refers to a business function application that can survive and run independently and provide business services to the outside world. Business application is a self-contained collection that can complete a business in a certain field. The collection includes all software services and data required by the business. Business application consists of deployment units and external dependencies that are closely related and coordinated with each other. In this solution, business application is the smallest unit for registration orchestration, deployment disaster recovery, fault monitoring and disaster recovery, and switching;

[0050] (7) Business system: refers to a business system that undertakes complete and independent business functions in a business area. It is usually a subsystem or subsystem of a complex large system and is the basic unit for development, operation and disaster recovery. A business system usually includes one or more business applications that work together. For example, in aerospace remote sensing ground systems, it usually includes business systems such as data reception, data preprocessing, task control, professional processing, and big data.

[0051] For relationships, this solution defines relationship types such as "HostedOn", "DependsOn", "ConnectsTo", and "BelongTo", and extends the "CopyOf" type to represent the relationship between multiple copies in a cluster or load balancing. The types of nodes and relationships in this model can be continuously refined and derived as needed, thus having the ability to describe complex business systems. Through these nodes and relationships, this solution constructs a business system topology orchestration model, whose logical structure is as follows: Figure 4 shown.

[0052] Figure 4 The following schematically shows a logical structure diagram of a business system topology orchestration model according to an embodiment of the present application.

[0053] like Figure 4 As shown, the business system topology orchestration model represents the business system as a hierarchical topology diagram with a tree structure, wherein the nodes of the hierarchical topology diagram represent entity objects, and the connecting lines between the nodes represent the dependency relationships between entity objects. In addition, some attributes and operations can be defined on demand for the nodes and lines in the topology diagram, representing the functional characteristics and management operations of the node or line, which are used to automatically restore the business system in the system recovery operation. The attributes of the node can include the registration information of the entity object in the software warehouse, and the connecting lines define the operations between the nodes on demand. For example: for the "business software" node, its deployment package, deployment script, start and stop script, operating environment, resource requirements and other attributes can be defined, and operations such as deployment, uninstallation, backup and version update can be defined. This gives each element in the topology diagram the ability to automatically manage, laying a solid foundation for subsequent automatic deployment and disaster recovery.

[0054] In the embodiment of the present application, a lightweight JSON format file can be used to describe the model structure for subsequent model data exchange and persistence. For example, the following data structure:

[0055] {

[0056] "name": "XXX Business System",

[0057] "type": "BusinessSystem",

[0058] "id": "1823978377232048921"

[0059] "apps" [

[0060] { "name": "XXX business application",

[0061] "type": "Application",

[0062] "id": "1823978377232048001"

[0063] "nodeList": [

[0064] {

[0065] "name": "bds-server",

[0066] "nodeType": "ecs",

[0067] "id": "1822922174259363842",

[0068] "cpuType": "KP",

[0069] "deployEnv": "aliyun",

[0070] "deployType": "virtual machine",

[0071] "osType": "Linux",

[0072] "packageType": "package",

[0073] "region": "bjcc",

[0074] "replicas": 1,

[0075] }

[0076] ],

[0077] "relationList": [

[0078] {

[0079] "from": "1823977899907670018",

[0080] "to": "1822922174259363842",

[0081] "type": "HostedOn"

[0082] },

[0083] {

[0084] "from": "1823977899907670018",

[0085] "to": "1822922541084803073",

[0086] "type": "ConnectsTo"

[0087] } ]

[0089] }

[0090] This model description file enables the orchestration, presentation, transmission, persistence, and version iteration of the topology of the cloud-based business system.

[0091] In an embodiment of the present application, in order to realize the unified registration management, version maintenance, disaster recovery strategy configuration and backup and recovery functions of business systems, business applications, and their basic software, business software, business images and other software products and deployment units, external dependencies, a software application registration and orchestration module 310 is designed. The software application registration and orchestration module 310 is used to register the entity objects of each business application in the business system to the software warehouse, upload the entity files of the entity objects, arrange the topology of the business system according to the dependency relationship, and configure the disaster recovery strategy required by the business system. The entity objects include the software products, external dependencies, deployment units and application instances of the business applications, and the entity files include deployment packages, scripts and images. The software application registration and orchestration module 310 can generate metadata for the business system and its various components, including structured attribute data, topology model files, and unstructured deployment packages, scripts and images and other entity files, which are saved in the relational database, object storage and image warehouse of the cloud platform respectively. Together, they constitute a software warehouse for unified management of various software applications of the business system. The application's disaster recovery strategy is a predefined disaster recovery strategy for sudden system failures and disasters, so that when an emergency occurs, corresponding disaster recovery backup, survival monitoring, failure and damage judgment, system recovery and other strategies can be executed according to the level and importance of the application.

[0092] The software application registration and orchestration module 310 may specifically include software sub-modules such as software product management, deployment unit management, external dependency management, application registration and orchestration, and application disaster recovery configuration. Among them, the software product management sub-module is used to implement operations such as registration, editing, version update, and offline (logical deletion) of basic software, business software, and business images, and manage the basic information, deployment packages, image files, deployment scripts, start and stop scripts, etc. of each software or image; the deployment unit management sub-module is used to implement functions such as registration, editing, version update, specification adjustment, and deletion of bare metal, virtual machines, containers, and other deployment units of cloud business applications, and supports the management of attributes such as the name, version, deployment type, resource requirements (CPU, memory, disk, network), image identifier, and number of copies of the deployment unit; the external dependency management sub-module is used to implement the relational database, in-memory database, message queue, registration discovery center, OSS object storage, N It supports registration, editing, querying, binding, and unbinding management operations for external dependencies such as AS storage, and supports the management of scripts or configuration parameters such as creation and initialization. The application registration and orchestration submodule is used to provide registration management and topology orchestration functions for business applications, and supports the management and maintenance of basic information such as application name, identification, version, business system, level, and importance. It provides a graphical topology structure orchestration interface, which can intuitively orchestrate the application topology structure in a graphical drag-and-drop manner. The application disaster recovery configuration submodule is used to configure and manage business application disaster recovery strategies, including the application's disaster recovery targets, disaster recovery areas, backup strategies, survival monitoring strategies, disaster recovery recovery strategies, etc., and formulate plans for the synchronization, backup, and recovery of software and data in disaster recovery applications.

[0093] In an embodiment of the present application, a software application deployment disaster recovery component is designed to achieve automated deployment, startup, and disaster recovery for each business application registered in the business system within the software repository. The software application deployment disaster recovery module 320 is used to automatically deploy and startup all application instances within the business system on the primary node after the business application is registered within the business system, and to synchronously back up the entity objects and entity files of each business application to at least one backup node according to the disaster recovery strategy. Specifically, the software application deployment disaster recovery module 320 includes an automatic pipeline execution unit, an automatic deployment resource creation unit, a dependency injection and service discovery unit, and an automatic software and data disaster recovery unit.

[0094] The automated pipeline execution unit analyzes the application topology based on the metadata and topology of business applications stored in the software repository. Using a recursive algorithm, it sequentially traverses each node in the topology, determining serial or parallel logic and precedence based on the relationships between nodes from the bottom up. This constructs a sequential pipeline in a directed acyclic graph (DAG). This sequential pipeline is then automatically executed by the workflow engine. By combining the attributes and operations defined for each node and line in the model, deploying disaster recovery components enables automated operations such as business application deployment, backup, and data synchronization in a pipelined manner.

[0095] The automatic resource provisioning unit, based on the cloud resource access interface provided by the foundational capability support layer, calls upon the computing, storage, networking, and middleware resources provided by the cloud platform. This unit automatically applies for, creates, and activates deployment units and external dependencies for business applications, and creates and configures the security groups, VPCs, DNS, SLB, EIP, and other cloud products required by business applications. With the automated pipeline execution unit, the entire deployment process of business systems can be fully automated.

[0096] The dependency injection and service discovery units are used to perform dependency injection on application instances of business applications based on dependencies, and to implement service registration, publishing, and mutual discovery through the registration and discovery center provided by the cloud platform.

[0097] Dependencies exist between software deployment units within a business application, typically requiring the dependent to perform operations such as data transmission, API calls, and command issuance. To access these dependencies, deployment units must be able to access their dependencies using specific access locations (such as IP addresses and domain names). Traditionally, in manual software deployment, software deployers manually record the IP addresses and domain names of each deployment unit and configure them in configuration files, environment variables, or startup parameters for the dependent software, enabling mutual discovery and addressing among deployment units. However, in automated deployment scenarios, mechanisms are needed to ensure that software deployment units can automatically discover the deployment locations of their dependent units, effectively implementing dependency injection and automated mutual discovery. To this end, this solution supports dependency injection during automated business application deployment, establishing dependencies between software deployment units and between them through methods such as environment variable injection, external configuration files, and dynamic binding of domain names, SLBs, or EIPs. Furthermore, it supports service registration, publishing, and mutual discovery through the cloud platform's registration and discovery center.

[0098] Environment variable injection primarily targets deployment units such as virtual machines, bare metal machines, and containers. It implements dependency injection by dynamically setting environment variables at the operating system level. When a deployment unit starts, the location information of all other deployment units it depends on is automatically injected into the deployment unit's operating system environment variables. Applications launched within that deployment unit can then obtain the specific addresses of their dependencies by reading these operating system environment variables.

[0099] External configuration files mainly refer to configuration files required for application software runtime, which are specified or mounted separately outside the deployment package or image, so that the dependency access address can be dynamically configured during deployment, and then the configuration files are specified or mounted at startup to implement dependency injection.

[0100] Dynamic binding of a domain name, SLB, or EIP means configuring access methods such as a domain name, SLB, or EIP when registering an application or deployment unit, providing a constant external access point. This allows the application or deployment unit to maintain the same domain name, SLB, or EIP regardless of where or when the instance is launched. Dependent software or deployment units can access the instance through the domain name, SLB, or EIP. This enables dependency injection and mutual discovery.

[0101] The registration discovery center refers to the use of common microservice governance tools and registration discovery frameworks (such as Nacos and Euraka) provided by the cloud platform. After the software or deployment unit is started, its access address and port information are automatically registered with the service registration discovery center. All software that depends on it can automatically discover the access location of the dependency through the registration discovery center.

[0102] The software and data automatic disaster recovery unit is used to automatically back up the software and data of the business application from the main node to one or more backup nodes according to the disaster recovery strategy after the business application is registered in the software application registration and orchestration module 310. The disaster recovery backup of the business system is first of all the disaster recovery backup of various software and applications. In this solution, after the application registration is completed, the disaster recovery pipeline is immediately initiated to perform synchronization and backup operations of applications and software (including images, deployment packages, scripts, etc.) according to the configured backup strategy. The metadata of the application, deployment unit, software, and its images, deployment packages, scripts, initialization parameters, etc. are automatically backed up from the main node to one or more backup nodes. The synchronous backup of software applications can be achieved by utilizing the API interfaces of the cloud platform's efficient file transfer, OSS object storage, image warehouse, etc., and supports a variety of automated backup strategies that are regular or event-driven (such as version updates).

[0103] Disaster recovery for business systems requires not only disaster recovery for software application executables or software images, but also for the underlying data and configuration parameters upon which the software applications depend. Furthermore, to ensure continued business continuity after the application is launched, the software application must be able to access existing data, state, or replicas. The data that software applications rely on typically resides in external dependencies such as databases (relational or non-relational), file storage, message queues, or registry discovery centers. Therefore, disaster recovery for business system data is primarily achieved through disaster recovery for these external dependencies. This can be achieved through the cloud platform's Data Transfer Service (DTS) and Database Backup Service (DBS).

[0104] Disaster recovery services need to be able to sense and monitor the operating status of the business system, and in the event of a fault or disaster, be able to provide fault identification and damage decision support, and automatically trigger disaster recovery tasks. In an embodiment of the present application, the fault monitoring and damage decision module 330 is used to collect status, monitor faults, and analyze damage decisions for each application instance of the business system, and issue an alarm notification when a fault or disaster is detected. Regular health check tasks can be automatically triggered by a timer, and the health check interfaces of various hierarchical objects such as various software, deployment units, and external dependencies can be called regularly for each business application; then, various types of collected data can be automatically aggregated, and based on predefined fault identification rules and damage decision analysis algorithms, the occurrence of application faults or disaster damage can be perceived at the first time, and fault identification or damage decisions can be automatically and intelligently implemented; and alarm notifications can be issued in a timely manner for faulty or damaged applications, automatically triggering or assisting disaster recovery management personnel in making decisions on fault recovery disposal.

[0105] Specifically, the fault monitoring and damage decision module 330 may include an information collection unit, a decision analysis unit, and a fault monitoring unit. The workflow of the fault monitoring and damage decision module 330 may refer to Figure 11 .

[0106] The information collection unit is used to monitor and collect information about the status of each application instance in the business system. This information is collected from each application instance. Comprehensive and efficient information collection on the operational status, resource usage, and workload of business applications can be achieved by deploying software probes, collecting status information from various cloud platform products, and monitoring health check interfaces for business application software registrations. Software probes non-invasively monitor software processes within deployment units, automatically obtaining instance process IDs from software registration information. This provides detailed information on the software instance's operational status, including real-time status such as CPU usage, memory usage, storage usage, and network traffic, as well as detailed information such as the software process's status, stack, garbage collection, context switches, out-of-memory (OOM) occurrences, and I / O load (read / write speed, IOPS). Software probes also support on-demand customization through the integration of shell commands, custom scripts, and custom business metrics. Custom probes can be used to collect information such as business application operation logs, exception logs, and workload information. Software probes are deployed and started alongside other software in the automated deployment pipeline when the deployment unit is deployed. Cloud product status collection involves invoking the APIs or commands of cloud products such as virtual machines, containers, bare metal, databases, message queues, and NAS storage on the cloud platform. This information is collected to determine the health status of the application's deployment unit instances, external dependency instances, and other operational environments. This includes information on resource usage, margins, and real-time load for CPU, memory, disk, and network resources, as well as information on whether the operating system and middleware services are experiencing suspended animation. Business software health checks automatically obtain the health status of each business software by invoking the health check interface provided during business software registration, providing a more accurate picture of the business health of each software.

[0107] The decision analysis unit is used to detect various types of anomalies in the status information, aggregate the anomalies, perform multi-level decision analysis on the anomalies based on the decision tree, and generate anomaly records for business applications.

[0108] The fault monitoring unit is used to perform comprehensive fault and damage judgment on abnormal records based on the configured multiple fault judgment rules, and generate an alarm notification when the judgment status is fault or damage.

[0109] In this embodiment, anomaly detection is performed on various aggregated status information using methods such as resource anomaly detection models, log anomaly detection models, comprehensive application status analysis, and decision tree-based decision analysis. Judgments and decisions are then made based on configured fault identification rules and damage decision criteria. This solution supports the configuration of multiple fault identification rules (including timeouts, retries, resource thresholds, anomaly levels, and number of anomalies).

[0110] When a failure or damage is detected, the disaster recovery service automatically initiates the recovery process based on the disaster recovery strategy, or allows business users to manually initiate precise processing. After system recovery is complete, upstream data flows and business access points are redirected to achieve disaster recovery of business systems and business access.

[0111] In an embodiment of the present application, the system recovery and disaster recovery switching module 340 is used to perform system recovery operations of business applications on the primary node or the backup node according to the disaster recovery strategy when an alarm notification is received, and after the recovery is completed, the upstream data traffic and business access entry are redirected by configuring the external access entry information of the business system to achieve business reorganization recovery and disaster recovery switching. The system recovery operation includes automatically restoring the business system according to the logical topology model of the business system and the topological structure of each business application, the registration information of the software warehouse, and the physical files.

[0112] In an embodiment of the present application, the system recovery disaster recovery switching module 340 supports an automatic recovery mode. In this mode, the system recovery module will first attempt a local restart strategy based on the disaster recovery recovery strategy. If the restart is successful, the business software will resume normal use. If the restart is not successful within the number of restart attempts configured in the disaster recovery strategy, the reconstruction recovery strategy will be entered. According to the configured reconstruction strategy, reconstruction will be attempted locally first. If reconstruction is still not successful within the configured number of attempts, remote reorganization, reconstruction, and pull-up operations will be performed according to the backup area configured for the business system. After waiting for a successful remote pull-up, the user can verify the restoration of normal access to the business software.

[0113] In an embodiment of the present application, the system recovery disaster recovery switching module 340 also supports a manual recovery mode. When a business user or disaster recovery administrator receives a fault or damage alarm, he or she can choose to restart or rebuild the specified version of the business system in a suitable backup area (local node, remote node) as needed. In addition, the system recovery strategy can be refined as needed to achieve system reorganization and reconstruction, such as: only rebuilding part of the business applications in the business system, configuring the resource scale of the backup area business system, and utilizing the elastic scaling capabilities of the cloud to achieve rapid system recovery and efficient and full use of resources.

[0114] Specifically, the system recovery disaster recovery switching module 340 includes: a preparation and inspection unit, an application disaster recovery strategy selection and monitoring unit, a system recovery determination unit and a disaster recovery switching unit. The workflow of this module can be referred to Figure 12 .

[0115] The preparation and inspection unit responds to alert notifications and, based on the software repository's registration information and topology, checks whether the status of the primary and backup nodes meets the requirements for disaster recovery, and then prepares for disaster recovery. Upon receiving a notification of a business application failure or corruption and initiating the system recovery process, the unit first checks the status of the current and backup nodes based on the application's registration information and topology model to see if they meet the requirements. It then performs preparatory tasks such as preparing backup versions, confirming resource quotas, and checking disaster recovery policies. It also verifies that all required files or images are complete and that the backup node has sufficient resources.

[0116] The application disaster recovery strategy selection and monitoring unit is used to select a disaster recovery strategy based on the status of the master node or the backup node, execute system recovery operations based on the disaster recovery strategy and monitor the recovery status, and upgrade the disaster recovery strategy when the recovery status is abnormal, and execute the system recovery operation again until the system recovery operation is completed. The disaster recovery strategy includes local restart strategy, local reconstruction strategy and off-site reconstruction strategy in order of priority from high to low.

[0117] The application disaster recovery strategy selection and monitoring unit includes a strategy selection subunit, a local restart strategy monitoring subunit, a local reconstruction strategy monitoring subunit, and a remote reconstruction strategy monitoring subunit.

[0118] The strategy selection subunit is used to confirm and select one of the local restart strategy, the local reconstruction strategy and the remote reconstruction strategy according to the priority to enter the next subunit;

[0119] The local restart strategy monitoring subunit is used for executing the local restart task on the master node and monitoring the task status when the disaster recovery strategy is the local restart strategy, and re-executing the local restart task when the local restart task fails until the restart count is reached;

[0120] The local reconstruction strategy monitoring subunit is used to execute the local reconstruction task on the master node and monitor the task status when the disaster recovery strategy is the local reconstruction strategy or the local restart task reaches the restart count, and when the local reconstruction task fails, re-execute the local reconstruction task until the reconstruction count is reached;

[0121] The off-site reconstruction strategy monitoring subunit is used to execute the off-site reconstruction task on the standby node and monitor the task status when the disaster recovery strategy is an off-site reconstruction strategy or the local reconstruction task reaches the reconstruction number. When the off-site reconstruction task fails to execute, the off-site reconstruction task is re-executed until the reconstruction number is reached.

[0122] The system recovery determination unit is used to determine whether the business applications of the business system have been successfully restored. If successful, the system will enter disaster recovery switchover. If failed, the system will return to the disaster recovery preparation and inspection steps and start the next round of operations again.

[0123] The disaster recovery switching unit is used to execute the redirection operation of the upstream data traffic and business access entrance of the business application when the business application is successfully restored, so as to restore the business access of the business application.

[0124] Considering the extensive dependencies and call relationships between business applications, disaster recovery services must ensure that the access portals for locally or remotely recovered business system applications remain unchanged. This ensures that disaster recovery operations are as transparent to upstream businesses as possible and prevents chain reactions caused by specific software failures. Therefore, after the system recovers through local or remote reconstruction, upstream business requests are redirected to the newly launched application instance. This ensures that upstream callers can continue to access the application software without changing it after the failure has been recovered, thus ensuring business continuity.

[0125] After the system is restored, this solution supports disaster recovery switching of business applications through the configuration and switching of cloud product service information such as Domain Name Service (DNS), Load Balancing (SLB) and Elastic Public IP (EIP).

[0126] The DNS configuration switching method supports configuring application access portals through domain name resolution. After the system disaster recovery is restored, the disaster recovery switching module will automatically call the cloud platform domain name resolution service interface to point the domain name to the newly started application instance deployment IP. Upstream businesses only need to access the application through the domain name and can be redirected to the recovered application without making any changes.

[0127] For multiple instances of a software application deployed, domain name configuration is used. Different domain names are required for different instances. Different versions and replica instances of the same application can be configured using subdomains (for example, if the application's domain name is aaa.com, replica 1's domain name is e1.aaa.com, and replica 2's domain name is e2.aaa.com). However, the access addresses of different application instances or multiple instances of the same application must remain unchanged. Whether the application is launched locally or remotely, the domain name must remain unchanged. Even if the IP address changes, the domain name and IP address correspondence must be modified in DNS. For the domain names of different replica instances of the same application, each node in the system will be configured with a global domain name service, and disaster recovery across nodes is implemented using the global domain name.

[0128] Figure 5 A schematic diagram of domain name access entry redirection according to an embodiment of the present application is shown schematically.

[0129] like Figure 5 As shown, the domain name remains unchanged during front-end access. When a failure occurs, the disaster recovery strategy will be automatically executed for recovery. After recovery, the access address remains unchanged. Even if the IP changes, it will be bound to the current domain name through DNS.

[0130] The SLB configuration switching method supports configuration through the load balancing service method. After the system is reorganized and restored, the disaster recovery switching module will automatically call the cloud platform load balancing service related interface, remove the original service from the SLB backend service list, and add the newly launched application instance IP address to the load balancing service backend. Upstream businesses accessing the load balancing service instance address can be redirected to the recovered application without making any changes. For multiple different instances deployed for an application, if the access entry point is the SLB (load balancing) IP address, then the application instances will each have their own IP. When the instance is created, the SLB IP address should no longer change. Then, the global IP address is configured through GSLB, which can be accessed from all disaster recovery cloud nodes.

[0131] Figure 6 A schematic diagram of access entry redirection in a load balancing manner according to another embodiment of the present application is shown schematically.

[0132] like Figure 6 As shown in the figure, a forwarding policy is configured using an SLB (load balancing) to distribute user access requests to multiple services based on the forwarding policy. The system exposes the SLB's IP address and port number to the public, while the IP addresses and ports of internal services are not exposed. The SLB policy determines how requests are distributed and accessed. If an internal service fails, the SLB forwards the original request to another available internal service.

[0133] The EIP configuration switching method supports configuring application access portals through elastic IP services. After the application is reorganized and restored, the module will automatically call the EIP service-related interface of the cloud platform to bind the fixed IP address to the newly rebuilt application instance, ensuring that the upstream business access portal remains unchanged.

[0134] Figure 7 The application diagram of the business system disaster recovery system based on cloud computing provided in accordance with an embodiment of the present application is schematically shown.

[0135] like Figure 7 As shown, the "application instance" in the figure is an operational instance of a business system created, monitored, and protected by the business system disaster recovery system provided in the embodiments of this application. It can be regarded as the dynamic "data" generated by the disaster recovery system. The disaster recovery system is supported by a cloud-based platform, that is, it is deployed and operated on the cloud-based platform. It uses the adaptation of abstract service interfaces on the cloud platform to call various resources and services of the cloud platform. It is an indispensable foundational dependency environment for the disaster recovery system.

[0136] like Figure 7As shown in the figure, the software application registration and orchestration component is responsible for registering and saving various software applications of the business system to the software warehouse; the software application deployment and disaster recovery component extracts the metadata and physical files of the software application from the software warehouse, executes the automated pipeline, completes the automated deployment and disaster recovery backup of the application, and thus pulls up the application instance; the fault monitoring and damage decision component collects the status of the application instance, monitors anomalies and faults, and performs damage decision analysis; when it is determined that a fault or damage has occurred, it notifies the system recovery and disaster recovery switching to perform disaster recovery operations such as restart and reconstruction and business redirection.

[0137] To implement local or remote disaster recovery, the disaster recovery system in this solution is typically deployed on one or more cloud nodes (cloud infrastructure), each acting as a primary or backup node. The two nodes are interconnected and share resources. Disaster recovery components deployed in software applications can send and receive data between the two nodes, enabling synchronized backup of software repositories and business data. The system recovery modules on each node can perform remote reconstruction via the other, and application instances can establish active-standby or active-active relationships, with failover executed via the disaster recovery switchover module.

[0138] The primary and backup role positioning of different nodes is only a relative concept in logic. In fact, the two are in a peer-to-peer relationship and can serve as the primary and backup for each other, and can be distinguished and adjusted through corresponding configurations. For specific applications, the primary node is usually the node where business applications are registered and created and mainly undertake business, and the backup node is the node for disaster recovery, backup, and recovery of business applications. Depending on the disaster recovery mode, in cold standby mode, the backup node may not run application instances at ordinary times, but only backs up application metadata and physical files. Only when disaster recovery is required will the application instance be pulled up and the business traffic be taken. In hot standby mode, the backup node can run the smallest application instance at ordinary times and only take business traffic during disaster recovery. In multi-active mode, the backup node always maintains an appropriate scale of application instances and takes a certain proportion of business traffic. In both hot standby and multi-active modes, the application instances of the backup node can automatically perform elastic scaling as needed to restructure the application instance scale.

[0139] It should be pointed out that although Figure 7 This diagram only illustrates a two-node system, one active and one standby. In reality, this solution supports distributed deployment across multiple nodes, with one active and multiple standby nodes, and on-demand disaster recovery. Furthermore, the cloud infrastructure for the active and standby nodes in the diagram can be two relatively independent homogeneous or heterogeneous cloud platforms in different locations, or different availability zones within the same cloud platform. All that matters is network connectivity and sufficient resources to meet the needs of the business system.

[0140] Figure 8 The flowchart of the business system disaster recovery method based on cloud computing provided in accordance with an embodiment of the present application is schematically shown.

[0141] like Figure 8 As shown, the cloud computing-based business system disaster recovery method provided in the embodiment of the present application includes S810~S850.

[0142] S810 , sorting out entity objects in the business system and dependencies between entity objects according to business applications, and constructing a logical topology structure of the business system. The entity objects include software products, external dependencies, deployment units, and application instances of business applications.

[0143] In the embodiments of this application, the business system follows the business system topology orchestration model proposed in this solution to organize the business applications belonging to the system. For each business application, the system lists software artifacts such as basic software, business software, and business images. The system then determines the deployment form and resource requirements of each software component to form a deployment unit. Furthermore, the system combines external dependencies such as databases and message queues to determine the dependencies between the various components within the application, forming the topology of the business application. Furthermore, the system can determine the level, importance, and disaster recovery goals and strategies of the business application from a business perspective.

[0144] Taking the preprocessing subsystem of a space remote sensing ground system as an example, the preprocessing subsystem consists of two business applications: a business middleware and an algorithm plug-in set. The business middleware application includes backend software services such as interface processing software, process control services, resource scheduling services, processing node execution agent services, process order services, and process monitoring services. These software services are deployed as deployment packages on ECS cloud hosts. The preprocessing algorithm plug-in set includes algorithm plug-ins for cataloging, product production, and object detection. These plug-ins need to be deployed as deployment packages on bare metal servers. Some algorithm programs also rely on GPU cards and require basic libraries such as MKL, CUDA, and GDAL. The preprocessing business middleware and algorithm plug-in set also rely on NAS storage, the cloud database PolarDB-O, the cloud in-memory database Redis, and the cloud message queue MQ. Based on the analysis of these business models of the preprocessing subsystem, a logical diagram of the preprocessing subsystem application topology can be constructed.

[0145] Figure 9 The following schematically shows the application topology logic diagram of the aerospace remote sensing ground system preprocessing subsystem provided by the embodiment of the present application. Figure 9As shown, based on the application topology logical structure shown in the figure, basic information about each software and application in the pre-processing business system, as well as deployment packages, image files, script files, configuration files, and physical files such as database and message queue creation and initialization scripts, can be collected and organized, laying the foundation for the next step of registering and entering the software warehouse. Preferably, if conditions permit, the information of each of the above software products and their physical files such as deployment packages, images, and scripts can be automatically collected and packaged through the development and testing pipeline.

[0146] S820, register the entity objects of the business applications to the software warehouse and upload the entity files of the entity objects. Orchestrate the topology of the business system according to the dependency relationships and configure the disaster recovery strategy required by the business system. The entity files include deployment packages, script files, image files, configuration files, and databases.

[0147] In the embodiment of the present application, the software application registration and orchestration module is used to register the software artifacts (e.g., basic software, business software, business images, etc.) prepared in the previous step, as well as external dependencies, deployment units, and business application metadata, into the software repository. Physical files such as deployment packages, images, and scripts are uploaded, the application topology is orchestrated based on dependencies, and the disaster recovery strategy required by the application is configured. Preferably, if conditions permit, the software application registration and orchestration module can be integrated with the development and testing pipeline, automatically registering and uploading to the software repository through an interface.

[0148] Taking the orbit calculation application of the space remote sensing mission control subsystem as an example, the application topology orchestration diagram after registration is as follows: Figure 10 As shown, Figure 10 The diagram schematically shows the orbital computing application arrangement of the task control subsystem provided in an embodiment of the present application.

[0149] S830: After the business application registration in the business system is completed, all or part of the application instances in the business system are automatically deployed and launched on the master node, and the entity objects and entity files of each business application are synchronously backed up to at least one standby node according to the disaster recovery strategy.

[0150] In an embodiment of the present application, after the business system is registered, the disaster recovery module can be deployed through the software application. According to business needs, for the specified version of the business application, the automatic deployment pipeline can be initiated and executed with one click, so as to realize the one-click deployment and startup of the business system on the master node cloud platform. For the deployed and launched application instance, the disaster recovery pipeline is automatically initiated according to the application backup strategy, and the business application software (including images, deployment packages, scripts, etc.) and business data are synchronized and backed up to one or more backup nodes. For software, regular full backup and incremental backup based on events (version updates, development and test pipeline releases, etc.) are supported; for business data, cloud platform-based data transmission services (DTS) and data backup services (DBS) support full + incremental synchronization and backup. For physical data files in NAS storage or OSS object storage, efficient file transfer tools are used to synchronize and backup files between the primary and backup nodes, and support file size, MD5 and other verification.

[0151] S840 performs status collection, fault monitoring, and damage decision analysis on each application instance of the business system, and issues an alarm notification when a fault or disaster is detected.

[0152] In an embodiment of the present application, status information of each application instance of the business system is collected in real time, anomaly detection of operating status and survival status is carried out, decision analysis and fault / damage determination are performed, and when a fault or damage is determined, an alarm notification is issued to trigger subsequent disaster recovery operations.

[0153] Figure 11 The following schematically shows a flow chart of fault monitoring and damage decision-making provided by an embodiment of the present application. Figure 11 As shown, this step primarily consists of three steps: information collection, decision analysis, and fault / damage determination. These steps repeat periodically at regular intervals throughout the lifecycle of an application instance until the instance is terminated or uninstalled. In the information collection phase, the information collection module collects various status information through various means, including software probes, cloud platform product status, business software health checks, and various operation logs, and aggregates this information for the decision analysis module. In the decision analysis phase, various anomalies are automatically and intelligently detected through a comprehensive analysis of log anomaly detection models, resource anomaly detection models, and application health status. These anomalies are then aggregated and analyzed using a decision tree to perform multi-level anomaly decision analysis across the software, deployment unit, application, and business system layers, generating business application anomaly records. In the fault / damage determination phase, the anomaly records generated in the previous step are then subjected to fault determination based on various configured fault determination rules (including application timeout, retry count, resource threshold, anomaly level, and anomaly frequency). A comprehensive damage determination is then made based on these various anomalies. If a fault / damage is determined, an alarm notification is generated, triggering subsequent logic.

[0154] S850, when receiving an alarm notification, performs system recovery operations for business applications on the primary or backup node according to the disaster recovery strategy. After the recovery is completed, it redirects upstream data traffic and business access portals by configuring external access portal information such as DNS, SLB, and EIP of the business system, achieving continuous access to upstream businesses without perception after business reorganization and recovery, and realizing business disaster recovery switching and succession recovery.

[0155] Figure 12 The system recovery and disaster recovery switching flow chart provided in an embodiment of the present application is schematically shown.

[0156] like Figure 12 As shown, the specific process of S850 is described as follows: Upon receiving a notification of a business application failure or corruption and initiating the system recovery process, the system first checks the status of the current node and backup node based on the application registration information and topology to determine whether they meet the requirements for disaster recovery. It then performs preparatory tasks such as preparing backup versions, confirming resource quotas, and checking the disaster recovery policy. These tasks include verifying the completeness of the backup files or images and confirming sufficient resources on the backup node. The application's disaster recovery policy is then checked to determine whether a local restart is required. If so, the local restart recovery task is executed. If not, the system is evaluated for local reconstruction strategies. After the local restart task is executed, the system determines whether the task was successful. If so, the system is evaluated for recovery. If not, the task is executed again until the number of restarts has been reached. The application's disaster recovery policy is then checked to determine whether a local rebuild is required. If so, the system determines whether the task is successful. If not, the system is evaluated for remote rebuild strategies. When executing the local rebuild task, the application version to be rebuilt can be specified. After the task is completed, the system determines whether the task was successful. If so, the system is evaluated for recovery. If not, the task is executed again until the number of local rebuilds has been reached. Check the application disaster recovery strategy to determine whether an off-site reconstruction operation is required. If so, execute the off-site reconstruction recovery task. If not, terminate the process. When executing the off-site reconstruction task, you can specify the backup node to be restored and the rebuilt application version. After the task is completed, determine whether the task execution is successful. If successful, enter the system recovery judgment. If failed, execute again until the off-site reconstruction times are reached. The system recovery judgment step determines whether the application has been successfully restored based on the application survival monitoring and health check strategy. If successful, enter the disaster recovery switch. If failed, return to the disaster recovery preparation and inspection steps and re-execute the next round of operations. The disaster recovery switch step executes the business redirection operation of the current business application, completes the business handover, and restores business access.

[0157] It should be noted that the cloud computing-based business system disaster recovery method part in the embodiment of the present application corresponds to the cloud computing-based business system disaster recovery system part in the embodiment of the present application. The description of the cloud computing-based business system disaster recovery method part specifically refers to the cloud computing-based business system disaster recovery system part, which will not be repeated here.

[0158] The present application provides a cloud computing-based business system disaster recovery system and method having at least the following features and advantages:

[0159] First, a business system topology orchestration model was constructed. This solution adheres to the TOSCA standard and builds and implements a topology orchestration model for aerospace remote sensing ground business systems. Model entity objects are represented by defining node types such as business systems, business applications, deployment units, external dependencies, and software artifacts (including basic software, business software, and business images). Relationship types such as "runs on," "depends on," "connected to," "belongs to," and "copied to" are defined to represent relationships between model entity objects. This topology orchestration model lays a solid foundation for automated deployment, disaster recovery backup, and recovery in subsequent disaster recovery. Furthermore, this solution uses lightweight JSON-formatted files to describe the model structure for subsequent model data exchange, persistence, and version upgrades.

[0160] Second, based on the topology orchestration model structure, a software repository was designed to centrally manage software applications and implement a pipeline for automated application deployment, backup, and recovery. This solution, through the software application registration orchestration component, generates metadata for the business system and its components. This includes structured attribute data, topology model files, and unstructured physical files such as deployment packages, scripts, and images. These files are stored in the cloud platform's relational database, object storage, and image repository, collectively forming a software repository that centrally manages all software applications in the business system. This solution also includes a software application deployment disaster recovery component that automates the deployment, backup, and recovery of business applications in the software repository. It also supports dependency injection through environment variable injection, external configuration files, and dynamic binding of domain names, SLBs, or EIPs. It also supports service registration, publishing, and mutual discovery through a registration discovery center, resolving the challenge of configuration dependencies in automated deployment.

[0161] Third, a disaster recovery system was designed to cover the entire disaster recovery service process. This system includes four software components: software application registration and orchestration, software application deployment and disaster recovery, fault monitoring and damage decision-making, and system recovery and disaster recovery failover. This system also houses a software repository that stores software application metadata and physical files. By connecting to the cloud platform's application programming interface (API), this system automatically creates the cloud resources required for disaster recovery, enabling one-click backup, restore, and failover in the cloud. The system supports distributed deployment across multiple nodes, enabling single-master and multiple-backup systems across nodes for on-demand disaster recovery. Across multiple nodes, it supports cold, hot, and active-active disaster recovery modes. In particular, the cold backup mode significantly improves recovery automation, reduces recovery difficulty and complexity, and offers high practicality.

[0162] Fourth, a full-lifecycle fault monitoring and damage decision-making method was designed. This method collects real-time status information from each application instance in the business system, detects anomalies in both operational and survival states, and performs decision analysis and fault / damage determination. When a fault or damage is detected, an alarm notification is issued, triggering subsequent disaster recovery operations. This solution achieves comprehensive and efficient collection of information on the operational status, resource usage, and workload of business applications by deploying software probes, collecting status information from various cloud platform products, and monitoring health check interfaces registered with business application software. This aggregated state information is then used to detect anomalies using methods such as resource anomaly detection models, log anomaly detection algorithms, application state decision analysis, and a multi-level anomaly decision analysis based on decision trees. Fault / damage determinations and decisions are then made based on configured fault identification rules and damage decision criteria, demonstrating high reliability and practicality.

[0163] Fifth, an automated local / remote disaster recovery method has been designed, while also supporting manually controlled, precise disaster recovery reorganization and reconstruction. In automatic disaster recovery mode, this solution will first attempt a local restart strategy based on the disaster recovery strategy. If the restart is successful, the business software will resume normal use; if the restart fails, the reconstruction recovery strategy will be entered. According to the configured reconstruction strategy, local reconstruction will be attempted first. If the reconstruction is unsuccessful, remote reorganization, reconstruction, and pull-up operations will be performed based on the backup area configured for the business system. After waiting for a successful remote pull-up, users can verify that normal access to the restored business software is restored, and then perform disaster recovery switching. In this mode, the entire system recovery process can be automated and executed without human intervention. This solution also supports manual recovery mode. Disaster recovery administrators can restart or rebuild the specified version of the business system in the appropriate backup area (local or remote, one or more) as needed. They can also refine the system recovery strategy as needed to achieve system reorganization and reconstruction. For example, only rebuild some business applications in the business system; configure the instance resource scale of the business system in the backup area to utilize the elastic scaling capabilities of the cloud to achieve rapid system recovery and efficient use of resources; set up disaster recovery modes such as cold standby, hot standby, or multi-active between the primary and backup nodes.

[0164] Sixth, this solution supports multiple disaster recovery failover methods (SLB, DNS, EIP, etc.). After system recovery, this solution supports disaster recovery failover of business applications by configuring and switching cloud product service information such as Domain Name Service (DNS), Load Balancing (SLB), and Elastic Public IP (EIP). These failover methods enable rapid and seamless failover of upstream services, ensuring business continuity.

[0165] Figure 13 A block diagram of an electronic device suitable for implementing the method described above according to an embodiment of the present application is schematically shown. Figure 13 The electronic device shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0166] like Figure 13As shown, the electronic device 1300 according to an embodiment of the present application includes a processor 1301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1302 or a program loaded from a storage unit 1308 into a random access memory (RAM) 1303. The processor 1301 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or a related chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 1301 may also include onboard memory for caching purposes. The processor 1301 may include a single processing unit or multiple processing units for performing different actions of the method flow according to the embodiment of the present application.

[0167] Various programs and data required for the operation of the electronic device 1300 are stored in the RAM 1303. The processor 1301, the ROM 1302, and the RAM 1303 are connected to each other via a bus 1304. The processor 1301 performs various operations of the method flow according to the embodiment of the present application by executing the programs in the ROM 1302 and / or the RAM 1303. It should be noted that the programs may also be stored in one or more memories other than the ROM 1302 and the RAM 1303. The processor 1301 may also perform various operations of the method flow according to the embodiment of the present application by executing the programs stored in one or more memories.

[0168] According to an embodiment of the present application, electronic device 1300 may further include an input / output (I / O) interface 1305, which is also connected to bus 1304. Electronic device 1300 may also include one or more of the following components connected to I / O interface 1305: an input section 1306 including a keyboard, mouse, etc.; an output section 1307 including devices such as a cathode ray tube (CRT), liquid crystal display (LCD), and speakers; a storage section 1308 including a hard disk; and a communication section 1309 including a network interface card such as a LAN card or modem. Communication section 1309 performs communication processing via a network such as the Internet. A drive 1310 is also connected to I / O interface 1305 as needed. Removable media 1311, such as a magnetic disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed in drive 1310 as needed, so that computer programs read from the removable media can be installed into storage section 1308 as needed.

[0169] According to an embodiment of the present application, the method flow according to the embodiment of the present application can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable storage medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 1309, and / or installed from the removable medium 1311. When the computer program is executed by the processor 1301, the above-mentioned functions defined in the system of the embodiment of the present application are executed. According to an embodiment of the present application, the system, equipment, device, module, unit, etc. described above can be implemented by a computer program module.

[0170] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments, or may exist independently and not be incorporated into the device / apparatus / system. The computer-readable storage medium carries one or more programs, and when the one or more programs are executed, the method according to the embodiments of this application is implemented.

[0171] According to embodiments of the present application, a computer-readable storage medium may be a non-volatile computer-readable storage medium. Examples include, but are not limited to, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present application, a 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, apparatus, or device.

[0172] For example, according to an embodiment of the present application, the computer-readable storage medium may include the ROM 1302 and / or the RAM 1303 described above and / or one or more memories other than the ROM 1302 and the RAM 1303 .

[0173] An embodiment of the present application also includes a computer program product, which includes a computer program, which contains program code for executing the method provided by the embodiment of the present application. When the computer program product is run on an electronic device, the program code is used to enable the electronic device to implement the cloud computing-based business system disaster recovery method provided by the embodiment of the present application.

[0174] When the computer program is executed by the processor 1301, the above functions defined in the system / device of the embodiment of the present application are performed. According to the embodiment of the present application, the system, device, module, unit, etc. described above can be implemented by a computer program module.

[0175] In one embodiment, the computer program may be stored on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may be transmitted and distributed in the form of a signal over a network medium, downloaded and installed via the communication portion 1309, and / or installed from removable media 1311. The program code contained in the computer program may be transmitted using any appropriate network medium, including but not limited to wireless, wired, or any suitable combination thereof.

[0176] According to an embodiment of the present application, the program code for executing the computer program provided by the embodiment of the present application can be written in any combination of one or more programming languages. Specifically, these computer programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages include, but are not limited to, languages such as Java, C++, Python, "C" or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, using an Internet service provider to connect via the Internet).

[0177] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or part of the code, and the above-mentioned module, program segment, or part of the code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions. It will be understood by those skilled in the art that the features described in the various embodiments of the present application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in the present application. In particular, without departing from the spirit and guidance of the present application, the features described in the various embodiments of the present application may be combined and / or coupled in various ways, and all such combinations and / or couplings fall within the scope of the present application.

[0178] The embodiments of the present application have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of the present application. Although each embodiment has been described separately above, this does not mean that the measures in each embodiment cannot be advantageously used in combination. Without departing from the scope of the present application, those skilled in the art may make various substitutions and modifications, and these substitutions and modifications should all fall within the scope of the present application.

Claims

1. A cloud computing-based business system disaster recovery system, comprising: A software application registration and orchestration module is used to register the entity objects of each business application in the business system to the software repository, upload the entity files of the entity objects, orchestrate the topology of the business system according to the dependencies between the entity objects, and configure the disaster recovery strategy required by the business system. The entity objects include the software products, external dependencies, deployment units, and application instances of the business applications, and the entity files include deployment packages, scripts, and images. A software application deployment disaster recovery module is used to automatically deploy and pull up all application instances in the business system on the master node after the business application registration in the business system is completed, and synchronously back up the physical objects and physical files of each business application to at least one standby node according to the disaster recovery strategy; A fault monitoring and damage decision module is used to collect status, monitor faults, and make damage decision analysis for each application instance of the business system, and issue an alarm notification when a fault or disaster is detected; The system recovery and disaster recovery switching module is used to execute the system recovery operation of the business application on the primary node or the backup node according to the disaster recovery strategy when the alarm notification is received, and after the recovery is completed, redirect the upstream data traffic and business access entry by configuring the external access entry information of the business system to achieve business reorganization recovery and business disaster recovery switching; the system recovery operation includes automatically restoring the business system according to the topology structure of the business system, the registration information of the software warehouse and the physical file.

2. The cloud computing-based business system disaster recovery system according to claim 1, wherein the topology structure is defined based on a business system topology orchestration model, the nodes in the business system topology orchestration model represent the entity objects, the connecting lines between the nodes represent the dependency relationships between the entity objects, and the dependency relationships include the relationship types of "running on", "depending on", "connected to", "belongs to", and "copied of" between the entity objects, wherein: The relationship type "copy to" is used to represent the relationship between multiple copies in the cluster or load balancing in the business system; both the nodes and the connection lines support on-demand definition of attributes and operations, and the attributes and operations are used to automatically restore the business system in the system recovery operation.

3. The cloud computing-based business system disaster recovery system according to claim 1, wherein: The software application registration and orchestration module supports basic information management and maintenance of the business applications and provides a graphical topology structure orchestration interface.

4. The cloud computing-based business system disaster recovery system according to claim 2, wherein: The software application deployment disaster recovery module includes: An automatic pipeline execution unit is configured to use a recursive algorithm to sequentially traverse each node of the topology structure based on the metadata of the business application stored in the software warehouse and the topology structure, determine serial or parallel logic and precedence from bottom to top according to the relationship between the nodes, construct a sequential pipeline of a directed acyclic graph, and then automatically execute the sequential pipeline through a workflow engine; The deployment resource automatic opening unit, based on the cloud resource access interface provided by the basic capability support layer, calls the resource service of the cloud platform, automatically applies for, creates and activates the deployment unit and external dependencies of the business application, and creates and sets up the cloud products required for the business application; A dependency injection and service discovery unit, configured to perform dependency injection on the application instance of the business application according to the dependency relationship, and implement service registration, publishing, and mutual discovery through the registration and discovery center provided by the cloud platform; The software and data automatic disaster recovery unit is used to automatically back up the software and data of the business application from the primary node to one or more backup nodes according to the disaster recovery strategy after the business application is registered in the software application registration and orchestration module.

5. The cloud computing-based business system disaster recovery system according to claim 1, wherein: The fault monitoring and damage decision module includes: An information collection unit, configured to sense the status of each application instance in the business system and collect information about the status of each application instance; a decision analysis unit, configured to detect various types of anomalies in the state information, aggregate the anomalies, perform multi-level decision analysis on the anomalies based on a decision tree, and generate an anomaly record for the business application; The fault monitoring unit is used to perform comprehensive fault discrimination and damage discrimination on the abnormal record based on the configured multiple fault discrimination rules, and generate the alarm notification when the status is judged to be faulty or damaged.

6. The cloud computing-based business system disaster recovery system according to claim 1, wherein: The system recovery disaster recovery switching module includes: A preparation and inspection unit, configured to respond to the alarm notification, check whether the status of the primary node and the backup node meets the conditions for disaster recovery according to the registration information and topology of the software warehouse, and perform disaster recovery preparation; An application disaster recovery strategy selection and monitoring unit is configured to select a disaster recovery strategy based on the status of the master node or the backup node, execute the system recovery operation based on the disaster recovery strategy and monitor the recovery status, and upgrade the disaster recovery strategy when the recovery status is abnormal, execute the system recovery operation again, and complete the system recovery operation. The disaster recovery strategies include, in descending order of priority, a local restart strategy, a local reconstruction strategy, and a remote reconstruction strategy; A system recovery determination unit, configured to determine whether the business application of the business system has been successfully restored; The disaster recovery switching unit is used to execute the redirection operation of the upstream data traffic and the service access entrance of the business application when the business application is successfully restored, so as to restore the business access of the business application.

7. The cloud computing-based business system disaster recovery system according to claim 6, wherein: The application disaster recovery strategy selection and monitoring unit includes: A strategy selection subunit, configured to sequentially confirm and select one of the local restart strategy, the local reconstruction strategy, and the remote reconstruction strategy according to priority to enter the next subunit; A local restart strategy monitoring subunit is configured to, when the disaster recovery strategy is a local restart strategy, execute a local restart task on the master node and monitor the task status; and when the local restart task fails, re-execute the local restart task until the restart count is reached; a local reconstruction strategy monitoring subunit, configured to execute the local reconstruction task on the master node and monitor the task status when the disaster recovery strategy is the local reconstruction strategy or the local restart task reaches the restart count, and to re-execute the local reconstruction task until the reconstruction count is reached when the local reconstruction task fails; The off-site reconstruction strategy monitoring sub-unit is used to execute the off-site reconstruction task on the standby node and monitor the task status when the disaster recovery strategy is an off-site reconstruction strategy or the local reconstruction task reaches the reconstruction number. When the off-site reconstruction task fails to execute, the off-site reconstruction task is re-executed until the reconstruction number is reached.

8. A cloud computing-based business system disaster recovery method, applied to the cloud computing-based business system disaster recovery system according to any one of claims 1 to 7, comprising: Sorting out entity objects in the business system and the dependencies between entity objects according to business applications, wherein the entity objects include software products, external dependencies, deployment units, and application instances of the business applications; Register the entity objects of each business application in the business system to the software warehouse, upload the entity files of the entity objects, arrange the topology of the business system according to the dependency relationships, and configure the disaster recovery strategy required by the business system. The entity files include deployment packages, script files, image files, configuration files, and databases; After the business application in the business system is registered, all or part of the application instances in the business system are automatically deployed and launched on the master node, and the entity objects and entity files of each business application are synchronously backed up to at least one standby node according to the disaster recovery strategy; Performing status collection, fault monitoring, and damage decision analysis on each application instance of the business system, and issuing an alarm notification when a fault or disaster is detected; When the alarm notification is received, the system recovery operation of the business application is performed on the primary node or the backup node according to the disaster recovery strategy, and after the recovery is completed, the upstream data traffic and business access entry are redirected by configuring the external access entry information of the business system to achieve system reorganization recovery and business disaster recovery switching. The system recovery operation includes restoring the business system according to the topology structure of the business system, the registration information of the software warehouse and the physical file.

9. An electronic device comprising: one or more processors; a memory for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors are caused to perform the method according to claim 8. 10 . A computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, causes the processor to perform the method according to claim 8 .

Images