负载均衡测试（负载均衡测试作用）

本文目录一览：

• 1、IPVS(LVS)负载均衡简介及实验测试

• 2、多台服务器负载均衡的压力测试要怎么做

• 3、网络负载均衡的验证方法

• 4、145LVS 集群负载均衡实战--LVS实战

• 5、如何验证负载均衡

• 6、负载均衡——LVS DR模式

IPVS(LVS)负载均衡简介及实验测试

LVS是Linux Virtual Server的简称，也就是Linux虚拟服务器, 是一个由章文嵩博士发起的自由软件项目，现在已经是 Linux标准内核的一部分。LVS是一种叫基于TCP/IP的负载均衡技术，转发效率极高，具有处理百万计并发连接请求的能力。

LVS的IP负载均衡技术是通过IPVS模块实现的。IPVS模块是LVS集群的核心软件模块，它安装在LVS集群作为负载均衡的主节点上，虚拟出一个IP地址和端口对外提供服务。用户通过访问这个虚拟服务（VS），然后访问请求由负载均衡器（LB）调度到后端真实服务器（RS）中，由RS实际处理用户的请求给返回响应。

根据负载均衡器转发客户端请求以及RS返回响应机制的不同，将IPVS的转发模式分为三种：VS/NAT，VS/DR，VS/TUN

DR模式下，客户端的请求包到达负载均衡器的虚拟服务IP端口后，负载均衡器不会改写请求包的IP和端口，但是会改写请求包的MAC地址为后端RS的MAC地址，然后将数据包转发；真实服务器处理请求后，响应包直接回给客户端，不再经过负载均衡器。所以DR模式的转发效率是最高的，特别适合下行流量较大的业务场景，比如请求视频等大文件。

DR模式的特点：

LB只是将数据包的MAC地址改写为RS的MAC地址，然后转发给相应的RS。

因为LB转发时并不会改写数据包的目的IP，所以RS收到的数据包的目的IP仍是LB的虚拟服务IP。为了保证RS能够正确处理该数据包，而不是丢弃，必须在RS的环回网卡上绑定LB的虚拟服务IP。这样RS会认为这个虚拟服务IP是自己的IP，自己是能够处理这个数据包的。否则RS会直接丢弃该数据包！

因为LB不会改写数据包的目的端口，所以RS服务的监听端口必须和虚拟服务端口一致，否则RS会直接拒绝该数据包。

因为RS收到的请求数据包的源IP是客户端的IP，所以理所当然RS的响应会直接回给客户端，而不会再经过LB。这时候要求RS和客户端之间的网络是可达的。

因为LB在转发过程中需要改写数据包的MAC为RS的MAC地址，所以要能够查询到RS的MAC。而要获取到RS的MAC，则需要保证二者位于一个子网，否则LB只能获取到RS网关的MAC地址。

NAT模式下，请求包和响应包都需要经过LB处理。当客户端的请求到达虚拟服务后，LB会对请求包做目的地址转换（DNAT），将请求包的目的IP改写为RS的IP。当收到RS的响应后，LB会对响应包做源地址转换（SNAT），将响应包的源IP改写为LB的IP。

NAT模式的特点：

对于请求包，会进行DNAT；对于响应包，会进行SNAT。

虽然LB在转发过程中做了NAT转换，但是因为只是做了部分地址转发，所以RS收到的请求包里是能看到客户端IP的。

因为RS收到的请求包源IP是客户端的IP，为了保证响应包在返回时能走到LB上面，所以需要将RS的默认网关地址配置为LB的虚拟服务IP地址。当然，如果客户端的IP是固定的，也可以在RS上添加明细路由指向LB的虚拟服务IP，不用改默认网关。

因为需要将RS的默认网关配置为LB的虚拟服务IP地址，所以需要保证LB和RS位于同一子网。

