负载均衡入门

提纲

1. ADC 行业现状
2. ADC 原理
3. ADC 的实现方式

为什么是 ADC 而不是负载均衡？

功能的扩展

解决了什么问题

• 可用性（Availability）
• 伸缩性（Scalability）
• 性能（End-user performance）
• 数据中心资源利用率（Data center resource utilization）
• 安全（Security）

行业现状

Gartner 魔力四象限

行业趋势

从硬件到软件，从裸机到云

从单纯的负载均衡到与网络，应用和安全 WAF 一起组合。

API 网关：Istio，Kong

基本原理

实现方式：

1. 芯片
2. x86 服务器：ipvs，ovs，dpdk

设计的技术栈：硬件(网卡指标)，驱动（网卡驱动），内核（网络协议栈），网络编程，基本数据中心网络，应用（http 各种优化）。

分层：

1. 跨数据中心的负载均衡
2. 数据中心内的负载均衡
3. 服务级别的负载均衡

GLB

LSLB：Local Server Load Balance

GSLB：Global Service Load Balance

DNS：负载均衡

L4：基于 IP 和基于连接

L7：基于 URL

物理机，虚拟机，容器

部署模式

1. arp
2. 路由

旁路模式（FULLNAT）

单臂模式（SNAT）

全代理模式

本地三角模式

1. 通过修改目的 mac
2. 绑定 loopback 网卡：运维复杂
3. 性能好， LB 只处理入流量
4. 关闭 arp

SNAT

DNAT

1. 只修改目标 ip
2. 服务器网关变为 LB 网关
3. 客户端直接访问服务器，由于会转发给 LB，导致丢包

穿透模式（SNAT，FULLNAT）

DNAT

FULLNAT

IP Tunning

运行模式

• 全代理模式
• 转发模式

基本功能

负载均衡算法

静态负载均衡算法

轮询

比率

优先级

动态负载均衡算法

最少连接数

最快响应时间

自定义负载均衡算法

运用机器学习，与监控，流量，负载联动的动态负载均衡

其他：

1. 加权
2. 加权轮询
3. 哈希
4. 一致性哈希
5. 预测模式：机器学习
6. 源地址保持

会话保持

1. 简单会话保持：源地址会话保持
2. Cookie 插入模式：在负载均衡器返回的时候插入
3. Cookie 重写模式：服务器为空 cookie，负载均衡器对 cookie 进行重写
4. Passive Cookie 模式：服务器包含 cookie，负载均衡器不做任何处理
5. SSL Session ID 模式：在交换证书的时候记录 SSL session ID
6. HTTP Header的会话保持：

健康检查

方式：推，拉（自定义，SDK）；

检查指标：网络层（ICMP，TCP，UDP），应用层（HTTP，FTP，DNS，SMTP，POP3），及自定义关联健康检查。

流量监控

1. 物理层流量
2. 应用流量

安全

1. 防 DDos 攻击：Syn Cookie
2. 访问控制(ACL)：基于协议，端口，设置服务的白名单（黑名单）

应用：web 缓存，web 压缩，web 加速，SSL 卸载，协议优化

其他功能

• 日志
• 命令行
• web 界面
• 监控

性能

F5 + 小机：SLA 5 个 9

LVS + PC Server：SLA 3 个 9

增加 nginx

1. 按照域名进行负载均衡
2. 切流量上线

增加 Haproxy

LVS-DR 无法跨网段

• RPS
• CPS

扩展性和可靠性

HA

主备

主主

集群

ospf , ecmp

F5 产品介绍

开源系统

IPVS

Nginx

HAproxy

Dpdk

OVS

腾讯的TGW

商业

• BVS
• 阿里的LVS集群
• 美团
• UCloud
• Google
• MicroSoft

智能 DNS

AWS Router53

腾讯 dnspod

BGP 多选路

BGP直接允许相同的IP在不同的运营商网络里广播，根据BGP协议自己实现就近接入。

基于 SDN 的 L4 负载均衡实现方案

考虑的因素

