US20130332771A1 - Methods and apparatus for virtual machine recovery - Google Patents

Methods and apparatus for virtual machine recovery Download PDF

Info

Publication number
US20130332771A1
US20130332771A1 US13/493,304 US201213493304A US2013332771A1 US 20130332771 A1 US20130332771 A1 US 20130332771A1 US 201213493304 A US201213493304 A US 201213493304A US 2013332771 A1 US2013332771 A1 US 2013332771A1
Authority
US
United States
Prior art keywords
data
images
restoration
image
virtual machine
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.)
Granted
Application number
US13/493,304
Other versions
US9170888B2 (en
Inventor
Valentina Salapura
Richard E. Harper
Kyung D. Ryu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US13/493,304 priority Critical patent/US9170888B2/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: RYU, KYUNG D., SALAPURA, VALENTINA, HARPER, RICHARD E.
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION CORRECTIVE ASSIGNMENT TO CORRECT THE THE DOCKET NUMBER IS INCORRECTLY LISTED AS YOR820120179US1 AND MUST BE UPDATED TO THE CORRECT DOCKET NUMBER, YOR920120179US1 PREVIOUSLY RECORDED ON REEL 028352 FRAME 0456. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT. Assignors: RYU, KYUNG D., SALAPURA, VALENTINA, HARPER, RICHARD E.
Publication of US20130332771A1 publication Critical patent/US20130332771A1/en
Application granted granted Critical
Publication of US9170888B2 publication Critical patent/US9170888B2/en
Expired - Fee Related legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1415Saving, restoring, recovering or retrying at system level
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1479Generic software techniques for error detection or fault masking
    • G06F11/1482Generic software techniques for error detection or fault masking by means of middleware or OS functionality
    • G06F11/1484Generic software techniques for error detection or fault masking by means of middleware or OS functionality involving virtual machines
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1415Saving, restoring, recovering or retrying at system level
    • G06F11/1417Boot up procedures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2041Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with more than one idle spare processing component

Definitions

  • the present invention relates generally to information services. More particularly, the invention relates to systems and techniques for restoring a virtual machine after a failure.
  • IT systems typically fill a vital role in the functioning of an enterprise. Failure of a system is frequently unacceptable, and many operations benefit from redundancy, so that a redundant component can quickly take the place of a failed component. Constructing duplicates of a component leads to considerable expense, and one approach to information services and processing that can increase the flexibility of a system and decrease the expense of providing redundancy is the use of virtual machines.
  • a virtual machine does not require that a single specific hardware element be configured to carry out the virtual machine's operation. Instead, one or more hardware elements are configured to carry out the operations of a virtual machine, with these operations being carried out by a single hardware element or spread across a plurality of hardware elements.
  • a virtual machine can be moved from one hardware element or combination of hardware elements to one another, and a hardware element that is running a virtual machine can be redirected to other purposes.
  • a new virtual machine can be constructed in a relatively short time, frequently using automated mechanisms, so that a virtual machine can be replaced without intervention and without expense for hardware replacement.
  • a high availability cluster comprises a plurality of nodes that have access to data identifying the network elements being served by one or more of the nodes.
  • the high availability cluster implements a failover strategy that allows for transfer of operations from a failed component.
  • a virtual machine can be restored by copying the data comprising the virtual machine to a suitable hardware element or combination of hardware elements.
  • a virtual machine may comprise a plurality of logical unit numbers (LUNs) that comprise components of the virtual machine.
  • LUN is a number used to identify a logical unit which is a device addressed by the small computer system interface (SCSI) protocol or similar protocols such as Fiber Channel or internet small computer system interface (iSCSI)
  • SCSI small computer system interface
  • iSCSI internet small computer system interface
  • a LUN may be used with any device which supports read/write operations, such as a tape drive, but is most often used to refer to a logical disc.
  • an apparatus comprises at least one processor and memory storing computer program code.
  • the memory is configured to, with the processor, cause an apparatus to perform actions comprising at least retrieving a data image comprising an operating system of the virtual machine, wherein the data image comprises an image of at least one data element, and wherein the at least one data element whose image is to be captured is selected based on an analysis directed at the most suitable data elements to be used in restoration, and wherein the image comprises at least one of a set of successively ranked images of the at least one data element.
  • the actions further comprise attempting to restore the virtual machine using the stored data image, determining if the restoration was successful, and, if the restoration was unsuccessful, successively attempting restoration using lower ranked data images until a successful restoration is accomplished or all available stored data images have been used.
  • a method comprises retrieving a data image comprising an operating system of the virtual machine, wherein the data image comprises an image of at least one data element, and wherein the at least one data element whose image is to be captured is selected based on an analysis directed at the most suitable data elements to be used in restoration, and wherein the image comprises at least one of a set of successively ranked images of the at least one data element.
  • the method further comprises attempting to restore the virtual machine using the stored data image, determining if the restoration was successful, and, if the restoration was unsuccessful, successively attempting restoration using lower ranked data images until a successful restoration is accomplished or all available stored data images have been used.
  • a computer readable medium stores a program of instructions. Execution of the program of instructions by a processor configures an apparatus to perform actions comprising at least retrieving a data image comprising an operating system of the virtual machine, wherein the data image comprises an image of at least one data element, and wherein the at least one data element whose image is to be captured is selected based on an analysis directed at the most suitable data elements to be used in restoration, and wherein the image comprises at least one of a set of successively ranked images of the at least one data element.
  • the actions further comprise attempting to restore the virtual machine using the stored data image, determining if the restoration was successful, and, if the restoration was unsuccessful, successively attempting restoration using lower ranked data images until a successful restoration is accomplished or all available stored data images have been used.
  • FIG. 1 illustrates an information technology services system according to an embodiment of the present invention
  • FIGS. 2A and 2B illustrate a process of data storage for operating system recovery and operating system recovery according to an embodiment of the present invention
  • FIG. 3 illustrates a set of data management elements used to store data to be used in operating system recovery and to identify the need for operating system recover and perform such recovery when the need is identified.
  • One or more embodiments of the present invention recognize that a virtual machine uses an operating system and that a prior art high-availability (HA) virtual machines typically cannot recover from a failure in which the operating system (OS) has been corrupted or compromised. Instead, an attempt is made to restart the OS image, and if the image has been corrupted or compromised, the restart attempt will fail.
  • OS operating system
  • a virtual machine appears to external entities as a set of services that is being provided, and a failure of an OS image to boot a virtual machine may be difficult to detect. An entity using the services of the virtual machine may recognize that it is not receiving the required services, but may not understand that the service is not being received because of an operating system failure.
  • Embodiments of the present invention also recognize that a snapshot of a previous virtual machine image may be used to recover a virtual machine, provided that the image is uncorrupted.
  • a large virtual machine may comprise many LUNs, each of which requires substantial data for a snapshot. The total amount of data representing a large virtual machine may therefore be enormous, so that a snapshot of the total data may require significant resources to collect and store.
  • Snapshots of the elements of a virtual machine that are to be recovered are best taken relatively frequently, so that taking such relatively frequent snapshots requires substantial time and resources.
  • recovery using a snapshot may not provide access to the most recent data representing conditions prevailing at the time of the time of the failure, but rather the status at the time when snapshot was taken.
  • These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, 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/acts specified in the flowchart and/or block diagram block or blocks.
  • These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
  • the computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
  • the system 100 comprises a plurality of servers 102 A- 102 C, serving a plurality of user terminals 104 A- 104 C over a network 106 .
  • the network 106 may comprise one or more local and wide area networks and may provide access to the public Internet 108 .
  • a virtual machine 110 is illustrated as residing on the server 102 A, with either or both of the servers 102 B and 102 C being available to take over the operations of the virtual machine 110 if the server 102 A fails.
  • the operations of the virtual machine 110 may be distributed over any one or more of the servers 102 A- 102 C, and it will also be recognized the virtual machine 110 may be reconstructed on the server 102 A if the virtual machine 110 fails for some reason other than failure of the server 102 A, so that the server 102 A is still available to implement the virtual machine 110 .
  • the virtual machine 110 uses, and may be constructed based on, data stored in a number of logical unit numbers (LUNs).
  • the logical unit numbers include a root virtual group (root vg) 112 A, and may also include a data virtual group (data vg) 114 .
  • the servers 102 B and 102 C employ root vgs 112 B and 112 C, respectively, and all of the servers 102 A- 102 C have access to the data vg 114 .
  • the virtual machine 110 resides in a logical partition 116 residing on the server 102 A, and logical partitions 118 and 120 reside on the servers 102 B and 102 C, respectively.
  • the logical partitions 116 - 120 have a high availability clustering relationship, allowing for automated failover—that is, reconstruction of the virtual machine 110 on one of the other logical partitions if the logical partition 116 becomes unusable.
  • the logical partitions 116 - 120 may store databases 122 , 124 , and 126 , respectively, and may have available operating systems 128 , 130 , and 132 , respectively.
  • the system 100 may implement a recovery manager 134 , which monitors the state of the virtual machine 110 and chooses data elements that need to be recorded and stored so as to provide for recovery in the case of failure.
  • the recovery manager 134 determines which data needs to be recorded to insure that the virtual machine 110 can be recovered and directs that periodic snapshots be taken of that data.
  • the recovery manager 134 is represented here as a single distinct unit for simplicity of illustration and discussion, but it will be recognized that recovery operations may be distributed across various network elements as desired.
  • Snapshots can be taken of logical unit numbers such as the root virtual group 112 , and may comprise simply the root virtual group 112 , or the root virtual group 112 and one or more of the data virtual group 114 .
  • a snapshot of at least the root virtual group will typically be stored for use in recovery, and snapshots of additional virtual groups or other logical unit numbers will be selected for storage based on factors such as specific user selections, characteristics of the LUNs, or usage of the LUNs.
  • Successive snapshots of selected LUNs will be recorded and stored, suitably in a recovery storage unit 136 , with the selected LUNs being ranked from higher to lower rank according to at least one appropriate criteria. For example, the newest snapshots may be ranked higher, with older snapshots being ranked successively lower.
  • Operation of the virtual machine 110 may be conveniently thought of as being divided into two stages—normal operation and recovery.
  • the recovery manager 134 determines which LUNs are candidates for snapshots.
  • One or more embodiments of the present invention recognize that taking snapshots of all LUNs would be expensive and time-consuming. Therefore, the recovery manager 134 gathers and analyzes data tending to identify LUNs for which snapshots should be taken.
  • Such data may include specific user inputs designating LUNs.
  • Data may also be collected relating to syntactic or content analysis of LUN data, or relating to the specific configuration, construction, or use of an LUN. For example, data relating to the configuration, construction, or use of an LUN may relate to whether the LUN is a root virtual group or a data virtual group.
  • Additional data that may be collected may relate to whether the LUN is small or large, the access rate of the LUN, such as whether access is rare or frequent, or the access pattern of the LUN, such as whether access is random or streaming.
  • the recovery manager 134 analyzes the collected data and identifies LUNs for which data should be recorded. Such collection and analysis may be conducted on any schedule desired, with different LUNs being identified for recording of LUN snapshots as the data being analyzed changes. Information identifying the LUNs for which snapshots are to be recorded may be stored in an LUN identification database 138 , which may conveniently reside in the recovery storage unit 136 .
  • the recovery manager 134 Periodically, for example daily, the recovery manager 134 takes a snapshot of the selected LUNs, suitably storing snapshot data in an LUN snapshot database 140 .
  • a snapshot history comprising multiple snapshots is maintained.
  • the snapshot history may extend back through a specified or computed time period, or may comprise as many snapshots as can be stored in a storage space allocated to the purpose.
  • the snapshot history can be expected to include at least one snapshot, and each snapshot can be expected to include at least the root virtual group for the virtual machine in question.
  • the recovery manager 134 monitors the virtual machine 110 for failure. Monitoring may, for example, use out of band machine learning technology, out of band heartbeats, in-band crash or hang detection, endpoint manager agents, or other suitable mechanisms.
  • the recovery manager 134 also monitors the host element of the virtual machine 110 for failure. In the present exemplary case, this is the server 104 A. Such monitoring may be accomplished, for example, by monitoring a hardware management console error state, using clustering technology, using endpoint manager agents in the host operating system, or any other suitable mechanism.
  • the recovery manager 134 implements a prescribed procedure to recover the virtual machine.
  • the virtual machine fails, or when the host on which the virtual machine is operating fails, an attempt is made to reboot the virtual machine.
  • the recovery manager 134 determines whether or not the boot was successful, for example, using machine learning boot detection. Any other suitable mechanism may also be used. If the virtual machine has not booted successfully, the root virtual group is restored from the most recent root virtual group snapshot. The data virtual group may remain at the crash state. First, particularly if the failure is not due to a failure of the host, the data virtual group may not be corrupted. Second, in many cases, data, such as fsck, journal replay, log replay, and other data, may be successfully recovered from a data virtual group crash image.
  • the next most recent root virtual group snapshot is used to recover the root virtual group and another reboot attempt is made.
  • the recovery manager 134 again determines if the reboot is successful. Successive recovery and reboot attempts may be made using successfully older root vg images.
  • a data vg snapshot or backup tape will provide for a complete restoration of a virtual machine such as the virtual machine 110 as of the time of the data vg snapshot or backup tape, but may be expected to be older than a root vg snapshot.
  • a data vg is typically much larger, on the order of tens or more times larger than a root vg snapshot, and so data vg snapshots can be expected to be made less frequently than root vg snapshots, in order to save space.
  • a backup tape can also be expected to be made less frequently than a root vg snapshot.
  • making or reading of a data tape may require intervention, because a data tape will typically be made using specialized equipment and media, and if multiple backup tapes are to be made, a previously made backup tape will often need to be removed before a new media can be mounted.
  • restoration is to be performed using a backup tape, the tape from which restoration is to be performed will often need to be mounted so that restoration can be performed.
  • the automated saving of root vg snapshots and automated restoration using such root vg snapshots avoids a need to use data vg snapshots or perform backup tape restoration in many cases, providing for a more efficient restoration.
  • the automated saving of multiple successive root vg snapshots provides for a greater likelihood that a successful restoration from a root vg will be possible.
  • FIG. 2 illustrates a process 200 according to an embodiment of the present invention.
  • operation of the system including operation of the virtual machines is analyzed.
  • the analysis is performed to identify logical unit numbers (LUNs) that are candidates for recording to a snapshot and which are candidates for crash image recovery.
  • LUNs logical unit numbers
  • the analysis may be based on user input, syntactic analysis, content analysis, construction, size, access rate, access pattern, or other suitable criteria or information.
  • Each virtual machine will typically use a root vg for which a snapshot can be recorded, and one or more data vgs can also be used by each virtual machine.
  • the analysis identifies the root vg for each virtual machine as well as the data vgs, if any, for which snapshots are to be recorded.
  • identification information for the LUNs for which snapshots are to be taken is stored.
  • snapshots are periodically taken of the identified LUNs.
  • one or more of the virtual machines is monitored for failure.
  • one or more hosts on which virtual machines reside are monitored for failure.
  • step 212 when a failure of a virtual machine is detected, an attempt is made to reboot the virtual machine. If the reboot is successful, the process returns to step 202 . If the reboot is not successful, the process continues to step 214 and an attempt is made to restore the root vg from the most recent snapshot for which a failed attempt has not been made. If the reboot is successful, the process proceeds to step 216 and data is recovered from a data vg crash image. The process then returns to step 202 . If the reboot fails, step 214 is repeated for the next most recent snapshot, through all available root vg snapshots. If all root vg snapshots are used without a successful reboot, the process proceeds to step 218 and the operating system image is restored through other means, such as from a data vg snapshot or a tape backup.
  • FIG. 3 illustrates additional details of the server 104 A, recovery manager 134 , and the recovery storage unit 136 .
  • the server 104 A comprises a processor 302 , memory 304 , and storage 306 , communicating over a bus 308 .
  • the server 104 A hosts the virtual machine 110 , implemented as software, which may be part of software 310 residing in storage and transferred to memory 304 as needed for execution by the processor 302 .
  • the server 104 A also employs data 312 , such as the root vg 112 A and one or more data vgs such as the data vg 114 , used by the server 104 A under the control of various software elements such as the virtual machine 110 .
  • the recovery manager 134 comprises a processor 320 , memory 322 , and storage 324 , communicating over a bus 326
  • the recovery storage unit 136 comprises a processor 330 , memory 332 , and storage 334 , communicating over a bus 336
  • the recovery manager 134 employs data 340 and programs 342 and the recovery storage unit 136 employs data 344 and programs 346 .
  • the data 344 may be the LUN identification database 138 .
  • the recovery manager 134 may suitably employ an LUN analysis and storage module 348 , a virtual machine failure monitoring module 350 , and a restoration module 352 .
  • the LUN analysis and storage module 348 examines data relating to the various LUNs that may be candidates for snapshots and identifies the LUNs for which snapshots should be recorded.
  • the LUN analysis and storage module 348 also creates and updates a database 356 of LUNs whose snapshots are to be taken, and periodically directs creation of snapshots and their storage in a snapshot database 360 of the recovery storage unit 136 .
  • the virtual machine failure monitoring module 350 monitors virtual machines such as the virtual machine 110 , and their hosts such as the host 104 A, for failure, and the restoration module 352 directs restoration procedures, including reboots and reconstruction of images, and evaluates reboot attempts.
  • aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
  • the computer readable medium may be a computer readable signal medium or a computer readable storage medium.
  • a computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.
  • a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
  • a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof.
  • a computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
  • Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
  • Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages.
  • the program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.
  • the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
  • LAN local area network
  • WAN wide area network
  • Internet Service Provider for example, AT&T, MCI, Sprint, EarthLink, MSN, GTE, etc.
  • Various embodiments of the present invention provide a more automated mechanism for restoring virtual machines following operating system failures, as well as mechanisms to provide for an efficient use of storage space by taking snapshots of only a limited set of data for use in restoration.
  • the data to be included in the set is identified using analysis directed toward identifying data best directed toward the restoration.

Abstract

Methods and apparatus for recovery of virtual machine failure. A succession of data images is captured, with each of the data images comprising an operating system of the virtual machine. The data images are images of data elements chosen based at least in part on their suitability for virtual machine restoration. Upon detection of a virtual machine failure, an attempt is made to restore the virtual machine using the highest ranked. If the attempt fails, further attempts are made using lower ranked data images, until an attempt is successful or all available data images have been used.

Description

    FIELD OF THE INVENTION
  • The present invention relates generally to information services. More particularly, the invention relates to systems and techniques for restoring a virtual machine after a failure.
  • BACKGROUND
  • Information technology (IT) systems typically fill a vital role in the functioning of an enterprise. Failure of a system is frequently unacceptable, and many operations benefit from redundancy, so that a redundant component can quickly take the place of a failed component. Constructing duplicates of a component leads to considerable expense, and one approach to information services and processing that can increase the flexibility of a system and decrease the expense of providing redundancy is the use of virtual machines. A virtual machine does not require that a single specific hardware element be configured to carry out the virtual machine's operation. Instead, one or more hardware elements are configured to carry out the operations of a virtual machine, with these operations being carried out by a single hardware element or spread across a plurality of hardware elements. A virtual machine can be moved from one hardware element or combination of hardware elements to one another, and a hardware element that is running a virtual machine can be redirected to other purposes. In addition, if the data used to construct a virtual machine is available, a new virtual machine can be constructed in a relatively short time, frequently using automated mechanisms, so that a virtual machine can be replaced without intervention and without expense for hardware replacement.
  • One mechanism for providing redundancy for information services is through the use of a high availability system, in which a hardware element, such as a server, belongs to a high availability cluster. A high availability cluster comprises a plurality of nodes that have access to data identifying the network elements being served by one or more of the nodes. The high availability cluster implements a failover strategy that allows for transfer of operations from a failed component.
  • One mechanism for providing a high availability system is to use virtual machines for the components for which redundancy is to be provided. A virtual machine can be restored by copying the data comprising the virtual machine to a suitable hardware element or combination of hardware elements. A virtual machine may comprise a plurality of logical unit numbers (LUNs) that comprise components of the virtual machine. A LUN is a number used to identify a logical unit which is a device addressed by the small computer system interface (SCSI) protocol or similar protocols such as Fiber Channel or internet small computer system interface (iSCSI) A LUN may be used with any device which supports read/write operations, such as a tape drive, but is most often used to refer to a logical disc.
  • SUMMARY
  • According to one embodiment, an apparatus comprises at least one processor and memory storing computer program code. The memory is configured to, with the processor, cause an apparatus to perform actions comprising at least retrieving a data image comprising an operating system of the virtual machine, wherein the data image comprises an image of at least one data element, and wherein the at least one data element whose image is to be captured is selected based on an analysis directed at the most suitable data elements to be used in restoration, and wherein the image comprises at least one of a set of successively ranked images of the at least one data element. The actions further comprise attempting to restore the virtual machine using the stored data image, determining if the restoration was successful, and, if the restoration was unsuccessful, successively attempting restoration using lower ranked data images until a successful restoration is accomplished or all available stored data images have been used.
  • According to one embodiment, a method comprises retrieving a data image comprising an operating system of the virtual machine, wherein the data image comprises an image of at least one data element, and wherein the at least one data element whose image is to be captured is selected based on an analysis directed at the most suitable data elements to be used in restoration, and wherein the image comprises at least one of a set of successively ranked images of the at least one data element. The method further comprises attempting to restore the virtual machine using the stored data image, determining if the restoration was successful, and, if the restoration was unsuccessful, successively attempting restoration using lower ranked data images until a successful restoration is accomplished or all available stored data images have been used.
  • According to one embodiment, a computer readable medium stores a program of instructions. Execution of the program of instructions by a processor configures an apparatus to perform actions comprising at least retrieving a data image comprising an operating system of the virtual machine, wherein the data image comprises an image of at least one data element, and wherein the at least one data element whose image is to be captured is selected based on an analysis directed at the most suitable data elements to be used in restoration, and wherein the image comprises at least one of a set of successively ranked images of the at least one data element. The actions further comprise attempting to restore the virtual machine using the stored data image, determining if the restoration was successful, and, if the restoration was unsuccessful, successively attempting restoration using lower ranked data images until a successful restoration is accomplished or all available stored data images have been used.
  • BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
  • FIG. 1 illustrates an information technology services system according to an embodiment of the present invention;
  • FIGS. 2A and 2B illustrate a process of data storage for operating system recovery and operating system recovery according to an embodiment of the present invention; and
  • FIG. 3 illustrates a set of data management elements used to store data to be used in operating system recovery and to identify the need for operating system recover and perform such recovery when the need is identified.
  • DETAILED DESCRIPTION
  • The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
  • One or more embodiments of the present invention recognize that a virtual machine uses an operating system and that a prior art high-availability (HA) virtual machines typically cannot recover from a failure in which the operating system (OS) has been corrupted or compromised. Instead, an attempt is made to restart the OS image, and if the image has been corrupted or compromised, the restart attempt will fail. In addition, a virtual machine appears to external entities as a set of services that is being provided, and a failure of an OS image to boot a virtual machine may be difficult to detect. An entity using the services of the virtual machine may recognize that it is not receiving the required services, but may not understand that the service is not being received because of an operating system failure.
  • Embodiments of the present invention also recognize that a snapshot of a previous virtual machine image may be used to recover a virtual machine, provided that the image is uncorrupted. However, a large virtual machine may comprise many LUNs, each of which requires substantial data for a snapshot. The total amount of data representing a large virtual machine may therefore be enormous, so that a snapshot of the total data may require significant resources to collect and store.
  • Snapshots of the elements of a virtual machine that are to be recovered are best taken relatively frequently, so that taking such relatively frequent snapshots requires substantial time and resources. In addition, recovery using a snapshot may not provide access to the most recent data representing conditions prevailing at the time of the time of the failure, but rather the status at the time when snapshot was taken.
  • Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of 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, 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/acts specified in the flowchart and/or block diagram block or blocks.
  • These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
  • The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
  • Turning now to FIG. 1, an information technology services system 100 according to an embodiment of the present invention is illustrated. The system 100 comprises a plurality of servers 102A-102C, serving a plurality of user terminals 104A-104C over a network 106. The network 106 may comprise one or more local and wide area networks and may provide access to the public Internet 108. In the presently illustrated example, a virtual machine 110 is illustrated as residing on the server 102A, with either or both of the servers 102B and 102C being available to take over the operations of the virtual machine 110 if the server 102A fails. However, it will be recognized that the operations of the virtual machine 110 may be distributed over any one or more of the servers 102A-102C, and it will also be recognized the virtual machine 110 may be reconstructed on the server 102A if the virtual machine 110 fails for some reason other than failure of the server 102A, so that the server 102A is still available to implement the virtual machine 110.
  • The virtual machine 110 uses, and may be constructed based on, data stored in a number of logical unit numbers (LUNs). The logical unit numbers include a root virtual group (root vg) 112A, and may also include a data virtual group (data vg) 114. The servers 102B and 102C employ root vgs 112B and 112C, respectively, and all of the servers 102A-102C have access to the data vg 114.
  • In the present example, the virtual machine 110 resides in a logical partition 116 residing on the server 102A, and logical partitions 118 and 120 reside on the servers 102B and 102C, respectively. The logical partitions 116-120 have a high availability clustering relationship, allowing for automated failover—that is, reconstruction of the virtual machine 110 on one of the other logical partitions if the logical partition 116 becomes unusable.
  • The logical partitions 116-120 may store databases 122, 124, and 126, respectively, and may have available operating systems 128, 130, and 132, respectively.
  • The system 100 may implement a recovery manager 134, which monitors the state of the virtual machine 110 and chooses data elements that need to be recorded and stored so as to provide for recovery in the case of failure. The recovery manager 134 determines which data needs to be recorded to insure that the virtual machine 110 can be recovered and directs that periodic snapshots be taken of that data. The recovery manager 134 is represented here as a single distinct unit for simplicity of illustration and discussion, but it will be recognized that recovery operations may be distributed across various network elements as desired.
  • Snapshots can be taken of logical unit numbers such as the root virtual group 112, and may comprise simply the root virtual group 112, or the root virtual group 112 and one or more of the data virtual group 114. In one or more embodiments of the invention, a snapshot of at least the root virtual group will typically be stored for use in recovery, and snapshots of additional virtual groups or other logical unit numbers will be selected for storage based on factors such as specific user selections, characteristics of the LUNs, or usage of the LUNs. Successive snapshots of selected LUNs will be recorded and stored, suitably in a recovery storage unit 136, with the selected LUNs being ranked from higher to lower rank according to at least one appropriate criteria. For example, the newest snapshots may be ranked higher, with older snapshots being ranked successively lower.
  • Operation of the virtual machine 110 may be conveniently thought of as being divided into two stages—normal operation and recovery. During normal operation, the recovery manager 134 determines which LUNs are candidates for snapshots. One or more embodiments of the present invention recognize that taking snapshots of all LUNs would be expensive and time-consuming. Therefore, the recovery manager 134 gathers and analyzes data tending to identify LUNs for which snapshots should be taken. Such data may include specific user inputs designating LUNs. Data may also be collected relating to syntactic or content analysis of LUN data, or relating to the specific configuration, construction, or use of an LUN. For example, data relating to the configuration, construction, or use of an LUN may relate to whether the LUN is a root virtual group or a data virtual group. Additional data that may be collected may relate to whether the LUN is small or large, the access rate of the LUN, such as whether access is rare or frequent, or the access pattern of the LUN, such as whether access is random or streaming. The recovery manager 134 analyzes the collected data and identifies LUNs for which data should be recorded. Such collection and analysis may be conducted on any schedule desired, with different LUNs being identified for recording of LUN snapshots as the data being analyzed changes. Information identifying the LUNs for which snapshots are to be recorded may be stored in an LUN identification database 138, which may conveniently reside in the recovery storage unit 136.
  • Periodically, for example daily, the recovery manager 134 takes a snapshot of the selected LUNs, suitably storing snapshot data in an LUN snapshot database 140. In one or more embodiments of the invention, a snapshot history comprising multiple snapshots is maintained. The snapshot history may extend back through a specified or computed time period, or may comprise as many snapshots as can be stored in a storage space allocated to the purpose. The snapshot history can be expected to include at least one snapshot, and each snapshot can be expected to include at least the root virtual group for the virtual machine in question.
  • During the normal operation stage, the recovery manager 134 monitors the virtual machine 110 for failure. Monitoring may, for example, use out of band machine learning technology, out of band heartbeats, in-band crash or hang detection, endpoint manager agents, or other suitable mechanisms. The recovery manager 134 also monitors the host element of the virtual machine 110 for failure. In the present exemplary case, this is the server 104A. Such monitoring may be accomplished, for example, by monitoring a hardware management console error state, using clustering technology, using endpoint manager agents in the host operating system, or any other suitable mechanism.
  • If a failure is detected, the recovery manager 134 implements a prescribed procedure to recover the virtual machine. When the virtual machine fails, or when the host on which the virtual machine is operating fails, an attempt is made to reboot the virtual machine. The recovery manager 134 then determines whether or not the boot was successful, for example, using machine learning boot detection. Any other suitable mechanism may also be used. If the virtual machine has not booted successfully, the root virtual group is restored from the most recent root virtual group snapshot. The data virtual group may remain at the crash state. First, particularly if the failure is not due to a failure of the host, the data virtual group may not be corrupted. Second, in many cases, data, such as fsck, journal replay, log replay, and other data, may be successfully recovered from a data virtual group crash image.
  • If the virtual machine is unable to reboot, the next most recent root virtual group snapshot is used to recover the root virtual group and another reboot attempt is made. The recovery manager 134 again determines if the reboot is successful. Successive recovery and reboot attempts may be made using successfully older root vg images.
  • If a reboot cannot be accomplished using any available root vg image snapshot, data may be restored using a data vg snapshot or a backup tape. A data vg snapshot or backup tape will provide for a complete restoration of a virtual machine such as the virtual machine 110 as of the time of the data vg snapshot or backup tape, but may be expected to be older than a root vg snapshot. A data vg is typically much larger, on the order of tens or more times larger than a root vg snapshot, and so data vg snapshots can be expected to be made less frequently than root vg snapshots, in order to save space. A backup tape can also be expected to be made less frequently than a root vg snapshot. In addition, making or reading of a data tape may require intervention, because a data tape will typically be made using specialized equipment and media, and if multiple backup tapes are to be made, a previously made backup tape will often need to be removed before a new media can be mounted. In addition, if restoration is to be performed using a backup tape, the tape from which restoration is to be performed will often need to be mounted so that restoration can be performed. The automated saving of root vg snapshots and automated restoration using such root vg snapshots avoids a need to use data vg snapshots or perform backup tape restoration in many cases, providing for a more efficient restoration. In addition, the automated saving of multiple successive root vg snapshots provides for a greater likelihood that a successful restoration from a root vg will be possible.
  • FIG. 2 illustrates a process 200 according to an embodiment of the present invention. At step 202, during normal operation of an information system that includes one or more virtual machines, operation of the system, including operation of the virtual machines is analyzed. The analysis is performed to identify logical unit numbers (LUNs) that are candidates for recording to a snapshot and which are candidates for crash image recovery. The analysis may be based on user input, syntactic analysis, content analysis, construction, size, access rate, access pattern, or other suitable criteria or information. Each virtual machine will typically use a root vg for which a snapshot can be recorded, and one or more data vgs can also be used by each virtual machine. The analysis identifies the root vg for each virtual machine as well as the data vgs, if any, for which snapshots are to be recorded. At step 204, identification information for the LUNs for which snapshots are to be taken is stored. At step 206, snapshots are periodically taken of the identified LUNs. At step 208, which may be performed concurrently with steps 202-206, one or more of the virtual machines is monitored for failure. At step 210, which may be performed concurrently with steps 202-208, one or more hosts on which virtual machines reside are monitored for failure.
  • At step 212, when a failure of a virtual machine is detected, an attempt is made to reboot the virtual machine. If the reboot is successful, the process returns to step 202. If the reboot is not successful, the process continues to step 214 and an attempt is made to restore the root vg from the most recent snapshot for which a failed attempt has not been made. If the reboot is successful, the process proceeds to step 216 and data is recovered from a data vg crash image. The process then returns to step 202. If the reboot fails, step 214 is repeated for the next most recent snapshot, through all available root vg snapshots. If all root vg snapshots are used without a successful reboot, the process proceeds to step 218 and the operating system image is restored through other means, such as from a data vg snapshot or a tape backup.
  • FIG. 3 illustrates additional details of the server 104A, recovery manager 134, and the recovery storage unit 136. The server 104A comprises a processor 302, memory 304, and storage 306, communicating over a bus 308. The server 104A hosts the virtual machine 110, implemented as software, which may be part of software 310 residing in storage and transferred to memory 304 as needed for execution by the processor 302. The server 104A also employs data 312, such as the root vg 112A and one or more data vgs such as the data vg 114, used by the server 104A under the control of various software elements such as the virtual machine 110. The recovery manager 134 comprises a processor 320, memory 322, and storage 324, communicating over a bus 326, and the recovery storage unit 136 comprises a processor 330, memory 332, and storage 334, communicating over a bus 336. The recovery manager 134 employs data 340 and programs 342 and the recovery storage unit 136 employs data 344 and programs 346. Among the data 344 may be the LUN identification database 138.
  • The recovery manager 134 may suitably employ an LUN analysis and storage module 348, a virtual machine failure monitoring module 350, and a restoration module 352. The LUN analysis and storage module 348 examines data relating to the various LUNs that may be candidates for snapshots and identifies the LUNs for which snapshots should be recorded. The LUN analysis and storage module 348 also creates and updates a database 356 of LUNs whose snapshots are to be taken, and periodically directs creation of snapshots and their storage in a snapshot database 360 of the recovery storage unit 136. The virtual machine failure monitoring module 350 monitors virtual machines such as the virtual machine 110, and their hosts such as the host 104A, for failure, and the restoration module 352 directs restoration procedures, including reboots and reconstruction of images, and evaluates reboot attempts.
  • As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
  • Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, 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), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
  • A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
  • Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
  • Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
  • Various embodiments of the present invention provide a more automated mechanism for restoring virtual machines following operating system failures, as well as mechanisms to provide for an efficient use of storage space by taking snapshots of only a limited set of data for use in restoration. The data to be included in the set is identified using analysis directed toward identifying data best directed toward the restoration.
  • The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiments were chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claims (20)

