第1章 负载均衡介绍

1.1 负载均衡的作用

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

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

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

1.2 LVS和Nginx的区别

1.2.1 Nginx优势

• Nginx工作在网络模型的7层，可以针对http应用做一些分流的策略，比如针对域名、目录结构，因此Nginx单可利用的场合远多于LVS。
• 最新版本的Nginx也支持4层TCP负载，曾经这是LVS比Nginx好的地方。
• Nginx对网络稳定性的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势之一，相反LVS对网络稳定性依赖比较大。
• Nginx安装和配置比较简单，测试起来比较方便，它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了，LVS对网络依赖比较大。

1.2.2 LVS优势

• LVS比Nginx性能高。当并发数超过Nginx上限，通常1000-2000W PV或并发请求1万以下都可以考虑用Nginx，超过此上限就需要使用LVS了，例如大型门户网站，电商网站都需要用到LVS。

第2章 LVS介绍

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

参考资料：

官网：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.1 LVS内核模块ip_vs介绍

早在2.2内核时， IPVS就已经以内核补丁的形式出现，从2.4.23版本开始，IPVS软件就合并到Linux内核的常用版本的内核补丁的集合，从2.4.24以后IPVS已经成为Linux官方标准内核的一部分。

• LVS无需安装
• 安装的是管理工具，第一种叫ipvsadm，第二种叫keepalive
• ipvsadm是通过命令行管理，而keepalive读取配置文件管理

第3章 ARP网络知识

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

3.1 ARP缓存表的作用

• 主机有了arp缓存表，可以加快ARP的解析速度，减少局域网内广播风暴，因为arp是发广播解析的，频繁的解析也是消耗带宽的，尤其是机器多的时候。
• 正是有了arp缓存表，给恶意黑客带来了攻击服务器主机的风险，这个就是arp欺骗攻击。
• 切换路由器，负载均衡器等设备时，可能会导致短时网络中断，因为所有的客户端ARP缓存表没有更新。

3.2 查看ARP缓存表的命令

3.2.1 Windows查看ARP缓存命令

arp -a

3.2.2 Linux查看ARP缓存命令

[root@lb02 ~]# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
10.0.0.254               ether   00:50:56:e3:3d:52   C                     eth0
10.0.0.3                 ether   00:0c:29:7b:8b:0f   C                     eth0
10.0.0.8                 ether   00:0c:29:b1:5b:a0   C                     eth0
10.0.0.1                 ether   00:50:56:c0:00:08   C                     eth0
10.0.0.7                 ether   00:0c:29:92:23:d8   C                     eth0

3.2.3 Linux解析IP对应的MAC地址

[root@lb02 ~]# arping -c 1 -I eth0 10.0.0.3
ARPING 10.0.0.3 from 10.0.0.6 eth0
Unicast reply from 10.0.0.3 [00:0C:29:7B:8B:0F]  0.846ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)

3.3 服务器切换ARP问题

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

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

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

3.3.1 ARP广播进行新的地址解析

1.3.1.1 查看当前缓存表

[c:\~]$ arp -a
...省略部分输出内容...
接口: 10.0.0.1 --- 0x15
  Internet 地址         物理地址              类型
  <strong>10.0.0.3              00-0c-29-7b-8b-0f     动态       </strong>
<strong>  10.0.0.5              00-0c-29-7b-8b-0f     动态       </strong>
  10.0.0.6              00-0c-29-06-04-d1     动态       
  10.0.0.7              00-0c-29-92-23-d8     动态       
  10.0.0.8              00-0c-29-b1-5b-a0     动态        
...省略部分输出内容...

3.3.1.2 取消lb01的VIP

[root@lb01 ~]# ip addr del 10.0.0.3/24 dev eth0
[root@lb01 ~]# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:7b:8b:0f brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.5/24 brd 10.0.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe7b:8b0f/64 scope link
       valid_lft forever preferred_lft forever

3.3.1.3 创建lb02的VIP

[root@lb02 ~]# ip addr add 10.0.0.3/24 dev eth0
[root@lb02 ~]# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:06:04:d1 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.6/24 brd 10.0.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 10.0.0.3/24 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe06:4d1/64 scope link
       valid_lft forever preferred_lft forever

3.3.1.4 通知新的地址解析

[root@lb02 ~]# arping -I eth0 -c 1 -U 10.0.0.3
ARPING 10.0.0.3 from 10.0.0.3 eth0
Sent 1 probes (1 broadcast(s))
Received 0 response(s)

3.3.1.5 查看更新后的ARP缓存表

[c:\~]$ arp -a
...省略部分输出内容...
接口: 10.0.0.1 --- 0x15
  Internet 地址         物理地址              类型
  <strong>10.0.0.3              00-0c-29-06-04-d1     动态 </strong>      
  10.0.0.5              00-0c-29-7b-8b-0f     动态       
  <strong>10.0.0.6              00-0c-29-06-04-d1     动态       </strong>
  10.0.0.7              00-0c-29-92-23-d8     动态       
  10.0.0.8              00-0c-29-b1-5b-a0     动态       
...省略部分输出内容...

3.4 arp_announce和arp_ignore详解

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

3.4.1 arp_announce

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

