lvs详细介绍

Posted 2020-10-11

lvs详细介绍

  LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。本项目在1998年5月成立，是中国国内最早出现的自由软件项目之一。LVS采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。

一、几种集群环境介绍

  说lvs前先来说说集群，根据所适用场景的不同，最常见的集群有以下三种类型：负载均衡集群（LB：Load Balance），高可用集群（HA：High Availability），高性能集群（HP：High Performance）。

  1）LB集群主要有应用层和传输层两个层次上的实现，有硬件的实现，也有开源软件的实现，硬件类型的LB设备主要有美国的F5的BIG/IP、思杰的NetScaler、A10、Array、RadWare，开源软件的实现主要有LVS（工作在四层）、Haproxy(四层、七层都可实现，但主要是七层的实现)、nginx(应用层的实现)。

  2）HA集群中开源的解决方案主要有heartbeat、keepalived、corosync+pacemaker、cman+rgmanager、cman+pacemaker。

  3）HP集群使用在一些特殊的场景，为高性能集群。

  4）DS：Distributed System，分布式系统；hadoop，HDFS，GlusterFS，mogilefs

二、LVS各种类型介绍

常见的术语

vs：调试器，virtual server, Director, Dispatcher, Balancer

rs：后端服务器，real server, backend server, upstream server

CIP：Client IP，客户端IP地址，即：请求发送方的IP地址；

VIP：Virtual Server IP，虚拟服务器的虚拟IP地址，客户端访问的目的地址；

DIP：Director IP，调度器IP地址，向后方Real Server转发客户端请求时使用的IP地址；

RIP：Real Server IP，后方真实服务器的IP地址；

LVS

   LVS工作在OSI七层模型中的第四层，是四层交换技术，它是工作在内核中的一段代码，根据目标地址和目标端口实现数据转发，它并且是工作在netfiler框架上。LVS分为两个部份，一部份工作在内核，叫ipvs，另一部份工作在用户空间，叫ipvsadmin，用此用户空间工具编写调度规则。

   LVS的架构类型大体上分为三种类型，一是VS/NAT，二是VS/DR，三是VS/TUN，四是lvs/fullnat。下边分别对这几种类型进行阐述。

1）lvs-nat

   多目标IP地址的DNAT，通过将请求报文中的目标地址和目标端口修改为某个利用调度算法挑选出来的后端RS的RIP和PORT的过程实现的转发；

 调度的大致过程：

  首先客户端向director的vip发起服务请求，在netfiler框架上的INPUT链上ipvs发现客户端请求的是自己定义好的集群服务，那director采用静态或动态算法从自己的规则中挑选出一个real server出来，再把客户端请求报文做DNAT转换，把请求报文的目的地址修改成已挑选出real server的ip地址，然后重新封装报文发送给real server；而当real server收到director的请求报文后，就会分析此报文看对方请求的是什么资源，再把资源准备好封装成响应报文发送给director，director再做SNAT，把源地址修改成自己的vip地址后把报文发送给客户端；在客户端看来他是直接访问的是director，而作出响应的也是director，其后端的real server对客户端是不可见的，对用户是透明的。

 注意下列几个问题：

  1.RIP和DIP必须在同一网段，并且应该是私有IP地址；RS的网关应该指向DIP；

  2.请求报文和响应报文都必须经过Director转发，Director易于成为系统性能瓶颈并引发单点故障；

  3.可以实现端口重定向；CIP向VIP发送请求的端口号可以与后端的RIP所提供服务的服务端口不同；

  4.VS必须是Linux系统，RS可以是任意操作系统；

2）lvs-dr：默认类型

  dr：Direct Routing，直接路由；

  通过为请求报文重新封装一个数据链路层首部(MAC地址)进行报文转发；重新封装之后的报文的源MAC地址是DIP所在网络接口的MAC地址；目的MAC地址是某个利用调度算法挑选出来的后端RS的RIP所在接口的MAC地址；源IP地址和源PORT，以及目的IP地址和目的PORT，在整个报文转发过程中保持不变；

 调度大致过程：

  客户端请求报文到达director的vip后，director发现是请求是一个集群服务，director采用静态或动态算法挑选出一个real server，这时director不再像VS/NAT中会修改报文中ip首部的目标ip，而是把目标MAC修改成已挑选real server的rip的MAC地址，因dip与rip是在同一个二层网络中，只需要MAC地址即可完成寻址，所以被修改了目的MAC的报文能成功送到real server，real server把报文拆开后发现目的MAC的确是rip上的MAC，所以它会处理这个报文，real server把客户端要请求的资源准备好后，强行让报文从“lo:0”这样的子接口上送出去，这个接口配置了vip的地址，每个real server都会配置rip与vip的地址，所以为了让vip地址不会导致冲突，所以各real server都要采取一定的机制让配置在"lo:0"上的vip地址不被网络上的其他设备得知，这个地址只是用在响应报文中把响应报文的源地址封装成vip的，这样响应报文就可通过real server直接到达客户端，而不必再通过director的再次转发，这样，接入的报文通过director，而响应报文则直接送到客户端，而客户端看到的报文也是从vip送回来的（其实是从real server来的），这种VS/DR模型让director得到的解放，只处理接入报文，压力也变得更小，能带动的real server也更多，处理并发能力更强，但后端real server配置比较麻烦。

 注意以下几个问题：

  1.确保前端路由器能够将目标IP地址为VIP的报文发往VS(Director)；

