Robin Systems, Inc.

Marvellworld Trade Ltd.

Violin Systems LLC

Jagadish Kumar Mukku

Dhanashankar Venkatesan

Ripulkumar Hemantbhai Patel

Kallur Vasudeva Rao Narasimha Subban

Ravi Kumar Alluboyina

Sandeep Karmarkar

Hy Dinh Vu

Shailesh Shiwalkar

Anil Goyal

Tushar Doshi

Nitin Singla

Partha Sarathi Seetala

Manjunath Mageswaran

Hector Cuellar

Snapshots are created of a unit of storage such that the snapshot includes all segments allocated to the unit of storage until a subsequent snapshot is created. A backup of a first snapshot may be performed by copying segments of the snapshot to backup storage. If a preceding snapshot has been backed up, those segments of the first snapshot are copied to backup storage without copying the segments of the preceding snapshot, otherwise all segments of the snapshot are copied. Metadata describing the snapshot may be retained but storage may be freed to be overwritten. The metadata may reference identifiers of segments copied to backup storage. Data stored in backup storage may also be labeled as individual segments or be associated with snapshot metadata in backup storage.

Managing snapshot metadata following backup

A new snapshot of a storage volume is created by instructing computing nodes to suppress write requests. Storage nodes create a new snapshot for the storage volume by allocating a new segment to the new snapshot and finalizes and performs garbage collection with respect to segments allocated to the previous snapshot. Subsequent write requests to the storage volume are then performed on the segments allocated to the new snapshot. A segment maps segments to a particular snapshot and metadata stored in the segment indicates storage volume addresses of data written to the segment. The snapshots may be represented by a storage manager in a hierarchy that identifies an ordering of snapshots and branches to clone snapshots. Consistency points may be created by storage nodes transmitting sequence numbers assigned to write IOPs to the storage manager. Segments store the sequence numbers in metadata enabling rolling back to specific sequence numbers.

Operation-level consistency points and rollback

A new snapshot of a storage volume is created by suppressing write requests. Once pending write requests from the computing nodes are completed, storage nodes create a new snapshot for the storage volume by allocating a new segment to the new snapshot. Subsequent write requests to the storage volume are then performed on the segments allocated to the new snapshot. An orchestration layer implements a bundled application that is provisioned with storage volumes and containers. A snapshot of the application may be created and used to rollback or clone the application. De-duplication may be performed by creating a signature map and identifying duplicated blocks. Blocks of segments containing duplicated blocks are copied to pool segments and metadata of those segments of the same logical storage unit may be consolidated to pool metadata segments. The identification of duplicate blocks may be performed in a cloud computing platform.

Data de-duplication

A new snapshot of a storage volume is created by instructing computing nodes to suppress write requests. Storage nodes create a new snapshot for the storage volume by allocating a new segment to the new snapshot and finalizes and performs garbage collection with respect to segments allocated to the previous snapshot. Subsequent write requests to the storage volume are then performed on the segments allocated to the new snapshot. A segment maps segments to a particular snapshot and metadata stored in the segment indicates storage volume addresses of data written to the segment. The snapshots may be represented by a storage manager in a hierarchy that identifies an ordering of snapshots and branches to clone snapshots. A non-snapshot volume may be converted to a snapshot volume at any point after creation.

Creating snapshots of a storage volume in a distributed storage system

A new snapshot of a storage volume is created by instructing computing nodes to suppress write requests. An orchestration layer implements a multi-role application that is provisioned with virtualized storage and computation resources. A snapshot of the application may be created and used to rollback or clone the application. Clones snapshots of storage volumes may be gradually populated with data from prior snapshots to reduce loading on a primary snapshot. A multi-role application may be orchestrated using multiple orchestration approaches and objects of the multi-role application may be discovered and added to an application definition. The application definition may be used to create snapshots of the application and the snapshot may be used to rollback, clone, backup, or migrate the application.

Orchestration of heterogeneous multi-role applications

A new snapshot of a storage volume is created by suppressing write requests. Once pending write requests from the computing nodes are completed, storage nodes create a new snapshot for the storage volume by allocating a new segment to the new snapshot. Data is written in segments and Metadata is stored in the segments indicating LBAs of data stored therein and offsets within the segments at which data for LBAs are stored. For write requests, index entries are stored in an index buffer for a segment and written to the segment when the buffer is full. A redo entry is created in a redo buffer for multiple storage volumes and slices for each write request. Write requests are acknowledged when the redo buffer is written to redo segments on a storage device. On restart, index buffers are reconstructed from the redo segments if needed.

Redo log for append only storage scheme

