LinuxHA Cluster
高可用集群，英文原文为High Availability Cluster，简称HACluster，简单的说，集群（cluster）就是一组计算机，它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统 就是集群的节点（node）。
高可用集群的出现是为了使集群的整体服务尽可能可用，从而减少由计算机硬件和软件易错性所带来的损失。如果某个节点失效，它的备援节点将在几秒钟的时间内接管它的职责。因此，对于用户而言，集群永远不会停机。
高可用集群软件的主要作用就是实现故障检查和业务切换的自动化。只有两个节点的高可用集群又称为双机热备，即使用两台服务器互相备份。当一台服务器出现故障时，可由另一台服务器承担服务任务，从而在不需要人工干预的情况下，自动保证系统能持续对外提供服务。双机热备只是高可用集群的一种，高可用集群系统更可以支持两个以上的节点，提供比双机热备更多、更高级的功能，更能满足用户不断出现的需求变化。
HACluster特性：
1.提供冗余系统：
HACluster：为提升系统调用性，组合多台主机构建成为的集群；
2.vote system：投票系统
HA中的各节点无法探测彼此的心跳信息时，必须无法协调工作；此种状态即为partitioned cluster；这个时候就需要一些机制来判定：
（a）少数服从多数的原则，仲裁quorum：
withquorum > total/2
即HA奇数的时候，可以实现投票仲裁，少数服从多数
withoutquorum <= total/2
即HA偶数的时候，两方人数相等，只能依靠第三方仲裁设备
在没有仲裁的情况下，原有资源按以下设定运行：
stopped默认
ignore 继续运行，有可能造成资源争用
freeze原有正在访问的用户可以继续访问，直到退出为止。但新的链
接不被接受
suicide 自杀
（b）仲裁设备：
quorumdisk = qdisk
即HA同时往一个磁盘写数据，表示自己的存在，无法正常写入时即代表有问题
pingnode
同时ping某个网关或设备，无法正常ping通时即代表有问题
3.failover: 失效转移，故障转移
failback：失效转回，故障转回。
例如ha.cf中有一项auto_failback on 表示修复上线后自动转回之前正常工作状态
4.心跳信息传递机制
HA之间通过多种检测机制和方式保持联系和判断是否可用
(a).serail cable：串口，作用范围有限，不建议使用；
(b).ethernet cable：网线，通过交换机来通信，还可以在每台HA上多加一个
网卡，直接连接起来，和交换机那个连接做主从备用
(c).UDP Unicast 单播，使用UDP协议，速度快
(d).UDP Multicast 多播
(e).UDP Broadcast 组播
组播地址：用于标识一个IP组播域；
IANA(Internet Assigned number authority)把D类地址空间分配给IP组播使用；
其范围是：224.0.0.0-239.255.255.255; 网卡要启动组播地址功能才能使用。
永久组播地址：224.0.0.0-224.0.0.255;
临时组播地址：224.0.1.0-238.255.255.255;
本地组播地址：239.0.0.0-239.255.255.255, 仅在特定本地范围内有效；
HACluster的工作模型：
A/P：两节点集群，active, passive；工作于主备模型；HA Service通常只有一个：HAresources可能会有
多个；
A/A：两节点集群，active/active，工作于双主模型；
通常这个模型，两节点所提供的服务不一样，不过也可以一样！例如2个节点运行的都是http 80端口的
服务，当其中一个节点离线，可以将它的IP转到另一台节点，因为服务内容是一样的，不转移服务也可
以！
N-M： N个节点，M个服务；通常N>M；例如有3个节点提供服务，还有1个只做备用
N-N：N个节点，N个服务；N个节点同时提供服务，当其中一个出现故障，资源
会转移到其他节点上一并运行
HACluster的资源：
在HA中，各种服务、IP、文件系统都统称为资源
资源类型：
两大类：
(1) HA-aware：资源自身可直接调用HA集群底层(message layer)的HA功能；
(2) 非HA-aware：必须借助于CRM完成在HA集群上实现HA功能；
具体分类：
(a)primitive：主资源，只能运行于集群内的某单个节点；(也称作native)；
(b) group：组资源，容器，包含一个或多个资源，这些资源可通过“组”这个资源统一进行调度；
(c)clone：克隆资源，可以在同一个集群内的多个节点运行多份克隆；
(d) master/slave：主从资源，在同一个集群内部于两个节点运行两份资源，其中一个主，一个为从；
资源的约束关系：
(a).location：位置约束，定义资源对节点的倾向性；用数值来表示，-oo, +oo；
例如某IP资源，对node1定义了100，node2定义了200，那么当node1、node2都正常工作时，该IP会选择在
node2上工作
(b).colocation：排列约束，定义资源彼此间“在一起”倾向性；-oo, +oo
分组：亦能实现将多个资源绑定在一起；
(c).order：顺序约束，定义资源在同一个节点上启动时的先后顺序；
有次序地启动资源；关闭的顺序正好与启动相反
例如haresource中某一条资源的定义：
(ha1)(192.168.61.100/24/eth0/192.168.61.255)(Filesystem::192.168.61.33:/tmp/webfile::/var/www/html::nfs) (httpd)
上面语句用括号划分（原语句没有）为4部分：主服务主机名 资源1 资源2 资源3
实验中可以查看log文件，启动时顺序是：资源1 -> 资源2 -> 资源3,切换关闭时顺序是：资源3 -> 资源2 -> 资源1
注意：heartbeat v1 不支持资源约束！
资源隔离：
级别
1.节点级别：STONITH(shooting the other node in the head)
关闭整个节点，通常用电源交换机
2.资源级别：fencing 只要隔离这个节点的资源访问就可以了，没必要关闭节点
(例如2个HA节点，通过交换机FC SAN同时连接一个存储，当其中一个节点出问题，只要控制交换机断掉出问题节点就可以）
HACluster架构
模型分层
1. messagelayer基础架构层；（主要负责心跳、事物信息的传递）
2. CRM集群资源管理器；（负责非ha aware服务的管理、调度，相当于一个管理中心，
可理解为，战略制定，或董事长。通过调用下层的API,并向上提供API接口。还提供一个管理员接口。提供资源的顺序、位置、排列机制）
3. LRM本地资源管理器；（可理解为，战略执行，CEO。为本地资源提供管理功能)
4.RA 代理； (可理解为：真正做事情的人。因为CEO不可能自己去做吧。）
架构各层次解决方案
message layer层：
1.heartbeat有v1,v2,v3版本，区别很大。早期流行，配置复杂，资源管理器很好用。
它除了message layer ,还提供其他各层，如CRM,LRM,RA
2.corosync仅提供message layer
3.cman红帽的，很强大，发展快
4.keepalived(工作方式完全不同于上述3种）
CRM层：
1.heartbeatv1版 haresources (配置接口就一个配置文件：haresources)
2.heartbeatv2 crm (在各节点运行一个crmd进程，配置接口：命令行客户端程序crmsh,gui客户端：hb_gui)
3.heartbeatv3 pacemaker (可以以插件或独立方式运行,配置接口：命令行接口：crmsh
（不是红帽自己的）,pcs(红帽自己的，难用，6.4后只提供这个。GUI接口：hawk,lcmc,pacemaker-mgmt)
4.rgmanager
注意：上述CRM已经自带了LRM
LRM层:由CRM通过子程序提供
RA层:
(a) heartbeatlegacy：heartbeat传统类型的RA，通常位于/etc/ha.d/haresources.d/目录下；
(b) LSB：Linux Standard Base, /etc/rc.d/init.d目录下的脚本，至少接受4个参数：
{start|stop|restart|status}；cenost7后没这些脚本，systemd管理
(c) OCF：Open Cluster Framework
子类别：provider
STONITH：专用于实现调用STONITH设备功能的资源；通常为clone类型；
上述各层可以组合使用，组合方式：
heartbeatv1 可以单独使用，包含了各层（4层）功能
heartbeatv2 可以单独使用，包含了各层（4层）功能
heartbeatv3 + pacemaker 这个版本分层设计了，分拆为heartbeat pacemaker
cluster-glue，需要搭配其他层使用
corosync+ pacemaker
cman+ rgmanager (RHCS)
cman+ pacemaker
HACluster软件简介
Corosync：它属于OpenAIS(开放式应用接口规范)中的一个项目corosync一版本中本身不具 备投票功能，到了corosync 2.0之后引入了votequorum子系统也具备了投票功能了，如果我们用的是1版本的，又需要用到票数做决策时那该如何是好呢；当然，在红帽上把 cman + corosync结合起来用，但是早期cman跟pacemaker没法结合起来，如果想用pacemaker又想用投票功能的话，那就把cman当成 corosync的插件来用，把cman当成corodync的投票功能，当然，这里结合了两个了Messaging Lader；Corosync目前有两个主流的版本：一个是2系列的，另一个是1系列的稳定版；2版本和1版本差别很大，1版本不具有投票功能，2版本之后引入了votequorum后支持投票功能了；OpenAIS自从诞生之后，红帽就基于这个规范研发了一个高可用集群的解决方案叫cman，并为cman提供了rgmangaer作为资源管理器，并且容合conga全生命周期的管理接口形成了RHCS；
Conrosync是从OpenAIS这个大项目中分支出来的一个项目，而Pacemaker是heartbeat v3版本中分裂出来专门用于提供高可用集群CRM的组件，功能十分强大， Coreosync在传递信息的时候可以通过一个简单的配置文件来定义信息传递的方式和协议等，Corosync可以提供一个完整的HA功 能，Corosync是未来的发展方向，在以后的新项目里，一般采用Corosync，而heartbeat_gui可以提供很好的HA管理功能，可以实 现图形化的管理。
Pacemaker是一个集群管理器。它利用首选集群基础设施（OpenAIS 或heartbeat）提供的消息和成员能力，由辅助节点和系统进行故障检测和回收，实现性群集服务（亦称资源）的高可用性。
Heartbeat3与 2.x的最大差别在于，3 按模块把的原来2.x 拆分为多个子项目，并且提供了一个cluster-glue的组件，专用于Local ResourceManager 的管理。即heartbeat +cluster-glue + resouce-agent 三部分：
（1）hearbeat本身是整个集群的基础（cluster messaging layer），负责维护集群各节点的
信息以及它们之前通信；
（2）cluster-glue相当于一个中间层，可以将heartbeat和crm（pacemaker）联系起来，
主要包含2个部分，LRM和STONITH；
（3）resource-agent，就是各种的资源的ocf脚本，这些脚本将被LRM调用从而实现各
种资源启动、停止、监控等等。
通过这三部分已可构成一套完整的HA集群系统。但是，这还不够，因为没有管理工具。
而原GUI 工具Cluster Resource Manager （简称CRM）也被拆分由另一独立项目Pacemaker 负责。Pacemaker 提供了多种用户接口：