keepalive和脑裂问题

keepalive

keepalive起初专门为lvs负载均衡软件设计的，用来管理监控lvs集群系统中各个服务节点的状态，后来又加入了可以实现高可用的vrrp功能。

keepalive软件通过vrrp协议实现高可用功能的。VRRP（虚拟路由器冗余协议）目的就是为了解决静态路由单点故障问题，竞选机制来将路由的任务交给某台VRRP路由器的，保证节点宕机，整个网络可以不间断的运行

　　Keepalived可以实现任意两台主机之间，例如Master和Backup主机之间的故障转移和自动切换，这个主机可以是普通的不能停机的业务服务器，也可以是LVS负载均衡、Nginx反向代理这样的服务器。

Keepalived高可用简单原理

　　master端的vrrp路由器会一直发送vrrp广播包，buckup会一直收到广播包，buckup不会抢占master资源，在backup上会一直监听，一旦收不到master的包，在多台backup中优先级最高的就会抢占为master

keepalive服务的三个重要功能

　　1、  管理LVS负载均衡软件

　　2、  实现对LVS集群节点健康检查功能

　　3、  作为系统网络服务的高可用功能

1、keepalive的配置文件

! Configuration File for keepalived
global_defs {                                     　　　　　　　  #全局定义
   notification_email {                      　　　　　　　　#出问题了收件人
       [email protected]
       [email protected]
       [email protected]
   }
   notification_email_from [email protected]        #发件人
   smtp_server 192.168.200.1            　　　　　　　 #发件服务器地址
   smtp_connect_timeout 30              　　　　　　　#超时时间
   router_id LVS_DEVEL                　　　　　　　　   #唯一标识，不同机器不能一样
}

vrrp_instance VI_1 {           　　　　　　　　　　　　#vrrp实例，名字可以自定义，与前面关键字空格隔开
    state MASTER                            　　　　　　　　 #标识是主还是备，一定要大写
    interface eth0                              　　　　　　　　#默认的通信的接口，当vip不指定时，默认绑定它
    virtual_router_id 51                     　　　　　　　　#实例的ID（主备必须一样，同一文件唯一，0-255）
    priority 100                               　　　　　　　　  #真正确定谁优先地方，数字越大，级别越高，越先获取资源，建议隔50
    advert_int 1                                　　　　　　　　 #心跳间隔
    authentication {                           　　　　　　　　#实例认证，主备一样
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {                      #VIP地址
        192.168.200.16
        192.168.200.18/24 dev eth0 label eth0:1
    }
}

2、keepalive+nginx双主实战

2.1、nginx配置

在实际工作中有三个域名

www.etiantian.org

blog.etiantian.org

bbs.etiantian.org

它们的访问量都很大，可以配置不同的ip来结合keepalived进行负载，先用两个域名来测试：

10.0.0.3 www.etiantian.org

10.0.0.4 blog.etiantian.org

目地：在初始阶段,两不不同域名的服务跑在不同的机器上，（实际是互为主备的配置）

lb1:
10.0.0.3 www.etiantian.org
lb2:
10.0.0.4 blog.etiantian.org

keepaived沿用上面互为主备的配置

以下是nginx的配置（分别在两台lb上做）

所需要做的就是监听ip

 [[email protected] conf]# cat nginx.conf
worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    upstream backend {
           server 172.16.1.8:80  weight=1;
           server 172.16.1.7:80  weight=1;
           check interval=3000 rise=2 fall=5 timeout=1000 type=http;
    }
    server {
        listen      10.0.0.3:80;   #这里要监听ip
        server_name  blog.etiantian.org;
        location / {
            proxy_pass http://backend;   #这加一定要加这个抛的字段，否则访问就访问成负载的主页了
            include proxy.conf;
        }
        location /status {
            check_status;
            access_log off;
        }
    }
    server {
        listen      10.0.0.4:80;
        server_name  blog.etiantian.org;
        location / {
           proxy_pass http://backend;
           include proxy.conf;
        }
        location /status {
            check_status;
            access_log off;
        }
    }
}

2.2、keepalive配置文件

LB01：

[[email protected] ~]# cat /etc/keepalived/keepalived.conf
global_defs {
   notification_email {
   490238852@qq.com
 }
   notification_email_from 490238852@qq.com
   smtp_server 192.168.200.1
   smtp_connect_timeout 30
   router_id LVS_lb01
}
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
             10.0.0.3/24 dev eth0 label eth0:1
      }
}
vrrp_instance VI_2 {
    state BACKUP
    interface eth0
    virtual_router_id 52
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
             10.0.0.4/24 dev eth0 label eth0:2
      }
}

LB02：

