What is the Linux High Availabi

What is the Linux High Availabi前端

   简介:node

    高可用性群集的出现是为了使群集的总体服务尽量可用,以便考虑计算硬件和软件的易错性。若是高可用性群集中的主节点发生了故障,那么这段时间内将由次节 点代替它。次节点一般是主节点的镜像,因此当它代替主节点时,它能够彻底接管其身份,而且所以使系统环境对于用户是一致的。linux

wKiom1NPxuqzdRgeAAHtJv7-4y8681.jpg

什么叫心跳:就是将多台服务器用网络链接起来,然后每一台服务器都不停的将本身依然在线的信息很简短很小的通告给同一个网络中的备用服务器的主机,告诉其实主机本身依然在线,其它服务器收到这个心跳信息就认为本机是在线的,尤为是主服务器。

心跳信息怎么发送,由谁来收,其实就是进程中的通讯两台主机是无法通讯的,只能利用网络功能,经过进程监听在某一套接字上,实现数据发送,数据请求,因此多台服务器就得运行同 等的进程,这两个进程不停的进行通讯,主节点(主服务器)不停的向对方同等的节点发送本身的心跳信息,那这个软件就叫高可用的集群的基准层次,也叫心跳信 息传递层以及事物信息的传递层,这是运行在集群中的各节点上的进程,这个进程是个服务软件,关机后须要将其启动起来,主机间才能够传递信息的,通常是主节 点传给备节点。在每一个节点上,CRM维护群集信息库 (CIB),包含全部群集选项、节点、资源及其关系和当前状态的定义。若是选择群集中的CRM为指定协调 程序(DC),则意味着它具备主CIB。群集中的全部其余CIB是此主CIB的 复本。对CIB的常规读写操做经过主CIB进行排序。DC是群集中惟一能够 决定须要在整个群集执行更改(例如节点屏障或资源移动)的实体。
群集信息库(CIB)
群集信息库是整个群集配置和当前状态在内存中的XML表示。它包含全部 群集选项、节点、资源、约束及其之间的关系的定义。CIB还将更新同步到 全部群集节点。群集中有一个主CIB,由DC维护。全部其余节点包含一个CIB副本.web

 

策略引擎(PE)算法

每当指定协调程序需呀进行整个鮮集的更改(对新CIB作出反应),策略引擎就会根据群集的当前状态和配置计算集群的下一个状态,PE还生成个转換图,包含用于达到下一个群集状态的(资源)操做和依赖性的列表,PE在每一个节点上都运行以加速DC故障转移。shell

 

本地资源管理器(LRM)vim

LRM 表明CRM调用本地资源代理.所以它能够执行启动/中止/监视操做并将结果报告给CRM。它还隐藏资源代理支持的脚本标准(OCF、LSB、Heartbeat VI)之间的区别。LRM是其本地节点上全部资源相关信息的权威来源.api

 

资源层安全

最高层是资源层。资源层包括一个或多个资源代理(RA)。资源代理是为启动、 中止和监视某种服务(资源) 而编写的程序,一般是服务控制脚本。资源代理仅由LRM调用。第三方可将他们本身的代理放在文件系统中定义的位皆,这样就为各自的软件提供了现成群集集成.所谓的资源:以web为例,vip是资源,web服务也是资源,还有网页面也是资源,一个服务包括多个资源,而像web的共享存储也是资源等等,不一样的服务所须要的资源也是不一样的,而共享存储是高可用集群中最难解决的问题。如是主节点挂了,多个备节点怎么样来选择一个备节点来作为提供服务的一个节点呢,而这种应该选择哪一个备用节点来作为提供服务的机制就叫作集群事物决策的过程ha_aware:若是一个应用程序本身可以利用底层心跳信息传递层的功能完成集群事物决策的过程的软件就叫ha_aware。   DC:Designated Coordinator选定的协调员,当DC所在的主机挂了就会先选出一个DC,再由DC作出事物的决策。注意:在高可用集群中最核心的、最底层的管理的单位叫资源,把资源组合在一块儿来组合成一个服务。高可用集群中任何资源都不该该自行启动,而是由CRM管理启动启动的;CRM:Cluster Resources Manager集群资源管理,真正作出决策的是CRM。bash

