災難復原最佳做法

在Google Cloud的 OpenShift Container Platform 上部署應用程式時，災難復原 (DR) 是維持應用程式持續運作的必要措施。本文將概略說明 OpenShift on Google Cloud的 DR 架構選項，協助貴機構在發生災難時，盡量縮短停機時間並快速復原。

本文件適用於系統管理員、雲端架構師和應用程式開發人員，他們負責維護在Google Cloud上部署的 OpenShift Container Platform 應用程式可用性和復原能力。

本文是系列文章之一，著重於應用程式層級的策略，確保工作負載在發生故障時仍維持高可用性，並能快速復原。本系列文件如下：

災難復原規劃

規劃災難復原是雲端執行正式環境工作負載的重要環節。雖然 OpenShift 和 Google Cloud 提供強大的基礎架構層級備援功能，但您也必須設計及設定應用程式，以便從災難性故障中快速復原。

有效的 DR 規劃需要採取分層做法。首先，請為應用程式和系統定義明確的復原時間目標 (RTO) 和復原點目標 (RPO)，以便快速重新部署。

密鑰和憑證也必須可供復原，並受到安全管理。 考量所有這些因素後，您就能達到 DR 資安態勢，在不同區域快速建立新的 OpenShift 叢集，或容錯移轉至非作用中的次要叢集。次要叢集會保持離線狀態，直到發生故障為止。屆時，系統會啟動次要叢集並連上網路，接管作業，盡量減少停機時間。

災難復原架構

您可以使用不同的部署架構選項，在 Google Cloud上透過 OpenShift 進行 DR。這些選項在成本、複雜度和可用性方面各有不同。下表概略說明這些架構：

架構 說明 用途 優點 缺點
主動/被動 一個叢集處於啟用狀態，負責處理所有流量，另一個叢集則處於被動狀態，隨時準備接管。資料會複製到被動叢集。 適用於 RTO 和 RPO 需求適中的應用程式。 實作較簡單，備用叢集的費用較低。 由於容錯移轉時間和潛在的資料同步延遲，RTO 較高。
有效-無效 與主動連被動類似，但非作用中叢集不會使用，直到發生 DR 事件為止。系統會定期備份資料。 適合成本敏感型環境，允許較高的 RTO 和 RPO。 閒置時營運成本較低，適合用於災難復原，因為次要系統不會主動執行 (冷災難復原)。 由於啟動和同步時間較長，RTO 較高，但資料可能過時。
Active-active 兩個叢集都會處於啟用狀態，透過負載平衡處理流量，並在區域之間複製資料。 需要最短停機時間和高可用性的重要應用程式。 最低 RTO 和 RPO，持續可用。 複雜度和成本最高，需要穩固的網路和資料同步。

後續步驟