Cloud-computing-based business system disaster recovery system and method, electronic device, and storage medium

Abstract

The application provides a cloud computing-based business system disaster recovery system, relates to the technical fields of disaster backup recovery and cloud computing, and comprises the following modules: a software application registration and arrangement module, which is used for registering entity objects of business applications to a software warehouse, arranging a topology structure of the business applications according to a dependency relationship, and configuring a disaster recovery strategy; a software application deployment disaster recovery module, which is used for automatically deploying and starting the business applications and backing up the business applications according to the disaster recovery strategy; a fault monitoring and damage decision module, which is used for monitoring application instance faults and making damage decisions, and sending an alarm notification when a fault or disaster is monitored; and a system recovery and disaster recovery switching module, which is used for performing a system recovery operation when the alarm notification is received, performing disaster recovery switching operations such as upstream data flow and business access entry redirection, and realizing system reorganization recovery and business takeover. The application also provides a cloud computing-based business system disaster recovery method, an electronic device and a storage medium.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of disaster recovery and cloud computing, and more particularly to a business system disaster recovery system and method based on cloud computing, an electronic device and a storage medium. BACKGROUND

[0002] In recent years, China's aerospace remote sensing satellite technology has developed rapidly, and its ground system has been widely used in key fields such as military, meteorology, agriculture, disaster prevention and mitigation. With the rapid increase in the number of satellites and users, the software size and data volume of the ground system have increased geometrically, and the system concentration has been continuously improved, making the demand for high availability and disaster recovery capacity increasingly urgent. Traditional disaster recovery technology has evolved from early tape backup to real-time data protection in the era of cloud computing. Cloud disaster recovery provides a new solution for aerospace remote sensing ground systems through an elastic and scalable cloud service platform. Currently, domestic mainstream cloud platforms (such as Alibaba Cloud and Huawei Cloud) and industry-built private clouds have become the main foundation platforms for ground systems, and establishing a flexible and efficient cloud disaster recovery mechanism has become a key 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 require high continuity. Current mainstream solutions focus on data-level and application-level disaster recovery, and typical technologies include the "two sites and three centers" mode (as shown in Figure 1 The production center data is synchronized and replicated to the city center, and asynchronously replicated to the off-site center. Each center needs to deploy a unified version of application software (except for gray release), and disaster recovery control is switched when a disaster occurs. However, such solutions have the problems of low resource utilization and high cost, and the disaster recovery center is usually idle, with high operational complexity. Existing patent technologies (such as CN118779159A and CN117851122A) attempt to optimize the disaster recovery process through cloud-native and automated means, but are 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 configuration and dependency relationships.

[0004] The current disaster recovery technology faces four core problems: first, the lack of a business system as a whole disaster recovery perspective, leading to difficulty in global coordination during recovery; second, focusing on data and ignoring applications, with software deployment and version synchronization relying on manual operation, limiting the application of cold backup mode; third, the lack of automation, with recovery processes relying on manual operation, resulting in low efficiency and errors; fourth, limited compatibility, making it difficult to support hybrid deployment environments such as bare metal, virtual machines, and containers. Future development should break through the resource waste bottleneck of the traditional "two-site three-center" mode and explore dynamic resource scheduling and intelligent disaster recovery management. For example, by combining the elastic expansion capabilities of cloud-native technologies such as Kubernetes, an automated disaster recovery platform supporting multi-form deployment can be built, ultimately achieving a low-cost, efficient, and highly available disaster recovery system for space remote sensing ground systems. SUMMARY

[0005] Therefore, the present application provides a business system disaster recovery system and method based on cloud computing, an electronic device, and a computer readable storage medium.

[0006] The first aspect of the present application provides a business system disaster recovery system based on cloud computing, comprising: a software application registration and arrangement module for registering entity objects of each business application in a business system to a software repository and uploading entity files of the entity objects, arranging the topology structure of the business system according to the dependency relationship between each entity object, and configuring the disaster recovery strategy required by the business system, wherein the entity objects include software artifacts, 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 and disaster recovery module for automatically deploying and starting all application instances in the business system on a master node after the registration of the business applications in the business system is completed, and synchronously backing up the entity objects and entity files of each business application to at least one backup node according to the disaster recovery strategy; a fault monitoring and damage decision module for collecting the state, monitoring the fault, and analyzing the damage decision of each application instance of the business system, and issuing an alarm notification when a fault or disaster is monitored; a system recovery and disaster recovery switching module for performing a system recovery operation of the business applications on the master node or the backup node according to the disaster recovery strategy when the alarm notification is received, and redirecting upstream data traffic and business access entry after the recovery is completed by configuring the external access entry information of the business system, realizing business reorganization and recovery and business disaster recovery switching, wherein the system recovery operation includes automatically recovering the business system according to the topology structure of the business system, the registration information of the software repository, and the entity files.

[0007] According to an embodiment of the present application, the topology is defined based on a business system topology arrangement model, a node of the business system topology arrangement model represents the entity object, a connection line between the nodes represents a dependency relationship between the entity objects, the dependency relationship includes relationship types of "runs on", "depends on", "connects to", "belongs to", and "replica on" between the entity objects, wherein the relationship type "replica on" is used to represent a relationship between multiple replicas in a cluster or load balancing in the business system; the node and the connection line both support defining attributes and operations on demand, and the attributes and the operations are used to automatically restore the business system in the system recovery operation.

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

[0009] According to an embodiment of the present application, the software application deployment disaster recovery module includes: an automatic pipeline execution unit, configured to sequentially traverse each node of the topology based on the meta-information of the business application and the topology saved in the software warehouse, determine serial or parallel logic and a sequence from bottom to top according to the relationship between the nodes, construct a directed acyclic graph order pipeline, automatically execute the order pipeline through a workflow engine, and realize deployment, backup, and data synchronization of the business application; a deployment resource automatic opening unit, configured to call a resource service of a cloud platform based on a cloud resource access interface provided by a basic capability support layer, and automatically apply for, create, and open a deployment unit and external dependent items of the business application, and create and set a cloud product required by the business application; a dependency relationship injection and service discovery unit, configured to perform dependency injection on an application instance of the business application according to the dependency relationship; a software and data automatic disaster recovery unit, configured to automatically backup software and data of the business application from a master node to one or more backup nodes according to the disaster recovery strategy when the business application is registered in the software application registration arrangement module.

[0010] According to an embodiment of the present application, the fault monitoring and damage decision module includes: an information collection unit, configured to perform state sensing and information collection on each application instance in the business system, and collect state information of each application instance; a decision analysis unit, configured to detect various abnormalities in the state information, aggregate the abnormalities, perform multi-level decision analysis on the abnormalities based on a decision tree, and generate an abnormal record of the business application; a fault monitoring unit, configured to comprehensively diagnose a fault and determine damage based on a plurality of configured fault diagnosis rules, and generate the alarm notification when the determination state is a fault or damage.

[0011] According to the embodiments of the present application, the system recovery module comprises: a preparation and checking unit, configured to, in response to the alarm notification, check whether the states of the master node and the standby node satisfy the conditions of disaster recovery according to the registration information and the topology of the software warehouse, and perform disaster recovery preparation; an application disaster recovery strategy selection and monitoring unit, configured to select a disaster recovery strategy based on the state of the master node or the standby node, perform the system recovery operation based on the disaster recovery strategy and monitor the recovery state, and upgrade the disaster recovery strategy when the recovery state is abnormal, and perform the system recovery operation again until the system recovery operation is completed, wherein the disaster recovery strategy comprises, in order of priority from high to low, a local restart strategy, a local rebuild strategy and a remote rebuild strategy; a system recovery judgment unit, configured to judge whether the business application of the business system is successfully recovered; and a disaster recovery switching unit, configured to, when the business application is successfully recovered, perform a redirection operation of upstream data flow and business access entry of the business application, and recover the business access of the business application.

