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

Last reviewed 2026-08-12 UTC

本文件提供參考架構,說明如何使用 Always On 可用性群組,在 Google Cloud 中部署高可用性 (HA) Microsoft SQL Server 資料庫。這份文件也包含高可用性和災難復原 (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 部署作業,其中包含 Always On 可用性群組,橫跨不同可用區和區域中的 Compute Engine VM。

上述架構顯示 Windows Server 容錯移轉叢集 (WSFC) 中具有三個節點的 Always On 可用性群組。每個節點都是執行 SQL Server 的 Compute Engine VM。

Always On 可用性群組是業界標準的部署模式,可達成重要業務 SQL Server 資料庫的可靠性目標。Always On 可用性群組提供本機高可用性 (區域內容錯移轉)「和」跨區域容錯移轉,可用於災難復原。這種部署模式是企業級的資料庫鏡像替代方案。Always On 可用性群組具有下列優點:

  • 不需要專門的基礎架構元件:SQL Server 會管理所有已設定資料庫副本的複製作業。
  • SQL Server 的最高服務水準協議設定:復原時間目標 (RTO) 少於一分鐘,復原點目標 (RPO) 接近零。
  • 可將唯讀工作負載卸載至次要副本:有效率地擴充部署作業,以便進行數據分析和其他常見用途。
  • 其他區域的災難復原節點:部署一個主要副本和最多八個次要副本。
  • 可在 Windows 和 Linux 上部署:您可以使用 Pacemaker 等第三方工具,做為 Linux 部署作業的叢集管理工具。

在上述架構中,主要和次要 SQL Server 節點位於區域內的不同可用區。DR 節點位於地理位置偏遠的區域。主要節點的資料會同步複製到次要節點,並以非同步方式複製到災難復原節點。

如要將流量從應用程式層分配到區域內的主要和次要資料庫節點,可以使用下列其中一種方法:

使用的產品

此架構使用下列 Google Cloud 和 Microsoft 產品與元件。

Google Cloud 產品

  • Compute Engine:安全可靠且可自訂的運算服務,可讓您透過 Google 的基礎架構建立及執行 VM。
  • Google Cloud Hyperdisk:這項網路儲存空間服務可讓您佈建及動態擴充區塊儲存空間磁碟區,並提供可設定且可預測的效能。
  • 虛擬私有雲 (VPC):虛擬系統,為 Google Cloud 工作負載提供可擴充的全球網路功能。虛擬私有雲包含虛擬私有雲網路對接、Private Service Connect、私人服務存取權和 Shared 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 可用性群組,以非同步方式複製到 DR 區域中的其他節點。規劃備援基礎架構和授權。
    • 中等成本:實作非同步磁碟複製至其他區域,或使用備份和災難復原。
    • 成本低但復原時間長:將資料庫備份至多區域 Cloud Storage bucket。
  • 失敗類型:您需要處理哪些類型的失敗?
    • 如要處理硬體層級、執行個體層級和可用區故障,可以使用可用性群組。
    • 如要從整個網站服務中斷或災難中復原,您需要分散在不同地理位置的災難復原解決方案,例如記錄傳送或具有非同步資料庫複製功能的 Always On 可用性群組。
  • 業務重要性:應用程式對業務有多重要?
    • 重要業務應用程式需要一套策略,提供最高層級的可用性、最低限度的資料遺失,以及快速復原。
    • 對於較不重要的系統,請考慮採用假設可接受停機時間或部分資料遺失的策略。

請使用下列決策流程問卷,為 SQL Server 資料庫選擇最佳可靠性策略。策略選項包括提供近乎零資料遺失的 Always On 可用性群組,以及符合成本效益的異地備份。

  1. 異地備份是否符合 RPO 和 RTO?
    • 是:使用異地備份或記錄傳送。
    • 否:繼續回答下一個問題。
  2. RTO 或 RPO 是否小於一分鐘?
    • 是 (RPO 接近零):使用 SQL Server Always On 可用性群組和災難復原資料庫副本。
    • 否:繼續回答下一個問題。
  3. 您的 RTO 為何?
    • 不到五分鐘:使用 SQL Server Always On 可用性群組,搭配非同步磁碟副本。
    • 一小時以上:繼續回答下一個問題。
  4. 您的 RPO 為何?
    • 不到兩小時:使用 SQL Server Always On 可用性群組搭配 Backup and DR。
    • 八小時以上:使用異地備份或記錄傳送。

選擇合適的備份選項

如果可靠性策略包含資料庫備份,請選擇符合需求的備份方法。 Google Cloud 提供下列彈性且適合企業使用的 SQL Server 資料庫備份選項:

  • 直接備份至 Cloud Storage bucket:使用 BACKUP TO URL 指令和 SQL Server (2022 以上版本) 的 S3 連接器,直接將資料庫備份寫入 Cloud Storage。如果是正式環境,您可以使用雜湊式訊息驗證碼 (HMAC) 存取金鑰。這個備份選項可為資料庫和記錄提供符合成本效益的保護,不需要中繼本機儲存空間。
  • Compute Engine 即時快照:使用 Transact-SQL (T-SQL) 凍結/解凍作業,搭配 Compute Engine 一致性群組,在不到一秒的時間內,同時擷取多個磁碟 (例如 Google Cloud Hyperdisk Balanced 磁碟) 的快照。這個選項可為多磁碟資料庫提供高效能的 VM 層級備份,且幾乎不需要寫入凍結。
  • 備份和災難復原:使用 Microsoft VSS 供應商和一致性群組,自動執行與應用程式一致的快照。如果您需要精細的多資料庫時間點復原 (PITR) 功能,以及使用記錄向前復原資料庫的能力,則適合使用這個備份選項。
  • Google Cloud NetApp Volumes:使用 ONTAP 儲存引擎,建立即時快照和非同步備份,並傳送至遠端保管庫。如果企業應用程式對延遲時間較為敏感,且需要快速緩解勒索軟體攻擊,以及節省空間的複製功能,建議使用 NetApp Volumes。

如果多雲端和混合式部署需要統一的資料保護政策,您可以選擇第三方備份產品,例如 Veeam、Veritas NetBackup 或 Cohesity。

作業

為確保部署在 Compute Engine VM 上的 SQL Server 資料庫具備高可用性和最佳效能,請使用 Cloud Monitoring 和 Cloud Logging 設定完善的監控和警告系統。

  • 持續追蹤核心資源的指標,例如 CPU 使用率和記憶體負載。設定基準快訊,在查詢效能開始下降前,偵測資源壓力。
  • 為避免資料庫寫入作業中斷,請持續觀察磁碟空間使用率。監控整體服務狀態,並設定快訊,在資料庫意外停止時接收通知。
  • 如果是高可用性部署作業,請追蹤所有非預期的容錯移轉,並確保在自動災難復原事件期間,能完整掌握相關資訊。
  • 除了系統層級的遙測資料外, Google Cloud 還提供一系列廣泛的資料庫專屬指標,例如活躍使用者連線限制、複製延遲和交易率。追蹤這些指標,監控 SQL Server 資料庫的可用性和效能。
  • 如要直接從 SQL Server 錯誤記錄擷取應用程式層級錯誤,例如死結、資料庫損毀和代理程式工作失敗,請在 Logging 中設定自訂記錄指標警告。

安全性

本節說明設計考量和建議,協助您在 Google Cloud 中設計符合工作負載安全性需求的 SQL Server 部署作業。

網路安全與隔離

  • 為防止資料庫對外公開,請在虛擬私有雲中部署具有私人 IP 位址的 SQL Server 執行個體。使用私人服務存取權在內部轉送流量。這種做法可確保資料庫流量不會經過公開網際網路。
  • 設定嚴格的虛擬私有雲防火牆規則,只允許來自授權應用程式子網路或特定 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 Edition:視高可用性和災難復原需求而定,您可以使用 SQL Server Standard Edition,而非 Enterprise Edition,藉此降低授權費用。詳情請參閱「SQL Server 的版本和支援功能」。
  • 最佳化儲存空間:Google Cloud Hyperdisk 提供不同的磁碟選項,您可以根據 SQL Server 部署作業的需求選擇。Hyperdisk Balanced 可在成本與效能之間取得平衡。您可以分別調度總處理量和每秒輸入/輸出作業數 (IOPS),讓基礎架構支出精準符合工作負載需求。詳情請參閱「選擇合適的儲存磁碟類型」一節。

效能最佳化

本節說明 SQL Server 部署作業的設計考量和建議,協助您滿足效能需求。

在 Compute Engine VM 上部署 SQL Server,即可完整控管資料庫和基礎架構。工作負載的效能取決於您選擇的基礎架構。為了在效能、成本和可靠性之間取得平衡,您必須針對 VM 機器系列和資料庫節點的磁碟類型,做出明智的決策。

選擇合適的 VM 機器家族

您為 Compute Engine VM 選擇的機器家族,會決定 SQL Server 節點可用的處理能力 (vCPU) 和記憶體 (RAM)。這些資源會影響資料庫的效能。

選擇可解決主要效能瓶頸的 VM 機器系列。舉例來說,如果 SQL Server 資料庫的 CPU 使用率持續偏高,請從運算最佳化機器系列中選擇機器類型。如果 SQL Server 資料庫從磁碟讀取資料的速度緩慢,請選擇記憶體最佳化機型。

下表比較 Compute Engine 提供的 VM 機器系列、各機器系列的主要用途,以及對 SQL Server 資料庫的效能影響:

機器家族和系列 主要應用實例 對 SQL Server 效能的影響
一般用途 (N4 機器系列) 兼顧價格和效能 這個機器家族適合做為大多數工作負載的起點。N4 機器系列提供最佳的 CPU 和記憶體平衡,適用於混合用途資料庫、網頁應用程式和開發或測試環境。
運算最佳化 (C3 或 C4 機器系列) 每核心最高效能 這個機器家族適用於 CPU 密集型工作負載。如果資料庫會執行複雜查詢、處理大量資料,或提供大量線上交易處理 (OLTP) 作業,請使用 C3 和 C4 機器系列。這些系列的機型有助於大幅縮短查詢執行時間。
記憶體最佳化 (M3 或 M4 機器系列) 記憶體與 vCPU 比率較高 這個機器家族非常適合需要大量記憶體的應用程式。SQL Server 會將資料和執行計畫快取在記憶體中,因此效能比從磁碟讀取更高。如果資料庫或資料倉儲非常龐大,用於線上分析處理 (OLAP),查詢通常會掃描大型資料表和資料集。在這類情況下,較高的記憶體有助於提升效能。

詳情請參閱機器家族資源與比較指南。

選擇合適的儲存磁碟類型

磁碟效能是資料庫回應能力的重要因素,對應用程式效能至關重要。 Google Cloud提供的磁碟類型,其效能指標如下:

  • IOPS:磁碟每秒可處理的讀取和寫入要求數量。對於涉及許多小型隨機讀寫作業 (例如更新客戶記錄或處理訂單) 的 OLTP 工作負載,IOPS 至關重要。
  • 處理量:每秒可移入或移出磁碟的資料總量。對於涉及掃描大量資料的 OLAP 工作負載 (例如執行報表、資料倉儲或執行備份),總處理量至關重要。

下表比較可供選擇的 Google Cloud 磁碟類型:

磁碟類型 效能特性 工作負載適用性
SSD 永久磁碟 (pd-ssd) 中到高效能,視 VM 機器類型和磁碟大小而定 工作負載的效能須隨著磁碟大小和 VM 的 vCPU 調整。詳情請參閱「Persistent Disk 效能總覽」。
Hyperdisk Balanced 高效能,可設定 IOPS 和處理量 正式環境 SQL Server 資料和記錄檔。 Hyperdisk Balanced 可讓您根據工作負載的需求,獨立設定 IOPS 和處理量,不受磁碟大小影響。
Google Cloud Hyperdisk Extreme 效能極高,可設定 IOPS 需要最高 IOPS 和最低延遲時間的高階重要業務 OLTP 工作負載,例如大型金融或電子商務系統。
本機 SSD IOPS 和處理量高於其他磁碟類型 不需要永久磁碟耐用性的暫存資料。對於 tempdb 系統資料庫和 Windows 分頁檔等資料,本機 SSD 由於實體連接至 VM,因此可提供最低延遲。

根據效能需求選擇基礎架構

請根據工作負載的效能需求,選擇 VM 機器類型和磁碟類型。下表列出不同工作負載情境的建議基礎架構設定:

情境 效能需求 建議的機型和磁碟設定
用於 OLTP 的高交易量電子商務資料庫 高 IOPS,可處理數千個小型並行讀取和寫入作業

VM 機型:選擇運算最佳化機型 (例如 C4 機器系列),有效率地處理交易。

資料和記錄磁碟:使用 Hyperdisk Balanced 磁碟。佈建高 IOPS,滿足交易需求。資料和記錄檔應使用不同的磁碟。

tempdb:使用本機 SSD 磁碟卸載臨時作業,並盡可能提高效能。

公司資料倉儲 (用於 OLAP) 高處理量,可掃描及匯總數 TB 的資料,用於製作報表

VM 機型:選擇記憶體最佳化機型 (例如 M4 機器系列),盡可能快取大型資料集。

資料磁碟:使用 Hyperdisk Balanced 磁碟。佈建高處理量,加快大型資料掃描作業。

開發或測試伺服器 成本效益,而非尖峰效能

VM 機型:從 E2 或 N4 機器系列中,選擇小型的一般用途機型。

磁碟:所有資料庫檔案都使用平衡型永久磁碟 (pd-balanced),以低成本達到可接受的效能。

部署作業

如要部署這項參考架構,請使用下列其中一項資源:

後續步驟

貢獻者

作者:

其他貢獻者:Kumar Dhanagopal | 跨產品解決方案開發人員