通过

将 StorSimple 8100 和 8600 迁移到 Azure 文件同步

  • 项目

StorSimple 8000 系列包含 8100 或 8600 本地物理设备及其云服务组件。 此迁移指南还介绍了 StorSimple 8010 和 8020 虚拟设备。 可以选择使用 Azure 文件同步将数据从这些设备中的任一设备迁移到 Azure 文件共享。Azure 文件同步是替代 StorSimple 本地功能的默认和长期战略性 Azure 服务。 本文提供成功迁移到 Azure 文件同步所需的背景知识和迁移步骤。

备注

StorSimple 服务（包括适用于 8000 和 1200 系列的 StorSimple 设备管理器以及 StorSimple 数据管理器）已终止支持。 对 StorSimple 的支持终止已在 2019 年发布在 Microsoft 生命周期策略和 Azure 通讯页上。 通过电子邮件发送了附加通知，并将其发布到了 Azure 门户和 StorSimple 概述中。 要获得更多详细信息，请联系 Microsoft 支持部门。

迁移概述 - 单击以播放！

此视频概述了：

  • Azure 文件
  • Azure 文件同步
  • StorSimple & Azure 文件存储的比较
  • StorSimple 数据管理器迁移工具和过程概述

阶段 1 - 准备迁移

此部分包含开始从 StorSimple 卷迁移到 Azure 文件共享时应执行的步骤。

准备迁移 - 单击以播放！

此视频涵盖：

  • 选择存储层
  • 选择存储冗余选项
  • 选择 direct-share-access 与 Azure 文件同步
  • StorSimple 服务数据加密密钥和序列号
  • StorSimple 卷备份迁移
  • 将 StorSimple 卷和共享映射到 Azure 文件共享
  • 在 Azure 文件共享中对共享进行分组
  • 映射注意事项
  • 迁移计划工作表
  • 命名空间映射电子表格

库存

开始规划迁移时，请首先确定需要迁移的所有 StorSimple 设备和卷。 之后，就可以决定最佳迁移路径。

  • StorSimple 物理设备（8000 系列）使用此迁移指南。
  • StorSimple 虚拟设备（1200 系列）使用其他迁移指南。

迁移成本摘要

可以免费通过 StorSimple 数据管理器资源中的迁移作业从 StorSimple 卷迁移到 Azure 文件共享。 迁移期间和之后可能会产生其他成本：

  • 网络出口： 你的 StorSimple 文件位于特定 Azure 区域内的存储帐户中。 如果预配的 Azure 文件共享将迁移到同一 Azure 区域的存储帐户中，则不会产生流出费用。 但是，如果在此迁移过程中将文件移动到其他区域中的存储帐户，则会产生流出费用。
  • Azure 文件共享事务： 如果将文件复制到 Azure 文件共享中（在迁移过程中或过程外进行），则在写入文件和元数据时，会产生事务成本。 最佳做法是在迁移过程中在事务优化层上启动 Azure 文件共享。 迁移完成后，切换到所需的层。 本文中所述的阶段会在适当的时机阐述这一点。
  • 更改 Azure 文件共享层： 更改 Azure 文件共享的层会产生事务成本。 大多数情况下，按照上一要点中包含的建议进行操作会更经济高效。
  • 存储成本：当此迁移开始将文件复制到 Azure 文件共享时，将消耗存储并对其计费。 迁移的备份成为 Azure 文件共享快照。 文件共享快照仅耗用与其包含的差异相对应的存储容量。
  • StorSimple：在你取消预配 StorSimple 设备和存储帐户之前，将会持续产生存储、备份和设备的 StorSimple 成本。

Direct-share-access 与 Azure 文件同步

可以通过 Azure 文件共享来构建文件服务部署，这是一种全新的方式。 Azure 文件共享是云中的一个 SMB 共享，你可以对其进行设置，让用户使用可以在本机使用的、熟悉的 Kerberos 身份验证和现有的 NTFS 权限（文件和文件夹 ACL）直接通过 SMB 协议进行访问。 详细了解如何对 Azure 文件共享进行基于标识的访问。

直接访问的替代方法是 Azure 文件同步。Azure 文件同步直接模拟 StorSimple 在本地缓存常用文件的功能。

Azure 文件同步是一种 Microsoft 云服务，基于两个主要组件：

  • 文件同步和云分层，用于在任何 Windows Server 上创建高性能的访问缓存。
  • 作为 Azure 中的原生存储的文件共享，可通过多个协议（例如 SMB 和文件 REST）访问。

Azure 文件共享保留重要的文件保真特性（如属性、权限和时间戳）。 使用 Azure 文件共享时，应用程序或服务不再需要解释存储在云中的文件和文件夹。 可以通过熟悉的协议和客户端以原生方式访问它们。 Azure 文件共享允许你将常规用途的文件服务器数据和应用程序数据存储在云中。

本文重点介绍迁移步骤。 如果要在迁移之前详细了解 Azure 文件同步，请参阅以下文章：

StorSimple 服务数据加密密钥

当你首次设置 StorSimple 设备时，它生成了一个“服务数据加密密钥”，并指示你安全地存储密钥。 此密钥用于对 StorSimple 设备将你的文件存储到的关联 Azure 存储帐户中的所有数据进行加密。

需要提供服务数据加密密钥才能成功进行迁移。 从记录中检索此密钥，清单中的每个设备都有自己的一个密钥。

如果在记录中找不到密钥，则可以从设备中生成一个新密钥。 每个设备都有唯一的加密密钥。

更改服务数据加密密钥

服务数据加密密钥用于加密机密客户数据，例如从 StorSimple Manager 服务发送到 StorSimple 设备的存储帐户凭据。 如果 IT 组织具有有关存储设备的密钥轮换策略，将需要定期更改这些密钥。 密钥更改过程可能会稍有不同，具体取决于 StorSimple Manager 服务管理的一个设备还是多个设备。 有关详细信息，请转到 StorSimple 安全性和数据保护。

更改服务数据加密密钥过程有 3 个步骤：

  1. 使用适用于 Azure 资源管理器的 Windows PowerShell 脚本，授权某个设备来更改服务数据加密密钥。
  2. 使用 StorSimple 的 Windows PowerShell，启动服务数据加密密钥更改。
  3. 如果有多个 StorSimple 设备，请更新其他设备上的服务数据加密密钥。

步骤 1：使用 Windows PowerShell 脚本授权某个设备来更改服务数据加密密钥

通常情况下，设备管理员会请求服务管理员授权某个设备来更改服务数据加密密钥。 然后，服务管理员会授权该设备来更改密钥。

此步骤是使用基于 Azure 资源管理器的脚本执行的。 服务管理员可以选择有资格接受授权的一个设备。 然后，授权该设备来启动服务数据加密密钥更改过程。

有关使用脚本的详细信息，请转到 Authorize-ServiceEncryptionRollover.ps1

可以授权哪些设备来更改服务数据加密密钥？

设备必须满足以下条件，才能接受授权以启动服务数据加密密钥更改：

  • 设备必须联机才有资格接受服务数据加密密钥更改授权。
  • 如果密钥更改尚未启动，可以在 30 分钟后再次授权同一台设备。
  • 如果先前授权的设备尚未启动密钥更改，可以授权其他设备。 新设备获得授权之后，旧设备不能启动更改。
  • 当正在进行服务数据加密密钥的滚动更新时，将无法授权设备。
  • 可以在以下情况下授权设备：某些使用服务注册的设备已滚动更新，但其他设备却没有。

步骤 2：使用 Windows PowerShell for StorSimple 启动服务数据加密密钥更改

在 Windows PowerShell for StorSimple 界面中对授权的 StorSimple 设备执行此步骤。

注意

除非已完成密钥的滚动更新，否则无法在 StorSimple Manager 服务的 Azure 门户中执行任何操作。

如果使用设备串行控制台连接到 Windows PowerShell 界面，请执行以下步骤。

启动服务数据加密密钥更改

  1. 选择选项 1 以使用完全访问权限登录。

  2. 在命令提示符处，键入：

    Invoke-HcsmServiceDataEncryptionKeyChange

  3. cmdlet 成功完成后，将收到新的服务数据加密密钥。 复制并保存此密钥，以供在此过程的步骤 3 中使用。 此密钥用于更新已使用 StorSimple Manager 服务注册的所有剩余设备。

    注意

    此过程必须在授权 StorSimple 设备后的四小时内启动。

    然后，此新密钥将发送到该服务，以推送到所有已使用该服务注册的设备。 之后，服务仪表板上会显示警报。 该服务将禁用已注册设备上的所有操作，随后设备管理员将需要更新其他设备上的服务数据加密密钥。 但是，不会中断 I/O（将数据发送到云的主机）。

    如果已有一台设备注册到服务，滚动更新过程现已完成，可以跳过下一步。 如果已有多台设备注册到服务，请继续执行步骤 3。

步骤 3：在其他 StorSimple 设备上更新服务数据加密密钥

如果已有多台设备注册到 StorSimple Manager 服务，则必须在 StorSimple 设备的 Windows PowerShell 界面中执行这些步骤。 必须使用在步骤 2 中获取的密钥来更新注册到 StorSimple Manager 服务的所有剩余 StorSimple 设备。

执行以下步骤，更新设备上的服务数据加密。

在物理设备上更新服务数据加密密钥

  1. 使用 Windows PowerShell for StorSimple 连接到控制台。 选择选项 1 以使用完全访问权限登录。
  2. 在命令提示符处，键入：Invoke-HcsmServiceDataEncryptionKeyChange – ServiceDataEncryptionKey
  3. 提供在步骤 2：使用 Windows PowerShell for StorSimple 启动服务数据加密密钥更改中所获取的服务数据加密密钥。

更新所有 8010/8020 云设备上的服务数据加密密钥

  1. 下载和安装 Update-CloudApplianceServiceEncryptionKey.ps1 PowerShell 脚本。
  2. 打开 PowerShell 并在命令提示符下键入：Update-CloudApplianceServiceEncryptionKey.ps1 -SubscriptionId [subscription] -TenantId [tenantid] -ResourceGroupName [resource group] -ManagerName [device manager]

此脚本将确保在设备管理器下的所有 8010/8020 云设备上设置服务数据加密密钥。

注意

在决定连接到 StorSimple 设备的方式时，请考虑以下方面：

  • 通过 HTTPS 会话进行连接是最安全的选项（建议使用）。
  • 直接连接到设备串行控制台是安全的，但通过网络交换机连接到串行控制台并不安全。
  • HTTP 会话连接是一个选项，但未进行加密。 不建议你使用 HTTP 会话连接，除非是在封闭的受信任网络中使用。

已知限制

