nginx主主叢集

在和一些朋友交流Nginx+Keepalived技術時，我雖然已成功多次實Nginx+Keepaived項目方案，但這些都是用的單主Nginx在工作，從Nginx長期只是處於備份狀態，所以我們想將二台Nginx負載平衡器都處於工作狀態，其實用Nginx+Keepalived也很容易實現。此方法適用情境：適合中小型網站應用程式情境。
一般為了維護方便，企業網站的伺服器都在自己的內部機房裡，只開放了Keepalived的VIP地址的兩個連接埠80、443，通過Juniper SSG550防火牆映射出去，外網DNS對應映射後的公網IP。此架構的防火牆及網路安全記事如下：
此系統架構僅映射內網VIP的80及443連接埠於外網的Juniper SSG550防火牆下，其他連接埠均關閉，內網所有機器均關閉iptables防火牆；外網DNS指向即通過Juniper SSG550映射出來的外網地址。
Nginx負載平衡作伺服器遇到的故障一般有：1.伺服器網線鬆動等網路故障；2.伺服器硬體故障發生損壞現象而crash；3.Nginx服務進程死掉（這種情況理論上會遇到，但事實上生產環境下的Linux伺服器沒有出現過這種情況，足以證明了Nginx作為負載平衡器/反向 Proxy伺服器的穩定性，我們可以通過技術手段來解決這一問題）。
測試實驗環境：
主Nginx之一：192.168.1.5
主Nginx之二：192.168.1.6
Web伺服器一：192.168.1.17
Web伺服器二：192.168.1.18
VIP地址一：192.168.1.8
VIP地址二：192.168.1.9
一、Nginx和Keepalived的安裝比較簡單，我這裡就不重複了，大家可以參考我的專題系列的文章，如下地址http://network.51cto.com/art/201007/209823.htm，我這裡附上Nginx.conf設定檔，如下所示：
    user www www;
    worker_processes 8;
    pid /usr/local/nginx/logs/nginx.pid;
    worker_rlimit_nofile 51200;
    events
    {
    use epoll;
    worker_connections 51200;
    }
    http{
    include       mime.types;
    default_type application/octet-stream;
    server_names_hash_bucket_size 128;
    client_header_buffer_size 32k;
    large_client_header_buffers 4 32k;
    client_max_body_size 8m;
    sendfile on;
    tcp_nopush     on;
    keepalive_timeout 60;
    tcp_nodelay on;
    fastcgi_connect_timeout 300;
    fastcgi_send_timeout 300;
    fastcgi_read_timeout 300;
    fastcgi_buffer_size 64k;
    fastcgi_buffers 4 64k;
    fastcgi_busy_buffers_size 128k;
    fastcgi_temp_file_write_size 128k;
    gzip on;
    gzip_min_length 1k;
    gzip_buffers     4 16k;
    gzip_http_version 1.0;
    gzip_comp_level 2;
    gzip_types       text/plain application/x-javascript text/css application/xml;
    gzip_vary on;
    
    upstream backend
    {
    ip_hash;
server 192.168.1.17:80;
    server 192.168.1.18:80;
    }
    server {
    listen 80;
    server_name www.1paituan.com;
    location / {
    root /var/www/html ;
    index index.php index.htm index.html;
    proxy_redirect off;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://backend;
    }
    
    location /nginx {
    access_log off;
    auth_basic "NginxStatus";
    #auth_basic_user_file /usr/local/nginx/htpasswd;
    }
    
    log_format access '$remote_addr - $remote_user [$time_local] "$request" '
    '$status $body_bytes_sent "$http_referer" '
    '"$http_user_agent" $http_x_forwarded_for';
    access_log /data/logs/access.log access;
    }
 
二、配置Keepalived檔案，我這裡簡單說下原理，其實也就是通過Keepalived產生二個執行個體，二台Nginx互為備份，即第一台是第二台機器的備機，而第二台機器也是第一台的備機，而產生的二個VIP地址分別對應我們網站http://www.1paituan.com，這樣大家在公網上可以通過DNS輪詢來訪問得到我們的網站，任何一台Nginx機器如果發生硬體損壞，Keepalived會自動將它的VIP地址切換到另一台機器，不影響用戶端的訪問，這個跟我們以前的LVS+Keepalived多執行個體的原理是一樣的，相信大家也能明白。
主Nginx機器之一的Keepalived.conf設定檔如下：
! Configuration File for keepalived
global_defs {
   notification_email {
   yuhongchun027@163.com
        }
   notification_email_from keepalived@chtopnet.com
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL
}
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1paituan.com
    }
    virtual_ipaddress {
        192.168.1.8
    }
}
vrrp_instance VI_2 {
    state BACKUP
    interface eth0
    virtual_router_id 52
    priority 99
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1paituan.com
    }
    virtual_ipaddress {
        192.168.1.9
    }
}
 
