故障转移到热备用

如何在Kubernetes、OpenShift,和Cloud Pak for Integration上的2DCDR部署中完成服务故障转移，适用于API Connect。

准备工作

确保您已阅读并了解 2DCDR 概念，并查看了 2DCDR 的关键概念和故障方案中描述的故障方案。在确认故障转移是针对您的情况的正确操作过程之前，请勿继续执行故障转移操作。

关于此任务

请注意以下要点:

该过程的第一步是将活动数据中心转换为热备用。将活动数据中心转换为热备用时，将从活动数据中心的管理数据库中删除所有数据，当这些数据变为活动时，将替换为从热备用复制的数据。
如果您怀疑热备用数据中心也有问题，并且您不确定它是否具有最新的管理数据，请不要继续进行故障转移。请参阅验证数据中心之间的复制，并考虑从备份复原活动站点，而不是尝试故障转移: 2DCDR 部署的备份和复原需求。
在所有场景中，必须避免主动/主动配置。主动/主动配置是将两个数据中心内的 API Connect 子系统配置为活动的位置。这种情况俗称裂脑。主动/主动配置意味着每个数据中心内的子系统数据库相互分离，两个管理子系统都在尝试管理其他 API Connect 子系统。
如果活动数据中心故障阻止您将其转换为热备用，那么必须禁用与此数据中心上发生故障的管理和门户网站子系统之间的网络连接，以防止发生意外的主动/主动情况 (如果发生故障的数据中心意外恢复)。
如果您正在执行操作故障转移，那么此过程将导致临时管理和门户网站 UI 中断，直到新的热备用完成转换为活动状态为止。

注： OpenShift® 用户：本主题中详细介绍的步骤使用 Kubernetes kubectl 命令。在 OpenShift, 使用等效的 oc 命令来代替它。如果您正在使用顶级 CR ，那么必须在顶级 CR 中编辑子系统的 multiSiteHA 部分，而不是直接在子系统 CR 中编辑。

过程

管理子系统故障转移

在这些示例步骤中， DC1 是活动数据中心， DC2 是热备用数据中心。

要完成从 DC1 到 DC2的故障转移，请先将 DC1 设置为热备用，然后再将 DC2 设置为活动状态。需要此顺序以防止出现主动/主动情况。
1. 将 DC1 管理子系统设置为热备用。
  - 在 Kubernetes 和 OpenShift 各个子系统 CR 部署上: 创建名为 demote-to-warm-standby.yaml的文件，并粘贴以下文本:
    metadata: annotations: apiconnect-operator/dr-data-deletion-confirmation: "true" spec: multiSiteHA: mode: passive
    将 demote-to-warm-standby.yaml 文件中指定的更新应用于管理 CR:
    kubectl patch mgmt <mgmt cr name> --type merge --patch "$(cat demote-to-warm-standby.yaml)"
  - 在 Cloud Pak for Integration 和 OpenShift 顶级 CR 部署上: 创建名为 demote-to-warm-standby.yaml的文件，并粘贴以下文本:
    metadata: annotations: apiconnect-operator/dr-data-deletion-confirmation: "true" spec: management: multiSiteHA: mode: passive
    将 demote-to-warm-standby.yaml 文件中指定的更新应用到 API Connect CR 中：
    oc patch apiconnectcluster <apic cr name> --type merge --patch "$(cat demote-to-warm-standby.yaml)"
  注: 如果 DC1 上的 API Connect 已关闭，因此无法将其设置为热备用，那么必须确保禁用与 DC1 中管理子系统的网络连接，以防止发生意外的主动/主动情况 (如果 DC1 意外恢复)。在将 DC1 设置为热备用之前，请勿复原网络连接。
2. 在 DC1 上运行以下命令以检查管理子系统 HA 方式是否不再 active:
```
kubectl get mgmt -o yaml
```
  在转换为热备用期间， status.haMode 显示 BlockedWarmStandbyConversion。您可以使用以下命令来监视转换:
```
kubectl get mgmt -o=jsonpath='{"Status: "}{.status.phase}{"\n - HA Mode: "}{.status.haMode} {"\n - Ha Status: "}{.status.haStatus[?(@.status=="True")].type}{"\n"}'
```
```
Status: Blocked
 - HA Mode: BlockedWarmStandbyConversion
 - Ha Status: BlockedWarmStandbyConversion
```
3. 将 DC2 管理子系统从热备用更改为活动。
  检查 DC2 管理子系统 haStatus:
```
kubectl get mgmt -o yaml
```
```
status
  ...    
  haMode: ReadyForPromotion
    haStatus: 
      ...
      type: ReadyForPromotion
  ...
```
  等待 haStatus 显示 ReadyForPromotion ，然后再继续。您可以使用以下命令来监视转换:
```
kubectl get mgmt -o=jsonpath='{"Status: "}{.status.phase}{"\n - HA Mode: "}{.status.haMode} {"\n - Ha Status: "}{.status.haStatus[?(@.status=="True")].type}{"\n"}'
```
```
Status: Blocked
 - HA Mode: ReadyForPromotion 
 - Ha Status: ReadyForPromotion
```
  - 在 Kubernetes 和 OpenShift 各个子系统 CR 部署上:
    编辑 DC2 管理 CR:
    kubectl edit mgmt
    将 spec.multiSiteHA.mode 更改为 active:
  - 在 Cloud Pak for Integration 和 OpenShift 顶级 CR 部署上:
    编辑 DC2 APIConnectCluster CR:
    oc edit apiconnectcluster
    将 spec.management.multiSiteHA.mode 更改为 active。
