linux脑裂处理命令 rhcs脑裂

keepalived产生脑裂的原因与解决方法

原因

一般来说，裂脑的发生，有以下几种原因：

1.高可用服务器对之间心跳线链路发生故障，导致无法正常通信。

2.因心跳线坏了（包括断了，老化）。

3.因网卡及相关驱动坏了，ip配置及冲突问题（网卡直连）。

4.因心跳线间连接的设备故障（网卡及交换机）。

5.因仲裁的机器出问题（采用仲裁的方案）。

6.高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输。

7.高可用服务器上心跳网卡地址等信息配置不正确，导致发送心跳失败。

8.其他服务配置不当等原因，如心跳方式不同，心跳广插冲突、软件Bug等。

9.Keepalived配置里同一 VRRP实例如果 virtual_router_id两端参数配置不一致也会导致裂脑问题发生。

解决方案

1.同时使用串行电缆和以太网电缆连接，同时用两条心跳线路，这样一条线路坏了，另一个还是好的，依然能传送心跳消息。

2.当检测到裂脑时强行关闭一个心跳节点（这个功能需特殊设备支持，如Stonith、feyce）。相当于备节点接收不到心跳消患，通过单独的线路发送关机命令关闭主节点的电源。

3.做好对裂脑的监控报警（如邮件及手机短信等或值班）.在问题发生时人为第一时间介入仲裁，降低损失。例如，百度的监控报警短倍就有上行和下行的区别。报警消息发送到管理员手机上，管理员可以通过手机回复对应数字或简单的字符串操作返回给服务器.让服务器根据指令自动处理相应故障，这样解决故障的时间更短.

相关问答

Q1: linux的LVS是如何防止脑裂的

LVS是cluster中负载均衡形式，他只分发请求报文到real server，又不共享存储，也没心跳连接对等（peer）机器，哪来的脑裂

Q2: RabbitMQ脑裂

目前生产环境RabbitMQ集群分布在铜牛机房和马驹桥机房linux脑裂处理命令，其中铜牛机房两个节点linux脑裂处理命令，马驹桥机房两个节点；

当铜牛和马驹桥机房之间网络中断或者有较大波动时linux脑裂处理命令，RabbitMQ集群会发生网络分区（脑裂），分成两个分区，当网络恢复时，网络分区的状态还是会保持，除非采取一些措施去解决，造成消息消费异常等问题。

处理网络分区的方式有两种linux脑裂处理命令：

1.手动处理网络分区：挑选一个信任的分区，重启其linux脑裂处理命令他分区的节点；

2.自动处理网络分区

RabbitMQ提供了4种处理网络分区的方式，在rabbitmq.config中配置cluster_partition_handling参数即可，分别为：ignore、pause_minority、pause_if_all_down、autoheal

经过对比，采用pause_minority方式比较符合当前场景，以下使用这种方案进行测试。

1、未加策略前，集群状态正常；

2、添加iptables策略，模拟网络中断；

网络中断后RabbitMQ服务端口还存在（同机房还可以进行读写）；

3、关闭iptables策略，检查集群状态，发现集群已经分成两个分区；

重启节点rabbit@sz-145-centos178后集群状态恢复正常。

4、修改/etc/rabbitmq/rabbitmq.config配置文件，添加pause_minority策略；

5、逐一重启所有节点，重启过程中集群状态正常；

重启完成后再次添加iptables策略，模拟网络中断；可以发现添加策略后网络中断时MQ节点检测到自身属于少数节点，所以关闭自身节点，不提供服务；

6、关闭iptables策略，可以看到该节点RabbitMQ服务自动启动，集群状态也正常；

Q3: 【Keepalived 】keepalived check and notify scripts

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基本应用解析

keepalived官方文档

使用keepalived实现redis的故障切换

Kamailio High Availability Done Right with Keepalived

Keepalived Check and Notify Scripts

Q4: Ceph分布式存储是怎么防止脑裂的？

解决脑裂问题，通常采用隔离(Fencing)机制，包括三个方面：

共享存储fencing：确保只有一个Master往共享存储中写数据。

客户端fencing：确保只有一个Master可以响应客户端的请求。

