HA集群之Keepalived(1)

HA之路(1)

集群是一个统称了概念,按照集群的架构来分可以分为三类

  1. 高可用集群
  2. 负载均衡集群(LS集群)
  3. 分布式计算集群

HA集群

每一种集群的应用点都是不同的,HA集群主要应用于服务的高可用。
在主机down了以后会自动切换到备机,也就是说我们的HA是有主备之分的。简单来说HA集群就是保证服务不间断的运行的一种集群模式。

负载均衡集群

从字面意思就能够看出,主要是用来做负载的均衡。如果在高并发的网站架构中,一台web server肯定扛不住这个压力,这个时候我们就可以考虑加服务器。现在有一个点就是如何让用户过来的流量能够分散的打在这些server上了?这个时候我们就需要有一个负载均衡的软件。通过这个软件让他去调度和分发我们的流量,从而实现了后端多个服务器负载均衡的一个模式。

分布式计算集群。

这个是比较好理解的,比如说在大数据领域hadoop集群,它就是一个典型的分布式计算集群。所谓的分布式计算就是把计算的需求分发的各个计算的节点上去。比如我们要在几亿条数据里面做一个整理和归类把我们所需要的数据筛选出来,这个时候单台服务器肯定是无法满足我们的需求的。那就是利用多台服务器共同参与计算。

这次要学习的主要是HA集群的keepalived软件,用来解决HA的需求。

HA 集群中的相关术语

  1. 节点(node)
    运行 HA 进程的一个独立主机,称为节点,节点是 HA 的核心组成部分,每个节点上运行着 操作系统和高可用软件服务,在高可用集群中,节点有主次之分,分别称为主节点和备用/备份 节点,每个节点拥有唯一的主机名,并且拥有属于自己的一组资源,例如,磁盘、文件系统、网 络地址和应用服务等。主节点上一般运行着一个或多个应用服务。而备用节点一般处于监控状态。
    双机热备:一个主节点,一个备节点
    双机多备:一个主节点,多个备节点

  2. 资源(resource)
    资源是一个节点可以控制的实体,并且当节点发生故障时,这些资源能够被其它节点接管, HA 集群软件中,可以当做资源的实体有:

    • 磁盘分区、文件系统
    • IP 地址 VIP
    • 应用程序服务
    • NFS 文件系统

对资源的转移和控制都是由集群软件来操作完成的。

  1. 事件(event) 也就是集群中可能发生的事情,例如节点系统故障、网络连通故障、网卡故障、应用程序故
    障等。这些事件都会导致节点的资源发生转移,HA 的测试也是基于这些事件来进行的。
  2. 动作(action)
    事件发生时 HA 的响应方式,动作是由 shell 脚步控制的,例如,当某个节点发生故障后,
    备份节点将通过事先设定好的执行脚本进行服务的关闭或启动。进而接管故障节点的资源。

常见的动作,不用我们去写脚本,集群软件已经帮助我们集成了,但是应用程序的动作,有些自定义程度比较高的就是又我们自己编写脚本来完成的。

Keepalived简介

Keepalived 是 Linux 下一个轻量级的高可用解决方案,它与 HACMP、RoseHA 实现 的功能类似,都可以实现服务或者网络的高可用,但是又有差别:HACMP 是一个专业的、 功能完善的高可用软件,它提供了 HA 软件所需的基本功能,比如心跳检测和资源接管,监 测集群中的系统服务,在群集节点间转移共享 IP 地址的所有者等,HACMP 功能强大,但
是部署和使用相对比较麻烦,同时也是商业化软件;与 HACMP 相比,Keepalived 主要 是通过虚拟路由冗余来实现高可用功能,虽然它没有 HACMP 功能强大,但 Keepalived 部署和使用非常简单,所有配置只需一个配置文件即可完成。这也是本课程重点介绍 Keepalived 的原因。

Keepalived 的主要用途

Keepalived 起初是为 LVS 设计的,Keepalived补充了LVS的功能,专门用来监控集群系统中各个服务节点的状态。它 根据 layer3, 4 & 5 交换机制检测每个服务节点的状态,如果某个服务节点出现异常,或工 作出现故障,Keepalived 将检测到,并将出现故障的服务节点从集群系统中剔除,而在故 障节点恢复正常后,Keepalived 又可以自动将此服务节点重新加入到服务器集群中,这些 工作全部自动完成,不需要人工干涉,需要人工完成的只是修复出现故障的服务节点。
Keepalived 后来又加入了 VRRP 的功能,VRRP 是 Virtual Router Redundancy Protocol(虚拟路由器冗余协议)的缩写,它出现的目的是为了解决静态路由出现的单点 故障问题,通过 VRRP 可以实现网络不间断地、稳定地运行。因此,Keepalived 一方面具 有服务器状态检测和故障隔离功能,另一方面也具有 HA cluster 功能.下面详细介绍下 VRRP 协议的实现过程。

