1. 本章介绍LVS的一些相关概念，调度策略和集群架构类型。下一章开始讲解LVS－NAT集群
2. 从Linux内核2.4.23开始，加入了一个叫做IP Virtual Server(IPVS)的特性，这就使得我们可以把一台Linux机器作为一个load balancer来使用。LVS就是一个很好的构建Linux load balance集群的软件。
3. LVS Address Name Conventions. 这里介绍一下LVS中会提到的多种IP的专有名称，其实看图就明白了：见附件1
OK，从图上就能明白这些IP的意思了：
Virtual IP (VIP) address
The IP address the Director uses to offer services to client computers
Real IP (RIP) address
The IP address used on the cluster nodes Director's IP (DIP) address
Director's IP(DIP) address
The IP address the Director uses to connect to the D/RIP network
Client computer's IP (CIP) address
The IP address assigned to a client computer that it uses as a source IP address for requests sent to the cluster
2. 从Linux内核2.4.23开始，加入了一个叫做IP Virtual Server(IPVS)的特性，这就使得我们可以把一台Linux机器作为一个load balancer来使用。LVS就是一个很好的构建Linux load balance集群的软件。
3. LVS Address Name Conventions. 这里介绍一下LVS中会提到的多种IP的专有名称，其实看图就明白了：见附件1
OK，从图上就能明白这些IP的意思了：
Virtual IP (VIP) address
The IP address the Director uses to offer services to client computers
Real IP (RIP) address
The IP address used on the cluster nodes Director's IP (DIP) address
Director's IP(DIP) address
The IP address the Director uses to connect to the D/RIP network
Client computer's IP (CIP) address
The IP address assigned to a client computer that it uses as a source IP address for requests sent to the cluster
4. LVS支持的load balance的方式共有三种：LVS-NAT, LVS-DR, LVS-TUN，本书重点讲解LVS-DR, LVS-TUN不讲，LVS-NAT简单讲解。其实LVS-TUN也不错，网上有资料，他是通过IP Tunneling的技术来做，和VPN有点像。
5. LVS-NAT，先看这张图：见附件1
从图中可以看到，所有的请求和回应都要经过load balancer，无疑这是一个瓶颈，所以，一般小规模的用这种架构，因为搭建简单。主要的特点如下：
(1)cluster nodes和director(load balancer)要位于同一网段。
(2)一般cluster node上都分配假IP地址，如192.x.x.x
(3)director架构request和response信息
(4)一般来说，director的DIP也就是cluster nodes的网关IP
(5)这种架构下，director可以remap一个端口，如可以把来自客户端的一个80端口请求映射到cluster某个node上的8080端口。（iptable嘛，自然可以）
(6)cluster nodes的OS可以自由选择，可以不同
(7)director是整个系统的bottleneck
6. LVS-DR，先看图：附件2
图上可以看出，请求直接由cluster node返回给client。这种架构有如下特性：
(1)cluster node和director要在同一个网段内。
(2)cluster nodes的IP地址不一定要是假IP地址
(3)director只需承受request的请求
(4)cluster node一般不把director作为他们的gateway
(5)director不能remap端口
(6)cluster node的OS可以不同
(7)LVS-DR比LVS－NAT，可以接受更多的负载
7. LVS-TUN，看图：附件3
从图上可以看出，和LVS－DR不同，这里利用了IP Tunneling的技术，这种技术是把一个包封装在另外一个包内，这样，接受端解开包后得到真正的那个包，就可以直接和包中的地址建立联系，和VPN有 点像，在LVS的官方中文站点有专门的详细文章。这种架构的特点如下：
(1)cluster node和director不需要一定要在一个网段内，因为采用了IP Tunneling，可以让两个不同网段的IP直接通讯。所以，这是一种最松散的架构，director和cluster nodes可能位于internet上，不像前两种，director和cluster nodes都在一个局域网内。
(2)RIP不能是假IP地址
(3)director只需要处理request
(4)response的信息不能经过director，换句话说，director不能是cluster nodes的gateway
(5)director不能remap端口
(6)cluster nodes的操作系统，必须要支持IP Tunneling protocol
5. LVS-NAT，先看这张图：见附件1
从图中可以看到，所有的请求和回应都要经过load balancer，无疑这是一个瓶颈，所以，一般小规模的用这种架构，因为搭建简单。主要的特点如下：
(1)cluster nodes和director(load balancer)要位于同一网段。
(2)一般cluster node上都分配假IP地址，如192.x.x.x
(3)director架构request和response信息
(4)一般来说，director的DIP也就是cluster nodes的网关IP
(5)这种架构下，director可以remap一个端口，如可以把来自客户端的一个80端口请求映射到cluster某个node上的8080端口。（iptable嘛，自然可以）
(6)cluster nodes的OS可以自由选择，可以不同
(7)director是整个系统的bottleneck
6. LVS-DR，先看图：附件2
图上可以看出，请求直接由cluster node返回给client。这种架构有如下特性：
(1)cluster node和director要在同一个网段内。
(2)cluster nodes的IP地址不一定要是假IP地址
(3)director只需承受request的请求
(4)cluster node一般不把director作为他们的gateway
(5)director不能remap端口
(6)cluster node的OS可以不同
(7)LVS-DR比LVS－NAT，可以接受更多的负载
7. LVS-TUN，看图：附件3
从图上可以看出，和LVS－DR不同，这里利用了IP Tunneling的技术，这种技术是把一个包封装在另外一个包内，这样，接受端解开包后得到真正的那个包，就可以直接和包中的地址建立联系，和VPN有 点像，在LVS的官方中文站点有专门的详细文章。这种架构的特点如下：
(1)cluster node和director不需要一定要在一个网段内，因为采用了IP Tunneling，可以让两个不同网段的IP直接通讯。所以，这是一种最松散的架构，director和cluster nodes可能位于internet上，不像前两种，director和cluster nodes都在一个局域网内。
(2)RIP不能是假IP地址
(3)director只需要处理request
(4)response的信息不能经过director，换句话说，director不能是cluster nodes的gateway
(5)director不能remap端口
(6)cluster nodes的操作系统，必须要支持IP Tunneling protocol
8. LVS Scheduling Methods. 首先介绍第一种，Fixed(or Non-Dynamic) Scheduling Methods. 这其实是一类调度算法，他们的共同特点就是静态的，一旦定义好了以后，不会根据具体情况做有逻辑的处理，这是呆板的根据调度定义来工作。比如这些算法都是 Fixed类型：
(1)Round-robin(RR)－－当一个请求到来时，director根据round-robin服务器的清单中挨个选择下一个server来接受请求，完全不管这个server目前是否负载重，是否连接过多等，只是呆板的依次在清单中向下选择，到尾了再返回。
(2)Weighted round-robin(WRR)－－在RR的基础上，给cluster中每个服务器赋予一个weight的东西以表示机器的性能。比如一台weight为2的服务器就能接受两个请求，而一个weight为1的机器只能接受一个请求。当然，weight为0的机器，director永远不会将请求递交给他，注意，即便是在动态调度策略中，将weight设置为0也是有用的，所以，如果你想维护一台机器，暂时不想让这台机器接受请求的话，将他的weight设置为0即可。
(3)Destination Hashing. 每个请求都会有个目的IP地址，这种调度算法下，相同的destination ip的请求，都会被调度到同一台cluster的server上。这种调度算法，当cluster中的server都是proxy或cache server的时候特别有用，因为这些server对这些destination ip都有cache，能很快的处理完请求。
(4)Source Hashing. This method can be used when the Director needs to be sure the reply packets are sent back to the same router or firewall that the requests came from. This scheduling method is normally only used when the Director has more than one physical network connection, so that the Director knows which firewall or router to send the reply packet back through to reach the proper client computer.
9. Dynamic Scheduling Method. 和静态的调度策略最大的不同是，在动态调度算法下，LVS会记录cluster中每台服务器当前的active和inactive的连接数量，根据每台服 务器当前的负载情况来决定下一个请求交给哪台服务器处理。所谓一个active的connection，指的是一个TCP session保持在open（也就是ESTABLISHED状态），比如telnet和ssh就一直会保持open状态，除非该用户退出。一个 inactive的connection，也就是不在ESTABLISH状态的一个连接了，一般情况下，用户关闭（发送了一个FIN packet），超时都会导致一个inactive connection，LVS会在IPVS table中会保留一个connection即便该connection已经drop了，这是因为如果短时间内该connection又要建立的话，那就 可以直接建立了，性能很好（director和cluster node都会这样做）。
10. OK，动态调度策略第一种：Least-Connection(LC)。这种调度策略逻辑是这样的，顾名思义，connection最少的那个处理请求。 当一个连接来到时，director将cluster node上每个node当前active的connection 乘以 256，然后加上每个node上inactive connection的数量，得到一个数值，这个数值最小的那台服务器处理该请求。
11. Weighted Least-Connection(WLC). WLC调度策略和LC一样，只不过在LC调度方法中算出来的那个overload的数值，再除以每台机器的Weight，得到一个新数值，这个数值最小的 那台机器处理请求，如果大家的数值都一样，那么，LVS选择在服务器列表中的第一台机器处理请求。就是结合了weight和LC策略的一种策略，注意，这是LVS缺省的调度策略，因为这种策略确实能应付不少场合。
12. shortest expected delay(sed). sed方法是最近加到LVS调度策略中的，这种方法比WLC稍微好一些，特别是处理很多连接是TCP长连接的场合（比如large batch job的场合，ssh或telnet一直开着）。他的算法是这样的，每台服务器的active connection的数量 + 1, 然后除以每台机器的weight，算出来的数值最小的那台服务器处理请求。注意这种算法，它不考虑inactive connection的情况（这就是为什么刚才提到这种算法特别适合很多TCP长连接的场景），而且他通过在active connection上加1来模拟该机器接受了新的连接后的情景。考虑这样一个例子，如果算法中不在active connection上加1：比如我们有两台机器，一台weight是1，有10个active connection，一台weight是3，有30个active connection，如果不加1，那么，这种算法下两台机器算下来的值都是10，那么，LVS在server list中挑选第一条服务器来处理请求，不确定到底是哪台；但是加了1以后，那么，weight是1的机器算下来的数值是10，但是weight是3的机 器算下来的数值是10.34，由weight高的那台机器处理请求，这显然是合理的。
但是这种算法有一个缺陷，就是当某些server上没有负载的时候，request却不会被调度上去，比如，还是两台机器，一个weight是 1，但是目前没有active连接，一台weight是3，目前有一个active connection，此时来了一个请求，按照算法，weight是1的机器算下来的值是1，weight是3的机器算下来是0.67－－还是 weight是3的机器处理请求，这就不合理了，应该让没有active connection的机器处理才对，基于此，下面一种调度策略（NQ）诞生了。
13. Never Queue(NQ)。这种策略就是对SED的一个改进，他规定如果某台机器上当前没有active connection，那么，不管SED计算的值如何，request都被调度到这台机器上。
14. Locality-Based Least-Connection(LBLC). 这种调度策略基于proxy/cache server的基础，有点像静态策略中的destination hashing, 他是这样的，当一个请求（请求某个特定的IP地址，比如是一个web server）第一次来的时候，LVS根据WLC（确切的应该是一个稍微经过改动的WLC算法）算法选定一台proxy server（比如这台服务器叫A）来处理该请求，那么，下次请求再过来的时候（当然请求的目的地一样，都是那台web server），那么，LVS就将请求直接给这台A服务器处理。这样可以非常有效的提高请求的cache命中率，提高请求处理性能。当然也不能一直这样下 去，当LVS发现当前A服务器的wlc值已经是最小的wlc值的2倍的时候，那么，LVS会把请求再调度给wlc值最小的那台服务器（假设叫B）处理，以 后这类请求就给B服务器处理，如此循环往复。
15. Locality-Based Least-Connection with Replication Scheduling(LBLCR). 这种算法也是对LBLC的一些改进，他建立了一个proxy server的set，这个set中有一批proxy server都能处理同样一种destination是一样的request，每次，LVS从这个SET中挑选active connection最少的那台服务器来处理请求。流程是这样的，首先请求来了，根据LBLC的算法，有了一台A服务器处理请求，当出现A服务器的wlc 是最小wlc 2倍的情况时，根据LBLC算法，新的最小wlc服务器B开始接受请求，但是在LBLCR中，新的B服务器被add到set中，和A服务器列在一起，然后 由B开始处理请求（因为B的active connection还是最少的嘛），如此往复，这个set中就会有不少的机器罗列在内。那么什么时候proxy server会被从set中删除呢？是这样的，当LVS发现这个set中服务器的清单在6分钟内没有变化时（这意味着6分钟内没有服务器被add进去，也 没有服务器被删除，这6分钟一直是由这个set中的那些服务器在“扛”），LVS就会把active connection最多的那台服务器从set中删除。
OK，结束本章，LVS的调度策略还是蛮精彩的，在实践过程中可以常回来看看，对LVS肯定有更好的理解。
(1)Round-robin(RR)－－当一个请求到来时，director根据round-robin服务器的清单中挨个选择下一个server来接受请求，完全不管这个server目前是否负载重，是否连接过多等，只是呆板的依次在清单中向下选择，到尾了再返回。
(2)Weighted round-robin(WRR)－－在RR的基础上，给cluster中每个服务器赋予一个weight的东西以表示机器的性能。比如一台weight为2的服务器就能接受两个请求，而一个weight为1的机器只能接受一个请求。当然，weight为0的机器，director永远不会将请求递交给他，注意，即便是在动态调度策略中，将weight设置为0也是有用的，所以，如果你想维护一台机器，暂时不想让这台机器接受请求的话，将他的weight设置为0即可。
(3)Destination Hashing. 每个请求都会有个目的IP地址，这种调度算法下，相同的destination ip的请求，都会被调度到同一台cluster的server上。这种调度算法，当cluster中的server都是proxy或cache server的时候特别有用，因为这些server对这些destination ip都有cache，能很快的处理完请求。
(4)Source Hashing. This method can be used when the Director needs to be sure the reply packets are sent back to the same router or firewall that the requests came from. This scheduling method is normally only used when the Director has more than one physical network connection, so that the Director knows which firewall or router to send the reply packet back through to reach the proper client computer.
9. Dynamic Scheduling Method. 和静态的调度策略最大的不同是，在动态调度算法下，LVS会记录cluster中每台服务器当前的active和inactive的连接数量，根据每台服 务器当前的负载情况来决定下一个请求交给哪台服务器处理。所谓一个active的connection，指的是一个TCP session保持在open（也就是ESTABLISHED状态），比如telnet和ssh就一直会保持open状态，除非该用户退出。一个 inactive的connection，也就是不在ESTABLISH状态的一个连接了，一般情况下，用户关闭（发送了一个FIN packet），超时都会导致一个inactive connection，LVS会在IPVS table中会保留一个connection即便该connection已经drop了，这是因为如果短时间内该connection又要建立的话，那就 可以直接建立了，性能很好（director和cluster node都会这样做）。
10. OK，动态调度策略第一种：Least-Connection(LC)。这种调度策略逻辑是这样的，顾名思义，connection最少的那个处理请求。 当一个连接来到时，director将cluster node上每个node当前active的connection 乘以 256，然后加上每个node上inactive connection的数量，得到一个数值，这个数值最小的那台服务器处理该请求。
11. Weighted Least-Connection(WLC). WLC调度策略和LC一样，只不过在LC调度方法中算出来的那个overload的数值，再除以每台机器的Weight，得到一个新数值，这个数值最小的 那台机器处理请求，如果大家的数值都一样，那么，LVS选择在服务器列表中的第一台机器处理请求。就是结合了weight和LC策略的一种策略，注意，这是LVS缺省的调度策略，因为这种策略确实能应付不少场合。
12. shortest expected delay(sed). sed方法是最近加到LVS调度策略中的，这种方法比WLC稍微好一些，特别是处理很多连接是TCP长连接的场合（比如large batch job的场合，ssh或telnet一直开着）。他的算法是这样的，每台服务器的active connection的数量 + 1, 然后除以每台机器的weight，算出来的数值最小的那台服务器处理请求。注意这种算法，它不考虑inactive connection的情况（这就是为什么刚才提到这种算法特别适合很多TCP长连接的场景），而且他通过在active connection上加1来模拟该机器接受了新的连接后的情景。考虑这样一个例子，如果算法中不在active connection上加1：比如我们有两台机器，一台weight是1，有10个active connection，一台weight是3，有30个active connection，如果不加1，那么，这种算法下两台机器算下来的值都是10，那么，LVS在server list中挑选第一条服务器来处理请求，不确定到底是哪台；但是加了1以后，那么，weight是1的机器算下来的数值是10，但是weight是3的机 器算下来的数值是10.34，由weight高的那台机器处理请求，这显然是合理的。
但是这种算法有一个缺陷，就是当某些server上没有负载的时候，request却不会被调度上去，比如，还是两台机器，一个weight是 1，但是目前没有active连接，一台weight是3，目前有一个active connection，此时来了一个请求，按照算法，weight是1的机器算下来的值是1，weight是3的机器算下来是0.67－－还是 weight是3的机器处理请求，这就不合理了，应该让没有active connection的机器处理才对，基于此，下面一种调度策略（NQ）诞生了。
13. Never Queue(NQ)。这种策略就是对SED的一个改进，他规定如果某台机器上当前没有active connection，那么，不管SED计算的值如何，request都被调度到这台机器上。
14. Locality-Based Least-Connection(LBLC). 这种调度策略基于proxy/cache server的基础，有点像静态策略中的destination hashing, 他是这样的，当一个请求（请求某个特定的IP地址，比如是一个web server）第一次来的时候，LVS根据WLC（确切的应该是一个稍微经过改动的WLC算法）算法选定一台proxy server（比如这台服务器叫A）来处理该请求，那么，下次请求再过来的时候（当然请求的目的地一样，都是那台web server），那么，LVS就将请求直接给这台A服务器处理。这样可以非常有效的提高请求的cache命中率，提高请求处理性能。当然也不能一直这样下 去，当LVS发现当前A服务器的wlc值已经是最小的wlc值的2倍的时候，那么，LVS会把请求再调度给wlc值最小的那台服务器（假设叫B）处理，以 后这类请求就给B服务器处理，如此循环往复。
15. Locality-Based Least-Connection with Replication Scheduling(LBLCR). 这种算法也是对LBLC的一些改进，他建立了一个proxy server的set，这个set中有一批proxy server都能处理同样一种destination是一样的request，每次，LVS从这个SET中挑选active connection最少的那台服务器来处理请求。流程是这样的，首先请求来了，根据LBLC的算法，有了一台A服务器处理请求，当出现A服务器的wlc 是最小wlc 2倍的情况时，根据LBLC算法，新的最小wlc服务器B开始接受请求，但是在LBLCR中，新的B服务器被add到set中，和A服务器列在一起，然后 由B开始处理请求（因为B的active connection还是最少的嘛），如此往复，这个set中就会有不少的机器罗列在内。那么什么时候proxy server会被从set中删除呢？是这样的，当LVS发现这个set中服务器的清单在6分钟内没有变化时（这意味着6分钟内没有服务器被add进去，也 没有服务器被删除，这6分钟一直是由这个set中的那些服务器在“扛”），LVS就会把active connection最多的那台服务器从set中删除。
OK，结束本章，LVS的调度策略还是蛮精彩的，在实践过程中可以常回来看看，对LVS肯定有更好的理解。