heartbeat v1版时就有了资源管理的概念,而v1版的资源就是heartbeat自带的,叫haresources,这个文件是个配置文件;而这个配置文件接口就叫haresources;

heartbeat v2第二版的时候,heartbeat被作了很大的改进,本身能够作为一个独立进程来运行,并而能够经过它接收用户请求,它就叫crm,在运行时它须要在各节点上运行 一个叫crmd的进程,这个进程一般要监听在一个套接字上,端口就是5560,因此服务器端叫crmd,而客户端叫crm(能够称为crm shell),是个命令行接口,经过这个命令行接口就能够跟服务器端的crm通讯了,heartbeat也有它的图形化界面工具,就叫 heartbeat-GUI工具,经过这个界面就能够配置进行。

第三版heartbeat v3,被独立成三个项目heartbeat、pacemaker(心脏起博器)、cluster-glue(集群的贴合器),架构分离开来了,能够结合其它的组件工做了。

RA:resource agent资源代理,其 实就是可以接收CRM的调度用于实如今节点上对某一个资源完成管理的工具,这个管理的工具一般是脚本,因此咱们一般称为资源代理。任何资源代理都要使用同 一种风格,接收四个参数:{start|stop|restart|status},包括配置IP地址的也是。每一个种资源的代理都要完成这四个参数据的输 出。
   当某一个节点出现故障时,其上面的资源被自动转移到其它正常的备用节点上并启动的这个过程叫故障转移,也称为失效转移(failover)
   若是出现故障的节点又回来的,那咱们就要把这个节点添加回来,那这个添加回来的过程咱们就叫失效转回,也称故障转回(failback)

资源争用、资源隔离:
   万一集群发生分裂时,为了不再也不成为集群上的节点继续使用资源而发生资源争用状况,致使有挂载文件系统的系统文件发生崩溃,成为新的集群的就会给再也不成为集群的节点补一枪,让不是集群节点的服务死透,再也不接收请求,这就叫stonith(shoot the other node in the head),而这种功能就叫资源隔离。争用共享存储的后果是很是严重的,轻则共享存储崩溃,重则整个文件系统都崩溃,数据所有丢失。


资源隔离有两种级别:
   节点级别:这种就叫STONITH,这种就是无论怎么样直接把对方的电源给切断,通常这种主机都是链接到电源交换机上的。
   资源级别:这种须要依赖一些硬件设备来完成,好比链接到共享存储的光纤交换机,把须要踢除出去的节点的光纤接口屏蔽了,这种就叫资源级别的隔离。
   对于服务器左右分隔的这种状况一般称为脑裂(brain-split),左右不协调了,在高能够用集群中避免资源争用完成资源隔离是咱们在设计高可用集群中必需要考滤的问题。

   两个节点的模式下,一旦发生集群分隔之后,其中一个节点发生故障,在咱们没法断定哪一个节点不正常的时候,而正常的节点必定是能够连到互联网上去的,这样的话就说明正常的节点是能够跟前端路由通讯的,因此咱们就把前端路由当成第三个节点,这里咱们称为ping节点,当每一个节点联系到对方以后先去ping前端的节点,若是能够ping通,那就说明本身是正常的,就说明该节点是有多票法定票数的节点,而前端的ping节点就叫仲裁设备,帮助节点判断哪一个节点是优胜一方的,偶数节点数时就会借助于仲裁设备。
   RHCS不是使用ping节点来判断的,他是使用了一个共享存储的设备,偶数个节点处于活动的节点不断的往磁盘中写数据,按照心跳信息频率每隔一个信息频率就往磁盘里写一个数据位,只要这个设备每隔一个心跳时间间隔就更新一次数据位,就说明这个设备处于活动状态的,若是发现节点屡次没有写数据位了就认为节点挂了,这种也叫仲裁设备(qdisk)。仲裁设备又有两种:分别为ping node和qdisk;

那心跳是怎么传递的呢,在多台主机之机又是怎么互相工做良好呢,如图:高可用主从的两个节点;

