万字长文带你从 0 学习 Keepalived

Posted 2021-05-01 Web开发

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了万字长文带你从 0 学习 Keepalived相关的知识，希望对你有一定的参考价值。

负载均衡器（Load Balancer, LB ）是一组能够将IP数据流以负载均衡形式转发到多台物理服务器的集成软件。有硬件负载均衡器和软件负载均衡器之分，硬件负载均衡器主要是在访问网络和服务器之间配置物理负载均衡设备，客户端对物理服务器的访问请求首先会抵达负载均衡设备，然后再由负载均衡设备根据一定的负载算法转发到后端服务器。相比而言，软件负载均衡器不需要特定的物理设备，只需在相应的操作系统上部署具有负载均衡功能的软件即可。

在Opens tack高可用集群部署中，服务的负载均衡和高可用主要有两种主流的实现方案，即HAProxy+ Keepalived和Pacemaker+HAProxy方案。由于OpenStack服务组件多样，不同服务均需要进行特定的高可用设计，并且从集群资源统一调度和集群稳定性的角度考虑，后一种方案是多数OpenStack厂商的高可用部署方案首选，但是选用后一方案并不意味着Keepalived在OpenStack高可用集群部署中不被使用。由于Keepalived 的主要作用之一是进行虚拟路由的故障切换，其在Neutron 的L3 高可用设计与实现中起着举足轻重的作用。

1.1 keepalived及LVS概述

Keepalived的项目实现的主要目标是简化LVS项目的配置并增强其稳定性，即Keepalived是对LVS项目的扩展增强。

Keepalived为Linux系统和基于Linux 的架构提供了负载均衡和高可用能力，其负载均衡功能主要源自集成在Linux内核中的LVS项目模块IPVS( IP Virtual Server ），基于IPVS提供的4 层TCP/IP协议负载均衡， Keepalived也具备负载均衡的功能，此外， Keepalived还实现了基于多层TCP/IP 协议（ 3 层、4 层、5/7 层）的健康检查机制，因此， Keepalived在LVS 负载均衡功能的基础上，还提供了LVS 集群物理服务器池健康检查和故障节点隔离的功能。

除了扩展LVS的负载均衡服务器健康检查能力， Keepalived 还基于虚拟路由冗余协议（ Virtual Route Redundancy Protocol, VRRP )实现了LVS 负载均衡服务器的故障切换转移，即Keepalived还实现了LVS负载均衡器的高可用性。Keepalived 就是为LVS 集群节点提供健康检查和为LVS 负载均衡服务器提供故障切换的用户空间进程。

图3-1为Keepalived的原理架构图，从图中可以看到， Keepalived的多数核心功能模块均位于用户空间，而仅有IPVS和NETLINK模块位于内核空间，但是这两个内核模块正是Keepalived 实现负载均衡和路由高可用的核心模块，其中的NETLINK主要用于提供高级路由及其相关的网络功能。Keepalived的大部分功能模块位于用户空间，其中几个核心功能模块的介绍如下。

图3-1 Keepalived的原理架构图

WatchDog ：其主要负责监控Checkers和VRRP子进程的运行状况。
Checkers ：此功能模块主要负责真实服务器的健康检查（ HealthChecking )，是Keepalived最主要的功能之一，因为HealthChecking是负载均衡功能稳定运行的基础， LVS集群节点的故障隔离和重新加入均依赖于HealthChecking的结果。
VRRPStack ：此功能模块主要负责负载均衡器之间的故障切换，如果集群架构中仅使用一个LVS负载均衡器，由于本身不具备故障切换的条件，则VRRPStack不是必须的。
IPVS Wrapper ：此模块主要用来发送设定的规则到内核IPVS代码。Keepalived的设计目标是构建高可用的LVS 负载均衡群集， Keepalived在运行中将会通过IPVSWrapper模块调用IPVSAdmin工具来创建虚拟服务器，检查和管理LVS集群物理服务器池。

