高可用集群原理

什么是高可用

在集群负载的基础上，考虑服务质量和服务的可用性，简单地说，就是当集群某个部分出现故障时，通过一些机制快速的恢复服务，最好让用户完全察觉不到，做到一种无缝的效果，一般作为一种服务都能实现高可用，像ipvs集群服务，httpd，mysql等。我觉得可以分为一下有两种情况

     1：通过部署多台服务器，设备间通过心跳线，固定时间通过事务传输层互相发送事务信息，若有设备故障，其他设备在限定时间内没有收到事务信息，则开始进行法定票数的投票，根据票数，对票数少的一方进行策略（重启，关闭等）

     2：后端节点故障，前端负载均衡器，固定时间对后端服务器进行 health check（健康检查），经过一定次数检查后，若有问题不在线了，则不再分配请求到故障节点，若后续解除了故障，再对其分配请求（针对负载均衡集群的后端节点）

---

如何判断故障

     1：借助另外的参考节点，如ping网关（可以是一个节点），可以和测试点ping通，但不可以和对方通，说明对方节点有问题，或本节点有问题

     2：仲裁设备，如仲裁磁盘，每个节点都间隔一定时间不停往磁盘写数据，若监测到对方不再写入的时候，可能对方节点出故障

---

故障处理：

法定票数（quorum）

     即当有节点故障时，节点间投票决定哪个节点是有问题的，票数大于半数为合法。票数是可以有多有少的，例如有些节点的性能较好或有其他优势，可以设置较多的票数，根据需要进行规划

全局集群资源管理策略：对不具备法定票数的集群节点采取的策略（without_quorum_policy）

• freeze：已经建立的请求继续提供服务，但不再接收新请求

• stop：暂停所有服务和请求

• ignore：继续正常服务

故障转移（FailOver）

     将高可用集群资源从不具备法定票数的集群节点转移到故障转移域（可以接收故障资源转移的节点），票数低的节点资源根据资源约束进行转移；当排除故障后，是否要故障回转（FailBack），则要看根据资源粘性和资源约束的设置，一般备用设备单纯只用于备份，性能低于主设备，所以当主设备恢复时应转回，根据实际判断。通过资源倾向实现

高可用集群资源 （HA resource）：例如，服务可以作为一个资源，vip，文件系统配置等都是高可用集群资源

• Primitive：主资源，在某一时刻只能运行在某个节点上，如VIP

• group：组，一般只包含primitive资源

• clone：克隆，可以在多个节点运行的资源，例如stonith作为资源，应运行在所有节点上；针对cluster filesystem产生的分布式锁管理器（distributed lock manager，dlm）为这种资源，应运行在所有节点上

• master/slave：特殊的clone资源，运行在两个节点上，一主一从，如：drbd，分布式复制块设备（2.6.33之后整合进内核了）

资源的倾向（资源定位的依据）

     资源粘性：资源和当前节点的关系

• 资源是否倾向于当前节点，score，正值倾向于当前节点，（还要和位置约束结合）

     资源约束 Constraint：资源和资源之间的关系

• 排列约束 （colocation）：资源间的互斥性，定义资源是否运行在同一节点上 ，score，正值表示要运行在同一节点上，负值则不可

• 位置约束（location），每个节点都有一个score值，正值则倾向于本节点，负值倾向于其他节点

• 顺序约束（order）：定义资源启动或关闭的次序，例如vip应先配置，httpd服务后配置

     特殊的score值，-inf 负无穷，inf 正无穷

---

高可用集群管理：高可用的具体实现

集群事务信息层（message layer）

     传递集群信息的一种机制，通过监听UDP 694号端口 ，可通过单播、组播、广播的方式，实时快速传递信息，传递的内容为高可用集群的集群事务，例如：心跳信息，资源信息等等，只负责传递信息，不负责信息的计算和比较

集群资源管理器（Cluster Resource Manager，CRM）

     利用messaging layer的功能收集节点信息，并负责信息的计算和比较，并做出相应的动作，CRM会推选出一个用于计算和比较的节点，叫DC（Designated coordinator）指定协调节点，计算由PE（Policy Engine）策略引擎实现，计算出结果后的动作控制由TE（Transition Engine）事务引擎实现，并且在每个节点上都有一个LRM（local resource manager）本地资源管理器，是CRM的一个子功能，接收TE传递过来的事务，在节点上采取相应动作，例如，运行RA脚本

     资源代理（Resource Agent，RA），能够集群资源进行管理的脚本，由于对于节点的动作因包含：对所有资源的状态检测，一定次数的检测检测后，若存在问题，则考虑资源的重置、重启，若重启无效，则进行资源转移，所以HA脚本格式应遵循linux脚本标准（linux standard base，LSB），包含（start|stop|restart|status），后来也出现了更加优化的脚本类型，如可以实现监控的OCF脚本