openstack-manuals/doc/admin-guide-cloud/blockstorage/section_multi_backend.xml
Christian Berendt d99744c3df Unified the syntax of the XML root element (admin-guide-cloud)
The XML root element of Docbook XML files should match the following
format:

<ELEMENT xmlns="http://docbook.org/ns/docbook"
  xmlns:xi="http://www.w3.org/2001/XInclude"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  version="5.0"
  xml:id="THE_XML_ID_OF_THE_ELEMENT">

Change-Id: I95a6f36d6887af952257a800e3359d53ac1f895a
2014-07-09 19:43:01 +02:00

148 lines
7.9 KiB
XML

<?xml version="1.0" encoding="UTF-8"?>
<section xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xml:id="multi_backend">
<title>Configure multiple-storage back ends</title>
<para>When you configure multiple-storage back ends, you can
create several back-end storage solutions that serve the same
OpenStack Compute configuration and one <systemitem class="service">cinder-volume</systemitem>
is launched for each back end.</para>
<para>In a multiple-storage back end configuration, each back end has a name
(<literal>volume_backend_name</literal>). 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.</para>
<para>The name of the back end is declared as an
extra-specification of a volume type (such as,
<literal>volume_backend_name=LVM_iSCSI</literal>). 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.</para>
<simplesect>
<title>Enable multiple-storage back ends</title>
<para>To enable a multiple-storage back ends, you must set
the <option>enabled_backends</option> flag in the
<filename>cinder.conf</filename> 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, <literal>[lvmdriver-1]</literal>).</para>
<note>
<para>The configuration group name is not related to the
<literal>volume_backend_name</literal>.</para>
</note>
<para>The options for a configuration group must be defined in
the group (or default options are used). All the standard
Block Storage configuration options
(<literal>volume_group</literal>,
<literal>volume_driver</literal>, and so on) might be
used in a configuration group. Configuration values in the
<literal>[DEFAULT]</literal> configuration group are
not used.</para>
<para>These examples show three back ends:</para>
<programlisting language="ini">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</programlisting>
<para>In this configuration, <literal>lvmdriver-1</literal>
and <literal>lvmdriver-2</literal> have the same
<literal>volume_backend_name</literal>. If a volume
creation requests the <literal>LVM_iSCSI</literal> back
end name, the scheduler uses the capacity filter scheduler
to choose the most suitable driver, which is either
<literal>lvmdriver-1</literal> or
<literal>lvmdriver-2</literal>. The capacity filter
scheduler is enabled by default. The next section provides
more information. In addition, this example presents a
<literal>lvmdriver-3</literal> back end.</para>
</simplesect>
<simplesect>
<title>Configure Block Storage scheduler multi back
end</title>
<para>You must enable the <option>filter_scheduler</option>
option to use multiple-storage back ends. The filter scheduler:</para>
<orderedlist>
<listitem>
<para>Filters the available back
ends. By default,
<literal>AvailabilityZoneFilter</literal>,
<literal>CapacityFilter</literal> and
<literal>CapabilitiesFilter</literal> are
enabled.</para>
</listitem>
<listitem>
<para>Weights the previously
filtered back ends. By default, the
<option>CapacityWeigher</option> option is
enabled. When this option is enabled, the filter
scheduler assigns the highest weight to back ends
with the most available capacity.</para>
</listitem>
</orderedlist>
<para>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.</para>
<!-- TODO: when filter/weighing scheduler documentation will be up, a ref should be added here -->
</simplesect>
<simplesect>
<title>Volume type</title>
<para>Before using it, a volume type has to be declared to
Block Storage. This can be done by the following
command:</para>
<screen><prompt>$</prompt> <userinput>cinder --os-username admin --os-tenant-name admin type-create lvm</userinput></screen>
<para>Then, an extra-specification has to be created to link
the volume type to a back end name. Run this
command:</para>
<screen><prompt>$</prompt> <userinput>cinder --os-username admin --os-tenant-name admin type-key lvm set volume_backend_name=LVM_iSCSI</userinput></screen>
<para>This example creates a <literal>lvm</literal> volume
type with <literal>volume_backend_name=LVM_iSCSI</literal>
as extra-specifications.</para>
<para>Create another volume type:</para>
<screen><prompt>$</prompt> <userinput>cinder --os-username admin --os-tenant-name admin type-create lvm_gold</userinput></screen>
<screen><prompt>$</prompt> <userinput>cinder --os-username admin --os-tenant-name admin type-key lvm_gold set volume_backend_name=LVM_iSCSI_b</userinput></screen>
<para>This second volume type is named
<literal>lvm_gold</literal> and has
<literal>LVM_iSCSI_b</literal> as back end
name.</para>
<note>
<para>To list the extra-specifications, use this
command:</para>
<screen><prompt>$</prompt> <userinput>cinder --os-username admin --os-tenant-name admin extra-specs-list</userinput></screen>
</note>
<note>
<para>If a volume type points to a
<literal>volume_backend_name</literal> that does
not exist in the Block Storage configuration, the
<literal>filter_scheduler</literal> returns an
error that it cannot find a valid host with the
suitable back end.</para>
</note>
</simplesect>
<simplesect>
<title>Usage</title>
<para>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.
<screen><prompt>$</prompt> <userinput>cinder create --volume_type lvm --display_name test_multi_backend 1</userinput></screen>
Considering the <literal>cinder.conf</literal> described
previously, the scheduler creates this volume on
<literal>lvmdriver-1</literal> or
<literal>lvmdriver-2</literal>.</para>
<screen><prompt>$</prompt> <userinput>cinder create --volume_type lvm_gold --display_name test_multi_backend 1</userinput></screen>
<para>This second volume is created on
<literal>lvmdriver-3</literal>.</para>
</simplesect>
</section>