Abstract: A object data backup and restore method and system include receiving a request to restore a target object to a first point-in-time version; identifying a first snapshot of the cluster corresponding to the first point-in-time version; generating a second snapshot of the cluster upon receiving the request to restore the target object; determining data changes associated with the target object based on the first snapshot and second snapshot; scanning all objects associated with the cluster to determine one or more additional objects that are affected by restoring the target object due to object dependencies defined by a cluster configuration; generating a relationship graph for the one or more additional objects and the target object; and restoring the target object based on the data changes, the first snapshot and the relationship graph.

Abstract: A object data backup and restore method and system include receiving a request to restore a target object to a first point-in-time version; identifying a first snapshot of the cluster corresponding to the first point-in-time version; generating a second snapshot of the cluster upon receiving the request to restore the target object; determining data changes associated with the target object based on the first snapshot and second snapshot; scanning all objects associated with the cluster to determine one or more additional objects that are affected by restoring the target object due to object dependencies defined by a cluster configuration; generating a relationship graph for the one or more additional objects and the target object; and restoring the target object based on the data changes, the first snapshot and the relationship graph.

Abstract: In some examples, a cluster protection system comprises at least one processor and a memory storing instructions which, when executed by the at least one processor, cause the system to perform operations comprising identifying a target cluster or an object in a container management framework, identifying application data and metadata associated with the target cluster or the object, generating a first snapshot of the target cluster or the object, the first snapshot including at least the metadata, storing the first snapshot in offsite cloud storage, generating a second snapshot of the target cluster, the second snapshot including at least the application data, and storing the second snapshot in a persistent volume in onsite storage.

Abstract: A object data backup and restore method and system include receiving a request to restore a target object to a first point-in-time version; identifying a first snapshot of the cluster corresponding to the first point-in-time version; generating a second snapshot of the cluster upon receiving the request to restore the target object; determining data changes associated with the target object based on the first snapshot and second snapshot; scanning all objects associated with the cluster to determine one or more additional objects that are affected by restoring the target object due to object dependencies defined by a cluster configuration; generating a relationship graph for the one or more additional objects and the target object; and restoring the target object based on the data changes, the first snapshot and the relationship graph.

Abstract: A object data backup and restore method and system provide for identifying an object from a first entity space in a cluster of a client compute environment; generating a snapshot of the object; copying the volume data to a second entity space in the cluster; detecting that the first entity space has been deleted from the cluster; receiving a request to restore the object to a point-in-time version associated with the snapshot; and restoring, via the snapshot tool, the object using the volume data copied to the second entity space and the content data of the snapshot.

Abstract: Contention for a resource in a computer system resource is managed by measuring a resource performance metric and, for each of a selected plurality of clients (for example, virtual machines), a client performance metric. For each of the selected clients, a relationship measure, such as correlation, is determined as a function of the resource performance metric and the respective client performance metric. A degree of resource contention effect is determined for each of the selected clients as a function of the respective relationship measure, and a resource-related action is taken according to the respective relationship measures. Clients may include virtualized components contending for storage. Example metrics include functions of I/O operation counts, latency or throughput measurements, pending I/O request counts, I/O throughput relative to I/O latency, a degree of change of the respective clients' I/O behavior, etc.

Abstract: The configuration of a cache is adjusted within a computer system that includes at least one entity that submits a stream of references, each reference corresponding to a location identifier corresponding to data storage locations in a storage system. The reference stream is spatially sampled using reference hashing. Cache utility values are determined for each of a plurality of caching simulations and an optimal configuration is selected based on the results of the simulations.

Abstract: A cache in a computer system is configured with a plurality of monitoring slices, each comprising a separately addressable partition of the cache. With each monitoring slice is associated a respective sub-range of a hash function, which has a range that includes at least the addressable partitions of the cache that comprise the monitoring slices. For each of a stream of location identifiers submitted by at least one entity, a respective location identifier hash value is computed and used to determine in which, if any, monitoring slice-associated hash function sub-range the location identifier hash value falls. For at least one of the monitoring slices, a frequency value is determined as a function of how many of the location identifier hash values fell into the slice's associated hash function sub-range, and a respective cache utility value is then computed as a function of each monitoring slice's frequency value.

