主動/被動設定的災難復原策略

本文說明如何規劃及實作 OpenShift 部署作業的主動-被動災難復原機制，以在發生災難時， Google Cloud 盡量縮短停機時間並快速復原。這項服務提供備份資料、以程式碼管理設定，以及處理密鑰的最佳做法，有助於確保您能在發生災害時快速復原應用程式。

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

本文是系列文章之一，著重於應用程式層級的策略，確保工作負載在發生故障時仍維持高可用性，並能快速復原。本文假設您已閱讀災難復原最佳做法。本系列文件包括：

災難復原架構

下圖顯示在 Google Cloud上，OpenShift 的主動-被動部署情境架構圖：

主動-被動部署 (詳見下文)。

如上圖所示，在災害復原的主動-被動部署中，主要區域的 OpenShift 叢集會處理所有生產環境流量。如果主要叢集發生故障，系統會準備好不同區域的次要叢集接手處理工作。這項設定可確保次要叢集預先佈建並處於「暖機」狀態，因此停機時間最短。暖機狀態是指叢集已設定必要的基礎架構和應用程式元件，但不會主動處理流量，直到需要時才會處理。應用程式資料會複製到被動叢集，以盡量減少資料遺失，符合 RPO。

其中一個區域叢集會做為主要 (作用中) 網站，處理所有正式流量。位於不同區域的次要叢集是災難復原的備援叢集。次要叢集會保持在暖機狀態，一旦主要叢集發生故障，次要叢集就能立即接管。

主動/被動 DR 情況下的元件說明

這個架構的設定如下：

  • 主要 OpenShift 叢集 (作用中)：位於主要Google Cloud 區域，這個叢集會執行正式版工作負載，並在正常運作情況下，主動處理所有使用者流量。
  • 次要 OpenShift 叢集 (被動)：位於獨立Google Cloud 區域，可隔離故障，這個叢集會做為暖待命叢集。已部分設定並執行，如果主要系統故障，隨時可以接管。這個叢集已部署必要的基礎架構、OpenShift 設定和應用程式元件，但除非觸發容錯移轉事件，否則不會處理實際的正式版流量。
  • Google Cloud 區域：地理位置上互相隔離，可做為災難復原的基礎。使用不同區域可確保影響某個區域的大規模事件不會影響待命叢集。
  • 全域外部 HTTPS 負載平衡器：做為應用程式流量的單一全域進入點。在正常情況下，系統會將所有流量轉送至主要 (作用中) 叢集。健康狀態檢查會監控主要叢集的可用性。
  • 資料複製機制：持續進行的程序或工具，負責將主要叢集的重要應用程式資料複製到次要叢集 (例如資料庫或永久磁碟區狀態)。這種方法可確保資料一致性，並在容錯移轉期間將資料遺失風險降至最低，有助於達成 RPO。
  • 監控和健康狀態檢查：持續評估主要叢集及其應用程式健康狀態和可用性的系統，例如 Cloud Monitoring、負載平衡器健康狀態檢查、內部叢集監控。這些系統對於快速偵測任何故障至關重要。
  • 容錯移轉機制：預先定義的程序 (手動、半自動或全自動)，用於偵測到主要叢集發生無法復原的故障時，將流量從主要叢集重新導向至次要叢集。這個程序通常需要更新全域負載平衡器的後端設定，以將次要叢集設為目標，使其成為新的有效網站。
  • 虛擬私有雲網路：基礎 Google Cloud 網路基礎架構，可在區域之間建立必要的連線，以進行資料複製和管理。

使用的產品

用途

建議在下列用途中使用主動-被動式 DR：

  • 應用程式需要比冷還原更短的 RTO (例如幾分鐘到幾小時)，因為冷還原是從無法立即存取的備份還原資料。
  • 系統可持續複製資料，且必須將 RPO 降到最低 (例如幾分鐘到幾秒)。
  • 受監管產業有嚴格的停機時間限制，且重要業務應用程式的停機時間會對業務造成影響，因此維護暖待命叢集的成本合理。

設計須知

本節說明使用這個參考架構開發拓撲時，應考量的設計因素、最佳做法和設計建議，以符合您在安全性、可靠性、成本和效能方面的特定需求。

保護應用程式狀態和設定

