如何运用lr工具对linux服务器做负载均衡测试

LVS的全称Linux vitual system,

LVS工作在一台server上提供Directory(负载均衡器)的功能，本身并不提供服务，只是把特定的请求转发给对应的realserver(真正提供服务的主机)，从而实现集群环境中的负载均衡。

LVS的核心组件ipvs工作在kernel中，是真正的用于实现根据定义的集群转发规则把客户端的请求转发到特定的realserver。而另一个组件ipvsadm是工作在用户空间的一个让用户定义ipvs规则的工具。故我们只要在server上装了ipvsadm软件包就可以定义ipvs规则，而在linux kernel的2.6版本之后kernel是直接支持ipvs的。

lvs 三种模型 （NAT DR TUN）

NAT 的架构的特点

工作原理：基于NAT机制实现。当用户请求到达director之后，director将请求报文的目标地址（即VIP）改成选定的realserver地址，同时将报文的目标端口也改成选定的realserver的相应端口，最后将报文请求发送到指定的realserver。在服务器端得到数据后，realserver将数据返给director，而director将报文的源地址和源端口改成VIP和相应端口，然后把数据发送给用户，完成整个负载调度过程。

特点：

1，所有的realserver和director要在同一个网段内

2，RIP是私有地址，仅用于集群节点之间进行通信

3，director同时处理请求和应答数据包

4，realserver的网关要指向DIP

5，可以实现端口映射

6，readlserver可以是任意 *** 作系统

7，director很可能成为系统性能瓶颈

TUN架构的优缺点

工作原理：这种方法通过ip隧道技术实现虚拟服务器。当用户请求到达director之后，director将请求报文的目标地址（即VIP）改成选定的realserver地址.然后，调度器采用ip隧道技术将用户请求发送到某个realserver，而这个realserver将直接相应用户的请求，不再经过director。此外，对realserver的地域位置没有要求。和director在不在同一网段都可以。

特点：

1，realserver和director可以不在一个物理网络中，可以跨越互联网

2，RIP一定不能是私有地址（因为要用到隧道传输）

3，director仅处理入站请求

4，realserver的网关不能指向DIP

5，不支持端口映射

6，支持ip隧道功能的 *** 作系统才能作为realserver

DR架构的优缺点（生产环境用的最多）

工作原理：基于直接路由来实现。当用户请求到达director之后，director将请求报文的目标地址（即VIP）改成选定的realserver地址，还要改写请求报文的mac地址，将请求发送到指定mac的realserver，而realserver将响应直接返回给客户端，不经过director。这个方式是三种调度中性能最好的，也是我们生产环境中使用最多的。

特点：

1，集群节点和director必须在一个物理网络内

2，RIP可以使用公网地址或私有地址

3，director仅处理入站请求

4，集群节点网关不指向director，故出站不经过director

5，不支持端口映射

6，大多数 *** 作系统可以作为realserver，要支持隔离arp广播

7，director服务器的压力比较小

1 准备工作

首先,监视Linux一定要有rstatd这个守护进程,有的Linux版本里也有可能是rpc.rstatd这里只是名字不同而已,功能是一样的

一般来说LINUX需要下载一个包才有这个服务,包名字是rpc.rstatd-4.0.1.tar.gz. 这是一个源码,需要编译,

下载并安装rstatd

tar -ivh rpc.rstatd-4.0.1.tar.gz

./configure —配置

make —编译

make install —安装

rpc.rstatd —启动rstatd进程

配置rstatd 目标守护进程是xinetd,它的主配置文件是/etc/xinetd.conf 里面内容是

只有基本信息

# Simple configuration file for xinetd

#

# Some defaults, and include /etc/xinetd.d/

defaults

{

instances = 60

log_type = SYSLOG authpriv

log_on_success = HOST PID

log_on_failure = HOST

cps = 25 30

}

includedir /etc/xinetd.d

里面内容的意思在这里就不说了!网上有具体解释,

我们这里需要修改的是/etc/xinetd.d/下的三个conf文件 rlogin ,rsh,rexec 这三个配置文件,

