注册 登录
  • 欢迎访问"运维那点事",推荐使用Google浏览器访问,可以扫码关注本站的"微信公众号"。
  • 如果您觉得本站对你有帮助,那么可以扫码捐助以帮助本站更好地发展。

高可用软件keepalived详解

集群和存储 彭东稳 13058次浏览 已收录 1个评论

一、高可用软件阐述

在高可用软件领域,我们可能常会听到Heartbeat、Corosync、Pacemaker、keepalived等软件。常见有人问Heartbeat、Corosync、Keepalived这三个集群组件我们到底选哪个好呢?首先我想说明的是,Heartbeat、Corosync是属于同一类型,Keepalived与Heartbeat、Corosync,根本不是同一类型的。Keepalived使用的vrrp协议方式,虚拟路由冗余协议 (Virtual Router Redundancy Protocol,简称VRRP);Heartbeat或Corosync是基于主机或网络服务的高可用方式;简单的说就是,Keepalived的目的是模拟路由器的高可用,Heartbeat或Corosync的目的是实现Service的高可用。所以一般Keepalived是实现前端高可用,常用的前端高可用的组合有,就是我们常见的LVS+Keepalived、Nginx+Keepalived、HAproxy+Keepalived。而Heartbeat或Corosync是实现服务的高可用,常见的组合有Heartbeat v3(Corosync)+Pacemaker+NFS+Httpd 实现Web服务器的高可用、Heartbeat v3(Corosync)+Pacemaker+NFS+MySQL 实现MySQL服务器的高可用。总结一下,Keepalived中实现轻量级的高可用,一般用于前端高可用,且不需要共享存储,一般常用于两个节点的高可用。而Heartbeat(或Corosync)一般用于服务的高可用,且需要共享存储,一般用于多节点的高可用。

这个问题我们说明白了,又有人会问了,那heartbaet与corosync我们又应该选择哪个好啊,我想说我们一般用corosync,因为corosync的运行机制更优于heartbeat,就连从heartbeat分离出来的pacemaker都说在以后的开发当中更倾向于corosync,所以现在corosync+pacemaker是最佳组合。但说实话我对于软件没有任何倾向性,所以我把所有的集群软件都和大家说了一下,我认为不管什么软件,只要它能存活下来都有它的特点和应用领域,只有把特定的软件放在特定的位置才能发挥最大的作用,那首先我们得对这个软件有所有了解。学习一种软件的最好方法,就是去查官方文档。好了说了那么多希望大家有所收获,下面我们来说一说keepalived。

二、Keepalived详解

Keepalived是什么?

Keepalived是集群管理中保证集群高可用的一个服务软件,用来防止单点故障。Keepalived起初就是为了LVS调度节点高可用而设计的,专门用来监控集群系统中各个服务节点的状态。如果某个服务节点出现异常,或工作出现故障,Keepalived将检测到,并将出现故障的服务节点从集群系统中剔除,也就是替LVS做了对后端realserver的健康状态监测。而当故障节点恢复正常后,Keepalived又可以自动将此服务节点重新加入到服务器集群中。这些工作全部自动完成,不需要人工干涉,需要人工完成的只是修复出现故障的服务节点。

Keepalived后来实现了VRRP协议的功能,基于VRRP协议来实现的LVS服务高可用方案,可以利用其来避免单点故障。一个LVS服务会有2台服务器运行Keepalived,一台为主服务器(MASTER),一台为备份服务器(BACKUP),但是对外表现为一个虚拟IP,主服务器会发送特定的消息给备份服务器,当备份服务器收不到这个消息的时候,即主服务器宕机的时候, 备份服务器就会接管虚拟IP,继续提供服务,从而保证了高可用性。Keepalived是VRRP的完美实现,因此在介绍keepalived之前,先介绍一下VRRP的原理。

VRRP工作机制?

先看两个概念:VRRP路由器和VRRP虚拟路由器

1. VRRP路由器

就是一台物理路由器,只不过上面运行了VRRP协议实现的程序,一台VRRP物理路由器可以位于多个虚拟路由器。

2 .VRRP虚拟路由器

