當下Linux運維技術越來越受到企業的關注和追捧, 在某些企業, 尤其是牽涉到電子商務和電子廣告類的網站，通常會要求作負載均衡和高可用的Linux集群方案。那么如何實施Llinux集群架構，才能既有效保證網站健康運行，又能節省運維成本呢？以下是根據本人幾年的運維經歷，簡單梳理下自己的一點感悟。
1) 機房的選擇
如果有自己公司的機房那是再好不過的了；如果沒有，建議放在BGP機房內托管，如果有選擇的話，最好是選擇帶有硬件防火牆的機房，這樣在安全方面也有保障；
網站如若是放在IDC機房托管，而機房最前面也沒有硬件防火牆防護時，要盡量做好流量監控的工作（尤其是Nginx/Haproxy負載機的流量），一般選用Zabbix監控軟件.服務器的選擇一切以穩定為前提和原則，在價格能得到公司接受的情況下，可以選擇像IBM和DELL的品牌服務器，質量有保障。在服務器資源緊張的情況下，可以部署openstack虛擬化，虛擬機可以充當test機器，beta機器以及對內業務部署機，充分利用機器資源。
2）負載均衡+高可用集群方案的選擇
負載均衡實施
2.1) 一種是通過硬件來實施
常見硬件有比較昂貴的NetScaler、F5、Radware和Array等商用負載均衡器，優點是有專業團隊維護，缺點是花銷太大，對於網絡規模較小的企業網站來說沒有必要；
2.2) 一種是通過開源免費負載均衡軟件策略實施
常用的是LVS、HAProxy、Nginx負載均衡,這些都是通過軟件級別來實現，費用非常低廉，對於中小企業來說，鑒於成本問題，選擇這一種比較靠譜。
高可用實施
首推是Nginx/Haproxy+Keepalived的架構，那么為什么不選擇基於LVS+Keepalived的集群方案呢？
因為我們部署的網站一般都會涉及到動靜分離、正則分發的需求，如果網站最前面選用LVS+Keepliaved架構，那么至少又要在中間加一層二級負載均衡的機器，這樣比較耗機器，無形中也會增加整個網站的成本；
有人會認為Nginx/Haproxy+Keepalived的穩定性不如LVS+Keepalived，其實這是個誤解！
通過近幾年的觀察期，加上十幾個項目的成功實施，發現Nginx/HAProxy+Keepalived的負載均衡器的穩定性很好，尤其是Haproxy+keepalive在高並發的情況下宕機可能性微乎其微。一個朋友的公司在近段時間實施的一個商業網站用的是HAProxy+Keepalived，在億/日高並發流量的沖擊下，HAProxy穩如磐石。LVS在性能方面是公認最好的，尤其是后面的節點(如Web或MySQL數據庫服務器)超過10台時，它的性能是最優異的。中小公司的並發和流量一般不是特別大，每日pv持續在百萬之內的，推薦使用Nginx/Haproxy+Keepalived。
負載均衡+高可用方案在節省成本的提前下，一般需要多少台服務器？
一般來說，中小網站采用2+2+2架構即可。最前面是2台Nginx/Haproxy+Keeplaived機器，后面是2台配置比較好的web機器；數據庫2台，一主一從方式。
服務器之間的數據同步采用Rsync+Inotify實時同步方案。如果時效性不是那么高，可以采用純Rsync方式，結合Crontab進行定時同步。
如果對文件服務器有更高要求比如圖片類型，可以考慮再增加2台服務器，做成DRBD+Heartbeat+NFS方式；
如果有海量文件需要存儲的話，還可以考慮用MFS，當然這樣也是比較耗機器的。
3）集群架構中同步session問題
中小型網站可以采用Nginx的ip_hash和Haproxy的balance source機制，它們的原理比較類似，都會讓某一客戶機在相當長的一段時間內只訪問固定的后端的某台真實的Web服務器，這樣會話就會得以保持，我們在網站頁面進行login的時候，就不會在后面的web服務器之間跳來跳去了，自然也不會出現登陸一次后網站又提醒你沒有登陸需要重新登陸的情況；
如果是大型項目或網站可以考慮用Memcached的方式。
session共享問題可以參考：http://www.cnblogs.com/kevingrace/p/6031356.html
4）web服務選擇Apache or Nginx
在網站流量和並發不大的環境下，完全可以選擇Apache作為Web服務，雖然它的抗並發能力不高，但它的穩定性是最好的，許多電子商務網站都是基於Apache；
如果網站是大流量大並發的環境下，強烈推薦Nginx作為web服務。
5）數據庫方案:Master-Slave
中小型企業網站，Mysql數據庫采用一主一從方案即可滿足業務需求，然后看起來比較單一，但是事實證明，這種設計的穩定性也是非常靠譜的！經驗證，采用mysql一主一從方案好多年的網站，很少沒有因為數據庫的故障發生過丟數據現象。網站上線的前期階段，可以通過PHP程序，把后台的查詢功能的入口選擇Slave機器，這樣可以大大減少主數據庫的壓力；Slave機器並非僅僅只起一個備份和備機的作用，完全可以通過Php程序將后台的復雜查詢轉到從MySQL機器上。
==========================運維場景中web高可用架構方式=========================
Keepalived和Heartbeat都是用來提高高可用性的工具，避免單點故障。那么它們有什么區別呢？又是怎么搭配的呢?
1) 二者區別
LVS 是通過VRRP協議進行數據包轉發的，提供的是四層的負載均衡, 特點是效率高，只要服務器網卡抗的住就不是問題。
Haproxy 可以提供四層或七層的數據轉發服務，能做到七層的好處是可以根據服務所處的狀態等進行負載。
2) 搭配方式
以上兩者只是實現了負載均衡，但是他們本身是明顯的單點故障，因此需要使用雙機軟件做熱備，來保證高可用性。
Keepalived可以通過檢測VRRP數據包來切換，因此Keepalived更適合與LVS搭配; Heartbeat更適於和Haproxy搭配。
正常情況下, LVS+Keepalived 和 Haproxy+Heartbeat 這兩個搭配方式是運維場景中運用比較多也比較經典的負載均衡高可用性方案了。
此外, Nginx + Keepalived 和 Haproxy + Keepalived搭配方式也是常見的一種負載均衡高可用方案.
四層負載均衡: 從第四層"傳輸層"開始, 基於tcp協議, 使用"ip+port"接收請求，再轉發到對應的機器; 四層負載均衡比較靈活, 可以做任何基於tcp/ip協議的軟件的負載均衡。
七層負載均衡: 從第七層"應用層"開始, 基於http協議, 根據虛擬的url或IP，主機名接收請求，再轉向相應的處理服務器。七層負載均衡適用於web服務器的負載均衡。
總的來說:
- LVS 提供四層負載均衡 ;
- Haproxy 提供七層負載均衡, 但它比較靈活, 四層負載均衡也可以做 ;
- Nginx 一般提供的是七層負載均衡, 但是從Nginx1.9.0版本后, 可以通過stream模塊做四層負載均衡 ;
- 這三種負載均衡都提供健康檢查,故障轉移, 自動切換機制; 負載均衡層發生故障時, 通過漂移VIP資源來實現故障無感知切換, 待故障修復后再接回自己的VIP資源(這個具體要根據配置中的策略而定); 后端節點發生故障后,會自動被踢出集群環境, 待故障修復后再回到集群環境中.
- 負載均衡層必須和后端節點之間要能正常通信, 如果負載均衡層只有一個網卡設備, 比如eth0, 則心跳線功能(Keepalive和Heartbeat)和與后端節點通信都走這個eth0網卡(VIP地址也是eth0網段); 如果負載均衡層有兩個網卡設備, 比如eth0(內網)和eth1(外網), 則eth0網卡用於和后端節點(也是eth0)通信, eth1網卡用於心跳線功能(VIP地址是eth1網段);
下面是運維場景中web網站常用的幾種高可用架構圖, 簡單展示下:
1) LVS+Keepalived+Tomcat/Nginx/其他web服務
2) Haproxy+Heartbeat+Tomcat/Nginx/其他web服務
3) Haproxy+Keepalived+Tomcat/Nginx/其他web服務
4) Nginx+Keepalived+Tomcat/Nginx/其他web服務
當然, 除了上面常用的幾種搭配方式, 其他搭配也是可以的, 比如 LVS+Heartbeat也是可以的.; 其他應用也可以使用這些部署高可用, 比如LVS+Keepalive+Mysql, Heartbeat+haproxy+MySQL, Redis+Keepalived等.
實現高可用的目的: 一是防止單點故障，另一個是實現負載均衡。當然負載均衡也可以防止單點故障，但負載均衡器本來就會產生單點故障，用一個產生問題的方法解決產生的問題，那這個問題怎么解決? 其實真正從源頭上解決單點故障這個問題, 需要使用如上所示Keepalived或Heartbeat, 它們兩個可以解決單點故障問題（雙機熱備, VIP漂移）卻不會引出新的單點故障問題; 然后再使用Haproxy, Nginx 或LVS做負載均衡，后端再跟web服務或其他應用服務多節點, 這樣即可做成負載均衡高可用方案了。