[0012] According to the embodiments of the present application, the application disaster recovery strategy selection and monitoring unit comprises: a strategy selection subunit, configured to sequentially confirm and select one of the local restart strategy, the local rebuild strategy and the off-site rebuild strategy according to the priority and enter a next subunit; a local restart strategy monitoring subunit, configured to, when the disaster recovery strategy is the local restart strategy, execute a local restart task on the master node and monitor a task state, when the local restart task fails, re-execute the local restart task until a restart number is reached; a local rebuild strategy monitoring subunit, configured to, when the disaster recovery strategy is the local rebuild strategy or the local restart task reaches the restart number, execute a local rebuild task on the master node and monitor the task state, when the local rebuild task fails, re-execute the local rebuild task until a rebuild number is reached; and an off-site rebuild strategy monitoring subunit, configured to, when the disaster recovery strategy is the off-site rebuild strategy or the local rebuild task reaches the rebuild number, execute an off-site rebuild task on the backup node and monitor the task state, when the off-site rebuild task fails, re-execute the off-site rebuild task until the rebuild number is reached. The second aspect of the present application provides a cloud computing-based business system disaster recovery method, applied to the cloud computing-based business system disaster recovery system as described in any one of the first aspect, comprising: combing entity objects in the business system and a dependency relationship between the entity objects according to a business application, wherein the entity objects comprise software artifacts, external dependencies, deployment units and application instances of the business application; registering the entity objects of the business application to a software warehouse, uploading entity files of the entity objects, arranging a topology structure of the business system according to the dependency relationship, and configuring disaster recovery strategies required by the business system, wherein the entity files comprise deployment packages, script files, image files, configuration files and databases; after the registration of the business application in the business system is completed, automatically deploying and pulling up all application instances in the business system on a master node, synchronously backing up software and data of each business application to at least one backup node according to the disaster recovery strategies; collecting a state, monitoring a fault and analyzing a damage decision of 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, executing a system recovery operation of the business application on the master node or the backup node according to the disaster recovery strategies, and after the recovery is completed, redirecting upstream data traffic and business access entry by configuring external access entry information of the business system, to realize system reorganization and recovery and business disaster recovery switching, wherein the system recovery operation comprises recovering the business system according to the topology structure 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; 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 as described above.

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

[0015] The embodiments of the present application provide a cloud computing-based business system disaster recovery system and method, which supports local / remote disaster recovery of software applications in virtual machines, containers and bare metal instances distributedly deployed on a cloud platform; supports automatic creation of application deployment resources by dynamically scheduling cloud platform computing, storage, network and middleware services and the like resources, and completely rebuilds and recovers service capabilities of software applications from a running environment of the software; so as to realize various fault recovery means such as local restart, local rebuild and remote rebuild based on the backup software applications. In the case of failure, abnormality or damage of a cloud node of a space remote sensing ground system, based on the implementation of the present application, the business can be quickly recovered locally or remotely, the application is recovered and the service is replaced, and the normal operation of the space remote sensing ground system is ensured. BRIEF DESCRIPTION OF DRAWINGS

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

[0017] Figure 1 A typical "two sites and three centers" mode disaster recovery scheme is schematically shown;

[0018] Figure 2 A general layered architecture diagram of the cloud computing-based business system disaster recovery system provided by the embodiments of the present application is schematically shown;

[0019] Figure 3 A block diagram of the cloud computing-based business system disaster recovery system provided by the embodiments of the present application is schematically shown;

[0020] Figure 4 A logical structure diagram of a business system topology arrangement model according to the embodiments of the present application is schematically shown;

[0021] Figure 5 An access entry redirection diagram in a domain name mode according to the embodiments of the present application is schematically shown;

[0022] Figure 6 An access entry redirection diagram in a load balancing mode according to another embodiment of the present application is schematically shown;

[0023] Figure 7 A cloud computing-based business system disaster recovery system application schematic diagram provided by an embodiment of the present application is shown schematically;

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

[0025] Figure 9 A space remote sensing ground system preprocessing subsystem application topology logical diagram provided by an embodiment of the present application is shown schematically;

[0026] Figure 10 A task management and control subsystem orbit calculation application orchestration diagram provided by an embodiment of the present application is shown schematically;

[0027] Figure 11 A fault monitoring and damage decision flowchart provided by an embodiment of the present application is shown schematically;

[0028] Figure 12 A system recovery and disaster recovery switching flowchart provided by an embodiment of the present application is shown schematically

[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 shown schematically. DETAILED DESCRIPTION

[0030] Hereinafter, embodiments of the present application will be described with reference to the accompanying drawings. It is to be understood, however, that the description is merely exemplary and is not intended to limit the scope of the present application. In the following detailed description of the embodiments of the present application, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the present application. However, it would be apparent to those skilled in the art that the embodiments of the present application can be practiced without these specific details. In other instances, well-known structures and functions have been omitted to avoid unnecessarily complicating the present application with details that would be apparent to those skilled in the art.

[0031] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the present application. As used herein, the term "includes" and tautological expressions thereof, such as "including," "includes," "include," "contains," "containing," and so on, mean the term "comprises," unless otherwise noted.

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

[0033] In the case of using expressions such as "at least one of A, B, and C", it generally should be interpreted to include any of A, B, or C alone, a combination of at least two of the items A, B, and C, or all of the items A, B, and C.

[0034] To achieve the overall disaster recovery of the business system, first, the business system must be taken as the object, and the business system to be disaster recovered can be clearly described, and the business system meta information is constructed, including its business application, software composition, service and data dependency, deployment form, resource requirement, topology structure, and disaster recovery strategy requirement, etc. Second, based on the meta information of the business system, the software units, deployment units, services, and data dependency instances involved in each application of the business system are managed throughout the life cycle, including registration, update, version management, offline and synchronization, backup, recovery, etc. Third, based on the meta information of the business system and the disaster recovery strategy, the business system to be disaster recovered can be quickly deployed on demand on various cloud platforms. Fourth, the running state of the business application system can be perceived and monitored, and when a fault or disaster occurs, fault discrimination and damage decision support can be provided, and a disaster recovery task can be automatically triggered. Finally, the rapid disaster recovery switching of the business system can be realized, and the business can be quickly taken over and recovered.

[0035] Figure 2 The overall layered architecture of the business system disaster recovery system based on cloud computing provided by the embodiment of the application is schematically shown.

[0036] As shown in Figure 2 In the embodiment of the application, the overall layered architecture of the business system disaster recovery system includes a cloud infrastructure platform layer, a basic capability support layer, a business system layer, and a disaster recovery service layer. The cloud infrastructure platform layer mainly provides various cloud platforms of resources and services such as computing, storage, network, and middleware services for the upper-layer business system, and is the infrastructure layer of the disaster recovery system of the present solution.

[0037] The basic capability support layer is an abstract layer of capabilities defined regardless of the cloud platform, which extracts public and general support capabilities such as identity authentication and authorization, cloud resource access interface, data synchronization and backup, and cloud state monitoring required by the disaster recovery service, and defines a group of abstract service interfaces for the upper-layer disaster recovery service to access, and the abstract service interfaces are specifically implemented for each cloud platform of the cloud infrastructure platform layer on demand. Through the basic capability support layer, the business system disaster recovery system based on cloud computing provided by the embodiment of the application can be independent of the specific cloud platform, and support for heterogeneous cloud platforms can be realized.

[0038] The business system layer is a service object of the business system disaster recovery system based on cloud computing provided by the embodiments of the present application, and is a collection of cloud business applications based on a cloud platform to undertake actual business. The business system layer needs to include static meta information describing the business system and each component unit thereof, and a business system application instance dynamically deployed and started according to the meta information. In the embodiments of the present application, a meta information model describing the business system and each component unit thereof is constructed, and an application instance is dynamically created according to the meta information model, which is the core content of the present solution.

[0039] The disaster recovery service layer is each service component for the business system to specifically execute a disaster recovery process according to the requirements and instructions of a user, calling a cloud platform and a basic capability support layer, including software application registration and orchestration, software application deployment disaster recovery, fault monitoring and damage decision support, system recovery and disaster recovery switching, and the like.

[0040] Figure 3 An overall block diagram of the business system disaster recovery system based on cloud computing provided by the embodiments of the present application is schematically shown.

[0041] As shown in Figure 3 The business system disaster recovery system based on cloud computing 300 provided by the embodiments 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 and disaster recovery switching module 340. The functions of each component of the system will be described in detail below. Figures 3-7

[0042] To describe the composition and topology of the business system, the present application refers to and follows the cloud application topology orchestration specification (TOSCA, Topology and Orchestration Specification for Cloud Applications) formulated by the OASIS organization (Structured Information Standard Promotion Organization), and constructs and implements a topology orchestration model for a space remote sensing ground business system. According to the TOSCA specification, the present solution describes the static structure of a cloud application through two basic concepts: nodes (node) and relationships (relationship); describes the software or resource objects of an application through nodes, and describes the dependency or connection relationship between each component object of the application through relationships.

[0043] For the nodes, the present solution defines node types such as a business system, a business application, a deployment unit, an external dependency, and a software product (including: basic software, business software, and a business image), which are used to represent model entity objects. The definitions of various types of model objects are described as follows:

[0044] ​(1) Foundation software: refers to the public general components such as basic class library, system tool or development framework, etc. provided by the foundation software for supporting the running of business software, providing a basic dependent environment, for example, JDK, Python, Nginx, Tomcat, NFS client, FTP tool, etc. which are usually provided in the form of installation package in the business system;

[0045] (2) Business software: application software that completes business functions, usually provided in the form of deployment package, the attributes of business software include: basic information, deployment package, deployment script, etc. and is completed by the deployment unit for deployment and running;

[0046] (3) Business image: business software in the form of image, including virtual machine image or container image, which is packaged by the business system on the basis of the general base image of the cloud platform, encapsulating the business application software and its dependent environment, and can create a deployment unit based on the business image to complete the deployment and running of the business software;

[0047] (4) External dependency: mainly refers to the data dependencies such as stateful databases, message queues, NAS shared storage, OSS object storage, etc. in the cloud application; the business system relies on mature middleware services on the external cloud platform to create, bind and manage these dependencies, helping the business application to quickly realize the injection and access of data dependencies;

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

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

[0050] (7) Business system: refers to a business system that undertakes complete and independent business functions in a business field, which is usually a subsystem or a subsystem of a complex large system, and is a basic unit for research, operation and disaster recovery. A business system usually includes one or more business applications that cooperate with each other. For example, in a space remote sensing ground system, it usually includes data receiving, data preprocessing, task control, professional processing and big data business systems.

[0051] For the relationship, the present solution defines the relationship types of "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 the model can also be continuously refined and derived as needed, thereby having the ability to describe complex business systems. Through these nodes and relationships, the present solution constructs a business system topology arrangement model, and the logical structure of the model is shown in Figure 4

[0052] Figure 4 The business system topology arrangement model according to the embodiments of the present application is schematically shown.

[0053] As shown in Figure 4 , the business system topology arrangement model represents the business system as a hierarchical topology graph in a tree structure, wherein the nodes of the hierarchical topology graph represent entity objects, and the connection lines between the nodes represent the dependency relationship between the entity objects. In addition, some properties and operations can be defined for the nodes and lines in the topology graph as needed, representing the functional characteristics and management operations of the nodes or lines, for automatically restoring the business system in the system recovery operation. The properties of the nodes can include the registration information of the entity objects in the software warehouse, and the connection lines define the operations between the nodes as needed. For example, for the "business software" node, the deployment package, deployment script, start-stop script, running environment, resource requirement and the like can be defined as properties, and the deployment, uninstallation, backup and version update and the like can be defined as operations. Thus, the automation management capability is given to each element in the topology graph, thereby laying a solid foundation for the subsequent automatic deployment and disaster recovery.

[0054] In the embodiments 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] Through the model description file, the arrangement, presentation, transmission, persistence and version iteration of the topology structure of the business system on the cloud can be implemented.

