1、什么是高可用集群
高可用集群（High Availability Cluster，简称HA Cluster），是指以减少服务中断时间为目的的服务器集群技术。它通过保护用户的业务程序对外不间断提供的服务，把因软件、硬件、人为造成的故障对业务的影响降低到最小程度。
简单说就是：保证服务不间断地运行，比如，在淘宝网什么时候都可以上去买东西，微信随时可以打开发消息聊天。
2、高可用集群的衡量标准
要保证集群服务100%时间永远完全可用，几乎可以说是一件不可能完成的任务。比如，淘宝在这几年双十一刚开始的时候，一下子进来买东西的人很多，访问量大，都出现一些问题，如下单后却支付不了。所以说只能保证服务尽可能的可用，当然有些场景相信还是可能做到100%可用的。
通常用平均无故障时间(MTTF)来度量系统的可靠性,用平均故障维修时间（MTTR）来度量系统的可维护性。于是可用性被定义为：HA=MTTF/(MTTF+MTTR)*100%。
具体HA衡量标准:
| 描述 |
通俗叫法 |
可用性级别 |
年度停机时间 |
| 基本可用性 |
2个9
扫描二维码关注公众号，回复：
195857 查看本文章
|
99% |
87.6小时 |
| 较高可用性 |
3个9 |
99.9% |
8.8小时 |
| 具有故障自动恢复能力的可用性 |
4个9 |
99.99% |
53分钟 |
| 极高可用性 |
5个9 |
99.999% |
5分钟 |
3、高可用集群实现原理
高可用集群主要实现自动侦测(Auto-Detect)故障、自动切换/故障转移(FailOver)和自动恢复(FailBack)。
简单来说就是，用高可用集群软件实现故障检查和故障转移（故障/备份主机切换）的自动化，当然像负载均衡、DNS分发也可提供高可性。
3-1、自动侦测(Auto-Detect)/ 故障检查
自动侦测阶段由主机上的软件通过冗余侦测线，经由复杂的监听程序，逻辑判断，来相互侦测对方运行的情况。
常用的方法是：集群各节点间通过心跳信息判断节点是否出现故障。
3-1-1、问题是：当有节点（一个或多个）和另外节点互相接收不到对方心跳信息时，如何决定哪一部分节点是正常运行的，而哪一部分是出现故障需要隔离的呢（避免集群脑裂）？
这时候通过法定票数（quorum）决定，即当有节点故障时，节点间投票决定哪个节点是有问题的，票数大于半数为合法。
票数：
每个节点可以设置票数，即决定节点在集群内是否合法（正常）的权限值，这个是可以有多有少的，例如有些节点的性能较好或有其他优势，可以设置较多的票数。
法定票数（quorum）：
当一个节点能和另一个节点保持心跳信息，该节点就获取得了另一个节点的票数，该节点获得的所有票数就是法定票数。
3-1-2、比较特殊的是只有两个节点的集群，或两边票数相等
这时候可以借助另外的参考节点，如ping网关（可以是一个节点），可以和测试点ping通，但不可以和对方通，说明对方节点有问题，或本节点有问题；还有就是通过仲裁设备，如仲裁磁盘，每个节点都间隔一定时间不停往磁盘写数据，若监测到对方不再写入的时候，可能对方节点出故障。
但最好还是使得组成集群的节点数量为单数台（2n+1），当集群分区脑裂时，节点数量小于一半（>n+1）的分区自动停止对外提供服务。
3-1-3、Pasox算法和Zookeeper
关于“投票”，有必要知道著名的Pasox算法和Zookeeper：
Paxos算法：
Paxos算法解决的是保证集群中每个节点执行相同的操作序列，可以保证分布式群集中的数据一致性。
例如，通过投票来对写操作进行全局编号，同一时刻，只有一个写操作被批准，同时并发的写操作要去争取选票，只有获得过半数选票的写操作才会被 批准（所以永远只会有一个写操作得到批准）；而其他的写操作竞争失败只好再发起一轮投票，就这样，在日复一日年复一年的投票中，所有写操作都被严格编号排序。
编号严格递增，当一个节点接受了一个编号为100的写操作，之后又接受到编号为99的写操作（因为网络延迟等很多不可预见原因），它马上能意识到自己数据不一致了，自动停止对外服务并重启同步过程。
任何一个节点挂掉都不会影响整个集群的数据一致性（总2n+1台，除非挂掉大于n台）。
Zookeeper：
Zookeeper是 Hadoop 大数据生态的一个独立组件，是 Google 的 Chubby一个开源的实现，可以说是Paxos算法（类似）的实现。
Zookeeper主要提供分布式协调服务，分布式应用程序可以基于它实现服务注册（高可用），同步服务，配置维护和命名服务等。
Zookeeper真正提供的是类似我们普通电脑上的文件系统目录的功能，不过可以原子的进行增/删/改/查操作；具体要实现什么分布式协调服务，需要自己写程序来操作Zookeeper上的“目录”。
Zookeeper为什么可以作为分布式系统提供协调服务？
最主要的是Zookeeper本身运行的是一个由多个Zookeeper节点组成的稳定的高可用集群。
Zookeeper集群的高可用性和各节点“目录”数据的一致性正是基于 类似 Paxos算法实现的投票机制来保证的。所以 Zookeeper集群节点数量最好也是单数（2n+1），当集群脑裂分区时，分区节点数量不超过一半的（<n+1），会自动停止对外服务。
比如：5台ZK节点组成ZK集群，当分成2台和3台的两个分区时，2台的分区会自动停止对外服务，3台的分区会继续提供服务。
另外，如果用6台节点组成ZK集群，当分成3台和3台的两个分区时，这两个分区都自动停止对外服务，所以，容错率和5台节点组成的集群的是一样的，更应该用单数（2n+1）节点数量组成集群。
3-2、自动切换/故障转移（FailOver）
自动切换阶段某一主机如果确认对方故障，则正常主机除继续进行原来的任务，还将依据各种容错备援模式接管预先设定的备援作业程序，并进行后续的程序及服务。
通俗地说，即当A无法为客户服务时，系统能够自动地切换，使B能够及时地顶上继续为客户提供服务，且客户感觉不到这个为他提供服务的对象已经更换。
通过上面判断节点故障后，将高可用集群资源（如VIP、httpd等，下面详见）从该不具备法定票数的集群节点转移到故障转移域（Failover Domain，可以接收故障资源转移的节点）。
3-2-1、高可用集群资源（HA Resource）和集群资源类型
集群资源是集群中使用的规则、服务和设备等，如VIP、httpd服务、STONITH设备等。类型如下：
1、Primitive：主资源，在某一时刻只能运行在某个节点上，如VIP。
2、group：组，资源容器，使得多个资源同时停/启等，一般只包含primitive资源。
3、clone：克隆，可以在多个节点运行的资源，例如stonith设备管理进程、集群文件系统的分布式锁（dlm）作为资源，应运行在所有节点上。
4、master/slave：特殊的clone资源，运行在两个节点上，一主一从，如：分布式复制块设备drbd（2.6.33之后整合进内核了）。
3-2-2、转移到哪个节点
根据资源的倾向（资源粘性、位置约束的分数比较）进行转移；
资源的倾向（资源定位的依据）：
A、资源粘性：资源对节点倾向程度，资源是否倾向于当前节点。score，正值倾向于当前节点（还要和位置约束结合）。
B、资源约束（Constraint）：资源和资源之间的关系
a、排列约束 （colocation）：资源间的依赖/互斥性，定义资源是否运行在同一节点上。score，正值表示要运行在同一节点上，负值则不可。
b、位置约束（location）：每个节点都有一个score值，正值则倾向于本节点，负值倾向于其他节点，所有节点score比较，倾向于最大值的节点。
c、顺序约束（order）：定义资源执行动作的次序，例如vip应先配置，httpd服务后配置。特殊的score值，-inf 负无穷，inf 正无穷。
也就是说资源粘性定义资源对资源当前所在节点的倾向性，而位置约束定义资源对集群中所有节点的倾向性。如webip的资源粘性为100，位置约束对node1为200，当webip在node2上时，node1上线资源会转移到node1，因为当前节点node2粘性100小于对node1的位置约束200；如webip的资源粘性为200，位置约束对node1为100，当webip在node2上时，node1上线资源不会转移到node1，继续留在node2上，因为当前节点node2粘性200大于对node1的位置约束100。
3-3、自动恢复/故障回转(FailBack)
自动恢复阶段在正常主机代替故障主机工作后，故障主机可离线进行修复工作。在故障主机修复后，透过冗余通讯线与原正常主机连线，自动切换回修复完成的主机上。
3-3-1、当排除故障后，是否要故障回转？
根据资源粘性和资源约束的设置，一般备用设备单纯只用于备份，性能低于主设备，所以当主设备恢复时应转回，但故障回转需要资源转移，会影响到正在使用的客户，过程代价较高，所以是否需要回转根据实际判断。
3-4、其他关注点
3-4-1、如果节点不再成为集群节点成员时（不合法），如何处理运行于当前节点的资源？
如果集群没有对其进行Fecning/Stonith隔离前，可以进行相关配置（without_quorum_policy），有如下配置选项：
1、stop：直接停止服务；
2、ignore：忽略，以前运行什么服务现在还运行什么（双节点集群需要配置该选项）；
3、Freeze：冻结，保持事先建立的连接，但不再接收新的请求；
4、suicide：kill掉服务。
3-4-2、集群脑裂（Split-Brain）和资源隔离（Fencing）
脑裂是因为集群分裂导致的，集群中有节点因为处理器忙或者其他原因暂时停止响应时，与其他节点间的心跳出现故障，但这些节点还处于active状态，其他节点可能误认为该节点"已死"，从而争夺共享资源（如共享存储）的访问权，分裂为两部分独立节点。
脑裂后果：这时两个节点开始争抢共享资源，结果会导致系统混乱，数据损坏。
脑裂解决：上面3-1-1、3-1-2的方法也能一定程度上解决脑裂的问题，但完全解决还需要资源隔离（Fencing）。
资源隔离（Fencing）：
当不能确定某个节点的状态时，通过fencing把对方干掉，确保共享资源被完全释放，前提是必须要有可靠的fence设备。
节点级别：
STONITH（shoot the other node in the head，爆头。硬件方式），直接控制故障节点的电源，绝对彻底。
资源级别：
例如：FC SAN switch（软件方式）可以实现在存储资源级别拒绝某节点的访问
4、高可用集群工作模型
4-1、Active/Passive：主备模型
一个活动主节点，另一个不活动作为备用节点，当主节点故障，转移到备节点，这时备节点就成为了主节点。备节点完全冗余，造成一定浪费。如下图，mysql、DRBD主从节点间还要进行同步：
4-2、Active/Active：双主模型
两个节点都是活动的，两个节点运行两个不同的服务，也互为备用节点。也可以提供同一个服务，比如ipvs，前端基于DNS轮询。这种模型可以使用比较均衡的主机配置，不会造成浪费。
4-3、N+1
N个活动主节点N个服务，一个备用节点。这需要额外的备用节点必须能够代替任何主节点，当任何主节点故障时，备节点能够负责它的角色对外提供相应的服务。如下图，最后一个备用节点可以作为前两台主节点的DRBD和第三台主节点的MYSQL提供备用功能：
4-4、N+M
N个活动主节点，M个备用节点。像上面的N+1模型，一个备用节点可能无法提供足够的备用冗余能力，备用节点的数量M是成本和可靠性要求之间的折衷。
也有一种说法：N-M: N个节点M个服务， N>M， 活动节点为N， 备用节点为N-M。
4-5、N-to-1
这和N+1一样，也是N个活动主节点，一个备用节点；不同是的备用节点成为主节点只是暂时的，当原来故障的节点修复后，必须回转才能正常工作。
4-6、N-to-N
N个主节点N个备用节点。这是A/A双主和N + M模型的组合，N节点都有服务，如果一个坏了，剩下的每个节点都可以作为替代提供服务。如下图，当共享存储是可用的，每一个节点都可能会被用于故障切换。起搏器甚至可以运行服务的多个副本，以分散工作量。
5、高可用集群架构层次
5-1、节点主机层
这一层主要是正在运行在物理主机上的服务，高可用集群相关的软件运行在各主机上，集群资源也是在各主机上。
5-2、Messaging and Membership Layer
信息传递层，传递集群信息的一种机制，通过监听UDP 694号端口，可通过单播、组播、广播的方式，实时快速传递信息，传递的内容为高可用集群的集群事务，例如：心跳信息，资源事务信息等等，只负责传递信息，不负责信息的计算和比较。
成员关系（Membership）层，这层最重要的作用是主节点（DC）通过Cluster Consensus Menbership Service（CCM或者CCS）这种服务由Messaging层提供的信息，来产生一个完整的成员关系。这层主要实现承上启下的作用，承上，将下层产生的信息生产成员关系图传递给上层以通知各个节点的工作状态；启下，将上层对于隔离某一设备予以具体实施。
5-3、CRM（Cluster Resource Manager）
集群资源管理器层，它主要是用来提供那些不具有高可用的服务提供高可用性的。它需要借助Messaging Layer来实现工作，因此工作在Messaging Layer上层。
资源管理器的主要工作是收集messaging Layer传递的节点信息，并负责信息的计算和比较，并做出相应的动作，如服务的启动、停止和资源转移、资源的定义和资源分配。
在每一个节点上都包含一个CRM，且每个CRM都维护这一个CIB（Cluster Information Base，集群信息库），只有在主节点上的CIB是可以修改的，其他节点上的CIB都是从主节点那里复制而来的。
CRM会推选出一个用于计算和比较的节点，叫DC（Designated coordinator）指定协调节点，计算由PE（Policy Engine）策略引擎实现，计算出结果后的动作控制由TE（Transition Engine）事务引擎实现。
在每个节点上都有一个LRM（local resource manager）本地资源管理器，是CRM的一个子功能，接收TE传递过来的事务，在节点上采取相应动作，如运行RA脚本等。
5-4、RA（Resource Rgent）
资源代理层，简单的说就是能够集群资源进行管理的脚本，如启动start，停止stop、重启restart和查询状态信息status等操作的脚本。LRM本地资源管理器负责运行。
资源代理分为：
1、Legacy heartbeat（heatbeat v1版本的资源管理）；
2、LSB（Linux Standard Base），主要是/etc/init.d/*目录下的脚,start/stop/restart/status；
3、OCF（Open Cluster Famework），比LSB更专业，更加通用,除了上面的四种操作，还包含monitor、validate-all等集群操作，OCF 的规范在http://www.opencf.org/cgi-bin/viewcvs.cgi/specs/ra/resource-agent-api.txt?rev=HEAD。
4、STONITH：实现节点隔离
6、高可用集群软件
6-1、Messaging Layer 集群信息层软件
1、heartbeat (v1, v2)
2、heartbeat v3
可以拆分为：heartbeat, pacemaker, cluster-glue
3、corosync
从OpenAIS分离的项目。
4、cman
5、keepalived
一般用于两个节点的集群
6、ultramokey
6-2、CRM集群资源管理器软件
1、Haresource
heartbeat v1 v2包含，使用文本配置接口haresources
2、crm
heartbeat v2包含，可以使用crmsh或者heartbeat-gui来进行配置
3、pacemaker
heartbeat v3分离出来的项目，配置接口：CLI：crm、pcs和GUI：hawk(WEB-GUI)、LCMC、pacemaker-mgmt、pcs
4、rgmanager
Cman包含，使用rgmanager(resource group manager)实现管理, 具有Failover Domain故障转移域这一特性，也可以使用RHCS（Redhat Cluster Suite）套件来进行管理：Conga的全生命周期接口，Conga（luci/ricci）先安装后，可用其安装高可用软件，再进行配置。
6-3、常用组合
heartbeat v2+haresource(或crm) (说明：一般常用于CentOS 5.X)
heartbeat v3+pacemaker (说明：一般常用于CentOS 6.X)
corosync+pacemaker (说明：现在最常用的组合)
cman + rgmanager (说明：红帽集群套件中的组件，还包括gfs2,clvm)
keepalived+lvs (说明：常用于lvs的高可用)
7、共享存储
高可用集群多节点都需要访问数据，如果各节点访问同一个数据文件都是在同一个存储空间内的，就是说数据共享的就一份，而这个存储空间就共享存储。
如Web或Mysql高可用集群，他们的数据一般需要放在共享存储中，主节点能访问，从节点也能访问。当然这也不是必须的，如可以通过rsync、DRBD来同步分别存储在主、从节点上的块数据，而且相对共享存储实现成本更低，具体使用什么需要根据实际场景来选择。下面我们就简单说一下共享存储的类型：
7-1、DAS（Direct attached storage，直接附加存储）
存储设备直接连接到主机总线上的，距离有限，而且还要重新挂载，之间有数据传输有延时；
这是设备块级别驱动上实现的共享，持有锁是在节点主机本地上的，无法通知其他节点，所以如果多节点活动模型的集群同时写入数据，会发生严重的数据崩溃错误问题，主备双节点模型的集群在分裂的时候了会出现问题；
常用的存储设备：RAID 阵列、SCSI 阵列。
7-2、NAS（network attached storage，网络附加存储）
文件级别交互的共享，各存储设备通过文件系统向集群各节点提供共享存储服务，是用C/S框架协议来实现通信的应用层服务。
常用的文件系统：NFS、FTP、CIFS等，如使用NFS实现的共享存储，各节点是通过NFS协议来向共享存储请求文件的。
7-3、SAN（storage area network、存储区域网络)
块级别的，将通信传输网络模拟成SCSI（Small Computer System Interface）总线来使用，节点主机（initiator）和SAN主机（target）都需要SCSI驱动，并借助网络隧道来传输SAN报文，所以接入到SAN主机的存储设备不一定需要是SCSI类型的。
常用的SAN：FC光网络（交换机的光接口超贵，代价太高）、IPSAN（iscsi、存取快，块级别，廉价）。