EnglishFrançaisDeutschEspañolItaliano日本語한국어NederlandsPortuguês (Brasil)中文 (简体)中文 (繁體, 台灣)
Skip to main content

2026 年 8 月 18 日

設定 Omnissa Access 的災難復原

Omnissa Access 支援使用共用 NFS 掛接點的備份與還原模型進行災難復原。在此模型中，次要叢集可以存取主要叢集產生的備份資料。宣告災難復原 (DR) 事件後，系統會手動將次要叢集提升為主要叢集，由其處理讀取和寫入流量。容錯回復至原始站台是一項計劃性的手動作業，不會自動執行。原始主要叢集恢復可用後，仍會維持次要叢集角色，直到執行計劃性的容錯回復作業為止。

本主題說明如何設定 NFS 備份儲存區、管理備份排程、備份所需的啟動程序節點資料，以及在容錯移轉期間從備份還原 Omnissa Access。

先決條件

設定災難復原前，請確保符合下列條件：

  • 已設定複寫的 NFS 共用，且主要叢集節點和次要叢集節點皆可透過網路存取。
  • 次要叢集將使用與來源叢集相同版本的資產服務包進行部署。
  • 您具有主要叢集啟動程序節點的管理存取權，可備份密碼和組態檔。

在 NFS 伺服器上設定 NFS 匯出

由於備份服務以 root 使用者身分執行，因此 NFS 匯出必須包含 no_root_squash 選項。在 NFS 伺服器上，確認 /etc/exports 中的匯出組態：

cat /etc/exports

輸出中應包含以下格式的項目：

<NFS-MOUNT-POINT> <NFS-CLIENT-IP>(rw,sync,no_subtree_check,no_root_squash)

<NFS-CLIENT-IP> 是涵蓋所有允許存取該掛接點之叢集節點的 IP 範圍或 IP 位址集合。例如，如果來源叢集節點使用 10.48.34.100–10.48.34.105 範圍內的位址，請將 <NFS-CLIENT-IP> 設為 10.48.34.0/24，以涵蓋整個子網路。當次要叢集在容錯移轉期間提升為主要叢集時，其節點位址也必須位於允許的 IP 範圍內。

設定用於 NFS 備份的 profile.yml

部署服務前，必須將來源叢集設定為將備份寫入共用 NFS 掛接點。這些備份用於在容錯移轉期間還原次要叢集。

  1. 在來源叢集的啟動程序節點上，開啟 /root/<cluster_name>/profile.yml。

  2. 找到下列各行，填入 NFS 伺服器詳細資料，並取消註解：

    nfs_host: <NFS-HOST-IP>
nfs_path: <NFS-MOUNT-POINT>
nfs_version: 4

  3. 儲存檔案，然後依照本指南第 4 階段和第 5 階段的說明繼續部署服務。

    **附註：**如果初始部署服務前未在 profile.yml 中加入 NFS 詳細資料，請於之後新增這些資料，並重新部署依賴備份的服務：

      > ```bash
  > wso services deploy -s postgres
  > wso services deploy -s control-plane-backup
  > wso services deploy -s opensearch
  > ```

  4. 若要確認可從次要叢集中的其他機器存取 NFS 掛接點，請在另一部虛擬機器上執行下列命令：

    # Mount the NFS share manually to test connectivity
mount -t nfs <NFS-IP>:<NFS-MOUNT-POINT> /mnt

# List the NFS exports visible to the client
showmount -e <NFS-IP>

    showmount -e 的輸出應包含已設定掛接點的項目：

    <NFS-MOUNT-POINT> <NFS-IP>

備份啟動程序節點資料

在執行還原之前，次要啟動程序節點必須能夠存取主要啟動程序節點中的下列項目。在災難復原 (DR) 事件發生前，將這些項目備份至安全的位置。

Omnissa 建議將此資料儲存在用於服務備份的同一部 NFS 伺服器上，但使用個別的 NFS 掛接點，以免干擾自動化備份作業。

項目主要啟動程序節點上的路徑
TLS 憑證/root/<cluster_name>/cp-cluster/secrets/cp-cluster/tls
保存庫解封金鑰和 root 金鑰/root/<cluster_name>/cp-cluster/secrets/cp-cluster/vault
服務部署環境變數/root/<cluster_name>/additional_env_vars.env
存取服務設定檔/root/<cluster_name>/access/access-profile.yml

設定備份頻率和保留期限

您可以在啟動程序節點上的 additional_env_vars.env 檔案中設定環境變數，以控制備份頻率和保留期限。這些設定會決定復原點目標 (RPO)，也就是發生故障時可能遺失的最大資料量。

變數說明
POSTGRESQL_FULL_BACKUP_CRON_SCHEDULE完整資料庫備份的 Cron 排程
POSTGRESQL_DIFF_BACKUP_CRON_SCHEDULE資料庫增量備份的 Cron 排程
CONTROL_PLANE_BACKUP_CRON_SCHEDULE控制平面元件備份 (Nomad、Consul 和 Vault) 的 Cron 排程
KEEP_DAYS_CP控制平面備份保留期限 (天)
WALG_RETENTION_DAYS資料庫備份保留期限 (天)
KEEP_DAYS_POSTGRES_BACKUP_LOGS資料庫備份記錄檔保留期限 (天)

