HA cluster高可用集群原理

trytete

高可用集群，英文原文为High Availability Cluster，简称HA Cluster，高可用集群的出现是为了使集群的整体服务尽可能可用，从而减少由计算机硬件和软件易错性所带来的损失。如果某个节点失效，它的备援节点将在几秒钟的时间内接管它的职责。因此，对于用户而言，集群永远不会停机。高可用集群软件的主要作用就是实现故障检查和业务切换的自动化。

只有两个节点的高可用集群又称为双机热备，即使用两台服务器互相备份。当一台服务器出现故障时，可由另一台服务器承担服务任务，从而在不需要人工干预的情况下，自动保证系统能持续对外提供服务。双机热备只是高可用集群的一种，高可用集群系统更可以支持两个以上的节点，提供比双机热备更多、更高级的功能，更能满足用户不断出现的需求变化。

以上这是度娘对高可用集群的一些简单的解释。
在之前的博客中也说到了，高可用集群就是保证服务的可用性，尽可能的减少宕机。之前一直说的lvs负载均衡集群，其实负载均衡也可以达到一定的高可用作用，但是不是非常专业，比如说对与lvs集群来说，通过director做健康状态检测，可以保证后端RS服务的可用性，但如有RS宕机，用户即便会被调度至其他RS上，但此前在这台宕掉的RS上的数据仍是必可避免的丢失。并且，对于集群的director而言，将会是整个系统的单点故障所在，如director一旦宕机，后端无论怎么高可用，都将无用武之地。相比来说，保证director的可用性要比保证RS的可用性的重要性高的多。
如何衡量系统的可用性：
Availability=MTBF/（MTBF+MTTR）
可用性=平均无故障时间/（平均无故障时间+平均修复时间）
对于电子设备来讲，故障是不可避免的存在，墨菲定律曰过，如果某个坏事可能要发生，那么一定会发生。一般集群出现故障有以下几中情况：
硬件故障：硬件设计缺陷、正常较长时间无法避免的损坏、人为故障、……；
软件故障：软件设计缺陷、误操作、……。
既然会出现这么多的问题，各大公司也是需要尽量避免这些事情的发生，比如定期做故障排除演练之类的，然而，对于支付宝这种传统行业一铲子的事，并没有什么卵用。

先说说怎么解决单点故障的问题吧，director一般只有一个，那么，解决单点故障无非就是使用两台director做冗余就可以了，一台作为主机，一台做备用机，如果主机挂了，备用机顶上去就ok了。但是，备用机如何得知主机的状态呢，这里就需要一个心跳检测过程，备用机通过间断的向主机发送报文检测主机是否在线，如在线，则备用机就一直处于备用状态，如检测几次后发现主机不在线，则立即将源主机上所有工作（IP地址切换、IPVS规则等）全部切换到备用机上，这样就实现了切换过程。如两台主机性能相同，当主机恢复时，直接作为备机使用；如果备机性能低下，则主机恢复时还需切换回主机。
但是此中还是有问题的，如果主备之间的心跳线连接有问题或者在线主机发生了短暂的网络拥塞现象的话，备用机检测不到主机心跳，则会切换，反之，原主机切换成备用机后也同样对原备用机进行检测，检测不到心跳后也会切换成在线状态，这样，主备之间形成了反复切换的问题，这就是集群的脑裂。
要解决这种问题，就需要在备机上线时，无论主机是什么状态都要强行下线，甚至断电，这样，才能避免由于脑裂造成的连接不稳定或数据的写入错乱。

上面所说的只是主从两个节点director的高可用，如果现在节点有5个，那么应该如何检测，如何分配呢？
举例：这五台主机在工作时，都会相应的基于多播向所有节点发送心跳信息和集群事物信息，告诉其他节点I am alive。此时突发情况左边三个节点由于网络原因无法和右边三个节点通讯，但左三和右二都是可用的，这时，应该由哪边主导就需要一个集群事物决策层，也就是一个投票系统。
这五台主机工作正常时，假如第二台主机作为DC，收集每台主机的投票信息，当左右分裂成三、二的结构时，右边两台主机由于脱离了原有组织，就会在其中，重新选取DC重新投票。这样左右票数不一致，最终由投票数量多的胜出，决定胜出的系统也就是个仲裁系统。
上述只是在票数不同的情况下判定的，如果说仅有两台主机，脑裂后就是票数相同。这种情况下，只需要一个共享硬盘，哪一个节点可以向其中写数据，则将另外一方干掉；或者设置一个网关，哪一个主机可以的请求可以到达网关，则干掉另外一方。

但是，服务器集群中基于IP或基于端口的检查基本上都没个卵用，最重要的还是检测服务器上资源状态。一旦服务器上的资源发生故障时，无论该主机在线与否，偶读要进行资源转移。例如：有两台主机，如果想在两台主机上都能探测到对方的心跳信息，就需要在每个主机上都运行一个应用程序，两台主机上的这个应用程序可以彼此间互相通信（两台主机上的这个程序可以向对方的指定端口上发心跳），也就是在两台主机上建立了一个层来传递心跳信息，叫做集群事物信息层（message layer）。此时第一台服务器上有IP和服务，当第一台上的资源有问题了，第二台主机只能检测到第一台主机的心跳但却不能检测到资源可用与否，所以在这几台主机上就还需要一个统一的管理器保证资源的统一调度，这个管理器叫做集群资源管理器（cluster resource manager），只需这两台主机上的资源纳入集群资源管理器范围内，由它判定运行的优先级、检测资源运行状况、实现资源故障转移、对资源故障主机进行补刀操作等工作。集群资源管理器主要任务就是只负责战略制定的。

这里所说的资源也是有类型的：
primitive：主资源，只能运行于集群内的某单个节点；(也称作native)；
group：组资源，容器，包含一个或多个资源，这些资源可通过“组”这个资源统一进行调度；
clone：克隆资源，可以在同一个集群内的多个节点运行多份克隆；
master/slave：主从资源，在同一个集群内部于两个节点运行两份资源，其中一个主，一个为从。

以上可以看出，在高可用集群中所用到的资源可能是各式各样的，而每一种资源都可能有不同的启动方式，而每一种启动方式都需要配置才能生效，所以这样就非常麻烦。这就引出了另外一个层次，本地资源管理器（location resource manager），本地资源管理器相对于集群资源管理器来说是负责战略实施，也就是战略落地，LRM一般由CRM直接提供，LRM在每个本地主机上都需要运行，但需要引用本地上的资源代理（RA，一种负责启动关闭资源的脚本）才能实现。具体结构是下图这样的：