haproxy+keepalived實現(xiàn)高可用負載均衡

1、haproxy+keepalived實現(xiàn)高可用負載均衡軟件負載均衡一般通過兩種方式來實現(xiàn)：基于操作系統(tǒng)的軟負載實現(xiàn)和基于第三方應(yīng)用的軟負載實現(xiàn)。LVS就是基于Linux操作系統(tǒng)實現(xiàn)的一種軟負載，HAProxy就是開源的并且基于第三應(yīng)用實現(xiàn)的軟負載。HAProxy相比LVS的使用要簡單很多，功能方面也很豐富。當 前，HAProxy支持兩種主要的代理模式:"tcp"也即4層（大多用于郵件服務(wù)器、內(nèi)部協(xié)議通信服務(wù)器等），和7層（HTTP）。在4層模式 下，HAProxy僅在客戶端和服務(wù)器之間轉(zhuǎn)發(fā)雙向流量。7層模式下，HAProxy會分析協(xié)議，并且能通過允許、拒絕、交換、增加、修改

2、或者刪除請求 (request)或者回應(yīng)(response)里指定內(nèi)容來控制協(xié)議，這種操作要基于特定規(guī)則。我現(xiàn)在用HAProxy主要在于它有以下優(yōu)點，這里我總結(jié)下：一、免費開源，穩(wěn)定性也是非常好，這個可通過我做的一些小項目可以看出來，單Haproxy也跑得不錯，穩(wěn)定性可以與LVS相媲美；二、根據(jù)官方文檔，HAProxy可以跑滿10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom's 10GbE NICs (Myri-10G PCI-Express)，這個作為軟件級負載均衡，也是比較驚人的；三、HAProxy可以作為MySQL、

3、郵件或其它的非web的負載均衡，我們常用于它作為MySQL(讀)負載均衡；四、自帶強大的監(jiān)控服務(wù)器狀態(tài)的頁面，實際環(huán)境中我們結(jié)合Nagios進行郵件或短信報警，這個也是我非常喜歡它的原因之一；五、HAProxy支持虛擬主機。=在做反向代理服務(wù)器的負載均衡時，我們通常會使用nginx的均衡配置。其實，haproxy的負載均衡也是屬于這一類的。那么關(guān)于這方面的配置過程我們現(xiàn)在來進行一下講解。首先，對haproxy進行一個簡單的介紹，之后就是安裝和配置環(huán)節(jié)了。HAProxy介紹反向代理服務(wù)器,支持雙機熱備支持虛擬主機,但其配置簡單,擁有非常不錯的服務(wù)器健康檢查功能,當其代理的后端服務(wù)器出現(xiàn)故障, H

4、AProxy會自動將該服務(wù)器摘除,故障恢復(fù)后再自動將該服務(wù)器加入新的1.3引入了frontend,backend；frontend根據(jù)任意 HTTP請求頭內(nèi)容做規(guī)則匹配,然后把請求定向到相關(guān)的backend.=keepalived簡介keepalived是一個類似于layer3, 4 & 5交換機制的軟件，也就是我們平時說的第3層、第4層和第5層交換。Keepalived的作用是檢測web服務(wù)器的狀態(tài)，如果有一臺web服務(wù)器死機，或工作出現(xiàn)故障，Keepalived將檢測到，并將有故障的web服務(wù)器從系統(tǒng)中剔除，當web服務(wù)器工作正常后K

5、eepalived自動將web服務(wù)器加入到服務(wù)器群中，這些工作全部自動完成，不需要人工干涉，需要人工做的只是修復(fù)故障的web服務(wù)器。類似的HA工具還有heatbeat、drbd等，heatbeat、drbd配置都較為復(fù)雜。 keepalived理論工作原理keepalived可提供vrrp以及health-check功能，可以只用它提供雙機浮動的vip（vrrp虛擬路由功能），這樣可以簡單實現(xiàn)一個雙機熱備高可用功能。keepalived是一個類似于layer3, 4 & 5交換機制的軟件，也就是我們平時說的第3層、第4層和第5層交換。Keepalived的作用是檢測web&#