• 0 – (默认) 在任意网络接口（eth0,eth1，lo）上的任何本地地址
• 1 -尽量避免不在该网络接口子网段的本地地址做出arp回应. 当发起ARP请求的源IP地址是被设置应该经由路由达到此网络接口的时候很有用.此时会检查来访IP是否为所有接口上的子网段内ip之一.如果改来访IP不属于各个网络接口上的子网段内,那么将采用级别2的方式来进行处理。
• 2 – 对查询目标使用最适当的本地地址.在此模式下将忽略这个IP数据包的源地址并尝试选择与能与该地址通信的本地地址.首要是选择所有的网络接口的子网中外出访问子网中包含该目标IP地址的本地地址. 如果没有合适的地址被发现,将选择当前的发送网络接口或其他的有可能接受到该ARP回应的网络接口来进行发送。

3.4.2 arp_ignore

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

• 0 – (默认值): 回应任何网络接口上对任何本地IP地址的arp查询请求
• 1 – 只回答目标IP地址是来访网络接口本地地址的ARP查询请求
• 2 -只回答目标IP地址是来访网络接口本地地址的ARP查询请求,且来访IP必须在该网络接口的子网段内
• 3 – 不回应该网络界面的arp请求，而只对设置的唯一和连接地址做出回应
• 4-7 – 保留未使用
• 8 -不回应所有（本地地址）的arp查询

3.4.3 抑制RS（Real Server）端arp前的广播情况

3.4.4 抑制RS端arp后广播情况

第4章 LVS集群的工作模式

LVS有四种工作模式，分别为：

• DR（Direct Routing）直接路由模式
• NAT（Network Address Translation）
• TUN（Tunneling）隧道模式
• FULLNAT（Full Network Address Translation）

注意：FULLNAT模式未集成在内核中，需要对ip_vs模块重新编译，以打补丁的方式开启此模式。

4.1 LVS相关名词概念

• CIP：Client IP Address，客户端主机IP地址
• DIP：Director IP Address，负载服务器的IP地址
• RIP：Real Server IP Address，真正提供服务的IP地址

4.2 Nginx负载均衡模式回顾

Nginx做反向代理时用户的web访问请求和服务端的响应请求均经过负载均衡服务器，因此Nginx负载均衡服务器就成了性能的瓶颈。

4.3 DR直接路由模式

DR模式是通过改写请求报文的目标MAC地址，将请求发给真实服务器的，而真实服务器将响应后的处理结果直接返回给客户端用户。DR技术可极大地提高集群系统的伸缩性。但要求调度器LB与真实服务器RS都有一块物理网卡连在同一物理网段上，即必须在同一局域网环境。

• DR模式访问过程：

1. 用户发送包含源IP地址为CIP（Client IP）、源MAC地址为CMAC（Client MAC），目的IP地址为VIP（Virtual IP）、目的MAC为DMAC（Destination MAC：LB01的MAC地址）的包到LB01上
2. LB01解包后通过VIP地址将用户请求的包重新打包为源IP地址为CIP（Client IP）、源MAC地址为CMAC（Client MAC），目的IP地址为VIP（Virtual IP）、目的MAC为RMAC（Real Server MAC：Web01的MAC地址）的包后发送给Web01进行处理
3. Web01接收到LB01的包后，处理用户的Web请求后，将处理的信息打包为源IP地址为VIP（Virtual IP）、源MAC为RMAC（Real Server MAC：Web01的MAC地址），目的IP地址为CIP（Client IP）、目的MAC为CMAC（Client MAC）的包后直接发送给用户

此过程因为只有用户访问web服务时经过负载均衡器，因此效率比Nginx高，也解决了Nginx作为负载均衡的瓶颈问题。

• 抓包获取源MAC地址信息：

4.3.1 DR直接路由模式小结

• 通过在调度器LB上修改数据包的目的MAC地址实现转发。注意，源IP地址仍然是CIP，目的IP地址仍然是VIP。
• 请求的报文经过调度器，而RS响应处理后的报文无需经过调度器LB，因此，并发访问量大时使用效率很高，比Nginx代理模式强于此处。
• 因DR模式是通过MAC地址的改写机制实现转发的，因此，所有RS节点和调度器LB只能在同一个局域网中。
• 需要注意RS节点的VIP的绑定(lo:vip/32)和ARP抑制问题。
• 强调下：RS节点的默认网关不需要是调度器LB的DIP，而应该直接是IDC机房分配的上级路由器的IP(这是RS带有外网IP地址的情况)，理论上讲，只要RS可以出网即可，不需要必须配置外网IP，但走自己的网关，那网关就成为瓶颈了。
• 由于DR模式的调度器仅进行了目的MAC地址的改写，因此，调度器LB无法改变请求报文的目的端口。LVS DR模式的办公室在二层数据链路层（MAC），NAT模式则工作在三层网络层（IP）和四层传输层（端口）。
• 当前，调度器LB支持几乎所有UNIX、Linux系统，但不支持windows系统。真实服务器RS节点可以是windows系统。
• 总之，DR模式效率很高，但是配置也较麻烦。因此，访问量不是特别大的公司可以用haproxy/Nginx取代之。这符合运维的原则：简单、易用、高效。日1000-2000W PV或并发请求1万以下都可以考虑用haproxy/Nginx(LVS的NAT模式)
• 直接对外的访问业务，例如web服务做RS节点，RS最好用公网IP地址。如果不直接对外的业务，例如：MySQL，存储系统RS节点，最好只用内部IP地址。

4.4 NAT模式

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

4.5 隧道模式

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

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

4.6 FULLNAT模式

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

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

第5章 常见LVS负载均衡高可用解决方案

• 开发类似keepalived的脚本，早期的办法，现在不推荐使用。
• heartbeat+lvs+ldirectord脚本配置方案，复杂不易控制，不推荐使用
• RedHat工具piranha，一个web界面配置LVS。
• LVS-DR+keepalived方案，推荐最优方案，简单、易用、高效。