RedHat 7配置keepalived+LVS实现高可用的Web负载均衡

buser

　　上一篇博文中我们使用keepalived实现了haproxy的高可用，但keepalived问世之初却是为LVS而设计，与LVS高度整合，LVS与haproxy一样也是实现负载均衡，结合keepalived可以实现LVS的高可用架构，这一篇主要介绍RedHat 7配置keepalived+LVS实现高可用的Web负载均衡，架构图如下：

　　
　　一、测试环境

计算机名	操作系统	IP地址	VIP	安装的软件
RH7-LVS01	Redhat 7.2	192.168.10.31	192.168.10.30	ipvsadm 1.27、keepalived 1.2.13
RH7-LVS02	Redhat 7.2	192.168.10.32		ipvsadm 1.27、keepalived 1.2.13
RH7-Web-01	Redhat 7.2	192.168.10.33	——	Apache httpd 2.4
RH7-Web-02	Redhat 7.2	192.168.10.34	——	Apache httpd 2.4

　　

　　二、安装配置lvs与keepalived
1、分别在两台lvs服务器rh7-lvs01和rh7-lvs02上安装ipvsadm和keepalived
[root@rh7-lvs01 ~]# yum install ipvsadm keepalived -y

　　[root@rh7-lvs02 ~]# yum install ipvsadm keepalived -y

