Share server 迁移

Share server 迁移是一种功能，允许管理员将 share server 及其所有 share 和快照迁移到新的目标位置。

与 share 迁移一样，share server 迁移也采用了两阶段方法，可以控制完成操作的合适时机，通常会导致客户端中断。

迁移 share server 的过程涉及对 share server 的各种操作，但可以通过调用两个主要操作来实现：“start”和“complete”。您需要从“start”操作开始，并等待服务完成迁移的第一阶段，然后才能调用“complete”操作。当 share server 正在进行第一阶段时，可以选择“cancel”它，或者获取进度报告。

提供了一个新的“migration check”操作，用于协助进行迁移前的阶段，通过验证目标主机是否可以完成迁移，并提供驱动程序支持的兼容功能输出。

Share server 迁移由 share 驱动程序驱动，这意味着源和目标后端都必须支持此功能，并且驱动程序必须以有效的方式提供此操作。

Server 迁移工作流程

在实际开始迁移之前，可以使用 migration_check 操作来验证目标主机和请求的功能是否受驱动程序支持。如果答案是 compatible 等于 True，则可以继续进行迁移过程，否则您需要识别冲突的参数，或者在更复杂的情况下，直接在 manila 日志中搜索消息。可用的功能包括：writable、nondisruptive、preserve_snapshots 和 new_share_network_id，这些功能在 Migration check 和 migration start 参数 中详细说明。

迁移过程通过调用 migration_start 操作来启动给定的 share server。此操作将启动迁移的第一阶段，将所有数据从源复制到目标，包括所有 share、它们的访问规则，甚至如果控制目标主机的驱动程序支持快照，也包括快照。

对于所有正在进行的迁移，您可以选择使用 migration_get_progress 操作请求 share server 迁移的当前状态，以检索数据复制的总体进度及其当前任务状态。如果驱动程序支持，您还可以通过发出 migration_cancel 并等待所有状态变为 active 和 available 来取消此操作。

在完成数据复制后，第一阶段完成，然后可以启动下一个操作 migration_complete，以完成迁移。 migration_complete 操作通常会中断客户端访问，因为 share 的导出位置将更改。新的导出位置将从在新目标处配置的新的 share server 派生，该 share server 使用不同的网络分配。

一个新的字段 task_state 可用于 share server 模型中，以帮助跟踪在此过程中执行的操作。下表显示了每个阶段的预期 task_state，以及它们的执行顺序和后端正在执行的操作的简要说明。

Share server 迁移状态 - 第 1 阶段

序列

task_state

描述

1

migration_starting

所有初始验证都已通过，所有 share 和快照在迁移结束之前都无法修改。

2

migration_in_progress

目标主机已启动迁移过程。如果驱动程序不支持保持 writable，则所有访问规则都将被修改为只读。

3

migration_driver_starting

已调用驱动程序以启动 share server 的迁移过程。Manila 将等待驱动程序的响应。

4

migration_driver_in_progress

驱动程序接受了请求并开始将数据复制到新的 share server。它将保持此状态直到数据复制完成。

5

migration_driver_phase1_done

驱动程序已完成数据复制，并准备好完成迁移。

除了 share server 迁移进度（百分比）和当前任务状态外，API 还提供目标 share server ID。或者，您可以通过查询 share server 以查找设置为正在迁移的 share server ID 的 source_share_server_id 来检查目标 share server ID。在整个迁移过程中，源 share server 将保持 server_migrating 状态，而目标 share server 将保持 server_migrating_to 状态。

如果在迁移的第一阶段发生错误，源 share server 的状态将恢复为 active，而目标服务器的状态将设置为 error。两个 share server 都会将其 task_state 更新为 migration_error。所有 share 和快照都更新为 available，任何 read-only 规则都将重置为允许写入 share。

Share server 迁移状态 - 第 2 阶段

序列

task_state

描述

1

migration_completing

目标主机已启动处理操作，并且调用驱动程序以完成 share server 迁移。

2

migration_success

迁移已成功完成。所有 share 和快照都 available。

完成 share server 迁移后，所有 share 和快照的状态都将更新为 available。源 share server 状态设置为 inactive，目标 share server 设置为 active。

如果在迁移的第二阶段发生错误，源和目标 share server 都会将其状态更新为 error，以及它们的 share 和快照，因为无法推断它们是否正常工作以及迁移的当前状态。在这种情况下，您需要手动验证所有 share server 资源的健康状况并手动修复其状态。两个 share server 都会将其 task_state 设置为 migration_error。

Share server 迁移状态 - 迁移取消

序列

task_state

描述

1

migration_cancel_in_progress

目标主机已启动取消过程。它将保持此状态，直到驱动程序完成所有正在进行的任务。

2

migration_cancelled

迁移已成功取消。

如果在迁移取消操作期间发生错误，源 share server 的状态将恢复为 active，而目标服务器的状态将更新为 error。两个 share server 都会将其 task_state 设置为 migration_error。所有 share 和快照的状态都更新为 available。

使用 share server 迁移 CLI

与 share server 迁移 API 交互的可用命令如下

  • migration_check：调用 migration check 操作以验证提供的目标主机是否与请求的操作及其参数兼容。输出显示目标主机是否兼容以及后端支持的迁移功能。

     $ manila share-server-migration-check f3089d4f-89e8-4730-b6e6-7cab553df071 stack@dummy2 --nondisruptive False --writable True --preserve_snapshots True

+------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Property               | Value                                                                                                                                                                                        |
+------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| compatible             | True                                                                                                                                                                                         |
| requested_capabilities | {'writable': 'True', 'nondisruptive': 'False', 'preserve_snapshots': 'True', 'share_network_id': None, 'host': 'stack@dummy2'}                                                               |
| supported_capabilities | {'writable': True, 'nondisruptive': False, 'preserve_snapshots': True, 'share_network_id': 'ac8e103f-c21a-4442-bddc-fdadee093099', 'migration_cancel': True, 'migration_get_progress': True} |
+------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

    在 supported_capabilities 中的 share_network_id 属性将对应于提供的 --new_share_network 选项的值，否则它将与源 share 网络相同。在输出中，可以识别目标主机是否支持 migration_cancel 和 migration_get_progress 操作，然后再启动迁移。请求参数与 migration_check 和 migration_start 操作相同，并在下一节中详细说明。

    注意

    后端可能会使用此操作来执行许多其他验证，例如存储兼容性、可用空间检查、share-type extra-specs 验证等。 compatible 等于 False 的答案可能不包含实际的冲突。您必须检查 manila-share 日志以获取更多详细信息。

  • migration_start：启动到提供的目标主机的 share server 迁移。此命令启动迁移的第一阶段，这是一个异步操作，可能需要很长时间才能完成，具体取决于 share server 的大小以及存储在复制所有数据方面的效率。

    $ manila share-server-migration-start f3089d4f-89e8-4730-b6e6-7cab553df071 stack@dummy2 --nondisruptive False --writable True --preserve_snapshots True

    参数说明在下一节中详细介绍。

    注意

    此操作不支持迁移具有副本或属于 share 组的 share server。

    注意

    可以使用 migration-get-progress 命令检索当前迁移状态和进度。

    注意

    此命令没有输出。

  • migration_complete：完成已经完成第一阶段的迁移。此操作无法取消，并且可能导致在所有 share 迁移到新的 share server 后中断客户端访问。

     $ manila share-server-migration-complete f3089d4f-89e8-4730-b6e6-7cab553df071