在开始之前，应考虑 StorSimple 数据管理器和 Azure 文件共享的一些限制，因为它们可能会阻止迁移：

  • 仅支持 StorSimple 设备的 NTFS 卷。 不支持 ReFS 卷。
  • 不支持放置在 Windows Server 动态磁盘上的任何卷。
  • 该服务不适用于经过 BitLocker 加密或启用了重复数据删除的卷。
  • 无法迁移损坏的 StorSimple 备份。
  • 在存储 StorSimple 备份的源存储帐户上和保存 Azure 文件共享的目标存储帐户上都不能启用专用网络选项，例如防火墙或仅限专用终结点的通信。

文件保真度

如果已知限制中没有任何限制阻止迁移，Azure 文件共享中可以存储的内容仍然存在限制。

文件保真度是指构成文件的众多属性、时间戳和数据。 在迁移中，文件保真度衡量源（StorSimple 卷）上的信息可以转换（迁移）到目标 Azure 文件共享的程度。

Azure 文件存储支持NTFS 文件属性的子集。 将迁移 Windows ACL、通用元数据和一些时间戳。

以下项不会阻止迁移，但在迁移过程中会导致每个项的问题：

  • 时间戳：不会设置文件更改时间。 目前，它通过 REST 协议实现只读。 不会移动文件上的上次访问时间戳，因为它不是存储在 Azure 文件共享中的文件的受支持属性。
  • 备用数据流不能存储在 Azure 文件共享中。 将复制保存备用数据流的文件，但备用数据流将在此过程中从文件中去除。
  • 迁移期间会跳过符号链接、硬链接、接合和重新分析点。 迁移复制日志会列出每个跳过的项和原因。
  • EFS 加密文件无法复制。 复制日志显示无法复制的项并显示“访问被拒绝”消息。
  • 将跳过损坏的文件。 复制日志可能会为 StorSimple 磁盘上损坏的每个项列出不同的错误：“由于严重的设备硬件错误，请求失败”、“文件或目录已损坏或不可读”或“访问控制列表(ACL)结构无效”。
  • 将跳过大于 4 TiB 的单个文件。
  • 文件路径长度必须等于或少于 2048 个字符。 将跳过路径较长的文件和文件夹。
  • 将跳过重分析点。 迁移引擎无法解析任何 Microsoft 重复数据删除/SIS 重分析点或第三方的重解析点，并会阻止迁移受影响的文件和文件夹。

本文末尾的故障排除部分详细介绍了项目级别和迁移作业级别错误代码，可能还会介绍缓解方案。

StorSimple 卷备份

StorSimple 在卷级别提供差异备份。 Azure 文件共享也具有这种功能（称为共享快照）。

迁移作业只能移动备份，而不能移动实时卷中的数据。 因此，最新备份与实时数据最接近，因此应始终是要在迁移中移动的备份列表的一部分。

决定是否需要在迁移期间移动任何较旧的备份。 最佳做法是使此列表尽可能小，从而使迁移作业的完成速度更快。

若要标识必须迁移的关键备份，请创建备份策略的核对清单。 例如：

  • 最新备份。
  • 每月备份一次，连续备份 12 个月。
  • 每年备份一次，连续备份三年。

在创建迁移作业时，可以使用此列表来确定必须迁移的具体 StorSimple 卷备份，以满足要求。

最好先挂起所有 StorSimple 备份保留策略，然后再选择用于迁移的备份。 迁移备份可能需要花费几天或几周的时间。 StorSimple 提供用于删除备份的备份保留策略。 选择进行迁移的备份可能会在迁移之前被删除。

注意

不支持选择超过 50 个 StorSimple 卷备份。

将现有 StorSimple 卷映射到 Azure 文件共享

在此步骤中，你将决定需要多少个 Azure 文件共享。 单个 Windows Server 实例（或群集）可以同步最多 30 个 Azure 文件共享。

卷上可能有更多文件夹当前作为 SMB 共享在本地共享给用户和应用。 描述此场景的最简单方法是设想 1:1 映射到 Azure 文件共享的本地共享。 如果共享数目够小，即单个 Windows Server 实例低于 30 个时，建议使用 1:1 映射。

如果共享数目超过 30 个，通常不需要将本地共享 1:1 映射到 Azure 文件共享。 请考虑以下选项。

共享分组

例如，如果人力资源 (HR) 部门有 15 个共享，则可以考虑将所有 HR 数据存储在一个 Azure 文件共享中。 将多个本地共享存储在一个 Azure 文件共享中不会阻止你在本地 Windows Server 实例上创建常规的 15 个 SMB 共享。 这只是意味着将这 15 个共享的根文件夹组织为公用文件夹下的子文件夹。 然后将此公用文件夹同步到 Azure 文件共享。 这样，这组本地共享便只需要云中的单个 Azure 文件共享。

卷同步

Azure 文件同步支持将卷的根同步到 Azure 文件共享。 如果同步卷根，则所有子文件夹和文件都会转到相同的 Azure 文件共享。

同步卷的根并非总是最佳选项。 同步多个位置有很多好处。 例如，这样做可帮助降低每个同步范围的项目数。 我们测试了 Azure 文件共享和 Azure 文件同步，每个共享有 1 亿个项目（文件和文件夹）。 但是，在单个共享中，最好试着将数目控制在 2000 万或 3000 万以下。 使用较少数量的项目设置 Azure 文件同步不只是对文件同步有利。在下面这些场景中，项目数量较少的优势也是显而易见的：

  • 对云内容的初始扫描可以更快地完成，这会减少命名空间出现在启用 Azure 文件同步的服务器上的等待时间。
  • 从 Azure 文件共享快照进行云端还原会更快。
  • 本地服务器的灾难恢复可以显著提高速度。
  • 可以更快地检测和同步在 Azure 文件共享中直接进行的更改（在同步之外）。

提示

如果你不知道你有多少个文件和文件夹，请使用 JAM Software GmbH 提供的 TreeSize 工具来确认。

部署映射的结构化方法

在稍后的步骤中部署云存储之前，请务必在本地文件夹与 Azure 文件共享之间创建映射。 此映射会告知，你要预配哪些 Azure 文件同步“同步组”资源以及具体数量。 同步组会将 Azure 文件共享和服务器上的文件夹关联在一起，并建立同步连接。

若要确定需要多少个 Azure 文件共享，请参考以下限制和最佳做法。 这样做有助于优化映射。

  • 安装了 Azure 文件同步代理的服务器可与最多 30 个 Azure 文件共享同步。

  • Azure 文件共享部署在存储帐户中。 这样安排会使存储帐户成为 IOPS 和吞吐量等性能指标的缩放目标。

    部署 Azure 文件共享时，应注意存储帐户的 IOPS 限制。 理想情况下，应该将文件共享按 1:1 与存储帐户映射。 但由于组织和 Azure 同时施加各种限制和制约，不一定始终能够实现这种映射。 如果无法在一个存储帐户中只部署一个文件共享，可考虑哪些共享会非常活跃和哪些将不会那么活跃，以确保不会将使用率最高的文件共享放置在同一存储帐户中。

    如果计划将应用提升到将在本机使用 Azure 文件共享的 Azure，则可能需要提高 Azure 文件共享的性能。 如果现在甚至以后都可以这样使用，最好在其自己的存储帐户中创建一个标准 Azure 文件共享。

  • 每个 Azure 区域的每个订阅的存储帐户限制为 250 个。

提示

考虑到这一点，通常需要将卷上的多个顶级文件夹分组到一个新的公用根目录中。 随后将这个新的根目录以及分组到其中的所有文件夹都同步到单个 Azure 文件共享。 此方法使你可以维持在每台服务器 30 个 Azure 文件共享同步的限制范围内。

在公用根下进行这种分组不会对数据访问产生影响。 你的 ACL 将保持原样。 只需要调整你在本地服务器文件夹上的任何共享路径（如 SMB 或 NFS 共享），现在你已将这些文件夹更改为公用根。 无其他更改。

重要

Azure 文件同步最重要的缩放矢量是需要同步的项目数（文件和文件夹）。 如需更多详细信息，请参阅 Azure 文件同步缩放目标。

最佳实践是使每个同步范围的项目数保持较低。 这是在将文件夹映射到 Azure 文件共享时要考虑的重要因素。 Azure 文件同步对每个共享使用 1 亿个项目（文件和文件夹）进行测试。 但是，在单个共享中，最好将项目数控制在 2000 万或 3000 万以下。 如果开始超过这些数量，请将命名空间拆分为多个共享。 如果一直大致低于这些数量，则可以继续将多个本地共享分组到相同 Azure 文件共享中。 这种做法可为你提供增长空间。

在这种情况下，可能能够以逻辑方式将一组文件夹同步到相同的 Azure 文件共享（使用前面提到的新的公用根文件夹方法）。 但是，重新分组文件夹使它们同步到两个（而不是一个）Azure 文件共享中可能会更好。 可以使用此方法使每个文件共享的文件和文件夹数在服务器间保持平衡。 还可以拆分本地共享并在更多的本地服务器上同步，从而增加每个额外服务器再同步 30 个 Azure 文件共享的能力。

常见文件同步方案和注意事项

# 同步方案 支持 注意事项（或限制） 解决方案（或解决方法）
1 将包含多个磁盘/卷和多个共享的文件服务器同步到同一目标 Azure 文件共享（合并） 否 目标 Azure 文件共享（云终结点）仅支持与一个同步组同步。

同步组仅支持在每个已注册服务器上使用一个服务器终结点。		 1) 首先将一个磁盘（其根卷）同步到目标 Azure 文件共享。 从最大的磁盘/卷开始将有助于满足本地存储要求。 配置云分层以将所有数据分层到云，从而释放文件服务器磁盘上的空间。 将其他卷/共享中的数据移到正在同步的当前卷。 继续逐个执行这些步骤，直到所有数据已分层到云/完成迁移。
2) 每次以一个根卷（磁盘）为目标。 使用云分层将所有数据分层到目标 Azure 文件共享。 从同步组中删除服务器终结点，使用下一个根卷/磁盘重新创建终结点，执行同步，然后重复该过程。 注意：可能需要重新安装代理。
3) 建议使用多个目标 Azure 文件共享（根据性能要求使用相同或不同的存储帐户）
2 将包含单个卷和多个共享的文件服务器同步到同一目标 Azure 文件共享（合并） 是 在同步到同一目标 Azure 文件共享的每个注册服务器上不能有多个服务器终结点（同上） 同步包含多个共享或顶级文件夹的卷的根目录。 有关详细信息，请参阅共享分组概念和卷同步。
3 将包含多个共享和/或卷的文件服务器同步到单个存储帐户下的多个 Azure 文件共享（1:1 共享映射） 是 单个 Windows Server 实例（或群集）可以同步最多 30 个 Azure 文件共享。

存储帐户是性能缩放目标。 IOPS 和吞吐量在文件共享之间共享。