Abstract: The configuration of a cache is adjusted within a computer system that includes at least one entity that submits a stream of references, each reference corresponding to a location identifier corresponding to data storage locations in a storage system. The reference stream is spatially sampled using reference hashing. Cache utility values are determined for each of a plurality of caching simulations and an optimal configuration is selected based on the results of the simulations.

Abstract: Cache utility curves are determined for different software entities depending on how frequently their storage access requests lead to cache hits or cache misses. Although possible, not all access requests need be tested, but rather only a subset, comprising fewer than all of the requests, determined by whether a hash value of each current storage location identifier (such as an address or block number) meets one or more sampling criteria. The subset may comprise as few as 20% or 10% or even less of the access requests.

Abstract: Interaction is evaluated between a computer system cache and at least one entity that submits a stream of references corresponding to location identifiers of data storage locations. The reference stream is spatially sampled by comparing a hash value of each reference with a threshold value and selecting only those references whose hash value meets a selection criterion. Cache utility values are then compiled for those references. In some embodiments, the compiled cache values may then be corrected for accuracy as a function of statistics of those location identifiers over the entire stream of references and of the sampled references whose hash values satisfied the selection criterion. Alternatively, a plurality of caching configurations is selected and the selected references are applied as inputs to a plurality of caching simulations, each corresponding to a different caching configuration. A resulting set of cache utility values is then computed for each caching simulation.

Abstract: Cache utility curves are determined for different software entities depending on how frequently their storage access requests lead to cache hits or cache misses. Although possible, not all access requests need be tested, but rather only a sampled subset, determined by whether a hash value of each current storage location identifier (such as an address or block number) meets one or more sampling criteria. The sampling rate is adaptively changed so as to hold the number of location identifiers needed to be stored to compute the cache utility curves to within a set maximum limit.

Abstract: Interaction is evaluated between a computer system cache and at least one entity that submits a stream of references corresponding to location identifiers of data storage locations. The reference stream is spatially sampled by comparing a hash value of each reference with a threshold value and selecting only those references whose hash value meets a selection criterion. Cache utility values are then compiled for those references. In some embodiments, the compiled cache values may then be corrected for accuracy as a function of statistics of those location identifiers over the entire stream of references and of the sampled references whose hash values satisfied the selection criterion. Alternatively, a plurality of caching configurations is selected and the selected references are applied as inputs to a plurality of caching simulations, each corresponding to a different caching configuration. A resulting set of cache utility values is then computed for each caching simulation.

Abstract: Cache utility curves are determined for different software entities depending on how frequently their storage access requests lead to cache hits or cache misses. Although possible, not all access requests need be tested, but rather only a subset, determined by whether a hash value of each current storage location identifier (such as an address or block number) meets one or more sampling criteria.

Abstract: Contention for a resource in a computer system resource is managed by measuring a resource performance metric and, for each of a selected plurality of clients (for example, virtual machines), a client performance metric. For each of the selected clients, a relationship measure, such as correlation, is determined as a function of the resource performance metric and the respective client performance metric. A degree of resource contention effect is determined for each of the selected clients as a function of the respective relationship measure, and a resource-related action is taken according to the respective relationship measures. Clients may include virtualized components contending for storage. Example metrics include functions of I/O operation counts, latency or throughput measurements, pending I/O request counts, I/O throughput relative to I/O latency, a degree of change of the respective clients' I/O behavior, etc.

Abstract: Cache utility curves are determined for different software entities depending on how frequently their storage access requests lead to cache hits or cache misses. Although possible, not all access requests need be tested, but rather only a sampled subset, determined by whether a hash value of each current storage location identifier (such as an address or block number) meets one or more sampling criteria. The sampling rate is adaptively changed so as to hold the number of location identifiers needed to be stored to compute the cache utility curves to within a set maximum limit.

Abstract: Cache utility curves are determined for different software entities depending on how frequently their storage access requests lead to cache hits or cache misses. Although possible, not all access requests need be tested, but rather only a subset, determined by whether a hash value of each current storage location identifier (such as an address or block number) meets one or more sampling criteria.