前言
介绍常用的负载均衡手段
初步方案与问题
haproxy + keepalived 实现负载均衡和高可用
问题：
haproxy 节点容易成为瓶颈
所以我们需要更有效的方案
Load Balance 介绍
在网络服务中，一端是客户程序，另一端是服务程序
通过 LB 将 client 请求分发到存储入口 swift proxy 上
基本方法
可以在不同的层次上实现多台服务器的负载均衡。用集群解决网络服务性能问题的现有方法主要分为以下四类：
- 基于RR-DNS的解决方法
- 基于客户端的解决方法
- 基于应用层负载均衡调度的解决方法
- 基于 IP 层负载均衡调度的解决方法
基于RR-DNS的解决方法
通过RR-DNS（Round-Robin Domain Name System）实现分流
RR-DNS总结
优点
- 部署简单
缺点
- 不能保证后端服务器的负载是均衡的
- 用户机器会缓冲从名字到IP地址的映射，同一用户的所有请求都会被发送到同一台机器上
- 系统的可靠性和可维护性差，一旦某个服务器出现故障，即使及时修改了 DNS 设置，还是要等待足够的时间（刷新时间）才能发挥作用，在此期间，保存了故障服务器地址的客户计算机将不能正常访问服务器
基于客户端的解决方法
每个客户程序都有一定的服务器集群的知识，进而把以负载均衡的方式将请求发到不同的服务器
基于客户端方法总结
缺点
- 需要另外维护一套 nameserver 之类的服务
- 需要客户端配合
- nameserver 的性能直接影响服务请求性能
基于应用层的解决方法
在前端有一个基于应用层的负载调度器。当用户访问请求到达调度器时，请求会提交给作负载均衡调度的应用程序，分析请求，根据各个服务器的负载情况，选出一台服务器，重写请求并向选出的服务器访问，取得结果后，再返回给用户
现网中用的就是这个方案
应用层方案总结
缺点
- 系统处理开销特别大，致使系统的伸缩性有限。当请求到达负载均衡调度器至处理结束时，调度器需要进行四次从核心到用户空间或从用户空间到核心空间的上下文切换和内存复制；需要进行二次TCP连接，一次是从用户到调度器，另一次是从调度器到真实服务器；需要对请求进行分析和重写。这些处理都需要不小的ＣＰＵ、内存和网络等资源开销，且处理时间长。所构成系统的性能不能接近线性增加的，一般服务器组增至3或4台时，调度器本身可能会成为新的瓶颈。所以，这种基于应用层负载均衡调度的方法的伸缩性极其有限。
- 本身会成为整个系统的瓶颈
基于IP层的解决方法
通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器
开源实例：LVS（Linux Virtual Server）
LVS具体实现方式有
- NAT实现（VS/NAT）
- IP隧道实现（VS/TUN）
- 直接路由实现（VS/DR）
LVS 简介
介绍 LVS 的几种模式
LVS之NAT实现（VS/NAT）
通过NAT（Network Address Translation，网络地址转换） ，调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程
VS/NAT总结
优点
- 是服务器可以运行任何支持TCP/IP的操作系统，它只需要一个IP地址配置在调度器上，服务器组可以用私有的IP地址
缺点
- 伸缩能力有限， 当服务器结点数到一定规模时，调度器本身有可能成为系统的新瓶颈，因为在 VS/NAT 中请求和响应报文都需要通过负载调度器
LVS之IP隧道实现（VS/TUN）
IP隧道（IP tunneling）是将一个IP报文封装在另一个IP报文的技术，这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址
VS/TUN总结
优点
- 本身不会成为系统的瓶颈，可以用来构建高性能的超级服务器
缺点
- 所有的服务器必须支持“IP Tunneling”或者“IP Encapsulation”协议
- IP Tunneling 需要额外的开销，性能上不如 VS/DR
LVS之直接路由实现（VS/DR）
与VS/TUN中的类似，但它的报文转发方法有所不同， VS/DR通过改写请求报文的MAC地址，将请求发送到后端服务器，而后端服务器将响应直接返回给客户，要求调度器和后端服务器在同一物理网段内
VS/DR总结
- 跟VS/TUN相比，这种方法没有IP隧道的开销，但是要求负载调度器与实际服务器都有一块网卡连在同一物理网段上，服务器网络设备（或者设备别名）不作ARP响应，或者能将报文重定向（Redirect）到本地的Socket端口上