将每个同步组的项数保持在每个共享包含 1 亿个项（文件和文件夹）以内。 理想情况下，最好在每个共享中包含不超过 2 千万到 3 千万个项。		 1) 使用多个同步组（同步组数量 = 要同步到的 Azure 文件共享数量）。
2) 在此方案中，每次只能同步 30 个共享。 如果该文件服务器上的共享数超过 30 个，请使用共享分组概念和卷同步来减少源上的根目录或顶级文件夹数量。
3) 使用本地的其他文件同步服务器并将数据拆分/移到这些服务器，以解决源 Windows 服务器上的限制。
4 将包含多个共享和/或卷的文件服务器同步到其他存储帐户下的多个 Azure 文件共享（1:1 共享映射） 是 单个 Windows Server 实例（或群集）最多可以同步 30 个 Azure 文件共享（相同或不同的存储帐户）。

将每个同步组的项数保持在每个共享包含 1 亿个项（文件和文件夹）以内。 理想情况下，最好在每个共享中包含不超过 2 千万到 3 千万个项。		 方法同上
5 将包含单个根卷或共享的多个文件服务器同步到同一目标 Azure 文件共享（合并） 否 同步组不能使用已在另一个同步组中配置的云终结点（Azure 文件共享）。

尽管同步组可以在不同的文件服务器上具有服务器终结点，但文件不能不同。		 请遵循上述方案 #1 中的指导，并注意每次以一个文件服务器为目标的附加要点。

创建映射表

显示映射表的示例的关系图。下载以下文件以体验并使用此图像的内容。

使用前面的信息来确定所需的 Azure 文件共享数目，以及现有数据的哪些部分最终会出现在哪个 Azure 文件共享中。

创建一个表来记录你的想法，这样你就可以在需要时进行参考。 保持井然有序非常重要，因为当你同时预配许多 Azure 资源时，可能会很容易丢失映射计划的详细信息。 下载以下 Excel 文件用作模板，以帮助创建映射。


用于设置下载上下文的 Excel 图标。 下载命名空间映射模板。

存储帐户数量

部署多个存储帐户，每个帐户存储较少数量的 Azure 文件共享，这可能有益于迁移。

如果文件共享的活跃度很高（文件共享由多个用户或应用程序使用），则两个 Azure 文件共享就可能达到存储帐户的性能限制。 因此，通常最好迁移到多个存储帐户，每个帐户都有其自己的单独的文件共享，并且每个存储帐户通常都不超过两个或三个共享。 最佳做法是在部署存储帐户时，让每个存储帐户都有一个文件共享。 可以将多个 Azure 文件共享加入同一存储帐户，前提是你在其中有存档共享。

相对于 Azure 文件同步，这些注意事项更适用于直接云访问（通过 Azure VM 或服务进行）。如果计划在这些共享上专门使用 Azure 文件同步，则可以将多个文件共享分组到一个 Azure 存储帐户中。 将来，你可能需要将应用直接迁移到云中，然后直接访问文件共享，因为这样可以受益于更高的 IOPS 和吞吐量。 也可以一开始就使用 Azure 中的服务，同样可以受益于 IOPS 和吞吐量的提高。

创建共享列表后，请将每个共享映射到它将驻留在其中的存储帐户。 确定一个 Azure 区域，确保每个存储帐户和 Azure 文件同步资源与所选的区域匹配。

重要

请勿立即配置存储帐户的网络和防火墙设置。 此时进行这些配置会导致迁移无法进行。 请在完成迁移后配置这些 Azure 存储设置。

存储帐户设置

可以对存储帐户进行许多配置。 使用以下清单确认存储帐户配置。 可以在迁移完成后更改网络配置。

  • 防火墙和虚拟网络：已禁用 - 不要配置任何 IP 限制或限制存储帐户对特定虚拟网络的访问。 在迁移过程中使用存储帐户的公共终结点。 必须允许来自 Azure VM 的所有 IP 地址。 迁移后，最好在存储帐户上配置任何防火墙规则。 按此方式配置源和目标存储帐户。
  • 专用终结点：支持 - 可以启用专用终结点，但使用公共终结点进行迁移，并且必须保持公共终结点可用。 这适用于源和目标存储帐户。

阶段 1 摘要

阶段 1 末尾：

  • 你已经大致了解 StorSimple 设备和卷。
  • 数据管理器服务已准备好访问云中的 StorSimple 卷，因为你已为每个 StorSimple 设备检索了“服务数据加密密钥”。
  • 你已经为需要迁移的具体卷和备份（可能不是最新的）制定了计划。
  • 你知道如何将卷映射到相应数量的 Azure 文件共享和存储帐户。

阶段 2：部署 Azure 存储和迁移资源

此部分讨论的注意事项涉及如何部署 Azure 中所需的不同资源类型。 某些资源类型用于保留迁移后数据，某些资源类型仅仅是用于迁移。 请不要在完成部署计划之前开始部署资源。 在部署 Azure 资源后，就很难（有时甚至不可能）更改 Azure 资源的某些方面。

部署所需资源 - 点击以播放！

该视频涵盖以下部署：

  • 存储帐户
  • 订阅和资源组
  • 存储帐户
  • 类型和名称
  • 性能和共享大小
  • 位置和复制类型
  • Azure 文件共享
  • StorSimple 数据管理器服务

部署存储帐户

你可能需要部署多个 Azure 存储帐户。 根据部署计划，每个 Azure 存储帐户都会保留较少数量的 Azure 文件共享。 请转到 Azure 门户来部署计划的存储帐户。 对于任何新的存储帐户，请考虑遵循基本设置。

重要

在迁移之前或迁移期间，不要为存储帐户配置网络和防火墙设置。 此时进行那些配置会导致迁移无法进行。 必须可在源和目标存储帐户上访问公共终结点。 不支持限制为特定 IP 范围或虚拟网络。 可以在迁移完成后更改存储帐户网络配置。

订阅

可以使用用于 StorSimple 部署的同一订阅，也可以使用其他订阅。 唯一限制是，你的订阅必须与 StorSimple 订阅位于同一个 Microsoft Entra 租户中。 在开始迁移之前，请考虑将 StorSimple 订阅移到相应的租户。 只能移动整个订阅，因为不能将单个 StorSimple 资源移到不同的租户或订阅。

资源组

Azure 中的资源组可用于组织资源和管理员管理权限。 了解更多信息。

存储帐户名称

存储帐户的名称将成为用于访问文件共享的 URL 的一部分，具有特定的字符限制。 在命名约定中，要注意以下几点：存储帐户名称必须独一无二；只允许使用小写字母和数字；长度要求 3 到 24 个字符之间；不允许使用连字符或下划线之类的特殊字符。 请参阅 Azure 存储资源命名规则。

位置

存储帐户所在的 Azure 区域非常重要。 如果使用 Azure 文件同步，则所有存储帐户都必须与存储同步服务资源位于同一区域。 你选取的 Azure 区域应靠近本地服务器和用户，或者是后者的几何中心。 部署资源后，无法更改其区域。

可以选取一个不同于 StorSimple 数据（存储帐户）当前驻留位置的区域，但这样做会在迁移过程中产生流出费用。 数据会离开 StorSimple 区域，进入新的存储帐户区域。 如果你始终在同一 Azure 区域，则没有任何带宽费用。

性能

你可以选择为 Azure 文件共享或标准存储选取高级存储 (SSD)。 标准存储包括用于文件共享的多个层。 对于从 StorSimple 进行迁移的大多数客户，标准存储是正确的选择。

  • 如果需要高级 Azure 文件共享的性能，请选择高级存储。
  • 为常规用途文件服务器工作负荷（包括热数据和存档数据）选择标准存储。 如果云中共享上的唯一工作负荷将是 Azure 文件同步，也请选择标准存储。
  • 对于高级文件共享，请选择创建存储帐户向导中的“文件共享”。

复制

有多种可用的复制设置。 只能从以下两个选项中进行选择：

  • 本地冗余存储 (LRS)。
  • 区域冗余存储 (ZRS)：并非在所有 Azure 区域都可用。

注意

不支持异地冗余存储 (GRS) 和异地区域冗余存储。

Azure 文件共享

创建存储帐户后，请转到存储帐户的“文件共享”部分，根据阶段 1 的迁移计划部署适当数量的 Azure 文件共享。 对于 Azure 中的新文件共享，请考虑遵循以下基本设置。

Azure 门户屏幕截图，显示新文件共享 UI。


名称
支持小写字母、数字和连字符。

配额
此处的配额相当于 Windows Server 实例上的 SMB 硬配额。 最佳做法是不要在此处设置配额，因为达到配额时，迁移和其他服务会失败。
层

为新的文件共享选择“事务优化”。 在迁移过程中，会发生许多事务。 稍后将层更改为最适合工作负荷的层会更经济高效。

StorSimple 数据管理器

将保存迁移作业的 Azure 资源称为“StorSimple 数据管理器”。 选择“新建资源”，搜索它。 然后选择“创建”。

此临时资源用于业务流程。 迁移完成后，可以取消对其的预配。 确保将其部署在与 StorSimple 存储帐户相同的订阅、资源组和区域中。

Azure 文件同步

使用 Azure 文件同步，你可以添加本地缓存，其中包含最常访问的文件。 与 StorSimple 的缓存能力类似，Azure 文件同步云分层功能带来的延迟相当于进行本地访问，并改进了对 Windows Server 实例和多站点同步上的可用缓存容量的控制。如果你的目标是有一个本地缓存，则请在本地网络中准备一个有足够的直连存储容量的 Windows Server VM（也支持物理服务器和故障转移群集）。

重要

目前不要设置 Azure 文件同步。 部署 Azure 文件同步的操作不应在迁移的阶段 4 之前开始。

阶段 2 摘要

在阶段 2 结束时，你应该部署了存储帐户以及跨这些帐户的所有 Azure 文件共享。 你还会有一个 StorSimple 数据管理器资源。 在配置迁移作业时，你将在阶段 3 使用后者。

阶段 3：创建和运行迁移作业

此部分介绍如何设置迁移作业，并映射 StorSimple 卷上那些应该复制到所选目标 Azure 文件共享中的目录。

创建并运行迁移作业 - 单击以播放！

此视频涵盖：

  • 创建迁移作业
  • 总结
  • 源
  • 选择要迁移的卷备份
  • 目标
  • 目录映射
  • 语义规则
  • 运行迁移作业
  • 运行作业定义
  • 查看作业状态
  • 并行运行作业
  • 解释日志文件

若要开始操作，请转到 StorSimple 数据管理器，找到菜单上的“作业定义”，然后选择“+ 作业定义”。 正确的目标存储类型为默认值：Azure 文件共享。

StorSimple 8000 系列迁移作业类型。

屏幕截图，显示了用于迁移作业的新作业创建窗体。

作业定义名称此名称应指示你要移动的文件集。 为其提供一个类似于 Azure 文件共享的名称是一种好的做法。

作业运行的位置
选择区域时，必须选择与 StorSimple 存储帐户相同的区域；如果该区域不可用，则必须选择一个靠近该区域的区域。

源

