Nginx、LVS、HAProxy 是目前使用最廣泛的三種負載均衡軟體，本人都在多個專案中實施過，通常會結合Keepalive做健康檢查，實現故障轉移的高可用功能。

1）在四層（tcp）實現負載均衡的軟體：

lvs------>重量級
nginx------>輕量級，帶快取功能，正則表示式較靈活
haproxy------>模擬四層轉發，較靈活

2）在七層（http）實現反向代理的軟體：

haproxy------>天生技能，全面支援七層代理，會話保持，標記，路徑轉移；
nginx------>只在http協議和mail協議上功能比較好，效能與haproxy差不多；
apache------>功能較差<br>
總的來說，一般是lvs做4層負載；nginx做7層負載；haproxy比較靈活，4層和7層負載均衡都能做一般對負載均衡的使用是隨著網站規模的提升根據不同的階段來使用不同的技術。具體的應用需求還得具體分析：
1）如果是中小型的 Web 應用，比如日PV小於1000 萬，用 Nginx 就完全可以了；
2）如果機器不少，可以用DNS輪詢， LVS所耗費的機器還是比較多的；大型網站或重要的服務，且伺服器比較多時，可以考慮用LVS。
還有一種是通過硬體來進行進行，常見的硬體有比較昂貴的F5和Array等商用的負載均衡器，它的優點就是有專業的維護團隊來對這些服務進行維護、缺點就是花銷太大，所以對於規模較小
的網路服務來說暫時還沒有需要使用；另外一種就是類似於 Nginx/LVS/HAProxy 的基於 Linux 的開源免費的負載均衡軟體，這些都是通過軟體級別來實現，所以費用非常低廉。目前關於網
站架構一般比較合理流行的架構方案： Web 前端採用Nginx/HAProxy+Keepalived 作負載均衡器；後端採用 MySQL 資料庫一主多從和讀寫分離，採用 LVS+Keepalived 的架構。 當然要根據
專案具體需求制定方案。下面說說各自的特點和適用場合。
下面簡單說下Nginx、LVS、HAProxy 負載均衡軟體的優缺點：

一、Nginx的優點是：

1）工作在網路的7層之上，可以針對 http 應用做一些分流的策略，比如針對域名、目錄結構，它的正則規則比 HAProxy 更為強大和靈活，這也是它目前廣泛流
行的主要原因之一， Nginx 單憑這點可利用的場合就遠多於 LVS 了。
2） Nginx 對網路穩定性的依賴非常小，理論上能 ping 通就就能進行負載功能，這個也是它的優勢之一；相反 LVS 對網路穩定性依賴比較大，這點本人深有體會；
3） Nginx 安裝和配置比較簡單，測試起來比較方便，它基本能把錯誤用日誌打印出來。 LVS 的配置、測試就要花比較長的時間了， LVS 對網路依賴比較大。
4）可以承擔高負載壓力且穩定，在硬體不差的情況下一般能支撐幾萬次的併發量，負載度比 LVS 相對小些。
5） Nginx 可以通過埠檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點，不過其中缺點就是不支援url來檢測。
比如使用者正在上傳一個檔案，而處理該上傳的節點剛好在上傳過程中出現故障， Nginx 會把上傳切到另一臺伺服器重新處 理，而LVS就直接斷掉了，如果是上傳一個很大的檔案或者很重要的文
件的話，使用者可能會因此而不滿。
6）Nginx 不僅僅是一款優秀的負載均衡器/反向代理軟體，它同時也是功能強大的 Web 應用伺服器。 LNMP 也是近幾年非常流行的 web 架構，在高流量的環境中穩定性也很好。
7）Nginx 現在作為 Web 反向加速快取越來越成熟了，速度比傳統的 Squid 伺服器更快，可以考慮用其作為反向代理加速器。
8）Nginx 可作為中層反向代理使用，這一層面 Nginx 基本上無對手，唯一可以對比 Nginx 的就只有 lighttpd 了，不過 lighttpd 目前還沒有做到 Nginx 完全的功能，配置也不那麼清晰易讀，社群資料也遠遠沒 Nginx 活躍。
9） Nginx 也可作為靜態網頁和圖片伺服器，這方面的效能也無對手。還有 Nginx社群非常活躍，第三方模組也很多。
Nginx 的缺點是：
1）Nginx 僅能支援 http、 https 和 Email 協議，這樣就在適用範圍上面小些，這個是它的缺點。
2）對後端伺服器的健康檢查，只支援通過埠來檢測，不支援通過 url 來檢測。不支援 Session 的直接保持，但能通過 ip_hash 來解決。

