This section presents the multi-backend storage feature introduced with the Grizzly release. Multi-backend allows the creation of several backend storage solutions serving the same OpenStack Compute configuration. Basically, multi-backend launches one cinder-volume per backend. In a multi-backend configuration, each backend has a name (volume_backend_name). Several backends can have the same name. In that case, the scheduler properly decides in which backend the volume has to be created. The name of the backend is declared as an extra-specification of a volume type (e.g. volume_backend_name=LVM_iSCSI). At a volume creation, according to the volume type specified by the user, the scheduler will choose an appropriate backend to handle the request. The multi-backend configuration is done into the cinder.conf file. The enabled_backends flag has to be set up. This flag defines the names (separated by a comma) of the config groups for the different backends: one name is associated to one config group for a backend (e.g. [lvmdriver-1]). The config group name is not related to the volume_backend_name. The options for a config group have to be defined in the group (or default options will be used). All the standard Cinder configuration options (volume_group, volume_driver, etc) may be used in a config group. Config values in the [DEFAULT] config group will not be used. The following example shows three backends: # a list of backends that will be served by this compute node enabled_backends=lvmdriver-1,lvmdriver-2,lvmdriver-3 [lvmdriver-1] volume_group=cinder-volumes-1 volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver volume_backend_name=LVM_iSCSI [lvmdriver-2] volume_group=cinder-volumes-2 volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver volume_backend_name=LVM_iSCSI [lvmdriver-3] volume_group=cinder-volumes-3 volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver volume_backend_name=LVM_iSCSI_b In this configuration lvmdriver-1 and lvmdriver-2 have the same volume_backend_name. This means that, if a volume creation requests the LVM_iSCSI backend name, the scheduler will choose between lvmdriver-1 and lvmdriver-2 which one is the most suitable. This is done thanks to the capacity filter scheduler which is enabled by default (the following section gives more information on that point). In addition, this example presents a third backend named lvmdriver-3. This one has a different backend name. Multi-backend has to be used with filter_scheduler enabled. Filter scheduler acts in two steps: First, filter scheduler filters the available backends. By default, AvailabilityZoneFilter, CapacityFilter and CapabilitiesFilter are enabled. Secondly, filter scheduler weights the previously filtered backends. By default, CapacityWeigher is enabled. The CapacityWeigher attributes high score to backends with the most available space. According to the filtering and weighing, the scheduler will be able to pick "the best" backend in order to handle the request. In that way, filter scheduler achieves the goal that one can explicitly creates volume on specifics backends using volume types. To enable the filter scheduler, the following line has to be added into the cinder.conf configuration file: scheduler_driver=cinder.scheduler.filter_scheduler.FilterScheduler However, filter_scheduler is the default Cinder Scheduler in Grizzly, this line is not mandatory. Before using it, a volume type has to be declared to Cinder. This can be done by the following command: $ cinder --os-username admin --os-tenant-name admin type-create lvm Then, an extra-specification have to be created to link the volume type to a backend name. This can be done by the following command: $ cinder --os-username admin --os-tenant-name admin type-key lvm set volume_backend_name=LVM_iSCSI In this example we have created a volume type named lvm with volume_backend_name=LVM_iSCSI as extra-specifications. We complete this example by creating another volume type: $ cinder --os-username admin --os-tenant-name admin type-create lvm_gold $ cinder --os-username admin --os-tenant-name admin type-key lvm_gold set volume_backend_name=LVM_iSCSI_b This second volume type is named lvm_gold and has LVM_iSCSI_b as backend name. To list the extra-specifications, use the following command line: $ cinder --os-username admin --os-tenant-name admin extra-specs-list If a volume type points to a volume_backend_name which does not exist in the Cinder configuration, the filter_scheduler will return an error mentioning that it is not able to find a valid host with the suitable backend. When creating a volume, the volume type has to be specified. The extra-specifications of the volume type will be used to determine which backend has to be used. cinder create --volume_type lvm --display_name test_multi_backend 1 Considering the cinder.conf described above, the scheduler will create this volume on lvmdriver-1 or lvmdriver-2. cinder create --volume_type lvm_gold --display_name test_multi_backend 1 This second volume will be created on lvmdriver-3.