Slave fencing：确保只有一个Master可以向Slave下发命令。

Hadoop公共库中对外提供了两种fenching实现，分别是sshfence和shellfence（缺省实现），其中sshfence是指通过ssh登陆目标Master节点上，使用命令fuser将进程杀死（通过tcp端口号定位进程pid，该方法比jps命令更准确），shellfence是指执行一个用户事先定义的shell命令（脚本）完成隔离。

切换对外透明：为了保证整个切换是对外透明的，Hadoop应保证所有客户端和Slave能自动重定向到新的active master上，这通常是通过若干次尝试连接旧master不成功后，再重新尝试链接新master完成的，整个过程有一定延迟。在新版本的Hadoop RPC中，用户可自行设置RPC客户端尝试机制、尝试次数和尝试超时时间等参数。

在“双机热备”高可用（HA）系统中，当联系2个节点的“心跳线”断开时，本来为一整体、动作协调的HA系统，就分裂成为2个独立的个体。由于相互失去了联系，都以为是对方出了故障，2个节点上的HA软件像“裂脑人”一样，“本能”地争抢“共享资源”、争起“应用服务”，就会发生严重后果：或者共享资源被瓜分、2边“服务”都起不来了；或者2边“服务”都起来了，但同时读写“共享存储”，导致数据损坏（常见如数据库轮询着的联机日志出错）。

运行于备用主机上的Heartbeat可以通过以太网连接检测主服务器的运行状态，一旦其无法检测到主服务器的“心跳”则自动接管主服务器的资源。通常情况下，主、备服务器间的心跳连接是一个独立的物理连接，这个连接可以是串行线缆、一个由“交叉线”实现的以太网连接。Heartbeat甚至可同时通过多个物理连接检测主服务器的工作状态，而其只要能通过其中一个连接收到主服务器处于活动状态的信息，就会认为主服务器处于正常状态。从实践经验的角度来说，建议为Heartbeat配置多条独立的物理连接，以避免Heartbeat通信线路本身存在单点故障。

1、串行电缆：被认为是比以太网连接安全性稍好些的连接方式，因为hacker无法通过串行连接运行诸如telnet、ssh或rsh类的程序，从而可以降低其通过已劫持的服务器再次侵入备份服务器的几率。但串行线缆受限于可用长度，因此主、备服务器的距离必须非常短。

2、以太网连接：使用此方式可以消除串行线缆的在长度方面限制，并且可以通过此连接在主备服务器间同步文件系统，从而减少了从正常通信连接带宽的占用。

基于冗余的角度考虑，应该在主、备服务器使用两个物理连接传输heartbeat的控制信息；这样可以避免在一个网络或线缆故障时导致两个节点同时认为自已是唯一处于活动状态的服务器从而出现争用资源的情况，这种争用资源的场景即是所谓的“脑裂”（split-brain）或“partitioned cluster”。在两个节点共享同一个物理设备资源的情况下，脑裂会产生相当可怕的后果。

为了避免出现脑裂，可采用下面的预防措施：

添加冗余的心跳线，例如双线条线。尽量减少“裂脑”发生机会。

启用磁盘锁。正在服务一方锁住共享磁盘，“裂脑”发生时，让对方完全“抢不走”共享磁盘资源。但使用锁磁盘也会有一个不小的问题，如果占用共享盘的一方不主动“解锁”，另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃，就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了“智能”锁。即，正在服务的一方只在发现心跳线全部断开（察觉不到对端）时才启用磁盘锁。平时就不上锁了。

设置仲裁机制。例如设置参考IP（如网关IP），当心跳线完全断开时，2个节点都各自ping一下 参考IP，不通则表明断点就出在本端，不仅“心跳”、还兼对外“服务”的本端网络链路断了，即使启动（或继续）应用服务也没有用了，那就主动放弃竞争，让能够ping通参考IP的一端去起服务。更保险一些，ping不通参考IP的一方干脆就自我重启，以彻底释放有可能还占用着的那些共享资源。

Q5: 请问linux的LVS是如何防止脑裂的？

lvs有脑裂问题的，参考： ... HOWTO.failover.html，解决方法是2台都做为backup

关于linux脑裂处理命令和rhcs脑裂的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。