【Nginx】如何基於主從模式搭建Nginx+Keepalived雙機熱備環境？這是最全的一篇了！！

本文轉載自查看原文 2020-09-01 22:43 613 Nginx

寫在前面

最近出版了《海量數據處理與大數據技術實戰》，詳情可以關注 冰河技術 微信公眾號，查看《我的《海量數據處理與大數據技術實戰》出版啦！》一文。

也有不少小伙伴讓我更新一篇基於主從模式搭建Nginx+Keepalived雙機熱備的環境，怎么辦呢？那必須安排上啊！不多說了，我們直接進入正文。

負載均衡技術

負載均衡技術對於一個網站尤其是大型網站的web服務器集群來說是至關重要的！做好負載均衡架構，可以實現故障轉移和高可用環境，避免單點故障，保證網站健康持續運行。

由於業務擴展，網站的訪問量不斷加大，負載越來越高。現需要在web前端放置nginx負載均衡,同時結合keepalived對前端nginx實現HA高可用。

1）nginx進程基於Master+Slave(worker)多進程模型，自身具有非常穩定的子進程管理功能。在Master進程分配模式下，Master進程永遠不進行業務處理，只是進行任務分發，從而達到Master進程的存活高可靠性，Slave(worker)進程所有的業務信號都由主進程發出，Slave(worker)進程所有的超時任務都會被Master中止，屬於非阻塞式任務模型。

2）Keepalived是Linux下面實現VRRP備份路由的高可靠性運行件。基於Keepalived設計的服務模式能夠真正做到主服務器和備份服務器故障時IP瞬間無縫交接。二者結合，可以構架出比較穩定的軟件LB方案。

Keepalived介紹

Keepalived是一個基於VRRP協議來實現的服務高可用方案，可以利用其來避免IP單點故障，類似的工具還有heartbeat、corosync、pacemaker。但是它一般不會單獨出現，而是與其它負載均衡技術（如lvs、haproxy、nginx）一起工作來達到集群的高可用。

VRRP協議

VRRP全稱 Virtual Router Redundancy Protocol，即虛擬路由冗余協議。可以認為它是實現路由器高可用的容錯協議，即將N台提供相同功能的路由器組成一個路由器組(Router Group)，這個組里面有一個master和多個backup，但在外界看來就像一台一樣，構成虛擬路由器，擁有一個虛擬IP（vip，也就是路由器所在局域網內其他機器的默認路由），占有這個IP的master實際負責ARP相應和轉發IP數據包，組中的其它路由器作為備份的角色處於待命狀態。master會發組播消息，當backup在超時時間內收不到vrrp包時就認為master宕掉了，這時就需要根據VRRP的優先級來選舉一個backup當master，保證路由器的高可用。

在VRRP協議實現里，虛擬路由器使用 00-00-5E-00-01-XX 作為虛擬MAC地址，XX就是唯一的 VRID （Virtual Router IDentifier），這個地址同一時間只有一個物理路由器占用。在虛擬路由器里面的物理路由器組里面通過多播IP地址 224.0.0.18 來定時發送通告消息。每個Router都有一個 1-255 之間的優先級別，級別最高的（highest priority）將成為主控（master）路由器。通過降低master的優先權可以讓處於backup狀態的路由器搶占（pro-empt）主路由器的狀態，兩個backup優先級相同的IP地址較大者為master，接管虛擬IP。

keepalived與heartbeat/corosync等比較

Heartbeat、Corosync、Keepalived這三個集群組件我們到底選哪個好呢？

首先要說明的是，Heartbeat、Corosync是屬於同一類型，Keepalived與Heartbeat、Corosync，根本不是同一類型的。
Keepalived使用的vrrp協議方式，虛擬路由冗余協議 (Virtual Router Redundancy Protocol，簡稱VRRP)；
Heartbeat或Corosync是基於主機或網絡服務的高可用方式；

簡單的說就是，Keepalived的目的是模擬路由器的高可用，Heartbeat或Corosync的目的是實現Service的高可用。
所以一般Keepalived是實現前端高可用，常用的前端高可用的組合有，就是我們常見的LVS+Keepalived、Nginx+Keepalived、HAproxy+Keepalived。而Heartbeat或Corosync是實現服務的高可用，常見的組合有Heartbeat v3(Corosync)+Pacemaker+NFS+Httpd 實現Web服務器的高可用、Heartbeat v3(Corosync)+Pacemaker+NFS+MySQL 實現MySQL服務器的高可用。

總結一下，Keepalived中實現輕量級的高可用，一般用於前端高可用，且不需要共享存儲，一般常用於兩個節點的高可用。而Heartbeat(或Corosync)一般用於服務的高可用，且需要共享存儲，一般用於多節點的高可用。這個問題我們說明白了。

