一、高可用基本概念
均无故障时间比上，平均无故障时间加平均故障修复时间
提高高可用的主要途径
最主要的途径是使用高可用冗余
| 硬件 | |
| 软件 | kiss keep it simple stupid |
二、高可用集群基本结构
最下面是Messageing layer信息传递层，使用corosync来传递心跳信息，
上一层是资源分配层，最主要的应用组件是CRM，在这一层推举长生一个DC，DC上运行了两个进程，pe（决策引擎） te（事务引擎）
策略引擎,policy engine，获取所有的节点信息，决定资源怎么分配，资源怎样启动，怎样启动，这样要通过资源约束来实现，资源约束通过配置接口实现。各个节点之间通过xml传递数据。pe通过CIB接受messaging layer信息。
使用CIB来配置xml文件 cluster information base（集群信息库） 。在配置集群时，可以连接到任何节点的CRM，配置cib，然后cib信息可以同步到DC中，DC再通知给 所有的CIB中。
CRM通过LRM（本地资源管理器）管理执行，LRM调用RA来具体实现。
简单描述下整个过程，在最底部的messaging layer，所有的节点都安装了heartbeat或者corosync等软件，节点之间能够互相通信，然后在上一层，资源管理层，CRM来统筹管理由messaging传递过来的信息，托举一个DC，DC运行了两个进程，pe和te，pe是策略引擎，它根据CIB（集群资源仓库）收集到的所有的资源配置信息（获取当前互动节点的信息），进行决策。连接到任何一个节点的CRM都可以配置CIB，然后就可以同步到DC中，DC再通知所有的节点。然后CRM通过LRM来管理资源管理，而LRM则调用RA来具体控制资源。
在高可用的情况下，所有的资源都是由CRM控制LRM调用RA来控制，自动启动的，因此，不用让资源服务开机自动启动。一定要保证。可以通过chkconfig service off来停止开机自动启动服务
1. 高可用的基本原理及其框架
DC发现集群中有一个节点发生故障，剔除掉，然后根据在CRM中配置的规则（比如倾向性，倾向于优先使用哪个备用服务器），然后通过底层信息将集群事务决策传递给备节点，备节点CRM收到来自底层的信息后，通知LRM，调用RA，启动资源。
实现服务的高可用。一个服务由多个资源组成，例如一个web服务需要有vip、web服务、网页文件，又如lvs服务，至少有ipvs和规则等组成才能算是一个完整的服务。
1) 各节点之间的基准信息传递层，一般情况下是由主节点通过广播的方式传递心跳信息给备用节点。心跳信息包含了服务状态信息等，这里的服务器状态信息主要是服务器服务的运行状态。通过服务或者API的方式向其他节点提供。根据这些心跳信息，来进行集群事务决策，以决定启用多个备用节点中的哪个节点，本层次无法提供该功能
该层称为信息层messageing layer
典型软件：
? heartbeat：heartbeat v1 heartbear v2 heartbear v3
? corosync:OpenAIS定义了一套规范，分隔为corosync和一组api。这里corosync是主要使的，只用于实现messaging layer，不实现资源管理的功能。
? cman:cluser manger,红帽的，是对OpenAIS的一种实现。
2) 拥有能力根据底层信息层通过api等传递的心跳信息来进行集群事务决策，叫做ha_aware，它才是真正来进行决策的软件。但是该软件复杂， 因此大部分的软件不具备此功能。因此，我们将其提取出，作为一个独立的公共模块存在，安装在每个节点之上。能够实现集群事务决策，剔除无效的节点，上线重新设置好的节点，设置主节点，辅助节点，选举leader(DC)。并且能够将底层信息传递给更上层。
通过该层次，系统管理员可以通过接口来定义服务(以资源作为基本的管理单元，资源组成了服务)，然后该层次依据决策启动节点上的服务（注意，高可用集群中，任何资源都不应该自行启动，而是由CRM管理启动与否；）
该层被称为资源分配层，最主要的组件是CRM：Cluster Resources Manager。依赖与底层的心跳信息
典型软件：
? heartbeat v1:haresources（hearbeat自带功能，配置接口是一个配置文件：haresource）
? heartbear v2:可以作为独立进程:crm（各个节点均运行进程crmd，5566，客户端使用crm进行交互（shell），完成配置），也有图形界面heartbeat-GUI
? heartbeat v3:分隔多个项目 heartbear（底层信息传递）+pacemaker（CRM资源管理）+cluster-glue。pacemaker不仅可以与heartbear一起工作，也可以与corosync一起工作，这个时候需要使用cluster-glue进行粘合。
pacemaker：仍然使用crmd运行，配置接口使用crm(红帽对应的为psc)，对应的GUI接口为hwk,LCMC,pacemaker-mgmt
? rgmanager:cman使用的工具，resource group manager。故障转移域,failover domain。
RHCS:Redhat Cluster Suite（套件），配置接口，conga，全生命周期的配置接口
3) 当节点发生故障时，心跳信息传递给CRM，CRM通过集群决策，决定哪个备用节点启动，但是CRM没有能力启动节点上的服务（资源），因此需要借助于RA来实现
RA：Resource agent（服务启动的脚本？），能够被CRM调用，用于实现在节点上对某资源进行管理的工具，通常情况下是一个脚本。必须能够接受参数｛start|stop|restart|status｝。CRM会每隔固定时长（自定义）检查资源状态，因此status必须是runing或者stopped，而不能是否定状态的短语。
RA类型：
4) LRM:CRM进行决策，LRM进行实际操作。一般由CRM提供。
2. 在使用主备模型中，如果主节点挂掉，那么请求过来的报文应该找到备节点，但是，由于封装报文的目标mac地址仍然是主节点，可能无法到达备节点。所以，使用欺骗式的广播解析：欺骗式arp
3. 集群分裂：脑裂。在集群中，很有可能出现这样的情况，集群中节点之间不能相同通信，导致集群被分裂成多个集群。导致资源争用。不同的节点都去读取磁盘文件，如果在脑裂的集群中使用了共享的文件磁盘，那么就会导致磁盘挂掉。分裂成的多个集群，必定是一个数量多，一个数量少，经过vote，的票数多（大于半数）的那个集群工作（quarum合法人数），另外的机器要放弃成为集群成员（但服务很有可能仍然存在）。放弃成为集群成员后仍然有可能在使用共享资源，无法卸载资源。为了实现脱离集群的节点不再访问系统资源，要进行资源隔离。避免资源争用，隔离资源。
资源隔离的主要方法：1、节点级别隔离：STONITH，使用电源交换机，断掉电源。
2、资源级别隔离：切断交换机接口
4. 高可用集群中：初始节点数大于2，并且总数应为奇数。仲裁。
如果集群中只有两个节点，由于无法进行有效的投票，因此，需要引入第三个节点，ping node，就是路由器上的接口，我们认为能够与这个接口互联的设备是有效的可用的节点。ping node可以成为仲裁设备，协助判断哪方为活跃集群节点。 红帽的解决方案是使用仲裁磁盘（q disk），在磁盘上写入数据，更新数据位。一旦数据位没有更新，则说明节点下线，备用节点启用。一旦主节点重新上线，直接kill掉备用节点，接管。
5. HA集群的工作模型
A/P:two nodes 工作于主备模型
N-M: N > M,N个节点，M个服务；活动节点为N，备用节点N-M个
N-N：N个节点，N个服务
A/A：双主模型，主要的应用场景是，后台有大量的RS，一台Director无法承受压力，部署两台Director，同时启动两台Director，也是就说同时运行两个ipvs服务。在他们之前使用DNS轮询功能进行负载均衡。一旦一个ipvs服务发生故障，只需要将其中一个vip转移到另一个ipvs服务上即可。
6. 资源转移，资源约束（重要）
讨论：如何让web service的三个资源vip httpd 及filesystem运行在同一节点上
1、 排列约束:明确三个资源在同一节点
2、 资源组（resource group）：定义成为一个组，然后控制一个组的资源是否在一个节点上运行
7. 如果节点不再是集群节点成员时，如何处理运行于当前节点的资源？（集群策略）
| stopped | 停止服务 |
| ignore | 忽略，继续运行 |
| freeze | 冻结，已经连接的请求继续响应，新的请求不再响应 |
| suicide | 自杀，将服务kill掉 |
8. 一个资源刚配置完成时，是否启动？
9. 资源类型