卷迁移改进¶
https://blueprints.launchpad.net/cinder/+spec/migration-improvement
本规范旨在改进当前的卷迁移，包括实现更好的卷迁移状态管理方式、添加迁移进度指示、通过向 Ceilometer 报告丰富通知系统、通过 Tempest 测试和 CI 支持保证迁移质量等。它旨在解决当前仅针对可用卷的问题，因为我们需要等待 Nova 中的多卷附加功能发布后才能解决与附加卷相关的问题。将会有另一份规范专门用于解决与附加卷相关的问题。
用例¶
拥有良好 定义的能力将允许部署者查看 Cinder 中超出其已部署后端共享的通用能力。
卷迁移有三种情况。本规范的范围仅限于可用卷，旨在解决以下迁移情况 1 和 2 中的问题
在本规范的范围内 1) 使用“dd”命令迁移可用卷。例如，从 LVM 到 LVM，从 LVM 到厂商驱动程序，以及不同厂商驱动程序之间。
2) 使用驱动程序特定的方式在同一厂商驱动程序的两个池之间迁移可用卷。Storwize 被视为本规范的参考示例。
超出本规范范围 3) 使用 Cinder 通用迁移的正在使用（已附加）卷迁移。
问题描述¶
目前，卷迁移存在一些直接的问题。1. 迁移成功或失败的信息没有保存，这让管理员感到非常困惑。即使管理员在 cinder migrate 命令中指定 –force 标志，卷状态仍然是可用或正在使用。2. 从 API 的角度来看，管理员无法检查迁移的状态。检查迁移是否成功或失败的唯一方法是检查数据库。3. 在迁移过程中，通过“cinder list”命令检查时，数据库记录中会出现两个卷。一个是源卷，一个是目标卷。后者实际上没有用处，会导致管理员混淆。4. 执行“cinder migrate”命令时，大多数情况下终端不会向管理员返回任何信息，这不够友好，需要改进。5. 迁移过程可能需要很长时间才能完成。目前管理员无法从日志中获取有关迁移进度的任何信息。6. 没有向 Ceilometer 报告任何信息。7. 没有 Tempest 测试用例，也没有 CI 支持来确保迁移真正适用于任何类型的驱动程序。
我们建议添加迁移状态管理以解决问题 1 到 4，添加迁移进度指示以涵盖问题 5，添加通知以解决问题 6，并添加 Tempest 测试和 CI 支持以解决问题 7。
提议的变更¶
一开始，我们声明所有更改和测试用例都专门针对可用卷。对于附加卷，我们将等待 Nova 中合并多卷附加功能。
卷迁移状态管理
如果迁移失败，迁移状态设置为“error”。如果迁移成功，迁移状态设置为“success”。如果卷从未进行过迁移，迁移状态设置为 None。迁移状态用于记录之前的迁移结果。只有管理员才能查看迁移状态。
管理员可以通过以下几种方式检查迁移状态：1) 管理员可以使用带有过滤器“migration_status=<期望的卷迁移状态>”的常规“volume list”来查找所有具有指定迁移状态的卷。如果未指定过滤器，则所有卷将列出迁移状态。2) 管理员可以针对某个卷发出“get”命令，迁移状态可以在字段‘os-vol-mig-status-attr:migstat’中找到。
如果管理员使用 –force 标志发出 migrate 命令，卷状态将更改为‘maintenance’。在迁移期间不允许附加或分离。如果管理员在没有 –force 标志的情况下发出 migrate 命令，卷状态将保持不变。在迁移期间发出的附加或分离操作将中止迁移。‘maintenance’状态可以扩展到在任何其他情况下使用，在这种情况下，由于任何原因，卷服务不可用。
我们计划在管理员运行“cinder migrate”命令时提供更多信息。如果迁移能够启动，我们将返回消息“您的迁移请求已收到。请检查迁移状态和服务器日志以获取更多信息。”如果 API 拒绝了迁移，我们应该返回诸如“由于某些原因，您的迁移请求处理失败”之类的消息。
我们计划删除冗余的虚拟目标卷信息。如果 Cinder 内部租户(https://review.openstack.org/#/c/186232/) 成功实施，我们将应用该补丁以隐藏目标卷。
迁移进度指示
我们希望引入轮询机制，以在一定间隔内检查迁移进度，作为迁移进度指示的实现。轮询机制可以在循环中实现，并且迁移进度将在 cinder.conf 中可配置的某个间隔内进行检查。该机制可以与卷迁移并行运行。
如果卷复制开始，另一个用于迁移进度检查的线程也将开始。如果卷复制结束，则迁移进度检查线程结束。
可以向每个驱动程序添加一个名为 migration_progress_report 的驱动程序能力。它为 True 或 False。这用于在卷从一个池迁移到同一存储后端中的另一个池的情况。如果为 True，则将启动轮询机制的循环。否则，将不会启动轮询机制。
可以将一个名为 migration_progress_report_interval 的配置选项添加到 cinder.conf 中，指定需要检查迁移进度的频率。例如，如果将 migration_progress_report_interval 设置为 30 秒，则代码将每 30 秒检查一次迁移进度并报告一次。
如果使用 dd 命令迁移卷，例如从 LVM 到 LVM，从 LVM 到厂商驱动程序，通过 blockcopy 从一个后端迁移到另一个后端等，则可以通过 /proc/<PID>/fdinfo/1 的位置指示来检查迁移进度。
如果卷使用文件 I/O 迁移，当前文件指针能够报告已传输数据的偏移量。可以通过相对于 EOF 的此位置来检查迁移进度。
如果卷在同一后端的不同池之间迁移，我们希望通过检查存储后端的统计信息来实现此功能。Storwize V7000 被视为报告迁移进度的参考实现。有些驱动程序可能支持进度报告，有些可能不支持。将添加一个新的键“migration_progress_report”到驱动程序中以报告该能力。如果后端驱动程序支持报告迁移进度，则将此键设置为 True。否则，将此键设置为 False，并且在这种情况下不支持进度报告。
迁移进度只能由管理员检查。由于进度未存储，每次从 API 查询进度时，请求将安排到 cinder-volume 服务，该服务可以获取指定卷的更新迁移进度并报告回来。
备选方案¶
我们可以使用隐藏标志来指示数据库行是显示还是隐藏。但是，cinder 需要一种一致的方式来解决其他问题，例如图像缓存、备份等，我们达成一致，cinder 内部租户是前进的方向。
我们计划更好地管理卷迁移状态、添加迁移进度指示、将统计信息报告给 Ceilometer 以及提供 Tempest 测试和 CI 的目的，仅仅是为了保证迁移以更可靠和稳定的方式工作。
数据模型影响¶
无
REST API 影响¶
REST API 应该能够为卷提供迁移状态和迁移进度信息。对于迁移状态，可以从数据库中检索。对于迁移进度，API 请求将安排到位于卷所在位置的 cinder volume 服务，cinder volume 服务将报告更新的进度。
安全影响¶
无
通知影响¶
卷迁移应将启动、进度和完成的通知发送到 Ceilometer。
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
如果后端驱动程序支持迁移进度指示，可以添加一个新的配置选项 migration_progress_report_interval。管理员可以决定 cinder volume 服务报告迁移进度的频率。例如，如果将 migration_progress_report_interval 设置为 30 秒，则 cinder volume 服务将每 30 秒提供一次进度信息。
开发人员影响¶
驱动程序维护者或开发人员应该知道他们需要添加一个新的能力来指示他们的驱动程序是否支持进度报告。如果是，他们需要实现相关的该方法，如本规范的实施中所述。
如果他们的驱动程序已经实现了卷迁移，集成测试和驱动程序 CI 对于确保质量至关重要。他们也需要注意并为他们的驱动程序实施这一点。
实现¶
负责人¶
- 主要负责人
Vincent Hou (sbhou@cn.ibm.com)
- 其他贡献者
Jay Bryant Jon Bernard
工作项¶
卷迁移状态管理
1) 如果迁移失败，将 migration_status 更改为“error”；如果迁移成功，将 migration_status 更改为“success”。2) 如果管理员使用 –force 标志执行迁移命令，将卷状态更改为“maintenance”。在此迁移期间不允许附加或分离。如果管理员在没有 –force 标志的情况下执行迁移命令，卷状态将保持不变。迁移期间的附加或分离操作将终止迁移，以确保卷的可用性。3) 使用 cinder migrate 和 retype 命令的友好消息丰富 cinderclient。4) 隐藏迁移期间冗余的虚拟目标卷。
迁移进度指示
添加一个循环来包装轮询机制的实现。
支持迁移进度报告的驱动程序将 migration_progress_report 设置为 True。否则，将其设置为 False。
将使用选项 migration_progress_report_interval 来指定检查迁移进度的间隔时间。
1) 如果卷在 LVM 后端之间迁移，或者从一个后端迁移到另一个后端，可以检查 /proc/<PID>/fdinfo/1 的位置指示来获取 blockcopy 的进度。
2) 如果卷在同一后端的不同池之间迁移，我们希望在一定的时间间隔内检查后端存储的进度报告。
迁移百分比将被记录并报告给 Ceilometer。
通知
添加在迁移期间将启动、进度和结束发送到 Ceilometer 的代码。
Tempest 测试和 CI 支持
这项工作计划分两个步骤完成。第一步称为手动模式，其中 Tempest 测试已准备好，人们需要手动配置 OpenStack 环境以满足测试要求。
第二步称为自动模式，其中 Tempest 测试可以在网关中自动运行。根据 OpenStack 基础设施的当前状态，我们只能执行手动模式。自动模式需要与 OpenStack-infra 团队合作，并且将为此创建一个蓝图。
将添加以下用例：1) 从 LVM(thin) 到 LVM(thin) 2) 从 LVM(thin) 到 Storwize 3) 从 Storwize 到 LVM(thin) 4) 从 Storwize Pool 1 到 Storwize Pool 2
此外，RBD 驱动程序也将提供与上述 (2) 到 (4) 类似的测试用例。
我们确信其他驱动程序可以参与测试。本规范的目标是添加 LVM、Storwize 和 RBD 驱动程序的测试用例作为启动。我们希望其他驱动程序可以将 LVM、Storwize 和 RBD 的实施作为未来的参考。
文档
更新管理员手册，以及驱动程序开发人员和维护人员的开发参考。
依赖项¶
Cinder 内部租户：https://review.openstack.org/#/c/186232/ 添加对文件 I/O 卷迁移的支持：https://review.openstack.org/#/c/187270/
测试¶
取决于解析 LVM 驱动程序所需的信息的可能性，将考虑以下可用卷场景：1) 使用 Cinder 通用迁移从 LVM(thin) 到 LVM(thin)。2) 使用 Cinder 通用迁移从 LVM(thin) 到厂商驱动程序。3) 使用 Cinder 通用迁移从厂商驱动程序到 LVM(thin)。4) 使用驱动程序特定的方式在同一厂商驱动程序的两个池之间迁移。
还有一些其他场景，但对于本次发布，我们计划考虑以上所述。对于场景 1 到 3，我们计划将测试用例放入 Tempest。对于场景 4，我们计划将测试放入 CI。场景 2 的参考案例是从 LVM 迁移到 Storwize V7000。场景 3 的参考案例是从 Storwize V7000 迁移到 LVM。
文档影响¶
应该更新文档，告知管理员如何使用 migrate 和 retype 命令。描述哪些命令适用于哪种用例，如何检查迁移状态，如何配置和检查迁移指示等。
参考文档将被更新，告知驱动程序维护者或开发者如何更改他们的驱动程序以适应本次迁移改进，链接为 https://docs.openstack.org/developer/cinder/devref/index.html。
