JumpServer高可用部署终极指南：一次深夜宕机逼出的集群改造方案

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 是开源界广受欢迎的特权访问管理（PAM）平台，通过 Web 浏览器就能安全地访问 SSH、RDP、Kubernetes、数据库和 RemoteApp 等多种资产。本文以一次真实的深夜宕机事故为线索，完整串起 JumpServer 高可用部署的思考、设计与落地过程——从单点故障的代价，到多节点集群怎么搭、怎么验证、怎么长期维护，帮你把可用性从"看运气"稳稳提到 99.9%。

一、深夜11点的告警：单节点JumpServer到底栽在了哪里

那天晚上 23:07，值班群突然炸了。核心业务部门的人开始刷屏："连不上服务器了""数据库也登录不了"。我打开监控一看，跑在单台机器上的 JumpServer 实例整个失联——磁盘写满、进程卡死，连 sshd 都不响应。

更糟的是后面的连锁反应：

• 运维想登录线上机器排查，发现堡垒机自己也登不上，只能绕道云控制台，效率骤降；
• 好不容易重启恢复，会话全丢了，正在进行的操作全部中断；
• 第二天复盘发现，这台机器已经连续两个月没有重启过，日志、录像、备份全堆在本地盘上。

这不是偶发故障，而是单节点架构的必然结局。所谓"一台机器扛所有"，意味着它身上的每个组件——应用进程、数据库、缓存、文件存储——都是单点。任何一个环节出问题，整个服务就跟着瘫。

如果你现在也是"一台机器跑全套"的部署方式，下面的内容就是为你准备的。我们不妨用"假如再来一次"的视角，把整个集群从零搭一遍。

二、高可用不是堆机器：先搞懂这三个核心目标

动手之前，先想清楚高可用到底要解决什么。很多人以为"多买几台服务器"就是高可用，结果机器是多了，该瘫还是瘫。真正的高可用架构，要同时满足三个目标：

这三点可以类比成一家餐厅：你要保证"任何一名厨师请假都不影响出餐"（无单点）、"缺食材时自动切到备用方案"（自动转移）、"前台和厨房对菜单的理解永远一致"（数据一致）。

对应到 JumpServer 上，具体拆解成五个组件：

用户 → Nginx负载均衡 → JumpServer节点1、节点2 → PostgreSQL主库(+从库) ↘ Redis集群(会话/缓存) ↘ 共享存储(录像/配置)

三、JumpServer高可用部署要准备哪些组件：一张规划表看懂全部角色

网上很多教程一上来就甩命令，看得人云里雾里。这里先把"谁负责什么"讲清楚，后面照着填就行。

整体架构可以画成下面这张图：

有个容易忽略的点：JumpServer 的 Web 终端走的是 WebSocket 长连接（默认端口 8070，对应配置里的WS_LISTEN_PORT），负载均衡层务必支持 WebSocket 升级，否则会话会莫名其妙断线。

四、PostgreSQL主从复制和Redis集群怎么搭：数据不丢的底层保障

数据是堡垒机的命根子——资产列表、用户授权、操作审计都在这。数据库一旦丢了，比宕机更可怕。

1. 数据库：主从复制就是"账本+副本"

PostgreSQL 主从的原理，用大白话说就是：主库负责读写（记账），从库实时同步一份（抄副本）。主库挂了，从库能顶上来继续读；配合自动切换工具，业务几乎无感。

搭建时注意三点：

• 主从版本必须一致，否则复制协议会出各种诡异问题；
• 务必开启 WAL 归档，这是复制和 PITR（时间点恢复）的基础；
• 从库的同步延迟要监控，延迟超过阈值就该告警了。

项目根目录的config_example.yml里已经给出了数据库的标准配置模板，多节点统一指向同一个主库地址即可：

# 数据库配置：所有应用节点都连同一套 PostgreSQL 主库 DB_ENGINE: postgresql DB_HOST: 192.168.1.6 # 主库地址 DB_PORT: 5432 DB_USER: jumpserver DB_PASSWORD: 换成你的强密码 DB_NAME: jumpserver

2. Redis：三个和尚挑水，为什么反而更稳

会话和缓存为什么要集群？因为单台 Redis 内存有限，而且一旦这台机器断电，所有在线会话全部失效——用户会被集体"踢下线"。

Redis 集群采用 3 主 3 从的典型布局，数据按哈希槽分散到 3 个主节点，每个主节点再挂一个从节点兜底。就算挂掉一整台主节点，从节点能在几秒内完成切换。搭建命令不长，重点是端口规划和槽位分配：

