清单:有关 Azure VM 上 SQL Server 的最佳做法

适用于: Azure VM 上的 SQL Server

本文提供一个可用于快速查看有关 Azure 虚拟机 (VM) 上 SQL Server 性能优化的一系列最佳做法和指南的清单。

如需了解全面的详情,请参阅本系列中的其他文章:VM 大小存储安全性HADR 配置收集基线

启用 Azure VM 上适用于 SQL Server 的 SQL 评估,SQL Server 将通过 Azure 门户的 SQL VM 管理页上的结果针对已知最佳做法进行评估。

概述

在 Azure 虚拟机上运行 SQL Server 时,继续使用适用于本地服务器环境中的 SQL Server 的相同数据库性能优化选项。 但是,关系数据库在公有云中的性能取决于许多因素,如虚拟机的大小和数据磁盘的配置。

通常需要在针对成本优化和针对性能优化之间进行权衡。 这一系列性能最佳做法侧重于实现 Azure 虚拟机上 SQL Server 的最佳性能。 如果工作负荷要求较低,可能不需要每项建议的优化。 评估这些建议时应考虑性能需求、成本和工作负荷模式。

VM 大小

下面是有关在 Azure VM 上运行 SQL Server 时应选择的 VM 大小的最佳做法的快速清单:

  • 使用具有 4 个或更多 vCPU 的 VM 大小,例如 E4ds_v4 或更高版本。
  • 使用内存优化的虚拟机大小,以实现 SQL Server 工作负载的最佳性能。
  • Edsv4M 系列提供 OLTP 工作负载所需的最佳内存与 vCore 比率。
  • M 系列 VM 提供 Azure 中最高的内存与 vCore 比率。 考虑将这些 VM 用于任务关键型和数据仓库工作负载。
  • 利用 Azure 市场映像部署 SQL Server 虚拟机,因为 SQL Server 设置和存储选项已配置为实现最佳性能。
  • 收集目标工作负载的性能特征,并使用它们来确定适用于你的业务的 VM 大小。
  • 使用数据迁移助手SKU 建议工具为现有 SQL Server 工作负载查找正确的 VM 大小。

若要了解详细信息,请参阅内容全面的 VM 大小最佳做法

存储

下面是有关在 Azure VM 上运行 SQL Server 时的存储配置的最佳做法的快速清单:

  • 在选择磁盘类型之前,监视应用程序并确定 SQL Server 数据、日志和 tempdb 文件的存储带宽和延迟要求
  • 为了优化存储性能,请规划可用的最高未缓存 IOPS,并使用数据缓存作为数据读取的性能功能,同时避免虚拟机和磁盘上限/限制
  • 将数据、日志和 tempdb 文件放在不同的驱动器上。
    • 对于数据驱动器,使用高级 P30 和 P40 或更小的磁盘以确保可提供缓存支持
    • 对于日志驱动器,规划容量并测试性能与成本,同时评估高级 P30 - P80 磁盘
    • 选择最佳 VM 大小后,请将 tempdb 放置在大多数 SQL Server 工作负载的本地临时 SSD(默认 D:\)驱动器上,这些工作负荷不是故障转移群集实例 (FCI) 的一部分。
      • 如果本地驱动器的容量对 tempdb 来说不足够,请考虑增加 VM 的大小。 有关详细信息,请参阅数据文件缓存策略
    • 对于 FCI,将 tempdb 放置在共享存储上。
      • 如果 FCI 工作负载严重依赖于 tempdb 磁盘性能,则请将 tempdb 放置在本地临时 SSD(默认 D:\)驱动器(不是 FCI 存储的一部分)上,作为高级配置。 此配置需要自定义监视和操作,以确保本地临时 SSD(默认 D:\)驱动器始终可用,因为只要此驱动器发生故障,就不会从 FCI 触发操作。
  • 使用存储空间对多个 Azure 数据磁盘进行条纹化,以将 I/O 带宽增加到目标虚拟机的 IOPS 和吞吐量上限。
  • 将数据文件磁盘的主机缓存设置为只读。
  • 将日志文件磁盘的主机缓存设置为无。
    • 请不要在包含 SQL Server 数据或日志文件的磁盘上启用读取/写入缓存。
    • 更改磁盘的缓存设置之前,请始终停止 SQL Server 服务。
  • 对于开发和测试工作负荷,请考虑使用标准存储。 不建议将标准 HDD/SDD 用于生产工作负载。
  • 基于额度的磁盘突发 (P1-P20) 仅应考虑用于较小的开发/测试工作负载和部门系统。
  • 预配与 SQL Server VM 位于同一区域的存储帐户。
  • 在存储帐户上禁用 Azure 异地冗余存储(异地复制)并使用 LRS(本地冗余存储)。
  • 将数据磁盘格式化,为临时 D:\ 驱动器(默认为 4 KB)以外的驱动器上放置的所有数据文件使用 64-KB 的分配单元大小。 通过 Azure 市场部署的 SQL Server VM 附带经过格式化的数据磁盘,其中分配单元大小和存储池的交错设置为 64 KB。