又因为需要保证RS的响应包能走回到LB上，则客户端不能和RS位于同一子网。否则RS直接就能获取到客户端的MAC，响应包就直接回给客户端了，不会走网关，也就走不到LB上面了。这时候由于没有LB做SNAT，客户端收到的响应包源IP是RS的IP，而客户端的请求包目的IP是LB的虚拟服务IP，这时候客户端无法识别响应包，会直接丢弃。

IP隧道（IP tunneling）是将一个IP报文封装在另一个IP报文的技术，这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技 术亦称为IP封装技术（IP encapsulation）。IP隧道主要用于移动主机和虚拟私有网络（Virtual Private Network），在其中隧道都是静态建立的，隧道一端有一个IP地址，另一端也有唯一的IP地址。

利用IP隧道技术将请求报文封装转发给后端服务器，响应报文能从后端服务器直接返回给客户。但在这里，后端服务器有一组而非一个，所以我们不可 能静态地建立一一对应的隧道，而是动态地选择一台服务器，将请求报文封装和转发给选出的服务器。这样，可以利用IP隧道的原理将一组服务器上的网络服 务组成在一个IP地址上的虚拟网络服务。各个服务器将VIP地址配置在自己的IP隧道设备上。

它的连接调度和管理与VS/NAT中的一样，只是它的报文转发方法不同。调度器根据各个服务器的负载情况， 动态地选择一台服务器，将请求报文封装在另一个IP报文中，再将封装后的IP报文转发给选出的服务器；服务器收到报文后，先将报文解封获得原来目标地址为 VIP的报文，服务器发现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。

轮叫调度（Round Robin Scheduling）算法就是以轮叫的方式依次将请求调度不同的服务器，即每次调度执行i = (i + 1) mod n，并选出第i台服务器。算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。

LB会根据RS上配置的权重，将消息按权重比分发到不同的RS上。可以给性能更好的RS节点配置更高的权重，提升集群整体的性能。

最小连接调度（Least-Connection Scheduling）算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来估计服务 器的负载情况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1；当连接中止或超时，其连接数减一。

加权最小连接调度（Weighted Least-Connection Scheduling）算法是最小连接调度的超集，各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员可以动态地设置服务器的权 值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。

基于局部性的最少链接调度（Locality-Based Least Connections Scheduling，以下简称为LBLC）算法是针对请求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群中 客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下，将相同目标IP地址的 请求调度到同一台服务器，来提高各台服务器的访问局部性和主存Cache命中率，从而整个集群系统的处理能力。

带复制的基于局部性最少链接调度（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集群系统的使用效率。

目标地址散列调度（Destination Hashing Scheduling）算法也是针对目标IP地址的负载均衡，但它是一种静态映射算法，通过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。

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

源地址散列调度（Source Hashing Scheduling）算法正好与目标地址散列调度算法相反，它根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法 的相同。它的算法流程与目标地址散列调度算法的基本相似，除了将请求的目标IP地址换成请求的源IP地址。

客户端发送对VIP的请求，lvs负载到后端某一台server，后端server处理后，直接封包回送客户端，源IP地址一定是lvs上面配的那个公网服务地址，也就后端server要配置这个ip，后端server收到的数据包是lvs没有变动过的（IP：vip），多个server，接入互联网的server持有相同的IP，是不允许的，因此，必须将后端server中的vip隐藏起来（对外隐藏，对自己可见）

VIP: 虚拟服务器地址

DIP: 转发的网络地址

1，和RIP通信：ARP协议，获取Real Server的RIP：MAC地址；

2，转发Client的数据包到RIP上，RIP上要求有VIP（对外隐藏VIP）；

RIP: 后端真实主机(后端服务器)

CIP: 客户端IP地址

对外隐藏，对内可见

kernel parameter:

目标mac地址为全F，交换机触发广播

arp_ignore: 定义接收到ARP请求时的响应级别；

0：只要本地配置的有相应地址，就给予响应；

1：仅在请求的目标(MAC)地址配置请求

到达的接口上的时候，才给予响应；

