Page History

...

The current implementation of S3-backed secondary storage synchronizes files from NFS volumes -based secondary storage to an object store. The primary reason for this approach is that there is no provision for global (i.e. cross zone) secondary storage. Currently. the design of the secondary storage resource management facilities are under re-design. In order to support direct access to an object store, it would beneficial if a simple object store SPI was introduced that met the following requirements:

1. Stream Oriented: All interfaces must based on Input/Output stream rather than File. This higher-level abstraction would permit uploads and downloads to be re-directed to the object store rather than using intermediate writes to disk. Furthermore, a stream-based interface would also permit the use of diskless compute nodes.
2. Zone Optional: Remove the requirement that secondary storage be associated with a zone.

This new facility will also need to work based on Input/OutputStreams raher than requiring underlying file system. When this architectural redesign is completed, then this feature can be modified to directly access the object store. Such an enhancement would greatly simplify the implementation and deployment of S3-backed secondary storage. It would also allow users of S3-backed secondary storage to realize significant cost savings by removing redundant storage capacity for NFS vlumes volumes in each zone.

Quality Risks/Test Guidelines

...

S3-backed secondary storage does not add any system-level requirements to CloudStack.

Deployment

The only pre-requisite following are the prerequisites for S3-backed secondary storage is a :

• A subscription to or configuration of an S3-compatible object store
• An empty bucket configured and associated access key and secret key with read/write access for the exclusive use of CloudStack

. A global configuration option, enable. s3.secondary.storageenable, is then enabled and following a restart of the management server(s), the administrator can configure the object store's connection parameters.

...

The design of this feature is based on the approach taken for the Swift integration. As such, this feature requires an NFS volume in each zone to search as a cache for assets. This approach was selected due to the architecture re-design work being performed around secondary storage, and the relative newness of the developer implementing the feature. As the new architecture stablizes, this decision will be re-evaluated. Given the basic nature of the core S3 integration, much of the work for this implementation should be transferable to the new architecturea lack of support for global secondary storage. If the secondary storage re-design permits global storage and integration points compatible with an object store, then this approach may be re-evaluated.

Template and ISO upload to the object store is facilitated by a thread which compares the contents of the NFS volume and the object store. Each element that is not present in the object store is uploaded to the object store. Currently, this process is single threaded whereby one assest is uploaded at a time. This approach simplifies the synchronization process, but may introduce measurable latency when a number of large files need to pushed to the object store.

...