　　2、修改rh7-lvs01上的keepalived配置文件，按以下内容进行修改，将rh7-lvs01配置为MASTER节点，并设置LVS的负载均衡模式为DR模式
[root@rh7-lvs01 ~]# vi /etc/keepalived/keepalived.conf
! Configuration Filefor keepalived
global_defs {
   notification_email {
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_fromAlexandre.Cassen@firewall.loc
   smtp_server 192.168.200.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL
}
vrrp_instance VI_1 {
    state MASTER #MASTER
    interface eno16777736
    virtual_router_id 52
    priority 100 #必须比BACKUP的值大
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.10.30 #VIP
    }
}
virtual_server192.168.10.30 80 {
    delay_loop 6
    lb_algo rr #轮询算法
    lb_kind DR #DR模式
    #persistence_timeout 50
    protocol TCP
    real_server 192.168.10.33 80 {
        weight 1
            TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
    real_server 192.168.10.34 80 {
        weight 1
            TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}　　

　　3、修改rh7-lvs02上的keepalived配置文件，按以下内容进行修改，其实只有2处地方与主节点的配置文件不同，即state 要修改为Backup，priority数值要比master的小
[root@rh7-lvs02 ~]# vi /etc/keepalived/keepalived.conf
! Configuration Filefor keepalived
global_defs {
   notification_email {
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_fromAlexandre.Cassen@firewall.loc
   smtp_server 192.168.200.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL
}
vrrp_instance VI_1 {
    state BACKUP #BACKUP
    interface eno16777736
    virtual_router_id 52
    priority 90 #必须比MASTER的值小
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.10.30 #VIP
    }
}
virtual_server192.168.10.30 80 {
    delay_loop 6
    lb_algo rr #轮询算法
    lb_kind DR #DR模式
    #persistence_timeout 50
    protocol TCP
    real_server 192.168.10.33 80 {
        weight 1
            TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
    real_server 192.168.10.34 80 {
        weight 1
            TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}　　

　　4、在rh7-lvs01上设置keepalived开机自动启动，并启动keepalived服务
[root@rh7-lvs01 keepalived]# systemctl enable keepalived
[root@rh7-lvs01 keepalived]# systemctl start keepalived

　　

　　5、观察rh7-lvs01的日志可观察到keepalived启动后所发生的一连串动作，根据配置文件的参数进入了MASTER状态，并绑定了VIP地址
　　[root@rh7-lvs01 ~]#tail -f /var/log/messages

　　6、查看rh7-lvs01的IP地址，可以看到VIP已经绑定到网卡上

　　

　　7、在rh7-lvs02上设置keepalived开机自动启动，并启动keepalived服务
[root@rh7-lvs02 keepalived]# systemctl enable keepalived
[root@rh7-lvs02 keepalived]# systemctl start keepalived

　　

　　8、观察rh7-lvs02的日志可观察到keepalived启动后所发生的一连串动作，根据配置文件的参数进入了BACKUP状态

　　

　　9、查看rh7-lvs02的IP地址，可以看到VIP不在网卡上

　　

　　10、查看LVS的状态，可以看到VIP和两台Realserver的相关信息

　　

　　11、由于DR模式是后端两台realserver在响应请求时直接将数据包发给客户端，无需再经过LVS，这样减轻了LVS的负担、提高了效率，但由于LVS分发给realserver的数据包的目的地址是VIP地址，因此必须把VIP地址绑定到realserver的回环网卡lo上，否则realserver会认为该数据包不是发给自己因此会丢弃不作响应。另外由于网络接口都会进行ARP广播响应，因此当其他机器也有VIP地址时会发生冲突，故需要把realserver的lo接口的ARP响应关闭掉。我们可以用以下脚本来实现VIP绑定到lo接口和关闭ARP响应。

　　

　　12、执行该脚本设置该脚本开机自动执行，查看IP地址，发现lo接口已经绑定了VIP地址

　　

　　13、同理，在RH7-Web-02上也绑定了VIP地址到lo接口上

　　本文出自江健龙的技术博客 http://jiangjianlong.blog.运维网.com/3735273/1909031
　　

　　三、LVS负载均衡测试
　　1、在两台WEB上分别配置不同的默认页面，以方便区分访问到的是哪台WEB，从而看出负载均衡效果是否生效
　　2、使用浏览器访问VIP，先是访问到Web01，进行刷新，又访问到Web02,说明负载均衡已经生效

　　3、查看LVS的状态，可以看到两台realserver各有2个不活动的连接，说明按1：1权重的轮询也有生效，不活动连接是因为我们只是访问一个静态页面，访问过后很快就会处于不活动状态

　　本文出自江健龙的技术博客 http://jiangjianlong.blog.运维网.com/3735273/1909031
　　

　　四、Keepalived高可用测试
　　1、停止rh7-lvs01上的keepalived服务，再观察它的日志，可以发现其绑定的VIP被移除，两个realserver节点也被移除了
　　[root@rh7-lvs01 ~]# systemctl stop keepalived
　　[root@rh7-lvs01 ~]# tail -f /var/log/messages

　　

　　2、再看看rh7-lvs02的日志，再看看rh7-lvs02的日志，可以看到它立刻检测到主节点出现故障，马上将自己进入MASTER状态，同时接管了VIP，将VIP绑定到自己的网卡上，成功完成一次切换。
[root@rh7-lvs02 ~]# tail -f /var/log/messages

　　

　　3、使用浏览器访问一下VIP，依然正常负载均衡地成功访问，对用户来说并未觉察到VIP刚发生过一次漂移。

　　

　　4、再将rh7-lvs01的keepalived服务启动，通过日志可以看到它启动后进入了MASTER状态，把刚才rh7-lvs02刚绑定的VIP又夺了回去，谁叫它配置为MASTER呢，天生为主呀，然王侯将相宁有种乎，我们其实也可以在主节点的keepalived配置文件中增加nopreempt参数控制它不要强行夺占VIP
　　[root@rh7-lvs01 ~]# systemctl start keepalived
[root@rh7-lvs01 ~]# tail -f /var/log/messages

　　[root@rh7-lvs02 ~]# tail -f /var/log/messages

　　

　　五、keepalived故障监控测试
　　1、我们将web01的httpd服务停止，模拟web01出现故障不能提供web服务，测试keepalived能否及时监控到并将web01从LVS中剔除，不再分发请求给web01，防止用户访问到故障的web服务器
　　[root@RH7-Web-01 ~]# systemctl stop httpd
　　

　　2、通过查看rh7-lvs01的日志可以看到keepalived检查到web01的80端口失败，于是将它从群集中移除，并尝试通过SMTP服务器发送邮件，由于我没配SMTP服务器因此连接失败报了错误
　　[root@rh7-lvs01 ~]# tail -f /var/log/messages

　　

　　3、通过查看rh7-lvs02的日志发现它作为备机也是触发了相同的操作，说明备机也是时刻在监控着后端realserver的健康状态
　　[root@rh7-lvs012~]# tail -f /var/log/messages

　　

　　4、分别在rh7-lvs01和rh7-lvs02上查看LVS的状态，可以看到确实都移除了故障的web节点

　　5、再把web01的httpd服务启动
[root@RH7-Web-01 ~]# systemctl start httpd
　　

　　6、通过rh7-lvs01和rh7-lvs02的日志可以看到它们监控到web01的80端口已成功连接，便再次把web01加入到LVS中去，这个监控的方法可以是检测端口，也可以检测URL等其他方法，具体取决于keepalived配置文件中的参数设置。
　　[root@rh7-lvs01 ~]# tail -f /var/log/messages

　　[root@rh7-lvs02 ~]# tail -f /var/log/messages

　　

　　7、分别在rh7-lvs01和rh7-lvs02上查看LVS的状态，可以看到确实都把web01节点又加了进来

　　本文出自江健龙的技术博客 http://jiangjianlong.blog.运维网.com/3735273/1909031