Keepalived+lvs 搭建高可用负载均衡

本站点停止更新，请访问:blog.coocap.com

不了解负载均衡高可用的童鞋，强烈建议先看keepalived+nginx高可用负载均衡：

传送门（求粉）：http://www.cnblogs.com/mrlinfeng/p/6146866.html

lvs不过多介绍，能看到这里的应该都了解了。

先介绍环境和各个服务器角色：

这里统一使用的是linux centOS6.5 32位系统，内核版本：2.6.32-431.el6.i686
lvs服务器称为DirectorServer，简称DS，主机为DS-Master，ip为192.168.200.129，备机为DS-Slave，ip为192.168.200.130


后端真实服务器称为RealServer，简称RS，各有一台tomcat web服务器,ip为192.168.200.128,192.168.200.131


虚拟IP（Virtual IP 简称VIP）为192.168.200.88

最终架构图：

ok，现在开始干活。

---

搭建RS环境

这个太简单，没压力，搞两个linux虚拟机嘛，然后装java嘛，然后上传tomcat解压嘛，搞一个web项目jsp页面嘛，发布访问如下即可：

当然，还有一个131的一样，不说了

---

搭建DS环境

1. 首先两台DS需要安装LVS，包括两部分，IPVS模块和IPVSadm管理模块。

2. IPVS模块在linux内核2.6及以上已经有了不需要安装，查看linux内核版本的命令是：uname -a

   
   
   如果你的linux版本在2.6以上，那么是已经安装IPVS的，如果不是2.6版本以上的，那就自己安装吧，当然建议是安装更新的linux了，因为我不知道怎么安装IPVS模块。。。。。
   
   通过这个命令可以查看IPVS是否安装：modprobe -l | grep ipvs
   
   如图，说明是有IPVS模块的
   
   

3. 安装IPVSadm管理模块，使用yum命令：yum -y install ipvsadm
   
   安装完后使用--help命令检查是否安装成功：ipvsadm --help
   
   出现如下图一大波的各种用法及说明安装成功
   
   

4. 安装完lvs之后，两台DS安装keepalived（这个在文章开头传送门处的教程中有详细keepalived安装方法）
   
   下载以下两个rpm包，区分32位64位，64位的去下载64位的包
   
   keepalived-1.2.13-5.el6_6.i686.rpm
   
   openssl-1.0.1e-30.el6.8.i686.rpm
   
   注意：openssl包要求必须是openssl-1.0.1e或以上才行
   
   将rpm包上传到两台DS，进入上传的目录，然后运行以下命令安装
   
   rpm –Uvh --nodeps ./openssl-1.0.1e-30.el6.8.i686.rpm

rpm –Uvh --nodeps ./keepalived-1.2.13-5.el6_6.i686.rpm
   
   安装完毕，在/etc/keepalived/目录下有个文件 keepalived.conf即是本台服务器keepalived的核心配置文件了：

5. 配置keepalived
   
   这里需要配置DS-Master的keepalived.conf和DS-Slave的keepalived.conf
   
   编辑器里不好贴配置文件，在keepalived配置文件夹中有两个配置并有说明。
   
   截个图吧:
   
   这是DS-Master配置（看配置说明）：

   
   

   ---

   这是DS-Slave配置，基本一样，红色圈出部分不一样：

   
   

6. 配置完成keepalived之后检查：
   
   启动两台keepalived，启动keepalived服务命令：keepalived service start
   
   查看绑定虚拟IP：ip addr
   
   如图所示，主机eth0网卡绑定VIP192.168.200.88，此时备机没有绑定，假设主机停止keepalived，那么备机就会马上绑定VIP，自行验证即可
   
   
   
   至此，我们keepalived搭建完成，DS环境搭建完毕。

---

配置RS

在两台RS上选择一个目录（我是在/sbin/），创建脚本realserver.sh如下（两台一样），注意红色圈出处修改为自己的VIP：

当然，创建完后记得给执行权限：chmod a+x /sbin/realserver.sh

然后，运行两台RS的tomcat，并且执行两台RS的realserver.sh脚本:/sbin/realserver.sh start

现在访问VIP即可访问到项目了。

---

测试

1. 高可用的测试
   
   停止DS-Master即主机lvs的keepalived服务，可以看到VIP会绑定在备机上，然后启动主机keepalived服务，VIP又会绑回到主机上，这个测试简单，自己测一下即可。

