2DCDR 和故障方案的关键概念

了解 API Connect 2DCDR 的工作方式以及在数据中心发生故障时要执行的操作。

本主题讨论有关 API Connect 2DCDR 部署的操作和维护的概念。 有关规划和安装 2DCDR 部署的信息,请参阅: Two data center warm-standby deployment on Kubernetes 和 OpenShift

故障转移

故障转移是一项手动操作,需要更新活动管理子系统,门户网站子系统或两个子系统以成为 热备用子系统,并更新 热备用 子系统以成为活动子系统。 完成故障转移操作的典型情况如下:
  • 操作故障转移: 活动的 API Connect 子系统和数据中心正常工作,但您希望出于操作原因切换数据中心,或者测试故障转移过程。

    在此场景中,首先将活动管理和门户网站子系统转换为 热备用 ,然后将原始 热备用 子系统转换为活动。

  • 系统停机故障转移: 当活动数据中心或该数据中心中的 API Connect 子系统处于故障状态时,您必须故障转移到 热备用 以复原 API Connect 服务。

    在此场景中, 热备用 数据中心内的子系统将转换为活动,并且将禁用与发生故障的活动子系统之间的网络连接,直到可以将它们转换为 热备用为止。

重要说明:
  • 在所有场景中,必须避免主动/主动配置。 主动/主动配置是将两个数据中心内的 API Connect 子系统配置为活动的位置。 这种情况俗称裂脑。 主动/主动配置意味着每个数据中心内的子系统数据库相互分离,两个管理子系统都在尝试管理其他 API Connect 子系统。
  • 当活动管理子系统设置为 warm-standby时,将从其数据库中删除所有数据。 来自新活动 (什么是 热备用) 的管理数据将复制到新的 热备用 数据中心。 在确认数据复制正在工作之前,请不要将活动数据中心设置为 热备用 ,请参阅: 验证数据中心之间的复制,或者具有管理数据的备份。

还原为独立部署

如果要还原为独立 API Connect 部署,请在启动该过程之前,确保选择使 API Connect 保持活动状态的数据中心设置为活动状态。
  • API Connect 还原为 热备用 数据中心上的独立部署时,将从该数据中心删除所有管理和门户网站数据。 它将变为空的独立部署。
  • 当活动数据中心上的 API Connect 还原为独立部署时,将保留所有管理和门户网站数据。

故障场景

发生故障时应执行的操作取决于故障类型以及发生故障的数据中心:
活动数据中心发生 API Connect 故障。
当活动数据中心仍在正常工作,并且仍与 热备用 数据中心连接,但 API Connect 未正常工作时:
  1. 可能可以在活动数据中心上恢复 API Connect 。 查看故障诊断文档:
  2. 遵循故障转移步骤,使 热备用 成为活动的数据中心。 如果发生故障的数据中心无法更改为 热备用,请禁用与其之间的网络连接,以避免在数据中心意外恢复时出现 主动/主动 情况。
  3. 从故障数据中心收集 API Connect 日志并打开支持请求:收集日志
  4. 在将发生故障的数据中心内的 API Connect 子系统设置为 热备用之前,请勿复原与这些子系统之间的网络连接。
完成活动数据中心故障
当活动数据中心发生故障并且 API Connect 不可访问时,请执行以下步骤:
  1. 禁用与活动子系统之间的网络连接。 需要网络禁用以防止发生主动/主动场景 (如果发生故障的数据中心恢复) ,然后才能将其更改为 热备用
  2. 执行故障转移步骤以将 热备用 数据中心转换为活动: 故障转移到热备用
  3. 在将发生故障的数据中心内的 API Connect 子系统设置为 热备用之前,请勿复原与这些子系统之间的网络连接。
阻止 API 调用或用户访问活动数据中心上的管理和门户网站子系统的网络故障。
在此场景中, API Connect 2DCDR 部署工作正常,但不可用,因为活动数据中心不可供 API 调用或管理和门户网站 UI/CLI/REST API 用户访问。
  1. 完成故障转移,将 热备用 设置为活动,并将活动设置为 热备用: 故障转移到热备用
暖-备用 数据中心上发生 API Connect 故障
其中 warm-standby 数据中心上的 API Connect pod 未按预期运行。
  1. 查看故障诊断文档 对两个数据中心复制问题进行故障诊断
  2. 从故障数据中心收集 API Connect 日志并打开支持案例:收集日志
热备用 数据中心故障
API Connect 作为 热备用 运行的数据中心发生故障。 在此情况下,当恢复数据中心时:
  1. 验证 API Connect 是否作为 热备用 正确运行,以及是否将活动数据复制到该活动数据: 验证数据中心之间的复制
数据中心之间的网络故障
恢复数据中心之间的网络连接时,请验证 2DCDR 数据库复制是否恢复: 验证数据中心之间的复制

管理 2DCDR 操作方式和状态

管理 CR status 部分包含有关管理子系统的当前 2DCDR 方式及其状态的信息。 状态部分包含在
kubectl -n <namespace> get mgmt -o yaml
...
status:
...
  haMode: active
  ...
  haStatus: 
表 1。 2DCDR 管理子系统操作方式 (status.haMode)
操作方式 描述
active 子系统 pod 已就绪,并且处于活动数据中心的正确灾难恢复状态。
passive 子系统 pod 已就绪,并且处于 热备用 数据中心的正确灾难恢复状态。
standalone 没有为 2DCDR配置管理子系统。
表 2. 管理子系统 2DCDR 状态 (status.haStatus)
status.haStatus 描述
暂挂 2DCDR 初始状态。
警告 复制失败。
准备就绪 正在复制。
错误 2DCDR 配置中出错。
PeerNotReachable 子系统无法与另一个站点上的子系统联系,因此复制失败。
BlockedWarmStandbyConversion 热备用 子系统处于 Blocked 状态,正在等待其他站点变为活动状态。 当用户将现有 热备用 转换为活动时,会发生此状态。
PromotionBlocked 当前 热备用 站点提升到活动状态的操作已阻塞
ReadyForPromotion 当前 热备用 站点已准备好进行升级
PGStateSetupBlocked

仅在活动数据中心上显示。 此状态表示 warm-standby 尚未启动与活动的操作员级别通信。 活动管理子系统正在阻止来自 热备用的传入数据库级别连接尝试。

Portal 2DCDR 操作状态

门户网站子系统具有在启动和故障转移期间传递的各种过渡状态。 可以从 CR 状态部分观察当前 2DCDR 操作状态,例如:
kubectl get ptl -o yaml
...
status:
...
  haMode: active
  ...
  haStatus: 
表 3。 2DCDR Portal 子系统操作状态
运行状态 描述
progressing to active Pod 正在进入活动状态,但子系统无法为流量提供服务。
progressing to active (ready for traffic) 每种类型的至少一个 pod 准备好接受流量。 可将动态路由器链接到此服务。
active 子系统 pod 已就绪,并且处于活动数据中心的正确灾难恢复状态。
progressing to passive Pod 正在进入 warm-standby 状态。 子系统无法为流量提供服务。
progressing to passive (ready for traffic) 每种类型的至少一个 pod 准备好接受流量。
passive 子系统已就绪,并且处于 热备用 数据中心的正确灾难恢复状态。
progressing to down Portal 正在准备执行出厂重置。 当除去 multiSiteHA 部分时,会在 热备用 门户网站中发生此情况。