LiuCHN®的博客：⌈思考、自由、启蒙、创业⌋，IT技术只是业余

本文介绍了Linux下的cluster软件LVS，并举例介绍一个Linux下的cluster(集群)的安装和实现的详细过程。
在各种网络服务普遍应用的今天，随网络速度的提高以及用户的增加，在一些繁忙的场合，单凭一台机器已经无法就能应付所有的网络请求了。为了解决这个问题，许多用户就采用一组cluster(集群)来代替单一的机器。cluster可以将多台计算机连接起来协同运作以对外提供各种服务，比如Apache、FTP、 Mail等。

在Linux上最常见的、也可能是运用最广泛的cluster方案就是LVS(Linux Virtual
Server)，很高兴LVS也是一个中国人创建和开发的开放源码项目。LVS自1998年开始，发展到现在已经是一个比较成熟的技术项目了。有许多比较著名网站和组织都在使用LVS架设的cluster，比如：www.linux.com、sourceforge.net、www.real.com等。

下面就开始介绍一下，笔者是如何利用LVS来架设一组cluster来对外提供Apache和FTP服务的。

安装操作系统

笔者选用的是Red Hat 9.0作为些cluster的director机器和所有real server机器的操作系统。RH的安装过程从略，笔者根据实际需要，只安装了少数的包。对于成批安装Linux，建议试试Kickstart来进入批理安装。

编译支持LVS的内核

LVS对Linux的kernel进行了修改和增加，所以要重新编译 linux kernel。我们先从http://www.linuxvirtualserver.org下载到LVS的内核补丁，对原有内核源代码进行更新，然后重新编译Linux的kernel。

下载LVS的内核补丁时要注意补丁版本要和kernel版本相一致，对于RH9.0，它的Linux核心版本是2.4.20，所以对应内核补丁应该是http://www.linuxvirtualserver.org/software/kernel-2.4/linux-2.4.20-ipvs-1.0.9.patch.gz

另外还有一个补丁是用来解决某些情况下ARP协议不能正常工作问题的，从http://www.ssi.bg/~ja/hidden-2.4.20pre10-1.diff下载。

把上面下载的两个补丁复制到/usr/src目录下，然后执行以下命令：

cd /usr/src
gzip -cd linux-2.4.20-ipvs-1.0.9.patch.gz
cd /usr/src/linux
patch -p1 ＜ ../linux-2.4.20-ipvs-1.0.9.patch
patch -p1 ＜ ../hidden-2.4.20pre10-1.diff

make mrproper
make menuconfig

执行make menuconfig时，我们将进入一个图形化的界面，在其中可以对Linux Kernel进行详细设置。与LVS相关的kernel选项都在“Networking options”中，进入“Networking options”，可以查看到“IP: Virtual Server Configuration”选项，将其它所有的子选项都选上：

＜M＞ virtual server support (EXPERIMENTAL)
[*] IP virtual server debugging
(12) IPVS connection table size (the Nth power of 2)
--- IPVS scheduler
＜M＞ round-robin scheduling
＜M＞ weighted round-robin scheduling
＜M＞ least-connection scheduling scheduling
＜M＞ weighted least-connection scheduling
＜M＞ locality-based least-connection scheduling
＜M＞ locality-based least-connection with replication scheduling
＜M＞ destination hashing scheduling
＜M＞ source hashing scheduling
＜M＞ shortest expected delay scheduling
＜M＞ never queue scheduling
--- IPVS application helper
＜M＞ FTP protocol helper

另外，“Networking options”中的“IP: Netfilter Configuration"中的选项的所有子项，除了以下两项不要选之外，其它全可以选：

＜ ＞ ipchains (2.2-style) support
＜ ＞ ipfwadm (2.0-style) support

还有，“Networking options”中还有一些关于网络的选项，要注意按自己的需要去选择：