wKiom1NXJgWSL8J2AALpfiAJ3U8039.jpg

   信息层(Messaging Layer):主从两个节点的心跳信息都要基于信息层来实现,也叫底层基础架构层,用于传递心跳信息的,而可以实现这种功能的有Corosync和heartbeat,corosync是openAIS的一个组件,
   资源分配层(Resource Allocation):也叫资源管理器层,这层的核心组件叫CRM(Cluster Resourcce Manager集群资源管理器),CRM上必须有一个资源被推举成为管理者的,叫Leader,它的工做是决策集群中的全部事物的,这里称为DC(Designated Coordinator指定协调员),任何DC上会额外运行两个进程,一个叫PE(Policy Engine策略引擎),所谓策略引擎就是将底层信息层收集整个集群中全部节点上的信息在本地生成一个大图big pic来策略节点运行在哪一个节点上,并通知其实节点上的资源管理器来实现资源的启动和关闭等操做;一个叫TE(Transition Engine 传输引擎),它主要是把PE作出的决策通告给对应节点的CRM;
   集群资源管理器必须借助于Messageing Layer通告给每个节点,自动的广播或组播给每个节点,这样就保证了每个节点上的信息都是同样的,而这些数据在计算机中又怎么样来交互数据的呢,这里就要基于扩展标记语言来实现数据的格式传递的,这种叫半结构化数据基于XML的,因此在各节点之间实现配置信息保存都是经过XML文件保存的,而要可以理解这个XML文件保存的信息使用到一个工具叫CIB(Cluster Information Base集群信息库);只要能链接到CRM上均可以去配置这个XML文件,首先它会先保存到DC的XML中,而后再由DC同步支每一个节点上的XML文件中去的;
   Resources层:而 PE(策略引擎)就是根据XML这个库来获取资源的配置信息的,并经过Messaging Layer不获取当前节点的活动信息,然后作出决策,一旦作得决策就要启动资源了;因此PE借助于本地的Messaging Layer通知给其实节点的集群信息库来实现对某些资源信息的传递,好比说通告其它CRM要启动某一资源了,收到信息后CRM并不负责启动,转由 LRM(Local Resource Manager本地资源管理)启动,每一个节点上都运行在这个LRM,而并发资源又借助于RA(Resource Agent资源代理)实现资源管理,这就是它的工做原理;CRM负责收集信息,推举为DC的由PE运行,PE负责整合整个集群中的全部资源,并确保某些资 源在合适的节点上运行起来,一旦作出决策就会通告给其它节点上的CRM,对应节点上的CRM收到通告之后会调用本身的LRM,由LRM指挥RA完成相关的操做;

处理流程:

    linux 高可用 使用 Pacemaker做为CRM, CRM做为守护程序执行(crmd),它在每一个集群节点上都有一个实例。Pacemaker 经过将某个crmd实例选为主实例,从而集中了全部的群集决策制定。若是选定的crmd进程(或它所在的节点)出现故障,则将创建一个新的进程。

在每一个节点上保留了一个CIB,它反映了群集的配置和群集中全部资源的当前状态。CIB的内容会在整个群集的同步过程当中自动保留下来。
群集中执行的许多操做都将致使整个群集的更改。这些操做包括添加或删除群集资源、更改资源约束等。了解执行这样的操做时群集中会发生的情况是很重要。
例如,假设您要添加一个群集IP地址资源。为此,您可使用一种命令行工具, 或GUI修改CIB您没必要在DC上执行此操做,可使用群集中任何节点上的任何工具,此操做会被传送到DC上。而后DC将把此CIB更改复制到全部群集节点。

根据CIB中的信息,PE便计算群集的理想状态及如何达到此状态,并将指令列表传递给DC.DC经过消息交换/基础结构层发出命令,其余节点上的crmd同 级将收到此命令《每一个lrmd使用它的LRM (做为Irmd实观)执行资源修改.lrmd不是群集感知的,它直接与资源代理(脚本)交互
全部同级节点将操做的结果报告给DC。一旦DC作出全部必需操做已在群集中成功执行的结论,群集将返回至空闲状态并等待进一步亊件。若是有操做末按计划执行,则会再次调用PE,CIB中将记录新信息。

