LVS那些事(上)

  • 2017-08-28
  • 26
  • 0

1998年,章文嵩博士成立了Linux Virtual Server的自由软件项目,进行Linux服务器集群的开发工作。

他的目标是:使用集群技术和Linux操作系统实现一个高性能、高可用的服务器,它具有很好的可伸缩性(Scalability)、可靠性(Reliability)和可管理性(Manageability)。

LVS到现在已经使用的非常广泛了,绝大部分国内的互联网企业用它来做四层的负载均衡组件。

我们分2-3篇博客来介绍LVS,包括从原理到实际的部署等方面。


LVS 做了什么工作?

当客户端向服务端发送请求,请求首先到LVS的服务器上。

  1. LVS选择一个服务器作为响应本次请求的真实服务器(Real Server)
  2. 将请求转发到 Real Server
  3. 将 Real Server 的回应转回客户端(某些模式下没有这一步)

归结起来,LVS做了两件很重要的事情:

  1. 挑选服务器
  2. 转发请求

下面就对这两个过程进行描述。在那之前,为了能更清楚的叙述,需要先认识一些名词:

  • Director 运行LVS的服务器,也叫 Virtual Server

LVS并不能直接提供服务,需要后端服务器提供真正的服务

  • RIP 实际提供服务的IP
  • RS 实际提供服务的服务器(Real Server)

一台Director至少提供两个IP,一个用来对外提供服务(一般为公网),一个用来向后端服务器转发请求:

  • VIP Virtual Server 对外提供服务的虚拟IP(Virtual IP)
  • DIP Virtual Server 用于转发的IP(Director IP)

向服务器发出请求的称为Client

  • CIP 客户端IP(Client IP)

转发请求

LVS在转发请求的方式一共有三种,各有优劣

1 Network Address Translation(VS/NAT)

全称 Virtual Network via Network Address Translation

这种方法是通过NAT的方式来实现负载均衡。

如上图

  1. 当一个请求到达Director,其 源IP|目的IPCIP|VIP
  2. Director将包的目的IP改为RIP,包地址为:CIP|RIP
  3. RS处理请求后,将结果返回,包地址为:RIP|CIP
  4. 返回的包经过Director时,将其包地址改为:VIP|CIP

当包从RS返回时,其地址为RIP|CIP。如何保证包一定会经过Director呢?需要将所有的RS的Gateway设置为DIP。这需要DIP和RIP在同一个网段或Vlan中。

Full-NAT

这是VS/NAT方式的一个变种。原理是在转发到RS上时,将目标地址和原地址全部改写,回给客户端时再改回去。这样的话DIP和RIP可以不在一个网段上,可以实现跨机房,或者异地容灾。

缺点

这种方式的缺点是:request和response全部要经过Director,当RS的数量很多,或者请求量很大时,Director会变成性能瓶颈。

#2 Direct Routing(VS/DR)

全称:Virtual Server via Direct Routing

这是目前较为常用的一种模式,可以避免VS/NAT出现的Director性能问题。

  1. 请求到达Director,将目标MAC改为RS的MAC;
  2. RS处理请求后,将包直接会给Client;

过程很简单,但中间的问题很多:

  1. 更改MAC地址来达到转发的时候,Director 和 RS们必须在同一物理交换机下啊?

    是的,这也是这个模式的缺点,Director必须和RS在同一交换机下。

  2. RS在收到包之后,发现目的IP不是自己的IP,不会去处理,怎么办?

    为了解决这个问题,需要给RS上绑定VIP。

  3. Linux主机的IP和MAC映射关系会通告给整个交换机网络下,这样的话就会出现混乱了,RS和Director都有同样的IP,该发给谁?

    可以通过设置内核参数来决定将哪些网卡通报,哪些不通报。一般来说绑定在lo上是最省事的。

  4. Linux包从某个网卡出去,此网卡必须有某个IP才能以此IP为源地址出去,VIP现在绑定到lo上,如何能回包?

    为了解决这个问题,需要加主机路由,所有source为VIP的包全部从连通公网的网卡走。

#3 IP Tunneling(VS/TUN)

Director收到Client的请求包后,在外层再加上一个IP头为DIP|RIP后封装成IP隧道协议报文,然后发送给real server.

RS一定要可以识别IP隧道协议才可以,拆包后看到还有一个头是CIP|VIP,所以RS就打上VIP|CIP的IP头直接回给Client.


选择服务器

选择服务器本质上就是如何调度请求。LVS提供了下面的几个算法:

1 轮询(Round Robin)

算法将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载。

2 加权轮询(Weighted Round Robin)

根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。

3 最少链接(Least Connections)

算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能,采用"最小连接"调度算法可以较好地均衡负载。

4 加权最少链接(Weighted Least Connections)

在集群系统中的服务器性能差异较大的情况下,调度器采用加权最少链接调度算法优化负载均衡性能,具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。

5 基于局部性的最少链接(Locality-Based Least Connections)

针对目标IP地址的负载均衡,目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器 是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于一半的工作负载,则用"最少链接"的原则选出一个可用的服务 器,将请求发送到该服务器。

6 带复制的基于局部性最少链接(Locality-Based Least Connections with Replication)

针对目标IP地址的负载均衡,目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个 目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务 器组,按"最小连接"原则从服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器,若服务器超载;则按"最小连接"原则从这个集群中选出一 台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的 程度。

7 目标地址散列(Destination Hashing)

根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。

8 源地址散列(Source Hashing)

根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。


关于为什么要分篇来写

为什么要分开几篇写不是一篇写完呢?是因为我觉得,博客不是论文,不需要长篇大论一次把事情讲完。利用碎片时间就能读完才是好的。

不占用读者太长时间又能有收获才是我的追求。哈哈哈


转载请注明作者和出处(reposkeeper),请勿用于任何商业用途!

关注微信公众号,获取新文章的推送!
qrcode

感谢打赏!
微信

评论

还没有任何评论,你来说两句吧

reposkeeper