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
Vault 解封密钥和根密钥/root/<cluster_name>/cp-cluster/secrets/cp-cluster/vault
服务部署环境变量/root/<cluster_name>/additional_env_vars.env
Access 服务配置文件/root/<cluster_name>/access/access-profile.yml

配置备份频率和保留时间

您可以通过在引导节点上的 additional_env_vars.env 文件中设置环境变量，控制创建备份的频率及其保留时间。这些设置可确定恢复点目标 (Recovery Point Objective, RPO)，即发生故障时可能会丢失的最大数据量。

变量描述
POSTGRESQL_FULL_BACKUP_CRON_SCHEDULE完整数据库备份的 Cron 调度
POSTGRESQL_DIFF_BACKUP_CRON_SCHEDULE数据库增量备份的 Cron 调度
CONTROL_PLANE_BACKUP_CRON_SCHEDULE控制平面组件备份的 Cron 调度（Nomad、Consul、Vault）
KEEP_DAYS_CP控制平面备份的保留期限（天）
WALG_RETENTION_DAYS数据库备份的保留期限（天）
KEEP_DAYS_POSTGRES_BACKUP_LOGS数据库备份日志文件的保留期限（天）

数据库备份类型

Omnissa Access 对 PostgreSQL 数据库使用两种互补的备份类型。

完整备份

完整备份在特定时间点捕获整个 PostgreSQL 数据目录的完整快照。完整备份是独立的，无需任何其他备份文件即可还原。默认情况下，完整数据库备份会在每天凌晨 5:00 UTC 运行一次，用作增量备份的基准。

增量备份

增量备份仅捕获自最近一次完整备份以来发生更改的数据页面。与完整备份相比，增量备份更小且完成得更快，但它们不是独立的；从增量备份还原需要最新的完整备份和增量备份。默认情况下，增量备份会在每天下午 5:00 UTC 运行一次。

完整备份作业和增量备份作业共同提供完整的每日数据覆盖。在计划备份间隔期间发生故障时，还原操作将使用最新完整备份并在此基础上应用最新增量备份，从而将潜在的数据丢失限制在大约 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 证书必须对与主集群相同的完全限定域名 (Fully Qualified Domain Name, FQDN) 有效。证书轮换过程必须始终涵盖主站点和辅助站点。
  • 防火墙规则必须允许传输到主集群端点和辅助集群端点的出站流量。必须主动维护两个站点的已发布 IP 地址范围。
  • 连接器会话状态必须在辅助网关上完全可重建，且不硬性依赖仅存在于主集群上的会话存储。

从备份还原 Omnissa Access

此过程介绍了如何在故障切换期间将辅助集群激活为新的主集群。还原完成后，辅助集群会处理所有读取和写入流量。原始主集群重新可用后，会被视为新的辅助集群，直到执行了计划的故障恢复为止。

**重要信息：**在开始此过程之前，请确保无法从辅助集群访问原始主集群。如果在还原期间仍可访问原始集群，OpenSearch 和 PostgreSQL 可能会尝试将原始集群中的节点添加到还原的集群。

**注意：**Omnissa 建议在生产环境中部署灾难恢复之前，先在非生产环境中执行定时还原演练。这有助于根据实际数据量确定切合实际的恢复时间目标 (Recovery Time Objective, RTO) 估算值。

必备条件

在开始还原过程之前，请确认：

  • 将使用与源集群相同的资产包版本部署辅助集群，以确保所有 Omnissa Access 服务映像均匹配。
  • 备份引导节点数据中列出的引导节点数据可在辅助引导节点上访问。

过程

步骤 1：部署辅助集群

置备新虚拟机，并使用与源集群相同的资产包版本在新虚拟机上部署控制平面资产包。辅助集群必须与源集群具有相同的配置。

**重要信息：**在此步骤中，仅部署 CP 平台服务 — 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 数值。

此页面对您有帮助吗?

对本主题提供反馈

本主题对您有帮助吗?

请勿填写任何个人信息或机密信息。

正在生成链接…