tier0-enterprise 三节点部署方案V2
文档状态：当前实现方案 适用范围：Enterprise Fleet Center 中心节点 部署形态：六台业务机器 + 一台独立部署器控制机 + 四个同网段 VIP 方案定位：单活主备容灾，不是跨机房、共识选主或零数据丢失的严格高可用集群
1. 方案目标
Section titled “1. 方案目标”本方案用于在离线或私有化环境中部署一套逻辑上的 Tier0 Enterprise Fleet Center。六台机器 共同承担业务、中间件和代理职责，用户及 Enterprise 内部服务始终访问固定 VIP；单台机器 或单个代理故障后，由 Keepalived、HAProxy、repmgr、RustFS 和 Fleet Agent 分别完成对应 层级的接管。
方案目标如下：
-
Fleet Center 中心节点发生单机故障后，业务入口能够漂移到健康 Standby；
-
PostgreSQL、Redis、RustFS 均提供固定访问地址，后端节点切换不要求修改 Enterprise
.env； -
App、Flow、Marimo、License 等本地业务文件能够由 Active 增量同步到 Standby；
-
一份 Cluster License 对应一个逻辑安装实例，切换 Enterprise 节点后不重复激活；
-
通过独立部署器完成六台机器的初始化、角色编排、部署、监控和故障验证；
-
明确数据保护边界，避免把 VIP 漂移、文件同步或双实例误认为完整的数据高可用。
本方案只用于 Fleet Center。Branch Enterprise 仍按普通单机方式安装，不参与六机主备。
2. 总体拓扑
Section titled “2. 总体拓扑”
核心请求链路为：
用户/现场系统 ↓业务 VIP :8088 ↓当前 Active Enterprise（D / E / F） ├─ PostgreSQL VIP :5432 → D/E HAProxy → A/B 当前可写 Primary ├─ Redis VIP :6379 → C 或 F 独立 Redis └─ RustFS VIP :19000 → A/B HAProxy → C/D/E/F RustFS 集群四个 VIP 是业务配置中的固定入口。Enterprise 切换或中间件后端角色变化后，客户端和 Enterprise 均不修改连接地址。
3. 规划 IP
Section titled “3. 规划 IP”以下地址只用于展示规划格式，实施时必须替换为现场同一 IPv4 子网中的实际地址。四个 VIP 必须未被 DHCP、静态主机或其他 VRRP 实例占用。
| 类型 | 名称 | 示例 IP | 说明 |
|---|---|---|---|
| 控制面 | deployer-controller | 10.60.10.20 |
独立部署器，不计入六台业务机器 |
| 业务节点 | ent-ha-01 / A | 10.60.10.11 |
PostgreSQL Primary 等职责 |
| 业务节点 | ent-ha-02 / B | 10.60.10.12 |
PostgreSQL Standby 等职责 |
| 业务节点 | ent-ha-03 / C | 10.60.10.13 |
Witness、Redis-1、RustFS-1 |
| 业务节点 | ent-ha-04 / D | 10.60.10.14 |
Enterprise 初始 Active 等职责 |
| 业务节点 | ent-ha-05 / E | 10.60.10.15 |
Enterprise Standby 等职责 |
| 业务节点 | ent-ha-06 / F | 10.60.10.16 |
Enterprise Standby 等职责 |
| 逻辑入口 | Business VIP | 10.60.10.101 |
Enterprise 统一入口，默认 8088 |
| 逻辑入口 | PostgreSQL VIP | 10.60.10.102 |
数据库统一入口，默认 5432 |
| 逻辑入口 | Redis VIP | 10.60.10.103 |
Redis 统一入口，默认 6379 |
| 逻辑入口 | RustFS VIP | 10.60.10.104 |
S3 统一入口，默认 19000 |
实施前还需要确认：业务网卡名称、IPv4 前缀长度、网关、DNS、NTP、主机名、SSH 用户、 磁盘挂载点和防火墙放行范围。VIP、节点 IP 和网卡不能靠脚本猜测后直接用于生产。
4. 六台机器职责
Section titled “4. 六台机器职责”
| 机器 | 默认部署内容 | 关键职责 |
|---|---|---|
| A | PostgreSQL Primary、RustFS HAProxy、Keepalived | 初始数据库主库；RustFS 代理候选一 |
| B | PostgreSQL Standby、RustFS HAProxy、Keepalived | 数据库流复制备库；RustFS 代理候选二 |
| C | PostgreSQL Witness、Redis-1、RustFS-1 | 数据库仲裁/状态记录；Redis 与 RustFS 数据节点 |
| D | PG HAProxy、Keepalived、RustFS-2、Enterprise、Fleet Agent、rsync | 初始业务 Active；PostgreSQL 代理候选一 |
| E | PG HAProxy、Keepalived、RustFS-3、Enterprise、Fleet Agent、rsync | 业务 Standby；PostgreSQL 代理候选二 |
| F | Redis-2、RustFS-4、Enterprise、Fleet Agent、rsync | 业务 Standby；第二 Redis 实例 |
该分配面向单机故障和六机资源均衡。部署器按环境内机器名称/IP 的自然顺序映射 A-F 并 默认勾选角色，提交前仍必须结合现场磁盘和故障域人工复核。
4.1 机器配置清单
Section titled “4.1 机器配置清单”**扩展能力说明：**当前 Enterprise 业务层采用单活主备模式，同一时刻只有业务 VIP 所在节点承载业务请求。当前只支持通过提升单个业务节点的 CPU、内存和磁盘规格进行纵向扩容，不支持通过增加 Enterprise 节点实现多节点负载均衡，也不应按节点数量估算并发能力的线性提升。
六台机器按以下配置准备：A、B 两台 PostgreSQL 数据库节点各配置 1T，C、D、E、F 四台中间件/业务节点各配置 500G。
| 机器 | 节点类型 | vCPU | 内存 | 基础存储 | 系统盘和数据盘建议 |
|---|---|---|---|---|---|
| A | PostgreSQL Primary 节点 | 8C | 16G | 1T | / 建议 80G；其余空间用于 PostgreSQL 数据、WAL 和备份暂存 |
| B | PostgreSQL Standby 节点 | 8C | 16G | 1T | / 建议 80G；其余空间用于 PostgreSQL 数据、WAL 和备份暂存 |
| C | Witness / 中间件节点 | 4C | 8G | 500G | 系统、Redis 和 RustFS 数据按固定挂载点分配 |
| D | Enterprise 初始 Active 业务节点 | 8C | 32G | 500G | 系统、容器、Enterprise 本地同步目录和 RustFS 数据按固定挂载点分配 |
| E | Enterprise Standby 业务节点 | 8C | 32G | 500G | 系统、容器、Enterprise 本地同步目录和 RustFS 数据按固定挂载点分配 |
| F | Enterprise Standby 业务节点 | 8C | 32G | 500G | 系统、容器、Enterprise 本地同步目录和 RustFS 数据按固定挂载点分配 |
基础机器资源汇总如下：
| 类别 | 数量 | 单台规格 | 小计 vCPU | 小计内存 | 小计基础存储 |
|---|---|---|---|---|---|
| PostgreSQL 数据库节点 | 2 | 8C / 16G / 1T |
16C | 32G | 2T |
| Witness / 中间件节点 | 1 | 4C / 8G / 500G |
4C | 8G | 500G |
| Enterprise 业务节点 | 3 | 8C / 32G / 500G |
24C | 96G | 1.5T |
| 合计 | 6 | - | 44C | 136G | 4T |
A、B 的 16G 内存用于 PostgreSQL/TimescaleDB/pgvector 的缓存和查询，是当前规模的生产基线；数据库量、时序查询或向量检索负载明显增加时再扩到 32G。C 同时承载 Witness、Redis 和 RustFS，因此配置 4C / 8G，不再按纯 Witness 的轻量规格准备。D、E、F 保持 8C / 32G 作为 Enterprise 生产基线，实际并发或 App 负载超出基线时再通过压测扩容。
C、D、E、F 组成 RustFS 四节点集群，四台机器均配置 500G。实施时仍需根据文件容量、增长率、保留周期和实际纠删码要求，为系统、Enterprise 本地文件与 RustFS 数据设置固定挂载点和容量预留，并在部署前验证容量、inode、吞吐和重启后自动挂载。
5. 配置汇总
Section titled “5. 配置汇总”5.1 Enterprise 统一连接配置
Section titled “5.1 Enterprise 统一连接配置”D、E、F 的 Enterprise 配置保持一致：
| 依赖 | 配置原则 |
|---|---|
| PostgreSQL | 连接 PostgreSQL VIP，不写 A/B 节点 IP |
| Redis | 连接 Redis VIP，不写 C/F 节点 IP |
| 文件存储 | FILESTORE_DRIVER=s3，S3 Endpoint 指向 RustFS VIP |
| Fleet 身份 | 三台共享一个逻辑 installationId，各自使用独立 memberId |
| Fleet Agent | 每套 Enterprise 对应本机一个进程级 Fleet Agent |
| License | 通过业务 VIP 激活一次，Bundle 纳入 HA fileset 同步 |
installationId 和 memberId 由安装流程生成和持久化，普通实施人员不应手工编造或在
三台机器间复制 memberId。
5.2 VIP 与候选节点
Section titled “5.2 VIP 与候选节点”| VIP | 候选节点 | 健康依据 | 接管结果 |
|---|---|---|---|
| 业务 VIP | D、E、F | Fleet Agent readiness、业务容器状态、同步 generation | 仅 Owner 启动 Enterprise HA 业务组 |
| PostgreSQL VIP | D、E | HAProxy/Keepalived 状态，HAProxy 只路由可写 Primary | Enterprise 仍使用原 DB 地址 |
| Redis VIP | C、F | Redis PING 和本机服务状态 |
切换到另一独立实例，缓存/会话可能丢失 |
| RustFS VIP | A、B | HAProxy 和 RustFS 后端健康 | 代理入口漂移，S3 地址不变 |
6. 组件部署设计
Section titled “6. 组件部署设计”6.1 Enterprise、Fleet Agent 与业务 VIP
Section titled “6.1 Enterprise、Fleet Agent 与业务 VIP”-
D、E、F 安装同一版本的完整 Enterprise 离线 ZIP；
-
Fleet Agent 是宿主机进程级服务，不是业务容器；
-
Keepalived 管理业务 VIP，调用 Fleet Agent 的 readiness 接口判断本机是否可以持有 VIP；
-
只有业务 VIP Owner 运行业务组，另外两台保持 Standby；
-
Owner 丢失 VIP 后必须停止业务组，恢复节点只能先以 Standby 加入；
-
EMQX 随业务组单活运行，不允许绕过 Agent 单独重启或在三台机器上组成另一套选主逻辑。
6.2 PostgreSQL 主备、Witness 与统一入口
Section titled “6.2 PostgreSQL 主备、Witness 与统一入口”-
A 初始为 Primary，B 为 Streaming Standby，C 为 repmgr Witness；
-
Witness 记录集群状态并参与故障判断，不保存完整业务数据，也不承载业务读写；
-
主库故障时，由 repmgr 流程将健康 Standby 提升为新 Primary；
-
D/E HAProxy 根据数据库实际角色，仅把
5432流量发送到当前可写 Primary； -
PostgreSQL VIP 在 D/E 两个代理间漂移，代理故障与数据库主备切换相互解耦；
-
验收必须同时证明“唯一可写 Primary”和“Standby 恢复 streaming”。
Witness 位于只读备库之外，因此不受 Standby 不可写的限制；它参与的是集群观察与仲裁， 不是由 Fleet Agent 向备库写入一套额外的 lease/epoch。
6.3 Redis 双独立实例
Section titled “6.3 Redis 双独立实例”-
C、F 各运行一个 Redis 单实例；
-
两个 Redis 不组成 Sentinel、Cluster 或主从复制；
-
Redis VIP 只提供连接入口切换；当前实例故障后，VIP 漂移到另一健康实例；
-
Redis 中只允许保存可丢失或可重建的数据。切换后缓存为空、用户重新登录属于当前设计边界；
-
如果未来 Redis 承载不可丢失状态，必须升级为复制/仲裁方案，不能继续沿用双独立实例假设。
6.4 RustFS 四节点集群
Section titled “6.4 RustFS 四节点集群”-
C、D、E、F 组成 RustFS 四节点分布式对象存储；
-
A、B 上的 HAProxy 代理全部健康 RustFS 后端；
-
RustFS VIP 在 A/B 之间漂移，Enterprise 始终通过该 VIP 使用 S3；
-
单个 RustFS 节点故障时由集群机制维持服务，单个代理故障时由 VIP 漂移恢复入口；
-
禁止通过 rsync、热拷贝或直接编辑 RustFS 挂载目录来“同步”对象数据；
-
RustFS 节点数量、磁盘数和纠删码可用边界以实际部署版本的集群检查结果为准。
6.5 App、Flow、Marimo 与 License 文件同步
Section titled “6.5 App、Flow、Marimo 与 License 文件同步”Fleet Agent 只同步不能直接放入 PostgreSQL/RustFS、但新 Active 又必须拥有的本地业务文件：
-
App 运行目录及
node_modules； -
Flow、Marimo、Notebook 等本地运行文件；
-
License Bundle；
-
当前实现明确登记的其他 HA fileset。
同步使用系统 rsync，通过部署器管理的业务节点专用 SSH 信任网，从 Active 增量发送到
两个 Standby。每次发布生成完整 generation/manifest，Standby 只有确认 generation 完整后
才具备接管资格。VIP 刚切换时，新 Active 不得用旧 generation 反向覆盖其他节点。
PostgreSQL 数据目录、Redis 数据目录和 RustFS 数据目录均不在该同步范围内。
7. 连接方式和网络基线
Section titled “7. 连接方式和网络基线”7.1 访问关系
Section titled “7.1 访问关系”| 来源 | 目标 | 用途 |
|---|---|---|
| 用户/现场系统 | 业务 VIP | Web/API 业务访问 |
| D/E/F Enterprise | PostgreSQL VIP | 业务数据库读写 |
| D/E/F Enterprise | Redis VIP | 缓存和会话 |
| D/E/F Enterprise | RustFS VIP | S3 对象读写 |
| 部署器控制机 | A-F | SSH、部署、状态采集和运维操作 |
| D/E/F | D/E/F | rsync/SSH 文件增量同步 |
| A/B/C | A/B/C | PostgreSQL 流复制、repmgr 和 Witness 通信 |
| RustFS 成员/代理 | C/D/E/F | RustFS 集群和 S3 后端通信 |
| 同一 VIP 候选节点 | 对应候选节点 | VRRP 通告与 VIP 漂移 |
7.2 端口和协议
Section titled “7.2 端口和协议”端口应按“来源→目标”最小化放行，禁止直接把全部管理端口暴露到用户网段。
| 端口/协议 | 建议放行范围 | 用途 |
|---|---|---|
22/TCP |
部署器→A-F；D/E/F 业务同步互访 | SSH、部署、rsync |
8088/TCP |
用户网段→业务 VIP | Enterprise 业务入口 |
5432/TCP |
D/E/F→PostgreSQL VIP；PG/代理内部互访 | PostgreSQL、流复制和代理 |
6379/TCP |
D/E/F→Redis VIP；健康检查节点→C/F | Redis 访问和健康检查 |
19000/TCP |
D/E/F→RustFS VIP | Enterprise S3 固定入口 |
9000/TCP |
A/B→C/D/E/F；RustFS 成员互访 | RustFS S3 后端/集群通信，按实际版本确认 |
9001/TCP |
运维受控网段→RustFS 管理入口 | RustFS 管理端，可选且不得暴露用户网 |
19731/TCP |
本机/Keepalived/受控运维网段 | Fleet Agent HTTP 健康与控制接口 |
18080/TCP |
运维网段→部署器控制机 | 部署器 HTTPS 页面 |
112/VRRP |
对应 VIP 候选节点互通 | Keepalived VIP 漂移，注意它是 IP 协议号而非 TCP/UDP 端口 |
1883/8883 |
现场设备网段→业务入口，按产品配置选择 | MQTT/MQTTS |
HAProxy 管理/统计端口、PostgreSQL 角色探测端口及 RustFS 内部端口应以最终部署器生成配置为准，并仅在集群内部按实际需要放行。
8. 故障切换和能力边界
Section titled “8. 故障切换和能力边界”| 故障场景 | 预期行为 | 数据影响/限制 |
|---|---|---|
| 当前 Enterprise Active 故障 | 业务 VIP 漂移；健康 Standby 校验 generation 后启动业务组 | 最近一次成功同步后的未同步文件可能丢失 |
| Fleet Agent 故障 | readiness 失败，旧业务组停止，业务 VIP 迁移 | 禁止手工绕过 Agent 启动容器 |
| PostgreSQL Primary 故障 | Standby 提升；HAProxy 自动路由新主；PG VIP 不变 | 切换窗口内连接短暂失败；需确认新备库恢复 |
| 一个 PG HAProxy 故障 | PostgreSQL VIP 漂移到另一个代理 | 数据库角色不因此改变 |
| 当前 Redis 故障 | Redis VIP 漂移到另一独立实例 | 缓存丢失、会话失效可发生 |
| 一个 RustFS 节点故障 | 其余集群节点继续服务 | 可容忍范围取决于实际纠删码和磁盘状态 |
| 一个 RustFS HAProxy 故障 | RustFS VIP 漂移到另一代理 | S3 地址不变，存量连接可能重连 |
| 部署器控制机故障 | 已运行数据面继续工作 | 暂时无法部署、集中监控和运维；控制机本身无自动主备 |
| 网络分区 | 当前方案不保证安全自动选主 | 可能出现双 VIP/双 Active，必须隔离故障侧并人工处理 |
| 任意两台同时故障 | 不作统一可用性承诺 | 结果取决于两台的角色组合，需逐场景验证 |
当前方案没有共识系统、租约、leaderEpoch 或 fencing，因此不宣称网络分区下的严格 HA。
它解决的是同一二层网络内的常见单机故障和人工恢复成本问题，产品口径应称为“主备容灾”。
9. 备份、监控和巡检
Section titled “9. 备份、监控和巡检”VIP 漂移和 rsync 都不能替代备份。生产环境至少需要：
-
PostgreSQL：独立定时备份、保留策略和恢复演练；
-
RustFS：按实际集群版本设计对象数据保护、磁盘监控和恢复流程；
-
Redis：确认其中仅保存可丢失数据；如果不是，先升级架构再上线；
-
Enterprise 本地 fileset：监控最近成功 generation、同步延迟、失败次数和 Standby 完整性；
-
部署器：备份数据卷、TLS/登录材料、SSH/Host Key 配置、完整交付包和校验文件；
-
通用指标：CPU、内存、磁盘容量、inode、磁盘 I/O、网卡错误、容器/服务重启次数；
-
HA 指标：四个 VIP Owner、唯一 Enterprise Active、唯一 PostgreSQL Primary、Standby streaming；
-
审计：记录部署、切换、重启、密码查看、License 操作和失败恢复。
日常操作和故障处理见 HA 日常运维手册（仓库 doc/ha/operations-guide.md）。
10. 上线前检查
Section titled “10. 上线前检查”| 检查项 | 通过标准 |
|---|---|
| 机器数量和角色 | 六台业务机器 A-F 与计划一致，部署器未混入业务节点 |
| SSH 和 sudo | 部署器可使用受控账号免交互访问 A-F，Host Key 已核验 |
| 网络与时间 | 六台同网段，四 VIP 未占用，网卡/前缀正确，时间偏差满足要求 |
| Docker/Compose | 六台初始化成功；无旧容器、端口、网络和数据目录冲突 |
| 磁盘 | PostgreSQL、RustFS、Enterprise fileset 使用计划挂载点，容量和 inode 正常 |
| PostgreSQL | 唯一 Primary、Standby streaming、Witness 在线、通过 PG VIP 可读写 |
| Redis | C/F 实例健康，通过 Redis VIP 可 PING，已接受切换后数据不复制的边界 |
| RustFS | 四节点均健康，通过 RustFS VIP 可完成对象写入、读取和删除 |
| Enterprise | D/E/F 版本一致，仅业务 VIP Owner 运行业务组 |
| Fleet Agent | 三台 Agent 在线，readiness、同步历史和 generation 状态可检查 |
| License | 业务 VIP 激活一次；切换后无需重新激活 |
| App 同步 | 导入包含 node_modules 的 App，同步完成后切换仍可运行 |
| 防火墙 | 只放行本方案所需来源、目标和协议 |
| 备份 | PostgreSQL、RustFS 和部署器备份方案已落地并至少完成一次恢复验证 |
11. 实施顺序
Section titled “11. 实施顺序”-
准备独立部署器控制机、六台业务机器、四个 VIP、网卡和磁盘规划；
-
校验完整交付包和 Enterprise 离线 ZIP 的 SHA256；
-
启动部署器，录入 SSH 凭据和六台机器并完成连通性检查；
-
初始化六台目标机的 Docker/Compose 和离线镜像环境；
-
创建“标准部署”，确认 A-F 角色分配和四个 VIP；
-
依次部署 PostgreSQL、Redis、RustFS、HAProxy 和 Keepalived；
-
建立 D/E/F 专用 rsync 账号和 SSH 信任网；
-
部署 D/E/F Enterprise 与 Fleet Agent，确认只有 D 初始 Active；
-
通过业务 VIP 完成一次 License 激活并等待 License 同步成功；
-
导入测试 App，验证 App、
node_modules、Flow/Marimo 和 License fileset 同步； -
分别执行 Enterprise、PostgreSQL、Redis、RustFS 单节点故障演练；
-
恢复节点并确认唯一 VIP Owner、唯一 Active、唯一 Primary 和完整同步状态；
-
完成备份恢复演练、运维交接和现场参数归档。
具体页面操作见 HA 部署安装流程（仓库 doc/ha/deployment-guide.md），AI 自动化验证用例见 HA 环境测试指南（仓库 doc/fleet/ha-test-guide.md）。
12. 验收标准
Section titled “12. 验收标准”12.1 功能验收
Section titled “12.1 功能验收”-
用户仅通过业务 VIP 登录和使用 Enterprise；
-
Enterprise 仅通过 PostgreSQL、Redis、RustFS VIP 访问中间件；
-
D/E/F 任意时刻只有一个 Active，失去业务 VIP 的节点不运行业务组；
-
PostgreSQL 任意时刻只有一个可写 Primary，Witness 不承载业务读写；
-
Redis 和 RustFS 后端切换后，Enterprise 无需修改
.env； -
License 只激活一次，业务节点切换后不进入激活页；
-
已完成 generation 的 App、Flow、Marimo 和 License 在新 Active 可用；
-
故障恢复节点以 Standby 加入，不用旧数据覆盖新 Active。
12.2 故障演练验收
Section titled “12.2 故障演练验收”-
Enterprise Active 单机故障后，业务 VIP 自动漂移并恢复访问；
-
PostgreSQL Primary 故障后，Standby 成为唯一新主，PG VIP 仍可读写；
-
当前 PG HAProxy 故障后，PG VIP 漂移，Enterprise 数据库连接恢复；
-
当前 Redis 实例故障后，Redis VIP 漂移，业务能够在允许的数据丢失边界内恢复；
-
一个 RustFS 节点或一个 RustFS HAProxy 故障后，通过 RustFS VIP 的对象读写恢复；
-
每次演练后均恢复稳定基线，不遗留双 VIP、双 Active 或双 Primary。
13. 风险和待现场确认项
Section titled “13. 风险和待现场确认项”-
四个 VIP 是否确实位于六台机器可共同持有的同一二层网络；
-
网络设备是否允许 VRRP/GARP，安全策略是否会阻断 VIP 漂移；
-
现场是否完全断网；当前部署器仍有 Harbor 可达性检查，需提前验证路由或代理；
-
PostgreSQL、RustFS 和 Enterprise fileset 的容量、增长率、RPO/RTO 目标；
-
Redis 中是否存在不能丢失的数据；若存在，当前双独立实例方案不满足要求；
-
App/Flow/Marimo 的最大文件量、单次变更量和可接受同步延迟；
-
是否存在跨网段、跨机房、网络分区或任意双机故障的强制可用性要求；
-
生产证书、域名、密码、License、SSH Key 和审计保管责任人；
-
部署器控制机的恢复方式、备份周期和替代运维通道。
上述任一项改变，都可能影响 VIP、角色分配、存储和故障边界，必须先更新方案再实施。
14. 结论
Section titled “14. 结论”当前方案以六台机器、四个固定 VIP 和单活 Enterprise 为核心，把业务入口、数据库入口、 缓存入口和对象存储入口分别解耦。它能够覆盖同网段内常见的单机故障，并显著减少切换后 修改连接配置、重新激活 License 和手工复制 App 文件的工作量。
同时必须接受三个边界：Redis 不复制数据、业务 fileset 为异步同步、网络分区没有共识仲裁。 因此本方案适合定义为 Fleet Center 六机单活主备容灾方案，不应对外承诺零中断、零数据 丢失或跨机房严格高可用。