基于keepalived构建 LVS-DR的主主模型（二）

 一、 理论部分：

keepalived通过虚拟路由器、主路由器、虚拟IP、虚拟MAC的方式来完成一个虚拟路由器的管理；在vrrp当中有很多术语，这些术语描述了一个vrrp的工作过程；在vrrp的工作模式当中常见的有：

主/备    主/主(主/备，备/主)，

（1） vrrp_script：能够自定义一个资源监控脚本；这个脚本可以作为vrrp实例当中去追踪作为其优先级高低判断或计算的一个基本标准；

通过vrrp实例或进程能根据脚本状态返回值来判定这个服务是成功的还是失败的基本依据；并且能够在脚本执行成功时，使得相应的节点的优先级提升，或者，在失败时使得相应的节点的优先级通过计算以后降低；降低到什么程度？

比如对于一个主节点来讲我可以运行两个资源，第一，是定义在网卡上的IP地址，第二，是我们所监控的一个nginx服务，我们不断的通过一个脚本去探测nginx所监听的80端口，或者是nginx中的某个资源是否能够正常访问，如果能够正常访问的话，那就一切不动，如果发现nginx服务访问不了的时候，它就会尝试着借助于在vrrp实例当中有一个track_script（追踪脚本），根据track_script中的定义，是的我们当前节点的优先级减去一个数值；减得以后的结果会低于BACKUP节点，因此这样子，他在向外通告时，通告的优先级就低于BACKUP节点，所以这时候BACKUP节点就会取而代之；

公共定义，可被多个实例调用，因此，vrrp_script定义在vrrp实例之外；

（2）track_script：跟踪脚本；调用vrrp_script定义的脚本去监控资源；还能够在监控的过程当中，一旦发现脚本成功了，能够使得优先级升高，失败了，就能够使得优先级降低，从而完成向外通告时，通告一个较高的优先级，或较低的优先级，完成所谓的节点角色转换。

track_script定义在实例之内，调用事先定义好的vrrp_script；

 使用实例1：要在实例之外定义chk_down,在实例之内调用chk_down;

vrrp_script chk_dowm{

script "[[ -f /etc/keepalived/down ]] && exit 1 || exit 0"    ##判断/etc/keepalived/目录下是否由down文件，如果有就退出；

interval 2                   ##每隔多久检测一次；

weight -5                    ##检测失败时把权重降低5，检测成功，权重不变；

}

track_script {

chk_down

}

使用实例2：如果监控服务具体的进程；

vrrp_script chk_httpd {

script "killall -0 httpd"

interval 2

weight -5

}

track_script {           ##如果有多个脚本一同使用的话在track_script添加多个脚本的调用即可；

chk_httpd

}

二、keepalived构建 LVS-DR的主主模型

拓扑：

环境：

Name ip address
主： VIP：172.18.200.6
备： VIP：172.18.100.5
Real Server1
VIP(1)：172.18.200.6/32

VIP(2)：172.18.200.5/32

RIP：172.18.100.100/16
Real Server2
VIP(1)：172.18.200.6/32

VIP(2)：172.18.200.5/32

RIP：172.18.100.110/16

操作步骤：

（1）各节点时间同步；

##yum -y install keepalived #前端两台主机都要安装；

##ntpdate 172.18.0.1        #同步时间； 两个节点都要同步；

##crontab -e       #创建计划任务，每5分钟同步一次时间；  两个节点都要同步；

*/5 * * * * /usr/sbin/ntpdate 172.18.0.1 &> /dev/null

（2）确保iptables及selinux不会阻碍;

(3)定义俩节点配置，并启动之；

在主节点上面修改配置文件：

#vim /etv/keepalived/keepalived.conf