1) 在路由器上静态绑定IP地址和MAC地址的映射关系；

2) 在RS上使用arptables；

3) 在RS上修改内核参数限制ARP的通告和对ARP请求的应答；

arp_announce

arp_ignore

 2.RS的RIP可以是私有地址也可以是公有地址，RIP和DIP应该在同一逻辑网络；

 3.请求报文必须要经过Director，但是所有的响应报文不需要经过Director直接通过路由转发给客户端即可；

 4.不支持端口重定向；

 5.RS必须是Linux操作系统；

 6.RS上必须配置RIP和VIP，并且VIP应该配置在lo接口的lable上；

3）lvs-tun：tunnel，隧道

  不修改请求报文的IP首部(源IP为CIP，目的IP为VIP)，而是在原有的IP报文的封装格式之外再次封装一个IP首部(源IP为DIP，目的IP为RIP)，将重新封装的报文发往使用调度算法挑选出的后端RS上；

 调度的大致过程：

  VS/TUN类型利用了IP隧道技术，把一个IP报文封装了另一个IP报文，这可以使把目标为一个IP的报文能封装转发到另一个IP地址。请求报文到达director后，director采用静态或动态算法挑选一个在隧道上的real server地址，把原来的源地址为cip，目标地址为vip的ip报文又封装在另一个IP报文上，把此IP报文送到隧道上转以给real server，real server拆开报文看到目标地址是vip，而自己的“lo:0”接口上又配置了vip，所以能正常的处理此报文，将响应报文准备好后，又可直接送达到cip。

 注意以下几个问题：

1.CIP，VIP，DIP，RIP都应该是公有IP地址；

2.RS的网关无法指向DIP，因此响应报文不会经过Director转发，而是直接发往CIP；

3.不支持端口重定向；

4.RS必须支持隧道协议；

5.RS上必须配置RIP和VIP；

4）lvs-fullnat

非标准类型；

通过同时修改请求报文的源IP地址和目的IP地址实现报文转发；

CIP --> DIP

VIP --> RIP

 注意以下几个问题：

1.VIP是公有地址，DIP和RIP是私有地址，且DIP和RIP可以不在同一网段；

2.RS对收到的请求报文的响应报文的目的地址是DIP，所以请求报文和响应报文都必须经过Director；

3.支持端口重定向；

4.此类型默认不支持；

三、LVS各种调度算法介绍

 根据lvs在调度时是否考虑各RS当前的负载状态，可以将调度算法分为两类:

静态调度算法: 

  仅根据调度算法本身进行调度。

  1)rr：round robin(轮流，轮询，轮叫)，这种算法是起点公平，但根据时间推移，各real server会产生负载不均衡的情况；

  2)wrr：weighted round robin（加权的轮询），用于real server服务器硬件性能不同时的场景；

  3)sh：source hashing（源地址hash），表示来源于同一个cip的请求将始终被定向到同一个rs，使用在需要session保持的场景，但这种算法又打破了负载均衡的初衷；

  4)dh：destination hashing(目标地址hash)，表示访问同一地址的资源始终被定向到同一个real server，用在内部访问外部网络时有两个出口（防火墙）时的特殊场景；

动态调度算法:

  根据算法及各real server当前的负载状况进行衡量计算后再进行调度。

  1)lc：least connection(最少连接)，lc算法是把新的连接调度给当前连接数最小的real server；

Overhead(负载)=Active*256+Inactive，值越小，越先被调度到

  2)wlc：weighted least connection（带权重的最少连接）,此算法是lc算法的一个补充，各real server用一个权值来代表其处理能力，director尽可能使用其调度按照其权值的比例来调度，这是IPVS的默认算法；

Overhead(负载)=(Active*256+Inactive)/weighted，这种算法会导致一种现象，在集群初始状态时，各real server没有活动连接，而在director的调度规则中把权重小的real server排在了前边，那最开始director会调度到权重小的real server上，而在现实中我们希望是先调度到处理能力强的（权重大）real server上；

  3)sed：shoutest expection delay(最短期望延迟)，表示让在初始状态时能让director挑选到权重大的real server，即使是权重小的real server在director规则中的前边，这种算法在各real server权重相差较大时会导致权重小的real server在一段时间内不会分配连接请求；

Overhead=(Active+1)*256/weight

  4)nq：never queue(永不排队)，表示在初始状态时director会依据weight的大小至上而下的为每一个RS分配一个连接，保证每一个real server都能在最短的时间内得到连接请求，解决了sed算法中real server有可能会在一段时间内不会分配到连接请求的问题；

  5)lblc：Locality-Based Least Connection(基于局部性的最少连接)，此算法是针对请求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统；

  6)lblcr：Replication lblc(带复制功能的lblc)，此算法是针对请求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统。

本文出自 “12657170” 博客，请务必保留此出处http://12667170.blog.51cto.com/12657170/1972993