Difference between revisions of "NovaVsaSpec"
(No difference)
|
Revision as of 21:03, 12 April 2011
Summary
In order to emulate the current IT environments, and to provide better capabilities than Amazon's EBS, we would like to add to nova the capability to create virtual storage arrays. VIrtual Storage Arrays are block storage devices, that have the same performance, reliability and features than current enterprise SAN arrays like EMC Clariion or HP 3PAR. With this feature Users of the cloud will be able to buy, on demand, virtual storage arrays and connect them to their virtual servers as they do in the physical environment. Within the Virtual Storage Array (VSA), storage administrators will be able to choose things like type of drives (SSDs, SAS, SATA), type of interface (iSCSI, AoE, FCoE), cache size, how many virtual controllers, policies around snapshots and remote replications and RAID level. With this feature, cloud providers implementing OpenStack will be able to offer to their clients, enterprise class storage systems at the low cost of simple disk drives attached to servers. Users of the cloud, will be able to choose particular QoS for the storage they use (i.e use only SAS drives or only SATA).
The proposal is to add VSA as an addition to OpenStack without the need to change the volume APIs.
Release Note
From the end user standpoint, with this feature they will be able to create Virtual Storage Arrays and set the different QoS (i.e number of virtual controllers, size of cache in GBs, type fo drives (SSD, SAS, SATA) etc). Once a virtual storage array is created the user will create volumes in the same way as today, but with the optional parameter from which VSA. For example if the VSA has SAS drives, 4 virtual controllers and 128 GBs of cache, the new created volume will have much better performance than a volume created in VSA where all the drives are SATA and has only 4GB cache. The VSA is an optional feature and will not impose a change to users that don't want to use this feature.
Rationale
In order
User stories
Assumptions
Design
You can have subsections that better describe specific parts of the issue.
Implementation
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
UI Changes
Should cover changes required to the UI, or specific UI that is required to implement this
Code Changes
Code changes should include an overview of what needs to change, and in some cases even the specific details.
Migration
Include:
- data migration, if any
- redirects from old URLs to new ones, if any
- how users will be pointed to the new way of doing things, if necessary.
Test/Demo Plan
This need not be added or completed until the specification is nearing beta.
Unresolved issues
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.
