Patent Application
20210182150
Embodiments of the present invention generally relate to data protection operations. More particularly, at least some embodiments of the invention relate to systems, hardware, software, computer-readable media, and/or methods for performing data protection operations including synchronization and/or timing determination operations.
Data protection operations include backup operations where production data is backed up. There are various reasons for performing backup operations. The typical reason is to allow the production data to be recovered from the backups in the event of a problem with the production data.
Generating backups, however, can be a complicated process for many reasons. In addition to considering the configuration of the production data, backup operations also need to consider the types of applications and storage being used. Further, abstractions such as virtualization also add to the complexity of performing backup operations. Consequently, backup operations are not trivial tasks.
In one example of a backup operation, a virtual machine may be backed up by creating an image of the virtual machine. Generating an image of a virtual machine has many steps and, in order to be useful, the image must satisfy several requirements. If the image is not consistent, for example, the value of the image as a backup is substantially reduced and in many cases will make the image unusable. Further, it is often necessary to generate multiple images over time at least because production data is constantly being changed while it is backed up. Further, a consistent image may not represent a state of the application that enables the application to recover from the image. Multiple images may need to be generated to create an application consistent image. The process of generating valid backups is difficult.
In order to describe the manner in which at least some of the advantages and features of the invention may be obtained, a more particular description of embodiments of the invention will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, embodiments of the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:
Embodiments of the present invention generally relate to data protection operations. More particularly, at least some embodiments of the invention relate to systems, hardware, software, computer-readable media, and methods for performing data protection operations. Data protection operations include, but are not limited to, backup operations, restore operations, deduplication operations, replication operations, journaling operations, timing determination operations, synchronization operations and the like or combination thereof.
In general, example embodiments of the invention relate to generating image-level backups of virtual machines. Embodiments of the invention further relate to live images including live virtual machine images and to generating live virtual machine images. A live virtual machine image, by way of example only, is an image of a virtual machine that is coupled with a journal. The journal may contain input/output (IO) operations near the time at which the image was taken. In other words, the backup or image is generated inside of a window of time associated with the journal.
Embodiments of the invention further relate to synchronization or timing determination operations that include determining a point in time at which a live virtual machine image was taken with respect to the journal. Embodiments of the invention allow a journal to be synchronized to a corresponding image without the complexity of requiring substantial timing requirements between the start of the journal and the point in time at which the image is taken. In one example, the timing determination can be performed after the backup is taken rather than performing the complex task of ensuring that the journal starts at the same time as the backup is taken.
As previously stated, a live virtual machine image is an image-level backup that includes a backup image coupled with a journal that logs IO operations or changes to the virtual machine or to data. Advantageously, live image level backups (images) can be generated without an agent operating on the virtual machine.
By associating the image with a journal, a virtual machine can be recovered at various points in time that are around the time at which the image was generated. This increases the probability of obtaining a recoverable image even if the image itself is not application consistent. The journal allows the live image to be rolled forward or backward in order to identify a useful image.
In one example, the data protection application may generate a backup using snapshots, clones, quiescing, and may even take down the application when generating a backup. A live image may require that IO to the virtual machine's volumes or disks be captured, for example in a journal. Embodiments of the invention, rather than performing a complex synchronization to ensure that the timing of the backup and the journal match as previously stated, find the place in the journal at which the backup or image was taken. Thus, the requirement of tight synchronization between the start of the journal and the start of the backup is avoided. In fact, embodiments of the invention allow the data protection operation (taking or generating image of a virtual machine) to be decoupled from the journal. Further, the backup and the journal can be performed by separate and independent systems.
Embodiments of the invention allow the journal to be analyzed to retrospectively synchronize or make a timing determination between the image and the journal. By evaluating the entries in the journal, the locations on the volume being protected, and/or values stored in the backup, the image and the journal can be synchronized after the fact. This simplifies the backup operation compared to synchronizing prior to performing the backup operation.
By way of example only and not limitation, a live image-level virtual machine backup (live image) taken at time t contains an image of each of the virtual machine's hard disks or volumes in one example. The live image may also include or be associated with a description of the hardware configuration of the virtual machine. The live image is also associated with a journal that stores IOs around the time of the backup.
The journal length may be determined by a parameter, which may be predefined. The journal length could also be defined using the amount of data generated by the application, the amount of time to wait after the backup was taken or initiated, or any other parameter that represents consistency requirements.
In one example, the journal may be implemented as an ordered list where each entry corresponds to an IO. By way of example only, each element or entry in the list may include or identify a write operation, metadata identifying the hard disk or volume of the virtual machine, an offset inside the disk (e.g., an LBA), and/or a length of the IO.
The process of creating the live image 100 may include taking a backup image 102 of the production virtual machine 150 and capturing an IO stream to the virtual machine for a period of time to create the journal 104. The journal 104 represents a time segment or a period of time during which IOs are recorded.
The process of creating a live virtual machine Image includes taking a backup and capturing an IO stream for a time period (e.g., a few seconds) to create the journal. In this example, the journal 104 is initiated at a point in time prior to a start of generating the image 102. The journal 104 may be terminated at a point in time that is after the start time of generating the image 102. This ensures that the image 102 is taken sometime within the time period associated with the journal. As previously stated, the start of taking the image 102 and the start of the journal 104 do not need to be synchronized prior to starting the backup operation or in order to start the backup operation.
Embodiments of the invention allow the start time of the image 102 to be synchronized with the journal 104 by analyzing the journal 104, the backup, and/or the volume at a later point in time. In one example, the journal 104 is searched or analyzed to find the point in time in the journal 104 at which the image 102 was taken relative to the entries in the journal 104. As previously stated, embodiments of the invention can decouple the components that create the image 102 from the components that capture or create the journal 104. To perform a retroactive synchronization between the image 102 and the journal 104, the approximate time at which the image 102 is taken or will be taken is all that is needed in embodiments of the invention. More specifically, embodiments of the invention ensure that the journal 104 is started at a time (start time) prior to taking the image 102 and that the journal 104 terminates (end time) at a time after taking the image 102. The journal 104 can then be searched or analyzed to identify the start time of the image 102 relative to the journal 104.
For example, the process of generating a live image or a live virtual image may begin with a backup that is taken at time T. The journal 104 (e.g., a journal stream) is captured from a time period q before time T (e.g., a few seconds) to a time period p after time T or until a journal length is satisfied. For example, if the image is taken at time T, the journal 104 may start at q seconds before time T and end p seconds after time T. The time p may depend on the time required to fill the journal 104 or may be a predetermined time. Thus, the journal corresponds to a time segment (T−q, T+p).
The backup should be taken within this time segment and, in one embodiment, the backup should not start exactly on the boundaries of the time segment. By way of example, only, the parameters p and q can be on the order of seconds (e.g., q=about 5 seconds and p=about 30 seconds). Embodiments of the invention, however, are not limited to these periods.
In addition, the journal 104 may be ordered. More specifically, the data 106 and the metadata 108 may be ordered to correspond to the order in which the IOs occurred in the virtual machine 150. The journal 104 may be configured to keep write order fidelity.
The production site 202 may include virtual machines 204 that operate to perform tasks and other applications. A data protection application 206 may be configured to provide or perform data protection operations on the virtual machines 204. Thus, the data protection application 206 may generate data sets 212 that are stored at the backup site 210.
Live images are examples of data sets 212. Each virtual machine may be associated with multiple live images. The data sets 212 or live images may be full backups, incremental backups, or the like. In one example, the data sets 212 include images 214 that are associated with journals 216. Each image 214 is typically associated with a corresponding journal. The synchronization (and/or other data protection operations) between the images 214 and the journals 216 can be performed as the images are generated, after the images are generated, at the backup site, at the production site, or the like.
The data protection application 206 may be configured to trigger both the backup of the virtual machines 204 (or of any single virtual machine or other consistency group) and also trigger the corresponding journals at appropriate times. This allows the data protection application 206 to generate live images that each include an image and an associated journal.
Once the live image is generated, the live image can be processed. Initially, the journal, which corresponds to a time segment, is broken 302 into time intervals. The size of the intervals does not need to be constant and, in one example, each interval or time interval corresponds to an IO event recorded in the journal. Thus, the number of intervals may correspond to the number of entries in the journal.
Next, for each location Lon the volume (e.g., the virtual hard disks) that were backed up, each time interval may be classified 304. The classification determines whether or not that time interval may be a time at which the backup was taken. In one example, it may only be necessary to evaluate the locations present in the journal at least because the other locations are presumed to be constant during the time segment corresponding to the journal.
Once all of the locations have been classified, the time intervals for all of the locations are evaluated to identify possible times when the backup could have been taken 306. More specifically, the classifications can be viewed holistically such that the start time of the backup relative to the journal can be determined. In one example, there may be more than one possible time at which the backup was taken. Finally, the time interval at which the backup was taken is selected 308.
The classification of the locations 304 may result in different classifications. In one example, the classification is performed from the perspective or viewpoint of a volume location. For example, location L, which maybe at a specific address (e.g., block 15), may contain data X in the backup or in the image. When analyzing the location L, there are (by way of example only and not limitation) three classifications or situations. The same considerations are applicable to all locations L in the volume. Consider the following situations:
If there are no IOs for the location L (situation or classification 1) in the journal, the location L has not changed during the time segment corresponding to the journal and can be ignored. Most locations in the volume fall in this situation because the time segment during which the journal tracks IOs is relatively small (e.g., about 30 seconds in one example).
If all IOs for L in the journal differ from value X in the backup (situation or classification 2), the backup must have been taken during a time interval prior to the time interval associated with the first IO for the location L in the journal.
In situation or classification 3, the backup may have been taken in or during any time interval after the value X has appeared and before the value was changed to something else. The backup may also have been taken before the first IO in the time interval. Before the first IO, no knowledge about the value of the location is available and the value may have been X or not.
As a result, looking at the time axis of (T−q, T+p) of the segment or of the journal, and splitting or breaking the time segment into intervals at every point there is an IO in the journal, each interval is in one of 4 states in one example:
In the backup 402, location L1 has data Q L2 has data X, L3 has data Y and L4 has data Z.
In the journal 404, L2 receives the value A at time T0, L2 receives the value X at time T1, L1 receives the value Q at time T2, L2 receives the value B at time T3, L3 receives the value C at time T4, L2 receives the value X at time T5 and L2 receives the value D at time T6. In other words, the journal 404 is a time ordered list of the IOs that occurred during a time segment associated with the backup operation. Because there are 7 entries in the journal 404 in this particular example, the journal 404 can be divided into 8 time intervals (TI) TI0-TI7 in this example. The time intervals could be defined and interpreted differently.
The classification of the locations L1, L2, L3 and L4 are illustrated in
With regard to the location L1, the journal 404 shows that the location L1 receives the IO Q at time T2. This is the only IO in the journal 404 for the location L1. Because the value of the location L1 in the backup is Q, any time from T2 and on is a possible solution. Thus, from the perspective of L1, the backup could have occurred at any time subsequent to time T2. In other words, the time interval during which the backup was started, from the perspective of location L1, is time intervals T13, T14, T15, T16 and T17
The value of location L1 prior to time T2 is not readily available. In fact, the location L1 may have had the value Q even before T2 (e.g., the same value was overwritten at time T2 in one example).
The classification 502 for the location L1 is a 4 (unknown) for the time intervals prior to interval T13 (TI0, TI1 and T12 in this example). The classification 502 for Location L1 after time T2 is 1, which indicates that the value of the location L1 matches the value in the backup. From the perspective of the location L1, the backup could have occurred in any of the time intervals classified with a 1.
The location L4 is analyzed next (the order in which the locations are analyzed can vary). The location L4 is not associated with any IOs in the journal 404. As a result, all time intervals receive a classification of 1 and the backup could have occurred in any of the time intervals in the journal 404 from the perspective of the location L4.
The location L3 is associated with one IO in the journal 404. At time T4, the location L3 receives a value C. However, the value of L3 in the backup is Y. Y is not equal to C. As a result, the value Y had to have been present in the volume from the beginning of the journal 404 (or the time segment associated with the journal 404) until time T4. The conclusion is that Y was present in the volume during this time intervals. In this case, the time intervals up to the time interval T14 are concluded to have the value Y and are classified with a code of 3. The time intervals from TI5 and on (TI5, TI6 and TI7) are classified with a code 2, where the value of the location L3 in the journal does not match the value of the location L3 in the backup. As a result, the timer intervals from TI5 and on cannot be when the backup was taken.
The location L2 is associated with multiple IOs in the journal 404. By analyzing the journal entries for the location L2 and the value of the location L2 in the backup, the time intervals are classified as illustrated in
Once the time intervals are classified for all relevant locations, candidate time intervals can be identified. A candidate time interval is a time interval where the backup could have started for all locations. These candidate time intervals are the ones that may correspond to the start time of the backup. Identifying candidate time intervals and then selecting one of the candidate time intervals allows the backup to by synchronized with the journal.
In this example, the time interval TI3 after time T2 is a candidate time interval because the codes for all locations are all 1 or 3. However, it is also possible for the time interval TI2 after T1 or the time interval TI0 before T0 to be selected as candidate time intervals. Even if it cannot be proven that the backup start time was associated with these latter candidate time intervals (TI0 and TI2), there is nothing to contradict this assertion. Plus, the backup is guaranteed, in one embodiment, to be within the time segment associated with the journal and must start somewhere. It may therefore be possible to associate the start time with one or more candidates.
However, selecting one of the candidate time intervals or choosing a specific time interval to associated with the start time of the backup may be performed by evaluating the intersections of the locations at each time interval that does not include a classification or code of 2. For example, the interval TI1 is discarded and is not a candidate time interval because the location L2 has a classification of 2 during this time interval (the value in the journal does not match the value in the backup). A time interval that includes a location with a classification or code of 2 precludes that time interval from corresponding to the start time of the backup operation.
As previously discussed, the analysis shown in
However, embodiments of the invention ensure that at least one candidate time interval exists in the time segment of the journal. Further, all IOs in the journal keep write order fidelity as previously discussed and this helps ensure that the at least one candidate time interval can be identified.
Advantageously, if there is more than one candidate time interval, any one of the candidate intervals may be a correct or a suitable solution. Embodiments of the invention, however, may implement a selection order when multiple candidate time intervals are present. If a single time interval candidate is found, that time interval is selected as the time interval in which the backup started or was initiated. The following selection order may be applied:
In some embodiments, the backup operation may include an incremental backup operation. This may lead to a situation where locations are not part of the backup but are part of the journal. These situations may require access to the missing data at the time of the backup. This information can be accessed or provided from previous backups, using synthetic full previous backups (e.g., backups generated from a full backup plus one or more incremental backups), snapshotting the data at the time of the backup and granting access to the snapshot. Once the missing data is acquired, the method can proceed as previously discussed.
Embodiments of the invention describe the conditions and requirements to capture a live image of a virtual machine or other data set. The classification of the live image (e.g., of the locations of the volume as represented in the backup and the journal) is also discussed. The classification allows time intervals in a time segment (the journal) to be identified that may correspond to a start time of the backup. Thus a live image is generated by synchronizing the image with the journal. Further, embodiments of the invention allow a specific interval to be selected from multiple candidate intervals.
Embodiments of the invention, such as the examples disclosed herein, may be beneficial in a variety of respects. For example, and as will be apparent from the present disclosure, one or more embodiments of the invention may provide one or more advantageous and unexpected effects, in any combination, some examples of which are set forth below. It should be noted that such effects are neither intended, nor should be construed, to limit the scope of the claimed invention in any way. It should further be noted that nothing herein should be construed as constituting an essential or indispensable element of any invention or embodiment. Rather, various aspects of the disclosed embodiments may be combined in a variety of ways so as to define yet further embodiments. Such further embodiments are considered as being within the scope of this disclosure. As well, none of the embodiments embraced within the scope of this disclosure should be construed as resolving, or being limited to the resolution of, any particular problem(s). Nor should any such embodiments be construed to implement, or be limited to implementation of, any particular technical effect(s) or solution(s). Finally, it is not required that any embodiment implement any of the advantageous and/or unexpected effects disclosed herein.
The following is a discussion of aspects of example operating environments for various embodiments of the invention. This discussion is not intended to limit the scope of the invention, or the applicability of the embodiments, in any way.
In general, embodiments of the invention may be implemented in connection with systems, software, and components, that individually and/or collectively implement, and/or cause the implementation of, data protection operations. Such data protection operations may include, but are not limited to, data read/write/delete operations, data deduplication operations, data backup operations, data restore operations, data cloning operations, data archiving operations, disaster recovery operations, synchronization operations or the like or combination thereof. More generally, the scope of the invention embraces any operating environment in which the disclosed concepts may be useful.
At least some embodiments of the invention provide for the implementation of the disclosed functionality in existing backup platforms, examples of which include the Dell-EMC NetWorker and Avamar platforms, and associated backup software, and storage environments such as the Dell-EMC DataDomain storage environment. In general however, the scope of the invention is not limited to any particular data backup platform or data storage environment.
New and/or modified data collected and/or generated in connection with some embodiments, may be stored in a data protection environment that may take the form of a public or private cloud storage environment, an on-premises storage environment, and hybrid storage environments that include public and private elements. Any of these example storage environments, may be partly, or completely, virtualized. The storage environment may comprise, or consist of, a datacenter which is operable to service read, write, delete, backup, restore, and/or cloning, operations initiated by one or more clients or other elements of the operating environment. Where a backup comprises groups of data with different respective characteristics, that data may be allocated, and stored, to different respective targets in the storage environment, where the targets each correspond to a data group having one or more particular characteristics.
Example public cloud storage environments in connection with which embodiments of the invention may be employed include, but are not limited to, Microsoft Azure, Amazon AWS, and Google Cloud. More generally however, the scope of the invention is not limited to employment of any particular type or implementation of cloud storage.
In addition to the storage environment, the operating environment may also include one or more clients that are capable of collecting, modifying, and creating, data. As such, a particular client may employ, or otherwise be associated with, one or more instances of each of one or more applications that perform such operations with respect to data.
Devices in the operating environment may take the form of software, physical machines, or virtual machines (VM), or any combination of these, though no particular device implementation or configuration is required for any embodiment. Similarly, data protection system components such as databases, storage servers, storage volumes (LUNs), storage disks, replication services, backup servers, restore servers, backup clients, and restore clients, for example, may likewise take the form of software, physical machines or virtual machines (VM), though no particular component implementation is required for any embodiment. Where VMs are employed, a hypervisor or other virtual machine monitor (VMM) may be employed to create and control the VMs. The term VM embraces, but is not limited to, any virtualization, emulation, or other representation, of one or more computing system elements, such as computing system hardware. A VM may be based on one or more computer architectures, and provides the functionality of a physical computer. A VM implementation may comprise, or at least involve the use of, hardware and/or software. An image of a VM may take various forms, such as a .VMDK file for example.
As used herein, the term ‘data’ is intended to be broad in scope. Thus, that term embraces, by way of example and not limitation, data segments such as may be produced by data stream segmentation processes, data chunks, data blocks, atomic data, emails, objects of any type, files of any type including media files, word processing files, spreadsheet files, and database files, as well as contacts, directories, sub-directories, volumes, and any group of one or more of the foregoing.
Example embodiments of the invention are applicable to any system capable of storing and handling various types of objects, in analog, digital, or other form. Although terms such as document, file, segment, block, or object may be used by way of example, the principles of the disclosure are not limited to any particular form of representing and storing data or other information. Rather, such principles are equally applicable to any object capable of representing information.
As used herein, the term ‘backup’ is intended to be broad in scope. As such, example backups in connection with which embodiments of the invention may be employed include, but are not limited to, full backups, partial backups, clones, snapshots, and incremental or differential backups.
Any one or more of the entities disclosed, or implied herein, may take the form of, or include, or be implemented on, or hosted by, a physical computing device. As well, where any of the aforementioned elements comprise or consist of a virtual machine (VM), that VM may constitute a virtualization of any combination of the physical components disclosed herein.
In the example, the physical computing device includes a memory which may include one, some, or all, of random access memory (RAM), non-volatile random access memory (NVRAM), read-only memory (ROM), and persistent memory, one or more hardware processors, non-transitory storage media, UI device, and data storage. One or more of the memory components of the physical computing device may take the form of solid state device (SSD) storage. As well, one or more applications may be provided that comprise instructions executable by one or more hardware processors to perform any of the operations, or portions thereof, disclosed herein.
Such executable instructions may take various forms including, for example, instructions executable to perform any method or portion thereof disclosed herein, and/or executable by/at any of a storage site, whether on-premises at an enterprise, or a cloud storage site, client, datacenter, or backup server, to perform any of the functions disclosed herein. As well, such instructions may be executable to perform any of the other operations and methods, and any portions thereof, disclosed herein.
Following are some further example embodiments of the invention. These are presented only by way of example and are not intended to limit the scope of the invention in any way.
Embodiment 1. A method for generating a live image of data, the method comprising identifying time intervals associated with a journal, wherein the journal is associated with an image of the data and wherein the journal includes entries associated with the data during a time period during which the image was taken, classifying every location in the journal impacted by the entries as a classified journal, identifying candidate time intervals from amongst the time intervals, wherein the image was generated during one of the candidate timer intervals; and synchronizing the journal with the image by selecting a synchronized time interval from amongst the candidate intervals as the time interval during which the image was taken.
Embodiment 2. The method of embodiment 1, further comprising starting the journal before a start time of taking the image.
Embodiment 3. The method of embodiment 1 and/or 2, further comprising ending the journal after an end time of the image.
Embodiment 4. The method of embodiment 1, 2 and/or 3, further comprising classifying every location in a volume associated with the virtual machine.
Embodiment 5. The method of embodiment 1, 2, 3, and/or 4, further comprising selecting the candidate time intervals, wherein a time interval is selected as a candidate time interval when all locations for associated with the time interval contain values equal to values in the image, are concluded to contain values equal to values in the image, or are unknown.
Embodiment 6. The method of embodiment 1, 2, 3, 4, and/or 5, further comprising selecting an earliest time interval when all locations contain locations that match the values in the backup.
Embodiment 7. The method of embodiment 1, 2, 3, 4, 5 and/or 6, further comprising selecting a latest time interval when the locations in the candidate time intervals do not all contain the value in the image.
Embodiment 8, The method of embodiment 1, 2, 3, 4, 5, 6 and/or 7, wherein the data comprises a virtual machine.
Embodiment 9. The method of embodiment 1, 2, 3, 4, 5, 6, 7, and/or 8, wherein the image is a partial image, further comprising accessing missing data from previous images or from a synthetic image, or from a snapshot of the image.
Embodiment 10. A non-transitory storage medium having stored therein instructions that are executable by one or more hardware processors to perform operations comprising identifying time intervals associated with a journal, wherein the journal is associated with an image of the data and wherein the journal includes entries associated with the data during a time period during which the image was taken, classifying every location in the journal impacted by the entries as a classified journal, identifying candidate time intervals from amongst the time intervals, wherein the image was generated during one of the candidate timer intervals, and synchronizing the journal with the image by selecting a synchronized time interval from amongst the candidate intervals as the time interval during which the image was taken.
Embodiment 11. The non-transitory storage medium of embodiment 10, the operations further comprising starting the journal before a start time of taking the image.
Embodiment 12. The non-transitory storage medium of embodiment 10 and/or 11, the operations further comprising ending the journal after an end time of the image.
Embodiment 13. The non-transitory storage medium of embodiment 10, 11 and/or 12, the operations further comprising classifying every location in a volume associated with the virtual machine.
Embodiment 14. The non-transitory storage medium of embodiment 10, 11, 12 and/or 13, the operations further comprising selecting the candidate time intervals, wherein a time interval is selected as a candidate time interval when all locations for associated with the time interval contain values equal to values in the image, are concluded to contain values equal to values in the image, or are unknown.
Embodiment 15. The non-transitory storage medium of embodiment 10, 11, 12, 13 and/or 14, the operations further comprising selecting an earliest time interval when all locations contain locations that match the values in the backup.
Embodiment 16. The non-transitory storage medium of embodiment 10, 11, 121, 13, and/or 15, the operations further comprising selecting a latest time interval when the locations in the candidate time intervals do not all contain the value in the image.
Embodiment 17. The non-transitory storage medium of embodiment 10, 11, 12, 13, 14, 15 and/or 16, wherein the data comprises a virtual machine.
Embodiment 18. The non-transitory storage medium of embodiment 10, 11, 12, 13, 14, 15, 16 and/or 17, wherein the image is a partial image, the operations further comprising accessing missing data from previous images or from a synthetic image, or from a snapshot of the image.
The embodiments disclosed herein may include the use of a special purpose or general-purpose computer including various computer hardware or software modules, as discussed in greater detail below. A computer may include a processor and computer storage media carrying instructions that, when executed by the processor and/or caused to be executed by the processor, perform any one or more of the methods disclosed herein, or any part(s) of any method disclosed.
As indicated above, embodiments within the scope of the present invention also include computer storage media, which are physical media for carrying or having computer-executable instructions or data structures stored thereon. Such computer storage media may be any available physical media that may be accessed by a general purpose or special purpose computer.
By way of example, and not limitation, such computer storage media may comprise hardware storage such as solid state disk/device (SSD), RAM, ROM, EEPROM, CD-ROM, flash memory, phase-change memory (“PCM”), or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage devices which may be used to store program code in the form of computer-executable instructions or data structures, which may be accessed and executed by a general-purpose or special-purpose computer system to implement the disclosed functionality of the invention. Combinations of the above should also be included within the scope of computer storage media. Such media are also examples of non-transitory storage media, and non-transitory storage media also embraces cloud-based storage systems and structures, although the scope of the invention is not limited to these examples of non-transitory storage media.
Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts disclosed herein are disclosed as example forms of implementing the claims.
As used herein, the term ‘module’ or ‘component’ may refer to software objects or routines that execute on the computing system. The different components, modules, engines, and services described herein may be implemented as objects or processes that execute on the computing system, for example, as separate threads. While the system and methods described herein may be implemented in software, implementations in hardware or a combination of software and hardware are also possible and contemplated. In the present disclosure, a ‘computing entity’ may be any computing system as previously defined herein, or any module or combination of modules running on a computing system.
In at least some instances, a hardware processor is provided that is operable to carry out executable instructions for performing a method or process, such as the methods and processes disclosed herein. The hardware processor may or may not comprise an element of other hardware, such as the computing devices and systems disclosed herein.
In terms of computing environments, embodiments of the invention may be performed in client-server environments, whether network or local environments, or in any other suitable environment. Suitable operating environments for at least some embodiments of the invention include cloud computing environments where one or more of a client, server, or other machine may reside and operate in a cloud environment.
The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.
