通过

清单：Azure 虚拟机上的 SQL Server 最佳实践

适用于：Azure 虚拟机上的 SQL Server

本文提供了一些列优化 SQL Server 性能的最佳实践和指南清单，这些清单用于在 Azure 虚拟机 (VM) 上实现最佳性能。 使用本指南可改进 VM 配置、存储设置、安全状况以及排查常见性能问题。

本文中的清单简要概述了本系列以下文章中更全面的详细信息：

在 Azure VM 上启用 SQL 评估，您的 SQL Server 将根据已知最佳实践进行评估，其结果将显示在 Azure 门户的 SQL VM 管理页面上。

概述

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

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

Next steps： 从第一个 VM 大小建议开始部分， 然后，继续执行 Storage、Security 和 SQL Server 功能部分，以获取完整的优化方法。

如果工作负荷要求较低，可能不需要每项建议的优化。 评估这些建议时应考虑性能需求、成本和工作负荷模式。

手动将SQL Server安装到 Azure VM

如果计划手动在Azure VM 上安装SQL Server，请按照以下基本步骤避免常见的配置问题：

  • 确保已准备好用于安装的产品密钥。
  • 避免 不受支持的 配置，例如：
    • 每个 NUMA 节点的 vCore 数超过 64 个。
    • 扇区大小为 8 KB 的存储。
    • Azure 虚拟机规模集 (Virtual Machine Scale Sets)。
  • 如果它们尚不存在，请在启动安装媒体之前为SQL Server安装和数据文件创建文件夹。
  • 将安装介质复制到本地驱动器，而不是直接从装载的 ISO 进行安装。
  • 安装后，将 SQL Server VM 注册到 SQL Server IaaS 代理扩展以自动执行管理任务。
  • 尽可能将 tempdb 数据库放在 本地 SSD 临时存储 上。

VM 大小

警告

不支持将 tempdb 放置在具有未初始化临时磁盘的 Azure 虚拟机映像的本地临时磁盘上，例如 FXmdsv2。 此问题仅影响具有本地临时存储的新 NVMe 接口Azure Virtual Machines。 通过 Azure 门户进行这些部署可能会失败，SQL Server可能无法启动。 要么使用其他 VM 系列，要么在通过 Azure 门户部署 SQL Server 映像和手动安装 SQL Server 时，将 tempdb 放置在非临时存储上。 若要详细了解此问题，另请参阅受影响的 VM 列表，请查看 VM 部署和SQL Server故障。

本部分中的清单介绍了在 Azure 虚拟机上使用 SQL Server 的 VM 大小最佳实践。

  • 在选择 VM 大小之前，请配置 存储。 在最高压力条件下从源环境中收集 基线 ，然后使用 20% 缓冲区根据工作负荷的 IOPS 和吞吐量需求配置存储，以便将来增长。
  • 确定工作负荷性能特征（OLTP 与 OLAP，工作负荷大小）以确定适合企业的 VM 大小。
  • 如果要迁移到Azure，请评估迁移准备，以查找现有SQL Server工作负荷的正确 VM 大小，然后使用 Azure Database Migration Service 进行迁移。
  • 使用 Azure Marketplace 的映像来部署 SQL Server 虚拟机，因为 SQL Server 设置和存储选项已经过配置以实现最佳性能。
  • 使用具有 4 个或多个 vCore 的 VM 大小。
  • 使用内存优化虚拟机大小实现SQL Server工作负荷的最佳性能。
    • Mbdsv3 系列为任务关键型 OLTP 和数据仓库工作负荷提供最佳的整体性能。
    • Ebdsv5 系列为大多数生产 SQL Server 工作负荷提供最佳性价比。
    • M 系列系列为最大工作负荷提供Azure中最高的内存配置。
  • 使用较低层 D 系列或 B 系列启动开发环境，并随着时间的推移发展环境。
  • 检查 VM 可支持性以避免不受支持的配置。

存储

