Google Cloud 中的 Microsoft SQL Server Always On 可用性组

Last reviewed 2026-08-12 UTC

本文档提供了一种参考架构,用于通过使用 Always On 可用性组在 Google Cloud 中部署高可用性 (HA) Microsoft SQL Server 数据库。本文档还介绍了高可用性和灾难恢复 (DR) 的设计注意事项、部署选项、自动化建议,以及 Backup and DR 操作指南。本文档适用于评估 Google Cloud 作为运行 SQL Server 数据库的平台的技术从业者。本教程假定您具备 Compute Engine 和 SQL Server 的基础知识。

Google Cloud 可提供经济高效、安全可靠且性能卓越的解决方案,用于运行 SQL Server 数据库。如需简要了解 Google Cloud中支持的 SQL Server 解决方案,请参阅 Google Cloud上的 SQL Server。

如需在 Google Cloud中运行 SQL Server 的非开发部署,请使用以下许可选项之一:

  • 自带许可 (BYOL):将现有的 Microsoft SQL Server 许可自带到 Google Cloud。您必须使用单租户节点或通过软件保障实现许可移动性。

  • 使用按需许可:在 Google Cloud 中使用预构建的 SQL Server 映像,并支付包含计算费用和 Microsoft 许可费用的费用。Google 负责处理 Microsoft 许可协议和结算事宜。

本文档的部署部分提供了可帮助您部署此参考架构的资源。

架构

下图展示了 Google Cloud中高可用性配置的 SQL Server 部署的参考架构:

此架构展示了 SQL Server 部署,其中包含一个跨不同可用区和区域中的 Compute Engine 虚拟机的 Always On 可用性组。

上述架构展示了 Windows Server 故障切换集群 (WSFC) 中具有三个节点的 Always On 可用性组。每个节点都是运行 SQL Server 的 Compute Engine 虚拟机。

Always On 可用性组是一种业界标准部署模式,可实现任务关键型 SQL Server 数据库的可靠性目标。Always On 可用性组提供本地高可用性(区域内故障切换)和跨区域故障切换,以实现灾难恢复。此部署模式是数据库镜像的企业级替代方案。Always On 可用性组具有以下优势:

  • 无需专门的基础设施组件:SQL Server 会管理所有已配置的数据库副本之间的复制。
  • SQL Server 的最高 SLA 配置:恢复时间目标 (RTO) 不到一分钟,恢复点目标 (RPO) 接近于零。
  • 能够将只读工作负载分流到次要副本:高效扩缩部署,以满足分析和其他常见应用场景的需求。
  • 其他区域中用于灾难恢复的节点:部署一个主要副本和最多八个次要副本。
  • 可在 Windows 和 Linux 上部署:您可以使用 Pacemaker 等第三方工具作为 Linux 部署的集群管理器。

在上述架构中,主 SQL Server 节点和辅助 SQL Server 节点位于一个区域内的不同可用区中。灾难恢复节点位于地理位置遥远的区域。主节点中的数据会同步复制到次要节点,并异步复制到灾难恢复节点。

如需将流量从应用层分发到区域内的主数据库节点和辅助数据库节点,您可以使用以下方法之一:

使用的产品

该架构使用以下 Google Cloud 和 Microsoft 产品及组件。

Google Cloud 产品

  • Compute Engine:一项安全且可自定义的计算服务,可让您在 Google 的基础设施上创建并运行虚拟机。
  • Google Cloud Hyperdisk:一种网络存储服务,可用于预配和动态扩缩块存储卷,具有可配置且可预测的性能。
  • Virtual Private Cloud (VPC):为您的 Google Cloud 工作负载提供全球可扩缩的网络功能的虚拟系统。VPC 包括 VPC 网络对等互连、Private Service Connect、专用服务访问通道和共享 VPC。
  • Cloud Load Balancing:一组高性能、可扩缩的全球和区域级负载均衡器。

Microsoft 产品和组件

SQL Server 节点上包含或启用了以下组件:

  • Windows Server(2019 版或更高版本)。
  • WSFC:一组 SQL Server 实例,安装在多个 Windows Server 集群节点或多个子网中。
  • Always On 可用性组:数据库镜像的企业级高可用性和灾难恢复替代方案。
  • 可用性组监听器:一个虚拟网络名称 (VNN),客户端可以使用该名称访问 Always On 可用性组的主副本或辅助副本中的数据库。客户端无需知道副本的物理实例名称。由于监听器会路由流量,因此在故障切换后无需修改客户端连接字符串。

部署此架构需要以下其他组件:

设计考虑事项

本部分介绍了一些设计因素、最佳实践和设计建议,您在使用此参考架构开发满足可靠性、运营效率、安全性、费用和性能要求的拓扑时应考虑这些内容。

