【IT168 技术】本文转载自微信公众号“ 鹅厂网事”(ID：tencent_network)，作者：薛长鑫。

　　随着腾讯业务的快速发展，腾讯网络所承载的流量也在成倍的增长，网络容量从早年的10G快速增长到100G，1T，10T甚至更大。受制于网络技术的发展和成本的考虑，当前网络端口容量主要还是以10G为主，近两年腾讯也逐步开始使用了100G端口，但是单端口容量的增长，仍远远无法满足腾讯对带宽的需求，所以多链路捆绑，路由ECMP等技术，在腾讯网络中大量使用。链路数量的的增加在提升网络容量的同时，也对网络运营带来了很多问题。记得早年刚开始接触网络的时候，曾经很简单的理解1条10G链路与10条1G链路捆绑在一起是等同的，但在工作中慢慢发现，流量并不会完全均匀的分布在10条链路上，这里涉及到多路径hash问题，接下来简单介绍下腾讯数据中心网络中多路径hash遇到的几种常见问题。

　　一、hash极化问题

　　某日，腾讯网络监控发现，LC(IDC内网核心设备)到MAN(城域网设备)的一条链路带宽撑爆了，排查发现，LC-1到MAN-1的带宽已满，而LC-1到MAN-2的链路几乎没有流量，查看LC的路由表，转发表等都没有异常，最后定位是hash极化问题造成的。

　　什么是hash极化呢?

　　以下图为例，在这个故障案例中，腾讯IDC网络的L交换机(三层接入设备)和LC交换机使用的是同一个型号的设备，并使用了相同的hash算法，对于L交换机来说，有四个不同的流，其中流1,2选择了左边的链路，到达了LC-1设备。由于LC-1和L的hash算法完全相同，所以在做hash时，LC1将流1,2归为了同一类，都选择了左边的链路进行转发。

　　下图场景中也可能存在hash极化问题。当某一设备的ECMP条目数与lacp捆绑链路数一致的情况，如果hash算法一样，算出的结果一致，lacp上面的流量会由于hash极化而集中到其中的一条链路上。

　　为了避免hash极化问题，在网络设计时，需要注意以下几点：

　　1.多台同厂商设备级联情况

　　a.避免在级联的设备中相邻的2台使用相同的负载均衡算法

　　b.当前部分厂商设备在hash计算时候，除传统的五元组外，可以增添其他因子参与计算，避免hash计算结果相同的情况

　　2.一台设备同时进行ECMP和LACP负载情况

　　a.注意ecmp总数量和每个lacp的链路数量是否存在比例对应关系，判断是否可能出现极化现象

　　b.尽量保持ecmp和lacp的负载均衡算法不一致，避免出现极化现象

　　注：MAN(Metropolian Area Network)：城域网

　　LC(LAN Core)：内网核心

　　二、hash算法选择问题

　　对于网络设备的hash算法，可以基于五元组+源目mac地址进行任意组合，通常我们都会选择基于源目IP加源目端口的方式进行hash，因为这样参与hash计算的因子较多，流量在多条链路上的均衡性较好。但是在有些场景下，需要设置特定的hash算法。

　　以腾讯LVS专区网络为例，LVS交换机从LD(负载均衡)学习到同一目标地址的等价的路由。LVS交换机收到数据后，会根据hash算法，将数据转发到负载均衡设备，再由LD将数据转发到后端具体负责业务处理的服务器上。对于部分业务，例如支付类的业务，同一个用户的一次支付过程会调用多个业务服务，业务侧要求一次支付的过程都落在同一个处理服务器上，也就是一个源目的ip的会话必须hash到同一台LD进行转发。

　　在早期的网络设计中，LVS交hash换机的hash算法是基于源目IP+协议端口进行计算的，由于目标协议端口在交互过程中可能发生变化，导致了部分业务的异常。在此场景中，LVS交换机的hash算法确定为基于源目IP，确保同一个源目IP数据流，只会被转发到同一台LD上。

　　三、Overlay网络中的hash问题

　　随着云网络的快速发展，网络虚拟化技术已经越来越多的在腾讯网络中应用，当前主流技术是基于overlay的网络。

　　如图所示，子机用户访问外部网络时，母机在子机发出的原始报文外层又添加了一层新的IP包头，在某些情况，由于子机发出的报文过大，再添加一个新的IP包头后，报文超过了母机网卡MTU的大小，这时母机会对该报文进行分片，分成了如图所示的两个报文。

　　对于第一个报文，由于报文包含了两层IP包头，部分网络设备在进行hash计算时，会基于内外层包头一起计算，于是分片报文被转发到了不同的LD设备，导致业务失败。

　　针对此类问题，当前主要有以下三种解决方案：

　　1)调整子机网卡MTU大小，避免母机二次封装后报文过大而造成分片;

　　2)修改业务逻辑，母机收到较大的子机报文后，先对报文进行分片，再进行外层封装;

　　3)调整网络设备只基于外层包头进行hash，而不考虑内层IP包头。

　　对于方案三，当前并不是所有厂商设备都支持，考虑到后续类似场景会越来越多，目前腾讯对新引入的设备，要求能够支持此特性。

　　后续展望

　　Hash结果可视化

　　当前网络运营的一大痛点在于，当业务反馈数据转发存在异常时，由于网络中存在海量节点，链路，导致无法快速定位到故障点，根本原因，就在于很难知道异常流量，承载在那条路径上。目前大多数网络设备对于流量hash的结果，都是不可视的，如果能够实现hash计算结果可视化，那么任何一条流量的转发路径，我们就可以非常清楚的知道，故障处理起来，将变得轻松容易很多。

　　Hash计算的动态均衡化

　　当前网络设备的hash算法主要还是基于数据流的五元组进行hash的，在很多场景下，数据流量还是没法在多条链路间做到较为均匀的转发。如果在hash计算时，能够将当前链路流量大小也做为hash计算的一个因素，将极大提升链路的利用率。