We claim:
1. An apparatus comprising:
at least one memory comprising instructions; and
at least one processor operatively coupled to the at least one memory, the at least one processor configured by the instructions to cause the apparatus to perform operations comprising:
retrieving a data image comprising an operating system of the virtual machine, wherein the data image comprises an image of at least one data element, and wherein the at least one data element whose image is to be captured is selected based on an analysis directed at the most suitable data elements to be used in restoration, and wherein the image comprises at least one of a set of successively ranked images of the at least one data element;
attempting to restore the virtual machine using the stored data image;
determining if the restoration was successful; and
if the restoration was unsuccessful, successively attempting restoration using lower ranked data images until a successful restoration is accomplished or all available stored data images have been used.
2. The apparatus of claim 1, wherein the at least one data element is a logical unit number.
3. The apparatus of claim 2, wherein the at least one data element comprises a root virtual group.
4. The apparatus of claim 1, wherein selection of the at least one data element is based at least in part on content analysis of logical unit number data.
5. The apparatus of claim 2, wherein selection of a logical unit number is based at least in part on whether the logical unit number is a root virtual group or a data virtual group.
6. The apparatus of claim 3, wherein selection of a logical unit number is based at least in part on a relative size of the logical unit number.
7. The apparatus of claim 1, wherein attempting to restore the machine using the stored data is preceded by an attempt to reboot the machine, and the attempt to restore the machine using the stored data is performed only if the reboot attempt fails.
8. The apparatus of claim 1, wherein the succession of stored data images are images of a root virtual group, and wherein the actions further comprise, if all attempts to restore the virtual machine using data images fail, performing a further attempt using a data virtual group.
9. The apparatus of claim 3, wherein the at least one logical unit number further comprises a data virtual group.
10. The apparatus of claim 1, wherein the set of successively captured and stored data images occupies storage space allocated to the storage of data images, and wherein retention of data images is based at least in part on the total storage space allocated to the storage of data images.
11. A method comprising:
retrieving a data image comprising an operating system of the virtual machine, wherein the data image comprises an image of at least one data element, and wherein the at least one data element whose image is to be captured is selected based on an analysis directed at the most suitable data elements to be used in restoration, and wherein the image comprises at least one of a set of successively ranked images of the at least one data element;
attempting to restore the virtual machine using the stored data image;
determining if the restoration was successful; and
if the restoration was unsuccessful, successively attempting restoration using lower ranked data images until a successful restoration is accomplished or all available stored data images have been used.
12. The method of claim 11, wherein attempting to restore the machine using the stored data is preceded by an attempt to reboot the machine, and the attempt to restore the machine using the stored data is performed only if the reboot attempt fails.
13. The apparatus of claim 11, wherein the succession of stored data images are images of a root virtual group, and wherein the actions further comprise, if all attempts to restore the virtual machine using data images fail, performing a further attempt using a data virtual group.
14. The method of claim 11, wherein the at least one data element is a logical unit number.
15. The method of claim 14, wherein the at least one data element comprises a root virtual group.
16. A computer readable medium tangibly embodying a program of machine-readable instructions executable by a digital processing apparatus to perform operations comprising:
retrieving a data image comprising an operating system of the virtual machine, wherein the data image comprises an image of at least one data element, and wherein the at least one data element whose image is to be captured is selected based on an analysis directed at the most suitable data elements to be used in restoration, and wherein the image comprises at least one of a set of successively ranked images of the at least one data element;
attempting to restore the virtual machine using the stored data image;
determining if the restoration was successful; and
if the restoration was unsuccessful, successively attempting restoration using lower ranked data images until a successful restoration is accomplished or all available stored data images have been used.
17. The computer readable medium of claim 16, wherein attempting to restore the machine using the stored data is preceded by an attempt to reboot the machine, and the attempt to restore the machine using the stored data is performed only if the reboot attempt fails.
18. The computer readable medium of claim 16, wherein the succession of stored data images are images of a root virtual group, and wherein the actions further comprise, if all attempts to restore the virtual machine using data images fail, performing a further attempt using a data virtual group.
19. The computer readable medium of claim 16, wherein the at least one data element is a logical unit number.
20. The computer readable medium of claim 19, wherein the at least one data element comprises a root virtual group.
US13/493,304 2012-06-11 2012-06-11 Methods and apparatus for virtual machine recovery Expired - Fee Related US9170888B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/493,304 US9170888B2 (en) 2012-06-11 2012-06-11 Methods and apparatus for virtual machine recovery

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US13/493,304 US9170888B2 (en) 2012-06-11 2012-06-11 Methods and apparatus for virtual machine recovery