＜*＞ Packet socket
[ ] Packet socket: mmapped IO
＜*＞ Netlink device emulation
[*] Network packet filtering (replaces ipchains)
[*] Network packet filtering debugging
[*] Socket Filtering
＜*＞ Unix domain sockets
[*] TCP/IP networking
[*] IP: multicasting
[*] IP: advanced router
[*] IP: policy routing
[ ] IP: use netfilter MARK value as routing key
[ ] IP: fast network address translation
＜M＞ IP: tunneling
对于kernel的其它选项，你可以根据需要进行选择。kernel的配置是一项很需要经验、细心和耐心的工作，不当的配置可能会导致编译过程中出现错误或者是新的kernel不能驱动原有的设备等问题。

退出保存，然后继续执行以下命令：

make dep
make clean
make bzImage
make modules
make modules_install

以上各步可能需要一点时间，如果出错请重新检查你的kernel配置，如果没有出现任何错误就继续执行以下命令：

depmod -a
cp arch/i386/boot/bzImage /boot/vmlinuz-lvs
cp System.map /boot/System.map-lvs

cd /boot
rm System.map
ln -s System.map-lvs System.map

然后修改你的lilo.conf使用新的kernel启动，比如在lilo.conf中以增加下几行以增加关于新的支持LVS的kernel的启动项：

image=/boot/vmlinuz-lvs
label=lvs
read-only
root=/dev/sda1

注：如果使用Grub做启动引导程序的，请自行做对应的修改，以增加关于新的支持LVS的kernel的启动项。

重新启动Linux，选择lvs项进入Linux。

安装ipvsadm

如果正常启动了，就开始安装IP虚拟服务器软件ipvsadm。因为我们用的是RH，所以我们直接下载RPM包进行安装。RPM包从以下地址下载：
http://www.linuxvirtualserver.org/software/kernel-2.4/ipvsadm-1.21-7.src.rpm

用以下命令来安装ipvsadm:

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

至此，LVS的安装算是完成了一半。就是说，现在的Linux已经具备了实现LVS的能力了，接下来的问题就是如果使用LVS来构建一组 cluster了。要想实现一组cluster，我们就要使用ipvsadm工具进行配置，而在我们开始使用ipvsadm进行配置之前，我们需要了解一些基本的LVS的知识，特别是以下三个要点：LVS的结构、LVS的三种包转发方式、LVS的八种调度算法。只有了解了这些知识以后，我们才能理该如何使用ipvsadm来进行配置。下面简单介绍LVS的这三个要点：

1. LVS的结构

LVS方式的cluster从结构上可分为两部分：前端的负载均衡器(称之为director)和后端的真实服务器(称之为real server)。cluster前端的director将来自外界的请求调度到cluster后端不同的real server去执行。real server负责真正的提供各种应用服务，比如：Web、FTP、Mail等服务。real server的数量可以根据实际需求进行增加、减少。

2. LVS的三种包转发方式

LVS提供了三种包转发方式：NAT(网络地址映射)、IP Tunneling(IP隧道)、Direct Routing(直接路由)。不同的转发模式决定了不同的cluster的网络结构，下面对三种转发方式分别介始：

NAT(网络地址映射)

NAT方式可支持任何的操作系统，以及私有网络，并且只需一个Internet IP地址，但是整个系统的性能受到限制。因为执行NAT每次需要重写包，有一定的延迟；另外，大部分应用有80%的数据是从服务器流向客户机，也就是用户的请求非常短，而服务器的回应非常大，对负载均衡器形成很大压力，成为了新的瓶颈。

IP Tunneling(IP隧道)

director分配请求到不同的real server。real server处理请求后直接回应给用户，这样director负载均衡器仅处理客户机与服务器的一半连接。IP Tunneling技术极大地提高了director的调度处理能力，同时也极大地提高了系统能容纳的最大节点数，可以超过100个节点。real server可以在任何LAN或WAN上运行，这意味着允许地理上的分布，这在灾难恢复中有重要意义。服务器必须拥有正式的IP地址用于与客户机直接通信，并且所有服务器必须支持IP隧道协议。

Direct Routing(直接路由)

与IP Tunneling类似，负载均衡器仅处理一半的连接，避免了新的性能瓶颈，同样增加了系统的可伸缩性。Direct Routing与IP Tunneling相比，没有IP封装的开销，但由于采用物理层（修改MAC地址）技术，所有服务器都必须在一个物理网段。