arp_announce：定义将自己地址向外通告时的通告级别；

0：将本地任何接口上的任何地址向外通告；

1：试图仅向目标网络通告与其网络匹配的地址；

2：仅向与本地接口上地址匹配的网络进行通告；

lvs 主机：192.168.56.118

RIP主机：也就是需要负载的服务器，192.168.56.101-103

LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统，后来将lvs嵌入到linux内核，叫做ipvs

ipvs参数

保存规则

-S

载入此前的规则：

-R

配置lvs的VIP

确保/proc/sys/net/ipv4/ip_forward 内容是1

调整RS的响应。通告级别（每一台RS都配）：

配置RS的VIP（每一台RS都配）

启动RS上的httpd

编写测试文件

启动httpd

客户端验证：

RIP：80 能显示

VIP：80不能显示

负载服务器安装LVS管理工具—ipvsadm

浏览器刷新: 访问vip：80

在DR模式中是所有服务机共享一个VIP，但是在IP隧道模式中，就相当于主代理机将包经过自己打包之后，将IP转化成公网可传递的IP，并将消息经过自己又一次的打包，发送给真实服务器，真实服务器对这个请求作出响应，这样就达到一个可以跨地区的传输。并且也避免了DR模式中代理机与真实服务机必须在同一局域网的不便。

说明：

1、当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。此时报文的源IP为CIP，目标IP为VIP 。

2、PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链

3、IPVS比对数据包请求的服务是否为集群服务，若是，在请求报文的首部再次封装一层IP报文，封装源IP为为DIP，目标IP为RIP。然后发至POSTROUTING链。此时源IP为DIP，目标IP为RIP

4、POSTROUTING链根据最新封装的IP报文，将数据包发至RS（因为在外层封装多了一层IP首部，所以可以理解为此时通过隧道传输）。此时源IP为DIP，目标IP为RIP

5、RS接收到报文后发现是自己的IP地址，就将报文接收下来，拆除掉最外层的IP后，会发现里面还有一层IP首部，而且目标是自己的lo接口VIP，那么此时RS开始处理此请求，处理完成之后，通过lo接口送给eth0网卡，然后向外传递。此时的源IP地址为VIP，目标IP为CIP

RIP、VIP、DIP全是公网地址

RS的网关不会也不可能指向DIP

所有的请求报文经由Director Server，但响应报文必须不能进过Director Server

不支持端口映射

RS的系统必须支持隧道

LVS服务器：192.168.56.100

RS服务器：192.168.56.101，192.168.56.102，192.168.56.103

4.4.5 ### 系统配置 vim /etc/sysctl.conf

4.5.5 ### 系统配置 vim /etc/sysctl.conf

多台服务器负载均衡的压力测试要怎么做

负载均衡是算法上的问题，按常规软件测试的方式来。

如果负载没问题，那理论上压力测试只要测单个服务就行了。

网络负载均衡的验证方法

网络负载均衡配置好后，为了实现某项具体的服务，需要在网络负载均衡的计算机上安装相应的服务。例如，为了实现IIS网站的负载均衡，需要在相应的网络负载均衡服务器上安装IIS服务。为了让每个用户在通过网络负载均衡访问到不同的计算机时，能够访问到一致的数据，需要在网络负载均衡的每台计算机上保持数据的一致性。举例来说，实现了两个节点的IIS的网络负载均衡，为了保证两个网站内容的一致性，除了这两个IIS服务器的配置相同外，相应的网站数据必须一致。

为了检验网络负载均衡，我们可以通过IIS来进行验证，其他的一些应用如终端服务、Windows Media服务与IIS的应用与之相类似。在其他计算机上的IE浏览器中键入192.168.0.9，根据网络的负载，网络负载均衡会自动转发到A机或B机。为了验证效果，你可以在浏览的时候，拔掉第一台计算机的网线或拔掉第二台机器的网线，将会发现浏览到的将是不同内容。当然，我们在测试的时候，为了验证网络负载均衡的效果，把两个网站设置成不一致的内容，而在正式应用的时候，网络负载均衡群集的每个节点计算机的内容将是一致的，这样不管使用哪一个节点响应，都能保证访问的内容是一致的。

