【分布式技术专题】「LVS负载均衡」全面透析Web基础架构负载均衡LVS机制的原理分析指南

前提概要

在大规模互联网应用中，负载均衡设备是必不可少的组成部分，源于互联网应用的高并
发和大流量的冲击压力场景下，通常会在服务端部署多个无状态的应用服务器和若干有状态的存储服务器（数据库、缓存等等）实现高可用特点和机制。

LVS的介绍说明

1. 官方站点：​​http://www.linuxvirtualserver.org​​；
2. 用过LVS的童鞋，其实大家的目的性很明确，就是需要通过LVS提供的负载均衡技术和Linux操作系统实现一个高性能，高可用的服务器群集；
3. 并且这个集群具有良好的可靠性、可扩展性和可操作性，从而以低廉的成本实现最优的服务性能，这也是大多数中小型公司青睐的架构；

LVS的体系架构

请求传播路径

负载均衡层（Load Balancer）

1. 处于集群最前端，一台或多台构成负载调度，俗称负载调度器（Director Server）；
2. 分发请求给服务器集群组层的应用服务器（Real Server）；
3. 监控应用服务器健康状况，动态从LVS路由表中剔除、添加；
4. 也可以兼职Real Server的身份；

负载均衡的作用

• 负载均衡设备的任务就是作为应用服务器流量的入口，挑选最合适的一台服务器，将客户端的请求转发给它处理，实现客户端到真实服务端的透明转发。
• 云计算以及分布式架构，本质上也是将后端服务器作为计算资源、存储资源，由某台管理服务器封装成一个服务对外提供，客户端不需要关心真正提供服务的是哪台机器，在它看来，就好像它面对的是一台拥有近乎无限能力的服务器，而本质上，真正提供服务的，是后端的集群支撑的计算能力。

典型的互联网应用的拓扑结构

负载均衡的类型

• 负载均衡可以采用硬件设备，也可以采用软件负载。商用硬件负载设备成本通常较高（一台几十万上百万很正常）一般有F5和A10硬件负载均衡；
• 所以在条件允许的情冴下我们会采用软负载，软负载解决的两个核心问题是：选谁、转发，其中最著名的是 LVS（Linux Virtual Server）、Nginx、HAproxy等。

软负载均衡（LVS）

LVS 是四层负载均衡，是我们国家著名技术专家：章文嵩博士研发的，也就是说建立在 OSI 模型的第四层——传输层之上，传输层上有我们熟悉的TCP/UDP，LVS支持TCP/UDP的负载均衡。

LVS的转发主要通过修改IP地址（NAT模式，分为源地址修改SNAT和目标地址修改DNAT）、修改目标MAC（DR 模式）来实现。

LVS是在第四层做负载均衡

• 首先，LVS不像HAProxy等七层软负载面向的是HTTP包，所以七层负载可以做的URL解析等工作，LVS无法完成。。
• 其次，用户访问是与服务端建立连接后交换数据包实现的，如果在第三层网络层做负载均衡，那么将失去「连接」的语义。
• 软负载面向的对象应该是一个已经建立连接的用户，而不是一个孤零零的 IP 包。后面会看到，实际上 LVS 的机器代替真实的服务器的用户通过TCP三次握手建立了连接，所以 LVS 是需要关心「连接」级别的状态的。

服务器群组层（Server Arrary）

1. 一台或多台实际运行的应用服务器构成；
2. 每个Real Server关联时通过有效网络互连；

共享存储层（Shared Storage）

提供共享存储空间和内容一致性的存储区域；例如：数据库、OSS存储、FS文件服务器等。

LVS相关术语

• DS：Director Server。指的是前端负载均衡器节点。
• RS：Real Server。后端真实的工作服务器。
• VIP：向外部直接面向用户请求，作为用户请求的目标的IP地址。
• DIP：Director Server IP，主要用于和内部主机通讯的IP地址。
• RIP：Real Server IP，后端服务器的IP地址。
• CIP：Client IP，访问客户端的IP地址。

LVS 的工作模式主要有 4 种：

• DR
• NAT
• TUNNEL
• Full-NAT
• TUN

返里挑选常用的 DR、NAT、Full-NAT、TUN 来简单介绍一下。

