架构设计:负载均衡层设计方案(6)——Nginx + Keepalived构建高可用的负载层

时间:2023-03-08 15:23:44
架构设计:负载均衡层设计方案(6)——Nginx + Keepalived构建高可用的负载层

1、概述

前两遍文章中,我们一直在说后文要介绍Nginx + Keepalived的搭建方式。这篇文章开始,我们就来兑现前文的承诺,后续的两篇文章我们将介绍Nginx + Keepalived和 LVS + Keepalived搭建高可用的负载层系统。如果你还不了解Nginx和LVS的相关知识,请参见我之前的两篇文章《架构设计:负载均衡层设计方案(2)——Nginx安装》(http://blog.csdn.net/yinwenjie/article/details/46620711)、《架构设计:负载均衡层设计方案(4)——LVS原理》(http://blog.csdn.net/yinwenjie/article/details/46845997

2、准备工作

2.1、准备两*立工作的Nginx系统

准备两台Nginx的主机,如果您不知道为什么需要准备两台,没关系,准备就行。保证两台Nginx主机能够被外网访问。在我这里,安装两台Nginx的虚拟机IP地址分别是:

  • Nginx VM1:192.168.61.129:80
  • Nginx VM2:192.168.61.130:80

访问相关的地址,确保两台Nginx都是可用的:

  • VM1: 
    架构设计:负载均衡层设计方案(6)——Nginx + Keepalived构建高可用的负载层

  • VM2: 
    架构设计:负载均衡层设计方案(6)——Nginx + Keepalived构建高可用的负载层

Nginx的安装在我的前文《架构设计:负载均衡层设计方案(2)——Nginx安装》(http://blog.csdn.net/yinwenjie/article/details/46620711)中已经进行了详细的讲解,所以这里的讲解就一笔带过。

2.2、再分别独立安装Keepalived系统

我们的目标是“在一台工作的Nginx崩溃的情况下,系统能够检测到,并自动将请求切换到另外一台备份的Nginx服务器上”。所以,之前安装的两台Nginx,一台是Master服务器是主要的工作服务器,另一台是备份服务器,在Master服务器出现问题后,由后者接替其工作。如下图所示(外网的请求使用一个由keepalived控制的虚拟的浮动IP进行访问):

架构设计:负载均衡层设计方案(6)——Nginx + Keepalived构建高可用的负载层

  • 请到 www.keepalived.org 下载keepalived的稳定版本,我下载的是1.2.17版本。

  • 解压,并且安装。注意,我在这里制定了perfix参数,指定安装位置,这是为了我自己便于管理。您在安装的时候,可以根据自己的情况来决定是不是加这个参数:

    tar -zxvf keepalived-1.2.17.tar.gz
    
    ./configure --perfix=/usr/keepalived-1.2.17
    
    make & make install
  • 如果您不是安装到默认路径,那么为了将keepalived做成系统服务,您需要拷贝一些文件到指定的路径下,如下:

    cp /usr/keepalived-1.2.17/etc/sysconfig/keepalived  /etc/sysconfig/keepalived
    
    cp /usr/keepalived-1.2.17/sbin/keepalived /usr/sbin/keepalived
    
    cp /usr/keepalived-1.2.17/etc/rc.d/init.d/keepalived  /etc/rc.d/init.d/keepalived
    
    mkdir /etc/keepalived
    
    cp /usr/keepalived-1.2.17/etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf
  • 然后您可以将keepalived做成服务了:

    /etc/rc.d/init.d/keepalived
    
    chkconfig keepalived on

3、检查Nginx状态

在正式介绍Nginx + Keepalived的配置前,我们首先介绍一下如何检查Nginx的状态。是的,这是为下一小节做准备。我们只有能够正确检查Nginx的状态,才说得上在Nginx节点出现问题的情况下,切换到另一台Nginx上接替其工作

Nginx为什么会停止响应呢?在我的工作经验中,无非有以下几种情况:

  • Nginx的所有进程被强行终止(或管理进程)。 
    这种情况,是我们需要检查和切换的。无论什么情况下进程被终止了,如果它不能重启,我们就要切换到备机。

  • Nginx日志盘的挂载点崩溃或者磁盘写满。 
    这个也是我们需要检查和切换的。

  • Nginx已经达到设置的最大连接数,暂时停止响应。 
    这种情况下,我们不能进行备机切换,因为通过VIP:192.168.61.100连接过来的用户请求比较多(在我们优化参数后,可以达到65535 / 4的数量),一旦我们进行备机切换,这些用户请求将全部异常。这个问题的解决需要靠增加负载机器,而不是主备切换。

  • Nginx物理机异常关机。 
    这个肯定是需要进行检查和切换的。

我们来看一段Linux脚本:

#!/bin/sh
if [ $(ps -C nginx --no-header | wc -l) -eq 0 ]; then
/usr/nginx-1.6.2/sbin/nginx
fi sleep 2
if [ $(ps -C nginx --no-header | wc -l) -eq 0 ]; then
service keepalived stop
fi

我们大致讲解一下“ps -C nginx –no-header | wc -l”这个命令: 
- ps 这个命令用来进行Linux中进程相关的查询,-C 意思是按照进程名称进行查询。查询出来后的结果如下:

[root@vm2 ~]# ps -C nginx
PID TTY TIME CMD
3374 ? 00:00:00 nginx
3375 ? 00:00:01 nginx
  • 如果要去掉统计出来的结果表的头部,那么要使用 –no-header参数,加上参数后,查询结果如下:

    [root@vm2 ~]# ps -C nginx  --no-header
    3374 ? 00:00:00 nginx
    3375 ? 00:00:01 nginx
  • “|”,这是Linux中的管道流命令,将上一个命令的输出结果作为下一个命令的输入。

  • wc 统计命令,-l 参数,代表按行数进行统计。所以整个命令的输出结果为:

    [root@vm2 ~]# ps -C nginx --no-header | wc -l
    2

清楚了其中最关键的命令,我们再来讲解一下整个脚本的含义: 
第一个判断说明的是,如果当前nginx的进程数量 == 0,那么执行nginx的启动命令,试图重新启动nginx;接下来等待2秒(这是为了给nginx一定的启动时间),然后再次查看Nginx的进程数量,如果仍然 == 0,那么停止这台机器的keepalived服务,以便备用的Keepalived节点检查到Keepalived已经停止这个事件,并将浮动IP切换到备用服务器上。

注意,这段脚本是和我机器上的Nginx安装路径、Keepalived服务的状态有关的,您如果要用的话,请进行相应的更改

4、Nginx + Keepalived最简配置

4.1、请再次确认前提

(首先,为了保证不会出现额外的问题,请首先关闭防火墙,当然正式环境里面,防火墙不能关闭)

外网进行Nginx访问的浮动IP:192.168.61.100

  • 我们将192.168.61.129这台服务器上运行的Nginx作为主要的Nginx,其上的keepalived服务我们设置成Master方式。

  • 我们将192.168.61.129这台服务器上运行的Nginx作为备用的Nginx服务,其上的keepalived服务我们设置为Backup方式。

4.2、正式开始设置

注意,经过安装,您的keepalived配置文件的位置在“/etc/keepalived/keepalived.conf”(如果没有,请创建一个,但是经过之前的步骤,这个位置肯定是有文件的,如果没有可能是之前您的步骤出现了什么问题)。

4.2.1、设置192.168.61.129上的MASTER

我们先来看看192.168.61.129上的原始ip信息:

架构设计:负载均衡层设计方案(6)——Nginx + Keepalived构建高可用的负载层

注意,这个129机器上的网卡设备号是eth1,而不是eth0,这个参数我们将在配置keepalived的时候使用到。

下面是129上keepalived的最简配置:

! Configuration File for keepalived
# global setting , notify email setting
global_defs {
#存在于同一个网段中,一组keepalived的各个节点都有不同的名字
#在全局设置中,我们还可以设置管理员的email信息等。
router_id LVS_V1
} #这个是我们在上一小结讲到的nginx检查脚本,我们保存在这个文件中(注意文件权限)
vrrp_script chknginx {
script "/usr/keepalived-1.2.17/bin/checknginx.sh"
#每10秒钟,检查一次
interval 10
} #keepalived实例设置,是最重要的设置信息
vrrp_instance VI_1 {
#state状态MASTER表示是主要工作节点。
#一个keepalived组中,最多只有一个MASTER节点,当然也可以没有
state MASTER
#实例所绑定的网卡设备,我的网卡设备是eth1。您按照您自己的来
interface eth1
#同一个keepalived组,节点的设置必须一样,这样才会被识别
virtual_router_id 52
#节点优先级,BACKUP的优先级一定要比MASTER的优先级低
priority 100
#组播信息发送间隔,两个节点设置必须一样
advert_int 1
#实际的eth1上的固定ip地址
mcast_src_ip=192.168.61.129
#验证信息,只有验证信息相同,才能被加入到一个组中。
authentication {
auth_type PASS
auth_pass 1111
}
#虚拟地址和绑定的端口,如果有多个,就绑定多个
#dev 是指定浮动IP要绑定的网卡设备号
virtual_ipaddress {
192.168.61.100 dev eth1
} #设置的检查脚本
#关联上方的“vrrp_script chknginx”
track_script {
chknginx
}
}

4.2.2、设置192.168.61.130上的BACKUP

再来看看192.168.61.130这个备用节点上keepalived的设置:

! Configuration File for keepalived
# global setting , notify email setting
global_defs {
#这里和master节点不同
router_id LVS_V2
} #check nginx
vrrp_script chknginx {
script "/usr/keepalived-1.2.17/bin/checknginx.sh"
interval 10
} # instance setting
vrrp_instance VI_1 {
# 这里和Master节点不一样
state BACKUP
interface eth1
# 这里一定是一样的
virtual_router_id 52
# 这里的优先级比Master节点低
priority 99
advert_int 1
# 这里和Master节点不一样
mcast_src_ip=192.168.61.130
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.61.100 dev eth1
} track_script {
chknginx
}
}

4.3、启动主节点和备用节点

以上配置中请注意几个关键点:

  • 注意nginx状态检查的脚本的位置,根据自己创建文件的位置不一样,脚本检查的指定位置也不一样
  • 注意优先级,MASTER节点的优先级一定要高于所有的BACKUP节点。
  • 注意局域网的组播地址,一定要可用。局域网内所有keepalived节点都是利用组播方式寻找对方。
  • 谁说BACKUP节点只能有一个!?
  • 最后,keepalived一定要注册成服务形式,您可以想象上面所有脚本、配置、命令如果重启后再来一次,会是什么情况。

接下来,我们要开始启动Master节点和Backup节点了,为了准确的查看日志状态,您需要观察系统日志。系统日志所在的位置:

tail -f /var/log/messages

先启动Master节点:

service keepalived start

再启动Backup节点:

service keepalived start

如果设置和启动都是成功的,您不会在日志信息中收到任何的keepalived报错信息。接下来您就可以使用192.168.61.100这个IP访问Nginx了:

架构设计:负载均衡层设计方案(6)——Nginx + Keepalived构建高可用的负载层

另外,这个绑定在192.168.61.129上的浮动ip:192.168.61.100,您通过ipconfig命令一般是看不到的,要使用ip addr命令进行查看:

架构设计:负载均衡层设计方案(6)——Nginx + Keepalived构建高可用的负载层

为了试验,我们主动停止Master节点上的keepalived服务(注意,杀Nginx进程不起作用,因为我们的检查脚本会试图重新启动Nginx进程),接下来我们可以看到浮动IP漂移到了130备机上:

架构设计:负载均衡层设计方案(6)——Nginx + Keepalived构建高可用的负载层

5、Nginx + Keepalived非抢占模式

通过第4节的详细介绍,相信您对Nginx + Keepalived的安装方式有了一个明确的理解。keepalived的切换可以是自动的,但是却做不到毫秒级别,他怎么都需要几秒钟的时间进行切换。

这就有一个问题,虽然在主节点出现问题我们转向备份节点时,这个延时无可避免,但是在我们修复主节点后,实际上并没有必要再马上做一次切换,所以Keepalived提供了一种非抢占模式,来满足这个要求。

下面我们就来介绍一下Keepalived的非抢占模式的配置(无MASTER节点,全部依据优先级确定哪个节点进行工作):

5.1、原来主节点的配置改动

! Configuration File for keepalived
# global setting , notify email setting
global_defs {
router_id LVS_V1
} vrrp_script chknginx {
script "/usr/keepalived-1.2.17/bin/checknginx.sh"
interval 10
# 一旦节点失效,节点的优先级就减少2
# 有多少个keepalived节点,就填写多少数量。
# 这样保证这个节点的优先级比其他节点都低
weight -2
# fall 表示多少次检查失败,就算节点失效。默认1
#fall 1
} vrrp_instance VI_1 {
#state状态都是BACKUP表示是主要工作节点。
state BACKUP
interface eth1
virtual_router_id 52
# 这个关键配置项,设置为“非抢占”模式
nopreempt
# 每个节点的优先级一定要不一样
priority 100
advert_int 1
mcast_src_ip=192.168.61.129
authentication {
auth_type PASS
auth_pass 1111
}
#虚拟地址和绑定的端口,如果有多个,就绑定多个
#dev 是指定浮动IP要绑定的网卡设备号
virtual_ipaddress {
192.168.61.100 dev eth1
} #设置的检查脚本
#关联上方的“vrrp_script chknginx”
track_script {
chknginx
}
}

原来的主节点设置更改完成。

5.2、原来备份节点的配置改动

加入“非抢占”模式的关键字、更改一个确定的优先级,设置检查失败后优先级的递减量,就行了。

6、后文介绍

这是我8月份的首篇文章,后文我们将介绍LVS + Keepalived + Nginx的安装和配置方式。注意,LVS被Keepalived后,就没有必要在对Nginx做Keepalived了。

http://blog.csdn.net/yinwenjie/article/details/47130609