在某系状况下,可能须要关闭节点以保护共享数据或完成资源恢复。为此,pacemaker附带了一个屏障子系统,stonithd。STONITH 是"shoot the other node in the head"(关闭其余节点)"的首字母缩写,一般经过一个远程电源开关实施。在pacemaker中将STONITH设备构形成资源(并在CIB中配置) 以便它们监视故障;然而,stonithd负责了解STONITH拓扑,这样它的客户端只需请求屏障节点,余下的工做由它来完成。

 

 

Linux High Availabi  资源类型:

original

原始资源是最基本的资源类型。

group

组包含一系列须要放置在一块儿的资源、按顺序启动和以反序中止的资源。

组具备如下属性:
启动和中止资源
资源以显示顺序启动,以相反顺序中止。
相关性
若是组中某个资源在某处没法运行,则该组中位于其以后的任何资源都不允 许运行。
组内容
组可能仅包含一些原始群集资源。要引用组资源的子代,请使用子代的ID 代替组的ID。
限制
尽管在约束中能够引用组的子代,但一般倾向于使用组的名称。
黏性
黏性在组中能够累加。每一个活动的组成员能够将其黏性值累加到组的总分 中。所以,若是默认的resource-stickiness值为100,而组中有七个 成员,其中五个成员是活动的,则组总分为500,更喜欢其当前位置。

资源监控

要为组启用资源监视,必须为组中每一个要监视的资源分配监视。

注意: 组必须包含至少一个资源,不然无效.

Web 服务器的资源组

资源组示例是须要IP地址和文件系统的Web服务器。在这种状况下,每一个组件 都是一个会合并到群集资源组中的独立群集资源。资源组在一台或多台服务器 上运行,若是软件或硬件有故障,故障转移至群集中的另外一台服务器上,这与 单个群集资源相同。

以下图所示:

wKioL1NP3ALyRnNiAADukhAQGRo449.jpg

 

clone

   克隆是能够在多个主机上处于活动状态的资源。若是各个资源代理支持,则任何资源都可克隆。(集群文件系统,文件共享服务器)

您可能但愿某些资源在群集的多个节点上同时运行。为此,必须将资源配置为 克隆资源。能够配置为克隆资源的资源示例包括STOMTH和群集文件系统(如 0CFS2)。若是受资源的资源代理支持,则能够克隆任何资源。克隆资源的配 置甚至也有不一样,具体取决于资源驻留的节点。
资源克隆有三种类型:
匿名克隆
这是最简单的克隆类型。这种克隆类型在全部位置上的运行方式都相同。因 此,每台计算机上只能有一个匿名克隆实例是活动的。
全局惟一克隆
这些资源各不相同。一个节点上运行的克隆实例与另外一个节点上运行的实例 不一样,同一个节点上运行的任何两个实例也不一样。
状态克隆
这些资源的活动实例分为两种状态:主动和被动。有时也称为主要和辅助, 或主和从。状态克隆能够是匿名克隆也能够是全局惟一克隆。

master

主资源是一种特殊的克隆资源,主资源能够具备多种模式。主资源必须只能包含一个组或一个常规资源。

master/slave

主从资源主的能读能写,从的不能读也不能写

 

Linux High Availabi   配置资源约束

配置好全部资源只是完成了该做业的一部分。即使群集熟悉全部必需资源,它 可能还没法进行正确处理。资源约束容许您指定在哪些群集节点上运行资源、 以何种顺序装载资源,以及特定资源依赖于哪些其余资源。
提供三种不一样的约束:

Resource Location (资源位置)
位置约束定义资源能够、不能够或首选在哪些节点上运行。 优先级(inf:无穷大、- inf: 负无穷大  n:指定优先级大小  -n :负优先级大小)

Resource Collocation (资源排列)
排列约束告诉群集资源能够或不能够在某个节点上一块儿运行。 inf:排列约束:资源不管如何都要在一块儿  -inf: 资源老死不相往来 (在某台服务器上)