从Keepalived 的实现原理和功能来看， Keepalived是开源负载均衡项目LVS的增强和虚拟路由协议VRRP实现的集合，即Keepalived通过整合和增强LVS与VRRP来提供高可用的负载均衡系统架构。

1.linux虚拟服务器---lvs

LVS是Linux Virtual Server的简称，即Linux虚拟服务器。目前，LVS项目已经被集成到Linux内核中。LVS具有良好的可靠性、可扩展性和可操作性，加上其实现最优的集群服务性能所需的低廉成本， LVS的负载均衡功能经常被用于高性能、高可用的服务器群集中。

基于LVS技术可以实现很多高伸缩、高可用的网络服务，例如Web服务、Cache服务、DNS服务FTP服务、MAIL服务、视频／音频点播服务等， LVS的功能也在发展过程中得到了很多用户的实践验证，例如很多著名网站和组织都在使用基于LVS架构的集群系统，包括Linux门户网站（ www.linux.com ）向RealPlayer 提供音频视频服务的Real公司（ www.real.com ）、全球最大的开源网站( sourceforge.net ）等都是LVS项目的使用者。

在基于LVS 项目架构的服务器集群系统中，通常包含三个功能层次：最前端的负载均衡层（ Load Balancer ）、中间的物理服务器群组层（ Server Array ）以及最底端的数据共享存储层（ Shared Storage ），典型的LVS 集群架构如图3-2 所示。在LVS负载均衡集群架构中，尽管整个集群内部有多个物理节点在处理用户发出的请求，但是在用户看来，所有的内部应用都是透明的，用户只是在使用一个虚拟服务器提供的高性能服务，这也是Linux虚拟服务器项目，即LVS项目的主要名称来源，如下是对LVS 集群架构中各个层次的功能描述。

万字长文带你从 0 学习 Keepalived

图3-2 LVS 集群架构

( 1 ) Load Balancer层

负载均衡层位于整个集群系统的最前端，由一台或者多台负载调度器（ Director Server )组成， LVS模块就安装在Director Server的系统上，而Director Server的主要功能类似路由器，其包含了完成LVS 负载转发功能所设定的路由表， Director利用这些路由表信息把用户的请求分发到Sever Array层的物理服务器（ Real Server ）上。此外，为了监测各个Real Server服务器的健康状况，在Director Server上还要安装监控模块Ldirectord，而当监控到某个Real Server不可用时，该服务器会被从LVS 路由表中剔除，恢复时又会重新加入。

( 2 ) Server Array 层

服务器阵列或服务器池由一组实际运行应用服务的物理机器组成，Real Server可以是Web服务器、Mail 服务器、FTP服务器、DNS服务器以及视频服务器中的一个或者多个的组合。每个Real Server之间通过高速的LAN或分布在各地的WAN 相连接。在实际应用中，为了减少资源浪费， Director Server也可以同时兼任Real Server的角色，即在Real Server同时部署LVS模块。

( 3) Shared Storage 层

存储层是为所有Real Server提供共享存储空间和内容一致性的存储区域，在物理实现上，该层一般由磁盘阵列设备组成。而为了提供一致性的内容，通常利用NFS网络文件系统提供集群的共享数据，但是NFS在繁忙的业务系统中，性能并不是很好，此时可以采用集群文件系统，例如Redhat的GFS文件系统和IBM的GPFS文件系统等。

（1） VSNAT (Virtual Server via Network Address Translation)

户请求越来越多，调度器的处理能力就会成为集群服务快速响应的瓶颈。

( 2) VSTUN (Virtual Server via IP Tunneling)

即IP隧道技术实现的虚拟服务器。VS TUN与VSNAT技术的报文转发方法不同，在VS TUN方式中，调度器采用IP隧道技术将用户请求转发到某个选中的Real Server上，而这个Real Server将直接响应用户的请求，不再经过前端调度器。此外， IP TUN技术对RealServer的地域位置没有要求，其既可以与Director Server位于同一个网段，也可位于独立网络中。因此，在VS TUN方式中，调度器将只处理用户的报文请求，而无需进行转发，故集群系统的响应速率相对而言得到极大提高。