二、LVS：使用 Linux 核心叢集實現一個高效能、 高可用的負載均衡伺服器，它具有很好的可伸縮性（ Scalability)、可靠性（ Reliability)和可管理性（Manageability)。

LVS 的優點是：

1）抗負載能力強、是工作在網路 4 層之上僅作分發之用， 沒有流量的產生，這個特點也決定了它在負載均衡軟體裡的效能最強的，對記憶體和 cpu 資源消耗比較低。
2）配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人為出錯的機率。
3）工作穩定，因為其本身抗負載能力很強，自身有完整的雙機熱備方案，如LVS+Keepalived，不過我們在專案實施中用得最多的還是 LVS/DR+Keepalived。
4）無流量， LVS 只分發請求，而流量並不從它本身出去，這點保證了均衡器 IO的效能不會收到大流量的影響。
5）應用範圍比較廣，因為 LVS 工作在 4 層，所以它幾乎可以對所有應用做負載均衡，包括 http、資料庫、線上聊天室等等。
LVS 的缺點是：
1）軟體本身不支援正則表示式處理，不能做動靜分離；而現在許多網站在這方面都有較強的需求，這個是 Nginx/HAProxy+Keepalived 的優勢所在。
2）如果是網站應用比較龐大的話， LVS/DR+Keepalived 實施起來就比較複雜了，特別後面有 Windows Server 的機器的話，如果實施及配置還有維護過程就比較複雜了，相對而言，
Nginx/HAProxy+Keepalived 就簡單多了。

三、HAProxy 的特點是：

1）HAProxy 也是支援虛擬主機的。
2）HAProxy 的優點能夠補充 Nginx 的一些缺點，比如支援 Session 的保持，Cookie的引導；同時支援通過獲取指定的 url 來檢測後端伺服器的狀態。
3）HAProxy 跟 LVS 類似，本身就只是一款負載均衡軟體；單純從效率上來講HAProxy 會比 Nginx 有更出色的負載均衡速度，在併發處理上也是優於 Nginx 的。
4）HAProxy 支援 TCP 協議的負載均衡轉發，可以對 MySQL 讀進行負載均衡，對後端的 MySQL 節點進行檢測和負載均衡，大家可以用 LVS+Keepalived 對 MySQL主從做負載均衡。
5）HAProxy 負載均衡策略非常多， HAProxy 的負載均衡演算法現在具體有如下8種：
1> roundrobin，表示簡單的輪詢，這個不多說，這個是負載均衡基本都具備的；
2> static-rr，表示根據權重，建議關注；
3> leastconn，表示最少連線者先處理，建議關注；
4> source，表示根據請求源 IP，這個跟 Nginx 的 IP_hash 機制類似，我們用其作為解決 session 問題的一種方法，建議關注；
5> ri，表示根據請求的 URI；
6> rl_param，表示根據請求的 URl 引數’balance url_param’ requires an URLparameter name；
7> hdr(name)，表示根據 HTTP 請求頭來鎖定每一次 HTTP 請求；
8> rdp-cookie(name)，表示根據據 cookie(name)來鎖定並雜湊每一次 TCP 請求。

四、Nginx和LVS 對比的總結：

