导出 (0) 打印
全部展开

实施 Azure 的迁移计划

更新时间: 2014年4月

Azure 是 Microsoft 数据中心承载的一项 Internet 规模的计算和服务平台。借助 Azure,开发人员和管理员不需要实施基础软件和硬件基础结构,因为所有基础操作系统、硬件、网络、存储资源和平台更新均由 Microsoft 自动处理。

我们强烈建议你在将应用程序迁移到云中后,对应用程序运行功能测试和性能测试,就像对待任何新部署的应用程序一样。由于 Azure 不同于你的本地平台,因此你在实施迁移时必须考虑下列重要问题:

请注意,本主题的重点主要是 Azure 云服务。有关迁移 Azure 虚拟机中的 SQL Server 的初步指导,请参阅使用 Windows Azure 虚拟机进行迁移

作者:Kun Cheng、Steve Howard
供稿人:Selcin Turkarslan

在将应用程序迁移到云时,你必须知道如何测试和调试你的应用程序,以便可确保应用程序在云中按预期正常工作。以下是你可以用来测试应用程序的方法列表:

  • Azure Tools for Microsoft Visual Studio:可生成应用程序,然后使用 Azure Tools 中的部分计算和存储仿真程序,在本地运行并调试此应用程序。在将应用程序部署到 Azure 之前,这可让你开发本地应用程序。Azure Tools for Microsoft Visual Studio 扩展了 Visual Studio 2010,它使你能够使用计算和存储仿真程序测试你的应用程序,而仿真程序可提供 Azure 的大多数功能。我们建议你在功能测试的早期阶段执行这种类型的测试。有关详细信息,请参阅 Azure Tools for Microsoft Visual Studio

  • SQL Server Data Tools:SQL Server Data Tools (SSDT) 在 Visual Studio 2010 内提供了一个集成环境,你可以使用此集成环境来设计数据库、创建或编辑数据库对象和数据,或者针对所有支持的 SQL 平台执行查询;包括外部 Azure SQL Database 和本地 Microsoft SQL Server 2012。它使你能够通过检查应用程序的关系数据访问部分,使用本地默认数据库或 Azure SQL Database 测试数据库项目解决方案。有关详细信息,请参阅 SQL Server Data Tools注意:Azure Tools for Microsoft Visual Studio 和 SSDT 两者都使你能够对应用程序以及脱机和联机数据源执行基本功能和兼容性测试。若要测试实际云应用程序的功能、性能和可扩展性的所有方面,你需要在部署和运行该应用程序的 Azure 上执行一次模拟测试。

  • 自动测试框架:很多现有的应用程序已具有一个自动测试框架,可用来确保应用程序的所有组件或功能按预期方式工作。当应用程序在 Azure 上运行时,自动测试框架是否正常工作具体取决于它是如何设计的。如果自动测试框架需要从本地运行,但它可以通过使用已定义的端点连接到 Azure 上的应用程序,则它仍可能正常工作。否则,我们建议你在 Azure 上同时承载自动测试框架和你的应用程序,以减轻潜在的连接丢失和延迟问题。

  • Visual Studio Load Testing:如果应用程序不具备现有的自动测试框架,我们建议你创建一个新的自动测试框架,并使用 Visual Studio Load Testing 对多个并发用户执行仿真测试。

在测试、过渡与生产之间,应尽可能地将实际转换时间降至最少。要将一个大型数据库从本地复制到 Azure,可能需要数小时或数天时间。而且,在完全迁移现有数据的这段时间内,应用程序也不可能一直处于关闭状态。这就是为什么你必须具有一个计划,以最大限度地减少因转换而导致的停机时间。注意,转换指的是向 Azure 执行最终迁移所需的时间。在转换之前,先查看你的表并确定哪些表包含静态数据,哪些表包含在转换期间可能发生变化的数据。对于静态数据,在转换时不需要移动任何数据。但是,如果你对某一特定表中的数据在转换过程中是否可能更改存有任何疑虑,则应在你的系统中包含在事后迁移所有更改的逻辑。我们还建议你考虑是否需要在应用程序于 Azure 中正常运行之前,将本地系统中的所有数据迁移到云中。如果你的应用程序可以正常运行,并允许稍后获取数据,则可以消除任何停机时间。

不过,如果应用程序在 Azure 中正常运行之前,Azure 中的数据必须与本地数据一致,则考虑尽量减少在转换时必须迁移的数据量,因为这有助于最大限度地缩短实际转换所需的停机时间。在某些情况下,这种情况可能适用于在转换之前迁移一些数据,然后在实际转换之后迁移剩余的数据。在此类情况下,你的迁移计划应明确地指明必须首先迁移的数据以及可以在转换后迁移的剩余数据。这样,你的应用程序在 Azure 上进入正常运行状态所需的停机时间就会减少,因为你可以在应用程序处于生产状态时迁移剩余数据。你可以使用以下数据同步方法在转换之前执行数据迁移:

SQL 数据同步(预览版)服务为 SQL Database(SQL Server 和 SQL Database)提供数据同步功能。该服务目前具有两个主要功能:

  • 本地 SQL Server 数据库和 SQL Database 实例之间数据的同步,允许本地应用程序和基于云的应用程序利用相同的数据。

  • 两个或更多 SQL Database 实例之间数据的同步;这些实例可以位于相同的数据中心、不同的数据中心或不同的区域。

