LVS的3种工作模式和8种调度算法

LVS的三种工作模式:

  • VS/NAT模式(Network address translation)
  • VS/TUN模式(tunneling)
  • DR模式(Direct routing)

参考文章:http://www.linuxvirtualserver.org/zh/lvs3.html

** NAT模式-网络地址转换 ** * Virtualserver via Network address translation(VS/NAT)*

这个是通过网络地址转换的方法来实现调度的。首先调度器(LB)接收到客户的请求数据包时(请求的目的IP为VIP),根据调度算法决定将请求发送给哪个后端的真实服务器(RS)。然后调度就把客户端发送的请求数据包的目标IP地址及端口改成后端真实服务器的IP地址(RIP),这样真实服务器(RS)就能够接收到客户的请求数据包了。真实服务器响应完请求后,查看默认路由(NAT模式下我们需要把RS的默认路由设置为LB服务器。)把响应后的数据包发送给LB,LB再接收到响应包后,把包的源地址改成虚拟地址(VIP)然后发送回给客户端。

原理简述:

  1. 客户端请求数据,目标IP为VIP
  2. 请求数据到达LB服务器,LB根据调度算法将目的地址修改为RIP地址及对应端口(此RIP地址是根据调度算法得出的。)并在连接HASH表中记录下这个连接。
  3. 数据包从LB服务器到达RS服务器webserver,然后webserver进行响应。Webserver的网关必须是LB,然后将数据返回给LB服务器。
  4. 收到RS的返回后的数据,根据连接HASH表修改源地址VIP&目标地址CIP,及对应端口80.然后数据就从LB出发到达客户端。
  5. 客户端收到的就只能看到VIP\DIP信息。

NAT模式优缺点:

  1. NAT技术将请求的报文和响应的报文都需要通过LB进行地址改写,因此网站访问量比较大的时候LB负载均衡调度器有比较大的瓶颈,一般要求最多之能10-20台节点
  2. 只需要在LB上配置一个公网IP地址就可以了。
  3. 每台内部的节点服务器的网关地址必须是调度器LB的内网地址。
  4. NAT模式支持对IP地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。

TUN模式 virtual server via ip tunneling

采用NAT模式时,由于请求和响应的报文必须通过调度器地址重写,当客户请求越来越多时,调度器处理能力将成为瓶颈。为了解决这个问题,调度器把请求的报文通过IP隧道转发到真实的服务器。真实的服务器将响应处理后的数据直接返回给客户端。这样调度器就只处理请求入站报文,由于一般网络服务应答数据比请求报文大很多,采用VS/TUN模式后,集群系统的最大吞吐量可以提高10倍。
VS/TUN和NAT模式不同的是,它在LB和RS之间的传输不用改写IP地址。而是把客户请求包封装在一个IP tunnel里面,然后发送给RS节点服务器,节点服务器接收到之后解开IP tunnel后,进行响应处理。并且直接把包通过自己的外网地址发送给客户不用经过LB服务器。

原理简述:

  1. 客户请求数据包,目标地址VIP发送到LB上。
  2. LB接收到客户请求包,进行IP Tunnel封装。即在原有的包头加上IP Tunnel的包头。然后发送出去。
  3. RS节点服务器根据IP Tunnel包头信息(此时就有一种逻辑上的隐形隧道,只有LB和RS之间懂)收到请求包,然后解开IP Tunnel包头信息,得到客户的请求包并进行响应处理。
  4. 响应处理完毕之后,RS服务器使用自己的出公网的线路,将这个响应数据包发送给客户端。源IP地址还是VIP地址。(RS节点服务器需要在本地回环接口配置VIP)

DR模式(直接路由模式) Virtual server via direct routing (vs/dr)

DR模式是通过改写请求报文的目标MAC地址,将请求发给真实服务器的,而真实服务器响应后的处理结果直接返回给客户端用户。同TUN模式一样,DR模式可以极大的提高集群系统的伸缩性。而且DR模式没有IP隧道的开销,对集群中的真实服务器也没有必要必须支持IP隧道协议的要求。但是要求调度器LB与真实服务器RS都有一块网卡连接到同一物理网段上,必须在同一个局域网环境。
DR模式是互联网使用比较多的一种模式。

DR模式原理过程简述:
VS/DR模式的连接调度和管理与NAT和TUN中的一样,它的报文转发方法和前两种不同。DR模式将报文直接路由给目标真实服务器。在DR模式中,调度器根据各个真实服务器的负载情况,连接数多少等,动态地选择一台服务器,不修改目标IP地址和目标端口,也不封装IP报文,而是将请求报文的数据帧的目标MAC地址改为真实服务器的MAC地址。然后再将修改的数据帧在服务器组的局域网上发送。因为数据帧的MAC地址是真实服务器的MAC地址,并且又在同一个局域网。那么根据局域网的通讯原理,真实服务器是一定能够收到由LB发出的数据包。真实服务器接收到请求数据包的时候,解开IP包头查看到的目标IP是VIP。(此时只有自己的IP符合目标IP才会接收进来,所以我们需要在本地的回环接口上面配置VIP。另:由于网络接口都会进行ARP广播响应,但集群的其他机器都有这个VIP的lo接口,都响应就会冲突。所以我们需要把真实服务器的lo接口的ARP响应关闭掉。)然后真实服务器做成请求响应,之后根据自己的路由信息将这个响应数据包发送回给客户,并且源IP地址还是VIP。