打这三个文件里的disable = yes都改成 disable = no ( disabled 用在默认的 {} 中 禁止服务)

或是把# default: off都设置成 on 这个的意思就是在xinetd启动的时候默认都启动上面的三个服务!

(由于貌似用ps ax不能看到rlogin ,rsh ,rexec这三个进程是否开启,所以使用default: on,因为rstatd和xinetd这二个服务是否启动在ps ax里是看的到的)

然后你在保证Linux机器上的进程里有rstatd和xinetd这二个服务就可以用LR去监视了

几点小的技巧:

检查是否启动: rsh server 监听和TCP 是514。

# netstat -an |grep 514

tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN

如果能看到514在监听说明rsh服务器已经启动。

检查是否启动: rstatd

输入命令: rpcinfo -p

如果能看到

程序 版本 协议 端口

*** **** udp 741 rstatd

Average load：

Average number of processes simultaneously in Ready state during the last minute

上一分钟同时处于“就绪”状态的平均进程数

Collision rate

Collisions per second detected on the Ethernet

每秒钟在以太网上检测到的冲突数。

Context switches rate

Number of switches between processes or threads, per second

每秒钟在进程或线程之间的切换次数。

CPU utilization

Percent of time that the CPU is utilized

CPU 的使用时间百分比。

Disk rate

Rate of disk transfers

磁盘传输速率。

Incoming packets error rate

Errors per second while receiving Ethernet packets

接收以太网数据包时每秒钟接收到的错误数。

Incoming packets rate

Incoming Ethernet packets per second

每秒钟传入的以太网数据包数。

Interrupt rate

Number of device interrupts per second

每秒内的设备中断数。

Outgoing packets errors rate

Errors per second while sending Ethernet packets

发送以太网数据包时每秒钟发送的错误数。

Outgoing packets rate

Outgoing Ethernet packets per second

每秒钟传出的以太网数据包数。

Page-in rate

Number of pages read to physical memory, per second

指标表明的是每秒交换到物理内存中的页面数。

Page-out rate

Number of pages written to pagefile(s) and removed from physical memory, per second

表示每秒从物理内存中移出或者写入到页面数。

Paging rate

Number of pages read to physical memory or written to pagefile(s), per second

每秒钟读入物理内存或写入页面文件中的页数。

Swap-in rate

Number of processes being swapped

每秒交换到内存的进程数。

Swap-out rate

Number of processes being swapped

每秒从内存交换出来的进程数。

System mode CPU utilization

Percent of time that the CPU is utilized in system mode

在系统模式下使用 CPU 的时间百分比。

User mode CPU utilization

Percent of time CPU is utilized in user mode

在用户模式下使用 CPU 的时间百分比。

一些常见的问题及处理方法：

1、在执行配置或安装命令过程中出现“拒绝的权限”的提示？

答：是由于文件的权限引起的，应该给当前用户所有文件的“777”权限，即完全控制权限。

2、安装好后从LoadRunner中看不到信息，但是没有报错？

答：可能是返回的信息值比较小，所以在图中几乎看不到，例如：如果没有运行程序的话，CPU的使用率接近于0，所以在监视图中看不到变化。也有可能是采样的频率过大，可以在图表中设置没1 秒获取一次信息，这样界面就刷新的比较及时了。

3、监视一段时间后LoadRunner中提示有错误发生不能继续监视到信息？

答：可能是由于CPU长时间处于高负荷状态，而导致系统自动关闭了该服务。可以在LoadRunner中重新加一次计数器，并且设置取样的时间稍长一点，就会避免这种情况。

4、以前用LoadRunner监视都是成功的，但是再次监视不到信息？

答：有可能是由于系统重新启动，而没有打开rstatd守护进程。可以手工重新打开一次，使用命令“rpc.rstatd”，另外可以使用“rpcinfo -p”命令来查看当前系统是否已经启动了rstatd守护进程。

5、使用LR监视Linux窗口，经常丢失？

