本文適用於系統管理員、雲端架構師和應用程式開發人員,他們負責維護部署在 Google CloudRed Hat OpenShift Container Platform 上的應用程式可用性和復原能力。
本文是系列文章之一,著重於應用程式層級的策略,確保工作負載在發生故障時仍維持高可用性,並能快速復原。本文假設您已閱讀災難復原最佳做法。本系列文件包括:
- 災難復原最佳做法
- 高可用性最佳做法
- 主動/被動設定的災難復原策略
- 主動/非使用中設定的災難復原策略 (本頁面)
災難復原架構
主動/非作用中災難復原是指維護次要區域做為待機區域,只有在發生災害時才會啟動。與持續複製資料的主動/被動設定不同,這項策略依賴儲存在 Cloud Storage 中的定期備份,並在容錯移轉期間佈建基礎架構及還原資料。您可以使用 Velero 等工具 (與 OpenShift API for Data Protection (OADP) 整合),定期執行備份。這種做法可將成本降至最低,因此非常適合可容許較長復原時間的應用程式。此外,這項功能也能協助機構配合延長的復原時間目標 (RTO) 和復原點目標 (RPO)。
在主動-非主動災難復原情境中,資料會定期備份至待命區域,但不會主動複製。基礎架構會在容錯移轉程序中佈建,並從最近的備份還原資料。您可以運用以 Velero 開放原始碼專案為基礎的 OpenShift API for Data Protection (OADP),定期執行備份作業。建議您將這些備份檔儲存在已啟用版本管理的 Cloud Storage 值區中。發生災害時,您可以使用 OADP 還原叢集內容。這種做法可盡量減少持續性成本,但與主動-被動式相比,RTO 可能會較長,RPO 也可能較高。這項設定適用於復原時間目標較長的應用程式。
下圖顯示主動/非主動部署作業和容錯移轉程序:
容錯移轉程序如下:
- 受監控的服務無法使用時,就會觸發 DR 事件。
- 管道會自動在 DR 區域佈建基礎架構。
- 系統會佈建新的 OpenShift 叢集。
- 應用程式資料、密碼和物件會透過 OADP 從最新備份還原。
- Cloud DNS 記錄已更新,指向 DR 區域中的區域負載平衡器。
如上圖所示,我們部署了兩個獨立的 OpenShift 區域叢集,每個叢集位於不同的 Google Cloud 區域,例如 us-central1 和 europe-west1。每個叢集都必須在所屬區域內具備高可用性,並使用多個可用區,以確保備援。
在主動/非作用中 DR 情況下,元件的說明
架構的設定如下:
- 主要區域 (區域 A):包含完全運作的 OpenShift 叢集,可處理實際運作流量。
- 次要區域 (區域 B):一開始只包含最少的資源 (虛擬私有雲和子網路)。容錯移轉期間會佈建基礎架構 (Compute Engine 執行個體和 OCP)。
- 備份儲存空間:Google Cloud Storage 值區會儲存定期備份 (應用程式物件的 OADP 或 Velero,以及 PV 和資料庫備份)。建議您為儲存空間啟用版本控管和跨區域複製功能。
- 設定管理:Git 存放區會儲存基礎架構即程式碼 (IaC,例如 Terraform) 和 Kubernetes 或 OpenShift 資訊清單 (適用於 GitOps)。
- 備份工具:在主要叢集中設定 OADP (Velero),以便定期將資料備份到 Cloud Storage。
- 調度管理:指令碼或自動化工具會在容錯移轉期間,觸發基礎架構佈建和還原程序。
使用的產品
- Google Compute Engine
- Google Cloud 全域外部 HTTPS 負載平衡器
- Google Cloud 直通式網路負載平衡器
- Cloud DNS
- 網路端點群組
- Cloud Storage
- Cloud SQL
- Persistent Disk
- Secret Manager
- Cloud Monitoring
- 虛擬私人雲端網路
用途
建議在下列用途中使用主動-非作用中 DR:
- 可容許較長 RTO 的應用程式 (例如幾分鐘到幾小時)。
- 需要進行成本最佳化的環境,以及持續執行待命叢集的費用過高。主要持續性費用是物件儲存空間,而非執行運算執行個體。
- 開發、測試或重要性較低的正式環境工作負載。
- 復原時間較不重要的封存或批次處理系統。
設計須知
本節說明使用這個參考架構開發拓撲時,應考量的設計因素、最佳做法和設計建議,以符合您在安全性、可靠性、成本和效能方面的特定需求。
以程式碼形式設定應用程式 (GitOps)
建議您採用 GitOps 方法,將所有叢集和應用程式設定儲存在 Git 存放區。這個方法可讓您同步處理另一個叢集中已知可穩定執行的狀態,在 DR 情境中快速還原。備份可確保您擁有執行階段狀態的快照,但您也需要可靠的方法,在發生災害後快速重新部署應用程式邏輯、資訊清單和基礎架構定義。
使用 OpenShift GitOps 運算子
OpenShift GitOps 運算子以 Argo CD 為基礎,提供 Red Hat 支援的方法,可直接在 OpenShift 環境中實作 GitOps 模式。這項工具會自動執行程序,持續使用您選擇的設定來協調叢集狀態,並將設定儲存在 Git 存放區中。
OpenShift GitOps 運算子的控制器會持續確保叢集狀態與這個存放區中定義的設定相符。如果資源發生偏移或遺失,系統會自動進行協調。如要瞭解詳情,請參閱「About Red Hat OpenShift GitOps」(關於 Red Hat OpenShift GitOps)。
執行 DR 情境
萬一發生災難,請採取下列做法:
- 在其他區域設定新的 OpenShift 叢集。
- 安裝 OpenShift GitOps 運算子。
- 套用參照 Git 存放區的相同應用程式資訊清單。
運算子會同步處理叢集狀態,以符合存放區,並快速重新部署程式碼中定義的部署項目、服務、路徑、運算子和任何其他資源。
為避免在 DR 期間發生任何問題,建議您採取下列做法:
- 在 Git 存放區中維持嚴格的分支和標記策略,以便找出適合用於 DR 的穩定設定。
- 確認 DR 叢集已連上網路,且具備存取 Git 存放區的適當權限。
- 以程式碼形式納入所有資源類型,避免在容錯移轉期間手動介入 (例如基礎架構元件、應用程式工作負載和設定)。
防火牆規則
定義統一的防火牆政策,並在兩個叢集之間一致套用,控管流量並提升安全性。
遵循最低權限原則,將輸入和輸出流量限制為應用程式功能所需的流量。
部署作業
如要瞭解如何根據這項參考架構部署拓撲,請參閱 Red Hat 說明文件。
後續步驟
- 瞭解如何在主要和次要環境中,實作監控和快訊功能,以掌握叢集健康狀態、複製狀態、備份成功率和應用程式效能。
- 瞭解如何在 Google Cloud上安裝 OpenShift。
- 進一步瞭解 Red Hat 解決方案 Google Cloud。