2. 负载均衡测试
   
   玩过nginx的都知道，如果是使用其默认的轮询机制的话，刷新一下页面，就会变换一下被轮询的RS服务器，即刷新页面会在128和131之间来回切换，但是lvs不会，他会在一定时间内进行切换。这里我也是郁闷了很久。一开始我以为是配置文件中persistence_timeout这个参数的原因，当然这里设置的话确实会影响，他会保证在一定时间内同一IP的连接被分配到同一台RS上，但是我注释之后还是在一定时间内在一台服务器上。这可能是lvs自己的机制吧，也没有找到原因。
   
   这里测试负载均衡的话我是用了一个测试工具：apache-jmeter
   
   运行bin目录下的jmeter.bat，然后简述一下测试过程，我也是现学了一下，模拟测试一下web访问。

   jmeter界面如下，新建一个线程组
   

   然后线程数输入个100，循环次数输入个100，这应该是模拟100并发访问，且永远循环一直访问（当然tomcat会受不了内存溢出的，这里是为了说明lvs能把所有请求都轮询到两个tomcat上，所以请无视，或者可以线程数为100，循环次数为2，请求间隔设置长一点时间如100进行观察）

   

   然后新建HTTP请求

   

   界面按如下填写
   

   然后，运行，启动

   

   这时再看lvs负载情况，在DS主机上使用命令：ipvsadm -l --stats
   
   得到如下所示图
   
   此时VIP88负载RS128和131，可以看到访问数是一样的都是343

   DS备机上查看结果为
   
   因为没有经过备机lvs进行负载，所以没有连接数都为0

   主机再次查看
   
   多次查看会发现在这两台RS之间的访问数要么相同，要么相差1，这是符合RR轮询算法的，负载均衡并没有问题。

   这时我们再把主机keepalived停掉，那么备机lvs会接管，页面上仍然可以访问虚拟IP到两个RS服务器。主机停掉之后，ipvsadm -l --stats查看发现连接数不再增加，而此时备机使用该命令查看发现由0开始进行负载，说明lvs服务器切换成功，一段时间后再把主机keepalived重启，发现备机连接数不动了，而主机又开始增加。。。

   说明这个高可用与负载均衡搭建没有问题。

---

lvs负载均衡算法和机制补充（网上资料）

这块很核心，建议多学习一下

轮询算法

1.轮询调度

调度器通过外部请求的顺序轮流的分配到集群中的真实服务器上，对每台服务器都是均等的。但是这样调度器不会考虑服务器上实际的连接数和系统负载，导致服务器处理请求慢，系统负载增大。

2.加权轮叫

调度器通过一个算法根据真实服务器的不同处理能力来分配访问请求，这样可以保证服务器的处理能力。

3.最少连接

调度器将访问请求自动的分配到已建立连接最少的服务器上，如果在集群中每台服务器的性能差不多的话，则这种算法可以较好的均衡负载。

4.加权最少连接

主要用于集群中服务器性能差异大的情况下，调度器可以优化负载性能，具有较高权值的服务器可以将承受较大的活动连接。

5.基于局部性的最少连接

主要是针对目标IP地址的负载均衡，将请求的目标IP地址找到离其最近的服务器进行使用，如果服务器不存在或者满载的话，就会继续寻找下一个服务器。

6.带复制的基于局部性的最少连接

主要是针对目标IP地址的负载均衡，根据请求的目标IP地址找出该地址所对应的服务器，如果服务器不存在或者满载的话，就会继续寻找下一个服务器。当服务器有一段时间没有被修改，则会从最忙的服务器组中删除。

7.目标地址散列

根据请求的目标IP地址从静态分配的散列表中超出对应的服务器，如果找到可用的服务器且没有满载，则返回空。

8.源地址散列

根据请求的源IP地址从静态分配的散列表中超出对应的服务器，如果找到可用的服务器且没有满载，则返回空。

简单介绍一下，超详细介绍看这里：
http://www.linuxvirtualserver.org/zh/lvs4.html

lvs工作机制

1.DR机制

<网上找的图，懒得画了>

请求由 LVS 接受，由真实提供服务的服务器（RealServer, RS）直接返回给用户，返回的时候不经过 LVS。
DR 模式下需要 LVS 和绑定同一个 VIP（RS 通过将 VIP 绑定在 loopback 实现）。
一个请求过来时，LVS 只需要将网络帧的 MAC 地址修改为某一台 RS 的 MAC，该包就会被转发到相应的 RS 处理，注意此时的源 IP 和目标 IP 都没变，LVS 只是做了一下移花接木。
RS 收到 LVS 转发来的包，链路层发现 MAC 是自己的，到上面的网络层，发现 IP 也是自己的，于是这个包被合法地接受，RS 感知不到前面有 LVS 的存在。
而当 RS 返回响应时，只要直接向源 IP（即用户的 IP）返回即可，不再经过 LVS。
DR 模式是性能最好的一种模式。但因其是修改MAC的，所以无法做端口映射，所以这里在配置keepalived时VIP端口与RS端口必须一致（这里搞死我了，一开始端口不一样，老出不来）

2.NAT机制