( 3) VSDR (Virtual Server via Direct Routing)

2 . 虚拟路由冗余协议一VRRP

万字长文带你从 0 学习 Keepalived

图3-3 VRRP虚拟路由示意图

路由器开启VRRP功能后，会根据设定的优先级确定自己在备份组中的角色。优先级高的路由器成为Master路由器，优先级低的成为Backup路由器，并且Master路由器定期发送VRRP通告报文，通知备份组内的其他Backup路由器自己工作正常，而备用路由器则启动定时器等待通告报文的到来。（如何判断Master路由器是否正常工作？）如果Backup路由器的定时器超时后仍未收到Master路由器发送来的VRRP通告报文，则认为Master 路由器已经故障，此时Backup路由器会认为自己是主用路由器（备份组内的路由器会根据优先级选举出新的Master路由器），并对外发送VRRP通告报文。此外， VRRP在提高路由可靠性的同时，还简化了主机的路由配置，在具有多播或广播能力的局域网中，借助VRRP能在某台路由器出现故障时仍然提供高可靠的默认链路，有效避免单一链路发生故障后网络中断的问题，并且无需修改主机动态路由协议、路由发现协议等配置信息。

1.2 KeepAlived工作原理

Keepalived 本质上是提供数据流转发与服务器健康检查并具备故障切换的高可用路由，而数据转发与健康检查是对LVS功能的扩展和增强，因此也可以认为Keepalived是运行在用户空间的LVS 路由（LVS Router) 进程。在实际应用中， Keepalived通常部署在两台主备或一主多备的服务器上，即Keepalived进程既运行在Active/Master状态的LVS Router中，也运行在Passive/Slave状态的LVS Router中，而所有运行Keepalived进程的LVS Router都遵循虚拟路由冗余协议VRRP。在VRRP的协议框架下，作为Master的Router将会处理两个主要任务，即转发客户端访问请求到后端物理服务器以进行负载均衡和周期性的发送VRRP协议报文，而作为Slave的Routers则负责接收VRRP报文，如果某一时刻作为Slave 的Routers 接收VRRP报文失败，则认为Master Router故障，并从Slave Routers中重新选举产生一个新的Master Router 。

Keepalived是一个与LVS Router相关的控制进程，在RHEL7 /Centos7 系统中，Keepalived 由Systemctl 命令通过读取/etc/keepalived/keepalived.conf配置文件来启动。在遵循VRRP协议的Master Router 中， Keepalived进程会启动内核中的LVS服务以创建虚拟服务器，并根据配置拓扑对服务运行状况进行监控。此外，Master Router还会向Slave Routers 发送周期性的VRRP广播报文，而Master Router运行状态的正常与否是由Slave Routers上的VRRP 实例决定的。如果在用户预置的时间段内Slave Router不能接收到VRRP 报文，则Keepalived认为Master Router故障，同时触发LVS Router 的Failover操作。

在Failover 的过程中， Keepalived 创建的虚拟服务器会被清除，新的Master Router将接管VIP 发送ARP信息、设置IPVS Table记录条目（Virtual Server）以及物理服务器的健康检查和发送VRRP 广播报文。Keepalived的Failover操作针对的是四层TCP/ IP 协议，即传输层，因为TCP在传输层上进行的是基于链路连接的数据传输。所以，当服务器在响应TCP请求时，如果出现设置时间段的Timeout，则Keepalived的健康检查机制将会监测到该情况并认为该服务器故障，然后将其从服务器池中移除（故障服务器隔离）。图3-4 是基于Keepalived 设计的具有二层拓扑的负载均衡架构，该架构分为两个层次。第一层为负载均衡层，由一个Active 和多个Backup的LVS Routers组成，其中，每个LVS Router 都配置有两个网络接口，一个接入Internet 网络，另一个接入内部私有网络， Active的LVS Router 在这两个网络接口间进行数据转发。在图3-4 的负载均衡架构中，位于第一层的LVS Routers和第二层的物理服务器通过私网接口接人相同的局域网中， Active的LVSRouter通过NAT 技术将Internet数据流转发到私网物理服务器上，而这些位于第二层的物理服务器运行着最终响应请求的服务。