VRRP 协议与工作原理

        在现实的网络环境中,主机之间的通信都是通过配置静态路由(默认网关)完成的,而 主机之间的路由器一旦出现故障,通信就会失败,因此,在这种通信模式中,路由器就成了 一个单点瓶颈,为了解决这个问题,就引入了 VRRP 协议。
熟悉网络的学员对 VRRP 协议应该并不陌生。它是一种主备模式的协议,通过 VRRP 可以在网络发生故障时透明地进行设备切换而不影响主机间的数据通信,这其中涉及两个概 念:物理路由器和虚拟路由器。

        VRRP 可以将两台或多台物理路由器设备虚拟成一个虚拟路由器,这个虚拟路由器通过 虚拟 IP(一个或多个)对外提供服务,而在虚拟路由器内部,是多个物理路由器协同工作, 同一时间只有一台物理路由器对外提供服务,这台物理路由器被称为主路由器(处于 MASTER 角色)。一般情况下 MASTER 由选举算法产生,它拥有对外服务的虚拟 IP,提供各 种网络功能,如 ARP 请求、ICMP、数据转发等。而其他物理路由器不拥有对外的虚拟 IP,
也不提供对外网络功能,仅仅接收 MASTER 的 VRRP 状态通告信息,这些路由器被统称为 备份路由器(处于 BACKUP 角色)。当主路由器失效时,处于 BACKUP 角色的备份路由器 将重新进行选举,产生一个新的主路由器进入 MASTER 角色继续提供对外服务,整个切换 过程对用户来说完全透明。

        在一个虚拟路由器中,只有处于 MASTER 角色的路由器会一直发送 VRRP 数据包,处 于 BACKUP 角色的路由器只接收 MASTER 发过来的报文信息,用来监控 MASTER 运行状态, 因此,不会发生 MASTER 抢占的现象,除非它的优先级更高。而当 MASTER 不可用时, BACKUP 也就无法收到 MASTER 发过来的报文信息,于是就认定 MASTER 出现故障,接着 多台 BACKUP 就会进行选举,优先级最高的 BACKUP 将成为新的 MASTER,这种选举并进 行角色切换的过程非常快,因而也就保证了服务的持续可用性。

Keepalived 的体系结构

Keepalived 是一个高度模块化的软件,结构简单,但扩展性很强,下图是官方给出的 Keepalived 体系结构拓扑图。
image
可以看出,Keepalived 的体系结构从整体上分为两层,分别是用户空间层(User Space)和内核空间层(Kernel Space).下面介绍 Keepalived 两层结构的详细组成及实 现的功能,用户空间主要实现高可用的功能。
内核空间层处于最底层,它包括 IPVS 和 NETLINK 两个模块。IPVS 模块是 Keepalived 引入的一个第三方模块,通过 IPVS 可以实现基于 IP 的负载均衡集群。IPVS 默认包含在 LVS 集群软件中,简单说这个IPVS就是我们的LVS核心模块。

Keepalived 最初就是为 LVS 提供服务的,由于 Keepalived 可以实现对集群节点的状 态检测,而 IPVS 可以实现负载均衡功能,因此,Keepalived 借助于第三方模块 IPVS 就可 以很方便地搭建一套负载均衡系统。在这里有个误区,由于 Keepalived 可以和 IPVS 一起 很好地工作,因此很多初学者都以为 Keepalived 就是一个负载均衡软件,这种理解是错误 的。

在 Keepalived 中,IPVS 模块是可配置的,如果需要负载均衡功能,可以在编译 Keepalived 时打开负载均衡功能,反之,也可以通过配置编译参数关闭。
NETLINK 模块主要用于实现一些高级路由框架和一些相关的网络功能,完成用户空间层 Netlink Reflector 模块发来的各种网络请求。
用户空间层位于内核空间层之上,Keepalived 的所有具体功能都在这里实现.

Keepalived 的安装过程

keepalived 的安装非常简单,建议通过 yum 方式直接安装:

1
yum install keepalived

如果需要 lvs 功能,还需要安装 ipvs 模块:

1
yum install ipvsadm

Keepalived 的全局配置