那heartbaet與corosync又應該選擇哪個好？

一般用corosync，因為corosync的運行機制更優於heartbeat，就連從heartbeat分離出來的pacemaker都說在以后的開發當中更傾向於corosync，所以現在corosync+pacemaker是最佳組合。

雙機高可用一般是通過虛擬IP（飄移IP）方法來實現的，基於Linux/Unix的IP別名技術。

雙機高可用方法目前分為兩種：

1）雙機主從模式：即前端使用兩台服務器，一台主服務器和一台熱備服務器，正常情況下，主服務器綁定一個公網虛擬IP，提供負載均衡服務，熱備服務器處於空閑狀態；當主服務器發生故障時，熱備服務器接管主服務器的公網虛擬IP，提供負載均衡服務；但是熱備服務器在主機器不出現故障的時候，永遠處於浪費狀態，對於服務器不多的網站，該方案不經濟實惠。

2）雙機主主模式：即前端使用兩台負載均衡服務器，互為主備，且都處於活動狀態，同時各自綁定一個公網虛擬IP，提供負載均衡服務；當其中一台發生故障時，另一台接管發生故障服務器的公網虛擬IP（這時由非故障機器一台負擔所有的請求）。這種方案，經濟實惠，非常適合於當前架構環境。

今天在此分享下Nginx+keepalived實現高可用負載均衡的主從模式的操作記錄：

keepalived可以認為是VRRP協議在Linux上的實現，主要有三個模塊，分別是core、check和vrrp。

core模塊為keepalived的核心，負責主進程的啟動、維護以及全局配置文件的加載和解析。
check負責健康檢查，包括常見的各種檢查方式。
vrrp模塊是來實現VRRP協議的。

環境說明

操作系統：centos6.8，64位
master機器（master-node）：103.110.98.14/192.168.1.14
slave機器（slave-node）：103.110.98.24/192.168.1.24
公用的虛擬IP（VIP）：103.110.98.20 //負載均衡器上配置的域名都解析到這個VIP上

應用環境如下

環境安裝

安裝nginx和keepalive服務（master-node和slave-node兩台服務器上的安裝操作完全一樣）。

安裝依賴

[root@master-node ~]# yum -y install gcc pcre-devel zlib-devel openssl-devel

大家可以到鏈接：https://download.csdn.net/download/l1028386804/10376846下載nginx1.9.7+keepalive1.3.2，也可以將nginx.1.9.7更新為nginx1.19.2。nginx1.19.2與nginx1.9.7的安裝方式相同，這里我以nginx1.9.7為例進行安裝。

[root@master-node ~]# cd /usr/local/src/
[root@master-node src]# wget http://nginx.org/download/nginx-1.9.7.tar.gz
[root@master-node src]# wget http://www.keepalived.org/software/keepalived-1.3.2.tar.gz

安裝nginx

[root@master-node src]# tar -zvxf nginx-1.9.7.tar.gz
[root@master-node src]# cd nginx-1.9.7

添加www用戶，其中-M參數表示不添加用戶家目錄，-s參數表示指定shell類型

[root@master-node nginx-1.9.7]# useradd www -M -s /sbin/nologin
[root@master-node nginx-1.9.7]# vim auto/cc/gcc
#將這句注釋掉 取消Debug編譯模式 大概在179行
#CFLAGS="$CFLAGS -g"
[root@master-node nginx-1.9.7]# ./configure --prefix=/usr/local/nginx --user=www --group=www --with-http_ssl_module --with-http_flv_module --with-http_stub_status_module --with-http_gzip_static_module --with-pcre
[root@master-node nginx-1.9.7]# make && make install

安裝keepalived

[root@master-node src]# tar -zvxf keepalived-1.3.2.tar.gz
[root@master-node src]# cd keepalived-1.3.2
[root@master-node keepalived-1.3.2]# ./configure
[root@master-node keepalived-1.3.2]# make && make install
[root@master-node keepalived-1.3.2]# cp /usr/local/src/keepalived-1.3.2/keepalived/etc/init.d/keepalived /etc/rc.d/init.d/
[root@master-node keepalived-1.3.2]# cp /usr/local/etc/sysconfig/keepalived /etc/sysconfig/
[root@master-node keepalived-1.3.2]# mkdir /etc/keepalived
[root@master-node keepalived-1.3.2]# cp /usr/local/etc/keepalived/keepalived.conf /etc/keepalived/
[root@master-node keepalived-1.3.2]# cp /usr/local/sbin/keepalived /usr/sbin/

將nginx和keepalive服務加入開機啟動服務