OpenShift Container Platform 提供 OADP，為叢集中執行的應用程式提供全面的災害復原防護。您可以使用這項服務，備份容器化應用程式和虛擬機器使用的 Kubernetes 和 OpenShift 物件 (例如 Deployment、Service、Route、PVC、ConfigMap、Secret 和 CRD)。不過，OADP 不支援完整叢集備份及還原。如要瞭解如何設定及排定備份作業，以及如何還原作業，請參閱 Red Hat 說明文件。

OADP 提供永久磁碟區的備份和還原程序，這些程序依賴應用程式使用的區塊儲存空間和 NFS 儲存空間。您可以使用 Restic 或 Kopia 等工具，透過快照或檔案層級備份執行這些程序。

OADP 可用於備份物件定義、確保設定一致性，以及視需要還原特定應用程式或命名空間，補足資料複製的不足之處。

如要進一步縮短主動/被動設定中的 RPO 和 RTO，建議您在主要和次要區域之間設定資料複製。

資料複製作業非常重要，可確保次要叢集能順利接管。如以下章節所述，從主要叢集到次要叢集的資料複製作業實作方式，取決於應用程式使用的儲存空間類型。

區塊儲存空間 (永久磁碟區)

使用 Google 永久磁碟非同步複製功能，將資料從主要區域複製到次要區域。採用這種做法時，您會在主要區域建立主要磁碟，在次要區域建立次要磁碟，並在這兩個磁碟之間設定複製功能。使用一致性群組可確保兩個磁碟都含有相同時間點的複製資料，然後用於 DR。詳情請參閱「設定永久磁碟非同步複製」。

PersistentVolume 物件

在 OpenShift 中，於兩個叢集建立連結至這些磁碟的 PersistentVolume 物件，並確保應用程式在兩個叢集中使用相同的 PersistentVolumeClaim (PVC)。

應用程式層級複製

部分應用程式 (例如資料庫和訊息佇列) 內建複寫功能，可供您在叢集之間設定。您也可以使用 Pub/Sub 等代管服務，簡化特定類型應用程式資料或事件的複製作業。

資料庫備份

應用程式可依附不同類型的資料庫產品。為協助您規劃資料庫備份的設計考量，本文以 PostgreSQL 做為範例資料庫。

使用叢集內資料庫運算子進行自架備份

資料庫運算子 (例如 CloudNative PostgreSQL 運算子) 可協助 PostgreSQL 叢集進行排程備份和災難復原。CloudNative PostgreSQL Operator 可與 pg_basebackup 等工具原生整合，並支援串流複製備份。您可以將備份檔儲存在 Google Cloud Storage (Cloud Storage) 等雲端儲存空間服務中，確保備份檔的耐久性，並在需要時復原。

您可以在主要和次要區域叢集之間設定串流複製功能，確保即使主要區域發生服務中斷，資料仍可存取。這種串流複製通常在區域內是同步的，跨區域則是異步。如需詳細設定步驟，請參閱 CloudNativePG 說明文件。

發生災害時，您可以將備份還原至新的 PostgreSQL 叢集，確保停機時間和資料遺失量降至最低。以下是使用 CloudNative PostgreSQL 運算子啟用排程備份的設定程式碼片段範例：

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: backup-example
spec:
  schedule: "0 0 0 * * *"
  backupOwnerReference: self
cluster:
  name: pg-backup

代管服務

Cloud SQL 等代管資料庫內建備份和複製功能。建議您從主要資料庫執行個體設定非同步複製，複製到次要區域的副本。詳情請參閱「關於 Cloud SQL 中的複製功能」。在 OpenShift 中，設定密鑰或設定對應，為每個叢集指向正確的資料庫連線字串。

由於非同步複製會導致 RPO 大於零，因此最近寫入的資料可能會遺失。您必須設計應用程式，以防資料遺失。或者，您也可以考慮使用其他複製方法。

此外，我們也建議您啟用 Cloud SQL 自動備份功能。詳情請參閱「建立及管理隨選和自動備份」。

容錯移轉程序

如果主要叢集發生故障，Cloud DNS 會根據健康狀態檢查和容錯移轉政策，自動將流量重新導向次要區域叢集。

次要叢集從唯讀副本升級為主要叢集後，會接管作用中網站並處理正式版流量。您必須完成這項促銷活動，才能接受資料庫寫入作業。

