高可用性 (HA) 與災難復原 (DR) 設計

彈性的基礎：高可用性 (HA) vs. 災難復原 (DR)

在雲端架構的世界中，高可用性 (High Availability, HA) 與 災難復原 (Disaster Recovery, DR) 是同一枚硬幣的兩面，但它們的目的不同。

• 高可用性 (HA)： 關注的是在「正常」局部故障（例如單個 VM 當機或單個區域電力問題）期間保持系統運行。HA 通常以 正常運行時間百分比（如 99.99%）來衡量。
• 災難復原 (DR)： 關注的是在災難性事件（例如整個區域因自然災害而離線）後恢復系統。DR 以 RTO 和 RPO 來衡量。

對於 GCP PCA 考試，您必須能夠設計滿足特定 RTO 和 RPO 目標且不超出預算的架構。「最優」解決方案通常涉及成本與恢復速度之間的權衡。

白話文解釋 HA 與 DR 設計

為彈性而設計就像是為城市準備不同等級的應急預案。

類比 1 — 醫院的備用電源系統 (HA)

將 HA 想像成醫院內部的備用電源系統。如果手術室的保險絲燒斷了（局部故障），醫院有即時的備援（冗餘）來保持燈光亮著，醫生甚至不會察覺。HA 處理的是那些不應中止任務的小型、預期內的故障。

類比 2 — 應急遷移計劃 (DR)

將 DR 想像成城市在發生大規模洪水時將整個運作遷移到另一個城市的計劃。這是一個罕見的災難性事件。您無法阻止洪水，但您有一個計劃：「如果 A 城被淹，我們就在 B 城開設備用辦公室。」在搬遷過程中，您可能會損失幾個小時的工作時間 (RTO) 和一些最近的文件 (RPO)，但城市仍能繼續運作。

類比 3 — 特技演員的安全繩與安全網

HA 就像特技演員穿的安全連身繩——它一開始就防止他們墜落。DR 則是底部的安全網——它不能阻止墜落，但能防止墜落致命。一位專業的架構師兩者都會使用：為每個動作準備一條繩子 (HA)，並準備一個大網以防繩子斷裂 (DR)。

定義 DR 模式：冷、溫、熱

隨著 RTO/RPO 要求變得更加嚴格，DR 解決方案的成本和複雜性也會增加。

冷備援 (Cold Standby / Backup and Restore)

• 機制： 定期將數據備份到 Cloud Storage。災難發生時，配置新的基礎設施並恢復數據。
• RTO： 數小時或數天。
• RPO： 數小時（取決於備份頻率）。
• 成本： 最低。
• 使用案例： 非關鍵的內部應用程式。

溫備援 (Warm Standby)

• 機制： 應用程式的縮減版本始終在次要區域運行。數據持續複製（例如 Cloud SQL 跨區域副本）。
• RTO： 分鐘級。
• RPO： 分鐘或秒級。
• 成本： 中等。
• 使用案例： 可以承受短暫停機的核心業務應用程式。

熱站點 (Hot Site / Active-Active)

• 機制： 全規模的基礎設施同時在兩個或多個區域運行。流量使用全域負載平衡進行分配。
• RTO： 趨近於零。
• RPO： 趨近於零（使用 Spanner 等全球一致性數據庫）。
• 成本： 最高。
• 使用案例： 關鍵的面向消費者的平台（如電商結帳、銀行系統）。

GCP 上的技術實施

多區域 vs. 多分區設計 (Multi-Regional vs. Multi-Zonal)

• 多分區 (Multi-Zonal)： 防範單個數據中心故障。使用具備「跨分區」分佈政策的代管執行個體群組 (MIGs)。
• 多區域 (Multi-Regional)： 防範整個區域故障。這是實現真正 DR 的要求。

全域負載平衡 (Global Load Balancing)

全域外部應用程式負載平衡器是關鍵的 DR 工具。它使用單一的 Anycast IP。如果某個區域發生故障，負載平衡器會自動停止將流量發送到該區域的後端，並將其重新路由到下一個健康的區域。這發生在邊緣，為用戶提供近乎瞬時的故障轉移。

數據複製與同步

• Cloud Spanner： 全域 HA 的「最優」選擇。它提供 99.999% 的可用性和跨區域的強一致性。
• Cloud SQL： 使用跨區域副本。請注意，切換到副本通常是手動或腳本化的過程，而非自動。
• Cloud Storage： 使用多區域 (Multi-regional) Bucket 以實現自動的地理冗餘。

RTO/RPO 層級對應 GCP 服務

將業務定義的復原目標轉譯成具體的 GCP 服務選擇，是 PCA 情境題中最常見的考點。請用這套層級模型作為決策框架。

