- 第一篇：《如何生成每秒百万级别的 HTTP 请求？》
- 第二篇：《为最佳性能调优 Nginx》
- 第三篇：《用 LVS 搭建一个负载均衡集群》
本文是构建能够每秒处理 3 百万请求的高性能 Web 集群系列文章的第一篇。它记录了我使用负载生成器工具的一些经历，希望它能帮助每一个像我一样不得不使用这些工具的人节省时间。
负载生成器是一些生成用于测试的流量的程序。它们可以向你展示服务器在高负载的情况下的性能，以及让你能够找出服务器可能存在的问题。通过负载测试了解服务器的缺点，是测试服务器弹性以及未雨绸缪的好方法。
负载生成工具（Load-Generating Tools）
在进行负责测试时要牢记一件重要的事：你能在 Linux 上建立多少个 socket 连接。这个限制是硬编码在内核里的，最典型的就是临时 W 端口的限制。（在某种程度上）你可以在 /etc/sysctl.conf 里扩展它。但是基本上，一台 Linux 机器只能同时打开大约 64,000 个 socket 。因此在负载测试时，我们不得不通过在单一的连接上尽可能多地发出请求来充分利用 socket 。 除此之外，我们还需要不止一台的机器来产生负载。否则，负载生成器会把可用的 socket 占用导致不能产生足够的负载。
我一开始用的是‘ab’，Apache Bench 。它是我所知道的 http 基准测试工具中最简单、最通用的。并且它是 Apache 附带的产品，因此它可能已经存在于你的系统中。不幸的是，我在使用它的时候每秒大约只能生成 900 个请求。虽然我见过其他人使用它每秒能达到 2,000 个请求，但我可以立即告诉你，‘ab’并不适合我们的基准测试。
Httperf
接着，我尝试了 ‘httperf’。这个工具更强大，但是它依然相对简单并且功能有限。要算出每秒生产了多少个请求并不是仅传递参数那么简单。经过我的多次尝试，获取了每秒超过几百请求的结果。例如：
它以每秒 1,000 个的速率创建了 100,000 个会话（session）。每次会话发起 5 次请求，时间间隔为 2 秒。
|
1
|
httperf --hog --server=192.168.122.10 --wsess=100000,5,2 --rate 1000 --timeout 5
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
Total: connections 117557 requests 219121 replies 116697 test-duration 111.423 s
Connection rate: 1055.0 conn/s (0.9 ms/conn, <=1022 concurrent connections)
Connection time [ms]: min 0.3 avg 865.9 max 7912.5 median 459.5 stddev 993.1
Connection time [ms]: connect 31.1
Connection length [replies/conn]: 1.000
Request rate: 1966.6 req/s (0.5 ms/req)
Request size [B]: 91.0
Reply rate [replies/s]: min 59.4 avg 1060.3 max 1639.7 stddev 475.2 (22 samples)
Reply time [ms]: response 56.3 transfer 0.0
Reply size [B]: header 267.0 content 18.0 footer 0.0 (total 285.0)
Reply status: 1xx=0 2xx=116697 3xx=0 4xx=0 5xx=0
CPU time [s]: user 9.68 system 101.72 (user 8.7% system 91.3% total 100.0%)
Net I/O: 467.5 KB/s (3.8*10^6 bps)
|
最终，我使用这些设置达到了每秒 6,622 个连接：
|
1
|
httperf --hog --server 192.168.122.10 --num-conn 100000 --ra 20000 --timeout 5
|
（总共创建了 100,000 个连接，并且以每秒 20,000 个连接的固定速率创建）
它还有一些潜在的优势，并且拥有比‘ab‘更多的特性。但它不是我要用在这个项目里的重量级工具。我需要的是能够支持分布式多负载测试节点的工具。因此，我的下一个尝试是：Jmeter。
Apache Jmeter
这是一个功能齐全的 web 应用测试套件，它可以模拟真实用户的所有行为。你可以使用 Jmeter 的代理去访问你的网站，进行点击、登陆、模仿用户可以做的所有行为。Jemeter 会把这些行为记录下来作为测试用例。然后 Jmeter 会反复执行这些动作来模拟你想要的用户数量。尽管 Jmeter 比 ‘ab‘ 和 ’httperf‘ 复杂得多，但它是一个很有趣的工具！
根据我的测试，它每秒可以产生 14,000 个请求！这绝对是一个好的进展。
我使用了 上的一些插件，并且使用它们的“Stepping Threads”和“HTTP RAW”请求，最终每秒大约可以产生 30,000 个请求！但这已经达到极限了，所以还要寻找另一个工具。这里有一个我之前的，希望可以帮助到其他人。虽然这个配置离完美相差甚远，但有时它可以满足你的要求。
Tsung: 重型的（heavy-duty）、分布式的、多协议测试工具
它每秒基本可以产生 40,000 个请求，这绝对是我们想要的工具。类似于 Jmeter，你可以把一些行为记录下来在测试时运行，并且可以测试大多数的协议。比如 SSL、HHTP、WebDAV、SOAP、PostgreSQL、MySQL、LDAP 和 Jabber/XMPP。与 Jmeter 不同的是，它没有让人感到迷茫的 GUI 设置，它仅有一个 XML 配置文件，和一些你选择的分布式节点的 SSH 密钥。它的简洁和效率对我的吸引力，完全不亚于它的健壮性和可扩展性。我发现它是一个很强大的工具，在正确的配置下它可以每秒产生百万级的 HTTP 请求。
除此之外，Tsung 还可以在 html 上产生图表以及输入你的测试的详细报告。测试的结果通俗易懂，并且你甚至可以把这些图片展示给你的 boss 看！
在这个系列文章的剩余部分，我还会讲解这个工具。现在你可以继续浏览下面的配置说明，或者直接跳到下一页。
在 CentOS 6.2 上安装 Tsung
首先，你要安装（Erlang 需要的） EPEL 源。因此，在进行下一步之前要把它安装好。安装完后，继续安装你用来产生负载的每个节点需要的包。如果你还没有在节点之间建立无密码 SSH 密钥（passwordless SSH key），那么请建立之。
|
1
|
yum -y install erlang perl perl-RRD-Simple.noarch perl-Log-Log4perl-RRDs.noarch gnuplot perl-Template-Toolkit firefox
|
从 Github 或者 Tsung 的官网上下载最新的 Tsung。
|
1
|
wget http://tsung.erlang-projects.org/dist/tsung-1.4.2.tar.gz
|
解压并且编译。
|
1
2
3
|
tar zxfv tsung-1.4.2.tar.gz
cd tsung-1.4.2
./configure && make && make install
|
把示例配置复制到 ~/.tsung 目录里。这是 Tsung 的配置文件和日志文件的存放地方。
|
1
|
cp /usr/share/doc/tsung/examples/http_simple.xml /root/.tsung/tsung.xml
|
你可以根据你的需求去编辑这个配置文件，或者使用我的配置文件。经过大量的尝试以及失败后，我目前的配置文件在使用 7 个分布式节点时可以每秒产生 5 百万个 HTTP 请求。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
|
<?xml version="1.0"?>
<!DOCTYPE tsung SYSTEM "/usr/share/tsung/tsung-1.0.dtd">
<tsung loglevel="notice" version="1.0">
<clients>
<client host="localhost" weight="1" cpu="10" maxusers="40000">
<ip value="192.168.122.2"/>
</client>
<client host="loadnode1" weight="1" cpu="9" maxusers="40000">
<ip value="192.168.122.2"/>
</client>
<client host="loadnode2" weight="1" maxusers="40000" cpu="8">
<ip value="192.168.122.3"/>
</client>
<client host="loadnode3" weight="1" maxusers="40000" cpu="9">
<ip value="192.168.122.21"/>
</client>
<client host="loadnode4" weight="1" maxusers="40000" cpu="9">
<ip value="192.168.122.11"/>
</client>
<client host="loadnode5" weight="1" maxusers="40000" cpu="9">
<ip value="192.168.122.12"/>
</client>
<client host="loadnode6" weight="1" maxusers="40000" cpu="9">
<ip value="192.168.122.13"/>
</client>
<client host="loadnode7" weight="1" maxusers="40000" cpu="9">
<ip value="192.168.122.14"/>
</client>
</clients>
<servers>
<server host="192.168.122.10" port="80" type="tcp"/>
</servers>
<load>
<arrivalphase phase="1" duration="10" unit="minute">
<users maxnumber="15000" arrivalrate="8" unit="second"/>
</arrivalphase>
<arrivalphase phase="2" duration="10" unit="minute">
<users maxnumber="15000" arrivalrate="8" unit="second"/>
</arrivalphase>
<arrivalphase phase="3" duration="30" unit="minute">
<users maxnumber="20000" arrivalrate="3" unit="second"/>
</arrivalphase>
</load>
<sessions>
<session probability="100" name="ab" type="ts_http">
<for from="1" to="10000000" var="i">
<request> <http url="/test.txt" method="GET" version="1.1"/> </request>
</for>
</session>
</sessions>
</tsung>
|
刚开始的时候有很多东西要理解，但你一旦理解了它们后就会变得很简单。
-
只是简单地指定了运行 Tsung 的主机。你可以指定 Tsung 使用的 IP 和 CPU 的最大数。你可以使用 maxusers 设置节点能够模拟的用户数量上限。每一个用户都会执行我们之后定义的操作。 -
指定了你要测试的 HTTP 服务器。我们可以使用这个选项去测试一个 IP 集群，或者一个单一的服务器。 -
定义了我们的模拟用户将会在什么时候“到达”我们的网站。以及它们达到的有多快。 -
在持续了 10 分钟的第一个阶段里，以 每秒 8 个用户的速率到达了 15,000 个用户。 -
-
- 这里还有两个 arrivalphases，它们的用户都以同样的方式达到。
-
这些 arrivalphases 一起组成了一个
，它控制了我们可以每秒产生多少个请求。
-
-
这部分定义了一旦这些用户达到了你的网站，它们将会执行什么动作。 - probability 允许你定义用户可能会做的随机事件。有时他们可能点击这里，有时他们可能点击那里。所有的Probability 加起来一定要等于 100% 。
- 在上面的配置里，用户只做一件事，所以它的 probability 等于 100% 。
-
这就是用户在 100% 的时间里做的事情。它们循环遍历 10,000,000 次并且 一个网页：/test.txt 。 - 这个循环结构允许我们使用少量的用户连接去获取比较大的每秒请求数量。
一旦你已经很好地理解了它们，你就可以创建一个便利的别名，去快速观察 Tsung 报告。
|
1
2
|
vim ~/.bashrc
alias treport="/usr/lib/tsung/bin/tsung_stats.pl; firefox report.html"
|
|
1
|
source ~/.bashrc
|
然后启动 Tsung
|
1
2
3
|
[root@loadnode1 ~] tsung start
Starting Tsung
"Log directory is: /root/.tsung/log/20120421-1004"
|
结束后观察报告
|
1
2
|
cd /root/.tsung/log/20120421-1004
treport
|
使用 Tsung 去规划你的集群构造
现在我们拥有了一个足够强大的负载测试工具，我们可以规划余下的集群构造了：
1. 使用 Tsung 去测试一个单一的 HTTP 服务器。获取一个基本的基准。
2. 对 web 服务器进行调优，定期使用 Tsung 进行测试提高性能。
3. 对这些系统的 TCP 套接字进行调优，获取最佳的网络性能。再来一次，测试，测试，不停地测试。
4. 构造 LVS 集群，它包含了这些充分调优过的 web 服务器。
5. 使用 Tsung IP 集群对 LVS 进行压力测试。
在之后的两篇文章里，我将会向你展示如何使你的 web 服务器获取最高性能，以及怎样用 LVS 集群软件把它们整合起来。
为最佳性能调优 Nginx
http://www.hackbase.com/portal.php?mod=view&aid=822&page=1&
|
这篇文章是《 打造3百万次请求/秒的高性能服务器集群 》系列的第2部分，在这个部分中你可以使用任何一种 WEB 服务器，不过我决定使用 Nginx，因其轻量级、高可靠及高性能的优点。 通常来说，一个优化良好的 Linux 服务器可以达到 500,000 – 600,000 次/秒 的请求处理性能，然而我的 Nginx 服务器可以稳定地达到 904,000 次/秒 的处理性能，并且我以此高负载测试超过 12 小时，服务器工作稳定。 这里需要特别说明的是，本文中所有列出来的配置都是在我的测试环境验证的，而你需要根据你服务器的情况进行配置： 从 EPEL 源安装 Nginx： yum -y install nginx 备份配置文件，然后根据你的需要进行配置： cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.orig
vim /etc/nginx/nginx.conf
# This number should be, at maximum, the number of CPU cores on your system. # (since nginx doesn't benefit from more than one worker per CPU.) # 这里的数值不能超过 CPU 的总核数，因为在单个核上部署超过 1 个 Nginx 服务进程并不起到提高性能的作用。 worker_processes 24; # Number of file descriptors used for Nginx. This is set in the OS with 'ulimit -n 200000' # or using /etc/security/limits.conf # Nginx 最大可用文件描述符数量，同时需要配置操作系统的 "ulimit -n 200000"，或者在 /etc/security/limits.conf 中配置。 worker_rlimit_nofile 200000; # only log critical errors # 只记录 critical 级别的错误日志 error_log /var/log/nginx/error.log crit # Determines how many clients will be served by each worker process. # (Max clients = worker_connections * worker_processes) # "Max clients" is also limited by the number of socket connections available on the system (~64k) # 配置单个 Nginx 单个进程可服务的客户端数量，（最大值客户端数 = 单进程连接数 * 进程数 ） # 最大客户端数同时也受操作系统 socket 连接数的影响（最大 64K ） worker_connections 4000; # essential for linux, optmized to serve many clients with each thread # Linux 关键配置，允许单个线程处理多个客户端请求。 use epoll; # Accept as many connections as possible, after nginx gets notification about a new connection. # May flood worker_connections, if that option is set too low. # 允许尽可能地处理更多的连接数，如果 worker_connections 配置太低，会产生大量的无效连接请求。 multi_accept on; # Caches information about open FDs, freqently accessed files. # Changing this setting, in my environment, brought performance up from 560k req/sec, to 904k req/sec. # I recommend using some varient of these options, though not the specific values listed below. # 缓存高频操作文件的FDs（文件描述符/文件句柄） # 在我的设备环境中，通过修改以下配置，性能从 560k 请求/秒 提升到 904k 请求/秒。 # 我建议你对以下配置尝试不同的组合，而不是直接使用这几个数据。 open_file_cache max=200000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on; # Buffer log writes to speed up IO, or disable them altogether # 将日志写入高速 IO 存储设备，或者直接关闭日志。 # access_log /var/log/nginx/access.log main buffer=16k; access_log off; # Sendfile copies data between one FD and other from within the kernel. # More efficient than read() + write(), since the requires transferring data to and from the user space. # 开启 sendfile 选项，使用内核的 FD 文件传输功能，这个比在用户态用 read() + write() 的方式更加高效。 sendfile on; # Tcp_nopush causes nginx to attempt to send its HTTP response head in one packet, # instead of using partial frames. This is useful for prepending headers before calling sendfile, # or for throughput optimization. # 打开 tcp_nopush 选项，Nginux 允许将 HTTP 应答首部与数据内容在同一个报文中发出。 # 这个选项使服务器在 sendfile 时可以提前准备 HTTP 首部，能够达到优化吞吐的效果。 tcp_nopush on; # don't buffer data-sends (disable Nagle algorithm). Good for sending frequent small bursts of data in real time. # 不要缓存 data-sends （关闭 Nagle 算法），这个能够提高高频发送小数据报文的实时性。 tcp_nodelay on; # Timeout for keep-alive connections. Server will close connections after this time. # 配置连接 keep-alive 超时时间，服务器将在超时之后关闭相应的连接。 keepalive_timeout 30; # Number of requests a client can make over the keep-alive connection. This is set high for testing. # 单个客户端在 keep-alive 连接上可以发送的请求数量，在测试环境中，需要配置个比较大的值。 keepalive_requests 100000; # allow the server to close the connection after a client stops responding. Frees up socket-associated memory. # 允许服务器在客户端停止发送应答之后关闭连接，以便释放连接相应的 socket 内存开销。 reset_timedout_connection on; # send the client a "request timed out" if the body is not loaded by this time. Default 60. # 配置客户端数据请求超时时间，默认是 60 秒。 client_body_timeout 10; # If the client stops reading data, free up the stale client connection after this much time. Default 60. # 客户端数据读超时配置，客户端停止读取数据，超时时间后断开相应连接，默认是 60 秒。 send_timeout 2; # Compression. Reduces the amount of data that needs to be transferred over the network # 压缩参数配置，减少在网络上所传输的数据量。 gzip on; gzip_min_length 10240; gzip_proxied expired no-cache no-store private auth; gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml; gzip_disable "MSIE [1-6]."; 启动 Nginx 并配置起机自动加载。 service nginx start chkconfig nginx on
配置 Tsung 并启动测试，测试差不多 10 分钟左右就能测试到服务器的峰值能力，具体的时间与你的 Tsung 配置相关。 [root@loadnode1 ~] vim ~/.tsung/tsung.xml < host="YOURWEBSERVER" port="80" type="tcp"/>
tsung start
你觉得测试结果已经够了的情况下，通过 ctrl+c 退出，之后使用我们之前配置的别名命令 treport 查看测试报告。 WEB 服务器调优，第二部分：TCP 协议栈调优 这个部分不只是对 Ngiinx 适用，还可以在任何 WEB 服务器上使用。通过对内核 TCP 配置的优化可以提高服务器网络带宽。 以下配置在我的 10-Gbase-T 服务器上工作得非常完美，服务器从默认配置下的 8Gbps 带宽提升到 9.3Gbps。 当然，你的服务器上的结论可能不尽相同。 下面的配置项，我建议每次只修订其中一项，之后用网络性能测试工具 netperf、iperf 或是用我类似的测试脚本 对服务器进行多次测试。 yum -y install netperf iperf vim /etc/sysctl.conf # Increase system IP port limits to allow for more connections # 调高系统的 IP 以及端口数据**，从可以接受更多的连接 net.ipv4.ip_local_port_range = 2000 65000 net.ipv4.tcp_window_scaling = 1 # number of packets to keep in backlog before the kernel starts dropping them # 设置协议栈可以缓存的报文数阀值，超过阀值的报文将被内核丢弃 net.ipv4.tcp_max_syn_backlog = 3240000 # increase socket listen backlog # 调高 socket 侦听数阀值 net.core.somaxconn = 3240000 net.ipv4.tcp_max_tw_buckets = 1440000 # Increase TCP buffer sizes # 调大 TCP 存储大小 net.core.rmem_default = 8388608 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.ipv4.tcp_congestion_control = cubic 每次修订配置之后都需要执行以下命令使之生效. sysctl -p /etc/sysctl.conf 别忘了在配置修订之后务必要进行网络 benchmark 测试，这样可以观测到具体是哪个配置修订的优化效果最明显。通过这种有效测试方法可以为你节省大量时间。 |
用 LVS 搭建一个负载均衡集群
- 第一篇：《如何生成每秒百万级别的 HTTP 请求？》
- 第二篇：《为最佳性能调优 Nginx》
- 第三篇：《用 LVS 搭建一个负载均衡集群》
这篇文章是《打造3百万次请求/秒的高性能服务器集群》系列的第3部分，有关于性能测试工具以及优化WEB服务器部分的内容请参看以前的文章。
本文基于你已经优化好服务器以及网络协议栈的基础之上，并使用 iperf 与 netperf 工具测试将服务器已优化到支持 500,000 次/秒的静态WEB页面的性能。
现在你已经做好足够准备进行安装服务器集群。
Redhat 官网已经有一些，所以我建议你在遇到不明白的问题时查看一下这些文章。不过你先别担心，我接下会一步步地讲解群集搭建的所有操作。
LVS 路由器配置
这里需要一台设备作为路由器，它负责将 TCP 流量均衡到 LVS 集群中的每一台服务器。因此你需要拿出一台设备按以下操作进行配置。如果你的 IP 路由的流量非常小的话，你可拿一台性能最比较弱服务器做为路由器。
1.在 LVS 路由器上安装 LVS 软件
|
1
2
3
|
yum groupinstall "Load Balancer"
chkconfig piranha-gui on
chkconfig pulse on
|
2.配置 WEB 管理的密码
|
1
|
/usr/sbin/piranha-passwd
|
3.在 iptables 中配置放行端口
|
1
2
|
vim /etc/sysconfig/iptables
-A INPUT -m state --state NEW -m tcp -p tcp --dport 3636 -j ACCEPT
|
4.启动 WEB 管理
|
1
|
service piranha-gui start
|
-> 一定要等到 Piranha 配置结束之后再开启 pulse 。
5.打开报文转发
|
1
2
3
4
|
vim /etc/sysctl.conf
net.ipv4.ip_forward = 1
sysctl -p /etc/sysctl.conf
|
6.启动 WEB 服务器
|
1
|
[root@webservers ~] service nginx start
|
Direct Routing 模式配置
1.在 LVS 路由器上登录 Piranha WEB 管理界面进行配置。
在 GLOBAL SETTINGS 页中查看，默认采用是 Direct Routing 模式，我们需要通过这个页面下的功能进行配置 LVS WEB 集群服务器的虚拟 IP 地址（Virtual IP）。
2.选择 VIRTUAL SERVERS 标签页，创建虚拟 WEB 服务器， 这里的服务器就是你的 WEB 服务器集群。通过这个配置可以让你有多台服务器对外像是一台服务器，因此又被称作虚拟服务器（virtual server）。
点击 ADD，然后点 EDIT。
3.编辑虚拟服务器，首先选择一个 IP 地址作为 Virtual IP（IP 不作为真实服务器使用），然后选择一个设备接口（Device）进行绑定。
点击 ACCEPT 完成配置，这个时候 WEB 页面并不会刷新，不过此时配置已经保存完毕。
点击 REAL SERVER 进行下一步真实服务器配置。
4.配置真实服务器，REAL SERVER 页面用于配置 WEB 集群所对应的真实服务器。
用 ADD 将所有的 HTTP 服务器添加进来，然后用 EDIT 进行服务器的详细配置，之后点 ACCEPT 进行保存。
如果需要重新配置集群，先点 VIRTUAL SERVER 之后重新配置 REAL SERVER。
在 REAL SERVER 页配置完所有的真实服务器之后，依次选择每一行后点击 (DE)ACTIVATE 进行激活。
5.至此，所有的真实服务器配置并激活完毕，下接下来回到 VIRTUAL SERVERS 页
点 (DE)ACTIVATE 激活虚拟服务器。
到此为止路由器配置完毕，现在你可以关闭并退出浏览器，接下来要打开 pulse 对每台服务器进行配置。
|
1
|
service pulse start
|
输入 ipvsadm 可以看到集群已经正常启动。
|
1
2
3
4
5
6
7
8
|
[root@lvsrouter ~]# ipvsadm
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.122.10:http wlc
-> 192.168.122.1:http Route 1 0 0
-> 192.168.122.2:http Route 1 0 0
-> 192.168.122.3:http Route 1 0 0
|
Direct Routing – 配置每台真实服务器节点
在集群中的每台服务器上按以下步骤进行配置。
1.为真实服务器配置虚拟 IP 地址。
|
1
|
ip addr add 192.168.12.10 dev eth0:1
|
由于我们希望 IP 地址配置在服务器重启之后也能生效，因此需要将配置写入 /etc/rc.local 文件中。
|
1
2
|
vim /etc/rc.local
ip addr add 192.168.12.10 dev eth0:1
|
2.在真实服务器上为虚拟 IP 配置 ARP 表项。
这里要关闭所有真实服务器对虚拟 IP 地址的 ARP 请求的响应，这些服务器只响应物理 IP 地址的ARP请求，在整个集群系统中，仅有 LVS 路由器才能响应虚拟 IP 地址的ARP请求。
|
1
2
3
|
yum -y install arptables_jf
arptables -A IN -d <cluster-ip-address> -j DROP
arptables -A OUT -s <cluster-ip-address> -j mangle --mangle-ip-s <realserver-ip-address>
|
3.在真实服务器上配置完毕之后，保存 ARP 表项配置。
|
1
2
|
service arptables_jf save
chkconfig --level 2345 arptables_jf on
|
4.测试
如果 arptables 命令配置正确，只有 LVS 路由器才会应答 Ping 请求。首先确保 pulse 已关闭，之后从群集的任一真实服务器上 ping 虚拟 IP 地址，如果有真实服务器回应这个请求，你可以通过查看 ARP 表项看到它。
|
1
2
|
ping 192.168.122.10
arp | grep 192.168.122.10
|
这里可以看到解析到服务器的 MAC 地址，然后在这台服务器上关闭 ARP 响应。
还有一个简单而有效测试方法就是使用 curl 向集群请求 WEB 页面，你可以在 LVS 路由器上通过命令 ipvsadm 查看到数据流量。
|
1
2
|
[root@lvsrouter ~]# watch ipvsadm
[user@outside ~]$ curl http://192.168.122.10/test.txt
|
使用 Tsung 对集群进行性能测试
到此为此集群服务器已经配置完毕并工作正常，这时你可以通过压力测试看到它的性能是多么的强大。参考一下这篇文章对 Tsung 进行配置并生成有效的数据流对集群进行测试。
|
1
2
3
|
[root@loadnode1 ~] tsung start
Starting Tsung
"Log directory is: /root/.tsung/log/20120421-1004"
|
建议测试至少进行 2 个小时以上，因为测试需要经过比较长的时间才能看到 HTTP 的峰值请求速率。在整个测试过程中你可以在集群服务器上通过 htop 命令看到每个 CPU 核的率用率。
这里假设你已经安装好了 EPEL 和 RPMforge 源。
|
1
2
3
|
yum -y install htop cluster-ssh
cssh node1 node2 node3 ...
htop
|
你可以看到 HTTP 服务器在高速地接收并回应 WEB 请求，整个过程 LVS 路由器实际没有多少负载。
在实际使用中请确保服务器的 CPU 占所有核的总负责的平均值小于 CPU 的总核数（比如：我的 24 核系统中，我始终保持负载小于等于 23 个核的能力。），这样所有 CPU 即能够充分发挥能力，同时系统又能够具备单一失效时的冗余能力。
在 Tsung 执行结束之后，可以查看集群服务器压力测试的详细测试报告。
|
1
2
3
|
cd /root/.tsung/log/20120421-1004
/usr/lib/tsung/bin/tsung_stats.pl
firefox report.html
|
译者注：LVS 主创人为阿里云 CTO 章文嵩博士，是我朝人民长脸作之一，其在服务器群集中应用广泛，相比于 M$ 的 NLB 群集技术而言更为强大，文中的 DR 模式使用通用服务器做为流量均衡设备，性能相对较弱，在实际高性能群集应用中，通常采用具备三层 ECMP 路由硬件能力的交换机或专用负载均衡硬件设备，在不需要复杂流量均衡策略（如：基于应用的均衡）的群集中，使用交换机性价比较高。