Linux入门攻坚——48、高可用HA之corosync/pacemaker（1）

Corosync是一个开源的集群管理套件，它提供了用于构建高可用性（HA）集群的基本功能。在Linux环境中，Corosync通常与Pacemaker结合使用，以提供资源管理、故障检测和自动恢复等功能。

对于Linux集群，即Linux Cluster，再次梳理，主要分以下几类：
LB（负载均衡）集群、HA（高可用）集群、HP（高性能）集群、hadoop为代表的分布式集群。
LB：
    传输层上的实现：lvs
    应用层上的实现：Nginx，haproxy，httpd，perlbal，ats，varnish
HA：
    vrrp：keepalived
    AIS：heartbeat，OpenAIS，corosync/pacemaker，cman/rgmanager(conga)-RHCS（Red Hat Cluster Suite，红帽集群套件）

对于HA高可用的场景，主要是解决：
  - 故障场景：硬件故障、软件故障等
  - 可用性A，A=MTBF/（MTBF+MTTR），MTBF (Mean Time Between Failures) =平均故障间隔时间，MTTR (Mean Time To Repair) =平均修复时间 ，可用性是指设备或系统处于可正常运行状态的时间占总时间的比例。0<A<1，A一般用几个9来表达，如2个9即为99%，3个9即99.9%，9越多，系统越可靠。

提高可用性，一是提高MTBF，一是减少MTTR，减少MTTR，一般使用冗余机制。

冗余机制，就是通过增加备用设备、组件或系统来提高可靠性和容错能力的技术手段‌。以vrrp实现的keepalived为例，一台提供特定服务的服务器，为保证高可用性，使用冗余机制，使用两台服务器实现集群提供服务，这涉及到以下几点问题：
    一是如何确定哪一台设备是主设备，哪一台是备用设备，在keepalived中是以vrrp的优先级，即priority为标准进行决策或叫做仲裁，谁的优先级高，谁就是主设备，即以优先级为仲裁机制，确定主备位置；二是备用设备如何确定主设备无故障，这主要是通过主设备周期性发送特定信息来确定，这个信息就是心跳信息heartbeat，备用设备只要周期性接收到这个信息，就确定主设备正常；三是主设备出现问题，主设备自己可以主动降低自身优先级，或是备用节点主动抢占主设备，需要发送一些集群事务决策（仲裁）相关信息，四是heartbeat信息和集群事务决策信息等简短信息要有特定通道实现传递，即在主、备设备间要有实现信息传递的一层，这个服务在每一个主备设备上都要有，是实现集群的基础功能，叫做Messaging Layer，集群的基础架构层（信息传输层）。

    keepalived中，通过在Messaging Layer中传递的heartbeat以及集群事务决策信息，由keepalived的程序仲裁谁是主设备，通过优先级进行仲裁，这涉及两个问题，一是仲裁的依据，这里是优先级，当然也可以是其他的信息，二是谁来仲裁以及如何实现主备切换，这里是keepalived进程本身进行仲裁，然后通过vrrp script脚本实现优先级的改变达到主备切换，当然也可以是其他单独的程序来实现仲裁和切换。

    为了支持更多种类的服务集群，从通用性和结构化角度，一般将仲裁机制/主备切换单独形成一个层次，通过提供众多的API，实现对不同集群事务决策信息的仲裁，然后，再通过另一个层次，实现主备设备（服务）的切换功能，即资源的切换，这个层次叫做资源管理层，Resource Manager，也叫Cluster Resource Manager（CRM）。因为Resource Manager需要管理下层的硬件状态、软件状态，即进程的状态，还要负责资源切换的管理，所以将其又分出一个层次，在其上层增加一个Local Resource Manager，本地资源管理，负责本地资源的管理，如本地进程状态监控和管理，如本地httpd出现故障后的重新启动管理等。而对本地资源的管理，如程序的运行、重启等，一般是通过运行一个脚本来进行的（有的如编译安装的没有此脚本，可以直接运行），这个脚本一般叫做资源代理（Resource Agent，RA），实现进程的启动、停止、重启、状态检测。而Local Resource Manager就是通过resource agent来完成对资源的管理的。

    对于上述需要实现的功能，其实现循序一定的规范。这里要了解AIS与OpenAIS。
    SA FORUM（服务可用性论坛）开发并发布了一些免费的规范，形成应用接口规范——AIS，用来定义应用程序接口（API）的开放性规范集合，使用AIS规范的应用程序接口（API），可以减少应用程序的复杂性和缩短应用程序的开发时间，提高中间组件可移植性和应用程序的高可用性。

AIS Management Services为AIS管理的服务包括IMM，NTF，LOG和SEC；AIS Frameworks为AIS 管理框架，有AMF和SMF两个架构；AIS Utility Services为AIS提供的公共服务，包括CKPT，EVT，LCK，MSG，NAM，TMR；AIS Platform Services分CLM和PLM两部分；最下面是硬件平台接口HPI部分。