本部分中的清单介绍了 Azure VM 上SQL Server的 storage 最佳做法。

  • 在选择磁盘类型之前，监视应用程序和确定存储带宽和延迟要求SQL Server数据、日志和tempdb文件。
  • 如果可用，请在部署 tempdb时，或在手动安装SQL Server之后，在 D: 本地 SSD 卷上配置数据和日志文件。 SQL IaaS 代理扩展可处理重新预配时所需的文件夹和权限。
  • 为了优化存储性能，请规划可用的最高未缓存 IOPS，并使用数据缓存作为数据读取的性能功能，同时避免虚拟机和磁盘上限。
    • 将数据文件磁盘的主机缓存设置为“只读”。
    • 将日志文件磁盘的主机缓存设置为“无”。
      • 不要在包含SQL Server数据或日志文件的磁盘上启用读/写缓存。
      • 在更改磁盘的缓存设置之前，请始终停止SQL Server服务。
  • 如果工作负荷需要 160,000 IOPS 以上，请使用 Azure 超级磁盘。
  • 将数据、日志和 tempdb 文件放在不同的驱动器上。
    • 对于数据驱动器，可使用高级 P30 和 P40 或更小的磁盘，以确保缓存支持可用。
    • 对于日志驱动器，规划容量并测试性能与成本，同时评估高级 SSD P30 - P80 磁盘
      • 如果需要亚毫秒级存储延迟，请对事务日志使用 Azure 超级磁盘。
      • 对于 M 系列虚拟机部署，请考虑优先使用 写入加速器 而不是 Azure 超级磁盘。
    • 在选择最佳 VM 大小后，将tempdb放置在临时磁盘上（该磁盘为短暂的，并默认为D:\），适用于大多数不属于故障转移群集实例（FCI）的 SQL Server 工作负载。
      • 如果本地驱动器的容量对 tempdb 来说不足够，请考虑增加 VM 的大小。 有关详细信息，请参阅数据文件缓存策略。
    • 对于故障转移群集实例 (FCI)，请将 tempdb 放置在共享存储上。
      • 如果 FCI 工作负载严重依赖于 tempdb 磁盘性能，则将 tempdb 放置在本地临时 SSD（默认 D:\）驱动器（不是 FCI 存储的一部分）上，作为高级配置。 此配置需要专门的监控和干预措施，以确保本地临时 SSD（默认为 D:\）驱动器始终保持可用，因为即使该驱动器发生故障，也不会触发 FCI 的操作。
  • 使用 Storage Spaces条带化多个Azure数据磁盘，以将 I/O 带宽增加到目标虚拟机的 IOPS 和吞吐量限制。
  • 对于开发和测试工作负载和长期备份存档，请考虑使用标准存储。 不建议将标准 HDD/SSD 用于生产工作负载。
  • 基于额度的磁盘突发 (P1-P20) 仅应考虑用于较小的开发/测试工作负载和部门系统。
  • 将你的数据磁盘格式化为 64-KB 的分配单元大小，用于除临时 D:\ 驱动器（默认为 4 KB）以外的所有驱动器上放置的所有数据文件。 SQL Server VM 通过 Azure Marketplace 部署的附带数据磁盘，其分配单元大小和存储池的交错设置为 64 KB。
  • 在SQL Server VM 所在的同一区域中配置存储帐户。
  • 禁用Azure异地冗余存储（异地复制）并在存储帐户上使用 LRS（本地冗余存储）。
  • 启用 SQL 最佳做法评估以确定可能的性能问题，并评估SQL Server VM 是否配置为遵循最佳做法。
  • 使用存储 IO 利用率指标查看和监视磁盘和 VM 限制。
  • 将 SQL Server 文件排除在防病毒软件扫描之外，包括数据文件、日志文件和备份文件。
  • 适当调整存储池的大小。

安全性

本部分中的清单介绍了 Azure VM 上SQL Server SQL Server的安全最佳做法。

