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

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

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

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

設計須知

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

同樣地，如果應用程式、檔案系統或作業系統不具備容錯能力，則可能無法使用區域性永久磁碟或Hyperdisk Balanced High Availability 磁碟，甚至是可用區磁碟快照。「容錯能力」是指從突然終止中復原的能力，且不會遺失或損毀在當機前已提交至磁碟的資料。

設計高可用性架構時，請考量下列事項：

  • 使用 Hyperdisk Balanced High Availability、區域性永久磁碟 或其他解決方案，對應用程式造成的影響。
  • 磁碟寫入效能。
  • 服務復原時間目標：服務必須在多久時間內從可用區中斷情形中復原，以及服務水準協議 (SLA) 規定。
  • 建構具備韌性且可靠的服務架構，所需成本。
  • 如要進一步瞭解特定區域的注意事項，請參閱「地理位置與區域」一文。

在成本方面，請使用下列選項進行同步和非同步應用程式複製：

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

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

  • 使用單一 VM，並同步複製磁碟。如要透過區域性永久磁碟或 Hyperdisk Balanced High Availability 磁碟實現高可用性，請使用與前一個選項相同的 VM 執行個體和磁碟元件，但也要加入同步複製的磁碟。 區域性永久磁碟和 Hyperdisk Balanced High Availability 磁碟會複製到兩個可用區，因此每位元組的費用是可用區磁碟的兩倍。

    不過，使用同步複製的磁碟可能會降低維護成本，因為資料會自動寫入兩個副本，不需要維護應用程式複製。

  • 在需要容錯移轉之前，請勿啟動次要 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 High Availability 磁碟，為有狀態資料庫服務 (MySQL、Postgres 等) 建構高可用性解決方案的高階概念。

如果 Google Cloud發生大範圍服務中斷，例如整個區域無法使用，應用程式可能會無法使用。視需求而定，您也可以考慮採用跨區域複製技術或非同步複製 ，進一步提高可用性。

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

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

主要 VM 執行個體至少有兩個磁碟：開機磁碟和區域磁碟。區域磁碟包含資料庫資料和任何其他可變動資料，應在發生中斷時保留至其他可用區。

待命 VM 執行個體需要獨立的開機磁碟，才能從設定相關中斷 (例如作業系統升級) 復原。

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

資料庫複製的挑戰

下表列出設定及管理應用程式同步或半同步複製 (例如 MySQL) 時，可能遇到的一些常見問題，並比較這些問題與使用區域性永久磁碟和 Hyperdisk Balanced High Availability 磁碟進行同步磁碟複製時的情況。

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

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

必須有使用者定義的健康狀態檢查，才能找出任何應用程式或 VM 問題，並觸發容錯移轉。
端對端容錯移轉時間比預期長。 容錯移轉作業所需時間沒有上限。 等待所有交易重播 (上述步驟 2) 可能需要任意時間，具體取決於結構定義和資料庫的負載。

區域性永久磁碟和 Hyperdisk Balanced High Availability 磁碟提供同步複製功能，因此容錯移轉時間受限於下列延遲時間的總和：

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

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

在決定讀取和寫入序列 (即資料從磁碟讀取和寫入磁碟的順序) 時，大部分的工作都是由 VM 中的磁碟驅動程式完成。使用者不必處理複製語意，可以照常與檔案系統互動。基礎驅動程式會處理讀取和寫入的序列。

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

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

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

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

健康狀態檢查

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

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

健康狀態檢查代理程式本身必須具備容錯能力。舉例來說，請注意，在下圖中，控制層與主要 VM 執行個體 (位於可用區 us-central1-a) 分開，而待命 VM 位於可用區 us-central1-f。

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

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

後續步驟