深入理解Keepalived+LVS

487次阅读

共计 5595 个字符，预计需要花费 14 分钟才能阅读完成。

keepalived 篇：

master 和 bakeup 之间的通信(vrrp 协议)
master : 172.25.88.1
bakeup :172.25.88.2

1. 在 matser 上抓 vrrp 的包
[root@server1 ~]# /etc/init.d/keepalived start
Starting keepalived: [OK]
[root@server1 ~]# tcpdump vrrp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:07:23.710761 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20
15:07:24.711710 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20
15:07:25.712926 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20
15:07:26.713916 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20
15:07:27.714890 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20
发现 master 在向 224.0.0.18 发送广播包，分析包文的值优先级为 102，是我们的 master

2. 在 bakeup 上抓 vrrp 的包
[root@server2 ~]# /etc/init.d/keepalived start
Starting keepalived: [OK]
[root@server2 ~]# tcpdump vrrp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:07:38.022848 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20
15:07:39.023899 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20
15:07:40.024861 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20
15:07:41.025770 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20
15:07:42.026831 IP 172.25.88.1 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 102, authtype simple, intvl 1s, length 20
由此发现，master 工作时，bakeup 不发送 vrrp 包，只是接受并返回 master 的包

3. 将 master 的 keepalived down 了
[root@server1 ~]# /etc/init.d/keepalived stop
Stopping keepalived: [OK]
再次抓包

[root@server1 ~]# tcpdump vrrp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:22:43.293115 IP 172.25.88.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 52, authtype simple, intvl 1s, length 20
15:22:44.293714 IP 172.25.88.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 52, authtype simple, intvl 1s, length 20
15:22:45.294471 IP 172.25.88.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 188, prio 52, authtype simple, intvl 1s, length 20
由优先级 prio 52 可知，现在已经是 bakeup 在组播 vrrp 包。

总结：master 只发不收，bakeup 反之
其他主机也收不到 vrrp 包，因为有 route_id 限制

关于接管

BACKUP 在确认没有收到 MASTER 的广播报文后，会主动发送组播报文，声明自己的 keepalived 状态，随后启用 VIP。正式接管 keepliaved。

关于谁来当 master

1. 当两个 state 均为 master 时，prio 大的为 master
2. 当两个 state 均为 master 时且 prio 优先级相同时，双方都认为自己是 master，双方会出现抢占 ip 的情况，导致地址冲突。

特殊说明

1. 实现不回切 bakeup

vim /etc/keepalived/keepalived.conf

29 no preempt 非抢占模式
30 priority 150 且 proi 要比 master 大，我的 master 的 proi 为 100

2. 主备的 virtual_router_id 要相同，否则都会发组播报文

virtual_router_id 188

LVS 篇

lvs-why

传统:DNS 负载均衡缺点:

1. 服务调度算法只支持 WRR
2. 攻击防御能力很弱，每次有攻击靠一台机器抗。
3. 如果 server 宕了, 运维就只能把 server 的 ip 从 DNS 中删除, 但 localDNS 有大量的缓存, 至于删除操作什么时候生效不可控.

工作机制

我们都知道 netfilter 加载 iptables 模块，实现了防火墙。

其实 lvs，就是 netfilter 加载 ipvs 模块实现的！

lvs 分为 ipvs（内核）和 ipvsadm（用户空间）两部分：

用户用过 ipvsadm 编写策略，而内核加载 ipvs 在 netfilter 生效！

ipvs 结合 input 链（钩子函数在链上）工作，发现用户请求的是一个集群服务，就转发至 forward，转发至 postrouting 链，进入 RS（后端服务器）。

类型

1.nat 地址转换
定义：多目标的 dnat（目标地址转换）
cip->vip->rip->vip->cip

深入理解 Keepalived+LVS

进出的连接都要经过 DS，DR 压力大，只能负载均衡 10 个 rs 左右。

rule：

）DR 和 RS 必须在同一个网络中。
2）RS 网关指向 DIP，因为 DR 要修改目的地址由 VIP->RIP
3）RIP 为私有地址，仅用于集群通信。
4）DR 位于 client 和 real server 之间，负责处理所有通信，亚历山大，成为瓶颈。
5）DR 支持端口映射。
6）RS 可以使用任意系统
7) NAT 模式可以防 DDOS