源订阅选择在其中存储 StorSimple 设备管理器资源的订阅。

StorSimple 资源
选择你的设备注册到的 StorSimple 设备管理器。

服务数据加密密钥
如果在记录中找不到该密钥，请查看本文前面的这个部分。

设备
选择包含你要迁移到其中的卷的 StorSimple 设备。

卷
选择源卷。 稍后你将决定是否要将整个卷或子目录迁移到目标 Azure 文件共享中。

卷备份
可以选择“选择卷备份”，以便选择要在此作业中移动的特定备份。 本文中的专门部分（即将发布）详细介绍了该过程。

目标

选择订阅、存储帐户和 Azure 文件共享作为此迁移作业的目标。

目录映射

本文中的专门部分讨论了所有相关的详细信息。

选择要迁移的卷备份

选择需要迁移的备份时，有一些重要的注意事项：

  • 迁移作业只能移动备份，而不能移动实时卷数据。 因此，最新备份与实时数据最接近，应始终位于在迁移中移动的备份的列表上。 打开“备份选择”对话框时，默认会选中它。
  • 确保最新备份是最新的，以便尽可能小地将差异保存到实时共享。 在创建迁移作业之前，可能需要手动触发并完成其他卷备份。 实时共享基础上的小增量可改善迁移体验。 如果此增量可以为零（意味着在列表中进行最新备份后 StorSimple 卷没有变化），则用户直接转换会大大简化和加速。
  • 必须将备份按照从最旧到最新的顺序回放到 Azure 文件共享中。 在运行迁移作业后，不能将较旧的备份“归类到”Azure 文件共享上的备份列表。 因此，在创建作业之前，必须确保备份列表已完成。
  • 创建作业后，无法修改作业中的备份列表，即使作业从未运行也是如此。
  • 若要选择备份，要迁移的 StorSimple 卷必须联机。

新作业创建窗体的屏幕截图，详细介绍了为迁移选择 StorSimple 备份的部分。

若要为迁移作业选择 StorSimple 卷的备份，请在作业创建窗体上选择“选择卷备份”。

一个图像，显示用于选择备份的边栏选项卡的上半部分列出了所有可用的备份。此列表中的选定备份将会灰显，并会被添加到边栏选项卡下半部分的第二个列表中。在那里，该备份也可以被再次删除。

当备份选择边栏选项卡打开时，它将分为两个列表。 在第一个列表中，将显示所有可用备份。 你可以通过对特定时间范围进行筛选来扩展和缩小结果集。 （请参阅下一部分）

选定备份将会灰显，并会被添加到边栏选项卡下半部分的第二个列表中。 第二个列表显示为迁移选定的所有备份。 还可以再次删除错误选择的备份。

注意

你必须选择要迁移的所有备份。 无法在以后添加较旧的备份。 创建作业后，无法通过修改作业来更改你的选择。

屏幕截图，显示备份选择边栏选项卡的时间范围选择。

默认情况下，将筛选列表以显示过去七天内的 StorSimple 卷备份。 默认情况下，将选择最新备份，即使它不是在过去 7 天内发生的。 对于较旧备份，请使用边栏选项卡顶部的时间范围筛选器。 你可以从现有筛选器中进行选择，也可以设置自定义时间范围，以便仅筛选在此期间进行的备份。

注意

不支持选择超过 50 个 StorSimple 卷备份。 包含大量备份的作业可能会失败。 确保迁移选中的备份之前，备份保留策略不会将其删除！

目录映射

对于迁移作业，目录映射是可选的。 如果将此部分留空，则 StorSimple 卷的根目录上的所有文件和文件夹都会移到目标 Azure 文件共享的根目录中。 大多数情况下，在 Azure 文件共享中存储整个卷的内容并不是最佳方法。 通常情况下，更好的做法是在 Azure 的多个文件共享中拆分卷的内容。 如果尚未制定计划，请先参阅将 StorSimple 卷映射到 Azure 文件共享。

你可能已在迁移计划中决定：必须将 StorSimple 卷上的文件夹跨多个 Azure 文件共享进行拆分。 如果是这种情况，你可以通过以下操作来完成拆分：

  1. 定义多个作业，以便将文件夹迁移到一个卷上。 每个作业都会有相同的 StorSimple 卷源，但会有与目标不同的 Azure 文件共享。
  2. 通过使用作业创建窗体的“目录映射”部分并遵循特定的映射语义，精确指定 StorSimple 卷中的哪些文件夹需要迁移到指定的文件共享中。

重要

提交此窗体时，无法验证窗体中的路径和映射表达式。 如果未正确指定映射，作业可能会彻底失败或产生不需要的结果。 在这种情况下，通常最好的办法是删除 Azure 文件共享，重新创建它，然后在新的迁移作业中修复此共享的映射语句。 使用固定映射语句运行新作业可以修复省略的文件夹并将其导入现有共享。 但是，只有因路径拼写错误而被忽略的文件夹才能以这种方式寻址。

语义元素

映射以从左到右的形式表示：[\源路径] > [\目标路径]。

语义字符 含义
\ 根级别指示符。
> [源] 和 [目标映射] 运算符。
| 或回车（换行符） 两个文件夹映射指令的分隔符。
或者，可以省略此字符，然后按 Enter 以在其所在行上获取下一个映射表达式。

示例

将 User data 文件夹的内容移到目标文件共享的根目录：

\User data > \

将整个卷内容移到目标文件共享上的新路径中：

\ > \Apps\HR tracker

将源文件夹内容移到目标文件共享上的新路径中：

\HR resumes-Backup > \Backups\HR\resumes

将多个源位置排序，形成一个新的目录结构：

\HR\Candidate Tracker\v1.0 > \Apps\Candidate tracker
\HR\Candidates\Resumes > \HR\Candidates\New
\Archive\HR\Old Resumes > \HR\Candidates\Archived

语义规则

  • 始终指定相对于根级别的文件夹路径。
  • 每个文件夹路径都以根级别指示符“\”开头。
  • 不要包含驱动器号。
  • 指定多个路径时，源路径或目标路径不能重叠：
    无效的源路径重叠示例：
    \folder\1 > \folder
    \folder\1\2 > \folder2
    无效的目标路径重叠示例：
    \folder > \
    \folder2 > \
  • 将忽略不存在的源文件夹。
  • 将创建目标中不存在的文件夹结构。
  • 与 Windows 一样，文件夹名称不区分大小写，但会保留大小写。

注意

迁移作业不会复制 StorSimple 卷上的 \System Volume Information 文件夹和 $Recycle.Bin 的内容。

运行迁移作业

你的迁移作业列在已部署到资源组的数据管理器资源中的“作业定义”下。 从作业定义列表中，选择要运行的作业。

在打开的作业边栏选项卡中，可以看到作业的当前状态和已选择的备份列表。 备份列表按从旧到新的顺序排序，并按此顺序迁移到 Azure 文件共享。

迁移作业边栏选项卡的屏幕截图，其中突出显示了启动作业的命令。它还显示已计划迁移的所选备份。

最初，迁移作业的状态为：“从未运行”。
准备就绪后，请开始迁移作业。 选择图像，查看分辨率更高的版本。
成功迁移备份后，将自动获取 Azure 文件共享快照。 StorSimple 备份的原始备份日期置于 Azure 文件共享快照的“注释”部分。 利用此字段，可以看到最初备份数据的时间与创建文件共享快照的时间的对照。

注意

必须按从最早到最新顺序处理备份。 创建迁移作业后，不能更改所选 StorSimple 卷备份列表。 如果备份列表不正确或不完整，请不要启动作业。 删除作业，并创建一个新作业，同时选择正确备份。 对于每个选中的备份，请检查保留计划。 一个或多个保留策略可能会在迁移前被删除！

每项错误

迁移作业在备份列表中有两列，其中列出了复制过程中可能发生的任何问题：

  • 复制错误
    此列列出了应复制但未复制的文件或文件夹。 这些错误通常可恢复。 当备份列出此列中的项问题时，请查看复制日志。 如果需要迁移这些文件，请选择“重试备份”。 完成备份处理后，此选项可用。 管理迁移作业部分更详细地介绍了你的选项。
  • 不支持的文件
    此列列出无法迁移的文件或文件夹。 Azure 存储对于当前或逻辑上不能存储在 Azure 文件共享中的文件名、路径长度和文件类型设定了限制。 对于此类错误，迁移作业不会暂停。 重试备份迁移不会更改结果。 当备份列出此列中的项问题时，请查看复制日志并记录下来。 如果上次备份中出现此类问题，并且你在复制日志中发现失败是由于文件名、路径长度或你可以影响的其他问题造成的，可能需要修正实时 StorSimple 卷中的问题，执行 StorSimple 卷备份，并仅通过该备份创建新的迁移作业。 然后，可迁移此修正的命名空间，使其成为 Azure 文件共享的最新/实时版本。 这是一个手动且耗时的过程。 仔细查看复制日志，并评估它是否值得。

这些复制日志是 *.csv 文件，其中列出了成功复制的命名空间项和未能复制的项。 错误进一步拆分为前面讨论的类别。 在日志文件位置，可以通过搜索“failed”来查找失败文件日志。 结果应是一组未能复制的文件日志。 按大小对这些日志进行排序。 可能会生成大小为 17 字节的额外日志。 它们是空的，可以忽略。 通过排序，可以将重点放在包含内容的日志上。

同一过程适用于记录成功复制的日志文件。

管理迁移作业

迁移作业具有以下状态：

  • 从未运行
    已定义但从未运行过的新作业。
  • 正在等待
    此状态中的作业正在等待将在迁移服务中预配的资源。 准备就绪后，它会自动切换到其他状态。
  • 失败
    失败的作业出现严重错误，导致无法处理更多备份。 作业不应进入此状态。 支持请求是最佳做法。
  • 已取消正在取消可以取消整个迁移作业或作业中的单个备份。 不会处理取消的备份，因为取消的迁移作业会停止处理备份。 预计取消作业需要很长时间。 这不会阻止你创建新作业。 最好的做法是耐心等待，让作业完全进入“已取消”状态。 可以忽略已失败/已取消的作业或稍后删除它们。 在 StorSimple 迁移结束时删除 Data Manager 资源之前，不必删除作业。

“迁移作业”边栏选项卡的屏幕截图，其顶部有一个处于“正在运行”状态的大状态图标。

正在运行

正在运行的作业当前正在处理备份。 请参阅边栏选项卡下半部分中的表，查看当前正在处理的备份以及哪些备份可能已迁移。
已迁移的备份包含一个列，其中含有指向复制日志的链接。 如果备份报告任何错误，应查看其复制日志。

“迁移作业”边栏选项卡的屏幕截图，其顶部有一个处于“已暂停”状态的大状态图标。

已暂停

