LVS
Load Balancer:
kernel 2.6.x 已內建 LVS 模组
kernel 2.4.x 或之前的内核版本需打补丁
rhel5 /rhel6 自带 LVS 软件包 安装 ipvsadm 软件包即可使用
三种 IP 负载均衡技术的优缺点归纳在下表中:
注:以上三种方法所能支持最大服务器数目的估计是假设调度器使用 100M 网卡,调度器的硬
件配置与后端服务器的硬件配置相同,而且是对一般 Web 服 务。使用更高的硬件配置(如千
兆网卡和更快的处理器)作为调度器,调度器所能调度的服务器数量会相应增加。当应用不同
时,服务器的数目也会相应地改变。所 以,以上数据估计主要是为三种方法的伸缩性进行量化
比较。
VS/NAT
VS/NAT 的优点是服务器可以运行任何支持 TCP/IP 的操作系统,它只需要一个 IP 地址配置在调度器上,
服务器组可以用私有的 IP 地址。缺点是它的伸缩能力有限, 当服务器结点数目升到 20 时,调度器本身
有可能成为系统的新瓶颈,因为在 VS/NAT 中请求和响应报文都需要通过负载调度器。
Load Balance 双网卡 eth0: 192.168.0.254 (对内) eth1: 192.168.1.254 (对外)
如果只有一块网卡可用以下方式:
Load Balance:192.168.0.254
Virtual IP: 192.168.1.254
Gateway: 192.168.0.254
Realserver1: 192.168.0.3
Realserver1: 192.168.0.4开启路由机制
vi /etc/sysctl.conf
net.ipv4.ip_forward = 1
sysctl -p
加载 nat 模块
modprobe iptable_nat
注:如果不加载此模块,也可以在第一次访问时成功,但是会在再次访问时出现延迟过长,或访问超时
现象
加载 rule
ipvsadm -A -t 192.168.1.254:80 -s rr
ipvsadm -a -t 192.168.1.254:80 -r 192.168.0.3:80 -m
ipvsadm -a -t 192.168.1.254:80 -r 192.168.0.4:80 -m
保存 rule
service ipvsadm save
邦定 vip
ifconfig eth0:0 192.168.1.254 netmask 255.255.255.0 up
RealServer 设置
Default Gateway 指向 Director 的 LAN IP 即 192.168.0.254
echo `hostname` > /var/www/html/index.html
service httpd start
测试
选择一台 192.168.1.0/24 网段主机访问 http:// 192.168.1.254 反复刷新网页,每次出现的网页不同
则表示成功。
VS/TUN
VS/TUN 技术对服务器有要求,即所有的服务器必须支持 “ IP Tunneling” 或者 “ IP
Encapsulation”协议。目前,VS/TUN 的后端服务器主要运行 Linux 操作系统。
在 VS/TUN 的集群系统中,负载调度器只将请求调度到不同的后端服务器,后端服务器将应答
的数据直接返回给用户。这样,负载调度器就可以处理大量的请求,它甚至可以调 度百台以上
的服务器(同等规模的服务器),而它不会成为系统的瓶颈。即使负载调度器只有 100Mbps
的全双工网卡,整个系统的最大吞吐量可超过 1Gbps。所以,VS/TUN 可以极大地增加负载调
度器调度的服务器数量。
VS/TUN 调度器可以调度上百台服务器,而它本身不会成为系统的瓶
颈,可以 用来构建高性能的超级服务器。Load Balance:192.168.0.254
Virtual IP: 192.168.0.200
gateway: 192.168.0.254
Realserver1: 192.168.0.3
Realserver1: 192.168.0.4
开启路由机制
vi /etc/sysctl.conf
net.ipv4.ip_forward = 1
sysctl -p
加载 rule
ipvsadm
ipvsadm
ipvsadm
ipvsadm
-C #清除以前的 rules
-A -t 192.168.0.200:80 -s rr
-a -t 192.168.0.200:80 -r 192.168.0.3:80 -i
-a -t 192.168.0.200:80 -r 192.168.0.4:80 -i
保存 rule
service ipvsadm save
邦定 vip
ifconfig eth0:0 192.168.0.200 netmask 255.255.255.255 up
RealServer 设置
Default Gateway 指向 Director 的 LAN IP 即 192.168.0.254
vi /etc/sysctl.conf
net.ipv4.ip_forward = 1
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
sysctl -p
ifconfig tunl0 192.168.0.200 netmask 255.255.255.255 up
route add -host 192.168.0.200 dev tunl0
echo `hostname` > /var/www/html/index.html
service httpd start
测试
选择一台主机访问 http:// 192.168.0.200 反复刷新网页,每次出现的网页不同则表示成功。
VS/DR
跟 VS/TUN 方法相同,负载调度器中只负责调度请求,而服务器直接将响应返回给客户,可以极大地提
高整个集群系统的吞吐量。跟 VS/TUN 相比,这种方法没有 IP 隧道的开销,但调度器和服务器组都必
须在物理上有一个网卡通过不分断的局域网相连,如通过交换机或者高速的 HUB 相连。VIP 地址为调
度器和服务器组共享,调度器配置的 VIP 地址是对外可见的,用于接收虚拟服务的请求报文;所有的服
务器把 VIP 地址配置在各自的 Non-ARP 网络设备上,它对外面是不可见的,只是用于处 理目标地址为
VIP 的网络请求。
以下是 LVS-DR 的工作原理,包括数据包、数据帧的走向和转换过程:
官方的原理说明:Director 接收用户的请求,然后根据负载均衡算法选取一台 realserver,将包转发
过去,最后由 realserver 直接回复给用户。
实例场景设备清单:
说明:我这里为了方便,client 是与 vip 同一网段的机器。如果是外部的用户访问,将 client 替换成
gateway 即可,因为 IP 包头是不变的,变的只是源 mac 地址。
1 client 向目标 vip 发出请求,Director 接收。此时 IP 包头及数据帧头信息如下:
2 VS 根据负载均衡算法选择一台 active 的 realserver(假设是 192.168.57.122),将此 RIP 所在网
卡的 mac 地址作为目标 mac 地址,发送到局域网里。此时 IP 包头及数据帧头信息如下:
3 realserver(192.168.57.122)在局域网中收到这个帧,拆开后发现目标 IP(VIP)与本地匹配,于是
处理这个报文。随后重新封装报文,发送到局域网。此时 IP 包头及数据帧头信息如下:
4 如果 client 与 VS 同一网段,那么 client(192.168.57.135)将收到这个回复报文。如果跨了网段,
那么报文通过 gateway/路由器经由 Internet 返回给用户。
Load Balance:192.168.0.254
Virtual IP: 192.168.0.200
Gateway: 192.168.0.254
Realserver1: 192.168.0.3
Realserver1: 192.168.0.4加载 rule
ipvsadm
ipvsadm
ipvsadm
ipvsadm
-C
#清空 ipvs 转发表
-A -t 192.168.0.200:80 -s rr
#-A:添加一个虚拟服务; -t:tcp 服务;-s:
-a -t 192.168.0.200:80 -r 192.168.0.3:80 -g
-a -t 192.168.0.200:80 -r 192.168.0.4:80 -g
保存 rule
service ipvsadm save
邦定 vip
ifconfig eth0:0 192.168.0.200 netmask 255.255.255.0 up
RealServer 设置
vi /etc/sysctl.conf
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
sysctl -p
ifconfig lo:0 192.168.0.200 netmask 255.255.255.255 up
route add -host 192.168.0.200 dev lo:0
echo `hostname` > /var/www/html/index.html
service httpd start
测试
访问 192.168.0.200 反复刷新网页,每次出现的网页不同则表示成功。
LVS 常见问题:
1. LVS/DR 如何处理请求报文的,会修改 IP 包内容吗?
1.1 vs/dr 本身不会关心 IP 层以上的信息,即使是端口号也是 tcp/ip 协议栈去判断是否正确,vs/dr 本
身主要做这么几个事:
1)接收 client 的请求,根据你设定的负载均衡算法选取一台 realserver 的 ip;
2)以选取的这个 ip 对应的 mac 地址作为目标 mac,然后重新将 IP 包封装成帧转发给这台 RS;
3)在 hashtable 中记录连接信息。
vs/dr 做的事情很少,也很简单,所以它的效率很高,不比硬件负载均衡设备差多少。
数据包、数据帧的大致流向是这样的:client --> VS --> RS --> client
1.2 前面已作了回答,vs/dr 不会修改 IP 包的内容.
2. RealServer 为什么要在 lo 接口上配置 VIP,在出口网卡上配置 VIP 可以吗?
2.1 既然要让 RS 能够处理目标地址为 vip 的 IP 包,首先必须要让 RS 能接收到这个包。
在 lo 上配置 vip 能够完成接收包并将结果返回 client。
2.2 答案是不可以将 VIP 设置在出口网卡上,否则会响应客户端的 arp request,造成 client/gateway
arp table 紊乱,以至于整个 loadbalance 都不能正常工作。
3. RealServer 为什么要抑制 arp 帧?这个问题在上一问题中已经作了说明,这里结合实施命令进一步阐述。我们在具体实施部署的时候都会
作如下调整:
echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2">/proc/sys/net/ipv4/conf/lo/arp_announce
echo "1">/proc/sys/net/ipv4/conf/all/arp_ignore
echo "2">/proc/sys/net/ipv4/conf/all/arp_announce
我相信很多人都不会弄懂它们的作用是什么,只知道一定得有。我这里也不打算拿出来详细讨论,只是
作几点说明,就当是补充吧。
3.1
echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce
这两条是可以不用的,因为 arp 对逻辑接口没有意义。
3.2 如果你的 RS 的外部网络接口是 eth0,那么
echo "1">/proc/sys/net/ipv4/conf/all/arp_ignore
echo "2">/proc/sys/net/ipv4/conf/all/arp_announce
其实真正要执行的是:
echo "1">/proc/sys/net/ipv4/conf/eth0/arp_ignore
echo "2">/proc/sys/net/ipv4/conf/eth0/arp_announce
所以我个人建议把上面两条也加到你的脚本里去,因为万一系统里上面两条默认的值不是 0,那有可能
是会出问题滴。
4. LVS/DR loadbalancer(director)与 RS 为什么要在同一网段中?
从第一个问题中大家应该明白 vs/dr 是如何将请求转发给 RS 的了吧?它是在数据链路层来实现的,所
以 director 必须和 RS 在同一网段里面。
5. 为什么 director 上 eth0 接口除了 VIP 另外还要配一个 ip(即 DIP)?
5.1 如果是用了 keepalived 等工具做 HA 或者 LoadBalance,则在健康检查时需要用到 DIP
5.2 没有健康检查机制的 HA 或者 Load Balance 则没有存在的实际意义.
6. LVS/DRip_forward 需要开启吗?
不需要。因为 director 跟 realserver 是同一个网段,无需开启转发。
7. lvs/dr 里,director 的 vip 的 netmask 没必要设置为 255.255.255.255,也不需要再去
route add -host $VIP dev eth0:0
director 的 vip 本来就是要像正常的 ip 地址一样对外通告的,不要搞得这么特殊.
LVS 的负载调度算法 在内核中的连接调度算法上,IPVS 已实现了以下八种调度算法:
一
轮叫调度(Round-Robin Scheduling )
轮叫调度(Round Robin Scheduling)算法就是以轮叫的方式依次将请求调度不同的服务器,
即每次调度执行 i = (i + 1) mod n,并选出第 i 台服务器。算法的优点是其简洁性,它无需记
录当前所有连接的状态,所以它是一种无状态调度。
二
加权轮叫调度(Weighted Round-Robin Scheduling )
加权轮叫调度 (Weighted Round-Robin Scheduling)算法可以解决服务器间性能不一的
情况,它用相应的权值表示服务器的处理性能,服务器的缺省权值为 1。假设服务器 A 的权值
为 1,B 的 权值为 2,则表示服务器 B 的处理性能是 A 的两倍。加权轮叫调度算法是按权值的高低和轮叫方式分配请求到各服务器。权值高的服务器先收到的连接,权值高的服 务器比权值
低的服务器处理更多的连接,相同权值的服务器处理相同数目的连接数。
三
最小连接调度(Least-Connection Scheduling )
最小连接调度(Least- Connection Scheduling)算法是把新的连接请求分配到当前连接数
最小的服务器。最小连接调度是一种动态调度算法,它通过服务器当前所活跃的连接数来估计
服务 器的负载情况。调度器需要记录各个服务器已建立连接的数目,当一个请求被调度到某台
服务器,其连接数加 1;当连接中止或超时,其连接数减一。
四
加权最小连接调度(Weighted Least-Connection Scheduling)
加权最小连接调 度(Weighted Least-Connection Scheduling)算法是最小连接调度的超
集,各个服务器用相应的权值表示其处理性能。服务器的缺省权值为 1,系统管理员可以动态
地设置服务器的权 值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其
权值成比例。
五
基于局部性的最少链接(Locality-Based Least Connections Scheduling )
基 于局部性的最少链接调度(Locality-Based Least Connections Scheduling,以下简称
为 LBLC)算法是针对请求报文的目标 IP 地址的负载均衡调度,目前主要用于 Cache 集群系统,
因为在 Cache 集群中 客户请求报文的目标 IP 地址是变化的。这里假设任何后端服务器都可以
处理任一请求,算法的设计目标是在服务器的负载基本平衡情况下,将相同目标 IP 地址的 请
求调度到同一台服务器,来提高各台服务器的访问局部性和主存 Cache 命中率,从而整个集群
系统的处理能力。LBLC 调度算法先根据请求的目标 IP 地址 找出该目标 IP 地址最近使用的服
务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服
务器超载且有服务器处于其一半的工 作负载,则用 “ 最少链接 ” 的原则选出一个可用的服务器,
将请求发送到该服务器。
六
带复制的基于局部性最少链接(Locality-Based Least Connections with
Replication Scheduling)
带 复制的基于局部性最少链接调度(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 集群系统的使用效率。LBLCR 算法
先根据请求的目标 IP 地址找出该目标 IP 地址对应的服务器组;按 “ 最小连接 ” 原则从该服务器
组中选出一台服务器,若服务器没有超载,将请求发送到该服务器;若服务器超载;则按 “ 最
小连接 ” 原则从整个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服
务器。同时,当该服务器组有一段时间没有被修改,将最忙的服 务器从服务器组中删除,以降
低复制的程度。
七
目标地址散列调度(Destination Hashing Scheduling )
目标地址散列调度 (Destination Hashing Scheduling)算法也是针对目标 IP 地址的负载均衡,但它是一种静态映射算法,通过一个散列(Hash)函数将一个目标 IP 地址映射到一台
服务 器。目标地址散列调度算法先根据请求的目标 IP 地址,作为散列键(Hash Key)从静态
分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否
则返回空。
八
源地址散列调度(Source Hashing Scheduling)
源地址散列调度(Source Hashing Scheduling)算法正好与目标地址散列调度算法相反,
它根据请求的源 IP 地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,
若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。它采用的散列函数与目
标地址散列调度算法 的相同。它的算法流程与目标地址散列调度算法的基本相似,除了将请求
的目标 IP 地址换成请求的源 IP 地址,所以这里不一一叙述。在实际应用中,源地址散列 调度
和目标地址散列调度可以结合使用在防火墙集群中,它们可以保证整个系统的唯一出入口。