Related Applications

[0001] The present patent application claims priority to US Patent Application No. 17/391,632 filed August 2, 2021 and is incorporated by reference herein in its entirety and for all purposes as if completely and fully set forth herein.

BACKGROUND OF THE INVENTION

Field of the Invention

[0002] Today’s businesses often rely extensively on data maintained online. Such frequently-accessed, constantly-changing data can be critical to the ongoing operations of such. Unforeseen events, such as natural disasters, failure of underlying hardware, inadvertent deletion of files, data corruption by malicious software, etc., which inhibits the availability of this data can seriously affect business operations. It is critically important to protect such systems and data from unforeseen events. When disaster strikes, businesses must be prepared to eliminate or minimize data loss, and recover quickly with useable data. Backups, snapshots, replicas, etc., can minimize adverse effects from unforeseen events.

[0003] Backup can be used to prevent data loss in case of any unforeseen event. A data backup process typically creates a copy of data. The copy can be used to restore the data after a data loss event. The backed-up data can be stored using a variety of media, such as magnetic tape, hard drives, flash memory, and/or optical storage, among others. Various techniques can be used to generate such backups, such full backups, incremental backups, or differential backups, among others.

[0004] Snapshots are also copies of data. Some snapshots are made instantly, and the content of them is immediately available. A common type of snapshot is the copy-on-write (COW) snapshot. At the time when a COW snapshot is initiated only metadata about the original data location is copied. After that, each time data is modified, the data is first copied to a snapshot area and then modified in the original memory location. Snapshots can restore data back to a prior point in time. Multiple snapshots can be taken to create multiple possible point- in-time restoration points.

[0005] Application consistent backups or snapshots are achieved by quiescing (i.e., pausing) application I/O write requests to disk, and flushing all pending I/O write requests (or “writes”) to disk. With the applications paused and all pending writes flushed, the backup or snapshot operation commences.

[0006] In addition to snapshots and backups, data can be protected through replication. Replication relies on software that can copy to a replica all changes made to disk in the order in which they occur. The replica is typically maintained at a remotely located target or target site with dedicated network connectivity linking it to the source or source site. Through replication, a company can insure the safety of important files and processes, and improve the reliability of their performance.

[0007] There are two major types of replication; synchronous replication, and asynchronous replication. In synchronous replication, data is copied to the target site as it is being written to the disk at the source site, giving the most precise backup. However, this may require expensive hardware and bandwidth. In asynchronous replication, data is copied to the target site on a scheduled or requested basis. In either, a replica of the disk at the target site is updated with the copied data (i.e., the replicated data) that is received from the source site.

SUMMARY

[0008] A system and method is disclosed to create an application consistent recovery point in disaster recovery solution without knowledge of I/Os. The method in one embodiment includes a first application sequentially issuing first write commands for writing data to memory via a file system. The first application receives a command to pause after issuing the first write commands. The first application pauses in response to the first application receiving the command. All of the first write commands that are pending are completed after the first application is paused. After the all the first write commands are completed, a module issues a read command to read a marker. [0009] The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present disclosure, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Embodiments of methods and systems such as those disclosed herein may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.

[0011] Fig. 1 is a block diagram depicting an example computing environment, according to one embodiment of this disclosure.

[0012] Fig. 2 is a block diagram depicting another example computing environment, according to one embodiment of this disclosure.

[0013] Fig. 3 is a flow chart illustrating relevant aspects according to one embodiment of this disclosure.

[0014] Fig. 4 is a flow chart illustrating relevant aspects according to one embodiment of this disclosure.

[0015] Fig. 5a - 5c illustrate example replication status updates in storage at a target site.

[0016] While the present disclosure is susceptible to various modifications and alternative forms, specific embodiments of the present disclosure are provided as examples in the drawings and detailed description. It should be understood that the drawings and detailed description are not intended to limit the present disclosure to the particular form disclosed. Instead, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure as defined by the appended claims. DETAILED DESCRIPTION

[0017] The following is intended to provide a detailed description and examples of the methods and systems of the disclosure, and should not be taken to be limiting of any inventions described herein. Rather, any number of variations may fall within the scope of the disclosure, and as defined in the claims following the description.

[0018] While the methods and systems described herein are susceptible to various modifications and alternative forms, specific embodiments are provided as examples in the drawings and detailed description. It should be understood that the drawings and detailed description are not intended to limit such disclosure to the particular form disclosed. Instead, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the appended claims.