Resource Order (资源顺序)
排序约束定义操做的顺序。 资源启动次序及关闭次序(好比 在启动web服务器的时候是先启动IP,仍是先启动web服务进程呀!)

定义约束时,还须要指定分数。各类分数是群集工做方式的重要组成部分。其 实,从迁移资源到决定在已降级群集中中止哪些资源的整个过程是经过以某种 方式操纵分数来实现的。分数按每一个资源来计算,资源分数为负的任何节点都 没法运行该资源。在计算出资源分数后,群集选择分数最高的节点。INFINITY (无穷大)目前定义为1, 000, 000。加减无穷大遵循如下3个基本规则:

◆任何值+无穷大=无穷大

◆任何值-无穷大=-无穷大

◆无穷大-无穷大=-无穷大

   定义资源约束时,也能够指定每一个约束的分数。分数表示您指派给此资源约束 的值。分数较高的约束先应用,分数较低的约束后应用。经过使用不一样的分数 为既定资源建立更多位置约束,能够指定资源要故障转移至的目标节点的顺序

 

指定资源故障回复节点(资源黏性)

当原始节点恢复联机并位于群集中时,资源可能会故障回复到该节点。若是但愿阻止资源故障回复到故障转移前运行的节点上,或若是但愿指定其余的节点让资源进行故障回复,则必须更改资源黏性值。在建立资源时或在建立资源后, 均可以指定指定资源黏性。
在指定资源黏性值时,请考虑如下状况:
值为0:
这是默认选项。资源放置在系统中的最适合位置。这意味着当负载能力“较好”或较差的节点变得可用时才转移资源。此选项的做用几乎等同于自动故障回复,只是资源可能会转移到非以前活动的节点上。
值大于0:
资源更愿意留在当前位置,可是若是有更合适的节点可用时会移动。值越高表示资源越愿意留在当前位置。
值小于0:
资源更愿意移离当前位置。绝对值越高表示资源越愿意离开当前位置。
值为 INFINITY:
若是不是因节点不适合运行资源(节点关机、节点待机、达到migration-threshold或配置更改)而强制资源转移资源转移,资源老是留在当前位置。此选项的做用几乎等同于彻底禁用自动故障回复.
值为-INFINITY:
资源老是移离当前位置。

 

那下面咱们来实现heartbeat v1版本的工做过程:
安装配置高可用集群:实现heartbeat v1版的过程
   一、节点名称很关键,集群每一个节的名称都得能互相解析;
   用hosts文件,/etc/hosts:hosts中主机名的正反解析结果必须跟”uname -n”的结果保持一致;
   二、时间必须得同步,使用网络时间服务器同步时间;
   三、各节点间能基于ssh密钥互相认证通讯;    

   1)配置主机名、
   第一台节点的主机名为node1.tanxw.com,第二台节点的主机名为node2.tanxw.com    

# vim /etc/hosts  改主机名,注意,两个节点都要添加,我几个节点就加几条解析
172.16.249.61 node1.tanxw.com
172.16.249.62 node2.tanxw.com
# uname -n
# hostname node1.tanxw.com
# hostname node2.tanxw.com
# cat /etc/sysconfig/network 若是这个与node1或2不一致就改一下,这个改配置文件保证下次系统重启时主机名依然有效,
# 若是改好了没有生效就ctrl+d注销一下再登陆就OK了。

   wKiom1NXNAHh7o3rAAF40k7SSIw972.jpgwKiom1NXNA_jgZgkAADC01OsoPE292.jpg    

   2)两台主机或多台主机基于ssh无密钥通讯    

# ssh-keygen -t rsa -P ‘’   这个生成一个密码为空的公钥和一个密钥,把公钥复制到对方节点上便可
# ssh-copy-id -i .ssh/id_rsa.pub root@node2.tanxw.com 对方主机名用登陆用户名
两台主机都要互相能够通讯,因此两台主机都得互相生成密钥和复制公钥,相互的节点上的hosts文件是都要解析对方的主机名,172.16.249.61 node1.tanxw.com
172.16.249.62 node2.tanxw.com
# ssh node2.tanxw.com ‘date’;date  测试一下是否已经互信

   3)安装heartbeat v1版本的程序,两个节点都要安装上heartbeat的相关程序包  