所谓虚拟就是说并不是实际存在的,虚拟路由器通常由多台物理的VRRP路由器通过某种方式组成的,就好比这些物理的路由器都丢到一个池里面去,整个pool对外看起来就像是一台路由器,其实内部有多台虚拟路由器。

然后再来看一下VRRP的工作机制?

VRRP全称Virtual Router Redundancy Protocol,即虚拟路由冗余协议。可以认为是实现路由器高可用的协议,目的就是为了解决静态路由单点故障。VRRP通过一种竞选协议来动态的将路由任务交给LAN中的虚拟路由器的某台VRRP路由器。将N台提供相同功能的路由器组成一个路由器组,这个组里面有一个master和多个backup,master上面有一个对外提供服务的vip(该路由器所在局域网内其他机器的默认路由为该vip),master会发组播,当backup收不到vrrp包时就认为master宕掉了,这时就需要根据VRRP的优先级来选举一个backup当master。这样的话就可以保证路由器的高可用了。Keepalived就是巧用VRRP协议来实现高可用性(HA)的。

VRRP所有的协议报文都是通过IP多播(multicast)包(多播地址224.0.0.18)形式发送的。虚拟路由器由VRID(范围0-255)和一组IP地址组成,对外表现为一个周知的MAC地址。所以,在一个虚拟路由 器中,不管谁是MASTER,对外都是相同的MAC和IP(称之为VIP)。客户端主机并不需要因为MASTER的改变而修改自己的路由配置,对客户端来说,这种主从的切换是透明的。

在一个虚拟路由器中,只有作为MASTER的VRRP路由器会一直发送VRRP通告信息(VRRPAdvertisement message),BACKUP不会抢占MASTER,除非它的优先级(priority)更高。当MASTER不可用时(BACKUP收不到通告信息), 多台BACKUP中优先级最高的这台会被抢占为MASTER。这种抢占是非常快速的(<1s),以保证服务的连续性。由于安全性考虑,VRRP包使用了加密协议进行加密。

VRRP工作流程?

1) 初始化

路由器启动时,如果路由器的优先级是255(最高优先级,路由器拥有路由器地址),要发送VRRP通告信息,并发送广播ARP信息通告路由器IP地址对应的MAC地址为路由虚拟MAC,设置通告信息定时器准备定时发送VRRP通告信息,转为MASTER状态;否则进入BACKUP状态,设置定时器检查定时检查是否收到MASTER的通告信息。

2) Master

  • 设置定时通告定时器;
  • 用VRRP虚拟MAC地址响应路由器IP地址的ARP请求;
  • 转发目的MAC是VRRP虚拟MAC的数据包;
  • 如果是虚拟路由器IP的拥有者,将接受目的地址是虚拟路由器IP的数据包,否则丢弃;
  • 当收到shutdown的事件时删除定时通告定时器,发送优先权级为0的通告包,转初始化状态;
  • 如果定时通告定时器超时时,发送VRRP通告信息;
  • 收到VRRP通告信息时,如果优先权为0,发送VRRP通告信息;否则判断数据的优先级是否高于本机,或相等而且实际IP地址大于本地实际IP,设置定时通告定时器,复位主机超时定时器,转BACKUP状态;否则的话,丢弃该通告包;

3)Backup

  • 设置主机超时定时器;
  • 不能响应针对虚拟路由器IP的ARP请求信息;
  • 丢弃所有目的MAC地址是虚拟路由器MAC地址的数据包;
  • 不接受目的是虚拟路由器IP的所有数据包;
  • 当收到shutdown的事件时删除主机超时定时器,转初始化状态;
  • 主机超时定时器超时的时候,发送VRRP通告信息,广播ARP地址信息,转MASTER状态;
  • 收到VRRP通告信息时,如果优先权为0,表示进入MASTER选举;否则判断数据的优先级是否高于本机,如果高的话承认MASTER有效,复位主机超时定时器;否则的话,丢弃该通告包;

VRRP ARP查询处理?

当内部主机通过ARP查询虚拟路由器IP地址对应的MAC地址时,MASTER路由器回复的MAC地址为虚拟的VRRP的MAC地址,而不是实际网卡的 MAC地址,这样在路由器切换时让内网机器觉察不到;而在路由器重新启动时,不能主动发送本机网卡的实际MAC地址。如果虚拟路由器开启的ARP代理 (proxy_arp)功能,代理的ARP回应也回应VRRP虚拟MAC地址。