在上节安装 Keepalived 的过程中,指定了 Keepalived 配置文件的路径为 /etc/Keepalived/Keepalived.conf,Keepalived 的所有配置均在这个配置文件中完成。 由于 Keepalived.conf 文件中可配置的选项比较多,这里根据配置文件所实现的功能,将 Keepalived 配置分为三类,分别是:

  • 全局配置(Global Configuration)、
  • VRRPD配置
  • LVS配置

下面将主要介绍下 Keepalived 配置文件中一些常用配置选项的含义和用法。

Keepalived 的配置文件都是以块(block)的形式组织的,每个块的内容都包含在{} 中,以“#”和“!”开头的行都是注释。全局配置就是对整个 Keepalived 都生效的配置, 基本内容如下:

1
2
3
4
5
6
7
! Configuration File for keepalived
global_defs {
notification_email { dba.gao@gmail.com ixdba@163.com
}
notification_email_from Keepalived@localhost smtp_server 192.168.200.1 smtp_connect_timeout 30
router_id LVS_DEVEL
}

全局配置以“global_defs”作为标识,在“global_defs”区域内的都是全局配置选 项,其中:

  • notification_email 用于设置报警邮件地址,可以设置多个,每行一个。注意,如果要 开启邮件报警,需要开启本机的 Sendmail 服务。
  • notification_email_from 用于设置邮件的发送地址。
  • smtp_server 用于设置邮件的 smtp server 地址。
  • smtp_connect_timeout 用于设置连接 smtp server 的超时时间。
  • router_id 表示运行 Keepalived 服务器的一个标识,是发邮件时显示在邮件主题中的
    信息。

Keepalived 的 VRRPD 配置

VRRPD 配置是 Keepalived 所有配置的核心,主要用来实现 Keepalived 的高可用功 能。下面进入 VRRP 实例的配置,也就是配置 Keepalived 的高可用功能。VRRP 实例段主
要用来配置节点角色(主或从)、实例绑定的网络接口、节点间验证机制、集群服务 IP 等。 下面是实例 VI_1 的一个配置样例。

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
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 151
priority 100
advert_int 1
track_interface {
eth0
eth1
} authentication {
auth_type PASS
auth_pass qwaszx
}
virtual_ipaddress {
192.168.200.16
192.168.200.17 dev eth1
192.168.200.18 dev eth2
}
nopreempt
preemtp_delay 300

notify_master "/etc/keepalived/master.sh "
notify_backup "/etc/keepalived/backup.sh"
notify_fault "/etc/keepalived/fault.sh"
}

