19個心得 明明白白說Linux下的負載均衡

    前言:做爲一名Linux/unix系統工程師,這幾年一直在涉及到對外項目,經手過許多小中型網站的架構,F五、LVS及Nginx接觸的都比較多,我想一種比較通俗易懂的語氣跟你們說明下何謂負載均衡,何謂Linux集羣,幫助你們走出這個誤區,真正意義上來理解它們,項目施工案例請參考我在network.51cto.com上的同類文章。前端

    1、目前網站架構通常分紅負載均衡層、web層和數據庫層,我其實通常還會多加一層,即文件服務器層,由於如今隨着網站的PV愈來愈多,文件服務器的壓力也愈來愈大;不過隨着moosefs、DRDB+Heartbeat+NFS的日趨成熟,這問題也不大了.網站最前端的負載均衡層稱之爲Director,它起的是分攤請求的做用,最多見的就是輪詢。linux

    2、F5是經過硬件的方式來實現負載均衡,它較多應用於CDN系統,用於squid反向加速集羣的負載均衡,是專業的硬件負載均衡設備,尤爲適用於每秒新建鏈接數和併發鏈接數要求高的場景;LVS和Nginx是經過軟件的方式來實現的,但穩定性也至關強悍,在處理高併發的狀況也有至關不俗的表現。ios

    3、Nginx對網絡的依賴較小,理論上只要ping得通,網頁訪問正常,nginx就能連得通,nginx同時還能區份內外網,若是是同時擁有內外網的節點,就至關於單機擁有了備份線路;lvs就比較依賴於網絡環境,目前來看服務器在同一網段內而且lvs使用direct方式分流,效果較能獲得保證。nginx

    4、目前較成熟的負載均衡高可用技術有LVS+Keepalived、Nginx+Keepalived,之前Nginx沒有成熟的雙機備份方案,但經過shell腳本監控是能夠實現的,有興趣的可具體參考我在51cto上的項目實施方案;另外,若是考慮Nginx的負載均衡高可用,也能夠經過DNS輪詢的方式來實現,有興趣的能夠參考張宴的相關文章。web

    5、集羣是指負載均衡後面的web集羣或tomcat集羣等,但如今的集羣意義泛指了整個系統架構,它包括了負載均衡器以及後端的應用服務器集羣等,如今許多人都喜歡把Linux集羣指爲LVS,但我以爲嚴格意義上應該區分開。sql

    6、負載均衡高可用中的高可用指的是實現負載均衡器的HA,即一臺負載均衡器壞掉後另外一臺能夠在<1s秒內切換,最經常使用的軟件就是Keepalived和Heatbeat,成熟的生產環境下的負載均衡器方案有Lvs+Keepalived、Nginx+Keepalived。shell

    7、LVS的優點很是多:①抗負載能力強;②工做穩定(由於有成熟的HA方案);③無流量;④基本上能支持全部的應用,基於以上的優勢,LVS擁有很多的粉絲;但世事無絕對,LVS對網絡的依賴性太大了,在網絡環境相對複雜的應用場景中,我不得不放棄它而選用Nginx。數據庫

    8、Nginx對網絡的依賴性小,並且它的正則強大而靈活,強悍的特色吸引了很多人,並且配置也是至關的方便和簡約,小中型項目實施中我基本是考慮它的;固然,若是資金充足,F5是不二的選擇。後端

    9、大型網站架構中其實能夠結合使用F五、LVS或Nginx,選擇它們中的二種或三種所有選擇;若是由於預算的緣由不選擇F5,那麼網站最前端的指向應該是LVS,也就是DNS的指向應爲lvs均衡器,lvs的優勢令它很是適合作這個任務。重要的ip地址,最好交由lvs託管,好比數據庫的ip、webservice服務器的ip等等,這些ip地址隨着時間推移,使用面會愈來愈大,若是更換ip則故障會接踵而至。因此將這些重要ip交給lvs託管是最爲穩妥的。tomcat

    10、VIP地址是Keepalived虛擬的一個IP,它是一個對外的公開IP,也是DNS指向的IP;因此在設計網站架構時,你必須向你的IDC多申請一個對外IP

    11、在實際項目實施過程當中發現,Lvs和Nginx對https的支持都很是好,尤爲是LVS,相對而言處理起來更爲簡便。

    12、在LVS+Keepalived及Nginx+Keepalived的故障處理中,這兩者都是很方便的;若是發生了系統故障或服務器相關故障,便可將DNS指向由它們後端的某臺真實web,達到短時間處理故障的效果,畢竟廣告網站和電子商務網站的PV就是金錢,這也是爲何要將負載均衡高可用設計於此的緣由;大型的廣告網站我就建議直接上CDN系統了。

    十3、如今Linux集羣都被你們神話了,其實這個也沒多少複雜;關鍵看你的應用場景,哪一種適用就選用哪一種,Nginx和LVS、F5都不是神話,哪一種方便哪一種適用就選用哪一種。

    十4、另外關於session共享的問題,這也是一個老生長談的問題了;Nginx能夠用ip_hash機制來解決session的問題,而F5和LVS都有會話保持機制來解決這個問題,此外,還能夠將session寫進數據庫,這也是一個解決session共享的好辦法,固然這個也會加劇數據庫的負擔,這個看系統架構師的取捨了。

    十5、我如今目前維護的電子商務網站併發大約是1000左右,之前的證券資訊類網站是100左右,大型網上廣告大約是3000,我感受web層的併發愈來愈不是一個問題;如今因爲服務器的強悍,再加上Nginx做web的高抗併發性,web層的併發並非什麼大問題;相反而言,文件服務器層和數據庫層的壓力是愈來愈大了,單NFS不可能勝任目前的工做,如今好的方案是moosefs和DRDB+Heartbeat+NFS;而我喜歡的Mysql服務器,成熟的應用方案仍是主從,若是壓力過大,我不得不選擇oracle的RAC雙機方案。

    十6、如今受張宴的影響,你們都去玩Nginx了(尤爲是做web),其實在服務器性能優異,內存足夠的狀況下,Apache的抗併發能力並不弱,整個網站的瓶頸應該仍是在數據庫方面;我建議能夠雙方面瞭解Apache和Nginx,前端用Nginx做負載均衡,後端用Apache做web,效果也是至關的好。

    十7、Heartbeat的腦裂問題沒有想象中那麼嚴重,在線上環境能夠考慮使用;DRDB+Heartbeat算是成熟的應用了,建議掌握。我在至關多的場合用此組合來替代EMC共享存儲,畢竟30萬的價格並非每一個客戶都願意接受的。

    十8、不管設計的方案是多麼的成熟,仍是建議要配置Nagios監控機來實時監控咱們的服務器狀況;郵件和短信報警均可以開啓,畢竟手機能夠隨身攜帶嘛;有條件的還能夠購買專門的商業掃描網站服務,它會每隔一分鐘掃描你的網站,若是發現沒有alive會向你的郵件發警告信息或直接電話聯繫。

    十9、至少網站的安全性問題,我建議用硬件防火牆,比較推薦的是華賽三層防火牆+天泰web防火牆,DDOS的安全防禦必定要到位;Linux服務器自己的iptables和SElinux都可關閉,固然,端口開放越少越好。

    補充說明:測試網站的響應時間是用http://tools.pingdom.com,發現上了LVS+Keepalived、Nginx+Keepalived後並不影響速度,這一點你們就不要多慮了,Nginx如今做反向加速也日趨成熟了。