升级 Tableau Server，从 2023.3 跳到 2025.3.7。单节点一切正常，但一把第二个节点加进来，Prep Conductor（Flow Processor）就罢工了。
这不是第一次遇到。之前从 2023.1 升级到 2024.2 时，同样的问题就出现过，当时没解决，只能回退。这次硬着头皮排查到底。
环境：Windows Server 2019，双节点（Node1: 10.100.50.82，Node2: 10.100.50.84）。原版本 Tableau Server 2023.3，目标版本 2025.3.7。
在单节点部署中，Flow Processor 在检查许可证时使用的是 localhost；而在多节点部署中，则会使用主机名解析（name resolution）。
症状：一切正常，除了 Prep Conductor
升级完成后，查看 TSM 状态页。Gateway、Repository、VizQL Server、Backgrounder——全部绿灯。唯独 Prep Conductor 状态停在 "Degraded" 或直接报错。
查看 Flow Processor 日志（tabminerva），关键报错如下：
ERROR com.tableau.minerva.lifecycle.MinervaProcess - The port file is empty.
ERROR com.tableau.minerva.lifecycle.MinervaProcess - The tabminerva process failed to start.
Refer to the tabminerva log for details.Apache 代理日志中还有一条连接拒绝错误：
[proxy:error] AH00957: http: attempt to connect to 10.100.50.82:8465 (tableaus1:8465) failed
(OS 10061) 由于目标计算机积极拒绝，无法连接。看到 "port file is empty" 和 "connection refused" 两条线索，第一反应是端口配置问题。但真正的原因远比这个隐蔽。
排查过程：绕了一大圈
第一轮：怀疑安装问题
既然升级不行，那就彻底清理。执行 obliterate 完全移除 Tableau Server，重启服务器，重新安装 2025.3.7。
单节点恢复后，Prep Conductor 正常启动。信心大增，加入 Node2——问题完美复现。
连全新安装都不行，说明不是升级残留的问题。
第二轮：怀疑已知 Bug
Tableau 技术支持（工程师 Daphne）介入后，发现日志表现与一个已知 Bug 高度吻合。
这个 Bug 的核心描述是：多节点部署中，Prep Conductor 在启动阶段进行许可证检查时，如果主机名解析耗时过长，会导致检查超时，进程启动失败。
技术支持给出了一个关键洞察：
这个区别解释了为什么单节点正常、多节点失败——两种模式下的通信机制根本不同。
官方建议降级到 2025.1.12（已修复该 Bug 的版本）或尝试 workaround。但降级不是好选项，已经花了两天折腾升级。而且——全新安装的 2025.3.7 也有同样问题，说明要么 Bug 修复不完全，要么根本是另一个问题。
第三轮：DNS 露出马脚
技术支持持续追问 DNS 配置。一查，果然有问题：
- 两台服务器都在 10.100.50.x 网段，默认网关 10.100.50.254
- DNS 服务器配置的是 192.168.1.3——一个完全不同的子网
- 两个节点无法通过主机名互相解析
这就是症结所在：Tableau Server 的 Prep Conductor 在多节点模式下使用主机名（hostname）进行节点间通信和许可证检查，而不是 IP 地址。如果 DNS 无法将主机名解析为正确的 IP，进程之间的连接就会失败。
flowchart TD
A[Prep Conductor 无法启动] --> B{单节点正常?}
B -->|是| C[问题在节点间通信]
B -->|否| D[检查安装/端口配置]
C --> E{节点间能互相 ping 主机名?}
E -->|否| F[DNS/主机名解析问题]
E -->|是| G[检查 8465 端口连通性]
F --> H[修改 hosts 文件]
H --> I[添加 IP-主机名映射]
I --> J[重新调整拓扑]
J --> K[Prep Conductor 正常启动]
G --> L{端口可达?}
L -->|否| M[检查防火墙/port.yml]
L -->|是| N[联系 Tableau 技术支持]
style A fill:#fef2f2,stroke:#ef4444
style K fill:#f0fdf4,stroke:#22c55e
style H fill:#dbeafe,stroke:#2563eb
style F fill:#fef3c7,stroke:#f59e0b解决方案：两行 hosts 搞定
修改两台服务器的 hosts 文件（C:\Windows\System32\drivers\etc\hosts），添加以下内容：
10.100.50.82 ts1
10.100.50.84 ts2两台服务器都添加相同的内容——将对方节点的 IP 和主机名的映射写入本地 hosts。DNS 保持不变，依然是 192.168.1.3。
修改后不需要重启服务器，hosts 文件修改立即生效。重新加入 Node2，调整拓扑（topology），Prep Conductor 一次性成功启动。问题解决。
为什么官方 KB 没帮上忙？
Tableau 官方 KB 001497254 专门针对 Prep Conductor 状态变为 Unavailable 的场景，给出的 workaround 分为两步：
第一步，执行管理服务重启：tsm stop → stop-administrative-services → start-administrative-services → tsm start。本质上就是重启 Tableau Server 的管理服务栈。
第二步（多节点环境），通过 tsm topology set-node-role 将 flowprocessor 所在节点先改为 no-flows 卸载 flowprocessor，再加回 all-jobs 重新安装——相当于在拓扑层面重新部署 Prep Conductor 进程。
我按照这个 KB 完整操作了一遍——停止服务、重启管理栈、甚至通过 topology 调整卸载重装 flowprocessor。问题依然存在。
原因很简单：KB 的思路是「重启许可证检查流程」，但根因不在这里。真正的问题是 Prep Conductor 需要通过主机名连接到许可证服务，而 DNS 配置无法正确解析这些主机名。不解决主机名解析，重启多少次都没用——进程每次启动都走到同一个死胡同。
更值得关注的是，KB 全文没有提到 hosts 文件或主机名解析。技术支持在沟通中也主要引导 nslookup、ipconfig /all 等 DNS 层面排查，没有直接建议修改 hosts。对于很多企业内网环境来说，DNS 由网络团队管理，改动流程可能很长；而 hosts 文件是一个立即可行、风险极低的方案——但这个选项在官方文档中完全缺失。
给你的排查清单
如果你在升级 Tableau Server 到 2024.2 或更高版本时，遇到多节点环境下 Prep Conductor 无法启动的问题，按以下顺序排查：
- 确认是单节点正常、多节点失败 — 先在单节点验证 Prep Conductor 是否能启动。如果能，问题大概率在节点间通信。
- 检查节点间主机名解析 — 在 Node1 上 ping Node2 的主机名，反之亦然。如果 ping 不通或解析到错误的 IP，问题就在这里。
- 检查 DNS 配置 — 执行 ipconfig /all 查看 DNS 服务器是否与当前网段匹配。如果 DNS 在另一个子网，大概率无法正确解析内网主机名。
- 修改 hosts 文件（立即可行的 fix） — 在两个节点的 hosts 文件中添加对方的 IP-主机名映射。不需要重启服务器，修改立即生效。
- 检查 Flow Processor 端口 — 运行 tsm topology list-ports 确认 flowprocessor 的端口配置正确，与 port.yml 中的设置一致。
- 最后才考虑 obliterate 重装 — 如果以上都不行，再走彻底清理重装的路线。
结语
这个问题本质上是一个网络配置问题，而非 Tableau Server 的软件缺陷。但Tableau Server 从 2024.2 开始，Prep Conductor 在多节点模式下改用主机名通信（而非 IP），这个行为变化并没有在升级文档中充分说明。
如果你的企业内网环境 DNS 配置不够完善——比如 DNS 服务器在不同子网，或者内网主机名没有注册到 DNS——那么升级 Tableau Server 时，你很可能会撞上这堵墙。
好消息是，修复极其简单：两行 hosts 文件。坏消息是，没有人告诉你。
希望这篇文章能帮你省下两天通宵排查的时间。
No comments yet