若要了解详细信息,请参阅内容全面的存储最佳做法

SQL Server 功能

下面是一个最佳做法快速清单,涵盖了在生产环境中,在 Azure 虚拟机上运行 SQL Server 实例的最佳 SQL Server 配置设置:

进行映射

以下是在 Azure VM 上运行 SQL Server 时 Azure 特定指南的最佳做法的快速清单:

HADR 配置

高可用性和灾难恢复 (HADR) 功能,如 Always On 可用性组故障转移群集实例依赖于基础的Windows Server 故障转移群集技术。 查看修改 HADR 设置以更好地支持云环境的最佳做法。

对于 Windows 群集,请考虑以下最佳做法:

  • 尽可能将 SQL Server VM 部署到多个子网,以避免依赖于 Azure 负载均衡器或分布式网络名称 (DNN) 来将流量路由到 HADR 解决方案。
  • 将群集更改为主动性较低的参数,以避免暂时性网络故障或 Azure 平台维护带来的意外中断。 要了解详细信息,请参阅检测信号和阈值设置。 对于 Windows Server 2012 或更高版本,请使用以下建议值:
    • SameSubnetDelay:1 秒
    • SameSubnetThreshold:40 个检测信号
    • CrossSubnetDelay:1 秒
    • CrossSubnetThreshold:40 个检测信号
  • 将 VM 放置在可用性集或不同的可用性区域中。 要了解详细信息,请参阅 VM 可用性设置
  • 每个群集节点使用一个 NIC,并使用一个子网。
  • 将群集仲裁投票配置为使用 3 个或更多奇数投票数。 不要将投票分配给 DR 区域。
  • 仔细监视资源限制,避免因资源限制出现意外重启或故障转移。
    • 确保 OS、驱动程序和 SQL Server 都是最新版本。
    • 针对 Azure VM 上的 SQL Server 优化性能。 查看本文中的其他部分了解详细信息。
    • 减少或分散工作负荷,避免资源限制。
    • 转到限制更高的 VM 或磁盘,避免受限。