万字长文带你从 0 学习 Keepalived

图3-4 基于Keepalived 设计的具有二层拓扑的负载均衡架构

此外， Active Router还负责动态监控后端服务器上特定服务的健康状况，监控方式主要是Keepalived自带的三种健康检测机制，即简单TCP连接、HTTP和HTTPS。就简单TCP连接检测方式， Active Router会周期性地对服务器上某个特定端口进行TCP连接，如果TCP 连接超时或者中断则认为服务不可用，而对于HTTP和HTTPS检测方式， ActiveRouter通过周期性地抓取（ Fetch ）请求URL并验证其内容来判断服务的可用性。与此同时， Backup Router一直处于Standby状态， LVS router的Failover由VRRP来处理。

图3-4中的两层负载均衡架构是最常见的部署环境，主要用于很多数据源变化不是很频繁的数据请求服务中，如静态Web页面站点，因为后端独立服务器（Real Severs ）之间不会自动进行数据同步。图3-5为基于Keepalived的三层负载均衡架构，在三层负载均衡架构中，前端的LVS Router负责将访问请求转发到物理服务器（ Real Servers ）中，然后Real Server再通过网络形式访问可共享的数据源。

万字长文带你从 0 学习 Keepalived

图3-5 基于Keepalived的三层负载均衡架构

对于数据请求比较繁忙的FTP站点，三层架构是最为理想的负载均衡架构，在这种架构下，可供访问的数据源集中存储在高可用的集群服务器上， Real Servers通过NFS共享目录或者Samba文件共享等网络文件系统形式来访问数据。此外，类似的三层负载均衡架构在需要提供中心化及数据库事务处理高可用的Web站点中也被普遍使用，如果将Keepalived负载均衡器配置为Active/Active 双活模式，则还可以将三层负载均衡架构同时用于提供FTP和Web数据库服务。

1.3 KeepAlived的负载均衡算法

( 1 ) Round-Robin

即所谓的轮询负载均衡，在这种算法中，服务请求会被依次转发到服务器池中的每一个服务器上，而不去评估服务器的当前负载或者处理能力，服务器池中的每一个服务器都被平等对待。如果使用Round-Robin负载均衡算法，每台后端服务器会轮询依次处理服务请求。

( 2 ) Weighted Round-Robin

即加权Round-Robin 算法，是对Round-Robin 算法的一种扩展。在这种算法中，请求被依次转发到每一台服务器上，但是当前负载较轻或者计算能力较大的服务器会被转发更多的请求，服务器的处理能力通过用户指定的权重因子来决定，权重因子可以根据负载信息动态上调或者下调。如果服务器的配置差别较大，导致不同服务器的处理能力相差较大，则加权的Round-Robin 算法会是不错的选择，但是如果请求负载频繁变动，则权重较大的服务器可能会超负荷工作。

( 3 ) Least-Connection

即最少连接算法，在这种算法中，请求被转发到活动连接较少的服务器上。在Keepalived的实际使用中， LVS Router一直在利用内核中的IPVS Table来记录后端服务器的活动连接，从而动态跟踪每个服务器的活动连接数。最少连接数算法是一种动态决策算法，它比较适合服务器池中每个成员的处理能力都大致相当，同时负载请求又频繁变化的场景，如果不同服务器有不同的处理能力，则下面的加权最少连接数算法较为合适。

( 4 ) Weighted Least-Connections

即加权最少连接数算法，在这种算法中，路由会根据服务器的权重，转发更多的请求到连接数较少的服务器上。服务器的处理能力通过用户指定的权重因子来决定，权重因子可以根据负载信息动态上调或者下调。一般来说，服务器加权算法主要用于集群存在不同类型服务器，而服务器配置和处理能力相差较大的场景中。

( 5) Destination Hash ScheduIing

( 6 ) Source Hash Scheduling

