在 Windows Azure 虚拟机上运行 SQL Server 工作负荷的十大注意事项

我们在2012 年 6 月宣布公开发布 Windows Azure 虚拟机和虚拟网络（我们将这两个服务集称为 Windows Azure 基础结构服务）预览版，此后世界各地的组织都开始测试它们的 Microsoft SQL Server 工作负荷，并最大限度地利用该预览版的功能。Windows Azure 基础结构服务的功能简直令人不可思议。您无需购买和管理硬件，即可以较低成本快速部署能够运行多种不同类型的 SQL Server 工作负荷的虚拟机 (VM)，这一功能具有广泛吸引力。在虚拟网络中进行复杂的多 VM 部署的能力、支持 Active Directory (AD) 和SharePoint，以及使用虚拟专用网络 (VPN) 网关将虚拟网络连接回内部部署网络或远程计算机的能力，使 Windows Azure 基础结构服务成为对 IT 商店和开发人员来说更加有趣的远程托管环境。Windows Azure 基础结构服务是一块垫脚石，各个组织可以使用它将现有的一些工作负荷原样迁移到云，不会发生任何变化，同时以混合方式利用 Windows Azure 更加先进的“平台即服务”功能。我们看到很多组织都事无巨细地处理着所有的事情，包括从简单的开发到测试 SQL Server 的工作负荷，再到复杂的分布式关键业务工作负荷。从他们的经验中，我们总结了下面几点。

1. 了解您的 SLA：
   在拔去服务器的电源插头并将 SQL Server 工作负荷迁移到 Windows Azure 之前，您需要了解相关的服务级别协议 (SLA)。请注意这样的表述：“对于在同一可用性集内部署了两个或两个以上实例的所有面向 Internet 的虚拟机，我们保证您在至少 99.95% 的时间可以使用外部连接。”这对于 SQL Server 来说意味着什么？这就是说，为了达到该 SLA 的覆盖范围，您需要部署一个以上运行 SQL     Server 的 VM，并将这些 VM 都添加到同一个可用性集。有关详细信息，请参阅管理虚拟机的可用性。这还表示，如果您要确保数据库在可用性集内的所有虚拟机之间保持同步，您需要实施SQL Server高可用性解决方案。最基本的前提是您需要执行一些操作来确保云中的高可用性，就像这些工作负荷在本地运行时一样。正确配置后，可用性集可以确保您的 SQL Server 工作负荷即使在执行升级和硬件更新等维护操作时也可以保持运行。
    
