导出 (0) 打印
全部展开

计划迁移到 Azure

更新时间: 2014年4月

当你开始规划迁移时,需要考虑几个关键因素,如成本、业务和技术要求、时间线以及迁移过程中需要的任何测试。此部分针对你在计划迁移到 Azure 时应考虑的若干问题和步骤提供演练。

作者:Steve Howard
审校:James Podgorski、Paolo Salvatori、Selcin Turkarslan、Stuart Ozer

成本是需要回答的最大问题之一。我们建议你在考虑将本地应用程序迁移到 Azure 时,在决策制定和规划过程的早期解决此问题。Azure 中应用程序的定价取决于若干因素,如网络通信流量负载、应用程序的输入/输出特性以及应用程序处理的数据量。计算价格不在本主题的范围之内。当你开始规划迁移时,建议你使用 Azure 定价计算器来帮助估计成本。你可以在此查找 Azure 定价计算器。

在计算组织的成本时,请记住加入开发和测试期间的 Azure 直接费用。在本地开发项目中,你需要针对开发和测试服务器付费。同样地,在 Azure 环境中,你需要对你在开发和测试过程中使用的资源付费。此外,你应计算培训和学习成本,以及与将应用程序移植到 Azure 关联的成本。我们建议你进行性能测试和容量规划,以提前评估应用程序需要多少容量。

Azure 可以很好地满足一些业务和技术要求。虽然以下列表并不详尽,但具有这些特点的应用程序是迁移到 Azure 的理想之选:

  • 分布式用户群:Azure 数据中心分布于几大洲。通过数据中心之间的互连,可以实现所需的高性能的数据分布。借助 Azure 功能(如内容分发网络 (CDN) 和数据同步服务),你可以在靠近最终用户的各数据中心之间分布式保留相关的或使用率较高的数据。让用户能够访问靠近其地理位置的数据中心可最大限度减少往返时间,进而优化用户体验。

  • 可变负载:你需要购买硬件来处理本地应用程序的峰值负载。例如,零售店通常购买服务器,以便能够处理节假日购物期间的负载。同样,会计部门可能规划附加的基础结构,以便能够处理月底或年底结算周期的峰值负载。在剩下的时间内,用于处理此类峰值负载的服务器处于未充分利用的状态。另一方面,针对弹性扩展而设计的应用程序可以利用 Azure,以使应用程序的新实例在高峰期保持在线,并在需求较低的期间内返回到较低水平的处理能力和容量。通过这种方式,借助经正确设计和管理的应用程序,Azure 使你只需对你需要的资源付费。

  • 多租户:对于服务提供商,Azure 允许你在同一基础结构上通过多种方法向任意数量的客户提供应用程序服务,从而最大限度地降低运营成本。

  • 需要将重点放在应用程序上:服务提供商尤其要将其资源集中于应用程序和功能的开发方面,这方面的投入应超出基础结构维护。Azure 可减少许多管理开销,而这些开销是承载本地或传统托管服务器应用程序的基础结构所必需的。它可让你将资源集中于应用程序和功能的开发方面。

  • 最大限度地减少基础结构资源要求:当你设计可充分利用 Azure 提供的弹性扩展的应用程序时,还可以根据需要分配角色实例和资源。这样,就不需要预先的硬件投资,也不需要维护服务器,因为服务器可以在利用率较低时期处理峰值负载。

除了具有传统平台面向服务的优势之外,Azure 还可以承载虚拟机。这些虚拟机可以运行任何支持 Azure 的操作系统,并且运行应用程序的方式与在本地运行一样。有关支持的操作系统的列表,请参阅 Azure 虚拟机概述。这些虚拟机也可以是较大应用程序体系结构的一部分,该体系结构可能包括 Web 角色或辅助角色的实例以及其他 Azure 组件。虚拟机是一种移植某些服务或应用程序某些部分的方法,如果没有虚拟机,它们可能无法轻松地移植到 Azure。有关详细信息,请参阅使用 Windows Azure 虚拟机进行迁移

在分析和设计阶段,应确定通过迁移到 Azure 给你带来最大好处的应用程序。然后,开始设计 Azure 实现以及实现计划。在此阶段,你应规划体系结构设计和时间线的轮廓。

