本文档提供了一种参考架构，用于在 Google Cloud 中使用 Always On 可用性组部署高可用性 (HA) Microsoft SQL Server 数据库。该文档还包括有关高可用性 (HA) 和灾难恢复 (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 部署的参考架构：
上述架构展示了一个 Windows Server 故障转移集群 (WSFC) 中包含三个节点的 Always On 可用性组。每个节点都是运行 SQL Server 的 Compute Engine 虚拟机。
Always On 可用性组是一种行业标准部署模式，可实现任务关键型 SQL Server 数据库的可靠性目标。Always On 可用性组可提供本地高可用性（区域内故障切换）和跨区域故障切换，以实现灾难恢复。此部署模式是数据库镜像的企业级替代方案。Always On 可用性组具有以下优势：
- 无需专门的基础设施组件：SQL Server 可管理所有已配置的数据库副本之间的复制。
- SQL Server 的最高 SLA 配置：恢复时间目标 (RTO) 不到 1 分钟，恢复点目标 (RPO) 接近于零。
- 能够将只读工作负载分流到辅助副本：高效扩展部署，以满足分析和其他常见应用场景的需求。
- 用于灾难恢复的其他区域中的节点：部署一个主副本和最多八个辅助副本。
- 可部署在 Windows 和 Linux 上：您可以将 Pacemaker 等第三方工具用作 Linux 部署的集群管理器。
在上述架构中，主 SQL Server 节点和辅助 SQL Server 节点位于同一区域内的不同可用区中。DR 节点位于地理位置较远的区域。主节点中的数据会同步复制到次节点，并异步复制到灾难恢复节点。
如需将应用层的流量分配到区域内的主数据库节点和辅助数据库节点，您可以使用以下方法之一：
- 一个内部负载均衡器，如架构图所示。
- 分布式网络名称 (DNN) 监听器和 DNS 服务器。
使用的产品
该架构使用以下 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：一组安装在多个 Windows Server 集群节点或多个子网中的 SQL Server 实例。
- Always On 可用性组：一种企业级高可用性和灾难恢复替代方案，可替代数据库镜像。
- 可用性组侦听器：虚拟网络名称 (VNN)，客户端可使用该名称访问 Always On 可用性组的主副本或辅助副本中的数据库。客户端无需知道副本的物理实例名称。由于监听器会路由流量，因此在故障切换后无需修改客户端连接字符串。
部署此架构需要以下其他组件：
- Active Directory 网域服务：一种 Windows Server 目录服务，用于管理网域中常见的资源，例如计算机、角色和用户。
- DNS：将域名解析为相应 IP 地址的服务器。
- 仲裁见证：可以是服务器消息块 (SMB) 文件共享或本地连接的共享磁盘。
设计考虑事项
本部分介绍了一些设计因素、最佳实践和设计建议，您在使用此参考架构开发满足可靠性、运营效率、安全性、费用和性能要求的拓扑时应考虑这些内容。
可靠性
本部分介绍在Google Cloud中为 SQL Server 部署构建和运营可靠的基础设施时应考虑的设计因素和建议。
选择高可用性和灾难恢复策略
如需在 Google Cloud中部署可靠的 SQL Server 数据库，您需要制定一种策略，将 Google Cloud 的强大基础设施与 SQL Server 的高可用性和灾难恢复功能相结合。这种组合可保护您的数据库免受各种故障的影响，从可用区中断到区域性灾难。
在为 SQL Server 部署设计 HA 和 DR 策略时，请考虑以下因素：
- RPO：发生故障时，可以接受多少数据丢失？
- 如需实现较低的 RPO（接近于零的数据丢失），请使用具有同步复制功能的 Always On 可用性组。
- 如果您可以容忍一定程度的数据丢失，请使用以下方法之一：异步复制、Backup and DR Service、备份到 Cloud Storage 存储桶或日志传送。
- RTO：发生故障后，数据库需要多快才能恢复运行？
- 如需实现较低的 RTO，请使用 Always On 可用性组。
- 如果可以接受一定的停机时间，请从备份中恢复数据库，或使用日志传送和手动故障切换。
- 预算：考虑成本与可靠性之间的权衡。
- 成本高但可靠：使用 Always On 可用性组，通过异步复制将数据复制到灾难恢复区域中的其他节点。规划冗余的基础设施和许可。
- 中等成本：实现跨区域的异步磁盘复制或使用 Backup and DR Service。
- 成本低但恢复时间长：将数据库备份到多区域 Cloud Storage 存储桶。
- 故障类型：您需要处理哪些类型的故障？
- 如需处理硬件级、实例级和可用区级故障，您可以使用可用性组。
- 为了从网站级中断或灾难中恢复，您需要一个地理位置分散的灾难恢复解决方案，例如日志传送或使用异步数据库复制的 Always On 可用性组。
- 业务关键性：应用对您的业务有多重要？
- 任务关键型应用需要一种可提供最高可用性、最低数据丢失和快速恢复的策略。
- 对于不太重要的系统，可以考虑采用假设停机时间或数据丢失量在可接受范围内的策略。
请回答以下决策流程问卷，为您的 SQL Server 数据库选择最佳可靠性策略。策略选项的范围从提供近乎零数据丢失的 Always On 可用性组到经济高效的异地备份。
- 异地备份是否符合您的 RPO 和 RTO？
- 可以：使用异地备份或日志传送。
- 否：请继续回答下一个问题。
- 您的 RTO 或 RPO 是否小于 1 分钟？
- 可以（接近零 RPO）：使用 SQL Server Always On 可用性组和灾难恢复数据库副本。
- 否：请继续回答下一个问题。
- 您的 RTO 是多少？
- 不到 5 分钟：使用具有异步磁盘副本的 SQL Server Always On 可用性组。
- 一小时或更长时间：请继续回答下一个问题。
- 您的 RPO 是多少？
- 不到 2 小时：使用 SQL Server Always On 可用性组和 Backup and DR Service。
- 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 一致性组相结合，在不到一秒的时间内跨多个磁盘（例如 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 错误日志中捕获应用级错误（例如死锁、数据库损坏和代理作业失败），请在 Cloud 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 版：您可以根据自己的高可用性和灾难恢复要求，使用 SQL Server Standard 版（而非 Enterprise 版）来降低许可费用。如需了解详情，请参阅 SQL Server 的各版本和支持的功能。
- 优化存储：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：磁盘每秒可处理的读取和写入请求数。对于涉及许多小型随机读写操作（例如更新客户记录或处理订单）的 OLTP 工作负载，IOPS 至关重要。
- 吞吐量：每秒可移入或移出磁盘的数据总量。吞吐量对于涉及扫描大量数据的 OLAP 工作负载（例如运行报告、数据仓储或执行备份）至关重要。
下表比较了可供选择的 Google Cloud 磁盘类型：
| 磁盘类型 | 性能特征 | 工作负载适用性 |
|---|---|---|
SSD 永久性磁盘 (pd-ssd) |
中到高，具体取决于虚拟机机器类型和磁盘大小 | 需要性能随磁盘大小和虚拟机 vCPU 数量而调节的工作负载。如需了解详情，请参阅永久性磁盘性能概览。 |
| Hyperdisk Balanced | 高性能，IOPS 和吞吐量可配置 | 生产 SQL Server 数据和日志文件。借助 Hyperdisk Balanced，您可以根据工作负载的需求，独立于磁盘大小来配置 IOPS 和吞吐量。 |
| Hyperdisk Extreme | 性能极高，IOPS 可配置 | 需要最高 IOPS 和最低延迟的高端任务关键型 OLTP 工作负载，例如大规模金融或电子商务系统。 |
| 本地 SSD | 与其他磁盘类型相比，IOPS 和吞吐量最高 | 不需要永久性磁盘耐用性的临时数据。对于 tempdb 系统数据库和 Windows 页面文件等数据，本地 SSD 可提供最低延迟，因为它们以物理方式连接到虚拟机。 |
根据性能要求选择相应的基础设施
根据工作负载的性能要求选择虚拟机机器类型和磁盘类型。下表针对不同的工作负载场景推荐了相应的基础设施配置：
| 场景 | 性能要求 | 建议的机器类型和磁盘配置 |
|---|---|---|
| 适用于 OLTP 的高交易量电子商务数据库 | 高 IOPS，可处理数千次并发的小规模读写操作 |
虚拟机机器类型：选择计算优化机器类型（例如，来自 C4 机器系列），以便高效处理交易。 数据磁盘和日志磁盘：使用 Hyperdisk Balanced 磁盘。预配高水平的 IOPS，以满足事务需求。使用单独的磁盘存储数据和日志。
|
| 用于 OLAP 的公司数据仓库 | 高吞吐量，可扫描和汇总数 TB 的数据以生成报告 |
虚拟机机器类型：选择内存优化机器类型（例如 M4 机器系列），以便尽可能多地缓存大型数据集。 数据磁盘：使用 Hyperdisk Balanced 磁盘。 提供高吞吐量，以加快大型数据扫描速度。 |
| 开发服务器或预发布服务器 | 成本效益而非峰值性能 | 虚拟机机器类型：从 E2 或 N4 机器系列中选择一种机器规模较小的通用机器类型。 磁盘：为所有数据库文件使用平衡永久性磁盘 ( |
部署
如需部署此参考架构，请使用以下资源之一：
- 基础设施即代码 (IaC)：使用 Terraform 配置在 Google Cloud中预配 SQL Server 集群。该配置包括用于配置必要组件的 PowerShell 预期状态配置 (DSC) 和 bash 脚本。您可以根据配置需求下载并修改代码。
- 引导式工作流：使用 Workload Manager 以单节点或集群配置部署 SQL Server。
- 教程：按照分步指南使用内部负载均衡器配置带有同步提交功能的 SQL Server Always On 可用性组。
后续步骤
- 了解 Google Cloud上 SQL Server 的许可和映像选项。
- 查看灾难恢复规划指南。
- 了解 Microsoft SQL Server 的灾难恢复。
- 了解如何部署 Microsoft SQL Server 来进行多地区灾难恢复。
- 了解如何在 Compute Engine 实例之间共享磁盘。
- 如需查看更多参考架构、图表和最佳做法，请浏览云架构中心。
贡献者
作者：
- Tom Niedzielak | 资深系统开发工程师
- Sung Baek | 软件工程师
其他贡献者：Kumar Dhanagopal | 跨产品解决方案开发者