HeartBeat？你到底要干什么！

xian123

　　上一篇博客我写了通过使用HeartBeat的简单配置来实现一个完整的高可用集群的方案，说白了，配置真的非常简单，安装几个软件，定义几个参数，写一下配置文件，一运行，搞定了~可以说我们使用了最简单的方式实现了一个听起来挺犀利的词，高可用集群。
　　但是HeartBeat到底在这过程中都干了什么？做了什么，为什么架构图上要出现“抢夺”这个词？难道HeartBeat是强盗？劫匪？
　　这篇博客，就一举通过HeartBeat揭开高可用集群的秘密！

　　首先我们知道高可用集群(HA)，就要像其名字一样，高可用，那么它带给人们的就是24*365不间断运行，你很难想象如果哪天你正在银行存款，刚存了10W块钱进去，立刻再一查，发现竟然没存上？！这时候工作人员很抱歉的告诉你，由于银行内部的服务器刚才断线了0.5秒，导致你现在这笔存款不翼而飞了……那时候的你抓狂不？所以，高可用集群就是为了解决这个问题而存在的。
　　它最起码的要保证我们的服务器必须不能因为一台服务器的宕机而导致全盘皆输~
　　我们通过两台或者两台以上的服务器，来提供相同的服务，虽然两台机子都开着，但是同时工作的只有一台，此时正在工作的这个主机叫做主节点，而处于暂时检测随时准备替代主节点的那个主机叫备节点。这样，当主节点因为某些原因宕机之后，备节点会立刻接替主节点的任务，并且开始提供服务。
　　但是问题出现了，备节点如何去检测主节点呢？这时候我们就要用到心跳信息了。心跳信息，是主机通过向外发出一种信号，来证明自己还活着，以告知其他备主机只需要一直检测状态就行，而不需要来瓜分自己的资源。于是，备节点们通过主节点发出的心跳信息，来不断的确定主节点活着，自己不需要去工作。
　　当然，现实的问题总比我们设计好的要差很远，现实的问题就是，我们的主节点太忙了，它已经忙到没有时间去向外发送心跳信息了，于是一个新的问题出现了。备节点们很高兴的发现自己在规定的周期内没有检测到主节点发出的心跳信息，于是备节点们一个个高兴的准备启动了，以便能够接替主节点的所有任务。但是辛苦的主节点此时并没有任何问题，还正在欢快的忙碌着得时候，忽然发现了意见不妙的事情：自己的IP没了？服务也没了？用户在自己身上的连接瞬间被转移到其他的地方了！
　　主节点立刻就意识到了有人抢它的饭碗，愤怒的主节点立刻运行了一个机制再次把资源抢了回来。一抢回来不要紧，备节点依然因为主节点太忙而收不到主节点的心跳信息，于是，一个恶性循环开始了，主节点和备节点他们抢来抢去，直接导致我们用户的数据各种出错，各种无法读写。这种因为集群节点各行其事，导致资源哄抢的问题就叫做脑裂（Split-brain）。
　　毕竟这些节点主机都是人设计的，当我们发现问题，改正就行了。于是，我们设计出了一个机制节点级别的隔离机制。常用的叫做STONITH（Shoot The Other Node In The Head）爆头机制，一旦自己抢到资源，就立刻把其他节点主机的电源给掐断，让那个节点永远的不能跟自己抢夺资源。而这种机制就是专门来解决脑裂问题的。
　　当然，我们不能单纯的直接将电源切断，那样我们的当前节点正好宕机的话，那岂不是就再也没有备节点帮它提供服务了？所以我们又出了一种叫做资源级别的隔离机制，这种隔离只隔离服务器提供的资源，而不对服务器造成其他的什么损害。
　　但是，我们刚才的情况都仅仅针对了只有一个主节点和一从节点，如果有一堆节点怎么办？到底谁抢呢？难道是抢得快的抢的多，抢的慢的就抢的少么？呵呵，虽然备节点们一个个都像强盗一样在抢着各种资源，但是我们主节点可以规定，到底只允许哪个强盗在自己死后获得遗产，获得资源。而这种在自己死后控制资源转移的方式就叫做故障转移（failover）。
　　对于很多节点，他们都在提供不同的服务，不管哪个节点上的服务挂了，都会有其他的节点将其资源抢夺过来以保证服务的正常运行，那么到底挂掉多少节点，我们的服务才都不能运行了呢？这时候我们就需要一个机制，来计算整个多节点集群的工作是否处于一个正常状态，而计算的方法，我们采用投票制，每一个节点都握有票，要求集群的总体票数要超过半数才能运行，而我们投的票数叫做法定代表人数（quorum），一般必须是半数以上才能够确保一个多节点集群是处于正常状态的。而整个总管投票，决定投票的节点就叫做DC。
　　那么，一个完整的高可用集群到底是以什么结构来工作的呢？

　　第一层（最底层），Messaging and Infrastructure 信息和基础架构层，又称心跳层
　　用于传递心跳信息，和其他集群事物信息,向别人通知当前节点是否正常工作。
　　第二层：Membership Layer 成员关系层，
　　最重要的是CCM，这是个服务，根据第一层提供的信息，来计算成员关系，上面是否要采取各种动作，需要这一层提供的成员关系来提供功能。CCM还要为所有节点的状态信息生成一个所有节点的预览图，而且是以本节点作为主视角，确保本节点可以在某些情况下采取某种动作
　　第三层：Resource Allocation Layer资源分配层：（真正实现高可用服务层）
　　1.CRM（集群资源管理器），它运行在HA的每一个节点上。定义资源的特定属性，哪些资源谁先谁后，哪些资源运行在哪个节点上。资源管理的每一个动作都需要通过CRM来实现。在每一个节点上CRM都维护有一个CIB(集群信息机库 XML文档)，而只有工作在DC上的文档是可以修改的，其他CIB都是复制DC上的那个文档而来的。当某个节点发生故障之后，是由DC来决定是否抢夺资源。
　　2.CIB（集群信息库），这个库其实就是XML文档：在内存当中的集群级别的内存文件，工作的时候是常驻内存的，并且需要通知给其他节点的，在红帽里有一个叫CCSD的专门用于同步文件。配置它需要使用cibadmin命令，或者使用CRM等，也可以使用HeartBeat提供的前台处理窗口来配置。
　　3.PE和TE。任何时候资源的控制都需要又DC来控制，而PE是进行策略决策的，TE是来决策执行的。
　　4.LRM（本地资源管理器）是执行CRM传递过来的在本地执行某个资源的执行和停止的具体执行人，相对于资源来讲，CRM是决策者，LRM是执行者。这样CRM是管理全局资源，LRM则是管理本地资源的。
　　XML文档：各节点之间最通用的配置文档。需要修改的时候只需要修改DC的XML文档。而当修改其他各节点上的XML文件，其实都是在修改DC上的XML文件，而这种样实现需要使用Cluster Information Base来实现。
　　第四层：Resource Layer，资源层
　　通过Resource Agents（RA）,通过脚本来实现的：资源的代理，启动、停止、重新载入配置文件、获取状态信息等，真正实现在本机或者某个节点上管理某种资源的。这些都是LSB脚本。
　　还有一种是OCF（Open Clustering Framework）脚本。比LSB稍微强大一点的脚本。通用性比LSB更好。
　　而我们使用的HeartBeat，就是这样一款，能够控制整个HA工作的，定义如何分配资源的，高可用集群的实现软件。