當下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服務或其他應用服務多節點, 這樣即可做成負載均衡高可用方案了。