Publications (2)

Publication Number Publication Date
US20130332771A1 true US20130332771A1 (en) 2013-12-12
US9170888B2 US9170888B2 (en) 2015-10-27

Family

ID=49716272

Family Applications (1)

Application Number Title Priority Date Filing Date
US13/493,304 Expired - Fee Related US9170888B2 (en) 2012-06-11 2012-06-11 Methods and apparatus for virtual machine recovery

Country Status (1)

Country Link
US (1) US9170888B2 (en)

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150033065A1 (en) * 2013-07-24 2015-01-29 Lsi Corporation Solid state drive emergency pre-boot application providing expanded data recovery function
US20150067393A1 (en) * 2013-08-27 2015-03-05 Connectloud, Inc. Method and apparatus to remotely take a snapshot of a complete virtual machine from a software defined cloud with backup and restore capacity
WO2015138701A1 (en) * 2014-03-12 2015-09-17 Nutanix, Inc. Method and system for providing distributed management in a networked virtualization environment
US20150326531A1 (en) 2014-05-09 2015-11-12 Nutanix, Inc. Mechanism for providing external access to a secured networked virtualization environment
US20160103698A1 (en) * 2014-10-13 2016-04-14 At&T Intellectual Property I, L.P. Network Virtualization Policy Management System
US9733958B2 (en) 2014-05-15 2017-08-15 Nutanix, Inc. Mechanism for performing rolling updates with data unavailability check in a networked virtualization environment for storage management
US9740472B1 (en) 2014-05-15 2017-08-22 Nutanix, Inc. Mechanism for performing rolling upgrades in a networked virtualization environment
US10249014B2 (en) * 2012-11-29 2019-04-02 International Business Machines Corporation Use of snapshots to reduce risk in migration to a standard virtualized environment
US10362092B1 (en) 2016-10-14 2019-07-23 Nutanix, Inc. Entity management in distributed systems
US10379759B2 (en) 2013-03-15 2019-08-13 Nutanix, Inc. Method and system for maintaining consistency for I/O operations on metadata distributed amongst nodes in a ring structure
US10606704B1 (en) * 2014-12-31 2020-03-31 Acronis International Gmbh Creation of consistent copies of application data
US10642507B2 (en) 2015-01-30 2020-05-05 Nutanix, Inc. Pulsed leader consensus management
GB2589628A (en) * 2019-12-05 2021-06-09 Cristie Software Ltd Methods to automatically correct and improve system recovery and replication processes
US11163644B2 (en) * 2019-09-03 2021-11-02 EMC IP Holding Company LLC Storage boost
US11194680B2 (en) 2018-07-20 2021-12-07 Nutanix, Inc. Two node clusters recovery on a failure
US11218418B2 (en) 2016-05-20 2022-01-04 Nutanix, Inc. Scalable leadership election in a multi-processing computing environment
US20220245036A1 (en) * 2021-02-01 2022-08-04 Dell Products L.P. Data-Driven Virtual Machine Recovery
US11770447B2 (en) 2018-10-31 2023-09-26 Nutanix, Inc. Managing high-availability file servers
US11768809B2 (en) 2020-05-08 2023-09-26 Nutanix, Inc. Managing incremental snapshots for fast leader node bring-up

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9665831B2 (en) * 2014-10-24 2017-05-30 International Business Machines Corporation Interactive learning
US11467922B2 (en) 2019-03-04 2022-10-11 Cisco Technology, Inc. Intelligent snapshot generation and recovery in a distributed system

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6167494A (en) * 1998-04-28 2000-12-26 International Business Machine Corporation Method and system for recovering from operating system failure
US20070266204A1 (en) * 2006-05-15 2007-11-15 Hitachi, Ltd. Storage system comprising a plurality of tape media
US7523277B1 (en) * 2005-03-30 2009-04-21 Symantec Operating Corporation Transient point-in-time images for continuous data protection
US20090217255A1 (en) * 2008-02-25 2009-08-27 Rpath, Inc. Methods, systems, and computer program products for taking a snapshot of installed software on a data processing system as part of a software update process
US20100070678A1 (en) * 2008-09-12 2010-03-18 Vmware, Inc. Saving and Restoring State Information for Virtualized Computer Systems
US7689861B1 (en) * 2002-10-09 2010-03-30 Xpoint Technologies, Inc. Data processing recovery system and method spanning multiple operating system
US20100299309A1 (en) * 2009-05-21 2010-11-25 Hitachi, Ltd. Backup management method
US20110066879A1 (en) * 2009-09-11 2011-03-17 Fujitsu Limited Virtual machine system, restarting method of virtual machine and system
US20120066546A1 (en) * 2010-09-13 2012-03-15 Samsung Electronics Co., Ltd System recovery method and computing apparatus having system recovery function

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7865459B2 (en) 2007-02-06 2011-01-04 Sap Ag Integration of a service-oriented transaction system with an information storage, access and analysis system
WO2008121873A1 (en) 2007-03-29 2008-10-09 Vmware, Inc. Synchronization and customization of a clone computer
US8122212B2 (en) 2009-04-06 2012-02-21 Hitachi, Ltd. Method and apparatus for logical volume management for virtual machine environment

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6167494A (en) * 1998-04-28 2000-12-26 International Business Machine Corporation Method and system for recovering from operating system failure
US7689861B1 (en) * 2002-10-09 2010-03-30 Xpoint Technologies, Inc. Data processing recovery system and method spanning multiple operating system
US7523277B1 (en) * 2005-03-30 2009-04-21 Symantec Operating Corporation Transient point-in-time images for continuous data protection
US20070266204A1 (en) * 2006-05-15 2007-11-15 Hitachi, Ltd. Storage system comprising a plurality of tape media
US20090217255A1 (en) * 2008-02-25 2009-08-27 Rpath, Inc. Methods, systems, and computer program products for taking a snapshot of installed software on a data processing system as part of a software update process
US20100070678A1 (en) * 2008-09-12 2010-03-18 Vmware, Inc. Saving and Restoring State Information for Virtualized Computer Systems
US20100299309A1 (en) * 2009-05-21 2010-11-25 Hitachi, Ltd. Backup management method
US20110066879A1 (en) * 2009-09-11 2011-03-17 Fujitsu Limited Virtual machine system, restarting method of virtual machine and system
US20120066546A1 (en) * 2010-09-13 2012-03-15 Samsung Electronics Co., Ltd System recovery method and computing apparatus having system recovery function

