OpenText Exceed TurboX(以下简称 ETX)是芯片研发环境中常见的远程图形会话平台。其架构里有两个关键角色:

  • etxsvr:管理服务器(ETX Server / Server Manager / etxdb),处理用户登录、Dashboard、REST API、Profile 分发、Session 调度、License 控制、集群复制等。
  • etxcn:Connection Node(连接节点),实际承载 X server / Windows RDP / VirtualGL 等会话进程。

EDA 用户日常感知到的 “Virtuoso/Innovus/Verdi 长时间挂起 session 不掉” 主要发生在 etxcn 上。只要 etxcn 不停,session 就不掉。这也是滚动升级 etxsvr 的关键前提:换 etxsvr 不应影响 etxcn 上正在跑的 session。

本文基于 ETX etx-svr-mgr-guide-1254(12.5.4)官方 Server Manager Administration Guide,结合实际运维场景,整理:

  1. 如何安装第二台、第三台 etxsvr,并加入到 HA 集群;
  2. 如何把 etxcn 接入到这个 HA 集群(”etxcn join” 在 ETX 里其实是 Server Manager 端的节点注册动作);
  3. 如何做滚动升级(rolling upgrade),逐台升级 etxsvr 而不影响 etxcn 上的活跃 session 与挂起 session。

详细的安装步骤(操作系统准备、防火墙端口、etxdb 复制网络、磁盘容量、Java 堆参数等)以 Exceed TurboX High Availability Configuration Guide 为准。本文聚焦集群命令行操作与升级流程。

0. 一个关键架构事实:etxsvr → etxcn 是单向控制

在动手之前先把 ETX 控制面方向钉死,因为后面所有”升 etxsvr 不影响 etxcn”的结论都建立在这一条上:

  • etxcn 是被动方:监听端口(默认 5510),等待 etxsvr 主动连入做控制。
  • 注册一台 etxcn 给集群时,Admin 在 Server Manager Nodes and Sessions → Nodes → Register node 输入的只有 etxcn 自己的 host/IP + port(5510)这两项;注册后由 Server Manager 主动连出去到 etxcn。
  • 节点记录写入 etxdb 后,通过集群复制同步到所有 etxsvr,集群里任何一台健康成员都能管理这台 etxcn。
  • etxcn 自身不持有任何一台具体 etxsvr 的”上游地址”作为长期控制通道。”etxcn 装机时填的那个 etxsvr IP”(如果安装脚本确实问过)至多是用来安装完成时回调注册一次,注册结果一进 etxdb 就开始复制到全集群,之后那个 IP 对该 etxcn 不再起作用。

因此结论是清晰的:“etxcn 安装时只填了第一台 etxsvr 的 IP” 不会影响后续滚动升级。即便首台 etxsvr 停机维护,其他健康成员仍能通过 5510 管理同一台 etxcn,etxcn 上的 X server / Xvnc / EDA 进程不受影响。

依据:/etx/help/admin/admin/nodes/registering-connection-nodes.html。该页面只描述了 etxsvr → etxcn 单向注册,并明确指引节点安装脚本细节查 Exceed TurboX Installation and Configuration Guide 中 “Installing Exceed TurboX Connection Nodes” 一节。


1. etxsvr 集群是什么

ETX HA 集群是一组 all-active 的 etxsvr,特点:

  • 仅 Linux / Solaris 支持。Windows 上的 etxsvr 不支持 HA。
  • 集群中的每台 etxsvr 都可作为 active server,用户和管理员都可以连接任意一台访问 Dashboard / Server Manager / REST API。
  • 集群通过 etxdb(ETX 内嵌的复制数据库)进行 双向数据复制。每个 server 都有自己的 recovery journal、replication sender/receiver。
  • 集群中有一台 master 角色,负责发邮件、生成报表等”单实例”任务。Site Settings → Cluster → Preferred master 可指定首选 master,60 秒生效。当前 master 不可用时,集群会自动选出一台新的。
  • License Server 不支持 HA。License Server 是独立的、不能放进 HA 集群(虽然你可以让多个 ETX site 共用同一台 remote License Server)。

