軟件負載均衡一般通過兩種方式來實現：基於操作系統的軟負載實現和基於第三方應用的軟負載實現。LVS就是基於Linux操作系統實現的一種軟負載，HAProxy就是開源的並且基於第三應用實現的軟負載。
HAProxy相比LVS的使用要簡單很多，功能方面也很豐富。當 前，HAProxy支持兩種主要的代理模式:"tcp"也即4層（大多用於郵件服務器、內部協議通信服務器等），和7層（HTTP）。在4層模式 下，HAProxy僅在客戶端和服務器之間轉發雙向流量。7層模式下，HAProxy會分析協議，並且能通過允許、拒絕、交換、增加、修改或者刪除請求 (request)或者回應(response)裏指定內容來控制協議，這種操作要基於特定規則。
我現在用HAProxy主要在於它有以下優點，這裏我總結下：
一、免費開源，穩定性也是非常好，這個可通過我做的一些小項目可以看出來，單Haproxy也跑得不錯，穩定性可以與LVS相媲美；
二、根據官方文檔，HAProxy可以跑滿10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom's 10GbE NICs (Myri-10G PCI-Express)，這個作爲軟件級負載均衡，也是比較驚人的；
三、HAProxy可以作爲MySQL、郵件或其它的非web的負載均衡，我們常用於它作爲MySQL(讀)負載均衡；
四、自帶強大的監控服務器狀態的頁面，實際環境中我們結合Nagios進行郵件或短信報警，這個也是我非常喜歡它的原因之一；
五、HAProxy支持虛擬主機。
===================================================================================
在做反向代理服務器的負載均衡時，我們通常會使用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理論工作原理
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又太貴，你們又是創業型互聯公司如何有效節約成本，節省不必要的浪費？同時實現商業硬件一樣的高性能高可用的功能？有什麼好的負載均衡可伸張可擴展的方案嗎？答案是肯定的！有！我們利用 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)進行冗餘備份，從而在其中一臺路由設備宕機時，備份路由設備及時接管轉發工作，向用戶提供透明的切換，提高了網絡服務質量。
一、協議概述
在基於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地址，故對終端使用者系統是透明的。
二、工作原理
一個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頭認證的方式提供了更高的安全性，能夠防止報文重放和修改等***。
三、 應用實例
最典型的VRRP應用：RTA、RTB組成一個VRRP路由器組，假設RTB的處理能力高於RTA，則將RTB配置成IP地址所有者，H1、H2、H3的默認網關設定爲RTB。則RTB成爲主控路由器，負責ICMP重定向、ARP應答和IP報文的轉發；一旦RTB失敗，RTA立即啓動切換，成爲主控，從而保證了對客戶透明的安全切換。
在VRRP應用中，RTA在線時RTB只是作爲後備，不參與轉發工作，閒置了路由器RTA和鏈路L1。通過合理的網絡設計，可以到達備份和負載分擔雙重效果。讓RTA、RTB同時屬於互爲備份的兩個VRRP組：在組1中RTA爲IP地址所有者；組2中RTB爲IP地址所有者。將H1的默認網關設定爲RTA；H2、H3的默認網關設定爲RTB。這樣，既分擔了設備負載和網絡流量，又提高了網絡可靠性。
VRRP協議的工作機理與CISCO公司的HSRP（Hot Standby Routing Protocol）有許多相似之處。但二者主要的區別是在CISCO的HSRP中，需要單獨配置一個IP地址作爲虛擬路由器對外體現的地址，這個地址不能是組中任何一個成員的接口地址。
使用VRRP協議，不用改造目前的網絡結構，最大限度保護了當前投資，只需最少的管理費用，卻大大提升了網絡性能，具有重大的應用價值。
===================================================================================
keepalive的簡單應用——管理VIP的飄動
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 {
[email protected]
}
notification_email_from [email protected]
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 {
[email protected]
}
notification_email_from [email protected]
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實現高可用負載均衡
我的環境：
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.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.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
