一文透析高并发场景下LVS安装与高可用实现

文章经作者授权转载，来源：惨绿少年的博客（http://www.cnblogs.com/clsn/p/7920637.html）

本文目录：

1. LVS介绍与集群搭建

2. 负载均衡（LVS）相关名词

3. 在Web端的操作有什么含义

4. LVS集群的工作模式

5. IPVS调度器实现的八种负载调度算法

6. LVS+Keepalived方案实现

7. 常见LVS负载均衡高可用解决方案

一、负载均衡介绍

1 、负载均衡的妙用

负载均衡（Load Balance）集群提供了一种廉价、有效、透明的方法，来扩展网络设备和服务器的负载、带宽，增加吞吐量，加强网络数据处理能力，提高网络的灵活性和可用性。

• 单台计算机无法承受大规模的并发访问或数据流量了，此时需要搭建负载均衡集群把流量分摊到多台节点设备上分别处理，即减少用户等待响应的时间又提升了用户体验；

• 7*24小时的服务保证，任意一个或多个有限后端节点设备宕机，不能影响整个业务的运行。

2 、为什么要用LVS

1. 工作在网络模型的7层，可以针对http应用做一些分流的策略，比如针对域名、目录结构，Nginx单凭这点可利用的场合就远多于LVS了。

2. 最新版本的Nginx也支持4层TCP负载，曾经这是LVS比Nginx好的地方。

3. Nginx对网络稳定性的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势之一，相反LVS对网络稳定性依赖比较大。

4. Nginx安装和配置比较简单，测试起来比较方便，它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了，LVS对网络依赖比较大。

那为什么要用LVS呢？

• 简单一句话，当并发超过了Nginx上限，就可以使用LVS了。

• 日1000-2000W PV或并发请求1万以下都可以考虑用Nginx。

• 大型门户网站，电商网站需要用到LVS。

 

二、LVS介绍

LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统，可以在Unix/Linux平台下实现负载均衡集群功能。该项目在1998年5月由章文嵩博士组织成立，是中国国内最早出现的自由软件项目之一。

1 、相关参考资料

LVS官网：

http://www.linuxvirtualserver.org/index.html

相关中文资料：

• LVS项目介绍

  http://www.linuxvirtualserver.org/zh/lvs1.html

• LVS集群的体系结构

  http://www.linuxvirtualserver.org/zh/lvs2.html

• LVS集群中的IP负载均衡技术

  http://www.linuxvirtualserver.org/zh/lvs3.html

• LVS集群的负载调度

  http://www.linuxvirtualserver.org/zh/lvs4.html

 

2 、LVS内核模块ip_vs介绍

• 早在2.2内核时， IPVS就已经以内核补丁的形式出现。

• 从2.4.23版本开始，IPVS软件就合并到Linux内核的常用版本的内核补丁的集合。

• 从2.4.24以后IPVS已经成为Linux官方标准内核的一部分。

• LVS无需安装

• 安装的是管理工具，第一种叫ipvsadm，第二种叫keepalive

• ipvsadm是通过命令行管理，而keepalive读取配置文件管理

• 后面我们会用Shell脚本实现keepalive的功能

 

三、LVS集群搭建

1 、集群环境说明

主机说明

[[email protected] ~]# cat /etc/redhat-release

CentOS Linux release 7.4.1708 (Core)

[[email protected] ~]# uname -a

Linux lb03 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

[[email protected] ~]# systemctl status firewalld.service

● firewalld.service - firewalld - dynamic firewall daemon

   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)

   Active: inactive (dead)

     Docs: man:firewalld(1)

[[email protected] ~]# getenforce

Disabled

 

Web 环境说明

[[email protected] ~]# curl 10.0.0.17

web03

[[email protected] ~]# curl 10.0.0.18

web04

Web服务器的搭建参照：

• Tomcat： http://www.cnblogs.com/clsn/p/7904611.html

• Nginx： http://www.cnblogs.com/clsn/p/7750615.html

 

