Share Server Migration¶

https://blueprints.launchpad.net/manila/+spec/share-server-migration

Manila 支持一种部署模型，其中 share 驱动程序能够处理 share 服务器的创建和管理，以及 share 及其功能[1]。通过管理每个租户级别的不同 share 服务器，Manila 利用其配置存储实体的能力，并为管理员提供更强的可管理性。正如 Liberty 版本中呈现的，并在 Mitaka、Newton 和 Ocata 版本中得到改进，share 迁移操作允许管理员以非破坏性方式将 share 迁移到不同的后端，通过实施两阶段迁移方法。本规范现在建议将此迁移概念扩展到 share 服务器实体，依赖于能够以原子和高效的方式执行此操作的 share 驱动程序。

问题描述¶

管理员可能需要处理后端撤离或负载均衡等情况，并面临将大量 share 一一迁移到特定且可能通用的目标的问题。即使使用额外的工具或脚本，这项任务也难以管理，并且主要难以从故障状态中恢复。缺乏帮助管理员重新平衡/撤离大型存储系统的功能是提出以下解决方案的原因。

用例¶

在多种场景下，share 服务器迁移对云管理员都非常有用

负载均衡：将 share 迁移到具有更多可用容量的后端，从而释放空间供其他 share 增长；
优化：迁移 share 并释放后端，以节省电力。将数据移近主机，以获得更好的网络性能；
撤离：撤离过旧或正在经历故障的后端；
维护：将 share 迁移到较新的硬件版本/型号；
其他：更改 share 的配置，例如：share 网络、安全服务等。

提议的变更¶

正如 Newton 版本中的 share 迁移设计[2]一样，两阶段迁移逻辑也将应用于 share 服务器。通过调用 share-server-migration-start，share 服务器迁移可以开始将所有数据从源端复制到目标端，包括所有 share、快照和 share 访问权限（如果实现它的驱动程序支持）。

完成第一阶段后，管理员可以计划并启动第二阶段，通过调用 ‘share-server-migration-complete’ 来完成操作，这通常会导致 share 访问中断，因为 share 的导出位置可能会更新。

重要的是要注意，在迁移 share 服务器时，许多 share 属性在过程中不会被修改，而 share 服务器属性可能会根据提供的参数而更改。管理员可以提供一个新的 ‘Share Network’ 与新的 share 服务器关联，但无法更改其 share 的属性，例如 ‘Share Type’，因为这是一个 share 级别实体，并且不同的 ‘Share Types’ 可以存在于同一个 share 服务器中。

Share API 和 Manager 变更¶

share API 将持有在继续驱动程序调用和数据库更新之前所需的所有验证。API 将检查正在迁移的 share 服务器内的任何 share 是否处于无效状态，或者是否有任何无法与 share 一起迁移的依赖资源。如果其中任何验证无法通过，迁移可能会提前失败。

在开始迁移之前，share 服务器及其所有 share 的状态都将被更新，以反映正在执行的操作，并阻止在此操作启动后可能触发的任何其他操作。源 share 服务器及其所有 share 的状态将被更新为 server_migrating，而目标 share 服务器将被更新为 server_migrating_to。通过更改所有 share 的状态，用户可以识别出一组被阻止接收任何其他操作的 share。

在成功通过所有验证后，share 服务器的新属性 task_state 将被更新为 server_migration_starting，并且调度器将被调用以验证主机是否与提供的 share 类型匹配。

到达 share manager 的迁移启动方法后，将触发驱动程序调用以分析目标后端是否可以在开始迁移之前处理此操作。如果无法满足所需的选项之一，迁移将失败。

share manager 将更新 share 服务器的 task_state 为 server_migrating，以及所有实例的状态为 server_migrating。目标后端可能会请求一个新的 share 服务器来保存来自源端的所有数据。预计驱动程序能够识别正在请求一个用于迁移用途的新服务器。之后，将调用驱动程序以启动 share 服务器迁移并立即返回。

share manager 的周期性任务将持续检查 task_state 设置为 server_migrating 的 share 服务器，以调用驱动程序接口 share_server_migration_continue，以跟踪处于迁移第一阶段的 share 服务器的进度。成功完成第一阶段后，share 服务器 task_state 将被更新为 server_migrating_phase1_done。

最后，share manager 的 share_server_migration_complete 方法可以被调用用于已经完成第一阶段的 share 服务器，以完成迁移。在此阶段，驱动程序被调用以完成 share 服务器迁移并在后端执行最后一步，并返回所有 share 的导出位置列表。share 服务器的 task_state 设置为 server_migration_completed，并且所有 share 的导出路径在它们再次变为 available 之前被更新。