[[email protected] ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
   notification_email {
        490238852@qq.com
}
   notification_email_from 490238852@qq.com
   smtp_server 192.168.200.1
   smtp_connect_timeout 30
   router_id LVS_lb02
}
vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
       10.0.0.3/24 dev eth0 label eth0:1
    }
}
vrrp_instance VI_2 {
    state MASTER
    interface eth0
    virtual_router_id 52
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
       10.0.0.4/24 dev eth0 label eth0:2
    }
}

3、脑裂原因

一般来说脑裂问题有以下这几种原因：

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

心跳线坏了（包括断了，老化）、

网卡及相关驱动坏了，IP配置及冲突问题（网卡直连）

心跳线之间的设备故障（网卡及交换机）、

仲裁的机器出现问题（才用仲裁的方案）

  1. 高可用服务器上开启了iptables防火墙，阻止了心跳传消息输
  2. 高可用服务器上心跳网卡地址等信息配置不正确，导致发送心跳失败
  3. 其他服务配置不当的原因，如心跳方式不同，心跳广播冲突，软件bug等

提示keepalive配置里同一VRRP实例如果virtual_router_id两端参数配置不一致，也会导致脑裂问题

4、脑裂方案

在实际生产环境中，我们从以下方面防止脑裂：

  1. 同时使用串行电缆和以太网电缆连接、同时使用两条心跳线路，这样一条线路断了，另外一条还是好的，依然能传送心跳消息
  2. 当检查脑裂时强行关闭一个心跳节点（这个功能需要特殊设备支持，如stonith、fence）相当于备节点接收不到心跳消息，通过单独的线路发送关机命令关闭主节点的电源
  3. 做好对脑裂的监控报警

解决常见方案：

  1. 如果开启防火墙，一定要让心跳消息通过，一般通过允许IP段的形式解决
  2. 可以拉一条以太网网线或者串口线作为主被节点心跳线路的冗余
  3. 开发检测程序通过监控软件检测脑裂

5、nginx配置文件监听的网卡上不存在IP地址问题

报错：

[[email protected] conf]# /application/nginx/sbin/nginx -t
nginx: the configuration file /application/nginx-1.6.3/conf/nginx.conf syntax is ok
nginx: [emerg] bind() to 10.0.0.4:80 failed (99: Cannot assign requested address)
nginx: configuration file /application/nginx-1.6.3/conf/nginx.conf test failed

配置好后，出现无法绑定ip10.0.0.4：80，这是由于本地没有这个ip造成的，而这个ip是需要keepalived来生的，这样就无法进行配置nginx。

解决方法：

echo ‘net.ipv4.ip_nonlocal_bind = 1‘ >> /etc/sysctl.confsysctl -p #生效

通过这个命令，系统就允许配置一个当前不存在的辅助ip

[[email protected] ~]# /application/nginx/sbin/nginx -s stop   #平滑重启没用，要关掉重启
[[email protected] ~]# /application/nginx/sbin/nginx
[[email protected] ~]# netstat -ntpl|grep nginx
tcp        0      0 10.0.0.4:80                 0.0.0.0:*                   LISTEN      7431/nginx
tcp        0      0 10.0.0.3:80                 0.0.0.0:*                   LISTEN      7431/nginx

用来访问的机器上做解析访问检查

vim /etc/hosts

10.0.0.3  www.etiantian.org

10.0.0.4  blog.etiantian.org

用户在进行访问体验是没有什么不同的，web服务器也没有一点变动，只是实现了负载均衡器流量的分流，

这样做的好处是平均负载的压力，但是注意的是负载的能力，因为当其中一台宕机了，另一台马上起另一个vip接管资源，压力太大就是雪崩。

6、开发监听脑裂的脚本

keepalived是服务器级别的，只监控服务器，nginx宕机了，是没有办法接管的

cat /server/scripts/check_nginx_by_keep.sh
#!/bin/sh
while true
do
 if [ `netstat -lntup|grep nginx|wc -l` -ne 1 ];then
    /etc/init.d/keepalived stop
 fi
  sleep 5
done

当负载器上出现nginxr的监听ip大于1时（或写做-eq 0 ，即等于0时），就杀掉keepalived进程，这样来实现web服务如nginx挂掉接管资源

7、指定日志输出文件

1、/etc/sysconfig/keepalived

修改为　　KEEPALIVED_OPTIONS="-D -d -S 0"

2、/etc/rsyslog.conf

修改为　　*.info;mail.none;authpriv.none;cron.none;local0.none    /var/log/messages

最后加　　local0.*                                                /var/log/keepalived.log

3、重启

/etc/init.d/rsyslog restart

/etc/init.d/keepalived restart

时间： 2024-07-31 08:22:34

keepalive和脑裂问题的相关文章

(转)Elasticsearch集群的脑裂问题

