Open Stack

Hi Chuck,

This idea is very good aligned with some functionality we intend to
propose as part of our Virtual Storage Array feature.

I suppose in general the goal here is to be able to create a volume from
storage of specified class. For me it means that:

1. User should be able to select storage type from some list of allowed
drive types
2. Scheduler-related:
	- Scheduler should find the appropriate storage node
	- Nova-volume service should collect node capabilities and report
to schedulers
3. Storage node (SN) running nova-volume service should be able to select
an appropriate driver for managing this request

In our VSA proposal we've introduced a new table of drive types with all
methods for controlling it. These types are currently used during VSA
creation process. User specifies what storage should be allocated for VSA
instances and such request automatically remapped through scheduler to
appropriate SN nodes. In our first version of APIs we extended os-volumes
API extensions and allowed drive_type selection there, but later reverted
it and created our own set of volume APIs.

As you know the current nova-volume driver mechanism doesn't allow
coexistence of drivers from several vendors/types. Especially, if you
would like to support "standard" volumes and new "enhanced" ones at the
same time.
Same is true for heterogeneous storage connected to the cloud managed by
different drivers. There are multiple possible ways of supporting multiple
types of volumes, including creation of derived classes and calling parent
class for "foreign" volumes, but we've decided to create a small wrapper
inside of nova-volume manager for picking up the correct driver. This
approach was not generalized yet, but it might be a good starting point.

Easily we could extend the table of drive types and add something like
"driver name" there or ... just add an additional drive_type field to
volume_api.create API.

We recently published our code for VSA proposal here -
lp:~vladimir.p/nova/vsa

It also includes several schedulers looking at drive_type field in volume
record and reverting to base class (SimpleScheduler) for regular volumes.
These schedulers are derived from SimpleScheduler, but using some aspects
of zone-aware scheduler including capabilities reporting.

We also have our own set of packages for recognizing different HW
capabilities and drive types, but this code may differ from vendor to
vendor.

Regards,
-Vladimir


-----Original Message-----
From: openstack-bounces+vladimir=zadarastorage.com at lists.launchpad.net
[mailto:openstack-bounces+vladimir=zadarastorage.com at lists.launchpad.net]
On Behalf Of Chuck Thier
Sent: Monday, July 18, 2011 4:06 PM
To: Openstack
Subject: [Openstack] Adding Volume Types to Nova Volume

There are two concepts that I would like Nova Volumes to support:

1.  Allow different storage classes within a storage driver.  For example,
in our case we will have some nodes with high iops capabilities and other
nodes for cheaper/larger  volumes.

2.  Allow for different storage backends to be used and specified by the
user.  For example, you might want to use both the Lunr volume backend,
and one of the SAN backends.

I think having the idea of a volume type when creating a volume would
support both of these features.  I have started a blueprint and spec
below, and would like to solicit feedback.

Blueprint: https://blueprints.launchpad.net/nova/+spec/volume-type
Spec: http://etherpad.openstack.org/volume-type

Please let me know what you think, and if you have any questions.

--
Chuck

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp