天啊，距离小编将HA群集已经有一个多月啦，还记得小编在HA群集最后提出的一个小问题么，没有企业会拿HA来做一些普通业务的，HA一般都是来做一些关键性业务的，那么在这篇博客中小编就来讲讲LB群集（负载均衡群集）的原理以及实现啦
一、负载均衡群集总体架构
使用负载均衡群集能实现综合业务的海量并发，在负载均衡架构中，Director（dispatcher）负责接收客户端请求，并将请求按照某种算法分发到后台真正提供服务的服务器上。按照层次来划分，有四层交换和七层交换。为了实现这种技术可以基于硬件来实现，常用的有F5（四层交换），也可以基于软件来实现ipvs（四层交换）、squid（七层交换）、nginx（七层交换）
二、使用LVS（Linux Virtual Server）来实现负载均衡
在linux的2.4之后的内核中有一种实现数据包请求处理的模块叫ipvs，并且提供了的相关客户端软件ipvsadm来实现规则的定义以完成对请求数据包的处理，小编的内核是2.6.18，看看它的内核配置文件可以发现IPVS的
LVS的整体架构如图2-1所示：
图2-1
VIP(Virtual IP)：Director对外呈现的IP地址，用户可以通过VIP来获取相关服务；
DIP(Director's IP)：Director用来和Real Server通信的IP；
RIP(Real IP)：Real Server的IP；
三、LVS的模型分类
根据Director和后端服务器的通信方式，LVS大致可分为三类：Network Address Translation（LVS-NAT）、Director routing （LVS-DR ）、IP tunneling (LVS-TUN )，小编就每一种分类做一下简要说明
1、Virtual Server via Network Address Translation（LVS-NAT）
通过网络地址转换，Director重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的Real Server；Real Server的响应报文通过Director时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。可以想象一下，所有的数据请求都经过Director，那实现Director的服务器压力三大啦；
2、Virtual Server via Direct Routing（LVS-DR）
为了解决LVS-NAT的的问题，便产生了LVS-DR，外界用户发送每次发送数据请求的时候是要经过Director的，Director通过一定得调度算法选择Real Server并将收到的客户端请求报文的目标MAC改写成为被选Real Server的MAC地址，而Real Server将响应客户端的时候并不经过Director了。
3、Virtual Server via IP Tunneling（LVS-TUN）
Director把请求报文通过IP隧道转发至Real Server，而Real Server将响应直接返回给客户，所以Director只处理请求报文。由于一般网络服务应答比请求报文大许多，采用 LVS-TUN技术后，集群系统的最大吞吐量可以提高10倍。
四、Director采用的调度算法
Director支持的调度算法可以直接从内核配置文件中看到的，如图4-1所示：
图4-1
当然这九种调度算法又可以分为两大类，分别是静态调度和动态调度啦，小编这里做一下解释：
1、固定调度算法
按照某种既定的算法，不考虑实时的连接数予以分配：
A、Round-robin（RR）轮循：将外部请求按顺序轮流分配到集群中的Real Server， 它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载；
B、Weighted round-robin（WRR）加权轮询：给每台Real Server分配一个权值，权值越大，分到的请求数越多；
C、Destination hashing （DH）目标散列：根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。来自于同一个IP地址的请求都被重定向到同一台Real Server上，保证目标地址不变；
D、Source hashing（SH）源地址散列：根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。Director必须确保响应的数据包必须通过请求数据包所经过的路由器或者防火墙，保证源地址不变。
2、动态调度算法
通过检查服务器上当前连接的活动状态来重新决定下一步调度方式该如何实现：
A、Lease Connection （LC） 最少连接：哪一个Real Server上的连接数少就将下一个连接请求定向到那台Real Server上去。算法实现：连接数=活动连接数*256+非活动连接数；
B、Weight Least-Connection（WLC） 加权最少连接：在最少连接的基础上给每台Real Server分配一个权重。算法实现：连接数=（活动连接数*256+非活动连接数）÷权重，是一种比较理想的算法；
C、Shortest Expected Delay (SED) 最短期望延迟：不再考虑非活动连接数，算法实现：连接数=(活动连接数+1) *256 ÷权重；
D、Never Queue (NQ) 永不排队算法：对SED的改进，当新请求过来的时候不仅要取决于SED算法所得到的值，还要取决于Real Server上是否有活动连接；
E、Locality-Based Least-Connection (LBLC) 基于本地状态的最少连接：在DH算法的基础上还要考虑服务器上的活动连接数；
F、Locality-Based Least-Connection with Replication Scheduling (LBLCR) 带复制的基于本地的最少连接：是LBLC算法的改进。
五、LVS-NAT
目标地址转换，即所有客户端的请求都被Director根据访问请求和算法被定向到后台的Real Server 上，后台的Real Server回应客户端的数据包也要经过Director返回给客户端，地址转换过程如图5-1所示：
图5-1
LVS-NAT特性：
1、Director和Real Server必须在同一个网段中；
2、一般情况下，RIP是私有地址，只用于集群内部节点间通信；
3、Director 会响应所有的请求在客户端和Real Server之间，所承担的负载较大；
4、所有的Real IP 网关必须指向DIP以响应客户端请求；
5、Director可以重映射网络端口，即前端使用标准端口，后端使用非标准端口；
6、后台的Real Server可以使用任何操作系统；
7、Director可能会成为系统瓶颈。
LVS-NAT集群的设计及实现
拓扑如图5-2所示：
图5-2
Director ： VIP 192.168.0.80
DIP 192.168.110.254
Real Server 1： RIP 192.168.10.2 网关指向：192.168.110.254
提供Web服务，测试页内容为 Web1
Real Server 2： RIP 192.168.10.3 网关指向：192.168.110.254
提供Web服务，测试页内容为 Web2
Client： 192.168.0.1 客户端
Real Server 1：
# ifconfig eth0 192.168.110.2 //为eth0 设置IP地址；
# route add default gw 192.168.110.254 //添加网关；
Real Server 2：
# ifconfig eth0 192.168.110.3 //同上；
# route add default gw 192.168.110.254 //同上；
Director：
# ifconfig eth1 192.168.110.254 //为Director 设置DIP；
# echo 1 > /proc/sys/net/ipv4/ip_forward //开启内核路由功能；
# vim /etc/sysctl.conf //修改内核参数，确保永久有效；
net.ipv4.ip_forward = 1
# sysctl -p //查看内核参数；
net.ipv4.ip_forward = 1
准备工作已经配置完毕，开始LVS-NAT的配置：
# yum install ipvsadm -y //安装ipvsadm工具；
# ipvsadm -A -t 192.168.0.80:80 -s rr //定义服务，设定算法
为服务添加Real Server并设置权重：
# ipvsadm -a -t 192.168.0.80:80 -r 192.168.110.2 -m -w 5
# ipvsadm -a -t 192.168.0.80:80 -r 192.168.110.3 -m -w 2
# ipvsadm -Ln //查看服务状态；
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.80:80 rr
-> 192.168.110.3:80 Masq 5 0 11
-> 192.168.110.2:80 Masq 2 0 12
此时，我们使用物理机访问http：192.168.0.80就会发现页面出现交替变化的情况，这是由RR算法的特性决定的。我们改变为WRR算法试试：
# ipvsadm -E -t 192.168.0.80:80 -s wrr //改为WRR调度算法；
# ipvsadm -Ln
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.80:80 wrr
-> 192.168.110.3:80 Masq 5 0 50
-> 192.168.110.2:80 Masq 2 0 21
改变为LBLC算法：
# ipvsadm -E -t 192.168.0.80:80 -s lblc
# ipvsadm -Ln
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.0.80:80 lblc
-> 192.168.110.3:80 Masq 5 0 100
-> 192.168.110.2:80 Masq 2 0 35
此时会发现无论客户端怎么刷新，访问页面都不会改变，这是由LBLC调度算法所决定的。
六、LVS-DR
直接路由就是客户端请求经过Director分发给Real Server后，Real Server直接回应客户端。如图6-1所示，数据包地址转换过程：
图6-1
LVS-DR特性：
1、Real Server 上必须配置VIP且需要隐藏起来，只有在响应客户端请求时才使用VIP作为源地址，除此之外并不使用此VIP；
2、集群节点和Director必须在同一个网络中；
3、RIP不要求为私有地址；
4、Director仅处理所有进来的请求；
5、Real Server 不能以DIP作为网关，而是以公网上的某台路由器作为网关；
6、Director 不能再使用端口重映射；
7、大多数操作系统可以被用来作为Real Server，windows除外；
8、LVS-DR模式可以处理比LVS-NAT更多的请求。
LVS-DR为实际生产环境中最常用的一种方式，因为RIP 为公网地址，管理员可以远程连接Real Server来查看工作状态；当Director 当掉，可以通过修改DNS记录将A记录指向RIP 继续向外提供服务。
Director分发到Real Server的过程中，数据包的源地址和目标地址都没有发生改变，Director仅仅是将目标mac地址转换成某台Real Server的mac地址，源mac地址改为Director内网网卡的mac地址。这里，我们要解决的两个技术难题：
1、Real Server要避免回应客户端发来的对VIP的arp地址解析请求；
解决方法：
修改内核的两个参数：arp_announce, arp_ignore；
arp_announce ：定义不同级别：当ARP请求通过某个端口进来是否利用这个接口来回应；
0 默认级别，利用本地的任何地址，不管配置在哪个接口上去响应ARP请求；
1 避免使用另外一个接口上的mac地址去响应ARP请求；
2 尽可能使用能够匹配到ARP请求的最佳地址。
arp_ignore：当ARP请求发过来后发现自己正是请求的地址是否响应；
0 默认级别，利用本地的任何地址，不管配置在哪个接口上去响应ARP请求；
1 哪个接口上接受ARP请求，就从哪个端口上回应。
Red Hat系统提供了arptables工具，利用arp防火墙也可以实现。
2、当Real Server内网网卡响应客户端请求时，要以VIP作为源地址，不能以RIP作为源地址。
解决方法:添加一条路由
route add -host 192.168.110.1 dev lo:0
使客户端访问VIP，就让VIP来响应客户端。这样避免了使用RIP作为源地址。
图6-2
Director ： eth0:0 VIP 192.168.110.1
eth0 DIP 192.168.110.254
Real Server 1： eth0 RIP 192.168. 110.2
lo:0 VIP 192.168. 110.1
提供Web服务，测试页内容为 Web1
Real Server 2： eth0 RIP 192.168.110.3
lo:0 VIP 192.168.110.1
提供Web服务，测试页内容为 Web2
Client：192.168.110.2 客户端
Real Server 1:
# vim /etc/sysctl.conf //修改内核参数，避免回应客户端发来的对VIP的arp地址解析请求；
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_announce = 2
# sysctl -p //显示内核参数；
# ifconfig eth0 192.168.110.2/24 //设置IP地址RIP；
# ifconfig lo:0 192.168.110.1 broadcast 192.168.110.1 netmask 255.255.255.255 // 设置VIP；
# route add -host 192.168.110.1 dev lo:0 //添加路由；
Real Server 2网卡eth0的地址为192.168.110.3，服务的设置方法同Real Server 1一致。
Director:
# ifconfig eth0 192.168.110.254/24 //设置DIP；
# ifconfig eth0:0 192.168.110.1 broadcast 192.168.110.1 netmask 255.255.255.255 //设置VIP；
# route add -host 192.168.110.1 dev eth0:0 // 添加路由；
# echo 1 > /proc/sys/net/ipv4/ip_forward //开启内核路由功能；
# ipvsadm -C //清空规则；
# ipvsadm -A -t 192.168.110.1:80 -s wlc //添加服务，设定调度算法；
添加Real Server：
# ipvsadm -a -t 192.168.110.1:80 -r 192.168.110.2 -g -w 5
# ipvsadm -a -t 192.168.110.1:80 -r 192.168.110.3 -g -w 8
使用物理机浏览器访问http://192.168.110.1，查看服务状态，就可以看到两台Real Server的非活动连接数之比近似于5:8，这是由分配的权重所决定的。
# ipvsadm -Ln //查看服务状态；
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.110.1:80 wlc
-> 192.168.110.3:80 Route 8 0 18
-> 192.168.110.2:80 Route 5 0 11
七、LVS-TUN
如图7-1所示，LVS-TUN模式与LVS-DR的网络结构一样，但Director和Real Server可以在不同的网络当中。数据包从Director到Real Server过程中是基于隧道来传输，在数据包外层额外封装了S:DIP D:RIP 的地址。
图7-1
LVS-TUN特性：
1、Director和Real Server 不需要在同一个物理网络中；
2、RIP一定不能是私有地址；
3、Director只负责处理进来的数据包；
4、Real Server直接将数据包返回给客户端，所以Real Server默认网关不能是DIP，必须是公网上某个路由器的地址；
5、Director不能做端口重映射；
6、只有支持隧道协议的操作系统才能作为Real Server。
尽管我们选择了LVS的分发方法，但是大多时候我们要保证返回给客户端的所有响应请求必须来自于同一台Real Server，这里我们就要用到LVS Persistence（持久性）。当使用SSL会话的时候，我们常常期望只交换一次密钥就可以建立永久连接，因此，LVS持久性在SSL会话中经常被用到。
使用LVS持久性的时候，Director在内部使用一个连接根据记录称之为“持久连接模板”来确保所有来自同一个客户端的请求被分发到同一台Real Server上。
LVS 持久性类型分为PCC、PPC、PNMP、混合类型：
1、Persistent client connections
来自同一客户端所有服务的请求都被重定向到同一台Real Server上，以IP地址为准。PCC是一个虚拟服务没有端口号（或者端口号为0），以"-p" 来标识服务。
缺点是定向所有服务，期望访问不同的Real Server无法实现。
假设一个用户在访问购物网站时同时使用HTTP（80）和HTTPS（443）两种协议，就需要这样定义：
ipvsadm -A -t 192.168.110.1:0 -s rr -p
ipvsadm -a -t 192.168.110.1:0 -r 192.168.110.2 -m
ipvsadm -a -t 192.168.110.1:0 -r 192.168.110.3 -m
2、Persistent port connections
来自同一服务的请求都被重定向到同一台Real Server上，以端口号为准。例如：client---->LVS(80,22)---->RS1
client---->LVS(23)---->RS2
缺陷：期望访问不同的端口到同一台RS上，无法实现。
3、Persistent Netfilter Marked Packet persistence
根据iptables 的规则，将对于某类服务/几个不同端口的访问定义为一类。具体过程是先对某一特定类型的数据包打上标记，然后再将基于某一类标记的服务送到后台的Real Server上去，后台的Real Server 并不识别这些标记。
由于LVS-DR模型作了网卡别名，所以并不适合PNMP，因此PNMP只能用在LVS-NAT模式下：
# iptables -t mangle -A PREROUTING -i eth0 -d 192.168.110.1 -p tcp --dport 80 -j MARK --set-mark 2
# ipvsadm -A -f 2 -s wlc -p 3600
# ipvsadm -a -f 2 -r 192.168.110.2 -m -w 2
# ipvsadm -a -f 2 -r 192.168.110.3 -m -w 5
服务状态
# ipvsadm -Ln
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
FWM 2 wlc persistent 3600
-> 192.168.110.3:0 Masq 5 0 70
-> 192.168.110.2:0 Masq 2 0 0
来自同一客户端的访问请求都被分发到192.168.110.3这台Real Server上去了。
将持久和防火墙标记结合起来就能够实现端口姻亲功能，只要是来自某一客户端的对某一特定服务（需要不同的端口）的访问都定义到同一台Real Server上去。
假设这样一种场景：一个用户在访问购物网站时同时使用HTTP（80）和HTTPS（443）两种协议，我们需要将其定义到同一台Real Server上，而其他的服务不受限制，可以这样来实现：
这里会用到根CA，读者如果不清楚的话可以看看小编原来的博客
Real Server 1：
# cd /etc/pki/tls/certs/
# make httpd.pem //做一个自签名证书，内容如8-1示：
图 8-1
# mv httpd.pem /etc/httpd/ //将证书存放在httpd目录下；
# yum install mod_ssl -y //为Web服务添加openssl功能；
# cd conf.d/
# vim ssl.conf
SSLCertificateFile /etc/httpd/httpd.pem // 指定证书位置；
SSLCertificateKeyFile /etc/httpd/httpd.pem //指定密钥位置；
重启httpd 服务。
# vim /etc/hosts //修改IP地址到主机名的映射；
192.168.110.2 web1.a.com web1
Real Server 2 证书的配置过程同Real Server 1过程一样，在此不再赘述，证书内容如图8-2所示：
# make -C /etc/pki/tls/certs httpd.pem
图 8-2
# vim /etc/hosts // 修改IP地址到主机名称的映射；
192.168.110.3 web2.a.com web2
Director：
为客户端对http（80）服务、https（443）服务的访问打上标记5：
# iptables -t mangle -A PREROUTING -d 192.168.110.1 -p tcp --dport 80 -j MARK --set-mark 5
# iptables -t mangle -A PREROUTING -d 192.168.110.1 -p tcp --dport 443 -j MARK --set-mark 5
# ipvsadm -A -f 5 -s wlc -p //定义服务；
# ipvsadm -a -f 5 -r 192.168.10.2 -m -w 2 //添加Real Server；
# ipvsadm -a -f 5 -r 192.168.10.3 -m -w 5 // 添加Real Server；
# ipvsadm -Ln
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
FWM 5 wlc persistent 3600
-> 192.168.110.3:0 Masq 5 0 23
-> 192.168.110.2:0 Masq 2 0 0
使用Windows客户端访问的时候要修改C:\WINDOWS\system32\drivers\etc\hosts 文件，添加两条名称解析记录：
192.168.110.1 web1.a.com
192.168.110.1 web2.a.com
使其能够解析192.168.0.127所对应的主机名。
此时客户端无论是 访问192.168.110.1的http服务还是https 服务都会被定义到同一台Real Server上去。
4、FTP Connections
众所周知FTP在被动模式下，所使用的数据传输的端口不是固定的，这就使我们在定义持久性时无法为其打上标签。此时我们可以指定一个范围，将范围内的端口打上标记，然后使VSFTPD在被动模式下不再使用随机端口，而是使用范围内的随机端口，从而实现FTP的负载均衡。具体实现如下：
修改vsftpd的主配置文件定义在被动模式下使用的端口的范围：
vim /etc/vsftpd.conf:
pasv_min_port=10000
pasv_max_port=20000
必须保证在LVS-NAT集群模式下，服务端返回给客户端的数据包的源地址为VIP，而不是Real Server 的RIP,在vsftpd的主配置文件中添加一行：
vim /etc/vsftpd.conf
pasv_address=VIP
在Director上使用iptables定义端口：
iptables -t mangle -A PREROUTING -p tcp -d VIP --dport 21 -j MARK --set-mark 21
iptables -t mangle -A PREROUTING -p tcp -d VIP --dport 10000:20000 -j MARK --set-mark 21
好嘞，LB的东东小编算是给讲完啦，不知读者你收到多少啦，LB群集能很好的实现各种应用的负载均衡啦，非常的实用，可是读者还要考虑一个问题，万一前端的Director死掉啦咋办啦，还记得HA吧，呵呵，把HA群集的关键业务设置成处理Director，不就解决了么，这就是HA+LB的群集架构啦，读者可以去自己动手先做一做，小编会在之后的博客中附上HA+LB+NAS的实现啦，敬请关注哈
本文转自 chenming421 51CTO博客，原文链接:http://blog.51cto.com/wnqcmq/1210394
