高可用集群软件——Keeepalived简介及其相关内容剖析
一、高可用集群简介
1.1、高可用是什么
高可用是指通过设计和技术手段,确保系统在发生故障时仍能持续对外提供服务,保障业务的连续性。高可用的核心目标是减少服务中断时间,使用户感知不到系统的故障。 | ||
序号 | 高可用的内容 | 说明 |
1 | 高可用的关键原则 | 《1》冗余设计:冗余是高可用的基础,通过部署多个服务器节点(如:主从模式、集群模式),实现即使某个节点发生故障,其他节点仍然能接管服务。 ①【主从模式】一个主节点负责写操作,多个从节点负责读操作。 ②【分片集群】将数据分片存储,每个分片有多个副本,避免单点问题。 |
《2》自动故障转移:自动故障转移通过工具(如:Keepalived、Zookeeper等)实现;当检测到主节点故障时,系统会自动选举新的主节点并切换服务。 ①【Keepalived】通过VRRP协议实现主备节点的健康监测和VIP地址漂移。 ②【Zookeeper】通过ZAB协议选举出新的领导者,确保分布式系统的一致性。 | ||
2 | 高可用的实现方式 | 《1》接入层与反向代理:在接入层(如:软件负载均衡LVS)和反向代理层(如:Nginx),通过Keepalived实现主备切换;当主节点宕机或故障时,备用节点接管VIP地址,确保流量不中断。 |
《2》微服务架构:微服务通过注册中心(如:Zookeeper或Nacos)实现服务的动态发现和复杂均衡;当某个服务实例不可用时,注册中心会及时更新服务列表,消费者自动切换到其他可用实例。 | ||
《3》数据存储层:在数据库(如:MariaDB、Redis)中,通过主从复制或分片集群实现高可用。 ①MariaDB的主从复制:通过Keepalived实现主从切换,确保数据库服务的连续性。 ②Redis Sentinel:通过哨兵机制监控主节点状态,自动选举新的主节点。 | ||
3 | 中间件 | 中间件(如:Kafka、Elasticsearch)通过分片和副本机制实现高可用(如:Kafka的分区副本在Leader节点故障时,Follower节点可快速接管) |
4 | 高可用的衡量标准 | 高可用性通常用几个九来作为衡量标准(全年共有365*24=8760小时): 《1》99%:表示每年宕机时间约为87.6小时。 《2》99.9%:表示每年宕机时间约为8.76小时(即:52.56分钟)。 《3》99.99%:表示每年宕机时间约为0.876小时(即:52.56分钟)。 《4》99.999%:表示每年宕机时间约为0.0876小时(即:5.256分钟)。 |
5 | 重要考虑事项 | 虽然高可用架构能显著提升系统可靠性,但是还需要考虑如下三个方面的问题: 《1》隔离性:通过分散和隔离风险,避免单点故障影响全局。 《2》限流与降级:在流量激增或服务异常时,通过限流和降级策略保障核心功能的稳定性。 《3》监控与告警:实时监控系统状态,及时发现并处理潜在问题。 |
总结:通过合理的架构设计和工具支持,高可用集群能够有效保障系统的稳定性和业务的连续性。 |
1.2、高可用集群中的相关术语
序号 | 高可用集群中的相关术语 | 说明 |
1 | 节点(node) | 运行集群进程的一个独立主机,称为节点。 《1》节点是集群的核心组成部分,每个节点上运行着操作系统和高可用软件服务; 《2》在高可用集群中,节点有主次之分(即:主节点和备用/备份节点); 《3》每个节点拥有唯一的主机名,且拥有属于自己的一组资源(如:磁盘、文件系统、网络地址和应用服务等)。 《4》主节点上一般运行着一个或多个应用服务,而备用节点一般处于监控状态。 |
2 | 资源(resource) | 资源是一个节点可以控制的实体,并且当主节点发生故障时,这些资源能够被其它节点接管,集群软件中,可以当做资源的实体有如下四个内容: 《1》磁盘分区、文件系统。 |
3 | 事件(event) | 也就是集群中可能发生的事情(如:节点系统故障、网络连通故障、网卡故障、应用程序故障等)。这些事件都会导致节点的资源发生转移,集群的测试也是基于这些事件来进行的。 |
4 | 动作(action) | 事件发生时高可用(HA)的响应方式,动作是由shell脚步控制的(如:当某个节点发生故障后,备份节点将通过事先设定好的执行脚本进行服务的关闭或启动,进而接管故障节点的资源)。 |
1.3、集群的分类
序号 | 集群的分类 | 说明 |
1 | 高可用集群 | 高可用集群(High Availability Cluster,简称HA Cluster) 高可用的含义是最大限度的可以使用。 从集群的名字上可以看出,此类集群实现的功能是保障用户的应用程序持久、不间断的提供服务。 |
【双机热备】是最简单的应用模式,即经常说的active/standby方式,它使用两台服务器,一台作为主服务器(action),运行应用程序对外提供服务,另一台作为备机(standby),安装和主服务器一样的应用程序,但是并不启动服务,处于待机状态。 主机和备机之间通过心跳技术相互监控,监控的资源可以是网络、操作系统、也可以是服务,用户可以根据自己的需要,选择需要监控的资源,当备机监控到主机的某个资源出现故障时,根据预先设定好的策略,首先将IP切换过来,然后将应用程序服务也接管过来,接着就由备机对外提供服务,由于切换过程时间非常短,用户根本感觉不到程序出了问题,而且还进行了切换,从而保障了应用程序持久、不间断的服务。 | ||
【高可用集群】一般是通过高可用软件来实现的,在Linux下常用的高可用软件有:开源heartbeat HA、Redhat提供的RHCS、开源的Keepalived和商业软件ROSE等。 | ||
2 | 负载均衡集群 | 负载均衡集群(Load Balance Cluster,简称LB Cluster)是由两台或者两台以上的服务器组成: 《1》前端调度:调度部分负责把客户端的请求按照不同的策略分配给后端服务节点。 《2》后端节点服务:后端节点是真正提供应用程序服务的部分。 |
与HA Cluster不同的是(在负载均衡集群中,所有的后端节点都处于活动状态,它们都对外提供服务,分摊系统的工作负载)。 | ||
负载均衡集群可以把一个高负荷的应用分散到多个节点来共同完成,适用于业务繁忙、大负荷访问的应用系统。 但是它也有不足的地方:当一个节点出现故障时,前端调度系统并不知道此节点已经不能提供服务,仍然会把客户端的请求调度到故障节点上来,这样访问就会失败;为了解决这个问题,负载调度系统一般都引入了节点监控系统【节点监控系统位于前端负载调度机上,负责监控下面的服务节点,当某个节点出现故障后,节点监控系统会自动将故障节点从集群中剔除,当此节点恢复正常后,节点监控系统又会自动将其加入集群中,而这一切,对用户来说是完全透明的】。 | ||
3 | 分布式计算集群 | 分布式计算集群:致力于提供单个计算机所不能提供的强大的计算能力,包括数值计算和数据处理,并且倾向于追求综合性能。 |
在Hadoop的系统中,会有一台或多台master,主要负责NameNode的工作以及JobTracker的工作。 《1》JobTracker的主要职责就是启动、跟踪和调度各个Slave的任务执行。 《2》还会有多台slave,每一台slave通常具有DataNode的功能并负责TaskTracker的工作。TaskTracker根据应用要求来结合本地数据执行Map任务以及Reduce任务。 |
二、Keepalived介绍
之所以优先选择Keepalived,是因为Keepalived比Heartbeat要简单得多,特别是Heartbeat2.1.4后拆分成3个子项目,安装、配置、使用都比较复杂,当出问题的时候,都不知道具体是哪个子系统出问题了;而Keepalived只有1个安装文件、1个配置文件,配置文件也简单很多。
Heartbeat虽然复杂,但功能更强大,配套工具更全,适合做大型集群管理;而Keepalived主要用于集群倒换,基本没有管理功能。
2.1、Keepalived简介和用途
序号 | Keppalived | 说明 |
1 | Keppalived是什么 | Keepalived是Linux下一个轻量级的高可用解决方案,它与HACMP、RoseHA实现的功能类似,都可以实现服务或者网络的高可用,但是又有差别: 《1》HACMP是一个专业的、功能完善的高可用软件,它提供了HA软件所需的基本功能(如:心跳检测和资源接管,监测集群中的系统服务,在群集节点间转移共享IP地址的所有者等),HACMP功能强大,但是部署和使用相对比较麻烦,同时也是商业化软件; 《2》与HACMP相比,Keepalived主要是通过虚拟路由冗余来实现高可用功能,虽然它没有HACMP功能强大,但Keepalived部署和使用非常简单,所有配置只需一个配置文件即可完成。 |
2 | Keepalived的用途 | Keepalived起初是为LVS设计的,专门用来监控集群系统中各个服务节点的状态(它根据layer3, 4 & 5交换机制检测每个服务节点的状态,如果某个服务节点出现异常,或工作出现故障,Keepalived将检测到,并将出现故障的服务节点从集群系统中剔除,而在故障节点恢复正常后,Keepalived又可以自动将此服务节点重新加入到服务器集群中,这些工作全部自动完成,不需要人工干涉),需要人工完成的只是修复出现故障的服务节点。 |
Keepalived后来又加入了VRRP的功能,VRRP是Virtual Router Redundancy Protocol(虚拟路由器冗余协议)的缩写(目的是为了解决静态路由出现的单点故障问题,通过VRRP可以实现网络不间断地、稳定地运行)。 因此,Keepalived一方面具有服务器状态检测和故障隔离功能,另一方面也具有HA cluster功能。 |
2.2、VRRP协议与工作原理
序号 | 说明 |
1 | 在现实的网络环境中,主机之间的通信都是通过配置静态路由(默认网关)完成的,而主机之间的路由器一旦出现故障,通信就会失败,因此,在这种通信模式中,路由器就成了一个单点瓶颈,为了解决这个问题,就引入了VRRP协议。 |
2 | VRRP协议是一种主备模式的协议,通过VRRP可以在网络发生故障时透明地进行设备切换而不影响主机间的数据通信,这其中涉及两个概念【物理路由器】和【虚拟路由器】: VRRP可以将两台或多台物理路由器设备虚拟成一个虚拟路由器,这个虚拟路由器通过虚拟IP(一个或多个)对外提供服务,而在虚拟路由器内部,是多个物理路由器协同工作,同一时间只有一台物理路由器对外提供服务,这台物理路由器被称为主路由器(处于MASTER角色)。一般情况下MASTER由选举算法产生,它拥有对外服务的虚拟IP,提供各种网络功能,如ARP请求、ICMP、数据转发等。而其他物理路由器不拥有对外的虚拟IP,也不提供对外网络功能,仅仅接收MASTER的VRRP状态通告信息,这些路由器被统称为备份路由器(处于BACKUP角色)。当主路由器失效时,处于BACKUP角色的备份路由器将重新进行选举,产生一个新的主路由器进入MASTER角色继续提供对外服务,整个切换过程对用户来说完全透明。 |
3 | 在一个虚拟路由器中,只有处于MASTER角色的路由器会一直发送VRRP数据包,处于BACKUP角色的路由器只接收MASTER发过来的报文信息,用来监控MASTER运行状态,因此,不会发生MASTER抢占的现象,除非它的优先级更高。而当MASTER不可用时,BACKUP也就无法收到MASTER发过来的报文信息,于是就认定MASTER出现故障,接着多台BACKUP就会进行选举,优先级最高的BACKUP将成为新的MASTER,这种选举并进行角色切换的过程非常快,因而也就保证了服务的持续可用性。 |
2.3、Keepalived的体系结构
Keepalived是一个高度模块化的软件,结构简单,但扩展性很强,下图是官方给出的Keepalived体系结构拓扑图。
Keepalived的体系结构从整体上分为两层【用户空间层(User Space)】和【内核空间层(Kernel Space)】 | |
序号 | 说明 |
1 | 内核空间层处于最底层,它包括IPVS和NETLINK两个模块。 IPVS模块是Keepalived引入的一个第三方模块,通过IPVS可以实现基于IP的负载均衡集群。IPVS默认包含在LVS集群软件中。Keepalived最初就是为LVS提供服务的,由于Keepalived可以实现对集群节点的状态检测,而IPVS可以实现负载均衡功能,因此,Keepalived借助于第三方模块IPVS就可以很方便地搭建一套负载均衡系统。 |
2 | 有个误区(即:由于Keepalived可以和IPVS一起很好地工作,因此很多初学者都以为Keepalived就是一个负载均衡软件)这种理解是错误的: 《1》在Keepalived中,IPVS模块是可配置的,如果需要负载均衡功能,可以在编译Keepalived时打开负载均衡功能,反之,也可以通过配置编译参数关闭。 《2》NETLINK模块主要用于实现一些高级路由框架和一些相关的网络功能,完成用户空间层Netlink Reflector模块发来的各种网络请求。 |
3 | 用户空间层位于内核空间层之上,Keepalived的所有具体功能都在上图中看到。 |
Keepalived是用纯ANSI/ISO C编写的。该软件围绕一个中央I/O多路复用器进行连接,以提供实时网络设计。主要的设计重点是在所有元素之间提供同质的模块化。为了确保健壮性和稳定性,守护进程被切分为3个不同进程:
《1》一个极简的父进程,负责fork和监控子进程。
《2》两个子进程,一个负责VRRP框架,另一个负责健康检查。
父进程监控框架称为watchdog,设计是每个子进程打开一个accept unix域套接字,然后在守护进程引导时,父进程连接到那些unix域套接字并向子进程发送周期性(5秒)的hello数据包。如果父进程无法向远程连接的unix域套接字发送hello数据包,则只需重启子进程。
每个子进程都有自己的调度I/O多路复用器,这种方式优化了VRRP调度抖动,因为VRRP调度比健康检查更敏感/关键。这种拆分设计最小化了健康检查依赖库的使用,并将其自己的操作最小化到空闲主循环,以避免由自身引起的故障。
三、其他资料
LVS项目中的有关中文文档http://www.linuxvirtualserver.org/zh/软件设计 — keepalived 1.4.3 文档
https://keepalived-doc.readthedocs.io/zh-cn/latest/%E8%BD%AF%E4%BB%B6%E8%AE%BE%E8%AE%A1.html