4. 在两个数据中心上运行以下命令以确认管理子系统故障转移何时完成:
```
kubectl get mgmt
```
  示例输出如下所示：
```
production-mgmt   n/n   Running   10.0.x.y   10.0.x.y        Management is ready. HA status Ready - see HAStatus in CR for details
```
  注: 故障转移可能需要 10 分钟或更长时间才能完成。如果故障转移未完成，那么可以检查 API Connect 操作程序 pod 日志中是否存在错误 (搜索单词 Multi)。
5. 更新动态路由器以将所有流量重定向到 DC2 而非 DC1。在 DC2 站点变为 active之前， UI 可能无法运行。
6. 仅限 Cloud Pak for Integration : 检查 APIConnectCluster CR 状态:
```
oc get apiconnectcluster
```
  如果状态返回 Warning:
```
NAME         READY   STATUS    VERSION    RECONCILED VERSION   MESSAGE                                      AGE
production   4/5     Warning   10.0.8.0   10.0.8.0-7178        Warning - see status condition for details   7d9h
```
  然后检查状态条件:
```
oc get apiconnectcluster <apiconnectcluster cr name> -o json | jq -r '.status.conditions[] | select(.status=="True")'
```
  如果输出显示以下条件:
```
{
  "lastTransitionTime": "2024-05-29T18:15:16Z",
  "message": "an error occured while running job apic/production-configurator",
  "reason": "na",
  "status": "True",
  "type": "Warning"
}
```
  然后在新的活动数据中心上运行以下命令:
```
oc -n <namespace> delete job -l app.kubernetes.io/component=configurator
```
  其中 <namespace> 是 APIConnectCluster的名称空间。
Developer Portal 子系统故障转移

在这些示例步骤中， DC1 是活动数据中心， DC2 是热备用数据中心。

如果您有多个 Developer Portal 服务，那么必须对要故障转移的每个 Developer Portal 子系统重复这些步骤。
1. 将 DC1 Developer Portal 子系统设置为热备用。
  - 在 Kubernetes 和 OpenShift 各个子系统 CR 部署上:
    编辑 DC1 PortalCluster CR:
    kubectl edit ptl
    将 multiSiteHA.mode 更改为 passive。
  - 在 Cloud Pak for Integration 和 OpenShift 顶级 CR 部署上:
    编辑 DC1 APIConnectCluster CR:
    oc edit apiconnectcluster
    将 spec.portal.multiSiteHA.mode 更改为 passive。
  注: 如果 DC1 上的 API Connect 已关闭，因此您无法将其设置为热备用，那么必须确保禁用与 DC1 中的门户网站子系统的网络连接，以防止发生意外的主动/主动情况 (如果 DC1 意外恢复)。在将 DC1 设置为热备用之前，请勿复原网络连接。
2. 在 DC1 上运行以下命令以检查 Developer Portal 子系统状态:
```
kubectl get ptl -o yaml
```
  当 status.haMode 设置为 progressing to passive或任何 passive 状态时，继续执行下一步。
  例如：
```
status:
  ...
  haMode:                            progressing to passive
  ...
```
3. 将 DC2 Developer Portal 子系统从热备用更改为活动。
  - 在 Kubernetes 和 OpenShift 各个子系统 CR 部署上:
    编辑 DC2 PortalCluster CR:
    kubectl edit ptl
    将 spec.multiSiteHA.mode 更改为 active。
  - 在 Cloud Pak for Integration 和 OpenShift 顶级 CR 部署上:
    编辑 DC2 APIConnectCluster CR:
    oc edit apiconnectcluster
    将 spec.portal.multiSiteHA.mode 更改为 active。
4. 更新动态路由器以将所有流量重定向到 DC2 而非 DC1。
5. 运行以下命令以检查 DC1 和 DC2 上的 Developer Portal 服务是否已准备好处理流量:
```
kubectl get ptl -o yaml
```
  当 status.haMode 在 DC1上设置为 passive 并且在 DC2上设置为 active 时，这些服务已为流量准备就绪。
管理子系统和门户网站子系统的故障转移

首先对管理子系统进行故障转移，然后对门户网站子系统进行故障转移。
完成故障转移所需的时间不尽相同，具体取决于硬件速度、网络等待时间和数据库大小。近似计时为:
对于管理子系统:
- warm-standby 到 active: 5 分钟
- active 到 warm-standby: 15 分钟
对于 Developer Portal:
- warm-standby 到 active: 15-40 分钟
- active 到 warm-standby: 10 分钟

后续操作

如果原始活动数据中心已成功转换为热备用，请验证复制是否正常工作: 验证数据中心之间的复制。如果复制正在工作，那么可以执行下列任一操作:

将 2DCDR 部署还原为原始活动和热备用数据中心指定。要还原部署，请遵循本主题中的相同故障转移步骤。
不执行任何操作，并继续当前活动和热备用数据中心指定。

如果发生故障的数据中心无法更新为热备用，请确保已禁用与发生故障的数据中心内的管理和门户网站子系统之间的网络链接。如果网络链路保持启用状态，那么在发生故障的数据中心意外恢复时，可能会发生意外的主动/主动情况。

当您能够恢复发生故障的数据中心时，请确保在复原网络连接之前将管理子系统和门户网站子系统设置为热备用，以防止出现主动/主动情况。

注: 原始活动数据中心处于失败状态的时间越长，恢复到热备用时，数据复制所需的时间越长。

如果您期望发生故障的数据中心长时间关闭，请将活动数据中心转换为独立部署。请参阅除去两个数据中心部署。