可靠性

本部分介绍了在Google Cloud中为 SQL Server 部署构建和运营可靠的基础设施的设计注意事项和建议。

选择高可用性和灾难恢复策略

如需在 Google Cloud中部署可靠的 SQL Server 数据库,您需要一种将 Google Cloud 的强大基础架构与 SQL Server 的高可用性和灾难恢复功能相结合的策略。这种组合可保护您的数据库免受从可用区级服务中断到区域级灾难等各种故障的影响。

在为 SQL Server 部署设计高可用性和灾难恢复策略时,请考虑以下因素:

  • RPO:发生故障时,可接受的数据丢失量是多少?
  • RTO:发生故障后,数据库需要多快才能再次运行?
    • 如需实现低 RTO,请使用 Always On 可用性组。
    • 如果可以接受一些停机时间,请从备份中恢复数据库,或使用日志传送和手动故障切换。
  • 预算:考虑成本与可靠性之间的权衡。
    • 成本高但可靠:使用 Always On 可用性组,将数据异步复制到灾难恢复区域中的其他节点。规划冗余基础设施和许可。
    • 中等成本:实现到其他区域的异步磁盘复制,或使用 Backup and DR。
    • 费用低但恢复时间长:将数据库备份到多区域 Cloud Storage 存储桶。
  • 故障类型:您需要处理哪些类型的故障?
    • 如需处理硬件级、实例级和可用区级故障,您可以使用可用性组。
    • 如需从网站级服务中断或灾难中恢复,您需要一个地理位置分散的灾难恢复解决方案,例如日志传送或具有异步数据库复制功能的 Always On 可用性组。
  • 业务关键性:应用对您的业务有多重要?
    • 任务关键型应用需要一种能够提供最高可用性、最少数据丢失和快速恢复的策略。
    • 对于不太重要的系统,请考虑采用假设可接受停机时间或部分数据丢失的策略。

使用以下决策流程问卷,为您的 SQL Server 数据库选择最佳可靠性策略。策略选项包括提供近乎零数据丢失的 Always On 可用性组,以及经济实惠的异地备份。

  1. 异地备份是否符合您的 RPO 和 RTO?
    • 是:使用异地备份或日志传送。
    • 否:请继续回答下一个问题。
  2. 您的 RTO 或 RPO 是否小于 1 分钟?
    • 是(RPO 接近于零):使用具有灾难恢复数据库副本的 SQL Server Always On 可用性组。
    • 否:请继续回答下一个问题。
  3. 您的 RTO 是多少?
    • 不到 5 分钟:使用具有异步磁盘副本的 SQL Server Always On 可用性组。
    • 1 小时或更长时间:请继续回答下一个问题。
  4. 您的 RPO 是多少?
    • 不到两小时:将 SQL Server Always On 可用性组与 Backup and DR 搭配使用。
    • 8 小时或更长时间:使用异地备份或日志传送。

选择适当的备份选项

如果您的可靠性策略包括数据库备份,请选择满足您要求的备份方法。 Google Cloud 提供了以下灵活且企业就绪的选项来备份 SQL Server 数据库:

  • 直接备份到 Cloud Storage 存储桶:使用 SQL Server(2022 版或更高版本)中的 BACKUP TO URL 命令和 S3 连接器,将数据库备份直接写入 Cloud Storage。对于生产环境,您可以使用基于哈希的消息认证码 (HMAC) 访问密钥。此备份选项可为数据库和日志提供经济实惠的保护,而无需中间本地存储。
  • Compute Engine 即时快照:通过使用 Transact-SQL (T-SQL) 冻结-解冻操作以及 Compute Engine 一致性组,在不到一秒的时间内跨多个磁盘(例如,跨 Google Cloud Hyperdisk Balanced 磁盘)捕获同步快照。此选项可为多磁盘数据库实现高性能虚拟机级备份,并且具有接近零的写入冻结要求。
  • Backup and DR:使用 Microsoft VSS 提供程序和一致性组编排应用一致性快照。当您需要精细的多数据库时间点恢复 (PITR) 以及使用日志前滚数据库的功能时,此备份选项非常合适。
  • Google Cloud NetApp Volumes:使用 ONTAP 存储引擎创建即时快照和异步备份到远程保险柜。对于需要快速缓解勒索软件和节省空间的克隆的延迟敏感型企业应用,我们建议使用 NetApp Volumes。

对于需要统一数据保护政策的多云和混合部署,您可以选择第三方备份产品,例如 Veeam、Veritas NetBackup 或 Cohesity。

操作

