Share 迁移¶
Share 迁移是指在不同的存储池之间迁移 share 的功能。
用例¶
作为管理员,您可能出于多种原因希望将 share 从一个存储池迁移到另一个存储池。例如
维护或疏散
为了硬件或软件升级而疏散后端
疏散正在发生故障的后端
疏散被标记为生命周期结束的后端
优化
碎片整理后端,使其为空闲并可以离线以节省功耗
重新平衡后端,以最大化可用性能
将数据和计算移至更靠近的位置,以减少网络利用率并降低延迟或增加带宽
迁移 shares
从旧硬件代迁移到较新的代
从一个供应商迁移到另一个供应商
迁移工作流¶
通常,在不同的存储池之间移动 shares 是一项破坏性操作,当源停止存在时会断开现有客户端的连接。因此,share 迁移采用两阶段方法实现,允许管理员控制中断的时间。第一阶段执行数据复制,同时用户仍可以访问 share。复制完成后,可以触发第二阶段执行切换,其中可能包括最后一次同步和删除源,通常需要用户重新连接才能继续访问 share。
为了迁移 share,可以使用两种可能的机制中的一种,它们提供不同的功能并影响数据复制阶段的用户访问方式以及切换阶段的断开连接方式。这两种机制是
驱动程序辅助迁移:此机制旨在利用驱动程序优化,在同一存储供应商的池之间迁移 shares。此机制允许在源保持可写状态的同时无破坏性地迁移 shares,从而保留所有文件系统元数据和快照。迁移工作负载在存储后端执行。
主机辅助迁移:此机制旨在以一种不区分的方式在两个不同的池之间迁移 shares,无论存储供应商如何。此机制的实现不提供驱动程序辅助迁移中找到的相同属性。在主机辅助迁移中,源保持可读状态,必须在开始迁移之前删除快照,可能会丢失文件系统元数据,并且客户端将在迁移结束时断开连接。迁移工作负载由数据服务执行,该服务是 manila 用于密集数据操作的专用服务。
在开始迁移时,首先尝试驱动程序辅助迁移。如果共享文件系统服务检测到无法执行驱动程序辅助迁移,则它将继续尝试主机辅助迁移。
使用迁移 API¶
与 share 迁移 API 交互的命令是
migration_start:在保留对 share 的访问权限的同时启动迁移。迁移暂停并等待migration_complete调用,直到它复制完所有数据并准备关闭源 share。$ manila migration-start share_1 ubuntu@generic2#GENERIC2 --writable False --preserve-snapshots False --preserve-metadata False --nondisruptive False
注意
此命令没有输出。
migration_complete:完成迁移,删除源 share,并将目标 share 实例设置为available。$ manila migration-complete share_1
注意
此命令没有输出。
migration_get_progress:获取 share 的迁移进度信息。$ manila migration-get-progress share_1 +----------------+--------------------------+ | Property | Value | +----------------+--------------------------+ | task_state | data_copying_in_progress | | total_progress | 37 | +----------------+--------------------------+
migration_cancel:取消 share 的正在进行的迁移。$ manila migration-cancel share_1
注意
此命令没有输出。
参数¶
要启动迁移,管理员应指定几个参数。其中,有两个参数对于迁移至关重要。
share:将要迁移的 share。destination_pool:应迁移 share 的目标池,格式为 host@backend#pool。
其他一些参数,此处称为 driver-assisted parameters,必须在 migration_start API 中指定。它们是
preserve_metadata:是否应强制保留此迁移的文件系统元数据。preserve_snapshots:是否应强制保留此迁移的快照。writable:是否应强制源 share 保持可写状态以进行此迁移。nondisruptive:是否应强制在迁移过程中保持客户端连接。
将上述任何布尔参数指定为 True 将禁止主机辅助迁移。
为了适当将 share 移动到不同的存储池,可能需要更改 share 类型、share 网络或可用区等一个或多个 share 属性。为此,请使用可选参数
new_share_type_id:指定应在迁移的 share 中设置的 share 类型的 ID。new_share_network_id:指定应在迁移的 share 中设置的 share 网络的 ID。
如果不想尝试驱动程序辅助迁移,可以提供可选参数
force_host_assisted_migration:是否应跳过驱动程序辅助迁移尝试。如果将此选项设置为True,则必须将所有驱动程序辅助选项设置为False。
配置¶
为了使 share 迁移在云中工作,需要满足几个配置要求
对于驱动程序辅助迁移:所有 manila-share 节点的文件 manila.conf 中必须存在所有后端 stanza 的配置。此外,运行 manila-share 服务及其各自存储后端之间的网络连接是必需的。
对于主机辅助迁移:必须在连接到云管理员网络的节点上安装和配置数据服务 (manila-data)。参与迁移的源后端和目标后端的相关驱动程序能够提供可以从管理员网络访问的 shares。如果驱动程序支持 admin_only 导出位置,则可以轻松实现这一点,否则管理员需要设置连接方式。
为了使数据服务挂载源和目标实例,它必须使用 manila share 访问 API 来授予访问权限以挂载实例。访问规则类型因 share 协议而异,因此有几个配置选项来为每种类型设置访问值
data_node_access_ips:对于基于 IP 的访问类型,提供运行数据服务的节点的一个或多个管理员网络 IP 地址。对于 NFS shares,驱动程序应始终添加具有“no_root_squash”属性的规则。data_node_access_cert:对于基于证书的访问类型,提供授予数据服务访问权限的证书名称的值。data_node_access_admin_user:对于基于用户的访问类型,提供授予访问权限和 share 中文件管理员权限的用户名值。data_node_mount_options:提供协议名称到各自挂载选项的映射值。数据服务使用挂载命令模板,默认情况下,该模板具有一个专门的字段用于插入挂载选项参数。此配置选项的默认值已包含 CIFS shares 的用户名和密码参数以及 NFS shares 的 NFS v3 强制参数。mount_tmp_location:提供一个字符串值,表示应临时挂载迁移中使用的 share 实例的路径。默认值为/tmp/。check_hash:此布尔配置选项值确定是否应验证复制的迁移中所有文件的哈希值。设置此选项会增加迁移文件所需的时间,建议用于超可靠的系统。默认情况下禁用。
上述配置选项仅适用于数据服务,应在 manila.conf 配置文件的 DEFAULT 组中定义。此外,数据服务节点必须预安装所有与协议相关的库,才能运行每种协议的挂载命令。
您可能需要更改某些驱动程序特定的配置选项,以使其从默认值更改为与特定驱动程序一起使用。如果是这样,它们必须在 manila.conf 中的驱动程序配置 stanza 下设置。下面详细描述了每个配置选项
migration_ignore_files:提供一个列表作为值,其中包含在特定驱动程序的迁移过程中要忽略的文件或文件夹的名称。默认值是一个仅包含lost+found文件夹的列表。share_mount_template:提供一个字符串,定义特定驱动程序的挂载命令的模板。模板应包含以下条目以供格式化proto:share 协议。由数据服务自动格式化。
options:挂载选项,由数据服务根据 data_node_mount_options 配置选项进行格式化。
export:share 的导出路径。由数据服务自动格式化,并使用 share 的
admin_only导出位置。path:挂载 share 的路径。由数据服务自动格式化,并根据 mount_tmp_location 配置选项进行格式化。
此配置选项的默认值为
mount -vt %(proto)s %(options)s %(export)s %(path)s.
share_unmount_template:提供一个字符串值,定义特定驱动程序的卸载命令的模板。模板应包含 share 挂载的位置的路径,根据mount_tmp_location配置选项,由数据服务自动格式化。此配置选项的默认值为umount -v %(path)s
protocol_access_mapping:提供访问规则类型到受支持协议的映射值。默认值指定 IP 和基于用户的访问类型映射到 NFS 和 CIFS,这是 manila 支持的组合。如果某个驱动程序对 IP 或基于用户的访问类型使用不同的协议,或者未包含在默认映射中,则应在此配置选项中指定它。
其他说明¶
在迁移完成后,无需手动添加任何先前存在的访问规则,它们将在目标上保留。
一旦 share 迁移开始,用户将看到状态
migrating,这将阻止其他 share 操作,例如添加或删除访问规则、创建或删除快照、调整大小等。目标 share 实例的导出位置,尽管它可能在主机辅助迁移的开始时就存在,但不可见且无法访问,因为无法添加访问规则。
在主机辅助迁移期间,将添加一个授予数据服务访问权限的访问规则,并通过查询
access-listAPI 来显示。不应篡改此访问规则,否则会导致迁移失败。分配的资源在迁移失败时会自动清理,除非此失败发生在驱动程序辅助迁移的第二阶段。迁移的每个步骤都保存到 Share 模型中的字段
task_state中。如果由于某种原因,状态未在失败期间设置为migration_error,则需要使用reset-task-stateAPI 重置它。建议运行数据服务的节点安全可靠,因为它将以最高权限挂载 shares,暂时将用户数据暴露给可以访问此节点的人员。
两种迁移机制受服务重启的影响不同
如果执行主机辅助迁移,则在执行复制时(
task_state字段的值以data_copying_开头)可以重启所有服务,但不能重启 manila-data 服务。在主机辅助迁移的其他步骤中,不应重启源和目标 manila-share 服务。如果执行驱动程序辅助迁移,如果
task_state是migration_driver_in_progress,则迁移受驱动程序重启的影响最小,而复制是在后端完成的。否则,不应重启源和目标 manila-share 服务。