[0091] In the embodiments of the present application, in order to implement the unified registration management, version maintenance, disaster recovery strategy configuration and backup recovery of the business system, the business application, and the software artifacts and deployment units, external dependencies of the basic software, business software, business image, etc., a software application registration arrangement module 310 is designed. The software application registration arrangement module 310 is used to register the entity objects of each business application in the business system to the software warehouse, and upload the entity files of the entity objects, arrange the topology structure of the business system according to the dependency relationship, and configure the disaster recovery strategy required by the business system. The entity objects include software artifacts, external dependencies, deployment units and application instances of the business application, and the entity files include deployment packages, scripts and images. The software application registration arrangement module 310 can generate meta information for the business system and each component, including structured attribute data, topology structure model files, and unstructured deployment packages, scripts and images, etc. entity files are saved to the relational database, object storage and image warehouse of the cloud platform, which together constitute a software warehouse for unified management of various software applications of the business system. The disaster recovery strategy of the application is a disaster recovery strategy predefined for system sudden failure and disaster, so that in the event of an emergency, the corresponding disaster recovery backup, survival monitoring, fault and damage determination, system recovery, etc. strategies can be executed according to the level and importance of the application.

[0092] The software application registration and arrangement module 310 can specifically include software artifact management, deployment unit management, external dependency management, application registration and arrangement, application disaster recovery configuration, and the like. The software artifact management submodule is configured to implement registration, editing, version updating, and offline (logical deletion) of basic software, business software, and business images, and manage basic information, deployment packages, image files, deployment scripts, start-stop scripts, and the like of each software or image. The deployment unit management submodule is configured to implement registration, editing, version updating, specification adjustment, and deletion of bare metal, virtual machines, containers, and the like of the cloud-based business application deployment units, and support management of attributes such as the name, version, deployment type, resource requirements (CPU, memory, disk, network), image identifier, and number of replicas of the deployment unit. The external dependency management submodule is configured to implement registration, editing, querying, binding, and unbinding of external dependencies provided by the cloud platform, such as relational databases, in-memory databases, message queues, registration and discovery centers, OSS object storage, and NAS storage, and support management of scripts or configuration parameters such as creation and initialization. The application registration and arrangement submodule is configured to provide registration management and topology arrangement functions for business applications, support management and maintenance of basic information such as the application name, identifier, version, belonging business system, level, and importance, provide a graphical topology structure arrangement interface, and enable intuitive arrangement of the topology structure of the application in a graphical drag-and-drop manner. The application disaster recovery configuration submodule is configured to implement configuration and management of disaster recovery strategies for business applications, including disaster recovery targets, disaster recovery regions, backup strategies, survival monitoring strategies, disaster recovery strategies, and the like, and develop plans for synchronization, backup, and recovery of software and data of the disaster recovery application.

[0093] In the embodiments of the present application, in order to realize automatic deployment, pulling up, and disaster backup of the business applications of the business system registered in the software warehouse, a software application deployment and disaster recovery component is designed. The software application deployment and disaster recovery module 320 is configured to automatically deploy and pull up all application instances of the business system in the master node after registration of the business applications in the business system is completed, and synchronize and backup entity objects and entity files of each business application to at least one backup node according to a disaster recovery strategy. Specifically, the software application deployment and disaster recovery module 320 includes an automatic pipeline execution unit, a deployment resource automatic opening unit, a dependency relationship injection and service discovery unit, and a software and data automatic disaster recovery unit.

[0094] The automatic pipeline execution unit is used to parse the application topology based on the meta-information and topology structure of the business application saved in the software warehouse, adopt a recursive algorithm to sequentially traverse each node of the topology structure, determine the serial or parallel logic and the order from bottom to top according to the relationship between the nodes, thereby constructing a directed acyclic graph order pipeline, and then automatically executing the order pipeline through the workflow engine. Combined with the attributes and operations defined by each node and line in the model, the deployment of the disaster recovery component can realize the automatic deployment, backup and data synchronization of the business application in a pipeline manner.

[0095] The deployment resource automatic opening unit is used to call the computing, storage, network and middleware resources services provided by the cloud platform based on the cloud resource access interface provided by the basic capability support layer, automatically apply, create and open the deployment unit, external dependencies of the business application, and create and set the security group, VPC, DNS, SLB, EIP and other cloud products required by the business application. With the help of the automatic pipeline execution unit, the entire deployment and pull-up process of the business system can be fully automated.

[0096] The dependency relationship injection and service discovery unit is used to perform dependency injection on the application instance of the business application according to the dependency relationship, and realize the registration, publication and mutual discovery of services through the registration and discovery center provided by the cloud platform.

