Storage Backup Object Store Plugin Framework

Problem Statement

Currently CloudStack does not offer a flexible pluggable framework for users to easily integrate and configure any 3rd-party object stores for such backup services as registering templates, taking snapshots, etc. Along with Edison's recent refactored storage subsystem 2.0, we are proposing to develop a storage backup object store plugin framework to allow CloudStack to systematically manage and configure various types of backup data stores from different vendors.
With this new plugin framework, we would like to achieve following functionalities:

Support different object store providers in a uniform and extensible fashion

so that we can easily add an S3-based Object Storage as a secondary storage in CloudStack for storing all artifacts currently stored in secondary storage - snapshots, ISOs and templates. Although current CloudStack has some existing business logic to handle S3, Swift, NFS secondary storages, the code to interact with these vendor-specific providers is closely mingled together with CloudStack orchestration code, specifically, TemplateManagerImpl, SnapshotManagerImpl, etc, using an ugly if-else control flow. With such a tight coupling, it becomes very hard to extend the framework to support new object store providers. By extracting out ImageDataStore pluggble service interface, we can wrap these vendor-specific logic inside each provider plugin, then CloudStack orchestration code can be greatly simplified and provide a uniform and extensible way to manage different object store vendors.

Enable region wide object backup using s3-like object store.

Currently CloudStack only allows registering a template to a specific zone by using NFS secondary storage. In order to enable this template to another zone, user has to invoke copyTemplate to copy the template from one zone to another. With this new plugin framework, customers can plugin their own object store providers, like S3/Swift, etc and choose them as the backup store. CloudStack can provide an option in *registerTemplate* api to allow them to create either "perZone" or "regionWide" templat

Provide cache storage framework

For certain hypervisors, when moving data(either templates or snapshots, etc) between primary storage and backup object store, a cache storage is required. The cache storage acts as an intermediate storage, stores templates, volumes and snapshots temporarily. Current CloudStack uses admin provided NFS server as the only one cache storage and takes cache storage as zone-wide for granted.

It has its drawbacks: 

1. Admin can't add other type of storages as cache storage.
2. Deep coupled with cache storage in the operations related to template and snapshot upload, which is unnecessary and introduce scalability issue on cache storage.

With cache storage framework, 

Provide pluggable Data motion strategies to handle data transfer

Make SSVM optional and configurable

Storage DataStore Plugin Framework

In this new refactored backup datastore plugin framework, we have clearly defined those pluggable service interfaces, such as PrimaryDataStore, ImageDataStore, DataMotionStrategy, AutoScaleStrategy, etc, so that different storage providers can develop their vendor-specific plugins based on the well-defined contracts that can be seemlessly managed by CloudStack orchestration.

API Changes

Following will be the changes in their behavior post introduction of Object Store plugin framework:

snapshot commands

• CreateSnapshotCmd

Gliffy Macro Error

Cannot find a diagram with these parameters:

• Name: backup snapshot sequence
• Version: 1

---

Diagrams with the same name were found on the following pages:

Hover over the link to preview, click to set.

Storage subsystem 2.0

Storage subsystem 2.0

Storage subsystem 2.0

template/iso commands

• No changes: createTemplate, updateTemplate, listTemplates, updateTemplatePermissions, listTemplatePermissions, prepareTemplate
• To be changed:
  registerTemplate - Would register the URI. Download work would be done by S3 now.
  deleteTemplate - Would just unregister the template, physically deleting it from OS should happen through S3 api.
  extractTemplate - would just give the S3 url
  copyTemplate - would return success since the template would be available region wide.

volume commands

• No changes: attachVolume, detachVolume, deleteVolume, listVolumes
• To be changed:
  extractVolume - Do we put it into S3 now internally ?
  uploadVolume - similar to register template. User needs to put in just the S3 url here.
  createVolume - when creating volume from snapshot, zone id needs to be mentioned.
  migrateVolume - should work as is using scratch storage instead of nfs sec. storage.

Besides these existing API changes, we will provide two new admin APIs to configure backup object store provider:

• listBackupProviders – List CS managed backup providers and their capabilities.
• configureBackupProvider – choose a provider (like S3 or Swift) as backup provider.