PLM在处在AIS最底层，提供硬件的逻辑视图和系统低级软件，这些低级软件可以构成操作系统，并为各种应用程序提供了执行的环境。CLM是在集群中描述集群节点的信息和集群节点的配置信息。AMF，SMF是AIS的两个框架，AMF是集群框架，为集群各个实体提供注册、注销，错误报告，保护组管理，可用性管理，健康状况监控等。SMF是服务管理框架，作用包括保持活动状态模型、监控由于软件改变造成的潜在的错误信息、配置恢复错误信息的步骤等。AIS Utility Services为AIS提供公共服务。AIS Management Services是AIS管理服务的对象。

OpenAIS是基于SA Forum 标准的集群框架的应用程序接口规范。OpenAIS提供一种集群模式，这个模式包括集群框架，集群成员管理，通信方式，集群监测等，能够为集群软件或工具提供满足 AIS标准的集群接口，但是它没有集群资源管理功能，不能独立形成一个集群。也就是OpenAIS是遵循AIS规范，为实现集群功能而定义的一个更细化的规范，同时它又是一组已经实现的具体组件，OpenAIS组件包括AMF,CLM,CKPT,EVT,LCK,MSG,TMR,CPG,EVS等，因为OpenAIS组件开发有不同的分支，所以不同的分支组件略有不同。OpenAIS主要包含三个分支：Picacho，Whitetank，Wilson。比较常用的是Whitetank和Wilson，两者之间有很多不同。OpenAIS从Whitetank升级到Wilson版本后，组件变化很大，Wilson把Openais核心架构组件独立出来放在Corosync（Corosync是一个集群管理引擎）里面。Whitetank包含的组件有AMF，CLM，CKPT，EVT，LCK ,MSG, CPG，CFG,EVS, aisparser, VSF_ykd，bojdb等。而Wilson只含有AMF，CLM，CKPT，LCK, MSG,EVT,TMR（TMR，Whitetank里面没有），这些都是AIS组件。其他核心组件被放到了Corosync内。Wilson被当做Corosync的一个插件。

OpenAIS的规范框架围绕着几个核心领域展开，每个领域都有其特定的目标和功能：
    集群构建：定义了创建和初始化集群的基本步骤，包括节点的加入和离开流程。
    成员管理：详细说明了如何有效地管理集群内的各个节点，确保它们能够高效协作。
    通信机制：描述了节点间通信的具体方式，包括消息传递、事件通知等。
    状态监控：提供了监控集群健康状况的方法，帮助管理员及时发现并解决问题。

Corosync是OpenAIS发展到Wilson版本后衍生出来的开放性集群引擎工程。可以说Corosync是OpenAIS工程的一部分。OpenAIS从openais0.90开始独立成两部分，一个是Corosync；另一个是AIS标准接口Wilson。

以高可用httpd服务为例，hostA、hostB、hostC组成一个高可用集群，A为主设备，BC为备用设备，首选A通过Messaging Layer进行心跳信息和集群事务决策信息的传递，BC通过Messaging Layer获取相关信息；CRM层通过调用ML层的不同API获取到相关信息（之所以有不同的API，是因为信息种类很多，做成不同API，即可精简程序，又可灵活扩展），进行判断和决策。CRM要做的工作很多，如要判断硬件的状态、软件的状态，即httpd的状态、软硬件出现非正常状态后的处理，如是否进行进程重启、资源的管理，即哪些属于集群资源，如这个例子中，IP和httpd进程都是集群资源、资源的切换，即将主设备的IP和httpd切换到B或C上。对软硬件的管理，又涉及进程的启动、停止、重启、状态查看等，所以，CRM要完成的功能太多了，同时，不同的软硬件资源又会有不同的管理方式，因此，CRM将功能进行了剥离，对本地资源的管理形成LRM层，实现对本地进程的启动、停止、重启、状态查看等；而本地资源又是多种多样的，为了精简和灵活扩展，LRM又形成了资源代理，即RA来完成不同资源的管理。

    网络分区（network partition）问题：投票系统（vote system）解决。
    网络分区，也可叫做网络分裂，就是一个集群的多个节点所在的网络分裂成了多个，如两台交换机互联，而集群的多个节点分别连接在这两台交换机上，而两台交换机互联的线路出现故障，造成集群所在网络分裂（分区）了，主设备的一切服务正常，但是备用设备却接收不到heartbeat信息和其他集群事务决策信息，此时集群该如何决断？如下图：

一旦网络出现分区，集群必须保证只有一台主设备对外服务，否则就会出现混乱。

