在2020网络数据平面峰会上,来自紫金山实验室未来网络中心的研究员——沈洋给我们带来了《基于可编程交换机和智能网卡的四层负载均衡器》的主题演讲。
本次演讲主要包括三个部分:L4负载均衡器的现状调研,可编程交换机的LB卸载,以及智能网卡+OVS的LB卸载。
(文末有视频)
L4负载均衡器的现状调研
首先,来了解下什么是四层负载均衡器。
什么是L4负载均衡器?
比如,在云数据中心里部署一组服务,以HTTP方式对外提供API接口,如下图所示,可以看到,HTTP API URL主要由两部分组成,一个是IP地址+四层端口号,另一个是path路径,二者组成api的唯一标识。为了考虑大连接并发,通常部署多服务实例进行负载分担,每个实例以容器POD或者虚机形式部署,拥有属于自己的后端IP地址。
那么问题来了,用户如何找到这些成千上万的后端IP地址?
业界通用的解决方案是对外仅暴露一个或少量VIP地址,通过层层负载均衡器来实现后端分担和定位。比如,最接近service的是7层负载均衡器,它识别到URL path信息,实现服务发现和负载均衡,常见的有nigix;接着通过4层负载均衡器,实现对nigix集群负载分担;再通过BGP/IGP路由协议,实现对L4负载均衡器的集群的负载分担。当然,这还没完,比如还会有DNS等。
简单总结一下,这张图中,存在三级均衡策略,包括:
由于4层以上都是有状态连接,只有确保源一致性,才能保证服务不中断,所以这里强调L4、L7层要求源一致性。
针对负载均衡器的一些关键技术,总结如下:
沈洋认为,考验一个负载均衡器产品最核心水平的三点包括:是否支持大session会话数量、新建流并发能力、以及转发性能。
业界情况
Linux:LVS
Linux内核的LVS,也就是IPVS。它是很多互联网公司构建负载均衡的首选,大致总结一下它的特点:
阿里巴巴:SLB
阿里巴巴的SLB,开始时基于LVS,做了大量扩展和优化,包括以下4点:
1、LVS-FULLNAT转发模式:提出了TOA的概念解决RealServer无法获得用户IP。主要原理是:将client address放到了TCP Option里面带给后端RealServer,RealServer上通过toa内核模块hack了getname函数,给用户态返回TCP Option中的client ip。
2、LVS-SYNPROXY主要原理:参照linux tcp协议栈中syncookies的思想,LVS-构造特殊seq的synack包,验证ack包中ack_seq是否合法-实现了TCP三次握手代理。也就是client和LVS间建立3次握手,成功后,LVS再和RS建立3次握手;
3、LVS-集群:通过OSPF ECMP + seesion全局同步,来实现集群化;
4、性能优化:第一,多队列网卡,绑核;或使用google提供的软多队列-RPS;第二,对keepalived进行了优化,主要将网络模式从select改为了epool;第三,关闭网卡LRO、GRO功能关掉,尤其是broadcom的网卡。
爱奇艺:DPVS
爱奇艺的DPVS,源于阿里巴巴LVS,主要实现了DPDK的转发加速,相关的源码可以在github上找到,不过很久不更新了。
京东:SKYLB
京东 skylb,依靠路由协议来实现IP层ECMP,也就是的第一级负载均衡,设计实现一套高可靠、高性能、易维护及性价比高的L4负载均衡系统。
美团:MGW
美团 MGW,有三个显著的技术特征:
关键技术1:利用网卡的RSS和flow director特性实现无锁编程;
关键技术2:利用IP ECMP+全局有状态连接表实现集群高扩展和高可用;
关键技术3:利用Google Maglev实现源一致性Hash。
总结一下美团MGW的特点:
1、利用DPDK实现kernel bypass;
2、为了获得较强的网络环境适应性,选择FULLNAT,牺牲一定的性能;
3、session全局同步,复杂度高;
github:GLB-director
GLB-director的亮点:
从通用性的角度来看,GLB-director有一些不足:
Github glb-director最大的技术特点是利用GUE隧道,实现无状态连接一致性。相关代码也可以在githhub上可以下载,建议有兴趣的同学读下它的源码。
F5:BIG-IP
商用负载均衡器产品F5 BIG-IP,这里取了它的两款高端产品,列举核心指标。它的i15800系列最大吞吐可以做到320G,基本算是业界最强了。需要提及的是,nigix在19年3月份被F5以6.7亿美金收购,F5宣称会继续在nigix开源社区投入,此刻你是否想到了JDK8?
小结与展望
下面沈洋讲述了紫金山实验室相关的一些工作进展情况。
可编程交换机的LB卸载
P4可编程芯片
首先来看看基于P4可编程的芯片当前业界的一些情况:
L4 LB(NAT模式)
随着转发面可编程语言和芯片可扩展流水技术的涌现,使用交换芯片实现负载均衡器将成为可能。紫金山实验室当前主要研究了主要NAT模式的4层负载均衡器的实现,然后用可编程交换机进行卸载。先来看一看什么是NAT模式。
看上图,从用户侧去访问后端的服务,经过4层负载均衡器处理的时候,用户看到的目的IP是VIP,也就是暴露了虚拟IP的地址,然后在负载均衡器上,目的IP被替换成某个后端的的地址,叫RIP,比如,当前连接选择的后端是RS2,那就替换成RIP2地址转发到后端,回程的报文在经过轮番处理的时候,把原IP地址再替换回Vip,然后转发到用户端,当然在NAT转换的过程中,四层端口号也可能会做相应转换。可以看到,从用户侧到服务侧,这条路线在均负载均衡器上做了一次DNAT的转换,回程的报文做了一次SNAT的转换,这就是所谓的NAT模式。
在实现的过程中有三张关键的表,这三张表来指导4层负载均衡器业务逻辑的实现:
第一张是虚拟服务的表,主要有后端提供服务的列表。另一张是后端的真实服务的表,主要信息包含后端的Rip、Rport的信息。还有一张是连接表,连接表是动态生成的,主要信息有用户的IP、用户的port、以及选择哪个后端的地址和Port的信息。
NAT模式的4层负载均衡器,它的数据平面pipeline如何设计?刚才提到的三张表,用p4的语言来插入到现有的二三层功能,再到pipeline,这三张表第一张是 vs table,放在RMac之后,如果命中,再走连接表,运动后修改目的地和目的端口号,放在route表处理。即便交换机是可编程,回程的流量走的流程还是固定的,要先经过vs table去处理,这种情况回程是不会命中的,miss会走到rs table。如果命中,要修改原端口号,再到route表处理;如果miss,那不做修改,正常走route表处理。
控制平面与数据平面API接口
再来看看那上行和下行两个方向的流量,在负载均衡器上进行的一些查表的动作以及修改报文的动作。
典型应用:L4LB与DCgw合一的云数据中心组网方案
需要进一步完善:
在研究和落地的过程中遇到的最大的一个问题:ASCI芯片表容量非常有限,无法满足LB大连接表需求。
智能网卡+OVS的LB卸载
由于硬件交换机表容量受限,我们接着想到能否利用可编程智能网卡来卸载L4LB功能?
有三个问题等待研究:
①智能网卡能否提供大容量表项?
②数据平面性能如何,pipeline应该如何设计?
③控制平面应该如何设计? 应该选择怎样的offload接口?
先来看看目前智能网卡的主流方案有哪些,以及各自优缺点。通过综合比较,紫金山倾向于优先考虑基于FPGA和可编程ASCI的smart nic。
智能网卡能否提供大容量LB表项?
通过和一些厂家接触了解到,网卡可以外挂memory来存储转发表,如此一来,表容量问题将有可能得到解决;但是,吞吐、时延、表容量能否鱼和熊掌兼得?这个问题还在需验证。
基于L4LB控制平面与数据平面设计
先看一下开源的云平台对load Balancers接口的一些定义。
openstack LBaas2.0
K8s Service
OVN+OVS的L4LB功能
智能网卡offload驱动接口
紫金山的目标是将vxlan/geneve隧道、L4LB offload到智能网卡,实现host overlay、L4LB硬化。关于技术选型,紫金山最终选择OVN+OVS,借助开源社区,快速构建能力;offload接口选择overlay tc flow + underlay switch dev,简化数据平面pipeline。
可编程交换机与智能网卡的组合拳
通过实现可编程交换机和智能网卡来硬化LB功能,在云数据中心里,也需要一个组合方案,可以从上图看到,DC GW的点可以兼做LB,另外,在服务器侧,通过vSwitch和智能网卡来卸载vxlan隧道,加上4层负载均衡的功能,实现从服务器侧到GW都能提供LB功能。
如此组合有一些优势和弊端,交换机上明显的弊端是其表容量有限,不过其转发性能较高,那我们如何扬长避短,发挥各自优势?如何识别大象老鼠流,大象流引导到交换机,老鼠流引导到服务器上处理?硬件表容量超标时,如何进行冷热分离、软硬结合?如何将LB服务能力池化管理,支持服务自动感知、故障转移、按需扩缩容?如何进行流量模型调度,即业务链自动编排和管理?如何与openstack、k8s以及一些商用云平台自动化对接?
答案都是通过SDN控制器解决上述问题。
总结
事物的发展总是螺旋式上升,网络通信数据平面在追求高性能和扩展性道路上一直孜孜不倦,相信未来总有一天能找到像CPU指令的自由、ASCI芯片高性能的结合体,为人们提供廉价、便捷、高效的通信载体。
以上就是沈洋分享的全部内容。