2. 了解您的支持策略：
   在 Windows Azure 虚拟机中运行 SQL Server 的美妙之处就在于，它就跟在其他地方运行 SQL     Server 一样。它可以一如既往地运行。您无需更改应用程序，也无需担心各项 SQL Server 功能是否受支持。当SQL Server在 Windows Azure 基础结构服务中运行时，除了一些主要例外情况，绝大多数功能都完全受支持。让我们从 SQL Server 版本支持开始。Microsoft 为 Windows Azure 基础结构服务中的 SQL Server 2008 及更高版本提供技术支持。如果您仍然在 SQL Server 2005 或更低版本中运行工作负荷，那么您需要升级到更新版本才能获得技术支持。如果您准备升级，我们建议您升级到 SQL Server 2012。在管理工具、开发工具和基础数据库引擎方面，SQL Server 2012 均设计为具有 Windows Azure 内置支持的“云就绪”软件。
       
        我们先来谈谈高可用性。如果您觉得自己无需为     Windows Azure 基础结构服务中的 SQL Server 部署实施高可用性解决方案而操心，那么现在应该重新考虑这个问题了。如前面所说，为了达到 SLA 的覆盖范围，您需要在虚拟机可用性集内实施数据库冗余。但是以下限制会影响 SQL Server 高可用性功能。首先，不支持SQL Server故障转移群集。但是不用紧张，如果您希望为SQL Server配置高可用性， 还有很多其他选项可供您选择。例如AlwaysOn可用性组，或者使用诸如数据库镜像或日志传送等旧功能。我们建议您使用 SQL Server 2012 中的 AlwaysOn 可用性组功能以实现高可用性，但使用该方法时，有几点需要注意。当前不支持可用性组侦听器，但是我们计划在不久的将来增加此支持，敬请关注。如果您等不及侦听器支持，而仍然希望使用 AlwaysOn 可用性组，那么有一个解决方法。您可以使用 FailoverPartner 连接字符串属性代替。您应该意识到该方法将限制您在 AlwaysOn 可用性组中只能使用两个副本（一个主副本和一个辅助副本），并且不支持可读取的辅助副本的概念。有关更多信息，请参阅将客户端连接到数据库镜像会话。
       
        接下来我们谈谈为 SQL Server 数据库配置存储时需要考虑的一些重要事项。通常，我们建议您向 VM 附加一个数据磁盘，使用该磁盘存储所有数据和日志文件。如果您决定跨多个数据磁盘扩展数据和日志文件，以获得更多存储容量或更好的性能，那么您不应启用跨地域冗余。跨地域冗余无法与多磁盘配置配合使用，因为它无法保证各个磁盘之间一致的写入顺序。
       
        最后我们要讨论的是 SQL Server 支持的各种“分布式”功能，例如复制、服务代理、分布式事务、分布式查询和链接服务器等。所有这些功能在同一个虚拟网络内部署的 SQL Server VM 中应运行良好，但是，如果需要跨越网络边界（跨公共 Internet 或虚拟网络 VPN 网关），您最好对这些功能进行彻底测试。这些功能设计用于内部部署的数据中心，包括 LAN 和 WAN，而非跨公共 Internet。
       
        要了解更多详细信息，请花一些时间阅读在硬件虚拟化环境中运行的 Microsoft SQL Server产品的支持策略。
    
3. 了解您的许可：
   为 Windows Azure 基础结构服务中的 SQL Server 部署授予许可的首选方法（最简单的方法）是使用镜像库中的一个预构建 SQL Server 平台映像创建一台新的虚拟机。使用该方法，您将按小时付费，具体取决于您选择的 SQL Server 版本（企业版、标准版或 Web 版）。无需担心产品密钥、激活等问题，并且您在几分钟内就可以访问新配置的 SQL Server VM。注意，将按分钟收取费用，并且没有最低限制。有关更多信息，请参阅在 Windows Azure上配置 SQL Server 虚拟机。Microsoft 不会查看 VM 内部的数据，因此，即使从使用平台映像置备的 VM 卸载 SQL Server，您仍将需要为 SQL Server 的使用付费，除非您删除该 VM。
       
        第二种方法是“使用您自己的 VM”。这将涉及在内部部署中构建自己的     Hyper-V VM、在这些 VM 上安装 SQL Server，然后将它们上传到 Windows Azure。有关如何执行该操作的指南，请参阅创建并上传包含 Windows Server 操作系统的虚拟硬盘。当您使用自己的 VM 时，Windows Server 操作系统许可成本将计入每小时的计算费用，但该情况并不适用于其他服务器产品，如 SQL Server。您需要确保您的 VM 符合 Microsoft 许可策略。默认情况下，SQL Server 等服务器产品并未获得在虚拟化配置或托管环境（如 Windows Azure 基础结构服务）中运行的许可。Microsoft 依据您运行的是生产工作负荷还是开发/测试工作负荷来为此情况提供不同的 SQL     Server 许可选项。
       
        要运行生产 SQL Server 工作负荷，您必须购买软件维护。有关详细信息，请参阅 Microsoft 软件保障中的许可移动性。从许可的角度来看，您需要与内部部署中相同的 SQL Server 版本和许可证数量。例如，如果您在内部部署中使用基于以CPU核的数量计算的 SQL Server 标准版或企业版的许可证，通过软件保障您可以将这些以CPU核的数量计算的许可证移动到 Windows Azure。每台虚拟机最少可以应用四个以CPU核的数量计算的许可证，因此请挑选大小合适的虚拟机。请注意，如果您希望将许可证重新分配给内部部署的服务器，那么您将需要等待 90 天。要运行开发/测试 SQL Server 工作负荷，您应考虑购买 MSDN 专业版、高级版或旗舰版订阅。您无需支付其他费用即可在 VM 上安装 MSDN 订阅中包含的大多数软件（包括 SQL Server）。有关详细信息，请参阅Windows Azure 对 MSDN订阅者的好处。
       
        如果您已决定创建自己的 SQL Server VM，您应了解我们在对 SQL Server 2012 SP1 的累积更新中发布的一些最新改进功能，这些功能可以大大简化使用SysPrep 实用程序准备 SQL Server VM 映像的过程。有关更多信息，请参阅 SQL Server 2012 SP1 CU2 中的扩展 SysPrep支持。
       
        对于 SQL Server AlwaysOn 可用性组部署，请注意该“免费的被动式故障转移实例”许可优惠不适用于在 Windows Azure 基础结构服务（或任何其他托管环境）中运行的 SQL     Server 部署。该优惠仅适用于内部部署，即不涉及共享托管环境的部署。这意味着所有副本均需要获得完全许可的 SQL Server 企业版副本。要获取所有这些详细信息的最新内容，请参阅SQL Server 2012 许可指南。
     