第 1 級 — 熱備援 (RTO 秒級、RPO ≈ 0)

保留給 tier-0 系統：支付處理、身分驗證、即時庫存。

• 運算： 兩個（或更多）區域中的 regional MIGs，前端搭配全域外部應用程式負載平衡器 (Global External Application Load Balancer)，兩個區域同時對外服務。
• 資料庫： Cloud Spanner 多區域執行個體（例如 nam-eur-asia1 或 nam3）— 跨區域同步 Paxos quorum，已提交寫入的 RPO 為零。
• 儲存： 多區域 GCS bucket，啟用 turbo replication 以達成跨地理位置 15 分鐘內的 RPO。
• 快取： Memorystore for Redis Standard Tier，並在次要區域設定 read replica。

第 2 級 — 溫備援 (RTO 5-30 分鐘、RPO 1-15 分鐘)

適用於可承受短暫降級的核心業務應用程式。

• 運算： 區域 A 為正式 MIG；區域 B 為縮減版 MIG（1-2 個執行個體），故障轉移時自動擴容。
• 資料庫： Cloud SQL 跨區域 read replicas。提升為 primary 需手動操作，但可在數分鐘內完成。
• 儲存： 標準多區域 bucket（不啟用 turbo），RPO 約 12 小時且為最終一致性。

第 3 級 — 冷備援 (RTO 數小時、RPO 1-24 小時)

適用於內部工具、批次作業、報表類工作負載。

• 運算： 將 Terraform/Deployment Manager 範本儲存在 Cloud Source Repositories。DR 區域不執行任何基礎設施。
• 資料庫： Backup and DR Service 排程匯出到不同區域，依需求復原。
• 儲存： Nearline 或 Coldline bucket，僅對關鍵物件設定跨區域複製。

Cloud SQL 跨區域副本故障轉移機制

Cloud SQL 跨區域 read replica 是 MySQL、PostgreSQL、SQL Server 工作負載的溫備援主力。理解其機制是 PCA 情境題的必修內容。

複製拓撲

• Primary 執行個體位於區域 A 並啟用 HA（同步複製到區域 A 內另一個 zone 的 standby — 對 zonal 故障 RPO 0）。
• 一個或多個跨區域 read replicas 位於區域 B，透過 binary log（MySQL/SQL Server）或 WAL streaming（PostgreSQL）非同步複製。
• 複製延遲通常為 1-5 秒，但在大量寫入下可能增加。請務必在 Cloud Monitoring 監控 replica_lag。

提升流程

當區域 A 故障時，必須手動提升跨區域副本：

gcloud sql instances promote-replica my-replica-region-b

提升後：

1. Replica 變成獨立的 primary — 與舊 primary 的複製關係中斷且無法重新建立。
2. 應用程式連線字串必須改指向新 primary（使用 Cloud SQL Auth Proxy，或在 Secret Manager 更新 connection name）。
3. 從提升後的執行個體重新設定新的 HA standby 與新的跨區域 replica — 在完成前 DR 防護等級會下降。

注意事項

• 提升是不可逆的。即使區域 A 復原，也無法將新 primary「降級」回去。
• Replica 不會繼承使用者定義的備份；提升後請立刻設定備份排程。
• 若需要兩個區域都能進行讀寫流量，Cloud SQL 不適用 — 請改用 Spanner。

DNS、負載平衡器與 MIG 層級的故障轉移

故障轉移是分層議題。不同的 GCP 元件處理不同的影響範圍 — 知道哪個元件用於哪一層是 PCA 核心內容。

Cloud DNS Failover Routing Policy

Cloud DNS 支援 failover policy：當主 IP 的健康檢查通過時回傳主 IP，否則切換至備用 IP。設定方式：

gcloud dns record-sets create api.example.com. \
  --type=A --ttl=60 \
  --routing-policy-type=FAILOVER \
  --routing-policy-primary-data=34.120.0.10 \
  --routing-policy-backup-data-policy-type=GEO \
  --enable-health-checking

當您每個區域有不同 IP（例如 regional TCP proxy LB），或混合雲架構橋接地端與 GCP 時使用。注意： 以 DNS 為基礎的故障轉移受 TTL 加上 resolver 快取限制 — 60 秒的 TTL 在用戶端實際換算下來會是 2-5 分鐘的故障轉移時間。

全域應用程式負載平衡器的跨區域後端

全域外部應用程式負載平衡器將多個 regional backend services 掛在單一 Anycast frontend IP 之下。在邊緣執行的健康檢查會自動把流量從故障區域 drain 掉，完全不需要變更 DNS — 通常 30 秒內完成。對 HTTP(S) 工作負載要求次分鐘 RTO 時，這是首選機制。