# 安装这几个包,可是存在依赖关系,须要解决:
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
# 解决依赖关系:
# yum -y install perl-TimeDate net-snmp-libs libnet PyXML
# rpm -ivh heartbeat-pils-2.1.4-12.el6.x86_64.rpm heartbeat-stonith-2.1.4-12.el6.x86_64.rpm  heartbeat-2.1.4-12.el6.x86_64.rpm

   一个高可用集群得依赖:一、信息层; 二、资源管理器;三、资源代理
   咱们配置的过程就按这种层次去配置就能够了;
   这里要注意的是:如 何在网络中咱们指望的节点集群成为咱们所须要的节点,在集群中信息不能随便传递,而心跳节点是基于组播地址传递的,若是别人也装了heartbeat也连 接到这个组播地址上来,这都不安全,基于这种状况,咱们各节点这间信息传递是须要认证的,这种认证基于HMAC(消息认证码),消息认证码是使用单向加密 算动法来实现的,而单向加密通常有三类:crc(循环冗余校验码)、md5(信息摘要算法)、sha1。heartbeat基于udp协议,监听在694 端口上;

   4)配置heartbeat,它的配置文件在/etc/ha.d/的目录下,可是安装完程序以后这个目录下没有这个配置文件,只有/usr/share /doc/heartbeat-2.1.4/目录下有ha.cf的主配置文件样本,复制到/etc下修改配置文件便可使用;还有一个authkeys的认 证文件,这个文件就是咱们各节点认证时所保存的认证密码和认证机制,因此这个文件的权限相当重要,必须是600,不然启动不了服务;第三个 haresources,定义资源时须要资源管理器来读取这个文件,因此这个也得有;  

# cp /usr/share/doc/heartbeat-2.1.4/{ha.cf,authkeys,haresources} /etc/ha.d/
# cd /etc/ha.d/
# openssl rand -hex 8   生成16位随机数
ee869d3d86e1556f
# vim /etc/ha.d/authkeys
auth 2   这里的2与下面选项的数只要一致就能够了,没有什么限定
2 sha1 ee869d3d86e1556f
# chmod 600 authkeys
# vim /etc/ha.d/ha.cf    启用如下参数及功能
logfile /var/log/ha-log  #日志文件,正常日志信息记录到哪去的
keepalive 1000ms   #每隔多长时间发送一次心跳信息的,单位是秒,毫秒用ms
deadtime 8    #隔多长时间探测到对方不在线就kill掉的时间间隔
warntime 10   #警告时间
udpport 694
mcast eth0 225.0.0.1 694 1 0   #定义组播地址
auto_failback on    #开启故障转回功能
node    node2.tanxw.com   #定义两个节点
node    node1.tanxw.com
crm on      #启用crm功能
ping 172.16.0.1   #ping节点
compression     bz2    #压缩格式
compression_threshold 2    #表示小于2K时不压缩传输

