Stonith,全称Shoot The Other Node In The Head,用于防止集群出现脑裂现象。简单来说,一旦集群中的节点相互之间失去了通信,无法知道其他节点的状态,此时集群中的每个节点将尝试fence(隔离或“射杀”)失去通信的节点,确保这些节点不再抢夺资源,然后才继续启动服务资源,对外提供服务。
在3台集群主机上安装fence-agents软件包。
安装完毕后可查看到系统支持的stonith设备类型:
以上输出中的每个Fence agent都是一种Stonith设备,从名字的后缀可以看出,这些Agent有以下几类:
前两种都属于电源类型的Stonith设备,而第三种和电源无关,之所以要这样划分,是因为:
以下以fence_scsi为例进行实验。
安装 《在CentOS7上配置iSCSI》 中的方法,通过一台专用的存储节点ha-disks为集群中的3个主机提供共享存储(即在ha-disks上创建iscsi硬盘,然后将其映射到3个集群主机上)。
在iscsi-disks上创建3个100M的硬盘fen1,fen2,fen3,挂载到主机上后设备名称分别为sdb,sdc,sdd
测试一下这些硬盘是否支持PR Key:
首先使用一个fence盘/dev/sdb来进行实验:
使用sg_persist -s参数获取/dev/sdb上的所有信息:
可以看到,3个节点使用不同的PR Key在这个磁盘上进行了注册(register),并且ha-host1保留(reservation)成功,类型为“Write Exclusive, registrants only”。表明此时只有ha-host1对该磁盘进行写 *** 作。
此时如果断开其中两个节点的的链接,如ha-host1和ha-host3:
可以看到,经过协商后,ha-host3退出集群,并且也删除在fencing磁盘中的注册信息。由于stonith资源运行在ha-host2上,所以在ha-host2的日志中可以看到ha-host3被fence的过程:
ha-host3被fence之后,必须重启才能重新注册PR Key,否则即使网络恢复,其也无法运行需要stonith支持的资源。
问题:仲裁机制保证了必须有超过半数的节点的partition才能启动资源,拿为什么还需要stonith设备?
Keepalived软件起初是专为LVS负载均衡软件设计的,用来管理并监控LVS集群系统中各个服务节点的状态,后来又加入了可以实现高可用的VRRP功能。因此,Keepalived除了能够管理LVS软件外,还可以作为其他服务(例如:Nginx、Haproxy、MySQL等)的高可用解决方案软件。
Keepalived采用是模块化设计,不同模块实现不同的功能。
keepalived主要有三个模块,分别是core、check和vrrp。
core :是keepalived的核心,负责主进程的启动和维护,全局配置文件的加载解析等
check : 负责healthchecker(健康检查),包括了各种健康检查方式,以及对应的配置的解析包括LVS的配置解析;可基于脚本检查对IPVS后端服务器健康状况进行检查
vrrp :VRRPD子进程,VRRPD子进程就是来实现VRRP协议的
keepalived 配置文件:
Keepalived 配置文件为:keepalived.conf;
主要有三个配置区域,分别是:全局配置(Global Configuration)、VRRPD配置、LVS配置
全局配置又包括两个子配置: 全局定义(global definition) 静态IP地址/路由配置(static ipaddress/routes)
Keepalived服务VRRP的工作原理:
Keepalived高可用对之间是通过 VRRP进行通信的, VRRP是通过竞选机制来确定主备的,主的优先级高于备,因此,工作时主会优先获得所有的资源,备节点处于等待状态,当主宕机的时候,备节点就会接管主节点的资源,然后顶替主节点对外提供服务
在 Keepalived服务对之间,只有作为主的服务器会一直发送 VRRP广播包,告诉备它还活着,此时备不会抢占主,当主不可用时,即备监听不到主发送的广播包时,就会启动相关服务接管资源,保证业务的连续性.接管速度最快
出现脑裂的原因:
高可用服务器对之间心跳线链路发生故障,导致无法正常通信。
因心跳线坏了(包括断了,老化)。
因网卡及相关驱动坏了,ip配置及冲突问题(网卡直连)
因心跳线间连接的设备故障(网卡及交换机)
因仲裁的机器出问题(采用仲裁的方案)
高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输。
高可用服务器上心跳网卡地址等信息配置不正确,导致发送心跳失败
其他服务配置不当等原因,如心跳方式不同,心跳广插冲突、软件Bug等。
如何解决脑裂:
① 同时使用串行电缆和以太网电缆连接,同时用两条心跳线路,这样一条线路坏了,另一个还是好的,依然能传送心跳消息。
② 当检测到裂脑时强行关闭一个心跳节点(这个功能需特殊设备支持,如Stonith、feyce)。相当于备节点接收不到心跳消患,通过单独的线路发送关机命令关闭主节点的电源。
③ 做好对裂脑的监控报警(如邮件及手机短信等或值班).在问题发生时人为第一时间介入仲裁,降低损失。管理员可以通过手机回复对应数字或简单的字符串 *** 作返回给服务器.让服务器根据指令自动处理相应故障这样解决故障的时间更短。
####################################################################
大家知道keepalived会有四种状态的变化,每种状态变化时,都可以调用一个脚本
当进入Master状态时会呼叫notify_master
当进入Backup状态时会呼叫notify_backup
当发现异常情况时进入Fault状态呼叫notify_fault
当Keepalived程序终止时则呼叫notify_stop
进入Master和Backup这两种状态很容易理解了,就是分别变为主和从
进入Fault,简单的说就是keepalived发现自己有问题了,不能能再去参与Master竞选了,你得修好他才行。
进入这种状态一般是keepalived自身出问题了,或者keepalived检测的网卡出问题不通了,再或者就是我们自己写的检测业务的脚本返回错误
进入Stop 这个就容易理解了,执行service keepalived stop 或者 systemctl stop keepalived 就会进入这个状态。
设置selinux为宽松模式
# setenforce 0
# sed -i 's/^SELINUX=.*/SELINUX=permissive/g' /etc/selinux/config
CentOS防火墙默认是不允许keepalived使用 vrrp的组播。
如果不开启组播ip,keepalived双机不能实现热备的效果,只能实现负载的效果,即虚拟ip不能实现漂移 。
Check that the multicast IP and protocol for VRRP are allowed in the firewall on both servers.
For firewalld:
添加规则
# firewall-cmd --direct --permanent--add-rule ipv4 filterINPUT 0 --in-interface eth0 --destination 224.0.0.18 --protocol vrrp -j ACCEPT
# firewall-cmd --direct --permanent--add-ruleipv4 filterOUTPUT 0 --out-interface eth0 --destination 224.0.0.18 --protocol vrrp -j ACCEPT
# firewall-cmd --reload
删除规则
# firewall-cmd --direct --permanent--remove-ruleipv4 filterINPUT 0 --in-interface eth0 --destination 224.0.0.18 --protocol vrrp -j ACCEPT
# firewall-cmd --direct --permanent--remove-rule ipv4 filterOUTPUT 0 --out-interface eth0 --destination 224.0.0.18 --protocol vrrp -j ACCEPT
# firewall-cmd --reload
For iptables:
添加规则
# iptables -A INPUT -p vrrp -j ACCEPT
# iptables -A OUTPUT -p vrrp -j ACCEPT
# service iptables save
删除规则
# iptables -D INPUT -p vrrp -j ACCEPT
# iptables -D OUTPUT -p vrrp -j ACCEPT
# service iptables save
keepalived基本应用解析
http://blog.51cto.com/pangge/1301878
keepalived官方文档
http://www.keepalived.org/doc/introduction.html
使用keepalived实现redis的故障切换
http://peiqiang.net/2014/11/21/keepalived-and-redis.html
Kamailio High Availability Done Right with Keepalived
http://blog.unicsolution.com/2015/01/kamailio-high-availability-with.html
Keepalived Check and Notify Scripts
https://tobrunet.ch/keepalived-check-and-notify-scripts
OracleRACCSS提供2种后台服务包括群组管理(GroupManagment简称GM)和节点监控(NodeMonitor简称NM),其中GM管理组(group)和锁(lock)服务。在集群中任意时刻总有一个节点会充当GM主控节点(masternode)。集群中的其他节点串行地将GM请求发送到主控节点(masternode),而masternode将集群成员变更信息广播给集群中的其他节点。组成员关系(groupmembership)在每次发生集群重置(clusterreconfiguration)时发生同步。每一个节点独立地诠释集群成员变化信息。而节点监控NM服务则负责通过skgxn(skgxn-libskgxn.a,提供节点监控的库)与其他厂商的集群软件保持节点信息的一致性。此外NM还提供对我们熟知的网络心跳(Networkheartbeat)和磁盘心跳(Diskheartbeat)的维护以保证节点始终存活着。当集群成员没有正常Networkheartbeat或Diskheartbeat时NM负责将成员踢出集群,被踢出集群的节点将发生节点重启(reboot)。NM服务通过OCR中的记录(OCR中记录了Interconnect的信息)来了解其所需要监听和交互的端点,将心跳信息通过网络发送到其他集群成员。同时它也监控来自所有其他集群成员的网络心跳Networkheartbeat,每一秒钟都会发生这样的网络心跳,若某个节点的网络心跳在misscount(bytheway:10.2.0.1中Linux上默认misscount为60s,其他平台为30s,若使用了第三方vendorclusterware则为600s,但10.2.0.1中未引入disktimeout;10.2.0.4以后misscount为60s,disktimeout为200s;11.2以后misscount为30s:CRS-4678:Successfulgetmisscount30forClusterSynchronizationServices,CRS-4678:Successfulgetdisktimeout200forClusterSynchronizationServices)指定的秒数中都没有被收到的话,该节点被认为已经”死亡”了。NM还负责当其他节点加入或离开集群时初始化集群的重置(Initiatesclusterreconfiguration)。在解决脑裂的场景中,NM还会监控votingdisk以了解其他的竞争子集群(subclusters)。关于子集群我们有必要介绍一下,试想我们的环境中存在大量的节点,以Oracle官方构建过的128个节点的环境为我们的想象空间,当网络故障发生时存在多种的可能性,一种可能性是全局的网络失败,即128个节点中每个节点都不能互相发生网络心跳,此时会产生多达128个的信息”孤岛”子集群。另一种可能性是局部的网络失败,128个节点中被分成多个部分,每个部分中包含多于一个的节点,这些部分就可以被称作子集群(subclusters)。当出现网络故障时子集群内部的多个节点仍能互相通信传输投票信息(votemesg),但子集群或者孤岛节点之间已经无法通过常规的Interconnect网络交流了,这个时候NMReconfiguration就需要用到votingdisk投票磁盘。因为NM要使用votingdisk来解决因为网络故障造成的通信障碍,所以需要保证votingdisk在任意时刻都可以被正常访问。在正常状态下,每个节点都会进行磁盘心跳活动,具体来说就是会到投票磁盘的某个块上写入disk心跳信息,这种活动每一秒钟都会发生,同时CSS还会每秒读取一种称作”killblock”的”赐死块”,当”killblock”的内容表示本节点被驱逐出集群时,CSS会主动重启节点。为了保证以上的磁盘心跳和读取”killblock”的活动始终正常运作CSS要求保证至少(N/2+1)个投票磁盘要被节点正常访问,这样就保证了每2个节点间总是至少有一个投票磁盘是它们都可以正常访问的,在正常情况下(注意是风平浪静的正常情况)只要节点所能访问的在线votingdisk多于无法访问的votingdisk,该节点都能幸福地活下去,当无法访问的votingdisk多于正常的votingdisk时,ClusterCommunicationService进程将失败并引起节点重启。所以有一种说法认为votingdisk只要有2个足以保证冗余度就可以了,没有必要有3个或以上votingdisk,这种说法是错误的。Oracle推荐集群中至少要有3个votingdisks。补充1:Question:有同学问那么votingdisk必须是奇数个呢?Answer:实际上我们仅仅是推荐使用奇数个votedisk,而非必须是奇数个。10gR2中votedisk的数目上限是32个。Question我们可以使用2或4个votedisk吗?Answer:可以的。但是2、4这样的数目在“至少(N/2+1)个投票磁盘要被节点正常访问”这一diskheartbeat的硬性算法下是不利的:当我们使用2个votedisk时,不能发生任意个votedisk的心跳失败当我们使用3个votedisk时,不能发生大于1个的votedisk心跳失败当我们使用4个votedisk时,不能发生大于1个的votedisk心跳失败,这和3个时的容错率是一样,但是因为我们有的votedisk,这会导致管理成本和引入的风险增长当我们使用5个votedisk时,不能发生大于2个的votedisk心跳失败当我们使用6个votedisk时,仍然不能发生大于2个的votedisk心跳失败,同样的因为比5时多出一个,也会引入不合理的管理成本和风险补充2:Question:若节点间的网络心跳正常,且节点所能正常心跳的votedisk大于不能正常访问的,如3个votedisk时恰巧有1个votedisk的diskheartbeat超时,此时Brainsplit会发生吗?Answer:这种情况即不会触发BrainSplit,也不会引发节点驱逐协议(evictionprotocol)。当单个或小于(N/2+1)个的votingdisk心跳失败(diskheartbeatfailure)时,这种心跳失败可能是由于短期内节点访问votingdisk发生I/Oerror错误而引起的,此时css会立刻将这些失败的votingdisk标记为OFFLINE。虽然有一定数量的votingdiskOFFLINE了,但是我们仍有至少(N/2+1)个投票磁盘可用,这保证了evictionprotocol不会被调用,所以没有节点会被reboot重启。紧接着nodemonitor模块的DiskpingMonitorThread(DPMT-clssnmDiskPMT)会重复尝试访问这些失败的OFFLINEvotingdisk,若这些投票磁盘变得再次可I/O访问且经过验证其上的数据也没有讹误,那么css会再次将此votingdisk标记为ONLINE;但是如果在45s(这里的45s是基于misscount和内部算法获得的)内仍不能正常访问相关的votingdisk,那么DMPT将在cssd.log中生成警告信息,如:欢迎分享,转载请注明来源:内存溢出
评论列表(0条)