如果需要决策，迁移作业将暂停。 此状况会启用边栏选项卡顶部的两个命令按钮：
当备份显示应移动但没有移动的文件时，选择“重试备份”（“复制错误”列）。
当备份丢失（自创建迁移作业后被策略删除）或备份损坏时，选择“跳过备份”。 单击失败的备份时，可以在打开的边栏选项卡中找到详细的错误信息。

当你跳过或重试当前备份时，迁移服务将在你的目标 Azure 文件共享中创建一个新快照。 你可能想要在以后删除以前的版本，因为它可能是不完整的。

显示“迁移作业”边栏选项卡的图像，其中顶部有一个处于“完成”状态的大状态图标。

“完成”和“完成但出现警告”如果作业中的所有备份都已成功处理，则会将迁移作业列为“完成”。
在以下情况下会进入“完成但出现警告”状态：

  • 备份遇到了可恢复的问题。 此备份标记为“部分成功”或“失败”。
  • 你决定通过跳过存在上述问题的备份来继续进行暂停的作业。 （你选择了“跳过备份”而不是“重试备份”）
如果迁移作业完成但出现警告，则应始终查看相关备份的复制日志。

并行运行作业

你可能有多个 StorSimple 卷，每个卷都有其自己的共享必须迁移到 Azure 文件共享。 务必要了解可以并行执行多少操作。 用户体验不会强制实施限制，如果同时执行作业，则会降级或阻止完成迁移。

定义迁移作业没有限制。 可以在相同或不同的 StorSimple 设备上定义相同的 StorSimple 源卷、相同的 Azure 文件共享。 但是，运行它们有一些限制：

  • 一次只能运行一个具有相同 StorSimple 源卷的迁移作业。
  • 一次只能运行一个具有相同目标 Azure 文件共享的迁移作业。
  • 在开始下一个作业之前，确保以前的任何作业都在 copy stage 中，并显示移动文件的进度至少 30 分钟。
  • 只要你遵守上述规则，最多可以对每个 StorSimple 设备管理器并行运行四个迁移作业。

尝试启动迁移作业时，将检查先前的规则。 如果有作业正在运行，则可能无法启动新作业。 你将收到一个警报，其中列出了在开始新作业之前必须完成的当前正在运行的作业的名称。

提示

最好在“数据管理器”资源的“作业定义”选项卡中定期检查迁移作业，看看是否有任何作业已暂停并需要你的输入才能完成。

阶段 3 摘要

在阶段 3 结束时，你将至少运行了一个迁移作业（从 StorSimple 卷迁移到 Azure 文件共享）。 在运行的情况下，你将把指定的备份迁移到 Azure 文件共享快照。 你现在可以重点关注以下事项：为共享设置 Azure 文件同步（在某个共享的迁移作业完成后进行），或让信息工作者和应用直接共享访问 Azure 文件共享。

阶段 4：访问 Azure 文件共享

访问 Azure 文件共享的主要策略有两种：

  • Azure 文件同步：将 Azure 文件同步部署到本地 Windows Server 实例。 Azure 文件同步具有本地缓存的所有优点，就像 StorSimple 一样。
  • Direct-share-access：部署 Direct-share-access。 如果给定 Azure 文件共享的访问方案无法受益于本地缓存，或者你不再能够托管本地 Windows Server 实例，请使用此策略。 在这里，你的用户和应用将继续通过 SMB 协议访问 SMB 共享。 这些共享不再位于本地服务器上，而是直接位于云中。

你应该已经确定了本指南的阶段 1 中最合适的选项。

此部分的其余内容重点介绍部署说明。

Azure 文件共享的访问选项 - 单击以播放！

此视频涵盖：

  • 访问 Azure 文件共享的方法
  • Azure 文件同步
  • Direct-share-access
  • 部署 Azure 文件同步
  • 部署 Azure 文件同步云资源
  • 部署本地 Windows Server 实例
  • 为 Azure 文件同步准备 Windows Server 实例
  • 在 Windows Server 实例上配置 Azure 文件同步
  • 监视初始同步
  • 测试 Azure 文件同步
  • 创建 SMB 共享

部署 Azure 文件同步

现在可以部署 Azure 文件同步的一部分了。

  1. 创建 Azure 文件同步云资源。
  2. 在本地服务器上部署 Azure 文件同步代理。
  3. 将服务器注册到云资源。

此时请不要创建任何同步组。 只有在完成迁移作业（迁移到 Azure 文件共享）后，才应使用 Azure 文件共享设置同步。 如果在迁移完成之前开始使用 Azure 文件同步，则可能会给迁移带来不必要的困难，因为你无法轻松判断何时启动直接转换。

部署 Azure 文件同步云资源

要完成此步骤，你需要 Azure 订阅凭据。

为 Azure 文件同步配置的核心资源称为存储同步服务。 建议只为当前或将来同步同一组文件的所有服务器部署一项存储同步服务。 仅当有不同的服务器组，且这些服务器永不交换数据时，才创建多项存储同步服务。 例如，你可能有一些绝不会同步同一个 Azure 文件共享的服务器。 否则，最佳做法是使用一项存储同步服务。

为存储同步服务选择一个离你的位置最近的 Azure 区域。 所有其他云资源必须部署在同一区域中。 若要简化管理，请在订阅中创建一个包含同步和存储资源的新资源组。

有关详细信息，请参阅有关部署 Azure 文件同步的文章中关于部署存储同步服务的部分。请严格按照这部分内容操作。 后续步骤中有这篇文章其他部分的链接。

提示

如果要在迁移完成后更改数据驻留的 Azure 区域，请在此迁移的目标存储帐户所在的区域中部署存储同步服务。

部署本地 Windows Server 实例

  • 以虚拟机或物理服务器的形式创建 Windows Server 2019（最低版本为 2012R2）。 也支持 Windows Server 故障转移群集。 不要重复使用面向 StorSimple 8100 或 8600 的服务器。
  • 预配或添加直连存储。 不支持网络连接存储 (NAS)。

最佳做法是，为新的 Windows Server 实例提供相当的或更大的存储量（相对于 StorSimple 8100 或 8600 设备在本地提供的用于缓存的存储量而言）。 你使用 Windows Server 实例的方式与使用 StorSimple 设备的方式相同。 如果它具有与设备相同的存储量，则缓存体验应该类似（即使不是完全相同）。 你可以在 Windows Server 实例中随意添加或删除存储。 此功能使你能够扩展本地卷大小以及可用于缓存的本地存储量。

为文件同步准备 Windows Server 实例

在本部分中，你将在 Windows Server 实例上安装 Azure 文件同步代理。

部署指南说明了需要关闭“Internet Explorer 增强的安全性配置”。 此安全措施不适用于 Azure 文件同步。将其关闭后，可以对 Azure 进行身份验证，而不会出现任何问题。

打开 PowerShell。 使用以下命令安装所需的 PowerShell 模块。 请确保按照提示安装完整的模块和 NuGet 提供程序。

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

如果从服务器访问 Internet 时遇到任何问题，现在可以解决这些问题。 Azure 文件同步使用与 Internet 的任何可用网络连接。 还支持要求代理服务器访问 Internet。 可以立即配置计算机范围的代理，也可以在代理安装期间指定仅由 Azure 文件同步使用的代理。

如果配置代理意味着需要为服务器打开防火墙，那么这种方法可能适合你。 服务器安装结束时，在完成服务器注册后，会有一个网络连接报表精确显示所选区域中 Azure 文件同步需要与之通信的 Azure 中的终结点 URL。 该报告还会告诉你需要进行通信的原因。 可以使用该报告将服务器上的防火墙锁定到特定的 URL。

还可以采用相对保守的方法，就是不完全打开防火墙。 可以改为限制服务器与更高级别的 DNS 命名空间进行通信。 有关详细信息，请参阅 Azure 文件同步代理和防火墙设置。 遵循自己的网络最佳做法。

在服务器安装向导结束时，将打开一个服务器注册向导。 从一开始将服务器注册到存储同步服务的 Azure 资源。

部署指南中详细地介绍了这些步骤，其中包含要首先安装的 PowerShell 模块：Azure 文件同步代理安装。

使用最新的代理。 可以从 Microsoft 下载中心下载：Azure 文件同步代理。

成功安装并注册服务器后，可以确认是否已成功完成此步骤。 转到 Azure 门户中的存储同步服务资源。 在左侧菜单中，转到“已注册的服务器”。 你将看到你的服务器已在此处列出。

在 Windows Server 实例上配置 Azure 文件同步

要完成此过程，已注册的本地 Windows Server 实例必须准备就绪，并已连接到 Internet。

重要

在继续操作之前，必须先完成 StorSimple 迁移，将文件和文件夹迁移到 Azure 文件共享中。 请确保不会对文件共享进行更多更改。

此步骤将前面步骤中在 Windows Server 实例中设置的所有资源和文件夹绑定在一起。

  1. 登录 Azure 门户。
  2. 找到你的存储同步服务资源。
  3. 在每个 Azure 文件共享的存储同步服务资源中创建一个新的同步组。 在 Azure 文件同步术语中，Azure 文件共享是你在创建同步组时所述的同步拓扑中的云终结点。 在创建同步组时，为它提供一个熟悉的名称，便于你识别在那里同步的是哪组文件。 请确保引用具有匹配名称的 Azure 文件共享。
  4. 创建同步组后，该同步组的行会显示在同步组列表中。 选择名称（链接）可显示同步组的内容。 你将在“云终结点”下看到你的 Azure 文件共享。
  5. 找到“添加服务器终结点”按钮。 你在本地服务器上预配的文件夹将成为此服务器终结点的路径。

重要

确保启用云分层。 云分层是一项 Azure 文件同步功能，它允许本地服务器的存储容量小于云中的存储容量，但仍然提供完整的命名空间。 在本地有用的数据也缓存在本地，以实现快速性能。 在此步骤启用云分层的另一个原因是我们不想在此阶段同步文件内容。 此时只应移动命名空间。

部署 direct-share-access

此视频是有关如何通过五个简单步骤将 Azure 文件共享直接安全地公开给信息工作者和应用的指南和演示。
该视频引用了以下主题的专用文档。 请注意，Azure Active Directory 现已更名为 Microsoft Entra ID。 有关详细信息，请参阅 Azure AD 的新名称。

阶段 4 摘要

在此阶段结束时，你已在 StorSimple 数据管理器中创建并运行了多个迁移作业。 这些作业已将文件和文件夹及其备份迁移到 Azure 文件共享。 你还为 direct-share-access 部署了 Azure 文件同步或准备了网络和存储帐户。

阶段 5：用户直接转换

在此阶段，你将完成迁移：

  • 计划停机时间。
  • 当阶段 3 中的迁移作业已经运行后，追加你的用户和应用已在 StorSimple 端生成的任何更改。
  • 通过直接共享访问将用户故障转移到使用 Azure 文件同步或 Azure 文件共享的新 Windows Server 实例。

将工作负载直接转换到 Azure 文件共享的步骤 - 单击以播放！