SQL Server特性和功能提供了在数据库级别保护数据的方法，这些数据可与基础结构级别的安全功能相结合。 总之，这些功能为基于云和混合的解决方案在基础结构级别提供了纵深防御。 此外，通过Azure安全措施，可以加密敏感数据，保护虚拟机免受病毒和恶意软件的侵害，保护网络流量，识别和检测威胁，满足合规性要求，并提供单一方法来管理和报告混合云中的任何安全需求。

  • 使用 Microsoft Defender for Cloud 评估和采取措施，改善数据环境的安全状况。 可以在混合工作负荷中使用 Azure Advanced Threat Protection （ATP） 等功能来改进安全评估，并能够应对风险。 将 SQL Server VM 注册到 SQL IaaS 代理扩展后，即可在 Azure 门户中的 SQL 虚拟机资源中显示 Microsoft Defender for Cloud 评估。
  • 使用 Microsoft Defender for SQL发现和缓解潜在的数据库漏洞，并检测可能指示SQL Server实例和数据库层威胁的异常活动。
  • 漏洞评估 是 Microsoft Defender for SQL 的一部分，可发现并帮助修正 SQL Server 环境的潜在风险。 它可让用户观察安全状态，并包含用于解决安全问题的可行步骤。
  • 如果使用的是 2022 SQL Server，请考虑使用 Microsoft Entra 身份验证连接到SQL Server实例。
  • Azure Advisor分析资源配置和使用情况遥测数据，然后建议可帮助你提高Azure资源的成本效益、性能、高可用性和安全性的解决方案。 使用虚拟机、资源组或订阅级别的Azure Advisor来帮助识别和应用最佳做法来优化Azure部署。
  • 如果您的合规性和安全性需求要求使用加密密钥对数据进行端到端加密，包括附加的临时（本地附加的临时）磁盘的加密，请使用 Azure 磁盘加密。
  • 默认情况下，Managed Disks使用 Azure Storage 服务加密进行静态加密，其中加密密钥Microsoft托管密钥存储在Azure中。
  • 有关托管磁盘加密选项的比较，请查看 托管磁盘加密比较图表。
  • 应在虚拟机上关闭管理端口 - 打开远程管理端口会导致 VM 面临基于 Internet 的攻击的严重风险。 此类攻击试图暴力破解凭据，来获取对计算机的管理员访问权限。
  • 为Azure虚拟机启用 实时 （JIT） 访问。
  • 通过 Remote Desktop 协议（RDP）使用 Azure Bastion。
  • 锁定端口，仅允许必须的应用流量通过，使用 Azure Firewall，这是一种托管防火墙即服务（FaaS），它基于源 IP 地址授予或拒绝服务器访问。
  • 使用 网络安全组（NSG）来筛选来自于和流向 Azure 虚拟网络上 Azure 资源的网络流量。
  • 使用应用程序安全组将端口筛选要求和功能类似的服务器（例如 Web 服务器和数据库服务器）分组到一起。
  • 使用 VM 扩展来帮助实现反恶意软件、所需状态、威胁检测、预防和修正，以解决操作系统、计算机和网络级别的威胁：
    • 来宾配置扩展在虚拟机内部执行审核和配置操作。
    • 适用于 Windows 和 Linux 的 Network Watcher 代理虚拟机扩展是一种网络性能、诊断和分析服务，它允许监视 Azure 网络。
    • Microsoft Windows有助于识别和删除具有可配置警报的病毒、间谍软件和其他恶意软件。
  • 使用 Azure Policy 创建可应用于环境的业务规则。 Azure策略通过将这些资源的属性与 JSON 格式定义的规则进行比较来评估Azure资源。
  • 将备份还原视为高风险操作，且切勿从不受信任的来源还原备份。

SQL Server功能

下面是在生产Azure虚拟机中运行SQL Server实例时SQL Server配置设置的最佳做法的快速清单：

Azure功能

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

HADR 配置

本部分中的清单介绍了在 Azure VM 上的 SQL Server 的 HADR 最佳做法。

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

对于Windows群集，请考虑以下最佳做法：

  • 尽可能将SQL Server VM 部署到多个子网，以避免依赖Azure Load Balancer或分布式网络名称（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 Load Balancer 连接到 HADR 解决方案时，即使群集仅包含一个子网，也请在连接字符串中指定 MultiSubnetFailover = true。
    • 如果客户端不支持 MultiSubnetFailover = True，你可能需要设置 RegisterAllProvidersIP = 0 和 HostRecordTTL = 300 来缓存较短持续时间内的客户端凭据。 但这样做可能会导致对 DNS 服务器进行其他查询。
  • 要使用分布式网络名称 (DNN) 连接到 HADR 解决方案，请考虑以下事项：
    • 必须使用支持 MultiSubnetFailover = True 的客户端驱动程序，并且此参数必须位于connection string中。
    • 连接到可用性组的 DNN 侦听器时，请在连接字符串中使用唯一的 DNN 端口。
  • 对基本可用性组使用数据库镜像连接字符串来避免对负载均衡器或 DNN 的需求。
  • 在部署高可用性解决方案之前，请验证 VHD 的扇区大小，以避免 I/O 未对齐的情况。 有关详细信息，请参阅 KB3009974。
  • 如果SQL Server数据库引擎、AlwaysOn 可用性组侦听器或故障转移群集实例运行状况探测配置为使用端口 49,152 到 65,536（ TCP/IP 的default 动态端口范围），请为每个端口添加排除项。 这样做可以防止其他系统被动态地分配到相同的端口。 下面的示例为端口 59999 创建一个排除项：
    netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

性能故障排除

遇到SQL Server性能问题时，请使用这些诊断资源来识别和解决特定问题：

相关内容

有关每个优化区域的详细指南：

推荐工具：启用 SQL 评估功能，以便在 Azure VM 上对 SQL Server 的配置进行自动化评估，并根据这些最佳实践进行检查。

在 SQL Server on Azure Virtual Machines 概述查看其他SQL Server虚拟机文章。 如果对 SQL Server 虚拟机 有疑问，请参阅 常见问题。

  • Last updated on