使用同步複製的磁碟建構高可用性服務

地區永久磁碟和 Hyperdisk Balanced High Availability 是儲存空間選項，可讓您在 Compute Engine 中實作高可用性 (HA) 服務。區域永久磁碟和 Hyperdisk 平衡高可用性磁碟會在同一區域的兩個可用區之間同步複製資料，並確保磁碟資料的高可用性，最多可容許一個可用區發生故障。

使用區域磁碟建構高可用性服務

本節說明如何使用地區永久磁碟或Hyperdisk Balanced 高可用性磁碟建構高可用性服務。

設計須知

開始設計高可用性服務之前，請先瞭解應用程式、檔案系統和作業系統的特性。這些特性是設計的基礎，能夠排除許多種方法。比方說，如果應用程式不支援應用程式層級的複製作業，則某些對應的設計選項即不適用。

同樣地，如果應用程式、檔案系統或作業系統不具備容忍當機的能力，則可能無法使用地區永久磁碟或Hyperdisk Balanced 高可用性磁碟，甚至區域磁碟快照。當機容錯能力是指從突然終止的狀態復原的能力，這種復原不會讓當機前提交至磁碟的資料遺失或損壞。

設計高可用性系統時，請考慮下列事項：

  • 使用 Hyperdisk Balanced High Availability、地區永久磁碟 或其他解決方案對應用程式的影響。
  • 磁碟寫入效能。
  • 服務復原時間目標：服務必須以多快的速度從區域服務中斷狀態復原，以及服務水準協議的相關規定。
  • 建立彈性且可靠的服務架構所需的費用。
  • 如要進一步瞭解特定地區的注意事項，請參閱「地理位置與區域」一文。

就費用而言，同步和非同步應用程式複製作業有下列選項：

  • 使用資料庫和 VM 的兩個執行個體。在這種情況下，總費用會依下列項目而定：

    • VM 執行個體費用
    • 永久磁碟或 Hyperdisk 費用
    • 維護應用程式複製作業的費用

  • 使用單一 VM，搭配同步複製的磁碟。如要透過地區永久磁碟或 Hyperdisk Balanced 高可用性磁碟獲得高可用性，請使用與上一個選項相同的 VM 執行個體和磁碟元件，並提供同步複製的磁碟。 地區永久磁碟和 Hyperdisk 平衡高可用性磁碟會在兩個區域中複製，因此每位元組的成本是區域磁碟的兩倍。

    不過，使用同步複製磁碟可能會降低您的維護成本，原因是系統會自動將資料寫入兩個備用資源，因此不需要維護應用程式的複製作業。

  • 在需要容錯移轉前，請勿啟動次要 VM。如果僅在容錯移轉期間依需求啟動次要 VM，而非將 VM 保持為作用中待命 VM，您還可以節省更多主機費用。

比較費用、效能和彈性

下表重點說明不同服務架構在成本、效能和彈性之間的權衡取捨。

高可用性服務
架構		 區域磁碟
快照		 應用程式層級
同步
 應用程式層級
非同步		 區域性磁碟
防止應用程式、VM、區域故障*
緩解應用程式損壞的風險 (範例：無法容忍應用程式當機) † †
費用 $ $$

  • Two instances of the database or VM running, application replication setup and maintenance, cross zone networking.
 $$

  • 執行資料庫或 VM 的兩個執行個體、應用程式複製設定和維護作業，以及跨區域網路。
 $1.5x - $$

  • 如果您使用作用中待命 VM，則費用與應用程式複製作業相同。如要降低成本，您可以在容錯移轉期間依需求啟動備用 VM。磁碟副本之間的跨區域網路不會產生任何費用。
應用程式效能

  • 無影響

  • 具備同步複製功能但犧牲應用程式效能

  • 無影響

  • 對大多數應用程式沒有影響
適用於低 RPO 要求的應用程式 (極不容許遺失資料)

  • 資料是否遺失取決於拍攝快照的時間

  • 不會導致資料遺失‡

  • 非同步複製作業導致資料遺失

  • 不會導致資料遺失
儲存空間進行災難復原的時間#
  • O (分鐘)
  • O (秒)
  • O (秒)
  • O(秒) - 將磁碟強制連接到待命 VM 執行個體

* 使用區域磁碟或快照不足以防範及緩解故障和損毀。您的應用程式、檔案系統和其他可能的軟體元件必須具有當機一致性，或是使用某種暫停動作。

† 某些應用程式的複製功能確實可以緩解部分應用程式損壞的風險。舉例來說，MySQL 主要應用程式毀損並不會導致其副本 VM 執行個體也毀損。詳情請參閱應用程式的說明文件。

‡ 資料遺失代表提交至永久儲存空間的資料遺失且無法復原。任何未提交的資料仍會遺失。

# 容錯移轉效能不包括檔案系統檢查和應用程式復原，以及容錯移轉後的載入。

使用區域磁碟建構高可用性資料庫服務

本節將說明使用 Compute Engine 搭配地區永久磁碟和 Hyperdisk Balanced 高可用性磁碟，針對有狀態資料庫服務 (MySQL、Postgres 等) 建構高可用性解決方案的整體概念。

