LB(Load Balancer)

Posted on

LB

Load Balancer 的功能是在服务集群和客户端之间做负载均衡处理，将客户端请求按一定策略分发给集群中不同服务实例处理，以降低单个服务实例的压力。 下面记录常见的 LB 方案。

LB 方案

DNS(Domain Name System，可靠性较差)

一个域名绑定多个 IP 后，如果有客户端通过域名请求 IP 地址，域名服务器会轮询方式返回 IP 地址。

  • 优点：
    • 可以在客户端的最初入口处就进行 LB
    • DNS 在客户端有本地缓存，没有性能瓶颈
  • 缺点：
    • 如果 IP 对应的服务发生问题，客户端会持续错误
    • 即使立刻更改 IP，也会由于 DNS 的较大延迟更新，导致长时间不可用
    • 如果把多个服务 IP 暴露给 DNS，会引起外网 IP 占用量过大的问题

Nginx(性能较高、广泛采用)

Nginx 主机作为反向代理，在客户端请求时建立连接、然后与服务实例建立连接，将客户端请求转发给服务端、将服务端返回结果转发给客户端。 由于 Nginx 利用了 epoll 技术，在大量连接下性能非常好，单机百万并发连接。

  • 解决单点问题：

    • 利用 Linux 的 VIP(Virtual IP) 功能，向外暴露公网 IP
    • 假设有两个 Nginx 实例 A B，它们向外暴露的 VIP 分别是 IPa IPb，这两个 IP 都注册到 DNS 了，这样可以进行负载均衡
    • Nginx 装有 keepalived 组件，可以相互检查对方的状态(ping)，如果检测不到对方，则将对方的 VIP 指向自己，这样做到 HA(High Available)
  • 优点：
    • 性能好
    • 设计较好，只需要简单配置即可实现功能
    • 插件式设计，很容易开发自定义插件
  • 缺点：
    • 由于要建立连接，所以性能存在瓶颈，连接数更大之后就不容易支持了，需要想其他办法

LVS(Linux Virtual Server，性能极高)

LVS 是由章文嵩博士主导的开源负载均衡项目，目前已经整合入 Linux 内核。如其名，LVS 也是一种 LB，是用一台 Linux 作为 Load Balance Server。 LVS 实现了网络层的基于 IP 的数据请求负载均衡调度方案，整个过程没有建立连接，所以性能极高，达到百万以上连接才值得使用。

  • LVS 涉及的名词：
    • VIP(Virtual IP): 服务系统整体向外网提供的虚拟 IP，由 LB 向外暴露。
    • RIP(Real Server IP): 后端 Real Server 的 IP
    • LD(Load Balancer Director): 同 LB，负载均衡调度器
    • Real Server: 在 LB 之后的提供真实服务的 Server 实例
    • DIP(Director IP): 在 NAT 模式中是后端 real server 的 gateway; 在 DR 和 Tune 中如果使用 heartbeat 或者 keepalived，用来探测使用 LVS 有三种模式：

NAT(Network Address Translation, 网络地址转换)

NAT 通过修改 IP 数据报报头中的 IP 地址和端口号实现负载均衡

  • 步骤：

    1. 客户端请求 DNS 拿到系统的 VIP(Virtual IP)，也就是 LVS 的 IP，然后向 VIP 发出请求
    2. VIP 中记录着有哪些 RealServer 并通过心跳维护着它们的状态(IP、端口、是否可用)
    3. 有客户端请求的 IP 数据包来到 LVS 后，LVS 篡改目标 IP 和端口号，然后根据负载均衡策略转发给某个 RealServer
    4. RealServer 处理完后把 response 发给 LVS，LVS 篡改源 IP 和端口号，转给客户端

  • 细节：

    • LVS 有一个连接 Hash 表，用于保存一个连接和目标 RealServer 的映射关系，保证一个连接的报文都打在一个 RealServer 上
    • 这种模式下，LVS 要有两块网卡，一块向外网提供一个 VIP，一块用于内网 RealServer 通信

