雲端HA、BCDR、Backup 分不清?從客戶案例一次搞懂(下)|專家論點【黃婉中】

作者:黃婉中(雲端架構師)

上篇簡介了HA、BCDR、Backup差異,這篇我們繼續談RTO、RPO、儲存備援還有技術選擇。

對架構師來說,BCDR 的設計不是決定用什麼服務,而是根據風險與業務優先級,決定哪些系統值得高可用、哪些系統只需還原能力。(圖/123RF)

重要概念:RTO 跟 RPO 是你選擇技術的依據

當你在規劃架構時,不要先想用什麼服務,先問自己兩件事:

  1. RTO(Recovery Time Objective):災難發生後,你能忍受系統最多中斷多久?
  2. RPO(Recovery Point Objective):你能忍受最多遺失多久前的資料?

支援圖片說明:

What are business continuity, high availability, and disaster recovery?(資料來源/ Microsoft Learn)

 

這兩個數字決定你需要哪種架構:

  • RTO 最多幾秒 → 你需要 HA
  • RPO 可以接受數幾小時 → Backup 就能搞定
  • 兩者都很敏感 → 必須投入完整的 BCDR 策略與預算

每一個選擇背後都是成本

舉例來說:

  • 銀行的交易系統:每一筆資料都關係到金錢,幾乎不能有任何中斷與資料遺失 → 需要 HA + 高頻率同步 + 異地備援 + 快速 Failover。
  • 一個內部庫存查詢系統:查不到資料不是馬上致命,只要隔天恢復就好 → Backup 即可。

正確的策略不是「用最厲害的技術」,而是「用合理的技術解決對你最重要的風險」。

補充重點:LRS、ZRS、GRS、RA-GRS 是什麼?它們和 BCDR 有什麼關係?

當你在設計 BCDR 架構時,不是只有 VM 要設計 HA,儲存的容錯能力也要一併考慮。這時候,就會遇到 Azure 上的儲存備援選項:LRS、ZRS、GRS、RA-GRS。
這些選項決定了你的資料能不能被讀取、能不能從災難中恢復,是構成 BCDR 策略的基礎。

類型 中文說明 資料存放位置 容錯能力 與 BCDR 的關係 建議用途
LRS(Locally Redundant Storage) 本地冗餘儲存 同一個資料中心 防單機損壞,但資料中心掛就沒救 沒有 BCDR 功能,只適合低風險場景 測試環境、不關鍵資料
ZRS(Zone-Redundant Storage) 區域冗餘儲存 同一區域三個 Zone 可承受整個 Zone 停機 用來實現資料層的 HA,對應 Business Continuity 關鍵系統、不中斷服務
GRS(Geo-Redundant Storage) 異地冗餘儲存 異區域冷備份 可承受整個 Region 故障 是 Disaster Recovery 的關鍵機制 異地備援、合規備份
RA-GRS(Read-Access GRS) 可讀取異地備援 GRS 加值版 主區掛掉也能查資料 增加災後可讀性,加速復原效率 災難時查詢備份資料用

(圖表來源/ 中途筆記)

支援圖片說明:

Data redundancy in Azure Files。(資料來源/ Microsoft Learn)

 

換句話說:

  • ZRS 是為了不中斷(BC):讓資料在 Zone 掛掉時仍可即時存取。
  • GRS/RA-GRS 是為了災後復原(DR):讓資料在整個 Region 掛掉時仍能回復。
  • LRS 則無法處理跨資料中心災難,只適合開發測試用途。

如果你正在規劃 BCDR 架構,但儲存還是用 LRS,就像蓋防火屋卻拿紙糊的地基一樣,風險潛藏卻看不見。

技術怎麼選?Azure 上可以這樣做:

需求 Azure 解法
做 Backup 使用 Azure Backup 或 Azure Key Vault
做高可用架構(HA) 使用 VM Scale Set、Availability Set、ZRS 儲存方案
做容錯切換(Failover) 使用 Azure Site Recovery、Front Door、Traffic Manager
做異地備援(BCDR) 使用 GRS、RA-GRS 儲存,搭配 Site Recovery,設定異地架構

(圖表來源/ 中途筆記)

想實現 BCDR,不是一個服務就搞定,而是多項組合、根據你的 RTO/RPO 需求,搭配設計出來的整體架構。

結論:選技術之前,先選擇「你能承受多少損失」

對架構師來說,BCDR 的設計不是決定用什麼服務,而是根據風險與業務優先級,決定哪些系統值得高可用、哪些系統只需還原能力。
在系統設計上,沒有萬能解。
你真正該問的是:

  • 我的服務幾分鐘不能停?(這是 RTO)
  • 我的資料最多能損失多久?(這是 RPO)
  • 這個系統一旦中斷,會不會直接影響業務營收?
  • 我能為這些風險投入多少預算?

這些問題的答案,才是BCDR 策略的起點。

小結

實現 BCDR 架構不是購買某一個 Azure 服務就能完成,而是依據你的業務目標、風險容忍度,去組合一組能支撐「不中斷」與「能復原」的整體策略。

還沒看上篇?先從這裡開始:雲端HA、BCDR、Backup 分不清?從客戶案例一次搞懂(上)

💡延伸閱讀

如果你對今天講的 HA、BCDR、RTO、ZRS 都感到有趣,或開始思考:「我也想變成能設計這種架構的人」,那你可能會對這篇文章有興趣:我如何轉職成為雲端解決方案架構師 Cloud Solution Architect

瀏覽 146 次

覺得不錯的話就分享出去吧!

發佈留言

Back to top button