Nginx-03- Nginx+Keepalived高可用集群和基本原理

1：Keepalived+Nginx 高可用集群 （主从模式）

1：Nginx高可用概念

首先了解一下什么是高可用，高可用是分布式系统架构中必须考虑的因素。
我们知道使用nginx的反向代理和负载均衡可以解决tomcat服务器的单点故障问题，如，其中一台tomcat服务挂掉之后，nginx可以把全部的请求分配到其他服务器上，这样保证了高可用；

但是这样的架构依然存在问题，之前讨论tomcat挂掉后，系统还能使用，那要是nginx挂了呢？那么所有对外的接口都将不能访问，所以针对此种情况，我们可以使用nginx+keepalived来实现nginx的高可用；

2：双机热备

双机热备方案是目前使用最为普遍的一种高可用方案，双机热备就是指一台服务器(主服务器)在提供服务，另外一台（从服务器）作为备用状态，当一台服务器挂掉之后另外一台就会代替他继续提供服务。

3：LVS负载均衡+keepalived健康监测

LVS（Linux Vritual Server）即Linux虚拟服务器，他是一个开源的软件，可以实现传输层四层负载均衡，通过 LVS 达到的负载均衡技术可以实现一个高性能高可用的 Linux 服务器集群。

大概流程就是：当客户端发出请求时，会先连接到互联网的DNS服务器，然后解析到LVS负载均衡调度器上，LVS可以帮我们虚拟出来一个IP地址（外网IP-VIP），此时客户端用户就会去连接这个虚拟出来的IP，当用户连接到虚拟IP之后LVS会根据指定的调度算法确定具体要连接到哪一台Nginx服务器上（真实IP-RIP）。客户端连接到虚拟IP的过程对用户是透明的，而LVS具体连接到哪一台Nginx服务器对用户来说是不知道的。

LVS负载均衡调度器仅仅只是一个调度器，并不是真正的服务。

LVS可以实现负载均衡，但是不能够进行健康检查。意思就是，假如一台Nginx服务器挂掉了，LVS仍然会把客户端的请求发送到这个挂掉了Nginx上（因为LVS并不知道此Nginx挂了），这样就会导致请求无效无法处理客户端的请求。

keepalive 软件可以进行健康检查，所以我们需要使用他来进行监测，而且可以实现Nginx的高可用性，解决Nginx的单点故障问题及LVS不能进行健康检查的问题。

keepalived的工作原理
keepalived是基于VRRP协议实现的保证集群高可用的一个服务软件，主要功能是实现真机的故障隔离和负载均衡器间的失败切换，防止单点故障。VRRP协议保证当主机的下一路由器出现故障时，由另外一台路由器来代替出现故障的路由器进行工作，从而保持网络通信的连续性和可靠性。

VRRP虚拟出来的是路由。

4：搭建Nginx高可用集群

1：准备工作

（1 ）需要两台 nginx 服务器。192.168.17.129 和 192.168.17.131，一个作为主服务器MASTER，一个作为备服务器BACKUP，
（2 ）需要 nginx,不在赘述
（3 ）需要安装keepalived

#搭建keepalived环境
yum install -y keepalived

#keepalived的启动与停止
service keepalived start
service keepalived stop

2：完成高可用配置

修改主Nginx服务器keepalived文件：vim /etc/keepalived/keepalived.conf

! Configuration File for keepalived
vrrp_script chk_nginx {
    script "/etc/keepalived/nginx_check.sh" #运行脚本，脚本内容下面有，就是起到一个nginx宕机以后，自动开启服务
    interval 2 #检测时间间隔
    weight -20 #如果条件成立的话，则权重 -20
}
# 定义虚拟路由，VI_1 为虚拟路由的标示符，自己定义名称
vrrp_instance VI_1 {
    state MASTER #来决定主从
    interface eth0# 绑定虚拟 IP 的网卡接口，根据自己的机器填写
    virtual_router_id 121 # 虚拟路由的 ID 号， 两个节点设置必须一样
    mcast_src_ip 192.168.66.100 #填写本机ip
    priority 100 # 节点优先级,主要比从节点优先级高
    nopreempt # 优先级高的设置 nopreempt 解决异常恢复后再次抢占的问题
    advert_int 1 # 组播信息发送间隔，两个节点设置必须一样，默认 1s
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    # 将track_script块加入instance 配置块
    track_script {
        chk_nginx #执行Nginx监控的服务
    }
 
    virtual_ipaddress {
        192.168.66.99 #虚拟ip
    }
}

