linux 内核round-robin scheduler代码,用LVS构架负载均衡Linux集群系统 linux lvs

never queue scheduling

--- IPVS application helper

FTP protocol helper

以上所有项建议全部选择。

(4)Networking options项中的IP: Netfilter Configuration项

对于2.4版本以上的Linux Kernel来说，iptables是取代早期ipfwadm和ipchains的更好选择，所以除非有特殊情况需要用到对ipchains和 ipfwadm的支持，否则就不要选它。本文在LVS/NAT方式中，使用的就是iptables，故这里不选择对ipchains和ipfwadm的支持：

< > ipchains (2.2-style) support

< > ipfwadm (2.0-style) support

10. 编译内核

(1)检查依赖关系

# make dep

确保关键文件在正确的路径上。

(2)清除中间文件

# make clean

确保所有文件都处于最新的版本状态下。

(3)编译新核心

# make bzImage

(4)编译模组

# make modules

编译选择的模组。

(5)安装模组

# make modules_install

# depmod -a

生成模组间的依赖关系，以便modprobe定位。

(6)使用新模组

# cp System.map /boot/System.map-2.4.20-LVS

# rm /boot/System.map

# ln -s /boot/System.map-2.4.20-LVS /boot/System.map

# cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.20-LVS

# rm /boot/vmlinuz

# ln -s /boot/vmlinuz-2.4.20-LVS /boot/vmlinuz

# new-kernel-pkg --install --mkinitrd --depmod 2.4.20-LVS

(7)修改GRUB，以新的核心启动

执行完new-kernel-pkg命令后，GRUB的设置文件/etc/grub.conf中已经增加了新核心的启动项，这正是开始安装Linux时推荐使用GRUB做引导程序的原因。

grub.conf中新增内容如下：

title Red Hat Linux (2.4.20-LVS)

root (hd0,0)

kernel /boot/vmlinuz-2.4.20LVS ro root=LABEL=/

initrd /boot/initrd-2.4.20LVS.img

将Kernel项中的root=LABEL=/改成 root=/dev/sda1 (这里的/dev/sda1是笔者Linux的根分区，读者可根据自己的情况进行不同设置)。

保存修改后，重新启动系统:

# reboot

系统启动后，在GRUB的界面上会出现Red Hat Linux(2.4.20-LVS)项。这就是刚才编译的支持LVS的新核心，选择此项启动，看看启动过程是否有错误发生。如果正常启动，ipvs将作为模块加载。同时应该注意到，用LVS的内核启动后在/proc目录中新增了一些文件，比如/proc/sys/net/ipv4/vs/*。

11.安装IP虚拟服务器软件ipvsadm

用支持LVS的内核启动后，即可安装IP虚拟服务器软件ipvsadm了。用户可以用tar包或RPM包安装，tar包可以从以下地址http: //下载进行安装。

这里采用源RPM包来进行安装：

# wget

# rpmbuild --rebuild ipvsadm-1.21-7.src.rpm

# rpm -ivh /usr/src/redhat/RPMS/i386/ipvsadm-1.21-7.i386.rpm

注意高版本的rpm命令去掉了--rebuild这个参数选项，但提供了一个rpmbuild命令来实现它。这一点和以前在Red Hat 6.2中以rpm―rebuild XXX.src.rpm来安装源RPM包的习惯做法有所不同。

安装完，执行ipvsadm命令，应该有类似如下的信息出现：

# ipvsadm

IP Virtual Server version 1.0.9 (size=4096)

Prot LocalAddress:Port Scheduler Flags

-> RemoteAddress:Port Forward Weight ActiveConn InActConn

出现类似以上信息，表明支持LVS的内核和配置工具ipvsadm已完全安装，这台Director机器已经初步安装完成，已具备构架各种方式的集群的条件。

原理

接下来的工作是根据实际需求选择采用何种负载分配方式和调度算法。目前LVS主要有三种请求转发方式和八种调度算法。根据请求转发方式的不同，所构架集群的网络拓扑、安装方式、性能表现也各不相同。用LVS主要可以架构三种形式的集群，分别是LVS/NAT、LVS/TUN和LVS/DR，可以根据需要选择其中一种。在选定转发方式的情况下，采用哪种调度算法将决定整个负载均衡的性能表现，不同的算法适用于不同的应用场合，有时可能需要针对特殊场合，自行设计调度算法。LVS的算法是逐渐丰富起来的，最初LVS只提供4种调度算法，后来发展到以下八种：

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)从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

了解这些算法原理能够在特定的应用场合选择最适合的调度算法，从而尽可能地保持Real Server的最佳利用性。当然也可以自行开发算法，不过这已超出本文范围，请参考有关算法原理的资料。

实例

理解了上述关于请求转发方式和调度算法的基本概念后，就可以运用LVS来具体实现几种不同方式的负载均衡的集群系统。LVS的配置是通过前面所安装的IP 虚拟服务器软件ipvsadm来实现的。ipvsadm与LVS的关系类似于iptables和NetFilter的关系，前者只是一个建立和修改规则的工具，这些命令的作用在系统重新启动后就消失了，所以应该将这些命令写到一个脚本里，然后让它在系统启动后自动执行。网上有不少配置LVS的工具，有的甚至可以自动生成脚本。但是自己手工编写有助于更深入地了解，所以本文的安装没有利用其它第三方提供的脚本，而是纯粹使用ipvsadm命令来配置。

下面就介绍一下如何配置LVS/NAT、LVS/TUN、LVS/DR方式的负载均衡集群。

1.设定LVS/NAT方式的负载均衡集群

NAT是指Network Address Translation，它的转发流程是：Director机器收到外界请求，改写数据包的目标地址，按相应的调度算法将其发送到相应Real Server上，Real Server处理完该请求后，将结果数据包返回到其默认网关，即Director机器上，Director机器再改写数据包的源地址，最后将其返回给外界。这样就完成一次负载调度。

构架一个最简单的LVS/NAT方式的负载均衡集群Real Server可以是任何的操作系统，而且无需做任何特殊的设定，惟一要做的就是将其默认网关指向Director机器。Real Server可以使用局域网的内部IP(192.168.0.0/24)。Director要有两块网卡，一块网卡绑定一个外部IP地址 (10.0.0.1)，另一块网卡绑定局域网的内部IP(192.168.0.254)，作为Real Server的默认网关。

这里将所有LVS的配置命令写到一个可执行脚本中，脚本如下：

#!/bin/bash

# Open IP Forwarding

echo 1 > /proc/sys/net/ipv4/ip_forward

# To make the load balancer forward the masquerading packets

iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -d 0.0.0.0/0 -o eth0 -j MASQUERADE

ipvsadm -C

# Choose the Weighted Round Robing

ipvsadm -A -t 10.0.0.1:80 -s wrr

# Set Real Server

ipvsadm -a -t 10.0.0.1:80 -r 192.168.0.1:873 -m -w 2

ipvsadm -a -t 10.0.0.1:80 -r 192.168.0.2:873 -m -w 3

ipvsadm

将该脚本保存为/root/lvs_nat.sh，然后加上可执行属性，执行它：

# chmod a+x /root/lvs_nat.sh

# /root/lvs_nat.sh

运行该脚本后，一个简单的LVS/NAT方式的负载均衡集群已经成功架设。模拟多个用户从外界访问10.0.0.1的80端口，用ipvsadm可以观看到以下信息：

# ipvsadm

IP Virtual Server version 1.0.9 (size=4096)

Prot LocalAddress:Port Scheduler Flags

-> RemoteAddress:Port Forward Weight ActiveConn InActConn

TCP 10.0.0.1:http wrr

-> 192.168.0.1:http Masq 3 2 0

-> 192.168.0.2:http Masq 2 1 0

其中ActiveConn表示对应的Real Server当前有多少个正在活动的连接，InActConn表示不活动的连接数。从这里我们可以看到有3个HTTP请求，被分别分配在不同的Real Server上，表明这个负载均衡集群正在成功运行中。

本例完成了这样一个简单的LVS/NAT集群，由此可以看出，LVS/NAT方式实现起来最为简单，而且Real Server使用的是内部IP，可以节省Real IP的开销。但因为执行NAT需要重写流经Director的数据包，在速度上有一定延迟；另外，当用户的请求非常短，而服务器的回应非常大的情况下，会对Director形成很大压力，成为新的瓶颈，从而使整个系统的性能受到限制。

2.设定LVS/TUN方式的负载均衡集群

TUN是指IP Tunneling，它的转发流程是：Director机器收到外界请求，按相应的调度算法将其通过IP隧道发送到相应Real Server，Real Server处理完该请求后，将结果数据包直接返回给客户。至此完成一次负载调度。

最简单的LVS/TUN方式的负载均衡集群架构使用IP Tunneling技术，在Director机器和Real Server机器之间架设一个IP Tunnel，通过IP Tunnel将负载分配到Real Server机器上。Director和Real Server之间的关系比较松散，可以是在同一个网络中，也可以是在不同的网络中，只要两者能够通过IP Tunnel相连就行。收到负载分配的Real Server机器处理完后会直接将反馈数据送回给客户，而不必通过Director机器。实际应用中，服务器必须拥有正式的IP地址用于与客户机直接通信，并且所有服务器必须支持IP隧道协议。

这里将所有LVS的配置命令写到一个可执行脚本，脚本内容如下：

#!/bin/bash

# Close IP Forwarding

echo 0 > /proc/sys/net/ipv4/ip_forward

ifconfig eth0 down

ifconfig eth0 192.168.0.253 netmask 255.255.255.0 broadcast 192.168.0.255 up

ifconfig eth0:0 192.168.0.254 netmask 255.255.255.255 broadcast 192.168.0.254 up

ipvsadm -C

ipvsadm -A -t 192.168.0.254:80 -s wlc

ipvsadm -a -t 192.168.0.254:80 -r 192.168.0.1 -i -w 3

ipvsadm -a -t 192.168.0.254:80 -r 192.168.1.201 -i -w 1

ipvsadm

将上面的脚本保存为/root/lvs_tun.sh。然后加上可执行属性，执行它：

# chmod a+x /root/lvs_tun.sh

# /root/lvs_tun.sh

运行此脚本之后应该出现如下信息：

# ./lvs-tun.sh

IP Virtual Server version 1.0.9 (size=4096)

Prot LocalAddress:Port Scheduler Flags

-> RemoteAddress:Port Forward Weight ActiveConn InActConn

TCP 192.168.0.254:http wlc

-> 192.168.1.201:http Tunnel 1 0 0

-> 192.168.0.1:http Tunnel 1 0 0

另外在每台Real Server上还要执行如下的命令：

ifconfig tunl0 192.168.0.254 netmask 255.255.255.255 broadcast 192.168.0.254 up

route add -host 192.168.0.254 dev tunl0

echo 1 > /proc/sys/net/ipv4/conf/all/hidden

echo 1 > /proc/sys/net/ipv4/conf/tunl0/hidden

注意Real Server的内核必须打上修正ARP问题的内核补丁，如Linux2.4.20的内核是hidden-2.4.20pre10-1.diff，编译内核的方法参见Director机器。

通过本例来简单评价一下LVS/TUN方式。该方式中Director将客户请求分配到不同的Real Server，Real Server处理请求后直接回应给用户，这样Director就只处理客户机与服务器的一半连接，极大地提高了Director的调度处理能力，使集群系统能容纳更多的节点数。另外TUN方式中的Real Server可以在任何LAN或WAN上运行，这样可以构筑跨地域的集群，其应对灾难的能力也更强，但是服务器需要为IP封装付出一定的资源开销，而且后端的Real Server必须是支持IP Tunneling的操作系统。

3.设定LVS/DR方式的负载均衡集群

DR是指Direct Routing，它的转发流程是：Director机器收到外界请求，按相应的调度算法将其直接发送到相应Real Server，Real Server处理完该请求后，将结果数据包直接返回给客户，完成一次负载调度。

构架一个最简单的LVS/DR方式的负载均衡集群Real Server和Director都在同一个物理网段中，Director的网卡IP是192.168.0.253，再绑定另一个IP： 192.168.0.254作为对外界的virtual IP，外界客户通过该IP来访问整个集群系统。Real Server在lo上绑定IP：192.168.0.254，同时加入相应的路由。

Director端的实现脚本如下：

#！/bin/bash

# set ip_forward OFF for vs-dr director (1 on, 0 off)

echo 0 > /proc/sys/net/ipv4/ip_forward

ifconfig eth0:0 192.168.0.254 netmask 255.255.255.255 broadcast 192.168.0.255 up

ipvsadm -C

ipvsadm -A -t 192.168.0.254:80 -s wlc

# Set Real Server

ipvsadm -a -t 192.168.0.254:80 -r 192.168.0.1:873 -g

ipvsadm -a -t 192.168.0.254:80 -r 192.168.0.2:873 -g

ipvsadm

将脚本保存为/root/lvs_dr.sh，加上可执行属性，执行它：

# chmod a+x /root/lvs_dr.sh

# /root/lvs_dr.sh

运行此脚本之后可以看到如下信息：

# ./lvs_dr.sh

IP Virtual Server version 1.0.9 (size=4096)

Prot LocalAddress:Port Scheduler Flags

-> RemoteAddress:Port Forward Weight ActiveConn InActConn

TCP 192.168.0.254:http wlc

-> 192.168.0.2:http Route 1 0 0

-> 192.168.0.1:http Route 1 0 0

另外每台Real Server上要执行如下命令：

ifconfig lo:0 192.168.0.254 netmask 255.255.255.255 broadcast 192.168.0.255 up

route add -host 192.168.0.254 dev lo:0

echo 1 > /proc/sys/net/ipv4/conf/all/hidden

echo 1 > /proc/sys/net/ipv4/conf/lo/hidden

注意Real Server的内核也必须打上修正ARP问题的内核补丁，编译内核的方法参见Director机器。

同样通过本例来简单评价一下LVS/DR方式。LVS/DR方式与前面的LVS/TUN方式有些类似，前台的Director机器也是只需要接收和调度外界的请求，而不需要负责返回这些请求的反馈结果，所以能够负载更多的Real Server，提高Director的调度处理能力，使集群系统容纳更多的Real Server。但LVS/DR需要改写请求报文的MAC地址，所以所有服务器必须在同一物理网段内。

结束语

其实集群架设到此还不能达到正式应用的要求，至少还需要解决三个问题：

1. 安装监视软件

集群运作时，应当监视集群中所有Real Server的运行情况并对其中的变化作出反应。如果发现Real Server突然down机，需要将其从集群队列中删除，等恢复后再重新加入。mon就是这样一个系统资源监控程序，可以监控网络服务可用性、服务器问题等。用户可以对其进行定制和扩展。

2. 后台Real Server节点的数据一致性问题和更新方法

比如一个提供Web服务的集群系统，每台服务器的Web资料必须一致，如果对Web资料的内容进行更新、增加或删除，如何使所有服务器之间数据同步呢？对于这种数据同步问题，一是采用网络镜像，如借用Mirror、FTP等来自行编写脚本进行镜像；另一种是使用网络文件系统，如coda等。

3. 提高可用性

以上示例中，Director机器只有一台，一旦Director机器down掉，整个集群也就崩溃了，所以要考虑使用两台机器做一个HA(High-Availability)。比如，配合使用Linux的另一个软件heartbeat来实现HA。

/sbin/ipvsadm -a -t 192.168.1.110:http -r 192.168.1.12 -g -w 1

-a 表示往一个服务内增加一个real server

-r 指定real server的IP地址

-w 表示权重

-g 表示使用DR方式，-m表示NAT方式，-i表示tunneling方式。

ipvsadm用到的其他几个参数含义如下：

-A 增加一个虚拟服务，该服务由协议、IP地址和端口号组成

例如：-A -t 202.99.59.110:80 (增加一格虚拟服务，其协议(-t表示tcp，-u表示udp)为TCP、IP为202.99.59.110、端口号为80。

-s 指定服务采用的算法，常用的算法参数如下：

rr 轮叫(Round Robin)

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

wrr 加权轮叫(Weighted Round Robin)

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

lc 最少链接(Least Connections)

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

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

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

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

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

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

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

dh 目标地址散列(Destination Hashing)

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

sh 源地址散列(Source Hashing)

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