Keepalived

LVS集群的缺点

LVS能够实现四层负载，能够支持足够大的并发量，但使用LVS负载均衡集群有以下两个缺点。

① 如果调度器（Director）挂了（不可用），将会导致整个系统不可用，从而调度器成为了单点故障（SPOF）。

② 调度器（Director）无法对后端RealServer做健康状态检测。因此，如果后端的某一台RealServer挂了，前端调度器将无法得知，仍然会向该RealServer调度请求，导致服务不可用；另外，如果某一台挂了的RealServer但已经恢复正常并重新提供服务时，前端调度器也无法得知，并将其加入调度队列。

因此，为了能够使前端调度器（Director）能够冗余、使Director能够对后端各RS做健康状态检测，并按需增删RS，需要引入高可用集群的解决方案。以下介绍的是Keepalived高可用软件。

Keepalived的介绍

什么是keepalived呢？keepalived是实现高可用的一种轻量级的技术手段，主要用来防止单点故障(单点故障是指一旦某一点出现故障就会导致整个系统架构的不可用)的发生。

Keepalived的高可用功能是通过VRRP协议实现的，VRRP是Virtual Router Redundancy Protocol（虚拟路由器冗余协议）的缩写。VRRP的出现是为了解决静态路由单点故障的问题，当某一节点出现故障时，可以防止导致整个网络不可用。Keepalived除了可以高可用LVS之外，还可以作为其他系统网络服务（Nginx、Haproxy等）的高可用解决方案（Keepalived可通过调用vrrp_script来高可用其它服务，并通过调用vrrp_track来追踪每一个服务）。

Keepalived的功能

Keepalived有三个重要功能，如下。

  • 高可用系统网络服务。

Keepalived可以实现在两台或多台主机之间的故障切换转移。如果在两台主机中都安装了Keepalived，当正常工作时，有一台主机工作为Master角色，另一台主机工作为Backup角色。角色为Master的主机获得所有资源（VIP资源、服务资源）并向用户提供服务，角色为Backup的主机不提供服务而仅作为Master主机的热备。当角色为Master的主机出现故障时，角色为Backup的主机将自动接管Master主机的所有资源（VIP资源、服务资源）并开始工作。当Master主机故障修复完成时，将重新接管原来的资源和工作，而Backup主机则释放Master主机故障时它接管的资源和工作，各自恢复原来的角色。

  • 实现对LVS集群中各RealServer的健康状态进行检测。

Keepalived可以通过在自身配置文件keepalived.conf中配置LVS集群服务中各台RealServer的IP地址和相关参数，并可以通过网络层、传输层和应用层这三层进行探测各RealServer的健康状态。当有一台或多台RealServer出现故障而无法提供服务时，Keepalived服务可以把出现故障的RealServer从LVS的正常转发队列中移除，保证不影响用户的访问。而当有RealServer故障修复完成时，Keepalived服务可以将其重新加入LVS的正常转发队列中，向用户提供服务。

  • 管理LVS负载均衡软件

Keepalived可以读取配置文件，并通过一个更为底层的接口来管理IPVS并生成IPVS规则，这使得LVS的使用更为方便。

Keepalived工作原理

前面提到，Keepalived的高可用功能是通过VRRP协议实现的，要了解Keepalived的工作原理，需要先了解VRRP协议的工作原理。

VRRP

​ VRRP是一种容错性协议，它是通过将多台设备虚拟化成一台设备，如果其中一台设备出现故障，那么另一台设备可以迅速接替其工作，已保证通讯的可靠性和连续性。

​ 1.工作原理

​ 在企业网当中，PC一般是需要使用”网关”来与外部网络进行通讯，这样如果网关出现了故障那么整一个子网的对外通讯都会被切断，VRRP的出现就能把这个问题很好地解决了，VRRP可以通过把多台设备（路由器、交换机、防火墙等）虚拟化成一台设备，然后通过配置虚拟IP地址作为网关就能实现对网关的备份（这虚拟IP地址是代表整个VRRP组内的所有设备），当其中一台设备出现故障之后，VRRP组内其他设备会通过某些机制来接替故障设备的工作。

VRRP概念

