提纲
- ADC 行业现状
- ADC 原理
- ADC 的实现方式
为什么是 ADC 而不是负载均衡？
功能的扩展
解决了什么问题
- 可用性（Availability）
- 伸缩性（Scalability）
- 性能（End-user performance）
- 数据中心资源利用率（Data center resource utilization）
- 安全（Security）
行业现状
Gartner 魔力四象限
行业趋势
从硬件到软件，从裸机到云
从单纯的负载均衡到与网络，应用和安全 WAF 一起组合。
API 网关：Istio，Kong
基本原理
实现方式：
- 芯片
- x86 服务器：ipvs，ovs，dpdk
设计的技术栈：硬件(网卡指标)，驱动（网卡驱动），内核（网络协议栈），网络编程，基本数据中心网络，应用（http 各种优化）。
分层：
- 跨数据中心的负载均衡
- 数据中心内的负载均衡
- 服务级别的负载均衡
GLB
LSLB：Local Server Load Balance
GSLB：Global Service Load Balance
DNS：负载均衡
L4：基于 IP 和基于连接
L7：基于 URL
物理机，虚拟机，容器
部署模式
- arp
- 路由
旁路模式（FULLNAT）
单臂模式（SNAT）
全代理模式
本地三角模式
- 通过修改目的 mac
- 绑定 loopback 网卡：运维复杂
- 性能好， LB 只处理入流量
- 关闭 arp
SNAT
DNAT
- 只修改目标 ip
- 服务器网关变为 LB 网关
- 客户端直接访问服务器，由于会转发给 LB，导致丢包
穿透模式（SNAT，FULLNAT）
DNAT
FULLNAT
IP Tunning
运行模式
- 全代理模式
- 转发模式
基本功能
负载均衡算法
静态负载均衡算法
轮询
比率
优先级
动态负载均衡算法
最少连接数
最快响应时间
自定义负载均衡算法
运用机器学习，与监控，流量，负载联动的动态负载均衡
其他：
- 加权
- 加权轮询
- 哈希
- 一致性哈希
- 预测模式：机器学习
- 源地址保持
会话保持
- 简单会话保持：源地址会话保持
- Cookie 插入模式：在负载均衡器返回的时候插入
- Cookie 重写模式：服务器为空 cookie，负载均衡器对 cookie 进行重写
- Passive Cookie 模式：服务器包含 cookie，负载均衡器不做任何处理
- SSL Session ID 模式：在交换证书的时候记录 SSL session ID
- HTTP Header的会话保持：
健康检查
方式：推，拉（自定义，SDK）；
检查指标：网络层（ICMP，TCP，UDP），应用层（HTTP，FTP，DNS，SMTP，POP3），及自定义关联健康检查。
流量监控
- 物理层流量
- 应用流量
安全
- 防 DDos 攻击：Syn Cookie
- 访问控制(ACL)：基于协议，端口，设置服务的白名单（黑名单）
应用：web 缓存，web 压缩，web 加速，SSL 卸载，协议优化
其他功能
- 日志
- 命令行
- web 界面
- 监控
性能
F5 + 小机：SLA 5 个 9
LVS + PC Server：SLA 3 个 9
增加 nginx
- 按照域名进行负载均衡
- 切流量上线
增加 Haproxy
LVS-DR 无法跨网段
- RPS
- CPS
扩展性和可靠性
HA
主备
主主
集群
ospf , ecmp
F5 产品介绍
开源系统
IPVS
Nginx
HAproxy
Dpdk
OVS
腾讯的TGW
商业
- BVS
- 阿里的LVS集群
- 美团
- UCloud
- MicroSoft
智能 DNS
AWS Router53
腾讯 dnspod
BGP 多选路
BGP直接允许相同的IP在不同的运营商网络里广播，根据BGP协议自己实现就近接入。
基于 SDN 的 L4 负载均衡实现方案
考虑的因素
- tcp 乱序
- 各个 server 流量不均衡或者连接数不均衡, 如 “大象流”
- 增加和删除 server 的影响, 如何平滑上线和下线
- 进程异常退出
- server 异常
- 客户端访问不均匀
集群方案
ospf + ecmp : 交换机最好支持一致性哈希
bgp + gre : 云环境
策略路由
集群增加了复杂度
- lb 设备的上线和下线
- lb 异常宕机
- lb 之间是否需要 session 的同步
不同处理连接方式的设计思路
基于 ip 的负载均衡
- 根据 client 的 client_ip + pool_ip + pool_port 进行负载均衡
- 下发流表时， 不要求流表过期上报控制器，只有控制器发现客户端分配的 server 不可用时才分配新的 server
- 如果是 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 的连接数限制才能起作用
参考