以太网高可用方案：网络架构、IP规划与Keepalived VIP漂移实录-北京尧图网络

前几天还有个朋友问我说他们内网系统要做高可用是不是必须得上一台硬件负载均衡设备我跟他讲很多时候不用那么折腾传统的Ethernet以太网加上合理的IP规划和VIP虚拟IP方案就能把故障切换这件事做得非常漂亮。今天把这个工程项目的完整思路和实操记录整理一下从网络架构设计、IP地址规划到Keepalived实现VIP漂移再到验收和踩坑一步不落都捋清楚。这篇内容适合网络运维工程师、项目实施人员也适合那些对服务器高可用方案有需求但不想一上来就堆设备的团队参考。1. 项目背景与方案选型背后的逻辑1.1 这个工程项目到底要解决什么问题项目背景是一家传统企业自建机房里面跑了几个核心业务系统对外提供Web服务和API接口。业务方提了一个很明确的要求系统不能被单点故障拖死任何时候一台服务器宕机了客户端无感知业务继续跑。这个需求听起来不复杂但落到工程上涉及的不只是服务器层面还牵扯到交换机、IP设计、接入层架构。我接手的时候先做了一次现状摸底。机房里有两台应用服务器配置完全一致跑着同一个服务但彼此各自独立前端没有任何调度入口。如果一台机器挂了另一个虽然活着客户端也不知道怎么切过去因为DNS解析指向的是某一台固定的心跳地址。这其实是很多小机房的通病——服务器有冗余网络的接入模型却还是单点。整个项目的核心目标可以拆成三点第一网络链路要冗余交换机层不能一台宕机就全断第二IP入口要虚拟化对外只暴露一个VIP后端随便怎么切换客户端不用改配置第三故障检测和切换必须自动化不能等着人半夜爬起来拔网线。1.2 为什么定下以太网静态IPVIP的组合当时做方案对比的时候旁边有人提议上硬件负载均衡设备也有人提上K8s做容器化。但结合这个项目的实际情况这两个方案都被否掉了。硬件负载均衡性能确实强但采购周期长预算也高而且这台设备自身又变成了新的单点还得再给它做双机成本直接翻倍。K8s则太重了现有的业务是传统Java应用改造工作量很大运维团队也没搞过容器上线风险不可控。最后定下来的方案是沿用机房里成熟的Ethernet以太网架构在二层网络里划分VLAN隔离广播域服务器侧全部配置静态IP再通过VRRP协议配合Keepalived软件把VIP挂到两台服务器上。这套组合的优势就在于轻量、可控、不依赖额外硬件。以太网本身就是机房里的基础设施静态IP保证了网络行为的可预测性VIP则让整个故障切换过程对客户端完全透明。说白了就是用软件协议层面的设计去补硬件架构上的单点问题。这套方案还有一个更隐性的好处便于排障。整个链路从交换机端口到服务器网卡再到VIP每一层的IP都是固定且可查的。出了问题ping、telnet、抓包每一步都能定位不用像在容器网络里那样还要翻overlay的转发路径。2. 网络架构设计与IP地址规划实操2.1 网段划分业务、管理、备份要分开IP规划是整个项目里最不起眼、但后期影响最大的部分。很多工程出问题回头看都是因为一开始图省事把所有设备塞进一个大网段里。这个项目我坚持把网段拆成三块业务网段、管理网段、备份/互联网段。业务网段专门承载客户端访问服务器的流量这个段的IP要稳定、简洁方便做防火墙规则和审计。管理网段则是给运维人员SSH登录服务器、登录交换机用的和业务流量物理或者逻辑隔离避免有人在机房里乱敲命令的时候把业务影响到了。备份网段是给服务器之间传数据用的比如数据库同步、日志收集这种流量通常比较大和业务共用网段容易抢占带宽。实际的分配可以参考下面这个表网段用途网段地址子网掩码说明业务网段192.168.10.0255.255.255.0客户端访问入口与服务器业务地址管理网段192.168.20.0255.255.255.0运维SSH登录、带外管理备份/互联网段192.168.30.0255.255.255.0服务器间数据同步、心跳线用办公室来类比的话业务网段就像是对外接待客户的会客厅管理网段是员工走的后门备份网段则是仓库和仓库之间的货梯。三者各走各的互相不添乱出了事也容易查清楚到底是哪个门出了问题。2.2 子网掩码与可用地址计算规划网段的时候掩码的选择特别关键。很多人直接无脑用24位掩码也就是255.255.255.0但其实要根据实际设备数量来算。我这次三个网段都用了24位掩码是因为每个网段里的设备数量不会超过50台254个可用地址绰绰有余多出来的空间还能应付未来的扩容。掩码的计算逻辑并不复杂。24位掩码意味着网络位占24位主机位占8位可用地址数是2的8次方减2也就是254个。为什么要减2因为每个网段里主机位全0的地址代表网络号全1的地址代表广播地址这两个地址是不能分配给设备用的。举个例子业务网段192.168.10.0/24网络号就是192.168.10.0广播地址是192.168.10.255真正能用的地址从192.168.10.1到192.168.10.254。但实际配置的时候还有一个隐形规则要注意网关地址通常用网段的第一个或第二个可用地址方便记忆和排错。我习惯把网关设在192.168.10.1VIP设在192.168.10.100这样的中间段一眼看过去就知道这个是虚拟地址不落在一台具体的物理机上。2.3 VLAN划分与交换机端口规划二层交换机这边我先把VLAN规划好。每个网段对应一个独立的VLAN这样可以避免广播风暴在整个机房泛滥也能让不同业务的二层域互相隔离。交换机上创建VLAN其实很简单关键是端口要分对。连接服务器的端口设置成access模式归属于业务VLAN连接核心交换机的上联口设置成trunk模式放行业务VLAN和管理VLAN这样才能跨交换机传递。项目里用了两台接入交换机做冗余两台服务器分别接到不同的交换机上。这样做是为了避免出现服务器挂了有备用但备用接的那台交换机也挂了这种双重故障。端口规划的时候我专门做了个表格记录每个端口接的是哪台设备、属于哪个VLAN、端口速率要求是什么。这个表格后面验收的时候非常有用出了故障不看它光靠记忆排查效率会低很多。交换机上的VLAN配置思路大致是创建VLAN 10、20、30分别命名business、manage、backup。接服务器的端口划入对应的VLAN设置access模式。交换机互连端口设置trunk模式放行业务VLAN和管理VLAN。在三层交换机上为每个VLAN配置网关接口地址作为各网段的网关。3. 以太网基础配置与关键参数详解3.1 Linux服务器网卡配置实操服务器操作系统是Linux这个项目里网络配置我全走了静态IP。为什么不用DHCP因为服务器承担的是核心业务IP地址必须稳定可控DHCP租约一到期地址变了整个网络就乱了。静态IP虽然配置起来麻烦一点但一劳永逸。以第一台服务器为例它的业务网卡配置是这样的# 进入网络配置目录 cd /etc/sysconfig/network-scripts/# ifcfg-eth0 内容 DEVICEeth0 BOOTPROTOnone ONBOOTyes IPADDR192.168.10.11 NETMASK255.255.255.0 GATEWAY192.168.10.1DEVICE指定网卡设备名BOOTPROTO设为none表示不自动获取地址ONBOOT设为yes表示开机自启。IPADDR就是这台服务器在业务网段里的固定地址。这里特意说一下服务器的业务地址我用的是192.168.10.11和192.168.10.12预留了.2到.10这一段方便以后加设备。第二台服务器的配置完全一样只是IPADDR改成192.168.10.12。配置完成后要执行systemctl restart network或者用nmcli connection reload让配置生效。生效后别急着往下走先确认一下网卡状态和IP是否真的设置成功。用ip addr show eth0看IP用ip route show查默认路由是否指向网关。我遇到过明明配了网关但重启后路由没起来的情况大概率是配置文件里GATEWAY写错了网段或者ONBOOT没设成yes。3.2 交换机侧联调与连通性检查服务器配置完成后就要从交换机那边验证链路通不通。排查顺序有个讲究从物理层开始一层一层往上查。先看交换机端口状态是不是Up如果端口是Down那可能是网线问题、电口协商失败或者对端设备网卡没起来。端口正常后ping一下网关地址确认三层通不通。实际联调过程中我经常碰到一种情况端口状态是Up的但ping不通。这时候第一反应不是去怀疑IP配置而是去看VLAN有没有划对。如果服务器所属的VLAN和交换机端口不一致二层帧根本不会被正确转发三层自然不通。还有一个容易被忽视的问题是接口速率协商。如果交换机端口是自适应模式而服务器网卡被强制设置成了千兆双工两边协商结果可能变成百兆甚至速率不匹配导致丢包严重。这个项目里我全部保持默认协商遇到个别网卡驱动老旧的服务器才手动指定速率。排查链路问题的时候可以先用ethtool eth0查看网卡当前协商到的速率和双工模式避免走弯路。3.3 网关冗余与路由设计的坑单网关是很多小网络的高可用盲区。如果所有服务器的默认网关都指向同一个三层交换机地址那这台交换机就成了一个隐藏的单点。虽然这个项目因为预算原因没有在主备交换机上做网关热备但我在路由设计上做了一个补救业务网关放在主交换机的VLAN接口上同时管理网段的网关放在了备交换机上这样两边都有活干不至于一台交换机全扛。默认路由别瞎配。服务器只需要一条默认路由指向网关就够用了不要添加多余的路由条目尤其是不要手写指向对端服务器的路由。我在做备份网段同步流量优化的时候发现有人在服务器上加了一条route add -net 192.168.30.0/24 gw 192.168.10.1看起来没什么问题但由于备份网段的物理链路是独立走线的这条静态路由反而把备份流量引到了错误的路径上导致数据同步走了三层转发性能差了一大截。4. VIP虚拟IP方案落地全过程4.1 VIP的工作原理从VRRP说起VIP虚拟IP是整个高可用方案的核心但很多人对它只有个模糊的概念以为就是两个机器配同一个IP。实际远没那么简单。两台机器如果直接配相同IP网络就会冲突交换机的MAC表会反复抖动谁也访问不了。真正让VIP起作用的是VRRP协议。VRRP的全称是虚拟路由冗余协议它做的事情是一群设备组建成一个虚拟组这个组对外共用一个虚拟IP组内通过优先级选举出一个Master节点其他都是Backup。Master正常工作时VIP的流量全部由它处理一旦Master宕机或者链路故障Backup节点会在几秒钟内接管VIP同时发一个免费ARP报文告诉交换机现在这个IP对应的MAC地址换成我的了。整个过程对客户端是完全透明的。用生活化一点的方式理解VIP就像是一个前台的共用工牌。谁今天值班工牌就挂在谁胸前。客人进来只认工牌不认人前台值班的人换了也不影响接待。VRRP协议就是负责判断谁该挂工牌以及什么时候换人挂的那套规则。4.2 Keepalived核心配置实例项目里我用Keepalived来落地VRRP协议。Keepalived不仅实现了VIP漂移还能监控后端服务的存活状态服务挂了对端才接管的才是真正的高可用。它最核心的配置文件是/etc/keepalived/keepalived.conf。下面是主服务器的配置我加了详细的注释global_defs { notification_email { adminlocaldomain } router_id LVS_MASTER_01 } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 150 advert_int 1 authentication { auth_type PASS auth_pass 123456 } unicast_peer { 192.168.10.12 } virtual_ipaddress { 192.168.10.100/24 dev eth0 label eth0:0 } }备服务器的配置大体一样只有一个关键参数不同state改成BACKUPpriority改成100。priority的值直接决定了谁会成为VIP的持有者数值越大优先级越高。这里有个细节priority的差值我特意设成了50目的是让主备差异足够明显避免出现两个节点互相争抢VIP的震荡情况。还有一个参数要注意advert_int。它是VRRP通告报文的发送间隔单位是秒。我设置的是1秒也就是说主节点每隔1秒钟广播一次我还活着。这个值越大网络开销越小但故障发现时间越长反之则切换更快但会占用一点点带宽。对于大多数内网项目1秒是标准选择。如果核心业务对切换时间非常敏感可以调到0.5秒甚至更低但需要确保网络质量和交换机CPU足够好。配置写完后执行以下命令让Keepalived启动并设置为开机自启systemctl start keepalived systemctl enable keepalived启动后在Master机器上执行ip addr show eth0会看到192.168.10.100这个VIP已经挂在eth0上。在Backup机器上同样执行这个命令正常情况下是看不到VIP的。如果两台机器都出现了VIP那就说明发生了脑裂需要马上排查防火墙是否拦截了VRRP通告。4.3 故障切换测试记录配置完成后我做了一个完整的故障切换演练。这个环节不能省很多配置看起来没问题一演练就露馅。测试过程分为三个场景服务进程崩溃、整机宕机、Keepalived进程被kill。场景一模拟服务进程崩溃。我在Master上执行systemctl stop nginx因为没有配置监控脚本所以Keepalived本身不会感知到服务挂了VIP还是留在Master上。这说明一个关键点仅靠Keepalived本身只能检测主机的网络状态检测不到业务进程的健康状态。所以我又加了自定义监控脚本通过每隔两秒检查业务端口的方式判断服务是否正常如果端口不通就把本机的Keepalived停掉让VIP漂移到备机。场景二模拟整机宕机。直接把Master服务器强制断电。这时候情况更严重Keepalived进程都没了。由于开启了VRRPBackup在3秒内没有收到Master的通告报文就会进入Master状态VIP漂移到了备机业务访问恢复。实测中整个切换时间大约在2~3秒客户端侧的TCP连接会断开一次但重连后就能正常访问。场景三测试网络链路。拔掉Master机连接的交换机网线和宕机效果一样VIP会在几秒钟内迁移到备机。这个测试在项目中非常关键因为很多服务器宕机处理起来还好但网线松动这种物理问题偶尔也会发生VIP必须保证能在这种故障下切换。4.4 主备模式与负载均衡模式怎么选这个项目用的是主备模式也就是说同一时间只有一台服务器在处理业务另一台处于闲置待命状态。这种模式的好处是配置简单、故障切换逻辑清晰不会有会话冲突的问题。缺点也明显就是有一台机器的性能被白白浪费了。如果业务量比较大可以考虑负载均衡模式。办法是在前端用LVS加上Keepalived把VIP的流量均匀分发到多台后端服务器上此时Keepalived负责保障VIP入口的高可用LVS再负责在后端之间做流量调度。两种模式的选择归根结底要看业务并发量。我这个项目的业务量一天只有几万次请求主备完全够用。如果你的场景是几百万次那还是认真评估一下LVS负载均衡模式比较靠谱具体配置是另一套体系后续有机会单独展开聊。5. 工程验收要点与常见问题排查实录5.1 项目验收清单与文档归档项目做完不是跑通了就完事验收和文档归档同样重要。我整理了一份验收清单建议有类似项目的朋友直接拿去对照着测测试项目测试方法预期结果基础连通性服务器之间互ping丢包率为0网关连通性服务器ping网关地址通延迟低于1msVIP访问测试在客户端访问VIP的业务端口正常返回业务响应主备切换测试手动停止Master的Keepalived服务备机接管VIP业务恢复宕机切换测试直接断电Master服务器备机接管切换时间小于5秒恢复回切测试恢复Master服务器并启动KeepalivedVIP自动回到Master文档归档这块我把网络拓扑图、IP地址分配表、交换机端口对照表、Keepalived配置文件全部整理成了一套文档放到运维团队共享目录里。特别是IP地址分配表要记录每台设备使用哪些IP、是什么用途、属于哪个VLAN、对应哪个物理端口。这个表在后续排查故障的时候就是网络工程的地图没有它就像在大楼里断电摸黑走路。5.2 高频故障与排查速查表项目上线至今也积累了一些典型的故障案例这里挑几个典型的说故障现象可能原因排查步骤客户端访问VIP超时VIP没有正确漂移在两个节点上分别执行ip addr show确认VIP是否在一个且仅在一个节点上两台服务器都绑定了VIPVRRP报文被防火墙拦截检查防火墙规则确认放行了VRRP协议和Keepalived使用的端口切换后业务恢复慢免费ARP未被交换机学习到在备机上手动执行arping命令触发ARP更新主服务器复活后VIP不自动回切配置了nopreempt策略确认是否配置了nopreempt如果不想手动干预可以去掉该参数这里有个真实的坑值得重点讲一下。项目上线后第三周夜里值班电话打过来说VIP地址ping不通了业务全断。我远程登录一看发现两台服务器上居然都绑着VIP典型的脑裂状态。排查下来居然是防火墙规则在重启后被重置了导致VRRP端口被拦截主备之间互相听不到通告两台机器都以为自己是Master。解决方式也很简单把防火墙策略固化到配置文件里并且启动了VRRP专有的认证功能从源头避免非法的VRRP报文干扰选举。还有一个值得提醒的点就是免费ARP。VIP漂移后交换机MAC表有时候不会立刻更新如果遇到VIP能ping通但新连接分配不上这种诡异情况大概率是ARP缓存过期的问题。手动在备机执行一下arping -I eth0 -c 5 -U 192.168.10.100强制刷新一下上游设备的ARP表项业务往往瞬间就恢复了。5.3 运维与安全加固的心得高可用方案上线后不代表就一劳永逸了运维侧的加固一点不能少。首先是VRRP报文本身的安全问题。默认情况下VRRP报文是明文传输的局域网内如果有恶意设备加入可能会伪装成高优先级节点把VIP抢过去。所以我在配置里给VRRP认证设置了密码并建议定期更换。第二点是防火墙策略需要额外留意。Keepalived的VRRP报文基于IP协议号112没有固定的TCP/UDP端口很多防火墙策略只放行了TCP/UDP就把VRRP漏掉了。要确保主备两台服务器之间防火墙放行了IP协议号112的报文否则就会出现我在前面提到过的脑裂问题。第三点是监控。VIP高可用做得再好如果没人盯着故障发生的那一刻没人知道那就等于没有高可用。我给VIP加了一个定时探测脚本每隔一分钟从外部探测一次VIP的存活状态与业务响应码如果有连续三次失败就把告警消息推到工作群里。这套监控脚本非常简单但价值极大它才是保障高可用真正落地的最后一环。6. 写在工程收尾之后这个项目让我对高可用有了更实在的理解。很多人一听到高可用就想着上多贵的设备、多复杂的架构但回过头来看真正把Ethernet网络规划清楚、把IP地址设计得可扩展、把VIP的切换逻辑做到稳定就已经能解决大多数传统业务场景的痛点。最后再分享一个运维小技巧主备服务器的配置文件一定要做版本管理。我见过太多团队在一台机器上改了配置却不记得同步到另一台导致主备配置不一致平时看不出来一旦切换就翻车。每次修改Keepalived配置或者网络参数两边必须同步更新并且用diff命令对比确认没有差异再去做切换测试。养成这个习惯才算把这套方案的最后一个坑也填上了。

以太网高可用方案：网络架构、IP规划与Keepalived VIP漂移实录

相关推荐

Claude Code插件市场搭建指南：从JSON目录到Git分发实践

lingbot-map实战：机器人导航地图的格式统一与坐标对齐

端侧AI推理实战：边缘计算与硬件落地的关键路径

更多资讯

sentry_drift鸿蒙化适配：Flutter数据库级性能追踪

VS Code 高效开发实战：从安装配置到插件调试完整指南

AI调度官真的能管好团队？从拆目标到团建的三周实测拆解

智能体技能体系设计：从提示词到可复用能力单元

GPT-4o API接入实战：认证、流式输出与工程优化全攻略

CactiEZ实战：华为、H3C、中兴交换机SNMP监控模板导入与排错

今日更新

微信云开发旅游小程序实战：LBS打卡+UGC社交全栈方案

金融AI代理平台核心拆解：从多代理协作到财报分析实战

基于大数据的智慧旅游推荐与可视化平台架构实践

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？