Nginx負載均衡器排障實錄
原創【51CTO.com獨家特稿】這段時間，公司的web架構要升級，考慮用負載均衡；初期準備采用LVS+Keepalived，我比較有自信，剛剛在一個客戶的局域網里實現了這個，所以直接把腳本移過來了；然而，杯具開始了，發現LVS怎么也實現不了后端二臺web的轉發。
后來關于此問題我請教了田逸兄，他懷疑我們的網絡環境太復雜了，因為牽涉到內外網的問題，我們的每臺機器上有5條靜態路由，2個gateway，直接導致了LVS的不成功；我們試圖跟network Engeneer溝通，結果是網絡不能做一絲一毫改動，所以白白測試了二天。
后來改用了Nginx負載均衡器，5分鐘就解決了問題，真真切切的體會到了Nginx對網絡的依賴較小，理論上只要ping得通，網頁訪問正常，nginx就能連得通。為了以防萬一，我采用的是Nginx+keepalived高可用架構。
在這里，我不是神話Nginx，只是說這是一種解決問題的方法而矣，LVS也有適用的場合，穩定性方面是眾所周知的，所以只要提到web層的負載均衡，我就想到LVS，但LVS不僅僅是；如果網絡環境比較復雜的朋友們，不妨換種思路解決問題。
當然用了Nginx后，大問題暫時沒有；小問題就都來了，首先是SSL，這個目前支持得算是比較好的，在負載均衡器上開啟ssl功能，監聽443端口，將證書放在Nginx代理上，非后面的web服務器,輕構解決掉問題，詳細見以下http.conf配置文件
- server
- {
- listen 443;
- server_name www.cn7788.com;
- ssl on;
- ssl_certificate /usr/local/nginx/keys/www.cn7788.com.crt;
- ssl_certificate_key /usr/local/nginx/keys/www.cn7788.com.key;
- ssl_protocols SSLv3 TLSv1;
- ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP;
- }
但問題又來了，這么有個問題，跑在后方 apache 上的應用獲取到的IP都是Nginx所在服務器的IP ，或者是本機 127.0.0.1 。最明顯就是查看 apache 的訪問日志。就會見到來來去去都是內網的IP；雖然可以通過Nginx日志來判斷客戶的client,但有些考慮不周全的應用，例如 Tattertools (一個博客程序) 就會犯誤,后臺的訪問日志死活顯示訪客數 1，ip來自 127.0.0.1。這時候就要想辦法來處理了。你可以通過修改 nginx proxy 的參數令后端應用獲取到Nginx 發來的請求報文獲取到外網的IP。
- proxy_set_header Host $host;
- proxy_set_header X-Real-IP $remote_addr;
- proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
這僅僅只是讓Nginx獲到到外網IP，Apache未必買帳呢，即Aapche端也需要設置，搜尋了一下，發現了apache這一個來自第三方的mod 配合Nginx proxy 使用。
說明：http://stderr.net/apache/rpaf/
下載：http://stderr.net/apache/rpaf/download/
最新版本是 mod_rpaf-0.6.tar.gz
安裝也相當簡單。
# tar zxvf mod_rpaf-0.6.tar.gz 下載后解壓# cd mod_rpaf-0.6
Apache 的目錄按自己的環境修改，并選擇相應的安裝方式：
#/usr/local/apache/bin/apxs -i -c -n mod_rpaf-2.0.so mod_rpaf-2.0.c
完成后會在 http.conf 的 LoadModule 區域為你多加了一行。
LoadModule mod_rpaf-2.0.so_module modules/mod_rpaf-2.0.so 經 apache 2.2.6 的實驗，使用這一行啟動 apache 的時候會報錯的。
所以改為：
LoadModule rpaf_module modules/mod_rpaf-2.0.so
并在下方添加
- RPAFenable On
- RPAFsethostname On
- RPAFproxy_ips 127.0.0.1 192.168.1.101 192.168.102
#填寫Nginx所在的內網IP，Nginx的內網地址必寫，不然一樣失敗的，這問題花了幾個小時測試；有幾個代理服務器的IP就寫幾個代理服務器的IP
RPAFheader X-Forwarded-For
保存退出后重啟apache，再看看 apache 的日志內容？不再是來來去去的那幾個IP了吧，呵呵。
另外這里來個小插曲，我做的某個小項目本為是基于Nginx的1+3架構，突然要加一臺機器是windows2003系統，專門作存放圖片及 PDF等，但項目的要求是能在nginx后的三臺web上有顯示圖片及pdf下載的需求；當時迷糊了下，因為程序是用到的Zend Framwork，所以一直用正則作跳轉；后來才想明白，IE程序是先在nginx負載均衡器上提申請，所以nginx.conf是做分發而非正則跳轉，此時最前端的nginx，既是負載勻衡器也是反向代理，明白這個就好做多了，語法如下；另外注意location /StockInfo與location ~^/StockInfo的差異性，Nginx默認的是正則優先的，by the way,proxy_pass支持直接寫IP的方式。
- upstream mysrv {
- ip_hash;
- server 192.168.110.62;
- server 192.168.110.63;
- }
- upstream myjpg {
- server 192.168.110.3:88;
- }
- server
- {
- listen 80;
- server_name web.tfzq.com;
- proxy_redirect off;
- location ~ ^/StockInfo{
- proxy_pass http://myjpg;
- }
再說下Nginx下的并發，這是個容易讓人誤會的概念。現在Nginx的文章滿天飛，好像只要一涉及到web并發，就非將Apache換成nginx不可，其實完全沒這必要；在內存足夠的情況，Apache的抗并發能力也是很強的。玩了幾年nginx了，遇到的最大并發也是以前在北京維護的CDN之廣告網站，大約在3000-5000之間(這種情況建議用Nginx)，一般的資訊類金融網站也就100多，電子商務網站1100左右，web層的并發壓力并沒有想象中的大；相反，我感覺文件和數據層的壓力越來越大，單個NFS服務器越來越難受了，所以我后期準備布署moosefs；而mysql數據庫我一般用的是主從復制，壓力也不小，目前只是從二方面來解決此問題：一、用公司最好的服務器來作數據庫服務器；二、盡可能的優化，如果壓力持續增長的話，后期我考慮從架構級方面優化了。對于一個網站而言，建議多從架構極的觀念來看問題和解決問題。
今天一直測試網站的響應時間是用Linux/unix下工具httping,今天同事找了個專業網站給我，發現很好用，特的拿出來與大家共享http://tools.pingdom.com,可以測試個幾十次然后取平均值，這樣得出的結果較為精準；系統運維工作本來就是一個細膩活，有時短短幾行代碼，說不定就要調試幾天；而有時維護的服務器日志，經常是十幾萬行，看得人心花繚亂...痛并快樂著，這也是算是目前工作的心態吧。
【51CTO.com獨家特稿，非經授權謝絕轉載，合作媒體轉載請注明原文出處及作者！】
