Nexenta Cloud Copy on Write™ (CCOW™) is an object storage system providing for versioned access to objects with chunk-based distributed deduplication. Nexenta CCOW is composed of a set of software components that can be deployed in various fashions within bare metal and/or Virtual Machine servers.
In the deployment model shown on the picture below, a bare-metal or Virtual Machine is used to deploy a set of “Object Storage Servers”. The servers federate with each other to persistent storage that can survive the loss of any single server.
Each Object Storage Server has the following software components:
- Object Storage Access Server: provides one or more conventional object storage access methods to the clients. These interfaces will typically be compatible with existing protocols such as Amazon S3 or OpenStack Swift Object Service. These requests are translated into Chunk Requests and Manifest Requests that are forwarded to the co-located Chunk Server and Manifest Server.
- Chunk Server: provides for local storage of Chunks. A Chunk Server:
- Stores Chunks put to it. Each put request supplies a Transaction ID as relayed from the Manifest Server and the Chunk ID of the chunk to be put. Each Chunk is identified using a cryptographic hash of the optionally compressed chunk payload. If the Chunk is already known, the Chunk Servers completes the Chunk Put transaction successfully without requiring that the payload be transferred.>
- Replicates Chunks to the Designated Chunks Servers for this Chunk ID.
- Retains Chunks when this Chunk Server is one of that Chunk’s Designated Chunk Servers, or when there is space available and the Chunk has had sufficient traffic to warrant its local retention.
- Retrieves Chunks when stored locally, or from one of the Designated Chunk Servers otherwise.
- Maintains references to the referencing objects.
- Manifest Server: maintains metadata information about each version of an Object. Objects are organized within Service Directories that correspond to a traditional object service Container (aka Bucket). Each version is identified by a unique version identifier which can be generated by any Manifest Server based on a globally synchronized timestamp and a tiebreaker. The unique version identifier guarantees that Version Manifests can be applied by different Manifest Servers in different orders while still guaranteeing that all Manifest Servers will eventually achieve the same Version Manifest once all transactions are applied on all servers.
Each Manifest Server in part updates Chunk references on the Designated Chunk Servers for each chunk referenced whenever the effective Class of Storage requirement for a chunk derived from the Version Manifests for an Object has changed.
Next diagram shows an alternative deployment:
On the picture, Virtual Machines and/or bare metal servers are deployed to provide Object Storage service to co-located clients, while relying on a set of Permanent Object Storage Servers to provide reliable persistent storage. Note that the Local Object Storage Server deploys the same software but behaves differently in the following ways:
- It does not volunteer to be a Designated Chunk or Manifest Server. Therefore it is never required to retain any Chunk or Version Manifest. It will retain a subset of the Chunks/Version Manifests held by the Permanent Object Storage Servers for the current Cloud Copy on Write (CCOW™) Segment.
- Because it is not the Designated Server, it will always do a “Put” transaction for a new Chunk/Manifest to one of the Designated Servers, rather than a “Replicate” transaction.
- It will typically have less persistent storage available, and therefore will delete unreferenced Chunks/Versions more quickly.