keepalived高可用系列~通用基础

简介:今天咱们来聊聊keepalived
一 keepalived 架构

1  标准架构:

keepalived+lvs/haproxy+后端 real server(mysql从库,nginx.mycat) 实现静态的高可用和负载均衡
     1 特点 :

1 keepalived在独立的服务器上,为后端多组集群提供高可用服务

2 配置文件 包含后端真实IP和端口检测
    2 检测后端服务脚本：
        1 手段 1 TCP 2 HTTP 3 MISC_CHECK(自定义脚本)
        2 目的 用以实现后端服务的动态踢出和加入
  2   标准架构2
     keepalived+service 实现服务的高可用
     特点

1 keepalived和service绑定在同一组机器上

2  配置文件不包含真实IP,服务为本地脚本检测     
   检测自身服务脚本
       1 手段

1 vrrp_script+ track_script 搭配
           2 notify模块 notify_master 状态改变为master以后执行的脚本
                              notify_backup 状态改变为backup以后执行的脚本。
                              notify_down 服务停止以后执行的脚本。
       2 目的 用以实现高可用服务和VIP的动态漂移
     不抢占模式
       1 state 都设置为BACKUP
       2 主增加 nopreempt 参数 备参数不变
       3 priority 参数主备不一致
       4 先启动主(因为设置了nopreempt，所以不会按照优先级来定夺)

二 keeplived的主从切换策略
    1 在Keepalived集群中，其实并没有严格意义上的主、备节点，虽然可以在Keepalived配置文件中设置“state”选项为“MASTER”状态，但是这并不意味着此节点一直就是Master角色。由两点确定
            1 节点的priority值，但并它并不控制所有节点的角色，
            2 是在vrrp_script模块中设置的“weight”值，这两个选项对应的都是一个整数值，其中weight值可以是个负整数
   2 在一个一主多备的Keepalived集群中，“priority”值最大的将成为集群中的Master节点，而其他都是Backup节点。在Master节点发生故障后，Backup节点之间将进行“民主选举”，通过对节点优先级值“priority”和““weight”的计算，选出新的Master节点接管集群服务。
   3 在vrrp_script模块中，如果不设置“weight”选项值，那么集群优先级的选择将由Keepalived配置文件中的“priority”值决定，而在需要对集群中优先级进行灵活控制时，可以通过在vrrp_script模块中设置“weight”值来实现。

三  keeplived的部署条件

1 DR模式下必须为同一网段的机器

2 绑定双网卡,有独立的网卡进行检测,防止因为流量阻塞发生脑裂现象,俗称双网卡机制

3 不论何种架构,keepalived都是通过判断对方进程是否存在判断VIP是否需要漂移

四  LVS 相关命令

1 调整权重

ipvsadm -e -t 1VIP:3306  -r IP -w 0 降低

ipvsadm -e -t 1VIP:3306  -r IP -w 1 升高