• tcp 乱序
• 各个 server 流量不均衡或者连接数不均衡, 如 “大象流”
• 增加和删除 server 的影响, 如何平滑上线和下线
• 进程异常退出
• server 异常
• 客户端访问不均匀

集群方案

ospf + ecmp : 交换机最好支持一致性哈希

bgp + gre : 云环境

策略路由

集群增加了复杂度

1. lb 设备的上线和下线
2. lb 异常宕机
3. lb 之间是否需要 session 的同步

不同处理连接方式的设计思路

基于 ip 的负载均衡

1. 根据 client 的 client_ip + pool_ip + pool_port 进行负载均衡
2. 下发流表时， 不要求流表过期上报控制器，只有控制器发现客户端分配的 server 不可用时才分配新的 server
3. 如果是 TCP 协议支持连接数限制, 非 TCP 不支持连接数限制

此外, 如果连接数限制开启（配置最小连接数算法），那么控制器还要求出现 FIN 报文上报控制器，

链路保持

不管是 TCP 还是 UDP，新的连接仍然用分配之前的服务器，缓存被过期流表上报的消息更新

控制器下发流表时要求流表过期时上报控制器，并且流表过期时间为链路保持时间

缓存更新依赖于流表删除上报控制器的消息, 具体为流表过期之后发送 FLOW_REMOVE 消息，控制器删除对应缓存

这里链路保持与 IP 负载均衡不同之处在于这里是连接级别的，而前者是 IP 级别的.

此外, 如果连接数限制开启（配置最小连接数算法），那么控制器还要求出现 FIN 报文上报控制器

链路不保持

对包含 SYN 的报文分配新的服务器，已存在连接分配之前分配的服务器（除非服务不可用）

控制器下发流表要求出现 FIN 报文上报控制器，并且要求流表过期不上报控制器(否则，后面删除流表再次上报控制器，增加开销），

如果控制器有对应的缓存，就删除流表，删缓存，并且包通过 PACKET_OUT 转发给后端服务器

缓存更新依赖连接断开的结束报文.

此外: 已有服务器突然不可用需要删除流表, 交换机端口宕掉需要删除对应的流表。

bounded-load

解决问题: 当使用一致性哈希算法， 客户端请求不均匀时，部分 server 成为热点

request : 总请求数

threshold : 阈值

number : 集群中机器的数量

weight[i] : 第 i 台机器的权重

每个 server 分配的应该分配的请求数 expect[i] = request / sum(weight[i]) * weight[i]

每个 server 实际分配的请求数 real[i]

当 real[i] < expect[i] * threshold 时, 就将请求分配给这个 server; 否则，就寻找下一个 server, 检查它是否满足条件。

每次有新的连接建立，或断开连接，就进行一个重新计算。

https://github.com/haproxy/haproxy/blob/25f067ccec52f53b0248a05caceb7841a3cb99df/src/lb_chash.c

https://arxiv.org/abs/1608.01350

总结

以上三种方法都需要配置缓存过期时间, 依赖过期时间清理异常连接导致的缓存没有更新的问题。

连接数限制

开启该功能，需要控制器下发流表，对于 FIN 标志的报文上报控制器。

只对 TCP, HTTP 有用，对于 UDP 不行

问题：如何解决没有通过 FIN 结束的包报文，比如 RESET 结束的报文，以及自始至终没有发送 FIN 的连接d的情况(比如服务器异常宕机，网络异常断开）。

解决办法: 增加超时时间，超时回收该连接。

DNAT

该模式下，必须禁止客户端直接访问后端服务器，而且部署方式也必须是穿透模式

FULLNAT

部署模式可以是穿透或旁路模式

客户端可以直接访问后端

SNAT

SNAT 只能工作与穿透部署模式，无法工作于旁路部署模式

连接数限制只能用于 TCP 和 HTTP, 无法用于 UDP

最小连接数算法和最大连接数配置都需要 FIN, SYN 包文的支持

连接数限制，只有配置 pool 的连接数限制，对该 pool 的连接数限制才能起作用

参考

https://cloud.baidu.com/doc/BLB/index.html