1）Nginx 工作在網路的 7 層，所以它可以針對 http 應用本身來做分流策略，比如針對域名、目錄結構等，相比之下 LVS 並不具備這樣的功能，所以 Nginx 單憑這點可利用的場合就遠多於LVS了；
但 Nginx 有用的這些功能使其可調整度要高於 LVS，所以經常要去觸碰觸碰，觸碰多了，人為出問題的 機率也就會大。
2）Nginx 對網路穩定性的依賴較小，理論上只要 ping 得通，網頁訪問正常， Nginx就能連得通，這是 Nginx 的一大優勢！ Nginx 同時還能區 分內外網，如果是同時擁有內外網的節點，就相當於
單機擁有了備份線路； LVS 就比較依賴於網路環境，目前來看伺服器在同一網段內並且 LVS 使用 direct 方式分流，效果較能得到保證。另外注意， LVS 需要向託管商至少申請多一個 ip 來做
Visual IP，貌似是不能用本身的 IP 來做 VIP 的。要做好 LVS 管理員，確實得跟進學習很多有關網路通訊方面的知識，就不再是一個 HTTP 那麼簡單了。
3）Nginx 安裝和配置比較簡單，測試起來也很方便，因為它基本能把錯誤用日誌打印出來。 LVS 的安裝和配置、測試就要花比較長的時間了； LVS 對網路依賴比較大，很多時候不能配置成功都是
因為網路問題而不是配置問題，出了問題要解決也相應的會麻煩得多。
4）Nginx 也同樣能承受很高負載且穩定，但負載度和穩定度差 LVS 還有幾個等級：Nginx 處理所有流量所以受限於機器 IO 和配置；本身的 bug 也還是難以避免的。
5）Nginx 可以檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點。目前 LVS 中ldirectd 也能支援針對伺服器內部的情況
來監控，但 LVS 的原理使其不能重發請求。比如使用者正在上傳一個檔案，而處理該上傳的節點剛好在上傳過程中 出現故障， Nginx 會把上傳切到另一臺伺服器重新處理，而 LVS 就直接斷掉了，如果
是上傳一個很大的檔案或者很重要的檔案的話，使用者可能會因此而惱火。
6）Nginx 對請求的非同步處理可以幫助節點伺服器減輕負載，假如使用 apache 直接對外服務，那麼出現很多的窄帶連結時 apache 伺服器將會佔用大 量記憶體而不能釋放，使用多一個 Nginx 做 apache
代理的話，這些窄帶連結會被 Nginx 擋住，apache 上就不會堆積過多的請求，這樣就減少了相 當多的資源佔用。這點使用squid 也有相同的作用，即使 squid 本身配置為不快取，對 apache 還是有
很大幫助的。
7）Nginx 能支援 http、 https 和 email（ email 的功能比較少用）， LVS 所支援的應用在這點上會比 Nginx 更多。在使用上，一般最 前端所採取的策略應是 LVS，也就是 DNS 的指向應為 LVS 均衡器，
LVS 的優點令它非常適合做這個任務。重要的ip地址，最好交由 LVS 託管，比如資料 庫的 ip、 webservice 伺服器的 ip等等，這些 ip 地址隨著時間推移，使用面會越來越大，如果更換 ip 則故障會接踵
而至。所以將這些重要 ip 交給 LVS 託管是最為穩妥的，這樣做的唯一缺點是需要的 VIP 數量會比較多。Nginx 可作為 LVS 節點機器使用，一是可以利用 Nginx的功能，二是可以利 用 Nginx 的效能。當然這一層面也可以直接使用 squid，squid 的功能方面就比 Nginx 弱不少了，效能上也有所遜色於 Nginx。Nginx 也可作為中層代理使用，這一層面 Nginx 基本上無對手，唯一可以撼動 Nginx 的就只有 lighttpd了，不過 lighttpd 目前還沒有能做到 Nginx 完全的功能，配置也不那麼清晰易讀。另外，中層代理的 IP 也是重要的，所以中層代理也擁有一個VIP 和 LVS 是最完美的方案了。具體的應用還得 具體分析，如果是比較小的網站（日 PV 小於 1000 萬），用 Nginx 就完全可以了，如果機器也不少，可以用DNS 輪詢， LVS 所耗費的機器還是比較多 的；大型網站或者重要的服務，機器不發愁的時候，要多多考慮利用 LVS。

現在對網路負載均衡的使用是隨著網站規模的提升根據不同的階段來使用不同的技術：