4. 了解您的硬件和存储：
   本节我们将从 CPU、RAM、I/O 和网络等方面探讨 Windows Azure 基础结构服务的性能特征。Microsoft 致力于通过 Windows Azure 基础结构服务，以极具竞争力的成本提供一流的计算和存储性能（有关更多信息，请参阅虚拟机定价详细信息）。但您必须了解：云的核心价值主张在于能够使用低成本的共享计算和存储基础结构进行横向扩展，而不是在昂贵而笨重的专用设备上进行纵向扩展。许多大型组织已经对自己私有云中的部分甚至全部 SQL Server 工作负荷进行虚拟化，但有些固执的 SQL     Server 传统用户对其性能和可靠性仍持怀疑态度。言归正传，SQL Server 虚拟化完全受支持，并且将成为一种趋势。尽管如此，但您不能指望使用 VM 就能获得在昂贵的大型服务器和存储器子系统上可以实现的相同性能级别。
       
        Windows Azure 虚拟机托管于共享群集中的通用型服务器上，而 Windows Azure 磁盘（操作系统和数据磁盘）是使用     Windows Azure 存储进行实施的，这是一种具有内置冗余性的共享存储服务。从 CPU 角度而言，您为虚拟化付出了代价。从 IO 角度而言，您为共享冗余存储付出了代价。因此在将高度优化的关键业务 SQL Server OLTP 工作负荷转移到 Windows Azure 基础结构服务之前，您应该对性能、吞吐量和延迟有个基本了解。如果您进行了充分的规划和测试，大多数典型 SQL Server 工作负荷都能在 Windows Azure 虚拟机中正常运行。但有少数对性能敏感的“纵向扩展”工作负荷就永远无法适应这种环境。
       
        我们先从 CPU 说起。我们的虚拟核的时钟速度以及其他特性根据虚拟核部署在哪种主机服务器上可能有所不同。因为 SQL Server 需要大约 4GB 的 RAM 才能正常运行，因此应至少使用中等大小的 VM 实例 (A2)。A2 和较大的 VM 提供专用虚拟核，所以无需在相同主机上与其他 VM 共享虚拟核。根据您选择的 VM 大小，您可以配置少到两个虚拟核 (A2)，多到八个虚拟核（超大 A4 VM 及更大 VM）。
       
        接下来我们看看 RAM。大型数据集上的读密集型 SQL Server 和分析服务工作负荷通常需要大量 RAM，才能将所有这些数据缓存在内存中，从而实现最佳性能。如果您的 SQL Server 的缓存命中率逐步下降，您可能想迁移到更大的 VM 以获得更多 RAM。您可以获取少到中型 (A2) VM 中的 3.5 GB RAM，多到高内存 A7 VM 中的 56 GB RAM。为了控制成本，您在估算 VM 大小时应该谨慎。在较小的 VM 上测试您的工作负荷，以查看性能是否可接受。您可以稍后根据需要随时升级到较大的 VM。
       
        接下来我们探讨一下存储性能。如前面所说，您的 VHD（操作系统和磁盘数据）是使用 Windows Azure 磁盘实施的，这种磁盘是一种特殊的     Windows Azure  PageBlob，可以本地缓存在共享磁盘子系统中的主机服务器上。本地冗余为内置选项，跨地域冗余则为附加选项。支持您的本地缓存 VHD 的page blobs 远程存储在可通过 REST API 高速互连访问的共享存储服务中。有关更多信息，请查看数据系列：探索 Windows Azure 驱动器、磁盘和映像。到现在为止您应该已经认识到：Windows Azure 磁盘的性能特征、配置和行为方式与本地连接存储甚至 SAN 都大不相同。
       
        那么存储容量如何呢？首先，不要将您的数据库存储在操作系统驱动器上，除非这些数据库很小。不要对数据库（包括临时数据库）使用 D: 盘临时驱动器，因为存储在此驱动器上的数据可能会在重新启动后丢失，并且临时驱动器的性能将无法预测。我们建议您将单个数据磁盘连接到您的 VM，并用它来存储您所有的用户数据库。有关更多信息，请参阅如何将数据磁盘连接到虚拟机。数据磁盘的大小可以高达 1 TB，因此您在一个 A4 或更大的 VM 上最多可以拥有 16 个驱动器。如果您的数据库大于 1 TB，则可以使用 SQL Server 文件组来将您的数据库分布到多个数据磁盘上。您也可以选择使用 Windows Server 2012 中的存储空间将多个数据磁盘合并到一个大型卷中。存储空间要优于传统的操作系统条带化技术，因为它们能很好地适应 Windows Azure 存储的仅追加特性。如第 2 节中所讨论，如果您不想使用多个数据磁盘，请勿启用跨地域冗余。每秒输入/输出操作数 (IOPS) 往往成为用来测量 SQL Server 工作负荷的磁盘性能的关键指标。那么您在     Windows Azure 磁盘上能达到多大 IOPS 呢？答案是，这取决于 IO 大小和访问模式。对于执行 8 KB IO 且读/写比例为 60/40 的工作负荷，我们的目标是为单个磁盘提供高达 500 IOPS 的速度。需要达到更高速度？那么请添加更多数据磁盘，并将您的数据库工作负荷分布到这些磁盘上。创建或还原大型数据库时，您应该使用即时文件初始化来提高性能。
       
        最后一点是关于网络带宽和延迟。VM 根据大小分配了一定量的网络带宽。此分配可能会影响数据传输和备份的性能，因此如果您计划移动大量数据，则应考虑使用较大的 VM。通过公共端点或 VPN 网关连接 VM 时，请务必记住，您是通过公共 Internet 访问您的基础结构的。您的 VM 远离您的物理位置，并且使用了复杂的网络基础结构，如启用了高级安全选项的负载平衡器和网关。这会导致网络延迟，并要求对依赖于低延迟网络的多种操作采取不同的操作方法。例如，将大型数据库迁移到云耗时会长得多，并且不是为云端网络延迟设计的客户端应用程序可能无法正常运行。我们将在下一节更详细地讨论网络。
       
        有关 VM 大小和选项的更多信息，请参阅虚拟机云服务大小。有关性能最佳实践的详细信息，请参阅Windows Azure虚拟机中的 SQL Server 性能指南。
    
