openstack-manuals/doc/admin-guide-cloud-rst/source/blockstorage_multi_backend.rst
zhangguoqing cee582f99a [admin-guide-cloud-rst] fix catalog structure
The catalog's structure is wrong which is the section
'Configure multiple-storage back ends' that under
the 'Manage volumes' in 'Block Storage'.

Change-Id: Ia3e949cde1fcb5db5987ba6643e5322187172f48
2015-07-29 10:58:19 +00:00

182 lines
6.2 KiB
ReStructuredText

.. _multi_backend:
.. highlight: ini
:linenothreshold: 5
====================================
Configure multiple-storage back ends
====================================
When you configure multiple-storage back ends, you can create several
back-end storage solutions that serve the same OpenStack Compute
configuration and one ``cinder-volume`` is launched for each back-end
storage or back-end storage pool.
In a multiple-storage 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.
Enable multiple-storage back ends
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To enable a multiple-storage back ends, you must set the
`enabled_backends` flag in the :file:`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]``).
.. note::
The configuration group name is not related to the ``volume_backend_name``.
.. note::
After setting the `enabled_backends` flag on an existing cinder
service, and restarting the Block Storage services, the original ``host``
service is replaced with a new host service. The new service appears
with a name like ``host@backend``. Use::
$ cinder-manage volume update_host --currentname CURRENTNAME --newname CURRENTNAME@BACKEND
to convert current block devices to the new hostname.
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:
.. code-block:: ini
:linenos:
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.
.. note::
For Fiber Channel drivers that support multipath, the configuration group
requires the ``use_multipath_for_image_xfer=true`` option. In
the example below, you can see details for HP 3PAR and EMC Fiber
Channel drivers.
.. code-block:: ini
:linenos:
[3par]
use_multipath_for_image_xfer = true
volume_driver = cinder.volume.drivers.san.hp.hp_3par_fc.HP3PARFCDriver
volume_backend_name = 3parfc
[emc]
use_multipath_for_image_xfer = true
volume_driver = cinder.volume.drivers.emc.emc_smis_fc.EMCSMISFCDriver
volume_backend_name = emcfc
Configure Block Storage scheduler multi back end
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You must enable the `filter_scheduler` option to use
multiple-storage back ends. The filter scheduler:
#. Filters the available back ends. By default, ``AvailabilityZoneFilter``,
``CapacityFilter`` and ``CapabilitiesFilter`` are enabled.
#. Weights the previously filtered back ends. By default, the
`CapacityWeigher` option is enabled. When this option is
enabled, the filter scheduler assigns the highest weight to back
ends with the most available capacity.
The scheduler uses filters and weights to pick the best back end to
handle the request. The scheduler uses volume types to explicitly create
volumes on specific back ends.
.. TODO: when filter/weighing scheduler documentation will be up, a ref
should be added here
Volume type
~~~~~~~~~~~
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.
.. note::
To list the extra-specifications, use this command::
$ cinder --os-username admin --os-tenant-name admin extra-specs-list
.. note::
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.
Usage
~~~~~
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 :file:`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``.