你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
评估阶段可确保在迁移到 Azure 之前完全了解每个组件、依赖项和要求。 通过收集有关体系结构、性能、安全性、代码和数据库的详细信息,可以预测问题、最小化风险并做出明智的迁移决策。
| 工作负荷类型 | 发现工具 | 评估工具 | Examples |
|---|---|---|---|
| On-premises | Azure Migrate | • Azure Migrate • Dr Migrate |
• 物理服务器 • VMware VM • Hyper-V VM • SQL 数据库 • Web 应用程序 |
| AWS 基础结构 (IaaS) | Azure Migrate | • Azure Migrate • AWS 到 Azure 指南 |
• AWS EC2 实例 • AWS RDS 数据库 • AWS EBS 卷 |
| Google 云基础结构 (IaaS) | Azure Migrate | • Azure Migrate • Google Cloud 到 Azure 迁移指南 |
• Google 云计算引擎 VM • Google Cloud SQL • Google Cloud Persistent Disk |
| AWS 平台服务 (PaaS) | AWS 资源浏览器 | • AWS 到 Azure 的迁移指南 • AWS 和 Azure 服务比较 • Cloudockit |
• AWS Lambda • AWS Elastic Beanstalk • AWS DynamoDB |
| Google 云平台服务 (PaaS) | Google 云资产清单 | • Google Cloud 到 Azure 指南 • Google Cloud 和 Azure 服务比较 • Cloudockit |
• Google Cloud BigQuery • Google Cloud App Engine • Google Cloud Run Functions |
| 应用程序代码 | CAST 突出显示 | • AppCAT • Dr Migrate • CloudPilot • CAST 突出显示 • CloudAtlas |
• GitHub • Azure Repos • GitLab |
评估工作负荷体系结构
完整的体系结构评估可了解所有工作负荷组件及其交互方式。 这通过确定需要一起移动的内容以及可能需要修改的内容,从而支持准确的迁移规划。
使用评估工具。 Azure Migrate 或其他产品等工具可自动发现工作负荷组件和配置。 这些工具可减少手动工作,并在整个环境中提供一致的数据收集,尽管它们可能错过未记录的依赖项。 可以使用 Cloudockit 等工具来生成图表。 您还可以使用 Azure 图标 或调整 Azure 体系结构中心中可下载的图形来创建自己的图表。
使用主题专业知识验证体系结构。 工作负荷所有者可以确认工具发现并确定缺失或过时的信息。 进行面试或体系结构评审会议,以缩小自动发现数据中的差距。
文档体系结构。 以支持规划和验证的格式存储体系结构关系图、组件列表和配置数据。 使用Microsoft Visio、电子表格或 Azure DevOps wiki 等工具来维护此信息。
评估工作负荷组件
对于每个工作负荷,请从当前环境收集详细的基线性能和使用情况指标。 此数据对于正确调整 Azure 资源的大小以及迁移后的性能进行比较至关重要
收集工作负荷指标。 跟踪 CPU 使用率、内存使用率、磁盘 I/O(读取/写入、IOPS)、网络吞吐量以及峰值并发或用户负载。 确定每日或每周高峰,以了解容量需求。 测量用户事务的平均响应时间、每小时处理的作业吞吐量以及任何与 SLA 相关的指标。 这有助于确保迁移的工作负载满足相同的业务性能要求。
捕获配置细节。 请注意缩放配置、当前 VM 大小或物理服务器规格(CPU 核心、RAM)、OS 类型和版本、存储类型(SSD/HDD)和容量,以及任何特殊硬件(如 GPU)。 这些详细信息用于指导选择 Azure VM 大小或 PaaS 服务。 此外,记录软件许可信息,因为这可能会允许使用 Azure 混合权益或需要许可证迁移。
记录所有安全和标识配置。 清点所有安全和标识配置:列出服务帐户、任何硬编码凭据、使用的加密方法和防火墙规则。 必须在 Azure 中复制或调整这些配置。
安全组件 Action Purpose 标识清单 记录应用程序用于身份验证的所有服务帐户、用户帐户和 API 密钥 在直接迁移或现代化方法之间进行选择时,会影响迁移排序 加密文档 记录静态数据和传输中数据的当前加密方法。 将这些要求映射到 Azure 加密服务以维护安全标准 网络安全配置 捕获网络安全规则、防火墙配置和访问控制列表 使用此信息设计 Azure 网络安全组和访问策略 确定兼容性问题。 自动化工具针对 Azure 支持策略提供对作系统、中间件和应用程序框架的系统分析。 这些工具标记不支持、弃用或即将结束支持组件。 Azure Migrate 和其他评估工具等工具可以在环境中检测这些问题,而无需手动配置评审。
列出所需的修正。 创建所有兼容性问题及其修正要求的综合列表。 优先处理那些必须在迁移前完成的问题(阻断项),其余可在迁移后解决。 如有必要,请与供应商联系以了解商业软件的升级路径。
映射内部和外部依赖项
绘制内部依赖关系图。 绘制工作负荷内各组件之间及与组织内其他系统之间的通信方式。 使用网络监视工具或应用程序性能监视查看服务之间的运行时连接。 此映射有助于确定迁移波中的分组。 例如,如果应用 A 不断调用数据库 B,则可以将它们一起迁移或提供 Azure 与源环境之间的网络连接,直到两者都在云中。
标识所有外部依赖项。 列出工作负荷与之交互的任何外部服务。 这些依赖项包括 SaaS 平台、合作伙伴 API、本地系统和应用程序需要正常运行的第三方服务。 必须对所有上游和下游集成、共享服务和数据管道进行编录,才能了解完整的依赖项环境。 文档 API、消息系统、ETL 进程、共享数据库、身份验证方法、数据交换模式和服务级别协议。 查看集成文档并接受应用程序所有者的采访,以确保对所有外部连接的完整可见性。 此全面的映射可防止集成失败,并支持准确的迁移排序。
让工作负荷所有者验证和完成依赖项数据。 工作负荷所有者提供对系统行为、共享资源和工具可能无法检测到的非正式集成的关键见解。 你必须与应用程序和工作负荷所有者进行结构化的面试或研讨会,以验证工具生成的数据并识别未记录的依赖项。 此步骤可确保依赖项映射的完整性和准确性,并帮助捕获通知迁移排序的业务上下文。
记录中央存储库中的所有依赖项。 以支持跨团队协作和迁移规划的格式存储依赖项数据,例如电子表格、体系结构关系图或依赖项映射工具。 确保存储库可访问并定期更新,以反映迁移过程中的更改。
使用依赖项规划迁移。 将工作负荷组织到迁移波中,以最大程度地减少损坏的依赖项。有关详细信息,请参阅 迁移波规划。
评估合规性和运营要求
确定法规合规性要求。 明确了解法规符合性要求,可确保 Azure 体系结构符合法律、行业和组织义务。 这些要求会影响区域选择、服务可用性、数据保护和体系结构决策。 法规和合规性标准包括全球、区域、行业特定和内部策略。 这些标准可能包括 GDPR、HIPAA、FedRAMP、ISO 27001 或 SOX 等财务法规。 每个标准都对数据处理、访问控制、加密和可审核性施加了特定的要求。 必须通过咨询法律、合规性和安全利益干系人来确定每个工作负载的所有适用标准。
记录 SLA、RPO 和 RTO。 服务级别协议(SLA)、恢复点目标(RPO)和恢复时间目标(RTO)定义了可接受的可用性和数据丢失级别。 这些指标指导备份、复制和故障转移策略的设计。 必须记录每个工作负荷的这些值,以确保体系结构符合业务连续性预期。 请参阅 “定义可靠性要求”。
对每个工作负荷环境进行分类。 工作负荷通常在生产、测试或开发环境中运行。 每个环境都有不同的可用性、安全性和性能要求。 必须记录每个工作负荷的环境分类,以通知迁移排序、访问控制和资源分配。
验证 ISV 与 Azure 的集成。 许多工作负荷依赖于来自独立软件供应商(ISV)的软件。 在迁移之前,必须确认所有 ISV 软件都与 Azure 兼容。 使用供应商文档、测试环境或直接与 ISV 验证。 确定任何所需的更新、替换或配置更改。 此外,确定 Azure 混合权益或其他许可模型是否适用。 在迁移计划中包括许可成本和兼容性调整,以便进行准确的预算和计划。
评估应用程序代码
应用程序代码评估可识别可能影响迁移成功的兼容性问题和现代化机会。 此评估对于确保应用程序在 Azure 中可靠运行并有效地规划迁移波至关重要。 必须评估应用程序代码,以便尽早检测阻止程序,降低迁移失败的风险,并通知目标体系结构决策。
使用自动化工具评估应用程序代码
将 AppCAT 用于 .NET 和 Java 应用程序。AppCAT 为 .NET 和 Java 工作负载提供详细的评估。 此工具可识别已弃用的 API、不支持的 SDK 以及可能阻止成功迁移的配置问题。 使用 AppCAT 为这些工作负载生成兼容性和现代化建议。
将第三方工具用于其他应用程序语言。 CloudPilot 和 CAST Highlight 等工具支持 Python、JavaScript、Node.js和 Go 等语言。 这些工具标识 Azure 兼容性所需的代码级更改并提供现代化见解。 使用这些工具评估 non-.NET 和非 Java 工作负载。
使用评估结果通知目标体系结构决策。 应用程序兼容性发现可能会影响 Azure 服务的选择。 例如,与一个服务不兼容的应用程序可能与另一个服务兼容,且代码更改最少。 使用此灵活性可以更快地迁移应用程序,并将代码现代化推迟到更高阶段。 此方法可降低迁移风险并缩短云到云的时间。
验证框架和 SDK 兼容性
了解代码兼容性。 框架和 SDK 兼容性可确保应用程序在 Azure 中可靠运行。 不支持的版本或不兼容的 SDK 可能会导致运行时失败或需要大量返工。 必须验证 Azure 是否支持应用程序的语言版本和框架。
检查 Azure 对应用程序的语言和框架的支持。 确认 Azure 支持 .NET、Java、Python、JavaScript、Node.js和 Go 版本。 使用官方 Azure 文档验证兼容性。
避免不必要的框架更改。 如果存在强大的业务理由,则仅迁移到新框架(如 .NET Framework 到 .NET Core)。 框架更改需要大量的开发工作和测试。
评估数据库
数据库依赖项通常确定应用程序迁移的成功。 共享数据库、跨应用程序依赖项和集成模式可能会使迁移规划复杂化。 必须评估支持应用程序并了解其依赖项的数据库。 遵循以下指南:
标识应用程序使用的所有数据库。 创建应用程序使用的所有数据库的完整清单。 包括数据库引擎类型(SQL Server、MySQL)、版本和托管模型(例如本地、IaaS、PaaS)。 使用 Azure Migrate 等工具系统地收集此信息。 指定数据库是自承载的、托管在虚拟机上还是作为托管服务传递。 此信息有助于确定迁移准备情况和目标平台兼容性。
映射入站和出站依赖关系。 清楚地了解数据流入和流出每个数据库对于排序迁移和避免服务中断至关重要。 依赖项通常跨越多个应用程序、服务和外部系统。 包括内部应用程序、API、批处理作业、报告工具和其他集成。 指定依赖项是只读的、只写的还是双向的。 此详细信息有助于确定工作负荷的优先级,并确定潜在的迁移阻止程序。
确定数据库迁移策略。 确定是将数据库移动为共享实例还是按工作负荷拆分数据库。 共享数据库简化了管理,但如果多个应用程序依赖于它们,则可能会延迟迁移。 拆分数据库可实现独立的迁移,但需要仔细协调和测试。 确保数据库迁移计划支持对应用程序移动进行排序,并最大程度地减少停机时间或服务中断。
创建和维护风险注册
风险寄存器是用于识别、评估、确定优先级和监视可能影响云采用的潜在风险的文档或工具,并概述了缓解策略。 维护此记录可确保风险管理的主动性。
为所有工作负荷建立风险注册。 记录与技术、运营和组织因素相关的风险。 此寄存器提供潜在障碍因素及其值的可见性。
定义缓解策略并跟踪其状态。 对于每个风险,记录缓解作、责任方和解决时间线。 此跟踪可确保主动管理和解决风险。
有关详细信息,请参阅 CAF Govern - 评估云风险
Azure 资源和工具
| Category | Tool | Description |
|---|---|---|
| 发现和评估 | Azure Migrate | 针对本地服务器、数据库和应用程序的全面发现和评估 |
| 已启用 Arc 的服务器 | Azure Arc | 将 Azure 管理扩展到本地和多云环境 |
| 代码评估 | AppCAT | .NET 和 Java 应用程序的自动兼容性分析 |
| 数据库迁移 | 数据迁移助手 | SQL Server 数据库的评估和迁移工具 |
| 多云映射 | AWS 到 Azure 服务映射 | AWS 到 Azure 迁移的服务比较指南 |
| 多云映射 | Google Cloud 到 Azure 服务映射 | Google Cloud 到 Azure 迁移的服务比较指南 |
| Azure 开发 | Azure 上的 .NET | 从 .NET 应用程序访问 Azure 服务的指南 |
| Azure 开发 | Azure 上的 Java | 适用于在 Azure 上构建的 Java 开发人员的资源 |
| Azure 开发 | Azure 上的 Python | 为在 Azure 上构建的 Python 开发人员提供的资源 |
| Azure 开发 | Azure 上的 JavaScript 和 Node.js | Azure 上的 JavaScript 和 Node.js 开发指南 |
| Azure 开发 | 转到 Azure | 为在 Azure 上进行开发的 Go 开发人员提供的资源 |
| 云采用框架 | 定义可靠性要求 | 有关定义云工作负载可靠性要求的指导 |