# 准备 6 个端口（7000~7005），全部启用集群模式 for port in 7000 7001 7002 7003 7004 7005; do mkdir -p /data/redis/$port cat > /data/redis/$port/redis.conf <<EOF port $port cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes EOF done # 用 redis-cli 一键创建集群，--cluster-replicas 1 表示每个主节点配 1 个从节点 redis-cli --cluster create \ 192.168.1.7:7000 192.168.1.7:7001 192.168.1.7:7002 \ 192.168.1.7:7003 192.168.1.7:7004 192.168.1.7:7005 \ --cluster-replicas 1

最容易踩的坑：忘了给 Redis 配置密码，或者所有节点的cluster-enabled没统一开启。前者是安全隐患，后者会导致节点互相"不认识"，集群创建直接报错。

创建完成后，JumpServer 这边只需要填集群里任意一个节点地址，客户端会自动重定向到正确的分片：

# 会话与任务队列统一走 Redis 集群 REDIS_HOST: 192.168.1.7 REDIS_PORT: 7000

五、多节点如何共享一份配置与录像：共享存储的挂载实战

数据库和缓存搞定了，还有一个隐蔽的单点：文件。JumpServer 会落地操作录像、备份文件、部分配置，如果每台节点各自存一份，用户在节点 1 上的会话录像，节点 2 上就回放不了。

解法是共享存储（NFS/SMB）。它就像楼层的"公共储物柜"，所有节点往里放东西、拿东西，都是同一份。

服务端只需两步：编辑/etc/exports暴露目录，然后启动 NFS 服务。客户端挂载后，把 JumpServer 的数据目录指向挂载点，比如：

# 应用节点上挂载共享目录 mkdir -p /data/jumpserver/share mount -t nfs 192.168.1.5:/data/share /data/jumpserver/share # 启动容器时把共享目录挂进容器 docker run -d --name jumpserver \ -v /data/jumpserver/share:/opt/jumpserver/share \ -v /data/jumpserver/config:/opt/jumpserver/config \ ...

这里有个忠告：共享存储别图省事放在应用节点自己身上，那等于没共享。宁可单独用一台机器或者对象存储，也要保证储物柜和取东西的人不是同一间房。

六、如何用Nginx实现节点故障自动切换：负载均衡与健康检查配置

负载均衡是这套架构的"总闸"。它的工作方式可以这样理解：用户请求先到 Nginx，Nginx 按策略把请求分给后台的一号窗口或二号窗口；某个窗口出餐慢了、卡住了，它自动把后面的客人都引到另一个窗口——这就是故障自动切换。

一份精简可用的 Nginx 配置长这样：

# 定义后端节点池：max_fails=3 表示连续失败 3 次记为宕机 # fail_timeout=30s 表示在 30 秒内不再把流量分给它 upstream jumpserver_cluster { server 192.168.1.10:8080 max_fails=3 fail_timeout=30s; server 192.168.1.11:8080 max_fails=3 fail_timeout=30s; } server { listen 80; server_name jumpserver.example.com; location / { proxy_pass http://jumpserver_cluster; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # Web 终端依赖 WebSocket 长连接，必须带上升级头 proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } }

光有 Nginx 还不够，还得让 JumpServer 自己会"报平安"。JumpServer 内置了健康检查接口/health/，返回 HTTP 200 就代表节点正常。把它接到监控系统里，节点一凉，告警立刻弹出来。

另外，Celery 工作节点（负责执行自动化任务）同样需要健康探测。项目里现成的utils/check_celery.sh思路很巧妙：工作节点周期性往/tmp/worker_heartbeat_celery等文件写入心跳，脚本检查这个文件是否存在、时间戳是否在 20 秒以内，以此判断工作节点是死是活：

# 心跳文件在 20 秒内更新过，说明 Celery 工作节点还活着 test -e /tmp/worker_heartbeat_celery && \ test $(($(date +%s) - $(stat -c %Y /tmp/worker_heartbeat_celery))) -lt 20

这比单纯的"端口通不通"可靠得多——进程可能还占着端口，但早就卡死不动了。

七、多节点跑定时任务会重复执行吗：Celery分布式任务去重机制

"机器变多了，麻烦事也变多"——这是分布式架构的经典课题。JumpServer 里有大量定时任务，比如账号改密、资产扫描、数据统计。如果两台节点各跑一遍，资产会被扫描两遍、密码被改两遍，甚至产生冲突。

