负载均衡:浅谈常用场景锐捷设备的优化方法 | 运维实战家 网络

2020-11-20 224

 
 


前言


随着互联网业务的高速增长,为满足数据中心灵活扩展高带宽的需求,端口聚合或者是路由ECMP被普遍应用。


目前锐捷数据中心交换产品负载均衡模式基于流模式的负载均衡,实际负载均衡基于IP报文五元组或者增强模式。负载均衡模式因子包括:源/目的MAC、源/目的IP、源/目的L4端口号。增强模式还可以支持数据中心特性字段,例如支持协议类型如MPLS报文、FCOE报文类型等字段。


涉及到负载均衡的场景包括二层AP口、三层AP口、路由ECMP,默认三者共用同一个全局的负载均衡模板。AP可以基于单个端口调整负载均衡模板,路由ECMP只能共享全局定义的负载均衡模板。


普通型的负载均衡,其中二、三层AP口默认基于源/目的MAC;路由ECMP默认基于源/目的IP。以报文匹配负载均衡因子的方式来生效,比如一个报文是IPv4报文,默认负载均衡模式,二、三层AP口都是以源目的MAC进行负载均衡,而ECMP端口则以源/目的IP来进行负载均衡。如果修改了为IP/PORT的负载均衡,则二三层AP/路由ECMP都以IP/PORT的负载均衡为准。


增强型的均衡模式,以报文匹配负载均衡因子的方式来生效。比如一个报文是IP报文,增强型有默认定义IPV4的字段负载均衡以源目的IP为准,如果需要调整ipv4的均衡算法只能调整ipv4 field字段。无论二三层AP/路由ECMP都如此。


负载均衡模式的配置建议


       

第一步:


一般情况下,采用普通模式进行负载均衡,采用源目的IP/源目L4port,可以满足绝大部分的HASH负载均衡模式。


注:全局模式配置,对于二三层AP/路由ECMP公用模板,共同生效。


即:


aggregateport load-balance src-dst-ip-l4port


       

第二步:


如果存在负载均衡较差的情况,可以在HASH因子不变的情况下修改为增强型的模式进行使用。


load-balance-profile ecmp

ipv4 field src-ip dst-ip l4-src-port l4-dst-port


aggregateport load-balance enhanced profile ecmp


show aggregatePort load-balance可查询当前选择的负载均衡因子,若涉及到增强模式,还需要show load-balance-profile XXXX查询增强模板,针对不同报文的负载均衡方式。


 
 


一般情况下通过上述两种方案就可达到均衡效果,但在一些特殊场景下又有哪些地方需要注意呢?请看下文讲解:


场景一

CDN场景下出口部署PBR多个等价下一跳情况


 

图1:CDN场景下出口部署PBR多个等价下一跳


如图所示,在CDN场景下在出口连接多个运营商时,往往需要匹配IP为某运营商如电信时选择下一跳为电信的多个互联端口,互联端口间要求流量负载均衡。


route-map pbr permit 10

 match ip address Telecommunications

 set ip next-hop 10.1.1.1

 set ip next-hop 10.1.2.1


针对该场景默认情况下多条链路为主备模式,要达到负载均衡效果需在全局下配置:


ip policy load-balance


场景二

VSU开启本地优先转发时出口负载均衡


 

图2:开启VSU本地转发,当主备机输入流量不一致


 

 图3:开启VSU本地转发,当主备机输出端口数不一致


如图所示,当使用VSU组网时,由于设备默认开启了本地转发,当主备机输入流量不一致,或输出端口数不一致时,如果要实现在所有ECMP出口之间负载均衡,可以考虑关闭默认的VSU本地转发,但此时出向流量会经过VSL链路,会给VSL链路带宽带来压力


VSU模式下配置


no switch virtual ecmp-lff enable


注意:如果该场景下存在ECMP下一跳出口为AP口,我们的AP/ECMP采用相同的算法,而且根据业务的流量特征选择相同的因子,就会导致LACP上面的流量会由于HASH极化而集中到其中的一条链路上,此时推荐在增强型负载下增加配置扰动因子来解决


load-balance-profile ecmp

ipv4 field src-ip dst-ip l4-src-port l4-dst-port

hash-disturb 5



场景三

LVS负载均衡调度器集群与TOR通过ECMP互连


数据中心LVS集群通常通过ECMP和TOR互联,如果通过动态路由协议在TOR和LVS集群之间生成ECMP路由,当ECMP某条链路因故障失效后,动态路由协议会重新收敛,从TOR到集群的流量会重新均衡,这就打乱了集群成员机上原来维护的会话状态,整个集群需要重建会话,导致部分会话中断。


该场景下推荐配置ECMP CLUSTER 特性,使用ECMP CLUSTER后,如果ECMP 路径数量减少,只会将失效链路上承载的流量均衡到活跃链路上,活跃链路上承载的流量不变,如果ECMP路径数量增多,会将原先活跃链路上的部分流量切到新增链路。


 

图4:TOR与LVS集群之间通过ECMP互联

  

 

图5:当TOR与LVS最右侧链路中断后流量转发规则



全局模式下


ecmp cluster enable


注意,开启该特性前提需要使用增强型负载均衡模式


场景四

多台同厂商设备级联且采用聚合或者ECMP等价负载的情况


 

图6:多台同厂商设备级联且采用聚合

或者ECMP等价负载的情况


在数据中心场景里,如果出现图中LEAF/SPINE交换机都是同型号设备(或者同芯片算法)。对于LEAF交换机来说,有四个不同的流,其中流1,2选择了左边的链路,到达了SPINE-1设备。由于SPINE-1和LEAF的HASH算法完全相同,所以在做HASH时,SPINE-1将流1,2归为了同一类,都选择了左边的链路进行转发,如此计算SPINE-2将流量3、4选择右边链路进行转发。


该场景下建议在配置增强型负载均衡模式后,不同层级设备调整均衡算法,避免极化现象


aggregateport algorithm mode XXX


场景五

对收到经过GRE封装后的报文要求基于内层报文进行HASH实现负载均衡


 

图7:对收到经过GRE封装后的报文要求基于内层报文进行HASH实现负载均衡拓扑


       

场景介绍:


某数据中心客户反馈机房一组62H下挂的2个服务器和62H来建立OSPF,并同时发布一个用于建立GRE隧道的地址,比如是10.1.1.1,和远端的一个在其他节点的路由器上的地址来建立GRE隧道,GRE隧道的源地址是2个服务器发布上来的一个VIP地址,目的地址是远端路由器地址,源目地址已经通过路由打通了,我们62H相当于是GRE流量的过路设备,目前发现62H下挂的2个服务器只有其中一个有接收到远端路由器经过GRE封装发过来的流量。


该场景下,由于我司交换机默认情况下对经过的GRE流量只能基于外层报文进行HASH,无法获得均衡效果,可以通过以下命令修改对GRE报文支持过路的内层均衡


全局下


aggregateport hash-header inner


注意,开启该特性前提需要使用增强型负载均衡模式

最新回复 (0)
返回