( 7 ) Shortest Expected Delay

即最小延时算法，在这种算法中，请求被转发到具有最小连接响应延时的服务器上。

1.4 Keepalived 路由方式

（1） NAT

万字长文带你从 0 学习 Keepalived

图3-6 NAT 路由实现的Keepalived负载均衡

（2） DR

相对于其他的负载均衡网络拓扑， DR(Direct Routing）路由方式为基于Keepalived 的负载均衡系统提供了更高的网络性能， DR路由方式允许后端服务器直接将处理后的应答数据返回给客户端，而无需经过LVS Router的处理操作，DR路由方案极大降低了LVS Router 造成网络瓶颈的可能性。如图3-7所示。在基于Keepalived的负载均衡架构中， Keepalived的最佳路由方式是DR 路由，即在配置Keepalived的路由方式时，优先将其设置为DR 。

图3-7 DR 路由实现的Keepalived负载均衡

1.5 Keepalived 配置与使用

//全局配置段
global_defs {
notification_email{
admin@example . com
}
notification_email from noreply@example.com
smtp_server 127.0 . 0.1
smtp_connect_timeout 60
router_id LVS DEVEL
}
/ /VRRP配置段
vrrp_sync_group VG1 {
group {
VRRP EXT
VRRP INT
}
/ /VRRP 实例VRRP_EXT配置段
vrrp_instance VRRP_EXT {
state MASTER
interface eth0
virtual_router_id 50
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass passwordl23
}
virtual_ipaddress {
10.0.0.1
}
}
// VRRP 实例VRRP_ INT 配置段
vrrp_instance VRRP_ENT {
state MASTER
interface eth1
virtual_router_id 2
priority 100
advert_int 1
authentication{
auth_type PASS
auth_pass passwordl23
}
virtual_ipaddress {
192 .168 .1.1
}
}
//虚拟服务器LVS 配置段
virtual_server 10 .0.0 .180 {
delay_loop 6
lb_algo rr
lb_kind NAT  //NAT路由方式
protocol tcp
//后端服务器1
real_server 192.168.1.20 80 {
TCP_CHECK {
connect timeout 10
}
}
//后端服务器2
real_server 192 .168 .1.21 80 {
TCP_CHECK {
connect timeout 10
}
}
//后端服务器3
real_server 192.168.1.22 80 {
TCP_CHECK {
connect timeout 10
}
}
//后端服务器4
real_server 192.168.1.23 80 {
TCP_CHECK {
connect timeout 10
}
}

从Keepalived 配置文件/etc/keepali ved/keepali ved. conf 中的内容可以看到， Keepalived的配置主要分为三个模块，即全局配置段、VRRP 定义段、虚拟服务器LVS 配置段。

1. 全局配置段

global_defs {
notification_email {
admin@example.com
}
notification_ email_from noreply@example.com
smtp_server 127 0 . 0.1
smtp_connect_timeout 60
router id LVS DEVEL
}

全局配置段（ global_defs ）的主要作用之一就是Keepalived出现故障时的邮件通知管理员，让管理员以邮件形式知道Keepalived的运行情况。通常情况下，邮件通知不是必须的，用户可以选择其他监控方式来对Keepalived 进行监控，如Nagios。需要说明的是，全局配置段对Keepalived来说是可选的，其内容并不是Keepalived 配置所必须的。全局配置段的几个主要配置参数说明如下：

Notification_email ：用于配置接收邮件的负载均衡器的管理员群组邮箱。
LVS_ID: LVS 负载均衡器标志，同一网络中其值唯一。

2. VRRP 配置段

vrrp_sync_group VGl (
group {
VRRP EXT
VRRP INT
}
vrrp_instance VRRP_EXT {
state MASTER
interface eth0
virtual_router_id 50
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass password123
}
virtual_ipaddress {
10.0.0.1
}
}
vrrp_instance VRRP_ INT {
state MASTER
interface eth1
virtual_router_id  
priority 100
advert_int 1
authentication {
auth_type PASS
auth__pass password123
}
virtual_ipaddress {
192.168 .1.1
}
}

VRRP配置段（ vrrp sync group ）主要用于定义VRRP组，在Keepalived发生任何状态

变化时，被定义在VR即组中的VRRP实例作为逻辑整体一致行动，如在发生LVS Router故障切换Failover的过程中， VRRP组中的实例会作为一致整体同时切换。在本节的演示配置中，同一个VRRP组内配置了两个VRRP实例，分别是针对外部网络的VRRP_EXT实例和针对内部私有网络的VRRP_INT 实例。VRRP 配置段中的关键参数说明如下。

vrrp_sync_group : VRRP实例一致组，用于定义VRRP一致组中的成员，组内的VRRP实例行为是一致的，如在Failover的时候，一致组内的VRRP实例将同时迁移。在本机示例中，当LBl出现故障时， VRRP INT和VRRP EXT实例将同时切换到LB2上。
vrrp_instance: VRRP实例，用于配置一个VRRP服务进程实例，其中的State设定了当前节点VRRP实例的主备状态，在主LVS Router中，该值应该为MASTER,在备LVS Router中，其值为BACKUP 。正常情况下只有Master的LVS Router在工作， Backup的LVS Router处于Standby状态。
interface ：对外提供服务的网络接口，如eth0和eth1，选择服务接口时，一定要核实清楚，LV Router 的VIP将会配置到这个物理接口上。
Virtual_Router_id ：虚拟路由标志，同一个VRRP实例使用唯一的标识。即同一个VRRP实例中， MASTER和BACKUP状态的VRRP实例中， virtual_router_id 值是相同的，同时在全部VRRP 组内是唯一的。
Priority ：此参数指明了该VRRP实例的优先级，数字越大说明优先级越高，取值范围为0-255 ，在同一个VRRP实例里， MASTER的优先级高于BACKUP。若MASTER的Priority值为100 ，那BACKUP 的Priority只能是90或更小的数值。
Advert_ int: Master路由发送VRRP广播的时间间隔，单位为秒。
Authentication ：包含验证类型和验证密码，类型主要有PASS 和AH两种，通常使用的类型为PASS 验证密码为明文，同一VRRP实例MASTER与BACKUP使用相同的密码才能正常通信。

3. 虚拟服务器LVS 配置段

virtual_server 10.0.0.1 80 {
delay_loop 6
lb_algo rr
lb_kind NAT
protocol tcp
real_server 192 .16 8.1.20 80 {
TCP_CHECK {
connect timeout 10
}
real_server 192 .16 8.1.21 80 {
TCP_CHECK {
connect timeout 10
}
real_server 192 .16 8.1.22 80 {
TCP_CHECK {
connect timeout 10
}
real_server 192 .16 8.1.23 80 {
TCP_CHECK {
connect timeout 10
}
}

Delay_Loop ：健康检查的时间间隔，单位为秒。
LB_Algo ：选用的负载均衡算法，示例中的rr表示Round-Robin算法。
LB_Kind ：采用的路由方法，示例中采用的是NAT路由，还可以采用DR和TUN路由。
Protocol ：转发协议，一般有TCP 和UDP两种。
TCP CHECK ：表示采用TCP连接对Real Servers 进行健康检查。
Connect timeout : TCP连接允许中断的时间，单位为秒，超过此值认为TCP连接Timeout ，即后端服务器不可用。

上述示例中Keepalived的配置采用的是NAT路由方式，而在大规模负载均衡集群中，NAT 路由通常造成网络性能瓶颈，因此建议采用DR路由方式。DR路由方式的配置与NAT 方式类似，，为了使用DR路由，将LB_Kind参数配置为DR。

在LBJ 和LB2 上配置完keepalived.conf 后，分别在两个节点上启动Keepalived服务，即可正常使用Keepalived的负载均衡功能。

//启动Keepalived服务
systemctl start keepalived . service
//将Keepalived服务设置为开机启动
systemctl enable keepalived . service

●编号564，输入编号直达本文

●输入m获取文章目录