JumpServer 的解法是用 Redis 分布式锁给调度器"划地盘"。在apps/ops/celery/utils.py里能看到它的实现：调度器启动前先尝试拿一把名为beat-distribute-start-lock的锁，拿不到锁的节点就乖乖当"看客"，只有持锁的节点负责派发任务，从而保证同一时刻只有一个调度器在工作。

# 仅演示核心逻辑，完整实现见 apps/ops/celery/utils.py lock = redis_lock.Lock(r, name="beat-distribute-start-lock") if lock.acquire(blocking=False): # 拿到锁：我是唯一的任务调度者 start_beat_scheduler() else: # 没拿到锁：另一个节点在调度，我只跑普通任务 start_worker_only()

这告诉我们一个道理：多节点部署不是简单的"复制粘贴"，每个组件都要想清楚"重复了怎么办"。除了定时任务，迁移脚本、初始化脚本这类一次性操作，也要保证只在首台节点执行。

八、验证高可用集群的四种演练方法：故障注入与压测实操

集群搭好不等于万事大吉。不上手做一次"定向爆破"，你永远不知道它到底能不能扛。

演练一：应用节点故障注入

模拟某天凌晨节点突然宕机，看系统是否真的"无感切换"：

# 停掉一号应用节点，模拟故障 docker stop jumpserver # 观察 Nginx 日志，确认后续请求全部被转发到二号节点 tail -f /var/log/nginx/access.log

正常的话，你只会看到一号节点不再出现新请求，用户侧完全无感知。

演练二：数据同步验证

在主库插入一条测试资产，然后到从库查，确认复制链路是通的：

# 主库写入 psql -h 192.168.1.6 -U jumpserver -c "INSERT INTO assets_asset(name) VALUES('ha-test');" # 从库读取，能查到说明复制正常 psql -h 192.168.1.6 -U jumpserver -c "SELECT * FROM assets_asset WHERE name='ha-test';"

演练三：并发压测

用 Apache Bench 模拟 100 并发、1000 次请求，观察负载是否被合理分摊、错误率是否为零：

ab -n 1000 -c 100 http://jumpserver.example.com/api/v1/assets/assets/

演练四：数据库主从切换演练

这是最容易被跳过、却最值得做的一项。把主库"打死"，验证从库能否自动提升为主库、应用节点能否自动重连。千万别在生产环境直接演练，先在测试环境跑通切换脚本，再排期到低峰期操作。

九、上线后怎么守：监控告警与备份恢复的日常运维清单

高可用是一场马拉松，不是一次性的装修。上线之后，下面这张运维清单请贴在工位上。

1. 告警阈值：让机器替你盯梢

JumpServer 的apps/ops/notifications.py里内置了资源告警机制，核心指标和默认阈值如下：

配合 Nginx 的/health/健康检查和 Celery 心跳探测，四路信号一起盯，基本能做到"故障还没被用户感知，告警先响"。

2. 备份恢复：最后一道防线

再高可用的架构也防不住"删库跑路"和"误操作"。请记住一句话：高可用保障的是"不中断"，备份保障的是"可回滚"，两者缺一不可。

• 数据库：每日全量 + 实时 WAL 归档，至少保留 7 天；
• 录像与配置文件：随共享存储一并定期快照；
• 每季度做一次真实的恢复演练——备份能不能用，只有真正还原过才知道。

3. 版本升级：别在集群里"裸奔"升级

集群的优势之一就是可以滚动升级：先停一个节点升级、验证，再升下一个，全程业务不断。utils/build_docker.sh可以帮你用仓库代码直接构建指定版本的镜像，例如：

bash utils/build_docker.sh v3.10.0

升级前务必先看官方 changelog，数据库结构变更类升级一定要先备份。

十、写在最后：给初学者的4条落地建议

回头看那晚的宕机，其实要感谢它——没有那次事故，我可能永远不会认真对待高可用。最后给还在观望的你四条建议：

1. 从小处开始：不必一步到位。先加一台应用节点 + Nginx 负载均衡，让"应用层"先冗余起来，感受一下双节点的踏实感；
2. 数据先行：数据库主从 + 定时备份是性价比最高的投入，优先做，别的可以慢慢来；
3. 把演练写进日程：每季度一次故障演练，把"切流量""升从库"这些动作练成肌肉记忆，真出事时不慌；
4. 监控要早配：告警不是在出事之后装的，而是在出事之前。先把磁盘、内存、心跳三项阈值配上，成本几乎为零，收益却可能是一次关键的业务挽救。

架构没有终点，只有不断逼近的目标。今天的 2 节点集群，明天随着业务增长，完全可以平滑扩到 4 节点、8 节点——这正是集群架构最有魅力的地方：它给未来留好了位置。

【免费下载链接】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