高可用集群
LinuxHA Clusterhtml
高可用集群，英文原文为High Availability Cluster，简称HACluster，简单的说，集群（cluster）就是一组计算机，它们做为一个总体向用户提供一组网络资源。这些单个的计算机系统 就是集群的节点（node）。node
高可用集群的出现是为了使集群的总体服务尽量可用，从而减小由计算机硬件和软件易错性所带来的损失。若是某个节点失效，它的备援节点将在几秒钟的时间内接管它的职责。所以，对于用户而言，集群永远不会停机。web
高可用集群软件的主要做用就是实现故障检查和业务切换的自动化。只有两个节点的高可用集群又称为双机热备，即便用两台服务器互相备份。当一台服务器出现故障时，可由另外一台服务器承担服务任务，从而在不须要人工干预的状况下，自动保证系统能持续对外提供服务。双机热备只是高可用集群的一种，高可用集群系统更能够支持两个以上的节点，提供比双机热备更多、更高级的功能，更能知足用户不断出现的需求变化。服务器
HACluster特性：网络
1.提供冗余系统：架构
HACluster：为提高系统调用性，组合多台主机构建成为的集群；ide
2.vote system：投票系统工具
HA中的各节点没法探测彼此的心跳信息时，必须没法协调工做；此种状态即为partitioned cluster；这个时候就须要一些机制来断定：ui
（a）少数服从多数的原则，仲裁quorum：spa
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，那么当node一、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 提供了多种用户接口：