高可用解决方案--keepalived

企业开发 2018-08-19 18:53:50 阅读次数: 0

高可用指标=MTBF/(MTBF+MTTR)
MTBF：Mean Time Between Failture [两次故障平均间隔时间]
MTTR：Mean Time To Restoration [平均恢复时间]

从上诉公式可以得出，要提高系统的高可用性，就需要提高系统的无故障时间（MTBF）和缩短系统修复的时间（MTTR）。
缩短MTTR的办法：引入冗余机制，当系统某一部分出现故障，备份可以快速替换。因此MTTR主要取决于检测出故障的时间和完成故障切换的时间。

keepalived的作用：
  ①生成ipvs规则；
  ②实现IP漂移。
keepalived是VRRP协议在Linux系统上的实现软件，是为了实现IP漂移。

目录

  • VRRP协议的实现
  • keepalived的工作原理
  • keepalived的配置文件
  • keepalived的主备模型实例
  • keepalived的双主模型实例
  • keepalived实现状态切换时的消息通知
  • keepalived实现高可用ipvs
  • vrrp script实现特定服务的高可用

1、VRRP协议的实现

VRRP的相关术语

 虚拟路由器：由一个Master路由器和多个Backup路由器组成。通俗讲就是一个路由器集群。
 VRID：虚拟路由器标识，如果多个路由器有相同的VRID，那么这些路由器就组成了一个虚拟路由器。
 Master路由器：虚拟路由器中真正承担报文转发的节点。
 Backup路由器：虚拟路由器中某一时刻除Master路由器的其他都有节点。
 虚拟IP（VIP）：虚拟路由器的IP，VIP是用于客户接入的IP地址。
 虚拟MAC地址：虚拟路由器拥有的MAC地址，其格式为00-00-5E-00-01-VRID。
 优先级：VRRP根据每个节点的优先级确定节点在虚拟路由器中的地位。如果优先级相同，则根据节点的IP地址大小进行比较。
 抢占方式和非抢占方式：抢占方式中只要优先级最高才会成为Master路由器，而非抢占方式中只要Master路由器没有出现故障，则Baskup路由器的优先级再高也不会成为Master路由器。

VRRP协议的工作原理

可以参考VRRP协议工作原理

2、keepalived的工作原理

keepalived的核心组件

高可用解决方案--keepalived
Checkers：对后端服务器节点（RS）进行健康状态监测和故障隔离，我们知道，LVS本身是没有健康状态监测功能，keepalived起初就是为LVS生成ipvs规则和增加健康状态检测功能而设计的。
VRRP Stack：这是keepalived实现VRRP功能的模块，VRRP功能可以实现对前端调度器集群的故障切换(failover)。
SMTP：Checkers和VRRP Stack都是对节点进行状态监测，不同的是监测前端调度器和监测后端RS，但是这两个模块都可以通过SMTP通知管理员故障信息的邮件。
System Call：Checkers和VRRP Stack同样都可以调用系统内核功能完成故障隔离和故障切换。
IPVS wrapper：Checkers通过监测后端RS的工作状态得出信息，IPVS wrapper通过这些信息添加ipvs规则，内核中的IPVS则通过这些规则进行工作。
Netlink Reflector：在调度器发生故障切换的时候，该模块充当调用内核NETLINK的接口，完成虚拟IP的设置和切换。
Watch Dog：keepalived的核心模块就是Checkers和VRRP Stack，当这两个模块发生故障的时候怎么办呢，这时候Watch Dog就发生了作用，它是一个硬件检测工具，一旦Checkers和VRRP Stack发生故障，Watch Dog就能够检测到并采取恢复措施（重启）。

3、keepalived的配置文件

配置文件的结构层次

keepalived的配置文件分为三个部分，分别是：
 Global Configuration：全局配置部分
  Global definition
  static routes/address
 VRRPD Configuration：VRRPD配置部分
  VRRP instance:VRRP实例配置
  VRRP synchronization group:VRRP同步组
 LVS Configuration：LVS配置部分
  Virtual server:ipvs的RS和VS

全局配置的常用参数

参数 含义
global_defs {...} 全局配置区域，该参数是全局配置开始的标识
notification_email{...} 设置接受邮件报警的地址。即指明邮件的接收人是谁
smtp_server 设置连接邮件服务器的超时时间
smtp_connnet_timeout 全局配置区域，该参数是全局配置开始的标识
notification_email_from 设置邮件的发送地址。即指明邮件的发件人是谁
vrrp_mcast_group4 设置组播地址，4代表ipv4
router_id 表示运行一个keepalived服务的标识

