centos vnc如何进行负载均衡

CentOS 上实现 VNC 负载均衡的可行路径

• 四层转发优先：VNC 是基于 **RFB 协议（默认端口 5900+）**的长连接，最适合用 L4（TCP） 负载均衡器按连接数或最少连接进行分发，避免七层代理对桌面协议的不必要解析与开销。
• 连接亲和性：VNC 会话与单个桌面进程（如 :1、:2）强绑定，建议开启 源地址会话保持（IP Hash），减少同一用户被调度到不同后端导致的会话中断。
• 调度策略：优先 最少连接 或 加权最少连接；若有性能差异，给高性能节点更高权重。
• 健康检查：对后端 5901/5902… 做 TCP 探活，失败即摘除，恢复后自动回切。
• 高可用：部署 主备两台 负载均衡器，使用 VRRP/VIP 保证 VIP 不中断。

方案一 四层 LVS + Keepalived（内核级转发，性能最佳）

• 适用场景：自建机房或虚拟机环境，需要高吞吐、低延迟的 VNC 接入层。

• 架构要点：

  • 负载均衡器两台：LVS-Master / LVS-Backup，共享 VIP。
  • 后端 Real Server 运行 Xvnc/TigerVNC/RealVNC，每个桌面实例占用独立端口（如 5901、5902）。
  • 分发算法：最少连接（lc） 或 源地址哈希（sh）；健康检查用 TCP 探测。

• 快速步骤（示例）：

  1. 在两台 LB 安装工具
     • yum install -y ipvsadm keepalived
  2. 配置 Keepalived（/etc/keepalived/keepalived.conf 核心片段）
     • state MASTER/BACKUP、interface eth0、virtual_router_id 51、priority 100/90
     • virtual_ipaddress { 192.168.10.254 }
  3. 配置 LVS（在 LB 上以脚本或 systemd 执行）
     • 开启转发：echo 1 > /proc/sys/net/ipv4/ip_forward
     • 清除旧规则：ipvsadm -C
     • 添加虚拟服务（示例分发到 5901–5903 三个桌面端口）：
       • ipvsadm -A -t 192.168.10.254:5901 -s lc
       • ipvsadm -a -t 192.168.10.254:5901 -r 192.168.10.11:5901 -g -w 1
       • ipvsadm -a -t 192.168.10.254:5901 -r 192.168.10.12:5901 -g -w 1
       • 同理为 5902、5903 添加后端（算法与权重可按需调整）
     • 说明：5901 对应后端桌面 :1，5902 对应 :2，以此类推。
  4. 后端 Real Server 配置（以常见 VNC 为例）
     • 启动桌面：vncserver :1 -geometry 1440x900 -depth 24
     • 放行 ARP 与回环（示例）：
       • sysctl -w net.ipv4.conf.all.arp_ignore=1
       • sysctl -w net.ipv4.conf.all.arp_announce=2
       • ip addr add 192.168.10.254/32 dev lo:0
  5. 防火墙放行
     • firewall-cmd --permanent --add-port=5901-5903/tcp
     • firewall-cmd --reload
  6. 验证
     • ipvsadm -ln 查看连接与后端状态
     • 客户端连接 VIP:5901/5902/5903 验证会话保持与故障切换
       上述流程基于 LVS + Keepalived 的典型用法，可满足 VNC 的 L4 分发与高可用诉求。

方案二 七层 HAProxy（灵活运维，便于观测）

• 适用场景：需要更细粒度的观测、ACL、限速、HTTP 管理页面等。

• 注意点：VNC 为二进制 RFB，建议以 TCP 模式 代理，不做 HTTP 解析；如需会话保持，使用 balance source。

• 核心配置（/etc/haproxy/haproxy.cfg 片段）

  • global
    • log /dev/log local0
    • maxconn 4096
  • defaults
    • mode tcp
    • timeout connect 10s
    • timeout client 1m
    • timeout server 1m
  • frontend vnc-in
    • bind *:5901
    • default_backend vnc-backend
  • backend vnc-backend
    • balance source # 会话保持（源地址哈希）
    • server node1 192.168.10.11:5901 check
    • server node2 192.168.10.12:5901 check
    • server node3 192.168.10.13:5901 check

• 运维要点

  • 为每个桌面端口（5901/5902/…）各建一个 frontend/backend，或在前端用 ACL 按端口分发。
  • 启用统计页面（stats enable）便于观察连接数与健康状态。
  • 防火墙放行 5901–5903/tcp。
    该方式利用 HAProxy 的 TCP 转发与健康检查 能力，适合在已有 HAProxy 体系内快速接入 VNC。

方案三 云上弹性负载均衡 ELB（免自建，快速上线）

• 适用场景：在公有云上运行 VNC 接入层，追求快速交付与高可用。
• 做法：创建 四层（TCP）负载均衡器，前端监听 5901–5903，后端绑定多个 登录/桌面节点；开启 会话保持（源 IP） 与健康检查。
• 优势：多实例多可用区容灾、规格可选、访问日志与监控完善；部分云厂商的远程登录（VNC）支持 一次性 Token URL，便于安全接入与审计。
• 提示：VNC 会话粘滞依赖 源 IP 会话保持；若客户端经过 NAT，需确认云厂商对源地址的处理策略（必要时使用代理协议或应用层会话绑定）。

会话保持与调度策略建议

• 调度算法：
  • 最少连接（leastconn）：更适合长连接、连接时长差异大的 VNC 场景。
  • 加权最少连接：节点性能不均时更优。
  • 源地址哈希（source/IP Hash）：实现会话粘滞，避免同一用户被调度到不同后端。
• 健康检查：
  • LVS/HAProxy 对 5901/5902… 做 TCP 探活；失败即摘除，恢复后自动回切。
• 会话粘滞与中断最小化：
  • 尽量让用户在同一 桌面号（:1/:2） 上持续工作；若需迁移，先通知用户或设计“排队/预留”机制。
• 连接数均衡的进阶做法：
  • 在调度器中引入“最小 VNC 连接数优先 + CPU/内存阈值”的策略，避免把新桌面创建到看似空闲但资源紧张的节点；阈值可设为 90% 等经验值，超过则告警或跳过该节点。
    上述策略与“最小连接数优先 + 性能阈值”的方法在工业实践中被证明能有效均衡 VNC 登录节点的负载并降低过载风险。

快速验证与排障清单

• 连接分发：ipvsadm -ln（LVS）、HAProxy stats 页面、云 ELB 监控，确认后端 Up 且连接数分布合理。
• 会话保持：同一客户端多次重连 VIP:端口，应落到同一后端（使用 source/IP Hash 时）。
• 健康检查：停掉某后端 VNC 服务，观察是否在超时后自动摘除；恢复后自动回切。
• 防火墙与安全组：放行 5901–5903/tcp；云上注意 安全组 与 NACL 规则。
• 端口规划：统一约定 桌面号与端口映射（:1→5901，:2→5902），避免冲突与运维混乱。
• 性能与容量：关注 并发连接数、CPU/内存；必要时增加后端或调整权重/算法。