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/jumpserverJumpServer 是开源界广受欢迎的特权访问管理PAM平台通过 Web 浏览器就能安全地访问 SSH、RDP、Kubernetes、数据库和 RemoteApp 等多种资产。本文以一次真实的深夜宕机事故为线索完整串起 JumpServer 高可用部署的思考、设计与落地过程——从单点故障的代价到多节点集群怎么搭、怎么验证、怎么长期维护帮你把可用性从看运气稳稳提到 99.9%。一、深夜11点的告警单节点JumpServer到底栽在了哪里那天晚上 23:07值班群突然炸了。核心业务部门的人开始刷屏连不上服务器了数据库也登录不了。我打开监控一看跑在单台机器上的 JumpServer 实例整个失联——磁盘写满、进程卡死连 sshd 都不响应。更糟的是后面的连锁反应运维想登录线上机器排查发现堡垒机自己也登不上只能绕道云控制台效率骤降好不容易重启恢复会话全丢了正在进行的操作全部中断第二天复盘发现这台机器已经连续两个月没有重启过日志、录像、备份全堆在本地盘上。这不是偶发故障而是单节点架构的必然结局。所谓一台机器扛所有意味着它身上的每个组件——应用进程、数据库、缓存、文件存储——都是单点。任何一个环节出问题整个服务就跟着瘫。如果你现在也是一台机器跑全套的部署方式下面的内容就是为你准备的。我们不妨用假如再来一次的视角把整个集群从零搭一遍。二、高可用不是堆机器先搞懂这三个核心目标动手之前先想清楚高可用到底要解决什么。很多人以为多买几台服务器就是高可用结果机器是多了该瘫还是瘫。真正的高可用架构要同时满足三个目标目标大白话解释没做好的后果无单点故障任何一个组件坏了服务还能跑硬盘、数据库、缓存坏了直接全瘫自动故障转移不用人半夜爬起来手动切流量机器死了业务就停到有人发现为止数据一致同步多台机器读到的是同一份状态节点 A 有这台资产节点 B 查不到这三点可以类比成一家餐厅你要保证任何一名厨师请假都不影响出餐无单点、缺食材时自动切到备用方案自动转移、前台和厨房对菜单的理解永远一致数据一致。对应到 JumpServer 上具体拆解成五个组件用户 → Nginx负载均衡 → JumpServer节点1、节点2 → PostgreSQL主库(从库) ↘ Redis集群(会话/缓存) ↘ 共享存储(录像/配置)三、JumpServer高可用部署要准备哪些组件一张规划表看懂全部角色网上很多教程一上来就甩命令看得人云里雾里。这里先把谁负责什么讲清楚后面照着填就行。组件角色类比数量建议最低配置承担的职责Nginx/HAProxy餐厅门口的叫号台2配 Keepalived VIP2C4G分发请求、健康检查、故障切换JumpServer 应用节点窗口里的厨师2 起步4C8G跑 Web、WebSocket、Celery 任务PostgreSQL 主从前台总账本 副本主 1 从 14C16G存资产、用户、授权等核心数据Redis 集群传菜部的黑板3 主 3 从2C4G用户会话、缓存、Celery 队列共享存储NFS/SMB公共储物柜1100G录像回放、配置文件保持一致整体架构可以画成下面这张图有个容易忽略的点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: jumpserver2. 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实现节点故障自动切换负载均衡与健康检查配置负载均衡是这套架构的总闸。它的工作方式可以这样理解用户请求先到 NginxNginx 按策略把请求分给后台的一号窗口或二号窗口某个窗口出餐慢了、卡住了它自动把后面的客人都引到另一个窗口——这就是故障自动切换。一份精简可用的 Nginx 配置长这样# 定义后端节点池max_fails3 表示连续失败 3 次记为宕机 # fail_timeout30s 表示在 30 秒内不再把流量分给它 upstream jumpserver_cluster { server 192.168.1.10:8080 max_fails3 fail_timeout30s; server 192.168.1.11:8080 max_fails3 fail_timeout30s; } 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, namebeat-distribute-start-lock) if lock.acquire(blockingFalse): # 拿到锁我是唯一的任务调度者 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 nameha-test;演练三并发压测用 Apache Bench 模拟 100 并发、1000 次请求观察负载是否被合理分摊、错误率是否为零ab -n 1000 -c 100 http://jumpserver.example.com/api/v1/assets/assets/演练四数据库主从切换演练这是最容易被跳过、却最值得做的一项。把主库打死验证从库能否自动提升为主库、应用节点能否自动重连。千万别在生产环境直接演练先在测试环境跑通切换脚本再排期到低峰期操作。九、上线后怎么守监控告警与备份恢复的日常运维清单高可用是一场马拉松不是一次性的装修。上线之后下面这张运维清单请贴在工位上。1. 告警阈值让机器替你盯梢JumpServer 的apps/ops/notifications.py里内置了资源告警机制核心指标和默认阈值如下监控指标默认告警阈值触发时的含义组件在线状态离线即告警某个核心组件掉线了磁盘使用率超过 80%再不清腾空间就要写满内存使用率超过 85%有内存泄漏风险或容量不足CPU 负载超过 5节点已在高负荷运转配合 Nginx 的/health/健康检查和 Celery 心跳探测四路信号一起盯基本能做到故障还没被用户感知告警先响。2. 备份恢复最后一道防线再高可用的架构也防不住删库跑路和误操作。请记住一句话高可用保障的是不中断备份保障的是可回滚两者缺一不可。数据库每日全量 实时 WAL 归档至少保留 7 天录像与配置文件随共享存储一并定期快照每季度做一次真实的恢复演练——备份能不能用只有真正还原过才知道。3. 版本升级别在集群里裸奔升级集群的优势之一就是可以滚动升级先停一个节点升级、验证再升下一个全程业务不断。utils/build_docker.sh可以帮你用仓库代码直接构建指定版本的镜像例如bash utils/build_docker.sh v3.10.0升级前务必先看官方 changelog数据库结构变更类升级一定要先备份。十、写在最后给初学者的4条落地建议回头看那晚的宕机其实要感谢它——没有那次事故我可能永远不会认真对待高可用。最后给还在观望的你四条建议从小处开始不必一步到位。先加一台应用节点 Nginx 负载均衡让应用层先冗余起来感受一下双节点的踏实感数据先行数据库主从 定时备份是性价比最高的投入优先做别的可以慢慢来把演练写进日程每季度一次故障演练把切流量升从库这些动作练成肌肉记忆真出事时不慌监控要早配告警不是在出事之后装的而是在出事之前。先把磁盘、内存、心跳三项阈值配上成本几乎为零收益却可能是一次关键的业务挽救。架构没有终点只有不断逼近的目标。今天的 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考