Omnissa Access 集群的集群重新引导或计划内维护

在重新引导任何节点后，该节点不会自动重新加入 Omnissa Access 集群。必须从引导节点运行 wso cp unseal，才能还原集群成员资格。

**注意：**此行为仅适用于当前临时内部版本。

请根据您的维护方案，使用以下相应的过程选项。

方案 1 - 计划内维护：一次重新引导一个节点

一次重新引导一个节点可保持集群可用性。在重新引导期间，集群会以降低的容量保持正常运行。

Omnissa Access 节点

1. 关闭要维护的节点。

2. 监控集群运行状况和服务状态。

   集群应保持正常运行，且每项服务有一个实例在以降低的容量运行。

3. 完成维护并使节点恢复联机。

4. 从引导节点，运行：

   wso cp unseal
   

5. 从引导节点，运行以下命令以验证集群运行状况。

   等待所有服务恢复联机：

   wso healthcheck
   

6. 确认每项服务有两个实例在运行。

7. 运行以下命令以确认所有服务都已准备好处理流量：

   wso access check-service-readiness
   

如果两个 Access 节点都关闭（计划外）：

1. 在两个节点恢复联机后，从引导节点运行以下命令：

   wso cp unseal
   

2. 从引导节点运行 wso healthcheck，并等待所有服务恢复联机。
3. 确认每项服务有两个实例在运行。
4. 运行 wso access check-service-readiness 以确认各项服务已准备好处理流量。

基础架构/平台节点

一次重新引导一个节点。在重新引导期间，基础架构服务（PostgreSQL、Kafka、Redis 和 OpenSearch）保持有两个实例正常运行。

1. 关闭要维护的节点。

2. 监控集群运行状况。

   集群应保持正常运行，且每项基础架构服务有两个实例在运行。

3. 完成维护并使节点恢复联机。

4. 从引导节点，运行：

   wso cp unseal
   

5. 从引导节点，运行 wso healthcheck 以验证集群运行状况。

   等待所有服务恢复联机。

6. 确认每项基础架构服务有三个实例在运行。

如果所有基础架构/平台节点都关闭（计划外）：

1. 在所有节点恢复联机后，从引导节点运行以下命令：

   wso cp unseal
   

2. 从引导节点运行 wso healthcheck，并等待各项服务恢复联机。
3. 确认每项基础架构服务有三个实例在运行。

对引导节点进行重新引导

对引导节点进行重新引导不会影响集群服务。引导节点仅负责集群初始化，而不运行关键服务。

方案 2 - 计划内维护：不降低性能（缓冲区节点）

要在不降低服务性能的情况下执行维护，请在开始之前添加临时缓冲区节点。这样，服务就可以从要维护的节点中迁移。

1. 使用与现有节点相同的配置部署新节点，并将其添加到集群。

2. 从引导节点，使用新节点 IP 更新 cp-cluster.ini 并运行：

   wso cp deploy -t <new-node-ip>
   

3. 从 Nomad UI 对要维护的节点进行引流（客户端 > 选择节点 > 引流）。

   此操作会将所有服务迁移到其他节点（包括缓冲区节点），而不会影响性能。

4. 一次对一个现有节点执行维护操作。

5. 维护完成后，可以选择通过从 cp-cluster.ini 中删除缓冲区节点的条目并将其关闭来移除该节点。

   此外，也可以将其保留为备用节点，以供将来维护时使用。

6. 从引导节点，运行：

   wso cp unseal
   

7. 运行 wso healthcheck 以验证集群运行状况。

8. 确认每项 Access 服务有两个实例、每项基础架构/平台服务有三个实例在运行。

9. 运行 wso access check-service-readiness 以确认所有服务都已准备好处理流量。

   **注意：**在节点重新引导和运行 wso cp unseal 后，等待所有服务恢复联机并形成正常集群。在此期间监控集群运行状况。如果服务无法恢复，请在 Nomad UI 中查看其日志，清除该服务，然后重新部署：

   wso services deploy -s <service-name>