[0019] While the methods and systems described herein are susceptible to various modifications and alternative forms, specific embodiments are provided as examples in the drawings and detailed description. It should be understood that the drawings and detailed description are not intended to limit such disclosure to the particular form disclosed. Instead, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the appended claims.

Introduction

[0020] Methods and systems such as those described herein provide for application consistent recovery points in a replication environment. Recovery points in replication provide data protection against unforeseen events including data corruption caused by malicious software. Essentially, replication recover points provide continuous data protection for recovering application and data to any point in time.

[0021] The disclosed methods and systems may include inserting a unique data marker, hereinafter referred to as an application consistent marker (ACM), into select replication update sets (RUSs) before the replication sets are transmitted by a source site to a target site. In general replication update sets include copies of data and meta data from I/O write requests. The application consistent marks are used by the target site to identify recovery points.

[0022] Replication update sets are sequentially transmitted from a source site to a target site. Replication update sets are stored end-to-end in a staging storage area at the target site. A replica at the target site can be updated by applying the data of one or more replication update sets. The replica is updated with the data in the order in which the data was received by the target site.

[0023] Application consistent markers are not inserted in every replication update set. An application consistent marker is inserted when a backup or snapshot operation is started at the source site. However, after an application consistent marker is inserted in a replication update set, the replication update set should be immediately transmitted to the target site (i.e., without adding further data). The replication update sets are held in a staging area at the target site. The replica can be updated using the replication update sets. As will be more fully described, the replica at the target site can be placed in an application consistent state by applying data of one or more replication update sets that are between a pair application consistent markers.

[0024] The present methods and systems can find particular application in an information technology resiliency platform (ITRP; e.g., VERITAS RESILIENCY PLATFORM). An ITRP can address a number of disaster recovery (DR) use cases, allowing organizations to mitigate the adverse consequences from unforeseen events such as malicious software attacks. An ITRP such as that described herein can use standalone replication to move data from one site (e.g., a source site) to another (e.g., a target site), in an ongoing fashion. In so doing, a user’s (or organization’s) data is typically replicated from the source site to the target site. However, as will also be appreciated, the user (or organization) will typically employ some manner of recovery software at the target site, such that the user (or organization) is able to restore a given computing resource and/or data to an earlier point in time. It will be appreciated that users will want and need the ability to perform such restorations (as well as the ability to perform other operations with comparable effects).

[0025] The present disclosure will be described with reference to replication in a virtualization environment, it being understood the present disclosure should not be limited thereto. Virtualization is becoming increasingly common. In such environments, virtual machines (VMs) can be used to extend the functional capabilities a physical host computing devices. How effective the VMs are depends, largely, on the configuration of the VMs, and the host(s) on which the VMs are implemented. VMs are software constructs that can perform tasks typically associated with physical computing devices. Multiple VMs can be implemented on a single physical host, each VM having its own operating system, and can operate independently of the other VMs. Thus, virtualization systems can allow multiple operating systems (which can actual be separate instances of the same type of operating system) to execute on the same hardware. Each executing operating system acts as an independent “VM” and can be interacted with and used in substantially the same manner as standalone operating system executing on independent hardware. Virtual machines allow increased use of hardware resources by effectively turning one hardware-computing device into several VMs. Some virtualization systems provide a virtualization controller that can manage one or more VMs implemented on one or more computing devices. Such a virtualization controller can communicate with the VMs and control the operation of those VMs.

[0026] As will be described in greater detail, methods and systems such as those described herein employ the use of VO request tracking at the source site. For example, in one implementation, an VO tracker (or “VO tap”) is employed to track VO write requests to disk, and certain read requests, such as requests to read a particular file that is designated to contain the aforementioned application consistent marker (ACM). The VO tap can be implemented, for example, as a filter in a VM. An ITRP architecture also employs one or more gateways at the source site and one or more gateways at the target site. Such gateways, when sending replicated data, are referred to as source gateways. Alternatively, when receiving replicated data, such gateways are referred to as target gateways. In one embodiment, gateways are implemented as replication appliances deployed on both sites.