! Configuration File for keepalived
global_defs {
   notification_email {
       [email protected]
   }
   notification_email_from [email protected]
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id node1
   vrrp_mcast_group4 224.0.100.18
}
vrrp_script chk_down {
    script "[[ -f /etc/keepalived/down ]] && exit 1 || exit 0"
    interval 2 
    weight 5
}
vrrp_script chk_httpd {
    script "killall -0 httpd"
    interval 2 
    weight -5
}
vrrp_instance VI_1 {
    state MASTER
    interface eno16777736 
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass pBkfC1ax 
    }
    virtual_ipaddress {
    172.18.200.6 dev eno16777736 label eno16777736:0
    }
    track_script {
    chk_down
    }
    notify_master "/etc/keepalived/notify.sh master"    
    notify_backup "/etc/keepalived/notify.sh backup"
    notify_fault "/etc/keepalived/notify.sh fault"
}
vrrp_instance VI_2 {                
    state BACKUP
    interface eno16777736
    virtual_router_id 60
    priority 98
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass pBkfC1ab
    }
    virtual_ipaddress {
        172.18.200.5 dev eno16777736 label eno16777736:1
    }
    track_script {
        chk_down
    }
    notify_master "/etc/keepalived/notify.sh master"
    notify_backup "/etc/keepalived/notify.sh backup"
    notify_fault "/etc/keepalived/notify.sh fault"
}
virtual_server 172.18.200.6 80 {
    delay_loop 6
    lb_algo wlc
    lb_kind DR
    protocol TCP
    sorry_server 127.0.0.1 80
    real_server 172.18.200.100 80 {
        weight 1
        HTTP_GET {
            url {
            path /
            status_code 200
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
    real_server 172.18.200.110 80 {
        weight 2
        HTTP_GET {
            url {
            path /
            status_code 200
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}
virtual_server 172.18.200.5 80 {
    delay_loop 6
    lb_algo wlc
    lb_kind DR
    protocol TCP
    sorry_server 127.0.0.1 80
    real_server 172.18.200.100 80 {
        weight 1
        HTTP_GET {
            url {
            path /
            status_code 200
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
    real_server 172.18.200.110 80 {
        weight 2
        HTTP_GET {
            url {
            path /
            status_code 200
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

在主节点上面修改配置文件：

#vim /etv/keepalived/keepalived.conf

! Configuration File for keepalived
global_defs {
   notification_email {
       [email protected]
   }
   notification_email_from [email protected]
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id node1
   vrrp_mcast_group4 224.0.100.18
}
vrrp_script chk_down {
    script "[[ -f /etc/keepalived/down ]] && exit 1 || exit 0"
    interval 2 
    weight 5
}
vrrp_script chk_httpd {
    script "killall -0 httpd"
    interval 2 
    weight -5
}
vrrp_instance VI_1 {
    state BACKUP 
    interface eno16777736 
    virtual_router_id 51
    priority 98
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass pBkfC1ax 
    }
    virtual_ipaddress {
    172.18.200.6 dev eno16777736 label eno16777736:0
    }
    track_script {
    chk_down
    }
    notify_master "/etc/keepalived/notify.sh master"    
    notify_backup "/etc/keepalived/notify.sh backup"
    notify_fault "/etc/keepalived/notify.sh fault"
}
vrrp_instance VI_2 {
    state MASTER
    interface eno16777736
    virtual_router_id 60
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass pBkfC1ab
    }
    virtual_ipaddress {
        172.18.200.5 dev eno16777736 label eno16777736:1
    }
    track_script {
        chk_down
    }
    notify_master "/etc/keepalived/notify.sh master"
    notify_backup "/etc/keepalived/notify.sh backup"
    notify_fault "/etc/keepalived/notify.sh fault"
}
virtual_server 172.18.200.6 80 {
    delay_loop 6
    lb_algo wlc
    lb_kind DR
    protocol TCP
    sorry_server 127.0.0.1 80
    real_server 172.18.200.100 80 {
        weight 1
        HTTP_GET {
            url {
            path /
            status_code 200
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
    real_server 172.18.200.110 80 {
        weight 2
        HTTP_GET {
            url {
            path /
            status_code 200
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}
virtual_server 172.18.200.5 80 {
    delay_loop 6
    lb_algo wlc
    lb_kind DR
    protocol TCP
    sorry_server 127.0.0.1 80
    real_server 172.18.200.100 80 {
        weight 1
        HTTP_GET {
            url {
            path /
            status_code 200
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
    real_server 172.18.200.110 80 {
        weight 2
        HTTP_GET {
            url {
            path /
            status_code 200
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

##systemctl start keepalived.servcie

测试一下：

主节点：


            备节点：

(4)在Real Server上配置：

在各real server节点上添加VIP：

#ifconfig lo:0 172.18.200.6 netmask 255.255.255.255 broadcast 172.18.200.6

#ifconfig lo:1 172.18.200.5 netmask 255.255.255.255 broadcast 172.18.200.5

# route add -host 172.18.200.6 dev lo:0

# route add -host 172.18.200.5 dev lo:1

限制响应级别和通告级别：

#echo 1> /proc/sys/net/ipv4/conf/all/arp_ignore

#echo 1> /proc/sys/net/ipv4/conf/lo/arp_ignore

#echo 2> /proc/sys/net/ipv4/conf/all/arp_announce

#echo 2> /proc/sys/net/ipv4/conf/lo/arp_announce

(5)测试

写的不好之处请各路大神多多指点，互相交流学习！

下一遍聊聊运维自动化工具之一：Ansible  （待续......）

时间： 2024-08-23 23:29:10

基于keepalived构建 LVS-DR的主主模型（二）的相关文章

基于Keepalived实现LVS双主高可用集群

前言 前面说过基于heartbeat的LVS高可用方案,今天带来另一种解决方案:基于Keepalived实现LVS双主高可用集群.什么是Keepalived呢,keepalived观其名可知,保持存活,在网络里面就是保持在线了, 也就是所谓的高可用或热备,用来防止单点故障的发生.本文将详细讲述Keepalived工作原理及高可用解决方案的实现. 相关介绍 Keepalived简介 Keepalived采用VRRP(virtual router redundancy protocol,虚拟路由冗余

基于Keepalived构建高可用集群配置实例（HA Cluster）

什么是集群 简单的讲集群(cluster)就是一组计算机,它们作为一个整体向用户提供一组网络资源.这些单个的计算机系统就是集群的节点(node).一个理想的集群是,用户从来不会意识到集群系统底层的节点,在他/她们看来,集群是一个系统,而非多个计算机系统.并且集群系统的管理员可以随意增加和删改集群系统的节点. 关于更详细的高可用集群我们在后面再做详解,先来说说Keepalived Keepalived是什么 Keepalived是集群管理中保证集群高可用的一个服务软件,其功能类似于heartbea

基于keepalived实现LVS的高可用

keepalived简介 首先简单介绍一下VRRP协议(虚拟路由器冗余协议).VRRP是一种容错协议,它可以将一组路由器组织成一个虚拟路由器,这个虚拟路由器仅适用一个IP地址,这个IP地址配置在其中的一台路由器上,这个路由器即为主路由器(MASTER),其余的为备用路由器(BACKUP).如果这个路由器组内的MASTER路由器出现故障了,BACKUP路由器将会通过选举策略选出一个新的MASTER路由器继续向外提供服务.这样就保证了网络之间的通信不会中断. keepalived即采用了VRRP协议

构建LVS+Keepalived高可用群集

防伪码:不必向我诉说春天,我的心里并没有秋寒 第六章 构建LVS+Keepalived高可用群集 前言:keeplived是专门针对LVS设计的一款辅助工具,主要功能是实现故障切换和健康检查,官方网站:http://www.keepalived.org.类似于我们以前学习过的HSRP热备份路由协议,HSRP是思科的私有协议,而VRRP是通用协议,都是为了实现故障切换,当一台路由器发生故障的时候,另一台马上接替工作,用户感觉不到服务器发生了问题,而且不会中断服务.我们今天学习的双机热备是就是利用了

keepalived+LVS/DR

keepalived 是解决单故障节点的软件1. keepalived+LVS/DR2. 任意单故障节点 的 高可用作 分发器 的 高可用用 keepalived 作 LVS/DR 模式 分发器 的 高可用实验拓扑clientnode1主.node2备webA .webB 浮动资源有: 浮动ip.策略 IP 规划client 192.168.4.254node1 192.168.4.50node2 192.168.4.55浮动ip(vip) 192.168.4.252webA 192.168.4

HA集群之keepalived详解/基于keepalived+LVS-DR构建HA主备模型（一）

一.理论部分:     keepalived是vrrp协议的实现:原生设计目的为高可用ipvs服务:keepalived能够配置文件中的定义生成ipvs规则:并能够对各RealServer的健康状态进行检测:  vrrp协议:虚拟冗余路由协议:早期只是主要在路由器上提供的一种非常简单的完成将多个物理设备组建成一个虚拟设备,并且在多个物理设备之间漂移地址一种协议:非常轻量化,性能非常好.而keepalived无非就是通过vrrp协议在Linux主机上通过一个守护进程,把Linux主机扮演成路由器,

MySQL 主主复制 + LVS + Keepalived 实现 MySQL 高可用性

MySQL复制能够保证数据的冗余的同时可以做读写分离来分担系统压力,如果是主主复制还可以很好的避免主节点的单点故障.但是MySQL主主复制存在一些问题无法满足我们的实际需要:未提供统一访问入口来实现负载均衡,如果其中master宕掉的话需要手动切换到另外一个master,而不能自动进行切换. 这篇文章下面要介绍如何通过LVS+Keepalived的方式来是实现MySQL的高可用性,同时解决以上问题. Keepalived和LVS介绍 Keepalived是一个基于VRRP(虚拟路由冗余协议)可用

MySQL主主复制+LVS+Keepalived实现MySQL高可用性

MySQL主主复制+LVS+Keepalived实现MySQL高可用性 MySQL复制能够保证数据的冗余的同时可以做读写分离来分担系统压力,如果是主主复制还可以很好的避免主节点的单点故障.但是MySQL主主复制存在一些问题无法满足我们的实际需要:未提供统一访问入口来实现负载均衡,如果其中master宕掉的话需要手动切换到另外一个master,而不能自动进行切换. 这篇文章下面要介绍如何通过LVS+Keepalived的方式来是实现MySQL的高可用性,同时解决以上问题. Keepalived和L

keepAlived+nginx实现高可用双主模型LVS

实验目的: 利用keepalived实现高可用反向代理的nginx.以及双主模型的ipvs 实验环境: node1:在nginx做代理时做反向代理节点,在keepalived实现LVS时做Director.VIP1:172.16.18.22 VIP2:172.16.18.23 node2:在nginx做代理时做反向代理节点,在keepalived实现LVS时做Director.VIP1:172.16.18.22 VIP2:172.16.18.23 node3:在nginx做代理时做web服务器.