1）第一階段：利用 Nginx 或 HAProxy 進行單點的負載均衡，這一階段伺服器規模剛脫離開單伺服器、單資料庫的模式，需要一定的負載均衡，但是仍 然規模較小沒有專業的維護團隊來進行維護，也沒有需要進行大規模的網站部署。這樣利用Nginx 或 HAproxy 就是第一選擇，此時這些東西上手快， 配置容易，在七層之上利用 HTTP 協議就可以。這時是第一選擇。
2）第二階段：隨著網路服務進一步擴大，這時單點的 Nginx 已經不能滿足，這時使用 LVS 或者商用 Array 就是首要選擇， Nginx 此時就作為 LVS 或者 Array 的節點來使用，具體 LVS 或 Array 的是選擇是根據
公司規模和預算來選擇，Array 的應用交付功能非常強大，本人在某專案中使用過，價效比也遠高於 F5，商用首選！但是一般來說這階段相關人才跟不上業務的提升，所以購買商業負載均衡已經成為了必經之路。
3）第三階段：這時網路服務已經成為主流產品，此時隨著公司知名度也進一步擴充套件，相關人才的能力以及數量也隨之提升，這時無論從開發適合自身產品的定製，以及降低成本來講開源的 LVS，已經成為首選，這時LVS 會成為主流。最終形成比較理想的基本架構為： Array/LVS — Nginx/Haproxy —Squid/Varnish — AppServer。
軟體負載均衡一般通過兩種方式來實現：基於作業系統的軟負載實現和基於第三方應用的軟負載實現。LVS就是基於Linux作業系統實現的一種軟負載，HAProxy就是開源的並且基於第三應用實現的軟負載。HAProxy相比LVS的使用要簡單很多，功能方面也很豐富。當前，HAProxy支援兩種主要的代理模式:"tcp"也即4層（大多用於郵件伺服器、內部協議通訊伺服器等），和7層（HTTP）。在4層模式 下，HAProxy僅在客戶端和伺服器之間轉發雙向流量。7層模式下，HAProxy會分析協議，並且能通過允許、拒絕、交換、增加、修改或者刪除請求 (request)或者回應(response)裡指定內容來控制協議，這種操作要基於特定規則。
現在用HAProxy主要在於它有以下優點：
1）免費開源，穩定性也是非常好，這個可通過我做的一些小專案可以看出來，單Haproxy也跑得不錯，穩定性可以與LVS相媲美；
2）根據官方文件，HAProxy可以跑滿10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom’s 10GbE NICs (Myri-10G PCI-Express)，這個作為軟體級負載均衡，也是比較驚人的；
3）HAProxy可以作為MySQL、郵件或其它的非web的負載均衡，我們常用於它作為MySQL(讀)負載均衡；
4）自帶強大的監控伺服器狀態的頁面，實際環境中我們結合Nagios進行郵件或簡訊報警，這個也是我非常喜歡它的原因之一；
5）HAProxy支援虛擬主機。
HAProxy介紹 反向代理伺服器,支援雙機熱備支援虛擬主機,但其配置簡單,擁有非常不錯的伺服器健康檢查功能,當其代理的後端伺服器出現故障, HAProxy會自動將該伺服器摘除,故障恢復後再自動將該伺服器加入｡新的1.3引入了frontend,backend；frontend根據任意 HTTP請求頭內容做規則匹配,然後把請求定向到相關的backend.
keepalived簡介　 keepalived是一個類似於layer3, 4 & 5交換機制的軟體，也就是我們平時說的第3層、第4層和第5層交換。Keepalived的作用是檢測web伺服器的狀態，如果有一臺web伺服器宕機，或工作出現故障，Keepalived將檢測到，並將有故障的web伺服器從系統中剔除，當web伺服器工作正常後Keepalived自動將web伺服器加入到伺服器群中，這些工作全部自動完成，不需要人工干涉，需要人工做的只是修復故障的web伺服器。 類似的HA工具還有heatbeat、drbd等，heatbeat、drbd配置都較為複雜。
keepalived工作原理 keepalived可提供vrrp以及health-check功能，可以只用它提供雙機浮動的vip（vrrp虛擬路由功能），這樣可以簡單實現一個雙機熱備高可用功能。 keepalived是一個類似於layer3, 4，5交換機制的軟體，也就是我們平時說的第3層、第4層和第5層交換。Keepalived的作用是檢測web 伺服器的狀態。 Layer3,4&5工作在IP/TCP協議棧的IP層，TCP層，及應用層,原理分別如下：
Layer3：Keepalived使用Layer3的方式工作式時，Keepalived會定期向伺服器群中的伺服器傳送一個ICMP的資料包（既我們平時用的Ping程式）,如果發現某臺服務的IP地址沒有啟用，Keepalived便報告這臺伺服器失效，並將它從伺服器群中剔除，這種情況的典型例子是某臺伺服器被非法關機。Layer3的方式是以伺服器的IP地址是否有效作為伺服器工作正常與否的標準。在本文中將採用這種方式。
Layer4:如果您理解了Layer3的方式，Layer4就容易了。Layer4主要以TCP埠的狀態來決定伺服器工作正常與否。如web server的服務埠一般是80，如果Keepalived檢測到80埠沒有啟動，則Keepalived將把這臺伺服器從伺服器群中剔除。
Layer5：Layer5就是工作在具體的應用層了，比Layer3,Layer4要複雜一點，在網路上佔用的頻寬也要大一些。Keepalived將根據使用者的設定檢查伺服器程式的執行是否正常，如果與使用者的設定不相符，則Keepalived將把伺服器從伺服器群中剔除。
vip即虛擬ip，是附在主機網絡卡上的，即對主機網絡卡進行虛擬，此IP仍然是佔用了此網段的某個IP。
keepalived作用 隨著網站業務量的增長，網站的伺服器壓力越來越大，需要負載均衡方案！商業的硬體如F5又太貴，創業型互聯公司如何有效節約成本，節省不必要的浪費呢？同時實現商業硬體一樣的高效能高可用的功能？有什麼好的負載均衡可伸張可擴充套件的方案嗎？答案是肯定的！有！可以利用Haproxy+Keepalived基於完整開源軟體的架構可以為你提供一個負載均衡及高可用的伺服器。 Keepalived的作用是檢測web伺服器的狀態，如果有一臺web伺服器宕機，或工作出現故障，Keepalived將檢測到，並將有故障的web伺服器從系統中剔除，當web伺服器工作正常後Keepalived自動將web伺服器加入到伺服器群中，這些工作全部自動完成，不需要人工干涉，需要人工做的只是修復故障的web伺服器。Keepalived是一個基於VRRP協議來實現的WEB 服務高可用方案，可以利用其來避免單點故障。一個WEB服務至少會有2臺伺服器執行Keepalived，一臺為主伺服器（MASTER），一臺為備份伺服器（BACKUP），但是對外表現為一個虛擬IP，主伺服器會發送特定的訊息給備份伺服器，當備份伺服器收不到這個訊息的時候，即主伺服器宕機的時候，備份伺服器就會接管虛擬IP，繼續提供服務，從而保證了高可用性。keepalived是VRRP的完美實現！