TUN(IP tunning，IP 隧道)

TUN 在 LVS（NAT）模式的集群环境中，由于请求的收、发都要经过 LVS，当 RealServer 数量较多时 LVS 就会成为瓶颈。对于一个网络请求， 往往 Request 中的数据较少而 Response 中的数据较多，可以用 IP 隧道的方式，让 RealServer 直接返回给客户端，就能极大的减少 LVS 的瓶颈。 相比 NAT 模式的区别是，在 RealServer 返回 Response 时，篡改 IP 数据报报头的源 IP 和端口号，改为 LVS 的，这样客户端就好像直接在和 LVS 通信。

  • 细节：
    • TUN 模式要求除了 LVS 需要一个公网 IP 外，Real Server 也要与外网相连，这样可以直接给客户端发 Response

DR(Direct, 直连)

DR 在 LVS（TUN）模式下，为了在 LVS 和 RealServer 间创建 IP 隧道，需要对 IP 数据报进行篡改，这同样会增加服务器的负担。所以又有了 DR 直连模式。 DR 模式下，LB 设备在以太帧中篡改 MAC 地址，转发给根据负载均衡策略选定的 RealServer。DR 模式要求 LVS 和 RealServer 都在同一局域网内，共享 VIP， 这样 RealServer 返回 Response 时就可以直接以 VIP 为源地址。

  • 细节：
    • RealServer 和 LVS 都在一个局域网下，共享 VIP，那么有请求来了谁响应这个请求呢？如何避免 RealServer 先响应请求？这就需要对ARP协议处理， 只有 LVS 收到 ARP 请求时回复 LVS 的 MAC 地址，这样就只对外暴露一个 MAC 地址了。RealServer 需要配置在 Non-ARP 网络设备上。
    • 在 LVS 转发时，由于 MAC 地址在以太帧报中，不用再解开以太帧改写 IP 数据报，所以改写效率非常高，完全没有瓶颈

负载均衡调度算法

  • 轮询调度(Round Robin，简称 RR) 依次循环的方式将请求调度到不同 RealServer 上

  • 加权轮询调度(Weight Round Robin，简称 WRR) 在 RR 的基础上，根据 RealServer 的性能设定一个权值，性能越高权值越大，在 RR 过程中该 RealServer 处理的请求越多。

  • 最小连接调度(Least Connections，简称 LC) 记录各个 RealServer 的连接数，当一个请求被调度到 RealServer 时+1；当连接中断或超时时-1。 LVS 把新的连接请求分配到当前连接数最小的 RealServer。 (由于真实的服务器集群具有相近的性能，采用最小连接调度算法可以比较好的均衡负载。)

  • 加权最小连接调度(Weight Least Connections，简称 WLC) 类似 WRR，系统管理员可以设置 RealServer 的权值，权值高的连接数可以更多。 调度器可以自动问询 RealServer 的负载情况，并动态地调整其权值。

  • 基于局部的最少连接(Locality-Based Least Connections，LBLC)

  • 带复制的基于局部性的最少连接（Locality-Based Least Connections with Replication，LBLCR）

  • 目标地址散列调度（Destination Hashing，DH） 根据目标 IP 地址计算 Hash Key，从静态散列表找到 RealServer，若该服务器是可用的且并未超载，则发送，否则返回空。

  • 源地址散列调度（Source Hashing，SH） 类似 DH，用源 IP 地址进行散列。

  • 最短的期望的延迟调度（Shortest Expected Delay，SED） 基于 WLC 算法。根据当前连接数和服务器权重计算期望延延迟，把新请求分配给”当前相对负担最小”的服务器。 例如有两台权重、已连接数分别为：A 权重 10 已连接 3，B 权重 3 已连接 1； 计算 Expected Delay 分别为：SED_A = (1+3) / 10 = 0.4，SED_B = (1+1) / 3 = 0.67，所以选负担更小的 A

  • 最少队列调度（Never Queue，NQ） 如果有 RealServer 的连接数等于 0 就直接分配过去，无需 SED 计算。

其他