Cited By (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10249014B2 (en) * 2012-11-29 2019-04-02 International Business Machines Corporation Use of snapshots to reduce risk in migration to a standard virtualized environment
US10379759B2 (en) 2013-03-15 2019-08-13 Nutanix, Inc. Method and system for maintaining consistency for I/O operations on metadata distributed amongst nodes in a ring structure
US9329931B2 (en) * 2013-07-24 2016-05-03 Seagate Technology Llc Solid state drive emergency pre-boot application providing expanded data recovery function
US20150033065A1 (en) * 2013-07-24 2015-01-29 Lsi Corporation Solid state drive emergency pre-boot application providing expanded data recovery function
US20150067393A1 (en) * 2013-08-27 2015-03-05 Connectloud, Inc. Method and apparatus to remotely take a snapshot of a complete virtual machine from a software defined cloud with backup and restore capacity
WO2015138701A1 (en) * 2014-03-12 2015-09-17 Nutanix, Inc. Method and system for providing distributed management in a networked virtualization environment
US9590843B2 (en) 2014-03-12 2017-03-07 Nutanix, Inc. Method and system for providing distributed management in a networked virtualization environment
US20150326531A1 (en) 2014-05-09 2015-11-12 Nutanix, Inc. Mechanism for providing external access to a secured networked virtualization environment
US11310286B2 (en) 2014-05-09 2022-04-19 Nutanix, Inc. Mechanism for providing external access to a secured networked virtualization environment
US10542049B2 (en) 2014-05-09 2020-01-21 Nutanix, Inc. Mechanism for providing external access to a secured networked virtualization environment
US9733958B2 (en) 2014-05-15 2017-08-15 Nutanix, Inc. Mechanism for performing rolling updates with data unavailability check in a networked virtualization environment for storage management
US9740472B1 (en) 2014-05-15 2017-08-22 Nutanix, Inc. Mechanism for performing rolling upgrades in a networked virtualization environment
US20160103698A1 (en) * 2014-10-13 2016-04-14 At&T Intellectual Property I, L.P. Network Virtualization Policy Management System
US11693749B2 (en) 2014-10-13 2023-07-04 Shopify, Inc. Network virtualization policy management system
US9892007B2 (en) 2014-10-13 2018-02-13 At&T Intellectual Property I, L.P. Network virtualization policy management system
US10592360B2 (en) 2014-10-13 2020-03-17 Shopify Inc. Network virtualization policy management system
US9594649B2 (en) * 2014-10-13 2017-03-14 At&T Intellectual Property I, L.P. Network virtualization policy management system
US11237926B2 (en) 2014-10-13 2022-02-01 Shopify Inc. Network virtualization policy management system
US10606704B1 (en) * 2014-12-31 2020-03-31 Acronis International Gmbh Creation of consistent copies of application data
US10642507B2 (en) 2015-01-30 2020-05-05 Nutanix, Inc. Pulsed leader consensus management
US11218418B2 (en) 2016-05-20 2022-01-04 Nutanix, Inc. Scalable leadership election in a multi-processing computing environment
US11888599B2 (en) 2016-05-20 2024-01-30 Nutanix, Inc. Scalable leadership election in a multi-processing computing environment
US10362092B1 (en) 2016-10-14 2019-07-23 Nutanix, Inc. Entity management in distributed systems
US11194680B2 (en) 2018-07-20 2021-12-07 Nutanix, Inc. Two node clusters recovery on a failure
US11770447B2 (en) 2018-10-31 2023-09-26 Nutanix, Inc. Managing high-availability file servers
US11163644B2 (en) * 2019-09-03 2021-11-02 EMC IP Holding Company LLC Storage boost
GB2589628B (en) * 2019-12-05 2023-03-08 Cristie Software Ltd Methods to automatically correct and improve system recovery and replication processes
US11782800B2 (en) 2019-12-05 2023-10-10 Cristie Software Ltd Methods to automatically correct and improve system recovery and replication processes
GB2589628A (en) * 2019-12-05 2021-06-09 Cristie Software Ltd Methods to automatically correct and improve system recovery and replication processes
US11768809B2 (en) 2020-05-08 2023-09-26 Nutanix, Inc. Managing incremental snapshots for fast leader node bring-up
US20220245036A1 (en) * 2021-02-01 2022-08-04 Dell Products L.P. Data-Driven Virtual Machine Recovery
US11841772B2 (en) * 2021-02-01 2023-12-12 Dell Products L.P. Data-driven virtual machine recovery

Also Published As

Publication number Publication date
US9170888B2 (en) 2015-10-27

Similar Documents

Publication Publication Date Title
US9170888B2 (en) Methods and apparatus for virtual machine recovery
US11716385B2 (en) Utilizing cloud-based storage systems to support synchronous replication of a dataset
US11086555B1 (en) Synchronously replicating datasets
US10346253B2 (en) Threshold based incremental flashcopy backup of a raid protected array
US9600375B2 (en) Synchronized flashcopy backup restore of a RAID protected array
US10108367B2 (en) Method for a source storage device sending data to a backup storage device for storage, and storage device
US7725579B2 (en) Computer readable medium and system for remote activity monitoring
US9274902B1 (en) Distributed computing fault management
US9075771B1 (en) Techniques for managing disaster recovery sites
US8688642B2 (en) Systems and methods for managing application availability
US7747830B2 (en) Backup system with continuous data protection
CN108351821B (en) Data recovery method and storage device
US6785838B2 (en) Method and apparatus for recovering from failure of a mirrored boot device
EP3238063B1 (en) Techniques for data backup and restoration
WO2017014814A1 (en) Replicating memory volumes
US9002798B1 (en) Systems and methods for remedying corrupt backup images of host devices
US11550677B2 (en) Client-less database system recovery
US11226875B2 (en) System halt event recovery
US20230353635A1 (en) Replication Utilizing Cloud-Based Storage Systems
US11016862B2 (en) Error-initiated mirror redrive to collect diagnostic information
Bach et al. Recovering Exadata
US8370306B1 (en) Systems and methods for recovering from continuous-data-protection blackouts

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SALAPURA, VALENTINA;HARPER, RICHARD E.;RYU, KYUNG D.;SIGNING DATES FROM 20120607 TO 20120608;REEL/FRAME:028352/0456

AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE THE DOCKET NUMBER IS INCORRECTLY LISTED AS YOR820120179US1 AND MUST BE UPDATED TO THE CORRECT DOCKET NUMBER, YOR920120179US1 PREVIOUSLY RECORDED ON REEL 028352 FRAME 0456. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT;ASSIGNORS:SALAPURA, VALENTINA;HARPER, RICHARD E.;RYU, KYUNG D.;SIGNING DATES FROM 20120607 TO 20120608;REEL/FRAME:028644/0235

STCF Information on status: patent grant

Free format text: PATENTED CASE

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

LAPS Lapse for failure to pay maintenance fees

Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Expired due to failure to pay maintenance fee

Effective date: 20191027