軟件負載均衡通常經過兩種方式來實現:基於操做系統的軟負載實現和基於第三方應用的軟負載實現。LVS就是基於Linux操做系統實現的一種軟負載,HAProxy就是開源的而且基於第三應用實現的軟負載。html
HAProxy相比LVS的使用要簡單不少,功能方面也很豐富。當 前,HAProxy支持兩種主要的代理模式:"tcp"也即4層(大多用於郵件服務器、內部協議通訊服務器等),和7層(HTTP)。在4層模式 下,HAProxy僅在客戶端和服務器之間轉發雙向流量。7層模式下,HAProxy會分析協議,而且能經過容許、拒絕、交換、增長、修改或者刪除請求 (request)或者回應(response)裏指定內容來控制協議,這種操做要基於特定規則。linux
我如今用HAProxy主要在於它有如下優勢,這裏我總結下:ios
1、免費開源,穩定性也是很是好,這個可經過我作的一些小項目能夠看出來,單Haproxy也跑得不錯,穩定性能夠與LVS相媲美;nginx
2、根據官方文檔,HAProxy能夠跑滿10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom's 10GbE NICs (Myri-10G PCI-Express),這個做爲軟件級負載均衡,也是比較驚人的;web
3、HAProxy能夠做爲MySQL、郵件或其它的非web的負載均衡,咱們經常使用於它做爲MySQL(讀)負載均衡;算法
四、自帶強大的監控服務器狀態的頁面,實際環境中咱們結合Nagios進行郵件或短信報警,這個也是我很是喜歡它的緣由之一;後端
五、HAProxy支持虛擬主機。安全
===================================================================================bash
在作反向代理服務器的負載均衡時,咱們一般會使用nginx的均衡配置。其實,haproxy的負載均衡也是屬於這一類的。那麼關於這方面的配置過程咱們如今來進行一下講解。首先,對haproxy進行一個簡單的介紹,以後就是安裝和配置環節了。服務器
HAProxy介紹
反向代理服務器,支持雙機熱備支持虛擬主機,但其配置簡單,擁有很是不錯的服務器健康檢查功能,當其代理的後端服務器出現故障, HAProxy會自動將該服務器摘除,故障恢復後再自動將該服務器加入新的1.3引入了frontend,backend;frontend根據任意 HTTP請求頭內容作規則匹配,而後把請求定向到相關的backend.
http://blog.liuts.com/post/223/ (搭建四層負載均衡器)
http://rfyimcool.blog.51cto.com/1030776/413187 (搭建七層負載均衡器)
===================================================================================
keepalived簡介
keepalived是一個相似於layer3, 4 & 5交換機制的軟件,也就是咱們平時說的第3層、第4層和第5層交換。Keepalived的做用是檢測web服務器的狀態,若是有一臺web服務器死機,或工做出現故障,Keepalived將檢測到,並將有故障的web服務器從系統中剔除,當web服務器工做正常後Keepalived自動將web服務器加入到服務器羣中,這些工做所有自動完成,不須要人工干涉,須要人工作的只是修復故障的web服務器。
相似的HA工具還有heatbeat、drbd等,heatbeat、drbd配置都較爲複雜。
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。
隨着你的網站業務量的增加你網站的服務器壓力愈來愈大?須要負載均衡方案!商業的硬件如F5又太貴,大家又是創業型互聯公司如何有效節約成本,節省沒必要要的浪費?同時實現商業硬件同樣的高性能高可用的功能?有什麼好的負載均衡可伸張可擴展的方案嗎?答案是確定的!有!咱們利用 LVS+Keepalived基於完整開源軟件的架構能夠爲你提供一個負載均衡及高可用的服務器。
LVS+Keepalived 介紹
LVS
LVS是Linux Virtual Server的簡寫,意即Linux虛擬服務器,是一個虛擬的服務器集羣系統。本項目在1998年5月由章文嵩博士成立,是中國國內最先出現的自由軟件項目之一.目前有三種IP負載均衡技術(VS/NAT、VS/TUN和VS/DR)八種調度算法(rr,wrr,lc,wlc,lblc,lblcr,dh,sh)。
Keepalvied
Keepalived在這裏主要用做RealServer的健康狀態檢查以及LoadBalance主機和BackUP主機之間failover的實現。keepalived簡介 keepalived是一個相似於layer3, 4 & 5交換機制的軟件,也就是咱們平時說的第3層、第4層和第5層交換。Keepalived的做用是檢測web服務器的狀態,若是有一臺web服務器死機,或工做出現故障,Keepalived將檢測到,並將有故障的web服務器從系統中剔除,當web服務器工做正常後Keepalived自動將web服務器加入到服務器羣中,這些工做所有自動完成,不須要人工干涉,須要人工作的只是修復故障的web服務器。
===================================================================================
Keepalived介紹
Keepalived是一個基於VRRP協議來實現的WEB 服務高可用方案,能夠利用其來避免單點故障。一個WEB服務至少會有2臺服務器運行Keepalived,一臺爲主服務器(MASTER),一臺爲備份服務器(BACKUP),可是對外表現爲一個虛擬IP,主服務器會發送特定的消息給備份服務器,當備份服務器收不到這個消息的時候,即主服務器宕機的時候,備份服務器就會接管虛擬IP,繼續提供服務,從而保證了高可用性。
+-------------VIP(192.168.0.7)------------------+ | |
| | | | | | |
|
server(MASTER) <----keepalived----> server(BACKUP) | |
(192.168.172.1) (192.168.172.2) | |
keepalived是VRRP的完美實現,所以在介紹keepalived以前,先介紹一下VRRP的原理。
VRRP協議簡介
在現實的網絡環境中,兩臺須要通訊的主機大多數狀況下並無直接的物理鏈接。對於這樣的狀況,它們之間路由怎樣選擇?主機如何選定到達目的主機的下一跳路由,這個問題一般的解決方法有二種:
· 在主機上使用動態路由協議(RIP、OSPF等)
· 在主機上配置靜態路由
很明顯,在主機上配置路態路由是很是不切實際的,由於管理、維護成本以及是否支持等諸多問題。配置靜態路由就變得十分流行,但路由器(或者說默認網關default gateway)卻常常成爲單點。
VRRP的目的就是爲了解決靜態路由單點故障問題。
VRRP經過一競選(election)協議來動態的將路由任務交給LAN中虛擬路由器中的某臺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包使用了加密協議進行加密。
==========================================
vrrp簡介
隨着Internet的迅猛發展,基於網絡的應用逐漸增多。這就對網絡的可靠性提出了愈來愈高的要求。斥資對全部網絡設備進行更新固然是一種很好的可靠性解決方案;但本着保護現有投資的角度考慮,能夠採用廉價冗餘的思路,在可靠性和經濟性方面找到平衡點。
虛擬路由冗餘協議就是一種很好的解決方案。在該協議中,對共享多存取訪問介質(如以太網)上終端IP設備的默認網關(Default Gateway)進行冗餘備份,從而在其中一臺路由設備宕機時,備份路由設備及時接管轉發工做,向用戶提供透明的切換,提升了網絡服務質量。
1、協議概述
在基於TCP/IP協議的網絡中,爲了保證不直接物理鏈接的設備之間的通訊,必須指定路由。目前經常使用的指定路由的方法有兩種:一種是經過路由協議(好比:內部路由協議RIP和OSPF)動態學習;另外一種是靜態配置。在每個終端都運行動態路由協議是不現實的,大多客戶端操做系統平臺都不支持動態路由協議,即便支持也受到管理開銷、收斂度、安全性等許多問題的限制。所以廣泛採用對終端IP設備靜態路由配置,通常是給終端設備指定一個或者多個默認網關(Default Gateway)。靜態路由的方法簡化了網絡管理的複雜度和減輕了終端設備的通訊開銷,可是它仍然有一個缺點:若是做爲默認網關的路由器損壞,全部使用該網關爲下一跳主機的通訊必然要中斷。即使配置了多個默認網關,如不從新啓動終端設備,也不能切換到新的網關。採用虛擬路由冗餘協議 (Virtual Router Redundancy Protocol,簡稱VRRP)能夠很好的避免靜態指定網關的缺陷。
在VRRP協議中,有兩組重要的概念:VRRP路由器和虛擬路由器,主控路由器和備份路由器。VRRP路由器是指運行VRRP的路由器,是物理實體,虛擬路由器是指VRRP協議建立的,是邏輯概念。一組VRRP路由器協同工做,共同構成一臺虛擬路由器。該虛擬路由器對外表現爲一個具備惟一固定IP地址和MAC地址的邏輯路由器。處於同一個VRRP組中的路由器具備兩種互斥的角色:主控路由器和備份路由器,一個VRRP組中有且只有一臺處於主控角色的路由器,能夠有一個或者多個處於備份角色的路由器。VRRP協議使用選擇策略從路由器組中選出一臺做爲主控,負責ARP相應和轉發IP數據包,組中的其它路由器做爲備份的角色處於待命狀態。當因爲某種緣由主控路由器發生故障時,備份路由器能在幾秒鐘的時延後升級爲主路由器。因爲此切換很是迅速並且不用改變IP地址和MAC地址,故對終端使用者系統是透明的。
2、工做原理
一個VRRP路由器有惟一的標識:VRID,範圍爲0—255。該路由器對外表現爲惟一的虛擬MAC地址,地址的格式爲00-00-5E-00-01-[VRID]。主控路由器負責對ARP請求用該MAC地址作應答。這樣,不管如何切換,保證給終端設備的是惟一一致的IP和MAC地址,減小了切換對終端設備的影響。
VRRP控制報文只有一種:VRRP通告(advertisement)。它使用IP多播數據包進行封裝,組地址爲224.0.0.18,發佈範圍只限於同一局域網內。這保證了VRID在不一樣網絡中能夠重複使用。爲了減小網絡帶寬消耗只有主控路由器才能夠週期性的發送VRRP通告報文。備份路由器在連續三個通告間隔內收不到VRRP或收到優先級爲0的通告後啓動新的一輪VRRP選舉。
在VRRP路由器組中,按優先級選舉主控路由器,VRRP協議中優先級範圍是0—255。若VRRP路由器的IP地址和虛擬路由器的接口IP地址相同,則稱該虛擬路由器做VRRP組中的IP地址全部者;IP地址全部者自動具備最高優先級:255。優先級0通常用在IP地址全部者主動放棄主控者角色時使用。可配置的優先級範圍爲1—254。優先級的配置原則能夠依據鏈路的速度和成本、路由器性能和可靠性以及其它管理策略設定。主控路由器的選舉中,高優先級的虛擬路由器獲勝,所以,若是在VRRP組中有IP地址全部者,則它老是做爲主控路由的角色出現。對於相同優先級的候選路由器,按照IP地址大小順序選舉。VRRP還提供了優先級搶佔策略,若是配置了該策略,高優先級的備份路由器便會剝奪當前低優先級的主控路由器而成爲新的主控路由器。
爲了保證VRRP協議的安全性,提供了兩種安全認證措施:明文認證和IP頭認證。明文認證方式要求:在加入一個VRRP路由器組時,必須同時提供相同的VRID和明文密碼。適合於避免在局域網內的配置錯誤,但不能防止經過網絡監聽方式得到密碼。IP頭認證的方式提供了更高的安全性,可以防止報文重放和修改等***。
3、 應用實例
最典型的VRRP應用:RTA、RTB組成一個VRRP路由器組,假設RTB的處理能力高於RTA,則將RTB配置成IP地址全部者,H一、H二、H3的默認網關設定爲RTB。則RTB成爲主控路由器,負責ICMP重定向、ARP應答和IP報文的轉發;一旦RTB失敗,RTA當即啓動切換,成爲主控,從而保證了對客戶透明的安全切換。
在VRRP應用中,RTA在線時RTB只是做爲後備,不參與轉發工做,閒置了路由器RTA和鏈路L1。經過合理的網絡設計,能夠到達備份和負載分擔雙重效果。讓RTA、RTB同時屬於互爲備份的兩個VRRP組:在組1中RTA爲IP地址全部者;組2中RTB爲IP地址全部者。將H1的默認網關設定爲RTA;H二、H3的默認網關設定爲RTB。這樣,既分擔了設備負載和網絡流量,又提升了網絡可靠性。
VRRP協議的工做機理與CISCO公司的HSRP(Hot Standby Routing Protocol)有許多類似之處。但兩者主要的區別是在CISCO的HSRP中,須要單獨配置一個IP地址做爲虛擬路由器對外體現的地址,這個地址不能是組中任何一個成員的接口地址。
使用VRRP協議,不用改造目前的網絡結構,最大限度保護了當前投資,只需最少的管理費用,卻大大提高了網絡性能,具備重大的應用價值。
===================================================================================
from:http://www.cnblogs.com/killkill/archive/2010/12/31/1922360.html
VIP的飄動能夠爲咱們解決不少問題,之前我試過使用ifup/ifdown的方式控制網卡的up/down來實現,這種方式有個小問題,就是每次VIP 飄動以後都要等上幾十秒才能生效,感受時間比較長,並且還要配合一些邏輯腳本才能很好地工做,有沒有更好的方法呢?固然有,這就是本文的主角—— keepalived。
安裝很簡單:
tar zxvf keepalived-1.1.20.tar.gz cd keepalived-1.1.20 ./configure --prefix=/ make make install
修改一下 /etc/keepalived/keepalived.conf 這個配置文件就能夠用了,如下是個人環境,192.168.172.1和192.168.172.2是兩個VIP,能夠在兩臺服務器之間互動:
主機的配置:
global_defs { notification_email { failover@firewall.loc } notification_email_from Alexandre.Cassen@firewall.loc smtp_server 192.168.0.48 smtp_connect_timeout 10 router_id nginx } vrrp_instance VI_141 { state BACKUP interface eth0 virtual_router_id 141 priority 50 //主機優先級 advert_int 1 authentication { auth_type PASS auth_pass 141 } virtual_ipaddress { 192.168.172.1/26 dev eth0 } } vrrp_instance VI_142 { state BACKUP interface eth0 virtual_router_id 142 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 142 } virtual_ipaddress { 192.168.172.2/26 dev eth0 } }
備機的配置:
global_defs { notification_email { failover@firewall.loc } notification_email_from Alexandre.Cassen@firewall.loc smtp_server 10.168.0.48 smtp_connect_timeout 10 router_id nginx } vrrp_instance VI_141 { state BACKUP interface eth0 virtual_router_id 141 priority 100 //備機優先級 advert_int 1 authentication { auth_type PASS auth_pass 141 } virtual_ipaddress { 192.168.172.1/26 dev eth0 } } vrrp_instance VI_142 { state BACKUP interface eth0 virtual_router_id 142 priority 50 advert_int 1 authentication { auth_type PASS auth_pass 142 } virtual_ipaddress { 192.168.172.2/26 dev eth0 } }
乍一看,主機和備機的配置文件是同樣的,仔細看一下priority的值。
使用如下命令便可將keepalived加入linux的服務中:
chkconfig --add keepalived ; 或 chkconfig --level 345 keepalived on ;
經過啓、停keepalived這個服務便可觀察到VIP的飄動,至於爲何VIP飄動後能夠很快地生效,還有待研究。
===================================================================================
個人環境:
haproxy keepalived 主:192.168.1.192
haproxy keepalived 備:192.168.1.193
vip:192.168.1.200
web:192.168.1.187:80 192.168.1.187:8000
一:安裝過程,在192.168.1.192上:
keepalived的安裝: #tar -zxvf keepalived-1.1.17.tar.gz #ln -s /usr/src/kernels/2.6.18-128.el5-i686/ /usr/src/linux #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 keepalived vrrp_script chk_http_port { script "/etc/keepalived/check_haproxy.sh" interval 2 weight 2 global_defs { router_id LVS_DEVEL } vrrp_instance VI_1 { state MASTER #192.168.1.193上改成BACKUP interface eth0 virtual_router_id 51 priority 150 #192.168.1.193上改成120 advert_int 1 authentication { auth_type PASS auth_pass 1111 } track_script { chk_http_port } virtual_ipaddress { 192.168.1.200 } } } #vi /etc/keepalived/check_haproxy.sh #!/bin/bash A=`ps -C haproxy --no-header |wc -l` if [ $A -eq 0 ];then /usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/conf/haproxy.cfg sleep 3 if [ `ps -C haproxy --no-header |wc -l` -eq 0 ];then /etc/init.d/keepalived stop fi fi #chmod 755 /etc/keepalived/check_haproxy.sh
haproxy的安裝(主備都同樣): #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.cfg global log 127.0.0.1 local3 info maxconn 4096 user nobody group nobody daemon nbproc 1 pidfile /usr/local/haproxy/logs/haproxy.pid defaults maxconn 2000 contimeout 5000 clitimeout 30000 srvtimeout 30000 mode http log global log 127.0.0.1 local3 info stats uri /admin?stats option forwardfor frontend http_server bind :80 log global default_backend info_cache acl test hdr_dom(host) -i test.domain.com use_backend cache_test if test backend info_cache #balance roundrobin balance source option httpchk HEAD /haproxy.txt HTTP/1.1\r\nHost:192.168.1.187 server inst2 192.168.1.187:80 check inter 5000 fall 3 backend cache_test balance roundrobin #balance source option httpchk HEAD /haproxy.txt HTTP/1.1\r\nHost:test.domain.com server inst1 192.168.1.187:8000 check inter 5000 fall 3
二:再兩臺機器上都分別啓動:
/etc/init.d/keepalived start (這條命令會自動把haproxy啓動)
三:測試:
1.再兩臺機器上分別執行ip add
主: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0c:29:98:cd:c0 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.192/24 brd 192.168.1.255 scope global eth0
inet 192.168.1.200/32 scope global eth0
inet6 fe80::20c:29ff:fe98:cdc0/64 scope link
valid_lft forever preferred_lft forever
備: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0c:29:a6:0c:7e brd ff:ff:ff:ff:ff:ff
inet 192.168.1.193/24 brd 255.255.255.254 scope global eth0
inet6 fe80::20c:29ff:fea6:c7e/64 scope link
valid_lft forever preferred_lft forever
2.停掉主上的haproxy,3秒後keepalived會自動將其再次啓動
3.停掉主的keepalived,備機立刻接管服務
備: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0c:29:a6:0c:7e brd ff:ff:ff:ff:ff:ff
inet 192.168.1.193/24 brd 255.255.255.254 scope global eth0
inet 192.168.1.200/32 scope global eth0
inet6 fe80::20c:29ff:fea6:c7e/64 scope link
valid_lft forever preferred_lft forever
4.更改hosts
192.168.1.200 test.com
192.168.1.200 test.domain.com
經過IE測試,能夠發現
test.com的請求發向了192.168.1.187:80
test.domain.com的請求發向了192.168.1.187:8000