设为首页 收藏本站
查看: 1568|回复: 0

[经验分享] 高可用解决方案

[复制链接]

尚未签到

发表于 2018-12-29 08:31:50 | 显示全部楼层 |阅读模式
  高可用指标=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的核心组件

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  ]
  查看主节点的日志信息

查看备节点的日志信息

利用命令ip a查看主节点的ip状态,可以看到VIP已经配置到了eth1网卡上

备节点因为处于BACKUP状态,则没有获得VIP。

arp 192.168.239.250命令也可以看出VIP的MAC地址为主节点eth1网卡的MAC地址。

现在将主节点中的keepalived.conf中的优先级参数设置为80(低于备节点),然后重启主节点的keepalived服务。再次查看IP状态和ARP缓存表信息。


并且VIP对应的MAC地址也发生了变化。说明IP漂移已经实现。


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信息:

节点2的VIP2信息:

当节点1的keepalived停止,节点1的VIP移除,效果如下:

节点2获得两个VIP,如图:


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的FAULT状态,该状态与keepalived监控的网络接口有关,如果节点的网卡出现故障,则keepalived会进入FAULT状态,暂停主节点的网卡,然后系统会受到通知邮件,如下图,通知keepalived进入FAULT状态。

[root@Master ~]# ifdown eth1


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服务配置成功。


第二步:
该实验中基于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节点上分别运行该脚本,运行效果如下:


到目前为止,客户端ping VIP-192.168.239.250,结果显示无法访问目标主机。说明ARP抑制已经实现。

第三步:
配置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服务。

[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服务,浏览器能够继续返回页面内容,


现在暂停两个RS节点的http服务,然后继续访问VIP地址,结果返回是备用节点的信息。说明sorry_server已经实现。


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
}
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)在发送心跳信息。

通过浏览器访问VIP,在会返回主节点的网页内容。

第三步:
关闭主节点的http服务(注意是http服务,不是上面实验做的关闭keepalived服务),抓包工具可以看到主节点的权值降低为80,然后权值90的节点获得VIP进入MASTER状态。

浏览器继续访问VIP,此时网页内容已经自动跳转到新的主节点(Backup.linux.com)。

这样keepalived就可以实现Apache的高可用。




运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-657036-1-1.html 上篇帖子: LVS+Keepalived负载均衡高可用如此简单? 下篇帖子: LVS+KeepAlived,搭建MySQL高可用负载均衡
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表