Sandisk Enterprise IP LLC

Sun Microsystems, Inc.

Oracle America, Inc.

Sap Se

Sandisk Technologies Inc.

Schooner Information Technology, Inc.

Sandisk Enterprises IP LLC

Darpan Dinker

Pramod Gopinath

Brian Walter O'Krafka

Mahesh Kannan

Darryl Ouye

Michael John Koster

Andrew David Eckhardt

Suveen R Nadipalli

Johann George

Manavalan Krishnan

Earl T Cohen

Thomas M McWilliams

Sudhir Tonse

John Richard Busch

James M Bodwin

Dhirendra Pandey

Aaron Keith Olbrich

Vipul Gupta

Balaji Raghunathan

Jan L Bonebakker

Ulrich Bruening

Thomas A Riddle

Evgeny H Firsov

Patrick Chiu

Kannan Bhoopathy

Herbert D Schwetman

Richard Jordan

Various embodiments of systems, computer program products, and methods for encrypting data in a multi-tenant cloud environment are described herein. In an aspect, an encryption time frame to encrypt data associated with a user in a multi-tenant cloud environment may be retrieved. Based on the encryption time frame, a list of object types to be encrypted may be identified. A batch encryption period may be determined for encrypting data corresponding to the list of object types. Further, batches are sequentially selected based on the batch encryption period, for a selected batch: one or more data records may be retrieved based on the batch encryption period and the one or more data records may be encrypted in groups based on at least one throttling value.

Data encryption in a multi-tenant cloud environment

A persistent storage device includes both persistent storage, which includes a set of persistent storage blocks, and NVRAM, and in particular a set of NVRAM blocks. The persistent storage device also typically includes a storage controller. The persistent storage device, in addition to responding to commands to write data directly to and to read data directly from persistent storage blocks is also configured to write data to specified NVRAM blocks (e.g., specified by a host NVRAM write command) and to transfer data from a specified NVRAM block to a specified persistent storage block. As a result, multiple writes to a particular persistent storage block can be replaced with multiple writes to an NVRAM block and a subsequent single write to the particular persistent storage block. This reduces the number of writes to persistent storage and also reduces the number of corresponding block erase operations.

Persistent storage device with NVRAM for staging writes

A method for retrieving versioned data in a non-volatile memory is provided. The method includes: (1) receiving a read request for a data object, (2) in response to the request, determining, via an object table, whether one or more versions of the data object exist in memory, (3) in accordance with a determination that one or more versions exist in memory, obtaining, via the object table, a respective location where each of the one or more versions of the data object are stored, and (4) reading at least one of the one or more versions of the data object from the respective location into volatile memory.

Low level object version tracking using non-volatile memory write generations

Approaches for a non-volatile, solid-state storage system that is capable of supporting high bandwidth and/or random read/write access. The storage system may include a chassis having a bus slot and a disk bay, a master card mounted in the bus slot, and a flash memory card stacked in the disk bay and cabled to the master card. The master card enables one or more flash memory cards to be communicatively coupled to a single PCI Express bus. The master card may split a multi-lane PCI Express bus into a plurality of lanes, where one or more of the flash memory cards communicate over each of the plurality of lanes. Alternately, the master card may includes active circuitry for processing, switching, routing, reformatting, and/or converting the PCI Express bus into one or more busses for a plurality of flash memory cards. The stacked flash memory card is not in an enclosure.

Non-volatile solid-state storage system supporting high bandwidth and random access

Approaches for throttling backgrounds processes to a high degree of precision. The utilization of a shared resource that is used by one or more background processes is monitored. A frequency at which the one or more background processes are executed is dynamically adjusted based on the current utilization of the shared resource without adjusting the frequency in which one or more foreground processes are executed to ensure that the utilization of the shared resource does not exceed a threshold value. The monitoring of the utilization of the shared resource may be performed more often than the adjusted of the frequency at which the background processes are executed, and the utilization of the shared resources may be performed many times a second. Consequently, the utilization of the shared resource may be above a certain level (such as 65%) and less than another level, such as 90%, when background processes are executing.

Fine grained adaptive throttling of background processes

Approaches for a distributed storage system that comprises a plurality of nodes. Each node, of the plurality of nodes, executes one or more application processes which are capable of accessing persistent shared memory. The persistent shared memory is implemented by solid state devices physically maintained on each of the plurality of nodes. Each the one or more application processes, maintained on a particular node, of the plurality of nodes, communicates with a shared data fabric (SDF) to access the persistent shared memory. The persistent shared memory comprises a scoreboard implemented in shared DRAM memory that is mapped to a persistent storage. The scoreboard provides a crash tolerant mechanism for enabling application processes to communicate with the shared data fabric (SDF).

Cluster of processing nodes with distributed global flash memory using commodity server technology

