Cloud de Confiance by S3NS 上的 OpenShift：主動/被動和主動/非作用中設定的災難復原策略

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

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

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

災難復原架構

本節說明主動-被動和主動-非作用中災害復原情境的架構。

使用的產品

主動/被動部署作業

下圖顯示在 Cloud de Confiance上部署 OpenShift 的主動-被動情境。

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

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

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

主動/被動 DR 情境中的元件說明

架構的設定如下：

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

有效/無效的部署作業

主動/非現用災難復原是指維護次要區域做為待機狀態，只有在發生災害時才會啟動。與主動/被動設定不同，這種策略依賴儲存在 Cloud Storage 中的定期備份，並在容錯移轉期間佈建基礎架構和還原資料，而非持續複製資料。您可以使用 Velero 等工具 (與 OpenShift API for Data Protection (OADP) 整合)，定期執行備份。這種做法可將成本降至最低，因此非常適合可容許較長復原時間的應用程式。此外，這項功能也能協助機構配合延長的復原時間目標 (RTO) 和復原點目標 (RPO)。

在主動-非主動災難復原情境中，資料會定期備份至待命區域，但不會主動複製。基礎架構會在容錯移轉程序中佈建，並從最近的備份還原資料。您可以透過以 Velero 開放原始碼專案為基礎的 OpenShift API for Data Protection (OADP)，定期執行備份作業。建議您將這些備份檔儲存在已啟用版本管理的 Cloud Storage 值區中。發生災害時，您可以使用 OADP 還原叢集內容。這種做法可將持續性成本降至最低，但與主動/被動式相比，RTO 可能會較長，RPO 也可能較高。這項設定適用於復原時間目標較長的應用程式。

下圖顯示主動/非主動部署和容錯移轉程序。

容錯移轉程序。

容錯移轉程序如下：

  1. 受監控服務無法使用時，就會觸發 DR 事件。
  2. 管道會自動在 DR 區域佈建基礎架構。
  3. 系統會佈建新的 OpenShift 叢集。
  4. 應用程式資料、密碼和物件會透過 OADP 從最新備份還原。
  5. Cloud DNS 記錄已更新，指向 DR 區域中的區域負載平衡器。

如上圖所示，我們部署了兩個獨立的 OpenShift 區域叢集，分別位於不同的 Cloud de Confiance 區域，例如 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。
  • 調度管理：指令碼或自動化工具會在容錯移轉期間，觸發基礎架構佈建和還原程序。

用途

本節提供主動-被動和主動-非作用中部署作業的不同用途範例。

主動/被動式 DR 應用實例

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

  • 應用程式需要比冷還原更短的復原時間目標 (例如幾分鐘到幾小時)，因為冷還原是從無法立即存取的備份還原資料。
  • 系統可持續複製資料，且必須盡量縮短 RPO (例如幾分鐘到幾秒)。
  • 停機時間限制嚴格的受監管產業，以及停機造成的業務影響足以證明維護暖待命叢集成本合理的關鍵業務應用程式。

主動/非主動 DR 應用實例

建議在下列用途中使用主動-非作用中 DR：

  • 可容許較長 RTO 的應用程式 (例如幾分鐘到幾小時)。
  • 成本最佳化至關重要的環境，以及持續執行待命叢集的費用過高。主要持續性費用是物件儲存空間，而非執行運算執行個體。
  • 開發、測試或重要性較低的正式環境工作負載。
  • 復原時間較不重要的封存或批次處理系統。

設計須知

本節說明設計因素、最佳做法和設計建議，供您參考這些資訊，根據這個參考架構開發拓撲，滿足安全性、可靠性、成本和效能方面的特定需求。

主動/被動設計注意事項

本節說明主動/被動 DR 情境的設計注意事項。

保護應用程式狀態和設定

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 Operator 啟用排程備份功能的設定程式碼片段範例：

        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 角色或驗證方法，可從外部存放區擷取密鑰。

網路和流量管理

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

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

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

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

虛擬私有雲

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

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

子網路和 IP 位址

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

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

透過 Red Hat Service Mesh 進行跨叢集流量傳輸

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

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

有效/無效設計注意事項

本節說明主動/非作用中 DR 解決方案的設計注意事項。

以程式碼形式設定應用程式 (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 說明文件。

後續步驟