[0097] Each software deployment unit in the same business application has a dependency relationship, which usually means that the dependent item has data transmission, interface call, instruction sending and other operation requirements for the dependent item. At this time, the deployment unit needs to know the specific access location (IP address, domain name, etc.) of its dependent item in order to perform the corresponding access operation. When deploying software manually in the traditional way, the software deployment personnel usually manually records the IP address, domain name and other information of each deployment unit, and configures them in the configuration file, environment variable or startup parameter of the software that depends on it, to realize the mutual discovery and addressing of each deployment unit. However, in the scenario of automatic deployment, a corresponding mechanism needs to be designed to ensure that the software deployment unit can automatically discover the deployment location of the other units it depends on, that is, to realize dependency relationship injection and automatic mutual discovery. Therefore, in the process of automatic deployment of the business application, the present scheme supports dependency injection through environment variable injection, external configuration file, domain name, SLB or EIP dynamic binding, and at the same time, supports the registration, publication and mutual discovery of services through the registration and discovery center provided by the cloud platform.

[0098] Environment variable injection is mainly aimed at deployment units such as virtual machines, bare metals and containers, and realizes dependency injection by dynamically setting environment variables at the operating system level. When a deployment unit is started, the location information of all other deployment units on which the deployment unit depends is automatically injected into the environment variables of the operating system of the deployment unit. Then, the application program started in the deployment unit can obtain the specific address of the dependency by reading the operating system environment variable information.

[0099] External configuration file mainly refers to separately specifying or mounting the configuration file required by the application software during runtime outside the deployment package or image, so as to dynamically configure the access address of the dependency during deployment, and then specify or mount the configuration file during startup to realize dependency injection.

[0100] Domain name, SLB or EIP dynamic binding refers to configuring domain name, SLB or EIP and other access methods when the application software or deployment unit is registered, and providing an unchanged access entry to the outside. In this way, no matter where or when the instance of the software or deployment unit is pulled up, the domain name, SLB or EIP bound thereto can remain unchanged, and the software or deployment unit that has a dependency thereon can access it through the domain name, SLB or EIP. Thus, dependency injection and mutual discovery are realized.

[0101] Registration discovery center refers to using common microservice management tools and registration discovery framework (such as Nacos, Euraka, etc.) provided by the cloud platform to automatically register the access address and port information of the software or deployment unit to the service registration discovery center after the software or deployment unit is started. All software that has a dependency thereon can automatically discover the access location of the dependency through the registration discovery center.

[0102] Software and data automatic disaster recovery unit is used to automatically backup the software and data of the business application from the master 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 arrangement module 310. The disaster recovery backup of the business system is first the disaster recovery backup of various software and applications. In this scheme, after the application is registered, a disaster recovery pipeline is immediately initiated, and the synchronization and backup operation of the application, software (including image, deployment package, script, etc.) is performed according to the configured backup strategy. The meta information of the application, deployment unit and software, and the image, deployment package, script, initialization parameter, etc. thereof are automatically backed up from the master node to one or more backup nodes. The synchronization backup of the software application can be realized by using the API interface of the high-efficiency file transfer, OSS object storage, image repository, etc. of the cloud platform, and supports various automatic backup strategies such as periodic or event-driven (such as version update).

[0103] Disaster recovery backup of a business system needs to implement disaster recovery of not only executable programs or software images of software applications but also underlying data and configuration parameters relied on by the software applications. In addition, to support the business application to continue running after being pulled up, it is necessary to ensure that the software application can continue to access the original data, state or its copy. The data relied on by the software application generally exists in external dependencies such as databases (relational, non-relational), file storage, message queue or registration discovery center, so the disaster recovery backup of business data of the business system is mainly implemented by disaster recovery backup of the above external dependencies. In specific implementation, cloud platform data transmission service (DTS), database backup service (DBS) and the like can be used for execution.

[0104] The disaster recovery service needs to be able to perceive and monitor the running state of the business system, and when a fault or disaster damage occurs, it can provide fault discrimination and damage decision support and automatically trigger a disaster recovery task. In the embodiments of the present application, the fault monitoring and damage decision module 330 is used to collect the state, monitor the fault and analyze the damage decision of each application instance of the business system, and when a fault or disaster is monitored, an alarm notification is sent. A periodic health check task can be automatically triggered by a timer, and the health check interface of each level object such as each software, deployment unit and external dependency of each business application is called in time; then the collected various data are automatically collected, the occurrence of application fault or disaster damage is perceived in the first time according to the pre-defined fault discrimination rule and damage decision analysis algorithm, the fault discrimination or damage decision is automatically and intelligently implemented, and an alarm notification is sent in time for the fault or damaged application, and the disaster recovery personnel is automatically triggered or assisted to make a decision on fault disaster disposal.

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

[0106] The information collection unit is used for state sensing and information collection of each application instance in the business system, and collects state information of each application instance. The running state, resource usage and business load of the business application and other information can be comprehensively and efficiently collected through means such as laying software probes, collecting cloud platform product state information and monitoring the health check interface registered by the business application software. The software probe monitors the software process in the deployment unit in a non-invasive manner, automatically obtains the instance process ID through software registration information, thereby finely obtaining the running state of the software instance, including real-time states such as CPU usage, memory usage, storage usage, network real-time traffic, and detailed information of the software process, such as state, stack, GC, context switching times, OOM occurrence times, IO load (read / write rate, IOPS), and supports integration of Shell commands, customized scripts and custom business indicators for on-demand personalized customization collection. Through the custom probe, the running log, abnormal log, business load and other information of the business application can be obtained. The software probe is deployed by an automatic deployment pipeline, and is deployed and started together with other software when the deployment unit is deployed. Cloud product state collection refers to calling API interfaces or commands of cloud products such as virtual machines, containers, bare metals, databases, message queues and NAS storage of the cloud platform, collecting the health status of the running environment of the application deployment unit instance, external dependency instance and other information, including CPU, memory, disk, network resource occupation, real-time load, and whether the operating system and middleware service are dead or not. The business software health check refers to automatically obtaining the health status of each business software by calling the health check interface provided when the business software is registered, and more accurately obtaining the business health status of each business software.

[0107] The decision analysis unit is used for detecting various exceptions in the state information, aggregating the exceptions, performing multi-level decision analysis on the exceptions based on a decision tree, and generating an exception record of the business application.

[0108] The fault monitoring unit is used for comprehensive fault discrimination and damage determination of the exception record based on a variety of configured fault discrimination rules, and generates an alarm notification when the determination state is fault or damage.

[0109] In the embodiments of the present application, various types of aggregated state information are detected for exceptions through resource exception detection models, log exception detection models, application state comprehensive analysis and decision analysis based on a decision tree. Then, according to the configured fault discrimination rules and damage decision standards, a determination and decision are made. The present scheme supports configuration of a variety of fault discrimination rules (including timeout time, retry times, resource threshold, exception level, exception number, etc.).

[0110] When determining that a fault or damage occurs, the disaster recovery service can automatically initiate a disaster recovery processing flow according to a disaster recovery strategy, or manually initiate accurate processing by a business user. After system recovery is completed, upstream data flow and business access entry are redirected to achieve disaster recovery switching of business system recovery and business access.

[0111] In the embodiment of the present application, the system recovery disaster switching module 340 is configured to perform system recovery operations of the business application on the master node or the backup node according to the disaster recovery strategy when receiving the alarm notification, and to perform upstream data flow and business access entry redirection by configuring external access entry information of the business system after recovery is completed, to achieve business reorganization recovery and disaster recovery switching. The system recovery operation includes automatically recovering the business system according to the logical topology model of the business system and the topology structure of each business application, the registration information of the software warehouse, and the entity file.

[0112] In the embodiment of the present application, the system recovery disaster switching module 340 supports an automatic recovery mode. In this mode, the system recovery module first attempts to restart locally according to the disaster recovery strategy, and if the restart is successful, the business software is restored to normal use. If the restart is not successful within the number of restart attempts configured in the disaster recovery strategy, the recovery strategy of reconstruction is entered. According to the configured reconstruction strategy, reconstruction is first attempted locally, and if reconstruction is not successful within the number of attempts configured, reconstruction is performed in a remote area according to the backup area configured for the business system, and the system is pulled up after successful reconstruction in the remote area. The user can verify the normal access of the recovered business software.

[0113] In the embodiment of the present application, the system recovery disaster switching module 340 also supports a manual recovery mode. When receiving a fault or damage alarm, a business user or a disaster recovery administrator can select to restart or reconstruct a specified version of the business system in a suitable backup area (local node or remote node) according to needs. In addition, the system recovery strategy can be finely controlled according to needs to achieve system reorganization and reconstruction, such as reconstructing only part of the business application in the business system, configuring the resource scale of the backup area business system, and using the elastic scaling capability of the cloud to achieve fast system recovery and efficient use of resources.