VRRPD配置的常用参数

  VRRP实例参数

参数 含义
vrrp_instance VRRP实例开始的标识，后面跟实例的名称
state 指明keepalived的角色，MASTER或者BACKUP
interface 指定keepalived在高可用集群中监控的网络接口
virtual_router_id 自定义的虚拟路由器标识，在同一个VRRP实例中，MASTRE和BACKUP的标识号必须一样
priority 定义高可用集群中节点的优先级，值越大优先级越高，范围是1-254
advert_int 高可用集群中主备节点之间发送心跳信息的时间间隔
authentication{...} 设置高可用集群中节点之间通信时的验证类型和验证密码，MASTER和BACKUP之间只有验证密码相同才能通信
virtual_ipaddress{...} 设置虚拟IP地址，例如192.168.239.105/24 dev eth1
track_interface{...} 定义要监控的网络接口,当网卡出现故障的时候，节点的状态变为FAULT
nopreempt 定义为非抢占模式
preempt_delay 定义为抢占模式，并且定义节点上线后多长的时间延迟后触发选举操作,保证不会让新节点刚上线就去抢占
notify_master 当当前节点的keepalived进入MASTER状态的时候触发的脚本，格式为notify_master "script-location arg1 arg2 ..."
notify_backup 当前节点的keepalived进入BACKUP状态的时候触发的脚本，格式为notify_backup"script-location arg1 arg2 ..."
notify_fault 当前节点的keepalived进入FAULT状态的时候触发的脚本，格式类似
notify_stop 当前节点的keepalived终止的时候触发的脚本，格式类似

上诉notify相关的四个参数，一般用于状态监控通知的脚本。

4、keepalived主备模型实例

在主备模型中的所有节点中，某一时刻只允许有一个节点处于MASTER状态，其他节点均为BACKUP状态。工作中只有MASTER节点会接受请求，BACKUP状态的节点处于闲置状态。只有在MASTER出现故障的时候，BACKUP节点才会重新选举出新的节点进入MASTER状态。
主节点的配置文件内容如下：

! Configuration File for keepalived
global_defs {
    notification_email {
        root@localhost
}
    notification_email_from keepalived@localhost
    smtp_server 127.0.0.1
    smtp_connect_timeout 10
    router_id node1
    vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
    state MASTER      # 初始化设置为MASTER节点
    interface eth1
    virtual_router_id 50   # 同一个VRRP实例中每个节点的虚拟路由ID必须相同
    priority 100             # MASTER节点的优先级必须高于BACKUP节点
    advert_int 1
    authentication {
        auth_type PASS    # 验证类型为密码认证
        auth_pass 1111qwer # 验证密码，需要注意密码最大长度为8位
    }
    virtual_ipaddress {
        192.168.239.250/24 dev eth1  # 主备节点的VIP一定要相同
    }
}

Backup节点的配置文件内容如下：

! Configuration File for keepalived
global_defs {
    notification_email {
        root@localhost
}
    notification_email_from keepalived@localhost
    smtp_server 127.0.0.1
    smtp_connect_timeout 10
    router_id node1
    vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
    state BACKUP
    interface eth1
    virtual_router_id 50
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111qwer
    }
    virtual_ipaddress {
        192.168.239.250/24 dev eth1
    }
}

关闭防火墙和SELinux。
开启两个节点的keepalived服务。

[root@Master ~]# /etc/init.d/keepalived restart
Starting keepalived:                                       [  OK  ]
[root@Backup ~]# /etc/init.d/keepalived start
Starting keepalived:                                       [  OK  ]

查看主节点的日志信息
高可用解决方案--keepalived
查看备节点的日志信息
高可用解决方案--keepalived
利用命令ip a查看主节点的ip状态，可以看到VIP已经配置到了eth1网卡上
高可用解决方案--keepalived
备节点因为处于BACKUP状态，则没有获得VIP。
高可用解决方案--keepalived
arp 192.168.239.250命令也可以看出VIP的MAC地址为主节点eth1网卡的MAC地址。
高可用解决方案--keepalived
现在将主节点中的keepalived.conf中的优先级参数设置为80（低于备节点），然后重启主节点的keepalived服务。再次查看IP状态和ARP缓存表信息。
高可用解决方案--keepalived
高可用解决方案--keepalived
并且VIP对应的MAC地址也发生了变化。说明IP漂移已经实现。
高可用解决方案--keepalived