2.dr 直接路由

原理：DS 在数据链路层直接修改 mac 地址，源 IP 和目标 IP 都没有改变

深入理解 Keepalived+LVS

只有进入的连接经过 DS，能负载均衡 100 个 rs 左右。
DS:dip,vip
RS:rip,vip
vip 是隐藏的，仅仅作为源地址不通信。可以配置在 lo 上，或者设置 arp 防火墙，
通信还是靠 rip 所在的网络设备

rule：

1）DR 和 RS 必须在同一个物理网络中（同一网段）
2）RS 一定网关不能指向 DIP。
3）RIP 不一定是私有地址，可以 ssh 上来管理，但有危险。
4）DR 仅处理入栈请求，响应报文由 RS 发往 client。
5）DR 不支持端口映射，因为请求端口的时候，RS 直接响应。
6）RS 可以使用大多数操作系统，因为 RS 要隐藏 vip。。

3.tun 隧道

基本同 DR，但转发的时候，要封装隧道，再添加一个 ip 首部。

rule：

1）DR 和 RS 必须可以跨越互联网
2）RIP 必须是公网地址
3）DR 仅处理入栈请求，响应报文由 RS 发往 client。
4）响应报文一定不能通过 DR
5）不支持端口映射 6）RS 必须支持隧道协议 OS4.fullnat

调度算法（schedule method）

分为静态和动态：动态则考虑服务器的负载。

静态调度算法（4 个）

1.rr（轮叫调度）

2.wrr（加权轮叫）

3.sh（源地址哈希）：基于 session 的会话绑定。一个用户访问过某个 RS，下次访问就由这个 RS 给他提供服务。

4.dh（目的地址哈希）：不同用户，相同的访问需求，就访问同一个 RS。

活动链接（active）：客户与服务器建立连接并且有数据传送

非活动链接（inactive）：只是建立连接，没有数据传送，没有断开连接

动态调度算法（6 个）

1.lc（最少链接）：

算法：active*256 + inactive

因为在实际生产环境中，inactive 的数量是巨大的，所以不能忽略

2.wlc（加权最少链接）LVS 的默认算法

算法：active*256+inactive）/weight 比 lc 多考虑了权重

3.sed（最短期望延迟）

基于 wlc 算法，避免 wlc 出现的问题。

算法：（active+1)*256/weight（活动的连接数 +1）*256/ 除以权重谁小发给谁

4.nq（用不排队）

谁的链接数为 0，直接将请求发送给他，一般和 sed 结合使用，因为有些机器即使空着也调度不到他。

5.LBLC（基于本地的最少连接）类似于 dh，目标地址 hash

这个算法主要用于 Cache 集群系统，因为 Cache 集群的中客户请求报文的目标 IP 地址的变化，将相同的目标 URL 地址请求调度到同一台服务器，来提高服务器的访问的局部性和 Cache 命中率。从而调整整个集群的系统处理能力。但是，如果 realserver 的负载处于一半负载，就用最少链接算法，将请求发送给活动链接少的主机。

6.LBLCR（带复制的基于本地的最少链接）

该算法首先是基于最少链接的，当一个新请求收到后，一定会将请求发给最少连接的那台主机的。但这样又破坏了 cache 命中率。但这个算法中，集群服务是 cache 共享的，假设 A 的 PHP 跑了一遍，得到缓存。但其他 realserver 可以去 A 那里拿缓存，这是种缓存复制机制。

各种术语

DS：Director Server。前端负载均衡调度器。

RS：Real Server。后端真实工作的服务器。

VIP：向外部直接面向用户请求，作为用户请求的目标的 IP 地址。

DIP：Director Server IP，主要用于和服务器内部通讯的 IP。

RIP：Real Server IP，后端真实服务器的 IP 地址。

CIP：Client IP，客户端的 IP 地址。

端口映射：如用户访问 80，可在 RS 上服务实际工作在 8080。（只有 dnat 支持）

一些关于 Keepalived 相关教程集合：

CentOS 7 下 Keepalived + HAProxy 搭建配置详解 http://www.linuxidc.com/Linux/2017-03/141593.htm