[0114] Specifically, the system recovery disaster 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 switching unit. The working process of the module can refer to Figure 12 .

[0115] The preparation and checking unit is configured to check whether the states of the primary node and the backup node meet the conditions of disaster recovery according to the registration information and the topology structure of the software warehouse in response to the alarm notification, and to perform disaster recovery preparation. After receiving the service application failure or damage notification and initiating the system recovery process, the states of the current node and the backup node are checked according to the registration information and the topology model structure to determine whether the conditions of disaster recovery are met, and preparation work such as backup version preparation, resource quota confirmation, disaster recovery strategy checking, confirmation of whether the backup files or images are complete, and confirmation of whether the resources of the backup node are sufficient is performed.

[0116] The application disaster recovery strategy selection and monitoring unit is configured to select a disaster recovery strategy based on the state of the primary node or the backup node, to perform a system recovery operation and monitor the recovery state based on the disaster recovery strategy, and to upgrade the disaster recovery strategy when the recovery state is abnormal, and to perform the system recovery operation again until the system recovery operation is completed. The disaster recovery strategies include, in order of priority from high to low, a local restart strategy, a local rebuild strategy, and a remote rebuild strategy.

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

[0118] The strategy selection subunit is configured to sequentially confirm and select one of the local restart strategy, the local rebuild strategy, and the remote rebuild strategy according to the priority, and to enter the next subunit.

[0119] The local restart strategy monitoring subunit is configured to perform a local restart task on the primary node and monitor the task state when the disaster recovery strategy is the local restart strategy, and to re-perform the local restart task until the number of restarts is reached when the local restart task fails.

[0120] The local rebuild strategy monitoring subunit is configured to perform a local rebuild task on the primary node and monitor the task state when the disaster recovery strategy is the local rebuild strategy or the number of restarts of the local restart task is reached, and to re-perform the local rebuild task until the number of rebuilds is reached when the local rebuild task fails.

[0121] The remote rebuild strategy monitoring subunit is configured to perform a remote rebuild task on the backup node and monitor the task state when the disaster recovery strategy is the remote rebuild strategy or the number of rebuilds of the local rebuild task is reached, and to re-perform the remote rebuild task until the number of rebuilds is reached when the remote rebuild task fails.

[0122] The system recovery determination unit is configured to determine whether the service application of the service system is successfully recovered. If so, the system enters disaster recovery switching, and if not, the system returns to the disaster recovery preparation and checking step and re-performs the next round of operation.

[0123] The disaster recovery switching unit is configured to perform redirection of upstream data flow and service access entry of the service application when the service application is successfully recovered, and to recover service access of the service application.

[0124] Considering the extensive dependency and calling relationship between service applications, the disaster recovery service needs to ensure that the access portal of the locally / remote recovered service system application remains unchanged, so as to make the disaster recovery operation as transparent as possible to the upstream service and avoid a chain reaction caused by a specific software failure. Therefore, after the system is recovered through local or remote reconstruction operation, the upstream service request is redirected to the newly started application instance, ensuring that the application software can be continuously accessed without changing the upstream caller after failure recovery, thereby guaranteeing the continuity of the service.

[0125] The present scheme supports configuration and switching of cloud product service information through domain name service (DNS), load balancing (SLB), and elastic public network IP (EIP) after system recovery, to realize disaster recovery switching of the service application.

[0126] The DNS configuration switching mode supports configuration of application program access entry through domain name resolution. After system disaster recovery, the disaster recovery switching module automatically calls the cloud platform domain name resolution service interface to point the domain name to the IP of the newly started application instance, and the upstream service only needs to access the application through the domain name, so as to be redirected to the recovered application without any modification.

[0127] For multiple different instances of a software application, the domain name configuration mode is adopted, which requires the application to use different domain names for different instances. Different versions and different copy instances of the same application can be configured in the form of subdomain names (for example, the domain name of the application is aaa.com, the domain name of copy 1 is e1.aaa.com, and the domain name of copy 2 is e2.aaa.com). However, it is necessary to ensure that the access addresses of different instances of different applications or multiple instances of the same application remain unchanged. Whether the application is started locally or started remotely, the domain name should not change. Even if the IP changes, the domain name and IP should be modified in the DNS. For the domain names of different copy instances of the same application, a global domain name service is configured in each node in the system, and disaster recovery between nodes is realized through the global domain name.

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

[0129] As shown in Figure 5 , the domain name is always unchanged when the front end is accessed. When a failure occurs, the disaster recovery strategy is 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] SLB configuration switching mode, support through load balancing service mode configuration, system reorganization recovery, disaster recovery switching module will automatically call the cloud platform load balancing service related interface, will remove the original service from the SLB backend service list, add the IP address of the newly launched application instance to the load balancing service backend, upstream business access load balancing service instance address, can be redirected to the recovered application without any modification. For a plurality of different instances deployed for an application, if the access application entrance is the IP address of SLB (load balancing), then the application instances are each with their own IP, when the instance is created, the IP address of SLB should not change again, and the global IP address is configured through GSLB, which can be accessed on each disaster recovery cloud node.

[0131] Figure 6 The access entrance redirection schematic diagram of the load balancing mode according to another embodiment of the application is schematically shown.

[0132] As Figure 6 shown, the user access request is distributed to a plurality of services according to the forwarding policy by SLB (load balancing) configuration forwarding policy. The system exposes the IP and port of SLB to the outside, and the IP and port of the internal service are not exposed to the outside, and the SLB policy determines how to distribute and access. When a certain internal service fails, the SLB will forward the original distribution request to other available internal services.

[0133] EIP configuration switching mode, support through elastic IP service mode configuration application program access entrance, application reorganization recovery, module will automatically call the EIP service related interface of the cloud platform, bind the fixed IP address to the new application instance after reconstruction, ensure that the upstream business access entrance does not change.

[0134] Figure 7 The application schematic diagram of the business system disaster recovery system based on cloud computing according to the embodiment of the application is schematically shown.

[0135] As Figure 7 shown, the "application instance" in the figure is the running instance of the business system created, monitored and protected by the business system disaster recovery system provided by the embodiment of the application, which can be regarded as dynamic "data" generated by the disaster recovery system. The disaster recovery system is based on the support of cloud infrastructure platform, that is, it is deployed and runs on the cloud infrastructure platform, and is realized through the adaptation of the abstract service interface on the cloud platform, and calls various resources and services of the cloud platform. It is an indispensable basic dependent environment of the disaster recovery system.

[0136] As Figure 7As shown, the software application registration and arrangement component is responsible for registering and saving each software application of the business system into the software warehouse; the software application deployment and disaster recovery component extracts the meta information and entity files of the software application from the software warehouse, executes an automated pipeline, completes the automated deployment and disaster recovery of the application, and thus starts the application instance; the fault monitoring and damage decision component performs state collection, abnormality monitoring, fault judgment, damage decision analysis on the application instance; when a fault or damage is determined to occur, the system recovery and disaster recovery switching are notified to perform restart, reconstruction, and other disaster recovery and business redirection switching operations.

[0137] To perform local or off-site disaster recovery, the disaster recovery system of the present scheme generally needs to be deployed in one or more cloud nodes (cloud infrastructure platform) to respectively assume the roles of master node or backup node. The two nodes are interconnected and share resources, and can send and receive data through the software application deployment and disaster recovery component to realize the synchronous backup of the software warehouse and business data; the system recovery modules of the two nodes can perform off-site reconstruction through each other, the application instances can establish a master-slave or dual-active relationship, and the disaster recovery switching module can perform switching.

[0138] The master-slave roles of different nodes are only a relative concept in logic, and in fact, they are in a peer-to-peer relationship and can be master and slave to each other, and are distinguished and adjusted through corresponding configurations. For a specific application, the master node is usually the node where the business application is registered and created and mainly undertakes the business, and the backup node is the node where the business application is backed up and recovered. According to different disaster recovery modes, for the cold backup mode, the backup node can not run the application instance at ordinary times, only the backup of the application metadata and entity files, and only the application instance is started when disaster recovery is needed to undertake the business traffic; for the hot backup mode, the backup node can run a minimum scale application instance at ordinary times, and only when disaster recovery is needed, the business traffic is undertaken; for the multi-live mode, the backup node always maintains an appropriate scale of application instance and undertakes a certain proportion of business traffic. In the hot backup and multi-live modes, the application instance of the backup node can automatically perform elastic scaling according to the needs to reconstruct the scale of the application instance.