规划的一些关键元素包括:

  • 确定当前面临的挑战:下面的列表显示了一些在规划任何体系结构的重新设计需要时应确定的挑战示例:

    • 在当前体系结构中的当前负载下,执行效果达不到标准的应用程序组件:例如,如果 SQL 查询的执行效果不令人满意,则应先进行优化,然后再进行迁移或进一步设计。还应重新设计和扩展任何应用程序层组件。

    • 确定弹性扩展要求:应确定如何将应用程序分解为可独立扩展的功能单元,而这些单元可以彼此独立地运行。

    • 非均匀负载模式:应确定不均匀的负载模式,并设计应用程序进行扩展以应对高峰时段。你应针对如何管理扩展水平(从高峰期到低需求期)制定相应的计划。

    • 增长预测:通常,首先警示 IT 部门可能需要更改范例的就是增长预测。决定在何处扩展可能是解决增长预测的一种方法。增长预测也可能是你需要考虑范例转变的一个指示器,例如,在以数据仓库为中心的应用程序中切换到某些大型数据分析范例。你应该在规划阶段讨论这些选项。请记住,此时你可能无法确切了解解决办法,直到以后进入设计和实施过程。你应列出此类突发事件和决定性因素,以便你可以在适当的时候评估它们,例如,在初始迁移过程中或晚些时候。

  • 确定技术要求:了解应用程序的每个组件在高峰期和非高峰期的要求。然后,为每个组件计划扩展。每个组件都可能采用不同的功能和机制来进行扩展。技术要求可能不仅仅体现在性能方面。例如,在规划迁移时,应确定高可用性和灾难恢复要求或最大网络延迟要求,并与 Azure 功能进行对比。下表说明了技术要求的一些示例:

    • 关系存储的使用:检查存储在关系数据库中的数据。其性质是真正事务性和关系型的数据或要求真正事务处理的数据应留在关系存储中。可以使用 Azure SQL Database (SQL Database) 或在虚拟机中运行的 SQL Server 存储此类型的数据。可以在 Azure 表、Azure Blob 存储或 Azure 驱动器中高效地存储其他类型的数据。我们建议你确定数据的每个部分所需的存储类型。

    • 选择关系数据存储:是选择 SQL Database 还是选择在 Azure 虚拟机中运行的 SQL Server,这一点取决于几个因素。如果你想要避免高可用性、负载平衡和透明故障转移的管理开销,SQL Database 是最好的选择。然而,对于迁移应用程序时的中间状态,或针对 SQL Database 中尚未提供某些功能的特殊情况,在 Azure 虚拟机中运行的 SQL Server 可能是最好的解决办法。这些问题的答案取决于具体情况和解决方案。下面的列表显示了有关这一点的一些注意事项:

      • 数据库大小:Azure SQL Database 目前对于 Web Edition Database 限于 5 GB 的数据,而对于 Business Edition Database 限于 150 GB 的数据。若要扩展数据库的容量,请使用向外扩展方法。若要了解 Azure 向外扩展方法,请阅读向外扩展 Windows Azure SQL Database。有关可用的数据库版本和大小的最新信息,请参阅 Azure SQL Database 帐户和计费

      • 数据库数目:默认情况下,SQL Database 支持每个订阅最多包含 6 台服务器,每台 SQL Database 服务器上最多包含 150 个数据库(包括 master 数据库)。可以扩展此限制。有关详细信息,请通过 Microsoft Online Services 客户门户与客户支持代表联系。

      • 跨数据库查询:SQL Database 目前不支持跨数据库联接或其他跨数据库查询。如果联合或联接要求数据来自 SQL Database 中的多个数据库,则必须在应用程序的应用程序层中执行该逻辑。

      • 公共语言运行时 (CLR) 对象:SQL Database 目前不支持 CLR 存储过程、聚合、触发器或函数。你应移植 Transact-SQL 中的存储过程、触发器或函数,以便在 SQL Database 上运行。在 TRANSACT-SQL 中无法在数据库级别执行的复杂逻辑或操作(如聚合)应移到应用程序层。你可以使用辅助角色来执行此类工作。

      • 数据类型:SQL Database 不支持 SQL Server 的某些系统数据类型。有关最新信息,请参阅 SQL MSDN 库中的数据类型 (Azure SQL Database)

      • 复制:复制类型(如事务复制或合并复制)在 SQL Database 中不可用。你可以在 Azure 虚拟机中运行的 SQL Server 中安装和运行它们。可以使用 SQL 数据同步在 SQL Database 实例之间同步数据。但在要求事务一致性或复杂冲突解决的情况下,SQL 数据同步服务可能不令人满意。警告:SQL 数据同步目前仅以预览版的形式提供,发行目的仅是为了获得针对将来版本的产品反馈,不应在生产环境中使用。

      • 全文搜索:Azure SQL Database 目前不支持全文搜索。如果你的应用程序针对 SQL Server 表中的字符数据运行全文查询,则你可能要考虑将数据库迁移到 Azure 虚拟机中的 SQL Server。有关 Azure 虚拟机中 SQL Server 的详细信息,请参阅迁移到 Azure 虚拟机中的 SQL Server

      • 许可:SQL Database 每月根据所选的数据库大小收费。当在 Azure 虚拟机中运行时,SQL Server 需要许可证。

      • 登录和安全性:Windows 身份验证(集成安全性)在 SQL Database 中不受支持,但它可用于 Azure 虚拟机中运行的 SQL Server。有关 SQL Database 的更多安全性指南和限制,请参阅Azure SQL Database 安全指导原则和限制

      • 功能同等:有关 SQL Server 与 SQL Database 之间的相似性和差异的详细信息,请参阅 SQL Database Overview

  • 登录和用户安全性:借助 Azure 中新增的网络增强功能,本地网络中的 Active Directory 域可以扩展到 Azure。有关详细信息,请参阅使用 Windows Azure 虚拟机进行迁移。有关 SQL Database 安全性管理的详细信息,请参阅在 Azure SQL Database 中管理数据库和登录名

  • 应用程序的功能分解:确定可在何处将应用程序分解为功能单元,使之可在单独的 Azure 角色或虚拟机中运行。你可以通过这样做来生成弹性扩展,此外,如果某些应用程序并不很适合云计算,则还可以考虑混合应用程序。

  • 支付卡行业 (PCI) 和其他法规要求:在将应用程序或组件移至 Azure 之前,检查所需证书或要求的当前状态。对于诸如 PCI 法规遵从性要求的情况,你可能要从迁移到 Azure 的项中删除应用程序和数据库的某些部分,并运行混合应用程序。这样,就可以在大多数组件上发挥 Azure 和云计算的优势;同时,对于数据和应用程序中需要实施严密的制度控制和法规遵从性的组成部分,你仍可以对其实现相应的监控。

  • 不能在 Azure 平台中托管的关键组件:由于其他一些问题,你可能无法在公有云中托管某些组件或某些类型的数据。确定这些组件,并考虑使用混合应用程序。借助混合体系结构,可以在 Azure 中承载某些组件,以实现 Azure 和云计算的完全优势。同时,对于数据和应用程序中需要实施严密的制度控制和法规遵从性的组成部分,你仍可以对其实现相应的监控。

