openstack/openstack-manuals
Code Issues Proposed changes

Converts section_volume-migration.xml to RST

Browse Source 
[admin-guide-cloud-rst] Block Storage
In 'Manage volumes' section:
converts blockstorage/section_volume-migration.xml
to blockstorage_volume_migration.rst

Change-Id: Icd65a49b1556ac89005d06650eb1157e23391a4e
This commit is contained in:
zhangguoqing
2015-07-09 14:29:26 +08:00
parent dcee631998
commit 19b5183d1f
2 changed files with 199 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
doc/admin-guide-cloud-rst/source/blockstorage-manage-volumes.rst
View File

@@ -59,6 +59,7 @@ troubleshoot your installation and back up your Compute volumes.
.. include:: blockstorage_glusterfs_backend.rst
.. include:: blockstorage_multi_backend.rst
.. include:: blockstorage_backup_disks.rst
.. include:: blockstorage_volume_migration.rst
.. include:: blockstorage_glusterfs_removal.rst
.. include:: blockstorage_volume_backups.rst
.. include:: blockstorage-lio-iscsi-support.rst
@@ -75,6 +76,7 @@ troubleshoot your installation and back up your Compute volumes.
blockstorage_glusterfs_backend.rst
blockstorage_multi_backend.rst
blockstorage_backup_disks.rst
blockstorage_volume_migration.rst
blockstorage_glusterfs_removal.rst
blockstorage_volume_backups.rst
blockstorage-lio-iscsi-support.rst
@@ -84,6 +86,5 @@ troubleshoot your installation and back up your Compute volumes.
blockstorage_over_subscription.rst
.. TODO (MZ) Convert and include the following sections
include: blockstorage/section_volume-migration.xml
include: blockstorage/section_volume-backups-export-import.xml
include: blockstorage/section_volume_number_weighter.xml

197
doc/admin-guide-cloud-rst/source/blockstorage_volume_migration.rst Normal file
View File

@@ -0,0 +1,197 @@
.. _volume_migration.rst:
.. highlight: ini
:linenothreshold: 5
Migrate volumes
~~~~~~~~~~~~~~~
OpenStack has the ability to migrate volumes between back-ends which support
its volume-type. 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).
These workflows are possible for a migration:
#. 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.
#. If the volume is not attached, the Block Storage service creates a volume
and copies the data from the original to the new volume.
.. note::
While most back-ends support this function, not all do. See the driver
documentation in the `OpenStack Configuration Reference
<http://docs.openstack.org/kilo/config-reference/content/>`__ for more
details.
#. 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.
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.
First, list the available back-ends:
.. code::
# cinder get-pools
.. code::
+----------+----------------------------------------------------+
| Property | Value |
+----------+----------------------------------------------------+
| name | server1@lvmstorage-1#lvmstorage-1 |
+----------+----------------------------------------------------+
+----------+----------------------------------------------------+
| Property | Value |
+----------+----------------------------------------------------+
| name | server2@lvmstorage-2#lvmstorage-2 |
+----------+----------------------------------------------------+
.. note::
Only Block Storage V2 API supports :command:`get-pools`.
You can also get available back-ends like following:
.. code::
# cinder-manage host list
server1@lvmstorage-1 zone1
server2@lvmstorage-2 zone1
But it needs to add pool name in the end. For example,
``server1@lvmstorage-1#zone1``.
Next, as the admin user, you can see the current status of the volume
(replace the example ID with your own):
.. code::
$ cinder show 6088f80a-f116-4331-ad48-9afb0dfb196c
.. code::
+--------------------------------+--------------------------------------+
| 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#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 |
+--------------------------------+--------------------------------------+
Note these attributes:
* ``os-vol-host-attr:host`` - the volume's current back-end.
* ``os-vol-mig-status-attr:migstat`` - the status of this volume's migration
(None means that a migration is not currently in progress).
* ``os-vol-mig-status-attr:name_id`` - 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
``volume_name_template`` configuration parameter). For example, if
``volume_name_template`` is kept as the default value (``volume-%s``), your
first LVM back-end has a logical volume named
``volume-6088f80a-f116-4331-ad48-9afb0dfb196c``. 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 ``name_id``
attribute.
.. note::
If you plan to decommission a block storage node, you must stop the
``cinder`` volume service on the node after performing the migration.
On nodes that run CentOS, Fedora, openSUSE, Red Hat Enterprise Linux,
or SUSE Linux Enterprise, run:
.. code::
# service openstack-cinder-volume stop
# chkconfig openstack-cinder-volume off
On nodes that run Ubuntu or Debian, run:
.. code::
# service cinder-volume stop
# chkconfig cinder-volume off
Stopping the cinder volume service will prevent volumes from being
allocated to the node.
Migrate this volume to the second LVM back-end:
.. code::
$ cinder migrate 6088f80a-f116-4331-ad48-9afb0dfb196c server2@lvmstorage-2
You can use the :command:`cinder show` command to see the status of the
migration. While migrating, the ``migstat`` attribute shows states such as
``migrating`` or ``completing``. On error, ``migstat`` is set to None and the
host attribute shows the original ``host``. On success, in this example, the
output looks like:
.. code::
+--------------------------------+--------------------------------------+
| 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#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 |
+--------------------------------+--------------------------------------+
Note that ``migstat`` is None, host is the new host, and ``name_id`` holds the
ID of the volume created by the migration. If you look at the second LVM back
end, you find the logical volume
``volume-133d1f56-9ffc-4f57-8798-d5217d851862``.
.. note::
The migration is not visible to non-admin users (for example, through the
volume ``status``). 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.
.. note::
Migrating volumes that have snapshots are currently not allowed.