Apr
6
高可用集群是指一组通过硬件和软件连接起来的独立计算机,它们在用户面前表现为一个单一系统,在这样的一组计算机系统内部的一个或者多个节点停止工作,服务会从故障节点切换到正常工作的节点上运行,不会引起服务中断。从这个定义可以看出,集群必须检测节点和服务何时失效,何时恢复为可用。这个任务通常由一组被称为“心跳”的代码完成。在Linux-HA里这个功能由一个叫做heartbeat的程序完成。
Heartbeat是Linux-HA工程的一个组件,自1999年开始到现在,发布了众多版本,是目前开源Linux-HA项目最成功的一个例子,在行业内得到了广泛的应用。
下面以2.1.3版本为例讲解其框架和基础概念。
一、基本框架
Heartbeat分1.x和2.x两个大版本,v2版本是可以兼容之前v1的配置文件的,但从功能的角度来看,v2要强不少:
Heartbeat 2.x基于集群资源管理器(Cluster Resource Manager-CRM)CRM模式:可以支持最多16个节点,这些模式使用基于XML的集群信息(Cluster Information Base-CIM)配置。CIB文件(/var/lib/heartbeat/crm/cib.xml)会在各个节点间自动复制,可以实现下面的对象和动作:
二、基础概念
Heartbeat包括以下几个组件:
三、可靠消息通信
以下内容转自:互动百科
Heartbeat通过插件技术实现了集群间的串口、多播、广播和组播通信,在配置的时候可以根据通信媒介选择采用的通信协议,heartbeat启动的时候检查这些媒介是否存在,如果存在则加载相应的通信模块。这样开发人员可以很方便地添加新的通信模块。
对于高可用集群系统,如果集群间的通信不可靠,那么很明显集群本身也不可靠。Heartbeat采用UDP协议和串口进行通信,它们本身是不可靠的,可靠性必须由上层应用来提供。那么怎样保证消息传递的可靠性呢?
Heartbeat通过冗余通信通道和消息重传机制来保证通信的可靠性。Heartbeat检测主通信链路工作状态的同时也检测备用通信链路状态,并把这一状态报告给系统管理员,这样可以大大减少因为多重失效引起的集群故障不能恢复。例如,某个工作人员不小心拨下了一个备份通信链路,一两个月以后主通信链路也失效了,系统就不能再进行通信了。通过报告备份通信链路的工作状态和主通信链路的状态,可心完全避免这种情况。因为这样在主通信链路失效以前,就可以检测到备份工作链路失效,从而在主通信链路失效前修复备份通信链路。
Heartbeat通过实现不同的通信子系统,从而避免了某一通信子系统失效而引起的通信失效。最典型的就是采用以太网和串口相结合的通信方式。这被认为是当前的最好实践,有几个理由可以使我们选择采用串口通信:
不管是采用串口还是以太网IP协议进行通信,heartbeat都实现了一套消息重传协议,保证消息包的可靠传递。实现消息包重传有两种协议,一种是发送者发起,另一种是接收者发起。
对于发送者发起协议,一般情况下接收者会发送一个消息包的确认。发送者维护一个计时器,并在计时器到时的时候重传那些还没有收到确认的消息包。这种方法容易引起发送者溢出,因为每一台机器的每一个消息包都需要确认,使得要发送的消息包成倍增长。这种现像被称为发送者(或者ACK)内爆(implosion)。
对于接收者发起协议,采用这种协议通信双方的接收者通过序列号负责进行错误检测。当检测到消息包丢失时,接收者请求发送者重传消息包。采用这种方法,如果消息包没有被送达任何一个接收者,那么发送者容易因NACK溢出,因为每个接收者都会向发送者发送一个重传请求,这会引起发送者的负载过高。这种现像被称为NACK内爆(implosion)。
Heartbeat实现的是接收者发起协议的一个变种,它采用计时器来限制过多的重传,在计时器时间内限制接收者请求重传消息包的次数,这样发送者重传消息包的次数也被相应的限制了,从而严格的限制了NACK内爆。
Heartbeat是Linux-HA工程的一个组件,自1999年开始到现在,发布了众多版本,是目前开源Linux-HA项目最成功的一个例子,在行业内得到了广泛的应用。
下面以2.1.3版本为例讲解其框架和基础概念。
一、基本框架
Heartbeat分1.x和2.x两个大版本,v2版本是可以兼容之前v1的配置文件的,但从功能的角度来看,v2要强不少:
引用
a)2.x支持CRM管理,资源文件由原来的haresources变为cib.xml;
b)支持ocf、lsb、stonith等格式的resource agent;
c)可以对多资源组进行独立监控,不再需要依赖mon或ldirectord等第三方脚本;
d)支持多节点;
e)提供GUI图形配置和管理工具。
b)支持ocf、lsb、stonith等格式的resource agent;
c)可以对多资源组进行独立监控,不再需要依赖mon或ldirectord等第三方脚本;
d)支持多节点;
e)提供GUI图形配置和管理工具。
Heartbeat 2.x基于集群资源管理器(Cluster Resource Manager-CRM)CRM模式:可以支持最多16个节点,这些模式使用基于XML的集群信息(Cluster Information Base-CIM)配置。CIB文件(/var/lib/heartbeat/crm/cib.xml)会在各个节点间自动复制,可以实现下面的对象和动作:
引用
a)集群节点配置和监控;
b)集群资源,包括属性、优先级、组和依赖性的定制;
c)日志、监控、仲裁和fence标准管理;
d)当服务失败或其中设定的标准满足时,需要执行的动作。
b)集群资源,包括属性、优先级、组和依赖性的定制;
c)日志、监控、仲裁和fence标准管理;
d)当服务失败或其中设定的标准满足时,需要执行的动作。
二、基础概念
Heartbeat包括以下几个组件:
引用
heartbeat – 节点间通信校验模块
CRM - 集群资源管理模块
CCM - 维护集群成员的一致性
LRM - 本地资源管理模块
StonithDaemon - 提供节点重启服务
logd - 非阻塞的日志记录
apphbd - 提供应用程序级的看门狗计时器
Recovery Manager - 应用故障恢复
底层结构–包括插件接口、进程间通信等
CTS – 集群测试系统,集群压力测试
CRM - 集群资源管理模块
CCM - 维护集群成员的一致性
LRM - 本地资源管理模块
StonithDaemon - 提供节点重启服务
logd - 非阻塞的日志记录
apphbd - 提供应用程序级的看门狗计时器
Recovery Manager - 应用故障恢复
底层结构–包括插件接口、进程间通信等
CTS – 集群测试系统,集群压力测试
三、可靠消息通信
以下内容转自:互动百科
Heartbeat通过插件技术实现了集群间的串口、多播、广播和组播通信,在配置的时候可以根据通信媒介选择采用的通信协议,heartbeat启动的时候检查这些媒介是否存在,如果存在则加载相应的通信模块。这样开发人员可以很方便地添加新的通信模块。
对于高可用集群系统,如果集群间的通信不可靠,那么很明显集群本身也不可靠。Heartbeat采用UDP协议和串口进行通信,它们本身是不可靠的,可靠性必须由上层应用来提供。那么怎样保证消息传递的可靠性呢?
Heartbeat通过冗余通信通道和消息重传机制来保证通信的可靠性。Heartbeat检测主通信链路工作状态的同时也检测备用通信链路状态,并把这一状态报告给系统管理员,这样可以大大减少因为多重失效引起的集群故障不能恢复。例如,某个工作人员不小心拨下了一个备份通信链路,一两个月以后主通信链路也失效了,系统就不能再进行通信了。通过报告备份通信链路的工作状态和主通信链路的状态,可心完全避免这种情况。因为这样在主通信链路失效以前,就可以检测到备份工作链路失效,从而在主通信链路失效前修复备份通信链路。
Heartbeat通过实现不同的通信子系统,从而避免了某一通信子系统失效而引起的通信失效。最典型的就是采用以太网和串口相结合的通信方式。这被认为是当前的最好实践,有几个理由可以使我们选择采用串口通信:
引用
(1)IP通信子系统的失效不太可能影响到串口子系统。
(2)串口不需要复杂的外部设备和电源。
(3)串口设备简单,在实践中非常可靠。
(4)串口可以非常容易地专用于集群通信。
(5)串口的直连线因为偶然性掉线事件很少。
(2)串口不需要复杂的外部设备和电源。
(3)串口设备简单,在实践中非常可靠。
(4)串口可以非常容易地专用于集群通信。
(5)串口的直连线因为偶然性掉线事件很少。
不管是采用串口还是以太网IP协议进行通信,heartbeat都实现了一套消息重传协议,保证消息包的可靠传递。实现消息包重传有两种协议,一种是发送者发起,另一种是接收者发起。
对于发送者发起协议,一般情况下接收者会发送一个消息包的确认。发送者维护一个计时器,并在计时器到时的时候重传那些还没有收到确认的消息包。这种方法容易引起发送者溢出,因为每一台机器的每一个消息包都需要确认,使得要发送的消息包成倍增长。这种现像被称为发送者(或者ACK)内爆(implosion)。
对于接收者发起协议,采用这种协议通信双方的接收者通过序列号负责进行错误检测。当检测到消息包丢失时,接收者请求发送者重传消息包。采用这种方法,如果消息包没有被送达任何一个接收者,那么发送者容易因NACK溢出,因为每个接收者都会向发送者发送一个重传请求,这会引起发送者的负载过高。这种现像被称为NACK内爆(implosion)。
Heartbeat实现的是接收者发起协议的一个变种,它采用计时器来限制过多的重传,在计时器时间内限制接收者请求重传消息包的次数,这样发送者重传消息包的次数也被相应的限制了,从而严格的限制了NACK内爆。