資料庫備份類型

Omnissa Access 針對 PostgreSQL 資料庫採用兩種互補的備份類型。

完整備份

完整備份會擷取特定時間點的整個 PostgreSQL 資料目錄完整快照。完整備份可獨立還原，不需要任何其他備份檔案。依預設，完整資料庫備份會在每天 UTC 上午 5:00 執行一次，並作為增量備份的基準。

增量備份

增量備份只會擷取自最近一次完整備份以來發生變更的資料頁面。增量備份的檔案較小，完成所需時間也比完整備份短，但無法獨立還原。若要從增量備份還原，必須同時使用最近一次完整備份和該增量備份。依預設，增量備份會在每天 UTC 下午 5:00 執行一次。

完整備份和增量備份工作搭配使用，可提供完整的每日備份涵蓋範圍。如果故障發生在兩次排定備份之間，還原時會使用最近一次完整備份，並在其上套用最新的增量備份，將可能的資料遺失限制在約 12 小時內。

增量備份鏈深度

單一完整備份之上最多可串接 2 層增量備份。此限制由 WALG_DELTA_MAX_STEPS 在內部強制執行，無法設定。

Full Backup (base)
└── Delta 1 (changes since Full Backup)
    └── Delta 2 (changes since Delta 1)  ← maximum chain depth

當備份鏈達到設定的上限時，WAL-G 會自動將下一次排定的增量備份提升為新的完整備份。

您可以調整完整備份和增量備份的排程，但必須確保相鄰兩次完整備份之間最多只執行兩次增量備份。不支援超過此限制。

FQDN 與網路需求

為了在容錯移轉時不需要變更使用者或連接器組態，次要叢集必須在災難復原 (DR) 事件發生前符合下列需求：

  • 次要叢集端點上的 TLS 憑證必須適用於與主要叢集相同的完整網域名稱 (FQDN)。憑證輪替程序必須一致涵蓋主要站台和次要站台。
  • 防火牆規則必須允許輸出流量傳送至主要叢集和次要叢集端點。必須主動維護兩個站台所發佈的 IP 位址範圍。
  • 連接器工作階段狀態必須可在次要閘道上完整重建，且不得硬性依賴僅存在於主要叢集上的工作階段儲存區。

從備份還原 Omnissa Access

此程序說明如何在容錯移轉期間啟用次要叢集，使其成為新的主要叢集。完成還原後，次要叢集會處理所有讀取和寫入流量。原始主要叢集恢復可用後，將視為新的次要叢集，直到執行規劃的容錯回復作業為止。

**重要：**開始執行此程序前，請確保次要叢集無法連線至原始主要叢集。如果還原期間仍可連線至原始叢集，OpenSearch 和 PostgreSQL 可能會嘗試將原始叢集中的節點新增至還原後的叢集。

**附註：**Omnissa 建議先在非生產環境中執行計時還原演練，再於生產環境中部署災難復原。如此可根據實際資料量，建立符合實際情況的復原時間目標 (RTO) 估算。

先決條件

開始執行還原程序前，請確認符合下列條件：

  • 次要叢集將使用與來源叢集相同版本的資產服務包進行部署，以確保所有 Omnissa Access 服務映像一致。
  • 次要啟動程序節點可存取備份啟動程序節點資料中所列的啟動程序節點資料。

程序

步驟 1：部署次要叢集

佈建新的虛擬機器，並在這些虛擬機器上部署控制平面資產服務包。請使用與來源叢集相同版本的資產服務包。次要叢集的組態必須與來源叢集相同。

**重要：**在此步驟中，僅部署控制平面平台服務，也就是 Vault、Consul 和 Nomad。此階段請勿部署 Omnissa Access 服務。稍後將在此程序中還原 Access 服務。

繼續之前，請備份次要啟動程序節點上的 /root/<cluster_name>/cp-cluster/secrets/cp-cluster 目錄。

**預估時間：**30 分鐘

步驟 2：建立次要叢集節點的快照

成功部署控制平面後，請為所有次要叢集節點建立虛擬機器快照。如果需要重新開始執行災難復原程序，這些快照可提供已知良好的還原點。

**附註：**如果您在還原程序中的任何時間點還原至這些快照，請先確認次要叢集上的 Vault 已解封，再繼續執行。使用適當的認證登入 Vault UI，確認 Vault 狀態為已解封。

步驟 3：將密碼複製到次要叢集

將備份位置中的 tls 和 vault 資料夾複製到次要叢集的 backup_secrets 目錄：

  • 將已備份的 tls 資料夾複製到 → /root/<cluster_name>/cp-cluster/backup_secrets/tls
  • 將已備份的 vault 資料夾複製到 → /root/<cluster_name>/cp-cluster/backup_secrets/vault

