844efef3cd
The administrator guide includes many links to the install guides, configuration guide, and so forth. As the administrator guide is the current version all links should link to current (Juno) vs. Icehouse or trunk (Kilo) versions of the docs. Closes-Bug: #1410565 Change-Id: I8fa3bc6d0af2ee90f436fe065b8897eefefa2be9
173 lines
10 KiB
XML
173 lines
10 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="volume-migration">
|
|
<title>Migrate volumes</title>
|
|
<para>OpenStack has the ability to
|
|
migrate volumes between back-ends. Migrating a volume
|
|
transparently moves its data from the current back-end for the
|
|
volume to a new one. This is an administrator function, and
|
|
can be used for functions including storage evacuation (for
|
|
maintenance or decommissioning), or manual optimizations (for
|
|
example, performance, reliability, or cost).</para>
|
|
<para>These workflows are possible for a migration:</para>
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>If the storage can migrate the volume on its own, it
|
|
is given the opportunity to do so. This allows the
|
|
Block Storage driver to enable optimizations that the
|
|
storage might be able to perform. If the back-end is
|
|
not able to perform the migration, the Block Storage
|
|
uses one of two generic flows, as follows.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>If the volume is not attached, the Block Storage
|
|
service creates a volume and copies the data from the
|
|
original to the new volume.</para>
|
|
<note>
|
|
<para>While most back-ends support this function, not all do.
|
|
See the driver documentation in the <link
|
|
xlink:href="http://docs.openstack.org/juno/config-reference/content/"
|
|
><citetitle>OpenStack Configuration
|
|
Reference</citetitle></link> for more
|
|
details.</para>
|
|
</note>
|
|
</listitem>
|
|
<listitem>
|
|
<para>If the volume is attached to a VM instance, the
|
|
Block Storage creates a volume, and calls Compute to
|
|
copy the data from the original to the new volume.
|
|
Currently this is supported only by the Compute
|
|
libvirt driver.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
<para>As an example, this scenario shows two LVM back-ends and
|
|
migrates an attached volume from one to the other. This
|
|
scenario uses the third migration flow.</para>
|
|
<para>First, list the available back-ends:</para>
|
|
<screen><prompt>#</prompt> <userinput>cinder-manage host list</userinput>
|
|
<computeroutput>server1@lvmstorage-1 zone1
|
|
server2@lvmstorage-2 zone1</computeroutput></screen>
|
|
<para>Next, as the admin user, you can see the current status of
|
|
the volume (replace the example ID with your own):</para>
|
|
<screen><prompt>$</prompt> <userinput>cinder show 6088f80a-f116-4331-ad48-9afb0dfb196c</userinput>
|
|
<computeroutput>+--------------------------------+--------------------------------------+
|
|
| Property | Value |
|
|
+--------------------------------+--------------------------------------+
|
|
| attachments | [...] |
|
|
| availability_zone | zone1 |
|
|
| bootable | False |
|
|
| created_at | 2013-09-01T14:53:22.000000 |
|
|
| display_description | test |
|
|
| display_name | test |
|
|
| id | 6088f80a-f116-4331-ad48-9afb0dfb196c |
|
|
| metadata | {} |
|
|
| os-vol-host-attr:host | server1@lvmstorage-1 |
|
|
| os-vol-mig-status-attr:migstat | None |
|
|
| os-vol-mig-status-attr:name_id | None |
|
|
| os-vol-tenant-attr:tenant_id | 6bdd8f41203e4149b5d559769307365e |
|
|
| size | 2 |
|
|
| snapshot_id | None |
|
|
| source_volid | None |
|
|
| status | in-use |
|
|
| volume_type | None |
|
|
+--------------------------------+--------------------------------------+</computeroutput></screen>
|
|
<para>Note these attributes:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><literal>os-vol-host-attr:host</literal> - the
|
|
volume's current back-end.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><literal>os-vol-mig-status-attr:migstat</literal> -
|
|
the status of this volume's migration (<literal>None</literal>
|
|
means that a migration is not currently in progress).</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><literal>os-vol-mig-status-attr:name_id</literal> -
|
|
the volume ID that this volume's name on the back-end
|
|
is based on. Before a volume is ever migrated, its
|
|
name on the back-end storage may be based on the
|
|
volume's ID (see the <option>volume_name_template</option>
|
|
configuration parameter). For example, if
|
|
<option>volume_name_template</option> is kept as the default
|
|
value (<literal>volume-%s</literal>), your first LVM back-end
|
|
has a logical volume named
|
|
<literal>volume-6088f80a-f116-4331-ad48-9afb0dfb196c</literal>.
|
|
During the course of a migration, if you create a
|
|
volume and copy over the data, the volume get the new name but keeps its
|
|
original ID. This is
|
|
exposed by the <literal>name_id</literal>
|
|
attribute.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<note>
|
|
<para>If you plan to decommission a block storage node, you must
|
|
stop the <systemitem class="service">cinder</systemitem> volume
|
|
service on the node after performing the migration.</para>
|
|
<para os="rhel;centos;fedora;opensuse;sles">On nodes that run
|
|
CentOS, Fedora, openSUSE, Red Hat Enterprise Linux, or SUSE Linux
|
|
Enterprise, run:</para>
|
|
<screen os="rhel;centos;fedora"><prompt>#</prompt> <userinput>service openstack-cinder-volume stop</userinput>
|
|
<prompt>#</prompt> <userinput>chkconfig openstack-cinder-volume off</userinput></screen>
|
|
<para os="debian;ubuntu">On nodes that run Ubuntu or Debian, run:
|
|
</para>
|
|
<screen os="debian;ubuntu"><prompt>#</prompt> <userinput>service cinder-volume stop</userinput>
|
|
<prompt>#</prompt> <userinput>chkconfig cinder-volume off</userinput></screen>
|
|
<para>Stopping the <systemitem>cinder</systemitem> volume service
|
|
will prevent volumes from being allocated to the node.</para>
|
|
</note>
|
|
<para>Migrate this volume to the second LVM back-end:</para>
|
|
<screen><prompt>$</prompt> <userinput>cinder migrate 6088f80a-f116-4331-ad48-9afb0dfb196c server2@lvmstorage-2</userinput></screen>
|
|
<para>You can use the <command>cinder show</command> command to
|
|
see the status of the migration. While migrating, the
|
|
<literal>migstat</literal> attribute shows states such as
|
|
<literal>migrating</literal> or
|
|
<literal>completing</literal>. On error,
|
|
<literal>migstat</literal> is set to
|
|
<literal>None</literal> and the <literal>host</literal>
|
|
attribute shows the original host. On success, in this
|
|
example, the output looks like:</para>
|
|
<screen><computeroutput>+--------------------------------+--------------------------------------+
|
|
| Property | Value |
|
|
+--------------------------------+--------------------------------------+
|
|
| attachments | [...] |
|
|
| availability_zone | zone1 |
|
|
| bootable | False |
|
|
| created_at | 2013-09-01T14:53:22.000000 |
|
|
| display_description | test |
|
|
| display_name | test |
|
|
| id | 6088f80a-f116-4331-ad48-9afb0dfb196c |
|
|
| metadata | {} |
|
|
| os-vol-host-attr:host | server2@lvmstorage-2 |
|
|
| os-vol-mig-status-attr:migstat | None |
|
|
| os-vol-mig-status-attr:name_id | 133d1f56-9ffc-4f57-8798-d5217d851862 |
|
|
| os-vol-tenant-attr:tenant_id | 6bdd8f41203e4149b5d559769307365e |
|
|
| size | 2 |
|
|
| snapshot_id | None |
|
|
| source_volid | None |
|
|
| status | in-use |
|
|
| volume_type | None |
|
|
+--------------------------------+--------------------------------------+</computeroutput></screen>
|
|
<para>Note that <literal>migstat</literal> is None,
|
|
<literal>host</literal> is the new host, and
|
|
<literal>name_id</literal> holds the ID of the volume
|
|
created by the migration. If you look at the second LVM
|
|
back end, you find the logical volume
|
|
<literal>volume-133d1f56-9ffc-4f57-8798-d5217d851862</literal>.</para>
|
|
<note>
|
|
<para>The migration is not visible to non-admin users (for
|
|
example, through the volume <literal>status</literal>).
|
|
However, some operations are not allowed while a
|
|
migration is taking place, such as attaching/detaching a
|
|
volume and deleting a volume. If a user performs such an
|
|
action during a migration, an error is returned.</para>
|
|
</note>
|
|
<note>
|
|
<para>Migrating volumes that have snapshots are currently not
|
|
allowed.</para>
|
|
</note>
|
|
</section>
|