[openstack-dev] [cinder]The backend-group concept in Cinder
sombrafam at gmail.com
Wed Jun 15 12:53:32 UTC 2016
You can define several backends with the same volume_backend_name and call
that a group. For example:
So, no matter what storage is behind every backend, it will be filtered
based on the backend_name (and the other capabilities each backend
reports). If you don't want to restart the volume service to each backend
you add. You can add another instance of cinder-volume, even in the same
controller. The scheduler will know how to handle the new ones.
On Tue, Jun 14, 2016 at 6:15 AM, chen ying <chenyingkof at outlook.com> wrote:
> Hi Duncan Thomas,
> Does you means we can create a volume type include list of backend
> names(such as: backend_name="<in> name1 name2 name3 name4"), so when we
> create a volume, we can use the volume type to choose one backend from
> these list of backend names(name1,name2,name3,name4)?
> But in this way, we cannot show the backends obviously capabilities to
> users(such as: performance, ssd, spinning-rust etc).
> *发件人:* Duncan Thomas <duncan.thomas at gmail.com>
> *发送时间:* 2016年6月14日 8:03
> *收件人:* OpenStack Development Mailing List (not for usage questions)
> *主题:* Re: [openstack-dev] [cinder]The backend-group concept in Cinder
> As long as each backend has a unique name, you can key the type to a list
> of backend names if there's no useful capabilities to key off. No restart
> On 14 June 2016 at 10:16, chen ying <chenyingkof at outlook.com> wrote:
>> Hi John,
>> User case 1:
>> The backends in backend-group-1 have SSD disk, more memory .
>> The backend-group-1 can provide higher performance to user.
>> The other backends in backend-group-2 have HHD disk, more
>> capacity. The backend-group-2 can provide more storage space to user .
>> Not sure, but we sort of do some of this already via the filter
>> scheduler. An Admin can define various types (they may be set up based on
>> performance, ssd, spinning-rust etc). Those types are then given arbitrary
>> definitions via a type (again details hidden from end user) and he/she can
>> create volumes of a specific type.
>> Yes, An Admin can arbitrary define various types and he/she can create
>> volumes of a specific type. But we need to restart our cinder driver after
>> define various types in each driver(If the driver cannot report
>> capabilities by itself). It will not easy to manage for Admin.
>> Does Admin could use the concept of dynamically adding/removing backends
>> to backend-group. In this way, we not need to modify backend configure
>> file(such as: report a capabilities of ssd, spinning-rust etc).We can
>> arbitrary define various types for backend-group, and also he/she can
>> create volumes of a specific type(from backend-group type).
>> So for example I could say "I want these backends with capability XYZ",
>> and many of backends from different vendors. How to manage these backends
>> by Administrator?
>> 1. Admin need modify backend configure file, let the backend
>> report capability XYZ to filter scheduler.
>> 2. Restart the volume service, make the capability valid
>> 3. Create volume type(test_type) with capability XYZ.
>> 4. he/she can create volumes of a specific type(test_type)
>> Now we expect:
>> 1. Admin add backend to backend-group
>> 2. Create volume type(test_type) with capability XYZ, use
>> frefix(group or something else (group: capability = XYZ)) to distinguish
>> between the backend capability and the backend-group capability.
>> 3. he/she can create volumes of a specific type(test_type)
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> Duncan Thomas
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev