JumpServer 集群部署指南如何构建 99.9% 高可用架构【免费下载链接】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 为例拆解生产级 JumpServer 集群部署高可用的完整方案2 个应用节点 PostgreSQL 主从 3 节点 Redis 集群即可实现无人工干预的自动故障切换可用性目标 99.9%并教你用故障演练独立验证切换真的生效。高可用集群架构设计 整个架构围绕三条目标展开无单点故障任一层负载、应用、数据、缓存、存储至少 2 份冗余单组件宕机服务不中断自动故障切换故障由负载均衡器被动健康检查发现并摘除全程无需人工介入数据一致同步会话与任务队列存 Redis 实现跨节点共享业务数据靠 PostgreSQL 流复制主库实时同步到从库的复制机制保持主从一致。各组件职责与最小数量如下组件职责最小数量Nginx 负载均衡分发 HTTP/WebSocket 请求被动健康检查摘除故障节点2或配 Keepalived 做 VIP 漂移JumpServer 应用节点提供 Web 界面与 API无状态会话外置2PostgreSQL存储用户、资产、权限等核心业务数据主从流复制21 主 1 从Redis 集群存储 Celery 任务队列、缓存与用户会话节点故障不丢数据3NFS 共享存储录像文件、配置文件多节点共享读写1流量方向与依赖关系一句话说明每个组件Nginx 负责请求分发与故障摘除应用节点无状态可随时水平扩容PostgreSQL 主从保证数据不丢并可从库接管Redis 集群承载任务与会话是跨节点切换的基础NFS 保证录像与配置在所有节点视图一致。架构就位后接下来按层落地。分层落地负载均衡、应用、数据与存储负载均衡层Nginx 被动健康检查为什么这么选Nginx 的被动健康检查不需要额外组件max_fails与fail_timeout两个参数即可实现3 次失败、30 秒内摘除对新手最友好。关键配置项upstream jumpserver { server 192.168.1.10:8080 max_fails3 fail_timeout30s; server 192.168.1.11:8080 max_fails3 fail_timeout30s; } server { location / { proxy_pass http://jumpserver; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /api/health/ { proxy_pass http://jumpserver/api/health/; proxy_next_upstream error timeout http_502 http_503; } }参数建议值作用max_fails3连续 3 次失败标记节点不可用fail_timeout30s失败观察窗口到期后自动重试该节点proxy_next_upstreamerror timeout http_502出错立即转下一节点用户无感JumpServer 内置健康检查接口/api/health/见 apps/jumpserver/urls.py可作为主动探活端点。验证该层就绪curl -s -o /dev/null -w %{http_code} http://负载均衡IP/api/health/返回200即链路贯通。应用层JumpServer 多节点部署要点为什么这么选JumpServer 应用层无状态会话、任务队列全部外置到 Redis因此多节点只需指向同一套数据层。节点扩容即横向扩展是 99.9% 可用性的主要弹性来源。关键配置项完整示例见 config_example.yml每个节点配置需完全一致仅HTTP_LISTEN_PORT可各自绑定DB_ENGINE: postgresql DB_HOST: 192.168.1.6 # 所有节点指向同一数据库 DB_PORT: 5432 DB_USER: jumpserver DB_PASSWORD: ****** DB_NAME: jumpserver REDIS_HOST: 192.168.1.7 # Redis 集群入口 REDIS_PORT: 6379 SESSION_COOKIE_AGE: 3600 # 会话有效期 1 小时会话数据存 Redis部署上建议用 utils/build_docker.sh 构建镜像各节点容器把共享目录录像、配置挂载到同一 NFS 路径如需源码构建先执行git clone https://gitcode.com/GitHub_Trending/ju/jumpserver再构建。登录入口效果如下验证该层就绪bash utils/check_celery.sh脚本检查/tmp/worker_heartbeat_*心跳文件由 apps/ops/celery/heatbeat.py 每 20 秒刷新是否在 20 秒内更新退出码 0 表示 Celery 工作节点存活。数据层PostgreSQL 主从与 Redis 集群为什么这么选业务数据是集群中唯一不可重建的部分PostgreSQL 流复制让从库可在主库故障后接管Redis 3 节点集群模式保证任务队列与缓存单点故障不中断。特别注意定时任务JumpServer 的 Beat 调度器通过 Redis 分布式锁beat-distribute-start-lock见 apps/ops/celery/utils.py保证多节点环境下同一时刻只有一个调度器持有锁避免任务重复执行。关键配置项配置建议值说明DB_ENGINE/DB_HOSTpostgresql / 主库地址主从复制在数据库侧配置应用侧始终指向主库Redis3 节点cluster-enabled yes会话共享 任务队列nodes.conf与 AOF 落盘PERIOD_TASK_ENABLEDtrue定时任务依赖 Celery Beat多节点由锁去重验证该层就绪# 主库写入测试数据 psql -h 192.168.1.6 -U jumpserver -c INSERT INTO users_user(username) VALUES(ha-test) # 从库查询非空即复制生效 psql -h 192.168.1.7 -U jumpserver -c SELECT id FROM users_user WHERE usernameha-test存储层NFS 共享存储挂载为什么这么选会话录像、导出文件、配置文件必须多节点一致读写NFS 提供标准的 POSIX 共享挂载比对象存储更贴合 JumpServer 的目录式文件访问模式。关键配置项项目示例说明服务端/etc/exports/data/share 192.168.1.0/24(rw,sync,no_root_squash)sync保证落盘一致性客户端挂载点/opt/jumpserver/share录像与配置统一挂载节点重启后重新 mount验证该层就绪df -h /opt/jumpserver/share输出中显示 NFS 挂载且剩余空间充足即就绪。确认无误后最后用故障演练检验整个集群。故障演练一键验证自动切换与数据一致性 怎么判断切换真的生效了——看三个现象摘除时长符合预期、接口持续 200、从库数据可查到。故障注入停掉一个节点验证流量切换docker stop jumpserver-node1 # 模拟应用节点故障 tail -f /var/log/nginx/access.log # 观察流量去向 curl -s -o /dev/null -w %{http_code}\n http://负载均衡IP/api/health/预期现象Nginx 最多在 3 个失败请求max_fails3后将该节点标记不可用30 秒观察窗口内全部流量落到存活节点健康检查接口持续返回 200客户端无 5xx。数据同步核验确认主从复制psql -h 192.168.1.7 -U jumpserver -c SELECT id FROM users_user WHERE usernameha-test预期现象上一节主库插入的测试数据在从库可立即查到说明流复制延迟在秒级以内若查不到需检查复制槽位与网络。并发压测验证高负载下会话连续性ab -n 1000 -c 100 http://jumpserver.example.com/api/v1/assets/assets/预期现象1000 请求 100 并发下无 5xx 尖峰个别 502 属正常重试且同一用户会话在两个节点间往返请求不被踢出——因为会话存 Redis这正是跨节点故障切换不丢登录态的关键证据。生产化上线清单 ✅备份每天用 数据库备份脚本 定时导出数据库保留 30 天每月至少 1 次真实恢复演练告警阈值启用内置资源告警CPU/内存/磁盘阈值建议 90%磁盘超阈值自动推送通知文案见国际化文件中的Disk used more than {max_threshold}%心跳巡检将utils/check_celery.sh接入监控系统心跳文件超过 20 秒未更新即告警蓝绿发布升级时先在一个节点切新版本观察 15 分钟无异常再切流量避免全量升级风险灾备演练每季度完整演练一次停应用节点 主库切换演练通过才算高可用达标Beat 锁巡检确认 Redis 中beat-distribute-start-lock同一时刻仅被一个节点持有防止定时任务重复执行。至此集群达到 99.9% 可用性目标JumpServer 应用层无状态的设计意味着后续只需在 Nginx upstream 中追加server行即可继续横向扩展应用节点数可按业务增长线性增加。【免费下载链接】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），仅供参考 JumpServer 集群部署指南：如何构建 99.9% 高可用架构
JumpServer 集群部署指南如何构建 99.9% 高可用架构【免费下载链接】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 为例拆解生产级 JumpServer 集群部署高可用的完整方案2 个应用节点 PostgreSQL 主从 3 节点 Redis 集群即可实现无人工干预的自动故障切换可用性目标 99.9%并教你用故障演练独立验证切换真的生效。高可用集群架构设计 整个架构围绕三条目标展开无单点故障任一层负载、应用、数据、缓存、存储至少 2 份冗余单组件宕机服务不中断自动故障切换故障由负载均衡器被动健康检查发现并摘除全程无需人工介入数据一致同步会话与任务队列存 Redis 实现跨节点共享业务数据靠 PostgreSQL 流复制主库实时同步到从库的复制机制保持主从一致。各组件职责与最小数量如下组件职责最小数量Nginx 负载均衡分发 HTTP/WebSocket 请求被动健康检查摘除故障节点2或配 Keepalived 做 VIP 漂移JumpServer 应用节点提供 Web 界面与 API无状态会话外置2PostgreSQL存储用户、资产、权限等核心业务数据主从流复制21 主 1 从Redis 集群存储 Celery 任务队列、缓存与用户会话节点故障不丢数据3NFS 共享存储录像文件、配置文件多节点共享读写1流量方向与依赖关系一句话说明每个组件Nginx 负责请求分发与故障摘除应用节点无状态可随时水平扩容PostgreSQL 主从保证数据不丢并可从库接管Redis 集群承载任务与会话是跨节点切换的基础NFS 保证录像与配置在所有节点视图一致。架构就位后接下来按层落地。分层落地负载均衡、应用、数据与存储负载均衡层Nginx 被动健康检查为什么这么选Nginx 的被动健康检查不需要额外组件max_fails与fail_timeout两个参数即可实现3 次失败、30 秒内摘除对新手最友好。关键配置项upstream jumpserver { server 192.168.1.10:8080 max_fails3 fail_timeout30s; server 192.168.1.11:8080 max_fails3 fail_timeout30s; } server { location / { proxy_pass http://jumpserver; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /api/health/ { proxy_pass http://jumpserver/api/health/; proxy_next_upstream error timeout http_502 http_503; } }参数建议值作用max_fails3连续 3 次失败标记节点不可用fail_timeout30s失败观察窗口到期后自动重试该节点proxy_next_upstreamerror timeout http_502出错立即转下一节点用户无感JumpServer 内置健康检查接口/api/health/见 apps/jumpserver/urls.py可作为主动探活端点。验证该层就绪curl -s -o /dev/null -w %{http_code} http://负载均衡IP/api/health/返回200即链路贯通。应用层JumpServer 多节点部署要点为什么这么选JumpServer 应用层无状态会话、任务队列全部外置到 Redis因此多节点只需指向同一套数据层。节点扩容即横向扩展是 99.9% 可用性的主要弹性来源。关键配置项完整示例见 config_example.yml每个节点配置需完全一致仅HTTP_LISTEN_PORT可各自绑定DB_ENGINE: postgresql DB_HOST: 192.168.1.6 # 所有节点指向同一数据库 DB_PORT: 5432 DB_USER: jumpserver DB_PASSWORD: ****** DB_NAME: jumpserver REDIS_HOST: 192.168.1.7 # Redis 集群入口 REDIS_PORT: 6379 SESSION_COOKIE_AGE: 3600 # 会话有效期 1 小时会话数据存 Redis部署上建议用 utils/build_docker.sh 构建镜像各节点容器把共享目录录像、配置挂载到同一 NFS 路径如需源码构建先执行git clone https://gitcode.com/GitHub_Trending/ju/jumpserver再构建。登录入口效果如下验证该层就绪bash utils/check_celery.sh脚本检查/tmp/worker_heartbeat_*心跳文件由 apps/ops/celery/heatbeat.py 每 20 秒刷新是否在 20 秒内更新退出码 0 表示 Celery 工作节点存活。数据层PostgreSQL 主从与 Redis 集群为什么这么选业务数据是集群中唯一不可重建的部分PostgreSQL 流复制让从库可在主库故障后接管Redis 3 节点集群模式保证任务队列与缓存单点故障不中断。特别注意定时任务JumpServer 的 Beat 调度器通过 Redis 分布式锁beat-distribute-start-lock见 apps/ops/celery/utils.py保证多节点环境下同一时刻只有一个调度器持有锁避免任务重复执行。关键配置项配置建议值说明DB_ENGINE/DB_HOSTpostgresql / 主库地址主从复制在数据库侧配置应用侧始终指向主库Redis3 节点cluster-enabled yes会话共享 任务队列nodes.conf与 AOF 落盘PERIOD_TASK_ENABLEDtrue定时任务依赖 Celery Beat多节点由锁去重验证该层就绪# 主库写入测试数据 psql -h 192.168.1.6 -U jumpserver -c INSERT INTO users_user(username) VALUES(ha-test) # 从库查询非空即复制生效 psql -h 192.168.1.7 -U jumpserver -c SELECT id FROM users_user WHERE usernameha-test存储层NFS 共享存储挂载为什么这么选会话录像、导出文件、配置文件必须多节点一致读写NFS 提供标准的 POSIX 共享挂载比对象存储更贴合 JumpServer 的目录式文件访问模式。关键配置项项目示例说明服务端/etc/exports/data/share 192.168.1.0/24(rw,sync,no_root_squash)sync保证落盘一致性客户端挂载点/opt/jumpserver/share录像与配置统一挂载节点重启后重新 mount验证该层就绪df -h /opt/jumpserver/share输出中显示 NFS 挂载且剩余空间充足即就绪。确认无误后最后用故障演练检验整个集群。故障演练一键验证自动切换与数据一致性 怎么判断切换真的生效了——看三个现象摘除时长符合预期、接口持续 200、从库数据可查到。故障注入停掉一个节点验证流量切换docker stop jumpserver-node1 # 模拟应用节点故障 tail -f /var/log/nginx/access.log # 观察流量去向 curl -s -o /dev/null -w %{http_code}\n http://负载均衡IP/api/health/预期现象Nginx 最多在 3 个失败请求max_fails3后将该节点标记不可用30 秒观察窗口内全部流量落到存活节点健康检查接口持续返回 200客户端无 5xx。数据同步核验确认主从复制psql -h 192.168.1.7 -U jumpserver -c SELECT id FROM users_user WHERE usernameha-test预期现象上一节主库插入的测试数据在从库可立即查到说明流复制延迟在秒级以内若查不到需检查复制槽位与网络。并发压测验证高负载下会话连续性ab -n 1000 -c 100 http://jumpserver.example.com/api/v1/assets/assets/预期现象1000 请求 100 并发下无 5xx 尖峰个别 502 属正常重试且同一用户会话在两个节点间往返请求不被踢出——因为会话存 Redis这正是跨节点故障切换不丢登录态的关键证据。生产化上线清单 ✅备份每天用 数据库备份脚本 定时导出数据库保留 30 天每月至少 1 次真实恢复演练告警阈值启用内置资源告警CPU/内存/磁盘阈值建议 90%磁盘超阈值自动推送通知文案见国际化文件中的Disk used more than {max_threshold}%心跳巡检将utils/check_celery.sh接入监控系统心跳文件超过 20 秒未更新即告警蓝绿发布升级时先在一个节点切新版本观察 15 分钟无异常再切流量避免全量升级风险灾备演练每季度完整演练一次停应用节点 主库切换演练通过才算高可用达标Beat 锁巡检确认 Redis 中beat-distribute-start-lock同一时刻仅被一个节点持有防止定时任务重复执行。至此集群达到 99.9% 可用性目标JumpServer 应用层无状态的设计意味着后续只需在 Nginx upstream 中追加server行即可继续横向扩展应用节点数可按业务增长线性增加。【免费下载链接】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），仅供参考