haproxy+keepalived(涵蓋了lvs,nginx.haproxy比較)
文章轉載自：javascript
haproxy+keepalived https://cloud.tencent.com/developer/article/1026385前端
網絡四層和七層的區別 https://juejin.im/post/59a0472f5188251240632f92java
Nginx、LVS、HAProxy 是目前使用最普遍的三種負載均衡軟件，本人都在多個項目中實施過，一般會結合Keepalive作健康檢查，實現故障轉移的高可用功能。linux
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 負載均衡軟件的優缺點： 1、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 來解決。 2、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 就簡單多了。 3、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 請求。 4、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)裏指定內容來控制協議，這種操做要基於特定規則。ios
如今用HAProxy主要在於它有如下優勢：nginx
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.web
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層，及應用層,原理分別以下：redis
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 服務器不被暴露到網絡上。
1、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.12.tar.gz