存储迁移评估

在评估阶段，数据资产、依赖项以及数据的量和使用情况系统地列出清单。 此清单考虑了迁移前和迁移后状态中的数据。 每个数据集都根据性能、复原能力、安全性、成本和使用要求等因素进行分析。 这些属性有助于进行适当的评估和目标服务选择。

以下列表包含常见的库存和编录项目，以便识别和评估您的源数据。

盘点数据资产

1. 编录要迁移的所有 数据源 。 这些源包括用户数据、部门共享、文件共享、应用程序数据、内容管理系统和数据库。 它们还包括备份存档数据、虚拟机磁盘或存储在任何 SAN、NAS、DFS 或磁带存档中的数据。
2. 估计目录中每个数据源 的数据大小 （以 GB/TB/PB 为单位）。 包括大概的文件和对象数量。
3. 捕获目录结构的层次结构和深度。
4. 排下任何特殊属性，例如 保留文件名、 目录或文件长度、 长路径或涉及 的备用数据流 。
5. 记录当前和将来数据服务所涉及的 身份验证方法 。

标识数据类型和访问模式

1. 记录每个源的 数据类型 和 访问方法 以及 访问频率。
2. 确定文件级别、对象级别或块级别的 访问方法和协议 。 例如，文件级协议可能包括 SMB 或 NFS。 对象级协议可能包括 S3 或 REST API，块级协议可能包括 iSCSI、原始磁盘或附加到服务器的 LUN。
3. 记录此数据的应用程序依赖项，以便在迁移前后进行访问，以及迁移到 Azure 后使用哪些协议。
4. 捕获特定权限级别和 ACL、权限保留要求以及文件的任何特定功能支持，例如 基于访问的枚举 或 备用数据流。
5. 另请注意 访问模式- 顺序与随机;读/写比率
6. 如果考虑 合并或重组 数据，请在迁移到 Azure 存储时提及。

了解性能需求

1. 评估源与 Azure 之间的网络带宽和延迟
2. 记录源读取/写入性能或 IOPS 限制、吞吐量要求
3. 季节性或突发模式
4. 发现的源数据的外部和内部集成要求是什么

评估复制、更改率、弹性和停机时间容忍度

1. 确定数据 更改率 ，以了解数据更改的频率以及直接转换的可接受 停机时间 。 如果数据是静态的且不会更改，则可以接受一次性副本。 但是，主动更改的动态数据需要你规划增量同步和最终直接转换时段。
2. 就最终迁移的任何只读时间段达成一致，以避免错过更新。
3. 基于应用程序的可用性和复原需求，确定 SLA、RPO、RTO 要求。
4. 记录现有的数据保护、恢复和监视需求。
5. 记录任何复制策略，例如同步或异步的高可用性或灾难恢复策略。 另请注意（如适用）所有快照策略，例如频率和保留期。

此时，请考虑数据更改是否过于频繁，以及当前网络带宽是否可以在初始离线同步后支持差量数据更改。 是否有其他参数可以考虑此类系统和数据？

考虑安全性和合规性要求

1. 记录有关数据的任何 权限 和 ACL 。 确保迁移方法可以保留它们，或创建计划以在 Azure 中 重新应用 它们。
2. 计划对任何一定不能通过公共 Internet 传输的外部测试中的数据使用 ExpressRoute 或专用链接。
3. 请考虑 法规符合性 可能会规定特定的目标 Azure 区域，以满足数据驻留要求。 根据 安全性和合规性需求对数据进行分类，例如 审核 或 监管链。 如果要考虑脱机迁移，请查看并记录任何此类特定需求。
4. 概述必须审查和建立的关键 技术设计决策 ，以推进目标选择。
5. 考虑是否有任何系统即将进入生命周期结束。 尽管可能未迁移已弃用的系统，但系统数据可能需要存储一段时间才能满足法规遵从性。

在评估阶段结束时，应该有一个明确概述每个数据源要求的文档。 这些要求包括其当前和未来的需求，以及迁移到目标系统或服务后的特定要求集。 评估文档清楚地定义了目标系统中必须存在才能成功托管数据的功能。

另请参阅

• Azure Migrate 文档
• 合作伙伴评估工具
• 使用 Azure Data Box 进行脱机数据传输