2 、安装ipvsadm管理工具

安装管理工具

yum -y install ipvsadm

查看当前LVS状态，顺便激活LVS内核模块。

ipvsadm

查看系统的LVS模块。

[[email protected] ~]# lsmod|grep ip_vs

ip_vs_wrr              12697  1

ip_vs                 141092  3 ip_vs_wrr

nf_conntrack          133387  1 ip_vs

libcrc32c              12644  3 xfs,ip_vs,nf_conntrack

3 、LVS集群搭建

配置LVS负载均衡服务（在lb03操作）

• 步骤1：在eth0网卡绑定VIP地址（ip）

• 步骤2：清除当前所有LVS规则（-C）

• 步骤3：设置tcp、tcpfin、udp链接超时时间（--set）

• 步骤4：添加虚拟服务（-A），-t指定虚拟服务的IP端口，-s 指定调度算法 调度算法见man ipvsadm， rr wrr 权重轮询 -p 指定超时时间

• 步骤5：将虚拟服务关联到真实服务上（-a） -r指定真实服务的IP端口 -g LVS的模式 DR模式 -w 指定权重

• 步骤6：查看配置结果（-ln）

 

命令集：

ip addr add 10.0.0.13/24 dev eth0

ipvsadm -C                   

ipvsadm --set 30 5 60        

ipvsadm -A -t 10.0.0.13:80 -s wrr -p 20  

ipvsadm -a -t 10.0.0.13:80 -r 10.0.0.17:80 -g -w 1

ipvsadm -a -t 10.0.0.13:80 -r 10.0.0.18:80 -g -w 1

ipvsadm -ln

检查结果：

[[email protected] ~]# ipvsadm -ln

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Scheduler Flags

  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn

TCP  10.0.0.13:80 wrr persistent 20

  -> 10.0.0.17:80                 Route   1      0          0 

  -> 10.0.0.18:80                 Route   1      0          0  

 

ipvsadm参数说明：(更多参照 man ipvsadm)

 

4 、在Web浏览器配置操作

• 步骤1：在lo网卡绑定VIP地址（ip）

• 步骤2：修改内核参数抑制ARP响应

命令集：

ip addr add 10.0.0.13/32 dev lo

cat >>/etc/sysctl.conf<

net.ipv4.conf.all.arp_ignore = 1

net.ipv4.conf.all.arp_announce = 2

net.ipv4.conf.lo.arp_ignore = 1

net.ipv4.conf.lo.arp_announce = 2

EOF

sysctl –p

至此LVS集群配置完毕！

 

5 、进行访问测试

浏览器访问：

命令行测试：

[[email protected] ~]# curl 10.0.0.13

web03

抓包查看结果：

arp解析查看：

[[email protected] ~]# arp -n

Address                  HWtype  HWaddress           Flags Mask            Iface

10.0.0.254               ether   00:50:56:e9:9f:2c   C                     eth0

10.0.0.18                ether   00:0c:29:ea:ca:55   C                     eth0

10.0.0.13                ether   00:0c:29:de:7c:97   C                     eth0

172.16.1.15              ether   00:0c:29:de:7c:a1   C                     eth1

10.0.0.17                ether   00:0c:29:4a:ac:4a   C                     eth0

四、负载均衡（LVS）相关名词

术语说明：

• DS：Director Server。指的是前端负载均衡器节点。

• RS：Real Server。后端真实的工作服务器。

• VIP：向外部直接面向用户请求，作为用户请求的目标的IP地址。

• DIP：Director Server IP，主要用于和内部主机通讯的IP地址。

• RIP：Real Server IP，后端服务器的IP地址。

• CIP：Client IP，访问客户端的IP地址。

 

1 、LVS集群的工作模式--DR直接路由模式

DR模式是通过改写请求报文的目标MAC地址，将请求发给真实服务器的，而真实服务器将响应后的处理结果直接返回给客户端用户。