5、keepalived双主模型实例

在keepalived的主备模型中，当主节点正常的时候，备节点永远处于闲置状态，不会接受web请求，这样就会浪费一半的资源。因此可以使用keepalived的双主模型实例，使得其中的两个节点都能够接受web请求，这要求节点1在一个vrrp实例处于master状态，在另一个vrrp实例中处于backup状态；节点2在一个vrrp实例中处于backup状态，在另一个vrrp实例中处于master状态。
节点1的配置文件内容如下：

[root@Master ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
    notification_email {      
        root@localhost
} 
    notification_email_from keepalived@localhost  
    smtp_server 127.0.0.1  
    smtp_connect_timeout 10  
    router_id node1
    vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
    state MASTER
    interface eth1 
    virtual_router_id 50   
    priority 100
    advert_int 1  
    authentication { 
        auth_type PASS  
        auth_pass 1111qwer    
    }
    virtual_ipaddress {        
        192.168.239.250/24 dev eth1
    }
}
vrrp_instance VI_2 {
    state BACKUP
    interface eth1
    virtual_router_id 52
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111qwer
    }
    virtual_ipaddress {
        192.168.239.150/24 dev eth1
    }
}

节点2的配置文件内容如下：

[root@Backup ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
    notification_email {      
        root@localhost
} 
    notification_email_from keepalived@localhost  
    smtp_server 127.0.0.1  
    smtp_connect_timeout 10  
    router_id node2
    vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
    state BACKUP
    interface eth1 
    virtual_router_id 50   
    priority 90
    advert_int 1  
    authentication { 
        auth_type PASS  
        auth_pass 1111qwer    
    }
    virtual_ipaddress {        
                192.168.239.250/24 dev eth1 # VIP1的信息
    }
}
vrrp_instance VI_2 {
    state MASTER
    interface eth1
    virtual_router_id 52
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111qwer
    }
    virtual_ipaddress {
        192.168.239.150/24 dev eth1 # VIP2的信息
    }
}

节点1的VIP1信息：
高可用解决方案--keepalived
节点2的VIP2信息：
高可用解决方案--keepalived
当节点1的keepalived停止，节点1的VIP移除，效果如下：
高可用解决方案--keepalived
节点2获得两个VIP，如图：
高可用解决方案--keepalived

6、keepalived状态切换时的消息通知

当keepalived的状态发生变化的时候，往往需要通知管理员，这个时候就需要借助notify_master、notify_backup、notify_fault三个参数，进而配合脚本来实现keepalived的消息通知机制。这三个参数的使用规范上面有说过。
实验中每个节点使用同一个脚本，脚本内容如下：
脚本的主要功能是当keepalived的状态发生转换之后，keepalived会给指定收件人发送通知邮件，告诉收件人哪个节点切换为什么状态。

#!/bin/bash
#
recipient="root@localhost"

notify () {
    local mailsubject="$(hostname) to be $1 and VIP floating"
    local mailbody="$(date '+%F %T'):vrrp transation,$(hostname) changed to be $1"
    echo "$mailbody" | mail -s "$mailsubject" $recipient
}

case $1 in
master)
    notify master
    ;;
backup)
    notify backup
    ;;
fault)
    notify fault
    ;;
*)
    echo "Usage:$(basename $0) {master|backup|fault}"
    exit 1
    ;;
esac

该实验使用的是主备模型，其中主节点的配置文件内容如下：

[root@Master ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
            notification_email {      
        root@localhost
} 
            notification_email_from keepalived@localhost  
            smtp_server 127.0.0.1  
            smtp_connect_timeout 10  
            router_id node1
            vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
            state MASTER
            interface eth1 
            virtual_router_id 50   
            priority 100
            advert_int 1  
            authentication { 
                    auth_type PASS  
                    auth_pass 1111qwer    
            }

            track_interface {
                    eth1
            }

            notify_master "/etc/keepalived/notify.sh master"
            notify_backup "/etc/keepalived/notify.sh backup"
            notify_fault "/etc/keepalived/notify.sh fault"

            virtual_ipaddress {        
                    192.168.239.250/24 dev eth1
            }
}

备节点的配置文件内容如下：