145LVS 集群负载均衡实战--LVS实战

在本实验环境中我们没有办法为大家提供多台服务器来模拟集群环境，由此我们 docker 工具来创建多个 container 来模拟集群所需要的多台服务器。

docker 可以简单的理解为非常轻量级的虚拟机工具，而 container 则理解为创建的虚拟机。

集群系统中，服务器资源可以简单分为两种角色：

一种是 Load Balancer，即负载均衡调度器，位于集群系统的前端，对后端服务器实现负载均衡作用，对外 IP 地址也称为 VIP（虚拟 IP 地址）。

另一种就是后端服务器群，处理由 Load Balancer 发来的请求。

整个集群系统结构：

宿主机环境（默认桌面环境）：装有 ipvsadm（LVS 的 IP 负载由 IPVS 内核模块完成，ipvsadm 是为 IPVS 编制规则的工具），充当负载均衡调度器

宿主机浏览器：通过宿主机中的浏览器来充当客户端

RealServer1 的 container：部署 Nginx web 服务器，提供 Web 访问服务，充当服务器池中的一员

RealServer2 的 container：部署 Nginx web 服务器，提供 Web 访问服务，充当服务器池中的一员

我们将通过这样的一些步骤来完成此次的实验：

本地安装 ipvsadm 工具，加载 IPVS 模块

通过 docker 创建两个 container 来模拟服务器池中的成员

配置两台 RealServer 的环境：

安装 vim 与 nginx 工具

修改默认的 nginx 展示页面

配置负载均衡调度机器：

修改内核转发参数

配置 ipvsadm 规则

测试实验效果

LVS 成功测试：我们能够通过 VIP 访问我们的 Nginx 站点，经过多次的刷新我们能够访问另一个站点的内容（以显示的内容以作区分，因为负载并不高，所以需要很多次刷新，点击地址栏，按住 F5 不放）

安装 ipvsadm 工具

首先为了能够使用 IPVS 内核模块，我们将在宿主机中安装 ipvsadm，并尝试能否使用：

命令讲解：

docker run：创建 docker 容器

name 参数：给容器命名，方便区分

tid 参数：分配 tty，能够与之交互

ubuntu：指定容器镜像，这里使用 ubuntu 镜像

安装相关工具

为了区分 RealServer1 和 RealServer2 的 Nginx 响应页面，需要修改默认 nginx 的展示 html 页面。

按 i 键插入，按 esc 再输入 :wq 保存退出。

注意若完成了 RealServer1 的配置之后，如果我们不想打开新的终端，可以通过 ctrl+p+q 的组合快捷键脱离当前机器的登录，切勿使用 exit 的方式退出 container，这样的方式关闭服务器的。 脱离之后便会返回到 shiyanlou 的 zsh 交互，可以通过 docker attach RealServer2 的命令来登录另一台机器，然后做类似的操作（同上的软件安装操作以及 nginx 启动操作）

接下来就修改 nginx 页面，如下所示：

LoadBalancer 的对外 IP 地址为 VIP，即 VIP 地址为 120.26.15.9 （注意，你的 VIP 地址可能和我的不一样，根据自己实际情况来）。对内 IP 称为 RIP，此时 RIP 为 192.168.0.1。

2.开启 LoadBalancer 的内核路由转发：

3.查看当前机器内核路由转发开启情况：

得到的值为 1，说明此机器已开启内核路由转发。进行下一步。

4.使用 ipvsadm 添加 ipvs 规则。定义集群服务：

上面命中 ipvsadm 参数讲解：

以上便实现了 LVS 的 NAT 负载均衡系统。

与 NAT 方式相同，我们将通过 docker 来模拟我们的集群环境。

