5f33b97fb3
Upon enabling multi-backend, existing cinder volumes may no longer be usable as the "old" default cinder host name is no longer running. You need to convert the host name of existing volumes to the new "host@backend" type naming. Partial-Bug: #1437761 Change-Id: I1beb83e0117bd35eb17ece8953f204f1a26089ea
158 lines
8.6 KiB
XML
158 lines
8.6 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 storage or back-end storage pool.</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>
|
|
<note>
|
|
<para>After setting the <option>enabled_backends</option> flag
|
|
on an existing cinder service, and restarting the Block Storage
|
|
services, the original <literal>host</literal>
|
|
service is replaced with a new host service. The new service
|
|
appears with a name like <literal>host@backend</literal>. Use:
|
|
<screen><prompt>$</prompt> <userinput>cinder-manage volume host --currentname <replaceable>CURRENTNAME</replaceable> --newname <replaceable>CURRENTNAME</replaceable>@<replaceable>BACKEND</replaceable></userinput></screen>
|
|
to convert current block devices to the new hostname.</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>
|