清单:有关 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 大小最佳做法。
- 确定工作负载的性能特征,以确定适用于你的业务的 VM 大小。
- 使用 Azure 市场映像来部署 SQL Server VM,配置 SQL Server 设置和存储选项以获得最佳性能。
- 将 VM 大小与 4 个或更多个 vCPU 配合使用。
- 使用内存优化的虚拟机大小,以实现 SQL Server 工作负载的最佳性能。
- 使用较低层 D 系列、B 系列或 Av2 系列开始开发环境,并随着时间的推移扩展你的环境。
存储
本部分中的清单涵盖了 Azure VM 上的 SQL Server 的 VM 存储最佳做法。
- 在选择磁盘类型之前,监视应用程序并确定 SQL Server 数据、日志和
tempdb
文件的存储带宽和延迟要求。 - 如果可用,请配置 D 盘本地 SSD 卷上的
tempdb
数据和日志文件。 SQL IaaS 代理扩展可处理重新预配时所需的文件夹和权限。 - 为了优化存储性能,请规划可用的最高未缓存 IOPS,并使用数据缓存作为数据读取的性能功能,同时避免虚拟机和磁盘上限。
- 将数据、日志和
tempdb
文件放在不同的驱动器上。- 对于数据驱动器,可使用高级 P30 和 P40 或更小的磁盘,以确保缓存支持可用。
- 对于日志驱动器,规划容量并测试性能与成本,同时评估高级 SSD P30 - P80 磁盘
- 如果需要亚毫秒存储延迟,请对事务日志使用 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 服务。
- 对于开发和测试工作负载和长期备份存档,请考虑使用标准存储。 不建议将标准 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 顾问可分析资源配置和遥测使用情况,并推荐解决方案,有助于提高 Azure 资源的经济效益、性能、高可用性和安全性。 在虚拟机、资源组或订阅级别使用 Azure 顾问可以帮助识别和应用最佳做法来优化 Azure 部署。
- 当合规性与安全性政策要求使用加密密钥对数据进行端到端加密(包括加密临时磁盘,即本地附加的临时磁盘)时,可以使用 Azure 磁盘加密。
- 系统默认会使用 Azure 存储服务加密来静态加密托管磁盘,其中,加密密钥是 Azure 中的 Microsoft 托管密钥。
- 有关托管磁盘加密选项的比较,请查看托管磁盘加密比较图表
- 应在虚拟机上关闭管理端口 - 打开远程管理端口会导致 VM 面临基于 Internet 的攻击的严重风险。 此类攻击试图暴力破解凭据,来获取对计算机的管理员访问权限。
- 为 Azure 虚拟机启用实时 (JIT) 访问
- 通过远程桌面协议 (RDP) 使用 Azure Bastion。
- 使用 Azure 防火墙锁定端口并仅允许传送必要的应用程序流量。Azure 防火墙是一个托管的防火墙即服务 (FaaS),它根据来源 IP 地址授予/拒绝服务器访问权限。
- 使用网络安全组 (NSG) 筛选传入和传出 Azure 虚拟网络上的 Azure 资源的网络流量
- 使用应用程序安全组将端口筛选要求和功能类似的服务器(例如 Web 服务器和数据库服务器)分组到一起。
- 使用 VM 扩展来帮助实现反恶意软件、所需状态、威胁检测、预防和修正,以解决操作系统、计算机和网络级别的威胁:
- 来宾配置扩展在虚拟机内部执行审核和配置操作。
- 适用于 Windows 和 Linux 的网络观察程序代理虚拟机扩展可以监视网络性能、诊断和分析服务,从而可以启用 Azure 网络监视。
- 适用于 Windows 的 Microsoft Antimalware 扩展可帮助识别和删除病毒、间谍软件与其他恶意软件,并提供可配置的警报。
- 使用 Azure Policy 创建可应用于环境的业务规则。 Azure 策略通过将这些资源的属性与以 JSON 格式定义的规则进行比较来评估 Azure 资源。
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 范围的保护,包括漏洞评估和实时访问,后者可减少攻击服务,同时允许合法用户在必要时访问虚拟机。 若要了解详细信息,请参阅实时访问。
- 利用 Azure 顾问 来解决性能、成本、可靠性、卓越运营和安全建议。
- 实现满足业务连续性 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 虚拟机有任何疑问,请参阅常见问题解答。