Patent Application
20230333934
The present application relates to cloud technologies, data storage technologies, synchronization technologies, caching technologies, data consistency and integrity technologies, error resolution technologies, and more particularly, to a system and method for resolving transient and localized errors in a hybrid cloud cache.
A hybrid cloud is a computing architecture that combines an on-premise data center with a public cloud environment. Hybrid cloud caches are local data storage elements used in conjunction with a public cloud-based data storage and serve as an important component of internet applications, as they help achieve improved throughput and increased data access speeds. Conventionally, such caches persist data and metadata regarding operations or transactions on a local file system. The integrity of data stored locally by a hybrid cloud cache may be ensured by implementing a journaling system, where a system adds records representing user requested transactions and the associated operations to a journal. Thus, the journaling system may be a data storage location where records are added to represent operations initiated by a user or by a computing system at the direction of a user, and the backing store for a journal may comprise disk blocks. Journals may also be referred to as logs and the two terms are often used interchangeably.
When using a journal, user transactions and the associated operations are typically described using as little storage space as possible. At a high level, such operations may be classified into two types or categories of operations. The first type of operation may comprise data operations, which typically involve the local cache being used to upload data or files to, or download data or files from, the cloud system or platform. The second type of operation may comprise metadata operations, which typically involve the local cache being used to perform operations where data itself is not involved. For example, such metadata operations may include, but are not limited to, data or file rename and delete operations.
For practical reasons of local storage capacity, journals cannot grow indefinitely and typically must wrap-around, where this refers to a journaling system having the ability to overwrite old records without a system losing data or metadata. The ability to overwrite or wrap-around for a journal is dependent upon the operations described by the journal records having been completed and the associated data, file, or metadata having reached a final destination (such as a cloud-based platform), and so may be removed from the local hybrid cloud cache.
From the vantage point of a hybrid cloud cache, operations performed through it (i.e., using the local cache as a data storage to record a transaction or operation) are referred to as Explicit Transactions (or write-through transactions), while operations that are performed directly in the cloud, i.e., around or without use of the cache, are referred as Implicit Transactions (or write-around transactions).
User initiated transactions often include (or result in) a mix of data and metadata operations. Data operations, which involve transfer of the actual data, typically take a longer time to complete than metadata operations. In some situations, each of the operations to be performed may be assigned monotonously increasing numbers referred to as transaction identifiers. In order to maintain consistency and ensure the integrity of the hybrid cloud cache, the transactions may be “pushed” to the cloud in the same order that they appear in the hybrid cloud cache, that is in the numerical order of the transaction identifiers. Transactions may also be marked PUSHDONE in the journal in the same order.
Errors may occur while pushing a transaction to the cloud. These errors can be broadly categorized as being transient or long lasting. Transient errors are likely to disappear and can often be corrected by retrying an operation a few times, whereas long lasting errors cannot be remedied by retrying an operation.
Longer lasting errors can further be categorized as global errors or localized errors. The scope of localized errors, such as name and type conflicts, is limited to a particular part of a cached namespace, whereas global errors, such as network connectivity issues, affect and can impact the entire namespace. Localized errors such as name and/or type conflicts may sometimes be resolved by renaming the objects involved. Global errors may sometimes be resolved by switching the hybrid cloud cache to an offline or read-only status. Despite this method of error handling, the user data and metadata typically need to be preserved, and the transaction must be concluded to unblock subsequent transactions. Normally when there are no errors, the data and metadata are preserved in both the cache and cloud. However, when there is an error which caused a folder/file to be moved to a Lost+Found region of a cache, then the data and metadata are preserved only in the cache.
While current technologies and methodologies for using hybrid cloud computing architectures provide benefits and efficiencies, such technologies and methodologies still have disadvantages. These disadvantages include the method of handling transient and longer-term errors in the operation of the hybrid cloud cache. Embodiments disclosed herein are directed to overcoming these disadvantages, both individually and collectively.
The terms “invention,” “the invention,” “this invention,” “the present invention,” “the present disclosure,” or “the disclosure” as used herein are intended to refer broadly to all of the subject matter described in this document, the drawings or figures, and to the claims. Statements containing these terms should be understood not to limit the subject matter described herein or to limit the meaning or scope of the claims. Embodiments covered by this disclosure are defined by the claims and not by this summary. This summary is a high-level overview of various aspects of the disclosure and introduces some of the concepts that are further described in the Detailed Description section below. This summary is not intended to identify key, essential or required features of the claimed subject matter, nor is it intended to be used in isolation to determine the scope of the claimed subject matter. The subject matter should be understood by reference to appropriate portions of the entire specification, to any or all figures or drawings, and to each claim.
As will be described, conventional methodologies and technologies used in managing a hybrid cloud computing architecture or other system that includes a hybrid cloud cache may be modified and/or enhanced by using an embodiment of the system, apparatuses, and methods described herein to provide a more optimized caching performance, along with enhanced data consistency and integrity. Such enhancements and improvements to conventional methodologies and technologies may provide improved efficiency, improved data consistency, improved data integrity, improved speed, improved upload and/or download optimization capabilities, improved caching capabilities, improved wrap-arounds, improved overwrites, reduced blocking of transactions, improved long-term and short-term performance, reduced costs, and increased ease-of-use.
A system, apparatus, and accompanying methods for resolving transient and localized errors in a hybrid cloud cache architecture are disclosed herein. In some embodiments, the system, apparatus, and methods comprise a “Lost+Found” subsystem of a hybrid cloud cache for use in handling and resolving various types of errors occurring in a cloud computing system.
In conventional filesystems, a Lost+Found file or folder may be utilized as a destination to recover files from a corrupt filesystem using a filesystem check operation (e.g., by using the fsck command or function). In conventional systems and approaches, the files recovered by using fsck may lack context and often do not have complete data, metadata, or both. In some cases, a file system error may cause the recovery tool (fsck) to be unable to determine the parent directory/folder that the file should be in, and it operates to move the file to the Lost+Found. In such cases, the only information that is known about the object is its unique inode number, and often not even the name of the file.
In the absence of a file name, parent folder or file, and other relevant metadata, the recovery process is cumbersome and unreliable. This can impact the operation of the hybrid cloud cache and the execution of other transactions. A file may also be moved to Lost+Found due to other types of errors, or an inability to determine other types of information about an object. This is why the preservation of metadata when an object is moved to a Lost+Found can be of such importance in overcoming a file system error and recreating corrupted files or folders.
In contrast, in a system or architecture comprising a hybrid cloud cache and the associated methods described herein, a subsystem (referred to as a Lost+Found) is used to recover files and folders created by the user that could not be pushed to the cloud (i.e., to a cloud-based platform) without loss of metadata and/or data. In some embodiments, the Lost+Found subsystem works together with the transaction processing subsystem of a hybrid cloud cache computing architecture to release transactions involving those files and folders that could not be pushed to the cloud due to errors. This allows for the unblocking of the subsequent transactions and/or user-initiated operations. Further, as will be described, the files and folders in the Lost+Found subsystem can be recovered with both the data and metadata intact.
In one embodiment, the disclosure is directed to a method for resolving transient and localized errors in a hybrid cloud cache. The method may include the following steps, stages, or operations:
In another embodiment, the disclosure is directed to a system for resolving transient and localized errors in a hybrid cloud cache. The system may include a memory that stores a set of computer-executable instructions and a processor or processors that execute the instructions. When executed by the processor or processors, the instructions cause the processor or processors (or a device of which they are part) to perform a set of operations that implement the disclosed method.
In another embodiment, the disclosure is directed to a set of computer-executable instructions for resolving transient and localized errors in a hybrid cloud cache. The computer instructions, when executed by a processor or processors, may cause the processor or processors (or a device of which they are a part) to perform a set of operations that implement the disclosed method.
These and other features of the systems and methods for resolving transient and localized errors in a hybrid cloud cache are described in the following detailed description, drawings, and appended claims. Other objects and advantages of the systems and methods described will be apparent to one of ordinary skill in the art upon review of the detailed description and the included figures. Throughout the drawings, identical reference characters and descriptions indicate similar, but not necessarily identical, elements. While the exemplary embodiments described herein are susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and will be described in detail herein. However, the exemplary embodiments described herein are not intended to be limited to the forms disclosed. Rather, the present disclosure covers all modifications, equivalents, and alternatives falling within the scope of the appended claims.
Embodiments of the system and methods in accordance with the present disclosure will be described with reference to the drawings, in which:
Note that the same numbers are used throughout the disclosure and figures to reference like components and features.
The subject matter of embodiments of the present disclosure is described herein with specificity to meet statutory requirements, but this description is not intended to limit the scope of the claims. The claimed subject matter may be embodied in other ways, may include different elements or steps, and may be used in conjunction with other existing or later developed technologies. This description should not be interpreted as implying any required order or arrangement among or between various steps or elements except when the order of individual steps or arrangement of elements is explicitly noted as being required.
Embodiments of the disclosure will be described more fully herein with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, exemplary embodiments by which the disclosure may be practiced. The disclosure may, however, be embodied in different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy the statutory requirements and convey the scope of the disclosure to those skilled in the art.
Among other things, the present disclosure may be embodied in whole or in part as a system, as one or more methods, or as one or more devices. Embodiments of the disclosure may take the form of a hardware implemented embodiment, a software implemented embodiment, or an embodiment combining software and hardware aspects. For example, in some embodiments, one or more of the operations, functions, processes, or methods described herein may be implemented by one or more suitable processing elements (such as a processor, microprocessor, CPU, GPU, TPU, controller, etc.) that is part of a client device, server, network element, remote platform (such as a SaaS platform), an “in the cloud” service, or other form of computing or data processing system, device, or platform.
The processing element or elements may be programmed with a set of executable instructions (e.g., software instructions), where the instructions may be stored on (or in) one or more suitable non-transitory data storage elements. In some embodiments, the set of instructions may be conveyed to a user through a transfer of instructions or an application that executes a set of instructions (such as over a network, e.g., the Internet). In some embodiments, a set of instructions or an application may be utilized by an end-user through access to a SaaS platform or a service provided through such a platform.
In some embodiments, one or more of the operations, functions, processes, or methods described herein may be implemented by a specialized form of hardware, such as a programmable gate array, application specific integrated circuit (ASIC), or the like. Note that an embodiment of the inventive methods may be implemented in the form of an application, a sub-routine that is part of a larger application, a “plug-in”, an extension to the functionality of a data processing system or platform, or other suitable form. The following detailed description is, therefore, not to be taken in a limiting sense.
As mentioned, in conventional systems that implement a hybrid cloud cache, an object (e.g., a file) may be moved to a Lost+Found because the file system is corrupt and the recovery tool (fsck) is not able to determine the parent directory/folder of the file. This makes the recovery process more difficult and prone to error. However, this problem can be overcome if the metadata associated with a file can be preserved when a file is transferred to the Lost+Found.
As will be described further, the disclosed system, apparatuses, and methods implement a Lost+Found subsystem for handling files and folders that cannot be pushed to the cloud (i.e., a cloud-based data storage and data processing platform that is part of a hybrid cloud cache system) due to errors in pushing the upload file or create folder operations. In some embodiments, the disclosed system, apparatuses, and methods utilize a Lost+Found as a subsystem of a hybrid cloud cache, where the Lost+Found file or folder has a structure similar to (and compatible with) that of the namespace(s) cached by the hybrid cloud cache.
In some embodiments, the Lost+Found subsystem may have its own metadata file system (MDFS), data cache file system (DCFS), and associated meta-files. The Lost+Found subsystem may be utilized to assist in processing and resolving a transaction that results in a failed push operation, without permitting the failure to prevent the processing of other transactions. In some embodiments, this is accomplished by using the described logic to resolve the failure while ensuring the integrity of the hybrid cache journal and by releasing the transaction processing and computing resources associated with the transaction within a finite time. This allows those resources to be used by the processing subsystem of the hybrid cloud cache for processing other transactions.
Preserving data, metadata, and the effects of user operations by redirecting the data and metadata to a Lost+Found subsystem of the local cache of a hybrid cloud cache system can provide multiple benefits. For example, since the data and metadata are preserved via the Lost+Found subsystem, the transactional integrity of the hybrid cloud cache is maintained. Additionally, by releasing transactions that involve operations associated with files and folders that cannot be pushed to the cloud, the system and methods allow for using journal/log wraparound for the remaining transactions without a decrease in the throughput of the hybrid cloud cache. Furthermore, the system, apparatus, and methods disclosed allow users to recover data and contextual information associated with the data after resolving an underlying problem preventing an upload of a file or creation of a folder, and can also be enhanced to execute operations orthogonal to (i.e., independent of) the hybrid cloud cache.
In some embodiments, one orthogonal operation that is possible to implement is to present a listing of such objects to the user/administrator and allow them to retry pushing these objects to the cloud. This operation is termed as “recovering” an object from the Lost+Found. The listing can provide additional information to the user/administrator, such as the user that performed the operation(s), the time of attempting to perform the operation(s), the size of a file, the name of the file or folder, the identifier, etc.
In some embodiments, a system that implements the disclosed method for resolving transient and localized errors in a hybrid cloud cache may receive a request from a client device or process to perform a data operation that is associated with uploading a file, creating a folder, or both, to a cloud location (such as a file or folder contained in a data storage of a cloud-based platform). In response, the system may perform an operation that includes associating the requested data operation with a corresponding transaction (or creating such a transaction) in a journal of a hybrid cloud cache of the system. The system may also perform an operation that includes associating a unique identifier with the transaction. The identifier may be a number, with the transactions in the cache being numbered in order of when they were entered into the cache (i.e., the lower numbers correspond to transactions that were entered into the cache earlier). The system may then attempt to upload or “push” the file, the created folder, or both to the cloud.
Assume that a folder is being pushed to the cloud and is associated with a create folder transaction, and that it has no parent in the metadata file system of the Lost+Found subsystem. If a failure occurs while attempting to push the folder to the cloud, then the system may perform an operation that includes moving the folder to the metadata file system (referred to as MDFS herein) of the Lost+Found subsystem of the hybrid cloud cache. This may be followed by renaming the folder to its unique identifier and adding a corresponding entry to a meta-file of the MDFS of the Lost+Found subsystem.
Now assume that a file is being pushed to the cloud and is associated with an upload file transaction, and that it has no parent in the metadata file system of the Lost+Found subsystem. If a failure occurs while attempting to push the file to the cloud, then the system may perform an operation that includes moving the file to a data cache file system (referred to as DCFS herein) of the Lost+Found subsystem of the hybrid cloud cache and adding an entry in the meta-file of the MDFS of the Lost+Found subsystem.
If a parent folder of a folder that was the subject of the failed create operation is already in the metadata file system of the Lost+Found subsystem, then the hybrid cloud cache system may perform an operation that includes flagging or indicating the folder as already in the Lost+Found subsystem of the hybrid cloud cache and adding an entry in the meta-file of the parent folder in the Lost+Found subsystem.
If a parent folder of a file that was the subject of the failed push operation is already in the metadata file system of the Lost+Found subsystem, then the system may perform an operation that includes adding an entry associated with the file in a meta-file of the parent folder and moving the file from the DCFS of the cache to the DCFS of the Lost+Found subsystem.
Further, in some embodiments, the system may perform an operation that includes writing a PUSHDONE record (or other indication of a completed transaction) in the journal of the hybrid cloud cache for the current (i.e., the failed or uncompleted) transaction. Moreover, the system may perform an operation that includes enabling a subsequent transaction to be processed by the hybrid cloud cache despite the failure in the upload or create operation.
In contrast, a hybrid cloud cache system or architecture as disclosed herein utilizes a Lost+Found as an element or component to recover files and folders that could not be pushed to the cloud and does so without losing metadata and/or data. In some embodiments, the Lost+Found subsystem in a hybrid cloud cache may be used in coordination with the transaction processing (sub)system of a hybrid cloud cache to release transactions associated with those files and folders that could not be pushed to the cloud (i.e., to a location or destination on a cloud-based platform or system) due to errors. This allows for the unblocking of the subsequent transactions and/or user requested operations. Further, the files and folders in the Lost+Found may be recovered while ensuring that the data and metadata remain intact.
As described herein, the system 100 and methods implement a Lost+Found subsystem for handling files and folders that cannot be pushed to the cloud, such as where a transaction meant to push a folder or file to the cloud cannot be completed. To that end, the system 100 and methods utilize the Lost+Found as a subsystem of the hybrid cloud cache, where the Lost+Found structure is similar to that of the namespace cached by the hybrid cloud cache.
In some embodiments, the Lost+Found subsystem 206 (as shown in
As mentioned, preserving data, metadata, and the effects of user operations by redirecting them to the Lost+Found subsystem 206 on the local storage of a hybrid cloud cache provides several benefits. Since the data and metadata are preserved via the Lost+Found subsystem 206, the transactional integrity of the hybrid cloud cache may be maintained. Additionally, by releasing transactions corresponding to failed operations to push a file or folder to the cloud, the system 100 and methods allow for journal/log wraparound for subsequent transactions without a decrease in the throughput of the hybrid cloud cache. Furthermore, the system 100 and methods allow users to recover data and context information associated with the data after resolving the underlying problem(s) that prevented a creation of the folder or upload of the file.
In some embodiments, the Lost+Found subsystem can be enhanced to include the capability to execute operations orthogonal to (i.e., independent of) the hybrid cloud cache. For example, the processes or operations compatible with the Lost+Found subsystem can be extended to support actions specific to the Lost+Found, such as providing users or administrators with functionality to recover a file by pushing it to the cloud, restoring it to the cache, or deleting a file without interfering with the regular operations of the Hybrid Cloud Cache.
In some embodiments, the hybrid cloud cache may keep folders in the MDFS(s) (metadata file system, as described with reference to
For each folder or file, a transaction may have been created as part of processing a user's request to create the folder/file, and the folder/file may be created locally in the hybrid cloud cache and associated with a unique identifier (such as a UID). The folder and/or file may be pushed to the cloud, and then the transaction may be released by a transaction processing (sub)system of the hybrid cloud cache by writing a PUSHDONE record for the appropriate transaction in the journal of the hybrid cloud cache.
However, if there is a failure while attempting to push the folder and/or file to the cloud, then instead of stopping the processing, the disclosed system, apparatus, and methods may proceed in one of the following ways to address and overcome the failure:
Returning to
In some embodiments, the system 100 may be included within another system, may be a separate system from another system, and/or may be a subsystem of another system. The system 100 may include, but is not limited to including, a REST Application Programming Interface (API) 102 (or other API), a smart cache API layer 104 (or other API layer), a journaling system 106 (which may include a number of journals), a metadata cache manager 108, a data cache manager 110, a metadata store 112, a data store 114, a policy enforcer 116, a cache refresh manager 118, a cloud-file-storage client layer 120, a recovery manager 122, and a policy engine 124.
The system 100 of
The journaling system 106 may include one or more journals. One or more of the journals may be configured to record transactions associated with operations requested by a user (including, for example, data and metadata associated with the operations). The metadata may be information that describes the data and/or operations, what is in the data, and/or the type of operation. In some embodiments, the journals may be a circular log, buffer, and/or other data structure. In some embodiments, the journals may transfer records containing information associated with the operations to the cloud, such as to a cloud-based platform or system. Once the records are transferred to the cloud, the records may be deleted from (or overwritten in) the journal(s). The journal(s) may be utilized to ensure that the operations requested by users/clients are carried out and performed, even if the system 100 crashes or suffers another type of interruption. Data and metadata associated with the operations may be managed by the data cache manager 110 and the metadata cache manager 108, respectively. In some embodiments, the records including the data and metadata may be stored in the data store 114 and the metadata store 112, respectively.
The system 100 may include a policy enforcer 116, which may be configured to enforce the policies and rules associated with the system 100. The cache refresh manager 118 may be configured to refresh a cache in the system 100. For example, the cache refresh manager 118 may be configured to ensure that data and/or metadata recently stored in a particular cache is current and/or accurate. The system 100 may also include a cloud-file-storage (CFS) system client layer 120, which may be utilized to facilitate providing records associated with the operations from the journal(s) to the cloud-based file-storage system. Additionally, the system 100 may include a recovery manager 122, which may be configured to recover un-pushed data and/or metadata and to ensure that the integrity of the data in the journals and/or caches of the system 100 is preserved. The system 100 may further include a policy engine 124, which may be configured to generate and/or conduct various operations associated with policies and/or rules to be utilized with the system 100.
With regards to policy engine 124, examples of policies that may be implemented by the engine include but are not limited to, or required to include the following:
Referring now to
The system 200 may include a cache 202 for storing data, files and/or folders, a DCFS (data cache file system) 208 of the cache 202 for storing files and/or data, a MDFS (metadata file system) 204 of the cache 202 for storing metadata (for all objects in the cache, except those in the Lost+Found), a meta-file 210 of the MDFS 204 for storing metadata associated with files and/or data, an orphanage 212 for providing a separate internal meta-namespace for objects that are associated with Implicit metadata transactions, a purgatory 214 for providing a location to which are transferred objects deleted from the cloud, a transient area 216 for data for files not yet transferred to the cloud, a Lost+Found subsystem 206, a DCFS 218 of the Lost+Found subsystem 206, a MDFS 220 of the Lost+Found subsystem 206 (for metadata for the objects in the Lost+Found), a meta-file 221 of the Lost+Found subsystem 206, a shared portion 222, a meta-file 224 of the shared portion 222, documents 226 of the shared portion 222, a meta-file 228 of the documents 226, general information 230, a meta-file 232 of the general information 230, design documents 234, a meta-file 236 of the design documents 234, a private portion 238, a meta-file 240 of the private portion 238, a user1242, a meta-file 244 associated with the user1242, a user2246, a meta-file 248 associated with the user2246, and a cloud 250 (i.e., a cloud-based platform or data storage).
Folders 222, 226, 230, 234, 238, 242, and 246 are examples of user folders in the namespace. There can be any number of such folders arranged in a hierarchy. The figure shows them as examples to demonstrate that for each user folder a meta-file is created in the hybrid cloud cache which stores the metadata associated with that folder.
It should be noted that the elements, components, or processes illustrated in
User1242 and User2246 may be humans, computing devices, programs, processes, clients, robots, and/or other types of users. The meta-files 210, 221, 224, 228, 232, 236, 240, 244, and 248 may serve as files that describe data, files and/or folders associated with the corresponding component of the system 200 to which they are connected. In some embodiments, the meta-files 210, 221, 224, 228, 232, 236, 240, 244, and 248 may include attributes, such as, but not limited to, name, size, user, number of versions, upload-time, another attribute, or a combination thereof.
In some embodiments, the white boxes to the left of the black boxes in
In some embodiments, the system 100 and system 200 may operate in the following manner with the following parameters. The hybrid cloud cache may be configured to keep folders in metadata file systems and files in the data cache file systems. In some embodiments, an MDFS may be a structured hierarchy or tree of cached folders and the DCFS may be a repository of cached files stored as objects.
At each level in the MDFS, the hybrid cloud cache maintains a meta-file (i.e., a metadata file) that contains metadata of folders and files created by the user at that level. In some embodiments, folder listing operations (such as refreshes) may read the meta-file instead of traversing the tree. The Lost+Found subsystem 206 of the hybrid cloud cache may have its own MDFS 220, DCFS 218, and meta-files 221. Any files and/or folders that could not be pushed to the cloud may be moved to the Lost+Found subsystem 206.
In order to push newly created folders and files to the cloud, the system 100 and/or 200 may perform three primary steps for every folder created and/or file uploaded by the user:
However, instead of stopping the operation of the hybrid cloud cache if there is a failure during a push/create attempt (2), the system 100, 200 may handle the failure in one of the following ways:
When releasing a transaction by writing a PUSHDONE record to the cache journal, the system 100, 200 may also log information about the file or folder that was moved to Lost+Found subsystem 206 to protect against crashes and to persist the information in the case of reboots. Once a PUSHDONE record has been written, the transaction processing subsystem of the hybrid cloud cache may move on to the next transaction after releasing the resources associated with the current (failed or uncompleted) transaction.
In some embodiments, use of the meta-file, MDFS 220, and DCFS 218 in the Lost+Found subsystem 206 with the transaction processing subsystem of the hybrid cloud cache causes the Lost+Found subsystem 206 to be a structure similar to that of a namespace cached by the hybrid cloud cache. It can be listed like other folders in the cache, which may enable the user to recover the files and folders from the Lost+Found subsystem 206 and back those up to cloud data storage from the hybrid cloud cache. Further, as mentioned, in some embodiments, the Lost+Found subsystem 206 can be extended to support operations or processes specific to the Lost+Found subsystem 206, such as by providing users or administrators with the capability to recover a file by pushing it to the cloud, restoring it to the cache, or deleting it without blocking or interfering with the regular operations of the hybrid cloud cache.
Note that a combination of the components, devices, programs, and/or networks of the system 100 and system 200 may execute and/or conduct the functionality as described in the method(s) that follow.
In some embodiments, the method 300 may proceed as follows:
One or more steps or stages of the method 300 may be incorporated in (or executed by) an element of the system 100, the system 200, or a combination as disclosed or as otherwise described herein. Further, method 300 may incorporate a function or operation described with regards to system 100 or system 200.
As mentioned, systems and apparatuses that implement the techniques and methods described may provide several benefits. In some embodiments, these benefits may include:
The illustrations of arrangements described herein are intended to provide a general understanding of the structure of various embodiments, and they are not intended to serve as a complete description of all the elements and features of apparatus and systems that might make use of the structures described herein. Other arrangements may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. Figures are also merely representational and may not be drawn to scale. Certain proportions thereof may be exaggerated, while others may be minimized. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
Thus, although specific arrangements have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific arrangement shown. This disclosure is intended to cover all adaptations or variations of various embodiments and arrangements of the system and methods described. Combinations of the above arrangements, and other arrangements not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description. Therefore, it is intended that the disclosure not be limited to the particular arrangement(s) or embodiments disclosed, but include all embodiments and arrangements falling within the scope of the appended claims.
The foregoing is provided for purposes of illustrating, explaining, and describing one or more embodiments of the disclosure. Modifications and adaptations to these embodiments will be apparent to those skilled in the art and may be made without departing from the scope or spirit of this invention. Upon reviewing the embodiments, it would be evident to an artisan with ordinary skill in the art that said embodiments can be modified, reduced, or enhanced without departing from the scope and spirit of the claims described below.
This application is a Continuation of U.S. patent application Ser. No. 17/349,429, titled “System and Method for Resolving Transient and Localized Errors in a Hybrid Cloud Cache,” filed Jun. 16, 2021, which claims the benefit of U.S. Provisional Application No. 63/040,237, titled “System And Method For Resolving Transient And Localized Errors In A Hybrid Cloud Cache,” filed Jun. 17, 2020, the disclosure of which is incorporated, in its entirety herein, by this reference.
| Number | Date | Country | |
|---|---|---|---|
| 63040237 | Jun 2020 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17349429 | Jun 2021 | US |
| Child | 18117213 | US |