VRRP協議簡介 在現實的網路環境中，兩臺需要通訊的主機大多數情況下並沒有直接的物理連線。對於這樣的情況，它們之間路由怎樣選擇？主機如何選定到達目的主機的下一跳路由，這個問題通常的解決方法有二種：

1）在主機上使用動態路由協議(RIP、OSPF等)
2）在主機上配置靜態路由
很明顯在主機上配置路態路由是非常不切實際的，因為管理、維護成本以及是否支援等諸多問題，配置靜態路由就變得十分流行，但路由器(或者說預設閘道器default gateway)卻經常成為單點。 VRRP的目的就是為了解決靜態路由單點故障問題。VRRP通過一競選(election)協議來動態的將路由任務交給LAN中虛擬路由器中的某臺VRRP路由器。
VRRP工作機制 在一個VRRP虛擬路由器中，有多臺物理的VRRP路由器，但是這多臺的物理的機器並不能同時工作，而是由一臺稱為MASTER的負責路由工作，其它的都是BACKUP，MASTER並非一成不變，VRRP讓每個VRRP路由器參與競選，最終獲勝的就是MASTER。MASTER擁有一些特權，比如 擁有虛擬路由器的IP地址，我們的主機就是用這個IP地址作為靜態路由的。擁有特權的MASTER要負責轉發傳送給閘道器地址的包和響應ARP請求。 VRRP通過競選協議來實現虛擬路由器的功能，所有的協議報文都是通過IP多播(multicast)包(多播地址 224.0.0.18)形式傳送的。虛擬路由器由VRID(範圍0-255)和一組IP地址組成，對外表現為一個周知的MAC地址。所以，在一個虛擬路由 器中，不管誰是MASTER，對外都是相同的MAC和IP(稱之為VIP)。客戶端主機並不需要因為MASTER的改變而修改自己的路由配置，對他們來 說，這種主從的切換是透明的。 在一個虛擬路由器中，只有作為MASTER的VRRP路由器會一直髮送VRRP廣告包(VRRPAdvertisement message)，BACKUP不會搶佔MASTER，除非它的優先順序(priority)更高。當MASTER不可用時(BACKUP收不到廣告包)， 多臺BACKUP中優先順序最高的這臺會被搶佔為MASTER。這種搶佔是非常快速的(<1s)，以保證服務的連續性。由於安全性考慮，VRRP包使用了加密協議進行加密。

-------------------------------------------------------------------------------------- Haproxy+Keepalived的負載均衡和高可用環境的部署過程，有主從和主主兩種模式：

主從模式：一個vip，vip在master機器上，當master機器出現故障後，vip漂移到slave機器上，slave變為master提供服務。
主主模式：兩個vip，兩臺機器都設定vip，當其中一臺機器出現故障後，它的vip就漂移到另一臺機器上（即另一臺機器有兩個vip），當故障機器恢復後，再將vip重新漂移過來。