集群成员列表可以在 Server Manager 的 Site Settings → Cluster → Servers 里看到,每行展示:

含义
Name 集群内唯一名
Address 复制使用的 server 地址
Version etxsvr 版本(升级时强相关
State Live mode / Maintenance mode
Link status 网络连接状态
Replication status 是否准备好收发复制数据
Resync data recovery journal 中未发送出去的数据量
Replication backlog 已收到但未 replay 的数据量
Master 是否是 master

红色行表示该成员需要立即关注(异常或错误)。


2. 安装多台 etxsvr 并加入集群

下文假设已有一台已经初始化好的 etxsvr(创建了 etxadmin 密码、上传了 license),现在要扩展到 2~3 台。

2.1 关键约束

  • 加入集群的 etxsvr 必须是干净 server,未初始化 etxdb。即:装完 etxsvr 后不要启动 Server Manager 走完 EULA + etxadmin 设置密码的初次登录流程,否则会”已初始化”,无法 cluster join
  • 加入集群的 etxsvr 版本(包括 Service Pack 和 update 版本号)必须与集群创建者完全一致,版本不一致 join 请求会被拒绝并报错。
  • 集群成员之间的复制端口必须双向可通(默认 8447 用于 etxdb 复制,9000 用于 cluster 通信;以你环境实际配置为准)。
  • 集群成员名(-n name)在集群里必须唯一。

2.2 在第一台 etxsvr 上初始化集群

第一台 etxsvr 已经按单机方式部署完毕(/opt/etxsvr/etxsvr-<version>、走完 etxadmin 初始化、license 已加载、能正常起会话)。

1
2
cd /opt/etxsvr/etxsvr-12.5.4
bin/etxsvr cluster create -h 172.31.0.120 -p 8447 -n etxsvr-a

参数:

  • -h IP_address:本机用于远程复制的 IP(建议是内网/复制专网 IP,不要用外部反代 IP)。
  • -p port:本机用于复制的 TCP 监听端口。
  • -n name:本台 server 在集群中的唯一名(之后会出现在 Cluster 页面和 Preferred master 下拉)。

省略参数时命令会进入交互,给默认值回车即可。该命令需要 server 处于运行状态,本质是把一台单机 server 转换成集群中的第一个成员。

执行后用:

1
bin/etxsvr cluster status

确认状态健康(只有自己一个成员)。

2.3 在第二台 / 第三台 etxsvr 上 join

第二台机器准备工作:

  1. 同样在 /opt/etxsvr/etxsvr-<version> 安装相同版本(含同样的 patch level)。
  2. 不要走 EULA + etxadmin 设密码的初次启动流程。直接以应用方式短暂启动一次,使其生成基本目录结构即可;如果不确定,参考 HA Configuration Guide 中”join 之前 server 状态”那一节。
  3. 确认本机到第一台的 8443 / 8447 / 9000(取决于实际配置)双向可达。

执行 join:

1
2
3
4
5
6
7
cd /opt/etxsvr/etxsvr-12.5.4
bin/etxsvr cluster join \
  -h 172.31.0.121 \
  -p 8447 \
  -n etxsvr-b \
  -r https://rd-172-31-0-120:8443 \
  -a '<etxadmin-password-on-first-server>'

参数:

  • -r remote_URL:已存在的集群中任意一台 server 的 base URL(带 https + 端口)。
  • -a remote_pass:那台远程 server 上 etxadmin 的密码(join 完成后即可丢弃,不会长期保留)。
  • 其他 -h / -p / -n 同上,本机视角。

完成后回到第一台执行 bin/etxsvr cluster status,应该能看到 2 个成员,并且 Replication status 为 ready,Resync dataReplication backlog 在追平后变为 0。

第三台、第四台重复 2.3 的步骤,每台分配不同的 -n name

2.4 加入集群之后

  • 在 Server Manager Site Settings → Cluster → Preferred master 里选择首选 master(一般是网络条件、硬件配置最稳的那台)。
  • 用户访问入口建议配置一台 L4 / L7 LB(HAProxy / F5 / Nginx stream),上游是集群里的 etxsvr,做健康检查与会话亲和(ETX 自身用 token + REST 鉴权,可以在不同 etxsvr 间无缝切换)。

2.5 IP 还是 域名 / HA VIP?

这是 ETX HA 部署里最容易踩偏的一处。简化为一张表(文档原文出处见参考章节):

用途 参数 / 字段 文档定义 该填什么
cluster create -h 本机复制地址 IP_address “IP Address of this Exceed TurboX Server for remote connections” 真实 IP不要填 VIP/域名
cluster join -h 本机复制地址 IP_address 同上 真实 IP
cluster join -r 引导握手 URL remote_URL “Base URL of the existing remote Exceed TurboX Server in the Exceed TurboX Server cluster. Example: https://etx.server.name:8443 任意一台已加入成员的 Base URL,IP/FQDN 均可,别填 VIP
Server Manager 注册 etxcn 时 Address Address “The host name or IP address of the node” etxcn 自己的 host/IP,与 VIP 无关
用户访问 Dashboard / REST API 入口 (部署侧决定) 文档未强制 域名 → LB/VIP → 集群所有 etxsvr

三句话原因:

  1. 集群内部复制是 mesh 直连,必须用每个成员的真实 IP。 用 VIP 会让所有成员的复制流量都打到同一个真后端,复制拓扑塌成一对一,HA 自动失效。文档把 -h 的形参直接命名为 IP_address 就是这个意思。
  2. cluster join -r 只在握手那一次用,填 IP 或 FQDN 都可以(文档例子用 FQDN);但别填 VIP——VIP 后端可能恰好把请求转到了正在 join 的这台机器上,握手成环或失败。填一台明确已存在的集群成员地址最稳。
  3. 域名 / HA VIP 只用在面向用户的入口(Dashboard / REST API)。 因为只有这一层会因为某台 etxsvr 进维护模式而需要”换台机器”;集群内部互连与 etxcn 注册都不经过这一层。

3. 把 etxcn 接入集群(”etxcn join”)

ETX 的 etxcn 不是集群成员,而是被集群管理的资源——它没有 “join cluster” 这种命令;接入流程就是在 Server Manager 上注册一次,注册记录会通过 etxdb 复制扩散到集群所有 etxsvr。

3.1 在 etxcn 机器上完成节点安装

Exceed TurboX Installation and Configuration Guide 的 “Installing Exceed TurboX Connection Nodes” 章节执行:

  • Linux/UNIX:跑 shell 安装脚本;
  • Windows:跑 connection node installer。

安装脚本结尾会打印 etxcn 自身的 host/IP 与监听端口(默认 5510)——这就是要拿去 Server Manager 注册的两项信息。Windows installer 最后一屏也是同样的内容。

3.2 在 Server Manager 上注册节点

打开集群中任意一台健康 etxsvr 的 Server Manager(建议走 LB 域名访问;走单台 IP 也不影响最终一致性,因为注册结果会复制):

  1. 进入 Nodes and Sessions → Nodes
  2. 点右上角 Register node
  3. Registration 页填入:
    • Address = etxcn 的 host name 或 IP
    • Port = etxcn 的端口(默认 5510)
  4. Register

注册成功后:

  • 节点出现在 Nodes 列表里;
  • 自动弹出 node properties 对话框的 Settings 页,可以马上配置该节点(资源上限、可见用户组、虚拟显卡组等);
  • 该记录通过 etxdb 复制同步到集群里其他所有 etxsvr,无需在每台 etxsvr 上重复注册。

3.3 验证集群所有 etxsvr 都能管理这台 etxcn

  • 在不同 etxsvr 的 Server Manager 上分别打开 Nodes 页,应该都能看到刚注册的 etxcn,状态相同;
  • 在 etxcn 机器上:
1
2
# 看 5510 上是否有来自集群多台 etxsvr 的连接
ss -tnp | grep ':5510 ' | grep ESTAB

每台健康 etxsvr 通常都会有一条到 etxcn:5510 的 ESTABLISHED 连接(具体连接条数与版本有关,但至少要看到不仅仅来自第一台 etxsvr 的连接)。如果只看到来自一台 etxsvr 的连接、其他成员都没连过来,那不是 etxcn 这边的配置问题(etxcn 是被动监听),而是其它 etxsvr 还没把节点记录复制完,或者它们之间的网络/端口策略限制了那几台 etxsvr 主动出站连接 5510——这是排查重点。

3.4 关于 “etxcn 装机时填的 etxsvr IP” 这件事

如题:它不影响后续 HA 滚动升级

依据已在第 0 节给出:ETX 控制平面是单向 etxsvr → etxcn(5510);注册信息存在 etxdb 里、由集群复制扩散;etxcn 本身不需要”知道”任何一台具体 etxsvr 作为长期控制通道。安装脚本里若问到过某台 etxsvr 的 IP,其作用至多是”安装完成时自动调用 Server Manager 完成 3.2 节那次注册”,相当于一种便捷脚本,注册一旦写入 etxdb 就被复制走,那个 IP 不再被持续使用。

如果你不确信,做一次小范围验证:

  1. 在 lab 里把那台第一次填过 IP 的 etxsvr 停掉(不维护模式,直接 bin/etxsvr stop);
  2. 在 etxcn 上看 ss -tnp | grep ':5510',应能继续看到来自其他 etxsvr 的 ESTABLISHED;
  3. 在其他健康 etxsvr 的 Server Manager 上对该 etxcn 做一次”Reassign session” 或 “Shadow”,能否正常发起;
  4. 在该 etxcn 上起一个新 session,能否被调度成功。

这四步全部通过,就证明 etxcn 与第一台 etxsvr 之间没有不可替代的依赖。


4. 滚动升级 etxsvr:不打断 etxcn 已有 session

核心机制:etxsvr 停机 ≠ etxcn 停机。 Maintenance mode 只是禁止新登录,正在跑的 active session 和 suspended session 全部不受影响;甚至 etxsvr 进程整体停掉,etxcn 上的 X server / Xvnc / RDP 进程也会继续跑。用户感知到的”掉 session”通常是 etxcn 端进程被杀,而不是 etxsvr 端。

4.1 升级前置确认

  • 准备好补丁包 etx-svr-<version>-<patch>.tgz 或新版安装包,所有 etxsvr 升级到同一个版本(同 Service Pack 同 update 号)。版本不同 → cluster 复制会拒绝。
  • 通知用户在升级窗口内不要发起新 session,但已有 session 可以继续使用。
  • 在 Server Manager 里截图保存 Cluster 页面当前状态(Version、Replication status、Master)作为 baseline。
  • 在 LB 上准备好把目标 etxsvr 摘掉的能力(健康检查 fail,或手动 drain)。

4.2 滚动升级单台 etxsvr 的标准动作

假设集群中有 3 台:etxsvr-a(master, 172.31.0.120)、etxsvr-b(172.31.0.121)、etxsvr-c(172.31.0.122)。从非 master 开始升级。

Step 1:把目标 etxsvr 从 LB 上摘掉

在前置 LB 上把 etxsvr-b 的 backend 状态置为 drain / down。Dashboard 上将不会再有新登录走到这台 server。

Step 2:切到 Maintenance mode(可选但强烈推荐)

登录 etxsvr-b 的 Server Manager(直接访问该节点的 URL,不要经过 LB),Configuration → General → Switch to maintenance mode

进入维护模式后:

  • 你自己的 Server Manager 会话保持。
  • 任何尝试登录 etxsvr-b 的用户会看到维护提示页面并被引导到 sign-in。
  • 已签入的用户被签出(这是为了禁止他们再通过这台 etxsvr 触发操作),但他们的 active / suspended session 不受影响,菜单里的 Suspend / Disconnect / Terminate 控制仍可使用。

如果该节点上当前签入用户很多,需要给个缓冲时间窗口,让他们的 Dashboard 重连到其他 etxsvr。

Step 3:先 resync 再停服

集群里 etxsvr-b 自己尚未发到其他成员的 recovery journal 数据要先推完,避免停机时丢同步进度。

1
2
3
4
cd /opt/etxsvr/etxsvr-12.5.4

# 把本机产生但还没复制出去的变更推到集群
bin/etxsvr cluster resync

文档原话:”Call this command only against a stopped server” 与 “We recommend that you call this command before taking the Server down for maintenance, to ensure that any local changes are correctly synchronized to the cluster”。两句之间存在矛盾。实际操作时按”先 resync,再 stop”的顺序最稳,并在 stop 之后再次确认 cluster status 中本节点不再有 backlog 即可;如果 resync 命令在 running 状态被拒绝,按文档先 stop 再 resync。

然后停止本机服务:

1
2
3
4
5
6
7
8
9
10
# 若以服务方式运行
systemctl stop otetxsvr
# 或多实例
systemctl stop otetxsvr_2

# 若以应用方式运行
bin/etxsvr stop

# 确认进程已退
bin/etxsvr status

关键: 这一步只停 etxsvr 进程,不动 etxcn。etxsvr-b 上不应该跑 etxcn;etxcn 一般是另外的 Connection Node 机器。即便 etxsvr-b 与 etxcn 是同一台物理机,也只要不去 systemctl stop etxcn 相关 service,session 就不掉。

Step 4:应用 patch / 升级二进制

按补丁形态选择:

Patch 形式(小版本/热修复):

1
2
3
4
5
6
7
8
9
10
11
cd /opt/etxsvr/etxsvr-12.5.4
# 把补丁包拷到 server 目录
cp /share/patches/etx-svr-12.5.4-p3.tgz .

# 解压(支持多个补丁同时解压)
sh etx-svr-12.5.4-p3.tgz --tar xpf

# 应用,可用 -c 指定子组件
bin/etxsvr patch apply
# 或仅应用某些组件
bin/etxsvr patch apply -c webui,etxdb

清理 staging(确认应用成功后):

1
2
3
4
# 只清掉状态为 unavailable 的文件
bin/etxsvr patch -safe
# 或者全部清掉
bin/etxsvr patch

Runtime 形式(Xvnc / Xserver 版本升级):

1
2
3
4
5
6
7
8
# 添加新 runtime
bin/etxsvr runtime add etx-runtime-12.5.4-rtm.tgz

# 设为默认
bin/etxsvr runtime setdefault 12.5.4-rtm

# 老 runtime 等所有引用它的 session 退出后再删
bin/etxsvr runtime remove 12.5.3-rtm

Runtime 删除要小心:如果 etxcn 上还有 session 使用旧 runtime(X server 进程),删除 runtime 不会立刻杀 session,但相关日志/调试链路会出问题。建议先 setdefault 到新版,旧 runtime 等 session 自然退出/被用户清理后再 remove。

全量大版本升级: 解压新版 tar 到 /opt/etxsvr/etxsvr-<newversion>,迁移 license、settings(用 bin/etxsvr backup 在老版本生成备份,新版用 bin/etxsvr restore),再走 cluster create / join 流程。这种情况通常不走滚动升级,而是借助 cluster 复制做”新建一个对等版本集群再切换”的方案,超出本文范围。

Step 5:启动并验证

1
2
3
4
5
6
7
8
9
10
# 启动
systemctl start otetxsvr
# 或
bin/etxsvr start

# 确认进程
bin/etxsvr status

# 确认集群
bin/etxsvr cluster status

期望看到的:

  • etxsvr-bVersion 列变成新版本号;
  • Link status 为 connected;
  • Replication status 为 ready;
  • Resync data / Replication backlog 在几十秒内追平为 0。

在 Server Manager 上把 etxsvr-b 从 Maintenance mode 切回 Live mode(Switch to live mode → Yes)。

在 LB 上把 etxsvr-b 的 backend 状态从 drain 改回 up,等健康检查通过。

Step 6:观察 + 移动到下一台

观察 5~15 分钟,看:

  • Dashboard 上是否能正常登录这台 etxsvr-b
  • 新建一个测试 profile 起 session,确认 etxcn 调度正常;
  • Site Settings → Cluster → Servers 上没有红色行;
  • bin/etxsvr cluster status 没有 backlog。

确认稳定后,对 etxsvr-c 重复 Step 1~6。

Step 7:最后升级 master

在升级 master(etxsvr-a)之前,把它先 手动切换 master 给已经升完级的某台:

Site Settings → Cluster → Preferred master 改为 etxsvr-b → Apply(60 秒生效)。

确认 master 已经切换后(Master 列的 Yes 跑到 etxsvr-b 那一行),再对 etxsvr-a 走一遍 Step 1~6。

升级全部结束后,如果你原本就希望 master 留在 etxsvr-a,再把 Preferred master 改回来。


5. 操作过程中常见坑

  1. 版本不一致拒绝 join / 拒绝复制。常发生在多人维护、各自打了不同 hotfix。bin/etxsvr cluster statusVersion 列要严格一致到 update 号。
  2. 资源 backlog 一直涨。一般是复制端口不通或带宽不够,先用 ss -tnp 看端口、用 Viewing cluster member detailsPending backlog / Write backlog / Flush backlog / Replay backlog 四个值卡在哪一段,再判断是网络还是磁盘问题。
  3. 维护模式没切回 Live。升完忘了点 Switch to live mode,导致整台 etxsvr 一直不收新登录,但 LB 健康检查可能仍然返回 200(取决于探测端点)。建议把 maintenance state 也纳入健康检查。
  4. 同时停了两台 etxsvr。在 3 台集群中同时停 2 台,剩下的那台虽然能继续服务,但失去 quorum 容错,复制日志会大量堆积,恢复时风险陡增。严格遵守”一台一台来”
  5. 试图给 License Server 做 HA。License Server 本身不支持 HA cluster;高可用要通过 “多个 License 文件 + 多个 License Server” 或外部 license 高可用方案解决。
  6. 把 etxcn 也跟着重启。除非真的要升级 etxcn 上的 X server / VirtualGL / 驱动,否则升 etxsvr 期间完全不需要碰 etxcn。一旦 etxcn 上的 Xvnc/Xorg 进程被杀,对应的 EDA tool 进程会瞬间收到 X IO error,长跑仿真 / DRC / LVS 就会前功尽弃。
  7. bin/etxsvr cluster resync 用错时机。文档自相矛盾时,以”先推完再停”的实际行为更稳;停服后如果 Resync data 仍非 0,再 resync 一次让本机日志读完。
  8. 以为”etxcn 装机时填的 etxsvr IP”在 HA 下是个长期依赖。这是常见误解。根据 Server Manager Administration GuideRegistering connection nodes,etxcn 是被动监听 5510 的资源、由集群侧 etxdb 复制后的注册记录驱动 etxsvr 主动连入。装机时若问到过 etxsvr IP,那只是用来”装完顺手做一次 3.2 节那次注册”,注册一旦写入 etxdb 就被复制走,那个 IP 在后续运维里不再起作用,与 HA 滚动升级无关。
  9. 把 HA VIP / 域名填进 cluster create -hcluster join -h。文档明确该参数是 IP_address,意为”本机用于复制的真实 IP”。误填 VIP 会让集群所有成员往同一个真后端写复制,HA 自动失效。VIP / 域名只用在用户访问 Dashboard / REST API 的入口层。

6. 升级流程速查(Cheat Sheet)

1
2
3
4
5
6
7
8
9
10
11
12
对每一台非 master etxsvr:
  LB drain  →  Maintenance mode  →  cluster resync
  →  systemctl stop otetxsvr
  →  patch apply / runtime add+setdefault
  →  systemctl start otetxsvr
  →  cluster status 确认 Replication ready + Version 已更新
  →  Switch to live mode  →  LB up  →  观察 10 min

最后一步:
  Preferred master 切到已升级节点
  →  对原 master 走一遍上面的流程
  →  Preferred master 再切回(可选)

只要这套流程严格执行,每一台 etxsvr 停机的时间窗口里,所有 etxcn 上的 active / suspended session 都不会丢,用户感受到的只是 “Dashboard 短暂跳转到另一台 server”。


参考