集群系统中，服务器资源可以简单分为两种角色：

一种是 Load Balancer，即负载均衡调度器，位于集群系统的前端，对后端服务器实现负载均衡作用，对外 IP 地址也称为 VIP（虚拟 IP 地址）。

另一种就是后端服务器群，处理由 Load Balancer 发来的请求。

整个集群系统结构：

宿主机环境（默认桌面环境）：充当客户端访问 web 服务

LoadBalancer1 的 container：装有 ipvsadm，充当负载均衡调度器

RealServer1 的 container：部署 Nginx web 服务器，提供 Web 访问服务，充当服务器池中的一员

RealServer2 的 container：部署 Nginx web 服务器，提供 Web 访问服务，充当服务器池中的一员

我们将通过这样的一些步骤来完成此次的实验：

本地安装 ipvsadm 工具，加载 IPVS 模块

通过 docker 创建三个 container 来模拟服务器池中的成员

配置两台 RealServer 的环境：

安装 vim 与 nginx 工具

修改默认的 nginx 展示页面

修改内核参数，抑制 arp

创建网卡别名与添加路由

配置一台 LoadBalancer 环境：

安装 ipvsadm

配置网卡别名

配置 ipvsadm 规则

测试实验效果

LVS 成功测试：我们能够通过 VIP 访问我们的 Nginx 站点，经过多次的刷新我们能够访问另一个站点的内容（以显示的内容以作区分，因为负载并不高，所以需要很多次刷新，点击地址栏，按住 F5 不放）

查看 ipvsadm 中的统计数据。

若是我们沿用 NAT 的实验环境，我们需要做环境的清理：

1.首先清除 ipvsadm 的规则：

2.删除之前所创建的 container，虽然都是提供 Web 服务，但是在 DR 模式中需要修改内核参数与创建网卡别名，需要超级权限，所以不能沿用之前的 container：

安装 ipvsadm 工具

因为在 NAT 实验中我们已安装所以可跳过该步骤，若是新启动的环境请参考 NAT 中的步骤，此处提示务必在宿主机环境中执行 ipvsadm -L 的验证步骤，若是不执行该步骤，在 LoadBalancer 的 container 中我们将无法加载 IPVS 的内核模块。

创建与配置服务器池成员

同样我们使用 docker 来模拟我们的集群环境，创建三台 container：

其中 --privileged 参数用于给予容器超级权限。

完成我们服务器池成员的创建之后，我们参照 NAT 中配置步骤完成 RealServer 中的：

nginx 与 vim 的安装

默认展示页面的修改

nginx 服务的启动

在完成这样的配置之后我们需要一些额外的操作：

1.修改内核参数

以 RealServer1 为例，登录 container：

执行下列命令：

ARP 的内核参数： arp_ignore 部分参数：定义了本机响应 ARP 请求的级别

0 表示目标 IP 是本机的，则响应 ARP 请求。默认为 0

1 如果接收 ARP 请求的网卡 IP 和目标 IP 相同，则响应 ARP 请求

arp_announce 参数：定义了发送 ARP 请求时，源 IP 应该填什么。

0 表示使用任一网络接口上配置的本地 IP 地址，通常就是待发送的 IP 数据包的源 IP 地址 。默认为 0

1 尽量避免使用不属于该网络接口(即发送数据包的网络接口)子网的本地地址作为 ARP 请求的源 IP 地址。大致的意思是如果主机包含多个子网，而 IP 数据包的源 IP 地址属于其中一个子网，虽然该 IP 地址不属于本网口的子网，但是也可以作为ARP 请求数据包的发送方 IP。

2 表示忽略 IP 数据包的源 IP 地址，总是选择网络接口所配置的最合适的 IP 地址作为 ARP 请求数据包的源 IP 地址(一般适用于一个网口配置了多个 IP 地址)

2.配置网卡别名

只有目的 IP 是本机器中的一员时才会做相应的处理，所以需要添加网卡别名：