这是你图形显示时间设置问题，跟lr稳定不稳定没关系，具体设置如下：

1.运行Controller

2.在"Unix Resources"图形窗口中，点击右键，选择Configure选项

3.随后d出“Graph Configuration”窗口，在该窗口有一个选项“Graph Time(sec)”，默认显示是60秒

这里共有4个选项：60秒，180秒，600秒，3600秒，whole scenario（整个场景运行都显示图形数据）

注：如果按照你疲劳测试动则十几小时的情况来看，应该选择whole scenario（整个场景运行都显示图形数据）

1.具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

2.查找瓶颈时按以下顺序，由易到难。

服务器硬件瓶颈 �8�1 网络瓶颈（对局域网，可以不考虑）�8�1 服务器 *** 作系统瓶颈（参数配置）�8�1 中间件瓶颈（参数配置，数据库，web服务器等）�8�1 应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）

分析的信息来源：

1 根据场景运行过程中的错误提示信息

2 根据测试结果收集到的监控指标数据

颜色比例度量图最小值平均值图最大值图中间值图SD

1Throughput1257502.7951375591.3721525865.0471372743.69149130.473

同样，从图中可以看出，在4个小时的时候，web服务器的吞吐量开始增高。在图中还可以看到吞吐量的走势图，从开始到进行到4个小时反d之前呈降低的趋势，这是因为系统在初期调用的资源都是直接来之服务器，运行一段时间后系统的部分资源来自缓存。

6．下载组件大小

每个页面的组件大小，且包括组件的标头的大小！

页面组件大小的分析表格比较复杂，实际分析中可以通过loadrunner的报告分析工具来分析。页面组件大小分析主要是找到页面中比较庞大的组件，如果其影响到了页面的下载速度，则要想办法将其改小！

7．Apache资源

显示APACHE web服务器上的资源摘要。前面已经提到过以并发点击数为主。

颜色比例度量最小值平均值最大值SD

100Apache CPU 使用情况(Apache):172.17.7.2100.7770.8520.930.043

0.01已发送 KB/秒(Apache):172.17.7.21061430.3712689.333327.924

0.1点击次数/秒(Apache):172.17.7.2100.333114.352533.66740.201

三．服务器资源监控指标：

（目前通过top监察）

内存：

Linux资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

实际测试中，当并发点击数出现突然剧增前后，内存的PR 值则居高25不下。说明目前测试的系统中内存存在瓶颈！

内存资源成为系统性能的瓶颈的征兆:

很高的换页率(high pageout rate)

进程进入不活动状态

交换区所有磁盘的活动次数可高

可高的全局系统CPU利用率

内存不够出错(out of memory errors)

处理器：

Linux资源监控中指标CPU占用率持续超过80%（对该值的要求，根据具体应用和机器配置而要求不同，有资料表明95％），表明瓶颈是CPU。

实际测试中，当并发点技数出现突然增加前后，cpu的占用率持续保持在86％以上！

说明，目前系统用应用的cpu也是测试的瓶颈！

CPU资源成为系统性能的瓶颈的征兆:

很慢的响应时间(slow response time)

CPU空闲时间为零(zero percent idle CPU)

过高的用户占用CPU时间(high percent user CPU)

过高的系统占用CPU时间(high percent system CPU)

长时间的有很长的运行进程队列(large run queue size sustained over time)

四．数据库服务器：

数据库服务器目前测试观察，当web服务器点击率增大时，观察mysql数据库的最大连接数，仍未超过系统设置的最大连接数。所以，暂时未发现数据库的瓶颈！

五．结论

以上报告分析中的数据、图标均来自同一次测试。是在平时测试中挑出的一次现象比较明显，比较利于观察的作为分析案例。

根据以上综合分析，当前测试环境下，当应用系统产生最大533.667的并发压力。平均负载压力114.352。根据分析，用户在4个小时的时候，并发数迅速增加前后的值在400左右！分析结果跟实际测试的硬件环境以及测试脚本有一定关系。同时，测试服务器的硬件配置和实际服务器的配置还有一定的差距！

---