This section presents the multi back-end storage feature introduced with the Grizzly release. Multi back-end allows the creation of several back-end storage solutions serving the same OpenStack Compute configuration. Basically, multi back-end launches one cinder-volume for each back-end. In a multi back-end configuration, each back-end has a name (volume_backend_name). Several back-ends can have the same name. In that case, the scheduler properly decides which back-end the volume has to be created in. The name of the back-end is declared as an extra-specification of a volume type (such as, volume_backend_name=LVM_iSCSI). When a volume is created, the scheduler chooses an appropriate back-end to handle the request, according to the volume type specified by the user. To enable a multi back-end configuration, you must set the enabled_backends flag in the cinder.conf file. This flag defines the names (separated by a comma) of the configuration groups for the different back-ends: one name is associated to one configuration group for a back-end (such as, [lvmdriver-1]). The configuration group name is not related to the volume_backend_name. The options for a configuration group must be defined in the group (or default options are used). All the standard Block Storage configuration options (volume_group, volume_driver, and so on) might be used in a configuration group. Configuration values in the [DEFAULT] configuration group are not used. These examples show three back-ends: # a list of back-ends that are 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. If a volume creation requests the LVM_iSCSI back-end name, the scheduler uses the capacity filter scheduler to choose the most suitable driver, which is either lvmdriver-1 or lvmdriver-2. The capacity filter scheduler is enabled by default. The next section provides more information. In addition, this example presents a lvmdriver-3 back-end. You must enable the filter_scheduler option to use multi back-end. Filter scheduler acts in two steps: The filter scheduler filters the available back-ends. By default, AvailabilityZoneFilter, CapacityFilter and CapabilitiesFilter are enabled. The filter scheduler weighs the previously filtered back-ends. By default, CapacityWeigher is enabled. The CapacityWeigher attributes higher scores to back-ends with the most available. The scheduler uses the filtering and weighing process to pick the best back-end to handle the request, and explicitly creates volumes on specific back-ends through the use of volume types. To enable the filter scheduler, add this line to the cinder.conf configuration file: scheduler_driver=cinder.scheduler.filter_scheduler.FilterScheduler While the Block Storage Scheduler defaults to filter_scheduler in Grizzly, this setting is not required. Before using it, a volume type has to be declared to Block Storage. This can be done by the following command: $ cinder --os-username admin --os-tenant-name admin type-create lvm Then, an extra-specification has to be created to link the volume type to a back-end name. Run this command: $ cinder --os-username admin --os-tenant-name admin type-key lvm set volume_backend_name=LVM_iSCSI This example creates a lvm volume type with volume_backend_name=LVM_iSCSI as extra-specifications. Create 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 back-end name. To list the extra-specifications, use this command: $ cinder --os-username admin --os-tenant-name admin extra-specs-list If a volume type points to a volume_backend_name that does not exist in the Block Storage configuration, the filter_scheduler returns an error that it cannot find a valid host with the suitable back-end. When you create a volume, you must specify the volume type. The extra-specifications of the volume type are used to determine which back-end has to be used. $ cinder create --volume_type lvm --display_name test_multi_backend 1 Considering the cinder.conf described previously, the scheduler creates this volume on lvmdriver-1 or lvmdriver-2. $ cinder create --volume_type lvm_gold --display_name test_multi_backend 1 This second volume is created on lvmdriver-3.