通用卷迁移¶
https://blueprints.launchpad.net/cinder/+spec/generic-volume-migration
目标是允许不支持 iSCSI 并使用其他方式进行数据传输的卷驱动程序也能参与卷迁移操作。目前，现有代码使用 create_export 创建并通过 iSCSI 附加卷以执行 I/O 操作。通过使其更加通用，我们可以允许其他驱动程序也参与卷迁移。
此更改对于支持 Ceph 驱动程序的卷迁移是必要的。
问题描述¶
在两个后端之间迁移卷时，源卷驱动程序中的 copy_volume_data 例程会被执行，以将块从一个卷移动到另一个卷。此例程假定源卷和目标卷都可以通过 iSCSI 本地附加，并调用 create_export 来将卷附加到本地 cinder-volume 实例。这在技术上对于本地卷来说不是必需的，并且也阻止了像 Ceph 这样的驱动程序参与卷迁移操作。
用例¶
提议的变更¶
通过使用类似于备份卷驱动程序方法的文件类对象抽象，我们可以允许卷驱动程序确定如何最好地本地附加其卷。对于大多数驱动程序，这将继续是 iSCSI。对于 Ceph，将返回支持文件语义的 RBD 对象。在两种情况下，copy_volume_data 例程都以与现在相同的方式对这些文件对象进行操作，而无需显式了解底层传输机制。
具体来说，我想在卷驱动程序 (cinder/volume/driver.py) 中添加一个例程
- ::
open_volume() close_volume()
这些例程在执行本地卷附加时（如在 copy_volume_data() 中）被调用。我认为这些例程是必要的，因为本地文件 I/O 操作可能需要与标准的 create_export/initialize_connection 方法不同的传输方式。在 Ceph 的情况下，create_export 什么也不做，initialize_connection 返回 Nova 与 Ceph 卷直接通信所需的 RBD 连接信息。我们希望驱动程序作者保留这种灵活性。
open_volume 例程将返回一个支持文件操作（如读取、写入、查找等）的卷文件对象。close_volume 例程将处理卷文件对象的拆卸和清理。
这将允许 Ceph 返回一个与卷直接通信的文件类对象。其他后端，例如 LVM，将继续创建一个 iSCSI 导出，附加它，打开结果块设备，并返回对此文件的句柄。此外，本地 LVM 卷可以跳过 iSCSI 步骤并直接打开本地块设备。此更改稍后可以进行，目前的工作是进行支持该功能的必要的最少更改。
有了这些驱动程序例程，copy_volume_data 被修改为使用这些调用，而不是直接使用 _attach_volume。对于非 Ceph 驱动程序，结果与以前完全相同。RBD 驱动程序现在可以实现这些例程以添加对卷迁移的支持。
备选方案¶
最明显的替代方案是更改 Ceph 驱动程序以实现导出例程并允许通过 iSCSI 进行卷附加。这将意味着使用 rbd 内核驱动程序，这并不是理想的，因为它将代码引入到 cinder-volume 节点上运行的内核中，并且在功能上比 librbd 滞后一些。我们希望尽可能避免这种情况。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
如果一切正常，Ceph 与其他后端之间的卷迁移应该按预期工作。双向的。
性能影响¶
这种额外的抽象仅启用 iSCSI 附加的替代方案，不会对现有功能产生任何影响。
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
jbernard
工作项¶
引入文件对象抽象，并更改现有代码以使用 iSCSI 进行卷附加——就像现在一样。Ceph 迁移将继续失败。
实现 Ceph 特定的附加逻辑，应该允许卷迁移在其他后端之间成功。
添加测试（s）到 tempest 以验证代码路径是否正确执行并产生逐块完全相同的迁移结果。
依赖项¶
无
测试¶
我不认为卷迁移包含在 gate 中，但可以在 tempest 中进行测试。Ceph 卷迁移到非 Ceph 后端应该在两个方向上都成功。如果该测试通过，那么这项工作就成功了。
文档影响¶
我不认为这里需要任何操作。
参考资料¶
无