DR（Dynamic Route 动态路由）

通过为请求报文重新封装一个MAC首部进行转发，源MAC是DIP所在的接口的MAC，目标MAC是某挑选出的RS的RIP所在接口的MAC地址；源IP/PORT，以及目标IP/PORT均保持不变；

请求由LVS接受，由真实提供服务的服务器（RealServer, RS）直接返回给用户，返回的时
候不经过 LVS。

流程分析

DR 模式下需要LVS和绑定同一个 VIP（RS 通过将 VIP绑定在 loopback 实现），此时报文的源IP为CIP，目标IP为VIP；

1. 当用户请求到达DS后，LVS只需要将网络帧的MAC地址修改为某一台RS的 MAC，该包就会被转发到相应的RS处理，注意此时的源IP和目标IP都没变，LVS 只是做了一下移花接木。

IPVS比对数据包请求的服务是否为集群服务，若是，将请求报文中的源MAC地址修改为DIP的MAC地址，将目标MAC地址修改RIP的MAC地址， 此时的源IP和目的IP均未修改，仅修改了源MAC地址为DIP的MAC地址，目标MAC地址为RIP的MAC地址；

2. 由于DS和RS在同一个网络中，所以是通过二层来传输。目标MAC地址为RIP的MAC地址，那么此时数据包将会发至RS。
3. RS 收到 LVS 转发来的包，链路层发现 MAC 是自己的，到上面的网络层，发现 IP 也是自己的，于是返个包被合法地接受，RS 感知不到前面有 LVS 的存在。处理完成之后，将响应报文通过lo接口传送给eth0网卡然后向外发出，此时的源IP地址为VIP，目标IP为CIP；

4. 响应报文最终送达至客户端，而当 RS 返回响应时，只要直接向源 IP（即用户的 IP）返回即可，不再经过 LVS。DR 模式是性能最好的一种模式

这种模式下，有几个要点：

主要是这种模式在于，通过LVS只是在请求阶段做转发，而且修改的也不是IP地址，而是MAC地址，针对于修改后的MAC地址会自动转发到对应网段内MAC主机的服务器上面，之后因为IP都没有改变，之后实际RS可以直接发送给目标client服务器，这种性能最好，但是对网络层面要求比较高，对网络扩展角度而言控制力度略低。

NAT（Network Address Translation 网络地址准换）

• NAT是一种外网和内网地址映射的技术。
• NAT模式下，网络报的进出都要经过LVS的处理。

原理

多目标IP的DNAT，通过将请求报文中的目标地址和目标端口修改为选出来的RS的RIP和PORT实现转发。

流程分析

1. LVS需要作为RS的网关，当包到达LVS 时，LVS 做目标地址转换（DNAT）。此时报文的源IP为CIP，目标IP为VIP；

2. IPVS比对数据包请求的服务是否为集群服务，若是，修改数据包的目标IP地址为后端服务器IP， 此时报文的源IP为CIP，目标IP为RIP；RS接收到包以后，仿佛是客户端直接发给它的一样。

3. RS比对发现目标为自己的IP，将请求处理完，返回响应时，此时报文的源IP为RIP，目标IP为CIP；

4. 返回时RS的包通过网关（LVS）中转，LVS 会做源地址转换（SNAT），将包的源地址改为VIP，这样，这个包对客户端看起来就仿佛是LVS直接返回给它的。此时会将源IP地址修改为自己的VIP地址，然后响应给客户端，此时报文的源IP为VIP，目标IP为CIP；

客户端无法感知到后端RS 的存在

要点

客户端是不知道真是RS地址的，但是RS服务器却是可以知道ClientIP的（因为数据包中会包含了ClientIP），但是由于中介LVS的原因，使得发送的时候发给VIP（LVS），返回的时候，由LVS把源地址修改为VIP，所以对于客户端不能来讲是不知道目标地址的RS的存在。这就是反向代理的概念，客户端是不知道真正服务器的存在，知道的只有门面VIP的存在。

特性

1. 要求DS具备双网卡，VIP应对公网，而DIP必须和RIP在同一个网段内；
2. RIP、DIP应该使用私网地址，同在一个网段中，且RS的网关要指向DIP；
3. 请求和响应报文都要经由DS转发，极高负载中，DS可能会成为系统瓶颈；
4. RS可以使用任意OS；