各自作用：
1）Keepalived 的作用是檢測web伺服器的狀態，如果有一臺web伺服器宕機，或工作出現故障，Keepalived將檢測到，並將有故障的web伺服器從系統中剔除， 當web伺服器工作正常
後Keepalived自動將web伺服器加入到伺服器群中，這些工作全部自動完成，不需要人工干涉，需要人工做的只是修復故障的 web伺服器。
2）HAProxy 提供高可用性、負載均衡以及基於TCP和HTTP應用的代理,支援虛擬主機,它是免費、快速並且可靠的一種解決方案。HAProxy 特別適用於那些負載特大的 web 站點, 這些
站點通常又需要會話保持或七層處理。HAProxy 執行在當前的硬體上,完全可以支援數以萬計的併發連線。並且它的執行模式使得它可以很簡單安全的整 合進您當前的架構中, 同時
可以保護你的 web 伺服器不被暴露到網路上。

一、Haproxy+Keepalived主主架構部署記錄

0）需求描述：
網站的域名之前都是放在機房的兩臺伺服器上，前面做CDN加速，CDN節點會同步快取到網站資料，使用者訪問網站，流量壓力都在前面的CDN裝置上。
後續網站伺服器被***，又在CDN前面加了一個上層，即又多加一層快取，剛加這個上層的時候，流量回源會很大，訪問量也會減少，不過隨著回源，訪問量漸漸恢復。

後來為了安全考慮，計劃做Keepalivedd+Haproxy負載均衡的高可用，部署好之後，可以將後端源站伺服器的外網ip拿下，進來的請求通過Haproxy代理進來，出去的請求可以通過squid代理出去。
後端源站機器的web埠只需要對Haproxy機器開放即可，然後CDN解析那邊將源站ip改為Haproxy伺服器ip即可。
1）環境準備
Haproxy_Keepalived_Master 182.148.15.237
VIP1 182.148.15.239

Haproxy_Keepalived_Backup 182.148.15.236
VIP2 182.148.15.235

Real_Server1 182.148.15.233
Real_Server2 182.148.15.238

系統版本都是centos6.8
基本的網路拓撲圖如下：

2）Haproxy_keepalived_Master和Haproxy_keepalived_Backup兩臺伺服器上安裝配置haproxy和keepalived的操作記錄：
關閉 SElinux、配置防火牆（Haproxy_Keepalived_Master 和 Haproxy_Keepalived_Backup兩臺機器都要操作）
[root@Haproxy_Keepalived_Master ~]# vim /etc/sysconfig/selinux
#SELINUX=enforcing #註釋掉
#SELINUXTYPE=targeted #註釋掉
SELINUX=disabled #增加

[root@Haproxy_Keepalived_Master ~]# setenforce 0 #臨時關閉selinux。上面檔案配置後，重啟機器後就永久生效。

注意下面182.148.15.0/24是伺服器的公網網段，192.168.1.0/24是伺服器的私網網段
一定要注意：加上這個組播規則後，MASTER和BACKUP故障時，才能實現VIP資源的正常轉移。其故障恢復後，VIP也還會正常轉移回來。
[root@Haproxy_Keepalived_Master ~]# vim /etc/sysconfig/iptables
…
-A INPUT -s 182.148.15.0/24 -d 224.0.0.18 -j ACCEPT #允許組播地址通訊。
-A INPUT -s 192.168.1.0/24 -d 224.0.0.18 -j ACCEPT
-A INPUT -s 182.148.15.0/24 -p vrrp -j ACCEPT #允許 VRRP（虛擬路由器冗餘協）通訊
-A INPUT -s 192.168.1.0/24 -p vrrp -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT

[root@Haproxy_Keepalived_Master ~]# /etc/init.d/iptables restart
下載Haproxy地址：http://www.haproxy.org/download/1.6/src/
1）安裝Haproxy（Haproxy_Keepalived_Master 和 Haproxy_Keepalived_Backup兩臺機器都要操作） 注意：安裝之前，先執行yum install gcc gcc-c++ make openssl-devel kernel-devel
[root@Haproxy_Keepalived_Master src]# wgethttp://www.haproxy.org/download/1.6/src/haproxy-1.6.12.tar.gz
[root@Haproxy_Keepalived_Master src]# tar -zvxf haproxy-1.6.