单主的 LVS-DR 模式(基于ip+port集群)、单主的 LVS-DR 模式(基于FWM集群、单主的Nginx反向代理高可用

单主的 LVS-DR 模式(基于ip+port集群)架构图：

 

 

 

 

思路简述：
通过Keepalive和Lvs(DR模式)的结合实现LVS的高可用,图为单主架构因此只创建一个VIP10.0.0.100对外提供访问即可,10.0.0.200和10.0.0.201分别作为Keepalive的MASTER和BAKCUP节点,而Keepalive集成LVS因此以VIP去创建服务集群将10.0.0.10、10.0.0.20作为RS纳入到服务集群中。

个别软件作用：
MASTER和BAKCUP
1）Nginx：配置道歉页面,充当sorry_server当RS全宕机后将访问本节点的道歉页面。
2）ipvsadm：只MASTER安装,当配置基本完成后用来观测集群服务信息。

软件路径：
Keepalive安装路径：/usr/local/keepalive
Keepalive配置文件路径：/etc/keepalive/keepalived.conf
Keepalive子配置文件目录路径：/etc/keepalive/conf.d
Nginx统一路径：/apps/nginx
注：软件安装流程省略

1.全局配置 配置
1）MASTER：MASTER和BAKCUP的配置相差不多,MASTER该完后可以远程发送给BAKCUP再进行些许修改。

cat /etc/keepalived/keepalived.conf 

! Configuration File for keepalived
  
global_defs {
   notification_email {
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 192.168.200.1
   smtp_connect_timeout 30
   router_id node1.qinglin.com   #修改处：自定义为主机名或域名。
   vrrp_skip_check_adv_addr
   #vrrp_strict
   #vrrp_garp_interval 0
   #vrrp_gna_interval 0
   vrrp_mcast_group4 233.6.6.6   #修改处：组播地址,用于状态是MASTER的节点发送相关信息给状态是BAKCUP的节点(如健康信息等)
}

include /etc/keepalived/conf.d/*.conf   #增加处：定义包含子配置文件的目录,VIP和LVS的配置一般作为子配置文件单独建立。好处：便于管理。

2）BAKCUP：

cat /etc/keepalived/keepalived.conf 

! Configuration File for keepalived
  
global_defs {
   notification_email {
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 192.168.200.1
   smtp_connect_timeout 30
   router_id node2.qinglin.com   #修改处：自定义为主机名或域名。
   vrrp_skip_check_adv_addr
   #vrrp_strict
   #vrrp_garp_interval 0
   #vrrp_gna_interval 0
   vrrp_mcast_group4 233.6.6.6   #修改处：组播地址,用于状态是MASTER的节点发送相关信息给状态是BAKCUP的节点(如健康信息等)
}

include /etc/keepalived/conf.d/*.conf   #增加处：定义包含子配置文件的目录,VIP和LVS的配置一般作为子配置文件单独建立。好处：便于管理。

2.虚拟路由器配置(创建VIP)
1）MASTER

cat /etc/keepalived/conf.d/vip_nginx.conf 

vrrp_instance VI_1 {     #修改处：实例名称,每个实例一个独有的名称
    state MASTER         #修改处：此项决定模式,延时抢占式、非抢占式此项都必须为BAKCUP,生产中模式推荐：延时抢占式>抢占式>非抢占式。当前为测试环境因此MASTER节点此项设置MASTER。细节不说
    interface eth0       #修改处：绑定为当前虚拟路由器使用的物理接口，如：eth0,bond0,br0,可以和VIP不在一个网卡
    virtual_router_id 50 #修改处：虚拟路由ID，每一个实例一个虚拟路由ID不可与其他实例冲突。
    priority 100         #修改处：优先级，此项才是真正决定初始启动时,节点状态为MASTER还是BAKCUP,值越高优先级越高
    advert_int 1
    authentication {
        auth_type PASS   #修改处：明文密码：实例间建立练习的密码。
        auth_pass 1111
    }
    virtual_ipaddress {
        10.0.0.100/24 dev eth0 label eth0:1   #修改处：VIP：指定VIP浮动的网卡并打上标签，以便区分
    }
}

notify_master "/etc/keepalived/notify.sh master"  #通过Keepalive的节点状态监测功能,当前节点倘若发生变化则向脚本进行传参,根据脚本逻辑执行某些命令、功能(此案例用不上)
notify_backup "/etc/keepalived/notify.sh backup"
notify_fault "/etc/keepalived/notify.sh fault"

2）BACKUP,从MASTER拷贝过来,修改priority即可。

cat /etc/keepalived/conf.d/vip_nginx.conf 

vrrp_instance VI_1 {     #修改处：实例名称,每个实例一个独有的名称
    state BAKCUP         #修改处：抢占式的BACKUP节点设置为BACKUP
    interface eth0       #修改处：绑定为当前虚拟路由器使用的物理接口，如：eth0,bond0,br0,可以和VIP不在一个网卡
    virtual_router_id 50 #修改处：虚拟路由ID，每一个实例一个虚拟路由ID不可与其他实例冲突。
    priority 80          #修改处：优先级，此项才是真正决定初始启动时,节点状态为MASTER还是BAKCUP,值越高优先级越高(低于MASTER)
    advert_int 1
    authentication {
        auth_type PASS   #修改处：明文密码：实例间建立练习的密码。
        auth_pass 1111
    }
    virtual_ipaddress {
        10.0.0.100/24 dev eth0 label eth0:1   #修改处：VIP：指定VIP浮动的网卡并打上标签，以便区分
    }


notify_master "/etc/keepalived/notify.sh master"  #通过Keepalive的节点状态监测功能,当前节点倘若发生变化则向脚本进行传参,根据脚本逻辑执行某些命令、功能(此案例用不上)
notify_backup "/etc/keepalived/notify.sh backup"
notify_fault "/etc/keepalived/notify.sh fault"

}

测试VIP的可用性：
1）启动Keepalive服务后的VIP：10.0.0.100归属为MASTER(正常)

2）关闭keepalive服务模拟MASTER节点故障,看VIP是否切换到BAKCUP的eth0网卡上(成功)

3）MASTER节点重启Keepalive服务后VIP又浮动MASTER上说明：1.MASTER优先级高于BACKUP 2.当前模式为抢占式。

3.配置RS：10.0.0.10、10.0.0.20。
1）因为LVS服务集群采用DR模式,因此RS上需配置VIP使RS处理完请求后的响应报文src为VIP能够被Client接收。(建议写成脚本)

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore #降低VIP的应答级别和ARP广播等
    
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

ip a a 10.0.0.100/32 dev lo label lo:1   #创建VIP,32位掩码单独一个网段设置在lo网卡并打标签

注:在实际组网中,RS的GW需指向路由器,让响应报文直接通过路由发送给Client,这也是DR模式的优势所在：降低响应报文原路返回VS对LVS的负载)。
2）将index.html页面修改以便后面测试,修改前记得备份

cat /apps/nginx/html/index.html

1）10.0.0.10

2）10.0.0.20

4.基于VIP：10.0.0.100配置LVS的集群服务
1）MASTER和BAKCUP：LVS服务集群的配置文件一样

cat /etc/keepalived/conf.d/lvs_nginx.conf

virtual_server 10.0.0.100 80 {   #修改处：基于虚拟路由器的VIP创建服务集群
    delay_loop 3
    lb_algo rr                   #修改处：调度算法
    lb_kind DR                   #RS的工作模式
    protocol TCP                 
    sorry_server 127.0.0.1 80    #修改处：道歉服务器,也会加入到服务集群中,因此需指向本节点(带有VIP),如果指向其他地址需配置VIP否则Client会因相应报文的src不是VIP而拒绝。
real_server 10.0.0.10 80 {       #修改处：加入集群的RS服务器
    weight 1                     #修改处：权重：性能高的服务器一般权重设置高点
    HTTP_GET {                   #修改处：七层健康性检查,检测RS的URL路径是否可达
    url {
    path /index.html
    status_code 200
 }
    connect_timeout 1
    nb_get_retry 3
    delay_before_retry 1
 }
}
real_server 10.0.0.20 80 {      #RS服务器地址及端口,注：DR模式请求是二层转发个RS之所以要添加端口是用于健康性检查(如四层的TCP检查)
    weight 1
    HTTP_GET {
    url {
    path /index.html
    status_code 200
 }
    connect_timeout 1
    nb_get_retry 3
    delay_before_retry 1
  }
 }
}

5.MASTER和BAKCUP都需配置sorry_server(道歉服务器),修改index.html文件。

至此基本配置完成~

测试环节：
第一步：当客户机访问VIP时能否调度请求到RS。 

while true;do curl 10.0.0.100;sleep 0.5;done

 

结果：成功！且权重也确为设置的 1:1
第二步：在测试过程将MASTER上Keepalive服务关闭查看是否会影响访问。
1）MASTER状态

2）BACKUP状态,VIP成功切换。

3）测试过程,循环访问依旧能够进行(正常)。

第三步：模拟RS全部宕机,看请求是否调度到sorry_server上且显示道歉页面。
1)RS服务状态

2）可以看到访问过程已显示道歉页面说明,sorry_server应用成功


👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇

👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇
👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇
单主的 LVS-DR 模式(基于FWM集群)：
思路简述：实现单主的 LVS-DR 模式，利用FWM绑定成多个服务为一个集群服务。

防火墙标签的作用：通常web服务会添加ssl进行加密(https)而用户一般通过http或https访问web服务，这样一来VIP对外提供服务的VIP端口要设置两个分别为80和443(即要创建两个服务集群),而防火墙标签则可通过与防火墙规则的配合使指定的连接请求打上标签并让其通过,再利用LVS将请求调度到RS中.

注：配置与单主的 LVS-DR 模式(基于ip+port集群)基本上差不多：

1.修改将虚拟服务器配置(LVS集群),将类型改为FWM(基于防火墙标签创建LVS集群)。
MASTER和BAKCUP：在上个案例的基础上仅修改FWM即可

cat lvs_nginx.conf
virtual_server fwmark 50 {   #修改处：防火墙标签(自定义)
    delay_loop 3
    lb_algo rr
    lb_kind DR
    protocol TCP
    sorry_server 127.0.0.1 80
real_server 10.0.0.10 80 {
    weight 1
    HTTP_GET {
    url {
    path /index.html
    status_code 200
 }
    connect_timeout 1
    nb_get_retry 3
    delay_before_retry 1
 }
}
real_server 10.0.0.20 80 {
    weight 1
    HTTP_GET {
    url {
    path /index.html
    status_code 200
 }
    connect_timeout 1
    nb_get_retry 3
    delay_before_retry 1
  }
 }
}

注意：端口需指定,此类型有BUF,端口用于健康检查。

2.添加防火墙规则
MASTER和BAKCUP：

iptables -t mangle -A PREROUTING -d 10.0.0.100 -p tcp -m multiport --dports 80,443 -j MARK --set-mark 50

解读：在PREROUTING链将dst为VIP、传输协议为TCP、目的端口为80、443的连接请求通过并打上50这个防火墙标记(与FWM一致),配合LVS集群服务调度。

3.循环测试：重启keepalive服务后调度成功~

注：其他测试方法与上个案例相同不做演示。

👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇

👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇
👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇👇

 

实现单主模式的Nginx反向代理的高可用：
简述思路：
1）Keepalive+Nginx结合,Nginx自身具备反向代理功能且对RS拥有健康性检查功能因此不需要配置LVS集群。
2）创建VRRP脚本：Keepalive默认关注的是自身节点的状态实现VIP浮动,而实际工作场景中Keepalive与应用服务的结合之后是根据应用服务的状态去实现VIP浮动而不是Keepalive本身,因此需要定义VRRP脚本让Keepalive基于应用服务状态去进行VIP浮动。

还原下环境：
1）将RS：10.0.0.10、10.0.0.20的VIP清除。

bash dr_vip_conf.sh stop
#!/bin/bash
vip=10.0.0.10
dev=lo

case $1 in
start)
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
  ip a a $vip/32 dev $dev label $dev:1
#route add -host $vip dev $dev

echo "The RS Server is Ready!"
  ;;
stop)
ip a del $vip/32 dev $dev label $dev:1
echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 0 > /proc/sys/net/ipv4/conf/lo/arp_announce
echo "The RS Server is Canceled!"
  ;;
*) 
echo "Usage: $(basename $0) start|stop"
exit 1
  ;;
esac

2）将MASTER和BAKCUP将之前案例创建的虚拟服务器(LVS)集群配置文件清除掉。注：VIP仍旧保留

rm -rf /etc/keepalived/conf.d/lvs_nginx.conf

 

1.Nginx配置文件中创建负载均衡集群实现反代。
MASTER和BACKUP：

vim /apps/nginx/conf/nginx.conf

http {
     upstream websrvs {   #在http语句块下通过upstream语句块创建服务集群,websrvs为集群名称。
     server 10.0.0.10:80 weight=1;
     server 10.0.0.20:80 weight=1;
 }
 server {
    listen 80;
    location / {
       proxy_pass http://websrvs/;   #修改处：将所有请求调度到服务集群
  }
 }
}

2.配置VRRP脚本,实现应用服务的监控
1）全局配置中定义VRRP脚本

vrrp_script check_nginx {   #修改处：check_nginx为自定义的脚本名称,调用名称即调用脚本
   script "/etc/keepalived/check_nginx.sh"   #修改处：实际检查Nginx服务的脚本路径
   interval 1
   weight -30    #修改处：权重为负数时，脚本中用于检测服务的命令执行如果为非0则会减30优先级。
   fall 3        #脚本中命令连续执行失败的次数,达到该次数后视为fall触发权重机制。
   rise 5        #脚本中命令连续执行成功的次数,达到该次数后节点的优先级会恢复原先。
   timeout 2
}

2）编写检测Nginx服务的脚本命令

cat /etc/keepalived/check_nginx.sh
#!/bin/bash
/usr/bin/killall -0 nginx   #修改处：killall需安装

chmod a+x /etc/keepalived/check_nginx.sh #增加执行权限

3）在虚拟路由器实例中通过名称调用VRRP脚本
MASTER和BAKCUP：

vim /etc/keepalived/conf.d/vip_nginx.conf

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 50
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        10.0.0.100/24 dev eth0 label eth0:1
    }

track_script {   #增加处：调用VRRP脚本
 check_nginx
}

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

4）重启MASTER和BAKCUP节点的Keepalive、Nginx服务使得配置生效。

测试环节：
1.Client访问VIP：10.0.0.100看请求是否能够被调度RS服务器上(根据反馈的测试页面结果可以判断Nginx反代成功将用户请求调度到后端的RS服务器上且权重确为设定的1:1)

2.此时的VIP浮动在MASTER上,模拟Nginx崩溃(stop nginx),测试VRRP脚本是否生效。
1）关闭Nginx服务

 

2）关闭Nginx后,可以看到VIP切换到了BAKCUP且客户端访问正常>

 

3.为VRRP脚本增加故障自愈命令,当监测到Nginx进程不存在时,自动重启Nginx服务。
MASTER和BAKCUP：

vim /etc/keepalived/check_nginx.sh
#!/bin/bash
/usr/bin/killall -0 nginx || systemctl restart nginx   #增加处：重启Nginx代码

测试：
1）增加重启代码后Keepalive会执行此脚本,根据脚本逻辑重启之前MASTER节点关闭掉的Nginx服务,届时状态为rise而MASTER优先级恢复原先再次将VIP抢占过来。
效果：

2）当MASTER再次关闭Nginx服务也会自动重启Nginx服务,VIP也不在浮动到BACKUP上且Client继续稳定访问。