DR模式小结:

  1. 通过在调度器LB上修改数据包的目的MAC地址实现转发。注意源地址仍然是CIP,目的地址仍然是VIP地址。
  2. 请求的报文经过调度器,而RS响应处理后的报文无需经过调度器LB,因此并发访问量大时使用效率很高(和NAT模式比)
  3. 因为DR模式是通过MAC地址改写机制实现转发,因此所有RS节点和调度器LB只能在一个局域网里面
  4. RS主机需要绑定VIP地址在LO接口上,并且需要配置ARP抑制。
  5. RS节点的默认网关不需要配置成LB,而是直接配置为上级路由的网关,能让RS直接出网就可以。
  6. 由于DR模式的调度器仅做MAC地址的改写,所以调度器LB就不能改写目标端口,那么RS服务器就得使用和VIP相同的端口提供服务。

LVS调度算法

参考文章:http://www.linuxvirtualserver.org/zh/lvs4.html
Lvs的调度算法决定了如何在集群节点之间分布工作负荷。当director调度器收到来自客户端访问VIP的上的集群服务的入站请求时,director调度器必须决定哪个集群节点应该处理请求。Director调度器用的调度方法基本分为两类:
固定调度算法:rr,wrr,dh,sh
动态调度算法:wlc,lc,lblc,lblcr

算法说明

RR(Round Robin Scheduling)

轮询算法,它将请求依次分配给不同的rs节点,也就是RS节点中均摊分配。这种算法简单,但只适合于RS节点处理性能差不多的情况

WRR(Weighted Round-Robin Scheduling)

加权轮询调度,它将依据不同RS的权值分配任务。权值较高的RS将优先获得任务,并且分配到的连接数将比权值低的RS更多。相同权值的RS得到相同数目的连接数。

WLC(Weighted Least-Connection Scheduling)

加权最小连接数调度,假设各台RS的全职依次为Wi,当前tcp连接数依次为Ti,依次去Ti/Wi为最小的RS作为下一个分配的RS

DH(Destination Hashing Scheduling)

目的地址哈希调度以目的地址为关键字查找一个静态hash表来获得需要的RS

SH(Source Hashing Scheduling)

源地址哈希调度以源地址为关键字查找一个静态hash表来获得需要的RS

LC(Least-Connection Scheduling)

最小连接数调度,IPVS表存储了所有活动的连接。LB会比较将连接请求发送到当前连接最少的RS.

LBLC(Locality-Based Least Connections Scheduling)

基于地址的最小连接数调度:将来自同一个目的地址的请求分配给同一台RS,此时这台服务器是尚未满负荷的。否则就将这个请求分配给连接数最小的RS,并以它作为下一次分配的首先考虑。

LBLCR(Locality-Based Least Connections with Replication Scheduling)

带复制的基于局部性最少链接调度算法也是针对目标IP地址的负载均衡。LBLCR算法先根据请求的目标IP地址找出该目标IP地址对应的服务器组;按“最小连接”原则从该服务器组中选出一台服务器,若服务器没有超载, 将请求发送到该服务器;若服务器超载;则按“最小连接”原则从整个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该 服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的程度。

LVS调度算法的生产环境选型:

  1. 一般的网络服务,如http,mail,mysql等常用的LVS调度算法为:
  • 基本轮询调度RR
  • 加权最小连接调度WLC
  • 加权轮询调度WRR
  1. 基于局部性的最小连接LBLC和带复制的给予局部性最小连接LBLCR主要适用于web cache和DB cache
  2. 源地址散列调度SH和目标地址散列调度DH可以结合使用在防火墙集群中,可以保证整个系统的出入口唯一。
    实际适用中这些算法的适用范围很多,工作中最好参考内核中的连接调度算法的实现原理,然后根据具体的业务需求合理的选型。

参考文章:http://atong.blog.51cto.com/2393905/1351362

LVS+keepalived实现负载均衡&高可用

部署成功后的另一些问题

  1. 当我们的RS节点出现问题,LB如何知道。如果不知道是会把会话连接接续转发到RS上面。
  2. 如果LB出现故障,那么整个网络就出现故障。

针对上面的1问题,我们就需要一种RS节点健康检查机制。定时的去检测RS是否正常,如果出现不正常那么就把这个RS从VIP服务里面删除掉。如果恢复正常了,就再把RS添加进来。针对2问题,我们可以另外再架设一台LB服务器,作为备LB服务器。那么当主LB出现故障,备LB服务器就会启动接管主LB服务器的工作,接管它的资源(IP地址,在网络中的角色身份等)

LVS/Nginx/HAProxy负载均衡器的对比分析

你可能感兴趣的:(LVS的3种工作模式和8种调度算法)