5. 优先计划您的网络
   Windows Azure 基础结构服务可提供用于 VM 部署的各种网络连接选项。在创建 VM 之前，应该首先计划网络配置，以免犯错后不得不从头开始。可以使用远程桌面功能从您的桌面连接到各个 VM，并对其进行管理。有关详细信息，请参阅如何登录到运行 Windows Server 的虚拟机。如果要允许从公共 Internet 连接到 VM，可以使用端点打开端口。有关详细信息，请参阅如何设置与虚拟机的通信。要通过 Internet 远程管理 SQL Server，您可以创建一个允许通过标准 SQL Server 端口 1433 访问 VM 的端点，但由于此端口为黑客所熟知，因此我们建议对 SQL Server 端点使用随机公共端口。您可以在 VM 集内自动实现到端点的传入连接的负载平衡。有关详细信息，请参阅实现虚拟机的负载平衡。对于跨多个 VM 横向扩展前端 Web 服务器的方案，此方法十分有用。
       
        为了在 VM 之间建立完整的连接，您应该首先创建 Windows Azure 虚拟网络，然后在该新的虚拟网络中创建 VM。系统将使用在虚拟网络配置中指定的范围为您的新 VM 自动分配一个 IP 地址，因此无需实施您自己的 DHCP 服务。虚拟网络具有内置 DNS，您也可以部署您自己的 DNS 服务器。有关详细信息，请参阅Windows Azure名称解析。您应该彻底地测试您的名称解析，然后再继续。如果您没有太多网络专业知识，您可能希望在继续之前有同事能帮您检查一下配置，从而不让自己陷入困境。
       
        现在事情开始变得真正有趣了。您可以使用安全 VPN     网关在企业网络和虚拟网络之间建立点对点连接。要达到此目的，您的企业网络中需要有 VPN 设备。建立 VPN 网关时，我们支持使用专用 VPN 设备和基于软件的选件。有关详细信息，请参阅创建跨界连接的虚拟网络。还可以使用 VPN 连接直接从计算机到虚拟网络建立点对站连接，这对于需要从远程位置访问虚拟网络的开发人员或管理员非常有用。有关详细信息，请参阅在管理门户中配置点对站 VPN。
       
        大部分 Windows Server 部署通常依赖 Active Directory (AD) 进行身份识别和确保安全。Windows Azure 基础结构服务支持各种 Active Directory 部署选项。如果希望部署仅由虚拟网络中 VM 使用的独立 AD，请参阅在 Windows Azure 中安装新的 Active Directory forest。如果实施 VPN 网关，您可以将虚拟网络中的 VM 加入到企业 Active Directory 域中。在此方案中，在虚拟网络中部署只读 AD 域控制器以提升性能和可靠性是有意义的。有关如何达到此目的的指南，请参阅在 Windows Azure 虚拟网络中安装副本 Active Directory域控制器。Windows Azure还支持更多强大的 AD 配置，例如 Active Directory 联合身份验证服务，以及对混合身份验证方案的支持，该方案覆盖了在 Windows Azure 中运行的 VM 和其他云服务。有关详细信息，请参阅Windows Azure Active Directory。
    