此视频涵盖：

  • 直接转换工作负载前要执行的步骤
  • 执行直接转换
  • 直接转换后的步骤

计划停机时间

对于用户和应用来说，此迁移方法都需要一定的停机时间。 目标是将停机时间尽量缩短。 可以查看以下注意事项：

  • 确保 StorSimple 卷在运行迁移作业时始终可用。
  • 为共享运行完数据迁移作业后，就可以从 StorSimple 卷或共享中删除用户访问权限（至少可以删除写入访问权限）。 最终的 RoboCopy 会跟上 Azure 文件共享的进度。 然后，你可以对用户进行直接转换。 运行 RoboCopy 的位置取决于你选择使用 Azure 文件同步还是 direct-share-access。 随后的部分介绍了该主题。
  • 完成 RoboCopy 追加以后，便可以通过 Azure 文件共享直接向用户公开新位置，也可以使用 Azure 文件同步通过 Windows Server 实例上的 SMB 共享向用户公开新位置。通常，使用 DFS-N 部署可快速高效地完成直接转换。 它会使现有共享地址保持一致，并重新指向包含已迁移文件和文件夹的新位置。

对于存档数据，完全可行的方法是在 StorSimple 卷（或子文件夹）上停机，再进行一次 StorSimple 卷备份、迁移，然后打开迁移目标供用户和应用访问。 这样，你就无需再追赶 RoboCopy。 但是，这种方法的代价是停机时间延长，停机时间可能会延长到几天或更长时间，具体取决于你需要迁移的文件和备份的数量。 这可能只适用于长时间无写访问权限也可以执行的存档工作负载。

确定你的命名空间完全同步到你的服务器的时间

对 Azure 文件共享使用 Azure 文件同步时，必须在启动任何本地 RoboCopy 之前确定整个命名空间已下载到服务器，这一点很重要。 下载命名空间所花的时间取决于 Azure 文件共享中的项目数。 可以通过两种方法来确定命名空间是否已完全到达服务器。

Azure 门户

可以使用 Azure 门户来查看命名空间完全到达的时间。

  • 登录到 Azure 门户，转到同步组。 检查同步组和服务器终结点的同步状态。
  • 下载是一种有意思的指示。 如果服务器终结点是新预配的，则会显示“初始同步”，表示命名空间仍在下载。 在该状态更改为除“初始同步”之外的任何状态后，命名空间将在服务器上完全填充。

你现在可以使用本地 RoboCopy 继续操作了。

Windows Server 事件查看器

你还可以使用 Windows Server 实例上的事件查看器来确定命名空间完全到达的时间。

  1. 打开“事件查看器”，转到“应用程序和服务”。
  2. 转到 Microsoft\FileSync\Agent\Telemetry 并将其打开。
  3. 查找与已完成的同步会话对应的最近的事件 (9102)。
  4. 选择“详细信息”，确认你在查看 SyncDirection 值为 “Download”的事件。
  5. 若要了解命名空间完全下载到服务器的时间，可以查看一个包含 Scenario 的事件，其值为 FullGhostedSync，HResult = 0。
  6. 如果错过了该事件，也可查找 SyncDirection = Download 且 Scenario = "RegularSync" 的其他 9102 事件。 如果找到这些事件中的一个，则还表明命名空间已下载完毕且同步已进展到定期同步会话阶段，不管此时是否有需要同步的内容。

最终 RoboCopy

此时，本地 Windows Server 实例与 StorSimple 8100 或 8600 设备之间存在差异。

  1. 在迁移过程中，需要追加用户或应用已在 StorSimple 端生成的更改。
  2. 在使用 Azure 文件同步的情况下：StorSimple 设备具有填充的缓存，而 Windows Server 实例此时只有一个命名空间，没有在本地存储的文件内容。 可以通过最终 RoboCopy 来快速启动本地 Azure 文件同步缓存，方法是：尽可能多地拉取本地缓存的文件内容，只要这些内容可用且 Azure 文件同步服务器能够容纳它们。
  3. 迁移作业可能会遗留某些文件（由于存在无效的字符）。 如果是这样，请将它们复制到已启用 Azure 文件同步的 Windows Server 实例。 稍后可以调整它们，这样它们就会同步。如果不将 Azure 文件同步用于特定共享，则最好是在 StorSimple 卷上重命名那些使用无效字符的文件， 然后直接对 Azure 文件共享运行 RoboCopy。

警告

Windows Server 2019 中的 Robocopy 遇到一个问题，该问题会导致在使用 /MIR 函数时，在目标服务器上由 Azure 文件同步分层的文件会从源重新复制并重新上传到 Azure。 建议在除 2019 之外的 Windows Server（如 Windows Server 2016）上运行 Robocopy。

警告

在服务器具有下载完的用于 Azure 文件共享的命名空间之前，不得启动 RoboCopy。 有关详细信息，请参阅确定何时将命名空间完全下载到服务器。

你只希望复制在上次运行迁移作业后更改过的文件，以及之前尚未通过这些作业进行移动的文件。 你可以稍后（在完成迁移后）在服务器上解决它们为何没有移动的问题。 有关详细信息，请参阅 Azure 文件同步故障排除。

RoboCopy 有多个参数。 以下示例展示了一个完成的命令，以及选择这些参数的原因的列表。

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
开关 含义
/MT:n 允许 Robocopy 以多线程方式运行。 n 的默认值为 8。 最大线程数为 128 个。 尽管较高的线程计数有助于使可用带宽饱和，但并不意味着线程越多，迁移就越快。 对 Azure 文件存储的测试表明，在 8 和 20 之间会体现出初始复制运行的均衡性能。 后续的 /MIR 运行会逐步受到可用计算与可用网络带宽的影响。 对于后续的运行，请让你的线程计数值尽量与处理器核心计数和每个核心的线程计数匹配。 考虑是否需要为生产服务器可能具有的其他任务预留核心。 通过 Azure 文件存储进行的测试表明，线程多达 64 个也可以获得良好的性能，但前提是处理器可以同时使它们保持活动状态。
/R:n 第一次尝试复制失败的文件的最大重试计数。 在运行中文件复制永久失败之前，Robocopy 会尝试 n 次。 你可以优化运行的性能：如果你认为是超时问题导致了过去的失败，请选择值 2 或 3。 这在 WAN 链接上可能更常见。 如果你认为文件复制失败是因为它正在被使用，请选择“不重试”或值 1。 如果在几秒钟后重试，可能没有足够的时间让文件的使用中状态发生变化。 使文件保持打开状态的用户或应用可能需要数小时的时间。 在这种情况下，接受文件未能复制，然后在计划的一次后续 Robocopy 运行中捕获该文件，最终可能会成功复制文件。 这有助于使当前运行更快完成，而不会因多次重试而延长，最终在超过重试超时时间之后，由于文件仍处于打开状态而导致大量复制失败。
/W:n 指定在尝试复制上一次复制尝试未成功的文件之前 Robocopy 等待的时间。 n 是两次重试之间的等待间隔（秒）。 /W:n 通常与 /R:n 一起使用。
/B 在备份应用程序会使用的同一模式下运行 Robocopy。 此开关允许 Robocopy 移动当前用户无权访问的文件。 备份开关依赖于在管理员提升控制台或 PowerShell 窗口中运行 Robocopy 命令。 如果对 Azure 文件存储使用 Robocopy，请确保使用存储帐户访问密钥与域标识装载 Azure 文件共享。 如果不这样做，错误消息可能不会直观地引导你解决问题。
/MIR （将源镜像映射到目标）使 Robocpy 只复制源和目标之间的增量。 将复制空子目录。 将复制目标上已更改或不存在的项（文件或文件夹）。 将从目标上清除（删除）目标上存在但源上没有的项。 使用此开关时，要使源和目标文件夹结构完全匹配。 “匹配”表示从正确的源和文件夹级别复制到目标上的匹配文件夹级别。 只有这样，才能成功完成“追赶”复制。 当源和目标不匹配时，使用 /MIR 将导致大规模删除和重新复制。
/IT 确保在某些镜像方案中保留保真度。
例如，如果在两个 RoboCopy 运行之间，文件遇到 ACL 更改和属性更新的情况，它将被标记为“隐藏”。 如果没有 /IT，RoboCopy 可能会遗漏 ACL 更改，并且不会将其传输到目标位置。
/COPY:[copyflags] 文件副本的保真度。 默认值：/COPY:DAT。 复制标志：D= 数据，A= 属性，T= 时间戳，S= 安全性 = NTFS ACL，O= 所有者信息，U= 审核信息D。 审核信息无法存储在 Azure 文件共享中。
/DCOPY:[copyflags] 目录副本的保真度。 默认值：/DCOPY:DA。 复制标记：D = 数据，A = 属性，T = 时间戳。
/NP 指定不显示每个文件和文件夹的复制进度。 显示进度会明显降低复制性能。
/NFL 指定不记录文件名。 提高复制性能。
/NDL 指定不记录目录名。 提高复制性能。
/XD 指定要排除的目录。 在卷的根目录上运行 Robocopy 时，请考虑排除隐藏的 System Volume Information 文件夹。 如果根据设计使用了它，其中的所有信息都特定于此确切系统上的确切卷，并且可按需重新生成。 复制此信息在云中或者将数据复制回另一个 Windows 卷时不会有任何帮助。 留下此内容不应被视为数据丢失。
/UNILOG:<file name> 将状态以 Unicode 形式写入日志文件。 （覆盖现有日志。）
/L 仅适用于测试运行
仅列出文件。 它们不会被复制，也不会被删除，并且也不会有时间戳。 通常与 /TEE 配合使用以获得控制台输出。 可能需要删除示例脚本中的标志（例如 /NP、/NFL 和 /NDL），才能正确记录测试结果。
/LFSM 仅适用于具有分层存储的目标。 当目标为远程 SMB 共享位置时则不受支持。
指定 Robocopy 在“低可用空间模式”下运行。此开关可对具有分层存储的目标有用，这些目标可能会在 Robocopy 完成之前耗尽本地容量。 它是专门为启用 Azure 文件同步云分层的目标而添加的。 它可独立于 Azure 文件同步使用。在此模式下，每当文件复制会导致目标卷的可用空间低于“下限”值时，Robocopy 都会暂停。 可通过标志的 /LFSM:n 形式指定此值。 参数 n 在基数 2 nKB、nMB 或 nGB 中指定。 如果指定的 /LFSM 没有明确的下限值，则下限将设置为目标卷大小的 10%。 低可用空间模式与 /MT、/EFSRAW 或 /ZB 不兼容。 Windows Server 2022 中添加了对 /B 的支持。 请参阅下面的 Windows Server 2022 和 RoboCopy LFSM 部分了解详细信息，包括有关相关 bug 和解决方法的详细信息。
/Z 谨慎使用
在重启模式下复制文件。 只有在不稳定的网络环境下，才建议使用此开关。 由于额外的日志记录，此开关会明显降低复制性能。
/ZB 谨慎使用
使用重启模式。 如果访问被拒绝，此选项将使用备份模式。 由于检查点，此选项会明显降低复制性能。

