杀掉任意一台机器跳板机服务照常运行JumpServer 高可用集群部署完整指南【免费下载链接】jumpserverJumpServer is an open-source Privileged Access Management (PAM) platform that provides DevOps and IT teams with on-demand and secure access to SSH, RDP, Kubernetes, Database and RemoteApp endpoints through a web browser.项目地址: https://gitcode.com/GitHub_Trending/ju/jumpserver凌晨两点机房一台物理机断电你的单节点 JumpServer 跟着一起倒下——所有 SSH、RDP 运维通道全断告警群里炸成一片。对一套覆盖 SSH、RDP、数据库等协议的门禁式特权访问管理PAM平台来说可用性就是生命线。这篇高可用部署指南会带你用两台应用节点加一套共享后端把 JumpServer 集群做到任何单点挂掉用户几乎无感并且每一步都给出可直接抄的命令。先看最终形态请求到底流向哪里先明确目标状态后面所有操作都是往这张蓝图上填东西。整套 JumpServer 集群按四层理解接入层两台 Nginx 组成负载均衡对负责分发请求和探测后端死活应用层至少两台 JumpServer 节点各自无状态地跑 Web 与终端服务可继续横向加机器数据层PostgreSQL 一主一从承担业务数据Redis 以 3 主 3 从的集群形态承担会话、缓存和 Celery 任务队列文件层一块 NFS 共享存储录像、回放和配置文件全部落在上面每一层的实例数和规格基线如下可按业务量上浮层级实例数规格底线职责负载均衡22C/4G流量分发、健康探测JumpServer 应用节点24C/8G控制台与终端会话PostgreSQL主从4C/16G业务数据持久化Redis 集群6 实例2C/4G会话、缓存、任务队列NFS 共享存储1100G录像回放与共享配置行动提示先画好这张拓扑并给每个角色分配真实 IP后面所有配置都对着这张表填。单点到底藏在哪四个位置逐个排查高可用的本质是消灭单点跳板机场景下单点恰好藏在四个地方一个都躲不掉应用节点本身——进程挂或机器挂登录页直接 502。解法是多节点后置于负载均衡之后。数据库——业务数据的唯一副本若在一台机器上它挂等于数据挂。解法是 PostgreSQL 主从复制主库故障时从库顶上。缓存与会话——用户登录态、任务队列都在 Redis 里。单实例 Redis 一挂全站登出、异步任务积压。解法是上 Redis 集群并开启 AOF 持久化。录像文件——这是最容易被忽略的一处会话录像必须跨节点可见否则用户在一台节点上发起的会话故障切换后回放会消失。解法就是 NFS/SMB 共享存储应用节点的录像目录统一挂到它上面。数据面初始化的关键动作只有两条主库用容器拉起DB_ENGINE: postgresql等字段可对照 config_example.yml再按官方文档把从库的流复制配上。docker run -d --name postgres-master \ -e POSTGRES_USERjumpserver -e POSTGRES_PASSWORD强密码 \ -e POSTGRES_DBjumpserver \ -v /data/postgres:/var/lib/postgresql/data \ -p 5432:5432 postgres:13行动提示执行psql -c SELECT pg_is_in_recovery();主库应返回f、从库返回t复制关系确认后再继续。让两台节点互为备份共享存储与多节点拉起两个 JumpServer 节点要做到任何一台倒下另一台无缝接手前提是它们看到的世界完全一样同一份数据库、同一个 Redis、同一份录像。所以共享存储必须先于应用就位# 存储节点导出目录 echo /data/share 192.168.1.0/24(rw,sync,no_root_squash) /etc/exports systemctl enable --now nfs-server # 每台应用节点挂载 mount -t nfs 192.168.1.5:/data/share /data/jumpserver/share应用节点用官方构建脚本出镜像utils/build_docker.sh 会自动拉源码构建也可从https://gitcode.com/GitHub_Trending/ju/jumpserver拉取然后两台机器跑同一个容器编排只是宿主机 IP 不同docker run -d --name jumpserver \ -v /data/jumpserver/share:/opt/jumpserver/share \ -v /data/jumpserver/config:/opt/jumpserver/config \ -e DB_HOST192.168.1.6 \ -e REDIS_HOST192.168.1.7:7000,192.168.1.7:7001 \ -p 8080:8080 jumpserver/jumpserver:当前版本Redis 集群的搭建就是把 6 个实例各起一个容器3 主 3 从cluster-enabled yesappendonly yes再用redis-cli --cluster create一次性建好环命令套路标准这里不再展开。行动提示在节点 A 往共享目录写一个测试文件立刻登节点 B 看能否读到——读不到就修 NFS不要带病上线。一台节点倒下时流量去哪儿负载均衡与健康探测流量层的核心是让 Nginx自动踢掉坏节点。被动探测靠两个参数主动重试靠一个转发策略参数取值起什么作用max_fails3累计失败几次才把节点判死fail_timeout30s判死后隔离多久期间流量全走健康节点proxy_next_upstreamerror/timeout/5xx请求已落到坏节点时自动改投下一台server指令下挂两台应用节点即可proxy_set_header把X-Real-IP、X-Forwarded-For透传给后端否则审计日志里全是 Nginx 的 IP。但TCP 通了不等于服务好了所以 JumpServer 自带/api/health/探针实现见 apps/jumpserver/api/health.py它每次请求都会真查一次数据库、真写读一次 Redis任何一项失败就返回非 200。把 Nginx 的健康检查指到这个端点节点活着但残废的情况也能被摘除。进程之外的 Celery 异步任务层同样要盯。utils/check_celery.sh 的逻辑只有一句检查/tmp/worker_heartbeat_celery心跳文件的修改时间超过 20 秒没更新就判定 worker 死亡。你可以把它挂进监控作为集群级兜底信号。行动提示curl -s http://任一节点:8080/api/health/确认db_status和redis_status都是true再让 Nginx 切流量。会话与数据凭什么不丢一致性是怎么保住的切换之后最怕两件事用户会话莫名其妙失效、数据库里出现两套账。分别对应三条保障登录态跨节点会话存 Redis 集群而非本地内存节点 A 登录的用户切到节点 B 继续操作不掉线业务数据单写入方所有节点只写 PostgreSQL 主库从库只读杜绝双写冲突异步任务不重复Celery 以 Redis 为 broker 做分布式调度任务天然去重多节点 worker 不会同跑一个任务实现位于 apps/ops/celery/配置文件单一事实源配置目录也挂在共享存储上避免改了一台忘了另一台的经典事故。行动提示在节点 A 上登录一次控制台然后curl走节点 B 的 API 验证会话仍然有效这一步过了跨节点切换才算真正成立。杀掉一台节点会发生什么三类演练缺一不可没做过故障演练的高可用叫纸面高可用。三类演练按顺序做全部通过才算交付1. 故障注入——直接docker stop jumpserver干掉一台应用节点观察 Nginx 日志里流量是否按max_fails的节奏漂到另一台期间已建立的终端会话是否按预期重连。2. 数据同步校验——主库写入一条测试资产去从库查出来确认流复制没有延迟断层psql -h 主库IP -U jumpserver -c INSERT INTO assets_asset(name) VALUES(ha-drill) psql -h 从库IP -U jumpserver -c SELECT name FROM assets_asset WHERE nameha-drill3. 并发压测——用ab对负载均衡入口打一千次、一百并发ab -n 1000 -c 100 http://入口/api/v1/观察两台节点负载是否均衡、P95 响应时间是否劣化。压测通过后再做一次故障注入叠加压测验证带病切换场景。行动提示把三组演练的结果切换耗时、会话保持情况、P95 延迟记成一份基线以后每次升级都跟它对比。上生产之前把这几件事钉死集群搭好只是起点下面是让它在半年后依然可靠的习惯备份要能一键恢复仓库自带 utils/backup_db.sh 这类导出脚本但更重要的是定期把 SQL 包和录像目录推到集群外的位置并真正做一次恢复演练——没恢复过的备份等于没有。⚠️蓝绿部署升级新大版本先在一套蓝环境上跑通再切流量别在双节点集群里做滚动盲升。告警阈值前置apps/ops/notifications.py 已内置磁盘水位告警超过 90% 触发把 CPU、内存、Redis 命中率、PG 复制延迟一并纳入再配上 Prometheus 指标端点做外部采集。每季度一次灾备演练模拟主库一台应用节点双故障验证从库提升和流量全切的完整动线演练发现的问题比事故便宜得多。✅把双节点 主从 集群缓存 共享存储这套 JumpServer 集群架构跑稳之后扩容路径也很直白应用层加机器即可线性扩瓶颈只会出现在数据层而那正是一开始按 4C/16G 配 PG 的原因。【免费下载链接】jumpserverJumpServer is an open-source Privileged Access Management (PAM) platform that provides DevOps and IT teams with on-demand and secure access to SSH, RDP, Kubernetes, Database and RemoteApp endpoints through a web browser.项目地址: https://gitcode.com/GitHub_Trending/ju/jumpserver创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