同两台 Web 服务器中都做该配置，即完成了所有 Web 服务器所需的配置工作。

** 配置调度器规则**

紧接着我们登录 LoadBalancer 机器：

安装 ipvsadm 软件：

创建 eth0 的别名并绑定 VIP 地址，作为集群同时使用：

查看网卡信息：ifconfig

在 LoadBalancer 中添加 IPVS 规则：

ipvsadm 命令参数讲解：

以上操作就实现了 LVS/DR 模式，实现集群系统的负载均衡。

如何验证负载均衡

如果您将硬件负载平衡器作为 Communicator Web Access（2007 R2 发行版）基础结构的一部分进行部署，则应该运行一系列的测试来验证负载平衡器是否正确配置并按预期的方式工作。建议您至少进行以下验证：

确认每台 Communicator Web Access 服务器都可以与网络上的其他计算机通信，并且可以连接到 Active Directory。

确认负载平衡器能够均匀分配传入连接。

确认标准 Communicator Web Access 活动（如即时消息和状态检测）按预期的方式运行。

验证 DNS 和 LDAP 流量

只有当 Communicator Web Access 服务器阵列中的各台服务器都能执行以下两项操作时，负载平衡才能工作：

解析 IP 地址和计算机主机名。

与 Active Directory 全局编录服务器通信。

为此，您应该执行的第一项测试是验证轻型目录访问协议 (LDAP) 和域名系统 (DNS) 连接；此项测试必须在服务器阵列中的每台服务器上执行。在测试的第一部分，您将通过 IP 地址（例如，192.168.1.5）对全局编录服务器执行 ping 操作。要成功完成测试，必须得到如下响应：

Pinging 192.168.1.5 with 32 bytes of data: Reply from 192.168.1.5:bytes=32 time1ms TTL=128 Reply from 192.168.1.5:bytes=32 time1ms TTL=128 Reply from 192.168.1.5:bytes=32 time1ms TTL=128 Reply from 192.168.1.5:bytes=32 time1ms TTL=128 Ping statistics for 192.168.1.5: Packets:Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms

如果这一部分测试成功完成，下一步您将通过名称对全局编录服务器执行 ping 操作。对于测试的第二部分，您应该得到如下响应：

Pinging gcserver.contoso.com [192.168.1.5] with 32 bytes of data: Reply from 192.168.1.5:bytes=32 time1ms TTL=128 Reply from 192.168.1.5:bytes=32 time1ms TTL=128 Reply from 192.168.1.5:bytes=32 time1ms TTL=128 Reply from 192.168.1.5:bytes=32 time1ms TTL=128 Ping statistics for 192.168.1.5: Packets:Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms

通过以上两部分测试验证 DNS 流量后，下一步应该使用 Ldp.exe 实用程序验证与 Active Directory 的 LDAP 连接。

验证负载平衡器配置

负载平衡器的主要用途是确保工作负载在服务器阵列中的所有服务器之间均匀分配。例如，假设您的服务器阵列中有四台服务器，有 100 个用户登录到 Communicator Web Access。如果您已经采用硬件负载平衡并且负载平衡已经配置正确，则每台服务器应该处理 25 个会话（总共 100 个会话，除以 4 台服务器）。

要验证负载平衡配置，应进行一系列测试，每次测试通过两个用户帐户（用户 A 和用户 B）和最多两台 Communicator Web Access 服务器进行。（因为如果使用两台以上的服务器，那么您可能遇到的问题的根源就更加难以追踪。）如果服务器阵列中有两台以上的服务器，应该在每个可能的计算机对上重复测试过程。例如，假设服务器阵列由以下计算机组成：

服务器 A

服务器 B

服务器 C

服务器 D

在这种情况下，您需要运行的测试涉及以下计算机对：

负载均衡——LVS DR模式