这时需要有一个投票决策系统（vote system），实行少数服从多数原则，同时，为了防止另一侧的主机继续或又抢占为主设备，投票决策后的主机会对另一侧的节点进行隔离。隔离分为节点级和资源级隔离，隔离分类：
        STONITH：shoot the other node on the head  节点级别隔离（爆头，将节点彻底隔离）
        Fence：资源级别的隔离（对共享的资源进行隔离，如共享存储）

STONITH，一般是有一个电源交换机，可以将要隔离的节点的电源关闭；
Fence，所有节点通过光交换机共享一个磁盘，关闭隔离节点连接到磁盘的光接口即可实现隔离；

如果网络分区后出现节点数相同的情况，如两个节点的集群，如果网络出现了分区，此时解决方案有两种：仲裁节点和仲裁盘
仲裁节点就是集群节点都需要连接的节点设备，如路由器，通过路由器来仲裁到底谁是主节点，路由器能够访问到的，就作为主节点。
仲裁盘（quorum disk ，qdisk），就是提供一个共享磁盘，每个节点都周期性往这个磁盘写一个标志信息，并能监控标志信息。如果有一个节点在规定的几个周期内没有写，那就认为出现故障，这个磁盘就叫做仲裁盘。

双节点系统必须配置仲裁节点或仲裁盘。

N-M模型：N个节点M个服务
    就是使用了N个节点，其上运行了M个服务，如一个集群使用了5个节点（设备），其上提供了httpd、ftp、mail、dns4个服务，每个节点运行一个服务，可以充分发挥每个节点的性能，又不至于造成浪费。每个节点上运行一个服务，剩下一个节点作为备用。
    但是，如何保证其中一个节点出现问题，资源会转移到第5个节点上呢？又如果出现了2个及以上节点出现故障，此时资源如何转移，都转移到第5个节点吗？会不会造成第5个节点压力过大，响应缓慢的问题？是不是可以考虑资源转移到其他正常的、性能余量大的节点呢？

第一种解决方案，使用failover domain —— 故障转移域：
    fda：node1，node5
    fdb：node2，node5
    fdc：node3，node5
    fdd：node4，node5
如在fda故障转移域中，node1出现故障，资源转移到node5。这样就是将node5作为唯一的备用节点了。

第二种解决方案，定义资源对节点的倾向性。因为对于上图的5-4模型集群，如果没有特别配置，很难保证httpd单独运行在node1，ftp单独运行于node2，mail单独运行于node3，dns单独运行于node4，很可能服务两两挤在一个节点上，或多个服务挤在一个节点上。解决方法就是定义资源对节点的倾向性，类似优先级。如httpd服务对于node1的倾向性为无穷大，代表只要node1无故障，httpd就要运行在其上，若倾向性为负无穷大，代表只要集群中还有其他无故障节点，httpd就不会运行于node1上，若倾向性为一个数值，类似优先级，判断后选择。如httpd对node1倾向性为正无穷大，对node5倾向性为100，对node2为负无穷大，则httpd运行于node1，故障后转移至node5，故障后，如果集群中只剩下node2，才会转移至node2上。

第三种解决方案，是定义资源之间的倾向性。有时候，还可能出现这样的需求，就是资源之间不能同时运行于一个节点，即资源之间是互斥的关系，如httpd不能跟dns运行在一个node上；还有需求是两个资源必须运行于同一个节点上；还有就是资源的启动要求有一定的顺序。

对于倾向性，可定义资源的约束性，资源的约束性分以下几类：
  位置约束：资源对节点的倾向性
  排列约束：资源彼此间是否能运行于同一节点的倾向性
  顺序约束：多个资源的启动顺序依赖关系；

vote system（投票系统）：
  少数服从多数原则：quorum
    with quorum：拥有法定票数     > total/2
    without quorum：不拥有法定票数    < total/2

两个节点（偶数个节点）：引入仲裁节点
  ping node
  qdisk

failover：故障转出，节点故障时，资源转出叫做failover
failback：故障转回，故障的节点恢复后，转出的资源又转回来，叫做failback

集群各层次功能实现及简释

Messaging Layer：  heartbeat，corosync，cman都提供了ML层功能
  heartbeat：多个版本 v1、 v2、v3

Cluster Resource Manager（CRM，集群资源管理器），实现此功能的有：
  heartbeat v1 haresources （配置接口：配置文件haresources）
  heartbeat v2 crm （配置文件为XML文件，因手动修改XML较困难，在每个节点运行一个crmd（5560/tcp）守护进程，有命令行接口crmsh；GUI图形接口：hb_gui，用以对XML配置修改）
  heartbeat v3，CRM被独立出来为 pacemaker （ 配置接口：crmsh，pcs-红帽开发；GUI：hawk(suse)，LCMC，pacemaker-gui）
  rgmanager：红帽的资源管理器，cman的crm（配置文件：cluster.conf，配置接口：system-config-cluster，conga(webgui),cman_tool,clustat）

