高可用集群的构架层次：
1. 后端主机层： 这一层主要是正在运行在物理主机上的服务。
2. Message layer： 信息传递层，主要传递心跳信息
2. Cluster Resources Manager(CRM): 集群资源管理器层，这一层是心跳信息传递层管理器。用于管理信条信息的传递和收集
3. Local Resources Manager(LRM): 本地资源管理器层， 用于对于收集到的心跳信息进行资源决策调整。是否转移服务等等
4. Resource Agent(RA): 资源代理层，这一层主要是具体启动或停止具体资源的脚本。遵循{start|stop|restart|status}服务脚本使用格式
各层次实现的软件和对应关系
1. Message layer层：
1） heartbeat v1
2） heartbeat v2
3） heartbeat v3
4）（OpenAIS）corosync
5） cman
2. CRM层
1） heartbeat v1:
使用文本配置接口haresources
2) heartbeat v2:
通过一个crmd服务来实现配置，各节点都需要运行crmd服务，并且使用crmsh或者heartbeat-gui来进行配置
3) heartbeat v3: heartbeat + pacemaker + cluster-glue
pacemaker: 集群资源管理器服务
CLI: crm(SuSE), pcs（redhat）
GUI: hawk, LCMC, pacemaker-mgmt
cluster-glue: 可以做为中间粘合层，使用其他资源管理器例如crmsh
4) cman:
使用rgmanager(resource group manager)实现管理, 具有Failover Domain故障转移域这一特性
也可以使用RHCS（Redhat Cluster Suite）套件来进行管理： Conga的全生命周期接口
5) corosync:
使用rgmanager或者pacemaker
3. LRM层通常和CRM层在实现上是通过CRM的一个组件实现
4. RA层
1） heartbeat legacy: heartbeat的传统类型
2） LSB：/etc/rc.d/init.d/*
3） OCF（Open Cluster Framework）：有提供商提供，有pacemaker，linbit
4） STONITH: 用来联合硬件设备工作，可以把故障机电源强制关闭。
RHEL OR CentOS高可用集群解决方案：
1. RHEL(CentOS)5：
1) 自带： RHCS(cman+rgmanager)
2) 选用第三方：corosync+pacemaker, heartbeat(v1或v2), keepalived
2. RHEL(CentOS)6:
1) RHCS(cman+rgmanager)
2) corosync+rgmanager
3) cman+pacemaker
4) heartbeat v3 + pacemaker
5) keepalived
应用方式：
1） 做前端负载均衡器的高可用：keepalived
2） 做大规模的高用集群：corosync(cman)+pacemaker
资源隔离：解决资源征用问题
1. 场景一：
当集群中分裂出两组子集群，并且两个子集群之间并不能通信时， 两个子集群会发生资源征用。如果两集群同时征用后端存储系统，则会造成灾难性的文件系统崩溃。
为了解决此问题，集群系统引入了投票机制，只有拥有半数以上合法票数的集群才能存活，否则退出集群系统。
votes： 投票权
total： 总票数
quarum： 满足法定人数，半数以上
2. 场景二:
如果集群为偶数时，如果集群分裂，两边可能都掌握相等的票数，因此集群系统不应该为偶数，如果是偶数则需要一个额外的ping节点参与投票。
3. 当分裂的票数不足集群退出集群系统后，为了保证它们永远不会征用资源需要STONITH机制来进行资源隔离。
STONITH具体来说，就是通过硬件设备，使得退出的主机重启或者关机。或者通过交换机阻断推出集群主机的向外通信和资源通信网络
HA集群的工作模型：
1. A/P： two node: 主被模型，要借助于ping node 工作
2. N-M: N个节点M个服务， N>M， 活动节点为N， 备用节点为N-M
3. N-N： N个节点N个服务, N节点都有服务，如果一个坏了，会有一个节点运行多个服务
4. A/A: 双主模型，两个节点都是活动的。两个节点运行两个不同的服务。也可以提供同一个服务，比如ipvs， 前端基于DNS轮询。
资源转移的限定方式：
1. rgmanager:
failover domain： 故障转移域，设定一个资源只能在哪些主机上面转移
priority： 设定，在一个转移域中，哪些主机优先被转移资源
2. pacemaker: 通过资源约束，和粘性来限定资源转移方式。
资源黏性： 如果两个节点倾向性位置约束一致，资源对哪个节点粘性为正值，则留在哪个节点。
资源约束（3种类型）：
位置约束：资源更倾向于哪个节点上；通过一个数值来表示。
1） inf: 无穷大
2） n: 倾向于运行在某节点
3） -n: 倾向于离开某节点
4） -inf: 负无穷，如果所有节点全不可选，只能在此节点。
排列约束：资源运行在同一节点的倾向性；
1） inf: 两者永远在一起
2） -inf: 两者永远不再一起
顺序约束：资源启动次序及关闭次序；
例子：如何让web service中的三个资源，vip, httpd, filesystem运行在同一节点
1. 排列约束,说明三个在一起可能性inf
2. 资源组（resource group）, 三个资源定义在一个组内，然后这个组决定在某一个节点上启动
3. 定义顺序约束，保证启动顺序，vip–filesystem–httpd
对称性与非对称性：
对称性： 默认所有节点都能转移资源。
非对称性； 有些节点不能转移资源。
如果节点不再成为集群节点成员时，如何处理运行于当前节点的资源:
stoped:直接停止服务
ignore： 忽略，以前运行什么服务现在还运行什么。
freeze:事先建立的连接，接续保持，不再接收新的请求。
suicide: kill掉服务。
一个资源刚配置完成时，是否启动。
target-role: 目标角色，可以为启动，也可以为不启动。
资源代理类型（RA）：
heartbeat legacy: 传统类型
LSB: /etc/rc.d/init.d/ 下面的服务脚本
OCF：
STONITH: 专门用来实现资源隔离的
资源类型：
primitive, native : 主资源，只能运行于一个节点。
group: 组资源
clone: 克隆资源，所有节点都运行的资源，首先是主资源。
通常为STONITH资源， Cluster filesystem, 分布式锁
1） 最多运行的最大数。 总clone数
2） 每一个节点上最多运行几个。
master/slave： 主从资源内容，只能克隆两份，主的能读能写，从的不能做任何操作
