前言：

    在很多场景中，服务的不间断及高可用性是非常重要的。不光要有负载均衡机制，虽然它在一定的场景中能实现一定的高可用性。（出门左转有过介绍）当其中的一台RealServer宕机后，客户多刷新几次页面，调度器还是能将请求转到其他的服务器上，不至于彻底挂掉。但是当调度器宕机后呢？这时就需要用到一些机制来实现系统的高可用性了。

    为了避免一台服务器出现单点故障，为了实现高可用性就得在服务器的旁边在配置另一台服务器，当它宕机后，旁边这台接替它的工作继续服务。（或者多台，n台提供服务，m台作为候补~，一般地都是奇数台服务器）

    这时就需要考虑些问题了（这里以web服务为例）：

    假设节点1提供web服务，节点2在旁边作替补。首先两人得实现通信，node2能知道node1什么时候挂掉了。当node1挂掉了，node2如何代替它来实现web服务？这就需要知道一个web服务需要些什么东西了（例如：node1的IP地址，httpd服务，文件系统等等）这些都把它叫做“资源”。再者，这些资源怎么从node1送到node2上？谁来决定资源给谁，让谁来提供服务？等等这些问题需要解决。

   下面先用一张图来解释我们是如何解决这些问题的：

    这幅图很好了说明这种框架具体是如何实现高可用性的：

先是最底下的信息层：

    两个节点通过串行线或者以太网连接来传递“心跳信息，通报健康状态，成员关系等”。

第二层是Resource Allocation(资源分配)：

    CRM（Cluster Resource Manager）集群资源管理器；

    LRM：（Local Resource Manager）本地资源管理器（只负责本地的事物通知）；    

    PE（Policy Engine）策略引擎。这个只有在DC（Designated Coordinator）指定的协调员（类似于集群中的首领）上才有；

    CLB（Cluster Information Base）基本集群信息，其中XML是扩展标记语言，用来规定交互格式。

最上面那层叫RA（Resource Agent）资源代理。