一旦你定义了迁移的范围,迁移计划中每一步骤的工作量也就变得清楚了。查看每个应用程序和数据组件,并估计开发、测试和迁移所需的时间和资源。当对应用程序进行功能分解时,并行开发这些分解的组件,以生成弹性可扩展的组件。

在迁移计划中设置项目里程碑,如功能和性能测试以及发布日期。你的迁移可能会分为一系列步骤和迭代过程,因为不同的组件要针对 Azure 做好相应的准备,或者组件要准备好移到 Azure Web 角色和辅助角色。

当设置开发和迁移时间线时,应规划此时段内的增长,并决定必须对现有应用程序和基础架构执行的操作。这种规划使你能够运行你现有的系统,直到完成迁移。当制定此过渡计划时,应确定当前的难点并确定必须执行哪些操作才能继续运行,以及在过渡基础结构上可以继续执行哪些扩展操作。此外,还应确定继续操作可能需要的步骤。通常,这些步骤可能与优化 SQL 查询或添加 Web 服务器一样简单,具体取决于特定应用程序的特性。确定当增长超过预期或需求意外激增时的应变计划。当制定应变计划时,考虑是否可以通过扩展到 Azure 虚拟机来应对需求激增或增长,因为这可能使你能够在没有额外硬件投资的情况下处理好这些情况。

任何迁移计划都应包括全面的功能测试和负载测试计划。测试方法的说明是超出了本文的范围。下面的列表显示了一些在测试时要记住的关键点:

  • 自动执行测试脚本

  • 测试应用程序的所有层和组件

  • 测试表示你系统上的真实比率的活动比率

  • 测试最高预期利用率级别或更高的利用率级别

我们建议你包括生成和运行测试的时间,以及解决在测试过程中发现的问题的时间。

当你定义业务和技术需求时,应确定成功执行迁移所需的资源。你可能需要加入这些资源以执行迁移。在确定资源时,应考虑三个主要方面:

  • 人员:为了成功地迁移应用程序,你可能需要引进具有额外技能组合的其他员工。此外,在迁移后,技术人员的角色可能会改变,技能可能需要更新。例如,考虑管理登录、访问权限以及服务和扩展级别的帐户管理员和服务管理员的角色。

  • 工具:确定开发、测试和部署 Azure 应用程序所需的工具。有关详细信息,请参阅 Azure Tools for Microsoft Visual StudioAzure SQL Database 工具和实用工具支持

  • 咨询:要迁移应用程序,你可能需要有具体的专业知识。迁移专家可帮助你避免常见的问题,使你节省大量的时间和金钱。

对于较小的应用程序,Azure 管理门户可能足以胜任管理 Azure 部署的任务。通过 Azure 管理门户,你可以登录和管理部署以及应用程序,包括更改实例角色的数量和管理 SQL Database 实例。然而,对于复杂的应用程序和为客户提供服务的应用程序,Azure 管理门户可能并不足够。

Azure 公开 REST API,使你能够以编程方式管理在 Azure 中承载的应用程序和虚拟机,以及设置和使用 Azure 存储。你可以编写一个管理界面,以处理对 Azure 环境的扩展和监控。你的迁移计划应包括在迁移之后管理应用程序的计划,尤其是当这种管理要包括自定义接口或自动操作时。

有关用于管理 Azure 部署的 REST API 的详细信息,请参阅 Azure 的 API 参考

另请参阅

显示:
© 2014 Microsoft