ipvsadm及lvs的调度算法

 libnet下载地址： http://search.cpan.org/dist/libnet/

ipvsadm下载地址： http://www.linuxvirtualserver.org/software/ipvs.html#kernel-2.6
从Linux内核版本2.6起，ip_vs code已经被整合进了内核中，所以，只要在编译内核的时候选择了ipvs的功能，您的Linux即能支持LVS。Linux 2.4.23之后的内核版本也整合了ip_vs code，但若是是更旧的内核版本，您得本身手动将ip_vs code整合进内核原码中，并从新编译内核方可以使用lvs。
1、关于ipvsadm:
ipvsadm是运行于用户空间、用来与ipvs交互的命令行工具，它的做用表如今：
一、定义在Director上进行dispatching的服务(service)，以及哪此服务器(server)用来提供此服务；
二、为每台同时提供某一种服务的服务器定义其权重（即概据服务器性能肯定的其承担负载的能力）；
注：权重用整数来表示，有时候也能够将其设置为atomic_t；其有效表示值范围为24bit整数空间，即（2^24-1）；
所以，ipvsadm命令的主要做用表如今如下方面：
一、添加服务（经过设定其权重>0）；
二、关闭服务（经过设定其权重>0）；此应用场景中，已经链接的用户将能够继续使用此服务，直到其退出或超时；新的链接请求将被拒绝；
三、保存ipvs设置，经过使用“ipvsadm-sav > ipvsadm.sav”命令实现；
四、恢复ipvs设置，经过使用“ipvsadm-sav < ipvsadm.sav”命令实现；
五、显示ip_vs的版本号，下面的命令显示ipvs的hash表的大小为4k；
  # ipvsadm
    IP Virtual Server version 1.2.1 (size=4096)
六、显示ipvsadm的版本号
  # ipvsadm --version
   ipvsadm v1.24 2003/06/07 (compiled with popt and IPVS v1.2.0)

七、查看LVS上当前的全部链接
# ipvsadm -Lcn   
或者
#cat /proc/net/ip_vs_conn
八、查看虚拟服务和RealServer上当前的链接数、数据包数和字节数的统计值，则可使用下面的命令实现：
# ipvsadm -l --stats
九、查看包传递速率的近似精确值，可使用下面的命令：
# ipvsadm -l --rate
2、ipvsadm使用中应注意的问题
默认状况下，ipvsadm在输出主机信息时使用其主机名而非IP地址，所以，Director须要使用名称解析服务。若是没有设置名称解析服务、服务不可用或设置错误，ipvsadm将会一直等到名称解析超时后才返回。固然，ipvsadm须要解析的名称仅限于RealServer，考虑到DNS提供名称解析服务效率不高的状况，建议将全部RealServer的名称解析经过/etc/hosts文件来实现；

3、调度算法
Director在接收到来自于Client的请求时，会基于"schedule"从RealServer中选择一个响应给Client。ipvs支持如下调度算法：（一、2为静态调度算法，三、四、五、六、七、8为动态调度算法）
一、轮询（round robin, rr),加权轮询(Weighted round robin, wrr)——
新的链接请求被轮流分配至各RealServer；算法的优势是其简洁性，它无需记录当前全部链接的状态，因此它是一种无状态调度。轮叫调度算法假设全部服务器处理性能均相同，无论服务器的当前链接数和响应速度。该算法相对简单，不适用于服务器组中处理性能不一的状况，并且当请求服务时间变化比较大时，轮叫调度算法容易致使服务器间的负载不平衡。

二、目标地址散列调度（Destination Hashing，dh）

算 法也是针对目标IP地址的负载均衡，但它是一种静态映射算法，经过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。目标地址散列调度算法先 根据请求的目标IP地址，做为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，不然返回空。

三、源地址散列调度（Source Hashing，sh）

算 法正好与目标地址散列调度算法相反，它根据请求的源IP地址，做为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，不然返回空。它采用的散列函数与目标地址散列调度算法 的相同。除了将请求的目标IP地址换成请求的源IP地址外，它的算法流程与目标地址散列调度算法的基本类似。在实际应用中，源地址散列调度和目标地址散列 调度能够结合使用在防火墙集群中，它们能够保证整个系统的惟一出入口。

 

四、最少链接(least connected, lc)， 加权最少链接(weighted least connection, wlc)——
新的链接请求将被分配至当前链接数最少的RealServer；最小链接调度是一种动态调度算法，它经过服务器当前所活跃的链接数来估计服务器的负载状况。调度器须要记录各个服务器已创建链接的数目，当一个请求被调度到某台服务器，其链接数加1；当链接停止或超时，其链接数减一。
lc：256*A+I=当前链接数  wlc：（256*A+I）/W=当前链接数   【A：活动链接数  I:非活动链接数 W：权重值】
五、基于局部性的最少连接调度（Locality-Based Least Connections Scheduling，lblc）——
针对请求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统，由于在Cache集群中客户请求报文的目标IP地址是变化的。这里假设任何后端服务器均可以处理任一请求，算法的设计目标是在服务器的负载基本平衡状况下，将相同目标IP地址的请求调度到同一台服务器，来提升各台服务器的访问局部性和主存Cache命中率，从而整个集群系统的处理能力。LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于其一半的工做负载，则用“最少连接”的原则选出一个可用的服务器，将请求发送到该服务器。
六、带复制的基于局部性最少连接调度（Locality-Based Least Connections with Replication Scheduling，lblcr）

——也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不一样之处是它要维护从一个目标IP地址到一组服务器的映射，而 LBLC算法维护从一个目标IP地址到一台服务器的映射。对于一个“热门”站点的服务请求，一台Cache 服务器可能会忙不过来处理这些请求。这时，LBLC调度算法会从全部的Cache服务器中按“最小链接”原则选出一台Cache服务器，映射该“热门”站点到这台Cache服务器，很快这台Cache服务器也会超载，就会重复上述过程选出新的Cache服务器。这样，可能会致使该“热门”站点的映像会出如今全部的Cache服务器上，下降了Cache服务器的使用效率。LBLCR调度算法将“热门”站点映射到一组Cache服务器（服务器集合），当该“热门”站点的请求负载增长时，会增长集合里的Cache服务器，来处理不断增加的负载；当该“热门”站点的请求负载下降时，会减小集合里的Cache服务器数目。这样，该“热门”站点的映像不太可能出如今全部的Cache服务器上，从而提供Cache集群系统的使用效率。LBLCR算法先根据请求的目标IP地址找出该目标IP地址对应的服务器组；按“最小链接”原则从该服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载；则按“最小链接”原则从整个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以下降复制的程度。
七、 最短的指望的延迟（Shortest Expected Delay Scheduling ,sed）
sed: (A+1)/w=当前链接数
八、最少队列调度（Never Queue Scheduling ,nq）
无需队列。若是有台realserver的链接数＝0就直接分配过去，不须要在进行sed运算
4、关于LVS追踪标记fwmark：
若是LVS放置于多防火墙的网络中，而且每一个防火墙都用到了状态追踪的机制，那么在回应一个针对于LVS的链接请求时必须通过此请求链接进来时的防火墙，不然，这个响应的数据包将会被丢弃。