6. 将您的 VM 上的时区设置为 UTC
   考虑将您的 VM 上的时区设置为 UTC。Windows Azure 基础结构服务在所有数据中心和区域中使用 UTC。使用 UTC 时区可以避免日后突然出现与夏令时相关的时间问题，尽管此问题很少发生。当然，客户端应该继续使用本地时区。
       
       
7. 使用数据和备份压缩
   SQL Server 支持数据压缩和备份压缩功能，从而在尽量减小 CPU 开销的前提下提升 I/O 性能。通过压缩数据和备份，可以对 Windows Azure 存储执行更快的 I/O 操作，且数据占用的空间更少。
       
       
8. 备份到 Blob 存储，而非磁盘
   在 SQL Server 2012     Service Pack 1 Cumulative Update 2 中，我们启用了在 Windows Azure 基础结构服务中部署 SQL Server 的新备份方案，非常方便。您可以使用 Windows Azure Blob 存储备份和还原数据库，而不必配置用于存储备份的其他数据磁盘。Blob 存储提供无限容量，具有内置本地冗余和可选跨地域冗余。这样可以腾出数据磁盘中的宝贵容量，以便您可以将其专门用于存储数据和日志文件。有关详细信息，请参阅使用 Windows Azure Blob 存储服务进行 SQL Server备份和还原。另外一个好处是，您可以跨存储帐户甚至跨地区异步复制您的备份 Blob，而无需浪费宝贵的时间和带宽来执行不必要的上传和下载操作。
       
       