为确保在 Compute Engine 虚拟机上部署的 SQL Server 数据库具有高可用性和最佳性能,请使用 Cloud Monitoring 和 Cloud Logging 设置全面的监控和提醒系统。

  • 持续跟踪核心资源的指标,例如 CPU 利用率和内存负载。设置基准提醒,以便在查询开始降级之前检测资源压力。
  • 为防止数据库写入操作停止,请持续观察磁盘空间利用率。监控整体服务状态,并设置提醒,以便在数据库意外停止时收到通知。
  • 对于高可用性部署,请跟踪所有计划外故障切换,并确保在自动灾难恢复事件期间实现完全可见性。
  • 除了系统级遥测之外, Google Cloud 还提供了一套广泛的数据库特定指标,例如活跃用户连接限制、复制延迟时间和事务速率。跟踪这些指标,以监控 SQL Server 数据库的可用性和性能。
  • 如需直接从 SQL Server 错误日志中捕获应用级错误(例如死锁、数据库损坏和代理作业失败),请在 Logging 中设置基于日志的自定义提醒。

安全

本部分介绍了在 Google Cloud 中设计满足工作负载安全要求的 SQL Server 部署的设计注意事项和建议。

网络安全和隔离

  • 为防止数据库对外公开,请在 VPC 中部署具有专用 IP 地址的 SQL Server 实例。使用专用服务访问通道在内部路由流量。此方法有助于确保数据库流量绝不会遍历公共互联网。
  • 通过配置严格的 VPC 防火墙规则,仅允许来自已获授权的应用子网或特定 CIDR 块的流量,从而进一步限制对数据库的访问。
  • 为保护传输中的数据免遭窃听和拦截,请对所有数据库连接强制执行 TLS/SSL,以实现加密连接。

加密和密钥控制

  • 默认情况下, Google Cloud 使用 Google 管理的 AES-256 密钥自动加密数据库磁盘、临时文件和备份中的所有静态数据。为了帮助满足合规性环境,您可以使用 SQL Server 的透明数据加密 (TDE) 功能实现数据库级加密。
  • 为帮助确保数据主权,您可以在 Cloud Key Management Service 中使用客户管理的加密密钥 (CMEK)。CMEK 可让您完全掌控加密。您可以管理密钥生命周期、设置自动轮替时间表,并在需要时立即撤消对数据库及其备份的访问权限。

身份验证和授权

  • 将数据库与 Microsoft Active Directory 集成,或使用 Identity and Access Management (IAM) 集中管理 SQL Server 数据库和其他Google Cloud 资源的身份。
  • 建立身份后,应用最小权限原则,以便用户和应用服务账号仅具有执行其功能所需的权限。将身份映射到精细的 SQL Server 数据库角色。

费用优化

本部分将指导您优化使用此参考架构构建的 SQL Server 部署的设置和运营费用。费用优化有助于确保部署在预算限制范围内满足工作负载的可靠性和性能要求。

请考虑以下建议:

  • 停用并发多线程 (SMT):通过停用 SMT,您可以将出于许可目的而报告的核心数减少 50%。通过将 CPU 超额预配 20%,然后停用 SMT,您可以在不牺牲性能的情况下大幅节省许可费用。如需了解详情,请参阅设置每个核心的线程数。
  • 使用 SQL Server Standard 版本:根据您的 HA 和 DR 要求,您可以使用 SQL Server Standard 版本(而非 Enterprise 版本)来降低许可费用。如需了解详情,请参阅 SQL Server 的版本和支持的功能。
  • 优化存储:Google Cloud Hyperdisk 提供不同的磁盘选项,您可以根据 SQL Server 部署的需求进行选择。Hyperdisk Balanced 可在费用和性能之间取得平衡。您可以单独扩缩吞吐量和每秒输入/输出操作数 (IOPS),以便您的基础架构支出与工作负载的需求精确匹配。如需了解详情,请参阅选择适当的存储磁盘类型部分。

性能优化

本部分介绍了满足性能要求的 SQL Server 部署的设计注意事项和建议。

通过在 Compute Engine 虚拟机上部署 SQL Server,您可以完全控制数据库和底层基础架构。工作负载的性能取决于您选择的基础设施。为了在性能、成本和可靠性之间取得平衡,您需要就虚拟机机器家族和数据库节点的磁盘类型做出明智的决策。

选择合适的虚拟机机器家族

您为 Compute Engine 虚拟机选择的机器家族决定了 SQL Server 节点可用的处理能力 (vCPU) 和内存 (RAM)。这些资源会影响数据库的性能。

选择可解决主要性能瓶颈的虚拟机机器家族。例如,如果您的 SQL Server 数据库始终处于高 CPU 使用率状态,请从计算优化机器家族中选择一种机器类型。如果您的 SQL Server 数据库显示从磁盘读取的速度较慢,请选择内存优化机器类型。