主Nginx之二的keepalivd.conf設定檔如下：
! Configuration File for keepalived
global_defs {
   notification_email {
   yuhongchun027@163.com
        }
   notification_email_from keepalived@chtopnet.com
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL
}
vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 99
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1paituan
    }
    virtual_ipaddress {
        192.168.1.8                  
    }
}
vrrp_instance VI_2 {
    state MASTER
    interface eth0
    virtual_router_id 52
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1paituan
    }
    virtual_ipaddress {
        192.168.1.9                  
    }
}
 
二台機器的監控Nginx的進程指令碼，指令碼內容如下：
#!/bin/bash
while  :
do
 nginxpid=`ps -C nginx --no-header | wc -l`
 if [ $nginxpid -eq 0 ];then
  /usr/local/nginx/sbin/nginx
  sleep 5
  nginxpid=`ps -C nginx --no-header | wc -l`
  echo $nginxpid
    if [ $nginxpid -eq 0 ];then
 /etc/init.d/keepalived stop
   fi
 fi
 sleep 5
done
 
我們分別在二台主Nginx上執行，命令如下所示：
nohup sh /root/nginxpid.sh & 
 
此指令碼我是直接從生產伺服器上下載的，大家不要懷疑它會引起死迴圈和有效性的問題，我稍為解釋一下，這是一個無限迴圈的指令碼，放在主Nginx機器上（因為目前主要是由它提供服務），每隔5秒執行一次，用ps -C 命令來收集nginx的PID值到底是否為0，如果是0的話（即Nginx進程死掉了），嘗試啟動nginx進程；如果繼續為0，即nginx啟動失改， 則關閉原生Keeplaived進程，VIP地址則會由備機接管，當然了，整個網站就會由備機的Nginx來提供服務了，這樣保證Nginx進程的高可用。
四、正常啟動二台主Nginx的Nginx和Keealived程式後，二台機器的正常IP顯示應該如下所示：
這台是IP為192.168.1.5的機器的ip addr命令顯示結果：
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0c:29:99:fb:32 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.5/24 brd 192.168.1.255 scope global eth0
  inet 192.168.1.8/32 scope global eth0
 
這台是IP為192.168.1.6的機器的ip addr命令顯示結果：
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0c:29:7d:58:5e brd ff:ff:ff:ff:ff:ff
inet 192.168.1.6/24 brd 192.168.1.255 scope global eth0
inet 192.168.1.9/32 scope global eth0
inet6 fe80::20c:29ff:fe7d:585e/64 scope link
valid_lft forever preferred_lft forever
3: sit0: <NOARP> mtu 1480 qdisc noop
  link/sit 0.0.0.0 brd 0.0.0.0
 
五、測試過程如下：
一、我們要分別在二台主Nginx上用killall殺掉Nginx進程，然後在用戶端分別訪問192.168.1.8和192.168.1.9這二個IP（類比DNS輪詢）看能否正常訪問Web伺服器。
二、嘗試重啟192.168.1.5的主Nginx負載平衡器，測試過程如上；
三、嘗試重啟192.168.1.6的主Nginx負載平衡器，測試過程如下；
四、嘗試分別關閉192.168.1.5和192.168.1.6的機器，測試過程如上，看影響網站的正常訪問不?
六、目前投入生產要解決的問題：
一、Cacti和Nagios等監控服務要重新部署，因為現在客戶機是分別訪問二台負載平衡器；
二、日誌收集要重新部署，現在訪問日誌是分布在二台負載平衡器上；
三、要考慮google收錄的問題；
四、認證的問題，二台機器都需要；
五、其它問題暫時沒有想到，待補充。
作者“撫琴煮酒”