重要

建议使用 Windows Server 2022。 使用 Windows Server 2019 时，请确保使用最新的修补程序级别或者至少安装了 OS 更新 KB5005103。 它包含适用于某些 Robocopy 方案的重要修补程序。

在配置 RoboCopy 命令的源和目标位置时，请务必查看源和目标的结构，以确保它们匹配。 如果使用了迁移作业的目录映射功能，则根目录结构可能不同于 StorSimple 卷的结构。 如果是这种情况，则可能需要多个 RoboCopy 作业，每个子目录一个。 如果不确定命令是否会按预期执行，则可以使用 /L 参数，该参数会模拟命令，实际上并不进行任何更改。

此 RoboCopy 命令使用 /MIR，因此不会移动相同的文件（例如分层文件）。 但是，如果获得的源路径和目标路径错误，则 /MIR 还会清除 StorSimple 源路径上不存在的 Windows Server 实例或 Azure 文件共享上的目录结构。 它们必须完全匹配，否则 RoboCopy 作业无法达到其预期目的：使用在迁移过程中所做的最新更改来更新已迁移的内容。

请查阅 RoboCopy 日志文件，看文件是否遗留了文件。 如果存在问题，请修复问题，然后重新运行 RoboCopy 命令。 在解决你关注的文件或文件夹的未决问题之前，请不要取消预配任何 StorSimple 资源。

如果不使用 Azure 文件同步来缓存相关且特定的 Azure 文件共享，而是选择使用 direct-share-access，请执行以下操作：

  1. 将 Azure 文件共享作为网络驱动器装载到本地 Windows 计算机。
  2. 在 StorSimple 与装载的 Azure 文件共享之间执行 RoboCopy。 如果文件无法复制，请在 StorSimple 端修复其名称，删除无效字符， 然后重试 RoboCopy。 前面列出的 RoboCopy 命令可以多次运行，而不会导致对 StorSimple 进行不必要的重新调用。

故障排除和优化

给定 RoboCopy 运行的速度和成功率将取决于以下几个因素：

  • 源和目标存储上的 IOPS
  • 源和目标之间的可用网络带宽
  • 快速处理命名空间中的文件和文件夹的能力
  • RoboCopy 运行之间的更改数
  • 需要复制的文件的大小和数量

IOPS 和带宽注意事项

在此类别中，你需要考虑源存储、目标存储以及连接这两者的网络的能力 。 可能的最大吞吐量由这三个组成部分中的最慢者决定。 请确保将网络基础结构配置为支持最佳传输速度来达到其最佳性能。

注意

尽管最理想的结果通常是尽可能快地复制，但还要考虑将本地网络和 NAS 设备用于其他（通常是业务关键的）任务。

当存在迁移可能独占可用资源的风险时，尽可能快地复制可能不可取。

  • 请考虑在你的环境中最适合运行迁移的时间：白天、非工作时间或周末。
  • 还请考虑在 Windows Server 上设立网络 QoS 来限制 RoboCopy 速度。
  • 避免迁移工具不必要的工作。

RoboCopy 可通过指定 /IPG:n 开关来插入数据包间延迟，其中 n 是 RoboCopy 数据包之间的时间间隔（以毫秒为单位）。 使用此开关有助于避免 IO 受限设备和拥堵网络链路上的资源独占。

/IPG:n 无法用于将带宽限制精确到特定 Mbps。 请改用 Windows Server 网络 QoS。 RoboCopy 完全依靠 SMB 协议来满足各项网络需求。 使用 SMB 导致 RoboCopy 无法影响网络吞吐量本身，但它可减慢其使用速度。

类似的思路也适用于在 NAS 上观察到的 IOPS。 NAS 卷上的群集大小、数据包大小和一系列其他因素都会影响 IOPS 观测值。 引入数据包间延迟通常是控制 NAS 上的负载的最简单方法。 测试多个值，例如从大约 20 毫秒 (n=20) 到该数字的倍数。 引入延迟后，可评估其他应用现在是否可按预期方式工作。 通过此优化策略，你可在环境中找到最佳的 RoboCopy 速度。

处理速度

RoboCopy 将遍历它指向的命名空间，并评估每个文件和文件夹是否适合复制。 在初始复制和追加复制期间将评估每个文件。 例如，对相同的源和目标存储位置重复运行 RoboCopy/MIR。 这些重复运行有助于最大程度地减少用户和应用的停机时间，同时提高迁移文件的总体成功率。

我们通常默认带宽是迁移过程中的最大限制因素，也可能的确如此。 但枚举命名空间的能力可能会影响复制的总时间，对于包含更小文件的更大命名空间来说，复制总时间甚至更长。 思考一下，假定所有其他变数都相同，与复制总大小为 1 TiB，但数量更少的更大文件相比，复制 1 TiB 的小文件所耗时间要长得多。 因此，如果要迁移大量小文件，则传输速度可能会很缓慢。 这是预期的行为。

导致这种差异的原因是遍历命名空间所需的处理能力。 RoboCopy 通过 /MT:n 参数支持多线程复制，其中 n 表示要使用的线程数。 因此，在专门为 RoboCopy 预配计算机时，请考虑处理器核心的数量及其与提供的线程计数的关系。 最常见的是每个核心两个线程。 计算机的核心和线程计数是一个重要的数据点，可决定应该指定的多线程值 /MT:n。 还应考虑计划在给定计算机上并行运行的 RoboCopy 作业的数目。

与更少的线程相比，线程更多可更快地复制 1-TiB 的小文件。 同时，对 1 TiB 更大文件投入额外资源可能不会产生成比例的效益。 如果线程数较高，则会尝试通过网络同时复制更多的大文件。 这种额外的网络活动增加了受吞吐量或存储 IOPS 限制的可能性。

在第一次 RoboCopy 到空目标或使用大量更改文件的差异运行期间，你可能会受到网络吞吐量的限制。 在初始运行时，以较高的线程数开始。 较高的线程数（甚至超过计算机上当前可用的线程）有助于使可用网络带宽饱和。 后续 /MIR 运行会逐渐受到处理项的影响。 差异运行中的更改越少，通过网络传输的数据就越少。 相比于通过网络链接来移动命名空间项，你的速度现在更取决于处理命名空间项的能力。 对于后续运行，请将线程计数值与处理器核心计数和每个核心的线程计数相匹配。 考虑是否需要为生产服务器可能具有的其他任务预留核心。

提示

经验法则：第一次运行 RoboCopy 时（将移动延迟较高的网络的大量数据），会受益于过度预配线程计数 (/MT:n)。 后续运行将复制较少的差异，更有可能从网络吞吐量受限转变为计算受限。 在这些情况下，通常最好将 RoboCopy 线程计数与计算机上实际可用的线程数相匹配。 在这种情况下，过度预配可能会导致处理器产生更多与情景相关的波动，从而可能会减慢复制速度。

避免不必要的工作

避免在命名空间中进行大规模更改。 例如，在目录之间移动文件、大规模更改属性或更改权限 (NTFS ACL)。 尤其是 ACL 更改可能会产生很大的影响，因为它们通常对文件夹层次结构中位置较低的文件具有级联更改效果。 可能产生如下后果：

  • 延长 RoboCopy 作业运行时，因为受 ACL 更改影响的每个文件和文件夹都需要更新
  • 重用先前移动的数据可能需要重新复制。 例如，如果在早先复制文件后文件夹结构发生更改，则需要复制更多数据。 RoboCopy 作业无法“回放”命名空间更改。 下一个作业必须清除先前传输到旧文件夹结构中的文件，然后再次将文件上传到新文件夹结构中。

另一个重要方面是有效使用 RoboCopy 工具。 借助推荐的 RoboCopy 脚本，你将创建一个日志文件来放置错误并保存该文件。 可能会发生复制错误，这是正常的。 这些错误通常使得必须运行多轮复制工具，例如 RoboCopy。 有一个初始运行，例如从 NAS 到 DataBox 或从服务器到 Azure 文件共享。 还会使用 /MIR 开关执行一次或多次额外运行，以捕获并重试未复制的文件。

应最好准备来针对给定的命名空间范围运行多轮 RoboCopy。 后续运行将更快完成，因为它们需要复制的内容更少，但会越来越多地受到命名空间的处理速度限制。 运行多轮复制时，可禁止 RoboCopy 尝试在给定的运行中过度复制所有内容来加快每一轮的速度。 这些 RoboCopy 开关可造成很大的差异：

  • /R:n n = 重试复制失败文件的频率
  • /W:n n = 两次重试之间需等待的秒数

/R:5 /W:5 是一个合理的设置，你可根据自己的喜好进行调整。 在本例中，失败的文件将重试 5 次，两次重试之间有 5 秒的等待时间。 如果文件仍无法复制，则下一个 RoboCopy 作业将重试。 通常，由于正在使用或超时问题而失败的文件最终可能会以这种方式成功复制。

Windows Server 2022 和 RoboCopy LFSM

RoboCopy 开关 /LFSM 可用于避免 RoboCopy 作业因“卷已满”错误而失败。 每当文件复制导致目标卷的可用空间低于“下限”值时，RoboCopy 都会暂停。

将 RoboCopy 与 Windows Server 2022 一起使用。 只有此版本的 RoboCopy 包含重要的 bug 修复和功能，它们使开关与大多数迁移中所需的其他标志兼容。 例如，与 /B 标志兼容。

/B 在备份应用程序会使用的同一模式下运行 RoboCopy。 通过此开关，RoboCopy 可移动当前用户无权操作的文件。

通常，RoboCopy 可以在源、目标或第三台计算机上运行。

重要

如果要使用 /LFSM，则必须在 Windows Server 2022 目标 Azure 文件同步服务器上运行 RoboCopy。

另请注意，对于 /LFSM，还必须使用本地路径（而不是 UNC 路径）作为目标。 例如，应使用 E:\Foldername 而不是像 \\ServerName\FolderName 这样的 UNC 路径作为目标路径。

注意

Windows Server 2022 上当前可用的 RoboCopy 版本存在一个 bug，这会导致暂停针对每个文件错误计数而进行计数。 请应用以下解决方法。

建议的 /R:2 /W:1 标志会增加文件因 /LFSM 所致暂停而失败的可能性。 在此示例中，因 /LFSM 所致暂停而在 3 次暂停后未复制的文件会错误地导致 RoboCopy 使该文件失败。 解决方法是为 /R:n 和 /W:n 使用更高的值。 /R:10 /W:1800（每 30 分钟重试 10 次）是一个很好的例子。 这可以让 Azure 文件同步分层算法有时间在目标卷上创建空间。

此 bug 已修复，但修补程序尚未公开发布。 请查看此段落，了解修补程序的可用性及其部署方法。