[root@Backup ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
            notification_email {      
        root@localhost
} 
            notification_email_from keepalived@localhost  
            smtp_server 127.0.0.1  
            smtp_connect_timeout 10  
            router_id node2
            vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
            state BACKUP
            interface eth1 
            virtual_router_id 50   
            priority 90
            advert_int 1  
            authentication { 
                    auth_type PASS  
                    auth_pass 1111qwer    
            }

            track_interface {
                    eth1
            }

            notify_master "/etc/keepalived/notify.sh master"
            notify_backup "/etc/keepalived/notify.sh backup"
            notify_fault "/etc/keepalived/notify.sh fault"

            virtual_ipaddress {        
                        192.168.239.250/24 dev eth1
            }
}

现在启动主备节点的keepalived服务，其中主节点获得VIP，进入MASTER状态，备节点进入BACKUP状态。然后每个节点会收到相对应的通知邮件。可以使用mail命令查看，该命令是由mailx软件提供的。
高可用解决方案--keepalived
高可用解决方案--keepalived
对于keepalived的FAULT状态，该状态与keepalived监控的网络接口有关，如果节点的网卡出现故障，则keepalived会进入FAULT状态，暂停主节点的网卡，然后系统会受到通知邮件，如下图，通知keepalived进入FAULT状态。

[root@Master ~]# ifdown eth1

高可用解决方案--keepalived

7、keepalived实现高可用ipvs

keepalived的另一个重要的配置段是关于LVS的配置，LVS配置段是实现LVS高可用功能。该配置段以virtual_server为开始标识。

LVS配置段参数 具体含义
virtual_server LVS配置段开始标识，格式为virtual_server vip port {...}
delay_loop 对后端服务器集群进行健康状态监测的时间间隔，单位是秒
lb_algo 定义负载均衡的调度算法，有rr，wrr，lc，wlc，lblc，sh，dh等
lb_kind 定义LVS的工作模式，有NAT、DR和TUN三种模式
persistence_timeout 定义ipvs的持久连接时长
protocol ipvs服务的协议类型，目前keepalived仅支持ipvs的TCP协议
sorry_server 指定备用后端服务器的IP地址，仅在所有real server失效后，备用节点才会生效，格式为sorryserver ip port
real_server 后端真实服务器的配置段的开始标识，格式为realserver ip port {...}
real_server段配置参数 具体含义
weight 设置后端服务器节点的权值，数字越大权值越大
notify_up 当后端节点切换为UP状态触发的脚本，格式为notifyup scriptlocation arg1 arg2 ...，功能类似于notify_master参数
notify_down 当后端节点切换为DOWN状态触发的脚本
健康监测段配置 HTTP_GET、SSL_GET、TCP_CHECK、SMTP_CHECK、MISC_CHECK
健康监测端配置参数 具体含义
HTTP_GET、SSL_GET 这两个参数是基于应用层的检测方式，格式为HTTP_GET {...}
TCP_CHECK 基于四层的监测方式，格式为TCP_CHECK {...}

应用层检测配置段的参数：
HTTP_GET|SSL_GET {
  url {
    path /index.html
    status_code 200
    digest xxxxxxxx

  }

  nb_get_retry 3
  delay_before_retry 2
  connect_ip
  connect_port
  bindto
  bind_port
  connect_timeout
}
url：指定HTTP/SSL监控的URL信息.
path：定义要监控的详细的URL
status_code：指定返回http检测正常的状态码类型，就是当返回指定的状态码时即可认定节点正常，一般为200。
digest：status_code定义的状态码并不准确，即使返回200的状态码，还是有网页内容被篡改的可能，这样就无法发现错误信息，因此加入了digest参数，对网页内容的摘要信息进行比对，如果一致则认为页面没有发生改变。该摘要信息可以使用命令genhash生成。

genhash -s 192.168.239.129 -p 80 -u /index.html

nb_get_retry：重试的次数
delay_before_retry：重试之前等待的时间延迟,即两次重试之间的间隔，单位是秒
上边的两个参数是在检测到错误信息之后才会生效。
connect_ip：向当前RS的哪个IP地址发送健康状态监测信息
connect_port：向当前RS的哪个端口发送健康状态监测信息
如果connect_ip和connect_port都没有指定，则默认使用real_server参数指定的IP和port。
bindto：指定负载均衡器对RS发送健康状态监测的源IP地址
bind_port：指定负载均衡器对RS发送健康状态监测的源端口
connect_timeout：定义健康状态监测的连接超时时间
基于四层监测配置段参数：
TCP_CHECK {
  connect_ip
  connect_port
  bindto
  bind_port
  connect_timeout
}
keepalived的LVS段配置实例
实验环境：