在移动到第二阶段之前，在数据复制期间或在完成第一阶段时，管理员可以通过调用 share_server_migration_cancel API 来取消操作。如果驱动程序支持，取消操作将删除过程中创建的所有新内容，并且 share 服务器及其所有 share 将返回到初始状态。

Scheduler 变更¶

调度器的过滤器可用于验证目标主机是否可以容纳与正在迁移的 share 服务器关联的所有 share。Share API 需要提供 share 服务器的总大小以及所有关联 share 类型的功能，以便验证目标主机是否适合新的 share 服务器。但是，调度器无法验证跨多个池的 share 服务器，对于这种场景，share 服务器迁移需要依赖驱动程序的检查来验证这种操作的可行性。

备选方案¶

另一种方法是使用脚本或任何其他自动化工具，使用 share 迁移功能逐个将所有 share 移动到新的目标位置。

数据模型影响¶

将在 Share Server 表中添加一个新字段，以帮助跟踪 share 服务器迁移的状态。新的字段 task_state 将与 Share 表中已有的相同字段一样工作。管理员可以通过发出 API share-server-reset-task-state 来重置 task_state，如下一节所示。

REST API 影响¶

仅供管理员使用，将实现新的 API 方法

share-server-migration-start

迁移 share 服务器

POST /share-servers/{share_server_id}/action

Body

{
  "migration_start": {
    "writable": true,
    "nondisruptive": true,
    "preserve_snapshots": true,
    "host": "host@dummy1#pool2",
    "new_share_network_id": "new_share_network_id"
  }
}

host 包含将迁移 share 服务器到的主机字符串。如果启用了 preserve_metadata、writable、nondisruptive 和 preserve_snapshots 功能，则必须由实现此功能的驱动程序支持。如果不支持其中任何一种功能，则迁移将在驱动程序的兼容性检查中失败。

通过将 writable 设置为 true，预计所有 share 在第一阶段的迁移过程中将保持可写状态，此时通常会发生数据复制。但是，它不能保证在第二阶段保持 writable，对于不支持 nondisruptive 迁移的驱动程序，切换通常会发生。

通过将 nondisruptive 指定为 true，迁移将在整个过程中不会中断客户端，通常意味着导出位置不会被修改，因此不会为新的 share 服务器进行新的网络分配。

如果设置了 preserve_snapshots，预计所有 share 的所有快照将与 share 服务器一起迁移。如果驱动程序不支持，用户需要在继续迁移之前考虑取消管理或删除所有快照。

唯一的可选参数是 ‘new_share_network_id’，可能需要提供它以适应目标网络要求。

如果提供的 share_server_id 不存在，API 将响应 404 Not Found。如果可选参数无效或不存在，API 将响应 400 Bad Request。如果在 Share API 中的初始验证期间，资源正忙或状态无效，API 将响应 409 Conflict。

发生故障时，share 服务器及其所有 share 的状态将被更新为 available，其 task_state 设置为 server_migration_error。

share-server-migration-complete

启动迁移的第二阶段

POST /share-servers/{share_server_id}/action

Body

{"migration_complete": {}}

触发已完成第一阶段的 share 服务器的第二阶段迁移的开始。

如果提供的 share_server_id 不存在，API 将响应 404 Not Found。如果由于不支持的迁移状态而无法执行操作，API 将响应 400 Bad Request。

在迁移的第二阶段发生故障时，share 服务器及其所有 share 的状态将被更新为 error，其 task_state 设置为 server_migration_error。此时，将无法确定 share 服务器及其 share 的状态，并且管理员需要手动修复此问题。

share-server-migration-cancel

尝试取消迁移

POST /share-servers/{share_server_id}/action

Body

{"migration_cancel": {}}

要取消正在进行的迁移，操作必须不在第二阶段，并且驱动程序必须支持此操作。

如果提供的 share_server_id 不存在，API 将响应 404 Not Found。如果由于不支持的迁移状态或驱动程序内的不支持的操作而无法执行操作，API 将响应 400 Bad Request。

在成功取消迁移操作后，share 服务器及其所有 share 的状态将被更新为 available，其 task_state 设置为 server_migration_cancelled。

share-server-migration-get-progress

尝试获取迁移进度

POST /share-servers/{share_server_id}/action

Body

{"migration_get_progress": {}}

响应

{"total_progress": 30}

提供迁移的当前进度百分比值。驱动程序还可以提供额外的 total_progress 信息。

如果提供的 share_server_id 不存在，API 将响应 404 Not Found。如果提供的 share_server_id 未执行迁移，API 将响应 400 Bad Request。

share-server-reset-task-state

重置任务状态字段值

POST /share-servers/{share_server_id}/action

Body

{
  "reset_task_state": {
    "task_state": "migration_error"
   }
}

如果提供的 share_server_id 不存在，API 将响应 404 Not Found。