Approaches for recovering a node of a distributed transactional system. When a recovering node is being brought on-line, a copy of at least a portion of a first data store maintained by an existing node is created without ceasing to process transactions against the first data store at the existing node. The recovering node creates a second data store based on the copy of the first data store. While the recovering node creates the second data store, the recovering node stores committed transaction data received from a plurality of nodes. The committed transaction data describes transactions committed against data stores maintained by the sender of the committed transaction data. The recovering node may thereafter replay, against the second data store, any transactions identified by the committed transaction data that are associated with a global transaction number that is more recent than is a reference commit number.

Efficient recovery of transactional data stores

Data versioning in a non-volatile memory. An object key associated with a data object is created. An index into an object table is generated using the object key. A version number is stored in conjunction with the data object stored in the non-volatile memory. In an object linked-list, the object key and the location information of the data object in the non-volatile memory are stored. A record associated with the data object is created in an object table. The record includes an index, a reference to the object linked-list, and the version number. The index is generated based on the object key.

Approaches for processing an event in an objects store, such as an MySQL database management system or a memcached caching system, that are maintained on one or more solid state devices. A plurality of threads may be instantiated. Each of the threads may be configured to retrieve items from a queue of items. Each item in the queue of items may be associated with a particular event occurring within the object store. Each event is a message that indicates an activity requiring work has occurred within the object store. When a particular thread retrieves an item from the queue of items, the particular thread processes the particular event associated with the item retrieved by the particular thread. In this way, event handling in object stores such as MySQL and memcached may be performed more efficiently on a solid state device.

Event processing in a flash memory-based object store

A Sharing Data Fabric (SDF) causes flash memory attached to multiple compute nodes to appear to be a single large memory space that is global yet shared by many applications running on the many compute nodes. Flash objects stored in flash memory of a home node are copied to an object cache in DRAM at an action node by SDF threads executing on the nodes. The home node has a flash object map locating flash objects in the home node's flash memory, and a global cache directory that locates copies of the object in other sharing nodes. Application programs use an applications-programming interface (API) into the SDF to transparently get and put objects without regard to the object's location on any of the many compute nodes. SDF threads and tables control coherency of objects in flash and DRAM.

Sharing data fabric for coherent-distributed caching of multi-node shared-distributed flash memory

Approaches for an object store implemented, at least in part, on one or more solid state devices. The object store may store objects on a plurality of solid state devices. The object store may include a transaction model means for ensuring that the object store performs transactions in compliance with atomicity, concurrency, isolation, and durability (ACID) properties. The object store may include means for providing parallel flushing in a write cache maintained on each of the solid state devices. The object store may include means for maintaining one or more double-write buffers, for the object store, at a location other than the solid state devices. The object store may optionally comprise means for maintaining one or more circular transaction logs, for the object store, at a location other than the solid state devices. The object store may operate to minimize write operations performed on the solid state devices.

Efficient flash memory-based object store

Approaches for minimizing the amount of write transactions issued to an object store maintained on a solid state device (SSD). Transactions requested against an object store maintained on a SSD may be committed once transaction information for the transaction is durably stored in a non-volatile dynamic random access memory (DRAM), which may be maintained in a HDD controller. Further, data blocks stored in a volatile cache of a database server that issues write requests to an object store maintained on one or more SSDs may be considered persistent stored once confirmation is received that the data blocks are written to a double-write buffer stored on a non-volatile medium, such as NV RAM in a HDD controller. Additionally, any data blocks that are to be written over in a non-volatile DRAM are first ensured to be no longer present within the volatile write cache maintained a the solid state device.

Minimizing write operations to a flash memory-based object store

Approaches for replicating data in a distributed transactional system. At a first node of a cluster, a per-transaction write set, comprising a plurality of write operations, is committed against a first MySQL database. One or more per-transaction write sets are replicated from the first node to a second node. Upon receiving a read query, the second node parses the read query to identify a read set, calculates a write set conflict window for the read query, and upon determining that the read set conflicts with one or more write sets in the write set conflict window, waits to process the read query until all conflicting write sets are committed. However, upon determining that the read set does not conflict any write sets in the write set conflict window, the read query is processed without first committing any write transactions in the write set conflict window for the read query.

Slave consistency in a synchronous replication environment

Approaches for performing a write operation on a solid state device (SSD). One or more containers are maintained on the solid state device. Each container is a logical grouping of objects independent from where the logical grouping of objects are physically stored on the solid state device. When a write operation is received at the SSD, the manner is which changes requested by the write operation should be stored are determined based on which container is being written. Containers provide a flexible approach for specifying attributes of how data should be stored and accessed which is independent from where the data is physically stored. Containers also have particular utility in performing load balancing and ensuring high availability and recovery.

Flexible way of specifying storage attributes in a flash memory-based object store

Approaches for replicating data in a distributed transactional system. At a first node of a cluster, a per-transaction write set that comprises a plurality of write operations that are performed against a first data store maintained by the first node is committed. The per-transaction write set is replicated from the first node to a second node of the cluster. At the second node, the plurality of write operations, specified by the per-transaction write set, may be performed in parallel against a second data store maintained by the second node. At the second node, two or more threads may perform a portion of the plurality of write operations against data blocks stored within an in-memory buffer.

Growing community of inventors

Union City, CA, United States of America

Darpan Dinker