+-----------------------------+--------------------------------------+
| Property                    | Value                                |
+-----------------------------+--------------------------------------+
| destination_share_server_id | f3fb808f-c2a4-4caa-9805-7caaf55c0522 |
+-----------------------------+--------------------------------------+

  • migration_cancel：取消正在进行的 share server 迁移。此操作只能在迁移仍在迁移的第一阶段时启动。

    $ manila share-server-migration-cancel f3089d4f-89e8-4730-b6e6-7cab553df071

    注意

    此命令没有输出。

  • migration_get_progress：获取 share server 迁移的当前进度信息。

     $ manila share-server-migration-get-progress f3089d4f-89e8-4730-b6e6-7cab553df071

+-----------------------------+--------------------------------------+
| Property                    | Value                                |
+-----------------------------+--------------------------------------+
| total_progress              | 50                                   |
| task_state                  | migration_driver_in_progress         |
| destination_share_server_id | f3fb808f-c2a4-4caa-9805-7caaf55c0522 |
+-----------------------------+--------------------------------------+

Migration check 和 migration start 参数

Share server migration_check 和 migration_start 操作具有特定的参数，这些参数的语义如下。其中，只有 new_share_network 是可选参数。

  • share_server_id：将要迁移的 share server 的 ID。

  • destination_host：share server 应该迁移到的目标主机，格式为 host@backend。

  • preserve_snapshots：强制执行快照保留对于请求的迁移是强制性的。如果目标主机不支持它，则操作将被拒绝。如果此参数设置为 False，则驱动程序支持的功能将定义是否保留快照。

    注意

    如果驱动程序不支持保留快照，但至少有一个 share 具有快照，则操作将失败，您需要手动删除剩余的快照才能继续。

  • writable：强制指定请求的迁移操作是否应保持源共享服务器可写。如果目标主机不支持此功能，则操作将被拒绝。如果将此参数设置为 False，则驱动程序支持的功能将定义所有共享是否将保持可写状态。

  • nondisruptive：强制指定迁移过程中是否应保持客户端连接。如果目标主机不支持此功能，则操作将被拒绝。如果将此参数设置为 False，则驱动程序支持的功能将定义所有客户端是否将保持连接状态。

为了恰当地将共享服务器迁移到不同的主机，可能需要更改新的共享服务器要使用的目标共享网络。在这种情况下，可以使用以下可选参数提供新的共享网络：

  • new_share_network_id：指定在设置新的共享服务器时应使用的共享网络的 ID。

    注意

    由于将根据目标主机的可用区自动选择，因此无法选择目标共享网络子网。如果新的共享网络在目标主机的可用区中没有共享网络子网，或者没有默认子网，则操作将失败。

配置

为了使共享服务器迁移正常工作，所有 manila-share 节点上的 manila 配置文件中必须存在兼容的后端配置节。

某些驱动程序可能会提供一些特定于驱动程序的配置选项，可以更改这些选项以适应特定的工作负载。有关更多详细信息，请查看 共享驱动程序 文档。

重要说明

  • 一旦共享服务器的迁移开始，用户将看到所有相关资源的 status 状态更改为 server_migrating，这将阻止任何其他共享操作，例如添加或删除访问规则、创建或删除快照、调整大小等。

  • 由于这是一个驱动程序辅助的迁移，因此无法保证在迁移失败后会清理目标共享服务器。因此，如果发生任何故障，目标共享服务器将始终更新为 error。在成功迁移后，对源共享服务器也做出了相同的假设，manila 会将其状态更新为 inactive，以避免将其用于新的共享。

  • 如果在迁移的第二阶段发生故障，您需要手动识别源共享服务器的当前状态，以便将其恢复为 active。如果共享服务器及其所有资源仍然正常，您需要使用 reset_status API 为每个受影响的资源重置状态。

  • 迁移过程中的每个步骤都保存在共享服务器模型中的 task_state 字段中。如果由于某种原因，状态未在发生故障后设置为 migration_error，则需要使用 reset_task_state API 重置它，以解锁新的共享操作。

  • 发生故障后，目标共享服务器的状态将被更新为 error，并将继续指向原始源共享服务器。这可以帮助您在并行运行多个迁移时识别失败的共享服务器。