主机名 IP地址 备注信息
Master.linux.com 192.168.239.137 keepalived的主节点
Backup.linux.com 192.168.239.138 keepalived的备节点
Web1.linux.com 192.168.239.129 RS1
Web2.linux.com 192.168.239.133 RS2
---- 192.168.239.250 VIP，基于keepalived的主备模型

开始该实验之前先暂停上面实验的keepalived的服务。
第一步：
配置后端真实服务器集群的每个节点，其中的HTTP服务使用Nginx实现，具体Nginx的操作可以参考博客Nginx使用，并且设置Web1.linux.com节点的首页文件index.html的内容为This is web1 with 80 。Web2.linux.com节点的首页文件index.html的内容为This is web2 with 80。
当出现下图所示的页面内容的时候表示RS集群的http服务配置成功。
高可用解决方案--keepalived
高可用解决方案--keepalived
第二步：
该实验中基于LVS的DR模型，因此需要设置RS的VIP地址和ARP抑制参数等。我这里使用脚本。

[root@Web1 data]# cat arp_depress.sh 
#!/bin/bash
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
ifconfig lo:0 192.168.239.250 broadcast 192.168.239.250 netmask 255.255.255.255 up
route add -host 192.168.239.250 dev lo:0

然后在两个RS节点上分别运行该脚本，运行效果如下：
高可用解决方案--keepalived
高可用解决方案--keepalived
到目前为止，客户端ping VIP-192.168.239.250，结果显示无法访问目标主机。说明ARP抑制已经实现。
高可用解决方案--keepalived
第三步：
配置keepalived的两个节点的配置文件 ，配置内容是在4、keepalived的主备模型和6、keepalived的状态切换时的消息通知机制的基础上增加virtual_server配置段来完成的。
主节点的配置文件内容：

! Configuration File for keepalived
global_defs {
    notification_email {
        root@localhost
}
    notification_email_from keepalived@localhost
    smtp_server 127.0.0.1
    smtp_connect_timeout 10
    router_id node1
    vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
    state MASTER
    interface eth1
    virtual_router_id 50
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111qwer
    }

    track_interface {
        eth1
    }

    notify_master "/etc/keepalived/notify.sh master"
    notify_backup "/etc/keepalived/notify.sh backup"
    notify_fault "/etc/keepalived/notify.sh fault"

    virtual_ipaddress {
        192.168.239.250/24 dev eth1
    }
}
# LVS配置段
virtual_server 192.168.239.250 80 {
    delay_loop 3
    lb_algo rr
    lb_kind DR
    protocol TCP
    sorry_server 127.0.0.1 80
    real_server 192.168.239.129 80 {
        weight 1
        HTTP_GET {
            url {
                path /index.html
                status 200
            }
            nb_get_retry 3
            delay_before_retry 2
            connect_ip 192.168.239.129
            connect_port 80
            bindto 192.168.239.137
            bind_port 80
            connnect_timeout 6
        }
    }
    real_server 192.168.239.133 80 {
        weight 1
        HTTP_GET {
            url {
                path /index.html
                status 200
            }
        nb_get_retry 3
        delay_before_retry 2
        connect_ip 192.168.239.133
        connect_port 80
        bindto 192.168.239.137
        bond_port 80
        connect_timeout 6
        }
    }
}

备节点的配置文件内容：

! Configuration File for keepalived
global_defs {
    notification_email {
        root@localhost
}
    notification_email_from keepalived@localhost
    smtp_server 127.0.0.1
    smtp_connect_timeout 10
    router_id node2
    vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
    state BACKUP
    interface eth1
    virtual_router_id 50
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111qwer
    }

    track_interface {
        eth1
    }

    notify_master "/etc/keepalived/notify.sh master"
    notify_backup "/etc/keepalived/notify.sh backup"
    notify_fault "/etc/keepalived/notify.sh fault"

    virtual_ipaddress {
        192.168.239.250/24 dev eth1
    }
}