DR技术可极大地提高集群系统的伸缩性。但要求调度器LB与真实服务器RS都有一块物理网卡连在同一物理网段上，即必须在同一局域网环境。

DR直接路由模式说明：

1. 通过在调度器LB上修改数据包的目的MAC地址实现转发。注意，源IP地址仍然是CIP，目的IP地址仍然是VIP。

2. 请求的报文经过调度器，而RS响应处理后的报文无需经过调度器LB，因此并发访问量大时使用效率很高，比Nginx代理模式强于此处。

3. 因DR模式是通过MAC地址的改写机制实现转发的，因此所有RS节点和调度器LB只能在同一个局域网中。需要注意RS节点的VIP的绑定(lo:vip/32)和ARP抑制问题。

4. 强调下：RS节点的默认网关不需要是调度器LB的DIP，而应该直接是IDC机房分配的上级路由器的IP(这是RS带有外网IP地址的情况)，理论上讲，只要RS可以出网即可，不需要必须配置外网IP，但走自己的网关，那网关就成为瓶颈了。

5. 由于DR模式的调度器仅进行了目的MAC地址的改写，因此调度器LB无法改变请求报文的目的端口。LVS DR模式的办公室在二层数据链路层（MAC），NAT模式则工作在三层网络层（IP）和四层传输层（端口）。

6. 当前调度器LB支持几乎所有Unix、Linux系统，但不支持Windows系统。真实服务器RS节点可以是Windows系统。

7. 总之，DR模式效率很高，但配置也较麻烦。因此，访问量不是特别大的公司可以用Haproxy/Nginx取代之。这符合运维的原则：简单、易用、高效。日1000-2000W PV或并发请求1万以下都可以考虑用Haproxy/Nginx(LVS的NAT模式)

8. 直接对外的访问业务，例如Web服务做RS节点，RS最好用公网IP地址。如果不直接对外的业务，例如：MySQL，存储系统RS节点，最好只用内部IP地址。

 

DR的实现原理和数据包的改变

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

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

3. IPVS比对数据包请求的服务是否为集群服务，若是，将请求报文中的源MAC地址修改为DIP的MAC地址，将目标MAC地址修改RIP的MAC地址，然后将数据包发至POSTROUTING链。此时的源IP和目的IP均未修改，仅修改了源MAC地址为DIP的MAC地址，目标MAC地址为RIP的MAC地址

4. 由于DS和RS在同一个网络中，所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址，那么此时数据包将会发至Real Server。

5. RS发现请求报文的MAC地址是自己的MAC地址，就接收此报文。处理完成之后，将响应报文通过lo接口传送给eth0网卡然后向外发出。 此时的源IP地址为VIP，目标IP为CIP。

6. 响应报文最终送达至客户端。

 

五、在Web端的操作有什么含义？

1 、RealServer为什么要在lo接口上配置VIP？

既然要让RS能够处理目标地址为vip的IP包，首先必须要让RS能接收到这个包。在lo上配置VIP能够完成接收包并将结果返回client。

2 、在eth0网卡上配置VIP可以吗？

不可以，将VIP设置在eth0网卡上，会影响RS的arp请求，造成整体LVS集群arp缓存表紊乱，以至于整个负载均衡集群都不能正常工作。

3 、为什么要抑制ARP响应？

（1）arp协议说明

ARP协议，全称"Address Resolution Protocol"，中文名是地址解析协议，使用ARP协议可实现通过IP地址获得对应主机的物理地址(MAC地址)。ARP协议要求通信的主机双方必须在同一个物理网段（即局域网环境）！

 

为了提高IP转换MAC的效率，系统会将解析结果保存下来，这个结果叫做ARP缓存。

• Windows查看ARP缓存命令 arp -a

• Linux查看ARP缓存命令 arp -n

• Linux解析IP对应的MAC地址 arping -c 1 -I eth0 10.0.0.6

 

ARP 缓存表是把双刃剑

