做网络工程这些年我经手过不少Ethernet以太网项目但真正让我觉得“值回票价”的往往是那些把IP规划和VIP高可用想明白了的工程。今天要聊的这个项目是某园区网络的升级改造核心就三件事理清以太网基础架构、重做一套干净的IP地址规划、再给关键业务配上VIP虚拟IP做高可用。如果你正打算做园区网络改造、机房高可用方案或者只是想把现有网络捋清楚这篇分享应该能给你一些可落地的参考——这里面的坑和思路都是我从实际项目里一条一条踩出来的。做网络工程和做软件不一样软件上线挂了还能马上回滚网络出问题往往就是全网的事电话会被打爆。所以我现在的习惯是动手之前把架构想清楚把IP规划表做扎实把冗余和切换关系画明白后面实施才有底。这个项目能顺利交付靠的也是这三件事。1. 项目需求与总体设计思路1.1 这种项目通常是从什么痛点开始的这个项目是某园区网络的整体升级。原网络的问题在地下埋了几年集中爆发的时候大概有三类第一是单点故障。核心交换机就一台网关都在这台设备上核心一挂整个园区不能上网、业务系统全部中断。这种结构在中小型网络里太常见了预算紧张的时候一台上能撑就撑着但业务部门不会知道你在赌这台设备的MTBF。第二是IP地址混乱。历史原因造成办公网、打印机、门禁、监控这些设备混在同一个大网段里IP全是手动登记的小本本换个人就乱。新设备接入的时候经常随便挑一个地址冲突是家常便饭查起来尤其头疼。第三是服务器缺乏高可用。对外Web、ERP这些核心业务都是单机部署绑定一个固定IP服务器宕机或者进程崩溃业务就断了没有自动切换的机制。改造目标很明确双核心架构三层网关做冗余单台设备故障不影响全网。IP地址体系结构化按业务划分VLAN能预留扩展能审计。服务器区独立隔离和办公网、管理网分开。关键业务通过VIP虚拟IP实现故障自动切换做到“用户无感”。1.2 为什么选择“双核心V.P.R.R.Pkeepalived”这个组合方案选型阶段其实纠结过几次。第一版想过在二层用STP/RSTP做链路冗余但仔细一想STP解决的只是物理链路环路和冗余问题网关还是挂在单台设备上核心设备一坏照样断网。网关这一层必须做三层的冗余所以直接上VRRP虚拟路由冗余协议让两台核心交换机共享一个虚拟网关IP主设备承载流量备设备实时同步状态主设备挂了备设备自动接管。服务器侧的高可用考虑过两个方向一个是集群软件套件功能强但配置重对这种Web/Nginx场景有点杀鸡用牛刀另一个是keepalived它本身就实现了VRRP协议又自带健康检查脚本配置简单、维护成本低非常适合Web服务和API网关这类业务。最后定了“网络层VRRP做网关冗余应用层keepalived做VIP漂移”的组合层与层之间解耦出问题也好排查。这个设计里有两条原则是我比较坚持的能少一层就少一层能用标准协议就不用私有协议。VRRP有行业标准任意主流设备之间都可以互通后续扩容换品牌也不怕keepalived因为是纯软件方案跑在标准Linux上后续就算要换负载均衡设备VIP的IP规划思路也可以直接沿用。2. 以太网基础架构与IP地址规划细节2.1 VLAN划分和网段设计IP规划是整个项目的地基。地址用好了后面做路由策略、ACL、限速都顺手规划乱了排查问题的时候全是阻力。这次按业务用途把园区网拆成了几个VLAN地址段统一采用10.x.x.x段。很多人习惯用192.168.x.x但10.0.0.0/8的容量大得多私网地址也不容易被消费级路由器和现有办公网习惯冲突后续不管是加楼栋、加网段还是做聚合都更方便。VLAN用途网段网关说明VLAN 10设备管理10.0.10.0/2410.0.10.254交换机、AP、防火墙的管理口VLAN 20办公终端10.0.20.0/2410.0.20.254员工有线接入DHCP动态分配VLAN 30无线接入10.0.30.0/2410.0.30.254AP业务、访客/员工WiFiVLAN 40监控/门禁10.0.40.0/2410.0.40.254摄像头、门禁控制器VLAN 100服务器业务10.0.100.0/2410.0.100.254服务器物理地址和VIP都在这段VLAN 200核心互联10.0.200.0/30-两台核心交换机之间的三层互通每个网段按什么逻辑预留也有讲究。拿办公VLAN 20举例10.0.20.0/24一共254个可用地址我把它切成几块10.0.20.1 - 10.0.20.99固定设备保留区。打印机、门禁、考勤机、IP电话这些需要设静态地址的设备全部从这里分配。10.0.20.100 - 10.0.20.249DHCP动态分配池。给员工电脑、访客终端这种频繁变动的设备。10.0.20.250 - 10.0.20.253预留地址。给未来可能增加的网络设备或临时测试用。10.0.20.254网关地址通常是核心交换机上VLANIF的VRRP虚拟IP。网关地址为什么放在254而不是1除了习惯之外还有一个好处网段的低位地址留给服务器和固定设备高位地址留给网关和网络设备人在排查的时候只要看IP段就能猜个八九不离十不用每次都翻地址表。这个习惯在后来几个月运维里被验证非常有用新来的同事上手也快。2.2 子网计算和地址预留逻辑说几个容易被新手忽略的计算细节。IP地址计算的核心就是三件事网络地址、广播地址、可用主机范围。以10.0.100.0/24为例网络地址10.0.100.0广播地址10.0.100.255可用主机地址10.0.100.1 - 10.0.100.254254个如果子网掩码换成255.255.255.128也就是/25那这个网段就只有126个可用地址网络地址10.0.100.0广播地址10.0.100.127另一段是10.0.100.128/25。做规划之前一定要把这些边界算明白否则很容易出现“规划好了但地址用不了”的尴尬。还有核心交换机之间的互联地址我只用了10.0.200.0/30这个子网。很多新手喜欢给点对点互联用一个/24白白浪费两百多个地址不算路由表还容易被塞得很胖。/30刚刚好两个可用地址分别是两台设备的接口IP网络地址和广播地址各占一个。这是经验也是习惯第一次做规划的朋友建议直接照这个思路来。服务器VLAN的VIP预留我单独放在10.0.100.51到10.0.100.60这十个地址段。物理服务器从10.0.100.1开始分配VIP统一放在后半段这样看地址就知道哪个是真实机器、哪个是浮动的虚拟IP监控告警的时候一眼就能分辨。实际工程里很多团队不区分物理IP和VIP段搞到后面IP和VIP混在一起排查问题要多绕好几个弯这事吃过亏的人自然懂。2.3 DHCP与静态地址的边界IP规划再漂亮落地的时候还需要一套分配机制配合。办公终端走DHCP但DHCP不是放个地址池就行。我在核心交换机上配置了DHCP服务同时做了这几件事DHCP地址池范围只覆盖10.0.20.100 - 10.0.20.249不能把固定设备保留区放进去否则打印机可能被随机分配一个地址和别的设备冲突。通过DHCP Option下发网关和DNS网关是10.0.20.254DNS指向内网解析服务器。办公WiFi的VLAN 30单独一个池访客网络地址池更小而且和员工完全隔离开。静态地址和动态地址的边界要坚决一点。打印机、摄像头、服务器这些“不能随便动”的设备一律静态IP而且静态IP的管理要落到表格里谁分配的、什么时候分配的、用途是什么都记录清楚。这个项目的旧网络就是吃了没有地址表的亏这次我把地址规划表做成了交付文档的一部分后续运维都按这个表走。3. VIP虚拟IP的原理与高可用方案选型3.1 VIP到底是什么为什么一定要有它VIP全称是Virtual IP虚拟IP。通俗点说它就是一台不绑定任何具体物理设备的“房子门牌号”。正常情况下只有主设备响应这个地址备设备在旁边安静监听一旦主设备故障备设备立刻把这个门牌号接过来继续对外提供同样的服务。客户端从头到尾只和这一个IP打交道完全感知不到后台发生了什么。为什么一定要有VIP而不是直接把IP配在备机上因为IP在同一个二层网络里只能被一台设备持有。如果两台机器都配了同一个IP交换机MAC地址表会疯狂抖动网络一片混乱。VIP的出现解决的正是这个矛盾它允许一组设备共享一个服务地址靠协议机制来保证“同一时间只有一台设备响应”。这个原理放在网络交换机和放在Linux服务器上是一样的。在核心交换机上VRRP让两台三层交换机共享一个虚拟网关IP在服务器上keepalived让两台业务服务器共享一个服务VIP。区别只在于承载的业务层级——一个是网关一个是应用入口。3.2 网络层网关冗余VRRP的工作机制VRRP全称Virtual Router Redundancy Protocol虚拟路由冗余协议。它把两台路由器这里就是两台三层交换机抽象成一台“虚拟路由器”组内设备通过优先级选出一台Master其余都是Backup。Master负责转发流量Backup监听Master的VRRP通告报文。一旦连续几个通告周期没有收到Master的报文Backup中优先级最高的那台就会自动升为Master继续承担网关职责。核心交换机的配置上虚拟网关IP是10.0.20.254两台核心设备自己的物理接口IP分别是10.0.20.253和10.0.20.252。也就是说设备真实IP和虚拟IP是独立的。这么做有一个非常现实的好处排查问题的时候你可以登录任意一台设备的真实IP去查状态不用抢那个虚拟IP。很多新手第一次配置容易把虚拟IP配到主设备物理接口上结果备设备就无法宣告同一个VIP切换逻辑直接失效属于典型低级但常见的错。VRRP还有几个参数值得留意priority优先级取值范围1-254数值越大越容易成为Master。一般主设备设120备设备设100差值够用就好不用太大。advert_int通告间隔默认1秒主设备每隔1秒向组内发一次通告。检测超时一般是3秒也就是连续3次没收到就切换。preempt模式默认开启意思是优先级更高的设备会主动抢占Master位置。但如果Master故障恢复后立刻抢占会引起网络抖动所以要给抢占加个延迟比如10秒。这样网络先稳定一小段时间再切回去。这些参数单看都简单组合起来的时序体验才是项目成败的关键。切换太快容易误判比如设备只是重启一个接口切换太慢业务断太久。我的习惯是网关VRRP的advert_int保持1秒preempt延迟10秒服务器keepalived的健康检查间隔2秒配合权重降级而不是直接干掉进程。不同层级的妥协策略是不一样的套用一个模板到处用很容易出问题。3.3 应用层服务高可用keepalived与健康检查keepalived做的事情本质上就是在Linux服务器上实现了VRRP协议再加上一层健康检查能力。它有两个核心组件一个是VRRP的完整实现负责VIP的漂移另一个是健康检查框架通过track_script定期执行脚本判断当前节点的业务是否正常。常见的健康检查方案有两种思路进程检查脚本里查一下Nginx进程在不在不在就认为故障。服务检查用nc或curl去探测VIP的端口比如检查80端口有没有响应更贴近“业务真实可用性”。只查进程有一个盲区进程在但服务已经假死比如Nginx master进程还在worker全卡死端口没响应。所以成熟的配置会优先探测端口或者HTTP状态码然后再决定是否降级或切换。我这次用的是二者结合默认每2秒做一次端口探测连续失败1次就把keepalived的优先级降下来让备机接管。weight参数是这里的关键。如果脚本检测失败给当前节点的priority减去一个weight值比如-20让它的优先级低于备机VIP自然漂过去。相比直接把keepalived服务停掉降权重的方式更优雅因为主节点只是“业务异常”但进程还活着你还是能登录去排查。4. 核心配置实操详解4.1 双核心交换机VRRP网关配置两台核心交换机先配好互联接口。互联地址用10.0.200.1/30主和10.0.200.2/30备跑三层互联VRRP心跳报文可以走独立的互联链路也可以走业务VLAN的二层链路。实际项目里我建议把VRRP报文所在的VLAN和互联链路都放通双保险。下面是核心网关VLAN 20的配置逻辑不同品牌命令有差异思路一致interface Vlanif20 ip address 10.0.20.253 255.255.255.0 vrrp vrid 20 virtual-ip 10.0.20.254 vrrp vrid 20 priority 120 vrrp vrid 20 preempt-mode timer delay 10备机上对应配置是把接口IP换成10.0.20.252priority设成100不用开preempt延迟或者保持默认就行。注意VRRP虚拟IP不能和接口真实IP一样两台设备的vrid要一致不然协议根本不会协商成功。写完配置后用查看命令确认一下状态Master设备上应该能看到VLAN 20的虚拟IP是Active状态。其他VLAN的配置模式完全一样就是把vrid和虚拟IP对应到相应VLAN。vrid只在同一二层网络内有效但我习惯把vrid和VLAN ID用同一个数字比如VLAN 20用VRID 20VLAN 100用VRID 100维护起来一目了然。4.2 Linux服务器keepalived配置服务器侧的配置以两台Nginx节点为例跑在VLAN 100里的两台物理服务器上物理IP分别是10.0.100.1和10.0.100.2服务VIP是10.0.100.51。主节点的keepalived配置是global_defs { router_id SVR_MASTER } vrrp_script chk_http { script /etc/keepalived/check_http.sh interval 2 weight -20 } vrrp_instance VI_100 { state MASTER interface ens192 virtual_router_id 100 priority 120 advert_int 1 authentication { auth_type PASS auth_pass 100 } virtual_ipaddress { 10.0.100.51/24 dev ens192 } track_script { chk_http } }备节点只需要改几个地方state改成BACKUPpriority改成100router_id改成SVR_BACKUP其他保持不变。virtual_router_id和auth_pass必须和主节点一致这是两台设备能不能组成同一个VRRP组的关键。健康检查脚本check_http.sh我写的是这样#!/bin/bash if curl -fsS http://127.0.0.1/healthz /dev/null 21; then exit 0 else exit 1 fi脚本加执行权限放在/etc/keepalived/下面keepalived每2秒跑一次。curl的-s静默、-f失败不输出错误、-S显示错误但配合重定向一起用避免日志被刷爆。健康检查的目的是判断业务到底行不行而不是纠结具体报错所以脚本越简单越好逻辑太复杂的脚本本身就是故障点。4.3 业务侧Nginx的接入方式VIP在网卡上生效之后Nginx必须监听VIP的地址才能真正对外提供服务。配置里有一个容易忽略的重点Nginx监听地址要同时覆盖VIP和本机回环不然VIP绑定漂移之后流量过不来。我用的是这种写法server { listen 10.0.100.51:80; server_name api.internal; location / { proxy_pass http://backend_servers; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }当VIP从主节点漂移到备节点时备节点上的Nginx如果早已监听10.0.100.51:80那么切换瞬间流量就能无缝接入如果备节点没监听这个地址VIP过来了也没有进程接收客户端会看到连接被拒绝。这个细节我在很多项目里都见过VIP配置了、漂移也成功了但业务还是断就是因为应用只监听了本机物理IP没监听VIP。4.4 防火墙和二层放通规则VRRP和keepalived都依赖组播报文VRRP使用的组播地址是224.0.0.18协议号112。两台交换机如果中间隔了防火墙或者服务器之间隔了安全域一定要把这条组播放通。很多“主备切换失败”的现场最后查出来就是中间设备把VRRP组播给拦了两台机器各说各话全都以为自己是主设备形成脑裂。预防办法也很简单核心交换机之间建议直连心跳链路不要过防火墙keepalived节点之间在同一交换机下别跨三层。服务器自身的防火墙也要注意。keepalived绑定VIP之后iptables如果开了要确保VIP上的服务端口被放行。我一般会给业务VIP单独加一条规则iptables -A INPUT -d 10.0.100.51/32 -p tcp --dport 80 -j ACCEPT iptables -A INPUT -d 224.0.0.18/32 -j ACCEPT少写一条足以让你排查一整天。5. 项目实施步骤与验证测试方法5.1 实施顺序怎么排才不容易出事故网络工程的实施顺序我总结下来有一条核心原则先做不影响业务的底层铺垫再做核心切换最后做业务验证。这次项目的实施顺序是先把两台核心之间的互联链路和VLAN配置好确认互联互通。创建所有业务VLAN打通二层端口但先不切换终端。配置VRRP网关确认虚拟IP在Master上生效。这时新旧网络是并行的旧终端不感知。把办公网终端从旧网络切到新VLAN和新网关分段切换一秒可以完成。服务器区迁移到VLAN 100部署keepalived和Nginx绑定VIP。外部访问全部指向新VIP完成迁移。整个过程最忌讳的就是“一次性切换好”。我一般按楼层或按部门分批切每切完一批就验证一批发现问题还能定向回滚。这次实施时晚上窗口内完成核心切换第二天早上办公网全部验证通过基本没影响业务。5.2 连通性和切换可靠性测试测试不光是“能通就行”要量化。我用的测试方法有两类第一类是连通性验证ping -c 10 10.0.20.254 traceroute 10.0.100.51从办公终端去ping网关VIP再traceroute到服务器VIP路径应该经过核心交换机上的VRRP网关不会出现往返不一致。如果traceroute里看到访问10.0.100.51时经过的路径和预期不符说明路由或者VLAN划分有问题。第二类是切换测试也是高可用项目的重头戏。我的做法是主核心交换机直接拔掉上行网线或者强制关闭VLANIF接口观察办公网丢多少包。正常情况下VRRP切换在3秒左右收敛终端侧会丢2-4个ping包业务无感知。主keepalived节点执行systemctl stop keepalived模拟服务进程故障观察VIP是否漂移到备机Nginx业务是否持续可用。更强硬一点的做法拔掉主服务器网线模拟整机宕机。这时候VIP应该由备机接管外网用户几乎无感。切换测试做完还要做一个恢复测试。把主设备重新加电确认它会延迟10秒后抢占回MasterVIP回到主节点全程不能出现震荡。恢复测试很多人不做但恰恰是恢复过程最容易出问题。5.3 抓包验证协议运行状态配置和ping都正常不代表协议真的在工作。最直接的办法就是抓包看协议报文。在核心交换机上用抓包工具过滤VRRPtcpdump -i any vrrp -n正常状态下你应该每隔1秒能看到一条VRRP广播报文source地址是Master设备的真实IP说明Master在正常向外通告。如果抓不到VRRP报文优先检查组播放通和vrid一致性。keepalived节点上也可以抓tcpdump -i ens192 vrrp -nn抓包是排查“一切看起来都正常但切换就是失败”的利器。协议层面有没有在收敛、VIP有没有真正漂移、报文是不是被中间策略丢弃抓一次包就知道不用瞎猜。5.4 性能验证与长稳压测连通性OK之后还要做量化的性能验证。我用iperf3做吞吐测试验证VIP承载业务流量的能力iperf3 -c 10.0.100.51 -p 5201 -t 60 -i 5两端服务器上都要安装iperf3服务端用-s启动。这里要注意VIP迁移之后iperf客户端仍然连10.0.100.51但实际响应的是当前持有VIP的那台物理机这个结果就能逼真模拟真实业务流量的路径。长稳测试也不能省。新网络跑通之后我习惯至少打流2小时以上观察丢包率、延迟抖动、VRRP切换次数。丢包率超过0.1%或者延迟抖动明显优先查二层环路、端口协商速度以及链路聚合的负载不均。稳定压倒一切网络工程尤其如此。6. 常见问题与排查技巧实录6.1 问题速查表问题现象可能原因排查方法VIP ping不通虚拟IP被占用VRRP状态异常没有放行VRRP组播查看VRRP状态抓包确认检查IP冲突主备切换后服务仍然中断应用没有监听VIPARP缓存未更新健康检查误判检查Nginx监听地址清ARP缓存手动跑健康检查脚本两台设备都是MasterVRRP组播被拦截auth_pass不一致vrid不一致放行224.0.0.18核对配置一致性抓包看通告MAC地址漂移告警两个网卡上绑了相同VIPbond配置不当检查网卡绑定模式确认VIP只绑定在bond口切换时间远超预期advert_int过大track_script轮询间隔太长preempt延迟过长调小advert_intinterval改2秒合理设置延迟6.2 几个值得单独说说的坑第一个坑虚拟IP被其他设备占掉。有一台旧服务器一直没有下线地址恰好是规划里的VIP结果VIP一直起不来。这种问题最隐蔽因为你看两台配置都没问题但就是不通。排查方法很简单先在三层交换机上ping一下这个VIP看返回的MAC地址是不是Master设备的接口MAC。如果不是那就是有别的设备占着这个地址。所以规划阶段一定要确认全网所有地址都登记在案没下线的设备绝对不放过。第二个坑keepalived健康检查脚本权限忘加。脚本写好了忘了chmod xkeepalived执行脚本时权限不足每次都返回失败主节点一直被降权VIP反复在两边跳业务一断一断的。这种情况好在检查日志能很快发现。我的经验是脚本写完先手动执行一遍看返回码确认能正常退出再交给keepalived去调用。第三个坑核心交换机VRRP报文走了业务口被禁。有些安全策略会在二层端口上做组播抑制VRRP这个组播一旦被抑制两台核心就互相联系不上全以为自己是主设备。这个问题的表现和中间防火墙拦截一模一样都是脑裂。排查时重点看交换机的组播过滤配置该放行的放行该单独划心跳链路的就单独划。第四个坑切换后VIP在备机网卡上存在但业务入口不通。备机的Nginx没监听VIP或者监听了但upstream里的后端地址写错了。这种情况测试切换时最容易暴露所以我上面的实施顺序里特意强调切换测试必须连同业务请求一起验证不能只看VIP是否漂移到位。VIP在不在和业务通不通是两回事。第五个坑恢复测试时主设备抢占过快导致网络震荡。默认preempt模式没有延迟的话主设备一恢复就抢占VRRP状态反复切换终端会连续丢包。所以我在主设备上专门加了10秒抢占延迟让网络先稳定一小会儿再切回去。这个细微的配置差异在真实恢复操作里体验差别特别大。7. 交付物和日常运维扩展7.1 项目交付必须带哪些东西网络工程项目不能光把设备调通就算完工。我这次项目的交付物做了四份第一份是IP地址规划表。包含每个VLAN、每个网段、每个固定IP归属于哪台设备、哪个端口、用途是什么。这张表是整个后续运维的地图没有它一切免谈。第二份是拓扑图。不只是二层交换机连线图要带着VLAN、网关、VIP、物理IP画一份三层逻辑图。哪里是主、哪里是备、VIP漂移路径是什么一看就懂。第三份是配置备份和变更清单。两台核心、两台业务服务器的当前配置全部导出存档同时记录这次项目做了哪些变更、为什么这么改方便后续审计。第四份是操作手册。内容包括日常巡检命令、如何查看VRRP主备状态、如何手动切换VIP、日志在哪看。这套手册我习惯写成“照着做就能完成常见操作”的口吻因为以后值班的同事不一定有项目上下文越傻瓜越好。7.2 后续还能怎么扩展这个项目的架构本身留了不少扩展余地。核心层面如果节点增加可以在VRRP基础上引入多台设备做负载分担也可以把三层网关升级为动态路由协议比如OSPF在大规模园区里更灵活。应用层面keepalived维护的VIP前面可以再加一层负载均衡把流量分发到更多后端节点健康检查也可以从端口探测升级为HTTP状态码和延迟综合评分。监控层面VRRP状态和keepalived漂移事件应该接入告警系统切换发生后第一时间通知到人而不是事后从业务部门那里听说。我个人的习惯是每次做完一个项目都会抽时间把“可复用的模板”整理出来比如通用的VRRP配置片段、keepalived脚本模板、IP规划Excel表。下次做类似项目直接拿模板改参数省时省力还能避开这次踩过的坑。这个项目从头到尾做下来我的体会其实很简单网络工程的复杂度往往不在设备配置上而是在决策细节里。IP地址规划时多花一个小时后面可能省下十几个小时的排查时间VIP高可用配置时多想一步健康检查的问题紧急故障时就能少挨一小时的电话轰炸。做网络这行方案要简单配置要能审计出了状况要能快速定位。这套思路放到任何一个以太网工程里都适用剩下的就是在实践中不断打磨细节了。
做网络工程这些年我经手过不少Ethernet以太网项目但真正让我觉得“值回票价”的往往是那些把IP规划和VIP高可用想明白了的工程。今天要聊的这个项目是某园区网络的升级改造核心就三件事理清以太网基础架构、重做一套干净的IP地址规划、再给关键业务配上VIP虚拟IP做高可用。如果你正打算做园区网络改造、机房高可用方案或者只是想把现有网络捋清楚这篇分享应该能给你一些可落地的参考——这里面的坑和思路都是我从实际项目里一条一条踩出来的。做网络工程和做软件不一样软件上线挂了还能马上回滚网络出问题往往就是全网的事电话会被打爆。所以我现在的习惯是动手之前把架构想清楚把IP规划表做扎实把冗余和切换关系画明白后面实施才有底。这个项目能顺利交付靠的也是这三件事。1. 项目需求与总体设计思路1.1 这种项目通常是从什么痛点开始的这个项目是某园区网络的整体升级。原网络的问题在地下埋了几年集中爆发的时候大概有三类第一是单点故障。核心交换机就一台网关都在这台设备上核心一挂整个园区不能上网、业务系统全部中断。这种结构在中小型网络里太常见了预算紧张的时候一台上能撑就撑着但业务部门不会知道你在赌这台设备的MTBF。第二是IP地址混乱。历史原因造成办公网、打印机、门禁、监控这些设备混在同一个大网段里IP全是手动登记的小本本换个人就乱。新设备接入的时候经常随便挑一个地址冲突是家常便饭查起来尤其头疼。第三是服务器缺乏高可用。对外Web、ERP这些核心业务都是单机部署绑定一个固定IP服务器宕机或者进程崩溃业务就断了没有自动切换的机制。改造目标很明确双核心架构三层网关做冗余单台设备故障不影响全网。IP地址体系结构化按业务划分VLAN能预留扩展能审计。服务器区独立隔离和办公网、管理网分开。关键业务通过VIP虚拟IP实现故障自动切换做到“用户无感”。1.2 为什么选择“双核心V.P.R.R.Pkeepalived”这个组合方案选型阶段其实纠结过几次。第一版想过在二层用STP/RSTP做链路冗余但仔细一想STP解决的只是物理链路环路和冗余问题网关还是挂在单台设备上核心设备一坏照样断网。网关这一层必须做三层的冗余所以直接上VRRP虚拟路由冗余协议让两台核心交换机共享一个虚拟网关IP主设备承载流量备设备实时同步状态主设备挂了备设备自动接管。服务器侧的高可用考虑过两个方向一个是集群软件套件功能强但配置重对这种Web/Nginx场景有点杀鸡用牛刀另一个是keepalived它本身就实现了VRRP协议又自带健康检查脚本配置简单、维护成本低非常适合Web服务和API网关这类业务。最后定了“网络层VRRP做网关冗余应用层keepalived做VIP漂移”的组合层与层之间解耦出问题也好排查。这个设计里有两条原则是我比较坚持的能少一层就少一层能用标准协议就不用私有协议。VRRP有行业标准任意主流设备之间都可以互通后续扩容换品牌也不怕keepalived因为是纯软件方案跑在标准Linux上后续就算要换负载均衡设备VIP的IP规划思路也可以直接沿用。2. 以太网基础架构与IP地址规划细节2.1 VLAN划分和网段设计IP规划是整个项目的地基。地址用好了后面做路由策略、ACL、限速都顺手规划乱了排查问题的时候全是阻力。这次按业务用途把园区网拆成了几个VLAN地址段统一采用10.x.x.x段。很多人习惯用192.168.x.x但10.0.0.0/8的容量大得多私网地址也不容易被消费级路由器和现有办公网习惯冲突后续不管是加楼栋、加网段还是做聚合都更方便。VLAN用途网段网关说明VLAN 10设备管理10.0.10.0/2410.0.10.254交换机、AP、防火墙的管理口VLAN 20办公终端10.0.20.0/2410.0.20.254员工有线接入DHCP动态分配VLAN 30无线接入10.0.30.0/2410.0.30.254AP业务、访客/员工WiFiVLAN 40监控/门禁10.0.40.0/2410.0.40.254摄像头、门禁控制器VLAN 100服务器业务10.0.100.0/2410.0.100.254服务器物理地址和VIP都在这段VLAN 200核心互联10.0.200.0/30-两台核心交换机之间的三层互通每个网段按什么逻辑预留也有讲究。拿办公VLAN 20举例10.0.20.0/24一共254个可用地址我把它切成几块10.0.20.1 - 10.0.20.99固定设备保留区。打印机、门禁、考勤机、IP电话这些需要设静态地址的设备全部从这里分配。10.0.20.100 - 10.0.20.249DHCP动态分配池。给员工电脑、访客终端这种频繁变动的设备。10.0.20.250 - 10.0.20.253预留地址。给未来可能增加的网络设备或临时测试用。10.0.20.254网关地址通常是核心交换机上VLANIF的VRRP虚拟IP。网关地址为什么放在254而不是1除了习惯之外还有一个好处网段的低位地址留给服务器和固定设备高位地址留给网关和网络设备人在排查的时候只要看IP段就能猜个八九不离十不用每次都翻地址表。这个习惯在后来几个月运维里被验证非常有用新来的同事上手也快。2.2 子网计算和地址预留逻辑说几个容易被新手忽略的计算细节。IP地址计算的核心就是三件事网络地址、广播地址、可用主机范围。以10.0.100.0/24为例网络地址10.0.100.0广播地址10.0.100.255可用主机地址10.0.100.1 - 10.0.100.254254个如果子网掩码换成255.255.255.128也就是/25那这个网段就只有126个可用地址网络地址10.0.100.0广播地址10.0.100.127另一段是10.0.100.128/25。做规划之前一定要把这些边界算明白否则很容易出现“规划好了但地址用不了”的尴尬。还有核心交换机之间的互联地址我只用了10.0.200.0/30这个子网。很多新手喜欢给点对点互联用一个/24白白浪费两百多个地址不算路由表还容易被塞得很胖。/30刚刚好两个可用地址分别是两台设备的接口IP网络地址和广播地址各占一个。这是经验也是习惯第一次做规划的朋友建议直接照这个思路来。服务器VLAN的VIP预留我单独放在10.0.100.51到10.0.100.60这十个地址段。物理服务器从10.0.100.1开始分配VIP统一放在后半段这样看地址就知道哪个是真实机器、哪个是浮动的虚拟IP监控告警的时候一眼就能分辨。实际工程里很多团队不区分物理IP和VIP段搞到后面IP和VIP混在一起排查问题要多绕好几个弯这事吃过亏的人自然懂。2.3 DHCP与静态地址的边界IP规划再漂亮落地的时候还需要一套分配机制配合。办公终端走DHCP但DHCP不是放个地址池就行。我在核心交换机上配置了DHCP服务同时做了这几件事DHCP地址池范围只覆盖10.0.20.100 - 10.0.20.249不能把固定设备保留区放进去否则打印机可能被随机分配一个地址和别的设备冲突。通过DHCP Option下发网关和DNS网关是10.0.20.254DNS指向内网解析服务器。办公WiFi的VLAN 30单独一个池访客网络地址池更小而且和员工完全隔离开。静态地址和动态地址的边界要坚决一点。打印机、摄像头、服务器这些“不能随便动”的设备一律静态IP而且静态IP的管理要落到表格里谁分配的、什么时候分配的、用途是什么都记录清楚。这个项目的旧网络就是吃了没有地址表的亏这次我把地址规划表做成了交付文档的一部分后续运维都按这个表走。3. VIP虚拟IP的原理与高可用方案选型3.1 VIP到底是什么为什么一定要有它VIP全称是Virtual IP虚拟IP。通俗点说它就是一台不绑定任何具体物理设备的“房子门牌号”。正常情况下只有主设备响应这个地址备设备在旁边安静监听一旦主设备故障备设备立刻把这个门牌号接过来继续对外提供同样的服务。客户端从头到尾只和这一个IP打交道完全感知不到后台发生了什么。为什么一定要有VIP而不是直接把IP配在备机上因为IP在同一个二层网络里只能被一台设备持有。如果两台机器都配了同一个IP交换机MAC地址表会疯狂抖动网络一片混乱。VIP的出现解决的正是这个矛盾它允许一组设备共享一个服务地址靠协议机制来保证“同一时间只有一台设备响应”。这个原理放在网络交换机和放在Linux服务器上是一样的。在核心交换机上VRRP让两台三层交换机共享一个虚拟网关IP在服务器上keepalived让两台业务服务器共享一个服务VIP。区别只在于承载的业务层级——一个是网关一个是应用入口。3.2 网络层网关冗余VRRP的工作机制VRRP全称Virtual Router Redundancy Protocol虚拟路由冗余协议。它把两台路由器这里就是两台三层交换机抽象成一台“虚拟路由器”组内设备通过优先级选出一台Master其余都是Backup。Master负责转发流量Backup监听Master的VRRP通告报文。一旦连续几个通告周期没有收到Master的报文Backup中优先级最高的那台就会自动升为Master继续承担网关职责。核心交换机的配置上虚拟网关IP是10.0.20.254两台核心设备自己的物理接口IP分别是10.0.20.253和10.0.20.252。也就是说设备真实IP和虚拟IP是独立的。这么做有一个非常现实的好处排查问题的时候你可以登录任意一台设备的真实IP去查状态不用抢那个虚拟IP。很多新手第一次配置容易把虚拟IP配到主设备物理接口上结果备设备就无法宣告同一个VIP切换逻辑直接失效属于典型低级但常见的错。VRRP还有几个参数值得留意priority优先级取值范围1-254数值越大越容易成为Master。一般主设备设120备设备设100差值够用就好不用太大。advert_int通告间隔默认1秒主设备每隔1秒向组内发一次通告。检测超时一般是3秒也就是连续3次没收到就切换。preempt模式默认开启意思是优先级更高的设备会主动抢占Master位置。但如果Master故障恢复后立刻抢占会引起网络抖动所以要给抢占加个延迟比如10秒。这样网络先稳定一小段时间再切回去。这些参数单看都简单组合起来的时序体验才是项目成败的关键。切换太快容易误判比如设备只是重启一个接口切换太慢业务断太久。我的习惯是网关VRRP的advert_int保持1秒preempt延迟10秒服务器keepalived的健康检查间隔2秒配合权重降级而不是直接干掉进程。不同层级的妥协策略是不一样的套用一个模板到处用很容易出问题。3.3 应用层服务高可用keepalived与健康检查keepalived做的事情本质上就是在Linux服务器上实现了VRRP协议再加上一层健康检查能力。它有两个核心组件一个是VRRP的完整实现负责VIP的漂移另一个是健康检查框架通过track_script定期执行脚本判断当前节点的业务是否正常。常见的健康检查方案有两种思路进程检查脚本里查一下Nginx进程在不在不在就认为故障。服务检查用nc或curl去探测VIP的端口比如检查80端口有没有响应更贴近“业务真实可用性”。只查进程有一个盲区进程在但服务已经假死比如Nginx master进程还在worker全卡死端口没响应。所以成熟的配置会优先探测端口或者HTTP状态码然后再决定是否降级或切换。我这次用的是二者结合默认每2秒做一次端口探测连续失败1次就把keepalived的优先级降下来让备机接管。weight参数是这里的关键。如果脚本检测失败给当前节点的priority减去一个weight值比如-20让它的优先级低于备机VIP自然漂过去。相比直接把keepalived服务停掉降权重的方式更优雅因为主节点只是“业务异常”但进程还活着你还是能登录去排查。4. 核心配置实操详解4.1 双核心交换机VRRP网关配置两台核心交换机先配好互联接口。互联地址用10.0.200.1/30主和10.0.200.2/30备跑三层互联VRRP心跳报文可以走独立的互联链路也可以走业务VLAN的二层链路。实际项目里我建议把VRRP报文所在的VLAN和互联链路都放通双保险。下面是核心网关VLAN 20的配置逻辑不同品牌命令有差异思路一致interface Vlanif20 ip address 10.0.20.253 255.255.255.0 vrrp vrid 20 virtual-ip 10.0.20.254 vrrp vrid 20 priority 120 vrrp vrid 20 preempt-mode timer delay 10备机上对应配置是把接口IP换成10.0.20.252priority设成100不用开preempt延迟或者保持默认就行。注意VRRP虚拟IP不能和接口真实IP一样两台设备的vrid要一致不然协议根本不会协商成功。写完配置后用查看命令确认一下状态Master设备上应该能看到VLAN 20的虚拟IP是Active状态。其他VLAN的配置模式完全一样就是把vrid和虚拟IP对应到相应VLAN。vrid只在同一二层网络内有效但我习惯把vrid和VLAN ID用同一个数字比如VLAN 20用VRID 20VLAN 100用VRID 100维护起来一目了然。4.2 Linux服务器keepalived配置服务器侧的配置以两台Nginx节点为例跑在VLAN 100里的两台物理服务器上物理IP分别是10.0.100.1和10.0.100.2服务VIP是10.0.100.51。主节点的keepalived配置是global_defs { router_id SVR_MASTER } vrrp_script chk_http { script /etc/keepalived/check_http.sh interval 2 weight -20 } vrrp_instance VI_100 { state MASTER interface ens192 virtual_router_id 100 priority 120 advert_int 1 authentication { auth_type PASS auth_pass 100 } virtual_ipaddress { 10.0.100.51/24 dev ens192 } track_script { chk_http } }备节点只需要改几个地方state改成BACKUPpriority改成100router_id改成SVR_BACKUP其他保持不变。virtual_router_id和auth_pass必须和主节点一致这是两台设备能不能组成同一个VRRP组的关键。健康检查脚本check_http.sh我写的是这样#!/bin/bash if curl -fsS http://127.0.0.1/healthz /dev/null 21; then exit 0 else exit 1 fi脚本加执行权限放在/etc/keepalived/下面keepalived每2秒跑一次。curl的-s静默、-f失败不输出错误、-S显示错误但配合重定向一起用避免日志被刷爆。健康检查的目的是判断业务到底行不行而不是纠结具体报错所以脚本越简单越好逻辑太复杂的脚本本身就是故障点。4.3 业务侧Nginx的接入方式VIP在网卡上生效之后Nginx必须监听VIP的地址才能真正对外提供服务。配置里有一个容易忽略的重点Nginx监听地址要同时覆盖VIP和本机回环不然VIP绑定漂移之后流量过不来。我用的是这种写法server { listen 10.0.100.51:80; server_name api.internal; location / { proxy_pass http://backend_servers; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }当VIP从主节点漂移到备节点时备节点上的Nginx如果早已监听10.0.100.51:80那么切换瞬间流量就能无缝接入如果备节点没监听这个地址VIP过来了也没有进程接收客户端会看到连接被拒绝。这个细节我在很多项目里都见过VIP配置了、漂移也成功了但业务还是断就是因为应用只监听了本机物理IP没监听VIP。4.4 防火墙和二层放通规则VRRP和keepalived都依赖组播报文VRRP使用的组播地址是224.0.0.18协议号112。两台交换机如果中间隔了防火墙或者服务器之间隔了安全域一定要把这条组播放通。很多“主备切换失败”的现场最后查出来就是中间设备把VRRP组播给拦了两台机器各说各话全都以为自己是主设备形成脑裂。预防办法也很简单核心交换机之间建议直连心跳链路不要过防火墙keepalived节点之间在同一交换机下别跨三层。服务器自身的防火墙也要注意。keepalived绑定VIP之后iptables如果开了要确保VIP上的服务端口被放行。我一般会给业务VIP单独加一条规则iptables -A INPUT -d 10.0.100.51/32 -p tcp --dport 80 -j ACCEPT iptables -A INPUT -d 224.0.0.18/32 -j ACCEPT少写一条足以让你排查一整天。5. 项目实施步骤与验证测试方法5.1 实施顺序怎么排才不容易出事故网络工程的实施顺序我总结下来有一条核心原则先做不影响业务的底层铺垫再做核心切换最后做业务验证。这次项目的实施顺序是先把两台核心之间的互联链路和VLAN配置好确认互联互通。创建所有业务VLAN打通二层端口但先不切换终端。配置VRRP网关确认虚拟IP在Master上生效。这时新旧网络是并行的旧终端不感知。把办公网终端从旧网络切到新VLAN和新网关分段切换一秒可以完成。服务器区迁移到VLAN 100部署keepalived和Nginx绑定VIP。外部访问全部指向新VIP完成迁移。整个过程最忌讳的就是“一次性切换好”。我一般按楼层或按部门分批切每切完一批就验证一批发现问题还能定向回滚。这次实施时晚上窗口内完成核心切换第二天早上办公网全部验证通过基本没影响业务。5.2 连通性和切换可靠性测试测试不光是“能通就行”要量化。我用的测试方法有两类第一类是连通性验证ping -c 10 10.0.20.254 traceroute 10.0.100.51从办公终端去ping网关VIP再traceroute到服务器VIP路径应该经过核心交换机上的VRRP网关不会出现往返不一致。如果traceroute里看到访问10.0.100.51时经过的路径和预期不符说明路由或者VLAN划分有问题。第二类是切换测试也是高可用项目的重头戏。我的做法是主核心交换机直接拔掉上行网线或者强制关闭VLANIF接口观察办公网丢多少包。正常情况下VRRP切换在3秒左右收敛终端侧会丢2-4个ping包业务无感知。主keepalived节点执行systemctl stop keepalived模拟服务进程故障观察VIP是否漂移到备机Nginx业务是否持续可用。更强硬一点的做法拔掉主服务器网线模拟整机宕机。这时候VIP应该由备机接管外网用户几乎无感。切换测试做完还要做一个恢复测试。把主设备重新加电确认它会延迟10秒后抢占回MasterVIP回到主节点全程不能出现震荡。恢复测试很多人不做但恰恰是恢复过程最容易出问题。5.3 抓包验证协议运行状态配置和ping都正常不代表协议真的在工作。最直接的办法就是抓包看协议报文。在核心交换机上用抓包工具过滤VRRPtcpdump -i any vrrp -n正常状态下你应该每隔1秒能看到一条VRRP广播报文source地址是Master设备的真实IP说明Master在正常向外通告。如果抓不到VRRP报文优先检查组播放通和vrid一致性。keepalived节点上也可以抓tcpdump -i ens192 vrrp -nn抓包是排查“一切看起来都正常但切换就是失败”的利器。协议层面有没有在收敛、VIP有没有真正漂移、报文是不是被中间策略丢弃抓一次包就知道不用瞎猜。5.4 性能验证与长稳压测连通性OK之后还要做量化的性能验证。我用iperf3做吞吐测试验证VIP承载业务流量的能力iperf3 -c 10.0.100.51 -p 5201 -t 60 -i 5两端服务器上都要安装iperf3服务端用-s启动。这里要注意VIP迁移之后iperf客户端仍然连10.0.100.51但实际响应的是当前持有VIP的那台物理机这个结果就能逼真模拟真实业务流量的路径。长稳测试也不能省。新网络跑通之后我习惯至少打流2小时以上观察丢包率、延迟抖动、VRRP切换次数。丢包率超过0.1%或者延迟抖动明显优先查二层环路、端口协商速度以及链路聚合的负载不均。稳定压倒一切网络工程尤其如此。6. 常见问题与排查技巧实录6.1 问题速查表问题现象可能原因排查方法VIP ping不通虚拟IP被占用VRRP状态异常没有放行VRRP组播查看VRRP状态抓包确认检查IP冲突主备切换后服务仍然中断应用没有监听VIPARP缓存未更新健康检查误判检查Nginx监听地址清ARP缓存手动跑健康检查脚本两台设备都是MasterVRRP组播被拦截auth_pass不一致vrid不一致放行224.0.0.18核对配置一致性抓包看通告MAC地址漂移告警两个网卡上绑了相同VIPbond配置不当检查网卡绑定模式确认VIP只绑定在bond口切换时间远超预期advert_int过大track_script轮询间隔太长preempt延迟过长调小advert_intinterval改2秒合理设置延迟6.2 几个值得单独说说的坑第一个坑虚拟IP被其他设备占掉。有一台旧服务器一直没有下线地址恰好是规划里的VIP结果VIP一直起不来。这种问题最隐蔽因为你看两台配置都没问题但就是不通。排查方法很简单先在三层交换机上ping一下这个VIP看返回的MAC地址是不是Master设备的接口MAC。如果不是那就是有别的设备占着这个地址。所以规划阶段一定要确认全网所有地址都登记在案没下线的设备绝对不放过。第二个坑keepalived健康检查脚本权限忘加。脚本写好了忘了chmod xkeepalived执行脚本时权限不足每次都返回失败主节点一直被降权VIP反复在两边跳业务一断一断的。这种情况好在检查日志能很快发现。我的经验是脚本写完先手动执行一遍看返回码确认能正常退出再交给keepalived去调用。第三个坑核心交换机VRRP报文走了业务口被禁。有些安全策略会在二层端口上做组播抑制VRRP这个组播一旦被抑制两台核心就互相联系不上全以为自己是主设备。这个问题的表现和中间防火墙拦截一模一样都是脑裂。排查时重点看交换机的组播过滤配置该放行的放行该单独划心跳链路的就单独划。第四个坑切换后VIP在备机网卡上存在但业务入口不通。备机的Nginx没监听VIP或者监听了但upstream里的后端地址写错了。这种情况测试切换时最容易暴露所以我上面的实施顺序里特意强调切换测试必须连同业务请求一起验证不能只看VIP是否漂移到位。VIP在不在和业务通不通是两回事。第五个坑恢复测试时主设备抢占过快导致网络震荡。默认preempt模式没有延迟的话主设备一恢复就抢占VRRP状态反复切换终端会连续丢包。所以我在主设备上专门加了10秒抢占延迟让网络先稳定一小会儿再切回去。这个细微的配置差异在真实恢复操作里体验差别特别大。7. 交付物和日常运维扩展7.1 项目交付必须带哪些东西网络工程项目不能光把设备调通就算完工。我这次项目的交付物做了四份第一份是IP地址规划表。包含每个VLAN、每个网段、每个固定IP归属于哪台设备、哪个端口、用途是什么。这张表是整个后续运维的地图没有它一切免谈。第二份是拓扑图。不只是二层交换机连线图要带着VLAN、网关、VIP、物理IP画一份三层逻辑图。哪里是主、哪里是备、VIP漂移路径是什么一看就懂。第三份是配置备份和变更清单。两台核心、两台业务服务器的当前配置全部导出存档同时记录这次项目做了哪些变更、为什么这么改方便后续审计。第四份是操作手册。内容包括日常巡检命令、如何查看VRRP主备状态、如何手动切换VIP、日志在哪看。这套手册我习惯写成“照着做就能完成常见操作”的口吻因为以后值班的同事不一定有项目上下文越傻瓜越好。7.2 后续还能怎么扩展这个项目的架构本身留了不少扩展余地。核心层面如果节点增加可以在VRRP基础上引入多台设备做负载分担也可以把三层网关升级为动态路由协议比如OSPF在大规模园区里更灵活。应用层面keepalived维护的VIP前面可以再加一层负载均衡把流量分发到更多后端节点健康检查也可以从端口探测升级为HTTP状态码和延迟综合评分。监控层面VRRP状态和keepalived漂移事件应该接入告警系统切换发生后第一时间通知到人而不是事后从业务部门那里听说。我个人的习惯是每次做完一个项目都会抽时间把“可复用的模板”整理出来比如通用的VRRP配置片段、keepalived脚本模板、IP规划Excel表。下次做类似项目直接拿模板改参数省时省力还能避开这次踩过的坑。这个项目从头到尾做下来我的体会其实很简单网络工程的复杂度往往不在设备配置上而是在决策细节里。IP地址规划时多花一个小时后面可能省下十几个小时的排查时间VIP高可用配置时多想一步健康检查的问题紧急故障时就能少挨一小时的电话轰炸。做网络这行方案要简单配置要能审计出了状况要能快速定位。这套思路放到任何一个以太网工程里都适用剩下的就是在实践中不断打磨细节了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
