nginx,lvs,haproxy+keepalived區別

 

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]# wget http://www.haproxy.org/download/1.6/src/haproxy-1.6.12.tar.gz
[root@Haproxy_Keepalived_Master src]# tar -zvxf haproxy-1.6.