Heartbeat3.x应用全攻略之:概念组成及工作原理

简介:
一、Heartbeat的概念组成以及工作原理
1、 heartbeat的概念 
   Heartbeat是Linux-HA项目中的一个组件,也是目前开源HA项目中最成功的一个例子, Linux-HA的全称是High-Availability Linux,这个开源项目的目标是:通过社区开发者的共同努力,提供一个增强linux可靠性(reliability)、可用性(availability)和可服务性(serviceability)(RAS)的群集解决方案.
   Heartbeat提供了所有 HA 软件所需要的基本功能,比如心跳检测和资源接管、监测群集中的系统服务、在群集中的节点间转移共享 IP 地址的所有者等.
Linux-HA的官方网站: http://www.linux-ha.org  
                    http://hg.linux-ha.org 
 
2、 HA集群相关术语 
(1) 节点(node) 
运行heartbeat进程的一个独立主机,称为节点,节点是HA的核心组成部分,每个节点上运行着操作系统和heartbeat软件服务,在heartbeat集群中,节点有主次之分,分别称为主节点和备用/备份节点,每个节点拥有唯一的主机名,并且拥有属于自己的一组资源,主节点上一般运行着一个或多个应用服务。而备用节点一般处于监控状态。
(2)资源(resource) 
资源是一个节点可以控制的实体,并且当节点发生故障时,这些资源能够被其它节点接管,heartbeat中,可以当做资源的实体有:
磁盘分区、文件系统、IP地址、应用程序服务、NFS文件系统
(3)事件(event) 
也就是集群中可能发生的事情,例如节点系统故障、网络连通故障、网卡故障、应用程序故障等。这些事件都会导致节点的资源发生转移,HA的测试也是基于这些事件来进行的。 
(4)动作(action) 
事件发生时HA的响应方式,动作是由shell脚步控制的,例如,当某个节点发生故障后,备份节点将通过事先设定好的执行脚本进行服务的关闭或启动。进而接管故障节点的资源。
 
3、 Heartbeat的组成 
(1) Heartbeat的结构
Heartbeat1.x和2.0.x版本的结构十分简单,各个模块都集中在heartbeat中,到了3.0版本后,整个heartbeat项目进行了拆分,分为不同的项目来分别进行开发。 
   Heartbeat2.0.x之前的版本具有的模块:
heartbeat: 节点间通信检测模块 
ha-logd: 集群事件日志服务 
CCM(Consensus Cluster Membership):集群成员一致性管理模块 
LRM (Local Resource Manager):本地资源管理模块 
Stonith Daemon: 使出现问题的节点从集群环境中脱离 
CRM(Cluster resource management):集群资源管理模块 
Cluster policy engine: 集群策略引擎 
Cluster transition engine:集群转移引擎
Heartbeat3.0拆分之后的组成部分:
Heartbeat:将原来的消息通信层独立为heartbeat项目,新的heartbeat只负责维护集群各节点的信息以及它们之前通信;
Cluster Glue:相当于一个中间层,它用来将heartbeat和pacemaker关联起来,主要包含2个部分,即为LRM和STONITH。
Resource Agent:用来控制服务启停,监控服务状态的脚本集合,这些脚本将被LRM调用从而实现各种资源启动、停止、监控等等。
Pacemaker:也就是Cluster Resource Manager (简称CRM),用来管理整个HA的控制中心,客户端通过pacemaker来配置管理监控整个集群。
Pacemaker 提供了多种用户管理接口,分别如下:
1)crm shell:基于字符的管理方式;
2)一个使用Ajax Web配置方式的web konsole窗口;
3)hb_gui ,即heartbeat的gui图形配置工具,这也是原来2.1.x的默认GUI配置工具;
4)DRBD-MC,一个基于Java的配置管理工具。
 
(2) Pacemaker内部组成及与各模块之间关系

(3) Heartbeat3.x内部组成及之间关系 

 

(4) Heartbeat各个版本之间的异同

与1.x风格相比,Heartbeat2.1.x版本之后功能变化如下:

1)保留原有所有功能

        如,网络,heartbeat ,机器down时均可切换资源。