keepalived架构

keepalived也是模块化设计不同模块负责不同的功能,下面是keepalived的相关模块:core、check、vrrp、libipfwc、libipvs-2.4、libipvs-2.6。

core:是keepalived的核心,负责主进程的启动和维护及全局配置文件的加载解析等。

check:负责healthchecker(健康检查),包括了各种健康检查方式以及对应的配置的解析(包括LVS的配置解析)。

vrrp:VRRPD子进程就是来实现VRRP协议的。

libipfwc:liipfwc库是配置LVS时会用到的。

libipvs*:配置LVS时会用到。

PS:注意keepalived和LVS完全是两码事只不过他们各负其责相互配合而已。

三、keepalived配置文件

先简单介绍一下Keepalived的安装,一般使用YUM安装即可:

keepalived只有一个配置文件keepalived.conf,里面主要包括以下几个配置区域,分别是:

global_defs区域

主要是配置故障发生时的通知对象以及机器标识。

vrrp_script区域

提供keepalived维护状态,我们一般进行主从切换测试时都是关闭keepalived或关闭网卡接口,有没有一种方法能实现在不关闭keepalived下或网卡接口来实现维护呢?方法肯定是有的,在keepalived新版本中,支持脚本vrrp_srcipt,具体如何使用大家可以man keepalived.conf查看。下面我们来演示一下具体怎么实现。

然后在vrrp_instance区域使用track_script调用这个脚本,如下:

然后测试时就可以建立/etc/keepalived/down文件,就会完成维护模式切换。

vrrp_instance区域

用来定义对外提供服务的VIP区域及其相关属性。

virtual_server区域

在virtual_server区域外还可以设置virtual_server_group,一般在超大型的LVS中用到,一般LVS用不到这东西,因此不多说。

这里需要重点说几个参数:

persistence_timeout

会话保持时间,单位是秒,这个选项对动态网页是非常有用的,为集群系统中的session共享提供了一个很好的解决方案。有了这个会话保持功能,用户的请求会被一直分配到某个服务节点,直到超过这个会话的保持时间。需要注意的是,这个会话保持时间是最大无响应超时时间,也就是说,用户在操作动态页面时,如果在50秒内没有执行任何操作,那么接下来的操作会被分发到另外的节点,但是如果用户一直在操作动态页面,则不受50秒的时间限制。另外当Keepalived配合LVS一起工作时,关于会话保持还要结合LVS的超时时间(ipvsadm -Ln –timeout)。

HTTP_GET

常用的健康检查方式健康检查方式一共有HTTP_GET、SSL_GET、TCP_CHECK、SMTP_CHECK和MISC_CHECK等。如果使用TCP_CHECK的话配置如下:

sorry_server

如果所有realserver都down机,怎么处理?是不是用户就没法打开,还是提供一下维护页面呢?sorry_server就是用来干这个事情的,当后端realserver都挂掉了之后,就会访问sorry_server定义的主机地址,一般在负载均衡开一个web即可。

四、注意事项

在配置keepalived.conf时,需要特别注意配置文件的语法格式以及出现重复的VIP,因为keepalived在启动时并不检测配置文件的正确性,即使没有配置文件,keepalived也能照样启动,所以一定要保证配置文件的正确性。本人曾经在线上业务就配置过重复的VIP地址和端口,Reload keepalived之后就覆盖了原来的VIP地址和端口从而导致业务出问题了。当发现后立马把此VIP的端口改掉(作用恢复原来的地址),再次reload时发现此操作无法生效,不得以进行了restart操作。

在默认情况下,keepalived在启动时会查找/etc/keepalived/keepalived.conf配置文件,如果配置文件放在了其他路径下,可以通过“keepalived -f”参数指定配置文件的路径即可。


如果您觉得本站对你有帮助,那么可以支付宝扫码捐助以帮助本站更好地发展,在此谢过。
喜欢 (8)or分享 (0)
关于作者:

您必须 登录 才能发表评论!

(1)个小伙伴在吐槽