e4aac82b07
A standard pre-release patch, looking for any obsolete text to remove, and references to newly unsupported releases to remove. Feel free to update the patch if you find other things. Review request: this patch touches many files in a small way. Please try and focus on the small changes, and not the rest of the file ... since many of them do need an edit ;) Change-Id: I383c51acf149bb6553ddfd33cad382f5dd15fe62
147 lines
7.9 KiB
XML
147 lines
7.9 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<section xml:id="multi_backend" xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink" version="1.0">
|
|
<title>Configure a multiple-storage back-end</title>
|
|
<para>With multiple storage back-ends configured, you can create
|
|
several back-end storage solutions serving the
|
|
same OpenStack Compute configuration. Basically, multi
|
|
back-end launches one <systemitem class="service"
|
|
>cinder-volume</systemitem> for each back-end.</para>
|
|
<para>In a multi 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 multi back-end</title>
|
|
<para>To enable a multi back-end configuration, 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"># 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</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 multi back-end. Filter scheduler acts in two
|
|
steps:</para>
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>The filter scheduler filters the available
|
|
back-ends. By default,
|
|
<literal>AvailabilityZoneFilter</literal>,
|
|
<literal>CapacityFilter</literal> and
|
|
<literal>CapabilitiesFilter</literal> are
|
|
enabled.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>The filter scheduler weighs the previously
|
|
filtered back-ends. By default,
|
|
<literal>CapacityWeigher</literal> is enabled.
|
|
The <literal>CapacityWeigher</literal> attributes
|
|
higher scores to back-ends with the most
|
|
available.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
<para>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.</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>
|