A new snapshot of a storage volume is created by suppressing write requests. Once pending write requests from the computing nodes are completed, storage nodes create a new snapshot for the storage volume by allocating a new segment to the new snapshot. Subsequent write requests to the storage volume are then performed on the segments allocated to the new snapshot. A block map records segments where current data for an LBA of a slice of a storage volume is stored. Block maps may be written to a storage device in order to free memory. Block maps may be read back into memory when needed. Writing and reading of block maps may be performed upon fragments of block maps. On restarting of the storage node, block maps may be restored from block maps stored in the storage device.

Block map cache

A distributed storage system stores a storage volume as segments that are allocated as needed and assigned VSIDs according to a monotonically increasing counter. The storage volume may be provisioned by an orchestration layer that manages the storage volumes as well as containers executing executable components of the storage volume. The storage volume may be replicated, such as by replicating slices of the storage volume. A primary copy of the slice may be moved from one node to another within the distributed storage system by designating it as a replica, creating a new replica at the new location which is then brought current. The new replica is then designated as the primary replica and the former primary replica may be deleted. A non-replicated storage volume may be converted to a replicated storage volume and vice versa.

Changing a distributed storage volume from non-replicated to replicated

A new snapshot of a storage volume is created by suppressing write requests. Once pending write requests from the computing nodes are completed, storage nodes create a new snapshot for the storage volume by allocating a new segment to the new snapshot. Subsequent write requests to the storage volume are then performed on the segments allocated to the new snapshot. An orchestration layer implements a bundled application that is provisioned with storage volumes and containers. A snapshot of the application may be created and used to rollback or clone the application. The amount of processing cores, memory, and containers may be increased or decreased based on usage. Amount of storage allocated to a storage volume may be augmented by a snapshot reservation ratio. The snapshot reservation ratio is adjusted over time according to usage.

Snapshot reservations in a distributed storage system

An application executing on a first computing platform includes containers executing role instances. One or more logical storage volumes include segments allocated to the application and references in a mapping table. The mapping table indicates a tier ID corresponding to the computing platform on which each segment is located. A snapshot of the application may be restored on a second computing platform. The mapping table may be copied to the second computing platform and used without transferring segments from the first computing platform to the second computing platform. Reads will be routed to the first computing platform using the tier ID in the mapping table.

Storage scheme for a distributed storage system

A distributed storage system stores a storage volume as segments that are allocated as needed and assigned VSIDs according to a monotonically increasing counter. The storage volume may be provisioned by an orchestration layer that manages the storage volumes as well as containers executing executable components of the storage volume. A storage volume may be stored across multiple tiers with a storage node managing on which tier a segment is stored based on a volume tier policy and usage of the segments. The tiering policy may be used to relocate the entire storage volume to a tier, such as a cloud computing platform, after which an application may be restored on the tier. Segments on a tier with built in redundancy may be used as both primary and backup copies.

Implementing storage volumes over multiple tiers

A new snapshot of a storage volume is created by instructing computing nodes to suppress write requests. Once pending write requests from the computing nodes are completed, storage nodes create a new snapshot for the storage volume by allocating a new segment to the new snapshot and finalizes and performs garbage collection with respect to segments allocated to the previous snapshot. The snapshots may be represented by a storage manager in a hierarchy. Deleted snapshots may be flagged as such in the hierarchy and deletion may be implemented only in memory on a storage node, which is then restored from the hierarchy in the event of a crash. A snapshot is removed from the hierarchy when all segments previously are freed by garbage collection. A hybrid storage node may perform both computing and storage services. Data may be written with tags indicating encoding protocols used to encode the data.

Encoding tags for metadata entries in a storage system

A new snapshot of a storage volume is created by instructing computing nodes to suppress write requests. Once pending write requests from the computing nodes are completed, storage nodes create a new snapshot for the storage volume by allocating a new segment to the new snapshot and finalizes and performs garbage collection with respect to segments allocated to the previous snapshot. The snapshots may be represented by a storage manager in a hierarchy. Deleted snapshots may be flagged as such in the hierarchy and deletion may be implemented only in memory on a storage node, which is then restored from the hierarchy in the event of a crash. A hybrid storage node may perform both computing and storage services. An IO module determines whether IOPs reference a locally-mounted storage device or a remote storage device. The IO module issues a library call for local IOPs using a shared memory in kernel space.

Implementing a hybrid storage node in a distributed storage system

Snapshot deletion in a distributed storage system

A storage system and method of operating the storage system is described where the metadata used to access the data stored in a storage device is distributed amongst a plurality of controllers in communication with a user, with each other and with the storage device. Each controller stores at least the metadata needed to access the data relevant to the user at the time, and metadata is updated to respond to internal system activities such as device failures, snapshots, backup operations or the like. To preserve coherence of the metadata, each metadata update is communicated to the other controllers and the storage device. The update is either transmitted to the other controllers and to the storage device and each metadata location is updated, or the update is transmitted to the storage device and each of the controllers is instructed to request an update from the storage device.

Growing community of inventors

San Jose, CA, United States of America

Jagadish Kumar Mukku