下表比较了 Compute Engine 提供的虚拟机机器系列、每个机器系列的主要用例以及对 SQL Server 数据库的性能影响:

机器家族和系列 主要用途 对 SQL Server 性能的影响
通用(N4 机器系列) 兼顾价格和性能 对于大多数工作负载,请使用此机器家族作为起点。N4 机器系列为混合用途数据库、Web 应用和开发或测试环境提供了 CPU 和内存的最佳平衡。
计算优化型(C3 或 C4 机器系列) 每核心性能最高 此机器家族适用于 CPU 密集型工作负载。对于执行复杂查询、处理大量数据或处理大量在线事务处理 (OLTP) 操作的数据库,请使用 C3 和 C4 机器系列。这些系列中的机器类型有助于显著缩短查询执行时间。
内存优化型(M3 或 M4 机器系列) 内存与 vCPU 比率较高 此机器家族非常适合内存密集型应用。SQL Server 会在内存中缓存数据和执行计划,这比从磁盘读取数据和执行计划具有更高的性能。对于用于在线分析处理 (OLAP) 的超大型数据库或数据仓库,查询通常会扫描大型表和数据集。对于此类用例,增加内存有助于提高性能。

如需了解详情,请参阅机器家族资源和比较指南。

选择适当的存储磁盘类型

磁盘性能是影响数据库响应能力的重要因素,而数据库响应能力对应用性能至关重要。对于 Google Cloud提供的磁盘类型,性能功能通过以下指标表示:

  • IOPS:磁盘每秒可处理的读写请求数。IOPS 对于涉及许多小型随机读写操作(例如更新客户记录或处理订单)的 OLTP 工作负载至关重要。
  • 吞吐量:每秒可移入或移出磁盘的数据总量。吞吐量对于涉及扫描大量数据的 OLAP 工作负载(例如运行报告、数据仓储或执行备份)至关重要。

下表对可供选择的 Google Cloud 磁盘类型进行了比较:

磁盘类型 性能特征 工作负载适用性
SSD 永久性磁盘 (pd-ssd) 中到高性能,具体取决于虚拟机机器类型和磁盘大小 需要性能随磁盘大小和虚拟机 vCPU 数量而调节的工作负载。如需了解详情,请参阅 Persistent Disk 性能概览。
Hyperdisk Balanced 高性能,具有可配置的 IOPS 和吞吐量 生产环境 SQL Server 数据和日志文件。借助 Hyperdisk Balanced,您可以根据工作负载的需求,独立于磁盘大小配置 IOPS 和吞吐量。
Google Cloud Hyperdisk Extreme 性能极高,IOPS 可配置 需要最大 IOPS 和最低延迟的高端、任务关键型 OLTP 工作负载,例如大规模金融或电子商务系统。
本地 SSD 与其他磁盘类型相比,IOPS 和吞吐量最高 不需要永久性磁盘耐用性的临时数据。对于 tempdb 系统数据库和 Windows 页面文件等数据,本地 SSD 可提供最低的延迟,因为它们以物理方式挂接到虚拟机。

使基础架构与性能要求相匹配

根据工作负载的性能要求选择虚拟机机器类型和磁盘类型。下表针对不同的工作负载场景推荐了基础架构配置:

场景 性能要求 建议的机器类型和磁盘配置
适用于 OLTP 的高事务电子商务数据库 高 IOPS,可处理数千个小型并发读写操作

虚拟机机器类型:选择计算优化机器类型(例如 C4 机器系列),以高效处理事务。

数据和日志磁盘:使用 Hyperdisk Balanced 磁盘。预配高水平的 IOPS,以满足事务需求。为数据和日志使用单独的磁盘。

tempdb:使用本地 SSD 磁盘来分流临时操作并最大限度地提高性能。

用于 OLAP 的公司数据仓库 高吞吐量,可扫描和汇总数 TB 的数据以生成报告

虚拟机机器类型:选择内存优化机器类型(例如 M4 机器系列),以便尽可能多地缓存大型数据集。

数据磁盘:使用 Hyperdisk Balanced 磁盘。 预配高吞吐量,以加快大型数据扫描。

开发或预演服务器 成本效益,而非峰值性能

虚拟机机器类型:从 E2 或 N4 机器系列中选择机器大小较小的通用机器类型。

磁盘:对所有数据库文件使用平衡永久性磁盘 (pd-balanced),以便以较低的成本实现可接受的性能。

部署

如需部署此参考架构,请使用以下资源之一:

后续步骤

贡献者

作者:

其他贡献者:Kumar Dhanagopal | 跨产品解决方案开发者