1. 主机有了arp缓存表，可以加快ARP的解析速度，减少局域网内广播风暴。因为arp是发广播解析的，频繁的解析也是消耗带宽的，尤其是机器多的时候。

2. 正是有了arp缓存表，给恶意黑客带来了攻击服务器主机的风险，这个就是arp欺骗攻击。

3. 切换路由器、负载均衡器等设备时，可能会导致短时网络中断，因为所有的客户端ARP缓存表没有更新。

 

（2）服务器切换ARP问题

当集群中一台提供服务的lb01机器宕机后，然后VIP会转移到备机lb02上，但客户端的ARP缓存表的地址解析还是宕机的lb01的MAC地址，从而导致，即使在lb02上添加VIP，也会发生客户端无法访问的情况。

解决办法是：当lb01宕机，VIP地址迁移到lb02时，需要通过arping命令通知所有网络内机器更新本地的ARP缓存表，从而使得客户机访问时重新广播获取MAC地址。

这个是自己开发服务器高可用脚本及所有高可用软件必须考虑到的问题。

ARP广播进行新的地址解析

arping -I eth0 -c 1 -U VIP

arping -I eth0 -c 1 -U 10.0.0.13

测试命令

ip addr del 10.0.0.13/24 dev eth0

ip addr add 10.0.0.13/24 dev eth0

ip addr show eth0

arping -I eth0 -c 1 -U 10.0.0.13

windows查看arp -a

 

接口: 10.0.0.1 --- 0x12

Internet 地址         物理地址              类型

  10.0.0.13             00-0c-29-de-7c-97     动态      

  10.0.0.15             00-0c-29-de-7c-97     动态      

  10.0.0.16             00-0c-29-2e-47-20     动态      

  10.0.0.17             00-0c-29-4a-ac-4a     动态      

  10.0.0.18             00-0c-29-ea-ca-55     动态       

 

（3）arp_announce和arp_ignore详解

#  配置的内核参数

net.ipv4.conf.all.arp_ignore = 1

net.ipv4.conf.all.arp_announce = 2

net.ipv4.conf.lo.arp_ignore = 1

net.ipv4.conf.lo.arp_announce = 2

LVS在DR模式下需要关闭arp功能。

• arp_announce

对网络接口上，本地IP地址发出的，ARP回应，作出相应级别的限制：确定不同程度的限制，宣布对来自本地源IP地址发出Arp请求的接口。

• arp_ignore定义

对目标地定义对目标地址为本地IP的ARP询问不同的应答模式0

• 抑制RS端arp前的广播情况

• 抑制RS端arp后广播情况

 

六、LVS集群的工作模式

DR（Direct Routing）直接路由模式

NAT（Network Address Translation）

TUN（Tunneling）隧道模式

FULLNAT（Full Network Address Translation）

1 、LVS集群的工作模式--NAT

 

通过网络地址转换，调度器LB重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器，真实服务器的响应报文处理之后，返回时必须要通过调度器，经过调度器时报文的源地址被重写，再返回给客户，完成整个负载调度过程。

收费站模式---来去都要经过LB负载均衡器。

 

NAT 方式的实现原理和数据包的改变

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

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

3. IPVS比对数据包请求的服务是否为集群服务，若是，修改数据包的目标IP地址为后端服务器IP，然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP，目标IP为RIP。

4. POSTROUTING链通过选路，将数据包发送给Real Server。

5. Real Server比对发现目标为自己的IP，开始构建响应报文发回给Director Server。 此时报文的源IP为RIP，目标IP为CIP。

6. Director Server在响应客户端前，此时会将源IP地址修改为自己的VIP地址，然后响应给客户端。 此时报文的源IP为VIP，目标IP为CIP。

 

LVS-NAT 模型的特性

• RS应该使用私有地址，RS的网关必须指向DIP

• DIP和RIP必须在同一个网段内

• 请求和响应报文都需要经过Director Server，高负载场景中，Director Server易成为性能瓶颈

• 支持端口映射

• RS可以使用任意操作系统