[0027] In one embodiment, VO taps provide data and associated metadata of VO write requests to one or more network queues of the source site. In one embodiment, such metadata includes, for example, the logical sector of a disk at which the data begins, the amount of data in question, etc. Such metadata can also include verification information (e.g., a checksum, hash, or other such information), in order to maintain data integrity. The network queue accumulates data and metadata into a replication update set (RUS). RUSs can be sent by a source gateway to a target gateway at regularly scheduled intervals. The I/O tap can also write ACMs to one or more network queues. Rather than wait for the next regularly scheduled interval, an RUS should be sent to the target gateway immediately after the aforementioned ACM is added to it. Target gateways store RUSs in a staging area in the order they were received from the source gateway. The RUS data and corresponding metadata can be used to update the target replica. The application consistent markers define application consistent recovery points.

Example Architectures Providing Data Replication

[0028] An Information Technology Resiliency Platform (ITRP), employing methods and systems such as those described herein, is implemented. Such an ITRP can provide not only for disaster recovery, but also provide workload management capabilities for VMs, as well as various applications, such as those which might be executed on a desktop computer platform. In so doing, such an ITRP architecture provides a system for managing IT applications for numerous resiliency capabilities in various forms, with such solutions providing for, e.g., disaster recovery. An ITRP architecture such as those described herein provides a scalable, distributed, and layered architecture with the potential to add new capabilities to the platform on demand.

[0029] In general terms, operations such as the following provide an example of a method according to the present disclosure that can be employed to create application consistent recovery points at a target site: a. A unique identifier (e.g., application consistent marker ACM) is added to a RUS in response to freezing a file system at the source site. b. The source gateway sends the RUS with ACM to its peer gateway (the target gateway) via an inter-site communications channel such as a wide-area network. c. The target data gateway recognizes the ACM of the RUS as the demarcation between consecutive application consistent recovery points. d. Data and metadata corresponding to respective application consistent recovery points are maintained at the target site (e.g., in target staging storage of the target gateway) until applied to the replica disk. [0030] A more detailed description of such methods is now provided in connection with a discussion of the figures. Fig. 1 is a simplified block diagram illustrating an example ITRP architecture 100, which includes various computing resources at a source site 102 and a target site 104, which are in communication via a network 105. ITRP 100 provides a resiliency manager 110 that orchestrates the ITRP by communicating with various infrastructure management services (depicted in Fig. 1 as a source IMS 112 and a target IMS 114), which, in turn, communicate with the replication engines of the gateways depicted therein. More specifically, source IMS 112 communicates with the components of a source gateway 120, while target IMS 114 communicates with the components of a target gateway 122. More specifically still, source IMS 112 communicates with a replication engine 130 of source gateway 120, while target IMS 114 communicates with a replication engine 132 of target gateway 122.

[0031] Source gateway 120 provides replication services to the computing resources of source site 102, replicating data at source site 102 to target site 104 by replicating the data resulting from write operations to target site 104 by way of communications with target gateway 122 via network 105.

[0032] An ITRP may include a number of host computers 140. Each host computer in an ITRP can support one or more VMs 142, each of which can support one or more applications 144. Also depicted in Fig. 1 are VO taps 150, which can also referred to as filters or filter drivers 150. In the manner noted elsewhere herein, an VO tap 150 tracks information regarding VO write requests and certain VO read requests, and also passes information (e.g., VO write request data and metadata, ACM, etc.) to a data receiver 155 of source gateway 120. Data receiver 155 stores RUSs in source gateway staging storage 157 (depicted in Fig. 1 as RUSs 160(N)-(M)) before source data transceiver 162 sends the RUSs from source gateway 102 to target gateway 104 via network 105. RUSs are received at target gateway 122 by a target data receiver 164, and target data receiver 164 stores the received RUSs (depicted in Fig. 1 as RUSs 160(M-l)-(l)) in target gateway (TDM) staging storage 165. Data applier 167 retrieves RUSs from TDM staging storage 165 and sends those RUSs to a target data storage unit 170 for updating the replica thereof. [0033] As noted I/O taps 150 also track certain I/O read requests. For example, VO taps track requests to read files that are designated to contain the aforementioned application consistent markers (ACM). Offsets in VO read requests can be used to identify requests to read files that are designated to contain ACMs. When an VO request to read a file containing the ACM is detected, VO tap 150 adds the ACM to the RUS it is building. The ACM is the last piece of information added to the RUS before it is forwarded to the staging storage 157.

