你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
清单:有关 Azure VM 上 SQL Server 的最佳做法
本文提供一个可用于快速查看有关 Azure 虚拟机 (VM) 上 SQL Server 性能优化的一系列最佳做法和指南的清单。
如需了解全面的详情,请参阅本系列中的其他文章:VM 大小、存储、安全性、HADR 配置、收集基线。
启用 Azure VM 上适用于 SQL Server 的 SQL 评估,SQL Server 将通过 Azure 门户的 SQL VM 管理页上的结果针对已知最佳做法进行评估。
有关优化 SQL Server VM 性能和自动化管理的最新功能的视频,请查看以下数据公开的视频:
- 高速缓存和存储上限
- 使用 SQL Server IaaS 代理扩展实现自动管理
- 使用 Azure Monitor 指标跟踪 VM 缓存运行状况
- 为 Azure VM 上的 SQL Server 工作负载获得最佳性价比
- 使用 PerfInsights 评估资源运行状况并排除故障
- Ebdsv5 系列的最佳性价比
- 使用 SQL 评估在 Azure 虚拟机上优化配置 SQL Server
- Azure VM 部署和管理体验的新的改进的 SQL Server
概述
在 Azure 虚拟机上运行 SQL Server 时,继续使用适用于本地服务器环境中的 SQL Server 的相同数据库性能优化选项。 但是,关系数据库在公有云中的性能取决于许多因素,如虚拟机的大小和数据磁盘的配置。
通常需要在针对成本优化和针对性能优化之间进行权衡。 这一系列性能最佳做法侧重于实现 Azure 虚拟机上 SQL Server 的最佳性能。 如果工作负荷要求较低,可能不需要每项建议的优化。 评估这些建议时应考虑性能需求、成本和工作负荷模式。
VM 大小
本部分中的清单涵盖了 Azure VM 上的 SQL Server 的 VM 大小最佳做法。
- Ebdsv5 系列在 Azure 中提供最高的 I/O 吞吐量与 vCore 比率,内存与 vCore 比率为 8。 此系列为 Azure VM 上的 SQL Server 工作负载提供最佳性能。 对于大多数 SQL Server 工作负载,请首先考虑此系列。
- 将 VM 大小与 4 个或多个 vCPU(如 E4ds_v5 或更高版本)一起使用。
- 使用内存优化的虚拟机大小,以实现 SQL Server 工作负载的最佳性能。
- Edsv5 系列和 Ebdsv5 系列、Msv3 和 Mdsv3 系列提供 OLTP 工作负荷所需的最佳内存与 vCore 比率。
- M 系列 VM 在 Azure 中提供最高的内存与 vCore 比率。 对于任务关键型 OLTP 和数据仓库工作负荷,请考虑这些 VM。
- 使用 Azure 市场映像来部署 SQL Server 虚拟机,配置 SQL Server 设置和存储选项以获得最佳性能。
- 收集目标工作负载的性能特征,并使用它们来确定适用于你的业务的 VM 大小。
- 使用数据迁移助手和 SKU 建议工具为现有 SQL Server 工作负载查找正确的 VM 大小。
- 使用 Azure Data Studio 迁移到 Azure。
警告
当前不支持将 SQL Server 安装到每个 NUMA 节点超过 64 个核心的系统。 此限制目前适用于 Msv3 和 Mdsv3 中型内存系列中的 Standard_M176s_3_v3 和 Standard_M176s_4_v3 Azure 虚拟机大小。
存储
本部分中的清单涵盖了 Azure VM 上的 SQL Server 的 VM 存储最佳做法。
- 在选择磁盘类型之前,监视应用程序并确定 SQL Server 数据、日志和
tempdb
文件的存储带宽和延迟要求。 - 如果可用,请配置 D 盘本地 SSD 卷上的
tempdb
数据和日志文件。 SQL IaaS 代理扩展可处理重新预配时所需的文件夹和权限。 - 为了优化存储性能,请规划可用的最高未缓存 IOPS,并使用数据缓存作为数据读取的性能功能,同时避免虚拟机和磁盘上限。
- 使用 Ebdsv5 或 Ebsv5 系列 SQL Server VM 时,请使用高级 SSD v2 获得最佳性价比。 可以使用 Azure 门户(目前为预览版),通过高级 SSD v2 部署 SQL Server VM。
- 将数据、日志和
tempdb
文件放在不同的驱动器上。- 对于数据驱动器,使用高级 P30 和 P40 或更小的磁盘以确保可提供缓存支持。 使用 Ebdsv5 VM 系列时,请使用高级 SSD v2,它为需要高 IOPS 和 I/O 吞吐量的工作负载提供了更好的性价比。
- 对于日志驱动器,规划容量并测试性能与成本,同时评估高级 SSD v2 或高级 SSD P30 - P80 磁盘
- 如果需要亚毫秒存储延迟,请对事务日志使用高级 SSD v2 或 Azure 超级磁盘。
- 对于 M 系列虚拟机部署,请考虑写入加速器,而不是使用 Azure 超级磁盘。
- 选择最佳 VM 大小后,将 tempdb 放在不属于故障转移群集实例 (FCI) 的大多数 SQL Server 工作负载的临时磁盘(临时磁盘是暂时性的,默认值为
D:\
)上。- 如果本地驱动器的容量对
tempdb
来说不足够,请考虑增加 VM 的大小。 有关详细信息,请参阅数据文件缓存策略。
- 如果本地驱动器的容量对
- 对于故障转移群集实例 (FCI),将
tempdb
放置在共享存储上。- 如果 FCI 工作负载严重依赖于
tempdb
磁盘性能,则将tempdb
放置在本地临时 SSD(默认D:\
)驱动器(不是 FCI 存储的一部分)上,作为高级配置。 此配置需要自定义监视和操作,以确保本地临时 SSD(默认D:\
)驱动器始终可用,因为只要此驱动器发生故障,就不会从 FCI 触发操作。
- 如果 FCI 工作负载严重依赖于
- 使用存储空间对多个 Azure 数据磁盘进行条纹化,以将 I/O 带宽增加到目标虚拟机的 IOPS 和吞吐量上限。
- 将数据文件磁盘的主机缓存设置为“只读”。
- 将日志文件磁盘的主机缓存设置为“无”。
- 请不要在包含 SQL Server 数据或日志文件的磁盘上启用读取/写入缓存。
- 更改磁盘的缓存设置之前,请始终停止 SQL Server 服务。
- 将多个不同的工作负载迁移到云时,Azure 弹性 SAN 可能是经济高效的合并存储解决方案。 但是,使用 Azure 弹性 SAN 时,实现 SQL Server 工作负载所需的 IOPS/吞吐量通常需要过度预配容量。 虽然通常不适合单个 SQL Server 工作负载,但在将低性能工作负载与 SQL Server 组合在一起时可以获得经济高效的解决方案。
- 对于开发和测试工作负载和长期备份存档,请考虑使用标准存储。 不建议将标准 HDD/SSD 用于生产工作负载。
- 基于额度的磁盘突发 (P1-P20) 仅应考虑用于较小的开发/测试工作负载和部门系统。
- 为了优化存储性能,请规划可用的最高未缓存 IOPS,并使用数据缓存作为数据读取的性能功能,同时避免虚拟机和磁盘上限/限制。
- 将数据磁盘格式化,为临时
D:\
驱动器(默认为 4 KB)以外的驱动器上放置的所有数据文件使用 64-KB 的分配单元大小。 通过 Azure 市场部署的 SQL Server VM 附带经过格式化的数据磁盘,其中分配单元大小和存储池的交错设置为 64 KB。 - 配置与 SQL Server VM 位于同一区域的存储帐户。
- 在存储帐户上禁用 Azure 异地冗余存储(异地复制)并使用 LRS(本地冗余存储)。
- 启用 SQL 最佳做法评估以识别可能存在的性能问题,并评估 SQL Server VM 是否配置为遵循最佳做法。
- 使用存储 IO 利用率指标查看和监视磁盘和 VM 限制。
- 从防病毒软件扫描中排除 SQL Server 文件,包括数据文件、日志文件和备份文件。
安全性
本部分中的核对列表涵盖了 Azure VM 上的 SQL Server 的安全最佳做法。
SQL Server 特性和功能提供在数据库级别保护数据的方法,其可与基础结构级别的安全功能结合使用。 总之,这些功能为基于云和混合的解决方案在基础结构级别提供了纵深防御。 此外,借助 Azure 安全措施,可以加密敏感数据、防范虚拟机遭到病毒和恶意软件的侵害、保护网络流量、识别和检测威胁、满足合规要求,并提供单一的方法来管理和报告混合云中的任何安全需求。
- 使用 Microsoft Defender for Cloud 评估数据环境的安全态势,并采取措施来做出改进。 可以在混合工作负载中使用 Azure 高级威胁防护 (ATP) 等功能来改善安全评估并提供对风险做出反应的能力。 向 SQL IaaS 代理扩展注册 SQL Server VM 后,会在 Azure 门户的 SQL 虚拟机资源中显示 Microsoft Defender for Cloud 评估。
- 使用 Microsoft Defender for SQL 发现和缓解潜在的数据库漏洞,以及检测可能表示 SQL Server 实例和数据库层受到威胁的异常活动。
- 漏洞评估是 Microsoft Defender for SQL 的一部分,可以发现并帮助修正 SQL Server 环境面临的潜在风险。 它可让用户观察安全状态,并包含用于解决安全问题的可行步骤。
- 使用 Azure 机密 VM 加强对正在使用的数据和静态数据的保护,防止主机操作员访问。 借助 Azure 机密 VM,可以放心地将敏感数据存储在云中,并满足严格的合规性要求。
- 如果使用 SQL Server 2022,请考虑使用 Microsoft Entra 身份验证连接到 SQL Server 实例。
- Azure 顾问可分析资源配置和遥测使用情况,并推荐解决方案,有助于提高 Azure 资源的经济效益、性能、高可用性和安全性。 在虚拟机、资源组或订阅级别使用 Azure 顾问可以帮助识别和应用最佳做法来优化 Azure 部署。
- 当合规性与安全性政策要求使用加密密钥对数据进行端到端加密(包括加密临时磁盘,即本地附加的临时磁盘)时,可以使用 Azure 磁盘加密。
- 系统默认会使用 Azure 存储服务加密来静态加密托管磁盘,其中,加密密钥是 Azure 中的 Microsoft 托管密钥。
- 有关托管磁盘加密选项的比较,请查看托管磁盘加密比较图表
- 应在虚拟机上关闭管理端口 - 打开远程管理端口会导致 VM 面临基于 Internet 的攻击的严重风险。 此类攻击试图暴力破解凭据,来获取对计算机的管理员访问权限。
- 为 Azure 虚拟机启用实时 (JIT) 访问
- 通过远程桌面协议 (RDP) 使用 Azure Bastion。
- 使用 Azure 防火墙锁定端口并仅允许传送必要的应用程序流量。Azure 防火墙是一个托管的防火墙即服务 (FaaS),它根据来源 IP 地址授予/拒绝服务器访问权限。
- 使用网络安全组 (NSG) 筛选传入和传出 Azure 虚拟网络上的 Azure 资源的网络流量
- 使用应用程序安全组将端口筛选要求和功能类似的服务器(例如 Web 服务器和数据库服务器)分组到一起。
- 对于 Web 和应用程序服务器,可以使用 Azure 分布式拒绝服务 (DDoS) 防护。 DDoS 攻击旨在瘫痪和耗尽网络资源,使应用速度变慢或无响应。 DDoS 攻击通常以用户界面为目标。 Azure DDoS 防护可以在有害网络流量影响到服务可用性之前对其进行净化
- 使用 VM 扩展来帮助实现反恶意软件、所需状态、威胁检测、预防和修正,以解决操作系统、计算机和网络级别的威胁:
- 来宾配置扩展在虚拟机内部执行审核和配置操作。
- 适用于 Windows 和 Linux 的网络观察程序代理虚拟机扩展可以监视网络性能、诊断和分析服务,从而可以启用 Azure 网络监视。
- 适用于 Windows 的 Microsoft Antimalware 扩展可帮助识别和删除病毒、间谍软件与其他恶意软件,并提供可配置的警报。
- 评估第三方扩展,例如 Symantec Endpoint Protection for Windows VM (/azure/virtual-machines/extensions/symantec)
- 使用 Azure Policy 创建可应用于环境的业务规则。 Azure 策略通过将这些资源的属性与以 JSON 格式定义的规则进行比较来评估 Azure 资源。
- 通过 Azure 蓝图,云架构师和中心信息技术组同样可以定义一组可重复的 Azure 资源,这些资源实现并遵守组织的标准、模式和要求。 Azure 蓝图不同于 Azure 策略。
- 使用 Windows Server 2019 或 Windows Server 2022 来使 Azure VM 上的 SQL Server 符合 FIPS 标准。
SQL Server 功能
下面是一个最佳做法快速清单,涵盖了在生产环境中,在 Azure 虚拟机上运行 SQL Server 实例的最佳 SQL Server 配置设置:
- 适用时启用数据库页压缩。
- 启用备份压缩。
- 对数据文件启用即时文件初始化。
- 限制数据库自动增长。
- 禁用数据库自动收缩。
- 禁用数据库自动关闭。
- 将所有数据库(包括系统数据库)转移到数据磁盘。
- 将 SQL Server 错误日志和跟踪文件目录移到数据磁盘。
- 配置默认的备份和数据库文件位置。
- 设置最高 SQL Server 内存限制,为操作系统留出足够内存。 (使用内存\可用字节来监视操作系统内存运行状况)。
- 启用锁定内存页。
- 启用针对 OLTP 繁重环境的临时工作负荷优化。
- 评估并应用已安装的 SQL Server 版本的最新累积更新。
- 遵循最佳做法,为所有生产 SQL Server 数据库启用查询存储。
- 对任务关键型应用程序数据库启用自动优化。
- 确保遵循所有 tempdb 最佳实践。
- 使用建议的文件数,使用多个
tempdb
数据文件,从每个核心一个文件开始,最多八个文件。 - 如果可用,请在 D 盘本地 SSD 卷上配置
tempdb
数据和日志文件。 SQL IaaS 代理扩展可处理重新预配时所需的文件夹和权限。 - 计划 SQL Server 代理作业以运行 DBCC CHECKDB、索引重新编制、索引重新生成和更新统计信息作业。
- 监视和管理 SQL Server 事务日志文件的运行状况和大小。
- 利用可用于所使用版本的任何新 SQL Server 功能。
- 请注意考虑部署的各版本之间在支持的功能方面的差异。
- 从防病毒软件扫描中排除 SQL Server 文件。 这包括数据文件、日志文件和备份文件。
进行映射
下面是有关在 Azure VM 上运行 SQL Server 时 Azure 特定指南的最佳做法的快速清单:
- 注册 SQL IaaS 代理扩展,以获取多项功能优势。
- 利用 SQL Server 工作负载的最佳备份和还原策略。
- 确保在虚拟机上启用加速网络。
- 利用 Microsoft Defender for Cloud 改进虚拟机部署的总体安全状况。
- 利用 Microsoft Defender for Cloud(与 Microsoft Defender for Cloud 集成)获得特定 SQL Server VM 范围的保护,包括漏洞评估和实时访问,后者可减少攻击服务,同时允许合法用户在必要时访问虚拟机。 要了解详细信息,请参阅漏洞评估、为 SQL Server VM 和实时访问启用漏洞评估。
- 利用 Azure 顾问 来解决性能、成本、可靠性、卓越运营和安全建议。
- 利用 Azure Monitor 从 SQL Server 环境收集、分析和处理遥测数据。 这包括识别 VM 见解的基础结构问题并通过日志分析监视数据,以便进行更深入的诊断。
- 为开发和测试环境启用自动关闭。
- 实现满足业务连续性 SLA 的高可用性和灾难恢复 (HADR) 解决方案,请参阅适用于 Azure VM 上的 SQL Server 的 HADR 选项。
- 使用 Microsoft Azure 门户(支持 + 故障排除)评估资源运行状况和历史记录;在需要时提交新的支持请求。
HADR 配置
本部分中的清单涵盖了 Azure VM 上的 SQL Server 的 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 秒开始。 如果使用之前建议的宽松SameSubnetThreshold
和SameSubnetDelay
值,则租用超时值不要超过 80 秒。 - 指定时间段内的最大失败数:将此值设置为 6。
- 租用超时:使用此公式计算最大租用超时值:
- 使用虚拟网络名称 (VNN) 和 Azure 负载均衡器连接 HADR 解决方案时,即使群集只跨越一个子网,也请在连接字符串中指定
MultiSubnetFailover = true
。- 如果客户端不支持
MultiSubnetFailover = True
,你可能需要设置RegisterAllProvidersIP = 0
和HostRecordTTL = 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
性能故障排除
下面是有助于进一步排查 SQL Server 性能问题的资源列表。
- 排查高 CPU 使用率问题
- 了解并解决阻止问题
- 排查运行缓慢的查询
- 排查 I/O 问题导致的性能缓慢问题
- 排查查询超时错误
- 排查内存耗尽或内存不足问题
- 性能仪表板提供 SQL Server 性能状态的快速见解。
相关内容
请考虑启用 Azure VM 上适用于 SQL Server 的 SQL 评估。
查看 Azure 虚拟机上的 SQL Server 概述中的其他 SQL Server 虚拟机文章。 如果对 SQL Server 虚拟机有任何疑问,请参阅常见问题解答。