修改从Nginx服务器keepalived文件：vim /etc/keepalived/keepalived.conf

! Configuration File for keepalived
vrrp_script chk_nginx {
    script "/etc/keepalived/nginx_check.sh" #运行脚本，脚本内容下面有，就是起到一个nginx宕机以后，自动开启服务
    interval 2 #检测时间间隔
    weight -20 #如果条件成立的话，则权重 -20
}
# 定义虚拟路由，VI_1 为虚拟路由的标示符，自己定义名称
vrrp_instance VI_1 {
    state BACKUP #来决定主从
    interface eth0# 绑定虚拟 IP 的网卡接口，根据自己的机器填写
    virtual_router_id 121 # 虚拟路由的 ID 号， 两个节点设置必须一样
    mcast_src_ip 192.168.66.101 #填写本机ip
    priority 100 # 节点优先级,主要比从节点优先级高
    nopreempt # 优先级高的设置 nopreempt 解决异常恢复后再次抢占的问题
    advert_int 1 # 组播信息发送间隔，两个节点设置必须一样，默认 1s
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    # 将 track_script 块加入 instance 配置块
    track_script {
        chk_nginx #执行 Nginx 监控的服务
    }
 
    virtual_ipaddress {
        192.168.66.99 # 虚拟ip
    }
}

3：实现高可用的运行脚本

#!/bin/bash
A=`ps -C nginx —no-header |wc -l`
if [ $A -eq 0 ];then
    /usr/local/nginx/sbin/nginx
    sleep 2
    if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then
        killall keepalived
    fi
fi

授权

chmod 775 /etc/keepalived/nginx_check.sh

4:测试

在浏览器访问虚拟IP192.168.66.99时即可访问到主Nginx服务器中的服务，即使主Nginx服务器挂了，也会自动连接到从Nginx服务器上，从而保证了Nginx的高可用，当主Nginx恢复正常时，会再次自动连接到主Nginx服务器上继续服务。

2：nginx 原理与优化参数配置

nginx内部使用的是master&worker机制

1：master- -s workers 的机制的好处

首先，对于每个 worker 进程来说，独立的进程，不需要加锁，所以省掉了锁带来的开销，
同时在编程以及问题查找时，也会方便很多。其次，采用独立的进程，可以让互相之间不会
影响，一个进程退出后，其它进程还在工作，服务不会中断，master 进程则很快启动新的
worker 进程。当然，worker 进程的异常退出，肯定是程序有 bug 了，异常退出，会导致当
前 worker 上的所有请求失败，不过不会影响到所有请求，所以降低了风险。

2：需要设置多少个 worker

Nginx 同 redis 类似都采用了 io 多路复用机制，每个 worker 都是一个独立的进程，但每个进
程里只有一个主线程，通过异步非阻塞的方式来处理请求， 即使是成千上万个请求也不在话
下。每个 worker 的线程可以把一个 cpu 的性能发挥到极致。所以 worker 数和服务器的 cpu
数相等是最为适宜的。设少了会浪费 cpu，设多了会造成 cpu 频繁切换上下文带来的损耗。
总的来说：worker 数和服务器的 cpu 相等即可

3：连接数 worker_connection

这个值是表示每个 worker 进程所能建立连接的最大值，所以，一个 nginx 能建立的最大连接
数，应该是 worker_connections * worker_processes。当然，这里说的是最大连接数，对于
HTTP 请 求 本 地 资 源 来 说 ， 能 够 支 持 的 最 大 并 发 数 量 是 worker_connections *
worker_processes，如果是支持 http1.1 的浏览器每次访问要占两个连接，所以普通的静态访
问最大并发数是： worker_connections * worker_processes /2，而如果是 HTTP 作 为反向代
理来说，最大并发数量应该是 *worker_connections worker_processes/4。因为作为反向代理服务器，每个并发会建立与客户端的连接和与后端服务的连接，会占用两个连接。