2)自动监控资源

        默认情况下每2分钟检测资源运行情况,如果发现资源不在,则尝试启动资源, 如果60s后还未启动成功,则资源切换向另节点。时间可以修改。

3)  可以对各资源组实现独立监控.

        比如apache运行在node1上,tomcat运行在node2上,Heartbeat可同时实现两台主机的服务监控。

4)同时监控系统负载

        可以自动将资源切换到负载低的node上。

Heartbeat官方最后一个STABLE release 2.x 版本是2.1.4,Heartbeat 3官方正式发布的首个版本是3.0.2,Heartbeat 3与Heartbeat2.x的最大差别在于,Heartbeat3.x按模块把的原来Heartbeat2.x拆分为多个子项目,但是HA实现原理与Heartbeat2.x基本相同。配置也基本一致。 

(5) Heartbeat集群的一般拓扑图 

未完待续!

本专题相关内容

Heartbeat3.x应用全攻略之:安装、配置、维护  http://ixdba.blog.51cto.com/2895551/746271

Heartbeat3.x应用全攻略之: 测试Heartbeat的HA功能  http://ixdba.blog.51cto.com/2895551/747510
















本文转自南非蚂蚁51CTO博客,原文链接: http://blog.51cto.com/ixdba/745228,如需转载请自行联系原作者



相关文章
|
4月前
|
JSON 负载均衡 网络协议
Rpc编程系列文章第二篇:RPC框架设计目标
Rpc编程系列文章第二篇:RPC框架设计目标
|
4月前
|
存储 网络协议 Dubbo
Rpc编程系列文章第一篇:RPC概述和架构演变
Rpc编程系列文章第一篇:RPC概述和架构演变
|
9月前
|
存储 Kubernetes 负载均衡
【k8s 系列】k8s 学习二十六,有状态的应用如何部署 1?
前面我们分享很多关于 K8S 的内容,有没有发现 pod 都是无状态,RS / RC 管理的 pod 也是无状态的,我们可以任意删除一个 pod,副本管理器又会马上给我们创建一个 pod 那么如果咱们的这个 pod 是有挂载持久卷的,那么我们用老方法可还行?
154 0
|
9月前
|
缓存 运维 Kubernetes
【k8s 系列】k8s 学习二十七 - 7,k8s 自身原理之高可用
说到高可用,咱们在使用主机环境的时候(非 k8s),咱做高可用有使用过这样的方式: • 服务器做主备部署,当主节点和备节点同时存活的时候,只有主节点对外提供服务,备节点就等着主节点挂了之后,立刻补位
129 0
|
9月前
|
Linux 虚拟化 Windows
嵌入式Linux开发环境搭建之三---网络的设置
嵌入式Linux开发环境搭建之三---网络的设置
121 0
|
11月前
|
消息中间件 存储 缓存
RabbitMQ:第一章:6 种工作模式以及消息确认机制(理论与代码相结合)
RabbitMQ:第一章:6 种工作模式以及消息确认机制(理论与代码相结合)
|
缓存 负载均衡 算法
精华推荐 | 深入浅出学习透析Nginx服务器的基本原理和配置指南「Keepalive性能分析实战篇」
精华推荐 | 深入浅出学习透析Nginx服务器的基本原理和配置指南「Keepalive性能分析实战篇」
191 0
精华推荐 | 深入浅出学习透析Nginx服务器的基本原理和配置指南「Keepalive性能分析实战篇」
|
负载均衡 网络协议 算法
深入浅出学习透析Nginx服务器的基本原理和配置指南「负载均衡篇」
深入浅出学习透析Nginx服务器的基本原理和配置指南「负载均衡篇」
145 0
深入浅出学习透析Nginx服务器的基本原理和配置指南「负载均衡篇」
|
运维 Unix 应用服务中间件
深入浅出学习透析 Nginx 服务器的基本原理和配置指南「运维操作实战篇」
深入浅出学习透析 Nginx 服务器的基本原理和配置指南「运维操作实战篇」
600 0
深入浅出学习透析 Nginx 服务器的基本原理和配置指南「运维操作实战篇」