标签：ha linux
高可用计算公式：A=MTBF/(MTBF+MTTR)
A：Availability
MTBF：mean time between failure
MTTR：mean time to repair
A在0和1之间，使用9来表示其可用性：90%, 95%, 99%, 99.9%, 99.99%, 99.999%
提升可用性的手段：现在用的比较多的便是提供冗余系统。比如，为调度器提供冗余、为调度器和RS连接的交换机提供冗余、为它们之间联系的网线提供冗余、避免两根网线连到交换机上出现环路、为电源提供冗余、为电源线提供冗余、为电源提供交换机等等。
备用主机每隔一段时间就会发送一条短小的探测报文给活动主机，活动主机就会响应一条很简单的报文给备用主机。这种探测报文的机制，就称为heartbeat心跳机制，它们之间连接的线缆我们也称为心跳线缆，专用于心跳检测。一旦活动主机多次未响应，备用主机就会取而代之。这样一来，我们就要用到HA Cluster。
HA Cluster：为提升系统调用性，组合多台主机构建成为的集群。
director的基本配置：ip地址以及ipvs规则。如果备用主机想要取而代之，就需要拥有这些资源。ip地址如何转移？只需将此地址配置在网卡别名上，而不作为主地址即可。
当备用主机取代后，活动主机并没有挂掉，这种情况就称为split brain(脑裂)，而这种集群我们称为partitioned cluster(分区的集群)。集群一旦分裂，两主机之间就会发生拉锯战，如果此时一台主机网存储设备中写，另一台主机删，就会造成文件系统的因错乱而损坏。因为文件上的锁对于另一台主机是没有效果的，而这样的后果是致命的。
如何避免呢？补刀，直接切断活动主机的电源即可。这时就不能使用备用电源了。
以上只是两个节点，如果多个节点，比如5个。节点是不会等待其他节点来探测它的心跳的，而是主动向其他节点进行通告。而由于网络原因，其中3台主机的心跳信息可以彼此送达，另外2台主机直接的心跳信息也能彼此送达，但3台和2台之间却无法送达。这也称为split brain和partitioned cluster。这时怎么办？是3台取代2台，还是2台取代3台呢？很简单，少数服从多数。这就需要在构建高可用集群时，需要一个集群事务决策层。需要一个软件，运行在某个主机上，收集整个集群的状态信息。比如，每个在线的主机可以投一票，一旦分裂，哪方票数多，哪方继续作为活动主机。
因此，集群中设置主机需要保持奇数原则。否则，需要找一个仲裁设备。比如，找一个硬盘，哪台主机能够往里面写入数据，哪台主机就为活动主机。又或者，找一个网关哪台主机ping通，哪台主机就继续作为活动主机。基本上只有两节点的集群是最特殊，需要仲裁设备的。因为，4节点出现两两分裂的几率1/2,6节点就为1/3，只有2节点为100%。
少数服从多数的原则：quorum(法定票数)
with quorum(拥有法定票数) > total/2
without quorum(不再拥有法定票数) <= total/2
仲裁设备：
quorum disk = qdisk
ping node
少数服从多数的原则和仲裁设备只是高可用集群中的一个流派，keepalived是另一种。
我们高可用的目的并不是主机同时在线，而是主机上的服务资源是实时在线的。如果活动的web服务器虽然能够正常发送心跳信息，但是由于web服务无法启动，那怎么办？将其上的资源转移至备用主机。但是活动主机可以正常发送心跳信息，备用主机就无法取代它，资源转移也就无从说起。显然我们不能允许这种情况的发生，因此，作为一个高可用集群服务，它必须具有监控资源可用状态的功能。一旦资源出现故障，就要实现资源转移。因此，便有了以下两种概念：
failover：失效转移，故障转移。
failback：失效转回，故障转回。
也称为心跳层，两台主机之间相互探测心跳信息，其实说白了就是，两个相互之间可以通信的程序。我们称之为运行在多个节点上的公共层次。这个层我们称为messages layer集群事务信息层。它负责心跳信息的传输和资源的转移，以及集群事务消息传递。比如多节点的集群中，活动主机挂了，由谁上呢？这些协调的信息就由此层传递。补刀操作也是由messages layer完成的。
还有，比如说多个节点中，哪个节点作为运行服务的节点，活动主机上怎么知道自身服务不可用，还得将服务重启，一旦重启不成功后还得将资源转移至备用主机的呢？是什么在其中调节呢？ 这些都是资源自行进行的。我们必需要有种机制，让资源(应用程序)自行判断适合运行于哪台主机之上。资源如何知道有多少台主机？每台主机的性能如何呢？这就需要此应用程序在研发时，调用messages layer提供的API。
messages layer在各节点中都安装了一个应用程序，这些程序之间能够互相传递心跳。多台节点之间如何传递心跳？通过一个专门的网络基于多播来实现。之所以不是单播，因为节点过多的话，会浪费时间。在同一个多播域内的所有主机都能收到。之所以不是广播，是因为多播的范围只是在一个多播域，而广播是在全部范围内。
资源就必须能够调用每一个节点上的，应用程序探测到的各主机的硬件信息。才能做出资源转移决策。但如果此资源在开发时，没有调用此API，那就无法实现这种功能。这样高可用就太受限制了。因此，就有人提供了一个公共层次，帮助资源进行调用。这个层次称为CRM(集群资源管理器)。
CRM在启动后，根据管理员给出的配置，将资源运行在指定的节点上，不仅如此，它还能帮我们监控资源。当此资源在某个节点上时，CRM会不断探测此资源是否可用，比如两秒探测一次，多次探测失败后，CRM会将资源转移至其他节点。从而使得这些不具备高可用能力的服务，在高可用集群中运行。
CRM负责在每个节点上生成CIB，使得每个节点都能了解整个集群的配置状态。其中DC负责维护主CIB文档，任何的客户端工具完成的修改会最先到达DC，由crm中的policy engine进行决策，写入进CIB，最后同步给其他节点的CIB。任何cib的读写操作都应该在DC上进行，因为其他节点的CIB不会同步。
由此资源类型分为两种：
HA-aware：资源自身可直接调用HA集群底层的HA功能。
非HA-aware：必须借助于CRM完成在HA集群上实现HA功能。
我们需要在CRM的接口上配置三个方面的需求，也就是定义资源的约束关系：
1、资源更倾向于运行在哪个节点上。
2、资源更倾向于和哪个资源运行在一起。一个资源不能称之为服务，服务是由多个资源所构成。比如web服务需要IP资源，页面资源。因此，必须要让这些能够组合成为一个服务的资源在一起。
3、需要配置构成同一个服务的多个资源的先后关系。比如web服务，需要先配置ip，再启动服务。
location：位置约束，定义资源对节点的倾向性。用数值-∞和∞来表示，-∞表示厌恶，∞表示喜欢。如果对一个节点的倾向性为负值的话，此资源无论如何是不会运行在此节点上的。而如果想要资源在A节点挂了以后会运行在B节点上，需要定义两个位置约束，两个都为正值，只要让A的值大于B的值就行。
colocation：排列约束，定义资源彼此间“在一起”倾向性。-∞, +∞。不光可以使用排列约束，还可以使用分组的机制，将多个资源定义为一个组。
order：顺序约束，定义资源在同一个节点上启动时的先后顺序。
根据工作模式的不同，资源有着诸多类型：
primitive：基本资源，只能运行于集群内的某单个节点，只能启动一份(也称作native)。
group：组资源，容器，包含一个或多个资源，这些资源可通过“组”这个资源统一进行调度。
clone：克隆资源，可以在同一个集群内的多个节点运行都运行一份。没有基本资源，就不可能有克隆资源。
master/slave：主从资源，在同一个集群内部于两个节点运行两份资源，其中一个主，一个为从。主从也属于克隆资源，同样依赖于基本资源。
补刀机制在高可用集群被称为资源隔离，资源隔离是有级别的。
节点级别：STONITH(Shooting The Other Node In The Head)机制。如果在一个节点上，一个资源启动不起来了。虽然此节点心跳OK，但还是会将此资源进行转移，为了防止此节点将资源夺回，需要将节点干掉，也称为power switch。
资源级别：fencing。将资源本身隔离，不让节点访问就行，而不需要将节点干掉。也称为FC SAN switch。
不同类型的资源的启动、关闭、监控方式各有不同。但是一个高可用集群中用到的资源非常多，而每个资源的启动各不相同，这使得配置一个服务很困难。因为我们需要向CRM配置各种资源的启动、关闭、和监控方式。为了避免这一情况，我们需要在CRM之上再加一个LRM(本地资源管理器)层。同样需要运行在每个节点上。
LRM负责接收CRM发来的指令，用于实现在当前节点上完成资源管理。但操作是通过RA是完成的。
LRM依然不能直接做出一个资源该如何启动和关闭，而是借助于资源代理来实现。在每一个节点上都有众多的叫做RA(资源代理)的东西。RA是什么呢？是帮助我们启动、关闭、和监控资源的脚本。
1、heartbeat，到今天为止有v1, v2, v3三个版本。v1可以完整的提供一个高可用集群；v2资源管理器已经有独立出的意思了；而v3则分裂为3个项目。
2、corosync，openais组织所开发，仅提供Messaging Layer的功能，因此无法独立工作。现今最为流行。
3、cman，红帽，自成一家，RHCS。
4、keepalived，完全不同上述三种，之所以放在一起，是因为它也实现了Messaging Layer的功能。
三者同源，遵循OpenAIS。
1、heartbeat v1：提供了一个简单的haresources(高可用资源管理器)，配置接口为配置文件，文件名为haresources。
2、heartbeat v2：crm独立出来，工作特性为，在各节点运行一个crmd进程，通过Messaging Layer完成各节点进程间的衔接。配置接口为命令行客户端程序crmsh，以及GUI客户端的hb_gui。
3、heartbeat v3：v2版的crm单独运作成了pacemaker这个项目，它的全称为心脏起搏器。pacemaker可以以插件或独立方式运行，与corosync结合方式便是插件式。配置接口的CLI接口有crmsh, pcs，以及GUI接口的hawk(webgui), LCMC, pacemaker-mgmt。
4、rgmanager，资源组管理器。配置接口的CLI接口有clustat, cman_tool，以及GUI接口的Conga，红帽开发，它有luci, ricci两个组件。
组合方式：
heartbeat v1
heartbeat v2
heartbeat v3 + pacemaker
corosync + pacemaker
cman + rgmanager (RHCS)
cman + pacemaker
Local Resource Manager，由CRM通过子程序提供，不用单独安装。
各种脚本，资源代理的类型：
1、heartbeat legacy：heartbeat v1提供，heartbeat传统类型的RA，通常位于/etc/ha.d/haresources.d/目录下。
2、LSB：Linux Standard Base(linux标准库)，/etc/rc.d/init.d目录下的脚本，至少接受4个参数：{start|stop|restart|status}。
3、OCF：Open Cluster Framework(开放集群框架)，定义了多种子类别，称为provider。OCF脚本能够实现比LSB更为强大的监控功能，如果知道OCF格式的脚本如何使用，OCF将是首选。
4、STONITH：爆头，专用于实现调用STONITH设备功能的资源，通常为clone类型。
由于网络的拥塞，可能会导致活动主机的心跳信息无法传递到其他节点上。为了避免此种情况的发生，可以在每个节点上都增加一块网卡，使用这一新网卡，通过网线专门传递心跳信息。也有通过serail cable串行线缆进行传递的，但作用范围有限，不建议使用。
而基于网线传递心跳的有三种方法：
UDP Unicast：UDP单播，两节点时使用。
UDP Multicast：UDP的组播，多节点时使用。
UDP Broadcast：UDP的广播，作用范围太广，不理想。
组播通过组播地址实现，是要在多个节点上都要配置的一个相同的地址，组播地址都相同就相当于处在同一个组播域。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, 仅在特定本地范围内有效。
linux主机需要启动组播功能才能使用组播地址。
资源有三个：ip, httpd, filesystem。文件系统为共享存储，并且此文件系统不能够被多个节点同时访问。而且需要使用“组”资源，或通过排列约束让资源运行于同一节点；同时还要对它们做顺序约束，IP地址应该最先启动。
程序选型：
heartbeat v2 + haresources
配置HA集群的前提：
1、节点间时间必须同步：使用ntp协议实现。
2、节点间需要通过主机名互相通信，必须解析主机至IP地址。
(1) 建议名称解析功能使用hosts文件来实现，因为DNS不仅慢，而且一旦DNS产生故障，集群也就完了。
(2) 通信中使用的名字与节点名字必须保持一致：“uname -n”命令，或“hostname”展示出的名字保持一致。
3、考虑仲裁设备是否会用到。
4、建立各节点之间的root用户能够基于密钥认证。
定义成为集群服务中的资源，一定不能开机自动启动，因为它们将由crm管理。
此处并不提供filesystem，因为需要两个不同的页面来以示区别。因此只配置两个资源：
fip：floating ip，172.16.45.11，此IP为流动IP，一定不能固定配置。
daemon：httpd
配置文件：
/etc/ha.d目录下：
ha.cf：主配置文件，定义各节点上的heartbeat HA集群的基本属性。
authkeys：集群内节点间彼此传递消息时使用加密算法及密钥。为了保证安全，节点的每个信息在传递之前都是要做签名的，能够允许对方做完整性校验。这是一个域共享密钥，使用的是单项加密。此文件权限必须为600或400.
haresources：为heartbeat v1提供资源管理器配置接口，v1版本专用的配置接口，只有使用V1版的资源管理器才会用到此文件。
1、定义周期性同步时间
[root@web1 ~]# crontab -e */3 * * * * /usr/sbin/ntpdate 172.16.0.1 &> /dev/null [root@web1 ~]# date; ssh 172.16.45.2 "date" # 验证时间是否一致 Fri May 29 19:48:06 CST 2015 Fri May 29 19:48:06 CST 2015
2、定义两台主机之间使用密钥连接
[root@web1 ~]# ssh-keygen -t rsa -b 1024 -P ‘‘ [root@web1 .ssh]# ssh-copy-id -i ~/.ssh/id_rsa.pub root@172.16.45.2
3、保证2台主机间可以通过主机名通信，以上所有步骤两个主机都要进行。
[root@web1 ~]# vim /etc/hosts 172.16.45.1 web1 172.16.45.2 web2
4、使用自制的rpm包安装heartbeat，两台机器同时进行
[root@web1 heartbeat2]# yum install net-snmp-libs libnet PyXML # 先解决依赖关系 [root@web1 heartbeat2]# yum install libtool-ltdl [root@web1 heartbeat2]# rpm -ivh heartbeat-2.1.4-12.el6.x86_64.rpm heartbeat-pils-2.1.4-12.el6.x86_64.rpm heartbeat-stonith-2.1.4-12.el6.x86_64.rpm
5、查看配置文件
[root@web2 heartbeat2]# cd /etc/ha.d [root@web2 ha.d]# ll # 这些文件都用不着 total 24 -rwxr-xr-x 1 root root 745 Sep 10 2013 harc drwxr-xr-x 2 root root 4096 May 29 20:20 rc.d -rw-r--r-- 1 root root 692 Sep 10 2013 README.config drwxr-xr-x 2 root root 4096 May 29 20:20 resource.d # 为lsb提供补充的代理脚本 -rw-r--r-- 1 root root 7864 Sep 10 2013 shellfuncs
6、复制配置文件的模板
[root@web2 ha.d]# cp /usr/share/doc/heartbeat-2.1.4/{ha.cf,haresources,authkeys} /etc/ha.d/
[root@web2 ha.d]# chmod 600 authkeys # 此文件的权限不改，节点将无法启动7、配置authkeys文件，使用的算法和密钥。
[root@web2 ha.d]# openssl rand -base64 16 # 生成随机的密码，此密码无需管理 [root@web2 ha.d]# vim authkeys auth 2 #1 crc # 循环冗余校验码，已经不安全了 2 sha1 Jzxb5Glvt+Ca7piBIGotbA #3 md5 Hello!
8、编辑ha.cf主配置文件
[root@web2 ha.d]# vim ha.cf logfile /var/log/ha-log # 日志 #logfacility local0 # 和上面二选一 #keepalive 2 # 默认两秒发送一次心跳信息，不启用表示使用默认 #deadtime 30 # 30秒没探测到心跳，就认为挂了 #warntime 10 # 多长时间警告心跳延迟，此值范围在上面两个之间 #initdead 120 # 第一次启动时第一个启动的节点和最后一个启动的节点中间的隔得时间可能比较长，在120秒内没收到心跳信息都不算挂了。 #udpport 694 mcast eth0 225.12.45.1 694 1 0 # 因为多播不允许发送出去后又绕回来，也不允许报文经过路由器，因此定义报文的TTL为1。0表示不允许回环。这里使用的是组播，不用广播和单播。 auto_failback on # 重新上线后，会将资源抢回来运行 node web1 # 定义节点 node web2 ping 172.16.0.1 # 定义仲裁 #ping_group group1 10.10.10.254 10.10.10.253 # 如果觉得一个仲裁不够保险 compression bz2 # 节点间传递的信息压缩 compression_threshold 2 # 低于2KB不压缩
9、组播相关
[root@web2 ~]# ifconfig|grep MULTICAST # 确认网卡支持组播 [root@web2 ~]# ip link set eth1 multicast on # 启动网卡的组播功能 [root@web2 ~]# ip link show # 查看
10、配置haresources
[root@web2 ha.d]# vim haresources web1 172.16.45.11/16/eth0/172.16.255.255 httpd # 主节点web1，在eth0上配置流动IP(资源1)，httpd(资源2)不用指定路径，会自动在脚本目录下查找。这就表示了两个资源必须运行在一起，并且倾向于web1.
11、同步配置文件
[root@web2 ha.d]# scp -p authkeys ha.cf haresources web1:/etc/ha.d/ # 保持文件属性
12、安装httpd
[root@web2 ha.d]# yum install -y httpd [root@web2 ha.d]# vim /var/www/html/index.html web2 # web1为web1，以示区别 [root@web2 ha.d]# curl 172.16.45.2 # 确保没有问题 [root@web2 ha.d]# service httpd stop # 关闭服务 [root@web2 ha.d]# chkconfig httpd off # 一定不能开机启动，由资源管理器负责管理
13、启动服务，两台主机同时启动
[root@web1 ~]# /etc/init.d/heartbeat start; ssh web2 "/etc/init.d/heartbeat start" [root@web1 ~]# ifconfig # 可以看到相关信息 eth0:0 Link encap:Ethernet HWaddr 08:00:27:7F:3B:FF inet addr:172.16.45.11 Bcast:172.16.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
14、浏览器访问：
15、模拟web1故障
[root@web1 ~]# /etc/init.d/heartbeat stop
16、刷新浏览器
17、重新上线会将资源重新要回
如果没有定义网卡，而是只定义IP，haresources会通过/usr/lib64/heartbeat/findif此脚本，查找和流动IP在同一网段的网卡，并将流动IP配置在此网卡的别名上。
1、A/P：两节点集群，资源运行于active活动主机上。passive，除了备用之外没有丝毫作用。HA Service通常只有一个，HA resources可能会有多个。
2、A/A：两节点集群，两节点都工作于活动状态，那谁是备用？互相备份。他们的工作方式是这样的：两个节点同时运行两个高可用服务，A节点运行web高可用，B节点运行邮件高可用。一旦B出现故障，A节点就会同时运行web和邮件服务。一般来讲，只允许运行两种不同服务，因为端口只有一个。但通过精巧的设计，可以运行两个相同的服务。比如两个web服务都相同，只要在B节点出现故障后，转移ip即可。通过DNS的两条A记录分别解析两个IP地址。通过再次的精巧设计，还能让两个节点同时使用一个IP地址，它们之间不会冲突，并且通过地址哈希，将用户请求分发到两个节点上。
3、N-M：N个节点，M个服务，通常N>M。比如5节点集群，一台运行web服务、一台运行ftp、一台运行邮件、一台Samba、最后一台备用。这样资源浪费就少多了。
4、N-N：N个节点，N个服务。一旦节点重新上线后，就需要将资源要回来。不然其他节点的压力就太大了。
一旦集群发生分裂，处于without quorum状态的主机资源会转移，但内存中的数据势必会丢失。我们有多种手段可以应对这样的情况：
1、stop，让without quorum状态的节点停止，资源不再启动，也不做资源转移。
2、ignore，即便不具有quorum，我也照样跑。但是这样会产生资源争用，默认为stop。
3、freeze，冻结，此前分配到此节点的用户照样运行，直到退出为止。不再接受新连接。
4、suicide，自杀。
1、rgmanager是通过failover domain(故障转移域)来实现的，并且在故障转移域内定义节点的node priority。什么意思呢？我们在定义任何一个资源时，都要定义好它的故障转移域有哪些节点。比如我们想一个5节点集群中添加一个资源httpd，并且限制此资源只能运行在ABC三个节点上，有个三个节点构成的范围，就称为故障转移域。但是此资源默认运行在哪个节点上呢？我们通过此资源对3个节点的优先级，就是所谓的node priority进行定义。
2、pacemaker则是通过资源约束实现的。再说资源约束之前，还要说下资源黏性，资源黏性是指运行于当前节点的倾向性。集群中新加入了一个节点，资源会不会转移至此节点，取决于两个方面。一是当前节点的黏性；二是对目标节点的约束的倾向性。
(1) 位置约束：资源对运行于某节点的倾向性。假如ip和httpd两个资源是必须在一起的，但是ip对新节点的倾向性是正无穷，而httpd则是负无穷，那web服务是否会转移至新节点呢？这需要做加法运算。一般来讲，讨厌大于喜欢，负无穷+正无穷=负无穷。如果对一个节点的倾向性为负值的话，此资源无论如何是不会运行在此节点上的。而如果想要资源在A节点挂了以后会运行在B节点上，需要定义两个位置约束，两个都为正值，只要让A的值大于B的值就行。
inf：正无穷
-inf：负无穷
n：正值
-n：负值
(2) 排列约束：资源运行于一处的倾向性，表示是否在一起。同样需要做运算。
inf，-inf，n，-n
(3) 顺序约束：启动的先后顺序。如果A启动不了，B是一定无法启动的。同样的，C无法关闭，B就一定不能关闭。
A --> B --> C：启动顺序
C --> B --> A：关闭顺序
如果没定义倾向性，资源转移时，随机选择节点。如果没有定义排列约束，为了充分发挥每个节点的性能，资源默认分散于多节点运行。
对于pacemaker而言，集群工作还有对称和非对称两种模式。非对称是指，集群资源默认可以运行在任何一个节点上。也就是说一个节点发生故障，上面的资源可以转移至任意一个节点上运行，如果定义了约束，就按约束来。对称则相反，资源默认不能运行在任何一个节点上。只有明确定义资源运行于某节点后，才能运行。因此，非对称可以称为黑名单，对称可以称为白名单。
对于一个集群而言，它的工作默认有去中心化和有中心节点两种模式。高可用就属于有中心节点。也就意味着，必须在众多的节点中，推选出一个节点，负责主事。DC负责管理整个集群的状态，并做出决策。
Designated Coordinator，指派的协调员。DC不是固定的，是系统启动后，由系统选举产生。DC负责计算一个资源对节点的倾向性，通知对应节点上的LRM，LRM指挥RA对此资源进行相应的操作等等等等的工作。
当用户的请求到来后，肯定是由路由器进行ARP地址解析，解析的网卡的MAC地址会缓存下来。但是此节点出故障后IP转移了，当用户再次请求时，路由器根据arp缓存就会将用户的请求发送到已经不工作的节点上了。这显然不符合我们的期望，因此，当地址转移到新节点以后，此节点必须立即发送arp广播请求，以通知前端路由器。怎么通知？广播“fip对应的MAC地址谁有？发给我！“，自问自答。因为这是广播，所以路由器虽然不会响应，但是会根据广播的内容更新自己的缓存。
对资源的管理必须通过资源代理来实现，filesystem是个资源代理、httpd也是资源代理、172.16.45.11/16/eth0/172.16.255.255这不是资源代理，但是不要紧，haresources会发现此配置是一个ip，它会通过/etc/ha.d/resource.d/IPaddr或者IPaddr2脚本进行管理。使用IPaddr2配置的话，地址是无法用ifconfig进行查看的，只能使用ip addr show。
非LSB的脚本，有些是可以接受参数的，而每一个参数的配置，要使用::双冒号指定，之所以使用双冒号是因为有的参数会用到冒号。比如：
Filesystem::/dev/sda1::/data1::ext2：向filesystem传递3个参数。挂载设备、挂载点、文件系统。
两测试脚本：/usr/lib64/heartbeat/{hb_standby,hb_takeover}，当然此目录下还有很多有用的脚本。
hb_standby：强制变为备用节点
hb_takeover：强制抢回资源
一旦启用共享存储，此共享存储就会成为单点，所以，能不用就不用。用也是用分布式文件系统。
停止一个高可用服务是很慢的，特别是在多节点的集群。每停一个，其他节点就会抢资源。最后可能由于资源无法转出而超时。
如果无法停止高可用服务，需要强行kill掉，但是这样会造成文件的不一致，需要清理状态数据，据说很麻烦。
案例1的后续，提供一个共享存储。3台主机，web3作为NFS服务器。
开始：
1、输出共享目录，NFS可以开机启动
[root@web3 ~]# mkdir -pv /web/htdocs [root@web3 ~]# vim /web/htdocs/index.html Page On NFS Server [root@web3 ~]# vim /etc/exports /web/htdocs 172.16.0.0/16(rw,no_root_squash) # 不挤压root权限 [root@web3 ~]# /etc/rc.d/init.d/rpcbind start [root@web3 ~]# /etc/rc.d/init.d/rpcidmapd start [root@web3 ~]# /etc/rc.d/init.d/nfs start
2、挂载共享存储并测试，两台主机都测试
[root@web1 ~]# /etc/init.d/heartbeat stop; ssh web2 "/etc/init.d/heartbeat stop" [root@web1 ~]# mount -t nfs 172.16.45.3:/web/htdocs /var/www/html/ # 使用浏览器测试 [root@web1 ~]# /etc/init.d/httpd stop # 不能手动启动 [root@web1 ~]# umount /var/www/html/ # 挂载会自动完成
3、配置资源
[root@web1 ~]# file /etc/ha.d/resource.d/Filesystem # 此脚本就是文件系统资源代理，可接受三个参数 /etc/ha.d/resource.d/Filesystem: POSIX shell script text executable [root@web1 ~]# cd /etc/ha.d [root@web1 ha.d]# vim haresources web1 172.16.45.11/16/eth0/172.16.255.255 Filesystem::172.16.45.3:/web/htdocs::/var/www/html::nfs httpd # 定义了3个资源，以及资源的位置约束、排列约束、顺序约束。
4、同步配置文件，可以使用/usr/lib64/heartbeat/ha_propagate此脚本
[root@web1 ha.d]# scp -p haresources web2:/etc/ha.d/
5、启动服务
[root@web1 ha.d]# /etc/init.d/heartbeat start; ssh web2 ‘/etc/init.d/heartbeat start‘ logd is already running Starting High-Availability services: 2015/05/30_15:03:18 INFO: Running OK 2015/05/30_15:03:18 CRITICAL: Resource 172.16.45.11/16/eth0/172.16.255.255 is active, and should not be! 2015/05/30_15:03:18 CRITICAL: Non-idle resources can affect data integrity! 2015/05/30_15:03:18 info: If you don‘t know what this means, then get help! 2015/05/30_15:03:18 info: Read the docs and/or source to /usr/share/heartbeat/ResourceManager for more details. CRITICAL: Resource 172.16.45.11/16/eth0/172.16.255.255 is active, and should not be! CRITICAL: Non-idle resources can affect data integrity! info: If you don‘t know what this means, then get help! info: Read the docs and/or the source to /usr/share/heartbeat/ResourceManager for more details. 2015/05/30_15:03:18 CRITICAL: Non-idle resources will affect resource takeback! 2015/05/30_15:03:18 CRITICAL: Non-idle resources may affect data integrity! Done. Starting High-Availability services: 2015/05/30_15:03:18 INFO: Resource is stopped Done. # 这里报错，啥都没启动 [root@web1 ha.d]# killall heartbeat # 两个节点都停掉 [root@web2 ~]# /etc/init.d/heartbeat start # 先启动第二个节点，再启动第一个节点，就OK了 [root@web1 ha.d]# mount 172.16.45.3:/web/htdocs on /var/www/html type nfs (rw,vers=4,addr=172.16.45.3,clientaddr=172.16.45.1) # 挂载成功
6、浏览器访问
7、测试
[root@web1 ha.d]# /usr/lib64/heartbeat/hb_standby # 模拟服务不可用
资源管理器已不再是1版中的haresources，而是crm。每个节点中，在heartbeat的底层之上，CRM运行为一个守护进程，监听在某个套接字上，彼此之间能够相互通信。能够借助底层heartbeat传递而来的事务信息，作为自己做出决策的依据。并且在它之上的LRM也运行为单独的守护进程，受CRM的管理。通过DC负责管理整个集群的状态，并做出决策，并通过messages layer通知LRM采取动作。
由于crm自身监听在5560端口上，所以它支持本地或远程的连接
所有的配置的信息会先在DC上实现，DC配置完成后，自动同步给其他节点，
1、要想在heartbeat上使用crm很简单，先停止heartbeat服务，然后在heartbeat的主配置文件中的任意位置，增加一行crm on：
[root@web1 ~]# vim /etc/ha.d/ha.cf crm on
2、启动服务，一旦启用crm，默认会禁用v1 haresources资源管理器。
[root@web1 heartbeat2]# rpm -ivh heartbeat-gui-2.1.4-12.el6.x86_64.rpm # 先安装图形配置接口
[root@web1 ~]# /etc/init.d/heartbeat start; ssh web2 ‘/etc/init.d/heartbeat start‘
[root@web1 ~]# ss –tnlp # crm监听的端口
LISTEN 0 10 *:5560 *:* users:(("mgmtd",8979,10))3、crm监控命令
[root@web1 ~]# crm_mon # 每隔15S刷新一次集群的信息 Refresh in 9s... ============ Last updated: Sat May 30 16:07:37 2015 Current DC: web2 (0b189e90-d638-4eff-ad54-0e41fd8ce31b) # 当前DC的节点 2 Nodes configured. # 2个节点 0 Resources configured. # 没有配置资源 ============ Node: web2 (0b189e90-d638-4eff-ad54-0e41fd8ce31b): online # 两节点都在线 Node: web1 (4e01d5c7-ab29-4b94-968f-8790c7bf6988): online
4、使用命令行配置工具配置起来极为不便，因此使用图形界面。查看生成的文件，此程序是由python语言所开发，并且有用的只有第一个，其余的都是模板。
[root@web1 ~]# rpm -ql heartbeat-gui /usr/bin/hb_gui /usr/lib64/heartbeat-gui /usr/lib64/heartbeat-gui/_pymgmt.so /usr/lib64/heartbeat-gui/_pymgmt.so.0 /usr/lib64/heartbeat-gui/_pymgmt.so.0.0.0 /usr/lib64/heartbeat-gui/haclient.py /usr/lib64/heartbeat-gui/pymgmt.py /usr/lib64/heartbeat-gui/pymgmt.pyc /usr/lib64/heartbeat-gui/pymgmt.pyo /usr/share/heartbeat-gui /usr/share/heartbeat-gui/active-node.png /usr/share/heartbeat-gui/add-resource.png /usr/share/heartbeat-gui/cleanup-resource.png /usr/share/heartbeat-gui/default-resource.png /usr/share/heartbeat-gui/down-resource.png /usr/share/heartbeat-gui/exit.png /usr/share/heartbeat-gui/ha.png /usr/share/heartbeat-gui/haclient.glade /usr/share/heartbeat-gui/haclient.py /usr/share/heartbeat-gui/haclient.pyc /usr/share/heartbeat-gui/haclient.pyo /usr/share/heartbeat-gui/login.png /usr/share/heartbeat-gui/logout.png /usr/share/heartbeat-gui/master-resource.png /usr/share/heartbeat-gui/mgmtcmd.py /usr/share/heartbeat-gui/mgmtcmd.pyc /usr/share/heartbeat-gui/mgmtcmd.pyo /usr/share/heartbeat-gui/remove-resource.png /usr/share/heartbeat-gui/slave-resource.png /usr/share/heartbeat-gui/standby-node.png /usr/share/heartbeat-gui/start-resource.png /usr/share/heartbeat-gui/stop-resource.png /usr/share/heartbeat-gui/up-resource.png
建立一个web服务的高可用。
1、此图形界面在使用时需要登录，用户已生成，我们需要添加密码。在哪个节点上使用此工具，就需要添加密码
[root@web1 ~]# tail /etc/passwd hacluster:x:498:499:heartbeat user:/var/lib/heartbeat/cores/hacluster:/sbin/nologin # 就是此用户 [root@web1 ~]# echo 123456|passwd --stdin hacluster
2、启动，登陆后，稍等一段时间
[root@web1 ~]# hb_gui &
2、添加资源：Resource上右键 --> 选择增加 --> native，下面三个是定义约束的
(1) 接下来添加webserver资源，代理就选择lsb的httpd，大多数的lsb脚本无法添加参数。此时应该保证两个节点上都有web应用，并且不能开机启动。但是此资源启动后，运行在web1上，因为默认是分散运行的。但这不是我们想要的，因此，需要组或者定义约束。
# 添加组资源，这里默认就有两个约束，但是无法将定义好的资源加入组中。因此，使用排列约束。
3、添加排列约束：Colocations邮件 --> 添加，但是添加完成后，启动次序没有先后之分，显然不符合我们的要求
4、定义顺序约束：Orders右键 --> 添加，但是添加完成后，由于web2是DC，资源优先运行于web2，但可以通过位置约束进行修改。
5、定义位置约束，毕竟ip先启动。
1、构建mysql高可用，就势必要提供一个共享存储，除非此mysql是只读的。这里就简单的使用NFS，也不考虑其他问题了。
2、由于mysqld这个进程是mysql用户mysql组运行的，因此，mysql用户必须对NFS有读写权限。而且两个节点的mysql用户的UID和GID必须保持一致。
3、安装时，第一个节点完成数据库初始化后，第二个节点就不需要了。
4、为了不受干扰，将上面的约束先删除，再删资源。
需要的资源：
ip, mysqld, shared storage
开始：
1、导出共享目录
[root@web3 ~]# mkdir /data/mydata -pv [root@web3 ~]# groupadd -r -g 306 mysql [root@web3 ~]# useradd -r -g 306 -u 306 mysql [root@web3 ~]# vim /etc/exports /data 172.16.0.0/16(rw,no_root_squash) # 需要root用户初始化数据库 [root@web3 ~]# chown -R mysql.mysql /data/mydata/ # 改为mysql用户，mysql组 [root@web3 ~]# exportfs –ar
2、测试挂载nfs
[root@web1 ~]# mkdir /data [root@web1 ~]# mount -t nfs 172.16.45.3:/data /data [root@web1 ~]# groupadd -r -g 306 mysql [root@web1 ~]# useradd -r -g 306 -u 306 mysql [root@web1 ~]# su - mysql [mysql@web1 root]$ cd /data/mydata/ [mysql@web1 mydata]$ touch 1 # 验证mysql用户是否可写 [root@web1 ~]# touch /data/mydata/3 # 验证root用户是否可写
3、安装mariadb，安装完成后，禁止开机启动
[root@web1 mysql]# chkconfig mysqld off
4、卸载nfs
[root@web1 ~]# umount /data/
5、在nfs服务器上安装mysql客户端用于测试
[root@web3 mydata]# yum install -y mysql
6、这次直接定义组进行排列约束，定义在组内的次序就是资源的启动次序
数据库资源在转移时，连接到mysql上的连接不会断开。
CIB：Cluster Information Base，位于内存中的，里面保存了集群配置的各个条目的相关信息。其中包括集群的状态、节点成员关系、定义的每一个资源、以及资源间的约束关系等等。对应的文件为cib.xml，此文件就是hb_gui命令的配置文件。
为什么配置文件是XML格式的？heartbeat V2版的crm会在各节点上都运行一个crmd的进程，各节点的crdm可以相互通信。为了使配置后的资源信息得以保存，使得下次开机依然有效，需要在各节点间实现数据交换。而为了让各节点理解交换而来的数据的意义，使用半结构化的数据可能能够更加清晰的描述配置文件的意义
相对于heartbeat而言，XML配置文件所在为/var/lib/heartbeat/cib/目录下。
Policy Engine和Transition Engine，这两个组件只有DC才会拥有。PE用于整个集群的集群级事务决策，比如活动节点挂了，下一步需要做什么，都是由PE根据配置信息进行计算，然后由TE执行，TE将PE生成的策略下达给每个节点的crm，由crm同时通知给LRM，LRM自身却不会直接执行，而是调用RA执行。
1、Messaging and Infrastructure Layer：又称为Heartbeat Layer，和原来一样。
2、Membership Layer：集群成员核心层，核心功能为CCM，可以理解为投票系统。
3、Resource Allocation Layer：资源分配层，核心组件CRM。其中DC节点有此LRM, PE, TE, CIB四个组件，其他节点无PE和TE。
4、Resource Layer资源层，主要就是RA
NFS是文件级别的共享，而不是块设备级别的，因此无法对其进行格式化。
NAS：Network Attached Storage，文件级别输出，文件格式的输出特点是：多台主机同时挂载共享存储，当其中一台主机对一个文件进行写入时，此共享存储会自动为此文件加锁，这样一来，其他主机就无法对此文件进行读写操作了。
SAN：Storage Area Network，块级别，输出特点是：当其中一台主机使用时，它必须把自己在块级别上所使用各种数据以块的形式缓存在自己的内存中，这是linux的特性。因此所有的操作都在本地的内核内存中完成，因为在它看来，这就是一块磁盘，完全不知道其他主机的存在。这样一来，写锁只能对当前主机生效，而对其他主机无法生效。后果是都写完后一合并，文件系统崩溃。因此，此共享存储不能多主机同时挂载。
SAN的性能好于NAS，但SAN代价高。因为SAN为了保证输出传输的速度，使用的是光纤。
但是当使用双主互备模型的话，就必须多节点同时挂载，这就需要使用集群文件系统。假如是两个节点的双主模型，在这两个节点的CRM层之上，加一层DLM(分布式锁管理器)。这样一来，当A节点对共享存储的文件进行写入时，施加在其上的锁就会通过底层Messages Layer层传递到B节点之上。但是对此文件系统是有要求的，比如这个锁允许以集群的方式进行工作，能够支持分布式锁管理器来实现分布式锁的功能。而此文件系统的格式就应该是特定的格式，比如GFS2或者OCFS2。
clvm2：红帽系统的专用集群逻辑卷。
集群文件系统用的少，因为它前端支持的节点数量有限，10个就已经极限了。
标签：ha linux
原文地址：http://10042224.blog.51cto.com/10032224/1658028