[0034] Also depicted in Fig. 1 are a number of host computers (depicted in Fig. 1 as host computers 180) in target site 104, which support a number of virtual machines 182. Virtual machines 182, in turn, support one or more applications 184. Host computers 180, virtual machines 182, and applications 184 are depicted to illustrate a scenario in which one or more virtual machines can fail over to target site 104, as might be the case, for example, were an unforeseen event to befall the infrastructure at source site 102.

[0035] It will be appreciated that each of the foregoing components of ITRP architecture 100, as well as alternatives and modifications thereto, are discussed in further detail below and/or will be apparent in view of this disclosure. In this regard, it will be appreciated that the various data storage systems described herein can be implemented by any type of computer-readable storage medium, including, but not limited to, internal or external hard disk drives (HDD), optical drives (e.g., CD-R, CD-RW, DVD-R, DVD-RW, and the like), flash memory drives (e.g., USB memory sticks and the like), tape drives, removable storage in a robot or standalone drive, and the like. Alternatively, it will also be appreciated that, in light of the present disclosure, ITRP architecture 100 and/or the various networks thereof can include other components such as routers, firewalls and the like that are not germane to the discussion of the present disclosure and will not be discussed further herein. It will also be appreciated that other configurations are possible.

[0036] Fig. 2 is a simplified block diagram illustrating an example of certain components, features, and processes of a replication architecture 200, according to one embodiment. Replication architecture 200 depicts certain of the features of ITRP architecture 100 in greater detail. To this end, Fig. 2 depicts a host computer 210 (e.g., in the manner of one of host computers 140 of Fig. 1) communicatively coupled to a source gateway 220 (e.g., in the manner of source gateway 120 of Fig. 1), which is, in turn, communicatively coupled to a target gateway 230 (e.g., in the manner of target gateway 122 of Fig. 1).

[0037] Also in the manner of host computers 140 of Fig. 1, host computer 210 supports a virtual machine 240 that, in turn, supports a number of applications 242(1 )-(N), an I/O tap 245 (in the manner of I/O taps 150 of Fig. 1), a plugin module 245, an operating system 251, and a network queue 267. Although shown separately, plugin module 245 may be component of one of the applications 242.

[0038] Operating system 251 includes a file system 252 and a volume shadow service (VSS) 253, which coordinates the creation of backup copies or snapshots of virtual disk VMDK 247. For purposes of explanation, application consistent recovery points in disaster recovery solution will be described with reference to snapshots of virtual disk VMDK 247, it being understood the present disclosure should not be limited thereto. Target gateway 230 maintains a replica 235 of virtual disk 247.

[0039] VSS 253 coordinates the actions needed to create an application consistent snapshot of VMDK 247. The actions may include sending a pause or quiescence command to applications 242 in anticipation of a snapshot operation. In response, each application prepares for the snapshot operation by completing all open transactions and flushing their caches in response to receiving the pause command. The applications do not issue write I/O requests (read I/O requests are still possible) while they are in the quiescent state. The applications notify VSS 253 when they are ready for snapshot. When VSS 253 is notified that all applications are ready, VSS 253 flushes the buffers of file system 252, and then freezes the file system. After the file system is frozen, VSS 253 instructs plugin VSS 253 to issue an I/O request to read the ACM. The I/O read request may include an offset that identifies a file that contains the ACM. VSS 253 also tells the snapshot provider (not shown) to create the snapshot. The period for creating the snapshot should last no more than 10 seconds. When the snapshot is created, VSS 253 releases file system 252 and applications 242. At this point applications 242 can resume sending I/O write requests to VMDK 247 via file system 252.

[0040] Fig. 3 illustrates the foregoing process in greater detail. Essentially the process begins while applications are generating VO read and/or VO write requests. In step 304, applications 242 receive a pause command from VSS 253. In response, applications 242 are placed in the quiescent state, and begin flushing pending I/O write requests to disk 247 via file system 252 as shown in step 306. While in the quiescent or paused state, applications 242 can send I/O read requests to file system 252, but not I/O write requests. Once the applications confirm to VSS 253 that all pending I/O write requests have been flushed, file system 252 is frozen by VSS 253 as shown in step 310. Thereafter, VSS 253 sends plug-in module 248 a notification to issue an I/O request to read the ACM as shown in step 314. This I/O read request may include a time stamp indicating when it was filed. File system 252, although frozen, receives and processes the I/O request to read ACM. It is noted that the I/O tap 245 will receive the I/O request to read ACM. VSS 253 can be notified that plug-in module 248 has sent the VO read request to the file system.