SQL 数据同步(预览版)对于在下列情况下同步本地数据库和 SQL Database 实例是一个很好的选项:

  • 你需要对应用程序执行并行测试。

  • 你需要在将所有本地数据操作最终迁移到 之前,并行运行应用程序。

  • 在迁移到 时,你需要在本地运行应用程序,同时需要确保停机时间最短。

  • 你需要执行连续的数据同步,以作为本地和 应用程序之间的混合解决方案的一部分。

请注意,为了跟踪增量数据更改,在配置同步组后,SQL 数据同步(预览版)将为正在同步的所有表添加更改跟踪表。使用 SQL 数据同步(预览版)时,确保你的空间计划考虑了更改跟踪表的因素。此外,对于设置同步之后正在同步的表,你不应对其表结构或主键进行更改,除非你重新初始化同步组。SQL 数据同步(预览版)对于需要中间或持续数据同步的情况不是最佳选择。

警告: SQL 数据同步(预览版)目前仅以预览版的形式提供,仅用于提供对将来版本的产品反馈,不应该用于生产环境中。

有关 SQL 数据同步(预览版)的详细信息,请参阅 SQL 数据同步(预览版)

你可以使用复制、镜像或日志传送,将数据从本地 SQL Server 移到其他本地 SQL Server 或在 Azure 虚拟机中运行的 SQL Server 实例。但是,你不能使用它们将数据移入或移出 Azure SQL Database。有关详细信息,请参阅复制和日志传送数据库镜像和日志传送

为最大限度地减少在转换时传输数据所需的时间,应在实际转换之前将尽可能多的数据移到 Azure 平台。你可以创建一个自定义 ETL 作业,以将更改的数据从本地系统移到 Azure 环境。当从本地 SQL Server 2008 或更高版本进行迁移时,我们建议使用变更数据捕获或变更数据跟踪,以确保所有已更改的数据且只有已更改的数据实际从本地数据库移到 Azure SQL Database 实例。有关这两项功能的详细信息,请参阅 SQL Server 联机丛书中的跟踪数据更改。对于不使用变更数据捕获或变更数据跟踪的数据库,你需要为你的更改和已迁移的数据创建一个跟踪系统。在所有情况下,在实际转换时使要移动的数据达到最少,这是最大限度地减少实际转换所需停机时间的关键。

使用 DAC 可以从 SQL Server 实例中导出数据,并将它放入 Azure Blob 存储,从中可以将其导入 Azure SQL Database。使用 DAC,你可以设置筛选器来筛选应导入或导出哪些表。但是,你不能设置行级筛选器。这就是 DAC 适合以下情况的原因:整个表适合位于单一数据库中,但对于向外扩展的数据库则效果不佳。DAC 对于需要持续数据同步的应用程序不是用于迁移数据的理想之选。有关详细信息,请参阅 SQL Server 联机丛书中的导出数据层应用程序

创建数据库备份的目的是使你能够从因管理错误、应用程序错误或数据中心重大损失而导致的数据丢失中得以恢复。在 Azure SQL Database 中备份和还原数据不同于本地 SQL Server,并且必须使用可用的资源和工具。因此,可靠地使用备份和还原以实现恢复需要有一个 Azure SQL Database 备份和还原策略。可能需要对 Azure SQL Database 实例执行恢复的问题分为以下三类:

  • 基础结构或硬件故障:数据中心内可能会发生硬件故障。例如,运行你的 Azure SQL Database 实例的物理节点可能崩溃。

  • 应用程序或用户生成的问题或故障:用户或应用程序可能会意外地对数据进行更改。这可能需要还原操作。例如,用户可能会修改属于不合适的客户的某些数据等。

  • 数据中心设施的丢失:当前 Azure SQL Database 服务级别协议专门针对 Microsoft 合理控制范围之外的因素(如灾难)规定了例外条款。在发生灾难的情况下,数据中心可能被损坏,导致无法从副本或现场备份中恢复数据库。

最终,你需要针对存储在 Azure SQL Database 数据中心内的数据,确定你愿意承受的风险级别。有关可用的备份和恢复工具以及如何围绕它们制订灾难恢复策略的详细信息,请参阅 MSDN 库中的文章 Azure SQL Database 业务连续性

当你执行将应用程序实际迁移到 Azure 的过程时,你可以按照以下方法操作:

  • 并行运行:使用此方法,你的应用程序可以同时在本地和 Azure 中并行运行。这样,你可以在你的应用程序变得完全依赖于云之前,在 Azure 中对你的应用程序执行实时测试。你的测试应包括但不限于以下项:功能测试、性能测试和可伸缩性测试。当你在 Azure 上完成对新系统的全面测试后,执行最终数据迁移,然后务必关闭本地系统。

  • 暂停和转换:如果所有数据在 Azure 上完全正常生效之前需要先进行同步,则这种方法很适合。使用这种方法,应首先在 Azure 上完成所有功能测试和性能测试。然后,对系统进行设置,使用上面指定的数据同步方法之一将数据复制到 Azure 环境。我们建议通过最大限度地减少在最终转换之前执行最后一次同步或 ETL 操作所需的时间量,使数据尽可能保持接近同步状态。当转换到 Azure 的时机成熟时,请关闭本地系统,执行最后一次数据同步,然后在 Azure 上运行你的应用程序。

另请参阅

Microsoft 正在进行一项网上调查,以了解您对 MSDN 网站的意见。 如果您选择参加,我们将会在您离开 MSDN 网站时向您显示该网上调查。

是否要参加?
显示:
© 2014 Microsoft