实现一个集群的组合方式，即要实现ML和CRM两层的功能：
  heartbeat v1 （haresources），即v1版本本身具有完整的ML和CRM层
  heartbeat v2 （crm），v2同v1，CRM层的实现叫做crm
  heartbeat v3 + pacemaker，因CRM层独立出去，所以实现集群需要两个软件组合
  corosync + pacemaker：分两种
    corosync v1 + pacemaker （plugins），pacemaker作为corosync的插件使用
    corosync v2 + pacemaker（standalone service），pacemaker是作为独立服务运行的
  cman + rgmanager，这是红帽的集群实现，cman主要实现ML层，rgmanager实现CRM层。
  corosync v1 + cman + pacemaker，cman的vote system很完善，而corosync v1没有vote system

RHCS：Red Hat Cluster Suite（红帽集群套件）
  RHEL5：cman+rgmanager+conga（Ricci/Luci），conga是配置工具，由两部分组成Ricci/Luci
  RHCL6：cman + rgmanager + conga（Ricci/Luci）
                  corosync + pacemaker
                  corosync + cman + pacemaker
  RHCL7：corosync + pacemaker

Conga是一种新的基于网络的集群配置工具，Conga是通过web方式来配置和管理集群节点的。Conga有两部分组成，分别是luci和ricci，luci安装在一台独立的计算机上，用于配置和管理集群，Luci是一个基于web的集群配置工具，通过它可以直接管理和配置RHCS集群。Luci提供了一个图形界面，使得集群的配置和管理变得更加直观和简单。ricci安装在每个集群节点上，Luci通过ricci和集群中的每个节点进行通信。

RHCS 集群组成简单了解，其组成主要有以下几部分：
  ● 集群架构管理器
  这是RHCS 集群的一个基础套件，提供一个集群的基本功能，使各个节点组成的集群在一起工作，具体包含分布式集群管理器（CMAN），成员关系管理、锁管理（DLM）、配置文件管理（CCS——ClusterConfigurationSystem）、栅设备（FENCE）
  ● 高可用服务管理器
  rgmanager，提供节点服务监控和服务故障转移，当一个节点服务出现故障时，将服务转移到另一个健康的节点上。
  ● 集群配置管理工具
  通过Luci来管理和配置RHCS集群，Luci是一个基于web的集群配置方式，通过Luci可以轻松的搭建一个功能强大的集群系统，节点主机可以使用ricci来和luci 管理端进行通信
  ● Linux virtual server
  LVS 是一个开源的负载均衡软件，利用LVS 可以将客户端的请求根据指定的负载策略和算法合理分配到各个节点，实现动态、智能的负载分担。
  ● RedHatGS（Global FileSystem）
  GFS 是Redhat公司开发的一款集群文件系统，GFS文件系统允许多个服务同时读写一个磁盘分区，通过GFS可以实现数据的集中管理，免去了数据同步和拷贝的麻烦，但GFS不能独立存在，需要RHCS的底层组件支持
  ● ClusterLogicalVolumeManger
  Cluster 逻辑卷管理，即CLVM，是LVM的扩展，允许cluster 中的机器使用LVM来管理共享存储
  ● ISCSI
  是一种在Internet协议上，特别是以太网上进行数据传输的标准，是一种基于IPstorage理论的新型存储技术，RHCS可以通过ISCSI技术来导出和分配共享存储的使用。

Resource Agent（RA）：资源代理的种类很多
    heartbeat legacy（heartbeat传统代理）：/etc/ha.d/haresources.d/目录下的脚本
    LSB（Linux标准代理）：/etc/rc.d/init.d/目录下的脚本，基本参数：start|stop|restart|status
    OCF（Open Cluster Framework--开放集群框架）：遵循OCF规范的脚本
          provider：需要提供者
    STONITH：不同厂商提供的用于节点隔离的代理
    systemd：使用systemctl进行代理

资源类型：
    primitive：主资源，原始资源，在集群中只能运行一个实例；
    clone：克隆资源，在集群中可运行多个实例；
        匿名克隆、全局唯一克隆、状态克隆（主动、被动）
    multi-state（master/slave）：克隆资源的特殊实现，多状态资源；
    group：组资源，同进同退的一组资源；具有如下属性：
        启动或停止
        资源监控
        相关性

资源属性：
    priority：优先级；
    target-role：started、stopped、master；资源被配置到集群时的状态角色；
    is-managed：是否允许集群管理此资源；
    resource-stickiness：资源粘性，资源留在当前节点的倾向性。
    allow-migrate：是否允许迁移；

约束：score
    前面介绍过，三种，位置、排列、顺序三种约束
    （-∞，+∞）