virtual_server 192.168.239.250 80 {
    delay_loop 3
    lb_algo rr
    lb_kind DR
    protocol TCP
    sorry_server 127.0.0.1 80
    real_server 192.168.239.129 80 {
        weight 1
        HTTP_GET {
            url {
                path /index.html
                status 200
            }
            nb_get_retry 3
            delay_before_retry 2
            connect_ip 192.168.239.129
            connect_port 80
    # 发送检测消息的源地址和端口是调度器的真实IP，不是VIP
            bindto 192.168.239.138
            bind_port 80
            connnect_timeout 6
        }
    }
    real_server 192.168.239.133 80 {
        weight 1
        HTTP_GET {
            url {
                path /index.html
                status 200
            }
        nb_get_retry 3
        delay_before_retry 2
        connect_ip 192.168.239.133
        connect_port 80
        bindto 192.168.239.138
        bond_port 80
        connect_timeout 6
        }
    }
}

第四步：
配置整个集群中的备用节点，也即sorry_server参数，假设这样的场景，后端RS集群的每个节点都出现故障，这时候就需要备用节点返回响应内容。这里将sorry_server配置为keepalived的两个节点。因此在第三步的两个keepalived节点中设置sorryserver 127.0.0.1 80，并且两个备用节点都返回相同的页面内容“This web is maintaining”。
主节点的操作流程：

[root@Master ~]# yum -y install httpd
[root@Master ~]# vim /var/www/html/index.html 
This web is maintaining
[root@Master ~]# /etc/init.d/httpd start

备节点的操作流程：

[root@Backup ~]# yum -y install httpd
[root@Backup ~]# vim /var/www/html/index.html 
This web is maintaining
[root@Backup ~]# /etc/init.d/httpd start

效果图如下：
高可用解决方案--keepalived
高可用解决方案--keepalived
第五步：
接下来开启主备节点的keepalived服务。

[root@Master ~]# /etc/init.d/keepalived start
Starting keepalived:                                       [  OK  ]
[root@Backup ~]# /etc/init.d/keepalived start
Starting keepalived:                                       [  OK  ]

然后访问VIP地址，结果会返回后端RS的页面内容，并且每次刷新页面内容会发生变化。说明LVS的负载均衡已经实现。并且利用ipvsadm工具也可以查看到主备节点已经生成了ipvs规则。
高可用解决方案--keepalived
高可用解决方案--keepalived
第六步：
测试，暂停主节点的keepalived服务，浏览器能够继续返回页面内容，
高可用解决方案--keepalived
高可用解决方案--keepalived
现在暂停两个RS节点的http服务，然后继续访问VIP地址，结果返回是备用节点的信息。说明sorry_server已经实现。
高可用解决方案--keepalived

8、vrrp script实现特定服务的高可用

keepalived本身是由三个配置段组成的，分别是全局配置段、VRRP配置段和LVS配置段。VRRP配置段是用来实现IP地址（VIP）漂移的，LVS配置段是用来实现生成ipvs规则的。keepalived的基本功能仅此而已，总之keepalived的基本功能就是实现LVS的高可用，如果要实现特定服务的高可用功能，就需要借助脚本来实现。例如通过keepalived实现Nginx、Apache、mysql等特定服务的高可用，则需要编写相应的监控脚本。

脚本中priority和weight参数的关系

vrrp script在keepalived的配置文件的格式为：
vrrp_script check_server-name {
  script " ... "
  interval ...
  weight <+|-int>
}
check_script {
  check_server-name
}
其中集群中MASTER和BACKUP角色进行切换，是由priority和weight共同决定的。weight的绝对值一定为整数。
一、weight为正数（+int）：
① 脚本执行成功，MASTER节点的priority和int之和小于BACKUP节点的priority和int之和，则发生角色切换；
② 脚本执行失败，MASTER节点的priority和int之和大于BACKUP节点的priority和int之和，则不发生角色切换。
二、weight为负数（-int）：
① 脚本执行失败，MASTER节点的priority和int之差小于BACKUP节点的priority，则发生角色切换；
② 脚本执行成功，MASTER节点的priority和int之差大于BACKUP节点的priority，则不发生角色切换。
因此为了保证weight的值能够保证脚本在成功与失败后触发主备切换，通常设置weight的绝对值大于主备节点priority之差

vrrp script实现Apache的http服务高可用

实验环境：

主机名 IP地址 集群中的服务
Master.linux.com 192.168.239.137 http服务
Backup.linux.com 192.168.239.138 http服务
---- 192.168.239.250 虚拟IP