6、160;服務(wù)器的狀態(tài)。 Layer3,4&5工作在IP/TCP協(xié)議棧的IP層，TCP層，及應(yīng)用層,原理分別如下： Layer3：Keepalived使用Layer3的方式工作式時，Keepalived會定期向服務(wù)器群中的服務(wù)器 發(fā)送一個ICMP的數(shù)據(jù)包（既我們平時用的Ping程序）,如果發(fā)現(xiàn)某臺服務(wù)的IP地址沒有激活，Keepalived便報告這臺服務(wù)器失效，并將它從服務(wù)器群中剔除，這種情況的典型例子是某臺服務(wù)器被非法關(guān)機。Layer3的方式是以服務(wù)器的IP地址是否有效作為服務(wù)器工作正常與否的標準。在本文中將采用這種方式。 Layer4:如果您理解了Lay

7、er3的方式，Layer4就容易了。Layer4主要以TCP端口的狀態(tài)來決定服務(wù)器工作正常與否。如web server的服務(wù)端口一般是80，如果Keepalived檢測到80端口沒有啟動，則Keepalived將把這臺服務(wù)器從服務(wù)器群中剔除。 Layer5：Layer5就是工作在具體的應(yīng)用層了，比Layer3,Layer4要復(fù)雜一點，在網(wǎng)絡(luò)上占用的帶寬也要大一些。Keepalived將根據(jù)用戶的設(shè)定檢查服務(wù)器程序的運行是否正常，如果與用戶的設(shè)定不相符，則Keepalived將把服務(wù)器從服務(wù)器群中剔除。 vip即虛擬ip，是附在主機網(wǎng)卡上的，即對主機網(wǎng)卡進行虛擬，此IP仍然是

8、占用了此網(wǎng)段的某個IP。 keepalived作用隨著你的網(wǎng)站業(yè)務(wù)量的增長你網(wǎng)站的服務(wù)器壓力越來越大？需要負載均衡方案！商業(yè)的硬件如F5又太貴，你們又是創(chuàng)業(yè)型互聯(lián)公司如何有效節(jié)約成本，節(jié)省不必要的浪費？同時實現(xiàn)商業(yè)硬件一樣的高性能高可用的功能？有什么好的負載均衡可伸張可擴展的方案嗎？答案是肯定的！有！我們利用 LVS+Keepalived基于完整開源軟件的架構(gòu)可以為你提供一個負載均衡及高可用的服務(wù)器。 LVS+Keepalived 介紹 LVS LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務(wù)器，是一個虛擬的服務(wù)器集群系統(tǒng)。

9、本項目在1998年5月由章文嵩博士成立，是中國國內(nèi)最早出現(xiàn)的自由軟件項目之一.目前有三種IP負載均衡技術(shù)（VS/NAT、VS/TUN和VS/DR）八種調(diào)度算法（rr,wrr,lc,wlc,lblc,lblcr,dh,sh）。 Keepalvied Keepalived在這里主要用作RealServer的健康狀態(tài)檢查以及LoadBalance主機和BackUP主機之間failover的實現(xiàn)。keepalived簡介keepalived是一個類似于layer3, 4 & 5交換機制的軟件，也就是我們平時說的第3層、第4層和第5層交換。Keepalived的作用是檢測we

10、b服務(wù)器的狀態(tài)，如果有一臺web服務(wù)器死機，或工作出現(xiàn)故障，Keepalived將檢測到，并將有故障的web服務(wù)器從系統(tǒng)中剔除，當web服務(wù)器工作正常后Keepalived自動將web服務(wù)器加入到服務(wù)器群中，這些工作全部自動完成，不需要人工干涉，需要人工做的只是修復(fù)故障的web服務(wù)器。=Keepalived介紹Keepalived是一個基于VRRP協(xié)議來實現(xiàn)的WEB 服務(wù)高可用方案，可以利用其來避免單點故障。一個WEB服務(wù)至少會有2臺服務(wù)器運行Keepalived，一臺為主服務(wù)器（MASTER），一臺為備份服務(wù)器（BACKUP），但是對外表現(xiàn)為一個虛擬IP，主服務(wù)器會發(fā)送特定的消息給備份服務(wù)器