转自 http://blog.csdn.net/cnweike/article/details/39083089 所谓脑裂问题(类似于精神分裂),就是同一个集群中的不同节点,对于集群的状态有了不一样的理解. 今天,Elasticsearch集群出现了查询极端缓慢的情况,通过以下命令查看集群状态: curl -XGET 'es-1:9200/_cluster/health' 发现,集群的总体状态是red,本来9个节点的集群,在结果中只显示了4个:但是,将请求发向不同的节点之后,我却发现即使是总体状

iptables导致防火墙脑裂

在将heartbeat应用到生产环境中,还是有许多要注意的地方,一不小心就可能导致heartbeat无法切换或脑裂的情况,下面来介绍下由于iptables导致脑裂的现象. 主:192.168.3.218 192.168.4.218 心跳ip usvr-218 主机名 备:192.168.3.128 192.168.4.128 心跳ip usvr-128 主机名 现象:当启动heartbeat主后,VIP在218上生效:然后再启动heartbeat备,VIP在128上也生效:此时脑裂产生,导致访问

redis 脑裂等极端情况分析

脑裂真的是一个很头疼的问题(ps: 脑袋都裂开了,能不疼吗?),看下面的图: 一.哨兵(sentinel)模式下的脑裂 如上图,1个master与3个slave组成的哨兵模式(哨兵独立部署于其它机器),刚开始时,2个应用服务器server1.server2都连接在master上,如果master与slave及哨兵之间的网络发生故障,但是哨兵与slave之间通讯正常,这时3个slave其中1个经过哨兵投票后,提升为新master,如果恰好此时server1仍然连接的是旧的master,而serve

GlusterFS复制卷修复原理以及脑裂分析

裂脑 所谓脑裂,就是指两个或多个节点都"认为"自身是正常节点而互相"指责"对方,导致不能选取正确的节点进行接管或修复,导致脑裂状态.这种现象出现在数据修复.集群管理等等高可用场景. Glusterfs的冗余镜像(下文简称AFR)提供了数据副本功能,能够在即使只有一个冗余节点的情况下仍能正常工作,不中断上层应用.当节点恢复后,能够将数据修复到一致状态,保证数据的安全. AFR工作原理 AFR数据修复主要涉及三个方面:ENTRY,META,DATA,我们以冗余度为2即含

让我们聊聊脑裂这事情

万事皆有因 最近IM云平台也好,社交应用也好,大量的使用ejabberd的厂商涌现出来了.不过所有使用ejabberd厂商可能都会遇到Mnesia脑裂的问题.在这里打算简单的谈谈脑裂这个事情. 什么是脑裂 我在这里面给个非官方的定义吧.当一个集群的不同部分在同一时间都认为自己是活动的时候,我们就可以将这个现象称为脑裂症状.我们当如何理解这句话呢? 首先我们需要是个集群. 其次当中有业务是Master-Backup模式或双星模式.也就是说当主节点挂掉了,备用节点需要接管业务或者是两个节点直接有数据

数据库脑裂

Oracle RAC CSS提供2种后台服务包括群组管理(Group Managment简称GM)和节点监控(Node Monitor简称NM),其中GM管理组(group)和锁(lock)服务.在集群中任意时刻总有一个节点会充当GM主控节点(master node).集群中的其他节点串行地将GM请求发送到主控节点(master node),而master node将集群成员变更信息广播给集群中的其他节点.组成员关系(group membership)在每次发生集群重置(cluster reco

检测keepalived脑裂的脚本

检测思路:正常情况下keepalived的VIP地址是在主节点上的,如果在从节点发现了VIP,就设置报警信息 脚本如下: #!/bin/bash # 检查脑裂的脚本,在备节点上进行部署 LB01_VIP=10.10.10.229 LB01_IP=10.10.10.129 LB02_IP=10.10.10.130 while true do   ping -c 2 -W 3 $LB01_VIP &>/dev/null     if [ $? -eq 0 -a `ip add|grep &quo

Zookeeper和分布式环境中的假死脑裂问题(转)

Zookeeper和分布式环境中的假死脑裂问题 最近和同事聊天无意间发现他们的系统也存在脑裂的问题.想想当初在我们的系统中为了解决脑裂花了非常大的功夫,现在和大家一起讨论下脑裂,假死等等这些问题和解决的方法. 在一个大集群中往往会有一个master存在,在长期运行过程中不可避免的会出现宕机等问题导致master不可用,在出现这样的情况以后往往会对系统产生很大的影响,所以一般的分布式集群中的master都采用了高可用的解决方案来避免这样的情况发生. master-slaver方式,存在一个mast

【翻译自mos文章】12c rac中，当脑裂发生时，哪个节点会幸存下来？

来源于: 12c: Which Node Will Survive when Split Brain Takes Place [1951726.1] 12c rac中,当脑裂发生时,哪个节点会幸存下来? 适用于: Oracle Database - Enterprise Edition - Version 12.1.0.2 and later Information in this document applies to any platform. 目的: 理解 从12.1.0.2开始,当脑裂发