HA（High Availability）高可用集群，其特点为根据实际需求为前端Diretor,后端RS-server，数据库服务器，共享存储等集群节点做一个从备份服务器或者多个服务器互相备份，一旦主服务器挂掉，备份服务器能立马检测到并取代主服务器上的资源继续运行服务，从而最大限度避免了因服务器宕机造成的服务中止。
主节点（active/primary）备节点（passive/standby）
主调度器（Director）一般为集群中的关键节点，所以一般都有备份节点的存在；而后端RS-server可以根据实际可靠需求加备份节点，而存储服务器，如Mysql-Server,也作为集群的关键节点，一般都配有主从服务器。
HA集群着重服务的可靠性和稳定性两个方面
可用性=服务在线时间/（服务在线时间+故障处理时间）
可用性由 99%，99.9%，99.99%，99.999%不断提升，每多一个9，服务可用性提高十倍。在某些应用中服务可用性都要达到五个9的级别如：金融交易系统.....
HA Resource（高可用集群资源）:一旦节点故障这些资源需要转移到其他备份节点上，包括VIP，服务，隔离设备，文件系统。每个RS上都运行有服务资源，当有多个RS节点时，一旦某个节点发生故障要立马进行资源转移到其他节点，让其他节点处理未处理完的请求，并且要防止Director将前端请求继续此节点，但有如此多的节点存在，故障发生时到底往哪个节点转移了？且要是这个故障节点又恢复了如何处理？这时就要定义资源的黏性，资源的约束等。
资源的粘性：资源更倾向运行在哪个节点上，即资源与节点的倾向性
如：定义web服务在A服务器上的资源粘性为120，在B服务器上的资源粘性为100，一旦A发生故障又恢复正常后web服务又会从B服务器上转移到A服务器
资源的黏性：资源是否倾向运行在当前节点，Score>0（倾向）Scoro<0（不倾向，即一有其他可运行此服务的节点，资源就立马转移到其他节点）
资源的约束：定义资源与资源的倾向性
-
colocation（排列约束）：定义不同资源能否运行在同一个节点上，Score>0（可以），Score<0（不可以）
-inf(负无穷。。决不能运行在同一节点）
inf(正无穷。。必须运行在同一个节点）
-
location（位置约束）：每个节点都可以给某资源一个Score，Score >0（资源倾向运行在此节点）
-
Score <0（资源不倾向运行在此节点）
一般资源黏性+位置约束 哪个大，资源更倾向运行在那个节点
Order(顺序约束）：定义资源启动关闭时的顺序，因为不同资源可能有依赖关系如：VIP与IPVS规则，VIP先启动IPVS规则后启动
资源分类
-
Primitive 一个资源单独只运行在一个节点上（主资源）。
-
clone 每个节点上都运行此资源。
-
group 将多个资源划分为一个组，同组资源同进退，一起在节点上进行转移。
-
master/slave 主/从,一个资源只能运行在两个节点上，且一个为主一个为从。
备份节点如何知道主节点故障？
heartbeat（心跳信息）：每个节点都要随时与备份节点上进行通信，目的为检测对方是否在线
但当存在三个及三个以上节点时且这些节点也要互相传输心跳信息（如 运行有同种服务的RS之间互为备份节点，），从而判断自己是否故障，是否为合法节点，如何判断？
将所有节点定义在一个组播内让其互相ping， 比如有A、B、C、D、E 五个RS节点运行有Web服务，某时刻A、B、C三个节点能互相ping通，而D、E两个节点可以互相ping 通，则可以定义一个Quorum（投票）机制，为每个节点定义为一票，则五个节点共五票，且定义只有获得一半以上票数才为合法节点，所以此时A、B、C节点共三票，而D,E节点共两票，可以认为D,E节点未非法节点（即D,E节点出了故障）
或者A节点ping不通其他节点获得一票，而B、C、D、E四个节点可以互相ping通获得四票，可以认为A节点为非法节点
而对于多节点集群来说，为了投票机制的实施，节点数最好为奇数，获得票数超过一半则认为合法
且可以定义不同节点的拥有票数不同，如A节点性能好有两票投票权，B节点性能一般拥有一票投票权，此时就不用节点奇数，只要总票数为奇数便可以产生决策。
一旦节点被认为为非法节点应对其采取什么措施？
-
Freeze（冻结） 此非法只处理已经连接的请求，不再接受新的请求，处理完请求后再进行资源转移
-
stop 非法节点直接停止运行服务，进行资源转移，这种措施最常用
-
ignore 直接忽略 继续正常运行服务
什么时候会用到ignore?
只有两个互为备份的节点时
当只有两个节点互为备份时，一旦主节点ping不通备份节点，这时因为只有两个节点无法采取投票机制（一旦采取投票机制则两个节点都只获得一票，都认为自己挂掉了，那么不但主节点会停止服务，原本应该替代主节点的备份节点也因为认为自己非法而无法对主节点进行取代），主节点只能继续运行服务，直到被Stonish设备或fence设备隔离进行资源转移，这时备份节点也会取代主节点。
为了提供一个一个MySQL服务要具有哪些资源？
-
VIP 专门提供服务
-
FIP(float IP)流动的IP,可以再节点之间转移
-
Mysql服务
-
文件系统（要进行挂载）
一旦一个节点挂掉，向哪个节点转移？
定义个节点的资源约束score,哪个score大，更倾向于向哪个节点转移
脑裂:假设一个集群有4个RS_Server A、B、C、D
其中A正在往一个文件中写入数据，并且由于A服务器的CPU繁忙或错误添加了一条Iptables规则隔离了heartbeat传输等原因，未对其备份节点发出自己的心跳信息，这时CRM(cluster resource manager 专门用来收集集群资源或服务信息的集群资源管理器）发现检测不到A的心跳信息，认为A服务器挂掉了，便把A上的所有资源转移到了其他节点比如B上，这是B节点继续完成A节点的任务（向文件中写入数据），就会造成A和B同时往一个文件中写入，便会造成文件系统的崩溃及文件错乱。
如何避免脑裂？
在进行资源转移之前先将原来的节点进行资源隔离：
-
节点隔离
Stonish设备 如 直接断电爆头，一发现某节点无法传输heartbeat直接给其断电
-
资源级别隔离
FC-SAN （光纤交换机）可以实现在存储资源隔离故障节点的访问
如何检测一个节点是否故障？
-
加仲裁磁盘 主节点往一个共享磁盘中不断写入数据，一旦备节点发现自己可以访问共享磁盘但未发现主节点写入数据，则可以认为主节点挂掉，进行隔离
-
ping网关 只要能ping通网关 说明本节点正常，一旦ping不同则可以认为自己发生故障进行隔离
-
watchdog看门狗，协调同一个节点上不同进程每隔一段时间往watchdog中写入数据，一旦写入中断watchdog会尝试重启此进程，如果重启不了，则此节点故障，从此集群中去掉
Massaging Layer（负责以UDP协议在主节点与备节点间以组播模式传输heartbeat，资源黏性，资源约束，等信息），Massaging Layer 也是一个服务（UDP/694），且要让其开机自启动。
Cluster Resource Manager（集群的资源管理器）：专门处理统计收集群上每个资源的状态如：资源黏性资源约束，节点是否健康;并又CRM的子件PE计算出资源现在应该运行在哪个节点上，再由CRM的子件TE指挥每个节点的LRM完成相应操作如：将服务从A节点迁移到B，在B节点上启用VIP，文件系统.....
高可用集群节点上的服务启动都要由CRM决定，不能让其自启动,所以必须#chkocnfig 服务名称 off
PE:policy engine 策略引擎
TE：Tranaction Engine 事物引擎
LRM：location Resource Manager 本地资源管理器
PE，TE，LRM都是CRM的组成
RA：Resource Agent资源代理
所有能够负责资源启动、关闭、重启、状态监测的脚本都叫RA，RA运行在每个节点上
RA的类别
Legency heartbeat v1 RA
LSB 所有遵循linux的shell编程支持start|restart|stop|status的脚本都是LSB类型 如/etc/rc.d/init.d/目录中的所有脚本
OCF（open cluster framework）此类脚本不但可以接受start|restart|stop|status等参数，甚至可以接受monitior（监控）等参数
DC(designated coordinator）事物协调员，DC也为CRM的子件，是在多节点中选举出的一个节点
Messager Layer的软件实现
-
heartbeat（v1 v2 v3 三个版本）
-
heartbeat v3 又分为heartbeat、pacemaker、cluster-glue
-
CoroSync 红帽6.0后默认使用的Messaging Layer
-
Cman 红帽5.0后默认使用的Messaging Layer 但由于工作在内核空间且配置复杂所以6.0后换成了工作在用户空间的CoroSync
-
keepalived keepalived的配置与应用与前几个相比有所不同，如对VIP的配置是基于VRRP（Virtual Router Redundancy Protocol）虚拟路由冗余协议实现的
CRM（cluster resource manager）层的软件实现
CRM必须工作在Messaging Layer 层上
Haresources (heartbeat v1 v2 都有自带）
CRM （heartbeat v2 自带）
Pacemaker (heartbeat v3 独立出去的项目）
Ragmanager (专门为Cman提供的一种crm）所以集群的Messager Layer与CRM 组合如下：
haresource + heartbeat v1/v2
crm + heartbeat v2
pacemaker + corosync
pacemaker + heartbeat v3
cman + ragmanager那么定义一个Web服务的高可用集群至少要几个节点？要定义几个资源？
至少需要两个节点，上面要运行MassagerLayer 和 CRM
至少要定义四个资源 VIP 、httpd服务 、Filesystem、Stonish设备
为了避免随便一个服务器配好资源，装上MassagerLayer和CRM，时间再一同步就可以随便加入我们的集群系统，该如何处理？
首先每个节点要装Messager Layer和CRM节点之间进行heartbeat等信息传输时都因该采取加密传输（如进行hash运算）， 如果有两个节点可以进行单播传输heartbeat信息，两个以上节点可以进行单播、组播、广播传输heartbeat信息，高级可用集群节点上的服务必须由CRM控制，所以要设置CRM自启动而服务要用chkconfig关闭开机自启动，而Massager Layer也是一个服务且要开机自启动，Messager Layer监听在UDP/694上，以UDP协议在Messager Layer层传输heartbeat等信息。
如果要配置一个HA集群要注意什么？
节点名称要与uname -n的结果一致；节点名称/IP的解析最好在/etc/hosts文件中，不要用DNS解析，否则DNS-Server挂掉会对集群造成影响；节点的时间必须同步；SSH互信通信（当要停止或其他节点的HA集群服务时，不能从此节点进行，而要从一个正常的节点进行HA服务的关闭或启动）这是就必须要求能够以SSH远程登录到其他节点。
那第一个节点怎么办？
第一个节点要自我启动，然后启动其他节点上的服务
本文来自云栖社区合作伙伴“DBGEEK”