虚拟设备：由一个”主（Master）”设备和多个”备（Backup）”设备组成的一个虚拟网关。

主设备（Master）：负责转发数据报文和周期性向备设备发送VRRP协议报文。

备设备（Backup）：不负责转发数据报文，在Master设备发生故障的时候会通过选举形式成为新的Master设备，该角色会接收来自Master设备的VRRP报文并加以分析。

VRID：用来表示一个VRRP组。

虚拟IP：配置在虚拟设备上的虚拟IP地址，一个虚拟设备可以拥有一个或者多个虚拟IP地址。

IP地址拥有者：分配给虚拟设备的虚拟IP的真实拥有者（例如：分配个虚拟路由的IP为192.168.1.1，但是这个IP已经分配给物理接口G0/0/1这个接口那么这个接口就是”IP拥有者”），IP拥有者会直接跳过选举成为Master，并且是不可抢占的。

虚拟MAC地址：由虚拟设备生成的虚拟MAC地址，每一个虚拟设备都会自动生成一个虚拟MAC地址，这个MAC地址是用于虚拟设备处理ARP报文的。

优先级：用于表示物理设备的优先级，这个参数用于Master的选举，取值范围是1-254，这个有优先级有两个比较特殊的值，分别是0和255，优先级0是由原来Master设备发送的，这个优先级是声明此设备不再参与VRRP组。优先级为255的是IP拥有者的优先级，拥有这个优先级会直接成为Master。（优先级数值越低优先级则越高）

抢占模式：当Backup 设备接收到的VRRP报文通过分析得出当前Master设备的优先级低于Backup设备，则Backup设备会切换为Master设备。

工作流程

VRRP备份组会通过优先级选举出Master，Master会使用虚拟MAC发送ARP报文，使与Master连接的主机或者客户端建立与虚拟MAC对应的ARP映射表，同时Master会周期性发布VRRP报文向所有Backup通告其配置信息与工作状态。

如果当前Master出现故障，Backup设备将会在MASTER_DOWN_INTERVAL定时器超时或者其他联动技术检测到Master出现故障时则会根据Backup组内的成员的优先级选举出新的Master，如果Backup只有一台设备则直接成为Master。

新的Master使用虚拟MAC发送ARP报文，使连接在当前VRRP组内的客户端或者设备刷新其ARP映射表。

如果原来的Master从故障中恢复过来，如果其优先级为255则会直接切换到Master，若不是则会恢复到Backup状态，如果当前为抢占模式，当原Master接收到新Master的VRRP报文发现其优先级高于原Master则原Master会直接成为Master。如果处于非抢占模式，则原Master会在新Master出现故障时通过选举等方式成为Master。

VRRP选举

VRRP通过优先级来确定设备成为Master或者Backup，优先级取值越低，则优先级越高。

初始创建的VRRP设备都处于初始状态，在该状态下，如果设备的优先级为255，则直接成为Master并且跳过接下来的选举，若不是则会切换到Backup状态，然后会等待MASTER_DOWN_INTERVAL超时后成为Master。

首先切换到Master的设备会通过VRRP报文获取其他设备的优先级，然后通过以下规则进行选举：

  1. 如果Backup设备接收到来自Master的VRRP报文，发现其优先级数值低于自身，则继续处于Backup状态。
  2. 如果Backup设备接收到来自Master的VRRP报文，发现其优先级数值高于自身，则当前Backup设备会切换到Master，而原Master设备会切换到Backup。如果在非抢占模式下，Backup设备仍然会处于Backup状态。
  3. 如果同时有多个设备切换到Master，则会互相通过VRRP报文确定其优先级，优先级高的则成为Master，若优先级一样，则对比IP地址，IP地址大的则成为Master。

VRRP状态通告

Master设备会周期性发送VRRP报文，通告其配置信息与工作状态，Backup则会接收并处理VRRP报文确定Master设备的工作状态。

当Master主动退出VRRP组是，会发送优先级为0的报文通知所有的Backup设备，Backup设备接收到之后会直接切换到Master状态，若Backup组内有多台设备则通过上述选举选出新的Master设备，而不需要等待MASTER_DOWN_INTERVAL超时后再进行切换或者选举。