3. LVS的八种调度算法

LVS已实现了以下八种调度算法：

1.轮叫调度（Round-Robin Scheduling）
2.加权轮叫调度（Weighted Round-Robin Scheduling）
3.最小连接调度（Least-Connection Scheduling）
4.加权最小连接调度（Weighted Least-Connection Scheduling）
5.基于局部性的最少链接（Locality-Based Least Connections Scheduling）
6.带复制的基于局部性最少链接（Locality-Based Least Connections with Replication Scheduling）
7.目标地址散列调度（Destination Hashing Scheduling）
8.源地址散列调度（Source Hashing Scheduling）

注：如果想了解关于以上几点的技术细节，LVS的主页查询。LVS的主页是：

http://www.LinuxVirtualServer.org/
http://www.linux-vs.org/

了解了LVS的三个要点之后，接下来我们来配置一个采用Direct Routing包转发方式、加权最小连接调度算法的cluster。

我们知道Direct Routing包转发方式是通过改写请求报文的MAC地址，将请求发送到real server。前台的director机器只需要接收和调度外界的请求，而不需要负责返回这些请求的反馈结果。director机器和real server都有一块网卡连在同一物理网段上。所以我们给出以下的网络拓扑图：

director机器上需要进行如下配置：

设置好本机的IP：192.168.2.1
然后执行以下命令：
ifconfig lo:0 192.168.2.254 netmask 255.255.255.255 broadcast
192.168.2.254 up
route add -host 192.168.2.254 dev lo:0
echo 1 ＞ /proc/sys/net/ipv4/ip_forward
echo 1 ＞/proc/sys/net/ipv4/conf/all/hidden

ipvsadm -C
ipvsadm -A -t 192.168.2.254:80 -s wlc
ipvsadm -a -t 192.168.2.254:80 -r 192.168.2.2 -g
ipvsadm -a -t 192.168.2.254:80 -r 192.168.2.3 -g
......
ipvsadm -A -t 192.168.2.254:21 -s wlc
ipvsadm -a -t 192.168.2.254:21 -r 192.168.2.2 -g
ipvsadm -a -t 192.168.2.254:21 -r 192.168.2.3 -g
......

real server机器上需要进行如下配置：

对于第一台real server(RS1)，设置好本机的IP：192.168.2.2 然后执行以下命令：

ifconfig lo:0 192.168.2.254 netmask 255.255.255.255 broadcast
192.168.2.254 up
route add -host 192.168.2.254 dev lo:0

对于其它real server：RS2、RS3、RS4......，做相类的设定。

完成以上设置后，所有对192.168.2.254的80端口的访问都会通过director机器分配到后面的real server上去，而real server的处理后结果将直接反馈给客户。至此，我们完成了一个cluster的例子。通过这个例子，相信您也可以轻松地利用Linux架设起一组 cluster来。其实在cluster架设到这里之后，还并不能达到正式应用的要求，实际应用中还有一些问题需要解决，比如要安装监视软件，监视集群的运作，要能及时发现real server的故障并对应调整real server的列表。还有后台real server节点的数据一致性等问题。这些在一些商用的cluster软件产品中就得到了很好的解决，而网络也有一些非商用的软件，比如mon就是这样的系统资源监控程序，可以监控网络服务可用性、服务器问题等，最重要的是mon提供了一个框架，用户可以自行定义和扩展。这些内容请参阅其它文章。

10. 管理集群管理员交流

设置 MediaWiki
要想设置 MediaWiki，首先要指定一个驻留它的服务器。如果没有其他节点可用的话，我们常常使用管理服务器：
ssh mgmt
现在，确保安装 http 服务器、mysql 服务器和 php5。如果使用 Red Hat 5.1 或其衍生版本，那么输入： 
yum install http mysql php5 mysql-server
接下来，配置 mysql：
service mysqld start
mysql_install_db
mysqladmin -u root password 'mypasswd'
下载安装媒体 wiki：
cd /tmp/
wget http://download.wikimedia.org/mediawiki/1.13/mediawiki-1.13.0.tar.gz
tar zxvf mediawiki-1.13.0.tar.gz
mv mediawiki-1.13.0 /var/www/html/wiki
chmod a+x /var/www/html/wiki/config
完成这些步骤之后，在 Web 浏览器中访问 http://localhost/wiki。然后，只需按照菜单安装其余部分。
安装完成之后，会提示您执行命令：
cd /var/www/html/wiki
mv config/LocalSettings.php

