CN110321250B - Disaster recovery method and device for application - Google Patents
Disaster recovery method and device for application Download PDFInfo
- Publication number
- CN110321250B CN110321250B CN201910476229.5A CN201910476229A CN110321250B CN 110321250 B CN110321250 B CN 110321250B CN 201910476229 A CN201910476229 A CN 201910476229A CN 110321250 B CN110321250 B CN 110321250B
- Authority
- CN
- China
- Prior art keywords
- disaster recovery
- application
- target
- application container
- container
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1464—Management of the backup or restore process for networked environments
Abstract
The specification discloses a disaster recovery method and device for applications. According to the disaster recovery requirement of the application, a target application container for disaster recovery can be determined for the application, and a local or remote target disaster recovery type corresponding to the target application container in advance is determined, so that disaster recovery can be executed for the application according to the target application container and the target disaster recovery type.
Description
Technical Field
The present disclosure relates to the field of computer technologies, and in particular, to a disaster recovery method and apparatus for applications.
Background
Disaster tolerance can mean that service systems with the same functions are deployed at the same time at two places, health state monitoring and function switching can be performed between the two places, and when one place system stops working due to accidents (such as fire, earthquake and the like), the whole service system can be switched to the other place, so that the service can continue to work normally.
In one application scenario, the business systems may be deployed on different servers (or server clusters), respectively. The application meeting the user requirements can be divided into an application client and an application server, and a plurality of application servers can be deployed in a server, so that the application server can meet the requirements of the application client through a service system in the server.
In general, a server is called by multiple application servers at the same time, that is, the server provides service support for multiple application servers at the same time, and when a call problem occurs in an application server, disaster recovery needs to be executed. However, in practical application, the probability of calling problems is low for all application servers on the server, but the probability of calling problems is high for a single application server. There is a need for a more efficient disaster recovery mechanism to solve the above problems.
Disclosure of Invention
The embodiment of the specification provides a disaster recovery method and device for an application, which are used for realizing disaster recovery for a single application so as to improve disaster recovery processing efficiency.
In order to solve the above technical problems, the embodiments of the present specification are implemented as follows:
the embodiment of the specification adopts the following technical scheme:
in a first aspect, a disaster recovery method for an application is provided, including:
determining a target application container for disaster recovery for an application according to disaster recovery requirements of the application;
determining a target disaster recovery type corresponding to the target application container, wherein the disaster recovery type comprises local disaster recovery and remote disaster recovery;
and executing disaster recovery on the application according to the target disaster recovery type and the target application container.
In a second aspect, a disaster recovery device for an application is provided, including: a first determining unit, a second determining unit, and a disaster recovery executing unit, wherein,
the first determining unit determines a target application container for disaster recovery for the application according to the disaster recovery requirement of the application;
the second determining unit determines a target disaster recovery type corresponding to the target application container, wherein the disaster recovery type comprises local disaster recovery and remote disaster recovery;
and the disaster recovery executing unit executes disaster recovery for the application according to the target disaster recovery type and the target application container.
In a third aspect, an electronic device is presented, the electronic device comprising:
a processor; and
a memory arranged to store computer executable instructions that, when executed, cause the processor to:
determining a target application container for disaster recovery for an application according to disaster recovery requirements of the application;
determining a target disaster recovery type corresponding to the target application container, wherein the disaster recovery type comprises local disaster recovery and remote disaster recovery;
and executing disaster recovery on the application according to the target disaster recovery type and the target application container.
In a fourth aspect, a computer-readable storage medium storing one or more programs that, when executed by an electronic device comprising a plurality of application programs, cause the electronic device to:
determining a target application container for disaster recovery for an application according to disaster recovery requirements of the application;
determining a target disaster recovery type corresponding to the target application container, wherein the disaster recovery type comprises local disaster recovery and remote disaster recovery;
and executing disaster recovery on the application according to the target disaster recovery type and the target application container.
According to the technical scheme provided by the embodiment, according to the disaster recovery requirement of the application, a target application container for disaster recovery can be determined for the application, and a local or remote target disaster recovery type corresponding to the target application container in advance is determined, so that disaster recovery can be executed for the application according to the target application container and the target disaster recovery type. That is, an application container for disaster recovery can be set for a single application in advance, and when a disaster recovery requirement occurs for an application, a target application container and a corresponding disaster recovery type are determined for the application, so that disaster recovery is performed, and disaster recovery processing for the single application is realized, thereby improving the efficiency of the disaster recovery processing.
Drawings
In order to more clearly illustrate the embodiments or the prior art solutions of the present description, the drawings that are required for the embodiments or the prior art description will be briefly described below, it being apparent that the drawings in the following description are only some of the embodiments described in the present description, and that other drawings may be obtained according to these drawings without inventive faculty for a person skilled in the art.
Fig. 1 is a flow chart of a disaster recovery method for an application according to an embodiment of the present disclosure;
fig. 2 is a schematic diagram of acquiring a preset disaster recovery policy according to an embodiment of the present disclosure;
FIG. 3 is a schematic diagram of a disaster recovery analysis strategy according to an embodiment of the present disclosure;
FIG. 4 is a block diagram of a disaster recovery device for applications provided in an embodiment of the present disclosure;
fig. 5 is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure.
Detailed Description
For the purposes of clarity, technical solutions and advantages of the present specification, the technical solutions of the present specification will be clearly and completely described below with reference to specific embodiments and corresponding drawings. It will be apparent that the described embodiments are only some, but not all, of the embodiments of the present specification. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.
The following describes in detail the technical solutions provided by the embodiments in the present specification with reference to the accompanying drawings.
Example 1
As mentioned above, the server (or server cluster) generally provides service support for multiple application servers at the same time, for example, the server may provide support for application servers (hereinafter, simply referred to as applications) of application 1, application 2, application 3, etc. simultaneously, specifically, the application may implement a service by calling different interfaces in the server, if only application 1 has a disaster tolerance requirement due to a problem of calling interfaces, according to an existing scheme, the calling relationships of all applications are switched to other servers. Obviously, this increases the business risk for other applications. Therefore, disaster recovery needs to be implemented for a single application without affecting normal execution of services by other applications. The embodiment of the specification provides a disaster recovery method for an application, which can be used for realizing disaster recovery for a single application on the premise of not affecting other applications. The specific flow chart is shown in fig. 1, and comprises the following steps:
step 102: and acquiring a preset disaster recovery strategy.
In order to implement single application disaster recovery, a disaster recovery policy for disaster recovery may be set in advance for a single application. Specifically, the disaster recovery policy may include an application container for providing application support, and a corresponding disaster recovery type. Here, the application container may refer to a running environment provided to support normal execution of an application; the disaster recovery types may include at least local disaster recovery (Local Disaster Recovery, LDR) and remote disaster recovery (Remote Disaster Recovery, RDR). In general, a disaster recovery policy preset for a certain application may include a plurality of available application containers, and may respectively correspond to the same or different disaster recovery types.
Here, it may be assumed that an application scenario calls a downstream server for an upstream server, thereby implementing a service of a certain application. In an actual application, for a certain application, an application container for executing the application may be started in an upstream server and a downstream server at the same time, and then a disaster recovery policy preset for the application may be acquired. In one embodiment, a disaster recovery client may be pre-established to obtain a preset disaster recovery policy, and the disaster recovery client may be deployed in an upstream server, which may not only be used to obtain the disaster recovery policy in this step, but also be used as an execution subject of the method. Of course, in practical applications, the device can be deployed at other positions.
In addition, a disaster recovery server can be pre-established, and the disaster recovery server can manage disaster recovery strategies, namely, can manage different disaster recovery strategies aiming at different applications. Specifically, the manager may store disaster recovery policies preset for different applications in the disaster recovery server. And a manager can preset a disaster recovery strategy for the purpose of disaster recovery success rate or convenience in management and control. For example, for applications with high availability requirements, an application container with higher stability and a corresponding disaster recovery type may be preset in the disaster recovery policy. That is, different disaster recovery strategies can be preset for different applications due to different disaster recovery requirements.
In practical application, for convenience in management, the disaster recovery server may assemble the application container and the corresponding disaster recovery type, for example, may assemble parameters corresponding to the application container and the disaster recovery type into JSON (JavaScript Object Notation, JS object numbered musical notation) strings. Further, since a plurality of application containers may be preset for different applications and respectively correspond to disaster recovery types, when assembling JSON strings, a plurality of application containers for the same application and corresponding disaster recovery types may be assembled together.
For the mode of acquiring the disaster recovery strategy, the disaster recovery client can request the disaster recovery strategy for a certain application from the disaster recovery server and can wait for the disaster recovery server to push. Specifically, the effect that the disaster recovery client obtains the disaster recovery policy from the disaster recovery server can be achieved by utilizing DRM (Distributed Resource Management ).
Further, as shown in fig. 2, to obtain a schematic diagram of a preset disaster recovery policy, DRM resources may be deployed in a disaster recovery server, and a manager may store different disaster recovery policies corresponding to different applications in the DRM resources, update and maintain the policies periodically and regularly, and actually may store a unique identifier and a version number of the corresponding application. Accordingly, the disaster recovery client can obtain the disaster recovery policy version number for a certain application from the DRM resource, for example, the disaster recovery client can request from the disaster recovery server according to the application unique identifier, or can receive a message pushed by the disaster recovery server and containing the application unique identifier and the disaster recovery policy version number. After the version number of the disaster recovery strategy corresponding to a certain application is obtained, the disaster recovery client can search whether the corresponding disaster recovery strategy exists locally, if so, the disaster recovery client can directly analyze and cache the disaster recovery strategy to the local of the client, and if not, the disaster recovery client can download the disaster recovery strategy from the disaster recovery server and analyze and cache the disaster recovery strategy to the local of the client. This process may be referred to as an initialization operation of the application disaster recovery.
For the parsing and caching process, the JSON string may be parsed into metadata that can be used by the disaster recovery client to perform disaster recovery, and cached to the local of the disaster recovery client to perform disaster recovery. For example, the foregoing may assemble parameters corresponding to the application container and the disaster recovery type respectively. The corresponding metadata can be resolved during the resolution, and the metadata and the corresponding application unique identifier are cached, so that the disaster recovery client can conveniently execute disaster recovery according to the parameters.
As already described above, the application container may be used to support application execution, whereas in an actual application, the application container may support application execution by providing a call interface and a corresponding call method. In one embodiment, the application container may provide a call interface and corresponding call method. When the application is executed, the calling method can be used for calling the calling interface, so that disaster recovery of the application is executed.
According to the foregoing description, parameters of an application container and a disaster recovery type may be assembled into JSON, and accordingly, a call interface, a corresponding call method, and a corresponding local disaster recovery or remote disaster recovery may be assembled into JSON. Further, in practical application, the call interface, the call method and the disaster recovery type can be assembled through different fields.
For example, the call interface and the corresponding call method may be assembled in unstructured data, and specifically, a service field may be used, and for example, for a remote access (Remote Procedure Call, RPC) function, a name of the call interface and a name of the call method (method) may be included; the disaster recovery type can be assembled by structured data, and a route field can be adopted specifically. In the parsing process, the calling interfaces and the calling methods in the service field can be parsed into a tree structure, and the disaster recovery type in the route field can be parsed into a domain model. It should be noted that, the calling interface, the calling method, and the disaster recovery type may have a corresponding relationship, and by what assembly and analysis methods, the corresponding relationship may be obtained, so as to perform disaster recovery subsequently. In practical application, the local disaster recovery or the remote disaster recovery needs the corresponding downstream server, so that the number of the downstream server providing the application support can be preset in the service field and the route field, and the correspondence between the application container and the disaster recovery type is facilitated.
As shown in fig. 3, to analyze the disaster recovery policy, after the start, the service field and the route field may be analyzed, and after that, integrity, validity, and the like of the analysis result may be checked, and if the check is passed, the cache may be performed.
It should be noted that, in the initialization (including parsing) process, if an error occurs, the application container may not be blocked from being started, and the global disaster recovery policy may not be triggered, but the original planned service may be continuously executed. That is, the implementation of the method does not destroy the global disaster recovery strategy.
In practical application, fuzzy matching can be supported for the call interface, namely, the application container can provide one call interface and correspondingly provide a plurality of call methods. For example, a call interface can be made to correspond to a plurality of call methods by means of a regular expression, so that disaster recovery can be achieved by any one of a plurality of call methods, and a specific call method is not required to be used when disaster recovery is executed, so that the success rate of disaster recovery is improved to a certain extent.
Step 104: and determining a target application container for disaster recovery for the application according to the disaster recovery requirement of the application.
In the foregoing, the application container may be started in the upstream server and the downstream server for implementing the application running, and in practical application, the requirement of disaster recovery may occur only because the downstream server cannot meet the call requirement of the application. Therefore, the disaster recovery client serving as the execution subject can determine whether the disaster recovery requirement appears according to the calling condition of the downstream server. For example, when a call error occurs in a certain application or the call fails, it may be determined that a disaster tolerance requirement occurs in the application.
It should be noted that, the process of determining the disaster recovery requirement of the application may be to take the application as a complete whole, or may be specific to a specific function in the application, for example, the remote access function, the message transmission function, or a specific service in the application described above, that is, in order to implement executing disaster recovery with finer granularity on the application, the method may be applicable to a specific function in the application, and correspondingly, when a disaster recovery policy is preset for the application, different disaster recovery policies may be preset for different specific functions in the application. That is, different application containers can be preset for different functions in the application, and when a disaster tolerance requirement occurs for a certain function, disaster tolerance can be independently executed for the function without affecting normal operation of other functions of the application.
When the disaster recovery client determines that the disaster recovery requirement exists in the application, a target application container for disaster recovery can be determined for the application, and in practical application, the determination basis can be the same as the original application container, namely, the fact that the application is switched to other application containers can be immediately executed is ensured. The original application container herein may refer to an application container that successfully executes a service in the previous time, and has a call problem in the process of executing the service, and may be temporarily discarded. Specifically, the target application container having the same parameters as the original application container can be screened out by the parameters of the application container.
In the foregoing, the application container may provide the call interface and the corresponding call method, and in this step, determining, according to the disaster tolerance requirement of the application, the target application container for disaster tolerance for the application may include: and determining a target application container which is used for disaster tolerance for the application according to the disaster tolerance requirement of the application and has the same calling interface and calling method relative to the original application container. Specifically, when the target application container is determined, the target application container having the same calling interface and the same calling method as those provided by the original application container can be found out from preset application containers which can be used for disaster recovery, so that the success rate of disaster recovery can be ensured as much as possible.
Here, the disaster recovery client may determine the target application container according to whether the application containers are the same, and in actual application, may also determine according to the basis of load balancing or the like.
In the foregoing steps, it has been described that, for different disaster recovery requirements, a disaster recovery policy may be set for the application in advance, so, in order to meet the preset disaster recovery requirement, the application container determined in the step may be matched with the disaster recovery policy, and if the matching is successful, disaster recovery may be performed according to the determined application container, thereby meeting the preset requirement.
In one embodiment, determining a target application container for disaster recovery for an application according to a disaster recovery requirement of the application may include: determining candidate application containers for the application according to disaster tolerance requirements of the application; matching the determined candidate application container with an application container in a preset disaster recovery strategy; and determining the preset application container successfully matched as a target application container. Specifically, since the disaster recovery client may determine the application container for the application according to parameters of the application container and/or load balancing factors, the determined application container may not be preset, that is, may not meet the preset requirement, so that the determined application container may be temporarily determined as a candidate application container, the candidate application container may be matched with the application container in the disaster recovery policy, and if the matching is successful, the successfully matched application container may be determined as the target application container. This manner of operation may also be referred to as policy matching.
In practical application, a switch for disaster recovery of single application can be preset, after the candidate application container is determined, the switch state can be judged, and if the candidate application container is in the closed state, the original application container can be determined as the target application container. That is, after the disaster recovery requirement occurs to the application, if the single-application disaster recovery switch is in the off state, the disaster recovery can be performed by using the original application container. If the switch is in the on state, matching can be performed according to the description above until the target application container is determined.
In the execution process of the application, a plurality of disaster recovery operations may occur, and in order to facilitate the disaster recovery client to execute the operation of the matching policy, a general target application container matching interface may be set in the disaster recovery client, where the interface may converge the disaster recovery policies for different applications. For example, according to the foregoing description, the disaster recovery policy may include a calling interface, a calling method, and a correspondence relation of a disaster recovery type, so that the interface may converge the calling interface, the calling method, and the correspondence relation of the disaster recovery type together, and when the disaster recovery client determines, according to a disaster recovery requirement of an application, a candidate application container, the interface may be called, thereby completing an operation of policy matching more conveniently.
Step 106: and determining a target disaster recovery type corresponding to the target application container.
Step 108: and executing disaster recovery on the application according to the determined target disaster recovery type and the target application container.
If the target application container is determined in the foregoing step, a corresponding target disaster recovery type can be determined according to the determined target application container, where the disaster recovery type may include a Local Disaster Recovery (LDR) and a Remote Disaster Recovery (RDR), as described above, and the step may determine whether the local disaster recovery or the remote disaster recovery needs to be performed. Specifically, a corresponding disaster recovery type may be set for the application container in advance, that is, when the application container is called, a local disaster recovery mode, a remote disaster recovery mode, and the like are required.
The disaster recovery strategy can be preset as described above, and the strategy can include the application container and the corresponding disaster recovery type, that is, the corresponding disaster recovery type is preset for the application container, so that the step can be directly obtained from the disaster recovery strategy. The method is characterized in that the unique identifier of the downstream server can be added in the disaster recovery strategy, so that the calling interface, the calling method, the unique identifier of the downstream server and the disaster recovery type can be associated. The disaster recovery type can be determined by utilizing the association relations.
After the target disaster recovery type and the target application container are determined, disaster recovery can be executed on the single application accordingly, and in one implementation mode, the flow of the application with the disaster recovery requirement can be switched into the target application container in a local disaster recovery or remote disaster recovery mode, so that the application can be normally executed. Therefore, the disaster recovery of a single application is combined with local disaster recovery and remote disaster recovery, and the disaster recovery of the single application is realized on the premise of not affecting other applications.
In the foregoing, the application container may provide a call interface and a corresponding call method, and executing disaster recovery on the application according to the determined target disaster recovery type and the target application container may include: and according to the determined target disaster recovery type, calling a calling interface provided by the target application container by using a calling method provided by the target application container. Specifically, after the call interface provided by the target application container is determined, local disaster recovery or remote disaster recovery can be realized in a corresponding server through a corresponding call method in a local call or remote call mode.
In the foregoing step, the target application container may be determined by means of policy matching. In practical application, for the fact that multiple disaster recovery occurs to an application possibly due to performance, maintenance reasons and the like of a server, in order to improve the disaster recovery efficiency, a target application container and a target disaster recovery type can be stored, so that when the disaster recovery requirement occurs again to the application, and a disaster recovery client determines a candidate application container, the candidate application container can be matched with the stored target application container, and if the matching is successful, the stored target application container and the target disaster recovery type can be directly adopted for disaster recovery.
According to the technical scheme provided by the embodiment, according to the disaster recovery requirement of the application, a target application container for disaster recovery can be determined for the application, and a local or remote target disaster recovery type corresponding to the target application container in advance is determined, so that disaster recovery can be executed for the application according to the target application container and the target disaster recovery type. That is, an application container for disaster recovery can be set for a single application in advance, and when a disaster recovery requirement occurs for an application, a target application container and a corresponding disaster recovery type are determined for the application, so that disaster recovery is performed, and disaster recovery processing for the single application is realized, thereby improving the efficiency of the disaster recovery processing.
Example 2
Based on the same concept, embodiment 2 of the present disclosure provides a disaster recovery device for an application, which may be used to implement disaster recovery for a single application without affecting other applications. The structure of the device is schematically shown in fig. 4, and the device comprises: first determination unit 202, second determination unit 204, and disaster recovery execution unit 206, wherein,
the first determining unit 202 may determine, for an application, a target application container for disaster recovery according to a disaster recovery requirement of the application;
a second determining unit 204, configured to determine a target disaster recovery type corresponding to the target application container, where the disaster recovery type includes a local disaster recovery and a remote disaster recovery;
disaster recovery execution unit 206 may execute disaster recovery for the application according to the target disaster recovery type and the target application container.
In one embodiment, the first determining unit 202 may further determine, according to a disaster tolerance requirement of the application, before determining the target application container for the application:
acquiring a preset disaster recovery strategy, wherein the disaster recovery strategy comprises an application container and a corresponding disaster recovery type; then
A second determination unit 204, which can
Determining candidate application containers for the applications according to disaster tolerance requirements of the applications;
matching the candidate application container with the application container in the disaster recovery strategy;
and determining the successfully matched application container as a target application container.
In one embodiment, the apparatus further comprises a storage unit operable to
And storing the target application container for executing the disaster recovery and the corresponding target disaster recovery type.
In one embodiment, the application container provides a call interface and corresponding call method, then
Disaster recovery execution unit 206 may
And according to the target disaster recovery type, calling a calling interface provided by the target application container by using a calling method provided by the target application container.
In one embodiment, the first determining unit 202 may
And determining a target application container which is used for disaster tolerance for the application according to the disaster tolerance requirement of the application and has the same calling interface and calling method relative to the original application container.
In one embodiment, an application container provides a call interface and a corresponding plurality of call methods.
In one embodiment, the apparatus is adapted for specific functions in an application.
According to the device provided by the embodiment, according to the disaster recovery requirement of the application, a target application container for disaster recovery can be determined for the application, and a local or remote target disaster recovery type corresponding to the target application container in advance is determined, so that disaster recovery can be executed for the application according to the target application container and the target disaster recovery type. That is, an application container for disaster recovery can be set for a single application in advance, and when a disaster recovery requirement occurs for an application, a target application container and a corresponding disaster recovery type are determined for the application, so that disaster recovery is performed, and disaster recovery processing for the single application is realized, thereby improving the efficiency of the disaster recovery processing.
Fig. 5 is a schematic structural view of an electronic device according to an embodiment of the present specification. At the hardware level, the electronic device comprises a processor, optionally an internal bus, a network interface, a memory. The Memory may include a Memory, such as a Random-Access Memory (RAM), and may further include a non-volatile Memory (non-volatile Memory), such as at least 1 disk Memory. Of course, the electronic device may also include hardware required for other services.
The processor, network interface, and memory may be interconnected by an internal bus, which may be an ISA (Industry Standard Architecture ) bus, a PCI (Peripheral Component Interconnect, peripheral component interconnect standard) bus, or EISA (Extended Industry Standard Architecture ) bus, among others. The buses may be classified as address buses, data buses, control buses, etc. For ease of illustration, only one bi-directional arrow is shown in FIG. 5, but not only one bus or type of bus.
And the memory is used for storing programs. In particular, the program may include program code including computer-operating instructions. The memory may include memory and non-volatile storage and provide instructions and data to the processor.
The processor reads the corresponding computer program from the nonvolatile memory to the memory and then runs the computer program to form a disaster recovery device for the application on a logic level. The processor is used for executing the programs stored in the memory and is specifically used for executing the following operations:
determining a target application container for disaster recovery for an application according to disaster recovery requirements of the application;
determining a target disaster recovery type corresponding to the target application container, wherein the disaster recovery type comprises local disaster recovery and remote disaster recovery;
and executing disaster recovery on the application according to the target disaster recovery type and the target application container.
The method executed by the disaster recovery device for application provided in the embodiment shown in fig. 4 of the present disclosure may be applied to a processor or implemented by the processor. The processor may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in a processor or by instructions in the form of software. The processor may be a general-purpose processor, including a central processing unit (Central Processing Unit, CPU), a network processor (Network Processor, NP), etc.; but also digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), field programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. The various methods, steps and logic blocks disclosed in the embodiments of this specification may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The steps of a method disclosed in connection with the embodiments of the present specification may be embodied directly in hardware, in a decoded processor, or in a combination of hardware and software modules in a decoded processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory, and the processor reads the information in the memory and, in combination with its hardware, performs the steps of the above method.
The electronic device may also execute the functions of the embodiment shown in fig. 5 of the disaster recovery device for application provided in the embodiment shown in fig. 4, which is not described herein.
The embodiments of the present specification also provide a computer readable storage medium storing one or more programs, where the one or more programs include instructions, which when executed by an electronic device including a plurality of application programs, enable the electronic device to perform the method performed by the disaster recovery means for applications in the embodiment shown in fig. 4, and specifically are configured to perform:
determining a target application container for disaster recovery for an application according to disaster recovery requirements of the application;
determining a target disaster recovery type corresponding to the target application container, wherein the disaster recovery type comprises local disaster recovery and remote disaster recovery;
and executing disaster recovery on the application according to the target disaster recovery type and the target application container.
The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
For convenience of description, the above devices are described as being functionally divided into various units, respectively. Of course, the functions of each element may be implemented in one or more software and/or hardware elements when implemented in the present specification.
It will be appreciated by those skilled in the art that embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, the present specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
The present description is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the specification. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.
It will be appreciated by those skilled in the art that embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, the present specification may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
The description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments.
The foregoing is merely exemplary of the present disclosure and is not intended to limit the disclosure. Various modifications and alterations to this specification will become apparent to those skilled in the art. Any modifications, equivalent substitutions, improvements, or the like, which are within the spirit and principles of the present description, are intended to be included within the scope of the claims of the present description.
Claims (9)
1. A disaster recovery method for an application, comprising:
determining a target application container for disaster recovery for an application according to disaster recovery requirements of the application, wherein the target application container comprises an application container which is used for disaster recovery and has the same calling interface and calling method relative to an original application container and is determined according to the disaster recovery requirements of the application;
determining a target disaster recovery type corresponding to the target application container, wherein the disaster recovery type comprises local disaster recovery and remote disaster recovery;
and executing disaster recovery on the application according to the target disaster recovery type and the target application container.
2. The method of claim 1, before determining a target application container for an application based on disaster recovery requirements of the application, the method further comprising:
acquiring a preset disaster recovery strategy, wherein the disaster recovery strategy comprises an application container and a corresponding disaster recovery type; then
Determining a target application container for an application according to disaster tolerance requirements of the application, including:
determining candidate application containers for the applications according to disaster tolerance requirements of the applications;
matching the candidate application container with the application container in the disaster recovery strategy;
and determining the successfully matched application container as a target application container.
3. The method of claim 2, the method further comprising:
and storing the target application container and the target disaster recovery type.
4. The method of claim 1, wherein the application container provides a call interface and corresponding call method, then
Executing disaster recovery for the application according to the target application container and the target disaster recovery type, including:
and according to the target disaster recovery type, calling a calling interface provided by the target application container by using a calling method provided by the target application container.
5. The method of claim 1, the application container providing a call interface and a corresponding plurality of call methods.
6. The method of claim 1, adapted for a specific function in the application.
7. A disaster recovery device for an application, comprising: a first determining unit, a second determining unit, and a disaster recovery executing unit, wherein,
the first determining unit determines a target application container for disaster recovery for the application according to the disaster recovery requirement of the application, wherein the target application container comprises application containers which are determined according to the disaster recovery requirement of the application and are used for disaster recovery and have the same calling interface and calling method relative to the original application container;
the second determining unit determines a target disaster recovery type corresponding to the target application container, wherein the disaster recovery type comprises local disaster recovery and remote disaster recovery;
and the disaster recovery executing unit executes disaster recovery for the application according to the target disaster recovery type and the target application container.
8. An electronic device, comprising:
a processor; and
a memory arranged to store computer executable instructions that, when executed, cause the processor to:
determining a target application container for disaster recovery for an application according to disaster recovery requirements of the application, wherein the target application container comprises an application container which is used for disaster recovery and has the same calling interface and calling method relative to an original application container and is determined according to the disaster recovery requirements of the application;
determining a target disaster recovery type corresponding to the target application container, wherein the disaster recovery type comprises local disaster recovery and remote disaster recovery;
and executing disaster recovery on the application according to the target disaster recovery type and the target application container.
9. A computer-readable storage medium storing one or more programs that, when executed by an electronic device comprising a plurality of application programs, cause the electronic device to:
determining a target application container for disaster recovery for an application according to disaster recovery requirements of the application, wherein the target application container comprises an application container which is used for disaster recovery and has the same calling interface and calling method relative to an original application container and is determined according to the disaster recovery requirements of the application;
determining a target disaster recovery type corresponding to the target application container, wherein the disaster recovery type comprises local disaster recovery and remote disaster recovery;
and executing disaster recovery on the application according to the target disaster recovery type and the target application container.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910476229.5A CN110321250B (en) | 2019-06-03 | 2019-06-03 | Disaster recovery method and device for application |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910476229.5A CN110321250B (en) | 2019-06-03 | 2019-06-03 | Disaster recovery method and device for application |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110321250A CN110321250A (en) | 2019-10-11 |
| CN110321250B true CN110321250B (en) | 2023-05-09 |
Family
ID=68119438
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910476229.5A Active CN110321250B (en) | 2019-06-03 | 2019-06-03 | Disaster recovery method and device for application |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110321250B (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104115447A (en) * | 2014-04-14 | 2014-10-22 | 华为技术有限公司 | Allowing destroy scheme configuration method and device under cloud computing architecture |
| WO2015096500A1 (en) * | 2013-12-24 | 2015-07-02 | 华为技术有限公司 | Service migration method and device and disaster tolerance system |
| CN106815097A (en) * | 2017-01-18 | 2017-06-09 | 北京许继电气有限公司 | Database disaster tolerance system and method |
| CN107391294A (en) * | 2017-07-28 | 2017-11-24 | 郑州云海信息技术有限公司 | A kind of method for building up and device of IPSAN disaster tolerance systems |
| CN107977287A (en) * | 2016-10-21 | 2018-05-01 | 中兴通讯股份有限公司 | One kind is using disaster tolerance implementation method, apparatus and system |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10812582B2 (en) * | 2016-03-10 | 2020-10-20 | Vmware, Inc. | Management of applications across nodes using exo-clones |
-
2019
- 2019-06-03 CN CN201910476229.5A patent/CN110321250B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2015096500A1 (en) * | 2013-12-24 | 2015-07-02 | 华为技术有限公司 | Service migration method and device and disaster tolerance system |
| CN104115447A (en) * | 2014-04-14 | 2014-10-22 | 华为技术有限公司 | Allowing destroy scheme configuration method and device under cloud computing architecture |
| CN107977287A (en) * | 2016-10-21 | 2018-05-01 | 中兴通讯股份有限公司 | One kind is using disaster tolerance implementation method, apparatus and system |
| CN106815097A (en) * | 2017-01-18 | 2017-06-09 | 北京许继电气有限公司 | Database disaster tolerance system and method |
| CN107391294A (en) * | 2017-07-28 | 2017-11-24 | 郑州云海信息技术有限公司 | A kind of method for building up and device of IPSAN disaster tolerance systems |
Non-Patent Citations (3)
| Title |
|---|
| A Consistent Backup Mechanism for Disaster Recovery that Using Container Based Virtualization;Yida Xu et al;《2012 Seventh ChinaGrid Annual Conference》;20121025;95-100页 * |
| 基于Kubernetes的分布式ELK日志分析系统;陈建娟等;《电子技术与软件工程》;20160728;211-212,214页 * |
| 网络化制造平台集成框架研究;宋豫川等;《中国机械工程》;20041031(第19期);1765-1769页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110321250A (en) | 2019-10-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107450981B (en) | Block chain consensus method and equipment | |
| US11714675B2 (en) | Virtualization-based transaction handling in an on-demand network code execution system | |
| CN107395659B (en) | Method and device for service acceptance and consensus | |
| EP3605352B1 (en) | Short-link parsing method, apparatus and device | |
| CN110704037B (en) | Rule engine implementation method and device | |
| CN109669709B (en) | Data migration method and data migration system for block chain upgrading | |
| CN108846749B (en) | Partitioned transaction execution system and method based on block chain technology | |
| CN108173706B (en) | Service marking method, device and equipment under multi-service system | |
| US20140280441A1 (en) | Data integration on retargetable engines in a networked environment | |
| CN103377059A (en) | Function module dynamic loading method and device based on jQuery framework | |
| CN107578338B (en) | Service publishing method, device and equipment | |
| CN108459913B (en) | Data parallel processing method and device and server | |
| CN109408232B (en) | Transaction flow-based componentized bus calling execution system | |
| CN111651467B (en) | Block chain node interface issuing and calling method and device | |
| CN112433863A (en) | Micro-service calling method and device, terminal equipment and storage medium | |
| CN116305298B (en) | Method and device for managing computing power resources, storage medium and electronic equipment | |
| US20200310828A1 (en) | Method, function manager and arrangement for handling function calls | |
| CN111694639A (en) | Method and device for updating address of process container and electronic equipment | |
| CN108647102B (en) | Service request processing method and device of heterogeneous system and electronic equipment | |
| CN113010561A (en) | Data acquisition method and device based on super account book and computer system | |
| CN107301097B (en) | Method and device for storing calling java object and reference address information of java object | |
| CN110545328A (en) | Non-invasive service function expansion enhancing method and device and server | |
| CN110321250B (en) | Disaster recovery method and device for application | |
| US10176059B2 (en) | Managing server processes with proxy files | |
| CN110750271B (en) | Service aggregation, method and device for executing aggregated service and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20200923 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman, British Islands Applicant after: Innovative advanced technology Co.,Ltd. Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman, British Islands Applicant before: Advanced innovation technology Co.,Ltd. Effective date of registration: 20200923 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman, British Islands Applicant after: Advanced innovation technology Co.,Ltd. Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands Applicant before: Alibaba Group Holding Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |