Nginx主主負載均衡架構
原創【51CTO.com 獨家特稿】在和一些朋友交流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負載均衡作服務器遇到的故障一般有：服務器網線松動等網絡故障；服務器硬件故障發生損壞現象而crash；
Nginx服務進程死掉（這種情況理論上會遇到，但事實上生產環境下的Linux服務器沒有出現過這種情況，足以證明了Nginx作為負載均衡器/反向代理服務器的穩定性，我們可以通過技術手段來解決這一問題）。
測試實驗環境：
主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;
- }
- }
#p#
二、 配置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
- }
- }
#p#
三、大家都知道Keepalived是實現不了程序級別的高可用的，所以我們要寫SHELL腳本，來實現Nginx的高可用，腳本/root/nginxpid.sh內容如下：
- #!/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`
- 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進程的高可 用。
#p#
四、正常啟動二臺主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收錄的問題；
四、證書的問題，二臺機器都需要；
五、其它問題暫時沒有想到，待補充。
【51CTO.com獨家特稿，非經授權謝絕轉載！合作媒體轉載請注明原文出處及出處！】