收集系统的相关信息之后，应该把这些信息存储在某个方便的位置，让其他集群管理员可以轻松地访问。请回想一下 2000 年的情况，那时候文档大都采用 Word 或 Excel 格式，这既不酷，效率也不高。目前，生产力最高的文档共享方法是设置一个内部 wiki。这是因为懒惰的管理员不喜欢反复回答相同的问题。有了 wiki，管理员就不必这么做了，他只需说：“您自己去查看 wiki”。然后就不关他的事儿了。

每个站点都应该维护一个内部 wiki，其中应该包含所有常常被问到的集群相关信息，比如：

●系统修改的日志记录，包括在集群上执行管理操作的时间。
●集群的资产清单：固件版本、型号、序号、集群中的节点数量、处理器类型、内存。
●向厂商要求技术支持的链接和获取更新的地址。
●关于使用管理软件执行常见任务的文档。
●关于创建操作系统映像的过程的信息。
●简单地说，这个 wiki 包含的信息应该足够全面，如果有人询问关于此集群的问题，管理员只需回答 “您自己去查看 wiki”。另一方面，如果有人询问了一个 wiki 中没有涉及的问题，而您回答了他，那么您应该告诉他，作为回报他应该把您告诉他的知识添加到 wiki 中。另外，这也是对他的奖励，因为他发现了别人没有注意到的东西，这会让他在狂野的 IT 世界中获得尊敬。

为什么 wiki 比其他文档形式更好？

●wiki 是可编辑的，位于一个中心位置，可以根据需要授予用户对它的访问权。我们见过保存在共享信息库中的文档，但是要想查看这些文档，用户必须先导航到信息库，然后把文档保存到自己的硬盘上，然后再打开。效率太低了。对于 wiki，只需单击链接，这更快更简便。
●Word 文档或电子表格中的信息是静态的，修改起来比较麻烦（编辑、重新保存和发送修订后的文档）。更不用说，常常会看到同一文档的许多修订版，人们无法确定他们手里的版本是不是最新的。如果多个人编辑同一文档，就更混乱了。实际上，把文档放在 wiki 上，它们的寿命就会长得多。
设置 wiki 是极其容易的。我们使用 MediaWiki。它是免费的，很容易安装和配置。（请参见边栏）。

Wiki 的语法比 HTML 简单得多，而且网上有许多讲解如何使用 wiki 的参考资料。还有一些用来突出显示 perl 或 bash 中的代码语法的扩展。

当我们提议通过安装 wiki 帮助管理员变得更懒惰时，没有遇到过任何阻力。

11. 不断寻找更懒惰的办法

我们常常看到集群管理员总是按照自己的方式做事，这是因为他们习惯了。我们认为，这对于 Linux 集群不是好现象，这会磨灭管理员的才能，丧失进一步挖掘集群的潜力的机会。变化是很重要的，并且新的思想常常伴随变化出现。

当然，我们并不指望任何人能够研究他们遇到的每个新思想，但是是否熟悉新的趋势是区分优秀的管理员和平庸的管理员的重要标志。在这个快速变化的世界里，没人能够知晓所有东西，并且只很少一部分人精通某些东西。但是，优秀的管理员了解那些非常好的东西，乐于测试新产品，而且对于以前没听说过的东西很好奇。

因此，如果有人谈到以前没听说过的东西，懒惰的 Linux 管理员会追问下去，因为他实在太懒了，很希望找到更偷懒的方法。他还会通过搜索引擎查找相关信息。最糟糕的 Linux 集群管理员就是那些从来不提问题的。懒惰的 Linux 集群管理员不怕承认自己不知道某个东西。他对自己的本事很自信，即使他不知道某个产品，也能很快掌握它。