完成複製後，請確認次要啟動程序節點上的 backup_secrets 目錄中包含這兩個資料夾：

ls -lrt backup_secrets/
total 0
drwxr-x---. 2 root root 64 May  7 07:46 tls
drwxr-x---. 4 root root 30 May  7 07:46 vault

步驟 4：規劃備份還原

在次要叢集目錄中執行下列命令，以檢閱備份並確認還原點：

wso cp plan-restore-backup

若要還原至特定時間點，請搭配時間長度使用 -a 旗標。例如：

加旗標含義
-a 1d最多回溯一天的最新備份
-a 2h最多回溯兩小時的最新備份
-a 30m最多回溯 30 分鐘的最新備份

此旗標會設定還原作業的復原點目標 (RPO)。

步驟 5：還原控制平面元件

此步驟會將 Consul 鍵值資料和 Vault 密碼還原至次要叢集。

  1. 確保次要叢集上的 Vault 已解封。

  2. 執行還原命令前，請確認次要啟動程序節點的 backup_secrets 目錄中包含 tls 和 vault 資料夾：

    ls -lrt /root/<cluster_name>/cp-cluster/backup_secrets/

    輸出應顯示 tls 和 vault 這兩個目錄：

    drwxr-x---. 2 root root 64 <date> tls
drwxr-x---. 4 root root 30 <date> vault

  3. 在叢集目錄中執行：

    wso cp restore-backup

    此命令會將 Consul 鍵值資料和 Vault 密碼還原至次要叢集。預期的輸出：

    Imports KV in case of disaster recovery
Backing up control plane credentials
Restoring vault
Restoring control plane credentials
Resetting vault integration tokens
Resetting vault integration token in nomad
Resetting vault PKI integration token
Updated vault with secrets after restore during Disaster recovery
Adding PKI root and intermediate CA to truststore
Deploying vault
Restarting vault servers
Unsealing Vault
Enabling consul and nomad integration with vault
Deploying consul
Configuring consul connect CA provider
Restarting the consul leader
Restarting nomad scheduler agent
Cleaning up
Generating environment file with cluster details and secret tokens

    **附註：**如果在此步驟中發生錯誤，請將所有次要叢集虛擬機器還原至步驟 2 建立的快照，確認次要叢集上的 Vault 已解封，然後從步驟 3 重新開始執行此程序。

    **預估時間：**15 分鐘

步驟 6：還原服務

此步驟會還原資料庫和所有服務。此步驟期間不會建立備份。

  1. 將環境變數檔案從備份位置複製到次要啟動程序節點：

    /root/<cluster_name>/additional_env_vars.env

  2. 將 Access 服務設定檔複製到次要啟動程序節點：

    /root/<cluster_name>/access/access-profile.yml

  3. 在 access-profile.yml 檔案中執行下列作業：

    • 更新 ip_ignore_list_for_xff_header 和 fqdn.ip 欄位，使其反映次要叢集的 IP 位址和組態。
    • 將 Nomad 子網路新增至 ip_ignore_list_for_xff_header 清單。
      • **附註：**預設值為 172.26.64.0/20。如果您在部署時選擇使用自訂子網路，請相應更新 ip_ignore_list_for_xff_header 欄位中的子網路值。

  4. 更新 DNS 伺服器，將 FQDN 導向次要叢集。

  5. 確認原始主要叢集已離線或無法連線。

  6. 執行下列命令以還原所有服務：

    wso services restore --cps_image <cps-image>

    **附註：**如果此步驟中的任何工作失敗，請清除該工作，然後重新執行相同的命令。

    若只要還原特定服務，請加入 -s 旗標：

    wso services restore -s <service-name> --cps_image <cps-image>

    其中，<cps-image> 是與來源叢集部署相符的控制平面服務映像標籤。

    **附註：**如果在此步驟中發生錯誤，請將所有次要叢集虛擬機器還原至步驟 2 建立的快照，確認次要叢集上的 Vault 已解封，然後從步驟 3 重新開始執行此程序。

    **預估時間：**至少 75 分鐘。實際所需時間會隨 PostgreSQL 和 OpenSearch 中的資料量呈線性增加。

步驟 7：完成還原並恢復備份作業

執行下列命令，以驗證還原的資料，並在新提升為主要叢集的叢集上啟用備份作業：

wso services restore-complete --cps_image <cps-image>

**預估時間：**10 分鐘

復原時間目標

整體復原時間目標 (RTO) 取決於 PostgreSQL 和 OpenSearch 中的資料量。預期的 RTO 最短約為兩小時，實際所需時間會隨資料量成比例增加。Omnissa 建議執行計時還原演練，以在生產環境容錯移轉中採用此程序前，確立適用於您部署的 RTO 數值。

此頁面對您有幫助嗎?

針對本主題提供意見回饋

本主題對您有幫助嗎?

請勿填寫任何個人或機密資訊。

正在產生連結…