缺陷：对Director Server压力会比较大，请求和响应都需经过director server。

 

2 、LVS集群的工作模式--隧道模式TUN

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

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

TUN 原理和数据包的改变

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。

6. 响应报文最终送达至客户端。

 

LVS-Tun 模型特性

• RIP、VIP、DIP全是公网地址

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

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

• 不支持端口映射

• RS的系统必须支持隧道

 

3 、LVS集群的工作模式--FULLNAT

LVS的DR和NAT模式要求RS和LVS在同一个vlan中，导致部署成本过高；TUNNEL模式虽然可以跨vlan，但RealServer上需要部署ipip隧道模块等，网络拓扑上需要连通外网，较复杂，不易运维。

为了解决上述问题，开发出FULLNAT，该模式和NAT模式的区别是：数据包进入时，除了做DNAT，还做SNAT（用户ip->内网ip），从而实现LVS-RealServer间可以跨vlan通讯，RealServer只需要连接到内网。类比地铁站多个闸机。

七、IPVS调度器的八种负载调度算法

1 、轮询（Round Robin）RR

调度器通过"轮叫"调度算法，将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。

 

2 、加权轮叫（Weighted Round Robin）WRR

调度器通过"加权轮叫"调度算法，根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

 

3 、最少链接（Least Connections） LC

调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载。

 

4 、加权最少链接（Weighted Least Connections） Wlc

在集群系统中的服务器性能差异较大的情况下，调度器采用"加权最少链接"调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

 

5 、基于局部性的最少链接（Locality-Based Least Connections） Lblc

"基于局部性的最少链接" 调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用"最少链接"的原则选出一个可用的服务 器，将请求发送到该服务器。

 

6 、带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）

"带复制的基于局部性最少链接"调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是，它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务 器组，按"最小连接"原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按"最小连接"原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。

 

7 、目标地址散列（Destination Hashing） Dh

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

 

8 、源地址散列（Source Hashing）SH

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

八、LVS+Keepalived方案实现

1 、keepalived功能

• 添加VIP

• 添加LVS配置

• 高可用（VIP漂移）

• web服务器健康检查

 

2 、在负载器安装Keepalived软件

yum -y install keepalived

# 检查软件是否安装

[[email protected] ~]# rpm -qa keepalived

keepalived-1.3.5-1.el7.x86_64

3 、修改配置文件

• lb03上keepalied配置文件

lb03 /etc/keepalived/keepalived.conf

[[email protected] ~]# cat /etc/keepalived/keepalived.conf

global_defs {

    router_id LVS_01

}

vrrp_instance VI_1 {

     state MASTER

     interface eth0

     virtual_router_id 51

     priority 150

     advert_int 1

     authentication {

         auth_type PASS

         auth_pass 1111

     }

     virtual_ipaddress {

      10.0.0.13/24

     }

}