Regional MIG 搭配自我修復

Regional Managed Instance Group 預設會將執行個體散佈於區域內三個 zone。Auto-healing 透過 health check 重建不健康的 VM：

• 自我修復處理單一區域內的 VM 層級與 zone 層級故障。
• 它無法防範整個區域層級的中斷 — 那需要在不同區域部署多個 MIG，再用全域 LB 串接。

Backup and DR Service 的多區域復原

Google Cloud Backup and DR Service（原 Actifio GO）是 Compute Engine VM、VMware Engine 工作負載、資料庫（Cloud SQL、SAP HANA、Oracle）與檔案系統的代管備份平面。

多區域備份保管庫

• 備份資料儲存於備份/復原 appliance 加上位於 Cloud Storage 的備份保管庫 (backup vault)。
• 保管庫的區域可與來源工作負載的區域獨立設定。跨區域 vault 對於防護區域性中斷至為關鍵 — 若來源與備份都位於 us-central1，區域性災難會同時毀掉兩者。
• 不可變備份保管庫搭配強制最短保留期，可防護擁有刪除權限的勒索軟體。

復原模式

• 掛載式復原 (Mount-based recovery)： 將備份映像直接掛載為新 VM 的磁碟 — 適用於鑑識調查或部分復原（RTO 分鐘級，不需完整還原）。
• 跨區域完整還原： 從備份保管庫在 DR 區域重建 VM 或資料庫，這是冷備援的標準模式。
• 應用程式一致性備份： Pre/post script 在 snapshot 前讓資料庫靜止 (quiesce) — 是交易完整性的必要步驟。

多區域 bucket 的最終一致性陷阱

標準多區域 GCS bucket 物件以非同步方式跨區域複製。兩項後果：

• 在一個區域寫入的物件，可能要等好幾分鐘才能從另一個區域看到 — 從故障轉移區域讀取「最新」物件的應用程式會看到舊資料。
• Turbo replication（在 dual-region bucket 上可用，例如 nam4、eur5、asia1）以 SLA 保證 15 分鐘 RPO，多數寫入在數秒內複製完成。
• 即便啟用 turbo，列表操作 (gs://bucket?prefix=) 仍可能呈現最終一致的排序 — 千萬不要把列表的新鮮度當成同步機制使用。

如果 DR 計畫仰賴復原區域能立即讀取備份物件，請使用啟用 turbo replication 的 dual-region bucket，或在備份管線中明確執行 gsutil rsync 將資料同步到區域專屬 bucket。

混沌工程與彈性測試

如果不進行測試，設計 DR 就毫無意義。

• 演練日 (Game Days)： 團隊模擬災難（例如在預發布環境中「刪除生產數據庫」）以測試恢復手冊的預定事件。
• 故障注入 (Fault Injection)： 故意注入故障（如關閉隨機分區）以觀察系統反應。
• 驗證： 始終驗證恢復的數據是否準確，以及應用程式在故障轉移後是否功能完備。

HA/DR 最優解 (Optimal) vs. 可行解 (Viable) 決策摘要

FAQ — 高可用性與災難復原

Q1. 我可以實現 100% 的正常運行時間嗎？

不行。在雲端中，99.999% (五個九) 被視為行業極限。總會存在統計學上的故障概率。

Q2. 多區域 DR 中最大的挑戰是什麼？

數據一致性。跨越數千英里的數據同步受限於光速。這就是為什麼 Cloud Spanner 如此具有革命性——它使用原子鐘在全球範圍內管理這種同步。

Q3. HA VPN 是連線的「高可用性」嗎？

是的。GCP 中的 HA VPN 設置由兩個位於兩個獨立介面上的隧道組成，確保混合連線具備 99.99% 的 SLA。

Q4. Serverless (Cloud Run) 是否內建 DR？

Cloud Run 是區域性的。要實現 Cloud Run 的多區域 DR，您必須將服務部署到多個區域，並在它們前面放置全域負載平衡器。

Q5. 什麼是「自我修復 (Self-healing)」？

自我修復是 MIGs 的一項功能，如果 VM 執行個體未能通過健康檢查，基礎設施會自動重新建立該執行個體，無需任何人工干預。

最終架構師提示

在 PCA 考試中，當您看到 「業務連續性」 或 「零停機時間」 的要求時，您的腦海應立即想到 多區域 Active-Active 和 全域負載平衡。始終先評估 RTO/RPO 目標——它們會告訴您哪種 DR 模式是「最優」選擇。