LVS 特性介绍:
1 属于四层调度 [物理层 | 数据链路层 | 网络层 | 传输层]
不需要解封装, 但不能识别报文数据, 速度快, 性能好!
2 高可用性实现方式 --keepalived
3 工作原理:
LVS 根据请求报文的目标 IP 和目标协议及端口将其调度转发至某 RS, 根据调度 算法来挑选 RS
4 工作位置: INPUT 链之前
5 专用术语简介:
VS:Virtual Server,Director Server(DS) -- 调度器
- Dispatcher(调度器),Load Balancer
- RS:Real Server(lvs), upstream server(nginx)
backend server(haproxy) -- 后端服务器
CIP:Client IP -- 客户端拥有的 IP 地址
VIP: Virtual serve IP VS 外网的 IP
DIP: Director IP VS 内网的 IP
RIP: Real server IP 后端服务器 IP
6 访问流程简述:
CIP <--> VIP == DIP <--> RIP
7 命令行管理工具: ipvsadm
8 工作于内核级别, 支持并发访问量大
验证内核支持 LVS
- [root@KEEP208:56:43~]#cat /boot/config-3.10.0-862.el7.x86_64 | grep -i "ipvs"
- CONFIG_NETFILTER_XT_MATCH_IPVS=m
- # IPVS transport protocol load balancing support
- # IPVS scheduler
- # IPVS SH scheduler
- # IPVS application helper
LVS 四种模型简介: NAT
lvs-nat: 修改请求报文的目标 IP, 多目标 IP 的 DNAT
解析:
本质是多目标 IP 的 DNAT, 通过将请求报文中的目标地址和目标端口修改为某挑出的 RS 的 RIP 和 PORT 实现转发
(1) RIP 和 DIP 应在同一个 IP 网络 [也可以跨网段], 且应使用私网地址; RS 的网关要指向 DIP
(2) 请求报文和响应报文都必须经由 LVS 转发, LVS 易于成为系统瓶颈
(3) 支持端口映射, 可修改请求报文的目标 PORT
(4)VS 必须是 Linux 系统, RS 可以是任意 OS 系统
LVS 四种模型简介: DR
lvs-dr: 操纵封装新的 Mac 地址 默认模式
解析:
LVS-DR:Direct Routing, 直接路由, LVS 默认模式, 应用最广泛
通过为请求报文重新封装一个 Mac 首部进行转发, 源 Mac 是 DIP 所在的接口的 Mac
目标 Mac 是某挑选出的 RS 的 RIP 所在接口的 Mac 地址; 源 IP/PORT, 以及目标 IP/PORT 均保持不变
1 LVS 和各 RS 都配置有 VIP
2 确保前端路由器将目标 IP 为 VIP 的请求报文发往 LVS
方式 1:
在前端网关做静态绑定 VIP 和 LVS 的 Mac 地址
方式 2:
在 RS 上使用 arptables 工具
- arptables -A IN -d $VIP -j DROP
- arptables -A OUT -s $VIP -j mangle --mangle-ip-s $RIP
方式 3:
在 RS 上修改内核参数以限制 arp 通告及应答级别
忽略 apr 广播:
/proc/sys.NET/ipv4/conf/all/arp_ignore --1
不宣称自己有这段 IP:
/proc/sys.NET/ipv4/conf/all/arp_announce --2
后端服务器也设置 vip 一样的 IP 地址
配置解析:
限制响应级别: arp_ignore
0: 默认值, 表示可使用本地任意接口上配置的任意地址进行响应
1: 仅在请求的目标 IP 配置在本地主机的接收到请求报文的接口上时, 才给予响应
限制通告级别: arp_announce
0: 默认值, 把本机所有接口的所有信息向每个接口的网络进行通告
1: 尽量避免将接口信息向非直接连接网络进行通告
2: 必须避免将接口信息向非本网络进行通告
参数其它配置:
- [root@KEEP211:01:29~]#find /proc -name *arp_ign*
- /proc/sys.NET/ipv4/conf/all/arp_ignore
- /proc/sys.NET/ipv4/conf/default/arp_ignore
- /proc/sys.NET/ipv4/conf/eth0/arp_ignore
- /proc/sys.NET/ipv4/conf/eth1/arp_ignore
- /proc/sys.NET/ipv4/conf/lo/arp_ignore
- ........................................................
- [root@KEEP211:47:29~]#find /proc -name *arp_announce*
- /proc/sys.NET/ipv4/conf/all/arp_announce
- /proc/sys.NET/ipv4/conf/default/arp_announce
- /proc/sys.NET/ipv4/conf/eth0/arp_announce
- /proc/sys.NET/ipv4/conf/eth1/arp_announce
- /proc/sys.NET/ipv4/conf/lo/arp_announce
vip 配置在 lo 接口上!
举例:
ip a a 1.1.1.1/32 dev lo -- 要配置 32 的子网掩码
--- 加默认路由 route add default dev eth0
ping -I 1.1.1.1 1.1.1.2 -- 指定从本机那个 IP -ping 对方
DR 模型特点:
1 RS 的 RIP 可以使用私网地址, 也可以是公网地址;
2 RIP 与 DIP 在同一 IP 网络; RIP 的网关不能指向 DIP, 以确保响应报文不会经由 Director
3 RS 和 LVS 一个物理网络
4 请求报文要经由 LVS, 相应报文不经过 LVS
而由 RS 直接发往 Client
5 不支持端口映射 - 端口不能修改
6 RS 可使用大多数 OS 系统
DR 模型不用启用 ip_forward 功能
NAT 模型必须要启用此功能
LVS 四种模型简介: tun
lvs-tun: 在原请求 IP 报文之外新加一个 IP 首部
转发方式: 不修改请求报文的 IP 首部 (源 IP 为 CIP, 目标 IP 为 VIP)
而在原 IP 报文之外再封装一个 IP 首部 (源 IP 是 DIP, 目标 IP 是 RIP)
将报文发往挑选出的目标 RS;RS 直接响应给客户端 (源 IP 是 VIP, 目标 IP 是 CIP)
(1) DIP, VIP, RIP 都应该是公网地址
(2) RS 的网关一般不能指向 DIP
(3) 请求报文要经由 Director, 但响应不能经由 Director
(4) 不支持端口映射
(5) RS 的 OS 须支持隧道功能
LVS 四种模型简介: lvs-fullnat
lvs-fullnat:
通过同时修改请求报文的源 IP 地址和目标 IP 地址进行转发
- CIP --> DIP
- VIP --> RIP
(1) VIP 是公网地址, RIP 和 DIP 是私网地址, 且通常不在同一 IP 网络;
因此 RIP 的网关一般不会指向 DIP
(2) RS 收到的请求报文源地址是 DIP, 因此只需响应给 DIP;
但 Director 还 要将其发往 Client
(3) 请求和响应报文都经由 LVS
(4) 支持端口映射
注意: 此类型 kernel 默认不支持
模式之间差异总结:
差异总结:
lvs-nat 与 lvs-fullnat: 请求和响应报文都经由 Director
lvs-nat:RIP 的网关要指向 DIP
lvs-fullnat:RIP 和 DIP 未必在同一 IP 网络, 但要能通信
lvs-dr 与 lvs-tun: 请求报文要经由 Director, 但响应报文由 RS 直接发往 Client
lvs-dr: 通过封装新的 Mac 首部实现, 通过 Mac 网络转发
lvs-tun: 通过在原 IP 报文外封装新 IP 头实现转发, 支持远距离通信
对比项 NAT TUN DR
后端服务器 任何服务器 必须支持隧道 关闭 apr 广播
服务器网络 私网 / 公网 私网 / 公网 局域网
后端服务器数量 10--20 最大 100 最大 100
服务器网关: 指向 LVS 其它路由 其它路由
LVS 十种算法: 静态算法
1,RR:roundrobin, 轮询
2,WRR:Weighted RR, 加权轮询
自己的权重 / 总权重
3,SH:Source Hashing, 实现 session sticky, 源 IP 地址 hash;
将来自于同一个 IP 地址的请求始终发往第一次挑中的 RS, 从而实现会话绑定
4,DH:Destination Hashing; 目标地址哈希, 将发往同一个目标地址的请求始终转发至第一次挑中的 RS,
典型使用场景是正向代理缓存场景中的负载均衡, 如: 宽带运营商
LVS 十种算法: 动态算法
1,LC:least connections 适用于长连接应用 [最小连接算法]
Overhead=activeconns*256+inactiveconns
活动连接 * 256 + 非活动连接
值越小优先级越高!
2,WLC:Weighted LC, 默认调度方法
Overhead=(activeconns*256+inactiveconns)/weight
(活动连接 * 256 + 非活动连接)/ 权重
值越小优先级越高!
权重越大, 值越小, 优先级越高
第一个请求过来时, 为 0
3,SED:Shortest Expection Delay, 初始连接高权重优先
Overhead=(activeconns+1)*256/weight
(活动连接 + 1)*256 / 权重
4,NQ:Never Queue, 第一轮均匀分配, 后续 SED
5,LBLC:Locality-Based LC, 动态的 DH 算法,
使用场景: 根据负载状态实现 正向代理
6,LBLCR:LBLC with Replication, 带复制功能的 LBLC,
解决 LBLC 负载不均衡 问题, 从负载重的复制到负载轻的 RS
来源: http://www.bubuko.com/infodetail-2848903.html