干货分享高性能负载均衡介绍
Posted 苏研大云人
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了干货分享高性能负载均衡介绍相关的知识，希望对你有一定的参考价值。
一
高性能负载均衡出现的背景
1.1 移动需要高性能负载均衡的场景
流量会出现短暂爆发式增长的场景：如运营商月底或年底集中在一个时间段去拉取话费统计，消费清单、新品发布，活动，秒杀等；流量需求一直很高的场景：如基于Docker平台的服务、软件自定义数据中心(SDDC)、日志中心、数据库仓储中心，内容服务平台如视频，下载，SDN等。以上两个场景，对带宽，延迟的要求非常高，高性能负载均衡就显得非常必要。
1.2 开源负载均衡面临的问题
现有的开源软件并不会把周边生态完全开源。配置，运维，部署，监控等，无界面，无web端。复杂场景配置管理，完全靠手动。而且现有的都是基于特定场景开发配置，不能完全符合场景需求。代码不可控，依赖社区，反馈慢，bug跟进不及时。增加或修改功能的时候，需求无人响应。
1.3 苏研的高性能负载均衡软件
基于DPDK，网卡性能被充分的压榨，可以接近网卡线速的转发处理能力。支持DR、NAT、FNAT、TUNL等主流模式之外还支持ECMP/OSPF协议，可以集群化部署，N+1冗余。有专人维护，研究如何集群化，多种模式部署。基于开源的代码二次开发，增加配置，监控，告警，等功能。Bug和特性有人反馈跟踪，需求积极响应。基于DPDK的负载均衡配置比较繁琐，在解决问题的同时，也可以储备相关的知识和人才。在和LVS对比测试中，包转发性能达到了前者的3~4倍。而且随着CPU核心的增加，处理报文的能力线性增加。
1.4 负载均衡各阶段的方案
7层或者4层负载，面向的业务场景不同。没有一成不变的负载方案，需要根据企业流量和主机的拓扑，主机的数量等等，灵活的做出选择和更改。
早期阶段
第一阶段：利用nginx或Haproxy进行单点的负载均衡，这一阶段服务器规模刚脱离开单服务器、单数据库的模式，需要一定的负载均衡，但是仍然规模较小没有专业的维护团队来进行维护，也没有需要进行大规模的网站部署。这样利用Nginx或Haproxy就是第一选择，此时这些东西上手快， 配置容易，在七层之上利用HTTP协议就可以。
中期阶段
第二阶段：随着网络服务进一步扩大，这时Nginx已经不能满足，这时使用LVS或者商用F5就是首要选择，Nginx此时就作为LVS或者F5的节点来使用，具体LVS或F5的是选择是根据公司规模和预算来选择，一般来说这阶段相关人才跟不上业务的提升，所以购买商用的F5做负载均衡已经成为了必经之路。
后期阶段
第三阶段：这时网络服务已经成为主流产品，此时随着公司知名度也进一步扩展，相关人才的能力以及数量也随之提升，随着公司流量的暴涨，需要在性能方面下功夫。这时定制基于DPDK等零拷贝技术的高性能负载均衡作为首选。
二
高性能负载均衡介绍
2.1 简介
2.1.1 网络拓扑
2.1.2 技术架构图：
高性能负载均衡是基于DPDK的4层负载均衡器。基于阿里巴巴/ LVS衍生而来。使用了DPDK的核绑定，无锁队列，自定义轻量级IP协议栈等技术，所有报文都在用户态处理。绕过了内核协议栈复杂繁琐的处理流程。报文不需要从用户态到内核态的频繁拷贝，直接使用UIO驱动。
2.1.3 报文处理流程
硬件中断-->放弃中断流程-->用户层通过设备映射取包（UIO）-->进入用户层协议栈-->逻辑层-->业务层
2.2 功能模块
2.3 高性能负载均衡各种主要模式介绍
高性能负载均衡原生继承了LVS的三大模式（DR，NAT，TUN），但是因为DPDK接管了网卡，没有协议栈，在配置和管理方面会有很大的不同，下面会一一介绍。
2.3.1 DR模
（1） DR模式的工作过程
l Client 发送request包到LB服务器的VIP上
l 被选择的RS把应答包直接传给Client
（2）使用DR模式的特点
l 负载均衡服务器首先需要LAN IP。 （单臂模式下，必须与VIP不同）。
l RS和负载均衡服务器必须位于同一子网（on-link）中。
l 在RS：必须将VIP添加到其lo接口。
l 在RS上：arp_ignore必须设置为lo接口。
2.3.2 Tunnel隧道模式
隧道模式要求RS支持IP隧道。应配置VIP并在RS上设置arp_ignore。
（1） 隧道模式的工作过程：
l Client 发送request包到LB服务器的VIP上
l VIP按照算法选择后端的一个RS，并将记录一条消息到hash表中，然后将Client的request包封装到一个新的IP包里，新IP包的目的IP是RS的IP，然后转发给RS
（2） 隧道模式的特点：
l 负载均衡服务器不需要和RS在一个网段
l 因为需要封包解包，需要RS支持IP 隧道协议
2.3.3 NAT模式
（1） NAT模式的工作过程
l RS收到request包后，发现目的IP是自己的IP，于是处理请求，然后发送reply给LB
l 从Client来的属于本次连接的包，查hash表，然后发给对应的RS
（2） NAT模式的特点
2.3.4 Full-NAT模式
（1） Full-NAT模式的工作过程：
l RS收到request包后，发现目的IP是自己的IP，于是处理请求，然后发送reply给LB
l 从Client来的属于本次连接的包，查hash表，然后发给对应的RS因为后端只能看到LB的DIP，如果后端RS服务器需要获取Client IP port，需要安装TOA模块。
（2） Full-NAT模式的特点
l 外部和内部IP互相隔离，抗攻击，可以跨网段，VLAN部署。
l 不同于NAT和DR要求LB和RS位于一个子网，FULLNAT对于组网没有要求。只需要保证Client和LB、LB和RS之间网络互通即可。
l 相比NAT模式等，多了一次Source IP更新，性能会有所下降。
2.3.5 Full-NAT和NAT区别
Full-NAT模式Packet IN 时，除了做 DNAT，还做 SNAT（用户 IP->内网 IP），从而实现LVS-RS 间可以跨 VLAN通讯， RS只需要连接到内网
(1) NAT模式
NAT模式下报文变化
发送 接收
cIP ---> vIP
cIP ---> rIP ( DNAT )
rIP ---> cIP
vIP ---> cIP ( SNAT )
(2) Full-NAT模式
Full-NAT模式下报文变化：
发送 接收
cIP ---> vIP
dIP ---> rIP ( SNAT + DNAT )
rIP ---> dIP
vIP ---> cIP ( SNAT + DNAT )
(3) Full-NAT的问题：
l 相对于NAT多了DIP的来回转换，性能比NAT损失10%
l RS无法获得用户IP,但是可以解决
为了解决这个问题我们提出了TOA的概念，主要原理是：将Client Address放到了TCP Option里面带给后端RS，RS上通过TOA内核模块hack了getname函数，给用户态返回TCP Option中的Client IP。
2.4 高性能负载均衡总结
2.4.1 优点
l DPDK加成，可以充分利用网卡性能
l 摈弃纷繁复杂的内核协议栈，带宽和处理延迟有很大提升
l 协议栈可控，功能和业务逻辑完全掌握在自己手中
l 对比测试，无论在哪种模式，和原生的LVS对比，性能都有很大的提高
2.4.2 缺点
l 没有完整的协议栈，DPDK接管之后，没有内核协议栈的网卡，虽然可以用KNI弥补，但是KNI达不到DPDK的性能，对性能要求高的协议，用原生协议栈或者自己实现，需要抉择。
l 因为报文都在用户态处理，自然所有的流程都跑在用户态代码里，需要主程序自己实现业务逻辑，相比于内核完整的生态和强大的代码，出错的概率增大，对代码质量要求大大提高。
l 相比于原生网络的配置，DPDK相关的运维会比较复杂。可能对于某些协议的支持不完全，就会有很多的麻烦。对运维的要求比较高。
l DPDK需要绑定CPU核心，基于轮询的机制，不管报文多少，都是100%CPU使用率。如果带宽不高，会浪费CPU核心资源，耗费电量。
寒
END
露
1. 【干货分享】
2.
3. 【
以上是关于干货分享高性能负载均衡介绍的主要内容，如果未能解决你的问题，请参考以下文章