云厂商负载均衡漫谈

发表于 更新于 分类于 阅读次数： 本文字数： 2.9k 阅读时长 ≈ 3 分钟

负载均衡是所有云厂商里都必备的一个组件，要是一个云厂商要是连负载均衡都没有的话，那还是叫vps厂商吧，也别叫云了。

说负载均衡之前我们先熟悉一下基础网络知识：

首先我们要知道开放系统互联（OSI）模型由国际标准化组织和其他机构在 20 世纪 70 年代末制定。1984 年发布了第一版 ISO 7498 标准，当前版本为 ISO/IEC 7498-1:1994。

以下图片引用自https://blog.smartbuildingsacademy.com/what-is-the-osi-model

通过这个图我们大概可以知道我们平时说的那些协议都是运行在哪一层的？ 那么问题来，tcpdump这个工具是运行在哪一层的呢？

image-20240913193726464

这里我们可以网络整体分为7层，所有应用数据的网络传输都是遵循于这个模型：也就是应用数据从上往下发，从下往上收的。

image-20240913195558354

但是由于现在互联网大多是基于tcp/ip的，毕竟现在也没有玩红警了，这个我记得当年是IPX/SPX协议簇的。早些年网吧里的游戏大部分都是IPX/SPX协议的。所以tcp/ip的协议栈有一个对应osi七层的。

image-20240913200211578

但是我们实际在说的时候还是基于osi模型来说的，比如4层还是7层，7层就是应用层，你常见的dns, http, ntp这些都是。 4层就是tcp，udp层面，可以确定到协议和端口。

但是我们常见的ping,它默认走的是icmp协议，这个是运行在网络层的，所以它能通，不代表tcp和上层的协议会通。这个在排查问题的时候需要十分注意。

但是负载均衡在各家其实都有很多子产品。比如：

云厂商 负载均衡名字 支持协议 日志 监控
阿里云 clb（原先的slb） 支持4层，7层（tcp, udp, http, https, ws, wss）基本无日志和分钟级监控 无日志 1分钟监控
阿里云 alb 7层（http, https, quic）同时可以针对http协议内容进行判断 有日志 1分钟监控
阿里云 nlb 4层+ （tcp, udp, tcpssl） 有日志 1分钟监控
aws clb 支持4层，7层（tcp, udp, http, https, ws, wss） 有日志 5分钟监控
aws alb 7层（http, https, gPRC） 有日志 5分钟监控
aws nlb 4层+ （tcp, udp, tcpssl） 有日志 5分钟监控

这里就列出了主要的2家的，其他家的大家可以自己去查一下。基本上按照aws这种监控频率在大宋早就挂了，大家还是自己搞一下监控。

但你以为负载均衡就这点东西吗？ 这里还是比较负载的，只要当年搞过章博士的lvs，大家应该都能知道负载均衡的网络复杂点是在哪里的。从实际来看，阿里云的四层slb是使用的lvs+fullnat的模式在做的，但是由于厂商都有专门的硬件和芯片做这个事情，所以肯定比我们原先直接x86的cpu跑这个要快。

image-20240914103925492

首先我们得知道clb这一层是怎么从公网ip转为内网ip的，这在iptables就是 ( DNAT + SNAT )

SNAT(Source Network Address Translation)：源网络地址转换，内部地址要访问公网上的服务时，内部地址会主动发起连接，将内部地址转换为公网IP。这个在我们内部共享上网的时候就会用到这个，这样大家的出口地址都一样。

DNAT(Destination Network Address Translation)：目标地址转换，内部需要对外提供服务时，外部主动发起连接，路由器或者防火墙的网络接收到这个连接，然后将连接转换到内部。

我们可以看到在clb这一层，我们把公网ip都转成了内网ip。 这样导致的情况是real server获取到的用户ip就是clb的内网ip（100.64.0.2）。但是我们可以看到实际在云上，我们的real server都是能够获取到真实的用户ip（202.96.209.2）的，这是怎么做到的。

这个就仰赖一种叫TOA（TCP_option_address）https://datatracker.ietf.org/doc/html/rfc6994 的技术。 它工作原理其实就是在clb这里把client的ip写入到tcp的option内（一般code point为253或254,不同云厂商不一样），然后把数据包传到后端real server中， real server会去解option内的数据，然后把这个option内作为真正的client ip来进行处理记录等。而且这种策略是只在首次连接时候会使用TOA， 后面数据传输都不会加了。

当然，现在还有一种nginx proxy protocol的协议，它工作原理是直接修改tcp包，在所有tcp包最前面添加client ip的数据，当中可以跨过任意nat环境，只要末端设备去解这个tcp包最前面的数据就可以获得client ip的数据。当然使用nginx proxy protocol后，不光可以在里面写ip数据，还有端口等等信息，具体可以参看作者： https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

缺点就是一般云厂商不给你解析，它一般只管添加，但是不管解析。nginx可以解析，但是别的自己写的tcp服务就要自己去解析这个了。不过这个实现也不难。

好了，现在我们才正式要评估负载均衡的注意事项了：

  1. 最大并发保持连接数
  2. 最大并发新建连接数
    1. 以上这2个注意测试方法，一个是测试维持的时间，另外一个是梯度，比如每分钟增加5000请求什么的，无论哪家你直接一把打过去50万都是必然挂掉的。
  3. 是否跨az的
    1. 首先必须要选择跨az的，阿里云早期的clb就是不跨az的。
    2. 另外一个是一旦一个az的挂了，另外一个多久可以可以起来，一般心跳检测大概是5秒，不过还是实际确认一下好。有些厂商有坑。（这个不好测试，需要云厂商配合）
  4. 是否支持toa和nginx proxy protocol
  5. 健康检查策略
    1. 检查间隔
    2. 检查超时时间
    3. 摘除的检查次数
    4. 放入后端的检查次数
  6. 超时时间设置
    1. 连接超时时间
    2. 响应超时时间
    3. 保持超时时间
    4. 超时后是发送rst还是正常fin.
  7. IP白名单和黑名单
  8. TLS和https支持的版本
  9. 负载均衡策略
    1. rr
    2. 加权rr等
  10. 服务器组
    1. 单个负载均衡后端支持最大real server的个数
    2. 单个服务器组是否支持挂载到多个负载均衡后面
      1. 如果可以的话可以挂到多少个负载均衡后
  11. 7层协议的规则匹配
  12. 流量镜像
    1. 这个在做线上压测什么的会特别有用。
  13. 费用
    1. 是根据实际使用的费用，还是根据规格
    2. tls和https是否单独计费
    3. 费用的组成部分：
      1. 保持连接数
      2. 新建连接数
      3. tls请求
      4. 流量
        1. 公网
        2. 内网

好了，我们现在来揭晓一下tcpdump到底是在哪一层了，其实是工作在第二层。这种就导致了我们用tcpdump抓入的包是完整的数据，抓出去的包其实是上层处理过的，但是这个跟实际网络流程是一样的，只是这种情况下要排查上层应用的问题还得继续排查。特别是在云上要排查这种问题可能是难上加难，因为这当中经过的设备实在太多了。曾经跟阿里云一起同时抓了32个网络节点，后面问题好像还是没有解决，最后靠升级处理的。

good