如要為 Cloud SQL 設定災難復原機制，請按照 Google Cloud SQL 災難復原說明文件中的步驟操作。使用非同步資料庫或儲存空間複製功能會導致 RPO 大於零，有助於確保應用程式可容許最近寫入的資料遺失。或者，您也可以考慮使用其他複製方法。

安全管理密鑰

資料庫密碼、API 金鑰和 TLS 憑證等密鑰是 DR 的重要環節。您必須能夠在新叢集中安全且可靠地還原這些密鑰。

常見的密鑰管理方法如下：

  • 使用外部密鑰：使用外部密鑰運算子等工具，從 Google Secret Manager 中提取密鑰。
  • 使用 OADP 運算子備份密鑰：如果您未使用外部商店，請確保備份內容包含密鑰。
  • 定期輪替：定期輪替密鑰，並確保密鑰管理策略能因應災難復原情境。
  • 測試：在暫存環境中測試還原密鑰，確認所有服務都能使用提供的憑證啟動。
  • 驗證：驗證 DR 叢集是否具備必要的 IAM 角色或驗證方法，可從外部存放區擷取密鑰。

網路和流量管理

使用 Google Cloud的全域外部 HTTPS 負載平衡器做為主要進入點，在多個 OpenShift 叢集 (例如主要和次要叢集) 之間分配流量。這項全域服務會根據距離、健康狀態和可用性，將使用者要求導向適當的後端叢集。

如要將全域負載平衡器連線至 OpenShift 叢集，可以使用下列任一方法：

  • 使用區域負載平衡器 (網際網路 NEG)：設定Google Cloud 網際網路網路端點群組 (NEG)，指向公開每個 OpenShift 叢集 Ingress 服務 (OCP 路由器) 的區域負載平衡器外部 IP 位址。接著，全球負載平衡器會將流量轉送至這些區域負載平衡器 IP。這種做法可提供抽象層，但會涉及額外網路的躍點。
  • 直接 Pod 路由 (Compute Engine_VM_IP_PORT NEGs)： 設定 OpenShift Ingress Controller 整合，以使用 Compute Engine_VM_IP_PORT 類型的 Google Cloud 網路端點群組 (NEG)。這種做法可讓全域負載平衡器使用內部 PodIP:TargetPort，直接以 OpenShift Ingress 控制器 (路由器) Pod 為目標。這個方法會略過額外的躍點和節點代理。這通常會降低延遲時間，並讓全域負載平衡器進行更直接的健康狀態檢查。

這兩種設定都能讓全域負載平衡器有效管理不同區域叢集間的流量分配。詳情請參閱「設定具備外部後端的全域外部應用程式負載平衡器」。

VPC

我們建議採用下列 VPC 管理方法：

  • Shared VPC：使用Shared VPC集中管理主要和次要叢集的網路。這種做法可簡化管理作業，並確保各區域的網路政策一致。
  • 全域動態轉送：在虛擬私有雲中啟用全域動態轉送，即可在區域之間自動傳播路徑，確保叢集之間的連線暢通無阻。
  • 自訂模式虛擬私有雲：使用自訂模式虛擬私有雲，並在叢集執行的區域中建立特定子網路。如果方法需要虛擬私有雲原生 Pod 網路，例如 Compute Engine_VM_IP_PORT 路由，通常就必須執行這項操作。
  • VPC 網路對等互連：如果每個區域和叢集都必須使用個別的 VPC 網路，請使用 VPC 網路對等互連來連結區域和叢集。

子網路和 IP 位址

在每個區域中建立區域子網路，以維持網路區隔並避免 IP 位址衝突。

請確保區域之間的 IP 範圍不會重疊，以免發生路由問題。

使用 Red Hat Service Mesh 進行跨叢集流量傳輸

OpenShift 支援服務網格聯盟，可讓部署在多個 OpenShift 叢集中的服務互相通訊。這項函式特別適合用於 DR 情境，因為服務可能需要在容錯移轉或資料複製期間跨叢集通訊。

如要瞭解如何在主要和次要叢集之間設定 Service Mesh 聯盟，請參閱 Red Hat 說明文件。

部署作業

如要瞭解如何根據這項參考架構部署拓撲，請參閱 Red Hat 說明文件。

後續步驟