导出 (0) 打印
全部展开
此主题尚未评级 - 评价此主题

实施 Windows Azure 的迁移计划

更新时间: 2013年12月

注:本页面内容可能不完全适用中国大陆地区运营的 Windows Azure服务。如要了解不同地区 Windows Azure 服务的差异, 请参考本网站.

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

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

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

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

设置验证测试

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

  • Windows Azure Tools for Microsoft Visual Studio:您可以构建应用程序,然后可以使用作为 Windows Azure Tools 的一部分提供的计算和存储仿真程序在本地运行并调试此应用程序。这样,您就可以先在本地开发应用程序,然后将其发布到 Windows Azure。Windows Azure Tools for Microsoft Visual Studio 扩展了 Visual Studio 2010,它使您能够使用计算和存储仿真程序测试您的应用程序,而仿真程序可提供 Windows Azure 的大多数功能。我们建议您在功能测试的早期阶段执行这种类型的测试。有关详细信息,请参阅 Windows Azure Tools for Microsoft Visual Studio

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

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

  • Visual Studio Load Testing:如果应用程序不具备现有的自动测试框架,我们建议您创建一个新的自动测试框架,并使用 Visual Studio Load Testing 对多个并发用户执行仿真测试。有关详细信息,请参阅Using Visual Studio Load Tests in Windows Azure Roles

同步数据库,以最大限度地减少转换时间

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

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

Windows Azure SQL 数据同步

Windows Azure SQL 数据同步服务为 Windows Azure SQL Database 提供数据同步功能。该服务目前具有两个主要功能:

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

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

Windows Azure SQL 数据同步对于在下列情况下同步内部数据库和 Windows Azure SQL Database 实例是一个很好的选项:

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

  • 您需要在将所有内部数据操作最终移动到 Windows Azure 之前,并行运行应用程序。

  • 在迁移到 Windows Azure 时,您需要在内部运行应用程序,同时需要确保停机时间达到最短。

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

请注意,为了跟踪增量数据更改,SQL 数据同步针对配置同步时正在同步的每个表添加更改跟踪表。当使用 SQL 数据同步时,您必须计划为旨在保持数据同步的更改跟踪表留出空间。此外,对于设置同步之后正在同步的表,您不应对其表结构或主键进行更改,除非您重新初始化同步组。SQL 数据同步对于需要中间或持续数据同步的情况不是理想之选。有关详细信息,请参阅 SQL Data Sync警告:SQL 数据同步目前仅以预览版的形式提供,发行目的仅是为了获得针对将来版本的产品反馈,并且不应在生产环境中使用。

复制、镜像或日志传送

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

自定义提取转换和加载 (ETL)

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

导出数据层应用程序 (DAC)

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

备份和还原

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

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

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

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

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

转换到 Windows Azure

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

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

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

另请参见

本文是否对您有所帮助?
(1500 个剩余字符)
感谢您的反馈

社区附加资源

添加
显示:
© 2014 Microsoft. 版权所有。