share-server-migration-check

检查 share 服务器是否可以迁移到目标主机

POST /share-servers/{share_server_id}/action

Body

{
  "migration_check": {
    "writable": true,
    "nondisruptive": true,
    "preserve_snapshots": true,
    "host": "host@dummy1#pool2",
    "new_share_network_id": "new_share_network_id"
  }
}

响应

{
  "compatible": true,
  "requested_capabilities": {
    "writable": true,
    "nondisruptive": true,
    "preserve_snapshots": true,
    "host": "host@dummy1#pool2",
    "new_share_network_id": "new_share_network_id"
  }
  "supported_capabilities": {
    "writable": true,
    "nondisruptive": false,
    "preserve_snapshots": true,
    "new_share_network_id": "new_share_network_id"
    "migration_cancel": true,
    "migration_get_progress" false,
  }
}

检查将 share 服务器迁移到目标主机是否可行。驱动程序将能够检查提供的目标主机是否可以容纳 share 服务器，以及将为该操作提供哪些迁移选项。

通过将 compatible 等于 true 或 false，管理员将知道提供的 host 是否是 share 服务器的可行目标。

迁移选项 writable、nondisruptive 和 preserve_snapshots 显示驱动程序在迁移 share 服务器时是否支持这些选项。如果支持，当前 share 网络或（如果提供）new_share_network_id 也将出现在 supported_capabilities 字段中。

迁移操作 migration_cancel 和 migration_get_progress 也可能取决于驱动程序实现而可用。

驱动程序影响¶

希望支持 share 服务器迁移的厂商必须实现以下接口

choose_share_server_compatible_for_migration：share manager 需要此接口来告知哪个兼容的 share 服务器可以用作迁移操作中的目标；
share_server_migration_check_compatibility：它始终在开始迁移之前被调用，以检查驱动程序是否支持将 share 服务器迁移到所需的目的地，并回答将支持该操作的哪些功能；
share_server_migration_start：调用以启动迁移的第一阶段。该过程应在后端启动并立即返回。
share_server_migration_continue：将被调用以监视 share 服务器迁移的进度。驱动程序将回答第一阶段是否已完成或在发生故障时引发异常。
share_server_migration_complete：启动迁移的第二阶段，以通过从源端切换访问并提供通过目标端访问来完成操作。
share_server_migration_cancel：如果驱动程序支持取消正在进行的迁移操作，驱动程序将实现此调用。对于已经开始第二阶段的 share 服务器，将无法取消迁移；
share_server_migration_get_progress：驱动程序将实现此调用以提供迁移的总进度。

正如 share 迁移方法中实现的那样，将在开始迁移之前调用驱动程序以检查与目标后端的兼容性。在此验证期间，驱动程序能够返回在将 share 服务器迁移到提供的目标时支持的功能，例如保持可写、保留快照等。

之后，将执行 share_server_migration_start 并要求驱动程序启动迁移的第一阶段，该阶段应在后端异步回答。Manila 将重用 share 迁移中的相同周期性任务，以持续检查第一阶段是否已通过调用驱动程序接口 share_server_migration_continue 完成。

最终，当调用 `share_server_migration_complete` 时，驱动程序需要执行最后一步来完成共享服务器迁移。此时，根据驱动程序的功能，对源共享服务器共享的访问可能会中断，并转移到新的目标服务器。

安全影响¶

无

通知影响¶

无

其他最终用户影响¶

在迁移过程中，用户将无法对属于正在迁移的共享服务器的所有共享执行任何管理操作。根据驱动程序的功能，用户可能还会失去对这些共享的写入访问权限。

性能影响¶

预计实施此功能不会对性能产生影响。但是，根据放置在共享服务器中的共享数量，由于共享服务器迁移触发的数据库操作数量，以及对所有受影响资源（共享、快照、访问权限等）进行健全性检查和状态更新，其他操作可能会受到影响。

其他部署者影响¶

实现共享服务器迁移的驱动程序可能需要从其他后端检索配置，以便访问它并提供复制所有数据的方式。管理员需要在所有共享服务实例中保持这些文件最新。

开发人员影响¶

无。

实现¶

负责人¶

主要负责人: dviroel

工作项¶

实现主要补丁，包含
- 用于共享服务器迁移的新 API 方法；
- 用于启动共享服务器迁移的新调度器调用；
- 共享管理器实现用于共享服务器迁移；
- 共享服务器模型的数据库更新；
- 用于迁移共享服务器的新驱动程序接口。
使用新的共享服务器 CLI 命令更新 python-manilaclient。
用于测试
- 改进并实现容器和虚拟驱动程序，以支持跨不同后端进行共享服务器迁移。
- manila-tempest-plugin 中的新功能测试。
文档更新。