[0139] It should be noted that although Figure 7 only one master and one backup node are shown, in fact, the present scheme can support distributed deployment in multiple nodes and support one master and multiple backups between nodes for on-demand disaster recovery. In addition, the cloud infrastructure platforms of the master node and the backup node in the figure can be two relatively independent homogeneous / heterogeneous cloud platforms in different places, or different availability zones of the same cloud platform, as long as they are networked and the resources can meet the needs of the business system.

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

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

[0142] S810, the entity objects in the business system and the dependency relationships between the entity objects are sorted according to the business application, and the logical topology structure of the business system is constructed, the entity objects including software artifacts of the business application, external dependencies, deployment units and application instances.

[0143] In the embodiments of the present application, the business system sorts the business application belonging to the system according to the business system topology arrangement model proposed in the present scheme, and lists the basic software, business software, business image and other software artifacts for each business application; determines the deployment form, resource demand of each software, forms the deployment unit; then combines the database, message queue and other external dependencies to determine the dependency relationship of each component in the application, and forms the topology structure of the business application. At the same time, the level, importance and disaster recovery target and strategy of the business application can be determined from the business.

[0144] Taking the preprocessing subsystem of the space remote sensing ground system as an example, the preprocessing subsystem is composed of two business applications, business middle platform and algorithm plug-in set. Among them, the business middle platform application includes interface processing software, process control service, resource scheduling service, processing node execution agent service, process order service and process monitoring service, etc. These software services are deployed in the form of deployment package on ECS cloud host. The preprocessing algorithm plug-in set application includes catalog processing, product production and target detection algorithm plug-in set, which need to be deployed in the form of deployment package on bare metal server, and part of the algorithm program also needs to depend on GPU card, and needs to have MKL, CUDA and GDAL basic class library. The business middle platform and algorithm plug-in set application of preprocessing also need to depend on NAS storage, cloud database PolarDB-O, cloud memory type database Redis and cloud message queue MQ, etc. According to the analysis of these business models of preprocessing subsystem, the logical diagram of preprocessing subsystem application topology structure can be constructed.

[0145] Figure 9 The application topology structure logical diagram of the preprocessing subsystem of the space remote sensing ground system provided by the embodiments of the present application is schematically shown. As Figure 9As shown, according to the application topology logical structure shown in the figure, the basic information of each software and application of the preprocessing business system can be collected and arranged respectively, and the entity files such as deployment package, image file, script file, configuration file, and creation and initialization script of database and message queue are laid as a foundation for the next step of registration into the software warehouse. Preferably, under the condition of having conditions, the information of each software product and its deployment package, image, script and other entity files can be automatically collected and packaged through the development test pipeline.

[0146] S820, registering the entity object of the business application to the software warehouse, uploading the entity file of the entity object, arranging the topology structure of the business system according to the dependency relationship, and configuring the disaster recovery strategy required by the business system. The entity file includes deployment package, script file, image file, configuration file and database.

[0147] In the embodiment of the application, through the software application registration and arrangement module, the software products such as basic software, business software and business image prepared in the previous step, and external dependencies, deployment units and business application meta information are registered to the software warehouse, and the entity files such as deployment package, image, script are uploaded, the application topology structure is arranged according to the dependency relationship, and the disaster recovery strategy required by the application is configured. Preferably, under the condition of having conditions, the software application registration and arrangement module can be integrated with the development test pipeline to automatically register and upload to the software warehouse through the interface.

[0148] Taking the orbit calculation application of the space remote sensing task management and control sub-system as an example, the registered application topology arrangement diagram is as shown in Figure 10 Figure 10 The orbit calculation application arrangement diagram of the task management and control sub-system provided by the embodiment of the application is schematically shown.

[0149] S830, after the registration of the business application in the business system is completed, the master node automatically deploys and pulls up all or part of the application instances in the business system, and synchronously backs up the entity object and entity file of each business application to at least one standby node according to the disaster recovery strategy.

[0150] ​In the embodiments of the present application, after the business system is registered, a disaster recovery module can be deployed through a software application, and a specified version of a business application can be launched to execute an automatic deployment pipeline according to business needs, so as to realize one-key deployment and startup of the business system on a master node cloud platform. According to the deployed and started application instance, a disaster recovery pipeline is automatically launched according to an application backup strategy, and software (including images, deployment packages, scripts, etc.) and business data of the business application are synchronously backed up to one or more backup nodes. For software, periodic full backup and incremental backup based on events (version update, development and test pipeline release, etc.) are supported; for business data, full and incremental synchronization and backup are supported based on cloud platform data transmission services (DTS) and data backup services (DBS), etc. For entity data files in NAS storage or OSS object storage, efficient file transmission tools are used to perform file synchronization and backup between master and backup nodes, and size, MD5, etc. of the files are supported.

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

[0152] In the embodiments of the present application, state information of each application instance of the business system is collected in real time, abnormality detection of running state and survival state is carried out, decision analysis and fault / damage determination are performed, an alarm notification is sent when a fault or damage is determined, and subsequent disaster recovery operations are triggered.

[0153] Figure 11 A fault monitoring and damage decision flowchart provided by the embodiments of the present application is schematically shown. As shown in Figure 11 The three links of information collection, decision analysis and fault / damage determination are mainly included. These steps are periodically and continuously circulated at a certain interval in the life cycle of the application instance until the application instance is stopped or unloaded. In the information collection link, various state information is collected by the information collection module through software probes, cloud platform product state collection, business software health check and various running log collection, and is collected to the decision analysis module. In the decision analysis link, various abnormalities are automatically and intelligently detected through log abnormality detection models, resource abnormality detection models and comprehensive analysis of application health states, various abnormalities are collected, multi-level abnormality decision analysis of “software-deployment unit-application-business system” is performed based on a decision tree, and abnormality records of the business application are generated. In the fault / damage determination link, the abnormality records generated in the previous step are determined based on various fault determination rules (including application timeout time, retry number, resource threshold, abnormality level, abnormality frequency, etc.) configured, damage decision comprehensive judgment is performed on various abnormalities. When the fault / damage is determined, an alarm notification is generated, and subsequent logic is triggered.

[0154] S850, when receiving the alarm notification, performing system recovery operation of the business application on the master node or the backup node according to the disaster recovery strategy, and after the recovery is completed, redirecting upstream data flow and business access entry by configuring external access entry information such as DNS, SLB, EIP and the like of the business system, realizing non-perception continuous access of upstream business after business reorganization and recovery, realizing business disaster recovery switching and takeover recovery.

[0155] Figure 12 The system recovery and disaster recovery switching flowchart provided by the embodiment of the application is schematically shown.

[0156] As shown in Figure 12 the specific flow of S850 is described as follows: after receiving the business application failure or damage notification and initiating the system recovery flow, first, according to the registration information and topology structure of the application, checking the state of the current node and the backup node to see whether the conditions for disaster recovery are met, and performing preparation work such as backup version preparation, resource quota confirmation, disaster recovery strategy inspection, confirming whether the backup files or images are complete, confirming whether the resources of the backup node are sufficient, and the like. Checking the application disaster recovery strategy to determine whether to perform local restart operation, if yes, performing local restart recovery task, if no, entering local rebuild strategy judgment; after the local restart task is executed, determining whether the task execution is successful, if yes, entering system recovery judgment, if no, performing again until the number of restarts is reached. Checking the application disaster recovery strategy to determine whether to perform local rebuild operation, if yes, performing local rebuild recovery task, if no, entering remote rebuild strategy judgment; when the local rebuild task is executed, the application version to be rebuilt can be specified, after the execution is completed, determining whether the task execution is successful, if yes, entering system recovery judgment, if no, performing again until the number of local rebuilds is reached. Checking the application disaster recovery strategy to determine whether to perform remote rebuild operation, if yes, performing remote rebuild recovery task, if no, ending the flow; when the remote rebuild task is executed, the backup node to be recovered and the application version to be rebuilt can be specified, after the execution is completed, determining whether the task execution is successful, if yes, entering system recovery judgment, if no, performing again until the number of remote rebuilds is reached. The system recovery judgment step determines whether the application is successfully recovered according to the application survival monitoring and health inspection strategy, if yes, entering disaster recovery switching, if no, returning to the disaster recovery preparation and inspection step to perform the next round of operation again. The disaster recovery switching step performs business redirection operation of the current business application, completes business takeover and recovers business access.

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