TUN

在原有的IP报文外再次封装多一层IP首部，内部IP首部(源地址为CIP，目标IIP为VIP)，外层IP首部(源地址为DIP，目标IP为RIP)。

流程分析

1. 当用户请求到达DS后，此时请求的数据报文会先到内核空间的PREROUTING链，此时报文的源IP为CIP，目标IP为VIP；

2. PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链；
3. IPVS比对数据包请求的服务是否为集群服务，若是，在请求报文的首部再次封装一层IP报文，封装源IP为为DIP，目标IP为RIP。然后发至POSTROUTING链。 此时源IP为DIP，目标IP为RIP；

4. POSTROUTING链根据最新封装的IP报文，将数据包发至RS（因为在外层封装多了一层IP首部，所以可以理解为此时通过隧道传输），此时源IP为DIP，目标IP为RIP；
5. RS接收到报文后发现是自己的IP地址，就将报文接收下来，拆除掉最外层的IP后，会发现里面还有一层IP首部，而且目标是自己的tun0接口VIP，那么此时RS开始处理此请求，处理完成之后，通过tun0接口送出去向外传递，此时的源IP地址为VIP，目标IP为CIP；

6. 响应报文最终送达至客户端；

4.3 特性

1、DIP、VIP、RIP都应该是公网地址；
2、RS的网关不能，也不可能指向DIP；
3、RS必须支持IP隧道；

Full-NAT

无论是 DR 还是 NAT 模式，不可避免的都有一个问题：LVS 和 RS 必须在同一个 VLAN 下，
否则 LVS 无法作为 RS 的网关。

这引发的两个问题是：

1. 同一个VLAN的限制导致运维不方便，跨VLAN的RS无法接入。
2. LVS的水平扩展受到制约。当RS水平扩容时，总有一天其上的单点LVS会成为瓶颈。

Full-NAT 由此而生，解决的是 LVS 和 RS 跨 VLAN 的问题，而跨 VLAN 问题解决后，LVS
和 RS 不再存在 VLAN 上的从属关系，可以做到多个 LVS 对应多个 RS，解决水平扩容的问
题。

Full-NAT 相比 NAT 的主要改迕是，在 SNAT/DNAT 的基础上，加上另一种转换，转换过
程如下：

• 在包从 LVS 转到 RS 的过程中，源地址从客户端 IP 被替换成了 LVS 的内网 IP。
• 内网IP之间可以通过多个交换机跨VLAN通信。
• 当RS处理完接受到的包，返回时，会将返个包返回给LVS的内网IP，返一步也不受限于VLAN。
• LVS 收到包后，在 NAT 模式修改源地址的基础上，再把RS发来的包中的目标地址从LVS内网 IP 改为客户端的 IP。

Full-NAT主要的思想是把网关和其下机器的通信，改为了普通的网络通信，从而解决了跨
VLAN 的问题。采用返种方式，LVS 和 RS 的部署在 VLAN 上将不再有任何限制，大大提高了运维部署的便利性。

上面其实是把内网ip和内网ip之间通过交换机进行转换捆绑，从而可以跨vlan进行服务请求代理。

Session

客户端与服务端的通信，一次请求可能包含多个TCP 包，LVS 必须保证同一连接的TCP包，必须被转发到同一台RS，否则就乱套了。为了确保返一点，LVS 内部维护着一个 Session的 Hash 表，通过客户端的某些信息可以找到应该转发到哪一台 RS 上。

LVS 集群化

采用 Full-NAT 模式后，可以搭建 LVS 的集群，拓扑结构如下图：

容灾

容灾分为 RS 的容灾和 LVS 的容灾。

RS 的容灾可以通过 LVS 定期健康检测实现，如果某台 RS 失去心跳，则认为其已经下线，
不会在转发到该 RS 上。

LVS 的容灾可以通过主备+心跳的方式实现。主 LVS 失去心跳后，备 LVS 可以作为热备立
即替换。

容灾主要是靠 KeepAlived 来做的。(心跳以及下线剔除或者替换工作主要通过keepalived进行控制)