如果 Google Cloud發生大規模服務中斷 (例如整個地區都無法使用)，應用程式可能無法使用。建議您根據需求考慮使用跨地區複製技術 或非同步複製 來提高可用性。

資料庫高可用性設定通常至少有兩個 VM 執行個體。這些 VM 執行個體最好屬於下列一或多個代管執行個體群組：

  • 主要區域中的主要 VM 執行個體
  • 次要區域中的待命 VM 執行個體

主要 VM 執行個體至少具有兩個磁碟：開機磁碟和地區磁碟。區域磁碟包含應保存至其他可用區的資料庫資料以及其他任何可變動資料，以免發生服務中斷的情形。

待命 VM 執行個體需要擁有獨立的開機磁碟，才能從設定相關的服務中斷 (例如作業系統升級) 復原。此外，您無法在容錯移轉期間將開機磁碟強制連接到另一個 VM。

系統會將主要和待命 VM 執行個體設定為使用負載平衡器，並且根據健康狀態檢查訊號將流量導向主要 VM。資料的災難復原案例會說明其他可能更符合您使用情境的容錯移轉設定。

資料庫複製的挑戰

下表列出設定和管理應用程式的同步或半同步複製作業 (例如 MySQL) 的一些常見難題，以及與使用地區永久磁碟 和 Hyperdisk Balanced 高可用性磁碟進行同步磁碟複製的異同之處。

挑戰 應用程式同步
或半同步複製作業		 同步磁碟複製
在主要執行個體和容錯移轉備用資源之間維護穩定的複製作業。 有許多情況都可能會發生錯誤，並導致 VM 執行個體退出高可用性模式：
  1. 複製參數設定錯誤 (例如 SSL 憑證不符)，或主要執行個體缺少 ACL。
  2. 主要 VM 執行個體的工作負載過高，導致容錯移轉備用資源無法跟上。
  3. 導致複製問題的錯誤，例如應用程式問題、作業系統設定錯誤或 Docker 故障。
  4. 基礎架構故障，例如 CPU 爭用，VM 凍結或中間網路中斷。

儲存空間故障是由 區域性永久磁碟 和 Hyperdisk Balanced 高可用性磁碟處理。這對應用程式而言清晰可見，但無法察覺磁碟效能可能發生的波動。

系統必須執行使用者定義的健康狀態檢查，才能發現任何應用程式或 VM 問題並觸發容錯移轉。
端對端容錯移轉的時間比預期的時間長。 容錯移轉作業所需的時間沒有上限。 等待重新進行所有交易 (上述步驟 2) 的時間無上限，實際情況視資料庫的結構定義和負載而定。

區域永久磁碟和 Hyperdisk Balanced 高可用性磁碟提供同步複製功能，因此容錯移轉時間會受到下列延遲時間總計的限制：

  1. 建立次要 VM (除非已有可用的待命 VM 執行個體)。
  2. 強制連接區域性磁碟。
  3. 進行應用程式初始化。
核心分裂 為避免核心分裂，這兩種方式都需要佈建，以確保一次只能有一個主要執行個體。

磁碟讀取和寫入作業的順序

在判斷讀取和寫入序列，或從磁碟讀取資料及將資料寫入磁碟的順序時，大部分的工作是由 VM 中的磁碟驅動程式完成。使用者不必處理複製語意，可以照常與檔案系統互動。底層驅動程式會處理讀取和寫入的序列。

根據預設，具有區域永久磁碟或 Hyperdisk Balanced High Availability 的 Compute Engine VM 會以完整複製模式運作，從磁碟讀取或寫入的請求會傳送至兩個副本。

在完整複製模式下，會發生下列情況：

  • 寫入時，寫入要求會嘗試寫入兩個副本，並在兩次寫入都成功時確認。
  • 讀取時，VM 會將讀取要求傳送至兩個副本，並傳回成功副本的結果。如果讀取要求逾時，系統會傳送另一個讀取要求。

如果備用資源落後或無法確認讀取或寫入要求已完成，系統就會更新備用資源狀態。

健康狀態檢查

負載平衡器使用的健康狀態檢查是由健康狀態檢查代理程式實作。健康狀態檢查代理程式有兩種用途：

  1. 健康狀態檢查代理程式會駐留在主要和次要 VM 中，以監控 VM 執行個體並與負載平衡器通訊以引導流量。搭配執行個體群組設定時，這項功能最能發揮效用。
  2. 健康狀態檢查代理程式會與應用程式專用地區控制層同步，並根據控制層行為做出容錯移轉決策。控制層必須和健康狀態受監控的 VM 執行個體位於不同區域。

健康狀態檢查代理程式本身必須具備容錯性質。舉例來說，請注意下圖的控制層與主要 VM 執行個體各自獨立，主要 VM 執行個體位於 us-central1-a 區域，而待命 VM 位於 us-central1-f 區域。

VM 中的健康狀態檢查代理程式角色。

主要和待命 VM 執行個體中的健康狀態檢查代理程式角色。

後續步驟