[0041] In general VO tap 245 captures information regarding VO write requests performed by applications 242. VO tap 245 copies the information (data and metadata) of the VO write requests it receives. The copied information is sent to network queue 267 where the next RUS is being built. I/O tap 245 also detects I/O requests to read the ACM. In response to receiving and detecting an I/O request to read the ACM, I/O tap 245 writes the ACM to the RUS in the network queue 267. Fig. 4 illustrates an example method performed by I/O tap 245. The method starts when I/O tap 245 receives an I/O request as shown in step 402. I/O tap 245 evaluates the I/O request in step 404. If the I/O request is a request to write data, I/O tap 245 adds the data and the metadata of the request to the RUS in the network queue 267, and the process waits for the next I/O request. If the I/O request is not an I/O write request, I/O tap 245 determines whether it is an I/O request to read data as shown in step 410. The I/O request is dropped in step 412 if the I/O request is not a request to read data. However, if I/O tap 245 determines the I/O request is one to read data in step 410, the I/O tap in step 414 determines whether the I/O read request is configured to read the ACM. If I/O tap 245 determines the I/O request is not configured to read the ACM, the I/O tap 245 drops the I/O read request as shown in step 416. If, however, I/O tap 245 determines the I/O request does read the ACM, the I/O tap 245 appends the ACM to the end of the RUS in the network queue as shown in step 420. The I/O tap 245 may also write the time stamp of the I/O read request to the RUS. Then, the RUS of the network queue is sent to the data receiver without further delay. In other words, the contents of the network queue is forwarded to the data receiver as an RUS with ACM being the last component added to the RUS before it is forwarded. Although not shown in Figure 4, the network queue is cleared before it begins receiving new information for the next RUS. It is noted that if the network queue does not receive an ACM when the contents of the network queue is scheduled to be sent to the data receiver as the next RUS, the RUS is sent without the ACM.

[0042] The data receiver stores the RUSs it receives in source staging storage 272. The RUSs are stored in the order in which they are received. Source data transceiver 274 retrieves these RUSs and sends them to target gateway 230 in the order in which they are received and held in storage 272. Data receiver 270 and source data transceiver 274 perform these operations under the control of a replication engine 276 that is configured using information in a source configuration database 278.

[0043] The RUSs sent by source gateway 220 are received by target gateway 230 at a target data transceiver 280. Target data transceiver 280 stores the received RUSs in a target staging storage 282 in the order in which they were sent by gateway 220. Data applier 284 can apply the data of RUSs to replicated host data storage unit 235 in the order in which they were received. Data applier 284 deletes RUSs from storage 282 as the RUSs are applied to the replica 235. Target data transceiver 280 and data applier 284 perform the foregoing operations under the control of a replication engine 286 that is configured using information in a source configuration database 288.

[0044] Fig. 5a-5c illustrates target-staging storage 282 as RUSs are added by target data transceiver 280. Fig. 5b illustrates storage 282 of Fig. 5a after new RUS 160(x+l) is added by target data transceiver 280. Fig. 5c illustrates storage 282 of Fig 5b after several more RUSs are sequentially added by target data transceiver 280. Several of the RUSs in Figs. 5a-5c include ACMs as shown. Time stamps TSx indicating the date and time when the ACMs were issued in I/O read requests by the plug-in module at the source site mentioned above, may also be included with corresponding ACMs in the RUSs.

[0045] The source site is subject to unforeseen events such as corruption of data in VMDK 247 by malicious software executing on VM 240. When the data corruption is discovered, operations can failover from source site to the target site. Before operations failover to the target site, replica 235 can be updated by data applier 284 using RUSs stored in target staging storage

282. Replica 235, however, should be updated to a point in time before VMDK 247 was corrupted.

[0046] During failover, data applier 284 can update replica 235 by applying the RUSs in staging storage 282 in the order in which they were received therein. Ideally, data applier 284 should update replica 235 with RUSs up to and including the RUS with an ACM that has a corresponding time stamp that is closest to, but prior to the time when VMDK 247 was first corrupted. In this manner, the replica 235 of VMDK 247 is recovered to an application consistent point in time that is just prior to data corruption.

Other Embodiments