对于 SQL Server 可用性组或故障转移群集实例,请考虑以下最佳做法:

  • 如果经常出现意外失败,请遵循本文其余部分中概述的最佳性能做法。
  • 如果优化 SQL Server VM 性能无法解决意外的故障转移,请考虑放宽对可用性组或故障转移群集实例的监视。 但这样做可能无法解决根本问题,同时可能会降低失败可能性而掩盖症状。 你可能仍需要调查并解决根本原因。 对于 Windows Server 2012 或更高版本,请使用以下建议值:
    • 租用超时:使用此公式计算最大租用超时值:
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      首先从 40 秒开始。 如果使用的是之前建议的宽松 SameSubnetThresholdSameSubnetDelay 值,则租用超时值不超过 80 秒。
    • 指定时间段内的最大失败数:可以将此值设置为 6。
    • HealthCheck 超时:你最初可以将此值设置为 60000,然后根据需要进行调整。
  • 使用虚拟网络名称 (VNN) 和 Azure 负载均衡器连接 HADR 解决方案时,即使群集只跨越一个子网,也请在连接字符串中指定 MultiSubnetFailover = true
    • 如果客户端不支持 MultiSubnetFailover = True,你可能需要设置 RegisterAllProvidersIP = 0HostRecordTTL = 300 来缓存较短持续时间内的客户端凭据。 但这样做可能会导致对 DNS 服务器进行其他查询。
  • 要使用分布式网络名称 (DNN) 连接 HADR 解决方案,请考虑以下事项:
    • 必须使用支持 MultiSubnetFailover = True 的客户端驱动程序,而且此参数必须位于连接字符串中。
    • 连接可用性组的 DNN 侦听器时,请在连接字符串中使用唯一的 DNN 端口。
  • 对基本可用性组使用数据库镜像连接字符串,免去负载均衡器或 DNN 需求。
  • 在部署高可用性解决方案之前验证 VHD 的扇区大小,避免出现未对齐的 I/O。 有关详细信息,请参阅 KB3009974
  • 如果将 SQL Server 数据库引擎、Always On 可用性组侦听程序或故障转移群集实例运行状况探测配置为使用 49,152 到 65,536 之间的端口(TCP/IP 的默认动态端口范围),请为每个端口添加一个排除项。 这样做可以防止其他系统被动态地分配到相同的端口。 下面的示例为端口 59999 创建一个排除项:
    netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

要了解详细信息,请参阅全面的 HADR 最佳做法

安全性

本部分中的核对列表涵盖了 Azure VM 上的 SQL Server 的安全最佳做法

SQL Server 特性和功能在数据级别提供安全性方法,并且是在基础结构级别为基于云的解决方案和混合解决方案实现深层防御的方法。 此外,借助 Azure 安全措施,可以加密敏感数据、防范虚拟机遭到病毒和恶意软件的侵害、保护网络流量、识别和检测威胁、满足合规要求,并提供单一的方法来管理和报告混合云中的任何安全需求。

  • Azure 顾问可分析资源配置和遥测使用情况,并推荐可帮助提高 Azure 资源的经济效益、性能、高可用性和安全性的解决方案。 在虚拟机、资源组或订阅级别利用 Azure 顾问可以帮助识别和应用最佳做法来优化 Azure 部署。
  • 当合规性与安全性政策要求使用加密密钥对数据进行端到端加密(包括加密临时磁盘,即本地附加的临时磁盘)时,可以使用 Azure 磁盘加密
  • 系统默认会使用 Azure 存储服务加密来静态加密托管磁盘,其中,加密密钥是 Azure 中的 Microsoft 托管密钥。
  • 有关托管磁盘加密选项的比较,请查看托管磁盘加密比较图表
  • 应在虚拟机上关闭管理端口 - 打开远程管理端口会导致 VM 面临基于 Internet 的攻击的严重风险。 此类攻击试图暴力破解凭据,来获取对计算机的管理员访问权限。
  • 为 Azure 虚拟机启用实时 (JIT) 访问
  • 通过远程桌面协议 (RDP) 使用 Azure Bastion
  • 使用 Azure 防火墙锁定端口并仅允许传送必要的应用程序流量。Azure 防火墙是一个托管的防火墙即服务 (FaaS),它根据来源 IP 地址授予/拒绝服务器访问权限。
  • 使用网络安全组 (NSG) 筛选传入和传出 Azure 虚拟网络上的 Azure 资源的网络流量
  • 利用应用程序安全组将端口筛选要求和功能类似的服务器(例如 Web 服务器和数据库服务器)分组到一起。
  • 利用 VM 扩展来帮助实现反恶意软件、所需状态、威胁检测、预防和修正,以解决操作系统、计算机和网络级别的威胁:
  • 利用 Azure Policy 创建可应用于环境的业务规则。 Azure 策略通过将这些资源的属性与以 JSON 格式定义的规则进行比较来评估 Azure 资源。

后续步骤

有关详细信息,请参阅本最佳做法系列中的其他文章:

请考虑启用 Azure VM 上适用于 SQL Server 的 SQL 评估

查看 Azure 虚拟机上的 SQL Server 概述中的其他 SQL Server 虚拟机文章。 如果对 SQL Server 虚拟机有任何疑问,请参阅常见问题解答