11、，當備份服務(wù)器收不到這個消息的時候，即主服務(wù)器宕機的時候，備份服務(wù)器就會接管虛擬IP，繼續(xù)提供服務(wù)，從而保證了高可用性。1      +-VIP()-+2      |                        &

12、#160;          |                           |  3      |     &

13、#160;                             |                     

14、;      |  4server(MASTER) <-keepalived-> server(BACKUP)5 ()                              

15、0;       ()keepalived是VRRP的完美實現(xiàn)，因此在介紹keepalived之前，先介紹一下VRRP的原理。 VRRP協(xié)議簡介在現(xiàn)實的網(wǎng)絡(luò)環(huán)境中，兩臺需要通信的主機大多數(shù)情況下并沒有直接的物理連接。對于這樣的情況，它們之間路由怎樣選擇？主機如何選定到達目的主機的下一跳路由，這個問題通常的解決方法有二種：·        在主機上使用動態(tài)路由協(xié)議(RIP、OSPF等)· 

16、0;      在主機上配置靜態(tài)路由很明顯，在主機上配置路態(tài)路由是非常不切實際的，因為管理、維護成本以及是否支持等諸多問題。配置靜態(tài)路由就變得十分流行，但路由器(或者說默認網(wǎng)關(guān)default gateway)卻經(jīng)常成為單點。VRRP的目的就是為了解決靜態(tài)路由單點故障問題。VRRP通過一競選(election)協(xié)議來動態(tài)的將路由任務(wù)交給LAN中虛擬路由器中的某臺VRRP路由器。工作機制在一個VRRP虛擬路由器中，有多臺物理的VRRP路由器，但是這多臺的物理的機器并不能同時工作，而是由一臺稱為MASTER的負責路由工作，其它的都是BACK

17、UP，MASTER并非一成不變，VRRP讓每個VRRP路由器參與競選，最終獲勝的就是MASTER。MASTER擁有一些特權(quán)，比如 擁有虛擬路由器的IP地址，我們的主機就是用這個IP地址作為靜態(tài)路由的。擁有特權(quán)的MASTER要負責轉(zhuǎn)發(fā)發(fā)送給網(wǎng)關(guān)地址的包和響應(yīng)ARP請求。VRRP通過競選協(xié)議來實現(xiàn)虛擬路由器的功能，所有的協(xié)議報文都是通過IP多播(multicast)包(多播地址 8)形式發(fā)送的。虛擬路由器由VRID(范圍0-255)和一組IP地址組成，對外表現(xiàn)為一個周知的MAC地址。所以，在一個虛擬路由 器中，不管誰是MASTER，對外都是相同的MAC和IP(稱之為VI

18、P)?？蛻舳酥鳈C并不需要因為MASTER的改變而修改自己的路由配置，對他們來 說，這種主從的切換是透明的。在一個虛擬路由器中，只有作為MASTER的VRRP路由器會一直發(fā)送VRRP廣告包(VRRPAdvertisement message)，BACKUP不會搶占MASTER，除非它的優(yōu)先級(priority)更高。當MASTER不可用時(BACKUP收不到廣告包)， 多臺BACKUP中優(yōu)先級最高的這臺會被搶占為MASTER。這種搶占是非?？焖俚?<1s)，以保證服務(wù)的連續(xù)性。由于安全性考慮，VRRP包使用了加密協(xié)議進行加密。=vrrp簡介隨著Internet的迅猛發(fā)展，基于網(wǎng)絡(luò)的應(yīng)用逐漸

19、增多。這就對網(wǎng)絡(luò)的可靠性提出了越來越高的要求。斥資對所有網(wǎng)絡(luò)設(shè)備進行更新當然是一種很好的可靠性解決方案；但本著保護現(xiàn)有投資的角度考慮，可以采用廉價冗余的思路，在可靠性和經(jīng)濟性方面找到平衡點。   虛擬路由冗余協(xié)議就是一種很好的解決方案。在該協(xié)議中，對共享多存取訪問介質(zhì)（如以太網(wǎng)）上終端IP設(shè)備的默認網(wǎng)關(guān)(Default Gateway)進行冗余備份，從而在其中一臺路由設(shè)備宕機時，備份路由設(shè)備及時接管轉(zhuǎn)發(fā)工作，向用戶提供透明的切換，提高了網(wǎng)絡(luò)服務(wù)質(zhì)量。  一、協(xié)議概述   在基于TCP/IP協(xié)議的網(wǎng)絡(luò)中，為了保證不直接物理連接的設(shè)備之間

20、的通信，必須指定路由。目前常用的指定路由的方法有兩種：一種是通過路由協(xié)議（比如：內(nèi)部路由協(xié)議RIP和OSPF）動態(tài)學習；另一種是靜態(tài)配置。在每一個終端都運行動態(tài)路由協(xié)議是不現(xiàn)實的，大多客戶端操作系統(tǒng)平臺都不支持動態(tài)路由協(xié)議，即使支持也受到管理開銷、收斂度、安全性等許多問題的限制。因此普遍采用對終端IP設(shè)備靜態(tài)路由配置，一般是給終端設(shè)備指定一個或者多個默認網(wǎng)關(guān)(Default Gateway)。靜態(tài)路由的方法簡化了網(wǎng)絡(luò)管理的復(fù)雜度和減輕了終端設(shè)備的通信開銷，但是它仍然有一個缺點：如果作為默認網(wǎng)關(guān)的路由器損壞，所有使用該網(wǎng)關(guān)為下一跳主機的通信必然要中斷。即便配置了多個默認網(wǎng)關(guān)，如不重新啟動終端設(shè)備

21、，也不能切換到新的網(wǎng)關(guān)。采用虛擬路由冗余協(xié)議 (Virtual Router Redundancy Protocol，簡稱VRRP)可以很好的避免靜態(tài)指定網(wǎng)關(guān)的缺陷。   在VRRP協(xié)議中，有兩組重要的概念：VRRP路由器和虛擬路由器，主控路由器和備份路由器。VRRP路由器是指運行VRRP的路由器，是物理實體，虛擬路由器是指VRRP協(xié)議創(chuàng)建的，是邏輯概念。一組VRRP路由器協(xié)同工作，共同構(gòu)成一臺虛擬路由器。該虛擬路由器對外表現(xiàn)為一個具有唯一固定IP地址和MAC地址的邏輯路由器。處于同一個VRRP組中的路由器具有兩種互斥的角色：主控路由器和備份路由器，一個VRRP組中有且只有

22、一臺處于主控角色的路由器，可以有一個或者多個處于備份角色的路由器。VRRP協(xié)議使用選擇策略從路由器組中選出一臺作為主控，負責ARP相應(yīng)和轉(zhuǎn)發(fā)IP數(shù)據(jù)包，組中的其它路由器作為備份的角色處于待命狀態(tài)。當由于某種原因主控路由器發(fā)生故障時，備份路由器能在幾秒鐘的時延后升級為主路由器。由于此切換非常迅速而且不用改變IP地址和MAC地址，故對終端使用者系統(tǒng)是透明的。  二、工作原理   一個VRRP路由器有唯一的標識：VRID，范圍為0255。該路由器對外表現(xiàn)為唯一的虛擬MAC地址，地址的格式為00-00-5E-00-01-VRID。主控路由器負責對ARP請求用該M

23、AC地址做應(yīng)答。這樣，無論如何切換，保證給終端設(shè)備的是唯一一致的IP和MAC地址，減少了切換對終端設(shè)備的影響。   VRRP控制報文只有一種：VRRP通告(advertisement)。它使用IP多播數(shù)據(jù)包進行封裝，組地址為8，發(fā)布范圍只限于同一局域網(wǎng)內(nèi)。這保證了VRID在不同網(wǎng)絡(luò)中可以重復(fù)使用。為了減少網(wǎng)絡(luò)帶寬消耗只有主控路由器才可以周期性的發(fā)送VRRP通告報文。備份路由器在連續(xù)三個通告間隔內(nèi)收不到VRRP或收到優(yōu)先級為0的通告后啟動新的一輪VRRP選舉。   在VRRP路由器組中，按優(yōu)先級選舉主控路由器，VRRP協(xié)議中優(yōu)先級范圍是0

24、255。若VRRP路由器的IP地址和虛擬路由器的接口IP地址相同，則稱該虛擬路由器作VRRP組中的IP地址所有者；IP地址所有者自動具有最高優(yōu)先級：255。優(yōu)先級0一般用在IP地址所有者主動放棄主控者角色時使用?？膳渲玫膬?yōu)先級范圍為1254。優(yōu)先級的配置原則可以依據(jù)鏈路的速度和成本、路由器性能和可靠性以及其它管理策略設(shè)定。主控路由器的選舉中，高優(yōu)先級的虛擬路由器獲勝，因此，如果在VRRP組中有IP地址所有者，則它總是作為主控路由的角色出現(xiàn)。對于相同優(yōu)先級的候選路由器，按照IP地址大小順序選舉。VRRP還提供了優(yōu)先級搶占策略，如果配置了該策略，高優(yōu)先級的備份路由器便會剝奪當前低優(yōu)先級的主控路由器

25、而成為新的主控路由器。   為了保證VRRP協(xié)議的安全性，提供了兩種安全認證措施：明文認證和IP頭認證。明文認證方式要求：在加入一個VRRP路由器組時，必須同時提供相同的VRID和明文密碼。適合于避免在局域網(wǎng)內(nèi)的配置錯誤，但不能防止通過網(wǎng)絡(luò)監(jiān)聽方式獲得密碼。IP頭認證的方式提供了更高的安全性，能夠防止報文重放和修改等攻擊。 三、 應(yīng)用實例   最典型的VRRP應(yīng)用：RTA、RTB組成一個VRRP路由器組，假設(shè)RTB的處理能力高于RTA，則將RTB配置成IP地址所有者，H1、H2、H3的默認網(wǎng)關(guān)設(shè)定為RTB。則RTB成為主控路由器，負責ICMP重

26、定向、ARP應(yīng)答和IP報文的轉(zhuǎn)發(fā)；一旦RTB失敗，RTA立即啟動切換，成為主控，從而保證了對客戶透明的安全切換。   在VRRP應(yīng)用中，RTA在線時RTB只是作為后備，不參與轉(zhuǎn)發(fā)工作，閑置了路由器RTA和鏈路L1。通過合理的網(wǎng)絡(luò)設(shè)計，可以到達備份和負載分擔雙重效果。讓RTA、RTB同時屬于互為備份的兩個VRRP組：在組1中RTA為IP地址所有者；組2中RTB為IP地址所有者。將H1的默認網(wǎng)關(guān)設(shè)定為RTA；H2、H3的默認網(wǎng)關(guān)設(shè)定為RTB。這樣，既分擔了設(shè)備負載和網(wǎng)絡(luò)流量，又提高了網(wǎng)絡(luò)可靠性。   VRRP協(xié)議的工作機理與CISCO公司的HSRP（Hot

27、Standby Routing Protocol）有許多相似之處。但二者主要的區(qū)別是在CISCO的HSRP中，需要單獨配置一個IP地址作為虛擬路由器對外體現(xiàn)的地址，這個地址不能是組中任何一個成員的接口地址。   使用VRRP協(xié)議，不用改造目前的網(wǎng)絡(luò)結(jié)構(gòu)，最大限度保護了當前投資，只需最少的管理費用，卻大大提升了網(wǎng)絡(luò)性能，具有重大的應(yīng)用價值。=keepalive的簡單應(yīng)用管理VIP的飄動 from:     VIP的飄動可以為我們解決很多問題，以前我試過使用ifup/ifdown的方式控制網(wǎng)卡的up/down來實現(xiàn)，這種方式有個

28、小問題，就是每次VIP 飄動之后都要等上幾十秒才能生效，感覺時間比較長，而且還要配合一些邏輯腳本才能很好地工作，有沒有更好的方法呢？當然有，這就是本文的主角 keepalived。      安裝很簡單：1tar zxvf keepalived-1.1.20.tar.gz  2cd keepalived-1.1.203./configure -prefix=/4make5make install      修改一下 /etc/keepalived/keepalived.conf 這個配

29、置文件就可以用了，以下是我的環(huán)境，41和42是兩個VIP，可以在兩臺服務(wù)器之間飄動：         主機的配置：01global_defs 02   notification_email 03     failoverfirewall.loc04   05   notification_email_from Alexandre.

30、Cassenfirewall.loc06   smtp_server 807   smtp_connect_timeout 1008   router_id nginx0910 11vrrp_instance VI_141 12    state BACKUP13    interface eth014    virtual_router_id 14115

31、    priority 5016    advert_int 117    authentication 18        auth_type PASS19        auth_pass 14120    21    virtual

32、_ipaddress 22        41/26 dev eth023    2425 26vrrp_instance VI_142 27    state BACKUP28    interface eth029    virtual_router_id 14230    pri

33、ority 10031    advert_int 132    authentication 33        auth_type PASS34        auth_pass 14235    36    virtual_ipaddress 37  &

34、#160;     42/26 dev eth038    39      備機的配置：01global_defs 02   notification_email 03     failoverfirewall.loc04   05   notification_email_from Alexa

35、ndre.Cassenfirewall.loc06   smtp_server 807   smtp_connect_timeout 1008   router_id nginx0910 11vrrp_instance VI_141 12    state BACKUP13    interface eth014    virtual_router_id 1

36、4115    priority 10016    advert_int 117    authentication 18        auth_type PASS19        auth_pass 14120    21    vi

37、rtual_ipaddress 22        41/26 dev eth023    2425 26vrrp_instance VI_142 27    state BACKUP28    interface eth029    virtual_router_id 14230   

38、0;priority 5031    advert_int 132    authentication 33        auth_type PASS34        auth_pass 14235    36    virtual_ipaddress 37 

39、60;      42/26 dev eth038    39      乍一看，主機和備機的配置文件是一樣的，仔細看一下priority的值，使用以下命令即可將keepalived加入linux的服務(wù)中：1chkconfig -add keepalived ;      通過啟、停keepalived這個服務(wù)即可觀察到VIP的飄動，至于為什么VIP飄動后可以很快地生效，還

40、有待研究。=haproxy+keepalived實現(xiàn)高可用負載均衡 我的環(huán)境：haproxy keepalived 主：92haproxy keepalived 備：93vip：00web：87:80 87:8000一：安裝過程，在92上：keepalived的安裝:#tar -zxvf keepalived-1.1.17.tar.gz#ln -s /usr/src/kernels/2.6.18-128.el5-i686/ /usr/src/linux#

41、cd keepalived-1.1.17#./configure -prefix=/ -mandir=/usr/local/share/man/ -with-kernel-dir=/usr/src/kernels/2.6.18-128.el5-i686/#make && make install#cd /etc/keepalived/#mv keepalived.conf keepalived.conf.default#vi keepalived.conf! Configuration File for keepalivedvrrp_script chk_http_port s

42、cript "/etc/keepalived/check_haproxy.sh"interval 2weight 2global_defs router_id LVS_DEVELvrrp_instance VI_1 state MASTER #93上改為BACKUPinterface eth0virtual_router_id 51 priority 150 #93上改為120advert_int 1authentication auth_type PASSauth_pass 1111track_script chk_h

43、ttp_portvirtual_ipaddress 00 #vi /etc/keepalived/check_haproxy.sh#!/bin/bashA=ps -C haproxy -no-header |wc -lif $A -eq 0 ;then/usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/conf/haproxy.cfgsleep 3if ps -C haproxy -no-header |wc -l -eq 0 ;then/etc/init.d/keepalived stopfifi#chm

44、od 755 /etc/keepalived/check_haproxy.shhaproxy的安裝(主備都一樣)：#tar -zxvf haproxy-1.4.9.tar.gz#cd haproxy-1.4.9#make TARGET=linux26 PREFIX=/usr/local/haproxy install#cd /usr/local/haproxy/#mkdir conf logs#cd conf#vi haproxy.cfggloballog local3 infomaxconn 4096user nobodygroup nobodydaemonnbproc 1pidfile /usr/local/haproxy/logs/haproxy.piddefaultsmaxconn 2000contimeout 5000clitimeout 30000srvtimeout 30000mode httplog globallog local3 infostats uri /admin?statsoption forwardforfrontend http_serverbind :80log globaldefault_backend info_cacheacl test hdr_dom(host)