前面我们了解到linux上的集群大致分为：LB、HA、HP。对于HP集群用的比较少，大多用的是并行处理系统，我们也可以称为分布式计算和存储平台，比如hadoop
LB集群的方案有：
传输层实现的：lvs
应用层实现的：nginx, haproxy, httpd(用到的是proxy模块和balance模块)，perlbal, ats, varnish
HA集群的方案有：
vrrp协议的实现：keepalived
AIS（专门的HA集群的实现）：heartbeat、OpenAIS、corosync/pacemaker，cman/rgmanager(conga) RHCS
AIS有两个著名的实现：heatbeat和OpenAIS。
AIS实现的内容当中，除了高可用集群之外，还有自己非常复杂的庞大的API。从这个角度来说，OpenAIS既是一个高可用集群解决方案，同时也是高可用应用程序调用接口的方案。corosync是OpenAIS的一个实现，并且是独立出来的一个项目。其实cman也是在OpenAIS基础之上研发的另外一个分支，由红帽自己来维护。后来人们发现corosync实现的功能比cman要强大多了，所以到今天为止，红帽已经抛弃了cman而采用corosync了，rgmanager是cman专用的集群资源管理器，cman+rgmanager这套组合再加上它的web gui套件conga, 统称为RHCS，红帽的集群套件。这套方案所能够实现的功能要远远强于keepalived，如果我们仅仅是要高可用lvs的话，keepalived要比heartbeat或corosync更适应；但是要构建一个基于某种服务所实现的高可用集群，甚至要仲裁很多复杂机制的话，corosync才是不二选择。
对于x86平台的pc server这些服务器来说，出现故障的可能性是很大的，出现故障的场景有：
硬件故障：
设计缺陷
使用过久自然损坏
人为故障
。。。
软件故障
设计缺陷
bug
人为误操作
。。。
衡量一个系统的可用性的方式：
公式：
A=MTBF/(MTBF+MTTR) MTBF: Mean Time Between Failure,平均无故障时间 MTTR: Mean Time To Repair,平均修复时间
0 < A < 1 它的计算结果是介于0和1之间的值，不过我们一般用百分比来衡量它。
常见的有90%算是可用性较低的了；95%的可用性还算可以，对于要求不是特别高的场景，基本可以接受；99%算是好的了；
但是对于一些非常关键性的系统来说，我们通常用几个9来衡量它的可用性：比如三个9，指的是99.9%、四个9：99.99%、五个9：99.999%,那就很困难了
从上面的公式可以看出，要想提高系统的可用性，无非是增大分子，或者减小分母。增大分子是很困难的，所以只有减小分母，也就是降低平均修复时间。我们可以通过冗余这种思路：
当一个节点出现故障时，我们用冗余节点取而代之，让故障节点下线、修复然后重新上线作为冗余节点，来提供系统的可用性。
所以说提供冗余的这种机制，就是找一个与它原有的活动节点具有相似或相同功能的节点，随时进行备用，一旦活动节点故障，备用节点就取而代之。我们提供服务的主机不再是一台主机，而是一组主机，这也是为什么我们将它称之为cluster的原因。
对于cluster来说，它可能需要解决诸多问题：
两个主机之间，备用主机如何才能够成为备用：
比如我们之前了解到的keepalived，在每一个节点之上都装有keepalived这个程序。这两个节点上的keepalived彼此之间能够互相通信，并且能够基于某种仲裁机制来决定谁是主节点谁是备用节点。主节点还要周期性的，比如每一秒钟进行广播或单播或多播一次自己的心跳信息，心跳信息包括传递vrrp的事务信息和自己的优先级等短小信息，这样备用节点才能知道主节点下线了并取而代之。
无论是哪一种高可用集群，它们通常都需要一个运行在多个节点上的，彼此间能够互相通信、传递心跳和集群事务决策中所依赖的其他信息的应用程序。这个应用程序对于高可用集群来说，是一个基础性的程序，没有它，高可用集群将无法工作。这个程序通常称为高可用集群的信息传递层，也称为基础架构层。这个层次我们称为Messaging Layer。
我们知道keepalived根据优先级来决定主备节点，那么，如何实现让一个主节点能够在没有故障的情况下也能够降级为备节点呢，也就是它本地要监控着一些资源或运行着一些监控条件，一旦某些条件不能满足时，就自动降低自身优先级。这就是集群事务仲裁机制。对于keepalived来说，这样的冲裁机制仍然由keepalved来完成，而对于AIS这样类别的集群来说，不是这样的。也就是说Messaging Layer它并不负责集群事务仲裁功能，它仅仅是将当前节点所通告的心跳信息通过多播、单播或广播的方式传递给同一集群中的其他节点，最终哪个节点该是主的哪个节点该是备的，keepalbed当中是调用vrrp_script来额外定义脚本实现的，而对于AIS集群来说，有一个专门的功能非常强大的层次来完成这个功能，这个层次也需要运行在各个节点之上，它们需要调用Messaging Layer当中所需要实现的功能。
Messaging Layer能够传递各节点之间的集群事务信息，一旦主节点不在了，它传递心跳信息的机制也就无法完成了。这时候，我们就需要将运行在主节点上的服务要切换到另外一个节点上，Messaging Layer并不完成这个功能，keepalved是通过在脚本中notify start等来实现的。而为了支撑更多的服务能够实现高可用功能，Messaging Layer将自己实现的各种功能都通过API向外提供，这就是AIS提供大量API的原因。
这样一来，任何一个服务要想实现高可用的话，它就需要调用这些API去研发才可以。既然每种服务都需要去调用API研发，那么就做成一个通用功能，就有人实现了这个机制。这个层次我们称之为资源管理层, Resource Manager。每一个在这个平台上需要运行的服务就是所谓的资源了。
Resource Manager所实现的功能是承上启下的，承上负责管理运行在高可用集群中每个节点上的每一个资源，向下还要调用Messaging Layer的API所开发的这些功能来决定在多个节点中哪一个节点是活动的，哪一个是备用的，一旦活动节点故障了，它还能实现将资源转移到备用节点上。不仅仅如此，Resource Manager不但能够监控硬件，还能监控软件。比如活动节点上运行的是httpd服务，当它发现httpd服务进程挂了，它会尝试着重启httpd，重启成功就会继续运行，而重启失败再重启，还是失败，就会将httpd服务转移到备用节点，IP地址也要转移过去。那么，如何保证IP地址和httpd服务一起转义过去同进退呢，我们需要自己来定义的，我们需要定义资源和资源之间有一种什么样的关系才可以的。
不过这样的话，Resource Manager就太难了，所以在在这一层之上还有第三个层次，我们称之为本地资源管理层，Local Resource Manager。这个层次我们可以认为它是Resource Manager的一个子系统，但可以当做一个独立层次来理解。它只负责管理当前主机上的资源启动重启等操作，并且将操作的结果通知给Resource Manager，比如重启成功了就可以了，重启不成功的话Resource Manager还要重新做出决策。LRM管理资源其实是通过调用资源代理来完成资源管理的。
这些就是高可用集群当中的几个基本层次，其中LRM和RM其实是由一个层次来完成的，而资源代理是通过服务脚本来实现的。
有这么一种情况，高可用集群中有多个节点，一个节点在交换机1上，一个节点再交换机2上，这两个交换机之间直接是通过某一个汇聚交换机或直接是一根网线相连，如果这根网线故障了，交换机1上节点好好的，但就是无法和交换机2上节点通信了，这个时候，我们的集群就被割裂了，割裂的原因是网络出现了partition，网络分区了，交换机1这边的partition只能找到四个节点，交换机2网络分区只能找到3个节点了，那么接下来怎么办？
这时候，我们就必须保证一旦网络分区，只能有一方能够代表集群继续工作。我们可以设计一个投票系统vote system，来决定当出现网络分区了，由哪一方继续代表集群工作。万一另一方待会又回来了怎么办，可以强制让它下线。
所以，一旦网络发生分区，我们就要借助于投票系统完成隔离操作，隔离的方式有两种：
network partition：vote system
隔离：
STONITH: shoot the other node on the head, 节点级别的隔离，直接将别的节点给下线
Fence: 资源隔离，只要让别人访问不到资源就可以了
vote system:
少数服从多数：quorum
with quorum:拥有法定票数，法定票数就是大于总票数的一半
without quorum: 不拥有法定票数
一般来说，隔离是只有那些非常关键性的，绝不允许两个节点同时访问，一访问就要崩溃的资源，我们才需要做这么严苛的设定。
那么就有这么一种情况，两节点的集群如果发生网络隔离，接下来谁应该代表集群继续工作呢，投票数是均分的，这种时候谁都不应该代表集群继续工作，这时候，就需要借助于第三方仲裁机制来完成这种操作。比如一个节点能够连上网关，另一个节点连不上网关，那么我们可以将网关节点作为仲裁设备，谁能够找到这个网关，谁就是活动的一方。这种方式可能不够靠谱，我们可以使用共享存储，将共享存储设备当做仲裁设备，任何活动状态的节点都要周期性往共享存储写一位数据，只要一个节点几个周期没写，那么就认为对方挂了，这种就叫做仲裁盘。RHCS中有个quorum disk,它是帮助两节点完成仲裁的仲裁设备，简称为qdisk。
两个节点（偶数个节点）：这种情况就需要引入仲裁节点
比如：
Ping node
qdisk
对于多节点高可用集群来说，活动节点只有一个，其他就都为备用节点，这样是不是很浪费。不过我们可以运行多个高可用服务，比如第一个运行web服务，将其他四个当做备用节点，第二个节点运行smtp服务，剩余四个当做备用节点，类似这种方式，我们称为N-M模型。
那么就有个问题，比如我们专门用一个空闲节点来当做其他四个节点的备用节点，一旦一个节点故障了，那么怎么保证故障节点上资源能转移到那个空闲节点而不是其他节点呢。这就要说到资源管理器的特性了，它在实现转移的时候可以分为两类情形来对待，第一种：我们可以将主机分为主机组，这个主机组称为故障转移域（failover domain), 比如将1号节点和5号节点做成故障转移域，当一号节点故障了，资源就会自动转移到5号节点上了。
failover domain:
fda: node1, node5
fdb: node2, node5
fdc: node3, node5
fdd: node4, node5
第二种方案：我们可以定义资源对节点的倾向性，比如第一个资源对第一个节点的倾向性是+oo，第一个资源对第五个节点的倾向性是100，那么第一个资源会优先运行在第一个节点，当第一个节点故障了，资源就会转移到第五个节点上。 再比如，两个服务不能两两运行在一起，这时候我们就要定义两个资源之间的约束关系，有三种方式：
资源的约束性：约束我们一般通过score来衡量
位置约束：资源对某一个节点的倾向性;
取值范围是（-oo, +oo）：如果对一个节点的倾向性是-oo，但是没有其他节点可用了，它也照样能够在这个节点上运行，一旦有其他节点可用，它就立马转到其他节点上运行
多个资源的倾向性可以进行运算：一般无穷大是用100万表示
任何值 + 无穷大 = 无穷大
任何值 + 负无穷大 = 负无穷大
无穷大 + 负无穷大 = 负无穷大
排列约束：资源彼此间是否能运行于同一节点的倾向性
取值范围：（-oo, +oo）
顺序约束：多个资源启动顺序依赖关系
取值范围（-oo,+oo）
特殊用法：
Mandatory: 强制，相当于正无穷
这样，就能让资源管理器决定哪些资源应该运行在什么位置了。
下面我们来详细了解下高可用集群当中的三个层次：
Messageing Layer：消息传递层, 主要用来传递心跳以及集群事务等信息。这个层次通常是应用服务程序，而且运行于每个节点上。
这些服务程序有:
heartbeat v1, v2, v3;
corosync
cman
heartbeat v1版自带的就有资源管理器，到v2版已经不怎么维护了，到v3版分裂成了两个项目: heartbeat和pacemaker；而heartbeat所实现的功能远远没有corosync强大，所以也不怎么被使用了。
corosync：
AIS早期的时候为了演示的目的而研发的系统OpenAIS，后来OpenAIS分裂成两个项目。一个是corosync，专门用来做Messaging Layer; 而原本专门对高可用提供可用性的API依然留在了OpenAIS中，
红帽的cman其实也是脱胎于OpenAIS。
cman与corosync的对阵当中已然败下阵来，而人们发现它所实现的功能也远远没有corosync强大，所以到v3版维护也已经不怎么活跃了，未来很可能会被废弃，所以将来估计就是corosync的天下了。
不过corosync它只是一个消息传递层，没有集群资源管理器。而从heartbeat中独立出来的pacemaker反而越来越受到青睐,也就是我们说的第二层CRM。
corosync有v1，v2两个版本：
CentOS6上默认是v1版
CentOS7上默认是v2版，v2版最大的特性是它有自己的votequorm
有了消息传递层message layer,那么任何一个程序员在开发一个服务程序时，只要调用了Messaging Layer的API,那么就可以做到自我实现高可用。但是应用程序的程序员他们
很可能压根就没有尝试着去调用这个API, 更何况高可用本来就是个通用功能，因此,后来就有了将那些本身不具备调用Messageing Layer的服务,做成一个通用层，这个层就叫做集群资源管理器。
其实有些程序是调用了Messaging Layer的API研发的, 因此，这类应用程序本身是拥有了高可用服务所拥有的功能的，不过这种应用少之又少。
Cluster Resource Manager：集群资源管理器层,主要目的是让那些本身不具备高可用能力的服务也能够运行在高可用集群中，以高可用模式的方式提供高可用服务。
资源管理器有：
heartbeat v1：自带的就有集群资源管理器叫做 haresources （配置接口：配置文件haresources）
heartbeat v2：自带的集群资源管理器叫做 crm，在每个节点运行一个crmd守护进程，监听在5560/tcp，它的配置文件是xml格式的文件，所以很少有人能够熟悉的配置，所以它有客户端接口工具，能够将对crmd发送的配置信息自动转为xml格式的，而且这个xml格式的配置文件会发布给每一个节点。客户端程序命令行接口工具有：crmsh、crmsh还不是很完善，所以有了一个补充性的图形化接口heartbeat-gui，安装上后有一个图形接口：hb_gui
heartbeat v3：资源管理器被独立出来称为一个独立的项目，叫做 pacemaker，在heartbeat v3之后，它与heartbeat结合时依然可以作为独立服务运行，与corosync v1结合时是 作为插件来运行的
pacemaker项目被重命名成pacemaker, 而且已经被独立成为一个单独的项目使用。pacemaker虽然是heartbeat v3版中独立出来的，但它比原生的heartbeat所提供CRM更受到青睐，
因为heartbeat已经有了更好的替代者corosync。所以在CRM当中，我们目前可用的选择无非就是pacemaker。
无论任何一个集群资源管理器，为了管理高可用集群中可配置的资源（这些资源比如IP地址、各种各样的服务、文件系统的挂载等）,它都应该有自己的配置接口。
所以对于pacemaker来讲，它就需要提供一个接口让用户能够按需要定义资源,甚至定义整个集群的工作特性。
pacemaker有自己开发的API能够跟其他的配置工具进行交互，当然我们也可以通过pacemaker自己可读取的xml配置文件进行配置,不过对于大多数用户来说这是一个挑战。
后来有人开发的配置接口有：
crmsh
crmsh是suse研发的配置接口，它是python语言研发的，是agentless的, 它在管理每一个高可用集群中的节点时是通过pssh实现的。
早期的时候，crmsh v1版仅仅是用来配置pacemaker，不能用来实现安装corosync、pacemaker并启动pacemaker,所以它不是一个全生命周期管理配置工具。
crmsh v2版以后也能实现全生命周期管理，安装好crmsh之后,它能够帮我们根据需要在所有节点上安装corosync、pacemaker，配置好集群并启动起来，甚至集群的停止，删除等操作。
pcs
pcs是红帽研发的配置接口，它也是python语言研发的，但它是依赖agent的，管理每一个高可用集群中的节点是通过pcsd实现的；
pcs也可以实现全生命周期管理，centos6上面的pcs是不拥有pcsd的，所以它只能实现集群配置，而不能实现安装。
pacemacer还有其他的图形化接口工具：hawk(suse), LCMC, pacemaker-gui
rgmanager：
它是红帽rhcs提供的资源管理器的解决方案，红帽给rgmanager提供的配置接口弱爆了，它的配置接口文件是：cluster.conf，这个配置文件是xml格式的，配置起来比较麻烦，
所以后来红帽又提供了两个工具：system-config-cluster,conga；此外还有其他的一些命令行配置工具：cman_tool,clustat等，不过又丑又不好用。
conga
conga是基于pacemaker的API去研发的webgui接口中的一种,它的组件包括ricci和luci。
ricci在红帽6.4之前的确发挥了作用，luci是控制端，ricci是运行在每个节点上的代理。
既然ricci是运行在每个节点上的代理，而pcsd也是运行在每个节点上的代理，所以到了centos7以后，ricci就被废弃了，取而代之的是pcsd
centos6上，如果使用的是rhcs,并且使用rgmanager来实现集群资源管理的话，那我们可以使用rgmanager的配置文件：cluster.conf来进行配置；或者使用conga这种webgui接口进行。
有了CRM，我们接下来就可以配置资源了，就需要用到RA（Resource Agent）。
Resource Agent：资源代理，主要作用是让运行在各节点上的crm中的lrm能够借助于脚本完成服务的的启动、停止、重启和监控等操作
所谓RA本身无非就是一些常用的脚本，但这些脚本为了实现不同的功能，它们在实现上的风格和方式会有所不同，常见的有：
LSB: /etc/rc.d/init.d/目录下的脚本; centos5,centos6,centos7上都可以使用LSB脚本
systemd: /etc/systemd/system/
OCF: Open Cluster Framework, 开放集群框架
任何组织或公司都可以基于这种方式来开发脚本，这些脚本也可以实现start、stop、restart、status操作，但OCF在实现资源监控和和获取元数据方面比LSB的脚本要强大很多，
而且能支持参数，实现灵活配置。
OCF可以由不同组织研发，早期有heartbeat,在pacemaker出现之前，由heartbeat所提供的脚本，我们都称为OCF的provider
目前有三大类provider:
heartbeat
pacemaker
linbit
drbd：分布式磁盘块设备, 就是由这家商业组织研发的。
drbd能够让块设备跨越两个节点，一个节点上的硬盘所有数据能够镜像到另一个节点上的磁盘上，当前节点挂了，另一个节点还有一模一样的数据。
drbd在做成高可用模式时，它是特殊资源，必须是ms类型的，
service: 通用服务，不完全是LSB也不完全是OCF的，但它可以在各种linux发行版都能用，也能实现高可用服务配置的作用，/etc/ha.d/haresources.d/目录下的脚本;
STONITH: 专用于STONITH设备的资源类别
资源一旦在高可用集群上配置起来，它也有自己的类型：有的资源可能只能在整个集群上运行一份，有的资源可以在整个集群上运行N份
资源的类型：
primitive: 通常称为主资源，原始资源；在集群中只能运行一个实例；
clone: 克隆资源，在集群中可运行多个实例
clone资源还有三种特殊种类：
匿名克隆
全局唯一克隆： 我们可以克隆N份，但每份都是全局唯一的
状态克隆：资源的状态有主动和被动之分
multi-state: 多状态类型资源，早些时候称为（master/slave）,这种资源只能运行两份，克隆资源的特殊实现
group：组资源，将资格资源归并到一个组中来，要转移资源的时候可以一起转移
group这种组资源是一种高级资源，它有以下属性
启动或停止：我们可以对一个组资源执行启动或停止操作；
资源监视：还可以被监视
相关性：还可以做相关性，比如组内一个资源启动不了，其他资源都不能启动
将多个资源配置成服务时：
rgmanager用到的是resource group这种机制，所谓资源组就是使用failover domain这种机制实现的。
pacemaker也可以通过resource group来实现，也可以借助于约束constraint的方式来实现。
我们在集群的资源管理器上定义资源的时候，需要定义资源的诸多属性：
资源属性：
priority: 优先级，
target-role: 目标角色，资源配置在集群上之后默认是启动还是停止的；一般有 started,stopped, master等；
is-managed: 是否允许集群管理此资源；
resource-stickness: 资源粘性，指的是资源对当前所在节点的倾向性；比如资源所在的节点挂了，那么资源就会转移到其他节点，当故障节点又回来了，那么资源要不要回到之前的节点，这就取决于资源对节点的粘性
allow-migrate:是否运行迁移；可以指明一个资源是否可以手动迁移到另一个节点上
。。。
高可用集群的可用方案：
CentOS 6:
heartbeat v1 (haresources)： 可以独立使用, 不过没有默认的rpm包，需要去编译
heartbeat v2 (crm)： 可以独立使用，也是没有默认的rpm包，需要去编译
heartbeat v3 + pacemaker ：v3没有专用的集群资源管理器，所以我们要额外配置pacemaker,并且借助pacemaker的接口工具进行配置的；v3不常用
corosync v1 + pacemaker (作为plugin运行)：centos6上默认是corosync v1版，v1版没有投票系统；v2版需要编译，而2.6.32版本的内核对corosync v2的支持是有限的，所以它不能使用v2版的投票系统
cman + rgmanager: 虽然cman投票系统很强，但rgmanager弱爆了，于是我们有一个折中的方案：
conrosync + cman + pacemaker:
corosync v1版它的投票系统没有或者还不完善，cman的投票系统很完善,但是cman又只能结合rgmanager,所以要将cman作为corosync的插件，然后再结合pacemaker
不过这种方案很多分布式文件系统内核的锁（集群锁管理器）支持不是很好,所以用起来即诡异又不好用
CentOS 7:
corosync v2 + pacemaker (作为独立standalone service运行的):这是最好的方案了，v2版有自己的投票系统，据说比cman的投票系统还要好
不过在互联网公司，用的最多的高可用集群解决方案是：
keepalived
原文：https://www.cnblogs.com/ckh2014/p/14407357.html