目前，在 Linux 集群管理领域有一些非常好的趋势。我们最感兴趣的是：

越来越多的集群向无状态计算迁移。这会使映像的管理和保持节点同步更加轻松。
从数据中心的角度看待集群。这意味着会考虑三年或更长时间内的电力、制冷和人员成本，而不仅仅考虑最初的采购成本。
从气体制冷向液体制冷发展。您知道吗？液体制冷的效率比气体制冷高 90%。
自适应式管理。按照这种管理方式，队列系统能够根据需要供应节点。这是真正的云计算，我们已经用 Moab 和 xCAT 证明了它的优越性。这是实现完全清闲 的最后一步。

结束语

如果本文达到了它的目的，那么您现在应该有了一些偷懒的好主意，应该会尝试减轻自己的工作，同时更好地控制您现有的 Linux 集群环境，还计划在下一个集群中更偷懒。我们相信本文提供的思想和实践有助于更好地使用集群，促使集群管理成为更专业的科学，帮助造就更高效的集群管理员。

问题越少，要开的会和要做的工作就越少，管理员就有更多时间玩 WoW、睡觉或做懒鬼们喜欢做的任何事情。

8. 用队列调度程序控制/管理用户

懒惰的管理员都知道，用户是所有问题的根源。因此，防止用户获得根权限是极其重要的。甚至可以这样说：您应该尽一切努力把用户挡在您的计算机之外。

队列系统就提供这样的功能：用户提交作业，队列系统决定在哪些节点上运行此作业。除了运行作业之外，用户应该完全影响不了系统。

当今流行的队列系统包括一些付费产品，比如 LSF 和 PBS Pro。许多商业客户、政府实验室和大学使用这些产品。但是，对于许多系统，一般的开放源码解决方案（比如 TORQUE 和 SLURM）就很好了。

我们喜欢结合使用 TORQUE 和 Maui 调度程序来把用户挡在集群之外（除了运行作业）。在 Linux 上，这需要先设置 /etc/security/access.conf 文件，只允许根用户登录，拒绝其他任何人。例如，如果在每个节点上运行命令：

echo "-:ALL EXCEPT root:ALL" >>/etc/security/access.conf

那么只有根用户能够登录此计算机。接下来，创建一个 TORQUE 序言脚本，它运行下面这样的命令：

perl -pi -e "s/:ALL$/ $USER:ALL/" /etc/security/access.conf

（提示：$USER 变量是在运行脚本时 TORQUE 传递给脚本的第二个变量）。因为根用户运行序言脚本，所以此用户被允许登录集群。当作业完成时，运行收尾脚本，该脚本从 /etc/security/access.conf 中删除此用户，因此他无法再登录节点：perl -pi -e "s/ $USER\b//g" /etc/security/access.conf。这会防止用户相互冲突。

我们在集群上看到的一些 “性能” 问题实际上与计算机本身无关；真正的问题是多个用户在同一台计算机上运行作业，而他们运行的作业都要求占用全部 CPU 时间。

众所周知，用户管理是必需的。但是，在排除故障时，管理员常常没有认识到用户本身正是问题的根源。我们强烈建议把用户挡在系统之外，只允许他们通过受控的环境（比如资源调度程序）进入系统。另外，我们建议集群网络本身（千兆管理或用户网络）应该与公司或校园 WAN 的其余部分分开，只允许某些用户节点提供访问点。

9. 执行基准测试！提前发现性能问题

很多人只有在集群性能急剧下降、计算结果不正确时，才会意识到危险迫在眉睫。所以要记住，在判断集群的性能时硬件诊断常常是惟一的测试方法，但是硬件诊断提供的信息可能不完整。

硬件诊断常常以厂商指定的阈值作为成功/失败的评判标准 —— 实际的阈值可能高些，也可能低些。如果硬件诊断测试失败了，那么您就遇到问题了；但是，即使没有失败，也不意味着没问题。

下面的这些问题会对系统性能产生实质性影响，但厂商无法诊断出这些问题：