NAT（Network Address Translation）是一种外网和内网地址映射的技术。
NAT 模式下，网络报的进出都要经过 LVS 的处理。LVS 需要作为 RS 的网关。
当包到达 LVS 时，LVS 做目标地址转换（DNAT），将目标 IP 改为 RS 的 IP。RS 接收到包以后，仿佛是客户端直接发给它的一样。
RS 处理完，返回响应时，源 IP 是 RS IP，目标 IP 是客户端的 IP。
这时 RS 的包通过网关（LVS）中转，LVS 会做源地址转换（SNAT），将包的源地址改为 VIP，这样，这个包对客户端看起来就仿佛是 LVS 直接返回给它的。客户端无法感知到后端 RS 的存在。

3.FULL-NAT机制

无论是 DR 还是 NAT 模式，不可避免的都有一个问题：LVS 和 RS 必须在同一个 VLAN 下，否则 LVS 无法作为 RS 的网关。
这引发的两个问题是：
1、同一个 VLAN 的限制导致运维不方便，跨 VLAN 的 RS 无法接入。
2、LVS 的水平扩展受到制约。当 RS 水平扩容时，总有一天其上的单点 LVS 会成为瓶颈。
Full-NAT 由此而生，解决的是 LVS 和 RS 跨 VLAN 的问题，而跨 VLAN 问题解决后，LVS 和 RS 不再存在 VLAN 上的从属关系，可以做到多个 LVS 对应多个 RS，解决水平扩容的问题。
Full-NAT 相比 NAT 的主要改进是，在 SNAT/DNAT 的基础上，加上另一种转换，转换过程如下：

在包从 LVS 转到 RS 的过程中，源地址从客户端 IP 被替换成了 LVS 的内网 IP。
内网 IP 之间可以通过多个交换机跨 VLAN 通信。
当 RS 处理完接受到的包，返回时，会将这个包返回给 LVS 的内网 IP，这一步也不受限于 VLAN。
LVS 收到包后，在 NAT 模式修改源地址的基础上，再把 RS 发来的包中的目标地址从 LVS 内网 IP 改为客户端的 IP。
Full-NAT 主要的思想是把网关和其下机器的通信，改为了普通的网络通信，从而解决了跨 VLAN 的问题。采用这种方式，LVS 和 RS 的部署在 VLAN 上将不再有任何限制，大大提高了运维部署的便利性。

4.TUN机制

采用NAT模式时，由于请求和响应的报文必须通过调度器地址重写，当客户请求越来越多时，调度器处理能力将成为瓶颈。为了解决这个问题，调度器把请求的报文通过IP隧道转发到真实的服务器。真实的服务器将响应处理后的数据直接返回给客户端。这样调度器就只处理请求入站报文，由于一般网络服务应答数据比请求报文大很多，采用VS/TUN模式后，集群系统的最大吞吐量可以提高10倍。

VS/TUN的工作流程图如下所示，它和NAT模式不同的是，它在LB和RS之间的传输不用改写IP地址。而是把客户请求包封装在一个IP tunnel里面，然后发送给RS节点服务器，节点服务器接收到之后解开IP tunnel后，进行响应处理。并且直接把包通过自己的外网地址发送给客户不用经过LB服务器。

原理图过程简述：

• 客户请求数据包，目标地址VIP发送到LB上。

• LB接收到客户请求包，进行IP Tunnel封装。即在原有的包头加上IP Tunnel的包头。然后发送出去。

• RS节点服务器根据IP Tunnel包头信息（此时就又一种逻辑上的隐形隧道，只有LB和RS之间懂）收到请求包，然后解开IP Tunnel包头信息，得到客户的请求包并进行响应处理。

• 响应处理完毕之后，RS服务器使用自己的出公网的线路，将这个响应数据包发送给客户端。

---

lvs与nginx比较

这一块建议看一下，网上查询即可。

四层与七层负载均衡

四层负载均衡：

通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器与请求客户端建立TCP连接，然后发送Client请求的数据。

七层负载均衡：

也称内容交换，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的服务器。

由上图可知：
在四层负载设备中，把client发送的报文目标地址(原来是负载均衡设备的IP地址)，根据均衡设备设置（lvs的不同负载均衡机制）的选择web服务器的规则选择对应的web服务器IP地址，这样client就可以直接跟此服务器建立TCP连接并发送数据。

七层负载均衡服务器起了一个代理服务器的作用，我们知道建立一次TCP连接要三次握手；而client要访问webserver要先与七层负载设备进行三次握手后建立TCP连接，把要访问的报文信息发送给七层负载均衡；然后七层负载均衡再根据设置的均衡规则选择特定的webserver，然后通过三次握手与此台webserver建立TCP连接，然后webserver把需要的数据发送给七层负载均衡设备，负载均衡设备再把数据发送给client；所以，七层负载均衡设备起到了代理服务器的作用。

本站点停止更新，请访问:blog.coocap.com

学习参考资料链接

http://blog.csdn.net/ioy84737634/article/details/44916241

http://blog.csdn.net/zwz1984/article/details/45194377

http://www.jizhuomi.com/software/351.html

http://www.aixchina.net/Article/39457

http://lovelace.blog.51cto.com/1028430/1550188

本站点停止更新，请访问:blog.coocap.com