[0047] The example systems and computing devices described herein are well adapted to attain the advantages mentioned as well as others inherent therein. While such systems have been depicted, described, and are defined by reference to particular descriptions, such references do not imply a limitation on the claims, and no such limitation is to be inferred. The systems described herein are capable of considerable modification, alteration, and equivalents in form and function, as will occur to those ordinarily skilled in the pertinent arts in considering the present disclosure. The depicted and described embodiments are examples only, and are in no way exhaustive of the scope of the claims.

[0048] Such example systems and computing devices are merely examples suitable for some implementations and are not intended to suggest any limitation as to the scope of use or functionality of the environments, architectures and frameworks that can implement the processes, components and features described herein. Thus, implementations herein are operational with numerous environments or architectures, and may be implemented in general purpose and special-purpose computing systems, or other devices having processing capability. Generally, any of the functions described with reference to the figures can be implemented using software, hardware (e.g., fixed logic circuitry) or a combination of these implementations. The term “module,” “mechanism” or “component” as used herein generally represents software, hardware, or a combination of software and hardware that can be configured to implement prescribed functions. For instance, in the case of a software implementation, the term “module,” “mechanism” or “component” can represent program code (and/or declarative-type instructions) that performs specified tasks or operations when executed on a processing device or devices (e.g., CPUs or processors). The program code can be stored in one or more computer-readable memory devices or other computer storage devices. Thus, the processes, components and modules described herein may be implemented by a computer program product.

[0049] The foregoing thus describes embodiments including components contained within other components (e.g., the various elements shown as components of computer system 1310). Such architectures are merely examples, and, in fact, many other architectures can be implemented which achieve the same functionality. In an abstract but still definite sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermediate components.

Likewise, any two components so associated can also be viewed as being "operably connected," or "operably coupled," to each other to achieve the desired functionality.

[0050] Furthermore, this disclosure provides various example implementations, as described and as illustrated in the drawings. However, this disclosure is not limited to the implementations described and illustrated herein, but can extend to other implementations, as would be known or as would become known to those skilled in the art. Reference in the specification to “one implementation,” “this implementation,” “these implementations” or “some implementations” means that a particular feature, structure, or characteristic described is included in at least one implementation, and the appearances of these phrases in various places in the specification are not necessarily all referring to the same implementation. As such, the various embodiments of the systems described herein via the use of block diagrams, flowcharts, and examples. It will be understood by those within the art that each block diagram component, flowchart step, operation and/or component illustrated by the use of examples can be implemented (individually and/or collectively) by a wide range of hardware, software, firmware, or any combination thereof. [0051] The systems described herein have been described in the context of fully functional computer systems; however, those skilled in the art will appreciate that the systems described herein are capable of being distributed as a program product in a variety of forms, and that the systems described herein apply equally regardless of the particular type of computer-readable media used to actually carry out the distribution. Examples of computer-readable media include computer-readable storage media, as well as media storage and distribution systems developed in the future.

[0052] The above-discussed embodiments can be implemented by software modules that perform one or more tasks associated with the embodiments. The software modules discussed herein may include script, batch, or other executable files. The software modules may be stored on a machine-readable or computer-readable storage media such as magnetic floppy disks, hard disks, semiconductor memory (e.g., RAM, ROM, and flash-type media), optical discs (e.g., CD- ROMs, CD-Rs, and DVDs), or other types of memory modules. A storage device used for storing firmware or hardware modules in accordance with an embodiment can also include a semiconductor-based memory, which may be permanently, removably or remotely coupled to a microprocessor/memory system. Thus, the modules can be stored within a computer system memory to configure the computer system to perform the functions of the module. Other new and various types of computer-readable storage media may be used to store the modules discussed herein.

[0053] In light of the foregoing, it will be appreciated that the foregoing descriptions are intended to be illustrative and should not be taken to be limiting. As will be appreciated in light of the present disclosure, other embodiments are possible. Those skilled in the art will readily implement the steps necessary to provide the structures and the methods disclosed herein, and will understand that the process parameters and sequence of steps are given by way of example only and can be varied to achieve the desired structure as well as modifications that are within the scope of the claims. Variations and modifications of the embodiments disclosed herein can be made based on the description set forth herein, without departing from the scope of the claims, giving full cognizance to equivalents thereto in all respects. [0054] Although the present invention has been described in connection with several embodiments, the invention is not intended to be limited to the specific forms set forth herein. On the contrary, it is intended to cover such alternatives, modifications, and equivalents as can be reasonably included within the scope of the invention as defined by the appended claims.