ha.cf配置文件部分参数详解:

   autojoin    none
        #集群中的节点不会自动加入
    logfile /var/log/ha-log
        #指名heartbaet的日志存放位置
    keepalive 2
        #指定心跳使用间隔时间为2秒(即每两秒钟在eth1上发送一次广播)
    deadtime 30
        #指定备用节点在30秒内没有收到主节点的心跳信号后,则当即接管主节点的服务资源
    warntime 10
        #指定心跳延迟的时间为十秒。当10秒钟内备份节点不能接收到主节点的心跳信号时,就会往日志中写入一个警告日志,但此时不会切换服务
    initdead 120
        #在某些系统上,系统启动或重启以后须要通过一段时间网络才能正常工做,该选项用于解决这种状况产生的时间间隔。取值至少为deadtime的两倍。                                     
    udpport 694
        #设置广播通讯使用的端口,694为默认使用的端口号。
    baud    19200
        #设置串行通讯的波特率
    bcast   eth0
        # Linux  指明心跳使用以太网广播方式,而且是在eth0接口上进行广播。
    #mcast eth0 225.0.0.1 694 1 0
        #采用网卡eth0的Udp多播来组织心跳,通常在备用节点不止一台时使用。Bcast、ucast和mcast分别表明广播、单播和多播,是组织心跳的三种方式,任选其一便可。
    #ucast eth0 192.168.1.2
        #采用网卡eth0的udp单播来组织心跳,后面跟的IP地址应为双机对方的IP地址
    auto_failback on
        # 用来定义当主节点恢复后,是否将服务自动切回,heartbeat的两台主机分别为主节点和备份节点。主节点在正常状况下占用资源并运行全部的服务,遇到 故障时把资源交给备份节点并由备份节点运行服务。在该选项设为on的状况下,一旦主节点恢复运行,则自动获取资源并取代备份节点,若是该选项设置为 off,那么当主节点恢复后,将变为备份节点,而原来的备份节点成为主节点
    #stonith baytech /etc/ha.d/conf/stonith.baytech
        # stonith的主要做用是使出现问题的节点从集群环境中脱离,进而释放集群资源,避免两个节点争用一个资源的情形发生。保证共享数据的安全性和完整性。
    #watchdog /dev/watchdog
        # 该选项是可选配置,是经过Heartbeat来监控系统的运行状态。使用该特性,须要在内核中载入"softdog"内核模块,用来生成实际的设备文件, 若是系统中没有这个内核模块,就须要指定此模块,从新编译内核。编译完成输入"insmod softdog"加载该模块。而后输入"grep misc /proc/devices"(应为10),输入"cat /proc/misc |grep watchdog"(应为130)。最后,生成设备文件:"mknod /dev/watchdog c 10 130" 。便可使用此功能
    node node1.magedu.com
        #主节点主机名,能够经过命令“uanme –n”查看。
    node node2.magedu.com
        #备用节点主机名
    ping 192.168.12.237
        #选择ping的节点,ping 节点选择的越好,HA集群就越强壮,能够选择固定的路由器做为ping节点,可是最好不要选择集群中的成员做为ping节点,ping节点仅仅用来测试网络链接
    ping_group group1 192.168.12.120 192.168.12.237
        #相似于ping  ping一组ip地址
    apiauth pingd  gid=haclient uid=hacluster
respawn hacluster /usr/local/ha/lib/heartbeat/pingd -m 100 -d 5s
        # 该选项是可选配置,列出与heartbeat一块儿启动和关闭的进程,该进程通常是和heartbeat集成的插件,这些进程遇到故障能够自动从新启动。最 经常使用的进程是pingd,此进程用于检测和监控网卡状态,须要配合ping语句指定的ping node来检测网络的连通性。其中hacluster表示启动pingd进程的身份。

 

 定义资源:在资源管理器的配置文件中定义;/etc/ha.d/haresources,在/etc/ha.d/resource.d下有各类资源类型,当在资源配置文件中定义时就会调用这里的资源类型来运行相应的程序;

# vim /etc/ha.d/haresources
node1.tanxw.com 172.16.249.66 httpd   # 172.16.249.66这个是浮动地址
注:node1.tanxw.com:说明哪台主机是主节点,更倾向于谁上面
[node1.tanxw.com 172.16.249.61/16/eth0/172.16.255.255 httpd 也能够这样定义
node2.tanxw.com 172.16.249.62 httpd  httpd是怎么被调用的呢:首先会找/etc/ha.d/resource.d目录下,若是没有就去/etc/init.d/目录下找httpd,找到就start。]
# scp -p authkeys haresources ha.cf node1.tanxw.com:/etc/ha.d/
# service heartbeat start

   wKiom1NXRlmxEq7jAAGESzZ-U_g798.jpg

在主节点上使用下面的命令仅仅中止 heartbeat 来模拟故障转移(failover):

/etc/rc.d/init.d/heartbeat stop

您应该会看到,在一分钟以内,第二个节点上的全部 Web 服务器进程都会启动。若是不是那样,那么去查看 /var/log/messages 来肯定问题所在并改正它。

相关文章
相关标签/搜索