当Master设备由于故障不能发送VRRP报文，所有的Backup设备都需要等待MASTER_DOWN_INTERVAL 超时后才会认为Master设备出现故障，之后才切换到Master。

如何保证单台服务器的可靠性

可以借用VRRP的两种模式

  • 主备备份模式

  • 负载分担模式

主备备份模式：

主备备份模式就是只由Master设备负责转发数据，而Backup设备则处于待机备份模式不参与数据转发，当Master设备出现故障时才会切换到Master进行数据转发。

参照下图，正常情况下只有SW1转发数据，而SW2则处于待机状态，SW1会周期发送VRRP报文告知SW2自身的配置信息和工作状态，如果SW1发生故障，则SW2会自动切换到到Master继续进行数据转发等。

而当SW1恢复之后，若当前为抢占模式，若SW1的优先级为255那么SW1会直接成为Master否则会先切换到Backup然后再切换到Master。

graph TD
A[pc]  
      A --> |客户端的情求| C[SW3]
      C -->  B[Master   SW1]
      C -->  f[Backup SW2]
      B --> c[SW3]
      f --> c[R]

负载分担模式：

上述的主备备份模式，若SW1一直正常工作，那么SW2则长期处于待机状态，显然这种做法比较浪费，所以一般会采用负载分担模式，负载分到模式会是SW2都处于工作状态。

参照下图，负载分担模式是创建两个VRRP组分别为A组和B组，A组的Master为SW1，Backup为SW2，而B组的Master为SW2，Backup为SW1，通过创建多个拥有不同虚拟IP的VRRP组，为不同的VLAN指定网关实现负载分担。

graph TD

A[pc1]  
      D[pc2]
      A --> |客户端的情求| C[SW3]
      D --> |客户端的情求| C[vlan 10 192.168.10.1 
 vlan 20   192.168.20.1
  SW3]
      C -->  B[Master:vlan 10 
 backup:vlan 20 
  SW1]  
      C -->  f[Master:vlan 20 
 backup:vlan 10 
  SW2]
      f --> E[R]
      B --> E[R]

参照上图，在VLAN10当中Master是SW1，Backup为SW2，两台交换机都分别创建vlan10和vlan20 并且分配好IP地址，正常情况下vlan10的客户端会通过SW1访问R1，vlan20的客户端会通过SW2访问R1这样就实现了负载分担，如果SW1出现故障，那么SW2会成为vlan10的Master（同时也是vlan20的Master），接替SW1的工作，而vlan10的客户端也会通过SW2访问R1，而SW2故障则同理。

Keepalived的配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
主备服务安装Keepalived
	yum install keepalived ipvsadm -y
	
 修改配置文件：
		cd  /etc/keepalived/
		cp keepalived.conf keepalived.conf.bak
		vi keepalived.conf

			node01:
			vrrp：虚拟路由冗余协议！
				vrrp_instance VI_1 {
					state MASTER     //MASTER/ BACKUP
					interface eth0  //网关接口
					virtual_router_id 51
					priority 100 //权重配置	100/ 50
					advert_int 1
					authentication {
						auth_type PASS
						auth_pass 1111
					}
					virtual_ipaddress {
						192.168.150.100/24 dev eth0 label  eth0:3     //虚拟IP
					}
				}
//配置入包规则
			virtual_server 192.168.150.100 80 {
				delay_loop 6
				lb_algo rr   //负载机制  rr轮询
				lb_kind DR   //模式
				nat_mask 255.255.255.0
//在50秒内如果同一个用户有多次的请求发送过来则向固定的一台服务负载
				persistence_timeout 50  
				protocol TCP
// 出包规则
				real_server 192.168.150.12 80 {
					weight 1
					HTTP_GET {
						url {
						  path /
						  status_code 200
						}
						connect_timeout 3
						nb_get_retry 3
						delay_before_retry 3
					}   
				}       
				real_server 192.168.150.13 80 {
					weight 1
					HTTP_GET {
						url {
						  path /
						  status_code 200
						}
						connect_timeout 3
						nb_get_retry 3
						delay_before_retry 3
					}
				}

详细参考https://www.cnblogs.com/wuweidong/p/13804180.html