libnet下載地址： http://search.cpan.org/dist/libnet/
ipvsadm下載地址： http://www.linuxvirtualserver.org/software/ipvs.html#kernel-2.6
從Linux內核版本2.6起，ip_vs code已經被整合進了內核中，因此，只要在編譯內核的時候選擇了ipvs的功能，您的Linux即能支持LVS。Linux 2.4.23以後的內核版本也整合了ip_vs code，但如果是更舊的內核版本，您得自己手動將ip_vs code整合進內核原碼中，並重新編譯內核方可使用lvs。
一、關於ipvsadm:
ipvsadm是運行於用戶空間、用來與ipvs交互的命令行工具，它的作用表現在：
1、定義在Director上進行dispatching的服務(service)，以及哪此服務器(server)用來提供此服務；
2、爲每臺同時提供某一種服務的服務器定義其權重（即概據服務器性能確定的其承擔負載的能力）；
注：權重用整數來表示，有時候也可以將其設置爲atomic_t；其有效表示值範圍爲24bit整數空間，即（2^24-1）；
因此，ipvsadm命令的主要作用表現在以下方面：
1、添加服務（通過設定其權重>0）；
2、關閉服務（通過設定其權重>0）；此應用場景中，已經連接的用戶將可以繼續使用此服務，直到其退出或超時；新的連接請求將被拒絕；
3、保存ipvs設置，通過使用“ipvsadm-sav > ipvsadm.sav”命令實現；
4、恢復ipvs設置，通過使用“ipvsadm-sav < ipvsadm.sav”命令實現；
5、顯示ip_vs的版本號，下面的命令顯示ipvs的hash表的大小爲4k；
# ipvsadm
IP Virtual Server version 1.2.1 (size=4096)
6、顯示ipvsadm的版本號
# ipvsadm --version
ipvsadm v1.24 2003/06/07 (compiled with popt and IPVS v1.2.0)
二、ipvsadm使用中應注意的問題
默認情況下，ipvsadm在輸出主機信息時使用其主機名而非IP地址，因此，Director需要使用名稱解析服務。如果沒有設置名稱解析服務、服務不可用或設置錯誤，ipvsadm將會一直等到名稱解析超時後才返回。當然，ipvsadm需要解析的名稱僅限於RealServer，考慮到DNS提供名稱解析服務效率不高的情況，建議將所有RealServer的名稱解析通過/etc/hosts文件來實現；
三、調度算法
Director在接收到來自於Client的請求時，會基於"schedule"從RealServer中選擇一個響應給Client。ipvs支持以下調度算法：
1、輪詢（round robin, rr),加權輪詢(Weighted round robin, wrr)——新的連接請求被輪流分配至各RealServer；算法的優點是其簡潔性，它無需記錄當前所有連接的狀態，所以它是一種無狀態調度。輪叫調度算法假設所有服務器處理性能均相同，不管服務器的當前連接數和響應速度。該算法相對簡單，不適用於服務器組中處理性能不一的情況，而且當請求服務時間變化比較大時，輪叫調度算法容易導致服務器間的負載不平衡。
2、最少連接(least connected, lc)， 加權最少連接(weighted least connection, wlc)——新的連接請求將被分配至當前連接數最少的RealServer；最小連接調度是一種動態調度算法，它通過服務器當前所活躍的連接數來估計服務器的負載情況。調度器需要記錄各個服務器已建立連接的數目，當一個請求被調度到某臺服務器，其連接數加1；當連接中止或超時，其連接數減一。
3、基於局部性的最少鏈接調度（Locality-Based Least Connections Scheduling，lblc）——針對請求報文的目標IP地址的負載均衡調度，目前主要用於Cache集羣系統，因爲在Cache集羣中客戶請求報文的目標IP地址是變化的。這裏假設任何後端服務器都可以處理任一請求，算法的設計目標是在服務器的負載基本平衡情況下，將相同目標IP地址的請求調度到同一臺服務器，來提高各臺服務器的訪問局部性和主存Cache命中率，從而整個集羣系統的處理能力。LBLC調度算法先根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於其一半的工作負載，則用“最少鏈接”的原則選出一個可用的服務器，將請求發送到該服務器。
4、帶複製的基於局部性最少鏈接調度（Locality-Based Least Connections with Replication Scheduling，lblcr）——也是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統。它與LBLC算法的不同之處是它要維護從一個目標IP地址到一組服務器的映射，而 LBLC算法維護從一個目標IP地址到一臺服務器的映射。對於一個“熱門”站點的服務請求，一臺Cache 服務器可能會忙不過來處理這些請求。這時，LBLC調度算法會從所有的Cache服務器中按“最小連接”原則選出一臺Cache服務器，映射該“熱門”站點到這臺Cache服務器，很快這臺Cache服務器也會超載，就會重複上述過程選出新的Cache服務器。這樣，可能會導致該“熱門”站點的映像會出現在所有的Cache服務器上，降低了Cache服務器的使用效率。LBLCR調度算法將“熱門”站點映射到一組Cache服務器（服務器集合），當該“熱門”站點的請求負載增加時，會增加集合裏的Cache服務器，來處理不斷增長的負載；當該“熱門”站點的請求負載降低時，會減少集合裏的Cache服務器數目。這樣，該“熱門”站點的映像不太可能出現在所有的Cache服務器上，從而提供Cache集羣系統的使用效率。LBLCR算法先根據請求的目標IP地址找出該目標IP地址對應的服務器組；按“最小連接”原則從該服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載；則按“最小連接”原則從整個集羣中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低複製的程度。
5、目標地址散列調度（Destination Hashing，dh）算法也是針對目標IP地址的負載均衡，但它是一種靜態映射算法，通過一個散列（Hash）函數將一個目標IP地址映射到一臺服務器。目標地址散列調度算法先根據請求的目標IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
6、源地址散列調度（Source Hashing，sh）算法正好與目標地址散列調度算法相反，它根據請求的源IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。它採用的散列函數與目標地址散列調度算法的相同。除了將請求的目標IP地址換成請求的源IP地址外，它的算法流程與目標地址散列調度算法的基本相似。在實際應用中，源地址散列調度和目標地址散列調度可以結合使用在防火牆集羣中，它們可以保證整個系統的唯一出入口。
四、關於LVS追蹤標記fwmark：
如果LVS放置於多防火牆的網絡中，並且每個防火牆都用到了狀態追蹤的機制，那麼在迴應一個針對於LVS的連接請求時必須經過此請求連接進來時的防火牆，否則，這個響應的數據包將會被丟棄。
查看LVS上當前的所有連接
# ipvsadm -Lcn
或者
#cat /proc/net/ip_vs_conn
查看虛擬服務和RealServer上當前的連接數、數據包數和字節數的統計值，則可以使用下面的命令實現：
# ipvsadm -l --stats
查看包傳遞速率的近似精確值，可以使用下面的命令：
# ipvsadm -l --rate
VS/NAT
LVS-NAT基於cisco的LocalDirector。VS/NAT不需要在RealServer上做任何設置，其只要能提供一個tcp/ip的協議棧即可，甚至其無論基於什麼OS。基於VS/NAT，所有的入站數據包均由Director進行目標地址轉換後轉發至內部的RealServer，RealServer響應的數據包再由Director轉換源地址後發回客戶端。
VS/NAT模式不能與netfilter兼容，因此，不能將VS/NAT模式的Director運行在netfilter的保護範圍之中。現在已經有補丁可以解決此問題，但尚未被整合進ip_vs code。
____________
| |
| client |
|____________|
CIP=192.168.0.253 (eth0)
|
|
VIP=192.168.0.220 (eth0)
____________
| |
| director |
|____________|
DIP=192.168.10.10 (eth1)
|
(switch)------------------------
| |
RIP=192.168.10.2 (eth0) RIP=192.168.10.3 (eth0)
_____________ _____________
| | | |
| realserver1 | | realserver2 |
|_____________| |_____________|
設置VS/NAT模式的LVS(這裏以web服務爲例)
Director:
建立服務
# ipvsadm -A -t VIP:PORT -s rr
如:
# ipvsadm -A -t 192.168.0.220:80 -s rr
設置轉發：
# ipvsadm -a -t VIP:PORT -r RIP_N:PORT -m -w N
如：
# ipvsadm -a -t 192.168.0.220:80 -r 192.168.10.2 -m -w 1
# ipvsadm -a -t 192.168.0.220:80 -r 192.168.10.3 -m -w 1
打開路由轉發功能
# echo "1" > /proc/sys/net/ipv4/ip_forward
服務控制腳本：
#!/bin/bash
#
# chkconfig: - 88 12
# description: LVS script for VS/NAT
#
. /etc/rc.d/init.d/functions
#
VIP=192.168.0.219
DIP=192.168.10.10
RIP1=192.168.10.11
RIP2=192.168.10.12
#
case "$1" in
start)
/sbin/ifconfig eth0:1 $VIP netmask 255.255.255.0 up
# Since this is the Director we must be able to forward packets
echo 1 > /proc/sys/net/ipv4/ip_forward
# Clear all iptables rules.
/sbin/iptables -F
# Reset iptables counters.
/sbin/iptables -Z
# Clear all ipvsadm rules/services.
/sbin/ipvsadm -C
# Add an IP virtual service for VIP 192.168.0.219 port 80
# In this recipe, we will use the round-robin scheduling method.
# In production, however, you should use a weighted, dynamic scheduling method.
/sbin/ipvsadm -A -t $VIP:80 -s rr
# Now direct packets for this VIP to
# the real server IP (RIP) inside the cluster
/sbin/ipvsadm -a -t $VIP:80 -r $RIP1 -m
/sbin/ipvsadm -a -t $VIP:80 -r $RIP2 -m
/bin/touch /var/lock/subsys/ipvsadm.lock
;;
stop)
# Stop forwarding packets
echo 0 > /proc/sys/net/ipv4/ip_forward
# Reset ipvsadm
/sbin/ipvsadm -C
# Bring down the VIP interface
ifconfig eth0:1 down
rm -rf /var/lock/subsys/ipvsadm.lock
;;
status)
[ -e /var/lock/subsys/ipvsadm.lock ] && echo "ipvs is running..." || echo "ipvsadm is stopped..."
;;
*)
echo "Usage: $0 {start|stop}"
;;
esac
ARP問題：
__________
| |
| client |
|________|
|
|
(router)
|
|
| __________
| DIP | |
|------| director |
| VIP |__________|
|
|
|
------------------------------------
| | |
| | |
RIP1, VIP RIP2, VIP RIP3, VIP
______________ ______________ ______________
| | | | | |
| realserver1 | | realserver2 | | realserver3 |
|______________| |______________| |______________|
在如上圖的VS/DR或VS/TUN應用的一種模型中（所有機器都在同一個物理網絡），所有機器（包括Director和RealServer）都使用了一個額外的IP地址，即VIP。當一個客戶端向VIP發出一個連接請求時，此請求必須要連接至Director的VIP，而不能是RealServer的。因爲，LVS的主要目標就是要Director負責調度這些連接請求至RealServer的。
因此，在Client發出至VIP的連接請求後，只能由Director將其MAC地址響應給客戶端（也可能是直接與Director連接的路由設備），而Director則會相應的更新其ipvsadm table以追蹤此連接，而後將其轉發至後端的RealServer之一。
如果Client在請求建立至VIP的連接時由某RealServer響應了其請求，則Client會在其MAC table中建立起一個VIP至RealServer的對就關係，並以至進行後面的通信。此時，在Client看來只有一個RealServer而無法意識到其它服務器的存在。
爲了解決此問題，可以通過在路由器上設置其轉發規則來實現。當然，如果沒有權限訪問路由器並做出相應的設置，則只能通過傳統的本地方式來解決此問題了。這些方法包括：
1、禁止RealServer響應對VIP的ARP請求；
2、在RealServer上隱藏VIP，以使得它們無法獲知網絡上的ARP請求；
3、基於“透明代理（Transparent Proxy）”或者“fwmark （firewall mark）”；
4、禁止ARP請求發往RealServers；
傳統認爲，解決ARP問題可以基於網絡接口，也可以基於主機來實現。Linux採用了基於主機的方式，因爲其可以在大多場景中工作良好，但LVS卻並不屬於這些場景之一，因此，過去實現此功能相當麻煩。現在可以通過設置arp_ignore和arp_announce，這變得相對簡單的多了。
Linux 2.2和2.4（2.4.26之前的版本）的內核解決“ARP問題”的方法各不相同，且比較麻煩。幸運的是，2.4.26和2.6的內核中引入了兩個新的調整ARP棧的標誌（device flags）：arp_announce和arp_ignore。基於此，在DR/TUN的環境中，所有IPVS相關的設定均可使用arp_announce=2和arp_ignore=1/2/3來解決“ARP問題”了。
arp_annouce：Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent on interface；
0 - (default) Use any local address, configured on any interface.
1 - Try to avoid local addresses that are not in the target's subnet for this interface.
2 - Always use the best local address for this target.
arp_ignore: Define different modes for sending replies in response to received ARP requests that resolve local target IP address.
0 - (default): reply for any local target IP address, configured on any interface.
1 - reply only if the target IP address is local address configured on the incoming interface.
2 - reply only if the target IP address is local address configured on the incoming interface and both with the sender's IP address are part from same subnet on this interface.
3 - do not reply for local address configured with scope host, only resolutions for golbal and link addresses are replied.
4-7 - reserved
8 - do not reply for all local addresses
在RealServers上，VIP配置在本地迴環接口lo上。如果迴應給Client的數據包路由到了eth0接口上，則arp通告或請應該通過eth0實現，因此，需要在sysctl.conf文件中定義如下配置：
#vim /etc/sysctl.conf
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
以上選項需要在啓用VIP之前進行，否則，則需要在Drector上清空arp表才能正常使用LVS。
到達Director的數據包首先會經過PREROUTING，而後經過路由發現其目標地址爲本地某接口的地址，因此，接着就會將數據包發往INPUT(LOCAL_IN HOOK)
HOOK）進程會發現此數據包請求的是一個集羣服務，因爲其目標地址是VIP。於是，此數據包的本來到達本機(Director)目標行程被改變爲經由POSTROUTING HOOK發往RealServer。這種改變數據包正常行程的過程是根據IPVS表(由管理員通過ipvsadm定義)來實現的。
如果有多臺Realserver，在某些應用場景中，Director還需要基於“連接追蹤”實現將由同一個客戶機的請求始終發往其第一次被分配至的Realserver，以保證其請求的完整性等。其連接追蹤的功能由Hash table實現。Hash table的大小等屬性可通過下面的命令查看：
# ipvsadm -lcn
爲了保證其時效性，Hash table中“連接追蹤”信息被定義了“生存時間”。LVS爲記錄“連接超時”定義了三個計時器：
1、空閒TCP會話；
2、客戶端正常斷開連接後的TCP會話；
3、無連接的UDP數據包（記錄其兩次發送數據包的時間間隔）；
上面三個計時器的默認值可以由類似下面的命令修改，其後面的值依次對應於上述的三個計時器：
# ipvsadm --set 28800 30 600
數據包在由Direcotr發往Realserver時，只有目標MAC地址發生了改變(變成了Realserver的MAC地址)。Realserver在接收到數據包後會根據本地路由表將數據包路由至本地迴環設備，接着，監聽於本地迴環設備VIP上的服務則對進來的數據庫進行相應的處理，而後將處理結果迴應至RIP，但數據包的原地址依然是VIP。
ipvs的持久連接：
無論基於什麼樣的算法，只要期望源於同一個客戶端的請求都由同一臺Realserver響應時，就需要用到持久連接。比如，某一用戶連續打開了三個telnet連接請求時，根據RR算法，其請求很可能會被分配至不同的Realserver，這通常不符合使用要求。
Director腳本:
#!/bin/bash
#
# LVS script for VS/DR
#
. /etc/rc.d/init.d/functions
#
VIP=192.168.0.210
RIP1=192.168.0.221
RIP2=192.168.0.222
PORT=80
#
case "$1" in
start)
/sbin/ifconfig eth0:1 $VIP broadcast $VIP netmask 255.255.255.255 up
/sbin/route add -host $VIP dev eth0:1
# Since this is the Director we must be able to forward packets
echo 1 > /proc/sys/net/ipv4/ip_forward
# Clear all iptables rules.
/sbin/iptables -F
# Reset iptables counters.
/sbin/iptables -Z
# Clear all ipvsadm rules/services.
/sbin/ipvsadm -C
# Add an IP virtual service for VIP 192.168.0.219 port 80
# In this recipe, we will use the round-robin scheduling method.
# In production, however, you should use a weighted, dynamic scheduling method.
/sbin/ipvsadm -A -t $VIP:80 -s wlc
# Now direct packets for this VIP to
# the real server IP (RIP) inside the cluster
/sbin/ipvsadm -a -t $VIP:80 -r $RIP1 -g -w 1
/sbin/ipvsadm -a -t $VIP:80 -r $RIP2 -g -w 2
/bin/touch /var/lock/subsys/ipvsadm &> /dev/null
;;
stop)
# Stop forwarding packets
echo 0 > /proc/sys/net/ipv4/ip_forward
# Reset ipvsadm
/sbin/ipvsadm -C
# Bring down the VIP interface
/sbin/ifconfig eth0:1 down
/sbin/route del $VIP
/bin/rm -f /var/lock/subsys/ipvsadm
echo "ipvs is stopped..."
;;
status)
if [ ! -e /var/lock/subsys/ipvsadm ]; then
echo "ipvsadm is stopped ..."
else
echo "ipvs is running ..."
ipvsadm -L -n
fi
;;
*)
echo "Usage: $0 {start|stop|status}"
;;
esac
RealServer腳本:
#!/bin/bash
#
# Script to start LVS DR real server.
# description: LVS DR real server
#
. /etc/rc.d/init.d/functions
VIP=192.168.0.219
host=`/bin/hostname`
case "$1" in
start)
# Start LVS-DR real server on this machine.
/sbin/ifconfig lo down
/sbin/ifconfig lo up
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
/sbin/ifconfig lo:0 $VIP broadcast $VIP netmask 255.255.255.255 up
/sbin/route add -host $VIP dev lo:0
;;
stop)
# Stop LVS-DR real server loopback device(s).
/sbin/ifconfig lo:0 down
echo 0 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/lo/arp_announce
echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce
;;
status)
# Status of LVS-DR real server.
islothere=`/sbin/ifconfig lo:0 | grep $VIP`
isrothere=`netstat -rn | grep "lo:0" | grep $VIP`
if [ ! "$islothere" -o ! "isrothere" ];then
# Either the route or the lo:0 device
# not found.
echo "LVS-DR real server Stopped."
else
echo "LVS-DR real server Running."
fi
;;
*)
# Invalid entry.
echo "$0: Usage: $0 {start|status|stop}"
exit 1
;;
esac
HeartBeat
運行於備用主機上的Heartbeat可以通過以太網連接檢測主服務器的運行狀態，一旦其無法檢測到主服務器的“心跳”則自動接管主服務器的資源。通常情況下，主、備服務器間的心跳連接是一個獨立的物理連接，這個連接可以是串行線纜、一個由“交叉線”實現的以太網連接。Heartbeat甚至可同時通過多個物理連接檢測主服務器的工作狀態，而其只要能通過其中一個連接收到主服務器處於活動狀態的信息，就會認爲主服務器處於正常狀態。從實踐經驗的角度來說，建議爲Heartbeat配置多條獨立的物理連接，以避免Heartbeat通信線路本身存在單點故障。
1、串行電纜：被認爲是比以太網連接安全性稍好些的連接方式，因爲hacker無法通過串行連接運行諸如telnet、ssh或rsh類的程序，從而可以降低其通過已劫持的服務器再次侵入備份服務器的機率。但串行線纜受限於可用長度，因此主、備服務器的距離必須非常短。
2、以太網連接：使用此方式可以消除串行線纜的在長度方面限制，並且可以通過此連接在主備服務器間同步文件系統，從而減少了從正常通信連接帶寬的佔用。
基於冗餘的角度考慮，應該在主、備服務器使用兩個物理連接傳輸heartbeat的控制信息；這樣可以避免在一個網絡或線纜故障時導致兩個節點同時認爲自已是唯一處於活動狀態的服務器從而出現爭用資源的情況，這種爭用資源的場景即是所謂的“腦裂”（split-brain）或“partitioned cluster”。在兩個節點共享同一個物理設備資源的情況下，腦裂會產生相當可怕的後果。
爲了避免出現腦裂，可採用下面的預防措施：
1、如前所述，在主、備節點間建立一個冗餘的、可靠的物理連接來同時傳送控制信息；
2、一旦發生腦裂時，藉助額外設備強制性地關閉其中一個節點；
第二種方式即是俗稱的“將其它節點‘爆頭’（shoot the other node in the head）”，簡稱爲STONITH。基於能夠通過軟件指令關閉某節點特殊的硬件設備，Heartbeat即可實現可配置的Stonith。但當主、備服務器是基於WAN進行通信時，則很難避免“腦裂”情景的出現。因此，當構建異地“容災”的應用時，應儘量避免主、備節點共享物理資源。
Heartbeat的控制信息：
“心跳”信息: （也稱爲狀態信息）僅150 bytes大小的廣播、組播或多播數據包。可爲以每個節點配置其向其它節點通報“心跳”信息的頻率，以及其它節點上的heartbeat進程爲了確認主節點出節點出現了運行等錯誤之前的等待時間。
集羣變動事務（transition）信息：ip-request和ip-request-rest是相對較常見的兩種集羣變動信息，它們在節點間需要進行資源遷移時爲不同節點上heartbeat進程間會話傳遞信息。比如，當修復了主節點並且使其重新“上線”後，主節點會使用ip-request要求備用節點釋放其此前從因主節點故障而從主節點那裏接管的資源。此時，備用節點則關閉服務並使用ip-request-resp通知主節點其已經不再佔用此前接管的資源。主接點收到ip-request-resp後就會重新啓動服務。
重傳請求：在某集羣節點發現其從其它節點接收到的heartbeat控制信息“失序”（heartbeat進程使用序列號來確保數據包在傳輸過程中沒有被丟棄或出現錯誤）時，會要求對方重新傳送此控制信息。 Heartbeat一般每一秒發送一次重傳請求，以避免洪泛。
上面三種控制信息均基於UDP協議進行傳送，可以在/etc/ha.d/ha.cf中指定其使用的UDP端口或者多播地址（使用以太網連接的情況下）。
此外，除了使用“序列號/確認”機制來確保控制信息的可靠傳輸外，Heartbeat還會使用MD5或SHA1爲每個數據包進行簽名以確保傳輸中的控制信息的安全性。
資源腳本：
資源腳本（resource scripts）即Heartbeat控制下的腳本。這些腳本可以添加或移除IP別名（IP alias)或從屬IP地址（secondary IP address），或者包含了可以啓動/停止服務能力之外數據包的處理功能等。通常，Heartbeat會到/etc/init.d/或/etc/ha.d/resource.d/目錄中讀取腳本文件。Heartbeat需要一直明確瞭解“資源”歸哪個節點擁有或由哪個節點提供。在編寫一個腳本來啓動或停止某個資源時，一定在要腳本中明確判斷出相關服務是否由當前系統所提供。
Heartbeat的配置文件：
/etc/ha.d/ha.cf
定義位於不同節點上的heartbeat進程間如何進行通信；
/etc/ha.d/haresources
定義對某個資源來說哪個服務器是主節點，以及哪個節點應該擁有客戶端訪問資源時的目標IP地址。
/etc/ha.d/authkeys
定義Heartbeat包在通信過程中如何進行加密。
當ha.cf或authkeys文件發生改變時，需要重新加載它們就可以使用之生效；而如果haresource文件發生了改變，則只能重啓heartbeat服務方可使之生效。
儘管Heartbeat並不要求主從節點間進行時鐘同步，但它們彼此間的時間差距不能超過1分鐘，否則一些配置爲高可用的服務可能會出異常。
Heartbeat當前也不監控其所控制的資源的狀態，比如它們是否正在運行，是否運行良好以及是否可供客戶端訪問等。要想監控這些資源，冉要使用額外的Mon軟件包來實現。
haresources配置文件介紹：
主從節點上的/etc/ra.d/raresource文件必須完全相同。文件每行通常包含以下組成部分：
1、服務器名字：指正常情況下資源運行的那個節點（即主節點），後跟一個空格或tab；這裏指定的名字必須跟某個節點上的命令"uname -n"的返回值相同；
2、IP別名（即額外的IP地址，可選）：在啓動資源之前添加至系統的附加IP地址，後跟空格或tab；IP地址後面通常會跟一個子網掩碼和廣播地址，彼此間用“/”隔開；
3、資源腳本：即用來啓動或停止資源的腳本，位於/etc/init.d/或/etc/ha.d/resourcd.d目錄中；如果需要傳遞參數給資源腳本，腳本和參數之間需要用兩個冒號分隔，多個參數時彼此間也需要用兩個冒號分隔；如果有多個資源腳本，彼此間也需要使用空格隔開；
格式如下：
primary-server [IPaddress[/mask/interface/broadcast]] resource1[::arg1::arg2] resource2[::arg1::arg2]
例如：
primary-server 221.67.132.195 sendmail httpd
安裝配置Heartbeat
yum install
cp /usr/share/doc/heartbeat-2*/authkeys, ha.cf, haresources
( echo -ne "auth 1\n1 sha1 "; \
dd if=/dev/urandom bs=512 count=1 | openssl md5 ) \
> /etc/ha.d/authkeys
chmod 0600 /etc/ha.d/authkeys
/usr/lib/heartbeat/ha_propagate
HA的LVS集羣有兩臺Director，在啓動時，主節點佔有集羣負載均衡資源（VIP和LVS的轉發及高度規則），備用節點監聽主節點的“心跳”信息並在主節點出現異常時進行“故障轉移”而取得資源使用權，這包括如下步驟：
1、添加VIP至其網絡接口；
2、廣播GARP信息，通知網絡內的其它主機目前本Director其佔有VIP；
3、創建IPVS表以實現入站請求連接的負載均衡；
4、Stonith；
棄用resource腳本，改用ldirecotord來控制LVS：
ldirectord用來實現LVS負載均衡資源的在主、備節點間的故障轉移。在首次啓動時，ldirectord可以自動創建IPVS表。此外，它還可以監控各Realserver的運行狀態，一旦發現某Realserver運行異常時，還可以將其從IPVS表中移除。
ldirectord進程通過向Realserver的RIP發送資源訪問請求並通過由Realserver返回的響應信息來確定Realserver的運行狀態。在Director上，每一個VIP需要一個單獨的ldirector進程。如果Realserver不能正常響應Directord上ldirectord的請求，ldirectord進程將通過ipvsadm命令將此Realserver從IPVS表中移除。而一旦Realserver再次上線，ldirectord會使用正確的ipvsadm命令將其信息重新添加至IPVS表中。
例如，爲了監控一組提供web服務的Realserver，ldirectord進程使用HTTP協議請求訪問每臺Realserver上的某個特定網頁。ldirectord進程根據自己的配置文件中事先定義了的Realserver的正常響應結果來判斷當前的返回結果是否正常。比如，在每臺web服務器的網站目錄中存放一個頁面".ldirector.html"，其內容爲"GOOD"，ldirectord進程每隔一段時間就訪問一次此網頁，並根據獲取到的響應信息來判斷Realserver的運行狀態是否正常。如果其返回的信息不是"GOOD"，則表明服務不正常。
ldirectord需要從/etc/ha.d/目錄中讀取配置文件，文件名可以任意，但建議最好見名知義。
實現過程：
創建/etc/ha.d/ldirectord-192.168.0.219.cf，添加如下內容：
# Global Directives
checktimeout=20
# ldirectord等待Realserver健康檢查完成的時間，單位爲秒；
# 任何原因的檢查錯誤或超過此時間限制，ldirector將會將此Realserver從IPVS表中移除；
checkinterval=5
# 每次檢查的時間間隔，即檢查的頻率；
autoreload=yes
# 此項用來定義ldirectord是否定期每隔一段時間檢查此配置文件是否發生改變並自動重新加載此文件；
logfile="/var/log/ldirectord.log"
# 定義日誌文件存放位置；
quiescent=yes
# 當某臺Realserver出現異常，此項可將其設置爲靜默狀態（即其權重爲“0”）從而不再響應客戶端的訪問請求；
# For an http virtual service
virtual=192.168.0.219:80
# 此項用來定義LVS服務及其使用的VIP和PORT
real=192.168.0.221:80 gate 100
# 定義Realserver，語法：real=RIP:port gate|masq|ipip [weight]
real=192.168.0.223:80 gate 300
fallback=127.0.0.1:80 gate
# 當IPVS表沒有任何可用的Realserver時，此“地址：端口”作爲最後響應的服務；
# 一般指向127.0.0.1，並可以通過一個包含錯誤信息的頁面通知用戶服務發生了異常；
service=http
# 定義基於什麼服務來測試Realserver；
request=".ldirectord.html"
receive="GOOD"
scheduler=wlc
#persistent=600
#netmask=255.255.255.255
protocol=tcp
# 定義此虛擬服務用到的協議；
checktype=negotiate
# ldirectord進程用於監控Realserver的方法；{negotiate|connect|A number|off}
checkport=80
在/etc/hd.d/haresources中添加類似如下行：
node1.example.com 192.168.0.219 ldirectord::ldirectord-192.168.0.219.cf
# yum install docbook-stype-xsl
# yum install net-snmp-devel
# yum install OpenIPMI-devel
# groupadd -g 694 haclient
# useradd -G haclient -d /dev/null -s /sbin/nologin -u 694 hacluster
安裝glue和heartbeat
# wget http://hg.linux-ha.org/glue/archive/glue-1.0.3.tar.bz2
# tar jxvf glue-1.0.3.tar.bz2
# cd glue-1.0.3
# ./autogen.sh
# ./configure
# make
# make install
# wget http://hg.linux-ha.org/heartbeat-STABLE_3_0/archive/STABLE-3.0.2.tar.bz2
# tar jxvf STABLE-3.0.2.tar.bz2
# cd Heartbeat-3-0-STABLE-3.0.2/
# ./bootstrap
# ./ConfigureMe configure
# make
# make install
# cp doc/{ha.cf,haresources} /etc/ha.d/
生成authkeys：
# echo -ne "auth 1\n1 sha1 " >> /etc/ha.d/authkeys
# dd if=/dev/urandom bs=512 count=1 | openssl md5 >> /etc/ha.d/authkeys
# chmod 0600 /etc/ha.d/authkeys
將heartbeat服務加入到自動啓動隊列：
# chkconfig --add heartbeat
# chkconfig heartbeat on
# /usr/share/heartbeat/ha_propagate
LVS & Heartbeat
# yum -y --nogpgcheck localinstall libnet-1.1.4-3.el5.i386.rpm
# yum -y --nogpgcheck localinstall perl-MailTools-1.77-1.el5.noarch.rpm
# yum -y --nogpgcheck localinstall heartbeat-pils-2.1.4-10.el5.i386.rpm
# yum -y --nogpgcheck localinstall heartbeat-stonith-2.1.4-10.el5.i386.rpm
# yum -y --nogpgcheck localinstall heartbeat-gui-2.1.4-10.el5.i386.rpm
# yum -y --nogpgcheck localinstall heartbeat-ldirectord-2.1.4-10.el5.i386.rpm
# yum -y --nogpgcheck localinstall heartbeat-devel-2.1.4-10.el5.i386.rpm
# yum -y --nogpgcheck localinstall heartbeat-2.1.4-10.el5.i386.rpm
perl-Compress-Zlib
perl-HTML-Parser
perl-HTML-Tagset
perl-URI
perl-libwww-perl
perl-MailTools
perl-TimeDate
perl-String-CRC32
net-snmp-libs
# cp -v /usr/share/doc/heartbeat-2.1.4/{ha.cf,authkeys,haresources} /etc/ha.d/
# cp /usr/share/doc/heartbeat-ldirectord-2.1.4/ldirectord.cf /etc/ha.d/
Director:
eth0 , 192.168.0.209
ifconfig eth0:1 $VIP broadcast $VIP netmask 255.255.255.255
route add -host $VIP dev eth0:1
ipvsadm -A -t $VIP:80 -s wrr
ipvsadm -a -t $VIP:80 -r $RIP1 -w 5 -g
ipvsadm -a -t $VIP:80 -r $RIP2 -w 50 -g
RealServer
iptables -t nat -F
iptables -F
ipvsadm -C
ifdown lo
ifup lo
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
ifconfig lo:0 $VIP broadcast $VIP netmask 255.255.255.255 up
route add -host $VIP dev lo:0
primary.mydomain.com 209.100.100.3/24/eth0/209.100.100.255 httpd
heartbeat (HA), keepalived, ultramokey, openais/corosync
RHCS:RedHat Cluster Suite, (openais/corosync), CRM
pacemaker
方法：
heartbeat v1
/etc/init.d/httpd
CIF
web
IP：192.168.0.186
primary:
IP:192.168.0.181
192.168.10.6
standby
192.168.0.182
192.168.10.7
web
/etc/ha.d/authkeys 該文件在兩個版本作用是完全相同的，都必須設置，並且保證每個節點（node）內容一樣；
/etc/ha.d/ha.cf 這個是主要配置文件，由其決定v1或v2 style格式
/etc/ha.d/haresources 這是v1的資源配置文件
/var/lib/heartbeat/crm/cib.xml 這是v2的資源配置文件，兩者根據ha.cf的設定只能選其一
v2版本使用CRM管理工具，而cib.xml文件可有幾種方式來編寫：
a）人工編寫XML文件；
b）使用admintools工具，其已經包含在heartbeat包中；
c）使用GUI圖形工具配置，也包含在heartbeat-gui包裏面；
d）使用python腳本轉換1.x style的格式配置文件。
# more /etc/ha.d/ha.cf
#發送keepalive包的間隔時間
keepalive 2
#定義節點的失效時間
deadtime 30
#定義heartbeat服務啓動後，等待外圍其他設備（如網卡啓動等）的等待時間
initdead 30
#使用udp端口694 進行心跳監測
udpport 694
#定義心跳
bcast eth0 eth1 # Linux
#定義是否使用auto_failback功能
auto_failback off
#定義集羣的節點
node hatest3
node hatest4
#使用heartbeat提供的日誌服務，若use_logd設置爲yes後，下面的三個選項會失效
use_logd yes
#logfile /var/log/ha_log/ha-log.log
#logfacility local7
#debugfile /var/log/ha_log/ha-debug.log
#設定一個監控網關，用於判斷心跳是否正常
ping 192.168.0.254
deadping 5
#指定和heartbeat一起啓動、關閉的進程
respawn hacluster /usr/local/lib64/heartbeat/ipfail
apiauth ipfail gid=haclient uid=hacluster
先停止heartbeat
service heartbeat stop
vim /etc/ha.d/ha.cf
添加/啓用如下選項：
crm respawn
#下面是對傳輸的數據進行壓縮，是可選項
compression bz2
compression_threshold 2
轉換v1.x爲v2.x格式文件
heartbeat提供了一個使用python寫的轉換工具，可直接轉換v1 style的配置文件爲v2 style：
# /usr/lib/heartbeat/haresources2cib.py /etc/ha.d/haresources
查看資源列表：
crm_resource -L
查看某資源在哪個節點上運行:
# crm_resource -W -r
查看節點運行狀態信息：
# crm_mon -1
CRM:
heartbeat v1, haresources
crm
crm
pacemaker
heartbeat v2
1、停止heartbeat：
2、vim /etc/ha.d/ha.cf
crm respawn
3、
# cd /usr/lib/heartbeat
# ./haresources2cib.py /etc/ha.d/haresources
轉換後的文件：/var/lib/heartbeat/crm/cib.xml
mv /etc/ha.d/haresources /root
# scp /var/lib/heartbeat/crm/cib.xml standby:/var/lib/heartbeat/crm
4、啓動heartbeat
piranha, LVS
pacemaker, heartbeat
heartbeat2, heartbeat3
/usr/lib/ocf/resource.d/heartbeat/IPaddr meta-data
隔離
級別：
節點級別
STONITH: Shoot The Other Node In The Head
資源級別
fencing
active/active
active/passive
n/n-1
n/m
n/n
HA:
fencing
節點
資源
Message and Infrastructure Layer
Membership, CCM
Resource Allcation, CRM, LRM, CIB, PE, TE
Resource Layer, RA
Linux: HA
Heartbeat(v1, v2, v3) (heartbeat, pacemaker, cluster-glue)
Keepalive
Ultramonkey
Corosync/openais + pacemaker
RHCS( heartbeat )
Types of Resources
Primitives
A primitive resource, the most basic type of a resource.
Groups
Groups contain a set of resources that need to be located together, started sequentially and stopped in the reverse order.
Clones
Clones are resources that can be active on multiple hosts. Any resource can be cloned, provided the respective resource agent supports it.
Masters
Masters are a special type of clone resources, they can have multiple modes.