[root@master-node keepalived-1.3.2]# echo "/usr/local/nginx/sbin/nginx" >> /etc/rc.local
[root@master-node keepalived-1.3.2]# echo "/etc/init.d/keepalived start" >> /etc/rc.local

配置服務

先關閉SElinux、配置防火牆（master和slave兩台負載均衡機都要做）

[root@master-node ~]# vim /etc/sysconfig/selinux
#SELINUX=enforcing                      #注釋掉
#SELINUXTYPE=targeted                #注釋掉
SELINUX=disabled                           #增加
[root@master-node ~]# setenforce 0                               #使配置立即生效

[root@master-node ~]# vim /etc/sysconfig/iptables
.......
-A INPUT -s 103.110.98.0/24 -d 224.0.0.18 -j ACCEPT                        #允許組播地址通信
-A INPUT -s 192.168.1.0/24 -d 224.0.0.18 -j ACCEPT
-A INPUT -s 103.110.98.0/24 -p vrrp -j ACCEPT                                  #允許 VRRP（虛擬路由器冗余協）通信
-A INPUT -s 192.168.1.0/24 -p vrrp -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT      #開通80端口訪問

[root@master-node ~]# /etc/init.d/iptables restart                               #重啟防火牆使配置生效

配置nginx

master-node和slave-node兩台服務器的nginx的配置完全一樣,主要是配置/usr/local/nginx/conf/nginx.conf的http，當然也可以配置vhost虛擬主機目錄，然后配置vhost下的比如LB.conf文件。

其中:
多域名指向是通過虛擬主機（配置http下面的server）實現;
同一域名的不同虛擬目錄通過每個server下面的不同location實現;
到后端的服務器在vhost/LB.conf下面配置upstream,然后在server或location中通過proxy_pass引用。

要實現前面規划的接入方式，LB.conf的配置如下（添加proxy_cache_path和proxy_temp_path這兩行，表示打開nginx的緩存功能）

[root@master-node ~]# vim /usr/local/nginx/conf/nginx.conf
user  www;
worker_processes  8;
 
#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;
 