相比于nginx只能用于7层负载均衡，LVS就比较强大了，能在4层做负载均衡。而且性能和稳定性上LVS也比较占优，毕竟是合入内核模块，不稳定肯定不行。

LVS通过工作于内核的ipvs模块来实现功能，其主要工作于netfilter的INPUT链上。除此之外，还需要一个用户态工具，ipvdadm，用于用户负载集群定义和集群服务管理。

LVS DR模式的流程大概如下：

1、客户端发送请求至VIP，也就是访问服务，请求报文源地址是CIP，目标地址为VIP；

2、LVS调度器接收到请求，报文在PREROUTING链检查，确定目的IP是本机，于是将报文发送至INPUT链，ipvs内核模块确定请求的服务是我们配置的LVS集群服务，然后根据用户设定的均衡策略选择某台后端RS，并将目标MAC地址修改RIP的MAC地址。因为调度器和后端服务器RS在同个网段，因此直接二层互通，将请求发给选择的RS处理；

3、因为报文目的mac是本机，且RS上有配置VIP，因此RS能接收该报文。后端服务处理完请求后，将响应直接发往客户端，此时源IP地址为VIP，目标IP为CIP。

如下，准备三台服务器，

机器 作用

192.168.0.100 VIP，LVS调度器对外服务IP

192.168.0.200 RIP，后端web服务器之一

192.168.0.300 RIP，后端web服务器之二

上面我们说过lvs依赖于ipvs内核模块，和ipvsadm用户态工具。因为centos 7已经默认加载ipvs模块，因此这一步我们不需要配置。我们只需要安装ipvsadm工具即可，

yum install -y ipvsadm

然后在LVS调度器上配置VIP，这里我们采用虚拟网卡，当然也可以使用独立网卡配置，

ifconfig eth0:0 192.168.0.100/24 up

接着配置LVS集群服务，

[root@CentOS-7-2 ~]# ipvsadm -C

[root@CentOS-7-2 ~]# ipvsadm -A -t 192.168.0.100:80 -s rr

[root@CentOS-7-2 ~]# ipvsadm -a -t 192.168.0.100:80 -r 192.168.0.200:80 -g

[root@CentOS-7-2 ~]# ipvsadm -a -t 192.168.0.100:80 -r 192.168.0.300:80 -g

其中，

第一条命令是清空所有规则；

第二条命令是定义LVS服务，并指定负责均衡策略为rr，即轮询；

第三、四条命令各添加一台后端web服务器，作为负载均衡节点，并指定为DR模式。

ipvsadm基本命令参数如下：

-A  指定添加的LVS负载均衡虚拟服务

-t  指定虚拟服务器的IP地址和端口

-s  指定调度算法，ss为轮询，wrr为加权轮询，dh为目标地址散列，sh为源地址散列，lc为最少链接等

-a  在对应的VIP下添加RS节点

-g  指定LVS的工作模式为DR模式

-l  指定LVS的工作模式为tunnel模式

-m  指定LVS的工作模式为NAT模式

添加完后端RS，我们可以查看此LVS对应的均衡规则，

[root@CentOS-7-2 ~]# ipvsadm -Ln

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Scheduler Flags

  - RemoteAddress:Port          Forward Weight ActiveConn InActConn

TCP  192.168.0.100:80 rr

  - 192.168.0.200:80            Route  1      0          0       

  - 192.168.0.300:80            Route  1      0          0

这里web服务器使用nginx搭建，因此在两台RS上安装nginx，

yum install -y nginx

同时为了后面测试，我们修改web服务器的index.html内容，

[root@192_168_0_200 ~]# cat /usr/share/nginx/html/index.html

This is 192.168.0.200

[root@192_168_0_300 ~]# cat /usr/share/nginx/html/index.html

This is 192.168.0.300

接着开始进行LVS相关配置，

首先将VIP配置在lo接口上，(注意掩码要配置成32位，不然RS通信会出问题)

ifconfig lo:0 192.168.0.100/32 up

接着配置对应路由，