[0158] The cloud computing-based business system disaster recovery system and method proposed in the embodiments of the present application has at least the following features and advantages:

[0159] First, a business system topology arrangement model is constructed. The present scheme follows the TOSCA standard, constructs and implements a topology arrangement model for a space remote sensing ground business system. By defining node types such as business system, business application, deployment unit, external dependency, software product (including: basic software, business software, business image), etc., the model entity objects are represented; by defining relationship types such as "runs on", "depends on", "connects to", "belongs to" and "replica of", the relationship between the model entity objects is represented. The topology arrangement model lays a solid foundation for automatic deployment, disaster recovery and recovery in subsequent disaster recovery. At the same time, the present scheme uses a lightweight JSON format file to describe the model structure, which is used for subsequent model data exchange, persistence and version upgrade.

[0160] Second, a software warehouse for unified management of software applications is designed based on the topology arrangement model structure, and a processing pipeline for automatic deployment, backup and recovery of applications is implemented. The present scheme can generate meta-information for business systems and their components through software application registration arrangement components, including structured attribute data, topology structure model files, and unstructured entity files such as deployment packages, scripts and images, which are saved to the relational database, object storage and image warehouse of the cloud platform, respectively, and they together constitute a software warehouse for unified management of various software applications of business systems. The present scheme also designs a software application deployment disaster recovery component, which can automatically implement the deployment, backup and recovery of business applications in the software warehouse in a pipeline manner. It also supports dependency injection through environment variable injection, external configuration file, domain name, SLB or EIP dynamic binding, etc.; it supports service registration, publication and mutual discovery through a registration and discovery center, solving the configuration dependency problem in automatic deployment.

[0161] Third, a disaster recovery system covering the whole process of disaster recovery service is designed, which includes four software components of software application registration and arrangement, software application deployment disaster recovery, fault monitoring and damage decision, system recovery and disaster recovery switching, and a software warehouse for saving software application meta information and entity files. The system can automatically create cloud resources required for disaster recovery through the application program interface (API) of the cloud platform, and realize one-key backup, one-key recovery and one-key switching on the cloud. The system can support distributed deployment on multiple nodes at the same time, support one master and multiple backups between nodes, and support on-demand disaster recovery. Among multiple nodes, it supports cold backup, hot backup and multi-live disaster recovery modes. Especially for the cold backup mode, it can greatly improve the automation level of recovery, reduce the difficulty and complexity of recovery, and has high practicality.

[0162] Fourth, a full life cycle fault monitoring and damage decision method is designed. This method collects real-time state information of each application instance of the business system, conducts abnormal detection of running state and survival state, conducts decision analysis and fault / damage judgment, issues an alarm notification when a fault or damage is judged, and triggers subsequent disaster recovery operations. This scheme realizes comprehensive and efficient collection of information such as running state, resource usage and business load of business applications through means such as laying software probes, collecting state information of each product of the cloud platform and monitoring the health check interface of the registered business application software. For the collected various types of state information, abnormal detection is conducted through resource abnormal detection model, log abnormal detection algorithm, application state decision analysis and multi-level abnormal decision analysis based on decision tree. Then, according to the configured fault discrimination rules and damage decision standards, fault / damage judgment and decision are made, which has good reliability and practicality.

[0163] Fifth, an automated local / remote disaster recovery method is designed, while supporting manual control of precise disaster recovery reorganization and reconstruction. In the automatic disaster recovery mode, the system first attempts to restart in the local area according to the disaster recovery strategy, and if the restart is successful, the business software is restored to normal use. If the restart is not successful, the system enters the recovery strategy of reconstruction. According to the configured reconstruction strategy, the system first attempts to reconstruct in the local area, and if the reconstruction is not successful, the system performs remote reorganization, reconstruction, and pull-up operation according to the configured backup area of the business system. After the successful remote pull-up, the user can verify the normal access of the recovered business software, and then perform disaster recovery switching. In this mode, the entire system recovery process can be automatically executed without human intervention. The system also supports manual recovery mode. The disaster recovery administrator can select the appropriate backup area (local or remote, one or more) to restart or reconstruct the specified version of the business system according to the needs. The system recovery strategy can also be fine-tuned to achieve system reorganization and reconstruction, such as: only part of the business applications in the business system are reconstructed; the instance resource scale of the backup area business system is configured to utilize the elastic scaling capability of the cloud to achieve fast system recovery and efficient resource utilization; the cold backup, hot backup, or multi-live disaster recovery mode between the master and backup nodes is set.

[0164] Sixth, the system supports multiple disaster recovery switching methods (SLB, DNS, EIP, etc.). After the system is recovered, the system supports the configuration and switching of cloud product service information such as domain name service (DNS), load balancing (SLB), and elastic public IP (EIP) to achieve disaster recovery switching of business applications. Through these switching methods, the upstream business can be quickly and imperceptibly switched to ensure 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 impose any limitations on the functions and use range of the embodiments of the present application.

[0166] As Figure 13As shown, the electronic device 1300 according to embodiments of the present application includes a processor 1301 which can perform various appropriate actions and processes in accordance with a program stored in a read only memory (ROM) 1302 or a program loaded into a random access memory (RAM) 1303 from a storage section 1308. The processor 1301 can include, for example, a general purpose microprocessor (e.g., a CPU), an instruction set processor, and / or a related chip set, and / or a dedicated microprocessor (e.g., an application specific integrated circuit (ASIC)), and so on. The processor 1301 can also include an on-board memory for cache use. The processor 1301 can include a single processing unit or multiple processing units to perform the various actions of the method processes according to embodiments of the present application.

[0167] In the RAM 1303, various programs and data required for the operation of the electronic device 1300 are stored. 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 processes according to embodiments of the present application by executing the programs in the ROM 1302 and / or the RAM 1303. Note that the programs can also be stored in one or more memories other than the ROM 1302 and the RAM 1303. The processor 1301 can also perform various operations of the method processes according to embodiments of the present application by executing the programs stored in the one or more memories.

[0168] According to embodiments of the present application, the electronic device 1300 can also include an input / output (I / O) interface 1305 which is also connected to the bus 1304. The electronic device 1300 can also include one or more of the following components connected to the input / output (I / O) interface 1305: an input section 1306 including a keyboard, a mouse, etc.; an output section 1307 including a display such as a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1308 including a hard disk, etc.; and a communication section 1309 including a network interface card such as a LAN card, a modem, etc. The communication section 1309 performs communication processing via a network such as the Internet. A drive 1310 is also connected to the input / output (I / O) interface 1305 as necessary. A removable recording medium 1311 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is attached to the drive 1310 as necessary, so that a computer program read therefrom is installed into the storage section 1308 as necessary.

[0169] According to an embodiment of the present application, the method flow according to the embodiments of the present application can be implemented as a computer software program. For example, the embodiments of the present application include a computer program product comprising a computer program carrying computer program code embodied in a computer readable storage medium, the computer program code comprising program code for executing the method shown in the flow chart. In such an embodiment, the computer program can be downloaded and installed from a network by the communication part 1309, and / or installed from the detachable medium 1311. When the computer program is executed by the processor 1301, the above-mentioned functions defined in the system of the embodiments of the present application are executed. According to an embodiment of the present application, the system, device, apparatus, module, unit, etc. described above can be implemented by computer program modules.

[0170] The present application also provides a computer readable storage medium, which can be included in the device / apparatus / system described in the above embodiments, or exist separately without being assembled into the device / apparatus / system. The above computer readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of the present application.

[0171] According to an embodiment of the present application, the computer readable storage medium can be a non-volatile computer readable storage medium. For example, it can include but is not limited to a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any appropriate combination thereof. In the present application, the computer readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus or device.

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

[0173] The embodiments of the present application also include a computer program product comprising a computer program containing program code for executing the method provided by the embodiments of the present application, which program code, when the computer program product is run on an electronic device, causes the electronic device to implement the cloud computing-based business system disaster recovery method provided by the embodiments of the present application.