用户完全转移

如果使用 Azure 文件同步，则可能需要在那个与 StorSimple 卷上的已有共享匹配且已启用 Azure 文件同步的 Windows Server 实例上创建 SMB 共享。 你可以事先安排好此步骤，提前进行操作，这样就不会在这里浪费时间。 但在此之前，必须确保无人有权更改 Windows Server 实例。

如果你有一个 DFS-N 部署，则可将 DFN-Namespaces 指向新的服务器文件夹位置。 如果你没有 DFS-N 部署，并且在本地为 8100 或 8600 设备前置了 Windows Server 实例，则可将该服务器从域中取出。 然后，将启用了 Azure 文件同步的新 Windows Server 实例加入域。 在该过程中，请为服务器提供与旧服务器相同的服务器名称和共享名称。这样，对用户、组策略和脚本来说，直接转换就仍然是透明的。

详细了解 DFS-N。

第 6 阶段：撤销

取消预配资源时，你将失去对该资源及其数据的配置的访问权限。 取消预配无法撤消。 在确认以下事项之前，请不要继续操作：

  • 迁移已完成。
  • 没有对你要取消预配的 StorSimple 文件、文件夹或卷备份的任何依赖项。

在开始之前，最佳做法是在生产环境中观察新的 Azure 文件同步部署一段时间。 你可以在该段时间内解决可能遇到的任何问题。 观察 Azure 文件同步部署至少几天后，就可以开始按以下顺序预配资源：

  1. 通过 Azure 门户取消预配 StorSimple 数据管理器资源。 所有 DTS 作业都将随之一起删除。 你将无法轻松地检索复制日志。 如果这些日志对你的记录很重要，请在取消预配前检索它们。
  2. 确保已迁移 StorSimple 物理设备，然后将其注销。 如果确定它们已迁移，请勿继续。 如果在这些资源仍是必需的情况下将其取消预配，则无法恢复数据或其配置。
    也可以先取消预配 StorSimple 卷资源，这会清除设备上的数据。 此过程可能需要几天的时间，不会对设备上的数据进行取证式清除。 如果这对你很重要，请按照策略独立于资源取消预配操作进行磁盘清除处理。
  3. 如果 StorSimple 设备管理器中没有剩余的已注册设备，则可以继续删除设备管理器资源本身。
  4. 现在可以在 Azure 中删除 StorSimple 存储帐户。 同样，在继续操作之前，请停下来确认迁移已完成，并且不会有任何内容和任何人员依赖于此数据。
  5. 从数据中心拔出 StorSimple 物理设备。
  6. 如果你拥有 StorSimple 设备，则可以自由地对其执行电脑回收操作。 如果设备是租用的，请通知出租人，在合适的情况下返回设备。

迁移已完成。

注意

仍有疑问或问题？
我们随时为你提供帮助：

故障排除

使用 StorSimple 数据管理器迁移服务时，整个迁移作业或单个文件都可能由于各种原因而失败。 文件保真度部分详细介绍了支持/不支持的场景。 下表列出了错误代码和错误详细信息，可能还会提供缓解方案。

作业级别错误

阶段 错误 详细信息/缓解措施
备份 找不到指定参数的备份 在“估计”或“复制”时没有找到为作业运行选择的备份。 确保备份仍然在 StorSimple 备份目录中。 有时，自动备份保留策略会在选择备份进行迁移和实际为此备份运行迁移作业之间删除备份。 考虑先禁用任何备份保留计划，再开始迁移。
估计
配置计算		 加密密钥安装失败 你的服务数据加密密钥不正确。 查看本文中的加密密钥部分了解更多详细信息并帮助检索正确的密钥。
批处理错误 启动执行迁移所需的所有内部基础结构可能会遇到问题。 此过程涉及多个其他服务。 当你再次尝试运行作业时，这些问题通常会自行解决。
StorSimple Manager 遇到了内部​​错误。 等候几分钟时间，并重试操作。 如果问题持续出现，请联系 Microsoft 支持。 （错误代码：1074161829） 此一般性错误有多种原因，但遇到的一种可能性是 StorSimple 设备管理器达到了 50 台设备的限制。 检查设备管理器中最近运行的作业是否突然开始失败，并出现此错误，这表明这就是问题所在。 此特定问题的缓解措施是删除数据管理器服务创建和使用的任何离线 StorSimple 8001 设备。 可以在门户中提交支持工单或手动删除它们。 请确保仅删除离线 8001 系列设备。
评估文件 克隆卷作业失败 此错误很可能表明你指定的备份由于某种不明原因损坏了。 迁移服务无法装载或读取它。 可以手动尝试备份或打开支持工单。
由于卷为非 NTFS 格式，因此无法继续 迁移服务只能使用未启用重复数据删除的 NTFS 卷。 如果卷的格式不同（例如 ReFS 或第三方格式），迁移服务将无法迁移此卷。 请参阅已知的限制部分。
请联系支持人员。 在磁盘上没有找到合适的分区 StorSimple 磁盘应该具有指定用于迁移的卷，但该卷似乎没有分区。 这是不寻常的，可能表明损坏或管理不当。 要进一步调查此问题就只能提交支持工单。
已超时 估计阶段因超时而失败通常是 StorSimple 设备或源卷备份速度缓慢甚至有时损坏的问题。 如果重新运行备份不起作用，则提交支持工单是最佳操作方案。
找不到文件 <路径>
找不到部分路径		 作业定义允许提供源子路径。 当该路径不存在时，会显示此错误。 例如：\Share1 > \Share\Share1
在本例中，你已指定 \Share1 为源中的子路径，映射到目标中的另一个子路径。 但是，源路径不存在（拼写错误？）。 注意：Windows 保留大小写，但与大小写无关。 这意味着指定 \Share1 和 \share1 是等效的。 此外：将自动创建不存在的目标路径。
该请求无权执行此操作 当源 StorSimple 存储帐户或具有 Azure 文件共享的目标存储帐户启用了防火墙设置时，会显示此错误。 必须允许流量通过公共终结点，而不是使用进一步防火墙规则来限制它。 否则，即使已授权，数据转换服务也无法访问任一存储帐户。 禁用任何防火墙规则并重新运行作业。
复制文件 所访问的帐户不支持 HTTP 在目标存储帐户上禁用 Internet 路由或使用 Microsoft 路由终结点。
指定共享已满 如果目标是高级 Azure 文件共享，请确保为共享预配了足够的容量。 临时超量预配是一种常见做法。

项目级别错误

在迁移作业运行的复制阶段，单个命名空间项目（文件和文件夹）可能会遇到错误。 下表列出了最常见的错误，可能的话还会建议缓解方案。

阶段 错误 缓解措施
复制 -2146233088
服务器繁忙。		 如果失败次数过多，请重新运行作业。 如果错误很少，可以尝试再次运行该作业，但通常手动复制失败项目会更快。 然后，通过跳到处理下一个备份来继续迁移。
-2146233088
无法在指定时间内完成操作。		 如果失败次数过多，请重新运行作业。 如果错误很少，可以尝试再次运行该作业，但通常手动复制失败项目会更快。 然后，通过跳到处理下一个备份来继续迁移。
上传超时或复制未开始 如果失败次数过多，请重新运行作业。 如果错误很少，可以尝试再次运行该作业，但通常手动复制失败项目会更快。 然后，通过跳到处理下一个备份来继续迁移。
-2146233029
操作已取消。		 如果失败次数过多，请重新运行作业。 如果错误很少，可以尝试再次运行该作业，但通常手动复制失败项目会更快。 然后，通过跳到处理下一个备份来继续迁移。
1920
系统无法访问该文件。		 这是迁移引擎遇到重解析点、链接或接合时的常见错误。 不支持。 无法复制这些类型的文件。 查看本文中的已知的限制部分和文件保真度部分。
-2147024891
拒绝访问		 此错误见于以无法在磁盘上访问的方式加密的文件。 可以从磁盘读取但仅具有加密内容的文件不受影响并且可以复制。 唯一的选项是手动复制这些文件。 可以通过装载受影响的卷并运行以下命令来查找此类项目：get-childitem <path> [-Recurse] -Force -ErrorAction SilentlyContinue | Where-Object {$_.Attributes -ge "Encrypted"} | format-list fullname, attributes
无效的 Win32 FileTime。 参数名称：fileTime 在这种情况下，可以访问该文件，但无法评估其复制，因为迁移引擎所依赖的时间戳已损坏或由应用程序以不正确的格式写入。 无法执行太多操作，因为无法更改备份中的时间戳。 如果保留此文件很重要，也许可以在最新版本（包含此文件的最后一个备份）上手动复制文件，修复时间戳，然后将其移动到目标 Azure 文件共享。 此选项无法缩放自如，但要在目标中至少保留一个版本的高价值文件可以选择该选项。
-2146232798
已关闭 Safe handle		 通常是暂时性错误。 如果失败次数过多，请重新运行作业。 如果错误很少，可以尝试再次运行该作业，但通常手动复制失败项目会更快。 然后，通过跳到处理下一个备份来继续迁移。
-2147024413
致命的设备硬件错误		 这是一个罕见的错误，报告的对象实际上不是物理设备，而是迁移服务使用的 8001 系列虚拟化设备。 设备遇到问题。 出现此错误的文件不会阻止迁移继续进行到下一次备份。 这使得你难以执行手动复制或重试包含出现此错误的文件的备份。 如果留下的文件很重要或者数量很多，可能需要重新启动迁移所有备份。 打开支持工单以进行进一步调查。
删除
（镜像清除）		 指定的目录不为空。 当迁移模式设置为“镜像”，并且从 Azure 文件共享中删除项目的过程遇到阻止其删除项目的问题时，会发生此错误。 删除仅在实时共享中发生，而不是从以前的快照中发生。 删除是必要的，因为受影响的文件不在当前备份中，因此必须在下一次快照之前从实时共享中删除。 有两个选项：选项 1：装载目标 Azure 文件共享并手动删除出现此错误的文件。 选项 2：可以忽略这些错误并继续处理下一个备份，并预期目标与源不同，并且有一些原始 StorSimple 备份中没有的额外项目。
错误的请求 此错误指示源文件具有某些无法复制到 Azure 文件共享的特征。 最值得注意的是，文件名中可能有不可见的控制字符，或者文件名或文件路径中可能有 1 个字节的双字节字符。 你可以使用复制日志获取路径名，将文件复制到临时位置，重命名路径以删除不受支持的字符，然后再次使用 robocopy 将路径名复制到 Azure 文件共享。 然后，可以通过跳到要处理的下一个备份来继续迁移。

后续步骤

  • 了解云分层策略的灵活性。
  • 在 Azure 文件共享上启用 Azure 备份，进行快照安排并定义备份保留计划。
  • 如果在 Azure 门户中看到某些文件始终未同步，请参阅故障排除指南以获取解决这些问题的步骤。