route add -host 192.168.0.100 dev lo

然后设置相关系统参数，

echo 1 /proc/sys/net/ipv4/conf/eth0/arp_ignore

echo 2 /proc/sys/net/ipv4/conf/eth0/arp_announce

echo 1 /proc/sys/net/ipv4/conf/all/arp_ignore

echo 2 /proc/sys/net/ipv4/conf/all/arp_announce

其实严格意义上只要配置出口网卡的对应参数就可以了，配置all也只是为了保险而已，文章最后面会有说明。

使用curl命令对vip进行访问，

[root@CentOS-7-3 /home]# curl 

This is 192.168.0.200

[root@CentOS-7-3 /home]# curl 

This is 192.168.0.300

[root@CentOS-7-3 /home]# curl 

This is 192.168.0.200

[root@CentOS-7-3 /home]# curl 

This is 192.168.0.300

可见结果符合我们设置的轮询策略。

因为当调度器把请求转发给对应RS时，并没有修改报文目的IP，因此请求报文目的IP仍为VIP，所以如果RS没有配置VIP，那么报文到达RS后就会被丢弃。

arp_ignore=1:只响应目的IP地址为接收网卡上的本地地址的arp请求

因为我们在RS上都配置了VIP，因此此时是存在IP冲突的，当外部客户端向VIP发起请求时，会先发送arp请求，此时调度器和RS都会响应这个请求。如果某个RS响应了这个请求，则之后该客户端的请求就都发往该RS，并没有经过LVS，因此也就没有真正的负载均衡，LVS也就没有存在的意义。因此我们需要设置RS不响应对VIP的arp请求，这样外部客户端的所有对VIP的arp请求才会都解析到调度器上，然后经由LVS的调度器发往各个RS。

系统默认arp_ignore=0，表示响应任意网卡上接收到的对本机IP地址的arp请求(包括环回网卡上的地址)，而不管该目的IP是否在接收网卡上。也就是说，如果机器上有两个网卡设备A和B，即使在A网卡上收到对B IP的arp请求，也会回应。而arp_ignore设置成1，则不会对B IP的arp请求进行回应。由于lo肯定不会对外通信，所以如果只有一个对外网口，其实只要设置这个对外网口即可，不过为了保险，很多时候都对all也进行设置。

arp_announce=2:网卡在发送arp请求时使用出口网卡IP作为源IP

当RS处理完请求，想要将响应发回给客户端，此时想要获取目的IP对应的目的MAC地址，那么就要发送arp请求。arp请求的目的IP就是想要获取MAC地址的IP，那arp请求的源IP呢？自然而然想到的是响应报文的源IP地址，但也不是一定是这样，arp请求的源IP是可以选择的，而arp_announce的作用正是控制这个地址如何选择。系统默认arp_announce=0，也就是源ip可以随意选择。这就会导致一个问题，如果发送arp请求时使用的是其他网口的IP，达到网络后，其他机器接收到这个请求就会更新这个IP的mac地址，而实际上并不该更新，因此为了避免arp表的混乱，我们需要将arp请求的源ip限制为出口网卡ip，因此需要设置arp_announce=2。

由上可知，只要RS上的VIP不响应arp请求就可以了，因此不一定要配置在lo上，也可以配置在其他网口。由于lo设备不会直接接收外部请求，因此只要设置机器上的出口网卡不响应非本网卡上的arp请求接口。但是如果VIP配置在其他网口上，除了上面的配置，还需要配置该网口不响应任何arp请求，也就是arp_ignore要设置为8。

这是由于lo设备的特殊性导致， 如果lo绑定192.168.0.200/24，则该设备会响应该网段所有IP(192.168.0.1~192.168.0.254) 的请求，而不是只响应192.168.0.200这一个地址。

根据DR模式的原理，调度器只修改请求报文的目的mac，也就是转发是在二层进行，因此调度器和RS需要在同一个网段，从而ip_forward也不需要开启。