[0174] The computer program, when executed by the processor 1301, performs the aforementioned functions defined in the system / apparatus of embodiments of the present application. According to embodiments of the present application, the system, apparatus, modules, units, etc. described above can be implemented by way of a computer program.

[0175] In one embodiment, the computer program can be stored in a tangible storage medium, such as a compact disc, a memory, etc. In another embodiment, the computer program can be transmitted over a network using a wireless, wireline, etc. communication means. In some embodiments, the computer program can be downloaded and installed by way of a communication port, etc.

[0176] According to embodiments of the present application, the program code of the computer program for performing the methods of embodiments of the present application can be written in any combination of one or more programming languages, including a high-level procedural or object-oriented programming language, and / or an assembly / machine language. Program code can execute entirely on a user's computing device, partly on the user's computing device, as a stand-alone software package, partly on the user's computing device and partly on a remote computing device or entirely on the remote computing device or server. In the latter scenario, the remote computing device can be connected to the user's computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computing device, such as through the Internet using an Internet Service Provider (ISP).

[0177] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions. Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations are not explicitly described in this application. In particular, without departing from the spirit and guidance of this application, the features described in the various embodiments of this application can be combined and / or combined in various ways. All such combinations and / or combinations fall within the scope of this application.

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

Claims

1. A cloud computing-based business system disaster recovery system, comprising: a software application registration and arrangement module, configured to register entity objects of business applications in a business system to a software warehouse, upload entity files of the entity objects, arrange a topology of the business system according to dependency relationships between the entity objects, and configure a disaster recovery strategy required by the business system, wherein the entity objects include software artifacts, 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 and disaster recovery module, configured to automatically deploy all application instances in the business system on a master node after registration of the business applications in the business system is completed, and backup the entity objects and entity files of the business applications to at least one backup node according to the disaster recovery strategy; a failure monitoring and damage decision module, configured to collect states, monitor failures and analyze damage decision of the application instances in the business system, and send an alarm notification when a failure or disaster is monitored; a system recovery and disaster recovery switching module, configured to perform a system recovery operation of the business applications on the master node or the backup node according to the disaster recovery strategy when the alarm notification is received, and perform upstream data flow and business access entry redirection by configuring external access entry information of the business system after the recovery is completed, so as to realize business reorganization recovery and business disaster recovery switching; the system recovery operation includes automatically recovering the business system according to the topology of the business system, the registration information of the software warehouse and the entity files; the system recovery and disaster recovery switching module comprises: an application disaster recovery strategy selection and monitoring unit, configured to select a disaster recovery strategy based on a state of the master node or the backup node, perform the system recovery operation based on the disaster recovery strategy and monitor a recovery state, wherein the disaster recovery strategy includes, from high to low in priority, a local restart strategy, a local rebuild strategy and a remote rebuild strategy. 2.The cloud computing based business system disaster recovery system according to claim 1, wherein the topology is defined based on a business system topology orchestration model, wherein nodes in the business system topology orchestration model represent the entity objects, and connection lines between the nodes represent dependency relationships between the entity objects, and the dependency relationships include relationship types of “runs on”, “depends on”, “connects to”, “belongs to”, and “replica of” between the entity objects. A relationship type “copy in” is used to represent a relationship between multiple copies in a cluster or load balancing in the business system; the nodes and the connection lines both support defining attributes and operations on demand, and the attributes and the operations are used to automatically recover 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 arrangement module supports management and maintenance of basic information of the business applications, and provides a graphical topology arrangement interface.

4. The cloud computing based business system disaster recovery system according to claim 2, wherein, The software application deployment and disaster recovery module comprises: an automatic pipeline execution unit, configured to recursively traverse each node of the topology based on meta-information of the business applications and the topology saved in the software warehouse, determine serial or parallel logic and a sequence from bottom to top according to a relationship between the nodes, construct a sequential pipeline of a directed acyclic graph, and automatically execute the sequential pipeline through a workflow engine; a deployment resource automatic opening unit, configured to call a resource service of a cloud platform based on a cloud resource access interface provided by a basic capability support layer, and automatically apply for, create and open deployment units and external dependencies of the business applications, and create and set cloud products required by the business applications. A dependency injection and service discovery unit is configured to perform dependency injection on application instances of the business application according to the dependencies, and to implement registration, publication and mutual discovery of services through a registration and discovery center provided by the cloud platform; A software and data automatic backup unit is configured to automatically backup software and data of the business application from a master node to one or more backup nodes according to the backup strategy when the business application is registered in the software application registration and arrangement module.

5. The cloud computing based business system disaster recovery system according to claim 1, wherein, The failure monitoring and damage decision module comprises: An information collection unit is configured to sense and collect state information of each application instance in the business system; A decision analysis unit is configured to detect various abnormalities in the state information, aggregate the abnormalities, perform multi-level decision analysis on the abnormalities based on a decision tree, and generate abnormality records of the business application; A failure monitoring unit is configured to comprehensively determine failures and damages of the abnormality records based on various failure determination rules configured, and generate the alarm notification when the determination state is failure or damage.

6. The cloud computing based business system disaster recovery system according to claim 1, wherein, The system recovery and disaster recovery switching module further comprises: A preparation and inspection unit is configured to respond to the alarm notification, check whether states of the master node and the backup node satisfy conditions of disaster recovery according to registration information and a topology structure of the software warehouse, and perform disaster recovery preparation; An application backup strategy selection and monitoring unit is further configured to upgrade the backup strategy when the recovery state is abnormal, and perform the system recovery operation again until the system recovery operation is completed; A system recovery determination unit is configured to determine whether the business application of the business system is successfully recovered; A disaster recovery switching unit is configured to perform redirection of upstream data traffic and business access entry of the business application when the business application is successfully recovered, and recover business access of the business application.

7. The cloud computing based business system disaster recovery system according to claim 6, wherein, The application backup strategy selection and monitoring unit comprises: A strategy selection subunit is configured to sequentially confirm and select one of the local restart strategy, the local rebuild strategy and the remote rebuild strategy according to a priority, and enter a next subunit; A local restart strategy monitoring subunit is configured to perform a local restart task on the master node and monitor a task state when the backup strategy is the local restart strategy, and re-perform the local restart task until a restart number is reached when the local restart task fails; A local rebuild strategy monitoring subunit is configured to perform a local rebuild task on the master node and monitor a task state when the backup strategy is the local rebuild strategy or the local restart task reaches the restart number, and re-perform the local rebuild task until a rebuild number is reached when the local rebuild task fails; A remote rebuild strategy monitoring subunit is configured to perform a remote rebuild task on the backup node and monitor a task state when the backup strategy is the remote rebuild strategy or the local rebuild task reaches the rebuild number, and re-perform the remote rebuild task until the rebuild number is reached when the remote rebuild task fails. 8.A cloud computing-based business system disaster recovery method applied to a cloud computing-based business system disaster recovery system according to any one of claims 1 to 7, comprising: combing entity objects in the business system and dependency relationships between the entity objects according to business applications, wherein the entity objects include software artifacts, external dependencies, deployment units and application instances of the business applications; registering the entity objects of each business application in the business system to a software warehouse, uploading entity files of the entity objects, arranging a topology of the business system according to the dependency relationships, and configuring a 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 registration of the business applications in the business system is completed, automatically deploying and starting all or part of the application instances in the business system on a master node, and synchronously backing up the entity objects and entity files of each business application to at least one backup node according to the disaster recovery strategy; collecting states, monitoring faults and analyzing damage decision of 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, performing a system recovery operation of the business application on the master node or the backup node according to the disaster recovery strategy, and after the recovery is completed, redirecting upstream data traffic and business access entry by configuring external access entry information of the business system, to realize system reorganization and recovery and business disaster recovery switching, wherein the system recovery operation includes recovering the business system according to the topology of the business system, the registration information of the software warehouse and the entity files; selecting a disaster recovery strategy based on a state of the master node or the backup node, performing the system recovery operation and monitoring a recovery state based on the disaster recovery strategy, wherein the disaster recovery strategy includes, from high to low in priority, a local restart strategy, a local rebuild strategy and a remote rebuild strategy. 9.An electronic device, comprising: one or more processors; memory for storing one or more programs, wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to perform the method according to claim 8. 10.A computer-readable storage medium having stored thereon executable instructions that, when executed by a processor, cause the processor to perform the method according to claim 8.

Images