Embodiments of the invention generally relates to information technology, and, more particularly, to disaster recovery.
Disaster recovery (DR) planning, in many existing approaches, starts by getting requirements from the administrator (referred to as DR profiles). A common approach is to apply the profile to all of the data associated with the application, that is, the DR planner provides the same level of DR support to all of the application data. In reality, however, a requirement could arise to differentiate the data of the application for the purpose of DR planning (and system management in general). For example, if an application's data has data, log and index, the DR planner can treat the index differently from the data, which in turn can be treated differently from the data.
Unlike existing approaches, data classification (and hence differentiated DR service level agreements (SLAs) for each component of an application) should be an important criterion for DR planning because multiple vendors may have DR planners, and the key differentiator will be the ability to optimize resource utilization using application-specific and/or vertical-market libraries with white-box information about the application's operational and data details. In existing approaches, however, no tools exist in this domain, and some existing approaches disadvantageously use manual techniques that are hand-crafted and/or based on guesses.
Principles of the invention provide techniques for determining disaster recovery (DR) service level agreements (SLAs) for data components of an application. An exemplary method (which may be computer-implemented) for determining one or more disaster recovery (DR) service level agreements (SLAs) for each of one or more components of an application, according to one aspect of the invention, can include steps of identifying one or more components of an application, capturing one or more intra-application data dependencies between the one or more components, and mapping each of the one or more components to a DR profile to determine one or more DR SLAs for each of the one or more components of an application.
One or more embodiments of the invention or elements thereof can be implemented in the form of a computer product/storage medium including a computer usable medium with computer usable program code for performing the method steps indicated. Furthermore, one or more embodiments of the invention or elements thereof can be implemented in the form of an apparatus or system including a memory and at least one processor that is coupled to the memory and operative to perform exemplary method steps. Yet further, in another aspect, one or more embodiments of the invention or elements thereof can be implemented in the form of means for carrying out one or more of the method steps described herein; the means can include hardware module(s), software module(s), or a combination of hardware and software modules.
These and other objects, features and advantages of the embodiments of the invention will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.
Principles of the invention include an intra-application differentiated disaster recovery (DR) planning framework. Additionally, principles of the invention include automatically inferring the DR service level agreements (SLAs) for each component of an application from the DR SLAs of the application in a way such that the differentiated DR SLAs for each component lead to meeting the DR SLAs for the application. Further, in one or more embodiments of the invention, the differentiated DR SLAs present an optimal way to meet the application SLAs by taking the intra-application data dependencies and resource usage of individual components into account. Also, the techniques described herein detail how to represent the dependencies information and use it for DR planning. Also, in one or more embodiments of the invention, application specific data can be provided by vertical market segment consultants and/or experts.
One or more embodiments of the invention include performing intra-application DR based on the type of data, as well as identifying application data dependencies and performing differentiated DR planning. Additionally, unlike the disadvantageous existing approaches, the techniques described herein include differentiated DR planning that has the ability to capture intra-application data dependencies. Further, one or more embodiments of the present invention also include intelligent planning based on category of data, application dependence and sequencing of data sources.
Also, given a DR service level agreement (SLA) for an application, one may derive a set of SLAs for individual data sources. Data dependencies for the application are known and can be used to learn DR SLAs for data sources. As such, one or more embodiments of the invention include creating DR SLAs for data components recursively from DR SLA for the application. One can use application-to-data dependency relationships that capture serial dependency, subsumption, invariance and composition. One can also optimize SLA values based on data update rates and optimize overall cost by dividing the SLA parameter among component SLAs in the most cost-effective manner (for example, where the optimization uses gradient-based optimization). Additionally, one can use templates that capture application-to-data dependencies.
In one or more embodiments of the invention, an application-to-data mapper creates dependency relationships between data. Given a DR SLA for an application, a workflow can be created using the data sources. DR SLA values are assigned to each step in the workflow so that the application SLA is met.
As described herein, one or more embodiments of the invention can include the following intra-application dependencies and characteristics.
Further, because an application is recovered by creating a recovery workflow for all of the data that constitutes the application, in one or more embodiments of the invention, the DR SLA for each component of the application may have some requirements, which can be captured by the following notation.
By way of example, one or more embodiments of the invention can include the following.
Additionally, one or more embodiments of the invention can be formulated as a covering problem on a directed graph where the cover set includes nodes for applications and/or data that need to be recovered. By way of example, the root node can be the application, and edges can have a cost versus DR SLA parameter curve that represents various technologies possible for the data. One can also, for example, let recovery time objective (RTO) represent one of the DR SLAs.
For a given node, aggregation relationships can be used to identify the data and create child nodes. For example, for a DB application A with data storage in a volume V1, log stored in volume V2, and index stored in volume V3, one has the relationship A=[V1, V2, V3]. Similarly, i<j dependencies can captured by creating a special node j′ and adding edges from i to j′, and from j′ to j. If j′ already exists, then one can use the existing j′. The edge [i,j′] has the RTO/cost curve that is the same as j, whereas the edge [j′,j] is zero cost. Also, subsume relationships can be captured by adding another node from the parent to the child with a zero cost edge and a RTO value equal to the reconstruction time. Invariant relationships can be captured by adding another edge to the node with a recovery point objective (RPO) reduced to the invariant limit and an event rule added to the edge.
Additionally, in one or more embodiments of the invention, a RTO/cost for a path can be computed as sum of the RTO/cost of all edges in the path. RTO for a node V can be computed, for example, as the maximum RTO amongst all paths that start from V. Cost for a node V can be computed, for example, as the sum of the cost of all selected paths from that node. Further, edges can be introduced for all possible sequences of recovery.
In one or more embodiments of the invention, one can find an assignment of RTO values to all the nodes such that all of the nodes that are part of the application are covered, the total cost of the nodes is minimized, and the RTO values meet the application SLA. A minimum spanning tree (MST) can be created from the root to all of its dependent nodes, and gradient-based techniques can be used to select the cost-RTO points for the nodes based on which the MST is selected. One can start with minimum cost for all edges, and select the edge to increase cost that leads to highest decrease in overall RTO.
The techniques described herein can also include using templates to identify pre-cooked assignments, wherein the templates are parametric in nature.
As described herein, one or more embodiments of the invention include intra-application differentiated DR planning. Such DR planning can include, for example, the ability to capture the intra-application data dependencies, the ability to include content semantics in DR planning and the ability to map data dependencies on a user-specified application DR profile. Additionally, the techniques described herein include transparently supported differentiated DR for the application, as well as the ability to minimizing DR costs by integrating copy services with backup and point-in-time snapshots. Further, one or more embodiments of the invention include optimizing searches for solutions that integrates the search space of replication and backup options.
DR planning input can also be synchronized with data dictionaries of popular applications (for example, SAP, Peoplesoft), classification engines (for example, data classifiers), application dependency trackers, system/application registries (signifying the updates to the application executables, which would help determine periodicity of copy (that is, a replica of the data)), and vertical industry experts. By way of example, input to a DR planner can include a DR Plan for DB, wherein input from runstats in DB2, for example, would determine the read-only, read-write tablespace(s). This would lead to a differentiated DR plan.
Step 304 includes capturing one or more intra-application data dependencies between the one or more components. Capturing intra-application data dependencies can include obtaining application-specific data from vertical market segment consultants and/or experts.
Step 306 includes mapping each of the one or more components to a DR profile to determine one or more DR SLAs for each of the one or more components of an application (including, for example, deriving a set of SLAs for each of the components). Every component is attached a DR Profile such that if all DR profiles are met for the respective component, the DR profile of the application would be met. By way of example, assume that an application includes two components, data and index. Also assume that the RTO for the application is 10 minutes. Further, assume that index can only be recovered after data is recovered. As such, if a DR profile for data has an RTO of 5 minutes, then the DR profile for index should be less than (10−5=5), that is, 5 or less.
Mapping each of the components to a DR profile can include mapping each of the components to a DR profile (for example, a user-specified application DR profile) such that a recovery time objective (RTO) value is assigned to each of the components such that the components of the application are protected, a total cost of DR solutions is minimized, and the RTO values assigned to the components (in combination) meet the SLA of the application.
The techniques depicted in
Further, one or more embodiments of the invention can include generating a directed graph, wherein a cover set of the graph includes nodes for applications and/or data that need to be recovered. One can capture dependencies between data sources by creating additional nodes and edges, wherein creating additional nodes and edges can include, for a given node, using aggregation relationships to identify data and create child nodes. For example, as detailed herein, for a DB application A with data storage in a volume V1, log stored in volume V2 and index stored in volume V3, one has the relationship A=[V1, V2, V3]. Also, i<j dependencies can captured by creating a special node j′ and adding edges from i to j′, and from j′ to j. If j′ already exists, then one can use the existing j′. The edge [i,j′] has the RTO/cost curve that is the same as j, whereas the edge [j′,j] is zero cost. Subsume relationships can be captured by adding another node from the parent to the child with a zero cost edge and a RTO value equal to the reconstruction time. Further, invariant relationships can be captured by adding another edge to the node with a recovery point objective (RPO) reduced to the invariant limit and an event rule added to the edge.
As described herein, a directed graph can include, for example, a root node that includes the application, and edges that include a cost versus DR SLA parameter curve that represents one or more technologies possible for the data. Also, one can perform an assignment of DR SLAs to each component on the directed graph by creating a minimum spanning tree (MST) from the root to each of its dependent nodes, and using gradient-based techniques to select cost-RTO points for the nodes based on which the MST is selected. By way of example, one can start with minimum cost for all edges and select the edge to increase cost that leads to highest decrease in overall RTO.
One or more embodiments of the invention can also include synchronizing DR planning input with data dictionaries of popular applications, classification engines, application dependency trackers, application registries and/or vertical industry experts.
A variety of techniques, utilizing dedicated hardware, general purpose processors, software, or a combination of the foregoing may be employed to implement the present invention. At least one embodiment of the invention can be implemented in the form of a computer product including a computer usable medium with computer usable program code for performing the method steps indicated. Furthermore, at least one embodiment of the invention can be implemented in the form of an apparatus including a memory and at least one processor that is coupled to the memory and operative to perform exemplary method steps.
At present, it is believed that certain implementations will make substantial use of software running on a general-purpose computer or workstation. With reference to
Accordingly, computer software including instructions or code for performing the methodologies of the invention, as described herein, may be stored in one or more of the associated memory devices (for example, ROM, fixed or removable memory) and, when ready to be utilized, loaded in part or in whole (for example, into RAM) and executed by a CPU. Such software could include, but is not limited to, firmware, resident software, microcode, and the like.
Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium (for example, media 418) providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer usable or computer readable medium can be any apparatus for use by or in connection with the instruction execution system, apparatus, or device.
The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid-state memory (for example, memory 404), magnetic tape, a removable computer diskette (for example, media 418), a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read and/or write (CD-R/W) and DVD.
A data processing system suitable for storing and/or executing program code will include at least one processor 402 coupled directly or indirectly to memory elements 404 through a system bus 410. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
Input and/or output or I/O devices (including but not limited to keyboards 408, displays 406, pointing devices, and the like) can be coupled to the system either directly (such as via bus 410) or through intervening I/O controllers (omitted for clarity).
Network adapters such as network interface 414 may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
In any case, it should be understood that the components illustrated herein may be implemented in various forms of hardware, software, or combinations thereof, for example, application specific integrated circuit(s) (ASICS), functional circuitry, one or more appropriately programmed general purpose digital computers with associated memory, and the like. Given the teachings of the invention provided herein, one of ordinary skill in the related art will be able to contemplate other implementations of the components of the invention.
At least one embodiment of the invention may provide one or more beneficial effects, such as, for example, performing intra-application DR based on the type of data, as well as identifying application data dependencies and perform differentiated DR planning.
Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be made by one skilled in the art without departing from the scope or spirit of the invention.