1. 为什么堡垒机也要做高可用很多团队在搭建堡垒机跳板机的时候第一反应是装一台就行了毕竟它只是一个运维入口平时用的人也不多。但真正在生产环境里跑过一段时间之后就会发现堡垒机一旦挂掉整个运维通道就断了——所有服务器都进不去故障排查、紧急发布、线上救火全部停摆。这种单点故障带来的风险远比想象中严重。我所在的团队之前就踩过这个坑。当时用一台中等配置的机器跑堡垒机某天磁盘写满导致服务异常结果整整两个小时里所有运维人员都无法登录任何一台生产服务器。虽然业务本身没受影响但那种看得见问题却进不去的无力感让团队下定决心要做高可用部署。这篇文章围绕jumpserver v1.5.9 版本的高可用部署方案展开把整个架构设计、组件拆解、实操步骤、参数配置、踩坑经验完整地梳理一遍。适合正在规划堡垒机高可用架构的运维工程师、DevOps 从业者以及需要给团队搭建一套稳定运维入口的技术负责人。即使你之前没接触过 jumpserver跟着思路走也能理解每一步在做什么、为什么这么做。需要提前说明的是jumpserver 的版本迭代比较快v1.5.9 属于较早期的稳定版本它的组件架构和后续版本有一定差异。本文的方案基于这个版本的实际部署经验整理如果你用的是其他版本部分组件名称和配置路径需要对照官方文档做调整。2. 高可用架构的整体设计思路2.1 先搞清楚 jumpserver 有哪些组件要做高可用第一步必须把 jumpserver 的组件拆清楚知道哪些是有状态的、哪些是无状态的才能决定每个组件用什么方式做冗余。v1.5.9 版本的核心组件大致分为以下几类组件作用是否有状态高可用方式Jumpserver 核心服务提供 Web 界面和 API无状态多节点 负载均衡MySQL存储用户、资产、权限等元数据有状态主从复制 / 主主Redis缓存和会话存储有状态哨兵 / 集群录像存储存放会话录像文件有状态共享存储 / 对象存储这个拆分非常关键。核心服务本身是无状态的意味着你可以起多个实例前面挂一个负载均衡就能实现冗余。但 MySQL、Redis 和录像存储是有状态的它们的高可用需要单独设计不能简单靠多起几个进程解决。提示很多人做高可用时只关注了 Web 服务忽略了录像存储。结果 Web 服务做了双节点录像却写在了本地磁盘上一旦某个节点挂掉那台机器上的历史录像就找不到了。录像存储的高可用同样重要。2.2 为什么选择双节点 外部数据库方案高可用方案有很多种从最简单的主备切换到复杂的多活集群都有。结合 v1.5.9 版本的实际能力和大多数团队的成本预算我最终选择的是双节点核心服务 外部独立数据库 共享录像存储的方案。选择这个方案的理由有三点。第一双节点已经能覆盖绝大多数故障场景单节点故障时另一台可以立即接管可用性从单点提升到基本无中断性价比最高。第二把 MySQL 和 Redis 独立出来部署核心服务节点就变成了纯粹的无状态节点扩容和替换都非常简单哪台坏了直接换掉即可。第三录像存储用共享方式NFS 或对象存储保证无论请求落到哪个节点录像都能被正确读写。如果团队规模更大、对可用性要求更高可以扩展到三节点甚至更多架构思路是一样的只是负载均衡的配置和数据库的承载能力需要相应提升。但对于大多数中小团队来说双节点是投入产出比最合适的选择。2.3 负载均衡层怎么选负载均衡层是整个架构的入口它的稳定性直接决定了整套系统能不能被访问到。常见的选择有 LVS、Nginx、HAProxy 以及云厂商的负载均衡服务。我在实际部署中用的是Nginx Keepalived的组合。Nginx 负责七层转发和健康检查Keepalived 负责虚拟 IP 的漂移。这样即使一台 Nginx 挂掉虚拟 IP 会自动漂移到另一台对外表现为一个始终可用的入口。选择这个组合的原因是配置简单、社区资料丰富、排查问题方便而且 Nginx 对 WebSocket 的支持很好——jumpserver 的 Web 终端依赖 WebSocket这一点必须考虑进去。如果你用的是云环境直接使用云厂商的负载均衡服务会更省心健康检查、证书管理、带宽弹性都是现成的。但要注意确认它是否支持 WebSocket 长连接以及会话保持sticky session的配置方式。3. 部署前的环境准备与关键参数3.1 服务器规划与资源配置在动手之前先把服务器规划清楚。下面是我实际使用的一套配置供参考角色数量配置建议说明负载均衡节点22C4G跑 Nginx Keepalived核心服务节点24C8G跑 jumpserver 核心服务MySQL 节点24C8G SSD主从复制Redis 节点22C4G哨兵模式录像存储1按容量规划NFS 或对象存储核心服务节点为什么给 4C8G因为 jumpserver 在处理 Web 终端会话时会对 SSH 流量做转发和录像编码CPU 和内存的消耗比想象中高。如果并发会话多配置低了会出现终端卡顿、录像丢帧的情况。我实测下来4C8G 大概能稳定支撑 50 到 80 个并发会话超过这个量级就要考虑加节点或升配。MySQL 一定要用 SSD。jumpserver 的元数据读写虽然不算特别频繁但在用户登录、权限校验、资产查询这些操作上对响应时间很敏感。用机械盘的话登录时的等待感会很明显。3.2 网络与端口规划网络规划这块最容易出问题的是端口。jumpserver 涉及的端口比较多提前规划好能省很多事80/443Web 访问端口由负载均衡层对外暴露8080核心服务内部监听端口3306MySQL 端口只对核心服务节点开放6379Redis 端口只对核心服务节点开放2222SSH 代理端口用于客户端工具连接2048/2049NFS 相关端口用于录像共享存储注意2222 端口是 jumpserver 用来代理 SSH 连接的很多人在防火墙里只开了 80 和 443结果 Web 界面能打开但用客户端工具连不上排查半天才发现是端口没放行。这个端口必须对所有需要连接资产的运维人员开放。另外核心服务节点和数据库节点之间的网络延迟要尽量低最好在同一个内网网段。跨机房部署会引入额外的网络延迟影响数据库操作的响应速度。3.3 时间同步不能忽视这一点看起来是小事但在高可用架构里非常关键。所有节点的时间必须保持同步否则会出现各种诡异问题录像文件的时间戳错乱、日志时间对不上、数据库主从复制的延迟计算异常、Keepalived 的健康检查误判等等。部署前务必在所有节点上配置好时间同步服务确保各节点时间偏差在秒级以内。这个步骤花不了几分钟但能避免后面大量的排查工作。4. 核心组件的实操部署过程4.1 数据库层MySQL 主从复制配置数据库是整个高可用架构的基础先把它搞定。MySQL 采用主从复制模式主库负责写从库负责读和备份主库故障时可以手动或自动切换到从库。主库的配置重点在my.cnf里开启 binlog[mysqld] server-id 1 log-bin mysql-bin binlog-format ROW gtid-mode ON enforce-gtid-consistency ON从库的server-id要改成不同的值比如 2其他保持一致。用 GTID 模式的好处是主从切换时不用手动计算 binlog 位置直接根据 GTID 就能找到同步点切换过程更可靠。配置完成后在主库上创建复制账号并授权然后在从库上执行CHANGE MASTER TO指向主库启动复制。用SHOW SLAVE STATUS检查Slave_IO_Running和Slave_SQL_Running两个状态是否都是Yes。实操心得主从复制配置好之后一定要做一次实际的故障演练——手动停掉主库看看从库能不能正常接管应用能不能连上。我见过太多配置看起来没问题真出事时切换失败的案例。演练一次心里才有底。4.2 缓存层Redis 哨兵模式搭建Redis 在 jumpserver 里主要承担会话缓存和部分队列功能。单点 Redis 挂掉会导致用户会话丢失、需要重新登录严重时会影响服务启动。用哨兵模式可以实现自动故障转移。哨兵模式的部署分两部分一是 Redis 数据节点一主一从二是哨兵节点建议至少三个但双节点环境下可以用两个哨兵加一个仲裁配置。主节点的redis.conf关键配置bind 0.0.0.0 protected-mode yes requirepass your_strong_password masterauth your_strong_password从节点除了server-id不同还要加上slaveof 主节点IP 6379。哨兵节点的配置里指定要监控的主节点地址和仲裁数量sentinel monitor mymaster 主节点IP 6379 2 sentinel auth-pass mymaster your_strong_password sentinel down-after-milliseconds mymaster 5000down-after-milliseconds设成 5000 表示 5 秒没响应就认为主节点挂了。这个值不要设太小否则网络抖动会触发误切换也不要设太大否则故障转移太慢。5 秒是个比较平衡的值。4.3 核心服务节点部署核心服务节点的部署是重头戏。v1.5.9 版本的安装方式主要是通过安装脚本或手动部署 Python 环境。两台核心服务节点的配置要完全一致包括版本号、配置文件、依赖库。部署时的关键点在于配置文件的修改。核心服务需要连接数据库、Redis 和录像存储这些连接信息都写在配置文件里。两台节点的配置除了本机监听地址外其他应该完全相同都指向同一个 MySQL 主库、同一组 Redis 哨兵、同一个录像存储路径。# 数据库配置示例 DB_HOST 10.0.0.10 # MySQL 主库地址 DB_PORT 3306 DB_USER jumpserver DB_PASSWORD your_password DB_NAME jumpserver # Redis 配置示例 REDIS_HOST 10.0.0.20 # Redis 哨兵地址 REDIS_PORT 26379 REDIS_PASSWORD your_password部署完成后先启动第一台节点确认能正常访问、能登录、能连接资产。然后再启动第二台通过负载均衡访问确认请求能正确分发到两台节点。注意两台核心服务节点必须使用同一个数据库和同一个 Redis否则会出现在这台机器上创建的资产换一台就看不到的问题。这是新手最容易犯的错误——把两台节点当成独立系统来装结果数据完全隔离。4.4 录像共享存储配置录像存储用 NFS 是最简单的方案。找一台机器或者用现有的存储服务器搭建 NFS 服务导出一个目录给两台核心服务节点挂载。NFS 服务端的/etc/exports配置/data/jumpserver/replay 10.0.0.0/24(rw,sync,no_subtree_check,no_root_squash)客户端的挂载命令mount -t nfs 10.0.0.30:/data/jumpserver/replay /opt/jumpserver/data/replay挂载完成后在两台节点上分别创建测试文件确认另一台能看到说明共享存储工作正常。为了开机自动挂载记得把挂载信息写进/etc/fstab。如果团队有对象存储比如兼容 S3 协议的服务也可以把录像直接存到对象存储里这样可用性和扩展性更好但需要在 jumpserver 里做相应的存储后端配置。v1.5.9 版本对对象存储的支持相对基础需要根据实际情况评估。4.5 负载均衡与虚拟 IP 配置最后一步是把负载均衡层配好。Nginx 的配置核心是 upstream 和健康检查upstream jumpserver { server 10.0.0.101:8080 max_fails3 fail_timeout10s; server 10.0.0.102:8080 max_fails3 fail_timeout10s; } server { listen 80; server_name your_domain.com; location / { proxy_pass http://jumpserver; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; } }Upgrade和Connection这两行是 WebSocket 支持的关键少了它们 Web 终端会连不上。max_fails3 fail_timeout10s表示 10 秒内失败 3 次就把这个节点标记为不可用实现自动摘除故障节点。Keepalived 的配置在两台负载均衡节点上分别设置主备状态配置虚拟 IP 和优先级。主节点优先级高备节点优先级低主节点故障时虚拟 IP 自动漂移到备节点。5. 常见问题与排查技巧实录5.1 登录后频繁掉线这是高可用部署后最常见的问题之一。表现是用户登录后操作一会儿就提示会话失效需要重新登录。根本原因通常是Redis 会话没有共享或者负载均衡没有做会话保持。排查思路先确认两台核心服务节点连接的是同一个 Redis。如果 Redis 配置没问题再检查负载均衡的会话保持配置。Nginx 可以用ip_hash让同一 IP 的请求固定落到同一节点但更推荐的做法是确保会话数据存在共享的 Redis 里这样无论请求落到哪台都没问题。5.2 录像文件丢失或无法播放录像丢失一般有两个原因一是录像存储没有共享写在了本地磁盘二是 NFS 挂载异常导致写入失败。排查时先在两台节点上分别检查录像目录看文件是否一致。如果一台有、一台没有说明共享存储没配好。如果 NFS 挂载断了可以用df -h查看挂载状态用showmount -e检查 NFS 服务端导出是否正常。实操心得NFS 挂载建议加上hard和intr选项避免 NFS 服务端异常时客户端进程卡死。另外可以写一个定时脚本定期检查挂载状态发现异常自动重新挂载并告警。5.3 数据库主从延迟导致数据不一致主从复制有延迟是正常的但如果延迟过大会导致用户在主库写入的数据从库还没同步过来读请求落到从库时看不到最新数据。排查方法是在主库执行SHOW MASTER STATUS在从库执行SHOW SLAVE STATUS对比Seconds_Behind_Master的值。如果这个值持续增大说明从库同步跟不上可能是从库性能不足或网络带宽不够。解决思路一是提升从库配置二是优化大事务三是对于强一致性要求的读操作直接走主库。jumpserver 的元数据读操作对一致性要求不算特别高但登录和权限校验这类操作建议走主库。5.4 常见问题速查表问题现象可能原因排查方向Web 界面打不开负载均衡故障 / 核心服务未启动检查 Nginx 状态、核心服务进程能登录但连不上资产2222 端口未放行 / SSH 代理异常检查防火墙、SSH 代理进程频繁掉线Redis 会话未共享 / 会话保持缺失检查 Redis 配置、负载均衡策略录像丢失存储未共享 / NFS 挂载异常检查挂载状态、目录一致性数据不一致主从延迟 / 读写分离配置错误检查复制状态、读写路由时间戳错乱节点时间不同步检查时间同步服务5.5 故障演练与监控告警高可用架构配好之后一定要做故障演练。手动停掉一台核心服务节点观察负载均衡是否自动摘除、用户是否受影响手动停掉 MySQL 主库观察从库是否能接管手动断开 NFS观察录像是否还能正常写入。监控方面重点监控几个指标核心服务节点的进程状态和资源使用率、MySQL 主从复制延迟、Redis 哨兵状态、NFS 挂载状态、负载均衡的健康检查结果。这些指标任何一个异常都可能导致整套系统不可用必须配置告警。我个人在实际操作中的体会是高可用架构的价值不在于配置得多复杂而在于故障时能不能真正顶上。很多看起来完美的配置没有经过实际演练真出事时往往掉链子。所以部署完成只是第一步定期的故障演练和监控巡检才是保证长期稳定的关键。另外文档一定要写清楚——每个组件的配置、切换步骤、回滚方案都要有据可查这样即使换人来维护也能快速上手。