9. 避免受到黑客攻击
   花点时间妥善保护 Windows Azure 基础结构服务中 VM 和 SQL Server 部署的安全，防止未经授权的访问。黑客通常会攻击 Internet 上安全防护不严的计算机，将其用于他们自己的目的。我们建议您使用保护网络 DMZ 后的内部 SQL Server 部署的方式，来保护 Windows Azure 基础结构服务中 SQL Server 部署的安全。避免打开 RDP 或 TSQL 的公共端点。而应设置安全 VPN 网关并直接管理数据库服务器。使用     Windows 身份验证进行身份识别和访问控制。如果必须使用 SQL     身份验证，请创建用于管理 SQL Server 的其他帐户、将其添加到 sysadmin 角色、设置强密码，然后禁用 sa 帐户。通过停止和禁用不想使用的服务，将攻击降低到最低程度。可考虑使用SQL Server透明数据加密 (TDE) 来保护您的数据、日志和备份文件，让您高枕无忧。如果在 VM 外复制这些文件，它们将没有价值。
       
       
10. 学习 PowerShell
    Windows Azure 管理门户具有大量的图形界面，用于配置和管理 Windows Azure 基础结构服务中的 VM 部署，但是如果必须部署多个虚拟机，您应该花点时间学习 PowerShell。通过开发 PowerShell 脚本库来配置 VM 和虚拟网络，您可以节省大量的时间和精力。有关详细信息，请参阅使用 PowerShell 实现 Windows Azure基础结构服务 (IaaS) 部署自动化。

现在您已了解一些信息，我们鼓励您投入工作，开始标识哪些 SQL Server 工作负荷已准备好迁移到 Windows Azure 基础结构服务。从迁移一些较小的工作负荷开始，这样您可以有所收获并获得自信，然后转向更密集的工作负荷。请记住，除了兼容性之外，Windows Azure 基础结构服务还可以对 SQL Server 部署的配置和维护提供（并要求）精细控制。对于大多数 IT 组织，这是一大卖点，但是其他组织希望摆脱维护服务器的业务，而更加专注于创新。

Windows Azure SQL 数据库基于 SQL Server 技术构建，并作为服务提供。无需安装和管理服务器软件，而且内置了高可用性和灾难恢复等高级功能。也有的组织希望在 Windows Azure 基础结构服务中运行 SQL Server 时将兼容性和精细控制相结合，以迁移现有工作负荷，同时融合 Windows Azure SQL 数据库中针对新工作负荷的托管服务的敏捷性和优势，达到两全其美的效果。这种混合使用 Windows Azure 的方式完全受支持，并已成为与其他公共云提供商相抗衡的关键差异化因素。有关所有这些功能的详细信息，请参阅数据管理。

 

Roger Doherty
高级项目经理
Microsoft 客户咨询团队

本文翻译自：

http://blogs.msdn.com/b/windowsazure/archive/2013/06/04/the-top-10-things-to-know-when-running-sql-server-workloads-on-windows-azure-virtual-machines.aspx