第一步：
配置两个节点的http服务，这里使用Apache，为了显示请求确实发生了跳转，将两个节点的http主页设置为不同的内容。
Master.linux.com节点的页面内容：

[root@Master ~]# cat /var/www/html/index.html 
This is web1

Backup.linux.com节点的页面内容：

[root@Backup ~]# cat /var/www/html/index.html 
This is web2

然后开启两个节点的http服务。
第二步：
配置两个节点的keepalived配置文件和脚本文件，脚本思路：原本主节点的权值为100，备节点的权值为90，各个节点每隔一秒监控各自的http服务是否正常，如果主节点的http服务发生异常，则权值减少20（即降低至80），这样80小于90，MASTER会变为权值90的节点。内容如下，
Master.linux.com：

! Configuration File for keepalived
global_defs {
    notification_email {
        root@localhost
}
    notification_email_from keepalived@localhost
    smtp_server 127.0.0.1
    smtp_connect_timeout 10
    router_id node1
    vrrp_mcast_group4 224.0.199.32
}
# 监控http服务的脚本
vrrp_script check_httpd {
# script "<脚本内容或者脚本文件>"
    script "killall -0 httpd"   # 检测httpd进程是否运行，这里前边的script参数比不可少
    interval 1   # 脚本运行一次的时间间隔
    weight -20 # httpd进程出现异常后，该节点keepalived的权值减少20，原本权值为100
}
vrrp_instance VI_1 {
    state MASTER
    interface eth1
    virtual_router_id 50
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111qwer
    }

    track_interface {
        eth1
    }

    track_script {
        check_httpd
    }

    virtual_ipaddress {
        192.168.239.250/24 dev eth1
    }
}

Backup.linux.com：

! Configuration File for keepalived
global_defs {
    notification_email {
        root@localhost
}
    notification_email_from keepalived@localhost
    smtp_server 127.0.0.1
    smtp_connect_timeout 10
    router_id node2
    vrrp_mcast_group4 224.0.199.32
}

vrrp_script check_httpd {
    script "killall -0 httpd"
    internal 1
    weight -20
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth1
    virtual_router_id 50
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111qwer
    }

    track_interface {
        eth1
    }

    track_script {
        check_httpd
    }

    virtual_ipaddress {
        192.168.239.250/24 dev eth1
    }
}

然后依次开启Master.linux.com和Backup.linux.com的keepalived服务。利用抓包工具tcpdump可以看到是主节点（权值100）在发送心跳信息。
高可用解决方案--keepalived
通过浏览器访问VIP，在会返回主节点的网页内容。
高可用解决方案--keepalived
第三步：
关闭主节点的http服务（注意是http服务，不是上面实验做的关闭keepalived服务），抓包工具可以看到主节点的权值降低为80，然后权值90的节点获得VIP进入MASTER状态。
高可用解决方案--keepalived
浏览器继续访问VIP，此时网页内容已经自动跳转到新的主节点（Backup.linux.com）。
高可用解决方案--keepalived
这样keepalived就可以实现Apache的高可用。

猜你喜欢

转载自blog.51cto.com/13570193/2161637
今日推荐
TIOBE 5 月榜单：Fortran “复活”进入 Top 10
GCC 14.1 发布
面壁智能发布 Eurux-8x22B 开源大模型 —— 堪称「理科状元」
开源日报 | 谷歌扶持鸿蒙上位；开源Rabbit R1；Docker加持的安卓手机；微软的焦虑和野心；海尔电器把开放平台关了
中国码农的“35岁魔咒”
蘭雅 CorelDRAW 插件 2024.5.1 国际劳动节版，免费下载
Arc Browser for Windows 1.0 正式 GA
90后程序员开发视频搬运软件、不到一年获利超 700 万，结局很刑！
周排行
Java自定义时间格式
同步整形电路
在开发中最最最常用的字符串的属性大集合
Linux 查看端口占用并杀掉
Java基础四：ArrayList
多线程之死锁就是这么简单
mysql 基础命令集
awk 命令详解
Centos6.3编译安装nginx+php步骤
OCR （Optical Character Recognition，光学字符识别）
每日归档
更多
2024-05-08(42)
2024-05-07(14)
2024-05-06(40)
2024-05-05(0)
2024-05-04(7)
2024-05-03(19)
2024-05-02(0)
2024-05-01(4)
2024-04-30(1)
2024-04-29(40)

代码天地 © 2018 codetd.com

境外服务器   最新电视剧2022