區域永久磁碟和 Hyperdisk 平衡高可用性是儲存空間選項，可讓您在 Compute Engine 中實作高可用性 (HA) 服務。地區永久磁碟和 Hyperdisk 平衡高可用性可在同一地區的兩個可用區之間同步複製資料，並確保磁碟資料的 HA 可達到最多一個區域故障。
使用地區磁碟建構高可用性服務
本節說明如何使用地區性永久磁碟或Hyperdisk 平衡高可用性磁碟建構 HA 服務。
設計須知
開始設計高可用性服務之前，請先瞭解應用程式、檔案系統和作業系統的特性。這些特性是設計的基礎，能夠排除許多種方法。比方說，如果應用程式不支援應用程式層級的複製作業，則某些對應的設計選項即不適用。
同樣地，如果應用程式、檔案系統或作業系統不具備容忍當機的能力，則可能無法使用地區性永久磁碟或Hyperdisk 平衡高可用性磁碟，甚至區域磁碟快照。當機容忍度是指突然停止運作而後進行復原的能力，這種復原不會讓當機前提交至磁碟的資料遺失或損壞。
設計高可用性時，請考慮以下事項：
- 使用 Hyperdisk Balanced High Availability、區域性永久磁碟 或其他解決方案對應用程式造成的影響。
- 磁碟寫入效能。
- 服務恢復時間目標：服務必須在多久內從區域服務中斷中恢復，以及服務水準協議的相關規定。
- 建構彈性且可靠的服務架構所需的費用。
- 如要進一步瞭解特定地區的注意事項，請參閱「地理位置與區域」一文。
就費用而言，請使用下列選項進行同步和非同步應用程式複製：
使用資料庫和 VM 的兩個執行個體。在這種情況下，總費用會依下列項目而定：
- VM 執行個體費用
- 永久磁碟或Hyperdisk 費用
- 維護應用程式複製作業的費用
使用單一 VM 搭配同步複製的磁碟。如要透過地區永久磁碟或 Hyperdisk 平衡高可用性磁碟獲得高可用性，請使用與前一個選項相同的 VM 執行個體和磁碟元件，並提供同步複製的磁碟。 地區永久磁碟和 Hyperdisk 平衡高可用性磁碟會在兩個區域中複製，因此每位元組的成本是區域磁碟的兩倍。
不過，使用同步複製的磁碟可能會降低維護成本，因為系統會自動將資料寫入兩個備用資源，因此不需要維護應用程式的複製作業。
除非需要備援，否則請勿啟動次要 VM。如果僅在容錯移轉期間依需求啟動次要 VM，而非將 VM 保持為活動待命 VM，您還可以節省更多主機費用。
比較費用、效能和彈性
下表重點說明不同服務架構在成本、效能和彈性之間的權衡取捨。
| 高可用性服務 架構 |
區域磁碟 快照 |
應用程式層級 同步 |
應用程式層級 非同步 |
區域性磁碟 |
|---|---|---|---|---|
| 防止應用程式、VM、區域故障* | ||||
| 緩解應用程式損壞的風險 (範例：無法容忍應用程式當機) | † | † | ||
| 費用 | $ |
$$
|
$$
|
$1.5x - $$
|
| 應用程式效能 |
|
|
|
|
| 適用於低 RPO 要求的應用程式 (資料遺失容許值極低) |
|
|
|
|
| 儲存空間進行災難復原的時間# |
|
|
|
|
* 使用地區磁碟或快照不足以防範及緩解故障和損毀。您的應用程式、檔案系統和其他可能的軟體元件必須具有當機一致性，或是使用某種暫停動作。
† 某些應用程式的複製功能確實可以緩解部分應用程式損壞的風險。例如，MySQL 主要應用程式毀損並不會導致其備用資源 VM 執行個體也毀損。詳情請參閱應用程式的說明文件。
‡ 資料遺失代表提交至永久儲存空間的資料遺失且無法復原。任何未提交的資料仍會遺失。
# 容錯移轉效能不包括檔案系統檢查和應用程式復原，以及容錯移轉後的載入。
使用區域磁碟建構高可用性資料庫服務
本節將說明使用 Compute Engine 搭配地區永久磁碟和 Hyperdisk 平衡高可用性磁碟，針對有狀態資料庫服務 (MySQL、Postgres 等) 建構高可用性解決方案的整體概念。
如果 Google Cloud發生大規模服務中斷 (例如整個地區都無法使用)，應用程式可能就會無法使用。建議您根據需求考慮使用跨區域複製技術 或非同步複製 來提高可用性。
資料庫高可用性設定通常至少有兩個 VM 執行個體。這些 VM 執行個體最好屬於下列一或多個代管執行個體群組：
- 主要區域中的主要 VM 執行個體
- 次要區域中的待命 VM 執行個體
主要 VM 執行個體至少具有兩個磁碟：開機磁碟和區域磁碟。區域磁碟包含資料庫資料和其他任何可變動資料，應保存至其他區域，以免發生服務中斷的情形。
待命 VM 執行個體需要擁有獨立的開機磁碟，才能從設定相關的服務中斷 (例如作業系統升級) 復原。此外，您無法在容錯移轉期間將開機磁碟強制連接到另一個 VM。
系統會將主要和待命 VM 執行個體設定為使用負載平衡器，並且根據健康狀態檢查訊號將流量導向主要 VM。資料的災難復原案例會說明其他可能更符合您使用情境的容錯移轉設定。
資料庫複製的挑戰
下表列出設定和管理應用程式的同步或半同步複製作業 (例如 MySQL) 的一些常見難題，以及與使用地區永久磁碟和 Hyperdisk 平衡高可用性磁碟進行磁碟同步複製作業的異同之處。
| 挑戰 | 應用程式同步 或半同步複製作業 |
同步磁碟複製 |
|---|---|---|
| 在主要執行個體和容錯移轉備用資源之間維護穩定的複製作業。 | 有許多情況都可能會發生錯誤，並導致 VM 執行個體退出高可用性模式：
|
儲存空間故障是由 地區性永久磁碟和 Hyperdisk Balanced 高可用性磁碟處理。這對應用程式而言清晰可見，但無法察覺磁碟效能可能發生的波動。 系統必須執行使用者定義的健康狀態檢查，才能發現任何應用程式或 VM 問題並觸發容錯移轉。 |
| 端對端容錯移轉的時間比預期的時間長。 | 容錯移轉作業所需的時間沒有上限。等待重新執行所有交易 (上述步驟 2) 的時間無上限，實際情況視資料庫的結構定義和負載而定。 | 區域性永久磁碟和 Hyperdisk 平衡高可用性磁碟可提供同步複製功能，因此容錯移轉時間會受到下列延遲時間總計的限制：
|
| 核心分裂 | 為避免核心分裂，這兩種方式都需要佈建，以確保一次只能有一個主要執行個體。 | |
磁碟讀取和寫入作業的順序
在決定讀取和寫入序列 (也就是資料從磁碟讀取及寫入的順序) 時，VM 中的磁碟驅動程式會執行大部分工作。使用者不必處理複製意義，而且可以照常與檔案系統互動。基礎驅動程式會處理讀取和寫入的序列。
根據預設，搭配Regional Persistent Disk 或Hyperdisk Balanced High Availability 的 Compute Engine VM 會以完整複寫模式運作，也就是說，從磁碟讀取或寫入的請求會傳送至兩個複本。
在完整複製模式下，會發生以下情況：
- 寫入時，寫入要求會嘗試寫入備援資料庫，並在兩次寫入成功時傳送確認訊息。
- 讀取時，VM 會向兩個副本傳送讀取要求，並傳回成功的副本的結果。如果讀取要求逾時，系統會傳送另一個讀取要求。
如果備用資源落後，或無法確認讀取或寫入要求已完成，則會更新備用資源狀態。
健康狀態檢查
負載平衡器使用的健康狀態檢查是由健康狀態檢查代理程式實作。健康狀態檢查代理程式具備兩種用途：
- 健康狀態檢查代理程式會駐留在主要和次要 VM 中，以監控 VM 執行個體並與負載平衡器通訊，以引導流量。搭配執行個體群組設定時，這項功能的效果最佳。
- 健康狀態檢查代理程式會與應用程式專用地區控制層同步，並根據控制層行為做出容錯移轉決策。控制層必須和健康狀態受監控的 VM 執行個體位於不同區域。
健康狀態檢查代理程式本身必須具備容錯性質。舉例來說，請注意下圖的控制層與主要 VM 執行個體各自獨立，主要執行個體位於 us-central1-a 區域，而待命 VM 位於 us-central1-f 區域。
後續步驟
- 瞭解如何建立及管理區域磁碟。
- 瞭解非同步複製。
- 瞭解如何為多寫入端模式下的磁碟設定 SQL Server 容錯移轉叢集執行個體。
- 瞭解如何在 Google Cloud上建構可擴充且有彈性的網路應用程式。
- 請參閱災難復原規劃指南。