管理 Omnissa Access Control Plane 集群节点

本主题介绍如何通过添加 Omnissa 基础架构/平台节点和 Access 节点来替换现有的控制平面部署，并说明当节点运行不正常且从集群中移除时会发生什么情况。

将 Omnissa Access 节点添加到集群

可以通过将 Omnissa Access Linux 节点添加到集群来替换现有的控制平面节点。新节点使用 wso cp deploy 命令从引导节点载入。

必备条件

• 运行部署命令之前，已将新节点的 IP 地址添加到 cp-cluster.ini 中的相应主机组下。
• 新节点可通过 SSH 从引导节点进行访问。

过程：

1. 打开 /opt/wss/<cluster_name>/cp-cluster/cp-cluster.ini 文件，然后在相应的主机组下添加新节点的 IP 地址。例如：

   选项 1 - Omnissa Access 节点： 如果要添加新的 Omnissa Access 节点，请在以下部分下添加该节点：

   [general_compute_access_linux]
   10.0.0.x
   10.0.0.x  # New node
   [vault_server_linux]
   10.0.0.x  # New node
   [consul_server_linux]
   10.0.0.x  # New node
   [nomad_server_linux]
   10.0.0.x  # New node
   [general_compute_nginx_http]
   10.0.0.x  # New node
   

   选项 2 - 基础架构/平台节点： 如果要为基础架构/平台节点添加新节点，请在除以下部分以外的所有其他部分下添加该节点：

   [general_compute_access_linux]
   [general_compute_nginx_http]
   [asset_server_linux]
   
   # If the new node is a candidate for asset-server-linux that will replace existing asset-server, you must add a node IP in asset_server_linux, too.
   

   **重要信息：**不要将引导节点 IP 地址添加到清单中。如果检测到引导 IP，验证会失败。

2. 从引导节点，运行 wso cp deploy 以载入节点。

   • 要载入一个或多个特定节点，请使用 -t (--target-hosts) 标记：

     # navigate to your cluster working directory
     cd /opt/wss/<cluster_name>
     wso cp deploy -t "10.0.0.x"
     

     对于多个节点：

     cd /opt/wss/<cluster_name>
     wso cp deploy -t "10.0.0.x,10.0.0.x"
     

3. 运行以下命令，检查集群是否处于正常状态：

   wso healthcheck
   

4. 将工作负载（服务）移至新节点。 默认情况下，新添加的节点上不会运行任何工作负载。 您应使用 Nomad 令牌登录 Nomad UI，并执行以下步骤。

   1. 登录 Nomad UI，网址为 https://10.0.0.x:4646/ui/jobs。
   2. 单击客户端。
   3. 单击要从中移动工作负载的节点 ID。
   4. 单击引流以将工作负载移至新虚拟机。

   **注意：**完成引流操作后，所有工作负载都将移至新虚拟机。无法将选定的服务移至新节点。

5. 通过执行以下命令，从集群中移除现有节点。

   # From the bootstrap VM
   source /opt/wss/<cluster_name>/cp-cluster/cp-cluster.env
   server_id = <node_ip> # IP of the node being removed
   
   # API to remove peer
   curl -sk \
   -H "X-Vault-Token: $VAULT_TOKEN" \
   -H "Content-Type: application/json" \
   -X POST \
   -d '{"server_id":"$server_id"}' \
   "$VAULT_ADDRESS/v1/sys/storage/raft/remove-peer"
   

6. 验证集群和服务的运行状况。

   wso healthcheck
   wso access check-service-readiness
   

故障排除

从集群中移除 Omnissa Access 节点

没有专门的 CLI 命令用于从控制平面集群中移除节点。当节点不可用或运行不正常时，集群会自动处理移除：

• 在丢失大约两个检测信号后，节点会停止接收新的工作负载分配。
• 节点上的现有工作负载会重新调度到正常节点。
• 不需要执行手动移除命令。

1. 从 cp-cluster.ini 文件中的所有相关部分移除旧节点 IP。
2. 关闭已移除节点的电源。

**注意：**集群成员资格清理的时间线与故障检测不同：

• Consul 会在 24 到 72 小时内自动清除其成员列表中的非活动节点。
• Nomad 会在下一个垃圾数据收集周期中移除失效节点。
• 因此，已移除的节点在停止接收流量后，仍可能会在 Nomad 或 Consul UI 中显示一段时间，尽管该节点已不再用于调度。

控制平面集群节点的密码管理

configuser 和 root 帐户的默认密码有效期是 60 天。您必须在密码过期之前更改每个控制平面集群节点上的密码。

root 密码和 configuser 密码不需要相互匹配，但每个密码在集群中的所有节点上必须相同。例如，所有节点上的 root 密码必须相同，所有节点上的 configuser 密码也必须相同。

重置 configuser 或 root 密码

单个节点，以 root 身份或通过 sudo 登录：

passwd configuser
passwd root

一次在所有节点上，从引导节点中：

export TARGETS='general_compute_linux:general_compute_access_linux'
wso control-plane ansible -- -b -m shell -a "echo 'configuser:NEW_PASSWORD' | chpasswd" "${TARGETS}"
wso control-plane ansible -- -b -m shell -a "echo 'root:NEW_PASSWORD' | chpasswd" "${TARGETS}"

在运行之前，请将 NEW_PASSWORD 替换为实际的密码，并将 ${TARGETS} 替换为要更新的节点的 Ansible 清单组或主机模式 — 请勿在已保存的脚本或 Shell 历史记录中保留文字占位符。

**重要信息：**更改 configuser 密码后，请在引导节点上的 cp-cluster.ini 中更新相同的密码，否则针对集群执行 wso CLI 操作时将开始出现身份验证失败。重置密码后，无需使活动的 configuser 会话失效。

更改密码有效期

60 天的有效期由每个帐户上的密码时效字段控制。

**注意：**如果以 configuser 身份运行，请在命令前面使用 sudo。

使用以下命令查看当前设置：

chage -l configuser
chage -l root

按帐户更改该设置（单个节点）：

chage -M <days> configuser
chage -M <days> root

-M 将设置密码保持有效的最大天数；-1 将禁用过期（通常不建议用于 root 或服务帐户）。

恢复完全忘记的 root 密码

这需要对受影响的虚拟机进行控制台 (Hypervisor) 访问 — 该操作不能通过 SSH 完成，并且一次只能恢复一个节点。

1. 重新引导虚拟机并在 GRUB 菜单中断。

2. 突出显示引导条目，然后按 e 键进行编辑。

3. 找到以 linux（或 linux16）开头的行，转到该行末尾，然后附加：

   rd.break enforcing=0
   

4. 按 Ctrl+X（或 F10）以使用修改后的参数进行引导 — 这会使您进入 Dracut 紧急 Shell。

5. 以读写模式重新挂载根文件系统，并运行 chroot 以进入该文件系统：

   mount -o remount,rw /sysroot
   chroot /sysroot
   

6. 设置新密码：

   passwd root
   

7. 将该文件系统标记为在下次引导时进行 SELinux 重新标记，因为此会话的 SELinux 处于许可模式：

   touch /.autorelabel
   

8. 退出 chroot 并重新引导：

   exit
   reboot
   

   由于 SELinux 重新标记，在此之后首次引导所需的时间会比平时长。