共计 4653 个字符，预计需要花费 12 分钟才能阅读完成。
丸趣 TV 小编给大家分享一下 Windows Azure 是什么，希望大家阅读完这篇文章之后都有所收获，下面让我们一起去探讨吧！
Windows Azure 是一个由微软数据中心提供的一个 Internet 级别的计算和服务平台。因为通过使用 Windows Azure, 微软会维护所有底层的操作系统、硬件、网络、存储资源并且会不断的更新这个平台，因此开发和系统管理人员不再需要为底层的软件和硬件基础构架操心。
由于 Windows Azure 和企业内平台有很大的区别。我们强烈推荐您在将程序迁移到云端之后，就像新部署程序时一样对程序进行功能和性能的测试。您需要在实现迁移的过程中考虑下述重要部分：
本篇主题的重点是 Windows Azure Cloud Services. 而关于将 SQL Server 迁移到 Windows Azure 虚拟机的初步指导，请参阅 Migrating with Windows Azure Virtual Machines。
构建验证测试环境
在将程序迁移到云端的时候，您必须知道如何测试和调试您的程序以便保证您的程序在云端和在本地一致。下述列表展示了您可以用于测试您的程序的方法：
Windows Azure Tools for Microsoft Visual Studio: 在您创建程序后，您可以使用计算和存储模拟器在本地对程序进行调试。这使得您可以在将程序发布到 Windows Azure 之前在本地开发程序。Windows Azure Tools for Microsoft Visual Studio 对 Visual Studio 2010 进行扩展使得额外添加的计算和扩展模拟器包含了 Windows Azure 的大部分功能，从而您可以在本地对程序进行测试。我们推荐您在功能测试的早期就进行这类测试。更多信息，请参阅:Windows Azure Tools for Microsoft Visual Studio。
SQL Server 数据工具: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 负载测试: 如果程序当前并不存在自动化测试框架，我们推荐您创建一个新的自动化测试框架并使用 Visual Studio 负载测试来模拟多用户负载。更多信息，请参阅:Using Visual Studio Load Tests in Windows Azure Roles。
同步数据库以减少转移时间
您应该尽量减少在测试、数据移动和生产之间的转换时间。将企业内部的数据上传到 Windows Azure 可能会需要数个小时甚至数天。您不会希望在这段时间内您的程序不可用。这也是为什么您需要一个减少停机时间的计划。注意转移时间意味着将企业内部程序迁移到 Windows Azure 的最终步骤所需的时间。在转移之前，看看哪些表中的数据在迁移过程中不改变而哪些表中的数据在迁移的过程中可能改变。对于静态数据来说，您不需要在转移时间内转移这部分数据，如果您不能确定某些特定表中的数据是否会在转移时间内改变，您应该在系统中添加将改变的数据迁移到云端的程序。我们还推荐您考虑是否所有企业内部的数据都需要迁移到云端才能使得在 Windows Azure 上的程序上线。如果您的程序只有部分数据存在云端就能上线，那就会大大减少停机时间。
但如果是程序在 Windows Azure 上线之前，云端数据需要和企业内部数据保持一致，那就考虑减少在转移时间内所转移的数据量。在某些情况下，可以在转移时间之前就先转移部分数据，在实际的转移时间内转移另外一部分数据。在这种情况下，您需要区分哪些数据是可以提前转移的，而哪部分数据需要在转移时间内转移，这样做的好处是允许您的程序在 Windows Azure 中上线的过程中因为只转移部分数据而减少停机时间，您可以使用下述方式在转移时间之前同步数据:
Windows Azure SQL Data Sync
Windows Azure SQL 数据同步服务提供了为 Windows Azure SQL Databases 同步数据的功能，这个服务目前有两个主要功能:
同步企业内部的 SQL Server 数据库和 Windows Azure SQL Database 实例之间的数据，使得企业内部和基于云端的程序可以使用相同的数据。
同步 Windows Azure SQL Database 实例之间的数据，被同步的实例可以在同一个数据中心，不同的数据中心，甚至是不同的区域。
对于下述情况，用 Windows Azure SQL 数据同步服务来同步企业内部数据库和 Windows Azure SQL Database 实例之间的数据是一个很好的选择:
您需要对程序进行并行测试。
在将企业内部的所有数据迁移到 Windows Azure 之前您的程序需要继续运行，在迁移之后将这部分改变的数据迁移到 Windows Azure。
在迁移到 Windows Azure 之前，您企业内部的程序需要继续运行，同时还需要减少停机时间。
程序同时使用了云端和企业内部数据库作为混合解决方案的。
值得注意的是，SQL Data 同步服务使用改变跟踪表用于跟踪被改变的表来使得这些改变的数据被同步。当使用 SQL 数据同步服务时，您必须为这个改变跟踪表预留空间。除此之外，您 *** 不要修改被同步表的表结构或是主键，除非您重新初始化同步组。但对于需要中介和实时数据同步的情况下 SQL Data 同步服务就不是那么理想了，更多信息，请参阅 SQL Data Sync。警告:SQL Data Sync 当前仅仅是预览版，仅仅是为了未来的版本收集反馈信息，所以不应该被用到生产环境中。
复制、镜像、事务日志传送
您可以使用复制、镜像、事务日志来将企业内部的一个 SQL Server 实例中的数据同步到另一个企业内部的 SQL Server 实例或是 Windows Azure 虚拟机上的实例。但是这些选项都不能将数据移入或移出 Windows Azure SQL Database 中。更多信息，请参阅:Replication and Log ShippingandDatabase Mirroring and Log Shipping。
自定义抽取、转换、装载 (ETL)
为了减少在转移时间内转移数据所需的时间，您应该尽量在转移时间之前尽可能多的转移数据。您可以使用自定义 ETL job 来将那些被改变的数据从企业内部的 SQL Server 转移到 Windows Azure 环境中。当从 SQL Server 2008 之后的版本中迁出数据时，我们推荐使用 CDC 功能来确保仅仅那些改变的数据从企业内部的数据库中转移到 Windows Azure SQL Database 实例中。更多关于 CDC 的信息，请参阅 BOL 上的 Track Data Changes。但对于那些没有 CDC 的数据库，您需要创建一个数据跟踪系统来追踪那些被迁移之后改变的数据。总之，在实际的转移时间迁移最小量的数据会大大减少停机时间。
导出数据层应用程序 (DAC)
通过 DAC, 您可以将 SQL Server 实例中的数据导出并将其存入 Windows Azure Blob 存储中并稍后还原到 Windows Azure SQL Database。通过 DAC，您可以设置只有需要的表被导入或导出的表级别过滤器，但无法设置行级别的过滤器。这也是为什么 DAC 适合整个表都在单独数据库中的情况而不适合联合数据库。DAC 还不适合需要实时同步的程序，更多信息，请在 BOL 中参阅 Export a Data-tier Application。
备份和还原
创建数据库备份是为了从管理错误、程序错误以及数据中心中出问题导致的数据丢失中进行还原。在 Windows Azure SQL Database 中备份和还原数据和在企业内部的 SQL Server 中并不一样，因此需要和可用的资源和工具共同使用。因此为了进行可靠的恢复而进行的备份还原 Windows Azure SQL Database 就需要一个的备份和还原策略。需要 Windows Azure SQL Database 进行数据恢复的场景主要分为下述三类:
基础构架和硬件失败: 数据中心可能出现硬件故障，比如说为您的数据提供 Windows Azure SQL Database 服务的硬件节点故障。
程序或用户所产生的问题和故障: 用户或程序有可能对数据产生意料之外的操作，这类操作需要进行恢复。比如说，某个用户错误的修改了一个客户的信息，等等。
数据中心设备损坏: 当前的 Windows Azure SQL Database 服务协议指定了在微软控制之外的原因比如说灾难发生所导致的问题是免责的。在灾难发生时，数据中心可能出现数据库无法从复制或是在线备份中恢复的损害。
最终您需要决定对于存储在 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 上的程序上线。
看完了这篇文章，相信你对“Windows Azure 是什么”有了一定的了解，如果想了解更多相关知识，欢迎关注丸趣 TV 行业资讯频道，感谢各位的阅读！