以上 VRRP 配置以“vrrp_instance”作为标识,在这个实例中包含了若干配置选项,
分别介绍如下:

  • vrrp_instance 是 VRRP 实例开始的标识,后跟 VRRP 实例名称。
  • state 用于指定 Keepalived 的角色,MASTER 表示此主机是主服务器,BACKUP 表示
    此主机是备用服务器。
  • interface 用于指定 HA 监测网络的接口。
  • virtual_router_id 是虚拟路由标识,这个标识是一个数字,同一个 vrrp 实例使用唯一
    的标识,即在同一个 vrrp_instance 下,MASTER 和 BACKUP 必须是一致的。
  • priority 用于定义节点优先级,数字越大表示节点的优先级就越高。在一个
    vrrp_instance 下,MASTER 的优先级必须大于 BACKUP 的优先级。
  • advert_int 用于设定 MASTER 与 BACKUP 主机之间同步检查的时间间隔,单位是秒。
  • track_interface用于设置一些额外的网络监控接口,其中任何一个网络接口出现故障,Keepalived 都会进入 FAULT 状态。
  • authentication 用于设定节点间通信验证类型和密码,验证类型主要有 PASS 和 AH
    两种,在一个 vrrp_instance 下,MASTER 与 BACKUP 必须使用相同的密码才能正常
    通信。
  • virtual_ipaddress 用于设置虚拟 IP 地址(VIP),又叫做漂移 IP 地址。可以设置多个虚拟 IP 地址,每行一个。之所以称为漂移 IP 地址,是因为 Keepalived 切换到 Master 状态时,这个 IP 地址会自动添加到系统中,而切换到 BACKUP 状态时,这些 IP 又会 自动从系统中删除。Keepalived 通过“ip address add”命令的形式将 VIP 添加进系 统中。要查看系统中添加的 VIP 地址,可以通过“ip add”命令实现。“virtual_ipaddress” 段中添加的 IP 形式可以多种多样,例如可以写成 “192.168.16.189/24 dev eth1” 这 样的形式,而 Keepalived 会使用 IP 命令“ip addr add 192.168.16.189/24 dev eth1” 将 IP 信息添加到系统中。因此,这里的配置规则和 IP 命令的使用规则是一致的。
  • nopreempt 设置的是高可用集群中的不抢占功能。在一个 HA Cluster 中,如果主节 点死机了,备用节点会进行接管,主节点再次正常启动后一般会自动接管服务。这种来 回切换的操作,对于实时性和稳定性要求不高的业务系统来说,还是可以接受的,而对 于稳定性和实时性要求很高的业务系统来说,不建议来回切换,毕竟服务的切换存在一 定的风险和不稳定性,在这种情况下,就需要设置 nopreempt 这个选项了。设置 nopreempt 可以实现主节点故障恢复后不再切回到主节点,让服务一直在备用节点工 作,直到备用节点出现故障才会进行切换。在使用不抢占时,只能在“state”状态为 “BACKUP”的节点上设置,而且这个节点的优先级必须高于其他节点。
  • preemtp_delay 用于设置切换的延时时间,单位是秒。有时候系统启动或重启之后网 络需要经过一段时间才能正常工作,在这种情况下进行发生主备切换是没必要的,此选 项就是用来设置这种情况发生的时间间隔。在此时间内发生的故障将不会进行切换,而 如果超过“preemtp_delay”指定的时间,并且网络状态异常,那么才开始进行主备 切换。
  • notify_master:指定当 Keepalived 进入 Master 状态时要执行的脚本,这个脚本可 以是一个状态报警脚本,也可以是一个服务管理脚本。Keepalived 允许脚本传入参数, 因此灵活性很强。
  • notify_backup:指定当 Keepalived 进入 Backup 状态时要执行的脚本,同理,这 个脚本可以是一个状态报警脚本,也可以是一个服务管理脚本。
  • notify_fault:指定当 Keepalived 进入 Fault 状态时要执行的脚本,脚本功能与前两 个类似。
  • notify_stop:指定当 Keepalived 程序终止时需要执行的脚本。

    Keepalived 的 LVS 配置

        由于 Keepalived 属于 LVS 的扩展项目,因此, Keepalived 可以与 LVS 无缝整合, 轻松搭建一套高性能的负载均衡集群系统。下面介绍下 Keepalived 配置文件中关于 LVS 配置段的配置方法。

        LVS 段的配置以“virtual_server”作为开始标识,此段内容有两部分组成,分别是 real_server 段和健康检测段。下面是 virtual_server 段常用选项的一个配置示例:

