Jump to: navigation, search

Difference between revisions of "Cinder-multi-backend"

(Configuration)
(add outdated info notice)
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
+
<div style="background-color:yellow; font-size:125%">
 +
<p>
 +
<strong>This page has been superseded by the "official" Cinder documentation:<br>
 +
https://docs.openstack.org/cinder/latest/admin/blockstorage-multi-backend.html</strong>
 +
</p>
 +
<p style="text-align:center">
 +
<em>This page is kept here for historical purposes only and is no longer maintained.</em>
 +
</p>
 +
</div>
 
= Cinder multi backends =
 
= Cinder multi backends =
 
This article is a explanation for creating an environment w/ multiple backends. Cinder volume backends are spawned as children to cinder-volume, and they are keyed from a unique Queue. They are named cinder-volume.HOST.BACKEND. Example cinder-volume.ubuntu.lvmdriver. The filter scheduler determines where to send the volume based on the volume type thats passed in.
 
This article is a explanation for creating an environment w/ multiple backends. Cinder volume backends are spawned as children to cinder-volume, and they are keyed from a unique Queue. They are named cinder-volume.HOST.BACKEND. Example cinder-volume.ubuntu.lvmdriver. The filter scheduler determines where to send the volume based on the volume type thats passed in.
Line 21: Line 29:
 
   </source>
 
   </source>
 
</div>
 
</div>
 +
 +
 +
The cinder-volume service does not monitor this config file, rather the file is read at startup.  You can restart the cinder-volume service (including the per-backend slaves) with the command `service cinder-volume restart`.
  
 
The cinder filter_scheduler also needs to be used in order to achieve the goal that one can explicitly create volume on certain back-end using volume types. However filter scheduler is the default scheduler starting Grizzly.
 
The cinder filter_scheduler also needs to be used in order to achieve the goal that one can explicitly create volume on certain back-end using volume types. However filter scheduler is the default scheduler starting Grizzly.

Latest revision as of 13:36, 18 December 2019

This page has been superseded by the "official" Cinder documentation:
https://docs.openstack.org/cinder/latest/admin/blockstorage-multi-backend.html

This page is kept here for historical purposes only and is no longer maintained.

Cinder multi backends

This article is a explanation for creating an environment w/ multiple backends. Cinder volume backends are spawned as children to cinder-volume, and they are keyed from a unique Queue. They are named cinder-volume.HOST.BACKEND. Example cinder-volume.ubuntu.lvmdriver. The filter scheduler determines where to send the volume based on the volume type thats passed in.

Configuration

The configuration now has a flag, enabled_backends. This defines the names of the option groups for the different backends. Each backend defined here has to link to a config group (example [lvmdriver]) in the configuration. A full example of this is included in the configuration with 2 backends. The options need to be defined in the group, or the defaults in the code will be used. Putting a config value in [DEFAULT] will not be used.

Example (cinder.conf)

# a list of backends that will be served by this machine
enabled_backends=lvmdriver-1,lvmdriver-2
[lvmdriver-1]
volume_group=stack-volumes-1
volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name=LVM_iSCSI
[lvmdriver-2]
volume_group=stack-volumes-2
volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name=LVM_iSCSI


The cinder-volume service does not monitor this config file, rather the file is read at startup. You can restart the cinder-volume service (including the per-backend slaves) with the command `service cinder-volume restart`.

The cinder filter_scheduler also needs to be used in order to achieve the goal that one can explicitly create volume on certain back-end using volume types. However filter scheduler is the default scheduler starting Grizzly.

scheduler_driver=cinder.scheduler.filter_scheduler.FilterScheduler

Volume Type

The volume_type must be defined in the volume_type table in the database. When creating a volume for a particular backend (or group of > 1 backends) the volume_type is passed in. There can be > 1 backend per volume_type, and the capacity scheduler kicks in and keeps the backends of a particular volume_type even. In order to group a volume_type to a backend, you must define extra specs for the type.

Example

  • cinder --os-username admin --os-tenant-name admin type-create lvm
  • cinder --os-username admin --os-tenant-name admin type-key lvm set volume_backend_name=LVM_iSCSI
  • cinder --os-username admin --os-tenant-name admin extra-specs-list (just to check the settings are there)

Usage

When creating a volume, specify the volume_type that you created in the above example. This will be used in determining which type of backend to send to. As previously stated, if there is > 1 backend for a type, the capacity scheduler is used.

  • cinder create --volume_type lvm --display_name my-test 1

If the volume type is defined in the database but no volume types exist for that backend in the configuration, then no valid host will be found. If both are true, it will prov to one of the volume backends.