做运维这些年亲手搭过不下十套 Web 集群但每次给团队讲高可用架构我仍然会把 LVSKeepalivedNFS 这套组合拿出来当第一课。原因很简单它没有 Kubernetes 那么重也没有单台 Nginx 那么脆而且一旦把这三样东西吃透后面再去理解任何负载均衡、会话保持、共享存储方案都会顺很多。这套方案的最终形态是——一组 Web 服务器共同对外提供服务用户访问同一个虚拟 IP前端节点异常时心跳机制自动把虚拟 IP 切走后端文件不落在任何一台服务器的本地磁盘而是统一放在 NFS 共享目录上。对大多数企业内部系统、门户网站、中小规模应用来说这个组合的性价比和可控性都相当高也是面试和方案评审里出现频率极高的一套底层架构。接下来我按自己的实际部署经验从方案选型、环境规划、LVS 配置、Keepalived 冗余、NFS 共享存储到故障演练完整走一遍过程。全程用最小可复现的虚拟机组演示每一步都写清原因和参数来源尤其是那些手册里不会写、但你上线后一定会踩的坑。1. 为什么我会选 LVSKeepalivedNFS 这套组合1.1 高可用方案不止一种先捋清楚需求很多人一提高可用就想到 Kubernetes但真实业务里并不是所有场景都需要容器编排。我见过太多团队为了追新把一套每天几千访问的内部系统硬塞进 K8s结果运维成本和故障率双双上升。如果你的需求是Web 服务不能因为单台机器宕机而中断文件需要多台服务器共享团队运维能力有限需要方案简单可见那 LVSKeepalivedNFS 几乎是量身定做的。这套架构实际上解决的是三个不同层面问题接入高可用、服务高可用、数据一致性。LVS 负责流量分发Keepalived 负责检测和切换NFS 负责让每台 Web 服务器读到同一份文件。三层各管一件事互不干扰出了问题也能快速定位。1.2 LVS、Keepalived、NFS 各自承担什么角色先给完全没接触过的读者把三个角色拆开讲。LVSLinux Virtual Server跑在 Linux 内核里工作在第四层也就是传输层。它能把到达虚拟 IP 的 TCP/UDP 流量按调度算法转发给后端真实服务器。跟 Nginx 的七层负载均衡相比LVS 不解析 HTTP 内容只处理 IP端口级别的转发所以性能极高转发延迟很小吞吐量可以做到几十万并发也没有太大压力。Keepalived 最初就是为 LVS 设计的它通过 VRRP 协议实现虚拟 IP 的漂移。简单说集群里有一台主节点和若干台备用节点正常情况下虚拟 IP 绑在主节点上主节点心跳丢失后备用节点抢占这个 IP继续对外提供服务。它还会定期执行健康检查脚本如果发现某台后端服务器已经不可用就把它从 LVS 转发列表里摘掉。NFSNetwork File System解决的是 Web 集群最常见的痛点用户上传的图片、程序部署代码、Session 文件、日志文件如果落在每台服务器本地负载均衡请求分散到不同机器后就会出现文件在这台上传的另外一台读不到的诡异问题。NFS 把一台存储服务器上的目录通过网络挂载到所有 Web 服务器上大家读写同一份文件这些问题自然消失。1.3 为什么不直接用 Nginx 负载均衡就够了这是我在方案评审时被问最多的问题。Nginx 做负载均衡当然可以而且配置很简洁upstream backend { server 192.168.10.11 weight2; server 192.168.10.12 weight1; } server { listen 80; location / { proxy_pass http://backend; } }但这里有几个现实问题。首先Nginx 工作在七层需要解析 HTTP 报文CPU 开销明显高于纯内核态的 LVS。其次Nginx 本身也是一个单点你依然需要再为 Nginx 做 Keepalived 或别的冗余方案。更重要的是如果后端有 WebSocket、TCP 长连接这类业务Nginx 的配置复杂度会迅速上升。而 LVS 天然支持四层协议什么 TCP 业务都能转发无需关心应用层细节。Nginx 不是不能用它更适合做网关、做 SSL 终结、做基于 URL 的精细分发。但在高可用 高性能 高稳定这个组合要求下LVS 作为入口Nginx 作为 Web 服务进程是更合理的分工。我后来很多生产环境就是 LVS 在前、Nginx 在后只在需要特殊路由规则时才加一层 Nginx 网关。2. 动手前的环境规划IP、软件版本、拓扑2.1 规划一个最小可复现的集群我经常跟学员强调一句话任何高可用架构先画 IP 表再动手装系统。很多部署问题最后都演变成 IP 混乱问题。下面是最小化的三节点架构一共五台虚机但在验证阶段可以先只上三台核心节点把 NFS 和备用 Director 放在同一台机器上先跑通流程。这次演示我准备了四台机器全部使用 Rocky Linux 9内核自带 LVS 和 NFS 相关模块不需要额外编译。角色主机名IP 地址说明LVS 主节点lvs-master192.168.10.10绑定 VIP 192.168.10.100LVS 备用节点lvs-backup192.168.10.20主节点故障时接管 VIPWeb 节点 1web01192.168.10.11运行 Nginx挂载 NFSWeb 节点 2web02192.168.10.12运行 Nginx挂载 NFSNFS 存储节点nfs-server192.168.10.30提供共享目录 /data/www这里需要说明为什么 VIP 选择 192.168.10.100 而不是直接用某个节点的 IP。VIP 是逻辑地址它不属于任何一台物理服务器由 Keepalived 动态绑定到当前活跃的 Director 上。客户端和 Web 服务器都只认识这个 IP切换过程对两端透明。2.2 三台虚机怎么分角色很多人会把所有组件装在同一台机器上测试这没有问题但生产至少需要把 NFS 独立出来因为 NFS 的磁盘 IO 和网络 IO 都比较重跟 LVS 混跑会互相影响。建议的部署顺序是先装 NFS再装两台 Web最后装 LVS 主备节点。原因很直接——LVS 的转发目标是 Web 节点Web 节点需要挂载 NFS 目录才能读写数据依赖方向是从后往前。如果把 LVS 先装好后端还没准备好Keepalived 健康检查会一直报警干扰排查。全部节点系统装好后第一步不是配置任何服务而是确认基础环境三件事时间同步、防火墙放行、SELinux 状态。2.3 开始前的坑时间同步、防火墙、SELinux时间同步被很多人忽略但对高可用集群来说非常关键。Keepalived 的日志时间戳、LVS 的连接跟踪、NFS 文件的时间戳全部依赖系统时间。如果两台 Director 时间差超过几秒主备切换时可能出现两边都认为自己是主的脑裂窗口。统一用 chrony 同步dnf install -y chrony systemctl enable --now chronyd chronyc sources -v防火墙方面LVS 的 VIP 和 VRRP 协议需要放行。VRRP 默认使用组播地址 224.0.0.18协议号是 112。Rocky Linux 9 默认 firewalld 比较严格最少要放行这些firewall-cmd --permanent --add-protocolvrrp firewall-cmd --permanent --add-port80/tcp firewall-cmd --permanent --add-port2049/tcp firewall-cmd --reloadSELinux 建议先临时设为 Permissive排除它对 NFS 挂载和 LVS 转发的干扰。当然我不建议直接 disabled因为生产环境还是需要 SELinux 兜底的。等整套架构跑通后再针对 NFS 和 httpd 放开对应布尔值setsebool -P httpd_use_nfs 1 setsebool -P httpd_read_user_content 1这一步很多人不做结果 Nginx 能启动但读不了 NFS 上的文件日志里全是 Permission denied排查半天泪流满面。3. LVS 核心配置DR 模式的完整落地3.1 为什么生产环境我默认选 DR 而不是 NAT/TUNLVS 有三种转发模式NAT、TUN、DR。NAT 模式下请求和响应都经过 Director后端服务器的网关要指到 DirectorTUN 模式需要后端支持 IP 隧道DR 模式下Director 只处理入站请求响应由各 Web 节点直接回给客户端。大多数生产环境我推荐 DR 模式核心原因是响应流量不进 Director。Web 场景里响应体往往远大于请求体比如一个页面几百 KB请求只有几 KB。如果用 NATDirector 要承担全部双向流量很快成为瓶颈。DR 模式下 Director 的负载非常轻只做 TCP 层的转发决策。代价是后端 Web 节点必须和 Director 在同一二层网络且要处理 VIP 的 ARP 响应问题稍后再展开。TUN 模式理论上可以跨网段但 IP 隧道封装有额外开销而且很多云厂商网络环境会过滤 IPIP 协议所以除非特殊场景我基本不碰。3.2 Director 上配置 LVS 的完整步骤Rocky Linux 9 没有像 CentOS 7 那样的 ipvsadm 服务脚本手动配置或者用 Keepalived 托管都可以。既然最终要上 Keepalived我建议生产环境把 LVS 规则直接写进 Keepalived 配置里由它负责加载。但为了先验证 LVS 本身我们先用手动命令把转发链路打通。第一步装上 ipvsadm 管理工具dnf install -y ipvsadm第二步在 Director 上配置虚拟 IP。DR 模式下 VIP 绑定在 lo 接口的别名上但这里先不手动绑定因为下一步 Keepalived 会自动配置。如果只用手动方式测试可以用ip addr add 192.168.10.100/32 dev eth0注意掩码是 32不能写成 24否则会改变接口的路由行为产生诡异网络问题。第三步添加 LVS 转发规则ipvsadm -A -t 192.168.10.100:80 -s rr ipvsadm -a -t 192.168.10.100:80 -r 192.168.10.11:80 -g ipvsadm -a -t 192.168.10.100:80 -r 192.168.10.12:80 -g-s rr表示轮询调度-g表示 DR 模式。先手动验证时我常用 rr够直观生产环境我会换-s wrr或者lc最少连接因为后端机器性能不一定完全相同。看配置ipvsadm -Ln你会看到 VIP 下挂了两台后端服务器状态全是 Active。如果此时从客户端curl http://192.168.10.100后端还没配置好 ARP 抑制和 VIP 响应大概率是不通的所以下一步必须做。3.3 后端 Web 服务器上的 ARP 抑制设置这是整套架构里最容易失败的一步。DR 模式下VIP 同时配置在 Director 和所有 Web 节点的 lo 接口上但对外必须只有 Director 响应 VIP 的 ARP 请求。如果不做抑制Web 节点也宣称自己拥有 VIP客户端 ARP 表会混乱直接导致负载均衡失效甚至整个网段网络抖动。先说 VIP 在 Web 节点上的配置。在 web01 和 web02 上执行ip addr add 192.168.10.100/32 dev lo然后修改 ARP 内核参数。新建/etc/sysctl.d/99-lvs-dr.confnet.ipv4.conf.all.arp_ignore 1 net.ipv4.conf.all.arp_announce 2 net.ipv4.conf.lo.arp_ignore 1 net.ipv4.conf.lo.arp_announce 2立即生效sysctl -p /etc/sysctl.d/99-lvs-dr.conf这两个参数的含义arp_ignore1表示只有目标 IP 是本机接口上的 IP 时才响应 ARP 请求arp_announce2表示不主动通告那些不属于本接口的 IP 地址。简单理解就是Web 节点对 VIP 的请求一律闭嘴但收到发往 VIP 的数据包时仍然正常处理。如果不做这步现象非常典型客户端 curl VIP 有时通、有时不通arp -n看到 VIP 对应多个 MAC 地址流量随机跑到后端但后端又没绑 VIP 的 socket连接直接 reset。我见过很多人在这一步卡了一整天最后定位到是 ARP 问题。3.4 手动测试转发链路先别急着上 Keepalived配置完 ARP 抑制后在客户端访问 VIPcurl -I http://192.168.10.100正常情况下会看到 Nginx 的响应头。因为是轮询模式连续访问多次会把请求交替打到 web01 和 web02。看后端日志确认tail -f /var/log/nginx/access.log如果能看到 192.168.10.10 的地址代表访问来自 Director。手动验证通过后ipvsadm -Ln --stats可以看到总连接数和每个后端的转发包统计。这里有个小技巧访问一次后立刻看ipvsadm -Ln --stats转发包数为 0 说明数据包根本没到 Director多半是 VIP 或路由问题转发包数正常但后端日志没记录多半是 ARP 抑制或后端防火墙问题。4. Keepalived 接管 VIP 漂移与健康检查4.1 Keepalived 的作用不是高可用而是探测 漂移很多人以为装了 Keepalived 就等于高可用这是误解。Keepalived 只负责三件事定期间发 VRRP 心跳、根据优先级决定谁持有 VIP、调用健康检查脚本决定是否摘除故障后端或切换主备。真正的高可用效果是这三件事组合出来的。在实际架构里我让 Keepalived 同时管理 VIP 和 LVS 规则。这样当主节点故障时备用节点不光漂移 VIP还会自动加载完整的 ipvsadm 规则保证后端转发配置一致。4.2 主备配置文件的差异与同步项在 lvs-master 和 lvs-backup 上都安装 Keepaliveddnf install -y keepalived主节点配置文件/etc/keepalived/keepalived.conf如下global_defs { router_id LVS_MASTER vrrp_skip_check_adv_addr script_user root enable_script_security } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 150 advert_int 1 authentication { auth_type PASS auth_pass 123456 } virtual_ipaddress { 192.168.10.100/24 dev eth0 label eth0:1 } } virtual_server 192.168.10.100 80 { delay_loop 10 lb_algo wrr lb_kind DR protocol TCP real_server 192.168.10.11 80 { weight 1 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 2 } } real_server 192.168.10.12 80 { weight 1 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 2 } } }备用节点只需要改三处router_id改为LVS_BACKUPstate改为BACKUPpriority改为 100其他完全一致。这里要说明virtual_router_id必须是唯一的同一网段里如果有多套 Keepalived 集群这个 ID 不能冲突否则 VRRP 消息会互相干扰。4.3 健康检查脚本怎么写才靠谱Keepalived 自带的 TCP_CHECK 只能判断后端 80 端口是否可连接但对 Web 应用来说端口通不代表服务正常。比如 Nginx 进程卡死、PHP-FPM 假死、连接积压到不响应新请求端口检查全部通过用户却已经无法访问了。所以我通常不用内置 TCP_CHECK而是写一个脚本来做应用层探测#!/bin/bash # /etc/keepalived/check_web.sh curl -s -o /dev/null -w %{http_code} --connect-timeout 5 --max-time 10 http://127.0.0.1/ 2/dev/null | grep -E 200|301|302脚本返回值是 0 表示服务正常非 0 表示异常。然后在 real_server 里用 MISC_CHECK 调用real_server 192.168.10.11 80 { weight 1 MISC_CHECK { misc_path /etc/keepalived/check_web.sh misc_timeout 10 misc_dynamic } }健康检查脚本还有个容易被忽略的细节点脚本里访问的是 127.0.0.1 还是 VIP。在 DR 模式下后端节点上虽然绑定着 VIP但通常只有 Nginx 监听 80 端口没有特别绑定 VIP访问 127.0.0.1 即可准确反映本机服务状态。如果写curl http://192.168.10.100反而可能因为 ARP 抑制而路径不清晰造成误判。4.4 故障切换触发条件别只检查端口只检测 Web 服务是否正常是不够的。如果 Director 本身网卡故障、内核模块异常、或者到后端的路由出了问题Keepalived 不会自动切换因为 VRRP 心跳还在走。生产环境我建议在健康检查脚本里增加一个额外的自检能力——比如检查 ipvsadm 规则是否还在if ! ipvsadm -Ln | grep -q 192.168.10.100:80; then exit 1 fi当脚本返回非 0 时Keeplaived 不仅会摘除这台 real_server还可以触发自身降优先级把 VIP 让给备用节点。实现方式是在脚本异常时主动停止 keepalived 或者执行killall keepalived这样备用 Director 会立即抢占 VIP整个集群入口完成切换。这个设计听起来简单但没有做过故障演练的人很难想象它的价值——我遇到过真实事故网卡物理故障导致 VRRP 还在跑但转发已经断了用户访问全部超时急救时才发现切换条件设计得太窄。5. NFS 共享存储让每台 Web 都看到同一份文件5.1 Web 集群为什么要共享存储先描述一个没有 NFS 的典型问题。用户上传了一张头像请求被 LVS 分配到 web01文件写在 web01 本地。下一次刷新请求被分到 web02web02 的站点目录里没有这张头像直接 404。这类问题在单机环境下不存在但一旦做负载均衡就必然暴露。更严重的是程序部署的不一致。你更新代码时只 push 到一台服务器另一台还是旧版本用户在不同请求之间体验完全不一致。用 NFS 把整个 Web 根目录共享出去后所有节点读同一份文件部署一次全部生效这也顺带省去了每次发布后同步文件的操作。5.2 exports 配置与权限设计NFS 安装在 nfs-server 上dnf install -y nfs-utils systemctl enable --now nfs-server共享目录选择/data/www注意这个目录的属主要是 nfsnobody 或者某个固定 UID否则 Web 节点写文件时权限会错乱。推荐做法是统一使用一个 UID比如用 nginxmkdir -p /data/www chown nginx:nginx /data/www编辑/etc/exports/data/www 192.168.10.0/24(rw,sync,no_root_squash,no_subtree_check)导出并查看exportfs -rav showmount -e localhost几个参数里最要紧的是sync。很多教程建议用async提升性能但这是拿可靠性换的。async模式下 NFS 先响应写请求再异步落盘服务器突然断电时客户端告诉用户写入成功但实际数据丢了。对业务数据我坚决用sync。no_root_squash允许 root 保留权限如果你没有特殊需求可以不加默认的 root_squash 更安全但 Web 程序如果需要以 root 身份操作共享文件就会遇到权限问题需要在安全和便利之间权衡。5.3 客户端挂载与开机自动挂载两台 Web 节点安装客户端dnf install -y nfs-utils mount -t nfs 192.168.10.30:/data/www /usr/share/nginx/html查看是否挂载成功df -h | grep nfs这里注意Nginx 的默认站点目录在/usr/share/nginx/html直接把它作为挂载点是很多人的选择但其实生产环境我建议把 Nginx 站点目录独立出来比如/data/webroot别和 RPM 包默认目录混在一起否则升级 Nginx 时容易误清数据。开机自动挂载需要写进/etc/fstab192.168.10.30:/data/www /usr/share/nginx/html nfs defaults,_netdev,noatime,nolock 0 0_netdev表示网络设备在 network 就绪后再挂载防止开机时网络没起来导致挂载失败卡住启动流程。nolock用于兼容部分场景如果你确认不需要文件锁服务可以加上有些环境不加反而有 lockd 服务冲突的问题。5.4 NFS 性能与稳定性sync、no_root_squash 的权衡NFS 最大的争议点在于性能。我见过不少团队因为 NFS 太慢而质疑整套架构。真实情况是大部分慢的问题出在默认参数上尤其是 mount 选项里没加noatime。文件系统每次读都会更新访问时间戳NFS 的每次更新都是一次网络往返在高频读的场景下延迟被放大得非常明显。所以noatime几乎是必加的。另外要确认 NFS 服务端开启了足够数量的线程。在高并发写入场景下默认的 8 个 nfsd 线程可能不够可以调大/etc/nfs.conf里的rpc-nfsd-count到 16 或 32然后重启systemctl restart nfs-server最后还要提醒一句连接跟踪和端口问题。NFSv4 只需要 2049 端口如果 NFSv3 需要额外开 111、20048 等端口写防火墙规则时容易漏我统一建议只用 NFSv4配置里加上/data/www 192.168.10.0/24(rw,sync,no_root_squash,no_subtree_check,vers4)加上vers4可以避免客户端自动协商到旧版本减少开放端口数量安全性和稳定性都有提升。6. 高可用验证从简单 ping 到模拟故障切换6.1 第一步验证VIP、LVS 转发、NFS 挂载整套架构配置完成后先别急着上压力按照从下到上的顺序做基础验证。在客户端机器上ping 192.168.10.100确认 VIP 能通。在 lvs-master 上执行ip addr show eth0:1确认 VIP 绑在 eth0 上。查看ipvsadm -Ln确认转发规则已经由 Keepalived 写入了内核。在 web01 和 web02 上df -h确认 NFS 挂载点都在。在 nfs-server 上/data/www下创建测试文件echo hi /data/www/test.html两台 Web 节点都能通过curl http://127.0.0.1/test.html访问到。这一步最容易发现的问题是VIP 通了但 curl 80 端口不通。先别怀疑 iptables多半是 Web 节点没监听 0.0.0.0:80或者 Nginx 配置文件里 root 指向的目录因为 NFS 挂载失败变成了空目录访问直接 403。6.2 第二步验证手动杀掉 keepalived 主节点高可用切换验证是核心中的核心。在 lvs-master 上停掉 Keepalivedsystemctl stop keepalived此时观察 lvs-backup 上的日志tail -f /var/log/messages正常情况下几秒内会出现类似 Entering MASTER STATE 的日志然后在 backup 节点上查看 IPip addr show eth0:1看到 VIP 已经漂移到 backup 上之后马上从客户端访问curl -I http://192.168.10.100业务不断这是最基本的标准。同时确认ipvsadm -Ln里的转发规则也存在因为 Keepalived 配置里的 virtual_server 段会自动重构规则。这个流程我建议至少演练三次包括优雅停止、kill -9、直接拔虚拟网卡三种方式。拔网卡的测试最真实因为 VRRP 心跳会先丢失备用节点抢占 VIP但 LVS 规则能否正确加载取决于配置里的健康检查状态如果你的健康检查脚本有问题这个场景一定会暴露。6.3 第三步验证停掉 Nginx 服务主备切换验证完还要验证 Keepalived 能否感知后端节点故障。在 web01 上systemctl stop nginx然后在 lvs-master 上观察ipvsadm -Ln等待健康检查周期配置里 delay_loop 是 10 秒内web01 的状态会从 Active 变成 Failed并从后端列表里摘除。此时从客户端持续访问所有流量都落到 web02用户侧无感知。要注意一个细节Keepalived 摘除的是后端节点不是 VIP 漂移。也就是说只要 Director 节点健康即使只剩一台 Web 存活访问依然有响应。把 Nginx 恢复后web01 会在下一个健康检查周期被自动加回来。6.4 第四步验证压测与连接状态检查基础功能和切换验证都通过后我习惯再用 ab 或 wrk 跑一轮短压测同时盯三个指标请求失败率。ab 的 failed requests 必须为 0。各后端连接数是否均匀。看ipvsadm -Ln --stats -n每个 real server 的 ActiveConn 差额。NFS 服务端的 IO 是否异常偏高。iostat -x 1关注 util 是否持续接近 100%。举个例子压测命令wrk -t4 -c200 -d60s http://192.168.10.100/跑完后看ipvsadm -Ln --stats如果 web01 和 web02 的转发包数量几乎一样说明 rr/wrr 调度正常。如果某一台数量明显偏多检查健康检查脚本是不是把另一台误判成故障了或者 weight 设置不对。压测阶段我经常发现 TCP_CHECK 会把慢响应误判为超时导致所有流量倒到另外一台改用 MISC_CHECK 后恢复正常这也是压测才能看出来的隐性坑。7. 运行半年之后的一些总结这套架构投入生产之后我最大的体会是高可用不是装完就完事而是持续维护的结果。Keepalived 的日志要看、健康检查脚本要定期测试、NFS 剩余空间要监控尤其是 NFS 挂载断开的场景——网络抖动时 Web 节点可能变成哑状态TCP 连接正常但文件全部读不到。我当时加了一个监控脚本每隔一分钟在挂载点目录写入一个心跳文件然后删除一旦失败立即告警这个思路分享给大家。另一个真实经验是不要把 VIP 的掩码配成 24。Keeplaived 配置里我写的是192.168.10.100/24 dev eth0 label eth0:1这个 24 与普通接口的掩码含义不同直接决定 VIP 是否参与 ARP 通告。如果你写成 32某些网络环境下客户端路由表会认为 VIP 不可达表现为外部能 ping 通但 TCP 连接超时。这种边界参数的问题只有实际搭建时才会记住所以我建议所有想掌握这套架构的人都亲手完整建一遍。最后再分享一个小技巧把所有配置文件和安装命令写成一个简单的自动化脚本用 Ansible 或者 bash 都行。这样不仅方便复现环境更重要的是当故障出现在两年后时你还能精准知道当初每一步到底做了什么。高可用系统的终极目标不是预防所有故障而是当故障发生时你能够快速、准确地把它切换掉并且在事后找到根因。LVSKeepalivedNFS 这套组合之所以经典就是因为它把所有关键路径都暴露在你能看见、能控制的位置而不是封装在黑盒里。