#pid        logs/nginx.pid;
 
 
events {
    worker_connections  65535;
}
 
 
http {
    include       mime.types;
    default_type  application/octet-stream;
    charset utf-8;
       
    ######
    ## set access log format
    ######
    log_format  main  '$http_x_forwarded_for $remote_addr $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_cookie" $host $request_time';
 
    #######
    ## http setting
    #######
    sendfile       on;
    tcp_nopush     on;
    tcp_nodelay    on;
    keepalive_timeout  65;
    proxy_cache_path /var/www/cache levels=1:2 keys_zone=mycache:20m max_size=2048m inactive=60m;
    proxy_temp_path /var/www/cache/tmp;
 
    fastcgi_connect_timeout 3000;
    fastcgi_send_timeout 3000;
    fastcgi_read_timeout 3000;
    fastcgi_buffer_size 256k;
    fastcgi_buffers 8 256k;
    fastcgi_busy_buffers_size 256k;
    fastcgi_temp_file_write_size 256k;
    fastcgi_intercept_errors on;
 
    #
    client_header_timeout 600s;
    client_body_timeout 600s;
   # client_max_body_size 50m;
    client_max_body_size 100m;               #允許客戶端請求的最大單個文件字節數
    client_body_buffer_size 256k;            #緩沖區代理緩沖請求的最大字節數，可以理解為先保存到本地再傳給用戶
 
    gzip  on;
    gzip_min_length  1k;
    gzip_buffers     4 16k;
    gzip_http_version 1.1;
    gzip_comp_level 9;
    gzip_types       text/plain application/x-javascript text/css application/xml text/javascript application/x-httpd-php;
    gzip_vary on;
 
    ## includes vhosts
    include vhosts/*.conf;
}

[root@master-node ~]# mkdir /usr/local/nginx/conf/vhosts
[root@master-node ~]# mkdir /var/www/cache
[root@master-node ~]# ulimit 65535

[root@master-node ~]# vim /usr/local/nginx/conf/vhosts/LB.conf
upstream LB-WWW {
      ip_hash;
      server 192.168.1.101:80 max_fails=3 fail_timeout=30s;     #max_fails = 3 為允許失敗的次數，默認值為1
      server 192.168.1.102:80 max_fails=3 fail_timeout=30s;     #fail_timeout = 30s 當max_fails次失敗后，暫停將請求分發到該后端服務器的時間
      server 192.168.1.118:80 max_fails=3 fail_timeout=30s;
    }
    
upstream LB-OA {
      ip_hash;
      server 192.168.1.101:8080 max_fails=3 fail_timeout=30s;
      server 192.168.1.102:8080 max_fails=3 fail_timeout=30s;
}
          
  server {
      listen      80;
      server_name dev.wangshibo.com;
    
      access_log  /usr/local/nginx/logs/dev-access.log main;
      error_log  /usr/local/nginx/logs/dev-error.log;
    
      location /svn {
         proxy_pass http://192.168.1.108/svn/;
         proxy_redirect off ;
         proxy_set_header Host $host;
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header REMOTE-HOST $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_connect_timeout 300;             #跟后端服務器連接超時時間，發起握手等候響應時間
         proxy_send_timeout 300;                #后端服務器回傳時間，就是在規定時間內后端服務器必須傳完所有數據
         proxy_read_timeout 600;                #連接成功后等待后端服務器的響應時間，已經進入后端的排隊之中等候處理
         proxy_buffer_size 256k;                #代理請求緩沖區,會保存用戶的頭信息以供nginx進行處理
         proxy_buffers 4 256k;                  #同上，告訴nginx保存單個用幾個buffer最大用多少空間
         proxy_busy_buffers_size 256k;          #如果系統很忙時候可以申請最大的proxy_buffers
         proxy_temp_file_write_size 256k;       #proxy緩存臨時文件的大小
         proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;
         proxy_max_temp_file_size 128m;
         proxy_cache mycache;                                
         proxy_cache_valid 200 302 60m;                      
         proxy_cache_valid 404 1m;
       }
    
      location /submin {
         proxy_pass http://192.168.1.108/submin/;
         proxy_redirect off ;
         proxy_set_header Host $host;
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header REMOTE-HOST $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_connect_timeout 300;
         proxy_send_timeout 300;
         proxy_read_timeout 600;
         proxy_buffer_size 256k;
         proxy_buffers 4 256k;
         proxy_busy_buffers_size 256k;
         proxy_temp_file_write_size 256k;
         proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;
         proxy_max_temp_file_size 128m;
         proxy_cache mycache;        
         proxy_cache_valid 200 302 60m;
         proxy_cache_valid 404 1m;
        }
    }
    
server {
     listen       80;
     server_name  www.wangshibo.com;
  
      access_log  /usr/local/nginx/logs/www-access.log main;
      error_log  /usr/local/nginx/logs/www-error.log;
  
     location / {
         proxy_pass http://LB-WWW;
         proxy_redirect off ;
         proxy_set_header Host $host;
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header REMOTE-HOST $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_connect_timeout 300;
         proxy_send_timeout 300;
         proxy_read_timeout 600;
         proxy_buffer_size 256k;
         proxy_buffers 4 256k;
         proxy_busy_buffers_size 256k;
         proxy_temp_file_write_size 256k;
         proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;
         proxy_max_temp_file_size 128m;
         proxy_cache mycache;                                
         proxy_cache_valid 200 302 60m;                      
         proxy_cache_valid 404 1m;
        }
}
   
 server {
       listen       80;
       server_name  oa.wangshibo.com;
  
      access_log  /usr/local/nginx/logs/oa-access.log main;
      error_log  /usr/local/nginx/logs/oa-error.log;
  
       location / {
         proxy_pass http://LB-OA;
         proxy_redirect off ;
         proxy_set_header Host $host;
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header REMOTE-HOST $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_connect_timeout 300;
         proxy_send_timeout 300;
         proxy_read_timeout 600;
         proxy_buffer_size 256k;
         proxy_buffers 4 256k;
         proxy_busy_buffers_size 256k;
         proxy_temp_file_write_size 256k;
         proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;
         proxy_max_temp_file_size 128m;
         proxy_cache mycache;                                
         proxy_cache_valid 200 302 60m;                      
         proxy_cache_valid 404 1m;
        }
}

驗證Nginx配置

驗證方法（保證從負載均衡器本機到后端真實服務器之間能正常通信）：
1）首先在本機用IP訪問上面LB.cong中配置的各個后端真實服務器的url
2）然后在本機用域名和路徑訪問上面LB.cong中配置的各個后端真實服務器的域名/虛擬路徑

后端應用服務器的nginx配置，這里選擇192.168.1.108作為例子進行說明。

由於這里的192.168.1.108機器是openstack的虛擬機，沒有外網ip，不能解析域名。所以在server_name處也將ip加上，使得用ip也可以訪問。

[root@108-server ~]# cat /usr/local/nginx/conf/vhosts/svn.conf
server {
listen 80;
#server_name dev.wangshibo.com;
server_name dev.wangshibo.com 192.168.1.108;

access_log /usr/local/nginx/logs/dev.wangshibo-access.log main;
error_log /usr/local/nginx/logs/dev.wangshibo-error.log;

location / {
root /var/www/html;
index index.html index.php index.htm;
}
}

[root@108-server ~]# ll /var/www/html/
drwxr-xr-x. 2 www www 4096 Dec 7 01:46 submin
drwxr-xr-x. 2 www www 4096 Dec 7 01:45 svn
[root@108-server ~]# cat /var/www/html/svn/index.html
this is the page of svn/192.168.1.108
[root@108-server ~]# cat /var/www/html/submin/index.html
this is the page of submin/192.168.1.108

[root@108-server ~]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.1.108 dev.wangshibo.com

[root@108-server ~]# curl http://dev.wangshibo.com       //由於是內網機器不能聯網，亦不能解析域名。所以用域名訪問沒有反應。只能用ip訪問
[root@ops-server4 vhosts]# curl http://192.168.1.108
this is 192.168.1.108 page!!!
[root@ops-server4 vhosts]# curl http://192.168.1.108/svn/           //最后一個/符號要加上，否則訪問不了。
this is the page of svn/192.168.1.108
[root@ops-server4 vhosts]# curl http://192.168.1.108/submin/
this is the page of submin/192.168.1.108

然后在master-node和slave-node兩台負載機器上進行測試（iptables防火牆要開通80端口）：

[root@master-node ~]# curl http://192.168.1.108/svn/
this is the page of svn/192.168.1.108
[root@master-node ~]# curl http://192.168.1.108/submin/
this is the page of submin/192.168.1.108

瀏覽器訪問：
在本機host綁定dev.wangshibo.com，如下，即綁定到master和slave機器的公網ip上測試是否能正常訪問（nginx+keepalive環境正式完成后，域名解析到的真正地址是VIP地址）
103.110.98.14 dev.wangshibo.com
103.110.98.24 dev.wangshibo.com

keepalived配置

1）master-node負載機上的keepalived配置

[root@master-node ~]# cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.bak
[root@master-node ~]# vim /etc/keepalived/keepalived.conf

! Configuration File for keepalived     #全局定義
  
global_defs {
notification_email {     #指定keepalived在發生事件時(比如切換)發送通知郵件的郵箱
ops@wangshibo.cn   #設置報警郵件地址，可以設置多個，每行一個。 需開啟本機的sendmail服務
tech@wangshibo.cn
}
  
notification_email_from ops@wangshibo.cn   #keepalived在發生諸如切換操作時需要發送email通知地址
smtp_server 127.0.0.1      #指定發送email的smtp服務器
smtp_connect_timeout 30    #設置連接smtp server的超時時間
router_id master-node     #運行keepalived的機器的一個標識，通常可設為hostname。故障發生時，發郵件時顯示在郵件主題中的信息。
}
  
vrrp_script chk_http_port {      #檢測nginx服務是否在運行。有很多方式，比如進程，用腳本檢測等等
    script "/opt/chk_nginx.sh"   #這里通過腳本監測
    interval 2                   #腳本執行間隔，每2s檢測一次
    weight -5                    #腳本結果導致的優先級變更，檢測失敗（腳本返回非0）則優先級 -5
    fall 2                    #檢測連續2次失敗才算確定是真失敗。會用weight減少優先級（1-255之間）
    rise 1                    #檢測1次成功就算成功。但不修改優先級
}
  
vrrp_instance VI_1 {    #keepalived在同一virtual_router_id中priority（0-255）最大的會成為master，也就是接管VIP，當priority最大的主機發生故障后次priority將會接管
    state MASTER    #指定keepalived的角色，MASTER表示此主機是主服務器，BACKUP表示此主機是備用服務器。注意這里的state指定instance(Initial)的初始狀態，就是說在配置好后，這台服務器的初始狀態就是這里指定的，但這里指定的不算，還是得要通過競選通過優先級來確定。如果這里設置為MASTER，但如若他的優先級不及另外一台，那么這台在發送通告時，會發送自己的優先級，另外一台發現優先級不如自己的高，那么他會就回搶占為MASTER
    interface em1          #指定HA監測網絡的接口。實例綁定的網卡，因為在配置虛擬IP的時候必須是在已有的網卡上添加的
    mcast_src_ip 103.110.98.14  # 發送多播數據包時的源IP地址，這里注意了，這里實際上就是在哪個地址上發送VRRP通告，這個非常重要，一定要選擇穩定的網卡端口來發送，這里相當於heartbeat的心跳端口，如果沒有設置那么就用默認的綁定的網卡的IP，也就是interface指定的IP地址
    virtual_router_id 51         #虛擬路由標識，這個標識是一個數字，同一個vrrp實例使用唯一的標識。即同一vrrp_instance下，MASTER和BACKUP必須是一致的
    priority 101                 #定義優先級，數字越大，優先級越高，在同一個vrrp_instance下，MASTER的優先級必須大於BACKUP的優先級
    advert_int 1                 #設定MASTER與BACKUP負載均衡器之間同步檢查的時間間隔，單位是秒
    authentication {             #設置驗證類型和密碼。主從必須一樣
        auth_type PASS           #設置vrrp驗證類型，主要有PASS和AH兩種
        auth_pass 1111           #設置vrrp驗證密碼，在同一個vrrp_instance下，MASTER與BACKUP必須使用相同的密碼才能正常通信
    }
    virtual_ipaddress {          #VRRP HA 虛擬地址 如果有多個VIP，繼續換行填寫
        103.110.98.20
    }
 
    track_script {                      #執行監控的服務。注意這個設置不能緊挨着寫在vrrp_script配置塊的后面（實驗中碰過的坑），否則nginx監控失效！！
       chk_http_port                    #引用VRRP腳本，即在 vrrp_script 部分指定的名字。定期運行它們來改變優先級，並最終引發主備切換。
    }
}

slave-node負載機上的keepalived配置

[root@slave-node ~]# cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.bak
[root@slave-node ~]# vim /etc/keepalived/keepalived.conf

! Configuration File for keepalived    
  
global_defs {
notification_email {                
ops@wangshibo.cn                     
tech@wangshibo.cn
}
  
notification_email_from ops@wangshibo.cn  
smtp_server 127.0.0.1                    
smtp_connect_timeout 30                 
router_id slave-node                    
}
  
vrrp_script chk_http_port {         
    script "/opt/chk_nginx.sh"   
    interval 2                      
    weight -5                       
    fall 2                   
    rise 1                  
}
  
vrrp_instance VI_1 {            
    state BACKUP           
    interface em1            
    mcast_src_ip 103.110.98.24  
    virtual_router_id 51        
    priority 99               
    advert_int 1               
    authentication {            
        auth_type PASS         
        auth_pass 1111          
    }
    virtual_ipaddress {        
        103.110.98.20
    }
 
    track_script {                     
       chk_http_port                 
    }
 
}

讓keepalived監控NginX的狀態：

1）經過前面的配置，如果master主服務器的keepalived停止服務，slave從服務器會自動接管VIP對外服務；
一旦主服務器的keepalived恢復，會重新接管VIP。但這並不是我們需要的，我們需要的是當NginX停止服務的時候能夠自動切換。
2）keepalived支持配置監控腳本，我們可以通過腳本監控NginX的狀態，如果狀態不正常則進行一系列的操作，最終仍不能恢復NginX則殺掉keepalived，使得從服務器能夠接管服務。

如何監控NginX的狀態
最簡單的做法是監控NginX進程，更靠譜的做法是檢查NginX端口，最靠譜的做法是檢查多個url能否獲取到頁面。

注意：這里要提示一下keepalived.conf中vrrp_script配置區的script一般有2種寫法：

1）通過腳本執行的返回結果，改變優先級，keepalived繼續發送通告消息，backup比較優先級再決定。這是直接監控Nginx進程的方式。
2）腳本里面檢測到異常，直接關閉keepalived進程，backup機器接收不到advertisement會搶占IP。這是檢查NginX端口的方式。

上文script配置部分，"killall -0 nginx"屬於第1種情況，"/opt/chk_nginx.sh" 屬於第2種情況。個人更傾向於通過shell腳本判斷，但有異常時exit 1，正常退出exit 0，然后keepalived根據動態調整的 vrrp_instance 優先級選舉決定是否搶占VIP：

如果腳本執行結果為0，並且weight配置的值大於0，則優先級相應的增加
如果腳本執行結果非0，並且weight配置的值小於0，則優先級相應的減少
其他情況，原本配置的優先級不變，即配置文件中priority對應的值。

提示：
優先級不會不斷的提高或者降低

可以編寫多個檢測腳本並為每個檢測腳本設置不同的weight（在配置中列出就行）

不管提高優先級還是降低優先級，最終優先級的范圍是在[1,254]，不會出現優先級小於等於0或者優先級大於等於255的情況
在MASTER節點的 vrrp_instance 中配置 nopreempt ，當它異常恢復后，即使它 prio 更高也不會搶占，這樣可以避免正常情況下做無謂的切換

以上可以做到利用腳本檢測業務進程的狀態，並動態調整優先級從而實現主備切換。

另外：在默認的keepalive.conf里面還有 virtual_server,real_server 這樣的配置，我們這用不到，它是為lvs准備的。

如何嘗試恢復服務
由於keepalived只檢測本機和他機keepalived是否正常並實現VIP的漂移，而如果本機nginx出現故障不會則不會漂移VIP。
所以編寫腳本來判斷本機nginx是否正常，如果發現NginX不正常，重啟之。等待3秒再次校驗，仍然失敗則不再嘗試，關閉keepalived，其他主機此時會接管VIP；

根據上述策略很容易寫出監控腳本。此腳本必須在keepalived服務運行的前提下才有效！如果在keepalived服務先關閉的情況下，那么nginx服務關閉后就不能實現自啟動了。

該腳本檢測ngnix的運行狀態，並在nginx進程不存在時嘗試重新啟動ngnix，如果啟動失敗則停止keepalived，准備讓其它機器接管。
監控腳本如下（master和slave都要有這個監控腳本）：

[root@master-node ~]# vim /opt/chk_nginx.sh

#!/bin/bash
counter=$(ps -C nginx --no-heading|wc -l)
if [ "${counter}" = "0" ]; then
    /usr/local/nginx/sbin/nginx
    sleep 2
    counter=$(ps -C nginx --no-heading|wc -l)
    if [ "${counter}" = "0" ]; then
        /etc/init.d/keepalived stop
    fi
fi

[root@master-node ~]# chmod 755 /opt/chk_nginx.sh
[root@master-node ~]# sh /opt/chk_nginx.sh
80/tcp open http

此架構需考慮的問題
1）master沒掛，則master占有vip且nginx運行在master上
2）master掛了，則slave搶占vip且在slave上運行nginx服務
3）如果master上的nginx服務掛了，則nginx會自動重啟，重啟失敗后會自動關閉keepalived，這樣vip資源也會轉移到slave上。
4）檢測后端服務器的健康狀態
5）master和slave兩邊都開啟nginx服務，無論master還是slave，當其中的一個keepalived服務停止后，vip都會漂移到keepalived服務還在的節點上；
如果要想使nginx服務掛了，vip也漂移到另一個節點，則必須用腳本或者在配置文件里面用shell命令來控制。（nginx服務宕停后會自動啟動，啟動失敗后會強制關閉keepalived，從而致使vip資源漂移到另一台機器上）

最后驗證（將配置的后端應用域名都解析到VIP地址上）：關閉主服務器上的keepalived或nginx，vip都會自動飄到從服務器上。

驗證keepalived服務故障情況：
1）先后在master、slave服務器上啟動nginx和keepalived，保證這兩個服務都正常開啟:

[root@master-node ~]# /usr/local/nginx/sbin/nginx
[root@master-node ~]# /etc/init.d/keepalived start
[root@slave-node ~]# /usr/local/nginx/sbin/nginx
[root@slave-node ~]# /etc/init.d/keepalived start

2）在主服務器上查看是否已經綁定了虛擬IP

[root@master-node ~]# ip addr
.......
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 44:a8:42:17:3d:dd brd ff:ff:ff:ff:ff:ff
inet 103.110.98.14/26 brd 103.10.86.63 scope global em1
valid_lft forever preferred_lft forever
inet 103.110.98.20/32 scope global em1
valid_lft forever preferred_lft forever
inet 103.110.98.20/26 brd 103.10.86.63 scope global secondary em1:0
valid_lft forever preferred_lft forever
inet6 fe80::46a8:42ff:fe17:3ddd/64 scope link
valid_lft forever preferred_lft forever

3）停止主服務器上的keepalived:

[root@master-node ~]# /etc/init.d/keepalived stop
Stopping keepalived (via systemctl): [ OK ]
[root@master-node ~]# /etc/init.d/keepalived status
[root@master-node ~]# ps -ef|grep keepalived
root 26952 24348 0 17:49 pts/0 00:00:00 grep --color=auto keepalived
[root@master-node ~]#

4）然后在從服務器上查看，發現已經接管了VIP：

[root@slave-node ~]# ip addr
.......
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 44:a8:42:17:3c:a5 brd ff:ff:ff:ff:ff:ff
inet 103.110.98.24/26 brd 103.10.86.63 scope global em1
inet 103.110.98.20/32 scope global em1
inet6 fe80::46a8:42ff:fe17:3ca5/64 scope link
valid_lft forever preferred_lft forever
.......

發現master的keepalived服務掛了后，vip資源自動漂移到slave上，並且網站正常訪問，絲毫沒有受到影響！

5）重新啟動主服務器上的keepalived，發現主服務器又重新接管了VIP，此時slave機器上的VIP已經不在了

[root@master-node ~]# /etc/init.d/keepalived start
Starting keepalived (via systemctl): [ OK ]
[root@master-node ~]# ip addr
.......
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 44:a8:42:17:3d:dd brd ff:ff:ff:ff:ff:ff
inet 103.110.98.14/26 brd 103.10.86.63 scope global em1
valid_lft forever preferred_lft forever
inet 103.110.98.20/32 scope global em1
valid_lft forever preferred_lft forever
inet 103.110.98.20/26 brd 103.10.86.63 scope global secondary em1:0
valid_lft forever preferred_lft forever
inet6 fe80::46a8:42ff:fe17:3ddd/64 scope link
valid_lft forever preferred_lft forever
......

[root@slave-node ~]# ip addr
.......
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 44:a8:42:17:3c:a5 brd ff:ff:ff:ff:ff:ff
inet 103.110.98.24/26 brd 103.10.86.63 scope global em1
inet6 fe80::46a8:42ff:fe17:3ca5/64 scope link
valid_lft forever preferred_lft forever

接着驗證下nginx服務故障，看看keepalived監控nginx狀態的腳本是否正常？
如下：手動關閉master機器上的nginx服務，最多2秒鍾后就會自動起來（因為keepalive監控nginx狀態的腳本執行間隔時間為2秒）。域名訪問幾乎不受影響！

[root@master-node ~]# /usr/local/nginx/sbin/nginx -s stop
[root@master-node ~]# ps -ef|grep nginx
root 28401 24826 0 19:43 pts/1 00:00:00 grep --color=auto nginx
[root@master-node ~]# ps -ef|grep nginx
root 28871 28870 0 19:47 ? 00:00:00 /bin/sh /opt/chk_nginx.sh
root 28875 24826 0 19:47 pts/1 00:00:00 grep --color=auto nginx
[root@master-node ~]# ps -ef|grep nginx
root 28408 1 0 19:43 ? 00:00:00 nginx: master process /usr/local/nginx/sbin/nginx
www 28410 28408 0 19:43 ? 00:00:00 nginx: worker process
www 28411 28408 0 19:43 ? 00:00:00 nginx: worker process
www 28412 28408 0 19:43 ? 00:00:00 nginx: worker process
www 28413 28408 0 19:43 ? 00:00:00 nginx: worker process

最后可以查看兩台服務器上的/var/log/messages，觀察VRRP日志信息的vip漂移情況~~~~

可能出現的問題

1）VIP綁定失敗
原因可能有：
-> iptables開啟后，沒有開放允許VRRP協議通信的策略（也有可能導致腦裂）；可以選擇關閉iptables
-> keepalived.conf文件配置有誤導致，比如interface綁定的設備錯誤

2）VIP綁定后，外部ping不通
可能的原因是：
-> 網絡故障，可以檢查下網關是否正常；
-> 網關的arp緩存導致，可以進行arp更新，命令是"arping -I 網卡名 -c 5 -s VIP 網關"

重磅福利

關注「 冰河技術 」微信公眾號，后台回復 “設計模式” 關鍵字領取《深入淺出Java 23種設計模式》PDF文檔。回復“Java8”關鍵字領取《Java8新特性教程》PDF文檔。回復“限流”關鍵字獲取《億級流量下的分布式限流解決方案》PDF文檔，三本PDF均是由冰河原創並整理的超硬核教程，面試必備！！

好了，今天就聊到這兒吧！別忘了點個贊，給個在看和轉發，讓更多的人看到，一起學習，一起進步！！

寫在最后

如果你覺得冰河寫的還不錯，請微信搜索並關注「 冰河技術 」微信公眾號，跟冰河學習高並發、分布式、微服務、大數據、互聯網和雲原生技術，「 冰河技術 」微信公眾號更新了大量技術專題，每一篇技術文章干貨滿滿！不少讀者已經通過閱讀「 冰河技術 」微信公眾號文章，吊打面試官，成功跳槽到大廠；也有不少讀者實現了技術上的飛躍，成為公司的技術骨干！如果你也想像他們一樣提升自己的能力，實現技術能力的飛躍，進大廠，升職加薪，那就關注「 冰河技術 」微信公眾號吧，每天更新超硬核技術干貨，讓你對如何提升技術能力不再迷茫！

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 Nginx+keepalived 雙機熱備（主從模式） Nginx+Keepalived主從雙機熱備+自動切換 Nginx+keepalived 高可用雙機熱備（主從模式/雙主模式） Nginx+keepalived 雙機熱備（主主模式） Nginx+Keepalived雙機熱備 Nginx+Keepalived(雙機熱備)搭建高可用負載均衡環境(HA) nginx + keepalived 雙機熱備 haproxy/nginx+keepalived負載均衡雙機熱備郵件報警實戰及常見問題 keepalived nginx 雙機熱備圖文講解 docker nginx1.7.6+keepalived實現雙機熱備