●双位内存错误
●单位内存错误
●SRAM 奇偶错误
●PCI 总线错误
●数字错误
●缓存错误
●磁盘错误
●性能不一致
问题常常与硬件无关，而是与软件相关。应用程序、库、编译器、固件和操作系统的任何部分都可能是问题的根源，而硬件诊断探测不出这些问题。运行硬件诊断的运行时环境常常与应用程序的环境不一样，而且子系统承受的压力也不一样 —— 所以无法重现软件造成的问题。

显然，需要在操作环境中运行某种相应的工作负载，从而检查集群的实际工作情况。这可以通过运行几个行业认可的基准测试来完成。基准测试的目的不是要获得最好的结果，而是要获得一致的、可重复的、精确的结果（当然，这也是最好的结果）。

如何知道结果是否是最好的？集群可以划分为下面的主要子系统：

●内存
●CPU
●磁盘
●网络
●硬件厂商应该有基准测试数据，这些数据说明预期的内存、CPU (FLOPS)、磁盘和网络性能。

如何知道结果是否是一致的？

采用统计学技术。在每个节点（对于多节点测试，是节点集）上运行每个基准测试一次或多次，然后把每个节点（或节点集）的最具代表性的数据集中在一起，并进行分析。结果的分布形态比结果本身更有意义。本文中所有基准测试的经验证明，结果都应该形成正态分布。正态分布是典型的钟形曲线，这在统计学中经常出现。它是更小的独立（可能无法察觉到的）恒等分布的变量或随机事件的综合结果。

基准测试也有许多很小的独立（可能无法察觉到的）恒等分布的变量，这些变量可能会影响性能，比如：

●小的竞争进程
●上下文切换
●硬件中断
●软件中断
●内存管理
●进程/线程调度
●宇宙射线
●这些变量可能是不可避免的，但是它们是形成正态分布的原因之一。

基准测试还可能有非 恒等分布的可观察到的变量，它们也会影响性能：

●大的竞争进程
●内存配置
●BIOS 版本和设置
●处理器速度
●操作系统
●内核类型（比如 NUMA、SMP 和 UNI）和版本
●坏内存（比如过多的 ECC）
●芯片组修订
●超线程或 SMT
●不均衡的竞争进程（比如在某些节点上运行 httpd，但是在其他节点上不运行）
●共享库版本
这些变量是可避免的。可避免的不一致性可能导致多重模态分布或非正态分布，可能会对应用程序性能造成可度量的影响。

由于我们的目标是一致的、可重复的、精确的结果，所以最好先尽可能减少变量。首先进行单节点基准测试，比如 STREAM。如果所有计算机都产生相似的 STREAM 结果，那么在其他基准测试出现异常时，就可以排除内存这个因素。接下来，做处理器和磁盘基准测试，然后是两节点（并行）基准测试，再执行多节点（并行）基准测试。在完成每个更复杂的基准测试阶段之后，检查结果是否是一致的、可重复的、精确的，之后才能执行下一个测试。

下面是我们推荐的基准测试次序（报告组件性能的基准测试以粗体显示）。

●单节点（串行）基准测试：
1 STREAM（内存 MBps）
2 NPB Serial（单处理器 FLOPS 和内存）
3 NPB OpenMP（多处理器 FLOPS 和内存）
4 HPL MPI Shared Memory（多处理器 FLOPS 和内存）
5 IOzone（磁盘 MBps、内存和处理器）
●并行基准测试（只针对 MPI 系统）：
1 Ping-Pong（互连 microsec 和 MBps）
2 NAS Parallel（多节点 FLOPS、内存和互连）
3 HPL MPI Distributed Memory（多节点 FLOPS、内存和互连）
等一下，听起来要做的工作太多了！

是这样的，但是如果您希望以后清闲的话，这也是必要的。幸运的是，可以通过工具和文档简化这些工作。提前做一点儿计划，以后就能够避免许多麻烦。我们将在以后的一篇文章中讨论基准测试工具和图表；在未来的 xCAT RPM 中也会提供这些工具，这会极大地提高生产力。