1
2
3
4
5
6
virtual_server 192.168.12.200 80 {
delay_loop 6
lb_algo rr
lb_kind DR
persistence_timeout 50 persistence_granularity <NETMASK> protocol TCP
sorry_server <IPADDR> <PORT>

下面介绍每个选项的含义。

  • virtual_server:设置虚拟服务器的开始,后面跟虚拟 IP 地址和服务端口,IP 与端 口之间用空格隔开。
  • delay_loop:设置健康检查的时间间隔,单位是秒。
  • lb_algo:设置负载调度算法,可用的调度算法有 rr、wrr、lc、wlc、lblc、sh、
    dh 等,常用的算法有 rr 和 wlc。
  • lb_kind:设置 LVS 实现负载均衡的机制,有 NAT、TUN 和 DR 三个模式可选。
  • persistence_timeout:会话保持时间,单位是秒。这个选项对动态网页是非常有
    用的,为集群系统中的 session 共享提供了一个很好的解决方案。有了这个会话保 持功能,用户的请求会一直分发到某个服务节点,直到超过这个会话的保持时间。 需要注意的是,这个会话保持时间是最大无响应超时时间,也就是说,用户在操作 动态页面时,如果在 50 秒内没有执行任何操作,那么接下来的操作会被分发到另 外的节点,但是如果用户一直在操作动态页面,则不受 50 秒的时间限制。
  • persistence_granularity:此选项是配合 persistence_timeout 的,后面跟的值 是子网掩码,表示持久连接的粒度。默认是 255.255.255.255,也就是一个单独的 客户端 IP。如果将掩码修改为 255.255.255.0,那么客户端 IP 所在的整个网段的请 求都会分配到同一个 real server 上。
  • protocol:指定转发协议类型,有 TCP 和 UDP 两种可选。
  • ha_suspend:节点状态从 Master 到 Backup 切换时,暂不启用 real server 节
    点的健康检查。
  • sorry_server:相当于一个备用节点,在所有 real server 失效后,这个备用节点会
    启用。

下面是 real_server 段的一个配置示例:

1
2
3
4
5
6
real_server 192.168.12.132 80 {
weight 3
inhibit_on_failure
notify_up <STRING> | <QUOTED-STRING>
notify_down <STRING> | <QUOTED-STRING>
}

下面介绍每个选项的含义。

  • real_server:是 real_server 段开始的标识,用来指定 real server 节点,后面跟
    的是 real server 的真实 IP 地址和端口,IP 与端口之间用空格隔开。
  • weight:用来配置 real server 节点的权值。权值大小用数字表示,数字越大,权 值越高。设置权值的大小可以为不同性能的服务器分配不同的负载,为性能高的服 务器设置较高的权值,而为性能较低的服务器设置相对较低的权值,这样才能合理地利用和分配了系统资源。
  • inhibit_on_failure:表示在检测到 real server 节点失效后,把它的“weight”值
    设置为 0,而不是从 IPVS 中删除。
  • notify_up:此选项与上面介绍过的 notify_maser 有相同的功能,后跟一个脚本,
    表示在检测到 real server 节点服务处于 UP 状态后执行的脚本。
  • notify_down:表示在检测到 real server 节点服务处于 DOWN 状态后执行的脚
    本。

健康检测段允许多种检查方式,常见的有 HTTP_GET、SSL_GET、TCP_CHECK、 SMTP_CHECK、MISC_CHECK。首先看 TCP_CHECK 检测方式示例:

1
2
3
4
5
6
TCP_CHECK {
connect_port 80
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}

下面介绍每个选项的含义介。

  • connect_port:健康检查的端口,如果无指定,默认是 real_server 指定的端口。
  • connect_timeout:表示无响应超时时间,单位是秒,这里是 3 秒超时。
  • nb_get_retry:表示重试次数,这里是 3 次。
  • delay_before_retry:表示重试间隔,这里是间隔 3 秒。

下面是 HTTP_GET 和 SSL_GET 检测方式的示例:

1
2
3
4
5
6
7
8
9
10
11
12
13
HTTP_GET |SSL_GET
{
url {
path /index.html
digest e6c271eb5f017f280cf97ec2f51b02d3
status_code 200
}
connect_port 80
bindto 192.168.12.80
connect_timeout 3
nb_get_retry 3
delay_before_retry 2
}

下面介绍每个选项的含义。

  • url:用来指定 HTTP/SSL 检查的 URL 信息,可以指定多个 URL。
  • path:后跟详细的 URL 路径。
  • digest:SSL 检查后的摘要信息,这些摘要信息可以通过 genhash 命令工具获取。 例如:genhash -s 192.168.12.80 -p 80 -u /index.html。
  • status_code:指定 HTTP 检查返回正常状态码的类型,一般是 200。
  • bindto:表示通过此地址来发送请求对服务器进行健康检查。

下面是 MISC_CHECK 检测方式的示例:

1
2
3
4
5
6
MISC_CHECK
{
misc_path /usr/local/bin/script.sh
misc_timeout 5
! misc_dynamic
}

MISC 健康检查方式可以通过执行一个外部程序来判断 real server 节点的服务状态,
使用非常灵活。以下是常用的几个选项的含义。

  • misc_path:用来指定一个外部程序或者一个脚本路径。
  • misc_timeout:设定执行脚本的超时时间。
  • misc_dynamic:表示是否启用动态调整realserver节点权重,“!misc_dynamic”
    表示不启用,相反则表示启用。在启用这功能后,Keepalived 的 healthchecker 进程将通过退出状态码来动态调整 real server 节点的“weight”值,如果返回状 态码为 0,表示健康检查正常,real server 节点权重保持不变;如果返回状态码为
    1,表示健康检查失败,那么就将 real server 节点权重设置为 0;如果返回状态码 为 2~255 之间任意数值,表示健康检查正常,但 real server 节点的权重将被设置 为返回状态码减 2,例如返回状态码为 10,real server 节点权重将被设置为 8 (10-2)。

到这里为止,Keepalived 配置文件中常用的选项已经介绍完毕,在默认情况下, Keepalived 在启动时会查找/etc/Keepalived/Keepalived.conf 配置文件,如果配置文 件放在其他路径下,通过“Keepalived -f”参数指定配置文件的路径即可。

在配置 Keepalived.conf 时,需要特别注意配置文件的语法格式,因为 Keepalived 在启动时并不检测配置文件的正确性,即使没有配置文件,Keepalived 也照样能够启动, 所以一定要保证配置文件正确。

第一章的学习结束