virtual_server 10.0.0.13 80 {

     delay_loop 6             

     lb_algo wrr               

     lb_kind DR               

     nat_mask 255.255.255.0

     persistence_timeout 50    

     protocol TCP               

     real_server 10.0.0.17 80 {

         weight 1              

         TCP_CHECK {

         connect_timeout 8      

         nb_get_retry 3

         delay_before_retry 3

         connect_port 80

         }

     }

     real_server 10.0.0.18 80 {

         weight 1             

         TCP_CHECK {

         connect_timeout 8      

         nb_get_retry 3

         delay_before_retry 3

         connect_port 80

         }

     }

• lb04的Keepalied配置文件

lb04 /etc/keepalived/keepalived.conf

[[email protected] ~]# cat /etc/keepalived/keepalived.conf

global_defs {

    router_id LVS_02

}

vrrp_instance VI_1 {

     state BACKUP

     interface eth0

     virtual_router_id 51

     priority 100

     advert_int 1

     authentication {

         auth_type PASS

         auth_pass 1111

     }

     virtual_ipaddress {

      10.0.0.13/24

     }

}

virtual_server 10.0.0.13 80 {

     delay_loop 6         

     lb_algo wrr               

     lb_kind DR               

     nat_mask 255.255.255.0

     persistence_timeout 50    

     protocol TCP                

     real_server 10.0.0.17 80 {

         weight 1             

         TCP_CHECK {

         connect_timeout 8      

         nb_get_retry 3

         delay_before_retry 3

         connect_port 80

         }

     }

     real_server 10.0.0.18 80 {

         weight 1             

         TCP_CHECK {

         connect_timeout 8      

         nb_get_retry 3

         delay_before_retry 3

         connect_port 80

         }

     }

}

• keepalived persistence_timeout参数意义 

• LVS Persistence 参数的作用

http://blog.csdn.net/nimasike/article/details/53911363

 

4 、启动keepalived服务

 

[[email protected] ~]# systemctl restart  keepalived.service

# 检查lvs状态

[[email protected] ~]# ipvsadm -ln

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port Scheduler Flags

  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn

TCP  10.0.0.13:80 wrr persistent 50

  -> 10.0.0.17:80                 Route   1      0          0        

  -> 10.0.0.18:80                 Route   1      0          0 

# 检查虚拟ip

[[email protected] ~]# ip a s eth0

2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000

    link/ether 00:0c:29:de:7c:97 brd ff:ff:ff:ff:ff:ff

    inet 10.0.0.15/24 brd 10.0.0.255 scope global eth0

       valid_lft forever preferred_lft forever

    inet 10.0.0.13/24 scope global secondary eth0

       valid_lft forever preferred_lft forever

    inet6 fe80::20c:29ff:fede:7c97/64 scope link

       valid_lft forever preferred_lft forever

 

5 、在web服务器上进行配置

（在web03/web04同时操作下面步骤）

步骤1：在lo网卡绑定VIP地址（ip）

步骤2：修改内核参数抑制ARP响应

ip addr add 10.0.0.13/32 dev lo

cat >>/etc/sysctl.conf<

net.ipv4.conf.all.arp_ignore = 1

net.ipv4.conf.all.arp_announce = 2

net.ipv4.conf.lo.arp_ignore = 1

net.ipv4.conf.lo.arp_announce = 2

EOF

sysctl –p

注意：web服务器上的配置为临时生效，可以将其写入rc.local文件，注意文件的执行权限。

使用curl命令进行测试

[[email protected] ~]# curl 10.0.0.13

web03

至此keepalived+LVS配置完毕。

 

九、常见LVS负载均衡高可用解决方案

Ø 开发类似keepalived的脚本，早期的办法，现在不推荐使用。

Ø heartbeat+lvs+ldirectord脚本配置方案，复杂不易控制，不推荐使用

Ø RedHat工具piranha，一个web界面配置LVS。

Ø LVS-DR+keepalived方案，推荐最优方案，简单、易用、高效。

1 、LVS排错思路

2、 参考文档

• LVS项目介绍

  http://www.linuxvirtualserver.org/zh/lvs1.html

• LVS集群的体系结构

  http://www.linuxvirtualserver.org/zh/lvs2.html

• LVS集群中的IP负载均衡技术

  http://www.linuxvirtualserver.org/zh/lvs3.html

• LVS集群的负载调度      

  http://www.linuxvirtualserver.org/zh/lvs4.html

• NAT模式安装详解  

  http://www.cnblogs.com/liwei0526vip/p/6370103.html

• 开发眼光看LVS   

  http://blog.hesey.net/2013/02/introduce-to-load-balance-and-lvs-briefly.html

• LVS介绍     

  http://www.it165.net/admin/html/201401/2248.html

近期热文：

唯品会运维数据技术实践的三重境界

一套大而全的系统架构体系与具体落地方案

AWS DevOps实践：一年5000万次部署是怎样一种概念？

京东京麦：微服务架构下的高可用网关与容错实践

凡墙皆门：移动云自动化运维平台的破墙与进化之路