CLOUD STORAGE SYSTEM WITH DISTRIBUTED METADATA

• US 20130041872A1
• Filed: 08/12/2011
• Published: 02/14/2013
• Est. Priority Date: 08/12/2011
• Status: Active Grant

• Current Assignee: Nexenta by DDN, Inc.
• Original Assignee: Alexander Aizman
• Inventors: Aizman, Alexander, Bestler, Caitlin
• Granted Patent: US 8,533,231 B2
• Time in Patent Office: Days
• US Class Current: 707/690
• CPC Class Codes: G06F 16/182 Distributed file systems

Abstract

A method and system is disclosed for providing a cloud storage system supporting existing APIs and protocols. The method of storing cloud storage system (CSS) object metadata separates object metadata that describes each CSS object as a collection of named chunks with chunk locations specified as a separate part of the metadata. Chunks are identified using globally unique permanent identifiers that are never re-used to identify different chunk payload. While avoiding the bottleneck of a single metadata server, the disclosed system provides ordering guarantees to clients such as guaranteeing access to the most recent version of an object. The disclosed system also provides end-to-end data integrity protection, inline data deduplication, configurable replication, hierarchical storage management and location-aware optimization of chunk storage.

Claims

1. A system comprising:

one or more enhanced chunk servers (ECS) that validate that chunk data is consistent with the chunk identifier used; and

one or more metadata servers, wherein a first subset of those metadata servers are responsible for object metadata that encodes information on objects and versions of objects, while a second subset of metadata servers are responsible for chunk metadata that tracks the locations of chunks.

2. The system of claim 1 further comprising one or more Cloud Storage Access Modules (CSAMs) that support external cloud storage system API (CSS-API) and protocol (CSS-protocol) clients configured supporting distributed deduplication and end-to-end integrity checking.

3. A method for avoiding single metadata server bottlenecks on processing cloud storage system (CSS) object metadata, the method comprising:

dividing the metadata storage for a cloud storage system between Object metadata that encodes information on object and versions of objects and Chunk metadata that tracks the locations of chunks;

identifying each chunk reference in the object metadata using a globally unique permanent chunk identifier which is never re-used to identify a different payload; and

maintaining the CSS object metadata in a shared global name space, wherein the CSS object metadata is distributed over the plurality of object metadata servers (OMDS).

4. The method of claim 3, wherein end-to-end data integrity is ensured by one or more enhanced chunk servers (ECS) not accepting a chunk for storage when the chunk identifier is inconsistent with the chunk payload.

5. The method of claim 3, wherein at least one of the OMDSs archives CSS object metadata to external storage services so that the CSS object metadata can be expunged from the local file systems and restored from an external storage system when needed.

6. The method of claim 3, wherein one or more Chunk Metadata Servers (CMDS) archives chunks to external storage services so that they can be expunged from the ECSs and restored from the external storage system when needed.

7. The method of claim 3, where each OMDS maintains the object metadata for each CSS object as metadata file within a local file system using a file name derived from a fully qualified object name.

8. The method of claim 3, wherein the OMDSs create a global name space by publishing their object metadata files using distributed network attached storage (NAS) protocol.

9. The method of claim 3, wherein a collective CMDS is responsible for storing and retrieving chunk metadata.

10. The method of claim 3, wherein a permanent chunk identifier is used to permanently identify all persistently stored chunks, wherein the permanent chunk identifier is based upon a cryptographic hash algorithm of sufficient strength that excludes the possibility of a preimage attack.

11. The method of claim 3, wherein a permanent chunk identifier comprises a lesser hash algorithm with a unique identifier assigned by either a CSAM or an ECS.

12. The method of claim 3, wherein the identification of a chunk is deferred during a put transaction using a deferred chunk identifier to act as a temporary placeholder for a permanent chunk identifier.

13. The method of claim 3, wherein each CSS object at any point in time has a designated home OMDS which is solely responsible for assigning new version numbers.

14. The method of claim 13, wherein each CSS object is represented by an object directory in the OMDS local file system with a directory name derived from the fully qualified object name.

15. The method of claim 14, wherein each version of a CSS object is represented by an object metadata file within the object directory with a name that encodes the version and contents that encode the set of permanent chunk identifiers sufficient to reconstruct the object and the required sequencing information for those chunks.

16. The method of claim 3, wherein each OMDS maintains transactional consistency of metadata derived from information in the object metadata files.

17. The method of claim 3, wherein an OMDS acts as a NAS client to access metadata files in the OMDS shared global name space.

18. The method of claim 3, wherein the ECSs or the CMDSs encode chunk files named based upon the chunk class of storage and permanent chunk identifier, the chunk files optionally hold the compressed payload for this chunk as the data, and the metadata of the chunk file encodes the identifiers of zero or more other ECSs known to hold the payload for this chunk.

19. The method of claim 18, wherein a request to get a chunk that has no local payload stored for it is answered with a chunk referral response redirecting the requester to another ECS that does have the chunk payload stored.

20. The method of claim 18, wherein one of the ECSs issues a chunk referral response when it has determined that processing this get request itself would cause excessive delay.

21. The method of claim 18, wherein one of the ECSs will acknowledge each valid put of a chunk with a chunk cookie that encodes the permanent chunk identifier for the chunk, the length of the chunk data after compression and context information supplied by the CSAM which the OMDS may use to validate the commit of the full object.

22. The method of claim 21, wherein an ECS that receives a request to put a chunk that is identified with a deferred chunk identifier will:

validate that the checksum encoded in the deferred chunk identifier is valid unless it was delivered over a transport protocol with sufficient protection from transmission errors;

determine what the permanent chunk identifier should be for the chunk payload;

store the chunk under that permanent chunk identifier, if not already present; and

provide a chunk cookie as an acknowledgement.

23. The method of claim 9, wherein one of the ECSs will report an error when the payload read for a chunk is inconsistent with its chunk identifier.