LB简介
-
LB=Load Blancing，即负载均衡；
-
就是将负载（工作任务）进行平衡、分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器等，从而共同完成工作任务的机制；
-
负载均衡设备不是基础网络设备，而是一种性能优化设备；
-
对于网络应用而言，并不是一开始就需要负载均衡，当网络应用的访问量不断增长，单个处理单元无法满足负载需求时，网络应用流量将要出现瓶颈时，负载均衡才会起到作用
LB分类
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
# 一般分类：
tcp层：LVS，Haproxy
应用层：Nginx，Haproxy，Ats
缓存：Varnish，Squid
# 开源解决方案：
LVS：工作于tcp层，性能好，但控制力差
Haproxy：工作于tcp或http层
Nginx：较Haproxy性能欠佳，但缓存能力较好
# 硬件解决方案：
BIG-IP(F5公司)
Netscaler(Citrix公司)
A10(A10公司)
Array
Redware
|
LVS简介
-
LVS=Linux Virtual Server，意即Linux虚拟服务器，是一个虚拟的服务器集群系统；
-
本项目在1998年5月由章文嵩博士成立，是中国国内最早出现的自由软件项目之一；
LVS组成
-
ipvs：框架，需要依赖于规则完成转发；工作于内核的INPUT链上；相当于iptables/netfilter中的netfilter
-
在INPUT链上强行将发送至本机的连接转发至POSTROUTING链；
-
与DNAT不同的是：在经过ipvs处理后，目标IP地址并不一定会修改；
-
ipvs提供集群服务(如172.16.100.7:80)，定义一个或多个后端服务器RS
-
ipvsadm：用户空间的规则生成器
-
注：LVS工作于tcp/udp层，故又称为四层交换、四层路由
LVS基本结构图
LVS 4大模型
NAT：多目标的DNAT
特性：
-
RS应该使用私有地址；
-
RS的网关必须指向DIP；
-
RIP和DIP必须在同一网段内；
-
请求和响应的报文都得经过Director；（在高负载应用场景中，Director很可能成为系统性能瓶颈）
-
支持端口映射；
-
RS可以使用任意支持集群服务的OS(如Windows)
适用场景：
-
非高并发请求场景，10个RS以内；可隐藏内部的DIP和RIP地址；
结构图
DR：Direct Routing
需解决的关键问题：
-
让前端路由将请求发往VIP时，只能是Director上的VIP进行响应；实现方式是修改RS上的Linux内核参数，将RS上的VIP配置为lo接口的别名，并限制Linux仅对对应接口的ARP请求做响应
特性：
-
RS可以使用私有地址，但也可以使用公网地址，此时可以直接通过互联网连入RS以实现配置，监控等；
-
RS的网关一定不能指向DIP；
-
RS和Director要在同一物理网络(即不能由路由器分隔)
-
请求报文经过Director，但响应报文一定不进过Director；
-
不支持端口映射；
-
RS可以使用大多数的操作系统
适用场景：
-
因为响应报文不经过Director，极大的减轻了Director的负载压力，故Director可以支持更大的并发访问，一般RS在100台以内；
结构图：
LVS-DR配置架构根据其VIP与RIP是否在同一个网段内又分为两种模型
TUN：IP隧道，即含有多个IP报头
特性：
-
RIP、DIP、VIP都得是公网地址；
-
RS的网关不会指向也不可能指向DIP；
-
请求报文经过Director，但响应报文一定不经过Director；
-
不支持端口映射；
-
RS的操作系统必须得支持隧道功能，即部署ipip模块
适用场景：
-
跨互联网的请求转发
结构图：
FULLNAT：NAT模型的改进版
特性：
-
实现RS间跨VLAN通信，是NAT模式的改进版；
-
默认内核不支持，需重新编译内核，才能使用；
适用场景：
-
内网服务器跨VLAN的负载分担
结构图：
LVS调度算法
静态方法：仅根据算法本身进行调度
|
1
2
3
4
|
rr：Round Robin
# 即轮询
wrr：Weighted RR
# 即加权轮询
sh：Source Hashing
# 即来源IP地址hash
dh：Destination Hashing
# 即目标地址hash（不常用，仅用于前端多防火墙的场景，保证防火墙的连接追踪功能有效）
|
动态方法：根据算法及RS当前的负载情况
|
1
2
3
4
5
6
7
8
9
10
11
12
|
lc：Least Connection
# 评判标准：Overhead=Active*256+Inactive
# Overhead最小者胜出
wlc：Weighted LC
# 评判标准：Overhead=(Active*256+Inactive)/weight
# Overhead最小者胜出
sed
：Shortest Expect Delay
# 评判标准：Overhead=(Active+1)*256/weight
# Overhead最小者胜出
nq：Never Queue
# 集群开始时工作时，每台服务器都至少分配一个连接请求，然后再根据sed算法调度；
lblc：Locality-based Least Connection
# 类似于dh+lc
lblcr：Relicated and Locality-based Least Connection
# 主要用于后端服务器是缓存服务器时
|
LVS持久连接
简介
-
无论LVS采用何种调度算法，都可以在一段时间内，将客户端的请求发往同一个后端RS；
类型
-
PCC=Persistent client connections：
-
将来自于同一客户端发往VIP的所有请求统统定向至同一RS；
-
-
PPC=Persistent port connections：
-
将来自于同一客户端发往某VIP的某端口的所有请求统统定向至同一个RS；针对特定服务特定端口转发的；
-
-
PFMC=Persistent Filewall Mark Connection
-
基于防火墙标记，将两个或以上的端口绑定为同一个服务
-
防火墙标记是0-99间的整数
-
实现：编写LVS规则时，加上-p选项即可
|
1
2
3
4
5
6
|
PCC：ipvsadm -A -t 172.16.100.7:0 -s rr -p 120
# 端口为0表示全部端口
PPC：ipvsadm -A -t 172.16.100.7:80 -s rr -p 120
PFMC：
# 首先需要利用iptables将相关的服务打上标签：
iptables -t mangle -A PREROUTING -d 172.16.100.8 -p tcp --dport 80 -j MARK --
set
-mark 10
iptables -t mangle -A PREROUTING -d 172.16.100.8 -p tcp --dport 443 -j MARK --
set
-mark 10
ipvsadm -A -f 10 -s rr -p 1200
|
注：若LVS集群中存储的持久连接模板(即连接记录)倒计时归0了，则判断当前是否还有连接，若还有连接，则此模板就延时失效，每次延迟2min，直至连接断开
